Nokia LTE RL10 Features

LTE Radio Access, Rel. RL60, Operating Documentation, Issue 03 Feature Descriptions RL10 DN0978045 Issue 02B Approval Date 2012-09-30

Feature Descriptions RL10

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Solutions and Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Solutions and Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Solutions and Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Solutions and Networks and the customer. However, Nokia Solutions and Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Solutions and Networks will, if deemed necessary by Nokia Solutions and Networks, explain issues which may not be covered by the document. Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Solutions and Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR 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. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. NSN is a trademark of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © Nokia Solutions and Networks 2012. 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 Solutions and Networks 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 Solutions and Networks for any additional information.

2

DN0978045

Issue: 02B


Table of Contents This document has 131 pages

Summary of Changes.................................................................. 15

1 1.1

Feature Descriptions RL10.......................................................... 16 Radio resource management and telecom features from previous releases for RL20.........................................................................16 LTE28: Closed loop UL power control..........................................16 Introduction to the feature............................................................ 16 Benefits........................................................................................ 16 End user benefits......................................................................... 16 Operator benefits......................................................................... 16 Requirements...............................................................................17 Software requirements................................................................. 17 Hardware requirements................................................................17 Functional description.................................................................. 17 Functional details......................................................................... 17 Messages and information elements........................................... 19 System impacts............................................................................ 20 Interdependencies between features........................................... 20 Impacts on interfaces................................................................... 20 Impacts on performance and capacity......................................... 20 User interface...............................................................................20 Parameters...................................................................................20 Measurements and counters........................................................23 Activating The Feature................................................................. 24 Abbreviations............................................................................... 24 0 – Z............................................................................................. 24 LTE30: CQI adaption (DL)............................................................24 Introduction to the feature............................................................ 24 Benefits........................................................................................ 25 Requirements...............................................................................25 Software requirements................................................................. 25 Hardware requirements................................................................25 Functional description.................................................................. 25 Functional details......................................................................... 25 System impacts............................................................................ 26 Interdependencies between features........................................... 26 User interface...............................................................................26 Parameters...................................................................................26 Activating The Feature................................................................. 27 LTE37: Ciphering and LTE38: Integrity protection........................27 Introduction to the feature............................................................ 27 Benefits........................................................................................ 28

1.1.1 1.1.1.1 1.1.1.2 1.1.1.2.1 1.1.1.2.2 1.1.1.3 1.1.1.3.1 1.1.1.3.2 1.1.1.4 1.1.1.4.1 1.1.1.4.1.1 1.1.1.5 1.1.1.5.1 1.1.1.5.2 1.1.1.5.3 1.1.1.6 1.1.1.6.1 1.1.1.6.2 1.1.1.7 1.1.1.8 1.1.1.8.1 1.1.2 1.1.2.1 1.1.2.2 1.1.2.3 1.1.2.3.1 1.1.2.3.2 1.1.2.4 1.1.2.4.1 1.1.2.5 1.1.2.5.1 1.1.2.6 1.1.2.6.1 1.1.2.7 1.1.3 1.1.3.1 1.1.3.2

Issue: 02B

DN0978045

3


1.1.3.3 1.1.3.3.1 1.1.3.3.2 1.1.3.4 1.1.3.4.1 1.1.3.4.2 1.1.3.4.3 1.1.3.5 1.1.3.5.1 1.1.3.5.2 1.1.3.5.3 1.1.3.6 1.1.3.6.1 1.1.3.7 1.1.4 1.1.4.1 1.1.4.2 1.1.4.3 1.1.4.3.1 1.1.4.3.2 1.1.4.4 1.1.4.4.1 1.1.4.5 1.1.4.5.1 1.1.4.6 1.1.4.7 1.1.4.7.1 1.1.4.7.2 1.1.4.7.3 1.1.4.8 1.1.4.9 1.1.4.9.1 1.1.5 1.1.5.1 1.1.5.2 1.1.5.2.1 1.1.5.2.2 1.1.5.3 1.1.5.3.1 1.1.5.3.2 1.1.5.4 1.1.5.4.1 1.1.5.4.2 1.1.5.4.2.1

4

Requirements...............................................................................28 Software requirements................................................................. 28 Hardware requirements................................................................28 Functional description.................................................................. 29 Functional overview..................................................................... 29 Security keys................................................................................30 Messages and information elements........................................... 33 System impacts............................................................................ 35 Interdependencies between features........................................... 35 Impacts on network elements...................................................... 35 Impacts on system performance and capacity.............................35 User interface...............................................................................35 Parameters...................................................................................35 Activating The Feature................................................................. 36 LTE43: Support of 64 QAM in DL, LTE788: Support of 16 QAM (UL), LTE793: Support of 16 QAM (DL)....................................... 36 Introduction to the feature............................................................ 36 Benefits........................................................................................ 36 Requirements...............................................................................37 Software requirements................................................................. 37 Hardware requirements................................................................37 Functional description.................................................................. 38 Functional details......................................................................... 38 System impacts............................................................................ 38 Interdependencies between features........................................... 38 Sales information......................................................................... 38 User interface...............................................................................39 Managed objects..........................................................................39 Parameters...................................................................................39 Measurements and counters........................................................39 Activating The Features............................................................... 41 Abbreviations............................................................................... 41 0 – Z............................................................................................. 41 LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas................................ 43 Introduction to the feature............................................................ 43 Benefits........................................................................................ 43 End user benefits......................................................................... 43 Operator benefits......................................................................... 43 Requirements...............................................................................43 Software requirements................................................................. 44 Hardware requirements................................................................44 Functional description.................................................................. 44 Functional overview..................................................................... 44 Downlink adaptive open loop MIMO for two antennas.................44 Receive diversity.......................................................................... 46

DN0978045

Issue: 02B


1.1.5.4.2.2 1.1.5.4.2.3 1.1.5.4.3 1.1.5.4.4 1.1.5.5 1.1.5.5.1 1.1.5.5.2 1.1.5.5.3 1.1.5.5.4 1.1.5.6 1.1.5.7 1.1.5.7.1 1.1.5.7.2 1.1.5.7.3 1.1.5.7.4 1.1.5.8 1.2 1.2.1 1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.3.1 1.2.1.3.2 1.2.1.4 1.2.1.4.1 1.2.1.5 1.2.1.6 1.2.1.6.1 1.2.1.6.2 1.2.1.6.3 1.2.1.7 1.2.2 1.2.2.1 1.2.2.2 1.2.2.3 1.2.2.3.1 1.2.2.3.2 1.2.2.4 1.2.2.4.1 1.2.2.4.1.1 1.2.2.4.2 1.2.2.4.3 1.2.2.5

Issue: 02B

Transmit diversity......................................................................... 46 Downlink open loop MIMO........................................................... 47 Transmit diversity for two antennas..............................................48 Open loop spatial multiplexing..................................................... 48 System impacts............................................................................ 49 Interdependencies between features........................................... 49 Impacts on interfaces................................................................... 49 Impacts on network and network element management tools..... 49 Impacts on system performance and capacity.............................49 Sales information......................................................................... 49 User interface...............................................................................49 Managed Objects......................................................................... 50 Parameters...................................................................................50 Alarms.......................................................................................... 51 Measurements and counters........................................................51 Activating the Feature.................................................................. 51 Transport and transmission features from previous releases for RL20.............................................................................................51 LTE713: Synchronous Ethernet................................................... 51 Introduction to the Feature........................................................... 51 Benefits........................................................................................ 51 Requirements...............................................................................51 Software Requirements................................................................51 Hardware Requirements.............................................................. 52 Functional Description..................................................................52 Synchronization Status Messages (SSM)....................................52 Sales Information......................................................................... 53 User Interface...............................................................................53 Parameters...................................................................................53 Alarms.......................................................................................... 54 Measurements and Counters.......................................................54 Activating and Configuring the Feature........................................54 LTE132: VLAN based traffic differentiation ................................. 54 Introduction to the Feature........................................................... 54 Benefits........................................................................................ 54 Requirements...............................................................................55 Software Requirements................................................................55 Hardware Requirements.............................................................. 55 Functional Description..................................................................55 Network Scenarios with VLAN based Traffic Differentiation.........56 X2 interface via IPsec Star Configuration.................................... 57 VLAN based Traffic Differentiation: Mapping of DL Packets in the Security Gateway......................................................................... 58 VLAN based Traffic Differentiation: Mapping of DL Packets in the VLAN Gateway.............................................................................59 Sales Information......................................................................... 59

DN0978045

5


1.2.2.6 1.2.2.6.1 1.2.2.6.2 1.2.2.6.3 1.2.2.7 1.2.3 1.2.3.1 1.2.3.1.1 1.2.3.1.2 1.2.3.1.3 1.2.3.1.3.1 1.2.3.1.3.2 1.2.3.1.3.3 1.2.3.1.4 1.2.3.1.5 1.2.3.1.6 1.3 1.3.1 1.3.1.1 1.3.1.2 1.3.1.3 1.3.1.3.1 1.3.1.3.2 1.3.1.4 1.3.1.4.1 1.3.1.5 1.3.1.5.1 1.3.1.5.2 1.3.1.5.3 1.3.1.5.4 1.3.1.6 1.3.1.7 1.3.1.8 1.3.2 1.3.2.1 1.3.2.2 1.3.2.3 1.3.2.3.1 1.3.2.3.2 1.3.2.3.3 1.3.2.4 1.3.2.4.1 1.3.2.4.1.1

6

User Interface...............................................................................59 Parameters...................................................................................59 Alarms.......................................................................................... 60 Measurements and Counters.......................................................60 Activating and Configuring the Feature........................................61 LTE134: Timing over packet.........................................................61 LTE134: Timing over Packet........................................................ 61 Benefits........................................................................................ 61 Requirements...............................................................................61 Functional Description..................................................................62 ToP Master................................................................................... 62 ToP Slave..................................................................................... 62 Support of IEEE 1588 Event Messages.......................................63 Management data........................................................................ 64 Sales information......................................................................... 65 Activating and configuring the feature..........................................65 Operability features from previous releases for RL20..................65 LTE150: LTE OAM Transport Layer Security (TLS) Support........65 Introduction to the feature............................................................ 65 Benefits........................................................................................ 65 Requirements...............................................................................66 Software requirements................................................................. 66 Hardware requirements................................................................66 Functional description for LTE OAM Transport Layer Security (TLS) Support...............................................................................66 Secure BTS Site Manager connection......................................... 69 System impact..............................................................................69 Interdependencies between features........................................... 69 Impact on interfaces.....................................................................69 Impact on network and network element management tools.......69 Impact on system performance and capacity...............................69 Sales information......................................................................... 69 Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support.........................................................................................70 Alarms for LTE150: LTE OAM Transport Layer Security (TLS) Support.........................................................................................70 LTE432: Cell Outage Detection....................................................71 Introduction.................................................................................. 71 Benefits........................................................................................ 71 Requirements...............................................................................71 Software Requirements for LTE432............................................. 71 Software Requirements for LTE502............................................. 71 Hardware Requirements.............................................................. 71 Functional Description..................................................................72 LTE432: Cell Outage Detection....................................................72 Failure Scenarios......................................................................... 72

DN0978045

Issue: 02B


1.3.2.4.1.2 1.3.2.4.2 1.3.2.5 1.3.2.5.1 1.3.2.6 1.3.2.7 1.3.2.7.1 1.3.2.7.1.1 1.3.2.7.2 1.3.2.7.2.1 1.3.2.7.3 1.3.2.8 1.3.2.9 1.3.2.10 1.3.2.10.1 1.3.3 1.3.3.1 1.3.3.2 1.3.3.2.1 1.3.3.3 1.3.3.3.1 1.3.3.3.2 1.3.3.4 1.3.3.4.1 1.3.3.4.1.1 1.3.3.4.1.2 1.3.3.4.1.3 1.3.3.5 1.3.3.5.1 1.3.3.6 1.3.3.7 1.3.3.8 1.3.3.8.1 1.3.4 1.3.4.1 1.3.4.1.1 1.3.4.1.2 1.3.4.2 1.3.4.2.1 1.3.4.2.2 1.3.4.3 1.3.4.3.1

Issue: 02B

Alarm Generation......................................................................... 73 LTE502: Cell outage triggered reset.............................................73 System Impacts............................................................................74 Interdependencies between Features..........................................74 Sales Information......................................................................... 74 User Interface...............................................................................74 Parameters for LTE432: Cell outage detection............................ 74 LTE502: Cell outage triggered reset.............................................75 Alarms for LTE432: Cell outage detection....................................75 Alarms for LTE502: Cell outage triggered reset........................... 76 Measurements and Counters for LTE432: Cell outage detection.... 76 System Responses to Failures.................................................... 77 Activating the Feature.................................................................. 77 Abbreviations............................................................................... 77 0 – Z............................................................................................. 77 LTE539: Central ANR...................................................................78 Introduction.................................................................................. 78 Benefits........................................................................................ 78 Operator Benefits......................................................................... 78 Requirements...............................................................................78 Software Requirements................................................................78 Hardware Requirements.............................................................. 79 LTE539: Central ANR...................................................................79 Functional Overview/Details.........................................................79 NetAct Optimizer.......................................................................... 79 NetAct Configurator......................................................................83 Integration in the Auto configuration Workflow.............................84 System Impacts............................................................................84 Interdependencies Between Features......................................... 84 Sales Information......................................................................... 85 Activating and Configuring the Feature........................................85 Abbreviations............................................................................... 85 0 – Z............................................................................................. 85 LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA)........86 Introduction to the feature............................................................ 86 LTE665: LTE Certificate Management......................................... 86 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) ......................................................... 86 Benefits........................................................................................ 86 LTE665: LTE Certificate Management......................................... 86 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA).......................................................... 86 Requirements...............................................................................86 Software requirements................................................................. 86

