lte_fd_rel_10

Nokia

LTE Radio Access, Rel. FDDLTE16, Operating Documentation, Issue 02, Documentation Change Delivery 3 Feature Descriptions RL10 DN0978045 Issue 04A Approval Date 2016-07-25

Feature Descriptions RL10

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

©2016Nokia

DN0978045Issue:04A


Table of Contents This document has 354 pages Summary of Changes.................................................................. 31 1

RL10 Features - not supported by Fl exi Zone Micro....................32

2

Radio resource management and telecom features from previous releases for RL10.........................................................................33 LTE5: Radio bearer and S1 bearer e stablishment and release... 33 Introduction to the feature............................................................ 33 Benefits........................................................................................ 33 Requirements............................................................................... 33 Software requirements................................................................. 33 Hardware requirements................................................................ 33 Functional description.................................................................. 33 System impact..............................................................................34 Sales information......................................................................... 34 User interface............................................................................... 34 Parameters...................................................................................34 LTE20: Admission control............................................................. 38 Introduction to the feature............................................................ 38 Benefits........................................................................................ 38 Requirements............................................................................... 38 Software requirements................................................................. 39 Hardware requirements................................................................ 39 Functional description.................................................................. 39 Radio admission control............................................................... 39 Basic RAC functions (RL10)........................................................ 39 Interaction of radio admission control with other RRM functions..... 40 Radio admission control mechanism........................................... 41 Margin for the maximum number of active UEs in the cell accessing the cell via handover................................................... 42 Maximum bit rate in UL and DL....................................................43 Sales information......................................................................... 44 LTE27: Open-loop UL Power Control and DL Power Setting.......44 Introduction to the feature............................................................ 44

2.1 2.1.1 2.1.2 2.1.3 2.1.3.1 2.1.3.2 2.1.4 2.1.5 2.1.6 2.1.7 2.1.7.1 2.2 2.2.1 2.2.2 2.2.3 2.2.3.1 2.2.3.2 2.2.4 2.2.4.1 2.2.4.1.1 2.2.4.1.2 2.2.4.1.3 2.2.4.1.3.1 2.2.4.1.3.2 2.2.6 2.3 2.3.1 2.3.2 2.3.3 2.3.3.1 2.3.3.2 2.3.4 2.3.4.1 2.3.5 2.3.5.1

DN0978045Issue:04A

Benefits........................................................................................ 44 Requirements...............................................................................44 Software requirements................................................................. 44 Hardware requirements................................................................45 Functional description.................................................................. 45 Functional details......................................................................... 45 System impacts............................................................................47 Interdependencies between features........................................... 47

©2016Nokia

3


2.3.6 2.3.6.1 2.4 2.4.1 2.4.2 2.4.2.1 2.4.2.2 2.4.3

4

User interface...............................................................................47 Parameters...................................................................................47 LTE28: Closed loop UL power control ..........................................48 Introduction to the feature............................................................ 48 Benefits........................................................................................ 49 End user benefits......................................................................... 49 Operator benefits......................................................................... 49 Requirements...............................................................................49

2.4.3.1 2.4.3.2 2.4.4 2.4.4.1 2.4.4.1.1 2.4.5 2.4.5.1 2.4.5.2 2.4.5.3 2.4.6 2.4.6.1 2.4.6.2 2.4.7 2.4.8 2.4.8.1

Software requirements................................................................. 49 Hardware requirements................................................................49 Functional description.................................................................. 50 Functional details......................................................................... 50 Messages and information elements........................................... 52 System impacts............................................................................ 52 Interdependencies between features........................................... 52 Impacts on interfaces................................................................... 52 Impacts on performance and capacity ......................................... 53 User interface............................................................................... 53 Parameters...................................................................................53 Measurements and counters........................................................ 55 Activating The Feature................................................................. 56 Abbreviations............................................................................... 56 0 – Z............................................................................................. 56

2.5 2.5.1 2.5.2 2.5.3 2.5.3.1 2.5.3.2 2.5.4 2.5.4.1 2.5.5 2.5.5.1 2.5.6 2.5.6.1 2.5.7 2.6 2.6.1

LTE30: CQI adaption (DL)............................................................ 56 Introduction to the feature............................................................ 56 Benefits........................................................................................ 56 Requirements...............................................................................56 Software requirements................................................................. 57 Hardware requirements................................................................57 Functional description.................................................................. 57 Functional details......................................................................... 57 System impacts............................................................................ 58 Interdependencies between features........................................... 58 User interface...............................................................................58 Parameters...................................................................................58 Activating The Feature................................................................. 59 LTE31: Link Adaptation by AMC (UL/DL).....................................59 Introduction to the feature............................................................ 59

2.6.2 2.6.3 2.6.3.1 2.6.3.2 2.6.4 2.6.4.1 2.6.5 2.6.5.1

Benefits........................................................................................ 59 Requirements...............................................................................59 Software requirements................................................................. 59 Hardware requirements................................................................60 Functional description.................................................................. 60 Functional details......................................................................... 60 System impacts............................................................................62 Interdependencies between features........................................... 62

©2016Nokia

DN0978045Issue:04A


DN0978045Issue:04A

2.6.6 2.6.6.1 2.7 2.7.1 2.7.2 2.7.3 2.7.3.1 2.7.3.2

User interface............................................................................... 62 Parameters...................................................................................62 LTE37: Ciphering and LTE38: Integri ty protection........................63 Introduction to the feature............................................................ 63 Benefits........................................................................................ 64 Requirements............................................................................... 64 Software requirements................................................................. 64 Hardware requirements................................................................ 65

2.7.4 2.7.4.1 2.7.4.2 2.7.4.3 2.7.5 2.7.5.1 2.7.5.2 2.7.5.3 2.7.6 2.7.6.1 2.7.7 2.8 2.8.1 2.8.2 2.8.3

Functional description.................................................................. 65 Functional overview..................................................................... 65 Security keys................................................................................ 66 Messages and information elements ........................................... 69 System impacts............................................................................70 Interdependencies between features ........................................... 71 Impacts on network elements...................................................... 71 Impacts on system performance and capacity.............................71 User interface............................................................................... 71 Parameters...................................................................................71 Activating The Feature................................................................. 72 LTE39: System Information Broadca st.........................................72 Introduction to the feature............................................................ 72 Benefits........................................................................................ 72 Requirements............................................................................... 72

2.8.3.1 2.8.3.2 2.8.4 2.8.4.1 2.8.5 2.8.5.1 2.8.6 2.8.6.1 2.9 2.9.1 2.9.2 2.9.3 2.9.3.1 2.9.3.2 2.9.4

Software requirements................................................................. 72 Hardware requirements................................................................73 Functional description.................................................................. 73 Functional details......................................................................... 73 System impacts............................................................................74 Interdependencies between features ........................................... 74 User interface............................................................................... 74 Parameters...................................................................................74 LTE40: Physical and Transport Chan nels.................................... 83 Introduction to the feature............................................................ 83 Benefits........................................................................................ 83 Requirements...............................................................................83 Software requirements................................................................. 83 Hardware requirements................................................................84 Functional description.................................................................. 84

2.9.4.1 2.9.5 2.9.5.1 2.9.6 2.9.6.1 2.10 2.10.1 2.10.2

Functional details......................................................................... 84 System impacts............................................................................87 Interdependencies between features........................................... 87 User interface............................................................................... 87 Parameters...................................................................................87 LTE41: PDCP, RLC and MAC support......................................... 88 Introduction to the feature............................................................ 88 Benefits........................................................................................ 89

©2016Nokia

5


6

2.10.3 2.10.3.1 2.10.3.2 2.10.4 2.10.4.1 2.10.5 2.10.5.1 2.10.6

Requirements............................................................................... 89 Software requirements................................................................. 89 Hardware requirements................................................................89 Functional description.................................................................. 89 Functional details......................................................................... 89 System impacts............................................................................ 93 Interdependencies between features........................................... 94 User interface...............................................................................94

2.10.6.1 2.11 2.11.1 2.11.2 2.11.3 2.11.3.1 2.11.3.2 2.11.4 2.11.4.1 2.11.5 2.11.5.1 2.11.6 2.11.7 2.11.7.1

Parameters...................................................................................94 LTE43: Support of 64 QAM in DL, LT E788: Support of 16 QAM (UL), LTE793: Support of 16 QAM (DL)....................................... 95 Introduction to the feature............................................................ 95 Benefits........................................................................................ 95 Requirements............................................................................... 96 Software requirements................................................................. 96 Hardware requirements................................................................96 Functional description.................................................................. 96 Functional details......................................................................... 97 System impacts............................................................................ 97 Interdependencies between features........................................... 97 Sales information......................................................................... 97 User interface............................................................................... 97 Managed objects.......................................................................... 98

2.11.7.2 2.11.7.3 2.11.8 2.11.9 2.11.9.1 2.12 2.12.1 2.12.2 2.12.3 2.12.3.1 2.12.3.2 2.12.4 2.12.5 2.12.6 2.12.6.1

Parameters...................................................................................98 Measurements and counters........................................................ 98 Activating The Features............................................................. 100 Abbreviations............................................................................. 100 0 – Z........................................................................................... 100 LTE49: Paging............................................................................102 Introduction to the feature.......................................................... 102 Benefits...................................................................................... 102 Requirements.............................................................................102 Software requirements...............................................................102 Hardware requirements..............................................................102 Functional description................................................................ 103 System impact............................................................................106 User interface.............................................................................106 Alarms........................................................................................106

2.12.6.2 2.12.6.3 2.12.6.4 2.12.7 2.13 2.13.1 2.13.2 2.13.3

Measurements and counters......................................................107 Key performance indicators....................................................... 107 Parameters.................................................................................107 Sales information....................................................................... 107 LTE50: UE state management...................................................107 Introduction to feature................................................................ 107 Benefits...................................................................................... 107 Requirements.............................................................................107

©2016Nokia

DN0978045Issue:04A


DN0978045Issue:04A

2.13.3.1 2.13.3.2 2.13.4 2.13.6 2.14 2.14.1 2.14.2 2.14.3

Software requirements............................................................... 108 Hardware requirements..............................................................108 Functional description................................................................ 108 Sales information....................................................................... 109 LTE51: Cell selection and re-selectio n.......................................109 Introduction to the feature.......................................................... 109 Benefits...................................................................................... 109 Requirements............................................................................. 109

2.14.3.1 2.14.3.2 2.14.4 2.14.5 2.14.6 2.14.6.1 2.14.6.2 2.14.6.3 2.14.6.4 2.14.7 2.15 2.15.1 2.15.2 2.15.3 2.15.3.1

Software requirements............................................................... 109 Hardware requirements.............................................................. 110 Functional description.................................................................110 System impact............................................................................ 113 User interface............................................................................. 113 Alarms........................................................................................ 113 Measurements and counters...................................................... 113 Key performance indicators........................................................113 Parameters................................................................................. 113 Sales information........................................................................ 113 LTE53: Intra and inter eNB handover with X2............................ 114 Introduction to the feature........................................................... 114 Benefits.......................................................................................114 Requirements............................................................................. 114 Software requirements............................................................... 114

2.15.3.2 2.15.4 2.15.4.1 2.15.4.1.1 2.15.4.1.2 2.15.4.2 2.15.5 2.15.6 2.15.6.1 2.15.6.2 2.15.6.3 2.15.7 2.16 2.16.1

Hardware requirements.............................................................. 114 Functional description.................................................................114 General procedure......................................................................114 Inter-eNodeB handover.............................................................. 114 Intra-eNodeB handover.............................................................. 119 Target cell list handling............................................................... 120 System impact............................................................................120 User interface.............................................................................120 Alarms........................................................................................ 120 Measurements and counters......................................................120 Key performance indicators....................................................... 120 Sales information....................................................................... 120 LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas.............................. 121 Introduction to the feature.......................................................... 121

2.16.2 2.16.2.1 2.16.2.2 2.16.3 2.16.3.1 2.16.3.2 2.16.4 2.16.4.1

Benefits...................................................................................... 121 End user benefits....................................................................... 121 Operator benefits....................................................................... 121 Requirements.............................................................................121 Software requirements...............................................................122 Hardware requirements..............................................................122 Functional description................................................................ 122 Functional overview................................................................... 122

©2016Nokia

7


8

2.16.4.2 2.16.4.2.1 2.16.4.2.2 2.16.4.2.3 2.16.4.3 2.16.4.4 2.16.5 2.16.5.1

Downlink adaptive open loop MIMO for two antennas...............122 Receive diversity........................................................................ 124 Transmit diversity....................................................................... 125 Downlink open loop MIMO.........................................................125 Transmit diversity for two antennas............................................ 126 Open loop spatial multiplexing................................................... 127 System impacts..........................................................................127 Interdependencies between features......................................... 127

2.16.5.2 2.16.5.3 2.16.5.4 2.16.6 2.16.7 2.16.7.1 2.16.7.2 2.16.7.3 2.16.7.4 2.16.8 2.17 2.17.1 2.17.2 2.17.3 2.17.3.1

Impacts on interfaces................................................................. 127 Impacts on network and network element management tools... 127 Impacts on system performance and capacity...........................127 Sales information....................................................................... 128 User interface.............................................................................128 Managed Objects....................................................................... 128 Parameters.................................................................................128 Alarms........................................................................................129 Measurements and counters...................................................... 129 Activating the Feature................................................................ 129 LTE423: RRC connection release with redirect..........................129 Introduction to the feature.......................................................... 129 Benefits...................................................................................... 130 Requirements.............................................................................130 Software requirements............................................................... 130

2.17.3.2 2.17.4 2.17.5 2.17.6 2.17.6.1 2.17.6.2 2.17.6.3 2.17.6.4 2.17.7 2.18 2.18.1 2.18.2 2.18.3 2.18.3.1 2.18.3.2

Hardware requirements..............................................................130 Functional description................................................................ 130 System impact............................................................................130 User interface............................................................................. 130 Alarms........................................................................................131 Measurements and counters...................................................... 131 Key performance indicators....................................................... 131 Parameters.................................................................................131 Sales information....................................................................... 132 LTE747: Support of UE radio capabilities...................................132 Introduction to feature................................................................ 132 Benefits...................................................................................... 133 Requirements.............................................................................133 Software requirements...............................................................133 Hardware requirements..............................................................133

2.18.4 2.18.6 2.19 2.19.1 2.19.2 2.19.3 2.19.3.1 2.19.3.2

Functional description................................................................ 133 Sales information....................................................................... 134 LTE749: Link Adaptation for PDCCH......................................... 134 Introduction to the feature.......................................................... 134 Benefits...................................................................................... 134 Requirements.............................................................................134 Software requirements...............................................................134 Hardware requirements..............................................................134

©2016Nokia

DN0978045Issue:04A


2.19.4 2.19.4.1 2.19.5 2.19.5.1 2.19.6 2.19.6.1 2.20

Functional description................................................................ 134 Functional details....................................................................... 134 System impacts.......................................................................... 136 Interdependencies between features ......................................... 136 User interface.............................................................................136 Parameters.................................................................................136 LTE761: Advanced target cell selecti on and handover retry for intra frequency handover........................................................... 137

2.20.1 2.20.2 2.20.3 2.20.3.1 2.20.3.2 2.20.4 2.20.5 2.20.6 2.20.6.1 2.20.6.2 2.20.6.3 2.20.7 2.21

Introduction to the feature.......................................................... 137 Benefits...................................................................................... 137 Requirements............................................................................. 137 Software requirements...............................................................137 Hardware requirements..............................................................137 Functional description................................................................ 137 System impact............................................................................138 User interface............................................................................. 138 Alarms........................................................................................ 138 Measurements and counters...................................................... 138 Key performance indicators....................................................... 139 Sales information....................................................................... 139 LTE762: Idle mode mobility from LTE to WCDMA, GSM or other LTE bands.................................................................................. 139 Introduction to the feature.......................................................... 139

2.21.1 2.21.2 2.21.3 2.21.3.1 2.21.3.2 2.21.4 2.21.5 2.21.6 2.21.6.1 2.21.6.2 2.21.6.3 2.21.6.4 2.21.7 2.22 2.22.1 2.22.2 2.22.3 2.22.3.1 2.22.3.2 2.22.4 2.22.4.1 2.22.5 2.22.5.1 2.22.6

DN0978045Issue:04A

Benefits...................................................................................... 139 Requirements............................................................................. 139 Software requirements............................................................... 139 Hardware requirements..............................................................139 Functional description................................................................ 139 System impact............................................................................140 User interface.............................................................................140 Alarms........................................................................................ 140 Measurements and counters...................................................... 140 Key performance indicators....................................................... 140 Parameters.................................................................................140 Sales information....................................................................... 143 LTE767: Support of Aperiodic CQI Reports............................... 143 Introduction to the feature.......................................................... 143 Benefits...................................................................................... 144 Requirements.............................................................................144 Software requirements...............................................................144 Hardware requirements..............................................................144 Functional description................................................................ 144 Functional details....................................................................... 144 System impacts..........................................................................145 Interdependencies between features.........................................145 User interface.............................................................................145

©2016Nokia

9


2.22.6.1 2.23 2.23.1 2.23.2 2.23.3 2.23.3.1 2.23.3.2 2.23.4 2.23.6 3 3.1 3.1.1 3.2 3.2.1 3.3 3.3.1 3.4 3.4.1 3.5 3.5.1 3.6 3.6.1 3.7 3.7.1 3.7.2 3.7.3 3.7.3.1 3.7.3.2 3.7.4 3.7.4.1 3.7.4.1.1 3.7.4.2 3.7.4.3 3.7.5 3.7.6 3.7.6.1 3.7.6.2 3.7.6.3 3.7.7

10

Parameters.................................................................................145 LTE905: Non GBR QCI 5, 6,7, 8 and 9...................................... 145 Introduction to feature................................................................ 145 Benefits...................................................................................... 145 Requirements............................................................................. 146 Software requirements............................................................... 146 Hardware requirements..............................................................146 Functional description................................................................ 146 Sales information....................................................................... 146 Transport and transmission features f rom previous releases for RL10...........................................................................................147 LTE1: S1/X2 Datapath Management.......................................... 147 Description of LTE1: S1/X2 Datapath Management.................. 147 LTE3: S1, X2 and RRC Common Sig naling...............................151 Description of LTE3: S1, X2 and RRC Common Signaling........151 LTE118: Fast Ethernet (FE) / Gigabit Ethernet (GE) Electrical Interface..................................................................................... 154 Description of LTE118: Fast Ethernet (FE) / Gigabit Ethernet (GE) Electrical Interface......................................................................154 LTE119: Gigabit Ethernet (GE) Optica l Interface....................... 156 Description of LTE119: Gigabit Ethernet (GE) Optical Interface...... 156 LTE129: Traffic Prioritization on Ether net Layer.........................158 Description of LTE129: Traffic Prioritiz ation on Ethernet Layer..158 LTE131: Traffic Prioritization on IP Layer (Diffserv)................... 160 Description of LTE131: Traffic Prioritization on IP Layer (Diffserv).. 160 LTE132: VLAN based traffic differenti ation ............................... 164 Introduction to the Feature......................................................... 164 Benefits...................................................................................... 164 Requirements.............................................................................164 Software Requirements..............................................................164 Hardware Requirements............................................................ 164 Functional Description................................................................164 Network Scenarios with VLAN based Traffic Differentiation.......165 X2 interface via IPsec Star Configuration.................................. 166 VLAN based Traffic Differentiation: Mapping of DL Packets in the Security Gateway....................................................................... 167 VLAN based Traffic Differentiation: Mapping of DL Packets in the VLAN Gateway...........................................................................168 Sales Information....................................................................... 168 User Interface.............................................................................168 Parameters.................................................................................168 Alarms........................................................................................169 Measurements and Counters.....................................................169 Activating and Configuring the Feature......................................170

©2016Nokia

DN0978045Issue:04A


DN0978045Issue:04A

3.8 3.8.1 3.8.1.1 3.8.1.2 3.8.1.3 3.8.1.3.1 3.8.1.3.2 3.8.1.3.3

LTE134: Timing over packet.......................................................170 LTE134: Timing over Packet...................................................... 170 Benefits...................................................................................... 170 Requirements............................................................................. 170 Functional Description................................................................171 ToP Master................................................................................. 171 ToP Slave................................................................................... 172 Support of IEEE 1588 Event Messages.....................................172

3.8.1.3.3.1 3.8.1.4 3.8.1.5 3.8.1.6 3.9 3.9.1 3.10 3.10.1 3.11 3.11.1 3.12 3.12.1 3.13 3.13.1

Unicast Negotiation.................................................................... 172 Management data...................................................................... 173 Sales information....................................................................... 174 Activating and configuring the featur e........................................174 LTE138: Traffic Shaping (UL)..................................................... 174 Description of LTE138: Traffic Shaping (UL)..............................174 LTE664: LTE Transport Protocol Sta ck...................................... 177 Description of LTE664: LTE Transport Protocol Stack............... 177 LTE707: Flexi Transport Sub-module FTIB................................179 Description of LTE707: Flexi Transpo rt Sub-module FTIB.........179 LTE710: Synchronization from PDH Interface............................181 Description of LTE710: Synchronizat ion from PDH Interface.....181 LTE711: Synchronization from 2.048 MHz Signal......................183 Description of LTE711: Synchronization from 2.048 MHz Signal..... 183

3.14 3.14.1 3.14.2 3.14.3 3.14.3.1 3.14.3.2 3.14.4 3.14.4.1 3.14.5 3.14.6 3.14.6.1 3.14.6.2 3.14.6.3 3.14.7 3.15

LTE713: Synchronous Ethernet................................................. 185 Introduction to the Feature......................................................... 185 Benefits...................................................................................... 185 Requirements............................................................................. 186 Software Requirements..............................................................186 Hardware Requirements............................................................ 186 Functional Description................................................................186 Synchronization Status Messages (S SM)..................................186 Sales Information....................................................................... 187 User Interface.............................................................................187 Parameters.................................................................................187 Alarms........................................................................................188 Measurements and Counters.....................................................188 Activating and Configuring the Feature......................................188 LTE800: Flexi Transport Sub-module FTLB...............................188

3.15.1 3.16 3.16.1

Description of LTE800: Flexi Transport Sub-module FTLB........188 LTE875: Different IP Addresses for U/C/M/S-plane................... 190 Description of LTE875: Different IP Addresses for U/C/M/S-plane.. 190

4 4.1 4.1.1

Operability features from previous releases for RL10................194 LTE80: GPS Synchronisation.....................................................194 Introduction to the feature.......................................................... 194

©2016Nokia

11


4.1.2 4.1.3 4.1.3.1 4.1.3.2 4.1.4 4.1.4.1 4.1.4.2 4.1.5

Benefits...................................................................................... 194 Requirements.............................................................................194 Software requirements............................................................... 194 Hardware requirements..............................................................194 Functional description................................................................ 194 Architecture of time management.............................................. 195 Use cases.................................................................................. 195 System impact............................................................................ 195

4.1.5.1 4.1.5.2 4.1.5.3 4.1.5.4 4.1.6 4.1.6.1 4.1.6.2 4.1.6.3 4.1.6.4 4.1.7 4.2 4.2.1 4.2.2 4.2.3 4.2.3.1

Interdependencies between features......................................... 195 Impact on interfaces...................................................................196 Impact on network and network elem ent management tools.....196 Impact on system performance and c apacity.............................196 User interface.............................................................................196 Alarms for LTE80: GPS Synchronisat ion................................... 196 Measurements and counters for LTE8 0: GPS Synchronisation.196 Key performance indicators for LTE80: GPS Synchronisation...196 Parameters for LTE80: GPS Synchro nisation............................196 Sales information....................................................................... 196 LTE147: Hardware Management............................................... 196 Introduction to the feature.......................................................... 196 Benefits...................................................................................... 197 Requirements.............................................................................197 Software requirements............................................................... 197

4.2.3.2 4.2.4 4.2.4.1 4.2.5 4.2.5.1 4.2.5.2 4.2.5.3 4.2.5.4 4.2.6 4.2.6.1 4.2.6.2

Hardware requirements..............................................................197 Functional description ............................................................... 197 Architecture of network inventory............................................... 198 System impact............................................................................ 199 Interdependencies between features.........................................199 Impact on interfaces................................................................... 199 Impact on network and network elem ent management tools.....200 Impact on system performance and capacity.............................200 User interface............................................................................. 200 Alarms for LTE147:Hardware Management...............................200 Measurements and counters for LTE147:Hardware Management.. 200 Key performance indicators for LTE147:Hardware Management.... 200 Parameters for LTE147: Hardware Management.......................200 Sales information....................................................................... 200 LTE150: LTE OAM Transport Layer Security (TLS) Support......201 Introduction to the feature.......................................................... 201 Benefits...................................................................................... 201 Requirements.............................................................................201 Software requirements...............................................................201 Hardware requirements..............................................................201

4.2.6.3 4.2.6.4 4.2.7 4.3 4.3.1 4.3.2 4.3.3 4.3.3.1 4.3.3.2

12

©2016Nokia

DN0978045Issue:04A


4.3.4 4.3.4.1 4.3.5 4.3.5.1 4.3.5.2 4.3.5.3 4.3.5.4 4.3.6 4.3.7

4.4.11 4.5 4.5.1 4.5.2 4.5.3 4.5.3.1

Sales information....................................................................... 205 Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support.......................................................................................205 Alarms for LTE150: LTE OAM Trans port Layer Security (TLS) Support.......................................................................................206 LTE154: SON LTE BTS Auto Connectivity.................................206 Introduction to LTE154: SON LTE BT S Auto Connectivity.........206 Benefits...................................................................................... 206 Requirements.............................................................................207 Software requirements............................................................... 207 Hardware requirements..............................................................207 Overview.................................................................................... 207 Terms......................................................................................... 208 Phase 1 - pre-planning and HW insta llation...............................210 Phase 2 - start-process of an auto-c onnection.......................... 214 Phase 3 - Connect..................................................................... 215 Phase 4 - register....................................................................... 216 Manual intervention.................................................................... 217 Monitoring Auto Connection via BTS site manager................... 217 WCDMA BTS support of Auto Connection in an LTE network...218 Auto Connection workflow.......................................................... 219 Interdependencies between features ......................................... 220 Use case: BTS/eNB Auto Connection........................................221 Registration to OMS and activation o f new BTS/eNB in the topology......................................................................................222 Parameters for LTE154: SON LTE BTS auto connectivity......... 222 LTE158: NTP Clock Time Synchronization................................ 223 Introduction to the feature.......................................................... 223 Benefits...................................................................................... 223 Requirements.............................................................................223 Software requirements...............................................................223

4.5.3.2 4.5.4 4.5.5 4.5.5.1 4.5.5.2 4.5.5.3 4.5.5.4

Hardware requirements..............................................................223 Functional description................................................................ 224 System impact............................................................................224 Interdependencies between features.........................................224 Impact on interfaces...................................................................224 Impact on network and network element management tools.....225 Impact on system performance and capacity.............................225

4.3.8 4.4 4.4.1 4.4.2 4.4.3 4.4.3.1 4.4.3.2 4.4.4 4.4.4.1 4.4.4.2 4.4.4.3 4.4.4.4 4.4.4.5 4.4.5 4.4.6 4.4.7 4.4.8 4.4.9 4.4.10 4.4.10.1

DN0978045Issue:04A

Functional description for LTE OAM Transport Layer Security (TLS) Support.............................................................................201 Secure BTS Site Manager connectio n....................................... 204 System impact............................................................................204 Interdependencies between features ......................................... 205 Impact on interfaces................................................................... 205 Impact on network and network element management tools.....205 Impact on system performance and capacity.............................205

©2016Nokia

13


4.5.6 4.5.6.1 4.5.6.2

4.5.6.4 4.5.7

User interface............................................................................. 225 Alarms for LTE158: NTP Clock Time Synchronisation...............225 Measurements and counters for LTE1 58: NTP Clock Time Synchronisation..........................................................................225 Key performance indicators for L TE158: NTP Clock Time Synchronisation..........................................................................225 Parameters for LTE158: NTP Clock T ime Synchronization....... 225 Sales information....................................................................... 225

4.6 4.6.1 4.6.2 4.6.3 4.6.3.1 4.6.3.2 4.6.4 4.6.4.1 4.6.4.1.1 4.6.4.1.2 4.6.5 4.6.5.1 4.6.6 4.6.7 4.6.7.1

LTE432: Cell Outage Detection.................................................. 225 Introduction................................................................................ 225 Benefits...................................................................................... 226 Requirements.............................................................................226 Software Requirements for LTE432........................................... 226 Hardware Requirements............................................................ 226 Functional Description................................................................ 226 LTE432: Cell Outage Detection..................................................226 Failure Scenarios....................................................................... 227 Alarm Generation....................................................................... 227 System Impacts..........................................................................228 Interdependencies between Features ........................................228 Sales Information....................................................................... 228 User Interface.............................................................................228 Parameters for LTE432: Cell outage detection.......................... 228

4.5.6.3

4.6.7.2 4.6.7.3 4.6.8 4.6.9 4.6.10 4.6.10.1 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.1.7 4.7.1.8 4.7.1.9 4.8 4.8.1 4.8.2 4.8.2.1

14

Alarms for LTE432: Cell outage detec tion..................................229 Measurements and Counters for LTE432: Cell outage detection.... 229 System Responses to Failures.................................................. 230 Activating the Feature................................................................ 231 Abbreviations............................................................................. 231 0 – Z........................................................................................... 231 LTE468: PCI Management......................................................... 231 LTE468: PCI Management......................................................... 231 Overview.................................................................................... 231 Benefits...................................................................................... 231 NetAct Optimizer........................................................................232 Collision detection with alarming in eNB.................................... 232 NetAct Self-Healing process...................................................... 233 External LTE object support for LTE468: PCI Management in NetAct........................................................................................ 233 Interdependencies between features.........................................233 Alarms for LTE468: PCI management........................................234 Parameters for LTE468: PCI management................................234 LTE539: Central ANR.................................................................234 Introduction................................................................................ 234 Benefits...................................................................................... 235 Operator Benefits....................................................................... 235

©2016Nokia

DN0978045Issue:04A


4.8.3 4.8.3.1 4.8.3.2 4.8.4 4.8.4.1 4.8.4.1.1 4.8.4.1.2 4.8.4.1.3 4.8.4.1.3.1 4.8.4.1.3.2 4.8.4.1.3.3 4.8.4.1.4 4.8.4.1.4.1 4.8.4.1.4.2 4.8.4.1.5 4.8.5 4.8.5.1 4.8.6 4.8.7 4.8.8 4.8.8.1 4.9

NetAct SON features support for the external LTE cells............ 240 Intra-system adjacency border area management.....................240 External LTE cell support for the LTE539: Central ANR in NetAct... 241 Neighbor relation clean up in the Net Act....................................241 Optimizer: select and delete.......................................................241 Configurator: delete consistently................................................ 241 Central ANR for New eNBs........................................................ 242 System Impacts.......................................................................... 243 Interdependencies Between Feature s....................................... 243 Sales Information....................................................................... 243 Activating and Configuring the Featu re......................................244 Abbreviations............................................................................. 244 0 – Z........................................................................................... 244 LTE654: Configuration Management ..........................................244

4.9.1 4.9.1.1 4.9.1.2 4.9.1.3 4.9.1.3.1 4.9.1.3.2 4.9.1.4 4.9.1.4.1 4.9.1.4.1.1 4.9.1.5 4.9.1.5.1 4.9.1.5.2 4.9.1.5.3 4.9.1.5.4 4.9.1.6

LTE654: Configuration Management..........................................244 Introduction to the feature.......................................................... 244 Benefits...................................................................................... 244 Requirements............................................................................. 245 Software requirements............................................................... 245 Hardware requirements..............................................................245 Functional description................................................................ 245 Architecture of configuration manage ment................................ 248 Architecture of configuration management operations...............249 System impact............................................................................250 Interdependencies between features.........................................250 Impact on interfaces...................................................................251 Impact on network and network element management tools.....251 Impact on system performance and capacity.............................251 User interface.............................................................................251

4.9.1.6.1 4.9.1.6.2

Alarms for LTE654: Configuration Management........................ 251 Measurements and counters related for LTE654: Configuration Management.............................................................................. 251 Key performance indicators for LTE654: Configuration Management.............................................................................. 251 Parameters for LTE654: Configuration Management.................251 Sales information....................................................................... 251 Operating tasks related to configuration management.............. 251

4.9.1.6.3 4.9.1.6.4 4.9.1.7 4.9.1.8

DN0978045Issue:04A

Requirements.............................................................................235 Software Requirements..............................................................235 Hardware Requirements............................................................ 235 LTE539: Central ANR................................................................. 235 Functional Overview/Details.......................................................235 NetAct Optimizer........................................................................ 236 NetAct Configurator....................................................................239 External LTE Cell Support in NetAct.......................................... 240

©2016Nokia

15


4.9.1.8.1 4.9.1.8.2 4.9.1.8.3 4.9.1.8.4 4.10 4.10.1 4.10.2 4.10.3 4.10.3.1 4.10.3.2 4.10.4 4.10.4.1 4.10.4.2 4.10.4.3 4.10.4.3.1 4.10.4.3.2 4.10.4.3.3 4.10.4.3.4 4.10.4.4 4.10.4.4.1 4.10.4.4.1.1 4.10.4.4.1.2

Reguirements.............................................................................255 Software requirements............................................................... 255 Hardware requirements..............................................................255 Functional description................................................................ 255 Architecture of software managemen t....................................... 256 Software management with BTSSM.......................................... 257 Remote software management.................................................. 257 NetAct software management solutio n...................................... 257 eNB software management........................................................258 eNB software management functiona lity....................................258 iOMS software management......................................................261 Use cases.................................................................................. 262 Software download to network eleme nt..................................... 262 Software download to network eleme nt for FZM........................262 Manual software download and activa tion................................. 263

4.10.4.4.2 4.10.4.4.3 4.10.4.4.4 4.10.4.4.4.1

Software file distribution in FZM................................................. 264 Software download and activation............................................. 264 Software configuration (upload)................................................. 265 Upload of the SW configuration file a utomatically after activation... 265 System impact............................................................................265 Interdependencies between features.........................................265 Impact on interfaces................................................................... 266 Impact on network and network elem ent management tools.....266 Impact on system performance and capacity.............................266 User interface.............................................................................266 Alarms for LTE655: Software Management............................... 266 Measurements and counters related for LTE655: Software Management.............................................................................. 266 Key performance indicators for LTE655: Software Management..... 266

4.10.5 4.10.5.1 4.10.5.2 4.10.5.3 4.10.5.4 4.10.6 4.10.6.1 4.10.6.2 4.10.6.3 4.10.6.4 4.10.7 4.11 4.11.1 4.11.2 4.11.3 4.11.4

16

Downloading plans to network eleme nts....................................251 Activating plans in network elements......................................... 252 Direct configuration modifications wit h BTSSM......................... 253 NetAct Configurator operating tasks related to configuration management reference documentation..................................... 254 LTE655: Software Management................................................. 255 Introduction to the feature.......................................................... 255 Benefits...................................................................................... 255

Parameters for LTE655: Software Management........................266 Sales information....................................................................... 267 LTE656: LTE Fault Management................................................267 Introduction to fault management...............................................267 Benefits...................................................................................... 268 Requirements.............................................................................268 Functional description for fault management............................. 268

©2016Nokia

DN0978045Issue:04A


4.11.4.1 4.11.4.1.1 4.11.4.1.2 4.11.4.1.2.1 4.11.4.1.2.2 4.11.4.1.2.3 4.11.4.1.2.4 4.11.4.2

Fault management principles..................................................... 268 NetAct........................................................................................ 268 eNB............................................................................................ 269 Critical alarms............................................................................ 270 Clearing alarms.......................................................................... 270 Alarms per fault.......................................................................... 270 Alarm management.................................................................... 270 Suppress (block) toggling fault................................................... 270

4.11.4.2.1 4.11.4.2.2 4.11.4.3

Suppress (block) toggling fault functionality...............................271 User interface............................................................................. 271 Fault management related to LTE 44 7: SW support for RF sharing GSM - LTE..................................................................................273 RF sharing configurations ......................................................... 273 Architecture of fault management.............................................. 274 User............................................................................................274 NetAct........................................................................................ 274 eNB............................................................................................ 275 BTS Site Manager...................................................................... 275 iOMS.......................................................................................... 275 System impact............................................................................275 User Interface.............................................................................275 Parameters for LTE656: LTE Fault M anagement ......................275 Alarms for LTE656: LTE Fault Manag ement ............................. 276

4.11.4.3.1 4.11.4.4 4.11.4.4.1 4.11.4.4.2 4.11.4.4.3 4.11.4.4.4 4.11.4.4.5 4.11.5 4.11.6 4.11.6.1 4.11.6.2 4.11.6.3 4.11.6.4 4.11.7 4.12 4.12.1 4.12.2 4.12.3 4.12.3.1 4.12.3.2 4.12.4 4.12.4.1 4.12.4.1.1 4.12.4.1.2 4.12.4.1.3 4.12.4.1.4 4.12.4.1.5 4.12.4.1.6 4.12.4.1.7 4.12.4.2 4.12.4.2.1 4.12.5

DN0978045Issue:04A

Measurements and counters for LTE 656: LTE Fault Management . 276 Key performance indicators for LTE6 56: LTE Fault Management ... 276 Sales information....................................................................... 276 LTE657: Performance Management.......................................... 277 Introduction to the feature.......................................................... 277 Benefits...................................................................................... 277 Requirements............................................................................. 277 Software requirements............................................................... 277 Hardware requirements..............................................................277 Functional description................................................................ 277 Functional description for performance management................279 Terms in performance management.......................................... 280 Measurement administration......................................................280 Measurement collection............................................................. 281 Measurement data storage........................................................ 281 Measurement data transfer........................................................ 281 Measurement data presentation................................................ 282 Measurement data threshold monitoring....................................283 Architecture of performance management.................................283 Architectural roles...................................................................... 284 System impact............................................................................285

©2016Nokia

17


4.12.5.1 4.12.5.2 4.12.5.3 4.12.5.4 4.12.6 4.12.7 4.12.7.1 4.12.7.2 4.12.7.3 4.12.7.4 4.13 4.13.1 4.13.2 4.13.3 4.13.3.1 4.13.3.2 4.13.4 4.13.5 4.13.5.1 4.13.5.2 4.13.5.3 4.13.5.4 4.13.6 4.13.6.1 4.13.6.2 4.13.6.3 4.13.6.4 4.13.7 4.14 4.14.1 4.14.1.1 4.14.1.2 4.14.2 4.14.2.1 4.14.2.2 4.14.3 4.14.3.1 4.14.3.2 4.14.4 4.14.4.1

18

Interdependencies between features......................................... 285 Impact on interfaces...................................................................285 Impact on network and network element management tools.....285 Impact on system performance and c apacity.............................285 Sales information....................................................................... 285 User interface............................................................................. 285 Alarms for LTE657: Performance Management.........................285 Measurements and counters for LTE6 57: Performance Management.............................................................................. 285 Key performance indicators for LTE657: Performance Management.............................................................................. 286 Parameters for LTE657: Performan ce Management..................286 LTE663: GPS Location and Time Ret rieval................................286 Introduction to the feature.......................................................... 286 Benefits...................................................................................... 286 Requirements.............................................................................286 Software requirements............................................................... 286 Hardware requirements..............................................................286 Functional description................................................................ 286 System impact............................................................................287 Interdepencies between features............................................... 287 Impact on interfaces...................................................................287 Impact on network and network elem ent management tools.....287 Impact on system performance and c apacity.............................287 User interface.............................................................................287 Alarms for LTE663: GPS Lo cation and Time Retrieval.............. 287 Measurements and counters for LTE663: GPS Location and Time Retrieval..................................................................................... 287 Key performance indicators for LTE6 63: GPS Location and Time Retrieval..................................................................................... 287 Parameters for LTE663: GPS Locatio n and Time Retrieval.......287 Sales information....................................................................... 288 LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA)......288 Introduction to the feature.......................................................... 288 LTE665: LTE Certificate Management....................................... 288 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) ....................................................... 288 Benefits...................................................................................... 288 LTE665: LTE Certificate Management....................................... 288 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA)........................................................ 288 Requirements.............................................................................289 Software requirements...............................................................289 Hardware requirements..............................................................289 Functional description for certificate management.....................289 LTE665: LTE Certificate Management....................................... 289

©2016Nokia

DN0978045Issue:04A


4.14.4.2 4.14.5 4.14.6 4.14.7 4.14.7.1 4.14.7.2 4.14.8

LTE685: Infrastructures for Certificat ion Authority (CA) and Registration Authority (RA)........................................................ 293 System impacts.......................................................................... 295 Sales information....................................................................... 295 User interface............................................................................. 295 Parameters for LTE665: LTE Certificate Management...............295 Alarms for LTE665: LTE Certificate M anagement...................... 296 Activating and configuring the feature........................................297

4.15 4.15.1 4.15.2 4.15.3 4.15.3.1 4.15.3.2 4.15.4 4.15.4.1 4.15.4.2 4.15.4.3 4.15.4.3.1 4.15.4.4 4.15.5 4.15.6 4.15.7

LTE666: LTE User Account Manage ment.................................. 297 Introduction to the feature.......................................................... 297 Benefits...................................................................................... 297 Requirements............................................................................. 297 Software Requirements..............................................................298 Hardware Requirements............................................................ 298 Functional description for user secur ity......................................298 Authentication and authorization................................................ 298 Disabling user accounts in NetAct............................................. 299 User management......................................................................299 Mass updating of eNB local user acc ounts................................ 299 Audit trail.................................................................................... 300 System impacts.......................................................................... 301 Sales information....................................................................... 301 User interface............................................................................. 301

4.15.7.1 4.15.7.2 4.15.8 4.16 4.16.1 4.16.2 4.16.3 4.16.3.1 4.16.3.2 4.16.4

Parameters for LTE666: LTE User A ccount Management......... 301 Alarms for LTE666: LTE User Accou nt Management.................302 Activating and configuring the featur e........................................302 LTE679: LTE Local User Account Ma nagement........................ 302 Introduction to the feature.......................................................... 302 Benefits...................................................................................... 302 Requirements............................................................................. 302 Software requirements............................................................... 302 Hardware requirements..............................................................303 Functional description for LTE Local User Account Management... 303 System impacts..........................................................................303 Sales information....................................................................... 303 User interface.............................................................................303 Parameters for LTE679: LTE Local User Account Management...... 303 Activating the feature................................................................. 304 LTE689: LTE IPsec Support.......................................................304 Introduction to the feature.......................................................... 304 Benefits...................................................................................... 304 Requirements.............................................................................304 Software requirements...............................................................304 Hardware requirements..............................................................305

4.16.5 4.16.6 4.16.7 4.16.7.1 4.16.8 4.17 4.17.1 4.17.2 4.17.3 4.17.3.1 4.17.3.2

DN0978045Issue:04A

©2016Nokia

19


4.17.4 4.17.4.1 4.17.5 4.17.6 4.17.7 4.17.7.1 4.17.7.2 4.17.7.3

Functional description for IPsec Support................................... 305 Transport security.......................................................................306 System impacts.......................................................................... 307 Sales information....................................................................... 307 User interface............................................................................. 307 Parameters for LTE689: LTE IPsec S upport.............................. 307 Alarms for LTE689: LTE IPsec Support......................................311 Counters for LTE689: LTE IPsec Sup port.................................. 311

4.17.8 4.18 4.18.1 4.18.1.1 4.18.1.2 4.19 4.19.1 4.19.2 4.19.3 4.19.3.1 4.19.3.2 4.19.4 4.19.4.1 4.19.4.2 4.19.4.3

Activating and configuring the feature ........................................312 LTE690: Interface Trace Support .............................................. 312 LTE690: Interface Trace Support............................................... 312 Overview.................................................................................... 312 Benefits...................................................................................... 312 LTE692: LTE Firewall Support.................................................... 312 Introduction to the feature.......................................................... 312 Benefits...................................................................................... 312 Requirements............................................................................. 312 Software requirements............................................................... 313 Hardware requirements..............................................................313 Functional description for LTE Firewa ll Support.........................313 Firewall functionality................................................................... 314 Firewall filter...............................................................................315 Logging...................................................................................... 316

4.19.5 4.19.6 4.19.7 4.19.7.1 4.19.7.2 4.19.8 4.20 4.20.1 4.20.2 4.20.3 4.20.3.1 4.20.3.2 4.20.4 4.20.5 4.20.6

System impacts.......................................................................... 316 Sales information....................................................................... 317 User interface............................................................................. 317 Parameters for LTE692: LTE Firewall Support...........................317 Counters for LTE692: LTE Firewall Support...............................317 Activating and configuring the feature ........................................317 LTE720: SON LTE BTS Auto Configu ration...............................318 Introduction................................................................................ 318 Benefits...................................................................................... 318 Requirements.............................................................................318 Software requirements...............................................................318 Hardware requirements..............................................................318 Overview.................................................................................... 318 Interdependencies between features.........................................321 Bar code reader support for BTS site manager......................... 321

4.20.7 4.20.7.1 4.20.7.2 4.20.7.3 4.20.8 4.20.8.1 4.20.8.2 4.20.8.2.1

20

Configurator user visibility to auto configuration in NetAct.........322 E-mail indications....................................................................... 322 CM operations manager operations history tab......................... 322 Auto configuration report............................................................322 Use case: BTS/eNB Auto Configuration.................................... 322 SW download and activation......................................................323 Configuration data download and activation.............................. 325 Download and validation of configuration data.......................... 325

©2016Nokia

DN0978045Issue:04A


4.20.8.2.2 4.20.8.2.3 4.20.9 4.21 4.21.1 4.21.2 4.21.3 4.21.3.1

Activation of configuration.......................................................... 326 Automatic physical-layer cell ID generation............................... 327 Parameters for LTE720: SON LTE B TS auto configuration....... 328 LTE724: LTE Automatic Neighbor Ce ll Configuration................ 329 Introduction to the feature.......................................................... 329 Benefits...................................................................................... 329 Requirements............................................................................. 329 Software requirements...............................................................329

4.21.3.2 4.21.4 4.21.4.1 4.21.4.2 4.21.4.3 4.21.4.4 4.21.4.5 4.21.4.6 4.21.5 4.21.6 4.21.6.1 4.21.6.2 4.21.6.3 4.21.7 4.22

Hardware requirements..............................................................330 Functional description................................................................ 330 Pre-planning............................................................................... 330 Commissioning and integration phas e of a new eNB................ 330 LTE neighbor cell information.....................................................330 Neighbor cell update.................................................................. 331 Configuration data exchange via X2.......................................... 331 LTE724 Interaction with Common Object Model........................332 System impact............................................................................333 User interface............................................................................. 333 Alarms........................................................................................333 Measurements and counters...................................................... 333 Key performance indicators....................................................... 333 Sales information....................................................................... 333 LTE746: IP based filtering for BTS S ite Support Equipment......333

4.22.1 4.22.2 4.22.3 4.22.3.1 4.22.3.2 4.22.4

Introduction to the feature.......................................................... 333 Benefits...................................................................................... 333 Requirements............................................................................. 333 Software requirements............................................................... 334 Hardware requirements..............................................................334 Functional description for IP based fi ltering for BTS Site Support Equipment.................................................................................. 334 System impacts.......................................................................... 335 Sales information....................................................................... 335 User interface.............................................................................335 Parameters for LTE746: IP based filtering for BTS Site Support Equipment.................................................................................. 335 Activating the feature................................................................. 336 LTE913: LTE NEBS compliant OMS.......................................... 337 Introduction to the Feature......................................................... 337 Benefits...................................................................................... 337 Functional Description................................................................337 Requirements.............................................................................338

4.22.5 4.22.6 4.22.7 4.22.7.1 4.22.8 4.23 4.23.1 4.23.2 4.23.3 4.23.4 5 5.1 5.2 5.2.1

DN0978045Issue:04A

Flexi Multiradio BTS LTE Site Solution features from previous releases for RL10.......................................................................339 Introduction to the Flexi Multiradio BTS Site Solution features..33 9 Cell-related features...................................................................339 LTE cell bandwidth features: LTE112,LTE114, and LTE115.......339

©2016Nokia

21


22

5.2.1.1 5.2.1.2 5.2.1.3 5.2.1.4 5.2.2 5.2.2.1 5.2.2.2 5.2.2.3

Introduction................................................................................ 339 Functional description................................................................ 339 Benefits...................................................................................... 339 Activating the feature................................................................. 339 LTE75: Up to 3 cells per Flexi LTE BT S.....................................339 Introduction................................................................................ 340 Benefits...................................................................................... 340 Functional description................................................................ 340

5.2.3 5.2.3.1 5.2.3.2 5.2.3.3 5.2.3.4 5.2.4 5.2.4.1 5.2.4.2 5.2.4.3 5.2.4.4 5.3 5.3.1 5.3.1.1 5.3.1.2 5.3.1.3

LTE81: Cell range up to 13 km................................................... 340 Introduction................................................................................ 340 Benefits...................................................................................... 340 Functional description................................................................ 340 Management data...................................................................... 341 LTE97: Cell radius max 77 km................................................... 341 Introduction................................................................................ 341 Benefits...................................................................................... 341 Functional description................................................................ 341 Activating the feature................................................................. 341 Antenna line features................................................................. 341 LTE71: 2-way RX diversity (MRC).............................................. 341 Introduction................................................................................ 342 Benefits...................................................................................... 342 Functional description................................................................ 342

5.3.2 5.3.2.1 5.3.2.2 5.3.2.3 5.3.2.4 5.3.2.5 5.3.3 5.3.3.1 5.3.3.2 5.3.3.3 5.3.3.4 5.3.4 5.3.4.1 5.3.4.2 5.3.4.3

LTE160: Flexi Multiradio BTS 3GPP a ntenna tilt support.......... 342 Introduction................................................................................ 342 Benefits...................................................................................... 342 Functional description................................................................ 342 Management data...................................................................... 343 Activating the feature................................................................. 344 LTE899: Antenna Line Supervision............................................ 344 Introduction................................................................................ 344 Benefits...................................................................................... 344 Functional description................................................................ 344 Activating the feature................................................................. 344 LTE94: Feederless site...............................................................344 Introduction................................................................................ 344 Benefits...................................................................................... 344 Functional description................................................................ 345

5.3.5 5.3.5.1 5.3.5.2 5.3.5.3 5.3.5.4 5.4 5.4.1 5.4.2

Features related to mast head amplifiers...................................345 LTE76: Support for legacy MHA.................................................345 LTE155: Support for third-party MHA.........................................345 LTE902: Flexi Multiradio BTS AISG MHA support..................... 346 LTE810: Flexi Multiradio BTS dual MHA 2600 (FLHA).............. 346 Flexi Multiradio BTS RF Modules...............................................346 Introduction................................................................................ 346 Benefits...................................................................................... 346

©2016Nokia

DN0978045Issue:04A


DN0978045Issue:04A

5.4.3 5.4.4 5.4.5 5.4.6 5.4.6.1 5.4.6.2 5.4.6.3 5.5

LTE85: Flexi 3-sector RF Module 2600 (FRHA).........................347 LTE99: Flexi 3-sector RF Module 1.7 /2.1 (FRIE)....................... 347 LTE437: Flexi 3-sector RF Module 8 00EU.................................347 LTE96: MIMO 2TX configuration with 3-sector RF Module........347 Introduction................................................................................ 347 Benefits...................................................................................... 347 Functional description................................................................ 347 Flexi Multiradio BTS Remote Radio Heads................................347

5.5.1 5.5.2 5.5.3 5.6 5.6.1 5.6.1.1 5.6.1.2 5.6.1.3 5.6.2 5.6.2.1 5.6.2.2 5.6.2.3 5.6.3 5.6.3.1 5.6.3.2

Benefits...................................................................................... 348 Functional description................................................................ 348 LTE547: Flexi RRH 2TX 800EU................................................. 348 Cabinets and other Flexi Multiradio B TS hardware....................348 LTE79: Flexi Indoor (FCIA) and Outdoor (FCOA) Cabinets.......348 Introduction................................................................................ 348 Benefits...................................................................................... 348 Functional description................................................................ 349 LTE78: Flexi AC/DC with Battery Po wer Module (FPMA)..........350 Introduction................................................................................ 350 Benefits...................................................................................... 350 Functional description................................................................ 350 LTE82: High-capacity Flexi System Module (FSME)................. 350 Introduction................................................................................ 350 Benefits...................................................................................... 350

5.6.3.3 5.7 5.7.1 5.7.1.1 5.7.1.2 5.7.1.3 5.7.2 5.7.2.1 5.7.2.2 5.7.2.3 5.7.3 5.7.3.1 5.7.3.2 5.7.3.3 5.7.4

Functional description................................................................ 351 Power support features.............................................................. 351 LTE900: Flexi Multiradio BTS 40 W p ower support....................351 Introduction................................................................................ 351 Benefits...................................................................................... 351 Functional description................................................................ 351 LTE901: Flexi Multiradio BTS 8 W po wer support......................352 Introduction................................................................................ 352 Benefits...................................................................................... 352 Functional description................................................................ 352 LTE903: Flexi Multiradio BTS 60 W power support....................352 Introduction................................................................................ 352 Benefits...................................................................................... 353 Functional description................................................................ 353 LTE904: Flexi LTE BTS Branch Activation.................................353

5.7.4.1 5.7.4.2 5.7.4.3

Introduction................................................................................ 353 Benefits...................................................................................... 353 Functional description................................................................ 353

©2016Nokia

23


List of Figures

24

Figure 1

Power control decision matrix.............................................................51

Figure 2

Principle of CQI adaptation.................................................................58

Figure 3

C-plane security..................................................................................65

Figure 4

U-plane security..................................................................................65

Figure 5

Security key hierarchy........................................................................ 67

Figure 6 Figure 7

Layer 2 downlink, transmitting side.................................................... 90 Layer 2 uplink, receiving side............................................................. 90

Figure 8

PDCP U-plane and C-plane............................................................... 93

Figure 9

Throughput for different modulation schemes.................................... 96

Figure 10

QAM modulation................................................................................. 97

Figure 11

Message flow for an inter-eNodeB handover................................... 118

Figure 12

2x2 MIMO configuration................................................................... 125

Figure 13

Traffic prioritization on the Ethernet layer......................................... 159

Figure 14

QoS differentiation between user, control and management plane traffic................................................................................................. 161

Figure 15

Multipoint-to-multipoint VLAN........................................................... 166

Figure 16

Point-to-Point VLAN......................................................................... 166

Figure 17

IPsec star configuration....................................................................167

Figure 18

FTIB module..................................................................................... 180

Figure 19 Figure 20

FTLB module.................................................................................... 189 Different IP addresses for eNB applications.....................................192

Figure 21

Architecture of network inventory..................................................... 198

Figure 22

LTE154: SON LTE BTS Auto Connection .........................................207

Figure 23

Auto-Connection with DHCP server................................................. 208

Figure 24

Transport overview with IP addresses.............................................. 216

Figure 25

Auto-configuration dialog.................................................................. 218

Figure 26

Auto Connection workflow using NetAct...........................................220

Figure 27

LTE432 “Thresholder and Profiler” in NetAct....................................227

Figure 28

Border area management - info model.............................................240

Figure 29

LNREL deletion................................................................................ 241

Figure 30

Local and remote usage of BTS Site manager.................................248

Figure 31

Mass operations in CM area (example)............................................249

Figure 32 Figure 33

Architecture of software management..............................................256 Suppress (block) toggling faults....................................................... 271

Figure 34

Block Toggling Fault Feature in the Fault View................................ 272

Figure 35

Block Toggling Fault Dialog.............................................................. 272

Figure 36

Filter definitions (example)............................................................... 273

Figure 37

LTE alarm system architecture......................................................... 274

Figure 38

LTE performance management architecture.................................... 283

©2016Nokia

DN0978045Issue:04A


DN0978045Issue:04A

Figure 39

Transport protocol stack overview....................................................306

Figure 40

Auto-Configuration............................................................................320

Figure 41

Software download and activation....................................................324

Figure 42

Configuration of neighbor cells.........................................................332

©2016Nokia

25


List of Tables

26

Table 1

RL10 Features - not supported by Flexi Zone Micro.......................... 32

Table 2

Software requirements for different netwo rk elements....................... 33

Table 3

Parameters for LTE5: Radio bearer and S1 bearer establishment and release................................................................................................34

Table 4

Parameters related to the AM RLC profile for DRBs ( LTE5: Radio bearer and S1 bearer establishment and release)............................. 35

Table 5 Table 6

AM RLC pollByte table....................................................................... 37 Parameters related to the PDCP profile ( LTE5: Radio bearer and S1 bearer establishment and release)..................................................... 37

Table 7


Table 8


Table 9

Parameters for LTE27: Open Loop UL Power Control and DL Power Setting................................................................................................ 48

Table 10


Table 11

Parameters for closed loop UL power con trol.................................... 53

Table 12

Parameters common for open and closed loop UL power control......54

Table 13


Table 14


Table 15

Parameters for LTE31: Link Adaptation by AMC (UL/DL).................. 62

Table 16


Table 17

Security related messages and informatio n elements........................69

Table 18

Parameters for ciphering and integrity p rotection...............................71

Table 19

Software requirements for different network elements....................... 72

Table 20

Parameters for LTE39: System Inform ation Broadcast...................... 74

Table 21


Table 22

Uplink: Mapping of transport channels on to the physical channels....86

Table 23

Downlink: Mapping of transport channels onto the physical channels... 86

Table 24

Parameters for LTE40: Physical and transport channels................... 87

Table 25

Software requirements for different network elements....................... 89

Table 26

Mapping of logical channels onto transport channels in DL............... 91

Table 27

Mapping of transport channels onto logical channels in UL............... 91

Table 28

Parameters for LTE41: PDCP, RLC and MAC support.......................94

Table 29 Table 30

Software requirements for different network elements....................... 96 Parameters for LTE43: Support of 64QAM in DL............................... 98

Table 31

Counters for LTE43............................................................................ 98

Table 32

Software requirements for different network elements..................... 102

Table 33

Content of the S1AP: PAGING message......................................... 105

Table 34

Content of the RRC: PAGING message...........................................106

Table 35

Parameters for the LTE49: Paging .................................................. 107

©2016Nokia

DN0978045Issue:04A


Table 36

DN0978045Issue:04A

Sales information.............................................................................. 107

Table 37


Table 38

Software requirements for different netw ork elements..................... 109

Table 39

NAS and AS parts of cell selection and c ell reselection................... 110

Table 40


Table 41


Table 42


Table 43 Table 44

Multi antenna options in LTE............................................................ 124 Parameters for “LTE70: Downlink adapti ve open loop MIMO for two antennas”..........................................................................................128

Table 45


Table 46

Parameters for RRC connection release with redirect..................... 131

Table 47


Table 48


Table 49


Table 50

Code rates for PDCCH..................................................................... 135

Table 51

Parameters for LTE749: Link Adaptation for PDCCH.......................136

Table 52


Table 53


Table 54


Table 55

Parameters for the ...........................................................................140

Table 56


Table 57

CQI report modes for aperiodic reporting......................................... 144

Table 58

Parameters for LTE767: Support of Aper iodic CQI Reports.............145

Table 59


Table 60

Hardware and software requirements.............................................. 147

Table 61

New alarms.......................................................................................149

Table 62

New counters....................................................................................149

Table 63

New parameters............................................................................... 150

Table 64

Sales information..............................................................................151

Table 65


Table 66

New alarms.......................................................................................153

Table 67

New BTS faults.................................................................................153

Table 68

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

Table 69


Table 70


Table 71


Table 72


Table 73


Table 74


©2016Nokia

27


Table 75

28


Table 76


Table 77

Default DSCP/PHB mapping for traffic typ es without QCI assigned...... 161

Table 78

New parameters for LTE131: Traffic Prioritization on IP Layer (Diffserv)........................................................................................... 163

Table 79


Table 80

Software requirements for different netwo rk elements..................... 164

Table 81

Supported numbers of VLANs..........................................................165

Table 82

Sales Information..............................................................................168

Table 83

Parameters related to the LTE132: VLAN based traffic differentiation... 168

Table 84

Counters for the LTE132: VLAN based traffic differentiation............ 169

Table 85

Software requirements for different netwo rk elements..................... 171

Table 86

Parameters related to the LTE134: Timing over packet feature....... 173

Table 87


Table 88


Table 89

Parameters for LTE138: Traffic Shaping (UL)...................................176

Table 90


Table 91


Table 92

New BTS faults................................................................................. 178

Table 93 Table 94

New parameters for LTE664: LTE Transport Protocol Stack............178 Sales information.............................................................................. 179

Table 95


Table 96

New BTS faults................................................................................. 180

Table 97


Table 98


Table 99

New BTS faults.................................................................................182

Table 100

New parameters for LTE710: Synchronization from PDH Interface . 183

Table 101


Table 102


Table 103

New parameters for LTE711: Synchronization from 2.048 MHz Signal .. 185

Table 104


Table 105


Table 106

Parameters related to the LTE713: Synchronous Ethernet feature..188

Table 107


Table 108

New BTS faults.................................................................................190

Table 109


Table 110


©2016Nokia

DN0978045Issue:04A


DN0978045Issue:04A

Table 111

New parameters for LTE875: Different IP Address for U/C/M/S-plane... 193

Table 112


Table 113


Table 114


Table 115


Table 116

Parameters for LTE147: Hardware Management.............................200

Table 117 Table 118

Sales information.............................................................................. 200 Software requirements for different network elements..................... 201

Table 119

Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support............................................................................................. 205

Table 120

Alarms for LTE150: LTE OAM Transport Layer Security (TLS) Support ..........................................................................................................206

Table 121


Table 122

Terms related to LTE154: SON LTE BTS Auto Connectivity............ 208

Table 123

OMS PREBTS parameters...............................................................210

Table 124

Format of vendor class identifier in DHCP discover.........................212

Table 125

Format of vendor specific extensions............................................... 213

Table 126

TLV format of vendor specific parameters........................................213

Table 127

Interdependencies between LTE154 features and others................ 220

Table 128

Parameters for LTE154: SON LTE BTS a uto connectivity................223

Table 129 Table 130

Software requirements for different network elements..................... 223 Parameters for LTE158: NTP Clock Time Synchronization..............225

Table 131


Table 132


Table 133

Interdependencies between features............................................... 228

Table 134

Parameters for the LTE432: Cell Outage Detection......................... 228

Table 135

Alarms for the LTE432: Cell outage detection.................................. 229

Table 136

Counters for the LTE432: Cell outage detection...............................230

Table 137

Error codes....................................................................................... 230

Table 138

Alarms for the LTE468: PCI management........................................ 234

Table 139

Parameters for LTE468: PCI management...................................... 234

Table 140


Table 141

Interdependencies between features............................................... 243

Table 142 Table 143

Software requirements for different network elements..................... 245 Sales information.............................................................................. 251

Table 144


Table 145

Alarms related to eNB software management..................................266

Table 146

Alarms for OMS Remote SW management......................................266

Table 147


Table 148


©2016Nokia

29


30

Table 149

Parameters related to LTE656: LTE Fault Management.................. 275

Table 150

Alarms related to LTE656: LTE Fault Management..........................276

Table 151

..........................................................................................................276

Table 152


Table 153

Terms in performance management.................................................280

Table 154


Table 155


Table 156 Table 157

Sales information..............................................................................288 Software requirements for different network elements..................... 289

Table 158

Parameters for LTE665: LTE Certificate Management.....................296

Table 159

Alarms for LTE665: LTE certificate management............................. 296

Table 160


Table 161

Parameters for LTE666: LTE User Accou nt Management................301

Table 162

Parameters for LTE666: LTE User Account Management - BTSSM...... 301

Table 163

Alarms for LTE666: LTE User Account M anagement.......................302

Table 164


Table 165

Parameters for LTE679: LTE Local User Account Management...... 303

Table 166


Table 167

Hardware requirements for different network elements....................305

Table 168

IPsec capabilities.............................................................................. 305

Table 169


Table 170

Parameters for LTE689: LTE IPsec Support.....................................307

Table 171

Alarms for LTE689: LTE IPsec Support............................................ 311

Table 172

Counters for LTE689: LTE IPsec Support .........................................311

Table 173


Table 174

Messages......................................................................................... 314

Table 175

Parameters for LTE692: LTE Firewall Support................................. 317

Table 176

Counters for LTE692: LTE Firewall Support..................................... 317

Table 177


Table 178

Interdependencies between LTE720 and other features..................321

Table 179

Parameters for LTE720: SON LTE BTS auto configuration..............328

Table 180


Table 181


Table 182

Parameters for LTE746: IP based filtering for BTS Site Support Equipment........................................................................................ 335

Table 183

Parameter for configuring MTU size................................................. 336

Table 184

The parameters related to LTE81: Cell range up to 13 km...............341

Table 185

The parameters related to LTE160: Flexi Multiradio BTS 3GPP antenna tilt support........................................................................... 343

©2016Nokia

DN0978045Issue:04A

FeatureDescriptionsRL10

SummaryofChanges

Summary of Changes Changes between version 04 (2016-06-14) and 04A (2016-07-25)

The LTE50: UE state managementfeature description has been updated. Changes between version 03D (2016-02-19) and 04 (2016-06-14)

The LTE45: Fair Scheduler (UL/DL)feature description has been added. Changes between version 03C (2015-12-11) and 03D (2016-02-19)

The following feature descriptions have been updated: • •

DN0978045Issue:04A

LTE78: Flexi AC/DC with Battery Power Module (FPMA) LTE79: Flexi Indoor (FCIA) and Outdoor (FCOA) Cabinets

©2016Nokia

31

RL10 Features - not supported by Flexi Zone Micro


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

RL10 Features - not supported by Flexi Zone Micro F eat u re s

LTE75:Upto3cellsperFlexiLTEBTS LTE76:SupportforlegacyMHA

C at e go ry

BTS BTS

LTE78: Flexi AC/DC with Battery Power Module

BTS

LTE79: FlexiIndoor andOutdoor cabinets

BTS

LTE82: FSME High Capacity Flexi System Module LTE85: FRHA Flexi 3-sector RF Module 2600

BTS BTS

LTE86: FRGP Flexi 3-sector RF Module 2100

BTS

LTE94:FeederlessSite

BTS

LTE96: MIMO 2TX configuration with 3-sector RF Module LTE97:Cellradiusmax77km

BTS BTS

LTE99: FRIE Flexi 3-sector RF Module 1.7/2.1 LTE155:Supportfor3rdpartyMHA LTE160: Flexi BTS 3GPP Antenna Tilt Support LTE437: FRMA Flexi 3-sector RF Module 800EU

BTS BTS BTS BTS

LTE547:FRMBFlexiRRH2TX800EU

BTS

LTE630:FLMAFlexiDualMHA800

BTS

LTE707: FlexiTransport sub-module FTIB

BTS

LTE710: Synchronization from PDH interface

Operability

LTE724: LTE Automatic Neighbor Cell Configuration

Operability

LTE746: IP based Filtering for BTS Site Support Equipment LTE800: FlexiTransport sub-module FTLB LTE810:FLHAFlexiDualMHA2600 LTE871: Transport Support for Site Support Equipment

Operability BTS BTS Transport

LTE900: FlexiLTEBTS 40W Power support

BTS

LTE901:FlexiLTEBTS8WPowersupport

BTS

LTE903: FlexiLTEBTS 60W Power support

BTS

LTE904:FlexiLTEBTSBranchActivation

32

Operability

LTE711: Synchronization from 2.048MHz signal

©2016Nokia

BTS

DN0978045Issue:04A


Radio resource management and telecom features from previous releases for RL10

2 Radio resource management and telecom features from previous releases for RL10 2.1 LTE5: Radio bearer and S1 bearer establishment and release 2.1.1

Introduction to the feature The LTE5: Radio bearer and S1 bearer establishment and releasefeature for end-user services is a part of the basic user data management functionality. Bearer management procedures establish the default Evolved Packet System (EPS) bearer that provides an always-on service for a user offered data services.

2.1.2

Benefits The feature provides the basic user data management to the end-user.

2.1.3 2.1.3.1

Requirements Software requirements The following software is required for this feature: Table 2

Software requirements for different network elements N e t w o r k e l e me n t

R eq u i r e ds o f tw ar er e l e ase

Systemrelease

2.1.3.2

RL09

MME

NS10

SAE GW

NG10 CD2

UE

3GPP R8

NetAct

-

Hardware requirements This feature does not require any new or additional hardware.

2.1.4

Functional description When attached, the default EPS bearer is established between a UE and Evolved Packet Core (EPC). The application IP address and default EPS bearer are maintained with the state transition from ECM_IDLE to ECM_CONNECTED between UE and EPC. Currently, one default EPS bearer is supported so that a single data radio bearer and a single S1 bearer is needed per UE in ECM_CONNECTED state. The default EPS bearer is a non-GBR bearer from LTE point of view. The following eNB-related functions are included:

DN0978045Issue:04A

©2016Nokia

33


• • •


UE context setup and release between EPC and eNB S1 bearer establishment and release between EPC and eNB Radio bearer establishment and release between eNB and UE

The MME applies semi-static UE-AMBR values during the default EPS bearer setup: • • •

The AMBR has a global value without UE or subscription differentiation. The AMBR must be configured below theUE capabilities. The eNB applies the AMBR as maximum bit rate setting for the packet scheduler.

2.1.5

System impact

2.1.6

Sales information This feature belongs to Basic Software (BSW) product structure class.

2.1.7 2.1.7.1

User interface Parameters shows basic parameters related to LTE5: Radio bearer and S1 bearer establishment and release.

Table 3

Parameters for LTE5: Radio bearer and S1 bearer establishment and release

Full name (Short name)

Object

DRB Downlink Scheduling Priority (drbPrioDl)

LNBTS

Downlink Pathloss Change (dlPathlossChg)

Description

Range / Step

Default value

Downlink Scheduling priority for DRB

1...1000,

LNCEL

Trigger Condition for Power Headroom submission due to Pathloss change;

1 db (0), 3 db (1), 6 db (2), infinite (3)

Periodic BSR Time (tPeriodicBsr) LNCEL

Time period of the periodic Buffer Status Report for the reporting of the UE transmission buffer utilisation.

5ms (0), 10ms (1), 16ms 40ms (5) (2), 20ms (3), 32ms (4), 40ms (5), 64ms (6), 80ms (7), 128ms (8), 160ms (9), 320ms (10), 640ms (11), 1280ms (12), 2560ms (13), infinity (14)

Periodic PHR Timer (tPeriodicPhr)

LNCEL

UE configuration for sending periodic sounding reports.

10sf (0), 20sf (1), 50sf (2), 20sf (1) 100sf (3), 200sf (4), 500sf (5), 1000sf (6), infinity (7)

Prohibited PHR Timer (tProhibitPhr)

LNCEL

Minimum Intermediate Time within 2 consecutive Power Headroom reports.

0sf (0), 10sf (1), 20sf (2), 50sf (3), 100sf (4), 200sf (5), 500sf (6), 1000sf (7)

34

©2016Nokia

1

step 1 3 db (1)

0sf (0)

DN0978045Issue:04A


Table 3


Parameters for LTE5: Radio bearer and S1 bearer establishment and release (Cont.)


Retransmission BSR Timer (tReTxBsrTime

Object

LNCEL

Description

Time the Regular BSRs is repeated

Range / Step

Default value

320 ms (0), 640 ms (1), 2560 ms (3) 1280 ms (2), 2560 ms (3), 5120 ms (4), 10240 ms (5)

shows parameters of the AM RLC profile for DRBs. Table 4

Parameters related to the AM RLC profile for DRBs ( LTE5: Radio bearer and S1 bearer establishment and release)


Object

Description

Range / Step

Default value

AM RLC DRB Profile List (rlcProf)

LNBTS

RLC Profile for DRBs

--

--

RLC Profile Id (rlcProfileId)

LNBTS

Identity of the RLC AM profile,

0...1,

--

0 specifies an invalid, dummy profile step 1 AM RLC Poll PDU DRB (pollPdu)

LNBTS

The AM RLC Poll PDU defines the number of RLC PDUs that are sent on a logical channel before the RLC polling bit is set. Element is defined for DRB

4 (0), 8 (1), 16 (2), 32 (3), 64 (4), 128 (5), 256 (6), infinity (7)

64 (4)

AM RLC Timer Poll Retransmit DRB (tPollRetr)

LNBTS

This timer is used by the transmitting side of an AM RLC entity in order to retransmit a poll. This timer is only used when it has been activated with the AMRLCPollingTriggers.

5 (0), 10 (1), 15 (2), 20 (3), 25 (4), 30 (5), 35 (6), 40 (7), 45 (8), 50 (9), 55 (10), 60 (11), 65 (12), 70 (13), 75 (14), 80 (15), 85 (16), 90 (17), 95 (18), 100 (19), 105 (20), 110 (21), 115 (22), 120 (23), 125 (24), 130 (25), 135 (26), 140 (27), 145 (28), 150 (29), 155

120 (23)

(30), 160 (31), 165 (32), 170 (33), 175 (34), 180 (35), 185 (36), 190 (37), 195 (38), 200 (39), 205 (40), 210 (41), 215 (42), 220 (43), 225 (44), 230 (45), 235 (46), 240 (47), 245 (48), 250 (49), 300

DN0978045Issue:04A

©2016Nokia

35


Table 4


Parameters related to the AM RLC profile for DRBs ( LTE5: Radio bearer and S1 bearer establishment and release) (Cont.)


Object

Description

Range / Step

Default value

(50), 350 (51), 400 (52), 450 (53), 500 (54) AM RLC Timer Reordering DRB (tReord)

LNBTS

This timer is used by the receiving side of an AM RLC entity for reordering, PDU loss detection and delay of STATUS PDU transmission. This timer depends on HARQ RTT and number of HARQ retransmissions.

0 (0), 5 (1), 10 (2), 15 (3), 20 (4), 25 (5), 30 (6), 35 (7), 40 (8), 45 (9), 50 (10), 55 (11), 60 (12), 65 (13), 70 (14), 75 (15), 80 (16), 85 (17), 90 (18), 95 (19), 100 (20), 110 (21), 120 (22), 130 (23), 140 (24), 150 (25), 160 (26), 170 (27), 180 (28), 190 (29), 200 (30)

50 (10)

AM RLC Timer Status Prohibit DRB

LNBTS

This timer is used by the receiving

0 (0), 5 (1), 10 (2),

50 (10)

side of an AM RLC entity in order to prohibit transmission of a STATUS PDU. Element is defined for DRB.

15 (3), 20 (4), 25 (5), 30 (6), 35 (7), 40 (8), 45 (9), 50 (10), 55 (11), 60 (12), 65 (13), 70 (14), 75 (15), 80 (16), 85 (17), 90 (18), 95 (19), 100 (20), 105 (21), 110 (22), 115 (23), 120 (24), 125 (25), 130 (26), 135 (27), 140 (28), 145 (29), 150 (30), 155 (31), 160 (32), 165 (33), 170 (34), 175 (35), 180 (36), 185 (37), 190 (38), 195 (39), 200 (40), 205 (41), 210 (42), 215 (43), 220 (44), 225 (45), 230 (46), 235 (47), 240 (48), 245 (49), 250 (50), 300 (51), 350 (52), 400 (53), 450 (54), 500 (55)

(tProhib)

shows the AM RLC poll byte table.

36

©2016Nokia

DN0978045Issue:04A


Table 5


AM RLC pollByte table


ueCategory

Object

LNBTS

ulPollByte

Description

Range / Step

ueCategory

LNBTS

ForInstances:

AM RLC PollByte value in uplink direction.

Default value

For inst.:

1: 1

1: 1

2: 2

2: 2

3: 3

3: 3

4: 4

4: 4

5; 5

5; 5

25, 50, 75, 100, 125, 250, 375, 500, 750, 1000, 1250, 1500, 2000, 3000, infinity (in kByte)

For UE category: 1 : 50 2 : 250 3 : 500 4 : 750 5 ; 1000

dlPollByte

LNBTS

AM RLC PollByte value in downlink direction.

25, 50, 75, 100, 125, 250, 375, 500, 750, 1000, 1250, 1500, 2000, 3000, infinity (in kByte)

For UE category: 1 : 25 2 : 125 3 : 250 4 : 250 5 ; 375

shows parameters related to the PDCP profile. Table 6

Parameters related to the PDCP profile ( LTE5: Radio bearer and S1 bearer establishment and release)


PDCPProfileList(pdcpProf) PDCP Profile Id (pdcpProfileId)

DN0978045Issue:04A

Object

LNBTS

Description

PDCPprofile

Range / Step

--

Identity of the PDCP profile; 0 specifies an invalid dummy profile

©2016Nokia

Default value

-0...1,

--

step 1

37


Table 6


Parameters related to the PDCP profile ( LTE5: Radio bearer and S1 bearer establishment and release) (Cont.)


Object

PDCP Timer Discard (tDiscard)

Description

This parameter indicates the delay before a PDCP PDU along with the

Range / Step

Default value

50 (0), 100 (1), 150 750 (5) (2), 300 (3), 500 (4),

corresponding PDCP SDU is 750 (5), 1500 (6), discarded from the buffer. This timer infinity (7) shall be set in a way that the packet delay defined by the QCI characteristics is kept. The timer can be disabled by setting the parameter to disabled. PDCP Status Report Required (statusReportReq)

PDCP Status Report: This parameter determines whether a PDCP Status Report is sent from PDCP receiver to PDCP transmitter. The PDCP Status Report may be sent from eNB to UE (eNB PDCP Status Report) or from UE to eNB (UE PDCP Status Report). Possible settings: 00: no Status Report 01: eNB Status Report 10: UE Status Report 11: eNB and UE Status

Bit 0: eNB Status Report,

--

Bit 1: UE Status Report

Report

2.2 LTE20: Admission control 2.2.1

Introduction to the feature The LTE20: Admission controlfeature introduces a mechanism that decides on the admission of incoming calls based on the number of RRC connections and the number of connected users per cell. Handover requests can be prioritized over initial access requests with individual thresholds. Connection-based Radio Admission Control (RAC) maintains the eNB in stable operation and ensures a minimum service level for individual end users. Radio admission control applies separate thresholds for the maximum number of RRC connections and the maximum number of connected users per cell.

2.2.2

Benefits The operator-configured number of connection-based RAC maintains the eNB in stable operation, and it further manages a minimum service level per end user.

2.2.3

38

Requirements

©2016Nokia

DN0978045Issue:04A


2.2.3.1


Software requirements The following software is required for this feature: Table 7



Systemrelease

RL09

MME SAE GW

-

UE

-

NetAct

2.2.3.2

-


2.2.4

Functional description An RRC connection is established when the Signaling Radio Bearers (SRB1s) have been successfully configured. The UE is considered as RRC connected when a signaling radio bearer is established. The SRB1 establishment is checked against the threshold maxNumRc, SRB2 is admitted together with the default DRB. The number of RRC connected users (only SRB1) includes the number of activated UEs, where the UE has an SRB1, SRB2 and at least 1 DRB. Thethreshold maxNumRrc is greater than the threshold maxNumActUe. Radio admission control thresholds are operator-configurable. The upper limit for the maximum number of supported connections depends on the baseband hardware configuration of the eNB and on cell configuration parameters such as the cell bandwith. Radio admission control is triggered with SRB1 establishment and for each DRB-Setup or DRB-Release to initial access or due to handover. Possible later resource congestion is handled by the packet scheduler. For more information on packet scheduler function, see “Packet scheduler”functional area description. In RL20 it is possible to admit more than one DRB per UE if LTE7: Support of Multiple EPS bearers is activated.

2.2.4.1

Radio admission control Radio admission control admits or rejects the requests for the establishment of Radio Bearers (RBs). The scope of radio admission control is cell level.

2.2.4.1.1

Basic RAC functions (RL10) The RAC (Radio Admission Control) decision scheme bases on the following criteria:

DN0978045Issue:04A

©2016Nokia

39


•

•

•


The number of RRC-connections established in thecell does not exceed an O&M configurative threshold (Maximium Number of RRC Connections, maxNumRRC). This criterion implies that RAC is invoked for the admission of SRB1 at RRC Connection Setup. The number of active UEs in the cell may not exceed an O&M configurative threshold (Maximum Number of active UEs, maxNumActUE) . This criterion implies that RAC is invoked for the admission of the single non-GBR DRB at S1AP Initial Context Setup. When a handover message isreceived, the mobility managementfunction in the telecom control plane of the target eNB requests radio admission control to decide in an “all-or-nothing” manner on the admission/rejection of the resources used by the UE in the source cell prior to the handover. “All-or-nothing” manner means that either both signaling radio bearers AND (logical) all DRBs are admitted or rejected. For a HO (handover) both the number of RRC-connections and the number of active UEs in the cell may not exceed the respective O&M configurative thresholds (Maximium Number of RRC Connections, Maximum Number of active UEs) with the thresholds providing different priority depending on the handover cause indicated by mobility management. For the handover cause, themaxNumRrc and maxNumActUe thresholds are modified by theadditional active Ue with radio reason handover (addAUeRrHo) and additional active UE with reason time critical handover (addAueTcHo) .

2.2.4.1.2

Interaction of radio admission control with other RRM functions Radio admission control interacts with events driven functions of the Telecom control plane and associated parameters . This section provides an overview of the interactions between radio admission control and other functions. UE State Handling (UE-SH)

Upon RRC connection setup, UE state handling triggers the SRB Setup. Radio admission control responds with the decision to admit or reject the SRB setup. If the configuration of the admitted SRB1 fails in the Telecom control plane, UE state handling informs radio admission control of that by using the SRB Abort event. Upon RRC connection release, UE state handling informs radio admission control about that by using the UE Release event. Bearer Management (BM)

Upon initial context setup, bearer management triggers the DRB Setup to request the establishment of the single non-GBR data radio bearer for a UE for which the RRC connection has been successfully established. Radio admission control responds with the radio admission control decision on admission or rejection of the bearer setup. If the configuration of the admitted data radio bearer fails in the Telecom control plane, bearer management informs radio admission control about that by using the DRB Abort event. Mobility Management (MM)

In the event of a handover, the admission of the radio bearers at the target cell is carried out in an “all-or-nothing” manner, using event-driven interactions with the mobility management function of the Telecom control plane.

40

©2016Nokia

DN0978045Issue:04A



Mobility management at the target eNB requests radio admission control of the target cell to admit the UE for which a handover has been requested. No difference is made between Intra-eNodeB and Inter-eNodeB handover. Due the 'all-or-nothing' resource allocation principle, mobility management requests the establishment of both SRB1 AND the non-GBR DRB by using the HO RB Setup event. If the configuration of the admitted radio bearers fails in the Telecom control plane, mobility management inform radio admission control by using the HO Abort event. If a UE leaves the about cell due a successful handover, mobility management informs radio admission control thattoby using the HO UE Release event. Currently, a handover for a UE with SRB only is not supported. UL Scheduler (UL-S)

If a DRB Setup or a HO RB Setup has been admitted, radio admission control provides the UL packet scheduler with the following parameters: • •

Minimum bit rate required in UL Minimum Bitrate Uplink (minBitrateUl) Maximum bit rate allowed in UL Maximum Bitrate Uplink (maxBitrateUl)

DL Scheduler (DL-S)

If a DRB Setup or a HO RB Setup has been admitted, radio admission control provides the UL packet scheduler with the following parameters: •

Minimum bit rate required in DL Minimum Bitrate Downlink

•

Maximum bit rate allowed in DL Maximum Bitrate Downlink

(minBitrateDl) (maxBitrateDl) •

2.2.4.1.3

Structure containing the UE_EUTRA_capabilities

Radio admission control mechanism Radio admission control decisions are based on the following criteria: •

•

•

DN0978045Issue:04A

TheSRB1 setup request is accepted if the number of established RRC connections in the cell is less than the Maximum Number Of RRC Connections (maxNumRrc). There is no separate check for the SRB2 as it is automatically admitted/rejected with the data radio bearer. The SRB Setup, SRB abort, and UE Release event is issued by UE state handling. If the number of active UEs in the cell is less than the Maximum Number Of Active UEs (maxNumActUE), the DRB setup request is accepted. Otherwise it is rejected. The DRB Setup, DRB Abort and DRB Release events are issued by bearer management. For incoming handover requests, theradio admission control decision atthe target cell follows the 'all-or-nothing' principle. UEs entering the cell via handover are prioritized with respect to those requesting initial access. In addition, different priorities can be specified for individual handover cases. The handover request is accepted if all of the following criteria are true:

©2016Nokia

41



–

The number of established RRC connections inthe cell is less than the sum of theMaximum Number Of RRC Connections (maxNumRrc) and the margin for the handover causeadditional Active Ue with Reason Radio Reason Handover (addAUeRrHo) or additional Active Ue

–

The number of active UEs in the cell isless than the sum of the Maximum Number Of Active UEs (maxNumActUE) for native UEs and the respective bonus marginadditional Active Ue with Reason Radio Reason Handover (addAUeRrHo) or additional Active Ue with

with Reason Time Critical Handover (addAUeTcHo)

Reason Time Critical Handover (addAUeTcHo)

Otherwise the request is rejected. The HO Setup and HO Abort requests are issued by mobility management. The Maximum Number Of RRC Connections (maxNumRrc) defines the upper bound for the sum of UEs with RRC connection (UEs with established SRB1 only) and active UEs (UEs with established SRB1, SRB2 and DRB). Maximum Number Of RRC Connections (maxNumRrc) is to be set to a higher value than Maximum Number Of Active UEs (maxNumActUE).

2.2.4.1.3.1

Margin for the maximum number of active UEs in the cell accessing the cell via handover

Two operator-configurative margins can be used to prioritize UEs accessing the cell via handover while at the same time allowing to set different admission priorities depending on the handover cause: •

additional Active Ue with Reason Radio Reason Handover (addAUeRrHo)

Margin in terms of additional number of active UEs admitted in the cell on top of those defined by the maxNumActUe whenever mobility management requests cell access for a UE due to handover with the cause value "HO desirable for radio reasons". •

additional Active Ue with Reason Time Critical Handover (addAUeTcHo)

Margin in terms of additional number of active UEs admitted in the cell on top of those defined by maxNumActUe whenever mobility management requests cell access for a UE due to handover with the cause value "Time critical HO". Setting both parameters to 0 implies that no admission priority is granted for UEs accessing the cell due to handover.IfaddAUeTcHo is set to a higher value than addAUeRrH, UEs requesting cell access due to "Time critical HO" have a higher priority than those requesting cell access due to "HO desirable for radio reasons". Although it is recommended to give higher priority to time-critical handover it is up to the operator how to choose the settings for these attributes. Since active UEs accessing the cell via handover have to be served first of the UEs requesting initial access, the total number of RRC-connected and active UEs in the cell must not exceed certain maximum values representing the system capability. The maximum number of RRC-connected and active UEs per sector is scaled by the system (carrier) bandwidth.

42

©2016Nokia

DN0978045Issue:04A



The Uplink Channel Bandwidth (ulChBw) and Downlink Channel Bandwidth (dlChBw) parameters specify the bandwidth for the LBTS transmission in a cell and the number of available Physical Resource Blocks (PRBs). The channel bandwidth mapping to the number of physical resource blocks is: • • • •

5.0 MHz = 25 PRBs 10.0 MHz = 50 PRBs 15.0 MHz = 75 PRBs 20.0 MHz = 100 PRBs

The consistency can be checked for the maximum number of RRC-connected and active use per sector in 3-sector sites as follows: •

5 MHz bandwidth maxNumRrc+max(addAUeRrH, addAUeTcHo) < 200 maxNumActUe+max(addAUeRrH, addAUeTcHo) < 200

•

10 MHz bandwidth maxNumRrc+max(addAUeRrH, addAUeTcHo) < 400 maxNumActUe+max(addAUeRrH, addAUeTcHo) < 400

•

20 MHz bandwidth maxNumRrc + max(addAUeRrH, addAUeTcHo) < 800 maxNumActUe + max(addAUeRrH, addAUeTcHo) < 800.

2.2.4.1.3.2

Maximum bit rate in UL and DL

The Maximum Bitrate Selector (mbrSelector) parameter offers maximum flexibility in setting the maximum bit rate in UL and DL direction according to requirements from bearer management, mobility management, UL AMC, DL AMC, UL packet scheduler, DL packet scheduler and MIMO mode control. The Maximum Bitrate Selector (mbrSelector) parameter has the following settings: •

mbrSelector = ueCapability (0)

The maximum bit rate in UL and DL direction is specified by the throughput and MIMO capabilities of the UE included in the UE_RADIO_CAPABILITES structure provided by bearer management/mobility management. The maximum bit rate in UL and DL direction corresponds to the physical layer parameters for the UE category specified in Table 4.1-1 and Table 4.1-2 of 3GPP TS36.306. Example: UE of category 3 – –

Maximum DL bit rate: 102.048 Mb Maximum UL bit rate: 51.024 Maps

•

mbrSelector OaM (1)and DL direction are specified by the minimum out of: The maximum bit=rate in UL – –

the throughput and MIMO capabilities ofthe UE the Maximum Bitrate Downlink (maxBitrateDl) and Maximum Bitrate Uplink (maxBitrateUl) parameters

Example: UE of category 3 –

DN0978045Issue:04A

maxBitRateDl = 120 Mbps

©2016Nokia

43


– – –

2.2 2.2.5


maxBitRateUl = 20 Mbps Maximum DL bit rate: 102.048 Mbp (lower value coming from UE category) Maximum UL bit rate: 51.024 Mbps (lower value coming from the operatorconfigurable parameters)

System impact Sales information This feature belongs to Basic Software (BSW) product structure class.

2.3 LTE27: Open-loop UL Power Control and DL Power Setting 2.3.1

Introduction to the feature Open-loop uplink power control

The open-loop uplink power control is the basic power control functionality for uplink transmission. The UE adjusts its transmission power based on a downlink path loss estimate, broadcasted parameters, and uplink transmission configuration. This feature is fundamental for efficient air interface operation. Downlink power setting

In the downlink direction only a semi-static power control mechanism is applied keeping the eNB’s transmission power per unit bandwidth on the same level independently of the allocated downlink bandwidth (flat power spectral density).

2.3.2

Benefits This feature offers basic power control functionality for efficient air interface operation.

2.3.3 2.3.3.1

Requirements Software requirements Software requirements for different network elements

Table 8

Network element

Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

44

Required software release

3GPPR8mandatory

©2016Nokia

DN0978045Issue:04A



Table 8

Software requirements for different network elements (Cont.)

Network element

NetAct

2.3.3.2


–

Hardware requirements This feature does not require any additional hardware.

2.3.4 2.3.4.1

Functional description Functional details Open-loop power control

Open-loop UL power control is applied on PUSCH, PUCCH and on PRACH. PUSCH can be configured for fractional path loss compensation. The random access procedure applies power ramp-up when multiple access attempts are needed. The calculations of the UE’s transmit power are a bit different for PUSCH, PUCCH and SRS (sounding reference symbol); these are described in 3GPP TS 36.213, also including the factors for closed loop power control. In this feature, only simplified versions are valid – excluding for example, closed loop effects. Control channels and datawhile channels arepartial handled differently because for better control full compensation is desired, for data compensation may yield performance. This part includes naming as defined in 3GPP TS 36.213. O&M parameters are provided for the different components of the formulas determining the UE’s transmit power. Calculation of UE's UL transmission power for PUSCH

The UE’s transmission power PPUSCH for PUSCH transmission is limited by a configurable maximum value, and beneath this maximum P PUSCH in a subframe i is defined by: PPUSCH(i) = 10 · log10(MPUSCH(i)) + P0_PUSCH(i) +

· PL +

TF(i)

[dBm]

with: •

•

•

DN0978045Issue:04A

MPUSCH(i): The bandwidth of the allocated PUSCH resources which the subframe i belongs to, expressed in numbers of resource blocks. A larger bandwidth results in an increase of the transmission power (in order to keep the transmission power per frequency in the subframe constant). P0_PUSCH(i): An adjustable power offset used to control the averaged UL received signal power and thereby the UL signal-to-noise ratio. P 0_PUSCH(i) is the sum of a nominal value P0_NOMINAL_PUSCH(i) and the UE-specific value P0_UE_PUSCH(i). : Fractional compensationfactor enabling a flexible trade-off betweencapacity and fairness. Partial compensation of path loss ( < 1) may be tolerable for data transmission and may yield better performance (for example, = 0.8).

©2016Nokia

45


•

•


PL: The downlink path loss estimate in dB calculated in the UE. It is the difference between a reference signal power (related to the DL transmission power of the eNB, broadcast to the UE via PBCH) and the reference signal received power (RSRP) which is measured by the UE. The lower the RSRP value, the higher the path loss and the contribution of PL to the transmission power. ΔTF(i): A correction factor taking into account details of the transport format (TF) used for the subframe i (for more details, see 3GPP TS 36.213).

Calculation of UE's UL transmission power for PUCCH

The UE’s transmission power PPUCCH for PUCCH transmission is limited by a configurable maximum value, and beneath this maximum P PUCCH in a subframe i is defined by: PPUCCH(i) = P0_PUCCH(i) + PL + h(nCQI,nHARQ) + ΔF_PUCCH(F) [dBm] with: •

P0_PUCCH(i): An adjustable power value used to control the averaged UL received signal power and thereby the UL signal-to-noise ratio. P 0_PUCCH(i) is the sum of a nominal value P0_NOMINAL_PUCCH(i) and the UE-specific value P 0_UE_PUCCH(i).

•

PL: The downlink path loss estimate indB calculated in theUE. PL is given as for PUSCH. Note, that no fractional compensation factor is applied because the path loss of control data signaling is fully compensated. h(nCQI,nHARQ): A PUCCH format dependent value taking into account the different numbers of bits for CQI and HARQ (for more details, see 3GPP TS 36.213). ΔTF(i): A correction factor taking into account details of the PUCCH format (F) used

•

•

for the subframe i (for more details, see 3GPP TS 36.213). Calculation of UE's UL transmission power for SRS

The calculation of the UE’s transmission power P SRS for sounding reference symbol (SRS) transmission in a subframe i is very similar to that for P PUSCH: PSRS(i) = PSRS_OFFSET(i) + 10 · log10(MSRS) + P 0_SRS(i) +

· PL +

TF(i)

[dBm]

with: •

PSRS_OFFSET(i) defines the power offset for SRS in the UE uplink power control algorithm. Note that the actual power offset depends on the value of deltaTfEnabled.

The other naming and meaning of the parameters corresponds with those in the section for PUSCH. Downlink power setting

Downlink power control is semi-static keeping the eNB’s transmission power per bandwidth unit on the same level independently of the allocated downlink bandwidth (flat power spectral density). The flat power spectral density keeps the interference quite flat and tolerable; in the downlink direction, much less interference fluctuations occur than in the uplink direction. Hence, a dynamic downlink power control mechanism is not foreseen. Instead, the eNB’s transmission power is used in the adjustment of the cell size (configurable by the dlCellPwrRed parameter for macro cell and pMax parameter for FZM) and for coverage control.

46

©2016Nokia

DN0978045Issue:04A



The downlink power control for PDSCH takes into account the effects of adaptive MIMO and diversity modes (MIMO compensation). In FZM, the pMax parameter can be adjusted in increments of 1 dB, but requires an eNB restart. In macro cell, an online change ofdlCellPwrRed parameter is possible, but only up to 0.2dB. Every change of dlCellPwrRed results in the modification of the SI broadcast message SIB1 with respect to the systemInfoValueTag (++ mod32) and SIB2 with respect to the referenceSignalPower parameter, which provides the downlink reference signal EPRE, see TS 36.213 [23, 5.2]. The UE checks systemInfoValueTagwhen it returns from out of synchronization, to verify if the previously stored SI messages are unchanged. The UE assumes that its stored system information is valid if the value of systemInfoValueTag has not been changed and the time elapsed, since it was successfully confirmed as valid, is less than three hours. If the system information in the cell is modified more often than 31 times within three hours, the UEs may sporadically not recognize that the systemInfoValueTag has been changed during its absence (this tag has 5 bits and after 32 modifications it reaches again the same value - the UE then will not re-read the system information). Anyway if a SIB parameter is modified more often than 31 times per three hours, the changes will be accepted, however, as stated above a temporary ambiguity may arise.

2.3.5 2.3.5.1

System impacts Interdependencies between features This chapter is divided into Open-loop UL power control, Closed-loop UL power control, and Downlink power setting. Open-loop UL power control can efficiently compensate long-term variations of the radio conditions such as path loss and shadowing, but it typically suffers from errors in path loss estimations and the setting of the transmission power. Closed-loop UL power control, which takes into account eNB measurements of the received uplink signals, and exchanges data between UE and eNB, is less sensitive to errors in path loss estimations and transmit power setting; however, it degrades performance when there is no available feedback due to UL transmission pauses or decoding errors. Thus a combination of open-loop and close-loop power control gives the best results. Based on the results of filtered eNB measurements, the eNB can send power-up or power-down commands to the UE via PDCCH.

2.3.6 2.3.6.1

User interface Parameters The table shows the parameters introduced with this feature.

DN0978045Issue:04A

©2016Nokia

47


Table 9


Parameters for LTE27: Open Loop UL Power Control and DL Power Setting

Full name

DeltaFPUCCHlist

Abbreviated name

dFListPucch

Delta preamble random access message 3

Managed object

LNCEL

deltaPreMsg3

LNCEL

Enabled TB size impact to UE PUSCH power calculation

deltaTfEnabled

LNCEL

Cell power reduce (for macro cell)/maximum Output Power (for FZM)

dlCellPwrRed/pMax

LNCEL

MIMO power compensation

dlpcMimoComp

LNCEL

Filtercoefficient

filterCoeff

LNCEL

Nominal power for UE PUCCH TX power calculation

p0NomPucch

LNCEL

Nominal power for UE PUSCH TX power calculation

p0NomPusch

LNCEL

Power Offset For SRS Transmission Power Calculation

srsPwrOffset

LNCEL

Alpha

ulpcAlpha

LNCEL

TPC command in Random Access response

ulpcRarespTpc

LNCEL

2.4 LTE28: Closed loop UL power control 2.4.1

Introduction to the feature Closed loop UL power control complements the basic open loop UL power control. It is based on eNodeB’s measurements of UL signal level and quality. Of the measurement data the eNodeB determines an UL power increase or decrease step and commands the UE (user equipment) to increase or decrease the current UL transmit power by this step. Open loop power control is based on pathloss estimations of the UE and mainly static system and O&M parameters; it compensates long-term variations of the radio conditions, but typically suffers from errors in pathloss estimations. The closed loop power control strongly improves the pathloss estimations and allows optimized UL power adaption. Hence, the UE is enabled to operate with optimum power levels under varying propagation and interference conditions.

48

©2016Nokia

DN0978045Issue:04A



Actually, open loop UL power control and closed loop UL power control are combined and one formula is used to calculate the UE’s transmit power taking into account both open and closed loop power control components. Separate UL power adjustments are calculated for different PUCCH formats, SRSs (sounding reference symbols) and specific UL allocations on PUSCH. Closed loop UL power commands are sent on PDCCH. The operator enables/disables and configures closed loop power control by O&M setting. The general cell specific parameters are delivered via system information broadcasting and the UE specific parameters are delivered via RRC signalling. The Flexi Multiradio BTS supports slow closed loop uplink power control.

2.4.2 2.4.2.1

Benefits End user benefits The UE power consumption is reduced. The reduction of interference by operation with closed loop UL power control optimizes the transmission conditions within the cell in terms of speech quality and/or data rates.

2.4.2.2

Operator benefits Closed loop UL power control reduces intra-cell, inter-cell and inter-system interference. The results are improved cell edge behavior and a relaxation of requirements on intracell orthogonality.

2.4.3 2.4.3.1

Requirements Software requirements Table 10

Software requirements for different network elements

Network element


Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

3GPPrelease8

NetAct

2.4.3.2

–


DN0978045Issue:04A

©2016Nokia

49


2.4.4 2.4.4.1


Functional description Functional details Closed loop UL power control is done as follows: 1. The eNodeB measures every TTI (transmission time interval) for every PRB (physical resource block) and for all UEs, whose signals are received, the signal level (RSSI, received signal indicator) and quality signal-tointerference plus noise ratio)strength from PUCCH and/or PUSCH(SINR, depending on the O&M configuration. 2. The eNodeB processes the measurement data by • •

• •

transforming it into a transport format independent format, clipping the measurementdata (a limitation of each value in a certain range between a O&M defined minimum and maximum threshold), weighting the measurement data, filtering the measurement data (averaging filters).

3. After that, the eNodeB makes adecision about PUCCH and/or PUSCH commands by using a decision matrix with a target window for signal quality and level configured by an operator. For example, if the signal quality and level is below the lower thresholds, a power increase is initiated. 4. The new UL power is calculated. 5. PUCCH/PUSCH/SRS power commands arethen signalled to the UE via PDCCH. The command contains the power adjustments (e.g. +3 dB for PUSCH). The UE uses the closed loop power correction values as additive term to the open loop component for the calculation of its total uplink transmit power. The described UL power control scheme is applied separately for the physical uplink shared channel (PUSCH), physical uplink control channel (PUCCH) and sounding reference symbols (SRSs) with different parameter sets. The UL power control is performed independently for each particular UE in a cell. Measurements

The eNodeB measures: •

• •

RSSI (received signal strength indicator) of received signals for every UE transmitting on PUCCH or PUSCH or transmitting SRS Interference for every received PUCCH/PUSCH/SRS physical resource block (PRB) Interference for every UE transmitting via PUCCH or PUSCH

The eNodeB then calculates the related SINR values for the cell and for each UE. Power adjustment decision and determination of the power adjustment value

Separate UL power control windows for the power adjustment decision are defined for the PUSCH, SRS and PUCCH components. The UL power control window is defined by upper and lower quality and level thresholds (in a two-dimensional quality-level space the thresholds define the fields of a decision matrix). Figure 1: Power control decision matrix schematically shows the UL power control decision matrix for PUSCH and for PUCCH.

50

©2016Nokia

DN0978045Issue:04A



The required power adjustment step to be sent to the UE is given in the fields of the matrix and is called PUSCH or δ PUCCH. Figure 1

Power control decision matrix SINR

d o g

+ 1 dB or + 3 dB

- 1 dB

- 1 dB

m iu + 1 dB or d e + 3 dB m

0 dB

- 1 dB

+ 1 dB or + 3 dB

+ 1 dB or + 3 dB

medium

high

high_qual_thresh

low_qual_thresh r o o p

+ 1 dB or + 3 dB low

low_lev_thresh

RSSI

high_lev_thresh

In the formula for the UE’s calculation of the UL transmission power,PUSCH is an additive component. The UL transmission power for subframe i, PUSCH P (i), uses the power adaption value PUSCH(i – 4) which was signalled via PDCCH 4 subframes before (according to 3GPP 36.213: PUSCH(i – KPUSCH), and for FDD mode: KPUSCH = 4). is given as the current contribution to an accumulated power correction summand. In this case the summand is given by f(i) = f(i – 1) + PUSCH/PUCCH(i – 4). Another possibility (described in 3GPP 36.213) would be to give as an absolute (standalone) power correction value. The eNodeB takes care that successive power up or power down commands do not exceed an upper and a lower absolute power limit. Since closed loop UL power control takes into account the SINR conditions, SINR is not considered in open loop UL power control. Transmit power control commands

The UL power adjustment value PUSCH for PUSCH is carried within the transmit power control (TPC) command which is sent to the UE in combination with the uplink scheduling grant: Whenever a UE is scheduled, it gets a TPC command together with being informed which resources and transport format is assigned. The TPC command is included in the PDCCH with DCI format 0. Another possibility of conveying the TPC information – not implemented in the current solution – would be to use the TPC-PUSCH format, which is a special PDCCH payload and contains jointly coded UL TPC commands for a set of up to N users. In this case DCI format 3/3A would be used whose CRC parity bits are scrambled with TPC-PUSCH-RNTI. Correspondingly, the UL power adjustment value PUCCH for PUCCH is carried within the transmit power control (TPC) command which is also sent to the UE in combination with the uplink scheduling grant. Possible values for

DN0978045Issue:04A

PUSCH/PUCCH

©2016Nokia

in the accumulation case are -1 dB, 0 dB, 1 dB, 3 dB.

51



The UE attempts to decode a PDCCH of DCI format 0 with the UE's C-RNTI or SPS CRNTI and a PDCCH of DCI format 3/3A with this UE's TPC-PUSCH-RNTI in every subframe except when in DRX mode. If DCI format 0 and DCI format 3/3A are both detected in the same subframe, then the UE uses the power value provided in DCI format 0.

2.4.4.1.1

Messages and information elements Messages

UL UE specific power control parameters are included in the RRC: CONNECTION RECONFIGURATION message. It contains information elements described below. Information elements

The IE “UplinkPowerControlCommon” and IE “UplinkPowerControlDedicated” are used to specify parameters for uplink power control in the system information and in the dedicated signalling, respectively; see 3GPP TS 36.331. For example, the IE “UplinkPowerControlDedicated” is included in the “physicalConfigDedicated” IE which is included in the “radioResourceConfigDedicated” IE. The last one is a part of the RRC: CONNECTION RECONFIGURATION message. The “physicalConfigDedicated” IE also contains the “TPC-PDCCH-Config” IE which is used to specify the RNTIs and indexes for PUCCH and PUSCH power control. The power control function can either be setup or released with the IE.

2.4.5 2.4.5.1

System impacts Interdependencies between features "Closed loop UL power control" complements the feature "Open loop UL power control and DL power setting". “Closed loop UL power control” has effects on the packet scheduler. The combining of power control and resource allocation allows interference coordination to further enhance cell edge performance and allows higher overall spectral efficiency. For example, UEs with comparable pathloss in adjacent cells can be directed to transmit in the same timefrequency resource. On average, such a grouping of UEs with a similar channel quality in adjacent cells results in the best cell edge performance, because it avoids strong interference from UEs close to the eNodeB in adjacent cells. Vice versa, aligning UEs with different channel quality between cells results in a good channel quality for these UEs, hence the peak data rates and the average cell throughput can be increased.

2.4.5.2

Impacts on interfaces Regarding the radio interface, the communication between eNodeB and UE is done via RRC signalling. Cell specific UL power control parameters are included in the system information block type 1 (SIB1). General power control parameters are sent to the UE during the Initial Context Setup Request procedure. UL UE specific power control parameters are included in the RRC: CONNECTION RECONFIGURATION message (includes the “radioResourceConfigDedicated” IE which includes the “physicalConfigDedicated” IE; the last one includes the”uplinkPowerControlDedicated” IE).

52

©2016Nokia

DN0978045Issue:04A


2.4.5.3


Impacts on performance and capacity Since “Closed loop UL power control” is related to interference, the feature – combined with allocation of resources (by the packet scheduler) – improves the performance at cell edge and allows a higher overall spectral efficiency.

2.4.6 2.4.6.1

User interface Parameters The following table shows the parameters implemented for the feature. Parameters common for closed loop and open loop uplink power control are shown in the second table.

Table 11

Parameters for closed loop UL power control

Name

Enable Closed Loop Uplink Power Control

Object

LNCEL

Description

Range

This parameter allows to enable/disable closed loop uplink power control.

0 (false)

Include PUCCH LNCEL Measurements In CL Power

Including or excluding of RSSI and SINR measurements from PUCCH in the closed

0 (false)

Control (ulpcPucchEn)

loop PC component.

Include PUSCH LNCEL Measurements In CL Power Control

Including or excluding of RSSI and SINR measurements from PUSCH in the closed loop PC component.

0 (false)

Lower threshold of the power control window for the RSSI (signal level) for PUCCH component.

-127...0 dBm

Lower threshold of the power control window for the RSSI (signal level) for PUSCH/SRS component.

-127...0 dBm

Lower threshold of the power control window for the SINR (signal quality) for PUCCH component.

-47...80 dB

Default value

0

1 (true)

(ulpcEnable) 1

1 (true)

1

1 (true)

(ulpcPuschEn) Lower RSSI Threshold For PUCCH Power Command Decision

LNCEL

-103 dBM

step 1 dBm

(ulpcLowlevCch) Lower RSSI Threshold For PUSCH Power Command Decision

LNCEL

-103 dBM

step 1 dBm

(ulpcLowlevSch) Lower SINR Threshold For PUCCH Power Command Decision

LNCEL

1 dB

step 1 dB

(ulpcLowqualCch)

DN0978045Issue:04A

©2016Nokia

53


Table 11


Parameters for closed loop UL power control (Cont.)

Name

Lower SINR Threshold For PUSCH Power Command Decision

Object

LNCEL

Description

Range

Lower threshold of the power control window for the SINR (signal quality) for PUSCH/SRS component.

-47...80 dB

Upper threshold of the power control window for the RSSI (signal level) for PUCCH component.

-127...0 dBm

Upper threshold of the power control window for the RSSI (signal level) for PUSCH/SRS component.

-127...0 dBm

Upper threshold of the power control window for the SINR (signal quality) for PUCCH component.

-47...80 dB

Upper threshold of the power control window for the SINR (signal quality) for PUSCH/SRS component.

-47...80 dB

Time interval for sending averaged RSSI and SINR values to the decision matrix to determine power corrections in closed loop uplink power control.

10...2000 ms

Default value

8 dB

step 1 dB

(ulpcLowqualSch) Upper RSSI Threshold For PUCCH Power Command Decision

LNCEL

-98 dBM

step 1 dBm

(ulpcUplevCch) Upper RSSI Threshold For PUSCH Power Command Decision

LNCEL

-98 dBm

step 1 dBm

(ulpcUplevSch) Upper SINR Threshold For PUCCH Power Command Decision

LNCEL

4 dB

step 1 dB

(ulpcUpqualCch) Upper SINR Threshold For PUSCH Power Command Decision

LNCEL

11 dB

step 1 dB

(ulpcUpqualSch) Time Interval For Power Command Decisions

LNCEL

(ulpcReadPeriod)

Table 12

50 ms

step 10 ms

Parameters common for open and closed loop UL power control

Name

Object

Description

Enabled TB Size Impact To LNCEL UE PUSCH Power Calculation

This parameter enables/disables a transport format dependent offset on a per UE basis. In case that this parameter is enabled, PUSCH

(deltaTfEnabled)

power calculation in UE uplink power control equation (P1) takes the transport block size in account during power calculation.

DeltaF PUCCH Format 1 (dFpucchF1)

LNCEL

This parameter parameter defines the deltaF PUCCH Format 1.

Range

0 (false),

Default value

1

1 (true)

0 (-2),

1

1 (0), 2 (2)

54

©2016Nokia

DN0978045Issue:04A



Parameters common for open and closed loop UL power control (Cont.)

Table 12

Name

Object

DeltaF PUCCH Format 1b

LNCEL

(dFpucchF1b)

Description

This parameter parameter defines the deltaF PUCCH Format 1b.

Range

0 (1),

Default value

0

1 (3), 2 (5)

DeltaF PUCCH Format 2

LNCEL

(dFpucchF2)

This parameter parameter defines the deltaF PUCCH Format 2.

0 (-2),

1

1 (0), 2 (1), 3 (2)

DeltaF PUCCH Format 2a

LNCEL

(dFpucchF2a)

This parameter parameter defines the deltaF PUCCH Format 2a.

0 (-2),

1

1 (0), 2 (2)

DeltaF PUCCH Format 2b

LNCEL

(dFpucchF2b)

This parameter parameter defines the deltaF PUCCH Format 2b.

0 (-2),

1

1 (0), 2 (2)

Filter Coefficient (filterCoeff)

LNCEL

This parameter specifies the filtering coefficient used for RSRP (3GPP: TS 36.331)

0 (fc0),

4

1 (fc1), 2 (fc2), 3 (fc3), 4 (fc4), 5 (fc5), 6 (fc6), 7 (fc7), 8 (fc8), 9 (fc9), 10 (fc11), 11 (fc13), 12 (fc15), 13 (fc17), 14 (fc19)

2.4.6.2

Measurements and counters There are no measurements and counters related to this feature.

DN0978045Issue:04A

©2016Nokia

55


2.4.7


Activating The Feature This feature needs activation. For instructions see Activating the LTE28:Closed loop UL power control.

2.4.8 2.4.8.1

Abbreviations 0–Z

A xxx

2.5 LTE30: CQI adaption (DL) 2.5.1

Introduction to the feature CQI (channel quality indicator) is an indicator of the current downlink channel conditions as seen by the UE. In LTE, the user equipment (UE) reports CQIs to assist the eNodeB in selecting an appropriate modulation and coding scheme (MCS) to be used for the downlink transmission. A high CQI value is indicative of a channel with high quality. The UE determines the CQI value from the downlink received signal quality, typically based on measurements of the downlink reference signals. A CQI value reported from the UE may not be reliable enough for the eNodeB selecting a modulation and coding scheme to achieve a certain (low) block error rate (BLER) for downlink data transmission. Therefore the eNodeB adjusts the reported CQI value by taking into account ACK/NACK (acknowledged / not acknowledged) reports from the UE for received downlink data blocks (e.g. NACK is sent if the UE could not successfully decode a received data block). This process is called CQI adaptation. The adjusted CQI value is used by the AMC (adaptive modulation and coding) algorithm, which is a component of the link adaptation functionality within the eNodeB, to select the optimum MCS for the following downlink data transmission.

2.5.2

Benefits CQI adaptation compensates user equipment measurement errors (yielding to suboptimal CQI values reported to the eNodeB) and allows to achieve a configurable DL target block error rate (BLER).

2.5.3

56

Requirements

©2016Nokia

DN0978045Issue:04A


2.5.3.1


Software requirements Table 13


Network element


Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

3GPPrelease8

NetAct

2.5.3.2

–


2.5.4 2.5.4.1

Functional description Functional details CQI adaptation is the adjustment of the reported CQI value in the eNodeB with an adapted offset before link adaptation by AMC (adaptive modulation and coding) is applied in downlink direction. This functionality compensates user equipment measurement errors and allows to achieve a configurable DL target block error rate (BLER). Figure 2: Principle of CQI adaptationshows how the offset value CQI is calculated and applied. CQI adaptation is also called outer loop quality control (OLQC): An UL ACK/NACK report and the following DL transmission, whose MCS is influenced by the previous ACK/NACK report and which determines the next UL ACK/NACK report, form a loop.

DN0978045Issue:04A

©2016Nokia

57


Figure 2


Principle of CQI adaptation

Data blocks Packet scheduler

DL link adaptation: Select MCS

(PDSCH) Evaluate reference signals

CQI adaptation

CQI report

CQI reported

CQIreported + ΔCQI = CQIcorrected

(PUCCH/PUSCH) ACK

Decode transport blocks

ACK/NACK (PUCCH/PUSCH)

1st DL transport block transmissions

NACK

UE

ΔCQI(t-1) + CQI stepup

= ΔCQI(t)

ΔCQI(t-1) + CQI

= ΔCQI(t)

stepdown

Additionally: Δ CQI between CQI max and CQI min eNodeB

The CQI offset is determined in the eNodeB with the help of the incoming ACK/NACK responses from the UE (via L1/L2 control signaling) for the initial transmission of each transport block in DL direction. For a correct received transport block the offset value ΔCQI is increased by a step CQI stepup whereas for an incorrect transport block the value is decreased by CQIstepdown. No change is done when no ACK/NACK is available or in case of a retransmission of the corresponding transport block (there are some other specific conditions where CQI is not changed). The parameters CQIstepup and CQIstepdown are chosen in a way that a certain block error rate target value (BLERtarget) is reached. The offset value CQI lies between a maximum and minimum value.

2.5.5 2.5.5.1

System impacts Interdependencies between features CQI adaptation is closely related to the feature LTE31 “Link adaptation by AMC (UL/DL)”: The selection of the appropriate modulation and coding scheme for DL transmission by the AMC (adaptive modulation and coding) algorithm is based on the adjusted CQI value. For more information, see the functional area description “Link control”.

2.5.6 2.5.6.1

User interface Parameters The following table shows the parameters implemented for the feature “LTE30: CQI adaption (DL)”.

58

©2016Nokia

DN0978045Issue:04A


Name

dlOlqcEnable


Object

LNCEL

Description

Range

This parameter allows to enable/disable CQI adaption (i.e. downlink outer loop link quality control).

false(0)

Default value

true(1)

Other parameters for this feature are internal or vendor-specific.

2.5.7

Activating The Feature This feature requires activation. For instructions see Activating the LTE30:CQI Adaption.

2.6 LTE31: Link Adaptation by AMC (UL/DL) 2.6.1

Introduction to the feature AMC (adaptive modulation and coding) dynamically adjusts the modulation and coding scheme for PDSCH and PUSCH in order to match the prevailing radio conditions for each user. AMC maintains the optimum working point for the hybrid automatic repeat request (HARQ) process under varying traffic load and radio propagation conditions. Furthermore, the adaptive transport bandwidth (ATB) function defines the maximum resource in the UE.allocation for uplink in the constraint according to the reported power headroom AMC is an essential radio link control function for optimizing air interface efficiency.

2.6.2

Benefits Link adaptation is the most essential radio link control function for optimizing air interface efficiency.

2.6.3 2.6.3.1



Network element

DN0978045Issue:04A


Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

©2016Nokia

59


Table 14



Network element


UE

3GPPR8mandatory

NetAct

2.6.3.2

–


2.6.4 2.6.4.1

Functional description Functional details AMC link adaptation

Adaptive modulation and coding (AMC) dynamically matches the information data rate for each user to the variations in the received signal quality. AMC can select between different modulation schemes and code rates. •

•

Modulation scheme: Low-order modulation (that is few data bits per modulated

symbol, for example, QPSK) is more robust and can tolerate higher levels of interference but provides a lower transmission rate. High-order modulation (that is more bits per modulated symbol, for example, 64QAM) offers a higher bit rate but is more prone to errors due to its higher sensitivity to interference, noise, and channel estimation errors. Thus, high-order modulation is useful only when the SINR is sufficiently high. Code rate: A lower code rate is used in case of poor channel conditions and a higher code rate in case of high SINR. Generally, a lower code rate is connected with a greater overhead for error correction.

The combination of modulation and code rate results in modulation and coding schemes (MCSs), which are standardized, see 3GPP TS 36.213 listing the MCSs (MCS0 – MCS28) and relating them to a modulation scheme and a transport block size. There are separate relations between MCS number, modulation scheme and transport block size for uplink and downlink direction. Hence, AMC means the dynamic optimization of the utilized MCS. The same MCS is applied on all physical resource blocks belonging to one transport block (which is the data unit for one UE and one subframe after processing in the media access control (MAC) layer), that is the MCS is constant over the allocated frequency resources for a given user and time (subframe) and the MCS for this user can change only in the next subframe. In addition, when two transport blocks are transmitted to one user in a given subframe using multi-stream MIMO, each transport block can use an independent MCS. AMC is performed independently in the uplink (for PUSCH) and downlink direction (for PDSCH). Adaptive modulation and coding on PDSCH

60

©2016Nokia

DN0978045Issue:04A



The AMC algorithm for PDSCH is based on the UE’s CQI reports and includes the following main characteristics: •

•

•

•

•

•

•

The O&M provides an initial modulation andcoding scheme, which isused as the default modulation and coding scheme. In case AMC is not activated, the algorithm always uses this default MCS. Retransmissions are handled differently from initial transmissions. For a HARQ retransmission, the same MCS is used as for the corresponding initial transmission. The MCS determined for an initial transmission therefore is remembered as long as HARQ retransmissions are performed for the same block of data. An average channel state (that is an average CQI value) is internally determined from the received CQI information corresponding to the physical resource blocks having been assigned by the scheduler. CQI adaptation (adjustment of thereported CQI value inthe eNB based on BLER measurements (ACK/NACK events)) is applied if enabled. The eNB interpolates the target code ratebased on the averaged CQI over selected resource blocks for a UE with a new transmission. Afterwards, the eNB selects the suitable MCS based on the target code rate and the number of scheduled resource blocks. The basis for the MCS selection is a mapping table like in 3GPP TS 36.213. For spatial multiplexing (dual stream MIMO mode), where separate CQI values are available for both transmission paths, the eNB separately determines the MCS for each transmission path and the two MCSs can be different. For diversity (single stream MIMO mode), the eNB determines one common MCS for both transmission paths, since the input is only one averaged CQI value. If no new CQI value is received from a UE and the UE is scheduled nevertheless, the eNB multiplies the old CQI value by a configurable factor, and the MCS is determined as described above provided the latest available CQI information is not older than a configurable maximum time period; if this maximum period is already exceeded (or CQI values are not yet available), the initial MCS is applied.

MCSs called MCS0 and MCS2 to MCS28 are available in DL direction according to 3GPP TS 36.213. MCS0 to MCS9 have QPSK modulation, MCS10 to MCS16 have 16QAM modulation, and MCS17 to MCS28 have 64QAM modulation. So the most robust MCS is MCS0 and the least robust is MCS28. From a more general view, DL AMC consists of an inner and an outer loop component. The inner loop component is formed by an UE’s CQI report and the following eNB’s downlink transmission whose MCS is influenced by the CQI report. The outer loop component is the CQI adaptation. Adaptive modulation and coding on PUSCH

The following mechanisms are applied on PUSCH: •

•

DN0978045Issue:04A

A slow inner loop component based on the BLER of all transport blocks transmissions (first transmissions and also retransmissions) within a configurable time period derived from the HARQ process. ACK/NACK events (periodic information from L1/L2; UL HARQ process) are counted and the result is used to determine the BLER. An average BLER is calculated and from this an optimum MCS is derived. The inner loop AMC takes into account BLER thresholds for MCS upgrade and downgrade by configurable parameters. A fast outer loop component based on the ACK/NACK reports of 1sttransport blocks transmission derived from the HARQ process. This part provides emergency downgrade and fast upgrade events. The target BLER for first transport blocks transmissions is configurable. In this part a compensation value is calculated.

©2016Nokia

61


•


Whenever the compensation value reaches the related configurable threshold, the AMC immediately switches to the next lower/upper (that is more/less robust) MCS. The related parameters have to be configured carefully depending on the configured target BLER, so that a certain number of consecutive NACKS triggers the MCS upgrade/downgrade. The ATB functionality which takesinto account both uplink power control related limitations (especially the UE power headroom report) as well as QoS related "minimum/maximum uplink bit rate" provided by admission control. Power headroom reports from the UE impact the ATB. ATB calculates UE-specific upper physical resource block allocation limits per transmission time interval (TTI) and reports them to the packet scheduler, which itself provides a very fast ATB within those boundaries.

MCSs called MCS0 and MCS2 to MCS20 are available up to 16QAM modulation in UL direction according to 3GPP TS 36.213. The 3GPP document provides further MCSs for 64QAM UL transmission. The feature LTE829: Increased Uplink MCS Rangecan extend the range of MCSs used for 16 QAM UEs (cat1- cat4) beyond MCS20 to MCS21MCS24. In this case the UE uses the 16-QAM modulation with less coding. MCS0 to MCS10 have QPSK modulation and MCS11 to MCS24 have 16QAM modulation. The most robust MCS is MCS0 and the least robust is MCS24.

2.6.5 2.6.5.1

System impacts Interdependencies between features There are no interdependencies between this and any other feature.

2.6.6 2.6.6.1

User interface Parameters The table shows the parameters introduced with this feature. Table 15

Parameters for LTE31: Link Adaptation by AMC (UL/DL)

Full name

Periodic subband CQI cycles K Enable simultaneous CQI and ACK/NACK

62

Abbreviated name

cqiPerSbCycK cqiPerSimulAck

Managed object

LNCEL LNCEL

EnableOLQC

dlOlqcEnable

LNCEL

DLtargetBLER

dlTargetBler

LNCEL

DefaultCQI

dlamcCqiDef

LNCEL

EnableDLAMC

dlamcEnable

LNCEL

©2016Nokia

DN0978045Issue:04A


Table 15


Parameters for LTE31: Link Adaptation by AMC (UL/DL) (Cont.)

Full name

PDCCH aggregation level for preamble assignments Rank Indication Reporting Enable

Abbreviated name

pdcchAggPreamb

riEnable

Managed object

LNCEL

LNCEL

ULAMCtargetBLER

ulTargetBler

LNCEL

Enable all TBs in UL AMC

ulamcAllTbEn

LNCEL

UL AMC MCS switch period

ulamcSwitchPer

ULATBperiod

ulatbEventPer

LNCEL LNCEL

2.7 LTE37: Ciphering and LTE38: Integrity protection 2.7.1

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 security for the radio access network is described (in other words:The air link security). This feature description LTE37: Ciphering and LTE38: Integrity protection consists user data security between UE and eNodeB for radio layer 2 (u-plane data) and 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 signalling) and user plane data and it is used in order 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. Flexi Multiradio BTSspecifications supports ciphering for the planeTS36.331 PDUs and the RRC PDUs The according to the 3GPP TS 36.300, TSuser 36.323, and TS36.401. The keys used for ciphering and integrity protection of traffic (data / control signalling) 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 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

DN0978045Issue:04A

©2016Nokia

63



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) 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, he can use a NULL-algorithminstead.

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. From3GPPview no integrity protection NULLalgorithm is available. But in extension to 3GPP- completely explained by the LTSI-forum there a IP-NULL-algorithm is implemented. This extension can only be used if the MME is configured to do so, such it can not be used by accident.

2.7.2

Benefits Ciphering and integrity protection in the access stratum (AS) provides security of the air interface and protects against attacks and eavesdropper.

2.7.3 2.7.3.1



Network element

Systemrelease

RL10

eNodeB

LBTS1.0

MME

NS10CD2

SAE GW UE NetAct

64


– 3GPPrelease8 –

©2016Nokia

DN0978045Issue:04A


2.7.3.2



2.7.4 2.7.4.1

Functional description Functional overview Figure 3: C-plane security and Figure 4: 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 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. C-plane security

Figure 3

integrity protected, ciphered

NAS

RRC

integrity protected ciphered

RRC

integrity protected

S 1 AP / X 2 A P

L3

PDCP

L2

S1AP

ciphered

AP

SCTP

SCTP

PDCP

L4

. . .

. . .

UE

NAS

IPv4/IPsec

IPv4/IPsec L3

...

eNB

.

.

.

MME

integrity protected, ciphered RRC

X 2 AP

..

..

AP: Application Layer L2, L3, ...: Layer 2, Layer 3, ...

eNB

Figure 4

U-plane security

Data stream

PDCP . . .

Data stream

ciphered

PDCP L2

GTP-U

AP

. . .

UDP

integrity protected ciphered

GTP-U

GTP-U

ciphered

UDP

UDP

IPv4/IPsec

IPv4/IPsec

L4

IPv4/IPsec L3

. . .

UE

integrity protected

eNB

. . . S-GW

. . . P-GW

integrity protected, ciphered

PDCP

GTP-U

. . .

. . .

eNB

AP: Application Layer L2, L3, ...: Layer 2, Layer 3, ...

C-plane security includes the following characteristics: • •

DN0978045Issue:04A

NAS signalling protection is transparent for the eNodeB. NAS signalling is ciphered and integrity protectedbetween UE and MME.

©2016Nokia

65


•

• • •


RRC integrity protection and ciphering is applied to NAS messages carried by RRC messages in addition to the NAS signalling security between MME and UE. This results in double protection of NAS signalling. RRC signalling is always integrity protected by PDCP in the eNodeB and in the UE. RRC signalling is ciphered between UE and eNodeB by PDCP. S1AP signalling is ciphered and integrity protected between eNodeBand MME by an underlying transport security mechanism. This is an seperate feature (LTE689) and describedt into FAD: IPsec operation. It is an optional feature.

•

X2AP signalling is protected in the same way as S1AP signalling. The security described by LTE:37/LTE38 is always between UE and eNodeB. If there is data forwarding from an source-eNodeB to a target eNodeB there will be transport security activated.

2.7.4.2

Security keys Various security keys are used for ciphering and integrity protection of traffic depending on the type of traffic (user data / control signalling) 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:

•

KUPenc for encryption of user plane traffic KRRCenc for encryption of control plane traffic (which is RRC signalling)

•

KRRCint for integrity protection of control plane traffic

•

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 K ASME . The NAS keys K NASenc and KNASint are also derived from KASME . Figure 5: 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 K ASME 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 srcin 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 K eNB* and NH are described in the related chapters.

66

©2016Nokia

DN0978045Issue:04A



Figure 5

Security key hierarchy HSS

UE

K

CK

K

IK

CK

IK

MME

K ASME

K ASME

K NASint

Keys for NAS signalling

K NASenc

K ASME

K NASint K NASenc

NAS area AS area K eNB

K eNB

K eNB

eNB K UPenc

AS keys for

K RRCint K RRCenc

C-plane and U-plane traffic

K UPenc K RRCint K RRCenc

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 exists always; it is the only permanent key. The NAS keys K ASME , KNASenc, KNASint and CK, IK exist while the EMMREGISTERED state is ongoing. The AS keys K eNB, K UPenc, 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

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. K ASME is derived from CK, IK and the PLMN ID; the HSS transfers K ASME to the MME. AKA is a NAS procedure and does not have any prerequisite besides the permanent key K.

DN0978045Issue:04A

©2016Nokia

67



•

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 signalling security. NAS SMC needs a valid K ASME 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, K eNB 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 ASME K . 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 K UPenc, KRRCint, and KRRCenc from KeNB. These keys are needed for user plane encryption and RRC integrity protection and encryption. AS SMC needs a valid eKNB 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 K ASME key. Later, several KASME may be known by network and UE. For example, while the RRCCONNECTED state is still ongoing, NAS may apply a new K ASME (by executing another NAS security mode command). In this case there is the old K ASME , from which NAS and AS keys are still derived, and the new K ASME , 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 signalled at NAS level only, i.e. during the Authentication and Key Agreement procedure and NAS security mode command procedure. At AS level the KSI is not signalled. 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 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 signalled 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 K eNB* and transmits this key via X2 interface to the target eNodeB. Then the target eNodeB deriveseNB K from KeNB*.

68

©2016Nokia

DN0978045Issue:04A



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 K eNB from the new target K eNB. 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 availabe 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 handovers with each transport K eNB* derived directly from the previous K eNB form a chain with backward security only. A handover where the transport eNB K * 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 signalled by the MME; NCC has the value 0 at the initial security context setup.

2.7.4.3

Messages and information elements The following table shows the messages which include relevant security information and their security related content:

Table 17

Security related messages and information elements

Message

Information element

IE includes

RRC messages

SECURITY MODE COMMAND

“securityConfigSMC”

“securityAlgorithmConfig” IE (“cipheringAlgorithm” and “integrityProtAlgorithm”)

RRC CONNECTION REESTABLISHMENT REQUEST

“ue-Identity”

shortMAC-I

RRC CONNECTION RECONFIGURATION

“securityConfigHO”

“keyChangeIndicator” (not processed by the eNodeB) “nextHopChainingCount” “securityAlgorithmConfig” (“cipheringAlgorithm” and “integrityProtAlgorithm”; only necessary in case of algorithm changes)

DN0978045Issue:04A

©2016Nokia

69


Table 17


Security related messages and information elements (Cont.)

Message

RRC MOBILITY FROM EUTRA COMMAND

Information element

IE includes

“nasSecurityParamFromEUTR A”

S1AP messages

INITIAL CONTEXT SETUP REQUEST

“UE Security Capabilities” “Security Key”

“HandoverPreparationinformation” IE such as ciphering and integrity protection information of the serving cell and the “targetCellShortMAC-I” Initial security key KeNB

HANDOVER REQUIRED

“RRC Context”

HANDOVER REQUEST

“RRC Context”

“HandoverPreparationinformation” IE such as ciphering and integrity protection information of the serving cell and the “targetCellShortMAC-I” (see above)

“UE Security Capabilities”

(see below)

“SecurityContext”

NH parameter NCC related to NH.

HANDOVER COMMAND

“NAS Security Parameters from E-UTRAN”

PATH SWITCH REQUEST

“UE Security Capabilities”

PATH SWITCH REQUEST ACKNOWLEDGEMENT

“SecurityContext”

“HandoverPreparationinformation” such as ciphering and integrity protection information of the serving cell and the “targetCellShortMAC-I” Supported encryption and integrity protection algorithms in two 2-bit representations. NH parameter NCC related to NH.

X2AP messages

HANDOVER REQUEST

“UE Context Information”

“ RRC Context” “UE Security Capabilities” “AS Security Information” (transition key KeNB* and NCC)

2.7.5

70

System impacts

©2016Nokia

DN0978045Issue:04A


2.7.5.1


Interdependencies between features An additional security feature is the optional LTE689 “LTE IPsec support” which allows secure eNodeB control and secure bulk data communication between eNodeBs as well as between eNodeBs and core nodes. IPsec is related to transport and application protocols. Supported IPsec capabilities are data integrity protection, srcin authentication and anti-replay protection.

2.7.5.2

Impacts on network elements A secure environment is required in the network elements storing security keys. The Flexi Multiradio BTS provides such a secure environment.

2.7.5.3

Impacts on system performance and capacity Security mechanisms are associated with processing effort and additional control data according to common laws.

2.7.6 2.7.6.1 Table 18

User interface Parameters

Parameters for ciphering and integrity protection


Ciphering Algorithm Activation

Object

false (0), true (1)

true (1)

LNBTS

A list of supported AS ciphering algorithms. The algorithm is identified by the parameter name, and the assigned value determines the algorithm preference.

–

–

LNBTS

A list of supported AS integrity protection algorithms. The algorithm is identified by the parameter name, and the assigned value determines the algorithm preference.

–

–

LNBTS

This parameter defines a threshold for PDCP COUNT supervision. If the remaining COUNT space becomes less than this threshold, the eNodeB key hierarchy will be refreshed.

0 ... 4 294 96 7 295,

50 000

(integrityPrefL)

Key Refresh Margin (keyRefrMarg)

DN0978045Issue:04A

Default value

This parameter allows to enable/disable the optional ciphering algorithms.

(cipherPrefL)

Integrity Protection Algorithm Preference List

Range / Step

LNBTS

(actCiphering) Ciphering Algorithm Preference List

Description

©2016Nokia

step 1

71


Table 18


Parameters for ciphering and integrity protection (Cont.)


Object

Null Ciphering Algorithm Fallback

LNBTS

(nullFallback)

2.7.7

Description

This parameter determines if a fallback to Null ciphering caused by eNodeB limitations is accepted (true) or not (false).

Range / Step

false (0), true (1)

Default value

true (1)

Activating The Feature The feature LTE37: ciphering requires activation. For instructions see Activating the LTE37:Ciphering.

2.8 LTE39: System Information Broadcast 2.8.1

Introduction to the feature The system information is structured through SIBs. Each SIB contains a set of parameters. The system information is composed of a master information block (MIB) and a number of SIBs. The types of SIBs described in this document are the SIB1-SIB8 and SIB10-13. Handling of the system information is part of the radio resource control (RRC) protocol.

2.8.2

Benefits The SIB message is necessary for cell access and mobility support. It is broadcast containing information elements from the non-access stratum (NAS) and radio network to all user equipment (UE).

2.8.3 2.8.3.1



Network element

Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

72


3GPPR8mandatory

©2016Nokia

DN0978045Issue:04A



Table 19


Network element

NetAct

2.8.3.2


–


2.8.4 2.8.4.1

Functional description Functional details The system information (SI) contains data used for making decisions regarding cell selection, reselection, or handover. It is sent from the eNodeB to all UEs in RRC_IDLE or RRC_CONNECTED mode. The RRC protocol broadcasts the system information containing information elements from the eNodeB to all UEs. The system information is repeated on a regular basis with variable repetition frequency depending on specified parameters. The RRC protocol performs scheduling and repetition of system information messages. This function supports broadcast of core network specific, radio access network specific and cellspecific information. A system information is consists of the following: •

•

•

Master information block (MIB): TheMIB includes a limited number of the most essential and most frequently transmitted parameters that are needed to acquire other information from the cell, and is transmitted on BCH with a periodicity of 40 ms. System information blockType 1: SIB1 (which contains alsoscheduling information for the SIs). It is scheduled with a periodicity of 80 ms and transmitted on the DSCH. System Information Messages: All other SIBs to be transmitted are mapped onto SIs. The following are mapping restrictions: the SIB2 has to be contained in the first SI in the scheduling information list (contained in SIB1 - according to 3GPP) and each SI message contains just 1 SIB type.

The following information is contained in each of the supported SIB: •

• • •

•

•

•

DN0978045Issue:04A

SIB1: SIB1 contains information relevant when evaluating ifa UE is allowed to access a cell and defines the scheduling of other system information blocks. SIB2: SIB2 contains common and shared channel information. SIB3: SIB3 contains cell re-selection information, mainly related to the serving cell. SIB4: SIB4 contains information aboutthe serving neighboring frequencies andintrafrequency neighboring cells relevant for cell re-selection. SIB5: SIB5 contains information about other E-UTRAN frequencies and inter frequency neighboring cells relevant for cell reselection. SIB6: SIB6 contains information aboutUTRA frequencies andUTRA neighboring cells relevant for cell reselection. SIB7: SIB7 contains information about GERAN frequencies relevant for cell reselection.

©2016Nokia

73


•

• • • •

2.8.5 2.8.5.1


SIB8: SIB8 contains information aboutCDMA2000 frequencies and CDMA2000 neighboring cells relevant for cell re-selection. SIB10: SIB10 containsEarthquake and Tsunami Warning System (ETWS) primary notification. SIB11: SIB11 contains ETWS secondary notification SIB12: SIB12 contains Commercial Mobile Alert System (CMAS) notification. SIB13: SIB13 contains the information required to acquire the MBMS control information.


2.8.6 2.8.6.1


Parameters for LTE39: System Information Broadcast

Full name

Abbreviated name

Structure

cdfimId

CDFIM

CDMA2000 HRPD Band Class List

hrpdBdClList

CDFIM

Structure

CDMA2000 HRPD Band Class

hrpdBdClBcl

CDFIM

hrpdBdClList

CDMA2000 HRPD Cell Reselection Priority

hrpdCResPrio

CDFIM

hrpdBdClList

CDMA2000 HRPD Reselection High Threshold

hrpdFrqThrH

CDFIM

hrpdBdClList

CDMA2000 HRPD Reselection Low Threshold

hrpdFrqThrL

CDFIM

hrpdBdClList

CDMA2000 HRPD Neighbour Cell List

hrpdNCList

CDFIM

Structure

CDMA2000 HRPD Frequency hrpdArfcn CDMA2000 HRPD Band Class

74

Managed object

CDMA2000 frequency idle mode configuration identifier

hrpdBdClNcl

©2016Nokia

CDFIM CDFIM

hrpdNCList hrpdNCList

DN0978045Issue:04A


Table 20


Parameters for LTE39: System Information Broadcast (Cont.)

Full name

Abbreviated name

Managed object

Structure

CDMA2000 HRPD Physical Cell Identity

hrpdCellId

CDFIM

hrpdNCList

CDMA2000 HRPD NCL extension selector

hrpdExSel

CDFIM

hrpdNCList

CDMA2000 1xRTT band class rttBdClList list

CDFIM

Structure

CDMA2000 1xRTT band class rttBdClBcl BCL

CDFIM

rttBdClLis

CDMA2000 1xRTT cell reselection priority

CDFIM

rttBdClLis

CDMA2000 1xRTT reselection rttFrqThrH high threshold

CDFIM

rttBdClLis

CDMA2000 1xRTT reselection rttFrqThrL low threshold

CDFIM

rttBdClLis

CDMA2000 1xRTT neighbour

CDFIM

Structure

rttCResPrio

rttNCList

cell list CDMA2000 1xRTT frequency

DN0978045Issue:04A

rttArfcn

CDFIM

rttNCList

CDMA2000 1xRTT band class rttBdClNcl (NCL)

CDFIM

rttNCList

CDMA2000 1xRTT physical cell identity

rttCellId

CDFIM

rttNCList

CDMA2000 1xRTT NCL extension selector

rttExSel

CDFIM

rttNCList

CDMA Search Window Size

searchWinSize

CDFIM

CDMA2000 HRPD Cell Reselection Timer

tResHrpd

CDFIM

Speed Dep Scaling Treselection HRPD Factors

tResHrpdSF

CDFIM

Structure

HRPD Cell Reselection Timer Factor High Mobility

hrpResTiFHM

CDFIM

tResHrpdSF

HRPD Cell Reselection Timer Factor Med Mobility

hrpResTiFMM

CDFIM

tResHrpdSF

©2016Nokia

75


Table 20


Full name

Abbreviated name

Managed object

Structure

CDMA2000 1xRTT cell reselection timer

tResRtt

CDFIM

Speed dep scaling factors treselection 1xRTT

tResRttSF

CDFIM

Structure

1xRTT cell reselection timer factor high mobility

rttResTiFHM

CDFIM

tResRttSF

1xRTT cell reselection timer factor med mobility

rttResTiFMM

CDFIM

tResRttSF

GFIMIdentifier

76


gfimId

GFIM

GERAN Cell Reselection Timer

tResGer

GFIM

Speed dependent Scaling Factors Treselection GERAN

tResGerSF

GFIM

Structure

GERAN Cell Reselection Timer Factor High Mobility

gerResTiFHM

GFIM

tResGerSF

GERAN Cell Reselection Timer Factor Medium Mobility

gerResTiFMM

GFIM

tResGerSF

GERAN Frequency Band Indicator

bandInd

GNFL

GERAN RAT Carrier Frequency Absolute Priority

gCelResPrio

GNFL

ARFCN Value List

gerArfcnVal

GNFL

GERAN Inter Frequency Threshold High

gerFrqThrH

GNFL

GERAN Inter Frequency Threshold Low

gerFrqThrL

GNFL

GNFLIdentifier

gnflId

GNFL

NCC Permitted Bit Map

nccperm

GNFL

GERAN Maximum Allowed Transmit Power

pMaxGer

GNFL

GERAN Minimum Required Receive Level

qRxLevMinGer

GNFL

©2016Nokia

DN0978045Issue:04A


Table 20



Full name

Abbreviated name

IAFIMIdentifier

iafimId

Structure

IAFIM

Intra-Frequency Blacklisted Cell List

intrFrBCList

IAFIM

Structure

Number Of PCI In The Intra Frequency Range

rangeIntraPci

IAFIM

intrFrBCList

Lowest PCI In The Intra Frequency Range

startIntraPci

IAFIM

intrFrBCList

Intra-Frequency Neighbouring Cell List

intrFrNCList

IAFIM

Structure

Physical Cell Identifier In Neighbouring Cell List

physCellIdNcl

IAFIM

intrFrNCList

Cell Reselection Procedure Offset

qOffsetCell

IAFIM

intrFrNCList

dlCarFrqEut

IRFIM

EUTRA Frequency Value

DN0978045Issue:04A

Managed object

EUTRA Carrier Frequency Absolute Priority

eutCelResPrio

IRFIM

Inter-Frequency Blacklisted Cell List

intFrBCList

IRFIM

Structure

Number Of PCI In The Inter Frequency Range

rangeInterPci

IRFIM

intFrBCList

Lowest PCI In The Inter Frequency Range

startInterPci

IRFIM

intFrBCList

Inter-Frequency Neighbouring Cell List

intFrNCList

IRFIM

Structure

Physical Cell Identifier In Neighbouring Cell List

physCellIdNcl

IRFIM

intFrNCList

Cell Reselection Procedure Offset

qOffCell

IRFIM

intFrNCList

EUTRA Inter Frequency Threshold High

interFrqThrH

IRFIM

EUTRA Inter Frequency Threshold Low

interFrqThrL

IRFIM

©2016Nokia

77


Table 20


Full name

Abbreviated name

Managed object

EUTRA Presence Antenna Port1

interPresAntP

IRFIM

EUTRA Cell Reselection Timer

interTResEut

IRFIM

IRFIMIdentifier

78


irfimId

Structure

IRFIM

Allowed Measurement Bandwidth

measBdw

IRFIM

Pmax Neighbouring EUTRA Cells

pMaxInterF

IRFIM

EUTRA Frequency Specific Offset

qOffFrq

IRFIM

Minimum Required Rx RSRP Level

qRxLevMinInterF

IRFIM

Speed dependent Scaling tResEutSF Factors Treselection EUTRAN

IRFIM

Structure

EUTRA Cell Reselection Timer Factor High Mobility

eutResTiFHM

IRFIM

tResEutSF

EUTRA Cell Reselection Timer Factor Medium Mobility

eutResTiFMM

IRFIM

tResEutSF

Access class barring for srcinating calls

acBarOc

LNCEL

Structure

Access class barring list for mobile srcinating calls

ocAcBarAC

LNCEL

acBarOc

Access class barring time for srcinating calls

ocAcBarTime

LNCEL

acBarOc

Access probability factor for srcinating calls

ocAcProbFac

LNCEL

acBarOc

Access barring for signaling

acBarSig

LNCEL

Strucure

Access class barring list mobile src signaling

sigAcBarAC

LNCEL

acBarSig

Access class barring time for signaling

sigAcBarTime

LNCEL

acBarSig

©2016Nokia

DN0978045Issue:04A


Table 20



Full name

Abbreviated name

Managed object

Structure

Access probability factor for signaling

sigAcProbFac

LNCEL

Additional spectrum emission mask

addSpectrEmi

LNCEL

Intra Frequency Reselection Timer EUTRA

celResTiF

LNCEL

Structure

Cell Reselection Timer Factor High Mobility

celResTiFHM

LNCEL

celResTiF

Cell Reselection Timer Factor Medium Mobility

celResTiFMM

LNCEL

celResTiF

Cell barred flag

cellBarred

LNCEL

Cell reselection priority

cellReSelPrio

LNCEL

Default Paging Cycle

defPagCyc

LNCEL

Access Barred For Emergency eCallAcBarred

acBarSig

LNCEL

Calls Further PLMN Identity List

furtherPlmnIdL

LNCEL

Cell Reserved For Operator Use

cellReserve

LNCEL

furtherPlmnIdL

MobileCountryCode

mcc

LNCEL

furtherPlmnIdL

MobileNetworkCode

mnc

LNCEL

furtherPlmnIdL

Mobile Network Code Length

m ncLength

LNCEL

Group assignment for PUSCH grpAssigPUSCH

LNCEL

Hopping mode of PUSCH

hopModePusch

LNCEL

Intra Frequency Cell

intrFrqCelRes

LNCEL

intraPresAntP

LNCEL

furtherPlmnIdL

Reselection Allowed Presence Antenna Port1

Modification Period Coefficient modPeriodCoeff Maximum Number Of Out-OfSync Indications

DN0978045Issue:04A

n310

©2016Nokia

LNCEL LNCEL

79




Table 20

Full name

Abbreviated name

Maximum Number Of In-Sync Indications

n311

Number Of Transmission Antenna Ports

numOfTxPorts

LNCEL

Pmax Intra Frequency Neighbouring E-UTRA

pMaxIntraF

LNCEL

Max Uplink Transmission Power Own Cell

pMaxOwnCell

LNCEL

PagingnB

pagingNb

LNCEL

prachHsFlag

LNCEL

Power ramping step

prachPwrRamp

LNCEL

Preamble Transmission Maximum

preambTxMax

LNCEL

Cell reserved for operator use

primPlmnCellres

LNCEL

Cell reselection procedure hysteresis value

qHyst

LNCEL

qRxLevMinOffset

LNCEL

Minimum Required RX Level in the cell

qrxlevmin

LNCEL

Min Required RX level for intra-freq neighbouring cells

qrxlevminintraF

LNCEL

Intra Frequency Measurements Threshold

sIntrasearch

LNCEL

Inter Frequency And Inter RAT sNonIntrsearch Measurements Threshold SI Window Length

siWindowLen

Structure

LNCEL

PRACH high speed flag

QRX level min. offset

80

Managed object

LNCEL

LNCEL

System Information 2 Scheduling

sib2Scheduling

LNCEL

Structure

Periodicity

siMessagePeriodici ty

LNCEL

sib2Scheduling

©2016Nokia

DN0978045Issue:04A




Table 20

Full name

Managed object

LNCEL

Structure

Repetition

siMessageRepetitio n

Message Mapping

siMessageSibType

LNCEL

sib2Scheduling

System Information 3 Scheduling

sib3Scheduling

LNCEL

Structure

Periodicity


LNCEL

sib3Scheduling

Repetition


LNCEL

sib3Scheduling

Message Mapping

siMessageSibType

LNCEL

sib2Scheduling

sib3Scheduling

System information scheduling sibSchedulingList list

LNCEL

Structure

Periodicity


LNCEL

sibSchedulingLis t

Repetition


LNCEL

sibSchedulingLis t

SIB type

siMessageSibType LNCEL

sibSchedulingLis t

Speed Dependent Reselection spStResPars Structure

LNCEL

Structure

Number Cell Changes High Mobility

nCellChgHigh

LNCEL

spStResPars

Number Cell Changes Medium Mobility

nCellChgMed

LNCEL

spStResPars

Cell Reselection Hysteresis High Mobility

qHystSfHigh

LNCEL

spStResPars

Cell Reselection Medium Mobility Hysteresis

qHystSfMed

LNCEL

spStResPars

TimerTCRmax

tEvaluation

LNCEL

spStResPars

Timer TCRmaxHyst

tHystNormal

LNCEL

spStResPars

TimerT300

DN0978045Issue:04A

Abbreviated name

t300

©2016Nokia

LNCEL

81



Table 20

Full name

Abbreviated name

Managed object

TimerT301

t301

LNCEL

TimerT310

t310

LNCEL

TimerT311

t311

LNCEL

Cell reselection timer

tReselEutr

Trackingareacode

tac

Threshold Serving Low

threshSrvLow

Preamble initial received target power

ulpcIniPrePwr

UTRA Cell Reselection Timer

tResUtra

Structure

LNCEL LNCEL LNCEL LNCEL

UFFIM

Speed dependent Scaling Factors Treselection UTRAN

tResUtraSF

UFFIM

Structure

UTRA Cell Reselection Timer Factor High Mobility

utrResTiFHM

UFFIM

tResUtraSF

UTRA Cell Reselection Timer Factor Medium Mobility

utrResTiFMM

UFFIM

tResUtraSF

UFFIM Identifier

82


uffimId

UFFIM

List Of UTRA Carrier Frequencies

utrFddCarFrqL

UFFIM

Structure

UTRA downlink frequency value

dlCarFrqUtra

UFFIM

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 frequency threshold high

utraFrqThrH

UFFIM

utrFddCarFrqL

©2016Nokia

DN0978045Issue:04A




Table 20

Full name

Abbreviated name

UTRA inter frequency threshold low

g

utraFrqThrL

Managed object

UFFIM

Structure

utrFddCarFrqL

Note: For the SIB1 scheduling list, the parameters for SIB2 ( sib2Scheduling

parameter structure) and SIB3 (sib3Scheduling parameter structure) are provided. For all other SIBs (SIB4, SIB5, SIB6, SIB7, SIB8, SIB10, SIB11, and SIB12), the sibSchedulingList parameter structure exists with one entry per SIB used.

2.9 LTE40: Physical and Transport Channels 2.9.1

Introduction to the feature The LTE40: Physical and Transport Channelscovers the following features: • • • • • • •

2.9.2

definition of the uplink (UL) and downlink (DL) physical and transport channels structure of the physical channels, frame format, and physical resource elements physical shared channelin the UL and DL synchronization signals physical layer management coding radio link failure detection basedon the channel quality indicator (CQI) discontinuous transmission (DTX) detection

Benefits The physical layer functionality is supported.

2.9.3 2.9.3.1



Network element

DN0978045Issue:04A


Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

©2016Nokia

83


Table 21



Network element


UE

3GPPR8mandatory

NetAct

2.9.3.2

–


2.9.4 2.9.4.1

Functional description Functional details Transport channels

The evolved node B (eNodeB) supports the following transport channels: •

•

•

•

•

•

Broadcast channel (BCH): The BCH is a DL BCH that is used to broadcast the necessary system parameters to enable the UEs to access the system (and to identify the operator). The BCH broadcasts in the entire coverage of a cell. Paging channel (PCH): The PCH is used for carrying the paging information forthe UE in the DL direction to move the UE from RRC_IDLE to RRC_CONNECTED. The PCH broadcasts in the entire coverage of a cell Random access channel (RACH): TheRACH is used in the UL to respond the paging message or to initiate the move from/to RRC_CONNECTED state according to UE data transmission needs. Downlink shared channel (DSCH): The DSCH carries user data for point-to-point connections in the DL direction. All the information (either user data or higher layer control information) is intended only for one user or UE is transmitted on the DSCH. Uplink shared channel (USCH): The USCH carries user data as well as UE srcinated control information in the UL direction. Multicast channel (MCH): The MCH transfers information from one device or point to multiple devices or multiple receiving points.

Physical channels Downlink physical channels

The eNodeB supports the following DL physical channels: •

•

84

Physical broadcast channel (PBCH): The PBCH carries the primary system information (for example: MIB) transport block from the BCH. The eNodeB performs the scrambling, modulation, layer mapping, and precoding on the PBCH. The PBCH is mapped onto the fixed frequency and time resource in a slot. Physical control format indicator channel, PCFICH: The PCFICH is transmitted from the eNodeB to the UE and is mapped onto a set of resource element groups in the first orthogonal frequency-division multiplexing (OFDM) symbol in every subframe.

©2016Nokia

DN0978045Issue:04A


•

•

•

•


The control format indicator (CFI) is mapped onto the PCFICH. The PCFICH carries information of the number of OFDM symbols (1, 2 or 3) used for transmission of physical downlink control channels (PDCCHs) in a subframe. Physical hybrid ARQ indicator channel (PHICH): The PHICH is supported and therefore transmitted from the eNodeB to the UE. The PHICH carries the HARQ ACK/NACK for USCH transmission. The hybrid ARQ indicator (HI) is mapped onto the PHICH. The eNodeB supports normal duration of the PHICH. Physical downlink control channel (PDCCH): The PDCCH is transmitted from the eNodeB to the UE in every transmission time interval (TTI) via the air interface on an aggregation of one up to eight control channel elements (CCEs). Physical downlink shared channel (PDSCH): If data is available, the PDSCH is transmitted from the eNodeB to the UE in every TTI via the air interface. The PDSCH carries transport blocks from the DSCH and paging channel (PCH). The eNodeB performs the scrambling, modulation, layer mapping, and precoding on the PDSCH. The PDSCH is mapped onto the scheduled frequency and time resource. Physical multicast channel (PMCH): The PMCH transfers information from a source to one or more devices within the radio coverage area.

Uplink physical channels

The eNodeB supports the following UL physical channels: •

•

•

Physical random access channel (PRACH): The PRACH is transmitted from the UE to the eNodeB and carries a preamble sequence selected from a cell specific set of signature sequences. The eNodeB supports the reception of the preamble format 0, 1, 2, and 4. Physical uplink control channel (PUCCH): The PUCCH is transmitted from the UE to the eNodeB. The uplink control information (UCI) is mapped onto PUCCH. The PUCCH carries the CQI or precoding matrix indicator (PMI), rank indicator (RI), and ACK/NACK information for DSCH transmission and scheduling request (SR). Physical uplink shared channel (PUSCH): The PUSCH is transmitted from the UE to the eNodeB. The PUSCH carries one UL transport block per TTI per UE. It is also time/frequency multiplexed with the UL control signal (CQI and ACK/NACK) if the UE is scheduled in the UL.

In addition to the DL and UL physical channels, the following physical signals are supported: • • • • • •

primary and secondary synchronization signals, DL cell-specific reference signal, DL positioning reference signal (PRS), DL demodulation reference signal (DMRS), UL sounding reference signal, UL MBMS reference signal, DL

Mapping

Table 22: Uplink: Mapping of transport channels onto the physical channels. and Table 23: Downlink: Mapping of transport channels onto the physical channels. show the mapping between the transport and physical channels.

DN0978045Issue:04A

©2016Nokia

85


Table 22


Uplink: Mapping of transport channels onto the physical channels.

Transport channel

Physical channel

UL-SCH

PUSCH

RACH

PRACH

Control information

UCI

PUCCH,PUSCH

Table 23

Downlink: Mapping of transport channels onto the physical channels.

Transport channel

DL-SCH

Physical channel

PDSCH

BCH

PBCH

PCH

PDSCH

MCH

PMCH

Control information

HI

PHICH

DCI

PDCCH

CFI

PCFICH

PBCH is only used for transporting the MIB. The remaining system information is scheduled into PDSCH. The downlink control information (DCI) carries the DL and UL scheduling information and controls other dedicated physical layer procedures. The UCI includes: • • • • •

ACK/NACK CQI PMI (supported along with closed loop multiple inputs multipleoutputs (MIMO)) RI SR

LTE applies OFDM in the DL and SC-OFDMA (single carrier orthogonal frequency division multiple access) in the UL. The subcarrier spacing is 15 KHz in a unicast mode. The synchronization and reference signals support 504 unique physical cell identities. The eNodeB supports the following physical channel processing according to the physical channel type [3GPP TS 36.211]:

86

©2016Nokia

DN0978045Issue:04A


• • • •


scrambling modulation precoding layer mapping

The PDSCH and PUSCH apply adaptively quadrature phase shift keying (QSPK) and 16-quadrature amplitude modulation (16-QAM) modulations. On PDSCH and PUSCH, a further adaptation to 64-QAM can be enabled through an O&M configuration. The other physical channels and signals mostly apply QPSK with the exception of PUCCH applying QPSK and binary phase shift keying (BPSK) and PHICH applying BPSK. The Flexi Multiradio BTS supports the DCI formats 0, 1, 1A, 1C, 2, and 2A. Resource allocations of type 0 and 2 are supported. The reception of the preamble formats 0 and 1 are supported. The eNodeB supports the following coding functions according to the transport channel type or to control information type [3GBB TS 36.212]: • • • • •

cyclic redundancy check (CRC) code block segmentation channel coding rate matching interleaving

The following coding schemes are applied depending on data type:

•

tail biting convolutional codes (CC) convolutional turbo codes (TC) Reed-Muller block coding

• •

repetition coding simplex coding

• •

2.9.5 2.9.5.1


2.9.6 2.9.6.1


Parameters for LTE40: Physical and transport channels

Full name

DN0978045Issue:04A

Abbreviated name

Managed object

Delta cyclic shift for PUCCH

deltaPucchShift

LNCEL

Downlink Channel Bandwidth

dlChBw

LNCEL

EARFCNDownlink

earfcnDL

LNCEL

©2016Nokia

87


Table 24


Parameters for LTE40: Physical and transport channels (Cont.)

Full name

Abbreviated name

EARFCNUplink

earfcnUL

Managed object

LNCEL

Maximum Number of OFDM Symbols for maxNrSymPdcch PDCCH

LNCEL

ACK/NACK offset

LNCEL

n1PucchAn

PUCCHbandwidthforCQI

nCqiRb

LNCEL

MaximumOutputPower

pMax

LNCEL

PHICHDuration

phichDur

LNCEL

PHICHResource

phichRes

LNCEL

Physical Layer Cell Identity

phyCellId

LNCEL

PRACHCyclicShift

prachCS

LNCEL

PRACH Configuration Index

prachConfIndex

LNCEL

PRACH Frequency Offset

prachFreqOff

LNCEL

PUCCH cyclic shift for mixed formats

pucchNAnCs

LNCEL

Number Of Random Access Preambles RACHRootSequence

raNondedPreamb

LNCEL

rootSeqIndex

Synchronization Signals Transmission Mode

LNCEL

syncSigTxMode

LNCEL

SRS bandwidth configuration

srsBwConf

LNCEL

UplinkChannelBandwidth

ulChBw

LNCEL

Uplink Reference Signals Cyclic Shift

ulRsCs

LNCEL

2.10 LTE41: PDCP, RLC and MAC support 2.10.1

Introduction to the feature The PDCP, RLC, and MAC are the layer 2 protocols of the radio interface: •

88

Packet data convergence protocol (PDCP): The main functions of PDCP are encryption and integrity protection (C-plane only).

©2016Nokia

DN0978045Issue:04A


Radio link control (RLC): The RLC protocol is responsible for segmenting and concatenation of the packet data convergence protocol-protocol data units (PDCPPDUs) for radio interface transmission. It also performs error correction with the automatic repeat request (ARQ) method. Medium access control (MAC): The MAC layer is responsible for scheduling the data according to priorities, and multiplexing the data to the layer 1 transport blocks. The MAC layer also provides error correction with hybrid ARQ (HARQ).

•

•

2.10.2


Benefits The feature provides an efficient L2 functionality for data services.

2.10.3 2.10.3.1



Network element


Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

3GPPR8mandatory

NetAct

2.10.3.2

–


2.10.4 2.10.4.1

Functional description Functional details Overview

The radio layer 2 is split into the following sublayers: medium access control (MAC), radio link control (RLC) and packet data convergence protocol (PDCP).

DN0978045Issue:04A

©2016Nokia

89


Figure 6


Layer 2 downlink, transmitting side

In the DL direction, the PDCP and RLC sublayers provide the data transfer services from the radio bearers to the logical channels. The MAC sublayer provides the data transfer services on the logical channels which are mapped onto the transport channels. In the UL direction, the MAC sublayer uses the data transfer services provided by the physical layer on the transport channels. The transport channels are mapped to logical channels. The RLC and PDCP sublayers provide the data transfer to the radio bearers. An overview of the UL direction is given in Figure 7: Layer 2 uplink, receiving side. Figure 7

90

Layer 2 uplink, receiving side

©2016Nokia

DN0978045Issue:04A



MAC sublayer

The following are the main functions of the MAC sublayer: • • • • • • • •

mapping between logical channels and transport channels scheduling information reporting error correction through HARQ priority handling between logical channels of one UE priority handling between UEs through dynamic scheduling transport format selection logical channel prioritization (UE) time alignment

The eNodeB maps the logical channels to the transport channels in the DL as shown in Table 26: Mapping of logical channels onto transport channels in DL . Mapping of logical channels onto transport channels in DL

Table 26

Logical channel

MIBofBCCH

Transport channel

BCH

dynamic system information of BCCH PCCH

DL-SCH PCH

CCCH

DL-SCH

DCCH

DL-SCH

DTCH

DL-SCH

MTCH

MCCH

The eNodeB maps the transport channels to the logical channels in the UL as shown in Table 27: Mapping of transport channels onto logical channels in UL . Table 27

Mapping of transport channels onto logical channels in UL

Transport channel

Logical channel

UL-SCH

ULCCCH,ULDCCH,ULDTCH

UL-RACH

nologicalchannel

HARQ is an error detection and correction procedure. It is located in the MAC sublayer. The Flexi Multiradio BTS applies incremental redundancy in retransmission. The HARQ procedure is applied for common control channel (CCCH), dedicated control channel (DCCH), and dedicated traffic channel (DTCH).

DN0978045Issue:04A

©2016Nokia

91



The MAC-sublayer supports control and configuration procedures for DRX functionality with long DRX cycles. RLC sublayer

The following are the main functions of the RLC sublayer: • • •

• • • • • •

transfer of upper layer protocol data units (PDUs) error correction through ARQ (only for AM data transfer) concatenation, segmentation andreassembly of RLC service data units (SDUs) (not valid with TM transfer) resegmentation and reassembly of RLC data PDUs (only for AM data transfer) in-sequence delivery of upper layer PDUs (not valid with TM transfer) duplicate detection (not valid with TM transfer) SDU discard (not valid with TM transfer) RLC re-establishment protocol error detection and recovery

The RLC can operate in three modes: •

•

•

Transparent Mode (TM):In the TM mode, the RLC only delivers and receives the PDUs on a logical channel but does not add any headers to it and thus, no track of received PDUs is kept between the receiving and the transmitted entity. Unacknowledged Mode (UM): Inthe UM mode of RLC operation, the RLC provides more functionality including in-sequence delivery of data which might be received out of sequence. Acknowledged Mode (AM):In addition to UM, with AM, the RLC provides the retransmission if PDUs are lost as a result of operations in the lower layers.

For BCCH, PCCH, and DL CCCH using TM data transfer, the TM RLC transmitting entity in the eNodeB forms the RLC PDU from the whole RLC SDU only when a transmission opportunity has been notified by a lower layer and is then delivered to the lower layer. Neither segmentation nor concatenation is done on RLC SDU to form the RLC PDU. No RLC PDU header is attached to the transparent mode data (TMD) PDU. For UL CCCH using TM data transfer, the TM RLC receiving entity in the eNodeB delivers the whole TMD PDU (=RLC SDU) to the upper layer. No deconcatenation and reassembling is done on TMD PDU to form the RLC SDU. For the AM and UM RLC operations, the RLC layer receives data from the PDCP layer, the data are stored in the transmission buffer and then, based on the resources available, segmentation or concatenation is used. For control purposes, in both directions (UL and DL) in UM 5 and 10 bit sequence number (SN) is used. In AM only 10 bit sequence number is used. When the receiving entity gets a RLC PDU, it checks for possible duplicated parts and then forwards a RLC PDU for reassembly (assuming no SNs are missing in between) and provides data to the next protocol layer (in this case PDCP) for further processing. In the AM, the transmitter polls status report in a continuous manner and the receiver sends the ACKs and NACKs of the RLC PDUs and the RLC PDU segments. This proceeding controls the data transfer in DL and UL. Thus the eNodeB polls the status reports in DL and the eNodeB has to send the status reports to the UE whenever the UE asks for the report.

92

©2016Nokia

DN0978045Issue:04A



RLC UM is applied for EPS bearers with QCI 1-4. RLC AM can be applied for EPS bearers with QCI 4-9. PDCP sublayer

The main functions of the PDCP sublayer include: •

•

• •

• • • • •

header compression anddecompression of IP data flows using the ROHC protocol at the transmitting and receiving entity, respectively (for EPS bearers with QCI 1) transfer of data (U-plane or C-plane data): This function is used to convey data between users of PDCP services. maintenance of PDCP sequence numbers forradio bearers mappedon RLC AM duplicate detection oflower layer SDUs at handover for radio bearers mapped on RLC AM in-sequence delivery ofupper layer PDUs at handover ciphering and deciphering of U-plane data and C-plane data integrity protection and integrity verification of control plane data timer based discard active queue management (LTE1680: Active Queue Management)

The PDCP can be split up into U-plane and C-plane usage as shown inFigure 8: PDCP U-plane and C-plane. Figure 8

PDCP U-plane and C-plane

The SN assignment of NACKed PDCP Sequence Numbers is limited to a maximum number of 2048. Forset theup U-plane, ciphering per SAE is performed. A separate PDCPu be for each SAE bearer. Thebearer U-plane traffic is mapped to RLCu SAP.entity must For the C-plane, integrity and ciphering protection are performed for SRB1 and SRB2 after the security mode command (SMC) procedure. The PDCPc is transparent for SRB0 signaling messages using the CCCH logical channel, that is no integrity and ciphering is performed at all. The C-plane traffic is mapped to RLCc SAP.

2.10.5

DN0978045Issue:04A

System impacts

©2016Nokia

93


2.10.5.1


Interdependencies between features There are no interdependencies between this and any other feature.

2.10.6 2.10.6.1

User interface Parameters Table 28: Parameters for LTE41: PDCP, RLC and MAC supportshows the parameters for LTE41: PDCP, RLC, and MAC Support. Table 28

Parameters for LTE41: PDCP, RLC and MAC support

Parameter name

Managed object

Cell Scheduling Request Periodicity

cellSrPeriod

LNCEL

Dedicated SR Transmission Maximum

dSrTransMax

LNCEL

Maximum Number Of Message 3 HARQ Transmissions

harqMaxMsg3

LNCEL

Maximum Number Of HARQ Transmission In DL

harqMaxTrDl

LNCEL

Maximum Number Of HARQ Transmission In UL

harqMaxTxUl

LNCEL

InactivityTimer

inactivityTimer

LNCEL

InitialMCSInDownlink

iniMcsDl

LNCEL

InitialMCSInUplink

iniMcsUl

LNCEL

Initial Amount Of PRBs In Uplink

iniPrbsUl

Maximum Content Resolution Timer

LNCEL

raContResoT

LNCEL

Large size random access MCS in uplink raLargeMcsUl

LNCEL

RA Message Power Offset For Group B Selection

raMsgPoffGrB

LNCEL

Random Access Preambles Group A Size

raPreGrASize

LNCEL

Random Access Response Window Size ra RespWinSize

LNCEL

Scheduling request indication enable

LNCEL

TimeAlignmentTimer

94

Abbreviated name

sriEnable taTimer

©2016Nokia

LNCEL

DN0978045Issue:04A



2.11 LTE43: Support of 64 QAM in DL, LTE788: Support of 16 QAM (UL), LTE793: Support of 16 QAM (DL) 2.11.1

Introduction to the feature The srcinal bit streams in the eNodeB and in the UE are digital. To send them via radio antenna they must be converted to analogous waveform. This is done by modulation. The basic modulation method is QPSK for robust transmission on PUSCH and PDSCH. On top there are higher order modulations with QAM (quadrature amplitude modulation) - which are the content of this feature description. This feature description comprises the following features: • • •

2.11.2

LTE793:”Support of 16QAM (DL)” LTE788:”Support of 16QAM (UL)” LTE43:”Support of 64QAM in DL”

Benefits The benefits of the features are: 16QAM: Increase of the peak rate by 100% compared to QSPK, around 70% increased spectral efficiency. 64QAM(DL) : Increase of the DL peak rate by 50% as compared to 16QAM scenario. Figure 9: Throughput for different modulation schemesgives a short overview of the throughput of different modulation schemes. The figure is valid for a bandwidth of 20Mhz.

DN0978045Issue:04A

©2016Nokia

95


Throughput for different modulation schemes

Figure 9

Throughput, MIMO TxDiv (2x2), PedA 3 km/h, ML CE

7

7


x 10

E-UTRAN 4-QAM Rc=1/2 E-UTRAN 4-QAM Rc=3/4 E-UTRAN 16-QAM Rc=1/2 E-UTRAN 16-QAM Rc=3/4 E-UTRAN 64-QAM Rc=2/3

6

5 s t t 4 u p g u ro

3

. g v

2

1

0 -10

2.11.3 2.11.3.1

-5

0

SNIR 5(dB)

10

15

20

Requirements Software requirements The following software is required for these features: Table 29


Network element

Systemrelease

RL09

eNodeB

64QAM: LBTS0.5, 16QAM: –

UE

2.11.3.2


3GPPrelease8


2.11.4

96

Functional description

©2016Nokia

DN0978045Issue:04A


2.11.4.1


Functional details Quadrature amplitude modulation (QAM) is one of the widely used modulation schemes, which changes (modulates) the amplitude of two othogonal sinusoidal carrier waves depending on the input bits as follows

where I(t) and Q(t) are the modulating signal amplitudes, f is the carrier frequency. In a graphical representation (I-Q-plane) the I- and Q- amplitudes are arranged in a square grid with equal vertical and horizontal spacing. 16QAM consists of a 4 x 4 grid of (I,Q)-points, 64QAM consists of a 8 x 8 grid. Figure 10

QAM modulation 16QAM 4 bits/symbol

64QAM 6 bits/symbol

Q

Q

I

I

In case of downlink direction the QAM (both 16QAM and 64QAM) is used by link adaption and coding for PDSCH (physical downlink shared channel), in case of uplink direction the 16QAM is used by adaptive modulation for PUSCH (physical uplink shared channel).

2.11.5 System impacts 2.11.5.1

Interdependencies between features LTE31:” Link adaptation by AMC” describes how QAM is deployed by link adaption.

2.11.6 Sales information These features are optional.

2.11.7

DN0978045Issue:04A

User interface

©2016Nokia

97


2.11.7.1


Managed objects The managed object class LNCEL is used. Attribute of it is the parameter dl64QamEnable. Parent of LNCEL is LNBTS.

2.11.7.2 Table 30

Parameters

Parameters for LTE43: Support of 64QAM in DL

Name

dl64QamEnable

2.11.7.3

Object

LNCEL

Description

Range

Enables/disables downlink 64 QAM modulation for link adaptation use in PDSCH.

false, true

Default value

–

Measurements and counters The following counters are defined for the feature LTE43:”Support of 64QAM in DL” Table 31

Counters for LTE43

Network element name

98

Database ID

Description

HarqAck16QAM_Dl

47244

Downlink HARQ Acks received.

HarqOkRetr1_16QAM_Dl

47247

DL-SCH TBs acknowledged at the 1st retransmission.


47251

DL-SCH TBs acknowledged at the 2nd retransmission.


47255

DL-SCH TBs acknowledged at the 3rd retransmission or later.

HarqSizeOrig16QAM_Dl

47261

Total size of original transmissions of DLSCH TBs.

HarqSizeRetr16QAM_Dl

47264

Total size of retransmissions of DL-SCH TBs.

HarqSizeOk16QAM_Dl

47258

Total size of acknowledged DL-SCH TBs.

TbSchOrig16QAM_Dl

47270

Number of original transmissions of transport blocksHARQ on DL-SCH.

TbSchRetr16QAM_Dl

47273

Number of HARQ retransmissions of transport blocks on DL-SCH.

TbSchNoHarq16QAM_Dl

47267

Number of transmitted transport blocks on DL-SCH without HARQ. For these blocks, the HARQ counters shall not be updated.

©2016Nokia

DN0978045Issue:04A


Table 31


Counters for LTE43 (Cont.)


DN0978045Issue:04A

Database ID

Description

HarqAck64QAM_Dl

47245



47248



47250



47253


HarqSizeOrig64QAM_Dl

47259

Total size of original transmissions of DLSCH TBs.

HarqSizeRetr64QAM_Dl

47262


HarqSizeOk64QAM_Dl

47256


TbSchOrig64QAM_Dl

47268

Number of original HARQ transmissions of transport blocks on DL-SCH.

TbSchRetr64QAM_Dl

47271


TbSchNoHarq64QAM_Dl

47265


HarqAckQPSK_Dl

47246


HarqOkRetr1QPSK_Dl

47249


HarqOkRetr2QPSK_Dl

47252


HarqOkRetr3QPSK_Dl

47254


HarqSizeOrigQPSK_Dl

47260

Total SCH size TBs.of original transmissions of DL-

HarqSizeRetrQPSK_Dl

47263


HarqSizeOkQPSK_Dl

47257


©2016Nokia

99


Table 31

Counters for LTE43 (Cont.)


2.11.8


Database ID

Description

TbSchOrigQPSK_Dl

47269

Number of original HARQ transmissions of transport blocks on DL-SCH.

TbSchRetrQPSK_Dl

47272


TbSchNoHarqQPSK_Dl

47266


Activating The Features Thess features require activation. For instructions see Activating the LTE793: Support of 16QAM (DL), Activating the LTE788: Support of 16QAM (UL) , Activating the LTE43: Support of 64QAM in DL.

2.11.9 Abbreviations 2.11.9.1

0–Z

3GPP third generation partnership project

AMC adaptive modulation and coding

CQI channel quality indicator

DL downlink

HARQ hybrid automatic repeat request

LBTS land based test side

100

©2016Nokia

DN0978045Issue:04A



LTE long term evolution

MCS modulation and coding scheme

MIMO multiple input multiple output

PDSCH physical downlink shared channel

PUSCH physical uplink shared channel

QAM quadrature amplitude modulation

QPSK quadrature phase shift keying

Rc Rate code for channel coding

UE user equipment

UL uplink

SCH synchronization channel

DN0978045Issue:04A

©2016Nokia

101



SNIR signal to noise and interference ratio

TB transport block

TTI transmission time interval

2.12 LTE49: Paging 2.12.1

Introduction to the feature UE terminated service requests for connection with an UE in LTE_IDLE state. The paging functionality consists of two components: • •

Paging on S1 via S1AP Paging on Uu via RRC

The paging messages are scheduled in the time domain. The scheduling is based on UE-specific DRX settings. The eNode B supports cell specifc tracking areas (TA).

2.12.2

Benefits The LTE system can contact the UE when the core network gets a request for a connection to it from another device.

2.12.3 2.12.3.1

Requirements Software requirements The following software is required for the feature: Table 32


R e q u i r e d s o f t w a r e r e l e as e

Systemrelease

RL09

MME

NS10

SAE GW

-

NetAct

2.12.3.2

-

Hardware requirements This feature has no particular hardware requirements.

102

©2016Nokia

DN0978045Issue:04A


2.12.4


Functional description Functional overview

Paging is a network-initiated procedure to find and contact a UE. A UE which is in idle mode and attached to the LTE network regularly listens to the broadcasted paging messages. When the UE detects a message intended to it, it initiates an access procedure to connect to the network. As a result of a successful connect procedure, a radio bearer is established and the state of the UE changes into RRC_CONNECTED. The functional description part for paging describes the message flow applied and the paging messages involved. Additionally, the discontinuous reception mechanism is explained by which the UE has to monitor only a small fraction of subframes of a radio frame to detect paging indications. Paging is initiated by the MME as a function of the NAS – non access stratum. The MME sends paging messages via S1 interface to the relevant eNBs. The eNodeBs are determined by the tracking areas (maintained in the MME) where the UE is expected to be located. In the eNodeBs and between UE and eNodeB, paging is included in the RRC (radio resource control) protocol which is a part of the AS – access stratum). There are several reasons why the network needs to contact a UE, the most common one being that downlink data to be delivered to a UE arrives at the S-GW (serving gateway), another reason is for example the indication of a system configuration change. In order to contact a UE, a paging procedure is initiated. In case of arriving DL data at the S-GW, the S-GW requests the MME (mobility management entity) to page the UE. The MME then triggers a paging procedure as it is responsible for UE tracking. Its role involves control, execution, and supervision of the procedure. These functions are realized using the S1AP protocol. The MME starts paging by distributing a PAGING message to all eNodeBs (E-UTRAN NodeB) that are related to cells corresponding to the UE's registered tracking areas. The MME also coordinates paging responses and supervises the process by scheduling retransmissions of PAGING messages. The eNodeB, having received the paging request from the MME, allocates resources, schedules the paging process related to the air interface, and transmits the PAGING messages in the radio cells involved. The scheduling takes into account DRX (discontinuous reception) of the UE. Once the UE has detected that it is being paged, it initiates a standard random access procedure. Procedure and message flow

A UE that is attached to the network and is in idle state (ECM-IDLE) is traceable only to its tracking areas (TAs) registered in the serving MME (as part of the mobility information kept in the UE’s context). Every time the network needs to contact such a UE, a paging procedure is performed taking into account the TAs. The following steps are performed during paging: 1. The MME starts the paging procedure by sending a P AGING message via S1 interface to each eNodeB belonging to one of the UE’s tracking areas. This message is part of the S1AP protocol. 2. The eNodeBs derive the destination cells for thepaging request. 3. For each destination cell, the related eNodeB calculates the radio frames for the paging request and schedules (per cell) the paging request accordingly. 4. The eNodeBs transmit PAGING messages to the indicated cells according to the scheduling. These messages are part of the RRC layer.

DN0978045Issue:04A

©2016Nokia

103



5. The addressed UE receives and decodes thePAGING message. The UE responds to the successfully decoded PAGING message by initiating a random access procedure in order to establish a connection to the network. From the eNodeB perspective, multiple paging requests can arrive on S1 before they are actually sent out on the Uu interface. They may need to be scheduled for the same or for different paging occasions. Different paging requests scheduled for the same cell and paging frame have to be transmitted on Uu within the same RRC: PAGING message. Therefore, the eNodeB has to collect and buffer the received paging requests according to their destination cellspaging and their schedule. For eachhas celltoand at each paging at least one scheduled request, the eNodeB setup and send an frame RRC: with PAGING message including all paging requests scheduled for that same paging frame to the UEs. Discontinuous reception for paging

The UE in idle mode may use discontinuous reception (DRX) in order to reduce power consumption. For this case, a DRX cycling period (which is a number of radio frames) is defined and within this period a number of frames (“paging frames”), which the eNodeB can use for paging. For an individual UE to be paged, a system frame number (SFN) for a paging frame in the current DRX cycling period is calculated depending on the UE’s IMSI, and a subframe number within the paging frame is determined, too (the combination of paging frame and subframe number for paging is called “paging occasion”); the eNodeB then begins to page this UE just at this paging occasion in the current DRX cycling period and schedules subsequent paging occasions accordingly in the following DRX cycling periods. Consequently, the UE has to monitor only one subframe of one paging frame within each DRX cycling period. The paging subframe does not contain a complete PAGING message but a L1 PAGING INDICATION message providing information about how the actual paging message can be read and what physical resources have been allocated for it. After having detected a paging indication, the UE listens to the radio frames with the complete PAGING message. The paging indication is repeated until the UE responds or until the number of retries reaches a maximum. The following parameters are used for calculating the system frame number of the paging frame within a DRX cycling period: •

T: The DRX cycling period, which is a number of radio frames, for example 8, 16, 32, ... This parameter is broadcasted as defaultPagingCycle by a system information message (SystemInformationBlockType2 including the “RadioResourceConfigCommon” IE). The value of T is determined either by the MME which can send an UE-specific value to the eNodeB via the S1AP PAGING message or (if the value from the MME is missing or is too large) by the cell specific DRX cycling period whose value is defined by the O&M parameter defaultPagingCycle.

•

N: A fraction of T, possible values are: T, T/2, T/4, T/8, T/16, T/32 This parameter defines the number of paging frames within the T radio frames of one DRX cycling period. Its value is determined by T and the parameter nB which is broadcasted via a system information message (SystemInformationBlockType2 including the “RadioResourceConfigCommon” IE). N = min(T,nB). Since nB is set by the O&M parameterpagingNb “ ” which has the upper limit of “oneT”, N = “pagingNb”. UE_ID:

•

104

©2016Nokia

DN0978045Issue:04A



The IMSI mod 1024 of the UE. The SFN (system frame number) of the paging frame satisfies the following formula (“mode T” on the left side of the equation indicates the repetition period): SFN mod T = (T : N) · (UE_ID mod N) (T : N) gives the distance between paging frames in units of of radio frames (for example, T = 256, “pagingNb” = quarterT, thus N = 64, T/N = 4, which means that every fourth radio frame can contain a paging occasion). The multiplication with (UE_ID mod N) gives the position of a paging frame relative to the start frame of a DRX cycle. UE_ID allows to distribute different UEs over different positions. Currently, the subframe number of the paging frame to be used for a paging indication is always set to 9 (for FDD). Usually, several UEs are addressed with the same paging frame and thus belong to the same paging group. All of them may detect the PAGING INDICATION message and read the PAGING message as well. The UE Identity field in the PAGING message then identifies the desired receiving UE. S1AP message: PAGING

The S1AP: PAGING message includes the following information elements: Content of the S1AP: PAGING message

Table 33

IE

Description

Message Type

This fields identifies: PAGING

UE Identity Index Value

The IMSI mod 1024 which corresponds with the 10 rightmost bits of the IMSI

UE Paging Identity

The IMSI or the S-TMSI

Paging DRX

This optional field defines the UE specific DRX cycle period. If the value is missing, the cell specific DRX cycle period is used.

CN Domain

Value passed to the UE and used in the paging record

List of TAIs

TAI (1)

Tracking area identifier

PLMN Identity

One component of the TAI

TAC

Tracking area code, the second component of the TAI

TAI(2)

...

PLMN Identity TAC ...

DN0978045Issue:04A

... ... ...

©2016Nokia

105



Content of the S1AP: PAGING message (Cont.)

Table 33

IE

Description

Paging Cause

The content of this field is to be passed to the RRC PAGING message

RRC message: PAGING

The RRC: PAGING message includes the following information elements: Content of the RRC: PAGING message

Table 34

IE

Description

pagingRecordList

This fields is only included if an UE specific paging has been triggered by the MME.

UE Identity

Taken from the S1AP PAGING message from the MME

Choice S-TMSI S-TMSI Choise IMSI IMSI

2.12.5

CN Domain

Taken from the S1AP PAGING message from the MME

systemInfoModification

This IE is present if a system information change is notified.

etws Indication

This IE is present if a ETWS notification is indicated via S1AP: WRITE-REPLACE WARNING REQUEST message.

cmas Indication

This IE is present if a CMAS notification is indicated via S1AP: WRITE-REPLACE WARNING REQUEST message.

Paging Cause

Taken from the S1AP PAGING message

System impact The feature has no additional impacts on the system.

2.12.6 2.12.6.1

User interface Alarms There are no alarms related to this feature.

106

©2016Nokia

DN0978045Issue:04A


2.12.6.2



2.12.6.3

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

2.12.6.4

Parameters Table 35: Parameters for the LTE49: Pagingshows parameters for the LTE49: Paging feature. Parameters for the LTE49: Paging

Table 35

Full name

2.12.7

Abbreviated name

Managed object

Cellbarredflag

cellBarred

LNCEL

Defaultpagingcycle

defPagCyc

LNCEL

PagingnB

pagingNb

LNCEL

Trackingareacode

tac

LNCEL

Sales information Table 36

Sales information BS W/ASW

BSW

L i ce n s e c on tr ol i n n e t w or k element

-

License control attributes

-

2.13 LTE50: UE state management 2.13.1

Introduction to feature The LTE50: UE state managementfeature provides session and RRC connection state

management procedures. The feature also introduces the RL failure procedure.

2.13.2

Benefits The feature provides a necessary state management functionality for UEs.

2.13.3

DN0978045Issue:04A

Requirements

©2016Nokia

107


2.13.3.1


Software requirements The following software is required for this feature: Table 37



Systemrelease

RL09

MME SAE GW

2.13.3.2

NS10 -

UE

3GPP R8

NetAct

-


2.13.4

Functional description Individual UE state models are used to describe the status of a UE for EPS connection management (ECM) and EPS mobility management (EMM): •

ECM-CONNECTED

The RRCinterface. connection is established on the air interface and the S1 connection on the S1-MME •

ECM-IDLE

The RRC connection is released on the air interface and the S1 connection on the S1-MME interface. •

EMM-REGISTERED

The registration procedure has been successful for the UE. •

EMM-DEREGISTERED

The UE has been switched off. The Radio Resource Control (RRC) in E-UTRAN are E-UTRA RRC_IDLE and EUTRA RRC_CONNECTED. In LTE, the states are RRC_IDLE and RRC_CONNECTED. UE state handling covers those AS procedures that are involved in initiation and support of EPC connection management state transitions such as: •

Paging

triggering the UE to initiate a ECM-IDLE to ECM-CONNECTED transition •

Initial access

transition to ECM-CONNECTED •

Signaling connection release

Transition to ECM-IDLE •

Error scenarios

for example RRC connection re-establishment

108

©2016Nokia

DN0978045Issue:04A


2.13 2.13.5



2.13

User interface

2.14 LTE51: Cell selection and re-selection 2.14.1

Introduction to the feature The eNB transmits in each cell physical synchronization signals and broadcast information. This information support initial cell selection and later cell re-selection for an UE in idle state. The eNB transmits primary and secondary synchronization signals in each cell: •

•

The UE does initial cell search and synchronization based on synchronization signals. In further re-selection, the UE may consider measurement thresholds for optimizing its search effort

The cell selection triggers attachment to EPS. The UE will receive a cell-specific physical configuration from PBCH. •

•

2.14.2

Synchronization signals and PBCH are bandwidth independentlyallocated within 72 sub-carriers System wide semi-static bandwidth is assumed in RL09. Network planning andcell based commissioning is needed for configuring cell identities, cell (re)selection thresholds.

Benefits The UE, which may be moving between different tracking areas, can connect to the radio network very quickly.

2.14.3 2.14.3.1




Systemrelease

RL09

MME

NS10

SAE GW

-

NetAct

DN0978045Issue:04A

-

©2016Nokia

109


2.14.3.2



2.14.4

Functional description The functional description part for cell selection and reselection describes the criteria and formulas applied for selection/reselection. Cell selection means that in idle mode the UE searches for the strongest cell on all supported carrier frequencies until a suitable one is found. The search space includes cells of other supported radio access technologies (for example UMTS, GSM). As a result of successful cell selection, the UE camps on a certain cell. Cell reselection means that when camping on a cell, the UE regularly searches for a better cell, and if one is found, it is selected. Cell selection and reselection are performed by the UE in RRC_IDLE mode after the UE has been switched on and has selected a PLMN. The information that the idle UE uses for selecting a cell is broadcast within system information messages. Cell selection and reselection functions belong partly to NAS and partly to AS, see the following table (according to 3GPP TS 36.304). Table 39

NAS and AS parts of cell selection and cell reselection

Process

Cell selection

UE non access stratum •

•

Controling cell selection for example by indicating RAT(s) associated with the selected PLMN to be used initially in the search of a cell in the cell selection. Maintaining a list of forbidden registration areas and providing this list to AS.

UE access stratum • •

•

•

Cell reselection •

•

•

Controling cell reselection by for example, maintaining lists of forbidden registration areas. Maintaining a list of equivalent PLMN identities and providing the list to AS. Maintaining a list of forbidden registration areas and providing the list to AS.

•

•

•

Performing measurements needed to support cell selection. Detecting and synchronizing to a broadcast channel. Receiving and handling broadcast information. Forwarding NAS system information to NAS. Searching for a suitable cell. Responding to NAS whether such cell is found or not. Camping on a suitable cell (if available). Performing measurements needed to support cell reselection. Detecting and synchronizing to a broadcast channel. Receiving and handling broadcast information. Forwarding NAS system information to NAS. Changing cell if a more suitable cell is found.

The eNodeB transmits in each cell physical synchronization signals and broadcast information supporting initial cell selection and cell re-selection. The synchronization signals are the basis for the UE to do the initial cell search.

110

©2016Nokia

DN0978045Issue:04A



The NAS (non-access stratum) can control the RAT(s) (radio access technologies) in which cell selection is performed, for example, by maintaining a list of forbidden registration areas and a list of equivalent PLMNs. Cell selection

During the cell selection, the UE searches for a suitable cell on all supported carrier frequencies of each supported RAT. Once a suitable cell is found, this cell is selected. On each carrier frequency the UE only searches for the strongest cell. For speeding up the procedure, the UE can use information stored from a previous access. The following criterion called S-criterion is used: A cell is suitable for cell selection if the cell selection RX level S rxlev defined below has a positive value (all values in dB, parameter names are according to 3GPP). In additon in RL50 ( LTE1036: RSRQ Based cell reselection)a 2nd criterium(for Squal ) is introduced: Srxlev = Q rxlevmeas – (Q rxlevmin – Q rxlevminoffset) – max(Pemax – P umax , 0) Squal = Q qualmeas - (qQualMinR9 + q QualMinOffsetR9) Qrxlevmeas

The measured RX level value, that is, the RSRP

Qrxlevmin

The minimum required RX level in the cell

Qrxlevminoffset

An offset which may be configured to prevent ping-pong effects between PLMNs which may otherwise occur due to fluctuating radio conditions. The offset is taken into account only when performing a periodic search for a higher priority PLMN while the UE camps on a suitable cell in a visited PLMN

Pemax

The maximum transmit power an UE is allowed to use for an uplink transmission in the cell

Pumax

The maximum RF output power of the UE according to the UE’s power class

Qqualmeas

UE measurement (RSRQ)

qQualMinR9

Min required RSRQ level incell

qQualMinOffsetR9

Offset to the signaled qQualMinR9 taken into account in the Squal evaluation as a result of a periodic search for a higher priority PLMN while camped normally in a VPLMN

max(Pemax – P umax , 0) is a compensation factor giving a contribution only if the UE has less power capabilities than allowed. In such cases, the compensation factor makes a cell less suitable for cell selection. Th S-criterium is fulfilled if S rxlev >0 and Squal >0. Assuming that the power class of an UE is high enough and neglecting higher priority PLMNs, a cell is suitable if the measured RX level is higher than a minimum receive level which can be configured. The cell selection parameters are broadcasted within the SystemInformationBlockType1.

DN0978045Issue:04A

©2016Nokia

111



Cell reselection

Cell reselection between frequencies and RATs is primarily based on priorities. LTE configures an absolute priority for all applicable frequencies of each RAT. Cell-specific priorities are provided via system information. Of the frequencies allowed for cell reselection, the UE considers only those for which it has priorities. Equal priorities are not applicable for inter-RAT cell reselection. The UE can reselect to a cell on a higher-priority frequency only if the S-value (according to the S-criterion above) of the concerned target cell exceeds a high threshold for at least a duration Treselection . The UE can reselect to a cell on a lower-priority frequency only if the S-value of the serving cell is below a low threshold for at least T reselection while the S-value of the target cell exceeds another low threshold. If there is still more than one candidate target cell, the UE compares these cells using the following ranking criterion called R-criterion: For the serving cell: Rs = Q meas,s + Q hyst,s For the neigbour cells: Rn = Q meas,n + Qoffset,s,n Qmeas

The measured RX level value, that is, the RSRP

Qhyst,s

This parameter controls the degree of hysteresis for the ranking

Qoffset

An offset for weighting between serving cell and neigbour cells

The UE selects the highest-ranked candidate cell provided that it is better ranked than the serving cell for at least the time period Treselection. Afterwards, the UE checks the accessibility of that cell and performs the cell reselection to that cell if possible. Broadcasting of cell reselection parameters:

The cell reselection parameters are broadcasted within SystemInformationBlockType3/4/5/6/7/8 in the system information messages. More in detail, the SystemInformationBlockType (SIB) includes the following information: •

•

•

•

112

SIB3: SystemInformationBlockType3 contains cell re-selection information common for intra-frequency, inter-frequency and/or inter-RAT cell reselection (applicable to more than one type of cell reselection but not necessarily all) as well as intra-frequency cell reselection information other than neighboring cell related. SIB4: SystemInformationBlockType4 contains neighboring cell related information relevant only for intra-frequency cell reselection. The IE includes cells with specific reselection parameters as well as blacklisted cells. SIB5: SystemInformationBlockType5 contains information relevant only for inter-frequency cell reselection. This is information about other E-UTRA frequencies and interfrequency neighboring cells relevant for cell reselection. The IE includes cell reselection parameters common for a frequency as well as cell specific reselection parameters. SIB6:

©2016Nokia

DN0978045Issue:04A


•

•


SystemInformationBlockType6 contains information relevant only for inter-RAT cell reselection. This is information about UTRA frequencies and UTRA neighboring cells relevant for cell reselection. The IE includes cell reselection parameters common for a frequency.(depending on support of UMTS) SIB7: SystemInformationBlockType7 contains information relevant only for inter-RAT cell reselection. This is information about GERAN frequencies relevant for cell reselection. The IE includes cell reselection parameters for each frequency.(depending on support of GSM) SIB8: SystemInformationBlockType8 contains information relevant only for inter-RAT cell reselection to CDMA/1xRTT or CDMA/eHRPD. The IE includes cell reselection parameters for like frequencies and neighbor cell information. The parameters are described in the following feature descriptions: – –

2.14.5

LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT LTE870: Idle Mode Mobility from LTE to CDMA /eHRPD


2.14.6 2.14.6.1


2.14.6.2


2.14.6.3


2.14.6.4

Parameters There are no parameters related to this feature.

2.14.7



BSW

DN0978045Issue:04A


-

©2016Nokia


-

113



2.15 LTE53: Intra and inter eNB handover with X2 2.15.1

Introduction to the feature The inter-eNodeB handover is the basic type of a handover within LTE. Intra-eNodeB handover is just a specification of the inter-eNodeB handover. Handovers in LTE arethe network andtoUE assisted. are prepared the target cell before UE is controlled commanded move to the Resources target cell. Data packets in whose reception could not be acknowledged before the handover procedure are retransmitted.

2.15.2

Benefits With this feature, intra- and inter-eNB handover is possible via X2 interface.

2.15.3 2.15.3.1




Systemrelease

2.15.3.2

RL09

MME

NS10

SAE GW

NG10 CD2

NetAct

-


2.15.4

Functional description Generally, many handover scenarios are supported – at least in future releases –, for example intra-LTE, inter-RAT (for example LTE and UMTS, RAT: radio access technology). The basic handover type is an intra-LTE handover which is mainly controlled between two eNBs connected via X2 interface (inter-eNB handover).

2.15.4.1 2.15.4.1.1

General procedure Inter-eNodeB handover The following procedure is performed in case of an inter-eNodeB handover (see Figure 11: Message flow for an inter-eNodeB handover ).

114

©2016Nokia

DN0978045Issue:04A



1. The source eNodeB makes thedecision to handover the UEto the target eNodeB based on the MEASUREMENT REPORT of the UE and RRM information. 2. The source eNodeB issues aHANDOVER REQUEST message via the X2interface to the target eNodeB which passes necessary information to prepare the handover at the target side. This message includes signalling references, transport layer addresses and tunnel endpoint identifiers to enable the target eNodeB to communicate with the source eNodeB and the EPC nodes, as well as QoS information for the UE's bearers and RRM information. 3. Admission Control is performed by thetarget eNodeB dependent onthe received radio bearer QoS information and S1 connectivity to increase the likelihood of a successful handover. If the resources can be granted by the target eNodeB, it configures the required resources according to the received UE context information, and reserves a C-RNTI (cell radio network temporary identifier) and a dedicated preamble for the UE. One or more U-plane tunnels may also be established between the source and the target eNodeB in order to support data forwarding of downlink PDCP SDUs (PDCP: packet data convergence protocol, SDU: service data unit) that have not been acknowledged by the UE, and optionally any uplink PDCP SDUs which have been received out of order at the source eNodeB. It should be noted that not all bearers are subject to data forwarding (for example, realtime bearers) and that this is dependent on the bearer's QoS profile. 4. The target eNodeB prepares the handover regarding layer 1and layer 2 and sends a HANDOVER REQUEST ACKNOWLEDGE message via X2 to the source eNodeB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE later as part of the CONNECTION RECONFIGURATION message. The container includes the new C-RNTI and the value of the dedicated preamble to be used by the UE to synchronise with the target cell as well as other parameters required transport by the UE. The HANDOVER REQUEST ACKNOWLEDGE message also contains network layer information for the forwarding tunnels, if necessary, and completes the setup of the X2 signalling connection with the source eNodeB. 5. The source eNodeB sends a CONNECTION RECONFIGURATION message towards the UE, which includes the transparent container (of the previous step) received from the target eNodeB. The source eNodeB performs the necessary integrity protection and ciphering of the message. Once this message has been sent the source eNodeB begins implementing a means to minimize data loss. 6. The SN STATUS TRANSFER message is sent from the source to the target eNodeB. Thereby PDCP layer information is transferred to ensure uplink and downlink PDCP SN continuity for every bearer that requires PDCP status preservation. For each bearer this message contains: •

• •

The downlink SN the target eNodeB should assign to the first SDU which does not have a SN yet. The SN of the next uplink SDU the target eNB should send to the S-GW. Optionally, a status report created by thesource eNodeB for theUE's uplink data which includes a list of the SNs that the UE needs to retransmit in the target cell, if there are any such SDUs.

7. Some time after sending the CONNECTION RECONFIGURATION messageto the UE (and possibly before sending the SN STATUS TRANSFER message to the target eNodeB), the source eNodeB begins forwarding user data in the form of PDCP SDUs using the resources set up previously and continues as long as packets are

DN0978045Issue:04A

©2016Nokia

115



received at the source eNB from the EPC. All SDUs which have already been allocated a SN are forwarded with their SN, otherwise SDUs are forwarded without a SN. 8. When the UE receives the CONNECTION RECONFIGURATIONmessage with the necessary parameters (that is, new C-RNTI, dedicated preamble, target cell ID) it is commanded by the source eNodeB to perform the handover immediately to the target cell. The UE then performs the non-contention based random access procedure. The dedicated preamble which the UE has received is used during the random access procedure. 9. The random access response conveys timing alignment information and initial uplink grant for handover. 10. When the UE has successfully accessed the target cell, it sends the CONNECTION RECONFIGURATION COMPLETE message (containing its new C-RNTI) to the target eNodeB to indicate that the handover procedure is completed for the UE. Once the target eNodeB has verified the C-RNTI it can begin sending downlink data forwarded from the source eNodeB to the UE, and the UE can begin sending uplink data to the target eNodeB. 11. Using the “Source Measurement Configuration” information element given to the target eNodeB by the source eNodeB in the HANDOVER REQUEST message, the target eNodeB decides if a new “Measurement Configuration” needs to be sent to the UE. If a new “Measurement Configuration” is to be sent to the UE, it is sent in a separate CONNECTION RECONFIGURATION message. 12. The target eNodeB sends a PATH SWITCH REQUEST message to the MME to inform it that the UE has been handed over to another eNodeB. Included in this message is information required by the EPC nodes to enable downlink data and Cplane messages to be sent to the target eNodeB (that is, the target eNodeB's signalling reference, transport layer addresses and TEID(s) for each of the UE's bearers). 13. The MME sends a USER PLANE UPDATE REQUEST message to the S-GW, which includes the target eNodeB's TEID(s) received before to enable the user data path to be switched from the source to the target eNodeB. 14. The S-GW switches the downlink data path to the target eNodeB. Before the S-GW can release any U-plane/TNL resources towards the source eNodeB, it sends one or more “end marker” packet(s) to the source eNodeB as an indication that the downlink data path has been switched. It should be noted that the “end marker” packets do not contain user data, and are forwarded transparently by the source eNodeB to the target eNodeB to help it decide when the last forwarded packet was received. 15. The S-GW sends a USER PLANE UPDATE RESPONSE message to the MME to confirm that it has switched the downlink data path. 16. The MME confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACK message. 17. By sending a UE CONTEXT RELEASE message, the target eNodeB informs the source eNodeB of the success of the handover and triggers the release of resources. It should be noted that the target eNodeB does not release its data forwarding tunnels from the source eNodeB until it has received an “end marker” packet indicating that all forwarded SDUs have been received. 18. Upon reception of the UE CONTEXT RELEASE message, the source eNodeB may forward any remaining PDCP SDUs before it releases the radio and C-plane related resources associated to the UE context. Buffering and forwarding data via source eNode during handover

116

©2016Nokia

DN0978045Issue:04A



During the handover procedure, the source eNodeB buffers downlink and uplink PDCP SDUs which arrive from the S-GW or from the UE. The PDCP SDUs shall be forwarded as follows: •

PDCP SDUs with a (already assigned) PDCP SN below the value which was reported by the X2AP: SN STATUS TRANSFER message are accompanied by their PDCP SN (these SDUs have already been sent to the RLC layer and may have already been sent to the UE partially). These SDUs are forwarded first and in order of their PDCP SN.

•

PDCP SDUs with a (intended) PDCP SN equalor beyond the value which was reported by the internal X2AP: SN STATUS TRANSFER message are not accompanied by a PDCP SN (these SDUs have not been processed by the PDCP layer, so they do not have a SN). These SDUs are forwarded in order of their arrival on the source cell S1 GTP-U interface or from the UE. Due to DL RLC retransmission there might exist gaps in downlink PDCP SDUs. For example, if the PDCP SDUs 1 and 3 have not been successfully delivered to the UE, then the PDCP SDUs 1, 2, 3, ... are forwarded to the target eNodeB.

•

In case of uplink data forwarding, the RLC layer sends to the PDCP layer also the completely received uplink RLC SDUs (PDCP PDUs) which are not delivered to the PDCP layer, because some RLC PDUs, sent earlier, are not yet received and a reordering timer in the RLC layer for that missing PDU is still running. This means that there exists PDCP PDUs in the RLC buffer but they have not been sent to the PDCP layer, because of the RLC reordering function. Therefore the RLC layer provides to the PDCP layer the last correctly received RLC SDU (PDCP PDU) and the list of missing RLC SDUs (PDCP PDUs). All PDCP PDUs which were indicated by the RLC layer are forwarded to the target eNodeB via uplink forwarding tunnel. The source eNodeB keeps the copies from srcinal user and data of signalling radio bearer SRB2 (and also incoming S1 GTP-U data) in its own data buffers until the handover is accomplished and resources are released or the handover fails.

DN0978045Issue:04A

©2016Nokia

117


Figure 11


Message flow for an inter-eNodeB handover Source eNB

UE

Target eNB

Serving GW

MME

Packet data

Packet data

Measurement reports Handover decision Handover request Admission control and resource allocation Handover request acknowledge

DL allocation Connection reconfiguration Detach from old cell

Deliver buffered and intransit packets to target eNB SN status transfer Data forwarding Buffer packets from source eNB Synchronisation

UL allocation + TA for UE Connection reconfiguration complete Connection reconfiguration measurement configuration

Path switch request

Connection reconfiguration complete

User plane update request End marker

Switch DL path Packet data

Path switch request acknowledge

User plane update response

UE context release Release S1, X2 signaling Release X2 and radio resources signaling connection Continue forwarding packets Data forwarding End marker Release remaining resources

Begin sending S1 - U data Release other X2 resources

Packet data

Packet data

Time control and exception handling

Several timers are used to supervise the duration of the steps of the handover procedure: •

•

118

After sending a HANDOVER REQUEST messagevia the X2 interface to the target eNodeB, the source eNodeB sets the guard timer “TX2 RELOC Prep” to supervise the time period before receiving the HANDOVER REQUEST ACKNOWLEDGE answer from the target eNodeB. If this timer expires before the answer arrives, the handover procedure is stopped (beginning with the X2AP: HANDOVER CANCEL message to the target eNodeB). In case of handover cancelling, the source eNodeB starts the “Handover Cancel Latency Timer” when sending the X2AP: HANDOVER CANCEL message. The source eNodeB starts the internal “TX2 RELOC Overall” timer after having received the HANDOVER REQUEST ACKNOWLEDGE message from the target eNodeB. This timer supervises the time period until receiption of the the X2AP: RELEASE RESOURCE message from the target eNodeB after a successful handover. “TX2 RELOC Overall” is the sum of T304, T311, T301 and a configurable security offset. If the timer “TX2 RELOC Overall” expires, the handover procedure is cancelled.

©2016Nokia

DN0978045Issue:04A


•

•

•

•

2.15.4.1.2


The target eNodeB starts the “TX2 RELOC Exec” timer after sending the HANDOVER REQUEST ACKNOWLEDGE message to the source eNodeB. This timer is used to supervise the duration time until reception of the RRC: RRC CONNECTION RECONFIGURATION COMPLETE message from the UE. The timer “TDATA Fwd S1” is started in the source eNodeB whenthe X2AP: RELEASE RESOURCE message is received from target eNodeB. It is used to define a time period for forwarding all user data and all GTP-U “end marker” packets. When the timer “TDATA Fwd S1” expires, all U-plane user context resources are released including temporary GTP-U data forwarding tunnels between the source eNodeB and the target eNodeB. Also, all C-plane user context resources are released including the eNodeB’s internal connection for X2 message transfer. The timer “TX2 RELOC Comp” is started in the targeteNodeB when the S1AP: PATH SWITCH REQUEST message is sent to the MME and it is typically stopped when the S1AP: PATH SWITCH REQUEST ACKNOWLEDGE message is received in return. When the timer expires, the eNodeB initiated context release procedure is started. The timer “TDATA Fwd X2” is started in the target eNodeB whenthe S1AP: PATH SWITCH REQUEST ACKNOWLEDGE message is received. If the timer expires, the eNodeB closes its user data tunnels at X2.

Intra-eNodeB handover Handovers between cells of an eNodeB can be seen as a variant of the inter-eNodeB handover without CN node relocation where the handover is performed completely within the eNodeB, and does not involve signalling to EPC nodes at any point during the procedure. The following procedure is performed in case of an inter-eNodeB handover. 1. The eNodeB makes thedecision to handover the UE toanother cell which belongs to the same eNodeB based on the MEASUREMENT REPORT of the UE and RRM information. 2. Admission Control is performed in the target cell and if the resources can be granted the radio bearers are configured. Additional resources are also configured to allow the UE to access the new cell, which includes allocating the UE a new C-RNTI and a dedicated preamble. At this point, any downlink user data for the UE is buffered until the handover has been completed. 3. The eNodeB sends a CONNECTION RECONFIGURATION message towards the UE with the necessary parameters (i.e. new C-RNTI and dedicated preamble) to allow the UE to connect to the new cell. 4. The UE immediately detaches from the source cell and synchronizes with the target cell using the non-contention based random access procedure. 5. The random access response conveys timing alignment information and initial uplink grant for handover. 6. When the UE has successfully accessed the target cell, it sends the CONNECTION RECONFIGURATION COMPLETE message to the eNodeB to indicate that the handover procedure is completed for the UE. The eNodeB can then begin sending downlink user data towards the UE, and the UE can begin sending uplink user data to the eNodeB. 7. The eNodeB releases the UE's resources in the source cell.

DN0978045Issue:04A

©2016Nokia

119



Intra-eNodeB handovers include all cases where the eNodeB-internal system modules (e.g. FSM, flexi system module) or processing units change or do not change. Buffering of data within the eNodeB and forwarding to the target system unit is provided similar to inter-eNodeB handovers.

2.15.4.2

Target cell list handling Having decided that a handover is to be executed, the eNodeB selects the most appropriate target cell from the target cell list. Dependent on the output from the RRM handover algorithm, the eNodeB derives the handover mode from the selected target cell. In special cases, the eNodeB processes the target cell list received by the UE, e.g. excluding inhibited cells and performs a re-sorting of the list if necessary (the sorting of TCL might be obsolete as it is done yet by the UE).

2.15.5


2.15.6 2.15.6.1


2.15.6.2


2.15.6.3


2.15.7


Sales information BSW /ASW

BSW

120

L i c e n s e co n tr ol i n n e t w or k element

-


-

©2016Nokia

DN0978045Issue:04A



2.16 LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas 2.16.1

Introduction to the feature The following features offer solutions related to multi-path downlink transmissions. As MIMO (Multiple Inputs Multiple Outputs) is one of the key features of LTE, techniques for “downlink adaptive open loop MIMO” and “transmission diversity” are presented. By applying the feature LTE70: Downlink adaptive open loop MIMO for two antennas , the eNodeB selects dynamically between “Space Frequency Block Coding (SFBC) transmit diversity” and “Open Loop Spatial Multiplexing” with “Large-delay Cyclic Delay Diversity” (“Large-delay CDD”). When using the featureLTE69: Transmit diversity for two antennas , the eNodeB transmits each data stream via 2 TX diversity paths, and the “Space Frequency Block Code” mode is applied. Diversity methods are complementing the basic feature LTE187: Single TX path mode, where the TX signal is transmitted via a single TX antenna per cell, either due to HW configuration or in semi-static mode selected by O&M for HW configurations with two TX paths per cell.

2.16.2

Benefits In the following section, benefits for operators and end users are summarized with regard to the following features: • •

2.16.2.1

LTE69: Transmit diversity for two antennas LTE70: Downlink adaptive openloop MIMO for two antennas

End user benefits The mentioned features support radio links, offering high data rates and signal quality.

2.16.2.2

Operator benefits By the feature LTE69: Transmit diversity for two antenna, cell coverage and capacity are enhanced by the transmit diversity of two antennas. The feature LTE70: Downlink adaptive open loop MIMO for two antennasprovides high peak rates (using two code words) and good cell edge performance (using a single code word) by the adaptive algorithm. Furthermore, “double stream 2x2 MIMO spatial multiplexing (open loop)” can be used for small cells with low load if the UE capabilities are sufficient.

2.16.3

Requirements For the features LTE70: Downlink adaptive open loop MIMO for two antennasand LTE69: Transmit diversity for two antennas , the following hardware and software requirements have to be met.

DN0978045Issue:04A

©2016Nokia

121


2.16.3.1


Software requirements The features LTE69 and LTE70 require RL09 software.

2.16.3.2

Hardware requirements The features LTE70 and LTE69 require particular hardware to support radio diversity techniques: •

•

For LTE70: Downlink adaptive open loop MIMO for two antennas , the eNodeB and the UE support MIMO. UEs which are not MIMO capable shall use dlMimoMode=1. For LTE69: Transmit diversity for two antennas, the eNodeB has to be equipped with two antennas at least.

UEs as defined in 3GPP release 8 comply with these requirements.

2.16.4 2.16.4.1

Functional description Functional overview By means of the feature LTE70: Downlink adaptive open loop MIMO for two antennas , the eNodeB is able to select dynamically between “Space Frequency Block Coding (SFBC) Transmit Diversity” and “Open Loop Spatial Multiplexing” with “Large-delay Cyclic Delay Diversity” (“Large-delay CDD”). Open loop spatial multiplexing is offered with two code words with “Large-delay CDD” for the PDSCH (Physical Downlink Shared Channel) on UE basis. Using the feature LTE69: Transmit diversity for two antennas , the eNodeB transmits single data streams via 2 TX diversity paths. Furthermore, each data stream is transmitted by two diversity antennas per sector, and “Space Frequency Block Coding (SFBC) Transmit Diversity” is applied. Diversity methods complement the basic feature LTE187: Single TX path mode.

2.16.4.2

Downlink adaptive open loop MIMO for two antennas By means of the feature LTE70: Downlink adaptive open loop MIMO for two antennas , the eNodeB is able to select dynamically between “Space Frequency Block Coding (SFBC) Transmit Diversity” and “Open Loop Spatial Multiplexing” with “Large-delay Cyclic Delay Diversity” (“Large-delay CDD”). Open loop spatial multiplexing is offered with two code words with “Large-delay CDD” for the PDSCH on UE basis. The open loop dynamic MIMO switch functionality can be enabled and disabled on cell level by means of O&M. When the dynamic MIMO switch is disabled, either static multiplexing or static transmit diversity can be selected for the whole cell (all UEs). The dynamic switch takes into account the UE’s specific link quality and rank information. Furthermore, the UE radio capabilities are considered and additional offsets for CQI reporting compensation are provided with regard to the dynamic MIMO switching functionality. MIMO is a key technology in achieving the ambitious requirements for throughput and spectral efficiency for the LTE air interface. MIMO refers to the use of multiple antennas at the transmitter and at the receiver. For the LTE downlink, a 2x2 configuration for MIMO is assumed as baseline configuration, i.e. two transmit antennas at the base

122

©2016Nokia

DN0978045Issue:04A



station and two receive antennas at the terminal side. Configurations with four transmit or receive antennas are also supported by LTE Rel-8. Different gains can be achieved depending on the MIMO mode that is used. Table 43: Multi antenna options in LTEgives an overview on the typical LTE multi antenna configurations:

DN0978045Issue:04A

©2016Nokia

123



Multi antenna options in LTE

Table 43

DL

1x21 2x2

BS

UE

TX

RX

UL

Gain to smaller configuration

2 2

1x2 1 2

+ 4 .. 5 dB DL link budget

UE

BS

TX

RX

2 1x2 1

Configuration type

Gain to smaller configuration

minimum 2

standard

+ 100% peak data rate + user experience + 10% spectrum efficiency

The “standard” configuration of the LTE base station provides in addition to 2 RX antennas (RX diversity) 2 TX chains, which has the advantage in that no extra antenna and feeder cost is necessary compared to the minimum 1 TX chain. In a “high performance” scenario, 4 RX antennas at the LTE base station substantially enhance the LTE uplink path but require additional antenna and feeder effort and costs. Typically, the LTE UE is equipped with 2 RX antennas and 1 TX chain.

2.16.4.2.1

Receive diversity The company supports 2-branch and plans to support 4-branch receive diversity based on MRC (Maximum Ratio Combining). MRC aims at combining the 2 (or 4) receive signals in such a way that the wanted signal's power is maximized compared to the interference and the noise power, i.e. theSINR (Signal to Interferer and Noise Ratio) is enhanced. Compared to a single receive branch, 2-branch receive diversity allows for: • •

•

coherence link budget gain of 3 dB additional diversity link budget gainof some dB depending on many conditions including velocity, fading channel and carrier bandwidth link budget gain from MRC at about 10% Block Error Rate (BLER) mayreach up to 6 dB (as shown in simulations)

Correspondingly, 4-branch receive diversity will show a coherence link budget gain of 6 dB plus some dB additional diversity link budget gain. Receive diversity with two receive branches requires two uncorrelated receive antennas using a single cross-polar antenna or two vertically polarized spatially separated antennas; 4-branch receive diversity requires four uncorrelated receive antennas using e.g. 2 spatially separated cross-polar antennas. Receive diversity complies with LTE Rel-8 terminals and is supported on all uplink channels.

124

©2016Nokia

DN0978045Issue:04A


2.16.4.2.2


Transmit diversity The company supports 2-branch and plans to support 4-branch transmit diversity. If the total eNodeB transmit power keeps the transmit power per transmit branch as high as for the single transmit antenna case, the link budget is increased by 3 dB for two branches and by 6 dB for four branches. This implies coverage and capacity enhancements. If the total eNodeB transmit power is constant (compared to the single transmit branch case), transmit diversity leads to more robust links at the cell edge while slightly reducing cell capacity. However, forDRX (Discontinuous Reception) VoIP users, transmit diversity slightly enhances cell capacity by approximately 5% for two transmit branches. Transmit diversity may be semi-statically configured per cell, while for non-MIMO UEs, dlMimoMode=1 for PDSCH is automatically selected.

2.16.4.2.3

Downlink open loop MIMO The typical MIMO configuration encompassing “dual code word 2x2 DL SU (Single-User) MIMO Spatial Multiplexing” is illustrated in the figure below. This MIMO scheme targets a duplication of the downlink peak user data rate by means of two independent parallel data streams to a single UE. This is also called “Spatial Multiplexing”. The two base station transmit signals, two UE receive signals, and four channels form (for each subcarrier) a system of two equations with two unknown transmit signals. The two unknown transmit signals can be achieved by channel estimation, possible transmit alphabet(s), and the two receive signals. Figure 12

2x2 MIMO configuration Channel(s) TXantennas

RXantennas

H1,1

Data

H1,2

X1 TX

Y1 RX

H2,1 X2 H2,2 A

Data

Y2

k:

Y

k 1

k k = H1,1 X1k + H1,2 X2k

Y

k 1

k k = H2,1 X1k + H2,2 X2k

Transmission of 2 independent data streams transmitted at the same time depends on the channels’ signal quality and the decorrelation of both channels. Correlation of the channels is determined by the antenna characteristics. For example antennas are uncorrelated if they: • • •

are spatially separatedby about 10 or more wavelengths, or use orthogonal polarization planes (cross-polarity), or are located in a diffuse environment.

By uncorrelated antennas diversity and spatial multiplexing gains can be achieved, and coherence gains to some extent. For example antenna elements are correlated if they:

DN0978045Issue:04A

©2016Nokia

125


• • •


are phased by ½ wavelength spacing, have a low angular spread, and are located in a non-diffuse environment (e.g. onthe rooftop).

Correlated antennas easily provide robust coherence gains (the classical beamforming gain), but no spatial multiplexing or diversity gain. For Open Loop SU-MIMO Spatial Multiplexing, UE feedback, like PMI and RI is required. Mapping of data to the transmit antenna ports is fixed and the system cannot be thelower conditions for “Spatialrank Multiplexing” not good enough, UE influenced. may requestIf to the transmission and ultimately falls back to however, the dlMimoMode=1. For interoperability reasons, the “Open Loop SU-MIMO” scheme has to be based on the “Large-delay Cyclic Delay Diversity” (“Large-delay CDD”) precoding. The optimum unitary precoding matrix is selected by means of a predefined codebook which is known at eNodeB and UE side, and by the UE’s radio channel estimate. Operators may (statically) configure whether a cell supports “Transmit Diversity”, or “MIMO Spatial Multiplexing”, or allows for an adaptive mode. In the adaptive mode, the “Open Loop 2x2 SU-MIMO” fallback is “Space Frequency Block Coding (SFBC) Transmit Diversity”. In ideal situations, 2x2 SU-MIMO duplicates the peak user data rate. For realistic conditions, 2x2 SU-MIMO enhances cell capacity by 10% for macro-cellular and by 40% for micro-cellular deployment scenarios. The current eNodeB hardware meets the phase noise or the minimum jitter requirements (< 60 ns) between LTE baseband processing and antenna connectors required for MIMO schemes with uncorrelated antennas.

2.16.4.3

Transmit diversity for two antennas Using the feature LTE69: Transmit diversity for two antennas , the eNodeB transmits each data stream via 2 TX diversity paths. Each data stream is transmitted by two diversity antennas per sector, and “Space Frequency Block Coding (SFBC) Transmit Diversity” is applied. The transmit diversity mode can be used for most physical downlink channels, except for the synchronization signals, which are transmitted only via the first TX antenna, and except when the eNodeB send different cell-specific reference signals per antenna. The operator can enable the semi-static transmit diversity mode on cell basis. Diversity methods complement the basic feature LTE187: Single TX path mode, where the TX signal is transmitted via a single TX antenna per cell. Here, the single TX path mode can be applied for two scenarios dependent on the HW configuration of the eNodeB: Either for HW configurations with only one TX path per cell or for HW configurations with two TX paths per cell where the second TX path is disabled by O&M. The latter scenario is primarily intended for trialing purpose. In this case, the same 2path HW configuration supports enhanced operational modes of TX diversity or MIMO. The operator can select the TX mode semi-statically on cell basis by the O&M configuration. The single TX path per cell mode is the basic transmit solution without spatial diversity in the eNodeB. A single pattern of symbols for cell-specific reference signals is sent in downlink direction. In uplink direction, 2 RX paths per cell are always supported by the eNodeB.

126

©2016Nokia

DN0978045Issue:04A


2.16.4.4


Open loop spatial multiplexing For small cells with low load, “double stream 2x2 MIMO spatial multiplexing (open loop)” can be used if the UE capabilities are sufficient. Otherwise, dlMimoMode=1 has to be selected.

2.16.5

System impacts By introduction of the features LTE70: Downlink adaptive open loop MIMO for two antennas and LTE69: Transmit diversity for two antennas , the following interdependencies and impacts are relevant:

2.16.5.1

Interdependencies between features The following features are required for LTE70: Downlink adaptive open loop MIMO for two antennas:

•

LTE30: CQI adaptation LTE899: Antenna line supervision

•

LTE69: Transmit diversity for two antennas.

•

For LTE69: Transmit diversity for two antennas, the TX path activation or deactivation can be performed only if MIMO or TX features are enabled. The features LTE187: Single TX path mode, LTE69: Transmit diversity for two antennas, LTE70: Downlink adaptive open loop MIMO for two antennas , and LTE703: Downlink adaptive closed loop MIMO for two antennasare related to each other as they are configured by the same management parameterdlMimoMode.

2.16.5.2

Impacts on interfaces C-plane, U-plane and other RRM functions have to contain data for the MIMO mode or for the antenna configuration and settings.

2.16.5.3

Impacts on network and network element management tools The eNodeB antenna configuration has to comprise at least two antennas if MIMO is applied. Open loop MIMO has to take into account the UE capabilities. UEs which are not capable to support MIMO shall use dlMimoMode=1, i.e. “diversity”, in MIMO configurations.

2.16.5.4

Impacts on system performance and capacity By diversity methods, the channel capacity is enhanced, even for more restrictive radio channel constraints with regard to BLER and SINR for instance.

DN0978045Issue:04A

©2016Nokia

127


2.16.6


Sales information The feature LTE70: Downlink adaptive open loop MIMO for two antennasis a essential part for LTE, release 8 functionality. Diversity techniques are provided also by LTE69: Transmit diversity for two antennas.

2.16.7

User interface By introduction of the feature LTE70: Downlink adaptive open loop MIMO for two antennas, new parameters and counters are available.

2.16.7.1

Managed Objects This chapter is not relevant for the feature.

2.16.7.2

Parameters The following table displays the parameters implemented for the feature LTE70: Downlink adaptive open loop MIMO for two antennas . By dlMimoMode, diversity modes can be selected. For dynamic control of the respective mode, thresholds with regard to the CQI and the coding matrix rank are introduced, both comprising values for a hysteresis loop.

Parameters for “LTE70: Downlink adaptive open loop MIMO for two antennas”

Table 44

Name

dlMimoMode

Object

LNCEL

Description

"The used DL mimo mode for each physical channel is the following: 0: Single Stream Downlink: All downlink physical channels are transmitted using this mode; 1: Single Stream Downlink Transmit Diversity: All downlink physical channels are transmitted using this mode; 2: Dual Stream MIMO Spatial Multiplexing: SRB1 (DCCH) and RBs(DTCH) on PDSCH are transmitted using Dual Stream MIMO with spatial multiplexing; SRB0 (CCCH), BCCH and PCCH on PDSCH and all other physical channels are transmitted using Single Stream Downlink Transmit

Range

Default value

SingleTX (0), TXDiv (1), Static Open Loop MIMO (2), Dynamic Open Loop MIMO (3)

Diversity; 3: Dynamic Open Loopon MIMO: SRB1 (DCCH) and RBs(DTCH) PDSCH are transmitted using either Single Stream Downlink Transmit Diversity or Dual Stream MIMO with spatial multiplexing depending on radio conditions; SRB0 (CCCH), BCCH and PCCH on PDSCH and all other physical channels are transmitted using Single Stream Downlink Transmit Diversity; "

128

©2016Nokia

DN0978045Issue:04A


Table 44


Parameters for “LTE70: Downlink adaptive open loop MIMO for two antennas” (Cont.)

Name

Object

Description

Range

Default value

mimoOlCqiThD

LNCEL

CQI threshold for fallback to Open Loop MIMO diversity.

0...16, step 0.1

mimoOlCqiThU

LNCEL

CQI threshold for activation of Open Loop MIMO Spatial Multiplexing.

0...16, step 0.1

mimoOlRiThD

LNCEL

Rank threshold for fallback to Open Loop MIMO diversity.

1...2, step 0.05

1.4

mimoOlRiThU

LNCEL

Rank threshold for activation of Open Loop MIMO Spatial Multiplexing.

1...2, step 0.05

1.6

Note: The parameters are subject to change.

2.16.7.3

Alarms There are no relevant alarms for this feature defined in this release.

2.16.7.4

Measurements and counters Nor for the LTE70: Downlink adaptive open loop MIMO for two antennasneither for LTE69: Transmit Diversity for Two Antennas , there are additional counters.

2.16.8

Activating the Feature This feature requires activation. For instructions see Activating the LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas.

This feature requires deactivation. For instructions see Deactivating the LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas.

2.17 LTE423: RRC connection release with redirect 2.17.1

Introduction to the feature The eNodeB supports RRC Connection Release with redirection to an operatorspecifiable RAT & frequency if the UE risks losing coverage and no handover is possible. Due to RSRP measurements (event A2), the eNodeB then triggers a RRC connection release with redirect.

DN0978045Issue:04A

©2016Nokia

129


2.17.2


Benefits Faster change over to other frequeny layers is possible with the LTE423: RRC connection release with redirectfeature.

2.17.3 2.17.3.1




Systemrelease

RL10

MME

NS10 CD2

SAE GW

-

NetAct

2.17.3.2

-


2.17.4

Functional description The eNodeB supports RRC Connection Release with redirection to an operatorspecifiable RAT & frequency if the UE risks losing coverage and no handover is possible. Due to RSRP measurements (event A2), the eNodeB then triggers a RRC connection release with redirect. The thresholds for this event are operator configurable. The target frequency is also operator configurable. It can belong to eUTRAN, WCDMA, GSM, eHRPD, CDMA/1xRTT. The UE capabilities are considered for the redirect. The redirect functionality can be enabled/disabled via O&M. Up to six redirection target layers MORED are supported for each profile MOPR.

g

Note: When configuring the feature, do not configure theRAT for redirection (redirRAT) parameter value to: utraTDD in the following objects: • • •

2.17.5

REDRT MORED MODRED


2.17.6

130

User interface

©2016Nokia

DN0978045Issue:04A


2.17.6.1


Alarms There are no alarms related to this feature.

2.17.6.2


2.17.6.3


2.17.6.4 Table 46

Parameters

Parameters for RRC connection release with redirect

Name

Enable UE context release with redirect

Short name

actRedirect

Threshold Th4 For RSRP threshold4

Object

Description

Range

LNBTS

This parameter enables the feature UE context release with redirect.

enabled, disabled

LNCEL

Threshold for RSRP of intrafrequency neighbour cell. If RSRP of the serving value < threshold4 then redirect is triggered. This is an A2 event type

0 ... 97, step 1

Related Hysteresis of hysThreshold4 LNCEL Threshold Th4 For RSRP

Related Hysteresis of Threshold for 0 ...15 dB, RSRP of serving cell for redirection step 0.5 dB triggerParameter is used within the entry and leave condition of the A2 triggered reporting condition. The IE value is multiplied by 2.

Redirection target configuration identifier

redrtld

REDRT

This parameter defines the number of redirection targets specified for the respective cell.

1...2

RAT for redirect

redirRat

REDRT

This parameter selects the RAT in which the UE is redirected.

eutran, geran, utra-FDD, cdma2000HRPD, cdma20001xRTT

eUTRA frequency

redirFreqEutra REDRT

This parameter must be configured if redirRAT=eutran.

0 ... maxEARFCn

Default value

enabled

It is used to specify the eUTRA frequency (max. value ref. to 36.331)

DN0978045Issue:04A

©2016Nokia

131



Parameters for RRC connection release with redirect (Cont.)

Table 46

Name

Short name

GERAN band indicator

redirGeranBan dIndicator

Object

REDRT

Description

Range

Indicator to distinguish the GERAN frequency band in case of ARFCN values associated with either GSM

0 (gsm1800), 1 (gsm1900), 2 (notUsed)

Default value

2

1800 or GSM 1900 carriers. For ARFCN values not associated with one of those bands, the indicator has no meaning. This parameter must always be configured if redirRAT=geran. List of GERAN ARFCN values

redirGeranAR FCNValueL

REDRT

List of GERAN ARFCN values. This 0 ...1023, step 65535 parameter must be configured if 1 redirGeranFollowingARFCNsSwitch = explicitListofARFCNs

UTRA frequency

redirFreqUtra

REDRT

This parameter must be configured if redirRAT = utra-FDD. It is used to specify the UTRA frequency.

CDMA band

redirBandCdm a

REDRT

This parameter must be configured bc0, bc1, if reddirRAT = cdma2000-HRPD or bc2,.., bc17 reddirRAT= cdma2000-1xRTT. It is

0 ...16383

used to specify the cdma2000 bandclass. CDMA frequency

2.17.7

redirFreqCdma REDRT

This parameter must be configured 0 ... 2047 if reddirRAT = cdma2000-HRPD or reddirRAT= cdma2000-1xRTT. It is used to specify the cdma2000 ARFCN.



BSW


-


-

2.18 LTE747: Support of UE radio capabilities 2.18.1

Introduction to feature LTE747: Support of UE radio capabilitiesfeature introduces the basic function needed to

take into account the UE radio capabilities in individual RRM procedures.

132

©2016Nokia

DN0978045Issue:04A


2.18.2


Benefits The feature make it possible to take into account the UE radio capabilities in individual RRM procedures.

2.18.3 2.18.3.1




Systemrelease

RL10

MME

NS10 CD2

SAE GW

2.18.3.2

-

UE

3GPP R8

NetAct

-


2.18.4

Functional description The eNB retrieves the UE radio access capability parameters from one of the following sources: • • •

the S1AP initial setup request message the RRC UE capability transfer procedure if it is not provided via S1AP the X2AP in the event of a handover

The UE radio access capability parameters are stored in the eNB and evaluated by individual RRM functions. The UE radio access capability parameters include: • • • • • • • •

Access stratum release UE category PDCP parameters Physical layer parameter RF parameter Measurement parameter Feature group indicator Inter RAT-parameters

The eNB sends the UE radio access capability parameters to: •

DN0978045Issue:04A

the MME if the UE radio capabilities have been retrieved via RRC

©2016Nokia

133


•

2.18 2.18.5


the neighbor LBs or eNBs in the event of a handover


2.19 LTE749: Link Adaptation for PDCCH 2.19.1

Introduction to the feature The code rate and the control channel element (CCE) aggregation level respectively are adapted based on wideband CQI reports.

2.19.2

Benefits This feature allows efficient usage of PDCCH resources.

2.19.3 2.19.3.1



Network element


Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

3GPPR8mandatory

NetAct

2.19.3.2

–


2.19.4 2.19.4.1

Functional description Functional details Code rates and CCE aggregation

134

©2016Nokia

DN0978045Issue:04A



The PDCCH code rate is expressed as net-to-gross ratio where net is the data rate of control data and gross is the overall data rate, that is the rate for control data plus error protection overhead. Alternatively, the code rate can be described in terms of control channel elements (CCEs) since the PDCCH resources are organized in CCE units. A CCE consists of a set of nine resource element groups (REGs) each of which comprises of four QPSK symbols for control data. Thus, one CCE comprises of 36 QPSK symbols (background remark: REGs are the data units used for the interleaving mechanism on PDCCH). The more CCEs are aggregated for a particular PDCCH, the more bits are available for error protection and the lower is the code rate. LTE provides four PDCCH formats related to the number of CCEs used and the code rate respectively, see Table 50: Code rates for PDCCH. The number of CCEs, in other words the CCE aggregation level, used for transmission of a particular PDCCH is determined by the eNB in a way providing an optimal trade-off between the optimum usage of the available PDCCH space, low hash blocking probability and the reliability of PDCCH transmissions. Code rates for PDCCH

Table 50

PDCCH format

0

Code rate

2/3

Number of CCEs

1

Number of bits

72

1

1/3

2

144

2

1/6

4

288

3

1/12

8

576

Power adjustment

Link adaptation on PDCCH provides a power control component. If enabled, the following power adjustments are performed: 1. The power on PDCCH is decreased in an appropriate way for all UEs with an assigned CCE aggregation level greater or equal to the calculated one. The power change aims at a target of 1% BLER. 2. The power on PDCCH is increased in an appropriate way for all UEs with an assigned CCE aggregation level lower than the calculated one. The power change aims at a target of 1% BLER. 3. The power on unused CCEs is re-distributed in equal shares onto all scheduled CCEs. PDCCH scheduling

The mechanisms described above are accompanied by an improved PDCCH scheduling; for example, improved merging of DL and UL messages/users, or a possibility to assign a lower aggregation level than determined via CQI evaluation in order to keep PDCCH blocking very low. The operator can also define how much of the dedicated PDCCH capacity for dynamic uplink and downlink scheduling is really used (for example, setting the related parameter pdcchAlpha to 0.8 means 80% of the dedicated PDCCH capacity for users/messages used for dynamic scheduling information; common PDCCH capacity is not concerned), and the operator can define the balance between uplink and downlink PDCCH resource utilization (for example,

DN0978045Issue:04A

©2016Nokia

135



setting the related parameter pdcchUlDlBal to 0.5 means that dynamic uplink and downlink scheduling information get equal PDCCH resource spaces). The PDCCH consists of a common search area and a UE-specific search area, which is defined by a hashing function, and is constant regardless of pdcchAlpha or pdcchUlDlBal.

2.19.5 2.19.5.1


2.19.6 2.19.6.1


Parameters for LTE749: Link Adaptation for PDCCH

Full name

Enable AMC for PDCCH Link Adaptation Enable lower aggregation selection for PDCCH LA

enableAmcPdcch enableLowAgg

Managed object

LNCEL LNCEL

Enable PDCCH power control

enablePcPdcch

LNCEL

PDCCH LA UE default aggregation

pdcchAggDefUe

LNCEL

PDCCH aggregation for RA Msg4

pdcchAggMsg4

LNCEL

PDCCHallocation limit

pdcchAlpha

LNCEL

PDCCHLACQIshift

pdcchCqiShift

PDCCH LA UL DL allocation balance initial value

136

Abbreviated name

©2016Nokia

pdcchUlDlBal

LNCEL LNCEL

DN0978045Issue:04A



2.20 LTE761: Advanced target cell selection and handover retry for intra frequency handover 2.20.1

Introduction to the feature The target cell list is a sorted list of potential target cells for the handover. The eNodeB begins with the firstserving entry of the list checks indicating highest priority. cell selection” , the eNodeB for the all handover variantsWith that “Advanced the highest target priority cell is not contained in a blacklist. If the target cell is in a blacklist the eNodeB proceeds to the next target cell of the list. If an frequency handover attempt fails, a handover retry is performed: The eNodeB retries a handover with the next target cell of the list (including the checks according to “Advanced target cell selection”).

2.20.2

Benefits Advanced target cell selection and handover retry increase the handover success rate.

2.20.3 2.20.3.1




Systemrelease

RL10

MME

-

SAE GW

-

NetAct

2.20.3.2

-


2.20.4

Functional description Advanced Target Cell Handling

The eNodeB prepares the target cell list received from the UE by excluding cells which are not suitable and performing a re-sorting of the list if necessary. If a handover attempt with the best suited of the remaining target cells fails, the next best entry of the prepared target cell list is selected and the handover is retried with this new target cell. The list of conditions depends on whether the feature LTE54 is supported. Cells are removed from the target cell list for the following reasons:

DN0978045Issue:04A

©2016Nokia

137


•

• •

•

•

•


The cell is unknown to the source eNB, for example it was not possible to allocate the ECGI Neither the UEs Serving PLMN-ID nor one of the Equivalent PLMNslisted in the Handover Restriction List is supported in the target cell The target cell is an inter eNB target cell and is blacklisted by Operatorer. ).In the scope of this check the target cell is only considered as blacklisted when child parameter "Blacklisted Topologies" has value "all". The target cell is an intra eNodeB target cell and is blacklisted by Operator. In the scope of this check the intra eNodeB target cell is only considered as blacklisted as soon as it is contained in the structure "blacklistHoL" without evaluating child parameter "Blacklisted Topologies". The combination of PLMN-Idendity and TAC of the target cell is contained in the Handover Restriction List provided by MME (or during a previous incoming HO) The Target Cell is an intra eNodeB target andthe target cell is barred. For example, the 'cellBarred' parameter in SIB1 is set to 'barred'

If the S1 based handover is not activated, a LTE cell is from the TCL list if at least one of the conditions listed below are met: •

• •

• • •

•

The cell is unknown to Source eNodeB, for example itwas not possible to allocate the ECGI X2 connection to the Target eNodeB is not available / operable Neither the UEs Serving PLMN-ID nor one of the Equivalent PLMNslisted in the Handover Restriction List is supported in the target cell. The check of the S1 Connectivity of the Target eNodeB according tohas failed The target cell is blacklisted by Operator The combination of PLMN-Idendity and TAC of the target cell is contained in the Handover Restriction List provided by MME The Target Cell is an intra eNodeB target andthe target cell is barred. E.g. the 'cellBarred' parameter in SIB1 is set to 'barred'

Re-sorting is done in case intra-eNodeB handovers have been configured to be prioritized over inter-eNodeB handovers and has the result that the target cells of the serving eNodeB are on the top of the target cell list (in other cases the sorting of the target cell list might be obsolete as it is already done by the UE).

2.20.5


2.20.6 2.20.6.1


2.20.6.2


138

©2016Nokia

DN0978045Issue:04A


2.20.6.3



2.20.7



BSW


-


-

2.21 LTE762: Idle mode mobility from LTE to WCDMA, GSM or other LTE bands 2.21.1

Introduction to the feature This feature enables cell re-selection from LTE to WCDMA, GSM and other LTE networks.

2.21.2

Benefits Idle mode mobility for inter frequency and IRAT scenarios is possible.

2.21.3 2.21.3.1




Systemrelease

2.21.3.2

RL10

MME

NS10

SAE GW

NG10 CD2

NetAct

-


2.21.4

Functional description The related section in the functional description part describes which neighbor cell information is broadcasted via which system information.

DN0978045Issue:04A

©2016Nokia

139



This feature enables cell re-selection from LTE to WCDMA, GSM and other LTE networks. Information required for the re-selection is broadcasted in system information blocks SIB5, SIB6, and SIB7 as described in the following: •

•

•

SIB 5: The SIB5 contains information about other E-UTRA frequencies and interfrequencyneighbouring cells relevant for cell re-selection. SIB 6: The SIB6 contains information about UTRA frequencies and UTRA neighboring cells relevant for cell re-selection. SIB 7: The SIB7 contains information about GERAN frequencies and GERAN neighboring cells relevant for cell re-selection.

Additionally, the notification of changes in the system information is supported for RRC idle and RRC connected.

2.21.5


2.21.6 2.21.6.1


2.21.6.2


2.21.6.3


2.21.6.4

Parameters Table 55: Parameters for theshows parameters for the feature. Table 55

Parameters for the

Full name

140

Abbreviated name

Managed object

CDMA2000 frequency idle mode configuration identifier

cdfimId

CDFIM

GERAN frequency idle mode configuration identifier

gfimId

GFIM

GERAN cell reselection timer

tResGer

GFIM

©2016Nokia

Structure

DN0978045Issue:04A



Parameters for the (Cont.)

Table 55

Full name

Abbreviated name

Managed object

Structure

Speed-dependent scaling factors t-reselection GERAN

tResGerSF

GFIM

Structure

GERAN cell reselection timer factor high mobility

gerResTiFHM

GFIM

tResGerSF

GERAN cell reselection timer factor medium mobility

gerResTiFMM

GFIM

tResGerSF

GERAN frequency band indicator

bandInd

GNFL

GERAN RAT carrier frequency absolute priority

gCelResPrio

GNFL

ARFCN value list

gerArfcnVal

GNFL

GERAN inter-frequency threshold high

gerFrqThrH

GNFL

GERAN inter-frequency

gerFrqThrL

GNFL

gnflId

GNFL

threshold low GERAN neighbour frequency configuration identifier NCC permitted bitmap

nccperm

GERAN maximum allowed transmit power

pMaxGer

GNFL

GERAN minimum required receive level

qRxLevMinGer

GNFL

EUTRA frequency value

DN0978045Issue:04A

GNFL

dlCarFrqEut

IRFIM

EUTRA carrier frequency absolute priority

eutCelResPrio

IRFIM

Inter-frequency blacklisted cell list

intFrBCList

IRFIM

Structure

Number of PCI in interfrequency range

rangeInterPci

IRFIM

intFrBCList

Lowest PCI in inter-frequency range

startInterPci

IRFIM

intFrBCList

©2016Nokia

141


Table 55



Full name

Abbreviated name

Managed object

Structure

Inter-Frequency neighbouring cell list

intFrNCList

IRFIM

Structure

Physical cell identifier in neighbouring cell list

physCellIdNcl

IRFIM

intFrNCList

Cell reselection procedure offset qOffCell

IRFIM

intFrNCList

EUTRA inter frequency threshold high

interFrqThrH

IRFIM

EUTRA inter frequency threshold low

interFrqThrL

IRFIM

EUTRA presence antenna port1 interPresAntP

IRFIM

EUTRA cell reselection timer

interTResEut

IRFIM

IRFIMidentifier

irfimId

Allowed measurement

IRFIM

measBdw

IRFIM

pMaxInterF

IRFIM

bandwidth Pmax neighbouring EUTRA cells

EUTRA frequency specific offset qOffFrq Minimum required rx RSRP level

qRxLevMinInterF

IRFIM

Speed-dependent scaling factors t-reselection EUTRAN

tResEutSF

IRFIM

Structure

EUTRA cell reselection timer factor high mobility

eutResTiFHM

IRFIM

tResEutSF

EUTRA cell reselection timer factor medium mobility

eutResTiFMM

IRFIM

tResEutSF

UTRA cell reselection timer

142

IRFIM

tResUtra

Speed-dependent scaling factors t-reselection UTRAN

tResUtraSF

UTRA cell reselection timer factor high mobility

utrResTiFHM

©2016Nokia

UFFIM Structure

UFFIM

tResUtraSF

DN0978045Issue:04A


Table 55



Full name

Abbreviated name

UTRA cell reselection timer factor medium mobility

utrResTiFMM

UFFIM

Utran FDD idle mode configuration identifier

uffimId

UFFIM

UTRA carrier frequencies list

utrFddCarFrqL

UTRA downlink frequency value dlCarFrqUtra

2.21.7

Managed object

Structure

tResUtraSF

UFFIM utrFddCarFrqL

UTRA maximum allowed transmit power

pMaxUtra

utrFddCarFrqL

UTRA minumum needed quality parameter

qQualMinUtra

utrFddCarFrqL

UTRA minimum required receive level

qRxLevMinUtra

utrFddCarFrqL

UTRA carrier frequency absolute priority

uCelResPrio

utrFddCarFrqL

UTRA inter frequency threshold high

utraFrqThrH

utrFddCarFrqL

UTRA inter frequency threshold low

utraFrqThrL

utrFddCarFrqL

Sales information The LTE762: Idle mode mobility from LTE to WCDMA, GSM or other LTE bands feature is a basic software feature.

2.22 LTE767: Support of Aperiodic CQI Reports 2.22.1

Introduction to the feature CQI reports are the basis for the downlink link adaptation. CQI is an indicator of the current channel conditions which the UE sees. The UE can be ordered to send CQI reports periodically or aperiodically. The periodic CQI report is usually carried on physical uplink control channel (PUCCH). Aperiodic CQI reports always use PUSCH.

DN0978045Issue:04A

©2016Nokia

143


2.22.2


Benefits This feature allows efficient usage of PUCCH resource as periodic reporting needs to be done less frequently. Aperiodic Reports on PUSCH allows frequent submission of more detailed reports that is including frequency selective parts, MIMO, and so on.

2.22.3 2.22.3.1



Network element


Systemrelease

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

3GPPR8UEcapabilities

NetAct

2.22.3.2

–


2.22.4 2.22.4.1

Functional description Functional details The aperiodic CQI reports are transmitted from the UE to the eNB on PUSCH, together with uplink data or alone. A UE can be configured to have both periodic and aperiodic reporting at the same time. In case both periodic and aperiodic reporting occur in the same subframe, only the aperiodic report is transmitted in that subframe. When a CQI report is transmitted together with uplink data on PUSCH, it is multiplexed with the transport block by layer 1 mechanisms. The eNB schedules the aperiodic CQI report through setting a CQI request bit in an uplink resource grant sent on PDCCH. For more information about aperiodic CQI reports, see 3GPP 36.213 in section 7.2.1. Table 57

CQI report modes for aperiodic reporting

CQI report group

Wideband

144

No PMI

–

©2016Nokia

Single PMI

–

Multiple PMI

mode 1-2

DN0978045Issue:04A



Table 57

CQI report modes for aperiodic reporting (Cont.)

CQI report group

No PMI

Single PMI

Multiple PMI

(only with closed loop MIMO SM) UEselected

mode2-0

–

mode2-2 (only with closed loop MIMO SM)

Higher layer configured

mode 3-0

mode 3-1

–

(only with closed loop MIMO SM)

2.22.5 2.22.5.1


2.22.6 2.22.6.1


Parameters for LTE767: Support of Aperiodic CQI Reports

Full name

Rank Indication Reporting Enable

Abbreviated name

riEnable

Managed object

LNCEL

2.23 LTE905: Non GBR QCI 5, 6,7, 8 and 9 2.23.1

Introduction to feature The LTE905: Non GBR QCI 5, 6, 7, 8 and 9feature introduces the functionality that

allows the usages of different QCIs for non GBR bearers.

2.23.2

Benefits The feature allows the usage of different QCIs for non GBR bearers.

DN0978045Issue:04A

©2016Nokia

145


2.23.3 2.23.3.1





Systemrelease

RL10

MME

NS10 CD2

SAE GW

-

UE

-

NetAct

2.23.3.2

-


2.23.4

Functional description The eNB supports EPS bearers with the QCIs 5, 6, 7, 8, and 9. In RL25TD and RL40 all QCI=1,2,3 ..9 are supported. Furthermore operator specific QCIs 128 ..254 are supported.

2.23 2.23.5

System impacts Sales information This feature belongs to Basic Software (BSW) product structure class.

146

©2016Nokia

DN0978045Issue:04A


Transport and transmission features from previous releases for RL10

3 Transport and transmission features from previous releases for RL10 3.1 LTE1: S1/X2 Datapath Management 3.1.1

Description of LTE1: S1/X2 Datapath Management Introduction to the feature

The eNB and MME are able to transport: user data via the GTP-U tunnels signaling data via theSCTP connections over theS1 and X2 interfaces (above the IP layer)

• •

Benefits End-user benefits

This S1/X2 Datapath Managementfeature allows a fast establishment of data bearers and a fast handover of user equipment to another eNB. Operator benefits

This S1/X2 Datapath Managementfeature provides robust user and signalling data transport supports seamless mobility in the flat architecture. Requirements Hardware and software requirements Table 60

Hardware and software requirements

System release

RL10

Flexi Multiradio Flexi Multiradio Flexi Zone Micro Flexi Zone Access BTS 10 BTS BTS Point

LBTS0.5

Flexi Zone Controller

-

LBTS4.0

OMS

-

LBTSFZ5.0

UE

N e tA c t

-

NS10

-

MME

SAG EW

NG10 CD2

Additional hardware requirements

This feature requires no new or additional hardware. Functional description Functional overview

The control plane and user plane transport in following interfaces are provided: • •

DN0978045Issue:04A

S1-MME: Signalling transport betweeneNB and MME, which carries S1_AP protocol S1-U: User data transport between S-GW and eNB, which is based on GTP-U tunneling protocol

©2016Nokia

147


•

•


X2-C: Signalling transport between, which carrier X2AP protocol for supporting fast inter-eNB handover procedure and related supporting functions X2-U: Temporary user data transport during inter-eNB handover basedon GTP-U tunneling protocol

The GTP-U tunneling protocol is applied for user data transport both over S1-U and temporarily over X2-U during inter-eNB handover execution phase. •

The GTP-U protocol runs over UDP/IP protocol stack

•

GTPv1-U version is applied

Following GTP-U tunnel management functions are applied both for S1-U and for X2-U: • •

GTP-U data tunnel creation GTP-U data tunnel deletion

The GTP-U data tunnel is created and deleted separately on direction basis by the terminating entity: by eNB for downlink direction and S-GW for uplink direction, respectively. Accordingly the target eNB creates GTP-U data tunnel for DL data forwarding during handover preparation phase. The terminating entity informs about the TEID (Tunnel Endpoint Identifier) and the IP address. • • •

GTP_U data path supervision throughEcho Request/Response messages,only in S1-U Data tunnel Error indication Supported Extension Header Notification

The SCTP (Stream Control Transmission Protocol) is applied for signaling transport in S1-C and in X2-C. SCTP associations are managed with following functions: • •

g

Establishing SCTP association SCTP association supervision by Heartbeat/Heartbeat-ACK messages Note: Operator hints

1. The eNB supports the Quick Failover algorithm in SCTP by introducing a new SCTP path state Potential Failure (PF) due to the introduction of the new Linux kernel 3.10. If the T3-rtx timer expires on an active or idle path, the error counter is incremented. If the error counter exceeds the parameter pf_retrans (hardcoded to 0) then the SCTP path is in state PF. On idle path, eNB ignores the sctpHeartbeatInterval in PF state and sends directly another HB. If this HB is unacknowledged then it increments the error counter and exponentially backs off rto until rto.Max. 2. During association failure, before initiating the SCTP: INIT procedure, eNB sends SCTP: ABORT to MME to close the association. 3. In case and of asymmetrical multihoming eNB and is multihomed no route to MME@C2 is when defined in is thesingle-homed eNB, the eNB is MME not sending Heartbeats to MME@C2. In such a scenario, the association failure at eNB is raised after pathMaxRetrans expiry (instead of assocMaxRetrans). The SCTP association is maintained continuously with MME and with adjacent eNBs as connected via X2. System impact

148

©2016Nokia

DN0978045Issue:04A



Interdependencies between features

This LTE1: S1/X2 Datapath Managementfeature is the basis for all features which handle the S1-Interface or the X2-interface. Impact on interfaces

This feature impacts interfaces as follows: •

S1-Interface

•

X2-Interface

Impact on network management tools

This feature has no impact on network management tools. Management data Alarms

[xref] lists alarms introduced with this feature. Table 61

New alarms A l arm ID

A l arm n ame

7657

BASE STATION CONNECTIVITY DEGRADED

Measurements and counters

The table below lists counters introduced with this feature. Table 62

New counters C o u n t e rI D

DN0978045Issue:04A

C o u n t e rn a m e

M e as u re men t

M8004CRD500

GTP-U ECHO REQUEST FROM S1

LTE Transport Load

M8004CRD501

GTP-U ECHO RESPONSE TO S1

LTE Transport Load

M8004CRD502

GTP-U ERR IND TO S1_X2

M8004CRD503

GTP-U EX HEAD NOTIF FROM S1_X2

LTE Transport Load LTE Transport Load

M8004CRD504

GTP-U EX HEAD NOTIF TO S1_X2

LTE Transport Load

M8004CRD505

GTP-U MSG S1_X2 DISC HEADER

LTE Transport Load

M8004CRD506

GTP-U MSG S1_X2 DISC OTHER

LTE Transport Load

M8004CRD514

Unclassified GTP-U: ERROR INDICATION

LTE Transport Load

M8004CRD515

GTP-U ERR IND FROM X2 DL LTE Transport Load

M8004CRD516

GTP-U ERR IND FROM X2 UL LTE Transport Load

M8004CRD517

GTP-U INCOMING G-PDU

LTE Transport Load

M8004CRD518

GTP-U OUTGOING G-PDU

LTE Transport Load

©2016Nokia

149



New counters (Cont.)

Table 62

C o u n t e rI D

C o u n t e rn a m e

M e as ur e men t

M8004CRD519

GTP-U ECHO REQUEST TO S1

LTE Transport Load

M8004CRD520

GTP-U ECHO RESPONSE FROM S1

LTE Transport Load

M8004CRD521

GTP-U SUPERVISION

LTE Transport Load

M8004CRD522

FAILURE GTP-U SUPERVISION SUCCESS

LTE Transport Load

M8004CRD523

GTP-U ERR IND FROM S1

LTE Transport Load

Key performance indicators

There are no key performance indicators related to this feature. Parameters Table 63

New parameters

F ul l n ame

SGW IP Address List

A b b r e v i a t e d n am e

M an ag e d o bj e c t

Str uctur e

GTPU

-

sgwIpAddress

GTPU

sgwIpAddressList

Maximum number of unanswered N3 requests

gtpuN3Reqs

GTPU

-

GTP-U Path Supervision Interval

gtpuPathSupint

GTPU

-

T3 maximum waiting time for GTP-U responses

gtpuT3Resp

GTPU

-

SCTP association failure retransmission counter

assocMaxRetrans

SCTP

-

Maximum time to wait for for a new SCTP establishment

maxTimeSctpSetup

SCTP

-

SCTP

-

SGW IP Address

s gwIpAddressList

SCTP path failure pathMaxRetrans retransmission counter Minimum rtoMin retransmission timeout

SCTP

-

Maximum rtoMax retransmission timeout

SCTP

-

SCTP heartbeat message interval

sctpHeartbeatInterval

SCTP

-

Sales information

150

©2016Nokia

DN0978045Issue:04A



Sales information

Table 64

BS W/ASW


Activated by default

BSW

3.2 LTE3: S1, X2 and RRC Common Signaling 3.2.1

Description of LTE3: S1, X2 and RRC Common Signaling Introduction to the feature

The Flexi Multiradio BTS supports the following S1, X2 and RRC signaling procedures: UL information transfer Downlink information transfer Reset S1 and Reset resource, initiated either by eNB or by MME Reset X2 Error indication on S1 Error indication on X2 S1 setup X2 setup

• • • • • • • •

Benefits End-user benefits This LTE3: S1, X2, and RRC Common Signalingfeature is a basic requirement, without

call handling would be impossible. Operator benefits

This LTE3: S1, X2, and RRC Common Signalingfeature is a basic requirement, without call handling would be impossible. Requirements Hardware and software requirements Table 65


System release

RL10


LBTS0.5


-

LBTS4.0

OMS

-

LBTSFZ5.0

UE

3GPPR8

N e tA c t

-

NS10

MME

SAG EW

NG10CD2


This feature requires no new or additional hardware. Functional description

DN0978045Issue:04A

©2016Nokia

151



Functional overview

This feature provides the common signaling procedures on S1, X2 and for the information transfer between UE and MME in RRC_CONNECTED UE state. Common S1/X2 Signaling encompasses elementary procedures that are necessary for managing the S1 and X2 LTE/SAE reference points. These elementary procedures are independent of the UE state and in general they use non-UE-associated signaling, with the exception of Error Indication which can use UE-associated signaling if the error is related to a procedure that uses UE-associated signaling. Signaling in RRC_CONNECTED state comprises UE-specific RRC and S1AP signaling when the UE is in the RRC_CONNECTED state. This signaling does not change the UE's state and includes configuration and reporting of measurements and Uplink/Downlink transfer of NAS PDUs. The Flexi Multiradio BTS supports the following S1, X2 and RRC signaling procedures: •

•

•

•

•

•

S1 Reset:

Used by eNB or MME. Signals a S1-MME interface reset to a peer entity. Clears all UE-associated S1 signaling connections on S1 interface for example to recover from erroneous situations. X2 Reset: Used by eNB or MME. Clears all UE-associated X2 signaling connections on X2interface for example to recover from erroneous situations. Error indication on S1: Initiated by an eNB or a MME. Reports detected errors in one incoming message (whenever it is possible), or in the procedure related to that message. Error indication on X2: Initiated by an eNB. Reports errors detected in a message received via the X2 interface. S1 Setup: Initiated by the eNB. Exchanges application level data required for the correct interoperation between the eNB and MME over the S1 interface. X2 Setup: Exchanges application level data required for the correct interoperation between eNBs over the X2 interface. Both the initiating and the receiving eNBs provide their peer eNBs with configuration information, for example, the list of the cells that they serve.

The Flexi Multiradio BTS also supports the UE-associated signaling procedures: •

Uplink Direct Transfer:

Carries UE-to-MME signaling messages (for transport of NAS messages) over the S1 and air interfaces. •

Downlink Direct Transfer : messages (for transport of NAS messages) over the Carries MME-to-UE signaling S1 and air interfaces.

System impact Interdependencies between features

This feature is a basic for all features handling with the S1- , X2- interfaces and all call handling features.

152

©2016Nokia

DN0978045Issue:04A



Impact on interfaces

This feature impacts interfaces as follows: • • •

S1-interface X2-interface RRC common signaling


This feature has no impact on network management tools. Management data Alarms

The table below lists alarms introduced with this feature. Table 66

New alarms A l arm ID

A l arm n ame

7652

BASE STATION NOTIFICATION

7656

BASE STATION CONNECTIVITY LOST

7657


BTS faults and reported alarms

The table below lists BTS faults introduced with this feature. Table 67

New BTS faults

F a u l tI D

F a u l tn a m e

R e p o r t e dal a r ms A l ar mI D

6307

6202

X2 neighbor cell configuration inconsistency

7652

Transport layer connection failure in S1 interface

7656, 7657

A l ar mn a me BASE STATION NOTIFICATION

BASE STATION CONNECTIVITY LOST, BASE STATION CONNECTIVITY DEGRADED

6308

S1 interface setup failure

7656, 7657


6317

S1 interface recovery failure

7656, 7657


6203

DN0978045Issue:04A

Transport layer connection failure in X2 interface

©2016Nokia

7657


153



New BTS faults (Cont.)

Table 67

F a u l tI D

F au l tn a m e

R e p o r t e da l a r ms A l ar mI D

6204

S1 SCTP path failure

A l a r mn a me

7657


6303

X2 interface recovery

7657


failure 6304

X2 interface setup failure

7657



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 new parameters related to the feature: New parameters

Table 68

F u l ln a me

A b b r e v i a t e dn a m e

M a n a g e do b j e c t

MCCinPLMN

mcc

LNBTS

MNCinPLMN

mnc

LNBTS

MNClengthin PLMN

mncLength

eNBname

enbName

LNBTS LNBTS



BSW


-


Yes

3.3 L TE118: Fast Ethernet (FE) / Gigabit Ethernet (GE) Electrical Interface 3.3.1

Description of LTE118: Fast Ethernet (FE) / Gigabit Ethernet (GE) Electrical Interface Introduction to the feature

154

©2016Nokia

DN0978045Issue:04A



The LTE118: Fast Ethernet (FE) / Gigabit Ethernet (GE) Electrical Interface feature introduces Fast Ethernet (FE) / Gigabit Ethernet (GE) electrical interface, supported by the Flexi Transport sub-module. Benefits End-user benefits

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

Ethernet will be the main backhaul option for eNB. Requirements Hardware and software requirements


Table 70 System release

RL10


LBTS0.5


-

-

LBTS4.0

OMS

UE

LBTSFZ5.0 N e tA c t

MME

SAG EW

----



The LTE118: Fast Ethernet (FE) / Gigabit Ethernet (GE) electrical interface feature includes:

•

Fast Ethernet/Gigabit Ethernet interface, which offers 100Base-TX or 1000Base-T connectivity Ethernet 100Base-TX media support Support of electrical Fast Ethernet according to IEEE 802.3 Standard, Clause 24 and 25, as 100 Mbps over two pairs of Category 5 twisted-pair cable. Ethernet 1000Base-T media support Support of electrical Gigabit Ethernet according to IEEE 802.3 Standard, Clause 40, as 1000 Mbps over four pairs of Category 5E twisted-pair cable. RJ45 type cable connectors forFE and GE

• •

Overvoltage protection withrespect to Telecom Ports Mode and speed autonegotiation, forced mode

•

•

•


There are no interdependencies between this and any other feature. Impact on interfaces

DN0978045Issue:04A

©2016Nokia

155



This feature has no impact on interfaces. Impact on network management tools

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

This feature has no impact on system performance or capacity. Management data Alarms

There are no alarms related to this feature. Measurements and counters



There are no parameters related to this feature. Sales information Table 71


BSW


-


Yes

3.4 LTE119: Gigabit Ethernet (GE) Optical Interface 3.4.1

Description of LTE119: Gigabit Ethernet (GE) Optical Interface Introduction to the feature

The LTE119: Gigabit Ethernet (GE) Optical Interfacefeature introduces Gigabit Ethernet (GE) optical interface, supported by the Flexi Transport sub-module. Benefits End-user benefits


Ethernet will be the main eNB backhaul option. If fiber access is available at the site, the Flexi Multiradio BTS can be connected directly. Requirements

156

©2016Nokia

DN0978045Issue:04A






RL10


LBTS0.5


-

-

LBTS4.0

OMS

LBTSFZ5.0

UE

N e tA c t

MME

SAG EW

----



The GE optical interface 1000Base-BX/SX/LX/ZX is supported through an optional SFP module. Connectors for optical fibers are of type LC, according to EIA/TIA-604-10. The 1000Base-BX interface support includes two subtypes: • •

1000Base-BX-D 1000Base-BX-U

Optical transceivers are Class 1 laser certified under any condition of operation, according to IEC 60825-1. System impact Interdependencies between features







DN0978045Issue:04A

©2016Nokia

157




There are no parameters related to this feature. Sales information

Sales information

Table 73

BSW /ASW


BSW

-


Yes

3.5 LTE129: Traffic Prioritization on Ethernet Layer 3.5.1

Description of LTE129: Traffic Prioritization on Ethernet Layer Introduction to the feature

In addition to traffic prioritization on the IP layer, this feature supports traffic prioritization on the Ethernet layer, using packet marking methods (code points) applicable to Ethernet. Benefits End-user benefits


This feature ensures QoS, if the transport network is not IP QoS (DiffServ) aware. This is often the case if traffic aggregation is performed by Ethernet switching, not IP routing. Ethernet based BTS backhaul is recommend due to cost advantages (CAPEX and OPEX). Requirements Hardware and software requirements



RL10


LBTS1.0


-

-

LBTS4.0

OMS

UE


MME

SAE GW

----


This feature requires no new or additional hardware. Functional description

158

©2016Nokia

DN0978045Issue:04A



Functional overview

In addition to traffic prioritization on the IP layer, this feature supports traffic prioritization on the Ethernet layer, using Ethernet priority bits (IEEE 802.1p) to mark data packets. The Ethernet priority bits are set based on the DiffServ Code Point (DSCP) that was assigned by the IP layer. The mapping table is configurable. If traffic aggregation is performed by Ethernet switching rather than by IP routing, the transport network may not be IP QoS (DiffServ) aware. The Flexi Multiradio BTS LTE supports traffic prioritization on the Ethernet layer, as illustrated in . Ethernet priority bits and/or VLAN IDs (IEEE 802.1q) can be set per packet, based on the DiffServ Code Point (DSCP). Figure 13

Traffic prioritization on the Ethernet layer

MME Ethernet

Eth

IP Router (Securit y G W)

Flexi Multimode BTS

S-GW/P-GW

U-plane

C-plane

U-plane

M-plane

(User) IP

C-plane

M-plane

(User) IP

GTP-U

S1AP/X2AP

BTSOM

UDP

SCTP

TC P

Q oS marking

IP EthMac EthPhy

GTP-U

S1AP

UD P

SCTP

IP Ethernet Switching Et hPh y

Et hPh y

BTSOM TC P

IP

IP

EthMac

EthMac

EthMac

EthPhy

EthPhy

EthPhy

There are three Priority Code Point ( PCP) bits available in the VLAN tag, which allows indicating eight priority levels in the range 0 ...7. The PCP bits are determined by mapping the layer 3 DSCP priority to layer 2. ARP messages are always assigned the highest priority, PCP = 7. The table for mapping DSCP values to VLAN PCP bits may cover the whole DSCP value range (0 ... 63) and by default contains 14 entries so that the full range of Per-hop Behavior (PHB) values is covered. System impact Interdependencies between features





DN0978045Issue:04A

©2016Nokia

159






There are no parameters related to this feature. Sales information

Sales information

Table 75

BSW /ASW


BSW

-


yes

3.6 LTE131: Traffic Prioritization on IP Layer (Diffserv) 3.6.1

Description of LTE131: Traffic Prioritization on IP Layer (Diffserv) Introduction to the feature

The DiffServ is the most common way of traffic prioritization on IP layer. Benefits End-user benefits


This features ensures reliable system control, supporting different classes of user service. Requirements Hardware and software requirements



RL10


LNBTS1.0


-

160

-

LNBTS4.0

OMS

UE

LNBTSFZ5.0 N e tA c t

MME

SAE GW

----

©2016Nokia

DN0978045Issue:04A





DiffServ is the most common way of traffic prioritization on the IP layer. The Flexi Multiradio BTS LTE supports QoS differentiation based on DiffServ Code PointsDSCP ( values) as defined in RFC2474 and RFC2475. The DiffServ code point is contained in the Type of Service (ToS) field of a packet’s IP header as per RFC791. QoS differentiation between user, control, and management plane traffic is outlined in . A QoS Class Identifier (QCI) is assigned to all LTE U-plane traffic types. The QCI is in turn mapped to a DSCP value. QCI is not assigned to certain traffic types; however, DSCP assignments are in place for these traffic types (see ). Traffic end points (eNB, S-GW, MME, O&M/NetAct) put the DSCP values into the IP header of outgoing packets. To provide proper QoS, the elements of the intermediate network have to handle the packets according to these priority settings. If a part of the backhaul network is implemented using Ethernet (layer 2) switching rather than IP (layer 3) routing, there might still be DSCP information available. The Flexi Multiradio BTS LTE offers a means to apply prioritization on the Ethernet layer, see LTE . 129: Traffic Prioritization on Ethernet layer To apply traffic prioritization based on DSCP values, the Flexi Transport sub module performs packet scheduling using six queues with Strict Priority Queuing (SPQ) and WFQ (Weighted Fair Queuing). Each Service Data FlowSDF ( ) is associated with a QoS Class Identifier (QCI). The mapping between QCI and DSCP values is configurable as per 3GPP TS 23.401. Figure 14 QoS differentiation between user, control and management plane traffic

MME any

IP IP Router (Security GW)

Flexi Multimode BTS

S-GW/P-GW

U-plane

C-plane

S-plane

U-plane

M-plane

(User) IP GTP-U

S1AP /X2AP

PTP

BTSOM

UD P

SCTP

UDP

TC P

Qo S mapping (DSCP)

IP

S-plane

M-plane

GTP-U

S1AP

PTP

UDP

SCTP

UDP

IP

IP

IP

IP

BTSOM TCP IP

L2

L2

L2

EthMac

EthMac

EthMac

EthMac

L1

L1

L1

EthPhy EthPhy

EthPhy

EthPhy

EthPhy

Table 77

Default DSCP/PHB mapping for traffic types without QCI assigned

Traffic type

C-planetrafficonS1/X2

DN0978045Issue:04A

C-plane

(User) IP

DSCP (decimal)

46

PHB

EF

M-planetraffic

34

AF41

S-plane traffic (Timing over Packet)

46

EF

©2016Nokia

161


Table 77


Default DSCP/PHB mapping for traffic types without QCI assigned (Cont.)

Traffic type

ICMPtraffic(allmessages)

DSCP (decimal)

PHB

10

IKE traffic

34

AF11 AF41

Tracingtraffic

20

AF22

GTP-Upathmanagement

46

EF

g

Note: The listed DSCP values are configurable except for Tracing traffic and GTP-U

g

Note: During reconfiguration/setup of the BTS Firewall, for example during startup,

path management traffic (these traffic types uses fixed DSCP values).

there may be a short phase, in which ICMP messages are transmitted with DSCP 0 instead of the configured value. System impact Interdependencies between features








162

©2016Nokia

DN0978045Issue:04A


Table 78


New parameters for LTE131: Traffic Prioritization on IP Layer (Diffserv)

Full name

Abbreviated name

Managed Object

QOS traffic priorisation enabling flag

qosEnabled

IEIF

QOS traffic priorisation enabling flag

qosEnabled

IVIF

Per Hop Behaviour queue weight list

perHopBehaviourWeightList

QOS

Assured Forwarding Class 1 Weight Value

assuredForwardingClass1

QOS



QOS


assuredForwardingClas3

QOS



QOS

Best Effort Weight Value

bestEffort

QOS

Quality of Service configuration identifier

qosId

QOS

Table for mapping DSCPs to PHBs and PCP bits

dscpMap

DSCP

dscp

QOS

Per Hop Behaviour

pHB

QOS

VLAN priority bits

vlanPrio

QOS

Table for mapping traffic types to DSCPs

trafficTypesMap

QOS

QOS

Traffic type name

trafficType

QOS

DSCP

dscp

QOS

Overwrite DSCP in SSE messages

sseDscpOverwrite

QOS



BSW

DN0978045Issue:04A


-

©2016Nokia


Yes

163



3.7 LTE132: VLAN based traffic differentiation 3.7.1

Introduction to the Feature The LTE132: VLAN based traffic differentiation feature provides the support of traffic differentiation on layer 2. The Flexi Multiradio BTS LTE inserts VLAN IDs (IEEE 802.1q) into packet headers of egress traffic, based on their traffic type (U/C/M/S-plane). The traffic-type-to-VLAN mapping table is configurable. Each VLAN is associated with a dedicated IP address at the evolved node B.

3.7.2

Benefits This feature supports virtually separate networks for User, Control, Management and Synchronization Plane. Different types of traffic can be routed through different L2 network paths, with different QoS capabilities.

3.7.3 3.7.3.1

Requirements Software Requirements The following software is required for this feature: Table 80


Network element


Systemrelease

RL10

eNB

LBTS1.0

MME

-

NetAct SAE GW

3.7.3.2

OSS5.2CD3 -

Hardware Requirements This feature requires Flexi Transport sub-modules which support LTE.

3.7.4

Functional Description Traffic differentiation can in principle be performed on several layers:

164

•

L3: Using different IP subnets

•

L2: Using different VLANs

•

Each VLAN is terminated with a dedicated IP address at the eNB. L1: Using different physical paths

©2016Nokia

DN0978045Issue:04A



L1 traffic differentiation requires multiple physical interfaces of an NE. This is not supported in the current release. VLAN based traffic differentiation is an optional feature. The eNB supports 1, 2, 3, or 4 VLANs if the feature is enabled, and one single VLAN if the feature is disabled. UL and DL traffic are always carried in the same VLAN. The following maximum numbers of VLANs are supported per eNB: Table 81

Supported numbers of VLANs

VLAN

g

Main usage

Number of PHB queues

6

Associated IP network interface

VLAN#1

mainly for U-plane; optionally also for C-, M- and S-plane

IP network interface#1

VLAN#2

C-plane

1

IPnetworkinterface#2

VLAN#3

M-plane

1

IPnetworkinterface#3

VLAN#4

S-plane (Timing over Packet)

1

IP network interface#4

Note: The number of VLANs, six-queue scheduler and single-queue scheduler

mentioned in this document for RL10 can increase with newer releases and HW. VLAN based traffic differentiation can be used for various purposes. First, there may be a need to separate traffic of different planes (eNB applications) from each other for network planning reasons. For example, M-plane traffic may need to be separated from U/C/Splane traffic. Or, traffic may be split into multiple paths which have different QoS capabilities (path selection). The Flexi Multiradio BTS LTE inserts VLAN IDs (IEEE 802.1q) into packet headers of egress traffic, based on the traffic type (U/C/M/S-plane). The mapping table is configurable. Each VLAN is associated with a dedicated IP address at the evolved node B.

3.7.4.1

Network Scenarios with VLAN based Traffic Differentiation The following network scenarios for VLAN based traffic differentiation are supported: Multipoint-to-multipoint VLANs

In this scenario, the VLANs are operated in a multipoint-to-multipoint configuration. In terms of the Metro Ethernet Forum, the VLAN provides an "E-LAN service". Each of the VLANs (upintoall four) is identified single VLAN (VLAN ID) which is configuredthe identically eNBs and alsoby in athe VLAN GW.identifier Depending on the X2 configuration, X2 traffic can be switched between different eNBs directly in the Ethernet network, or routed (in the IP layer) in the VLAN GW or in the SEG. If IPsec is employed, X2 interfaces have to be set-up as an IPsec star, seeX2 interface via IPsec Star Configuration.

DN0978045Issue:04A

©2016Nokia

165


Figure 15


Multipoint-to-multipoint VLAN Ethernet Transport VLAN Network GW

S1/X2

SEG

VLAN #1

S-

S - GW

eNB VLAN #4

MME

MME

S1/X2

Local Operator Network

VLAN #1

eNB

O&M

VLAN #4

ToP

Point-to-point VLAN

In this scenario the VLANs are operated in a point-to-point configuration. In terms of the Metro Ethernet Forum, the VLAN provides an "E-LINE service". Each VLAN is identified by an individual VLAN ID which is configured at a eNBs and at the VLAN GW. Point-topoint VLAN requires more configuration effort than multipoint-to-multipoint VLAN but allows more fine-grained traffic management on a per-link basis. Figure 16

Point-to-Point VLAN

S1/X2

Ethernet Transport VLAN GW Network

SEG

VLAN #1

S-

S- GW

eNB VLAN #4

MME

MME Local Operator Network

S1/X2 eNB

VLAN #n+1 VLAN #n+4

O&M ToP

To avoid excessive configuration effort, separate (direct) Point-to-Point VLANs between individual eNBs for the X2 interfaces have been precluded. Depending on the X2 configuration, X2 traffic can be routed in the VLAN GW or the SEG. If IPsec is employed, X2 interfaces have to be set-up as an IPsec star, see X2 interface via IPsec Star Configuration. In both scenarios, the endpoints of the VLANs at the eNB are identified by separate IP addresses.

3.7.4.1.1

X2 interface via IPsec Star Configuration The eNB supports X2 interfaces towards up to 32 adjacent eNB nodes. An X2 interface comprises an X2_C interface (signaling) and an X2_U interface (user data). In scenarios without IPsec, the traffic between a pair of eNBs can be switched/routed directly by the switches/routers of the transport network. If IPsec is used on the X2 interfaces, all X2 traffic is carried via the Security Gateway (SEG). Figure 17: IPsec star configuration shows the principle of this IPsec star configuration for X2:

166

©2016Nokia

DN0978045Issue:04A



IPsec star configuration

Figure 17 eNB eNB UP IP Addr.

eNB Interface IP Addr. #1

eNB CP IP Addr.


SEG

X2_U

Eth.

MME X2_C

adjacent eNB eNB UP IP Addr.


eNB CP IP Addr.


S- GW

S-GW IPSec Tunn.Addr. #1

Router X2_U S-GW IPSec Tunn.Addr . #2

Eth. X2_C

IPsec tunnel pair for X2_U IPsec tunnel pair for X2_C

X2_U connection X2_C connection

The eNB transport subsystem uses a single IPsec tunnel pair towards the SEG for all X2_C traffic to/from its adjacent eNBs, and a single IPsec tunnel pair towards the SEG for all X2_U traffic to/from its adjacent eNBs. If an eNB uses a common address for Cand U-plane, the transport system combines the X2_C and X2_U traffic in a single IPsec tunnel pair which is dedicated to all X2 interfaces. The X2 packets are mapped into one of the outgoing X2 IPsec tunnels based on their destination IP address. A packet is mapped to an IPsec tunnel if its destination address (that is, either the C- or U-plane address of an adjacent eNB) matches a preconfigured subnet address. You can configure one subnet address for the CP addresses of all eNBs and one subnet for the UP addresses of all eNBs. The subnet addresses must be preconfigured when taking an eNB into service. The address range of the CP subnet (Adj eNB CP Subnet Address) must include the CP addresses of all eNBs which might become adjacent eNBs. Similarly, the address range of the UP subnet (Adj eNB UP Subnet Address) must include the UP addresses of all eNBs which might become adjacent eNBs. The X2 packets are sent to the SEG through (one of) the dedicated X2 IPsec tunnel(s). In the SEG, the received X2 packets are decrypted. The application level packets are then forwarded to the appropriate DL IPsec tunnel based on their destination IP address (the SEG has dedicated X2 IPsec tunnel pairs to all eNBs, and thus it also has the CP/UP addresses of all eNBs). The X2 packets are IPsec encrypted and sent to the addressed eNB.

3.7.4.2

VLAN based Traffic Differentiation: Mapping of DL Packets in the Security Gateway When using VLAN based traffic differentiation, the Security Gateway supports mapping of the DL packets into up to four IPsec tunnels towards each eNB. One separate IPsec tunnel is needed per VLAN.

DN0978045Issue:04A

©2016Nokia

167


3.7.4.3


VLAN based Traffic Differentiation: Mapping of DL Packets in the VLAN Gateway The VLAN Gateway (at the border of the L3 and L2 networks) supports termination of the layer 2, including VLAN functionality. The VLAN Gateway supports termination of up to four VLANs towards each eNB. The DL packets are distributed over the VLANs based on the Destination Address contained in the IP header.

3.7.5

Sales Information Table 82

Sales Information

BSW/ASW

ASW

3.7.6

Licensecontrol in network element

-


-

User Interface

3.7.6.1

Parameters Table 83: Parameters related to the LTE132: VLAN based traffic differentiation shows the parameters related to the LTE132: VLAN based traffic differentiation feature.

Table 83 Name vlanIfNetId

localIpAddr

Parameters related to the LTE132: VLAN based traffic differentiation Object

IVIF

IVIF

Description

Range/step

Default value

This parameter identifies the VLAN interface object. Value is 1 to 5. Up to 5VLANs may exist on the BTS. The 5th VLAN is used by LTE491: FlexiPacket Radio Connectivity.

1...5

1

This parameter specifies the IP address of the VLAN network interface towards the external transport network. It is accompanied with a subnet mask.

7...15 characters

-

-

step: 1

To be entered in dotted decimal format. netmask

IVIF

This parameter specifies the network mask for the IP address of the VLAN network interface in the external transport network. To be entered in dotted decimal format.

7...15 characters

vlanId

IVIF

This parameter specifies the VLAN identifier number of the VLAN network interface.

0...4094

sir

168

IVIF

-

step: 1

This parameter holds the shaper 100...1.000.000 kbps, information rate for a specific vlan interface.

©2016Nokia

1.000.000 kbps

DN0978045Issue:04A



Parameters related to the LTE132: VLAN based traffic differentiation (Cont.)

Table 83

Name

Object

Description

Range/step

Default value

step: 100 kbps sbs

IVIF

This parameter holds the shaper burst size for a specific vlan interface.

1522...2.000.000 octets, step: 1 octet

qosEnabled

IVIF

This parameter specifies if multiple PHB queues are used over this VLAN interface or only a single one. Multiple PHB queues allow DSCP based traffic priorisation.

0 (false), 1 (true)

wfqSchedQueu IVIF eWeight

This is the weight value to be used in the WFQ aggregation scheduler for this VLAN interface.

1..10000

wfqSchedQueue IEIF Weight

This is the weight value to be used in the WFQ aggregation scheduler for this VLAN interface.

1..10000

vlanMapId

IVMP

vlanMap ulTrafficPath vlanPtr

IVMP

IdentifieroftheVLANMap

VMP I IVMP

3.7.6.2

1000

1000

step: 1 1

-

NumberoftheUL-trafficpaths

false

step: 1

1

Structureof"vlanMap"

1522 octets

1...4

Reference to the corresponding VLAN i.e. MOI IVIF

-

-

Alarms This section lists alarms related to the LTE132: VLAN based traffic differentiation feature. There are no alarms for the LTE132: VLAN based traffic differentiation feature.

3.7.6.3

Measurements and Counters Table 84: Counters for the LTE132: VLAN based traffic differentiation shows the measurements and counters related to the LTE132: VLAN based traffic differentiation feature. Table 84

Counters for the LTE132: VLAN based traffic differentiation

Counter

ifInPackets15

DN0978045Issue:04A

Number

M51127C0

©2016Nokia

Description

The number of IP packets received on the VLAN interface that were delivered to higherlayer protocols.

169


Table 84

Counters for the LTE132: VLAN based traffic differentiation (Cont.)

Counter

3.7.7


Number

Description

ifInOctets15

M51127C1

The total number of kilo-octets received on the VLAN interface, including framing characters.

ifOutPackets15

M51127C2

The number of IP packets that were successfully transmitted over the VLAN interface.

ifOutOctets15

M51127C3

The total number of kilo-octets transmitted over the VLAN interface, including framing characters.

ifInErrors15

M51127C4

The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.

ifOutDroppedPackets

M51127C5

The number of total outbound packets that were dropped in the IP scheduler due to congestion.

ifOutDroppedOctets

M51127C6

The number of total outbound kilo-octets that were dropped in the IP scheduler due to congestion.

Activating and Configuring the Feature For activating and configuring the feature, see Feature Activation Instruction

3.8 LTE134: Timing over packet 3.8.1

LTE134: Timing over Packet Introduction to the feature

The Timing over Packet (ToP) solution consists of a Timing Master (ToP Master) at the core site, and Timing Slaves (ToP Slaves) implemented in the eNBs. The master and the slaves communicate through the IEEE 1588 v2 protocol. The ToP Master sends synchronization messages via the Ethernet/packet network to the slaves. The ToP Slaves recover the synchronization reference from these messages.

3.8.1.1

Benefits The LTE134: Timing over Packet (ToP) feature provides CAPEX/OPEX savings, as separate TDM links or GPS reception are no longer needed for providing a frequency synchronization reference for the eNBs. The feature requires sufficient Ethernet/packet network quality in terms of low frame/packet delay variation.

3.8.1.2

Requirements Software requirements

170

©2016Nokia

DN0978045Issue:04A



The following software is required for this feature: Table 85


Network element


Systemrelease

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

Hardware requirements

This feature requires Flexi Transport sub-modules which support LTE.

3.8.1.3

Functional Description Timing-over-Packet (ToP) is one of the available methods to support synchronization if a Flexi Multiradio BTS LTE is connected through IP/Ethernet backhaul.The ToP solution consists of a Master Clock (ToP Master) at the core site and Slave Clocks (ToP Slave) implemented in the eNBs. Master and the slaves communicate through synchronization messages via the Ethernet/IP network. The slaves recover the synchronization reference from these messages. This synchronization is required to maintain a stable frequency of the eNBs’ air interface. The Timing over Packet solution is based on the IEEE 1588-2008 standard. All supported IEEE 1588-2008 functions and features are compliant with this standard.

3.8.1.3.1

ToP Master The current ToP solution supports one single TP Master which may be supplemented by a redundant element. The eNB ToP Slaves are configured with the IP address of the ToP Master (“Unicast discovery” as specified in clause 17.5 of IEEE 1588-2008). ToP Master Redundancy

For more reliability, the ToP Master may support redundancy. If the primary ToP Master fails, the redundant ToP Master is taken into service and takes over the IP address that was previously used. At any given time, only one ToP Master, either the primary or the redundant one, may be active. Seen from the eNB ToP slave, there is one single IP address under which it finds the (one and only) ToP Master that is active in the system. After a switch-over from primary to redundant ToP Master, the eNB ToP Slave has to resolve the MAC address of the active ToP Master.

DN0978045Issue:04A

©2016Nokia

171


3.8.1.3.2


ToP Slave The eNB ToP Slave recovers the timing reference based on the messaging between it and the ToP Master. The ToP Slave generates an indication when it is out of lock. The maximum value for the ToP Slave locking time is 15 min. The locking time achieved with a certain SYNC packet rate depends on the packet delay variation in the network between Master and Slave. High packet delay variation may lead to longer locking times.

3.8.1.3.3

Support of IEEE 1588 Event Messages IEEE 1588-2008 specifies a set of messages of various types. For frequency synchronization, only the SYNC event message is required. IEEE 1588 event messages are timed messages, that is, a timestamp is generated both at transmission and receipt of the message. SYNC event messages are used to generate and communicate the timing information needed to synchronize the ToP Slaves. Apart from the SYNC event message, master and ToP Slaves also support the following IEEE 1588 general messages: •

•

Signaling message Signaling messages are used for unicast negotiation between ToP Master and ToP Slaves. ANNOUNCE message ANNOUNCE messages are used to establish the synchronization hierarchy. Another purpose of this message is to find the best master clock under use of the Best master clock algorithm, which in the LTE system is irrelevant since there is only one ToP Master.

The messages are exchanged using the PTP (Precision Time Protocol) protocol, which is carried in a protocol stack that has PTP over UDP over IP. The UDP source and destination ports are • •

319 for event messages 320 for unicast general messages

On the IP layer, the “time-to-live” field of IP packets used for ToP messages is set to 255. The QoS mechanism implemented in the LTE system also supports DiffServ for ToP traffic. By default, the DSCP value for packets with ToP traffic is set to 46, which is mapped to the highest per-hop-behavior, EF (Expedited Forwarding). 3.8.1.3.3.1

Unicast Negotiation

Unicast negotiation serves to initiate and maintain a unicast connection between ToP Master and a ToP Slave. Through unicast negotiation, a ToP Slave requests the ToP Master to transmit unicast SYNC and ANNOUNCE messages to it. This is done by exchanging Request_Unicast_Transmission and Grant_Unicast_Transmission TLVs (type, length, value messages): 1. The ToP Slave sends a signaling message containing the Request_Unicast_Tranmission TLV which includes the requested message type (SYNC or ANNOUNCE), rate and the requested duration of unicast transmission:

172

©2016Nokia

DN0978045Issue:04A



•

• •

The SYNC message rate can be chosen between 8/s, 16/sand 32/s, with a default of 16/s. In high-quality networks, lower message rates can be used. The RL10 eNB uses a fixed value of 300 s as the duration of Unicast transmission in the Request_Unicast_Transmission TLV. The ANNOUNCE message rate is set to a fixed value of 0.5/s (that is, once per 2 s).

2. The ToP Master confirms the requested unicast transmission with a Grant_Unicast_Transmission TLV which contains the granted message rate and the granted duration. If the requested message rate cannot be provided, the ToP Master rejects the request by setting the “duration” field to 0. Once a unicast transmission is set-up, the ToP Slave receives messages until the grant duration expires. The ToP Slave requests a new Unicast grant well before the current grant duration has expired. If no Unicast grant is received (for example because of transport failures), the ToP Slave repeats its request after a timeout of 5 s. It repeats the request two more times if no grant is received. If still no grant is received, the ToP Slave raises an alarm.

3.8.1.4

Management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation. Alarms




Table 86: Parameters related to the LTE134: Timing over packet feature shows the parameters related to the LTE134: Timing over packet feature. Table 86

Parameters related to the LTE134: Timing over packet feature

Name

Object

Description

administrativeState

TOPIK

Used to lock and unlock the TOP object instance. Locking the object deactivates it and supresses

logMeanSyncValue

TOPIK

This indicates how often a ToP sync message shall be send by the ToP master within the transmission duration request period. (The transmission duration request period is currently fixed to 300 seconds.) The following values are defined:

Range

Default

locked (0), unlocked (1)

-

-5...-3, step 1

-4

all its alarms.

•

DN0978045Issue:04A

-3: 8 per second

©2016Nokia

173


Table 86


Parameters related to the LTE134: Timing over packet feature (Cont.)

Name

masterIpAddr

Object

TOPIK

Description •

-4: 16 per second

•

-5: 32 per second

Range

IP address of the in ToP master. Format: this is an IPv4 IP address dotted decimal form.

Default

7...15 characters

-

Examples: IPv4: 10.12.11.0 TOPIK

topId

3.8.1.5

1...1, step 1

-


3.8.1.6

This parameter identifies the Timing Over Packet configuration of the FTM. The value is always 1.

Sales information

BSW/ASW

License control in network element License control attributes

ASW

-

-

Activating and configuring the feature For activating and configuring the feature, see Feature Activation Documentation.

3.9 LTE138: Traffic Shaping (UL) 3.9.1

Description of LTE138: Traffic Shaping (UL) Introduction to the feature

The LTE138: Traffic Shaping (UL)is a Flexi Transport sub-module feature, applicable to Ethernet interfaces, to reduce the burstiness of the traffic. Benefits End-user benefits


The Ethernet interface (FE or GE) may support a data rate (100Mbit/s or 1000Mbit/s) and burst size higher than the capacity of the Ethernet backhaul link. Traffic shaping is required to ensure conformance to the limited link capacity in order to avoid packet loss. This applies in particular to Ethernet leased lines where the link capacity is governed by a Service Level Agreement (SLA).

174

©2016Nokia

DN0978045Issue:04A



Requirements Hardware and software requirements



RL10


LBTS1.0


-

-

LBTS4.0

OMS

UE


MME

SAG EW

----



Traffic shaping is a means to ensure that a defined peak throughput in transmit direction is not exceeded, even at times when more packets are delivered to the transmitting device. If a connection is unshaped, the peak rate might be exceeded (and all surplus data might be discarded by the receiving network node) or surplus data must be discarded in the transmitting device. If the connection is shaped, surplus data packets are buffered and scheduled for transmission at a later time when the ingress is lower . Thus, traffic shaping enforces the peak transmission rate of the egress traffic, at the expense of a higher transfer delay. Traffic shaping is required to ensure conformance to the limited link capacity in order to avoid packet loss. This applies in particular to Ethernet leased lines, where the link capacity is governed by a Service Level Agreement SLA ( ). Traffic shaping reduces the burstiness of Ethernet or IP traffic in conformance with a given: • •

maximum average output rate on Ethernet or IP layer maximum burst size on Ethernet or IP layer

If packets need to be dropped despite shaping, this is done based on priorities (QoS aware). The eNB performs single-stage traffic shaping in UL direction according to [MEF10.1] chapter 10.3, with a shaping granularity of 100 kbit/s, exceeding the requirements of [MEF11]. Shaping can be applied per L2 interface, that is, per physical Ethernet interface or per VLAN. In consequence, traffic can be shaped per traffic type (U/C/M/S-plane) if VLAN differentiation is used accordingly. Shaping in DL direction is supported per bearer at the SAE-GW. eNB level shaping is recommended to be done by the Edge Router, which routes the traffic into one or more VLANs (EVCs) per eNB. System impact Interdependencies between features

There are no interdependencies between this and any other feature.

DN0978045Issue:04A

©2016Nokia

175










Parameters for LTE138: Traffic Shaping (UL)

Full name

Abbreviated name

Shaperburstsize

sbs

Managed Object

IEIF

Total Shaper Burst Size

sbsTotal

IEIF

Shaperinformationrate

sir

IEIF

Total shaper information rate

sirTotal

IEIF

Traffic Path Shaping Enabling Flag

trafficPathShapingEnable

IEIF

Take ethernet overhead into account when shaping

upperLayerShaping

IEIF

There are no modified or existing parameters related to this feature. Sales information Table 90


BSW

176


-


-

©2016Nokia

DN0978045Issue:04A



3.10 LTE664: LTE Transport Protocol Stack 3.10.1

Description of LTE664: LTE Transport Protocol Stack Introduction to the feature

The LTE664: LTE Transport Protocol Stackfeature provides eNB protocol stacks for User, Control and Management Plane Benefits End-user benefits


The IP based protocol stack enable lower transport cost and easier planning & configuration. The single IP address feature simplifies network configuration. Requirements Hardware and software requirements



RL10


LBTS0.5


-

-

LBTS4.0

OMS

UE


MME

SAG EW

----



This feature introduces the eNB protocol stacks for User, Control, and Management Plane. All protocol stacks for user (U), control (C), management (M) and (optionally) synchronization (S) planes are based on IP. It includes the fundamental transport functions that are necessary to support eNB interfaces S1 and X2 (user and control plane) as well as eNB remote management (M-plane). System impact Interdependencies between features


This feature has no impact on interfaces.

DN0978045Issue:04A

©2016Nokia

177





This feature has no impact on system performance or capacity. Management data BTS faults and reported alarms Table 92

New BTS faults

F a u l tI D

F au l tn a m e


A l a r mn a me

61029

LOSon unit $U, 7665 [Ethernet] interface $IF

BASESTATION TRANSMISSION ALARM

61600

FTM_LOSS_OF_CAR RIER


7665




New parameters for LTE664: LTE Transport Protocol Stack

Full name

IP address of the plain Ethernet network interface

Abbreviated name

localIpAddr

Managed Object

IEIF

Maximumtransferunit

mtu

IEIF

BTSidentifier

btsId

IPNO

Subnet mask of the plain Ethernet network interface

netmask

IEIF

BTS subnet IP address

ftmBtsSubnetAddress

Prefix length for the BTS subnet

ftmBtsSubnetPrefixLength

IPNO IPNO

Sales information

178

©2016Nokia

DN0978045Issue:04A



Sales information

Table 94

BS W/ASW


ASW

-


Yes

3.11 LTE707: Flexi Transport Sub-module FTIB 3.11.1 Description of LTE707: Flexi Transport Sub-module FTIB Introduction to the feature

The FTIB transport sub-module provides two Gigabit Ethernet (GE) and four E1/T1/JT1 interfaces. In addition, it supports Timing-over-Packet (ToP) and Synchronous Ethernet. Benefits End-user benefits


The FTIB is the cost optimized solution suitable for the majority of sites. Requirements Hardware and software requirements



RL10


LBTS1.0


-

-

not supported

OMS

UE

not supported N e tA c t

MME

SAG EW

----



The FTIB transport sub-module provides two Gigabit EthernetGE ( ) and four E1/T1/JT1 interfaces. In addition, it supports Timing-over-Packet (ToP) and Synchronous Ethernet. FTIB is the cost optimized solution suitable for the majority of sites. FTIB provides the following physical interfaces: •

•

DN0978045Issue:04A

Interface 1: GE SFP receptacle, which can be optionally equipped. If this interface is used, interface 2 is deactivated. Interfaces 2, 3: GE 100/1000Base-T (electrical, RJ45 connector), supporting ToP based on IEEE1588-2008 and Synchronous Ethernet based on ITU-T G.8261

©2016Nokia

179


•


Interfaces 4, 5, 6, 7: E1/T1/JT1 symmetrical, RJ48 connector

FTIB provides HW support for the following features: •

•

U/C/M-plane security based on IPSec (160Mbit/s DL and UL throughput performance) Ethernet switching with GE speed

Figure 18

FTIB module






New BTS faults

F a u l tI D

F au l tn a m e


61029

A l a r mn a me






There are no parameters related to this feature.

180

©2016Nokia

DN0978045Issue:04A



Sales information

Sales information

Table 97

BS W/ASW


BSW

-


-

3.12 LTE710: Synchronization from PDH Interface 3.12.1

Description of LTE710: Synchronization from PDH Interface Introduction to the feature

The LTE710: Synchronization from PDH Interfacefeature introduces base station frequency synchronization from a E1/T1/JT1 interface Benefits End-user benefits


Existing E1/T1/JT1 backhaul links can be used for base station frequency synchronization. Requirements Hardware and software requirements



RL10


LBTS1.0


-

-

LBTS4.0

OMS

UE

notsupported N e tA c t

MME

SAG EW

----



This feature contains the support of synchronization from a 2.048/1.544 Mbit/s signal according to ITU-T G.703 that is provided to the E1/T1/JT1 interface of the Flexi System Module. Existing E1/T1/JT1 links can therefore be used for base station frequency synchronization. The E1/T1/JT1 line clock has to be traceable to a Primary Reference Clock (PRC). System impact

DN0978045Issue:04A

©2016Nokia

181



Interdependencies between features





New BTS faults

F a u l tI D

F au l tn a m e


A l a r mn a me

61028

LOFon unit$U, interface $IF

7665


61151

AISon unit $U, interface $IF

7665


61150

LOMF on slot $U, interface $IF

7665


61152

RDI on unit $U, interface $IF

7665


61104

EBER on unit $U, interface $IF

7665


61058

Synchronization lost

61059

$Protocol Timing source lost [on unit $U] [, interface $IF]

7665

BASE STATION TRANSMISSION ALARM

7665





182

©2016Nokia

DN0978045Issue:04A



Table 100

New parameters for LTE710: Synchronization from PDH Interface

Full name

Abbreviated name

Administrative state

administrativeState

PDH line build out (transmitter signal attenuation

pdhLbo

PDHlinetype

PPTT PPTT

pdhLineType

PDH interface identifier

Managed Object

PPTT

pdhPSTTPId

PPTT

The synchronization sources of the BTS

synchroSourceList

STPG

Protocol of the clock source

clockProtocol

STPG

Interface number of recovered clock source

interfaceNumber

STPG

Clock source priority

priority

STPG

Synchronisation protection group identifier

timingGenPgId

STPG

Clock synchronization configuration identifier

syncId

SYNC


Sales information

BS W/ASW

BSW


-


-

3.13 LTE711: Synchronization from 2.048 MHz Signal 3.13.1

Description of LTE711: Synchronization from 2.048 MHz Signal Introduction to the feature

The feature LTE711: Synchronization from 2.048 MHz Signalsupports base station frequency synchronization from a 2.048MHz G.703 signal Benefits End-user benefits

DN0978045Issue:04A

©2016Nokia

183




An G.703 compliant 2.048MHz signal can be used to frequency synchronize the BTS. The G.703 2.048MHz signal is also a common signal used for testing and can be used with many measurement equipments. Requirements Hardware and software requirements



RL10


LBTS1.0


-

-

LBTS4.0

OMS

notsupported

UE

-

N e tA c t

MME

SAE GW

----



This feature contains the support of synchronization from a 2.048MHz signal provided to the SYNC input of the Flexi System Module. The input signal accuracy should comply with ITU-T G.812.

g

Note: not supported on FZM System impact Interdependencies between features





There are no alarms related to this feature.

184

©2016Nokia

DN0978045Issue:04A






New parameters for LTE711: Synchronization from 2.048 MHz Signal

Full name

Abbreviated name

Managed Object

The synchronization sources of the BTS

synchroSourceList

STPG

Protocol of the clock source

clockProtocol

STPG

Interface number of recovered clock source

interfaceNumber

STPG

Clock source priority

priority

STPG


Sales information

BS W/ASW

ASW


-


Yes

3.14 LTE713: Synchronous Ethernet 3.14.1

Introduction to the Feature The LTE713: Synchronous Ethernet differentiation feature provides base station frequency synchronization from the Ethernet interface as per G.8261. Synchronization is extracted from an Ethernet signal which is provided to the Flexi Transport sub-module. This requires that all nodes in the distribution chain supports the Synchronous Ethernet feature asapplicable per G.8261. through the LTE713: Synchronous Ethernet feature is onlySynchronization for FDD systems.

3.14.2

Benefits Synchronization from the Ethernet interface eliminates the need for a GPS receiver at the eNB site if TDM based synchronization or other synchronization methods are not available. Synchronous Ethernet provides synchronization in a TDM-like deterministic manner.

DN0978045Issue:04A

©2016Nokia

185


3.14.3 3.14.3.1


Requirements Software Requirements The following software is required for this feature: Table 105


Network element

3.14.3.2


Systemrelease

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

Hardware Requirements This feature requires Flexi Transport sub-modules which support LTE.

3.14.4

Functional Description Synchronous Ethernet is one of the possible frequency reference sources for an eNB. With the LTE713: Synchronous Ethernet feature activated, Synchronous Ethernet as specified in ITU-T Recommendations G.8261, G.8262 and G.8264 can be used for distributing a high quality synchronization reference in the Ethernet transport environment. With Synchronous Ethernet, the timing reference is traceable to a Primary Reference Clock (PRC). The Flexi Multiradio BTS LTE is HW-prepared for later upgrade which allows to generate the clock for the radio interface cards from an Ethernet interface, using Synchronous Ethernet according to ITU-T G.8261. This upgrade might require additional HW to be installed even though it is intended to re-use existing HW. The wander of the timing reference shall be in limits specified for traffic interfaces in ITUT Recommendation G.823. For North American digital hierarchy, the wander shall be in limits specified for traffic interfaces in ITU-T Recommendation G.824. In addition to synchronization interfaces mentioned in ITU-T Recommendations G.823 and G.824, an EEC interface can be used as reference for Synchronous Ethernet. In this case, the wander shall be in the limits specified for EEC interface network limits in ITU-T Recommendation G.8261, chapter 9.2.1.

3.14.4.1

Synchronization Status Messages (SSM) Synchronization status messages carry the information about the quality of incoming SyncE reference signal.

186

©2016Nokia

DN0978045Issue:04A



The Flexi Multiradio BTS LTE supports the reception of SSMs as specified in ITU-T Recommendation G.8264 section 10. Since an eNB always represents the last node in synchronization distribution chain, it is not required for it to send SSMs. The eNB consider the Ethernet signal as a valid synchronization source if the Quality Level (QL) contained in the received SSM messages is one of the following: • •

PRC (Primary Reference Clock), SSU (Synchronization Supply Unit)

•

PRS (Primary Reference Source). An ideal situation occurs when the reference provides PRC/ PRS traceable clock and indicates this with SSM containing QL=PRC/ PRS traceable. The customer needs to make sure that the lower quality of SyncE reference signal (SSUA or SSU-B) is good enough for frequency synchronization. In fault conditions, some of the clocks in the synchronization distribution chain may enter hold-over mode or free-run mode and the eNB receives SSM QLDo Not Use (DNU) or Do not Use for Sync (DUS). Consequently the reference signal is not used as synchronization source signal anymore and the eNB tries to switch to an alternative synchronication source. The eNB raises an alarm. The operation mode for Synchronous Ethernet can be switched between operation with and without SSM support. The default setting is “operation with SSM support”: •

•

3.14.5

In operation with SSM support, valid SSMs are continuously received through the Synchronous Ethernet capable Ethernet interface. The pure fact that an SSM is received at a Synchronous Ethernet capable interface already tells that the incoming signal is Synchronous Ethernet signal. An alarm is generated if no valid SSM is received within a certain time interval ( ssmTimeout parameter), or when for example the eNB receives QL Do Not Use (DNU). In this case, the SyncE reference signal is no longer used as synchronization source signal. In operation without SSM support, the Ethernet signal is still synchronized to the network reference (PRC) and it is possible to recover timing from an Ethernet interface that is traceable to the PRC. An alarm is generated when the signal at the Ethernet interface is lost. Without SSM support, the network planning and the configuration of the network must be done very carefully. There is a high risk of misconfiguration and the Ethernet signal may not carry timing reference traceable to the PRC. Without SSM support, it is also impossible to signal the hold-over mode or free-run mode of intermediate nodes in a synchronization distribution chain.

Sales Information This feature belongs to ASW.

3.14.6 3.14.6.1

User Interface Parameters Table 106: Parameters related to the LTE713: Synchronous Ethernet feature shows the parameters related to the LTE713: Synchronous Ethernet feature.

DN0978045Issue:04A

©2016Nokia

187



Parameters related to the LTE713: Synchronous Ethernet feature

Table 106

Name

synchroSourceLis t

Object

STPG

Description

This is the list of synchronization sources of the eNB.

Range

-

-

ssmEnabled

STPG

This parameter enables SSM support (Synchronization Status Message) for Synchronuous Ethernet.

Boolean

ssmTimeout

STPG

This is the maximum duration in seconds for which the actual SSM value may be less than acceptable clock quality or for which SSMs are not received at all. If the duration is surpassed, an alarm will be raised.

2...10 seconds, step 1 seconds

3.14.6.2

Default value

true

5s

Alarms This section lists alarms related to the LTE713: Synchronous Ethernet feature. There are no alarms for theLTE713: Synchronous Ethernet feature.

3.14.6.3

Measurements and Counters This section lists measurements and counters related to theLTE713: Synchronous Ethernet feature. There are no measurements and counters for the LTE713: Synchronous Ethernet feature.

3.14.7

Activating and Configuring the Feature For activating and configuring the feature, see Feature Activation Documentation.

3.15 LTE800: Flexi Transport Sub-module FTLB 3.15.1

Description of LTE800: Flexi Transport Sub-module FTLB Introduction to the feature

The FTLB is a high-capacity transport sub-module which provides three Gigabit Ethernet (GE) and four E1/T1/JT1 interfaces. In addition, it supports Timing-over-Packet (ToP) and Synchronous Ethernet. Benefits End-user benefits

This feature does not affect the end-user experience.

188

©2016Nokia

DN0978045Issue:04A



Operator benefits

The high-capacity transport submodule supports large eNB configurations. Requirements Hardware and software requirements Table 107


System release

RL10


LBTS0.5


OMS

UE

N e tA c t

MME

SAG EW


This feature requires the FSMr2 system module . Functional description Functional overview

The Flexi Transport LTE version B (FTLB) is a high-capacity transport sub-module, which provides three Gigabit Ethernet (GE) and four E1/T1/JT1 interfaces. The FLTB module supports Timing-over-Packet (ToP) and Synchronous Ethernet. FTLB provides the following physical interfaces: • Interface 1: GE SFP receptacle, which canbe optionally equipped • Interfaces 2, 3: GE 100/1000Base-T (electrical, RJ45 connector), supporting ToP and Synchronous Ethernet • Interfaces 4, 5, 6, 7: E1/T1/JT1 symmetrical, RJ48 connector (E1 coaxial supported via patch panel) FTLB provides HW support for the following features: • • • •

U/C/M-plane security based on IPSec (2Gbit/s DL and UL throughput performance) Timing-over-Packet (ToP) based on IEEE1588v2 Synchronous Ethernet based on ITU-T G.8261 Ethernet switching with GE speed

Figure 19

FTLB module


There are no interdependencies between this and any other feature.

DN0978045Issue:04A

©2016Nokia

189





This feature has no impact on system performance or capacity. Management data BTS faults and reported alarms

[xref] lists BTS faults introduced with this feature. Table 108

New BTS faults

F a u l tI D

F au l tn a m e


61029

A l a r mn a me





There are no parameters related to this feature. Sales information Table 109

Sales information

BSW /ASW

BSW


-


Yes

3.16 LTE875: Different IP Addresses for U/C/M/S-plane 3.16.1

Description of LTE875: Different IP Addresses for U/C/M/Splane Introduction to the feature

With the LTE875: Different IP Addresses for U/C/M/S-planefeature the eNB can be configured with separate Synchronization Plane. IP addresses for User, Control, Management and Benefits End-user benefits


190

©2016Nokia

DN0978045Issue:04A



The U/C/M/S-plane traffic can be differentiated based on IP addresses. For example, the traffic may be routed into different VLANs or into different physical paths. This feature will also be applied in conjunction with LTE132 (VLAN based traffic differentiation). Requirements Hardware and software requirements



RL10

Flexi BTS Multiradio Flexi Flexi Zone 10Multiradio BTS BTS Micro Flexi Zone PointAccess

LBTS1.0


-

-

LBTS4.0

OMS

UE


MME

SAG EW

----



The eNB can be configured with separate IP addresses for User, Control, Management, and Synchronization plane. eNB applications (S1/X2 U-plane, S1/X2 C-plane, M-plane, S-plane) may be arbitrarily bound to eNB interface address(es) or virtual address(es). Address sharing, that is, a configuration with the same IP address, is possible. In the simplest configuration, the eNB features a single IP address for U-plane, C-plane, M-plane and S-plane. Relevant data link layer interface types are Ethernet (physical interface) and/or VLAN (logical interface). Different data link layer interfaces belong to different IP subnets.

DN0978045Issue:04A

©2016Nokia

191


Different IP addresses for eNB applications

Figure 20

Application(s) bound to interface address(es) Address sharing (Single address)


Application(s) bound to virtual address(es)

Multiple interface addresses

U

U

U

C

C

C Routing

M

M

M

S

S

S

U

User plane traffic

C

Control plane traffic

M

Management plane traffic

S

Synchronization plane traffic








192

©2016Nokia

DN0978045Issue:04A




New parameters for LTE875: Different IP Address for U/C/M/S-plane

Full name

Abbreviated name

Control plane IP address

cPlaneIpAddress

Managed Object

IPNO

Management plane IP address mPlaneIpAddress

IPNO

Synchronization plane IP address

IPNO

sPlaneIpAddress

User plane IP address

uPlaneIpAddress

IPNO

There are no modified or existing parameters related to this feature. Sales information Table 112 Sales information BS W/ASW

BSW

DN0978045Issue:04A


-

©2016Nokia


-

193

Operability features from previous releases for RL10


4 Operability features from previous releases for RL10 4.1 LTE80: GPS Synchronisation 4.1.1

Introduction to the feature External Global Positioning System (GPS) synchronisation can be used for frequency synchronisation on sites utilising Ethernet transport.

4.1.2

Benefits A reliable frequency reference can be provided for sites using asynchronous transport media unable to provide frequency reference for Flexi BTS. For FDD LTE GPS synhronization at BTS site is optional feature if Timing Over Packet (ToP) or Synchronous Ethernet is not used in transport network.

4.1.3 4.1.3.1




Systemrelease

RL09

MME

-

SAE GW

-

NetAct

4.1.3.2

-


4.1.4

Functional description The GPS antenna with integrated receiver (FYGA) needs to be installed outside for satellite visibility and can be directly connected to the synchronization input of the Flexi System Module. The FZM utilizes an integrated GPS receiver. The GPS antenna is typically positioned atop of the FZM eNodeB but can be remotely positioned with a coaxial cable connection between the FZM GPS antenna connector and GPS antenna. Direct current (DC) power for the GPS receiver is supplied through the combined power and control cable connected to the MDR-26 Synchronization interface of the Flexi System Module. The Flexi System Module provides a power feeding of 12 V which allows cable lengths of more than 200m. The FZM radio frequency (RF) GPS antenna interface provides a 5VDC bias across the antenna connector to power the low-noise

194

©2016Nokia

DN0978045Issue:04A



amplifier (LNA) in active antennas. No separate power connections are required for the FZM GPS antenna. The total cable length supported by the FZM GPS antenna is dependent on satisfying the receiver gain and noise figure requirements. The total RF gain in the GPS L1 C/A band (1575.42MHz +/-1.023MHz) must be within +10dB and +26dB with a noise figure of less than 4.0dB. A distance of 55m can be supported with LMR-400 type cable connected between the supplied FZM GPS antenna. Longer distances can be supported with lower loss cables and / or higher gain antennas. An optional FYEA provides surge protection (that is Over Voltage Protection, OVP) against lightning in an IP65 housing for the Flexi System Module.

4.1.4.1

Architecture of time management Time clients use NTP in unicast mode. A client sends queries to the time servers, which sends Universal Time Co-ordinates (UTC) to the client as a response. Based on time zone and received time, the network elements can calculate the time themselves. If the Radio Access Network (RAN) covers more than one time zone, the user must be very careful when comparing the time stamps in the alarms. The time of the alarm depends on the location of the element and from which point of the network the alarm is observed. In the NetAct alarm system the time stamps of the alarms are adjusted according to the time zone setting of NetAct, so in the NetAct alarm system the timestamps of different alarms from different network elements are comparable. Architectural roles

eNB The BTS is the NTP client which gets its time from the NTP server in NetAct.

4.1.4.2

Use cases In order to activate the time management feature, the time servers in NetAct are configured in a similar way as the time clients in the eNBs. The configuration is typically done in the integration phase of the network element. The exception to this is the daylight saving time configuration. Activating time management

1. The IP address of the time server is set. 2. Time zone and daylight saving time (DST) information is set to the time clients. In the BTS, DST is not set separately but only the location information of the BTS site is configured. The time management setting is done, and the network element is ready to receive the time from the configured NTP server.

4.1.5 4.1.5.1

System impact Interdependencies between features There are no interdependencies between this and any other feature.

DN0978045Issue:04A

©2016Nokia

195


4.1.5.2


Impact on interfaces This feature has no impact on interfaces.

4.1.5.3

Impact on network and network element management tools This feature has no impact on network management or network element management tool.

4.1.5.4

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

4.1.6 4.1.6.1

User interface Alarms for LTE80: GPS Synchronisation There are no alarms related to this feature.

4.1.6.2

Measurements and counters for LTE80: GPS Synchronisation There are no measurements and counters related to this feature.

4.1.6.3

Key performance indicators for LTE80: GPS Synchronisation There are no key performance indicators related to this feature.

4.1.6.4

Parameters for LTE80: GPS Synchronisation There are no new parameters related to this feature.

4.1.7

Sales information Table 114 Sales information BSW /ASW

ASW


SW Asset Monitoring


-

4.2 LTE147: Hardware Management 4.2.1

Introduction to the feature The network inventory of the Evolved Node B (eNB) consists of an automatic hardware (HW) detection and notification/upload function to NetAct specifically the NetAct Inventory Application.

196

©2016Nokia

DN0978045Issue:04A


4.2.2


Benefits The operator has a continually updated view of the deployed HW infrastructure without requiring massive upload operations of network-level HW information. The transmission load is more evenly divided and there is no need to transfer information that is already known to the Inventory System.

4.2.3 4.2.3.1


Software requirements for different network elements N etwor kel emen t

R e qu i re d s of t w are re l e as e

Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.2.3.2

OSS5.2CD3


4.2.4

Functional description The Radio Access Network (RAN) network inventory functionality consists of two functional procedures: •

•

Hardware information upload thatcan be uploaded to NetAct either manually by selecting the particular eNB, or the upload can be scheduled in NetAct. Hardware information events, the eNB indicates to NetAct that a HW item has been installed or the HW information in the eNB has changed. The automatic HW information event decreases the need to upload HW information periodically. In this way the HW information is always up to date. The event is triggered either by manual HW installation or HW auto-detection depending on the type of installed HW unit.

HW components are automatically detected and tested when system is starting up or when a new component is plugged-in. The HW management is done by using the Base Transceiver Station Site Manager (BTSSM) either locally or from a remote site. The HW installation has been made as automated as possible in order to avoid user interaction. The HW management system keeps the Flexi LTE BTS HW configuration information up-to-date and provides the Flexi LTE BTS with the appropriate configuration parameters. The Flexi Transport Module (FTM) HW configuration information is stored in the Flexi LTE BTS as part of the BTS HW inventory. These functional procedures are used to update the network HW information to the NetAct Hardware Inventory.

DN0978045Issue:04A

©2016Nokia

197



The HW information in the network is changed when new hardware is installed in the network. The changes are reported to NetAct either with automatic hardware information events or using periodic hardware information uploads from the network. Hardware information upload

HW configuration data are updated at NetAct. NetAct sends a HW information upload request containing the affected eNB to integrated Operation Mediation System (iOMS). The iOMS fowards the upload request to eNB. The eNB forwards the HW Change Notification to NetAct.

g

Note: The eNB will not send the HW change notifications to the iOMS or the OSS

g

Note: The HW configuration is either manually configured or detected automatically by

when a module state change is detected. The HW inventory reports contain information about the current HW module state, but only the physical HW change (add, remove, or replace) triggers notification.

the system in the eNB. Automatic update of HW configuration data at NetAct

The Flexi Zone Micro (FZM) eNB is a single box unit and does not support the addition or removal of any hardware components. Thus, the functionality described in this section does not apply to the FZM eNB. HW configuration data kept up the date at NetAct. The eNB detects hardware changes and triggers a HW Change Notification to iOMS. The iOMS forwards the HW Change Notification to NetAct. .

4.2.4.1

Architecture of network inventory Figure 21: Architecture of network inventory shows the architecture of network inventory. Figure 21

198

Architecture of network inventory

©2016Nokia

DN0978045Issue:04A



NetAct OSS Framework

NetAct Application and Services

Element Management System NetAct GUI Server

NWI3

BTS SM

iiOMS

Site manager IF

BTS OM IF

eNB

Site manager IF BTS SM Element Manager LMT (PC)

Architectural roles

The collected HW information of the network is available in the Network Inventory application in NetAct. For more information, see NetAct product documentation. User

NetAct user is the actor for the HW information upload. NetAct

NetAct hardware inventory is the controller of the HW information upload function. NetAct hardware inventory also provides the data storage for the HW information that are collected from the network. eNB

The eNB is the data provider for eNB HW information. It also provides a local data storage for the current eNB HW information. The eNB is the actor for sending the automatic HW information event.

4.2.5 4.2.5.1


4.2.5.2


DN0978045Issue:04A

©2016Nokia

199


4.2.5.3



4.2.5.4


4.2.6 4.2.6.1

User interface Alarms for LTE147:Hardware Management There are no alarms related to this feature.

4.2.6.2

Measurements and counters for LTE147:Hardware Management There are no measurements and counters related to this feature.

4.2.6.3

Key performance indicators for LTE147:Hardware Management There are no key performance indicators related to this feature.

4.2.6.4

Parameters for LTE147: Hardware Management Table 116

Parameters for LTE147: Hardware Management

F u l ln a m e

A b b r e v i a t e dn a me

FTM

Network element system name systemTitle

FTM

Network element user defined description

FTM

UNITidentifier

4.2.7


Network element location name locationName

userLabel unitld

UNIT

Installed hardware unit type

unitTypeActual

UNIT

Expected hardware unit type

unitTypeExpected

UNIT

Sales information Table 117 Sales information BSW /ASW

ASW NetAct

200


NetAct

©2016Nokia


-

DN0978045Issue:04A



4.3 LTE150: LTE OAM Transport Layer Security (TLS) Support 4.3.1

Introduction to the feature This feature enables secure O&M control and bulk data communication between Evolved Node (eNB) and BTS Site Manager, NetAct, secure or otherprotocols management system. The featureBincludes a PKI infrastructure by utilizing such as Transport Layer Security (TLS). The feature also brings CAPEX savings, as there is no need to invest in any external HW. Applied together with LDAP, TLS takes care of confidential user credential exchange.

4.3.2

Benefits This feature offers enhanced risk management because of improved RAN network security. It also offers CAPEX savings by not requiring investment into any external HW.

4.3.3 4.3.3.1



Network element


Systemrelease

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

NetAct

4.3.3.2

OSS5.2CD3


4.3.4

Functional description for LTE OAM Transport Layer Security (TLS) Support This feature increases the security of the interfaces of the Evolved Node B ( eNB) towards the BTS Site Manager interface and iOMS by encryption, integrity protection and server authentication, which are provided by the Transport Layer Security Protocol ( TLS)

DN0978045Issue:04A

©2016Nokia

201



and further protocols such as HTTP or Lightweight Directory Access Protocol ( LDAP) running on top of it. Unsecure protocols such as FTP are no longer used. TLS is a secure communication method for protecting the confidentiality and integrity of, for example, Java, HTTP and LDAP based O&M traffic. TLS is also used for authenticating these services and the hosts and the servers that provide a service. eNB and iOMS support TLS version 1.0 [RFC 2246]. In detail, the feature introduces the following functions: •

•

•

• •

Digital certificates according to X.509v3 format are used to mutually authenticate the eNB, the BTS Site Manager, and network servers such as NetAct. Data encryption is used to prohibit both internal and external hostile attacks. iOMS and eNB encrypt all traffic that is sent via BTS O&M. Secure O&M interfaces O&M messages and commands are encrypted and integrity protected by TLS. Data such as user names and passwords is not transferred as plain text. Bulk data transfer is encrypted and integrity protected by HTTPS. The LDAP interface for user authentication andprovision of permission information for a user is secured by TLS.

TLS (similar to Secure Socket Layer Protocol, SSL) provides encryption and authentication mechanisms, and consists of two layers: •

•

The TLS record protocol provides encryption andintegrity protection ofthe message exchange. The TLS handshake protocol provides mutualauthentication of the communication peers by means of digital certificates. In this process, the certificates’ CA signature and lifetime are validated. This mutual authentication prevents man-in-the-middle and masquerade attacks.

LDAP secured with TLS

The NetAct centralized user authentication and authorizationCUAA ( ) application and other services use the LDAP interface to authenticate a user and to fetch permission information for a user. Insecure connections on the LDAP link between the BTS and the LDAP servers lead to a situation where a user's username and password are transferred in plain text across the O&M network. This is no longer the case with the secure LDAP feature, whereby the LDAP interface is secured by means of TLS, using AES-128 encryption and the related integrity protection according to LDAPv3 as specified in RFC 4513. LDAP operation modes

Using the ldapConnectionType parameter, the eNB can be configured to allow towards LDAP servers: •

only secured LDAP connections, or

•

both secured and unsecured LDAP connections.

If both secure and insecure connections are allowed, the eNB attempts to establish a secured LDAP connection first. If the LDAP server denies the secure connection, the eNB tries to establish an insecure connection. TLS operation mode in the eNB

Transport Layer Security in the eNB omsTLS ( parameter) can be configured as:

202

©2016Nokia

DN0978045Issue:04A


•


Probing (Secure/Unsecure)

Both secure and unsecure O&M connections are allowed between the iOMS and the eNB. If the connection setup to both secure and insecure ports fails, the eNB starts the connection procedure from the beginning, that is, it tries to establish secure connection first. This setting should be used for only for transition from insecure to secure BTS O&M interface without limiting the connectivity. From the security point of view, it is recommended not to use this setting permanently. •

Forced

Only secure O&M connections are established between iOMS and eNB. •

Off

Only unsecure O&M connections are established between iOMS and eNB. This is the default setting.

g

Note: Make sure to have the configuration matched between the operation mode

settings in the eNB and the iOMS. If the settings differ, the eNB might not be able to connect, but will continue trying to connect even though the iOMS connection port is closed. Insecure and secure O&M connections are established on separate TCP ports. By enabling or disabling (opening or closing) these ports, secure and insecure connections can be activated and deactivated. BTS O&M protocol (OM) security mode in iOMS

The TLSModeOM parameter in iOMS can be configured as: •

•

•

Forced

Only secure O&M protocol connection are established. The iOMS and the eNB use the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. The insecure port (8002) is closed. Probing (Secure/Unsecure) Both secure and unsecure O&M protocol connections are allowed. Both secure and insecure ports are open. When the parameter value is changed from Off to Probing, the iOMS resets the port 8002 to trigger the eNB change from insecure to secure connection. Off

Only unsecure O&M protocol connections are allowed. The secure port (8003) is closed. File Transfer (FT) security mode in iOMS

For file transfer between iOMS and eNB there is a separate parameterTLSModeFT ( ) which can be configured as: •

Forced – – – –

•

DN0978045Issue:04A

Only secure file transfers are allowed. The iOMS and the eNB use the TLS_RSA_WITH_RC4_128_SHA cipher suite. The secure port (443) is open. Insecure ports are closed (FTP 20, HTTP 80). This is the default value.

Probing

©2016Nokia

203


–

– •


Both secure and insecure file transfers are allowedbetween iOMS and eNB. Secure file transfer is tried first. File transfers between iOMS and NetAct are in secure mode only. Both secure and insecure ports are open.

Off – –

Only insecure file transfers are allowed. Both secure and insecure ports are open.

The file transfers between eNB and iOMS depends on the BTS O&M interface state. If the interface state is secure, then the file transfer is also secure. If the negotiated file transfer protocols allow both insecure and secure file transfers, and the file transfer attempts from both secure and insecure ports fails, the client does not retry, but aborts the procedure. Authentication and encryption of TLS connections

The eNB authenticates peer applications with digital certificates according to X.509v3 and encrypts all traffic that is sent via TLS links. The same eNB device certificate is used to authenticate towards IPSec and TLS peers. Parallel usage of TLS and other secure transport protocols

Depending on the transport network configuration and the number of network management locations and applications to be addressed, TLS (one or more instances) alone or together with other secure transport protocols like IPsec can be used and configured in parallel. For instance, it is possible to run TLS within a common IPsec tunnel.

4.3.4.1

Secure BTS Site Manager connection The BTS Site Manager (BTSSM) tries to establish only secure connection to an eNB. The BTSSM (acting as TLS client) authenticates the eNB (acting as TLS server) with eNB’s certificate; the eNB authenticates the BTSSM user with user name and password. Both the BTS SM and the eNB use theTLS_RSA_WITH_AES_128_CBC_SHA cipher suite for secure connection. If the eNB certificate validation fails in BTSSM, the BTSSM asks for the user permission to continue establishing a secure connection (even if the eNB certificate is unknown to BTSSM). The unknown certificate is: •

•

an operator end entity certificatethat cannot be validated by BTSSM (for example, because the operator root CA certificateis not configured in BTSSM), an Nokia vendor certificate (which cannot be validated by BTSSM),

an eNB self-signed certificate (which cannot be validated by BTSSM). If the user accepts, a secure connection is established. If the user declines, the connection is closed (no insecure connections between BTS Site Manger and eNB are possible). •

4.3.5

204

System impact

©2016Nokia

DN0978045Issue:04A


4.3.5.1


Interdependencies between features LTE665: LTE Certifcate Managementprovisioning of a common certificate handling.

4.3.5.2


4.3.5.3

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

4.3.5.4


4.3.6

Sales information This feature belongs to BSW.

4.3.7

Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support Table 119: Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support shows parameters related to LTE150: LTE OAM Transport Layer Security (TLS) Support.

g

Note: After changing parameters a BTS restart is necessary. Table 119

Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support

Full name

Object

Description

(Short name)

LDAP Server TLS access mode

Range / Step

Default value

AMGR

This parameter holds the TLS access mode for the LDAP server(s) of the BTS. The possible values are: ‘secured’ (allow only secured connections) and ‘both’ (allow both unsecured and secured

IPNO

Defines the usage of TLS between off (0), forced probing the eNB and the iOMS system.The (1), probing (2) usage of TLS requires that valid (2) certificates are installed to the eNB.

( ldapConnection Type)

TLS (0), TLS_OR_PL AIN_TEXT (1)

connections). TLS usage towards the iOMS system (omsTls)

DN0978045Issue:04A

©2016Nokia

205


4.3.8


Alarms for LTE150: LTE OAM Transport Layer Security (TLS) Support This section lists alarms related to RAN O&M security per feature. Alarms for LTE150: LTE OAM Transport Layer Security (TLS) Support

Table 120

Alarm number

Alarm name

Condition

71058

NE O&M connection failure

This alarm is raised when the BTS O&M connection between the iOMS and a network element fails. The managed network element is not reachable by the centralized O&M system.

71052

OMS file transfer connection could not be opened

Starting of a new file transfer connection has failed. File transfer between the iOMS and a target network element is not working.

71107

Insecure O&M connection attempt in OMS

iOMS is in ‘probing’ mode and an eNB attempts to connect with an insecure BTS O&M connection. In ‘probing’ mode secure connections are preferred, that is, the alarm may be an indication of a failure in setting up a secure connection.

4.4 LTE154: SON LTE BTS Auto Connectivity 4.4.1

Introduction to LTE154: SON LTE BTS Auto Connectivity The LTE154: SON LTE BTS Auto Connectivityfeature supports faster installations of new or relocated base stations by an automated IP transport connectivity set-up to the backhaul network.

4.4.2

Benefits The Flexi Multiradio BTS/FZM Auto Connectivity feature supports faster installations of new or relocated base stations by an automated IP transport connectivity set-up to the backhaul network. The LTE BTS Auto Connectionfeature comprises the following: • • • • •

phase 1 - pre-planning andhardware installation /start of auto-connection phase 2 - start-process of an auto-connection phase 3 - connect phase 4 - register manual intervention

The benefit is a less costly and quicker network rollout. After installation, the automatic establishment of an O&M connection allows the commissioning to be completed remotely without the need for a skilled commissioner on-site.

206

©2016Nokia

DN0978045Issue:04A


4.4.3 4.4.3.1





Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.4.3.2

OSS5.2CD3


4.4.4

Overview For an overview of the auto connection process, please see the figure: SON LTE BTS Auto Connection. Figure 22

LTE154: SON LTE BTS Auto Connection

Backhaul

GPS

DHCP

CA Server

Certificate repository

Security Gateway

NetAct

Manual Site Installation self test (POST)

DHCP: nE-IP@ & operator specific IDM-IP @/SEG-IP@/NetAct-IP@ Authenticate to Operator’s CA with eNB vendor Certificate & key signing request Create, sign & download operator’s eNB Certificate Establish Ipsec tunnel to the Network Management’s Security Gateway SOMS

Establish TLS connection to Operation & Mediation Subsystem (application security) Register to NetAct Topology Manager (eNB Registration) Connected

ready for remote manual or automated commissioning

IDM: Identify Management POST: Power on Selftest DHCP: Dynamic Host Configuration Protocol

For an overview of Plug and Play auto connection, please see the figure: Auto Connection with DHCP server.

DN0978045Issue:04A

©2016Nokia

207



The BTS needs basic auto-connection parameters in order to establish connection with the operator’s Security Gateway (SeGW), Certificate Authority Server (CA Server), and Configuration Server (iOMS). Figure 23

Auto-Connection with DHCP server Operator’s Network DHCP

Flexi Zone Small Cell

DNS

CA Server

SeGW

OMS

NetAct iSON Mgr cSON

EPC

LTE154: SON LTE BTS Auto Connectivity(see blue line in the figure) • • •

4.4.4.1

Parameters obtained from DHCP server Includes Nokia-specific DHCP options Supports no-touch Plug and Play

Terms The terms shown in the following are related to LTE154: SON LTE BTS Auto Connectivity. Table 122

Terms related to LTE154: SON LTE BTS Auto Connectivity

Term

Description

BTS Id

This is a legacy term used for the identifier by which the NE identifies itself to the network. Within this document, the term NE Id is preferred.

Commissioning

Commissioning starts when the installation has been completed, that is, when the equipment can be powered on. It covers all the required parameter settings, self-tests, and other possible tests, which are required to ensure the stand-alone operation of the network element in question. As a result of the successful commissioning, there is a report, which can be used forwhen commissioning acceptance if required. Commissioning ends the equipment stand-alone functionality complies with product requirements and the network element functions as a stand-alone entity.

Commissioning report

208

A commissioning report is generated by the network element for commissioning acceptance.

©2016Nokia

DN0978045Issue:04A



Table 122

Terms related to LTE154: SON LTE BTS Auto Connectivity (Cont.)

Term

Download

Description

Download (for example a configuration plan file) is triggered from NetAct or Element Manager by transmitting a download command to the Network Element. The Network Element downloads the required file(s) from a location defined in the download command. The download procedure does not include activation, which is done in a separate activation procedure.

Element Manager (EM)

The Element Manager provides a user interface to manage a network element. The Element Manager can be used either locally on site or remotely via Data Communication Network (DCN).

Identity Management System (IDM)

A server or a set of servers used to identify securely a client which accesses the server via an untrusted Network, based on a Public Key Infrastructure (PKI). During auto-connection, NEs will access an IDM via the Certificate Server.

NE Id

Identifier by which the NE identifies itself to the network. Other identifiers (for example a Logical Site Id in a format that is used in every day life, like a street address) may be used to identify the NE, as long as they can be mapped unambiguously to the NE Id. A legacy term with a similar meaning is BTS Id. However, the O&M interface of the BTS/eNB has introduced the NE id as a replacement for BTS Id. Therefore, NE Id is preferred.

Network Operation The Network Operation Center is the management site for NetAct, OMS Center (NOC) and other support systems of network and business management. O&M Mediator

An entity that performs protocol mediation and concentration between the NE and the NMS. In the Radio Access Network, this functionality is performed by OMS.

Radio Network Integration

Radio Network Integration contains procedures needed to configure a NE site and to create necessary connections for DCN and Radio Network. The Radio Network Integration is finished when the RNW configuration is downloaded to a NE and the BTS is ready to accept end-user traffic.

Radio Network Planning

The purpose of Radio Network Planning is to provide the best-optimized structure for a network based on coverage, capacity and quality requirements.

Site Configuration File (SCF)

A file containing the planned configuration for an NE.

g Transmission plan (TRS plan)

DN0978045Issue:04A

Note: Note that in LTE there is no separate Site Configuration

File; all types of configuration data can be downloaded in a single file.

A transmission plan contains configuration for transmission, transport and IP layers and for DCN

©2016Nokia

209


Terms related to LTE154: SON LTE BTS Auto Connectivity (Cont.)

Table 122

Term

4.4.4.2


Description

VPN/Security Gateway

A gateway from an untrusted network to the trusted network of a mobile operator, used to provide a secure data transfer through the untrusted network.

Flexi MultiRadio

A multiradio/multicarrier Base Tranceiver Station (BTS) that can use the GSM/EDGE, WCDMA and LTE network technologies either in dedicated or concurrent mode of operation. It supports the eNB functions.

FZM

Flexi Zone Micro, it is Nokia's second generation Pico/Micro solution primarily targeting outdoor/indoor installations. The design of Flexi Zone Micro BTS is based on Flexi Multiradio BTS platform.

Phase 1 - pre-planning and HW installation Factory

The eNB is delivered from the factory with an initial software load that includes all functions that are needed to successfully perform the auto connection and auto configuration procedures in an LTE environment. Identification server preparation

The planning data related to the new eNB should be prepared at NetAct. This is needed for the unambiguous identification of the eNB and to provide the IP address for the final OMS. At least one of the following three parameters have to be configured to the identification server as part of the PREBTS object and serves to identify the BTS: • • •

Auto Connection Hardware ID, Auto Connection Site ID, Geo-Coordinates (Altitude, Longitude, Latitude)

The following parameters are mandatory and replied from the identification server to the eNB. • • • •

BTS Identifier Final Mediator IP address Target technology Target Software version

The following table shows all relevant parameters of the managed object PREBTS. Table 123

OMS PREBTS parameters

MO class

PREBTS

210

Parameter name

Auto Connection Hardware ID

©2016Nokia

Abbreviated name

AutoConnHWID

Description

This parameter identifies Hardware ID of NE, which the NE

DN0978045Issue:04A



Table 123

OMS PREBTS parameters (Cont.)

MO class

Parameter name

Abbreviated name

Description

uses during autoconnection procedure to identify itself when the logical BTS Id is not yet known to the NE.

DN0978045Issue:04A

PREBTS

Auto Connection site ID

PREBTS

BTSIdentifier

BTSID

PREBTS

GPS Tolerance

GPSTolerance

This parameter specifies allowed deviation (meters) of GPS location from expected value.

PREBTS

PREBTS Identifier

PREBTSID

This parameter identifies PREBTS.

PREBTS

GPS Antenna Altitude

altitude

Altitude of GPS antenna of site

PREBTS

Final Mediator IP Address

PREBTS

GPS Antenna Latitude latitude

PREBTS

GPS Antenna Longitude

longitude

Longitude GPS antenna ofofsite

PREBTS

Technology Information

technologyInformation

This parameter specifies technology of BTS.

©2016Nokia

AutoConnSiteID

finalMediatorIPAddres s

This parameter is the unique identifier for the BTS site, which the NE uses during autoconnection procedure to identify itself,when the logical BTS Id is not yet known to the NE. Thisparameter defines unique identifier by which the BTS identifies itself to the Network.

IP Address for the Final Mediator Latitude of GPS antenna of site

211


Table 123


OMS PREBTS parameters (Cont.)

MO class

PREBTS

Parameter name

Version

Abbreviated name

version

Description

Thisparameter specifies the version information that BTS should use as swVersion until it has been commissioned.

DHCP server preparation

The auto connection requires the use of standard DHCP (Dynamic Host Configuration Protocol) services and, the DHCP servers must be pre configured with suitable options and eNB specific data (vendor-specific attributes) such as: •

•

•

g

IP address of the Certificate Server that is the operators' Registration Authority or Certificate Authority providing the operators' public key infrastructure (PKI) services. IP address of the VPN/Security Gateway protecting the responsible NetAct Operations, Administrations and Maintenance (OAM) system IP address of the management peer of the responsible NetAct system Note: The Layer 2 access network and Layer 3 transport network components such as

routers, firewalls, and SeGW need to be configured according to the operators' transport and connectivity policy. Vendor specific extensions in the DHCP protocol

The definition of the vendor specific extension is vendor specific. This chapter describes the DHCP interface, especially parameters and format of vendor specific extensions as used in the DHCP server/client interface (DHCP DISCOVER/OFFER) needed to support BTS/eNB auto connection. The vendor class identifier is used to identify the vendor. Table 124

Format of vendor class identifier in DHCP discover

DHCP option code

60

Length

08

vendor-classidentifier

NokiaBTS01

Format of vendor specific extensions

The definition of the vendor specific extension is vendor specific. The vendor parameter definition is based on the TLV (Type-Length-Value) approach.

212

©2016Nokia

DN0978045Issue:04A



Table 125

Format of vendor specific extensions

DHCP option Option length Identification of Vendor specific code (1- 255) TLV format parameter 1

43

n

0000

type/length/value

octet

octet

4 octets

octet/octet/n octets data

Vendor specific parameter 2

type/length/value octet/octet/n octets data

Format of vendor specific parameters in client/server interface

The types of parameters (parameter tags) that can be provided by the DHCP server are fixed. Servers, as well as, clients need to comply with the definition below. Table 126

TLV format of vendor specific parameters

Parameter tag (type)

Parameter length

Parameter name

Parameter content

01

variable (4 octets usually)

OMS IP

IP address of (dedicated) OMS or OMU

04


CA/CMP IP

IP address of CA server

05

variable

CA/CMP Port

Port number of CA server

06


VPN GW IP

IP address of VPN gateway

08


CMP Subject Name

Subject name for CA server

string, max length 100

Example: 43 Option type

10

0000

Total option length

1

TLV identifie r

4 OMS param type

A OMS param length

B

C

D OMS IP

<-------------------------------------->

Certificate server

DN0978045Issue:04A

©2016Nokia

213



The certificate server, respectively the operator Registration Authority (RA) and Certification Authority it represents, is in charge of operator certificate creation, signing and request handling if a newly deployed eNB asks for an operator certificate. The certificate server needs to be pre configured with the Nokia signing Factory CA certificate and Nokia root certificate, and all operator trusted certificates (trust anchors) that are to be installed in the eNB. For the automated initial deployment of operator certificates and certificate life cycle management, the security server needs to support CMPv2 Annex E7.

g

Note: Nokia offers with its “Identity Management System (IDM)” a complete security

suite as certificate server. IDM provides a Registration Authority, a Certificate Authority, a Certificate Repository and Nokia specific add-ones: As an enhancement to other commercial third party security solutions, the IDM can be configured with all the Nokia device serial numbers of the Flexi System Transport Modules, that the operator has ordered. With the help of the IDM's specific “Authentication Module” each initial eNB key-signing request will be checked for authenticity. Only HW modules that can be verified as operator owned will be given operator certificates.

g

Note: At a minimum, the auto connectivity procedure requires, the IP address of the

management peer of the responsible NetAct OAM system to be delivered to the eNB as a DHCP vendor-specific attribute. If this is not received by the eNB, the autoconfiguration procedure will fail. If the procedure fails, manual intervention is required to continue the installation process. BTS Site Manager can be used to provide the eNB with the missing IP connectivity information. If PKI certificate server IP address is not part of the DHCP OFFER, then IPsec and TLS connections are not possible and the eNB tries to connect to NetAct in an unencrypted mode. If the certificate server address is delivered but a VPN/SeGW address is not provided then, the eNB tries to connect to NetAct with TLS protection for the OAM traffic. HW plan generation

HW plan configuration includes all the details that are needed to install BTS components (like antennas) and cabling. BTS HW installation

As a precondition, the power cable, transmission link, antenna, and actual base station should be installed on site. The 3D map coordinates must be available to the BTS installer if a manual site binding procedure is applied (if no GPS site solution for automated binding is in place). Booting/power on the eNB

Every time a BTS is booted it automatically runs a self-test and the results of the test are stored in the eNB and also shown as LED indication. The power-on self-test (POST) tests the functionality of the eNB internal units.

4.4.4.3

Phase 2 - start-process of an auto-connection Check commissioning state

The connectivity agent checks, whether or not the BTS is already commissioned: •

214

If the eNB is not yet commissioned, the auto-connection procedure starts.

©2016Nokia

DN0978045Issue:04A


•


If the eNB is already commissioned, the regular start-up/recovery procedure starts.

Establishment of IP connectivity

The eNB is automatically configured to enable the eNB to communicate with the network backhaul. In order to retrieve all information necessary for the IP connection establishment between eNB and NetAct, the eNB acts as DHCP client. The DHCP server assigns an interface IP address, netmask and default gateway IP address to the eNB and in addition delivers furthersystem information on vendor attributes as the vendors’ Management IP address and specific the IP address ofsuch the Identity Management System (IDM) that is a third party PKI Certificate Server as listed above.

g

Note: The operator's network planning policy will determine if a new static BTS IP

address is assigned to the eNB during auto-configuration. Retrieval of operator certificate and trust anchors

In case of activated transport security (IPSec, TLS) the eNB starts the automatic acquisition of the operator eNB node certificate and trust anchors by contacting the operators’ IDMS/PKI certificate server. The CMPv2 protocol defined in RFC 4210 is followed by the eNB. For more details on certificate handling, see “LTE Certificate Management”.

4.4.4.4

Phase 3 - Connect As soon the final certificates are available in NetAct the Flexi Multimode BTS/FZM, the eNB starts theassecure O&M plane connection to the framework. •

•

If an IP address of a VPN/Security Gateway protecting the responsible NetAct OAM system was received from the DHCP server before, then an IPsec connection is established to the NetAct VPN/SEG gateway. A TLS connection to secure theOAM management plane is established betweenthe eNB OAM application and the responsible NetAct OAM system.

In addition the TLS connection may be tunneled within a previously established IPsec tunnel towards a given VPN Gateway at the operator domain border; this depends on the operators’ transport security concept.

g

Note: The mutual node authentication by public certificates is recommended by 3GPP

but is not mandatory if the operator runs a trusted network. Therefore, the autoconnection procedure is able to continue if no certificates are downloaded. In particular, the automated certification retrieval step is skipped if no IP address of the Identity Management System (IDM), in other words, the PKI Certificate Server was received from the DHCP server. Figure: Transport overview with IP addressesshows the setup of a secure O&M

connection via an IPSec gateway. During the preparation process the operator certificates need to be prepared on the security server. The IP addresses shown in the figure are retrieved from the DHCP server.

DN0978045Issue:04A

©2016Nokia

215


Figure 24


Transport overview with IP addresses. DHCP IPsec & BTS M-Plane IP address =10.10.43.111 Server

Security SEG

Gateway (optional)

IP

IP IP VPN O&M

eNB 10.10.43.111

10.10.43.100

10.10.43.200

Security Server (optional)

Secured and unsecured connection establishment towards OMS

Auto connection supports both secured and unsecured connection establishment towards OMS. •

•

•

4.4.4.5

Secured connection with IPSec to security GW (gateway) and TLS (transport layer security protocol) to OMS will be established if CMP (certificate management protocol) server IP/port and security GW IP is received in DHCP (dynamic host configuration protocol) offer. Secured connection with TLS to OMS will be established if CMP server IP/port is received in DHCP offer. Unsecured connection would beestablished if CMP IP/port is not part of DHCP offer and if OMS does not support TLS.

Phase 4 - register When the TLS connection is established, the registration request is sent to the NetAct to trigger the self-configuration sequence or manual remote commission. For executing the proper configuration, the provision of the geographical site location is essential. For more information see feature: LTE663: GPS Location and Time Retrieval •

Automatic HW-to-Site binding/site identification: If there is a GPS receiver available on site, the registration includes both a serial number and the measured geographical coordinates of the BTS. The delivered 3D map coordinates are sent to the NetAct's Auto Configuration application. The NetAct automatically identifies the appropriate BTS with the help of the coordinates.

216

©2016Nokia

DN0978045Issue:04A



g

Note: In some cases it might not be possible to cover BTS detection using only map

coordinates, for example in case of co-location of two eNBs. If this happens the autoconfiguration stops until the operator manually solves the ambiguity. When a GPS receiver is not provided the installer will most probably enter GPS coordinates or a street name at a site using Site Manager.

g

Note: Although a GPS receiver is always present at an Flexi Zone Micro eNB, the Flexi

Zone Micro might be configured to use alternate timing sources (such as ToP or SyncE). If the GPS is not used, even though the receiver is in the FZM, then the operator will need to go for the manual HW-to-Site binding as explained in the following paragraph. •

Manual HW-to-Site binding/site identification: If there is no fixed mounted GPS receiver available on site, then the manual outbound HW-to-Site binding is done: The registration request includes only a serial number. The field engineer delivers the geographical site information together with the outbound serial number to the remote integration center via for example SMS, phone call, mail etc. Therfore, the mapping between the eNB asking for registration and the appropriate deliverable is done manually with the help of the serial number. For this task the remote integration center interworks with the NetAct System.

g

Note: The manual outbound mapping might take some time. As long as the registration

is not confirmed, the eNB waits for an appropriate time. If this time expires the registration request is repeated again. •

Dedicated OMS: In the dedicated OMS there are the following assignments: – –

g 4.4.5

Identification of the eNB O&M address Note: Site ID, NE ID, and final OMS IP have to be pre-configured at NetAct.

Manual intervention There may be certain circumstances which will hinder a fully automated set-up of IP connectivity. To cope with those situations, an installer on site can help to finalize the procedure with the help of the BTS Site Manager. The Installer in this case, can use the Site manager tool to enter a SiteId attribute. This SiteId will be used by the BTS to identify itself during auto connection. Based on this Identifier the prepared SW files and configuration files will be assigned.

4.4.6

Monitoring Auto Connection via BTS site manager The dialog shown below is displayed automatically when the user establishes the BTS Site Manager session during the auto-connection process. The whole auto-connection process is divided into several phases, and their progress is displayed in the below dialog box.

DN0978045Issue:04A

©2016Nokia

217


Figure 25

4.4.7


Auto-configuration dialog

WCDMA BTS support of Auto Connection in an LTE network The FSMr3 hardware FSMF is coming with specific software (FDSW) from factory that supports auto connection/configuration into LTE current and future releases. The FSMr2 hardware units however may come from factory with WCDMA software stored in the flash. It is assured that a FSMr2 system module that is equipped with WCDMA software in factory, can connect to a LTE network. While auto-connection, the FlexiBTS running with WCDMA SW (WN6.0/ RU20MP2 at least) needs to be informed about its technology type and topology version by dedicated iOMS and has to indicate the distinguished name according to the target release within the Configuration Change Notification (CCN) when it requests configuration from NetAct. Impacts on BTS O&M interface

In the AER message there are the additional optional parameters NE-Type (technology type) and NE-SW-Version (topology version). OMS •

•

•

218

The dedicated OMS is pre configured with the target technologytype (mrBTS) and the topology version (LN1.0/LN2.0…) related to the NE that will connect automatically. The technology type and topology version are added to the AER-message (Auto Connection Established Response), which is delivered to BTS together with other data as a response to the AEI message. OMS includes the topology version into the topology event messageto NetAct (the parameter already exists in NWI3).

©2016Nokia

DN0978045Issue:04A



BTS •

•

In case the BTS is uncommissioned andauto connection is started, BTSgets the NE technology type and the topology version within the AER message. When the BTS is commissioned and normal start up is running, the BTS picks up the NE technology from SCF (Site Configuration File). BTS writes the technology type information to the CEI ‘neType‘ parameter and the topology version information to the CEI ‘neSwVersion‘ parameter .

Auto connection established response (AER) parameters

The Auto Connection Established Response (AER) message provides parameters, which indicate: • •

•

if the OMS could successfully identify the BTS the NE technology information, NE SW version, the resolved NE Id and the IP address of the final OMS information on failure situation indicating if NE should retry Auto Connection.

NE identification database

The NetAct planning tools support a new plan type, which contains information elements that allow resolving the NE Id from other identity information provided by NE. The following information fields are supported: • • • • • •

HW id GPS location info Logical Site id NE id NE type NE SW version

The technology information, as well as, software version is needed to support auto connection into an LTE network based on BTS 3G SW stored in factory.

4.4.8

Auto Connection workflow 1. The BTS/TRS (transmission system) checks for IP address. If it is not configured then the TRS starts the auto connection. 2. The TRS broadcasts DHCP Discovery. 3. The DHCP server sends DHCP offer with TRSIP, CMP IP/port, CA certificate subject name and OMS IP and remote tunnel end point IP. 4. TRS contacts the CMP server and downloads thecertificates from the CMP server. 5. The IPSec tunnel would be established to the security GW using the certificates downloaded from the CMP server. 6. BTS/TRS sends AUTOCONNECTIONESTABLISHEDINDICATION (AEI) to OMS. 7. OMS responds with AUTOCONNECTIONESTABLISHEDREPLY (AER). BTS ID, final OMS address would be provided in AER. 8. BTS/TRS establishes new connection to the final OMS sending CONNECTIONESTABLISHEDINDICATION (CEI). 9. The OMS responds with CONNECTIONESTABLISHEDREPLY (CER).

DN0978045Issue:04A

©2016Nokia

219


Figure 26


Auto Connection workflow using NetAct Auto Connection Installer

DHCP Server +Security Infrastructure

NE

OMS

MOC Operator

NetAct

Pre-Planning Install HW Power on NE Boot Retrieve IP address and vendor specific parameters Derive Certificates optional Derive Certificates Set up IPSec tunnel to VPN/Security Gateway Set up secure O&M connection Visual indication of OMS connection AutoConnectionEstablishedIndication AutoConnectionEstablishedReply

optional

Inform about installed NE (including identification of site and HW information Update BTS Planning Data Download updated BTS identification data to OMS

Determine BTS Id and final OMS

Set up connection to final OMS+NetAct(using BTS Id) Visual indication Autoconnection complete

Show NE as active

End Auto Connection

4.4.9

Interdependencies between features Table 127

220

Interdependencies between LTE154 features and others

LTE151

Autonomous Flexi LTE BTS Operability

LTE721

Support of a SW based secure key storage

LTE665

LTE Certificate Management - Cert & PKI handling

LTE663

LTE GPS Location Retrieval

©2016Nokia

DN0978045Issue:04A



Interdependencies between LTE154 features and others (Cont.)

Table 127 LTE720

4.4.10

LTE Auto Configuration

Use case: BTS/eNB Auto Connection This use case describes the NE behavior at the startup and gives an overall view of the auto connection feature from the NE point of view. Actors

NE, DHCP Server, OMS, NetAct Preconditions • •

NE hardware installation including cabling, dip-switch setting andso on is complete. The NE is physically connected to the Transport Network.

Trigger Event

An NE without site configuration data or with missing IP information is booted or restarted. Description

1. 2. 3. 4.

NE starts up and performs Power-On-Self-Test(POST). NE checks if it is already commissioned. NE checks the availability of BTS Id, Logical Site Id, and/or GPS location information. NE checks if it is connected to a local Site Manager. If this is the case, it proceeds with the next step only after it has received an acknowledgement from the Installer. This allows the installer to enter parameters which cannot be determined automatically (for example a GPS location that has been read manually from a mobile GPS receiver) or which must be adjusted since they are not correctly included in the planning data (for example antenna parameters). 5. NE checks the existence of other IP address parameters (own IP address, OMS IP address, Certificate Server IP address). If these are not available, they must be provided by the DHCP server, see next step. 6. NE contacts the DHCP server to retrieve missing IP parameters. 7. NE now must derive from certificates for use with TLS and (if required) IPSec. 8. If the IP address and parameters of a VPN/Security Gateway are available, NE sets up a secure IP connection to the mobile provider's network via the VPN/Security Gateway. 9. NE sets up a secure O&M connection to OMS usingTLS. 10. NE visually indicates successful connection to OMS. 11. NE registers itself to OMS and provides identification information (at least HW Id). 12. OMS supplies NE with BTS Id and information about the final OMS. 13. If the OMS (that NE is connected to) is different from the final OMS, NE disconnects and sets up a secure connection to the final OMS. 14. NE re-registers to OMS using its BTS Id. This can be the same OMS as in Step 11, or a different one. 15. NE visually indicates successful auto connection. Post condition

DN0978045Issue:04A

©2016Nokia

221



The NE is connected to NetAct and can proceed setting up connectivity over its telecom interfaces.

4.4.10.1

Registration to OMS and activation of new BTS/eNB in the topology Actors

NE, OMS, NetAct Preconditions •

• • •

The dedicated OMS has been pre-configured with BTSidentification data and NE technology information. NE object has been configured to NetAct with all necessary parameters. The NWI3 interface betweenOMS and NetAct is working. NE has successfully established secure TCP connection to OMS.

Description

1. NE sends an Auto Connection Established Indication (AEI) message to OMS. 2. OMS determines that itcontains NE identification data andNE topology information, i.e. it is a dedicated OMS. 3. OMS uses the identification information provided by NE to determine the NE Id and the IP address of the final OMS. 4. OMS sends an Auto Connection Established Reply (AER) message, which indicates the resolved NE id and the IP address of the final OMS. The NE technology type and main software target version of the NE are added as well. 5. The NE evaluates AER whether allmandatory information (NE Id, final OMS address) is provided. If the response is incomplete, the NE behaves depending on response (repeats AEI or restart Auto connection). 6. The BTS reads the technology type and the software version from AER. 7. NE disconnects from dedicated OMS and sets upsecure TCP connection to final OMS. 8. NE and final OMS exchange CEI/CER messages. CEI message includes NE-Id, NEType and NE-SW-Version parameter. 9. NE visually indicates that the connection to final OMS has been successfully established. 10. OMS sends a topology event to NetAct indicating the creation of a new NE. Post Conditions • •

NE has registered to final OMS. NE object has been activated in OMS and NetAct.

4.4.11 Parameters for LTE154: SON LTE BTS auto connectivity Table 128: Parameters for LTE154: SON LTE BTS auto connectivity shows parameters related to LTE154: SON LTE BTS auto connectivity

222

©2016Nokia

DN0978045Issue:04A


Table 128


Parameters for LTE154: SON LTE BTS auto connectivity

Short name

Object

Description

Range/step

BTSId_stored

BTSSC

Numeric Id by which NetAct identifies the NE

locationName

FTM

Logical Site Id

string 0...50 char

latitude

BTSSC

GPS antenna latitude

d eg-min-sec

longitude

BTSSC

GPS antenna longitude

GPSAntennaAl BTSSC titude

altitude of site

Default

2 byte integer

0

0

0

deg-min-sec

-250..10,000

0

0

4.5 LTE158: NTP Clock Time Synchronization 4.5.1

Introduction to the feature Theclocks Network Time Protocol (NTP)Network is a standard which makes it possible synchronize the / timestamps between Management nodes and the to Flexi LTE BTS over an IP backhaul network.

4.5.2

Benefits With this feature the time in NTP server(s) used for eNB is synchronized.

4.5.3 4.5.3.1



Systemrelease MME

RL09 -

SAE GW

-

NetAct

4.5.3.2


OSS5.2CD1


DN0978045Issue:04A

©2016Nokia

223


4.5.4


Functional description NTP Server(s) is introduced to provide the setting and adjustment of the internal clocks via the NTP protocol without degradation of the load processing by the Flexi LTE BTS. The addresses of a primary and secondary NTP server are configured as a dedicated IP address. The NTP server(s) used for the eNB are of stratum level 2 or better (higher) stratum levels are distanced from a Stratum-1 server over a network path. As such, a Stratum-2 server would get its time over an NTP link from a Stratum-1 server which provides the Universal Time Coordinated (UTC). The accurate time stamps are used for, for example, O&M time stamps to allow alarm correlation or for log entries and their evaluation.

g

Note: Information about local time zone is not provided via NTP, it is configured during

commissioning. The NTP is also needed for the TRS module UTC time. NTP server

Time clients use the NTP in consistent mode. A client sends queries to the time servers, which send universal time co-ordinates (UTC) to the client as a response. Based on time zone and received time, the network elements can calculate the time themselves. If the radio access network (RAN) covers more than one time zone, the user has to be very careful when comparing the time stamps in the alarms. The time of the alarm depends on the location of the element and from which point of the network the alarm is observed. to In the the time NetAct alarm system the time of the alarms are adjusted according zone setting of NetAct; sostamps in the NetAct alarm system the time stamps of different alarms from different network elements are comparable. The operator can also configure NetAct to use a different time zone for showing alarms. Activating time management

1. The IP address of the time server is set. 2. The time zone and daylight saving time (DST) information is set to the time clients. In the BTS, DST is not set separately but only the location information of the BTS site is configured. The time management setting is done, and the network element is ready to receive the time from the configured NTP server.

4.5.5 4.5.5.1


4.5.5.2


224

©2016Nokia

DN0978045Issue:04A


4.5.5.3



4.5.5.4


4.5.6 4.5.6.1

User interface Alarms for LTE158: NTP Clock Time Synchronisation There are no alarms related to this feature.

4.5.6.2

Measurements and counters for LTE158: NTP Clock Time Synchronisation There are no measurements and counters related to this feature.

4.5.6.3

Key performance indicators for LTE158: NTP Clock Time Synchronisation There are no key performance indicators related to this feature.

4.5.6.4

Parameters for LTE158: NTP Clock Time Synchronization Table 130

Parameters for LTE158: NTP Clock Time Synchronization

F u l ln a me

A b b r e v i a t e dn am e

List of NTP server IP addresses

4.5.7

ntpServers


INTP


Sales information

BS W/ASW

BSW


-


-

4.6 LTE432: Cell Outage Detection 4.6.1

Introduction Cells, identified as probably not providing service will be indicated with a quality of service alarm.

DN0978045Issue:04A

©2016Nokia

225



The detection mechanism of the featureLTE432: Cell Outage Detectionwill raise dedicated quality of service alarm for a cell in case it has been detected as “sleepy cell”.

4.6.2

Benefits The feature LTE432: Cell Outage Detectiondetects sleeping cells in the network and executes automatic corrective actions to put the cell in service again (cell outage correction). The operator benefits from a completely monitored network performance. • • •

Improved “fault management” in case of “cell outages / sleeping cells”. Higher cell and service availability. Automatic correction of service outages (self-healing).

The network operation is simplified and experiences in "traditional" networks showed good results in case of reset execution.

4.6.3 4.6.3.1

Requirements Software Requirements for LTE432 Table 132


Network element

4.6.3.2


Systemrelease

RL10

NetAct

OSS5.2CD3

Hardware Requirements This feature does not require any additional Hardware.

4.6.4 4.6.4.1

Functional Description LTE432: Cell Outage Detection Key Performance indicators, which indicate the success of critical procedures on the air interface (such as UE attempts to attach to the Network or establishment of a Radio Bearer) are evaluated to determine if there may be a problem in the cell. In addition, the current traffic in the cell is compared to historical data - encountering no traffic at an hour where there is usually a moderate or high load on the cell, is also a very likely problem indicator. The tools of the NetAct Reporter, Thresholder and Profiler applications are used for providing the correlation and alarm generation. This feature raises an indication that there may be a problem, so the operator must still check the situation in the cell and decide, which actions are to be triggered. This feature can be switched on or off in the Radio Access Network in “Thresholder & Profiler” in NetAct.

226

©2016Nokia

DN0978045Issue:04A



Figure 27: LTE432 Thresholder and Profiler in NetActgives an overview of the scenario. Figure 27

LTE432 “Thresholder and Profiler” in NetAct Alarm notification

Profile updates NetAct Reporter/ Global Reporter

Thresholder & Profiler

(K)PIs

4.6.4.1.1

E-mail notification

SMS notification

Failure Scenarios The following failure scenarios are taken into account: • • • • • • •

4.6.4.1.2

Failed RACH (Random Access Channel) access Failed RRC (Radio Resour ce Controller) connection setup Failed DRB (Data Radio Bearer) setup No RACH access No RRC connection setup No DRB setup No traffic

Alarm Generation Quality of Service alarms are generated in Netact Global “Reporter Threshold & Profiler.” For the generation of these alarms, eNB Performance Management Counters (uploaded automatically) and other O&M information e.g. alarms, states etc. are taken into account. To prevent false alarms, KPIs are compared against historical KPI result values. If there is no traffic in a time interval, where there is usually traffic (threshold exceeded), an alarm/notification is generated.

DN0978045Issue:04A

©2016Nokia

227



The following PM counters are taken into account: • • • • • •

4.6.5 4.6.5.1

Cell availability RACH failure rate RRC connection setup failure rate Data radio bearer setup failure rate PDCP cell throughput Uplink power measurements

System Impacts Interdependencies between Features Table 133 LTE432

Interdependencies between features Cell Outage Detection Sub-feature: LTE502: Cell outage triggered reset

4.6.6

Sales Information This feature belongs to Application Software (ASW) product structure class.

g 4.6.7 4.6.7.1

Note: For feature LTE432: Cell outage detectiona license is necessary. Feature LTE502: Cell outage triggered resetdoes not require a separate license.

User Interface Parameters for LTE432: Cell outage detection Table 134: Parameters for the LTE432: Cell Outage Detectionshows the parameters implemented for the featureLTE432: Cell Outage Detection. Table 134

Parameters for the LTE432: Cell Outage Detection

Name

228

Description

Default value

MIN_RACH_Threshold

Threshold for "MIN RACH"

MIN_RRC_Threshold

Threshold for "Failed RRC Connection Setup" and "No RRC Connection Setup" evaluation

50

MIN_DRB_Threshold

Threshold for "Failed DRB Setup" and "No DRB Setup" evaluation

50

MIN_PDCP_Threshold

Threshold for "No Traffic" evaluation

©2016Nokia

100

5 kBit/s

DN0978045Issue:04A



Table 134

Parameters for the LTE432: Cell Outage Detection (Cont.)

Name

Description

MIN_RSSI_Threshold

Threshold for "Degraded Uplink Power" evaluation

History_Evaluation

Attribute for historical KPI evaluation method used for "No RACH Access", "No RRC Connection Setup", "No DRB Setup" and "No Traffic" evaluation.

Default value

-100dbm)

7 days: historical KPI result value of corresponding time of day Min 7 days: minimum historical KPI result value for same time

4.6.7.2

Alarms for LTE432: Cell outage detection The following alarms are related to this feature: Table 135

Alarms for the LTE432: Cell outage detection

Alarm number

4.6.7.3

Alarm name

69301

Failed RACH access

69302

Failed RRC connection setup

69303

Failed DRBsetup

69304

NoRACHaccess

69305

No RRC connection setup

69306

NoDRBsetup

69307

Notraffic

Measurements and Counters for LTE432: Cell outage detection The following table shows the counters for LTE432: Cell outage detection.

g

DN0978045Issue:04A

Note: These counters do not serve just feature LTE432/502. They are collected also

for other evaluation purposes and are just re-used for the feature.

©2016Nokia

229



Counters for the LTE432: Cell outage detection

Table 136

Counter long name (short name)

Description

Cell Availability (CellAvail)

This KPI provides the Cell Availability mainly for permanent supervision of the eNB quality and for evaluation of Cell Outage detection scenarios.

RACH Failure Rate (RACHFailRate)

This KPI provides the RACH Failure Rate by dividing the failed RACH accesses through the number of received RACH preambles.

RRC Connection Setup Failure Rate (RRCConnSetupFailRate)

This KPI provides the RRC Connection Setup Failure Rate by dividing the failed RRC connection establishments through the RRC Connection Setup attempts.

DRB Setup Failure Rate (DRBSetupFailRate)

This KPI provides the Data Radio Bearer Setup Failure Rate by dividing the DRB Setups Failures through the DRB Setup attempts.

a) PDCP Data Rate uplink

This KPI provides the Cell Throughput on PDCP layer in uplink and downlink direction.

b) PDCP Data Rate downlink Short name: a) PDCP_DATA RATE_MEAN_UL b) PDCP_DATA RATE_MEAN_DL a) Mean RSSI on PUCCH

This KPI provides the Mean RSSI in uplink direction on PUCCH as well as on

b) Mean RSSI on PUSCH

PUSCH. This KPI can be used topower monitor the correct functionality of the a radio/air interface. In case uplink measurements show low values, malfunction of the eNB (i.e. power amplifier) could be ongoing.

c) Mean RSSI Short name: a) Mean_RSSI_PUCCH b) Mean_RSSI_PUSCH c) Mean_RSSI

4.6.8

System Responses to Failures This feature introduces the error codes shown in Table 137: Error codes.

Table 137

Error codes

Output DLDC feature

Name

Number

option_dldc_not_in_use_ec

000B4H

The DLDC feature cannot be enabled due to the fact that there is no license installed in the BSC, or the license in use has expired.

dldc_without_egprs_ec

000B6H

Self-explanatory

is not in use in BSC

DLDC cannot be

Description

enabled without EGPRS enabled in BTS

230

©2016Nokia

DN0978045Issue:04A


4.6.9


Activating the Feature To activate the feature see the NetActFeature Activation Manualin OSS5.2.

g 4.6.10 4.6.10.1

Note: For feature LTE432: Cell outage detectiona license is necessary.

Abbreviations 0–Z

DRB Data Radio Bearer

eNB evolved Node B

RACH Random Access Channel

RRC Radio Resource Controller

SCH Signalling Channel

4.7 LTE468: PCI Management 4.7.1 4.7.1.1

LTE468: PCI Management Overview Each cell of an LTE network needs to have a physical cell ID (PCI) assigned. The PCI is reported as part of the synchronization signal. As the range of PCIs is limited to 504 values and neither the neighbors of a cell, nor the neighbors of the neighbors shall have the same PCI value assigned, the value selection per cells needs to consider its environment. This feature includes the automatic assignment of PCI values to a cell.

4.7.1.2

Benefits Physical Cell ID assignment is done automatically.

DN0978045Issue:04A

©2016Nokia

231


4.7.1.3


NetAct Optimizer Automatic assignment will use the following algorithm in NetAct Optimizer: •

•

•

The already available ownneighbor relation information andthe neighbor's neighbor cells PCI allocation will be used as base for algorithm. NetAct does not assign PCI values that are seen in these neighbor configurations. The algorithm follows for allcells of one eNB some modulo rules and assigns PCI groups in consecutive order. This considers dependencies to base sequences and cyclic shift settings to achieve less interference of radio signals. Physical Cell IDs assignation is based on the closest distance of the re-occurrence of the equal PCI in an adjacent cell within the whole network. The distance is derived from the planned cell's geo-location data.

For cells served by the same eNB, different physical cell IDs will be assigned. Moreover, it will be ensured that neighbor eNBs and eNBs to be linked via X2 use disjoint sets of physical cell IDs. The assignment of PCI values allows the definition of forbidden ranges for all cells, planning distinct areas that do not overlap the configurations of PCI values for other purpose, for example home-eNB or border PLMN areas. PCI management will ensure eNBs to be linked via X2 use disjoint sets of physical cell IDs. The assignment of PCI values allows the definition of forbidden ranges for all cells or a group of cells. This allows for flexibility in network planning such as to define distinct areas that should not have overlap of PCI values. These areas may include home-eNB, multi-layer networks or border PLMN areas. The operator can define, on a per cell basis, whether or not to include a cell in automatic PCI management. This might be required in cases the operator performed manual corrections of assigned cells or wants to have highly loaded cells to be kept unchanged. Usually the PCI allocation is a part of the auto-configuration. The operator can run this later-on manually for a dedicated set of eNB(s) or cell(s) as desired. The operator can configure a scheduled execution of the PCI self-healing, that scans through all eNBs and checks any violation of the PCI assignment rules.

4.7.1.4

Collision detection with alarming in eNB With X2 Setup/Update message: 1. The eNB receives neighbor information via X2 messageincluding also neighbor’s neighbors information (optional) and stores it in the respective lists 2. The compares its own PCI with received entries: theof own servedlearned cells' PCI eNB or already known neighbor cells'the PCI values list is equal to Ifone a newly neighbor cells' PCI, the eNB behaves dependent on the feature activation situation: LTE1383: Cell Specific neighbor relation / PCI handlingis changing the X2 management

with respect to duplicated PCI. In RL50/RL25TD a new neighbor via X2 can have duplicated PCI.

232

©2016Nokia

DN0978045Issue:04A



If LTE782: ANR Fully UE basedis activated, there is a CGI-report requested from the UE to resolve an unknown PCI with respect to each single cell. Each cell is establishing individual neighbor relations (LNREL) to the neighbor cells (LNADJL or LNCEL). If LTE492: Automatic Neighbor Relationis activated, then the PCI/IP address table is used to resolve an unknown PCI. As basic support, if the equal PCI is present in one and only one LNADJL or LNCEL, then this one is used to establish a neighbor relation (LNREL). If there are more potential targets (same PCI in several LNADJL), then no neighbor relation is established. “Neighbor cell ambiguity detected” is raised, if the eNB cannot decide on a suitable neighbor relation in case of multiple suitable target cells with equal PCI value.

4.7.1.5

NetAct Self-Healing process The NetAct supports PCI self-healing. The operator can start manually or via a scheduled job the PCI self-healing process. The NetAct scans through the whole network to find any PCI rule violation and solves this with minimal impact to the whole network PCI allocation. The operator can have a final look on the new plan data before those are downloaded and activated in the network. If the operator has disabled the stop point for scheduled execution, then the changes are configured automatically.

4.7.1.6

External LTE object support for LTE468: PCI Management in NetAct

The LTE468: PCI Management feature considers all relevant LTE cells irrespective of the management system they are connected to. Since the cells managed by another management system also influence the selection of suitable PCI values, the NetAct's algorithms consider external cells when assigning PCI values to “own” cells. Nevertheless, the NetAct is not able to assign PCI values to external cells.

4.7.1.7

Interdependencies between features For LTE720: Auto Configurationthe LTE468: PCI Management for assigning the PCI value for all served cells is a precondition. All ANR features and the mobility procedures require a collision and confusion free PCI allocation. If LTE468 is not activated, then the operator has to pre-plan the physical cell ID values. The self-healing procedure updates the existing cell's PCI values if necessary. This has impact to other eNBs. NetAct will automatically update all LTE492 PCI/IP address tables impacted by this PCI value update. The eNBs will update the neighbor PCI values in the LNADJL object via the X2 link. In addition NetAct propagates via plan files any change for neighbors without X2 link, if NetAct has that neighbor cells under management.

DN0978045Issue:04A

©2016Nokia

233


g


Note: The feature LTE771 does detect high failure rates of neighbor relation (NR). One

reason can be, that wrong PCI values are still in a neighbor cell configuration without a X2 link (LNADJL). The operator should therefore double-check the black-listed neighbor relation (NR) for outdated PCI values. PCI updates can not be updated in theLNCEL - blacklistHoL. It is not recommended to use this kind of black-listing for PCI values inside the own network. Here LNREL handoverAllowed shall be used. LNCEL-blacklistHoL parameter is useful for forbidden PCI ranges, negotiated with neighbor PLMNs in border areas, or home eNB PCI ranges. These ranges can also be configured as forbidden PCI ranges in the LTE468: PCI management.

4.7.1.8

Alarms for LTE468: PCI management The following alarms are related to this feature. Table 138

Alarms for the LTE468: PCI management

Alarm number

6307

4.7.1.9

Alarm name

EFaultId_X2 Neighbour Cell Info Inconsistency

Parameters for LTE468: PCI management Table 179: Parameters for LTE720: SON LTE BTS auto configuration shows parameters related to LTE468: PCI management. Table 139

Parameters for LTE468: PCI management

Short name

phyCellId

Object

LNCEL

Description

Physical layer cell identity parameter defines a cell uniquely within a geo-graphical area with respect to UEs connected to one cell

4.8 LTE539: Central ANR 4.8.1

Introduction The LTE539: Central ANR feature is a centralized SON process for automatic neighbor relation (ANR) preparation. During auto-configuration (see the LTE720: SON LTE Auto Configuration feature) or manually triggered by the operator at the NetAct, the NetAct prepares for these eNB the most suitable neighbor cells based on geo-locations. The NetAct considers all LTE cells (inter- or intra-frequency) known within its scope. In addition the operator can add external LTE cells in border situations. The NetAct generates the configuration data that an operator would manually generate for the LTE724: Automatic Neighbor Cell Configurationfeature. The NetAct supports an

234

©2016Nokia

DN0978045Issue:04A



operator policy to define the wanted minimum and maximum number of neighbor cells per served cell. From that all closest intra-LTE neighbor cells within a distance limit are collected and their hosting eNB configuration is prepared.

4.8.2 4.8.2.1

Benefits Operator Benefits The automated detection and configuration of unknown cells or sites supports the selfconfiguration of the neighbor cell information without operator involvement and with reduced planning efforts. • •

•

4.8.3 4.8.3.1

The operator can preset the policy of the service to generate the neighbor list. The operator can pre-configure the lowertarget and the upper number of neighbor eNBs for each newly configured eNB. The operator can configure the threshold of the priority criterion (for example maximum distance, maximum difference in relative antenna main lobes).

Requirements Software Requirements Table 140


Network element

4.8.3.2


Systemrelease

RL10

OMS

GOMS6.0

NetAct

OSS5.2CD3

Hardware Requirements The LTE539: Central ANR feature does not require any additional Hardware.

4.8.4 4.8.4.1

LTE539: Central ANR Functional Overview/Details Feature scope

The LTE539: Central ANRrequests the NetAct Configurator and Optimizer to generate automatically LTE intra- and inter-frequency neighbor relations for a new eNB of an LTE network during auto-configuration, while the corresponding operational neighbor eNBs are not configured. It is assumed, that those will accept the X2 setup based on the LTE492: ANR or LTE782: ANR Fully UE basedfeature. The LTE539: Central ANR is a feature purely of the NetAct Optimizer and Configurator; the BTS will not be impacted by this feature.

DN0978045Issue:04A

©2016Nokia

235


•

•

•

•

4.8.4.1.1


The NetAct Optimizer generates adjacency information as required for UE management. The operator can control with a profile the number of minimum and maximum neighbor cell relation to be prepared for each served cell. The NetAct adapts this information to the eNB level neighbor relations and configures the required eNB identifications at the selected scope of eNBs. New installed eNBs will try to set-up the X2 link to the other peer. The NetAct Configurator will include neighbor cell relation information in the Configuration Management (CM) database for eNB auto-configuration. For the eNB the neighbor cell relation information isstored in the parameter database. One “Neighbor Relation” is always affecting two eNB DB.

NetAct Optimizer To support “Central ANR,” Optimizer creates for each (newly) planned eNB a list of neighboring eNBs based on a priority function composed of distance and antenna directions of the hosted LTE cells. The Optimizer identifies the neighbor relations based on cell-eCGI and identifies the required eNB-global eNB ID to inform the Configurator about the modifications. The list of neighboring eNBs: • •

•

The Optimizer passes lists ofneighboring eNBs to the Configurator. The Optimizer passes oneneighbor list for eachgiven eNB of the plan to the Configurator. The Optimizer and Configurator use the global eNB ID to identify eNBs.

The Optimizer ranks the list of cell neighbors according to a priority criterion and enforces the number of neighbor cells to be in an operator-definable range between the lower and the upper limit. The lower limit will only be enforced in case there are enough neighbor cells fulfilling the priority criterion.

g

Note: The aim of the LTE539: Central ANRfeature is to provide a ranked list of

neighbor eNBs to a given eNB. To reserve free entries in the neighbor table for not yet planned neighboring eNBs, it is possible to restrict the number of entries by limiting the number of neighbor cells. The policies, the lower and the upper number of neighbor cells and the priority criterion are existing mechanism for GSM and WCDMA neighbor cell configurations. Manual execution of Central ANR in Optimizer

Manual execution of theLTE539: Central ANR feature allows to determine neighbor eNBs according to an operator selected scope of eNBs based on geo-locations. Usually the eNB is in operational state and has existing neighbor eNBs. The manual execution of centralized ANR enforces the current policy. This means, that the neighborships for the selected eNBs are adapted to the latest findings of this workflow. As those eNBs run in a new NRT (Neighbor Relation Table) setup, the currently applied neighbor relation settings (for example, black listings and CIO settings) for deleted neighbor eNBs are useless. To avoid race conditions with the current configuration of the eNBs, the operator needs to disable existing decentralized ANR functions (the LTE782: ANR - UE Based and LTE492: Automated Neighbor Relation (ANR)features) in the scope of the selected eNBs. According to the described use cases, it is required, that the LTE782: ANR - UE

236

©2016Nokia

DN0978045Issue:04A



Based and LTE492: Automated Neighbor Relation (ANR)features are disabled during

plan provisioning. Of course the operator can enable the two features after the execution of the manually triggered theLTE539: Central ANRfeature. The use cases for manual execution of centralized ANR are: • •

Some eNBs have been installed without auto-configuration, no neighbors exist. The operator creates eNBs and manually creates plan files to be activated by installation personnel.

•

•

• •

Some eNBs failed during auto-configuration and needto be configured in a postprocess. The operator runs the network without the LTE492: ANR feature or the LTE782: ANR UE Based feature. Some eNBs have changed HW and cell deployment, andrequire re-configuration. Some eNBs have too much useless neighbors and needto obtain a new NRT.

The operator can select a scope of planned and/or operational eNBs and execute in NetAct Optimizer the tool for “centralized ANR”. This tool determines for each of the selected eNB a list of neighboring eNBs based on a priority function described below. The selected neighbor eNB might be: • • •

a part of the selected set other eNBs that are controlled by the same NetAct cluster external cells, which arecontrolled by anotherelement manager, even from an other vendor

During auto-configuration “Centralized ANR” ignores already planned neighbor relations, since it operates on a newly installed eNB. In contrast, if the user manually starts “Centralized ANR”, the algorithm needs to apply a certain replacement strategy to consider existing neighbors, that have been created manually or by ANR. Existing neighbor cells might be whitelisted or blacklisted, neighbor eNB might be blacklisted for handover via X2. Existing neighbors might have been optimized with respect to - for example - time to trigger or cell individual offset. Manual execution of centralized ANR supports distributed sites. The operator can configure the execution of the neighbor finding algorithm with preference settings: • • •

minimum required number of neighbor eNBs (irrespective of distance) maximum allowed number of neighbor eNBs (oamControlled LNADJ) maximum allowed distance between any cell-pair of source and neighboring eNBs

The neighbor finding algorithm ranks for each served cell of the selected eNBs the potential neighbor cells. The algorithm considers all managed cells of the NetAct cluster as well as all external LTE cells. For each found neighbor eNB, the Optimizer creates the respective LNADJ instances to the source eNB as required for each eNB. The NetAct Optimizer creates the configuration plan file for further processing in Configurator. •

•

DN0978045Issue:04A

The Optimizer deletes allnot required actual LNADJs and Configurator deletes their LNADJLs. The Optimizer creates all required LNADJs that are not yet existing and free instances are available.

©2016Nokia

237



The Optimizer reconfigures allexisting and required LNADJs to oamControlled Configurator also deletes all LNRELs related to deleted LNADJLs - no matter if those are blacklisted, have CIO settings different from default (“0”) or their nrControl property is set equal to “manual”.

• •

The NetAct Optimizer creates new neighbor eNBs. The configurator provides all further required information for the eNB to execute the LTE724: LTE Automatic Neighbor Cell Configuration feature functions to connect the X2 link.

g

Note: •

• •

•

•

•

•

•

During the execution of manually triggered centralized ANR the UE based ANR features need to be disabled to avoid a commissioning alarm and abort of the plan activation. The eNBs outside the scope of the selected eNBs will never be configured. The feature prepares the new LNADJs for the eNB feature LTE724: LTE Automatic Neighbor Cell Configurationas oamControlled LNADJs with the IP address. The IP address is not necessarily configured at both peers. Therefore, the operator should temporary enable theLTE782: ANR UE based or LTE492: ANR feature afterwards to enable the acceptance of incoming X2 links at the other peer. The workflow does not consider the capability of the eNBs to support ANR, intra- or inter-frequency LTE HO. If theLTE782: ANR UE Based or LTE492: ANR feature is configured at the other peer afterwards, then the peer will accept incoming X2 links. If the target global eNB ID is X2-black-listed, this is ignored for the LTE539: Centralized ANRfeature, as still S1 HO is supported. The LTE539: Central ANRfeature does not modify any X2-black-listing setting. The LTE539: Central ANRfeature does not consider the PCI configuration. It is left to the operator whether or not he runs LTE468: PCI Managementfeature to cleanup the PCI configuration The manual execution of central ANRdoes not support former ADIPNO LTE neighbor modeling as supported up to RL20. The operator has to run and provision the manually executed the LTE539: Central ANRfeature twice, if there are no sufficient free LNADJ instances available. The NetAct Optimizer gives a hint to the operator on the need for the second execution.

Use Case: manual execution of centralized ANR

This procedure describes the configuration of one or more planned or operational eNB(s) with LTE neighbor eNBs. This SON function is triggered by the operator for a scope of eNBs. NetAct Optimizer has to consider all planned and operational eNBs as possible neighbors and selects the best ranked ones for each eNB. Actors

The operator manually triggers the functionality for one or more eNBs. Preconditions

The geo-location data for the cells (respective the linked sites and/or antennas) in the selected scope of eNBs and the potential neighbor eNBs exist. The main lobe directions of the antennas exist or will be assumed to be omni-directional. NetAct Optimizer has refreshed all relevant CM data, like global eNB ID, CGI and PCI.

238

©2016Nokia

DN0978045Issue:04A



LTE492: ANR and LTE782: ANR UE Basedare disabled for all eNB in the selected

scope of eNBs during provisioning. Description

The following steps are supported by NetAct Optimizer in a manual triggered execution: 1. NetAct Optimizer allows the operator to select configuration data for the neighbor finding algorithm. 2. The operator selects a scope of eNBs. 3. The operator triggers the Centralized ANR tool of NetAct Optimizer to execute an algorithm that generates intra- or inter-frequency LTE neighbor eNBs. 4. NetAct Optimizer executes the neighbor finding algorithm for each eNB of the selected scope. Existing neighbor eNBs (LNADJs) that are not fulfilling the usergiven criteria anymore or are lower ranked compared to the new LNADJs are deleted by Optimizer/Configurator. Their child elements (LNADJLs) and the related LNRELs are deleted as well. The highest ranked found neighbor eNBs (LNADJs) full filling the operator defined criteria are added to the neighbor list of each eNB. 5. After checking and possible manual correction by the operator, hesaves the results to a new plan or merges the results back to the currently open plan and exchanges it to Configurator for further processing. 6. The Configurator complements the configuration of theneighbor eNBs and configures the mandatory parameter of the oamControlled LNADJs, like the IP address. 7. The operator triggers to download and activate the plan. NetAct Configurator triggers the consistency checks and forwards the plan via iOMS to the eNB. 8. The eNBs reconfigure online (without reset or cell lock) the eNB neighbor table. For all deleted LNADJ the respective X2 link is terminated. For all configured LNADJs the respective X2 link is maintained and set to oamControlled or is newly set-up. According to the execution of the X2 procedures and ANR settings the new neighbor information from X2 is obtained and is made available for call processing. NetAct will be informed with CCN and/or create notifications accordingly. Exceptions

If the neighbor eNB does not accept incoming X2 links, then the source eNB cannot update its neighbor cell information with respect to that neighbor eNB. Post-conditions

The selected scope of eNBs has a configuration of valid neighbor eNBs, that contains neighbors that comply to the criteria and policies as set in Optimizer. The former neighbor information is deleted, if not required any more. The eNBs operate on the new neighbor eNBs as it is configured for ANR and mobility functions (for example LTE724: LTE Automatic Neighbor Cell Configuration , LTE782: ANR - UE Based, ...) and will populate the NRT accordingly. Configurations of surrounding eNBs might be changed by terminated X2 links or incoming X2 set-up procedures triggered by eNBs in the selected scope.

4.8.4.1.2

NetAct Configurator The Configurator in turn finds for each global eNB ID the corresponding IP address, completes the entry in the attribute adjEnbIPAddressMap of the object ADIPNO (RL30: object LNADJ parameter cPlaneIpAddrCtrl) and writes this into a plan. In

DN0978045Issue:04A

©2016Nokia

239



addition the NetAct Configurator updates the other peer's plan files to have a symmetrical X2 configuration. At each neighbor eNB, identified by the global eNB ID, the attribute adjEnbIPAddressMap of the object ADIPNO is updated with the IP address and global eNB ID of the new eNB. With introduction of the common object model in RL30, the Configurator creates an LNADJ instance and sets the parameter cPlaneIpAddr, cPlaneIpAddressCtrl=oamControlled. After downloading and activating the plan, the affected eNB proceeds as defined by the LTE724: LTE Automatic Neighbor Cell Configurationfeature. The eNB starts X2 setup to another eNB (or other eNBs) and exchanges data about the cell it hosts.

4.8.4.1.3 4.8.4.1.3.1

External LTE Cell Support in NetAct NetAct SON features support for the external LTE cells

The external LTE cells in the NetAct are cells of another NetAct region or another vendor cells. The NetAct Configurator is able to support external LTE cells already with RL30. With RL30, the external cell and adjacency (X2 or S1) can be created manually by CM Editor or via northbound interface, XML, or CSV file input to Configurator. The external cell information is available in the NetAct in a way that SON features, as the LTE492: ANR, LTE469: PCI Management, can use it also for the border management of the external cells. The location information and antenna information is provided as well for the external cells and used in Configurator and Optimizer. The used OSS version is OSS5.4 CD2 or later versions. 4.8.4.1.3.2

Intra-system adjacency border area management Figure 28

Border area management - info model

(Target eNB) MCC:111 MNC:10

LNBTS-234

LNCEL (External LTE eNB) Further PLMN ID, m5 MCC:111 MNC:20 MCC:111 MNC:30

EXENBF

PLMN

EXEUCE

MRBTS

(External LTE cell) (Target eNB) LNBTS:234 MCC:111 MNC:10

1..1

EXENBF

LNBTS-345

EXEUCE

LNCEL

LNBTS

(Source eNB) LNBTS ID: 123 MCC:111 MNC:10

0..64 1..3

Further PLMN ID, m5

LNADJ

MCC:111

MNC:20

MCC:111 MNC:30

1..3, max 192

LNADJL

240

LNCEL

0..194

(NetAct region border)

LNREL

©2016Nokia

DN0978045Issue:04A


4.8.4.1.3.3


External LTE cell support for the LTE539: Central ANR in NetAct

The NetAct Optimizer considers external eNBs and its sub-ordinate cells as neighbor cell candidates during the centralized ANR configuration (the LTE539: Central ANRfeature). Similar as for the own-managed LTE cells the preference settings or the operator selections are applied for external eNBs and its sub-ordinate cells during neighbor cell candidate selection.

4.8.4.1.4

Neighbor relation clean up in the NetAct The NetAct is offering a tool support to clean up neighbor relation entrances in the eNB database. The operator has to select the entrances for deletion.

4.8.4.1.4.1

Optimizer: select and delete

In the NetAct Optimizer, a tool support for LNREL deletion is available and can be started manually by the operator. The operator can use sorting or filtering of LNREL instances based on available PM counter values as, for example, the number of HO attempts. The operator can request the deletion of these instances. The deletion request is provided to the NetAct Configurator via standard exchange of the plan file. See the steps in figure : Figure 29

LNREL deletion 1 Right-click, delete 2 eSlect top N

1.Select Scope, list to Browser 2.,3.,4., see above 5. Save to plan 6. Export to Configurator 7. Run plan prepare for “some stuff” 8. Provision plan

4.8.4.1.4.2

3

Sort ascending

for plan prepare Delete LNADJL if not referenced anymore Delete LNADJ if no LNADJL anymore

Configurator: delete consistently

In the NetAct Configurator, a deletion plan file request is executed in a consistent way with regard to related objects. The routine executes the following steps in automatic manner within “Plan/Prepare”: 1. All specified LNRELs are goingto be deleted. 2. In the next step all LNADJ & LNADJL objects without LNRELs are detected and deleted.

DN0978045Issue:04A

©2016Nokia

241



3. Deletions are done symmetrically for both ends of X2(deletion of LNREL) (in one NetAct region).

g 4.8.4.1.5

Note: The deletion routine is not preventing from the deletion of blacklisted neighbors.

It is up to the operator to decide about the entrances for deletion.

Central ANR for New eNBs This use case describes the deployment of a new eNB. The auto-configuration procedure performed in the NetAct is described. To support the immediate feedback to the eNB installation personnel, it is recommended that the eNB configuration is done instantly. Therefore, this use case considers one eNB to be configured. The NetAct Optimizer still has to consider all planned eNBs. Actors

The auto-configuration procedure is running on the NetAct for one new eNB. Preconditions •

• •

A new eNB has already been deployed and the auto-connection procedure has been executed. This means that the new eNB received M-plane, IP address from the DHCP server. The M-plane connection fromthe new eNB towards the NetAct exists. The C-plane IP address and the global eNB ID together with the geo-location ofthe planned and existing eNBs are known.

Description

The following steps are supported by the NetAct in the auto-configuration workflow: •

•

•

The workflow engine of Configurator triggers service of the NetAct Optimizer to generate a list of neighbor eNBs. This can be generated up-front based on the data received from the planning tool. The NetAct Optimizer generates a list of bi-directional neighbor relations of eNBs, based on the Operator policy, and the distance of the eNB to the new eNB in the current and planned network deployment. Service of Optimizer enforces bidirectional relationships and enforces the pre-set number of adjacencies. The NetAct Configurator incorporates the neighbor list received from the Optimizer into valid adjEnbIPAddressMaps, or from RL30 on it creates LNADJ instances. The Optimizer configures the global eNB ID of the list of neighboring eNBs in the new eNB's adjEnbIPAddressMap, or from RL30 on it creates LNADJ instances.

–

The Configurator complements theneighbor list of the new eNB with the corresponding IP addresses. The Configurator fills the ADIPNO.adjEnbIPAddressMap, or from RL30 on

–

creates LNADJ instances, of all neighbor eNBs with the address information of the new eNB. The NetAct Configurator continues theauto-configuration of the new eNB.

–

Post conditions •

242

The configuration ofthe new eNB has a valid ADIPNO the adjEnbIPAddressMap parameter, or from RL30 on created LNADJ instances, that contains neighbors complying with the criteria and policies as set in the Optimizer.

©2016Nokia

DN0978045Issue:04A


•

•

4.8.5 4.8.5.1


The configurations of the surrounding eNBs have valid ADIPNO the adjEnbIPAddressMaps parameter, or from RL30 on created LNADJ instances, that contains the new eNB as a target. The eNB will automatically set up the X2 links as defined in feature LTE724: Automatic Neighbor Cell Configuration .

System Impacts Interdependencies Between Features Table 141 LTE724

Interdependencies between features LTE Automatic Neighbor Cell Configuration LTE724 enables the eNB to exchange cell data via the X2 interface.

g

Note: The feature does not enable eNB to accept incoming X2 setup

requests from unknown IP addresses, in other words eNB is not able to learn IP addresses from incoming X2 setup.

LTE654

LTE Configuration Management

LTE720

SON LTE Auto Configuration Auto configuration workflow uses LTE539: Central ANR in order to automatically provide bi-directional neighbor relations between eNBs without the need for explicit planning.

LTE492

ANR LTE539: Central ANR in auto-configuration configures only the new installed eNB.

This eNB will try to establish a X2 link to all the other peers that shall become neighbor eNBs. The operator shall temporary enable LTE492: ANR at all neighbor eNBs to let them accept the incoming X2 link. LTE539: Central ANR triggered manually for a set of operational eNBs, requires, that those eNBs have feature LTE492: ANR disabled, as allowing incoming X2 links will end up in a commissioning alarm and the plan file will be abort. The operator shall disable LTE492: ANR ( LNBTS - anrOmExtEnable == False) manually as NetAct cannot do this automatically. LTE782

ANR - fully UE based LTE539: Central ANR in auto-configuration configures only the new installed eNB.

This eNB will try to establish a X2 link to all the other peers that shall become neighbor eNBs. The operator shall temporary enable LTE782: ANR - Fully UE based at all neighbor eNBs to let them accept the incoming X2 link. LTE539: Central ANR, triggered manually for a set of operational eNBs, requires, that those eNBs have feature LTE782: ANR UE Based disabled, as allowing

incoming X2 links will end up in a commissioning alarm and the plan file will be abort. The operator shall disable LTE782: ANR UE Based based (LNBTS actUeBasedAnrIntraFreqLte == False) manually as NetAct cannot do this automatically. "

4.8.6

Sales Information For “Feature Activation” see Feature Activation Manual in NetAct operating documentation OSS5.2.

DN0978045Issue:04A

©2016Nokia

243


4.8.7


Activating and Configuring the Feature To activate the feature see the NetActFeature Activation Manualin OSS5.2.

4.8.8 4.8.8.1

Abbreviations 0–Z

ANR Automated Neighbor Relation

eNB evolved Node B

4.9 LTE654: Configuration Management 4.9.1 4.9.1.1

LTE654: Configuration Management Introduction to the feature The LTE configuration management system helps the operator to run the network in an efficient way. With the full end-to-end provisioning chain with element management tools, data management, and handling up to network topology monitoring tools, the user operates the access network both in real-time and offline.

4.9.1.2

Benefits The BTS Site Manager (BTSSM) is an element management tool that provides a graphical user interface for creating and modifying site configuration, radio network configuration and transmission configuration plan files. These plans are then available to be downloaded, stored and activated to a single eNB via the BTSSM. The initial configuration is carried out locally at the eNB with the use of BTSSM by transferring the site commissioning file into the eNB and activating it. The commissioning file contains the parameters that are required for the initial HW configuration of the eNB. Next, the proper SW version and the radio and transmission plans are loaded into the eNB. In addition to this initial configuration, the features Auto-Connection /AutoConfiguration are offered. The SW and plans are activated after download. The activation causes a restart of the eNB. After initial commissioning SW and plan updates can also be executed from a remotely connected BTSSM. The newly downloaded plan file does not overwrite the radio and transmission databases that are already in use. Activation of the new data after download is initiated separately with a single command. An eNB restart is applied depending on the modified data, but an interruption-free activation is attempted at first.

244

©2016Nokia

DN0978045Issue:04A


4.9.1.3 4.9.1.3.1





Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.9.1.3.2

OSS5.2CD3


4.9.1.4

Functional description Configuration handling

The eNB site configuration plan (SC) portion, radio network (RNW) portion and transmission (TRS) plan portion are generated by offline planning. The plan portions contain changes to the attribute values for managed physical and logical objects of the eNB. The Nokia solution for LTE configuration management is based on the NetAct Configurator application. NetAct includes a: • • •

CM editor CM operations manager CM analyzer

The NetAct Configurator application allows for: •

Creating parameters and processing them

•

Exporting and importing parameter data

•

Automatic checking the validity of neighbor-related parameters between cells and nodes

The NetAct Configurator application outputs plan portions in XML format and distributes them to the eNB as a single file. The CM function in the eNB downloads the file and saves the configuration information in the flash memory. If NetAct is not accessible, the provisioning of all the plan portions can be done via the BTSSM locally from its file storage.

DN0978045Issue:04A

©2016Nokia

245



All modified radio-, transmission-, antenna- and general parameters are included in this plan. In addition, the BTSSM provides GUI for creating, editing, verifying, and storing all types of plan file portions either online (when connected to an eNB), or offline. Configuration change notifications are sent to NetAct to inform the operator about the new configurations. The NetAct Configurator application offers the means to import the configuration data from other planning tools as well, or from the eNB itself. If needed, configuration data can be modified and sent to the eNB within a single plan file. If the configuration data is modified, only the modified objects are sent to the eNB in the form of the delta file. After downloading the new configuration, it can be activated separately with a single command. eNB restart is applied depending on the data modified, but activation without interruption is attempted at first. When operator activates plans, the eNB checks if the changes of parameter values require modules to be restarted (such as in case of parameters having impact on HW behavior, for example frequency band modifications). If a restart is required, traffic downtime caused by updating the configuration is kept to minimum. Parameter changes with direct activation

With the NetAct Configurator application, the operator is able to modify several parameters. Single user interaction allows for the update to be sent to the eNB as a short delta file followed by an automated activation command.If consistency checks are passed successfully, the parameters enter directly into service, without the need of any activation procedure being triggered by the operator . Direct parameter operations on configurations

BTSSM allows the operator to modify all parameters via plan. Additionally, it also allows the operator to modify dedicated parameters with direct operation. The BTSSM performs then all the consistency checks, and if they are passed successfully, the parameters enter directly into service, without the need for any additional activation procedure being triggered by an operator. Consistency checks

Basic consistency checks used for detecting invalid database configurations are performed on the NetAct level as an integrated part of the NetAct Configurator application. In addition, the operator may use optional consistency add-on packages available for the NetAct Configurator application to configure more complex checks (such as checking parameter and feature dependencies). If checking fails, the plan file is rejected. State management

The LTE654: Configuration Managementfeature supports state management with the use of BTS Site Manager and/or NetAct. State attributes of objects can be viewed and, to some extent, also set. These attributes indicate the ability of the corresponding object to provide the specified service. NetAct supports views, by which the operator can check the state and status attributes for eNBs and cells: •

246

Operational State

©2016Nokia

DN0978045Issue:04A


• • •


Administrative State (cells only) Alarm Status Unknown Status

NetAct also supports other functions such as cell locking and unlocking, shutting cells down and eNB resetting. The operator can select multiple objects for processing. Site Manager, in addition, supports the Local State that can be used for blocking cells, RF modules or entire eNBs temporarily. A blocked object provides no service, but resumes normal operation after reset. ThisHW) state is introduced to support on-site maintenance activities (such as replacing without taking the object permanently outof-service. Administrative states are reset-safe. Thus, for example, a cell that is in a locked state, is not activated during eNB restart. Locally, the eNB can initiate changes of the operational states for itself and its own cells in response to eNB faults and eNB recovery actions. eNB will autonomously report state changes of itself and of its cells to NetAct. Transitional state changes of less than a few seconds are not reported. Independently of such autonomous reporting of state changes, the eNB allows for sending state attributes of a Managed Object Instance (MOI) to NetAct on request. For more information on state management of theLTE654: Configuration management feature, see System Management. Plan file data download and upload

Downloading and uploading the RNW and TRS plan portion or SCF portion have no impact on service quality, and do not degrade the service operability of the eNB. Configuration data backup & synchronization

The valid CM configuration can be uploaded on demand into the NetAct database e.g. to store a security backup or to serve as an input for NetAct to generate a new plan file. The backup interval can vary between sites as needed. If local configuration modifications are done with the BTSSM, the eNB configuration change notifications, including the modified configuration data, are sent to NetAct. SON initiated configurations

Self organizing network functions instruct the eNB to modify various attribute values or even to create new ones autonomously at the eNB level. Such changes are reported to NetAct. Network topology in NetAct

NetAct application shows the network topology. The topology is changed whenever one of its’ objects is created, updated or deleted. iOMS updates NetAct by sending topology event info. If the OM link is interrupted, iOMS requests the topology upload from eNB. If topology changes in the eNB occur (such as those initiated by SON), the eNB sends the topology update request to iOMS. O&M bulk data management

DN0978045Issue:04A

©2016Nokia

247



A bulk data interface for upload and download of mass data is supported between eNB and BTSSM. This bulk data interface at the eNB is necessary especially if a large amount of data is to be stored in the eNB (for example radio and transmission plans). Export and import of a complete eNB database including all radio and transmission configuration data is provided.

4.9.1.4.1

Architecture of configuration management Figure 30

Local and remote usage of BTS Site manager NetAct GUI Server

BTS Site manager remote eNB

RNW part

TRS part

SC part

local BTS Site manager

248

©2016Nokia

DN0978045Issue:04A


Figure 31


Mass operations in CM area (example)

NetAct

O&M Mediator

4.9.1.4.1.1

Architecture of configuration management operations

NetAct offers the possibility to execute mass operations as well as single BTS configuration operations.

DN0978045Issue:04A

©2016Nokia

249



With BTSSM, only single BTS configuration operations can be executed. 4.9.1.4.1.1.1

Architectural roles of mass operations Operator

The operator triggers the mass operations from NetAct. The user can also schedule operations with the NetAct Configurator application. NetAct

The mass configuration management operations are initiated from NetAct. The mass operations issued from NetAct identify each impacted eNB. In addition, NetAct provides data storage for copies of each eNB configuration. iOMS

iOMS is integrated in NetAct. iOMS splits up the mass operation command into single commands for each selected eNB. iOMS collects the results for the single commands from the eNB and sends them to NetAct. iOMS mediates data between NetAct and the eNB. eNB

The eNB is the target element for eNB radio, transmission and site configuration upload, download, and activation operations. It also provides a local data storage for the radio, transmission, and site configuration. 4.9.1.4.1.1.2

Architectural roles of single configuration operations Operator

The operator triggers the configuration management operations remotely with the Radio Access Configurator CM editor application, or with the BTSSM - either remotely or locally. NetAct

NetAct provides data storage for a copy of the eNB configuration data. BTSSM

BTSSM controls the single configuration management operations. BTSSM also provides a data storage for a copy of the eNB configuration data. eNB

The eNB is the target element for eNB configuration management operations. It also provides local data storage for the eNB configuration.

4.9.1.5 4.9.1.5.1

System impact Interdependencies between features There are no interdependencies between this and any other features.

250

©2016Nokia

DN0978045Issue:04A


4.9.1.5.2


Impact on interfaces The LTE654: Configuration Managementfeature introduces the CM interface between NetAct, iOMS, and the eNB.

4.9.1.5.3

Impact on network and network element management tools The LTE654: Configuration Managementfeature impacts the following network management tools: • NetAct • BTSSM

4.9.1.5.4


4.9.1.6 4.9.1.6.1

User interface Alarms for LTE654: Configuration Management There are no alarms related to this feature.

4.9.1.6.2

Measurements and counters related for LTE654: Configuration Management There are no measurements and counters related to this feature.

4.9.1.6.3

Key performance indicators for LTE654: Configuration Management There are key performance indicators related to this feature.

4.9.1.6.4

Parameters for LTE654: Configuration Management There are no new parameters related to this feature.

4.9.1.7


Sales information

BS W/ASW

BSW

4.9.1.8 4.9.1.8.1

Li c e n s e C o n tr ol i n N e tw o rk Element

-


-

Operating tasks related to configuration management Downloading plans to network elements Actors

The operator using NetAct tools, BTSSM. Precondition

DN0978045Issue:04A

©2016Nokia

251



NetAct, O&M mediator, and the BTS management plane is operational. The DCN connection between NetAct, iOMS, and network element (NE) is open. The BTS is commissioned. Description

1. The user starts the NetAct Operations Manager tool fordownloading the NetAct plan and selects the plan that contains the NEs to be configured, or the download operation is started according to a predefined download schedule. 2. NetAct creates an operation log for the results of the download procedure. NetAct updates the log online while the (mass) download operation proceeds. 3. NetAct validates the configuration plan. Both theplanned configuration and the existing full BTS configuration (if present) is used for pre-validation. 4. NetAct downloads theconfiguration plan file. 5. O&M mediator fetches the configuration plan file from NetAct. 6. O&M mediator splits and converts the configuration file into NE configuration files. In case of the O&M mediator NE configuration file, the file is stored in O&M mediator for activation. 7. NE fetches the specific NE configuration file from O&M mediator . 8. NE splits the NE configuration file into configuration portions and validates the integrity and completeness of the downloaded configuration portions. 9. NetAct informs the user of the status of theoperation. Validation results returned to the user if the plans are considered invalid by the NE. The actual service impact due to plan activation is also returned to the user.

4.9.1.8.2

Activating plans in network elements Actors

The operator using NetAct tools. Precondition

NetAct, O&M mediator and the eNB management plane is operational. The DCN connection between NetAct, iOMS, and the eNB is open. The plan is downloaded to the eNB. The eNB is commissioned. There is a new configuration plan downloaded to the eNB(s). The configuration plan is also already validated and ready for activation. Description

1. The operator starts the NetAct Operations Manager tool for configuration plan activation. The operator can either select the eNBs to be activated or the entire plan (all eNBs included in the plan) are activated. Then, the operator selects if the activation is immediate or is scheduled for a later time. 2. NetAct creates an operation log for the activation procedure results. NetAct updates the log on-line while the (mass) activation operation proceeds. 3. NetAct sends the activate command containing the list of selected eNBs to &M O mediator. 4. O&M mediator splits upthe command from NetAct and sendssingle activation commands to each eNB.

252

©2016Nokia

DN0978045Issue:04A



5. The eNB verifies that the activation command is valid. 6. If the plan requires the cells to be locked for activation and automatic cell locking has been enabled (LNBTS-enableAutoLock), the eNB locks the appropriate cells. If a graceful shutdown has been enabled enableGrflShdn ( LNBTS parameter), a shutdown instead of a lock is performed on the appropriate cells. 7. The eNB activates the parameters. Activation status can be successful or failed. If the parameter activation is successful new values are taken into use. If the parameter activation fails, the old values are used. Only failed parameter activations are reported in the activation response. If cells were automatically locked or shutdown due to configuration plan activation, they are unlocked. 8. The eNB sends the activation status to O&M mediator after all actions are completed. In case of failure, the parameters are listed for which the activation was unsuccessful. If the eNB site manager is connected, the activation notification is also sent to BTSSM.

g

Note: The eNB ignores some activation requests if they are not valid, for example, if

the operator requests a modification of a neighbor relation SON has removed. It is the change notifications that indicate what actually changed. 9. O&M mediator forwards the activation status of the eNB(s) to NetAct. 10. When the configuration activation is ready, the O&M mediator reports the status of the eNB(s) to NetAct. 11. NetAct informs the operator about the status of the operation. 12. Configuration change notification for each successfully created, deleted, or modified object is sent to NetAct through O&M mediator and to the BTSSM. 13. The eNB(s) determines the need for a restart depending on the parameter changed, and performs it. After the restart, the connection between O&M mediator and eNB is re-established.

4.9.1.8.3

Direct configuration modifications with BTSSM Actors

The operator using BTSSM tools for configuring specific eNB parameters. Preconditions

The connection between the eNB and BTSSM is established and working. The eNB management plane is operational. Description

1. The operator starts the BTSSM tool and is able to see the values for configuration parameters that are actually in use. The update is done automatically according upload scenario via the eNB O&M interface. 2. The operator can configure and changeone or several eNB parameter(s). The operator is able to identify the dedicated (TRS, SC objects) parameters that can be modified directly. 3. When the operator starts the configuration activation the BTSSM validates the parameter(s) that are to be changed. 4. The configuration request with configuration data (dedicated SCand/or TRS objects parameters) is sent to eNB. One request can contain requests for several parameters. 5. The eNB validates the parameter(s) that are received.

DN0978045Issue:04A

©2016Nokia

253



6. After a successful parameter validation, the eNB takes the configuration into use. Depending on the parameter, the change might require an eNB reset. 7. For keeping BTSSM up to date, the configuration change notification for each object is sent to BTSSM. The change notification can contain several parameters of one object, but a separate message is sent for each changed object including new configuration data. The BTSSM sends an acknowledgment for the configuration change notification to the eNB. 8. When the configuration change is completed, the acknowledgement forthe configuration change request including status is sent to BTSSM. 9. If NetAct is connected, the configuration change notification for each object is sent to NetAct through O&M mediator. 10. The BTSSM connection can be released by the operator.

4.9.1.8.4

NetAct Configurator operating tasks related to configuration management reference documentation For specific issues related to this document, see the following documents for more information. NetAct references: •

•

for an overview of the NetAct Configurator tools and the key concepts used in RNW and core network management, refer toNetAct Configurator Principlesin the NetAct library for more information on NetAct databases, see Managing NetAct Databasesand Database Description for NetAct Configurator in the NetAct library

•

for more information on NetAct Optimizer, see Optimizing a Network Using Optimizer and SON Scheduler Help in the NetAct library for more information about data flow in NetAct, see NetAct Data Flow in the NetAct library for more information on Configuration Management Process - see Configuration

•

for a description of the XML file format, refer t o XML Interface for Configuration

•

for a description of the CSV interface, refer to CSV Interface for Configuration

•

for more information on managed objects, see Managing Reference Configuration and Managing Adjacencies for more information on using CM Operations Manager - see CM Operations Manager Help for more information on using CM Analyzer - see CM Analyzer Help for more information on using CM Editor - see CM Editor Help

• •

Management Process Overview in the NetAct library Management Data Management Data

•

• •

for other information on using CM - see CM Reference and Viewing CM History LTE Configuration Management references: •

•

254

for more information on auto configuration, see LTE720: SON LTE BTS Auto Configuration.

©2016Nokia

DN0978045Issue:04A



4.10 LTE655: Software Management 4.10.1

Introduction to the feature The software (SW) management provided by NetAct services and Base Transceiver Station Site Manager (BTSSM) consists of software management functions focused to the Flexi Muliradio BTS. Those functionalities are downloading SW builds, activating SW builds, and uploading SW configurations. With NetAct several downloads and uploads may run in parallel for muitiple Flexi Multiradio BTS. A SW build consists of several files. Also SW update for parts of the SW are handled as builds consisting of one or more files updating the impacted SW segments. When a SW build is downloaded it can be activated immediately, or later by a dedicated activation request. The SW configuration upload functionality may be used to keep NetAct back-up database up-to-date.

4.10.2

Benefits The SW Management allows remote management of software configurations. The operator can view software configurations in a Flexi Multiradio BTS, initiate download, upload, activate actions and manage SW Packages in centralized SW archive.

4.10.3 4.10.3.1

Reguirements Software requirements The following software is required for the feature: Table 144



Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.10.3.2

OSS5.2CD3


4.10.4

Functional description SW management includes the actions needed to guarantee that the right version of the software is running in the network element (NE). It involves downloading software files, activation of software builds, and software builds status management. A software build contains the files related to a release. The main SW management functions are software download and software activation. In download, the new software is transferred from NetAct to the NE so that the operation does not affect the service level of the network. In software activation, the new software is brougjht into use. Software activation is usually done at night because activation requires restarting the NE and causes outage of NE services. For such use cases,

DN0978045Issue:04A

©2016Nokia

255



NetAct offers a command scheduling that allows a time-defined execution of the software download and software activation commands. Software build status management monitors the NE's software versions as well uploads the detailed software configuration data of the NEs.

4.10.4.1

Architecture of software management The iOMS, which is part of NetAct hardware provides mediation, concenration, and aggregation functions between eNB and NetAct From the eNB point of view there are following interfaces: •

BTS O&M interface between eNB and iOMS

•

NWI3 interface between NetAct and iOMS

•

XoH interface beetween eNB and BTSSM

Figure 32: Architecture of software managementshows the architecture of software management. Architecture of software management

Figure 32

NetAct OSS Framework Element Management System NetAct GUI Server

NetAct Application and Services NWI 3

BTS SM

iOMS BTS O &M I /F mediation

BTS O &M. IF / ASN 1.

HTTPs Client / Server

HTTPS (files transfer)

te o m e r

eNB

l a c lo

XoH HTTPS (files transfer)

BTS SM Element Manager LMT (PC )

256

©2016Nokia

DN0978045Issue:04A


4.10.4.2


Software management with BTSSM The Software Management consists of software management functions for downloading software builds, activating software builds, and uploading available software configuration between eNB and BTSSM. The software build consists of several files. When new software is downloaded it can be activated immediately, or later with a separate activation request. The activation of the software build may require a reset for the eNB but usually only modules/resources with new software are restarted. If the whole eNB or sub-parts reset, the related eNB resources are cleared in a controlled way when a new eNB software is activated. Software update

Software Update is done by delivering software builds, for example, by replacing one or more single files or through the installation of the whole software system. If a new version is available, the BTSSM offers a file descriptor table to the eNB including file descriptions and versions. The eNB makes a cross-check and downloads only the needed files from the BTSSM. Software activation

Bringing the software into use can either happen automatically as soon as the new software is loaded or by a separate action afterwards via the BTSSM. If the new package is not working properly fine after activation, the eNB raises an alarm. In case of restart loops or corrupted SW Build the eNB executes an automatic fallback to the previous running SW Build. Software inventory

It is possible to obtain a current view of the eNB software build version via the BTSSM. The operator is able to get information about the versions of the installed and locally available software objects.

4.10.4.3

Remote software management Software management includes the actions needed to guarantee that the correct version of the software is running in the eNBs. It involves downloading software files, activation of software builds, and software build status management. A software build contains the files related to a release of eNBs. The main software management functions are software download and software activation. In download the new software is transferred from NetAct to eNB, so that the operation does not affect the service level of the network. In software activation the new software is brought into use. Software activation is usually done at night, because activation requires restarting the eNB and causes outage for eNB services. For such use cases NetAct offers a command scheduling that allows a time-defined execution of the software detailed SW configuration data of the NEs.

4.10.4.3.1

NetAct software management solution The Net Act software management solution is called Software Manager. Software Manager is part of the NetAct Administrator function. With the Software Manager application, NetAct system administrators can archive, browse, and download the configurations of RAN node elements. The Software Manager user interface consists of three views:

DN0978045Issue:04A

©2016Nokia

257


•

•

•

4.10.4.3.2


The network software status view is used for: –

viewing the software configuration in a network

–

searching and comparing eNBs on the basis of the software configuration

–

uploading and downloading software configurations toand from eNBs

–

activating certain eNBs.

The software archive view is used for: –

importing software to the archive

–

browsing and viewing archived software

–

renaming and removing archived software.

The tasks view is used for monitoring the status of software management tasks.

eNB software management eNB software can be managed at a remote location with NetAct Software Manager or locally from the eNB BTSSM. iOMS mediates eNB software management messages between NetAct and the eNB. NetAct sends eNB software management messages to the eNB through the eNB management interface. The eNB has two software builds stored:as active and passive software builds.activation, When a new software is downloaded, it is stored a passive software build. During the status of the passive software build is changed to active. eNB software management operations can be executed as a mass operation. Mass operation means that Net Act manages software for several eNBs at a time with a single software management command. NetAct sets up a list of the eNBs that have been selected by the user. iOMS starts processing the given eNB list and sends required messages to each eNB. When the eNB has finished the operation, it gives feedback to NetAct.

4.10.4.3.3

eNB software management functionality The software build package is downloaded from NetAct to the eNB. In order to reduce the network capacity requirements, the eNBs are only fetching those software build files that are needed. Files that are already stored in flash memory will not be copied. In this way only a delta (changes) is downloaded to the eNB. For software corrections the same concept is used where the eNB only fetches the files that are actually changed. NetAct automatically triggers the upload of the configuration data after a software build has been activated. Software download to eNB

In software download operations, the new software is transferred to the eNB. eNB software download can be started either from NetAct Software Manager manually by selecting the particular eNB, or the download can be scheduled in NetAct. eNB software download can also be started from the eNB BTSSM.

258

©2016Nokia

DN0978045Issue:04A



Software activation

With software activation the downloaded software build will be activated. The activation is done through a restart which causes a service outage. Software download and activation can either be done as a one step approach where the activation is done automatically after download. Alternatively a two step approach can be used to separate the activation from the download. For instance the download can be executed in the background without service impact whereas the activation is executed during a low traffic period. For network-wide software activation, multiple eNBs can be selected by the NetAct Software Manager Application. The activation command is sent from NetAct through iOMS to the eNB. iOMS in the role of a mediator receives the NetAct triggered activation command with a list of eNBs and forwards the activation commands to the individual eNBs. Besides the central software management, all eNBs provide local software management through their BTSSMs. Software download and activation triggered by eNB

Macro eNB triggers a new software download to update its own software build, that is, when new HW is plugged in for which no build element exists. The downloaded software build element will be activated automatically. eNB software fallback

Software fallback is an automatic activation of an earlier SW version that is active before SW upgrade and is stored in the eNB. It is triggered by the system when the active software build is corrupted, a restart loop is detected, or there are critical exceptions while data is being converted to a new format. Since the eNB doesn't store the complete fallback SW for all HW units locally, the eNB requests a software update for the latest active software build version from the NetAct. Only after SW download from NetAct can service be re-established. After successful activation of the downloaded SW in all HW units service can be re-established. Any configuration updates done with the new SW will be lost, since eNB takes the configuration database into service that fits to the fallback SW.

g

Note: In case of automatic fallback, the NE will raise an alarm (

g

Note: In case of minor data conversion failures, no SW fallback will be initiated but the

STATION FAULTY) to indicate that the upgrade was not successful. After a fallback, the eNB configuration must be synchronized with NetAct via NetAct CM upload (LTE954: Intelligent configuration synchronizationfeature). 7650 BASE

error information will be indicated. The failures are logged in a non-volatile memory and include the detailed information about the reason of the failure. Consistent SW fallback

In RL70, the “consistent SW fallback” capability was introduced, which will be applied in case of an SW fallback from RL15A to RL70 and which prevents the need for an SW download from NetAct in case of an autonomous SW fallback When a system module starts up after an autonomous SW fallback, it shall check the SW consistency of the BTS with all the controlled HW units. Active as well as passive SW file versions (if available) are verified, and the SW version that fits to the system

DN0978045Issue:04A

©2016Nokia

259



module SW shall be activated in the HW units. This will allow activating the eNB with a consistent fallback SW state in all (controlled) HW units; an eNB can start into service autonomously without the need of an SW download from an external file server. An SW download from an external server is requested only in cases where no consistent SW version files are found on some of the controlled HW units.

g

Note: An alarm to the user will still be raised after an SW fallback to inform the user

g

Note: The SW consistency check of controlled HW units shall apply to all eNB FSM

g

Note: The enhancements to guarantee a consistent SW fallback, including the

about the event; however, severity is only major "BTS degraded."

types FSMr2 and FSMr3.

controlled HW units, are supported from RL70 onwards; this means that they are supported for fallback to an RL70 SW build version. They will not be supported yet for fallback RL70 to RL60 and RL50. SW fallback to those former releases will be performed without the new consistency enhancements. eNB software rollback

SW rollback is a manually initiated SW fallback using the BTSSM or NetAct SWM. It can be triggered by the operator when key services were not activated successfully after SW upgrade. Note that SW rollback is only guaranteed if the source SW version has not been removed or overwritten in a non-volatile storage (NVS). The SW rollback is done to the SW stored in the passive file system and no SW download from the server is part of the operation. If the passive SW has been overwritten with a different SW version, the rollback to the former release is not possible.

g

Note: Software downgrade must not be executed.

A SW downgrade to an earlier SW version is not guaranteed and may end up in an uncommissioned state of the eNB. Software rollback introduced in RL70 is considered more reliable than software downgrade used in earlier releases. This is because in software rollback the file systems are switched and the srcinal configuration files are used. Software rollback for a single eNB or for eNBs in bulk can be done using the NetAct SWM. Software rollback for a single eNB can also be performed on the BTSSM, using the Rollback to Passive SW function in the Update SW to BTS Site window.

g

Note: A SW rollback to the stored SW load restores the prior configuration. If there has

been a major network reconfiguration after the upgrade, such as reconfiguring the eNB from IPv4 to IPv6, then network connectivity issues can occur after the rollback. Reconfigurations after the SW upgrade must be evaluated before triggering SW rollback to avoid service outage. Software information upload

Software information upload is executed when the NetAct user wants to see the contents of software files in the eNB. eNB software information can be uploaded to NetAct either manually by selecting a particular eNB, or the upload can be scheduled in NetAct. eNB software information can be uploaded to local storage from the BTSSM.

260

©2016Nokia

DN0978045Issue:04A



The eNB software information can be uploaded in a mass operation, meaning that NetAct sends a list of eNBs and their software file version is then uploaded.

4.10.4.3.4

iOMS software management The iOMS software management includes the management of iOMS software updates and the mediation of remote eNB software management actions from NetAct. The remote software management for iOMS includes SW download and activation for minor software upgrade, SW monitoring, and software rollback. Minor software upgrades are typically fault corrections and enhancements. Minor updates can only be remotely processed when the update is backward compatible. Otherwise, the major software upgrade method is required. Remote major software upgrade is not yet supported. Supported NetAct operations

NetAct uses the existing software management infrastructure. The following NetAct operations are supported: 1. Download and installation The new iOMS software build that is imported to the NetAct software archive is downloaded from NetAct to the selected iOMSs and can be activated during and after stepup. iOMS installs the downloaded software build and creates a new software set. The download of the software build is done in the background without the service degradation. In software download, the “Software Download Progress Indicator” indicates the current step and the progress of the iOMS software management operation. 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. iOMS preserves the configuration data through a software update. During software activation, The iOMS must be restarted with the service impact. Status of the activated software set is changed from passive to active. 3. Software version monitoring NetAct requests information about the current software installed on iOMS. iOMS provides this information within the currentBD XML file. 4. Software rollback iOMS software rollback is supported by activating the previous software set. iOMS software management tools do not provide any explicit support for rollback of minor software upgrade. Active and passive software builds are stored in each iOMS. If there is a free storage space, iOMS is able to keep several passive software builds. The maximum number of software builds being stored in the iOMS is configured locally. At NetAct, the operator is able to monitor the software versions and the status information, which is updated automatically after SW download/activation. The operator is also able to upload the software configuration data at any time. Aside from the remote NetAct software management, a local iOMS element management is available. The iOMS major software upgrades are only handled on the iOMS element manager level only.

DN0978045Issue:04A

©2016Nokia

261


4.10.4.4 4.10.4.4.1


Use cases Software download to network element In software download operations the new software is transferred to the eNB: 1. The NetAct user selects the NEs (of same NE Type) and the software package to be downloaded. 2. NetAct operator selects the eNBs for which the new software build is to be downloaded. 3. NetAct sends one software download command including the list of selected eNBs to iOMS. 4. iOMS forwards the SW download command to each individual eNB referred to in the eNB list. iOMS downloads the SW Build also to its local file system. iOMS acts as a file server. 5. eNB downloads the software files from a fileserver and afterwards notifies iOMS. 6. iOMS notifies NetAct, that the software has been downloaded. 7. NetAct reports the result of the operation. 8. If the Automatic Activation Flag is True, the NE initiates after software download completion a restart and activates the new software build. 9. 15 minutes after the activation command was sent by NetAct an automatic SW Configuration upload is started by NetAct.

g

Note: Software activation is done by restarting either the required parts or the complete

software. Because activation may require restarting the eNB, and this causes outage of eNB services, software activation is usually done at night. In order to avoid unnecessary downloads iOMS keeps the latest downloaded software builds in local storage.

4.10.4.4.1.1

Software download to network element for FZM

In software download operations the new software is transferred to the FZM. 1. BTSOM creates connection to file server based on information received in SWUpdateRequest message. 2. BTSOM starts loading TargetBD.xml from the server (BTS manager/iOMS). 3. BTSOM updates SW download state to Ongoing depending on SW update srcinator either iOMS or BTS manager. 4. BTSOM mounts passive File System. This step is repeated for every buildElement in TargetBD.xml 5. BTSOM prepares the software load in passive partition. •

g

262

BTSOM removes from passive File System all files except persistent files and those determined as already present in passive File System. BTSOM copies all requested files from active File System to passive File System with related signature files if they exist. BTSOM calculates checksum of the each copied file and compares the checksum of the file with checksum given in TargetBD.xml Note: In case of TargetBD file, the checksum of the TargetBD file copied over from

active File System is compared against the calculated checksum of the downloaded TargetBD file.

©2016Nokia

DN0978045Issue:04A



•

BTSOM validates signature for each copied active file stored in passive File System. BTSOM calculates total size of SW files to be downloaded to BTS. In case of TargetBD file, the checksum of the TargetBD file copied over from active File System is compared against the calculated checksum of the downloaded TargetBD file.

•

BTSOM validates signature for each copied active file stored in passive File System then BTSOM calculates total size of SW files to be downloaded to BTS.

6. If SW update without automatic activation was requested or SW download failed, BTSOM log file with SWwith update details or BTSOM the SW update srcinator generates (iOMS or BTS Manager) SWUpToDate messageinforms that the requested file status is reached. 7. If BTS Manager was SW update srcinator: •

BTS Manager requests file transfer information for SWDLreport download with message SWUpdateReportRequest to BTSOM.

•

BTSOM replies with SWUpdateReportResponse.

•

BTS Manager loads the SWDLreport from BTS.

•

BTS Manager confirms the transfer with message FileLoadCompleted to BTSOM.

8. BTSOM updates SW download state to done.

g

Note: Software activation is done by restarting the entire FZM eNB which will result in

an outage of FZM services. Due to the need for an FZM restart, software activation is usually performed during periods where call traffic is low (for example at night). In order to avoid unnecessary downloads iOMS keeps the latest downloaded software builds in local storage.

4.10.4.4.1.2

Manual software download and activation

With the software download request a new software build can be downloaded from NetAct to NE. In addition the software build can be automatically activated after successful download.

g

Note: Please note the same command is used to activate an already downloaded

software build. In such a case NE recognizes that the software built is already stored at NE and does not download again the complete software build. In such a case the restart of the already stored software build is executed. 1. The NetAct user selects the NEs (of same NE Type) and the software package to be downloaded. 2. The NetAct user starts software downloading triggered manually or via scheduled 3. command. NetAct sends a software downloading request to iOMS. The request includes a list of the NEs, a link to the Target BD file to be downloaded and an activation flag to trigger the activation. 4. iOMS downloads the requested software build if necessary and stores software package to local file server, if the software build does not already exist. In order to avoid unnecessary downloads iOMS keeps up to 5 software builds in local storage. 5. iOMS sends the download requests to each NE mentioned in the list, the file server is now on iOMS level.

DN0978045Issue:04A

©2016Nokia

263



6. NE opens a session to the file server and downloads the files from the server (using the file server address given in the download request). The NE downloads first the targetBD file and checks the compatibility before the NE continues with the download of the new (missing) software build elements. If the targetBD is not compatible, the download will be terminated and a negative response will be send back to iOMS. 7. NE sends acknowledgement of the successful software download operation to the iOMS. 8. iOMS forwards the acknowledgement message to NetAct. 9. If the automatic activation flag is true, the NE initiates after software download completion a restart and activates the new software build. 10. 15 minutes after the activation command was sent by NetAct an automatic SW Configuration upload is started by NetAct.

4.10.4.4.2

Software file distribution in FZM After downloading the file from FTP/HTTP(S) server to BTS, BTSOM distributed the file to the all needed units. In this phase files are distributed into units, where those are stored into FLASH. In some case, files are stored into different units than final target unit. For that kind of units files are stored into FLASH in this phase and distributed into final target units in SW activation or BTS start-up phase. Units are able to store two versions of each SW file into FLASH and one only one version is active. 1. The NetAct user selects the NEs (of same NE Type) and the software package to be downloaded. 2. BTSOM requests CC&S to check if SW verification is enforced in PS environment by using function ddal_security_is_secure_env. 3. BTSOM requests CC&S to sign SW file using the AaFileSign function. 4. BTSOM requests the HWAPI to burn the downloaded SW file to passive file system in USB flash with API_OM_WRITE_FILE_TO_FLASH message. 5. BTSOM distributes file to TRS.

g 4.10.4.4.3

Note: Software activation is done by restarting the entire FZM eNB which will result in

an outage of FZM services. Due to the need for an FZM restart, software activation is usually performed during periods where call traffic is low (for example at night).

Software download and activation With the software download request a new software build can be downloaded from NetAct to NE. In addition the software build can be automatically activated after successful download.

g

Note: Please note the same command is used to activate an already downloaded

software build. In such a case NE recognizes that the software built is already stored at NE and does not download again the complete software build. In such a case the restart of the already stored software build is executed. 1. The NetAct user selects the NEs (of same NE Type) and the software package to be downloaded. 2. The NetAct user starts software downloading triggered manually or via scheduled command. 3. NetAct sends a software downloading request to iOMS. The request includes a list of the NEs, a link to the Target BD file to be downloaded and an activation flag to trigger the activation.

264

©2016Nokia

DN0978045Issue:04A



4. iOMS downloads the requested software build if necessary and stores software package to local file server, if the software build does not already exist. In order to avoid unnecessary downloads iOMS keeps up to 5 software builds in local storage. 5. iOMS sends the download requests to each NE mentioned in the list, the file server is now on iOMS level. 6. NE opens a session to the file server and downloads the files from the server (using the file server address given in the download request). The NE downloads first the targetBD file and checks the compatibility before the NE continues with the download of the new (missing) software build elements. If the targetBD is not compatible, the will be terminated and a successful negative response be send back to to iOMS. 7. download NE sends acknowledgement of the softwarewill download operation the iOMS. 8. iOMS forwards the acknowledgement message to NetAct. 9. If the Automatic Activation Flag is True, the NE initiates after software download completion a restart and activates the new software build. 10. Several minutes after the activation command was sent by NetAct an automatic SW Configuration upload is started by NetAct.

g 4.10.4.4.4

Note: Software activation is done by restarting either the required parts or the complete

software. Because activation may require restarting the eNB, and this causes outage of eNB services, software activation is usually done at night.

Software configuration (upload) A manual software configuration upload is triggered by the operator to update the software information at NetAct. When the SW configuration upload is need: 1. The NetAct operator selects the eNBs for which a SW configuration upload is requested. 2. NetAct sends one SW configuration upload request including the list of selected eNBs to iOMS. 3. iOMS forwards the SW configuration upload request to each individual eNB referred to in the eNB list. 4. The eNB prepares the current BD and afterwards notifies iOMS. 5. iOMS uploads the current BD file and stores it in its repository. 6. iOMS notifies NetAct that the BD files are present. 7. NetAct starts with the file transfer and uploads the current BD file.

4.10.4.4.4.1

Upload of the SW configuration file automatically after activation

Alternatively to the manual software upload concept, NetAct autonomously uploads the software config data several minutes after activation.

4.10.5 4.10.5.1

System impact Interdependencies between features There are no interdependencies between this and any other features.

DN0978045Issue:04A

©2016Nokia

265


4.10.5.2



4.10.5.3


4.10.5.4


4.10.6 4.10.6.1

User interface Alarms for LTE655: Software Management Alarms related to software management shows alarms related to software management. Table 145

Alarms related to eNB software management A l a r mn u m b e r

7650

A l ar m n ame

BASESTATIONFAULTY

7651

BASESTATIONOPERATIONDEGRADED

7652

BASESTATIONNOTIFICATION

For a detailed description see the alarms manuals. Table 146

Alarms for OMS Remote SW management A l a r mn u m b e r

4.10.6.2

A l ar m n ame

71110

STAGINGAREAININCONSISTENTSTATE

71111

SWSETACTIVATIONFAILED

71112

SWSETPOSTACTIVATIONSCRIPT EXECUTION ERROR

Measurements and counters related for LTE655: Software Management There are no measurements and counters related to this feature.

4.10.6.3

Key performance indicators for LTE655: Software Management There are key performance indicators related to this feature.

4.10.6.4

Parameters for LTE655: Software Management There are no new parameters related to this feature.

266

©2016Nokia

DN0978045Issue:04A


4.10.7



Sales information

BS W/ASW

BSW

Li c e n s e C o n tr ol i n N e tw o rk Element

-


-

4.11 LTE656: LTE Fault Management 4.11.1

Introduction to fault management The Fault Management (FM) functionality allows fault monitoring in the LTE RAN network. Faults are presented as alarm notifications that have certain basic characteristics in each network element for identifying and correcting the fault. Each network element keeps track of its own alarm situation and provides interfaces for viewing the alarms or managing the network element alarm system. These interfaces are provided to both local users via local user interfaces and to NetAct. Each network element type in the LTE RAN system has its own set of alarms that it can generate. Each alarm is documented separately. In this way the user gets the following information about an alarm: • • •

the meaning of the alarm description of the additional information relatedto the alarm instructions on how to analyze and correct the fault, if the fault correction requires user actions.

For details on alarms, see Flexi Multiradio BTS LTE Faults, Flexi Multiradio BTS LTE Alarms , and LTE iOMS Alarms and Troubleshooting. The main functions in the FM area on the system-level are: • •

alarm events alarm upload

Alarm events are used to keep the network management system up-to-date about the alarm situation in the lower-level network elements. These events are sent from the network elements as they appear and the events are buffered to prevent the alarm loss in an alarm event reporting congestion or a short network break situation. Alarm upload functionality provides a solution for synchronizing the alarm situation between the systems (if necessary). NetAct monitors the alarm flow from the eNB by using the heartbeat alarms, generated by the eNB with defined intervals. This heartbeat interval can be modified if needed. Alarm events are collected in the alarm history which is available for troubleshooting and network analyzing purposes. NetAct collects the RAN-level alarm history and the eNB provides local user interfaces for the network element-specific alarm history data. For further information on different alarm history viewing tools, see the product documentation of relevant network elements.

DN0978045Issue:04A

©2016Nokia

267


4.11.2


Benefits End-user benefits

The fault management system helps the operator to monitor the network. A decrease in the service level is reported to the operator, including the cause of the service loss. With the network monitoring tools the user gets information to start required actions.

4.11.3

Requirements Software requirements

The following table lists software required for this feature. Table 148



Systemrelease

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

NetAct

OSS5.2CD3

Hardware requirements

This feature has no particular hardware requirements.

4.11.4 4.11.4.1

Functional description for fault management Fault management principles The fault management system helps the operator to monitor the network. A decrease in the service-level is reported to the operator (including the cause of the service loss). With the network monitoring tools, the user gets the information to start recovery actions. The complete functionality of the eNB is supervised via alarms. The eNB detects faults, localizes them, generates Failure Event Reports (FER) and sends them to NetAct. Also via the BTS Site Manager the alarms can be managed locally for a single eNB. The alarm is generated immediately when a fault situation occurs (including the cause of the service loss). The alarms themselves are supplemented with the alarm manual pages to describe the conditions in more details.

4.11.4.1.1

NetAct NetAct provides a graphical user interface to view the active alarms with the related reports as well as the alarm history. The operator to modify alarm parameters, for example, the alarm severity. The report gives details on how the fault affects the services of logical objects in the network and, if available, the physical unit that caused the service loss. The report contains also the alarm number, which is an entry to the alarm reference manual, and an alarm text which explains briefly the fault and gives information on the severity level and time.

268

©2016Nokia

DN0978045Issue:04A



The alarm is generated immediately when a fault situation occurs. NetAct updates the alarm situation automatically. The alarm information provided via the NetAct northbound interface is assembled according to ITU X.733 and 3GPP TS 32.111 and comprises: •

• • • • • • •

the alarm type (for example communications alarm, resource shortage, equipment alarm, quality of service alarm, and so on) the emitting object the severity (critical, major, minor) probable cause specific problem notification ID alarm time additional text

This information is valuable for the operator in that it is easier to track down the source of the alarm and eliminate the trouble. To cope with the strong demand of the operators, that alarms contain information about the necessary maintenance measures resulting from the alarm, or that this maintenance information can be retrieved offline (for example, by means of the probable cause). Then the eNB provides maintenance information wherever possible. Within the eNB (and NetAct as well), it is possible to filter alarms based on criteria's like alarm Type, emitting object, and perceived Severity. Filtered alarms are not forwarded towards the NetAct monitoring system. Automatic interface alarm correlation

With the introduction of LTE424: Automatic interface alarm correlation , the number of alarms reported in NetAct can be reduced. Alarms caused by problems with S1/X2 interfaces, GTPU/SCTP path failure, or SCTP endpoint failure are correlated and only a dedicated interface-specific alarm is raised. The Flexi Multiradio BTS provides the correlation information in the alarm message. The user can check all the correlated alarms in the NetAct alarm correlator view.

4.11.4.1.2

eNB The eNB is able to identify each generated alarm which is also filtered by the toggling alarm suppression. It has a mechanism to keep track of the state of detected individual faults. It knows the active alarm situation and which are the current faults and related alarms. The severity level classifies the alarms according to their priorities and effects on services. The assignments of severity levels within the eNB are fixed and cannot be modified from NetAct or the BTS Site Manager. After the eNB reset and the connection establishment between the eNB and the BTSSM, an automatic alarm upload is initiated to ensure that the alarm situation in the BTSSM is up-to-date. The local alarm GUI data is updated in real-time (every time when a new alarm occurs). After a connection interruption between the eNB and the Site Manager, the eNB requests an alarm upload if the alarm situation in the eNB has changed during the connection interruption. It is possible to define external alarms in the eNB.

DN0978045Issue:04A

©2016Nokia

269


4.11.4.1.2.1


Critical alarms

Critical alarms require immediate actions from the maintenance personnel; all other alarms require actions during working hours. Handling of the alarms is carried out at different levels of the alarm system to simplify the pre-processing of the fault observations and to reduce the load on the whole alarm system. Alarms with severity warning are not treated as permanent faults. Hence, these alarms are not stored as active alarms in the eNB and are also not aligned to the NetAct when an alarm alignment is requested by the management system. The eNB maintains the currently active alarms. It will send these alarms to NetAct on request, independently of autonomous alarm reporting. (The definition of active alarm: an alarm event reported for a faulty condition with the severity minor, major or critical, which has not been already cleared by the eNB). One and the same alarm is not generated or sent more than once before it is cleared. 4.11.4.1.2.2

Clearing alarms

As soon as a fault condition is not active any more, the eNB sends a clearing alarm notification. Exceptions for automatic alarm clearing are the security alarms. This kind of alarms need to be cleared by the operator personnel also if the fault condition doesn't exist any longer. The emitted alarm clearing notification unambiguously identifies the corresponding srcinal alarm(s). After the eNB restart, the alarm situation is verified and only active alarms are reported, all others are automatically cleared. 4.11.4.1.2.3

Alarms per fault

Generation of more than one alarm per fault, that is, the generation of induced alarms, is avoided. However, exceptions may appear in the in the following two cases: 1. Alarming of key services with high importance for the operator 2. The primary fault is outside the scope of the NE and the current NE has no knowledge about it. An example of a key service is a cell that - as a consequence of some board failures goes out of service. An alarm is generated for the board failure, and induced alarms are generated for the affected cells. Each alarm has a unique notification identifier. The suppression of toggling alarms is supported. The configurable toggling conditions can be browsed, added and modified via BTSSM or NetAct 4.11.4.1.2.4

Alarm management

Alarms for both transport modules and antenna lines are supported: •

•

4.11.4.2

270

The transport modulealarms are collected inthe eNB alarm system and reported to the management system as radio eNB alarms. The transport module alarms are also included in the eNB alarm upload. The antenna line fault managementis supported by including VSWR alarming.

Suppress (block) toggling fault

©2016Nokia

DN0978045Issue:04A


4.11.4.2.1


Suppress (block) toggling fault functionality In order to reduce the amount of alarms in the BTS to the really important ones and in order to prevent the system from alarms which fill the alarm buffers but do not provide further important information, alarms which are raised and cleared in a short period of time and which do not give further information for fault analysis and fault localization are suppressed by means of a special algorithm. This algorithm detects toggling alarms as such and suppress the toggling alarm notifications after a specified time. If the same alarm is raised by the same MO "x" times within "y" seconds, the system enters the alarm toggling conditionfor this alarm in this related MO. During the alarm toggling condition, the single alarm clearance messages and alarm notifications are suppressed. The alarm toggling conditioncan be left in two different cases: Case 1: If the alarm is not present for "z" seconds after the alarm toggling conditionis left, an alarm clearance message, which indicates the end of the alarm toggling condition, is sent. Case 2: If the alarm in question becomes a stable state for the duration of "z" seconds, then the alarm toggling conditionis left (see also case 1) and the concerning alarm

message of the single alarm is sent to the management system. Figure 33: Suppress (block) toggling faults shows the suppress (block) toggling faults. Figure 33

4.11.4.2.2

Suppress (block) toggling faults

User interface Figure 34: Block Toggling Fault Feature in the Fault Viewshows the Block Toggling Fault Feature in Fault View

DN0978045Issue:04A

©2016Nokia

271


Figure 34


Block Toggling Fault Feature in the Fault View

Block toggling fault dialog is opened using a customized button. Also the fault table popup menu contains an item which opens the dialog. The correct fault row is automatically selected (fault name and HW resource) if there are any selections in the fault view. Toggling faults are shown in a separate icon in the fault table. The reported alarm field in the details panel shows what fault has affected the toggling fault. The toggling fault severity is the same as that of the srcinal fault. Each blocked toggling fault has its own toggling fault, so there may be several toggling faults in the fault table. Figure 35: Block Toggling Fault Dialogshows the Block Toggling Fault Dialog window Figure 35

Block Toggling Fault Dialog

Toggling fault blocking parameters are configured using the block toggling fault dialog. The dialog contains a static list with all faults and possible HW resources which may affect those faults. The table may contain the same fault a number of times because it may come from different HW resources. Additionally, the same HW resource may affect several different faults.

272

©2016Nokia

DN0978045Issue:04A



The user can take the blocking rule into use and configure the rule parameters. When the rule is in use, the rest of parameters are mandatory. The table supports multiselection and user can check all the used rules at the same time. The pen icon in the first column indicates a modified row and rule. Toggling fault block configuration table uses the online filtering. The filtering functionality is provided for the user, who knows what fault or HW resource rule is needed to be configured. Sometimes the static list may be long and it is hard to find a necessary rule. In those cases the filtering is useful. The user can select pre-defined filters or define own filters into table columns. The table content is filtered according to exists filters. The send button is used to send changed parameters. The button is disabled if the dialog does not have any changes or parameter sending is ongoing. The send button is also disabled if there are empty mandatory fields in the table. The progress is shown when parameter sending is ongoing. Thesave history button is used to retrieve the toggling alarm history file from the NE. This button is enabled when there are no changes in the table and parameter sending is not ongoing. Editable text fields are mandatory when the user has typed something to at least one column in the row. The text fields are also mandatory when the user has selected a row in use. Blocking rules are sent to an element if all the mandatory fields are defined. Figure 36: Filter definitions (example) shows an example of how to check and define filters for several alarms. Figure 36

4.11.4.3

4.11.4.3.1

Filter definitions (example)

Fault management related to LTE 447: SW support for RF sharing GSM - LTE RF sharing configurations The shared equipment needs to be managed in such way that both technologies exchange information, so they are aware of availability of the other side. The RAspecific cell lock/unlock does not lead to outage of other technology. If other changes, which require a restart, are made also the other technology is affected. Alarming

DN0978045Issue:04A

©2016Nokia

273



The alarms of the shared resources are doubled (there is a master and a slave alarm) and sent to respective technology-specific object, for example, a GSM cell and a LTE cell, of each system module. The alarmed resources are different for LTE and GSM objects and also the alarm ids are different. The alarms sent for shared objects include indication that this is a "shared alarm". No action needs to be triggered in case of a slave alarm, which is treated as an informative one. The master alarm triggers repair actions.

4.11.4.4

Architecture of fault management Figure 37

LTE alarm system architecture

NetAct

Northbound interface Alarm adaptation

Alarm database

Applications

NWI3 interface iOMS

Monitoring Tools NWI3 adaptation

Alarm system and database

BTS O&M adaptation

BTS O&M interface eNB

eNB OM functionality

OM functionality Proprietary interface

BTS site manager

4.11.4.4.1

BTS site manager

User The fault management functionality itself does not require user actions, because it is always active in the background, and the alarms are presented to the user when they occur. The user can, however, trigger the alarm upload from a certain network element, if it is suspected that the alarm situation is not up-to-date.

4.11.4.4.2

NetAct NetAct tools provide a real-time view of network alarms. Alarms are forwarded from the eNB to the NetAct, so the user has continuous access to the most recent alarm situation in the LTE RAN network. The user can trigger the alarm upload from the network element manually if needed, by using NetAct tools.

274

©2016Nokia

DN0978045Issue:04A


4.11.4.4.3


eNB The eNB alarm system collects the alarms from the eNB and its transport module. The alarms are buffered in the eNB and sent to the NetAct alarm system or mediator one by one via the eNB O&M interface. The alarm upload is started on the eNB request when needed.The eNB local UI provides a view to active alarms of a single eNB.

4.11.4.4.4

BTS Site Manager With the BTS Site Manager, the alarms can be managed and viewed locally for a single eNB.

4.11.4.4.5

iOMS The iOMS acts as a mediator between eNBs and NetAct. It receives the data from several eNBs and forwards them to NetAct. It also provides storage for the FM data.

4.11.5 System impact Interdependencies between features


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 tool. Impact on system performance and capacity

This feature has no impact on system performance or capacity.

4.11.6

User Interface This section lists the management data related to the fault management area.

4.11.6.1

Parameters for LTE656: LTE Fault Management Table 149: Parameters related to LTE656: LTE Fault Managementshows parameters related to LTE656: LTE Fault Management. Table 149

Parameters related to LTE656: LTE Fault Management

Full name Toggling alarm suppression list (structure)

DN0978045Issue:04A

Abbreviated name alToggSuppList

Toggling alarm amount

alToggAmount

Toggling clearance time

alToggClearenceTime

©2016Nokia

Managed object BTSSCL

BTSSCL BTSSCL

275


Table 149


Parameters related to LTE656: LTE Fault Management (Cont.)

Full name

Abbreviated name

Toggling alarm condition time

4.11.6.2

alToggConditonTime

BTSFaultname

faultName

Suppression of toggling alarms in use

inUse

Managed object

BTSSCL BTSSCL BTSSCL

Alarms for LTE656: LTE Fault Management Table 150: Alarms related to LTE656: LTE Fault Managementshows alarms related to LTE656: LTE Fault Management. Table 150

Alarms related to LTE656: LTE Fault Management

Alarm ID

4026

Alarm name

Toggling:

For information on alarms related to LTE424: Automatic interface alarm correlation , see LTE424: Automatic interface alarm correlation .

4.11.6.3

Measurements and counters for LTE656: LTE Fault Management The are no measurements and counters related to fault management.

4.11.6.4

Key performance indicators for LTE656: LTE Fault Management The are no key performance indicators related to fault management.

4.11.7


BSW

276


-


-

©2016Nokia

DN0978045Issue:04A



4.12 LTE657: Performance Management 4.12.1

Introduction to the feature The LTE657: Performance Management feature provides the operators with continuous up-to-date information, enabling them to maintain a high standard of network operability for their customers. With a NetAct Threshold Based PM Alarming, it makes it easier to detect faults, identify bottlenecks, and optimize the network. Flexible KPIs provide a quick view of the actual network performance.

4.12.2

Benefits With the LTE657: Performance Managementfeature, the operator gets an overview of the network performance and the Flexi Multiradio BTS status and performance. OPEX/CAPEX savings and enhanced end-user service quality are achieved with a continuous monitoring of the radio network. The operator is able to set thresholds for alarms on performance management data. KPI values calculated from the performance measurements provide valuable information about the network performance.

4.12.3 4.12.3.1




Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.12.3.2

OSS5.2CD3


4.12.4

Functional description The LTE657: Performance Management(PM) feature provides the framework for administering, collecting, storing, and processing of the performance measurement data and the performance-related statistical data. This is required before this data can be further utilized by various network and service management tools. The Radio Network and Transmission Network Monitoring Statistics provide the operators with continuous up-to-date information, enabling them to maintain a high standard of network operability for their customers.This feature consists of the following operability aspects:

DN0978045Issue:04A

©2016Nokia

277


• • •

•

•


measurement management via NetAct collection and intermediate storage of themeasurement data inthe eNB upload of the measurement data tothe NetAct management database(or to the BTS Site Manager) for viewing the data display of counters and KPI values calculated by the NetAct performance application or a simplified display of counters with the BTS Site Manager (BTSSM) set of thresholds for alarmsrelated to performance management data

The stores the performance in files.to The files are stored at least for 24 hours. This eNB storage in network elements data (in addition NetAct) helps in case of backhaul outages. NetAct collects the measurement data from all eNBs and correlates them. After receiving a notification about the PM data file readiness for transport from the eNB, NetAct fetches the files and stores them in a database. Threshold-based PM alarming

With the use of NetAct, the operator is able to define, update, and browse the appropriate performance threshold configurations, based on a threshold supervision. When the performance data is gathered from the measured objects in the network, their values are compared against any active threshold limits. When the performance threshold is exceeded, an alarm is generated and sent to the NetAct alarm system. A log containing the introduced threshold alarms is stored in NetAct. The saved event parameters include the threshold rule name, formula, event time, and the object for which the threshold was exceeded. The files are stored in NetAct for a configurable number of days before an automatic deletion. KPI calculations

NetAct provides the means to calculate the KPIs. Network performance can be evaluated based on KPIs, which present vital network information. KPIs are either an individual counter or a combination of several counters defined for radio and transport KPIs. This combination of counters can be a variable definable with the KPI formulas at the NetAct level. The KPI formulas for NetAct can be browsed, added, updated, and the calculated KPIs can be viewed as any other PM counter value. PM data transfer and supervision by NetAct

The counter file is uploaded to the NetAct or BTS Site Manager via a file-based interface and the bulk data file transfer has no impact on the service quality. It does not degrade the services of an operating eNB. There are various built-in recovery mechanisms, so the alarms are generated only for situations that: • • •

result in a loss of data require an explicit action for resolution indicate a problem in performance of measurementdata processing ortransfer

These PM-related alarms are intended to cover the PM-specific aspect of the data pipe. There are separate mechanisms to notice, for example, general problems with the DCN connections. The PM data reliability is important for reporting and managing the network. A clear indication is given if data for some measurements, intervals, or measured objects is lost. In normal operation, no data is lost between the eNB and NetAct. Temporary

278

©2016Nokia

DN0978045Issue:04A



malfunctions in SW or a temporary loss of backhaul connectivity are handled, for example, by buffering or retransmission. However, after an eNB restart, a lack of a suitable non-volatile data storage may cause a loss of the non-transferred PM data. PM Counter Licenses

Counters are licensed based on counter categories; there are three granularities for licensing: •

•

•

g

Counter category Basic Counter Package: no separate license is needed because the counters belong to the basic feature package of an eNB. Counter category Feature Counter Package: counters belong to a Telecom or Transmission feature (a corresponding feature license is needed). When a feature is licensed and enabled, the related counters are licensed automatically. Enhanced counter packages which are not part of the Feature Counter Packages: operators can buy such packages; each package needs its own license, which is enabled by a feature enabling flag in the configuration database. Note: Counters for non-licensed features are not reported if they do not belong to the

basic counter package. Performance Data File Formats

The eNB delivers the files in an OMeS XML format compressed with gzip. NetAct is able to generate the performance data in an XML schema-based format (3GPP TS 32.435) and supports (as default) the NSN Measurement Data Export (MDE) export interface, based on the OMeS XML, which is the most widely used NetAct export format. In the case of the 3GPP schema, NetAct export follows the file naming convention for the result files according to 3GPP the TS 32.432.

4.12.4.1

Functional description for performance management The LTE PM architecture is scalable so that one NetAct can host several iOMS mediators, and each iOMS in NetAct has connections to many network elements. With the BTS Site Manager (BTSSM), also some local administration settings can be done for the eNB. The PM data presentation is possible in: • •

the BTSSM, for a lower-level local analysis NetAct, for a detailed, network-wide analysis

Other NetAct PM applications such as Reporter or Optimizer also use the PM counterbased performance measurement data for further evaluation. They offer detailed presentation and customized reporting to the end user, for example: • •

evaluation of the network performance basedon KPIs performance measurement thresholdalarming based on threshold source data coming from single counters or formulas that consist of several counters

The PM data flow goes mainly in the bottom-up direction. The iOMS in NetAct collects the data files from all connected eNBs. It collects the received PM data and forwards those aggregated PM data files to the higher level NetAct applications. In NetAct, the PM data of the whole radio network is assembled and stored for up to two weeks. A data export interface allows the export of the collected PM data from NetAct to any other system.

DN0978045Issue:04A

©2016Nokia

279


4.12.4.1.1


Terms in performance management Table 153

Terms in performance management Te r m s

M e an i n g P e rf o rman c e M a n a g e m e n t : A set of functions

PM

that make it possible to measure the performance of the network services and to take corrective actions. KPI

K e yP e r f o r m an c eI n d i c at o r : A criterion by which an organisation can determine whether the outcome associated with a capability exists or the degree to which it exists.

AoM

A d m i n i s t r a t i o no fM e a s u r e m e n t s : NetAct function for managing the performance measurements.

PmC

P e r f o r m a n c eme a s u r e m e n tC o n t r o l :

Function that is responsible for the retrieval of PM counter results from the measurement data providers and the generation of performance reports in the network elements according to the administration settings. A metric that gives information about the performance of a network element, process, or function, on network element or network

performance indicator

subsystem level. NetAct tool that provides a view of the network and service performance and enables the operator to analyse network data, create reports, and distribute the information within the operator's organisation.

reporter

P e r f o r m a n c eM e as u r e m e n tp r o v i d eA r: function that provides the measurement data in PM counters.

PM Pr ovi d er

performance measurement

4.12.4.1.2

Part of performance management that includes gathering, analysing, and reporting statistical measurement data.

Measurement administration Only counters that belong to the activated groups are reported to NetAct or to the BTSSM. In RL30, measurement type can be activated/deactivated the introduction of every the LTE602: Performance Management Administrationseparately feature). (with

g

Note: If some counters, within a counter group, belong to a feature that needs a

dedicated license, these counters are reported only if the feature is licensed and enabled. The measurement interval can be set separately for every measurement type. The supported intervals are:

280

©2016Nokia

DN0978045Issue:04A


• • • • • •


15 minutes (default value) 30 minutes 60 minutes 6 hours 12 hours 24 hours

When the measurement interval expires, the current file is closed, a new one is opened and the old one is compressed. The interval starts are synchronized with 0:00 o'clock as a masterframe. The reporting interval triggering the upload towards NetAct is adjustable (see Upload interval). When the reporting interval expires, a notification, indicating that one or more PM files are ready for transfer, is sent to NetAct. The reporting intervals follow the measurement interval timing, so they are shifted by the time needed to compress the previously closed file.

4.12.4.1.3

Measurement collection The O&M sub-system provides the PmC function as part of the common PM framework. The data providers monitor numerous events, procedures, state changes, and collects them into counters according to the counter content definition. All these data providers collect and provide measurement data under the control of the PmC function in the NE. The data providers itself are part of the technology specific PM framework.

4.12.4.1.4

Measurement data storage In the eNB, all the collected PM data are stored by the PmC in a raw PM data result file (one file per measurement interval, for multiple measurement types) at the end of each measurement interval. This is valid for both radio and transport PM measurements. Each PM data report file is stored for up to 24 hours in the eNB before being deleted. After the merged PM report file is generated, the srcinal raw PM report files can be deleted. At the network management site, all measurement data that has been uploaded through the mediator (iOMS), as PM report files, are stored in a PM network database for mid and long-term storage, for example, one week and longer (Reporter). The eNB reports the collected measurements for both radio and transport PM counters in periodic intervals. If the data is not uploaded into an external file storage within 24 hours, older measurement intervals are lost in the eNB.

4.12.4.1.5

Measurement data transfer A reliable mechanism for the PM file upload is provided. An automatic PM file upload is possible independently for aPM network management system (NetAct)(NetAct, or BTSSM. The eNB notifies about the prepared files for upload to those managers BTSSM) which have subscribed to the eNB for this service. Two procedures are available: • •

DN0978045Issue:04A

one for the network managementsystem to reliably uploadthe PM report files one for the local manager to quickly upload the raw PM result files

©2016Nokia

281



It is necessary to ensure that NetAct gets all the generated PM files without any gaps. All the measurement intervals have to be available. This is supported by the eNBs by maintaining a list of unacknowledged PM report files as a part of the PM file upload procedure for NetAct. These unacknowledged (not uploaded) PM report files are passed on to iOMS/NetAct again within the next upload cycle. However, it is not necessary to guarantee a PM file upload without gaps for the BTSSM because this automatic file upload for the BTSSM is not the standard use case. Therefore, it does not need to be so reliable as for the NetAct case; the not uploaded PM report files are not notified to BTSSM again. The BTSSM is used in some specific temporary cases for test, service, or troubleshooting purposes, but on the local management site it is more important to get a quick upload as soon as a measurement interval has ended. Therefore, the raw PM result files are used. Each time a new raw PM result file is generated at the end of a measurement interval, the local manager is informed with a file load message about a new raw PM result file (including its name) which the BTSSM can upload. Upload interval

An upload interval is a period of time when all raw PM files are merged together in a single result PM file that is uploaded to NetAct. With the introduction of the LTE877: Adjustable Performance Upload feature, this interval can be configured by the operator. The following values are available: •

15 minutes

• •

30 minutes minutes 60

The upload interval is always aligned with a full hour. Every time the measurement interval expires, the eNB creates a raw PM file, one for each measurement interval which is running in eNB, and which has expired at the same moment. The raw PM file is an intermediate file which is intended to be merged when the upload interval expires.

4.12.4.1.6

Measurement data presentation At the NetAct level, there is a possibility to process the performance measurement data for presentation and reporting to the end user. The existing tools such as Reporter and Optimizer are able to access the centralized database that contains the measurement data collected from the eNBs. These tools provide a powerful graphical presentation and report possibilities, enabling the operator to analyze the performance of his network with relevant long/short-term reports. These reports support different reporting needs within different operator business processes, for example: • • • • • •

282

Management reports Network performance reports Geographical reports Reports to support troubleshooting Customized KPI reports Data export interfaces

©2016Nokia

DN0978045Issue:04A



It is possible to evaluate network performance based on KPIs, which are either individual counters or a combination of several counters. Radio and transport KPIs are definable with NetAct and can be browsed, added, and updated. The calculated KPIs, as well as any other PM counter value, can be viewed. At the BTSSM level, it is possible to view the performance measurement data in a tabular or graphical presentation for short term analysis locally at the eNB site. The selectable counter values during selectable measurement intervals are applicable.

4.12.4.1.7

Measurement data threshold monitoring The NetAct Threshold Monitoring (function of the Reporter application) analyzes the collected performance measurement data that is inserted into the database. If a predefined threshold is exceeded, an alarm is generated and passed to the NetAct fault management system, where it can be further processed or visualized (just as any other alarm). With the use of NetAct, the operator is able to define, update, activate, and browse the appropriate performance measurement thresholds, based on the threshold source data coming from single counters or counter formulas. For each of the alarm levels (Warning, Minor, Major, Critical), the threshold levels can be separately configured. A log containing the threshold alarms is stored in NetAct. The saved event parameters include a threshold rule name, formula, event time, and the object for which the threshold was exceeded. The files are stored in NetAct for a configurable number of days before being deleted automatically.

4.12.4.2

Architecture of performance management The PM architecture provides all the necessary functions for monitoring the statistics data, for example, the collected performance measurement counters. NetAct offers performance management applications for a centralized performance management. Figure 38: LTE performance management architectureshows the basic functions to support performance measurements. Figure 38

DN0978045Issue:04A

LTE performance management architecture

©2016Nokia

283



Data Export

NetAct - NM

Computing Platform

Application NB

NetAct - EM

Administration of Measurements

PM Application

Data Processing

Network PM Data

Data Collection

SW Platform

Mediation and Data Processing

Cluster PM Data Cluster PM Data

iOMS

BTSOM network element network element

Aggregated Data

PmC

Local PM Data Collection Local PM Data Collection PM Data PM Data Collection Local PM Data

Raw Data Data

PM Data

Control / Administration

4.12.4.2.1

Site Manager

PM Ll Application

eNB PMProvider

Architectural roles This section describes the responsibilities and the high level functions of performance management. NetAct •

•

Administration of Measurements (AoM) is the central application for managing the performance measurements. AoM has a Graphical User Interface (GUI) that allows the end user to configure the performance measurements (setting and retrieval). The Reporter application provides adatabase for a long-term storage ofperformance measurement data received by the mediator (iOMS). The Reporter provides configurable performance report generation (for example, for KPIs and thresholdbased PM alarms). The Reporter has a GUI that allows the end-user to present the performance measurement data and reports. The Reporter provides an export interface for the performance measurement data and reports.

iOMS

The iOMS acts as an O&M mediator. It is responsible for collecting the PM report files from the distributed NEs, concentrating them into larger files, buffering in a temporary file storage, and forwarding to a NetAct PM database for a central storage of PM data. PmC

The local Performance measurement Control (PmC) is responsible for controlling the different local Performance Measurement Provider functions (PMProvider). The PM Providers produce the measurement data in the form of counters. The local PmC merges all the collected measurement data during a measurement interval into the PM result files and stores them locally.

284

©2016Nokia

DN0978045Issue:04A



In a defined interval (reporting period), the PmC generates a PM report file containing all locally stored PM result files of the last reporting interval and sends a notification to the iOMS for the PM report file upload. EM/NM

The NE performance measurements can be managed with Element Manager (EM) applications (for Flexi LTE BTS it is the BTS Site Manager) or with central NetAct applications. When a PM data result file has been created by the NE, a message including the file name is sent to each subscribed (connected) element manager. Upon receiving this message from the NE, the element manager transfers the file with the secure file transfer mechanism. For an automatic PM report file upload, this procedure is executed automatically for each reporting interval. Performance Management Architecture of performance management Issue:

4.12.5 4.12.5.1


4.12.5.2


4.12.5.3

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

4.12.5.4


4.12.6


Sales information

B S W /A S W

BSW

4.12.7 4.12.7.1

Li c e n se c o n t r ol i n n e tw o rk element

-


-

User interface Alarms for LTE657: Performance Management There are no alarms related to this feature.

4.12.7.2

Measurements and counters for LTE657: Performance Management There are no measurements and counters related to this feature.

DN0978045Issue:04A

©2016Nokia

285


4.12.7.3


Key performance indicators for LTE657: Performance Management There are no key performance indicators related to this feature.

4.12.7.4

Parameters for LTE657: Performance Management There are no new parameters related to this feature.

4.13 LTE663: GPS Location and Time Retrieval 4.13.1

Introduction to the feature The LTE663: GPS Location and Time Retrievalfeature introduces an interface to a Global Positioning System (GPS) module to fetch geographical coordinates and time.

4.13.2

Benefits With this feature the accurate GPS time is fetched.

4.13.3 4.13.3.1




Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.13.3.2

-


4.13.4

Functional description This feature introduces the interface to a GPS module to fetch geographical coordinates and time. If a fixed mounted GPS module is available on site, the eNB can be configured to use the control interface (SW management interface) to access the GPS information: • •

286

to fetch the GPS coordinates in terms oflongitude, latitude, andaltitude values to fetch the accurate GPS time

©2016Nokia

DN0978045Issue:04A



The GPS time is calculated at UTC time. The time information may be used to set or synchronize the BTS internal clocks (time of day, not intended to be used as a frequency reference for oscillators), which in turn provide time stamps for messages, alarms, notifications and performance measurement files, trace records, and log files.

g

Note: The configuration of a time zone can not be derived via GPS and is done during

site commissioning. This feature requires feature LTE80: GPS synchronizationor feature LTE1629: Integrated GPS Synchronization for the Flexi Zone Micro (FZM) .

4.13.5 4.13.5.1

System impact Interdepencies between features There are no interdependencies between this and any other feature.

4.13.5.2


4.13.5.3


4.13.5.4


4.13.6 4.13.6.1

User interface Alarms for LTE663: GPS Location and Time Retrieval There are no alarms related to this feature.

4.13.6.2

Measurements and counters for LTE663: GPS Location and Time Retrieval There are no measurements and counters related to this feature.

4.13.6.3

Key performance indicators for LTE663: GPS Location and Time Retrieval There are no key performance indicators related to this feature.

4.13.6.4

Parameters for LTE663: GPS Location and Time Retrieval There are no new parameters related to this feature.

DN0978045Issue:04A

©2016Nokia

287


4.13.7



Sales information

BSW /ASW

BSW


-


-

4.14 LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA) 4.14.1 4.14.1.1

Introduction to the feature LTE665: LTE Certificate Management The eNB certificate management feature provides handling of the private and public key as well as digital certificates in X.509v3 format. Keys and certificates are used for mutual authentication between IPsec and/or TLS protocol peers. This feature represents the eNB local/peer part of the Nokia identity management system (IDM) or a 3rd party PKI solution.

4.14.1.2

LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) To enable public key certification based authentication and authorization within the access network and management network, provisioning of a public key infrastructure on both Nokia as vendor and the operator side is a prerequisite. TheNokia identity management solution integrates theNokia PKI manufacturing and delivery chain with the operators PKI infrastructure.

4.14.2 4.14.2.1

Benefits LTE665: LTE Certificate Management The certificate management feature provides centralized and scalable key and certificate management for operator networks. It enables: • •

4.14.2.2

Secure communication based on a public key infrastructure Mutual authentication based on digital public certificates

LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) Public key and certificate management provide a centralized and full scalable identity and security management for the network nodes and transmission for the eNB.

288

©2016Nokia

DN0978045Issue:04A


4.14.3 4.14.3.1




Network element


Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

4.14.3.2

OSS5.3CD1


4.14.4 4.14.4.1

Functional description for certificate management LTE665: LTE Certificate Management The certificate management is implemented by the system features: The certificate management feature is needed for enrollments, update, and revocation of operator certificates when public operator certificates are used in the network. This feature comprises the following characteristics:

•

factory provisioning of vendor keys and certificate remote operator certificate enrollment local operator certificate enrollment vendor certificate authentication PSK/RefNum authentication eNB self-signed certificate authentication

• •

certificate revocation certificate renewal/key update

• • • • •

Factory provisioning of vendor keys and certificate

To comply with the Nokia secure device identity (SDI) concept and the 3GPP TS 33.310 Authentication Framework for initial certificate enrollment, the manufacturing process of an eNB is extended by key pair and certificate creation steps:

DN0978045Issue:04A

©2016Nokia

289



1. When a new eNB is manufactured at a certain point in the process queue, a unique public and private key is generated andstored within the eNB. The public key portion is given to the factory RA/CA for signing. 2. The Nokia factory certification authority (Factory-CA) together with the factory registration authority (Factory-RA) creates and signs a Nokia device certificate for each individual eNB, where the subject of the certificate is linked to the eNB serial number.

g

Note: The Nokia Factory CA is a subordinate CA of the Nokia Root CA.

3. The public Nokia device certificate is stored together with the factory CA certificate in a Nokia repository, and in the FTM inside eNB, before modules are shipped to warehouses and/or customers. This device certificate or vendor certificate is used to authenticate against the operator RA/CA during automated enrolment (compliant with 3GPP TS 33.310). 4. When a new eNB is delivered to the operator, the operator also gets theserial numbers of the shipped modules on request via theNokia Web interface (NOLS). The eNB’s serial number can be used as a white list to verify or cross-check if the eNB belongs to the hardware that hasbeen ordered, by comparing the serial number of the certificate from the eNB with the order deliveries. Nokia provides with the Identity Management Server (IDM) a complete PKI solution which is able to execute this serial number check automatically. Certificate enrollment is done for each eNB . The network element generates a key pair and sends the initialization request to the certification authority. This procedure includes the registration, the initialization, and the certification processes. After this, the certificate is delivered to the network element and is published to the CA’s certificate repository. Supported certificates

The eNB support the following certificates in the x.509v3 format:

•

PEM: used for certificate installation using BTS Site Manager PKCS#12: used for certificate installation using BTS Site Manager. This formati is

•

used for transferring certificate together with private key stored in one file. The BTS Site Manager does not support PKCS#12 file without private key in it or containing more than one chain of trust. DER: used for transferring certificates over certificate management protocol ( CMP)

•

The same certificate is used for both IPSec and Transport Layer Security ProtocolTLS ( ) authentication needs. Remote operator certificate enrollment

When a newly deployed eNB connects to the transport network, it is provided with the address of the operator's IDM server (as a vendor/operator-specific attribute during plugand-play from the server server (RA/CA) asDHCP the first point or of manually contact. configured) or its third-party PKI security The eNB creates a new key pair and establishes a CMP connection to get the public key portion signed by a new operator device certificate for this eNB and to download the operator's public signing CA certificate as trust anchor. If a Nokia IDM server is in place, the server knows the eNB already (because its serial number has already been received and stored) and the server can verify optionally if the eNB belongs to the pool of ordered devices.

290

©2016Nokia

DN0978045Issue:04A



Once the eNB knows the final operator node certificate to be used, it can establish secure connections to all of its communication partners via IPsec or TLS with the correct operator node identity, for example, to connect with NetAct to continue with autoconfiguration. Local certificate enrollment

Local certificate enrollment is used if the operator runs no online PKI infrastructure. The operator certificates and trust anchors are then introduced by a manual procedure into the secure key storage of the eNB with the BTS Site Manager. A similar procedure can be used to inject other certificates like the trust anchors. eNB authentication

During eNB roll-out and in exceptional cases, no valid operator certificate may be available within the eNB. The eNB then tries the following alternatives to authenticate against the operator’s CA or certificate server to obtain the operator certificate: 1. If a PSK/RefNum is configured, the eNB tries to authenticate using these credentials. 2. If PSK/RefNum is not configured, and a Nokia device certificate (vendor certificate) is available, the eNB tries to authenticate with its vendor certificate. 3. If neither a PSK/RefNum nor a Nokia vendor certificate is available, the eNB uses a self-signed certificate. In case of a factory reset, the operator certificate and the operator CA certificate are removed from the network element and if a vendor certificate is available it is used to authenticate the network element against the operator’s CA to obtain a new operator certificate. PSK/RefNum authentication

The PSK and RefNum can be configured by the BTS Site Manager or via NetAct (NetAct mass update tool). The PSK/RefNum is used only if the PSK and RefNum values are different that the default values. The operator needs to activate an exception policy for the CA to allow acceptance of PSK/RefNum. eNB self-signed certificate

A default self-signed certificate is available for exceptional cases if no Nokia device certificate (vendor certificate), no operator device certificate, or PSK/RefNum is available in the eNB to authenticate the CMP connection to the operator's IDM system or certificate authority. The operator needs to activate an exception policy for the CA to allow acceptance of the self-signed certificate. Operator certificate revocation

Certificate revocation is done when properties of end entities change. Such changes are: private key compromise, change in affiliation, and name change. When certificates are identified for revocation, they are listed in the certificate revocation list ( CRL) in the operator's IDM/CA. The CRL is downloaded from the CRL repository to the eNB either periodically, or command-base triggered from NetAct.

DN0978045Issue:04A

©2016Nokia

291



The eNB fetches the CRL from a CLR distribution point. The reference to CRL distribution point is taken from eNB own operator certificate or CA certificate. With LTE482: DNS Support for Certificate revocationfeature, this reference can be either an IP address or fully qualified domain name FQDN ( ). Operator certificate renewal/key update

Operator certificate renewal in the eNB and iOMS is done automatically before a certificate’s lifetime ends and needs to be renewed for another period of time. Simultaneously, a key update is made to the still-valid current key pair. If the new certificate is received, the current key pair is substituted by the new one. This functionality is triggered from the eNB autonomously according to control timer settings or command base triggered from NetAct. The update of the operator certificate for eNB can be also done by triggering CMP initialization procedure using BTS Site Manager.

g

Note: Before triggering CMP initialization procedure of updating eNB operator

certificate, make sure the CMP/CA server policy is configured to allow a repeating CMP initialization requests for a certain eNB . When CMP initialization procedure finishes (triggered either automatically or manually), the currently established IPsec connections are terminated and re-established using new certificates. This causes temporary interruption in the eNB operation. The CMP initialization procedure does not affect secure connections that use TLS protocol. Operator certification authority (CA) certificate renewal/key update

The operator certification authority ( CA) certificate is usually valid for 10-20 years. If the operator CA certificate lifetime is going to expire, if there has been a leakage of the certificate, or a major change in the PKI hierarchy of the customer network has taken place the operator CA certificate must be renewed. The update of the operator CA certificate is done via manual procedure using the CMP initialization procedure. As with the operator certificate update, the CMP/CA server policy must be configured to allow a repeating CMP initialization requests for a certain eNB. The currently established IPsec connections are terminated and re-established using new certificates. For the new IPsec connections to work, the operator CA certificate must be updated also in all peer network elements (for example, security gateways, iOMS). It is recommended to update the operator CA certificate in all network elements in the order specified in LTE RAN O&M Security. For more information of the operator CA certificate update, see Manual operator CA certificate update, in Operating task related to LTE RAN O&M Security. Certificate management protocol (CMP)

CMPv2 according to RFC4210 is supported. HTTP 1.1 according to RFC2585 is used as the transport protocol for the CMP. The following CMP messages are supported: • • • • • •

292

ir (initialization request) ip (initialization response) kur (key update request) kup (key update response) pkiconf (PKI confirmation) certConf (certificate confirm)

©2016Nokia

DN0978045Issue:04A



Vendor certificates are provided in the CMP message ExtraCerts field.

4.14.4.2

LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) To enable the public-key-certification-based authentication and authorization within the access network and management network, provisioning of a public key infrastructure on both the Nokia side as vendor, and on the operator side is a prerequisite. TheNokia secure device identity (SDI) concept links the Nokia PKI manufacturing and delivery chain with the operator’s PKI infrastructure. On the operator side, theNokia identity management (IDM) solution provides all components to realize an operator PKI. This solution provides the required infrastructure including computer systems and applications for handling certificate requests and aligned processes for certificate implementation. This feature is licensed (trust based license). SDI concept on Nokia side

To support the Nokia IDM or another third party PKI, the manufacturing process of an eNB is extended by the introduction of aNokia factory certification authority (FactoryCA) and factory registration authority (Factory-RA), which creates and signs a vendor certificate for each individual eNB. The private and public key pairs are created during the eNB system module assembly. The Nokia factory-CA together with the factory-RA creates and signs a Nokia vendor device certificate for each individual eNB. IDM solution on operator side

On the operator side, the IDM provides the identity management, which comprises: •

a registration and certification authority for – –

• •

creation and management of the public operator device certificates additional authorizationmodules for automated checks of Nokia public device certificates against deployed eNB hardware

deployment of operator device certificates to the eNB renewal and revocation of operator certificates, ifnecessary.

The infrastructure is multi-vendor capable as long as other RA/CA products support the certificate exchange procedures and the related protocols, such as the certificate management protocol (CMPv2) with the required protocol options. The CMPv2 protocol is used to derive the operator certificate from the operator's IDM or third party CA. Identity management server solution

The identity management server solution consists of the following components: •

DN0978045Issue:04A

eNB In the initial enrollment phase, which uses CMP, the eNB vendor certificate, the serial number, and a newly created public key are sent to the operator CA/RA. The operator CA/RA authenticates the eNB, creates a new operator certificate, signs the new operator certificate with the operator CA certificate, and sends it back to the network element.

©2016Nokia

293


g


Note: In the initial enrollment the vendor certificate is used to authenticate the request.

When the eNB updates the operator certificate, it uses the already-enrolled operator certificate for authentication. •

DHCP server (to support automated certificate enrolment if eNB plug and play is

applied) The DHCP server is the operator’s normal DHCP server (used for eNB plug and play rollout), which delivers IP addresses to eNBs. As the eNBs is not aware of the IP

•

address of the operator’s IDM server, it receives thebut address theconfigurable initial DHCPto exchange. A standard DHCP server can be used it mustinbe support the configuration of vendor specific attributes. IDM server The IDM server represents the Nokia RA/CA solution to manage and deliver operator certificates to the eNBs in the operator network. The IDM server is owned and run by the operator. The main components of the identity management server are: –

–

–

–

–

security server The security server is the front-end of the operator PKI terminating the CMP protocol towards the eNB. It may host the RA function, too, and is often located in a demilitarized zone (DMZ), separated from the CA by a firewall. The security server is used by the eNB to enroll and renew the operator certificate. The IP address of the security server is passed to the eNB during the plug-and-play DHCP sequence or by manual configuration. operator CA The operator CA signs the eNB public RSA key received from the security server, creates the operator certificate, returns them to the requestor and stores the public certificates in repositories. serial number database (optional) The Nokia serial number database is an abstract entity containing a list of all NE serial numbers that the operator has purchased. certificate delivery software module (optional) The Nokia specific certificate delivery software module is run every time the customer orders a set of transport modules. The software receives as input a list of serial numbers of the delivered modules. It validates (compares) the serial number of a new enrolled eNB asking for an operator certificate with the serial numbers received from the delivery chain. If the entries match, the eNB is authorized to receive an operator certificate. customized RA (optional) The customized RA delivers each certificate signing request to the operator CA for signing. There have to be pre-set trust relations between the CA and the RA.

Deployment of operator certificates without IDM/online PKI

If the operator runs no online IDM or similar PKI infrastructure, then it is possible to introduce the operator certificates by a manual procedure into the secure key storage of the eNB either locally or remotely with the BTS Site Manager. Factory trust anchor

The factory CA belongs to the PKI of Nokia. The factory CA certificate itself is signed by the Nokia Root CA. These factory trust anchors are required by the identity management server (or another third party RA/CA used by the operator). During the initial operator

294

©2016Nokia

DN0978045Issue:04A



certificate enrollment, the CA validates and authenticates the CMP Initialization message using the factory CA signed vendor certificate. For this validation, the CA needs the Nokia trust anchors. The factory trust anchors (Nokia Root CA certificate and Nokia factory CA certificate) are delivered to the operator via the Nokia Web interface (NOLS). Operator trust anchor

The operator trust-anchor is protected by a secure key and secure file storage mechanism in the eNB. The eNB authenticates itself to a peer network element using its operator certificate, which is signed by the operator trust anchor. This trust anchor is used by the network elements to validate the peer certificate when executing TLS setup. The trust anchor is delivered by the identity management server to the network element during the initial operator certificate enrollment in the CMP initialization response message. Operator trust anchor and operator/vendor certificate installation

The eNB supports: • • •

4.14.5

operator trust anchor via CMP operator certificate via CMP transfer from BTS Site Manager (manual deployment with BTS Site Manager).

System impacts LTE665: LTE Certificate Managementfeature is related to following features:

4.14.6

•

LTE150: LTE OAM Transport Layer Security (TLS) Support

• •

LTE689: LTE IPsec Support

LTE154: SON LTE BTS Auto Connectivity

Sales information LTE665: LTE Certificate Managementand LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) are both additional software features and

their license is trust-based. The features are active for the whole eNB. They are indicated as active if the cmpServerIpAddress parameter is not empty.

4.14.7 4.14.7.1

User interface Parameters for LTE665: LTE Certificate Management Table 158: Parameters for LTE665: LTE Certificate Managementshows the parameters related to feature LTE665 LTE Certificate Management. All parameters are located in object CERTH.

DN0978045Issue:04A

©2016Nokia

295


Table 158


Parameters for LTE665: LTE Certificate Management

Name

Description

Range

btsCertificateUpdateTimNumber of days before a BTS certificate e expires and a CMP update sequence is

triggered autonomously from the BTS. caCertificateUpdateTim Number of days before a CA or trust e anchor certificate expires and a CMP

Name of CMP server

certhId

Certificate handler configuration

1...4999 365 days days, step 1 day 1...4999 1825 days, step 1 days day

update sequence is triggered autonomously from the BTS. caSubjectName

Default value

0...128 characters 1...1, step 1

1

Value is always 1, not modifiable cmpServerIpAddress

IP address of CMP server, entered in dotted decimal format

cmpServerPort

Port number for addressing CMP server

crlUpdatePeriod

Period for executing a periodical update of CRL

7...15 characters 1...65535, step 1 0...8760 hours, step 1 hour

Value 0 means no periodical update

4.14.7.2

Alarms for LTE665: LTE Certificate Management Table 159

Alarm number

61074

61510

296

0

Alarms for LTE665: LTE certificate management

Alarm name

CRL Update failure

NO_CERTIFICATE

Condition

This alarm is raised if the BTS cannot update the Certificate Revocation List (CRL) for one of the following reasons: •

the LDAP binding fails

• •

the LDAP search is empty (no CRLone found) LDAP search contains more than entry/ the the CRL signature validation fails

•

the CRL file exceeds the BTS storage limit

•

the BTS certificate is part of the CRL

A requested certificate could not be retrieved from the Certificate Authority (CA).

©2016Nokia

DN0978045Issue:04A


Table 159

Alarm number

7665


Alarms for LTE665: LTE certificate management (Cont.)

Alarm name


Condition

This alarm is raised if any of the below BTS faults occurs: •

•

CRL Update failure (61074)

The fault is reported when: –

the LDAP binding fails

– –

the LDAP search is empty (no CRL found) / the LDAP search contains more than one entry the CRL signature validation fails

–

the CRL file exceeds the BTS storage limit

–

the BTS certificate is part of the CRL

Automatic BTS Operator Certificate retrieval unsuccessful (61510)

The fault is reported when the requested certificate could not be retrieved from the Certificate Authority (CA).

4.14.8

Activating and configuring the feature For an activation instruction refer to Feature Activation Document.

4.15 LTE666: LTE User Account Management 4.15.1

Introduction to the feature This feature enables centralized user account management for the eNB and integrated operation and mediation function from NetAct. It also provides a mass updating function of local user passwords for eNB.

4.15.2

Benefits Enhanced risk management and OPEX savings are achieved because of centralized LTE radio access system security and a fast network wide management of local eNB user accounts.

4.15.3

DN0978045Issue:04A

Requirements

©2016Nokia

297


4.15.3.1


Software Requirements Table 160


Network element


Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

4.15.3.2

OSS5.2CD3

Hardware Requirements This feature does not require any new or additional hardware.

4.15.4

Functional description for user security Centralized user accounts of network elements are managed with NetAct. (For more information, see NetAct documentation: Centralized user authentication & authorization). It allows users to log into different network elements within the customer network with the same user ID and password. During login, users are authenticated and authorized using a local user repository or a centralized authentication server. If local authentication fails, the centralized authentication is attempted. User authorization profiles can be customized according to different roles. Roles are based on different types of usage needs and can be defined by the network administrator.

4.15.4.1

Authentication and authorization Centralized user authentication and authorizationis done by the authentication server,

which is located in NetAct, and by LDAP client software located in each network element. The operating mode of LDAP interface between the server and the client is configurable (secure/insecure mode). Network elements have their own accounts that provide communication with the centralized user repository. The iOMS have two types of accounts:registration account and NE account. The registration accountis used only for the registration purposes, when the iOMS connects to theNWI3 registration service in NetAct and further to the centralized user repository server (LDAP server) for the first time. After registration of a new network element, theregistration account is disabled and only theNE account is in use. If the registration account of an iOMS could not be used, theNE account is used as a back-up account for registering the iOMS in the CUAA repository.

298

©2016Nokia

DN0978045Issue:04A



NE accounts provide communication with the centralized user repository, enable

attachment of the role data for a particular user when the user logs into the system, and it is the only account type that is used for obtaining authentication and authorization data. Authentication with the local user repository can be used if there is no connection to the centralized authentication server or during the network element commissioning. The network element user authentication order is the first local user repository, then central user repository.

4.15.4.2

Disabling user accounts in NetAct It is possible to disable centralized end user accounts for each combination of network element type and version. If centralized end user accounts are disabled, NetAct uses the network element local account to connect to the network element instead of the centralized account. Internally, NetAct always uses the centralized authentication and authorization repository. Network elements can continue using their network element account even though centralized end user accounts are disabled in NetAct for that network element type and version. It is also possible to disable network element accounts.

4.15.4.3

User management With centralized user accounts and permission management functionality the network administrator can set up user accounts and define different access classes for different user groups and network elements. The eNB supports only one access class. A user that is connected and successfully authenticated to the eNB can perform any available action. It is possible to define and set multiple profiles for one centralized user account. In this case, access rights for the user are the combination of those profiles. Management operations using local user account can be performed in addition especially when the centralized management system is not available.

4.15.4.3.1

Mass updating of eNB local user accounts With the mass change functionality implemented in NetAct, it is possible to change eNB local user accounts. The eNB local user accounts can be changed for multiple network elements at the same time. To limit simultaneous NWI3 session openings to the same iOMS, the NetAct mass updating tool has been enhanced to send new user account and password information in a list mode. This means that a single message can contain several eNBs to which the change operation is targeted. The iOMS mediation function disassembles the target network element id list and forwards the separate messages individually to each eNB. To avoid the overload situation in the iOMS, NetAct will not send any new mass update requests towards the same iOMS, and the iOMS will not accept any new requests until the previous mass update request handling is complete.

DN0978045Issue:04A

©2016Nokia

299


4.15.4.4


Audit trail The Audit Trail application is additional NetAct software. With this application centralized user auditing is enabled. LTE667 LTE User Event Log Managementfeature is available from iOMS and eNB. Log file upload from the eNB and iOMS to NetAct is usually a scheduled event. Both eNB and iOMS can also trigger the upload by sending thelog file full event to NetAct. Files can be traced and processed with NetAct tools after the successful upload. LTE user event log management

User event log management is implemented for the iOMS and the eNB (where a user can establish interactive sessions). Both support centralized event log management. The iOMS collects the event logs from the eNB and transfers the logs to the NetAct. The following security-related user actions are collected in the user event log: • • • •

unsuccessful login attempts successful logins logouts configuration changes

Log file upload may be initiated by: • •

NetAct operator: Theoperator manually enters the referring NetAct command. NetAct scheduler: Theoperator schedules the upload periodically.

•

amaximum ‘log file full’ event:before TheiOMS andinitiates the eNBthe initiate theagain. upload if alog file reaches capacity NetAct upload To limit simultaneous NWI3 session openings to the same iOMS, the NetAct Audit Trail application sends eNB log file requests in a list mode. This means that in the log collection sequences a single message can contain several eNBs to which the request is targeted. The iOMS mediation function disassembles the target eNB ID list and forwards the messages to each individual eNBs. The eNB compresses the log files before upload. The eNB log files are transferred directly to NetAct. The eNB log files are first transferred to the iOMS and then sent to the NetAct. During log file upload, the new log events are buffered and stored afterwards in the new log file. After successful upload to NetAct, the log files are deleted in iOMS and eNB.

g

Note: Because of the eNB two-step file transfer mode via the iOMS, the TLS

configuration must be consistent in all network elements taking part in the file transfer. If TLS is to be enabled, it must be enabled between the eNB and the iOMS, and also between the iOMS and the NetAct. The configuration in which only one connection is secured with TLS (either between the eNB and the iOMS or between the iOMS and the NetAct) blocks the file transfer. If a log file has reached its maximum size and is not uploaded to NetAct, the log file is overwritten and the operator is informed by a message in the log file.

300

©2016Nokia

DN0978045Issue:04A


4.15.5


System impacts This feature has no impact on system performance or capacity.

4.15.6

Sales information The LTE User Account Managementfeature is an additional software feature.

4.15.7 4.15.7.1

User interface Parameters for LTE666: LTE User Account Management Table 161: Parameters for LTE666: LTE User Account Managementshows the parameters related to LTE666 LTE User Account Management. All parameters are located in object AMGR. Table 161

Parameters for LTE666: LTE User Account Management

Name

Description

Range

This parameter identifies the account manager

amgrID

Default value

1...1, step 1

Value is always 1, not modifiable primaryLdapPort

Port number of the primary LDAP server

primaryLdapServer

IP address of the primary LDAP server, entered in dotted decimal format

1...65535, step 1

389

7..15 characters

Table 162: Parameters for LTE666: LTE User Account Management - BTSSM shows the waiting time for the automatic disconnect parameter related to LTE666. It is set in the BTSSM application and is located inFile ► Preferences. Table 162

Parameters for LTE666: LTE User Account Management - BTSSM

Description

DN0978045Issue:04A

Range

item Automatic disconnection from BTS site , check

10..120 minutes,

Disconnect if no user activity

step 1

©2016Nokia

Default value

30 minutes

301


4.15.7.2


Alarms for LTE666: LTE User Account Management Table 163

Alarms for LTE666: LTE User Account Management

Alarm number

Alarm name

Condition

61500

Five failed logins to FTM due to wrong user name or password

Five consecutive failed login attempts to the FTM have been performed.

70025

POSSIBLE SECURITY THREAT IN NETWORK ELEMENT

Five (default value) consecutive failed login attempts to iOMS

7665


This alarm is raised if the below BTS fault occurs: •

Five failed logins to FTM due to wrong user name or password(61500)

The fault is reported when five consecutive failed login attempts to the FTM have been performed.

4.15.8

Activating and configuring the feature For an activation instruction refer to Feature Activation Document

4.16 LTE679: LTE Local User Account Management 4.16.1

Introduction to the feature This feature introduces a local user account management for the eNB.

4.16.2

Benefits Enhanced risk management is achieved by improved access security.

4.16.3 4.16.3.1



Network element

302


Systemrelease

RL09

eNodeB

LBTS0.5

©2016Nokia

DN0978045Issue:04A



Table 164


Network element


MME

–

SAE GW

–

UE

–

NetAct

4.16.3.2

–


4.16.4

Functional description for LTE Local User Account Management The BTS Site Manager access to an eNB is protected with a configurable password. The user authentication is done locally in the eNB. The user can change the local credentials (user password and account name) with the BTS Site Manager.

4.16.5

System impacts The feature has no additional impacts on the system.

4.16.6

Sales information The LTE679: LTE Local User Account Managementfeature is a basic software feature.

4.16.7 4.16.7.1

User interface Parameters for LTE679: LTE Local User Account Management Table 165: Parameters for LTE679: LTE Local User Account Management shows the parameters related to LTE679 LTE Local User Account Management. Table 165

Parameters for LTE679: LTE Local User Account Management

Name

DN0978045Issue:04A

Length

User account name

4-16 characters

User account password

8-128 characters

©2016Nokia

303


4.16.8


Activating the feature This feature does not require activation.

4.17 LTE689: LTE IPsec Support 4.17.1

Introduction to the feature The IPsec support enables secure eNB control and bulk data communication between eNBs and between eNBs and core nodes by utilizing secure transport and application protocols. IPsec supports the separation between different types of traffic, like control plane traffic and user plane traffic from management traffic, by dedicated transport tunnels. The security of eNB control, user, and management plane interfaces is increased by providing encryption, integrity protection and communication peer authentication with IPsec according RFC 4301. It is possible to enable / disable IPsec per connection, for example per neighbor eNB, or per core security gateway and to configure each connection independently in terms of security settings for each remote IPsec peer. The supported IPsec capabilities follow 3GPP TS 33.210 for interworking purposes and further appliance rules given by TS 33.401 and TR 33.821. Since IPsec standards include a high number of selectable security parameters options, 3GPP has recommended to cut down the number of these options in order to guarantee interoperability between different security domains.

4.17.2

Benefits Enhanced risk management is achieved because of improved RAN system security. It is not necessary to invest into any additional external HW to use IPsec support.

4.17.3 4.17.3.1



Network element

Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

304


–

©2016Nokia

DN0978045Issue:04A



Table 166


Network element


NetAct

4.17.3.2

OSS5.2CD3

Hardware requirements Table 167

Hardware requirements for different network elements

Network element

MME

Required hardware

-

eNodeB UE

4.17.4

-

Functional description for IPsec Support Supported IPsec capabilities

summarizes the supported IPsec capabilities: Table 168

IPsec capabilities

Services

Data integrity protection, origin authentication and anti-replay protection, confidentiality

Protocol

ESP (RFC 4303)

IPsec mode

Tunnel mode

Encryption/Ciphering

DN0978045Issue:04A

•

AES-128-CBC

•

3DES-192-CBC

•

NULL

Integrity protection algorithm

HMAC-SHA-1-96

Identification

•

IP addresses

• •

Fully Qualified Domain Names (FQDN) distinguished name ID_DER_ASN1_DN

Authentication

Digital certificates in X.509v3 format

Key exchange

•

Dual stack IKEv1 and IKEv2

•

Diffie-Hellman: Group 2 (1024-bit MODP)

•

Diffie-Hellman: Group 14 (2048-bit MODP)

©2016Nokia

305



Suggestions for IPsec configuration

IPsec implementation is optimized to provide best throughput and strongest security level when using ESP encapsulation with AES-128-CBC encryption algorithm along with the HMAC-SHA1-96 integrity protection algorithm. IPsec for traffic separation

Control plane traffic, user plane traffic, and management traffic can be separated with separate IPsec tunnels from each other and from any other operator's traffic if any part of the transport network is shared. The separation also ensures that flooding attacks at the control / signaling network will have no impact to the separated data paths. For traffic separation in LTE IPSecVPN tunnels as per 3GPP NDS/IP are supported. Parallel usage of IPsec and other secure transport protocols

Depending on the transport network configuration and the number of network management locations and applications to be addressed, IPsec (one or more dedicated connections) alone or together with other secure transport protocols can be used and configured in parallel. Properties of LTE689: IPsec Support

The IPsec feature is optional. If the license is not available, the eNB acts like IPsec is disabled with an active license in place. The eNB supports IPsec functions on the interfaces to peer-entities.

4.17.4.1

Transport security This section covers the transport security functions for the following logical interfaces: • •

• • •

S1-U: User data transport (U-plane) betweeneNB and S-GW (GTP-U tunneling) X2-U: User data transport (U-plane) betweeneNB nodes during handover ( GTP-U tunneling) S1-MME: Signaling transport (C-plane) between eNB and MME (S1-AP protocol) X2-C: Signaling transport (C-plane) between eNB nodes (X2-AP protocol) O&M i/f: Transport of O&M data (M-plane) between eNBand O&M System

IETF “Security Architecture for the Internet Protocol” including IPsec and IKE is used to provide transport security on the eNB for the above mentioned interfaces. Figure 39: Transport protocol stack overviewgives on overview on the eNB protocol stacks and the embedded IPsec layer. Figure 39

Transport protocol stack overview S1-U, X2-U

S1-MME, X2-C

O&M i/f

GTP-U

S1-AP / X2-AP

Mgmt Appl.

UDP

SCTP

IP/IPsec

Transport

306

IP/IPsec

UDP/TCP IP/IPsec

Ethernet Layer 2

Ethernet Layer 2

Ethernet Layer 2

Ethernet Layer 1

Ethernet Layer 1

Ethernet Layer 1

©2016Nokia

DN0978045Issue:04A



At eNB side, the IPsec function is integrated into the eNB. Therefore, the eNB represents a security domain of its own and can act as SEG according to 3GPP TS 33.210

4.17.5

System impacts The LTE689: IPsec Supportfeature is related to following features: • •

LTE665: LTE certificate management LTE875: Different IP addresses for U/C/M/S-plane

FTLB or FTIB are required for this feature.

4.17.6


Sales information

BSW/ASW

License control in network element License control attributes

ASW

pool licence

-

The feature is active for the whole eNB. It is indicated as active if the ipSecEnabled parameter is true.

4.17.7 4.17.7.1

User interface Parameters for LTE689: LTE IPsec Support Table 170: Parameters for LTE689: LTE IPsec Supportshows the parameters related to feature LTE689 LTE IPsec Support. All parameters are located in object IPSECC. Table 170

Parameters for LTE689: LTE IPsec Support

Name ipSecEnabled

ipSeccId

Description

Activation (TRUE) / deactivation (FALSE) of IPsec Identification of IPsec configuration

Range

FALSE, TRUE

1...1, step 1

Default value

FALSE

1

Value is always 1, not modifiable securityPolicies L ist of security policies

antiReplayEnable d

DN0978045Issue:04A

Activation (TRUE) / deactivation (FALSE) of anti-replay

©2016Nokia

Structure , comprising belowmentioned components FALSE, TRUE

TRUE

307


Table 170


Parameters for LTE689: LTE IPsec Support (Cont.)

Name

Description

Range

Default value

antiReplayWindo wSize

Size of anti-replay window, only relevant, if antiReplayEnabled parameter is TRUE

64, 128, 256

256

authentication

Determination, if a pre shared key or a certificate is used

certificate(1), psk(2) certificate

In this release only certificate is used dpddelay

dpdtimeout

Time delay with no messages received from remote peer node – at expiry DPD alive check message is sent

10…360 sec,

10 sec

Time delay with no messages received from peer node on DPD alive check messages – at expiry DPD alarm is raised

60…3600 sec, step 1 sec

step 1 sec

encryptionMethod ESP encryption algorithm

IKEencryptionMet hod

IKEprotocol ipSecStatus

120 sec

NULL, AES_128_CBC, AES_128_CBC_OR_3DES_192_C 3DES_192_CBC, BC (default value) means: AES_128_CBC_OR _3DES_192_CBC 1. AES_128_CBC tried first (priority 1: 2. 3DES_192_CBC tried second AES_128_CBC, priority 2: 3DES_192_CBC)

AES_128_CB C_OR_3DES_ 192_CBC(prior

IKE encryption algorithm AES_128_CBC, 3DES_192_CBC, AES_128_CBC_OR_3DES_192_C AES_128_CBC_OR BC (default value) means: _3DES_192_CBC(p riority 1: 1. AES_128_CBC tried first AES_128_CBC, 2. 3DES_192_CBC tried second priority 2: 3DES_192_CBC)

AES_128_CB C_OR_3DES_ 192_CBC(prior ity 1: AES_128_CB C, priority 2: 3DES_192_C BC)

IKE protocol version

IKE_V1, IKE_V2

Treatment of traffic data packets matching selection criteria of the IPsec the policy.

ity 1: AES_128_CB C, priority 2: 3DES_192_C BC)

IKE_V2

PROTECT,

BYPASS

DISCARD, BYPASS

PROTECT: packet is subject to the security associations settings DISCARD: packet is discarded without any further action or notification, that is it is not passed to its destination

308

©2016Nokia

DN0978045Issue:04A



Table 170


Name

Description

Range

Default value

BYPASS: packet is delivered to its destination without any further IPsec related processing localIpAddress

Local IP address of the data traffic packet, entered in dotted decimal format

7...15 characters

It can contain a single IP address or the IP address of a subnet. Value 0.0.0.0 means that all IP addresses are allowed localIpPort

Port number of local IP address If value -1 is configured, the IPsec policy is valid for all ports of local IP address

localNetmask

Netmask of local IP address

localTunnelEndpoi Local endpoint of IPsec tunnel, IP nt address entered in dotted decimal

-1 ... 65535,

-1

step 1

7...15 characters 7...15 characters

format remoteIpAddress

Remote IP address of the data traffic packet, entered in dotted decimal format

7...15 characters

It can contain a single IP address or the IP address of a subnet. Value 0.0.0.0 means that all IP addresses are allowed remoteIpPort

Port number of remote IP address

-1 ... 65535,

-1

If value -1 is configured, the IPsec step 1 policy is valid for all ports of remote IP address remoteNetmask

DN0978045Issue:04A

Netmask of remote IP address

7...15 characters

remoteTunnelEnd point

Remote endpoint of IPsec tunnel, IP address in dotted decimal format

policyNumber

Security policy order number - only 0...65535, step 1 the lowest number of several equally matching policies is applied

©2016Nokia

7...15 characters

309


Table 170



Name

Description

Range

Protocol information of the traffic data packet

protocol

-1 ... 254, step 1

Default value

-1

If value -1 is configured, the IPsec policy is valid for all protocols Lifetime of CHILD SAs (security associations). After the timer has expired for the security association, a new security association is negotiated.

saMaxLifeTime

ikeAssociationsList of IKE associations

peerState

State of IKE peer

remoteTunnelEnd point ikeId

300…86400 sec, step 1 sec

86400 sec

Structure, comprising belowmentioned components 0...1000 characters

Remote IPsec tunnel endpoint IP address Identification of IKE association

7...15 characters

1...1, step 1

1

database – value is always 1 operationalState Operational state of IKE

associations object - summarizes operational states of individual IKE associations associationList Information related to IPsec

DISABLED, ENABLED

ENABLED

1...4000 characters

associations sadbId

g

Identification of IPsec association database - value is always 1

1...1, step 1

Note: In case an existing security policy is changed or deleted, or there is a new policy

added, consequently the eNB IPsec application is restarted and the security associations resulting from the configured security policies are re-established. This causes a temporary transmission break. The eNB IKEv1 application is limited regarding usage of the 'remoteIpAddress' parameter for the configuration of multiple security policies. For a proper eNB IKEv1 operation it must be ensured that the 'remoteIpAddress' parameters of all policies do not overlap in the covered ranges. As an exception to that, one policy with 'remoteIpAddress = 0.0.0.0' meaning all IP addresses are allowed for the remote peer, can be configured.

310

©2016Nokia

DN0978045Issue:04A


4.17.7.2


Alarms for LTE689: LTE IPsec Support Table 171

Alarm number

61030

Alarms for LTE689: LTE IPsec Support

Alarm name

Dead Peer Detected

Condition

A dead peer was detected in one of the IPsec associations of the FTM. Possibly •

7665

a cable is cut or there is no cable connected to the interface

•

the signal is excessively attenuated

•

the port at the connected far end node is switched off

BASE This alarm is raised if the below BTS fault occurs: STATION Dead Peer Detected (61030) TRANSMISS • The fault is reported when a dead peer was detected in one of ION ALARM the IPsec associations of the FTM. Possibly:

–

a cable is cut or there is no cable connected to the interface the signal is excessively attenuated

–

the port at the connected far end node is switched off

–

4.17.7.3

Counters for LTE689: LTE IPsec Support Table 172: Counters for LTE689: LTE IPsec Supportshows counters related to LTE689: LTE IPsec Support. Table 172

PI ID

DN0978045Issue:04A

Counters for LTE689: LTE IPsec Support

Counter name

Description

M51125C0

Protected_ESPFramesTx

Number of successfully encrypted ESP packets in egress direction

M51125C1

Protected_ESPFramesRx

Number of successfully decrypted ESP packets in ingress direction

M51125C2

Discarded_ESPFramesTx

Number of dropped ESP packets in egress direction because of failed encryption

M51125C3

Discarded_ESPFramesRx

Number of dropped ESP packets in ingress direction because of failed decryption

M51125C4

Bypassed_FramesTx

Number of bypassed ESP packets in egress direction

©2016Nokia

311


Table 172

PI ID

M51125C5

4.17.8


Counters for LTE689: LTE IPsec Support (Cont.)

Counter name

Bypassed_FramesRx

Description

Number of bypassed ESP packets in ingress direction

Activating and configuring the feature For activating and configuring the feature, see Feature Activation Documentation.

4.18 LTE690: Interface Trace Support 4.18.1 4.18.1.1

LTE690: Interface Trace Support Overview For the SON use case MDT - Minimization of Drive Tests, the eNB supports a simple trace feature: LTE690: Interface Trace Support. This feature provides the monitoring of protocols of the Uu, S1, X2 and OAM interfaces in the Flexi Multiradio BTS in real-time and the provision of the protocol as binary/raw data via an Ethernet. The protocol information is captured by appropriate SW trace points before the related protocol information is encrypted (TX) and after it is decrypted (RX).

4.18.1.2

Benefits The feature allows protocol traces in encrypted radio and transport networks and offers an interface to external devices like protocol analyzers. As the collected data is available for the Diagnosis and Service Framework, the feature supports faster fault findings.

4.19 LTE692: LTE Firewall Support 4.19.1

Introduction to the feature This feature provides an internal firewall to protect the eNB.

4.19.2

Benefits Enhanced risk management is achieved because of improved RAN system security. CAPEX savings are achieved because it is not necessary to invest into any additional external HW to use this feature.

4.19.3

312

Requirements

©2016Nokia

DN0978045Issue:04A


4.19.3.1




Network element


Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

4.19.3.2


4.19.4

Functional description for LTE Firewall Support The eNB supports integrated firewall functionality. Access control aims to prevent the eNB from handling traffic, services and application to/from unauthorized hosts. IP packet filter rules are based on source and destination addresses, source and destination port numbers and protocols. Ingress rate limiting reduces overload situations on the eNB, whereas egress rate limiting protects other network nodes from unwanted traffic generated by the eNB. Protection against Denial of Service is applied on the eNB. Statistic is improved by implementing appropriate counters and traffic logging. Protected interfaces

The eNB firewall functionality applies to all external interfaces, for example S1-MME, S1U, X2-C, X2-U and O&M. In case the rate limit is exceeded, the exceeding traffic will be dropped. The rate limit is defined according to the resource capacity of the eNB. Firewall characteristics

The firewall functionality is enabled on principle, that is it can not be switched off. Furthermore, the firewall filter rules are fixed, that is they can not be configured. The fixed firewall rules are derived from the LTE IP topology such that they are appropriate for each plane, for example for C-plane the eNB accepts all SCTP traffic sent to the eNB C-plane IP address. Static rules allow to automatically cover relevant IP addresses, ports, protocols, etc. and thus configuration errors are avoided. ICMPv4

DN0978045Issue:04A

©2016Nokia

313



ICMPv4 is supported with the following messages:

Messages

Table 174

message

receive direction (Rx)

DestinationUnreachable

x

TimeExceeded

x

ParameterProblem

transmit direction (Tx)

x

x

Echo Request

x

Echo Reply

x

x x

It is possible to disable eNB responses to ICMP Ping (Echo Request) messages and traceroute messages received over the external interfaces.

4.19.4.1

Firewall functionality The following firewall functionalities are provided: • • • •

ingress IP packet filtering ingress rate limiting egress rate limiting DoS countermeasures

Ingress IP packet filtering

The ingress IP packet filter filters ingress IP traffic based on source and destination IP addresses (including IP subnets), source and destination port numbers, and protocol. Filter criteria/rules are fixed. Ingress IP packets which do not match any of the defined rules will be dropped. Compared to the general stateless operation of IP packet filtering, there is an exception for handling of ICMP on eNB side. ICMP is handled in a stateful, for example an egress ICMP message is evaluated regarding the included target address in order to accept the corresponding ingress ICMP message from this address. Ingress rate limiting

In order to avoid an overload of the eNB internal subsystems and to limit the effect of Denial of Service attacks, the ingress packet rate can be limited. Supported messages are ICMP and ARP. In orderoftoService avoid an overload of the NE internal andseparately to limit thefor effect Denial attack, the ingress packet ratesubsystems can be limited eachofofa the following traffic aggregates: • • •

M-plane

•

S-plane (ToP)

•

314

U-plane C- plane

ICMP Echo Request

©2016Nokia

DN0978045Issue:04A


• •


ICMP Echo Reply ARP Request and Reply

Traffic exceeding the defined rate limits will be dropped. Traffic exceeding one aggregate will not affect the traffic for other aggregates. The rate limits are defined according to the capacity of the eNB internal subsystems and the share of the internal resources that the traffic is allowed to use. Egress rate limiting

The egress packet rate of the following ICMP messages is limited: • • • •

Echo Request Echo Reply Time Exceeded Destination Unreachable

DoS countermeasures

The eNB is protected against the following DoS attacks: •

Smurf attack:

In the smurf attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate DoS attacks. •

Teardrop attack:

Some implementations of the TCP/IP fragmentation reassembly code do not properly handle overlapping IP fragments. This attack would affect only to O&M since reassembly is not supported by U-plane/C-plane. •

Land A Landattack: attack involves sending a spoofed SYN packet with the target host's IP address and an open port as both the source and the destination. This attack would affect only O&M since TCP is not used by U-plane/C-plane. •

TCP SYN attack:

For TCP protocol, SYN messages are sent to the target with non existent source addresses, causing the resources to be reserved until a time-out happens. This attack would affect only to O&M since TCP is not used by U-plane/C-plane. •

Ping of Death attack:

An ICMP Echo Request message is sent to the target with size over 65535 bytes. This is not a legal packet size and it could cause the operating system to crash.

4.19.4.2

Firewall filter Filter rules are fixed. Predefined packet filter rules

The packet automatically configured allowbased the following and protocols forfilter theisapplicable addresses and to ports, on the applications predefined configuration: • • • • • •

DN0978045Issue:04A

Control plane ( SCTP) IKE ( UDP) Timing over Packet (UDP) PW ( MPLS) LDAP (TCP) CMP (TCP)

©2016Nokia

315



If any of the applications above is not enabled, the respective filter configuration will not be performed. Rules include source and destination IP addresses, source and destination port numbers and protocol. icmpResponseEnable parameter

The icmpResponseEnable parameter controls the eNB response to ICMP and traceroute requests. The functionality is per default enabled. This parameter can be configured by NetAct or BTS Site Manager.

4.19.4.3

Logging The firewall allows to log discarded and dropped packets. Discarded packets statistic

Number of packet discarded by eNB firewall is measured. Counters are implemented for: 1. Ingress IP packet filtering: Discard of IP packets received which do not match the defined filtering rules. 2. Ingress rate limiting Discard of IP packets received and dropped in order to avoid an overload of the eNB internal subsystems. This report is useful to detect ‘attacks’ on IP layer. It should be mentioned that also misconfigurations at the IP layer, for example a configuration of wrong IP addresses may cause IP packets to be discarded according to the filtering rules. Traffic logging

It is possible to log the traffic which is dropped due to: • •

filtering rules rate limiting

Logging stops automatically when there is no more storage space available. It is possible to start and stop the traffic logging manually. The following is traced: • • • • • •

destination and source addresses protocol type destination and source port (if present) message type and code (for ICMP) cause (filtering rule, rate limit exceeded) timestamp

Traffic logging helps to determine a problem in the configuration of the filtering rules, and to monitor which type of traffic is used for DoS. Traffic logs are available only to the Site Manager.

4.19.5

System impacts There are no impacts related to the feature.

316

©2016Nokia

DN0978045Issue:04A


4.19.6


Sales information The LTE692: LTE Firewall Support feature is an additional software feature and the license is trust-based (SW Asset Monitoring). The feature is activated for the whole eNB. No special activation is necessary.

4.19.7 4.19.7.1

User interface Parameters for LTE692: LTE Firewall Support Table 175: Parameters for LTE692: LTE Firewall Supportshows parameters related to LTE692: LTE Firewall Support. All parameters are located in object IPNO. Table 175

Parameters for LTE692: LTE Firewall Support

Name

Description

icmpResponseEnabled

4.19.7.2

This parameter controls if the BTS responds to ICMP and traceroute requests

Range

TRUE, FALSE

Default value

TRUE

Counters for LTE692: LTE Firewall Support Table 176: Counters for LTE692: LTE Firewall Supportshows counters related to LTE692: LTE Firewall Support. Table 176

PI ID

4.19.8

Counters for LTE692: LTE Firewall Support

Counter name

Description

M51126C0

ipRmDroppedPacketsRateLimiting

Number of dropped packets due to ingress rate limiting

M51126C1

ipRmDroppedPacketsFiltering

Number of packets discarded due to ingress packet filtering violations

Activating and configuring the feature This feature needs no special activation procedure.

DN0978045Issue:04A

©2016Nokia

317



4.20 LTE720: SON LTE BTS Auto Configuration 4.20.1

Introduction The Flexi Multiradio BTS Auto Configuration feature provides automated configuration of new or relocated base stations from a remote network operation center with minimized manual interventions.

4.20.2

Benefits The automated configuration supports: •

•

•

4.20.3 4.20.3.1

Faster commissioning and configuration after a Flexi Multiradio BTS installation due to Plug'n'play. In regular case no skilled commissioner needed atsite for performing manuallocal commissioning and configuration steps. Higher reliability of software installation because there isn't almost any human interaction involved.




Systemrelease

RL10

MME

-

SAE GW

-

NetAct

4.20.3.2

OSS5.2CD3


4.20.4

Overview From an NE perspective, LTE720: SON BTS LTE Auto Configurationin short runs as following: The NE receives a SW download and is activated to a new SW release. Following the reset for SW activation, the NE receives a full plan file download from the NetAct. The LTE BTS auto-configurationfeature comprises the following:

318

©2016Nokia

DN0978045Issue:04A


• • •


pre-planning steps auto configuration steps network integration steps

The automated configuration is initiated by the eNB auto-configuration agent and controlled by the NetAct auto-configuration application, which belongs to the overall NetAct SON coordinator application. The agent‘s SW is a part of the initial basic SW build delivered from the factory which also provides the basic bootstrap process and the self-connectivity procedure. On the NetAct side, the SON coordinator coordinates the execution of the existing common functions required to bring the eNB into service, that is, it does not re-implement functions like SW and license file download which are also needed during normal operation. The auto-configuration can be run fully autonomously or certain stop points can be defined with the NetAct auto-configuration application. The configuration continues then until the next stop point as defined by the operator. For Flexi Zone Micro, a different set of optimizer preferences is recommended from the macro preferences. OSS5.5/NetAct 8 only allows for one set of preferences to be utilized during any automatic run of the optimizer algorithms. Therefore, it is recommended that the macro preferences be used for any automatic execution of the optimizer algorithms, including during auto-configuration. After the automatic execution has completed, the operator should manually change the preferences to be suitable for small cells and then manually invoke the optimizer algorithms for the small cells. Pre-planning steps •

•

Factory: The eNB is delivered from the factory with an initial SW load which includes all functions needed to in perform successfully thebut auto-connection and autoconfiguration functions an LTE environment without operator-specific configuration. Flexi Multiradio configuration plan preparation: Theplanning data that is needed to integrate a new or relocated eNB into the network is prepared in advance, that is, site configuration, radio network configuration, and transmission configuration. The planning data needs to be assigned to a “Site”, which can be identified by either GPS coordinates or by street name. Assignation of eNB to a “SITE” can be done when importing a new eNB plan file (RAML) into Configurator, or manually if creating eNB configuration plan in Configurator using CM Editor.

Auto configuration steps

1. The NE requests auto-commissioning, if it is not commissioned. NetAct receives a Configuration Change Notification (CCN) requesting a configuration for a auto connected eNB. 2. Download and activation ofthe appropriate eNB target SWbuild: The Auto configuration workflow in the NetAct triggers download of the prepared target SW and buildactivation to the eNB. The downloaded SW is activated and the eNB restarts. 3. Download of the prepared configuration plan: The auto-configuration workflow in the NetAct includes the update of time and location dependant parameters (PCI, PRACH and adjacencies). The operation is done per site, which means only the site which is under auto-configuration and the current eNBs are considered during the update. After the update the NetAct workflow triggers the download of the prepared eNB configuration plan including transportrelated, HW-related and radio network layer (RNL)-related data. The plan is validated in the eNB and – in case of positive validation – activated with an eNB restart.

DN0978045Issue:04A

©2016Nokia

319



After the restart, the external connection towards the NetAct is re-established based on the parameter values in the downloaded plan. Secure interfaces using IPsec and/or TLS are set up as selected in the database.

g

Note: It is up to the operator's network planning policy whether or not new IP

g

Note: Additional software loading for RF modules might take place, when the Radio

addresses are assigned. If the DHCP assigned IP address is continued then it is mandatory to assign the same address again in case of renewal/lifetime expiry.

modules auto by the eNBthe target SW and target they are in the database.are This willdetected be the case when downloaded SWconfigured is of different RAT than the one that has performed the Autoconnection, for example when: • •

LTE-specific RF modules are equipped, and there is an Auto connection into theLTE network based on an eNB software stored on eNB flash in factory, which is of WCDMA RAT or which is a RAT independent factory software.

The NetAct SWM setting is configured to allow the node-requested SW download. Otherwise, manual SW download is needed to provide the SW files for HW sub-units in the eNB. Auto-configuration steps Figure Auto-Configurationillustrates all the steps necessary to implement auto-

configuration. Figure 40 NE

Auto-Configuration RNC/ OMS

NetAct

Topology Manager

SW Manager

Configurator

License manager

Inventory

Auto configuration workflow

Create plan for BTS SC & TRS and SW package

Establish connection to RNC/OMU-OMS Setup NetAct Topology with new NE BTS connected and ready for configuring

Auto configuration request (param value change notification)

Autotriggering+ licence check

SW - Download Sequence

SW Download & activation Restart Configuration File Download (Site Creation & Transport Plans)

BTS SC+TRS plan download

BTS SC+TRS plan activation

Configuration File Activation Restart BTS is configured

NE is ready for Network Integration

Network integration

320

©2016Nokia

DN0978045Issue:04A



With the end of the configuration phase the eNB starts the establishment of all S1 connections towards the configured Mobility Management Entity (MME). If IPsec is activated then the appropriate IPSec Tunnel (or tunnels) — created before the Signaling Common Transport Protocol (SCTP) associations — are established. For completely pre-configured neighbor site configurations, the corresponding X2 SCTP connections are set up as well. Software upgrade from factory SW to FDD/TDD FL15A/TL15A

g 4.20.5

Note: Module FSMF with FDSW1.0 won’t support direct upgrade to FL/TL15A. The

workaround will be to upgrade from FDSW1.0 first to RL70 and then to FL/TL15A. FDSW1.1 supports the direct upgrade to FL/TL15A without restriction.

Interdependencies between features Table 178

g

Interdependencies between LTE720 and other features

LTE151

Autonomous Flexi LTE BTS Operability

LTE154

LTE Auto Connectivity

LTE152

LTE Feature Management

LTE665

LTE SW Management

LTE147

LTE HW Management

LTE654

LTE Configuration Management

LTE539

Central ANR

Note: LTE720: SON LTE BTS Auto Configurationrequires the feature LTE154: SON LTE BTS Auto Connectivityto be in place. It is not possible to configure

the initial IP configuration manually and to continue with Auto Configuration. For example a DHCP server must be available.

4.20.6

Bar code reader support for BTS site manager Use case: The unique eNB identifier is selected/specified during the network planning. The unique eNB identifier can be given to the installation service provider (external or internal one) printed on an order form with an agreed code readable by a bar code reader. The field installer can connect the bar code reader to the BTS Site Manager to inject the eNB identifier. Utilizing a bar code reader to obtain the information removes the possibility of erroneous data entered via typing errors. The eNB continues auto-configuration considering the configured unique eNB identifier into account.

DN0978045Issue:04A

©2016Nokia

321


4.20.7 4.20.7.1


Configurator user visibility to auto configuration in NetAct E-mail indications Defined users are informed in real time via e-mail when eNB Auto Configuration (AC) starts/stops. The e-mail contains a link to open the AC report, that contains more details. When eNB AC starts, the user(s) receives a real- time e-mail indication. When eNB AC ends, the user(s) receives a real-time e-mail that will contain the status of the auto configuration process.

4.20.7.2

CM operations manager operations history tab The CM Operations Manager operations history shows the eNB (similar to the usertriggered plan operations).

4.20.7.3

Auto configuration report The user can open an AC report with an overview of eNBs that are in “auto-configuration state” or similar. The AC report web page can be opened from: • • • •

browser bookmark own icon in the start page Configuration category e-mail notification get at AC start/stop generated report link with w-flow operation summary report

For one eNB, the user can open a report which contains detailed information for example, about the AC operations feedbacks. The e-mail indication received when AC starts/stops contains a link to the AC report (filtered for the eNB), in which the user can find more information.

4.20.8

Use case: BTS/eNB Auto Configuration This use case shows the overall workflow of eNB auto configuration when a fully automatic configuration is performed. Actors

NE, O&M Mediator, NetAct Preconditions •

All necessary data that isneeded for auto configuration has been prepared and is stored in the corresponding repositories: – Software loads are assigned to the NE in NetAct – System configuration data for each NE

g

322

Note: With the introduction of LTE, NetAct is provided with a dynamic plan completion

feature which allows determination of some data on-the-fly when the plan is downloaded.

©2016Nokia

DN0978045Issue:04A


• • • • •

• •

• •


NE O&M connection is established. NWI3 connection is established. NE is not commissioned. Auto configuration for this NE is not blocked. NE contains the SW build which includes (at least) all functionalities needed for auto configuration, such as the boot, file downloading, and basic SW management. This SW build may have been provided by the factory, or it may have been downloaded during an earlier configuration. In this case auto configuration is performed only when the NE’s earlier system configuration data has been removed or has become inaccessible. NetAct auto configuration wizard is up and running in automatic mode. All necessary NetAct services and applications (SW manager, license manager, NetAct configurator, HW manager) are licensed, and up and running. Auto configuration licenses are available in NetAct. The NE object has been configured to NetAct with all necessary parameters: – –

required: site configuration data optional: radio network data O&Mmediator has sent thetopology event for NEto NetAct and NE objects are added in the topology data.

Trigger event

NE sends the Configuration Change Notification (CCN) indicating “Commissioning required” to O&M Mediator. Description

1. 2. 3. 4.

O&M Mediator mediates CCN to NetAct. NetAct receives trigger for NE auto configuration. NetAct checks the auto configuration license. NetAct checks the availability of pre-planned data (NE SW build and NE configuration file) in its repository. 5. NetAct triggers the SW download to NE including automatic activation (optional). 6. NetAct triggers the configuration download to NEand validation of the received configuration. 7. NetAct triggers the configuration activation in NE. Post conditions • •

4.20.8.1

NE auto configuration has been completed. NE has reached at least thestate “commissioned” and is ready togo on to reach “configured.” “Integrated into RAN”, “On Air” or “Test Dedicated”, depending on the downloaded configuration and the accessibility of its partner network elements.

SW download and activation This use case describes the download and activation of SW as it occurs within the auto configuration workflow.

DN0978045Issue:04A

©2016Nokia

323



Software download and activation

Figure 41

NE

NetAct AutoConf wizard

NetAct SW Mgmt

OMS

SW download (NE)

Select SW load

SW Download (NE, SW load, immediate activation) Download SW Build SW update (target SW, repository,immediate activation) Download files SW Download reply Reset SW Download reply Re-establish O&M connection SW Change Notification

SW Change Notification

SW Change Notification

Actors

Auto configuration wizard, NE, O&M Mediator, NetAct SW management Preconditions •

• •

• •

NE is connected; NE O&M interface between NE and O&M Mediator is working; NWI3 interface is working. NE object has been configured to NetAct with all necessary parameters. All necessary data that is needed for auto configuration (SW loads, configurations for HW, physical and logical transport, radio) is stored in the corresponding repositories. Auto configuration wizardis up and running; auto-configuration license is available. Auto configuration for this NEhas not been blocked by the operator at BTS Site Manager.

Trigger event

NetAct has checked connection license. prerequisites like existence of pre-planned data and the auto If the confirmed mode of auto configuration is active, the operator has also confirmed that it is proceeding with the SW download. Description

1. NetAct auto configuration wizard triggers the NetAct SW Manager . 2. NetAct SW Manager selects the corresponding SW for the NE.

324

©2016Nokia

DN0978045Issue:04A



3. NetAct SW Manager triggers SWdownload to O&M Mediator indicating the target SW and SW repository. O&M Mediator downloads the required SW build from NetAct. 4. O&M Mediator sends the SWupdate request to the NEindicating target SW and SW repository. The request contains indication of automatic SW activation. 5. NE determines files that needto be downloaded.

g

Note: Note that this may be an empty set, if the NE already contains the right SW load.

6. NE downloads files from the indicated repository. 7. NE activates downloaded target SW via BTS site reset. 8. BTS re-establishes the O&M connection toO&M Mediator. 9. BTS sends the SW change notification to O&M Mediator. 10. O&M Mediator mediates the SW change notification to NetAct SW Manager. 11. NetAct SW Manager mediates the SW change notification to the auto configuration Wizard. In parallel to step 8. - 10. 12. O&M Mediator sends the SW download reply to NetAct SW Manager. 13. SW Manager reports the result to the auto configuration wizard. Post condition

NE has stored and activated the new SW load.

4.20.8.2 4.20.8.2.1

Configuration data download and activation Download and validation of configuration data Use Case

This use case describes the download of configuration data, as it occurs within the auto configuration workflow. Actors

NetAct Auto Configuration wizard, NetAct Configuration Management, O&M Mediator, NE. Preconditions • • •

•

•

•

NE is connected; NE O&M interface between NE and O&M Mediator is working; NWI3 interface is working NE object has been configured to NetAct with all necessary parameters All necessary data that is needed for Auto Configuration (configurations for NE HW, physical and logical transport objects) is stored in the corresponding repositories. Planning tool or operator provides Configuration Data for NE. Auto Configuration wizardis up and running, Auto Configuration licenses are available. Auto Configuration for this NEhas not been blocked by operator at BTS Site Manager. Auto Configuration workflow for the corresponding NE is running.

Trigger

DN0978045Issue:04A

©2016Nokia

325



SW Management has indicated successful SW Activation to the Auto Configuration wizard. If the confirmed mode of Auto Configuration is active, the operator also has confirmed to proceed with Configuration Download. If the SW download step is skipped, the same trigger as for SW download applies. Description

1. NetAct Auto Configuration wizard triggers NetAct CM. 2. NetAct CM selects the corresponding plan data for the NE. 3. NetAct CM performs a dynamic plan completion onthe selected data (optional). 4. NetAct CM validates the configuration data to be downloaded with the help of the BTS Site Manager. 5. NetAct CM triggers NE configuration download toO&M Mediator. 6. O&M Mediator transfers NE configuration data toits repository and sends download trigger to NE. 7. NE downloads configuration data fromthe indicated repository. 8. NE validates downloaded configuration data. 9. NE acknowledges file transfer to O&MMediator. 10. O&M Mediator mediates the file transfer completion to NetAct CM. 11. NetAct CM reports result to Auto Configuration wizard. Post condition

NE has stored the assigned Configuration Data on non-volatile storage.

4.20.8.2.2

Activation of configuration This use case describes the activation of configuration, as it occurs within the auto configuration workflow. Actors • • • •

NetAct auto configuration wizard NetAct Configuration management O&M Mediator NE

Preconditions •

•

•

• •

NE is connected; NE O&M interface between NE and O&M Mediator is working; NWI3 interface is working. All necessary data that is needed for Auto Configuration (SW loadand Configuration Data) has been downloaded and is stored on local NE repositories. Auto Configuration wizardis up and running, Auto Configuration licenses are available. Auto Configuration workflow for the corresponding NE is running. Auto Configuration for this NEhas not been blocked by the operator at BTS Site Manager.

Trigger

326

©2016Nokia

DN0978045Issue:04A



NetAct CM has indicated the successful download of a Configuration data to the Auto Configuration wizard. If confirmed mode of Auto Configuration is active, the operator also has confirmed proceeding with activation of configuration. Description

1. NetAct Auto Configuration wizard triggers NetAct CM to activate the downloaded Configuration Data 2. NetAct CM sends plan activation request for NE to O&MMediator. 3. O&M Mediator mediates activation request to NE. 4. NE acknowledges activation toO&M Mediator. 5. O&M Mediator mediates activation acknowledgement to NetActCM. 6. NetAct CM sends response to NetAct Auto Configuration wizard. 7. In parallel to step 5 + 6 NE restarts. 8. NE changes the state to “Commissioned”. 9. NE re-establishes O&M connection. 10. NE notifies state change to OMS.

g

Note: Note that this notification is a part of a state upload for all objects which are in

the NE's topology. Further processing of this state change notification within OMS/NetAct depends on the State Management relevant for this NE release, and is not relevant for Auto Connection workflow. 11. NE sends CCN indicating that Commissioning is no longer required for the NetAct via O&M mediator. 12. NE sends HW change notification to the NetAct via the O&M Mediator. 13. Dependent on the configuration data and status of other Network Elements, NE might go on to achieve State “Configured”, “Integrated into RAN”, “On Air” or “Test Dedicated”. Post condition

If no exceptions have occurred, NE has been re-started and runs with downloaded SW load and configuration data.

4.20.8.2.3

Automatic physical-layer cell ID generation This allows a UE to measure quickly the reception quality of a neighbor cell and know immediately its identification. In the RRC communication between UE and eNB the PCI value is used to reduce the message length. There are further physical-layer radio configurations dependent on the PCI value. This procedure describes the deployment of a new eNB. The auto configuration procedure performed at NetAct is described. To support immediate feedback to the eNB installationhas personnel, it is recommended, instantly do the eNB configuration. NetAct Optimizer to consider all yet planned to PCI value assignments. Actors

Operator-initiated action for preparation for several planned eNBs. Auto configuration procedure running on NetAct for one new eNB Precondition

DN0978045Issue:04A

©2016Nokia

327



An new eNB is already deployed and auto connection procedure has been yet executed. This means that the new eNB had received M-plane IP-address from DHCP server. Mplane connection from new eNB towards NetAct does exist. Description

The following steps have to be supported by NetAct: 1. NetAct Optimizer will be triggered to generate most suitable PCI values for the prepared plan file. The PCI values can be generated up-front based on the data received from the planning tool. 2. NetAct Optimizer has to generate the most suitable PCI values basedon the Operator policy and the current and planned network deployment. In addition, the distance and the intra-frequency radio improvements. 3. NetAct Configurator continues with the auto configuration of the new eNB. Post condition

The eNB operates with PCI values, that are collision- and confusion-free.

4.20.9

Parameters for LTE720: SON LTE BTS auto configuration Table 179: Parameters for LTE720: SON LT E BTS auto configurationshows parameters related to LTE720: SON LTE BTS auto configuration Table 179

Parameters for LTE720: SON LTE BTS auto configuration

Short name

328

Object

Description

Range/step

Default

resetToTestDe BTSSC dicated

flag indicating if NE should automatically go to "Test Dedicated" after reset

0 - do not enter "Test Dedicated" automatically1 - enter "Test Dedicated" automatically

commissioning BTSSC Required

flag indicating that NE requires commissioningalways set autonomously by NE

00 commissioning not required

autoConfBlock BTSSC

flag indicating if Auto

0 - Auto

ed

Configuration NE is allowed for - tothis be set by operator at BTSSM

Configuration allowed

©2016Nokia

0

1commissioning required 0

1 - Auto Configuration blocked

DN0978045Issue:04A


Table 179


Parameters for LTE720: SON LTE BTS auto configuration (Cont.)

Short name

Object

Description

g

Range/step

Default

Note: This

parameter is only relevant for an uncommissione d NE

4.21 LTE724: LTE Automatic Neighbor Cell Configuration 4.21.1

Introduction to the feature This feature supports manual configuration of intra-LTE neighbors for all cells of the target and source eNB by the operator. With the configuration of the neighbor identification, the X2 link is established and both eNB exchange their cell configuration to be prepared for HO. The neighbor identification can be prepared in a pre-planning phase or configured during operation of the eNBs. Only a subset of the standard information configuration is required. Off-line planning applies to the Node-ID and/or the IP address of the neighbor LTE eNB hosting the expected neighbor cells. All other configuration information for cells of neighbor LTE eNBs are automatically derived and updated via the X2 interface.

4.21.2

Benefits The operator considers only the configuration of the eNB's served cells and the IP connectivity to all its neighbor LTE eNBs. For all LTE neighbor cells, the configuration data necessary for establishing the required IP connectivity towards the hosting BTS site is pre-planned offline or can be reconfigured during operation. The eNB establishes X2 connections to all neighbor eNBs, up to the supported number of X2 links. With an established X2 link at both peers, the eNBs keep an up-to-date knowledge of the neighbor cell configuration data for S1 and X2 handover.

4.21.3 4.21.3.1

Requirements Software requirements The following software is required for the feature:

DN0978045Issue:04A

©2016Nokia

329


Table 180




Systemrelease

RL09

MME

-

SAE GW

-

NetAct

4.21.3.2

OSS5.2CD1


4.21.4 4.21.4.1

Functional description Pre-planning During offline planning with the NetAct planning tools or the BTS Site Manager, the operator has to plan the IP addresses of all neighbor sites. All further neighbor base station information about the hosted neighbor cell is derived automatically during the corresponding X2 set-up procedures.

g

Note: Only one single X2 connection is established between two base stations

regardless of the number of supported cells per eNB. This means all cells of an eNB, each assigned with a unique addresses are assigned to theglobal BTS Cell-ID, nodes. have the same X2 IP address because IP

4.21.4.2

Commissioning and integration phase of a new eNB If a newly deployed Flexi BTS for LTE has all the commissioning data including the configuration data, it runs the X2 Set up procedure to each configured neighbor eNB. When the connection is established successfully, for example the listed neighbor is already installed and commissioned then, after establishment of the X2 link, all required neighbor information is exchanged between the requesting eNB and all responding ones. The information is stored in the corresponding NCL entries of the involved eNB on both sides. If a listed neighbor does not respond, it is marked as not reachable without any further notification.

4.21.4.3

LTE neighbor cell information Neighbor cell information and neighbor cell relations are stored by eNB in managed objects. Cells served by eNB are represented by managed object LNCEL. The relation to neighbor cells for LNCEL are stored in the new introduced object LNREL, where one LNREL represents the neighbor relation of LNCEL to one NbCell. Compared to RL20 there was a remodelling of LTE neighbor cell information: • • •

330

Managed object LNREL is introduced Managed object LNADJG for providing GSM cell information is introduced Managed object LNADLP is removed

©2016Nokia

DN0978045Issue:04A


• •


Managed objects LNADJ and LNADJL are persistently stored by eNB IP-address used for X2-link establishment are stored in LNADJ

Compared to RL30 new MOCs are introduced: • •

4.21.4.4

Managed object LNRELW is introduced Managed object LNRELG is introduced

Neighbor cell update When one eNB in operational mode receives an X2 Set-up request from another eNB, it responds to the request, sends its own cell configuration data to the requesting eNB, and stores the received configuration information in its own NCL list.

g

Note: If the eNB receives an X2 setup request from another eNB but it already has the

g

Note: Without activation of the LTE492: Automatic Neighbor Relation (ANR)and/or LTE782: ANR-UE basedfeature, the eNB will discard incoming connection requests

maximum allowed number of X2 links, it will reject the new X2 link request. In this case the neighboring eNB may attempt S1 HO.

from a neighbor site if there is no IP address configuration available for this particular site. In RL30, if either the LTE492: ANR feature or the LTE782: ANR-UE basedfeature is activated at the target eNB, then for the LTE724: LTE Automatic Neighbor Cell Configurationfeature X2 configuration it is sufficient to configure the IP address, as OAM-controlled, at one peer. If the requesting eNB of the X2 Set-up procedure is already known and the neighbor configuration information is available, the responding Flexi LTE eNB still sends its own cell configuration to the initiating eNB. The received information is compared with the existing information and is updated if modifications are identified.

4.21.4.5

Configuration data exchange via X2 The common X2 procedures on the control plane are used to derive and update the OAM neighbor cell configuration data.

g

DN0978045Issue:04A

Note: In RL10/20, these cells reported from the connected neighbor eNB become

neighbors of the own cells. From RL30 on, more details are given in the common Object Model behavior description. It is up to the operator to consider the topology and configure the correct neighbors. The LTE539: Central ANR feature runs in the NetAct to find out the most suitable neighbors based on geolocation.

©2016Nokia

331


Figure 42

4.21.4.6


Configuration of neighbor cells

LTE724 Interaction with Common Object Model With the introduction of the common object model approach, there is a common storage of neighbor cell and relationship information for S1, X2 handover for manual configuration and/or automatic learning of neighbor cells, either in the auto configuration or later during operation of the eNB. This has impact on theLTE724: LTE Automatic Neighbor Cell Configuration, LTE539: Central ANR, LTE492: ANRand LTE782: ANR Fully UE based features, and allows concurrent operation of all these features. The operator can even configure neighbor eNB in a similar way as the LTE492: ANR/LTE782: ANR - UE based feature would find those during operation of the eNB. The eNB will not only store the neighbor IP address all the time, but also all the neighbor cell information. This supports X2 as well as S1 handover to these neighbors. In case the X2 link is dropped and X2 hand over is not possible, then automatically S1 handover is applied. The cell's neighbor information will be resolved as soon as the UE reports the neighbor PCI during mobility measurements. After an HO attempt is initiated to this cell, a persistent neighbor relation is established. The management of the neighbor relationships with blacklists on the cell and the eNB levels are supported. More neighbor eNBs and cells are supported to allow even more learning of neighbors. Still the manual configuration of neighbor eNB and cells is possible in parallel to ANR functions. The srcinal LTE724: LTE Automatic Neighbor Cell Configurationfeature behavior is obtained, if the IP address is configured as oamControlled IP address. Applying the feature requires only configuring at both peers the other neighbor eNB's IP address (neighbor identification).

332

©2016Nokia

DN0978045Issue:04A


4.21.5



4.21.6 4.21.6.1


4.21.6.2


4.21.6.3


4.21.7

Sales information The LTE724: LTE Automatic Neighbor Cell Configurationfeature is a basic software feature.

4.22 LTE746: IP based filtering for BTS Site Support Equipment 4.22.1

Introduction to the feature This feature allows selective access of the IP data communication network ( DCN) towards site support equipment and vice versa. Filtering is done based on IP addresses and the size of maximum transmission unit (MTU). It improves the protection of: • •

4.22.2

site support equipment from harmful IP DCN traffic IP DCN from harmful IP traffic srcinated from site support equipment

Benefits The protection against harmful manipulation of the site support equipment configuration via IP DCN is improved.

4.22.3

DN0978045Issue:04A

Requirements

©2016Nokia

333


4.22.3.1




Network element


Systemrelease

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

4.22.3.2

OSS5.2CD3


4.22.4

Functional description for IP based filtering for BTS Site Support Equipment The eNB provides access to site support equipment (for example battery backup units etc.) via additional ethernet interfaces. Typically, this type of IP-based equipment does not provide an own IP packet filter or a firewall. Thus, the site support equipment is directly accessible if there is no packet filter at eNB side. Therefore, the eNB provides an IP packet filter service that protects the site support equipment from harmful network traffic, but also protects the network from unintended traffic from this interface. It is possible to define IP addresses or IP subnets that have access to any site support equipment. IP packets from/to any site support equipment which do not match any of the configured IP addresses/subnets are dropped. The maximum transmission unit (MTU) of the eNB interface towards backhaul network is also configurable. The operator must set the MTU size to a value large enough to accommodate IP packets from SSE. The configured size must include the size of a possible overhead (up to 73 bytes if IPsec is applied to SSE traffic).

g

Note: Make sure to configure the MTU correctly. If packets arriving from/going to SSE

have size larger than the configured MTU, the packets are dropped. For more information on the configuration of MTU, seeLTE Transportfunctional area description. The configuration of the feature is done using BTS Site Manager from a local or remote site, or by NetAct.

334

©2016Nokia

DN0978045Issue:04A


4.22.5


System impacts The feature has no additional impact on the system.

4.22.6

Sales information The LTE746: IP based filtering for BTS Site Support Equipmentfeature is a basic software feature.

4.22.7 4.22.7.1

User interface Parameters for LTE746: IP based filtering for BTS Site Support Equipment Table 182: Parameters for LTE746: IP based filtering for BTS Site Support Equipment shows parameters related to LTE746: IP based filtering for BTS Site Support Equipment. All parameters are located in object IPRM. Table 182

Parameters for LTE746: IP based filtering for BTS Site Support Equipment

Full name

Description

Range / Step

(Short name) RmExceptions

Filter rules defined for traffic from/to attached site support equipment (SSE) – traffic from/to SSE to/from remote peers is only allowed if the remote peer’s IP address is configured in the filter rule. By default SSE cannot be accessed, i.e. a configured remote peer’s IP address is an exception to the default behavior.

Structure, comprising belowmentioned components

sourceTwoDiscr

Description of remote peer as dedicated

SINGLE, RANGE, WILDCARD

•

SINGLE: a single IP address

•

RANGE: range of IP addresses (IP address and subnet mask) WILDCARD: any IP address allowed

•

sourceTwoIpAddr

Meaningful if sourceTwoDiscr is defined as only SINGLE or RANGE • •

DN0978045Issue:04A

7…15 characters

Default value

0.0.0.0

SINGLE: IP address from/towards traffic is allowed RANGE: upper limit of the IP address range from/towards which traffic is allowed, entered in dotted decimal format

©2016Nokia

335


Table 182


Parameters for LTE746: IP based filtering for BTS Site Support Equipment (Cont.)

Full name

Description

Range / Step

(Short name)

Default value

Value 0.0.0.0 means address not used. sourceTwoNetMask

Relevant only if sourceTwoDiscr is defined as RANGE; when applied to sourceTwoIpAddr, the allowed range of IP addresses is derived. Entered in dotted decimal format.

7…15 characters

0.0.0.0

Value 0.0.0.0 means netmask not used. userLabel

User defined identification of the SSE specific filter rule

1…40 characters

iprmId

Identification of unique instance of class IPRM

1...1, step 1

Value is always 1, not modifiable

Table 183: Parameter for configuring MTU size.shows parameter for the configuration of the Ethernet interface MTU size. The parameter is a part of the LTE664: LTE Transport Protocol Stack. For the complete list of parameters related to LTE664, see Parameters for LTE transport. Table 183

Parameter for configuring MTU size.

Full name

Description

Range / Step

(Short name) Maximum transfer unit (MTU)

4.22.8

The size of the maximum transfer unit of 576...1608 the Ethernet interface. bytes

Default value

1500 bytes

Activating the feature This feature does not require activation.

336

©2016Nokia

DN0978045Issue:04A



4.23 LTE913: LTE NEBS compliant OMS 4.23.1

Introduction to the Feature OMS (Operation and Management Server) hardware is available as pre-certified NEBS

(Network Element Building Standard) compliant hardware. NEBS compliant hardware fullfills very strict requirements on reliability, product safety, electromagnetic compatibility and environmental requirements, and meets the highest standards for telecommunication networks.

4.23.2

Benefits Operators have accepted the Network Equipment Building StandardNEBS ( ) which ensures common criteria for network integrity, in particular in environments where equipment from multiple vendors is involved. NEBS compliance allows operators to deliver reliable network performance with uninterrupted service even during catastrophic events. NEBS compliance also provides energy savings. Additionally, operators can rely on the NEBS compliant equipment without having to test the reliability aspects covered under NEBS. As a result, it is easier to introduce new equipment to a network, to lower one’sOPEX, and to reduce time to market for new network roll-outs.

4.23.3

Functional Description OMS hardware is available as pre-certified NEBS compliant hardware.

NEBS is not a legal or regulatory requirement but a requirement by major North America operators for equipment that goes in the Central Office. Since in most cases OMS is such Central Office equipment, NEBS compliance is one requirement. NEBS compliant hardware fullfills very strict requirements on reliability, product safety, electromagnetic compatibility and environmental requirements, and meets the highest standards for telecommunication networks. NEBS compliant hardware can be bladebased or rack-based. Software changes on NEBS compliant hardware are not expected to cause retest for NEBS. However, hardware and platform/configuration changes made to NEBS hardware may create the requirement to retest the equipment. NEBS compliance is divided into three levels. The highest level (3) is the minimum to assure operability within network facility environment under extreme conditions. NEBS environmental criteria include Electromagnetic Compatibility ( EMC) and Safety requirements, including: • •

Electrostatic Discharge ( ESD) Electromagnetic Interference ( EMI) – – – – –

DN0978045Issue:04A

Radiated Emissions - Electric Fields Radiated Emissions - Magnetic Fields Conducted Emission ( AC Power Leads - Voltage) Conducted Emission (AC andDC Power and Signal Leads - Current) Conducted Emission (Analog Voiceband Leads)

©2016Nokia

337


• • • • • • • •


Lightning and AC Power Fault Bonding and grounding DC Potential Difference Electrical Safety Ambient Temperature and Humidity Airborne Contaminant (outdoor level) Fire Resistance Corrosion

Furthermore, NEBS compliance guarantees highest reliability of the network equipment in Earthquake 4 zones.

4.23.4

Requirements Not applicable.

338

©2016Nokia

DN0978045Issue:04A


Flexi Multiradio BTS LTE Site Solution features from previous releases for RL10

5 Flexi Multiradio BTS LTE Site Solution features from previous releases for RL10 5.1 Introduction to the Flexi Multiradio BTS Site Solution features This section introduces the Flexi Multiradio BTS Site Solution features for LTE RL10. Further information on the features, including installation instructions, will eventually be available in PIC.

5.2 Cell-related features 5.2.1 5.2.1.1

LTE cell bandwidth features: LTE112,LTE114, and LTE115 Introduction These features are offered according to 3GPP-specified bit rates and supported UE capability. •

LTE112: Cell bandwidth - 20MHz offers full LTE capacity with 20 MHzLTE cellbandwidth

•

LTE114: Cell bandwidth - 10MHz offers support for the 10MHz LTE cell bandwidth LTE115: Cell bandwidth - 5MHzoffers support for the 5 MHzLTE cell bandwidth

•

5.2.1.2

Functional description The LTE cell/carrier bandwidth for each bandwidth option is set using a software configuration parameter.The RF hardware is prepared to support bandwidths up to 20 MHz, depending on the 3GPP band and 3GPP specification.

5.2.1.3

Benefits LTE can operate in a number of different frequency bands. High LTE BTS and cell average and peak data rates are offered according to 3GPP specifications and UE capability. offers the following cell bandwidth features:

5.2.1.4

Activating the feature This feature is license-based.

5.2.2

DN0978045Issue:04A

LTE75: Up to 3 cells per Flexi LTE BTS

©2016Nokia

339


5.2.2.1


Introduction The Flexi Multiradio BTS provides up to three-sector configurations for cost-efficient coverage building. In future releases, more sector options will be offered.

5.2.2.2

Benefits Three-sector sites typically provide the most cost efficient way of building coverage. The Flexi Multiradio BTS provides optimal support for three-sector sites.

5.2.2.3

Functional description The Flexi Multiradio BTS product architecture design is optimized for three-sector configurations. A typical three-sector BTS site can be built with just two modules: a System Module and a three-sector RF Module, with the maximum of 60 W per sector. Optional Downlink 2TX MIMO support can be added by adding another three-sector RF Module. The second RF Module for 2TX MIMO can be added later on-site when MIMO capacity is needed. The supported LTE BTS configurations are: • • • • • •

1 omni SIMO 1+1 SIMO 1+1+1 SIMO 1 omni with 2TX DL MIMO 1+1 with 2TX DL MIMO 1+1+1 with 2TX DL MIMO

All the above configurations use two-way diversity reception with MRC and the maximum of 60 W output power per sector. With 2TX MIMO, the output power per cell/sector is max 60 W + 60 W. The maximum TX power on each 3GPP RF band depends on the RF Module version.

5.2.3 5.2.3.1

LTE81: Cell range up to 13 km Introduction This feature offers 13 km cell radius for coverage building.

5.2.3.2

Benefits The 13 km cell radius enables cost-efficient coverage building while allowing reuse of common towers with existing mobile radio access technologies.

5.2.3.3

Functional description The Flexi Multiradio BTS implementation is able to handle propagation delays and synchronization for terminals that are located within the maximum of 13 km from the BTS. This is the physical distance, so in addition the system is able to cope with multipath signal components.

340

©2016Nokia

DN0978045Issue:04A


5.2.3.4


Management data This section lists the parameters related to LTE81: Cell range up to 13 km. Table 184

The parameters relatedto LTE81: Cell range up to 13 km.

Parameter name

5.2.4 5.2.4.1

MO Class

Description

Maximum Number Of Time LNBTS Alignment Command Retries

The number of times the Timing Advance Command will be retried before LTE MAC assumes the UE has gone Out-of-Synch.

Time Alignment Offset Margin For Scheduling

Determines time alignment offset limit for the uplink sceduler to stop considering the UE for scheduling.

LNBTS

LTE97: Cell radius max 77 km Introduction The Flexi Multiradio BTS cell radius is supported up to the maximum of 77 km by using cell parameter settings defined in 3GPP.

5.2.4.2

Benefits This feature offers extended cell coverage for rural and coastal areas using high antenna towers and high mountain site locations, covering the same cell area as the GSM extended cell. No new LTE sites are needed for rural coverage.

5.2.4.3

Functional description This feature enables the support of LTE cells of up to 77 km according to 3GPP BTS cell parameter settings. The actual obtained coverage depends on many practical parameters, for example the RF band in use, BTS and UE antenna height, network traffic load conditions, and radio conditions. Detailed network planning tools are needed to estimate the obtainable coverage probability for a specific BTS site and terrain.

5.2.4.4

Activating the feature The feature is activated by special software parameters, using standard Flexi Multiradio BTS System and RF Modules.

5.3 Antenna line features 5.3.1

DN0978045Issue:04A

LTE71: 2-way RX diversity (MRC)

©2016Nokia

341


5.3.1.1


Introduction This feature provides two-way receive diversity for enhanced uplink coverage.

5.3.1.2

Benefits Receiver diversity is a well-known, robust method for increasing the received signal strength and quality by effectively doubling the received signal power and thus improving the performance against noise. It cancels the signal dropouts caused by multipath fading.

5.3.1.3

Functional description Receiver diversity is a standard feature for Flexi Multiradio BTS configurations. The signals from the two receiver antennas are separately amplified and downconverted and finally combined in baseband processing using Maximum Ratio Combining (MRC). The Flexi Multiradio BTS is able to operate with limited uplink performance (UL coverage) with just one RX receiver in case one of the two RX signals is missing.

5.3.2 5.3.2.1

LTE160: Flexi Multiradio BTS 3GPP antenna tilt support Introduction The Flexi Multiradio BTS has integrated antenna tilt control hardware in the radio module to control the 3GPP tilt antennas.

5.3.2.2

Benefits The main benefits of remote electric tilt management are: •

•

•

•

it simplifies and speeds up the network optimization process, allowing the network to be optimized regularly and independently of engineering resources, site access or weather conditions it creates the capability to react to changing load patterns and to tune the network, ensuring optimal network performance for all services it eliminates the needfor site visits to tilt antennasand hence the need to turn off sites. This leads to considerable savings in operational costs and avoids the loss of revenue due to site downtime. it reduces the overall antenna stock holdingand improves logistics because of a radical reduction of antenna variants, thanks to the use of antennas with continuously variable downtilt.

In short, the antenna tilt feature delivers savings because less effort on tilting is required and better radio RF performance is achieved.

5.3.2.3

Functional description Antenna tilt is integrated into the RF Module of the Flexi Multiradio BTS. It feeds DC power to the antenna and controls the antenna tilting. This 3GPP-specified antenna tilting functionality does not require additional hardware.

342

©2016Nokia

DN0978045Issue:04A


5.3.2.4


Management data This sections lists the parameters related to LTE160: Flexi Multiradio BTS 3GPP antenna tilt support. Table 185

The parameters related toLTE160: Flexi Multiradio BTS 3GPP antenna tilt support.

Parameter name

Description

AL DC Voltage Enabled

ANTL

Defines if DC power is enabled/disabled for an antenna line.

Communication 3gpp Enabled

ANTL

Defines if device scan functionality is enabled/disabled for an capable 3GPP antenna line.

Angle

RET

Defines the elevation angle.

Calibrate

RET

Definestheusageof calibration.

Calibration Done

RET

Defines if calibration is done.

ConfigurationFile DL Needed RET

Defines if Configuration File DL is needed.

Configuration Done

RET

Defines if configuration is done.

Configuration File

RET

This parameter is used to store and transfer devicespecific configuration data to the BTS.

Manufacturer

RET

Definesthe manufacturer of the device.

MaxAngle

Mechanical Angle

DN0978045Issue:04A

MO class

RET

RET

Definestheminimum allowed electrical tilt value. Defines the mechanical tilt fixed by the geometry of the installation.

MinAngle

RET

Definestheminimum allowed electrical tilt value.

SWVersion

RET

DefinestheRETFirmware SW Version.

©2016Nokia

343


5.3.2.5



5.3.3 5.3.3.1

LTE899: Antenna Line Supervision Introduction The Flexi Multiradio BTS has integrated antenna line supervision in the Radio Module to control the antenna line condition by the Voltage Standing Wave Ratio (VSWR) measurement. The VSWR measurement can be done to a TX/RX branch antenna line only.

5.3.3.2

Benefits The antenna line monitoring integrated into the Flexi Multiradio BTS RF Module enables remote supervision of the antenna line without any additional hardware components required. The Flexi Multiradio BTS RF performance is optimized because no jumper cables and extra connectors are needed on the antenna line.

5.3.3.3

Functional description The antenna line supervision is integrated into the RF Module of the Flexi Multiradio BTS, and it measures the reflected RF power of the BTS TX antenna branch, defined as a Voltage Standing Wave Ratio (VSWR) measurement. In the Flexi Multiradio BTS, antenna line supervision is license-based and no additional hardware is required. In case 2TX MIMO is activated in the Flexi Multiradio BTS, both TX/RX antenna lines can be supervised. A separate VSWR alarm is reported from both active TX/RX antenna lines. The VSWR monitoring system is used for producing alarms for the antenna line condition against specified alarm limits. A minor alarm will be generated when the VSWR is 1.9 and a major alarm (cell down) will be generated when the VSWR is 2.6.

5.3.3.4


5.3.4 5.3.4.1

LTE94: Feederless site Introduction The feederless LTE BTS site is a site where the Flexi Multiradio BTS RF Module is located close to antennas, so traditional long antenna feeders are not needed.

5.3.4.2

Benefits The feederless site solution using standard Flexi Multiradio BTS IP65 RF and System Modules offers a flexible way to optimize BTS site performance. BTS site level savings are achieved because: •

344

it is easier to acquire new sites

©2016Nokia

DN0978045Issue:04A


• • • • •


co-siting with existing 2G and 3G base stations, feeders andantennas is easier no need of long and thick antenna feeders installations optimized DL and UL RF performance - coverage andcapacity - is achieved no MHAs are needed standard RF Modules are used in the feederless installation option,which simplifies logistics as well as the installation work itself.

One Flexi Multiradio BTS RF Module can support max 60 W for up to three sectors and cells. Two Flexi Multiradio BTS RF Modules can support max 60 W + 60 W 2TX MIMO for up to three sectors and cells. Three Flexi Multiradio BTS RF Modules can support max 60 W + 60 W 2TX MIMO for one sector with HW capable to support 4RX diversity.

5.3.4.3

Functional description At a feederless BTS site, the Flexi Multiradio BTS RF Module is located close to the antenna. The distance between the RF Module and the antenna is only a few meters, so no traditional feeder cables are required. The System Module can be freely located by an optical interface up to 200 meters away from the RF Module. Typically, the System Module is installed closer to the transmission termination point and other site support equipment, such as an existing BTS shelter, or inside a BTS or Site Support cabinet, at a location with easier access. The System and RF Modules can be installed indoors and outdoors.

5.3.5

Features related to mast head amplifiers The main advantage using close an MHA is toantenna compensate feederand losses thefeeders uplink if installation of the RF of Module to the is not for possible longinRF are therefore required. An MHA is used only with traditional sites where the antenna feeders are typically over 30 meters long. MHAs are not typically used at distributed and feederless sites, where the Flexi Multiradio BTS, RF Modules, or a Remote RF Head is installed close to the antennas. For traditional BTS sites requiring an MHA, the Flexi Multiradio BTS has integrated bias-T hardware in the Radio Module; this reduces the total site and installation cost because there is no need to install separate bias-T hardware components to each antenna line with jumper cables. The minimized antenna feeder length optimizes BTS site RF performance in downlink and uplink. No extra losses are caused by external bias-Ts, connectors and jumper cables.

5.3.5.1

LTE76: Support for legacy MHA The integrated bias-T hardware is used to control NSN-delivered legacy Nokia masthead amplifiers used with Ultrasite or Flexi WCDMA BTSs. The integrated bias-T feeds DC power to the MHA and controls the MHA DC power consumption. If the power consumption is out of specified limits, an alarm is generated. The MHA power feeding and MHA alarm control functionalities are license-based.

5.3.5.2

LTE155: Support for third-party MHA For third-party MHAs, support is decided case-by-case. In specific cases, it is possible to use an existing third-party MHA/TMA with the Flexi Multiradio BTS and to define the maximum power supply current limit for the MHAs. The alarm limit for the maximum

DN0978045Issue:04A

©2016Nokia

345



value of the supply current consumption of the MHAs can be set by the operator. The alarm limit values for the maximum current are 120 to 775 mA in 5 mA steps (12 V power supply). The measurement accuracy is +/- 20 mA.

5.3.5.3

LTE902: Flexi Multiradio BTS AISG MHA support The integrated bias-T hardware is used to control Nokia Siemens Networks delivered and approved AISG 2.0 MHAs. The bias-T feeds DC power to the MHA and controls the MHA DC power consumption. If the power consumption is out of specified limits, an alarm is generated. AISG has specified additional control functionality for MHA. This control is done over OOK (On-OFF Keying) modulation using the antenna feeder. The AISG 2.0 MHA power feeding and enhanced MHA alarm control is license-based and no additional hardware is required. Nokia Siemens Networks’ own MHAs coded with the AISG vendor code 'NK' are supported.

5.3.5.4

LTE810: Flexi Multiradio BTS dual MHA 2600 (FLHA) The Flexi Multiradio BTS dual Mast-Head Amplifier (FLHA) is a small tower-mounted amplifier for 2600 MHz at 3GPP band 7. Fewer BTS sites are needed for basic coverage building at the new 2600 MHz band because of improved uplink BTS site total RF performance. The 2600 MHz dual MHA has one-sector support for both TX/RX and diversity RX branch in one physical unit. The 3GPP band 7 is supported with 70 MHz bandwidth.

5.4 Flexi Multiradio BTS RF Modules 5.4.1

Introduction The hardware of the Flexi Multiradio BTS 3-sector RF Modules for LTE is identical to the existing Dual and Single Flexi WCDMA BTS RF Modules. The environmental protection class of the modules is IP65. The modules are 3U high with Flexi Multiradio BTS platform mechanics. The RF Modules are able to support one, two or three sectors with up to 60 W output power at the BTS antenna connector. They can be used as a powerful one-sector Remote Radio Head (RRH) with the maximum of 60 W + 60 W 2TX MIMO for one cell. The basic LTE configurations - 1 omni, 1+1, 1+1+1 with the maximum of 20 MHz LTE bandwidth and 1TX/2RX for two or more cells - are offered. Software licenses enable the 8, 20, 40 or 60W mode per sector. The Flexi Multiradio BTS RF Modules can be used in feederless and distributed BTS sites.

5.4.2

Benefits The Flexi Multiradio BTS 3-sector RF Modules offer the following benefits: •

• • •

346

the most cost, size, and weight optimized three-sector BTS site; easier installation, less visual impact industry-leading RF integration level software-configurable radio: the same RF Module for LTE, HSPA+ and WCDMA can be configured to support one, two or three sectors, or one sector with 2TX MIMO with optional 4-way uplink diversity

©2016Nokia

DN0978045Issue:04A


• • • •

5.4.3


the widest ambient temperature range: -35... +55 C the smallest power consumption and OPEX can be used as feederless site withone DC and 1-2 optical cables can be used as powerful one-sector RemoteRadio Heads (RRH) : 60 + 60 W 2TX MIMO with HW prepared for 4RX. A three-sector module is more cost-effective than three separate RF Heads because it is lighter and causes less wind load and visual impact, while requiring only one third of the DC and optical cabling.

LTE85: Flexi 3-sector RF Module 2600 (FRHA) The Flexi Multiradio BTS RF Module for 2600 MHz (FRHA) offers 3X60W output for the 3GPP band 7.

5.4.4

LTE99: Flexi 3-sector RF Module 1.7/2.1 (FRIE) The Flexi Multiradio BTS RF Module for 1.7/2.1 GHz (FRIE) provides 1.7 GHz UL and 2.1 GHz DL. The 3GPP bands 4 and 10 are supported and the RF bandwidth range is 60 MHz.

5.4.5

LTE437: Flexi 3-sector RF Module 800EU The Flexi Multiradio BTS RF Module for 800 MHz (FRMA) supports the 3GPP band 20.

5.4.6 5.4.6.1

LTE96: MIMO 2TX configuration with 3-sector RF Module Introduction Downlink 2TX MIMO up to three sectors is supported with two three-sector Radio Modules with up to 60 W + 60 W RF power per cell or sector.

5.4.6.2

Benefits Just two Flexi Multiradio BTS RF Modules are needed to build a high performance threesector site supporting 2TX downlink MIMO. The maximum output power is 60 W + 60 W per cell or sector. The other software-configurable RF TX output level options are 20 W + 20 W and 40 W + 40 W.

5.4.6.3

Functional description Two RF Modules can be configured to operate as parallel, so that each module provides one branch of the 2TX MIMO up to a three-sector site configuration. The maximum TX power on each 3GPP RF band depends on the RF Module version.

5.5 Flexi Multiradio BTS Remote Radio Heads

DN0978045Issue:04A

©2016Nokia

347


5.5.1


Benefits The one-sector Flexi Multiradio BTS Remote Radio Heads (RRHs) are able to support 2TX MIMO with high output power. The modules are IP65-protected, so they can be installed outdoors close to the antennas, maximizing the BTS site capacity and coverage for one sector.

5.5.2

Functional description Flexi Multiradio BTS RRH Modules offer the following main features: • • • • • • • • • • •

5.5.3

40W + 40W with two power amplifiers optimized for single sector deployment with 2TX MIMO optical chaining supported by the HW (two optical connectors) operating temperature range:-35 to +50 °C with convection cooling two external RX outputs (main and div with small SMA connectors) external alarms and outputs AISG2.0 Antenna Tilt Support with an external connector (RS485) MHA supported by both RX branches with adjustable 0...30dB LNAs other TX/RX branch with integrated Bias-T to support AISG2.0 MHA MHA SW support via integrated Bias-T VSWR monitoring on both TX branches.

LTE547: Flexi RRH 2TX 800EU Flexi Multiradio Remote RF Head (RRH) with 2TX for 3GPP band 20 at 800 MHz (so called Digital Dividend) RF band.

5.6 Cabinets and other Flexi Multiradio BTS hardware 5.6.1 5.6.1.1

LTE79: Flexi Indoor (FCIA) and Outdoor (FCOA) Cabinets Introduction Optional Indoor (FCIA) and Outdoor (FCOA) Cabinets are available for Flexi Multiradio BTS installations where additional protection is needed or where the large number of modules prevents the stacked installation. The cabinets are introduced here only briefly; further information, for example installation instructions, is available in PIC as part of the LTE Radio Access, Rel. RL, Operating Documentation.

5.6.1.2

Benefits The Flexi Multiradio BTS Indoor Cabinet (FCIA) provides additional installation support for large configurations where the stacked installation is not possible.The Flexi Multiradio BTS Outdoor Cabinet (FCOA) provides additional shielding for the BTS site and provides space for auxiliary devices, such as a high-capacity battery backup unit (BBU).

348

©2016Nokia

DN0978045Issue:04A


5.6.1.3


Functional description The Flexi Multiradio BTS Indoor Cabinet (FCIA)

The Flexi Multiradio BTS multipurpose Indoor Cabinet (FCIA) is an option for indoor sites where a cabinet is needed. It provides 36 U space for the Flexi Multiradio BTS modules and for optional site support. The main applications are: •

the future-proof multipurpose cabinet can house two or three separate BTSs, for example WCDMA and/or EDGE, and/or Wimax, and/or LTE

•

several hours of sharedbattery backup for a single cabinet with oneor two BTSs (WCDMA, EDGE, WiMax or LTE) space for the operator's own 19-inch units earthquake protection forFlexi Multiradio BTSconfigurations having more than six modules (WCDMA, EDGE, WiMax or LTE).

• •

The optional Indoor Cabinet (FCIA) can include the following optional items: •

• • •

Indoor long-term Battery Backup solution (MIBBU), 62 Ah or 92 Ah battery with the indoor installation cable kit (FMBB). For more information, see section LTE78: Flexi AC/DC with Battery Power Module. Fire Detector (FCDA) EAC IP55 connection box (FSEB), neededto connect FCDA and MIBBU alarms. cabinet dimensions: 1800 x600 x 600 mm (H x W x D).

The Flexi Multiradio BTS Outdoor Cabinet (FCOA)

The Flexi Multiradio BTS System and RF Modules are IP65 weather-protected. The Flexi Multiradio BTS multipurpose Outdoor Cabinet (FCOA) is an option for sites where further protection is needed. The main applications are: • •

•

• •

•

module and cable protection against vandalism and wind-driven rain the future-proof multipurpose cabinet can house two or three separate BTSs, for example WCDMA and/or EDGE, and/or WiMax, and/or LTE several hours of sharedbattery backup for a single cabinet with oneor two BTSs (WCDMA, EDGE, WiMax or LTE) space (4U) for the operator's own indoor IP20 class units an optional air filter for harsh environmental conditions, for example salty coastal areas earthquake protection forFlexi Multiradio BTSconfigurations having more than six modules (WCDMA, EDGE, WiMax or LTE).

The optional outdoor cabinet (FCOA) can include the following optional items: •

• • •

•

DN0978045Issue:04A

Outdoor Site Support Module(FCSA with optional indoor MIBBU): 62Ah or 92 Ah long term battery with outdoor installation cable kit (FMBA). For more information, see section LTE78: Flexi AC/DC with Battery Power Module. Air filter (FCFA) Fire detector (FCDA) EAC IP55 connection box(FSEB), needed to connect the FCDA, FCFA and FCSA alarms. FCOA includes a lock and a door alarm switch that is connected to FSEB. cabinet dimensions: 1550 x770 x 770 mm (H x W x D). With optional air filter (FCFA): 1550 x 770 x 930 mm (H x W x D). With air filter (FCFA) and wind breaker: 1550 x 770 x 1020 mm (H x W x D).

©2016Nokia

349


5.6.2 5.6.2.1


LTE78: Flexi AC/DC with Battery Power Module (FPMA) Introduction The Flexi Multiradio BTS Power Module (FPMA) offers an IP55-protected Flexi Multiradio BTS AC/DC rectifier with an optional Battery Module with multiple installation options: outdoors or indoors, on a wall, pole, the floor or a cabinet.

5.6.2.2

Benefits The Flexi Multiradio BTS Power Module (FPMA) is a slim 3U high flexible general purpose Flexi Multiradio BTS Power Module that can be installed in virtually any cabinet. The AC/DC and Battery Module can be installed in the same installation conditions as the other Flexi Multiradio BTS Modules. No separate equipment room is needed for protecting the installed site against mains failures.

5.6.2.3

Functional description The Flexi Multiradio BTS AC/DC and battery module consists of the following main elements: the Flexi Multiradio BTS Power Module (FPMA), which is the casing for the AC input and DC output cable connector box and a support frame for the actual power submodules and the Flexi Multiradio BTS Power Battery Sub-Module (FPAA). The main function of the FPAA is to provide the BTS modules with 48 V DC power from an AC current. The function of the FPDA, a standalone 2 kW DC/DC module with 2 U height, is to generate BTS internal 48 V DC power from the external 24 V DC. The FPMA can house up to three AC/DC rectifiers, each of which has an output power of 1 kW 48 V DC power. The FPMA can house up to three battery sub-modules, which can provide up to one hour of battery back-up time when the AC power mains is down on a typical 1+1+1 Flexi Multiradio BTS site. Two Hardware Alarms can be connected from the FPMA directly to the Flexi Multiradio BTS System Module using an Ethernet RJ45 cable.

5.6.3 5.6.3.1

LTE82: High-capacity Flexi System Module (FSME) Introduction The Flexi Multiradio BTS System Module (FSME) provides all the common and baseband processing functions at the BTS site. The high-capacity Flexi Multiradio BTS System Module (FSME) can support a typical three-sector Flexi Multiradio LTE BTS with up to 20 MHz cell bandwidth.

5.6.3.2

Benefits The high-capacity Flexi Multiradio BTS System Module (FSME) is the most costoptimized and future-proof multimode System Module for high-capacity WCDMA/HSPA/LTE sites offering maximum capacity with minimum required site space. FSME is software-configurable. All the common functions at a BTS site - baseband processing, transport, power distribution and fans - are provided in a compact IP65 weather-proof 3U module. The module can operate in ambient temperatures ranging from -35C to +55C. No cabinet is needed, as the module can be installed to a wall or pole or an existing third-party BTS or site support cabinet.

350

©2016Nokia

DN0978045Issue:04A


5.6.3.3


Functional description The architecture of FSME allows for product capacity variants of one, two or three baseband processing units per one System Module. FSME is able to support three LTE cells with the maximum of 20 MHz carrier bandwidth with 2TX MIMO, or six LTE cells with the maximum of 10 MHz carrier bandwidth with 2TX MIMO. The FSME Module provides the following functionality: • • • • • •

• •

• • •

BTS and site-level O&M processing LTE eNB telecom and RRM functionality transport interface with transport sub-module external alarms and controls (EACs) timing and synchronization site 48 V DC input power interface and 48 V DC distribution to other modules with fuses Ethernet Switch with 1G and 100 M Ethernet interfaces 5 optical interfaces, used to connect Radio Modules and the second System Module in the extension mode RP3 summing/distribution function 2 redundant fans IP65 mechanics with -35 to +55 C ambient temperature.

5.7 Power support features 5.7.1 5.7.1.1

LTE900: Flexi Multiradio BTS 40 W power support Introduction Flexi Multiradio BTS 40 W RF Power license activates 40 W power mode to one TX Power Amplifier of Flexi Multiradio BTS RF Module in LTE mode.

5.7.1.2

Benefits The one and the same Flexi RF Module hardware can support 8, 20, 40 and 60 W RF power modes with SW licenses. Therefore there is no need for separate RF Module power variants. No site visits are needed because RF capacity increase is possible with the "Pay as you grow" - the no-site-visit principle. 60 W in LTE is needed especially at higher RF bandwidths, for example, at 15 MHz or 20 MHz bandwidth in order to keep coverage with high capacity. The one RF Module hardware model brings savings in spare part stock, logistics, and maintenance.

5.7.1.3

Functional description This feature is needed for Flexi Multiradio 3-sector RF Module for all RF band variants when 60 W RF mode per TX path is required.

DN0978045Issue:04A

©2016Nokia

351



In a SIMO (Single 1TX) BTS configuration one 60 W Power license is needed per sector. In a 2TX MIMO (two active TX paths) BTS configuration two 60 W Power licenses are needed per sector. Required hardware: • •

5.7.2 5.7.2.1

Flexi Multiradio 3-sector RF Module for all RF band variants. Tentatively, 60 W power mode not needed for any Remote RadioHead (RRH) 2TX (30+30W) MIMO product.

LTE901: Flexi Multiradio BTS 8 W power support Introduction Flexi Multiradio BTS 8 W RF Power license enables 8 W RF power mode operation with Flexi Multiradio BTS RF Module in LTE mode.

5.7.2.2

Benefits The one and the same Flexi Multiradio BTS hardware variant can be used at macro and micro/pico sites. Logistics and spare part costs are lower. Hot spot indoor and outdoor capacity and coverage can be built cost-efficiently using small Flexi Modules without cabinets or new costly macro BTS sites.

5.7.2.3

Functional description This feature makes it possible to limit the Flexi BTS RF power to 8 W with the 60 W RF Module, and limit the maximum allowed RF exposure from the BTS especially at micro sites. The RF exposure limits depend on national or local legislation in each coutry. The operator can select the 8 W module in the commissioning phase of Flexi BTS. The Flexi BTS RF Module internally limits the output power to 8 W with a control cycle of less than 1 ms. Configurations: • •

5.7.3 5.7.3.1

1, 1+1, 1+1+1 @ 8 W 1TX and 2 RX with 3-sector RF Module. 1 sector 8+8 W 2TX/2RX MIMO with 3-sector RF Module.

LTE903: Flexi Multiradio BTS 60 W power support Introduction Flexi Multiradio RF Power license activates the 60 WisRF mode to one TX path of FlexiBTS BTS 60 RFWModule in LTE mode. 60 W TX power at power the antenna connector of Flexi BTS, that is, RF Module TX/RX port. Support for maximum 60 W TX power mode on each 3GPP RF band depends on the RF Module version.

352

©2016Nokia

DN0978045Issue:04A


5.7.3.2


Benefits The one and the same Flexi RF Module HW can support 8, 20, 40 and 60 W RF power modes with SW licenses. Therefore, there is no need for separate RF Module power variants. No site visits are needed because RF capacity increase is possible with the "Pay as you grow" - the no-site-visits principle. 60 W in LTE is needed especially at higher RF bandwidths, for example, at 15 MHz or 20 MHz bandwidth in order to keep coverage with high capacity. The one RF Module hardware model brings savings in spare part stock, logistics, and maintenance.

5.7.3.3

Functional description This feature is needed for Flexi Multiradio 3-sector RF Module for all RF band variants when 60 W RF mode per TX path is required. In a SIMO (Single 1TX) BTS configuration one 60 W Power license is needed per sector. In a 2TX MIMO (two active TX paths) BTS configuration, two 60 W Power licences are needed per sector. Required hardware: • •

5.7.4 5.7.4.1

Flexi Multiradio 3-sector RF Module for all RF band variants. Tentatively, 60 W power mode not needed for any Remote RadioHead (RRH) 2TX (30+30W) MIMO product.

LTE904: Flexi LTE BTS Branch Activation Introduction The Downlink TX Branch Activation (BA) license is needed to activate one TX of the Flexi 3-sector RF Module. One branch activation license activates one TX Power Amplifier in the default 20 W RF power mode. The default 20 W TX power is at the antenna connector of the Flexi Multiradio BTS, at the TX/RX port of the RF Module. Three branch activation licenses are needed to activate all three TX paths of the 3-sector RF Module.

5.7.4.2

Benefits A single Flexi RF Module can be used flexibly for one, two or three sector configurations by software license activation. The same RF Module can also be configured and used as one sector remote 2TX MIMO RF Module (60 + 60 W). Because there is no need for separate two and three sector RF Modules, savings are achieved in logistics, spare parts andone, maintenance.

5.7.4.3

Functional description In order to activate any LTE cells in a Flexi 3-sector RF Module, at least one Branch Activation license is needed for each sector. In a SIMO (Single 1TX) BTS configuration, one Branch Activation license is needed per active sector. In a 2TX MIMO (two active TXs) BTS configuration, two Branch Activation licenses are needed per sector. This

DN0978045Issue:04A

©2016Nokia

353



license is needed for all frequency variants of the Flexi Multiradio 3-sector RF Module. The Remote RF Head (RRH) 2TX MIMO product requires one Branch Activation license for each active TX branch, that is, two Branch Activation licenses are needed for the 20 W + 20 W 2TX MIMO operation mode per sector and per each RRH.

354

©2016Nokia

DN0978045Issue:04A

lte_fd_rel_10

Recommend Documents