fd_rl50_desc.pdf

Nokia

LTE Radio Access, Rel. FDDLTE 16A, Operating Documentation, Issue 02 LTE RL50, Feature Descriptions and Instructions DN09185967 Issue 01M Approval Date 2016-08-26

LTE RL50, Feature Descriptions and Instructions

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

DN09185967 Issue: 01M


Table of Contents This document has 297 pages

Summary of changes................................................................... 20

1

RL50 Features - not supported by Flexi Zone Micro....................21

2

Introduction.................................................................................. 22

3

Activating and deactivating LTE features using BTS Site Manager. 23

4

Descriptions of radio resource management and telecom features. 25 LTE486: PLMN ID Selected Mobility Profiles............................... 25 Description of LTE486: PLMN ID Selected Mobility Profiles........ 25 Activating and configuring LTE486: PLMN ID Selected Mobility Profiles......................................................................................... 27 Deactivating LTE486: PLMN ID Selected Mobility Profiles.......... 29 LTE487: Idle Mode Mobility Load Balancing................................ 30 Description of LTE487: Idle Mode Mobility Load Balancing......... 30 Benefits........................................................................................ 30 Requirements...............................................................................30 Functional description.................................................................. 31 System impact..............................................................................32 LTE487: Idle Mode Mobility Load Balancing management data...... 32 Sales information......................................................................... 35 LTE487: Idle Mode Mobility Load Balancing Activating/Deactivating.................................................................36 LTE511: Intra Cell Handover........................................................ 37 Description of LTE511: Intra Cell Handover................................. 37 Benefits........................................................................................ 38 Requirements...............................................................................38 Functional description.................................................................. 39 System impact..............................................................................40 LTE511: Intra Cell Handover management data.......................... 40 Sales information......................................................................... 41 LTE568: DL adaptive closed loop MIMO (4x2).............................41 Description of LTE568: DL Adaptive Closed Loop MIMO (4x2)... 41 Benefits........................................................................................ 41 Requirements...............................................................................41 Functional description.................................................................. 42 System impact..............................................................................45 LTE568: DL adaptive closed loop MIMO (4x2) management data.. 46 Sales information......................................................................... 47

4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4 4.2.1.5 4.2.1.6 4.2.2 4.3 4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 4.3.1.5 4.3.1.6 4.4 4.4.1 4.4.1.1 4.4.1.2 4.4.1.3 4.4.1.4 4.4.1.5 4.4.1.6

DN09185967 Issue: 01M

© 2016 Nokia

3


4.4.2 4.4.3 4.5 4.5.1 4.5.1.1 4.5.1.2 4.5.1.3 4.5.1.4 4.5.1.5 4.5.1.6 4.5.2 4.5.3 4.6 4.6.1 4.6.1.1 4.6.1.2 4.6.1.3 4.6.1.4 4.6.1.5 4.6.1.6 4.6.2 4.6.3 4.7 4.7.1 4.7.1.1 4.7.1.2 4.7.1.3 4.7.1.4 4.7.1.5 4.7.1.6 4.7.2 4.7.3 4.8 4.8.1 4.8.1.1 4.8.1.2 4.8.1.3 4.8.1.4 4.8.1.5 4.8.1.6 4.8.2 4.8.3 4.9 4.9.1 4.9.1.1 4.9.1.2

4

Activating LTE568: DL Adaptive Closed Loop MIMO (4x2)..........47 Deactivating LTE568: DL Adaptive Closed Loop MIMO (4x2)..... 51 LTE585: Smart DRX.....................................................................51 Description of LTE585: Smart DRX..............................................51 Benefits........................................................................................ 52 Requirements...............................................................................52 Functional description.................................................................. 52 System impact..............................................................................57 LTE585: Smart DRX management data.......................................58 Sales information......................................................................... 60 Activating LTE585: Smart DRX.................................................... 60 Deactivating LTE585: Smart DRX................................................ 62 LTE786: Flexible UL Bandwidth................................................... 63 Description of LTE786: Flexible UL Bandwidth............................ 63 Benefits........................................................................................ 63 Requirements...............................................................................64 Functional description.................................................................. 64 System impact..............................................................................67 LTE786: Flexible UL Bandwidth management data..................... 67 Sales information......................................................................... 69 Activating LTE786: Flexible UL Bandwidth...................................69 Deactivating LTE786: Flexible UL Bandwidth.............................. 70 LTE907: TTI Bundling...................................................................71 Description of LTE907: TTI Bundling............................................71 Benefits........................................................................................ 71 Requirements...............................................................................71 Functional description.................................................................. 72 System impact..............................................................................77 LTE907: TTI Bundling management data.....................................79 Sales information......................................................................... 81 Activating LTE907: TTI Bundling.................................................. 81 Deactivating LTE907: TTI Bundling..............................................84 LTE980: IRC for 4 RX Paths........................................................ 85 Description of LTE980: IRC for 4 RX Paths................................. 85 Benefits........................................................................................ 85 Requirements...............................................................................85 Functional description.................................................................. 86 System impact..............................................................................87 LTE980: IRC for 4 RX Paths management data.......................... 88 Sales information......................................................................... 89 Activating LTE980: IRC for 4 RX paths........................................ 89 Deactivating LTE980: IRC for 4 RX paths.................................... 90 LTE1036: RSRQ Based Cell Reselection.................................... 91 Description of LTE1036: RSRQ Based Cell Reselection............. 91 Benefits........................................................................................ 91 Requirements...............................................................................91

© 2016 Nokia

DN09185967 Issue: 01M


4.9.1.3 4.9.1.4 4.9.1.5 4.9.1.6 4.10 4.10.1 4.10.1.1 4.10.1.2 4.10.1.3 4.10.1.4 4.10.1.5 4.10.1.6 4.10.2 4.10.3 4.11 4.11.1 4.11.1.1 4.11.1.2 4.11.1.3 4.11.1.4 4.11.1.5 4.11.1.6 4.11.2 4.11.3 4.12 4.12.1 4.12.1.1 4.12.1.2 4.12.1.3 4.12.1.4 4.12.1.5 4.12.1.6 4.12.2 4.13 4.13.1 4.13.1.1 4.13.1.2 4.13.1.3 4.13.1.4 4.13.1.5 4.13.1.6

DN09185967 Issue: 01M

Functional description.................................................................. 92 System impact..............................................................................93 LTE1036: RSRQ based cell Reselection management data....... 93 Sales information......................................................................... 96 LTE1060: TDD - FDD Handover.................................................. 96 Description of LTE1060: TDD - FDD handover............................ 96 Benefits........................................................................................ 97 Requirements...............................................................................97 Functional description.................................................................. 97 System impact..............................................................................99 LTE1060: TDD - FDD Handover management data.................. 100 Sales information....................................................................... 101 Activating LTE1060: TDD-FDD Handover..................................101 Deactivating LTE1060: TDD - FDD Handover............................102 LTE1089: Downlink Carrier Aggregation - 20 MHz.................... 103 Description of LTE1089: Downlink Carrier Aggregation - 20 MHz... 103 Benefits...................................................................................... 103 Requirements.............................................................................104 Functional description................................................................ 104 System impact............................................................................108 LTE1089: Downlink Carrier Aggregation - 20 Mhz management data............................................................................................ 109 Sales information........................................................................113 Activating LTE1089: Downlink Carrier Aggregation - 20MHz..... 113 Deactivating LTE1089: Downlink Carrier Aggregation - 20 MHz...... 114 LTE1139: ZUC security algorithm...............................................115 Description of LTE1139: ZUC security algorithm........................115 Benefits.......................................................................................116 Requirements............................................................................. 116 Functional description.................................................................117 System impact............................................................................122 Management data...................................................................... 122 Sales information....................................................................... 123 Activating LTE1139: ZUC security algorithm feature using the BTS Site Manager..............................................................................123 LTE1170: Inter - frequency Load Balancing............................... 125 Description of LTE1170: Inter-eNB Inter-Frequency Load Balancing................................................................................... 125 Benefits...................................................................................... 125 Requirements.............................................................................126 Functional description................................................................ 126 System impact............................................................................128 LTE1170: Inter-frequency Load Balancing management data... 129 Sales information....................................................................... 131

© 2016 Nokia

5


4.13.2

4.15.1.6 4.15.2 4.15.3 4.16 4.16.1 4.16.1.1 4.16.1.2 4.16.1.3 4.16.1.4 4.16.1.5 4.16.1.6 4.16.2 4.16.3 4.17 4.17.1 4.17.1.1 4.17.1.2 4.17.1.3 4.17.1.4 4.17.1.5 4.17.1.6

Activating LTE1170: Inter-eNB Inter-frequency Load Balancing...... 131 Deactivating LTE1170: Inter-eNB Inter-frequency Load Balancing.. 134 LTE1407: RSRQ Based Redirect............................................... 134 Description of LTE1407: RSRQ Based Redirect........................ 134 Benefits...................................................................................... 135 Requirements.............................................................................135 Functional description................................................................ 135 System impact............................................................................136 LTE1407: RSRQ Based Redirect management data................. 137 Sales information....................................................................... 138 LTE1442: Open Access Home eNodeB Mobility........................138 Description of LTE1442: Open Access Home eNodeB Mobility.138 Benefits...................................................................................... 138 Requirements.............................................................................138 Functional description................................................................ 139 System impact............................................................................141 LTE1442: Open Access Home eNodeB Mobility management data ................................................................................................... 142 Sales information....................................................................... 143 Activating LTE1442: Open Access Home eNodeB Mobility....... 143 Deactivating LTE1442: Open Access Home eNodeB Mobility... 144 LTE1542: FDD Supercell............................................................145 Description of LTE1542: FDD Supercell.....................................145 Benefits...................................................................................... 145 Requirements.............................................................................145 Functional description................................................................ 146 System impact............................................................................150 LTE1542: FDD Supercell management data..............................151 Sales information....................................................................... 153 Activating LTE1542: FDD Supercell........................................... 153 Deactivating LTE1542: FDD Supercell.......................................155 LTE1680: Active Queue Management....................................... 155 Description of LTE1680: Active Queue Management................ 155 Benefits...................................................................................... 156 Requirements.............................................................................156 Functional description................................................................ 156 System impact............................................................................158 LTE1680: Active Queue Management management data......... 158 Sales information....................................................................... 158

5 5.1 5.1.1 5.1.1.1 5.1.1.2

Descriptions of transport and transmission features.................. 159 LTE505: Transport Separation for RAN Sharing........................ 159 Description of LTE505: Transport Separation for RAN Sharing. 159 Benefits...................................................................................... 159 Requirements.............................................................................159

4.13.3 4.14 4.14.1 4.14.1.1 4.14.1.2 4.14.1.3 4.14.1.4 4.14.1.5 4.14.1.6 4.15 4.15.1 4.15.1.1 4.15.1.2 4.15.1.3 4.15.1.4 4.15.1.5

6

© 2016 Nokia

DN09185967 Issue: 01M


5.1.1.3 5.1.1.4 5.1.1.5 5.1.1.5.1 5.1.1.6 5.1.1.7

Functional description................................................................ 160 System impact............................................................................161 LTE505: Transport Separation for RAN Sharingdescription-module management data...................................................................... 162 Management data...................................................................... 162 Sales information....................................................................... 163 Abbreviations............................................................................. 163

6 6.1 6.1.1

Descriptions of operability features............................................ 165 LTE507: Inter-RAT Neighbor Relation Optimization...................165 Description of LTE507: Inter-RAT Neighbor Relation Optimization.. 165 Benefits...................................................................................... 165 Requirements.............................................................................165 Functional description................................................................ 166 System impact............................................................................174 Management data...................................................................... 176 Sales information....................................................................... 177 LTE523: Multi-Layered Certificate Authorities ........................... 177 Description of LTE523: Multi-Layered Certificate Authorities .... 177 Benefits...................................................................................... 177 Requirements.............................................................................178 Functional description................................................................ 178 System impact............................................................................182 LTE523: Multi-Layered Certificate Authorities management data.... 183 Sales information....................................................................... 184 Activating the LTE523: Multi-Layered Certificate Authorities feature using the BTS Site Manager.......................................... 184 Configuring the certificates manually (out-of-band installation). 185 Configuring the automatic certificate management....................186 Deactivating LTE523: Multi-Layered Certificate Authorities....... 189 LTE962: RACH Optimization......................................................192 Description of LTE962: RACH Optimization...............................192 Benefits...................................................................................... 193 Requirements.............................................................................193 Functional description................................................................ 193 NetAct Optimizer........................................................................ 195 System impact............................................................................195 Management data...................................................................... 196 Sales information....................................................................... 196 Abbreviations............................................................................. 196 LTE1099: Event-triggered symptom data collection and provisioning ............................................................................... 198 Description of LTE1099: Event-triggered symptom data collection and provisioning......................................................................... 198 Benefits...................................................................................... 198

6.1.1.1 6.1.1.2 6.1.1.3 6.1.1.4 6.1.1.5 6.1.1.6 6.2 6.2.1 6.2.1.1 6.2.1.2 6.2.1.3 6.2.1.4 6.2.1.5 6.2.1.6 6.2.2 6.2.2.1 6.2.2.2 6.2.3 6.3 6.3.1 6.3.1.1 6.3.1.2 6.3.1.3 6.3.1.3.1 6.3.1.4 6.3.1.5 6.3.1.6 6.3.1.7 6.4 6.4.1 6.4.1.1

DN09185967 Issue: 01M

© 2016 Nokia

7


6.4.1.2 6.4.1.3 6.4.1.4 6.4.1.5 6.4.1.6 6.4.2 6.5 6.5.1 6.5.1.1 6.5.1.2 6.5.1.3 6.5.1.4 6.5.1.5 6.5.1.6 6.7 6.7.1 6.7.1.1 6.7.1.2 6.7.1.3 6.7.1.4 6.7.1.5 6.7.1.6 6.8 6.8.1 6.8.1.1 6.8.1.2 6.8.1.3 6.8.1.4 6.8.1.5 6.8.1.6 6.9 6.9.1 6.9.1.1 6.9.1.2 6.9.1.3 6.9.1.3.1 6.9.1.3.2 6.9.1.4

8

Requirements.............................................................................198 Functional description................................................................ 199 System impact............................................................................201 LTE1099: Event-triggered symptom data collection and provisioning management data.................................................. 202 Sales information....................................................................... 203 Collecting eNB logs using the LTE1099: Event-triggered symptom data collection and provisioning feature.....................................203 LTE1260: iOMS Certificate Update and Revocation Support ... 204 Description of LTE1260: iOMS Certificate Update and Revocation Support.......................................................................................204 Benefits...................................................................................... 204 Requirements.............................................................................205 Functional description................................................................ 205 System impact............................................................................ 211 LTE1260: iOMS Certificate Update and Revocation Support management data.......................................................................211 Sales information....................................................................... 213 LTE1368: System Upgrade with Backward Compatibility.......... 218 Description of LTE1368: System Upgrade with Backward Compatibility...............................................................................218 Benefits...................................................................................... 218 Requirements.............................................................................218 Functional description................................................................ 219 System impact............................................................................221 LTE1368: System Upgrade with Backward Compatibility management data...................................................................... 222 Sales information....................................................................... 222 LTE1383: Cell-specific Neighbor Relation/PCI Handling........... 222 Description of LTE1383: Cell-specific Neighbor Relation/PCI Handling..................................................................................... 222 Benefits...................................................................................... 223 Requirements.............................................................................223 Functional description................................................................ 224 System impact............................................................................231 LTE1383: Cell-specific Neighbor Relation / PCI Handling management data...................................................................... 232 Sales information....................................................................... 234 LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS....................................................................... 234 Description of LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS.............................................234 Benefits...................................................................................... 235 Requirements.............................................................................235 Functional description................................................................ 236 Support of remote software management for iOMS...................236 Support of remote data backup and restore for iOMS............... 237 System impact............................................................................238

© 2016 Nokia

DN09185967 Issue: 01M


6.9.1.5

6.10.1.6

LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS management data......................................... 239 Sales information....................................................................... 239 LTE1687: Basic Layer3 Data Analyzer (L3DA) ......................... 239 Description of LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE............................................................................................. 239 Benefits...................................................................................... 239 Requirements.............................................................................240 Functional description................................................................ 240 System impact............................................................................241 LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE management data...................................................................... 241 Sales information....................................................................... 241

7 7.1 7.1.1 7.1.1.1 7.1.1.2 7.1.1.3 7.1.1.4 7.1.1.5 7.1.1.6 7.1.2 7.2 7.2.1 7.2.1.1 7.2.1.2 7.2.1.3 7.2.1.4 7.2.1.5 7.2.1.6 7.3 7.3.1 7.3.1.1 7.3.1.2 7.3.1.3 7.3.1.4 7.3.1.5 7.3.1.6 7.4 7.4.1 7.4.1.1 7.4.1.2 7.4.1.3 7.4.1.4 7.4.1.5

Descriptions of BTS site solution features................................. 242 LTE72: 4-way RX diversity......................................................... 242 Description of LTE72: 4-way RX diversity.................................. 242 Benefits...................................................................................... 242 Requirements.............................................................................242 Functional description................................................................ 242 System impact............................................................................243 LTE72: 4-way RX diversity management data........................... 244 Sales information....................................................................... 244 Activating and deactivating LTE72: 4-way diversity................... 244 LTE88: FXDA Flexi RF Module 3TX 900....................................248 Description of LTE88: FXDA Flexi RF Module 3TX 900.............248 Benefits...................................................................................... 249 Requirements.............................................................................249 Functional description................................................................ 249 System impacts..........................................................................250 LTE88: FXDA Flexi RF Module 3TX 900 management data..... 250 Sales information....................................................................... 250 LTE116: Cell Bandwidth - 3 MHz................................................251 Description of LTE116: Cell Bandwidth - 3 MHz.........................251 Benefits...................................................................................... 251 Requirements.............................................................................251 Functional description................................................................ 252 System impact............................................................................252 LTE116: Cell Bandwidth - 3 MHz management data..................253 Sales information....................................................................... 254 LTE117: Cell Bandwidth - 1.4 MHz.............................................254 Description of LTE117: Cell Bandwidth - 1.4 MHz......................254 Benefits...................................................................................... 255 Requirements.............................................................................255 Functional description................................................................ 256 System impact............................................................................256 LTE117: Cell Bandwidth - 1.4 MHz management data...............259

6.9.1.6 6.10 6.10.1 6.10.1.1 6.10.1.2 6.10.1.3 6.10.1.4 6.10.1.5

DN09185967 Issue: 01M

© 2016 Nokia

9


7.4.1.6 7.5 7.5.1 7.5.1.1 7.5.1.2 7.5.1.3 7.5.1.4 7.5.1.5 7.5.1.6 7.6 7.6.1 7.6.1.1 7.6.1.2 7.6.1.3 7.6.1.4 7.6.1.5 7.6.1.6 7.6.2 7.6.3 7.6.4 7.7 7.7.1 7.7.1.1 7.7.1.2 7.7.1.3 7.7.1.4 7.7.1.5 7.7.1.6 7.8 7.8.1 7.8.1.1 7.8.1.2 7.8.1.3 7.8.1.4 7.8.1.5 7.8.1.6 7.9 7.9.1 7.9.1.1 7.9.1.2 7.9.1.3

10

Sales information....................................................................... 260 RAN2126/LTE435: RF Sharing WCDMA-LTE............................260 Description of RAN2126/LTE435: RF Sharing WCDMA - LTE...260 Benefits...................................................................................... 260 Requirements.............................................................................260 Functional description................................................................ 261 System impacts..........................................................................262 RAN2126/LTE435 RF Sharing WCDMA - LTE management data... 262 Sales information....................................................................... 263 LTE471: LTE Dual carrier operation within one RF band........... 263 Description of LTE471: LTE Dual carrier operation within one RF band........................................................................................... 263 Benefits...................................................................................... 263 Requirements.............................................................................264 Functional description................................................................ 264 System impact............................................................................265 LTE Dual carrier operation within one RF band management data. 265 Sales information....................................................................... 265 Activating LTE471: LTE Dual carrier operation within one RF band ................................................................................................... 266 Verifying LTE471: LTE Dual carrier operation within one RF band.. 266 Deactivating LTE471: LTE Dual carrier operation within one RF band........................................................................................... 267 LTE748: FRHD Flexi RRH 4TX 2600 ........................................ 267 Description of LTE748: FRHD Flexi RRH 4TX 2600.................. 267 Benefits...................................................................................... 267 Requirements.............................................................................268 Functional description................................................................ 268 System impacts..........................................................................268 LTE748: FRHD Flexi RRH 4TX 2600 management data........... 269 Sales information....................................................................... 269 LTE972: Flexi Baseband Module FBBA..................................... 269 Description of LTE972: Flexi Baseband Module FBBA.............. 269 Benefits...................................................................................... 269 Requirements.............................................................................269 Functional description................................................................ 270 System impacts..........................................................................272 LTE972: Flexi Baseband Module FBBA management data....... 272 Sales information....................................................................... 273 LTE985: FRGT Flexi 3-sector RF Module 2100 ........................ 273 Description of LTE985: FRGT Flexi 3-sector RF Module 2100.. 273 Benefits...................................................................................... 273 Requirements.............................................................................273 Functional description................................................................ 274

© 2016 Nokia

DN09185967 Issue: 01M


7.9.1.4 7.9.1.5 7.9.1.6 7.10 7.10.1 7.10.1.1 7.10.1.2 7.10.1.3 7.10.1.4 7.10.1.5 7.10.1.6 7.11 7.11.1 7.11.1.1 7.11.1.2 7.11.1.3 7.11.1.4 7.11.1.5 7.11.1.6 7.12 7.12.1 7.12.1.1 7.12.1.2 7.12.1.3 7.12.1.4 7.12.1.5 7.12.1.6 7.13 7.13.1 7.13.1.1 7.13.1.2 7.13.1.3 7.13.1.4 7.13.1.5 7.13.1.6 7.14 7.14.1 7.14.1.1 7.14.1.2 7.14.1.3 7.14.1.4

DN09185967 Issue: 01M

System impacts..........................................................................274 LTE985: FRGT Flexi 3-sector RF Module 2100 management data. 275 Sales information....................................................................... 275 LTE986: FRGS Flexi 3-sector RF Module 2100 ........................275 Description of LTE986: FRGS Flexi 3-sector RF Module 2100..275 Benefits...................................................................................... 275 Requirements.............................................................................276 Functional description................................................................ 276 System impacts..........................................................................276 LTE986: FRGS Flexi 3-sector RF Module 2100 management data. 277 Sales information....................................................................... 277 LTE1066: FRHC Flexi RF Module 6TX 2600 ............................ 277 Description of LTE1066: FRHC Flexi RF Module 6TX 2600...... 277 Benefits...................................................................................... 278 Requirements.............................................................................278 Functional description................................................................ 278 System impacts..........................................................................279 LTE1066: FRHC Flexi RF Module 6TX 2600 management data..... 279 Sales information....................................................................... 279 LTE1067: FRMC Flexi RF Module 6TX 800...............................280 Description of LTE1067: FRMC Flexi RF Module 6TX 800........280 Benefits...................................................................................... 280 Requirements.............................................................................280 Functional description................................................................ 281 System impacts..........................................................................281 LTE1067: FRMC Flexi RF Module 6TX 800 management data.282 Sales information....................................................................... 282 LTE1247: Multiradio System Module extended LTE configurations. 282 Description of LTE1247: Multiradio System Module extended LTE configurations.............................................................................282 Benefits...................................................................................... 282 Requirements.............................................................................283 Functional description................................................................ 283 System impact............................................................................283 Multiradio System Module extended LTE configurations management data...................................................................... 284 Sales information....................................................................... 284 LTE1262: FHEB Flexi RRH 2TX 1800....................................... 284 Descrption of LTE1262: FHEB Flexi RRH 2TX 1800................. 284 Benefits...................................................................................... 285 Requirements.............................................................................285 Functional description................................................................ 285 System impacts..........................................................................285

© 2016 Nokia

11


7.14.1.5 7.14.1.6 7.15 7.15.1 7.15.1.1 7.15.1.2 7.15.1.3 7.15.1.4 7.15.1.5 7.15.1.6 7.16 7.16.1 7.16.1.1 7.16.1.2 7.16.1.3 7.16.1.4 7.16.1.5 7.16.1.6 7.17 7.17.1 7.17.1.1 7.17.1.2 7.17.1.3 7.17.1.4 7.17.1.5 7.17.1.6 7.18 7.18.1 7.18.1.1 7.18.1.2 7.18.1.3 7.18.1.4 7.18.1.5 7.18.1.6 7.19 7.19.1 7.19.1.1 7.19.1.2 7.19.1.3 7.19.1.4 7.19.1.5

12

LTE1262: FHEB Flexi RRH 2TX 1800 management data......... 286 Sales information....................................................................... 286 LTE1329: FRPA Flexi RF Module 6TX 700................................286 Description of LTE1329: FRPA Flexi RF Module 6TX 700.........286 Benefits...................................................................................... 287 Requirements.............................................................................287 Functional description................................................................ 287 System impact............................................................................288 LTE1329:FRPA Flexi RF Module 6TX 700 management data...288 Sales information....................................................................... 289 LTE1395: FRPB Flexi RF Module 6TX 700 ...............................289 Description of LTE1395: FRPB Flexi RF Module 6TX 700.........289 Benefits...................................................................................... 289 Requirements.............................................................................289 Functional description................................................................ 290 System impact............................................................................290 LTE1395: FRPB Flexi RF Module 6TX 700 management data. 291 Sales information....................................................................... 291 LTE1422: FXDB Flexi RF Module 3TX 900................................291 Description of LTE1422: FXDB Flexi RF Module 3TX 900.........291 Benefits...................................................................................... 291 Requirements.............................................................................291 Functional description................................................................ 292 System impacts..........................................................................292 LTE1422: FXDB Flexi RF Module 3TX 900 management data. 293 Sales information....................................................................... 293 LTE1563: FRHF Flexi RF Module 6TX 2600 .............................293 Description of LTE1563: FRHF Flexi RF Module 6TX 2600.......293 Benefits...................................................................................... 293 Requirements.............................................................................294 Functional description................................................................ 294 System impact............................................................................295 LTE1563: FRHF Flexi RF Module 6TX 2600 management data...... 295 Sales information....................................................................... 295 LTE1662: FRHE Flexi RRH 4TX 2600....................................... 295 Description of LTE1662: FRHE Flexi RRH 4TX 2600................ 295 Benefits...................................................................................... 296 Requirements.............................................................................296 Functional description................................................................ 296 System impacts..........................................................................296 Sales information....................................................................... 297

© 2016 Nokia

DN09185967 Issue: 01M


List of Figures Figure 1

Legacy DRX....................................................................................... 53

Figure 2

New DRX mechanism........................................................................ 54

Figure 3

Legacy DRX mechanism.................................................................... 55

Figure 4

Flexible UL bandwidth........................................................................ 64

Figure 5

Example of the Flexible UL Bandwidth configuration......................... 65

Figure 6

Benefits of Flexible UL Bandwidth......................................................67

Figure 7

Normal operation mode...................................................................... 72

Figure 8

TTI bundling mode..............................................................................72

Figure 9

HARQ retransmission in normal operation mode............................... 73

Figure 10

HARQ retransmission in TTI bundling mode...................................... 73

Figure 11

Configuration of Carrier aggregation: LNCEL-1 is used as SCell when LNCEL-4 is PCell..............................................................................107

Figure 12

Configuration of Carrier aggregation: LNCEL-1 is used as SCell when LNCEL-4 is PCell and LNCEL-4 is used as SCell when LNCEL-1 is PCell................................................................................................. 108

Figure 13

C-plane security................................................................................ 117

Figure 14

U-plane security................................................................................ 118

Figure 15

Security key hierarchy...................................................................... 119

Figure 16

RSRQ vs. RSRP...............................................................................136

Figure 17

LTE1442: Open Access Home eNodeB Mobility concept................ 139

Figure 18

ECGI Resolution...............................................................................141

Figure 19

Super cell..........................................................................................146

Figure 20

TA alignment.....................................................................................147

Figure 21

Benefits of super cell........................................................................ 148

Figure 22

discard probability function............................................................... 157

Figure 23

Maximum number of VLANs.............................................................161

Figure 24

Single-root multi-layer public key infrastructure model.....................179

Figure 25

eNB trust pool...................................................................................180

Figure 26

LTE962: RACH optimization overview..............................................194

Figure 27

Symptom data collection from the BTS............................................ 200

Figure 28

Defining symptom data trigger list.................................................... 203

Figure 29

Multi-layer certification authority support.......................................... 206

Figure 30

Signaling flow of automatic certificate update.................................. 207

Figure 31

Revoking an operator certificate.......................................................209

Figure 32

Establishing new TLS connection with CRL check...........................210

Figure 33

Top-down approach for the system upgrade.................................... 219

Figure 34

LTE NRs of eNB-A for a given LTE carrier....................................... 227

Figure 35

Layer 3 Data Analyzer implementation.............................................240

Figure 36

1-sector configuration with one RF Module...................................... 243

DN09185967 Issue: 01M

© 2016 Nokia

13


14

Figure 37

3-sector configuration with two RF Modules.....................................243

Figure 38

Cell Resources commissioning page............................................... 246

Figure 39

Isometric view of the FBBA.............................................................. 270

Figure 40

Capacity extension sub-module LEDs..............................................272

© 2016 Nokia

DN09185967 Issue: 01M


List of Tables Table 1

RL50 Features - not supported by Flexi Zone Micro.......................... 21

Table 2

Hardware and software requirements................................................ 25

Table 3

New parameters................................................................................. 26

Table 4

Related existing parameters...............................................................27

Table 5

Sales information................................................................................27

Table 6

Parameters used for activating and configuring the LTE486: PLMN ID Selected Mobility Profiles feature....................................................... 27

Table 7

Software requirements....................................................................... 31

Table 8

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

Table 9

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

Table 10


Table 11


Table 12


Table 13


Table 14

MIMO switching.................................................................................. 43

Table 15

Tx path failure handling...................................................................... 45

Table 16

New parameters................................................................................. 46

Table 17

Modified parameters...........................................................................46

Table 18


Table 19


Table 20


Table 21


Table 22

Recommended settings for smart DRX profiles................................. 57

Table 23

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

Table 24


Table 25


Table 26


Table 27

Range of the blankedPucch............................................................... 65

Table 28

Related existing counters................................................................... 68

Table 29

New parameters................................................................................. 68

Table 30


Table 31


Table 32


Table 33

TBS table............................................................................................75

Table 34

New counters......................................................................................79

Table 35

New parameters................................................................................. 80

Table 36


Table 37


Table 38


DN09185967 Issue: 01M

© 2016 Nokia

15


16

Table 39


Table 40


Table 41


Table 42


Table 43

Parameters for R-criteria.................................................................... 92

Table 44

Parameters for S criteria.....................................................................93

Table 45

New parameters................................................................................. 94

Table 46


Table 47


Table 48


Table 49

Feature Group Indicators used for inter-frequency Handover TDDFDD.................................................................................................... 99

Table 50

New parameters............................................................................... 100

Table 51

Sales information..............................................................................101

Table 52

Software requirements..................................................................... 104

Table 53

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

Table 54

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

Table 55

Modified parameters......................................................................... 111

Table 56

Sales information.............................................................................. 113

Table 57

Software requirements......................................................................117

Table 58

ZUC Parameters...............................................................................122

Table 59

New parameters............................................................................... 123

Table 60


Table 61


Table 62

Comparison to LTE1387: Intra-eNodeB IF Load Balancing............. 127

Table 63

New counters....................................................................................129

Table 64

New parameters............................................................................... 130

Table 65


Table 66


Table 67

New parameters............................................................................... 137

Table 68


Table 69


Table 70

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

Table 71

New parameters............................................................................... 143

Table 72


Table 73


Table 74

Tx failure handling - configuration A................................................. 148

Table 75

Tx failure handling - configuration B................................................. 149

Table 76

Tx failure handling - configuration C.................................................150

Table 77

Related existing alarms.................................................................... 151

© 2016 Nokia

DN09185967 Issue: 01M


Table 78

New parameters............................................................................... 152

Table 79

Modified parameters.........................................................................152

Table 80

Related existing parameters.............................................................152

Table 81


Table 82


Table 83


Table 84


Table 85


Table 86

New parameters............................................................................... 162

Table 87


Table 88


Table 89


Table 90

Related existing counters................................................................. 176

Table 91

Related existing key performance indicators....................................176

Table 92


Table 93


Table 94


Table 95

Modified alarms................................................................................ 183

Table 96

New parameters............................................................................... 183

Table 97


Table 98


Table 99

eNB authentication methods............................................................ 187

Table 100


Table 101


Table 102

Abbreviations....................................................................................196

Table 103

Terms................................................................................................197

Table 104

New alarms.......................................................................................202

Table 105

Related parameters.......................................................................... 202

Table 106

New OMS LDAP parameters............................................................202

Table 107


Table 108


Table 109

New alarms....................................................................................... 211

Table 110


Table 111

New OMS LDAP parameters............................................................212

Table 112


Table 113


Table 114

Related parameters.......................................................................... 217

Table 115


Table 116


Table 117


DN09185967 Issue: 01M

© 2016 Nokia

17


18

Table 118


Table 119


Table 120

New alarms.......................................................................................232

Table 121

New parameters............................................................................... 233

Table 122


Table 123


Table 124


Table 125


Table 126


Table 127


Table 128


Table 129


Table 130

New parameters............................................................................... 244

Table 131


Table 132


Table 133


Table 134


Table 135


Table 136


Table 137


Table 138


Table 139


Table 140


Table 141

Related Existing alarms....................................................................262

Table 142

New parameters............................................................................... 263

Table 143

WCDMA Sales information...............................................................263

Table 144

LTE Sales information...................................................................... 263

Table 145


Table 146

Modified Parameters........................................................................ 265

Table 147


Table 148


Table 149


Table 150


Table 151

Extension sub-module LEDs (from left to right)................................271

Table 152


Table 153


Table 154


Table 155


Table 156


Table 157


© 2016 Nokia

DN09185967 Issue: 01M


Table 158


Table 159


Table 160


Table 161


Table 162


Table 163


Table 164


Table 165


Table 166


Table 167


Table 168


Table 169


Table 170


Table 171


Table 172


Table 173


Table 174


DN09185967 Issue: 01M

© 2016 Nokia

19

Summary of changes


Summary of changes Changes between issues 01L (2016-07-29, FDD-LTE 15A) and 01M (2016-08-26, FDD-LTE 16A) The following feature has been updated: •

LTE471: LTE Dual carrier operation within one RF band

Changes between issues 01K (2016-06-29, FDD-LTE 16A) and 01L (2016-07-29, FDD-LTE 15A) The following features have been updated: • •

LTE116: Cell Bandwidth - 3 MHz LTE117: Cell Bandwidth - 1.4 MHz

Changes between issues 01J (2016-04-20, FDD-LTE 15A) and 01K (2016-06-29, FDD-LTE 16A) The following features have been updated: • • • • •

20

LTE1036: RSRQ Based Cell Reselection LTE116: Cell Bandwidth - 3 MHz LTE1383: Cell-specific Neighbor Relation/PCI Handling LTE585: Smart DRX LTE1542: FDD Supercell

© 2016 Nokia

DN09185967 Issue: 01M


RL50 Features - not supported by Flexi Zone Micro

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

RL50 Features - not supported by Flexi Zone Micro Features

Category

LTE88: FXDA Flexi RF Module 3TX 900

BTS

LTE435: RF sharing WCDMA-LTE

BTS

LTE471: LTE Dual carrier operation within one RF band

BTS

LTE748: FRHD Flexi RRH 4TX 2600

BTS

LTE985: FRGT Flexi 3-sector RF Module 2100

BTS

LTE986: FRGS Flexi 3-sector RF Module 2100

BTS

LTE1066: FRHC Flexi RF Module 6TX 2600

BTS

LTE1067: FRMC Flexi RF Module 6TX 800

BTS

LTE1089: Downlink carrier aggregation - 20 MHz

Operabiliy

LTE1095: 240 W Multiradio Remote RF

BTS

LTE1139: ZUC security algorithm

RRM

LTE1247: Multiradio System Module extended LTE configurations

BTS

LTE1262: FHEB Flexi RRH 2TX 1800

BTS

LTE1329: FRPA Flexi RF Module 6TX 700

Operability

LTE1367: Automatic cell combination assignment for Carrier Aggregation

Operability

LTE1368: System Upgrade with Backward Compatibility

Operability

LTE1395: FRPB Flexi RF Module 6TX 700

BTS

LTE1422: FXDB Flexi RF Module 3TX 900

BTS

LTE1471: RF sharing LTE-GSM with 3rd generation System Module for LTE and 900MHz band support

BTS

LTE1542: FDD Supercell

RRM

LTE1563: FRHF Flexi RF Module 6TX 2600

BTS

LTE1662: FRHE Flexi RRH 4TX 2600

BTS

DN09185967 Issue: 01M

© 2016 Nokia

21

Introduction


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

22

© 2016 Nokia

DN09185967 Issue: 01M


Activating and deactivating LTE features using BTS Site Manager

3 Activating and deactivating LTE features using BTS Site Manager Purpose Follow this general BTS Site Manager (BTSSM) procedure to activate or deactivate LTE features. Before you start The eNB must already be commissioned. The BTS Site Manager can be connected to the eNB either locally, or from a remote location. For information on feature-specific prerequisites, see section Before you start of every feature-specific procedure.

Steps 1

Start the BTSSM application and establish the connection to the eNB. For details, see Launching BTS Site Manager in Commissioning Flexi Multiradio BTS LTE or the BTSSM online help (section Instructions).

2

Upload the configuration plan file from the eNB. When the BTSSM is connected to the eNB, it automatically uploads the current configuration plan file from the eNB. a) Select View ► Commissioning or click Commissioning on the View bar. b) The BTS Site checkbox, located in the Target section, is selected by default. This is the recommended setting. c) Choose the commissioning type. Use the Template, Manual, or Reconfiguration option depending on the actual state of the eNB. For details, see Manual commissioning, Performing template commissioning, and Performing reconfiguration commissioning in Commissioning Flexi Multiradio BTS LTE.

3

Modify the feature-specific eNB configuration settings. The feature-related settings are found in the set of Commissioning pages. In the top right-hand corner of the BTSSM window, there is a location bar that shows at which stage of the Commissioning process the user is. It is recommended that the user carefully reads the pages containing full eNB configuration information.

DN09185967 Issue: 01M

© 2016 Nokia

23

Activating and deactivating LTE features using BTS Site Manager

4


Send the commissioning plan file to the eNB. Sub-steps a) Go to the Send Parameters page. b) In section Send, choose whether the BTSSM should send to the eNB only the changed parameters: Only changes (may require reset), or a whole set of parameters: All parameters (requires reset). c) Click the Send Parameters button.

5

The new commissioning plan file is automatically activated in the eNB. Sub-steps a) After successful transmission of the parameters, the new configuration is automatically activated. The BTSSM automatically sends an activation command after finishing the file download.

b) If the configuration changes require restart, the eNB performs the restart now.

g

24

Note: For information on possible restarts, see section Before you start of every feature -specific procedure.

© 2016 Nokia

DN09185967 Issue: 01M


Descriptions of radio resource management and telecom features

4 Descriptions of radio resource management and telecom features 4.1 LTE486: PLMN ID Selected Mobility Profiles 4.1.1 Description of LTE486: PLMN ID Selected Mobility Profiles Introduction to the feature The LTE486: PLMN ID Selected Mobility Profiles feature enables a Public Land Mobile Network (PLMN) ID to select a specific profile. This feature is an extension of the LTE490: Subscriber Profile Based Mobility feature. Instead of the Subscriber Profile Identifier (SPID), the Mobile Network Code (MNC) is used to select a mobility profile. The selection is controlled by an O&M switch per eNB. Benefits End-user benefits No effect on the end-user experience. Operator benefits This feature allows the operator to apply PLMN ID specific mobility schemes. Requirements Hardware and software requirements The table below lists hardware and software requirements for this feature. Table 2

Hardware and software requirements

System release RL50

Flexi Multiradio BTS LBTS5.0

OMS -

LBTS5.0

UE 3GPP R8 mandatory

Flexi Multiradio 10 BTS

LBTSFZ5.0

NetAct -

Flexi Zone Micro BTS

MME -

SAE GW -

Additional hardware requirements This feature requires no new or additional hardware. Functional description Functional overview The LTE486: PLMN ID Selected Mobility Profiles feature can be used instead of the LTE490: Subscriber Profile Based Mobility feature if the operator does not support SPID. When the LTE486: PLMN ID Selected Mobility Profiles feature is enabled, it uses the MNC value to map the mobility profile ID. The MNC value of the UE Serving PLMN ID is used as an input to calculate the virtual SPID value. This is when the SPID needs to make a mapping to the Mobility Profile to select the target frequencies for mobility

DN09185967 Issue: 01M

© 2016 Nokia

25



procedures. In selecting the mobility profile, it is possible to use this process to calculate the SPID from the MNC instead of taking it from the S1 message or incoming handover (HO). When the SPID is replaced with the virtual SPID value, the selection of the mobility profile is done according to the LTE490: Subscriber Profile Based Mobility feature (mapping to the mobility profile or, when not possible, to the default profile).

g

Note: The eNB uses the information provided by the RRC connection setup complete message, the broadcasted PLMN IDs, the PLMN IDs supported by the serving MME, and the handover restriction list to identify the serving PLMN ID of the UE. The MNC is derived from the serving PLMN ID. System impact Interdependencies between features This feature is enabled together with the LTE490: Subscriber Profile Based Mobility feature. Impact on interfaces No impact on interfaces. Impact on network management tools No impact on network management tools. Impact on system performance and capacity No impact on system performance or capacity. Management data Alarms No alarms are related to this feature. Measurements and counters No measurements or counters are related to this feature. Key performance indicators No key performance indicators are related to this feature. Parameters The follolwing table lists the parameter introduced with this feature. Table 3

New parameters Full name

Abbreviated name

Mobility profile selection mode

moProfileSelect

Managed object LNBTS

The following table lists existing parameters related to this feature.

26

© 2016 Nokia

DN09185967 Issue: 01M


Table 4


Related existing parameters

Full name

Abbreviated name

Managed object

Structure

Mobility default profile identifier

moDPrId

MODPR

-

Mobility profiles mapping list

moPrMappingList

LNCEL

-

Mobility profile ID

moPrId

LNCEL

moPrMappingList

Subscriber profile ID

spid

LNCEL

moPrMappingList

Last subscriber profile ID of a range

spidLast

LNCEL

moPrMappingList

Sales information The following table presents sales information for this feature. Table 5

Sales information BSW/ASW

License control in network element

ASW

SW Asset Monitoring

Activated by default No

4.1.2 Activating and configuring LTE486: PLMN ID Selected Mobility Profiles Before you start The Mobility profile selection mode (moProfileSelect) parameter activates the feature. Modification of this parameter does not require either an eNB restart or a cell locking. The LTE490: Subscriber Profile Based Mobility feature needs to be enabled. The following table lists the parameters needed for activation and configuration of the LTE486: PLMN ID Selected Mobility Profiles feature. Table 6

Parameters used for activating and configuring the LTE486: PLMN ID Selected Mobility Profiles feature Parameter

Purpose

Requires eNB restart or object locking

Mobility profile selection mode (moProfileSelect)

Activation flag

No

Mobility default profile identifier (moDPrId)

Mandatory configuration

No

Mobility profile identifier (moPrId)

Optional configuration

No

Mobility profiles mapping list (moPrMappingList)

Optional configuration

No

To activate and configure the LTE486: PLMN ID Selected Mobility Profiles feature, do the following:

DN09185967 Issue: 01M

© 2016 Nokia

27



Procedure 1

Follow the general procedure described in section Activating and deactivating LTE features using BTS Site Manager. In Step 3 (Modify the feature-specific eNB configuration settings) of the general procedure, perform the steps described in this procedure.

2

Activate the Mobility profile selection mode (moProfileSelect) parameter. a) b) c) d)

3

Go to the Radio Network Configuration page. Expand the MRBTS object. Select the LNBTS object. Set the Mobility profile selection mode (moProfileSelect) parameter value to plmn.

Create a MODPR instance. On the selected LNBTS object, create a MODPR instance. a) Set the value for the Mobility default profile identifier (moDPrId) parameter.

g

Note: The Mobility default profile identifier (moDPrId) parameter names the attribute of the MOC MODPR, which uniquely identifies a MODPR instance. When the Mobility profiles mapping list (moPrMappingList) or Mobility profile identifier (moPrId) parameter is not configured, all the UEs are mapped to the default profile.

4

(Optional) Create a MOPR instance. On the selected LNBTS object, create a MOPR instance. a) Set the value for the Mobility profile identifier (moPrId) parameter.

g

Note: The Mobility profile identifier (moPrId) parameter names the attribute of the MOC MOPR, which uniquely identifies a MOPR instance.

5

(Optional) Configure the Mobility profiles mapping list (moPrMappingList) parameter. a) b) c) d)

28

Expand the LNBTS object. Right click on the LNCEL object. Select New Mobility profiles mapping list object. Define the value of the listed parameters:

© 2016 Nokia

DN09185967 Issue: 01M


• • •

g


Mobility profile ID (moPrId) Subscriber profile ID (spid) Last subscriber profile ID of a range (spidLast)

Note: The Mobility profile ID (moPrId) parameter is the identifier of the Mobility Profile, which is mapped to one or more SPIDs.

6

Send the parameters to the eNB according to the procedure described in section Activating and deactivating LTE features using BTS Site Manager.

Expected outcome The LTE486: PLMN ID Selected Mobility Profiles feature is activated in the eNB.

4.1.3 Deactivating LTE486: PLMN ID Selected Mobility Profiles Before you start The Mobility profile selection mode (moProfileSelect) parameter deactivates the feature. Modification of this parameter does not require either an eNB restart or a cell locking. To deactivate the LTE486: PLMN ID Selected Mobility Profiles feature, do the following: Procedure 1


2

Configure the Mobility profile selection mode (moProfileSelect) parameter. a) b) c) d)

g

DN09185967 Issue: 01M

Go to the Radio Network Configuration page. Expand the MRBTS object. Select the LNBTS object. Set the Mobility profile selection mode (moProfileSelect) parameter value to spid.

Note: This deactivates the feature.

© 2016 Nokia

29


3


Send the parameters to the eNB according to the procedure described in section Activating and deactivating LTE features using BTS Site Manager.

Expected outcome The LTE486: PLMN ID Selected Mobility Profiles feature is deactivated in the eNB.

4.2 LTE487: Idle Mode Mobility Load Balancing 4.2.1 Description of LTE487: Idle Mode Mobility Load Balancing Introduction to the feature The LTE487: Idle Mode Mobility Load Balancing feature introduces new mechanisms for Idle mode load balancing. Currently existing Idle mode load balancing mechanism for LTE serving cell frequency and inter-frequency will be enhanced with inter-RAT targets. This feature enables following functions: • • •

support of IdleModeMobilityControlInfo IE with inter-RAT target frequencies, allowing UE idle mode mobility load balancing towards inter-RAT systems support of configuration on idle mode target frequencies in mobility profiles configuration support of round robin load balancing algorithm for RRC Connection Release with redirection and CS fallback with redirection

The operator is able to configure for load balancing purposes a percentage of UEs the IdleMode MobilityControlInfo IE is added at normal RRC connection release. Using the Cell Reselection Priority and Carrier Frequency Priority parameters included in the IdleMode MobilityControlInfo the operator is able to configure specific priority for idle mode mobility for intra- and inter-frequency carrier.The parameter Timer (T320) defines the validity time of dedicated priorities.

4.2.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits the operator as follows: With load balancing an improved load distribution is achieved. It is possible to balance in multi-carrier or multi-band deployment.

4.2.1.2

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

30

© 2016 Nokia

DN09185967 Issue: 01M



System release

Flexi Multiradio BTS


RL50

LBTS5.0

LBTS5.0

Table 7

Software requirements

UE

NetAct

MME

OMS

SAE GW

3GPP R8

Hardware requirements This feature requires no new or additional hardware.

4.2.1.3

Functional description Functional overview The LTE487: Idle Mode Mobility Load Balancing feature provides the following functions: •

• •

inter-RAT load balancing for RRC: RRCConnectionRelease message for an operator-configurable percentage of UEs with a RRC connection release without redirection load balancing for RRC with redirection with purpose of redirection and CS (Circuit Switched) fallback, when redirection priorities were set to equal value by operator configuration of idle mode mobility load balancing targets and priorities in Mobility Profiles

The operator is able to configure a specific priority for frequency of the serving cell and each inter-frequency and inter-RAT carrier defined for idle mode mobility. Additional targets and priorities for idle mode mobility load balancing can be configured by operator within mobility profiles. Load balancing algorithm guarantees that only the configured percentage of UEs is used for idle mode mobility load balancing and the new IE IdleModeMobilityControlinfo is added. Priorities defined in the IdleModeMobilityControlinfo IE in the RRC: RRCConnectionRelease message overwrites priorities sent to the UE in the system information broadcast procedures for a by an operator-configured timer value (T320) or until UE will enter RRC CONNECTED mode again. If the purpose is redirection or CS fallback (in the case of RRC Connection Release with redirection) the operator is able to set equal priorities for redirection targets and in such case the load balancing between target frequencies with equal priorities is performed. Selecting UE for load balancing All UEs, for which RRC Connection Release message without redirection will be sent are candidates for idle mode load balancing. Following conditions must be fulfilled for selecting a UE for idle mode load balancing: 1. The percentage of so far configured UEs for idle mode load balancing is not higher than the value configured by an operator in the parameter for percentage of UEs for idle mode load balancing. In case the LTE490: Subscriber profile based mobility

DN09185967 Issue: 01M

© 2016 Nokia

31



feature is activated and the SPID can be mapped to the mobility profile the percentage value is taken from corresponding mobility profile instance. If the default profile is used, it is taken from the default profile instance; and when default configuration is used, it is taken from parameters on LTE cell level. 2. The eNB has at least one frequency valid for load balancing. This frequency must be different than the frequency of the serving cell. Feature Activation The activation/deactivation of the feature will be described in a separate FAI.

4.2.1.4

System impact Interdependencies between features There are interdependencies between the LTE487: Idle Mode Mobility Load Balancing feature and the LTE490: Subscriber Profile Based Mobility feature: The LTE490: Subscriber Profile Based Mobility feature introduces support of SPID and mobility profiles configuration in the eNB. The LTE487: Idle Mode Mobility Load Balancing feature enhances mobility profiles with idle mode mobility targets. The LTE490: Subscriber Profile Based Mobility feature is not mandatory to activate the LTE487:Idle Mode Mobility Load Balancing, feature however, if it is disabled then the LTE487:Idle Mode Mobility Load Balancing feature does not use mobility profiles for choosing target frequencies. The following features are affected by the LTE487: Idle Mode Mobility Load balancing: feature: •

•

LTE562: CS Fallback with redirection: It introduced CSFB (Carrier Selection Fallback) with redirection. LTE487: Idle Mode Mobility Load Balancing allows the configuration of equal priorities for CSFB targets and uses load balancing with round robin algorithm for targets with equal priorities. LTE423: UE Context Release with redirection: It introduced UE Context release with redirection. LTE487: Idle Mode Mobility Load Balancing allows the configuration of equal priorities for redirection targets and uses load balancing with round robin algorithm for targets with equal priorities.

Impact on interfaces This feature impacts interfaces as follows: • • •

Uu interface: Inter-RAT target frequencies in the IdleModeMobility ControlInfo IE in the RRC Connection Release message are supported. eNB to O&M interface: New objects and parameter configurations are supported. NetAct, BTSSM: Additional performance counters are supported.

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

4.2.1.5

LTE487: Idle Mode Mobility Load Balancing management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms

32

© 2016 Nokia

DN09185967 Issue: 01M



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

New counters

Counter ID

Counter name

Measurement

M8023C28

Average number of active UEs of mobility profile 9

LTE UE and service differentiation

M8023C29



M8023C30



M8023C31



M8023C32



M8023C33



M8023C34



M8023C35



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

New parameters

Full name

Abbreviated name

Managed object

EUTRA carrier list for idle mode load balancing

dlCarFrqEutL

MOIMP, MODIMP

EUTRA carrier freq for idle mode load balancing

dlCarFrqEut

MOIMP, MODIMP

DN09185967 Issue: 01M

© 2016 Nokia

Structure

dlCarFrqEutL

33


Table 9


New parameters (Cont.)

Full name

Abbreviated name

Managed object

EUTRA carrier freq idleLBEutCelResPrio prio for idle mode load balancing

MOIMP, MODIMP

CDMA HRPD band list for idle mode load balancing

cdmaHrpdBdClL

MOIMP, MODIMP

CDMA HRPD band class for idle mode load balancing

cdmaHrpdBdCl

MOIMP, MODIMP

cdmaHrpdBDCIL

CDMA 1xRTT band class for idle mode load balancing

cdmaRttBdCl

MOIMP, MODIMP

cdmaHrpdBdClL

CDMA 1xRTT band list for idle mode load balancing

cdmaRttBdClL

MOIMP, MODIMP

GERAN band parameters for idle mode load balancing

geranCarFrqBd

MOIMP, MODIMP

GERAN carrier freq band for idle mode load balancing

geranBandInd

MOIMP, MODIMP

geranCarFrqBd

MOIMP, MODIMP

geranCarFrqBd

GERAN carrier freq idleLBGeranCelResPri prio for idle mode load o balancing

34

Structure dlCarFrqEutL

GERAN carrier freq list for idle mode load balancing

geranCarFrqIdleModeL MOIMP, MODIMP

CDMA HRPD band class prio idle mode load balancing

idleLBHrpdCelResPrio

MOIMP, MODIMP

cdmaHrpdBDCIL

CDMA 1xRTT band class prio for idle mode load balancing

idleLBRttCelResPrio

MOIMP, MODIMP

cdmaRttBdClL

Idle mode mobility profile identifier

moimpId

MOIMP

Idle mode mobility default profile identifier

modimpId

MODIMP

© 2016 Nokia

DN09185967 Issue: 01M


Table 9



Full name

Abbreviated name

Managed object

UTRA FDD carrier list for idle mode load balancing

utrFddCarFrqL

MOIMP, MODIMP

UTRA FDD carrier freq for idle mode load balancing

utrFddCarFrq

MOIMP, MODIMP

utrFddCarFrqL

UTRA FDD carrier idleLBUtraFddCelResP MOIMP, MODIMP freq prio for idle mode rio load balancing

utrFddCarFrqL

CDMA HRPD band priority for idle mode load balancing

idleLBHrpdCelResPrio

CDFIM

hrpdBDCIList

CDMA 1xRTT band priority for idle mode load balancing

idleLBRttCelResPrio

CDFIM

rttBDCIList

Auto adaptation for IMLB

autoAdaptIMLB

MODPR

Percentage of UE for idle mode load balancing

idleLBPercentageOfUe MOPR/MODPR s

GERAN carrier freq idleLBGeranCelResPri prio for idle mode load o balancing

GNFL

Activation of idle mode load balancing (IdleLB))

LNBTS

actIdleLB

UTRA-FDD carrier idleLBUtranFddCelRes UFFIM freq prio for idle mode Prio load balancing

4.2.1.6

Structure

utrFddCarFrqL

Sales information Table 10

Sales information

BSW/ASW


License control attributes

ASW

-

-

DN09185967 Issue: 01M

© 2016 Nokia

35



4.2.2 LTE487: Idle Mode Mobility Load Balancing Activating/Deactivating Purpose Follow these procedures to activate and deactivate the LTE487: Idle Mode Mobility Load Balancing feature.

Activating LTE487: Idle Mode Mobility Load Balancing Before you start The LTE487: Idle Mode Mobility Load Balancing feature must be activated by setting the parameter Activation of idle mode load balancing (actIdleLB) to true. This flag activates the following functionalities: • • •

inter-RAT IdleLB targets Load balancing for redirection (requires also the UE context release with redirect feature "actRedirect" and CS Fallback via Redirection feature "actCSFBRedir") IdleLB targets in Mobility profiles (requires also the "Selective Mobility Profiles" feature "actSelMobPrf")

The activation is possible on-line, a restart of the eNB is not necessary.

Steps

1

Follow the general procedure described in section Activating and deactivating LTE features using BTS Site Manager. In Step 3 (Modify the feature-specific eNB configuration settings) of the general procedure perform the steps described in this procedure.

2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of idle mode load balancing (actIdleLB) parameter value to true. This step activates the feature.

Deactivating LTE487: Idle Mode Mobility Load Balancing Before you start The feature LTE487: Idle Mode Mobility Load Balancing can be deactivated by setting the parameter Activation of idle mode load balancing (actIdleLB)to false.

36

© 2016 Nokia

DN09185967 Issue: 01M



With this setting of the Activation of idle mode load balancing (actIdleLB)to false, idle mode load balancing between different RATs is impossible, but load balancing between different LTE carrier frequencies is possible. To deactivate load balancing fully, in addition the LNCEL parameter Percentage of UE for idle mode load balancing (idleLBPercentageOfUes) must be set to 0. If actIdleLB is set to 'false' all of the following conditions need to be fulfilled: •

for all REDRT instances of the superior LNCEL – –

•

for all MORED instances of the superior MOPR – –

•

redirectPrio must be unique csFallBPrio must be unique


for all MODRED instances of the superior MODPR – –


Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of idle mode load balancing (actIdleLB) parameter value to false. This step deactivates the Inter-RAT idle mode load balancing feature. d) Set the LNCEL parameter Percentage of UE for idle mode load balancing (idleLBPercentageOfUes) to 0. This step deactivates the idle mode load balancing totally.

4.3 LTE511: Intra Cell Handover 4.3.1 Description of LTE511: Intra Cell Handover Introduction to the feature

DN09185967 Issue: 01M

© 2016 Nokia

37



The LTE511: Intra Cell Handover feature allows a handover to the serving cell (the cell where the UE camps). In general, intra-cell handover can be executed in every LTE cell. 3GPP states that intracell handover is not optimized over inter-cell handover. Therefore, the implementation of intra-cell handover is based on intra-eNodeB handover (with some modifications). Intra-cell handover is needed in LTE whenever reconfiguration must be applied synchronously in UE and on network side. For example, intra-cell handover is applied to perform (security) key change on-the-fly. As intra-cell handover is a basic feature, no activation or licensing is needed.

4.3.1.1

Benefits End-user benefits The end-user connection remains stable for some applications using the intra-cell handover, for example: intra-cell Handover for Re-Keying intra-cell Handover because of run out of DRB ID intra-cell Handover because of PDCP sequence number overflow intra-cell Handover because of RLC Retransmission Error

• • • •

Operator benefits The operator has the same benefits as in the end-user benefits are written. This leads to a lower call failure rate and no losing of connections caused by some events like ReKeying.

4.3.1.2

Requirements Software requirements lists the software required for this feature.

System release



RL50

LBTS5.0

LBTS5.0

Table 11

UE

OMS


NetAct

MME

SAE GW

3GPP R8


38

© 2016 Nokia

DN09185967 Issue: 01M


4.3.1.3


Functional description Functional overview LTE system does not support synchronized call processing procedures between UE and RAN. Activation time IE as known from other systems like UMTS are not present in RRC messages. Nevertheless, there are some reconfiguration which need to be executed synchronously in UE and RAN Examples for such reconfigurations are e.g. the switching on/off TTI-bundling or the change of ciphering keys. Intra-cell handover is the only method available within LTE to achieve this synchronization. From a UE point of view, the execution of intra-cell handover does not deviate from normal intra frequency handover. The only difference is that the handover was triggered by RAN internal events instead of measurement reports. From an eNodeB point of view intra-cell handover is also very similar to intra-frequency intra-eNodeB handover. However, some simplifications can be made, for example by bypassing admission control and avoiding measurement reconfiguration. Intra-cell Handover Execution 3GPP states that intra-cell handover is not optimized over inter-cell handover. Therefore the implementation of intra-cell handover is based on intra eNodeB handover with the following modifications: • •

•

The configuration information provided to the UE is the new configuration needed by the calling application. Further configuration changes independent of the calling procedure (for example. enabling/disabling of features, ...) is handled in the same way as during inter-cell handover. The RAC for the target cell is bypassed as it can be assumed that the resources needed on the air interface are the same before and after intra-cell handover (Note that PUCCH resources as well as some eNodeB internal resources need to be allocated temporarily twice. Therefore, it can happen in exceptional cases that an intra-cell handover can not be executed becaused of resource shortage.) In case of RRC Re-Establishment during intra-cell handover the UE shall be handled in the same way as a UE requesting RRC Re-Establishment towards the handover target cell.

Application Security Key Update Intra-cell handover is applied to perform key change on-the-fly. There are two kinds of key change on-the-fly: 1. Key refresh, which is needed to avoid a keystream reusage (by COUNT re-usage or by bearer-ID re-usage). Because a key refresh happens at any intra-LTE handover, intra-cell handover is suitable if no mobility happens. 2. Re-keying, which is needed to activate a new security context after an AKA (authentication and key agreement) run will be triggered by an S1AP: UE CONTEXT MODIFICATION REQUEST message containing a new KeNB. Because it requires a well defined context transition, it is done by intra-cell handover.

DN09185967 Issue: 01M

© 2016 Nokia

39


4.3.1.4


System impact Interdependencies between features The following features have interdependencies to the LTE511: Intra Cell handover feature: •

•

LTE53: Intra and inter eNodeB Handover with X2: the intra-cell handover execution is specified as a special case of intra eNodeB handover where source and target cell are identical. LTE907: TTI Bundling: TTI bundling makes use of intra-cell handover to switch TTI bundling on/off synchronously.

Impact on interfaces

S1-Interface The existing message UE CONTEXT MODIFICATION REQUEST is enhanced to

support security key update. 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 impacts system performance and capacity as follows: Physical Uplink Control Channel (PUCCH) resources as well as some eNodeB internal resources need to be allocated twice. Therefore, it can happen in exceptional cases that an intra-cell handover can not be executed because of resource shortage.

4.3.1.5

LTE511: Intra Cell Handover 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.

40

© 2016 Nokia

DN09185967 Issue: 01M


4.3.1.6



Sales information

BSW/ASW



BSW

-

-

4.4 LTE568: DL adaptive closed loop MIMO (4x2) 4.4.1 Description of LTE568: DL Adaptive Closed Loop MIMO (4x2) Introduction to the feature The evolved node B (eNB) supports downlink (DL) adaptive closed loop (CL) multiple inputs multiple outputs (MIMO) 4x2.

4.4.1.1

Benefits Operator benefits MIMO (4x2) configuration provides mainly additional cell coverage gain as well as a small capacity gain compared to a MIMO (2x2) configuration.

4.4.1.2


System release



RL50

-

LBTS5.0

Table 13

OMS

-


UE

NetAct

MME

SAE GW

3GPP R8 mandatory

-

-

-

Hardware requirements This feature requires the following hardware: • •

DN09185967 Issue: 01M

RRH that supports configuration of 4 antenna ports including DL reference signals for each port. Antenna system including 4 antennas branches (for example dual x-pol).

© 2016 Nokia

41


4.4.1.3


Functional description Functional overview The LTE568: DL Adaptive Closed Loop MIMO (4x2) feature extends the already existing MIMO functionality to support precoding for spatial multiplexing (SM) for two antenna ports (MIMO 2x2) to be extended to four antenna ports (MIMO 4x2) at the eNB side in DL direction. CL MIMO (4x2) leads to improved cell capacity (average cell throughput) and coverage at the cell edge. The basic transmission mode (TM) is TM4, which is a consequence of CL operation. The configuration of TM is decided during connection establishment. The eNB dynamically adapts the transmission multiplicity of data, in DL direction, over physical downlink shared channel (PDSCH) to the channel condition. The UE reports channel condition by means of Rank Indicator (RI), Precoding Matrix Indicator (PMI) and Channel Quality Indicator (CQI). Based on the provided reports, the eNB performs switching between single layer, single codeword and dual layer, dual codeword spatial multiplexing transmission. The eNB ensures fallback to Tx diversity mode over 4 antenna ports (4 Tx diversity), in case of no report or missing PMI/RI reports. When the DL adaptive closed loop MIMO (4x2) feature is configured the eNB supports improved codebook with respect to corresponding precoding used for MIMO 2x2 (16 PMIs instead of 4 for layer 1 and 2 for layer 2 transmissions). More PMIs means more discrete precoding available for 4 Tx antennas compared to 2 Tx antennas. DL adaptive closed loop MIMO (4x2) This feature supports: •

•

TM4 using DCI-Format 2 (DCI-2). The eNB uses DCI-2 to schedule one or two codewords on the PDSCH including Precoding Information to support CL spatial multiplexing. As a special case DCI-2 supports 4 layers transmit diversity by sending precoding information index 0, in case only 1 codeword is enabled. TM2 using DCI-1 that is additionally implemented to support transmit diversity in the 4 Tx antenna case. TM2 is supported as basic transmission mode to complement transmit diversity operation in case of 2 Tx antennas. All UEs have to support this basic TM.

CL MIMO 4x2 in DL restricts the maximum number of spatial layers to 2 layers. Therefore, the peak throughputs remain nearly unchanged under optimum radio conditions in comparison to MIMO 2x2 with slight reductions caused by code rate limitations depending on the detailed PDCCH configurations. When DL Adaptive Closed Loop MIMO (4x2) is configured the eNB supports: • • •

•

4 antenna ports to connect 4 Tx antennas Cell Reference Symbols (CRS) for channel estimation of transmission over antenna ports 0, 1, 2, and 3 precoding of transmitted symbols based on codebook specified for 4 Tx antenna to improve transmission performance by discrete channel feedback signaled via 16 PMIs (for more details, see TS 36.211 Table 6.3.4.2.3-2) 4-way Tx Diversity for physical downlink control channel (PDCCH), physical control format indicator channel (PCFICH), physical hybrid ARQ indicator channel (PHICH), PBCH, and PDSCH

The UE must support:

42

© 2016 Nokia

DN09185967 Issue: 01M


channel estimation of 4 transmission paths coming from the 4 Tx antennas channel state feedback by reporting the optimum RI and PMI to achieve maximum precoding gains. Optimum Rank selection in combination with optimum PMI selection provides overall gains (diversity gains, coherence gains and spatial multiplexing gains).

• •

g


Note: To fully benefit from using MIMO4x2, the optimum channel quality monitoring, channel estimation, and channel state reporting by the UE in case of four transmit antenna configurations are required. 4 Tx Fast Adaptive Closed Loop MIMO 4x2 The MIMO switching algorithm for TM4 closed loop MIMO (4x2) is enabled by setting the dlMimoMode operation and maintenance (O&M) parameter to the enumeration value Closed Loop MIMO (4x2) and Activate fast adaptive MIMO switch (actFastMimoSwitch) to true. Table 14: MIMO switching presents the possible transmission schemes for the PDSCH and the switching conditions in case of closed loop transmission in TM4. Table 14

MIMO switching

PDSCH in TM4: 4 antenna ports 4-way TxDiv

CL SM Single Layer

CL SM Dual Layer

No RI or PMI report

RI=1

RI=2

PMI: valid

PMI: valid

No Valid CL CSI

Fast MIMO switch based on reported RI

The UE estimates the most suitable beam direction for each of transmitted layers. In case of 4 antenna ports configuration (0, 1, 2, 3), based on the UE’s feedback, the eNB selects one of the following PDSCH transmission schemes: •

CL SM Single Layer: the eNB selects CL SM Single Layer Transmission in case the UE reports: – –

•

CL SM Dual Layer: the eNB selects CL SM Dual Layer Transmission in case the UE reports: – –

•

DN09185967 Issue: 01M

valid and complete CSI for RI = 1 CSI corresponding to PMI (PMI Є 0, 1,...,15)

valid and complete CSI for RI = 2 CSI corresponding to PMI (PMI Є 0, 1,...,15)

4-way TxDiv: Transmit Diversity using 4 antenna ports is used whenever there is no valid precoding information or rank information reported by the UE. It might happen when:

© 2016 Nokia

43


–

– –


There is no update of valid CL RI/PMI reports for single layer (RI=1) and dual layer (RI=2) transmissions since a determined update time in transmission time intervals (TTIs). If there is no valid report within this time period, then the eNB switches the transmission scheme to 4-way TxDiv. During initialization when radio resource control (RRC) setup is performed and no valid joint report for RI and PMI is known to the eNB. The UE does not send valid reports including RI and PMI as it is required for TM4 CL operation.

Performance gain of CL MIMO depends on the performance of the UE to send correctly and consistently the reports of CQI, RI and PMI belonging to a specific Rank and supporting Rank selection by the UE to maximize throughput. It is assumed that the UE performs filtering and averaging to provide reports for CQI, PMI and RI reflecting conditions of the channel at the location of the UE. LTE568: DL Adaptive Closed Loop MIMO (4x2) configuration The LTE568: DL Adaptive Closed Loop MIMO (4x2) feature can be enabled when four Tx antennas are connected to the eNB and when they are defined in the Resource list (resourceList). Activation of this feature is done by setting the dlMimoMode parameter to the enumeration value Closed Loop MIMO (4x2). This feature supports fast adaptive MIMO switching, that is fast Rank selection and fast codebook based precoding of data transmission, using CL feedback of PMI in combination with RI. Fast adaptive MIMO switching can be enabled by setting the Activate fast adaptive MIMO switch (actFastMimoSwitch) parameter to true. PMI and RI reporting delays have to be minimized by periodic and aperiodic reports sent by UEs to optimize PMI CL gain in combination with optimized Rank selection. If fast adaptive MIMO switching is activated, the periodic reports have to be configured as follows: • •

•

The Rank indication reporting enable (riEnable) parameter has to be set to true. The Multiplier M for periodic RI reporting period (riPerM) parameter has to be set to 1 to assure delays between RI and CQI/PMI reports to be 1 subframe. The Periodic RI reporting offset (riPerOffset) parameter is set to -1 (RI reporting offset is fixed to -1). Once the RI report is available, it is immediately reported to the eNB to support fast CL adaptation to channel state.

When the LTE568: DL Adaptive Closed Loop MIMO (4x2) feature is activated, periodic reporting mode has to be set to mode 1-1 or 2-1. The eNB configures aperiodic reporting (mode 2-2 or 3-1) depending on L1L2 O&M settings (the UE capabilities are also taken into account). For TM4 and aperiodic reporting, the eNB gets joint RI/PMI reports for either RI=1 or RI=2. The eNB always selects the most recent information from periodic/aperiodic report provided by the UE. TX path failure handling Table 15: Tx path failure handling presents operational state of the cell and reported alarms depending on the TX path failure mode (txPathFailureMode) and Synchronization signals transmission mode (syncSigTxMode) parameters configuration.

44

© 2016 Nokia

DN09185967 Issue: 01M


Table 15


Tx path failure handling

txPathFailureMode

syncSigTxMode

keepCellInService

SingleTx

keepCellInService

SingleTx

keepCellInService

TxDiv

TX path failure(s) in cell

LNCEL operational state and alarm

antenna which transmits synchronization signal

Disabled

one or more antennas which do not transmit synchronization signals

Enabled

all antennas failed

Disabled

CELL FAULTY Alarm

CELL DEGRADED Alarm

CELL FAULTY Alarm keepCellInService

TxDiv

at least one antenna operable

Enabled CELL DEGRADED Alarm

disableCell

SingleTx or TxDiv

one or more TX paths fail

Disabled CELL FAULTY Alarm

g

4.4.1.4

Note: Configuration of the txPathFailureMode parameter determines the operational state of the cell depending on configured syncSigTxMode parameter and Tx path failure status. The configuration does not guarantee that data transmission is maintained even if the cell has operational state Enabled. There are specific Tx path failure combinations that inhibit data transmission, for example when there is 15 MHz DL bandwidth configured and the failure of two Tx paths (0,2 or 1,3) occurs.

System impact Interdependencies between features LTE72: 4RX diversity or LTE980: IRC for 4 RX has to be enabled to activate LTE568: DL adaptive closed loop MIMO (4x2). The LTE1089: Downlink Carrier Aggregation feature has to be disabled before activation of LTE568: DL adaptive closed loop MIMO (4x2). LTE1247: Multiradio System Module extended LTE configurations specifies hardware configuration that is required to support LTE568: DL adaptive closed loop MIMO (4x2). 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 It is still under investigation. The information will be provided in further releases.

DN09185967 Issue: 01M

© 2016 Nokia

45


4.4.1.5


LTE568: DL adaptive closed loop MIMO (4x2) 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 LTE568: DL Adaptive Closed Loop MIMO (4x2) feature is reusing measurements and counters defined for the LTE703: Downlink Adaptive Closed Loop MIMO for Two Antennas feature. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 16: New parameters lists parameters introduced with this feature. Table 16

New parameters

Full name

Abbreviated name

Managed object

Activate fast adaptive MIMO switch

actFastMimoSwitch

LNCEL

TX path failure mode

txPathFailureMode

LNBTS

Table 18: Modified parameters and Table 17: Modified parameters list parameters modified by this feature. Table 17

Modified parameters

Full name

Abbreviated name

Structure

Resource list

resourceList

LCELL

Antenna line id

antlId

LNCEL

Resource list

Sub cell identifier

subCellId

LCELL

Resource list

TX and RX usage

txRxUsage

LNCEL

Resource list

Table 18

Modified parameters

Full name Downlink MIMO Mode

46

Managed object

Abbreviated name dlMimoMode

© 2016 Nokia

Managed object LNCEL

DN09185967 Issue: 01M



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


Full name

4.4.1.6

Abbreviated name

Managed object

Downlink reference signals transmission dlRsBoost power boost

LNCEL

MIMO power compensation

dlpcMimoComp

LNCEL

CQI threshold for fallback to CL MIMO 1 CW mode

mimoClCqiThD

LNCEL

CQI threshold for activation of CL MIMO 2 CW mode

mimoClCqiThU

LNCEL

Rank threshold for fallback to CL MIMO 1 CW mode

mimoClRiThD

LNCEL

Rank threshold for activation of CL MIMO 2 CW mode

mimoClRiThU

LNCEL

Multiplier M for periodic RI reporting period

riPerM

LNCEL

Periodic RI reporting offset

riPerOffset

LNCEL

Synchronization signals transmission mode

syncSigTxMode

LNCEL

PRS power boost

prsPowerBoost

LNCEL

Rank indication reporting enable

riEnable

LNCEL


Sales information

BSW/ASW



ASW

-

-

4.4.2 Activating LTE568: DL Adaptive Closed Loop MIMO (4x2) Before you start Restart of the eNB is required after activation of this feature only if the following parameter values are changed: •

DN09185967 Issue: 01M

Periodic RI reporting offset (riPerOffset)

© 2016 Nokia

47


• • •


Rank indication reporting enable (riEnable) TX path failure mode (txPathFailureMode) Resource list (resourceList) set of parameters

The Downlink MIMO mode (dlMimoMode) parameter and the Resource list (resourceList) set of parameters are used to activate the feature. The following parameters are used to perform an additional configuration of the feature: • • • • • • • • •

Activate fast adaptive MIMO switch (actFastMimoSwitch) Synchronization signals transmission mode (syncSigTxMode) TX path failure mode (txPathFailureMode) Downlink reference signals transmission power boost (dlRsBoost) MIMO power compensation (dlpcMimoComp) PRS power boost (prsPowerBoost) Rank indication reporting enable (riEnable) Multiplier M for periodic RI reporting period (riPerM) Periodic RI reporting offset (riPerOffset)

The following features need to be activated/configured before activation of LTE568: DL Adaptive Closed Loop MIMO (4x2): • •

LTE72: 4RX diversity or LTE980: IRC for 4 RX LTE1247: Multiradio System Module extended LTE configurations

The LTE1089: Downlink Carrier Aggregation - 20 MHz feature has to be deactivated before activation of LTE568: DL Adaptive Closed Loop MIMO (4x2) Procedure 1


2

Configure four Tx antennas and activate the feature a) Go to the Cell Resources page. b) In the Local cells section, select the cell where the LTE568: DL Adaptive Closed Loop MIMO (4x2) feature will be activated. c) Configure four Tx antennas in the Antennas section.

g

Note: This step modifies the Resource list (resourceList) set of parameters. d) In the MIMO settings section, set the Downlink MIMO mode (dlMimoMode) parameter to Closed Loop MIMO (4x2).

g

48

Note: This step activates the feature.

© 2016 Nokia

DN09185967 Issue: 01M


3


Activate fast adaptive MIMO switch (optional) Sub-steps a) Go to the Radio Network Configuration page.

b)

c)

d)

e)

f)

g)

g

4

Expand the MRBTS object.

Expand the LNBTS object.

Select the LNCEL object corresponding to the cell where the LTE568: DL Adaptive Closed Loop MIMO (4x2) feature is being activated and where the fast adaptive MIMO switch will be activated.

Set the Rank indication reporting enable (riEnable) parameter the true.

Set the Activate fast adaptive MIMO switch (actFastMimoSwitch) parameter to true.

Set the Multiplier M for periodic RI reporting period (riPerM) parameter to 1. Note: Make sure that the Periodic RI reporting offset (riPerOffset) parameter is set to -1. Modification of this parameter value leads to the eNB restart.

Configure TX path failure handling (optional) Sub-steps a)

Go to the Radio Network Configuration page.

b) Expand the MRBTS object.

DN09185967 Issue: 01M

© 2016 Nokia

49



c) Select the LNBTS object.

d)

g

Set the TX path failure mode (txPathFailureMode) parameter. Note: For more information on TX path failure handling, see TX path failure handling.

e) Set the Synchronization signals transmission mode (syncSigTxMode) parameter.

5

Configure downlink power control (optional) Sub-steps a)

b)



c) Expand the LNBTS object.

d)

e)

f)

g)

Select the LNCEL object corresponding to the cell where the LTE568: DL Adaptive Closed Loop MIMO (4x2) feature is being activated and where the downlink power control will be configured.

Set the MIMO power compensation (dlpcMimoComp) parameter.

Set the Downlink reference signals transmission power boost (dlRsBoost) parameter.

Set the PRS power boost (prsPowerBoost) parameter.

Expected outcome

50

© 2016 Nokia

DN09185967 Issue: 01M



The LTE568: DL Adaptive Closed Loop MIMO (4x2) feature is activated and the eNB uses four Tx antennas to transmit the signal over PDSCH to the compliant UEs.

4.4.3 Deactivating LTE568: DL Adaptive Closed Loop MIMO (4x2) Before you start Restart of the eNB is not required after deactivation of this feature. The Downlink MIMO mode (dlMimoMode) parameter and the Resource list (resourceList) set of parameters are used to deactivate the feature. Procedure 1


2

Deactivate the feature Sub-steps a)

b)

c)

g

Go to the Cell Resources page.

In the MIMO settings section, set the Downlink MIMO mode (dlMimoMode) parameter to any value other than Closed Loop MIMO (4x2).

Configure antennas in the Antennas section according to the selected downlink MIMO configuration. Note: This step modifies the Resource list (resourceList) set of parameters.

Expected outcome The LTE568: DL Adaptive Closed Loop MIMO (4x2) feature is deactivated.

4.5 LTE585: Smart DRX 4.5.1 Description of LTE585: Smart DRX Introduction to the feature

DN09185967 Issue: 01M

© 2016 Nokia

51



This feature is an extension to the existing LTE42: Support of DRX in RRC Connected Mode and LTE473: Extended DRX Settings, which improves power saving for always on users by introduction of short DRX cycle.

4.5.1.1

Benefits End-user benefits The feature enables the end-user better power saving for the duration of the UE short term inactivity timer in comparison to legacy DRX features. Operator benefits This feature reduces power-consumption of UEs in the network.

4.5.1.2

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


System release



RL50

LBTS5.0

LBTS5.0

OMS -

UE

NetAct

MME

SAE GW

UEs supporting short DRX (FGI bit 4 set to 1)

OSS5.4 CD2

-

-


4.5.1.3

Functional description Legacy DRX features overview The LTE42: Support of DRX in RRC Connected Mode feature introduces the basic DRX mechanism to perform micro-sleeps in monitoring PDCCH to extend the battery life, and in the same time, to assure good QoS and connectivity. The UE has to monitor the PDCCH only during the DRX Active Time. When there is neither UL nor DL traffic, the minimum duration of the DRX Active Time is given by the DRX OnDuration. Long DRX cycle is a time interval that consists of OnDuration and sleep times. When the UE is in the sleep state, it significantly reduces power consumption. Savings in power are feasible for bursty traffic patterns, that is, short phases with data transmission followed by long phases of data inactivity 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. The LTE42: Support of DRX in RRC Connected Mode defines three operator-configurable DRX profiles for different type of services. LTE473: Extended DRX Settings supports an extended value range of the long DRX cycle, introduces two additional operator configurable DRX profiles, and finally, enables uplink Out-of-Sync handling.

52

© 2016 Nokia

DN09185967 Issue: 01M



With every data transmission, the UE becomes DRX active, the eNB starts the Short Term Inactivity Timer (STIT) timer, and sends Timing Alignments (TA) commands or dummy grant to the UE until STIT expires. This is needed to provide reliable TA estimation and maintenance. After the expiry of the Short Term Inactivity Timer (STIT), the eNB does not send more time alignment (TA) commands to the UE, and after Time Alignment Timer (TAT), the eNB considers that UE as UL Out-Of-Sync (for more information, see Figure 1: Legacy DRX). Figure 1

Legacy DRX

The UE has to perform PDCCH monitoring after successful decoding the PDCCH that indicates an initial UL or DL transmission. The DRX inactivity timer (drxInactivityT) parameter defines the number of consecutive TTIs during which the UE performs the monitoring. The Nokia solution requires that the drxInactivityT parameter is greater or equal to the DRX cycle length. This restriction is valid only for DRX cycle >= 160 ms. STIT is the operator-configurable timer, which is calculated by multiplication of the Short term inactivity factor (stInactFactor) and the DRX inactivity timer (drxInactivityT) parameters. During STIT and remaining drxInactivityT, there is an increased battery consumption. The LTE585: Smart DRX feature removes this disadvantage by introduction of short (in addition to long) DRX cycle. Smart DRX overview

DN09185967 Issue: 01M

© 2016 Nokia

53



When legacy DRX is configured, all UEs defined by the Apply UL out-of-sync state (applyOutOfSyncState) parameter are continuously served with TA commands for the duration of the STIT. Together with the aforementioned restriction for DRX cycle >= 160 ms, this handling leads to the situation, when the UE is DRX Active during STIT and remaining drxInactivityT. Although the concept assures proper TA estimation, it makes impossible to save the UE’s battery (during STIT and remaining drxInactivityT). This situation can last even longer than twice the DRX long cycle, depending on STIT and drxInactivityT settings. LTE585: Smart DRX introduces the new concept that enables better battery saving and also assures reliable TA estimation. Instead of keeping the UE DRX active for the duration of STIT and remaining drxInactivityT, the short DRX cycle is used to provide enough measurements to estimate TA. The eNB measures the timing offset from PUSCH and PUCCH (CQI/RI/PMI reports) transmissions and based on the result, the eNB calculates reliable TA estimation. The restriction with regards to the value of the drxInactivityT is no longer necessary, and therefore, the entire 3GGP range of drxInactivityT can be used. Assuming that drxInactivityT is configured smaller than drxLongCycle, the new concept provides better battery savings as compared to legacy DRX for the duration of STIT and remaining drxInactivityT. After this time, the short DRX cycle times out and both concepts (LTE473: Extended DRX Settings and LTE585: Smart DRX) have the same battery consumption since only the long DRX cycle is run by the UE. Example of Smart DRX configuration Figure 2

New DRX mechanism

Figure 2: New DRX mechanism illustrates an example of Smart DRX configuration. The parameters used in this example are as follows: • • • • •

drxLongCycle = 2560 ms (purple lines) drxOnDuratT = 10 ms drxInactivityT = 50 ms drxShortCycle = 80 ms (yellow lines) drxShortCycleT = 16, it means that short DRX cycle runs minimum for the duration of 16 * 80 ms = 1280 ms

Parameters drxOnDuratT and drxInactivityT are common for both cycles. Both long and short DRX cycles are aligned with the CQI reporting period. This means that a CQI/RI report is received in every OnDuration time. The purple lines represent the OnDuration occurrences of the long DRX cycle and the yellow lines show the OnDuration occurrences of the short DRX cycle.

54

© 2016 Nokia

DN09185967 Issue: 01M


Figure 3


Legacy DRX mechanism

StartoflongDRXcycle;UL/DLtx

TAcommandordummygrant restart drxInactivityT;

start drxInactivityT;

DRXActiveTime;nobatterysaving

2560ms Figure 3: Legacy DRX mechanism illustrates legacy concept. For comparison reasons, all parameters are set equally to the previous example except the drxInactivityT and the short DRX cycle parameters. The drxIanctivityT parameter is set to 2560 ms (equally to drxLongCycle) and short DRX cycle parameters do not apply. The battery savings achieved with the new concept under same conditions are evident.

g

Note: Battery savings should not be achieved at the cost of inaccurate TA. Timing Alignment TA estimation relies on PUCCH (CQI/PMI/RI reports) and PUSCH transmissions. Samples for TA estimation are collected during a 250 ms observation window. In addition, three previous observation windows are included into the estimation. Each of them is weighted with a different factor. The older the observation window is, the lower the weighting factor is chosen. TA samples of the current observation window are weighted with 1. The reliability of the weighted TA estimates of all four observation windows is summed up. If the sum is greater or equal to 1, then the TA estimation is considered as reliable. In the worst case scenario only CQI reports are available for TA estimation. 12 CQI reports are necessary to estimate TA in a tolerable way. When the CQI reporting period is 80 ms, it means that TA estimation is available after 960 ms. Four observation periods with the combined duration of 1 s are necessary. When the short DRX cycle runs and a reliable TA estimate is available, the eNB sends TA command to the UE. This leads to the (re)start of the drxInactivityT and the UE (stays) becomes DRX Active. After expiration of drxInactivityT, the drxShortCycleT timer is restarted and the UE follows again the short DRX cycle. When the drxShortCycleT timer expires, the UE falls back to the long DRX cycle. UEs are served with TA commands only for the duration of STIT. To enable the eNB to collect enough measurements and avoid possible issues with TA estimation, the eNB monitors the short DRX cycle timer when the STIT runs. If the remaining runtime of the short DRX cycle timer is less than the short DRX cycle duration and if the STIT expires after the short DRX cycle timer, the eNB triggers the restart of the short DRX cycle timer. This restart is done by sending explicitly a dummy grant to the UE. Parameters recommendations The UE can take advantage of LTE585: Smart DRX when:

DN09185967 Issue: 01M

© 2016 Nokia

55


• •


The LTE585: Smart DRX feature is activated. The UE supports short DRX cycle. The UE indicates this to the eNB via respective settings (FGI bit 4 set to true).

When all the above conditions are met, the UE is configured with smart DRX profiles based on the current bearer combination. Smart DRX profiles are not applicable for ANR where only DRX long cycle is used. For more information on ANR, see LTE782: ANR UE based. LTE585: Smart DRX does not change Out-Of-Sync handling specified in LTE473: Extended DRX Settings, however, the definition of STIT is changed. When LTE585: Smart DRX is activated, STIT is calculated as follows: STIT = smartStInactFactor * drxShortCycle The smartStInactFactor parameter is defined for each of the smart DRX profiles 2, 3, 4 and 5. It is assured by consistency check that smartStInactFactor meets the following requirement:

smartStInactFactor * drxShortCycle >= max{200 ms, drxLongCycle} Since LTE585: Smart DRX introduces the short DRX cycle, the drxInactivityT parameter is now configurable without any restrictions. The parameter recommendations are based on the worst case scenario that only CQI reporting is available for TA estimation. The guidelines refer mostly to the parameterization of the short DRX cycle with regards to the configured values of the CQI periodicity network period (cqiPerNp), drxLongCycle, and drxOnDuratT parameters. It is recommended to always set the drxOnDuratT smaller than the drxShortCycle parameter. When RI reporting is enabled together with DRX, it is recommended to set the drxOnDuratT parameter greater than 1 to avoid potential TA issues and dropping CQI/PMI reports by the UE. The duration of the short DRX cycle should be smaller than the duration of the long DRX cycle to allow optimum UE power consumption, except the case of VoIP calls, where it is recommended to set the short cycle equal to the long cycle, see also Table 22: Recommended settings for smart DRX profiles. The short DRX cycle should obey the following rules: • •

drxShortCycle < 1/12 s for drxOnDuratT < cqiPerNp ceil(drxOnDuratT / cqiPerNp) * floor(1000 ms / drxShortCycle) >= 12 for drxOnDuratT >= cqiPerNp

In other words, at least 12 CQI reports have to be derived during 1 s to assure reliable TA estimation. The drxShortCycleT parameter is defined by 3GPP with the range {1, 2, ..., 16} (for more information, see 3GPP 36.321). For this reason, if drxLongCycle / drxShortCycle > 16, then drxShortCycleT is set to 16. Table 22: Recommended settings for smart DRX profiles presents the summary of recommended default values for the smart DRX profile parameters.

56

© 2016 Nokia

DN09185967 Issue: 01M


Table 22

Recommended settings for smart DRX profiles

drx drxP Sm rofil art eInd Pro ex file

drxLon gCycle

2

20

6

20

1

4

4

124

40

6

40

1

4

4

124

40

6

20

10

10

4

10

80

6

40

5

10

4

6

160

10

80

4

50

16

4

320

10

80

4

50

16

4

640

10

80

8

50

16

8

1280

10

80

16

50

16

16

2560

10

80

16

50

16

32

3

4

5

4.5.1.4


2

3

4

5

[ms]

drxOnD uratT

drxSho drxSh drxIna drxRetr smartS rtCycle ortCyc ctivityT ansT tInactF leT actor [no. of [ms] [no. of [no. of subfram subfra subfra es] mes] mes]

System impact Interdependencies between features The LTE585: Smart DRX feature depends on the following features: •

• •

LTE42: Support of DRX in RRC Connected Mode - introduces basic support for DRX operation in RRC_Connected state. This feature is a prerequisite for LTE585: Smart DRX. LTE473: Extended DRX Settings - extends basic support for DRX operation in RRC Connected state. This feature is a prerequisite for LTE585: Smart DRX. LTE495: OTDOA - imposes restrictions on the range of DRX-related drxOnDuratT parameter.

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.

DN09185967 Issue: 01M

© 2016 Nokia

57


4.5.1.5


LTE585: Smart DRX 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 23: New parameters lists parameters introduced with this feature.

Table 23

New parameters Full name

Abbreviated name

Managed object

Structure

Activate smart DRX

actSmartDrx

LNCEL

-

DRX smart profile 2

drxSmartProfile2

SDRX

-

DRX inactivity timer

drxInactivityT

SDRX

drxSmartProfile2

DRX long cycle

drxLongCycle

SDRX

drxSmartProfile2

DRX on duration timer

drxOnDuratT

SDRX

drxSmartProfile2

DRX profile index

drxProfileIndex

SDRX

drxSmartProfile2

DRX profile priority

drxProfilePriority

SDRX

drxSmartProfile2

DRX retransmission timer

drxRetransT

SDRX

drxSmartProfile2

DRX short cycle

drxShortCycle

SDRX

drxSmartProfile2

DRX short cycle timer

drxShortCycleT

SDRX

drxSmartProfile2

Short term inactivity factor for smart DRX

smartStInactFactor

SDRX

drxSmartProfile2

DRX smart profile 3

drxSmartProfile3

SDRX

-


drxInactivityT

SDRX

drxSmartProfile3

DRX long cycle

drxLongCycle

SDRX

drxSmartProfile3


drxOnDuratT

SDRX

drxSmartProfile3

DRX profile index

drxProfileIndex

SDRX

drxSmartProfile3

58

© 2016 Nokia

DN09185967 Issue: 01M


Table 23


New parameters (Cont.) Full name

Abbreviated name

Managed object

Structure


drxProfilePriority

SDRX

drxSmartProfile3


drxRetransT

SDRX

drxSmartProfile3

DRX short cycle

drxShortCycle

SDRX

drxSmartProfile3


drxShortCycleT

SDRX

drxSmartProfile3


smartStInactFactor

SDRX

drxSmartProfile3

DRX smart profile 4

drxSmartProfile4

SDRX

-


drxInactivityT

SDRX

drxSmartProfile4

DRX long cycle

drxLongCycle

SDRX

drxSmartProfile4


drxOnDuratT

SDRX

drxSmartProfile4

DRX profile index

drxProfileIndex

SDRX

drxSmartProfile4


drxProfilePriority

SDRX

drxSmartProfile4


drxRetransT

SDRX

drxSmartProfile4

DRX short cycle

drxShortCycle

SDRX

drxSmartProfile4


drxShortCycleT

SDRX

drxSmartProfile4


smartStInactFactor

SDRX

drxSmartProfile4

DRX smart profile 5

drxSmartProfile5

SDRX

-


drxInactivityT

SDRX

drxSmartProfile5

DRX long cycle

drxLongCycle

SDRX

drxSmartProfile5


drxOnDuratT

SDRX

drxSmartProfile5

DRX profile index

drxProfileIndex

SDRX

drxSmartProfile5


drxProfilePriority

SDRX

drxSmartProfile5


drxRetransT

SDRX

drxSmartProfile5

DRX short cycle

drxShortCycle

SDRX

drxSmartProfile5


drxShortCycleT

SDRX

drxSmartProfile5

DN09185967 Issue: 01M

© 2016 Nokia

59


Table 23


New parameters (Cont.) Full name

Abbreviated name


smartStInactFactor

Managed object

Structure

SDRX

drxSmartProfile5

There are no modified parameters related to this feature. Table 24: Related existing parameters lists existing parameters related to this feature. Table 24


Full name

Abbreviated name

Managed object

Structure

Activate DRX

actDrx

LNCEL

-

PRS activation

actOtdoa

LNCEL

-

Apply UL out-of-sync state

applyOutOfSyncState

DRX

-

CQI periodicity network period

cqiPerNp

MPUCCH

-

DRX profile 1

drxProfile1

DRX

-

DRX profile index

drxProfileIndex

DRX

drxProfile1


drxProfilePriority

DRX

drxProfile1

4.5.1.6 Table 25

Sales information

Sales information

BSW/ASW



Activated by default

ASW

-

-

No

4.5.2 Activating LTE585: Smart DRX Before you start Restart of the eNB is not required after activation of this feature. The Activate smart DRX (actSmartDrx) parameter is used to activate the feature. The following parameters are used to perform an additional configuration of the feature: • •

60

Apply UL out-of-sync state (applyOutOfSyncState) CQI periodicity network period (cqiPerNp)

© 2016 Nokia

DN09185967 Issue: 01M


• • • • •

DRX DRX DRX DRX DRX


profile 1 (drxProfile1) set of parameters smart profile 2 (drxSmartProfile2) set of parameters smart profile 3 (drxSmartProfile3) set of parameters smart profile 4 (drxSmartProfile4) set of parameters smart profile 5 (drxSmartProfile5) set of parameters

The following features need to be activated/configured before activation of LTE585: Smart DRX: • •

LTE42: Support of DRX in RRC Connected Mode LTE473: Extended DRX Settings

When the LTE495: OTDOA feature is activated, it imposes restrictions on the range of DRX-related drxOnDuratT parameter. Procedure 1


2

Set the activation flag. a) b) c) d)

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Select the LNCEL object corresponding to the cell where the LTE585: Smart DRX feature will be activated. e) Set the Activate smart DRX (actSmartDrx) parameter value to true.

g 3

Note: This parameter activates the feature.

Define DRX profiles (optional) a) In the Radio Network Configuration page expand the MRBTS object. b) Expand the LNBTS object. c) Expand the LNCEL object corresponding to the cell where the LTE585: Smart DRX feature is/will be activated. d) Configure DRX profiles (DRX profile 1, DRX smart profile 2, DRX smart profile 3, DRX smart profile 4, DRX smart profile 5) performing the following steps: 1. Under the LNCEL ► DRX object, expand the DRX profile 1 and set all parameters within the selected profile.

DN09185967 Issue: 01M

© 2016 Nokia

61



2. Under the LNCEL ► SDRX object, set all parameters related to DRX smart profile 2, DRX smart profile 3, DRX smart profile 4, and DRX smart profile 5.

4

Perform additional configuration of the LTE585: Smart DRX feature (optional) Sub-steps a)


b) Expand the MRBTS object.

c)

d)

e)

f)


Select the LNCEL object corresponding to the cell where the LTE585: Smart DRX feature is/will be activated.

Under the LNCEL object navigate to the DRX object and set the Apply UL out-of-sync state (applyOutOfSyncState) parameter value.

Under the LNCEL object navigate to the MPUCCH object and set the CQI periodicity network period (cqiPerNp) parameter.

Expected outcome The LTE585: Smart DRX feature is activated in the cell. UEs that support smart DRX are configured with smart DRX profiles either at DRX setup or during the next DRX reconfiguration.

4.5.3 Deactivating LTE585: Smart DRX Before you start Restart of the eNB is not required after deactivation of this feature. The Activate smart DRX (actSmartDrx) parameter is used to deactivate the feature.

62

© 2016 Nokia

DN09185967 Issue: 01M



Procedure 1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Expand the LNBTS object. c) Select the LNCEL object corresponding to the cell where the LTE585: Smart DRX feature will be deactivated. d) Set the Activate smart DRX (actSmartDrx) parameter value to false.

g

Note: This parameter deactivates the feature.

Expected outcome The LTE585: Smart DRX feature is deactivated in the cell.

4.6 LTE786: Flexible UL Bandwidth 4.6.1 Description of LTE786: Flexible UL Bandwidth Introduction to the feature This feature defines the area at the borders of uplink (UL) band where neither physical uplink shared channel (PUSCH) nor physical uplink control channel (PUCCH), and physical random access channel (PRACH) are allocated to user equipment (UE). The method is compliant with Rel-8 and it is called PUCCH blanking.

4.6.1.1

Benefits End-user benefits The end-user might experience a decreased peak throughput because of limited number of physical resource blocks (PRBs) on PUSCH. Operator benefits PUCCH Blanking can be used for: • • •

DN09185967 Issue: 01M

reducing the effective UL bandwidth below a nominal UL bandwidth (for example, 8.5 MHz instead of 10 MHz) controlling UE spurious and out-of-band emissions controlling UE self-interference

© 2016 Nokia

63


4.6.1.2



System release



RL50

LBTS5.0

LBTS5.0

Table 26

iOMS

-


UE

NetAct

MME

SAE GW

3GPP R8 mandatory

-

-

-


4.6.1.3

Functional description Functional overview The evolved node B (eNB) supports PUCCH blanking by not allocating resources to the outer PRBs. The purpose of this feature is to define an empty radio frequency (RF) area where neither PUSCH nor PUCCH, and PRACH resources are allocated to any UE (as it is presented in Figure 4: Flexible UL bandwidth). Figure 4

Flexible UL bandwidth

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

Blankedarea

PUCCH area

PUCSHresources

The “blanked” RF area is symmetrical with respect to the given system bandwidth center.The operator sets the PUCCH bandwidth for CQI (nCqiRb) parameter so that it reserves more PUCCH resources dedicated to channel quality indicator (CQI) than actually will be used. By means of the Blanked PUCCH resources (blankedPucch) parameter, the operator defines how many PRBs have to be blanked from the nCqiRb set.CQI allocation algorithm uses the number of PRBs defined by blankedPucch as an offset for the calculation of the correct starting allocation of the CQI resources to all incoming UEs. In other words, the CQI algorithm allocates resources for PUCCH Format 2.x in the range defined by the following formula:

blankedPucch … (nCqiRb - 1) Table 27: Range of the blankedPucch presents the range of the blankedPucch parameter in relation to the Uplink channel bandwidth (ulChBw) parameter.

64

© 2016 Nokia

DN09185967 Issue: 01M


Table 27


Range of the blankedPucch

ulChBw

range of blankedPucch

1.4 MHz

0

3 MHz

0

5 MHz

0 - 16

10 MHz

0 - 30

15 MHz

0 - 40

20 MHz

0 - 60

An example of the LTE786: Flexible UL Bandwidth feature configuration for 10 MHz ulChBw set to 10 MHz - is presented in Figure 5: Example of the Flexible UL Bandwidth configuration. The nCqiRb parameter is set to 20, while the blankedPucch parameter is set to 16. In this configuration, the space left for PUSCH is 24 PRBs. The allocation of PUCCH format 1.x starts in region 20 (PRB number 10) and allocation of PUCCH format 2.x starts in region 16 (PRB number 8). Figure 5

Example of the Flexible UL Bandwidth configuration

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

0 2 4 6 8 10 12 14 16 18 20 22 24

25 23 21 19 17 15 13 11 9 7 5 3

1 3 5 7 9 11 13 15 17 19 21 23 25

24 22 20 18 16 14 12 10 8 6 4 2 0

1

TotalPUSCHarea:24PRBs

Blankedzone AreareservedfornCqiRb PUCCHFormat1.xarea

g

Note: The operator must verify whether the difference nCqiRb - blankedPucch is according to the effective number of CQI resources that need to be allocated to CQI periodic report. The greater number of blanked PRB resources, the less space is left for PUSCH and as a consequence, the greater impact on the sounding reference signal (SRS) capacity. The number of blanked PUCCH resources is operator-configurable and has to be done manually. There is no consistency check with other features, so the proper configuration is very important. The operator has to consider the SRS configuration to avoid the situation when the SRS signal should be sent within the blanked PUCCH RF area (the uplink scheduler does not allocate any resource there).

g

Note: The operator has to ensure that the configuration of the Flexible UL Bandwidth provides a minimum of PUSCH resources for the scheduling of Random Access Procedure Msg3. For this purpose, a maximum expansion of the PUCCH Format 1.x area shall be restricted in configuration so that at least one PUSCH PRB is available during the subframe the PRACH is scheduled.

DN09185967 Issue: 01M

© 2016 Nokia

65



The maximum expansion of the PUCCH Format 1.x area is provided by the resources which are configured for the dynamic HARQ ACK/NACK resources. The need for and the number of PRBs which have to be spent for dynamic HARQ ACK/NACK resources varies, depending on the deployment scenario, and may lead to a restricted number of PUSCH resources. As an example for such a network deployment, the configurations is mentioned which provides for a 5 MHz bandwidth systems carrier aggregation in DL. If for such a configuration the blanked area is expanded to its maximum and the dynamic HARQ ACK/NACK resources are configured extensively, the remaining resources could become insufficient to allow the UEs to successfully attach due to a lack of PUSCH resources. This has to be prevented by an appropriate PUCCH configuration. The O&M-configured physical random access channel (PRACH) resources can be allocated at the center of the band between the two PUCCH areas - the PRACH frequency offset (prachFreqOff) parameter is adjusted accordingly. PUCCH blanking leads to a degradation of the achievable uplink peak rate and the UL cell throughput. The simulations show that the actual throughput loss is a bit higher than the percentage of PRBs unavailable because of PUCCH blanking. This is because the uplink scheduler has less flexibility in resource allocation and some PRBs are in fact left empty.

g

Note: In the operator’s network, the configuration of the blanked PRBs region has to be the same for all cells that have the same E-UTRA Operating Band, the same channel bandwidth (BW), and the same center carrier frequency (that is, the same Transmission BW configuration according to 3GPP 36.104 definition). The operator has to assure the correctness of the configuration. The automatic check is not introduced for this feature. SRS configuration Starting from RL40, there are several sets of SRSes available for each system bandwidth. Each set comprises of one wideband and one lowband SRS configuration. PUCCH blanking in Configuration 1 and Configuration 2 (24 SRS bandwidth) for 5 MHz system bandwidth is not possible. Main aim of Flexible UL Bandwidth The LTE786: Flexible UL Bandwidth feature allows LTE deployment in the presence of another system in the adjacent band. When there is insufficient number of available frequency resources, the configuration of this feature allows LTE deployment with narrower spacing (for more information, see Figure 6: Benefits of Flexible UL Bandwidth). Reduced bandwidth gives also more flexibility in refarming scenarios.

66

© 2016 Nokia

DN09185967 Issue: 01M


Figure 6


Benefits of Flexible UL Bandwidth Requiredcarrier-to-carrierspacing(ULbands)

LTE5Mhz

WCDMA5Mhz LTE786

Deploymentspacingpossiblewithnarrowerspacing

4.6.1.4

System impact Interdependencies between features When the LTE46: Channel Aware Scheduler (UL) feature is activated, the operator has to ensure that SRS does not overlap with blanked PRBs. 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 impacts system performance and capacity as follows: • • •

4.6.1.5

degrades the achievable uplink peak rates limits the uplink cell throughput some configurations of Flexible UL Bandwidth lead to decreasing the maximum number of connected UEs in the cell

LTE786: Flexible UL Bandwidth 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

DN09185967 Issue: 01M

© 2016 Nokia

67



Table 28: Related existing counters lists existing counters related to this feature. Table 28

Related existing counters

Counter ID

Counter name

Measurement

M8011C47

PRB used UL total

8011 - LTE Cell Resource (WBTS)

M8011C49

PRB used PUCCH

8011 - LTE Cell Resource (WBTS)

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

New parameters

Full name

Abbreviated name

Managed object

Maximum number of PRBs assigned in uplink

redBwMaxRbUl

LNCEL

Minimum number of PRBs assigned in uplink

redBwMinRbUl

LNCEL

Enable restricted PRB assignment in uplink

redBwRpaEnUl

LNCEL

Blanked PUCCH resources

blankedPucch

LNCEL



Full name

68

Abbreviated name

Managed object

Uplink channel bandwidth

ulChBw

LNCEL

PUCCH bandwidth for CQI

nCqiRb

LNCEL

© 2016 Nokia

DN09185967 Issue: 01M


4.6.1.6



Sales information

BSW/ASW



ASW

-

-

4.6.2 Activating LTE786: Flexible UL Bandwidth Before you start Restart of the eNB is required after activation of this feature only if the Uplink channel bandwidth (ulChBw) parameter value is changed. The Blanked PUCCH resources (blankedPucch) parameter is used to activate the feature. The following parameters are used to perform an additional configuration of the feature: • • • • •

PUCCH bandwidth for CQI (nCqiRb) Maximum number of PRBs assigned in uplink (redBwMaxRbUl) Minimum number of PRBs assigned in uplink (redBwMinRbUl) Enable restricted PRB assignment in uplink (redBwRpaEnUl) Uplink channel bandwidth (ulChBw)

Procedure 1


2

Go to the LTE Carriers page (optional). a) To change the Uplink channel bandwidth (ulChBw) parameter, in the table Downlink (TX) carriers, change the Downlink channel bandwidth (dlChBw) parameter. Change also the relevant EARFCN value. The Uplink channel bandwidth (ulChBw) parameter will be filled in automatically.

3

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Expand the LNBTS object. c) Select the LNCEL object corresponding to the cell where the LTE786: Flexible UL Bandwidth feature will be activated.

DN09185967 Issue: 01M

© 2016 Nokia

69



d) Set the Blanked PUCCH resources (blankedPucch) parameter to any value other than 0.

g

Note: This step activates the feature. e) Set the PUCCH bandwidth for CQI (nCqiRb) parameter. f) Set the Maximum number of PRBs assigned in uplink (redBwMaxRbUl) parameter. g) Set the Minimum number of PRBs assigned in uplink (redBwMinRbUl) parameter. h) Set the Enable restricted PRB assignment in uplink (redBwRpaEnUl) parameter.

Expected outcome The LTE786: Flexible UL Bandwidth feature is activated and PUSCH and PUCCH resources are no longer allocated to the blanked areas.

4.6.3 Deactivating LTE786: Flexible UL Bandwidth Before you start Restart of the eNB is not required after deactivation of this feature. Procedure 1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Expand the LNBTS object. c) Select the LNCEL object corresponding to the cell where the LTE786: Flexible UL Bandwidth feature will be deactivated. d) Set the Blanked PUCCH resources (blankedPucch) parameter to value 0.

g

Note: This step deactivates the feature.

Expected outcome PUCCH blanking is deactivated.

70

© 2016 Nokia

DN09185967 Issue: 01M



4.7 LTE907: TTI Bundling 4.7.1 Description of LTE907: TTI Bundling Introduction to the feature The LTE907: TTI Bundling feature allows transmitting a single transport block in space of four consecutive UL subframes, which leads to increased energy per transmitted bit and therefore, improved uplink link budget. More robust transmission scheme leads to reduction of PDCCH traffic.

4.7.1.1

Benefits End-user benefits TTI bundling is intended mainly for UEs at cell border with active VoIP (QCI1) services. This feature improves the uplink coverage and reduces latency caused by multiple adaptive HARQ retransmissions. Operator benefits In case of poor radio condition, the LTE907: TTI Bundling feature reduces PDCCH traffic by preventing from packet segmentation and because of fewer adaptive HARQ retransmissions. Fewer HARQ retransmissions leads to latency reduction. Bundling of TTIs enhances the uplink coverage. One transport block is allocated to four TTIs instead of one TTI, that is, the energy per transmitted bit is increased.

4.7.1.2

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

g


System release



RL50

-

LBTS5.0

iOMS

-

UE

NetAct

MME

SAE GW

3GPP R8 UE capabilities

-

-

-

Note: The LTE907 feature was introduced in RL50 SW release. The configuration of the feature from RL50 to FDD-LTE15A release is described in the first version of the LTE907: TTI Bundling document. The present, second version of the document, describes the new configuration from SW release FDD-LTE16 onwads.

DN09185967 Issue: 01M

© 2016 Nokia

71




4.7.1.3

Functional description Functional overview TTI bundling (known also as PUSCH bundling or subframe bundling) is designed to improve uplink performance of UEs at cell edge. These UEs often hit the maximum transmission power; nevertheless, because of poor radio conditions, the signal received by the eNB is getting worse. In this case, the eNB triggers TTI bundling activation. In TTI bundling mode, UL transport block (MAC PDU), consisting of Turbo coded data and redundancy information, is divided into four "redundancy versions" that are subsets of the PDU, taken from different offset positions, and partly overlapping each other. In TTI bundling mode, one UL grant triggers the transmission of one TTI bundle. The TTI bundle consists of all four redundancy versions, in sequence rv0, rv2, rv3, rv1. The TTI bundle is sent in four successive TTIs, using a fixed number of 3 PRBs. Redundancy and overlaps lead to increased energy per transmitted bit and therefore, improved UL link budget (for more information on differences between TTI bundling mode and normal operation mode, see Figure 7: Normal operation mode and Figure 8: TTI bundling mode). The eNB gives only one uplink grant for the bundle, which means that the grant is given just for the first uplink subframe of the bundle, and the UE performs nonadaptive HARQ retransmissions in next three UL subframes. The result of the more robust transmission scheme is that PDCCH load is reduced. Figure 7

Normal operation mode

NormalMode GrantonPDCCH

DataonPUSCH

ACK/NACKonPHICH

Figure 8

TTI bundling mode

TTIBundlingMode GrantonPDCCH

DataonPUSCH

ACK/NACKonPHICH

The UE expects only one ACK/NACK from the eNB that applies to a whole TTI bundle (for more information on normal operation vs. TTI bundling HARQ retransmissions, see Figure 9: HARQ retransmission in normal operation mode and Figure 10: HARQ retransmission in TTI bundling mode). ACK/NACK timing is always related to that TTI, in which the fourth subframe in a bundle is due for transmission. As can be observed in Figure 10: HARQ retransmission in TTI bundling mode, after the initial transmission and three consecutive non-adaptive HARQ retransmissions, assuming 1 ms for transmission

72

© 2016 Nokia

DN09185967 Issue: 01M



and 3 ms for decoding and processing, the eNB sends HARQ feedback in subframe number 7. To make TTI bundling synchronized with normal operation mode, the first adaptive HARQ retransmission (if it is needed) is done in subframe number 16. Figure 9

RV0 0 1 0 1

HARQ retransmission in normal operation mode

RV1 2 3 4 5 6 7 0 1

RV2 2 3 4 5 6 7 0 1

2 3 4 5 6 7

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

NACK

NACK

Initialtransmission

Figure 10

ACK

AdaptiveHARQ retransmission

HARQ retransmission in TTI bundling mode

RV0 2 3 1 RV2 2 3 1 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 0 0 0 0 1 1 1 1 0 1

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

ACK

NACK

Initialtransmission

AdaptiveHARQ retransmission

Non-AdaptiveHARQ retransmission

TTI bundling allows allocation of one transport block in UL in three PRBs. The modulation scheme is restricted to QPSK. In TTI bundling mode, the UE has a limited UL rate and longer HARQ round-trip-time (RTT), therefore the LTE907: TTI Bundling feature is reasonable only for low data rate. Higher redundancy provided for the data in a TTI bundle improves the eNB's chances to decode correctly the bundle without triggering further retransmissions. Although TTI bundling is not restricted to a particular service type, the main use case foreseen is UEs with active VoIP (QCI1) service. The eNB applies TTI bundling only for UEs with the related UE capabilities. The UEs that do not support TTI bundling are handled with other coverage extension methods like segmentation (for more information, see LTE571: Controlled Uplink Packet Segmentation) or setting higher maximum number of HARQ retransmission (this has to be done manually by the operator via Maximum number of HARQ transmission in UL - ). TTI bundling start/stop There are two ways, the BLER and SINR-based, to change TTI bundling mode: •

DN09185967 Issue: 01M

In the BLER-based method (the ttibOperMode parameter is set to any BLERbased value), the eNB moves the UE to TTI bundling mode in two steps. In the first one, if the UE transmits with the lowest possible MCS index defined by the

© 2016 Nokia

73



Extended uplink link adaptation low MCS threshold (eUlLaLowMcsThr) parameter, the eNB starts the BLER measurements for this UE. In the second step, all of the following three conditions have to be met to trigger TTI bundling: –

–

–

The UE transmits with Minimum UL transport block size (ulsMinTbs), or it reaches the minimum PRB allocation for UEs which are power-limited, defined by the Minimum PRB allocation for UEs which are power limited (ulsMinRbPerUe) parameter. The UE transmits with the lowest possible MCS index defined by the eUlLaLowMcsThr parameter (for more information on the configuration of this parameter, see LTE1034: Extended Uplink Link Adaptation). The current BLER is above the TTI bundling BLER threshold (ttiBundlingBlerThreshold) parameter value.

In the BLER-based method the eNB initiates moving the UE into the normal mode if the UE is in TTI bundling mode, the current UL SINR is better than the last known SINR in normal mode, and the average UL SINR exceeds TTI bundling SINR threshold (ttiBundlingSinrThreshold) + standard deviation of the SINR measurement.

g

Note: If radio condition is unstable, then the standard deviation is higher (the threshold becomes higher). In other words, when radio condition is unstable, it is harder for the UE to move back from TTI bundling to normal operation mode. •

In the SINR-based method (the ttibOperMode parameter is set to any SINRbased value), the UL SINR samples (which are taken from an initial PUSCH transmissions) are constantly checked, and the SINR threshold for entering TTI bundling mode (ttibSinrThresholdIn) parameter determines the threshold for switching UEs from a normal mode into a TTI bundling mode. The measurements to stop TTI bundling are the already ongoing measurements of UL SINR samples. The SINR threshold for leaving TTI bundling mode (ttibSinrThresholdOut) parameter determines the threshold for switching UEs from a TTI bundling mode into a normal mode.

There is no O&M parameter available that would limit the number of UEs that are switched into TTI bundling mode. Therefore, it is possible that all UEs in the cell (if other conditions are fulfilled) are in TTI bundling mode. A restriction is possible for the number of activated QCI1 bearers in the cell, through the Max number QCI1 DRBs (GBRs) (maxNumQci1Drb) parameter. The eNB dynamically starts/stops TTI bundling per UE with the RRC:RRCConnectionReconfiguration message. The RRC connection reconfiguration is performed as a part of an intra-cell handover to ensure that the UE and the eNB are synchronized (for more information on intra-cell handovers, see LTE511: Intra Cell Handover). The TTI bundling operation mode (ttibOperMode) parameter can be chosen such that TTI bundling mode changes are not dependent on measurement gap configuration. Any configured limitations apply only to measurement gaps for handover preparation (so, not for automatic neighbour relation (ANR) or reference signal time difference (RSTD) measurement gaps).

74

© 2016 Nokia

DN09185967 Issue: 01M



The eNB considers UEs for TTI bundling that have at least one active bearer with the Enforce TTI bundling (enforceTtiBundling) parameter set to true. Once the UE is in TTI bundling mode, then all its PUSCH traffic is done in TTI bundles. When the last remaining bearer that enforces TTI bundling is released, the UE is switched from TTI bundling mode into the normal mode. Link adaptation in TTI bundling mode In TTI bundling mode the number of PRBs allocated to the UE is fixed to three. Link adaptation (LA) in TTI bundling mode consists only of an algorithm that allocates appropriate MCS index, however, the modulation order is limited to 2 (QPSK). The default setting of the Minimum UL transport block size (ulsMinTbs) parameter is 104 and the LA can use TBS_index (I_TBS) range from 2 to 17. Further limitations to the range of MCS values do not apply to TTI bundling mode. This is necessary because in TTI bundling mode, the table entries are taken as the transport block sizes of the whole TTI bundle. Each TTI bundle consists of 12 resource blocks (3 PRBs * 4 TTIs). Assuming 2 symbols for PDCCH, 12*12 symbols are available in each PRB for reference symbols and payload, and 2 bits per symbol are used because of QPSK modulation. This means that in theory ( ignoring the reference symbols or DTX inserted into each PRB), the TBS of a bundle could go up to 12*12*12*2 = 3456 bits for coderate = 1. In the LTE907: TTI Bundling implementation size of TBS of the bundle is limited to 1608. MCS24 is the upper limit in to keep TTI bundling implementation consistent with the current maximum MCS24 in normal mode. It is not expected to see such high I_TBS (MCS) values in the field because such good radio conditions would much earlier lead to transition into normal mode. Table 33: TBS table shows number of PRBs in relation to the chosen MCS. Table 33

TBS table

MCS

I_TBS

Qm

nonbundling

N_PRB

bundling

3

0

0

2

2

56

1

1

2

2

88

2

2

2

2

144

3

3

2

2

176

4

4

2

2

208

5

5

2

2

224

6

6

2

2

256

7

7

2

2

328

DN09185967 Issue: 01M

© 2016 Nokia

75


Table 33


TBS table (Cont.)

MCS

I_TBS

Qm

nonbundling

N_PRB

bundling

3

8

8

2

2

392

9

9

2

2

456

10

10

2

2

504

11

10

4

2

504

12

11

4

2

584

13

12

4

2

680

14

13

4

2

744

15

14

4

2

840

16

15

4

2

904

17

16

4

2

968

18

17

4

2

1064

In the TTI bundling mode, the mechanism of MCS adjustment works in the same way as in a normal mode, however, with a dedicated BLER target defined by the TTI bundling BLER target (ttiBundlingBlerTarget) parameter. CQI/PMI/RI reports When the UE is in TTI Bundling mode, it drops the periodic CQI/PMI/RI reports on PUCCH if they collide with the TTI Bundle (the periodic reports are not multiplexed with the TTI Bundle). Otherwise, the UE transmits periodic reports to the eNB via PUCCH as usual. When the UE is In TTI Bundling mode, the eNB requests aperiodic CQI with each UL grant. CQI/PMI/RI reports are included in the first TTI of the bundle and the UE does not transmit any report in the remaining three TTIs of the bundle. Bearer management and admission control TTI Bundling operates in uplink direction. UEs are switched into TTI bundling if the radio conditions have deteriorated so that BLER or SINR threshold has been exceeded and available power is insufficient for transmission on more than just a few PRBs (for more information, see TTI bundling start/stop). The eNB configuration related to the UE’s bearer setup is done without respect to TTI bundling. The eNB bearer management

76

© 2016 Nokia

DN09185967 Issue: 01M



functions are not aware of the current radio conditions, and therefore admission control operates irrespective of whether or not the UE is in good or bad radio conditions. In particular, this also means that admission control operates without consideration of whether or not UEs are in TTI bundling mode. The main purpose of TTI bundling is to improve link quality for VoIP users at the cell edge. The operators can define which QCI classes are allowed for use of TTI bundling mode. The range of QCIs contains predefined classes and also operator-defined classes (for more information, see LTE518: Operator Specific QCI feature). The selection is done by setting the Enforce TTI bundling (enforceTtiBundling) to true in the QCI translation table QCI (qciTab) parameter and/or the QCI translation table operator specific QCIs (qciTabOperator) parameter. It is assumed that the operator sets the enforceTtiBundling parameter to true only for QCI1 bearers and/or the operator-defined bearers with similar throughput and quality demands as required by the voice transmission. With the following assumptions: • • •

adverse radio conditions TBS = 144 bits (and for the sake of this coarse estimation that this includes 100 bits of user data) the UE transmits in every scheduling occasion (5 UL grants per 2 radio frames)

the maximum throughput expectable in TTI bundling mode is 25 kbit/s. If the UE is scheduled once per 2 radio frames (that is, once per 20 ms), this boils down to ~ 5 kbit/s. If the UE: 1. is configured with a QCI1 bearer of a high bit rate 2. encounters bad radio conditions 3. runs into power limitation then the UL throughput is limited by the UE which represents the bottleneck. In this case, the eNB neither deletes any bearer whose throughput does not meet configured maximum/average rates nor prioritizes any bearer over others. It is the UE where UL prioritization takes place, and it is left to the UE software (or to the end-user) to delete bearers (or to close applications) that suffer from bad radio conditions to an unacceptable degree.

4.7.1.4

System impact Interdependencies between features The following features are prerequisites for LTE907: TTI Bundling activation: •

LTE511: Intra Cell Handover - the eNB uses intra-cell handover procedure to switch to/from TTI bundling mode.

The following features interwork with LTE907: TTI Bundling: •

•

DN09185967 Issue: 01M

LTE571: Controlled Uplink Packet Segmentation - Only UEs in coverage-limited area that use code point (MCS index and TBS) determined by this feature are considered for TTI bundling. LTE518: Operator specific QCI - The operator can extend the standardized QCIs with additional 21 non-GBR QCIs. The additional QCIs can be configured to be used with or without TTI bundling.

© 2016 Nokia

77


•

•


LTE519: eRAB modification - The operator can change the QCI and ARP of an eRAB and UE AMBR. The QCI configuration data also determines whether TTI bundling mode can be used for a UE with a given set of bearers. LTE1638: Inter-frequency RSTD measurement support - the Flexi Multiradio BTS supports the user equipment-reference signal time difference (UE-RSTD) interfrequency measurements for observed time difference of arrival (OTDOA).

The following features are affected when the LTE907: TTI Bundling feature is activated: •

• •

•

•

LTE7: Support of Multiple EPS Bearer and LTE9: Service Differentiation - The packet scheduler does not check or limit the rates of non-GBR bearers configured to use TTI bundling mode. LTE10: EPS bearers for conversational voice - TTI bundling is activated for coverage-limited UEs, and is mainly a use case for UEs with active voice bearer. LTE1034: Extended Uplink Link Adaptation - this feature can be activated only if actUlLnkAdp parameter is set to eUlLa or fUlLa and cellResourceSharingMode parameter is set to none or DLonly. LTE1382: Cell resource groups - this feature can be activated only when Cell resource sharing mode (cellResourceSharingMode) parameter is set to none or DLonly. During TTI bundle mode, the behavior of packet scheduler is modified. It assigns four consecutive subframes for the same transport block, using the same resource allocation as given in the first subframe of the bundle. This change affects the following packet scheduler features: – –

•

•

g

LTE46: Channel aware scheduler (UL) LTE619: Interference aware UL scheduling

LTE735: RRC Connection Re-establishment - If the UE is triggered to start TTI bundling using intra-cell handover, the UE has a radio link failure, and it becomes a candidate for RRC connection re-establishment then after RRC connection reestablishment, the UE assumes the TTI bundling configuration in source cell or in the target cell if the TTI bundling is activated there. LTE782: ANR - UE based - ANR measurements are not done for UEs in TTI bundling mode. Note: The eNB, upon detecting conditions to enable the TTI bundling on a UE, will deconfigure the DRX if configured, and will restore the DRX configuration when the UE is no longer using the TTI bundling mode.

Related features •

LTE2098: VoLTE Uplink Coverage Boosting - this feature improves the uplink coverage by up to 3 dB for UEs in a TTI bundling mode and introduces optimized algorithms for UL link adaptation and receiver functionality.

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

78

© 2016 Nokia

DN09185967 Issue: 01M



In case of poor radio condition, the LTE907: TTI Bundling feature reduces PDCCH traffic by preventing from packet segmentation and because of fewer adaptive HARQ retransmissions. Fewer HARQ retransmissions leads to latency reduction. Bundling of TTIs enhances the uplink coverage. One transport block is allocated to four TTIs instead of one TTI, that is, the energy per transmitted bit is increased.

4.7.1.5

LTE907: TTI Bundling 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 34: New counters lists counters introduced with this feature. Table 34

Counter ID

New counters

Counter name

Measurement

M8011C63

Number of UL grants for TTI Bundling

LTE Cell Resource (WBTS)

M8011C62

Average number of UEs configured for TTI Bundling mode


M8011C66

Long UE retention time in TTI Bundling mode


M8011C65

Medium UE retention time in TTI Bundling mode


M8011C64

Short UE retention time in TTI Bundling mode


There are no modified measurements or counters related to this feature. There are no existing measurements or counters related to this feature. There are counters related to MSC that are not modified but their interpretation is changed for UEs in TTI bundling mode. The following counters are incremented per bundle. They take the MCS of the bundle even though in TTI bundling the modulation scheme is always QPSK: • • •

DN09185967 Issue: 01M

M8001C16 - M8001C40 (PUSCH transmissions using MSCXX): The number of transmissions on PUSCH over the measurement period using MCSXX. M8001C435 - M8001C459 (First transmissions on PUSCH using MCSXX): The number of first transmissions on PUSCH for used Modulation and Coding Scheme. M8001C74 - M8001C98 (PUSCH transmission nacks using MCSXX): The number of unacknowledged transmissions on PUSCH using MCSXX.

© 2016 Nokia

79


•

•


M8001C460 - M8001C484 (First transmission NACKs on PUSCH using MCSXX): The number of not acknowledged 1st transmissions on PUSCH for used Modulationand Coding Scheme. M8001C177 - M8001C197 and M8001C485 - M8001C488 (Failed Reception PUSCH MCSXX): The number of unsuccessful receptions on PUSCH using MCS0 Modulation and Coding Scheme. Only not transmitted TB's exceeding max HARQ retransmissions are considered.

where XX is from 0 to 24. Key performance indicators There are no key performance indicators related to this feature. Parameters Table 35: New parameters lists parameters introduced with this feature. Table 35

New parameters

Full name

Abbreviated name

Managed object

Activate TTI bundling

actTtiBundling

LNCEL

Max number of UL HARQ transmissions during TTI bundling

harqMaxTrUlTtiBundling

LNCEL

TTI bundling BLER target

ttiBundlingBlerTarget

LNCEL

TTI bundling BLER threshold

ttiBundlingBlerThreshold

LNCEL

TTI bundling SINR threshold

ttiBundlingSinrThreshold

LNCEL

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

Modified parameters

Full name

80

Abbreviated name

Managed object

Minimum UL transport ulsMinTbs block size

LNCEL

Enable all TBs in UL AMC

ulamcAllTbEn

LNCEL

UL AMC target BLER

ulTargetBler

LNCEL

QCI translation table QCI [1... 9]

qciTab[1 ... 9]

LNBTS

Enforce TTI bundling

enforceTtiBundling

LNBTS

© 2016 Nokia

Structure

qciTab[1 ... 9]

DN09185967 Issue: 01M


Table 36


Modified parameters (Cont.)

Full name

Abbreviated name

Managed object

QCI translation table qciTabOperator operator specific QCIs

LNBTS

Enforce TTI bundling

LNBTS

enforceTtiBundling

Structure

qciTabOperator

The QCI translation table QCI [1... 9] (qciTab[1 ... 9]) and QCI translation table operator specific QCIs (qciTabOperator) structures contain more parameters, however, only the Enforce TTI bundling (enforceTtiBundling) is related to the LTE907: TTI Bundling feature. Table 37: Related existing parameters lists existing parameters related to this feature. Table 37


Full name

Abbreviated name

Activate uplink link adaptation

4.7.1.6

actUlLnkAdp



Sales information

BSW/ASW



ASW

-

-

4.7.2 Activating LTE907: TTI Bundling Before you start Restart of the eNB is not required after activation of this feature. The Activate TTI bundling (actTtiBundling) parameter is used to activate the feature. The following parameters are used to perform an additional configuration of the feature: • • • • • •

DN09185967 Issue: 01M

Max number of UL HARQ transmissions during TTI bundling (harqMaxTrUlTtiBundling) TTI bundling BLER target (ttiBundlingBlerTarget) TTI bundling BLER threshold (ttiBundlingBlerThreshold) TTI bundling SINR threshold (ttiBundlingSinrThreshold) Minimum UL transport block size (ulsMinTbs) TTI bundling operation mode (ttibOperMode)

© 2016 Nokia

81


• • • •


SINR threshold for entering TTI bundling mode (ttibSinrThresholdIn) SINR threshold for leaving TTI bundling mode (ttibSinrThresholdOut) Enable all TBs in UL AMC (ulamcAllTbEn) Enforce TTI bundling (enforceTtiBundling) in the QCI translation table operator specific QCIs (qciTabOperator) and the QCI translation table QCI [1... 9] (qciTab[1 ... 9]) structures.

The following parameters might need reconfiguration when the LTE907: TTI Bundling feature is activated: • •

Maximum number of HARQ transmission in UL (harqMaxTxUl) UL AMC target BLER (ulTargetBler)

The following features need to be activated/configured before activation of LTE907: TTI Bundling: LTE1034: Extended Uplink Link Adaptation or LTE1495: Fast Uplink Link Adaptation Procedure 1


2

Set the activation flag. a) b) c) d)

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Select the LNCEL object corresponding to the cell where the LTE907: TTI Bundling feature will be activated. e) Set the Activate TTI bundling (actTtiBundling) parameter value to true.

g 3


Configure the TTI bundling start/stop (optional). a) b) c) d)

82

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Select the LNCEL object corresponding to the cell where the LTE907: TTI Bundling feature start/stop will be configured.

© 2016 Nokia

DN09185967 Issue: 01M



e) Set the Minimum UL transport block size (ulsMinTbs) parameter value. f) Set the TTI bundling BLER threshold (ttiBundlingBlerThreshold) parameter value. g) Set the TTI bundling SINR threshold (ttiBundlingSinrThreshold) parameter value. h) Set the TTI bundling BLER target (ttiBundlingBlerTarget) parameter value.

4

Configure HARQ transmissions (optional). a) b) c) d)

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Select the LNCEL object corresponding to the cell where the HARQ transmissions will be configured. e) Set the Max number of UL HARQ transmissions during TTI bundling (harqMaxTrUlTtiBundling) parameter value.

5

Define the QCI classes which will enforce TTI bundling if corresponding bearers are active (and other TTI Bundling conditions are met). a) b) c) d)

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Under the LNBTS object, perform the following actions on the QCI translation tables corresponding to the QCIs that will be allowed for use of TTI bundling mode: 1. Expand the QCI translation table [QCI 1 .... QCI9, operator specific QCIs] object. 2. Select the QCI translation table [QCI 1 .... QCI9, operator specific QCIs]-1 object. 3. Set the Enforce TTI bundling (enforceTtiBundling) parameter value to true.

6

Perform additional configuration of the TTI bundling mode (optional). a) b) c) d)

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Select the LNCEL object corresponding to the cell where additional configuration of the LTE907: TTI Bundling feature will be done. e) Set the Enable all TBs in UL AMC (ulamcAllTbEn) parameter value.

DN09185967 Issue: 01M

© 2016 Nokia

83


7


Perform reconfiguration of other parameters (optional). Sub-steps a) Go to the Radio Network Configuration page.

b)

c)

d)



Select the LNCEL object corresponding to the cell where the LTE907: TTI Bundling feature is configured.

e) Set the Maximum number of HARQ transmission in UL () parameter value. It has to be less than or equal to the Max number of UL HARQ transmissions during TTI bundling (harqMaxTrUlTtiBundling) parameter.

f)

Set the UL AMC target BLER (ulTargetBler) parameter value. It has to be less than the TTI bundling BLER threshold (ttiBundlingBlerThreshold) parameter.

Expected outcome The LTE907: TTI Bundling feature is available in the cell for all UEs that are compliant and meet one of the following conditions: • • •

The UE is in the RRC_CONNECTED, ECM_CONNECTED state, and either a DRB is set up, released or modified. The UE is in the RRC_CONNECTED state and the initial context setup procedure is triggered. The UE enters the cell by means of handover.

4.7.3 Deactivating LTE907: TTI Bundling Before you start Restart of the eNB is not required after activation of this feature. The Activate TTI bundling (actTtiBundling) parameter is used to deactivate the feature.

84

© 2016 Nokia

DN09185967 Issue: 01M



Procedure 1


2

Set the deactivation flag a) b) c) d)

Go to the Radio Network Configuration page. Expand the MRBTS object. Expand the LNBTS object. Select the LNCEL object corresponding to the cell where the LTE907: TTI Bundling feature will be deactivated. e) Set the Activate TTI bundling (actTtiBundling) parameter value to false.

g


Expected outcome The LTE907: TTI Bundling feature is deactivated in the cell.

4.8 LTE980: IRC for 4 RX Paths 4.8.1 Description of LTE980: IRC for 4 RX Paths Introduction to the feature The Interference Rejection Combining (IRC) is improved mainly for highly loaded and interference limited cells. It improves the uplink (UL) performance of users at cell edge and slightly increases the uplink cell capacity.

4.8.1.1

Benefits End-user benefits Better uplink cell performance can be achieved with IRC. Operator benefits The same as for the end-user benefits: better uplink cell performance can be achieved with IRC.

4.8.1.2


DN09185967 Issue: 01M

© 2016 Nokia

85



System release



RL50

-

LBTS5.0

Table 39

iOMS

-


UE

NetAct

MME

SAE GW

-

-

-

-

Hardware requirements This feature requires Flexi Multiradio 10 BTS to support one, two, or three cells with 5 or 10 MHz bandwidth. Additional cell configurations covered in the LTE1247: Multiradio System Module extended LTE configurations feature are also supported by this feature, however, the LTE1137: Flexi BaseBand Module FBBA feature is then necessary. All RF modules supported by the LTE72: 4-way RX diversity feature are supported by the LTE980: IRC for 4 RX Paths feature.

4.8.1.3

Functional description Functional overview IRC is an equalizer used for diversity combining. The LTE980: IRC for 4 RX Paths feature combines the received signal in such a way that the overall post-equalizer signal to interference and noise ratio is maximized. IRC is an extension to 4-way RX diversity and Maximum Ratio Combining (MRC), (for more information, see LTE72: 4-way RX diversity). IRC equalizer was already implemented for 2 RX (for more information, see LTE979: IRC for 2 RX paths). Interference in a dedicated cell in the UL can occur e.g. from UEs with a different serving cell. Other sources of interference might be spurious emissions of other technologies (GSM, WCDMA, ...). Assuming there are only a few dominant interferers, IRC is a quite good approach to suppress this type of interference. The basic rule of thumb is that the number of RX antennas - 1 dominant interferers can be suppressed. This means, for 4 RX antennas three dominant interferers can be suppressed. This is only a rough rating since also interference from more users can be suppressed but the suppressor gain will decrease very rapidly. If on the other hand the number of interferers is high, then the interference starts to look like Gaussian noise and is no longer favorable for IRC. Supporting IRC is mainly a radio layer 1 issue. IRC is only applied to the physical uplink shared channel (PUSCH). All other channels and signals like physical uplink control channel (PUCCH), sounding reference signal (SRS) and physical random access channel (PRACH) do not apply IRC.

86

© 2016 Nokia

DN09185967 Issue: 01M


g


Note: The LTE980: IRC for 4 RX Paths feature performs the best with GPS synchronization where timing alignment among different cells belong to different eNBs is provided. The LTE980: IRC for 4 RX Paths feature works with the other synchronization schemes where timing alignment among different cells belong to different eNBs is not provided with reduced gain.

4.8.1.4

System impact Interdependencies between features The following features are prerequisites for LTE980: IRC for 4 RX Paths: • •

LTE72: 4-way RX diversity - provides the basic support for 4 RX. LTE1137: Flexi BaseBand Module FBBA - enables pugging FBBA module into the eNB.

The following features are not supported when LTE980: IRC for 4 RX Paths is activated: • • • • • • •

LTE48: Support of High Speed Users LTE117: Cell Bandwidth - 1.4 MHz LTE116: Cell Bandwidth - 3 MHz LTE447: SW Support for RF Sharing GSM-LTE LTE435: WCDMA-LTE RF Sharing Compatibility LTE1195: 3-sector Low Power Repeater Interface SK-RIM LTE1089: Downlink Carrier Aggregation

The following features interact with LTE980: IRC for 4 RX Paths: • •

g

LTE80: GPS Synchronization - a phase-synchronized air interface is required to achieve maximum performance of the IRC receiver. LTE891 Timing over Packet with Phase Synchronization - a phase-synchronized air interface is required to achieve maximum performance of the IRC receiver. Besides Synchronization via GPS, synchronization over packet (Timing over Packet - ToP) is an appropriate synchronization source. Note: Phase synchronization is recommended but not required. Even without phase synchronization LTE980: IRC for 4 RX Paths shows considerable performance improvement.

•

LTE899: Antenna Line Supervision - detects Tx antenna path failure. In case one of the Tx antenna lines gets broken and the eNB L1 receives only Gaussian Noise from this antenna line, the IRC is able to continue its operation.

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

DN09185967 Issue: 01M

© 2016 Nokia

87



This feature has no impact on capacity. With IRC a better uplink cell performance can be achieved.

4.8.1.5

LTE980: IRC for 4 RX Paths 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 new parameters related to this feature. There are no modified parameters related to this feature. lists existing parameters related to this feature. Table 40


Full name

88

Abbreviated name

Managed object

Structure

Uplink combination mode

ulCombinationMode

LNCEL

Resource list

resourceList

LNCEL

Antenna line id

antlId

LNCEL

resourceList

Sub cell identifier

subCellId

LNCEL

resourceList

TX and RX usage

txRxUsage

LNCEL

resourceList

PRACH high speed flag

prachHsFlag

LNCEL

Repeater mode activation

actRepeaterMode

LNCEL

© 2016 Nokia

DN09185967 Issue: 01M


4.8.1.6



Sales information

BSW/ASW



ASW

-

-

4.8.2 Activating LTE980: IRC for 4 RX paths Before you start Restart of the eNB is required after activation of this feature only if at least one parameter of the Resource list (resourceList) set of parameters is changed: The Uplink combination mode (ulCombinationMode) parameter is used to activate the feature. Modification of the Uplink combination mode (ulCombinationMode) parameter requires cell locking. If the LTE830: LTE Automatic Lock feature is active (LNBTS parameter Enable automatic locking (enableAutoLock) is set to enabled) the cell will be automatically locked (if not already in the locked state), otherwise the cell needs to be locked and unlocked manually. The Resource list (resourceList) set of parameters is used to perform an additional configuration of the feature: Required HW configurations can be found in Flexi Multiradio and Multiradio 10 BTS LTE Supported Configurations. The LTE72: 4-way RX Diversity feature needs to be activated and configured before activation of the LTE980: IRC for 4 RX Paths feature. The following features need to be deactivated before activation of the LTE980: IRC for 4 RX Paths feature: • • • • • • •

LTE48: Support of High Speed Users LTE117: Cell Bandwidth - 1.4 MHz LTE116: Cell Bandwidth - 3 MHz LTE447: SW Support for RF Sharing GSM-LTE LTE435: WCDMA-LTE RF Sharing Compatibility LTE1195: 3-sector Low Power Repeater Interface SK-RIM LTE1089: Downlink carrier aggregation - 20 MHz

One of the following features is recommended (but not required) for better performance of the LTE980: IRC for 4 RX Paths feature: • •

DN09185967 Issue: 01M

LTE80: GPS Synchronization LTE891 Timing over Packet with Phase Synchronization

© 2016 Nokia

89



Procedure 1


2

Go to the Radio network configuration page. a) Expand the LNBTS object. b) Select the LNCEL object. c) Set the Uplink combination mode (ulCombinationMode) parameter to IRC.

g

Note: This step activates the feature automatically if four RX antenna lines are configured in the Resource list (resourceList) set of parameters related to the LNCEL object.

Expected outcome The eNB informs the BTS Site Manager about the changed configuration via notifications. The IRC is applied to the physical uplink shared channel (PUSCH).

4.8.3 Deactivating LTE980: IRC for 4 RX paths Before you start Restart of the eNB is not required after activation of this feature. The Uplink combination mode (ulCombinationMode) parameter is used to deactivate the feature. Modification of the Uplink combination mode (ulCombinationMode) parameter requires cell locking. If the LTE830: LTE Automatic Lock feature is active (LNBTS parameter Enable automatic locking (enableAutoLock) is set to enabled) the cell will be automatically locked (if not already in the locked state), otherwise the cell needs to be locked and unlocked manually. Procedure 1


90

© 2016 Nokia

DN09185967 Issue: 01M


2


Go to the Radio network configuration page. a) Expand the LNBTS object. b) Select the LNCEL object. c) Set the Uplink combination mode (ulCombinationMode) parameter to MRC.

g


Expected outcome The MRC is applied to the physical uplink shared channel (PUSCH).

4.9 LTE1036: RSRQ Based Cell Reselection 4.9.1 Description of LTE1036: RSRQ Based Cell Reselection Introduction to the feature RSRQ means reference signal received quality. RSRQ is the ratio of RSRP (reference signal received power) and RSSI (received signal strength indicator). RSSI comprises the linear average of the total received power observed only in OFDM symbols containing reference symbols for antenna port 0, in the measurement bandwidth. Cell selection and reselection procedures are idle mode mobility functions, and therefore completly UE- based, however, the additional parameters are broadcast within the SIBs (System Information Block). The LTE1036: RSRQ Based Sell Reselection feature introduces the required extensions for RSRQ based cell selection and reselection for Rel. 9 UEs onwards.

4.9.1.1

Benefits End-user benefits If the UEs select cells with better RSRQ, the radio connection, if the UE once changes into active mode, is better, as a) the target cell is less interfered and b) the target cell is less loaded. Operator benefits This feature benefits the operator as follows: it allows Inter-RAT and inter-frequency load balancing for UEs in idle mode.

4.9.1.2


DN09185967 Issue: 01M

© 2016 Nokia

91



System release



RL50

LBTS5.0

LBTS5.0

Table 42

OMS


UE

NetAct

MME

SAE GW

3GPP R9


4.9.1.3

Functional description Functional overview To find a cell for a UE to camp, the UE proceeds in two steps: 1. Looking if a cell is suitable with the S-criteria 2. Ranking all cells (which fulfill the S-criteria) with the R-criteria The S-criteria: is fulfilled if: Srxlev > 0 and Squal >0. The R-criteria is defined as: RS = Qmeas,s + QHyst Rn = Qmeas,n - Qoffset The subscript s means serving cell, n means neighbor cell. Table 43

Parameters for R-criteria

Parameter

Meaning

Qmeas

RSRP measured by the UE in dBm

QHyst

qHyst (MOC: SIB), Hysteresis

Intra-Frequency: QOffset

qOffsetCell (if broadcast, otherwise it is set to 0)

Inter Frequency: QOffset

qOffCell + qOffFrq (if broadcast, otherwise it is assumed that those values are set to 0)

A cell reselection is performed, if a cell is ranked better than the current serving cell. The UE always camps on the highest ranked cell.

92

© 2016 Nokia

DN09185967 Issue: 01M



To calculate the S, R criteria, information from neighbored and serving cell is needed. The eNB broadcasts this information via SIB1, SIB3, SIB5, and SIB6 to each UE in the cell. Calculating the S criteria The S criteria are calculated as follows (in dB): Srxlev = Qrxlevmeas - (qrxlevmin + qRxLevMinOffset)- [max (pMaxOwnCEll - PUMAX,0)] Squal = Qqualmeas - (qQualMinR9 + qQualMinOffsetR9) with the parameters described in the following table: Table 44

Parameters for S criteria

Parameter

4.9.1.4

Meaning

Qrxlevmeas

UE measurement (RSRP)

qrxlevmin

Minimum Rx level in cell (MOC: SIB)

qrxLevMinOffset

Q RX level min. offset (MOC: SIB)

pMaxOwnCell

Max. uplink transmission power own cell (MOC: SIB).

PUMAX

UE class specific max UL transmit power

Qqualmeas

UE measurement (RSRQ)

qQualMinR9

Min Rx level in cell (MOC: SIB; Structure: cellSelectionInfoV920)

qQualMinOffsetR9

Q Rx level min offset (MOC: SIB; Structure: cellSelectionInfoV920)

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 system performance and capacity This feature has no impact on system performance or capacity.

4.9.1.5

LTE1036: RSRQ based cell Reselection management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms

DN09185967 Issue: 01M

© 2016 Nokia

93



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 The table below lists parameters introduced with this feature. Table 45

New parameters

Full name

94

Abbreviated name

Managed object

EUTRA inter-frequency quality thresholds (Rel9)

interFrqQThrR9

IRFIM

EUTRA inter-frequency quality threshold high (Rel9)

interFrqQThrHighR9 IRFIM

Structure

-

interFrqQThrR9

EUTRA inter-frequency interFrqQThrLowR9 quality threshold low (Rel9)

IRFIM

interFrqQThrR9

Min required RSRQ in inter-freq neighbor cells (Rel9)

IRFIM

-

qQualMinR9

Minimum required quality in cellSelectionInfoV92 SIB cell (Rel9) 0

-

Offset for minimum required RSRQ in cell (Rel9)

SIB

cellSelectionInfoV920

Minimum required RSRQ in qQualMinR9 cell (Rel9)

SIB

cellSelectionInfoV920

Intra-frequency measurements thresholds (Rel9)

sIntraSearchV920

SIB

-

Intra-frequency measurements power threshold (Rel9)

sIntraSearchPR9

SIB

sIntraSearchV920

Intra-frequency measurements quality threshold (Rel9)

sIntraSearchQR9

SIB

sIntraSearchV920

Inter-freq and inter-RAT meas thresholds (Rel9)

sNonIntraSearchV9 20

SIB

-

qQualMinOffsetR9

© 2016 Nokia

DN09185967 Issue: 01M


Table 45



Full name

Abbreviated name

Managed object

Structure

Inter-freq and inter-RAT power meas threshold (Rel9)

sNonIntraSearchPR 9

SIB

sNonIntraSearchV920

Inter-freq and inter-RAT quality meas threshold (Rel9)

sNonIntraSearchQR SIB 9

sNonIntraSearchV920

Q-threshold for reselection towards lower prio RAT/freq

threshServingLowQ R9

-

SIB

The table below lists parameters modified with this feature. Table 46

Modified parameters

Full name

Abbreviated name

Managed object

Structure

Inter-frequency blacklisted cell list

intFrBCList

IRFIM

-

Number of PCI in interfrequency range

rangeInterPci

IRFIM

intFrBCList

Lowest PCI in interfrequency range

startInterPci

IRFIM

intFrBCList

Inter-Frequency neighbouring cell list

intFrNCList

IRFIM

-

Physical cell identifier in neighbouring cell list

physCellIdNcl

IRFIM

intFrNCList

Cell reselection procedure offset

qOffCell

IRFIM

intFrNCList

List of UTRA FDD carrier frequencies

utrFddCarFrqL

UFFIM

-

UTRA downlink frequency value

dlCarFrqUtra

UFFIM

utrFddCarFrqL

UTRA-FDD carrier freq prio idleLBUtranFddCelR UFFIM for idle mode load esPrio balancing

utrFddCarFrqL

DN09185967 Issue: 01M

© 2016 Nokia

95


Table 46


Full name

4.9.1.6


Abbreviated name

Managed object

Structure

UTRA-FDD carrier weight factor idle mode load balancing

idleLBUtranFddCelR UFFIM esWeight

utrFddCarFrqL

UTRA maximum allowed transmit power

pMaxUtra

UFFIM

utrFddCarFrqL

UTRA minimum needed quality parameter

qQualMinUtra

UFFIM

utrFddCarFrqL

UTRA minimum required receive level

qRxLevMinUtra

UFFIM

utrFddCarFrqL

UTRA carrier frequency absolute priority

uCelResPrio

UFFIM

utrFddCarFrqL

UTRA inter-RAT quality threshold high (Rel9)

utraFrqQThrHighR9

UFFIM

utrFddCarFrqL

UTRA inter-RAT quality threshold low (Rel9)

utraFrqQThrLowR9

UFFIM

utrFddCarFrqL

UTRA inter frequency threshold high

utraFrqThrH

UFFIM

utrFddCarFrqL

UTRA inter frequency threshold low

utraFrqThrL

UFFIM

utrFddCarFrqL


Sales information

BSW/ASW



BSW

-

-

4.10 LTE1060: TDD - FDD Handover 4.10.1 Description of LTE1060: TDD - FDD handover Introduction to the feature The LTE1060: TDD-FDD handover feature provides support for inter-eNB, interfrequency handover of UEs from LTE FDD to LTE TDD and vice versa both via S1 and via X2. The evaluation of measurements reports, the handover preparation, execution,

96

© 2016 Nokia

DN09185967 Issue: 01M



completion and the data forwarding is identical to the inter-frequency handover via X2 (LTE53: Intra-LTE Handover via X2) respectively S1 (LTE54: Intra-LTE Handover via S1) and and Inter-eNB IF Load Balancing (LTE1170: Inter-frequency Load Balancing). As for inter-frequency Handover events A1 and A2 are used to control the start and stop of inter-frequency measurements on the target cells, the events A3, A4, or A5 are used to report suitable inter-frequency neighbors. Deployment Scenario An Operator has deployed both an LTE-TDD and an LTE-FDD network in the same geographical area whereas the coverage areas of both systems are at least partly overlapping. Both RANs are connected to a common Core Network.

4.10.1.1

Benefits End-user benefits The load is better deployed over the networks (FDD,TDD). Therefore, the end user gets a higher quality of his calls and a less call failure rate. Operator benefits The operator can offer service continuity between FDD and TDD.

4.10.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 48

OMS


UE

NetAct

MME

SAE GW


4.10.1.3

Functional description Functional overview The following TDD/FDD handover scenarios are supported by the Flexi Multiradio BTS: • •

inter-eNB, inter-frequency band via X2 inter-eNB, inter-frequency band via S1 (if enabled)

Both handover directions FDD -> TDD and TDD -> FDD are supported.

DN09185967 Issue: 01M

© 2016 Nokia

97



The following measurement events are used for the measurement-based inter-frequency handover: • • • • •

A1 - deactivate inter-frequency measurements A2 - activate inter-frequency measurements A3 - inter-frequency measurements A4 - inter-frequency measurements A5 - inter-frequency measurements

The events A1 and A2 are used to control the start and stop of inter-frequency measurements on the target cells. The events A3 - A5 are used to report suitable inter-frequency neighbors. The UE radio access capabilities are considered for the measurement configuration. The target cells for the inter-frequency handover can be configured by the operator. Also the handover thresholds, hysteresis margins and timer constraints for the inter-frequency handover are O&M parameters that can be configured by the operator. The evaluation of measurement reports, the handover preparation, execution, completion and the data forwarding is identical to the intra-frequency handover via X2 respectively S1. The existing inter-frequency performance counters are used in order to track the performance. The operator can enable/disable the functionality per eNodeB by O&M setting. For the LTE1060: TDD-FDD handover feature the activation of LTE55: Inter-frequency Handover is precondition. Both features are activated/deactivated via the same activation flag. Maximum Number of Carriers According to 3GPP TS36.133 (chapter 8.1.2.1.1.1) (starting with 3GPP R8 until now) UEs are capable of measuring using gaps of at least 7 carrier frequency layers. The number of measurement objects for inter-frequency and inter-RAT carriers in an UE at initial setup is fixed to following carriers: For FDD: • • •

3 FDD E-UTRA inter-frequency carriers 3 FDD UTRA carriers 32 GSM carriers (one GSM layer corresponds to maximum 32 carriers)

For TDD: • • •

3 TDD E-UTRA inter-frequency carriers 3 UTRA carriers (either 3 UTRA-FDD or 3 UTRA-TDD carriers) 32 GSM carriers (one GSM layer corresponds to maximum 32 carriers)

This means for TDD-FDD Handover only 3 LTE (TDD + FDD) inter-frequency carriers can be configured, and either 0 TDD / up to 3 FDD, 1 TDD / up to 2 FDD, up to 2 TDD/ 1 FDD or up to 3 TDD / 0 FDD inter-frequency carriers can be used.

98

© 2016 Nokia

DN09185967 Issue: 01M


g


Note: The UE is capable of monitoring, using gaps of three FDD UTRA carriers. In addition to this requirements, the UE is capable of monitoring using gaps a total of at least 7 carrier frequency layers comprising of any defined combination of E-UTRA FDD, E-UTRA TDD, UTRA FDD, UTRA TDD, GSM (one GSM layer corresponds to 32 carriers), cdma2000 1x and HRPD layers. If the operator has configred more than these number of layers in Mobility Profiles, it can not be guaranteed that the UE really measures all of theme. Feature Group Indicators The optional IE Feature Group Indicators is included in the UE_EUTRA_CAPABILITY. It is provided to RAC by the Bearer Management in the UE_RADIO_CAPABILITIES Structure. The following feature group indicators are considered for the LTE1060: TDD-FDD handover: (Table 49: Feature Group Indicators used for inter-frequency Handover TDDFDD) Table 49

Feature Group Indicators used for inter-frequency Handover TDD-FDD

Index of Indicator

Definition

13

Inter-frequency handover

14

•

•

4.10.1.4

Notes According to 36.331 this bit must be set to 1 because bit 30 has been set to 1

Measurement reporting event: Event A4 -Neighbor > threshold Measurement reporting event: Event A5 -Serving < threshold1 and Neighbor > threshold2

25

Inter-frequency measurements and reporting in E-UTRA connected mode

30

Handover between FDD and TDD

Can only set to 1 if the UE has set bit number 13 to 1.

System impact Interdependencies between features LTE55: Inter-frequency handover: This feature is precondition for LTE1060: TDD-FDD Handover. For both features the same Feature Activation Flag is used. Measurement events, the evaluation of measurements reports, the handover preparation, execution, completion and the data forwarding are identical to the inter-frequency handover. LTE54: Intra-LTE handover via S1: With this feature the general procedure handling for incoming S1-based handover was introduced, which is reused for TDD-FDD Handover if activated.

DN09185967 Issue: 01M

© 2016 Nokia

99



LTE53: Intra-LTE handover via X2: With this feature the general procedure handling for incoming X21-based handover was introduced, which is reused for TDD-FDD Handover. LTE1170: Inter-frequency load balancing: In case of inter-frequency load balancing between LTE FDD and LTE TDD cell vice versa FGI bit 30 (UE supports LTE FDD LTE TDD Handover) has to be checked. 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.10.1.5

LTE1060: TDD - FDD Handover 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 below lists parameters introduced with this feature: Table 50

New parameters

Full name

100

Abbreviated name

Managed object

DL cyclic prefix configuration

cpConfDL

LNADJL

UL Cyclic Prefix Configuration

cpConfUL

LNADJL

Downlink transmission bandwidth

dlTrmBw

LNADJL

Downlink EARFCN of LTE cell served by neighbor eNB

fDlEarfcn

LNADJL

© 2016 Nokia

Structure

DN09185967 Issue: 01M


Table 50



Full name

Abbreviated name

Managed object

Uplink EARFCN of FDD cell served by neighbor eNB

fUlEarfcn

LNADJL

Special Subframe Configuration Of Neighbor ENB

spcSubConfTD

LNADJL

UL and DL transmission bandwidth

trmBwTD

LNADJL

Uplink transmission bandwidth

ulTrmBw

LNADJL

Enable interFrequency handover

actIfHo

LNBTS

Structure

There are no parameters related to this feature.

4.10.1.6


Sales information

BSW/ASW



ASW

-

-

4.10.2 Activating LTE1060: TDD-FDD Handover Before you start The LTE1060: TDD-FDD handover feature needs as prerequisite the feature LTE55: Inter-frequency Handover. Both are started together by setting the parameter Enable interFrequency handover (actIfHo) to 1. If EnableInterFrequencyHandover (actIFHo) is set to 1 all of the following conditions need to be fulfilled: • • •

DN09185967 Issue: 01M

The Time to trigger for A1 to deactivate inter measurement (a1TimeToTriggerDeactInterMeas) must be 0ms ...5120ms. The Time to trigger for A2 to activate inter measurement (a2TimeToTriggerActInterFreqMeas) must be 0ms..5120ms. The Threshold th2 interFreq for RSRP(threshold2InterFreq) must be 0...97.

© 2016 Nokia

101


• •


The Related hysteresis of threshold th2 interFreq for RSRP (hysThreshold2InterFreq) must be 0...15 dB. The Related hysteresis of threshold th2a for RSRP (hysThreshold2a) must be 0...15 dB.

Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the EnableInterFrequencyHandover (actIFHo) parameter value to 1. This step activates the feature.

4.10.3 Deactivating LTE1060: TDD - FDD Handover Before you start The LTE1060: TDD-FDD handover feature is deactivated by setting the parameter Enable interFrequency handover (actIfHo) to disabled.

Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the EnableInterFrequencyHandover (actIFHo) parameter value to disabled. This step deactivates the feature.

102

© 2016 Nokia

DN09185967 Issue: 01M



4.11 LTE1089: Downlink Carrier Aggregation - 20 MHz 4.11.1 Description of LTE1089: Downlink Carrier Aggregation - 20 MHz Introduction to the feature The support of Downlink (DL) Carrier -Aggregation is described as follows: •

•

•

•

•

• • •

4.11.1.1

Two cells, in different bands (inter-band CA (Carrier Aggregation) ) are aggregated in the downlink so that CA capable UEs can achieve similar peak data rates as in case of a single cell with the wider corresponding bandwidth. The PDSCH (Physical Downlink Shared Channel) on the PCell (Primary Cell) and SCell (Secondary Cell) can be transmitted to the CA UE in a TTI that is up to 4 TBs. The CA UEs can transmit on only one UL cell. (PCell). Note that each of the cells can serve non-CA UEs in parallel to CA UEs. The feature is for FDD only RRC (Radio Resource Control) signaling is extended to support SCell Configuration/Deconfiguration and delivery of SCell's system information and SCell's dedicated parameters via PCell MAC (Medium Access Control) signaling is extended to support SCell Activation. Blind SCell activation and periodic buffer-based activation is supported. Separate per cell HARQ (Hybrid Adaptive Repeat and Request) entities are used for CA UEs. PHY (Physical Layer) signaling is extended to support reception of multi-cell UE's feedback on single UL PCell. The PDCCH (Physical Downlink Control Channel) and the corresponding PDSCH are on the same serving cell (on the PCell and/or on the SCell that is cross-CC scheduling is not used) Scheduling is enhanced to support CA UEs. Separate DL schedulers allocate the PCell's and SCell's DL resources. Additionally, the schedulers are coordinated to fulfill data rate limits of the CA UE and to provide fairness between CA and non-CA UEs. Only non-GBR DRBs of a CA UE can be served on both serving cells. GBR DRBs, SRB1 and SRB2 are served on the PCell only Configuration of PUCCH (Physical Uplink Control Channel) resources is modified to accommodate the CA UE's multi-cell feedback on single UL PCell. Additional CA-specific PM counters PDCCH OLLA (Outer Loop Link Adoption) is per serving cell and it is modified to cope with ambiguous HARQ feedback. Either the SCell's OLLA reuses the calculations of the PCell's OLLA or the OLLA in the SCell is disabled depending on an O&M parameter. PUSCH TX/DTX detection is used by PDCCH OLLA to compensate the reduced number of samples due to ambiguous HARQ feedback. PUSCH TX/DTX detection in PDCCH OLLA is used not only for UEs with an active SCell but also as a general improvement in RL50.

Benefits End-user benefits This feature benefits the end user as follows: the end user gets an improved peak and average UE downlink throughput. UE downlink throughput may be doubled in contrast to the deployment not employing Carrier Aggregation feature. Operator benefits

DN09185967 Issue: 01M

© 2016 Nokia

103



Operators with fragmented 5+5, 5+10 or 10+10 MHz spectrum allocations can offer the same end user experience as operators with a single band 10, 15 or 20 MHz deployment.From the system level point of view smooth load balancing between layers is achieved - without employing inter-frequency handover. System capacity gains may be observed - depending on the network deployment type and/or UE traffic profile.

4.11.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 52

OMS


UE

NetAct

MME

SAE GW

3GPP R10

Hint: CA capable UEs are required, that support the same CA band combination as in the BTS. Hardware requirements This feature requires no new or additional hardware.

4.11.1.3

Functional description Functional overview The feature allows the operator to provide higher UE peak data rates by aggregation of two cells of 10MHz each or of two cell of 5MHz each (or 5MHz + 10MHz only for FSMF) in different bands. To use this bandwidth extension and aggregate fragmented spectrum, the operator needs to enable and configure the feature in the sectors which support inter-band carrier aggregation. Only co-located cells which have antennas pointed to the same geographical area can be aggregated with LTE1089: Downlink Carrier Aggregation - 20 MHz. The following band combinations are alllowed: • • • • • •

104

band 1 + 5 band 1 + 8 band 1 + 18 band 3 + 5 band 3 + 8 band 5 + 12

© 2016 Nokia

DN09185967 Issue: 01M



To use CA at the UE, the SCell needs to be configured and activated at the UE. SCell configuration is blind meaning that if the feature is enabled at the eNB and if the UE supports CA in this band combination then SCell is configured by RRC. In addition, UE AMBR (Aggregate Maximum Bit Rate) is checked during SCell configuration to decide if the SCell is added for this UE. A new parameter in UE capability is used by the eNB to derive the UE CA support in this band configuration. SCell's system information and SCell's dedicated parameters are provided by dedicated RRC signaling on the PCell. SCell's configuration needs to be available in the PCell; furthermore, setting of some configuration parameters of the PCell and SCell need to be coordinated for example parameters related to Transmission Modes or CQI (Channel Quality Information) reporting. The UE configured with SCell but not activated with SCell does not monitor PDCCH on SCell, such an UE also does not report CQI feedback related to the SCell. The RAC counts and limits in a cell the amount of UEs that have the other cell configured as an SCell, the RAC is informed about the number of UEs which have a configured SCell on this cell. The maximum number of carrier aggregation configured UEs is an O&M parameter (Max number Carrier Aggr configured UEs double carrier, maxNumCaConfUeDc) The PCell's and SCell's RAC instances communicate with each other. There is no pre-emption selection in the SCell for non-GBR DRBs served on both cells. Note that the situation where only a subset of the UE's non-GBR DRBs admitted in PCell is admitted in the SCell cannot occur. New SCell configurations are not allowed if this cell is barred or reserved for the operator use; however, an already configured SCell is not de-configured in case this cell becomes barred. No check is performed on PLMNs configured in SCell. SCell can be used for any PLMN. SCell activation is done by an MAC control element and is blind or it can be periodic buffer based. The SCell can be deactivated by operator configurable MAC sCellDeactivationTimerEnb in case of no UE activity on SCell resulting in transmission of a MAC CE to deactivate the SCell. Once SCell is activated, separate per cell HARQ entities and DL-SCHes are used for the CA UE and the UE can be scheduled up to four transport blocks per TTI. Each of the cells can serve non-CA UEs in parallel to CA UEs; however, the CA UEs can transmit in the UL only on the PCell. DL scheduling is modified to provide operator configurable fairness between CA and non-CA UEs. For scheduling of CA UEs, separate per cell schedulers are assumed, the schedulers are coordinated in order to provide the above mentioned fairness and to fulfill data rate limits of CA UEs depending on their UE category and the amount of data available for transmission. A possibly configured limit of maxBitrateDl is ignored by the downlink schedulers when the UE is configured with an SCell because the standardized rate limits are used for carrier aggregation in any case. The UE activated with an SCell monitors PDCCH for C-RNTI on PCell and SCell, the same C-RNTI for the CA UE is used on both active serving cells. The UE monitors PDCCH for SI-RNTI/P-RNTI/RA-RNTI on PCell only. When the SCell is activated, the UE reports CQI feedback for both cells according to L1/L2 configuration and UL grant triggers. Additional RLC PDU(s) are generated because of scheduling of TB(s) on an SCell. SRB1, SRB2 and GBR DRB(s) are served on the PCell only. The UE's UL feedback received on one cell, needs to be distributed to the corresponding entities of PCell and SCell. The DL BSR (amount of data available for DL scheduling) provided to SCell's MAC/DL-scheduler considers only the DRBs which can be served on multiple cells. PDCCH OLLA is per serving cell and it is modified to cope with ambiguous HARQ feedback. Either SCell's OLLA reuses the calculations of PCell's OLLA or the OLLA in

DN09185967 Issue: 01M

© 2016 Nokia

105



SCell is disabled depending on an O&M parameter. PUSCH TX/DTX detection is used by PDCCH OLLA to compensate the reduced number of samples because of to ambiguous HARQ feedback. PUSCH TX/DTX detection in PDCCH OLLA is used not only for UEs with an active SCell but also as a general improvement in RL50. Various new functionalities are provided by L1 to support the UE feedback in the UL on one cell, the feedback is related to multiple cells. PUCCH format 1b with channel selection is added in the UL to support ACK/NACKs for multiple cells for the same reason the possibility to receive more than 2 ACK/NACKs on PUSCH is added. UE measurements on the frequency of a configured but not activated SCell are performed according to a cycle which is operator-configurable. The mobility of UEs with configured SCell is based on primary serving cell measurements and regular mobility management algorithms. The following new PM counters are introduced by the LTE1089: Downlink Carrier Aggregation - 20 MHz feature: • • • • • •

average number DL carrier aggregation capable UEs average number of UEs with a configured SCell average number of UEs with an activated SCell number of SCell configuration attempts number of successful SCell configurations PCell RLC data volume in DL via Scell

Carrier Aggregation Configuration One new MOC is introduced in order to configure Carrier Aggregation: CAREL (Carrier Aggregation Relation).

CAREL is subordinated to LNCEL. CAREL is created in the PCell and contains lcrId (Local cell resource ID of cell to be aggregated) of the Scell.

g

Note: Modification of the lcrId parameter requires object locking. This causes a cell service break. A maximum of two LCELL can have the same sectorId when LTE1089: Downlink Carrier Aggregation - 20MHz is enabled. The below describes the modelling for the following configuration: LNCEL-1 can be used as SCell when LNCEL-4 is PCell. New MOC and parameters for Carrier Aggregation are marked in yellow. Carrier Aggregation will use existing configuration of LNCELs (Primary and Secondary).

106

© 2016 Nokia

DN09185967 Issue: 01M


Figure 11


Configuration of Carrier aggregation: LNCEL-1 is used as SCell when LNCEL-4 is PCell

LNCEL-1

LNCEL-4 eNodeB

LNBTS actDLCAggr

LNCEL-4 (Band5)

lcrId

LNCEL-1 (Band1)

CAREL-1 lcrId

Please note that in order to provide Carrier Aggregation when LNCEL-1 is PCell, it is necessary to create also CAREL under LNCEL-1 containing lcrId of LNCEL-4. In the LTE1089: Downlink Carrier Aggregation - 20 Mhz feature, one cell can be part of only one group of aggregated cells. For example: if LNCEL-1 is configured as SCell for LNCEL-4 then only LNCEL-4 can be configured as SCell for LNCEL-1()

DN09185967 Issue: 01M

© 2016 Nokia

107


Figure 12


Configuration of Carrier aggregation: LNCEL-1 is used as SCell when LNCEL-4 is PCell and LNCEL-4 is used as SCell when LNCEL-1 is PCell

LNBTS actDLCAggr

lcrId

LNCEL-4 (Band5)

lcrId

LNCEL-1 (Band1)

CAREL-1 lcrId

CAREL-1 lcrId

Consistency Checks The parameter actCompChecks activates Complete Consistency Checks in Validator tool. This parameter can be used to disable the checks that could block eNB reconfiguration after SW upgrade. Only particular checks in Validator tool are disabled by this parameter. When, after SW upgrade, configuration validation fails in BTS Site Manager or in NetAct, it is possible to set this parameter to "false" and proceed with eNB reconfiguration. Note: During migration from RL40 to RL50 the parameter will be added with disabled complete checks, i.e. added with value "false". It is recommended to reconfigure the parameter to value "true" and adjust the configuration in case the Validator tool does identify inconsistencies.

4.11.1.4

System impact Interdependencies between features The LTE1089: Downlink Carrier Aggregation - 20Mhz feature can only be enabled if the LTE496: Support of QCI 2,3 and 4 feature is enabled. This restriction is used to avoid CA-related modifications of multiple types of scheduling metric calculation; CA-related modifications are introduced only together with the scheduling metric calculation as specified in LTE496: Support of QCI 2,3 and 4 . This also means that ARP handling is enabled with LTE1089: Downlink Carrier Aggregation - 20 MHz. The LTE1367: Automatic cell combination assignment for Carrier Aggregation supports the CA on the NetAct. Following features do not work with CA: • •

108

LTE1542: FDD Supercell LTE72: 4-way Rx diversity

© 2016 Nokia

DN09185967 Issue: 01M



LTE568: DL adaptive closed loop Mimo (4 x 2) LTE980: IRC for 4 RX paths

• •

Impact on interfaces This feature impacts interfaces as follows: Uu:

•

– –

RRCConnectionReconfiguration includes SCell's system information and dedicated RRC parameters UECapabilityInformation includes the CA related UE capabilities (supportedBandCombination)

BTSOM/NW13

•

– –

New object CAREL is created in eNB Object Model Additional PM counters

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 System performance: DL-Throughput performances for CA-2*5MHz is nearly identical to DL-Throughputperformances of a 10 MHz-cell in case of non-GBR traffic DL-Throughput performances for CA-2*10MHz is nearly identical to DL-Throughputperformances of a 20 MHz-cell in case of non-GBR traffic

• •

4.11.1.5

LTE1089: Downlink Carrier Aggregation - 20 Mhz 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 lists counters introduced with this feature. Table 53

Counter ID

New counters

Counter name

Measurement

M8001C494

Average number of DL carrier aggregated capable UEs

LTE Cell Load

M8001C495

Average number of UEs with a configured SCell

LTE Cell Load

DN09185967 Issue: 01M

© 2016 Nokia

109


Table 53


New counters (Cont.)

Counter ID

Counter name

Measurement

M8001C496

Average number of UEs with an activated SCell

LTE Cell Load

M8011C67

Number of SCell configuration attempts

LTE Cell Resource

M8011C68

Number of successful SCell configurations

LTE Cell Resource

M8012C151

PCell RLC data volume in DL via SCell

LTE Cell Throughput

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

New parameters

Full name

110

Abbreviated name

Managed object

Carrier aggregation relation identifier

caRelId

CAREL

Sched Carrier Aggr fairness control factor

caSchedFairFact

CAREL

Disable PDCCH outer disableSCellPDCCHOl loop link adaptation in La SCell

CAREL

Local cell resource ID of cell to be aggregated

lcrId

CAREL

Cell sector id

sectorId

LCELL

Activation of complete actCompChecks consistency checks

LNBTS

Activation of downlink carrier aggregation

actDLCAggr

LNBTS

Min UE-AMBR downlink for carrier aggregation

caMinDlAmbr

LNBTS

SCell activation cycle period

sCellActivationCyclePe LNBTS riod

© 2016 Nokia

Structure

DN09185967 Issue: 01M


Table 54



Full name

Abbreviated name

Managed object

SCell activation method

sCellActivationMethod

SCell deactivation timer eNB

sCellDeactivationTimer LNBTS eNB

SCell and PCell ambiguous HARQ feedback usage

sCellpCellHARQFdbkU LNBTS sage

Max number Carrier Aggr configured UEs double carrier

maxNumCaConfUeDc

Structure

LNBTS

LNCEL

lists parameters modified with this feature: Table 55

Modified parameters

Full name

Abbreviated name

Managed object

Activate enhanced AC actEnhAcAndGbrServi and GBR services ces

LNBTS

Activate flexible base band usage

actFlexBbUsage

LNBTS

Additional active UE with reason radio reason handover

addAUeRrHo

LNCEL

Additional active UE with reason time critical handover

addAUeTcHo

LNCEL

Add emergency sessions

addEmergencySession LNCEL s

Add number DRB radioReasHo

addNumDrbRadioReas LNCEL Ho

Add number DRB timeCriticalHo

addNumDrbTimeCritica LNCEL lHo

Add number QCI1 addNumQci1DrbRadio DRB for radioReasHo ReasHo

DN09185967 Issue: 01M

© 2016 Nokia

Structure

LNCEL

111


Table 55


Full name

112


Abbreviated name

Managed object

Add number QCI1 DRB for timeCriticalHo

addNumQci1DrbTimeC LNCEL riticalHo

Cell scheduling request periodicity

cellSrPeriod

LNCEL

CQI periodicity network period

cqiPerNp

LNCEL

Periodic CQI subbands cycles

cqiPerSbCycK

LNCEL

Delta cyclic shift for PUCCH

deltaPucchShift

LNCEL

Downlink MIMO mode dlMimoMode

LNCEL

EARFCN downlink

earfcnDL

LNCEL

Maximum bitrate downlink

maxBitrateDl

LNCEL

Max number act DRB

maxNumActDrb

LNCEL

Maximum number of active UEs

maxNumActUE

LNCEL

Max number QCI1 DRBs (GBRs)

maxNumQci1Drb

LNCEL

Maximum number of RRC connections

maxNumRrc

LNCEL

Maximum number RRC emergency

maxNumRrcEmergenc y

LNCEL

Maximum bitrate selector

mbrSelector

LNCEL

ACK/NACK offset

n1PucchAn

LNCEL

PUCCH bandwidth for nCqiRb CQI

LNCEL

PDCCH and HARQ pdcchHarqTargetBler response target BLER

LNCEL

© 2016 Nokia

Structure

DN09185967 Issue: 01M


Table 55


Full name

4.11.1.6


Abbreviated name

Managed object

Periodic CQI feedback type

periodicCqiFeedbackTy LNCEL pe

Rank indication reporting enable

riEnable

Structure

LNCEL


Sales information

BSW/ASW



ASW

-

-

4.11.2 Activating LTE1089: Downlink Carrier Aggregation - 20MHz Before you start The feature LTE1089:Downlink Carrier Aggregation - 20MHz is activated by setting the parameter Activation of downlink carrier aggregation (actDLCAggr) to true. The parameters actFlexBbUsage and actEnhAcAndGbrServices must be set to true. The parameter actSuperCellmust be set to false. For operating Carrier Aggregation features, it may be necessary to set the parameter link speed. The setting of the parameter link speed is described in Commissioning Flexi Multiradio BTS LTE. Please note, that normally the default value Auto is the optimal selection. In all LCELL instances the sectorId must be configured: for carrier aggregated cell (CA cell) with subordinated CAREL instance or which is linked by CAREL-lcrId of another LNCEL with same sectorId (maximal 2 LCELL instances are allowed having same sectorId); for non-CA cells the sectorId must be unique within the eNB. For fully functional carrier aggregation at least one CAREL instances need to exist in the eNB, if no CAREL instance is created carrier aggregation is only prepared. The feature is enabled for the whole eNodeB. A change of the enabling of this feature becomes valid at the next BTS restart.

DN09185967 Issue: 01M

© 2016 Nokia

113



Steps

1


2

Go to the Radio Network Configuration page. The following steps are precondition for activating the feature LTE1089. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set theActivate flexible base band usage (actFlexBbUsage) parameter value to true. d) Set theActivate enhanced AC and GBR services (actEnhAcAndGbrServices) parameter value to true. e) Select the LNCEL object. f) Set the Activate supercell configuration (actSuperCell) parameter value to false.

3

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of downlink carrier aggregation (actDLCAggr) parameter value to true. This step activates the feature. Hint: A BTS restart is needed.

4.11.3 Deactivating LTE1089: Downlink Carrier Aggregation - 20 MHz Before you start The feature LTE1089:Downlink Carrier Aggregation - 20MHz is deactivated by setting the parameter Activation of downlink carrier aggregation (actDLCAggr) to false. The feature is disabled for the whole eNodeB. A change of the enabling of this feature becomes valid at the next BTS restart.

114

© 2016 Nokia

DN09185967 Issue: 01M



Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of downlink carrier aggregation (actDLCAggr) parameter value to false. This step deactivates the feature. Hint: A BTS restart is needed.

4.12 LTE1139: ZUC security algorithm 4.12.1 Description of LTE1139: ZUC security algorithm Introduction to the feature Security for the eNodeB (as a network element) is at first time specified by 3GPP for LTE. This means: LTE is here the leading radio standard. It is needed to protect the confidentiality of the user and mitigate the effects of attacks on the network. In this document, the application of the ZUC security algorithm for the air link security is described. ZUC stands for Zu Chougzhi ( a Chinese mathematician and astronomer).This feature descriptionLTE1139: ZUC security algorithm consists of user data security between UE and eNodeB for radio layer 2 (u-plane data) and of radio layer 3 (RRC, control plane data). Two functions are provided for the maintenance of security: Ciphering and integrity protection. •

•

Ciphering is applied on both control plane data (RRC signaling) and user plane data and it is used to protect the data streams from being eavesdropped by a third party. Part of ciphering is also the key derivation function (SHA-256 in RL 3 protocol) Integrity protection is applied on control plane data only and allows the receiver to detect packet insertion or replacement.

Ciphering and integrity protection within the access stratum is performed in the PDCP layer. The Flexi Multiradio BTS supports ciphering for the user plane PDUs and the RRC PDUs according to the 3GPP specifications TS 36.300, TS 36.323, TS36.331 and TS36.401. The keys used for ciphering and integrity protection of traffic (data/control signaling) are established when a connection between UE and the eNodeB/network is built up and they are discarded after a session has been closed (sometimes keys can change within a

DN09185967 Issue: 01M

© 2016 Nokia

115



session); UE and eNodeB establish the same keys. The keys have 128 bits length and are derived from superior keys which are organized in a hierarchical structure. The last joint key KASME used for derivation of AS keys is calculated in the Home Subscriber Server (HSS) and stored and used in the MME and in a secure part of the Universal Subscriber Identity Module (USIM) in the UE. The eNode supports the following ciphering/integrity protection algorithms (EEA: EPS encryption algorithm; EIA: EPS integrity algorithm): • • • •

Null algorithm (EEA0/EIA0 – providing no security) SNOW 3G (EEA1/EIA1) AES (EEA2/EIA2) ZUC security algorithm (EEA3/EIA3)

Only the application of the ZUC security algorithm is described in this feature: LTE1139: ZUC security algortihm. The others are described in the feature description: LTE37: Ciphering and LTE38: Integrity Protection. A ciphering algorithm uses a ciphering key (and other parameters) as input to create a key stream which is combined with the plaintext stream. The resulting ciphered data stream is transmitted and the receiver gets the plaintext back by applying the same key stream on the ciphered data stream in the same way as done during ciphering. Ciphering is an optional feature. If a customer decides not to buy a license for this feature, they can use a NULL-algorithm instead. An integrity protection algorithm uses an integrity protection key (and other parameters) as input to create a message authentication code added to the message to be sent. The integrity protection is a mandatory feature. From 3GPP view no integrity protection NULL-algorithm is available besides for unauthenticated IMS emergency sessions. But in extension to 3GPP, completely explained by the LTSI-forum, there a IP-NULL-algorithm is implemented also for normal calls. Both unauthenticated IMS emergency sessions and the LTSI extension can only be used if the MME is configured to do so, such IP-NULLalgortihm cannot be used by accident.

4.12.1.1

Benefits End-user benefits This feature benefits the end user as follows: The ZUC security algorithm is a further possibility to offer ciphering and integrity protection in the AS (access stratum) and protects the air interface against attacks and eavesdroppers Operator benefits This feature benefits the operator as follows: The operator benefits are the same as for the end-user.

4.12.1.2


116

© 2016 Nokia

DN09185967 Issue: 01M



System release



RL50

LBTS5.0

LBTS5.0

Table 57

OMS

-


UE

NetAct

MME

SAE GW

3GPP R8

-

-

-


4.12.1.3

Functional description Functional Overview Figure 13: C-plane security and Figure 14: U-plane security show the overall security concept within LTE. The security architecture is different for user plane traffic and control plane traffic. Here and in the following sections, security aspects for the non-access stratum (NAS) are also included in order to show relations between NAS and AS security, and for comprehensibility. Figure 13

C-plane security integrityprotected,ciphered

NAS

RRC

integrityprotected ciphered

RRC

L2

AP

PDCP ...

...

integrityprotected

S1AP/X2AP

L3

PDCP

NAS

S1AP

ciphered

SCTP

SCTP L4

IPv4/IPsec

IPv4/IPsec L3

UE

...

eNB

MME

...

integrity protected, ciphered

RRC ... eNB

DN09185967 Issue: 01M

© 2016 Nokia

X2AP ...

AP:ApplicationLayer L2,L3,...:Layer2,Layer3,...

117


Figure 14


U-plane security

Datastream

PDCP ...

Datastream

ciphered

PDCP L2

GTP-U AP

...

integrity protected ciphered

GTP-U

integrity protected

GTP-U

ciphered

UDP

UDP

UDP

L4

IPv4/IPsec ... UE

L3

eNB

IPv4/IPsec ... S-GW

IPv4/IPsec ... P-GW

integrity protected, ciphered

PDCP

GTP-U

...

...

eNB

AP:ApplicationLayer L2,L3,...:Layer2,Layer3,...

C-plane security includes the following characteristics: • • •

• • •

•

NAS signaling protection is transparent for the eNodeB. NAS signaling is ciphered and integrity protected between UE and MME. RRC integrity protection and ciphering is applied to NAS messages carried by RRC messages in addition to the NAS signaling security between MME and UE. This results in double protection of NAS signaling. RRC signaling is always integrity protected by PDCP in the eNodeB and in the UE. RRC signaling is ciphered between UE and eNodeB by PDCP. S1AP signaling is ciphered and integrity protected between eNodeB and MME by an underlying transport security mechanism. This is an separate feature (LTE689) and described into the FAD: IPsec operation. It is an optional feature. X2AP signaling is protected in the same way as S1AP signalling.

The security described by LTE37/LTE38 or LTE1139 is always between the UE and the eNodeB. If there is data forwarding from a source-eNodeB to a target eNodeB there will be transport security activated. Security Keys Various security keys are used for ciphering and integrity protection of traffic depending on the type of traffic (user data/control signaling) and the related stratum (NAS/AS). For the NAS (non access stratum) these are: •

KNASenc for encryption of NAS messages between UE and MME

•

KNASint for integrity protection of NAS messages between UE and MME

For the AS (access stratum; transmission between UE and eNodeB) the following security keys are used:

118

•

KUPenc for encryption of user plane traffic

•

KRRCenc for encryption of control plane traffic (which is RRC signaling)

•

KRRCint for integrity protection of control plane traffic

© 2016 Nokia

DN09185967 Issue: 01M



The keys are derived from superior keys organized in a hierarchical structure. The AS keys KUPenc, KRRCenc , and KRRCint are derived from KeNB which is related to a certain eNodeB and which itself is derived from the superior key KASME. The NAS keys KNASenc and KNASint are also derived from KASME. Figure 15: Security key hierarchy shows the LTE security key hierarchy and key distribution concept. KASME is available in the Authentication Center (AuC) which resides in the Home Subscriber Server (HSS) and in a secure part of the Universal Subscriber Identity Module (USIM) in the UE; UE and eNodeB use the same KASME for deriving their security keys. ASME is the Access Security Management Entity of the EPS (evolved packet system) and is located in the MME. The key K which is the origin of all other keys and the keys CK (cipher key) and IK (integrity key) have no direct effect on RRM and are mentionened just for completeness. Other keys or structures for ciphering/integrity protection such as KeNB* and NH are described in the related chapters. Figure 15

Security key hierarchy HSS

UE K

CK

K

IK

CK

IK

MME K ASME

K ASME

K NASint K NASenc

KeysforNASsignalling

K ASME

K NASint K NASenc NASarea ASarea

K eNB

K eNB

K eNB

eNB K UPenc K RRCint K RRCenc

K UPenc K RRCint K RRCenc

ASkeysfor C-planeand U-planetraffic

Lifetime of security keys The existence of a key depends on the EMM/RRC state of a UE in respect of connection establishment (EMM: EPS mobility management; ECM: EPS connection management): • •

•

K always exists; it is the only permanent key. The NAS keys KASME, KNASenc, KNASint and CK, IK exist while the EMMREGISTERED state is ongoing. The AS keys KeNB, KUPenc, KRRCint, and KRRCenc are created on RRC-IDLE to RRCCONNECTED transitions (correlated with ECM-IDLE to ECM-CONNECTED transitions) when in EMM-REGISTERED state (as the UE is in EMM-REGISTERED state, an EPS security context already exists in the UE and the MME) and they exist during RRC-CONNECTED state. The eNodeB deletes the keys after receiving the S1AP: UE CONTEXT RELEASE COMMAND message.

Key establishment and key distribution

DN09185967 Issue: 01M

© 2016 Nokia

119



The different security keys are established during specific key establishment procedures: •

•

•

•

Authentication and Key Agreement (AKA): This procedure is performed when a UE initially attaches to the network. The MME authenticates the subscriber, and the keys CK, IK, and KASME are established, once in the USIM/UE, and in the same way in the AuC/HSS. KASME is derived from CK, IK and the PLMN ID; the HSS transfers KASME to the MME. AKA is a NAS procedure and does not have any prerequisite besides the permanent key K. NAS Security Mode Command (NAS SMC) procedure: This procedure is performed when the UE has successfully been authenticated. MME and UE generate the NAS keys KNASenc and KNASint for NAS signaling security. NAS SMC needs a valid KASME as prerequisite. In addition, NAS SMC activates the NAS security mechanisms. KeNB establishment: The procedure applied is specific for different cases: –

For a change of state to RRC-CONNECTED, KeNB is derived in the UE and in the MME from KASME and the eNodeB ID. The MME transmits KeNB to the eNodeB by the S1AP: INITIAL CONTEXT SETUP REQUEST message. MME and UE also derive the next hop (NH) parameter from the KASME.

–

For an intra-LTE intra-frequency handover, the source eNodeB creates KeNB*, a transport security key, which is transferred via X2 interface to the target eNodeB where the KeNB to be used is derived from the KeNB* (for more information, see below).

AS Security Mode Command (AS SMC) procedure: The eNodeB selects the security parameters required for deriving the AS security keys. These parameters are transferred to the UE via the SECURITY MODE COMMAND message. Then the UE and eNodeB derive the AS keys KUPenc, KRRCint, and KRRCenc from KeNB. These keys are needed for user plane encryption and RRC integrity protection and encryption. AS SMC needs a valid KeNB as prerequisite. In addition, AS SMC activates the AS security mechanisms.

Key set identifier and key change indicator At initial context setup AS and NAS security start with a common KASME key. Later, several KASME may be known by network and UE. For example, while the RRCCONNECTED state is still ongoing, NAS can apply a new KASME (by executing another NAS security mode command). In this case there is the old KASME, from which NAS and AS keys are still derived, and the new KASME, from which fresh NAS and AS keys shall be derived. Therefore, a specific parameter identifies a particular KASME. Subsequently to a NAS change of KASME (while the AS KASME is still used), AS follows the NAS change which includes a handover. The parameter identifying a particular KASME is KSI (key set identifier). KSI is generated together with KASME during the Authentication and Key Agreement procedure. All keys derived from a KASME inherit this KSI (this is why KSI is called a "set" identifier). The KSI is signaled at NAS level only, for example during the Authentication and Key Agreement procedure and NAS security mode command procedure. At AS level the KSI is not signaled. Instead, implicit dependencies between NAS and AS procedures keep the AS keys synchronous in the network and the UE: at beginning of AS procedures for an RRC connection, the AS uses the same KASME as the NAS, and AS does not change

120

© 2016 Nokia

DN09185967 Issue: 01M



this KASME during usual AS key changes. Only in combination of an intra-cell handover AS may change the KASME. In this case the KASME change is signaled by a flag called KCI (key change indicator). Key handling in case of handover The target eNodeB gets its KeNB to be used for generating its U-plane and C-plane keys as follows: The source eNodeB determines a transport security key KeNB* and transmits this key via X2 interface to the target eNodeB. Then the target eNodeB derives K eNB from KeNB*. One possibility to determine KeNB* is to have it derived directly from the currently active KeNB. This direct derivation of KeNB* uses a cryptographic hash function, so it is not feasible to reconstruct the source KeNB from the new target KeNB. Therefore a target eNodeB does not expose the security of the source eNodeB; in other words: backward security is guaranteed. However, there is no forward security which means that the target eNodeB keys are no secret for the source eNodeB. The second possibility to determine KeNB* is to have it derived from the NH (next hop) parameter which was calculated from the KASME. Since the source eNodeB cannot recalculate KeNB* from KeNB, forward security is achieved. In case of a S1 handover, NH is transported from the MME by the S1AP: HANDOVER REQUEST message and is immediately available for the handover (forward security after one hop). In case of X2 handover, NH is transported by the S1AP: PATH SWITCH ACKNOWLEDGEMENT message and is not available for the current handover (because the new keys are already determined at this point in time) but for the next one. Therefore, forward security is reached at next handover (forward security after two hops). Subsequent hand overs with each transport KeNB* derived directly from the previous KeNB form a chain with backward security only. A handover where the transport KeNB* is derived via NH is the starting point for another chain with backward security only. These chains are counted and identified with the NCC (next hop chaining counter) parameter signaled by the MME; NCC has the value 0 at the initial security context setup. Activation This feature LTE1139: ZUC security algorithm is optional and must be activated by setting the parameter actZUC to true. Message and Information Elements The message and information elements are described in LTE37: Ciphering and LTE38: Integrity protection. Parameters A table of the parameters are given in the Management Data . Some additional information is given in the following table Table 58: ZUC Parameters.

DN09185967 Issue: 01M

© 2016 Nokia

121


Table 58

ZUC Parameters

Parameter Name

4.12.1.4


Parameter Type

Short Description

Severity when deactivated/disabled Emptying the algorithm selection list leads to NULL ciphering, i.e. no cipher protection of user data.

actZUC

Dis-/enable

This parameter dis/enables usage of ZUC cipher algorithm. Disable removes ZUC from algorithm selection list. A empty algorithm selection list leads to NULL ciphering, i.e. no cipher protection of user data.

eea3

Priority

Defines the priority for selecting the ZUC cipher algorithm.

eia3

Priority

Defines the priority for selecting the ZUC integrity algorithm.

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.12.1.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

122

© 2016 Nokia

DN09185967 Issue: 01M



There are no key performance indicators related to this feature. Parameters lists parameters introduced with this feature. Table 59

New parameters

Full name

4.12.1.6

Abbreviated name

Managed object

Structure

Activation of ZUC algorithm

actZUC

LNBTS

ZUC-based algorithm preference for ciphering

eea3

LNBTS

cipherPrefL

ZUC-based algorithm preference for integrity protection

eia3

LNBTS

integrityPrefL


Sales information

BSW/ASW



ASW

-

-

4.12.2 Activating LTE1139: ZUC security algorithm feature using the BTS Site Manager Before you start The eNB must be already commissioned. The BTS Site Manager (BTSSM) can be connected to the eNB either locally or from a remote location. Steps To activate the LTE1139: ZUC security algorithm, do the following: Procedure 1


DN09185967 Issue: 01M

© 2016 Nokia

123


2


Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of ZUC algorithm (actZUC) parameter value to true.

Activating LTE1139: ZUC Security Algorithm Before you start The feature LTE1139: ZUC Security Algorithm must be activated by setting the parameter Activation of ZUC Algorithm (actZUC) to true. The activation runs on-line, a restart of the eNB is not necessary.

Steps To activate the LTE1139: ZUC security algorithm, do the following:

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of ZUC algorithm (actZUC) parameter value to true. This step activates the feature.

Deactivating LTE1139: ZUC Security Algorithm Before you start The feature LTE1139: ZUC Security Algorithm can be deactivated by setting the parameter Activation of ZUC algorithm(actZUC)to false.

124

© 2016 Nokia

DN09185967 Issue: 01M



Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of ZUC Algorithm (actZUC) parameter value to false. This step deactivates the feature.

4.13 LTE1170: Inter - frequency Load Balancing 4.13.1 Description of LTE1170: Inter-eNB Inter-Frequency Load Balancing Introduction to the feature The LTE1170: Inter-frequency Load Balancing feature is an extension of the LTE1387: Intra eNodeB inter-frequency Load Balancing feature. It provides the following functionalities on top of LTE1387: Intra eNodeB inter-frequency Load Balancing: • • • •

•

4.13.1.1

Inter-frequency load balancing is supported towards all frequency layers are used for inter-frequency eNodeB mobility as well. As additional load criterion is taken the PDCCH (Physical Downlink Control Channel) load. There is no load information exchange over the X2 interface with other eNodeBs. A ”load blind” handover to reported neighbors without known CAC (composite available capacity) according to the target cell ranking is used. If a handover preparation fails caused by high load in the target cell, this target cell becomes blacklisted for iF-LB handovers temporarily. New performance counters are introduced.

Benefits End-user benefits The load is better deployed over the network. Therefore the end user gets a higher quality of his calls and a less call failure rate. Operator benefits

DN09185967 Issue: 01M

© 2016 Nokia

125



This feature benefits the operator as follows: avoiding of overload situations for specific cells by steering the traffic into less loaded cells at a different frequency layer or balance load between frequency layers

4.13.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 61

OMS


UE

NetAct

MME

SAE GW

3GPP R8


4.13.1.3

Functional description Functional overview The Flexi Multiradio BTS supports load-based inter-frequency handover between different eNodeBs connected via X2 or S1. The eNodeB monitors the source cell load to initiate load based handovers. The cell load calculation takes the following parameters for downlink into account: • • • •

physical resource block (PRB) used for GBR bearers PRBs available for non GBR users number of bearers with data in the buffer and their scheduling weights PDCCH load

All UEs changing from RRC IDLE to RRC CONNECTED become candidates for the load-based inter-frequency handover if a UE-specific timer that is started at UE context setup has expired and optionally when no QCI 1 bearer is established for that particular UE. The eNodeB triggers the load based handover if the above condition are met at expiry of the timer. The UE capabilities are taken into account as well. The load balancing handover is measurement-based with dedicated thresholds using the event A4. RSRP is used as the handover trigger together with the measurements quantities RSRP and/or RSRQ. The UE measurements are aborted if the UE does not provide a measurement report (only if the timer expires) or only measurements reports of temporarily blacklisted cells.

126

© 2016 Nokia

DN09185967 Issue: 01M



All inter-frequency target layers for the coverage-based handover are used as targets for the load based handover. The eNodeB selects the target cell for the handover preparation based on reported CAC, blacklisting status and RF condition. The cause value ”reduce load at source cell”' is used for the handover preparation. The target cell uses the CAC in addition at radio admission control thresholds to decide whether to admit or reject a handover request with the cause value “reduce load at source cell”. Handover preparation rejections with the cause value “Radio Network Layer Cause” or “Transport Layer Cause” will be used to temporarily blacklist the concerned cell for a load based handover. The blacklisting timer is operator configurable. Handover preparation rejection does not terminate load balancing for this UE. Preparation with the next target cell will be performed. Handover retries are not performed (i.e. neither after a handover request due to load balancing has been rejected nor when a load balancing handover was not successful). Separate performance counters are provided in order to capture the hand overs because of load balancing. Comparison to LTE1387: Intra eNodeB Inter-frequency Load Balancing The LTE1170: Inter-frequency Load balancing feature provides on top of the LTE1387: Intra eNodeB Inter-frequency Load Balancing feature: Table 62

Comparison to LTE1387: Intra-eNodeB IF Load Balancing

Functional Block

LTE1387 IF-LB Specific Functionalities

LTE1170 Delta Functionalities (on top of LTE1387)

Frequency Layer Used for IFLB (Inter Frequency Load Balancing)

only frequency layers which are supported by the eNodeB (intra eNodeB cells only)

All frequency layers which are used for E-UTRA interfrequency mobility HO (intra and inter eNodeB cells possible)

Measured load types

GBRdl, nonGBRdl

PDCCH (inclusive 2 thresholds - target/ high load)

Load exchange between neighbor cells

only eNodeB internal exchange

Nothing changed for eNodeB internal cells. No load exchange with other eNodeBs (no X2 procedure for this).

Start/Stop High Load Status (Entry/Exit Active IF-LB state)

Start: At least one load type's Additional load type PDCCH actual load exceeds the related high load threshold.Stop: All load types actual loads are (again) below target threshold.

Candidate UE selection (in case of high load status of own cell)

Trigger: UE does idle --> active transition and fulfills some more conditions (all what is needed for interfrequency HOs)

DN09185967 Issue: 01M

© 2016 Nokia

nothing on top

127


Table 62


Comparison to LTE1387: Intra-eNodeB IF Load Balancing (Cont.)

Functional Block

LTE1387 IF-LB Specific Functionalities

LTE1170 Delta Functionalities (on top of LTE1387)

Measurement Solicitation

A4 report with minimum threshold ttt + postprocessing of reported RSRP/RSRQ values

For all frequency layers which are used for mobility HO

Target Cell Selection

Target cells from A4 report with RSRP/RSRQ > iF-LB thresholds and CAC > 0 which are supported from own eNodeB. Ranking criterion CAC.

Cells from any eNodeB. If neighbor cell CAC is not known, the related cells are ranked lowest. A “load blind” HO to reported neighbors without known valid CAC according to target cell ranking is possible. If any iFLB HO preparation fails (for any “lack of resources” reject reason) the target cell is blacklisted temporarily for LBHOs. Blacklisting is done just in the actual source cell and NOT in all cells of the eNodeB!

LB HO

regular HO with cause nothing on top "Reduce Load in Serving Cell"

Performance Counter

none

• •

•

RAC

4.13.1.4

RAC transports load measurements from Scheduler to higher layer (load types: GBRdl, nonGBRdl)

Number of load balancing Handover attempts Number of successful load balancing Handover completions High cell load Indicator for Load Balancing

RACin addition to the already performed threshold checks considers the actual CAC of the cell. If CAC=0 the HO preparation is rejected.Additional load type: PDCCH

System impact Interdependencies between features LTE55: Inter-frequency handover is a prerequisite for LTE1387: Intra eNodeB interfrequency load balancing and LTE1170: Inter-frequency load balancing.

128

© 2016 Nokia

DN09185967 Issue: 01M



LTE1387: Intra eNodeB inter-frequency balancing: this is the basis for the iF-LB functionality. LTE1170: Inter-frequency load balancing comprises some add-ons that work only together with the basis functionality. 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 No particular overall impact on system performance is expected. If cells are in active load balancing status, the handover rate will slightly increase. Depending on the parameter settings and traffic load, the average RAN network capacity might be increased, as the UEs are moved from high loaded cells to other cells and frequency layers (inter-eNB load balancing). There is no impact on the eNB system capacity or single cell capacity as such.

4.13.1.5

LTE1170: Inter-frequency Load Balancing 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 below lists counters introduced with this feature. Table 63

Counter ID

New counters

Counter name

Measurement

M8011C69

High cell load indicator for load balancing

LTE Cell Resource

M8021C23

Number of load balancing Handover attempts

LTE Handover

M8021C24

Number of successful load balancing Handover completions

LTE Handover

Key performance indicators There are no key performance indicators related to this feature. Parameters Table below lists parameters modified by this feature.

DN09185967 Issue: 01M

© 2016 Nokia

129


Table 64

New parameters

Full name

130


Abbreviated name

Managed object

Structure

Enable interFrequency handover

actIfHo

LNBTS

Activation of interfrequency load balancing (iFLB)

actInterFreqLB

LNBTS

Prohibit Load based handover timer

prohibitLBHOTimer

LNBTS

Inter-frequency load balancing load thresholds

iFLBLoadThresholds

LNCEL

Inter-frequency load balancing QCI1 Bearer check timer

iFLBBearCheckTimer

LNCEL

iFLBLoadThresholds

iFLBHighLoadGBRDL iFLBHighLoadGBRDL (Inter-frequency load balancing GBR high load DL

LNCEL

iFLBLoadThresholds

iFLBHighLoadNonGB RDL (Inter-frequency load balancing nonGBR high load DL

iFLBHighLoadNonGBR LNCEL DL

iFLBLoadThresholds

iFLBHighLoadPdcch (Inter-frequency load balancing PDCCH high load

iFLBHighLoadPdcch

LNCEL

iFLBLoadThresholds

Inter Freq Load Bal Retry Timer

iFLBRetryTimer

LNCEL

iFLBLoadThresholds

Inter-freq load bal threshold for RSRP target filter

thresholdRsrpIFLBFilte LNHOIF r

Load filtering coefficient

lbLoadFilCoeff

LNCEL

Intra- and inter-freq. load bal. common load settings

loadSettings

LNCEL

Cell capacity class value

cellCapClass

LNCEL

© 2016 Nokia

loadSettings

DN09185967 Issue: 01M


Table 64


Full name

4.13.1.6


Abbreviated name

Managed object

Structure

Mode for calculating the CAC in load bal. and eICIC

mlbEicicOperMode

LNCEL

loadSettings

Nominal number of PRBs for load balancing

nomNumPrbNonGbr

LNCEL

loadSettings

DL GBR resource target load

targetLoadGbrDl

LNCEL

loadSettings

DL non-GBR resource targetLoadNonGbrDl target load

LNCEL

loadSettings

PDCCH target load

targetLoadPdcch

LNCEL

loadSettings

Uplink CAC source selection

ulCacSelection

LNCEL

loadSettings

Static CAC for uplink

ulStaticCac

LNCEL

loadSettings


Sales information

BSW/ASW



ASW

-

-

4.13.2 Activating LTE1170: Inter-eNB Inter-frequency Load Balancing Before you start Restart of the eNB is not required after activation of this feature. The Activation of inter-frequency load balancing (iFLB)(actInterFreqLB) parameter is used to activate the feature.

g

Note: The Activation of inter-frequency load balancing (iFLB)(actInterFreqLB) parameter activates at the same time the LTE1387: Intra-eNodeB Inter-frequency Load Balancing feature. The following parameters are used to perform an additional configuration of the feature:

DN09185967 Issue: 01M

© 2016 Nokia

131


• • • •


Inter-frequency load balancing load thresholds (iFLBLoadThresholds) Intra- and inter-freq. load bal. common load settings (loadSettings) Inter-freq load bal threshold for RSRP target filter (thresholdRsrpIFLBFilter) Prohibit Load based handover timer (prohibitLBHOTimer)

The LTE55: Inter-frequency Handover feature needs to be activated/configured before activation of the LTE1170: Inter-frequency Load Balancing feature.

Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of inter-frequency load balancing (iFLB) (actInterFreqLB) parameter value to true.

g 3


Define Inter-frequency load balancing load thresholds (iFLBLoadThresholds) a) Expand the MRBTS object. b) Expand the LNBTS object where the LTE1170: Inter-frequency Load Balancing feature is being activated. c) In each LNCEL object under selected LNBTS, repeat the following actions: 1. If the Inter-frequency load balancing load thresholds object is not available under LNCEL, right-click on the LNCEL object and select New Inter-frequency load balancing load thresholds. 2. Expand Inter-frequency load balancing load thresholds under LNCEL object. 3. Select Inter-frequency load balancing load thresholds-1 and define all the parameters within this object.

132

© 2016 Nokia

DN09185967 Issue: 01M


g

4


Note: This action is optional because the

Inter-frequency load balancing load thresholds (iFLBLoadThresholds) parameters’ structure has default values set during the object creation. The modification of the default values is not mandatory.

Define Intra- and inter-freq. load bal. common load settings ( loadSettings) a) Expand the MRBTS object. b) Expand the LNBTS object where the LTE1170: Inter-frequency Load Balancing feature is being activated. c) In each LNCEL object under selected LNBTS, repeat the following actions: 1. If the Intra- and inter-freq. load bal. common load settings object is not available under LNCEL, right-click on the LNCEL object and select New Intra- and inter-freq. load bal. common load settings. 2. Expand Intra- and inter-freq. load bal. common load settings under LNCEL object. 3. Select Intra- and inter-freq. load bal. common load settings-1 and define all the parameters within this object.

g

5

Note: This action is optional because the

Intra- and inter-freq. load bal. common load settings (loadSettings) parameters’ structure has default values set during the object creation. The modification of the default values is not mandatory.

Define RSRP target filters (optional) Sub-steps a)


b) Expand the LNBTS object where the LTE1170: Inter-frequency Load Balancing feature is being activated.

c)

In each LNHOIF object that belongs to LNBTS where the LTE1170: Interfrequency Load Balancing feature is being activated, set the Inter-freq

load bal threshold for RSRQ target filter (thresholdRsrqIFLBFilter) or the Inter-freq load bal threshold for RSRP target filter (thresholdRsrpIFLBFilter) parameter.

DN09185967 Issue: 01M

© 2016 Nokia

133


g


Note: The RSRP/RSRQ filters have predefined default values that can be used.

4.13.3 Deactivating LTE1170: Inter-eNB Inter-frequency Load Balancing Before you start Restart of the eNB is not required after activation of this feature. The Activation of inter-frequency load balancing(iFLB) (actInterFreqLB) parameter is used to deactivate the feature.

g

Note: When the

Activation of inter-frequency load balancing(iFLB) (actInterFreqLB) parameter is set to false, it deactivates also the LTE1387: Intra-eNodeB Inter-frequency Load Balancing feature.

Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activation of inter-frequency load balancing (iFLB)(actInterFreqLB) parameter value to false.

g


4.14 LTE1407: RSRQ Based Redirect 4.14.1 Description of LTE1407: RSRQ Based Redirect Introduction to the feature

134

© 2016 Nokia

DN09185967 Issue: 01M



RSRQ means reference signal received quality. RSRQ is the ratio of RSRP (reference signal received power) and RSSI (received signal strength indicator). RSSI comprises the linear average of the total received power observed only in OFDM symbols containing reference symbols for antenna port 0, in the measurement bandwidth. By the LTE1407: RSRQ Based Redirect feature, the eNB configures in the UE additional to the existing RSRP - based A2 for redirect an RSRQ based A2 event on the own serving cell. A2 event means: the serving cell becomes worse than an absolute threshold. When the UE sends this A2-RSRQ event and when it is received by the eNB, an RRC Connection Release with Redirect is triggered at the UE by the eNB. This RRC Connection Release with Redirect is covered as introduced by the LTE423: Connection Release with Redirect feature. The target carrier selection for the RSRQ- based A2 trigger is the same as for the RSRP based A2 trigger.

4.14.1.1

Benefits End-user benefits This feature benefits the end user as follows: this new function allows to handle extreme inter-cell interference scenarios where RSRP is still good enough but RSRQ is bad. The quality of connections is improved in these cases. Operator benefits This feature benefits the operator as follows: avoiding of some interference scenarios, better quality of the connections.

4.14.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 66

OMS


UE

NetAct

MME

SAE GW

3GPP R8


4.14.1.3

Functional description Functional overview

DN09185967 Issue: 01M

© 2016 Nokia

135



The scope of the feature is to redirect UEs with poor RSRQ, but with a good RSRP, where neither a handover nor an RSRP-based redirect triggers to another radio access technology (RAT) layer, which is outside of the strong interference area (red rectangle of the ). Figure 16

RSRQ vs. RSRP RSRQvsRSRP

-122

-112

-102

-92

-82

0 -72

-62

-52

RSRPbased redirect

-5

-10

-15 -15dB -16dB -17dB

-20

-18dB

-25 RSRQbasedredirect

-30

It is strongly recommended that only UEs with a quiet low RSRQ value, which is almost against the lowest one of -19dB is considered for redirect to another RAT. This is to avoid ping-long effects back from these RATs into LTE. The same measurement-object and related Id as for the serving frequency as for RSRP triggered redirect must be used for RSRQ-based triggered redirect.

4.14.1.4

System impact Interdependencies between features The following features have interdependencies to the LTE1407: RSRQ Based Redirect feature: •

•

136

LTE423: RRC Connection Release with Redirect: the activation of the LTE423: RRC Connection Release with Redirect feature is precondition for the LTE1407: RSRQ Based Redirect feature. The general procedure is reused for the LTE1407: RSRQ Based Redirect feature. LTE487: Idle Mode Mobility Load Balancing: the LTE487: Idle Mode Mobility Load Balancing feature introduces the load balancing for normal redirect targets in case of the target carriers have the same priority. A round robin assignment scheme is applied in case of there are redirect targets with the same priority. If this load balancing function is wanted then the LTE487: Idle Mode Mobility Load Balancing feature must be switched on.

© 2016 Nokia

DN09185967 Issue: 01M



It is not recommended to use the LTE1407: RSRQ Based Redirect feature in combination with SRVCC (LTE872/LTE873: SRVCC to WCDMA/GSM). 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.1.5

LTE1407: RSRQ Based Redirect 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 below lists parameters introduced with this feature: Table 67

New parameters

Full name

Abbreviated name

Managed object

Structure

RSRQ redirection parameters

rsrqRedirectParams

Time to trigger for A2 by RSRQ to start redirect

a2TimeToTriggerRedire LNCEL ctRsrq

rsrqRedirectParams

Related Hysteresis of Threshold Th4 for RSRQ

hysThreshold4Rsrq

LNCEL

rsrqRedirectParams

Threshold Th4 for RSRQ

threshold4Rsrq

LNCEL

rsrqRedirectParams

DN09185967 Issue: 01M

© 2016 Nokia

LNCEL

137


4.14.1.6



Sales information

BSW/ASW



BSW

-

-

4.15 LTE1442: Open Access Home eNodeB Mobility 4.15.1 Description of LTE1442: Open Access Home eNodeB Mobility Introduction to the feature A Home eNodeB (HeNB) is a consumer- or enterprise-deployed eNodeB with low transmit power (round about 23 dBm). HeNB is also called femtocell. The access to an HeNB might be open, or closed (Closed Subscriber group CSG), when only selected users can connect to it. The LTE1442: Open Access Home eNodeB Mobility feature supports only Open Access HeNBs. The LTE1442: Open Access Home eNodeB Mobility feature allows to redirect a UE to a (foreign vendor's) Home eNodeB (HeNB). If an HeNB Physical Cell Identity (PCI) is selected as a handover target, a UE Context Release with Redirect towards the measured frequency is triggered (instead of performing the prepared handover). The LTE1442: Open Access Home eNodeB Mobility feature describes only mobility in the direction of Nokia Macro eNodeB towards a foreign vendor HeNB. The opposite direction is not a part of the LTE1442: Open Access Home eNodeB Mobility feature.

4.15.1.1

Benefits End-user benefits This feature benefits the end user as follows: He has a better chance to get a connection, especially for greater events, like the Oktoberfest. Operator benefits This feature enables higher density of HeNBs to be deployed. More data with less voltage can be exchanged.

4.15.1.2


138

© 2016 Nokia

DN09185967 Issue: 01M



System release



RL50

LBTS5.0

LBTS5.0

Table 69

OMS

-


UE

NetAct

MME

SAE GW

3GPP R9

OSS5.5

NS4.0

NG2.1


4.15.1.3

Functional description Functional overview In the an overview of the concept of the LTE1442: Open Access Home eNodeB Mobility feature is given. Figure 17

LTE1442: Open Access Home eNodeB Mobility concept

LTE1442concept LTE1442isthe macrocellfeature Foreignvendor homeeNodeBs

NSNLTE macro network

Home eNodeBs are distinguished by an operator-configurable range of Physical Cell Identities (PCI) per frequency.

DN09185967 Issue: 01M

© 2016 Nokia

139



Only mobility because of radio reasons is applied to a Home eNodeB. An RRC connection release with redirect message is used instead of a prepared handover. The HeNBs are treated at the target cell selection with the same priority like cells connected via S1. The range of HeNB-PCI is configurable per frequency. An operator might assign a common Cell individual offset (CIO) value to this range. Cell Individual Offset (CIO) of home eNB cells is for insertion into the CIO Cell List of EUTRA Serving or Neighbor Carrier Measurement Object. CIO values for macro eNodeB(s) always have higher priority than those for home eNBs as far as the PCI of the macro eNB is not in a home eNB PCI range. This is, because 3GPP allows only signalling of 32 CIO values to an UE. The Home eNodeB (HeNB) PCI might be received in regular measurement reports intended for intra-LTE handover (both intra-frequency & inter-frequency). For handover because of Radio Reasons HeNB PCI are considered for target cell selection with the same priority as S1-neighbor cells. Support of Mobility towards Home eNodeB for Handover due to radio reasons The eNodeB supports the mobility of UEs without emergency service towards an HeNB in case a measurement report dedicated for handover because of radio reasons is received. Both handover scenarios because of radio reasons (coverage handover & better cell handover) are supported. The eNodeB accepts HeNB-PCIs within measurement reports as suitable handover targets during target cell selection. Instead of performing a prepared handover, the eNodeB initiates a UE Context Release with redirect towards the EUTRAN frequency for which the measurement report was received. No mobility towards a HeNB is allowed for other handover scenarios (for example load based handover). E-UTRAN Cell Global Identifier (ECGI) Resolution An overview of the ECGI Resolution is shown in . The LTE cells in the target cell list (TCL) reported by the UE in the A3 or A5 measurement reports are identified by their combination of PCI-EARFCN. EARFCN is the E-UTRAN absolute radio frequency channel number. Normally, if the PCI belongs to macro, the eNB performs the mapping towards the global cell-ID (ECGI). If the PCI & frequency is in range configured for HeNB PCIs, then the PCI will be treated according to the LTE1442: Open Access Home eNodeB mobility. If a radio network layer (RNL) - available - neighbor relationship (NR) is defined for the source cell pointing to the PCI-EARFCN combination, the eNB takes the ECGI from this neighbor relation. Otherwise, the eNB checks whether exactly one RNL-available neighbor cell configuration exists for the PCI-EARFCN combination. In this case the eNB takes the ECGI from this RNL-available neighbor cell configuration. If there is no matching of PCI&frequency in the source eNB, the cell is deleted from the TCL.

140

© 2016 Nokia

DN09185967 Issue: 01M


Figure 18


ECGI Resolution

ECGIresolution

PCIreportedinTCL ofmeasurementreport

Yes

PCIinrangeof HeNB-PCIs

NEW

Ne

NoECGIresolution, treataccordingto LTE1442

w

NEW

No AnRNL-available NRforthePCIexists insourcecell?

Yes

TakeECGIfrom RNL-availableNR

No

ExactlyoneRNLavailableneighborcell configurationwithmatching PCIandfrequency existsinSourceeNB

Yes

TakeECGIfrom RNL-availableneighbor cellconfiguration

No ECGIcannotbe resolved DeletePCIfromTCL

4.15.1.4

System impact Interdependencies between features The following features are partly reused for the LTE1442: Open Access Home eNodeB mobility feature: • • • •

DN09185967 Issue: 01M

LTE53: Intra and Inter eNB Handover With X2: Intra frequency measurements are reused. LTE54: Intra LTE Handover via S1: The reordering algorithm is reused. LTE55: Inter-Frequency Handover: Inter frequency handover measurements are reused. The Activation of this feature is needed as Precondition. LTE423: RRC Connection Release with redirect: The UE Context Release with Redirect message is reused to send an UE the target frequency.

© 2016 Nokia

141


•

•


LTE761: Advanced Target Cell Selection and Handover Retry for Intra Frequency Handover: TCL blacklisting and reordering of the TCL based on Network Topology are reused. LTE971: Intra-LTE Mobility Offsets: The mechanism to signal CIO values to the UE is reused. On the other hand, the LTE971: Intra-LTE Mobility Offsets feature is an affected feature as its functionality is impacted. HeNB-PCIs are excluded from LTE971: Intra-LTE Mobility Offsets handling.

The following features are not applied for the Open Access HeNBs: • • • • • • • • • • •

LTE468: PCI Management: HeNB-PCIs are excluded from PCI allocation. LTE492: ANR LTE539: Central ANR LTE782: ANR fully UE Based LTE1383: ANR Robustness LTE771: Optimization of intra-LTE Neighbor Relations LTE533: Mobility Robustness LTE1140: Intra-frequency Load Balancing LTE1170: Inter frequency Load Balancing LTE581: PRACH Management LTE962: RACH Optimization

Impact on interfaces S1-Interface: The cause IE within S1AP: UE Context Release Request is set to a new value. X2-Interface: CSG configuration information is ignored. Impact on system performance and capacity This feature impacts system performance and capacity as follows: • •

4.15.1.5

There is a higher risk for call drops as during a regular handover. There is no impact on capacity.

LTE1442: Open Access Home eNodeB 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 lists counters introduced with this feature. Table 70

Counter ID M8008C15

142

New counters

Counter name Number of UEs attempted to redirect to Home eNB

© 2016 Nokia

Measurement LTE RRC

DN09185967 Issue: 01M



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

New parameters

Full name

Abbreviated name

Managed object

Activate home eNB mobility Report amount

actHeNBMobility

LNBTS

Home eNB cell individual offset

cellIndOff

LNHENB

Home eNB EUTRA carrier frequency

freqEutra

LNHENB

Home eNB set identifier

lnHeNBId

LNHENB

Home eNB first PCI

pciFirst

LNHENB

Home eNB last PCI

pciLast

LNHENB

Structure

There are no parameters related to this feature.

4.15.1.6


Sales information

BSW/ASW



ASW

-

-

4.15.2 Activating LTE1442: Open Access Home eNodeB Mobility Before you start The feature LTE1442: Open Access Home eNodeB Mobility is activated by setting the parameter Activate home eNB mobility (actHeNBMobility) to true. The activation of this feature can be done on-line. A restart of the eNB is not needed.

DN09185967 Issue: 01M

© 2016 Nokia

143



Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object. c) Set the Activate home eNB mobility (actHeNBMobility) parameter value to true. This step activates the feature. d) Create a LNHENB object and fill in the following parameters: 1. 2. 3. 4. 5.

Home Home Home Home Home

eNB eNB eNB eNB eNB

set identifier ( InHeNBId) cell individual offset (cellIndOff) EUTRA carrier frequency (freqEutra) first PCI (pciFirst) last PCI (pciLast)

4.15.3 Deactivating LTE1442: Open Access Home eNodeB Mobility Before you start The feature LTE1442: Open Access Home eNodeB Mobility is deactivated by setting the parameter Activate home eNB mobility (actHeNBMobility) to false.

Steps

1


2

Go to the Radio Network Configuration page. a) Expand the MRBTS object. b) Select the LNBTS object.

144

© 2016 Nokia

DN09185967 Issue: 01M



c) Set the Activate home eNB mobility (actHeNBMobility) parameter value to false. This step deactivates the feature.

4.16 LTE1542: FDD Supercell 4.16.1 Description of LTE1542: FDD Supercell Introduction to the feature The LTE1542: FDD Supercell feature allows combining two “normal” overlapping cells into one supercell. The capacity of the supercell is the same as that of one of the constituent normal cells.

4.16.1.1

Benefits End-user benefits This feature can increase the throughput at cell edge in dense network deployments because of reduced interference in comparison to “normal” cells. Operator benefits This features helps to reduce the inter-cell interference in dense network deployments with slowly moving UEs.

4.16.1.2


System release



RL50

-

LBTS5.0

Table 73

iOMS

-


UE

NetAct

MME

SAE GW

3GPP R8 mandatory

-

-

-

Hardware requirements For more information on the supported hardware configurations for LTE1542: FDD Supercell, see Creating LTE Configurations.

DN09185967 Issue: 01M

© 2016 Nokia

145


4.16.1.3


Functional description Functional overview The LTE1542: FDD Supercell feature allows combining two overlapping cells in such a way that they share the same radio resources. See figure below. Each of these overlapping cells (subcells) has two transmit antennas (Tx) and two receiving antennas (Rx) system to support 2-way TX Diversity and 2x2 MIMO. The antenna systems can be located in different places or collocated.

g

Note: In case of collocation, it is not possible to use the same antenna housing 4 Rx/Tx, because antennas of each subcell cannot be correlated. If the signals from two antennas have the same phase, it is possible to create static constructive/destructive superposition. Figure 19

Super cell Singlecell withone commonPCI

The antenna systems are connected to the same Flexi System Module (FSM) via two remote radio heads/radio modules (RRH/RF Modules), which are operating on the same carrier frequency and transmit the same Physical Cell ID (PCI). The super cell combines downlink (PSS/SSS, PBCH, PDCCH, PDSCH) and uplink (PRACH, PUCCH, PUSCH) transmissions on the same PRB resources, on the same carrier via two Tx/Rx cells. It is allowed to use the LTE1542: FDD Supercell feature in high-speed scenarios (the PRACH High Speed Flag (prachHsFlag) parameter is set true) with specific antenna deployments (antennas co-located and pointing into opposite directions). For high speed, the limits of the LTE48: Support of High Speed users feature apply. The sharing of physical resources leads to the restriction that both antenna locations should have an inter-site distance less than one kilometer, because of timing advance (TA). The timing alignment between both RRHs/RF Modules must be less than or equal to 0.5μs (for more information, see Figure 20: TA alignment). This is important when the areas are overlapping and different propagation paths should not introduce additional interference. The performance degrades because of inter-symbol interference introduced when the delayed multipath reception exceeds normal cyclic prefix length. Coverage gaps between subcells are not supported. In case of coverage gaps, LTE1542: FDD Supercell does not bring benefits (the gain is very limited).

146

© 2016 Nokia

DN09185967 Issue: 01M


Figure 20


TA alignment less than 1km ~ 3us

RRH UE RRH TimingattheUEreception pointthetransmissionmustbe alignedtobe<<4.7s(normalCP) u _ u timingalignment<0.5s

eNodeB

In downlink direction, the eNB copies the physical signal of the radio interface and transmits it in both subcells using two Tx MIMO or 2-way TX Diversity. In uplink, both RRH/RFM Rx signals are combined in a 4Rx receiver using either Maximum Ratio Combining (MRC) or Interference Rejection Combining (IRC). The Operator can change the basic eNB configuration (six cells of 10MHz) to one of the following: • • •

one super cell and four “normal” cells two super cells and two “normal” cells three super cells

Every eNB reconfiguration requires eNB restart.

DN09185967 Issue: 01M

© 2016 Nokia

147


g


Note: The LTE1542: FDD Supercell feature allows to decrease UE interference and the number of HO (handovers). For more information, see Figure 21: Benefits of super cell. Figure 21

Benefits of super cell

100

100

100

RRHdifferentlocation, overlappingarea noHO

RRHdifferentlocation, partlyoverlappingarea

lessUEinterference

noHO

Tx failure handling There are two parameters defined to manage the eNB behavior in case of Tx failure: • •

txPathFailureMode (keepCellInService, disableCell) syncSigTxMode (SingleTx, TxDiv)

To keep the cell in service as long as possible, the txPathFailureMode parameter has to be set to keepCellInService. During the Tx failure, the behavior of the eNB depends on the syncSigTxMode parameter. This parameter specifies how the eNB sends the synchronization information. Table 74: Tx failure handling - configuration A shows reported alarms and super cell state in case of txPathFailureMode is set to keepCellInService and syncSigTxMode is set to TxDiv. Table 74

Tx failure handling - configuration A

Problem

Subcell 1

Subcell 2

Super cell state

Reported alarms

One Tx is faulty

DEGRADED

WORKING

DEGRADED

Alarm 7654 in one RRH/RF Module

Two Txs are faulty in the same RRH/RF Module

FAULTY

WORKING

DEGRADED


Two Txs are faulty in different RRHs/RF Modules

DEGRADED

DEGRADED

DEGRADED

Alarm 7654 in each RRH/RF Module

148

© 2016 Nokia

DN09185967 Issue: 01M


Table 74


Tx failure handling - configuration A (Cont.)

Problem

Subcell 1

Subcell 2

Super cell state

Reported alarms

Three Txs are faulty

FAULTY

DEGRADED

DEGRADED


Four Txs are faulty

FAULTY

FAULTY

FAULTY


Table 75: Tx failure handling - configuration B shows reported alarms and super cell state in case of txPathFailureMode is set to keepCellInService and syncSigTxMode is set to SingleTx. Table 75

Tx failure handling - configuration B

Problem

Subcell 1

Subcell 2

Super cell state

Reported alarms

One Tx is faulty

FAULTY in case sync signal is impacted, otherwise DEGRADED

WORKING

DEGRADED



FAULTY

WORKING

DEGRADED





FAULTY in case both faulty Tx impacts sync signal, otherwise DEGRADED

If super cell is faulty, alarm 7653 in each RRH/RF Module

FAULTY


FAULTY in case the second subcell is also faulty, otherwise DEGRADED

FAULTY

FAULTY


Four Txs are faulty

FAULTY

or If super cell is degraded, alarm 7654 in each RRH/RF Module If super cell is faulty, alarm 7653 in each RRH/RF Module or If super cell is degraded, alarm 7654 in each RRH/RF Module Alarm 7653 in each RRH/RF Module

Table 76: Tx failure handling - configuration C shows reported alarms and super cell state in case of txPathFailureMode is set to disableCell. As soon as one of the Tx antennas fails, the related subcell is faulty.

DN09185967 Issue: 01M

© 2016 Nokia

149


Table 76


Tx failure handling - configuration C

Problem

Subcell 1

Subcell 2

Super cell state

Reported alarms

One Tx is faulty

FAULTY

WORKING

DEGRADED



FAULTY

WORKING

DEGRADED



FAULTY

FAULTY

FAULTY



FAULTY

FAULTY

FAULTY


Four Txs are faulty

FAULTY

FAULTY

FAULTY


4.16.1.4

System impact Interdependencies between features The following features are prerequisites for using LTE1542: FDD Supercell: • • •

g

LTE70: Downlink Adaptive open Loop MIMO for Two Antennas or LTE703: Downlink Adaptive Closed Loop MIMO for Two Antennas has to be configured and activated. LTE72: 4-way RX diversity or LTE980: IRC for 4 RX paths has to be configured and activated (one of both). LTE614: Distributed Site has to be configured and activated so that the RRH can be located up to 20km away from the eNB. The Tx and Rx signal has to met synchronization timing requirements of LTE1542: FDD Supercell. Note: The LTE614 feature is not required if the timing is provided by radio modules located close to the eNB.

• •

LTE933: RRH Chaining has to be configured and activated when RRHs are connected to the Flexi System Module via RRH chain. LTE1045: Full SON Support for Distributed Sites has to be configured and activated. It introduces geo-location information of cells/antennas in the system. One of the features that uses those data is LTE468: PCI Management. For super cells distributed in a certain area, the Operator has to provide geo-location data that represent the sum of all sub-cells of the super cell in the best way.

The following features are not supported simultaneously with LTE1542: FDD Supercell: •

g

Note: Since LTE16, it is allowed to use the LTE1542: FDD Supercell and LTE48: Support of High-speed Users features simultaneously, provided that specific antenna deployments are in place. • •

150

LTE48: Support of High-speed Users

LTE435: RF Sharing WCDMA-LTE LTE447: SW Support for RF Sharing GSM-LTE

© 2016 Nokia

DN09185967 Issue: 01M



LTE495: OTDOA LTE568: DL Adaptive Closed Loop MIMO (4x2) LTE1195: 3-sector low power repeater interface SK-RIM

• • •

Impact on interfaces The connection between RRH and RF module has to be done via OBSAI RP03. It must support RRH/RF module chaining. Impact on network and network element management tools SON features are supported equally for super cells and “normal” cells. The super cell is a decentralized site configuration. If the super cell is not a distributed site configuration, then SON functions can be based on site geo-location data as fallback. Impact on system performance and capacity The capacity of the super cell, combined from two normal cells, corresponds to a regular 10MHz cell in a six cells eNB configuration. The number of users per cell and super cell is the same (420). The performance of the super cell, combined from two normal cells, corresponds to a normal 10MHz cell in a six cells eNB configuration. The de/activation of the super cell has an impact to all related subcells. All RRHs of a supercell reduce the power in a configurable stepwise approach (for more information, see LTE830: LTE Automatic Lock and LTE914: Graceful cell shutdown).

4.16.1.5

LTE1542: FDD Supercell management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 77: Related existing alarms lists existing alarms related to this feature. Table 77

Related existing alarms

Alarm ID

Alarm name

7654

CELL OPERATION DEGRADED

7653

CELL FAULTY

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 78: New parameters lists parameters introduced with this feature.

DN09185967 Issue: 01M

© 2016 Nokia

151


Table 78


New parameters

Full name

Abbreviated name

Activate supercell configuration

Managed object

actSuperCell

LNCEL

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

Modified parameters

Full name

Abbreviated name

Managed object

Structure

Resource list

resourceList

LCELL

Antenna line id

antlId

LCELL

Resource list

Sub cell identifier

subCellId

LCELL

Resource list

TX and RX usage

txRxUsage

LCELL

Resource list



Full name

152

Abbreviated name

Managed object

Rf sharing enabled

rfSharingEnabled

BTSSCL


actDLCAggr

LNBTS

PRS activation

actOtdoa

LNCEL

Downlink channel bandwidth

dlChBw

LNCEL

Downlink MIMO mode

dlMimoMode

LNCEL

PRACH high speed flag

prachHsFlag

LNCEL


ulChBw

LNCEL

Repeater mode activation

actRepeaterMode

LNCEL

© 2016 Nokia

DN09185967 Issue: 01M


4.16.1.6



Sales information

BSW/ASW



ASW

-

-

4.16.2 Activating LTE1542: FDD Supercell Before you start Restart of the eNB is required after activation of this feature. The Activate supercell configuration (actSuperCell) parameter is used to activate the feature. The following parameters are used to perform an additional configuration of the feature: • • •

Downlink MIMO mode (dlMimoMode) Resource list (resourceList) set of parameters Activate flexible base band usage (actFlexBbUsage)

The following features need to be activated/configured before activation of LTE1542: FDD Supercell: • • •

g

LTE70: Downlink Adaptive open Loop MIMO for Two Antennas or LTE703: Downlink Adaptive Closed Loop MIMO for Two Antennas has to be configured and activated. LTE72: 4-way RX diversity or LTE980: IRC for 4 RX paths has to be configured and activated (one of both). LTE614: Distributed Site has to be configured and activated so that the RRH can be located up to 20km away from the eNB. The Tx and Rx signal has to met synchronization timing requirements of LTE1542: FDD Supercell. Note: The LTE614 feature is not required if the timing is provided by radio modules located close to the eNB.

• •

LTE933: RRH Chaining has to be configured and activated when RRHs are connected to the Flexi System Module via RRH chain. LTE977: RF chaining has to be configured and activated when RFs are connected to the Flexi System Module via RFs chain.

The following features have to be deactivated before activation of LTE1542: FDD Supercell: • • • • • •

DN09185967 Issue: 01M

LTE48: Support of high speed users LTE435: RF sharing WCDMA-LTE LTE447: SW support for RF sharing GSM-LTE LTE495: OTDOA LTE1089: Downlink carrier aggregation - 20 MHz LTE1195 Repeater Interface Unit

© 2016 Nokia

153



Procedure 1


2

g

Go to the Cell resources page. Note: Modification of some parameters causes eNB restart. a) In the Super cells section select Activate supercell configuration (actSuperCell).

g

Note: This parameter activates the feature. b) Assign sub cell IDs to the TX and RX antennas according to the one of the supported configurations (for more information on the supported hardware configurations for LTE1542: FDD Supercell, see Creating LTE Configurations).

g

Note: Modification of sub cell IDs causes BTS restart. c) Set the Downlink MIMO mode (dlMimoMode) parameter value to one of the following values: • • •

g 3

TXDiv Dynamic Open Loop MIMO Closed Loop MIMO Note: Modification of the Downlink MIMO mode (dlMimoMode) parameter causes BTS restart.

Go to the LTE Carriers page. a) In the table Downlink (TX) carriers set the Downlink channel bandwidth (dlChBw) parameter value to 10 MHz. Set also the relevant EARFCN value (the Uplink channel bandwidth (ulChBw) parameter will be filled in automatically).

4

Go to the Radio Network Configuration page. Sub-steps a)

154

Expand MRBTS object.

© 2016 Nokia

DN09185967 Issue: 01M



b) Select LNBTS object.

c)

Set the Activate flexible base band usage (actFlexBbUsage) parameter to true.

Expected outcome The LTE1542: FDD Supercell feature combines “normal” overlapping cells into super cell(s).

4.16.3 Deactivating LTE1542: FDD Supercell Before you start The Activate supercell configuration (actSuperCell) parameter is used to deactivate the feature. Deactivation of this feature requires the eNB restart. Procedure 1


2

Go to the Cell resources page. a) In the Super cells section deselect Activate supercell configuration (actSuperCell).

g

Note: This parameter deactivates the feature. b) Configure “normal” cells according to the selected transmission mode.

Expected outcome The LTE1542: FDD Supercell feature does not combine “normal” overlapping cells into super cell(s).

4.17 LTE1680: Active Queue Management 4.17.1 Description of LTE1680: Active Queue Management Introduction to the feature

DN09185967 Issue: 01M

© 2016 Nokia

155



The LTE1680: Active Queue Management feature introduces an improved packet data convergence protocol (PDCP) packet discard mechanism with Active Queue Management (AQM) using a timer-based discard probability function. Dependent of the load situation respectively overload network situation the RL40/RL25 may discard too many packets in the PDCP buffer. This might lead to long enduring stalling situations in transmission control protocol (TCP) - connections or even to TCP disconnections.

4.17.1.1

Benefits End-user benefits The end-user get an improved TCP/IP user experience for mobile communication services. Operator benefits This feature benefits the operator as follows: the operator gets more satisfied TCP/IP using customers.

4.17.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 82

OMS


UE

NetAct

MME

SAE GW

3GPP R8


4.17.1.3

Functional description Functional overview The main goal of the LTE1680: Active Queue Management is to improve the TCP/IP user experience in downlink direction. Especially long enduring TCP stalling conditions are mitigated or even avoided. The improvement is done with an Active Queue Management (AQM) in the DL PDCP buffer. The AQM application is limited to Data Radio Bearers with QoS class identifiers (QCIs) 1 - 9.

156

© 2016 Nokia

DN09185967 Issue: 01M



PDCP buffer AQM Discard Mechanism The PDCP buffer entity AQM discards PDCP service data units (SDUs) from the PDCP buffer entity with using a friendly packet discard mechanism. The AQM Discard prerequisites are: 1. The AQM uses the sojourn time (tS) of each packet in the PDCP buffer to determine a discard criterion for discard packets out of the PDCP buffer. The sojourn time (tS) of each packet in the PDCP queue is measured between the en-queuing of the packet into the PDCP buffer and the de-queuing of the packet. 2. The discard criterion is determined for each oldest PDCP packet when it is just dequeued, according the following decision process: a) I If the sojourn time of the oldest packet is less or equal the start threshold of the discard probability function (threshold st) no packets are discarded. b) If the sojourn time of the oldest packet is greater than the threshold st a time stamp is fed into the packet discard probability function. c) I If the packet discard probability function decides that a packet shall be discarded then the newest received PDCP SDU packet into the PDCP buffer is discarded. PDCP buffer AQM packet discard probability function. To provide a TCP-friendly discard mechanism the PDCP AQM uses a packet discard probability function that mitigates or avoids burst packet discards. A discard probabilities function is shown in Figure 22: discard probability function.

Threshold “st”

Threshold “tD”

discard probability function

PDCP!packet!drop probability![%]

Figure 22

3%

2%

max_discard

1%

0% 60%

100%

PDCP!packet sojourn!time,!t S

tDiscard!=!tD:

start!threshold!of!the discard!Prob.!Fct.; start_threshold!=!st

st=st_percentage*tD; in!the!example!above!st+percentage!=!60% DiscardProbability(t<st) S

=0%; [t>0]; S

DiscardProbability(st<t<tD) S

=1*

DiscardProbability(t>tD) S

=1%;

DN09185967 Issue: 01M

(t-st)**4 S (tD-st)**4

[%];

© 2016 Nokia

157



In RL50: • •

The max_discard (the maximum PDCP packet drop probability) is set to 1%. The st_percentage is set to 60%.

The AQM packet discarding is applied exclusively to data radio bearers (DRBs) with QCIs 1-9.

4.17.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 impacts system performance and capacity as follows: The system performance of TCP/IP services in DL is improved.

4.17.1.5

LTE1680: Active Queue Management 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.17.1.6


158

Sales information

BSW/ASW



BSW

-

-

© 2016 Nokia

DN09185967 Issue: 01M


Descriptions of transport and transmission features

5 Descriptions of transport and transmission features 5.1 LTE505: Transport Separation for RAN Sharing 5.1.1 Description of LTE505: Transport Separation for RAN Sharing Introduction to the feature The feature complements functionality of LTE4: Multi-Operator Core Network, which enables eNBs in the Radio Access Network (RAN) to operate with multiple core networks (MMEs and S-GWs) of different operators. With LTE505: Transport Separation for RAN Sharing operators, the eNB supports two Uplane IP addresses and two C-plane IP addresses.

5.1.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 RAN Sharing scenario where IP networks for mobile backhaul are separately administered.

•

5.1.1.2

Requirements Software requirements The following table lists the software required for this feature. Flexi Zone Micro BTS

System release



RL50

Not relevant

LBTS5.0

Table 84


OMS

LBTS7.0

Not relevant

UE

NetAct

MME

SAE GW

Not relevant

Not relevant

Not relevant

Not relevant

Hardware requirements This feature requires a Flexi MR10BTS.

DN09185967 Issue: 01M

© 2016 Nokia

159


5.1.1.3


Functional description This section covers the following feature-specific concepts: • • •

IP addressing Handover Quality of service

IP addressing The eNB supports two IP addresses for: • •

U-plane (U1@ for operator 1, U2@ for operator 2) C-plane (C1@ for operator 1, C2@ for operator 2)

M-plane and S-plane are owned by one of the operators. The eNB supports a single Mplane (M@) and a single S-plane (S@) application address. The IP addresses and corresponding VLAN's can be shared, eg. U1@=C1@, M@=S@. The eNB addresses must be different per operator: U1@?U2@, C1@?C2@. There is no restriction as to SAE-GW and MME IP addresses, i.e. same addresses may be used in the different core networks, if IPsec is applied within the eNB or policy based routing, for example source based routing, is done in the backhaul network. Handover There is only one SCTP association established between eNB pairs (3GPP TS 36.422). • •

All X2C traffic needs to go via one C-plane IP address of one eNB All X2U traffic needs to go via one U-plane IP address of one eNB

S1 HO happens at the border between operator areas. Quality of Service: Transport capacity reservation through dedicated VLAN(s) per operator QoS scheduling and shaping per each VLAN. The same QCI to PHB/DSCP/p-bit mapping is used for both operators. Transport security with IPSec for RAN Sharing is not included in this feature, but additions will be handled separately with the feature LTE523 Multilayered Certificate Authorities. Figure 23: Maximum number of VLANs shows the VLAN configuration, in which all application addresses are different from each other.

160

© 2016 Nokia

DN09185967 Issue: 01M


Figure 23


Maximum number of VLANs Operator1

U1 MME C1 IPsecTunnel1 M

VLAN1 ToP

O&M

SAE-GW

S

Operator2 VLAN2

U2

eNB

IPsecTunnel2 C2

MME

SAE-GW

S1/X2U-planeapplication S1/X2C-planeapplication M-planeapplication S-planeapplication

5.1.1.4

U C M S

Physicalinterface (Ethernet) Logicalinterface (VLAN)

System impact Interdependencies between features The following features are a prerequisite for taking the new feature into use: • • •

LTE4: Multi-Operator Core Network LTE132: VLAN Based Traffic Differentiation LTE689: LTE IPsec Support

The LTE2: S1 Flex feature can be applied in combination with LTE505: Transport Separation for RAN Sharing. Nevertheless, the maximum number of 16 MMEs is in that case divided between the operators. The same applies to the total number of S-GW (32 addresses) and eNBs (32 peers). The feature LTE523: Multi-Layered Certificate Authorities enables efficient Public Key Infrastructure (PKI) certificate management. It is assumed that operator will choose to activate LTE523: Multi-Layered Certificate Authorities as opposed to implementing nonscalable solution (pre-shared keys), or other less cost-effective key management approach. Nevertheless LTE523: Multi-Layered Certificate Authorities activation is not a mandatory prerequisite for LTE505: Transport Separation for RAN Sharing. Impact on interfaces This feature impacts the interfaces as follows: • •

The eNB Ethernet interface must support six interface addresses (VLANs) According to 3GPP TS 36.422 specification only one SCTP association can be established between eNB pairs. Therefore, on any given X2 interface, X2-C traffic must go through one C-plane address of one eNB.

Impact on network and network element management tools Only one of the operators manages the S-plane and M-plane of the shared RAN. Otherwise, this feature has no impact on network management or network element management tools.

DN09185967 Issue: 01M

© 2016 Nokia

161



Impact on system performance and capacity This feature does not affect overall LTE system capacity or performance. However, available system resources are shared among operators.

5.1.1.5 5.1.1.5.1

LTE505: Transport Separation for RAN Sharingdescription-module management data 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 85


Alarm ID

Alarm name

7650

BASE STATION FAULTY

7651

BASE STATION OPERATION DEGRADED

7656

BASE STATION CONNECTIVITY LOST

7657

BASE STATION CONNECTIVITY DEGREADED

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. Table 86

New parameters

Full name

Abbreviated name

Managed object

Additional Transport Network 1 MME IP Address List

addTransportNw1MmeIpAddrList

ADIPNO

Transport network 1 identifier

transportNw1Id

ADIPNO

Additional transport network 1 SGW IP address list

addTransportNw1SgwIpAddrList

GTPU

Transport network 1 identifier

transportNw1Id

GTPU

162

© 2016 Nokia

DN09185967 Issue: 01M


Table 86



Full name

Abbreviated name

Managed object

Activation Flag Transport Separation For RAN Sharing

actSeparationRanSharing

IPNO

Additional Transport Network IP Address List

addTransportNwIpAddrList

IPNO

User Plane IPv4 Address

addUPlaneIpv4Address

IPNO

Transport Network Identifier

transportNwId

IPNO

Main Transport Network Identifier

mainTransportNwId

IPNO

Transport network identifier

transportNwId

LNMME

Transport Network Identifier

transportNwId

LTAC

lists existing parameters related to this feature. Table 87


Full name

Abbreviated name

LTAC identifier

5.1.1.6

ltacId

LTAC


5.1.1.7

Managed object

Sales information

BSW/ASW



ASW

-

-

Abbreviations CN - Core Network DSCP - Differentiated Services Code Point IPsec - Internet Protocol Security PHB - per-hop behavior QCI - Quality of Service Class Identifier QoS - Quality of Service

DN09185967 Issue: 01M

© 2016 Nokia

163



RAN - Radio Access Network SEG - security gateway VLAN - Virtual Local Area Network

164

© 2016 Nokia

DN09185967 Issue: 01M


Descriptions of operability features

6 Descriptions of operability features 6.1 LTE507: Inter-RAT Neighbor Relation Optimization 6.1.1 Description of LTE507: Inter-RAT Neighbor Relation Optimization Introduction to the feature NetAct Optimizer/cSON supervises all registered Inter Radio Access Technology (InterRAT) neighbor cell relations between LTE cells and non-LTE cells. Their performance is good enough so they are used for handover (HO) execution. When the outcome results in an inefficient neighbor relation (NR), the individual mobility procedures of NRs might be blacklisted for HO.

6.1.1.1

Benefits End-user benefits This feature benefits the end user as follows: The HOs/mobility procedures are expected to get more stable. Failures and/or call drop are reduced. The feature increases the grade of service for the end user by maintaining well performing and robust neighbor relations (mobility procedures).

• • •

Operator benefits This feature benefits the operator as follows: The operator can reduce operating expenses (OPEX) because of reduced workload in managing NRs.

•

6.1.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 89

OMS

iOMS


UE

NetAct

MME

SAE GW

-

OSS5.5

-

-

Hardware requirements

DN09185967 Issue: 01M

© 2016 Nokia

165



This feature requires no new or additional hardware.

6.1.1.3

Functional description Functional overview The LTE507: Inter-RAT Neighbor Relation Optimization feature is intended to manage and optimize the use of inter-RAT NRs between LTE and WCDMA or between LTE and GSM for a defined set of mobility procedures, which transfer UE from one LTE cell to a cell of the other RAT. The goal of the feature is to keep only stable and reliable NRs active for given mobility procedures. To this end the NetAct evaluates the performance measurement data of all NRs between LTE and GERAN, as well as LTE and UTRAN cells. If the NetAct detects that a mobility procedure of an NR causes many failed HOs, the NetAct will blacklist the respective inter-RAT mobility procedure of this relationship. The LTE507: Inter-RAT Neighbor Relation Optimization feature offers independent optimization support for three UTRAN and one GERAN mobility procedures. The optimization works with independently defined thresholds and scheduler time setups per each mobility procedure per each RAT. Additionally, the LTE507: Inter-RAT Neighbor Relation Optimization feature describes manual operator use cases for completeness. Those show the possible interworking of the feature with manual operator configurations. RAN System Level Feature Scope The LTE507: Inter-RAT Neighbor Relation Optimization is a centralized SON feature, that operates on existing inter-RAT neighbor relations (NRs) from LTE cells towards interRAT GERAN/UTRAN neighbor cells. Those can be configured by the operator, learned from automatic neighbor relation (ANR) functions or generated by off-line tools via interface N (Itf-N). Handover (HO) performance counters and key performance indicators (KPIs) are collected for each defined NR for each mobility procedure as defined in the LNBTS feature activation. The administration of measurement and performance management (PM) data collection is expected to run for the whole NetAct cluster. It is a prerequisite out of the scope of the LTE507: Inter-RAT Neighbor Relation Optimization feature. NetAct evaluates the HO performance counters and KPI, and blacklists the mobility procedures of NRs in case it has an insufficient HO success ratio. The feature prerequisite is, that the required NR PM counters are available on such a granularity that the NetAct can aggregate them over a daily or weekly period for each specific mobility procedure. For statistical reliability purpose, NetAct includes only neighbor relations with a minimum, user-defined amount of HO attempts for mobility procedures into the optimization evaluation. If for such NRs NetAct detects insufficient HO performance (for example, too low HO success ratio) for a specific mobility procedure, NetAct configures to forbid the use of the respective mobility procedure at the respective NRs (blacklisting). If statistical reliability (for example, number of HO attempts) is not reached, NetAct excludes the respective mobility feature of the respective NR from the optimization evaluation. The operator can control the feature with a network/cluster profile setting. The feature does not delete relations, since UE-based ANR features would reestablish deleted relations again. Therefore, the feature keeps the relationship as such and flags the relationship as “forbidden for handover”; in other words blacklists a certain mobility procedure of an (inter-RAT) neighbor relation. At NetAct the user can execute the feature in the following ways:

166

© 2016 Nokia

DN09185967 Issue: 01M



workflow-based execution

•

– –

Workflow can be started by the user interactively from a NetAct UI. Workflow can be scheduled by NetAct using SON scheduler UI. In this case, the user can define a stop point to get access to the manual verification before provisioning.

manual execution of the workflow

•

– –

interactive execution The user is starting/giving any needed input via NetAct/cSON UIs interactively.

During or after the execution of an optimization run, the user is informed about the activity and the results of the session. In interactive or workflow-based execution with a stop point, the user can modify the proposed CM changes individually. The user can define manually neighbor relations from being excluded from the automated evaluation of the feature (for example, for whitelisting the operator applies the settings to “allow handover” and excludes this neighbor relation to be managed by this SON function). Result of the optimization mechanisms: no action An analyzed relation showed no suspect behavior. blacklisting A given relation was identified to be unreliable/weak performing. NetAct proposes to blacklist certain mobility procedure/-s of respective (inter-RAT) NRs.

• •

The changes, proposed by the optimization algorithms, can be taken over automatically (without any operator interaction) or after confirmation by the operator.

g

Note: If the operator does not provision plan files immediately to the network, then more and more plans might exist. Operator should remove not executed plan files. Old plan files might become outdated quickly and commissioning or validation error might occur. Also successfully provisioned plans are not deleted automatically. Temporary, intermediate plans created by system in the background are deleted automatically after certain time set in the Configurator’s settings. Configuration of the feature per mobility procedure (for example via preference settings in NetAct) For UTRAN: • •

inter-RAT handover to WCDMA (from LTE) and CS fallback to UTRAN (from LTE): can be executed only together (individually only manually) single-radio voice call continuation (SRVCC) to WCDMA (from LTE)

For GERAN it is SRVCC to GERAN functionality only. Managing the usage of inter-RAT GERAN or UTRAN neighbor relations for the following specified mobility types

DN09185967 Issue: 01M

© 2016 Nokia

167



The user is able to control for each neighbor relation for each mobility procedure individually, whether: • •

the neighbor relation can be used by this mobility procedure the feature is allowed to optimize (for example, to disallow) the given neighbor relation/mobility procedure.

To this end the BTS provides per Radio Access Technology (RAT) and its neighbor relation mobility procedures a control parameter: 1. xyzAllowed = allowed/forbidden to allow UE using given mobility procedure for the given neighbor relation. xyz in the parameter name indicates the respective mobility procedure. 2. nrControl = automatic/manual to define whether the feature optimizes (for example, set xyzAllowed=forbidden) the neighbor relation. Blacklisting means forbidding a given mobility procedure of a neighbor relation by setting the corresponding parameter in the BTS to forbidden. Remove the blacklisting of inter-RAT GERAN UTRAN neighbor relations manually, separately for each mobility type Removing the blacklisting of an individual mobility procedure at a given neighbor relation means to set the mobility procedure in this neighbor relation to allowed and to set nrControl to automatic to allow the present feature to optimize this neighborship. Whitelist inter-RAT GERAN or UTRAN neighbor relations manually, simultaneously for all mobility types towards one target RAT Whitelisting means to allow the mobility procedure for a given neighbor relation unconditionally, for example it is not subject of neighbor list optimization. Thus the mobility procedure of NR is set to allowed, while optimization is suppressed by setting nrControl = manual. Policy The operator can configure the NR optimization algorithm with a set of user-given or globally defined parameters (policies). The main control is the network-wide threshold of not acceptable HO performance for each mobility procedure and the amount of mobility events to ensure statistical reliability. The procedures are designed to work automatically based on policy settings for all cells and their NR on network or NetAct scope. By default LTE507: Inter-RAT Neighbor Relation Optimization considers all NR. The operator can switch to manual mode for each NR and configure the black/white listing individually for each mobility procedure. Then this NR and the specific mobility procedure is not considered by LTE507: Inter-RAT Neighbor Relation Optimization anymore. Reporting The operator can investigate the output of the automated process and optionally verify the proposed changes, respectively investigate the applied changes. NetAct is informing the operator about the progress of the feature sub-function for each cell or eNB. The following reports are shown for each enabled mobility procedure: • • •

168

total and done number of cells or eNBs number of checked neighbor relations (NRs) blacklisted mobility procedure

© 2016 Nokia

DN09185967 Issue: 01M


•


ignored NR

After the scheduled execution of the algorithm if the stop point is enabled, the operator can verify and if wanted, modify the proposed configuration changes (blacklist proposals). The operator then has to continue manually the provisioning process. For all accepted CM changes, NetAct adds context information related to the feature to support the creation of SON reports (LTE1019: SON Reports). The operator can retrieve from CM History the changes initiated by LTE507: Inter-RAT Neighbor Relation Optimization. PM data The generation of PM data is independent of LTE507: Inter-RAT Neighbor Relation Optimization functionality. The operator usually runs PM data generation for several features with different granularity period requirements. Basic raw PM counters at S1 interface are running in typical 15 min. or 1h granularity period with respect to dedicated mobility procedures like SRVCC, CSFB and PS HO. Those are separately accumulated and aggregated to KPI values for each mobility procedure with different schedule. LTE507: Inter-RAT Neighbor Relation Optimization sub features work on KPI values at least on daily and optionally on weekly basis for each existing NR. NetAct informs the operator on the non-availability of PM data in the feedback information. Inter-RAT GERAN or UTRAN NR data Inter-RAT GERAN or UTRAN NR are found in the network based on UE activity, or are pre-configured by the operator. An existing NR is represented by an instance of the MOC LNRELG for GERAN and LNRELW for UTRAN (WCDMA). Blacklisting LTE507: Inter-RAT Neighbor Relation Optimization manages the blacklisting or inter-RAT NR via the dedicated LNRELW and LNRELG instances. For each mobility type the NR can be blacklisted individually. The feature does not consider the band or frequency allocation of the neighbor inter-RAT cells among themselves. Ongoing changes in user behavior, topology and deployment will change the need for blacklisting. To obtain a new judgment of the performance of an NR, from time to time this blacklisting need to be switched back manually to allow handover (HO). Within the feature this adaptation is not done automatically. Handover performance The overall HO performance can be jeopardized by single NRs that have high failure ratios for a significant number of HO attempts. This feature aims on a high number of HO attempts and long supervision period, for statistical reliability, or single UE activity. Therefore, no further consistency checks are planned to identify other root causes of malfunction. Additionally, the operator has the possibility to request a high HO success ratio or otherwise blacklist the NR. At required HO success ratios above 95%, there are often mobility, coverage, load, speed or mobility robustness (MRO) problems in overlay. Blacklisting cannot solve those problems and further network optimization activities are required to find the root cause. Therefore, the setting of the feature thresholds has to be in-line with the overall network configuration quality. The higher the threshold the less blacklist proposal will come. NetAct Optimizer/cSON informs the operator, if more than a user-configurable amount (for example, 50%) of NR are blacklisted by the feature and

DN09185967 Issue: 01M

© 2016 Nokia

169



manual operator action. Areas with a high amount of cells having blacklisted mobility procedures can be investigated with other SON functions on mobility (PCI, pRACH, ANR), coverage, load, speed or mobility robustness (MRO) problems. NetAct Optimizer/cSON NetAct Optimizer/cSON supports preference settings and workflow execution for the feature separated for each mobility procedure and RAT: for GERAN SRVCC and for UTRAN SRVCC, PS HO and CSFB with PS HO (PS HO and CSFB with PS HO can be automatically blacklisted only together). NetAct Optimizer/cSON supports the reading of aggregated daily or weekly PM data (from raw PM data) for the feature. For each actual NR and for each mobility procedure per RAT the inter-RAT PM performance is required. In detail, the handover (HO) success ratio and the number of HO attempts. NetAct Optimizer/cSON generates the required KPI based on the aggregated performance management (PM) counters. NetAct Optimizer/cSON supports the activation of feature function manually triggered and interactively controlled by the operator. In addition NetAct Optimizer/cSON with NetAct Configurator support activation of the function as a scheduled work-flow that executes automatically based on globally defined settings. Manual trigger: NetAct Optimizer/cSON supports manual trigger of the feature for a defined scope of eNB or cells. The operator can interactively provide all required policy data to run the function for a specific mobility procedure and RAT. In detail the thresholds for the required number of HO attempts and the expected HO performance limit. NetAct Optimizer/cSON reports the progress of the feature session. In case of NetAct Optimizer: After all NR are checked, the operator obtains an execution report and a plan file containing the blacklisted NR for this mobility procedure and the corresponding SON report context information (LTE1019) for NetAct Configurator. The delta plan file is the basis for further operator action (visualization or provisioning to the network) within NetAct Configurator. In case of cSON: •

•

After cSON has run in open-loop mode the operator obtains a report file that lists all newly blacklisted NR for this mobility procedure. This report cannot be downloaded and activated in the NE. When cSON runs in closed-loop mode it generates a plan file with all newly blacklisted NR for this mobility procedure. cSON downloads and activates this plan in the NE unconditionally.

If LTE507: Inter-RAT Neighbor Relation Optimization is executed for the first time, then the policy setting starts with default values. Consecutive executions start with the previous user settings. Scheduled the LTE507: Inter-RAT Neighbor Relation Optimization (LTE, UTRAN, GERAN) feature workflow execution via workflow engine (WFE):

170

© 2016 Nokia

DN09185967 Issue: 01M



NetAct Optimizer/cSON supports within a pre-set policy, for each mobility procedure per RAT, the scheduled execution of the feature-related workflow by the workflow engine within the scope of all NetAct-controlled LTE cells. The policy supports the following settings for each mobility procedure per RAT: • • •

• • •

scheduler activation/deactivation scheduler time control (start/stop, periodic start time/day/week/month) feature control parameter (number of HO attempts per week (optional day), required HO success ratio, fix threshold for informing the user about number of neighbor relations per cell that have at least one of the mobility features in blacklisted state. Those that are blacklisted in the template might be excluded) in case of Optimizer: execution control (stop-point) in case of cSON: open-loop mode to result in report only or closed-loop mode to download and activate modifications in the network elements. execution report generation (level of details)

NetAct executes the feature based upon the policy for each mobility procedure and RAT. The specific analysis of the inter-RAT NR performance is based on the latest generated KPI data. If the raw counters are available and the KPIs have not been generated, NetAct attempts to create them. cSON reads raw counters from NetAct, aggregates them and calculates KPI for the last 24 h. NetAct Optimizer/cSON supports a scheduled SON function that is executed without further operator activity. NetAct Optimizer/cSON considers the operator decision to exclude certain inter-RAT NR from being changed by LTE507: Inter-RAT Neighbor Relation Optimization. NetAct Optimizer/cSON informs the operator about the performance (for example: number of blacklisted neighbor relations) or problems (for example: no PM data available) of the SON function. The report does not show the result of the operator controlled inter-RAT NR. cSON in closed-loop mode/NetAct Optimizer exchanges the newly found inter-RAT NR that need to be blacklisted, for the specific mobility procedure and RAT, towards NetAct Configurator to provision this into the actual network. Manual the LTE507: Inter-RAT Neighbor Relation Optimization (LTE, UTRAN, GERAN) feature workflow execution via WFE: The start of the scheduled workflow can be triggered manually as well. NetAct Configurator NetAct Configurator provides the current Inter-RAT neighbor relations itself and their status to NetAct Optimizer/cSON. This covers all the eNB objects LNRELG/W with their parameters for HO control, for example: •

•

LNRELG: eNACCAllowed (not for automated LTE507: Inter-RAT Neighbor Relation Optimization - only for manual use cases), srvccAllowed, redirWithSysInfoAllowed (not for automated LTE507: Inter-RAT Neighbor Relation Optimization - only for manual use cases), nrControl LNRELW: psHoAllowed, srvccAllowed, csfbPsHoAllowed, nrControl

NetAct Configurator supports generic configuration functions for the delta plan file: •

DN09185967 Issue: 01M

edit the plan file, for example remove changes to be done to the network,

© 2016 Nokia

171


•


download and activate at the eNBs.

NetAct Configurator supports configuration of the LNRELG/W parameter for HO control and NR-control. NetAct Configurator or Optimizer/cSON optionally stops and terminates the workflow at the defined break-point, to allow the operator to verify and modify the generated plan file before implementing in the network. eNB The operator has the possibility to exclude automated operation by LTE507: Inter-RAT Neighbor Relation Optimization for each single inter-RAT NR, to configure persistently any wanted setting. The eNB supports a persistent parameter NR-control for each Inter-RAT NR, to control LTE507: Inter-RAT Neighbor Relation Optimization access. The operator can set NRcontrol to “manual” to exclusively access the black-list settings of each single NR. The NetAct LTE507: Inter-RAT Neighbor Relation Optimization SON function interprets NRcontrol setting to “automatic” to be allowed to write to the specific mobility procedure black-listing settings. The centralized and decentralized inter-RAT ANR function will find additional inter-RAT neighbor cells and NR, those allow, by default LTE507: Inter-RAT Neighbor Relation Optimization automated procedures for this NR. Having NR control at eNB supports also BTSSM user activity to set own blacklisting and exclude LTE507: Inter-RAT Neighbor Relation Optimization. The Inter-RAT NRs upgraded from an earlier release are by default allowed to be optimized. Use cases The following use cases are supported: •

•

•

g

Neighbor cell relations which have an insufficient handover performance (for example weak handover success rate; threshold is operator-configured) may be blacklisted by an optimization mechanism or, optionally, manually by an operator. Neighbor cell relations which had been blacklisted, can be un-blacklisted again by the operator (for example, if an operator wants to re-evaluate the performance of a formerly blacklisted NR because of changed environment/topology). Neighbors cell relations can be marked by an operator in a way that they are excluded from optimization (whitelisting). Note: In case when a neighbor cell is blacklisted, no outgoing handover to the target cell is allowed.

Fully manual execution of all three use cases: The user can change all relevant parameters manually from the respective NetAct user interfaces like for example, Configurator CM Editor or Optimizer/cSON Browser. The changes can be saved to a configuration plan file and provisioned with standard NetAct functionality to the network elements. Execution of the blacklisting, interactively from a graphical user interface (for example. in the NetAct Optimizer/cSON) According to given user policies, an automated algorithm proposes poorly performing neighbor relations to be blacklisted.

172

© 2016 Nokia

DN09185967 Issue: 01M



1. The user selects, in a standard way, the set of network elements (“scope”) for the optimization. 2. The user selects the policies according to which the algorithm is executed. 3. If not automatically retrieved, the user retrieves manually the needed performance management indicators for the desired time and aggregation level. 4. The user starts the execution of the algorithm. 5. The NetAct validates the needed input data and gives the user information about exceptions in a hierarchical detail level. 6. The NetAct keeps the user informed about the progress and the result of the blacklisting algorithm. 7. The user verifies the results and can still modify manually the proposals. 8. The user saves the end result to a plan file, the NetAct adds context information to support SON reports. 9. The user makes the plan available for standard NetAct provisioning tools and provisions manually the plan to the network. 10. The network informs the NetAct about the success of the provisioning and the NetAct updates the configuration database with the actual configuration. Execution of the blacklisting, using a workflow, triggered by a scheduler (for example NetAct Configurator SON Scheduler) Similar steps as in manual, inter-active execution are collected and implemented to a workflow and executed as a service: 1. The user defines the input scope of the optimization. If no scope is given, the whole actual NetAct cluster is considered as the scope. 2. The user selects the values for the set of needed input parameters (policy) according to which the algorithm is executed. 3. The user defines, if the execution is stopped with a stop point before provisioning to the network happens. 4. The user defines the name of the plan file that collects the results. NetAct appends a unique identifier (for example, the time of execution) to make the plans unique in case of recurring executions. 5. From a graphical user interface (for example, NetAct SON Scheduler), the user defines the time/-s of execution. 6. At any time of execution (one-time or recurring), the scheduler starts the execution. 7. The NetAct validates the input data. If the needed (key) performance indicators are not readily available, NetAct tries to retrieve them from raw NetAct counters or external PM tool for the given execution time and aggregation (in NetAct PM solution, precondition is, that the relevant measurements have been activated). If the KPIs are not ready available, the underlying raw counters cannot be retrieved for KPI creation and the ready KPIs cannot be imported for ALL mobility procedures for ALL of the neighbor relations in the scope. The execution will be aborted in error and no plan file will be generated. The user is informed about this situation in the feedback messages. If the input needed data is validated for some mobility procedures for some neighbor relations in scope, those will be considered by the LTE507: Inter-RAT Neighbor Relation Optimization feature. For the reminder (no data available), the evaluation of the performance of the mobility procedure at a neighbor relation will be skipped and no action created for these particular cases. 8. The NetAct keeps the user informed about the progress and the result of the blacklisting algorithm by relevant feedback information stored in a feedback repository. The user is able to define the level of feedback information.

DN09185967 Issue: 01M

© 2016 Nokia

173



9. TheNetAct saves the results to a plan file and makes it available for provisioning. During saving, NetAct adds context information for the support of SON reports and CM history. 10. If a stop point was defined, the execution ends here and the user has a possibility to verify the proposals, modify them manually and proceed manually.

g

Note: Removal of outdated plan files from earlier execution is not a part of the LTE507: Inter-RAT Neighbor Relation Optimization feature, but requires manual user action with standard available NetAct functionality. 11. If no stop point was defined, the execution continues automatically with standard provisioning to the network. 12. The network will inform NetAct about the success of the provisioning and NetAct will update the configuration database with the actual configuration. Execution of the blacklisting, using a workflow, triggered manually from a graphical user interface for immediate execution (for example from NetAct Configurator Operations Manager UI) The user has the possibility to give the same input as in the previous case. The same workflow is executed immediately after pressing a start button. The feedback information is additional to previous case also presented in-time in a graphical user interface.

6.1.1.4

System impact Interdependencies between features The ANR features and the basic neighbor management provide the NR. •

•

•

•

•

LTE510: Synchronization of Inter-RAT Neighbor Relations (RL30) This feature identifies new inter-RAT cells and checks if those become new neighbors for LTE cells. The function can be executed manually or within a scheduled workflow. LTE783: ANR Inter-RAT UTRAN (RL30) This feature keeps known neighbor relations between LTE and UTRAN up-to-date. The function can be executed manually or within a scheduled work-flow. The LTE507: Inter-RAT Neighbor Relation Optimization feature blacklisting does not influence the SIB and UE measurement setup of the LTE783: ANR Inter-RAT UTRAN feature. LTE784: ANR Inter-RAT GERAN (RL30) This feature keeps known neighbor relations between LTE and GERAN up-to-date. The function can be executed manually or within a scheduled workflow. The LTE507: Inter-RAT Neighbor Relation Optimization feature blacklisting does not influence the SIB and UE measurement setup of the LTE784: ANR Inter-RAT GERAN feature. LTE460: ANR Inter-RAT GERAN - Fully UE based (planned for RL60) This feature automatically scans for unknown GERAN cells according to the constraints defined by the Operator in an inter-RAT GERAN ANR profile. The function is executed as decentralized SON function in the eNB. LTE908: ANR Inter-RAT UTRAN - Fully UE Based (RL50) This feature automatically scans for unknown UTRAN cells according to the constraints defined by the Operator in an inter-RAT UTRAN ANR profile. The function is executed as decentralized SON function in the eNB.

Affected features

174

© 2016 Nokia

DN09185967 Issue: 01M



The LTE507: Inter-RAT Neighbor Relation Optimization feature has impact to inter-RAT handover and with this also to the PM counters themselves. If for an NR a mobility procedure is blacklisted, the PM counters are still provided, but they are not updated anymore as long as the blacklisting is in place. The features themselves define the PM counters for the related mobility procedure. • •

•

•

LTE56: Inter-RAT Handover to WCDMA (RL30) Coverage-based inter-RAT PS handover from LTE to WCDMA LTE736: CS Fallback to UTRAN (with PS HO) (RL40) PS handover-based CS fallback from LTE to UTRAN (WCDMA) for mobile-originated and mobile-terminated call setup is supported. The target cell selection is based on fast measurement solicitation. LTE872: SRVCC to WCDMA (RL40)The LTE to WCDMA Single Radio Voice Call Continuity (SRVCC) functionality of the Flexi Multiradio BTS allows for a service continuity of voice services to the CS domain when changing from an LTE cell to a WCDMA cell. All non-voice services will be handed over to the PS domain. LTE873: SRVCC to GSM (RL40) The LTE to GERAN Single Radio Voice Call Continuity (SRVCC) handover functionality of the Flexi Multiradio BTS allows for a service continuity of voice services to the CS domain when changing from an LTE cell to a GERAN cell.

Impact on MML commands This feature is managed by the parameters listed in Flexi Multiradio BTS LTE Commissioning, RNW and Transmission Parameters excel in NOLS. Impact on network and network element management tools This feature impacts network management and network element management tools as follows: • •

The NetAct blacklists an inter-RAT mobility procedure of an NR causing many failed HOs. Operational modes defined in NetAct for the LTE507: Inter-RAT Neighbor Relation Optimization feature: – – –

•

• •

Feature is started manually in NetAct Optimizer/cSON for selected LTE cells. Feature is started manually in NetAct Configurator’s workflow engine (WFE) UI for the whole NetAct cluster or pre-defined scope. Feature is run automatically by NetAct Configurator’s SON Scheduler triggering the WFE. It is done according to the predefined schedule for the whole NetAct cluster or pre-defined scope.

Preference settings (LTE Adjacency Blacklisting) in Optimizer must be saved as “Global values”. It is required when blacklisting algorithm is running from SON Scheduler or Workflow engine. NetAct supports reading of PM data and generates required KPIs. Manual intervention is allowed via previously enabled stop points in NetAct (also in automatic mode) where the user is able to refine the proposed blacklists.

Impact on system performance and capacity This feature impacts system performance and capacity as follows: •

DN09185967 Issue: 01M

Effect on ther RAN KPIs: the HO success ratio improves, as bad performing NR are not considered for HO decisions.

© 2016 Nokia

175


•

6.1.1.5


The number of NR is quite high, nevertheless the processing with respect to a single NR is negligible. One scheduled job can execute all NR within the network or a given NetAct cluster, if a large network is split into smaller NetAct clusters.

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 90: Related existing counters lists existing counters related to this feature. Table 90

Counter ID

Related existing counters

Counter name

Measurement

M8019C3

Inter System Handover attempts to GERAN 8019 - LTE Inter System with SRVCC per neighbour cell relationship Handover to GSM per Neighbor Cell (WBTS)

M8017C7

Inter System Handover attempts to UTRAN per neighbour cell relationship

8017 - LTE Inter System Handover to UTRAN per Neighbor Cell (WBTS)

M8017C11

Inter System Handover attempts to UTRAN with SRVCC per neighbour cell relationship

8017 - LTE Inter System Handover to UTRAN per Neighbor Cell (WBTS)

Key performance indicators Table 91: Related existing key performance indicators lists existing key performance indicators related to this feature. Table 91

Related existing key performance indicators

KPI ID

KPI name

LTE_1057a

Int-Sys HO to GERAN with SRVCC per neighbour cell relationship Success Ratio

LTE_982a

Inter-System HO for UTRAN SR, per neighbour

LTE_1054a

Int-Sys HO to UTRAN with SRVCC per neighbour cell relationship Success Ratio

Parameters There are no new parameters related to this feature. Table 92: Related existing parameters lists existing parameters related to this feature.

176

© 2016 Nokia

DN09185967 Issue: 01M


Table 92



Full name

6.1.1.6

Abbreviated name

Managed object

NR-control

nrControl

LNRELG

PS Handover allowed

psHoAllowed

LNRELW

single radio voice call continuity allowed

srvccAllowed

LNRELW

circuit switched fallback with PS handover allowed

csfbPsHoAllowed

LNRELW

NR-control

nrControl

LNRELW

single radio voice call continuity allowed

srvccAllowed

LNRELG


Sales information

BSW/ASW



ASW

NetAct

-

6.2 LTE523: Multi-Layered Certificate Authorities 6.2.1 Description of LTE523: Multi-Layered Certificate Authorities Introduction to the feature This feature introduces the support of hierarchical public key infrastructure (PKI). The operator is able to integrate the Nokia Identity Management System (IDM) as a subordinate certification authority (CA) into its own existing PKI, or use a third party PKI solution as subordinate to the IDM.

g 6.2.1.1

Note: This feature introduces the hierarchical PKI to the eNB. The LTE1260: iOMS Certificate Update and Revocation Support feature provides the counterpart on the iOMS side.

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits

DN09185967 Issue: 01M

© 2016 Nokia

177



This feature enables the operator: to support the hierarchical public key infrastructure to increase network security by CMP protocol messages signing to integrate the Nokia IDM as subordinate CA into operator’s own PKI to integrate the eNB into any third party hierarchical PKI solution

• • • •

6.2.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 94

OMS

iOMS5.0


UE

NetAct

MME

SAE GW

-

OSS5.5 CD1

-

-


6.2.1.3

Functional description Functional overview The current certificate management in the eNB is enhanced by introducing the support of hierarchical and two-root PKI. This allows the operator to use various models of PKI. Supported PKI models Single-layer PKI is a PKI model that has one certification authority (CA), which creates and signs all operator EE certificates in the customer network. The CA issues a selfsigned certificate (operator root CA certificate) that is used by all network elements as a root of trust. The single-layer PKI is implemented with LTE665: LTE Certificate Management LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) features. Multi-layer PKI is an extension of single-layer PKI. It offers better flexibility by introducing the concept of multiple layers. In this model, the root CA is the highest certification authority in the operator’s network. The root CA creates self-signed certificate (operator root CA certificate) that is used as trust anchor for the entire domain of PKI entities. The multi-layer PKI introduces the possibility to deploy further certificate authorities as a subordinate to the root CA. Figure 24: Single-root multi-layer public key infrastructure model shows an example of hierarchical PKI with a single root CA.

178

© 2016 Nokia

DN09185967 Issue: 01M


Figure 24


Single-root multi-layer public key infrastructure model

operator'srootCA certificate

operator's rootCA (intermediate) RA1certificate

(intermediate) CA1certificate (intermediate)

(intermediate)

CA1

RA1

(signing) CA2certificate

(intermediate) RA2certificate (intermediate)

(signing)

RA2

CA2

(signing) RA3certificate

endentitycertificate

signing RA3

network element

With this feature, it is possible to establish up to three layers of intermediate CA. All entities in such PKI trust the single root CA, thus the same operator root CA certificate must be present in each network element. The multi-layer PKI, also called hierarchical PKI, is established in the following order: 1. The root CA creates and signs the operator root CA certificate as a trust anchor for all entities in the customer’s network. 2. The root CA creates and signs certificates for the intermediate CAs that are immediately below it (second layer). 3. If needed, the intermediate CAs create and sign certificates for the further intermediate CAs (third and fourth layers). 4. The intermediate CAs that are the lowest in the PKI hierarchy are called signing CA and they are used to create and sign certificates for network elements (operator EE certificates). If a Registration Authority (RA) is used to sign CMP messages, the RA uses its own certificate to sign the messages. In such case, the eNB supports also the multi-layer chain of trust for the RA. This chain includes up to three optional subordinate RA certificates, and one signing RA certificate. The RA certificate chain must lead to the same root CA certificate that is used for the operator CA certificate chain. Trust pool The LTE523: Multi-Layered Certificate Authorities feature introduces the support for additional trust anchor. The additional root CA certificate is used to establish IPsec connections to the peers that do not have a valid trust path to the eNB’s root CA. This

DN09185967 Issue: 01M

© 2016 Nokia

179



allows the operator to provide service in a shared radio access network, where each operator maintains its own PKI. Figure 25: eNB trust pool shows an example of two-root multi-layer PKI model. Figure 25

eNB trust pool eNBtrustpool operator'sroot CA1certificate

CA1.2certcross-signed bypeer'sCA2.2

peer'sroot CA2certificate

operator's rootCA1

peer's rootCA2 (intermediate) CA2.1certificate

(intermediate) CA1.1certificate

(intermediate)

(intermediate)

CA1.1

CA2.1 (intermediate) CA2.2certificate

(intermediate) CA1.2certificate

(intermediate)

(intermediate)

CA1.2

CA2.2 (signing) CA2.3certificate

(signing) CA1.3certificate

(signing)

(signing)

CA1.3

CA2.3

endentity certificate

endentity certificate

network element

network element

Chain of trust When the secure connection is established, the eNB validates the peer’s certificate chain. When the received certificates are validated, the eNB steps up the chain of trust until the known trust anchor is found (for example, a self-signed operator root CA certificate). If the operator EE certificate of the remote peer is not directly signed by a root CA then the remote peer sends all intermediate CA certificates of the trust chain up to the root CA certificate (except the root CA certificate). Each certificate is verified if the certificate life time is not expired. Another operator’s root CA certificate that is stored locally in the eNB trust pool and it is used to authenticate the peer’s operator EE certificate. The peer entity follows similar process on the other side to authenticate the eNB. Certificate storage capacity The eNB stores the complete chain of trust for its own operator EE certificate in a nonvolatile memory. The eNB storage capacity is 12 certificates. This includes the operator root CA certificate, one operator root CA certificate (update), up to three subordinate CA certificates, an operator EE certificate, and an optional RA certificate chain (one signing RA certificate and up to three subordinate RA certificates). The eNB allows for installation of one additional trust anchor of another operator (one root CA certificate and one root CA certificate (update)) to enable IPsec connections in basic RAN Sharing scenarios.

180

© 2016 Nokia

DN09185967 Issue: 01M



Operator certificate life-cycle management The certificate management in RAN elements and the operator’s PKI is based on CMPv2 protocol. The common rules for certificates and the enrollment of operator certificates follow 3GPP Release 9 "TS 33.310 Network Domain Security - Authentication Framework". The operator certificate initialization procedure for eNB is done using the PSK/Refnum, the eNB’s vendor certificate, or the default initial certificate as described in LTE665: LTE Certificate Management LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) feature description. With the introduction of the LTE523: Multi-Layered Certificate Authorities feature, the old trust anchor (operator root CA certificate) and optional intermediate CA (intermediate CA certificates) are removed from eNB trust pool if the operator certificate initialization procedure succeeds.

t

Tip: The serial number in the CN field is the transport module’s serial number of the Flexi Multiradio BTS, or the system module’s serial number of the Flexi Multiradio 10 BTS. The operator certificate update procedure is authenticated by current operator EE certificate, therefore the procedure must be performed before current operator EE certificate lifetime expires. During the procedure, a new operator EE certificate is sent together with optional intermediate CA certificates. If the procedure is successful, the old operator EE certificate and old operator CA certificates are removed from eNB trust pool. As the operator root CA certificate is not sent as a part of the procedure, it is not updated, modified, or removed from the eNB trust pool. Therefore, if the operator root CA certificate needs to be updated, it must be done with the operator certificate initialization procedure or manually with BTS Site Manger/NetAct. Certificate revocation check During certificate validation, the eNB checks the peer’s operator EE certificate for possible revocation against a certificate revocation list (CRL). The CRL is downloaded from the CRL distribution point given in the eNB’s operator EE certificate or in the signing CA certificate (if the operator EE certificate contains no CRLDP). The reference to the CRL distribution point is configured by the CA which issues the certificate. The reference can be given either as an IP address of the revocation server, or as a fully qualified domain name (FQDN) of the server. If the reference to the CRL distribution point is given as FQDN, the according IP address needs to be resolved by a DNS query. For more information, see LTE482: DNS Support for Certificate Examination feature description. The eNB has only one CRL that is issued by its signing CA and can verify only certificates that were issued by the same Certification Authority. The update of stored CRL is done regularly by the eNB with the frequency configured by the Certificate Revocation List update period (crlUpdatePeriod) parameter. The CRL download can also be triggered manually using BTS Site Manger or NetAct. Configuration Current certificate management feature configuration is extended by: •

DN09185967 Issue: 01M

the possibility to configure the CMP directory in the CA/RA server

© 2016 Nokia

181


•


the introduction of 61618 TRUST_ANCHOR_EXPIRING BTS fault. The fault raises the 7665 BASE STATION TRANSMISSION alarm if any of the operator root CA certificate’s lifetime is shorter than the value configured with the Update time for CA certificate renewal (caCertificateUpdateTime) parameter

For more information on certificate management feature configuration, see Activating LTE523: Multi-Layered Certificate Authorities. Software upgrade and compatibility The eNB supports the migration from single-layer PKI to multi-layer PKI (for example, from RL40 to RL50). During the software upgrade to multi-layer PKI, current operator EE certificate and the operator root CA certificate is not removed and is used straight away after the software upgrade (single-layer chain of trust in a multi-layer-capable eNB).

g

Note: The LTE523: Multi-Layered Certificate Authorities feature requires that operator certificates strictly follow certificate profile specified in LTE RAN O&M Security (for example, that the keyUsage attribute in the operator EE certificates is (at least) set to digitalSignature and keyEncipherment and that the keyUsage attribute in the operator root CA certificate is set (at least) to keyCertSign. If operator certificates that are stored in the eNB before the software upgrade are not consistent with the profile, the certificates will be removed during software upgrade procedure and the secure connections between the eNB and other network elements will no longer be possible. To avoid the connectivity problems after the software upgrade, make sure that the operator certificates stored in the eNB are in line with the certificate profile specified in Certificate and key format in LTE RAN O&M Security. The eNB supports multi-layer PKI for: • •

IPsec connections to the Security Gateway The SEG must support the multi-layer CA/RA. TLS connections to iOMS/NetAct and BTS Site Manager The iOMS must support multi-layer CA/RA to allow secure O&M interface and file transfers between the eNB and the iOMS. For more information, see LTE1260: iOMS Certificate Update and Revocation Support.

Because the software downgrade from multi-layer PKI to single-layer PKI is not possible (for example, an eNB with multi-layer chain of trust using the fallback software that supports only single-layer PKI), it is recommended that the fallback software in the eNB also supports the multi-layer PKI. For this reason, before installing a multi-layer chain of trust, create a fallback software that also supports the multi-layer PKI. For more information, see LTE System Upgrade and Release documentation.

6.2.1.4

System impact Interdependencies between features This feature extends the current certificate management solution implemented with the LTE665: LTE Certificate Management, LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA). The LTE482: DNS Support for Certificate Examination feature is needed for resolving CRL distribution point if given in certificate by FQDN. Impact on interfaces This feature has no impact on interfaces.

182

© 2016 Nokia

DN09185967 Issue: 01M



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.

6.2.1.5

LTE523: Multi-Layered Certificate Authorities management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 95: Modified alarms lists alarms modified with this feature. Table 95

Modified alarms

Alarm ID

Alarm name

7665

BASE STATION TRANSMISSION ALARM The alarm above is caused by the following BTS fault: •

61618 TRUST_ANCHOR_EXPIRING

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 96: New parameters lists parameters introduced with this feature. Table 96

New parameters

Full name

Abbreviated name

Managed object

Update time for CA certificate renewal

caCertificateUpdateTime

CERTH

CMP Directory

cmpDirectory

CERTH

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

DN09185967 Issue: 01M

© 2016 Nokia

183


Table 97



Full name

Abbreviated name

Managed object

CMP server IP address

cmpServerIpAddress

CERTH

CMP server port number

cmpServerPort

CERTH

CMP server subject name

caSubjectName

CERTH

Update time for BTS certificate renewal

btsCertificateUpdateTime

CERTH

Certificate Revocation List update period crlUpdatePeriod

6.2.1.6

CERTH


Sales information

BSW/ASW


BSW

-


-

6.2.2 Activating the LTE523: Multi-Layered Certificate Authorities feature using the BTS Site Manager Before you start The evolved NodeB must already be commissioned. The BTS Site Manager (BTSSM) can be connected to the eNB either locally or from a remote location. A restart of the eNB is not required after an activation of this feature. The operator certificates might be installed in the eNB by: • •

triggering the operator certificate initialization procedure. This method uses the Certificate Management Protocol. installing the eNB trust chain manually (out-of-band installation). This method is used if the operator does not have an online Public Key Infrastructure.

If the operator certificates are installed manually, the operator end entity certificate for the eNB must be created and signed by the operator’s Certification Authority in advance. The resulting operator end entity certificate should be stored in a PKCS#12 file together with the corresponding private key and the whole trust chain (the operator root CA certificate and optional intermediate CA certificates). The operator certificates must include all mandatory extensions as specified in Certificate and key format in the LTE RAN O&M Security functional area description.

184

© 2016 Nokia

DN09185967 Issue: 01M


g


Note: When the eNB receives new operator certificates, for example, as a result of the operator certificate initialization procedure, all currently established IPsec connections are terminated and re-established using the new certificates. This causes a short interruption to the eNB's operation. The operator certificate initialization procedure does not affect secure connections that use TLS protocol. When updating the operator root CA certificate in the network elements, it is recommended to follow the order specified in the LTE RAN O&M Security. For more information on the operator root CA certificate update, see Operator root CA certificate update, in Operating tasks related to LTE RAN O&M Security.

Next topic Configuring the certificates manually (out-ofband installation) on page 185

6.2.2.1

Configuring the certificates manually (out-of-band installation) Steps To configure the certificates manually, do the following: Procedure 1

Start the BTSSM application and establish connection to the eNB. For details, see Launching BTS Site Manager in Commissioning Flexi Multiradio BTS LTE or the BTS Site Manager Online Help (section Instructions).

2

Open the Certificate Management tool. From the top menu bar, select Configuration ► Certificate Management.

3

Install the eNB operator certificates. In the Install certificates section, configure: •

BTS trust chain – –

– – – •

Additional trust anchor –

DN09185967 Issue: 01M

Using the drop-down list, select Browse to open the file explorer. Find and select a PKCS#12 file (with .p12 file extension) that contains the eNB’s private key, the operator end entity certificate, optional intermediate CA certificates, and the operator root CA certificate. The PKCS#12 (.p12) files without a private key or with more than one chain of trust cannot be used. Click the Open button. Enter a file-protection password when prompted. Click the Send button.

Using the drop-down list, select Browse to open the file explorer.

© 2016 Nokia

185


–

–


Find and select a PEM file that contains the additional operator root CA certificate. Only self-signed certificates are supported as additional trust anchors. The PKCS#12 (.p12) files cannot be used for an additional trust anchor installation. Click the Open button.

– –

4

Install and configure the Certificate Revocation List settings. • • • •

5

Click the Send button.

Switch to the Certificate Revocation List tab. Configure the CRL update interval. Click Send. Click Trigger CRL update.

Verify the newly installed certificates. To verify installed certificates and CRLs: • •

Switch to the BTS Certificates tab and check if all previously installed certificates are listed. Switch to the Certificate Revocation List tab and check if the previously installed CRL is listed.

Previous topic Activating the LTE523: Multi-Layered Certificate Authorities feature using the BTS Site Manager on page 184

6.2.2.2

Next topic Configuring the automatic certificate management on page 186

Configuring the automatic certificate management Steps To configure the automatic certificate management, do the following: Procedure 1

Start the BTSSM application and establish connection to the eNB. For details, see Launching BTS Site Manager in Commissioning Flexi Multiradio BTS LTE or the BTS Site Manager Online Help (section Instructions).

2


186

© 2016 Nokia

DN09185967 Issue: 01M


3

Check if a vendor certificate is available in the eNB. Switch to the Vendor Certificates tab, which displays factory-installed certificates. Check if a vendor certificate is available.

• •

4


Configure the automatic certificate management. Switch to the Automatic Management tab. In the CMP/CA server settings section:

• •

– – –

Address: enter the CMP/CA server’s IP address. Port: enter the CMP/CA server’s port number. Directory: enter the directory path on the CMP/CA server. The default path to the CMP directory on a CMP/CA server is pre-configured to http://IP@:port/pkix/ If the CMP/CA server uses a different directory, it might be configured with this parameter.

g

Note: Although the directory path is modifiable with the BTS Site Manager, the BTS supports only the default /pkix value. –

–

CA subject name: enter the CA subject name. Use openssl order, for example:

C=, O=, CN= Choose an authentication method.

The eNB authenticates itself to the operator’s Certification Authority using the Reference number and Pre-shared key, the vendor certificate, or the default selfsigned certificate as shown in eNB authentication methods. Table 99

eNB authentication methods

Reference number and Pre-shared key

Vendor certificate

System behavior

configured

present or not present

The eNB uses the configured PSK and RefNum to authenticate to the operator’s CMP/CA server.

not configured

present

The eNB uses the vendor certificate to authenticate to the operator’s CMP/CA server.

not configured

not present

The eNB uses the default self-signed certificate to authenticate to the CMP/CA server.

If the Reference number and Pre-shared key are used for the eNB authentication, configure the parameters by typing a value into the text box field. Alternatively, import a file containing the Reference number or PSK value.

DN09185967 Issue: 01M

© 2016 Nokia

187


g


Note: The two optional parameters called Reference number and Pre-shared key are always used if the configured values are different from the default value 1234. For security reasons, the values of those parameters are not visible in the BTS Site Manager once they have been configured (they are visible only during the configuration phase). To make sure that the RefNum and the PSK are not used by the eNB for authentication, configure the default value 1234 for the RefNum and the PSK. The operator’s Certification Authority must configure a policy to allow the authentication method used by the eNB. For more information on policy configuration, refer to the Certification Authority documentation. In the Expiration settings section: •

•

5

Trust anchor expiry alarm: set how many days in advance to the operator root CA certificate expiration date the eNB should raise the 61618 Trust anchor expiring fault BTS certificate renewal: set how many days in advance to the operator end entity certificate expiration date the eNB should trigger the operator certificate update procedure

Send new settings to the eNB. Click the Send button.

6

Initialize certificates.

t

Tip: If there is no operator certificate installed in the eNB, the eNB initializes certificates automatically once the automatic certificate management is configured. In such a case, there is no need to perform this step. To trigger the operator certificate initialization procedure, click the Initialize Certificates button. Expected outcome After a while, the eNB receives and stores new operator certificates and is able to establish secure IPsec and TLS connections. Unexpected outcome The eNB cannot retrieve operator certificates and raises the 61510 Automatic BTS Operator Certificate retrieval unsuccessful fault. Trace the communication between the eNB and the operator’s Certification Authority to find out the reason for the failure. The most common problems are: •

•

188

The operator’s Certification Authority is not answering. The operator’s Certification Authority might be unavailable or there might be no IP route to the operator’s Certification Authority. Check if there is an IP connectivity between the eNB and operator’s Certification Authority. The authentication fails in the operator’s Certification Authority.

© 2016 Nokia

DN09185967 Issue: 01M


•


Check if the authentication method used by the eNB is allowed by the operator’s CA policy. If the Reference number and Pre-shared key were used for authentication, check if the configured values are correct. Wrong or misconfigured CMP/CA server’s subject name. Check the CMP/CA server’s subject name configuration in the eNB.

The 61510 Automatic BTS Operator Certificate retrieval unsuccessful fault is canceled automatically when the eNB receives new operator certificates or when the automatic certificate management is disabled. For more information on how to disable the automatic certificate management, see Deactivating LTE523: Multi-Layered Certificate Authorities. Further information If the CMP/CA server settings are changed but the eNB has a valid trust chain already installed, the eNB does not try to get new certificates automatically. If required, the operator might trigger the operator certificate initialization procedure manually by clicking the Initialize certificates button.

g

Note: The operator’s Certification Authority might be configured to allow only one operator certificate initialization procedure for a certain eNB. Before triggering the operator certificate initialization procedure, make sure the operator’s Certification Authority allows repeating operator certificate initialization procedure for the same eNB.

7

(Optional) Configure the CRL download interval. • • •

Switch to the Certificate Revocation List tab. In the Certificate Revocation List (CRL) settings section, configure the CRL update interval. Click the Send button.

Previous topic Configuring the certificates manually (out-ofband installation) on page 185

6.2.3 Deactivating LTE523: Multi-Layered Certificate Authorities Before you start When automatic certificate management is deactivated, the operator certificates are not removed from the eNB’s pool of trust. The certificates are still used by the eNB to establish new secure connections. The deactivation of automatic certificate management does not affect any currently established secure connections between the eNB and other network elements.

DN09185967 Issue: 01M

© 2016 Nokia

189



Deactivating automatic certificate management Procedure 1

Start the BTSSM application and establish a connection to the eNB. For details, see Launching BTS Site Manager in Commissioning Flexi Multiradio BTS LTE or the BTSSM online help (section Instructions).

2


3

Deactivate automatic certificate management. • •

Switch to the Automatic Management tab. In the CMP/CA server settings section: – – – – – –

g

Address: remove the CMP/CA server’s IP address. Port: remove the CMP/CA server’s port number. Directory: remove the directory path on the CMP/CA server. CA subject name: remove the CA subject name. Reference number: enter the default value 1234. Pre-shared key: enter the default value 1234.

Note: The two optional parameters called Reference number (RefNum) and Pre-shared key (PSK) are always used, if the configured values are different than the default value 1234. For the security reasons, the values of those parameters are not visible in the BTS Site Manager once they have been configured (they are visible only during the configuration phase). To make sure that the RefNum and the PSK are not used by the eNB for the authentication, configure the default values 1234 for the RefNum and the PSK.

4

Send new settings to the eNB. Click Send button.

5

Verify, that the automatic certificate management has been deactivated. • •

Switch to the BTS Certificates tab. Check the status of Automatic management.

Expected outcome The status of Automatic management is Not configured. Further information

190

© 2016 Nokia

DN09185967 Issue: 01M



If the operator certificates need to be removed from the eNB’s pool of trust, follow the procedure.

Deactivating CRL update Purpose To deactivate the automatic CRL update, set the CRL update interval parameter to 0. Deactivation of this feature does not require eNB restart or cell locking. Procedure 1


2

Switch to Certificate Revocation List tab. In the Certificate Management tool, switch to the Certificate Revocation List tab.

3

Deactivate CRL update. Set the CRL update interval to 0 hours.

4

Save the changes in configuration. To save the changes, click Send.

Removing certificates manually Procedure 1


2


3

Delete the eNB operator certificates. In the BTS certificates section (on the BTS Certificates tab): •

DN09185967 Issue: 01M

Select one trust anchor (a self-signed certificate).

© 2016 Nokia

191


•


Click Delete button.

Repeat this step for each trust anchor that need to be removed.

g

Note: It is not possible to remove the active eNB’s trust chain with the Delete button. To remove all operator certificates from the eNB’s pool of trust, follow the procedure. Expected outcome The BTS certificates section lists no trust anchors.

Restoring the vendor certificates Procedure 1


2


3

Restore the eNB vendor certificates. • •

Switch to the Vendor Certificates tab. Click Restore Vendor Certificates button.

Further information

g

Note: When the vendor certificates are restored, all operator certificates are removed from the eNB’s pool of trust. All currently established IPsec connections are terminated and the eNB is no longer able to establish new secure connections.

6.3 LTE962: RACH Optimization 6.3.1 Description of LTE962: RACH Optimization Introduction to the feature The feature LTE962: RACH Optimization offers an automated solution for optimization of RACH parameters used in LTE cells. The feature identifies and resolves the conflicts and inconsistencies arising due to incorrect configuration of RACH parameters. The optimization for the collision and inconsistency resolution can be applied for:

192

© 2016 Nokia

DN09185967 Issue: 01M


• • •


single eNB and all its subordinate cells or individual cells dedicated list of eNBs and all their subordinate cells all eNBs of a NetAct Regional Cluster

LTE962: RACH Optimization can be executed by Eden Net. RACH Optimization follows 3GPP TS 36.902 definitions, but still considering the central approach as defined with the LTE581: PRACH management feature.

6.3.1.1

Benefits End-user benefits This feature optimizes RACH parameters thereby improving end-user-experiences in terms of faster call setup, faster handover etc. Operator benefits 1. Optimal RACH configuration parameter improves LTE network performance. 2. Conflicts and inconsistencies are avoided which otherwise may lead to • •

6.3.1.2

decreased RACH detection probability. interference to and from other cells and physical channels.

Requirements Hardware requirements This feature requires no new or additional hardware.

6.3.1.3

Functional description Feature scope This feature is available as part of Eden Net (from release LTE16A). The feature offers an automated and efficient solution for optimization of RACH parameters by resolution of conflicts and inconsistencies. As part of the RACH optimization feature one or more of following LNCEL parameters will be optimized as part of conflict and inconsistency resolution operation: • • • •

RACH configuration index, RACH frequency offset, RACH cyclic shift, RACH root sequence.

LTE962: RACH Optimization can be used for network settings verification, if: • • •

•

DN09185967 Issue: 01M

some of eNBs were manually configured (for example without LTE581: PRACH management) eNB parameters relevant for PRACH/RACH allocation were CHANGED AFTER auto-configuration process of the eNB there is a change of network topology (new eNBs added with auto-configuration process BUT as LTE581: PRACH management is not able to change already configured eNBs therefore collision free PRACH allocation could not be performed) there is a change of antenna location - for example use of distributed sites.

© 2016 Nokia

193



RACH Optimization can be applied for single or group of cells or for the whole NetAct Cluster. In Optimizer 3.2 release, the user can trigger RACH Optimization from Optimizer client. Support for triggering the RACH optimization feature externally from Configurator, SON scheduler, iSON Manager and Operations on Demand will be available as part of Optimizer 8. From release LTE16A onwards the user can trigger LTE962 in Eden Net. An overview of the feature and its interdependencies between eNB, NetAct Configurator, and NetAct Optimizer is presented in Figure 26: LTE962: RACH optimization overview. Figure 26

LTE962: RACH optimization overview

LTE962:!RACH!Optimization Optimization!of!PRACH!parameters!-!addition!to!existing!SON!operations

eNB Preconditions:!needed parameters!modeled (in!PDDB)

Configurator* Preconditions!to!have:!actual DB!up!to!date!(including site!and!antenna!data)

Optimizer Preconditions!to!have:!fresh actual!NW!configuration!from Configurator!actual!DB. preference!set,!PRACH!license!active

Trigger!RACH!Optimization (based!in!scheduled!time!*), network!scope.

RACH!Optimization (Collision!inconsistency detection!and!resolution)

*NetAct!Configurator!specific applications!involved!in!triggering SON!Operations!*) *Son!Scheduler!*) *CM/SON!Operations!Manager!*) *racclimx.sh!(Command!line!interf.!*)

RACH!Optimization!Plan Plan!validation

eNB!RACH!Optimization

TriggerRACH!Optimization (based!on!scheduled!time!*), network!scope)

RACH!Optimization (Collision!inconsistency detection!and!resolution)

RACH!Optimization!Plan

Configuration activation!and!reset

Plan!validation!and eNB!configuration plan!activation

eNB!is!operational with!optimized!PRACH

TriggerviaOptimizer!client!or!Operation on!Demand!Portal!or!CM/SON!Operation Manager

Triggered!at -SON!scheduler,!CM/SON!Operations!Manager,!Command!line Interface!*) -Optimizer!user!interface,!SON!Portal Visualization -feedback!information!from!Optimizer!covers!RACH!Optimization, visible!in!Configurator!operations!history!UI -When!triggered!from “Optimizer!user!interface”, “SON!Portal”,!the results!are!visible!in “Optimizer!RACH!Optimization!tool”. “SON Portal!Optimization” tool. Controls -Optimizer!preferences

*)!Note:!this!functionality!is!available!in!the!next!release.

Use cases: LTE962: RACH optimization offers the following use cases: 1. Detection of conflicts arising due to incorrect configuration of RACH parameters. Conflicts are reported when:

194

© 2016 Nokia

DN09185967 Issue: 01M


• •


Two cells within a RACH reuse distance have the same RACH parameter configuration. One or more neighboring cells (LNREL) have the same RACH parameter configuration.

2. Detection of inconsistencies based on RACH configuration. •

Inconsistencies are reported, if the existing RACH configuration is not in line with own cell parameters.

3. Resolution of identified conflicts and inconsistencies by reallocation of RACH parameters.

6.3.1.3.1

NetAct Optimizer NetAct Optimizer supports the RACH conflict and inconsistency detection and resolution. The work-flow can be triggered manually with selectable scope of cells or for the whole network.

g 6.3.1.4

Note: From release 16A the feature LTE962 is triggered by Eden Net.

System impact Interdependencies between features LTE720: Auto configuration LTE581: PRACH management LTE1019: SON reports LTE1045: Full SON Support for Distributed Sites

• • • •

With LTE581: PRACH management PRACH parameters could be allocated during initial auto-configuration process supported by NetAct CM Operations Manager and Optimizer. LTE962: RACH Optimization can be used AFTER initial assignment of PRACH parameters. For example if performed with LTE581: PRACH management or where an eNB was manually configured.

g

Note: LTE962: RACH Optimization and LTE581: PRACH management must be activated together. Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools •

Optimizer User Interface: RACH Optimization tool available as part of Optimizer client and can be triggered manually


DN09185967 Issue: 01M

© 2016 Nokia

195


6.3.1.5


Management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Parameters The following table lists parameters modified by this feature. Table 100

Modified parameters

Full name

6.3.1.6

RACHCS

LNCEL

prachConfindex

RACHConfindex

LNCEL

prachFreqOff

RACHFreqOff

LNCEL

rootSeqIndex

rootSeqIndex

LNCEL

Sales information Sales information

BSW/ASW


ASW

NetAct


Abbreviations Table 102

Abbreviations

Abbreviations

196

Managed object

prachCS

Table 101

6.3.1.7

Abbreviated name

Description

BAM

Border Area Management

ECR

Expected Cell Range

NMS

Network Management System

PRACH

Physical Random Access Channel

RACH

Random Access Channel

RAR

Random Access Response

TTI

Transmission Time Interval

© 2016 Nokia

DN09185967 Issue: 01M


Table 103


Terms

Terms

Description

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.

Neighbor eNB

eNB which has an X2 connection (or contained in LNADJ object) to the eNB under configuration.

Neighbor cells

Cells of a Neighbor eNB.

Surrounding eNB's/cells

eNB's and their subordinate cells which have to be considered for RACH planning (only intra-frequency cells), independent of whether they have an X2 connection to the eNB under configuration or not.

PRACH configuration index

LNCEL parameter: RACHConfIndex defines the allowed system frame and sub-frame numbers for random access attempts, and the preamble format.

PRACH frequency offset

LNCEL parameter: RACHFreqOff defines the first physical resource block available for RACH in the UL system frequency band.

PRACH cyclic shift

LNCEL parameter: RACHCS - Preamble cyclic shift defines the configuration which is used for preamble generation. The configuration determines how many cyclic shifts are needed to generate preamble.

PRACH Root sequence

LNCEL parameter: rootSeqIndex - The preamble generation is started from the root sequence which is pointed by the logical root sequence number. 64 preambles can be transmitted in the RACH frame. If one root is not enough to generate all the 64 preambles, then the consecutive number is selected until the full set is generated. RACH root sequence is cell specific information and neighboring cells should have a different value. RACH root sequence is transmitted in system information.

RACH parameter conflicts

1. Two cells within a RACH reuse distance having the same RACH parameter configuration. 2. Cells of own LTE BTS having same RACH parameter configuration (including distributed site configuration). 3. One or more neighboring cells (related via LNREL) having the same RACH parameter configuration.

RACH parameter inconsistencies

RACH allocations are not in line with other own cell parameters. For example:

1. LNCELs using forbidden RACH parameters (Global and cell level forbidden sets being considered during RACH parameter inconsistencies detection and resolution).

DN09185967 Issue: 01M

© 2016 Nokia

197



Table 103

Terms (Cont.)

Terms

Description

2. LNCELs having overlapping RACH and PUCCH regions. Neighboring cluster

eNBs and network elements managed by an other Network Management System (NMS).

PLMN cluster

Network elements managed by the NMS. “Managed” refers to the possibility of provisioning network parameters, maintenance of configuration management change history etc.

6.4 LTE1099: Event-triggered symptom data collection and provisioning 6.4.1 Description of LTE1099: Event-triggered symptom data collection and provisioning Introduction to the feature This feature introduces automatic fault-triggered BTS symptom data (troubleshooting logs) collection. The triggering BTS faults are defined in the Site Configuration File (SCF) using the NetAct Configurator or using the BTS Site Manager. The logs are available in the OMS and can be uploaded to NetAct.

6.4.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits the operator as follows: • • •

6.4.1.2

Automatic symptom data collection reduces the workload. It introduces a proactive method of gathering BTS troubleshooting logs. The immediate data collection following the fault occurrence assists the troubleshooting process. Self-triggered symptom data generation is more accurate and thus, more efficient in solving failures (the logs can be sent to technical support to identify problems).

Requirements Hardware requirements This feature requires no new or additional hardware.

198

© 2016 Nokia

DN09185967 Issue: 01M


6.4.1.3


Functional description The event-triggered symptom data collection can be divided into following steps: 1. 2. 3. 4.

Selection of the triggering faults Data collection after the selected faults occurred Data transfer and storage Viewing the collected data

Selection of the triggering faults The automatic symptom data collection is triggered by BTS faults selected by the user, who should contact company Technical Support personnel to get the list of recommended triggers. The list of faults is defined with the symptomDataTriggerL parameter. By default, no triggers are defined. Data collection after the selected faults occurred The log collection happens only when the fault occurs. The log consists of, for example: • • • • • • • •

computer log writings HW configuration alarm history active SW version transport configuration black box data performance data auto-connection report

Some faults might trigger an eNB reset. The recovery eNB reset can be delayed to allow the eNB to collect the symptom data. This delay is configured with the recoveryResetDelay parameter. Data transfer and storage Figure 27: Symptom data collection from the BTS illustrates the log collection mechanism.

DN09185967 Issue: 01M

© 2016 Nokia

199


Figure 27


Symptom data collection from the BTS OMS

User

BTS

Triggering fault BTScollectssnapshotfilesof thesystemdataaccordingto pre-definedrules File transfer OMSpacks,savestheresultfileonahard disk,andraisesanalarmindicatingthatnew troubleshootingfilehasbeenreceived Theuserviewsthelistoflog filesintheOMSLogViewer

Symptom data consists of one or several files that are transferred separately to OMS immediately after the data has been collected. The OMS is able to perform simultaneous uploads from several BTSs. The existing file transfer mechanism through the BTSOM interface is used to transfer the data to OMS. If the triggering fault leads to a recovery reset of the BTS, the upload to OMS is stopped and it is not restarted automatically (the reset can be delayed as mentioned earlier). In the OMS, the files are combined into one package file. This file is named in a common way: TSUPL_eNB__..tar The name contains the following information: • • • •

TSUPL: used by OMS to identify the file type as a symptom data file : the eNB ID number : identifies the troubleshooting task in the eNB : indicates when the file is created (using the OMS local time). The date and time format is YYYYMMDDhhmmss.

The files are stored in the following directory: /var/opt/OMSftproot/NE/TroubleshootingData

g

Note: The 71106 TROUBLESHOOTING DATA RECEIVED alarm indicates that the log file has been transferred to OMS. The dwAlarmForUploadCompleted parameter is used for disabling/enabling the alarm setting in OMS. The 71129 TROUBLESHOOTING DATA CREATION OR UPLOAD FAILED indicates that the data creation or upload to OMS has failed. Old symptom data files are deleted automatically from the BTS (after being transferred to OMS) and from OMS (when the disk gets full, files older than 10 days are removed).

200

© 2016 Nokia

DN09185967 Issue: 01M



With the dwBTSUploadEnabled parameter, troubleshooting data transfer to OMS can be enabled/disabled. As BTS is unaware of the setting of this parameter, disabling the upload on OMS side will cause overhead by unsuccessful BTS attempts to upload data. Therefore, it is recommended to provide an empty trigger list if upload is to be permanently disabled. With the NetActNotifyEnabled parameter, the data upload to NetAct can be enabled/disabled. Viewing the collected data The files can be viewed or downloaded to the client's computer using the Log Viewer in the OMS. The log files are sent to OMS even if the BTS fault was filtered by the BTS alarm system and the related alarm was not displayed in OMS. Troubleshooting data file storage in OMS OMS stores eNB troubleshooting data files in a folder for a set period or until the disk utilization reaches an upper limit. The period is set using the LDAP Parameter dwNELogDaysSpan. The default period is 10 days. Troubleshooting data file deletion in OMS OMS monitors the disk space utilization reserved for the troubleshooting data files, and performs clean-up procedure to remove the files that are older than the specified period (configurable by LDAP parameter dwNELogDaysSpan) when the disk utilization reaches the upper limit (90%). OMS also does automatic clean-up when some trigger of troubleshooting data upload is received from eNB. OMS deletes troubleshooting data files older than the defined period of time from its disk. Maximum storage time for the NE troubleshooting data files stored in OMS Even if disk space utilization is below the threshold of 90%, OMS stores troubleshooting data files only for a configurable amount of time (the default value as configured in the parameter dwNELogDaysSpan is set to 10 days), and will delete files that are older. Automatic upload to NetAct Troubleshooting data can be uploaded automatically to NetAct. This can be enabled and disabled by a flag in OMS. If automatic upload is activated, NetAct will receive the archive created by OMS and store it under the same file name in a reserved directory. NetAct will keep the data available for at least 5 working days, provided disk space permits this.

6.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.

DN09185967 Issue: 01M

© 2016 Nokia

201




6.4.1.5

LTE1099: Event-triggered symptom data collection and provisioning management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 104: New alarms lists alarms introduced with this feature. Table 104

New alarms

Alarm ID

Alarm name

71106

TROUBLESHOOTING DATA RECEIVED

71129

TROUBLESHOOTING DATA CREATION OR UPLOAD FAILED

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 105: Related parameters lists parameters related to this feature. Table 105

Related parameters

Full name Recovery reset delay

Abbreviated name recoveryResetDelay

Managed object LNBTS

Table 106: New OMS LDAP parameters lists parameters introduced with this feature. Table 106

New OMS LDAP parameters

Attribute ClusterRoot/OMS/OMSPlatform/SS_NELogManager/NELogManager/dwAlarmForUploadCom pleted ClusterRoot/OMS/OMSPlatform/SS_NELogManager/NELogManager/dwBTSUploadEnabled ClusterRoot/OMS/OMSPlatform/SS_NELogManager/NELogManager/NetActNotifyEnabled

202

© 2016 Nokia

DN09185967 Issue: 01M


6.4.1.6



Sales information

BSW/ASW



BSW

-

-

6.4.2 Collecting eNB logs using the LTE1099: Event-triggered symptom data collection and provisioning feature This procedure shows how to configure the LTE1099: Event-triggered symptom data collection and provisioning feature to automate the eNB snapshot collection. Before you start The feature configuration is done during an eNB commissioning. Procedure 1

Define the list of symptom data collection triggers. Add a new Symptom data trigger list under the MRBTS object. Figure 28

2

Defining symptom data trigger list

Set the Fault ID that should trigger the data collection. Up to 20 faults can be configured.

g

Note: Use the faults that most frequently occur in a certain site or contact Nokia Services for a list of recommended triggers.

3

Define the recovery reset delay. Configure the recovery reset delay parameter under the LNBTS object. If a fault leads to a recovery reset, the eNB might delay it according to the configured value: •

DN09185967 Issue: 01M

'0': no delay

© 2016 Nokia

203


• •

4


'1-9999': delay time '10000': wait for snapshot to be transferred in iOMS

Configure the dwBTSUploadEnabled parameter to enable/disable the data transfer to OMS. It is recommended to provide an empty trigger list if upload is to be permanently disabled.

5

Configure the dwAlarmForUploadCompleted parameter to enable/disable the alarm setting in OMS. If enabled, the 71106 TROUBLESHOOTING DATA RECEIVED alarms is raised once the data is received in OMS

6

Configure the NetActNotifyEnabled parameter to enable/disable the data upload to NetAct.

Result When a fault defined in the symptom trigger list occurs, the symptom data is collected. The 71129 TROUBLESHOOTING DATA CREATION OR UPLOAD FAILED indicates that the data creation or upload to OMS has failed.

6.5 LTE1260: iOMS Certificate Update and Revocation Support 6.5.1 Description of LTE1260: iOMS Certificate Update and Revocation Support Introduction to the feature The iOMS supports automatic certificate life cycle management by autonomous update of the operator certificates. The chain of trust comprising of up to three sub-ordinate CA certificates and the root CA certificate on top, increase flexibility in choosing architecture of Public Key Infrastructure. Revocation list support provides better certificate examination before a secure connection establishment.

6.5.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The operator benefits are as follows: • •

204

easier certificate management by automatic operator certificate updates flexible multi-layer certification hierarchy

© 2016 Nokia

DN09185967 Issue: 01M


enhanced certificate examination uniform certificate management between different network elements

• •

6.5.1.2



System release



RL50

-

-

Table 108

OMS

iOMS5.0


UE

NetAct

MME

SAE GW

-

OSS5.5 CD1

-

-


6.5.1.3

Functional description Functional overview The basic iOMS certificate management functionality implemented with LTE524: Certificate Management for iOMS feature is enhanced by automatic operator certificates update procedure, the support of multi-layer certificate authorities, and the certificate revocation check. Accepting only valid (not revoked) certificates for secure TLS/HTTPS communication increases the overall network security. Chain of trust As number of issued certificates in Public Key Infrastructure (PKI) increases in time, it might become difficult for a single certification authority (CA) to track efficiently all the certificates it has issued. One way to address this issue is to create a hierarchy of certification authorities where the root certification authority delegates the authority to issue certificates to its subordinate certification authorities that might, in turn, delegate authority to their subordinates. A chain of trust is a hierarchical collection of certificates that goes from the end user up to a root of trust, typically called a root certification authority (root CA) or trusted organization. The iOMS stores a complete chain of trust for its operator end entity certificate (operator EE certificate). When validating the operator EE certificate of a peer network element, the iOMS steps up the trust chain until the known trust anchor is found. If no trusted root CA certificate is found, the authentication fails and the secure connection request is rejected. The iOMS supports a chain of trust that consists of up to four layers (one root CA certificate and up to three subordinate CA certificates) as shown in Figure 29: Multi-layer certification authority support.

DN09185967 Issue: 01M

© 2016 Nokia

205


Figure 29


Multi-layer certification authority support

operator'srootCA certificate

operator's rootCA (intermediate) RA1certificate

(intermediate) CA1certificate (intermediate)

(intermediate)

CA1

RA1

(signing) CA2certificate

(intermediate) RA2certificate (intermediate)

(signing)

RA2

CA2

(signing) RA3certificate

endentitycertificate

signing RA3

network element

If a Registration Authority (RA) is not the same entity as the Certification Authority, a separate certificate for the RA is required. In such case, the iOMS supports also multilayer chain of trust for RA. This chain includes up to three optional subordinate RA certificates, and one signing RA certificate. The RA certificate chain must lead to the same root CA certificate that is used for operator CA certificate chain. Initial certificate enrollment The initial certificate enrollment with CMP protocol is already implemented with LTE524: Certificate Management for iOMS feature. For more details, see LTE524: Certificate Management for iOMS feature description. This feature improves the current manual certificate enrollment process by the possibility to use also password-protected PKCS#12 file format. The PKCS#12 is a standard for transferring identity information like private keys, certificates, and other related data. Network elements supporting this standard allow the user to import and export a set of identity information. The support of PKCS#12 file is added to unify the manual certificate management in eNB and iOMS. Operator certificate and key update Current operator certificate management with CMP is enhanced by operator certificate update procedure which is done automatically before the operator EE certificate's lifetime is going to expire. shows steps in operator certificate update procedure using CMP protocol.

206

© 2016 Nokia

DN09185967 Issue: 01M


Figure 30


Signaling flow of automatic certificate update Operator's CAroot Nokia CAroot

Network Element

Certificate Repository

Certification Authority

Generatekeypair Signcertrequestwithexpiringprivatekey

Keyupdaterequestwithauthentication information(CMPkurmessage) Verifyauthentication Verifysignature

Network Element

Signnewoperator'sEEcertificate Operator's CAroot Network Element

Keyupdateresponse(CMPkupmessage) Validatereceivedoperator'sEEcertificate

Acknowledgements (CMPcerConfandpkiconfmessages) AutomaticCRLupdate(ifconfigured)

When an operator EE certificate or any of the intermediate CA certificates need to be renewed for another period of time, the iOMS starts the operator certificate update procedure automatically. The time advance in which the iOMS informs about certificate expiration is configured by the operator with the CANECloseCertUpdateTimerAdv parameter. The iOMS generates a new key pair, includes public key into the key update request, and sends the request to the CA server over the CMP protocol. The CA server receives the key signing request, authenticates the request with the iOMS’ expiring operator EE certificate, generates and signs a new operator EE certificate, and sends it back the iOMS. The subordinate CA certificates and subordinate RA certificates are also included in the reply message. The iOMS validates all received certificates with the operator root CA certificate, stores them, and sends a confirmation message to the CA server. In exceptional cases, the Certification Authority might not send new certificates back to the requestor iOMS (because of, for example, DCN network unavailability) or the newly received certificates validation fails in the iOMS. In such case, the iOMS logs the event and starts the procedure again until its own chain of trust is renewed. If the certificate’s lifetime becomes shorter than the value configured with the CANECloserCertUpdateTimerAdv parameter, the iOMS triggers the 71125 CERTIFICATE EXPIRING alarm and keeps trying to get new certificates. The operator certificate update procedure can also be triggered manually from the iOMS console or from NetAct. Operator CA/RA certificates update

DN09185967 Issue: 01M

© 2016 Nokia

207



When CA certificates (an operator root CA certificate or optional subordinate CA certificates) are close to expire, the iOMS sends notification to the NetAct. Upon reception of the 71125 CERTIFICATE EXIPIRING alarm, the operator can choose one of the following actions, depending on the type of expiring certificate: •

t

When a subordinate CA/RA certificate expires, trigger the operator certificate update procedure. When the iOMS updates its operator EE certificate (even still valid), all subordinate CA/RA certificates in the trust chain are updated as well. Tip: The operator root CA certificate is not updated as a part of the operator certificate update procedure.

•

•

When the operator root CA certificate expires, trigger the operator certificate initialization procedure. During the operator certificate initialization procedure, apart from the operator EE certificate and subordinate CA/RA certificates, also the operator root CA certificate is sent to the iOMS. The CA server must be configured to allow a repeating CMP initialization procedure from the same iOMS. If any of the operator CA/RA certificate expires (either the root CA certificate or one of subordinate CA certificates), configure the certificate manually. The manual configuration is always possible and might be needed in case the operator runs no online Public Key Infrastructure.

Certificate storage Certificates files, which store public key and subject information do not contain any sensitive information, are integrity protected by Certification Authority signature, and do not require additional security. The iOMS supports the storage of up to 12 certificates. This includes an operator root CA certificate, up to three subordinate CA certificates, an operator EE certificate, and an optional RA certificate chain (one signing RA certificate and up to three subordinate RA certificates). Certificate revocation support Certificate revocation is done when properties of network elements change (such as private key compromise, change in affiliation, name change, or a network element is removed from the network). When certificates are identified for revocation, a new version of the certificate revocation list (CRL) is created in the operator CA and published in certificate revocation server (LDAP server). Network elements download the updated version of the CRL automatically, or as a result of manually triggered CRL update procedure. The CRL are also updated during: • • •

network element start up operator certificate initialization procedure operator certificate update procedure

When iOMS retrieves a new CRL from the certificate revocation server, also called CRL Distribution Point, the iOMS first verifies if the signature of the CRL is correct and if its own chain of trust is still valid. If its own operator EE certificate or any of subordinate CA certificates are revoked, the iOMS tries to get a new operator EE certificate with the operator certificate initialization procedure. New secure connections from other network elements to that iOMS will only be possible after the iOMS obtains a new operator certificates.

208

© 2016 Nokia

DN09185967 Issue: 01M



In an exceptional case, when the iOMS’ operator EE certificate needs to be revoked because of corrupted keys, it is recommended to trigger the operator certificate initialization procedure in the iOMS. This ensures using the new certificates straight away for all connections to avoid interruptions of secure connections. Otherwise, a certain time is needed between the CRL creation, publication in a certificate repository server, the download of the new CRL version to a network element, own certificate validation, and the start of operator certificate initialization procedure. Figure 31

Revoking an operator certificate

OMS Certification Authority

Security Engineer

Certificate Repository

Triggercertificate initializationprocedure

Certificateinitializationprocedure Revokeoperator EEcertificate Addcertificate toCRLandissue newCRL

PublishnewCRL

t

Tip: The iOMS expects that a CRL is always published in the certificate revocation server, even if the CRL has no information of revoked certificates (an empty CRL). When a CRL cannot be downloaded from certificate revocation server because of download failure or unreachable server, the iOMS logs the event in the log and retries to obtain the CRL until successful. If the certificate revocation server has no CRL, the iOMS raises the CRL update failure alarm and does not perform any retries. The iOMS expects X509v2 format for CRL and CRLDistributionPoints extension. Certificate revocation check On secure connection establishment, the iOMS checks the received peer network element certificate if it is revoked. The CRLs are downloaded to the iOMS from the certificate revocation servers (CRL distribution points) that are included in the own operator EE certificate and the certificates in own trust chain. The CA signature and certificate’s lifetime is also validated. Once the certificate is successfully verified, the subsequent secure connection can be established as shown in Figure 32: Establishing new TLS connection with CRL check.

DN09185967 Issue: 01M

© 2016 Nokia

209


Figure 32


Establishing new TLS connection with CRL check attemptfornew secureconnection

signatureinvalid/ expired

validatereceived operatorcertificates (signature&lifetime)

certificatesvalid CRLcheck enabled?

NO

YES reject connection

YES

peercertificates inCRL?

NO establishnew secureconnection

To make the certificate revocation check efficient, the iOMS must check all the received certificates against the most up-to-date certificate revocation list (except the root CA certificate, which is either trusted or not). For this reason the iOMS downloads CRLs regularly, verifies, and uses only those CRLs which have correct CA signature. The frequency of CRL download is configured with the CRLPeriodicDownloadTimer parameter. The CRL update can be also manually triggered from the iOMS console, NetAct, or be a part of operator certificate initialization or operator certificate update procedure. The iOMS updates CRLs using CRLDistributionPoints from its own operator EE certificate. The protocol used for the CRL download is LDAPv3. Alternatively, the operator might install CRLs in the iOMS manually. The CRL support is an optional functionality in the iOMS. By default, the CRL support in the iOMS is disabled. If enabled, the CRLs are checked for: • • •

secure file transfer The iOMS, acting as a client, verifies the server’s operator EE certificate. secure BTS O&M interface The iOMS, acting as a server, verifies the eNB’s operator EE certificate. secure connection to Centralized User Authentication and Authorization (CUAA) server The iOMS, acting as a client, verifies the CUAA server’s operator EE certificate.

Certificate version and life cycle management

210

© 2016 Nokia

DN09185967 Issue: 01M



Certificate profiles, key types, CMP procedures, and certificate life cycle management follow common certificates rules defined in 3GPP TS33.310 Network Domain Security (NDS); Authentication Framework (AF). For more details on certificate life cycle management and certificate profiles, see Certificate management in LTE RAN O&M Security functional area description. Feature activation and configuration The support for multi-layer CA/RA does not require activation and is enabled by default. The CRL checking is disabled by default. To enable the CRL checking in the iOMS, see Certificate management in Administering and Security in LTE iOMS.

6.5.1.4

System impact Interdependencies between features The LTE524: Certificate Management for iOMS feature is a prerequisite for this feature. Impact on interfaces This feature has impact on the following interfaces: HTTPS O&M interface (secured with TLS) CUAA interface (secured with TLS)

• • •

Impact on network and network element management tools This feature simplifies network management by automatic and centralized certificate management functions. Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.5.1.5

LTE1260: iOMS Certificate Update and Revocation Support management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms lists alarms introduced with this feature. Table 109

New alarms

Alarm ID

Alarm name

71122

CRL UPDATE FAILURE This alarm is raised if iOMS cannot download or validate the downloaded CRL from the certificate revocation server.

71123

CERTIFICATE REVOKED This alarm is raised if the operator certificate signed with CA certificate could not be validated.

71133

CERTIFICATE CAPACITY REACHED

DN09185967 Issue: 01M

© 2016 Nokia

211


Table 109


New alarms (Cont.)

Alarm ID

Alarm name

71134

CERTIFICATE EXPIRED

70381

CRL DOWNLOAD FAILURE This alarm is raised if the iOMS cannot download or validate a CRL for peer’s operator certificate.

lists existing alarms related to this feature. For a full list of existing parameters, see also management data in LTE524: Certificate Management for iOMS feature description. Table 110


Alarm ID 71125

Alarm name CERTIFICATE EXPIRING This alarm is raised, when its own operator certificate, root CA certificate, or subordinate CA certificate is about to expire.

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 111: New OMS LDAP parameters lists parameters introduced with this feature. Table 111

New OMS LDAP parameters

Attribute

CANECloseCertUpdateTimerAdv Defines how many days in advance the iOMS triggers the operator certificate update procedure or fetch CA certificates from the certificate repository (if CR is configured).

CANECloserCertUpdateTimerAdv Defines how many days in advance the iOMS raises the 71125 CERTIFICATE EXPIRING alarm and triggers the operator certificate update procedure or fetch CA certificates from the certificate repository (if CR is configured).

CRLPeriodicDownloadTimer This parameter defines how often the iOMS downloads CRLs from CRL distribution points.

212

© 2016 Nokia

DN09185967 Issue: 01M


Table 111


New OMS LDAP parameters (Cont.)

Attribute

CRLDistributionPointExtension This parameter defines if CRLs are downloaded from distribution points given in cRLDistributionPoint extension of operator certificates.

TLSSessionWithoutCRLAvailable Defines if a TLS session should be established if, for some reason, the CRL for peer certificate is not available. By default the iOMS continues to establish TLS connection.

CRLDownloadInBackground This parameter defines allowing/disallowing CRL download for peer certificates in background (out of the TLS session). The downloaded CRL will be available for the next TLS session.

DownloadCRLTimer This parameter defines timer in milliseconds (ms) for CRL download related with peer certificate in background (out of the TLS session) or in foreground (during the TLS session).

CRLCumulativeTimer This parameter defines total timer in seconds for CRL download for all peer certificates in foreground

6.5.1.6


Sales information

BSW/ASW



BSW

-

-

6.6 LTE1367: Automatic cell combination assignment for carrier aggregation 6.6.1 Description of LTE1367: Automatic cell combination assignment for carrier aggregation Introduction to the feature The LTE mobility features (for example, LTE1089: Downlink carrier aggregation - 20 MHz) require to indicate groups of interworking cells. The LTE1367: Automatic cell combination assignment for carrier aggregation feature offers an automatic cell selection algorithm for: •

DN09185967 Issue: 01M

identifying the best candidates for Carrier Aggregation (CA)

© 2016 Nokia

213



creating necessary Configuration Management (CM) objects setting corresponding parameter values

• •

No manual selection of cells is required anymore.

6.6.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits the operator as follows: Automatic and optimized cell selection mechanism eliminates manual planning of cell combinations that are used in LTE mobility scenarios. The auto-configuration procedure can be enhanced with necessary CA assignments.

• •

6.6.1.2


System release



RL50

-

-

Table 113

OMS

-


UE

NetAct

MME

SAE GW

-

OSS 5.5

-

-


6.6.1.3

Functional description The LTE1367: Automatic cell combination assignment for carrier aggregation feature introduces an automatic algorithm to detect and configure cell pairs of a certain eNB appropriate for carrier aggregation functionality. It can be used during planning activities in the NetAct Optimizer or as an unattended function that: • •

provides proper cell pairs during auto-configuration process generates reports on the validity of cell pairs

Specific conditions for cell pairs applicable for carrier aggregation are considered (defined for the LTE1089: Downlink carrier aggregation - 20 MHz feature), for example: •

214

overlapping coverage area

© 2016 Nokia

DN09185967 Issue: 01M


LTE1089: Downlink carrier aggregation - 20 MHz feature activation certain bordering conditions:

• •

– – –

g


maximum 2 cells, both in the same eNB same bandwidth (5 or 10 MHz) or asymmetric carrier aggregation for 5+10 MHz different bands

Note: Some of the conditions are not verified by this algorithm. They need to be configured together with the carrier aggregation feature. For details, see the LTE1089: Downlink carrier aggregation - 20 MHz feature description. The sector identifier (sectorId) parameter and the Carrier Aggregation Relation (CAREL) object used in CA are generated for the cells in primary component carrier (PCC) and cells in secondary component carrier (SCC). The cells in the same sector are configured with the same sectorId and the CAREL identifies the cell pairs used for carrier aggregation. The functionality is applied for the eNBs/cells in the network for which carrier CA is enabled. Activation of the LTE1089: Downlink carrier aggregation - 20 MHz feature (actDLCAggr = true) requires an eNB restart, so an automated CA activation should be carefully planned. If the LTE1089: Downlink carrier aggregation - 20 MHz is not activated in a certain eNB, the algorithm can be used to prepare a list of appropriate cells to be used for future planning, when CA is applied. The selection of the corresponding cell pairs is proposed by Optimizer algorithms. If no corresponding cell pair can be identified, the operator is informed about possible mismatch in the configuration. The operator can decide, if he would like to activate the proposed changes in the network or discard them. Cell pair detection algorithm overview To detect overlapping cells the algorithm evaluates the differences in: • • • • •

location of the antennas bearing of the antennas main lobe beam width of the antennas tilt of the antennas transmit power of the cells

The corresponding parameters are listed in . The operator is able to select which of the above mentioned criteria the algorithm should use to detect overlapping cells. The algorithm applies user-defined thresholds and selects only these cells, that fulfill all criteria given by the operator. If the Optimizer detects a suitable cell pair candidate, it: • •

sets the sectorId of both cells accordingly creates CAREL (if the combination of bands and bandwidths of the cells fulfills the required bordering conditions for LTE1089: Downlink carrier aggregation - 20 MHz)

By default, the Optimizer overwrites sectorId or delete CAREL if those do not match the rules. The operator can decide whether to keep existing values unchanged (by setting the caControl LNBTS parameter).

DN09185967 Issue: 01M

© 2016 Nokia

215



In all the scenarios the operator gets a feedback about success, failure, and possible exceptions. Typical scenarios •

Auto-configuration for an individual eNB 1. Optimizer runs the algorithm for all cells of the eNB, irrespective of the initial site configuration plan (LTE1089: Downlink carrier aggregation - 20 MHz activated or not). 2. Optimizer detects cell pairs with reasonable overlap according to a user-defined criteria. 3. Optimizer sets sectorId of both cells accordingly. 4. Optimizer creates CAREL (If the combination of bands and bandwidths of the cells follows the required bordering conditions for LTE1089: Downlink carrier aggregation - 20 MHz). 5. Optimizer adds context information to support SON reports. 6. Auto-configuration mechanism downloads and activates the plan. 7. NetAct provides report to the user and log file.

g

•

•

Note: The user can set a preference (caControl parameter) to define whether the algorithm should overwrite the existing configuration. By default, the algorithm overwrites sectorId or deletes CAREL if those do not match the requirements (the feature activation flag for LTE1089: Downlink carrier aggregation - 20 MHz is not modified).

Cell pair selection as a part of preparation for auto-configuration Applied for all new eNBs to prepare a plan for auto-configuration. In this scenario, the Optimizer automatically detects and configures the appropriate cell pairs of each eNB irrespective of the LTE1089: Downlink carrier aggregation - 20 MHz feature activation flag value. Interactive plan for carrier aggregation The operator uses the algorithms and the Optimizer user interface to interactively plan carrier aggregation. Since the activation of CA requires an eNB restart, it should be performed interactively, either by using the interactive mode of Optimizer or manually by activating a plan (that has been automatically prepared during autoconfiguration preparation). 1. The operator defines preferences for Optimizer and its algorithm. 2. The optimizer proposes useful CA pairs. 3. The operator selects the CA relations to be established, modifies, and fine-tunes the plan. If needed, the operator provides preconditions and dependencies that are necessary to activate carrier aggregation. 4. Optimizer and Configurator generate a correct and consistent plan that contains sectorId, actDLCAggr = true, and CAREL. 5. The operator downloads and activates the plan.

6.6.1.4

System impact Interdependencies between features The LTE1367: Automatic cell combination assignment for Carrier Aggregation feature enhances the functionality of LTE1089: Downlink carrier aggregation - 20 MHz.

216

© 2016 Nokia

DN09185967 Issue: 01M



Impact on interfaces This feature has no impact on interfaces. Impact on network and network element management tools The NetAct Optimizer functionality is enhanced with the cell pairs detection algorithm that selects potential candidates for CA. Impact on system performance and capacity This feature has no impact on system performance or capacity.

6.6.1.5

LTE1367: Automatic cell combination assignment for Carrier Aggregation 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 related to this feature. Table 114

Related parameters

Full name

Abbreviated name

Managed object


actDLCAggr

LNBTS

Cell sector id

sectorId

LCELL

Antenna horizontal beamwidth

horBeamwidth

ANTL/ANTE

Antenna total tilt

totalTilt

ANTL/ANTE

Antenna bearing

bearing

ANTL/ANTE

Carrier aggregation control

caControl

LNBTS

Maximum output power

pMax

LNCEL

Local cell resource ID of cell to be aggregated

lcrId

CAREL

Carrier aggregation relation identifier

caRelId

CAREL

DN09185967 Issue: 01M

© 2016 Nokia

217


6.6.1.6



BSW/ASW

Sales information


ASW NetAct -

License control attributes -

6.7 LTE1368: System Upgrade with Backward Compatibility 6.7.1 Description of LTE1368: System Upgrade with Backward Compatibility Introduction to the feature The LTE1368: System Upgrade with Backward Compatibility feature enables the smooth upgrade from major release RL40 to release RL50 in the overall network including the backwards compatibility. It describes overall upgrade strategy and system upgrade workflow.

6.7.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature provides the operator with the smooth upgrade path from major release RL40 to release RL50.

6.7.1.2


System release



RL50

LBTS5.0

LBTS5.0

Table 116

218

OMS

OMS5.0


UE

NetAct

MME

SAE GW

-

OSS5.5 CD1

-

-

© 2016 Nokia

DN09185967 Issue: 01M




6.7.1.3

Functional description The LTE1368: System Upgrade with Backward Compatibility feature describes the SW upgrade from release RL40 to release RL50, including backward compatibility and possibility to fallback to RL40 release. As RL40 have introduced two new entities, Layer 3 Data Collector (L3DC) and Traffica, the two entities are considered for SW upgrade as well. The upgrade from RL40 release to RL50 release is possible in one step. No intermediate SW versions are required. System upgrade (which includes: SW download, SW upgrade, and fallback) can be managed locally and remotely via NetAct. Service outages are minimized by using available resiliency features and hardware redundancy. Therefore it is not possible to take the whole system out of service for introduction of a new SW release.

g

Note: It is recommended to perform the system upgrade in a time period with low traffic load (for example during night time) as service degradation and partial service loss cannot be fully avoided during upgrade. The system upgrade is performed step by step, in a top down approach as shown in the Figure 33: Top-down approach for the system upgrade: Figure 33

Top-down approach for the system upgrade

RL70 Optional elements NetAct new release

NetAct old release

Traffica new release

Traffica old release

Top down

OMS new release

OMS old release

L3DC new release

L3DC old release

eNB new release

eNB old release

eNB old release

eNB old release

FDD-LTE 15A

DN09185967 Issue: 01M

© 2016 Nokia

219



During the system upgrade from RL40 to RL50, HW upgrade cannot be combined with the SW upgrade. The upgrade paths for Flexi Multiradio platform are: • •

FSME to FSME FSMF to FSMF

The following upgrade path needs to be performed for successful system upgrade as presented in the Figure 33: Top-down approach for the system upgrade: •

•

•

•

•

Step A1 NetAct upgrade: OSS5.4 CD2 plus PCD -> OSS5.5 CD1 During system upgrade, the NetAct must be able to manage network elements (NE) of RL50 release and lower, RL40 release. Step A2 iOMS upgrade: iOMS 4.0 -> iOMS 5.0 The iOMS upgrade needs to be performed after successful NetAct upgrade. It is not needed to upgrade all iOMSes of an LTE network, before the first eNB can be upgraded. Instead it is possible to upgrade a complete branch of the hierarchy including iOMS and down to the eNBs of this iOMS. Step B1 Traffica upgrade: Traffica 6 -> Traffica supporting RL50 There is no dependency between the Traffica upgrade and the NetAct, iOMS, and eNB upgrade. To make upgrade procedure more efficient, it is recommended to upgrade Traffica in parallel with NetAct. Step B2 L3DC upgrade: Rel 5.0 -> Rel 6.0 This step is executed after Traffica has been upgraded. Step A3 eNB upgrade: LBTS 4.0 -> LBTS 5.0 This step needs to be executed after the controlling iOMS has been upgraded.There is no dependency between eNB upgrade and Traffica/L3DC upgrade, however it is recommended to upgrade eNB after L3DC has been upgraded. If eNB is upgraded and L3DC is still in old version, no problems are expected, since unknown messages will be ignored by L3DC.

After system upgrade and fallback no important information of all NE is lost. That includes: • • • • •

network security related system data information (for example certificates, keys) user security related data (for example user accounts, passwords) license information symptom, trace, and log data configuration data (which includes for example: transport configuration, BTS configuration, RNW configuration, PM data configuration)

Backward compatibility Backward compatibility means that interworking between upgraded and non-upgraded NEs is possible during system upgrade. As a consequence of the top-down approach: • •

220

NetAct of release RL50 needs to support iOMS and eNodeB of releases RL40 and RL50 iOMS of SW release RL50 needs to support eNB releases of RL40 and RL50

© 2016 Nokia

DN09185967 Issue: 01M



Traffica of release RL50 needs to support L3DC and eNB of releases RL40 and RL50 L3DC of release RL50 needs to support eNB of releases RL40 and RL50

• •

In addition also mixed eNB and OMS configurations (for example iOMS RL50, eNB RL40) needs be supported by iOMS and NetAct as well as mixed L3DC and eNB configurations (for example L3DC RL50, eNB RL40) need be supported by L3DC and Traffica. The eNB SW of a new release (RL50) is backward compatible with configuration data of former base release (RL40). The new SW after start up, can access, and read configuration data of former release as input for conversion to the new format. This is necessary to support automatic online data conversion. Fallback All NEs support automatic and manual fallback to source SW release (RL40 release) and configuration data. It is possible to trigger manual fallback remotely, if connection to NEs is established and interfaces are setup. Fallback is possible only if the source SW version has not been removed or overwritten by a new SW load from disk or non-volatile memory (NVS).

g

Note: If LTE523: Multi-layered Certificate Authorities feature is configured in RL50 network, then direct fallback of eNB to former release is not possible, the operator must re-configure a single-rooted hierarchy before the fallback. In case of automatic fallback, NE raises an alarm (7650 BASE STATION FAULTY) to indicate that upgrade was not successful.

6.7.1.4

System impact Interdependencies between features If LTE523: Multi-layered Certificate Authorities feature is activated in RL50 and multilayer signing is in use, direct fallback of eNB to former release is not possible.

g

Note: It is recommended to create a new fallback eNB SW version before activating LTE523: Multi-layered Certificate Authorities 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 Overall system performance and capacity might be affected during the upgrade procedure, when NEs become fully or partially unavailable. With the new SW some new functionalities are implemented which might impact the overall system performance and capacity, but this is out of scope of this feature description.

DN09185967 Issue: 01M

© 2016 Nokia

221


6.7.1.5


LTE1368: System Upgrade with Backward Compatibility management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 117: Related existing alarms lists existing alarms related to this feature. Table 117


Alarm ID

Alarm name

7650

BASE STATION FAULTY

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.

6.7.1.6


Sales information

BSW/ASW



BSW

-

-

6.8 LTE1383: Cell-specific Neighbor Relation/PCI Handling 6.8.1 Description of LTE1383: Cell-specific Neighbor Relation/PCI Handling Introduction to the feature The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature allows to make optimal usage of ANR- and handover-related features even in not perfect network setup conditions.

222

© 2016 Nokia

DN09185967 Issue: 01M



Cell-specific NR and PCI handling is needed to cope with network deployments with distributed sites, respectively for non-optimized network environments, for which handling of NRs per eNB is not sufficient. This enables the eNB to handle situations, where different neighbor cells with the same PCI and frequency are visible for different eNB cells. The following enhancements are included: cell-specific PCI resolution physical cell ID (PCI) validation extend maximum number of X2 neighbor eNBs from 32 to 64

• • •

6.8.1.1

Benefits End-user benefits The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature benefits the end user as follows: The increased number of X2-links from 32 to 64 allows the customer to connect all relevant neighbor eNBs via X2 to the eNB. The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature helps to keep good performance of the handover-related features.

• •

Operator benefits The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature benefits the operator as follows: The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature enables cellspecific PCI/NR configuration via O&M for inter-frequency LTE cells and cell-specific learning of PCI/NR via ANR for intra-frequecy LTE cells. The eNB detects and stores NRs per eNB cell. NRs are stored by eNB per cell and considered for HO.

•

•

6.8.1.2

Requirements Software requirements Table 119: Software requirements lists the software required for the LTE1383: Cellspecific Neighbor Relation/PCI Handling feature.

System release



RL50

LBTS5.0

LBTS5.0

Table 119

OMS

-


UE

NetAct

MME

SAE GW

-

OSS5.5

-

-

Hardware requirements

DN09185967 Issue: 01M

© 2016 Nokia

223



The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature requires no new or additional hardware.

6.8.1.3

Functional description Functional overview The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature introduces additions to the existing ANR features to allow high stability of the feature, even in difficult network setups. The following improvements are included: • •

NR and physical cell ID (PCI) support per eNB cell per carrier extension of the number of supported X2-links to provide X2 connectivity for all relevant NRs, for example in non-optimized network environments

The eNB supports cell-specific PCI and NR handling in the following ways: •

•

• •

•

The eNB establishes and handles the NRs associated to a certain PCI and frequency per eNB cell. The uniqueness of PCI/Freq is required for the NRs associated to the eNB cell. The NRs are validated by the eNB. To perform this validation, the eNB retrieves cell global identification (CGI) measurements from suitable UEs if UE-based ANR is available. The eNB detects and stores NRs per eNB cell. HO procedures are triggered using the stored cell-specific NRs. The cell-specific NRs might be provided via O&M or learned automatically via ANR features (using meachanisms of the LTE492: AND and the LTE782: ANR Fully UE Based features). For intra-frequency neighbor cells: – –

•

The eNB automatically determines the correct NRs even if there are several neighbor cells in the eNB service area with the same PCI/Freq. The eNB supports UE-based ANR, see the LTE782: ANR Fully UE Based.

For inter-frequency neighbor cells: – – – –

The eNB automatically determines the correct NRs, but only if PCI/Freq of all neighbor cells in the eNB service area are unique. The eNB supports only OAM-based ANR. To remove the restriction to have unique PCI/Freq in the eNB area, support of the LTE556: ANR Intra-LTE, Inter-frequency - UE Based feature is needed. If for a certain PCI/Freq several inter-frequency neighbor cells are visible for the eNB, the correct NRs have to be provided via O&M.

The cell-specific PCI handling is backward compatible in the sense that with respect to target cell selecion the legacy behaviour is supported even if UE-based ANR features are deactivated. X2 Link Handling to cell-specific NR handling For the resolution of a detected neighbor cell, the eNB supports two mechanisms: •

224

OAM-based ANR (if the LTE492: ANR feature is activated): in this case an X2-link establishment is triggered using the PCI-IP address mapping table provided via O&M.

© 2016 Nokia

DN09185967 Issue: 01M



UE-based ANR (if for example, the LTE782: ANR Fully UE Based feature is activated): in this case a CGI measurement is triggered.

•

Because of the introduction of the cell-specific PCI/NR handling, the eNB enhances the X2-link handling as follows: The eNB no longer triggers an X2-link establishment for the resolution of a neighbor cell via OAM-based ANR, if resolution of the neighbor cell via UE-based ANR is triggered. Concerning retrieval of the IP-address to be used for X2-link establishment, the eNB uses IP-address retrieval via S1-interface if the LTE492: ANR feature is deactivated or the IP-address is not available in the PCI-IP address mapping table.

•

•

Assigning the same PCI/EARFCN values for neighbors of different eNB cells The eNB handles Neighbor Relations (NRs) for each LTE carrier per eNB cell. If the eNB receives a measurement report triggering a mobility procedure (that is, measurement report A3 triggering a handover), then the eNB uses for the mobility procedure the neighbor cell identified as NR of the respective eNB cell, see Figure 34: LTE NRs of eNB-A for a given LTE carrier. The HO is triggered to the neighbor cell that is identified as NR of the respective eNB cell. Identification of the NR occurs cia ANR handling or via O&M configuration.

g

Note: The eNB validates the NRs used for the HO via CGI measurement if UE-based ANR is available. ANR configuration via ANRPRL The Automatic Neighbor Relationship Profile LTE (ANRPRL), a new managed object class (MOC), defines carrier frequency-specific settings for automatic detection of LTE intra-frequency and inter-frequency neighbor cells. Up to 32 ANRPRL instances might exist per eNB, where they are persistently stored. The instance with id 0 (default profile) is mandatory independent from the activation of any ANR feature. The ANRPRL managed object class (MOC) includes the following parameters: •

•

DN09185967 Issue: 01M

anrPrLId This parameter uniquely identifies an ANRPRL object. "anrPrLId=0" is the mandatory default profile and is applied to all target carriers, for which no other frequencyspecific ANR profile is available. targetCarrierFreq The parameter identifies the EUTRA target carrier frequency for which this ANR profile applies. The profile applies for intra-/inter-frequency ANR dependent on the carrier frequency of the cell. If no targetcarrier is defined, the profile applies for any frequency which is measured by a UE. This profile is considered as default profile and must exist in any case. The parameter must be omitted in the ANRPRL instance with "anrPrLId=0" (default profile). The parameter is mandatory in ANRPRL instance with anrPrLId greater than 0. Profile is effective only if measurements for targetCarrierFreq are performed by the eNB cell (for example, for inter-frequency case, measurements is activited only if LNHOIF for targetCarrierFreq is created).

© 2016 Nokia

225


•

•

•

•

•


actAlsoForUeBasedANR The following states are possible: –

"true": beside OAM-based ANR (if activated) is allowed towards this

–

targetCarrierFreq "false": the profile is not applied for UE based ANR but still applied for not UEbased ANR features (for example, the LTE492: ANR feature)

nrLimitIntraFreq When the number of LTE intra-frequency NRs of the eNB cell reaches the nrLimitIntraFreq, the eNB stops autonomous learning of new intra-frequency PCIs and their related neighbor cell configuration via ANR. The number of intrafrequency NRs can exceed this limit since new neighbor cells/NRs still can be configured via O&M and autonomous creation of NRs for already available neighbor cells might occur. nrLimitInterFreq When the number of LTE inter-frequency NRs of the eNB cell reaches the nrLimitInterFreq, the eNB stops autonomous learning of new inter-frequency PCIs and their related neighbor cell configuration via ANR. The number of interfrequency NRs can exceed this limit since new neighbor cells/NRs still can be configures via O&M and autonomous creation of NRs for already available neighbor cells might occur. anrThresRSRPNbCell If RSRP of neighbor cell included in ANR measurement "reportStrongestCells" is greater than anrThresRSRPNbCell, then a cell is accepted by eNB as a neighbor cell for which CGI is needed The anrThresRSRPNbCell parameter is relevant only if the LTE782: ANR Fully UE Based feature is activated. The anrThresRSRPNbCell parameter is relevant for UE-based ANR only. anrThresRSRQNbCell The eNB requests to resolve the CGI of unknown cells detected via a "ReportStrongestCell" only it the respective RSRQ level measured by the UE is at least equal to the anrThresRSRQNbCell parameter. The anrThresRSRQNbCell parameter is relevant if the LTE782: ANR Fully UE Based feature is activated. The anrThresRSRQNbCell parameter is relevant for UE-based ANR only.

With the introduction of the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature, the validityOfData parameter is deleted from LNADJL. The main difference coming with the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature to the LTE782: ANR Fully UE Based and the LTE492: ANR features, is the feature activation per carrier frequency (targetCarrierFreq), as defined by one or more ANRPRL instances. Each instances or ANRPRL defines for one carrier frequency (targetCarrierFreq) the behavior. If also depends on the feature flags for the LTE782: ANR Fully UE Based (actUeBasedAndIntraFrewLte)and the LTE492: ANR (anrRmExtEnable), which ANR activity is working. The nLTEIntraNeighbours parameter is replaced by the nrLimitIntraFreq and the nrLimitInterFreq parameters, so the operator can set distinct values for intrafrequency and inter-frequency neighbors. Those values are applicable to the LTE492: ANR and the LTE782: ANR Fully UE Based features with the assignment of the ANRPRL instance to the carrier frequency (targetCarrierFreq).

226

© 2016 Nokia

DN09185967 Issue: 01M



After upgrade to RL50 there is one default ANRPRL profile without a targetCarrierFreq parameter set, so this profile is valid for all carriers. For all carriers (actAlsoForUeBasedANR="true", default value) the LTE782: ANR Fully Based feature is activated if the actUeBasedAnrIntraFreqLte parameter is set to "true". The LTE492: ANR feature is activated for all carriers if the anrOmExtEnable parameter is set to "true". This is the same behaviour as for RL40. The LNREL parameter nrStatus has range = { unavailable, available ). When it is set to "unavailable", it shows an LNREL that has no corresponding LNADJL. LTE NRs of eNB-A for a given LTE carrier The eNB receives a measurement report triggering an HO procedure (measurement report A3/A5) in cell A2. The eNB triggers HO towards neighbor cell B1 (since neighbor cell B1 is an NR to cell A2). The eNB receives a measurement report triggering an HO procedure (measurement report A3/A5) in cell A3. The eNB triggers HO towards neighbor cell C1 (since neighbor cell C1 is an NR to cell A3).

• • • •

If the eNB receives a measurement report triggering a mobility procedure (that is, measurement report A3 triggering an HO), then the eNB uses for the mobility procedure the neighbor cell identified as NR of the respective eNB cell. The HO is triggered to the neighbor cell which is identified as NR of the respective eNB cell. Identification of the NR occurs via ANR handling or via O&M configuration.

g

Note: The eNB validates the NRs used for HO via CGI measurement if UE-based ANR is available. Figure 34

LTE NRs of eNB-A for a given LTE carrier MeasurementReport

eNB-A Measurement Report

A1 (PCI=3)

C1 (PCI=8) A3 (PCI=4)

A2 (PCI=5)

C2 (PCI=9) C3 (PCI=10)

B1 (PCI=8) B2 (PCI=7)

NeighboreNB-C

D1 (PCI=8)

RRH

B3 (PCI=6)

Neighbor eNB-D

D2 (PCI=12) A4 (PCI=11)

NeighboreNB-B

DN09185967 Issue: 01M

© 2016 Nokia

227



Example of targeted network deployment, see Figure 34: LTE NRs of eNB-A for a given LTE carrier: NRs of cell A3 used for HO: A1, A2, C1, C3 NRs of cell A2 used for HO: A1, A3, B1, B2 NRs of cell A4 used for HO: D1, D2

• • •

Informing the customer about the NRs in use by the eNB An NR is indicated to O&M if the neighbor cell is used by the eNB for handover (HO) purposes. The following conditions must be fulfilled: The eNB-A is operable. LTE cell environment of the eNB-A for a certain LTE carrier is as shown in Figure 34: LTE NRs of eNB-A for a given LTE carrier No NRs are stored by the eNB-A.

• • •

The eNB-A automatically learns the configuration information of neighbor cells (via X2 establishment or via ECGI measurements) and stores the neighbor cell configuration information. A neighbor cell NbCell 1 for which the configuration information has been learned and which is selected by eNB cell A for a HO preparation attempt is shown by eNB-A in the object model as an (RNL-available) NR of the eNB cell A. NRs used by eNB-A as target cells for HO preparation attempts are shown in the object model of the eNB. Configuration information of neighbor cells served by neighbor eNBs are visible in objects model via LNADJ/LNADJL objects.

g

Note: The “RNL-available Neighbor Relation” term is used for NRs known by eNB and used for HO preparation attempts. RNL-available NRs are visible in object model via LNREL objects, and have the following properties: • • •

RNL-available NRs have nrStatus=available. unidirectional relationship between a source cell (served by the eNB) and a target neighbor cell (served by eNB or by a neighbor eNB) The configuration information of the target neighbor cell (ECGI, PCI and carrier frequency) is known to the eNB.

Because of the support of cell-specific PCI/NR handling, for each eNB cell and each LTE target carrier frequency an own set of RNL-available NRs is stored and handled by the eNB. The cell-specific PCI/NR handling allows that different eNB cells might use different neighbor cells for HO, which have the same frequency and PCI. The eNB supports the validation of an NR by triggering a CGI measurement after the first creation of the RNL-available NR. The eNB considers the X2-link to a certain neighbor eNB (NbeNB) as needed, if there is at least one RNL-available NR available, which is associated with the NbeNB. Otherwise, the X2-link is considered as not needed by the eNB. Establishing an associated X2-link to the neighbor eNB for all NRs relevant for HO The following conditions must be fulfilled: • •

228

The eNB is operable. ANR functionality is activated in the eNB.

© 2016 Nokia

DN09185967 Issue: 01M


•


Configuration of network, respectively of eNB and neighbor eNBs, allows the establishment of associated X2-links.

For the NRs used by eNB for HO, the eNB automatically establishes X2-links to the associated neighbor eNBs. Up to 64 X2-links might be established by the eNB. An X2link establishment is not possible if the link is forbidden by operator configuration or if the maximum available number of X2-links (64) is already exhausted. Planing the PCI allocations in a network with the NetAct Optimizer/cSON tool and PCI allocations unique in cell scope The NetAct Optimizer/cSON finds PCI allocation for all cells in the network avoiding PCI collisions and confusions on cell level. For all LTE cells, a PCI allocation is available which is collision- and confusion-free on cell level. Removal of the PCI conflict NetAct Optimizer/cSON ensures PCI values that are unique for all served cells of an eNB. NetAct Optimizer/cSON corrects PCI duplications, by assigning different PCI values to the related cell, identified by the NetAct CGI value. Some PCI duplications are not visible from eNB NR status reporting. It happens when the eNB has initially less neighbors, or removes neighbors with duplicate PCI values, if those are added during ANR operations. For this reason NetAct Optimizer/cSON additionally checks for minimum PCI reuse distance, if this option is selected as “true”. PCI uniqueness rule NetAct Optimizer/cSON mandatorily ensures PCI values to be unique for a cell and all its neighbor cells. This rule should to be re-checked periodically (self-healing) to capture all its neighbor cells as reported in the actual configuration of each LNCEL and their modeled LNREL objects. For initial PCI assignment during auto-configuration the PCI is optionally unique for neighbors' neighbors as well. This rule might be dropped in case of PCI value range limitations that do not allow to assign collision- and confusion-free PCI values. Neighbor Relation (NR) and PCI support per eNB cell and per carrier If different neighbor cells with the same PCI and frequency are visible for different eNB cells, for example, if Remote Radio Heads are used, then the eNB behaves as following: • •

g

for intra-frequency LTE neighbor cells: the eNB resolves and handles NRs per eNB cell via Fully UE based ANR, if UE based ANR is activated. for inter-frequency LTE neighbor cells: the eNB supports learning of neighbor cells via ANR in the same way as available in RL40/RL25 (inter-frequency neighbor cells might be automatically learned per eNB using LTE492: ANR) Note: Automatic cell-specific inter-frequency neighbor learning via ANR is not possible as long as LTE556: ANR Intra-LTE, Inter-frequency - UE Based is not supported).

The eNB supports the cell-specific use of NRs provided via O&M. Therefore, the operator might resolve ambiguities on eNB level for inter-frequency neighbor cells via configuration of the correct NR. If several neighbor cells with identical PCI/EARFCN are available, then the operator might configure per eNB cell the correct NR (by providing the correct LNREL). HO is then triggered to the correct neighbor cell configured via LNREL. Support of cell-specific PCI and Neighbor Relation handling The eNB supports cell-specific PCI and NR handling, in the following ways:

DN09185967 Issue: 01M

© 2016 Nokia

229


•

• • •

•

The eNB establishes and handles the NRs associated to a certain PCI and frequency per eNB cell. Uniqueness of PCI/EARFCN is required for the NRs associated to the eNB cell. NRs are validated by the eNB. To perform this validation the eNB retrieves CGI measurements from suitable UEs. The eNB detects and stores NRs per eNB cell. HO procedures are triggered using the stored cell-specific NRs. The cell-specific NRs might be provided via O&M or learned automatically via ANR features (using mechanisms of the LTE492: ANR and the LTE782: ANR Fully UE Based features). For intra-frequency neighbor cells: – –

•


the eNB automatically determines the correct NRs even if there are several neighbor cells in eNB service area with the same PCI/Freq the eNB supports UE-based ANR, see the LTE782: ANR Fully UE Based feature

For inter-frequency neighbor cells: – – – –

the eNB automatically determines the correct NRs, but only if PCI/Freq of all neighbor cells in the eNB service area are unique eNB supports only OAM-based ANR To remove the restriction to have unique PCI/Freq in the eNB area, support of the LTE556: ANR Intra-LTE, Inter-frequency - UE Based feature is needed. If for a certain PCI/Freq several inter-frequency neighbor cells are visible for the eNB, the correct NRs have to be provided via O&M.

The cell-specific PCI handling is backward compatible in the sense that with respect to target cell selection the legacy behavior is supported even if UE-based ANR features are deactivated. A neighbor cell is allowed as HO target for a dedicated source cell if: • •

an RNL-available NR from the source cell to the target cell exists or exactly one RNL-available neighbor cell configuration for respective PCI-EARFCN combination exists

Neighbor Cell information The eNB supports: • • • • •

12 LNCEL per LNBTS (with FSM3 HW and FZM), 6 LNCEL per LNBTS (with FSM2 HW 64 LNADJ (with max 64 X2 connections) 389 LNREL total per cell (64 LNADJ * 6 LNADJL on average + 5 potential neighbors from cells of own eNB = 389) each neighbor eNB can have up to 24 cells (LNADJL) 1536 LNADJL per eNB (64 LNADJ * 24 LNADJL on average): value to be confirmed by testing

Management of neighbor eNB and LTE neighbor cells Neighbor eNB and neighbor LTE cell information, autonomously created by eNB ANR features or by the operator via plan file, are persistently stored in instances of the dedicated MOCs LNADJ, respectively LNADJL. Global eNB ID information in LNADJL is

230

© 2016 Nokia

DN09185967 Issue: 01M



defined as "value set by the system". Nevertheless, the eNB allows that Global eNB ID information is included into LNADJL object in downloaded plan file. In fact, NetAct Configurator copies the Global eNB ID from LNADJ to related LNADJL objects. When plan file is activated, eNB makes a validation check between Global eNB ID in LNADJL and related LNADJ object. When Global evolved node B (eNB) ID in LNADJL differs from Global eNB ID in related LNADJ or when Global eNB ID in LNADJL is empty, then eNB copies the Global eNB ID from related LNADJ to LNADJL object. Finally, the eNB informs the NetAct/BTS site manager (BTSSM) about LNADJL settings via configuration change notification (CCN). When neighbor LTE cell information is created by eNB ANR features and stored in instance of LNADJL, the eNB copies Global eNB ID from related LNADJ to LNADJL object and informs the NetAct/BTSSM about LNADJL settings via CCN. Improving eNB plan activation The following mechanisms are implemented to handle collisions by eNB during data plan activation: 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 as different LNADJ object stored in the eNB. The eNB rejects LNADJ object creation/modification/deletion that has the same global eNB ID IP as different LNADJ object stored in the eNB. The eNB rejects LNADJ object creation/modification/deletion that has the same 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 stored in the eNB.

• • • • •

g

6.8.1.4

Note: Other objects for which collision was not detected shall be activated. For all rejected objects from delta plan file the eNB provides warning report to the NetAct/BTSM. The NetAct/BTSSM provides the feedback about the warnings for the user.

System impact Interdependencies between features •

•

LTE782: ANR Fully UE Based Verification of an intra-frequency LTE Neighbor Relation (NR) via CGI measurement requires that LTE782: ANR Fully UE Based is activated. LTE1442: Open Access Home eNode B Mobility PCIs reserved for use by home eNode B are excluded from neighbor cell resolution via ANR.

Affected features •

DN09185967 Issue: 01M

LTE492: ANR The OAM-based ANR mechanism defined by the LTE492: ANR feature is based on the assumption that eNB-specific NR/PCI handling can be applied (that is, per LTE carrier one eNB-specific PCI-to-IP mapping table is provided to the eNB). Since in long term it is expected that the UE-based ANR mechanism is the solution preferred by the customers, for effort reduction reasons the LTE492: ANR mechanism is not

© 2016 Nokia

231


•

•


enhanced to support cell-specific NR/PCI handling. Therefore, also with LTE1383: Cell-specific Neighbor Relation/PCI Handling in place, the LTE492: ANR feature must be activated only if eNB-specific NR/PCI handling can be applied. LTE782: ANR Fully UE-based The mechanisms introduced with the ANR Fully UE-based feature are enhanced as described for LTE1383: Cell-specific Neighbor Relation/PCI Handling (for example, cell specific NR/PCI handling, NR management). LTE468: PCI Management The PCI Management feature makes use of the PCI collision check performed by the eNB. With introduction of the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature, PCI collisions on the eNB level are no longer informed to NetAct. The activities of LTE468: PCI Management are adapted to take into account that PCI collisions might be informed to the NetAct only if they are detected on cell level.

Impact on interfaces The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature impacts interfaces as follows: The maximum number of X2-links supported by eNB is increased from 32 to 64. Impact on network and network element management tools The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature impacts network management and network element management tools as follows: NetAct Optimizer/cSON is enhanced to provide PCI allocations which are collision- and confusion-free in cell-scope. Impact on system performance and capacity The LTE1383: Cell-specific Neighbor Relation/PCI Handling feature has no impact on system performance or capacity.

6.8.1.5

LTE1383: Cell-specific Neighbor Relation / PCI Handling management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 120: New alarms lists alarms introduced with the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. Table 120

New alarms

Alarm ID 7655

Alarm name CELL NOTIFICATION

Measurements and counters There are no measurements or counters related to the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. Key performance indicators

232

© 2016 Nokia

DN09185967 Issue: 01M



There are no key performance indicators related to the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. Parameters Table 121: New parameters lists parameters introduced with the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. Table 121

New parameters

Full name

Abbreviated name

Managed object

Neighbor relation status

nrStatus

LNREL

ANR robustness level

anrRobLevel

ANR

Neighbor relation limit intra frequency

nrLimitIntraFreq

ANRPRL

Neighbor relation limit inter-frequency

nrLimitInterFreq

ANRPRL

Target carrier frequency

targetCarrierFreq

ANRPRL

ANR quality threshold for neighbor cells

anrThresRSRQNbCell

ANRPRL

ANR power level threshold for neighbor cells

anrThresRSRPNbCell

ANRPRL

ANR profile for LTE identifier

anrPrLId

ANRPRL

Activate also for UE-based ANR

actAlsoForUeBasedANR

ANRPRL

The Automatic Neighbor Relationship Profile LTE (ANRPRL), a new managed object class (MOC), defines carrier frequency specific settings for automatic detection of LTE intra-frequency and inter-frequency neighbor cells. Up to 32 ANRPRL instances might exist per eNB, where they are persistently stored. The instance with ID 0 (default profile) is mandatory independent from the activation of any ANR feature. The anrThresRSRPNbCell parameter replaces the anrThresNbCell parameter. The anrThresRSRQNbCell parameter replaces the anrLTEIntraNbCellRSRQThres parameter.

g

Note: The ANR control parameters are newly modeled, as defined in the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. Table 122: Modified parameters lists parameters modified by the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature.

DN09185967 Issue: 01M

© 2016 Nokia

233


Table 122


Modified parameters

Full name

Abbreviated name

Managed object

Identity of neighbor eNB in ECGI

ecgiAdjEnbId

LNADJL

Primary PLMN identity of neighbor LTE cell in ECGI

ecgiPlmnId

LNADJL

MCC in broadcast PLMN identity

mcc

LNADJL

MNC of primary PLMN identity of neighbour ENB in ECGI

mnc

LNADJL

MNC length of primary PLMN ID of neighbour ENB in ECGI

mncLength

LNADJL

Table 123: Related existing parameters lists existing parameters related to the LTE1383: Cell-specific Neighbor Relation/PCI Handling feature. Table 123


Full name

Abbreviated name

Local cell resource ID of related neighbor cell

6.8.1.6

ecgiLcrId

Managed object LNADJL


Sales information

BSW/ASW



BSW

-

-

6.9 LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS 6.9.1 Description of LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS Introduction to the feature

234

© 2016 Nokia

DN09185967 Issue: 01M



The LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS feature implements two functional enhancements for iOMS management. The first function is the remote software management for iOMS. This function remotely handles software incremental deliveries for minor software upgrade or software corrections, with NetAct management tool/application. The second function is the remote data backup and restore solution for iOMS. This function remotely triggers creation and upload of iOMS backup files to NetAct. Likewise, it remotely triggers download and activation of the iOMS backup file from NetAct.

6.9.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits the operator as follows: 1. OPEX-savings by introducing remote software management for iOMS The software management for iOMS can be done with the same tool for other network elements. The software management process does not require manual element-specific commanding by CLI. Many instances of iOMS can be handled at the same time. iOMS software management supports incremental deliveries from minor software updates to software corrections. 2. OPEX-savings by introducing solution for iOMS remote data management Backup files can be created in iOMS with the desired content. It can be uploaded and stored remotely at NetAct repository during the iOMS upgrade process as a prestep. Thus, regular backup process can utilize this support. Likewise, backup files can be restored from NetAct repository to iOMS.

6.9.1.2

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


System release



RL50

-

-

OMS

iOMS5.0

UE

NetAct

MME

SAE GW

-

OSS5.4 CD3

-

-

Hardware requirements Because of the big size of OMS backup files, additional storage may be needed. The size of the additional storage depends on the number of OMSs in the network, the frequency of the backups, and the type of backups you perform.

DN09185967 Issue: 01M

© 2016 Nokia

235



Contact NetAct technical support to increase the size of the backup Storage Area Network (SAN). If you use custom NetAct backup solution, see Taking backups of Network Elements (DN00301956) in NetAct documentation for guidance on how to incorporate your backup storage with the NetAct SWM.

6.9.1.3

Functional description The LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS feature implements support of remote software management and support of remote data backup and restore for iOMS.

6.9.1.3.1

Support of remote software management for iOMS The remote software management for iOMS function includes minor software upgrade, support for software corrections and software rollback. Minor software upgrade Minor software upgrades are typically fault corrections and enhancements. The minor software upgrade approach is sufficient only when the new software in all susbsystems is compatible with the previously installed one. Activation of the software set requires iOMS restart. Status of the activated software set is then changed from passive to active. It is possible for an iOMS to have many passive software sets, but it can only have one active software set. Updates can only be remotely processed when the update is backward compatible. Otherwise, the major software upgrade method is required. Major software upgrade Major software upgrade is not yet supported. Supported NetAct operations The following NetAct operations are supported: 1. Download and installation Operator selects one or several iOMSes where the software will be downloaded to. The software is copied to iOMS from NetAct software archive. NetAct is informed when the software download is completed. iOMS installs the downloaded software build and creates a new software set. 2. Activation After receiving the software activation request, iOMS prepares the activation process including all the relevant steps and sends the progress indication notification to NetAct after every intermediate step in activation. 3. Software version monitoring NetAct requests information about the current software installed on iOMS. iOMS provides this information using the currentBD XML file. Software rollback support iOMS software rollback is supported by activating the previous software set. iOMS software management tools do not provide any explicit support for rollback for minor software upgrade.

236

© 2016 Nokia

DN09185967 Issue: 01M


6.9.1.3.2


Support of remote data backup and restore for iOMS The remote data backup and restore for iOMS function includes remote iOMS backup and remote iOMS restore. Remote iOMS backup Remote iOMS backup includes creation of a regular iOMS backup. This also serves as a pre-step during and after the iOMS upgrade process. It may be triggered manually upon NetAct user request or at a scheduled period using the NetAct backup scheduler request. During backup operation, iOMS remains active in the radio network. Backup procedure does not stop the iOMS system. Any type of backup does not deactivate the iOMS system. The prepared backup data is compressed during backup operation into one file. The backup file name should include the iOMS software version as reference when checking software version consistency if partial and custom restore is requested. The backup file content may be full, partial, or custom. Backup files contain system image (SI) including variable data (VD) and configuration files (CF), databases (DB), LDAP directory (LD), and system restoration tools (RT). For full backup (BF) and partial backup (BP), all of these items are combined into one backup file. The “home directory” (HD) contents are not included. However, for custom backup (BC), one of more selected items are combined into one backup file. Aside from the items already mentioned, BC also includes the HD contents. The name of the backup file has the following format:

____. where:

OMS_id refers to the unique iOMS identifier in customer radio network; OMSProduct refers to the product type; backupType refers to the type of backup (full, partial, or custom); backupPart refers to the detailed backup content; SWRelease refers to the active software set name; date&time refers to the date and time of backup creation in the format yyyymmdd_hhmmss; and file compression extension refers to the default file extension of the file compressor. If backup type is custom, the parameters of backupPart include:

DB_[database name] refers to the name of the included database; LD, if the LDAP directory is included; SI, if the entire system image is included; VI, if the configuration files and variable data on the system image are included; and RT, if the system restoration tools are included.

DN09185967 Issue: 01M

© 2016 Nokia

237



iOMS informs NetAct of the final status of remote backup operation. If backup operation is completed, the iOMS notifies the NetAct system. If backup operation fails, the iOMS notifies the NetAct system with the proper error message. Remote iOMS restore Remote iOMS restore includes restoration of a previous version of a software on iOMS. The NetAct operator selects iOMS item(s)/data area(s), backup archive, and type of restore. The remote restore is initialized by NetAct. The NWI3 request is sent to iOMS. It might be triggered upon NetAct user request. The iOMS restores items from backup file requested by the user. iOMS restore may be partial, or custom. Full restore is not supported. During custom or partial restore operation, iOMS is out of service. iOMS disables all Recovery Groups, except some crucial ones, during restore. After restore, iOMS unlocks and makes all Recovery Groups operational. iOMS checks if backup file sent from NetAct contains the software version compatible with the current running software set. If automatic activation is FALSE, iOMS forces the download operation. If the downloaded file already exists locally in the iOMS hard disk drive, the existing file is overwritten by the downloaded one. After receiving the request to download a backup, the iOMS downloads the compressed backup file from the backup repository located in NetAct. The restore operation is completed when the iOMS system data is activated (if automatic activation is TRUE) or when the restored file is properly transferred to iOMS (if automatic activation is FALSE). If error occurs during the restore operation, iOMS sends an error message to NetAct.

6.9.1.4

System impact Interdependencies between features There are no interdependencies between this and any other feature. Impact on interfaces The remote software management for iOMS function uses the existing NWI3 interfaces for manually or automatically downloading and installing the software build (incremental delivery) to iOMS. It is also used to trigger upload of iOMS software configuration data to NetAct. iOMS sends software change notification automatically after software activation. NetAct triggers software configuration upload to update the iOMS software configuration data in NetAct software registry. The remote data backup and restore solution for iOMS function is controlled by NetAct and requires iOMS/NetAct interaction on NWI3 level to prompt backup creation and download. Impact on network and network element management tools NetAct supports remote backup and restore as well as remote iOMS software management function. Impact on system performance and capacity The system backup loads the NE’s CPU. To avoid overloading the NE, periodic backups have to be done whenever low system load is expected; for example, at night time. The NE rejects the new remote backup order if the NE is already running in overload. If a backup is started and the system runs into overload, the running backup will not be interrupted.

238

© 2016 Nokia

DN09185967 Issue: 01M



In addition to CPU overload, disk space needs to be checked. Disk storage for backup files needs to be provided for iOMS and backup repository. A minimum of 10GB per iOMS needs to be provided to store backups.

6.9.1.5

LTE1405: Remote SW-Management and Data Backup/Restore Support for iOMS management data 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.

6.9.1.6


Sales information

BSW/ASW



BSW

-

-

6.10 LTE1687: Basic Layer3 Data Analyzer (L3DA) 6.10.1 Description of LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE Introduction to the feature This feature introduces the Layer 3 Data Analyzer (L3DA), which is a tool for analyzing Flexi Multiradio BTS trace data. The tool is also used in GSM and WCDMA.

6.10.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits This feature benefits the operator as follows: •

DN09185967 Issue: 01M

The LTE L3DA allows the operator to visualize and analyze the cell trace data collected in the L3 Data Collector (L3DC).

© 2016 Nokia

239


6.10.1.2


Requirements Software requirements Software requirements lists the software required for this feature.

System release



RL50

-

-

Table 127

OMS

-


UE

NetAct

MME

SAE GW

-

-

-

-

Hardware requirements The L3DC is required as the L3DA is integrated on the same platform. Nevertheless, it is possible to open the log files offline using another client machine.

6.10.1.3

Functional description With this feature, the multiradio-wide trace analysis platform is introduced for LTE. The L3DA allows the operator to analyze the Flexi Multiradio BTS trace data. The L3DA cooperates with L3DC and it is integrated with the L3DC hardware solution. There is no need for additional hardware. In RL50, the L3DA can access data from one L3DC. The support for several L3DCs is planned for further releases. Figure 35

Layer 3 Data Analyzer implementation Celltrace interface

FlexiMultiradioBTS

Security Gateway (optional)

L3DataCollector andAnalyser

L3Data AnalyserClient (graphicalinterface fordatavisualization)

In RL50, the following functionalities are offered: • • • • • •

240

analysis of the cell trace data including RRC, S1AP, and X2AP messages intuitive graphical interface with easy to read data format (including message names and ASN-decoded data) one call scenario in one row time-based retrieval of the trace information work in offline mode (reading data from files/logs stored in the L3DC) saving signaling scenarios to different formats

© 2016 Nokia

DN09185967 Issue: 01M



The operator can access all trace sessions stored on the server. One L3DC can collect data from up to 200 eNBs (The disk space use is configurable). The L3DA can open several cell trace session at the same time. The available sessions can be filtered on time or cell basis.

6.10.1.4

System impact Interdependencies between features The L3 Data Collector was introduced with the LTE1340: Trace-based Real Time Monitoring feature. The cell trace functionality was introduced with the LTE433: Cell trace 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.

6.10.1.5

LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE 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.

6.10.1.6


Sales information

BSW/ASW



ASW

-

-

DN09185967 Issue: 01M

© 2016 Nokia

241

Descriptions of BTS site solution features


7 Descriptions of BTS site solution features 7.1 LTE72: 4-way RX diversity 7.1.1 Description of LTE72: 4-way RX diversity Introduction to the feature This feature introduces 4-branch diversity reception per sector, with maximum ratio baseband combining of four uplink signals.

7.1.1.1

Benefits The LTE72: 4-way RX diversity is transparent to used antenna structures. It can be used with one physical 4 port antenna or two cross polarized antennas. This feature provides the following benefits: reduced site number for building the coverage. high UL data throughput less BTS sites for coverage

• • •

7.1.1.2

Requirements Software requirements

System release



RL50

-

LBTS5.0

Table 129

OMS

-


UE

NetAct

MME

SAE GW

-

OSS5.5

-

-

Hardware requirements This feature requires LTE947: FSMF Flexi Multiradio 10 System Module. Two or more cells with 15 and 20 MHz bandwidth requires FBBA and 6 Gbps OBSAI RP3 interface.

7.1.1.3

Functional description Functional overview Flexi BTS feederless site with the LTE72: 4-way RX diversity provides an optimal solution to reduce site costs. Antenna feeders can be replaced with optical connection providing no feeder loss and no need for MHA.

242

© 2016 Nokia

DN09185967 Issue: 01M



The following configurations are supported with 3-sector RF Modules: • • • •

1+1 and 1+1+1 2TX MIMO/ 4RX MRC with two RF Modules 1-omni 2TX MIMO/ 4RX MRC with one RF Module 1+1 2TX MIMO/ 4RX MRC with two RF Modules 1+1+1 2TX MIMO/ 4RX MRC with three RF Modules

Figure 36

1-sector configuration with one RF Module

1-sectorconfiguration RFModule Sector1

RX3for4-waydiversity TX1/RX1 NokiaSiemensNetworks

TX2/RX2 for2-waydiversity

RX4for4-waydiversity

Figure 37

3-sector configuration with two RF Modules

3-sectorconfigurationwithtwoRFModules Sector3

Sector2

Sector1

RX3for4-waydiversity TX1/RX1 NokiaSiemensNetworks

RX4for4-waydiversity TX2/RX2 for2-waydiversity NokiaSiemensNetworks

7.1.1.4

System impact Interdependencies between features

DN09185967 Issue: 01M

© 2016 Nokia

243



The following features can not be enabled in combination with this feature: • • •

7.1.1.5

LTE48: Support of High Speed Users LTE447: SW support for RF sharing GSM-LTE RAN2126/LTE435: RF Sharing WCDMA-LTE

LTE72: 4-way RX diversity 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. Table 130

New parameters

Full name

Abbreviated name

Resource list

7.1.1.6

resourceList



Sales information

BSW/ASW



ASW

SW Asset Monitoring

-

7.1.2 Activating and deactivating LTE72: 4-way diversity Purpose Follow this procedures to activate and deactivate the LTE72: 4-way diversity feature.

Activating LTE72: 4-way diversity using BTS Site Manager Before you start The evolved NodeB must already be commissioned. The BTS Site Manager (BTSSM) can be connected to the eNB either locally, or from a remote location.

244

© 2016 Nokia

DN09185967 Issue: 01M


g


Note: Before you start the activation procedure make sure that the following preconditions are fulfilled: 2RX antennas are configured to all cells in eNB eNB is in operational state

• •

Steps

1

Start the BTSSM application and establish the connection to the eNB. For details, refer to BTS Site Manager Online Help.

2

Upload the configuration plan file from the eNB. When the BTSSM is connected to the eNB, it automatically uploads the current configuration plan file from the eNB. • • •

3

Select View ► Commissioning or click Commissioning on the View bar. The BTS Site checkbox, located in the Target section, is selected by default. This is the recommended setting. Choose the commissioning type. Use the Template, Manual, or Reconfiguration option, depending on the actual state of the eNB.

Set Cell Resources settings. Feature is activated by proper configuration of Cell resources settings. 4 receiving antennas are configured to one cell or all cells of the eNB by defining 4Rx antennas in the LCEL resourceList.

DN09185967 Issue: 01M

© 2016 Nokia

245


Figure 38

4


Cell Resources commissioning page

Set MIMO settings. Select one of the following MIMO settings from the drop-down list: • • • • • •

TXDiv 4-way TXDiv Static Open Loop MIMO Dynamic Open Loop Mimo Closed Loop Mimo Closed Loop MIMO (4x2)

Press Next to continue.

246

© 2016 Nokia

DN09185967 Issue: 01M


5


Send the commissioning plan file to the eNB. Sub-steps a) Go to the Send Parameters page. b) In section Send, choose whether the BTSSM should send to the eNB only the changed parameters: Only changes (may require reset), or a whole set of parameters: All parameters (requires reset).

c) Click the Send Parameters button.

6


b) Note that the eNB may now restart.

Deactivating LTE72: 4-way diversity using BTS Site Manager Before you start The evolved NodeB must already be commissioned. The BTS Site Manager (BTSSM) can be connected to the eNB either locally, or from a remote location.

Steps

1

Start the BTSSM application and establish the connection to the eNB. For details, refer to BTS Site Manager Online Help.

2

Upload the configuration plan file from the eNB. When the BTSSM is connected to the eNB, it automatically uploads the current configuration plan file from the eNB.

DN09185967 Issue: 01M

© 2016 Nokia

247


• • •

3


Select View ► Commissioning or click Commissioning on the View bar. The BTS Site checkbox, located in the Target section, is selected by default. This is the recommended setting. Choose the commissioning type. Use the Template, Manual, or Reconfiguration option depending on the actual state of the eNB.

Modify the eNB Cell Resource settings. Reconfigure receiving antennas.

4

Send the commissioning plan file to the eNB. Sub-steps a) Go to the Send Parameters page. b) In section Send, choose whether the BTSSM should send to the eNB only the changed parameters: Only changes (may require reset), or a whole set of parameters: All parameters (requires reset).

c) Click the Send Parameters button.

5


b) Note that the eNB may now restart.

7.2 LTE88: FXDA Flexi RF Module 3TX 900 7.2.1 Description of LTE88: FXDA Flexi RF Module 3TX 900 Introduction to the feature

248

© 2016 Nokia

DN09185967 Issue: 01M



The FXDA is a Flexi Multiradio RF Module version for 900 MHz. FXDB supports one, two, or three sectors with maximum 3x60 W output power at the BTS antenna connectors. Can be used as powerfull one sector RRH with maximum 60 W + 60 W 2TX MIMO. Size and visual outlook is similar to the existing Flexi RF Modules.

7.2.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits FXDB Flexi 3-sector RF Module 80 W 900 MHz has 35 MHz HW bandwidth support at 3GPP band 8. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector.

7.2.1.2


System release


RL50

LBTS5.0

Table 132

OMS Support not required


UE

NetAct

MME

SAE GW

Support not required





7.2.1.3

Functional description Functional overview FXDA Flexi 3-sector RF Module 60 W 900 MHz has 20 MHz HW bandwidth support at 3GPP band 8. LTE88: FXDA Flexi RF Module 3TX 900 provides the following features: • • • • • •

DN09185967 Issue: 01M

the most cost and size and weight optimized 3-sector BTS site SW configurable radio: the same RF Module for LTE, HSPA+ and WCDMA and GSM/EDGE 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables

© 2016 Nokia

249


• • • • •

7.2.1.4


3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation RF Module can be used as powerfull one sector RRH : 60 + 60 W 2TX MIMO with HW prepared for 4RX

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.2.1.5

LTE88: FXDA Flexi RF Module 3TX 900 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 new or modified parameters related to this feature.

7.2.1.6

Sales information This module has same power and Multicarrier licenses as other earlier modules. It requires Branch license.

250

© 2016 Nokia

DN09185967 Issue: 01M


Table 133


Sales information

BSW/ASW BSW

License control in network element —

License control attributes —

7.3 LTE116: Cell Bandwidth - 3 MHz 7.3.1 Description of LTE116: Cell Bandwidth - 3 MHz Introduction to the feature The LTE116: Cell Bandwidth - 3 MHz feature introduces 3 MHz LTE cell RF bandwidth according to 3GPP specified bit rates and supported UE capability.

7.3.1.1

Benefits Operator benefits The operator can deploy LTE cells with 3 MHz bandwidth.

7.3.1.2


System release



RL50

Not relevant

LBTS5.0

Table 134

OMS

Not relevant


UE

NetAct

MME

SAE GW

3GPP R8 mandatory

Not relevant

Not relevant

Not relevant

Hardware requirements The LTE116: Cell Bandwidth - 3 MHz feature supports the following RF modules: • • • • •

DN09185967 Issue: 01M

Band 2: FXFA Band 3: FHEB, FXEB Band 5: FXCA Band 8: FHDB (with RL60 0.1 SW onwards) Band 8: FXDA, FXDB, FHDA, FHDG (from FDD-LTE 16 onwards)

© 2016 Nokia

251



To check which RF modules are supported in the next releases by the LTE116: Cell Bandwidth - 3 MHz feature, see the Flexi Multiradio BTS LTE Supported Configurations document.

g 7.3.1.3

Note: The FXEB module supports LTE-GSM RF sharing.

Functional description The Flexi Multiradio BTS supports 3 MHz cell bandwidth. The following special settings are applied for 3 MHz cells: • • •

7.3.1.4

Number of PUCCH PRBs: set to 2 Number of OFDM symbols for PDCCH: 2 or 3 SIB size and paging record limitations

System impact Interdependencies between features The following features are not supported for 3 MHz cells: • • • • • • • • • • • • • • • • • • • • • • • • • •

LTE4: RAN Sharing LTE786: Flexible UL Bandwidth LTE10: EPS Bearers for Conversational Voice LTE11: Robust Header Compression LTE872: SRVCC to WCDMA LTE873: SRVCC to GSM LTE495: OTDOA LTE619: Interference aware UL scheduling LTE46: Channel-aware Scheduler (UL) LTE496: Support of QCI 2, 3 and 4 LTE587: Multiple GBR EPS Bearers per UE LTE497: Smart Admission Control LTE534: ARP-based Admission Control for E-RABs LTE572: IMS emergency sessions LTE1387: Intra-eNode B IF Load Balancing LTE1170: Inter eNode B IF Load Balancing LTE907: TTI bundling LTE568: DL adaptive closed loop MIMO (4x2) LTE980: IRC for 4 RX paths LTE72: 4-way RX diversity LTE435: RF sharing WCDMA-LTE LTE736: CS Fallback to UTRAN LTE616: Usage based PDCCH adaptation LTE471 LTE Dual carrier operation with in one RF band LTE1073: Measurement-based Redirect to UTRAN WCDMA interworking: –

252

LTE762: Idle mode mobility from LTE to WCDMA, GSM or other LTE bands

© 2016 Nokia

DN09185967 Issue: 01M


–


LTE562: CSFB to UTRAN or GSM via redirect

CDMA interworking:

•

– – –

LTE870: Idle mode mobility from LTE to CDMA/eHRPD LTE807: Idle mode mobility LTE to CDMA/1xRTT LTE426: System time broadcast for SIB8

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 LTE116: Cell Bandwidth - 3 MHz affects: a UE’s throughput performance, since there is a limited amount of physical resources available. the number of active users per cell and active users per TTI per cell, due to a limitation on the signaling channel capacity.

• •

Compared to wider bandwidth cell performance from previous releases, there is no impact foreseen on the latency experienced by a single UE within a cell. However, as the number of UEs increases, a limited amount of PDCCH resources will impact the latency UEs experience. Latency also increases when data needs to be segmented due to small MCS.

7.3.1.5

LTE116: Cell Bandwidth - 3 MHz 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 new parameters related to this feature. Table Modified parameters lists parameters modified by this feature. Table 135

Modified parameters

Full name

Abbreviated name

Managed object

Downlink Channel Bandwidth

dlChBw

LNCEL


ulChBw

LNCEL

DN09185967 Issue: 01M

© 2016 Nokia

253


Table 135



Full name

Abbreviated name

ACK/NACK offset

g

n1PucchAn

Managed object MPUCCH

Note: If dlChBw parameter is set to 3 MHz, supported PRACH Configuration index values are: • •

PRACH format 0: 3, 4, 5, 6, 7, 8 PRACH format 1: 19, 20, 21, 22, 23, 24

A high number of parameter relationships (consistency checks) is added due to: • • •

disabling of features that are not supported in 3 MHz band. restrictions of the supported features because of the low number of resources available on PDCCH/PDSCH/PUSCH. restrictions of the range and defaults for bandwidth-dependent parameters.

To check which parameters are related to this feature, see FDD-LTE BTS Parameters.

7.3.1.6


Sales information

BSW/ASW



ASW

SW Asset Monitoring

-

7.4 LTE117: Cell Bandwidth - 1.4 MHz 7.4.1 Description of LTE117: Cell Bandwidth - 1.4 MHz Introduction to the feature 1.4 MHz LTE cell RF bandwidth according to 3GPP specified bit rates and supported UE capability. A cell bandwidth of 1.4 MHz provides six PRBs to be used in the cell. Feature LTE117 "Cell Bandwidth - 1.4 MHz" is supported by LTE FDD. Main functionalities the LTE117 offers are as follows: • • • • •

254

L3 Call, without voice support (40 Active UEs per cell and 120 UEs per eNodeB with 3 cells) Intra-LTE handover Support for Commercial Mobile Alert Service (CMAS) Earthquake and Tsunami Warning system (ETWS) Support for non-adaptive HARQ re-transmissions

© 2016 Nokia

DN09185967 Issue: 01M


Support for Distributed Sites

•

7.4.1.1


Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The operator is able to deploy LTE cells with 1.4 MHz bandwidth. The use of the narrow bandwidth options of LTE allows the operator greater flexibility to re-use existing bands, or co-deploys LTE with existing technologies where the operator has limited spectrum available for upgrading to LTE. By using the 1.4 MHz cell bandwidth feature, the operator is allowed to configure all cells of an eNB to operate using the same narrow bandwidth. Because of the nature of narrow bandwidth cells, there are limitations to the number of UEs which can be supported, and the cell throughput which can be achieved. The LTE117 "Cell Bandwidth 1.4 MHz" feature is targeted for coverage increase, allowing operator to provide LTE coverage on wider geographical area

7.4.1.2


System release



RL50

Not relevant

LBTS5.0

Table 137

OMS

Not relevant


UE

NetAct

MME

SAE GW

3GPP R8 UE capabilities

Not relevant

Not relevant

Not relevant

Hardware requirements This feature requires the following hardware: • •

Band 2: FXFA Band 5: FXCA

This feature supports the following RF units: • • •

DN09185967 Issue: 01M

Band 2: FXFB, FXFC, FHFA Band 3: FXEA, FXEB, FHEA, FHEB Band 5: FXCB, FHCA

© 2016 Nokia

255


•

7.4.1.3


Band 8: FXDA, FXDB, FHDA, FHDB

Functional description The Flexi Multiradio BTS supports a cell bandwidth of 1.4 MHz. The following special settings are applied for 1.4 Mhz cells: • • • • •

Number of PDCCH OFDM symbols: set to 4. Number of PUCCH PRBs: set to 2. Time Domain Scheduling (TDS) creates a list of several UEs per TTI along with time domain metrics; Frequency Domain Scheduling (FDS) selects one UE from the list. Non adaptive HARQ retransmissions are applied for the uplink. SIB size limitations are applied.

In the TTI where PRACH is allocated no PUSCH data or PUCCH signaling are admitted, with the only exception of ACK/NACK on PUCCH.

7.4.1.4

System impact Dependencies on features to support a narrow bandwidth cell LTE117 depends on the basic LTE-Uu features which are implemented in previous releases. In particular, the feature Link Adaptation for PDCCH (LTE749) is required for 1.4 MHz bandwidth. In addition, PDCCH channel power boosting is implemented for 1.4 MHz cell bandwidth. The following MIMO modes are supported by the sub-feature LTE117-A: • • • • •

SingleTx (LTE187) 2-way TXDiv (LTE69) Static Open Loop MIMO (2x2) (LTE70) Dynamic Open Loop MIMO (2x2) (LTE70) Closed Loop MIMO (2x2) (LTE703)

Dependencies on features to support the deployment scenario In order to support the LTE117 deployment scenarios, Intra-frequency handover (LTE53/LTE54) and Inter-frequency handover (LTE55/LTE54) need to be supported. Thus, the following features are required: • • •

LTE53 Intra and inter eNB handover with X2 LTE55 Inter-frequency Handover LTE54 Intra-LTE Handover via S1

The following features are affected: •

•

256

LTE82 High Capacity Flexi System Module FSME Narrow bandwidth 1.4MHz configurations are not supported on release 2 system module. LTE40 Physical & transport channels Existing feature LTE40 need to be modified. The allowable configuration of the physical control channels (e.g. SRI, CQI) shall be different where a narrow cell bandwidth is used.

© 2016 Nokia

DN09185967 Issue: 01M


•

•

•

•

• •

•

•

•

•

•

•

•

•

DN09185967 Issue: 01M


LTE495 OTDOA Observed Time Difference of Arrival (OTDOA) based positioning feature is not supported with 1.4MHz bandwidth due to capacity loss transmission of Positioning Reference Signal (PRS) is causing. LTE49 Paging Modification of existing feature. Restricted RRC PAGING message sizes are required in narrow bandwidth cells. LTE39 System Information Broadcast Modification of existing feature. Restricted SIB message sizes are required in narrow bandwidth cells. LTE10 EPS bearers for conversational voice GBR bearers are not supported in a narrow bandwidth cell. Consistency checks are used to prevent the operator from enabling the feature. Note that incoming handovers, where a non supported bearer combination (for example, a GBR bearer is established) is used, will fail at the handover preparation phase. LTE496 Support of QCI 2, 3 and 4 GBR bearers are not supported in a narrow bandwidth cell. LTE587 Multiple GBR EPS Bearers per UE As GBR bearers are not supported in 1.4MHz bandwidth (LTE10, LTE496), neither LTE587 is supported. LTE11 Robust header compression Robust Header Compression (ROHC) is used for voice service. As voice service is not supported, neither ROHC is supported. LTE767 Support of aperiodic CQI reports Feature cannot be used. Aperiodic CQI reports cannot be used in a 1.4MHz bandwidth cell, as defined by 3GPP. LTE749 Link adaptation for PDCCH Modification of existing feature is required. For a cell bandwidth of 1.4MHz, the algorithm for assigning CCEs to the uplink and downlink scheduler, as well as the method of combining the uplink and downlink scheduled UEs list is modified. LTE430 DL power boosting for control channels Based on simulations, power boosting of PDCCH, and perhaps even PCFICH, could be useful. The LTE430 does not offer this functionality, and for that a new functionality need to be specified for LTE117. LTE616 Usage based PDCCH adaptation Four OFDMA symbols are always used for PDCCH when 1.4MHz bandwidth is configured. LTE45 Fair scheduler (UL/DL) Modification of existing feature is required. For the cell bandwidth of 1.4MHz, a simplified frequency domain scheduling is used, since only one UE is scheduled per TTI. LTE46 Channel-aware Scheduler (UL) Channel Aware Scheduler does not provide any gain, as UEs are always allocated more or less all available PRBs. In addition, resources allocated to required Sounding Reference Signal (SRS) transmission would be away from data transmission, reducing uplink throughput. LTE619 Interference aware UL scheduling Interference Aware Uplink Scheduling does not provide any gain in 1.4MHz bandwidth, as only 4 PRBs available for data transmission. For that the feature is not supported.

© 2016 Nokia

257


•

•

•

•

• • • • • •

• • •

g


LTE13 Rate capping Rate capping can be used to distinguish gold, silver and bronze users. In order to get the feature work efficiently with 1.4MHz bandwidth, implemented algorithm would need to be modified.That rate capping is working efficiently; sufficient data volume and online duration is required. Rate capping is not supported with LTE117. LTE497 Smart Admission Control Smart Admission Control is done for GBR bearers, which are not supported in 1.4 MHz bandwidth. For this LTE497 is not supported. LTE534 ARP-based Admission Control for E-RABs ARP-based Admission Control is use with the features LTE496 and LTE497 (see above). As those features are not supported, neither LTE534 is supported. LTE762 Idle mode mobility from LTE to WCDMA, GSM or other LTE bands Modification of existing feature is required. Restricted SIB message sizes are required in narrow bandwidth cells. LTE807 Idle mode mobility LTE to CDMA/1xRTT Mobility to cdma2000 network is not supported. LTE870 Idle mode mobility from LTE to CDMA/eHRPD Mobility to cdma2000 network is not supported. LTE426 System time broadcast for SIB8 Mobility to cdma2000 network is not supported. LTE872 SRVCC to WCDMA SRVCC is not supported, as voice is not supported. LTE873 SRVCC to GSM SRVCC is not supported, as voice is not supported. LTE1387 Intra-eNode B IF Load Balancing All cells of the eNB are configured to the same 1.4MHz bandwidth and on the same frequency layer. For that, supporting Intra-eNB Inter-frequency load balancing is not needed. LTE442 Network Assisted Cell Change to GSM Mobility to GSM network is not supported. LTE4 Multi-Operator Core Network (MOCN) MOCN is not supported with 1.4MHz bandwidth. LTE907 TTI bundling TTI bundling is not supported as voice is not supported with 1.4MHz cell. Note: LTE117 cannot be used with LTE-GSM or LTE-WCDMA RF sharing.

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 impacts system performance and capacity as follows: • •

258

affects a UE’s throughput performance since there is a limited amount of physical resources available. affects the number of active users per cell and active users per TTI per cell, due to a limitation on the signaling channel capacity.

© 2016 Nokia

DN09185967 Issue: 01M



There is no impact foreseen on the latency experienced for a single UE within a cell compared to previous releases performance of wider bandwidth cells. However, as the number of UEs increases, for example a limited amount of PDCCH resources will impact latency UEs experiences. Latency increases also in cases when data needs to be segmented due to small MCS. Due to data segmentation, Ping delay requirements are only valid for bandwidths equal to or wider than 5 Mhz.

7.4.1.5

LTE117: Cell Bandwidth - 1.4 MHz 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 new parameters related to this feature. Table Modified parameters lists parameters modified by this feature. Table 138

Modified parameters

Full name

g

Abbreviated name

Managed object

Downlink Channel Bandwidth

dlChBw

LNCEL


ulChBw

LNCEL

Maximum number of OFDM symbols for PDCCH

maxNrSymPdcch

LNCEL

Note: If dlChBw parameter is set to 1.4 MHz, supported PRACH Configuration index values are: • •

PRACH format 0: 3, 4, 5 PRACH format 1: 19, 20, 21

High number of parameter relationships (consistency checks) is added due to: • • •

disabling of features that are not supported in 1.4 MHz band, restrictions in the supported features due to the low number of resources available on PDCCH/PDSCH/PUSCH, restrictions in the range and defaults for bandwidth dependent parameters.

To check which parameters are related to this feature, see FDD-LTE BTS Parameters.

DN09185967 Issue: 01M

© 2016 Nokia

259


7.4.1.6



Sales information

BSW/ASW



BSW

SW Asset Monitoring

-

7.5 RAN2126/LTE435: RF Sharing WCDMA-LTE 7.5.1 Description of RAN2126/LTE435: RF Sharing WCDMA - LTE Introduction to the feature With this feature WCDMA and LTE systems can share the same Flexi Multiradio BTS RF Modules operating in concurrent mode in 900 MHz or 2100 MHz frequency bands. Flexi Multiradio BTS RF Module is transmitting both WCDMA RF carrier(s) and LTE RF carrier signals at the same time in the 3GPP frequency band.

7.5.1.1

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

• • •

•

7.5.1.2

Easy and future proof BTS site evolution by using the same Flexi Multiradio RF Modules by SW mode either in WCDMA only mode, or in concurrent WCDMA/LTE mode or in LTE only mode. Operator can run both WCDMA and LTE concurrently by the same Flexi Multiradio RF Module(s). Flexi Multiradio BTS brings general OPEX savings on spare part stock, logistics and maintenance. Multiradio BTS concept simplifies the antenna system complexity dramatically. No additional external combiners are required and multiple RA technologies can share the same feeders and antennas in the same band. This feature enables the operator to allocate and share BTS RF resources between WCDMA and LTE in a flexible way.


RAS

Flexi Direct

IPA-RNC

mcRNC

OMS/iOMS BTS Flexi

RU40,

RU40

RN7.0

mcRNC3.0

RNO 2.0 1)

WN8.0,

IHO 5.0 2)

LBTS5.0

RL50

260

© 2016 Nokia

Flexi Lite

BTS Flexi 10

Support not WN8.0 2.0, required LBTS5.0

DN09185967 Issue: 01M


Table 140



NetAct

MSC

SGSN

MGW

UE

OSS5.5





MME Support not required

SAE GW Support not required

1) for IPA-RNC and mcRNC 2) for Flexi Direct

Hardware requirements For supported RF HW variants, see the Flexi Multiradio BTS RF Sharing Released Configurations document. One of the following System Modules is required for each technology: •

For Flexi Multiradio BTS: Flexi Multimode System Module FSMC, FSMD, or FSME – – –

•

7.5.1.3

RAN2382: FSMC RAN1016/LTE74: FSMD RAN1848/LTE82: FSME

For Flexi Multiradio 10 BTS: RAN2262/LTE947: FSMF

Functional description Functional overview Flexi Multiradio RF Module is operating in concurrent WCDMA and LTE mode on one 3GGP band. When operating in RF sharing mode, a single RF Module is connected to two System Modules simultaneously. One Flexi Multiradio BTS System Module is operating in WCDMA SW mode and the other Flexi Multiradio BTS System Module in LTE SW mode. Both are connected to the one and same Flexi Multiradio RF Module. The maximum supported distance between the System Module and RF Modules for classical RF sharing is 10 km. The RF sharing WCDMA-LTE supports up to 3+3+3 WCDMA and 1+1+1 LTE 2x2 MIMO configurations. Flexi 3-sector RF Module can support three sectors. One, two and three sector concurrent RF configurations are supported. For WCDMA optionally 2x2 MIMO/VAM (Virtual Antenna Mapping) concurrent RF mode configurations are supported. One sector 2x2 MIMO is supported by one Flexi 3-sector RF Module. For two and three sector 2x2 MIMO configurations at least two Flexi 3-sector RF Modules are needed. Configurations including three RF Modules are also supported. For details on the supported configurations, see Flexi Multiradio BTS RF Sharing Released Configurations document. Additional configurations are planned for future releases.

DN09185967 Issue: 01M

© 2016 Nokia

261



Feature activation For activation instruction, see Configuring RF Sharing document.

7.5.1.4

System impacts Interdependencies between features This feature cannot be used simultaneously with LTE614: Distributed Site. Impacts on interfaces The interface between WCDMA and LTE System Modules is needed. It is used to provide synchronization from WCDMA (synchronization master) to LTE (synchronization slave) and Ethernet connection between System Modules. Impacts on network and network element management tools The following SW releases of NetAct and OMS are required: • •

OSS5.3 CD set 3 for NetAct OMS 3.0 for OMS

Impacts on system performance and capacity This feature has no impact on system performance and capacity.

7.5.1.5

RAN2126/LTE435 RF Sharing WCDMA - LTE management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms Table 141: Related Existing alarms lists existing alarms related to this feature. Table 141

Related Existing alarms

Alarm ID 7654

Alarm name CELL 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 Table 142: New parameters lists parameters introduced with this feature.

262

© 2016 Nokia

DN09185967 Issue: 01M


Table 142


New parameters

Full name

7.5.1.6

Abbreviated name

Managed object

Connection list

connectionList

RMOD

Shared RF technologies

sharedRfTechnologies

MRBTS

Rf Sharing Enabled

rfSharingEnabled

BTSSCL


WCDMA Sales information

BSW/ASW ASW

Table 144

SW component RAN

License control in network element -

LTE Sales information

BSW/ASW



ASW

Pool license

-

7.5 Variable Definitions

7.6 LTE471: LTE Dual carrier operation within one RF band 7.6.1 Description of LTE471: LTE Dual carrier operation within one RF band Introduction to the feature The feature allows support for two separate LTE carriers by one pipe/antenna connector of Flexi RF Module or Remote Radio Head (RRH). Flexible carrier configurations provide maximized usage of the RF band.

7.6.1.1


DN09185967 Issue: 01M

© 2016 Nokia

263



Spectrum of the RF band is used in more efficient way, thus the utilization of the RF band is better. More capacity per BTS as the operator can use two carriers at the same RF band by one Flexi RF Module or RRH.

7.6.1.2


System release RL50

Table 145

Flexi Multiradio BTS LBTS5.0

Flexi Multiradio 10 BTS LBTS5.0

iOMS Support not required


UE

NetAct

MME

SAE GW


OSS5.5 CD1



Hardware requirements Flexi Multiradio 10 System Module required. Not supported with all RF module types..

7.6.1.3

Functional description One Flexi RF Module or RRH supports two LTE cells at one RF band simultaneously per RF sector (TX/RX and RX pipe). The same RF Bandwidth carrier combinations are supported per each RF TX/RX and RX sector/branch: • • • •

Carrier 1 @ 5 MHz + Carrier 2 @ 5 MHz Carrier 1 @ 10 MHz + Carrier 2 @ 10 MHz Carrier 1 @ 15 MHz + Carrier 2 @ 15 MHz (min. RF HW BW 30 MHz) Carrier 1 @ 20 MHz + Carrier 2 @ 20 MHz (min. RF HW BW 40 MHz)

The main supported dual carrier configurations are: • • • • •

2, 2+2, or 2+2+2 1TX 2RX with one RF Module 2+2 or 2+2+2 2TX MIMO 2RX with two RF Modules 2 cells 2TX MIMO 2RX with one RF Module, RRH 2TX, or RRH 4TX (only two antenna feeders used) 2+2 2TX MIMO 2RX with two RF Modules, RRH 2TX, or RRH 4TX (only two antenna feeders used) 2+2+2 2TX MIMO 2RX with three RF Modules, RRH 2TX, or RRH 4TX (only two antenna feeders used)

The other configurations introduced by this feature are: •

264

1+1 2TX MIMO 2RX with one RRH 4TX (four antenna feeders used per RRH)

© 2016 Nokia

DN09185967 Issue: 01M


1+1+1+1 2TX MIMO 2RX with two RRHs 4TX (four feeders used per RRH) 6x1 2TX 2RX with three RRHs 4TX (four feeders used per RRH)

• •

7.6.1.4


System impact Interdependencies between features Feature LTE179: Dual Band with One System Module is required. 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.

7.6.1.5

LTE Dual carrier operation within one RF band 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 Modified Parameters lists parameters modified by this feature. Table 146

Modified Parameters

Full name Resource list

7.6.1.6

Abbreviated name resourceList

Managed object LCELL


Sales information

BSW/ASW



ASW

SW Asset Monitoring

-

DN09185967 Issue: 01M

© 2016 Nokia

265



7.6.2 Activating LTE471: LTE Dual carrier operation within one RF band Purpose Follow this procedure to activate LTE471: LTE Dual carrier operation within one RF band. Before you start The eNB must be already commissioned. The BTS Site Manager (BTSSM) can be connected to the eNB either locally or from a remote place. Procedure 1

Commission the feature a) Start commissioning. For instructions, see Starting manual commissioning in the Commissioning Flexi Multiradio BTS LTE document. b) When two cells are assigned to the same physical antenna, Dual Carrier feature is activated.

g

Note: Note that cell 2 is added and assigned to the same antenna used by cell 1. The power level of both cells must be the same; it must not exceed the maximum power supported by the RF unit. c) Set up the two cells’ bandwidth and carrier spacing based on rules. Bandwidth of the two cells must not exceed the maximum bandwidth supported by the RF HW. For example: The total bandwidth of the two carriers must not exceed the maximum bandwidth supported by the HW. If 20 MHz is the maximum bandwidth of an RF HW, then the valid carrier bandwidth is as follows. Carrier 1 @ 5 MHz + Carrier 2 @ 5 MHz (10 MHz total) Carrier 1 @ 10 MHz + Carrier 2 @ 10 MHz (20 MHz total) If 40 MHz is the maximum bandwidth of an RF HW, then the valid carrier bandwidth is as follows. Carrier 1 @ 5 MHz + Carrier 2 @ 5 MHz (10 MHz total) Carrier 1 @ 10 MHz + Carrier 2 @ 10 MHz (20 MHz total) Carrier 1 @ 15 MHz + Carrier 2 @ 15 MHz (30 MHz total) Carrier 1 @ 20 MHz + Carrier 2 @ 20 MHz (40 MHz total) The carrier spacing must also follow the rule: The minimum Tx carrier spacing for dual carriers is (bw1 + bw2) divided by 2. The maximum Tx carrier spacing for dual carrier is (carrier frequency 2 + carrier 2 BW/2) - (carrier frequency 1 - carrier 1 BW/2) = or < than Max.Total.Bandwidth

7.6.3 Verifying LTE471: LTE Dual carrier operation within one RF band Purpose Follow these steps to verify that this feature has been activated successfully.

266

© 2016 Nokia

DN09185967 Issue: 01M



Procedure 1

Connect LTE Signal Analyzer to BTS antenna configured with dual carriers (F1 and F2).

2

Set LTE Signal Analyzer center frequency to F1. Verify that F1 signal is shown.

3

Set LTE Signal Analyzer center frequency to F2. Verify that F2 signal is shown.

7.6.4 Deactivating LTE471: LTE Dual carrier operation within one RF band Purpose Follow this procedure to deactivate LTE471: LTE Dual carrier operation within one RF band.

Steps

1

Recommission the BTS. To deactivate the Dual Carrier feature, simply commission the eNB so that only one cell is assigned to each antenna (antennas are not shared by more than one cell). The Flag is automatically set to FALSE.

7.7 LTE748: FRHD Flexi RRH 4TX 2600 7.7.1 Description of LTE748: FRHD Flexi RRH 4TX 2600 Introduction to the feature This feature introduces LTE748: FRHD Flexi RRH 4TX 2600 - Flexi Multiradio Remote Radio Head (RRH) with 4TX downlink MIMO and four receiver uplink diversity for global operation at 2600 MHz 3GPP band 7.

7.7.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits One sector Flexi Remote Radio Head supports 4TX MIMO with high output power. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector.

DN09185967 Issue: 01M

© 2016 Nokia

267


7.7.1.2



System release


RL50

LBTS5.0

Table 148



UE

NetAct

MME

SAE GW






7.7.1.3

Functional description Functional overview FRHD supports 3GGP band 7 at 2600 MHz and highest 50 MHz. It operates at DL: 2640-2690 MHz and UL: 2520-2570 MHz. The LTE748: FRHD Flexi RRH 4TX 2600 provides the following features: • • • •

• • • •

7.7.1.4

4x30 W with four power amplifiers (at 45°C) optimized for single sector deployment with 4TX MIMO one LTE cell with 4TX MIMO up to 20 MHz LTE per sector operating ambient temperature range: -35... +55°C (at constant high temperature and high traffic load at 30 W mode Pout might be limited) 4-way Uplink RX Maximum Ratio Combining (MRC) HW support optical chaining supported by HW (two optical connectors with 6 Gbit/s interfaces) external alarms and outputs (as with 2TX RRH) AISG2.0 Antenna tilt support with external connector (RS485)

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

268

© 2016 Nokia

DN09185967 Issue: 01M



New configurations are available.

7.7.1.5

LTE748: FRHD Flexi RRH 4TX 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 parameters related to this feature. Parameters There are no key performance indicators related to this feature.

7.7.1.6

Sales information This module has same power and Multicarrier licenses as other earlier modules. It requires Branch license. Table 149

Sales information

BSW/ASW BSW



7.8 LTE972: Flexi Baseband Module FBBA 7.8.1 Description of LTE972: Flexi Baseband Module FBBA Introduction to the feature The FBBA is a high capacity extension sub-module for the Flexi Multiradio System Module FSMF.

7.8.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The System Module FSMF capacity can be flexibly expanded.

7.8.1.2


DN09185967 Issue: 01M

© 2016 Nokia

269



Table 150: Software requirements lists software required for this feature. Table 150


System release



RL50

-

LBTS5.0

OMS

-

UE

NetAct

MME

SAE GW

-

OSS5.4 CD Set 3

-

-

Hardware requirements This feature requires Flexi Multiradio 10 System Module.

7.8.1.3

Functional description Functional overview The FBBA sub-module is an optional extension to the Flexi Multiradio BTS System Module. One FBBA provides a hardware baseband capacity for up to three 20 MHz LTE cells with 2x2 MIMO. FBBA is 1U high and it is IP65 ingress protected. FBBA operates at the temperature range from -35 to + 55 °C (-31 + 131°F). Figure 39: Isometric view of the FBBA presents the isometric view of the FBBA. Figure 39

Isometric view of the FBBA

Interfaces The FBBA provides the following external interfaces:

270

© 2016 Nokia

DN09185967 Issue: 01M



One -48 VDC input One -48 VDC output One baseband extension interface for interconnecting FBBA and Flexi Multiradio System Module One SRIO (Serial Rapid Input/Output) interface for an external baseband extension, for example additional System Module One optical OBSAI RP3-01 interface with up to 6 Gbit/s towards RF Module or Remote Radio Head

• • • • •

LEDs The FBBA has three tri-color LEDs on the front panel to indicate the operational status of the sub-module and all fault conditions during operation. The LED indications of the sub-module are listed and explained in the Table 151: Extension sub-module LEDs (from left to right). Table 151

Extension sub-module LEDs (from left to right)

LED

Color

SRIO

•

Red: no connection

•

Green: connection OK

•

Yellow: not in use

• •

Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm Red, blinking: Minor alarm

•

Yellow: Stand-by or blocked

•

Yellow, blinking: SW download or configuration ongoing, module non-operational Green: Module operational

Operational status

• •

Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational

RF/EXT

•

Red: no connection

RF link status

•

Green: connection OK

•

Yellow: not in use

DN09185967 Issue: 01M

© 2016 Nokia

271


Figure 40


Capacity extension sub-module LEDs

SRIO

STATUS

RF/EXT

For more information, see: • • •

7.8.1.4

Flexi Multiradio 10 Base Station System Module Description Flexi Multiradio Base Station and Flexi Multiradio 10 Base Station Optional Items Description Cabling Flexi Multiradio 10 Base Station

System impacts Interdependencies between features This feature is related to LTE947: FSMF Flexi Multiradio 10 System Module. Impacts on interfaces This feature expands the Flexi Multiradio 10 Base Station with additional interfaces that allow to create various configurations. For more information, see Creating LTE Configurations. 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.8.1.5

LTE972: Flexi Baseband Module FBBA management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms

272

© 2016 Nokia

DN09185967 Issue: 01M



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.8.1.6


Sales information

BSW/ASW

BSW

SW component

RAN



7.9 LTE985: FRGT Flexi 3-sector RF Module 2100 7.9.1 Description of LTE985: FRGT Flexi 3-sector RF Module 2100 Introduction to the feature FRGT Flexi Multiradio RF Module HW supports WCDMA and LTE in dedicated or concurrent mode. Flexi Multiradio RF Module provides 3x80 W output power at the antenna connector. Maximum capacity of one Flexi Multiradio RF Module for WCDMA 2100 MHz is up to 4 carriers and up to 2x20 MHz LTE carrier.

7.9.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits New high power 3-sector Flexi Multiradio RF Module introduces industry leading RF integration level and smallest power consumption combined with flexible WCDMA-LTE site evolution. Full support for Multi-operator sites with high output power and wide RF bandwidth.

7.9.1.2


DN09185967 Issue: 01M

© 2016 Nokia

273


System release

Flexi

Flexi Lite

Flexi 10

RL50

LBTS5.0

support not needed

LBTS5.0

Table 153

7.9.1.3



OMS

UE

NetAct

MME

SAE GW

-

support not needed

support not needed

support not needed

support not needed

Functional description Functional overview TX supports 35MHz instantaneous bandwidth and RX supports 60MHz instantaneous bandwidth.Power consumption is optimized by new advanced Power Amplifier architecture.In 2100 MHz band one Flexi Multiradio RF Module HW supports the following WCDMA configurations: • •

from 1+1+1 @ 80 W to 4+4+4 @ 20 W

Basic LTE configurations with one RF Module are as follows: • •

1+1+1 @ max. 80 W 1 TX / 2RX 1 omni @ 80+80 W 2TX / 2RX

Basic LTE configuration with two RF Modules is as follows: •

1+1 and 1+1+1 @ max 80 + 80 W 2TX MIMO / 2RX

Other functionalities: • • •

Integrated class II OVP protection level in DC connector RET connector 6 Gbit OBSAI

Optical interface with 6 Gbit/s mode enables 4-RX Div optional configurations with two RF Modules up to 20 MHz bandwidth: • •

7.9.1.4

1+1+1 @ max 80+80 W 2TX MIMO/4RX 15/20 MHz BW 2+2+2 @ max 40+40 W 2TX MIMO/4RX 15/20 MHz BW

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

274

© 2016 Nokia

DN09185967 Issue: 01M



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.1.5

LTE985: FRGT Flexi 3-sector RF Module 2100 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.9.1.6


Sales information

BSW/ASW ASW



7.10 LTE986: FRGS Flexi 3-sector RF Module 2100 7.10.1 Description of LTE986: FRGS Flexi 3-sector RF Module 2100 Introduction to the feature This feature introduces the LTE986: FRGS Flexi 3-sector RF Module 2100. New 3-sector Flexi Multiradio RF Module provides industry leading RF integration level and smallest power consumption combined with flexible WCDMA-LTE site evolution.

7.10.1.1

Benefits End-user benefits This feature does not affect the end-user experience.

DN09185967 Issue: 01M

© 2016 Nokia

275



Operator benefits One sector Flexi Remote RF Head supports 2TX MIMO with high output power. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector.

7.10.1.2


System release


RL50

LBTS5.0

Table 155



UE

NetAct

MME

SAE GW






7.10.1.3

Functional description Functional overview LTE986: FRGS Flexi 3-sector RF Module 2100 supports WCDMA and LTE in dedicated or concurrent mode. FRGS provides 3x80 W output power at the antenna connector. Maximum capacity of one Flexi Multiradio RF Module for WCDMA 2100 MHz is up to 4 carriers and up to 20 MHz LTE carrier. Filter bandwidth is 40MHz, covering UL: 19401980 MHz and DL: 2130-2170 MHz. TX supports 35 MHz instantaneous bandwidth, RX supports 40 MHz instantaneous bandwidth.Basic LTE configurations with one RF Module: • •

1+1+1 @ max. 80 W 1 TX / 2RX 1 omni @ 80+80 W 2TX / 2RX

Basic LTE configuration with two RF Modules: •

1+1 and 1+1+1 @ max 80 + 80 W 2TX MIMO / 2RX

Other functionalities: • • •

7.10.1.4

Integrated class II OVP protection level in DC connector RET connector 6Gbit OBSAI

System impacts Interdependencies between features

276

© 2016 Nokia

DN09185967 Issue: 01M



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.10.1.5

LTE986: FRGS Flexi 3-sector RF Module 2100 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 new or modified parameters related to this feature.

7.10.1.6


Sales information

BSW/ASW BSW



7.11 LTE1066: FRHC Flexi RF Module 6TX 2600 7.11.1 Description of LTE1066: FRHC Flexi RF Module 6TX 2600 Introduction to the feature This feature introduces the LTE1066: FRHC Flexi RF Module 6TX 2600 with six Power Amplifiers (PAs). The FRHC supports one, two, or three sectors at 30 MHz subbandwidth up to 40+40 W 2TX MIMO output power at the BTS antenna connectors. Size

DN09185967 Issue: 01M

© 2016 Nokia

277



and visual outlook is similar to the existing Flexi RF Modules. From HW point of view it can be used as powerful three sector RRH with max 4x40 W with 4TX MIMO and 4RX. 4TX MIMO and 4RX are separate SW features.

7.11.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The LTE1066: FRHC Flexi RF Module 6TX 2600 provides the following features: the most cost and size and weight optimized 3-sector 2TX MIMO BTS site high RF integration level 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables 3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation HW prepared to support one sector 4x40 W 4TX MIMO with 4RX

• • • • • • • • • • •

7.11.1.2


System release


RL50

LBTS5.0

Table 157



UE

NetAct

MME

SAE GW






7.11.1.3

Functional description Functional overview

278

© 2016 Nokia

DN09185967 Issue: 01M



FRHC supports 3GGP band 7 at 2600 MHz and lowest 55 MHz. It operates at DL: 2620 2675 MHz, UL: 2500 - 2555 MHz Basic LTE Configurations: • • • • •

1, 1+1 or 1+1+1 LTE cells @ max 20 MHz LTE bandwidth and 2TX MIMO / 2RX 8, 20 or 40 W 1TX mode per sector (by branch activation SW licenses) 8+8, 20+20 or 40+40 W 2TX mode per sector (by branch activation and MIMO SW licenses) 1, 2 or 3 sectors max 40 + 40 W 2TX MIMO/2RX HW prepared for 1 sector 4x40 W 4TX MIMO/4RX

FRHC can be used in Feederless site (optical and DC cable up to 200 m).

7.11.1.4


7.11.1.5

LTE1066: FRHC Flexi RF Module 6TX 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 new or modified parameters related to this feature.

7.11.1.6

Sales information This module has same power and Multicarrier licenses as other earlier modules. It requires Branch license.

DN09185967 Issue: 01M

© 2016 Nokia

279


Table 158


Sales information

BSW/ASW BSW



7.12 LTE1067: FRMC Flexi RF Module 6TX 800 7.12.1 Description of LTE1067: FRMC Flexi RF Module 6TX 800 Introduction to the feature This feature introduces the LTE1067: FRMC Flexi RF Module 6TX 800 with six Power Amplifiers (PAs). The FRMC supports one, two, or three sectors up to 40+40 W 2TX MIMO output power at the BTS antenna connectors. Size and visual outlook is similar to the existing Flexi RF Modules. The FRMC is tuned for operators having the highest 20 MHz RF band on 800 MHz fulfilling the new regulator requirements in order to minimize the interference with TV broadcasting systems. From HW point of view it can be used as powerful three sector RRH with max 4x40 W with 4TX MIMO and 4RX. 4TX MIMO and 4RX are separate SW features.

7.12.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The LTE1067: FRMC Flexi RF Module 6TX 800 provides the following features: • • • • • • • • • • •

7.12.1.2

the most cost and size and weight optimized 3-sector 2TX MIMO BTS site high RF integration level 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables 3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation HW prepared to support one sector 4x40 W 4TX MIMO with 4RX


280

© 2016 Nokia

DN09185967 Issue: 01M



System release


RL50

LBTS5.0

Table 159



UE

NetAct

MME

SAE GW






7.12.1.3

Functional description Functional overview The FRMC supports 3GGP band 20 at 800 MHz highest 20 MHz band. Basic LTE Configurations: • • • • • •

1, 1+1 or 1+1+1 LTE cells @ max 20 MHz LTE bandwidth and 2TX MIMO / 2RX 20 MHz DL BW; downlink 801-821 MHz and 30MHz UL BW; uplink 832-862 MHz RX filter BW 30 MHz, 832 - 862 MHz 8, 20 or 40 W 1TX mode per sector (by branch activation SW licenses) 8+8, 20+20 or 40+40 W 2TX mode per sector (by branch activation and MIMO SW licenses) HW prepared for 1 sector 4x40 W 4TX MIMO/4RX

One FRMC can be used in Feederless site (optical and DC cable up to 200 m) instead of three RRHs to support 1+1+1 with 2TX MIMO.

7.12.1.4


DN09185967 Issue: 01M

© 2016 Nokia

281


7.12.1.5


LTE1067: FRMC Flexi RF Module 6TX 800 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 new or modified parameters related to this feature.

7.12.1.6


Sales information

BSW/ASW BSW



7.13 LTE1247: Multiradio System Module extended LTE configurations 7.13.1 Description of LTE1247: Multiradio System Module extended LTE configurations Introduction to the feature The feature introduces extended LTE configurations with Flexi Multiradio System Module FSMF with one optional capacity extension sub-module FBBA.

7.13.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The feature allows the operator to create bigger cell configurations and allows for enhanced downlink and uplink performance, for example with LTE980: IRC for 4 RX feature.

282

© 2016 Nokia

DN09185967 Issue: 01M


7.13.1.2



System release RL50

Flexi Multiradio BTS Not relevant

Table 161

Flexi Multiradio 10 BTS LBTS5.0



UE

NetAct

MME

SAE GW





Hardware requirements This feature require the following HW: • •

7.13.1.3

LTE947:Flexi Multimode System Module FSMF LTE1137: FBBA Flexi Baseband Sub-Module

Functional description For details on RL50 configurations, see Flexi Multiradio and Multiradio 10 BTS LTE Supported Configurations. The feature introduces the following configurations: FSMF + one FBBA configurations •

Up to six cells with 15 or 20 MHz cell BW, 2TX MIMO, and 2RX diversity: – –

• • •

6-sector configuration with one RF band (single band configuration) Two 3-sector configurations with two different RF bands (dual band configuration)

Up to six cells with 5 or 10 MHz cell BW, 4x2 MIMO and/or 4RX diversity Up to three cells with 15 or 20 MHz cell BW, 4x2 MIMO and/or 4RX diversity Up to 12 cells with 5 or 10 MHz cell BW, 2TX MIMO and 2RX diversity

FSMF-only configurations • •

7.13.1.4

Up to three cells with one RF band, 5 or 10 MHz cell BW, 4x2 MIMO and/or 4RX diversity (single band configuration) Six cells with two different RF bands and 5 or 10 MHz cell BW, 2TX MIMO and 2RX diversity (dual band configuration)

System impact Interdependencies between features •

DN09185967 Issue: 01M

Feature LTE977: RF chainning need to be activated for using chained Radio Units.

© 2016 Nokia

283


• •


Feature LTE980: IRC for 4 RX paths or LTE72: 4-way RX diversity is needed for 4RX diversity configurations. Feature LTE568: DL adaptive closed loop MIMO (4x2) is needed for 4x2 MIMO configurations.

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.

7.13.1.5

Multiradio System Module extended LTE configurations 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 new or modified parameters related to this feature.

7.13.1.6


Sales information

BSW/ASW



BSW

-

-

7.14 LTE1262: FHEB Flexi RRH 2TX 1800 7.14.1 Descrption of LTE1262: FHEB Flexi RRH 2TX 1800 Introduction to the feature This feature introduces LTE1262: FHEB Flexi RRH 2TX 1800 with 2TX downlink MIMO and 2 RX receiver uplink diversity for world market operation at 3GPP band 3.

284

© 2016 Nokia

DN09185967 Issue: 01M


7.14.1.1


Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits One sector Flexi Remote RF Head supports 2TX MIMO with high output power. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector.

7.14.1.2


System release


RL50

LBTS5.0

Table 163



UE

NetAct

MME

SAE GW






7.14.1.3

Functional description Functional overview The LTE1262: FHEB Flexi RRH 2TX 1800 provides the following features: • • • • • • •

7.14.1.4

1800 MHz 3GPP band 3 supported optimized for single sector deployment with 2TX MIMO 40 MHz TX RF HW bandwidth and 60 MHz RX BW optical chaining supported by HW (two optical connectors) IP65 with -35 to +50°C with convection cooling external alarms and outputs AISG2.0 Antenna tilt support with external connector (RS485)

System impacts Interdependencies between features There are no interdependencies between this and any other feature. Impacts on interfaces

DN09185967 Issue: 01M

© 2016 Nokia

285



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.14.1.5

LTE1262: FHEB Flexi RRH 2TX 1800 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 new or modified parameters related to this feature.

7.14.1.6


Sales information

BSW/ASW BSW



7.15 LTE1329: FRPA Flexi RF Module 6TX 700 7.15.1 Description of LTE1329: FRPA Flexi RF Module 6TX 700 Introduction to the feature This feature introduces The LTE1329: FRPA Flexi Multiradio RF Module 6TX 700 MHz with six Power Amplifiers (PAs). The FRPA supports one, two or three sectors at 35 MHz sub-bandwidth up to 40+40 W 2TX MIMO output power at the BTS antenna connectors. Size and visual outlook is similar to the existing Flexi RF Modules. From HW point of view it can be used as powerful three sector RRH with max 4x40 W with 4TX MIMO and 4RX. 4TX MIMO and 4RX are separate SW features.

286

© 2016 Nokia

DN09185967 Issue: 01M


7.15.1.1


Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The LTE1329: FRPA Flexi RF Module 6TX 700 provides the following features: the most cost and size and weight optimized 3-sector 2TX MIMO BTS site high RF integration level 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables 3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation HW prepared to support one sector 4x40 W 4TX MIMO with 4RX

• • • • • • • • • • •

7.15.1.2


System release


RL50

LBTS5.0

Table 165



UE

NetAct

MME

SAE GW






7.15.1.3

Functional description Functional overview The LTE1329: FRPA Flexi RF Module 6TX 700 supports lowest 35 MHz sub-band of the 3GGP band X at 700 MHz. Basic LTE Configurations:

DN09185967 Issue: 01M

© 2016 Nokia

287


• • • • • • • • •


1, 1+1 or 1+1+1 LTE cells @ max 20 MHz LTE bandwidth and 2TX MIMO / 2RX 2 x 20 MHz + 1 x 10 MHz, 2 x 15 MHz, 3 x 10 MHz cells also to be supported Operator sharing supported target 35 MHz bandwidth; downlink 758-793 MHz RX BW 35 MHz, 703-738 MHz 8, 20 or 40 W 1TX mode per sector (by branch activation SW licenses) 8+8, 20+20 or 40+40 W 2TX mode per sector (by branch activation and MIMO SW licenses) 1, 2 or 3 sectors max 40 + 40 W 2TX MIMO/2RX HW prepared for 1 sector 4x40 W 4TX MIMO/4RX

One FRPA can be used in feederless site (optical and DC cable up to 200 m) instead of three RRHs to support 1+1+1 with 2TX MIMO.

7.15.1.4


7.15.1.5

LTE1329:FRPA Flexi RF Module 6TX 700 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 new or modified parameters related to this feature.

288

© 2016 Nokia

DN09185967 Issue: 01M


7.15.1.6



Sales information

BSW/ASW



BSW

-

-

7.16 LTE1395: FRPB Flexi RF Module 6TX 700 7.16.1 Description of LTE1395: FRPB Flexi RF Module 6TX 700 Introduction to the feature This feature introduces The LTE1395: FRPB Flexi Multiradio RF Module 6TX 700 MHz with six Power Amplifiers (PAs). The FRPB supports one, two, or three sectors at 30 MHz sub-bandwidth up to 40+40 W 2TX MIMO output power at the BTS antenna connectors. Size and visual outlook is similar to the existing Flexi RF Modules. From HW point of view it can be used as powerful three sector RRH with max 4x40 W with 4TX MIMO and 4RX. 4TX MIMO and 4RX are separate SW features.

7.16.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits The LTE1329: FRPB Flexi RF Module 6TX 700 provides the following features: • • • • • • • • • • •

7.16.1.2

the most cost and size and weight optimized 3-sector 2TX MIMO BTS site high RF integration level 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables 3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation HW prepared to support one sector 4x40 W 4TX MIMO with 4RX


DN09185967 Issue: 01M

© 2016 Nokia

289



System release


RL50

LBTS5.0

Table 167



UE

NetAct

MME

SAE GW






7.16.1.3

Functional description Functional overview The LTE1395: FRPB Flexi RF Module 6TX 700 supports lowest 30 MHz sub-band of the 3GGP band 28 at 700 MHz. Basic LTE Configurations: • • • • • • • • •

1, 1+1 or 1+1+1 LTE cells @ max 20 MHz LTE bandwidth and 2TX MIMO / 2RX 2 x 20 MHz + 1 x 10 MHz, 2 x 15 MHz, 3 x 10 MHz cells also to be supported Operator sharing supported TX BW 30 MHz; downlink 773 - 803 MHz RX BW 30 MHz, uplink 718 - 748 MHz 8, 20 or 40 W 1TX mode per sector (by branch activation SW licenses) 8+8, 20+20 or 40+40 W 2TX mode per sector (by branch activation and MIMO SW licenses) 1, 2 or 3 sectors max 40 + 40 W 2TX MIMO/2RX HW prepared for 1 sector 4x40 W 4TX MIMO/4RX

One FRPB can be used in feederless site (optical and DC cable up to 200 m) instead of three RRHs to support 1+1+1 with 2TX MIMO.

7.16.1.4


290

© 2016 Nokia

DN09185967 Issue: 01M


7.16.1.5


LTE1395: FRPB Flexi RF Module 6TX 700 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 new or modified parameters related to this feature.

7.16.1.6


Sales information

BSW/ASW



BSW

-

-

7.17 LTE1422: FXDB Flexi RF Module 3TX 900 7.17.1 Description of LTE1422: FXDB Flexi RF Module 3TX 900 Introduction to the feature The FXDB is a Flexi Multiradio RF Module version for 900 MHz. FXDB supports one, two, or three sectors with maximum 3x80 W output power at the BTS antenna connectors. Can be used as powerfull one sector RRH with maximum 80 W + 80 W 2TX MIMO. Size and visual outlook is similar to the existing Flexi RF Modules.

7.17.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits FXDB Flexi 3-sector RF Module 80 W 900 MHz has 35 MHz HW bandwidth support at 3GPP band 8. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector.

7.17.1.2


DN09185967 Issue: 01M

© 2016 Nokia

291



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

System release


RL50

LBTS5.0

Table 169



UE

NetAct

MME

SAE GW






7.17.1.3

Functional description Functional overview The LTE1422: FXDB Flexi RF Module 3TX 900 provides the following features: • • • • • • • • • • •

7.17.1.4

the most cost and size and weight optimized 3-sector BTS site SW configurable radio: the same RF Module for LTE, HSPA+ and WCDMA and GSM/EDGE 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables 3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation HW prepared to support one sector 4x40 W 4TX MIMO with 4RX

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

292

© 2016 Nokia

DN09185967 Issue: 01M



New configurations are available.

7.17.1.5

LTE1422: FXDB Flexi RF Module 3TX 900 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 new or modified parameters related to this feature.

7.17.1.6


Sales information

BSW/ASW BSW



7.18 LTE1563: FRHF Flexi RF Module 6TX 2600 7.18.1 Description of LTE1563: FRHF Flexi RF Module 6TX 2600 Introduction to the feature This feature introduces the LTE1563: FRHF Flexi RF Module 6TX 2600 MHz with six Power Amplifiers (PAs). The FRHC supports one, two, or three sectors up to 40+40 W 2TX MIMO output power at the BTS antenna connectors. Size and visual outlook is similar to the existing Flexi RF Modules. From HW point of view it can be used as powerful three sector RRH with max 4x40 W with 4TX MIMO and 4RX. 4TX MIMO and 4RX are separate SW features.

7.18.1.1


DN09185967 Issue: 01M

© 2016 Nokia

293



The LTE1563: FRHF Flexi RF Module 6TX 2600 provides the following features: the most cost and size and weight optimized 3-sector 2TX MIMO BTS site high RF integration level 3 sector 2TX MIMO RF in one outdoor IP65 box operating ambient temperature range: -35... +55°C smallest power consumption and OPEX can be used as feederless site with one DC and 1 or 2 optical cables 3-sector 2TX div and 2TX MIMO BTS can be built using only one 3-sector RF Module one 3-sector Module is more cost effective site solution than three RRHs in feederless installations 1/3 of DC and 2/3 of optical cabling compared to three sector site with Remote Radio Heads (RRH) easy installation HW prepared to support one sector 4x40 W 4TX MIMO with 4RX

• • • • • • • • • • •

7.18.1.2


System release


RL50

LBTS5.0

Table 171



UE

NetAct

MME

SAE GW






7.18.1.3

Functional description Functional overview The FRHF supports 3GGP band 7 at 2600 MHz highest 50 MHz part with 6 x 40 W output Flexi RF Module. Basic LTE Configurations: • • • • •

294

1, 1+1 or 1+1+1 LTE cells @ max 20 MHz LTE bandwidth and 2TX MIMO / 2RX 8, 20 or 40 W 1TX mode per sector (by branch activation SW licenses) 8+8, 20+20 or 40+40 W 2TX mode per sector (by branch activation and MIMO SW licenses) 1, 2 or 3 sectors max 40 + 40 W 2TX MIMO/2RX HW prepared for 1 sector 4x40 W 4TX MIMO/4RX

© 2016 Nokia

DN09185967 Issue: 01M



FRHF can be used in Feederless site (optical and DC cable up to 200 m).

7.18.1.4


7.18.1.5

LTE1563: FRHF Flexi RF Module 6TX 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 new or modified parameters related to this feature.

7.18.1.6


Sales information

BSW/ASW



BSW

-

-

7.19 LTE1662: FRHE Flexi RRH 4TX 2600 7.19.1 Description of LTE1662: FRHE Flexi RRH 4TX 2600 Introduction to the feature

DN09185967 Issue: 01M

© 2016 Nokia

295



Flexi Multiradio Remote Radio Head (RRH) with 4TX downlink MIMO and 4 receiver uplink diversity for world market operation at 2600 MHz 3GPP band 7 for the lowest 55 MHz part.

7.19.1.1

Benefits End-user benefits This feature does not affect the end-user experience. Operator benefits One sector Flexi Remote Radio Head supports 4TX MIMO with high output power. It enables easy outdoor installation close to antennas by maximizing BTS site capacity and coverage for one sector.

7.19.1.2


System release

Flexi

Flexi Lite

Flexi 10

RL50

LBTS5.0

support not needed

LBTS5.0

Table 173

7.19.1.3


iOMS

UE

NetAct

MME

SAE GW

support not needed

support not needed

support not needed

support not needed

support not needed

Functional description Functional overview The FRHE operates at DL: 2620-2675MHz and UL: 2500-2555MHz and provides the following features: • • • • • • •

7.19.1.4

4x30 W with four power amplifiers (at 45°C) optimized for single sector deployment with 4TX MIMO optical chaining supported by HW (two optical connectors) IP65 with -35 to +50°C with convection cooling external alarms and outputs AISG2.0 Antenna tilt support with external connector (RS485) MHA supported by both RX branches with adjustable 0...30 dB LNAsother TX/RX branch with integrated BiasT to support AISG2.0 MHA (or antenna tilt in future possible by the same HW)MHA SW support via integrated BiasT

System impacts Interdependencies between features

296

© 2016 Nokia

DN09185967 Issue: 01M



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.19.1.5


Sales information

BSW/ASW BSW

DN09185967 Issue: 01M



© 2016 Nokia

297

fd_rl50_desc.pdf

Recommend Documents