DN0978045

7


1.3.4.3.2 1.3.4.4 1.3.4.4.1 1.3.4.4.2 1.3.4.5 1.3.4.6 1.3.4.7 1.3.4.7.1 1.3.4.7.2 1.3.4.8 1.3.5 1.3.5.1 1.3.5.2 1.3.5.3 1.3.5.3.1 1.3.5.3.2 1.3.5.4 1.3.5.4.1 1.3.5.4.2 1.3.5.4.3 1.3.5.4.3.1 1.3.5.4.4 1.3.5.5 1.3.5.6 1.3.5.7 1.3.5.7.1 1.3.5.7.2 1.3.5.8 1.3.6 1.3.6.1 1.3.6.2 1.3.6.3 1.3.6.3.1 1.3.6.3.2 1.3.6.4 1.3.6.5 1.3.6.6 1.3.6.7 1.3.6.7.1 1.3.6.8 1.3.7 1.3.7.1 1.3.7.2

8

Hardware requirements................................................................87 Functional description for certificate management.......................87 LTE665: LTE Certificate Management......................................... 87 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA).......................................................... 91 System impacts............................................................................ 93 Sales information......................................................................... 93 User interface...............................................................................93 Parameters for LTE665: LTE Certificate Management.................93 Alarms for LTE665: LTE Certificate Management........................ 94 Activating and configuring the feature..........................................95 LTE666: LTE User Account Management.................................... 95 Introduction to the feature............................................................ 95 Benefits........................................................................................ 95 Requirements...............................................................................96 Software Requirements................................................................96 Hardware Requirements.............................................................. 96 Functional description for user security........................................96 Authentication and authorization..................................................96 Disabling user accounts in NetAct............................................... 97 User management........................................................................97 Mass updating of eNB local user accounts.................................. 97 Audit trail...................................................................................... 97 System impacts............................................................................ 98 Sales information......................................................................... 98 User interface...............................................................................99 Parameters for LTE666: LTE User Account Management........... 99 Alarms for LTE666: LTE User Account Management...................99 Activating and configuring the feature........................................100 LTE679: LTE Local User Account Management........................ 100 Introduction to the feature.......................................................... 100 Benefits...................................................................................... 100 Requirements.............................................................................100 Software requirements............................................................... 100 Hardware requirements..............................................................101 Functional description for LTE Local User Account Management... 101 System impacts..........................................................................101 Sales information....................................................................... 101 User interface.............................................................................101 Parameters for LTE679: LTE Local User Account Management...... 101 Activating the feature................................................................. 101 LTE689: LTE IPsec Support....................................................... 101 Introduction to the feature.......................................................... 101 Benefits...................................................................................... 102

DN0978045

Issue: 02B


1.3.7.3 1.3.7.3.1 1.3.7.3.2 1.3.7.4 1.3.7.4.1 1.3.7.5 1.3.7.6 1.3.7.7 1.3.7.7.1 1.3.7.7.2 1.3.7.7.3 1.3.7.8 1.3.8 1.3.8.1 1.3.8.2 1.3.8.3 1.3.8.3.1 1.3.8.3.2 1.3.8.4 1.3.8.4.1 1.3.8.4.2 1.3.8.4.3 1.3.8.5 1.3.8.6 1.3.8.7 1.3.8.7.1 1.3.8.7.2 1.3.8.8 1.3.9 1.3.9.1 1.3.9.2 1.3.9.3 1.3.9.3.1 1.3.9.3.2 1.3.9.4 1.3.9.5 1.3.9.6 1.3.9.7 1.3.9.7.1 1.3.9.8 1.3.10 1.3.10.1 1.3.10.2 1.3.10.3

Issue: 02B

Requirements.............................................................................102 Software requirements............................................................... 102 Hardware requirements..............................................................102 Functional description for IPsec Support................................... 103 Transport security.......................................................................104 System impacts..........................................................................104 Sales information....................................................................... 104 User interface.............................................................................105 Parameters for LTE689: LTE IPsec Support.............................. 105 Alarms for LTE689: LTE IPsec Support......................................108 Counters for LTE689: LTE IPsec Support.................................. 109 Activating and configuring the feature........................................109 LTE692: LTE Firewall Support....................................................110 Introduction to the feature...........................................................110 Benefits.......................................................................................110 Requirements............................................................................. 110 Software requirements............................................................... 110 Hardware requirements.............................................................. 110 Functional description for LTE Firewall Support......................... 110 Firewall functionality................................................................... 111 Firewall filter............................................................................... 113 Logging.......................................................................................113 System impacts.......................................................................... 114 Sales information........................................................................114 User interface............................................................................. 114 Parameters for LTE692: LTE Firewall Support........................... 114 Counters for LTE692: LTE Firewall Support............................... 114 Activating and configuring the feature........................................ 115 LTE746: IP based filtering for BTS Site Support Equipment...... 115 Introduction to the feature...........................................................115 Benefits.......................................................................................115 Requirements............................................................................. 115 Software requirements............................................................... 115 Hardware requirements.............................................................. 116 Functional description for IP based filtering for BTS Site Support Equipment.................................................................................. 116 System impacts.......................................................................... 116 Sales information........................................................................116 User interface............................................................................. 116 Parameters for LTE746: IP based filtering for BTS Site Support Equipment.................................................................................. 116 Activating the feature..................................................................118 LTE913: LTE NEBS compliant OMS.......................................... 118 Introduction to the Feature......................................................... 118 Benefits.......................................................................................118 Functional Description................................................................ 118

DN0978045

9


1.3.10.4 1.4 1.4.1 1.4.2 1.4.2.1 1.4.2.1.1 1.4.2.1.2 1.4.2.1.3 1.4.2.1.4 1.4.2.2 1.4.2.2.1 1.4.2.2.2 1.4.2.2.3 1.4.2.2.4 1.4.3 1.4.3.1 1.4.3.1.1 1.4.3.1.2 1.4.3.1.3 1.4.3.2 1.4.3.2.1 1.4.3.2.2 1.4.3.2.3 1.4.3.2.4 1.4.3.2.5 1.4.3.3 1.4.3.3.1 1.4.3.3.2 1.4.3.3.3 1.4.4 1.4.4.1 1.4.4.2 1.4.4.3 1.4.4.4 1.4.4.5 1.4.4.6 1.4.4.6.1 1.4.4.6.2 1.4.4.6.3 1.4.5 1.4.5.1 1.4.6 1.4.6.1 1.4.6.1.1 1.4.6.1.2

10

Requirements............................................................................. 119 Flexi Multiradio BTS LTE Site Solution features from previous releases for RL20....................................................................... 119 Introduction to the Flexi Multiradio BTS Site Solution features.. 119 Cell-related features...................................................................120 LTE cell bandwidth features: LTE112,LTE114, and LTE115....... 120 Introduction................................................................................ 120 Functional description................................................................ 120 Benefits...................................................................................... 120 Activating the feature................................................................. 120 LTE97: Cell radius max 77 km................................................... 120 Introduction................................................................................ 120 Benefits...................................................................................... 120 Functional description................................................................ 120 Activating the feature................................................................. 121 Antenna line features................................................................. 121 LTE71: 2-way RX diversity (MRC)..............................................121 Introduction................................................................................ 121 Benefits...................................................................................... 121 Functional description................................................................ 121 LTE160: Flexi Multiradio BTS 3GPP antenna tilt support.......... 121 Introduction................................................................................ 121 Benefits...................................................................................... 121 Functional description................................................................ 122 Management data...................................................................... 122 Activating the feature................................................................. 123 LTE94: Feederless site...............................................................123 Introduction................................................................................ 123 Benefits...................................................................................... 123 Functional description................................................................ 123 Flexi Multiradio BTS RF Modules...............................................124 Introduction................................................................................ 124 Benefits...................................................................................... 124 LTE85: Flexi 3-sector RF Module 2600 (FRHA).........................124 LTE99: Flexi 3-sector RF Module 1.7/2.1 (FRIE)....................... 124 LTE437: Flexi 3-sector RF Module 800EU.................................124 LTE96: MIMO 2TX configuration with 3-sector RF Module........ 125 Introduction................................................................................ 125 Benefits...................................................................................... 125 Functional description................................................................ 125 Flexi Multiradio BTS Remote Radio Heads................................125 Benefits...................................................................................... 125 Cabinets and other Flexi Multiradio BTS hardware....................125 LTE79: Flexi Indoor (FCIA) and Outdoor (FCOA) Cabinets....... 125 Introduction................................................................................ 125 Benefits...................................................................................... 125

DN0978045

Issue: 02B


1.4.6.1.3 1.4.6.2 1.4.6.2.1 1.4.6.2.2 1.4.6.2.3 1.4.6.3 1.4.6.3.1 1.4.6.3.2 1.4.6.3.3 1.4.7 1.4.7.1 1.4.7.2 1.4.7.3 1.4.8 1.4.8.1 1.4.8.1.1 1.4.8.1.2 1.4.8.1.3 1.4.8.2 1.4.8.2.1 1.4.8.2.2 1.4.8.2.3 1.4.8.3 1.4.8.3.1 1.4.8.3.2 1.4.8.3.3 1.4.8.4 1.4.8.4.1 1.4.8.4.2 1.4.8.4.3

Issue: 02B

Functional description................................................................ 126 LTE78: Flexi AC/DC with Battery Power Module (FPMA).......... 127 Introduction................................................................................ 127 Benefits...................................................................................... 127 Functional description................................................................ 127 LTE82: High-capacity Flexi System Module (FSME)................. 127 Introduction................................................................................ 127 Benefits...................................................................................... 128 Functional description................................................................ 128 LTE80: GPS synchronization..................................................... 128 Introduction................................................................................ 128 Benefits...................................................................................... 128 Functional description................................................................ 128 Power support features.............................................................. 129 LTE900: Flexi Multiradio BTS 40 W power support....................129 Introduction................................................................................ 129 Benefits...................................................................................... 129 Functional description................................................................ 129 LTE901: Flexi Multiradio BTS 8 W power support......................129 Introduction................................................................................ 129 Benefits...................................................................................... 129 Functional description................................................................ 130 LTE903: Flexi Multiradio BTS 60 W power support....................130 Introduction................................................................................ 130 Benefits...................................................................................... 130 Functional description................................................................ 130 LTE904: Flexi LTE BTS Branch Activation................................. 131 Introduction................................................................................ 131 Benefits...................................................................................... 131 Functional description................................................................ 131

DN0978045

11


List of Figures

12

Figure 1

Power control decision matrix.............................................................18

Figure 2

Principle of CQI adaptation.................................................................26

Figure 3

C-plane security..................................................................................29

Figure 4

U-plane security..................................................................................29

Figure 5

Security key hierarchy........................................................................ 31

Figure 6

Throughput for different modulation schemes.................................... 37

Figure 7

QAM modulation.................................................................................38

Figure 8

2x2 MIMO configuration..................................................................... 47

Figure 9

Multipoint-to-multipoint VLAN............................................................. 56

Figure 10

Point-to-Point VLAN........................................................................... 57

Figure 11

IPsec star configuration...................................................................... 58

Figure 12

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

Figure 13

Transport protocol stack overview.................................................... 104

DN0978045

Issue: 02B


List of Tables

Issue: 02B

Table 1

Software requirements for different network elements....................... 17

Table 2

Parameters for closed loop UL power control.................................... 21

Table 3

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

Table 4

New and modified counters................................................................ 23

Table 5


Table 6


Table 7

Security related messages and information elements........................33

Table 8

Parameters for ciphering and integrity protection...............................35

Table 9


Table 10

Parameters for LTE43: Support of 64QAM in DL............................... 39

Table 11

Counters for LTE43............................................................................ 39

Table 12

Multi antenna options in LTE.............................................................. 46

Table 13

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

Table 14


Table 15

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

Table 16


Table 17

Supported numbers of VLANs............................................................55

Table 18

Sales Information................................................................................59

Table 19

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

Table 20

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

Table 21


Table 22

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

Table 23

Sales information................................................................................65

Table 24


Table 25

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

Table 26

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

Table 27


Table 28

Interdependencies between features................................................. 74

Table 29

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

Table 30

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

Table 31

Alarms for the LTE502: Cell outage triggered reset........................... 76

Table 32

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

Table 33

Error codes......................................................................................... 77

Table 34


Table 35

