Feature Descriptions RL10
DN0978045
Issue 02B
Approval Date 2012-09-30
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 documen- tation has been prepared to be used by professional and properly trained personnel, and the cus-tomer 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 documenta-tion.
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 aris-ing 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 con-tained 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 DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DA-TA,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 respec-tive 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 ser-vices we offer, please contact us at Nokia Solutions and Networks for any additional information.
Summary of Changes... 15 1 Feature Descriptions RL10... 16 1.1 Radio resource management and telecom features from previous releases for RL20... 16 1.1.1 LTE28: Closed loop UL power control...16 1.1.1.1 Introduction to the feature... 16 1.1.1.2 Benefits... 16 1.1.1.2.1 End user benefits... 16 1.1.1.2.2 Operator benefits... 16 1.1.1.3 Requirements... 17 1.1.1.3.1 Software requirements... 17 1.1.1.3.2 Hardware requirements...17 1.1.1.4 Functional description... 17 1.1.1.4.1 Functional details... 17 1.1.1.4.1.1 Messages and information elements... 19 1.1.1.5 System impacts... 20 1.1.1.5.1 Interdependencies between features... 20 1.1.1.5.2 Impacts on interfaces... 20 1.1.1.5.3 Impacts on performance and capacity... 20 1.1.1.6 User interface... 20 1.1.1.6.1 Parameters...20 1.1.1.6.2 Measurements and counters...23 1.1.1.7 Activating The Feature... 24 1.1.1.8 Abbreviations... 24 1.1.1.8.1 0 – Z... 24 1.1.2 LTE30: CQI adaption (DL)...24 1.1.2.1 Introduction to the feature... 24 1.1.2.2 Benefits... 25 1.1.2.3 Requirements... 25 1.1.2.3.1 Software requirements... 25 1.1.2.3.2 Hardware requirements...25 1.1.2.4 Functional description... 25 1.1.2.4.1 Functional details... 25 1.1.2.5 System impacts... 26 1.1.2.5.1 Interdependencies between features... 26 1.1.2.6 User interface... 26 1.1.2.6.1 Parameters...26 1.1.2.7 Activating The Feature... 27 1.1.3 LTE37: Ciphering and LTE38: Integrity protection...27 1.1.3.1 Introduction to the feature... 27 1.1.3.2 Benefits... 28
1.1.3.4 Functional description... 29 1.1.3.4.1 Functional overview... 29 1.1.3.4.2 Security keys... 30 1.1.3.4.3 Messages and information elements... 33 1.1.3.5 System impacts... 35 1.1.3.5.1 Interdependencies between features... 35 1.1.3.5.2 Impacts on network elements... 35 1.1.3.5.3 Impacts on system performance and capacity... 35 1.1.3.6 User interface... 35 1.1.3.6.1 Parameters...35 1.1.3.7 Activating The Feature... 36 1.1.4 LTE43: Support of 64 QAM in DL, LTE788: Support of 16 QAM (UL), LTE793: Support of 16 QAM (DL)... 36 1.1.4.1 Introduction to the feature... 36 1.1.4.2 Benefits... 36 1.1.4.3 Requirements... 37 1.1.4.3.1 Software requirements... 37 1.1.4.3.2 Hardware requirements...37 1.1.4.4 Functional description... 38 1.1.4.4.1 Functional details... 38 1.1.4.5 System impacts... 38 1.1.4.5.1 Interdependencies between features... 38 1.1.4.6 Sales information... 38 1.1.4.7 User interface... 39 1.1.4.7.1 Managed objects... 39 1.1.4.7.2 Parameters...39 1.1.4.7.3 Measurements and counters...39 1.1.4.8 Activating The Features... 41 1.1.4.9 Abbreviations... 41 1.1.4.9.1 0 – Z... 41 1.1.5 LTE69: Transmit diversity for two antennas and LTE70: Downlink adaptive open loop MIMO for two antennas... 43 1.1.5.1 Introduction to the feature... 43 1.1.5.2 Benefits... 43 1.1.5.2.1 End user benefits... 43 1.1.5.2.2 Operator benefits... 43 1.1.5.3 Requirements... 43 1.1.5.3.1 Software requirements... 44 1.1.5.3.2 Hardware requirements...44 1.1.5.4 Functional description... 44 1.1.5.4.1 Functional overview... 44 1.1.5.4.2 Downlink adaptive open loop MIMO for two antennas...44 1.1.5.4.2.1 Receive diversity... 46
1.1.5.4.4 Open loop spatial multiplexing... 48 1.1.5.5 System impacts... 49 1.1.5.5.1 Interdependencies between features... 49 1.1.5.5.2 Impacts on interfaces... 49 1.1.5.5.3 Impacts on network and network element management tools... 49 1.1.5.5.4 Impacts on system performance and capacity... 49 1.1.5.6 Sales information... 49 1.1.5.7 User interface... 49 1.1.5.7.1 Managed Objects... 50 1.1.5.7.2 Parameters...50 1.1.5.7.3 Alarms... 51 1.1.5.7.4 Measurements and counters...51 1.1.5.8 Activating the Feature... 51 1.2 Transport and transmission features from previous releases for RL20...51 1.2.1 LTE713: Synchronous Ethernet... 51 1.2.1.1 Introduction to the Feature... 51 1.2.1.2 Benefits... 51 1.2.1.3 Requirements... 51 1.2.1.3.1 Software Requirements...51 1.2.1.3.2 Hardware Requirements... 52 1.2.1.4 Functional Description...52 1.2.1.4.1 Synchronization Status Messages (SSM)... 52 1.2.1.5 Sales Information... 53 1.2.1.6 User Interface...53 1.2.1.6.1 Parameters...53 1.2.1.6.2 Alarms... 54 1.2.1.6.3 Measurements and Counters... 54 1.2.1.7 Activating and Configuring the Feature...54 1.2.2 LTE132: VLAN based traffic differentiation ... 54 1.2.2.1 Introduction to the Feature... 54 1.2.2.2 Benefits... 54 1.2.2.3 Requirements... 55 1.2.2.3.1 Software Requirements...55 1.2.2.3.2 Hardware Requirements... 55 1.2.2.4 Functional Description...55 1.2.2.4.1 Network Scenarios with VLAN based Traffic Differentiation...56 1.2.2.4.1.1 X2 interface via IPsec Star Configuration... 57 1.2.2.4.2 VLAN based Traffic Differentiation: Mapping of DL Packets in the Security Gateway... 58 1.2.2.4.3 VLAN based Traffic Differentiation: Mapping of DL Packets in the VLAN Gateway...59 1.2.2.5 Sales Information... 59
1.2.2.6.3 Measurements and Counters... 60 1.2.2.7 Activating and Configuring the Feature...61 1.2.3 LTE134: Timing over packet...61 1.2.3.1 LTE134: Timing over Packet... 61 1.2.3.1.1 Benefits... 61 1.2.3.1.2 Requirements... 61 1.2.3.1.3 Functional Description...62 1.2.3.1.3.1 ToP Master... 62 1.2.3.1.3.2 ToP Slave... 62 1.2.3.1.3.3 Support of IEEE 1588 Event Messages...63 1.2.3.1.4 Management data... 64 1.2.3.1.5 Sales information... 65 1.2.3.1.6 Activating and configuring the feature...65 1.3 Operability features from previous releases for RL20... 65 1.3.1 LTE150: LTE OAM Transport Layer Security (TLS) Support...65 1.3.1.1 Introduction to the feature... 65 1.3.1.2 Benefits... 65 1.3.1.3 Requirements... 66 1.3.1.3.1 Software requirements... 66 1.3.1.3.2 Hardware requirements...66 1.3.1.4 Functional description for LTE OAM Transport Layer Security (TLS) Support...66 1.3.1.4.1 Secure BTS Site Manager connection... 69 1.3.1.5 System impact...69 1.3.1.5.1 Interdependencies between features... 69 1.3.1.5.2 Impact on interfaces... 69 1.3.1.5.3 Impact on network and network element management tools...69 1.3.1.5.4 Impact on system performance and capacity...69 1.3.1.6 Sales information... 69 1.3.1.7 Parameters for LTE150: LTE OAM Transport Layer Security (TLS) Support...70 1.3.1.8 Alarms for LTE150: LTE OAM Transport Layer Security (TLS) Support...70 1.3.2 LTE432: Cell Outage Detection...71 1.3.2.1 Introduction... 71 1.3.2.2 Benefits... 71 1.3.2.3 Requirements... 71 1.3.2.3.1 Software Requirements for LTE432... 71 1.3.2.3.2 Software Requirements for LTE502... 71 1.3.2.3.3 Hardware Requirements... 71 1.3.2.4 Functional Description...72 1.3.2.4.1 LTE432: Cell Outage Detection...72 1.3.2.4.1.1 Failure Scenarios... 72
1.3.2.5.1 Interdependencies between Features...74 1.3.2.6 Sales Information... 74 1.3.2.7 User Interface...74 1.3.2.7.1 Parameters for LTE432: Cell outage detection... 74 1.3.2.7.1.1 LTE502: Cell outage triggered reset...75 1.3.2.7.2 Alarms for LTE432: Cell outage detection...75 1.3.2.7.2.1 Alarms for LTE502: Cell outage triggered reset... 76 1.3.2.7.3 Measurements and Counters for LTE432: Cell outage detection.... 76 1.3.2.8 System Responses to Failures... 77 1.3.2.9 Activating the Feature... 77 1.3.2.10 Abbreviations... 77 1.3.2.10.1 0 – Z... 77 1.3.3 LTE539: Central ANR...78 1.3.3.1 Introduction... 78 1.3.3.2 Benefits... 78 1.3.3.2.1 Operator Benefits... 78 1.3.3.3 Requirements... 78 1.3.3.3.1 Software Requirements...78 1.3.3.3.2 Hardware Requirements... 79 1.3.3.4 LTE539: Central ANR...79 1.3.3.4.1 Functional Overview/Details...79 1.3.3.4.1.1 NetAct Optimizer... 79 1.3.3.4.1.2 NetAct Configurator...83 1.3.3.4.1.3 Integration in the Auto configuration Workflow...84 1.3.3.5 System Impacts...84 1.3.3.5.1 Interdependencies Between Features... 84 1.3.3.6 Sales Information... 85 1.3.3.7 Activating and Configuring the Feature...85 1.3.3.8 Abbreviations... 85 1.3.3.8.1 0 – Z... 85 1.3.4 LTE665:Certificate Management and LTE685:Infrastructures for Certification Authority (CA) and Registration Authority (RA)... 86 1.3.4.1 Introduction to the feature... 86 1.3.4.1.1 LTE665: LTE Certificate Management... 86 1.3.4.1.2 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA) ... 86 1.3.4.2 Benefits... 86 1.3.4.2.1 LTE665: LTE Certificate Management... 86 1.3.4.2.2 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA)... 86 1.3.4.3 Requirements... 86 1.3.4.3.1 Software requirements... 86
1.3.4.4.2 LTE685: Infrastructures for Certification Authority (CA) and Registration Authority (RA)... 91 1.3.4.5 System impacts... 93 1.3.4.6 Sales information... 93 1.3.4.7 User interface... 93 1.3.4.7.1 Parameters for LTE665: LTE Certificate Management...93 1.3.4.7.2 Alarms for LTE665: LTE Certificate Management... 94 1.3.4.8 Activating and configuring the feature...95 1.3.5 LTE666: LTE User Account Management... 95 1.3.5.1 Introduction to the feature... 95 1.3.5.2 Benefits... 95 1.3.5.3 Requirements... 96 1.3.5.3.1 Software Requirements...96 1.3.5.3.2 Hardware Requirements... 96 1.3.5.4 Functional description for user security...96 1.3.5.4.1 Authentication and authorization...96 1.3.5.4.2 Disabling user accounts in NetAct... 97 1.3.5.4.3 User management...97 1.3.5.4.3.1 Mass updating of eNB local user accounts... 97 1.3.5.4.4 Audit trail... 97 1.3.5.5 System impacts... 98 1.3.5.6 Sales information... 98 1.3.5.7 User interface... 99 1.3.5.7.1 Parameters for LTE666: LTE User Account Management... 99 1.3.5.7.2 Alarms for LTE666: LTE User Account Management...99 1.3.5.8 Activating and configuring the feature...100 1.3.6 LTE679: LTE Local User Account Management... 100 1.3.6.1 Introduction to the feature... 100 1.3.6.2 Benefits... 100 1.3.6.3 Requirements... 100 1.3.6.3.1 Software requirements... 100 1.3.6.3.2 Hardware requirements...101 1.3.6.4 Functional description for LTE Local User Account Management... 101 1.3.6.5 System impacts... 101 1.3.6.6 Sales information... 101 1.3.6.7 User interface... 101 1.3.6.7.1 Parameters for LTE679: LTE Local User Account Management... 101 1.3.6.8 Activating the feature... 101 1.3.7 LTE689: LTE IPsec Support... 101 1.3.7.1 Introduction to the feature... 101 1.3.7.2 Benefits... 102
1.3.7.4 Functional description for IPsec Support... 103 1.3.7.4.1 Transport security...104 1.3.7.5 System impacts... 104 1.3.7.6 Sales information... 104 1.3.7.7 User interface... 105 1.3.7.7.1 Parameters for LTE689: LTE IPsec Support... 105 1.3.7.7.2 Alarms for LTE689: LTE IPsec Support...108 1.3.7.7.3 Counters for LTE689: LTE IPsec Support... 109 1.3.7.8 Activating and configuring the feature...109 1.3.8 LTE692: LTE Firewall Support... 110 1.3.8.1 Introduction to the feature...110 1.3.8.2 Benefits...110 1.3.8.3 Requirements... 110 1.3.8.3.1 Software requirements... 110 1.3.8.3.2 Hardware requirements... 110 1.3.8.4 Functional description for LTE Firewall Support... 110 1.3.8.4.1 Firewall functionality... 111 1.3.8.4.2 Firewall filter... 113 1.3.8.4.3 Logging...113 1.3.8.5 System impacts... 114 1.3.8.6 Sales information...114 1.3.8.7 User interface... 114 1.3.8.7.1 Parameters for LTE692: LTE Firewall Support... 114 1.3.8.7.2 Counters for LTE692: LTE Firewall Support... 114 1.3.8.8 Activating and configuring the feature... 115 1.3.9 LTE746: IP based filtering for BTS Site Support Equipment... 115 1.3.9.1 Introduction to the feature...115 1.3.9.2 Benefits...115 1.3.9.3 Requirements... 115 1.3.9.3.1 Software requirements... 115 1.3.9.3.2 Hardware requirements... 116 1.3.9.4 Functional description for IP based filtering for BTS Site Support Equipment... 116 1.3.9.5 System impacts... 116 1.3.9.6 Sales information...116 1.3.9.7 User interface... 116 1.3.9.7.1 Parameters for LTE746: IP based filtering for BTS Site Support Equipment... 116 1.3.9.8 Activating the feature...118 1.3.10 LTE913: LTE NEBS compliant OMS... 118 1.3.10.1 Introduction to the Feature... 118 1.3.10.2 Benefits...118 1.3.10.3 Functional Description... 118
1.4.1 Introduction to the Flexi Multiradio BTS Site Solution features.. 119 1.4.2 Cell-related features... 120 1.4.2.1 LTE cell bandwidth features: LTE112,LTE114, and LTE115... 120 1.4.2.1.1 Introduction... 120 1.4.2.1.2 Functional description... 120 1.4.2.1.3 Benefits... 120 1.4.2.1.4 Activating the feature... 120 1.4.2.2 LTE97: Cell radius max 77 km... 120 1.4.2.2.1 Introduction... 120 1.4.2.2.2 Benefits... 120 1.4.2.2.3 Functional description... 120 1.4.2.2.4 Activating the feature... 121 1.4.3 Antenna line features... 121 1.4.3.1 LTE71: 2-way RX diversity (MRC)...121 1.4.3.1.1 Introduction... 121 1.4.3.1.2 Benefits... 121 1.4.3.1.3 Functional description... 121 1.4.3.2 LTE160: Flexi Multiradio BTS 3GPP antenna tilt support... 121 1.4.3.2.1 Introduction... 121 1.4.3.2.2 Benefits... 121 1.4.3.2.3 Functional description... 122 1.4.3.2.4 Management data... 122 1.4.3.2.5 Activating the feature... 123 1.4.3.3 LTE94: Feederless site...123 1.4.3.3.1 Introduction... 123 1.4.3.3.2 Benefits... 123 1.4.3.3.3 Functional description... 123 1.4.4 Flexi Multiradio BTS RF Modules...124 1.4.4.1 Introduction... 124 1.4.4.2 Benefits... 124 1.4.4.3 LTE85: Flexi 3-sector RF Module 2600 (FRHA)...124 1.4.4.4 LTE99: Flexi 3-sector RF Module 1.7/2.1 (FRIE)... 124 1.4.4.5 LTE437: Flexi 3-sector RF Module 800EU...124 1.4.4.6 LTE96: MIMO 2TX configuration with 3-sector RF Module... 125 1.4.4.6.1 Introduction... 125 1.4.4.6.2 Benefits... 125 1.4.4.6.3 Functional description... 125 1.4.5 Flexi Multiradio BTS Remote Radio Heads...125 1.4.5.1 Benefits... 125 1.4.6 Cabinets and other Flexi Multiradio BTS hardware...125 1.4.6.1 LTE79: Flexi Indoor (FCIA) and Outdoor (FCOA) Cabinets... 125 1.4.6.1.1 Introduction... 125 1.4.6.1.2 Benefits... 125
1.4.6.2.2 Benefits... 127 1.4.6.2.3 Functional description... 127 1.4.6.3 LTE82: High-capacity Flexi System Module (FSME)... 127 1.4.6.3.1 Introduction... 127 1.4.6.3.2 Benefits... 128 1.4.6.3.3 Functional description... 128 1.4.7 LTE80: GPS synchronization... 128 1.4.7.1 Introduction... 128 1.4.7.2 Benefits... 128 1.4.7.3 Functional description... 128 1.4.8 Power support features... 129 1.4.8.1 LTE900: Flexi Multiradio BTS 40 W power support...129 1.4.8.1.1 Introduction... 129 1.4.8.1.2 Benefits... 129 1.4.8.1.3 Functional description... 129 1.4.8.2 LTE901: Flexi Multiradio BTS 8 W power support...129 1.4.8.2.1 Introduction... 129 1.4.8.2.2 Benefits... 129 1.4.8.2.3 Functional description... 130 1.4.8.3 LTE903: Flexi Multiradio BTS 60 W power support...130 1.4.8.3.1 Introduction... 130 1.4.8.3.2 Benefits... 130 1.4.8.3.3 Functional description... 130 1.4.8.4 LTE904: Flexi LTE BTS Branch Activation... 131 1.4.8.4.1 Introduction... 131 1.4.8.4.2 Benefits... 131 1.4.8.4.3 Functional description... 131
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
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 Software requirements for different network elements... 25 Table 6 Software requirements for different network elements... 28 Table 7 Security related messages and information elements...33 Table 8 Parameters for ciphering and integrity protection...35 Table 9 Software requirements for different network elements... 37 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 Software requirements for different network elements... 52 Table 15 Parameters related to the LTE713: Synchronous Ethernet feature.... 53 Table 16 Software requirements for different network elements... 55 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 Software requirements for different network elements... 62 Table 22 Parameters related to the LTE134: Timing over packet feature... 64 Table 23 Sales information...65 Table 24 Software requirements for different network elements... 66 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 Software requirements for different network elements... 71 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 Software requirements for different network elements... 78 Table 35 Interdependencies between features... 84 Table 36 Software requirements for different network elements... 86
Table 39 Software requirements for different network elements... 96 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 Software requirements for different network elements... 102 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 Software requirements for different network elements... 110 Table 52 Messages...111 Table 53 Parameters for LTE692: LTE Firewall Support... 114 Table 54 Counters for LTE692: LTE Firewall Support... 115 Table 55 Software requirements for different network elements... 115 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
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)
• Vendor Certificate revocation section has been added
• Identity management server solution section has been updated • Factory trust anchor section has been updated.
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 Benefits
1.1.1.2.1 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 intra-cell orthogonality.1.1.1.3 Requirements
1.1.1.3.1 Software requirements
Table 1 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 –
1.1.1.3.2 Hardware requirements
This feature does not require any additional hardware.1.1.1.4 Functional description
1.1.1.4.1 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-to-interference 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).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 high_lev_thresh low_lev_thresh high_qual_thresh low_qual_thresh high low medium m e d iu m p o o r g o o d SINR RSSI + 1 dB or + 3 dB + 1 dB or + 3 dB + 1 dB or + 3 dB + 1 dB or + 3 dB + 1 dB or + 3 dB - 1 dB - 1 dB - 1 dB 0 dB
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 C-RNTI 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.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 System impacts
1.1.1.5.1 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 User interface
1.1.1.6.1 Parameters
The following table shows the parameters implemented for the feature. Parameters common for closed loop and open loop uplink power control are shown in the second table.Table 2 Parameters for closed loop UL power control
Name Object Description Range Default value
Enable Closed Loop Uplink Power Control (ulpcEnable) LNCEL This parameter allows to enable/disable closed loop uplink power control. 0 (false) 1 (true) 0 Include PUCCH Measurements In CL Power Control (ulpcPucchEn) LNCEL Including or excluding of RSSI and SINR measurements from PUCCH in the closed loop PC component. 0 (false) 1 (true) 1 Include PUSCH Measurements In CL Power Control (ulpcPuschEn) LNCEL Including or excluding of RSSI and SINR measurements from PUSCH in the closed loop PC component. 0 (false) 1 (true) 1 Lower RSSI Threshold For PUCCH Power Command Decision (ulpcLowlevCch) LNCEL Lower threshold of the power control window for the RSSI (signal level) for PUCCH component. -127...0 dBm step 1 dBm -103 dBM Lower RSSI Threshold For PUSCH Power Command Decision (ulpcLowlevSch) LNCEL Lower threshold of the power control window for the RSSI (signal level) for PUSCH/SRS component. -127...0 dBm step 1 dBm -103 dBM Lower SINR Threshold For PUCCH Power Command Decision (ulpcLowqualCch) LNCEL Lower threshold of the power control window for the SINR (signal quality) for PUCCH component. -47...80 dB step 1 dB 1 dB Lower SINR Threshold For PUSCH Power Command Decision (ulpcLowqualSch) LNCEL Lower threshold of the power control window for the SINR (signal quality) for PUSCH/SRS component. -47...80 dB step 1 dB 8 dB Upper RSSI Threshold For PUCCH Power Command Decision (ulpcUplevCch) LNCEL Upper threshold of the power control window for the RSSI (signal level) for PUCCH component. -127...0 dBm step 1 dBm -98 dBM Upper RSSI Threshold For PUSCH Power Command Decision (ulpcUplevSch) LNCEL Upper threshold of the power control window for the RSSI (signal level) for PUSCH/SRS component. -127...0 dBm step 1 dBm -98 dBm
Table 2 Parameters for closed loop UL power control (Cont.)
Name Object Description Range Default value
Upper SINR Threshold For PUCCH Power Command Decision (ulpcUpqualCch) LNCEL Upper threshold of the power control window for the SINR (signal quality) for PUCCH component. -47...80 dB step 1 dB 4 dB Upper SINR Threshold For PUSCH Power Command Decision (ulpcUpqualSch) LNCEL Upper threshold of the power control window for the SINR (signal quality) for PUSCH/SRS component. -47...80 dB step 1 dB 11 dB Time Interval For Power Command Decisions (ulpcReadPeriod) LNCEL 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 10 ms 50 ms Table 3 Parameters common for open and closed loop UL power control
Name Object Description Range Default value
Enabled TB Size Impact To UE PUSCH Power Calculation (deltaTfEnabled) LNCEL This parameter enables/disables a transport format dependent offset on a per UE basis. In 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. 0 (false), 1 (true) 1 DeltaF PUCCH Format 1 (dFpucchF1) LNCEL This parameter parameter defines the deltaF PUCCH Format 1. 0 (-2), 1 (0), 2 (2) 1 DeltaF PUCCH Format 1b (dFpucchF1b) LNCEL This parameter parameter defines the deltaF PUCCH Format 1b. 0 (1), 1 (3), 2 (5) 0 DeltaF PUCCH Format 2 (dFpucchF2) LNCEL This parameter parameter defines the deltaF PUCCH Format 2. 0 (-2), 1 (0), 2 (1), 3 (2) 1 DeltaF PUCCH Format 2a (dFpucchF2a) LNCEL This parameter parameter defines the deltaF PUCCH Format 2a. 0 (-2), 1 (0), 2 (2) 1
Table 3 Parameters common for open and closed loop UL power control (Cont.)
Name Object Description Range Default value
DeltaF PUCCH Format 2b (dFpucchF2b) LNCEL This parameter parameter defines the deltaF PUCCH Format 2b. 0 (-2), 1 (0), 2 (2) 1 Filter Coefficient (filterCoeff) LNCEL This parameter specifies the filtering coefficient used for RSRP (3GPP: TS 36.331) 0 (fc0), 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) 4
1.1.1.6.2 Measurements and counters
Counters for: LTE CELL LOAD MEASUREMENT
Table 4 New and modified counters
Counter Number Description TPC -1dB for PUCCH M8001CR D900 Number of sent TPC -1 dB values for PUCCH. Updated when Closed Loop UL power command for PUCCH with value -1 dB is sent on PDCCH to UE. TPC -0dB for PUCCH M8001CR D901 Number of sent TPC 0 dB values for PUCCH. Updated when Closed Loop UL power command for PUCCH with value 0 dB is sent on PDCCH to UE. TPC +1dB for PUCCH M8001CR D902 Number of sent TPC +1 dB values for PUCCH.
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 D903 Number of sent TPC +3 dB values for PUCCH. Updated when Closed Loop UL power command for PUCCH with value +3 dB is sent on PDCCH to UE. TPC -1dB for PUSCH M8001CR D904 Number of sent TPC -1 dB values for PUSCH. Updated when Closed Loop UL power command for PUSCH with value -1 dB is sent on PDCCH to UE. TPC -0dB for PUSCH M8001CR D905 Number of sent TPC 0 dB values for PUSCH. Updated when Closed Loop UL power command for PUSCH with value 0 dB is sent on PDCCH to UE. TPC +1dB for PUSCH M8001CR D906 Number of sent TPC +1 dB values for PUSCH. Updated when Closed Loop UL power command for PUSCH with value +1 dB is sent on PDCCH to UE. TPC +3dB for PUSCH M8001CR D907 Number of sent TPC +3 dB values for PUSCH. 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 Abbreviations
1.1.1.8.1 0 – Z
A
xxx1.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
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 Requirements
1.1.2.3.1 Software requirements
Table 5 Software requirements for different network elementsNetwork element Required software release
System release RL09 eNodeB LBTS0.5 MME – SAE GW – UE 3GPP release 8 NetAct –
1.1.2.3.2 Hardware requirements
This feature does not require any additional hardware.1.1.2.4 Functional description
1.1.2.4.1 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.Figure 2 Principle of CQI adaptation eNodeB CQI adaptation ACK NACK CQI report Data blocks UE DL link adaptation: Select MCS ΔCQI(t-1) + CQI Δ stepup = CQI(t)
ΔCQI(t-1) + CQIstepdown = CQI(t)Δ
CQIreported + ΔCQI = CQIcorrected
(PDSCH) (PUCCH/PUSCH) ACK/NACK (PUCCH/PUSCH) CQIreported Additionally: CQI between Δ
CQImax and CQImin
Packet scheduler transport block transmissions 1st DL Evaluate reference signals Decode transport blocks 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 System impacts
1.1.2.5.1 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 User interface
1.1.2.6.1 Parameters
The following table shows the parameters implemented for the feature “LTE30: CQI adaption (DL)”.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):
• 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 NULL-algorithm 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 Requirements
1.1.3.3.1 Software requirements
Table 6 Software requirements for different network elementsNetwork element Required software release
System release RL10 eNodeB LBTS1.0 MME NS10 CD2 SAE GW – UE 3GPP release 8 NetAct –
1.1.3.3.2 Hardware requirements
This feature does not require any additional hardware.1.1.3.4 Functional description
1.1.3.4.1 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 IPv4/IPsec RRC RRC S1AP/X2AP SCTP PDCP PDCP . . . . . . . . . NAS S1AP NAS IPv4/IPsec SCTP . . . eNB MME UE RRC X2AP . . . . . . eNB integrity protected integrity protected integrity protected, ciphered integrity protected, ciphered L3 AP L2 L3 L4 AP: Application Layer L2, L3, ...: Layer 2, Layer 3, ... ciphered ciphered Figure 4 U-plane security IPv4/IPsec GTP-U UDP PDCP PDCP . . . . . . . . . Data stream GTP-U IPv4/IPsec UDP . . . eNB S-GW UE GTP-U . . . . . . eNB
ciphered protectedintegrity
integrity protected, ciphered PDCP ciphered GTP-U IPv4/IPsec UDP . . . P-GW Data stream integrity protected ciphered AP L3 L4 L2 AP: Application Layer L2, L3, ...: Layer 2, Layer 3, ... C-plane security includes the following characteristics: • 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.
• 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 certaineNodeB 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.
Figure 5 Security key hierarchy K NASint K NASenc IK CK K K ASME K eNB K UPenc K RRCint K RRCenc K eNB K KUPenc RRCint K RRCenc UE eNB IK CK K K ASME HSS K NASint K NASenc K eNB K ASME MME AS keys for C-plane and U-plane traffic Keys for NAS signalling AS area NAS area
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 EMM-REGISTERED state is ongoing.
• The AS keys KeNB, KUPenc, KRRCint, and KRRCenc are created on RRC-IDLE to RRC-CONNECTED transitions (correlated with ECM-IDLE to ECM-CONNECTED transitions) when in EMM-REGISTERED state (as the UE is in EMM-REGISTERED state, an EPS security context already exists in the UE and the MME) and they exist during RRC-CONNECTED state. The eNodeB deletes the keys after receiving the S1AP: UE CONTEXT RELEASE COMMAND message.
Key establishment and key distribution
The different security keys are established during specific key establishment procedures: • Authentication and Key Agreement (AKA): This procedure is performed when a UE
initially attaches to the network. The MME authenticates the subscriber, and the keys CK, IK, and KASME are established, once in the USIM/UE, and in the same way in the AuC/HSS. KASME is derived from CK, IK and the PLMN ID; the HSS transfers KASME to the MME. AKA is a NAS procedure and does not have any prerequisite besides the permanent key K.
• NAS Security Mode Command (NAS SMC) procedure: This procedure is performed
when the UE has successfully been authenticated. MME and UE generate the NAS keys KNASenc and KNASint for NAS 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 RRC-CONNECTED 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).
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 KeNBfrom 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 re-calculate 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
RRC messages
SECURITY MODE COMMAND “securityConfigSMC” “securityAlgorithmConfig” IE (“cipheringAlgorithm” and “integrityProtAlgorithm”) RRC CONNECTION REESTABLISHMENT
REQUEST
“ue-Identity” shortMAC-I
RRC CONNECTION RECONFIGURATION “securityConfigHO” “keyChangeIndicator” (not processed by the eNodeB)
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 “nas-SecurityParamFromEUTR 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” “UE Security Capabilities” “SecurityContext” (see above) (see below) NH parameter NCC related to NH. HANDOVER COMMAND “NAS Security Parameters from E-UTRAN” “HandoverPreparationinformation” such 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)
1.1.3.5 System impacts
1.1.3.5.1 Interdependencies between features
An additional security feature is the optional LTE689 “LTE IPsec support” which allows secure eNodeB control and secure bulk data communication between eNodeBs as well as between eNodeBs and core nodes. IPsec is related to transport and application protocols. Supported IPsec capabilities are data integrity protection, 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 User interface
1.1.3.6.1 Parameters
Table 8 Parameters for ciphering and integrity protection
Full name (Short name) Object Description Range / Step Default value Ciphering Algorithm Activation (actCiphering) LNBTS This parameter allows to enable/disable the optional ciphering algorithms. false (0), true (1) true (1) Ciphering Algorithm Preference List (cipherPrefL) LNBTS A list of supported AS ciphering algorithms. The algorithm is identified by the parameter name, and the assigned value determines the algorithm preference. – – Integrity Protection Algorithm Preference List (integrityPrefL) 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. – – Key Refresh Margin (keyRefrMarg) 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, step 1 50 000
Table 8 Parameters for ciphering and integrity protection (Cont.)
Full name (Short name) Object Description Range / Step Default value Null Ciphering Algorithm Fallback (nullFallback) 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)
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: • LTE793:”Support of 16QAM (DL)” • LTE788:”Support of 16QAM (UL)” • LTE43:”Support of 64QAM in DL”