Fd Rl30 Desc

Nokia

LTE Radio Access, Rel. FDDLTE 16A, Operating Documentation, Issue 02 LTE RL30, Feature Descriptions DN0986461 Issue 01R Approval Date 2016-06-29

LTE RL30, Feature Descriptions

The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective company within Nokia Group of Companies with whom you have entered into the Agreement (as defined below). This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the purposes defined in the agreement between You and Nokia (“Agreement”) under which this document is distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia. If You have not entered into an Agreement applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof. The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility when using it. Nokia welcomes your comments as part of the process of continuous development and improvement of the documentation. This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on an “as is” and “as available” basis in this document, and Nokia reserves the right to change any such information and statements without notice. Nokia has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions, and Nokia will correct errors that You identify in this document. Nokia's total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product will be uninterrupted or error-free. NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT. This document is Nokia proprietary and confidential information, which may not be distributed or disclosed to any third parties without the prior written consent of Nokia. Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners. Copyright © 2016 Nokia. All rights reserved.

f

Important Notice on Product Safety This product may present safety risks due to laser, electricity, heat, and other sources of danger. Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product. The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components. If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia for any additional information.

2

© 2016 Nokia

DN0986461 Issue: 01R


Table of Contents This document has 326 pages

1

Summary of changes................................................................... 25

2

RL30 Features - not supported by Flexi Zone Micro....................26

3 3.1 3.2 3.3 3.4

Introduction to RL30 features.......................................................27 Introduction.................................................................................. 27 RL30 Transport and transmission features.................................. 27 RL30 Operability features............................................................ 27 Reference documentation............................................................ 28

4

Descriptions of radio resource management and telecom features. 30 LTE42:Support of DRX in RRC connected mode.........................30 Benefits........................................................................................ 30 Requirements...............................................................................30 Functional description.................................................................. 30 Feature scope.............................................................................. 30 Basic characteristics and limitations............................................ 31 Detailed description......................................................................31 User scenarios............................................................................. 32 System impact..............................................................................32 LTE42:Support of DRX in RRC connected mode management data.............................................................................................. 33 Sales information......................................................................... 34 LTE56: Inter RAT Handover to WCDMA...................................... 35 Benefits........................................................................................ 35 Requirements...............................................................................35 Functional description.................................................................. 35 Enhanced Handover Mode and Target selection ........................ 36 Handover from LTE to WCDMA................................................... 37 Measurement............................................................................... 37 Measurement Coordination .........................................................38 Measurement Configuration for Handover to WCDMA................ 38 Measured Results Including Handover to WCDMA Requirements.. 38 Connection Mobility Control: Handover (CMC-HO)..................... 39 Capacity, performance and overload control................................40 Configuration Management..........................................................40 Inter RAT handover to WCDMA................................................... 40 Activation of the feature............................................................... 41 System impact..............................................................................41 LTE56: Inter RAT Handover to WCDMA management data........ 41 Sales information......................................................................... 46

4.1 4.1.1 4.1.2 4.1.3 4.1.3.1 4.1.3.2 4.1.3.3 4.1.3.4 4.1.4 4.1.5 4.1.6 4.2 4.2.1 4.2.2 4.2.3 4.2.3.1 4.2.3.2 4.2.3.3 4.2.3.3.1 4.2.3.3.2 4.2.3.3.3 4.2.3.4 4.2.3.5 4.2.3.6 4.2.3.6.1 4.2.3.6.2 4.2.4 4.2.5 4.2.6


© 2016 Nokia

3


4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.6 4.6.1 4.6.2 4.6.3 4.6.3.1 4.6.3.1.1 4.6.3.1.2 4.6.3.1.3 4.6.3.2 4.6.3.3 4.6.3.3.1 4.6.3.4 4.6.3.5 4.6.3.5.1 4.6.3.5.2 4.6.4 4.6.5 4.6.6 4.7 4.7.1 4.7.1.1

4

LTE68: Support of Cell Based Location Service.......................... 46 Benefits........................................................................................ 46 Requirements...............................................................................47 Functional description.................................................................. 47 System impact..............................................................................51 LTE68: Support of Cell Based Location Service Management Data ..................................................................................................... 52 Sales information......................................................................... 53 LTE426: System Time Broadcast for SIB8...................................53 Benefits........................................................................................ 53 Requirements...............................................................................53 Functional description.................................................................. 54 System impact..............................................................................54 LTE426: System Time Broadcast for SIB8 management data.....55 Sales information......................................................................... 55 LTE430: DL power boosting for control channels........................ 55 Benefits........................................................................................ 55 Requirements...............................................................................56 Functional description.................................................................. 56 System impact..............................................................................57 LTE430: DL power boosting for control channels management data.............................................................................................. 58 Sales information......................................................................... 59 LTE442: Network Assisted Cell Change to GSM......................... 59 Benefits........................................................................................ 59 Requirements...............................................................................59 Functional description.................................................................. 59 eNACC to GSM............................................................................ 60 eNACC Phases............................................................................ 60 Enhanced Handover / eNACC Mode and Target selection ......... 61 GSM Measurement Configuration and Reporting Requirements..... 62 Connection Mobility Control: Handover (CMC-HO)..................... 62 Capacity, performance and overload control................................64 eNACC to GSM Performance...................................................... 64 Configuration Management for eNACC....................................... 64 User scenarios............................................................................. 65 Activation of eNACC to GSM....................................................... 65 UE leaves limited LTE Coverage Area......................................... 65 System impact..............................................................................66 LTE442: Network Assisted Cell Change to GSM management data.............................................................................................. 67 Sales information......................................................................... 69 LTE450: MME Capacity Value Change........................................ 69 LTE450: MME capacity value change.......................................... 69 Benefits........................................................................................ 70

© 2016 Nokia



4.7.1.2 4.7.1.3 4.7.1.4 4.7.1.5 4.7.2 4.8 4.8.1 4.8.2 4.8.3 4.8.3.1 4.8.3.2 4.8.3.3 4.8.4 4.8.5 4.8.6 4.9 4.9.1 4.9.2 4.9.3 4.9.3.1 4.9.3.2 4.9.3.3 4.9.3.4 4.9.3.4.1 4.9.3.4.2 4.9.3.4.3 4.9.3.5 4.9.3.5.1 4.9.3.5.2 4.9.3.5.3 4.9.4 4.9.5 4.9.6 4.10 4.10.1 4.10.2 4.10.3 4.10.4 4.10.5 4.10.6 4.11 4.11.1 4.11.2 4.11.3 4.11.4 4.11.5


Requirements...............................................................................70 Functional description.................................................................. 70 System impact..............................................................................72 Sales information......................................................................... 73 LTE450: MME capacity value change management data............ 73 LTE473: Extended DRX settings..................................................73 Benefits........................................................................................ 74 Requirements...............................................................................74 Functional description.................................................................. 74 Feature scope.............................................................................. 74 Basic characteristics and limitations............................................ 74 User scenarios............................................................................. 76 System impact..............................................................................76 LTE473: Extended DRX settings management data....................76 Sales information......................................................................... 78 LTE490: Subscriber profile based mobility .................................. 78 Benefits........................................................................................ 79 Requirements...............................................................................79 Functional description.................................................................. 79 Handling of LTE490 reconfiguration............................................. 80 Licensing of SPID Selective Neighbor Cell lists........................... 80 Impact on measurement configuration.........................................80 Mobility Profiles............................................................................ 81 Management of Mobility Profiles.................................................. 81 Mobility Profile Information...........................................................81 Default Mobility Profile Information.............................................. 82 User scenarios............................................................................. 82 Acivation / Deactivation Subscriber profile based mobility...........83 Configuration of Mobility Profiles information...............................83 Creation and assignment of new Mobility Profile......................... 83 System impact..............................................................................84 LTE490: Subscriber profile based mobility management data..... 85 Sales information......................................................................... 89 LTE518: Operator Specific QCI....................................................89 Benefits........................................................................................ 89 Requirements...............................................................................89 Functional description.................................................................. 90 System impact..............................................................................90 LTE518: Operator Specific QCI management data......................91 Sales information......................................................................... 93 LTE522: S1 Partial Reset............................................................. 93 Benefits........................................................................................ 93 Requirements...............................................................................94 Functional description.................................................................. 94 System impact..............................................................................96 LTE522: S1 Partial Reset management data............................... 97

© 2016 Nokia

5


4.11.6 4.12 4.12.1 4.12.2 4.12.3 4.12.4 4.12.5 4.12.6 4.13 4.13.1 4.13.2 4.13.3 4.13.4 4.13.5 4.13.6 4.14 4.14.1 4.14.2 4.14.3 4.14.4 4.14.5 4.14.6 4.15 4.15.1 4.15.2 4.15.3 4.15.3.1 4.15.4 4.15.5 4.15.6 4.16 4.16.1 4.16.2 4.16.3 4.16.3.1 4.16.3.2 4.16.4 4.16.5 4.16.6 4.17 4.17.1 4.17.2 4.17.3

6

Sales information......................................................................... 97 LTE570: Periodic UE measurements........................................... 97 Benefits........................................................................................ 97 Requirements...............................................................................98 Functional description.................................................................. 98 System impact..............................................................................98 LTE570: Periodic UE measurements management data............. 99 Sales information......................................................................... 99 LTE571: Controlled uplink packet segmentation........................ 100 Benefits...................................................................................... 100 Requirements.............................................................................100 Functional description................................................................ 100 System impact............................................................................101 LTE571: Controlled uplink packet segmentation management data ................................................................................................... 101 Sales information....................................................................... 102 LTE572: IMS Emergency Sessions............................................102 Benefits...................................................................................... 103 Requirements.............................................................................103 Functional description................................................................ 103 System impact............................................................................108 LTE572: IMS Emergency Session management data............... 108 Sales information........................................................................110 LTE616: Usage based PDCCH adaptation................................ 110 Benefits.......................................................................................111 Requirements............................................................................. 111 Functional description.................................................................111 Related parameters.................................................................... 111 System impact............................................................................ 112 LTE616: Usage based PDCCH adaptation management data........ 112 Sales information........................................................................113 LTE619: Interference aware UL scheduling............................... 113 Benefits.......................................................................................114 Requirements............................................................................. 114 Functional description.................................................................114 Feature overview........................................................................ 114 Detailed description.................................................................... 115 System impact............................................................................ 115 LTE619: Interference aware UL scheduling management data....... 116 Sales information........................................................................116 LTE735: RRC Connection Re-establishment............................. 116 Benefits.......................................................................................117 Requirements............................................................................. 117 Functional description.................................................................117

© 2016 Nokia



4.17.3.1 4.17.3.2 4.17.3.3 4.17.3.4 4.17.3.5 4.17.3.5.1 4.17.3.5.2 4.17.3.5.3 4.17.3.5.4 4.17.3.5.5 4.17.3.5.6 4.17.3.6 4.17.3.6.1 4.17.3.6.2 4.17.3.6.3 4.17.3.6.4 4.17.3.6.5 4.17.3.6.6 4.17.3.6.7 4.17.3.6.8 4.17.3.7 4.17.3.8 4.17.3.9 4.17.3.9.1 4.17.3.9.2 4.17.3.9.3 4.17.3.9.4 4.17.3.9.5 4.17.3.9.6 4.17.3.9.7


RRC Connection Re-establishment............................................118 RRC connection Re-establishment procedure........................... 119 Support of RRC Connection Reconfiguration Procedure for Reestablishment in Serving Cell.....................................................121 RRC Connection Re-establishment procedure successful case...... 121 PDCP......................................................................................... 121 eNB supports PDCP data transmission suspension.................. 121 eNB supports PDCP data transmission resumption.................. 121 eNB supports PDCP entity Re-establishment............................121 eNB supports PDCP Re-establishment procedure.................... 122 MAC reconfiguration, MAC reset, and MAC error handling of unknown, unforeseen and erroneous protocol data...................122 MAC Reconfiguration for RRC Connection Re-establishment...122 Access Stratum Security............................................................ 122 Support of key refresh at RRC connection Re-establishment to serving/source or target cell....................................................... 122 Security handling of RRC connection Re-establishment........... 122 Connection Re-establishment of a related UE........................... 124 Authentication check for RRC CONNECTION Re-establishment REQUEST message in case of Null integrity protection............ 124 Key refresh at RRC connection Re-establishment to serving/source or target cell....................................................... 124 Parameters of RRC CONNECTION Re-establishment message.... 125 RRC connection Re-establishment reject due to keystream reusage...................................................................................... 125 Intra-cell AS security maintenance by key refresh for RRC connection Re-establishment.....................................................126 Support of RRC Connection Re-establishment during intra-eNB handover in the source cell........................................................ 126 RRC Connection Re-establishment procedure successful case including mobility........................................................................126 Support of RRC Connection Reconfiguration Procedure for Reestablishment at handover......................................................... 126 Measurement Configuration at Re-establishment in "target cell"..... 126 Radio Bearer Reconfiguration at re-establishment in target cell with "target cell - source config"................................................. 126 Building of RRCConnectionReconfiguration for re-establishment in target cell with "target cell - Source Config"............................... 127 Building of RadioResourceConfigDedicated IE for reestablishment in target cell with "target cell - Source Config".... 127 Improved Failure Handling for RRC Connection Reconfiguration Procedure...................................................................................127 Interaction of UE Capability Transfer Procedure with RRC Connection Re-establishment.................................................... 127 Reception of RRCConnectionReestablishmentRequest message during RRC Connection Reconfiguration................................... 128

© 2016 Nokia

7


4.17.3.9.8 4.17.3.9.9

4.17.3.9.10

4.17.3.9.11

4.17.3.9.12

4.17.3.9.13

4.17.3.9.14

4.17.3.9.15

4.17.3.9.16

4.17.3.10 4.17.3.10.1 4.17.3.10.2 4.17.3.10.3 4.17.3.10.4 4.17.3.10.5 4.17.3.10.6 4.17.3.10.7 4.17.3.10.8

4.17.3.10.9

4.17.3.10.10

8

Supervision of RRC Connection Reconfiguration procedure for L1 reconfiguration........................................................................... 128 Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Setup... 128 Building of RRC: ConnectionReconfiguration for Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Setup..............................................................................128 Building of RadioResourceConfigDedicated IE for Reestablishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Setup.............................................. 128 Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Release...................................................................................... 128 Building of RRCConnectionReconfiguration for Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Release.......................................................................... 129 Building of RadioResourceConfigDedicated IE for Reestablishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Release...........................................129 Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for L1 Reconfiguration.......................................................................... 129 Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for Measurement Reconfiguration.......................................................................... 130 Support of RRC Connection Re-establishment during intra-eNB handover in the target cell..........................................................130 Receiving RRC CONNECTION Re-establishment REQUEST message during intra-eNB handover at the target cell...............130 Successful RRC Re-establishment at the target cell during intraeNB handover............................................................................ 130 RRC: RE-ESTABLISHMENT REJECTION at target cell during Intra-eNB handover....................................................................131 Support of RRC: CONNECTION RE-ESTABLISHMENT during inter-eNB handover via X2 in the target cell...............................131 Receiving RRC: CONNECTION RE-ESTABLISHMENT REQUEST message at the Target eNB during X2-handover.....131 Successful RRC: RE-ESTABLISHMENT at the target eNB during X2_HO....................................................................................... 131 RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT by Target eNB for a UE performing an X2 handover...................... 132 Stop guarding timer TRELOCreestablish due to RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT by Target eNB..... 132 RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT byTarget eNB for a UE performing Measurement Configuration...... 132 Stop guarding timer for RRC Connection Reconfiguration procedure due to RRC: RRC CONNECTION REESTABLISHMENT REJECT byTarget eNB................................132

© 2016 Nokia



4.17.3.10.11 4.17.3.10.12 4.17.3.10.13 4.17.3.10.14 4.17.3.11 4.17.3.12 4.17.3.12.1 4.17.3.12.2 4.17.3.12.3 4.17.3.12.4

4.17.4 4.17.5 4.17.6 4.18 4.18.1 4.18.1.1 4.18.1.2 4.18.1.3 4.18.1.4 4.18.1.5 4.18.1.6 4.19 4.19.1 4.19.2 4.19.3 4.19.3.1 4.19.3.2 4.19.4 4.19.5 4.19.6 4.20 4.20.1 4.20.2 4.20.3 4.20.3.1 4.20.3.2


Support of RRC Connection Re-establishment during inter-eNB handover via S1 in the target cell...............................................132 Receiving RRC: CONNECTION RE-ESTABLISHMENT REQUEST message at the target eNB during S1-handover..... 132 Successful RRC Re-establishment at the target eNB during S1_HO....................................................................................... 133 RRC Re-establishment rejection at the target eNB during S1handover.................................................................................... 133 Signaling in RRC_CONNECTED Requirements........................133 RRC Connection Re-establishment procedure successful case including interaction with S1AP procedures...............................133 RLF detection interacting with starting or ongoing S1AP requests.. 134 RRC: CONNECTION RE-ESTABLISHMENT procedure successful case in target cell with "target cell - Source Config". 134 Sending RRC: RRC CONNECTION RE-ESTABLISHMENT message in target cell with "target cell - Source Config"............134 Building of RadioResourceConfigDedicated IE at RRC: CONNECTION RE-ESTABLISHMENT at target cell with "Target cell - Source config"................................................................... 134 System impact............................................................................134 LTE735: RRC Connection Re-establishment management data..... 135 Sales information....................................................................... 136 ................................................................................................... 136 LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT............. 136 Benefits...................................................................................... 136 Requirements.............................................................................137 Functional description................................................................ 137 System impact............................................................................137 LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT management data...................................................................... 138 Sales information....................................................................... 139 LTE829: Increased Uplink MCS Range......................................140 Benefits...................................................................................... 140 Requirements.............................................................................140 Functional description................................................................ 140 User scenarios........................................................................... 141 Feature limitations......................................................................141 System impact............................................................................141 LTE829: Increased Uplink MCS Range management data....... 141 Sales information....................................................................... 145 LTE971: Intra-LTE mobility offsets............................................. 145 Benefits...................................................................................... 145 Requirements.............................................................................145 Functional description................................................................ 146 Functional overview................................................................... 146 Connection Mobility Control: Handover (CMC-HO)................... 146

© 2016 Nokia

9


4.20.3.2.1

4.22.6

Support of Intra-Frequency cell individual offsets (CIO cell list) and Intra-Frequency specific offsets ................................................ 146 Support of Inter-Frequency cell individual offsets (CIO cell lists) and Inter-Frequency specific offsets ......................................... 147 System impact............................................................................147 LTE971: Intra-LTE mobility offsets management data............... 147 Sales information....................................................................... 148 LTE1034: Extended Uplink Link Adaptation............................... 148 Benefits...................................................................................... 148 Requirements.............................................................................148 Functional description................................................................ 149 System impact............................................................................150 LTE1034: Extended Uplink Link Adaptation management data. 151 Sales information....................................................................... 151 LTE1035:Outer Loop Link Adaptation for PDCCH..................... 152 Benefits...................................................................................... 152 Requirements.............................................................................152 Functional description................................................................ 152 System impact............................................................................153 LTE1035:Outer Loop Link Adaptation for PDCCH management data ........................................................................................... 154 Sales information....................................................................... 155

5 5.1 5.1.1 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.3.1 5.1.1.3.2 5.1.1.4 5.1.1.5 5.1.1.6 5.2 5.2.1 5.2.2 5.2.3 5.2.3.1 5.2.3.2 5.2.3.3 5.2.4 5.2.5

Descriptions of transport and transmission features.................. 156 LTE144: Transport Admission Control ...................................... 156 LTE144: Transport Admission Control....................................... 156 Benefits...................................................................................... 156 Requirements.............................................................................156 Functional description................................................................ 157 User scenarios........................................................................... 157 Feature limitations......................................................................158 System impact............................................................................158 LTE144: Transport Admission Control management data......... 159 Sales information....................................................................... 160 LTE574: IP Transport Network Measurements.......................... 160 Benefits...................................................................................... 161 Requirements.............................................................................161 Functional description................................................................ 161 Measured values........................................................................163 User scenarios........................................................................... 164 Feature limitations......................................................................165 System impact............................................................................165 LTE574: IP Transport Network Measurements management data.. 166 Sales information....................................................................... 168 LTE866: Fast IP Rerouting......................................................... 168 Benefits...................................................................................... 168

4.20.3.2.2 4.20.4 4.20.5 4.20.6 4.21 4.21.1 4.21.2 4.21.3 4.21.4 4.21.5 4.21.6 4.22 4.22.1 4.22.2 4.22.3 4.22.4 4.22.5

5.2.6 5.3 5.3.1

10

© 2016 Nokia



5.3.2 5.3.3 5.3.3.1 5.3.3.2 5.3.3.3 5.3.3.4 5.3.3.5 5.3.3.6 5.3.3.7 5.3.4 5.3.5 5.3.6 5.4 5.4.1 5.4.2 5.4.3 5.4.3.1 5.4.3.2 5.4.3.3 5.4.4 5.4.5 5.4.6

Requirements.............................................................................168 Functional description................................................................ 169 Network access scenarios......................................................... 169 Recommended router configuration...........................................170 The eNB static route selection................................................... 171 Supervision of the Alternative Path............................................ 172 PR and AR router failures.......................................................... 172 Switchover time..........................................................................173 eNB VLAN/E-LAN configuration.................................................173 System impact............................................................................174 LTE866: Fast IP Rerouting management data........................... 174 Sales information....................................................................... 176 LTE931: Ethernet Jumbo Frames.............................................. 176 Benefits...................................................................................... 176 Requirements.............................................................................177 Functional description................................................................ 177 C-plane and M-plane transport IP packet fragmentation........... 178 Jumbo Frame switching............................................................. 178 Feature limitations......................................................................178 System impact............................................................................179 LTE931: Ethernet Jumbo Frames management data................ 179 Sales information....................................................................... 180

6 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5

Descriptions of operability features............................................ 181 LTE424: Automatic interface alarm correlation.......................... 181 Benefits...................................................................................... 181 Requirements.............................................................................181 Functional description................................................................ 181 System impact............................................................................184 LTE424: Automatic interface alarm correlation management data.. 184 Sales information....................................................................... 185 LTE459: LTE Timing Advance Evaluation.................................. 185 Benefits...................................................................................... 185 Requirements.............................................................................185 Functional description................................................................ 186 System impact............................................................................187 LTE459: LTE Timing Advance Evaluation management data.... 188 Sales information....................................................................... 188 LTE482: DNS Support for Certificate Examination.....................188 Benefits...................................................................................... 189 Requirements.............................................................................189 Functional description................................................................ 189 System impact............................................................................191 LTE482: DNS Support for Certificate Examination management data............................................................................................ 191

6.1.6 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5


© 2016 Nokia

11


6.3.6 6.4 6.4.1 6.4.2 6.4.3 6.4.3.1 6.4.3.2 6.4.3.3 6.4.4 6.4.5 6.4.6 6.4.7 6.5 6.5.1 6.5.2 6.5.3 6.5.3.1 6.5.3.2 6.5.3.2.1 6.5.3.2.2 6.5.3.2.3 6.5.3.2.4 6.5.3.2.5 6.5.3.3 6.5.3.4 6.5.4 6.5.5 6.5.6 6.5.7 6.6 6.6.1 6.6.2 6.6.3 6.6.3.1 6.6.3.2 6.6.3.2.1 6.6.3.2.2 6.6.3.2.3

6.6.4 6.6.5 6.6.6 6.6.7

12

Sales information....................................................................... 192 LTE510: Synchronization of InterRAT Neighbors.......................192 Benefits...................................................................................... 192 Requirements.............................................................................193 Functional description................................................................ 193 Functional overview................................................................... 193 Interactive management of eNBs...............................................194 Scheduled neighborship reconfiguration....................................195 System impact............................................................................197 Management data...................................................................... 198 Sales information....................................................................... 198 Abbreviations............................................................................. 198 LTE533: Mobility Robustness.....................................................198 Benefits...................................................................................... 199 Requirements.............................................................................199 Functional description................................................................ 199 LTE1222: Inter-Rat Auto Setup and Scheduled Optimization.... 201 Use cases.................................................................................. 202 Late HO counting....................................................................... 202 Type 2 early HO counting...........................................................203 LTE533 counters reading and visualization............................... 204 HO problems detection based on LTE533 counters reading..... 204 HO problems handling via parameter adjustment......................204 Use case: LTE533 MRO LTE1768 MRO Ping Pong.................. 204 Licensing.................................................................................... 205 System impact............................................................................205 LTE533: Mobility Robustness management data.......................207 Sales information....................................................................... 209 Abbreviations............................................................................. 209 Description of LTE581: PRACH management........................... 210 Benefits...................................................................................... 210 Requirements............................................................................. 211 Functional description.................................................................211 RAN system level scope............................................................ 212 User scenarios........................................................................... 213 eNB configuration without any surrounding eNB within PRACH reuse distance............................................................................213 eNB configuration with neighbor eNB within PRACH reuse distance......................................................................................214 eNB configuration with/without surrounding eNB within PRACH reuse distance and with surrounding eNB's of another PLMN within PRACH reuse distance.................................................... 217 System impact............................................................................218 LTE581: PRACH Management Data..........................................219 Sales information....................................................................... 220 Abbreviations............................................................................. 220

© 2016 Nokia



6.7 6.7.1 6.7.2 6.7.3 6.7.4 6.7.5 6.7.6 6.8 6.8.1 6.8.2 6.8.3 6.8.4 6.8.5 6.8.6 6.9 6.9.1 6.9.2 6.9.3 6.9.3.1 6.9.3.2 6.9.3.3 6.9.3.4 6.9.3.5 6.9.3.6 6.9.3.7 6.9.3.8 6.9.4 6.9.5 6.9.6 6.9.7 6.10 6.10.1 6.10.2 6.10.3 6.10.3.1 6.10.3.2 6.10.3.3 6.10.3.4 6.10.3.5 6.10.3.6 6.10.3.7 6.10.3.8 6.10.3.9 6.10.4


LTE602: Performance Management Administration...................220 Benefits...................................................................................... 221 Requirements.............................................................................221 Functional description................................................................ 221 System impact............................................................................222 LTE602: Performance Management Administration management data............................................................................................ 222 Sales information....................................................................... 224 LTE644: Configurable cell trace content.................................... 224 Benefits...................................................................................... 225 Requirements.............................................................................225 Functional description................................................................ 225 System impact............................................................................234 LTE644: Configurable cell trace content management data...... 234 Sales information....................................................................... 236 LTE771: Optimization of Intra-LTE Neighbor Relations..............236 Benefits...................................................................................... 236 Requirements.............................................................................237 Functional description................................................................ 237 RAN system level scope............................................................ 239 Scheduled LTE771 execution.................................................... 240 Use case scheduled workflow for LTE771................................. 241 Use case manual triggered workflow for LTE771.......................241 Use Case for the operator to manually clear the blacklist..........242 SON modus................................................................................242 Reporting....................................................................................243 Operator interaction outside of LTE771......................................243 System impact............................................................................244 LTE771:Optimization of neighbor relations management data.. 246 Sales information....................................................................... 247 Abbreviations............................................................................. 247 LTE782: ANR Fully UE Based....................................................247 Benefits...................................................................................... 248 Requirements.............................................................................248 Functional description................................................................ 249 Use case: UE-based ANR retrieval by eNB............................... 254 Use case: UE-based ANR at domain border............................. 255 LTE NB cell information..............................................................256 SON information exchange via S1............................................. 256 PCIs Blacklisted for Intra-LTE ANR............................................256 X2 link blacklisting......................................................................257 Neighbor information management............................................257 X2 link management.................................................................. 258 Feature activation and interaction with the existing LTE492: ANR feature........................................................................................ 260 System impact............................................................................260

© 2016 Nokia

13


6.10.5 6.10.6 6.11 6.11.1 6.11.2 6.11.3 6.11.3.1 6.11.3.2 6.11.3.3

6.13.6

LTE782: ANR Fully UE Based management data......................262 Sales information....................................................................... 267 LTE783: ANR InterRAT UTRAN.................................................267 Benefits...................................................................................... 267 Requirements.............................................................................268 Functional description................................................................ 268 The establishment of NR for InterRAT UTRAN.......................... 270 Maintenance of existing neighborship relations......................... 271 New UTRAN neighborship generation during LTE autoconfiguration...............................................................................271 System impact............................................................................272 LTE783: ANR InterRAT UTRAN management data...................273 Sales information....................................................................... 278 LTE784: ANR InterRAT GERAN................................................ 278 Benefits...................................................................................... 279 Requirements.............................................................................279 Functional description................................................................ 279 Network policy............................................................................281 Establishment of NR for Inter-RAT GERAN............................... 282 LTE784: Neighborship Relation Maintenance............................ 282 New GERAN neighbor ship generation during LTE autoconfiguration...............................................................................283 System impact............................................................................283 LTE784: ANR InterRAT GERAN management data.................. 285 Sales information....................................................................... 289 Abbreviations............................................................................. 289 LTE882: System Upgrade with Backward Compatibility............ 290 Benefits...................................................................................... 290 Requirements.............................................................................290 Functional description................................................................ 290 System impact............................................................................293 LTE882: System Upgrade with Backward Compatibility management data...................................................................... 294 Sales information....................................................................... 294

7 7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.2 7.2.1 7.2.2 7.2.3

Descriptions of BTS site solution features................................. 295 LTE74: Flexi System Module FSMD.......................................... 295 Benefits...................................................................................... 295 Requirements.............................................................................295 Functional description................................................................ 295 System impacts..........................................................................296 LTE74: Flexi System Module FSMD management data............ 296 Sales information....................................................................... 296 LTE89: Flexi RRH 2TX 2600...................................................... 297 Benefits...................................................................................... 297 Requirements.............................................................................297 Functional description................................................................ 298

6.11.4 6.11.5 6.11.6 6.12 6.12.1 6.12.2 6.12.3 6.12.3.1 6.12.3.2 6.12.3.3 6.12.3.4 6.12.4 6.12.5 6.12.6 6.12.7 6.13 6.13.1 6.13.2 6.13.3 6.13.4 6.13.5

14

© 2016 Nokia



7.2.4 7.2.5 7.2.6 7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.5 7.5.1 7.5.2 7.5.3 7.5.4 7.5.5 7.5.6 7.6 7.6.1 7.6.2 7.6.3 7.6.4 7.6.5 7.6.6 7.7 7.7.1 7.7.2 7.7.3 7.7.4 7.7.5 7.7.6 7.8 7.8.1 7.8.2 7.8.3 7.8.4 7.8.5 7.8.6


System impacts..........................................................................299 LTE89: Flexi RRH 2TX 2600 management data........................ 300 Sales information....................................................................... 300 LTE91: Flexi RRH 2TX 850........................................................ 300 Benefits...................................................................................... 300 Requirements.............................................................................301 Functional description................................................................ 301 System impacts..........................................................................303 LTE91: Flexi RRH 2TX 850 management data.......................... 303 Sales information....................................................................... 303 LTE106: 6 Cells support with one System Module.....................304 Benefits...................................................................................... 304 Requirements.............................................................................304 Functional description................................................................ 304 System impacts..........................................................................304 LTE106: 6 Cells support with one System Module management data............................................................................................ 305 Sales information....................................................................... 305 LTE452: Flexi RRH 2TX 2100.................................................... 305 Benefits...................................................................................... 305 Requirements.............................................................................306 Functional description................................................................ 306 System impacts..........................................................................308 LTE452: Flexi RRH 2TX 2100 management data...................... 308 Sales information....................................................................... 308 LTE614: Distributed Site.............................................................308 Benefits...................................................................................... 309 Requirements.............................................................................309 Functional description................................................................ 309 System impacts..........................................................................310 LTE614: Distributed Site management data.............................. 310 Sales information....................................................................... 310 LTE921: Flexi 3-sector RF Module 760...................................... 311 Benefits.......................................................................................311 Requirements............................................................................. 311 Functional description................................................................ 312 System impacts..........................................................................312 LTE921: Flexi 3-sector RF Module 760 management data........312 Sales information....................................................................... 313 LTE977: RF Chaining................................................................. 313 Benefits...................................................................................... 313 Requirements.............................................................................313 Functional description................................................................ 314 System impacts..........................................................................314 LTE977: RF Chaining management data................................... 315 Sales information....................................................................... 315

© 2016 Nokia

15


7.9 7.9.1 7.9.2 7.9.3 7.9.4 7.9.5 7.9.6 7.10 7.10.1 7.10.2 7.10.3 7.10.4 7.10.5 7.10.6 7.11 7.11.1 7.11.2 7.11.3 7.11.4 7.11.5 7.11.6 7.12 7.12.1 7.12.2 7.12.3 7.12.4 7.12.5 7.12.6 7.13 7.13.1 7.13.2 7.13.3 7.13.4 7.13.5 7.13.6

16

LTE1101: FFCB TRS External Filter for FHCA ......................... 315 Benefits...................................................................................... 315 Requirements.............................................................................315 Functional description................................................................ 316 System impacts..........................................................................316 LTE1101: FFCB TRS External Filter for FHCA management data.. 317 Sales information....................................................................... 317 LTE1106: Flexi low power RRH 850 2TX for optical repeater interface..................................................................................... 317 Benefits...................................................................................... 317 Requirements.............................................................................318 Functional description................................................................ 318 System impacts..........................................................................319 LTE1106: Flexi low power RRH 850 2TX for optical repeater interface management data....................................................... 319 Sales information....................................................................... 319 LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU)..........320 Benefits...................................................................................... 320 Requirements.............................................................................320 Functional description................................................................ 320 System impacts..........................................................................321 LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU) management data...................................................................... 321 Sales information....................................................................... 322 LTE1337: FHEC Flexi RRH 2TX 1800 low power...................... 322 Benefits...................................................................................... 322 Requirements.............................................................................322 Functional description................................................................ 323 System impacts..........................................................................323 LTE1337: FHEC Flexi RRH 2TX 1800 low power management data............................................................................................ 323 Sales information....................................................................... 324 LTE1356: Flexi RF Module 2TX 850 (FXCC)............................. 324 Benefits...................................................................................... 324 Requirements.............................................................................325 Functional description................................................................ 325 System impacts..........................................................................325 LTE1356: Flexi RF Module 2TX 850 (FXCC) management data..... 325 Sales information....................................................................... 326

© 2016 Nokia



List of Figures Figure 1

Direct location reporting......................................................................48

Figure 2

Location reporting upon cell change due to inter-eNB hand over...... 48

Figure 3

Location reporting upon cell change due to X2 handover.................. 49

Figure 4

Location reporting upon cell change due to S1 handover.................. 50

Figure 5

Stop location reporting........................................................................51

Figure 6

Location Report Failure Indication......................................................51

Figure 7

Time reference point in CDMA2000 timing.........................................54

Figure 8

Message Chart for MME changes...................................................... 71

Figure 9

Failure case........................................................................................ 72

Figure 10

S1 Partial reset triggered by eNB....................................................... 95

Figure 11

S1 Partial reset triggered by MME......................................................96

Figure 12

Attach in Limited Service State.........................................................104

Figure 13

EPS Bearer Establishment by S1AP: Initial Context Setup Procedure.. 106

Figure 14

EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls.............................................................................. 107

Figure 15

PRB allocation of the UEs................................................................ 115

Figure 16

PDSCH and PDCCH link adaptation................................................ 153

Figure 17

Packet formats..................................................................................162

Figure 18

RTT based on two timestamps......................................................... 163

Figure 19

RTT based on four timestamps........................................................ 164

Figure 20

User scenario 1................................................................................ 164

Figure 21

User scenario 2................................................................................ 165

Figure 22

User scenario 3................................................................................ 165

Figure 23

Single backhaul link..........................................................................169

Figure 24

Dual backhaul link............................................................................ 170

Figure 25

Rerouting example........................................................................... 170

Figure 26

Primary Path failure.......................................................................... 173

Figure 27

VLAN configuration example............................................................ 174

Figure 28

Overhead of IPsec protected IPv4 packet - the largest MTU case...176

Figure 29

Differences in MTU value throughout the network........................... 178

Figure 30

Alarm correlation example................................................................182

Figure 31

NetAct alarm correlator view............................................................ 183

Figure 32

New alarms for reporting interface faults..........................................183

Figure 33

Timing advance value collection signaling flow................................ 187

Figure 34

LTE510 Synchronization of InterRAT Neighbors.............................. 194

Figure 35

Mobility Robustness......................................................................... 201

Figure 36

Overview of PRACH management................................................... 212


© 2016 Nokia

17


18

Figure 37

eNB Configuration without any surrounding eNB within PRACH Reuse Distance............................................................................................214

Figure 38

eNB configuration with neighbor eNB within PRACH reuse distance.... 216

Figure 39

eNB configuration with neighbor eNB within PRACH reuse distance.... 218

Figure 40

Performance management administration object structure.............. 223

Figure 41

LTE771 Optimization of Intra-LTE neighbor relations....................... 239

Figure 42

ANR principle....................................................................................250

Figure 43

UE-based ANR Retrieval by eNB..................................................... 255

Figure 44

UE-based ANR at Domain Border....................................................256

Figure 45

LTE784: ANR InterRAT GERAN.......................................................280

Figure 46

Top down upgrade approach............................................................ 291

Figure 47

Isometric view of FRHB Remote Radio Head 2600......................... 298

Figure 48

Interfaces of FRHB Remote Radio Head 2600................................ 299

Figure 49

Isometric view of the FHCA.............................................................. 302

Figure 50

Isometric view of the Remote Radio Head (FRGQ)......................... 307

Figure 51

Front view of the FFCB.....................................................................316

© 2016 Nokia



List of Tables Table 1

RL30 Features - not supported by Flexi Zone Micro.......................... 26

Table 2

Transport and transmission features and related documents.............27

Table 3

RL30 Radio Resource Management and Telecom features and related documents.......................................................................................... 28

Table 4

Software requirements....................................................................... 30

Table 5

New counters......................................................................................33

Table 6

New parameters................................................................................. 33

Table 7

Modified parameters...........................................................................34

Table 8

Sales information................................................................................34

Table 9

Software requirements for FDD line................................................... 35

Table 10

Measurements....................................................................................39

Table 11

New counters......................................................................................42

Table 12

New parameters................................................................................. 43

Table 13

New parameters for the Target primary PLMN ID list......................... 45

Table 14

New parameters for the Target secondaryPlmnIdL list.......................45

Table 15

New parameters for the List Of Pointer to LNADJW Instance............45

Table 16

Related existing parameters...............................................................46

Table 17


Table 18


Table 19

New counters......................................................................................52

Table 20

New parameters................................................................................. 52

Table 21


Table 22


Table 23


Table 24

Modified alarms.................................................................................. 58

Table 25

New parameters................................................................................. 58

Table 26


Table 27


Table 28


Table 29

Measurements....................................................................................63

Table 30

New counters......................................................................................67

Table 31

New parameters................................................................................. 67

Table 32

New parameters for the “List of Pointer To LNADJG Instance”.......... 69

Table 33


Table 34


Table 35

Software requirements FD line........................................................... 70

Table 36

Software requirements TD line........................................................... 70

Table 37


Table 38

New alarms.........................................................................................73


© 2016 Nokia

19


20

Table 39


Table 40

New counters......................................................................................77

Table 41

New parameters................................................................................. 78

Table 42


Table 43


Table 44

New counters......................................................................................85

Table 45

New parameters................................................................................. 86

Table 46

New parameters for the “Mobility Profiles Mapping List”.................... 88

Table 47

New parameters for the “Reference frequency list network assisted cell change GERAN”.......................................................................... 88

Table 48


Table 49

Software requirements FDline............................................................ 90

Table 50

New Measurements............................................................................91

Table 51

New parameters................................................................................. 91

Table 52

Modified parameters...........................................................................93

Table 53


Table 54

Software requirements for different network elements....................... 94

Table 55


Table 56

New parameters................................................................................. 99

Table 57

Sales information..............................................................................100

Table 58

Software requirements..................................................................... 100

Table 59

New parameters............................................................................... 102

Table 60


Table 61


Table 62

New counters....................................................................................109

Table 63

New parameters............................................................................... 110

Table 64

Sales information.............................................................................. 110

Table 65

Software requirements...................................................................... 111

Table 66

New counters.................................................................................... 112

Table 67

New parameters............................................................................... 113

Table 68

Modified parameters......................................................................... 113

Table 69


Table 70

Software requirements......................................................................114

Table 71

New parameters............................................................................... 116

Table 72


Table 73

Software requirements for FDD line................................................. 117

Table 74

New counters....................................................................................135

Table 75


Table 76


Table 77

Parameters for LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT. 138

© 2016 Nokia



Table 78


Table 79


Table 80

Peak rate improvement.................................................................... 140

Table 81

New counters....................................................................................142

Table 82

New parameters............................................................................... 145

Table 83


Table 84

Software requirements for FDD line................................................. 145

Table 85

New parameters............................................................................... 148

Table 86


Table 87


Table 88

New parameters............................................................................... 151

Table 89


Table 90


Table 91

New counters....................................................................................154

Table 92

New parameters............................................................................... 154

Table 93

Related existing parameters.............................................................155

Table 94


Table 95


Table 96

New counters....................................................................................159

Table 97

New parameters............................................................................... 160

Table 98

Additional parameters for RL40........................................................160

Table 99


Table 100


Table 101

Related existing alarms.................................................................... 166

Table 102

New counters....................................................................................166

Table 103

New parameters............................................................................... 167

Table 104


Table 105


Table 106

BFD bound and regular static routes in the internal eNB router.......171

Table 107

Route selection.................................................................................172

Table 108

New parameters............................................................................... 175

Table 109


Table 110


Table 111

New parameters............................................................................... 180

Table 112


Table 113


Table 114

New alarms.......................................................................................184

Table 115


Table 116


Table 117

New parameters............................................................................... 188


© 2016 Nokia

21


22

Table 118


Table 119


Table 120

Modified alarms................................................................................ 191

Table 121

New parameters............................................................................... 192

Table 122


Table 123

Software requirements for RL40.......................................................193

Table 124


Table 125

Abbreviations....................................................................................198

Table 126

New counters....................................................................................207

Table 127

Related existing counters................................................................. 208

Table 128


Table 129

Abbreviations....................................................................................209

Table 130

Terms................................................................................................209

Table 131

Software requirements......................................................................211

Table 132

New parameters............................................................................... 219

Table 133


Table 134

Terms and abbreviations.................................................................. 220

Table 135


Table 136

New parameters............................................................................... 223

Table 137


Table 138


Table 139

S1AP messages traced in all trace types (Subscriber, Cell and Interface trace)................................................................................. 226

Table 140

S1AP messages traced only in case of Cell and Interface trace......228

Table 141

S1AP messages traced only in case of Interface trace.................... 228

Table 142

X2AP messages traced in all trace types (Subscriber, Cell and Interface trace)................................................................................. 230

Table 143

X2AP messages traced only in case of Cell and Interface trace......230

Table 144

X2AP messages traced only in case of Interface trace.................... 230

Table 145

RRC messages traced in all trace types (Subscriber, Cell and Interface trace)................................................................................. 231

Table 146

RRC messages traced in case of only Cell and Interface trace....... 233

Table 147

New parameters............................................................................... 234

Table 148


Table 149


Table 150

Software requirements for RL40.......................................................237

Table 151

New counters....................................................................................246

Table 152

New parameters............................................................................... 246

Table 153


Table 154

Abbreviations....................................................................................247

Table 155


© 2016 Nokia



Table 156

LTE782 Objects................................................................................ 258

Table 157

New alarms.......................................................................................263

Table 158

New counters....................................................................................263

Table 159

New parameters............................................................................... 264

Table 160

Modified parameters.........................................................................265

Table 161


Table 162


Table 163


Table 164

Modified parameters for MO LNBTS/LNCEL at NetAct....................274

Table 165

Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendor-defined-template “ANR inter RAT UTRAN”................275

Table 166

Modified parameters according to the network configuration at UTRAN network............................................................................................. 277

Table 167


Table 168


Table 169

Modified parameters for MO LNBTS/LNCEL at NetAct....................285

Table 170

Modified parameters for MO GFIM, GNFL, REDRT and LNHOG at NetAct set by vendor defined-template “ANR inter RAT GERAN”....286

Table 171

Modified parameters according to the network configuration at GERAN network............................................................................... 288

Table 172


Table 173

Abbreviations....................................................................................289

Table 174

Terms................................................................................................289

Table 175


Table 176

Related existing alarms.................................................................... 294

Table 177


Table 178


Table 179


Table 180


Table 181


Table 182


Table 183


Table 184


Table 185


Table 186


Table 187


Table 188


Table 189


Table 190


Table 191


Table 192



© 2016 Nokia

23


24

Table 193


Table 194


Table 195


Table 196


Table 197

Existing parameters related to LTE1106...........................................319

Table 198


Table 199


Table 200

Existing parameters related to LTE1195...........................................321

Table 201

New parameters introduced by LTE1195..........................................322

Table 202


Table 203


Table 204

Existing parameters related to LTE1337.......................................... 324

Table 205


Table 206


Table 207

Existing parameters related to LTE1356.......................................... 326

Table 208


© 2016 Nokia



Summary of changes

1 Summary of changes Changes between issue 01Q (2016-05-23, RL70) and 01R (2016-06-29, FDDLTE16A) The following feature descriptions have been updated: LTE42: Support of DRX in RRC connected mode LTE473: Extended DRX settings LTE782: ANR Fully UE Based Changes between issue 01P (2016-04-20, FDD-LTE15A) and 01Q (2016-05-23, RL70) The following feature description has been updated: LTE570: Periodic UE measurements Changes between issue 01O (2015-09-30, RL30) and 01P (2016-04-20, FDD-LTE15A) The following feature descriptions have been updated: LTE977: RF chaining


© 2016 Nokia

25

RL30 Features - not supported by Flexi Zone Micro


2 RL30 Features - not supported by Flexi Zone Micro The following features are not supported by Flexi Zone Micro: Table 1

RL30 Features - not supported by Flexi Zone Micro Features

26

Category

LTE74: FSMD Flexi System Module

BTS

LTE89: FRHB Flexi RRH 2TX 2600

BTS

LTE91: FHCA Flexi RRH 2TX 850

BTS

LTE452: FRGQ Flexi RRH 2TX 2100

BTS

LTE614: Distributed Site

BTS

LTE921: FRBB Flexi 3-sector RF Module 760

BTS

LTE977: RF chaining

BTS

LTE1101: FFCB TRS External Filter for FHCA

BTS

LTE1106: FHCB Flexi RRH 2TX 850 low power for optical repeater interface

BTS

LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU)

BTS

LTE1337: FHEC Flexi RRH 2TX 1800 low power

BTS

LTE1356: FXCC Flexi RF Module 2TX 850

BTS

© 2016 Nokia



Introduction to RL30 features

3 Introduction to RL30 features 3.1 Introduction This document provides the list of feature descriptions for the LTE Radio Access Network Release RL30. Hardware (HW) requirements indicate if the feature requires a specific HW in RAN LTE portfolio. If the feature has no specific hardware requirements, it means that only LTE System Module should be used. Please note that the subchapter Interdependencies between features lists only dependencies among Nokia RAN LTE features.

3.2 RL30 Transport and transmission features See the following table for more detailed information on LTE functions and feature activation: Table 2

Transport and transmission features and related documents

Feature

Other related descriptions

Related instructions

LTE144: Transport admission control

LTE Transport

This feature does not require the activation

LTE574: IP Transport Network Measurements

LTE Transport

Activating LTE574: IP Transport Network Measurements

LTE866: Fast IP Rerouting

LTE Transport

Activating LTE866: Fast IP Rerouting

LTE931: Ethernet Jumbo Frames

LTE Transport

This feature does not require the activation

LTE Datapath Management

3.3 RL30 Operability features See the following table for more detailed information on LTE functions and feature activation:


© 2016 Nokia

27


Table 3


RL30 Radio Resource Management and Telecom features and related documents

Feature

Other related descriptions

Related instructions

LTE424: Automatic interface alarm correlation

Fault Management

This feature does not require activation.

LTE459: LTE Timing Advance Evaluation

Tracing LTE RAN System


LTE482: DNS Support for Certificate Examinatio

LTE RAN O&M Security

Activating and deactivating LTE482: DNS Support for Certificate Examination using BTS Site Manager

LTE510: Synchronization of InterRAT Neighbors

Automated Neighbor Relation (ANR)


LTE533: Mobility Robustness

SON Management


LTE581: PRACH management

SON Management


LTE602: Performance Management Administration

Performance Management


LTE644: Configurable cell trace content Tracing LTE RAN System


LTE771:Optimization of neighbor relations



LTE782: ANR Fully UE based



LTE783: ANR InterRAT UTRAN



LTE784: ANR InterRAT GERAN



LTE882: System Upgrade with Backward Compatibility

This feature does not have any related documents.


3.4 Reference documentation For information on parameters, counters, key performance indicators, and alarms related to each feature, see the Management data section of the feature descriptions. For parameter descriptions, see: • •

Flexi Multiradio BTS LTE Commissioning and Transmission Parameters excel in NOLS LTE iOMS LDAP Parameters

For counter descriptions, see LTE Performance Measurements.

28

© 2016 Nokia




For key performance indicator descriptions, see: • •

LTE E2E Field Network Performance - Definitions of Key Performance Indicators Specifications of LTE RAN Key Performance Indicators

For alarm descriptions, see: • • •


Flexi Multiradio BTS LTE Alarms Flexi Multiradio Base Station LTE Faults LTE iOMS Alarms and Troubleshooting

© 2016 Nokia

29

Descriptions of radio resource management and telecom features


4 Descriptions of radio resource management and telecom features 4.1 LTE42:Support of DRX in RRC connected mode Introduction to the feature The Flexi Multiradio BTS supports DRX in status RRC-CONNECTED with long DRX cycles. The DRX functionality can considerably reduce the UE power consumption.

4.1.1 Benefits Enabling this feature results in longer battery life times.

4.1.2 Requirements Software requirements Table 4: Software requirements lists the software required for this feature. Table 4

Release

Software requirements

System Release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-

Hardware requirements This feature requires no new or additional hardware.

4.1.3 Functional description 4.1.3.1

Feature scope To maximize UE battery lifetime, LTE42 brings eNodeB support for discontinuous monitoring of the DL control channel (PDCCH) by the UE (DRX). This solution employs a periodic active/sleep pattern, thus creating phases where the UE is not able to receive or transmit data instantaneously. Instead, the UE must first send a scheduling request which starts a DRX Active phase. The possible power savings on UE side are determined by the discontinuous reception property, i.e., the possibility to switch off (parts of) the receiver when PDCCH does not need to be decoded. Maximum power savings are expected for a very bursty kind of traffic patterns (short phases with data followed by long phases with no data at all) and very long inactivity time, however, at the expense of increasing DL latency (at start of downlink data transmission).

30

© 2016 Nokia



4.1.3.2


Basic characteristics and limitations The feature introduces basic support of DRX, which supports only 3GPP-defined long DRX cycle. Up to three different DRX profiles can be defined by the operator: • • •

drxProfile1: “DRX off” drxProfile2: “VoIP optimized” drxProfile3: “non GBR”

One UE can use one DRX profile at one time. Each DRX profile (except "DRX off") comprises the following set of parameters: •

•

•

•

DRX Cycle Specifies the periodic repetition of the On Duration followed by a possible period of inactivity. The cycle provides a trade off between setup delay and UE battery power consumption. The maximum supported DRX cycle length is 80 ms. On Duration Timer Specifies the number of consecutive TTIs during which the UE shall monitor the PDCCH for possible allocations. The On Duration Timer is a part of a DRX Cycle. DRX Inactivity Timer Specifies the number of consecutive TTIs during which the UE shall monitor the PDCCH after successfully decoding a PDCCH indicating an initial UL or DL user data transmission for this UE. DRX Retransmission Timer Specifies the maximum number of consecutive PDCCH subframe(s) for as soon as a DL retransmission is expected by the UE.

The eNodeB has to activate the proper set of the parameters at the UE by configuring or reconfiguring depending on bearer combination and DRX to QCI profile mapping. Priority of DRX profiles determines profile to be applied for multiple bearers per UE. DRX is switched off when gap assisted measurements are activated.

4.1.3.3

Detailed description Determination of DRX usage for UE At Initial Context setup or incoming handover, the eNodeB determines whether DRX is used for the UE. DRX is used for the UE if all of the following conditions are met: • • •

DRX is enabled UE is capable of long DRX DRX is not disabled for Release 9 UEs that do not benefit from battery consumption optimization. DRX is disabled in this case if: –

–

The parameter drxApplyDeviceType is set to True (This parameter determines whether the device type noBenFromBatConsumpOpt of the UE is considered for DRX configuration. Such an UE does not foresee to particularly benefit from NW-based battery consumption optimization) The UE capabilities for E-UTRA contain the device type

noBenFromBatConsumpOpt Calculation of the current valid DRX profile


© 2016 Nokia

31



Each time, the current valid DRX profile needs to be calculated, the eNodeB: • •

•

Collects the drxProfileIndex of all QCIs that are contained in the current bearer combination (drxProfileIndex is a part of the qciTab) Selects the drxProfileIndex from this set that has the highest drxProfilePriority (the eNodeB compares the DRX profiles of the QCIs used for EPS bearers and selects the DRX profile with the highest priority; 50 is the highest priority and 0 is the lowest priority) Uses this selected drxProfileIndex for the DRX configuration

DRX profile can be associated with every QCI type in O&M interface. The selection of the profile to be applied for a QCI should be determined by the latency of the traffic being mapped to this QCI. For parameters details, see LTE42:Support of DRX in RRC connected mode management data chapter and Reference Documentation.

4.1.3.4

User scenarios The DRX is (re)configured when one of the listed triggers occurs: • • • •

Setup of data bearer, i.e. VoIP or non-GBR (from RRC Idle) Setup/Release of data bearer, i.e. VoIP or non-GBR (RRC Connected) Next intra-LTE handover (configuration of target cell applies) Release of inter-RAT/inter-frequency measurements

If in consequence different DRX parameters need to be applied, the UE is reconfigured correspondingly. At any such reconfiguration, also modified settings for the DRX related O&M parameters become effective for a UE. Feature activation/deactivation The operator can activate or deactivate Basic DRX support using a management tool. The feature can be activated or deactivated by setting the actDrx to True or False accordingly. If the feature is activated/deactivated, DRX configuration is taken into (out of) use for a single UE if one of the aforementioned triggers applies, i.e., not all UEs are reconfigured immediately.

4.1.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature affects system performance and capacity as follows:

32

© 2016 Nokia



•


Additional latencies are caused in DL direction once the UE is no longer in DRX Active as the UE will not listen to DL resource assignments until the next DRX Active phase.

4.1.5 LTE42:Support of DRX in RRC connected mode management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 5: New counters lists counters introduced with this feature. Table 5

New counters

Counter ID

Counter name

Measurement

M8021C18

Number of Handover attempts for UEs running in DRX mode

LTE Handover (WBTS)

M8021C19

Number of Handover completions for UEs running in DRX mode

LTE Handover (WBTS)

M8013C24

Subframes of DRX Active UE

LTE UE State (WBTS)

M8013C25

Subframes of DRX Sleep UE

LTE UE State (WBTS)

Key performance indicators There are no key performance indicators related to this feature. Parameters Table 6: New parameters lists parameters introduced with this feature. Table 6

New parameters

Full name

Abbreviated name

Managed object

Activate DRX

actDrx

LNCEL

DRX apply device type

drxApplyDeviceType

DRX

DRX profile index

drxProfileIndex

LNCEL

Structure

qciTab1, qciTab2, qciTab3, qciTab4,


© 2016 Nokia

33


Table 6


New parameters (Cont.)

Full name

Abbreviated name

Managed object

Structure qciTab5, qciTab6, qciTab7, qciTab8, qciTab9

DRX profile index

drxProfileIndex

DRX

drxProfile1, drxProfile2, drxProfile3

DRX Profile priority

drxProfilePriority

DRX

drxProfile1, drxProfile2, drxProfile3

DRX long cycle

drxLongCycle

DRX

drxProfile2, drxProfile3

DRX on duration timer

drxOnDuratT

DRX


DRX inactivity timer

drxInactivityT

DRX


DRX retransmission timer

drxRetransT

DRX


Table 7: Modified parameters lists parameters modified by this feature. Table 7

Modified parameters

Full name

Abbreviated name

Uplink improved latency reaction time

ilReacTimerUl

Managed object LNCEL

4.1.6 Sales information Table 8

34

Sales information

BSW/ASW

License control in network element

License control attributes

ASW

-

-

© 2016 Nokia




4.2 LTE56: Inter RAT Handover to WCDMA Introduction to the feature Coverage based inter-RAT Packet switched (PS) handover from LTE to WCDMA

4.2.1 Benefits Operator benefits Continuous PS coverage

4.2.2 Requirements Software requirements Table 9: Software requirements for FDD line lists the software required for this feature. Table 9

Release

Software requirements for FDD line

System Release

eNodeB

RL30

LBTS3.0

-

-

-

-


4.2.3 Functional description Functional overview The LTE to WCDMA handover functionality of the Flexi Multiradio BTS allows a service continuity of data services with minimal interruption time when changing from a LTE cell to a WCDMA cell. The functionality is only applicable to multimode devices supporting both LTE and WCDMA at the according frequency band and the according feature support. Handover trigger The handover is a network controlled handover with support of the UE. The following measurement events are used: • • •

A1 - deactivate IRAT measurements A2 - activate IRAT measurements B2 - IRAT measurements

The operator configurable measurement events A2 and A1 are used to start and stop IRAT measurements. The UE capabilities are considered for the IRAT measurements, for example to support measurement gap and support of frequency of target cells. The target cells for the IRAT measurements are operator configurable. Blacklisting of target cells is supported whereas blacklisting for measurements is not included


© 2016 Nokia

35



The event B2 is used for the IRAT measurements. The measurement configuration as source cell thresholds (RSRP), target cell thresholds (RSCP, EcN0), hysteresis, time to trigger and speed dependent scaling are operator configurable. Handover preparation The Flexi Multiradio BTS initiates a handover after receiving a measurement report from the UE by sending a S1AP:HANDOVER REQUIRED message to the MME. The Flexi Multimode BTS takes the first target cell indicated by the UE measurements for the handover. The MME responds to this with a S1AP:HANDOVER COMMAND message indicating that the resources at the target have been reserved. Handover execution The Flexi Multiradio BTS sends after this a RRC:MobilityfromEUTRAcommand message to the UE, which forces the UE to a WCDMA cell. The Flexi Multimode BTS performs handover retries to other target cells provided by the UE measurements in case of an unsuccessful handover preparation. Performance counter The Flexi Multiradio BTS supports Performance counters (management data) per cell in order to track the performance.

4.2.3.1

Enhanced Handover Mode and Target selection Depending on the output from RRM Handover Algorithm, the eNB selects the target cell for handover or eNACC (enhanced Network assisted cell change) and derives the appropriate handover mode from the selected target cell. Possible HO/eNACC Modes are: • • • • •

Intra eNB HO Intra LTE inter eNB HO via X2 Intra LTE inter eNB HO via S1 HO to WCDMA eNACC to GSM

All cells in the Target Cell list are checked according to the conditions listed below and are deleted from the Target Cell list if one of the conditions is met. An WCDMA cell is deleted from the TCL if at least one of the conditions listed below are met: •

• • •

36

the Serving PLMN of the UE is not on the list of PLMNs which are supported in the target cell. If a HO Restriction List is available and this list contains "Equivalent PLMNs", this means that neither the Serving PLMN nor one of the Equivalent PLMNs is contained in the list of PLMNs that are supported in the target cell. Note that restrictions applying to equivalent PLMNs in HO Restriction List are ignored if the Serving PLMN is selected for the Target system. the Target cell is blacklisted by Operator the combination of PLMN-Idendity and LAC of the target cell is on the Handover Restriction List provided by the MME Handover Restriction list contains the IE "Forbidden inter RATs" which is set to "ALL", "WCDMA", "GSM and WCDMA" or "CDMA2000 and WCDMA"

© 2016 Nokia




After the Target Cell has been finally selected as a WCDMA cell, the HO to WCDMA is executed. For WCDMA cells in the target cell list, eNB derives WCDMA Target Cell ID (including RNC ID) from O&M configuration.

4.2.3.2

Handover from LTE to WCDMA Handover from LTE to WCDMA passes the service responsibility for a UE from an LTE cell to a WCDMA cell. It is classified as an inter-RAT handover and is also an interfrequency handover. Inter-RAT handovers are Network Controlled, UE assisted backward handovers. Hard handover is performed - during the handover procedure the UE is only connected to one system at one time. The general objective is to be able to offer the UE the same level service in WCDMA as in LTE.Typical scenarios where this might be needed include: •

poor LTE coverage

Handover to WCDMA is a Handover via S1. The inter-RAT handover towards WCDMA can be logically split into four phases. These are: • • • •

Handover Initiation Handover Preparation Handover Execution Handover Completion

An inter eNB handover via S1 is always initiated by the source eNB based on the radio network configuration and the measurement results reported by the UE. If an ongoing S1 handover is stopped for any reason where the UE is to remain in the source cell (for example because Inter RAT UE Capabilities are missing) the following occurs at the source eNB: •

if guard timer TS1RELOCprep is running, stop it

•

if guard timer TS1RELOCoverall if it is running, stop it

•

if guard timer TS1RELOCcancel if it is running, stop it

If an ongoing S1 handover is stopped for any reason where the UE is not allowed to continue in the source cell, the source eNB: • • • •

4.2.3.3

stops the handover releases S1 signaling connection to the MME releases Radio Resources in the source cell releases S1 data connections to the S-GW

Measurement Activating WCDMA Measurements A new Measurement Configuration is constructed to activate Inter-RAT Measurements for WCDMA. UE-EUTRA-Capability contains the information if Handover to WCDMA is supported and which bandlists are supported and if measurement gaps are necessary for measurements. WCDMA measurements are only activated if the UE supports HO to WCDMA and there are predefined O&M Inter-RAT frequencies that the UE supports as well and the corresponding enabling flag is set.


© 2016 Nokia

37


4.2.3.3.1


Measurement Coordination Measurement Coordination requests for Measurement Control Command message can occur in four different use cases. These are : 1. LTE HO Idle -> Active When a UE starts a connection, it receives the instruction to measure intra-frequency only, that means it receives the Measurement Configuration with the following MeasId in the AddModifyList. Additionally if the UE supports event A5, that is indicated in the UE-EUTRA-Capabilities, then also measId Id_Trigger_Coverage_HO is included in the AddModifyList. 2. Incoming Handover The Handover Request from source eNodeB contains the VarMeasurementConfiguration, that must be modified properly. That means that only intra-frequency measurement with events A2, A3 and A5 (if supported by UE) and the corresponding thresholds are used. Therefore use in the MeasObjectRemovList all other frequencies from the source Configuration. Modify or Add the ReportConfig with event A2, A3 and A5 such that the correct Time-to-Trigger, hysteresis and thresholds are used.

g

Note: UE exchanges at inter-frequency HO the objects of serving and target frequency autonomously. Any other MeasObjects remain untouched. MeasGaps are deactivated by the UE, inter-frequency and inter-RAT measurements that require MeasGaps are continued when activated in new MeasConfig. 3. Outgoing Handovers Provide the current valid VarMeasurementConfiguration, where the MeasObjects and ReportConfigs are used in the corresponding AddModifyList 4. Changed Radio Conditions ( activate/deactivate Inter-Frequency/Inter-RAT measurements) The changed radio conditions are noticed by the Measurement result received, the constructed MeasConfig that is sent to the UE is described for activation and for deactivation. The AddModifyList and RemoveList is built according to activation thresholds.

4.2.3.3.2

Measurement Configuration for Handover to WCDMA For Handover to WCDMA the following IEs within MeasConfig IE are supported: • • •

4.2.3.3.3

measObjectUTRA reportConfigInterRAT measGapConfig

Measured Results Including Handover to WCDMA Requirements For Handover to WCDMA requirement the following information elements are supported: • •

38

mobilityMeasResult measResultListUTRA

© 2016 Nokia



4.2.3.4


Connection Mobility Control: Handover (CMC-HO) Support of Inter-RAT HO to WCDMA eNB supports inter RAT HO to WCDMA based on UE measurements. The feature works in parallel to other forms of active mobility. The handover algorithm handles the UE in RRC_CONNECTED message only. The UE in RRC_IDLE decides autonomously about cell reselection. The HO-Algorithm triggers the UE by Measurement Configuration to provide measurements. The measurement configuration consists of a list of measurement objects and report configuration. Depending on the RSRP of serving cell (rsrp(s)) different objects are measured: Table 10

Measurements

RSRP of serving cell

Measurement activities in UE

rsrp(s) > th1

no measurement except serving cell,

"th1 > rsrp(s) > max( Th2_InterFreq, Th2_WCDMA, Th2_GSM)"

intra-frequency measurement only

rsrp(s) < Th2_InterFreq

intra-frequency measurement + LTE inter frequency measurements+ potentially inter RAT measurements

rsrp(s) < Th2_WCDMA

intra-frequency measurement + WCDMA measurement+ potentially inter RAT/frequency measurements

rsrp(s) < Th2_GSM

intra-frequency measurement + GSM measurement+ potentially inter RAT/frequency measurements

Note: the last three rows in the foregoing table are interpreted in parallel. That means for rsrp(s) < min(Th2_InterFreq, Th2_WCDMA, Th2_GSM) all measurements interfrequency, WCDMA and GSM are activated. If RSRP of serving cell is higher than Th1, only the serving cell is measured. If it gets worse and is between Th1 and Th2_XXX, then additionally all other cells on the same frequency band (intra-frequency) are measured. In addition to the intra-frequency measurements HO-Alg activates inter-frequency measurements and/or inter-RAT measurements, if the RSRP of serving cell measure is worse than set threshold Th2_InterFreq, Th2_WCDMA and/or Th2_GSM. Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M. LTE inter frequency measurements are started only if: • • •


rsrp(s) < Th2_InterFreq the feature "Inter Frequency HO" is activated and the UE capabilities indicate that the UE is able to measure at least one of the LTE frequencies configured by the Operator to be measured and to perform intra LTE Inter Frequency Handover

© 2016 Nokia

39



WCDMA measurements are started only if: • • •

rsrp(s) < Th2_WCDMA the feature "HO to WCDMA" is activated and if the UE capabilities indicate that UE is able to measure at least one of the WCDMA layers configured by the Operator to be measured and to perform the Handover to WCDMA.

GSM measurements are started only if: • • •

rsrp(s) < Th2_GSM the feature "eNACC to GSM" is activated and if the UE capabilities indicate that UE is able to measure at least one of the GERAN layers configured by the Operator to be measured and to perform GSM measurement reporting event B2 in E_UTRA connected mode

When RSRP of serving cell becomes better than Th2a, then Inter-RAT measurements are de-activated. In order to prevent ping-pong effects, it is necessary that the value of Th2a is somewhat higher than Th2_InterFreq, Th2_WCDMA resp. Th2_GSM.Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.

4.2.3.5

Capacity, performance and overload control U-plane break during handover from LTE to WCDMA The U-plane interruption in DL during handover from LTE to WCDMA and inter-RAT handover from LTE to WCDMA is on average not greater than 150ms. In UL it is on average not greater than 300 ms. Inter-RAT HO to WCDMA The U-plane interruption in DL during inter-RAT handover from LTE to UMTS is not greater than 150 ms on average. The UL U-plane latency is not greater than 300 ms on average.

4.2.3.6

Configuration Management

4.2.3.6.1

Inter RAT handover to WCDMA Due to handover to WCDMA, additional objects are needed to provide information about Inter-RAT objects. Neighbouring information for WCDMA are statically configured by O&M. Therefore, such information is available in newly introduced Object classes LNADJW and LNHOW: LNADJW for neighbouring WCDMA cell information LNADJW object represents a WCDMA cell which can be taken into consideration as a neighbouring WCDMA cell by LNCEL when its lnAdjWId parameter is listed on WCMDA Neighbouring Cell Information adjWInf parameter. It is mandatory to specify exactly one Primary PLMN according to Table 13: New parameters for the Target primary PLMN ID list while the Further PLMN according to Table 14: New parameters for the Target secondaryPlmnIdL list are just optional. Up to five further PLMN can be configured.

40

© 2016 Nokia




The LTE-UTRAN neighboring object LNADJW is identified with separate parameters PLMN, RNC ID and CI. LNHOW for measurements and handover to WCDMA related information. LNHOW is an object that represents a set of HO to WCDMA related parameters, and it is created on LNCEL level per one WCDMA frequency given by utraCarrierFreq parameter. When an instance of LNADJW is added to adjWInf list in LNCEL, then for such LNCEL instance a corresponding LNHOW instance must exist (or be newly created) with the same value of the utraCarrierFreq parameter. Cardinality of new objects is as follows: • •

LNADJW is 0...32 LNHOW is 0...16

Cardinality of adjWInf relation: •

up to 32 elements

Both objects are handled in common way as other Object classes in plan file. Therefore creation, modification, and deletion of Object classses LNADJW and LNHOW can be done with plan file operations.

4.2.3.6.2

Activation of the feature Inter RAT handover to WCDMA is an optional feature in LTE. The operator needs to activate this feature by setting a corresponding flag represented by the parameter actHOtoWcdma to value enabled. This flag is set only once per eNB.

4.2.4 System impact Interdependencies between features •

LTE442: Network Assisted Cell Change to GSM Competing features. The LTE to GSM Network Assisted Cell Change (NACC) functionality of the Flexi Multiradio BTS allows for a service continuity of data services when changing from a LTE cell to a GSM cell.

Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.2.5 LTE56: Inter RAT Handover to WCDMA management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms


© 2016 Nokia

41



There are no alarms related to this feature. Measurements and counters Table 11: New counters lists counters introduced with this feature. Table 11

Counter ID

42

New counters

Counter name

Measurement

M8016C14

"Inter System Handover preparations

8016 - LTE Inter System Handover (WBTS)

M8016C15

Failed Inter System Handover preparations due to timer


M8016C16

Failed Inter System Handover preparations due to admission control


M8016C17

Failed Inter System Handover preparations due to other reasons


M8016C21

Inter System Handover attempts

8016 - LTE Inter System Handover (WBTS

M8016C23

Successful Inter System Handover attempts 8016 - LTE Inter System Handover (WBTS)

M8016C25

Failed Inter System Handover attempts


M8017C4

Failed Inter System Handover preparations to UTRAN due to expiration of guarding timer per neighbour cell relationship

8017 - LTE Inter System Handover Neighbour Cell (WBTS)

M8017C5

Failed Inter System Handover preparations to UTRAN due to admission control in target cell per neighbour cell relationship


M8017C6

Failed Inter System Handover preparations to UTRAN due to admission control in target cell per neighbour cell relationship


M8017C7

Inter System Handover attempts to UTRAN per neighbour cell relationship


M8017C8

Successful Inter System Handover completions to UTRAN per neighbour cell relationship


M8017C9

Failed Inter System Handover attempts to UTRAN per neighbour cell relationship


© 2016 Nokia



Table 11


New counters (Cont.)

Counter ID

Counter name

M8017C10

Measurement

Inter System Handover preparations per neighbour cell relationship


There are no measurements related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 12: New parameters lists parameters introduced with this feature. Table 12

New parameters

Full name


Abbreviated name

Managed object

Utran Target Index

lnAdjWId

LNADJW

Target Location Area Code

uTargetLac

LNADJW

Target Routing Area Code

uTargetRac

LNADJW

Target RNC Id

uTargetRncId

LNADJW

Target Cell Id

uTargetCid

LNADJW

Target Frequency

uTargetFreq

LNADJW

Primary Scrambling Code (FDD)

uTargetScFdd

LNADJW

Enable Handover From LTE To WCDMA actHOtoWcdma

LNBTS

Supervision Timer For The Preparation For Handover To WCDMA

tS1RelPrepU

LNBTS

Delta For Supervision Timer For The Execution For Handover To WCDMA

tS1RelOvDeltU

LNBTS

S1 Handover Cancel Supervision Timer For Handover To WCDMA

tS1RelCanU

LNBTS

Timer T304 For InterRAT

t304InterRAT

LNCEL

Filtering Coefficient Used For CpichRSCP

filterCoefficientCpichRscp

LNCEL

© 2016 Nokia

43


Table 12



Full name

Abbreviated name

Managed object

Filtering Coefficient Used For CpichEcNo

filterCoefficientCpichEcn0

LNCEL

Threshold Th2 WCDMA For RSRP

threshold2Wcdma

LNCEL

Related Hysteresis of Threshold Th2 WCDMA For RSRP

hysThreshold2Wcdma

LNCEL

Time To Trigger For A2 To Activate WCDMA Measurement

a2TimeToTriggerActWcdmaM eas

LNCEL

Measurement Quantity Used For UTRA FDD Measurements

measQuantityUtra

LNCEL

Time to trigger for A1 to deactivate inter measurement

a1TimeToTriggerDeactInterMe LNCEL as

Threshold th2a for RSRP

threshold2a

LNCEL

Related hysteresis of threshold th2a for RSRP

hysThreshold2a

LNCEL

Utran Carrier Frequency

utraCarrierFreq

LNHOW

Utran Offset Frequency

offsetFreqUtra

LNHOW

Time To Trigger UTRA Measurement Report

b2TimeToTriggerUtraMeas

LNHOW

Interval For Periodical UTRA Measurement Reporting

reportIntervalUtra

LNHOW

Threshold1 UTRA For RSRP Of Serving b2Threshold1Utra Cell

LNHOW

Threshold2 UTRA For EcNo neighbour Cell

b2Threshold2UtraEcn0

LNHOW

Threshold2 UTRA For RSCP neighbour Cell

b2Threshold2UtraRscp

LNHOW

Related Hysteresis of Thresholds B2Th1 hysB2ThresholdUtra and B2Th2 for Handover to WCDMA

LNHOW

Utran Handover Instance Identifier

LNHOW

lnHoWId

Table 13: New parameters for the Target primary PLMN ID list lists parameters introduced with this feature.

44

© 2016 Nokia



Table 13


New parameters for the Target primary PLMN ID list

Full name

Abbreviated name

Managed object

Structure

Mobile Country Code of the primary PLMN ID

mcc

LNADJW

primaryPlmnId

Mobile Network Code of the primary PLMN ID

mnc

LNADJW

primaryPlmnId

This parameter determines the length of MNC

mncLength

LNADJW

primaryPlmnId

Table 14: New parameters for the Target secondaryPlmnIdL list lists parameters introduced with this feature. Table 14

New parameters for the Target secondaryPlmnIdL list

Full name

Abbreviated name

Managed object

Structure

Mobile Country Code of the secondary PLMN ID

mcc

LNADJW

secondaryPlmnIdL

Mobile Network Code of the secondary PLMN ID

mnc

LNADJW

secondaryPlmnIdL

This parameter determines the length of MNC

mncLength

LNADJW

secondaryPlmnIdL

Table 15: New parameters for the List Of Pointer to LNADJW Instance lists parameters introduced with this feature. Table 15

New parameters for the List Of Pointer to LNADJW Instance

Full name

Abbreviated name

Managed object

Structure

Utran Adjacent WCDMA Cell Index

lnAdjWIndex

LNCEL

adjWInfList

WCDMA Cell Blacklisted Or Not

cellBlacklisted

LNCEL

adjWInfList

Table 16: Related existing parameters lists existing parameters related to this feature.


© 2016 Nokia

45


Table 16


Related existing parameters

Full name

Abbreviated name

Managed object

Threshold Th2a For RSRP

threshold2a

LNCEL

Related Hysteresis of Threshold Th2a For RSRP

hysThreshold2a

LNCEL

Time To Trigger For A1 To Deactivate Inter Measurement



Sales information

BSW/ASW



ASW

-

-

4.3 LTE68: Support of Cell Based Location Service Introduction to the feature With this feature it is possible for the operator to get the location data of an UE. Therefore the MME(Mobility Management Entity) requests eNB reports of the cell based location information for the concerned UE. An eNB report comprises: •

•

ECGI (E-UTRAN Cell Global Identifier) of the cell serving the concerned UE. ECGI globally identifies a cell. It is composed from the PLMN identity the cell belongs to and the Cell identity of the cell. TAI (Tracking Area Identity) of the tracking area the serving cell of the concerned UE belongs to. TAI globally identifies a tracking area. It is composed from the PLMN identity the tracking area belongs to and the tracking area code of the tracking area.

The MME can either request a single report or recurring reports upon cell change. The latter comprises reports in case of intra-eNB handover and inter-eNB handover (X2 and S1handover). The reporting is UE specific. An active reporting upon cell change can be stopped on MME request.

4.3.1 Benefits The location information can used by various location dependant applications, which affects the end user as well as the operator. End-user benefits This feature benefits the end user as follows

46

© 2016 Nokia



• •


Emergency calls: When the end-user initiates an emergency call, he can be located. Location based billing

Operator benefits This feature benefits the operator as follows: • • •

Emergency calls: When the end-user initiates an emergency call, he can be located Location based billing Lawful Interception

4.3.2 Requirements Software requirements Table 18: Software requirements lists the software required for this feature: Table 18


System Release

eNB

RL release

RL30

LBTS3.0

RL30

-

-

-

-


4.3.3 Functional description Functional overview For this feature different scenarios must be considered: •

•

direct eNB location reporting: The MME requests direct location reporting (single location report) from the eNB for a specific UE. The eNB immediately provides the report for the concerned UE back to the MME. eNB location reporting upon cell change: The MME requests location reporting upon cell change from the eNB for a specific UE. The eNB immediately provides a report for the concerned UE back to the MME after having received the request. Furthermore the eNB provides a report for the concerned UE upon cell change, i.e. after successful intra-eNB handover or X2 respective S1 handover. To stop the location reporting a stop-request from the MME must be executed.

This feature must be activated by setting the parameter actLocRep to true. If the parameter actLocRep is set to false, this feature is deactivated. In the following message sequence charts for different situation are shown: Direct location reporting In Figure 1: Direct location reporting the direct location reporting MSG is shown.


© 2016 Nokia

47


Figure 1


Direct location reporting

eNB

MME

1)S1AP:LOCATIONREPORTINGCONTROL(direct) 2)S1AP:LOCATIONREPORT(cellinfo)

Step 1: The MME requests a direct report of cell related information from the eNB serving the concerned UE by means of the S1AP: LOCATION REPORTING CONTROL message with IE Request type set to ‘direct’. Step 2: The eNB immediately provides the information of the serving cell to the MME by means of the S1AP: LOCATION REPORT message. Location reporting upon cell change due to inter-eNB hand over Figure 2: Location reporting upon cell change due to inter-eNB hand over shows the MSG for a cell change due to inter eNB hand over. Figure 2

Location reporting upon cell change due to inter-eNB hand over

eNB

MME

1)S1AP:LOCATIONREPORTINGCONTROL (changeofservicecell) 2)S1AP:LOCATIONREPORT (cellinfo) Intra-eNB handover 3)S1AP:LOCATIONREPORT (newcellinfo)

Step 1: The MME requests a report of cell related information upon cell change from the eNB serving the concerned UE by means of the S1AP: LOCATION REPORTING CONTROL message with IE Request Type set to ‘change of service cell’. Step 2: The eNB immediately provides the information of the serving cell to the MME by means of the S1AP: LOCATION REPORT message. This immediate report of the current serving cell information can also be regarded as conformation on MME side that the eNB has accepted the request for reporting of cell change. Step 3: After inter-eNB hand over the eNB provides the information of the new serving cell towards the MME by means of the S1AP: LOCATION REPORT message. Location reporting upon cell change due to X2 hand over Figure 3: Location reporting upon cell change due to X2 handover shows the MSC for a cell change to another eNB via x2 handover.

48

© 2016 Nokia



Figure 3


Location reporting upon cell change due to X2 handover

Target eNB

Source eNB

MME

1)S1AP:LOCATIONREPORTINGCONTROL (changeofservicecell) 2)S1AP:LOCATIONREPORT (cellinfo) X2 handover started 3)X2AP:HANDOVERREQUEST (changeofservicecell) X2 handover concluded 4)S1AP:LOCATIONREPORT (newcellinfo)

Step 1: The MME requests a report of cell related information upon cell change from the eNB serving the concerned UE by means of the S1AP: LOCATION REPORTING CONTROL message with IE Request Type set to ‘change of service cell’ Step 2: The eNB immediately provides the information of the serving cell to the MME by means of the S1AP: LOCATION REPORT message. This immediate report of the current serving cell information can also be regarded as conformation on MME side that the eNB has accepted the request for reporting of cell change. Step 3: During X2 handover the source eNB sends the X2AP: HANDOVER REQUEST message with IE Location Reporting Information set to ‘change of service cell’ to the target eNB in order to inform the target eNB on the ordered location reporting upon cell change. Step 4: After X2 handover the target eNB provides the information of the new serving cell towards the MME by means of the S1AP: LOCATION REPORT message. Location reporting upon cell change due to S1 handover Figure 4: Location reporting upon cell change due to S1 handover shows the msc for a cell change to another eNB via S1 handover.


© 2016 Nokia

49


Figure 4


Location reporting upon cell change due to S1 handover

Target eNB

MME

Source eNB

1)S1AP:LOCATIONREPORTINGCONTROL (changeofservicecell) 2)S1AP:LOCATIONREPORT (cellinfo) S1 handover started

3)S1AP:HANDOVERREQUIRED

4)S1AP: HANDOVERREQUEST (changeofservicecell) S1 handover concluded 5)S1AP:LOCATIONREPORT (newcellinfo)

Step 1: The MME requests a report of cell related information upon cell change from the eNB serving the concerned UE by means of the S1AP: LOCATION REPORTING CONTROL message with IE Request Type set to ‘change of service cell. Step 2: The eNB immediately provides the information of the serving cell to the MME by means of the S1AP: LOCATION REPORT message. This immediate report of the current serving cell information can also be regarded as conformation on MME side that the eNB has accepted the request for reporting of cell change. Step 3: During S1 handover the source eNB sends the S1AP: HANDOVER REQUIRED message to the MME. The S1AP: HANDOVER REQUIRED message does not include location reporting related parameters. Step 4: The MME sends the S1AP: HANDOVER REQUEST messsage to the target eNB including the IE Request Type set to ‘change of service cell’ if location reporting upon change of the serving cell shall be continued in the target eNB. It is up to the MME to decide if the location reporting upon cell change shall be continued or not. Step 5: After S1 handover the target eNB provides the information of the new serving cell towards the MME by means of the S1AP: LOCATION REPORT message. Stop location reporting In Figure 5: Stop location reporting the stopping of location reporting is shown.

50

© 2016 Nokia



Figure 5


Stop location reporting

eNB

MME

S1AP:LOCATIONREPORTINGCONTROL (stopchangeofservicecell)

The MME requests to stop reporting of cell related information upon cell change from the eNB serving the concerned UE by means of the S1AP: LOCATION REPORTING CONTROL message with the IE Request Type set to ‘stop change of service cell’. Failure reporting Failure reporting is done by the Location Report Failure Indication procedure. It is initiated by the eNB in order to inform the MME that a Location Report Control procedure has failed due to an interaction with a handover procedure (see Figure 6: Location Report Failure Indication). Figure 6

Location Report Failure Indication MME

eNB

S1AP:LOCATIONREPORTFAILUREINDICATION

The S1AP: LOCATION REPORT FAILURE INDICATION message is sent from the source eNB to the MME in case of interaction with X2- or S1- handover.

4.3.4 System impact Interdependencies between features LTE53: Intra and inter eNB handover with X2. After successful intra-eNB handover or inter-eNB handover via X2 a location report has to be sent in case of location reporting upon cell change. During inter-eNB handover via X2 the request for location reporting upon cell change has to be transferred from the source eNB to the target eNB. LTE54: Intra-LTE handover via S1: During inter-eNB handover via S1 the target eNB has to handle a location reporting request if it was received by means of handover signalling. Impact on interfaces This feature impacts interfaces as follows: •

New S1AP messages: – – –

•


S1AP: Location Reporting Control S1AP: Location Report S1AP: Location Report Failure Indication

New IE included in X2AP, S1AP messages

© 2016 Nokia

51


– –


IE: UE context Information -> Location Reporting Information in X2AP: Handover Request. IE: Request Type in S1AP: Handover Request

This feature is managed by the parameters listed in Parameters. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.3.5 LTE68: Support of Cell Based Location Service Management Data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 19: New counters lists counters introduced with this feature. Table 19

New counters

Counter ID

Counter name

Measurement

M8000C35

Number of Location Reporting Control messages

The number of Location Reporting Control messages received from MME per eNB.

M8000C36

Number of Location Report messages

The number of Location Report messages sent to MME per eNB.


New parameters

Full name Activate Location Reporting

52

Abbreviated name actLocRep

© 2016 Nokia

Managed object MRBTS / LNBTS





Sales information

BSW/ASW



ASW

-

-

4.4 LTE426: System Time Broadcast for SIB8 Introduction to the feature Idle mode mobility from LTE to CDMA2000/1xRTT and CDMA2000/HRPD networks requires that UEs camping on an LTE cell can remain synchronized with the CDMA2000 networks. In the scope of this feature, the CDMA2000 system time information is added to the content of SIB8 to be broadcasted to the UEs served by an LTE cell.

4.4.1 Benefits The timing info is used to enable single-receiver UEs to synchronize with CDMA2000 network while camping on an LTE cell.

4.4.2 Requirements Software requirements Table Software requirements lists the software required for this feature. Table 22


System release

RL30

eNodeB

LBTS3.0

MME

-

SAE GW

-

UE

3GPP release 8 capabilities

NetAct

-

Hardware requirements A GPS receiver is needed for the reception of the GPS satellite signal. It is an optional sales item. For instructions on how to install the GPS receiver, see Installing Flexi Multiradio BTS LTE Optional Items.


© 2016 Nokia

53



4.4.3 Functional description In the scope of this feature, the timing of LTE frames on the air interface is synchronized with the CDMA2000 frame timing. Both frame types have a length of 10ms. The frame borders become synchronized, the frame numbering remains RAT specific. The eNB receives its timing from the GPS receiver and calculates the CDMA2000 system time corresponding to a given reference point in the LTE network’s frame structure. The reference point is defined as ‘the LTE SFN boundary at or after the ending boundary of the SI-window in which SIB8 is transmitted’. This is illustrated in Figure Time reference point in CDMA2000 timing. Figure 7

Time reference point in CDMA2000 timing

phase synchronousto CDMA2000at antenna

SIB8

LTEframe boundary= CDMA2000 frameboundary

actualsendpositiononSIB8 si-Window(upto80ms)

Each 10-millisecond LTE frame represents 12288 CDMA2000 chips. When the bounder of an LTE frame is synchronous with the CDMA2000 frame signal, the CDMA2000 system time is broadcasted in SIB8. The difference in timing between the LTE frame and the broadcasted CDMA2000 system time will remain between ±1 microsecond.

4.4.4 System impact Interdependencies between features The feature is dependent on the following features: • • • •

LTE80: GPS Synchronisation LTE663: GPS Location and Time Retrieval LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT LTE870: Idle Mode Mobility from LTE to CDMA/eHRPD

Impact on interfaces SIB8 contains CDMA2000 system time information (a 39-bit long string defined in synchronousSystemTime). Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

54

© 2016 Nokia




4.4.5 LTE426: System Time Broadcast for SIB8 management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

4.4.6 Sales information This feature belongs to the Base Software (BSW) product structure class and does not require activation. Note, however, that the feature functions only if feature LTE807 or LTE870 has been activated.

4.5 LTE430: DL power boosting for control channels Introduction to the feature LTE430: DL power boosting for control allows to apply power offsets to the PCFICH (Physical Control Format Indicator Channel), PHICH (Physical Hybrid ARQ Indicator Channel) and the downlink reference symbols.

4.5.1 Benefits End-user benefits This feature benefits the end user as follows: • • •

Better detection of PCFICH indicating the number of OFDM (Orthogonal FrequencyDivision Multiplexing) symbols for the PDCCH (Physical Downlink Control Channel). Higher reliability of ACK/NACK (positive/negative acknowledgement) transmission via PHICH. Better channel estimation in case of RS (Reference Signal) boosting may improve handover performance.

Operator benefits While applying the boost of PCFICH and of PHICH in proper amounts, the feature provides a roughly uniform probability of correct decoding of control channels and is thus beneficial for coverage.


© 2016 Nokia

55





System release Release

eNodeB

RL30

MME

LBTS3.0

SAE GW

-

-

UE

NetAct

3GPP R8

-


4.5.3 Functional description Functional overview The eNodeB (Evolved Node B) supports the following DL (Downlink) power boost options for MIMO (Multiple Inputs Multiple Outputs) and SIMO (Single Input Multiple Outputs) configurations: •

•

•

PCFICH power boosting The PCFICH provides information about the number of OFDM symbols used for the PDCCH. The eNB supports dedicated power control settings for the PCFICH in order to ensure that especially cell edge UEs can properly receive the PCFICH. A relative offset between the flat PSD (Power Spectral Density) on PDSCH and PCFICH can be configured by O&M (Operation and Maintenance) on cell level. PHICH power boosting The PHICH provides ACK/NACK information for the uplink transmission. The eNB supports dedicated power control settings for the PHICH in order to ensure that the UE (User Equipment) can properly receive the PHICH. PHICH power boost may not be (fully) apllied if PDCCH PSD goes too low in the first OFDM symbol. In that case, the eNB rises the Phich Power Boost not applied warning. A maximum relative offset between the flat PSD on PDSCH and PHICH can be configured by O&M on cell level. Downlink reference signal boosting The downlink reference symbols are used by the UE for the channel estimation and used for Cell Measurements (Level, Quality) for Handover purposes. The eNB supports relative RS / PDSCH power control settings. A relative offset between the PDSCH and RS can be configured by O&M on cell level.

The eNB ensures that total Tx (Transmission) power is not exceed. The sum power for any OFDM symbol must not exceed the commited maximum power, otherwise all the configured boosts (PHICH) may not be applied. Subcarrier power boosting is only allowed if the excess power is withdrawn from the remaining subcarriers.

56

© 2016 Nokia



g


Note: UL coverage in LTE is very often limited, and in such cases it does not make much sense to improve the coverage in DL. UL (Uplink) coverage should be checked before applying DL control channels power boost. PCFICH and PHICH power boosting Both PCFICH and PHICH can be boosted by up to 6 dB, the exact amount of boost being controllable by operator configurable O&M parameters. Missing detection of PCFICH would lead to missing detection of PDCCH and therefore wasting PDCCH and PDSCH (Physical Downlink Shared Channel) or PUSCH (Physical Uplink Shared Channel) resources. Missing or false alarm on PHICH would falsify the HARQ (Hybrid Automatic Repeat Request) ACK/NACKs and thus deteriorate the QoS (Quality of Service) (throughput, latency, reliability of signaling, etc.). Downlink reference signal boosting The power of Cell-Specific Reference Symbols can be increased with respect to PDSCH power by up to 6dB. The resulting CRS Tx power offset is broadcasted in the cell as the PDSCH_ConfigCommon> referenceSignalPower parameter. The power offset with respect to the PDSCH power level in OFDMA symbols without CRS is signaled to the UE in the PDSCH_ConfigDedicated>p-a parameter. In the current Nokia implementation, a CRS power offset of 3dB can be used when 2 TX ports (antennas) are deployed. This setting is configurable by MIMO power compensation parameter. Please note, that the decrease of 3dB of the PDSCH PSD due to MIMO power compensation parameter comes on top of the CRS power boost. The Tx power needed for boosting the CRS must be somehow compensated if the total transmission power of the cell is not increased.Therefore, the 3GPP standards forces a possibility to decrease the PDSCH power in OFDMA symbols with CRS. An index to the corresponding offset is broadcast in the cell as the PDSCH_ConfigCommon>p-b parameter. The CRS power boost parameters that are signaled to the UE are listed in the chapter 6.3.2 of 3GPP TS36.331. PBCH power de-boost The PBCH (Physical Broadcast Channel) REs are transmitted with the same Tx power as the PDSCH REs in the same OFDMA symbol.

4.5.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity


© 2016 Nokia

57



LTE430: DL power boosting for control channels may provide some benefits for the quality of channel estimations and for handover, however it should be taken into account that boosting CRS significantly lowers the quality of PDCCH, especially for the REs contained in the first OFDM symbol of the subframe.

4.5.5 LTE430: DL power boosting for control channels management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 24: Modified alarms lists alarms modified by this feature. Table 24

Modified alarms

Alarm ID 7655

Alarm name CELL NOTIFICATION

Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 25: New parameters lists parameters introduced with this feature. Table 25

New parameters

Full name

Abbreviated name

Managed object

Downlink PCFICH transmission power boost

dlPcfichBoost

LNCEL

Downlink PHICH transmission power boost

dlPhichBoost

LNCEL

Downlink reference signals transmission dlRsBoost power boost

LNCEL

Table 26: Related existing parameters lists existing parameters related to this feature.

58

© 2016 Nokia



Table 26



Full name

Abbreviated name

MIMO power compensation

Managed object

dlpcMimoComp

LNCEL


Sales information

BSW/ASW


BSW


-

-

4.6 LTE442: Network Assisted Cell Change to GSM Introduction to the feature Service continuity for data service when moving from LTE to GSM.

4.6.1 Benefits Operator benefits Short service interruption time for data services when changing from LTE to GSM.

4.6.2 Requirements Software requirements Table 28: Software requirements for FDD line lists the software required for this feature for FDD line. Table 28

Release


System Release

eNodeB

RL30

LBTS3.0

-

-

-

-


4.6.3 Functional description Functional overview


© 2016 Nokia

59



The LTE to GSM Network Assisted Cell Change (NACC) functionality of the Flexi Multiradio BTS allows for a service continuity of data services when changing from an LTE cell to a GSM cell. NACC is only applicable to NACC capable multimode devices supporting both LTE and GSM at the according frequency band. The UE capabilites are provided to the eNB by the feature group indicator. NACC trigger The NACC is a network controlled functionality with support of the UE. The following measurement events are used: • • •

A1 - deactivate IRAT measurements A2 - activate IRAT measurements B2 - IRAT measurements

The measurement events A2 and A1 are used to start and stop IRAT measurements and can be configured by the operator. The eNB will trigger IRAT measurements only for NACC capable UEs. The UE capabilities are considered as well for the setup of the IRAT measurement configuration, for example support of measurement gap and support of frequency bands. The target frequencies for the GSM measurements can be configured by the operator. Blacklisting of target cells is supported whereas blacklisting for measurements is not included. The event B2 is used for the IRAT measurements. The measurement configuration as source cell thresholds (RSRP), target cell thresholds (RSSI), hysteresis, time to trigger and speed dependent scaling can be configured by the operator. The Flexi Multiradio BTS initiates the NACC after receiving a measurement report form the UE by sending an RRC:MOBILITYFROMEUTRACOMMAND message with cell change order indication to the UE, which forces the UE to a GSM cell. Performance counter Performance counters (management data) are provided per cell in order to track the NACC performance Activation / Deacivation The NACC functionality can be enabled / disabled (Activation of eNACC to GSM) per cell via O&M.

4.6.3.1

eNACC to GSM eNACC procedure is used to send a UE which is currently in RRC Connected state in the Source eNodeB to GSM. Unlike in the handover procedure no resources are prepared in the target system. The UE will enter GSM in RRC Idle mode and start the RRC Connection Setup procedure in GSM. Speeding up this process the UE is provided with the RRC parameters to access the GSM target cell. Optionally GSM System information is provided as well. Cell changed order (CCO) CCO to GSM is also supported. The main difference to eNACC is that in this case no GSM System information is provided

4.6.3.1.1

eNACC Phases The procedure of Network Assisted Cell Change to GSM can be modeled in 3 phases: •

60

eNACC Decision

© 2016 Nokia



• •


eNACC Execution eNACC Completion

eNACC Decision Phase eNACC to GSM is triggered when the UE receives poor coverage in LTE cell and no other LTE cell is received with sufficient quality. The feature can be used in parallel to handover to WCDMA or inter-frequency intra LTE handover (intra LTE intra-frequency handover is always active in parallel). All of them are based on the intention to measure the corresponding inter-frequency / inter RAT neighbour cells when the received level of the serving cell falls below a threshold. Different threshold for different RATs provides priorization of RATs. In the first step when the received level of serving cell falls below a threshold, then it advises by MeasResult the eNB. This Measurement Result triggers on eNB side the order to measure in addition GSM neighbor cells. This might include MeasGap if the UE-EUTRA-Capability indicates the necessity. The UE is instructed to report the GSM neighbor cell list when the RSRP of serving cell is below a lower threshold and the RSSI of one or more GSM neighbor cell is higher than another (lower) threshold. When the UE finds GSM neighbor cells fulfilling the criteria rsrp(serv) < Threshold_1 and rssi(neighbor) > Threshold_2 it sends a MeasurementResult with GSM target cell list. On the other side, if the rsrp(serv) exceeds the threshold, a new MeasConfig is sent to UE to deactivate GSM measurements. Interaction to Handover to WCDMA: mobility to both technologies can be handled in parallel. The Measurement Result with TCL that comes first determines to which RAT the UE is sent. Using different rsrp threshold when GSM or WCDMA measurements are activated and TimeToTrigger values gives the possibility to introduce priority of RATs. eNACC Execution Phase Once the decision to perform eNACC to GSM has been made in the eNACC Decision phase, it is verified that the identified GSM Target cell is a valid target for an eNACC to GSM. The required RNL parameters are retrieved from the O&M database, and UE is commanded to perform Cell Change towards GSM by RRC message MOBILITYFROMEUTRACOMMAND. When receiving MOBILITYFROMEUTRACOMMAND, UE disconnects from LTE, enters RRC Idle mode, and starts RRC connection establishment procedure in the specified GSM cell. Even though the eNACC to GSM uses the same RRC Message (MOBILITYFROMEUTRACOMMAND) as handover to WCDMA, the handling is completely different. eNACC to GSM is specified as an independent procedure in parallel to HO to WCDMA. The existing functionality for HO to WCDMA remains unchanged. eNACC Completion Phase After the UE has successfully established RRC Connection Setup within GSM, the UE will perform an Routing Area Update Procedure (RAU) with the Core Network. Core Network will notice that the UE is still registered within the Source eNodeB and the serving MME will initiate a UE Context Release Procedure on S1 towards the Source eNB.

4.6.3.1.2

Enhanced Handover / eNACC Mode and Target selection Dependent on the output from RRM Handover Algorithm, the eNB selects the target cell for handover or eNACC and derives the appropriate handover mode from the selected target cell. Possible HO/eNACC Modes are:


© 2016 Nokia

61


• • • • •


Intra eNB HO Intra LTE inter eNB HO via X2 Intra LTE inter eNB HO via S1 HO to WCDMA eNACC to GSM

All cells in the Target Cell list are checked according to the conditions listed below and are deleted from the Target Cell list if one of the conditions is met. An GSM cell is deleted from the TCL list if at least one of the conditions listed below are met: • • • •

Target cell is blacklisted by Operator. Operator has not selected the Target cell for eNACC, for example parameter eNACC in GeranNeighbourCell is set to 'Not Supported' combination of PLMN-Idendity and LAC of the target cell is contained in the Handover Restriction List provided by MME (or during a previous incoming HO) Handover Restriction list contains the IE "Forbidden inter RATs" which is set to "ALL" or "GERAN" or "GERAN and UTRAN"

The HO mode selection algorithm is extended to take eNACC to GSM into account if the Target Cell is a GSM cell, eNACC to GSM is executed.

4.6.3.1.3

GSM Measurement Configuration and Reporting Requirements Measurement configuration and measurement reports for GSM measurements are supported by eNB. For the feature "eNACC to GSM" the following IEs within MeasurConfig IE are supported: • • •

measObjectGSM reportConfigInterRat measGapConfig

For eNACC to GSM the following information elements are supported: • •

4.6.3.2

mobilityMeasResult measResultListGSM

Connection Mobility Control: Handover (CMC-HO) Support of eNACC to GSM The eNB supports eNACC to GSM, based on measurements. The feature works in parallel to other forms of active mobility as Handover to WCDMA, intra-LTE handover and Redirect. HO Algorithm handles the UE in RRC_CONNECTED only. UE in RRC_IDLE decides autonomously about cell reselection. The HO-Algo triggers the UE by Measurement Configuration to provide measurements. The measurement configuration consists of a list of measurement objects and report configuration. Depending on the RSRP of serving cell (rsrp(s)) different objects are measured.

62

© 2016 Nokia




Table 29

Measurements

RSRP of serving cell

measurement activities in UE

rsrp(s) > th1

no measurement except serving cell,

th1 > rsrp(s) > max( Th2_InterFreq, Th2_WCDMA, Th2_GSM)

intra-frequency measurement only

rsrp(s) < Th2_InterFreq

intra-frequency measurement + LTE inter frequency measurements+ potentially inter RAT measurements

rsrp(s) < Th2_WCDMA

intra-frequency measurement + WCDMA measurement+ potentially inter RAT/frequency measurements

rsrp(s) < Th2_GSM

intra-frequency measurement + GSM measurement+ potentially inter RAT/frequency measurements

Note: the last three rows in this table are interpreted in parallel. That means for rsrp(s) < min(Th2_InterFreq, Th2_WCDMA, Th2_GSM) all measurements inter-frequency, WCDMA and GSM are activated. As indicated in the table above, if RSRP of serving cell is higher than Th1 only the serving cell is measured. If it gets worse and is between Th1 and Th2_XXX, then additionally all other cells on the same frequency band (intrafrequency) are measured. In addition to the intra-frequency measurements, HO-Algorithmus activates interfrequency measurements and/or inter-RAT measurements, if the RSRP of serving cell measure is worse than set threshold Th2_InterFreq, Th2_WCDMA and/or Th2_GSM. Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.LTE inter frequency measurements are started only if: • • •

rsrp(s) < Th2_InterFreq the feature "Inter Frequency HO" is activated and the UE capabilities indicate that the UE is able to measure at least one of the LTE frequencies configured by the Operator to be measured and to perform intra LTE Inter Frequency Handover

WCDMA measurements are started only if: • • •

rsrp(s) < Th2_WCDMA the feature "HO to WCDMA" is activated and the UE capabilities indicate that UE is able to measure at least one of the WCDMA layers configured by the Operator to be measured and to perform the Handover to WCDMA.

GSM measurements are started only if: • •


RSRP(s) < Th2_GSM the feature "eNACC to GSM" is activated and

© 2016 Nokia

63


•


the UE capabilities indicate that the UE is able to measure at least one of the GERAN layers configured by the Operator to be measured and to perform GSM measurement reporting event B2 in E_UTRA connected mode.

When RSRP of serving cell becomes better than Th2a, then Inter-RAT measurements are de-activated. In order to prevent ping-pong effects, it is necessary that the value of Th2a is somewhat higher than Th2_InterFreq, Th2_WCDMA resp. Th2_GSM.Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.

4.6.3.3 4.6.3.3.1

Capacity, performance and overload control eNACC to GSM Performance The eNACC procedure can be split in three phases, see eNACC Phases: decision phase, execution phase, and completion phase. User data are still transmitted via UL and DL during the decision phase. Similarly, user data are transmitted again in both directions in the completion phase. Thus the most important performance indicator is the service gap in the execution phase, for eample the time while the UE is in idle state and there is no user data transfer. The user plane service gap is not longer than 140 ms on average. NACC success rate As eNACC KPIs two rates are defined, the success rate and the cancellation rate. The success rate is defined as the ratio of successful completions to attempts. Although it is defined by LTE counters, its performance is dominated by the GSM network coverage and quality. Therefore the achievable values are expected to be approximately equal to the call setup success rate of the target GSM system. The success rate target is 98% or better under load.

4.6.3.4

Configuration Management for eNACC As a result of eNACC to GSM, additional objects are needed to provide information about Inter-RAT objects for GSM network. Therefore two new Object Classes are introduced in object model: LNADJG for neighbouring GSM cell information and LNHOG for measurements and handover to GERAN related information. LNADJG object represents GSM cell which can be taken into consideration as neighbouring GSM cell by LNCEL when its lnAdjGId parameter is listed on GSM Neighbouring Cell Information adjGInf parameter. LNHOG is an object class which represents a set of eNACC to GSM related parameters, and it is created on LNCEL level. Up to 32 GSM BCCH frequencies (arfcn parameter) can be configured per LNHOG instance. When an instance of LNADJG is added to adjGInf list in LNCEL then for such LNCEL instance corresponding LNHOG instance must exist (or be newly created) with same value of arfcn parameter. Cardinality of new objects is following: • •

LNADJG is 0...32 LNHOG is 0...6

Cardinality of adjGInf relation •

64

up to 32 elements

© 2016 Nokia




RNL support for eNACC to GSM With respect to eNACC to GSM feature, RNL supports new GSM related object classes in object model and neighbouring list of GSM target cells in LNCEL. Neighbouring GSM cells Neighbouring information for GSM are statically configured by O&M. Therefore, such information is available in newly introduced object classes LNADJG and LNHOG. Neighbouring GSM cell information For eNACC to GSM, operator needs to provide information about neighbouring GSM cells and HO related parameters. For providing GSM cells information LNADJG object representing known GSM cell was introduced in scope of LNBTS object. LNADJG is created by operator in plan file. Neighbouring GSM Cells information is provided in LNCEL object in parameter called NeighbouringGSMInformation (abbreviated name adjGInf), which is a list of identification parameters pointing to LNADJG instance (lnAdjGId naming attribute can be reused for this purpose). Additionally, NeighbouringGSMInformation contain information if neighbouring is blacklisted by the operator or not, and other funcinality related to GSM cell. Handling of LNADJG and LNHOG objects Both objects are handled in common way as other object classes in plan file. Therefore creation, modification, and deletion of Object Classes LNADJG and LNHOG can be done with plan file operations.

4.6.3.5 4.6.3.5.1

User scenarios Activation of eNACC to GSM eNACC to GSM is an optional feature in LTE, which needs to be activated by operator. Using the management tool, the operater can set the parameter acteNACCtoGSM to value true. This flag is set only once per eNB. For Deactivation the parameter acteNACCtoGSM must set to value false

4.6.3.5.2

UE leaves limited LTE Coverage Area Pre-condition A UE is connected to an LTE cell (in RRC Connected Mode) and has at least one Data Radio Bearer (DRB) established. The UE is configured to perform measurements on its own LTE frequency layer and is moving out of the LTE coverage area. Description When the level of the serving cell becomes worse than a threshold (without the possibility to perform handover towards another LTE cell), the UE is configured to measure GSM neighbour cells and report the measurements of the GSM neighbour cells to eNB. When the LTE quality falls below a further threshold, and at least one GSM neighbour cell with sufficient quality has been reported by the UE, the eNB commands the UE to release the RRC connection with LTE and start RRC Connection establishment towards a GSM Cell.


© 2016 Nokia

65



The eNB selects the GSM Cell based on measurements provided by the UE (taking additional configuration data into account, for eample blacklisting) and supports the UE with GSM system information to accelerate RRC Connection Setup within GSM.


•

LTE56 Inter RAT handover to WCDMA Competing features. Avoiding loss of coverage a UE can either be ordered to perform an Inter RAT handover to WCDMA or to perform eNACC to GSM. Both features can be activated in parallel. Prioritization between the features is done by setting of measurement parameters. LTE735 RRC Connection Re-establishment RRC Connection Re-Establishment may be used to handle error cases

Impact on interfaces This feature affects external interfaces as follows: •

•

Air interface - RRC IE for Measurement Configuration and Measurement Reporting is extended to support GSM measurements - The RRC Message MOBILITYFROMEUTRACOMMAND supports the purpose "cellChangeOrder” S1 Interface - new cause vales in Message S1AP UE CONTEXT RELEASE COMMAND

Impact on network and network element management tools This feature affects network management and network element management tools as follows: •

Interface to Netact Additional O&M Parameter, e.g. - Feature Activation Flag for eNACC to GSM - GSM neighbour Cell parameters (LNADJG) - GSM Neighbour relationships (adjGInf) Additional Performance Counters

Impact on system performance and capacity System Performance The most important indicator is the service gap, for eample the time while the UE is in state Idle and there is no data transfer. This idle period begins when the UE receives the RRC message from the eNB to connect to a GSM cell. The service gap ends when the UE enters connected mode again. The duration of the service gap is defined by the duration of the GSM quality measurements and the GSM connection setup protocol. As eNACC KPIs two rates are defined, the success rate and the cancellation rate. Note that the eNACC success rate is determined by the GSM network properties and is approximately equal to the call setup success rate of the target GSM system. The cancellation rate depends strongly on network coverage and quality. In areas where the GSM coverage is a complete superset of the LTE coverage, the cancellation rate is expected to be close to 0, except in overload conditions.Introduction of eNACC to GSM is not expected to have any impact on the performance of existing features. System Capacity

66

© 2016 Nokia




Introduction of eNACC to GSM is not expected to have impact on the system capacity

4.6.5 LTE442: Network Assisted Cell Change to GSM management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 30: New counters lists counters introduced with this feature. Table 30

New counters

Counter ID

Counter name

Measurement

M8019C0

Number of NACC from LTE to GSM attempts LTE Inter System Handover per neighbour cell relationship to GSM per Neighbor Cell

M8019C26

Number of NACC from LTE to GSM attempts LTE Inter System Handover


New parameters

Full name


Abbreviated name

Managed object

Network Colour Code

networkColourCode

LNADJG

Basestation Colour Code

basestationColourCode

LNADJG

ARFCN Value Geran

arfcnValueGeran

LNADJG

Band Indicator Geran

bandIndicatorGeran

LNADJG

Network Control Order

networkControlOrder

LNADJG

System Information Type

systemInfoType

LNADJG

System Info List Geran

systemInfoListGeran

LNADJG

© 2016 Nokia

67


Table 31



Full name

68

Abbreviated name

Managed object

Naming Attribute Of MOC LNADJG

lnAdjGId

LNADJG

MCC GERAN

mcc

LNADJG

MNC GERAN

mnc

LNADJG

MNC Length GERAN

mncLenght

LNADJG

LAC GERAN

gTargetLac

LNADJG

CI GERAN

gTargetCi

LNADJG

Enable eNACC To GSM

acteNACCtoGSM

LNBTS

Timer T304 For eNACC To GSM

t304eNaccGsm

LNCEL

Filtering Coefficient Used For RSSI

filterCoefficientRSSI

LNCEL

Threshold Th2 GERAN For RSRP

threshold2GERAN

LNCEL

Related Hysteresis of Threshold Th2 GERAN For RSRP

hysThreshold2GERAN

LNCEL

Time To Trigger For A2 To Activate GERAN Measurement

a2TimeToTriggerActGERANM eas

LNCEL

ARFCN Frequency Band Indicator

bandIndicatorGERAN

LNHOG

ARFCN Value List

arfcnValueListGERAN

LNHOG

Time To Trigger GERAN Measurement Report

b2TimeToTriggerGERANMeas LNHOG

Interval For Periodical GERAN Measurement Reporting

reportIntervalGERAN

LNHOG

Threshold1 GERAN For RSRP Of Serving Cell

b2Threshold1GERAN

LNHOG

Threshold2 GERAN For RSSI neighbour b2Threshold2RssiGERAN Cell

LNHOG

Related Hysteresis of Thresholds B2Th1 hysB2ThresholdGERAN and B2Th2 for Handover to GERAN

LNHOG

NCC Permitted Bit Map

nccperm

LNHOG

Naming Attribute Of MOC LNHOG

lnHoGId

LNHOG

© 2016 Nokia




Table 32: New parameters for the “List of Pointer To LNADJG Instance” lists new parameters introduced wih this feature. Table 32

New parameters for the “List of Pointer To LNADJG Instance”

Full name

Abbreviated name

Managed object

Structure

LnAdjGId

lnAdjGId

LNCEL

adjGInfList

Cell Blacklisted

cellBlacklisted

LNCEL

adjGInfList

ENACC

eNACC

LNCEL

adjGInfList

Table 33: Related existing parameters lists existing parameters related to this feature. Table 33


Full name

Abbreviated name

Managed object


threshold2a

LNCEL

Related Hysteresis of Threshold Th2a For RSRP

hysThreshold2a

LNCEL




Sales information

BSW/ASW



ASW

-

-

4.7 LTE450: MME Capacity Value Change 4.7.1 LTE450: MME capacity value change Introduction to the feature The MME can change the initial MME relative capacity value. This can be done with the MME Configuration Update Procedure. Specifically , the relative MME capacity can be set to zero which has the effect that new UEs entering the MME pool willl not be assigned to the MME. In addition this LTE450 allows to modify served GUMMEIs (Globally Unique MME Identifiers) and the MME name without release of UE associated connections.


© 2016 Nokia

69


4.7.1.1


Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits the operator as follows: The relative MME capacity value can be changed in order to • •

increase / decrease the capacity of a MMEs in an MME pool support of load re-balancing between MMEs, in particular for gracefully removing an MME from an MME Pool Area

The MME name can be changed without release of UE connections. Furthermore served GUMMEIs can be modified - also without release of UE associated connections.

4.7.1.2

Requirements Software requirements Table 35: Software requirements FD line lists the software required for this feature in the FD- line.. Table 35

Release

Software requirements FD line

System release

RL release

eNodeB

RL30

RL30

LBTS3.0

-

-

-

Table 36: Software requirements TD line lists the software required for this feature in the TD-line. Table 36

Release

Software requirements TD line

System release

RL release

eNodeB

RL25TD

-

TDLBTS2.0

-

-

-


4.7.1.3

Functional description Functional overview The MME can change its during the S1 setup assigned relative MME capacity with the MME Configuration Update procedure (triggered by S1AP: MME Configuration Update message).

70

© 2016 Nokia




Specifically, the relative MME capacity value can be set to zero which has the effect that new UEs entering the MME pool will not be assigned to the MME. In addition to the relative MME capacity, with the MME Configuration Update also the MME Name and the Served GUMMEIs (Globally Unique MME identifiers) valid for this MME may be modified. In the Figure 8: Message Chart for MME changes the Message chart for MME changes is shown. Figure 8

Message Chart for MME changes NbeNBNbeNB

eNB

MME

S1AP:!MME!CONFIGURATION!UPDATE If “Relative!MME!Capacity” modified Replace!old!with!newly!received “Relative!MME!Capacity” If “MME!Name” modified Replace!old!with!newly!received “MME!Name” in!LNMME If “Served GUMMEIs” modified

Replace!old!with!newly!received “Served!GUMMEIs”

If!GU!Group!IDs!are!modified X2!Setup!Request!Procedure

X2!Setup!Request!Procedure If!Broadcast!PLMN!IDs!are!modified BCCH:!SIB1!(!PLMN-IDs) BCCH:!SIB1!(!PLMN-IDs)

S1AP:!MME!CONFIGURATION!UPDATE!ACKNOWLEDGE

Remarks: •

•

•

Repetition of X2 Setup procedure for available X2 links to neighbour eNBs (NbeNBs) is required only if the modified 'Served GUMMEIs' (Global unit MME Identifier) received from MME leads to a modification of the GU Group IDs which were send during earlier X2 Setup procedures to the neighbour eNBs Modification of the broadcasted PLMN IDs in an eNB cell is required only if the modified 'Served PLMNs' included in 'Served GUMMEIs' leads to a modification of the PLMN IDs which can be supported (also via S1 interface) by an eNB cell. The S1AP: MME CONFIGURATION UPDATE ACKNOWLEDGE message is send back to MME as soon as all modified values are stored by eNB and eNB is able to handle new S1AP: MME CONFIGURATION UPDATE messages, if send by MME.

The failure case is shown in Figure 9: Failure case


© 2016 Nokia

71


Figure 9


Failure case

NbeNBNbeNB

eNB

MME

S1AP:MMECONFIGURATIONUPDATE

MMEConfigurationUpdatefails

S1AP: MMECONFIGURATIONUPDATEFAILURE

eNBcontinueswitholdlink configurationdata

In case MME Configuration Update cannot be accepted by the eNB, the eNB keeps the old link configuration data.

4.7.1.4

System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. This feature is managed by the parameters listed in LTE450: MME capacity value change management data. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has impact on the MME capacity.

72

© 2016 Nokia



4.7.1.5


Sales information Table 37

BSW/ASW

Sales information

SW component

BSW



-

-

4.7.2 LTE450: MME capacity value change management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 38: New alarms lists alarms introduced with this feature. Table 38

New alarms

Alarm ID 7651

Alarm name Base Station Operation degraded

What is the meaning of this alarm? The eNB has encountered few possibly misconfigured PLMNs which cannot be used by the eNB for accepting calls from new UEs selecting those PLMNs. These PLMNs are configured with some cells at the eNB and served by one or more MME(s). But none of these PLMNs have serving MME(s) with relative capacity greater than zero. All previously registered UEs in these PLMNs remain unaffected. Raised if a MME pool is configured in the eNB and if no ‘Relative MME capacity’ is available for one or more PLMN IDs which are supported by connected MMEs and are at the same time configured for an activated eNB cell. Measurements and Counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

4.8 LTE473: Extended DRX settings Introduction to the feature


© 2016 Nokia

73



The Flexi Multiradio BTS supports with this feature an extended range of 3GPP settings for the long DRX cycle, two additional operator configurable DRX profiles, and uplink Out-of-Sync handling.

4.8.1 Benefits The extension to support longer settings for the long DRX cycle leads to a lower UE power consumption mainly for UEs with only occasional data transmission.


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-



Feature scope Extended DRX settings feature improves power savings for the UE by supporting also settings of the long DRX cycle beyond 80ms from the 3GPP defined range. Those additional savings in power are feasible for bursty traffic patterns (i.e. short phases with data transmission followed by long phases of idle period). The potential additional power savings come, however, at the cost of increased latency for DL transmission whenever the UE is in DRX sleep mode.

4.8.3.2

Basic characteristics and limitations LTE473 is an extension to feature LTE 42:Support of DRX in RRC Connected. LTE473: Extended DRX settings feature comprises three subfeatures: • • •

support of an extended value range of the long DRX Cycle two additional operator configurable DRX profiles uplink Out-of-Sync handling

Support of an extended value range of the long DRX Cycle Two profiles which support extended 3GPP value range for the long DRX cycle (160, 320ms in Profile4; 640, 1280, 2560ms in Profile5). Two additional operator configurable DRX profiles

74

© 2016 Nokia




Two additional operator configurable DRX profiles are introduced with this feature in order to allow more flexible definition of different DRX use cases, e.g. Out-of-Sync handling. •

•

drxProfile4: “non-GBR” (<500ms, e.g. QCI 5) The profile is optimized for non-GBR bearers with specific latency requirements that allow setting medium DRX cycle length (e.g. IMS signaling) drxProfile5: “non-GBR” (>=500ms) The profile is appropriate for non-GBR bearers without specific latency requirements that allow setting long DRX cycle length (e.g. web browsing)

Additional profiles will only yield some gains if gaps in UE data transmission are sufficiently large (e.g., always-on devices doing only an occasional data transmission with gaps of at least several tens of seconds). The UEs are kept DRX Active always during phases of data transmission and dropped to UL out-of-sync afterwards (the UE benefits from the extended DRX when in UL Out-of-Sync state). Any kind of traffic mapped to QCIs using such profiles should be latency tolerant as to match at least the long DRX cycle setting. Extended DRX is supported for QCI 5-9 (i.e., QCI types without any delay guarantees). Uplink Out-of-Sync handling The uplink Out-of-Sync handling comprises the following two subfeatures: •

•

Uplink Out-of-Sync enforcement By using very long settings for the DRX cycle, the UE may go to or is even actively sent to the uplink Out-of-Sync status. For this timing alignment is stopped some time after UE has finished data transmission. Transition to uplink In-Sync –

–

DL data transmission trigger The eNodeB initiates a random access procedure for UEs which are in uplink Out-of-Sync and have data for downlink transmission. The eNodeB provides in this case the RACH parameters via the PDCCH order to the UE. UL data transmission trigger During the UL Out-of-Sync state, UE may start a contention based random access procedure in order to transmit data on uplink Following the transition to In-Sync, UEs are reconfigured with any resources released during UL Out-of-Sync transition (resources on PUCCH and for SRS, if applicable).

Related parameters •

Apply UL Out-of-Sync Determines which UEs is actively sent to UL Out-of-Sync state provided that bearer combination and applied DRX profile allows this. Three settings are possible: – – –

•


extendedDrxonly: only UEs being configured with extended settings for the long DRX cycle allDrx: all UEs being configured for DRX provided that applied DRX profile allows allUEs: all UEs independently of DRX configuration provided that bearer combination allows

Short Term Inactivity Factor

© 2016 Nokia

75



Short Term Inactivity Timer determines when to trigger sending the UE to UL out-ofsync by stopping timing alignment to the UE after a data transmission phase of the UE has ended. Short Term Inactivity Timer is configurable in multiples of the DRX Inactivity Timer setting applied by the parameter Short Term Inactivity Factor.

4.8.3.3

User scenarios LTE473 does not have a separate O&M parameter for activation but it is activated along with the O&M parameter of LTE42 feature. Additional profiles of LTE473 are taken into use by assigning them to a certain QCI. For details, see LTE42:Support of DRX in RRC connected mode feature description. In contrast to the transition UL in-synch to UL out-of-synch, the transition of the UEs from UL out-of-sync to UL in-sync is not tied to any O&M parameter.

4.8.4 System impact Interdependencies between features LTE42 introduces a basic DRX functionality like triggers for (re)configuring DRX, DRX profile selection, UE DRX status tracking. LTE473 adds additional DRX profiles and functionalities. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature affects system performance and capacity as follows: •

Transitions from UL out-of-sync to UL in-sync due to either DL or UL data arrival generate additional load on RACH as well as in control plane due to a reconfiguration of resources on PUCCH and for SRS.

4.8.5 LTE473: Extended DRX settings management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 40: New counters lists counters introduced with this feature.

76

© 2016 Nokia



Table 40

Counter ID


New counters

Counter name

Measurement

M8001C421

Number of PDCCH order attempts

LTE Cell Load (WBTS)

M8001C422

Number of initial PDCCH order attempts


M8001C423

Number of successful PDCCH orders


M8001C424

Unavailability of dedicated preamble


M8001C425

Unavailability of dedicated preamble for PDCCH order purposes


M8001C426

Unavailability of dedicated preamble for handover purposes


M8001C427

Number of UE state transitions from UL-InSync to UL-Out-Of-Sync


M8001C428

Average number of UEs in UL-In-Sync


M8001C429

Average number of UEs with unlimited power supply resources


M8001C430

UE UL-Out-Of-Sync time T in the range 0 seconds < T <= 0.5 seconds


M8001C431

UE UL-Out-Of-Sync time T in the range 0.5 seconds < T <= 2.5 seconds


M8001C432

UE UL-Out-Of-Sync time T in the range 2.5 seconds < T <= 10 seconds


M8001C433

UE UL-Out-Of-Sync time T in the range 10 seconds < T <= 100 seconds


M8001C434

UE UL-Out-Of-Sync time T larger than 100 seconds


Key performance indicators There are no key performance indicators related to this feature. Parameters Table 41: New parameters lists parameters introduced with this feature.


© 2016 Nokia

77


Table 41


New parameters

Full name

Abbreviated name

Managed object

Apply UL out-of-sync state

applyOutOfSyncState

DRX

DRX profile index

drxProfileIndex

LNBTS

Structure

qciTab5, qciTab6, qciTab7, qciTab8, qciTab9

DRX profile index

drxProfileIndex

DRX


DRX profile priority

drxProfilePriority

DRX


DRX long cycle

drxLongCycle

DRX


DRX on duration timer

drxOnDuratT

DRX


DRX inactivity timer

drxInactivityT

DRX


DRX retransmission timer

drxRetransT

DRX


Short term inactivity factor

stInactFactor

DRX


Sales information

BSW/ASW



ASW

-

-

4.9 LTE490: Subscriber profile based mobility Introduction to the feature Subscriber profile ID (SPID) based mobility schemes can be deployed.

78

© 2016 Nokia




4.9.1 Benefits Operator benefits The feature introduces subscriber profile ID based traffic steering. A typical use case is national roaming where the SPID provided by the MME is used to identify own subscribers and national roaming subscribers. Another use case is MOCN where each operator can define its own target frequency layer.


Release


System Release

eNode B

RL30

LBTS3.0

-

-

-

-


4.9.3 Functional description Functional overview The feature allows the operator to assign subscriber profile IDs (SPID) to mobility profiles. The MME provides the subscriber profile ID to the eNB via the S1AP:InitialContextSetup message. When the eNB receives the SPID from another eNB, this is done via Handover message. The SPID is forwarded during intra LTE handovers either via X2AP:Handover Request or via the S1AP:HandoverCommand message. The SPID itself is mapped to a mobility profile. When SPID value was not received or SPID cannot be mapped to Mobility Profile instance, eNB uses so called "default profile", which can be manually configured by operator in the same way as Mobility Profile or which can use automatically all configurations provided by operator during configuration of separate mobility features. A mobility profile is a set of O&M configured target frequency layers for enabled inter-frequency and inter-RAT mobility functions, for example handover, NACC, RRC connection release with redirect or CSFB. Target frequency layers in mobility profiles can be seen as a filter on the configured neighbour cells represented by LNADJL, LNADJW and LNADJG objects. Redirection configuration, which is part of the profile (MODRED, MORED) is an alternative, typically restricted configuration compared to REDRT configuration, NACC, RRC connection release with redirect or CSFB. Up to eight mobility profiles can be defined per eNB by O&M settings. The eNB will use only the neighbor cells out of the SPID related mobility profile for the different mobility scenarios. It is possible to create, modify, and delete Mobility Profiles via plan file. Modifications are possible for O&M data but not for SPIDs which are assigned to UEs. All operations are possible online without affecting service. This means that ongoing calls are not affected and for this measurements will not be re-configured Performance counter


© 2016 Nokia

79



The Flexi Multiradio BTS supports Performance counters (management data) per cell in order to track performance.

4.9.3.1

Handling of LTE490 reconfiguration If LTE490 feature has already been enabled at eNB and there is a change in LTE490 configuration data, for example add/modify/delete of User Profile(s) and/or add/modify/delete of content in Mapping between User Profiles (MOPR) and SPIDs, the eNB has to update the locally stored LTE490 configuration data. The new configuration becomes applicable for new calls only. The existing calls are not affected, for example UEs which are already configured to measure certain frequencies are not re-configured due to the changes in LTE490 configuration data. If LTE490 feature has already been enabled at eNB and there is no change in LTE490 configuration data but there is a change in the feature flag status, for example the flag is changed to “disabled”, the eNB stops using the LTE490 configuration data and uses the configuration provided by operator during configuration of separate mobility features for UE measurement configuration. This applies only to new calls, existing calls are not affected.

g

Note: •

•

4.9.3.2

Target frequencies may be configured in User Profile (MOPR) or Default Profile in advance with no corresponding LNADJ defined, so there is no need to check for existing neighbor cell objects with the according frequency. If neighbor cells are deleted or created, there is no need for the eNB to perform an automatic update of the User Profile (MOPR) or the Default Profile.

Licensing of SPID Selective Neighbor Cell lists SPID Selective Neighbor Cell lists is an optional feature which is, if enabled, activated for the whole eNB. In order to keep it activated, a license for the eNB is required. The license type is on/off. The license is handled by the management system. If activated, for mobility features eNB use only those target frequencies that are specified for a given mobility feature in Mobility Profile configured and assigned for SPID related to the handled UE. If deactivated, the eNB will use all target cells defined for each mobility feature, without any impact from Mobility Profiles.

4.9.3.3

Impact on measurement configuration The eNB restricts measurement objects from configuration in the UE if the corresponding carrier frequency is not assigned in the SPID mobility profile used by the UE. Interactions between RRM-CMC and C-Plane for supporting the SPID selective neighbour cell lists are: •

80

C-Plane indicates to HO Algorithm when feature LTE490 is switched on and informs HO Algorithm about the related SPID value, in order the Measurement Configuration can take the related Mobility Profile Instance (MOPR) into account. Only RATs and frequencies configured by operator in Mobility Profile are set to be measured.

© 2016 Nokia



•

When SPID mapping is not possible (for example no related instance in MOPR can be found), then Default Mobility Profile (MODPR) shall be taken into account while configuring Measurements. This is done in the following way : – –

4.9.3.4 4.9.3.4.1


If the autoAdapt flag in MODPR is set to true, then the Measurements are configured as if the feature LTE490 is disabled If the autoAdapt flag in MODPR is set to false, then RATs and frequencies configured in Default Mobility Profile (MODPR) are to be measured.

Mobility Profiles Management of Mobility Profiles A Mobility Profile represents a set of O&M configured target frequency layers for enabled LTE Inter-Frequency and Inter-RAT mobility functions like Handover, Network Assisted Cell Change. It can be seen as a filter on the configured neighbor cell information of an eNB. Furthermore, there is a Mobility Profile specific configuration of target frequencies for UE Redirection, Circuit Switched Fallback and Emergency Calls. eNB supports management of Mobility Profiles including a default profile via plan file and persistently stores profile information. Any creation, modification, or deletion of Mobility Profile Information is possible online without affecting service. Mobility profiles are only supported if the feature is enabled.

4.9.3.4.2

Mobility Profile Information Mobility Profile Information is stored in instances of the Object classes MOPR and MORED. Up to 8 Mobility Profiles are supported. For each profile MOPR up to six redirection target layers MORED are supported. Each Mobility Profile provides the following information: •

•

•

optional Frequency Layer List for LTE Inter Frequency Mobility. The EARFCN value(s) are used to filter for LNHOIF objects which are selected for UE measurement configuration. optional Frequency Layer List for Packet Switched Handover to WCDMA target cells. The UARFCN values are used to filter for LNHOW objects, which are used for UE measurement configuration. optional list of Reference Frequencies for Network Assisted Cell Change to GERAN. Each list element consists of band indicator and ARFCN value. The frequencies and band indicators in the list are used as references to cell specific LNHOG objects. An LNHOG object is selected for UE measurement configuration if a LNHOG frequency matches the reference frequency.

Each of the subordinate MORED instances provides the following information: • • • • • •


Redirection Priority for Circuit Switched Fallback with Redirection Redirection Priority for Emergency Call Redirection Priority for UE Context Release RAT for Redirection eUTRA frequency or UTRA frequency

© 2016 Nokia

81


• •


or GERAN ARFCN values list and GERAN band indicator or CDMA frequency and CDMA band

If a mobility profile is selected for a UE, the profile specific MORED configuration data applies instead of the cell specific REDRT configuration data. If one or more list frequency lists are not provided or if no MORED object is created, the related mobility type is not supported for the profile.

4.9.3.4.3

Default Mobility Profile Information The default profile applies if no Mobility Profile is assigned to a Subscriber Profile ID (SPID) or if no SPID value is provided for a UE. The default profile is represented by a single MODPR instance. The instance has to be mandatorily created by using the plan file if the feature is activated. The default profile provides the following information: • • • •

Flag for Automatic Adaptation to Frequency Layers of all Neighbor Cells optional Frequency Layer List for LTE Inter Frequency Mobility optional Frequency Layer List for Packet Switched Handover to WCDMA target cells optional list of Reference Frequencies for Network Assisted Cell Change to GERAN. Each list element consists of band indicator and ARFCN value. The frequencies and band indicators in the list are used as references to cell specific LNHOG objects. An LNHOG object is selected for a UE measurement configuration if a LNHOG frequency matches the reference frequency.

If 'Automatic Adaptation' is enabled, the overall neighbor cell configuration which provides the parameters of the MOCs (LNADJ-L/W/G, LNHO-/W/G/IF, REDRT) automatically is valid. No further changes are necessary. This also includes objects which are created after enabling. In this case no frequency layer lists need to be configured. If 'Automatic Adaptation' is disabled it is the responsibility of the operator to ensure that any neighbor cell frequency covered by at least one mobility profile including the default profile. Otherwise such neighbor cell would be never considered as a valid handover target cell. Each of the MODRED instances subordinate to MODPR provides the following information: • • • • • • • •

Redirection Priority for Circuit Switched Fallback with Redirection Redirection Priority for Emergency Call Redirection Priority for UE Context Release RAT for Redirection eUTRA frequency or UTRA frequency or GERAN ARFCN values list and GERAN band indicator or CDMA frequency and CDMA band

If the default profile is selected for a UE, the default profile specific MODRED configuration data applies instead of the cell specific REDRT configuration data. Online modification of the default profile via plan file is supported. If one or more list frequency lists are not provided or if no MODRED object is created, the related mobility type is not supported for the default profile. Deletion of the default profile is only accepted if the feature has been deactivated before by setting actSelMobPrf to 'false'. MODRED instance(s) are automatically deleted with the MODPR object

4.9.3.5

82

User scenarios

© 2016 Nokia



4.9.3.5.1


Acivation / Deactivation Subscriber profile based mobility Operator has to enable the feature by setting a corresponding O&M flag on BTS level and creating managed object class (MOC) instance for Default Profile with autoAdapt flag set to ‘true’ or with manual configuration of Default Profile. The operator should provide Mobility Profiles Object class instances and related mapping between configured profile and SPID values. With such prepared configuration plan file downloaded to the eNB, LTE490 will be activated in eNB software. It is possible to activate and deactivate the feature per eNB. A new, online modifiable LNBTS parameter actSelMobPrf (activate selective Mobility Profiles) is introduced. The feature is activated by setting the LNBTS parameter actSelMobPrf to ‘true’. The feature is deactivated by setting the LNBTS parameter actSelMobPrf to ‘false’.

4.9.3.5.2

Configuration of Mobility Profiles information The pre-condition for this configuration is that the feature LTE490 is enabled and corresponding mobility features, planned to be used inside Mobility Profile are enabled (LTE55 Inter-frequency handover; LTE56 Inter RAT handover to WCDMA; LTE442 Network Assisted Cell Change to GSM; LTE562 CSFB to UTRAN or GSM via redirect; LTE423 RRC connection release with redirect; LTE22 Emergency Call handling). The operator provides a new instance of Mobility Profile MOC configured per LNBTS level. For each used mobility type the operator can specify target frequencies to be used by the eNB. The operator provides mapping of SPID to the configured Mobility Profile instance. Mapping is done on LNCEL level. Multiple SPID values can be specified for one specific Mobility Profile. The configuration must allow to uniquely choose Mobility Profile for a given SPID value. The plan file with above configuration is sent to eNB.

4.9.3.5.3

Creation and assignment of new Mobility Profile This example shows a user scenario for the creation of a new Mobility Profile. UEs of operator B are allowed to connect to LTE cells of operator A. Both operators have their own WCDMA networks and operator A wants that UEs of operator B are handed over or are redirected to the WCDMA network of operator B as far as possible by radio conditions. • • • •

Operator A uses WCDMA frequency layer fa Operator B uses WCDMA frequency layer fb MME indicates UEs of operator B with SPID value “s” UEs of operator A are assigned to the default profile

The procedure describes the configuration activities from the viewpoint of operator A. Pre-conditions: • • • •


eNB has activated RNW database and is in service NetAct is in service and DCN connection to eNB is established via OMS The feature ‘SPID selective Neighbor Cell Lists’ is activated by setting the LNBTS parameter actSelMobPrf to ‘true’. WCDMA mobility functionality is activated by setting the according activation flag(s) to ‘true’.

© 2016 Nokia

83


1. 2. 3. 4.

g


actHOtoWcdma for Inter-RAT HO to WCDMA actCSFBRedir for Circuit Switched Fallback to WCDMA (optional) actEmerCallRedir for Emergency Call handling via redirection (optional) actRedirect for UE context release with redirection (optional)

Note: The mobility profiles and SPID assignments could be already created in advance, for example without feature activation, but the information would be ignored by eNB. Description: •

Operator edits delta plan file with at least the following content: 1. A new MOPR object is created for the WCDMA frequency layer of operator B (freqLayListPsHoWcdma = fb). 2. Handover parameters are configured for the WCDMA frequency layer of operator B by creating of an LNHOW object for frequency layer fb. 3. WCDMA neighbor cell objects (LNADJW) objects are created for ‘visible’ neighbor cells of operator B (uTargetFreq=fb). 4. Optional, mobility profile specific WCDMA redirection objects (MORED) may be created for UE context release with redirection, Circuit Switched Fallback and/or emergency calls (redirRAT=utraFDD, redirFreqUtra=fb). 5. For all affected LNCEL objects the SPID s is assigned to the newly created mobility profile (MOPR) via the parameter moPrMappingList.

g

• • • •

Note: If the default profile is created with autoAdapt set to 'true' it has to be modified, for example the parameter autoAdapt has to be set to 'false' and the default frequency layers have to be explicitly configured for frequencies of operator A, i.e. MODPR has to be modified to freqLayListPsHoWcdma = fa and parameters for other RATs and optional redirection targets set to operator A values

Operator downloads and activates the plan eNB persistently creates new objects or stores persistently the cell specific SPID assignment values eNB informs NetAct and BTS Site Manager about the changed configuration via notifications. eNB applies the mobility profile to new UEs

Post-condition: • • •

The new mobility profile settings are persistently stored in eNB eNB applies the mobility profile for all new NEs in the cell if MME indicates SPID value “s”. The default profile is applied for all UEs with no SPID value or a SPID value different from value “s”.

4.9.4 System impact Interdependencies between features Related inter-frequency and IRAT mobility features required and need to be enabled, for example:

84

© 2016 Nokia



• • • • • •


LTE22: Emergency Call Handling LTE55: Inter-frequency Handover LTE56: Inter RAT Handover to WCDMA LTE423: RRC Connection Release With Redirect LTE442: Network Assisted Cell Change To GSM LTE562: CSFB To UTRAN or GSM Via Redirect

Impact on interfaces This feature affects external interfaces as follows: •

•

New parameter Subscriber Profile ID for RAT/Frequency priority is supported for the following messages: - S1AP: INITIAL CONTEXT SETUP - S1AP: HANDOVER REQUEST - X2AP: HANDOVER REQUEST Parameter is not supported in S1AP: UE CONTEXT MODIFICATION message

Impact on MML commands There are no MML commands related to this feature. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.9.5 LTE490: Subscriber profile based mobility management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 44: New counters lists counters introduced with this feature. Table 44

Counter ID


New counters

Counter name

Measurement

M8023C12

Average Number of active UE of Mobilty Profile 1

LTE UE and Service Differentiation

M8023C13



M8023C14



M8023C15



© 2016 Nokia

85


Table 44



Counter ID

Counter name

Measurement

M8023C16



M8023C17



M8023C18



M8023C19



M8023C20

Average Number of active UE of Default Mobilty Profile



New parameters

Full name

Abbreviated name

Activate selective Mobility Profiles

actSelMobPrf

LNBTS

Mobility Profiles Mapping List (Table 46: moPrMappingList New parameters for the “Mobility Profiles Mapping List”)

LNCEL

Auto adaptation to freq. layers of all neighbor cells

autoAdapt

MODPR

Frequency Layer List for LTE Inter Frequency Mobility

freqLayListLte

MODPR

Frequency layer list for packet switched handover WCDMA

freqLayListPsHoWcdma

MODPR

Mobility default profile identifier

moDPrId

MODPR

Reference freq. list network assisted cell refFreqListNaccGeran change GERAN

86

Managed object

© 2016 Nokia

MODPR



Table 45



Full name


Abbreviated name

Managed object

Redirection Priority for CS Fallback with Redirection

csFallBPrio

MODRED

Redirection Priority for Emergency Call

emerCallPrio

MODRED

Mobility default profile identifier for redirection

moDRedId

MODRED

CDMA band

redirBandCdma

MODRED

CDMA frequency

redirFreqCdma

MODRED

eUTRA frequency

redirFreqEutra

MODRED

UTRA frequency

redirFreqUtra

MODRED

GERAN ARFCN values list

redirGeranArfcnValueL

MODRED

GERAN band indicator

redirGeranBandIndicator

MODRED

RAT for Redirection

redirRAT

MODRED

Redirection Priority for UE Context Release

redirectPrio

MODRED

Frequency Layer List for LTE Inter Frequency Mobility

freqLayListLte

MOPR

Frequency layer list for packet switched handover WCDMA

freqLayListPsHoWcdma

MOPR

Mobility profile identifier

moPrId

MOPR

Reference freq. list network assisted cell refFreqListNaccGeran change GERAN (Table 47: New parameters for the “Reference frequency list network assisted cell change GERAN”)

MOPR


csFallBPrio

MORED


emerCallPrio

MORED

Mobility profile identifier for redirection

moRedId

MORED

CDMA band

redirBandCdma

MORED

CDMA frequency

redirFreqCdma

MORED

© 2016 Nokia

87


Table 45



Full name

Abbreviated name

Managed object

eUTRA frequency

redirFreqEutra

MORED

UTRA frequency

redirFreqUtra

MORED



MORED



MORED

RAT for Redirection

redirRAT

MORED


redirectPrio

MORED

Table 46: New parameters for the “Mobility Profiles Mapping List” lists new parameters introduced wih this feature. Table 46

New parameters for the “Mobility Profiles Mapping List”

Full name

Abbreviated name

Managed object

Structure

Mobility Profile ID

moPrId

LNCEL

moPrMappingList

Subscriber Profile ID

spid

LNCEL

moPrMappingList

Last Subscriber Profile ID of a range

spidLast

LNCEL

moPrMappingList

Table 47: New parameters for the “Reference frequency list network assisted cell change GERAN” lists new parameters introduced wih this feature. Table 47

New parameters for the “Reference frequency list network assisted cell change GERAN”

Full name

88

Abbreviated name

Managed object

Structure

Band Indicator applied to bandIndicator Reference ARFCN

MOPR / MODPR

refFreqListNaccGera n

Reference ARFCN

MOPR / MODPR

refFreqListNaccGera n

referenceARFCN

© 2016 Nokia





Sales information

BSW/ASW



ASW

-

-

4.10 LTE518: Operator Specific QCI Introduction to the feature In addition to the standardized QCI characteristics of the 3GPP Release 8/9, an operator of a network is free to define QCI characteristics particular to the network in 3GPP. In other words, the operator has the freedom to implement proprietary QCI characteristics whose definitions are only known by and are really meaningful only to the network itself. It is thus possible that operators of different networks will implement different sets of QCI characteristics. Between two networks, the least common denominator known by both parties is the common standardized QCI characteristics implemented by both operators.In 3GPP Release 8/9, the QCIs used for standardized QCI characteristics are in the range 1…9. The QCIs for operator specific characteritics have been restricted to the range 128…254 to avoid conflicts if the range of QCIs for standardized QCI characteristics is extended in later 3GPP releases

4.10.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits An eNB can be shared by 2 or more operators, with different QCIs for each of them. For example ( 2 operators: A and B): • •

Operator A has configured QCI 140, 141, 142, 143 according his QoS requirements Operator B has configured QCI 160, 161, 162, 163 according his (different) QoS requirements

Another application of this feature is: The operator can define specific QoS-data for different user groups, for example: • • •

For bronze users: QCI 130, 131, 132, 133 For silver users: QCI 140, 141, 142,143 For gold users: QCI 150, 151, 152, 153.

4.10.2 Requirements Software requirements Table 49: Software requirements FDline lists the software required for this feature in the FDline.


© 2016 Nokia

89


Table 49

Release


Software requirements FDline

System release

RL relaese

eNodeB

RL30

RL30

LBTS3.0-

-

-

-


4.10.3 Functional description Functional overview The operator can define up to 21 additional QCIs for non GBR EPS bearers.The QCI value for each QCI is operator configurable in the range from 128 to 254. Each operator specific QCI is defined by at least the following set of parameters: • • • • • • • • •

QCI value RLC profile PDCP profile DRX profile (DRX functionality needs to be enabled scheduling weight logical channel group ID DSCP scheduling priority schedule BSD (bucket size duration)

The eNBs supports up to 6 non-GBR QCI groups to combine QCI specific performance counters. The mapping from the operator specific QCIs onto the QCI group performance counters is operator configurable. The eNB supports the following QCI values: • •

QCI values 1, 5...9 QCI values 128..254.

This feature is under license control and must be activated / deactivated.

4.10.4 System impact Interdependencies between features The feature LTE518: Operator specific QCI can only be activated if the feature LTE09: Service Differentiation has been activated. Impact on interfaces This feature impacts the following procedures: • •

EPS Bearer Establishment by S1AP: Initial Context Setup EPS Bearer Establishment by S1AP: E-RAB Setup Request

Parameters

90

© 2016 Nokia




This feature is managed by the parameters listed in Parameters.

4.10.5 LTE518: Operator Specific QCI management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 50: New Measurements lists measurements introduced with this feature. Table 50

New Measurements

Measurement ID 8023

Measurement Name


Measurement Description

LTE UE and Service Differentiation measures operator specific UE and Service Differentiation items.


New parameters

Full name


Abbreviated name

Managed object

Structure

Activate Support of Operator Specific QCIs

actOperatorQCI

LNBTS

-

PDCP Profile ID

PDCPprofileId

LNBTS

pdcpProf4

Status Report Required

statusRepReq

LNBTS

pdcpProf4

Timer Discard

tDiscard

LNBTS

pdcpProf4

PDCP Profile ID

PDCPprofileId

LNBTS

pdcpProf5

Status Report Required

statusRepReq

LNBTS

pdcpProf5

Timer Discard

tDiscard

LNBTS

pdcpProf5

Counter Group

counter group

LNBTS

qciTabOperat or

© 2016 Nokia

91


Table 51


Full name

92


Abbreviated name

Managed object

Structure

DSCP

dscp

LNBTS

qciTabOperat or

DRX Profile Index

drxProfileindex

LNBTS

qciTabOperat or

Logical Channel Group Identifier

lgcid

LNBTS

qciTabOperat or

PDCP Profile Index

pdcpProfIdx

LNBTS

qciTabOperat or

QoS Class Identifier

QCI

LNBTS

qciTabOperat or

QCI Support

qciSupp

LNBTS

qciTabOperat or

Resource Type

resType

LNBTS

qciTabOperat or

RLC Mode

rlcMode

LNBTS

qciTabOperat or

RLC Profile Index

rlcProfIdx

LNBTS

qciTabOperat or

Scheduling Bucket Size Duration

scheduleBSD

LNBTS

qciTabOperat or

Scheduling Priority

schedulPrio

LNBTS

qciTabOperat or

Scheduling Weight

schedulWeight

LNBTS

qciTabOperat or

Poll PDU

pollPDU

LNBTS

rlcProf4, rlcProf5

RLC Profile ID

rlcProfileId

LNBTS

rlcProf4, rlcProf5

Timer Poll Retransmit

tPollRetr

LNBTS

rlcProf4, rlcProf5

Timer Status Prohibit

tProhib

LNBTS

rlcProf4, rlcProf5

© 2016 Nokia




Table 51


Full name

Abbreviated name

Timer Reordering

tReord

Managed object

Structure

LNBTS

rlcProf4, rlcProf5

Table 52: Modified parameters lists parameters modified by this feature. Table 52

Modified parameters

Full name

Abbreviated name

Managed object

Structure

RLC Profile Index

rlcProfIdx

LNBTS


PDCP Profile Index

pdcpProfIdx

LNBTS



Sales information

BSW/ASW



ASW

-

-

4.11 LTE522: S1 Partial Reset Introduction to the feature The LTE522: S1 Partial Reset feature allows the eNB performing a bulk release of several UE-associated S1 signaling connections with one message exchange between the eNB and MME. The reset is used by O&M procedures, for example for automatic lock functionality: in an automatic lock, an eNB cell is deactivated, and all UEs served by the cell are released by the eNB according to the S1 partial reset procedure.

4.11.1 Benefits Operator benefits


© 2016 Nokia

93



The feature provides a performance-optimized release of UE-associated signaling connections in situations that require a simultaneous release of several UE-associated signaling connections of a cell, without collateral damage in other cells, for example in case of automatic lock. In addition, the eNB is able to handle several parallel S1 partial reset procedures per one S1 link, which minimizes delays in the clearing of UE-associated logical S1 connections.

4.11.2 Requirements Software requirements Table 54

Software requirements for different network elements

Network element

Required software release

System release

RL30

eNodeB

LBTS3.0

MME

-

SAE GW

-

UE

3GPP release 8

NetAct

–


4.11.3 Functional description The S1 Partial Reset can be triggered by the eNB or the MME. S1 Partial Reset triggered by eNB S1 partial reset triggered by the eNB occurs according to the following procedure (Figure 10: S1 Partial reset triggered by eNB)

94

© 2016 Nokia



Figure 10


S1 Partial reset triggered by eNB

UE UE

eNB

MME

UE 1.)!eNB!internal!trigger!to release!a!list!of!UE-associated logical!S1-connections

4a.)!RRC:!RRC!CONNECTION!RELEASE

2.)!S1AP:!RESET (UE-associated!logical!S1-connection!list) 3.)!Clear!all S1!resources!related to!the!impacted ‘UE-associated logical!S1-connections’

4b.)!L2!ACK 5.)!Clear!UE resources; remove!UE!context

6.)!S1AP:!RESET!ACKNOWLEDGE (UE-associated!logical!S1-connection!list)

1. In the eNB occurs a situation which requires the release of multiple UE-associated logical S1-connections. 2. The eNB triggers the S1 Partial Reset by sending the S1AP: RESET message to the MME including the impacted “UE-associated logical S1-connections”. 3. The MME clears all S1 resources related to “UE-associated logical S1-connections”. This includes also the impacted resources in S-GW. 4. For the impacted UEs which have a RRC connection available, the eNB releases the RRC connection. 5. If the RRC connection is released/no RRC connection is available, all resources of the impacted UEs are cleared. 6. The MME acknowledges the release of the affected connections. S1 Partial Reset triggered by MME S1 partial reset triggered by the eNB occurs according to the following procedure (Figure 11: S1 Partial reset triggered by MME)


© 2016 Nokia

95


Figure 11


S1 Partial reset triggered by MME

UE eNB

UE

MME

UE 1.)!MME!internal!trigger!to release!a!list!of!UE-associated logical!S1-connections 2.)!S1AP:!RESET (UE-associated!logical!S1-connection!list)

4a.)!RRC:!RRC!CONNECTION!RELEASE

3.)!Clear!all S1!resources!related to!the!impacted ‘UE-associated logical!S1-connections

4b.)!L2!ACK 5.)!Clear!UE resources; remove!UE!context

6.)!S1AP:!RESET!ACKNOWLEDGE (UE-associated!logical!S1-connection!list)

1. The MME requires the release of multiple UE-associated logical S1-connections. 2. The MME triggers the S1 Partial Reset by sending the S1AP: RESET message to eNB including the impacted “UE-associated logical S1-connections”. 3. The MME clears all S1 resources related to the “UE-associated logical S1connections” including affected resources in the S-GW. 4. For the impacted UEs which have a RRC connection available, the eNB releases the RRC connection. 5. If the RRC connection is released/no RRC connection is available, all resources of the impacted UEs are cleared. 6. The eNB acknowledges the release of the affected connections.

4.11.4 System impact Interdependencies between features This feature is not dependent on other features. Impact on interfaces The eNB-initiated S1 partial reset procedure involves new messages in the S1 interface: • •

S1AP:RESET message S1AP:RESET ACKNOWLEDGE message

Impact on system performance and capacity The feature has no impact on system performance or capacity.

96

© 2016 Nokia




4.11.5 LTE522: S1 Partial Reset management data For the information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

4.11.6 Sales information This feature belongs to the Base Software (BSW) product structure class and does not require a license or activation.

4.12 LTE570: Periodic UE measurements Introduction to the feature When this feature is activated on cell-level, all UEs served by that cell and provided with required capabilites are configured to make periodic intra-frequency measurements and measurement reports. If the feature is used in connection with Subscriber and equipment trace or Cell trace, the measurement reports can be forwarded to the NectAct for post-processing to give the operator more detailed information about UE and cell functionality for, for example, troubleshooting, capacity and resource optimization and quality control.

4.12.1 Benefits Operator benefits When used in connection with Subscriber and equipment trace or Cell trace, this feature benefits the operator by offering more detailed information about the functionality of a specific cell or the UEs served by a specific cell. By means of intra-frequency measurements, the UE reports power and quality-related information of the serving cell, and of the neighbor cell that it it is able to detect. These measurements provide the operator with information about radio coverage and interference without a need to run drive tests on the field. In subscriber and equipment trace, the periodic UE measurements provide additional information about subscribers and user equipment to help the operators resolve error situations or find out why a UE is malfunctioning, plan resource usage and capacity optimization or control radio frequency coverage and quality.


© 2016 Nokia

97





System release

RL30

eNodeB

LBTS3.0

MME

-

SAE GW

-

UE


NetAct

-

Hardware requirements This feature requires no new or additional hardwares.

4.12.3 Functional description When the feature is activated in the eNB and a cell belonging to the eNB is selected for periodic intra-frequency UE measurements, the UEs requested to make measurements start reporting RSRP and RSRQ signals of the serving and detected neighbor cells to the eNB, as often and as many times as defined by the operator. If the feature is used together with LTE163: Subscriber and equipment trace or LTE433: Cell trace, the measurement results are also made available in the NetAct for further processing. If the feature is used together with LTE492: Automated neighbor relation or LTE782: ANR fully UE-based, the eNB can add neighbor relations to the cell for which periodic UE measurement has been activated.

g

Note: LTE782: ANR fully UE-based uses the same measurement, ReportStrongestCells , as LTE570, but the measurement is configured in a different way for the two features. If both features are simultaneously active in the same cell, the LTE570-related settings defined for the measurement are applied.

4.12.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature affects interfaces as follows:

98

© 2016 Nokia



• •


The radio interface supports the intra-frequency periodical measurement ReportStrongestCells . The O&M interface supports the parameters in which the operator can define the measurement time interval and the number of reports to be generated.

Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity The value range of those configurable parameters which control the periodic UE measurements has been chosen so that the functionality has a minimum impact on the eNB performance. There is no reason to expect any significant degradation in the UE handover performance or data throughput even with the highest possible measurement report frequency.

4.12.5 LTE570: Periodic UE measurements management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters The measurement results are reported in a periodic measurement ReportStrongestCells. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 56

New parameters

Full name

Abbreviated name

Managed object

Structure

Activate MDT cell trace

actMDTCellTrace

LNBTS

-

Periodic UE measurements

periodicUeMeas

MTRACE

-

Report Amount

reportAmount

MTRACE

periodicUeM eas

Report Interval

reportInterval

MTRACE

periodicUeM eas

4.12.6 Sales information This feature belongs to the Application Software (ASW) product structure class. When the feature has been acquired, it has to be activated at cell level.


© 2016 Nokia

99


Table 57


Sales information

BSW/ASW



ASW

-

-

For activation instructions, see LTE570: Periodic UE Measurements Feature Activation Instructions.

4.13 LTE571: Controlled uplink packet segmentation Introduction to the feature Increased uplink cell edge performance by controlled uplink packet segmentation.

4.13.1 Benefits End-user benefits This feature benefits the end-user by improving performance at cell edge, which in turn improve user experience. Operator benefits This feature benefits the operator by providing a better cell edge performance.



System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

3GPP release 8

-


4.13.3 Functional description Functional overview The Flexi Multiradio BTS supports an uplink coverage improvement algorithm as an extension to the uplink link adaptation.

100

© 2016 Nokia




The coverage extension is achieved by controlling the uplink packet segmentation. This leads to an improvement of the coverage throughput; also PDCCH is more optimally utilized as a result of balancing new transmissions and retransmissions. The enhancement in coverage throughput comes at the cost of cell throughput. For a given modulation code scheme (MCS) as determined by the uplink link adaptation and configured transport block size (TBS), the uplink scheduler determines the PRB allocation. The uplink packet segmentation algorithm is controlled for cell edge UEs by using two O&M parameters: • •

the minimal transport block size (ulsMinTbs) the minimal PRB allocation (ulsMinRbPerUe)

Both parameters are operator configurable.

4.13.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.13.5 LTE571: Controlled uplink packet segmentation management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 59: New parameters lists parameters introduced with this feature.


© 2016 Nokia

101


Table 59


New parameters

Full name

Abbreviated name

Managed object

Minimum PRB allocation for UEs which are power limited

ulsMinRbPerUe

LNCEL

Minimum UL Transport Block Size

ulsMinTbs

LNCEL


Sales information

BSW/ASW



BSW

-

-

4.14 LTE572: IMS Emergency Sessions Introduction to the feature The feature LTE572: IMS Emergency Sessions is used to provide support for IMS (IP Multimedia Subsystem) emergency sessions for Release 9 (and beyond) UEs. Such a session uses an APN (Access Point Name) which is dedicated for emergency and comprises typically one bearer for SIP signaling and one bearer for VoIP to provide a voice connection between user and an emergency center. An IMS emergency session is established and kept with preference compared to normal sessions. While a normal session requires a valid subscription, successful authentífication and access to the selected cell and PLMN, an IMS emergency session in contrast may be accepted in spite of violating some of these conditions - it depends on local regulation requirements and operator policies. Such an UE is in the so called limited service state (LSS). Its acceptance is completely controlled by the EPC. This feature allows the admission of unauthenticated IMS emergency sessions. An emergency request from an UEis recognized by • •

RRC Connection Request message with establishment cause emergency, EPS bearer which ARP (Allocation and Retention Priority) value matches the per PLMN (Public Land Mobile Network) operator configurable ARP value reserved for emergency services.

The eNB admits all emergency sessions until operator configurable thresholds are reached, if the related QCIs (QoS Class Identifiers) and bearer combinations are enabled. Furthermore mixed sessions are allowed: An UE can perform an emergency session and a normal session at the same time.

102

© 2016 Nokia




Intra LTE mobility is completly supported, and inter RAT mobility is supported by connection release with redirect.

4.14.1 Benefits End-user benefits The end user can quickly establish an emergency session - without authentication, valid subscription. This feature allows the admission of unauthenticated IMS - Emergency sessions. Operator benefits The operator can offer IMS emergency sessions for LTE.



System Release

RL release

eNodeB

RL30

RL30

LBTS3.0

-

-

Hardware requirements This feature requires no new or addtional hardware:

4.14.3 Functional description Functional overview The following situations for establishing an emergency call are possible: 1. The UE is in a cell in normal service state: Attach in Normal Service State. The user switches on his UE and enters the correct PIN. When the UE is ready, the user enters 112. 2. The UE is in a cell in the limited service state (for example, no valid PIN available or the cell belongs to a different operator without any roaming agreement): Attach in Limited Service State. The user switches on his UE and enters for example 112 as PIN (possible for some types of UEs). The UE offers only emergency calls to the user because the UE is out of coverage of its operator. 3. The UE is switched on and is in idle-mode: EPS Bearer Establishment by S1AP: Initial Context Setup Procedure (Service Request for IMS Emergency calls). The user dials 112 to start an emergency call. 4. The UE is switched on and active: EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls. The user dials 112 to start an emergency call. Attach in Normal Service State The Attach in Normal Service State is identical to the normal Attach procedure (RRC establishment cause is set to "mo-signaling", but not to "emergency".


© 2016 Nokia

103



After the attach, the UE is in EMM_REGISTERED and RRC_CONNECTED state. The emergency call is then further handled like in the message sequence chart (MSC) EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls. Attach in Limited Service State Figure 12: Attach in Limited Service State shows the msc for an attach in LSS: Figure 12

Attach in Limited Service State

UE

eNB

MME

UE!is!EMM_REGISTERED!and!RRC_IDLE!Limited!Service!State (if!UE!is!RRC_CONNECTED!to!non-emergency!CN,!UE!releases!RRC!connection!before!starting!emergency!procedure)

BCCH!Broadcast!with ims-EmergencySupport “set!to „true“ User!initiates Emergency!Call and!selects!cell Random!Access!Procedure RRC:!RRCConnectionRequest (Random!ID,!RRC!Establishment!Cause „Emergency“)

RAC!(RRC!Connection) based!on!Emergency!!Cause

RRC: RRCConnectionSetup RRC:!RRCConnectionSetupComplete (selected!PLMN!ID!only,!Attach!with!EPS!Attach Type “EPS!emergency!attach“ )

S1AP:!INITIAL!UE!MESSAGE (Attach!with!EPS!Attach!Type “EPS!emergency attach“ Establishment!Cause „Emergency“ )

S1AP: INITIAL!CONTEXT!SETUP!REQUEST (Signaling!Bearer!with QCI5!and!Emergency!ARP, NULL!Security!Algorithms, NAS!Attach!Accept!with ACTIVATE!DEFAULT!EPS!BEARER!CONTEXT REQUEST!)

RAC!(UE,!non-GBR) based!on!Emergency!Cause RRC:!Security!Mode!Command (ciph.Algorthm=eea0,!int.port.Algorithm=eia!0-v90)

RRC:!UECapabilityEnquiry RRC:!Security!Mode!Complete RRC:!UECapabilityInformation RRC:!RRCConnectionReconfiguration (NAS:!Attach!Accept!with ACTIVATE!DEFAULT EPS!BEARER!CONTEXT!REQUEST!)

RRC:!RRCConnectionReconfigurationComplete RRC:!ULInformationTransfer (NAS:!ATTACH!COMPLETE!with!ACTIVATE DEFAULT!EPS!BEARER!CONTEXT!ACCEPT!)

S1AP:!INITIAL!CONTEXT!SETUP!RESPONSE S1AP:!UE!CAPABILITY!INFO!INDICATION S1AP:!UL!NAS!TRANSPORT (NAS: ATTACH!COMPLETE!with!ACTIVATE DEFAULT!EPS!BEARER!CONTEXT!ACCEPT)

Setup!of!Dedicated!Bearer!for Emergency!APN (QCI1) -!Details!see!MSC!in!RRC_CONNECTED!-

Here comes a short overview of the msc:

104

© 2016 Nokia



• • • • • • • •

The UE (newly) attaches to the EPC with NAS ATTACH REQUEST and attache type EPS Emergency Attach. The UE searches for an Acceptable Cell according to 3GPP 36.304 where the eNB signals its support of emergency sessions via system information. The UE starts the RRC Connection Setup Procedure with the RRC establishment causes emergency. The eNB handles the RRC Connection Setup with the following addition: The eNB prioritizes the RRC Connection based on the RRC establishment cause emergency. NAS ATTACH REQUEST is passed to a MME via the S1AP message Initial UE message. The MME selects a preconfigured APN and starts the Create Session procedure towards S-GW/selected PDN-GW (Public Data Network-Gateway). The PDN-GW initiates the establishment of a default (non-GBR) bearer with QCI 5 and emergency ARP used for SIP signaling. The eNB handles the Initial Context Setup Procedure identically to the normal Initial Context Setup Procedure with the following addition: – –

•


The eNB prioritizes the Initial Context Setup based on the RRC establishment cause emergency. The MME informs the eNB that the NULL algorithm is configured for ciphering and integrity protection.

The UE triggers the establishment of the setup of an emergency voice call - see EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls.

EPS Bearer Establishment by S1AP: Initial Context Setup Procedure (Service Request for IMS Emergency calls). Figure 13: EPS Bearer Establishment by S1AP: Initial Context Setup Procedure shows the EPS Bearer Establishment by S1AP: Initial Context Setup Procedure.


© 2016 Nokia

105


Figure 13


EPS Bearer Establishment by S1AP: Initial Context Setup Procedure UE

MME

eNB

UE!is!EMM_REGISTERED!and!RRC_IDLE!Normal!Service!State MME!has!sent „EPS!network!feature!support“ with „Emergency!bearer!services!in!S1!mode!supported“ during!Attach User!initiates Emergency!Call

Random!Access!Procedure

RRC: RRCConnectionRequest (S-TMSI,!establishmentCause „Emergency“) RAC(RRCConnection) basedonEmergencyCause

RRC: RRCConnectionSetup RRC: RRCConnectionSetupComplete (Selected_PLMN_Id,!RegisteredMME,!Service!Request)

Enhanced Initial Context Setup procedure for!Service Request

S1AP: INITIAL!UE!MESSAGE (NAS:!Service!Request,!Establishment!Cause „Emergency“)

S1AP: INITIAL!CONTEXT!SETUP!REQUEST (Set!of!EPS!Bearers!as!before!RRC_IDLE,!!all!with!any!ARP)

RAC!(UE,!non-GBR) based!on!Emergency!Cause RRC: Security!Mode!Command RRC: RRCConnectionReconfiguration RRC: Security!Mode!Complete RRC: RRCConnectionReconfigurationComplete S1AP:!INITIAL!CONTEXT!SETUP!RESPONSE Setup!of!Signalling!Bearer!for Emergency!APN (QCI!5)!and Setup!of!Voice!Bearer!for Emergency!APN (QCI!1) -!Details!see!Emergency!MSC!in!RRC_CONNECTED!-

When the user enters an emergency call number (like 112), the UE recognizes that an emergency call is initiated: • • • • • •

106

The UE sends a NAS SERVICE REQUEST to come back to ECM_CONNECTED state. The UE starts the RRC Connection Setup Procedure with the RRC establishment causes emergency. The eNB handles the RRC Connection Setup with the following addition: The eNB prioritizes the RRC Connection based on the RRC establishment cause emergency. The NAS SERVICE REQUEST is passed to an MME via the S1AP message Initial UE message. The MME triggers the Initial Context Setup Procedure for the already established EPS bearers. The eNB handles the Initial Context Setup Procedure identically to the normal Initial Context Setup Procedure with the following addition: The eNB prioritizes the Initial Context Setup based on the RRC establishment cause emergency.

© 2016 Nokia



•


The UE triggers the establishment of a new PDN connection for emergency sessions and the setup of an emergency call - see EPS Bearer Establishment by S1AP: ERAB Setup for IMS Emergency Calls.

EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls Figure 14: EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls shows the EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls. Figure 14

EPS Bearer Establishment by S1AP: E-RAB Setup for IMS Emergency Calls UE

MME

eNB

UE!is!EMM_REGISTERED!and!RRC_IDLE!Normal!Service!State MME!has!sent „EPS!network!feature!support“ with „Emergency!bearer!services!in!S1!mode!supported“ during!Attach User!initiates Emergency!Call RRC: ULInformationTransfer (NAS:!PDN!Connectivity!Request!with!request!type

S1AP:!UL!NAS!TRANSPORT

„Emergency“)

(NAS:!PDN!Connectivity!Request!with!request!type „Emergency“)

S1AP:!E-RAB!SETUP!REQUEST (Signaling!Bearer!with QCI5!and!Emergency!ARP, NAS:!ACTIVATE!DEFAULT!EPS!BEARER!CONTEXT!REQUEST)

RAC!(non-GBR) based!on!ARP E-RAB Setup for!QCI 5 EPS Bearer

RRC: RRCConnectionReconfiguration (NAS:!ACTIVATE!DEFAULT!EPS!BEARER CONTEXT!REQUEST!)

RRC: RRCConnectionReconfigurationComplete S1AP:!E-RAB!SETUP!RESPONSE RRC: ULInformationTransfer (NAS: ACTIVATEDEFAULT EPSBEARER CONTEXT ACCEPT)

S1AP:!UL!NAS!TRANSPORT (NAS:!ACTIVATE!DEFAULT!EPS!BEARER CONTEXT!ACCEPT)

SIP!Signalling!on!QCI5!(including!SIP!INVITE!(Priority=Emergency)) S1AP:!E-RAB!SETUP!REQUEST

E-RAB Setup for!QCI 1 EPS Bearer

RAC!(GBR) based!on!ARP

(Voice!Bearer!with QCI1!and!Emergency!ARP, NAS:!ACTIVATE!DEDICATED!EPS!BEARER CONTEXT!REQUEST)

RRC: RRCConnectionReconfiguration (NAS:!ACTIVATE!DEDICATED!EPS!BEARER CONTEXT!REQUEST)

RRC: RRCConnectionReconfigurationComplete RRC: ULInformationTransfer (NAS:!ACTIVATE!DEDICATED!EPS!BEARER CONTEXT!ACCEPT)

S1AP:!E-RAB!SETUP!RESPONSE S1AP:!UL!NAS!TRANSPORT (NAS:!ACTIVATE!DEDICATED!EPS!BEARER CONTEXT!ACCEPT)

Continuation!of!SIP!Signalling!on!QCI5 and!Voice!Call

When the user enters an emergency call number (like 112), the UE recognizes that an emergency call is initiated •


The UE sends the NAS PDU PDN CONNECTIVITY REQUEST with cause emergency to the MME.

© 2016 Nokia

107


• • •

• • •

•


The MME selects a preconfigured APN and starts the Create Session procedure towards S-GW/selected PDN-GW (Public Data Network-Gateway). The PDN-GW initiates the establishment of a new default (non-GBR) bearer with QCI 5 and emergency ARP used for SIP signaling. The eNB handles the establishment procedure identically to the normal E-RAB Setup Procedure with the following addition: The eNB prioritizes the non-GBR bearer at Radio Admission Control based on the emergency ARP. When the new default bearer has been established, the UE performs SIP signaling on this bearer to initiate the establishment of the emergency voice call. A PDN-GW initiates the establishment of the emergency voice (GBR) bearer with QCI 1 and emergency ARP. The eNB handles the establishment procedure identically to the normal E-RAB Setup procedure with the following addition: The eNB prioritizes the GBR bearer at Radio Admission control based on the emergency ARP. Finally, the SIP signaling is continued and the user is able to use the emergency voice call.

4.14.4 System impact Interdependencies between features The features • •

LTE7: Support of Multiple EPS Bearer, LTE10: EPS Bearers for Conversational Voice

are prerequisites for this feature and must be activated. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.14.5 LTE572: IMS Emergency Session management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 62: New counters lists counters introduced with this feature.

108

© 2016 Nokia



Table 62

Counter ID



New counters

Counter name

Measurement

M8000C32

E-RAB Setup Requests for IMS emergency sessions

The number of E-RAB Setup Requests for IMS emergency sessions

M8000C33

E-RAB Setup Completions for IMS emergency sessions

The number of E-RAB Setup Completions for IMS emergency sessions

M8000C34

E-RAB setup failures for IMS emergency sessions due to to missing RB (Radio Bearer) resources

The number of E-RAB setup failures for IMS emergency sessions due to to missing RB (Radio Bearer) resources

M8013C21

Number of Signalling Connection Number of Signalling Establishment attempts for emergency calls Connection Establishment attempts for emergency calls

M8013C26

Signalling Connection Establishment completions for emergency calls

The number of Signalling Connection Establishment completions for emergency calls

M8013C27

Signalling Connection Establishment failures for emergency calls due to missing RB (Radio Bearer) resources

Signalling Connection Establishment failures for emergency calls due to missing RB (Radio Bearer) resources

M8021C6

eNB HO Handover preparations for IMS emergency sessions

The number of Handover preparations for IMS Emergency Sessions. It comprises the intra and inter eNB Handover scenario.

M8021C9

Failed eNB HO Handover preparations for IMS emergency sessions

The number of failed Handover preparations for IMS Emergency Sessions. It comprises the intra and inter eNB Handover scenario.

M8021C12

eNB HO Handover attempts for IMS emergency sessions

The number of Handover attempts for IMS Emergency Sessions. It comprises the intra and inter eNB Handover scenario.

M8021C15

Successful eNB HO Handover completions for IMS emergency sessions

The number of successful Handover completions for IMS Emergency Sessions. It comprises the intra and inter eNB Handover scenario.

© 2016 Nokia

109




New parameters

Full name

Abbreviated name

Managed object

Structure

Activate Support of IMS Emergency Sessions for Release 9

actIMSEmerSessR9

MRBTS/LNBTS

IMS Emergency PLMN Configurations

imsEmerPlmnConfig

MRBTS/LNBTS

Emergency Sessions ARP

emerSessArp

MRBTS/LNBTS

imsEmerPlmn Config

Emergency Sessions Limited Service Mode Support

emerSessLimServ

MRBTS/LNBTS

imsEmerPlmn Config

Emergency Sessions MCC

emerSessMcc

MRBTS/LNBTS

imsEmerPlmn Config

Emergency Sessions MNC

emerSessMnc

MRBTS/LNBTS

imsEmerPlmn Config

Emergency Sessions MNC Length

emerSessMncLen

MRBTS/LNBTS

imsEmerPlmn Config


Sales information

BSW/ASW



ASW

-

-

4.15 LTE616: Usage based PDCCH adaptation Introduction to the feature The number of OFDM symbols used for PDCCH is adapted to the required amount of CCEs (control channel elements).

110

© 2016 Nokia




4.15.1 Benefits Cell capacity is increased in cases where not all available PDCCH resource are needed. Subscribers may experience higher throughput in downlink in typical scenarios with low load on PDCCH and high utilization of PDSCH.


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30 EP

-

-

-

-

-


4.15.3 Functional description The Flexi Multiradio BTS automatically adapts the number of OFDM symbols used for PDCCH. The information is broadcasted every TTI via PCFICH.The adaptation is based on CCE blocking and used CCE (control channel elements). Additionally, the balance between the PDCCH space used for DL and for UL may be adapted depending on the current load split. The UL/DL PDCCH space balance is adapted in any case when required amount of resources due to different load on PDSCH and PUSCH differs from the configured value.

4.15.3.1

Related parameters Activate load adaptive PDCCH The operator can activate or deactivate LTE616: Usage based PDCCH adaptation by setting the parameter actLdPdcch to True or False respectively. The actual OFDM symbol amount used for PDCCH in a TTI is selected from values between the minimum reasonable amount of symbols for the selected DL bandwidth and maximum allowed number of PDCCH symbols (maxNrSymPdcch). The parameter actLdPdcch can be set to True if all of the following condition are fulfilled: • •

phichDur is set to Normal (PHICH is transmitted in the first OFDMA symbol) maxNrSymPdcch value is greater than 1

If actLdPdcch is set to False, configured UL and DL split of PDCCH resources (pdcchUlDlBal) is used as a fix value.


© 2016 Nokia

111



If actLdPdcch is set to True, UL and DL split of PDCCH resources is adjusted runtime based on load; the configured value of the pdcchUlDlBal parameter defines the initial starting point. PDCCH LA UL DL allocation balance initial value The parameter pdcchUlDlBal determines initial value of the PDCCH allocation balance constant between uplink and downlink. The Load Adaptive PDCCH algorithm optimizes the value depending on the actual load distribution between DL and UL. The Load Adaptive PDCCH algorithm optimizes the value depending on the actual load distribution between DL and UL. The PDCCH UE-specific search space capacity is divided into uplink and downlink based on the parameter before dynamic scheduling.

4.15.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces The feature affects signaling on PCFICH and thus size of PDDCH and PDSCH. The impact is in both cases usage dependent. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity The long-term average throughput is improved in scenarios with high PDSCH usage.

4.15.5 LTE616: Usage based PDCCH adaptation management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 66: New counters lists counters introduced with this feature. Table 66

Counter ID

112

New counters

Counter name

Measurement

M8011C59

Number of subframes with 1 OFDM symbol allocated to PDCCH

LTE Cell Resource (WBTS)

M8011C60

Number of subframes with 2 OFDM symbols allocated to PDCCH


© 2016 Nokia



Table 66



Counter ID M8011C61

Counter name

Measurement

Number of subframes with 3 OFDM symbols allocated to PDCCH



New parameters

Full name

Abbreviated name

Activate Load Adaptive PDCCH

Table 68

actLdPdcch


Modified parameters

Full name

Abbreviated name

PDCCH LA UL DL allocation balance initial value

pdcchUlDlBal


Table 68: Modified parameters lists existing parameters related to this feature.


Sales information

BSW/ASW



ASW

-

-

4.16 LTE619: Interference aware UL scheduling Introduction to the feature Uplink interference aware scheduling that does not require any communication via X2.


© 2016 Nokia

113



4.16.1 Benefits The feature provides an improved uplink cell edge performance in low loaded networks.


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-



Feature overview With the LTE619: Interference aware UL scheduling the eNodeB provides improved cell edge performance in UL for low loaded cells. For that purpose the eNodeB measures the interference plus noise power distribution over the PUSCH spectrum and evaluates the TX power density measurements of the UEs. On basis of these measurements the interference aware UL scheduler arranges the PUSCH PRB allocation of the UEs in the frequency domain so that the resource allocation or rather the interference to the adjacent cells is optimized without the means of eNodeB intercommunication via X2. The separation is achieved by assigning the UEs which have huge TX power density to the PUSCH scheduling area which is less affected by interference and noise. The feature can be enabled by setting the ulsSchedMethod parameter to interference aware. The interference aware UL scheduling is an alternative scheduling approach to the channel unaware UL scheduling, which can also be selected using the same parameter (setting the ulsSchedMethod to channel unaware).

114

© 2016 Nokia



Figure 15


PRB allocation of the UEs PRBs eNodeB measured interference

PUSCHschedulingarea withlowinterference

remainingPUSCH schedulingarea

4.16.3.2

Detailed description The general principle of the Interference aware UL scheduling is the separation of the PRB allocation in the adjacent cells, in particular the separation of the PRB from UEs generating huge intercell interference. The PUSCH is split into PUSCH scheduling areas of approximately equal size. The scheduler defines the best PUSCH scheduling area with respect to the average interference and noise power. For the selection of the preferred scheduling area, the interference aware UL scheduler evaluates the interference and noise power which is measured per PRB by the physical layer (Layer 1) of the eNodeB. The power headroom report (PHR) and finally the number of PRBs which are involved by the UL transmission give the information about the TX power density the UE provides for the UL transmission. The power density increases proportionally to the distance from the eNodeB and achieves the maximum when the UE is close to the cell edge (the higher the power density the higher the intercell interference the UE contributes to the adjacent cells), thus, the power density provides the parameter the interference aware scheduler requires for the scheduling of the UEs in the frequency domain. The UEs with a higher TX power density are assigned to the preferred scheduling area and the UEs with a lower TX power density are placed in the remaining PUSCH area.

4.16.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.


© 2016 Nokia

115



4.16.5 LTE619: Interference aware UL scheduling management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 71: New parameters lists parameters introduced with this feature. Table 71

New parameters

Full name

Abbreviated name

Scheduling method of the UL scheduler

ulsSchedMethod


If ulsSchedMethod is set to interference aware, ulsFdPrbAssignAlg must be set to RoundRobinFD. If ulsSchedMethod is set to interference aware, ulsFdPrbAssignAlg must be set to Mixed FD. if ulsSchedMethod is set to channel aware or interference aware, Periodic PHR timer (PeriodicPhr) must be set to value different from infinity.


Sales information

BSW/ASW



ASW

-

-

4.17 LTE735: RRC Connection Re-establishment Introduction to the feature RRC Connection Re-establishment is supported as preferred resolution for temporary RL failure or due to physical link failure during handover.

116

© 2016 Nokia




4.17.1 Benefits Operator benefits Improved user experience exceptionally poor radio conditions.


Release


System Release

eNode B

NetAct

MME

SAE GW

RL30

LBTS3.0

-

-

-


4.17.3 Functional description Functional overview The Flexi Multiradio BTS supports the RRC Connection Re-establishment procedure. The procedure is initiated by the UE in “RRC connected” in case of: •

Radio link failure detection due to, for example: – – –

• • •

expiry of the timer T310 (timer started after detection of physical layer problem) random access problem indication from MAC indication from RLC that the maximum number of retransmissions has been reached

Handover failure (T304 expiry) Integrity check failure indication from the lower layers RRC connection reconfiguration failure

The UE sends for the initiation of the procedure, an integrity checked RRC:RRConnectionReestablishmentRequest message to the evolved eNB. The eNB checks whether it still has a valid UE: • •

in a source cell which becomes the serving cell or in a prepared target cell which becomes the serving cell

and sends in case of a positive response a RRC:RRCConnectionReestablishment message to the UE for resuming the SRB1 and security. The UE confirms the message with a RRC:RRCConnectionReestablishmentComplete message. The eNB subsequently re-establishes the SRB2 and DRBs. The following counters are provided to track the performance: •


Number of RRC Connection Re-establishment attempts

© 2016 Nokia

117


• • • • •

4.17.3.1


Number of successful RRC Connection Re-establishment procedures RRC Connection Re-establishment attempts per cause (Handover Failure) RRC Connection Re-establishment success per cause (Handover Failure) RRC Connection Re-establishment attempts per cause (Other Failure) RRC Connection Re-establishment success per cause (Other Failure)

RRC Connection Re-establishment RRC Connection Re-establishment Procedure (RRC Re-establishment) can be initiated by the UE for different reasons during an ongoing intra-LTE handover, inter-RAT handover or eNACC to GSM. In case RRC Re-establishment was caused by Radio link failure or T304 expiry eNB will accept the RRC Re-establishment if the UE enters the source cell or a prepared target cell. In case the UE tries to enter an unprepared cell or the RRC Re-establishment was caused by a configuration error the eNB will not accept RRC Re-establishment. Acceptance of RRC Connection Re-establishment in the source cell of a handover In general it can happen during any mobility procedure (for example intra-LTE handover, inter-RAT handover or eNACC) that UE fails to execute the procedure, performs cell selection and initiates RRC Re-establishment procedure towards the source cell where the mobility procedure has been started. The general handling in eNB follows the list below: •

•

•

Decide whether the UE shall be allowed performing RRC Re-establishment towards the source cell. This requires the UE to be clearly identified (including intergrity check), UE context is still available in source cell and the UE tries to enter the source cell with the original configuration from the source cell. The RRC Re-establishment procedure is executed on the air interface followed by an RRC Connection Reconfiguration procedure to re-establish SRB2 and DRB. The measurement gaps for inter-Rat and Inter-frequency handover have to be reconfigured, if they were configured before the re-establishment. Finally the ongoing mobility procedure is canceled. This cancellation depends on the type of mobility procedure which is ongoing. It might either be eNB-internal or may require cancellation procedures towards Target eNB via X2 or towards MME.

Rejection of RRC Connection Re-establishment in the source cell of a handover The RRC Connection Re-establishment Request by the UE will not always be acceptable by the source cell. The reasons may be: • •

reason for RRC Re-establishment was "reconfiguration failure” UE has already applied configuration for the target cell

The general handling in eNB follows the list below: • • •

118

eNB decides to reject the RRC Connection Re-establishment request and sends the rejection message towards the UE eNB initiates a UE Context Release procedure towards the MME to inform the MME that the UE was sent to idle depending on the type of the mobility procedure eNB needs to cancel the ongoing mobility procedure. Especially for X2-handover eNB has to inform its peer via X2 signaling the ongoing handover shall be canceled. In case of S1-based handover

© 2016 Nokia




procedures no explicit cancellation is needed as the MME does not need an explicit cancellation of the S1-handover in addition to the UE Context Release. For other mobility procedures eNB internal actions will be sufficient. Acceptance of RRC Connection Re-establishment in the target cell of a handover In general it can happen during any mobility procedure (for example intra-LTE handover, inter-RAT handover or eNACC) that UE fails to execute the procedure, performs cell selection and initiates RRC Re-establishment procedure towards the target cell which has already been prepared. Only cases where the target cell is an LTE Cell are considered.The general handling in eNB follows the list below: •

•

•

Decide whether the UE shall be allowed performing RRC Re-establishment towards the target cell. This requires the UE to be clearly identified (including intergrity check), UE Context is already prepared in target cell. the RRC Re-establishment procedure is executed on the air interface followed by an RRC Connection Reconfiguration procedure to reestablish SRB2 and DRB. The measurement gaps for inter-Rat and Inter-frequency handover have to be reconfigured, if they were configured before the re-establishment. finally the ongoing mobility procedure is continued from the point in time at which target cell would have received RRC Connection Reconfiguration Complete message in the same way as if the UE joined the target cell for a regular handover

Rejection of RRC Connection Re-establishment in the target cell of a handover The RRC Connection Re-establishment Request by the UE will not always be acceptable by the target cell. The reason may be: •

reason for RRC Re-establishment was "reconfiguration failure"

The general handling in eNB follows the list below: • •

4.17.3.2

eNB decides to reject the RRC Connection Re-establishment request and sends the rejection message towards the UE eNB initiates a UE Context Release procedure towards the MME to inform the MME that the UE was sent to idle.

RRC connection Re-establishment procedure The connection Re-establishment succeeds only if the concerned cell is prepared, this means that it has a valid UE context. The procedure is preceded by the two first messages of contention-based random access procedure, which transmits the Timing Alignment information, initial UL grant and assignment of temporary C-RNTI. The UE starts the Re-establishment procedure by sending an RRC: RRC CONNECTION RE-ESTABLISHMENT REQUEST message on CCCH to the eNB. The eNB checks, if context (on C-Plane level) exists for the UE, based on the identity sent by the UE and performs the authentication. If both steps are successful the procedure will be continued, only if the following conditions apply, eNB has to check, if: • •


the Re-establishment Cause is set to “otherFailure” no RRC, X2AP or S1AP procedure is ongoing (including those cases when a reestablishment is already running or a UE context release was triggered by eNB).

© 2016 Nokia

119


•


the physical Cell Identity, received with the RRC: RRC CONNECTION REESTABLISHMENT REQUEST message, matches the current cell identity.

If any of these conditions fails, the eNB rejects the re-establishment. Before doing this, the eNB terminates any ongoing RRC or S1AP procedure with the corresponding failure message, and requests the MME to release the UE context. In case of any ongoing S1AP or RRC procedure the RRC Connection Re-establishment Request is accepted, if the re-establishment cause is set to “otherFailure” and serving cell is the source cell. The ongoing procedure can be repeated or completed before or after the re-establishment was done, dependently on the progress of the procedure. In case of an ongoing Initial Context Setup procedure, re-establishment is rejected an the ongoing procedure is aborted. The UE indicates Radio link failure in the RRC: RRC CONNECTION REESTABLISHMENT REQUEST message with the IE ReestablishmentCause set to "other failure". The same cause value is used in case of integrity check failure. The eNB cannot distinguish between both failure cases, for example the same handling takes place. The eNB suspends operations for all RBs originally used, except SRB0 (SRB1, SRB2 and all established DRBs). The next steps are: • • • •

configuration of MAC of new C_RNTI creation of new entities for RLC with the same parameter settings used at Bearer Setup creation of new PDCP entry and switching data queue from old to new PDCP. activation of Security

The eNB responds by sending an RRC: RRC CONNECTION RE-ESTABLISHMENT message on CCCH message to the UE. On UE side SRB1 function is resumed, but operation for all other RBs remains suspended. UE re-activates security and sends back RRC: RRC CONNECTION RE-ESTABLISMENT COMPLETE message on SRB1, DCCH to the eNB. After receiving the RRC: RRC CONNECTION REESTABLISHMENT COMPLETE message eNB resumes SRB1 and initiates RRC connection reconfiguration procedure to resume SRB2 and all DRBs on UE and eNB side, and to reconfigure measurements gaps, in case inter-frequency or Inter Radio Access Technology (IRAT) measurements were running before the re-establishment. After successful execution of the reconfiguration procedure, U-Plane is triggered to start DL and UL transfer on SRB2 and DRBs. In case the Re-establishment procedure was unsuccessful, the eNb takes care, that a retry of the Re-establishment procedure is rejected. Determination of UE Configuration in Serving and target cell at RRC Connection Re-establishment If eNB receives the RRC message RRC Connection Re-establishment Request the eNB compares the c-RNTI and phycellId in this message with UE context data.The UE has the configuration based on current cell if: • •

The phycellId of the Re-establishment message matches the phycellId of the current cell. The c-RNTI of the Re-establishment message matches the c-RNTI of one UE context of the current cell.

Without ongoing handover, this case happens if: •

UE enters the serving cell with the current configuration (Serving cell config case)

During an ongoing handover, this case happens if:

120

© 2016 Nokia



• •


UE enters the source cell with the (old) source configuration (Serving cell config case) UE enters the target cell with the (new) target configuration (Target cell - target config case)

The UE has the configuration based on source cell at handover if there is a UE context for which: • •

The phycellId of the re-establishment message matches the phycellId of the source cell (AS-Context - Re-establishmentInfo - sourcePhysCellId). The c-RNTI of the re-establishment message matches the c-RNTI allocated in the source cell (AS-Config - sourceUE - identity)

During an ongoing handover, this case happens if: •

4.17.3.3

UE enters the target cell with the (old) source configuration (Target cell - source config case)

Support of RRC Connection Reconfiguration Procedure for Reestablishment in Serving Cell The eNB supports the RRC Connection Reconfiguration procedure during reestablishment in the serving cell - especially resuming SRB2 and all DRBs. A RRC Connection Reconfiguration needs to be sent after the RRC Connection Reestablishment procedure to resume traffic on SRB2 and DRBs.

4.17.3.4

RRC Connection Re-establishment procedure successful case The successful case of the RRC Connection Re-establishment procedure is supported.

4.17.3.5

PDCP eNB supports PDCP functionality for RRC connection Re-establishment.

4.17.3.5.1

eNB supports PDCP data transmission suspension A PDCP entity of the eNB suspends downlink data transmission for a radio bearer by request from upper layer. In case of an RRC Connection Re-establishment procedure, accepted by the eNB, downlink data transmission of radio bearers SRB2 and all data radio bearers (DRB s) is suspended.

4.17.3.5.2

eNB supports PDCP data transmission resumption A PDCP entity of the eNB resumes downlink data transmission for a radio bearer by request from upper layer.

4.17.3.5.3

eNB supports PDCP entity Re-establishment The eNB re-establishes a PDCP entity by request from upper layer. In case of an RRC Connection Re-establishment procedure, the PDCP entities of SRB1, SRB2 and DRBs are re-established. A PDCP entity associated to a certain mode of RLC entity (TM/UM/AM) is re-established.


© 2016 Nokia

121


4.17.3.5.4


eNB supports PDCP Re-establishment procedure. For the re-establishment PDCP performs the same procedure upon handover and upon RRC Connection Re-establishment, for example lossless behavior for AM RLC DRBs. The PDCP Re-establishment procedure is triggered by higher layer (L3) with provision of two indications to PDCP entities: first to initiate the 2-phase PDCP Re-establishment procedure, second to complete the procedure (if applicable). The PDCP handles both triggers and performs the correct actions. - DL Data transfer - UL Data Transfer

4.17.3.5.5

MAC reconfiguration, MAC reset, and MAC error handling of unknown, unforeseen and erroneous protocol data MAC procedures for reconfiguration, reset, and handling of unknown, unforeseen, and erroneous protocol data is supported by eNB.

4.17.3.5.6

MAC Reconfiguration for RRC Connection Re-establishment By request of the RRC a MAC entity of a UE is reconfigured.

4.17.3.6 4.17.3.6.1

Access Stratum Security Support of key refresh at RRC connection Re-establishment to serving/source or target cell The eNB supports the refresh of the eNB key hierarchy at RRC connection Reestablishment to serving cell as well as to source cell.

4.17.3.6.2

Security handling of RRC connection Re-establishment If a UE decides to try RRC connection Re-establishment, the following steps regarding security happen: •

g

122

The UE transmits on SRB0 a RRC: CONNECTION RE-ESTABLISHMENT REQUEST message to the cell it selected for requesting RRC connection Reestablishment. This cell shall be called requested cell, and its controlling eNB requested eNB. The message contains a UE-Identity which tells the last serving cell from UE point of view, that is the cell in which the trigger for RRC reconnection occurred, to the eNB. This cell shall be called “serving cell” and its controlling eNB “serving eNB”. Note: The serving cell is defined from UE point of view. Usually the point of view, if UE or network, does not matter, because UE and network are synchronized, but a broken RRC connection may cause different assumptions for UE and eNB about serving cell. At RRC connection Re-establishment, the network will adapt its serving cell assumption to UE. The UE-Identity is called related to the eNB which controls the reported physical (=serving) cell.

© 2016 Nokia



•

Note: The term "requested" for RRC connection Re-establishment, and "target" for handover. The RRC CONNECTION RE-ESTABLISHMENT REQUEST message cannot be authenticated by PDCP MAC-I integrity protection, because it transmits across SRB0. Instead, the requested eNB checks the authentication of the received UEIdentity by comparing a received authentication code, which is contained in the UEIdentity IE and is called short MAC-I, with an authentication code calculated by the network. Each cell which shall be enabled to authenticate a RRC reestablishment request message applies a dedicated short MAC-I, because this code is bound to a cell. The following cases may happen: –

– –

–

•

If the serving cell is controlled by the same eNB as the requested cell, the authentication on network side is an internal matter of the requested eNB and may happen on demand. If the serving cell is controlled by a different eNB as the requested cell, the authentication on network side is the matter between the two eNBs The calculation of the network side authentication code happens on the serving eNB, because it requires the RRC integrity protection key (KRRCint) of the serving cell. The comparison of the authentication codes happens on the requested eNB, because it got the short MAC-I from the UE. The calculation of a set of short MAC-I and the delivery to another eNB happens at course of a handover preparation. A RRC connection Re-establishment is only possible to an eNB which knows some UE-context information, this is a prerequisite not only, but also, motivated by security issues. Therefore, a requested eNB must either contain the serving cell (above bullet) or already be prepared for a handover from the serving cell, that is contain a handover target cell (this bullet) for the UE. Otherwise, the RRC: connection Re-establishment request will fail. The requested cell is controlled by the same eNB as the serving cell, if the UEIdentity is related to the requested eNB, for example if the physical cell identity reported by the UE-Identity belongs to the requested eNB.

If the RRC connection Re-establishment request is accepted, both UE and eNB will refresh their AS key hierarchy in the same way as for handover from the serving cell to the requested cell, however always keeping the security algorithms of the serving cell. The possible cases are the same as for authentication: –

–

–

–



If the serving cell is controlled by the same eNB as the requested cell, the reestablishment procedure is on network side an eNB internal matter. In particular, the key refresh works like for intra-eNB handover or, if the requested cell is equal to the serving cell, by intra-cell AS security maintenance. If the serving cell is controlled by a different eNB as the requested cell, the reestablishment procedure is on network side a matter between two eNBs. In particular, the key refresh works like for inter-eNB handover, according to the handover type which prepared the target cell. In case of X2 handover, the source eNB needs to calculate a dedicated KeNB for each cell which supports a re-establishment and to signal it to target eNB at course of handover preparation. This is similar to the short MAC-I provision described above. In case of S1 handover, the target eNB derives the fresh KeNB from a NH parameter received from MME. Because the NH is independent from cell, nothing special for re-establishment support is needed (however, there is still the limitation by cell dedicated short MAC-Is).

© 2016 Nokia

123


•

In any case, the UE needs to know the NCC parameter for key refresh. It will be signaled by the RRC CONNECTION REESTABLISHMENT message. This message is unprotected, because it transmits across SRB0 SRB1 (and all later by RRC connection reconfiguration procedure added bearers) will apply the fresh keys immediately. From UE point of view the RRC connection Re-establishment procedure is independent from handover. The UE always sends its request to a selected cell and, if it was accepted, refreshes its AS keys in exactly the same way according to the received NCC parameter. From the network point of view the RRC connection Reestablishment procedure depends on handover: –

–

4.17.3.6.3


If no handover is prepared, a RRC connection Re-establishment can only succeed to the serving (this time from network point of view) eNB, because no other eNB knows the UE context. Also, the UE and network must share their assumptions about the serving eNB (but the serving cells may differ). If a handover is prepared, a RRC connection Re-establishment can succeed to both the source and to the target eNB, because they know the UE context. The handover source eNB can always expect to be addressed as serving eNB, there is no difference (besides the names) to the "no handover" case above. In contrast, the handover target eNB can be addressed either as serving eNB or not. If it is addressed as serving eNB, the UE regards the handover as completed. Otherwise, the UE regards the handover either as incompleted or was not aware of it at all, and will report the source cell as the serving cell.

Connection Re-establishment of a related UE This procedure happens, if the UE tries reconnecting to the serving eNB. With respect to security, it does not matter, if a handover is ongoing or not. The UE can request the serving cell or any other cell of the eNB, but the security handling is independent, too. In any case, the eNB will locally retrieve or derive the needed information from UE context, which are a shortMAC-I for authentication, and, if the authentication succeeded, the AS security algorithms (becomes requested cell security algorithms) and a fresh KeNB together with its related NCC. If a related UE reconnects during handover to a target eNB, the UE regards the corresponding handover as completed and the eNB as serving eNB.

4.17.3.6.4

Authentication check for RRC CONNECTION Re-establishment REQUEST message in case of Null integrity protection In case of null integrity protection (EIA0), the authentication of a received RRC CONNECTION REESTABLISHMENT REQUEST message is skipped and regarded as successful.

4.17.3.6.5

Key refresh at RRC connection Re-establishment to serving/source or target cell In case of an accepted RRC connection reestablishment request message, which is limited to serving cell and during handover to source cell and target cell for this requirement, the key hierarchy needs to become fresh, but without changing the security algorithms. The old AS key hierarchy from which the derivation happens (and which security algorithms is inherited) is part of the context which is identified by the UEIdentity:

124

© 2016 Nokia



•

•

•

•


If the UE-Identity is related to the requested eNB, for example if the reported physical cell identity belongs to it, the requested cell must be the serving cell, or during handover, the source or target cell. This can be determined by the reported C-RNTI, which is either a part of a serving/source cell context or part of a target cell context. If the UE-Identity identifies the serving or source cell context, the key hierarchy refresh happens from serving/source security context. Note: If the requested cell is a target cell (which may happen in case of intra-eNB handover or intra-cell handover), the already for handover prepared fresh KeNB can be applied like for the not related UE-Identity case below. If the UE-Identity identifies the (by handover prepared) target cell context, the key hierarchy refresh happens, but from the KeNB which was prepared by handover and it applies the security algorithms which should be applied after handover. Note: Above case of related UE-Identity with target cell happens, if a target eNB regards the handover as still ongoing, but the UE regards it as already completed. The case of target cell with not related UE-Identity is described below. If the UE-Identity is not related to the requested eNB, for example if the reported physical cell identity does not belong to it, the requested cell must be a handover target cell. The UE-Identity defines the source cell context, and the eNB applies the already for handover prepared fresh KeNB. The AS derived keys are derived from this KeNB, applying the source cell algorithms reported by the sourceSecurityAlgorithmConfig IE which is included in the RRC context container. Note: If the handover preparation did not change the security algorithms, the already prepared complete AS key hierarchy may be used for reestablishing.

In any case, the NCC (of the fresh KeNB) are placed into the RRC CONNECTION REESTABLISMENT message.The handling of RRC connection Re-establishment to a handover target cell depends on the UE-Identity relationship. If it is not related to the requested eNB, the already for handover prepared KeNB is used. Otherwise, less likely but possible, a fresh KeNB needs to be derived from handover prepared KeNB. A RRC connection Re-establishment will always satisfy a deferred key refresh, either by a fresh key hierarchy or by context release. RRC connection Re-establishment does not support (by 3GPP) a change of the security algorithms. This is the reason to be sticky as required by the "additional criteria", which works best if all algorithms of similar strength got assigned the same priority.

4.17.3.6.6

Parameters of RRC CONNECTION Re-establishment message This message is sent from eNB to UE at accepted RRC connection Re-establishment. The eNB configures the security parameters.

4.17.3.6.7

RRC connection Re-establishment reject due to keystream reusage If the UE tries a RRC connection Re-establishment with the source cell UE-Identity to the handover target cell after reception of the handover related RRC: CONNECTION RECONFIGURATION COMPLETE message, the request is rejected by RRC: CONNECTION REESTABLISHMENT REJECT message, because a keystream reuse would otherwise happen.


© 2016 Nokia

125


4.17.3.6.8


Intra-cell AS security maintenance by key refresh for RRC connection Reestablishment In case of a RRC: connection reestablishment message, a fresh serving cell key hierarchy is derived in the same way as for inter-eNB handover via X2. In particular, a fresh next hop is into account. However, the security algorithms may not change.

4.17.3.7

Support of RRC Connection Re-establishment during intra-eNB handover in the source cell If the UE requests RRC: Connection Re-establishment message towards the source cell of an ongoing intra-eNB handover, eNB reestablishes the RRC Connection via the source cell and cancel the ongoing intra-eNB handover. In the exceptional case that UE tries RRC Re-establishment with cause "reconfiguration failure" eNB rejects the RRC Re-establishment message and release the UE.

4.17.3.8

RRC Connection Re-establishment procedure successful case including mobility The successful case of the RRC Connection Re-establishment procedure is supported.

4.17.3.9

Support of RRC Connection Reconfiguration Procedure for Reestablishment at handover The eNB supports the RRC Connection Reconfiguration procedure during reestablishment in the target cell of an handover - especially reconfiguring and resuming SRB2 and all DRBs.The configuration of SRB2 and DRBs is modified and a RRC Connection Reconfiguration needs to be sent after the RRC Connection Reestablishment procedure to reconfigure and resume traffic on SRB2 and DRBs.

4.17.3.9.1

Measurement Configuration at Re-establishment in "target cell" eNB optionally configures UE measurements at the re-establishment in target cell of an handover. • • •

4.17.3.9.2

eNB configures UE measurement if indicated by MOBILTY SFS The measurement Configuration IE is also taken from these requirements The measurement Configuration is configured as part of the RRC message

Radio Bearer Reconfiguration at re-establishment in target cell with "target cell - source config" eNB detects the case if: • •

UE is in "target cell - Source Config" a handover is ongoing (at least HandoverPreparationInformation available for an UE)

In this case, the UE enters the target cell with the radio bearer configuration of the source cell and eNB shall reconfigure the UE as in case of handover:

126

© 2016 Nokia



• • • • •

4.17.3.9.3


the UE related MAC and L1 parameters (except DRX) have already been configured at the RRC Connection Re-establishment. the eNB uses the radio bearer configuration for SRB2 and DRBs that was already configured at the handover preparation the eNB applies the MAC DRX configuration the eNB optionally configures measurements the eNB sends the RRC message RRCConnectionReconfiguration containing the listed reconfigurations. The RRCConnectionReconfiguration message implicitly re-establishes and resumes SRB2 and existing DRB(s)

Building of RRCConnectionReconfiguration for re-establishment in target cell with "target cell - Source Config" eNB includes the high level IEs in the RRCConnectionReconfiguration message according table.

4.17.3.9.4

Building of RadioResourceConfigDedicated IE for re-establishment in target cell with "target cell - Source Config" eNB builds the RadioResourceConfigDedicated IE

4.17.3.9.5

Improved Failure Handling for RRC Connection Reconfiguration Procedure The RRC Connection Re-establishment procedure can interrupt an ongoing RRC Connection Reconfiguration procedure. eNB is able to handle these failure cases of the RRC Connection Reconfiguration procedure. Affected procedures: • • • • •

4.17.3.9.6

E-RAB Setup procedure E-RAB Release procedure reconfiguration in case PUCCH-SR Failure or in-sync start and Stop of inter-RAT/inter-frequency measurements retrieval of UE Capabilities for UTRAN

Interaction of UE Capability Transfer Procedure with RRC Connection Reestablishment The UE Capability Transfer procedure can be interrupted by the RRCConnectionReestablishmentRequest message from UE. •

• • • • •


Scenario "UE Capability Transfer procedure executed before sending the RRC message RRCConnectionReconfiguration of the Initial Context Setup procedure" eNB aborts the Initial Context Setup procedure Scenario "UE Capability Transfer procedure is executed after the Initial Context setup or handover procedure" If the UE context was found and the RRCConnectionReestablishmentRequest message was accepted eNB stops the supervision timer eNB starts the RRC Connection Reconfiguration for re-establishment without ongoing RRC Reconfiguration

© 2016 Nokia

127


•

4.17.3.9.7


eNB repeats the UE Capability Transfer procedure after the successful reestablishment

Reception of RRCConnectionReestablishmentRequest message during RRC Connection Reconfiguration If eNB receives the RRC message RRC:ConnectionReestablishmentRequest, the reconfiguration has failed.

4.17.3.9.8

Supervision of RRC Connection Reconfiguration procedure for L1 reconfiguration eNB supervises the transmission of the RRCConnectionReconfiguration message. eNB releases the timer when eNB receives the RRCConnectionReconfigurationComplete message or UE initiates a RRC Connection Re-establishment procedure. If the timer expires, eNB assumes this case as SRB failure.

4.17.3.9.9

Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Setup eNB detects this case if: • •

UE is "Serving Cell Config" RRC Connection Reconfiguration procedure is ongoing during an E-RAB Setup

In this case, eNB undo the E-RAB Setup: • • • • •

4.17.3.9.10

the eNB deletes all resources for the DRB(s) that have been added by the E-RAB Setup procedure (for example RLC, PDCP, S1 bearer) the eNB includes the deletion of the added DRB(s) to the RRCConnectionReconfiguration message. the eNB applies the DRX configuration for the old bearer combination. the eNB optionally configures measurements the eNB sends the RRC message RRCConnectionReconfiguration containing the listed reconfigurations. The RRCConnectionReconfiguration message implicitly re-establishes and resumes SRB2 and existing DRB(s).

Building of RRC: ConnectionReconfiguration for Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Setup eNB includes the high level IEs in the RRCConnectionReconfiguration table.

4.17.3.9.11

Building of RadioResourceConfigDedicated IE for Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Setup eNB includes the high level IEs in the RadioResourceConfigDedicated table.

4.17.3.9.12

Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Release The eNB detects this case if:

128

© 2016 Nokia



• •


UE is in "Serving Cell Config" An RRC Connection Reconfiguration procedure is ongoing during an E-RAB Release

In this case, eNB repeats the E-RAB Release procedure: •

• • •

•

4.17.3.9.13

The eNB repeats the deletion of the DRB(s) in the RRC:ConnectionReconfiguration message as during the normal E-RAB Release procedure. Also the optional NAS-PDU of the E-RAB Release Command message is added to this message. The eNB applies the DRX configuration for the new bearer combination. The eNB optionally configures measurements The eNB sends the RRC message RRCConnectionReconfiguration containing the listed reconfigurations. The RRC:ConnectionReconfiguration message implicitly re-establishes and resumes SRB2 and existing DRB(s). The further handling is as described for the normal E-RAB Release procedure (for example release of local resources or sending the E-RAB RELEASE RESPONSE).

Building of RRCConnectionReconfiguration for Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Release eNB includes the high level IEs in the RRCConnectionReconfiguration table.

4.17.3.9.14

Building of RadioResourceConfigDedicated IE for Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for E-RAB Release eNB includes the high level IEs in the RadioResourceConfigDedicated table.

4.17.3.9.15

Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for L1 Reconfiguration The eNB detects this case if: • •

UE is in "Serving Cell Config" An RRC Connection Reconfiguration procedure is ongoing during a L1 Reconfiguration

In this case, the eNB re-establishes and resume SRB2 and DRB(s) and configures optionally DRX on UE side. • • •


The eNB applies the DRX configuration as that has been used before the L1 Reconfiguration The eNB optionally configures measurements The eNB sends the RRC message RRCConnectionReconfiguration containing the listed reconfigurations. The RRCConnectionReconfiguration message implicitly re-establishes and resumes SRB2 and DRB(s) on UE side. The RRCConnectionReconfiguration message is identical to the case "Reestablishment with "Serving Cell Config" and without ongoing RRC reconfiguration".

© 2016 Nokia

129


4.17.3.9.16


Radio Bearer Reconfiguration at Re-establishment with "Serving Cell Config" and ongoing RRC Reconfiguration for Measurement Reconfiguration The eNB detects this case if: • •

UE is "Serving Cell Config" An RRC Connection Reconfiguration procedure is ongoing during a Measurement Reconfiguration.

In this case, the measurement configuration is sent a second time to overwrite the current measurement configuration in UE: • • • • • •

4.17.3.10

the eNB applies the DRX configuration depending on the type of measurement configuration: at start and stop of intra-frequency measurements eNB applies the DRX configuration that has been used before the measurement reconfiguration at start of ANR measurement for CGI resolution eNB configures DRX at start of ANR measurement for CGI resolution eNB configures DRX at stop of ANR measurement for CGI resolution eNB configures DRX the eNB sends the RRC message RRC:ConnectionReconfiguration containing the listed reconfigurations. The RRC:ConnectionReconfiguration message in this case is identical to the normal RRC:ConnectionReconfiguration message for Measurement Reconfiguration. The RRC:ConnectionReconfiguration message implicitly re-establishes and resumes SRB2 and existing DRB(s).

Support of RRC Connection Re-establishment during intra-eNB handover in the target cell If the UE requests RRC Connection Re-establishment towards the target cell of an ongoing intra-eNB handover, the eNB reestablishes the RRC Connection via the target cell and continue the intra-eNB handover procedure. In the exceptional case that UE tries RRC Re-establishment with cause "reconfiguration Failure" the eNB rejects the RRC Re-establishment and release the UE.

4.17.3.10.1

Receiving RRC CONNECTION Re-establishment REQUEST message during intra-eNB handover at the target cell If target cell receives an RRC: RRC CONNECTION RE-ESTABLISHMENT REQUEST message from the UE during intra-eNB handover, eNB decides whether the RRC Reestablishment is accepted or rejected. eNB performs the checks regarding Reestablishment cause, PCI and message integrity. If all checks are positive, the eNB accepts the RRC Re-establishment towards the target cell. If at least one condition is not fulfilled (for example because Re-establishmentCause is set to "reconfigurationFailure") the eNB rejects the RRC Re-establishment.

4.17.3.10.2

Successful RRC Re-establishment at the target cell during intra-eNB handover If it was decided to accept the RRC Re-establishment request, the eNB shall:

130

© 2016 Nokia



• • •

•

4.17.3.10.3


suspend the processing of the ongoing intra-eNB handover procedure perform RRC Connection Re-establishment procedure to reestablish SRB1 perform RRC Connection Reconfiguration procedure to reestablish SRB2 and DRBs in case the UE has entered the target cell with source cell configuration, or in case the UE has enterd the target cell with target cell configuration continue the processing of the ongoing intra-eNB handover procedure in the same way as if RRC Connection Reconfiguration Complete would have been received. In case the intra-eNB handover procedure would have foreseen a measurement reconfiguration, this measurement reconfiguration is skipped because the new measurement configuration has already been provided to the UE within the RRC Connection Reconfiguration message of the RRC Re-establishment.

RRC: RE-ESTABLISHMENT REJECTION at target cell during Intra-eNB handover If it was decided to reject RRC Re-establishment request, the eNB executes the rejection.

4.17.3.10.4

Support of RRC: CONNECTION RE-ESTABLISHMENT during inter-eNB handover via X2 in the target cell If the UE requests RRC Connection Re-establishment towards the target cell of an ongoing inter-eNB handover via X2, the eNB reestablishes the RRC Connection via the target cell and continue the inter-eNB handover procedure. In the exceptional case that UE tries RRC Re-establishment with cause "reconfiguration Failure” eNB rejects the RRC Re-establishment and release the UE. Anyhow handover signaling towards the source eNB is continued.

4.17.3.10.5

Receiving RRC: CONNECTION RE-ESTABLISHMENT REQUEST message at the Target eNB during X2-handover If target cell in the target eNB receives an RRC: RRC CONNECTION REESTABLISHMENT REQUEST message from the UE during the handover eNB decides whether the RRC Re-establishment is accepted or rejected. The eNB performs the checks regarding Re-establishment cause, PCI and message integrity. If all checks are positive, eNB accepts the RRC Re-establishment towards the target cell. If at least one condition is not fulfilled (for example because Re-establishment cause is set to "reconfigurationFailure") eNB rejects the RRC Re-establishment.

4.17.3.10.6

Successful RRC: RE-ESTABLISHMENT at the target eNB during X2_HO If it was decided to accept the RRC Re-establishment request, target eNB: • • •

•


suspends the processing of the ongoing X2-handover procedure performs RRC Connection Re-establishment procedure to reestablish SRB1 performs RRC Connection Reconfiguration procedure to reestablish SRB2 and DRBs, in case the UE has entered the target cell with source cell configuration, or in case the UE has enterd the target cell with target cell configuration continues the processing of the ongoing X2-handover procedure in the same was as if RRC Connection Configuration Complete message would have been received. In case the X2-handover procedure would have foreseen a measurement

© 2016 Nokia

131



reconfiguration, this measurement reconfiguration is skipped because the new measurement configuration has already been provided to the UE within the RRC Connection Reconfiguration message of the RRC Re-establishment.

4.17.3.10.7

RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT by Target eNB for a UE performing an X2 handover If an indication has been received that the RRC: RRC CONNECTION REESTABLISHMENT REJECT message has been sent to a UE performing a handover to the target eNB, the prepared handover is aborted for that UE.

4.17.3.10.8

Stop guarding timer TRELOCreestablish due to RRC: RRC CONNECTION REESTABLISHMENT REJECT by Target eNB Upon receiving an RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT indication, guarding timer TRELOCreestablish is stopped.

4.17.3.10.9

RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT byTarget eNB for a UE performing Measurement Configuration If an indication has been received that the RRC: RRC CONNECTION REESTABLISHMENT REJECT message has been sent to a UE performing a Measurement Configuration, the target eNB starts the eNB Initiated Context Release procedure as soon as the S1AP: PATH SWITCH REQUEST ACKNOWLEDGE message has been received, using Cause value: Radio Network Layer Cause (Radio Connection with UE Lost). The actions taken by the target eNB as a result of receiving the S1AP: PATH SWITCH REQUEST ACKNOWLEDGE message (for example sending an X2AP: UE CONTEXT RELEASE message to the source eNB) continues as described for the successful case.

4.17.3.10.10

Stop guarding timer for RRC Connection Reconfiguration procedure due to RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT byTarget eNB Upon sending an RRC: RRC CONNECTION RE-ESTABLISHMENT REJECT message, guarding timer TRRCGuardTimerRadioBearerManagement is be stopped.

4.17.3.10.11

Support of RRC Connection Re-establishment during inter-eNB handover via S1 in the target cell If the UE requests RRC Connection Re-establishment towards the target cell of an ongoing inter-eNB handover via S1, the eNB reestablishes the RRC Connection via the target cell and continue the inter-eNB handover procedure. In the exceptional case that UE tries RRC Re-establishment with cause "reconfiguration failure", the eNB rejects the RRC Re-establishment and release the UE.

4.17.3.10.12

Receiving RRC: CONNECTION RE-ESTABLISHMENT REQUEST message at the target eNB during S1-handover If target cell in the target eNB receives an RRC: RRC CONNECTION REESTABLISHMENT REQUEST message from the UE during the handover eNB decides whether the RRC Re-establishment shall be accepted or rejected. The eNB performs the

132

© 2016 Nokia




checks regarding re-establishment cause, PCI and message integrity.If all checks are positive, eNB shall accept the RRC Re-establishment towards the target cell.If at least one condition is not fulfilled (for example because re-establishment cause is set to "reconfigurationFailure") eNB rejects the RRC Re-establishment.

4.17.3.10.13

Successful RRC Re-establishment at the target eNB during S1_HO If it was decided to accept the RRC Re-establishment request, target eNB: • • •

•

4.17.3.10.14

suspends the processing of the ongoing X2-handover procedure performs RRC Connection Re-establishment procedure to reestablish SRB1 performs RRC Connection Reconfiguration procedure to reestablish SRB2 and DRBs, in case the UE has entered the target cell with source cell configuration, or in case the UE has enterd the target cell with target cell configuration continues the processing of the ongoing S1-handover procedure as if RRC Connection Reconfiguration Complete message have been received. In case the S1-handover procedure would have foreseen a measurement reconfiguration, this measurement reconfiguration is skipped because the new measurement configuration has already been provided to the UE within the RRC Connection Reconfiguration message of the RRC Re-establishment.

RRC Re-establishment rejection at the target eNB during S1-handover If it was decided to reject the RRC Re-establishment request, target eNB internally aborts the ongoing S1-handover procedure and initiate UE Context Release procedure towards the MME.

4.17.3.11

Signaling in RRC_CONNECTED Requirements eNB supports the interaction of S1AP procedure with RRC Connection Re-establishment procedure. Interacting with RRC Connection Re-establishment Procedure for the case that DL INFORMATION TRANSFER has to be sent, eNB behaves as follows: •

4.17.3.12

If RRC Connection Re-establishment is running, eNB buffers the PDU and retry delivery as soon as the re-establishment is completed. This means both RRC Connection Re-establishment and related RRC Connection Reconfiguration procedures have to be done before the retry.

RRC Connection Re-establishment procedure successful case including interaction with S1AP procedures eNB supports the interaction of several ongoing S1AP and RRC procedures with the successful case of the RRC Connection Re-establishment procedure.


© 2016 Nokia

133


4.17.3.12.1


RLF detection interacting with starting or ongoing S1AP requests When the eNB has detected an RLF and while timer T_RLF or an RLF triggered reestablishment is running, the eNB buffers new arriving S1AP requests and stop responding to the ongoing S1AP procedures with the exception of the S1AP messages UE CONTEXT RELEASE COMMAND and HANDOVER COMMAND that should be executed. After this, the eNB acts as follows: •

•

•

4.17.3.12.2

If the UE comes back before timer T_RLF expires (without re-establishment), the eNB executes the buffered S1AP requests and continue responding to the interrupted S1AP procedures. If the UE comes back via re-establishment and the Re-establishment procedure is finished, the eNB executes the buffered S1AP requests and continue responding to the interrupted S1AP procedures. If timer T_RLF expires, the buffered S1AP requests are deleted and the interrupted S1AP procedures are aborted. In both cases, eNB sends the related S1AP response; then the eNB sends the UE CONTEXT RELEASE REQUEST message with cause "Radio Connection With UE Lost" to the related MME.

RRC: CONNECTION RE-ESTABLISHMENT procedure successful case in target cell with "target cell - Source Config" eNB supports the RRC Connection Re-establishment procedure in the target cell with "target cell - source config" - especially reconfiguring SRB1. In case SRB1 configuration in source and target cell are different, SRB1 has to be reconfigured.

4.17.3.12.3

Sending RRC: RRC CONNECTION RE-ESTABLISHMENT message in target cell with "target cell - Source Config" Before sending of the RRC: RRC CONNECTION RE-ESTABLISHMENT message eNB • • • • •

reconfigures radio bearer configuration for SRB1, if the SRB1 radio bearer configuration in source and target cell are different configures MAC of new C_RNTI sets up RLC entities for new C-RNTI with the same parameter settings used at Bearer Setup Creation of new PDCP entry and switching data queue from old to new PDCP activates security

eNB sends RRC: RRC CONNECTION RE-ESTABLISHMENT message on CCCH to the UE. As soon as the message is sent, eNB starts timer MinLifeTimeOfHalfOpenRrcConnection.

4.17.3.12.4

Building of RadioResourceConfigDedicated IE at RRC: CONNECTION REESTABLISHMENT at target cell with "Target cell - Source config" The eNB builds the IE RadioResourceConfigDedicated at target cell with "target cell - source config"

4.17.4 System impact Interdependencies between features

134

© 2016 Nokia




The mobility related functionality depend partly on availability of optional SW features: • • • • • • •

LTE 53 - LTE intra-frequency via X2 LTE 54 - Intra-LTE handover via S1 LTE 55 - LTE inter-frequency handover LTE 56 - inter-RAT handover to WCDMA LTE 60 - inter-RAT handover to eHRPD LTE 872 - SRVCC to WCDMA LTE 873 - SRVCC to GSM

Impact on interfaces This feature impacts external interfaces as follows: Modified RRC message: • •

RRC Connection Re-establishment RRC Connection Reconfiguration

Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.17.5 LTE735: RRC Connection Re-establishment management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Measurements and counters Table 74: New counters lists counters introduced with this feature. Table 74

Counter ID


New counters

Counter name

Measurement

M8008C4

Number of RRC Connection Reestablishment attempts

M8008C5

Number of successful RRC Connection Re- 8008 - LTE RRC (WBTS) establishment procedures

M8008C6

RRC Connection Re-establishment attempts per cause (Handover Failure)

M8008C7

RRC Connection Re-establishment success 8008 - LTE RRC (WBTS) per cause (Handover Failure)

© 2016 Nokia

8008 - LTE RRC (WBTS)


135


Table 74



Counter ID

Counter name

Measurement

M8008C8

RRC Connection Re-establishment attempts per cause (Other Failure)


M8008C9

RRC Connection Re-establishment success 8008 - LTE RRC (WBTS) per cause (Other Failure)

There are no measurements related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


Sales information

BSW/ASW

SW component



BSW

-

-

-

4.18 4.18.1 LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT Introduction to the feature When this feature is enabled, information about CDMA2000 frequencies and neighboring cells relevant for cell re-selection from LTE to CDMA/1xRTT network can be broadcasted to the UE in the idle and in the active mode.

4.18.1.1

Benefits End-user benefits This feature and a set of related features guarantee the end-users the best possible coverage and voice quality in the radio access network. Operator benefits This feature improves the availability of service for the LTE subscribers and thus contributes to customer satisfaction.

136

© 2016 Nokia



4.18.1.2


Requirements Software requirements The table Software requirements lists the software required for this feature. Table 76


System release

RL30

eNodeB

LBTS3.0

MME

-

SAE GW

-

UE


NetAct

-


4.18.1.3

Functional description A user entity which is in the RRC-IDLE state can be reached in those cells that belong to the tracking area where the UE is currently registered. When camped on a cell, the UE regularly searches for a better cell according to the cell reselection criteria. This criteria is defined in operator-configurable parameters, stored to the eNB and broadcasted to the UE via the BCCH. The broadcast is repeated at regular intervals, depending on the value defined by the operator. When feature LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT is enabled, the eNB sends information about CDMA2000 frequences and neighboring cells to all UEs in RRC-IDLE and RRC-CONNECTED state. On the basis of this information, the UE is able to make an inter-RAT cell re-selection from LTE to CDMA/1xRTT. The configurable parameters are listed in chapter LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT management data.

4.18.1.4

System impact Interdependencies between features The following optional features also provide operator-configurable parameters for cell reselection, but they are not a prerequisite for the use of LTE807: • •

LTE762: Idle Mode Mobility from LTE to WCDMA, GSM or other LTE bands LTE870: Idle Mode Mobility from LTE to CDMA/eHRPD

All these features (LTE762, LTE807, and LTE870) can be activated and configured independently from each other.


© 2016 Nokia

137



For an overview of the idle mode operations and other related features in this area, see Idle Mode Operations Functional Area Description. Impact on interfaces System Information Broadcast 8 (SIB8) is modified. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.18.1.5

LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table Parameters for LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT lists parameters introduced with this feature. The parameters belong to System Information Block 8 (SIB8) of the CDMA2000 Frequency Idle Mode Configuration (managed object class CDFIM of the eNB object model). For detailed descriptions of the purpose and values of each parameter, see U-plane Protocol Stack and SIB Functional Area Description.

t

Tip: There are dependencies between some of the parameters. These have to be taken into account when configuring the parameter set. For a description of the dependencies, and instructions for taking the feature in use, see LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT Feature Activation Instructions. Table 77

Parameters for LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT Full name

138

Abbreviated name

Managed object

Structure

CDMA2000 1xRTT band class list

rttBdClList

CDFIM

CDMA2000 1xRTT band class BCL

rttBdClBcl

CDFIM

rttBdClList

CDMA2000 1xRTT cell reselection priority

rttCResPrio

CDFIM

rttBdClList

© 2016 Nokia



Table 77


Parameters for LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT (Cont.) Full name

4.18.1.6

Abbreviated name

Managed object

Structure

CDMA2000 1xRTT reselection high threshold

rttFrqThrH

CDFIM

rttBdClList

CDMA2000 1xRTT reselection low threshold

rttFrqThrL

CDFIM

rttBdClList

CDMA2000 1xRTT neighbor cell list

rttNCList

CDFIM

CDMA2000 1xRTT frequency

rttArfcn

CDFIM

rttNCList

CDMA2000 1xRTT band class (NCL)

rttBdClNcl

CDFIM

rttNCList

CDMA2000 1xRTT physical cell identity

rttCellId

CDFIM

rttNCList

CDMA2000 1xRTT NCL extension selector

rttExSel

CDFIM

rttNCList

CDMA2000 1xRTT cell reselection timer

tResRtt

CDFIM

Speed dep scaling factors treselection 1xRTT

tResRttSF

CDFIM

1xRTT cell reselection timer factor high mobility

rttResTiFHM

CDFIM

tResRttSF

1xRTT cell reselection timer factor med mobility

rttResTiFMM

CDFIM

tResRttSF

Sales information This feature belongs to the Application Software (ASW) product structure class and requires a license for the eNB. The license type is ON/OFF. When the license has been acquired, the feature can be enabled for the eNB with parameter actImmXrtt. For instructions, see LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT Feature Activation Instructions. When the license is not available, the 1xRTT-specific parameter set (parameters-1XRTT) is omitted from SIB8. If neither of the features LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT nor LTE870: Idle Mode Mobility from LTE to CDMA/eHRPD is available, SIB8 is not broadcasted at all. Table 78

Sales information

BSW/ASW

SW component



ASW

LNBTS

actImmXrtt

0 = false (default) 1 = true


© 2016 Nokia

139



4.19 LTE829: Increased Uplink MCS Range Introduction to the feature With the LTE829 feature, Uplink peak throughput is enhanced by additional support of MCS21-MCS24 for high 16-QAM UE.

4.19.1 Benefits The operator can state approximately 25% higher peak data rates in UL.


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-


4.19.3 Functional description Increased uplink MCS range can extend the range of MCSs used for 16 QAM UEs (cat1cat4) beyond MCS20 to MCS21-MCS24. In this case the UE still uses the 16-QAM modulation with less coding instead of 64-QAM originally foreseen for these MCS. Table 80: Peak rate improvement shows improvement in the maximum instantaneous PHY peak rate for MCS24. Table 80

Bandwidth (Mhz)

140

Peak rate improvement

Maximum number of PRBs

UL peak rate improvement (Mbps) (%)

3

12 of 15

6.456

+25

5

20 of 25

10.680

+26

10

48 of 50

25.456

+23

15

72 of 75

39.232

+28

© 2016 Nokia



Table 80

Bandwidth (Mhz)

20

4.19.3.1


Peak rate improvement (Cont.)

Maximum number of PRBs 96 of 100

UL peak rate improvement (Mbps) (%)

51.024

+26

User scenarios The operator can activate 16-QAM high MCS by setting the actModulationSchemeUL to 16QAMHighMCS.

4.19.3.2

Feature limitations LTE829: Increased Uplink MCS Range feature does not work unless the UE is located under very good radio conditions (very good RX level and SINR at eNodeB) or if UL data transfer is not too short to allow UL AMC to switch from initial MCS to high 16-QAM MCS. The maximum instantaneous PHY Peak Rate improvements can be achieved if the UE has enough data in buffer and as long as the cell has not been configured with too excessive PUCCH resources.

4.19.4 System impact Interdependencies between features LTE788: Support of 16 QAM (UL) feature needs to be activated. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

4.19.5 LTE829: Increased Uplink MCS Range management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 81: New counters lists counters introduced with this feature.


© 2016 Nokia

141


Table 81

Counter ID

142


New counters

Counter name

Measurement

M8001C435

First transmissions on PUSCH using MCS0


M8001C436



M8001C437



M8001C438



M8001C439



M8001C440



M8001C441



M8001C442



M8001C443



M8001C444



M8001C445



M8001C446



M8001C447



M8001C448



M8001C449



M8001C450



M8001C451



M8001C452



M8001C453



M8001C454



M8001C455



M8001C456



M8001C457



M8001C458



© 2016 Nokia



Table 81

Counter ID




Counter name

Measurement

M8001C459



M8001C460

First transmission NACKs on PUSCH using MCS0


M8001C461



M8001C462



M8001C463



M8001C464



M8001C465



M8001C466



M8001C467



M8001C468



M8001C469



M8001C470



M8001C471



M8001C472



M8001C473



M8001C474



M8001C475



© 2016 Nokia

143


Table 81



Counter ID

Counter name

Measurement

M8001C476



M8001C477



M8001C478



M8001C479



M8001C480



M8001C481



M8001C482



M8001C483



M8001C484



M8001C485

Failed Reception PUSCH MCS21


M8001C486



M8001C487



M8001C488



M8012C144

MAC PDU volume PUSCH MCS21

LTE Cell Throughput (WBTS)

M8012C145



M8012C146



M8012C147



Key performance indicators There are no key performance indicators related to this feature.

144

© 2016 Nokia




Parameters Table 82: New parameters lists parameters introduced with this feature. Table 82

New parameters

Full name

Abbreviated name

Activate modulation scheme UL

Managed object

actModulationSchemeUL

LNCEL


Sales information

BSW/ASW



BSW

-

-

4.20 LTE971: Intra-LTE mobility offsets Introduction to the feature Offset setting for intra LTE mobility is introduced.

4.20.1 Benefits Operator benefits The operator is able to optimize the intra-LTE mobility by applying different offsets to different target cells.


Release


System release

eNode B

RL30

LBTS3.0

-

-

-

-



© 2016 Nokia

145




Functional overview This feature extends the already existing configurable handover events A3 (better cell) and A5 (coverage) with the frequency-specific offsets and the Cell Individual Offsets (CIOs) for the serving carrier and all other neighbor carrier‘s measurement objects. For the own serving carrier (Intra) and all other carriers (Inter) the cellsToAddModList parameter (accordingly cellsToRemoveList parameter) further on called the CIO cell list - will be introduced. Each CIO cell list contains a set of up to 32 Physical Cell IDs (PCIs). The Cell Individual Offset (CIOs) of the serving cell with its PCI may also be contained in the cellsToAddModList parameter, where all other neighbor cell PCIs with its CIOs are also included. The operator is able to optimize the intra LTE mobility by applying following different offsets to different target cells : • •

cell Individual Offsets (CIOs) for the serving cell and neighbor cells on own serving carrier and on all other carriers additionally, carrier frequency specific offsets of own serving (Intra) and neighbor (Inter) carriers are introduced.

The Flexi Multiradio BTS supports offset settings for intra-frequency and inter-frequency handovers. The following offsets are supported: • • • •

Ofn - frequency specific offset of neighbour cells Ocn - Cell Individual Offsets (CIOs) of neigbour cells Ofs - frequency specific offset of the serving cell Ocs - serving Cell Individual Offset

The offsets are applied if the related measurements are configured, are sent to the UE as part of the measurement configuration, and the UE takes the offsets for the measurement triggering into consideration

4.20.3.2 4.20.3.2.1

Connection Mobility Control: Handover (CMC-HO) Support of Intra-Frequency cell individual offsets (CIO cell list) and IntraFrequency specific offsets •

•

•

146

The eNB supports the configuration of Intra-Frequency Cell Individual Offsets (CIO) in the CIO cell list in the measurement configuration of the serving carriers measurement object for the A3 event (neighbor cell becomes better than serving cell) and the A5 event (coverage). The CIO cell list is used to indicate explicitly to the UEs which cells/PCIs, to measure with an individual CIO to be applied for the measurement events. The CIO cell list is compiled from a parameter in LNCEL for the serving cell and from the parameters in LNREL for other neighbor cells The eNB supports the configuration of frequency-specific offsets in the measurement configuration of the serving carriers measurement object (Intra) for the A3 event (neighbor cell becomes better than serving cell).

© 2016 Nokia



4.20.3.2.2


Support of Inter-Frequency cell individual offsets (CIO cell lists) and InterFrequency specific offsets •

•

•

The eNB supports the configuration of Inter-Frequency Cell Individual Offsets (CIO) in the CIO cell lists in the measurement configuration of the neighbor carriers measurement objects for the A3 event (neighbor cell becomes better than serving cell) and the A5 event (Coverage). The CIO cell list is used to indicate explicitly to the UEs which cells/PCIs, to measure with an individual CIO to be applied for the measurement events. The CIO cell lists of neighbor carriers is compiled from parameters in LNREL for other neighbor cells. The eNB supports the configuration of frequency-specific offsets in the measurement configuration of the neighbor carriers measurement objects for the A3 event (neighbor cell becomes better than serving cell) and the A5 event (Coverage).

4.20.4 System impact Interdependencies between features • • •

LTE533: Mobility Robustness LTE430: DL power boosting for control channels LTE782: ANR - Intra-LTE, Intra-frequency - Fully UE based

Related optional mobility features are required for part of the functionality, for example LTE55: Interfrequency handover. Impact on interfaces This feature has no impact on interfaces. Impact on the network and network element management tools This feature has no impact on the network management or network element management tools. Impact on the system performance and capacity This feature has no impact on the system performance or capacity.

4.20.5 LTE971: Intra-LTE mobility offsets management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 85: New parameters lists parameters introduced with this feature.


© 2016 Nokia

147


Table 85


New parameters

Full name

Abbreviated name

Managed object

Cell Individual Offset of own serving cells PCI

cellIndOffServ

LNCEL

Intra EUTRA offset frequency

offsetFreqIntra

LNCEL

Inter EUTRA offset frequency

offsetFreqInter

LNHOIF

Cell Individual Offset of neighbor cells

cellIndOffNeigh

LNREL


Sales information

BSW/ASW

SW component



BSW

-

-

-

4.21 LTE1034: Extended Uplink Link Adaptation Introduction to the feature An enhanced uplink link adaptation (E-ULA) algorithm is introduced.

4.21.1 Benefits End-user benefits It improves perfomances in case of high P0 settings (which are required to transmit peak data rates) retarding the reduction of the maximum number of allocable PRBs (Physical Resource Block) and improving consequently throughput performances (expecially when under very low load condition in the cell). Operator benefits This feature benefits the operator as follows: • •

The E-ULA algorithm makes the eNodeB (evolved Node B) less sensitive to wrong P0 settings It introduces a more power efficient strategy trying, when possible, to transmit with a bigger number of PRBs and lower MCS (Modulation and Coding Scheme) level according to the required data rate. This is especially advantageous with power limitations.

4.21.2 Requirements Software requirements

148

© 2016 Nokia




Table 87: Software requirements lists the software required for this feature. Table 87

Release


Systemrele eNodeB ase

MME

SAE GW

UE

NetAct

RL30

-

-

3GPP R8 mandatory

-

LBTS3.0


4.21.3 Functional description Functional overview The feature enhances the slow ATB (Adaptive Transmission Bandwidth) algorithm by taking eNB UL (Uplink) BLER (Block Error Ratio) measurements in addition to the power headroom report provided by the UE (User Equipment) into account. The extended algorithm enforces the selection of a power efficient combination of PRBs and MCS. Extended Uplink Link Adaptation (E-ULA) E-ULA improves the currently implemented UL Link Adaptation. Thanks to the new mechanism power limited UEs (because of bad radio frequency conditions) can use a wider bandwidth with lower MCS level. The new solution is much more power efficient. When BLER is low and MCS does not reach the minimum, the PRBs are increased. It leads to a power efficient transmission with maximized PRB usage. The LTE1034 Extended Uplink Link Adaptation is mainly constituted by the following algorithmic parts: • • •

g

OLLA (Open Loop Link Adaptation), Slow ATB (a new algorithm) - it uses PHR (Power Headroom Report) and BLER measurements, OLLA and Slow ATB interworking and coordination algorithm. Note: Slow AMC is no longer necessary when OLLA and Slow ATB are integrated in EULA. When E-ULA is active both OLLA and Slow ATB are both active (no possibility to switch any of them off independently).

Changing UL power conditions Whenever uplink channel conditions deteriorate, the OLLA algorithm downgrades UL MCS until the low MCS threshold is reached (eUlLaLowMcsThr).

g


Note: The maximum allowed PRB allocation is not reduced before achieving the low MCS threshold.

© 2016 Nokia

149



When UL channel conditions are still deteriorating and in addition the low MCS threshold has been reached, the Slow ATB algorithm becomes active and reduces the maximum allowed PRB allocation (limited to eUlLaLowPrbThr) as long as it is possible to keep SINR good enough. If not, the eNB downgrades MCS until MCS0. When channel conditions improve, Slow ATB performs maximum allocable PRB resources enlargement only when the sum of the low MCS threshold (eUlLaLowMcsThr) and the given MCS delta (eUlLaDeltaMcs) has been reached. When channel conditions are improving and UE-specific PRB allocation size has been already limited by ATB, the UL OLLA increases the MCS index. Once the MCS index is equal to eUlLaLowMcsThr + eUlLaDeltaMcs, the ATB starts to enlarge the allocable bandwidth. The ATB algorithm in E-ULA is based on BLER evaluation. It increases or decreases the number of allocable PRBs by multiplying or dividing respectively this number by eUlLaPrbIncDecFactor. Migration to parameter actUlLinkAdapt The LNCEL parameters ulamcEnable, ulamcEdgFugEn and ulatbEnable are removed in RL30 and replaced by the new LNCEL parameter actUlLnkAdp. For each LNCEL the following migration is needed: • •

if ulamcEnable, ulamcEdgFugEn and ulatbEnable were set to false, then actUlLnkAdp has to be set to off. if ulamcEnable, ulamcEdgFugEn or ulatbEnable were set to true, then actUlLnkAdp has to be set to eUlLa.

The introduction of other choices to actUlLinkAdapt makes it possible to configure old UL Link Adaptation functions in the same way as before RL20. SlowAMC activates only the old SlowAMC algorithm. SlowAmcOlla turns on the SlowAMC, EDG (Emergency DownGrade) and FUG (Fast UpGrade). By setting slowAmcATB, only old SlowAMC and SlowATB functions are active. Finally, slowAmcOllaATB allows all the three old functions to be activated together (as it was up to RL20). For more details about E-ULA parameters, see Table 88: New parameters. Information about ranges, default values and steps can be found in the Reference documentation.

4.21.4 System impact Interdependencies between features LTE1034: Extended Uplink Link Adaptation influances on the LTE31: Link Adaptation By AMC (UL/DL). LTE31 introduces OLLA that is reused in LTE1034. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity The goal of the feature is to provide new uplink link adaptation scheme for getting better UL throughput in channel conditions having low SINR.

150

© 2016 Nokia




4.21.5 LTE1034: Extended Uplink Link Adaptation management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 88: New parameters lists parameters introduced with this feature. Table 88

New parameters

Full name

Abbreviated name

Managed object

Activate uplink link adaptation

actUlLnkAdp

LNCEL

Extended uplink link adaptation ATB periodicity

eUlLaAtbPeriod

LNCEL

Extended uplink link adaptation BLER averaging window

eUlLaBlerAveWin

LNCEL

Extended uplink link adaptation delta MCS

eUlLaDeltaMcs

LNCEL

Extended uplink link adaptation low MCS threshold

eUlLaLowMcsThr

LNCEL

Extended uplink link adaptation low PRB eUlLaLowPrbThr threshold

LNCEL

Extended uplink link adaptation PRB factor

LNCEL

eUlLaPrbIncDecFactor



Sales information

BSW/ASW



BSW

-

-

© 2016 Nokia

151



4.22 LTE1035:Outer Loop Link Adaptation for PDCCH Introduction to the feature The feature provides an enhancement to the PDCCH (Physical Downlink Control Channel) link adaptation algorithm.

4.22.1 Benefits End-user benefits This feature benefits the end user as follows: • •

Better cell edge performance Defined PDCCH error rate

Operator benefits This feature benefits the operator as follows: • •

•

Improved PDCCH performance The PDCCH OLLA (Outer Loop Link Adaptation) is needed to compensate various imperfections in the PDCCH ILLA (Inner Loop Link Adaptation) by dynamically adjusting the channel quality estimation per user Better utilization on PDCCH - no overdimensioning


Release


System release eNode B

NetAct

MME

SAE GW

RL30

-

-

-

LBTS3.0


4.22.3 Functional description Functional overview The eNodeB (evolved Node B) provides an enhancement to the dynamic adaptation of PDSCH and PDCCH block errors. When PDSCH (Physical Downlink Shared Channel) reaches its predefined target BLER (Block Error Ratio), the PDCCH achieves BLER 1%. PDCCH Link Adaptation The old solution is based on PDSCH OLLA. PDCCH offset is calculated as a sum of deltaCQI and deltaCQIShift, where deltaCQI is the PDSCH OLQC (Outer Loop Quality Control) offset already calculated from Ack/Nack/DTX (Discontinuous

152

© 2016 Nokia




Transmission) feedback from previous PDSCH transmission, and deltaCQIShift is a constant parameter to compensate the difference in BLER target (PDSCH - 10% and PDCCH - 1%). This algorithm is quite simple; however it may cause wasting of resources for PDCCH or too high error rate. The second disadvantage is that the parameter deltaCQIshift is the same for all UEs in the system. The new PDCCH Link Adaptation algorithm solves all these problems. It still uses deltaCQI from OLQC, but the CQI offset shift between PDSCH and PDCCH is dynamically adapted based on PDSCH NACK and DTX information. The control is based on UL HARQ (Uplink Hybrid Automatic Repeat Request) feedback (NACK vs DTX) that is sent in response to a DL (Downlink) PDSCH transmission (for more details see Figure 16: PDSCH and PDCCH link adaptation).

g

Note: PDSCH OLQC is a prerequisite for the usage of PDCCH OLQC and thus needs to be enabled by setting dlOlqcEnable to true. Figure 16

PDSCH and PDCCH link adaptation

4.22.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces


© 2016 Nokia

153



This feature has no impact on interfaces. Impact on network and network element management tools This feature affects BTS Site Manager / NetAc as follows: • •

Support of new O&M parameters Support of new PM counters (NetAct only: offline calculation for achieved BLER of PDCCH and DL HARQ response is needed)

Impact on system performance and capacity This feature improves PDCCH performance.

4.22.5 LTE1035:Outer Loop Link Adaptation for PDCCH management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 91: New counters lists counters introduced with this feature. Table 91

New counters

Counter ID

Counter name

Measurement

M8010C61

PDCCH allocations for PDSCH transmissions with HARQ reporting

8010 - LTE Power and Quality DL (WBTS)

M8010C62

PDCCH allocations for PDSCH transmissions with HARQ reporting for which eNB received no HARQ response from UE

8010 - LTE Power and Quality DL (WBTS)


New parameters

Full name

154

Abbreviated name

Managed object

Activate Outer Loop Link Adaptation

actOlLaPdcch

LNCEL

PDCCH and HARQ Response Target BLER

pdcchHarqTargetBler

LNCEL

© 2016 Nokia




Table 93: Related existing parameters lists existing parameters related to this feature. Table 93


Full name

Abbreviated name

PDCCH LA CQI shift

pdcchCqiShift




Sales information

BSW/ASW



BSW

-

-

© 2016 Nokia

155

Descriptions of transport and transmission features


5 Descriptions of transport and transmission features 5.1 LTE144: Transport Admission Control 5.1.1 LTE144: Transport Admission Control Introduction to the feature In LTE, it is assumed that Guaranteed Bit Rate (GBR) traffic is handled on the transport network with higher priority than other kinds of traffic. In order to support guaranteed bit rate, it is a common practice to permit GBR connections (traffic) only up to a certain committed bit rate. One technique of providing guaranteed bit rate is Connection Admission Control (CAC). CAC gives the possibility to restrict the number of connections (or, the bandwidth allocated to users) that is handled by the system. Two functional entities are used to support admission control: Radio Admission Control (RAC) and Transport Admission Control (TAC). RAC is in charge of controlling admittance based on resources available for the air interface. Information on available radio resources is obtained in C-plane via Radio Resource Management and via Radio Bearer Management units. TAC is in charge of controlling admittance based on available resources on the transport network. Both units need to co-operate in order to efficiently provide QoS to users, in particular by avoiding overload conditions on both the air interface and the transport interface. Basically, admittance to the system shall be granted if, at time of connection request, both RAC and TAC expect to have the resources available for the time the connection will be active.

5.1.1.1

Benefits This feature supports service stability. It ensures that new connections will only be admitted if there are sufficient transport resources available. It allows to split the available guaranteed transport bandwidth into a partition used for GBR traffic and a partition used for Non-GBR traffic. Controlled overbooking introduced in this feature allows optimized bandwidth usage.

5.1.1.2

Requirements Software requirements Benefits lists the software required for this feature. Table 95

Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-

Hardware requirements

156

© 2016 Nokia




This feature requires no new or additional hardware.

5.1.1.3

Functional description With the Connection Admission Control (CAC) function the eNodeB can accept or reject a connection request based on the current load situation. Whereas air interface resources are being checked with LTE20: Admission Control, LTE144: Transport Admission Control adds checking of available transport resources prior to accepting a bearer request. Transport Admission Control (TAC) ensures guaranteed transport of GBR traffic over the limited backhaul transport capacity. If OAM parameter TAC activity factor is set to 1, new GBR connections are admitted only as long as the operator-definable treshold is not exceeded by the summed up capacity of all connections. To ensure that Commited Information Rate (CIR) of the transport network is not exceeded, TAC thresholds should by set smaller or equal to CIR. To enable controlled overbooking, TAC activity factor needs to be set smaller than 1.

g

Note: Note that, if controlled overbooking is used (TAC activity factor is set < 1) the defined treshold, and consequently CIR, may be exceeded. In such case, packet loss may occur. TAC differentiates between: emergency, handover, and normal GBR calls. It is possible to implement different admission priorities for the admission of these calls, by using different bandwidth limits. The difference between CIR and TAC emergency limit is the minimum bandwidth available for non-GBR traffic. TAC is performed separately for DL and UL directions.The feature allows controlled overbooking by using a configurable overbooking factor. CAC related Performance Counters are provided.

5.1.1.3.1

User scenarios

g

Note: Example values are used in both scenarios presented in this section Two practically important users scenarios can be used with this feature: •

Restriction of the GBR traffic to Metro Ethernet CIR Assuming that Metro Ethernet is used as a transport network with a total bandwidth of 100 Mbit/s and a CIR of 10 Mbit/s and TAC is configured as follows: – – –

Emergency treshold value (OAM parameter: TAC limit GBR emergency) is set to 9.5 Mbit/s Handover treshold value (OAM parameter: TAC limit GBR handover) is set to 8.5 Mbit/s Normal treshold value (OAM parameter: TAC limit GBR normal) is set to 7 Mbit/s

All new GBR connections are accepted as long as the aggregated sum rate of GBR traffic does not exceed 7Mbit/s. Handover and emergency traffic would be accepted if the sum rate is between 7 and 8.5 Mbit/s. Only emergency calls would be accepted if the sum is between 8.5 and 9.5 Mbit/s. No connections would be accepted if the aggregated sum of GBR traffic exceeds 9.5 Mbit/s.


© 2016 Nokia

157


•


Note that the difference between CIR and the emergency threshold value is the bandwidth under CIR contract which is not considered by TAC (it can be saved for, for instance, Timing over Packet traffic or signalling traffic). Reservation of minimum bandwidth for non-GBR traffic Consider a plain Ethernet network with a total bandwidth of 100 Mbit/s is used as a transport network, at which a bottleneck bandwidth of 30 Mbit/s is expected somewhere between the eNodeB and S-GW. If the total GBR connections’ bandwidth needs to be limited to 10 Mbit/s in order to reserve a minimum bandwidth of 20 Mbit/s for non-GBR traffic the following configuration should be used: – – –

Emergency threshold value (OAM parameter: TAC limit GBR emergency) is set to 9.5 Mbit/s Handover threshold value (OAM parameter: TAC limit GBR handover) is set to 8.5 Mbit/s Normal threshold value (OAM parameter: TAC limit GBR normal) is set to 7 Mbit/s

If this configuration is used, every kind of traffic is accepted as long as the aggregated sum rate of GBR traffic does not exceed 7Mbit/s. Handover and emergency traffic would be accepted if the sum rate is between 7 and 8.5 Mbit/s. Only emergency calls would be accepted if the sum is between 8.5 and 9.5 Mbit/s. No connections would be accepted if the aggregated sum of GBR traffic exceeds 9.5 Mbit/s.

g

Note: Values set for the three limits must always meet the following condition: TAC limit GBR emergency > TAC limit GBR handover >

TAC limit GBR normal

5.1.1.3.2

Feature limitations Transport Admission Control is limited by five major factors which are inherent to the approach and need to be clearly understood: •

•

•

•

5.1.1.4

TAC has no information about the traffic situation for any other eNB, routers in the transport backhaul network, nor about core network elements (SAE gateway, MME). It cannot work on a per-route basis, but only use the information it has available at the eNB where it is located. TAC makes a decision to accept or reject a connection only at the time of connection setup request. For GBR traffic, information about the expected bit rate is available at this moment. Non-GBR connection requests are always accepted. There is no knowledge and no control about the future user behavior. There is no policing functionality that enforces user behavior as announced at connection set-up time. TAC expects that GBR traffic will be handled with higher priority than non-GBR traffic in the transport scheduler and in the transport network. However, mapping of traffic types to priorities (DSCP or PCP values) is configured by the operator. Inappropriate assignments may lead to unexpected behavior. TAC is applied to the user traffic only. Other traffic which is not necessarily visible on the air interface, but provides additional load on the transport network, like for example: Timing over Packet data, must be considered in the dimensioning of TAC.

System impact Interdependencies between features

158

© 2016 Nokia




This feature cooperates with LTE20: Admission Control to efficiently provide QoS to users, in particular by avoiding overload conditions on both the air interface and the transport interface. Impact on interfaces This feature has no impact on transport network interfaces. Impact on network and network element management tools This feature prevents overloading of the transport network. Configuration options for this feature were added in the BTS Site Manager interface. Impact on system performance and capacity This feature improves network stability and enables optimal bandwidth utilization with the use of controlled overbooking.

5.1.1.5

LTE144: Transport Admission Control management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 96: New counters lists counters introduced with this feature. Table 96

Counter ID

New counters

Counter name

Measurement

M51136C5

tacRejectedGbrEmergency

Number of rejected GBR emergency connections

M51136C4

tacRejectedGbrHandover

Number of rejected GBR handover connections

M51136C3

tacRejectedGbrNormal

Number of rejected normal connections

M51136C2

tacSuccessfulGbrEmergency

Number of successful emergency connections

M51136C1

tacSuccessfulGbrHandover

Number of successful handover connections

M51136C0

tacSuccessfulGbrNormal

Number of successful normal connections

Key performance indicators There are no key performance indicators related to this feature. Parameters


© 2016 Nokia

159



Table 97: New parameters lists parameters introduced with this feature. Table 97

New parameters

Full name

Abbreviated name

Managed object

LTAC identifier

ltacId

LTAC

TAC activity factor

tacActivityFactor

LTAC

Exclude layer 2 overhead

tacExludeL2Overhead

LTAC

TAC limit GBR emergency

tacLimitGbrEmergency

LTAC

TAC limit GBR handover

tacLimitGbrHandover

LTAC

TAC limit GBR normal

tacLimitGbrNormal

LTAC

TAC identifier

tacId

TAC

Table 98: Additional parameters for RL40 lists parameters introduced with RL40 for this feature. Table 98

Additional parameters for RL40

Full name

5.1.1.6

Abbreviated name

Managed object

Average Packet Size For QCI Value 2

qci2AvPacketSize

LTAC


qci3AvPacketSize

LTAC


qci4AvPacketSize

LTAC

Sales information Table 99

Sales information

BSW/ASW



BSW

-

-

5.2 LTE574: IP Transport Network Measurements Introduction to the feature

160

© 2016 Nokia




The LTE574: IP Transport Network Measurements feature provides active measures and supervision of the conditions through the mobile backhaul transport network between two points, for example: • •

eNB and SEG eNB and other (third party) site router or measuring equipment

Measuring and supervising is based on RFC863 UDP Echo and/or RFC5357 Two Way Active Measurement Protocol (TWAMP).

5.2.1 Benefits This feature brings OPEX savings as the operator is able to monitor the network conditions and can react quickly to potential service degradations. The measurements provide an indication of possible violations against an SLA (Service Level Agreement). CAPEX savings are obtained, because the built-in measurement obsoletes expensive measurement equipment that would be otherwise required to supervise and troubleshoot the network.


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-


5.2.3 Functional description The feature LTE574: IP Transport Network Measurements introduces a possibility to actively measure and supervise the conditions through the mobile backhaul transport network between two points, using RFC863 UDP Echo and RFC5357 TWAMP protocols (TWAMP light). Measurements can be performed, for example, between the eNB and SEG, between eNB and other site router or measuring equipment or between two eNBs (X2 interface measuring). The purpose of the measurement is to have an estimation of the quality and performance of the IP-based mobile backhaul. If the measured values fall under configurable thresholds, an alarm is raised. With this feature it is possible to carry out the measurements with different, configurable DiffServ Code points and packet sizes. All measurements are performed on IP layer. Thus, either physical or virtual interfaces can be measured if only IP address is assigned. This feature allows the eNB to take part in measurements in three different roles:


© 2016 Nokia

161


•

TWAMP measurement sender (initiator) - the eNB actively sends and receives test traffic. The following values are measured: – –

• •

g


Round-trip time (RTT) Round-trip Packet Loss Ratio (PLR)

TWAMP responder - the eNB reflects the received test traffic after adding receive and transmit timestamps towards the entity which carries out the measurement. UDP echo server -to support measurement senders without TWAMP capability, the eNB provides an UDP Echo service according to RFC862. The eNB only reflects the received test traffic without adding any further information towards the entity which carries out the measurement. The echoed packets have the same DSCP value and the Do Not Fragment flag (DF) is copied as well. Note: The total traffic which is reflected by the eNB UDP Echo server and TWAMP responder applications is restricted by a rate limiter to 100 packets per second. The purpose of the rate limiter is to avoid Denial of Service attacks.

TWAMP packet formats Figure 17: Packet formats gives an overview on the TWAMP packet formats (both for request and response packet). Figure 17

Packet formats Sender TTL (8bit)

PacketPadding

SenderErrorEst.(16bit)

MBZ(16bit)

Sender Timestamp(64bit) Sender SequenceNumber(32bit) Reciving TimestampatReflector(64bit) PacketPadding

ErrorEst.(16bit)

MBZ(16bit)

ErrorEst.(16bit)

TransmitTimestampatSender(64bit)

Transmit TimestampatReflector(64bit)

SequenceNumberatSender(32bit)

SequenceNumberatReflector(32bit)

UDP

UDP

IP

IP

Layer2

Layer2

Packetformatfor Session-Sender

Packetformatfor Session-Reflector

The TWAMP sender sends presented packet to the configured end-point of the measurement. The sequence number field carries the information about the number of the packet according to the transmit order (it starts with zero and is incremented one for each packet). The Error Estimate specifies the estimate of the error and synchronization. The Timestamp field is used to calculate packet delay. To ensure the same measurement conditions, it is reccomended that session-sender and session-reflector packets have the same length. This can be achieved with the use of the Packet Padding field.

162

© 2016 Nokia




In the packet format for session-reflector the Sender Sequence Number, Sender Timestamp and Sender Error Estimate fields are copied from the received packet and TTL 255 is set. The MBZ abbreviation stands for Must Be Zero statement. That means that all bits are equal to zero.

5.2.3.1

Measured values Round-Trip Time (RTT) based on two timestamps When the reflector has an UDP echo server implemented, the round-trip time (RTT) is calculated based on 2 timestamps (Figure 18: RTT based on two timestamps). The RTT is defined as the difference between the timestamp when the reply packet was received (Receive Timestamp Sender - RTSS) and the timestamp when the measurement packet was initially sent (Transmit Timestamp Sender - TTSS. The equation for calculation the RTT based on two timestamps is as follows: RTT = RTSS - TTSS The minumum, maximum and average values of the round-trip time are presented for both 1 minute and 15 minutes time interval via the BTS Site Manager application. Figure 18

RTT based on two timestamps T TTSS S G

TWAMP Sender

T S G RTSS

TWAMPmessagecontainingTTSS

ReflectedTWAMPmessagecontainingTTSS

UDPEcho Server

TSG:TimeStampGenerator TTSS:TransmitTimeStampatSender RTSS:Received TimeStampatSender

Round-Trip Time (RTT) based on four timestamps When the reflector has a TWAMP responder implementation, the round-trip time (RTT) is calculated based on four timestamps (Figure 19: RTT based on four timestamps). The RTT is defined as the difference between the timestamp when the reply packet was received (Receive timestamp Sender - RTSS) and the timestamp when the measurement packet was initially sent (Transmit Timestamp Sender - TTSS). This delay value is corrected by eliminating the internal processing time at the reflector side, which is defined as the difference between Transmit Timestamp Reflector (TTSR) and Receive Timestamp Reflector (RTSR). The equation for calculation the RTT based on four timestamps is as follows: RTT = RTSS - TTSS - (TTSR - RTSR) The minumum, maximum, and average values of the round-trip time are presented for both 1minute and 15 minutes time interval via BTS Site Manager application.


© 2016 Nokia

163


Figure 19

RTT based on four timestamps T S G

TWAMP Sender


TTSS

RTSR

TWAMPmessagecontainingTTSS

TWAMPmessagecontainingTTSS, RTSRandTTSR

T S RTSS G

T S G

T S TTSR G

TWAMP Reflector

TSG:TimeStampGenerator TTSS:TransmitTimeStampatSender RTSR:Receive TimeStampatReceiver TTSR: TransmitTimeStampatReceiver RTSS:Received TimeStampatSender

Two-way packet loss When the responder node has a TWAMP reflector implementation, it is possible to calculate the two-way packet loss. The eNB sends TWAMP request packets towards the reflector entity with a sequence number according to the transmit order (it starts with zero and is incremented one for each packet). The reflector copies the sequence number from the received test packet to the corresponding field in the header of the response packet and sends it back to the measurement initiator. The two-way packet loss is defined as a difference between the total amount of sent measurement packets and the number of all response packets received at the eNB during the measurement time interval. The packet loss ratio statistics are presented for each 15 minutes measurement time interval via the BTS Site Manager (BTSSM) application.

5.2.3.2

User scenarios Three different use case secnarios can be applied: •

eNB as TWAMP sender, SEG/site router/external PC as TWAMP responder or UDP Echo server The reflector must mirror the test traffic, which may or may not include the insertion of receive/transmit time stamps,. The eNB must be able to calculate the roundtrip delay both from packets with and without these time stamps (Figure 20: User scenario 1). Figure 20

User scenario 1

L2/L3 Transport Network

eNB =TWAMPsender

SecurityGatewayor externalPCwith analyzertool=TWAMPresponderor UDPechoserver

ExternalPC

•

164

eNB as TWAMP responder, SEG/site router/external PC as TWAMP sender

© 2016 Nokia




This configuration would allow starting the measurement from a central site towards the eNB. The drawback of this usage is that the measurement results are available at the SEG/site-router only. How to retrieve this data and present it in the management system depends on the used router device (Figure 21: User scenario 2). Figure 21

User scenario 2

L2/L3 Transport Network SecurityGatewayor externalPCwith analyzertool=TWAMPsender

eNB =TWAMP responder

ExternalPC

•

eNB as UDP Echo server, SEG/site router/external PC as UDP sender The eNB supports the UDP Echo functionality which allows reflecting received UDP measurement traffic on the standard port back. The UDP test traffic is generated and sent by the SEG, a site router or an external PC, which also analyzes the results and presents the statistics to the operator (Figure 22: User scenario 3). Figure 22

User scenario 3

L2/L3 Transport Network SecurityGatewayor externalPCwith analyzertool=UDP sender eNB =UDPechoserver

ExternalPC

g 5.2.3.3

Note: There are no particular limitations to be taken into account when IPSec is used. The IP measurements can be done inside the IPSec tunnel or outside the tunnel.

Feature limitations If IP network measurements are performed inside IPsec tunnel, measurement packets are naturally encrypted/decrypted by IPsec termination points. However, neither authenticated nor encrypted measurement messages are supported outside the IPsec tunnel.

5.2.4 System impact Interdependencies between features This feature has no interdependencies with other features. Impact on interfaces


© 2016 Nokia

165



This feature has no impact on interfaces. Impact on network and network element management tools This feature introduces new operator configurable parameters. Impact on system performance and capacity This feature has a small impact on eNB performance due to sending/receiving measurement traffic. TWAMP test traffic has a minor influence on capacity of transport linkfrom/towards the eNB. The operator needs to take this capacity into account. • •

8kbps for default values (rate limit: 10messages/second; message size: 100B) 120 kbps for maximum values (rate limit: 10 messages/second; message size: MTU=1500 B)

5.2.5 LTE574: IP Transport Network Measurements management data For information on alarms, counters, key performance indicators, and parameter documents, see Reference documentation. Alarms lists existing alarms related to this feature. Table 101

Related existing alarms

Alarm ID 7665

Alarm name BASE STATION TRANSMISSION ALARM The following LTE574 relevant BTS Faults are related to this alarm: •

61610 TWAMP RTT Threshold Crossed

•

61611 TWAMP PLR Threshold Crossed

Measurements and counters lists counters introduced with this feature. Table 102

New counters

Counter ID

166

Counter name

Measurement

M51132C0

avgRTT_15Min

LTE TWAMP Statistics (TWAMP)

M51132C1

maxRTT_15Min


M51132C2

minRTT_15Min


© 2016 Nokia



Table 102



Counter ID

Counter name

Measurement

M51132C3

lostTwampMessages


M51132C4

txTwampMessage


Key performance indicators There are no key performance indicators related to this feature. Parameters lists parameters introduced with this feature. Table 103

New parameters

Full name


Abbreviated name

Managed object

Feature Activation Flag IP Transport Network Measurements

twampFlag

IPNO

TWAMP reflector and udp echo flag indicator

actIpTnlMeasure

IPNO

TWAMP application or IP interface address

twampIpAddress

IPNO

TWAMP message response enabling flag

twampReflFlag

IPNO

UDP echo flag

udpEchoFlag

IPNO

TWAMP initiator rate for sending messages

twampMessageRate

IPNO

TWAMP reflector port number

twampReflectorPort

IPNO

Lock or unlock a TWAMP session

administrativeState

TWAMP

TWAMP session destination IP address

destIpAddress

TWAMP

TWAMP session destination port

destPort

TWAMP

DSCP value for TWAMP message transmission

dscp

TWAMP

TWAMP initiator message size

messageSize

TWAMP

Packet loss ratio alarm threshold

plrAlarmThreshold

TWAMP

Round-trip-time alarm threshold

rttAlarmThreshold

TWAMP

© 2016 Nokia

167


Table 103



Full name

Abbreviated name

Managed object

TWAMP initiator messages source IP address

sourceIpAddress

TWAMP

TWAMP session identifier

twampId

TWAMP


Sales information

BSW/ASW



ASW

-

-

5.3 LTE866: Fast IP Rerouting Introduction to the feature Fast IP Rerouting feature introduces path switchover mechanism that is able to: • •

define Primary Path (preferred) and Alternative Path (redundant) in the L2 network reroute traffic from failed path over working path (with switchover time tolerable for an end user

L3 Bidirectional Forwarding Detection (BFD) described in LTE592: Link Supervision with BFD is used to detect failures.

5.3.1 Benefits End-user benefits This feature improves network reliability. Operator benefits This feature benefits the operator as follows: • • •

IP network reliability is improved redundant routers are introduced switchover time tolerable for an end user

5.3.2 Requirements Software requirements Table 105: Software requirements lists the software required for this feature.

168

© 2016 Nokia



Table 105

Release



System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-


5.3.3 Functional description LTE866: Fast IP Rerouting introduces redundancy mechanism, which protects against the failures of: • •

5.3.3.1

L2 network between an eNB and a redundant pair of routers one of the redundant routers

Network access scenarios Single backhaul link The eNB is connected to the R1 (Primary Router) and the R2 (Alternative Router) through aggregating/distributing L2 network, possibly with many other eNBs connected.The path between the L2 switch and the routers must be loop-free. See, Figure 23: Single backhaul link. Traffic of all eNBs aggregated in the Primary Path is protected. Depending on the Primary Path BFD supervision status the traffic is transported either over the Primary Path or the Alternative Path. Figure 23

Single backhaul link R1Primary Router(PR)

eNB

PrimaryPathforULandDLtraffic

R2Alternative Router(AR)

AlternativePathforULandDLtraffic BFDControlPath

Dual backhaul link


© 2016 Nokia

169



Two eNB network interfaces are connected through direct physical links with routers R1 and R2. The internal eNB L2 switch aggregates/distributes the traffic. See, Figure 24: Dual backhaul link. Depending on the Primary Path BFD supervision status the traffic is transported either over the Primary Path or the Alternative Path. Figure 24

Dual backhaul link R1Primary Router(PR)

eNB

PrimaryPathforULandDLtraffic

R2Alternative Router(AR)

AlternativePathforUL andDL traffic BFDControlPath

5.3.3.2

Recommended router configuration In this example U, C and M-Planes are bound to eNB Virtual IP addresses, whereas the S-Plane (ToP) is bound to the single eNB IP address. See, Figure 25: Rerouting example. Figure 25

Rerouting example

static!entries!in!eNB!internal!router’s!routing!table default!via!80.2.3.1!(pref=1,!bound!to!BFD) default!via!80.2.3.2!(pref=5,!not!bound!to!BFD)

internal router

static!entries!in!PR’s!routing!table 80.2.3.3/32!via!80.2.3.3!(pref=1,!bound!to!BFD) 80.2.3.3/32!via!AR2!(pref=5,!not!bound!to!BFD)

network interface

PR PR1

BFD

U Virtual IPs

80.2.3.1

PR2

80.2.3.3

80.2.3.0/24

C M S eNB

AR2 80.2.3.2 AR1

AR

Primary!Path!for!UL!and!DL!traffic Alternative!Path!for!UL!and!DL!traffic BFD!Control!Path

static!entry!in!AR’s!routing!table 80.2.3.3/32!via!80.2.3.3!(pref=5,!not!bound!to!BFD)

The simple static route configuration is presented for clarity, but it has a limitation. Namely, the DL traffic towards eNB must always come through the PR. Otherwise possibly incoming traffic in AR would be immediately forwarded over the Alternative Path to the eNB.

170

© 2016 Nokia




In practice static routes and routing protocols should be used in combination to increase flexibility. This way, the DL traffic is allowed to come through PR and/or AR. PR and AR functionality configuration To keep this rerouting example simple, PR functionality is fully assigned to R1 and AR functionality is fully assigned to R2. Nevertheless it is recommended to evenly split utilization of R1 and R2 routers between PR and AR functionalities. Then, PR and AR roughly handle half of eNB nodes each. In such configuration support for BFD bound static route function is required for routers R1 and R2.

5.3.3.3

The eNB static route selection In a standard routing table two static entries towards the same destination lead to a route conflict (as long as the BFD bound Static Route entry is active). Route preference has been introduced as an additional priority indicator to prevent the conflict. Note that router vendors use Administrative Distance (AD) term instead of route preference. The lower the route preference value is, the higher the route priority. Static routes have low default values (typically 1). Routes established by routing protocols have lower priority. Route selection consists of the following steps: 1. deactivate downstate BFD bound static routes 2. select the route with the lowest route preference value 3. select the IP destination address with the longest prefix match (if needed) Table 106: BFD bound and regular static routes in the internal eNB router and Table 107: Route selection help to explain the rerouting:

Table 106

BFD bound and regular static routes in the internal eNB router

Route type

Destination IP address

Destination IP subnet mask

BFD session ID

Route preference

Next hop IP address

BFD bound static

SEG X IP address

subnet U

BFD-1

1

PR IP address

static (regular)

SEG X IP address

subnet U

0 (no protection)

5, (>1)

AR IP address

BFD bound static

SEG Z IP address

subnet W

BFD-1

1

PR IP address

static (regular)

SEG Z IP address

subnet W

0 (no protection)

5, (>1)

AR IP address


© 2016 Nokia

171


Table 107

Route selection

BFD session state

5.3.3.4


Up

Down

Action

The route with the lower route preference value is chosen.

When the BFD bound static route is inactive, the only remaining static route is chosen.

Result

Primary Path is used.

Alternative Path is used.

Supervision of the Alternative Path Although Alternative Path can fail, switchover protection for Alternative Path is not supported. Supervision of the Alternative Path only gives the path availability status. Therefore AR BFD session should use low control packet rate (as opposed to Primary Path BFD session). Then, router’s processor is used more efficiently. Switchover process is exclusively controlled by the Primary Path BFD monitoring. This applies for both: switchover to the Alternative Path as well as switchover to the Primary Path. BFD supervision of the Alternative Path is preferable over other methods (like Ethernet OAM) because it is done at the same level, and therefore is easier to correlate.

5.3.3.5

PR and AR router failures Routing tables of PR router and AR router contain: • • •

static routes BFD bound static routes routes created by routing protocols

PR failure scenario Routing protocols in PR and AR distribute all static route entries to all routers. When the failure occurs R3 takes over the tasks of PR and sends all eNB traffic through AR as follows: 1. PR router fails, and breaks the Primary Path. 2. The eNB reroutes the traffic to the Alternative Path. 3. Failure is detected in one of the routers (for example R3, R4, AR) using HELLO or BFD messages. 4. Routes imported through routing protocols are removed from the routing tables. 5. Only Alternative Path route is being exported to the AR. LTE866: Fast IP Rerouting feature monitors path availability. As soon as the Primary Path recovers, the traffic is rerouted back from the Alternative Path.

172

© 2016 Nokia




Figure 26

Primary Path failure

internal router

indirect&directBFDboundstaticrouters, routingprotocolsactive

network interface

PR

nostaticrouters, routingprotocolsactive

R3

PrimaryPath BFD1 U Virtual IPs

exportofstatic routersthroughRP

C M S eNB

AlternativePath

AR

indirect&directstaticrouters, routingprotocolsactive

R4 nostaticrouters, routingprotocolsactive

AR failure scenario If eNB traffic is routed over PR, the AR failure has no impact. When AR failure occurs: 1. Alternative Path failure is detected and reported by routing protocols. 2. Relevant changes in routing tables are made.

5.3.3.6

Switchover time The accumulated detection and rerouting times should not generate significant service impacts (like loss of established calls). Effective switchover time below 2.0 seconds provides a good compromise between service impact and reliable failure detection. Nevertheless U, C, M, S-plane traffic and, optionally transport IPsec tunnels are interrupted during the detection and rerouting event. C- and U-Plane have their own path supervision mechanisms with specific algorithms, which tolerate short interruptions. With default SCTP and GTP-U supervision values, alarms are not raised given the switchover time is below 2 seconds. IPsec with Dead Peer Detection (DPD) supervision mechanism also tolerates Fast IP Rerouting path failure conditions, if default DPD values are configured.

5.3.3.7

eNB VLAN/E-LAN configuration E-LAN is a multipoint to multipoint Ethernet Virtual Connection (EVC). If VLANs are to be used in combination with the Fast IP Rerouting function, the recommended solution is that an E-LAN structure is chosen. For the rerouting, the eNB as well as both routers must be part of that E-LAN. It is also possible to include not only a single eNB into the ELAN, there could also be multiple eNBs within that E-LAN. E-LAN configuration is in responsibility of Metro Ethernet Network (MEN) transport provider. Presently E-LANs are supported, but point-to-point connections with dedicated VLAN ID for each pair of points (E-LINEs) are not supported. The number of supported VLANs and the maximum network size between eNBs and Primary Router depend on the PR router(s) specifications. See Figure 27: VLAN configuration example.


© 2016 Nokia

173


Figure 27


VLAN configuration example

U,C,S-Plane = Application IPaddress

VLAN1 interface IPaddress

PR

U C eNB S M

VLAN1

VLAN2

MPApplication = IPaddress

VLAN2 interface IPaddress

AR

Following VLAN control approaches are supported by eNB: • •

a single BFD session is created within each VLAN a single BFD session within one of the VLANs controls the rerouting within all VLANs The second option is possible only if the router supports binding of multiple static routes to a single BFD session.

5.3.4 System impact Interdependencies between features LTE592: Link Supervision with BFD feature needs to be activated. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools Following actions can affect the network: • • • •

installation of an Alternative Path interconnection of an Alternative Router configuration during initial startup reconfiguration during operation

Impact on system performance and capacity •

ToP sync packet stream Switchover causes a delay impact and possibly a loss of few ToP sync packets. It is possible to keep the synchronization accuracy with a maximum of 6 reroutings a day.

5.3.5 LTE866: Fast IP Rerouting management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature.

174

© 2016 Nokia




Measurements and counters There are no measurements and no counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters lists parameters introduced with this feature. Table 108

New parameters

Full name

Abbreviated name

Managed object

BFD session activation flag

bfdActivation

BFD

BFD session admin down state control

bfdAdminUp

BFD

Destination IP address for the BFD session

bfdDestAddress

BFD

BFD session packets lost detection time multiplier

bfdDetectMult

BFD

BFD group reference

bfdGrp

BFD

BFD session identifier

bfdId

BFD

Source IP address for the BFD session

bfdSourceIpAddr

BFD

UDP source port of the BFD session

bfdSourceUdpPort

BFD

BFD session type

bfdType

BFD

Desired minimum BFD control word transmit interval

desMinTxInt

BFD

Required minimum BFD control word receive interval

reqMinRxInt

BFD

BFD identifier

bfdGrpId

BFDGRP

Feature Activation Flag For Fast IP Rerouting

actFastIpRerouting

IPNO

BFD Holdup time delay for reinstalling the protection

bfdHoldUpTime

IPNO

BFD route protection session identifier

bfdId

IPRT

Preference value of the route

preference

IPRT

Diff Serve Code Point value

dscp

QOS

Traffic type name

trafficType

QOS

Table for mapping traffic types to DSCPs

trafficTypesMap

QOS


© 2016 Nokia

175




Sales information

BSW/ASW



ASW

-

-

5.4 LTE931: Ethernet Jumbo Frames Introduction to the feature The default MTU value on Ethernet interfaces for IP packets is 1500 bytes. It means that if IP packet size exceeds 1500 bytes it is either dropped (DF=1) or fragmented (DF=0) depending on Don't Fragment flag value in the IP header. With the Ethernet Jumbo Frames feature, the MTU value for transport IP packets is raised up to 1608 for IPv4. Figure 28

Overhead of IPsec protected IPv4 packet - the largest MTU case max1608bytes

Sizeinbytes Field

20 TunnelIP

24

20

ESP

TransportIP

8 UDP

8 GTP-U

1500 UserIPpacket

14

2

12

Padding

PL/NH

Auth

nx16bytes(max97x16=1552bytes)

In this scenario, HMAC-SHA-1-96 hash function is used. Encapsulating Security Payload (ESP) protocol provides integrity, confidentiality and origin authentication to the payload of a transport IP packet. The ESPfield consists of: • • •

Security Parameter Index (SPI) Serial Number (SN) Advanced Encryption Standard (AES) Initialization Vector

The MTU for user IP packets remains 1500. Note that IPv6 is not supported in RL30, but will be introduced in a future release. The PL/HN field contains Padding Length/Next Header data.

5.4.1 Benefits End-user benefits This feature improves network performance. Operator benefits

176

© 2016 Nokia




The main purpose of this feature is to eliminate fragmentation/reassembly of transport IP packets containing 1500 byte user packets which make up a significant part of the total traffic. Thanks to Ethernet Jumbo Frames feature, operators can avoid the following overhead: • •

unnecessary processor load additional volumes of data


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-


5.4.3 Functional description The eNB determines maximum packet length at the higher layers by subtracting LTE transport overhead from the MTU. The larger MTU, the less overhead is carried. If a user IP packet size is close to 1500 bytes, transport PDU (transport IP packet) size exceeds the MTU treshold due to additional overhead. This in turn results in a need either to fragment and reassemble all such packets or to find alternative solution. MTU configuration MTU must be configured manually on all nodes at the Ethernet interfaces, with the exception of eNB nodes, which applies a single MTU parameter to all its Ethernet interfaces. When introducing or configuring new node, its MTU must not be higher than the lowest MTU in the end to end path. Selecting optimal fixed and universal LTE transport layer MTU is not trivial because: • • • •


LTE system has no direct control over MTU of user IP packets optional use of IPsec tunnel mode introduces high overhead some UEs use a fixed MTU, but there is no standard that would enforce fixed MTU 3GPP does not mandate the use of Path MTU Discovery in the UE

© 2016 Nokia

177


5.4.3.1


C-plane and M-plane transport IP packet fragmentation Segment size to be used in both directions is determined during TCP/SCTP handshake by an exchange of: Maximum Segment Size and Minimum Segment Size. Therefore, packets are automatically limited to a size which does not require IP layer fragmentation. This condition is not fulfilled only if L2 network with a lower MTU is located along the path. Router fragments IPv4 packets from an eNB when forwarding them to a peer node with a lower MTU only if the both conditions are met: • •

5.4.3.2

L3 packet size exceeds the MTU on the router interface. Don't Fragment (DF) bit in the IP header is set to 0.

Jumbo Frame switching Support for Ethernet Jumbo Frames on all the transport interfaces solves the issue of fragmentation and reassembly. In heterogeneous networks (connecting devices with different operating systems and protocols) nodes can have different MTU values assigned. Radio access networks in turn are expected to have the same MTU value set at a given interface. Note that it does not mean that MTU is the same throughout the PLMN. IPsec usage is another potential reason for non-uniform MTU. Figure 29

Differences in MTU value throughout the network MTU=1536bytes

MTU=1536bytes

MTU=1608bytes IPv4Operator Network

SEG SEG

S-GW MTU=1500bytes

MTU=1608bytes

MTU=1500bytes

MTU=1608bytes IPv4Operator IPv4Transport Network Network

IPv4Operator Network

SEG

Router

SEG

eNB

MME

O&M

ToP networksegment

networksegmentsupportingjumoframes networksegmentnotsupportingjumoframes

5.4.3.3

Feature limitations It is critical to consider support for Jumbo Frames, already at network planning phase, because: • •

178

Jumbo Frames are not in line with the IEEE802.3 standard L2 switches discard Jumbo Frames

© 2016 Nokia



• • •


switching security configuration is likely to affect end to end support for Jumbo Frames avoiding fragmentation of long user packets is possible only if all transport nodes in the path support Jumbo Frames (including SEG and S-GW) if S-GW does not support Jumbo Frames (with MTU of at least 1536), uplink user packets will have to be fragmented in the SEG

Moreover DF flag needs to be set to 0 if Ethernet Jumbo Frames feature is to be used. This way C, M and S plane packets originating from the following nodes: • • • •

MME OMS ToP Master other O&M servers (CMP, LDAP, Traffica, ToolPC, Trace)

can be fragmented and reach the destination, even if the named nodes do not support Jumbo Frames.

5.4.4 System impact Interdependencies between features This feature has no interdependencies. Impact on interfaces This feature affects external Ethernet interfaces of the eNB, namely interface towards the transport network, as well as the interfaces towards other eNBs. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity This feature improves system performance and has no impact on capacity.

5.4.5 LTE931: Ethernet Jumbo Frames management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters lists parameters introduced with this feature.


© 2016 Nokia

179


Table 111


New parameters

Full name

Abbreviated name

Maximum transfer unit

mtu

Managed object IEIF

There are no modified nor existing parameters related to this feature.


180

Sales information

BSW/ASW



BSW

-

-

© 2016 Nokia



Descriptions of operability features

6 Descriptions of operability features 6.1 LTE424: Automatic interface alarm correlation Introduction to the feature This feature minimizes the number of alarms reported in NetAct which are related to central interfaces (X2, S1) or entity problems either during setup or loss of an established connection. It is beneficial especially in the flat LTE architecture where a failed connection/node can cause a high number of alarms related to the same failure. With the alarm correlation, only a dedicated alarm is reported to the operator.

6.1.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits In case of problems with central interfaces (X2, S1), the operator receives a dedicated correlated alarm instead of many uncorrelated alarms.


Release


System release

eNode B

NetAct

MME

SAE GW

RL30

LBTS3.0

OSS5.3 CD3

-

-

NetAct Monitor 7


6.1.3 Functional description This feature reduces the number of alarms reported in NetAct by correlating the alarms caused by problems with S1 and X2 interfaces. Also alarms caused by a GTPU path failure, SCTP path failure, or SCTP endpoint failure are in the scope of this feature. The eNB-related interface failures are reported using new interface-specific alarms (BASE STATION CONNECTIVITY LOST, BASE STATION CONNECTIVITY DEGRADED). The Flexi Multiradio BTS provides the correlation information in the alarm message. Alarm correlation example


© 2016 Nokia

181


Figure 30


Alarm correlation example Alarm:!BTS!Connectivity!Degraded Object:!LNBTS-3!/!LNADJ-3 BTS!fault:!X2!endpoint!failure Connection!ID: ‘destination!IP’ Connection!type:!X2

LNBTS3 Alarm:!new!alarm!(created!in!NetAct) Object:!X2_LinkGroup BTS!fault:!X2!local Connection!ID: ‘destination!IP’ Connection!type:!X2

LNBTS4

CoreNetwork Alarm:!BTS!Connectivity!Degraded Object:!LNBTS-1!/!LNADJ-2 BTS!fault:!X2!endpoint!failure Connection!ID: ‘destination!IP’ Connection!type:!X2

LNBTS1 LNBTS2 Alarm:!BTS!Connectivity!Degraded Object:!LNBTS-2!/!LNADJ-4 BTS!fault:!X2!endpoint!failure Connection!ID: ‘destination!IP’ Connection!type:!X2

Three objects (LNBTS 1, 2, 3) have the same adjacency relation to the LNBTS 4 object. If these three objects detect an LNBTS 4 X2 interface failure, they raise three independent alarms (X2 endpoint failure of an adjacent object). These alarms are sent to NetAct through OMS independently. When NetAct receives the alarms and the alarm correlation mechanism is activated (the correlation rule is fulfilled), the particular alarms will be suppressed. Only one alarm, targeted at an X2 link group object (these kind of link groups are artificial objects available in NetAct for correlation purposes), is shown in NetAct and the user can check all the correlated alarms in the alarm correlator view (see Figure 31: NetAct alarm correlator view).

g

182

Note: The alarm correlator GUI is available only in NetAct Monitor 7.

© 2016 Nokia



Figure 31


NetAct alarm correlator view

Alarm correlation principles All the X2, S1, SCTP, or GTPU related logical connections are modeled based on the destination IP address and the fault ID (part of alarm additional information field). NetAct uses this information to correlate the alarms. If one or more alarms with the same destination IP address information are reported, they are suppressed and only one new common alarm (for all failures targeted to the particular object) is raised. OMS forwards the destination IP address information in the alarms to NetAct. Figure 32: New alarms for reporting interface faults shows how certain faults are mapped with alarm objects and alarms. Figure 32

Failures

Alarming objects

Alarms

New alarms for reporting interface faults SCTP path failure onS1

SCTP endpoint failure onS1/X2

SCTP

GTPU path failure onS1

SCTP endpoint failure onS1 (lastS1link)

GTPU

SCTP

BaseStation Connectivity Degraded

BaseStation ConnectivityLost

Additionalinfo: SCTP/GTPU pathalarminS1/X2

g


Additionalinfo:SCTP interfacealarm/ S1RetryOut

S1setup/reset retryout

X2setup/reset retryout

LNMME

LNADJ



Additionalinfo: S1RetryOut

Additionalinfo: X2RetryOut

Note: The BASE STATION CONNECTIVITY LOST alarm is generated only if the last SCTP connection on the interface and/or the last S1 interface is lost.

© 2016 Nokia

183



The alarm correlation is cancelled when the corresponding alarms are cleared.

6.1.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools A significantly smaller number of alarms reported in NetAct alarm monitoring tools. Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.1.5 LTE424: Automatic interface alarm correlation management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms lists alarms introduced with this feature. Table 114

New alarms

Alarm ID

Alarm name

7656

BASE STATION CONNECTIVITY LOST

7657

BASE STATION CONNECTIVITY DEGRADED

Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

184

© 2016 Nokia





Sales information

BSW/ASW



ASW NetAct

NetAct

-

6.2 LTE459: LTE Timing Advance Evaluation Introduction to the feature Timing Advance (TA) is necessary to have synchronized communication between the UE and the eNB. The TA value can be used to estimate the radial distance between the UE and the transceiver and to compensate the time a signal needs to travel this distance. The possibility to trace TA values allows the operator to: • • •

locate high and low traffic areas in the cell create a geographical view of user distribution in the cell obtain dropped call statistics

The timing advance has a limited scope and accuracy (78m for the UE - eNB distance) and does not provide enough information for location services.

6.2.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits With the timing advance values measured and calculated in the Flexi Multiradio BTS, the operator gets additional data for analysis of the network performance in a cell. The measurements can be used for network planning, troubleshooting, and optimization purposes.


Release


System release

eNode B

NetAct

MME

SAE GW

RL30

LBTS3.0

OSS5.3 CD3

-

-



© 2016 Nokia

185



6.2.3 Functional description This feature introduces the TA evaluation in the Flexi Multiradio BTS as part of the vendor specific extension tracing. For each UE with a Media Access Control (MAC) resource assigned, the BTS calculates the instantaneous TA value in real time. This value is captured in the U-plane MAC layer. MAC is responsible for generating trace records containing the TA value if the trace of a particular UE has been started and the initial TA value has changed. The regular trace management framework is used to report the TA value to NetAct or a 3rd party tool where the value can be correlated with: • •

the traced UE (UE correlation) - using the Trace Reference and the Trace Recording Session Reference included in the trace report with other traced messages (time correlation) - using the time stamp information.

The trace data provider generates a trace record with the TA value for the traced UE each time this value is changed. The collection mechanism works as follows: •

•

•

•

Collection start The initial TA value (calculated in the eNB) is sent to the dedicated UE with the Random Access Response (RAR) message. MAC stores this value in the buffer. Calculation Each time the TA command is sent to the dedicated UE, MAC calculates the instantaneous TA value and stores it in the buffer. Collection re-initialization In case of a UE handover, RRC connection re-establishment, or loss of UE synchronization, the initial TA value is sent to the UE again. MAC updates this value in the buffer. Collection stop If the RRC connection is released, the eNB stops the TA value collection and removes the value related to this UE from the buffer.

The whole message flow is shown in Figure 33: Timing advance value collection signaling flow.

186

© 2016 Nokia




Figure 33

Timing advance value collection signaling flow

NE CM

TraceController

MAC/TraceDataProvider PRACH

MAC BufferforallUEs

Initial TA valuecalculation

RAR(initialTAvalue)

Deltaplan filedownload

StoretheinitialTA valueinbuffer

Tracestart (instantaneous TAtraceactive)

CalculateinstantaneousTA value,overwriteoldvalue CalculateinstantaneousTA value,overwriteoldvalue

...(TA command)

...(TAcommand) . . .

Tracestart(TAtraceactive) ...(TAcommand) CalculateinstantaneousTA value,overwriteoldvalue

Tracerecord(TAvalue)

TCPstream (tracereport) . . .

...(TAcommand)

CalculateinstantaneousTA value,overwriteoldvalue

Tracerecord(TAvalue) . . .

. . .

The operator can enable the TA value collection in the eNB for the subscriber trace and on a cell level for the cell trace. There are two vendor specific trace parameters to control that: • •

g

If the taTracing parameter is set to true, the TA values are added to vendor specific extension tracing of the subscriber trace (LTE163). If the cellTaTracing parameter is set to true, the TA values are added to vendor specific extension tracing of the cell trace (LTE433). Note: If trace depth MaximumWithoutVendorSpecificExtension is selected, the vendorspecific extensions are not traced (regardless of the taTracing or cellTaTracing parameter value).

6.2.4 System impact Interdependencies between features The TA records are added to the trace contents if features LTE163: Subscriber and Equipment Trace or LTE433: Cell Trace are active. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools The TA values are collected and reported to the NetAct TraceViewer application or a 3rd party analyzer tool. Impact on system performance and capacity


© 2016 Nokia

187



This feature has no impact on system performance or capacity.

6.2.5 LTE459: LTE Timing Advance Evaluation management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 117: New parameters lists parameters introduced with this feature. Table 117

New parameters

Full name

Abbreviated name

Managed object

Structure

TA Tracing

taTracing

CTRLTS

Vendor Specific Extension Tracing

Cell TA Tracing

cellTaTracing

MTRACE

Cell Vendor Specific Tracing


Sales information

BSW/ASW



BSW

-

-

6.3 LTE482: DNS Support for Certificate Examination Introduction to the feature During the X.509 certificate examination procedure, the certificate is validated against the Certificate Revocation List (CRL) whether it has been revoked. The CRL is stored in the revocation repository server.

188

© 2016 Nokia




This feature provides the IP address of the revocation repository server to all network elements. This is done by including the fully qualified domain name (FQDN) of the revocation repository server inside the operator certificate or operator CA certificate, and using Domain Name Service (DNS) to obtain the IP address of the revocation repository server.

6.3.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature enables using a fully qualified domain name (FQDN) of the revocation repository server in the operator certificates instead of its IP address. This offers operating expenditure (OPEX) savings when the IP address of the revocation repository server needs to be changed. In that case, only the DNS needs to be updated with the new IP address instead of all operator certificates in all network elements.



Network element

System release

eNodeB

MME

SAE GW

UE

NetAct

Required software release

RL30

LBTS3.0

-

-

-

-

Hardware requirements A standalone third party DNS server is needed in the customer network. NetAct or iOMS do not provide DNS services for eNB.

6.3.3 Functional description Functional overview All certificates of the remote peers, received as a part of the IPSec or TLS secure connection establishment, need to be validated and checked if they have not been revoked. To allow this examination, each operator certificate and/or operator CA certificate contains a reference to the revocation repository server, which stores a Certificate Revocation List (CRL). This reference, known also as reference to CRL distribution point, can be either an IP address, or a fully qualified domain name (FQDN) of the server. The IP address of the certificate revocation server is used for all network elements, that do not support LTE482: DNS Support for Certificate Examination feature. Employing FQDN names in certificates enables the use of DNS services, and minimizes the management effort if the IP address of the revocation repository server must be changed.


© 2016 Nokia

189



When a certain certificate needs to be revoked, the operator Certification Authority issues a new version of the Certificate Revocation List containing all revoked certificates. Network elements retrieve the FQDN name of the revocation repository server from the operator certificate or from operator CA certificate if the operator certificate does not contain any CRL distribution point. Using the built-in DNS client, network elements send query to the DNS server with the FQDN. The DNS server sends a reply message to network elements with the corresponding IP address assigned to the repository server. The network elements continue with the normal CRL download and certificate validation procedures. For more information on the Certificate Revocation List download procedure, see Certificate revocation and download of CRL, in Operating tasks related to LTE RAN O&M security, LTE RAN O&M Security. The DNS server in the Nokia solution is a standalone third party entity. It can be located in any place in the customer network, however, it is recommended to place it in the demilitarized zone (DMZ). The IP address of the DNS server is configured in all network elements with normal configuration procedures using configuration plan, and Netact or BTS Site Manager. It is possible to configure two IP addresses of the DNS, although the secondary IP address is not required. The secondary IP address is used when a query to the primary DNS fails. If the query to the secondary DNS also fails or the IP address of the secondary DNS is not configured in the network element, the DNS client does not initiate any retrials. It depends on the application requiring DNS service whether to retry the DNS query. When resolving the IP address of the revocation repository server fails, an alarm is raised and the DNS query is repeated until the IP address is resolved. The alarm is cleared if the CRL is successfully downloaded to the network element. DNS hardening The following requirements are not closely related to the LTE482: DNS Support for Certificate Examination feature, but should be taken into account when selecting a DNS server for the network: • • •

•

• •

g

Place DNS server on the demilitarized zone. The DMZ should be located between the network elements and the NetAct. Use authentication ticketing for DNS services. Restrict zone transfers to minimize the amount of information on the network available to attackers. Consider the authenticated zone transfers if zone transfers are required. Use two servers, or the views feature, if internal and external clients require different information (so-called split-horizon or split-brain technique). For additional security, consider using DNS proxying for the external DNS server. Internal DNS servers should be recursive, and external DNS servers must be nonrecursive. Do not allow dynamic updates. If dynamic updates are required, use transaction signatures to authenticate requests. Note: This results in Dynamic Host Configuration Protocol (DCHP) service not being available. Note also that accurate time synchronization is required for transaction signatures.

•

190

If the system does not serve as a DNS server, ensure that no DNS service is running.

© 2016 Nokia



• •


Run DNS server in a chroot (change root) environment, and run it without super-user privileges. Run DNS on a dedicated server.

6.3.4 System impact Interdependencies between features This feature has no interdependencies between features. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools This feature affects network management and network element management tools as follows: • •

introduces DNS services into certificate management centralizes the management of the certificate revocation repository server, and simplifies the changes, if needed

Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.3.5 LTE482: DNS Support for Certificate Examination management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms lists alarms modified by this feature. Table 120

Modified alarms

Alarm ID 7665

Alarm name BASE STATION TRANSMISSION ALARM

Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters lists parameters introduced with this feature.


© 2016 Nokia

191


Table 121


New parameters

Full name

Abbreviated name

Managed object

DNS servers access configuration identifier

dnsAccessId

IDNS

IP address of the primary DNS server

serverIpAddress

IDNS

IP address of the secondary DNS server serverIpAddress2

IDNS


Sales information

BSW/ASW



BSW

-

-

6.4 LTE510: Synchronization of InterRAT Neighbors Introduction to the feature The LTE510: Synchronization of InterRAT Neighbors feature is a centralized SON process for automatic inter-RAT neighbor relation (IRAT-ANR) preparation. During normal operation by a scheduled (or manually triggered) process by the operator at the NetAct, the NetAct/cSON checks for new inter-RAT cells and if found, adds these cells as inter-RAT neighbors to the most suitable LTE eNBs, based upon geo-locations. Updates based on geo-locations are done by the Optimizer/cSON. The NetAct/cSON considers all inter-RAT (GERAN or UTRAN) cells for all LTE cells. In addition, the operator can add external inter-RAT cells in border situations. The NetAct/cSON activates for selected eNBs either the LTE783: ANR InterRAT UTRAN feature or the LTE784: ANR InterRAT GERAN feature to set-up the wanted inter-RAT neighbor configuration.

6.4.1 Benefits The LTE510: Synchronization of InterRAT Neighbors feature updates the NRs from LTE to UTRAN. New deployed GERAN or UTRAN neighbor cells are informed towards the UEs. This helps to keep connection towards the network. Operator benefits The LTE510: Synchronization of InterRAT Neighbors feature ensures up-to-date interRAT neighbor relationships, also in case UTRAN/GERAN cells are added to the network.

192

© 2016 Nokia




The LTE510: Synchronization of InterRAT Neighbors feature eases the process to be done by the operator when executing the LTE783: ANR InterRAT UTRAN and the LTE784: ANR InterRAT GERAN features for considering the impact of new inter-RAT cells. The LTE510: Synchronization of InterRAT Neighbors feature identifies the LTE cells, that are potentially impacted by the neighborship relations to the new inter-RAT cell, to be updated with an optimized delta plan.

6.4.2 Requirements Software requirements Table 123: Software requirements for RL40 lists the software required for the LTE510: Synchronization of InterRAT Neighbors feature. Table 123

Release

Software requirements for RL40

System release

eNode B

MME

SAE GW

UE

NetAct

RL40

-

-

-

-

OSS5.3 CD3

Hardware requirements This feature requires no special hardware.


Functional overview The LTE510: Synchronization of InterRAT Neighbors feature adds a mechanism to establish new inter-RAT neighbor relations (NRs) in case new UTRAN/GERAN cells are created. All relevant parameters for inter-RAT NR establishment are provided by Nokia management system (NetAct) in case of a co-existing Nokia 2G/3G network or by Nokia management via northbound interface (Itf-N), in case of another Nokia NetAct regional cluster or other vendor's co-existing 2G/3G network. The creation of inter-RAT NRs is evaluated basing on: • • •

the location (co-location) of the BTS the distance between the cell being configured and potential target cells the radio antenna main lobe direction

The LTE510: Synchronization of InterRAT Neighbors feature identifies the impacted LTE cells/eNBs, and runs for those, the LTE783: ANR InterRAT UTRAN / LTE784: ANR InterRAT GERAN feature because of new inter-RAT cells. Figure 34: LTE510 Synchronization of InterRAT Neighbors gives an overview about the feature.


© 2016 Nokia

193


Figure 34


LTE510 Synchronization of InterRAT Neighbors

Changesat the2G/3Gside NetAct

LTEBTS

2G/3GBTS

Scheduledefinedbytheuser 2G/3G

CM SON

LTE

CM Configurationfiledownloaded

Update UpdateInter-RAT neighborrelations, ifnecessary, dependingon -location(co-location) -distancebetweenBTS -antennaradiolobe

Update Configurationfiledownloaded CM

Update

CM

6.4.3.2

Interactive management of eNBs This procedure describes the management of NRs for inter-RAT UTRAN and/or GERAN. The LTE510: Synchronization of InterRAT Neighbors feature considers all eNBs or LTE cells with respect to their inter-RAT neighborship. The operator triggers the start of the work-flow manually. Preconditions • • • •

UTRAN and/or GERAN cell information is available. LTE cells and eNBs exist and are under management of NetAct. The operator has set the wanted NetAct profile values for inter-RAT UTRAN and/or GERAN cell selection. NetAct Configurator keeps all eNBs or LTE cells up-to-date.

Description The following steps are supported by NetAct: 1. Optional NetAct Optimizer generates a list of all LTE eNBs and removes those eNBs from the list, if those are out-of-range of the lately added UTRAN or GERAN cells. Optional NetAct Optimizer generates for each RAT a list of remaining LTE cells that need update. This helps to reduce the execution time of the neighbor table recalculation. 2. The scheduled process starts the ANR for InterRAT UTRAN algorithm for the list of eNB or LTE cells that need an UTRAN NR update. NetAct Optimizer identifies for each LTE cell the most suitable neighbor UTRAN cells under consideration of the operator policy, that is the policy for the LTE783: ANR InterRAT UTRAN feature.

194

© 2016 Nokia




Based on user preferences, Optimizer might find also NRs that need to be deleted/replaced by the new found ones. NetAct Optimizer reports all found UTRAN NR to NetAct Configurator. 3. The scheduled process starts the ANR for InterRAT GERAN algorithm for the list of eNB or LTE cells that need a GERAN NR update. NetAct Optimizer identifies for each LTE cell the most suitable neighbor UTRAN cells under consideration of the operator policy, that is the policy for the LTE784: ANR InterRAT GERAN feature. Based on user preferences, Optimizer might find also NRs that need to be deleted/replaced by the new found ones. NetAct Optimizer reports all found GERAN NR to NetAct Configurator. 4. Based on the information generated by NetAct Optimizer, NetAct updates the existing eNB plan file. NetAct Configurator generates the plan files for those eNBs that need addition or deletion of the NRs. 5. NetAct Configurator completes the configuration plan file for the impacted eNBs and downloads and activates the delta plan files. Postcondition The LTE cells are configured with an updated set of UTRAN and/or GERAN neighbor cells for support of HO and other mobility procedures from LTE to UTRAN and/or GERAN via S1 interface, and provides broadcast information for UE idle mode mobility.

6.4.3.3

Scheduled neighborship reconfiguration The LTE510: Synchronization of InterRAT Neighbors feature does automatically keep inter-RAT NRs up-to-date in case of inter-RAT cell additions. The intrinsic algorithm to identify neighbors is based on the LTE783: ANR InterRAT UTRAN and the LTE784: ANR InterRAT GERAN functionality. Similar as an operator defines manually the scope of eNBs or LTE cells, the LTE510: Synchronization of InterRAT Neighbors feature identifies automatically those eNB and LTE cells that need update of their neighborship relation. There are two additional use cases to be considered by the LTE510: Synchronization of InterRAT Neighbors: • •

scheduled workflow execution by workflow engine for neighborship reconfiguration from LTE view point manually triggered workflow execution by workflow engine for neighborship reconfiguration from LTE view point.

To avoid ping-pong effects between the LTE510: Synchronization of InterRAT Neighbors on the one hand and execution of the LTE783: ANR InterRAT UTRAN and the LTE784: ANR InterRAT GERAN feature, the same LTE783: ANR InterRAT UTRAN and LTE784: ANR InterRAT GERAN policy values for the selection of inter-RAT neighborship relation are applied. In addition the same black- and white-listings are used. Therefore, the design of the LTE510: Synchronization of InterRAT Neighbors feature aims at re-using the existing LTE783: ANR InterRAT UTRAN and LTE784: ANR InterRAT GERAN feature functionality and policy setting. The LTE510: Synchronization of InterRAT Neighbors feature is designed to be responsible to identify those eNB and LTE cells that need to update their inter-RAT NR. This approach defines a clear scope of the feature activation for each of the individual features: the LTE510: Synchronization of InterRAT Neighbors, the LTE783: ANR InterRAT UTRAN and the LTE784: ANR InterRAT GERAN. Scheduled neighborship reconfiguration Periodically or manually triggered, Optimizer


© 2016 Nokia

195


• • • • • •


finds new inter-RAT cells. finds affected LTE cells. starts LTE783: ANR InterRAT UTRAN and/or LTE784: ANR InterRAT GERAN for those LTE cells. NetAct Optimizer stores the newly identified inter-RAT NR and exchanges the plan to Configurator. If no stop-point is set NetAct Configurator proceeds with the provisioning. If a stop-point is set, the work-flow exits and the user can verify the results and proceed with the provisioning manually.

The NetAct keeps the operator informed about the progress and outcome of the scheduled job. Support at NetAct Optimizer NetAct Optimizer supports the identification of the LTE cells that are impacted by cell additions in the inter-RAT networks, based on their geo-locations and the direction of the antenna main lobe. The identification of impacted LTE cells considers the same LTE783: ANR InterRAT UTRAN and LTE784: ANR InterRAT GERAN geo-location criteria. NetAct Optimizer runs the features LTE783: ANR InterRAT UTRAN and LTE784: ANR InterRAT GERAN for update of the LTE network for those eNB or LTE cells. The following policy is supported: Scheduler execution control for the start of the LTE510: Synchronization of InterRAT Neighbors feature • •

disabled (the LTE510: Synchronization of InterRAT Neighbors feature is disabled) enabled (manual trigger)

Options for scheduler periodicity: • • • •

daily at certain time weekly at certain day/time bi-weekly at certain day/time monthly at certain day/time

The configuration plan containing the new inter-RAT NR is forwarded to NetAct Configurator. NetAct Optimizer generates one configuration plan for all activated RATs. Use case: Scheduled neighborship reconfiguration This procedure describes the management of NRs for inter-RAT UTRAN and/or GERAN. The operator does optionally configure a scheduled job at NetAct that does update the configuration of the impacted eNBs or LTE cells with respect to inter-RAT cell additions. The operator can schedule “to run the process autonomously” with or without a stoppoint for verifications. The operator can trigger execution of this procedure manually. Preconditions Inter-RAT cell geo-location information is available. The operator has set the wanted operator policy values for inter-RAT cell selection. All features are activated. NetAct Configurator keeps all eNB or LTE cells up-to-date. The operator has enabled the scheduled job at NetAct.

196

© 2016 Nokia




Description The following steps are supported by NetAct: 1. Optimizer identifies all new inserted inter-RAT cells (inter-RAT cells that do not have yet incoming LTE NRs). 2. The scheduled process starts the ANR for Inter-RAT UTRAN algorithm for the list of eNB or LTE cells that need UTRAN NR update. The scheduled process starts the ANR for Inter-RAT GERAN algorithm for the list of eNB or LTE cells that need GERAN NR update. The order of the RATs is arbitrary. 3. Based on the information generated by NetAct Optimizer, NetAct Optimizer has to update the existing eNB plan file. At the LTE510: Synchronization of InterRAT Neighbors stop-point the operator can still modify the found NR. 4. The NetAct Configurator has to complete the configuration plan file for the impacted eNBs and downloads and activates the delta plan files. Post conditions The LTE cells are configured with NR to newly added neighbor UTRAN and/or GERAN cells for support of HO and other mobility procedures from LTE to UTRAN/GERAN via S1 interface and to broadcast to the UE for idle mode mobility.

6.4.4 System impact Interdependencies between features Features • •

LTE783: ANR InterRAT UTRAN LTE784: ANR InterRAT GERAN

are pre-requisite for operating the LTE510: Synchronization of InterRAT Neighbors feature. •

•

•

The LTE783: ANR InterRAT UTRAN and the LTE784: ANR InterRAT GERAN features enable the operator to configure inter-RAT neighbor relations (NRs) when new LTE eNBs are created/exist using pre-planned data (network planning and configuration file download onto Flexi Multiradio BTS). LTE1019: SON Reports This feature defines SON feature labels, that are automatically added as context information for each change done by a SON function in the network configuration. In the CM History tool it is possible to generate SON Reports showing the changes done by the LTE510: Synchronization of InterRAT Neighbors feature. LTE1045: Full SON Support for Distributed Sites This feature allows to provide antenna geo-location data for antenna/cell equipment. In case of the LTE614: Distributed Sites, the antenna/cell geo-location data are mandatory for the execution of the LTE510: Synchronization of InterRAT Neighbors feature. If data are missing in the scope of cells or potential neighbor cells, then the execution of the LTE510: Synchronization of InterRAT Neighbors feature is aborted and the operator is informed to correct the geo-location data settings.

Impact on interfaces This feature has no impact on interfaces. Impact on MML commands


© 2016 Nokia

197



This feature has no impact on MML commands. Impact on network and network element management tools This feature has no impact on network management or network element management tools.

6.4.5 Management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


Sales information

BSW/ASW

SW component



ASW NetAct

-

NetAct

-

6.4.7 Abbreviations Table 125

Abbreviations

Abbreviations

Description

NR

Neighbor Relation

RAT

Radio Access Technology

HO

Hand Over

6.5 LTE533: Mobility Robustness Introduction to the feature

198

© 2016 Nokia




This feature improves the system performance by optimizing the Intra-LTE radio network HO-configuration in order to reduce as much as possible the following events: • •

too early HOs too late HOs

Number of call drops and radio link failures, as well as exchanged signaling will be also reduced as much as possible. This feature has to be considered as a first step of MROimplementation, covering not all 3GPP-defined use cases for MRO, for example HO to the wrong cell. To reduce radio link failures due to mobility problems, HOs to the wrong cell can be counted either as too early or too late HO events, whichever is more suitable.

6.5.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The aim of this feature is to increase the radio network performance by increasing the robustness of mobility procedures, fewer call drops/radio link failures, resulting in increasing end user quality perception.

6.5.2 Requirements Hardware requirements This feature requires the following hardware:

6.5.3 Functional description Functional overview The feature LTE533: Mobility Robustness (MRO) belongs to the set of SON-features and enables adjustment of Handover-related thresholds like • •

HO offsets (Cell Individual Offset, CIO) TimeToTrigger (TTT)

from long-term evaluation of Performance Measurements reported by Flexi Multiradio BTS and correlation of such PM with the relevant configuration parameters. The feature aims to reduce as much as possible the probability of radio link failures and HO failures due to sub-optimal configuration of mobility related parameters. In the initial network planning the configuration of mobility-related parameters depends on the type of Flexi Multiradio BTS-deployment. There may be different sets of mobility parameters for different deployment categories like urban/dense or urban/rural areas deployment and the used cell size/transmit power.


© 2016 Nokia

199



However, it is assumed that the initial configuration does not match best for all different Flexi Multiradio BTS-sites, so further fine tuning of these parameters is most often required after deployment of a Flexi Multiradio BTS, for example by performing drive tests and/or long-term evaluation of KPIs. MRO automates the work flow for fine tuning of these mobility related parameters, based on the long-term evaluation of corresponding KPIs. For this purpose, additional PM counters are implemented in Flexi Multiradio BTS to enable cause differentiation for detection of too early/too late HOs. The following new PM counters are introduced: • • •

Late HO counter - counts sequences of RLF in one cell followed by RRC connection re-establishment request in another cell. Type 1 early HO counter - an early HO type 1 is a sequence of a failed HO attempt followed by RRC connection re-establishment in the HO source cell. Type 2 early HO counter - counts sequences of successful connection establishment in HO target cell, followed by RLF in the target cell, followed by RRC connection reestablishment request in the HO source cell. Hereby, the re-establishment request is required to follow the connection establishment in HO target cell no later than some predefined time interval.

In NetAct SW, the LTE533 feature allows centralized reading and visualization of the above LTE533 counters for all neighbor relations on the LTE533 activation area. Based on comparison of LTE533 counters against thresholds, and an additional comparison of general PM counters against thresholds, neighbor relations with HO performance problems are identified by LTE533. Subsequently, an adjustment of neighbor relations parameters to improve HO performance can be performed. As output MRO may calculate updated values for: • •

cell-individual Offset (CIO) of the neighbor cell in the identified neighbor relation of the serving cell - in the LNREL object of the serving cell containing this NR TimeToTrigger (TTT) of all neighbor cells in the serving cell carrier frequency - in the LNCEL object of the serving cell

Existing and/or new PM counters (collected by the Flexi Multiradio BTS and reported to NetAct) constitute the base for evaluating suboptimal HO performance. NetAct visualizes the PM counters, indicates performance problems and optionally, proposes new settings for the above listed parameters at specific Flexi Multiradio BTS.

g

Note: Operator hint: If there is a problem with Network Element (NE) in NetAct and NE has to be deleteted in NetAct and integrated again, the PM data in Optimizer cannot be assigned to the NE because the NetAct internal ID changed during the re-integration. The feature is of semi-static nature: It works on the time scale of days-to-weeks. Consequently, it does not react on short-term to suddenly occurring HO problems. As a result of system level simulations and system analysis it turned out that it is essential to have a crucial amount of performance feedback (PM counters) from the network in order to trigger the right measures. Therefore, the MRO algorithm will not operate if there is not enough performance information available.

200

© 2016 Nokia




Biggest gains of MRO are expected in case of scenarios with specific local propagation effects, for example urban infrastructure deployments and specific arrangements of UE movements and cell coverage, like highway movement on cell edge, etc. The operator is able to specify policies (for example max or min parameter values; which cells should not be subject to MRO optimization) on how this feature should work. Figure 35: Mobility Robustness gives an overview of LTE533: Mobility Robustness. Figure 35

Mobility Robustness MRO-SF:ROSupportFunctionsin RRM/Telecom ->AdditionalPM-counterstobe implementedinBTSforsupportingMRO Operatorpolicies

PM-history

Optimizer/Configuration

MRO SF CM

PM

MRO SF CM

PM

NetAct

PerformanceMeasurements

The recalculated parameter values are proposed by MRO to the operator who can manually accept or reject their implementation.

6.5.3.1

LTE1222: Inter-Rat Auto Setup and Scheduled Optimization With the feature LTE1222: Inter-RAT Auto Setup and Scheduled Optimization the InterRAT neighbor-related features and optimization of Intra-LTE are executed in an automated manner. The feature LTE533: MRO is executable in a time scheduled manner. The scope of cells or eNBs is the whole network respectively the scope of NetAct. The operator defines the time schedules when the feature MRO has to be executed. Additionally the feature MRO can be started manually as before. NetAct supports preference settings to keep the network profile for the workflow-based execution of MRO: Preference settings: • • • •


Execution of the workflow (enabled, disabled) Scheduler configuration (day-of-week, time,...) stop point (none, active) MRO thresholds and weights

© 2016 Nokia

201


•


Network freeze mode (none, direct neighbors, all neighbors, ...)

The operator setting of the network profile data during the interactive activation of MRO does not change the preference setting for the automated execution of MRO. The operator can trigger the execution of the automated MRO workflow manually or abort the running workflow. The operator can activate a stop point. If this function is activated, then the automated MRO work-flow stops before the new plan file is downloaded and activated. The operator can control the further steps manually.

6.5.3.2

Use cases The LTE533 feature supports the following use cases at eNB, which lead to counter increments: 1. Late HO counting 2. Type 1 early HO counting 3. Type 2 early HO counting The LTE533 feature supports the following use cases at NetAct/cSON side: 1. LTE533 counters reading and visualization.

g

Note: This is supported in NetAct Optimizer, not supported in cSON. 2. HO problems detection based on LTE533 counters reading 3. HO problems handling via parameter adjustment

6.5.3.2.1

Late HO counting Late HO counting when no outgoing HO initiated Short Description A UE in connected mode in cell A obtaines an HO failure, while no HO is prepared for this UE, that is no other cell has a prepared UE context. Subsequently, the connection re-establishment request from the UE is received at (unprepared) cell B. The received re-establishment cause is set not equal to HO failure and not equal to ReconfigurationFailure. Cell B indicates this event to cell A by sending of X2 RLF INDICATION. After receiving the indication, Cell A finally increments the Late HO counter associated with CGI of cell B. Late HO counting when outgoing HO initiated and HO command not received Short Description A UE in connected mode in cell A obtaines an RLF (on UE side), while HO towards cell B had been already prepared for this UE, i.e. cell B has a prepared UE context. Subsequently, the connection re-establishment request from the UE is received either at prepared cell B or at unprepared 3rd cell C. The received re-establishment cause is set not equal to 'ReconfigurationFailure' and not equal to HO failure as UE has not received HO command. Cell B or C indicates this event to cell A via sending of X2 RLF INDICATION. After receiving the indication, Cell A finally increments the Late HO counter associated with CGI of cell B or C. Late HO counting when outgoing HO initiated and HO command received

202

© 2016 Nokia




Short Description A UE in connected mode in cell A obtaines an RLF (on UE side), while HO towards cell B had been already prepared for this UE, i.e. cell B has a prepared UE context, and UE has received already the HO command. The UE fails in random access to cell B during timer run, and subsequently the connection re-establishment request from the UE is received at unprepared 3rd cell C (re-establishment cause equal to 'HO failure'). Cell C indicates this event to cell A by sending of X2 RLF INDICATION. After receiving the indication, Cell A finally increments the Late HO counter associated with CGI of cell C.

6.5.3.2.2

Type 2 early HO counting Type 2 early HO counting when incoming HO initiated Short Description A HO of a UE from cell A towards cell B is initiated. The UE succeeds in random access to cell B, but perceives an RLF (on UE side) before Msg3 is received at cell B. Subsequently, the connection re-establishment request from the UE is received at an unprepared cell C. Cell C indicates this event to cell B via sending of X2 RLF INDICATION. After recognition that the indication occurs during incoming HO for this UE, cell B responds with X2 HANDOVER REPORT to cell A. Finally, cell A increments the Type 2 early HO counter associated with CGI of cell B, the target of initiated HO. Type 2 early HO counting when no outgoing/incoming HO initiated Short Description A HO of a UE from cell A towards cell B is successfully completed. Shortly after successful connection establishment in cell B, the UE perceives an RLF (on UE side) before a new HO is prepared for this UE. Subsequently, the connection re-establishment request from the UE is received at an unprepared cell C, in particular at cell C=A again. Cell C indicates this event to cell B via sending of X2 RLF INDICATION. After recognition that the indication follows shortly a completed HO of the UE context from cell A, cell B responds with X2 HANDOVER REPORT to cell A. Finally, cell A increments the Type 2 early HO counter associated with CGI of cell B, the target of completed HO. Type 2 early HO counting when outgoing HO initiated and HO command not received Short Description A HO of a UE from cell A towards cell B is successfully completed. Shortly after successful connection establishment in cell B, a new HO to some cell D is initiated at cell B. Subsequently, the UE perceives an RLF (on UE side) before the related HO command is received. The following connection re-establishment request from the UE is received at prepared HO target cell D, or at any unprepared cell C, which can be in particular equal to A. The received re-establishment cause is set not equal to ReconfigurationFailure and not equal to HO failure as UE has not received HO command. Cell C or D indicates this event to cell B via sending of X2 RLF INDICATION. After recognition that the indication follows soon after a completed HO of the UE context from cell A, cell B responds with X2 HANDOVER REPORT to cell A. Finally, cell A increments the Type 2 early HO counter associated with CGI of cell B, the target of completed HO. Type 2 early HO counting when outgoing HO initiated and HO command received Short Description


© 2016 Nokia

203



A HO of a UE from cell A towards cell B is successfully completed. Shortly after successful connection establishment in cell B, a new HO to some cell D is initiated at cell B. The UE receives the related HO command but fails in random access to cell D. The following connection re-establishment request from the UE is received at an unprepared 3rd cell C, which can be equal to cell A again (the re-establishment cause is set equal to HO failure as UE has received HO command). Cell C indicates this event to cell B via sending of X2 RLF INDICATION. After recognition that the indication follows shortly a completed HO of the UE context from cell A, cell B responds with X2 HANDOVER REPORT to cell A. Finally, cell A increments the Type 2 early HO counter associated with CGI of cell B, the target of completed HO.

6.5.3.2.3

LTE533 counters reading and visualization Short description The readings of the LTE533 counters are provided to the NetAct LTE533 logic for each execution of the algorithm as available.

6.5.3.2.4

HO problems detection based on LTE533 counters reading Short description The (normalized) values of the readings of the LTE533 counters are compared against critical thresholds on NR basis for the entire LTE533 activation area. In case of an exceeded threshold, a problem indication is released for each corresponding NR.

6.5.3.2.5

HO problems handling via parameter adjustment Short description Based on the counter readings visualization by NetAct LTE533 logic, the user is enabled to apply manually suitable parameter adjustments to achieve HO performance improvement (general option, not specific for LTE533). Optionally, LTE533 NetAct logic applies an automatic adjustment of CIO and TTT for NRs for which problem indication had been released.

6.5.3.3

Use case: LTE533 MRO LTE1768 MRO Ping Pong Example The operator uses LTE533/LTE1768 MRO algorithm at cSON in order to optimize cell individual offset (CIO) and time to trigger (TTT) related parameters. Actors The operator at cSON, NetAct Configurator, eNB Precondition • • • • •

204

The eNB is working properly and provides service. cSON and NetAct Configurator are up and running. The license for using LTE533/LTE1768 is installed. The operator activated related PM measurements. The eNB provides relevant PM counters to NetAct/cSON to use as input to the MRO algorithm, for example PM counters are available for the cSON to be considered.

© 2016 Nokia



• • • • •


cSON has a snapshot of the corresponding parameter settings from NetAct Configurator. The operator has selected a scope (for example a set of eNBs) for which the algorithm shall be run. The operator has configured the algorithm specific parameters. The operator starts the algorithm for MRO either interactively or scheduled by cSON. The connection between eNB and the management system is established and working.

Description 1. cSON runs the algorithm of LTE533/LTE1768 on the eNBs of the selected scope. The algorithm considers the eNB-provided PM counters and determines whether the related CIO and/or TTT parameters have to be adjusted. Thereby, cSON determines the optimized values for the CIO and TTT parameters. 2. If the criteria for adjusting the CIO and TTT parameters are fulfilled, cSON propose snew parameter values. 3. For the proposed parameter changes cSON adds the context information for SON reports to indicate the origin of the change. 4. cSON fills the result into a configuration plan of NetAct Configurator. 5. After the successful plan file validation, NetAct Configurator downloads and activates the plan to the corresponding eNB. 6. The eNB sends a Configuration Change Notification(s) to NetAct and BTSSM. Post-condition • •

6.5.3.4

The CIO and TTT parameters are operating in the eNB with the updated settings. The PM counters are collected so that the algorithm in cSON can, based on its configuration, consider the changed settings in the next adjustment phase if necessary.

Licensing The LTE533 feature is of ASW type and does not need license activation parameter on eNB. The feature is licensed by NetAct-internal license in NetAct Optimizer, respectively by the cSON tool related license mechanism.


•


LTE971: Intra-LTEmobility offsets is prerequisite for LTE533.LTE971 feature introduces CIO parameters and frequency offset parameters of LTE cells and frequencies. Dependency on LTE971 is caused by enabled arbitrary manual adjustment of parameters, in particular CIOs, based on counters visualization result by LTE533 NetAct logic. An analogous dependence is due to optionally enabled automatic adjustment of neighbor CIOs, subsequently to HO problems detection by LTE533 NetAct logic. LTE735: RRC Connection Re-establishmentLTE735 feature introduces the reestablishment timer for connection re-establishment purposes. Dependency on LTE735 is due to re-use of re-establishment timer by LTE533: The LTE533 counting procedures of Late HO and Type 2 early HO make implicit use of UE context availability on serving cell during run time of associated re-establishment timer.

© 2016 Nokia

205


•

Similarly, the LTE533 counting procedures rely on non-availability of UE context on serving cell after expiration of associated re-establishment timer. The differentiation between a prepared UE context and consolidated (matched with C-RNTI) UE context is used within LTE533 requirements similarly to LTE735 requirements. LTE782: UE-based ANRThe LTE533 feature requires created neighbor relations. Neighbor relations can be created manually, but the dependences on LTE782 need to be mentioned for the following two reasons: –

–

•


Intended benefit from LTE533 is the activation possibility without any preplanning needed. This pre-planning is omitted by activation of LTE782 in advance to the activation of LTE533. LTE533 relies then on created neighbor relations as a result of LTE782. In this sense, LTE782 and LTE533 represent a joint functionality of pre-planning-free creation of neighbor relations and their monitoring and control with respect to LTE533 counters. The monitoring and control with respect to LTE533 counters, enabled by LTE533, should be applied to online adapted/updated neighbor relation situation during network operation. In particular, newly created neighbor relations need to be automatically subject to LTE533 actions. The LTE782 feature is responsible for such permanent online updating of neighbor relations in the activation area of LTE533.

LTE771: Optimization of Intra-LTE Neighbor RelationsThe LTE771 feature is affected by LTE533 because they co-act on same NRs. As a result, the decisions of neighbor relations blacklisting controled by LTE771 depend on the effects of LTE533 activation. The LTE533 effects which impact LTE771 result from: – –

manual arbitrary parameter adjustment by the user on selected cells/NRs, based on LTE533 counters visualization result provided by NetAct LTE533 logic, optional single-step automatic adjustment of CIOs and/to TTT by NetAct LTE533 logic on selected cells of NRs.

The principle of affecting LTE771 via LTE533 is the following: LTE533 NetAct logic enables HO performance optimization on NRs via parameter adjustment. LTE771 concurrently aims at blacklisting of NRs based, in particular, on their HO performance. Thus, by adjusting the HO parameters, LTE533 affects (most often reducing) the set of candidate NRs for blacklisting by LTE771. Impact on interfaces This feature affects interfaces as follows: •

Impact on interface to O&M/NetAct: –

–

plan-based parameter support for LTE533 parameters, including upload, download, activation, change notifications, feature configuration (expiration value of TStoreUECntxt) support of new counters reading/provision from eNBs towards NetAct

Impact on MML commands There are no MML commands related to this feature. Impact on network and network element management tools This feature has no impact on network management or network element management tools. Impact on system performance and capacity

206

© 2016 Nokia




This feature has no impact on system performance or capacity.

6.5.5 LTE533: Mobility Robustness management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 126: New counters lists counters introduced with this feature. Table 126

New counters

Counter name

Measurement

Late HO counter

Counts sequences of missed HO attempt (instead of HO: RLF on UE side and optionally recoverable RLF on eNB side) in one cell followed by RRC connection re-establishment request in another cell.

Type 1 early HO counter

Counts sequences of attempted failed HO followed by RRC connection reestablishment request in the HO source cell.

Type 2 early HO counter

Counts two types of event sequences; •

•


© 2016 Nokia

successfull connection establishment in HO target cell (attempted HO completed) followed by RRC connection reestablishment request in another cell a 'short time' after HO completion, RRC Connection Reestablishment Request can follow an RLF or a HO failure on UE side. successfull random access to HO target cell followed by failed Msg3 reception (attempted HO uncompleted) followed by re-establishment request in another cell.

207


Table 126



Counter name

Measurement 'Short time' is defined as time period no longer than expiration value of Tstore_UE_cntxt timer up from HO completion.

Table 127: Related existing counters lists existing counters related to this feature. Table 127

Related existing counters

Counter name

Measurement

HARQ_RETRANS_ON_DL_SCH

Counts the number of retransmissions on DL-SCH

CORR_UL_SCH_TB_RE_RECEPT

Counts the number of correct UL-SCH TB with re-reception.

RLC_PDU_RE_TRANS

Counts the number of RLC data PDUs retransmitted on RLC level.

UL_RLC_PDU_RETR_REQ

Counts the number of UL RLC PDU retransmissions requested on RLC level.

ENB_INIT_TO_IDLE_RNL

Counts the number UE context releases towards MME.

INTER_HO_SUCC_NB

Counts the number of successfully completed intereNB intra-LTE HOs

INTRA_HO_SUCC_NB

Counts the number of successfully completed intraeNB intra-LTE HOs

There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

208

© 2016 Nokia





Sales information

BSW/ASW

SW component

ASW



NetAct


Abbreviations

Abbreviations

Description

HO

Handover

MRO

Mobility Robustness

CIO

Cell-Individual Offset

TTT

Time To Trigger

RRC

Radio Resource Control

RLF

Radio Link Failure

Table 130

Terms

Terms Neighbor Relation

Description A neighbor relation (NR) is an unilateral relation between a source cell and a target cell. For every cell served by an eNB (say, cell A), there is a neighbor relation to another cell (say, cell B) if following conditions are satisfied: •

Cell B is a configured neighbor cell of cell A as a consequence of either of the following two events: –

–

•


LTE782 use case: A UE served by cell A had detected cell B within configured measurements and reported it to cell A in measurement report message LTE724, LTE492 and manual use case: Cell A had been configured as a neighbor manually or via O&M NetAct functionalities, with no use of measurement reporting.

The configuration information of cell B is known to eNB of cell A (TAC, PLMN identity, CGI, TNL address).

© 2016 Nokia

209


Table 130


Terms (Cont.)

Terms Radio Link Failure

Description Within eNB requirements, two types of Radio Link Failures (RLFs) are distinguished; recoverable RLF and unrecoverable RLF. When no explicit remark is provided, an RLF in this document is understood as recoverable RLF. •

•

Recoverable RLF is detected at L3 of eNB upon radio link problem indication to L3 from either L1 or L2 or RRM (see UE state handling). Upon recoverable RLF, either timer T_RLF or T_RLC is started at eNB, depending on the problem indication type. Unrecoverable RLF is detected at L3 of eNB until either –

expiry of timer T_RLF, or

–

expiry of timer T_RLC when T_RLF is not running.

g

Cell-Individual Offset

Note: RLF on UE side is in general a different event from RLF types on eNB side. From UE-to-eNB process one can however recognize that RLF on UE side will usually be, up to some accuracy, concurrent in time with radio link problem indication by L1 or L2 at eNB side.

Cell-Individual Offset (CIO) is a parameter introduced within LTE971 feature. For a particular cell, the LTE971 feature distinguishes between •

serving cell CIO, located in LNCEL object, and

•

neighbor cell CIOs associated with target cells of particular NRs and located in corresponding LNREL objects.

Thus, a CIO of a neighbor cell means in this document a parameter in LNREL at the serving cell of an NR and related to target cell of this NR. Completed HO

A HO is referred to as completed if either connection reconfiguration complete message or connection re-establishment request is received at prepared HO target of the UE. Otherwise HO is regarded as uncompleted.

6.6 Description of LTE581: PRACH management Introduction to the feature With the feature LTE581: PRACH management an automatic assignment of PRACH (packet random access channel) settings during the initial auto configuration process supported by NetAct Configurator and Optimizer/cSON is provided.

6.6.1 Benefits End-user benefits This feature does not affect the end-user experience.

210

© 2016 Nokia




Operator benefits Less effort in O&M parameter setting and optimization.

6.6.2 Requirements Software requirements The following table lists the software required for this feature.

System release

Flexi Multiradio BTS

RL30

LBTS3.0

Table 131

Flexi Multiradio 10 BTS

OMS


UE

NetAct

MME

SAE GW

-

OSS5.3 CD3

-

-

Hardware requirements This feature requires the following hardware: •

LTE System Info

6.6.3 Functional description Functional overview This feature is an addition to the existing auto configuration process. The rules given below are applicable to eNB's using the same LTE UL-centre frequency.

g

Note: This includes also different centre frequencies, however, with overlapping ULtransmission bandwidth. For networks operation in an other LTE band, a separate PRACH planning has to be performed. An automatic assignment of the following PRACH parameters is supported by NetAct Optimizer/cSON: • • • •

PRACH cyclic shift PRACH configuration index PRACH frequency offset PRACH Root sequence

The algorithm uses the following information as input: • • •


type of System FDD/TDD geolocation and/or already available neighbor relation information own cell database parameters like UL center frequency, bandwidth etc.

© 2016 Nokia

211


• • • •


expected cell range increased pathless characteristic or high interference environment of the cell expected UE speed within the cell expected RACH load / RACH collision probability

The auto configuration process is started by the NetAct Optimizer/cSON with selecting the cells to be updated and providing the required input data. NetAct Optimizer/cSON derives out of these input parameters the abovementioned output parameters. This process is embedded into the LTE720: auto configuration framework. This input information stored in MRBTS and/or LNBTS object (or subordinate objects) is assigned to the site object of NetAct. The assignment is done via the input file from the planning tool, and the result is stored in NetAct Configurator. Default input values defined by the process are used if dedicated input values are missing. In this case a default PRACH configuration is generated. An overview of the feature and its interdependencies among eNB, NetAct Configurator, NetAct Optimizer are depicted below. Figure 36

Overview of PRACH management AutoplanningPRACHparameters-additiontoeNBautoconfigurationprocess InitialeNB planning

eNB

Configurator

Optimizer

Preconditions:needed paramsmodeled(inPDDB)

Preconditiontohave:actual DBuptodate,eNBauto conflicenseactive

Preconditiontohave:freshactual NWconfigurationfromConfiguratoractual DBpreferencesset,PRACHlicenseactive

Planfileimport&site templateapply,eNBplan creation

eNBautoplanning

planfile

PRACHauto planning(+otherautoConfigure autoplanninge.g.PCI)

Fileprecondition:filemay (must?)containcertain paramvaluesforPRACH algorithm

Planvalidation

eNBautoconnectsand requeststostartautoconf

eNBconfplanpreparation(inadvance) eNBautoconfiguration eNBautoconftriggering eNBautoplanning (redotoupdatewithalllatest changesaround)

SWactivation&reset

Configuration activation&reset

SWactivation

eNBconfiguration planactivation

eNBisoperational withautoplannedPRACH

PRACHauto planning(+otherautoConfigure autoplanninge.g.PCI)

Triggeredat -!eNB!conf!plan!preparation!(either!manually!by!user or!perhaps!automatically!with “zero!touch” new!feature) -eNB!auto!configuration!(by!eNB) Visualisation -!feedback!info!from!Optimizer!covers!PRACH!auto!planning, visible!in!Configurator!operations!history!UI Controls -!Optimizer!preferences,!enable/disable,!license -some!new!eNB!parameters!(from!initial!eNB!planning)

Whatis/means SONcoordinator forLTE581?

6.6.3.1

RAN system level scope The PRACH management feature is based on pre-planning information available for the cell under configuration, the geo-location of the eNB the cell belongs and if available on surrounding eNB/cell configuration data. The selection of surrounding cells is done only

212

© 2016 Nokia




on basis of the geo-location of the surrounding eNBs. The configuration applies to eNB's and all their subordinate cells which are newly configured by the auto configuration process and added to the network. It applies only to cells using the same frequency and bandwidth.

6.6.3.2 6.6.3.2.1

User scenarios eNB configuration without any surrounding eNB within PRACH reuse distance As shown in Figure 37: eNB Configuration without any surrounding eNB within PRACH Reuse Distance there is no eNB within the PRACH reuse distance, and therefore no surrounding eNB/cell has to be considered for PRACH planning. The NetAct Configurator starts the auto configuration for a new eNB, including the PRACH configuration for all its subordinate cells. As no eNB is located within the PRACH reuse distance, no cell has to be considered as surrounding cell for PRACH planning. Therefore, the PRACH configuration process can be terminated as soon as a valid PRACH configuration is found. The PRACH configuration process tries to find the best PRACH configuration with respect to the given input data. However, in case this best configuration cannot be used (for whatever reason), the configuration which is next to the best solution will be selected. This ensures that at the end of the process at least one valid PRACH configuration is selected. In this case a message is generated that the best PRACH configuration could not be selected.


© 2016 Nokia

213


Figure 37


eNB Configuration without any surrounding eNB within PRACH Reuse Distance

Cellunder

use CH re

nce Dista

PRA

configuration

eNBwhichbelongstothecell underconfiguration eNBoutsidePRACHreuse distance

Post condition A PRACH configuration is available for all cells subordinate to the eNB under configuration. These PRACH configurations are stored as part of the eNB configuration plan file into the NetAct Configurator plan database, and are available for further eNB auto configuration as part of the same plan file. After eNB is auto-configured, the eNB's current actual configuration is available from Configurator current CM database.

6.6.3.2.2

eNB configuration with neighbor eNB within PRACH reuse distance As shown in Figure 38: eNB configuration with neighbor eNB within PRACH reuse distance there are several eNBs within the PRACH reuse distance, and therefore the cells subordinate to those eNBs are considered as surrounding cells for PRACH configuration.

214

© 2016 Nokia




The NetAct Configurator starts the auto configuration for a new eNB, including the PRACH configuration for all its subordinate cells. As a first step, a set of PRACH configurations based on own cell parameters are determined (PRACH config Set A). In the second step this set of configurations is aligned with the PRACH configurations of the relevant surrounding eNBs/cells. Relevant surrounding cells are the cells subordinate to eNBs within the PRACH reuse distance. At the end of step two, at least one PRACH configuration which is aligned with the PRACH configurations of the relevant surrounding cells, is available (PRACH config Set B). If PRACH config Set B contains more than one PRACH configuration, one will be selected based on the priority selection algorithm. The PRACH configuration process tries to find the best PRACH configuration with respect to the given input data and surrounding cell PRACH configuration. However, in case this best configuration cannot be used (for whatever reason) the configuration which is next to the best configuration will be selected. This ensures that at the end of the process at least one valid PRACH configuration is selected. In this case a message is generated that the best PRACH configuration could not be selected.


© 2016 Nokia

215


Figure 38


eNB configuration with neighbor eNB within PRACH reuse distance

Cellunder

ce

istan

use D

H re PRAC

configuration

eNBwhichbelongstothecell underconfiguration eNBoutsidePRACHreuse distance eNBwithinPRACHreuse distance

CellsconsideredasneighborcellsforPRACHplanning CellsnotconsideredasneighborcellsforPRACHplanning

Post condition A PRACH configuration is available for all cells subordinate to the eNB under configuration. These PRACH configurations are stored as part of the eNB configuration plan file into the NetAct configurator plan database, and are available for further eNB auto-configuration as part of the same plan file. After eNB is auto configured, the eNB's current configuration is available from Configurator's current CM database.

216

© 2016 Nokia



6.6.3.2.3


eNB configuration with/without surrounding eNB within PRACH reuse distance and with surrounding eNB's of another PLMN within PRACH reuse distance As shown in the Figure 39: eNB configuration with neighbor eNB within PRACH reuse distance, there are several eNBs within the PRACH reuse distance, belonging to the home PLMN and to a neighbor PLMN. Therefore, cells belonging to these eNBs either from the home PLMN or from the neighbor PLMN should be considered as surrounding cells for PRACH configuration. A neighbor PLMN is considered in this process as the neighbor PLMN if the spectrum used by both networks overlaps. The PRACH configurations (following parameters: prachConfIndex, prachFreqOff, rootSeqIndex, prachCs) of the cells of the neighbor PLMN which should be considered for PRACH configuration are marked as “not allowed” configuration before starting the automatic PRACH configuration process. For example home PLMN use root sequences from 0 to 418 while neighbor PLMN use root sequences from 419 to 837 in overlapping PLMN areas - for example at country borders.

g


Note: Femto cells Femto cells can be planned and considered similar by using reserved or not allowed areas for the parameter rootSeqIndex. For example reserve the rootseqIndexfrom 0 – 19 for Femto cells.

© 2016 Nokia

217


Figure 39


eNB configuration with neighbor eNB within PRACH reuse distance

Cellunder

H PRAC

reuse

nce

Dista

configuration

CellofhomePLMN

CellofneighborPLMNnot consideredforPRACHplanning

eNBwhichbelongstothecell underconfiguration

CellofneighborPLMN consideredforPRACHplanning

eNBoutsidePRACHreuse distance eNBwithinPRACHreuse distance

eNBofneighborPLMNwithin PRACHresusedistance eNBofneighborPLMNoutside PRACHresusedistance

Post condition A PRACH configuration is available for all cells subordinate to the eNB under configuration. These PRACH configurations will be stored as part of the eNB configuration plan file into the NetAct configurator plan database, and are available for further eNB auto-configuration as part of the same plan file. After eNB is auto configured, the eNB's current configuration is available from Configurator's current CM database.

6.6.4 System impact Interdependencies between features

218

© 2016 Nokia




LTE720:SON LTE BTS Auto-configuration This feature provides automated configuration of new or relocated base stations from a remote network operation center to minimize manual interventions. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools NetAct Optimizer/cSON supports the PRACH auto configuration as sub-process of the eNB auto-configuration process. NetAct Configurator supports the PRACH auto configuration as sub-process of the eNB auto-configuration process. Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.6.5 LTE581: PRACH Management Data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters The following table lists parameters introduced with this feature. Table 132

New parameters

Full name


Abbreviated name

Managed object

PRACH Configuration Index

PrachConfigIndex

LNCEL

PRACH Frequency Offset

PrachFrequencyOffset

LNCEL

PRACH Cyclic Shift

PrachCs

LNCEL

PRACH High Speed Flag

PrachHsFlag

LNCEL

RACH Root Sequence

RootSeqIndex

LNCEL

© 2016 Nokia

219




Sales information

BSW/ASW

SW component

ASW



NetAct

-


Terms and abbreviations

Term/Abbreviation

Description

ECR

expected cell range

IPL

increased path loss

Ex_Rach_Load

Expected RACH Load (expected RACH procedures per second)

Neighbor eNB

eNB with an X2 connection (or contained in LNADJ object) to the eNB under configuration

Neighbor cells

Cells of an eNB with a X2 connection (or contained in LNADJL object) to the eNB under configuration and its subordinated cells

Surrounding eNB's / cells

eNB's and their subordinated cells which have to be considered for PRACH planning (only intra-frequency cells), are independent if they have a X2 connection to the eNB under configuration or not

Geo location

Geo location refers to the latitude and longitude of the site (eNB) assuming that the subordinate cells to this eNB and the related antenna system share the same location. It is assumed that the position of the antenna is at the location of the eNB – no distributed antenna sites are supported. The full support of distributed antennas will be part of the next release.

6.7 LTE602: Performance Management Administration Introduction to the feature

220

© 2016 Nokia




Until now all performance measurements by default were activated and reported with fixed 15 minutes’ measurement period. This feature allows the operator to administer measurement types. The activation/deactivation and the measurement period can be set separately for every measurement type.

6.7.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits With the measurement administration, performance monitoring becomes more flexible. The operator can adjust the measurement settings according to his needs. The amount of performance monitoring data can be reduced which as a result reduces the postprocessing capacity and brings OPEX savings.


Release


System release

eNode B

NetAct

MME

SAE GW

RL30

LBTS3.0

OSS5.3 CD3

-

-


6.7.3 Functional description With the performance administration, the following settings can be modified: •

Measurement period configuration The measurement period can be configured in the Flexi Multiradio BTS for different measurement types. The supported values are: – – – – – –

15 minutes (default value) 30 minutes 60 minutes 6 hours 12 hours 24 hours

When the period ends, a raw PM data result file is created. If the new interval is longer than the current one, the measurement start is scheduled when the ongoing measurement ends. If the new interval is shorter, the measurement start is scheduled for the nearest trigger point of this new measurement period (in case of 30 minutes’ period, it is xx:00, xx:30, and so on).


© 2016 Nokia

221


•


Measurement activation/deactivation Different measurement types can be activated/deactivated in the Flexi Multiradio BTS. Only the counters that belong to an activated measurement are reported to NetAct or the BTS Site Manager. For information on available measurement types, see LTE Performance Measurements.

The PM administration information is embedded in the standard Configuration Management (CM) network plan file. The updated configuration information is sent to NetAct and the BTS Site Manager (BTSSM). NetAct, iOMS, eNB and the BTSSM support the following operations: • • •

setting PM parameters modifying PM parameters requesting PM parameter settings

6.7.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools The performance management administration is done using NetAct Configurator or locally with the BTS Site Manager. Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.7.5 LTE602: Performance Management Administration management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters To support the performance measurement configuration, the following objects are introduced: •

222

PMTNL - to configure parameters for measurements provided by the Flexi Transport Module (FTM)

© 2016 Nokia



•


PMRNL - to configure parameters for all the measurements that are not provided by the FTM

Figure 40: Performance management administration object structure shows the object structure in the eNB. Figure 40

Performance management administration object structure

Table 136: New parameters lists parameters introduced with this feature. Table 136

New parameters

Full name


Abbreviated name

Managed object

This information will be provided in further deliveries

This information will be provided in further deliveries

PMTNL

LTE Cell Availability

mtCellAvailability

PMRNL

LTE Cell Load

mtCellLoad

PMRNL

LTE Cell Resource

mtCellRes

PMRNL

LTE Cell Throughput

mtCellThruput

PMRNL

LTE EPS Bearer

mtEPSBearer

PMRNL

LTE Intersystem Handover

mtInterSysHo

PMRNL

LTE Neighbour Cell related Inter System mtInterSysHoGsmNb Handover GSM

PMRNL

LTE Neighbour Cell related Inter System mtInterSysHoUtranNb Handover UTRAN

PMRNL

LTE Inter eNB Handover

PMRNL

mtIntereNBHo

© 2016 Nokia

223


Table 136



Full name

Abbreviated name

Managed object

LTE Intra eNB Handover

mtIntraeNBHo

PMRNL

LTE Handover

mtLTEHo

PMRNL

LTE Network Sharing

mtNetwSharing

PMRNL

LTE Power and Quality DL

mtPowQualDL

PMRNL

LTE Power and Quality UL

mtPowQualUL

PMRNL

LTE RRC

mtRRC

PMRNL

LTE Radio Bearer

mtRadBearer

PMRNL

LTE S1AP

mtS1AP

PMRNL

LTE Transport Load

mtTranspLoad

PMRNL


mtUEandServiceDiff

PMRNL

LTE UE State

mtUEstate

PMRNL

LTE X2AP

mtX2AP

PMRNL

LTE eNB Load

mteNBload

PMRNL

LTE Neighbour cell related Handover

mtintraLTEHoNb

PMRNL

Performance Management RNL identifier

pmRnlId

PMRNL


Sales information

BSW/ASW



BSW

-

-

6.8 LTE644: Configurable cell trace content Introduction to the feature

224

© 2016 Nokia




Until now only the full content (all messages) of each selected interface was traced. This feature allows the operator to configure specific messages to be traced for each selected interface.

6.8.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The traced content becomes scalable. The operator decides which messages to trace. The trace data amount can be limited and the data analysis becomes more focused. The reduction of trace content decreases the post-processing needs, thus it brings OPEX savings.


Release


System release

eNode B

NetAct

MME

SAE GW

RL30

LBTS3.0

OSS5.3 CD3

-

-


6.8.3 Functional description With this feature, the operator is able to make a message-based selection of cell trace content. It helps to reduce the data amount based on the information granularity provided by the maximum trace depth. It also concerns the vendor-specific extensions. The vendor-specific tracing can be configured separately for cell trace and subscriber and equipment trace. In RL20 all the active UEs in the cell were traced. With this feature, the number of traced UEs in a cell trace session can be set with the cellMaxActiveUEsTraced parameter. The supported values are 1-10000.

g

Note: It does not mean that up to 10000 UEs can be traced. Currently, the maximum number of traced UEs within a cell is 840. The second method of reducing the trace content is the selection of protocol messages to be traced. During the cell trace configuration, a list of messages for every traced protocol (that is, S1AP, X2AP, RRC) can be defined. Elementary procedures (for example RRC connection establishment) as well as single messages (for example RRCConnectionSetup) can be selected. Tables below shows procedures that can be selected. The trace content is extended with this feature, as in addition to UE-specific


© 2016 Nokia

225



messages, also the UE-non-specific messages can be traced. When no cellId is configured for the cell trace then the trace session is valid for all cells of the eNB. This is called interface trace. Only in this mode all possible messages can be traced. For information on possible configuration, see Table 147: New parameters. Table 139

S1AP messages traced in all trace types (Subscriber, Cell and Interface trace)

MsgNumber

226

S1AP id-Elementary Procedure

Message Name

3

id-PathSwitchRequest (3)

PathSwitchRequest

259


PathSwitchRequestAcknowled ge

515


PathSwitchRequestFailure

5

id-E-RABSetup (5)

E-RABSetupRequest

261

id-E-RABSetup (5)

E-RABSetupResponse

6

id-E-RABModify (6)

E-RABModifyRequest

262

id-E-RABModify (6)

E-RABModifyResponse

7

id-E-RABRelease (7)

E-RABReleaseCommand

263

id-E-RABRelease (7)

E-RABReleaseResponse

8

id-E-RABReleaseIndication (8) E-RABReleaseIndication

265

id-InitialContextSetup (9)

InitialContextSetupResponse

521


InitialContextSetupFailure

11

id-downlinkNASTransport (11)

DownlinkNASTransport

0

id-HandoverPreparation (0)

HandoverRequired

256


HandoverCommand

512


HandoverPreparationFailure

257

idHandoverResourceAllocation (1)

HandoverRequestAcknowledg e

513


HandoverFailure

2

id-HandoverNotification (2)

HandoverNotify

© 2016 Nokia



Table 139


S1AP messages traced in all trace types (Subscriber, Cell and Interface trace) (Cont.)

MsgNumber



Message Name

4

id-HandoverCancel (4)

HandoverCancel

260

id-HandoverCancel (4)

HandoverCancelAcknowledge

13

id-uplinkNASTransport (13)

UplinkNASTransport

15

id-ErrorIndication (15)

ErrorIndication

16

id-NASNonDeliveryIndication (16)

NASNonDeliveryIndication

18

id-UEContextReleaseRequest (18)

UEContextReleaseRequest

19

idDownlinkS1cdma2000tunnelin g (19)

DownlinkS1cdma2000tunnelin g

20

id-UplinkS1cdma2000tunneling UplinkS1cdma2000tunneling (20)

21

id-UEContextModification (21)

UEContextModificationReques t

277


UEContextModificationRespon se

533


UEContextModificationFailure

22

id-UECapabilityInfoIndication (22)

UECapabilityInfoIndication

23

id-UEContextRelease (23)

UEContextReleaseCommand

279

id-UEContextRelease (23)

UEContextReleaseComplete

24

id-eNBStatusTransfer (24)

ENBStatusTransfer

25

id-MMEStatusTransfer (25)

MMEStatusTransfer

26

id-DeactivateTrace (26)

DeactivateTrace

28

id-TraceFailureIndication (28)

TraceFailureIndication

31

id-LocationReportingControl (31)

LocationReportingControl

© 2016 Nokia

227


Table 139


S1AP messages traced in all trace types (Subscriber, Cell and Interface trace) (Cont.)

MsgNumber

Message Name

32

idLocationReportingFailureIndica LocationReportingFailureIndica tion tion (32)

33

id-LocationReport (33)

LocationReport

42

id-CellTrafficTrace (42)

CellTrafficTrace

Table 140

S1AP messages traced only in case of Cell and Interface trace

MsgNumber


Message Name

8193


HandoverRequest

9


InitialContextSetupRequest

12

id-initialUeMessage (12)

InitialUEMessage

27

id-TraceStart (27)

TraceStart

Table 141

S1AP messages traced only in case of Interface trace

MsgNumber

228



Message Name

8202

id-paging (10)

Paging

8206

id-reset (14)

Reset

8462

id-reset (14)

ResetAcknowledge

8209

id-S1Setup (17)

S1SetupRequest

8465

id-S1Setup (17)

S1SetupResponse

8721

id-S1Setup (17)

S1SetupFailure

8221

id-ENBConfigurationUpdate (29)

ENBConfigurationUpdate

© 2016 Nokia



Table 141


S1AP messages traced only in case of Interface trace (Cont.)

MsgNumber



Message Name

8477


ENBConfigurationUpdateAckn owledge

8733


ENBConfigurationUpdateFailur e

8222

id-MMEConfigurationUpdate (30)

MMEConfigurationUpdate

8478


MMEConfigurationUpdateAckn owledge

8734


MMEConfigurationUpdateFailu re

8226

id-OverloadStart (34)

OverloadStart

8227

id-OverloadStop (35)

OverloadStop

8228

id-WriteReplaceWarning (36)

WriteReplaceWarningRequest

8484

id-WriteReplaceWarning (36)

WriteReplaceWarningRespons e

8229

ideNBDirectInformationTransfer (37)

ENBDirectInformationTransfer

8230

idMMEDirectInformationTransfer MMEDirectInformationTransfer (38)

8232

id-eNBConfigurationTransfer (40)

ENBConfigurationTransfer

8233

id-MMEConfigurationTransfer (41)

MMEConfigurationTransfer

8235

id-kill (43)

KillRequest

8491

id-kill (43)

KillResponse

8238

iddownlinkNonUEAssociatedLP PaTransport (46)

DownlinkNonUEAssociatedLP PaTransport

© 2016 Nokia

229


Table 141


S1AP messages traced only in case of Interface trace (Cont.)

MsgNumber

8239

Message Name

idUplinkNonUEAssociatedLPPa uplinkNonUEAssociatedLPPaT Transport ransport (47)

Table 142

X2AP messages traced in all trace types (Subscriber, Cell and Interface trace)

MsgNumber

X2AP id-Elementary Procedure

Message Name

256

id-handoverPreparation (0)

HandoverRequestAcknowledg e

512


HandoverPreparationFailure

1

id-handoverCancel (1)

HandoverCancel

3

id-errorIndication (3)

ErrorIndication

4

id-snStatusIndication (4)

SNStatusTransfer

5

id-uEContextRelease (5)

UEContextRelease

Table 143

X2AP messages traced only in case of Cell and Interface trace

MsgNumber


Message Name

8192


HandoverRequest

8193

id-handoverCancel (1)

HandoverCancelNonUE

8205

id-rLFIndication (13)

RLFIndication

8206

id-handoverReport (14)

HandoverReport

Table 144

X2AP messages traced only in case of Interface trace

MsgNumber

8194

230


X2AP id-Elementary Procedure id-loadIndication

© 2016 Nokia

Message Name

LoadInformation



Table 144


X2AP messages traced only in case of Interface trace (Cont.)

MsgNumber


8198

id-x2Setup (6)

X2SetupRequest

8454

id-x2Setup (6)

X2SetupResponse

8710

id-x2Setup (6)

X2SetupFailure

8199

id-reset (7)

ResetRequest

8455

id-reset (7)

ResetResponse

8200

id-eNBConfigurationUpdate (8) ENBConfigurationUpdate

8456

id-eNBConfigurationUpdate (8) ENBConfigurationUpdateAckn owledge

8712

id-eNBConfigurationUpdate (8) ENBConfigurationUpdateFailur e

8201

idResourceStatusRequest resourceStatusReportingInitiati on (9)

8457

idResourceStatusResponse resourceStatusReportingInitiati on (9)

8713

idResourceStatusFailure resourceStatusReportingInitiati on (9)

8202

id-resourceStatusReporting (10)

8204

id-mobilitySettingsChange (12) MobilityChangeRequest

8460

id-mobilitySettingsChange (12) MobilityChangeAcknowledge

8716

id-mobilitySettingsChange (12) MobilityChangeFailure

Table 145

ResourceStatusUpdate

RRC messages traced in all trace types (Subscriber, Cell and Interface trace)

MsgNumber 6


Message Name

Message Name SecurityModeCommand (DL-DCCH)

© 2016 Nokia

231


Table 145


RRC messages traced in all trace types (Subscriber, Cell and Interface trace) (Cont.)

MsgNumber

232

Message Name

262

SecurityModeComplete (UL-DCCH)

518

SecurityModeFailure (UL-DCCH)

7

RRCConnectionReconfiguration (DL-DCCH)

263

RRCConnectionReconfigurationComplete (ULDCCH)

9

RRCConnectionReestablishmentRequest (ULCCCH)

521

RRCConnectionReestablishmentReject (DLCCCH)

10

RRCConnectionReestablishment

266

RRCConnectionReestablishmentComplete (UL-DCCH)

11

RRCConnectionRelease (DL-DCCH)

13

MobilityFromEUTRACommand (DL-DCCH)

14

HandoverFromEUTRAPreparation Request (DL-DCCH)

15

ULHandoverPreparationTransfer (UL-DCCH)

17

MeasurementReport (UL-DCCH)

18

DLInformationTransfer (DL-DCCH)

19

ULInformationTransfer (UL-DCCH)

20

UECapabilityEnquiry (DL-DCCH)

276

UECapabilityInformation (UL-DCCH)

21

CSFBParametersRequestCDMA2000 (ULDCCH)

277

CSFBParametersResponseCDMA2000 (DLDCCH)

22

UEInformationRequest (DL-DCCH)

278

UEInformationResponse (UL-DCCH)

© 2016 Nokia



Table 145


RRC messages traced in all trace types (Subscriber, Cell and Interface trace) (Cont.)

MsgNumber 24

Table 146

Message Name LoggedMeasurementConfiguration

RRC messages traced in case of only Cell and Interface trace

MsgNumber

Message Name

4

RRCConnectionRequest (UL-CCCH)

516

RRCConnectionReject (DL-CCCH)

5

RRCConnectionSetup (DL-CCCH)

261

RRCConnectionSetupComplete (UL-DCCH)

8192

MasterInformationBlock (BCCH-BCH)

8193

SystemInformationBlockType1 (BCCH-DLSCH)

8194

SystemInformation (BCCH-DL-SCH)

8195

Paging (PCCH)

The selection mechanism is based on the input format - there are specific markings of the messages to be included in the trace records. The message selection is stored in a file. It is possible to apply selected trace settings individually for each trace configuration in the NetAct TraceViewer. Some trace profile configurations for usual cases are prepared in form of templates which contain pre-defined subsets of messages. These profiles can be modified by the operator and stored for future reuse. An individual trace profile can be selected in the TraceViewer for each trace session. It is easy to notice which trace settings are used during the trace activation and data retrieval. The applied configuration is clearly indicated, for example, the file name includes the trace selection and the applied trace content profile is included in the content of the trace data once per trace session.

g


Note: Trace recording session not closed after Intra-Cell Handover, when cell tracing with Timing Advance is enabled. The only way to close this Trace Recording Session is to close the whole Cell Trace Session by removing MTRACE object from configuration or disable Cell Trace feature which will close all Cell Trace Sessions. To avoid this problem Cell TA tracing parameter needs to be set to false in scope of Cell Trace. However this disables TA tracing.

© 2016 Nokia

233



6.8.4 System impact Interdependencies between features The LTE433: Cell Trace feature is required to use LTE644. With the LTE106: 6 cell support with one System Module feature, the maximum number of cell trace sessions per eNB is 12 (up to 12 MTRACE objects can be created). Impact on interfaces The tracing interface to protocol analyzer is enhanced to provide the MsgList parameters which indicate the selected messages to be traced for each protocol. Impact on network and network element management tools The NetAct TraceViewer application is used to select the messages and set the maximum number of UEs to be traced. Impact on system performance and capacity The reduction of trace content decreases the post-processing capacity needs.

6.8.5 LTE644: Configurable cell trace content management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 147: New parameters lists parameters introduced with this feature. Table 147

New parameters

Full name

234

Abbreviated name

Local cell resource identifier

lcrId

Trace S1 Setting

traceS1Setting

Trace X2 Setting

traceX2Setting

Trace RRC Setting

traceRrcSetting

Trace S1 Msg Category

traceS1MsgCategory

Trace X2 Msg Category

traceX2MsgCategory

© 2016 Nokia

Managed object

MTRACE



Table 147



Full name

Abbreviated name

Trace RRC Msg Category

traceRrcMsgCategory

Trace S1 UE Spec Msg List

traceS1UeSpecMsgList

Trace S1 Non UE Spec Msg List

traceS1NonUeSpecMsgList

Trace X2 UE Spec Msg List

traceX2UeSpecMsgList

Trace X2 Non UE Spec Msg List

traceX2NonUeSpecMsgList

Trace RRC UE Spec Msg List

traceRrcUeSpecMsgList

Trace RRC Non UE Spec Msg List

traceRrcNonUeSpecMsgList

Cell Maximum Active UEs Traced

cellMaxActiveUEsTraced

Cell identifier

cellid

Cell vendor specific tracing

cellVendorSpecTracing

Cell trace session identifier

mTraceId

Control Plane IPv4 Address

addCPlaneIpv4Address

Managed object

IPNO

Configuration example If the traceRrcSetting parameter is set to: • • •

specific - the traceRrcMsgCategory parameter is available all - all RRC messages are traced (traceRrcMsgCategory not required) none - RRC messages are not traced (traceRrcMsgCategory not required)

If the traceRrcMsgCategory parameter is set to: • • •

UEspecific (tracing of UE-specific messages) - the traceRrcUeSpecMsgList parameter is available nonUEspecific (tracing of UE-non-specific messages) - the traceRrcNonUeSpecMsgList parameter is available All (tracing all types of messages) - both traceRrcUeSpecMsgList and traceRrcNonUeSpecMsgList parameters are available

The same rule applies to S1 and X2 parameters. Table 148: Related existing parameters lists existing parameters related to this feature.

g


Note: These parameters are not supported from RL30 onwards.

© 2016 Nokia

235


Table 148



Full name

Abbreviated name

Interfaces To Trace (structure)

tracedInterfaces

Trace RRC Protocol

rrcTrace

Trace S1AP Protocol

s1Trace

Trace X2AP Protocol

x2Trace

Managed object

MTRACE


Sales information

BSW/ASW



BSW

-

-

6.9 LTE771: Optimization of Intra-LTE Neighbor Relations Introduction to the feature The NetAct Optimizer/centralized SON (cSON) supervises all registered cell relations between the neighboring LTE cells if they are still valid and reliable candidates to be a handover destination. When the outcome results is an inefficient neighbor relation, the according cell relation might be blacklisted for handover. The optimizer/cSON neighbor cell optimization is based on statistically reliable data derived from the measurements collected by terminals and eNB during their normal operation. In-line with a centralized SON function, it works in a mid to long term schedule. The NetAct keeps an updated view of the network configuration. NetAct Optimizer/cSON evaluates the PM data for the identified neighbor relations and proposes blacklisting if required. The NetAct Optimizer/cSON forwards the proposed configuration in a plan file to NetAct Configurator.

6.9.1 Benefits End-user benefits The feature increases the grade of service for the end user by maintaining well performing and robust handover relationships (mobility procedures). Operator benefits

236

© 2016 Nokia




The operator can reduce operating expenses (OPEX) due to the reduced workload in managing neighbor relationships.

6.9.2 Requirements Software requirements Table 150: Software requirements for RL40 lists the software required for this feature. Table 150

Release

Software requirements for RL40

System release

eNodeB

MME

SAE GW

UE

NetAct

RL40

LBTS3.0

-

-

-

OSS5.3 CD3


LTE System Module

6.9.3 Functional description Functional overview LTE771: Optimization of Intra-LTE Neighbor Relations is part of the overall ANR (3GPP 36.300: Automatic Neighbour Relation) functionality. LTE neighbor cells will be discovered and added by ANR features or manual input by the Operator. The neighbor eNB and cell configuration is configured or exchanged, via the X2 set-up procedure, in a bi-directional mode, so both peers can be the initiator. While the cell neighborship relation itself is first of all a uni-directional linkage from the source cell to the target cell. The eNB will establish cell neighbor relations based on UE events. The feature LTE771 focuses on cell neighbor relations in the following way: NetAct Optimizer supervises all current cell relations between neighboring LTE cells if they are still valid and reliable candidates to be a handover destination. When the PM counters show an inefficient neighbor relation, the according cell relation may be blacklisted for handover. NetAct Optimizer uses Flexi Multiradio BTS configuration information and performance counters (Intra-frequency and Inter-frequency Handovers) in order to perform the analysis of the task. The evaluation may result in no action or blacklisting of a neighbor cell relation.

g

Note: Operator hint: If there is a problem with Network Element (NE) in NetAct and NE has to be deleteted in NetAct and integrated again, the PM data in Optimizer cannot be assigned to the NE because the NetAct internal ID changed during the re-integration. The following use cases are supported:


© 2016 Nokia

237


•

•

•

g


Neighbor cell relations that have been created by the operator (network planning) or have been created by SON-mechanisms like ANR (automated neighbor relation) and which have an insufficient handover performance (for example weak handover success rate; threshold is operator-configurable) may be blacklisted by an optimization mechanism or, optionally, manually by an operator. Neighbor cell relations that have been created by the operator or have been created by SON-mechanisms like ANR (automated neighbor relation) which had been blacklisted, can be whitelisted/enabled again by the operator (for example if an operator wants to re-evaluate the performance of a formerly blacklisted neighbor relation due to changed environment/topology). Neighbors cell relations that have been created by the operator or have been created by SON-mechanisms like ANR (automated neighbor relation) can be marked by an operator in such a way that they are excluded from the optimization. Note: Neighbor cell is blacklisted, no outgoing handover to the target cell is allowed, neither via X2 nor via S1-interface.

Possible results of optimization mechanism. • •

No action: The analyzed relation showed no suspect behavior. Blacklisting: A given relation was identified to be unreliable/weak performing. NetAct suggests a new configuration plan file with updated entries for appropriate Telecom/RRM black lists.

Figure 41: LTE771 Optimization of Intra-LTE neighbor relations gives an overview of the feature.

238

© 2016 Nokia



Figure 41


LTE771 Optimization of Intra-LTE neighbor relations Optimizer

PM PM Configurator

CM CM

Monitor

NoHO

6.9.3.1

RAN system level scope The centralized SON feature LTE771 operates on existing NR to intra-LTE neighbor cells. Those can be pre-configured, learnt from ANR functions, or generated from off-line tools. The PM data administration is expected to run for the whole NetAct cluster or even the whole network. The PM data are checked for being representative, so that enough HO attempts are considered. As there are a lot of NRs found by ANR functions, some of those are often used for HO others less. The prerequisite for feature LTE771 is that NR PM counters be available on weekly granularity period or optional on daily or monthly basis. Each NR with at least the required-HO-number will be checked to ensure that their HO success rate is better then the defined threshold. The operator controls the feature LTE771 with a network/cluster profile setting. This includes the configuration of the scheduled workflow, as well as the thresholds for the SON function itself. The feature LTE771 focuses on long term supervision of the HO performance. This task requires keeping and aggregation of PM data for a longer period of time at NetAct. In RL30 the feature LTE771 blacklists bad performing NRs at eNB. The feature LTE771 does not remove NR. The eNB interprets this to blacklist those neighbor cells in the measurement request and HO decision. The operator can trigger the feature LTE771 manually. In this case the profile setting will be done interactively. The profile for automatic execution is not changed by this operation. The operator can request set of cells or eNBs optimization or eNBs.


© 2016 Nokia

239



If no or insufficient NR PM counters are available for a NR, then this is treated as the exit criterion for deciding on individual NR performance. The black-listing does improve the KPI short-term, but for each black-listed neighbor relation the operator should identify the root cause. Following situations can lead to bad HO performance in addition to missing MRO and general threshold mis-configuration: •

•

• •

6.9.3.2

PCI-confusion on cell level: There are for one reported PCI for several UE different CGI visible, this is a classical PCI collision. The eNB takes one PCI/CGI association and will not recover from this situation. The SON function PCI management does resolve such situations. PCI-confusion on eNB level: There are for one reported PCI in different (mainly distributed) cells for several UE different CGI visible. This is a 3GPP compliant PCI allocation, but the eNB will take one PCI/CGI association and will not recover from this situation. This requires to run LTE468: PCI management as this SON function recovers such a situation. pRACH-collision: The HO fails because of bad RACH performance. This requires manual execution of LTE581: PRACH management to recover this situation. pRACH-range configuration: The HO fails because of wrong RACH format for the actual distance from the UE towards the target cell. This requires manual execution of LTE581: PRACH management with a bigger ISD (Inter Cell Distance), to recover this situation.

Scheduled LTE771 execution NetAct Optimizer supports within a pre-set profile the scheduled execution of LTE771 related workflow by the workflow engine within the scope of all NetAct controlled LTE cells.The profile supports the following settings: • • • • •

feature activation/deactivation, the license management follows the general NetAct approach scheduler time control (start/stop, periodic start time/day/week/month) LTE771 controls parameter (# of HO attempt per day, required HO success ratio, threshold for black-listed NR per cell to notify to the operator) Execution control (break-point). Execution report generation (level of details).

NetAct starts periodically, upon the profile, the analysis of the NR performance based on the latest generated KPI data. NetAct Optimizer supports a periodically retriggered SON function that operates without further operator activity. NetAct Optimizer considers the operator decision to exclude certain NR from being changed by LTE771. NetAct Optimizer generates an LTE771 execution report to inform the operator online or off-line about the performance or problems of the SON function. NetAct Optimizer forwards the newly found NR that need to be blacklisted towards NetAct Configurator to implement this in the actual network. Manual LTE771 workflow execution: The start of the scheduled workflow can be triggered manually as well.

240

© 2016 Nokia



6.9.3.3


Use case scheduled workflow for LTE771 This use case describes the HO performance optimization of Intra-LTE NRs. The operator configures a scheduled job at NetAct that analyzes all the eNBs or LTE cells with respect to their intra-LTE neighborship performance. The eNBs or LTE cells will be the whole network or the actual NetAct cluster. The operator cannot directly configure the scope of LTE cells. The operator can run the process autonomously or request break-points. In autonomous mode, all the resulting blacklisting of bad performing NR is configured with one common plan file together for all the impacted eNB-cell-NR. Preconditions The LTE cells and eNBs exist and are under the management of NetAct. The operator has set the wanted NetAct policy values for optimization of intra-LTE NR optimization. The operator has enabled the scheduled job at NetAct. Description The following steps are supported by NetAct: 1. NetAct starts the workflow according to the configured week-day and day-time. 2. NetAct collects all eNBs and their cells in the current network, based on their actual configuration. It is ignored, if the eNB or it cell are locked, in reset or other states. 3. NetAct starts for the given list of cells for each cell the performance evaluation of its NR. 4. This step is repeated for the whole list of cells. NetAct updates the procedure execution report of one eNB or cell NetAct informs the operator about the progress of the procedure to run in background. 5. NetAct creates the new plan of the proposed blacklisted NR. 6. Without active break point, NetAct downloads and activates the plan files to each eNB. A SON report is generated and notified to the operator. 7. Confirmed execution, NetAct stops at this break-point. The operator can access the new plan of the proposed blacklisted NR(s). The operator can edit the plan and decide on the further steps, either to withdraw the plan file or to implement it. A SON report is generated and notified to the operator or stored at well-defined location. Result In the network the NRs that perform badly will be blacklisted.

6.9.3.4

Use case manual triggered workflow for LTE771 This use case describes the manual triggered HO performance analysis of Intra-LTE NRs. The operator selects a set of LTE cells. The operator starts for the selected set of cells the analysis of their intra-LTE neighbor ship performance. Preconditions The LTE cells and eNBs exist and are under management of NetAct. The operator has selected a set of cells, otherwise the LTE771 option is not supported. Description


© 2016 Nokia

241



The following steps are supported by NetAct: 1. The operator can modify the policy values for optimization of intra-LTE NR. 2. NetAct collects all eNBs and their cells in the selected scope, based on their current configuration. It is ignored, if the eNB or it cell are locked, in reset or other states. 3. NetAct starts for the given list of cells for each cell the performance evaluation of its NR. 4. This step is repeated for the whole list of cells. NetAct updates the SON report of one eNB or cell. NetAct informs the operator about the progress of the procedure. 5. NetAct creates the new plan of the proposed blacklisted NR. A SON report is generated and will be accessible by the operator. The operator can access the new plan of the proposed blacklisted NR. The operator can edit the plan and decide on the further steps, either to withdraw the plan file or to implement it. The procedure execution report will not consider those manual changes. NetAct provides SON context information (LTE1019: SON Reports) for CM History support of the SON reports. Result In the selected set of cells the NRs that perform badly will be blacklisted.

6.9.3.5

Use Case for the operator to manually clear the blacklist This use case describes the steps by operator to list all the actual blacklisted NRs and to clear for individual NR the blacklisting. Preconditions NetAct controls the LTE network. Description The following steps are supported by NetAct: 1. NetAct lists all LNREL instances that have for HO-allowed the value Forbidden and NR-control the value Automatic. 2. NetAct shows for the found LNREL instances the parameter HO-allowed and NRcontrol in a table. 3. The operator can edit for each NR the parameters HO-allowed. 4. Operator can save the the proposed changes to the NR parameters into a plan. 5. The operator can edit the plan and decide on the further steps, either to withdraw the plan file or to implement it. Result For the desired set of Neighbor Relations (LNREL), the NR blacklisting is removed.

6.9.3.6

SON modus The functionality required from LTE771 is of the self-optimization type. The procedures optimize the neighborship relations based on performance data. The operator can execute the function of LTE771 manually triggered, too.

242

© 2016 Nokia




The operator can influence the neighborship optimization algorithm with policies to adapt the result towards his desire. The main control is the network-wide threshold of not acceptable HO performance. The procedures are designed to work automatically based on policy settings for all cells and their NR on network or NetAct scope. By default LTE771 considers all NR. The operator can switch to manual mode for each NR. Then this NR is not considered by LTE771 anymore. The following NetAct based policies are applicable at network level: • • •

feature activation flag at NetAct minimum number of HO attempts per day [#/day, {0..10000} default: 10] required success ratio for HO [%, {0..99.9} default: 50,0]

The following eNB based policies are applicable at NR level: • •

6.9.3.7

NR-control per NR {automatic, manual} default automatic HO-allowed per NR {allowed, forbidden, S1only} default allowed

Reporting The operator can investigate the output of the automated process and optionally verify the proposed changes, or investigate the applied changes. The operator is informed about the progress of the LTE771 function for each cell or eNB. The following reports are shown: • • • •

total and done number of cells or eNBs number of checked NR blacklisted NR ignored NR

After the execution of LTE771, the operator can have a look on the proposed neighborship relations blacklisting. The operator can edit the lists in principle. If the operator wants a certain deviation with respect to the ANR optimization result, this has to be changed at the NR characteristic setting, for example to set this NR as whitelisted. Any changes by the feature LTE507: InterRAT neighbor relation Optimization (LTE, UTRAN, GERAN) will be marked with a SON context lable. This allows to generate SON Reports (LTE1019: SON Reports) from CM History contents. The operator can retrieve any changes done by LTE507.

6.9.3.8

Operator interaction outside of LTE771 The MIB of the network is modified by the automated LTE771 procedures, nevertheless, the operator himself can also access the MIB directly via NetAct. There is an NR-control parameter to avoid access collisions. If the operator changes to manual control, then LTE771 procedures ignore this NR. Then manual changes to the current neighbor ship relations are considered by the automated procedures.. The operator value setting of: • •


HO-allowed forbidden and NR-control manual -> blacklisting of NR. HO-allowed allowed and NR-control manual -> whitelisting of NR.

© 2016 Nokia

243



The operator can select for HO-allowed the value S1only. With respect to LTE771 the HO-allowed values Allowed and onlyS1 are treated equally. LTE771 might change it to “forbidden”. The operator can change these values manually to Allowed or onlyS1.


•

g

Note: Operator hint: Up to RL20 the neighbor eNBs are found, based on the IP address configured in ADIPNO-adjEnbCPlaneIpAddress. With the upgrade to RL30 the IP address are moved into the persistent object LNADJ. During upgrade the IP address has the characteristic LNADJ-cPlaneIpAddrCtrl= oamControlled. As LTE771 is based on the LNREL-eCGI to identify the related LNADJ instance with the same eCGI, we recommend to enable LTE782 and change all IP address characteristics to enbControlled. This ensures that the LNREL-eCGI is always correctly assigned to the related LNADJ-global-eNB-ID. So that the correct PCI values are blacklisted. • •

g

LTE797: PM Counter Handover The PM Counter Handover feature provides more detailed insight into handover performance. LTE492: ANR If an unknown physical cell ID (PCI) is detected by the Flexi Multiradio BTS, the corresponding C-plane IP-connectivity information (IP address) of the neighbor site is resolved and the X2 signaling connection is set up in order to exchange neighbor cell information; alternatively the X2 interface is opened for control layer applications. Note: Operator hint: In RL20 the neighbor eNBs are found, and the IP address is configured at ADIPNO-adjEnbCPlaneIpAddress. With the upgrade to RL30, the IP address is moved into the persistent object LNADJ. During upgrade the IP address has the characteristic LNADJ-cPlaneIpAddrCtrl= "oamControlled". As LTE771 is based on the LNREL-eCGI to identify the related LNADJ instance with the same eCGI, we recommend to enable LTE492 and change all IPaddress characteristics to enbControlled. This ensures that the LNREL-eCGI is always correctly assigned to the related LNADJ-global-eNB-ID. So that the correct PCI values are blacklisted. In addition for LTE492 it is mandatory to have an up-to-date PCI/IP address table in case of LTE468: PCI management - PCI changes.

•

244

LTE651: Performance Monitoring The feature provides basic counters to verify basic system functionality and performance. Support for basic network optimization for coverage and performance. Internally provided performance counters can be complemented by external tracing tools and drive test data LTE724: LTE Automatic Neighbor Cell Configuration The establishment of neighbors is based on the information which is prepared in a pre-planning. Only a subset of information to standard configuration is required. For all neighbor cells only the Node-ID and the IP address of the neighbor LTE eNB hosting the expected neighbor cells need to be configured by offline pre-planning. All other configuration information for cells of neighbor LTE eNBs are automatically derived and updated via the X2 interface.

LTE782: ANR - Intra-LTE, Intra-frequency - Fully UE-based This feature covers Intra-LTE, Intra-frequency automated neighbor relation configuration (ANR). In case an unknown physical-layer cell ID (PCI) is detected and reported by a UE to the Flexi Multiradio BTS, the corresponding EUTRAN Cell Global ID (ECGI) is derived with the

© 2016 Nokia




help of the UE-measurements. The Flexi Multiradio BTS resolves the corresponding public IP address of the new found neighbor Flexi Multiradio BTS, and establishes the X2 connection to exchange neighbor cell information; alternatively, opens the X2 interface for control layer applications.

g

Note: Operator hint: As LTE771 is based on the LNREL-eCGI to identify the related LNADJ instance with the same eCGI, we recommend to enable LTE782 and change all IP address characteristics to enbControlled. This ensures that the LNREL-eCGI is always correctly assigned to the related LNADJ-global-eNB-ID. So that the correct PCI values are blacklisted. Operation of LTE782 requires MME support for IP address resolution based on global-eNB-ID. •

•

LTE53: Intra and inter eNB handover with X2 The Flexi Multiradio BTS supports intra-frequency intra-LTE handover via X2. Both the intra-eNB handover and the inter-eNB handover scenario are included. Downlink data forwarding over X2 is applied for lossless data path switching. LTE54: Intra-LTE handover via S1 The following S1 based intra-LTE handover scenarios are supported by the Flexi Multiradio BTS: – – –

•

LTE55: Inter-frequency handover The following inter-frequency handover scenarios are supported by the Flexi Multiradio BTS: – – – – – –

•

•

inter-eNB, intra-MME and intra-S-GW inter-eNB, inter-MME and intra-S-GW inter-eNB, inter-MME and inter-S-GW

intra-eNB, inter-frequency band intra-eNB, intra-frequency band with different center frequency inter-eNB, inter-frequency band via X2 inter-eNB, intra-frequency band with different center frequency via X2 inter-eNB, inter-frequency band via S1 (if enabled) inter-eNB, intra-frequency band with different center frequency via S1 (if enabled)

LTE1019: SON Reports This feature defines SON feature labels, that are automatically added as context information for each change done by a SON function in the network configuration. In the CM History tool it is possilbe to generate SON Reports showing the changes done by LTE771. LTE1222: ANR Auto Configuration and Scheduling This feature is a summary of the scheduled activation use cases shifted from RL30 features to RL40 features.



© 2016 Nokia

245



6.9.5 LTE771:Optimization of neighbor relations management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters Table 151: New counters lists counters introduced with this feature. Table 151

New counters

Counter ID

Counter name

Measurement

M8015C1

Intra eNB HO attempts per neighbour cell

HO attempts

M8015C8 (S1/X2)

Number of Inter eNB Handover attempts per neighbour cell relationship

HO attempts

M8015C2

Intra eNB HO successes per neighbour cell

successful HO

M8015C9 (S1/X2)

Number of successful Inter eNB Handover completions per neighbour cell relationship

successful HO


New parameters

Full name

246

Abbreviated name

Managed object

Neighbor Relation Control

nrControl

LNREL

handover Allowed

handoverAllowed

LNREL

© 2016 Nokia





Sales information

BSW/ASW

SW component



ASW NetAct

-

NetAct

-


Abbreviations

Abbreviations

Description

ANR

Automated Neighbor Relation

COC

Cell Outage Compensation

inter-RAT

Inter Radio Access Technology

MOC

Managed Object Class

MRO

Mobility Robustness Optimization

TLA

Transport Layer Address

NbEnb

Neighbor eNB

NbCell

Neighbor Cell

NR

Neighbor Relation

NRT

Neighbor Relation Table

NI

Neighbor Information

RAT


6.10 LTE782: ANR Fully UE Based Introduction to the feature The LTE782: ANR Fully UE Based feature covers intra-LTE, intra-frequency automatic neighbor relation configuration (UE-based ANR). If the eNB gets a measurement report from a UE with a physical cell (PCI) that it does not recognize, it will command the UE to report the EUTRAN Cell Global ID (ECGI) associated with the PCI. The eNB will then use the ECGI and PCI to obtain the X2 C-Plane IP address of the newly discovered LTE neighboring cell via the S1 interface, using the SON information exchange procedure.


© 2016 Nokia

247



Once the X2 C-Plane IP address is obtained, the eNB will attempt to establish an X2 connection with the newly discovered neighbor. The new neighbor information is persistently stored at the eNB for further use by the mobility management subsystem at the eNB.

g

Note: If the X2 C-Plane IP address is not obtained via the S1 interface, the eNB will still attempt handovers to the unknown neighbor via S1 handovers. In addition to the LTE724: Automatic Neighbor Cell Configuration feature in RL30 the LTE neighboring cell configuration is persistently stored at the eNB. This is a common approach for all ANR features. According to the activited ANR features, the X2 link can be re-established after each link drop based on: • • •

oamControlled LNADJ: the IP address enbControlled LNADJ and the LTE492: ANR feature activited: the PCI/IP address table with any PCI of a child LNADJ object enbControlled LNADJ and the LTE782: ANR Fully UE Based feature activited: the MME-S1 based IP address resolution from global eNB ID; in case LTE492: ANR is also activited, the eNB first tries to check the PCI/IP address table.

For all cells on the eNB, the persistent neighboring cell's information allows S1 handover, while X2 handover is preferred if the X2 link is active. Whenever one camping UE sees one of these known neighboring cells and this neighbor is selected as HO target then, within this cell, a neighboring cell relation is established. The LTE782: ANR Fully UE Based feature does not require additional support from the NetAct. However, the eNB will update the NetAct with newly discovered neighbor information.

6.10.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The automated detection and configuration of unknown cells, accordingly sites, supports the self configuration of the neighbor cell information without operator involvement and planning efforts.


Release

248


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

x

-

-

OSS5.3 CD3

© 2016 Nokia



Table 155


Software requirements (Cont.)

System release

eNodeB

MME

Some of functionalities are valid for RL50 and RL60.

SAE GW

UE

NetAct

OSS5.5 for RL50 NetAct 8 EP1 for RL60

Hardware requirements This feature requires no new or modified hardware.

6.10.3 Functional description Functional overview In the LTE networks the UE mobility relies on the information given by neighbor cell relations and neighbor cell configurations. An automatic mechanism is implemented to discover and integrate the unknown cells. It supports and allows the automated configuration and update of neighbor cell information without the need for an off-line planning update of the neighbor cell configurations.


© 2016 Nokia

249


Figure 42 Neighbor Site eNB-B


ANR principle Site eNB-A

UE connected

MME

Newcell discovered Newcell identified by ECGI

Neighborcellinformationcreation S1:RequestX2TransportConfiguration(ECGI) relays request

S1:RequestX2 TransportConfiguration

CM S1:RespondX2TransportConfiguration(IP@) S1:RespondX2TransportConfiguration(IP@)

AddSite&Cell parameterof eNB-A

CM X2Setup:Ipsec,SCTP,X2-AP[site&cellinfo]

CM

relays request

AddSite&Cell parameterof eNB-B

CM NeighborCellTablesinbotheNBupdated

Neighbor cell configuration via X2 initiated by camping UE The UE reports all detected/strongest cells above a given threshold. Therefore, it might report strong cells whose physical IDs are currently not yet known to the Flexi BTS. In this case the Flexi BTS might send a measurement request to the UE to discover and report the EUTRAN Cell Global ID (ECGI) for the previously reported unknown physical cell ID. After ECGI resolution the configuration of neighbor cell and neighbor relation (NR) is stored. The cell is available for S1HO. If there is no X2-link available and the X2-link establishment is not forbidden by the operator (via X2 neighbor blacklisting), the eNB retrieves the IP address serving the resolved neighbor cell and sets up the X2 connectivity. The X2 connectivity is set-up including establishment of the IPsec layer if the network domain security is applied followed by the SCTP connection setup.

250

© 2016 Nokia



g


Note: There might be cases when the Flexi BTS cannot establish an X2 link: • •

if the Flexi BTS has already set up the maximum number of X2 connections if the target Flexi BTS is in the operator's blacklist for X2 link connection (but not for S1)

On X2 application layer the Flexi BTS exchanges a list of served cells and subsequent configuration parameters with the new neighbor. The exchanged cell information covers all served cells of a site and is stored in the configuration databases of both sites. When the new neighbors are successfully included into the local configuration data, the Flexi BTS sends a configuration change notification to the NetAct to inform the operator about the new cell configurations. Active/Passive ANR To reduce the probability of call drops, the Flexi BTS supports ANR mechanisms to detect and configure any unknown neighbor cell as early as possible and not at the time when the first HO, to a newly detected cell, is triggered. This kind of operational mode of ANR is further referred to as active ANR. Active ANR If active ANR handling is started, the Flexi BTS will pro-actively scan for unknown intrafrequency LTE cells. The operator can reduce the number of unknown neighbor cells detected via Active ANR mode by setting a high value for the anrThresRSRPNbCell threshold parameter defined in the ANR profile. Passive ANR If no unknown cells need to be detected anymore, ANR operates as a background task. For example, the Flexi BTS does not configure ANR-specific measurements but uses normal measurement reports (as received for HO) for the detection of unknown cells. The operator can configure the ANR behavior of ANR, for more information see the ANR configuration via ANRPRL chapter in the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature description. Monitoring of ANR is supported by means of performance measurements. The following events can be monitored: • • •

number of successful/failed/attempted ECGI-resolutions number of successful/failed/attempted MME-queries (IP adress resolution) number of successful/failed/attempted X2-setups

After new neighbor cell relations have been successfully included into the local configuration data, the Flexi BTS sends a configuration change notification to the NetAct to inform the operator about the new neighbor cell configurations. Interworking of the LTE782: ANR Fully UE Based with the LTE492: ANR Both features LTE782: ANR Fully UE Based and LTE492: ANR can be activated at the same time in the network. If a new PCI on a certain radio frequency (RF) is found and the PCI/EARFCN/IP address lookup table contains the mapping information for this PCI and RF, then the information in the PCI/EARFCN/IP address lookup table is applied.


© 2016 Nokia

251



If the new PCI and RF is not included in the PCI/RF/IP address lookup table, then the LTE782: ANR Fully UE Based feature mechanism is applied to detect the required information.

g

Note: The LTE492: ANR feature is needed, if inter-frequency LTE neighbor cells need to be resolved. The operator configures the required inter-frequency measurement configuration for the known center frequency. This measurement configuration supports neighbor finding as well as the preparation for the HO to these neighbors. Interworking with the LTE539: Central ANR or manual neighbor configuration The operator can manually add neighbors parallel to the ANR function. The LTE539: Central ANR feature can pre configure a certain number of neighbor eNBs based on geo-locations. ANR learns from the current neighbor configuration. If the LTE539: Central ANR and the LTE782: ANR Fully UE Based features are activited, then the LTE539: Central ANR feature profile setings for minimum and maximum number of the neighbor cells should be rather at 3...6 neighbor cells, so that there is more room for finding suitable neighbors by the LTE782: ANR Fully UE Based feature on UE measurements.

g

Note: Operator hint As the radio path loss is high, the LTE782: ANR Fully UE Based feature works very well in coverage-limited network deployments (typical for rural and suburban areas). The UE reports a few neighboring cells, and all cells have a meaningful number of neighbors; no X2 black-listing is required. A requirement for a higher power level for measured neighbors in the active mode at an anrThresRSRPNbCell = 40 (= -100dBm) default value is proposed for the coveragelimited networks deployments. The LTE771: Optimization of Neighbor Relations feature can find some NRs that lead to a higher number of failures, but the threshold for the required success rate should not be set above 80%. Blacklisting of neighbor relation (LNREL) in coverage-limited networks should be based on a long-term supervision as mandatory neighbor relations are not black-listed. In such cases coverage holes might be the reason for call drops or HO failures, which cannot be improved by black-listing. If, for any reason, there are far-away neighbor eNBs connected via X2, with PCI values the same ase newly installed nearby eNBs, they will be detected by the LTE771: Optimization of Neighbor Relations feature and proposed to be black-listed in LNREL. In addition, the LTE468: PCI Management feature will check on neighbor's neighbors and propose to update the duplicate PCI values; wrong neighbors are still being configured but without a negative impact. To remove wrong neighboring eNBs and their X2 link, first they are X2 black-listed, and then the corresponding LNADJ&LNADJL is removed. This can be done for each eNB individually. Incoming HO via S1 is still supported. In capacity-limited network deployments (urban areas), the LTE782: ANR Fully UE Based feature will receive a lot of UE measurements containing other cells visible to them. The LTE782: ANR Fully UE Based feature will continue to add those cells; thus, the number of neighbors needs to be limited.

252

© 2016 Nokia




A requirement for a higher power level for measured neighbors in the active mode at anrThresRSRPNbCell = 50 (= -90dBm)... 60 (= -80dBm) is proposed for capacitylimited networks deployments. In addition, the operator is recommended to watch the found NR from a performance point of view. The LTE771: ANR Optimization feature finds an NR with low HO success rate. The level of a required HO success rate can be set to 90% from long term PM data supervision (for example, one week). Moreover, the operator can see the NR with insufficient HO attempts. If there is a high number of such NRs to all cells of one neighbor eNB, then this eNB can be X2 black-listed. This is done by adding the eNB's global ID into the LNBTS - glbNbEnbldX2LinkBlacklist[64]{global eNB ID}. Still, the LNADJ and LNADJL are kept to execute S1 HO. The X2 HO reduces the core load for HO execution so the NR with higher HO rate obtains one of the X2 links. Here we assume that all neighbor eNBs have eNB-controlled IP addresses set by the cPlanelpAddrCtrl = enbControlled(1) LNADJ - parameter. Having the X2 links on the main HO paths ensures in addition an in-time exchange of parameters between the eNBs, for example, in case of PCI updates at one peer. For those LNADJL that do not have the X2 link, the NetAct will trigger a plan preparation for updating their PCI value at LNADJL - phyCellId. This can take some time but should be acceptable for low HO performance. If almost all of the LNADJ instances are in use, the operator should remove some of them. The best candidates to be removed are those neighbor relations which have no HO attempts (via S1) at all cells of a neighbor eNB, and their X2 link was X2 black-listed before. The LTE1685: Neighbor Relation Robustness feature deletes their LNADJ and LNADJL objects. The free LNADJ might be occupied by new neighbors after the LTE782: ANR Fully UE Based feature finds any. Having a lot of neighbors per cell influences the LTE468: PCI Management feature. As PCI management considers the existing NR, it is quickly impossible to find suitable PCI values. Limitation of the “Addition of new neighbors” There is the possibility in the ANR intra-frequency handling (either with the LTE782: ANR Fully UE Based feature or LTE492: Automatic Neighbor Relation feature) to limit addition of new neighbors. For "passive ANR", the addition of new neighbors is limited to the following cases: • •

Accept the strongest unknown PCI in A3/A5 as “Candidate for ANR” only if no other HO targets are available. In addition to existing conditions, accept unknown PCI in reportStrongestCells (RSC) as “Candidate for ANR” only if it is the strongest PCI included in RSC.

This intention is as follows: If neither stronger nor any other known HO target cells for HO preparation are available, then available, consider the srongest unknown PCI in A3/A5 as “Candidate for ANR”. Addition of neighbors are allowed only up to a maximum amount which can be specified by the operator.


© 2016 Nokia

253



The eNB limits creation of new NRs by using the nrLimitIntraFreq/nrLimitInterFreq parameters. When the number of LTE intra/inter-frequency NRs of the eNB cell reaches the nrLimitIntraFreq/nrLimitInterFreq, the eNB stops autonomous learning of new neighbor cells via ANR.

g

Note: If the limits for the amount of neighbor relation have been crossed before already in the eNB database, no action is triggered in the eNB. If an unknown PCI is accepted as a “Candidate for ANR”, then the eNB resolves the neighbor information (via CGI measurement or X2) and stores the related LNADJ/LNADJL objects.

6.10.3.1

Use case: UE-based ANR retrieval by eNB Prerequisites • •

the neighbor eNB (Nb-eNB) cells operate on the same frequency as the cells of the eNB X2-link establishment is allowed/possible

Description • • • •

The eNB detects so far unknown intra-frequency LTE neighbor cells The eNB retrieves the configuration information (for LTE: ECGI, TAC, PLMNs) of the detected neighbor cells with help of the UE measurements The eNB stores the detected neighbor cells with known (and stored) configuration information as the Neighbor Relations to the eNB cells where they were detected The eNB determines the IP-addresses of the neighbor eNBs serving the detected neighbor cells (usually via S1-i/f) and establishes X2-links to the neighbor eNBs using the previously determined IP-addresses

Result • • •

254

X2-links to Nb-eNBs are established. Neighbor cell configuration information is stored in the eNB. Neighbor Relations are stored in eNB.

© 2016 Nokia



Figure 43


UE-based ANR Retrieval by eNB

NbeNB NbeNB

NbeNB

NbeNB

NeighborCell

eNB NbeNB

NbeNB NbeNB NbeNB

6.10.3.2

eNBdiscovering neighborcells viaUE-basedANR

Use case: UE-based ANR at domain border Prerequisites eNB operates normally. eNB is located at a domain border (for example X2-link establishment across the domain border is assumed to be not possible).

• •

Description The eNB detects so far unknown intra-frequency LTE neighbor cells. The eNB retrieves the configuration information (for LTE: ECGI, TAC, PLMNs) of the detected neighbor cells with the help of UE measurements. For the Nb-eNBs located in the same domain as the eNB, the eNB determines the IP addresses of the neighbor eNBs serving the detected neighbor cells and establishes X2-links to the neighbor eNBs using the previously determined IP addresses. No X2-links are established to Nb-eNBs which are located on the other side of the domain border

• • •

•

Result Neighbor cell configuration information is available at eNB. To Nb-eNBs belonging to the same domain as the eNB, X2-links are established. No X2-links are established to Nb-eNBs on the other side of the domain border.

• • •

g

Note: • • •


Domain border may be a country/network border. Suitable eNB Blacklisting for X2-links across such domain borders has to be provided. The operator may apply eNB Blacklisting to X2-links also for single neighbor eNBs.

© 2016 Nokia

255


Figure 44


UE-based ANR at Domain Border

domainborder NbeNB NbeNB NbeNB

NbeNB

NeighbourCell connectedviaX2

eNB NbeNB

NbeNB NbeNB

eNBdiscoveringneighbour cellsviaUE-basedANR

NbeNB

NeighbourCell notconnectedviaX2

6.10.3.3

LTE NB cell information Neighbor cell configuration information for a LTE NbCell received via O&M includes the following configuration information of the neighbor cell: • • • • •

CGI of the LTE NbCell PLMN IDs supported by the LTE NbCell TAC of the LTE NbCell Physical Cell ID (PCI) of the LTE NbCell downlink EARFCN of the LTE NbCell

At X2 link establishment additional information is stored in the LNADJL object.

6.10.3.4

SON information exchange via S1 SON Information exchange via S1 is applied to retrieve the X2 IP address of a neighbor eNB which is not yet connected to the eNB via X2. The retrieval of the X2 IP address of a neighbor eNB node is possible by combining the “eNB Configuration Transfer procedure” and the “MME Configuration Transfer procedure”.

6.10.3.5

PCIs Blacklisted for Intra-LTE ANR The LTE782: ANR Fully UE based feature reuses the existing PCI blacklist for handover:

256

© 2016 Nokia




PCIs which are blacklisted for handover are also be “blacklisted for Intra-LTE ANR”. For example, if such a PCI is received in a Measurement Report from UE, this PCI is ignored by ANR functionality in the eNB.

6.10.3.6

X2 link blacklisting X2 blacklisting is based on the global eNB Id. A new plan file configured LNBTS list parameter for X2 blacklisting glbNbEnbIdX2LinkBlacklist has been introduced. Up to 64 list entries are supported. The X2 Link blacklisting applies to all eNB-controlled X2-links. X2 blacklisting generally applies to, and does not depend on ANR feature activation. The NetAct and BTS Site Manager are informed about any change of blacklisting information.

g 6.10.3.7

Note: Operator hint If in an X2 black-listing entry the enbId parameter is omitted, then all eNBs of the set PLMN are X2-BL. This can be used for foreign PLMN, that do not allow X2 setup.

Neighbor information management Neighbor eNB and neighbor LTE cell information is stored in the instances of the dedicated MOCs LNADJ or LNADJL independent from the origin of the information. The information may be provided via X2 interface, via UE based ANR procedures, and via plan file. The new LNADJL read-only parameter sourceOfData provides information about the origin of the information (X2, UE or OM). All neighbor information is permanently stored in the eNB. Neighbor information which was configured in a previous release is automatically migrated to the new model. NetAct and BTS Site Manager are informed about creation, update, and deletion of neighbor information independent from its origin. The requirements for storage of LTE neighbor information generally apply to and are not related to the activation or deactivation of ANR features. Each relation to an LTE neighbor cell is stored in a dedicated relationship LNREL object. An LNREL object represents the unidirectional relation between the source and the target cell and acts as a container for relationship-specific information. The ECGI is used as a reference. The LNREL object is created, if a neighbor cell is detected and reported by a UE provided that the LNADJL/LNCEL object exists and an HO attempt was initiated to this neighbor cell. The referenced LNADJL or LNCEL object may exist or not, and the neighbor relation (NR) information is permanently stored per LNCEL instance. NetAct and BTS Site Manager are informed about any change of NR information. Objects representing neighbor eNB and LTE neighbor cell:


© 2016 Nokia

257


Table 156


LTE782 Objects

Object

Description

LNADJ

All neighbor eNB related information are stored in instances of the MOC LNADJ. neighbor eNB related parameters are moved from ADIPNO to LNADJ.

LNREL

A LNREL object is automatically created by the eNB, if a neighbor cell is reported by the UE with sufficient receive power. That neighbor cell is target for an HO attempt and the configuration information of the neighbor cell is available in the eNB. The MOC represents properties of LTE neighbor relations. It provides information about LTE neighbor relationships. The neighbor relation information is provided by Telecom or via plan file. A new instance of LNREL is created together with a learned LNADJL or an existing LNADJL, where the PCI was reported in an A3 or A5 measurement and an HO attempt was initiated. That new LNREL creation requires mandatory the related ECGI. All other data are filled with default values The Eutra cell global Id is used as a reference to the neighbor cell object (LNADJL or LNCEL).

6.10.3.8

X2 link management The C-plane IP address of neighbor eNBs is moved from ADIPNO to LNADJ. Two different types of X2 links are distinguished via the LNADJ parameter cPlaneIpAddrCtrl: •

•

oamControlled X2 link. The eNB establish the X2-link using the IP address provided via plan file. (no ANR mechanisms to determine IP address are used by the eNB.) enbControlled X2 link. The ANR mechanisms to establish and maintain the X2 link are applied by the eNB. (This includes retrieval of the IP address for X2 link establishment.)

Modification of the X2 link type (cPlaneIpAddrCtrl) via plan file is allowed and the new LNADJ read-only parameter x2LinkStatus provides information whether the link is available or unavailable. NetAct and BTS Site Manager are informed about any change of X2 link configuration and status information. Nokia eNB ANR functions rely on the fact that other-vendor neighbor eNBs inform the eNB during X2 setup about all its served cells (as requested by 3GPP 36.413), especially about all cells which are on air. Non-compliance of other-vendor neighbor eNBs on this may considerably impact ANR functions in the eNB. oamControlled X2 links The oamControlled X2 links have the following basic properties:

258

© 2016 Nokia



•

•

• •


The IP-address to be used for the establishment of the oamControlled X2 link is provided by the operator in the LNADJ object instance. It is the responsibility of the operator to cater for correct configuration of the IP-address of the oamControlled X2 link. The eNB automatically triggers the establishment of the oamControlled X2 link configured by the operator (for example if startup of the eNB occurs). No further conditions are checked by the eNB. Establishment of the oamControlled X2 link has priority over establishment of the enbControlled X2 link. If the establishment of the oamControlled X2 link fails, an alarm is raised by the eNB.

To avoid inconsistencies regarding establishment/re-establishment behavior, it is recommended to configure the same X2 link type at both sides of the X2 link (that is if the X2 link is configured as oamControlled in eNB, then it should be also configured as oamControlled in the peer eNB). enbControlled X2 links The enbControlled X2 links have the following basic properties: •

•

•

•

All X2 links which are automatically established by the ANR functions are labelled as the enbControlled X2 links. Activation of at least one of the ANR features (either LTE492: Automatic Neighbor Relation (ANR) or LTE782: ANR Fully UE based) is a pre-condition for the establishment of the enbControlled X2 link. The ANR functions of the eNB trigger the automatic establishment of the enbControlled X2 link, if the eNB detects that handover procedures to cells of the neighbor eNB have to be performed. The IP-address needed for X2 link establishment is automatically determined by the eNB (for IP-address retrieval mechanisms, see also LTE492: Automatic Neighbor Relation (ANR) in Automatic Neighbor Relation (ANR)). Establishment of the enbControlled X2 link to some neighbor eNB might be forbidden by the operator via X2 link blacklisting.

Regarding re-establishment of enbControlled X2 links, the eNB behaves as described in Outgoing enbControlled X2 link (establishment triggered by the eNB) and Incoming enbControlled X2 link (establishment triggered by neighbor eNB).

g

Note: In RL50, the eNB establishes an enbControlled X2 link only if at least one of the features LTE782: ANR Fully UE based or LTE492: ANR is activated (that is, either the actUeBasedAnrIntraFreqLte or anrOmExtEnable parameter is set to true). From RL60 on, handling of enbControlled X2 links is a basic functionality and is not guarded by any feature flag. Setting the maxNumX2LinksIn and the maxNumX2LinksOut parameters' values to 0 is the only way to disable accepting/establishing of enbControlled X2 links from RL60 on. Outgoing enbControlled X2 link (establishment triggered by the eNB) The eNB will trigger (re-)establishment of the enbControlled X2 link if all of the following conditions are met: •

• •


The eNB has seen that cells of the neighbor eNB are necessary as targets for handover (in this case LNREL/LNADJL object pairs are available associated with the neighbor eNB). The operator has not forbidden establishment of the enbControlled X2 link via X2 link blacklisting. The number of X2 links is still smaller than the maxNumX2LinksOut parameter.

© 2016 Nokia

259


•


The maximum number of X2 links, which can be established by the eNB, is not reached yet.

Incoming enbControlled X2 link (establishment triggered by neighbor eNB) The eNB will accept establishment request of the enbControlled X2 from the neighbor eNB if all of the following conditions are met: • • •

g

Note: The eNB will attempt to retrieve IP-address via S1 interface, if the LTE492: ANR feature is deactivated, or if the IP-address cannot be found in the PCI/IP address mapping table.

g 6.10.3.9

The operator has not forbidden establishment of the enbControlled X2 link via X2 link blacklisting. The number of X2 links is still smaller than the maxNumX2LinksIn parameter. The maximum number of X2 links which can be established by the eNB is not reached yet.

Note: It is recommended to run whole network or subclusters in common ANR mode (ANR ON or OFF).

Feature activation and interaction with the existing LTE492: ANR feature The LTE782: ANR Fully UE based feature is an optional feature and can be activated and deactivated with the LNBTS parameter actUeBasedAnrIntraFreqLte. The LTE782: ANR Fully UE based and LTE492: ANR features can be activated separately or even in parallel. The neighbor eNBs can be learned concurrently via LTE492: ANR from the PCI/IP address table, or via LTE782: ANR Fully UE based from the eCGI-Report and MME IPaddress resolution. A learned neighbor is equally treated, wether it is learned by LTE492: ANR or LTE782: ANR Fully UE based. If LTE492: ANR and LTE782: ANR Fully UE based are activated together, then the resolution of the IP address via the PCI/IP address table is first selected. If there the PCI is not found, then LTE782: ANR Fully UE based eCGI and/or MME IP address resolution is applied.

6.10.4 System impact Interdependencies between features There are interdependencies between the following features: • •

•

260

LTE724: LTE Automatic Neighbor Cell Configuration LTE492: ANR Support for LTE with OAM Extension T-plane functionality requested by the LTE492: ANR is reused by LTE782: ANR Fully UE based: the eNB is enabled to receive and accept X2 link establishment requests from neighbor eNBs which are not pre-configured via O&M. In addition, the mechanism for detection of unknown PCIs during measurements for handover is reused. LTE42: DRX in RRC Connected Mode

© 2016 Nokia



•

•

•

•

•

•


In order to allow CGI measurements, DRX needs to be set up in the UE. LTE782: ANR Fully UE based exploits the DRX functionalities provided by the LTE42 as needed. LTE473: Extended DRX Settings The LTE782: ANR Fully UE based exploits the extended DRX settings as well as the uplink out of synchronization handling offered by the LTE473 as needed. LTE875: Different IP Addresses for U/C/M/S-Plane The LNADJ object has the parameter C-Plane IP Address Control set to oamControlled. oamControlled means that the eNB automatically establishes and maintains the X2 link with the configured IP address. In this case the behavior is not changed compared to the earlier release. The operator is responsible for the correct IP address. It will not be modified by ANR features. LTE54: Intra-LTE Handover via S1 There is a common instance range for LTE neighbor cells. The range is shared by operator-configured cells and automatically configured cells based on X2- or UEinformation. In total a maximum 384 LNADJL objects may exist per eNB. The S1 handover behavior is improved. When neighbor cells have been learnt via X2 and the corresponding X2 interface drops, then the eNB is still be able to perform S1 handover to these neighbor cells. LTE570: Periodic UE Measurements: This feature is utilized to generate additional UE measurement reports of intrafrequency neighbor cells. Those data are directly generated for the transfer features in context of MDT (mean down time). In addition any new neighbor cell PCI will be resolved very similar as for LTE782: ANR Fully UE Based active ANR mode. It is recommended to run LTE570 only temporarily for the purpose of MDT and not permanently. In order not to generate too much LNADJ/LNADJL, the operator might switch off LTE782: ANR Fully UE based and LTE492: ANR in case of long lasting MDT activations, to keep the impact low to ANR. A possibility is to increase “anrThresRSRPNbCell” to a rather high value to avoid addition of new neighbors, for example "65" = RSRP(neighbor) > -75dBm. LTE468: PCI Management The PCI value of neighbor eNBs that have no X2 connection are updated in case of PCI changes done at NetAct with a configuration plan. LTE539: Central ANR The LTE539: Central ANR feature in auto-configuration configures only the new installed eNB. This eNB will try to establish a X2 link to all the other peers that shall become neighbor eNBs. The operator shall temporary enable the LTE782: ANR Fully UE Based or the LTE492: ANR feature at all neighbor eNBs to let them accept the incoming X2 link. The LTE539: Central ANR feature in auto-configuration can run concurrently with operational eNBs that have the LTE782: ANR Fully UE Based or the LTE492: ANR feature enabled. The LTE539: Central ANR feature, triggered manually for a set of operational eNBs, requires, that those eNBs have feature LTE782: ANR Fully UE based and the LTE492: ANR disabled, as allowing incoming X2 links will end up in a commissioning alarm and the plan file will be abort. The operator shall disable the LTE782: ANR Fully UE based (LNBTS - actUeBasedAnrIntraFreqLte == False) and the LTE492: ANR (LNBTS - anrOmExtEnable == False) manually as NetAct cannot do this automatically.

Impact on interfaces eNB/ MME configuration transfer procedures on S1AP. Impact on network and network element management tools


© 2016 Nokia

261


•

• •

•


Support of the information exchange for neighbor information and NR database between eNB and NetAct. BTSOM (BTS operation and maintenance interface) has sent (via OMS) the CCN notifications to Configurator (NetAct) to update the actual configuration of NI database regarding the created LNADJ, LNADJLs and LNREL objects. Support of ANR configuration parameter exchange. BTSOM has permanently stored content of NI database update notifications The number of LNREL per cell should be kept limited by the operator manually. Too many LNREL do impact the centralized SON functions: LTE468: PCI Management, LTE533: MRO and LTE771: Optimization of Intra-LTE Neighbor Relations optimization as well as the general PM management. The execution time scales partly with the number of LNREL. The number of LNADJ does require X2 management. Too many LNADJ & LNADJL do impact call processing functionality, as execution time scales partly with the number of neighbor cells. The operator can influence the amount of found neighbor cells with the anrThrsRSRPNbCell ANRPRL parameter. The default value 40 (= -100dBm) does ignore PCI values reported with RSRP less than -100dBm as a neighbor. In urban deployments this value is recommended to be increased to 50...60 (= -90..-80dBm). If for an eNB too many LNREL are created, then those can be deleted with the help of NetAct. NetAct supports filter mechanism to list LNREL to a plan and apply delete operation on this list entries, in the manner of a mass configuration. By setting of an higher threshold, less neighbor relations are found. Improving eNB delta plan activation The concurrency of creation/modification/deletion: – –

eNb's ANR functionality triggered object (LNADJ, LNADJL, LNREL) manual operator triggered object via plan file

leads to the collision on operations or on MOC parameters. To handle them, the following mechanisms are implemented: – –

–

The eNB rejects LNADJ/LNADJL/LNREL objects creation/modification/deletion if object with the same objectID is stored in the eNB. The eNB rejects LNADJ object creation/modification/deletion that has the same IP address/ global eNB ID IP/CGI (LCI) as different LNADJ object stored in the eNB. The eNB rejects LNREL object creation/modification/deletion that has the same CGI as different LNREL for for the same LNCEL that is stored in the eNB.

Other objects, for which collision was not detected, are activated. For all rejected objects from delta plan file the eNB provides warning report to the NetAct/BTSSM. The NetAct/BTSSM provides the feedback about the warnings for the user. Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.10.5 LTE782: ANR Fully UE Based management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 157: New alarms lists the alarms introduced with this feature.

262

© 2016 Nokia



Table 157


New alarms

Alarm ID

Alarm name

6265

Maximum number of neighbour eNBs/cells exceeded. This alarm indicates that the maximum number of LNADJ and/or LNADJL was exceeded in eNB and that the new object was not stored. Reported alarm: 7652 BASE STATION NOTIFICATION

7652

Maximum Number of neighbor eNB cell exceeded

7657

Transport Layer Connection Failure

Measurements and counters Table 158: New counters lists the counters introduced with this feature. Table 158

Counter ID

New counters

Counter name

Measurement

8008

ReportCGI (Number of Report CGI Requests)

ReportCGI is used to request the UE to measure and report the Cell Global Identity (CGI) of an unknown cell identified by a PCI at the serving cell carrier frequency

8008

ReportCGI (Number of successful CGI Reports)

Counts the number of ‘reportCGI’ measurement reports received from UE. Trigger: Receipt of ‘reportCGI’ Measurement Report message

8022

LTE X2AP(Number of X2 Setup attempts)

LTE X2AP (M8024) provides measurements related to X2 Setup procedure. The counters are updated at the originating eNB site..

8022

LTE X2AP (Number of failed X2 Setups)

Counts the total number of failed X2 Setup attempts triggered by eNB Trigger: Reception of X2AP: X2 SETUP FAILURE or ‘wait for response’ timeout

8000


Number of attempted X2 IP address retrievals via S1

© 2016 Nokia

Counts the total number of attempts made by eNB to retrieve the X2 IP address of a neighbour eNB via S1

263


Table 158



Counter ID

Counter name

Measurement Trigger: Transmission of S1AP: ENB CONFIGURATION TRANSFER including ‘SON Information Request’ for ‘X2 TNL Configuration Info’

8000

Number of successful X2 IP address retrievals via S1

Counts the total number of X2 IP addresses which are received by eNB via S1 interface Trigger: Reception of S1AP: MME CONFIGURATION TRANSFER including ‘SON Information Reply’ with ‘X2 TNL Configuration Info’

Key performance indicators There are no key performance indicators relevant for this feature. Parameters Table 159: New parameters lists the parameters introduced with this feature. Table 159

New parameters

Full name

264

Abbreviated name

Managed object

C-Plane IP address of the adjacent eNB

cPlaneIpAddr

LNADJ

C-Plane IP address of the adjacent eNB controlled

cPlaneIpAddrCtrl

LNADJ

C-Plane IP Address Control

x2LinkStatus

LNADJ

source of the data

sourceOfData

LNADJL

Global eNB Id X2-link Blacklist

glbNbEnbIdX2LinkBlacklist

ANR

Activate UE-based ANR for IntraFrequency LTE

actUeBasedAnrIntraFreqLte

LNBTS

ANR power level threshold for neighbor cells

anrThresRSRPNbCell

ANRPRL

Neighbor relation limit intra frequency

nrLimitIntraFreq

ANRPRL

Neighbor relation limit inter frequency

nrLimitInterFreq

ANRPRL

© 2016 Nokia



Table 159



Full name

Abbreviated name

Neighbour eNB identifier

g

lnAdjId

Managed object LNADJ

Note: The ANR control parameters are newly modeled, as defined in the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. For more details, see LTE1383: Cell-specific Neighbor Relation/PCI Handling in Automatic Neighbor Relation (ANR).

g

Note: Operator hint The threshold1 LNCEL parameter and the anrThresRSRPNbCell ANRPRL parameter shall be set according to the deployment of the cell. While threshold1 (s-measure) defines the RSRP threshold to start neighbor measurements, anrThresRSRPNbCell gives a minimum power level to trigger the CGI resolution for a new neighbor cell. In rural coverage limited deployments those values are set to lower values, for example 70/40 (threshold1: -70dBm/-100dBm). In urban capacity limited deployments those values are set to higher values, e.g. 90/60 (threshold1: -50dBm/-80dBm). Table 160: Modified parameters lists the parameters modified by this feature. Table 160

Modified parameters

Full name

Abbreviated name

PCI-IP Address Mapping Table

pciIpAdrMap

Managed object ANR

Table 161: Related existing parameters lists the existing parameters related to this feature. Table 161


Full name


Abbreviated name

Managed object

Identity of neighbor eNB

adjEnbId

LNADJ

C-Plane IP Address Control

cPlaneIpAddrCtrl

LNADJ

Neighbour eNB Identifier

InAdjId

LNADJ

Primary PLMN identity of neighbor eNB

plmnId

LNADJ

© 2016 Nokia

265


Table 161


Related existing parameters (Cont.)

Full name

266

Abbreviated name

Managed object

Broadcast PLMN identity list

bcPlmnIdList

LNADJL

Identity of neighbor eNB in ECGI

ecgiAdjEnbId

LNADJL

Identity of cell in ECGI

ecgiLcrId

LNADJL

Primary PLMN identity of neighbor eNB in ECGI

ecgiPlmnId

LNADJL

Downlink EARFCN of FDD cell served by neighbor eNB

fDlEarfcn

LNADJL

Neighbour LTE cell identifier

lnAdjlId

LNADJL

Physical cell ID of Cell served by Neighbor eNB

phyCellId

LNADJL

Tracking Area Code of Cell served by Neighbor eNB

tac

LNADJL

Activate UE-based ANR for IntraFrequency LTE

actUeBasedAnrIntraFreqLte

LNBTS

ANR quality threshold for neighbor cells

anrThresRSRQNbCell

ANRPRL

Global eNB Id X2-link Blacklist

glbEnbIdX2LinkBlacklist

ANR

PCI-IP Address Mapping Table

pciIpAdrMap

ANR

Wait Time for Establishment of eNB Controlled X2 Links

waitTimeEstCtrlX2Lnk

LNBTS

DRX Profile 101

drxProfile101

LNCEL

Identity of eNB in ECGI of related neighbor cell

ecgiAdjEnbId

LNREL

Identity of cell in ECGI of related neighbor cell

ecgiLcrId

LNREL

Primary PLMN ID of eNB in ECGI of related neighbor cell

ecgiPlmnId

LNREL

Naming Attribute of MOC LNREL

InRelId

LNREL

Maximum number of eNB-controlled incoming X2-links

maxNumX2LinksIn

ANR

© 2016 Nokia



Table 161


Related existing parameters (Cont.)

Full name

Abbreviated name

Maximum number of eNB-controlled outgoing X2-links

maxNumX2LinksOut

Managed object ANR


Sales information

BSW/ASW



ASW

SW Asset Monitoring

-

6.11 LTE783: ANR InterRAT UTRAN Introduction to the feature The automatic planning of neighbor relations to UTRAN cells is done on network management system (NMS) level with the help of the NetAct Configurator/Optimizer/cSON. The LTE783: ANR InterRAT UTRAN feature prepares neighbor relations for each LTE cell in the optimization scope and adds UTRAN neighbors automatically, based on current LTE and legacy UTRAN network configuration data; an intelligent algorithm in the Optimizer to used to identify the possible UTRAN neighbor cells. The established relations are updated and synchronized automatically in case of any changes occurring at the UTRAN side (deletion of cell or change of parameters), ensuring up-to-date inter-RAT neighbor relationships. This functionality is a part of auto-configuration process of LTE site. In addition, it is possible to trigger the functionality manually. According to the UTRAN cell configuration, the NetAct creates an eNB plan file that contains an inter-RAT cell configration table. In addition, the dependent inter-RAT SIB, measurement and redirect configuration are aligned. The NetAct supports inter-RAT UTRAN user-templates to control inter-RAT configuration data.

6.11.1 Benefits End-user benefits The UE is not actively involved in finding of neighbor relations. The end-user benefits from LTE783 to have support for idle mode mobility and handover or redirect support from LTE towards UTRAN networks. Operator benefits This feature keeps operator effort low for InterRAT neighborship configuration based on site planning data.


© 2016 Nokia

267




Release


System release

eNode B

MME

SAE GW

UE

NetAct

RL40

-

-

-

-

OSS5.3 CD3


6.11.3 Functional description Functional overview The configuration of inter-RAT neighbor relations is handled by the NetAct/cSON, whereby configuration data relevant for inter-RAT neighbor relations are uploaded and retrieved from any existing UTRAN network configuration management database and corresponding inter-RAT neighbor relations created for the relevant Flexi BTS, taking into account: • •

the geo-location of the source (LTE) and target UTRAN site/cell antenna sectorization/antenna horizontal main lobe direction of source LTE and target UTRAN cells. The algorithm does not consider whether the source and target are colocated.

The relevant parameters for inter-RAT neighbor relation establishment are provisioned by the NetAct/cSON if there is a co-existing Nokia UTRAN network, or by the NetAct northbound interface (Itf-N) as external or foreign cells in case of another Nokia NetAct regional cluster or other vendor's co-existing 3G network. The NetAct operates on the current configured external UTRAN cells for this feature. Between those external UTRAN cells and the LTE cells the neighbor relations are established automatically. Changes that might trigger an update or synchronization of the LTE inter-RAT neigbhor relation configuration are: • • •

UTRAN BTS deletion UTRAN cell deletion UTRAN cell-specific parameter change (for example, scrambling code, RAC, LAC)

The inter-RAT neighbor relation, established before the LTE783: ANR InterRAT UTRAN feature, might be overwritten. The operator can create neighbor relations (LNRELW) up front with a certain black- and white-listing for one or more cell(s). Within a newly generated plan, the operator is informed about each entry: • •

268

selected base on policy values (geo-locations) added because of allowed setting

© 2016 Nokia



•


removed because of forbidden setting

In addition, the final selected maximum number of cells is highlighted. The LTE783: ANR InterRAT UTRAN feature usually lists more inter-RAT cells which can be eventually configured. As a result, the operator can adapt the setting of allowed and forbidden inter-RAT cells (at the break point in confirmed mode); this also offers the possibility to give the chance to adapt persistently the assignment of inter-RAT cells within one eNB in, for example, unbalanced network deployments. As the LTE cells of one eNB share the inter-RAT NR cells only based on geo-location, an urban/rural border situation might assign to the rural cell only few inter-RAT NR cells. It is recommended that the operator triggers manually from time to time the LTE783: ANR InterRAT UTRAN feature for the whole network to ensure the update of each LTE cell and eNB according to the latest NR configuration.

g

Note: As neighbor relations significantly change the call processing and performance behavior and the performance counters, the operator might want to keep the impact low. It is therefore recommended not to start in the first establishment inter-RAT neighbors with the maximum number of neighbor relations, but with a rather low number, and then it is possible to increase this number. The operator can monitor the KPIs, for example, the call drop rate, throughput and handover success rate. If those do not improve significantly, then the actual number of inter-RAT relations, controlled by the network wide policy, is established properly. The external UTRAN cells to be configured in the NetAct area for the managed LTE cells have a different geo-graphical scope. The operator provides the UTRAN cells over-lapping with the LTE cells and in addition a border range around the LTE cell area. In a typical case, the UEs connected to the LTE network should be supported to execute a coverage-based handover to the UTRAN network at the LTE network border. In addition inside the LTE network there can be service-based redirect support. Idle mode mobility support aims more at coverage-based information. There are two use cases to be considered: the establishment of NR for inter-RAT UTRAN and the maintenance of existing neighbor relations. Neighbors finding algorithm The neighbor finding algorithm is based on geo-location information of the eNB/BTS or its cells and the antenna main lobe direction of their cells. The maximum distance value excludes far away cells if there are only few nearby cells and the minimum number of neighbors is not reached. The basic assumption behind the algorithm is that in cellular systems networks are planned in such a way that effort is made to minimize interference between cells on the same frequency layer. In addition, reuse of existing sites with nearby frequency bands results in quite similar cell deployments or LTE and UTRAN networks. In this case, the number of neighbor relation inside each RAT and also their inter-RAT neighbor relations are quite similar. The number of neighbor candidate cells is selected on the basis of site and antenna distance. Overlap of the antenna main lobe is estimated for the selected cells. This considers cells sending from the same site in the same direction as well as cells sending from different sites towards the same area. The distance and the main lobe overlap factor are considered to rank the given cells from the best candidate to worse neighbor candidate. At this point the selection of a suitable minimum number of inter-RAT cell


© 2016 Nokia

269



neighborships is very important. If the number is too low, some suitable inter-RAT neighbors might be not considered. If the number is too high, too many useless interRAT neighbors are considered. Below you can find three cases showing a range of inter-RAT neighbor cells depending on frequency and cell density in networks. Case 1: Rather similar frequency and cell density in both networks. The minimum number of inter-RAT neighbor cells is expected to be in the range from 6 to 12. Case 2: Considerably low frequency and lower cell density in the inter-RAT network, than in the LTE network.The minimum number of inter-RAT neighbor cells is expected to be in the range from 3 to 9. Case 3: Quite a high frequency and higher cell density in the inter-RAT network, than in the LTE network. The minimum number of inter-RAT neighbor cells is expected to be in the range from to 9 to 24. If the operator activates a UE-based ANR algorithm (in later releases) to find additional neighbor cells in the operational network, then the O&M based ANR policy, minimum number of inter-RAT neighbor cells, might be at the lower range to ensure an initial setup; this, however lets the UEs find the next best cells. If the operator needs to assign two inter-RAT bands, for example of UTRAN, as neighbor to the LTE network cells, then the number of minimum inter-RAT neighbors needs to be doubled. Main use cases to be considered: • • •

manual trigger for automatic generation of neighbor relations maintenance of existing neighbor relations auto-configuration triggers for automatic generation of neighbor relations

The operator can still reconfigure manually the UTRAN neighbors parameters at the eNB configuration plan. The operator can set at the NetAct Optimizer/cSON UTRAN neighbors (LNRELW) that are not modified.

6.11.3.1

The establishment of NR for InterRAT UTRAN This procedure describes the establishment of NR for inter-RAT UTRAN. This procedure is triggered by the operator manually, to establish NR for inter-RAT UTRAN, perform the following steps: Preconditions: • • •

UTRAN cell information is available. LTE cells and eNBs exist and are under management of the NetAct. The operator has set the desired NetAct policy values for inter-RAT UTRAN cell selection.

Description: The following steps are supported by the NetAct •

270

The operator selects a set of the eNB or the LTE cells and starts the “ANR for InterRAT UTRAN” algorithm.

© 2016 Nokia



•

• •


The NetAct Optimizer identifies for each LTE cell the most suitable neighbor UTRAN cells under consideration of the operator policy and reports all found NRs. The operator is able to modify the found NR. Based on the information generated by the NetAct Optimizer, the NetAct updates the existing eNB plan file. The NetAct Configurator downloads and activates the delta plan files.

Post conditions: •

6.11.3.2

The LTE cells are configured with neighbor UTRAN cells for handover support and other mobility procedures from LTE to UTRAN via S1 interface and UE idle mode mobility.

Maintenance of existing neighborship relations This procedure describes the maintenance of InterRAT neighborship relations. UTRAN cell and parameter changes of existing LTE to UTRAN neighbor relation are updated in the LTE neighbor configuration data, e.g. UTRAN cell deletion. Preconditions: • • •

InterRAT neighborship relations towards LTE eNB exists BTSs and eNBs are under the same NetAct management scope Changes from other NetAct domains are exchanged

Description: The following steps have to be supported by NetAct •

• •

The NetAct Configurator detects a change of parameter values in the configuration domain for a InterRAT cell object (original or external) issued via target UTRAN cell plan, which has one or more relationships to other LTE cell objects. NetAct Configurator determines the impact of the change, with respect to parameters applicable for LTE InterRAT NR configuration. Based on the updated InterRAT information, NetAct has to update the impacted eNBs plan files. NetAct Configurator generates the delta configuration plan file for the impacted eNBs, downloads and activates the delta plan files.

Post conditions: •

6.11.3.3

The LTE cells keeps an up-to-date configuration parameter set of neighbor InterRAT cells. It is possible to find out which cells need an update from the neighbor relations

New UTRAN neighborship generation during LTE auto-configuration This procedure describes the establishment of NR for inter-RAT UTRAN cells. The operator can run the process autonomously or define the LTE720: SON LTE Auto Configuration feature break point in-line with the LTE720: SON LTE Auto Configuration feature management. The automatic inter-RAT configuration of the eNB is based on the LTE783: ANR InterRAT UTRAN feature for the given cells of the new/planned eNB. Within the auto configuration process the LTE783: ANR InterRAT UTRAN feature does not support a break point itself. Preconditions:


© 2016 Nokia

271



The inter-RAT cell geo-location information is available. The own LTE cells for the new/planned eNB are assigned in the LTE720: SON LTE Auto Configuration process. The operator has set the wanted NetAct policy values for inter-RAT cell selection as preference settings. All features are activated. Description: The following steps are supported by the NetAct: 1. The LTE720: SON LTE Auto Configuration process starts the auto-configuration process, that includes the “ANR for Inter-RAT UTRAN” algorithm. 2. Based on the information generated by the NetAct Optimizer, the NetAct updates the eNB configuration plan. At the LTE720: SON LTE Auto Configuration break point the operator can modify the found NR. 3. The NetAct Configurator completes the configuration plan for the impacted eNBs and, within the LTE720: SON LTE Auto Configuration process, downloads and activates the delta plan file Post conditions: The LTE cells are configured with neighbor inter-RAT UTRAN cells for support of HO and other mobility procedures from LTE to inter-RAT UTRAN via S1 interface and UE idle mode mobility.

6.11.4 System impact There are interdependencies between the following features: • •

•

LTE39: System Information Broadcast: This feature requests SIB broadcast of information to support for LTE and InterRAT neighbors. LTE654: LTE Configuration Management: This feature requests to support the configuration of radio parameter in the eNB from NetAct. The eNBs and NetAct keep a synchronized MIB knowledge base of the LTE network. When the configuration update is required, a reset of the eNB is needed to apply the new configuration. LTE762: Idle Mode Mobility From LTE To WCDMA, GSM or Other LTE Bands: This feature requests SIB broadcast of information to support idle mode mobility for interRAT neighbor cells.

The following features are supported by LTE783: ANR InterRAT UTRAN to obtain configuration data: •

• •

•

•

272

LTE423: RRC Connection Release With Redirect: This feature defines redirect information for RSRP measurements. UE measurement configuration towards WCDMA and GSM (thresholds) should fit to LTE492: ANR/LTE782: ANR - UE based. LTE22: Emergency Call Handling: This feature also uses the fall-back mechanism. LTE56: Inter RAT Handover to WCDMA: This feature requires WCDMA neighbor cell configuration data to initiate WCDMA measurements and the hand over procedure towards WCDMA. LTE562: CSFB to UTRAN or GSM via Redirect: This feature requires WCDMA/GERAN neighbor cell configuration data to initiate WCDMA/GERAN measurements and the CS fallback procedure towards WCDMA/GERAN. LTE898: TDD inter-RAT handover to TD-SCDMA (UTRAN) The feature LTE783 does not support TD-SCDMA and its new MOC LNHOT, LNADJT and LNRELT.

© 2016 Nokia



•

•

•

•


LTE736: CS Fallback to UTRAN (with PS HO) This feature requires WCDMA neighbor cell configuration data to initiate WCDMA measurements and the hand over procedure towards WCDMA as for LTE56. The vendor templates for LNREW support "csfbPsHoAllowed". The operator need to manually configure additional CSFB parameters and to activate the feature. By default the feature is disabled and set to csfbPsHoAllowed = forbidden. LTE872: SRVCC to WCDMA This feature requires WCDMA neighbor cell configuration data to initiate WCDMA measurements and the handover procedure towards WCDMA for voice calls. The vendor templates for LNRELW support srvccAllowed. The operator need to manually activate the feature at LNBTS. LTE1019: SON Reports: This feature defines SON feature labels, that are automatically added as context information for each change done by a SON function in the network configuration. In the CM History tool it is possible to generate SON Reports showing the changes done by LTE783. LTE1045: Full SON Support for Distributed Sites: This feature allows to provide antenna geo-location data for antenna/cell equipment. In case of LTE614: Distributed Sites, the antenna/cell geo-location data are mandatory for the execution of LTE783. If the data are missing in the scope of cells or potential neighbor cells, then the execution of LTE783 is aborted and the operator is informed to correct the geolocation data settings of distributed sites.”


6.11.5 LTE783: ANR InterRAT UTRAN management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters NetAct delivers specific templates for the MOC LNHOW, UFFIM and REDRT (see Table 165: Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendordefined-template ANR inter RAT UTRAN). For LNBTS the operator has to set the activation pattern manual.


© 2016 Nokia

273


g


Note: The basic template mechanism in NetAct support the newly creation of an object instance. For the object classes in scope of the feature LTE783 (LNHOW, UFFIM, REDRT) some parameter are filled from the UTRAN neighbor cell list. All other parameters will be set from the templates. The templates are defined on NetAct level and will be used in each LTE783 work-flow (In RL30 manual triggered). The operator can of course create upfront (before running LTE783 the first time for this cell) those objects (LNHOW, UFFIM, REDRT) manually into the eNB plan file, then the operator settings are not overwritten by the template values. Still the parameter related to the UTRAN neighbor cell list are updated, if LTE783 is executed. Table 164: Modified parameters for MO LNBTS/LNCEL at NetAct: The parameters for MO LNBTS/LNCEL are to be manually configured by operator, or self-prepared user-templates. Table 164

Modified parameters for MO LNBTS/LNCEL at NetAct

Full name

274

Abbreviated name

Managed object

Activate CS fallback via redirection

actCSFBRedir

LNBTS

Enable UE context release with redirect

actRedirect

LNBTS

Activate emergency call via redirection actEmerCallRedir

LNBTS

Activate handover from LTE to WCDMA

actHOtoWcdma

LNBTS

Threshold serving low

threshSrvLow

LNCEL

Threshold th1 for RSRP

threshold1

LNCEL

Threshold th2 interFreq for RSRP

threshold2InterFreq

LNCEL


threshold2a

LNCEL


threshold3

LNCEL


threshold3a

LNCEL


threshold4

LNCEL

Related hysteresis of threshold th2 WCDMA for RSRP

hysThreshold2Wcdma

LNCEL

Threshold th2 WCDMA for RSRP

threshold2Wcdma

LNCEL

Maximum number RRC emergency

maxNumRrcEmergency LNCEL

© 2016 Nokia

Structure



Table 164


Modified parameters for MO LNBTS/LNCEL at NetAct (Cont.)

Full name

g

Abbreviated name

Managed object

Filtering coefficient used for cpich RSCP

filterCoefficientCpichRs LNCEL cp

Filtering coefficient used for cpich ecN0

filterCoefficientCpichEc n0

Time to trigger for A1 to deactivate inter measurement

a1TimeToTriggerDeactI LNCEL nterMeas

Time to trigger for A2 to activate WCDMA measurement

a2TimeToTriggerActWc LNCEL dmaMeas

Timer T304 for interRAT

t304InterRAT

LNCEL

Measurement quantity used for UTRA FDD measurements

measQuantityUtra

LNCEL

WCDMA cell blacklisted or not

cellBlacklisted

LNCEL

Structure

LNCEL

Note: The parameters of the managed objects LNCEL and LNBTS need to be set according to the call processing features: • • • • •

LTE442: Network Assisted Cell Change to GSM LTE53: Intra and inter eNB handover with X2 LTE54: Intra-LTE handover via S1 LTE55: Inter-frequency handover LTE56: LTE Inter RAT handover to WCDMA

to enable “Inter-RAT mobility”. Table 165: Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendor-defined-template ANR inter RAT UTRAN: Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendordefined-template “ANR inter RAT UTRAN” lists parameters modified by this feature. Table 165

Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendor-defined-template “ANR inter RAT UTRAN”

Full name


Abbreviated name

Managed object

UTRA cell reselection timer

tResUtra

UFFIM

Speed-dependent scaling factors treselection UTRAN

tResUtraSF

UFFIM

© 2016 Nokia

Structure

utrResTiFHM

275


Table 165


Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendor-defined-template “ANR inter RAT UTRAN” (Cont.)

Full name

Abbreviated name

Managed object

Structure

utrResTiFMM

276

UTRA Maximum Allowed Transmit Power

pMaxUtra

UFFIM

UTRA Minimum Required Receive Level

qRxLevMinUtra

UFFIM

UTRA Carrier Frequency Absolute Priority

uCelResPrio

UFFIM

UTRA Inter Frequency Threshold High utraFrqThrH

UFFIM

UTRA Inter Frequency Threshold Low

UFFIM

utraFrqThrL

Redirection priority for CS fallback with csFallBPrio redirection

REDRT

Redirection priority for emergency call

emerCallPrio

REDRT

CDMA band

redirBandCdma

REDRT

CDMA frequency

redirFreqCdma

REDRT

eUTRA frequency

redirFreqEutra

REDRT



REDRT


redirGeranBandIndicat or

REDRT

RAT for redirect

redirRat

REDRT

Redirection priority for UE context release

redirectPrio

REDRT

Utran offset frequency

offsetFreqUtra

LNHOW

Related hysteresis thresholds B2Th1, B2Th2 HO WCDMA

hysB2ThresholdUtra

LNHOW

Time to trigger UTRA measurement report

b2TimeToTriggerUtraM eas

LNHOW

Interval for periodical UTRA measurement reporting

reportIntervalUtra

LNHOW

© 2016 Nokia



Table 165


Modified parameters for MO UFFIM, REDRT and LNHOW at NetAct set by vendor-defined-template “ANR inter RAT UTRAN” (Cont.)

Full name

Abbreviated name

Managed object

Threshold1 UTRA for RSRP of serving b2Threshold1Utra cell

LNHOW

Threshold2 UTRA for RSCP neighbour cell

b2Threshold2UtraRscp

LNHOW

Threshold2 UTRA for ecNo neighbour cell

b2Threshold2UtraEcn0

LNHOW

Structure

Table 166: Modified parameters according to the network configuration at UTRAN network lists parameters modified by this feature. Table 166

Modified parameters according to the network configuration at UTRAN network

Full name

Abbreviated name

Managed object

System Information 6 mapping information

si*MappingInfo si*Periodicity si*Repetition

LNCEL, * = (4, ...,8) free position for SIB6


si6MappingInfo

LNCEL

System information * periodicity

si*Periodicity

LNCEL

System information * repetition

si*Repetition

LNCEL

A Downlink Frequency Value

dlCarFrqUtra

UFFIM

UTRA frequency

redirFreqUtra

REDRT

Utran carrier frequency

utraCarrierFreq

LNHOW

Target primary PLMN identity

primaryPlmnId

LNADJW

Structure

mcc mnc mncLength

Target secondary PLMN ID list

secondaryPlmnIdL

LNADJW

mcc mnc


© 2016 Nokia

277



Table 166

Modified parameters according to the network configuration at UTRAN network (Cont.)

Full name

Abbreviated name

Managed object

Structure

mncLength Target location area code

uTargetLac

LNADJW

Target routing area code

uTargetRac

LNADJW

Target RNC id

uTargetRncId

LNADJW

Target cell id

uTargetCid

LNADJW

Target frequency

uTargetFreq

LNADJW

Primary scrambling code (FDD)

uTargetScFdd

LNADJW

Utran adjacent WCDMA cell index

lnAdjWIndex

LNCEL


Sales information

BSW/ASW



ASW

NetAct

-

6.12 LTE784: ANR InterRAT GERAN Introduction to the feature The automatic planning of neighbor relation to GERAN cells is done on network management system (NMS) level with the help of centralized SON (cSON). The LTE784: ANR InterRAT GERAN feature prepares neighbor relations for each LTE cell in the optimization scope and adds GERAN neighbors automatically, based on current LTE and legacy GERAN network configuration data; an intelligent algorithm in cSON is used to identify possible GERAN neighbor cells. The established relations are updated and synchronized automatically in case of changes occurring at the GERAN side (deletion of cell or change of parameters), ensuring up-to-date interRAT neighbor relationships. This functionality is a part of the auto-configuration process of the LTE site. In addition, it is possible to trigger the functionality manually.

278

© 2016 Nokia




According to the GERAN cell configuration, the NetAct creates an eNB plan file that contains an inter-RAT cell configuration table. In addition, the dependent inter-RAT SIB, measurement and redirect configuration are aligned. The NetAct supports inter-RAT GERAN user-templates to control inter-RAT configuration data.

6.12.1 Benefits End user benefits The end user is not actively involved in the finding of neighbor relations. The end user benefits from LTE784 having support for idle mode mobility, eNACC, and redirecting support from LTE towards GERAN networks Operator benefits InterRAT interworking will be available to customers’ network as soon as the LTE eNB is set up and/or the operator manually triggers the function. The established relations are updated/synchronized automatically ensuring up-to-date InterRAT neighbor relationships.

6.12.2 Requirements Software requirements Table 168: Software requirements lists the software required for this feature.

System release

Flexi Multiradio BTS

Flexi Multiradio 10 BTS

OMS

RL40

Table 168

iOMS


UE

NetAct

MME

SAE GW

-

OSS5.3 CD3

-

-


6.12.3 Functional description Functional overview The configuration of inter-RAT neighbor relations is handled by the NetAct/cSON whereby configuration data, relevant for inter-RAT neighbor relations, are uploaded/retrieved from any existing 2G network configuration management database and corresponding inter-RAT neighbor relations are created for the concerned Flexi BTS, taking into account: •


the geo-location of the source (LTE) and target GERAN site/cell antenna

© 2016 Nokia

279


•


sectorization/antenna horizontal main lobe direction of source LTE and target GERAN cells (algorithm does not take into account whether the source and target are co-located)

The relevant parameters for inter-RAT neighbor relation establishment are provisioned by the NetAct in case of a co-existing Nokia 2G network or by the NetAct northbound interface (Itf-N), in case of another Nokia NetAct regional cluster or other vendor's coexisting 2G network. The NetAct operates on the current configured external GERAN cells for this feature. Between those external GERAN cells and the LTE cells the neighbor relations are established by manually triggered the LTE784: InterRAT GERAN feature function. In addition, the NetAct Configurator/cSON updates/synchronizes LTE inter-RAT neighbor relation information automatically. Changes occurring at the GERAN cells, which are relevant for LTE inter-RAT neighbor relations point of view, cause the update of the interRAT neighbor relationships. This is a part of the NetAct Configurator's plan functionality. Changes that might trigger an update of the LTE inter-RAT neighbor relation configuration are: • • •

GERAN BTS deletion GERAN cell deletion GERAN cell-specific parameter change (for example, ARFCN, BSIC, LAC)

Figure 45: LTE784: ANR InterRAT GERAN gives an overview of the feature. Figure 45

LTE784: ANR InterRAT GERAN

NetAct CM

Optimizer

Configurator Filter CM

LTEDomain Manager

CM CM

UTRAN/GERANHRPD DomainManagers NSNLTE

CM

HRPD

GERAN

UTRAN

280

© 2016 Nokia



6.12.3.1


Network policy The LTE442: Network Assisted Cell Change to GSM feature supports network-assisted cell change to EDGE networks. The required signaling of GERAN neighbors cells via SIB towards the UE is supported by the LTE762: Idle Mode Mobility from LTE to WCDMA, GSM or Other LTE Bands feature. This helps UEs to camp on LTE cells to find quickly the most suitable GERAN cells. The UEs connected to a voice or data call to the LTE network can hand over to GERAN/EDGE cells offering the same service. The related objects and parameters can be manually configured by the operator. This is of course the situation, when LTE784: ANR InterRAT GERAN feature is not activated. The LTE784: ANR InterRAT GERAN feature automates the configuration of GERAN neighborship information. An algorithm finds the suitable GERAN neighbor cells for all the given LTE cells, based on their geo-location and their antenna lobe main direction. The LTE cells can have existing GERAN neighborship relations or none. After the execution of the algorithm, the neighborship is updated to the current situation. It is the goal to run this algorithm for a huge number of LTE cells at once. For that reason, the operator can set some policy to influence the configuration, for example to limit the number of GERAN neighbor cells per LTE cell. This will be considered for all LTE cells. In addition, the operator can define allowed and forbidden GERAN cells for each LTE cell. This can consider service capabilities of the GERAN cells. For each automated generation of GERAN neighbor relations these profile settings can be entered. The NetAct/cSON allows a final check on the results of the algorithm, before the new delta configuration is downloaded and activated. The basic case is that one NetAct network area covers the same geographical area with LTE and GERAN cells. Otherwise, the NetAct network area covers only the LTE network and GERAN cells are modeled as external inter-RAT cells. In certain NetAct deployments only parts of the LTE network are covered and even LTE cells are modeled as external LTE cells, but this last case is not relevant for this feature. The external interRAT cells cover an additional border area around the LTE cells according to the range limits given by the radio signal propagation. In general case the NetAct areas are distinct and the NetAct assigned to manage the LTE network area allows configuration, via Itf-N, of the inter-RAT configuration from for example a configuration file. Optionally, the NetAct can identify the changes in the interRAT network with respect to the current inter-RAT configuration, whether the file is yet a delta configuration file. Main use cases to be considered: • • •

manual trigger for automatic generation of neighbor relations maintenance of existing neighbor relations new neighborship generation during LTE auto-configuration

The operator can still reconfigure manually the GERAN neighborship parameters at the eNB configuration plan. Of course the next automated generation rewrites this configuration.The operator can set at the NetAct Optimizer/cSON GERAN neighborships that are not modified.


© 2016 Nokia

281


6.12.3.2


Establishment of NR for Inter-RAT GERAN This procedure describes the establishment of NR for inter-RAT GERAN. The operator starts manually and interactively steps through the process. Preconditions • • •

The GERAN cell information is available. LTE cells and eNBs exist and are under management of the NetAct. The operator has set the wanted NetAct policy values for InterRAT GERAN cell selection.

Description The following steps are supported by the NetAct: • •

• •

The Operator selects or has selected a set of eNB or LTE cells. The Operator starts the "ANR for InterRAT GERAN" algorithm. The NetAct/cSON identifies for each LTE cell the most suitable neighbor GERAN cells under consideration of the operator policy. The NetAct/cSON reports all found NRs and the Operator can still modify the found NR. Based on the information generated by the NetAct/cSON, the NetAct has to update the existing eNB plan file. The NetAct Configurator downloads and activates the delta plan files.

Result The LTE cells will be configured with the neighbor GERAN cells for support of HO and other mobility procedures from LTE to GERAN via S1 interface and the UE idle mode mobility.

6.12.3.3

LTE784: Neighborship Relation Maintenance This procedure describes the maintenance of NR for InterRAT GERAN. This is called "plan preparation for" an intrinsic feature of NetAct Configurator to keep known object relations up-to-date. The feature works in the configuration management domain. Status performance, and fault conditions are not aligned for NRs. If the change has impact on the NR as such, for example deletion of the interRAT cell or re-hosting of the GERAN BTS to other BSC, then the clean-up of the NR is covered by LTE784. Preconditions InterRAT GERAN neighborship relations from LTE eNB exist. BTS-es are under the same NetAct management scope or are modeled as external interRAT objects. Description The following steps are supported by NetAct: 1. The NetAct Configurator detects a change of parameter values in the configuration domain for a interRAT cell object (original or external), which has one or more relationships to other LTE cell objects. 2. Based on the updated interRAT information NetAct has to update the impacted eNBs IRAT neighbor relation parameters. 3. NetAct Configurator has to generate the delta configuration plan file for the impacted eNBs and performs download and activation of the delta plan files

282

© 2016 Nokia




Result The LTE cells will keep an up-to-date configuration parameter set of neighbor GERAN cells. Whether LTE cells need an update of the interRAT NR depends on information held by NR. If it is found that an update is necessary, the LTE cell is updated accordingly.

6.12.3.4

New GERAN neighbor ship generation during LTE auto-configuration This procedure describes the establishment of the NR for inter-RAT GERAN cells. The operator can run the process autonomously or define the LTE720: SON LTE Auto Configuration feature break poit in-line with LTE720: SON LTE Auto Configuration feature management. The automatic inter-RAT configuration of the eNB is based on LTE784: ANR InterRAT GERAN for the given cells of the new/planned eNB. Within the auto configuration process the LTE784: ANR InterRAT GERAN feature does not support a break point itself. Preconditions The inter-RAT cell geo-location information is available. The own LTE cells for the new/planned eNB are assigned in the LTE720: SON LTE Auto Configuration feature process. The operator has set the wanted NetAct policy values for inter-RAT cell selection as preference settings. All features are activated. Description The following steps are supported by NetAct: 1. The LTE720: SON LTE Auto Configuration feature process starts the autoconfiguration process, that includes the “ANR for Inter-RAT GERAN” algorithm. 2. Based on the information generated by the NetAct/cSON, the NetAct updates the eNB configuration plan. At the LTE720: SON LTE Auto Configuration feature break point the operator can modify the found NR. 3. The NetAct Configurator completes the configuration plan for the impacted eNBs and, within the LTE720: SON LTE Auto Configuration process, downloads and activates the delta plan file. Post conditions The LTE cells are configured with the neighbor inter-RAT GERAN cells for support of HO and other mobility procedures from LTE to inter-RAT GERAN via S1 interface and the UE idle mode mobility.

6.12.4 System impact There are interdependencies between the following features: •

•

•


LTE423: RRC connection release with redirect: This feature defines redirecting information for RSRP measurements. UE measurement configuration towards WCDMA and GSM (thresholds) should fit to LTE492/LTE782 REDRT configuration, frequency data. For redirect information the MOC REDRT provides the related GERAN frequencies (ARFCN). LTE22: Emergency call handling This feature is also using the fall-back mechanism. REDRT configuration, frequency data LTE39: System Information Broadcast

© 2016 Nokia

283


•

•

•

•

•

•

•


This feature requests SIB broadcast of information to support for LTE and InterRAT neighbors. The GERAN related SIB information (system information broadcast) need to be configured at each LTE cell at the corresponding MOC LNCEL. The MOC GFIM carries the GERAN idle mode configuration. The optional GERAN neighbor frequency list can be added at MOC GNFL, a child of GFIM. LTE442: Network Assisted Cell Change to GSM (coverage based) This feature requires GERAN neighbor cell configuration data to initiate GERAN measurements and the Network Assisted Cell Change (NACC) procedure towards GERAN for continuity of data services. Optional SIB parameter, UE measurement configuration, cell data, (no DRX). LTE562: CSFB to UTRAN or GSM via redirect This feature requires WCDMA/GERAN neighbor cell configuration data to initiate WCDMA/GERAN measurements and the CS fallback procedure towards WCDMA/GERAN. REDRT configuration, frequency data LTE654: LTE Configuration Management: This feature requests support of the configuration of radio parameter in the eNB from NetAct. The eNBs and NetAct keep a synchronized MIB knowledge base of the LTE network. When the configuration update is required, a reset of the eNB is needed to apply the new configuration. LTE762: Idle Mode Mobility From LTE To WCDMA, GSM or Other LTE Bands: This feature requests SIB broadcast of information to support idle mode mobility for inter- RAT neighbor cells. LTE873: SRVCC to GSM: This feature requires GERAN neighbor cell configuration data to initiate GERAN measurements and the hand over procedure towards GERAN for voice calls. The vendor templates for LNRELG support srvccAllowed. The operator needs to manually activate the feature at LNBTS. LTE1019: SON Reports: This feature defines SON feature labels, that are automatically added as context information for each change done by a SON function in the network configuration. In the CM History tool it is possible to generate SON Reports showing the changes done by LTE784. LTE1045: Full SON Support for Distributed Sites: This feature allows to provide antenna geo-location data for antenna/cell equipment. In case of LTE614: Distributed Sites, the antenna/cell geo-location data are mandatory for the execution of LTE784. If the data are missing in the scope of cells or potential neighbor cells, then the execution of LTE784 is aborted and the operator is informed to correct the geolocation data settings of distributed sites.”


284

© 2016 Nokia




6.12.5 LTE784: ANR InterRAT GERAN management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters NetAct delivers specific templates for the MOC LNHOG, GFIM, GFNL and REDRT (see Table 170: Modified parameters for MO GFIM, GNFL, REDRT and LNHOG at NetAct set by vendor defined-template ANR inter RAT GERAN). For LNBTS the operator has to set the activation pattern manual.

g

Note: The basic template mechanism in NetAct support the newly creation of an object instance. For the object classes in scope of the feature LTE784 (LNHOG, GFIM, GFNL and REDRT) some parameter are filled from the GERAN neighbor cell list. All other parameters will be set from the templates. The templates are defined on NetAct level and will be used in each LTE784 work-flow (In RL30 manual triggered). The operator can of course create upfront (before running LTE784 the first time for this cell) those objects (LNHOG, GFIM, GFNL and REDRT) manually into the eNB plan file, then the operator settings are not overwritten by the template values. Still the parameter related to the GERAN neighbor cell list are updated, if LTE784 is executed. Table 169: Modified parameters for MO LNBTS/LNCEL at NetAct lists parameters modified by this feature. Table 169

Modified parameters for MO LNBTS/LNCEL at NetAct

Full name


Abbreviated name

Managed object


si*MappingInfo si*Periodicity si*Repetition

LNCEL, * = (4, ...,8) free position for SIB7


threshold2a

LNCEL

Threshold Th4 For RSRP

threshold4

LNCEL

Related Hysteresis of Threshold Th2 GERAN For RSRP

hysThreshold2GERAN

LNCEL

threshold2GERAN

threshold2GERAN

LNCEL

© 2016 Nokia

285


Table 169


Modified parameters for MO LNBTS/LNCEL at NetAct (Cont.)

Full name

Abbreviated name

Managed object

maxNumRrcEmergency

maxNumRrcEmergency

LNCEL


a1TimeToTriggerDeactInt erMeas

LNCEL

Time To Trigger For A2 To Activate WCDMA Measurement

a2TimeToTriggerActWcd maMeas

LNCEL

Timer T304 For InterRAT

t304

LNCEL

Filtering Coefficient Used For RSSI

filterCoefficientRSSI

LNCEL

Activate CS Fallback Via Redirection

actCSFBRedir

LNBTS

enable UE context release with redirect

actRedirect

LNBTS

Activate Emergency Call Via Redirection

actEmerCallRedir

LNBTS

Activate eNACC to GSM

acteNACCtoGSM

LNBTS

Table 170: Modified parameters for MO GFIM, GNFL, REDRT and LNHOG at NetAct set by vendor defined-template ANR inter RAT GERAN: Modified parameters for MO GFIM, GNFL, REDRT and LNHOG at NetAct set by vendordefined-template “ANR inter RAT GERAN” lists parameters modified by this feature. Table 170

Modified parameters for MO GFIM, GNFL, REDRT and LNHOG at NetAct set by vendor defined-template “ANR inter RAT GERAN”

Full name

286

Abbreviated name

Managed object

GERAN cell reselection timer

tResGer

GFIM

Speed-dependent scaling factors treselection GERAN

tResGerSF

GFIM

GERAN cell reselection timer factor high mobility

gerResTiFHM

GFIM

GERAN RAT carrier frequency absolute priority

gCelResPrio

GNFL

GERAN inter-frequency threshold high gerFrqThrH

GNFL

GERAN inter-frequency threshold low

GNFL

gerFrqThrL

© 2016 Nokia



Table 170


Modified parameters for MO GFIM, GNFL, REDRT and LNHOG at NetAct set by vendor defined-template “ANR inter RAT GERAN” (Cont.)

Full name


Abbreviated name

Managed object

NCC permitted bitmap

nccperm

GNFL

GERAN maximum allowed transmit power

pMaxGer

GNFL

GERAN minimum required receive level

qRxLevMinGer

GNFL


csFallBPrio

REDRT


emerCallPrio

REDRT

CDMA band

redirBandCdma

REDRT

CDMA frequency

redirFreqCdma

REDRT

eUTRA frequency

redirFreqEutra

REDRT

UTRA frequency

redirFreqUtra

REDRT

RAT for redirect

redirRat

REDRT


redirectPrio

REDRT

Cell Blacklisted

cellBlacklisted

adjGinf

ENACC

eNACC=Supported

adjGinf

Threshold1 GERAN For RSRP Of Serving Cell

b2Threshold1GERAN

LNHOG

Threshold2 GERAN For RSSI neighbour Cell

b2Threshold2RssiGERA N

LNHOG

Time To Trigger GERAN Measurement b2TimeToTriggerGERAN Report Meas

LNHOG

Related Hysteresis of Thresholds B2Th1 and B2Th2 for H

hysB2ThresholdGERAN

LNHOG

NCC Permitted Bit Map

nccperm=0xFF

LNHOG

Interval For Periodical GERAN Measurement Reporting

reportIntervalGERAN

LNHOG

© 2016 Nokia

287



Table 171: Modified parameters according to the network configuration at GERAN network lists parameters modified by this feature. Table 171

Modified parameters according to the network configuration at GERAN network

Full name

288

Abbreviated name

Managed object

GERAN frequency band indicator

bandInd

GNFL

ARFCN value list

gerArfcnVal

GNFL



REDRT



REDRT

ARFCN Frequency Band Indicator

bandIndicatorGERAN

LNHOG

MCC GERAN

mcc

LNADJG

MNC GERAN

mnc

LNADJG

MNC Length GERAN

mncLength

LNADJG

LAC GERAN

gTargetLac

LNADJG

CI GERAN

gTargetCi

LNADJG

ARFCN Value GERAN

arfcnValueGeran

LNADJG

Band Indicator GERAN

bandIndicatorGeran

LNADJG

Basestation Color Code

basestationColourCode

LNADJG

Network Color Code

networkColourCode

LNADJG

Network Control Order

networkControlOrder

LNADJG

System Info List GERAN

systemInfoListGeran

LNADJG

System Information Type

systemInfoType

LNADJG

List of Pointer To LNADJG Instance

adjGinf

LNCEL

© 2016 Nokia





Sales information

BSW/ASW



ASW NetAct

NetAct

-


Abbreviations

Abbreviations

Description

ANR

Automated Neighbor Relation

CGI

Cell Global Identifier

interRAT

Inter Radio Access Technology

PCI

Physical Cell Id

PSC

Primary Scrambling Code

TLA

Transport Layer Address

NbEnb

Neighbor eNB

NbCell

Neighbor Cell

NR

Neighbor Relation

NRT

Neighbor Relation Table

NI

Neighbor Information

RAT


Table 174

Terms

Terms Neighbor Relation (NR)

Description A Neighbor Relation is a relation between a source cell and a target cell. For every cell served by an eNB (say Cell#1), another cell (say Cell#2) is a neighbor relation to Cell#1 if: •


Cell#2 detected by a UE served by Cell#1 with sufficient quality and reported to eNB in a measurement report message

© 2016 Nokia

289



Table 174

Terms (Cont.)

Terms

Description •

The configuration information of Cell#2 is known to eNB.

Neighbor cell Information (NI)

Since the same target cell may be a NR for several eNB cells, the eNB stores the configuration information of target cells in a database with eNB scope, the Neighbor cell Information (NI) database (for example configuration information of a target cell is kept only once per eNB and not per eNB cell).

SC

system component

6.13 LTE882: System Upgrade with Backward Compatibility Introduction to the feature This feature enables the smooth upgrade from major release RL20 to release RL30 in the overall network.

6.13.1 Benefits Operator benefits This feature benefits the operator in smooth remote upgrade path from major release RL20 to release RL30.


Release


System release eNode B

NetAct

MME

SAE GW

RL30

OSS5.3 CD3

-

-

LBTS3.0


6.13.3 Functional description Functional overview

290

© 2016 Nokia




The system upgrade is performed in a top down approach starting with NetAct followed by OMS and followed by an eNB SW upgrade as shown in the Figure 46: Top down upgrade approach. Service outages are minimized by using available resiliency features and hardware redundancy as far as possible. It is not possible to take the whole system out of service to introduce the new SW release. As a consequence of this approach, NetAct supports at least two OMS releases and two BTS releases (RL30, RL20). OMS of SW release RL30 supports two eNB releases (RL30, RL20). Also mixed eNB and OMS configurations are supported by OMS and NetAct. Figure 46

Top down upgrade approach Step1 NetAct releasen

topdown

Step2 OMS(1) releasen

OMS(2) releasen-1

Step3 BTS(1) releasen

BTS(2) releasen-1

BTS(3) releasen-1

BTS(4) releasen-1

Upgrade path •

• •

NetAct upgrade OSS5.3 CD1 -> OSS5.3 CD3 OSS5.3 CD2 -> OSS5.3 CD3 Those two upgrade paths are not the only supported paths. For more information on NetAct upgrade see Description of the Commissioning and Upgrade Procedure, available in NOLS at the following path: Product Information -> Product Finder -> Operations Support Systems -> Network and Service Management -> NetAct -> Documentation -> NetAct, Rel. OSS5.3 CD Set 1, Operating Documentation, issue 01 OMS upgrade LTE OMS 2.0 -> LTE OMS 3.0 eNB upgrade SW upgrade RL20 -> RL30

The following functionality is supported with the upgrade from RL20 to RL30: 1. The upgrade from release RL20 to release RL30 is possible in one step. No intermediate SW versions are necessary to be installed. 2. All operator configured data are maintained in the system. Configuration data are converted into a new format.This implies that the data from the previous release can be reused after the upgrade. No manual intervention is required. This data includes:


© 2016 Nokia

291


• •


all configuration data of the Flexi Multiradio BTS adaptations done by operator for different (graphical) presentations in BTS SM or NetAct (for example top level user interface: topology view)

The BTS data migration is performed automatically by the BTS during the startup phase of the new SW. The migration operation includes: • • •

copying configuration data from release RL20 checking data compatibility preparing data for the new SW release, like conversion of parameters to the new format and/or provision of defaults for parameters or parameter value where necessary

The data migration includes all configurable data like BTS, TRS and RNW configuration files. OMS is required to provide conversion for internal OMS configuration data like LDAP parameters (including user accounts) and autoconnection data. No conversion for topology and alarms is needed, because this data are regained from eNB after restart. 3. System data are stored before system upgrade. The data are available after upgrade. This data includes: • •

user security, for example user accounts/passwords, log files network security, for example certificates, keys

No manual activities to reconfigure or reload system related data are necessary. 4. BTS SM is prepared to handle both NE releases, at least as co-existing versions of BTS SM with release RL30. 5. The downtime of a network entity during the system upgrade is reduced to the activation of the new software. The switch to the new release (activation of the software) is performed on operator request from NetAct or BTS SM. 6. In case of an upgrade failure an automatic fallback to the original release takes place. The automatic fallback avoids a situation where an NE is completely out of service and service personnel is needed on site for repair action. Triggers for fallback from new SW to the previous can be: • •

NE detects any critical error condition (especially critical exceptions while data conversion) NE does not restart with the new SW version

In addition the fallback can be initiated on operator command from NetAct or BTS SM. Backward compatibility Backwards compatibility of management system includes plan validation. Upgrade of all BTSs of a network usually is not done in parallel but takes longer time frame (even weeks). During this period NetAct must be able to manage network elements of RL30 and RL20 releases in parallel. This includes release specific validation of corresponding plan files before download. This needs at least installation of the BTS Site manager validation tools for the relevant BTS releases.

292

© 2016 Nokia




Upgrade of the eNBs is not done in parallel for all nodes also. Because of that network elements are backward comatible with each other during upgrade. The eNBs keeps their capability to communicate to other node elements (also to not yet upgraded ones) via X2 interface. During upgrade no data (symptom, trace or log data) are lost. All data remains available in NE in the new SW release. Also after fallback all data remains available for error analysis. BTS behavior in exception cases: • •

•

• •

BTS performs automatic fallback to former (working) SW build in case of critical errors detected in SW upgrade In case when restart with new SW build release is not successful, the BTS logs the error and automatically falls back to former RL20 SW build as stored in non volatile memory. The restarted fallback SW also loads the compatible RL20 fallback configuration. In case when configuration data conversion is not successful, the BTS logs the error and, when the conversion exception is critical, automatically falls back to former RL20 SW build. In case of automatic fallback the BTS set an alarm (see LTE882: System Upgrade with Backward Compatibility management data) After fallback the user can upload the log file, check the symptoms to get detailed information about the exception and restart upgrade with corrected SW load and/or data conversion routines.

OMS behavior in exception cases: • • • •

OMS supports fallback to previous SW version or former configuration data in case of critical SW upgrade exceptions OMS supports the automatic resiliency feature during the upgrade process No symptom, trace, log data are lost due to SW upgrade or due to SW fallback. All data are stored reset safe. OMS provides the compatibility of all parameters in case of data conversion during the upgrade or fallback.

6.13.4 System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools The impacted NEs are the Flexi Multiradio BTS, NetAct with all LTE relevant applications including Optimizer, Trace Viewer, the Northbound interfaces and the OMS. Impact on system performance and capacity This feature has no impact on system performance or capacity.


© 2016 Nokia

293



6.13.5 LTE882: System Upgrade with Backward Compatibility management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms lists existing alarms related to this feature. Table 176

Related existing alarms

Alarm ID

Alarm name

7651

BASE STATION OPERATION DEGRADED

Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


294

Sales information

BSW/ASW



BSW

-

-

© 2016 Nokia



Descriptions of BTS site solution features

7 Descriptions of BTS site solution features 7.1 LTE74: Flexi System Module FSMD Introduction to the feature Flexi BTS Multimode System Module FSMD provides common and baseband processing functions for the BTS site. It supports typical 3-sector configuration up to 10 MHz cell bandwidth or for example two LTE cells with up to 20 MHz bandwidth.

7.1.1 Benefits Operator benefits Flexi BTS Multimode System Module FSMD provides the following operator benefits: • •

• •

One SW configurable Flexi System Module for LTE and WCDMA/HSPA/HSPA+. All BTS site common functions, baseband processing, transport options, power distribution with fuses and fans integrated in one single, compact, IP65 weather proof 3U module. Operates at ambient temperature from -35 to +55 C. There is no need of having cabinet. It can be installed on wall or pole or existing 3rd party BTS or Site Support cabinet.

7.1.2 Requirements Software requirements lists software required for this feature. Table 178

Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-

7.1.3 Functional description Functional overview One system module supports six cells up to 10 MHz bandwidth (with 1TX or with 2TX MIMO). This feature provides the following functionalities: • • • • • •


BTS and site level O&M processing LTE eNB telecom and RRM functionality LTE baseband processing with two integrated baseband units transport interface with transport Sub-module external alarms and controls (EACs) timing and synchronization

© 2016 Nokia

295


• • • • • •


Ethernet Switch with 1G and 100 M Ethernet interfaces site 48 V DC input power interface and 48 V DC distribution to other modules with fuses five optical interfaces, to connect Radio Modules and second System Module in extension mode IP65 mechanics with -35...+55 C ambient temperature OBSAI RP3 summing/distribution function two redundant fans

7.1.4 System impacts Interdependencies between features This feature has no related or interworking features. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.1.5 LTE74: Flexi System Module FSMD management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

7.1.6 Sales information This module has same power and Multicarrier licenses as other earlier modules. It requires Branch license.

296

© 2016 Nokia




Table 179

Sales information

BSW/ASW



BSW

—

—

7.2 LTE89: Flexi RRH 2TX 2600 Introduction to the feature This feature defines new Remote Radio Head (RRH) variant to the LTE usage. The RRH is a multistandard radio head with OBSAI interface which is able to support WCDMA/HSPA and LTE applications processing at 2600 MHz 3GPP band 7.

7.2.1 Benefits WCDMA and LTE capable Flexi Multiradio RRH is optimized for single sector deployment and offers unique site evolution to MIMO and RRH Chaining with SW upgrade only. Operator benefits Flexi RRH 2TX 2600 (FRHB) provides the following benefits: • • • • • •

High output power (40W + 40 W) with low dimensions and low power consumption Support of RAN sharing, large bandwidth Backward compatibility, smooth evolution towards higher output power Mounting scenarios: wall, pole, mast, on the ground Conventional (passive) cooling with no fans Low weight and fast deployment option

7.2.2 Requirements Software requirements Table 180: Software requirements lists software required for this feature. Table 180

Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-

Hardware requirements • •


Flexi BTS Multimode System Module (FSMD, FSME) The RRH operates on DC voltage. If only an AC supply is available, an external AC/DC converter kit is required.

© 2016 Nokia

297



7.2.3 Functional description Functional overview Flexi Multiradio RRH 2TX 2600 offers 40W + 40W outputs that are operated by two parallel Multi Carrier Power Amplifiers (MCPA). Each MCPA supports WCDMA and LTE in dedicated or concurrent mode. Figure 47

298

Isometric view of FRHB Remote Radio Head 2600

© 2016 Nokia



Figure 48


Interfaces of FRHB Remote Radio Head 2600

LTE89: Flexi RRH 2TX 2600 provides following features: •

• • • • • • • • • • • • •

Operating frequency: 3GPP Band III –

UL: 2500 - 2570 MHz

–

DL: 2620 - 2690 MHz

40 W + 40 W with two power amplifiers (at 45 C) Optimized for single sector deployment with 2TX MIMO One LTE cell with 2TX MIMO up to 20 MHz LTE per sector. . Integrated OVP HW support for optical chaining (two optical connectors) Two external RX outputs, that is main and diversity with small SMA connectors for future use (for example for location device). External alarms and outputs AISG2.0 Antenna tilt support with external connector (RS485) MHA supported by both RX branches with adjustable LNAs (0 - 30 dB) Other TX/RX branch with integrated BiasT supports AISG2.0 MHA. Alternatively antenna tilt support will be available in the future by the same HW. VSWR monitoring on both TX branches Ingress protection: IP65 Temperature range: -35°C...+55°C

7.2.4 System impacts Interdependencies between features This feature has no related or interworking features. Impacts on interfaces This feature has no impact on interfaces.


© 2016 Nokia

299



Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.2.5 LTE89: Flexi RRH 2TX 2600 management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

7.2.6 Sales information This module has same power and Multicarrier licenses as other earlier modules. It requires Branch license. Table 181

Sales information

BSW/ASW



BSW

—

—

7.3 LTE91: Flexi RRH 2TX 850 Introduction to the feature This feature defines new Remote Radio Head (RRH) variant to the LTE usage. The RRH is a multistandard radio head with OBSAI interface which is able to support WCDMA/HSPA and LTE applications processing at 850 MHz 3GPP band 5.

7.3.1 Benefits WCDMA and LTE capable Flexi Multiradio RRH is optimized for single sector deployment and offers unique site evolution to MIMO and RRH Chaining with SW upgrade only. Operator benefits

300

© 2016 Nokia




Flexi RRH 2TX 850 (FHCA) provides the following benefits: • • • • • •



Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-



7.3.3 Functional description Functional overview Flexi Multiradio RRH 2TX 850 offers 40W + 40W outputs that are operated by two parallel Multi Carrier Power Amplifiers (MCPA). Each MCPA supports WCDMA and LTE in dedicated or concurrent mode. The following figure illustrates the isometric view of the FHCA.


© 2016 Nokia

301


Figure 49


Isometric view of the FHCA


• • • • • • • • •

302

Operating frequency: 3GPP Band 5: –

UL: 824 - 849 MHz

–

DL: 869 - 894 MHz

40 W + 40 W with two power amplifiers (at 45 OC) Optimized for single sector deployment with 2TX MIMO One LTE cell with 2TX MIMO up to 20 MHz LTE per sector Integrated OVP HW support for optical chaining (two optical connectors) Two external RX outputs, that is main and diversity with small SMA connectors for future use (for example for location device). External alarms and outputs AISG2.0 Antenna tilt support with external connector (RS485) MHA supported by both RX branches with adjustable LNAs (0 - 30 dB)

© 2016 Nokia



• • • •


Other TX/RX branch with integrated BiasT supports AISG2.0 MHA. Alternatively antenna tilt support will be available in the future by the same HW. VSWR monitoring on both TX branches Ingress protection: IP65 Temperature range: -35°C...+55°C





Sales information

BSW/ASW

RAS SW component License control in network element


BSW

RAN

—

© 2016 Nokia

—

303



7.4 LTE106: 6 Cells support with one System Module Introduction to the feature Six sector and six LTE cells with optional 2TX MIMO Flexi LTE BTS configuration is supported.

7.4.1 Benefits Operator benefits More coverage and capacity with six sector and cell configuration.


Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-

Hardware requirements •

Flexi BTS Multimode System Module FSME

7.4.3 Functional description Functional overview Flexi Multiradio System Module FSME supports up to six cells with 10 MHz bandwidth (with 1TX or with 2TX MIMO). This feature provides configurations: • • • •

up to 1+1+1+1+1+1 1TX/2RX with two 3-sector RF Modules, up to 1+1+1+1+1+1 2TX/2RX with four 3-sector RF Modules, up to 1+1+1+1 2TX/2RX with four 3-sector RF Modules configured to support one sector (2TX config max 60 + 60 W per sector), up to 1+1+1+1 2TX/2RX with four RRHs (2TX MIMO max 40 + 40 W per sector)

7.4.4 System impacts Interdependencies between features Not supported at the same time with LTE447: RF sharing LTE-GSM. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools

304

© 2016 Nokia




This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.4.5 LTE106: 6 Cells support with one System Module management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


Sales information

BSW/ASW



BSW

—

—

7.5 LTE452: Flexi RRH 2TX 2100 Introduction to the feature This feature defines new Remote Radio Head (RRH) variant to the LTE usage. The RRH is a multistandard radio head with OBSAI interface which is able to support WCDMA/HSPA and LTE applications processing at 2100 MHz 3GPP band I.

7.5.1 Benefits WCDMA and LTE capable Flexi Multiradio RRH is optimized for single sector deployment and offers unique site evolution to MIMO and RRH Chaining with SW upgrade only.


© 2016 Nokia

305



Operator benefits Flexi RRH 2TX 2100 (FRGQ) provides the following benefits: • • • • • •



Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-



7.5.3 Functional description Functional overview Flexi Multiradio RRH 2TX 2100 offers 40W + 40W outputs that are operated by two parallel Multi Carrier Power Amplifiers (MCPA). Each MCPA supports WCDMA and LTE in dedicated or concurrent mode.

306

© 2016 Nokia



Figure 50


Isometric view of the Remote Radio Head (FRGQ)


• • • • • • • • • • • •


Operating frequency: 3GPP Band I –

UL: 1920 - 1980 MHz

–

DL: 2110 - 2170 MHz

40 W + 40 W with two power amplifiers (at 45°C) Optimized for single sector deployment with 2TX MIMO One LTE cell with 2TX MIMO up to 20 MHz LTE per sector. . Integrated OVP HW support for optical chaining (two optical connectors) Two external RX outputs, that is main and diversity with small SMA connectors for future use (for example for location device). External alarms and outputs AISG2.0 Antenna tilt support with external connector (RS485) MHA supported by both RX branches with adjustable LNAs (0 - 30 dB) Other TX/RX branch with integrated BiasT supports AISG2.0 MHA. Alternatively antenna tilt support will be available in the future by the same HW. VSWR monitoring on both TX branches Ingress protection: IP65

© 2016 Nokia

307


•


Temperature range: -35°C...+55°C




Sales information

BSW/ASW



BSW

—

—

7.6 LTE614: Distributed Site Introduction to the feature

308

© 2016 Nokia




The Distributed Site Solution is a LTE BTS site where the distance between the System Module and RF Module or RRH can be up to 23 km. The single mode optical cables and single mode optical transceivers (SFP) need to be used to connect System Module to RF Module or RRH.

7.6.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The operator is able to utilise new site solutions by using long optical cables between the Flexi RF and System Module. Distributed Site is especially suitable for example for roadside applications. BTS System Modules and high capacity backhaul transport can be collected to one BTS hotel-type of centralized secured location with shared BTS site support functions like battery back up (for System Modules and transport).

7.6.2 Requirements Software requirements Table 188


System release

eNodeB

Release

MME

SAE GW

UE

NetAct

-

-

-

OSS5.3 CD3

Hardware requirements This feature requires the following hardware: • •

Flexi Multiradio BTS LTE System Module Flexi Multiradio BTS RF Module or Remote Radio Head

7.6.3 Functional description Functional overview Flexi System Module can be located (by an optical single mode interface and single mode SFPs) up to 23 km away from the RF Module or RRH, typically closer to the transmission termination point and other site support equipment (e.g. existing BTS shelter or inside BTS or Site Support cabinet) and to the location with easier access for the operator. Single Mode optical pluggable transceivers (SFP) can be installed to standard Flexi System Module and RF Modules and RRH to support max 23 km optical single mode fiber. Flexi RF Module or RRH is located close to antenna to support typically one sector with 2TX MIMO. RF Module and RRH needs local 48 V power supply and optional battery back-up solution.


© 2016 Nokia

309



Maximum output power is 60 + 60 W per sector with 2TX MIMO with RF Module. Maximum output power is 40 + 40 W per sector with RH 2TX MIMO with RRH.

g

Note: Note: In some cases of optical link length changes, BasebandbusFailure (1811) alarm is raised. This may happen due to redundancy switch-over in active optical networks (for example, a ring switch in a DWDM path) when the fiber lengths are not symmetrical. In such cases a manual eNB reset is required.

7.6.4 System impacts Interdependencies between features Following features will not work correctly together with distributed site: • • •

LTE468 PCI management LTE539 Central ANR LTE492 ANR

If the features are applied, then the prepared values for an eNB in distributed site configuration need to be re-worked manually. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.6.5 LTE614: Distributed Site management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.

7.6.6 Sales information This module has same power and Multicarrier licenses as other earlier modules. It requires Branch license.

310

© 2016 Nokia



Table 189


Sales information

BSW/ASW ASW

License control in network element -

License control attributes -

7.7 LTE921: Flexi 3-sector RF Module 760 Introduction to the feature New Flexi Multiradio RF Module provides new RF capabilities in the 700 MHz upper 3GPP band 14 supporting three sectors with 40W power at the BTS antenna connector.

7.7.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits 3-sector Flexi Multiradio RF Module 760 (FRBB) provides the following benefits: • • • • • • • • • • • •

the most cost, size, and weight optimized three-sector BTS site, easier installation,less visual impact industry-leading RF integration level the widest ambient temperature range: -35... +55 C the smallest power consumption and OPEX 3 sector RF Module in one outdoor IP65 protected box less wind load can be used as feederless site as well with one DC and one or two optical cables TX diversity and MIMO 2TX can be build using two 3-sector RF Modules RF redundancy option comes as additional advantage in feederless installations one 3-sector RF Module is more cost effective than three Remote Radio Heads (RRHs) typically only one third of DC and optical cabling required compared to the Remote Radio Heads can be used as powerfull one sector RRH : 40 + 40 W 2TX MIMO with HW prepared for 4RX

7.7.2 Requirements Software requirements lists software required for this feature.


© 2016 Nokia

311


Table 190

Release



System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-


Flexi WCDMA BTS Multimode System Module FSMD or FSME

7.7.3 Functional description Functional overview Flexi Multiradio RF Module HW supports LTE at the 3GPP Band 14 excluding 10 MHz band (5 MHz D-block and 5 MHz Public Safety block). Flexi Multiradio RF Module FRBB supports the following LTE configurations: • • • • •

1, 1+1 or 1+1+1 at maximum 10 MHz LTE bandwith and 1TX/2RX 1+1 or 1+1+1 LTE at maximum 10 MHz LTE bandwith and 2TX MIMO/2RX with Two RF Modules 8, 20 or 40 W mode per sector (controlled by SW licenses) 1 sector with maximum 40 + 40 W 2TX/2RX MIMO HW ready for 1 sector max 40 + 40 W 2TX/4RX MIMO

Flexi Multiradio RF Module FRBB can be used in Feederless (DC up to 200 m) and Distributed BTS sites.

7.7.4 System impacts Interdependencies between features There are no interdependencies between this and any other feature. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.7.5 LTE921: Flexi 3-sector RF Module 760 management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms

312

© 2016 Nokia




There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


Sales information

BSW/ASW BSW

License control in network element —

License control attributes —

7.8 LTE977: RF Chaining Introduction to the feature This feature provides the possibility of chaining of Flexi Multiradio RF Modules and Remote Radio Heads. In the distributed sites this feature allows to extend and optimize the coverage and capacity. In the feederless sites the length of fiber can be reduced to minimum.

7.8.1 Benefits Operator benefits This feature benefits operator as follows: • • •

more options for site design larger configurations to be built with single logical Flexi Multiradio BTS especially in multi-band cases chain configuration provides better solution for example for railway, highway or indoor coverage than traditional star configuration

7.8.2 Requirements Software requirements lists software required for this feature.


© 2016 Nokia

313


Table 192

Release



System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-

Hardware requirements This feature requires: •

Flexi BTS Multimode System Module FSME

In addition, the following RF modules support chaining: FRGF, FRGP, FRIE, FXEA, FXFA, FXCA, FRGQ, FHEA.

7.8.3 Functional description Functional overview Functional overview One Flexi Multiradio BTS System Module (FSME) supports up to six maximum 10 MHz LTE cells. One 3 Gbit/s optical link supports maximum two 10 MHz cells with 2TX MIMO and 2RX diversity. Therefore the maximum three 3 Gbit/s optical chains are supported with one System Module (FSME) are. Each chain with two RF Module or RRH with maximum 10 MHz bandwidth of LTE cell each. RRH or RF Module must support one cell/sector with 2TX MIMO & 2RX diversity. In feederless BTS site configuration maximum 200 m distance between System Module and two RF units in one chain supporting two different RF bands (Dual band site). In distributed BTS maximum 20 km distance between System Module and the last RRH/RFM in the chain. . RF chaining with new Multiradio System 10: Same RF chaining topologies as provided for FSME will be supported with FSMF as well. Maximum fibre length to last radio unit in chain is defined by LTE614 distributed site. .

7.8.4 System impacts Interdependencies between features This feature has no related or interworking features. Not supported at the same time with LTE447: RF sharing LTE-GSM. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity This feature has no impact on system performance and capacity.

314

© 2016 Nokia




7.8.5 LTE977: RF Chaining management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


Sales information

BSW/ASW ASW

License control in network element SW Asset Monitoring

License control attributes -

7.9 LTE1101: FFCB TRS External Filter for FHCA Introduction to the feature This feature defines the external filter FFCB that is used together with FHCA.

7.9.1 Benefits Operator benefits The FFCB allows to fulfill demanding cositing requirements on local Korean radio systems.

7.9.2 Requirements Software requirements Table lists software required for this feature. Table 194



System release

eNode B

NetAct

MME

SAE GW

RL30

LN3.0

-

-

-

© 2016 Nokia

315




Flexi BTS Multimode System Module (FSMD, FSME) Flexi Multiradio BTS RRH FHCA

7.9.3 Functional description Functional overview LTE1101: FFCB TRS External Filter for FHCA provides following features: • • • • • •

Four 7/16 antenna connectors (one pair towards the system module and one towards RRH) Two output ports (SMA, female) for power monitoring Dimensions are 482mm x 260mm x 121mm (length, widht, depth) without connectors and mounting brackets Weight less than 10kg Operating temperature range: -40°C...+55°C Ingress protection: IP65

Figure 51

Front view of the FFCB

7.9.4 System impacts Interdependencies between features

316

© 2016 Nokia




This feature has no related or interworking features. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.9.5 LTE1101: FFCB TRS External Filter for FHCA management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters There are no parameters related to this feature.


Sales information

BSW/ASW



BSW

—

—

7.10 LTE1106: Flexi low power RRH 850 2TX for optical repeater interface Introduction to the feature This feature defines new Remote Radio Head (RRH) variant for the LTE usage. It provides low power variant RRH with 2 TX for optical repeater interface.

7.10.1 Benefits Operator benefits


© 2016 Nokia

317



Flexi RRH 850 2TX (FHCA) provides the following benefits: • • • •

Indoor low power RRH optical repeater interface enables building LTE coverage using repeater solutions. Mounting scenarios: wall, pole, mast, on the ground Conventional (passive) cooling with no fans Low weight and fast deployment option



System release

eNode B

NetAct

MME

SAE GW

RL30

LN3.0

-

-

-

Hardware requirements •

Flexi BTS Multimode System Module (FSMD, FSME)

7.10.3 Functional description Functional overview LTE1106 provides the following features: • • •

10mW + 10mW with two power amplifiers (2TX/2RX) one LTE omni cell up to 10 MHz Antenna port: – –

•

Sample port: – – – –

•

–

•

318

Tx output level: -10~10dBm/10MHz (20dB Dynamic Range)

Rx characteristics: –

•

Number of Port: 2 Tx, 2 Rx (simplex) Connector Type: SMA Tx : 10~30dB Rx : within 10dB (LNA output signal)

Tx characteristics: –

•

Number of Port: 2 Tx, 2 Rx (simplex) Connector Type: SMA

Sensitivity : -76.5 dBm (considering 25dB gain of optic repeater) Dynamic Range : -20 ~ -76.5dBm

External alarms and outputs VSWR monitoring on both TX branches

© 2016 Nokia





7.10.5 LTE1106: Flexi low power RRH 850 2TX for optical repeater interface management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 197

Existing parameters related to LTE1106

Full name

Abbreviated name

Managed object

Parent structure

Enable graceful cell shutdown

enableGrflShdn

MRBTS/LNBTS

-

Cell power reduce

dlCellPwrRed

MRBTS/LNBTS/LNCE L

-

Maximum output power

pMax

MRBTS/LNBTS/LNCE L

-



Sales information

BSW/ASW



BSW

—

—

© 2016 Nokia

319



7.11 LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU) Introduction to the feature FHCC Flexi 850 Repeater Interface Unit (RIU) is optical mux & demux unit with RF interfaces. It is located between Flexi System Module and Flexi RF Modules and customer's (existing) 3rd party RF repeater system. On radio interface side one RIU is able to support up to three RF repeaters (cells or sectors) with three analog RF interfrequency interfaces. On optical interface side one RIM is able to support up to three LTE cells (sectors) with two optical interfaces towards Flexi RF Modules. Optical interface has delay functionality with settable 0 - 100 microsecond delay to adjust the RF Module and RF repeater delay the same in downlink and uplink.

7.11.1 Benefits Operator benefits RIU is customized market and customer specific product enabling operator to use their existing RF repeaters and analog-digital RF distribution system with new LTE BTS and LTE RF units.



System release

eNode B

NetAct

MME

SAE GW

RL30

LN3.0

-

-

-

7.11.3 Functional description Functional overview On radio interface side one RIU is able to support up to three RF repeaters (cells or sectors) with three analog interfrequency RF signal interfaces. RIU performs optical to IF radio conversion. 2TX MIMO is supported with each interface. On optical interface side one RIU is able to support up to three LTE cells (sectors) with two optical interfaces towards Flexi RF Modules. Optical interface has delay functionality with settable 0 - 100 microsecond delay to adjust the RF Module and RF repeater delay the same in downlink and uplink. 2TX MIMO is supported for each cell. Optical Mux/demux - OBSAI signal splitting (same cell to Radio Unit and Repater) in downlink in Coupling Mode

320

© 2016 Nokia




- OBSAI signal summing (same cell from Radio Unit and Repeater) in uplink in Coupling Mode - OBSAI signal handling in downlink and uplink in Dedicated Mode (Radio Unit and Repeater have theit own cells) Optical Delay functionality adds required delay towards the Flexi Radio Units uplink and downlink signals, tuning range 0 to 100 us. Purpose is to make exactly the same delay from the System Module to the antenna connectors of the Flexi Radio unit and 3rd party Repeater. Distance requirement is 20 km in case of delay compensation is 0 ms.


7.11.5 LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU) management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 200


Full name


Abbreviated name

Managed object

Parent structure

Antenna line id

antlId

LCELL

Resource list (resourceList)

Sub cell identifier

subCellId

LCELL


© 2016 Nokia

321


Table 200


Existing parameters related to LTE1195 (Cont.)

Full name

Abbreviated name

Managed object

Parent structure

TX and RX usage

txRxUsage

LCELL


Radio module reference id

rModId

MRBTS/ANTL

-

Unique sector electronics ID

useId

MRBTS/LNBTS/LNC EL

-

Scanned antenna interface

scannedAntennaI nterface

MRBTS/MHA

-

Scanned antenna interface

scannedAntennaI nterface

MRBTS/RET

-

Radio module reference id

rModId

MRBTS/RMOD

-

Table 201

New parameters introduced by LTE1195

Full name

Abbreviated name

Unique sector electronics ID

useId

Managed object MRBTS/LNBTS/LNCE L

Parent structure -


Sales information

BSW/ASW



BSW

—

—

7.12 LTE1337: FHEC Flexi RRH 2TX 1800 low power Introduction to the feature FHEC is the Flexi RRH 2TX 1800 MHz low power for optical repeater interface for 3GPP band 3.

7.12.1 Benefits Operator benefits Indoor low power RRH optical repeater interface enables building LTE indoor and outdoor coverage using repeater solutions.

7.12.2 Requirements Software requirements Table lists software required for this feature.

322

© 2016 Nokia



Table 203



System release

eNode B

NetAct

MME

SAE GW

RL30

LN3.0

-

-

-

7.12.3 Functional description Functional overview FHEC Flexi RRH 2TX 1800 low power repeater interface provides the following features: • • • • • • •

frequency band in LTE is 1840 MHz – 1850 MHz on downlink and 1745MHz –1755MHz on uplink output port: each 2 ports per downlink and uplink, SMA type signal monitoring port: one per DL and UL, SMA type, 10 dB coupling dedicated for one sector (one cell) configuration reference signal: 10MHz, 4 ports input power is -48VDC only optic Interface is OBSAI RP3-1


7.12.5 LTE1337: FHEC Flexi RRH 2TX 1800 low power management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature.


© 2016 Nokia

323



Parameters Table 204


Full name

Abbreviated name

Maximum output power

pMax

Managed object MRBTS/LNBTS/LNCE L

Parent structure -


Sales information

BSW/ASW



BSW

—

—

7.13 LTE1356: Flexi RF Module 2TX 850 (FXCC) Introduction to the feature This feature introduces Flexi Multiradio RF Module version for 850 MHz supporting two sectors with 60 W output power at the BTS antenna connector. It can be used as one sector powerfull RRH with 60 W + 60 W 2TX MIMO. The environmental protection class is IP65.

7.13.1 Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits FXCC Flexi 2-sector RF Module 60 W 850 MHz has 15 MHz instantanous bandwidth support at 3GPP band 5. HW supports operation in 3GPP bands 5, 18 and 19. FXCC provides the following benefits: • • • • • • • • • •

324

industry-leading RF integration level SW configurable radio: the same RF Module for LTE, HSPA+ and WCDMA and GSM/EDGE 2 sector RF Module in one outdoor IP65 box less visual impact the widest ambient temperature range: -35... +55 C the smallest power consumption and OPEX 3 sector RF Module in one outdoor IP65 protected box less wind load can be used as feederless site as well with one DC and one or two optical cables RF Module can be used as powerfull one sector RRH : 60 + 60 W 2TX MIMO with HW prepared for 4RX

© 2016 Nokia





Release


System release

eNodeB

MME

SAE GW

UE

NetAct

RL30

LBTS3.0

-

-

-

-


Flexi WCDMA BTS Multimode System Module FSMD or FSME

7.13.3 Functional description Functional overview Flexi Multiradio RF Module HW supports LTE at the 3GPP Band 5, 18 and 19. Flexi Multiradio RF Module FXCC supports the following LTE configurations: • • • •

1 or 1+1 at maximum 10 MHz LTE bandwith and 1TX/2RX 8, 20, 40 or 60 W mode per sector (controlled by SW licenses) 1 sector with maximum 60 + 60 W 2TX/2RX MIMO HW ready for 1 sector maximum 40 + 40 W 2TX/4RX MIMO

Flexi Multiradio RF Module FXCC can be used in feederless (DC up to 200 m) and distributed BTS sites.

7.13.4 System impacts Interdependencies between features There are no interdependencies between this and any other feature. Impacts on interfaces This feature has no impact on interfaces. Impacts on network and network element management tools This feature has no impact on network management and network element management tools. Impacts on system performance and capacity New configurations are available.

7.13.5 LTE1356: Flexi RF Module 2TX 850 (FXCC) management data Alarms


© 2016 Nokia

325



There are no alarms related to this feature. Measurements and counters There are no measurements or counters related to this feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 207


Full name

Abbreviated name

Managed object

Parent structure

EARFCN downlink

earfcnDL

MRBTS/LNBTS/LNCE L

-

EARFCN uplink

earfcnUL

MRBTS/LNBTS/LNCE L

-

For more information, see Reference ► Parameters ► Flexi Zone FDD-LTE BTS Parameters.


Sales information

BSW/ASW BSW

326

License control in network element —

License control attributes —

© 2016 Nokia


Fd Rl30 Desc

Recommend Documents