Interdependencies between features................................................. 84

Table 36


DN0978045

13


14

Table 37

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

Table 38

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

Table 39


Table 40

Parameters for LTE666: LTE User Account Management..................99

Table 41

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

Table 42

Alarms for LTE666: LTE User Account Management......................... 99

Table 43

Software requirements for different network elements..................... 100

Table 44

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

Table 45


Table 46

Hardware requirements for different network elements....................102

Table 47

Sales information..............................................................................104

Table 48

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

Table 49

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

Table 50

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

Table 51


Table 52

Messages..........................................................................................111

Table 53

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

Table 54

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

Table 55


Table 56

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

Table 57

Parameter for configuring MTU size................................................. 118

Table 58

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

DN0978045

Issue: 02B


Summary of Changes

Summary of Changes Changes between version 02B (2012-09-30, RL30) and 02C (2013-07-22, RL30) The following feature description has been updated: •

LTE665:Certificate Management

The following feature activation has been updated: •

Activating LTE665: Certificate Management

Changes between version 02A (2012-04-26, RL30) and 02B (2012-09-30, RL30) The following feature descriptions have been updated: •

LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA)

Changes between version 02 (2011-09-26, RL20) and 02A (2012-04-10, RL30) The following feature descriptions have been updated: • • •

LTE97: Cell Radius Max 77 km LTE432: Cell Outage Detection LTE746: IP Based Filtering for BTS Site Support Equipment

Changes between version 01B (2011-03-24, RL20) and 02 (2011-09-26, RL30) The following feature descriptions have been updated: •

LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA):: Functional description section has been updated.

Changes between version 01A (2010-12-17, RL20) and 01B (2011-03-24,RL20) The following feature descriptions have been updated: •

LTE870: Idle Mode Mobility From LTE To CDMA/eHRPD: Parameters section has been updated.

Changes between version 01A (2010-12-17, RL20) and 01 (2010-10-29, RL20) LTE665: Certificate Management and LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) • • •

Issue: 02B

Vendor Certificate revocation section has been added Identity management server solution section has been updated Factory trust anchor section has been updated.

DN0978045

15



1 Feature Descriptions RL10 1.1 Radio resource management and telecom features from previous releases for RL20 1.1.1 LTE28: Closed loop UL power control 1.1.1.1

Introduction to the feature Closed loop UL power control complements the basic open loop UL power control (see chapter “Power control” in the “Link control” functional area description; UL: uplink). 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. 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.

1.1.1.2 1.1.1.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.

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

16

DN0978045

Issue: 02B


1.1.1.3 1.1.1.3.1


Requirements Software requirements Table 1

1.1.1.3.2

Software requirements for different network elements

Network element

Required software release

System release

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

3GPP release 8

NetAct

–

Hardware requirements This feature does not require any additional hardware.

1.1.1.4 1.1.1.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 strength indicator) and quality (SINR, signal-tointerference plus noise ratio) from PUCCH and/or PUSCH depending on the O&M configuration. 2. The eNodeB processes the measurement data by • • • •

transforming it into a transport format independent format, clipping the measurement data (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 a decision 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 are then signalled to the UE via PDCCH. The command contains the power adjustments (e.g. +3 dB for PUSCH).

Issue: 02B

DN0978045

17



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

good

+ 1 dB or + 3 dB

- 1 dB

- 1 dB

medium

+ 1 dB or + 3 dB

0 dB

- 1 dB

poor

SINR

+ 1 dB or + 3 dB

+ 1 dB or + 3 dB

+ 1 dB or + 3 dB

medium

high

high_qual_thresh

low_qual_thresh

low

low_lev_thresh

18

DN0978045

RSSI

high_lev_thresh

Issue: 02B



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, PPUSCH(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 δPUSCH/PUCCH in the accumulation case are -1 dB, 0 dB, 1 dB, 3 dB. 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. 1.1.1.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.

Issue: 02B

DN0978045

19



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.

1.1.1.5 1.1.1.5.1

System impacts Interdependencies between features “Closed loop UL power control” complements the feature “Open loop UL power control and DL power setting”, see chapter “Power control” in the “Link control” functional area description. “Closed loop UL power control” has effects on the packet scheduler (see the “Packet scheduler” functional area description): 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 time-frequency 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.

1.1.1.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).

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

1.1.1.6 1.1.1.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.

20

DN0978045

Issue: 02B


Table 2


Parameters for closed loop UL power control

Name

Object

Description

Range

Default value

Enable Closed Loop Uplink Power Control

LNCEL

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

0 (false)

0

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

0 (false)

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

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

1 (true)

(ulpcEnable) Include PUCCH LNCEL Measurements In CL Power Control

1

1 (true)

(ulpcPucchEn) Include PUSCH LNCEL Measurements In CL Power Control

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) Lower SINR Threshold For PUSCH Power Command Decision

LNCEL

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)

Issue: 02B

DN0978045

21


Table 2


Parameters for closed loop UL power control (Cont.)

Name

Object

Description

Range

Default value

Upper SINR Threshold For PUCCH Power Command Decision

LNCEL

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

-47...80 dB

4 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

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 3

50 ms

step 10 ms

Parameters common for open and closed loop UL power control

Name

Object

Description

Enabled TB Size Impact To UE PUSCH Power Calculation

LNCEL

This parameter enables/disables a transport 0 (false), format dependent offset on a per UE basis. In 1 (true) case that this parameter is enabled, PUSCH power calculation in UE uplink power control equation (P1) takes the transport block size in account during power calculation.

1

LNCEL

This parameter parameter defines the deltaF PUCCH Format 1.

1

(deltaTfEnabled)

DeltaF PUCCH Format 1 (dFpucchF1)

Range

0 (-2),

Default value

1 (0), 2 (2)

DeltaF PUCCH Format 1b

LNCEL

(dFpucchF1b)

This parameter parameter defines the deltaF PUCCH Format 1b.

0 (1),

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 (dFpucchF2a)

LNCEL

This parameter parameter defines the deltaF PUCCH Format 2a.

0 (-2),

1

1 (0), 2 (2)

22

DN0978045

Issue: 02B


Table 3


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

Name

Object

Description

Range

Default value

DeltaF PUCCH Format 2b

LNCEL

This parameter parameter defines the deltaF PUCCH Format 2b.

0 (-2),

1

(dFpucchF2b)

1 (0), 2 (2)

Filter Coefficient

LNCEL

(filterCoeff)

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)

1.1.1.6.2

Measurements and counters

Counters for: LTE CELL LOAD MEASUREMENT Table 4

New and modified counters

Counter

Number

TPC -1dB for PUCCH

M8001CR Number of sent TPC -1 dB values for PUCCH. D900 Updated when Closed Loop UL power command for PUCCH with value -1 dB is sent on PDCCH to UE.

TPC -0dB for PUCCH

M8001CR Number of sent TPC 0 dB values for PUCCH. D901 Updated when Closed Loop UL power command for PUCCH with value 0 dB is sent on PDCCH to UE.

TPC +1dB for PUCCH

M8001CR Number of sent TPC +1 dB values for PUCCH. D902

Issue: 02B

Description

DN0978045

23


Table 4


New and modified counters (Cont.)

Counter

Number

Description Updated when Closed Loop UL power command for PUCCH with value +1 dB is sent on PDCCH to UE.

TPC +3dB for PUCCH

M8001CR Number of sent TPC +3 dB values for PUCCH. D903 Updated when Closed Loop UL power command for PUCCH with value +3 dB is sent on PDCCH to UE.

TPC -1dB for PUSCH

M8001CR Number of sent TPC -1 dB values for PUSCH. D904 Updated when Closed Loop UL power command for PUSCH with value -1 dB is sent on PDCCH to UE.

TPC -0dB for PUSCH

M8001CR Number of sent TPC 0 dB values for PUSCH. D905 Updated when Closed Loop UL power command for PUSCH with value 0 dB is sent on PDCCH to UE.

TPC +1dB for PUSCH

M8001CR Number of sent TPC +1 dB values for PUSCH. D906 Updated when Closed Loop UL power command for PUSCH with value +1 dB is sent on PDCCH to UE.

TPC +3dB for PUSCH

M8001CR Number of sent TPC +3 dB values for PUSCH. D907 Updated when Closed Loop UL power command for PUSCH with value +3 dB is sent on PDCCH to UE.

1.1.1.7

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

1.1.1.8 1.1.1.8.1

Abbreviations 0–Z A xxx

1.1.2 LTE30: CQI adaption (DL) 1.1.2.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.

24

DN0978045

Issue: 02B



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.

1.1.2.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).

1.1.2.3 1.1.2.3.1


1.1.2.3.2


Network element


System release

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

3GPP release 8

NetAct

–


1.1.2.4 1.1.2.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. Figure 2: Principle of CQI adaptation shows 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.

Issue: 02B

DN0978045

25


Figure 2


Principle of CQI adaptation

Data blocks Packet scheduler

DL link adaptation: Select MCS

(PDSCH) Evaluate reference signals

CQI adaptation

CQI report

CQIreported

(PUCCH/PUSCH) Decode transport blocks

ACK ACK/NACK (PUCCH/PUSCH)

1st DL transport block transmissions

NACK

UE

CQIreported + ΔCQI = CQIcorrected

ΔCQI(t-1) + CQIstepup = ΔCQI(t) ΔCQI(t-1) + CQIstepdown = ΔCQI(t)

Additionally: ΔCQI between CQImax and CQImin

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

1.1.2.5 1.1.2.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”.

1.1.2.6 1.1.2.6.1

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

26

DN0978045

Issue: 02B



Name

Object

Description

Range

Default value

dlOlqcEnable

LNCEL

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

false (0)

true (1)

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

1.1.2.7

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

1.1.3 LTE37: Ciphering and LTE38: Integrity protection 1.1.3.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. The Flexi Multiradio BTS supports ciphering for the user plane PDUs and the RRC PDUs according to the 3GPP specifications TS 36.300, TS 36.323, TS36.331 and TS36.401. The keys used for ciphering and integrity protection of traffic (data / control 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 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): •

Issue: 02B

Null algorithm (EEA0/EIA0 – providing no security)

DN0978045

27



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.

1.1.3.2

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

1.1.3.3 1.1.3.3.1


1.1.3.3.2


Network element


System release

RL10

eNodeB

LBTS1.0

MME

NS10 CD2

SAE GW

–

UE

3GPP release 8

NetAct

–


28

DN0978045

Issue: 02B


1.1.3.4 1.1.3.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. Figure 3

C-plane security integrity protected, ciphered

NAS

RRC

integrity protected ciphered

RRC

NAS

integrity protected

S1AP/X2AP

L3

ciphered

AP

PDCP

L4

...

...

SCTP

SCTP

PDCP

L2

S1AP

IPv4/IPsec

IPv4/IPsec L3

...

eNB

UE

MME

...

integrity protected, ciphered

RRC eNB

Figure 4

X2AP

...

...

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

U-plane security

Data stream

PDCP ...

Data stream

ciphered

PDCP L2

integrity protected

GTP-U AP

...

GTP-U

ciphered

UDP

UDP

integrity protected ciphered

GTP-U UDP

L4

IPv4/IPsec L3 ... UE

eNB

IPv4/IPsec ... S-GW

IPv4/IPsec ... 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: • • •

• •

Issue: 02B

NAS signalling protection is transparent for the eNodeB. NAS signalling is ciphered and integrity protected between UE and MME. RRC integrity protection and ciphering is applied to NAS messages carried by RRC messages in addition to the NAS 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.

DN0978045

29


•

•


S1AP signalling is ciphered and integrity protected between eNodeB and 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.

1.1.3.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 KASME. The NAS keys KNASenc 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 KASME for deriving their security keys. ASME is the Access Security Management Entity of the EPS (evolved packet system) and is located in the MME. The key K which is the origin of all other keys and the keys CK (cipher key) and IK (integrity key) have no direct effect on RRM and are mentionened just for completeness. Other keys or structures for ciphering / integrity protection such as KeNB* and NH are described in the related chapters.

30

DN0978045

Issue: 02B



Figure 5

Security key hierarchy

UE

HSS K

CK

K

IK

CK

IK

MME KASME

KASME

KNASint KNASenc

KNASint KNASenc

Keys for NAS signalling

KASME

NAS area AS area

KeNB

KeNB

KeNB

eNB KUPenc KRRCint KRRCenc

AS keys for C-plane and U-plane traffic

KUPenc KRRCint KRRCenc

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

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

Issue: 02B

Authentication and Key Agreement (AKA): This procedure is performed when a UE initially attaches to the network. The MME authenticates the subscriber, and the keys CK, IK, and KASME are established, once in the USIM/UE, and in the same way in the AuC/HSS. KASME is derived from CK, IK and the PLMN ID; the HSS transfers KASME to the MME. AKA is a NAS procedure and does not have any prerequisite besides the permanent key K.

DN0978045

31


•

•

•


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 KASME as prerequisite. In addition, NAS SMC activates the NAS security mechanisms. KeNB establishment: The procedure applied is specific for different cases: –

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

–

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

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

Key set identifier and key change indicator At initial context setup AS and NAS security start with a common KASME key. Later, several KASME may be known by network and UE. For example, while the RRCCONNECTED state is still ongoing, NAS may apply a new KASME (by executing another NAS security mode command). In this case there is the old KASME, from which NAS and AS keys are still derived, and the new KASME, from which fresh NAS and AS keys shall be derived. Therefore, a specific parameter identifies a particular KASME. Subsequently to a NAS change of KASME (while the AS KASME is still used), AS follows the NAS change which includes a handover. The parameter identifying a particular KASME is KSI (key set identifier). KSI is generated together with KASME during the Authentication and Key Agreement procedure. All keys derived from a KASME inherit this KSI (this is why KSI is called a "set" identifier). The KSI is 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).

32

DN0978045

Issue: 02B



Key handling in case of handover The target eNodeB gets its KeNB to be used for generating its U-plane and C-plane keys as follows: The source eNodeB determines a transport security key KeNB* and transmits this key via X2 interface to the target eNodeB. Then the target eNodeB derives K eNBfrom KeNB*. One possibility to determine KeNB* is to have it derived directly from the currently active KeNB. This direct derivation of KeNB* uses a cryptographic hash function, so it is not feasible to reconstruct the source KeNB from the new target KeNB. Therefore a target eNodeB does not expose the security of the source eNodeB; in other words: backward security is guaranteed. However, there is no forward security which means that the target eNodeB keys are no secret for the source eNodeB. The second possibility to determine KeNB* is to have it derived from the NH (next hop) parameter which was calculated from the KASME. Since the source eNodeB cannot recalculate KeNB* from KeNB, forward security is achieved. In case of a S1 handover, NH is transported from the MME by the S1AP: HANDOVER REQUEST message and is immediately available for the handover (forward security after one hop). In case of X2 handover, NH is transported by the S1AP: PATH SWITCH ACKNOWLEDGEMENT message and is not 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 KeNB* derived directly from the previous KeNB form a chain with backward security only. A handover where the transport KeNB* is derived via NH is the starting point for another chain with backward security only. These chains are counted and identified with the NCC (next hop chaining counter) parameter signalled by the MME; NCC has the value 0 at the initial security context setup.

1.1.3.4.3

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

Table 7

Security related messages and information elements

Message

Information element

IE includes

“securityConfigSMC”

“securityAlgorithmConfig” IE

RRC messages SECURITY MODE COMMAND

(“cipheringAlgorithm” and “integrityProtAlgorithm”) RRC CONNECTION REESTABLISHMENT REQUEST

“ue-Identity”

shortMAC-I

RRC CONNECTION RECONFIGURATION

“securityConfigHO”

“keyChangeIndicator” (not processed by the eNodeB) “nextHopChainingCount”

Issue: 02B

DN0978045

33


Table 7


Security related messages and information elements (Cont.)

Message

Information element

IE includes “securityAlgorithmConfig” (“cipheringAlgorithm” and “integrityProtAlgorithm”; only necessary in case of algorithm changes)

RRC MOBILITY FROM EUTRA COMMAND

“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”

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

HANDOVER REQUEST

“RRC Context”

(see above)

“UE Security Capabilities”

(see below)

“SecurityContext”

NH parameter NCC related to NH.

HANDOVER COMMAND

“NAS Security Parameters “HandoverPreparationinformation” such from E-UTRAN” as ciphering and integrity protection information of the serving cell and the “targetCellShortMAC-I”

PATH SWITCH REQUEST

“UE Security Capabilities”

Supported encryption and integrity protection algorithms in two 2-bit representations.

PATH SWITCH REQUEST ACKNOWLEDGEMENT

“SecurityContext”

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)

34

DN0978045

Issue: 02B


1.1.3.5 1.1.3.5.1


System impacts 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, origin authentication and anti-replay protection.

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

1.1.3.5.3

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

1.1.3.6 1.1.3.6.1 Table 8

User interface Parameters

Parameters for ciphering and integrity protection

Full name (Short name)

Object

Description

Range / Step

Default value

Ciphering Algorithm Activation

LNBTS

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

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

(actCiphering) Ciphering Algorithm Preference List (cipherPrefL)

Integrity Protection Algorithm Preference List (integrityPrefL)

Key Refresh Margin (keyRefrMarg)

Issue: 02B

DN0978045

step 1

35


Table 8


Parameters for ciphering and integrity protection (Cont.)

Full name (Short name)

Object

Description

Range / Step

Default value

Null Ciphering Algorithm Fallback

LNBTS

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

false (0), true (1)

true (1)

(nullFallback)

1.1.3.7

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

1.1.4 LTE43: Support of 64 QAM in DL, LTE788: Support of 16 QAM (UL), LTE793: Support of 16 QAM (DL) 1.1.4.1

Introduction to the feature The original 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: • • •

1.1.4.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 6: Throughput for different modulation schemes gives a short overview of the throughput of different modulation schemes. The figure is valid for a bandwidth of 20Mhz.

36

DN0978045

Issue: 02B


Figure 6

1.1.4.3 1.1.4.3.1


Throughput for different modulation schemes

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

1.1.4.3.2


Network element


System release

RL09

eNodeB

64QAM: LBTS0.5, 16QAM: –

UE

3GPP release 8

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

Issue: 02B

DN0978045

37


1.1.4.4 1.1.4.4.1


Functional description 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 7

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

1.1.4.5 1.1.4.5.1

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

1.1.4.6

Sales information These features are optional.

38

DN0978045

Issue: 02B


1.1.4.7 1.1.4.7.1


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

1.1.4.7.2 Table 10

Parameters

Parameters for LTE43: Support of 64QAM in DL

Name

Object

Description

Range

Default value

dl64QamEnable

LNCEL

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

false, true

–

1.1.4.7.3

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

Issue: 02B

Counters for LTE43

Network element name

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 HARQ transmissions of transport blocks on DL-SCH.

TbSchRetr16QAM_Dl

47273

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

DN0978045

39


Table 11

40


Counters for LTE43 (Cont.)


Database ID

Description

TbSchNoHarq16QAM_Dl

47267

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

HarqAck64QAM_Dl

47245



47248



47250



47253


HarqSizeOrig64QAM_Dl

47259


HarqSizeRetr64QAM_Dl

47262


HarqSizeOk64QAM_Dl

47256


TbSchOrig64QAM_Dl

47268


TbSchRetr64QAM_Dl

47271


TbSchNoHarq64QAM_Dl

47265


HarqAckQPSK_Dl

47246


HarqOkRetr1QPSK_Dl

47249


HarqOkRetr2QPSK_Dl

47252


HarqOkRetr3QPSK_Dl

47254


HarqSizeOrigQPSK_Dl

47260


HarqSizeRetrQPSK_Dl

47263


DN0978045

Issue: 02B


Table 11

1.1.4.8


Counters for LTE43 (Cont.)


Database ID

Description

HarqSizeOkQPSK_Dl

47257


TbSchOrigQPSK_Dl

47269


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.

1.1.4.9 1.1.4.9.1

Abbreviations 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

Issue: 02B

DN0978045

41



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

SNIR signal to noise and interference ratio

TB transport block

42

DN0978045

Issue: 02B



TTI transmission time interval

1.1.5 LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas 1.1.5.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 feature LTE69: 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.

1.1.5.2

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

1.1.5.2.1

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

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

1.1.5.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 antennas provides 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.

1.1.5.3

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

Issue: 02B

DN0978045

43


1.1.5.3.1


Software requirements The features LTE69 and LTE70 require RL09 software.

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

1.1.5.4 1.1.5.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.

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

44

DN0978045

Issue: 02B



Table 12: Multi antenna options in LTE gives an overview on the typical LTE multi antenna configurations:

Issue: 02B

DN0978045

45


Table 12


Multi antenna options in LTE

DL

UL

BS

UE

TX

RX

1x2

1

2

2x2

2

2

Gain to smaller configuration

+ 4 .. 5 dB DL link budget

Configuration type

UE

BS

Gain to smaller configuration

TX

RX

1x2

1

2

minimum

1x2

1

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

Receive diversity NSN 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. the SINR (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 gain of 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) may reach 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. 1.1.5.4.2.2

Transmit diversity NSN supports 2-branch and plans to support 4-branch transmit diversity.

46

DN0978045

Issue: 02B



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, for DRX (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. 1.1.5.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 8

2x2 MIMO configuration

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 separated by 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: • • •

Issue: 02B

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

DN0978045

47



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 influenced. If the conditions for “Spatial Multiplexing” not good enough, however, the UE may request to lower the transmission rank and ultimately falls back to 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.

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

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

48

DN0978045

Issue: 02B


1.1.5.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:

1.1.5.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 antennas are related to each other as they are configured by the same management parameter dlMimoMode.

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

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

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

1.1.5.6

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

1.1.5.7

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

Issue: 02B

DN0978045

49


1.1.5.7.1


Managed Objects This chapter is not relevant for the feature.

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

Table 13

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

Name

Object

Description

Range

dlMimoMode

LNCEL

"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 Diversity; 3: Dynamic Open Loop MIMO: SRB1 (DCCH) and RBs(DTCH) on 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; "

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

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

50

DN0978045

Default value

Issue: 02B



Note: The parameters are subject to change.

1.1.5.7.3

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

1.1.5.7.4

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

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

1.2 Transport and transmission features from previous releases for RL20 1.2.1 LTE713: Synchronous Ethernet 1.2.1.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 as per G.8261. Synchronization through the LTE713: Synchronous Ethernet feature is applicable only for FDD systems.

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

1.2.1.3 1.2.1.3.1

Requirements Software Requirements The following software is required for this feature:

Issue: 02B

DN0978045

51


Table 14

1.2.1.3.2



Network element


System release

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

Hardware Requirements This feature requires Flexi Transport sub-modules which support LTE.

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

1.2.1.4.1

Synchronization Status Messages (SSM) Synchronization status messages carry the information about the quality of incoming SyncE reference signal. 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: •

52

PRC (Primary Reference Clock),

DN0978045

Issue: 02B


• •


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 QL Do 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”: •

•

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

1.2.1.6 1.2.1.6.1

User Interface Parameters Table 15: Parameters related to the LTE713: Synchronous Ethernet feature shows the parameters related to the LTE713: Synchronous Ethernet feature.

Table 15

Parameters related to the LTE713: Synchronous Ethernet feature

Name

Object

Description

Range

Default value

synchroSourceList

STPG

This is the list of synchronization sources of the eNB.

-

-

Issue: 02B

DN0978045

53


Table 15


Parameters related to the LTE713: Synchronous Ethernet feature (Cont.)

Name

Object

Description

Range

Default value

ssmEnabled

STPG

This parameter enables SSM support (Synchronization Status Message) for Synchronuous Ethernet.

Boolean

true

ssmTimeout

STPG

This is the maximum duration in seconds for 2...10 seconds, step 1 which the actual SSM value may be less than seconds acceptable clock quality or for which SSMs are not received at all. If the duration is surpassed, an alarm will be raised.

1.2.1.6.2

5 s

Alarms This section lists alarms related to the LTE713: Synchronous Ethernet feature. There are no alarms for theLTE713: Synchronous Ethernet feature.

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

1.2.1.7

Activating and Configuring the Feature For activating and configuring the feature, see Feature Activation Documentation.

1.2.2 LTE132: VLAN based traffic differentiation 1.2.2.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.

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

54

DN0978045

Issue: 02B


1.2.2.3 1.2.2.3.1


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

1.2.2.3.2


Network element


System release

RL10

eNB

LBTS1.0

MME

-

NetAct

OSS5.2 CD3

SAE GW

-

Hardware Requirements This feature requires Flexi Transport sub-modules which support LTE.

1.2.2.4

Functional Description Traffic differentiation can in principle be performed on several layers: • • •

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 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 17

Issue: 02B

Supported numbers of VLANs

VLAN

Main usage

Number of PHB queues

Associated IP network interface

VLAN#1

mainly for U-plane; optionally also for C-, M- and S-plane

6

IP network interface#1

VLAN#2

C-plane

1


DN0978045

55


Table 17


Supported numbers of VLANs (Cont.)

VLAN

Main usage

Number of PHB queues

Associated IP network interface

VLAN#3

M-plane

1


VLAN#4

S-plane (Timing over Packet)

1


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.

1.2.2.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 (up to four) is identified by a single VLAN identifier (VLAN ID) which is configured identically in all eNBs and also in the VLAN GW. Depending on the X2 configuration, the 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, see X2 interface via IPsec Star Configuration. Figure 9

56

Multipoint-to-multipoint VLAN

DN0978045

Issue: 02B



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 10

Point-to-Point VLAN

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. 1.2.2.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 11: IPsec star configuration shows the principle of this IPsec star configuration for X2:

Issue: 02B

DN0978045

57


Figure 11


IPsec star configuration

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.

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

58

DN0978045

Issue: 02B


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

1.2.2.5

Sales Information Table 18

1.2.2.6 1.2.2.6.1

Sales Information

BSW/ASW

Licensecontrol in network element

License control attributes

ASW

-

-

User Interface Parameters Table 19: Parameters related to the LTE132: VLAN based traffic differentiation shows the parameters related to the LTE132: VLAN based traffic differentiation feature.

Table 19

Parameters related to the LTE132: VLAN based traffic differentiation

Name

Object

Description

Range/step

Default value

vlanIfNetId

IVIF

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

-

localIpAddr

IVIF

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

Issue: 02B

IVIF

step: 1

This parameter holds the shaper 100...1.000.000 kbps, information rate for a specific vlan interface. step: 100 kbps

DN0978045

1.000.000 kbps

59


Table 19


Parameters related to the LTE132: VLAN based traffic differentiation (Cont.)

Name

Object

Description

Range/step

Default value

sbs

IVIF

This parameter holds the shaper burst size for a specific vlan interface.

1522...2.000.000 octets, step: 1 octet

1522 octets

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)

false

wfqSchedQueu IVIF eWeight

This is the weight value to be used in the WFQ aggregation scheduler for this VLAN interface.

1..10000

1000

wfqSchedQueue IEIF Weight

This is the weight value to be used in the WFQ aggregation scheduler for this VLAN interface.

1..10000

vlanMapId

IVMP

Identifier of the VLAN Map

1

1

vlanMap

IVMP

Structure of "vlanMap"

-

-

ulTrafficPath

IVMP

Number of the UL- traffic paths

1...4

-

vlanPtr

IVMP

Reference to the corresponding VLAN i.e. MOI IVIF

-

-

1.2.2.6.2

step: 1 1000

step: 1

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.

1.2.2.6.3

Measurements and Counters Table 20: Counters for the LTE132: VLAN based traffic differentiation shows the measurements and counters related to the LTE132: VLAN based traffic differentiation feature. Table 20

60

Counters for the LTE132: VLAN based traffic differentiation

Counter

Number

Description

ifInPackets15

M51127C0

The number of IP packets received on the VLAN interface that were delivered to higherlayer protocols.

ifInOctets15

M51127C1

The total number of kilo-octets received on the VLAN interface, including framing characters.

DN0978045

Issue: 02B


Table 20

1.2.2.7


Counters for the LTE132: VLAN based traffic differentiation (Cont.)

Counter

Number

Description

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

1.2.3 LTE134: Timing over packet 1.2.3.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.

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

1.2.3.1.2

Requirements

Software requirements The following software is required for this feature:

Issue: 02B

DN0978045

61


Table 21



Network element


System release

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

Hardware requirements This feature requires Flexi Transport sub-modules which support LTE.

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

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

62

DN0978045

Issue: 02B



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. 1.2.3.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). 1.2.3.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: • • •

Issue: 02B

The SYNC message rate can be chosen between 8/s, 16/s and 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).

DN0978045

63



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.

1.2.3.1.4

Management data For information on alarm, counter, key performance indicator, and parameter documents, see Reference documentation.

Alarms There are no alarms related to this feature.

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

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

Parameters Table 22: Parameters related to the LTE134: Timing over packet feature shows the parameters related to the LTE134: Timing over packet feature. Table 22

Parameters related to the LTE134: Timing over packet feature

Name

Object

Description

administrativeState

TOPIK

Used to lock and unlock the TOP object instance. locked (0), Locking the object deactivates it and supresses unlocked (1) all its alarms.

-

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:

-4

• • •

64

Range

-5...-3, step 1

Default

-3: 8 per second -4: 16 per second -5: 32 per second

DN0978045

Issue: 02B


Table 22


Parameters related to the LTE134: Timing over packet feature (Cont.)

Name

Object

Description

Range

Default

masterIpAddr

TOPIK

IP address of the ToP master. Format: this is an IPv4 IP address in dotted decimal form.

7...15 characters

-

1...1, step 1

-

Examples: IPv4: 10.12.11.0 topId

TOPIK

1.2.3.1.5

Sales information Table 23

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


ASW

-

-

Activating and configuring the feature For activating and configuring the feature, see Feature Activation Documentation.

1.3 Operability features from previous releases for RL20 1.3.1 LTE150: LTE OAM Transport Layer Security (TLS) Support 1.3.1.1

Introduction to the feature This feature enables secure O&M control and bulk data communication between Evolved Node B (eNB) and BTS Site Manager, NetAct, or other management system. The feature includes a PKI infrastructure by utilizing secure protocols 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.

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

Issue: 02B

DN0978045

65


1.3.1.3 1.3.1.3.1


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

1.3.1.3.2


Network element


System release

RL10

eNB

LBTS1.0

MME

-

SAE GW

-

NetAct

OSS5.2 CD3

Hardware requirements This feature has no particular hardware requirements.

1.3.1.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) 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 and provision 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:

66

DN0978045

Issue: 02B


• •


The TLS record protocol provides encryption and integrity protection of the message exchange. The TLS handshake protocol provides mutual authentication 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 authorization (CUAA) 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: •

• •

g

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.

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.

Issue: 02B

DN0978045

67



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 parameter (TLSModeFT) which can be configured as: •

Forced – – – –

•

Probing –

– •

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.

Both secure and insecure file transfers are allowed between 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.

68

DN0978045

Issue: 02B



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.

1.3.1.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 the TLS_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 certificate that cannot be validated by BTSSM (for example, because the operator root CA certificate is not configured in BTSSM), an NSN 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).

1.3.1.5 1.3.1.5.1

System impact Interdependencies between features LTE665: LTE Certifcate Management provisioning of a common certificate handling.

1.3.1.5.2

Impact on interfaces This feature has no impact on interfaces.

1.3.1.5.3

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

1.3.1.5.4

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

1.3.1.6

Sales information This feature belongs to BSW.

Issue: 02B

DN0978045

69


1.3.1.7


Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support Table 25: Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support shows parameters related to LTE150: LTE OAM Transport Layer Security (TLS) Support.

g

After changing parameters a BTS restart is necessary. Table 25

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

Full name

Object

Description

Range / Step

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 connections).

TLS (0), TLS_OR_PL AIN_TEXT (1)

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.

(Short name) LDAP Server TLS access mode ( ldapConnectionT ype)

TLS usage towards the iOMS system (omsTls)

1.3.1.8

Default value

Alarms for LTE150: LTE OAM Transport Layer Security (TLS) Support This section lists alarms related to RAN O&M security per feature. Table 26

70

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

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.

DN0978045

Issue: 02B



1.3.2 LTE432: Cell Outage Detection 1.3.2.1

Introduction Cells, identified as probably not providing service will be indicated with a quality of service alarm. The detection mechanism of the feature LTE432: Cell Outage Detection will raise dedicated quality of service alarm for a cell in case it has been detected as “sleepy cell”. Based on this specific alarm the feature LTE502: Cell outage triggered reset triggers an action automatically to get the cell back into service.

1.3.2.2

Benefits The feature LTE432: Cell Outage Detection detects 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. With the feature LTE502: Cell outage triggered reset the operator can select to apply these automatic corrective actions per Flexi Multiradio BTS.

1.3.2.3

Requirements

1.3.2.3.1

Software Requirements for LTE432

1.3.2.3.2

Software Requirements for LTE502 Table 27

1.3.2.3.3


Network element


System release

RL20

NetAct

OSS5.3 CD3

Hardware Requirements This feature does not require any additional Hardware.

Issue: 02B

DN0978045

71


1.3.2.4 1.3.2.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. Figure 12: LTE432 Thresholder and Profiler in NetAct gives an overview of the scenario. Figure 12

1.3.2.4.1.1

LTE432 “Thresholder and Profiler” in NetAct

Failure Scenarios The following failure scenarios are taken into account:

72

DN0978045

Issue: 02B


• • • • • • •

1.3.2.4.1.2


Failed RACH (Random Access Channel) access Failed RRC (Radio Resource 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. The following PM counters are taken into account: • • • • • •

1.3.2.4.2

Cell availability RACH failure rate RRC connection setup failure rate Data radio bearer setup failure rate PDCP cell throughput Uplink power measurements

LTE502: Cell outage triggered reset The detection mechanism of the existing feature LTE432: Cell outage detection will be used as the basis. The raised quality of service alarm is the trigger for the automatic alarm reaction in NetAct. Only those conditions are evaluated, which indicate a problem with nearly absolute certainty: • • •

Failed RACH Access Failed RRC Connection Setup Failed DRB Setup

The related alarms are raised only if we have, during one PM data upload interval, a 100% failure rate of the associated telecom procedures. A BTS reset is attempted to correct the condition. As long as the alarm stays active, no further resets are initiated.

Logging of Automatic Cell Recoveries The operator can get information about the current performed recoveries by viewing a log file in NetAct.

Use Case: Cell Outage Triggered Reset This use case describes the recovery actions after a Cell Outage has been detected. Actors: NetAct, NE, OMS as mediator

Issue: 02B

DN0978045

73



Preconditions: NE is on Air Feature LTE432: Cell outage detection is enabled Feature LTE502: Cell outage triggered reset is enabled Management connection between NE and NetAct is up

• • • •

Trigger: NetAct Monitoring detects a Cell Outage Alarm with a suitable trigger condition. Description: 1. 2. 3. 4.

NetAct creates the Delta-Plan with the changed BTSResetRequest parameter NetAct downloads the Delta-Plan to the affected BTS NetAct activates the Delta-Plan The BTS performs the reset in order to activate the Delta-Plan.

Postconditions: The BTS has been reset.

1.3.2.5 1.3.2.5.1

System Impacts Interdependencies between Features Table 28 LTE432

Interdependencies between features Cell Outage Detection Sub-feature: LTE502: Cell outage triggered reset

1.3.2.6

Sales Information This feature belongs to Application Software (ASW) product structure class.

g 1.3.2.7 1.3.2.7.1

For feature LTE432: Cell outage detection a license is necessary. Feature LTE502: Cell outage triggered reset does not require a separate license.

User Interface Parameters for LTE432: Cell outage detection Table 29: Parameters for the LTE432: Cell Outage Detection shows the parameters implemented for the feature LTE432: Cell Outage Detection. Table 29

74

Parameters for the LTE432: Cell Outage Detection

Name

Description

Default value

MIN_RACH_Threshold

Threshold for "MIN RACH"

100

DN0978045

Issue: 02B


Table 29


Parameters for the LTE432: Cell Outage Detection (Cont.)

Name

Description

Default value

MIN_RRC_Threshold

Threshold for "Failed RRC Connection 50 Setup" and "No RRC Connection Setup" evaluation

MIN_DRB_Threshold

Threshold for "Failed DRB Setup" and "No DRB Setup" evaluation

50

MIN_PDCP_Threshold

Threshold for "No Traffic" evaluation

5 kBit/s

MIN_RSSI_Threshold

Threshold for "Degraded Uplink Power" evaluation

-100dbm)

History_Evaluation

Attribute for historical KPI evaluation method used for "No RACH Access", "No RRC Connection Setup", "No DRB Setup" and "No Traffic" evaluation. 7 days: historical KPI result value of corresponding time of day Min 7 days: minimum historical KPI result value for same time

1.3.2.7.1.1

LTE502: Cell outage triggered reset The user has the possibility to control the enabling of the feature LTE502: Cell outage triggered reset by editing an exclusion list, which is available on NetAct.

1.3.2.7.2

Alarms for LTE432: Cell outage detection The following alarms are related to this feature: Table 30

Issue: 02B

Alarms for the LTE432: Cell outage detection

Alarm number

Alarm name

69301

Failed RACH access

69302

Failed RRC connection setup

69303

Failed DRB setup

69304

No RACH access

69305

No RRC connection setup

DN0978045

75


Table 30

1.3.2.7.2.1


Alarms for the LTE432: Cell outage detection (Cont.)

Alarm number

Alarm name

69306

No DRB setup

69307

No traffic

Alarms for LTE502: Cell outage triggered reset The following alarms are related to this feature: Table 31

1.3.2.7.3

Alarms for the LTE502: Cell outage triggered reset

Alarm number

Alarm name

69301

Failed RACH access

69302

Failed RRC connection setup

69303

Failed DRB setup

Measurements and Counters for LTE432: Cell outage detection The following table shows the counters for LTE432: Cell outage detection.

g Table 32

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.

Counters for the LTE432: Cell outage detection

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

76

DN0978045

Issue: 02B


Table 32


Counters for the LTE432: Cell outage detection (Cont.)

Counter long name (short name)

Description

Short name: a) PDCP_DATA RATE_MEAN_UL b) PDCP_DATA RATE_MEAN_DL a) Mean RSSI on PUCCH b) Mean RSSI on PUSCH c) Mean RSSI

This KPI provides the Mean RSSI in uplink direction on PUCCH as well as on PUSCH. This KPI can be used to monitor the correct functionality of the radio/air interface. In case uplink power measurements show low values, a malfunction of the eNB (i.e. power amplifier) could be ongoing.

Short name: a) Mean_RSSI_PUCCH b) Mean_RSSI_PUSCH c) Mean_RSSI

1.3.2.8

System Responses to Failures This feature introduces the error codes shown in Table 33: Error codes.

Table 33

Error codes

Output

Name

Number

Description

DLDC feature is not in use in BSC

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.

000B6H

Self-explanatory

DLDC cannot be dldc_without_egprs_ec enabled without EGPRS enabled in BTS

1.3.2.9

Activating the Feature To activate the feature see the NetAct Feature Activation Manual in OSS5.2.

g 1.3.2.10 1.3.2.10.1

For feature LTE432: Cell outage detection a license is necessary. Feature LTE502: Cell outage triggered reset does not require a separate license.

Abbreviations 0–Z DRB Data Radio Bearer

Issue: 02B

DN0978045

77



eNB evolved Node B

RACH Random Access Channel

RRC Radio Resource Controller

SCH Signalling Channel

1.3.3 LTE539: Central ANR 1.3.3.1

Introduction This feature represents the first implementation of automated neighbor relation (ANR) for Intra-frequency, Intra-LTE ANR, enabling for the automatic creation and establishment of neighbor relations between Flexi Multiradio BTSs. The central ANR, as the name states, is a central solution based on NetAct Configurator and Optimizer, not considering any UE measurements.

1.3.3.2 1.3.3.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. • • •

1.3.3.3 1.3.3.3.1

The operator can preset the policy of the service to generate the neighbor list. The operator can pre-configure the lower target 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 34

78


Network element


System release

RL10

OMS

GOMS6.0

DN0978045

Issue: 02B


Table 34

1.3.3.3.2


Software requirements for different network elements (Cont.)

Network element


NetAct

OSS5.2 CD3

Hardware Requirements This feature does not require any additional Hardware.

1.3.3.4 1.3.3.4.1

LTE539: Central ANR Functional Overview/Details

Feature scope LTE539: Central ANR requests NetAct Configurator and Optimizer to automatically generate LTE intra-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 feature LTE492: ANR or LTE782: ANR Fully UE based. LTE539: Central ANR is a feature purely of NetAct Optimizer and Configurator. The BTS will not be impacted by this feature. • • • •

1.3.3.4.1.1

NetAct Optimizer generates adjacency information as required for PCI management. Depending on the profile the found adjacencies are entered as neighbor cell relation information for configuration data. NetAct Configurator will include neighbor cell relation information in the CM database for eNB auto configuration. For the eNB the neighbor cell relation information is included 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 hosted LTE cells. Optimizer adds/modifies the global eNB ID in the attribute adjEnbIPAddressMap of the object ADIPNO. • • •

Optimizer passes lists of neighboring eNBs to Configurator. Optimizer will pass one neighbor list for each given eNB of the plan to Configurator. Optimizer and Configurator use the global eNB ID to identify eNBs.

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 a lower and upper limit. The lower limit will only be enforced in case there are enough neighbor cells fulfilling the priority criterion.

Issue: 02B

DN0978045

79


g


Target of the feature LTE539: Central ANR is to provide a ranked list of neighbor eNBs to a given eNB. In order to reserve free entries in the object ADIPNO for not yet planned neighboring eNBs, it is possible to restrict the number of entries by limiting the number of neighbor cells. The policies, lower and 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 the feature LTE539: Central ANR 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 expected to be useless. To avoid race conditions with the current configuration of the eNBs, the operator needs to disable existing decentralized ANR functions (LTE782: ANR - UE based and LTE492: Automated neighbor relation (ANR)) in the scope of the selected eNBs. According to the described use cases, it is required, that LTE782: ANR UE based and LTE492: Automated neighbor relation (ANR) are disabled during plan provisioning. Of course the operator can enable the two features after the execution of the manual triggered LTE539: Central ANR. The uses 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 personal. Some eNBs failed during auto-configuration and need to be configured in a post process. The operator runs the network without LTE492: ANR or LTE782: ANR UE based. Some eNBs have a changed HW and cell deployment and require re-configuration. Some eNBs have too much useless neighbors and need to 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 are controlled by another element manager, even from an other vendor.

During auto-configuration “Centralized ANR” ignors 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.

80

DN0978045

Issue: 02B



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 (up to RL40/RL25TD: 32 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, Optimizer creates the respective LNADJ instances to the source eNB as required for each eNB. NetAct Optimizer creates the configuration plan file for further processing in Configurator. • • • •

Optimizer deletes all not required actual LNADJs and Configurator deletes their LNADJLs. Optimizer creates all required LNADJs that are not yet existing and free instances are available. Optimizer reconfigures all existing 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”.

NetAct Optimizer creates new neighbor eNBs. The configurator provides all further required information for the eNB to execute LTE724: LTE Automatic Neighbor Cell Configuration functions to connect the X2 link.

Issue: 02B

DN0978045

81


g

•

• •

•

•

•

• •


During the execution of manual 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 Configuration as oamControlled LNADJs with the IP address. The IP address is not necessarily configured at both peers. Therefore the operator should temporary enable the feature LTE782: ANR UE based or LTE492: ANR afterwards to enable the acceptance of incoming X2 links at the other peer. The work-flow does not consider the capability of the eNBs to support ANR, intra- or inter-frequency LTE HO. If the feature LTE782: ANR UE based or LTE492: ANR 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 LTE539: Centralized ANR, as still S1 HO is supported. The LTE539: Centralized ANR does not modify any X2-black-listing setting. The feature LTE539: Centralized ANR does not consider the PCI configuration. It is left to the operator whether or not he runs LTE468: PCI management to clean-up the PCI configuration The manual execution of central ANR does not support former ADIPNO LTE neighbor modeling as supported up to RL20/RL15TD. The operator has to run and provision the manual executed LTE539: Central ANR twice, if there are not sufficient free LNADJ instances available. 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. LTE492: ANR and LTE782: ANR UE based are 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.

82

DN0978045

Issue: 02B



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, he saves 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 the neighbor 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. 1.3.3.4.1.2

NetAct Configurator 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 addition 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 feature LTE724: LTE Automatic Neighbor Cell Configuration:

Issue: 02B

DN0978045

83



The eNB starts X2 setup to another eNB (or other eNBs) and exchanges data about the cell it hosts. 1.3.3.4.1.3

Integration in the Auto configuration Workflow •

• • • • • •

The operator in front of the Configurator manually creates/imports a plan with newly planned eNBs. The plan contains the global eNB Id, the geo-location and direction of cells and maybe also the location of sites. The IP addresses of the eNBs are either pre-planned, manually configured by the operator. In addition, the Configurator knows the current configuration of the already running network. The auto configuration workflow triggers Optimizer. Optimizer retrieves a list of new eNBs in the master plan to be handled. Optimizer has already access to the current configuration. Optimizer plans intra-LTE neighbors for the eNBs in the list. Optimizer allocates collision and confusion free compliant PCI values (LTE468: PCI management) Optimizer transfers information about PCIs and intra-LTE neighbors to Configurator. Configurator then uses neighbor information to complete “pre-planning” for new eNBs. – –

•

Configurator downloads and activates the plan to network. This will result in – –

1.3.3.5 1.3.3.5.1

Configurator creates entries in ADIPNO.adjEnbIPAddressMap only for the neighboring eNB that are already running. Configurator adds the new eNB to ADIPNO.adjEnbIPAddressMap of the running neighboring eNB. This update of the running eNB is necessary because the IP address of the new eNB has not been available before auto configuration of the new eNB.

Auto configuration of the new eNB and Update of ADIPNO.adjEnbIPAddressMap in the already running eNB.

System Impacts Interdependencies Between Features Table 35

Interdependencies between features

LTE724

LTE Automatic Neighbor Cell Configuration LTE724 enables the eNB to exchange cell data via the X2 interface.

g

84

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

DN0978045

Issue: 02B


Table 35


Interdependencies between features (Cont.) 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. "

1.3.3.6

Sales Information For “Feature Activation” see Feature Activation Manual in NetAct operating documentation OSS5.2.

1.3.3.7

Activating and Configuring the Feature To activate the feature see the NetAct Feature Activation Manual in OSS5.2.

1.3.3.8 1.3.3.8.1

Abbreviations 0–Z ANR Automated Neighbor Relation

eNB evolved Node B

Issue: 02B

DN0978045

85



1.3.4 LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA) 1.3.4.1 1.3.4.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 NSN identity management system (IDM) or a 3rd party PKI solution.

1.3.4.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 NSN as vendor and the operator side is a prerequisite. The NSN identity management solution integrates the NSN PKI manufacturing and delivery chain with the operators PKI infrastructure.

1.3.4.2 1.3.4.2.1

Benefits LTE665: LTE Certificate Management The certificate management feature provides centralized and scalable key and certificate management for operator networks. It enables: • •

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

1.3.4.3 1.3.4.3.1


86


Network element


System release

RL10

eNodeB

LBTS1.0

DN0978045

Issue: 02B


Table 36

1.3.4.3.2



Network element


MME

–

SAE GW

–

UE

–

NetAct

OSS5.3 CD1


1.3.4.4 1.3.4.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 NSN 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: 1. When a new eNB is manufactured at a certain point in the process queue, a unique public and private key is generated and stored within the eNB. The public key portion is given to the factory RA/CA for signing. 2. The NSN factory certification authority (Factory-CA) together with the factory registration authority (Factory-RA) creates and signs a NSN device certificate for each individual eNB, where the subject of the certificate is linked to the eNB serial number.

g Issue: 02B

The NSN Factory CA is a subordinate CA of the Nokia Root CA.

DN0978045

87



3. The public NSN device certificate is stored together with the factory CA certificate in a NSN 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 the serial numbers of the shipped modules on request via the NSN 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 has been ordered, by comparing the serial number of the certificate from the eNB with the order deliveries. NSN 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 user interface DER: used for transferring certificates over certificate management protocol (CMP) PKCS#12: used for transferring certificates and keys between eNB and BTS Site Manager (used for injecting the certificate and private/public key pair in the BTS in exceptional case where no online PKI is available)

The same certificate is used for both IPSec and Transport Layer Security Protocol (TLS) 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 DHCP server or manually configured) or its third-party PKI security server (RA/CA) as the first point of contact. 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 NSN 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. 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.

88

DN0978045

Issue: 02B



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. Certificate and key interchange according to PKCS#12 is supported between eNB and BTS Site Manager to inject both operator certificate and key pair.

g

The operator needs to compute the private and the public key pair off-line to get the public key signed by the operator's CA and to create the PKCS#12 container file. This file contains the operator certificate and the key pair and it is entirely ciphered. For decryption purposes, the field installer needs to know the right pass phrase. A similar procedure can be used to inject other certificates like the trust anchors.

eNB authentication During eNB rollout 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 NSN device certificate (vendor certificate) is available, the eNB tries to authenticate with its vendor certificate. 3. If neither a PSK/RefNum nor a NSN 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 NSN 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.

Issue: 02B

DN0978045

89



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. 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 revocation feature, 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

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.

90

DN0978045

Issue: 02B



The following CMP messages are supported: • • • • • •

ir (initialization request) ip (initialization response) kur (key update request) kup (key update response) pkiconf (PKI confirmation) certConf (certificate confirm)

Vendor certificates are provided in the CMP message ExtraCerts field.

1.3.4.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 NSN side as vendor, and on the operator side is a prerequisite. The NSN secure device identity (SDI) concept links the NSN PKI manufacturing and delivery chain with the operator’s PKI infrastructure. On the operator side, the NSN 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 NSN side To support the NSN IDM or another third party PKI, the manufacturing process of an eNB is extended by the introduction of a NSN factory certification authority (Factory-CA) 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 NSN factory-CA together with the factory-RA creates and signs a NSN 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 authorization modules for automated checks of NSN public device certificates against deployed eNB hardware

deployment of operator device certificates to the eNB renewal and revocation of operator certificates, if necessary.

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.

Issue: 02B

DN0978045

91



Identity management server solution The identity management server solution consists of the following components: •

g

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. In the initial enrollment the vendor certificate is used to authenticate the request. When the eNB updates the operator certificate, it uses the alreadyenrolled 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 the address in the initial DHCP exchange. A standard DHCP server can be used but it must be configurable to support the configuration of vendor specific attributes. IDM server The IDM server represents the NSN 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 NSN 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 NSN 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

92

DN0978045

Issue: 02B



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 NSN. 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 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 NSN trust anchors. The factory trust anchors (Nokia Root CA certificate and NSN factory CA certificate) are delivered to the operator via the NSN 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: • • •

1.3.4.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 Management feature is related to following features: • • •

1.3.4.6

LTE150: LTE OAM Transport Layer Security (TLS) Support LTE689: LTE IPsec Support LTE154: SON LTE BTS Auto Connectivity

Sales information LTE665: LTE Certificate Management and 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.

1.3.4.7 1.3.4.7.1

User interface Parameters for LTE665: LTE Certificate Management Table 37: Parameters for LTE665: LTE Certificate Management shows the parameters related to feature LTE665 LTE Certificate Management.

Issue: 02B

DN0978045

93



All parameters are located in object CERTH. Table 37

Parameters for LTE665: LTE Certificate Management

Name

Description

Range

Default value

btsCertificateUpdateTim Number of days before a BTS certificate e expires and a CMP update sequence is triggered autonomously from the BTS.

1...4999 365 days days, step 1 day

caCertificateUpdateTim e

Number of days before a CA or trust anchor certificate expires and a CMP update sequence is triggered autonomously from the BTS.

1...4999 1825 days, step 1 days day

caSubjectName

Name of CMP server

0...128 characters

certhId

Certificate handler configuration

1...1, step 1

1

Value is always 1, not modifiable cmpServerIpAddress

IP address of CMP server, entered in dotted decimal format

7...15 characters

cmpServerPort

Port number for addressing CMP server

1...65535, step 1

crlUpdatePeriod

Period for executing a periodical update of CRL

0...8760 hours, step 1 hour

Value 0 means no periodical update

1.3.4.7.2

Alarms for LTE665: LTE Certificate Management Table 38

Alarms for LTE665: LTE certificate management

Alarm number

Alarm name

Condition

61074

CRL Update failure

This alarm is raised if the BTS cannot update the Certificate Revocation List (CRL) for one of the following reasons: • •

• • •

94

0

DN0978045

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

Issue: 02B


Table 38


Alarms for LTE665: LTE certificate management (Cont.)

Alarm number

Alarm name

Condition

61510

NO_CERTIFICATE

A requested certificate could not be retrieved from the Certificate Authority (CA).

7665

BASE STATION TRANSMISSION ALARM

This alarm is raised if any of the below BTS faults occurs: •

CRL Update failure (61074) The fault is reported when: – –

– – – •

1.3.4.8

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

Activating and configuring the feature For an activation instruction refer to Feature Activation Document.

1.3.5 LTE666: LTE User Account Management 1.3.5.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.

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

Issue: 02B

DN0978045

95


1.3.5.3 1.3.5.3.1

Requirements Software Requirements Table 39

1.3.5.3.2



Network element


System release

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

OSS5.2 CD3

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

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

1.3.5.4.1

Authentication and authorization Centralized user authentication and authorization is 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 account is used only for the registration purposes, when the iOMS connects to the NWI3 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, the registration account is disabled and only the NE account is in use. If the registration account of an iOMS could not be used, the NE account is used as a back-up account for registering the iOMS in the CUAA repository.

96

DN0978045

Issue: 02B



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.

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

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

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

1.3.5.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 Management feature is available from iOMS and eNB.

Issue: 02B

DN0978045

97



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 the log 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: The operator manually enters the referring NetAct command. NetAct scheduler: The operator schedules the upload periodically. a ‘log file full’ event: The iOMS and the eNB initiate the upload if a log file reaches maximum capacity before NetAct initiates the upload again.

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

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.

1.3.5.5

System impacts This feature has no impact on system performance or capacity.

1.3.5.6

Sales information The LTE User Account Management feature is an additional software feature.

98

DN0978045

Issue: 02B


1.3.5.7 1.3.5.7.1


User interface Parameters for LTE666: LTE User Account Management Table 40: Parameters for LTE666: LTE User Account Management shows the parameters related to LTE666 LTE User Account Management. All parameters are located in object AMGR. Table 40

Parameters for LTE666: LTE User Account Management

Name

Description

Range

amgrID

This parameter identifies the account manager

1...1,

Default value

step 1

Value is always 1, not modifiable primaryLdapPort

Port number of the primary LDAP server

1...65535, step 1

primaryLdapServer

IP address of the primary LDAP server, entered in dotted decimal format

7..15 characters

389

Table 41: 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 in File ► Preferences. Table 41

1.3.5.7.2

Description

Range

Default value

item Automatic disconnection from BTS site, check Disconnect if no user activity

10..120 minutes, step 1

30 minutes

Alarms for LTE666: LTE User Account Management Table 42

Issue: 02B

Parameters for LTE666: LTE User Account Management - BTSSM

Alarms for LTE666: LTE User Account Management

Alarm number Alarm name

Condition

61500

Five consecutive failed login attempts to the FTM have been performed.

Five failed logins to FTM due to wrong user name or password

DN0978045

99


Table 42

1.3.5.8


Alarms for LTE666: LTE User Account Management (Cont.)

Alarm number Alarm name

Condition

70025

POSSIBLE SECURITY THREAT IN NETWORK ELEMENT

Five (default value) consecutive failed login attempts to iOMS

7665

BASE STATION TRANSMISSION ALARM

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.

Activating and configuring the feature For an activation instruction refer to Feature Activation Document

1.3.6 LTE679: LTE Local User Account Management 1.3.6.1

Introduction to the feature This feature introduces a local user account management for the eNB.

1.3.6.2

Benefits Enhanced risk management is achieved by improved access security.

1.3.6.3 1.3.6.3.1


100


Network element


System release

RL09

eNodeB

LBTS0.5

MME

–

SAE GW

–

UE

–

NetAct

–

DN0978045

Issue: 02B


1.3.6.3.2



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

1.3.6.5

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

1.3.6.6

Sales information The LTE679: LTE Local User Account Management feature is a basic software feature.

1.3.6.7 1.3.6.7.1

User interface Parameters for LTE679: LTE Local User Account Management Table 44: Parameters for LTE679: LTE Local User Account Management shows the parameters related to LTE679 LTE Local User Account Management. Table 44

1.3.6.8

Parameters for LTE679: LTE Local User Account Management

Name

Length

User account name

4-16 characters

User account password

8-14 characters

Activating the feature This feature does not require activation.

1.3.7 LTE689: LTE IPsec Support 1.3.7.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, synchronization, and management plane interfaces is increased by providing encryption, integrity protection and communication peer authentication with IPsec according RFC 4301.

Issue: 02B

DN0978045

101



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.

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

1.3.7.3 1.3.7.3.1


1.3.7.3.2


Network element


System release

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

OSS5.2 CD3

Hardware requirements Table 46

Hardware requirements for different network elements

Network element

Required hardware

MME

-

eNodeB UE

102

-

DN0978045

Issue: 02B


1.3.7.4


Functional description for IPsec Support Supported IPsec capabilities •

• • •

Services: Data integrity protection, origin authentication, anti-replay protection, and confidentiality. For Flexi BTS10, also IP packets reassembly (before IPsec decryption). Protocol: ESP (RFC 4303) IPsec mode: Tunnel mode Encryption/ciphering algorithms: – – –

• •

Integrity protection algorithm: HMAC-SHA-1-96 Identification with – – –

• •

AES-128-CBC 3DES-192-CBC NULL

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)

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 IPSec VPN 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.

Issue: 02B

DN0978045

103


1.3.7.4.1


Transport security This section covers the transport security functions for the following logical interfaces: • • • • •

S1-U: User data transport (U-plane) between eNB and S-GW (GTP-U tunneling) X2-U: User data transport (U-plane) between eNB 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 eNB and 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 13: Transport protocol stack overview gives on overview on the eNB protocol stacks and the embedded IPsec layer. Figure 13

Transport protocol stack overview

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

1.3.7.5

System impacts The LTE689: IPsec Support feature 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.

1.3.7.6

Sales information Table 47

Sales information

BSW/ASW

License control in network element


ASW

SW Asset Monitoring

-

The feature is active for the whole eNB. It is indicated as active if the ipSecEnabled parameter is true.

104

DN0978045

Issue: 02B


1.3.7.7 1.3.7.7.1


User interface Parameters for LTE689: LTE IPsec Support Table 48: Parameters for LTE689: LTE IPsec Support shows the parameters related to feature LTE689 LTE IPsec Support. All parameters are located in object IPSECC. Table 48

Parameters for LTE689: LTE IPsec Support

Name

Description

Range

Default value

ipSecEnabled

Activation (TRUE) / deactivation (FALSE) of IPsec

FALSE, TRUE

FALSE

ipSeccId

Identification of IPsec configuration 1...1, step 1

1

Value is always 1, not modifiable securityPolicies

List of security policies

Structure , comprising belowmentioned components

antiReplayEnable d

Activation (TRUE) / deactivation (FALSE) of anti-replay

FALSE, TRUE

TRUE

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 ceritificate 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,

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

encryptionMethod ESP encryption algorithm

10 sec

step 1 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(p 1. AES_128_CBC tried first riority 1:

120 sec

AES_128_CB C_OR_3DES_ 192_CBC(prior ity 1: AES_128_CB

2. 3DES_192_CBC tried second

Issue: 02B

DN0978045

105


Table 48


Parameters for LTE689: LTE IPsec Support (Cont.)

Name

Description

Range

Default value

AES_128_CBC, priority 2: 3DES_192_CBC)

C, priority 2: 3DES_192_C BC)

IKEencryptionMet hod

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 priority 2: second 3DES_192_CBC)

AES_128_CB C_OR_3DES_ 192_CBC(prior ity 1: AES_128_CB C, priority 2: 3DES_192_C BC)

IKEprotocol

IKE protocol version

IKE_V1, IKE_V2

IKE_V2

ipSecStatus

Treatment of traffic data packets matching the selection criteria of the IPsec policy.

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

localNetmask

Port number of local IP address

-1 ... 65535,

If value -1 is configured, the IPsec policy is valid for all ports of local IP address

step 1

Netmask of local IP address

7...15 characters

localTunnelEndpoi Local endpoint of IPsec tunnel, IP nt address entered in dotted decimal format

106

DN0978045

-1

7...15 characters

Issue: 02B


Table 48



Name

Description

Range

remoteIpAddress

Remote IP address of the data traffic packet, entered in dotted decimal format

7...15 characters

Default value

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

Netmask of remote IP address

7...15 characters

remoteTunnelEnd point

Remote endpoint of IPsec tunnel, IP address in dotted decimal format

7...15 characters

policyNumber

Security policy order number - only 0...65535, step 1 the lowest number of several equally matching policies is applied

protocol

Protocol information of the traffic data packet

-1 ... 254, step 1

-1

86400 sec

If value -1 is configured, the IPsec policy is valid for all protocols

Issue: 02B

saMaxLifeTime

Lifetime of CHILD SAs (security associations). After the timer has expired for the security association, a new security association is negotiated.

300…86400 sec, step 1 sec

ikeAssociations

List of IKE associations

Structure, comprising belowmentioned components

peerState

State of IKE peer

0...1000 characters

remoteTunnelEnd point

Remote IPsec tunnel endpoint IP address

7...45 characters

ikeId

Identification of IKE association database – value is always 1

1...1, step 1

DN0978045

1

107


Table 48

g



Name

Description

Range

Default value

operationalState

Operational state of IKE associations object - summarizes operational states of individual IKE associations

DISABLED, ENABLED

ENABLED

associationList

Information related to IPsec associations

1...4000 characters

sadbId

Identification of IPsec association database - value is always 1

1...1, step 1

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 reestablished. 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. In case of interworking with Cisco WSG as security gateway and intended eNB initiated re-keying of IKE security associations in IKEv2, the eNB default configuration for IKE encryption must be changed because of not standard compliant behavior of Cisco WSG in this regard. For such configurations, the 'IKEencryptionMethod' parameter must be either set to 'AES_128_CBC' or '3DES_192_CBC', but must not be set to 'AES_128_CBC_OR_3DES_192_CBC'.

1.3.7.7.2

Alarms for LTE689: LTE IPsec Support Table 49

Alarms for LTE689: LTE IPsec Support

Alarm number

Alarm name Condition

61030

Dead Peer Detected

A dead peer was detected in one of the IPsec associations of the FTM. Possibly • • •

108

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

DN0978045

Issue: 02B


Table 49


Alarms for LTE689: LTE IPsec Support (Cont.)

Alarm number

Alarm name Condition

7665

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 ION ALARM

one of the IPsec associations of the FTM. Possibly: – – –

1.3.7.7.3

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

Counters for LTE689: LTE IPsec Support Table 50: Counters for LTE689: LTE IPsec Support shows counters related to LTE689: LTE IPsec Support. Table 50

1.3.7.8

Counters for LTE689: LTE IPsec Support

PI ID

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

M51125C5

Bypassed_FramesRx

Number of bypassed ESP packets in ingress direction

Activating and configuring the feature For activating and configuring the feature, see Feature Activation Documentation.

Issue: 02B

DN0978045

109



1.3.8 LTE692: LTE Firewall Support 1.3.8.1

Introduction to the feature This feature provides an internal firewall to protect the eNB.

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

1.3.8.3 1.3.8.3.1



Network element


System release

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

NetAct

1.3.8.3.2


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

110

DN0978045

Issue: 02B



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 ICMPv4 is supported with the following messages: Table 52

Messages

message

receive direction (Rx)

transmit direction (Tx)

Destination Unreachable

x

x

Time Exceeded

x

Parameter Problem

x

Echo Request

x

x

Echo Reply

x

x

It is possible to disable eNB responses to ICMP Ping (Echo Request) messages and traceroute messages received over the external interfaces.

1.3.8.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,

Issue: 02B

DN0978045

111



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 order to avoid an overload of the NE internal subsystems and to limit the effect of a Denial of Service attack, the ingress packet rate can be limited separately for each of the following traffic aggregates: • • • • • • •

U-plane C- plane M-plane S-plane (ToP) ICMP Echo Request 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: •

•

•

•

112

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 attack: A Land 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:

DN0978045

Issue: 02B


•

1.3.8.4.2


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.

Firewall filter Filter rules are fixed.

Predefined packet filter rules The packet filter is automatically configured to allow the following applications and protocols for the applicable addresses and ports, based on the predefined configuration: • • • • • •

Control plane (SCTP) IKE (UDP) Timing over Packet (UDP) PW (MPLS) LDAP (TCP) CMP (TCP)

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.

1.3.8.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:

Issue: 02B

DN0978045

113


• •


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.

1.3.8.5

System impacts There are no impacts related to the feature.

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

1.3.8.7 1.3.8.7.1

User interface Parameters for LTE692: LTE Firewall Support Table 53: Parameters for LTE692: LTE Firewall Support shows parameters related to LTE692: LTE Firewall Support. All parameters are located in object IPNO. Table 53

1.3.8.7.2

Parameters for LTE692: LTE Firewall Support

Name

Description

Range

Default value

icmpResponseEnabled

This parameter controls if the BTS responds to ICMP and traceroute requests

TRUE, FALSE

TRUE

Counters for LTE692: LTE Firewall Support Table 54: Counters for LTE692: LTE Firewall Support shows counters related to LTE692: LTE Firewall Support.

114

DN0978045

Issue: 02B


Table 54

1.3.8.8


Counters for LTE692: LTE Firewall Support

PI ID

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.

1.3.9 LTE746: IP based filtering for BTS Site Support Equipment 1.3.9.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: site support equipment from harmful IP DCN traffic IP DCN from harmful IP traffic originated from site support equipment

• •

1.3.9.2

Benefits The protection against harmful manipulation of the site support equipment configuration via IP DCN is improved.

1.3.9.3 1.3.9.3.1


Issue: 02B


Network element


System release

RL10

eNodeB

LBTS1.0

MME

–

SAE GW

–

UE

–

DN0978045

115


Table 55

1.3.9.3.2



Network element


NetAct

OSS5.2 CD3


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

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, see LTE Transport functional area description. The configuration of the feature is done using BTS Site Manager from a local or remote site, or by NetAct.

1.3.9.5

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

1.3.9.6

Sales information The LTE746: IP based filtering for BTS Site Support Equipment feature is a basic software feature.

1.3.9.7 1.3.9.7.1

User interface Parameters for LTE746: IP based filtering for BTS Site Support Equipment Table 56: Parameters for LTE746: IP based filtering for BTS Site Support Equipment shows parameters related to LTE746: IP based filtering for BTS Site Support Equipment.

116

DN0978045

Issue: 02B



All parameters are located in object IPRM. Table 56

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

Full name

Description

Range / Step Default value

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, • SINGLE: a single IP address WILDCARD

(Short name)

• •

sourceTwoIpAddr

RANGE: range of IP addresses (IP address and subnet mask) WILDCARD: any IP address allowed

Meaningful only if sourceTwoDiscr is defined as SINGLE or RANGE • •

7…15 characters

0.0.0.0

7…15 characters

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

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. 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 1...1, step 1 IPRM Value is always 1, not modifiable

Issue: 02B

DN0978045

117



Table 57: 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 57

Parameter for configuring MTU size.

Full name

Description

(Short name) Maximum transfer unit (MTU)

1.3.9.8

Range / Step Default value

The size of the maximum transfer unit of 576...1608 the Ethernet interface. bytes

1500 bytes

Activating the feature This feature does not require activation.

1.3.10 LTE913: LTE NEBS compliant OMS 1.3.10.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.

1.3.10.2

Benefits Operators have accepted the Network Equipment Building Standard (NEBS) 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’s OPEX, and to reduce time to market for new network roll-outs.

1.3.10.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 blade-

118

DN0978045

Issue: 02B



based 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) – – – – –

• • • • • • • •

Radiated Emissions - Electric Fields Radiated Emissions - Magnetic Fields Conducted Emission (AC Power Leads - Voltage) Conducted Emission (AC and DC Power and Signal Leads - Current) Conducted Emission (Analog Voiceband Leads)

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.

1.3.10.4

Requirements Not applicable.

1.4 Flexi Multiradio BTS LTE Site Solution features from previous releases for RL20 1.4.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.

Issue: 02B

DN0978045

119



1.4.2 Cell-related features 1.4.2.1 1.4.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. • • •

1.4.2.1.2

LTE112: Cell bandwidth - 20 MHz offers full LTE capacity with 20 MHz LTE cellbandwidth LTE114: Cell bandwidth - 10 MHz offers support for the 10 MHz LTE cell bandwidth LTE115: Cell bandwidth - 5MHz offers support for the 5 MHz LTE cell bandwidth

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.

1.4.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:

1.4.2.1.4

Activating the feature This feature is license-based.

1.4.2.2 1.4.2.2.1

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.

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

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

120

DN0978045

Issue: 02B


1.4.2.2.4


Activating the feature The feature is activated by special software parameters, using standard Flexi Multiradio BTS System and RF Modules.

1.4.3 Antenna line features 1.4.3.1 1.4.3.1.1

LTE71: 2-way RX diversity (MRC) Introduction This feature provides two-way receive diversity for enhanced uplink coverage.

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

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

1.4.3.2 1.4.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.

1.4.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 need for site visits to tilt antennas and 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 holding and 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.

Issue: 02B

DN0978045

121


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

1.4.3.2.4

Management data This sections lists the parameters related to LTE160: Flexi Multiradio BTS 3GPP antenna tilt support. Table 58

122

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

Parameter name

MO class

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

Defines the usage of 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

Defines the manufacturer of the device.

Max Angle

RET

Defines the minimum allowed electrical tilt value.

Mechanical Angle

RET

Defines the mechanical tilt fixed by the geometry of the installation.

DN0978045

Issue: 02B


Table 58

1.4.3.2.5


The parameters related to LTE160: Flexi Multiradio BTS 3GPP antenna tilt support. (Cont.)

Parameter name

MO class

Description

Min Angle

RET

Defines the minimum allowed electrical tilt value.

SW Version

RET

Defines the RET Firmware SW Version.

Activating the feature This feature is license-based.

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

1.4.3.3.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: • • • • • •

it is easier to acquire new sites co-siting with existing 2G and 3G base stations, feeders and antennas is easier no need of long and thick antenna feeders installations optimized DL and UL RF performance - coverage and capacity - 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.

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

Issue: 02B

DN0978045

123



1.4.4 Flexi Multiradio BTS RF Modules 1.4.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.

1.4.4.2

Benefits The Flexi Multiradio BTS 3-sector RF Modules offer the following benefits: • • • • • • • •

1.4.4.3

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 the widest ambient temperature range: -35... +55 C the smallest power consumption and OPEX can be used as feederless site with one DC and 1-2 optical cables can be used as powerful one-sector Remote Radio 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.

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

1.4.4.5

LTE437: Flexi 3-sector RF Module 800EU The Flexi Multiradio BTS RF Module for 800 MHz (FRMA) supports the 3GPP band 20.

124

DN0978045

Issue: 02B


1.4.4.6 1.4.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.

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

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

1.4.5 Flexi Multiradio BTS Remote Radio Heads 1.4.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.

1.4.6 Cabinets and other Flexi Multiradio BTS hardware 1.4.6.1 1.4.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.

1.4.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).

Issue: 02B

DN0978045

125


1.4.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 shared battery backup for a single cabinet with one or two BTSs (WCDMA, EDGE, WiMax or LTE) space for the operator's own 19-inch units earthquake protection for Flexi Multiradio BTS configurations 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), needed to connect FCDA, FSEC and MIBBU alarms. OVP IP55 box (FSEC) cabinet dimensions: 1800 x 600 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 shared battery backup for a single cabinet with one or 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 for Flexi Multiradio BTS configurations having more than six modules (WCDMA, EDGE, WiMax or LTE).

The optional outdoor cabinet (FCOA) can include the following optional items: •

• •

126

Outdoor Site Support Module (FCSA with optional indoor MIBBU): 62 Ah 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)

DN0978045

Issue: 02B


•

• •

1.4.6.2 1.4.6.2.1


EAC IP55 connection box (FSEB), needed to connect the FCDA, FCFA, FSEC and FCSA alarms. FCOA includes a lock and a door alarm switch that is connected to FSEB. OVP IP55 connection box (FSEC) cabinet dimensions: 1550 x 770 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).

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.

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

1.4.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, the Flexi Multiradio BTS Power Battery Sub-Module (FPAA) and the optional battery (FPBA). The main function of the FPAA is to provide the BTS modules with 48 V DC power from an AC current. The FPBA, a maintenance free Lithium-Ion battery, brings significant OPEX savings over its ten-year battery lifetime. 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.

1.4.6.3 1.4.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.

Issue: 02B

DN0978045

127


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

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

1.4.7 LTE80: GPS synchronization 1.4.7.1

Introduction External GPS synchronization can be used for frequency synchronization on sites utilizing Ethernet transport.

1.4.7.2

Benefits A reliable frequency reference can be provided for sites using asynchronous transport media unable to provide a frequency reference for the Flexi Multiradio BTS.

1.4.7.3

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 Multiradio BTS System Module. DC power for the GPS receiver is supplied through the combined power and control cable connected to the MDR-26 Sync interface of the Flexi

128

DN0978045

Issue: 02B



Multiradio BTS System Module. The Flexi Multiradio BTS System Module provides a power feeding of 12 V which allows for cable lengths of more than 200 m. For FDD LTE, GPS synhronization at a BTS site is an optional feature if Timing Over Packet (ToP) or Synchronous Ethernet are not used in the transport network.

1.4.8 Power support features 1.4.8.1 1.4.8.1.1

LTE900: Flexi Multiradio BTS 40 W power support Introduction Flexi Multiradio BTS 40 W RF Power licence activates 40 W power mode to one TX Power Amplifier of Flexi Multiradio BTS RF Module in LTE mode.

1.4.8.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 licences. Therefore there is no need for separate RF Module Power variants. No site visits are needed because RF capacity increase is possible 'Pay as you grow' - the no-site-visit principle. 60 W in LTE is needed especially at higher RF bandwidths, e.g. at 15 MHz or 20 MHz bandwidth in order to keep coverage with high capacity. One RF Module hardware model brings savings in spare part stock, logistics, and maintenance.

1.4.8.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. In SIMO (Single 1TX) BTS configuration one 60 W Power licence is needed per sector. In 2TX MIMO (two active TX paths) BTS configuration two 60 W Power licences are needed per sector. Required hardware: • •

1.4.8.2 1.4.8.2.1

Flexi Multiradio 3-sector RF Module for all RF band variants. Tentatively, 60 W power mode not needed for any Remote Radio Head (RRH) 2TX (30+30W) MIMO product.

LTE901: Flexi Multiradio BTS 8 W power support Introduction Flexi Multiradio BTS 8 W RF Power licence enables 8 W RF power mode operation with Flexi Multiradio BTS RF Module in LTE mode.

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

Issue: 02B

DN0978045

129


1.4.8.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 teh 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: • •

1.4.8.3 1.4.8.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 BTS 60 W RF Power licence activates the 60 W RF power mode to one TX path of Flexi BTS RF Module in LTE mode. 60 W TX power is at 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 RF Module version.

1.4.8.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 licences. Therefore, there is no need for separate RF Module Power variants. No site visits are needed because RF capacity increase is possible 'Pay as you grow' - the no-site-visits principle. 60 W in LTE is needed especially at higher RF bandwidths, e.g. at 15 MHz or 20 MHz bandwidt in order to keep coverage with high capacity. One RF Module hardware model brings savings in spare part stock, logistics, and maintenance.

1.4.8.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 SIMO (Single 1TX) BTS configuration one 60 W Power licence is needed per sector. In 2TX MIMO (two active TX paths) BTS configuration, two 60 W Power licences are needed per sector. Required hardware: • •

130

Flexi Multiradio 3-sector RF Module for all RF band variants. Tentatively, 60 W power mode not needed for any Remote Radio Head (RRH) 2TX (30+30W) MIMO product.

DN0978045

Issue: 02B


1.4.8.4 1.4.8.4.1


LTE904: Flexi LTE BTS Branch Activation Introduction The Downlink TX Branch Activation (BA) licence is needed to activate one TX of the Flexi 3-sector RF Module. One branch activation licence 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.

1.4.8.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 one, two and three sector RF Modules, savings are achieved in logistics, spare parts and maintenance.

1.4.8.4.3

Functional description In order to activate any LTE cells in a Flexi 3-sector RF Module, at least one Branch Activation licence is needed for each sector. In a SIMO (Single 1TX) BTS configuration, one Branch Activation licence is needed per active sector. In a 2TX MIMO (two active TXs) BTS configuration, two Branch Activation licences are needed per sector. This 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 licence for each active TX branch, i.e. two Branch Activation licences are needed for the 20 W + 20 W 2TX MIMO operation mode per sector and per each RRH.

Issue: 02B

DN0978045

131

Nokia LTE RL10 Features

Recommend Documents