LTE RAN System Description

Nokia Siemens Networks LTE
Radio access, rel. RL10,

operating documentation, pre-
release 02
LTE RAN system description
DN0943905
Issue 01B DRAFT APPROVED
Approval Date 2010-02-23
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 Siemens 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 Siemens 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 Siemens 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 Siemens Networks and the customer. However,
Nokia Siemens 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
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens 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 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.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2010. All rights reserved
f Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment.
Some of the parts may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal
injury or in property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected
has to comply with the applicable safety standards.
The same text in German:

Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-
nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-
zungen und Sachschäden führen.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die
Anlagen installiert und wartet.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
2 Id:0900d805806eda7f
DN0943905 Issue 01B DRAFT AP-
Table of Contents
This document has 113 pages.
Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1 Introduction to Nokia Siemens Networks LTE/EPC system. . . . . . . . . . 11
2 Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 LTE architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 LTE overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 eNB functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 LTE multiple access radio interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 OFDM concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 OFDMA principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 SC-FDMA principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 LTE Radio protocol architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Multi-Antenna techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1 Receive diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.2 Transmit diversity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.3 MIMO techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.3.1 Downlink MIMO techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.3.2 Uplink MIMO techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.3.3 Multi-user MIMO techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.4 Beamforming (further study item) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.5 Active antenna system (further study item) . . . . . . . . . . . . . . . . . . . . . . 31
2.5 Radio network optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Interference mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 RAN sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8 Flexi Multiradio BTS LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9 Spectrum and bandwidth deployment for LTE. . . . . . . . . . . . . . . . . . . . 38
2.10 External interfaces of the Flexi Multiradio BTS LTE . . . . . . . . . . . . . . . 39
3 Network and service management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1 Network management architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Managing the LTE/EPC system with NetAct TM . . . . . . . . . . . . . . . . . . . 41
3.3 Element management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Mobility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Mobility scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Mobility anchors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Inter-eNB handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Inter-RAT handover (3GPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Radio resource management and telecom . . . . . . . . . . . . . . . . . . . . . . 47

5.1 RRM functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 RRM procedures and measurements . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Transport and transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1 LTE transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Control plane transport (RAN signaling) . . . . . . . . . . . . . . . . . . . . . . . . 52
Id:0900d805806eda7f 3
6.2.1 RRC Signaling Protocol (eNB <> UE). . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2.2 S1AP Signaling Protocol (eNB <> MME) . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 X2AP Signaling Protocol (eNB <> eNB) . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.4 NAS Signaling Protocol (MME <> UE) . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3 User plane transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3.1 LTE-Uu user plane transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2 S1-U user plane transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.3 X2 user plane transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4 Transport interface options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.5 Traffic engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.5.1 Traffic prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.5.2 Traffic separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5.3 Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.5.4 Multi-layer optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.6 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.1 Synchronization from PDH interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.2 Synchronization from 2.048 MHz signal . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.3 Synchronization from GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.6.4 Timing over Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.6.5 Synchronous Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7 Operability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1 NetAct ™ framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2 BTS Site Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3 Flexi Multiradio BTS LTE management functions. . . . . . . . . . . . . . . . . . 71
7.3.1 Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.2 Configuration management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.3.3 Software management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.4 Performance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3.5 Hardware/inventory management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3.6 Feature/license management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.3.7 User account management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3.8 User event log management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 Flexi Multiradio BTS supplementary OAM features . . . . . . . . . . . . . . . . 87
7.4.1 GPS location retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4.2 NTP clock time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4.3 DHCP server for BTS site equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.5 Flexi Multiradio BTS diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.5.1 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.6 Self organizing network support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6.1 Auto connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6.2 Auto configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.6.3 LTE neighbor cell configuration with preplanned identities. . . . . . . . . . . 97
7.6.4 Automated adjacent cell configuration for LTE . . . . . . . . . . . . . . . . . . . . 99
8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.1 Impact of LTE architecture on security . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.2 Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4 Id:0900d805806eda7f
8.3 Access security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

8.3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.3.2 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.3.3 User event logging and log collection . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.4 BTS security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.5 System security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.5.1 Firewall support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.5.2 IPsec support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.5.3 Transport layer security support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.5.4 IP based filtering for BTS site support equipment . . . . . . . . . . . . . . . . 108
8.5.5 Secure network element identity and authentication . . . . . . . . . . . . . . 108
8.5.6 Identity management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.5.7 Public key infrastructure support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.5.8 Certificate management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Id:0900d805806eda7f 5
List of Figures
Figure 1 LTE/SAE high-level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 2 LTE air interface technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 3 Architectural evolution of existing 2G/3G networks to LTE. . . . . . . . . . . 15
Figure 4 Smooth migration towards EPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 5 Functional split between radio access and core network . . . . . . . . . . . . 17
Figure 6 E-UTRAN and EPC with S1-flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 7 OFDMA and SC-FDMA modulation schemes. . . . . . . . . . . . . . . . . . . . . 20
Figure 8 OFDMA and SC-FDMA signal generation and reception (simplified model)
20
Figure 9 Orthogonal frequency division multiplex principle. . . . . . . . . . . . . . . . . . 22
Figure 10 OFDM and OFDMA subcarrier allocation . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 11 DFT pre-coding and principle of SC-FDMA . . . . . . . . . . . . . . . . . . . . . . 23
Figure 12 Uu interface protocol architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 13 Mapping of physical, transport and logical channels . . . . . . . . . . . . . . . 26
Figure 14 2x2 MIMO configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 15 Operator modules in RAN sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 16 RAN sharing architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 17 Flexi Multiradio BTS site solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 18 Flexi Multiradio BTS site solution for the 2TX MIMO in a 3-sector configu-
ration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 19 Flexi Multiradio RRH 60 W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 20 External interfaces of the Flexi Multiradio BTS LTE . . . . . . . . . . . . . . . . 39
Figure 21 LTE/EPC network management architecture . . . . . . . . . . . . . . . . . . . . . 40
Figure 22 Mobility scenarios for LTE/EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 23 Mobility anchor point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 24 Inter-eNB handover with X2 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 25 3GPP inter-RAT handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 26 Flexi Multiradio BTS interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 27 LTE RAN signaling connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 28 Control plane protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 29 C-plane operation of PDCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 30 User plane protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 31 U-plane operation of PDCP and RLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 32 Ethernet backhaul for LTE/EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 33 QoS differentiation between user, control and management plane traffic .
60
Figure 34 Traffic prioritization on the Ethernet layer, using packet marking methods
61
Figure 35 M-plane separation using VLAN over Ethernet. . . . . . . . . . . . . . . . . . . . 62
Figure 36 Multi-layer network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 37 Synchronization from PDH interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 38 Synchronization from 2.048 MHz signal . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 39 ToP based synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 40 Functional overview of the BTS Site Manager . . . . . . . . . . . . . . . . . . . . 69
Figure 41 Performance management architecture . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 42 Auto connection flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6 Id:0900d805806eda7f
Figure 43 Auto configuration flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Figure 44 Network integration flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 45 LTE/EPC security architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 46 Nokia Siemens Network device certificate delivery . . . . . . . . . . . . . . . 110
Figure 47 Nokia Siemens Networks Identity Mangement System . . . . . . . . . . . . 111
Id:0900d805806eda7f 7
List of Tables
Table 1 Summary of customer benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 2 Benefits of OFDMA and SC-FDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 3 Multi-antenna options in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 4 Frequency bands supported in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 5 Mobility scenarios and anchor points . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 6 Scope of RRM functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 7 BTS Site Manager local and remote functionality . . . . . . . . . . . . . . . . . 71
Table 8 IPsec capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8 Id:0900d805806eda7f
LTE RAN system description Summary of changes
Summary of changes
Issue History
Issue Date of Issue Reason for Update

Number
1st draft 2009-04-08 First draft for review.
01 2010-02-25 Second draft
Details
Id:0900d805806f2b87 9
Summary of changes LTE RAN system description
10 Id:0900d805806f2b87
LTE RAN system description Introduction to Nokia Siemens Networks LTE/EPC sys-
tem
1 Introduction to Nokia Siemens Networks

LTE/EPC system
g This document provides an overview of the LTE/EPC system. Functions and
features are described without respect to the system releases when they will actually
be available. This information can be found in the Nokia Siemens Networks LTE
roadmap.
Nokia Siemens Networks expects five billion people to be connected to the Internet by
2015. Wireless access plays a major role in realizing this target. Wireless networks will
be used to extend broadband penetration beyond the reach of wireline networks. Evo-
lution of terminals and networking technology coupled with Internet access as a global
phenomenon are allowing advanced operators to report polynomial growth in mobile
data usage already now.
With a view to taking the next step up the evolutionary ladder beyond HSPA, 3GPP
Release 8 has standardized a technology called Long Term Evolution/System Architec-
ture Evolution (LTE/SAE). It is designed to
• make the most of scarce spectrum resources:
Deployable with bandwidths ranging from 1.4 MHz to 20 MHz, LTE/SAE provides up
to four times the spectral efficiency of HSDPA Release 6.
• afford users an experience on par with today’s best residential broadband access:
LTE/SAE delivers peak user data rates ranging up to 173 Mbps and reduces latency
to as low as 10 ms.
• leverage flat all-IP network architecture and a new air interface to significantly cut
per-Mbyte costs, with later product innovations potentially improving performance
even further:
For instance a 4x4 Multiple Input/Multiple Output (MIMO) scheme will boost
downlink rates up to 326 Mbps.
System approach
Based on these performance targets 3GPP is defining the air interface, network archi-
tecture, and system interfaces. All services are packet-based; that is, VoIP serves to
implement voice. Figure 1 shows an LTE/SAE network’s high-level architecture.
LTE/SAE does not entail a circuit-switched domain. 3GPP envisages fully IP-based
transmission. The IP backbone network supports guaranteed QoS on demand with a
very simplified, but backward compatible QoS concept. Carrier-grade Ethernet is used
where possible; in particular to connect the evolved node B (eNB), the LTE’s base
station.
Id:0900d805806ec794 11
Introduction to Nokia Siemens Networks LTE/EPC sys- LTE RAN system description
tem
Service Control and Data Bases
IMS PCRF HSS/AAA
Access Core Switching & Transport
MME
Internet
eNB S-GW P-GW
Figure 1 LTE/SAE high-level architecture

In the following, the Nokia Siemens Networks solution of the LTE/SAE architecture is
referred to as Nokia Siemens Networks LTE/EPC (Long Term Evolution/Evolved Packet
Core) system.
Simplified network architecture

Today’s WCDMA core network architecture for the PS domain comprises SGSN and
GGSN. The radio network architecture comprises Node B and RNC.
The Nokia Siemens Network LTE/EPC system is streamlined to optimize network per-
formance, maximize data throughput, and minimize latency. Rather than four nodes
(Node B, RNC, SGSN, GGSN), the LTE/EPC system comprises a far simpler configu-
ration of just eNB, two logical user plane entities, Serving Gateway and PDN Gateway,
collectively called the S-GW/P-GW, and one control plane entity (MME). Gateway func-
tions may be provided in common or separate physical nodes. All entities are connected
by standardized interfaces to support multi-vendor configurations. Transport is fully IP-
based. Because the access network operates without a central controller (BSC, RNC),
base stations (eNBs) interconnect and connect directly to the S-GW/P-GW and MME to
exchange control and user information. This approach entails fewer interfaces and
minimal complexity caused by protocol conversion and content mapping.
High-performance air interface

The LTE air interface differs markedly from legacy technology. Advanced applied
Orthogonal Frequency Division Multiplexing (OFDM) technologies achieve performance
and savings goals based on low total cost of ownership.
Figure 2 summarizes the technological approach to the projected air interface. Many
orthogonal OFDM sub-carriers may be allocated according to carrier bandwidth avail-
able in the downlink. The uplink employs a single carrier FDMA technology (SC-FDMA)
to preclude high peak-to-average power ratios, thereby streamlining the RF design and
extending the battery life of the terminals.
12 Id:0900d805806ec794
tem
scalable Hybrid ARQ 64 QAM Fast Link Adaptation

Modulation
1 2
NACK ACK
DL: OFDMA UL: SC-FDMA 1

Combined Available bandwidth
decoding
Sub-carriers
2
Short TTI =1 ms Rx Buffer
...
Transmission time interval
OFDM
symbols
Frequency
...
Guard
TX RX intervals
Advanced Scheduling Time

MIMO
Time & Frequency
TX Channel RX (Frequency Selective Scheduling)
Figure 2 LTE air interface technology

OFDM allows for improved interference control, advanced scheduling techniques and
ease of implementation of Multiple Input Multiple Output (MIMO) concepts. MIMO
antenna technology and higher order modulation (64QAM), combined with fast link
adaptation methods, maximize spectral efficiency. In principle, operators do not need to
acquire new spectrum. The LTE air interface is designed to operate in the same
spectrum as, and in parallel with, the legacy WCDMA/HSPA air interface, for example
on a separate carrier. The system’s flexible spectrum allocation (including scalable
bandwidth) allows carriers to be spread across any suitable spectrum licensed for 2G or
3G operation. Deployable in spectrum bands with bandwidths of 1.4, 3, 5, 10, 15, and
20 MHz, LTE offers unique spectrum flexibility. The small 1.4 and 3.0 MHz bandwidths
are optimized for GSM and CDMA re-farming, where operators might not initially be able
to free up more bandwidth.
Customer benefits
The introduction of LTE provides the following key benefits to operators compared with
existing 3G deployments:
• Maximized use of allocated frequency bands
LTE provides high aggregate data rates per cell and supports flexible frequency
bandwidths and in particular allows re-farming of 2G spectrum.
• Reduced cost of ownership
LTE has a simpler architecture: it has fewer nodes and fewer node types, and is
entirely IP based. It also uses IP transport allowing the use of cheap equipment and
infrastructure. The ability to run voice and data services on a unified infrastructure
will also have an impact on reducing costs.
• Competitive mobile broadband packet access
LTE is optimized for broadband IP packet access providing the high bandwidth (100
Mbps DL/50 Mbps UL) and low latency required. It supports seamless and lossless
low latency handover and provides sophisticated QoS to support important real-time
applications such as voice, video and real-time gaming. LTE can support terminal
speeds of 150-350 km/s and cell ranges of up to 100 km.
Id:0900d805806ec794 13
tem
• Superior inter-technology mobility

The LTE/EPC combination provides seamless mobility with other 3GPP access
systems (UMTS, GPRS), with 3GPP2/cdma2000 and, where possible, with non-
3GPP (for example WLAN).
Table 1 summarizes the main customer benefits.
Operator benefits Subscriber benefits

• reduced complexity, flat IP based packet-only • enriched user experience with real time, interactive
architecture lower operator CAPEX and OPEX services and seamless connectivity
• interworking with legacy systems as an integral • broadband mobility at a decreasing cost
part of service continuity • wide variety of devices and services
• scalable bandwidth allows flexible deployment with
limited spectrum
• significant improvements in spectral efficiency and
data performance for multimedia services
• economies of scale leveraging existing assets
meaning rapid availability for the mass market
Table 1 Summary of customer benefits
Network evolution and migration

Nokia Siemens Networks is committed to providing a smooth evolutionary path for every
operator, following a roadmap that factors each operator’s installed base and strategy
into the equation (see Figure 3):
• 3G operators with a deployed WCDMA/HSPA network can migrate directly to
LTE/EPC. Migrating to the flat network architecture of Internet High Speed Packet
Access (I-HSPA) may also be beneficial because it accommodates LTE/EPC’s flat
IP-based network architecture while supporting legacy WCDMA/HSPA handsets.
The operator can thus enjoy the transport and network scaling benefits immediately,
and easily upgrade the network to LTE/EPC later.
• 3G operators who have deployed I-HSPA have flat network architecture similar to
LTE/EPC in place, and can thus cost-efficiently introduce LTE/EPC.
• Operators running 2G networks (GSM/GPRS) can introduce LTE/EPC directly or
via one of the above WCDMA/HSPA paths, depending on their timetables for intro-
ducing mobile broadband services and the spectrum they have available. Because
LTE supports bands as small as 1.4 MHz, spectrum may be re-farmed smoothly and
gradually from GSM to LTE.
• CDMA operators can introduce LTE/EPC networks directly, or follow one of the
above paths. GSM/EDGE may be a good choice for strategies more immediately
focused on voice centric business. The same applies to Greenfield operators.
Operators opting to take the I-HSPA path can capitalize on the ecosystem of HSPA
terminals, benefit from the flat architecture today, and quickly optimize mobile broad-
band performance.
• Operators with TD-SCDMA networks, which are currently deployed in China only,
will probably migrate directly to LTE, preferably using the TDD mode of LTE.
14 Id:0900d805806ec794
tem
Leverage existing handset base Exploit core network synergies
GSM/WCDMA Enabling flat broadbandarchitecture

handset base
LTE
I-HSPA
WCDMA/
HSPA
GSM/
TD-SCDMA
(E)GPRS
CDMA
Figure 3 Architectural evolution of existing 2G/3G networks to LTE
Network deployment
For 3GPP operators, the Nokia Siemens Networks EPS solution enables optimized
steps from 2G/3G legacy infrastructure to reach the target EPS architecture as illus-
trated in Figure 4:
1. Introduction of direct tunnel between RNC and GGSN (HSPA R7):
2. Introduction of RNC functionality and direct tunnel between NB and GGSN (I-HSPA
R7)
3. Introduction of EPC (LTE R8)
4. Upgradeability of legacy SGSN with MME functionality
5. Upgradeability of legacy GGSN with P-GW functionality
Id:0900d805806ec794 15
tem
Direct tunnel Internet HSPA
HSPA R6 HSPA R7 HSPA R7 LTE R8
P-GW
GGSN GGSN GGSN S-GW
Direct Direct Direct

SGSN SGSN tunnel SGSN tunnel MME tunnel
RNC RNC
NB with
NB NB eNB
RNC funct.
Control plane User plane Capacity expansions
Figure 4 Smooth migration towards EPS
Nokia Siemens Networks LTE/EPC product portfolio

The LTE/EPC system comprising the logical entities eNB, S-GW, P-GW, and MME is
realized by the following Nokia Siemens Networks products:
• Flexi Multiradio BTS LTE
eNB functionality is supported as the evolution of the Nokia Siemens Networks Flexi
Multiradio BTS. Nokia Siemens Networks’ LTE eNB is based on the Flexi Multiradio
BTS. The same Flexi Multiradio System and RF Modules are used for
WCDMA/HSPA and for LTE. With downloadable LTE SW, the Flexi Multiradio BTS
operates in LTE SW mode, to become the Flexi Multiradio BTS LTE. From a BTS
site installation and hardware point of view, Flexi Multiradio BTS LTE enables oper-
ators to build BTS sites using modules, without the requirement for a specific BTS
cabinet.
• Flexi Network Server
MME functionality is supported as the evolution of the Nokia Siemens Networks
SGSN product.
• Flexi Network Gateway
S-GW/P-GW functionality is supported as the evolution of Nokia Siemens Networks
ISN product.
16 Id:0900d805806ec794
LTE RAN system description Network architecture
2 Network architecture
2.1 LTE architecture

The Nokia Siemens Networks Long Term Evolution (LTE) architecture is compliant with
3GPP specification [TS 36.300].
The LTE system performs the following key functions in the operator LTE RAN network
(see 2.1.2 eNB functionality):
• handling terminals compliant to 3GPP
• managing radio resources
2.1.1 LTE overview

The LTE network architecture is composed of only one network element which provides
the air interface to UEs. Evolved node Bs (eNBs) can be connected to each other via
the X2 interface and connected to MMEs and S-GWs via the S1 interface.
Functional split
The functional split between LTE RAN and Core fully implements radio functionality in
the eNB as illustrated in Figure 5. The new functionalities compared with HSPA are
Radio Link Control (RLC) Layer, Radio Resorce Control (RRC) and Packet Data Con-
vergence Protocol (PDCP) functionalities.
E."
)NTER#ELL22-
2"#ONTROL
#ONNECTION-OBILITY#ONT
2ADIO!DMISSION#ONTROL
3 '7 0 '7
E."-EASUREMENT
#ONFIGURATION0ROVISION 5%)0!DDRESSALLOCATION
3 5 33
$YNAMIC2ESOURCE -OBILITY!NCHORING
!LLOCATION3CHEDULER 0ACKET&ILTERING
22#
0$#0 --%
.!33ECURITY
2,# 3 --%
)DLE3TATE
-OBILITY(ANDLING
-!#
3!%"EARER#ONTROL
0(9
% 542!. %0#
Figure 5 Functional split between radio access and core network
Id:0900d805806fc7da 17
Network architecture LTE RAN system description
S1 flexibility
A single eNB can connect to multiple MMEs and multiple S-GWs. This ability provides
flexibility and reliability and is referred to as S1-flex. The eNB connection options are
illustrated in Figure 6.
LTE_Uu S1
eNB S1-U
S-GW S5/S8a
X2 S10
S11
eNB MME P-GW

S1-MME
S11
X2 S10
S1-U
eNB S-GW
S11
S1-MME MME
EUTRAN EPC
Figure 6 E-UTRAN and EPC with S1-flex
2.1.2 eNB functionality

The eNB includes the majority of the LTE system functionality. The functions are very
similar to the HSPA part of a traditional Radio Network Controller but scaled down to the
scope of one eNB. Thus the complexity and related cost of the system are minimized.
The eNB hosts the following functions:
Physical layer (L1/PHY)
• PHY procedures, for example power control
• Channel coding, modulation, resource element and antenna mapping, (I)FFT
Data link layer (L2)
• PDCP: IP header compression (RoHC)
• Ciphering
• RLC: RLC segmentation
• Automatic Repeat Request (ARQ)
• MAC: MAC multiplexing
• Hybrid Automatic Repeat Request (HARQ)
• Packet Scheduling
Network layer (L3)
• Radio Resource Control
– Radio Bearer Control
18 Id:0900d805806fc7da
– Radio Admission Control

– Idle and Connected Mode Mobility Controll
– Packet Scheduling
– Inter-cell Interference Coordination
– Load Balancing
– Inter-RAT RRM
• Scheduling and transmission of
– Paging messages
– Broadcast information
Network related functions
• Routing of U-plane to S-GW
• Uplink QoS support at transport and bearer level
2.2 LTE multiple access radio interface

The LTE radio interface, as specified in [TS 36.101] for the UE and [TS 36.104] for the
eNB, supports both FDD and TDD modes, each with its own frame structures. The LTE
multiple access is based on OFDMA in the downlink direction (see 2.2.2 OFDMA prin-
ciples) and SC-FDMA in the uplink direction (see 2.2.3 SC-FDMA principles).
Different technologies for uplink and downlink

The main benefits of each technology are summarized in Table 2.
Downlink: OFDMA Uplink: SC-FDMA

• improved spectral efficiency • power efficient uplink which increases
• reduced interference battery lifetime
• very well suited for MIMO • improved cell edge performance by
low peak to average ratio
• reduced terminal complexity
Table 2 Benefits of OFDMA and SC-FDMA
Modulation schemes for uplink and downlink

The different modulation schemes of OFDMA and SC-FDMA are illustrated in Figure 7.
For clarity this example uses only four (M) subcarriers over two symbol periods with the
payload data represented by quadrature phase shift keying (QPSK) modulation.
However, real LTE signals are allocated in units of 12 adjacent subcarriers.
The most obvious difference between the two schemes is that OFDMA transmits the
four QPSK data symbols in parallel, one per subcarrier, while SC-FDMA transmits the
four QPSK data symbols series at four times the rate, with each data symbol occupying
M x 15 kHz bandwidth.
Visually, the OFDMA signal is clearly multi-carrier with one data symbol per subcarrier,
whereas the the SC-FDMA signal appears to be more like a single-carrier with each data
symbol being represented by one wide signal.
Id:0900d805806fc7da 19
Q
-1,1 1,1 1, 1 -1,-1 -1, 1 1, -1 -1,-1 1, 1 1, -1 -1, 1
I
Sequence of QPSK data symbols to be transmitted
-1,-1 1,-1
er
QPSK modulating ow
e r p MA
data symbols rri FD
ca C- d
s ub h S rio
t c e
an ea l p
n st ng bo
i m
Co dur sy
V V
bo A
bo A
m M
m DM
l
sy FD
l
sy -F
O
SC
CP CP
bo A
e
e
bo A
m DM
m
m M
l
Ti
Ti
sy FD
l
sy -F
O
SC
Frequency 60 kHz Frequency
fc 15 kHz fc
OFDMA SC-FDMA
Data symbols occupy 15 kHz for Data symbols occupy M*15 kHz for
one OFDMA symbol period 1/M SC-FDMA symbol periods
Figure 7 OFDMA and SC-FDMA modulation schemes
Signal generation and reception

OFDMA and SC-FDMA partly share the same signal generation and reception steps.
Different to OFDMA, SC-FDMA begins with a special pre-coding process from the time
domain to the frequency domain but then continues in a manner similar to OFDMA, as
illustrated in Figure 8. After that, an IDFT is performed to convert the frequency-shifted
signal to the time domain and CP (Cyclic Prefix) is inserted to provide a fundamental
robustness of OFDMA against multipath.
Unique to SC-FDMA Common with OFDMA
Map data to Generate Perform Map Perform

Upconvert
constellation time domain M-point DFT symbols to N-point IFFT
and transmit
M data waveform (time to freq) subcarriers N>M
bits in
Time domain Frequency domain Time domain
De-map Perform De-map Perform

Generate Receive and
constellation M-point IDFT subcarriers N-point DFT
constellation downconvert
M data to data (freq to time) to symbols N>M
bits out
Figure 8 OFDMA and SC-FDMA signal generation and reception (simplified model)
20 Id:0900d805806fc7da
Key ingredients of the LTE radio interface

In addition to the OFDMA and SC-FDMA concepts there are the following key ingredi-
ents of the LTE radio interface:
• The highest available modulation scheme of 64 QAM (mandatory in the Downlink
and optional in Uplink) provides a significant advantage over HSPA Rel-6.
• The turbo convolutional coder improves coding gain by 1 to 2 dB compared to a con-
ventional convolutional coder.
• LTE Rel-8 supports multi antenna schemes for MIMO and TX diversity. For details
see 2.4 Multi-Antenna techniques.
• Inter-cell interference coordination as well as interference cancellation enable
exploiting multi antenna configurations. For details see 2.6 Interference mitigation.
• The frequency-selective Packet Scheduler (PS) is channel-aware and dynamically
allocates to the UE a certain number of PRBs in accordance to QoS criteria.
• The Hybrid Automatic Repeat Request (HARQ) scheme can move the operating
point for link adaptation to a Block Error Rate (BLER) of 10 up to 20%.
2.2.1 OFDM concept

Rather than transmit a high-rate stream of data with a single carrier, OFDM makes use
of a large number of closely spaced orthogonal subcarriers that are transmitted in par-
allel. Each subcarrier is modulated with a conventional modulation scheme (such as
QPSK, 16QAM, or 64QAM) at a low symbol rate. The combination of hundreds or thou-
sands of subcarriers enables data rates similar to conventional single-carrier modulation
schemes in the same bandwidth.
Orthogonality in the frequency domain:
• ideally eliminates intra-cell interference
• allows for a very high spectral efficiency
• allows for rather small guard bands within the nominal bandwidth
These characteristics enable much more flexible spectrum usage than in CDMA-based
systems like UTRA. LTE (for FDD) supports carrier bandwidths of 1.4 MHz, 3 MHz, 5
MHz, 10 MHz, 15 MHz, and 20 MHz.
Orthogonality is also the reason why Multiple-Input Multiple-Output (MIMO) techniques
are better supported in Orthogonal Frequency Division Multiplex (OFDM) systems than
in CDMA-based systems. On the time axis, an OFDM transmitter sends a sequence of
OFDM symbols separated by guard time intervals. A key principle is the Cyclic Prefix
(CP) which is transmitted during such a guard time interval and which consists of a copy
of the succeeding OFDM symbol's tail.
Thanks to the intermitted CPs, the receiver can:
• eliminate inter-symbol interference caused by multi-path propagation (thereby
establishing orthogonality in the time domain)
• benefit from simplified equalization and simplified channel estimation in the fre-
quency domain
OFDM receiver and transmitter are based on the Discrete or Fast Fourier Transform
(FFT) algorithm. In the frequency domain, multiple adjacent tones or subcarriers are
each independently modulated with data. Then in the time domain, guard intervals are
inserted between each of the symbols to prevent inter-symbol interference at the
receiver caused by multi-path delay spread in the radio channel.
Id:0900d805806fc7da 21
Available bandwidth
Sub-carriers
...
OFDM
symbols
Frequency
...
Guard
intervals
Time
Figure 9 Orthogonal frequency division multiplex principle

Disadvantages of the OFDM concept are:
• The subcarriers are closely spaced, making OFDM sensitive to frequency errors and
phase noise. For the same reason, OFDM is also sensitive to Doppler shift, which
causes interference between the subcarriers.
• Pure OFDM also creates high Peak-to-Average Power Ratio (PAPR), and that is
why a modification of the technology called SC-FDMA is used in the uplink.
2.2.2 OFDMA principles

The E-UTRA system uses Orthogonal Frequency Division Multiple Access (OFDMA) for
the Downlink which divides the available bandwidth into many narrow, mutually orthog-
onal sub-carriers. OFDMA is a variant of orthogonal frequency division multiplexing
(OFDM), a digital multi-carrier modulation scheme that is widely used in wireless
systems but relatively new to cellular.
With standard OFDM, very narrow UE-specific transmissions can suffer from narrow-
band fading and interference. In contrast to an OFDM transmission scheme, OFDMA
allows the access of multiple users on the available bandwidth. That is why for the
downlink OFDMA is used for LTE, which incorporates elements of time division multiple
access (TDMA). Each user is assigned a specific time-frequency resource. OFDMA
allows subsets of the subcarriers to be allocated dynamically among the different users
on the channel, as shown in Figure 10. As a fundamental principle of E-UTRA, the data
channels are shared channels, that is, for each transmission time interval, a new sched-
uling decision is taken regarding which users are assigned to which time/frequency
resources during this transmission time interval. The result is a more robust system with
increased capacity. This is due to the trunking efficiency of multiplexing low rate users
and the ability to schedule users by frequency, which provides resistance to multi-path
fading.
22 Id:0900d805806fc7da
Subcarriers Subcarriers
Symbols (Time)
Symbols (Time)
User 1
User 2
User 3
OFDM OFDMA
Figure 10 OFDM and OFDMA subcarrier allocation
2.2.3 SC-FDMA principles

The E-UTRA system uses Single Carrier Frequency Division Multiple Access (SC-
FDMA) for the Uplink which combines the low PAR techniques of single-carrier trans-
mission systems, such as GSM and CDMA, with the multi-path resistance and flexible
frequency allocation of OFDMA. The single carrier signal has a Peak-to-Average Power
Ratio (PAPR) that is about 4 dB lower than a corresponding OFDM signal and this
extends the UE battery life time. Thanks to transform precoding each UE creates a
single carrier signal.
As illustrated in Figure 11, data symbols in the time domain are converted to the fre-
quency domain using a discrete Fourier transform (DFT). In the frequency domain they
are mapped to the desired location in the overall channel bandwidth before being con-
verted back to the time domain using an inverse FFT (IFFT). Finally, the CP is inserted.
UE data after Q-point

modulation CP RF
DFT NFTT-point Add Gen
mapping Add
Q IFFT
0s
(NFTT ≥ Q)
Q-point DFT
(Transform Pre-coding)
Results in Single-Carrier FDMA:
System BW
Figure 11 DFT pre-coding and principle of SC-FDMA
Id:0900d805806fc7da 23
2.3 LTE Radio protocol architecture

The LTE-Uu interface consists of three layers:
• Physical layer (L1/PHY)
• Data link layer (L2) contains sublayers:
– Medium access control (L2/MAC)
– Radio link control (L2/RLC)
In addition, the data link layer contains a protocol belonging to the user plane only
– Packet data convergence protocol (L2/PDCP)
• Network layer (L3) contains a protocol belonging to the control plane:
– Radio resource control (L3/RRC)
Figure 12 shows the Uu interface protocol architecture. Service Access Points (SAP) for
peer-to-peer communication are marked with ellipses.
C-plane signaling U-plane information

GC Nt DC
Duplication avoidance
GC Nt DC
UuS boundary
control L3
RRC
PDCP
PDCPPDCP L2/PDCP
control
control
control
control
L2/BMC
RLC
RLC
RLC
RLC RLC L2/RLC
RLC
RLC RLC
RLC
RLC RLC
Logical Channels
MAC L2/MAC
Transport Channels
PHY L1
Figure 12 Uu interface protocol architecture
Layer 1
Layer 1 offers information transfer services to the MAC and higher layers through trans-
port channels. The physical layer is controlled by a data link layer that has two sublay-
ers: MAC and RLC. MAC realizes transport channel management and RLC realizes flow
control. RRC manages the physical layer and its activities.
Layer 2
Layer 2 comprises the following sublayers:
• Medium Access Control (MAC) for:
24 Id:0900d805806fc7da
– MAC concatenation, i.e., RLC Packet Data Units (PDUs) are mapped from/to
RCL layer or logical channels from/to Transport Blocks (TBs) or transport
channels
– Error correction through Hybrid Automatic Repeat Request (H-ARQ)
– Packet scheduling including QoS priority handling referred to one UE and/or
referred to one Radio Bearer
• Radio Link Control (RLC) for:
– RLC segmentation
– Mapping from/to Radio Bearers to/from logical channels (incl. PDCP layer)
– Error correction through Automatic Repeat Request (ARQ)
• Packet Data Convergence Control (PDCP) for:
– IP header compression (RoHC)
– Ciphering
– Integrity protection
The Layer 2 protocols terminate in the eNB.
Layer 3
Layer 3 consists of the Control Plane's Radio Resource Control (RRC) protocol. In
contrast to WCDMA, the RRC layer terminates in the eNB thereby enabling the
LTE/EPC direct tunnel architecture.
Terminating the RRC in the eNB also means that there is no macro-diversity supported
as otherwise a Radio Network Controller (RNC) node would be needed. The Non-
Access Stratum protocol terminates in the Mobility Management Entity (MME).
The functions at the RRC layer consist of:
• Radio Resource Management (RRM) including:
– Radio Bearer Control
– Radio Admission Control
– Idle and Connected Mode Mobility Control
– Inter-Cell Interference Coordination
– Load Balancing
– Inter-RAT Radio Resource Management
• Scheduling and transmission of
– Paging messages
– Broadcast information
• UE measurement configuration
• Routing of U-plane to Serving Gateway
• Uplink QoS support at transport and bearer level
Downlink Physical channels

• Physical broadcast channel (PBCH)
The coded BCH transport block is mapped to four subframes within a 40 ms time
interval.
• Physical control format indicator channel (PCFICH)
Informs the UE about the number of OFDM symbols used for the PDCCHs and must
be transmitted in every subframe.
Id:0900d805806fc7da 25
• Physical downlink control channel (PDCCH)

Informs the UE about the resource allocation and Hybrid-ARQ information. It also
contains the Uplink scheduling grant.
• Physical downlink shared channel (PDSCH)
Carries the Downlink shared channel (DL-SCH) and the Paging Channel (PCH).
• Physical hybrid ARQ indicator channel (PHICH)
Carries Hybrid ARQ ACK/NAKs in response to Uplink transmission.
• Synchronization channels (Primary SCH and Secondary SCH)
Uplink Physical channels

• Physical uplink control channel (PUCCH)
Carries ACK/NACKs in response to Downlink transmission as well as CQI reports,
and scheduling requests.
• Physical uplink shared channel (PUSCH)
Carries the UL-SCH.
• Physical random access channel (PRACH)
Carries the random access preamble.
The mapping of physical, transport and logical channels is illustrated in Figure 13.
DL Logical Channel BCCH CCCH DTCH DCCH PCCH
DL Transport Channel BCH DL-SCH PCH
DL Physical Channel PACH PDSCH PDCCH PCFICH PHICH
UL Logical Channel DTCH DCCH CCCH
RACH UL-SCH
UL Transport Channel
UL Physical Channel PRACH PUSCH PUCCH
Figure 13 Mapping of physical, transport and logical channels

For more information see LTE/EPC interfaces.
26 Id:0900d805806fc7da
2.4 Multi-Antenna techniques

A key ingredient of the LTE air interface is the Multiple-Input Multiple-Output (MIMO)
support in order to achieve the ambitious requirements for throughput and spectral effi-
ciency. MIMO refers to the use of multiple antennas at transmitter and receiver side. For
the LTE downlink, a 2x2 configuration for MIMO is assumed as baseline configuration,
that is, 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. Table 3 gives an overview on the typical LTE multi antenna configurations.
DL UL Configuration
type
BS UE Gain UE BS Gain
TX RX to smaller configuration TX RX to smaller configuration
1x2 1 2 1x2 1 2 minimum

2x2 2 2 + 4 .. 5 dB DL link budget 1x2 1 2 standard
+ 100% peak data rate
+ user experience
+ 20% spectrum efficiency
4x2 4 2 + 3 .. 4 dB DL link budget 1x4 1 4 + 3 .. 4 dB UL link budget high-performance
+ moderate capacity gains + user experience
+ multi-user MIMO gain
4x4 4 4 + 100% peak data rate 1x4 1 4 future
+ user experience
Table 3 Multi-antenna options in LTE
The “standard” configuration at the LTE base station is strongly recommended. In

addition to 2 RX antennas (RX diversity) it also provides 2 TX chains at the LTE base
stations, which is highly beneficial without extra antenna and feeder effort and cost
compared to the minimum configuration with 1 TX. In a “high performance” scenario 4
RX antennas at the LTE base station substantially enhance the LTE Uplink but require
additional antenna and feeder effort and cost. This configuration is justified in a re-
farming scenario in order to avoid combing losses. Typically, the LTE UE has 2 RX
antennas and 1 TX chain.
2.4.1 Receive diversity

Nokia Siemens Networks supports 2-branch, and plans to support 4-branch receive
diversity based on Maximum Ratio Combining (MRC). MRC means to combine the 2 (or
4) receive signals such that the wanted signal's power is maximized compared to the
interference and the noise power - the Signal-to-Interference-and-Noise-Ratio (SINR) is
enhanced. MRC outperforms receive antenna selection.
Id:0900d805806fc7da 27
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 terminal 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)
In analogy, 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 2 receive branches requires 2 uncorrelated receive antennas
using a single cross-polar antenna or 2 vertically polarized spatially separated antennas;
4-branch receive diversity requires 4 uncorrelated receive antennas using for example
2 spatially separated cross-polar antennas.
Receive diversity is compliant with LTE Rel-8 terminals and supported on all Uplink
channels.
2.4.2 Transmit diversity

Nokia Siemens Networks supports 2-branch, and plans to support 4-branch transmit
diversity.
Depending on channel conditions there are two schemes to be distinguished for transmit
diversity:
• MIMO Transmit Diversity
Transmit diversity is based on Space Frequency Block Coding.
• Zero-delay CDD MIMO Spatial Multiplexing
Transmit diversity is based on transmitting a single codeword over multiple transmit
antennas.
Allowing for an increase of total eNB transmit power by keeping the transmit power per
transmit branch as high as for the single transmit antenna case improves the link budget
by 3 dB for 2 branches and by 6 dB for 4 branches. This allows both for coverage and
capacity enhancements.
Only if the total eNB transmit power is kept equal (compared to the single transmit
branch case) transmit diversity leads to more robust links at the cell edge while reducing
cell capacity slightly. In case of DRX VoIP users, however, transmit diversity slightly
enhances cell capacity by approximately 5% for 2 transmit branches.
Transmit diversity with up to 4 branches is supported for all Downlink channels. Transmit
diversity may be semi-statically configured per cell, while for UE Category 1 transmit
diversity for PDSCH is automatically selected.
2.4.3 MIMO techniques

The typical MIMO configuration encompassing Dual-Codeword 2x2 DL Single-User
(SU) MIMO Spatial Multiplexing is illustrated in Figure 14. This MIMO scheme targets at
a duplication of the Downlink peak user data rate by allowing for 2 independent parallel
data streams to a single UE. This is also called Spatial Multiplexing. The 2 base station
transmit signals, 2 UE receive signals, and 4 channels form (for each and every subcar-
rier) a system of 2 equations with 2 unknown transmit signals. The 2 unknown transmit
signals can be calculated from the estimated 4 channels, the possible transmit alpha-
bet(s), and the 2 receive signals.
28 Id:0900d805806fc7da
TX antennas Channel(s) RX antennas

H1,2
H2,2
X1 Y1
Data Data
TX RX
H1,2
X2 H2,2 Y2
A
k:
k k k k k
Y = H1,1 X 1 + H 1,2 X 2
1
k k k k k
Y 2 = H2,1 X 1 + H 2,2 X 2
Figure 14 2x2 MIMO configuration

Whether or not 2 independent data streams can be transmitted efficiently at the same
time depends on the channels as well as on how well the channels of the 2 data streams
decorrelate. Decorrelation of the channels strongly depends on the antenna character-
istics.
Antennas are uncorrelated if they:
• are spatially separated by about 10 or more wavelengths, or
• use orthogonal polarization planes (cross-polarity), or
• see a diffuse environment.
Uncorrelated antennas provide potential for diversity and spatial multiplexing gain, and
only partly for coherence gain.
Antenna elements are correlated if they:
• are phased by ½ wavelength spacing,
• have a low angular spread, and
• see a non-diffuse environment (for example, on the roof-top).
Correlated antennas provide robust coherence gain easily (the classical beamforming
gain) but no spatial multiplexing and/or diversity gain.
In case of Open Loop SU-MIMO Spatial Multiplexing there is no UE feedback
required. Mapping of data to the transmit antenna ports is fixed and the system cannot
be influenced. If the conditions for Spatial Multiplexing are too bad, however, the UE
may request to lower the transmission rank and ultimately fallback to Transmit Diversity.
In case of Closed Loop SU-MIMO Spatial Multiplexing there is UE feedback required.
Mapping of data to the transmit antenna ports follows the Codebook entry recom-
mended by the UE. The loop between base station and UE is closed, and the system
can be influenced to better enable Spatial Multiplexing. Again, if the conditions for
Spatial Multiplexing are too bad the UE may request the fallback to Transmit Diversity.
MIMO techniques comprise the following:
• Downlink MIMO techniques
• Uplink MIMO techniques
• Multi-user MIMO techniques
Id:0900d805806fc7da 29
2.4.3.1 Downlink MIMO techniques

For interoperability reasons, the Open Loop SU-MIMO scheme must be based on the
Large-delay Cyclic Delay Diversity (Large-delay CDD) precoding. Operators may (stat-
ically) configure whether a cell supports Transmit Diversity, or MIMO Spatial Multiplex-
ing, or allows for an adaptive mode. In the adaptive mode, Open Loop 2x2 SU-MIMO
fallback is Space Frequency Block Coding (SFBC) transmit diversity.
Codebook-based (Closed Loop) SU-MIMO uses no-CDD precoding. Operators may
(statically) configure whether a cell supports Transmit Diversity, MIMO Spatial Multiplex-
ing, or allows for an adaptive mode. In the adaptive mode, Closed Loop 2x2 SU-MIMO
fallback is 2x2 MIMO Spatial Multiplexing with a single codeword.
Under optimal conditions 2x2 SU-MIMO doubles the peak user data rate. Under realistic
conditions 2x2 SU-MIMO results in a cell capacity enhancement of 10% for macro-
cellular to 40% for micro-cellular deployment scenarios. Closed Loop SU-MIMO is well-
suited for UE velocities below 30 km/h while Open Loop SU-MIMO is naturally preferred
for higher UE velocities. Hence, an adaptation algorithm between Open Loop and
Closed Loop MIMO could be based on UE velocity.
The current Flexi Multiradio BTS Hardware meets the phase noise or minimum jitter
requirements (< 60 ns) between LTE baseband processing and antenna connectors
required for MIMO schemes with uncorrelated antennas. Whether or not a site can be
upgraded from 2 to 4 antennas per cell with little to no visible impact depends on the
characteristics of the site and whether deployed dual-band cross-polar antennas can be
reused or easily substituted with an antenna of similar geometry.
2.4.3.2 Uplink MIMO techniques

Uplink SU-MIMO has not been standardized for LTE Rel-8. Nokia Siemens Networks
will drive the standardization of Uplink SU-MIMO for LTE Rel-9 / LTE-A as Uplink SU-
MIMO will increase the coverage area of higher Uplink data rates. The eNB will have
implemented the MIMO receiver already for Uplink MU-MIMO while potential Uplink SU-
MIMO control signaling requirements are related to higher UE Categories not affecting
legacy Rel-8 terminals.
2.4.3.3 Multi-user MIMO techniques

Uplink Multi-User MIMO means that 2 different UEs exploit the same physical Uplink air
interface resources. Uplink MU-MIMO is supported in the 3GPP standard LTE Rel-8.
Uplink MU-MIMO is a capacity enhancement feature effective for loaded networks.
Nokia Siemens Networks will implement Uplink MU-MIMO in a future release in align-
ment with the 4 receive antenna configurations supported at the eNB. Uplink MU-MIMO
may either use 2 base station receive and for 4 base station receive antennas depend-
ing on the actual antenna deployment.
For evaluation purposes, a Proportional Fair scheduler and a frequency-selective MIMO
scheduler have been compared, indicating various performance gains achieavable with
2 or 4 receive antennas. Results are better for higher system loads, as an advanced
eNB receiver can best exploit Uplink MU-MIMO if there are sufficient appropriate
pairings of UEs. An initial implementation of the Uplink MU-MIMO scheduler starts from
semi-static pairing of UEs to allow for smooth integration with Hybrid Automatic Repeat
Request (HARQ) processing.
30 Id:0900d805806fc7da
Downlink Multi-User MIMO has not been standardized in LTE Rel-8, as gains for uncor-
related antennas have been rather small. Cell capacity gains in the order of 10% are
expected from Downlink MU-MIMO in the correlated antenna case.
2.4.4 Beamforming (further study item)
2.4.5 Active antenna system (further study item)
2.5 Radio network optimization

Nokia Siemens Networks has large experience in developing GSM/EGPRS, 3G/HSPA,
I-HSPA, and WiMax and providing all necessary parameters for optimization, and
similar kind of documentation will be available for LTE system as well.
Many of the RF parameters for optimization are similar to other technologies (i.e.
Antenna Tilting/Azimuth, Tx Power, Frequency Reuse), plus specific parameters related
to advanced features like PF Scheduler, Interference Coordination. Nokia Siemens Net-
works' planning guidelines and available parameters will be similar to the WiMAX
system, as its OFDMA and tight RF reuse will be very similar to LTE's planning. LTE
planning guidelines cover specific aspect of traditional RF planning and optimization
which may differ in OFDM system as compared with CDMA or WCDMA.
The main aspects affecting coverage and capacity optimization are:
• Optimization using azimuth adjustments
• Antenna tilting
• SINR optimization by down tilting
• Flexi BTS configuration parameters
Optimization using azimuth adjustments

Since the SINR is tolerant against azimuth deviation from the ideal direction, it is useful
as a tool for RF optimization provided that there is a reasonable overlap between sectors
of the same site. The overlap is achieved by using a relatively wide horizontal antenna
beam width. This technique needs to be used in conjunction with down tilting since the
irregular site locations would mean different effective cell radii for various sectors.
Antenna tilting
Antenna tilting is very effective in controlling co-channel interference by suppressing
signal spillage. The vertical antenna pattern is also used to compensate the near-far
effect because of propagation, which in turn can enhance the signal distribution in the
cell. There are two ways of antenna tilting:
• Electrical tilting can be controlled remotely and may be integrated into the Opera-
tions Support System (OSS) . The choice of antenna becomes very important since
electrical and mechanical down tilting have different effects to the effective shape of
the horizontal and vertical patterns.
• Mechanical tilting is relatively cheap to implement since the antenna always allows
the mounting to be adjusted vertically. The main drawback of mechanical tilt is its
distortion in the horizontal pattern since it provides higher attenuation at the main
lobe's azimuth direction. This is acceptable only if small tilts are required.
Id:0900d805806fc7da 31
For larger down tilts, electrical tilting is more effective in reducing the effective coverage
across the antenna's entire horizontal main lobe.
SINR optimization by down tilting

The down tilt angle setting in OFDM system differs slightly from the conventional tilt
angle calculation. This is because the traditional down tilt formula is based on maximiz-
ing the signal strength at the receiver without taking into account the strong co-channel
interference that results from tight frequency reuse.
When dealing with co-channel interference, the suppression of the upper vertical side
lobe is essential after a certain distance from the cell edge.
Flexi BTS configuration parameters

There will be standard Flexi Multiradio BTS LTE parameters used to control RF aspects
such as the Antenna Round Trip Delay, which will be configured when commissioning
the BTS based on specific site information.
2.6 Interference mitigation

Interference mitigation for up to 4 receive antennas must be considered in LTE. In
contrast to WCDMA or HSPA, however, intra-cell interference does not (or at least only
in high mobility scenarios) occur in LTE.
2.7 RAN sharing

Nokia Siemens Networks plans to support MOCN (multiple operator core networks) as
the LTE network sharing functionality.
The MOCN solution allows two operators to share the complete Flexi Multiradio BTS. In
this solution both operators share:
• cell
• system module
• RF module
• parameterization
• NetAct
• transport I/F: physical S1 and X2 interface
• RF feeder line
32 Id:0900d805806fc7da
RF Feeder Line A + B
PLM
NA
,B
RF Module Operator A+B

RF Module Operator A+B
System Module Operator A+B
S1 Operator A
S1 Operator B
Figure 15 Operator modules in RAN sharing
Id:0900d805806fc7da 33
3 3'I
MME
S-GW /PERATOR! IMS
8 P-GW
MME
PDN
S-GW /PERATOR" Public IP
Services
P-GW
IMS
MME
8
S-GW /PERATOR#
IMS
P-GW
Figure 16 RAN sharing architecture

For Inter RAT mobility it is assume that each operator has its own network. Therefore
operator specific Inter RAT neighbor lists are planned to be supported.
From O&M perspective, the whole eNB is shared and also the configuration, parameter
settings, and feature activations are shared. The only necessary distinction in configu-
ration for the two operators will be visible in the different configuration of the S1 inter-
faces.
2.8 Flexi Multiradio BTS LTE

Nokia Siemens Networks’ LTE evolved node B (eNB) is based on the Flexi Multiradio
BTS. The same Flexi Multiradio System and RF Modules are used for WCDMA/HSPA
and for LTE. With downloadable LTE SW, the Flexi Multiradio BTS is operating in LTE
SW mode. From a BTS site installation and hardware point of view, Flexi Multiradio BTS
enables operators to build BTS sites using modules, without a specific BTS cabinet.
34 Id:0900d805806fc7da
Multiradio System Module
3-sector RF Module
AC/DC + Battery Module
Figure 17 Flexi Multiradio BTS site solution

As shown in Figure 17, the complete macro high power outdoor 1+1+1 @ 60 W Flexi
Multiradio BTS consists of:
• system module
• 3-sector RF module for 60 W per sector/cell
• optional AC/DC and battery module
The full LTE BTS (DC powered) is as light and as small as about 50 kg and 50 liters.
The Flexi Multiradio BTS modules can be used very flexibly with different BTS configu-
rations, with optional AC/DC and battery back-up module, and the operator's own site
equipment, for an integrated site solution. Ultimate LTE capacity can be achieved with
optional 2TX MIMO configuration.
A complete macro high power outdoor 1+1+1 @ 60 W + 60 W Flexi Multiradio BTS
consists of:
• system module
• two 3-sector RF modules for 60 W + 60 W per sector/cell
• optional AC/DC and battery module
The Flexi Multiradio BTS provides very high radio downlink output power when using
Flexi 210W 3-sector Radio Module. In the 3-sector BTS all RF functions are integrated
to one single outdoor installable 3U high module. With two 3-sector RF Modules in 2TX
MIMO configuration TX power is 120W per sector/cell (60 W + 60 W).
Id:0900d805806fc7da 35
to r 1 to r 2 to r 3
ec c c
S Se Se
RX3
O p tio na l T M A /M H A T x1/R X 1
RX4
T x2/R X 2
M u ltiradio S yste m M o d u le
T w o 3- se cto r R F M o d u le s
O p tio na l A C /D C + B a tte ry
Figure 18 Flexi Multiradio BTS site solution for the 2TX MIMO in a 3-sector configu-
ration
Another option especially for feederless and distributed LTE BTS sites is Flexi Multiradio
Remote Radio Head (RRH) that can support one sector with the following integrated fea-
tures:
• two transceivers to support 2TX MIMO
• 30 W + 30 W output power at antenna connectors
• two linear power amplifiers
• two RF filters for TX/RX
• 2 way RX diversity
• wide bandwidth support (up to 20 MHz depending on 3GPP band RF variant)
• 48 V DC input power supply
• no fans
• OBSAI optical interface to the BTS system module
• antenna tilt support
36 Id:0900d805806fc7da
Figure 19 Flexi Multiradio RRH 60 W

The Flexi Multiradio BTS provides the following installation options:
• wall installation
• floor installation
• any legacy cabinet installation
• pole installation
• inside constructions
Id:0900d805806fc7da 37
2.9 Spectrum and bandwidth deployment for LTE

LTE has some 13 FDD bands and 8 TDD bands available at the moment. Significant
overlap exists between some of the bands, but this does not necessarily simplify designs
since there can be band-specific performance requirements based on regional needs.
There is no consensus on which band LTE will first be deployed, since the answer is
highly dependent on local variables. This lack of consensus is a significant complication
for equipment manufacturers and contrasts with the start of GSM and WCDMA, both of
which were specified for only one band. What is now firmly established is that one may
no longer assume that any particular band is reserved for any particular access technol-
ogy.
E-UTRA Uplink (UL) UE transmit Downlink (DL) eNB UL-DL band Duplex
band eNB receive transmit UE receive separation mode
FUL_low – FUL_high FDL_low – FDL_high FDL_low – FUL_high
1 1920 – 1980 MHz 2110 – 2170 MHz 130 MHz FDD
2 1850 – 1910 MHz 1930 – 1990 MHz 20 MHz FDD
3 1710 – 1785 MHz 1805 – 1880 MHz 20 MHz FDD
4 1710 – 1755 MHz 2110 – 2155 MHz 355 MHz FDD
5 824 – 849 MHz 869 – 894MHz 20 MHz FDD
6 830 – 840 MHz 875 – 885 MHz 35 MHz FDD
7 2500 – 2570 MHz 2620 – 2690 MHz 50 MHz FDD
8 880 – 915 MHz 925 – 960 MHz 10 MHz FDD
9 1749.9 – 1784.9 MHz 1844.9 – 1879.9 MHz 60 MHz FDD
10 1710 – 1770 MHz 2110 – 2170 MHz 340 MHz FDD
11 1427.9 – 1452.9 MHz 1475.9 – 1500.9 MHz 23 MHz FDD
13 777 – 787 MHz 746 – 756 MHz –41 MHz FDD
14 788 – 798 MHz 758 – 768 MHz –40 MHz FDD
20 832 – 862 MHz 791 – 821 MHz –71 MHz FDD
....
33 1900 – 1920 MHz 1900 – 1920 MHz N/A TDD
34 2010 – 2025 MHz 2010 – 2025 MHz N/A TDD
35 1850 – 1910 MHz 1850 – 1910 MHz N/A TDD
36 1930 – 1990 MHz 1930 – 1990 MHz N/A TDD
37 1910 – 1930 MHz 1910 – 1930 MHz N/A TDD
38 2570 – 2620 MHz 2570 – 2620 MHz N/A TDD
39 1880 – 1920 MHz 1880 – 1920 MHz N/A TDD
40 2300 – 2400 MHz 2300 – 2400 MHz N/A TDD
Table 4 Frequency bands supported in LTE
38 Id:0900d805806fc7da
For Flexi Multiradio BTS LTE supported frequency bands please refer to the Flexi Mul-
tiradio BTS product description.
2.10 External interfaces of the Flexi Multiradio BTS LTE

The external interfaces (see Figure 20) of the Flexi Multiradio BTS LTE include:
• LTE-Uu interface between eNBs and UEs, acting as the user and control plane
between E-UTRAN and UEs.
• S1-MME interface between eNBs and MME, carrying control plane traffic between
E-UTRAN and MME.
• S1-U interface between eNBs and S-GW, carrying user plane traffic between E-
UTRAN and S-GW.
• O&M interface between eNBs and NetAct via iOMS
• O&M interface between eNB and BTSSM
• X2 interface between eNBs
Integrated Operation
User Equipment Mediation System
LTE-Uu
O&M
S1-U O&M BTS

Serving Gateway Site Manager
X2
S1-MME
Mobility Management other eNBs
Entity
Figure 20 External interfaces of the Flexi Multiradio BTS LTE
Id:0900d805806fc7da 39
Network and service management LTE RAN system description
3 Network and service management
3.1 Network management architecture

The Nokia Siemens Networks LTE/EPC network management system is easily scal-
able; all network sizes are supported. Some of the solutions have already been in use
in Nokia WCDMA (3G) networks and have been developed further for LTE/EPC. From
the users’ point of view, managing the Nokia Siemens Networks Mobile LTE/EPC
network is very similar to that of Nokia WCDMA when NetAct ™ is used.
The LTE/EPC network management architecture is described in Figure 21.
.-3
3rd party
NetAct XML NMS
BTSOM NE3S/SNMP
S1-MME
eNB MME
X2 S11
S1-U S5
eNB S-GW P-GW
Evolved UTRAN Evolved Packet Core
Figure 21 LTE/EPC network management architecture

Management system traffic to and from LTE/EPC network elements always goes
through NetAct ™. The LTE RAN Element Manager has its own direct interface. The
interface between the Flexi Multiradio Base Station and NetAct ™ is based on the
BTSOM protocol. It carries all the necessary data and commands (for example, alarms,
measurements, configuration and new software data) to control the network element
behavior remotely. The interface between the Element Managers for MME and EPC-
GW is based on the NES3/SNMP protocol.
NetAct ™ offers an open northbound interface for other management systems and
provides advanced tools for full-scale management functionality (FCAPS). Textual and
graphical presentation of measurement data reporting is based on 3GPP formats.
The LTE/EPC Element Managers can present alarm and measurement information, for
example, active alarms. However, these capabilities are not on the same level as the
NetAct ™ capabilities. The NetAct ™ southbound interface can be used to integrate
other core and access network elements under common management.
For more details see Operability.
40 Id:0900d805806f2b8b
LTE RAN system description Network and service management
3.2 Managing the LTE/EPC system with NetAct TM

NetAct ™, the network management application for the Nokia Siemens Networks
LTE/EPC system, is a network and service management solution that consists of
numerous tools for handling a number of network elements and expanding networks. It
is designed to be able to handle an increase in both complexity of the network and
volume of traffic and data.
With NetAct ™ both the network and services within the network are managed centrally,
that is, the operator can view the network element failures, service quality indicators,
and traffic from one screen.
NetAct ™ provides full FCAPS (Fault, Configuration, Accounting, Performance, Secu-
rity) functionality comprising:
• fault management
• performance management
• configuration management
• topology management
• basic administration and access to local node/element managers
• centralized software management
• alarm filtering and reclassification, modifiable alarm manual
NetAct ™ fault management and performance management functions together can help
operators guarantee end user access to the services through LTE, thus improving sub-
scriber perception of the service quality. Problems with, for example, hardware modules,
physical channels or priority settings, or in handovers (HOs), packet transmission or
serving cell changes can be detected and corrected without delay.
NetAct ™ performance management functionality provides analysis data that indicates
the geographical areas where high speed data access is most needed and used.
NetAct ™ Key Performance Indicators (KPIs) enable the operator to analyze the use of
LTE/EPC in their network.
The NetAct ™ functionality for LTE/EPC is implemented in OSS5.2.
3.3 Element management tools

Network element (NE) level management is handled by individual element managers
which can be operated remotely from NetAct ™ or from local terminals. The operator
can access these NE management functions via a graphical user interface (GUI) that is
provided by the NE local management tool (LMT). This management tool is also called
Element Manager (EM).
Graphical user interfaces offer online help. This helps the user to perform operation and
maintenance tasks fast and without errors. GUIs are built on top of the services that
network elements offer. Network element level services are managed using a local GUI.
NetAct ™ handles services with broader focus, for example, network-wide management
or service management. Local GUIs are also available in NetAct ™.
Radio network rollout and troubleshooting

Usually EMs are used locally for commissioning or setting up the equipment at the site.
However, they are also available in NetAct ™ for remote operations when, for example,
configuring or troubleshooting a single network element. The EM installation package
can be installed to a client workstation that is connected to the operator's network (O&M
DCN).
Id:0900d805806f2b8b 41
Network and service management LTE RAN system description
Flexi Multiradio Base Station (eNB) management

The BTS EM, called Nokia Siemens Networks BTS Site Manager, is used for both local
and remote management. For local management, a PC with the Nokia Siemens
Networks BTS Site Manager is connected to the Local Management Port (LMP) of the
BTS with an Ethernet cable. The Flexi Multiradio Base Station site can also be controlled
remotely by opening a BTS Site Manager session at a remote iOMS or NetAct ™ site.
Nokia Siemens BTS Site Manager comprises the following main features:
• integrated BTS and TRS manager functionality
• BTS site Commissioning Wizard
• configuration of BTS units, cabling and cells
• downloading BTS software releases
• auto-detecting and presenting BTS hardware in a graphical Equipment View
• monitoring and managing BTS, cell and unit states
• alarm monitoring
42 Id:0900d805806f2b8b
LTE RAN system description Mobility
4 Mobility
EPS mobility management comprises functions and procedures that maintain the con-
nectivity between UE and EPS as the UE moves between the coverage areas of differ-
ent base stations or access networks. As far as possible, seamless mobility is provided
so that the mobility is transparent to the UEs and the applications they use. For applica-
tions that require it, the mobility is “lossless”. In other words, the packet loss probability
is very low.
4.1 Mobility scenarios

A number of mobility scenarios is supported as illustrated in Figure 22.
• LTE Intra-RAT mobility comprises:
– Intra-eNB mobility (handover between cells within a certain eNB)
– Inter-eNB mobility (handover between adjacent eNBs).
• Inter-RAT mobility comprises:
– mobility between LTE and other 3GPP RATs (GERAN or UTRAN)
– mobility between LTE and non-3GPP RATs (such as WLAN, WiMAX or 3GPP2
access network (HRPD))
3GPP PS Core
Evolved UTRAN Non-3GPP
UTRAN or WLAN
GERAN WiMAX
UE eNB SGSN 3GPP2
Packet
eNB S-GW P-GW Data
Network
Evolved Packet Core
Figure 22 Mobility scenarios for LTE/EPC
4.2 Mobility anchors

During mobility, the U-plane data path continuity to the PDN is maintained using mobility
anchors as illustrated in Figure 23. These are network element instances which are per-
manent members of the U-plane path and located such that the path from the anchor to
the PDN does not change.
Id:0900d805806fc800 43
Mobility LTE RAN system description
PDN
S2
P-GW non-3GPP
S5/S8a
S5/S8a
S4
S-GW S-GW 3GPP
S1-U S4 Gp/Gn
S1-U
SGSN SGSN
eNB eNB
Rel-8 pre-Rel-8
cell cell
Mobility anchor U-Plane path
Figure 23 Mobility anchor point

The mobility anchors for each mobility scenario are summarized in Table 5.
Mobility scenario Anchor point location

intra-LTE intra-eNB eNB
intra-LTE inter-eNB S-GW or P-GW if S-GW is changed
3GPP inter-RAT S-GW
(P-GW for accesses prior to 3GPP Release 8)
3GPP Inter-RAT (Rel-8 SGSN) S-GW is the anchor if S4 interface is supported by

the SGSN. If the SGSN only supports Gn interface,
the anchor is in GGSN functionality of P-GW.
Table 5 Mobility scenarios and anchor points
4.3 Inter-eNB handover

Inter-eNB handovers are typically handovers that aim to minimize service interruption
and packet loss. Based on measurements received from the UE, the source eNB selects
a target eNB and initiates the handover. The signaling takes place over the X2 interface.
If there is no X2 connectivity between the base stations, the signaling must take place
via the MME and via the S1-MME interface. These two alternatives are illustrated in
Figure 24 and Figure 2.
The UE can access the target eNB after the resources have been reserved and the
bearers are set up. To avoid packet loss, the source eNB forwards all downlink packets
that are not yet acknowledged by the UE via the X2 interface to the target eNB. In uplink,
44 Id:0900d805806fc800
LTE RAN system description Mobility
the UE will switch to the target cell and then re-transmit all packets which have not been
acknowledged in the sequence before the handover.
At the Serving Gateway, late path switching is performed. This means that the downlink
path is not switched to the target eNB before the handover is completed. Thus, packet
bi-casting is avoided.
Path switch
S-GW S-GW
Packet forwarding 3 3 3 3
for not acknowledged SDUs,
use of PDCP sequence number
Source eNB
eNB 8
8 8
DL prioritization
Target of packets forwarded
UE eNB from source eNB
UL reordering
based on PDCP
sequence numbers
Figure 24 Inter-eNB handover with X2 interface
4.4 Inter-RAT handover (3GPP)

3GPP inter radio access technology (inter-RAT) handovers differ from intra-LTE inter-
eNB handovers in that there is no control plane (signaling) interface between the eNB
and the non-LTE radio access network. Therefore, signaling between the access
systems always takes place via MME and SGSN.
Like inter-eNB handovers, 3GPP inter-RAT handovers are typically backward han-
dovers. In other words, radio resources are prepared in the target access system before
the UE is commanded by the source access system to switch over to the target access
system.
Another possibility for handling 3GPP inter-RAT mobility is to force the UE to idle state
and perform a tracking area update (TAU) if the target network is the LTE network, or
routing area update (RAU) if the target network is the non-LTE network as illustrated in
Figure 25.
Id:0900d805806fc800 45
Mobility LTE RAN system description
UTRAN 3GPP PS Core

Gb Backward handover
SGSN or
GERAN Iu
Force UE to idle state and
No direct signalling interface S4 S3 perform TAU or RAU
between UTRAN and eNB
Evolved UTRAN
S1-MME
eNB MME
X2 S11
S1-U S5 SGi Packet

eNB S-GW P-GW Data
Network
Evolved Packet Core
Figure 25 3GPP inter-RAT handover
46 Id:0900d805806fc800
LTE RAN system description Radio resource management and telecom
5 Radio resource management and telecom

RRM is responsible for the management of the available radio resources to enable pro-
visioning of high quality services to users without compromising overall radio network
capacity and performance. To meet user and system requirements, RRM functions have
an impact on L2 and L3 functions and procedures as well as cooperating with U-plane
and C-plane functions.
5.1 RRM functions

RRM provides the following L3 and above (L3+) functions to the system:
• Radio Bearer Control (RBC)
• Radio Admission Control (RAC)
• Connection Mobility Control (CMC)
• Dynamic Resource Allocation (DRA)
• Inter-cell interference RRM & load management (ICR)
• Radio Configuration (RC)
• Inter-RAT RRM (IRR)
In addition, RRM L3 functions use the following lower layer functions defined in L1/L2 to
alter the behavior of the system:
• UL/DL Power Control
• Congestion Control
• DTX/DRX Control
• Link Adaptation (Adaptive Modulation and Coding)
• Link Quality Control
• HARQ Control
• MIMO and Aerial Control
The difference between L3 RRM and L1/L2 functions reflects the scope of functions
(more global or local), interactions with other layers (C-plane and O&M as opposed to
U-plane and RLC/MAC/PHY layers) and responsiveness (relatively slow or fast in com-
parison to TTI levels).
RRM functions have an impact on system behavior which ranges in its scope from UE
to Inter-RAT. This is summarized in Table 6.
System Aspect L3+ RRM functions L1/L2 functions

UE Connection Mobility Control UL/DL Power Control
Link Adaptation
Link Quality Control
MIMO/Aerial Control
DRX/DTX Control
Cell Radio Bearer Control Dynamic Resource Allocation
Radio Admission Control (for example, Packet Scheduling)
Radio Configuration Congestion Control
E-UTRAN Load Balancing
Inter Cell Coordination
Table 6 Scope of RRM functions
Id:0900d805806f2b8f 47
Radio resource management and telecom LTE RAN system description
System Aspect L3+ RRM functions L1/L2 functions

Inter-RAT Inter RAT Handover
Table 6 Scope of RRM functions (Cont.)
In comparison with pre-LTE UMTS system the main difference reflects decentralized
RRM control moved to the edge of E-UTRAN (RRM resides at eNB) as opposed to the
centralized RRM control in UMTS (RNC entity performs most RRM functions).
Softer and Soft handovers are not supported by the LTE system and requirements on
power control are much less stringent due to the different nature of LTE radio interface
(WCDMA requires fast power control to address the "Near-Far" problem and intra-fre-
quency interference). On the other hand, the LTE system requires much more stringent
timing synchronization for OFDMA signals.
RRM functions for unicast transmission

RRM functions, including inter-cell RRM functions, are implemented at the eNB. There
is no central RRM server entity coordinating RRM tasks. The functions are:
• Radio Bearer Control (RBC)
• Radio Admission Control (RAC)
• Connection Mobility Control (CMC)
• Dynamic Resource Allocation (DRA)
• Inter-cell interference RRM & load management (ICR)
• Radio Configuration (RC)
• Inter-RAT RRM (IRR)
The Radio Bearer Control (RBC) function is responsible for the establishment, main-
tenance and release of radio bearers. The radio bearer establishment procedure with
the aid of the RAC function ensures that system resources can be allocated to the new
bearer without compromising in-progress sessions. RBC also supervises bearers,
making sure they will not suffer due to changes in the radio resource situation caused
by, for example, the mobility of other users. The release of radio resources associated
with radio bearers caused by session termination or handover is also controlled by RBC.
The Radio Admission Control (RAC) function is invoked every time a new radio bearer
is to be set up. RAC admits or rejects requests to create bearers, depending on whether
the system can or cannot meet a new bearer's QoS requirements without compromising
ongoing sessions.
The Connection Mobility Control (CMC) function provides support for ECM-IDLE and
ECM-CONNECTED mobility control. In ECM-IDLE state, CMC is responsible for setting
up cell-reselection criteria, measurement configuration and restricting access to the cell
due to heavy load. In ECM-CONNECTED state, CMS configures intra/inter RAT mea-
surements and provides load and traffic distribution information to entities responsible
for making handover decisions.
The Dynamic Resource Allocation (DRA) function coordinates transmission power
levels and frequencies used in a cell. DRA provides input for the packet scheduler,
whose aim is to meet the QoS requirements of the traffic and utilize resources efficiently
under varying load and radio conditions (packet scheduling is not a part of the RRM
functions).
The Inter-cell interference RRM & load management (ICR) function provides coordi-
nation of resource allocation between eNBs to minimize inter-cell interference. ICR may
48 Id:0900d805806f2b8f
LTE RAN system description Radio resource management and telecom
be part of O&M or it might be performed in a distributed network among eNBs. ICR can
deal with situations where the load between cells is uneven, and informs the RRM entity
of the interference level of neighboring cells. This helps to optimize radio resources and
guarantees that a high level of QoS can be provided. Load distribution can be enforced
by network triggered handovers or cell re-selections to redistribute traffic from heavily
loaded cells to underutilized cells.
The Radio Configuration (RC) function configures global parameters in the cell that
provide information necessary for idle and active mode mobility by defining pools of
resources available for dynamic allocations. RC enables operators to set up their
network in a consistent manner providing global strategies and policies to be applied in
a more dynamic manner to RRM algorithms. In this way operators can achieve dynamic
capacity and coverage control of the cells according to traffic demands.
The Inter-RAT RRM (IRR) function aids the management of resources during inter-RAT
handover. Handover decisions may take into account UE capabilities, operator policies,
availability of resources, and traffic load condition in the target system. Load balancing
functions may also use IRR to obtain information enabling them to redistribute users to
other RATs.
5.2 RRM procedures and measurements

RRM covers the procedures and performance requirements that are used to make
effective use of the radio resources.
As defined in TS 36.133 the most basic requirements in the LTE_RRC_IDLE state cover
initial cell selection and cell reselection procedures including those between different
radio access technologies (RAT). Additional procedures are defi ned in the
LTE_RRC_CONNECTED state related to handover and measurement performance.
RRM covers the following:
• Procedures during LTE RRC_IDLE state mobility
• Procedures during LTE RRC_CONNECTED state mobility
• Procedures for RRC connection mobility control
• Timing and signaling characteristics
• Procedures for UE measurements in RRC_CONNECTED state
• Performance requirements for UE measurements
• Performance requirements for LTE measurements
Procedures during LTE RRC_IDLE state mobility

• Cell selection
• Cell re-selection
– LTE intra-frequency, LTE inter-frequency, UTRAN FDD
– UTRAN TDD, GSM
Procedures during LTE RRC_CONNECTED state mobility

Handover delay and interruption requirements for
• LTE FDD – FDD, LTE FDD – TDD, LTE TDD – FDD
• LTE TDD – TDD, LTE – UTRAN FDD, LTE – UTRAN TDD
• LTE – GSM
Id:0900d805806f2b8f 49
Radio resource management and telecom LTE RAN system description
Procedures for RRC connection mobility control

• RRC re-establishment
• Random access
Timing and signaling characteristics

• UE transmit timing
• UE timer accuracy
Procedures for UE measurements in RRC_CONNECTED state

• E-UTRA UE measurements
– LTE FDD intra frequency measurements
– LTE TDD intra frequency measurements
– LTE FDD – FDD inter frequency measurements
– LTE FDD – TDD inter frequency measurements
– LTE TDD – FDD inter frequency measurements
– LTE TDD – TDD inter frequency measurements
• Inter-RAT measurements
– LTE FDD – UTRAN FDD measurements
– LTE TDD – UTRAN FDD measurements
– LTE FDD – UTRAN TDD measurements
– LTE TDD – UTRAN TDD measurements
– LTE FDD – GSM measurements
– LTE TDD – GSM measurements
Performance requirements for UE measurements

• Absolute RSRP accuracy
• Relative accuracy of RSRP
• Inter-frequency RSRP accuracy requirements
• UTRAN FDD CPICH RSCP
• UTRAN FDD carrier RSSI
• UTRAN FDD CPICH Ec/No
• UTRAN TDD P-CCPCH RSCP
• UTRAN TDD carrier RSSI
• UTRAN TDD P-CCPCH RSCP
• GSM carrier RSSI
Performance requirements for LTE measurements

• DL RS Tx power
For detailed information see the Physical layer, u-plane protocol stacks and SIB FAD.
50 Id:0900d805806f2b8f
LTE RAN system description Transport and transmission
6 Transport and transmission
6.1 LTE transport

All protocol stacks for User (U), Control (C) and Management (M) planes in Figure 26
are based on IPv4. From a mobile backhaul perspective, the Flexi Multiradio BTS LTE
acts as an IP host. User IP packets are tunneled between BTS (eNB ) and S-GW using
GTP-U.
IP based protocol stacks enable lower transport cost and easier planning and configu-
ration. On the other hand, RAN traffic becomes more vulnerable to hacker attacks, so
security features are mandatory. Consequently, the Flexi Multiradio BTS LTE supports
IPSec authentication and encryption for all traffic, including M-, C- and U-plane. The
IPSec throughput performance is sufficient for even the largest possible eNB configura-
tion.
Flexi S 1-c
Multiradio X 2-u/c (S 1-MM E )
B TS
MM E
IP
Inter- eNB
conne ctivity
S 1-u
(S1-U)
S-G W/P-GW
NetA ct
O&M
Flexi
Multiradio
B TS
Figure 26 Flexi Multiradio BTS interfaces

Flexi Multiradio BTS interfaces to the backhaul connection are provided by field-replace-
able Flexi Transport sub-modules which are mounted on top of the Flexi System Module
core. Selected Flexi Transport sub-modules support both LTE and WCDMA SW appli-
cations (multi-radio).
In the basic configuration, Flexi Multiradio BTS LTE supports a single IP address for
combined M-plane and U/C-plane. While this feature simplifies network configuration,
more complex addressing options are also supported (such as separate IPSec tunnel
end point addresses, separate address for M-plane).
Id:0900d805806f2b91 51
Transport and transmission LTE RAN system description
6.2 Control plane transport (RAN signaling)

LTE RAN signaling consists of both Access Stratum (AS) and Non-Access Stratum
(NAS) elements. An overview of LTE RAN signaling connections is presented in Figure
27.
CELL BCCH eNB1 MME

Signaling may be received
PCCH S1-AP
by all UEs in the Cell
Connectionless
Signaling
UE1 UE1 NAS Signaling
(Actually carried over UE1 [S1-AP+RRC DCCh2])
UE1 NAS UE1 NAS
DCCH1
UE1 RRC DCCH2 UE1 S1-AP UE1 S1-AP
Connection Oriented
.......
.......
.......
Signaling
.......
UEn UE1 NAS Signaling
(Actually carried over UEn [S1-AP+RRC DCCh2])
UEn NAS UEn NAS
DCCH1
UEn RRC DCCH2 UEn S1-AP
Connection Oriented
UEn S1-AP
Signaling
X2-AP
(eNB1 - eNB2)
eNB1
Figure 27 LTE RAN signaling connections

The protocol stacks for the LTE-Uu, S1 and X2 reference points are shown in Figure 28.
The X2 reference point is used during handovers and to exchange cell/eNB specific
information between the eNBs. In this figure IPSec is shown as contained within the IP
part of the protocol stack. In reality IPSec can operate in one of several different modes,
each with a different level of encapsulation, that is, some modes include the encapsula-
tion of the original IP header and construction of a new IP header.
g In all cases the DiffServ Code Point (DSCP) should be available in plain text in the
outer IP header.
NAS messages are not transferred between eNBs during handover; therefore, there
is no need for NAS in the X2 protocol stack.
52 Id:0900d805806f2b91
UE eNB MME
NAS Signaling NAS Signaling Target eNB Source eNB
Protocols Protocols
(including security) (including security)
X2-AP X2-AP
RRC RRC S1-Application S1-Application
Protocol (S1-AP) Protocol (S1-AP)
PDCP PDCP SCTP SCTP

SCTP SCTP
RLC RLC IPSec IPSec
IPSec IPSec
MAC MAC IP inc. Diffserv IP inc. Diffserv IP inc. Diffserv IP inc. Diffserv
Data Link Layer 2 Data Link Layer 2 Data Link Layer 2 Data Link Layer 2
PHY PHY
PHY Layer 1 PHY Layer 1 PHY Layer 1 PHY Layer 1
LTE-Uu S1-MME X2
Figure 28 Control plane protocols
6.2.1 RRC Signaling Protocol (eNB <> UE)

The RRC protocol [TS36.331] is responsible for the transfer of signaling information
between the eNB and UE. It consists of common 'cell wide' broadcast information and
dedicated signaling specific to an individual UE. It is used for:
• AS Signaling Connection Control
• Radio Bearer Control Signaling
• Mobility handling
• UE Measurement Reporting
• UE Power Control
• UE Security Signaling
• MBMS Control Signaling
• Transport of NAS Messages
• Distribution of Cell and System Information Broadcast
• Distribution of Paging Signaling
Id:0900d805806f2b91 53
To / From RRC
RRC Message
PDCP Sequence
Numbering / Packet
Reordering
PDCP SN RRC Message
Integrity Protection
PDCP SN RRC Message MAC*
C-Plane Ciphering
RLC SDU (Ciphered + Integrity Protected)
To / From MAC
Figure 29 C-plane operation of PDCP

RRC signaling is transported over the LTE-Uu interface using the Packet Data Conver-
gence Protocol (PDCP) and the Radio Link Control (RLC) protocol in a similar way to U-
plane data. This is illustrated in Figure 29. Note that MAC* is the Message Authentica-
tion Code added by integrity protection in PDCP. For more details on RLC see Figure
31.
For C-plane signaling the PDCP layer is responsible for:
• Maintenance and assignment of PDCP sequence numbers which are attached to
packets
• Application of C-plane integrity protection
• Application of C-plane ciphering
6.2.2 S1AP Signaling Protocol (eNB <> MME)

The S1AP protocol [TS36.413] is responsible for transferring signaling information
between the eNB and MME over the S1-MME reference point. S1AP is carried using
Stream Control Transmission Protocol (SCTP) [RFC 4960]. It is used for:
• QoS Bearer Management (Activation, Modification, and Deactivation of EPS
Bearers)
• S1 Signaling Bearer Management
• Paging Distribution Signaling
• Mobility Signaling
• Security Mode Signaling
• S1 Interface Management (Setup, Reset, Reset Resource, Overload and Error Indi-
cation)
• Tracking Area Control Signaling
• Trace Configuration Signaling
• Transport of NAS Messages
54 Id:0900d805806f2b91
6.2.3 X2AP Signaling Protocol (eNB <> eNB)

The X2AP protocol [TS36.423] is responsible for transferring signaling information
between neighboring eNBs over the X2 reference point. X2AP is carried using SCTP.
This signaling is used for:
• Handover Signaling
• Inter-Cell RRM Signaling
• X2 Interface Management (Setup, Reset, Reset Resource and Error Indication)
6.2.4 NAS Signaling Protocol (MME <> UE)

NAS Signaling Protocols provide C-plane signaling between the UE and MME which is
not processed by the eNB. NAS messages are encapsulated into the RRC and S1AP
protocols in order to provide direct transport of NAS signaling between the MME and UE.
The eNB is responsible for mapping NAS messages between the RRC and S1AP pro-
tocols. NAS messages are involved during the following procedures:
• Allocation of S-TMSI
• Identification
• Authentication
• Attach, Detach, Tracking Area Update
• Bearer Handling
• Service Request
• Paging
• Handover
6.3 User plane transport

Within LTE/EPC an EPS bearer is used to transport user data between the UE and the
P-GW (or the S-GW for PMIP S5/S8). An EPS bearer consists of a radio bearer, an S1
bearer and possibly an S5/S8 Bearer (non-PMIP).
Within the LTE network, GTP-U is the tunneling protocol used for transport of user data
between nodes as shown in Figure 30. It is used across the following reference points:
• S1-U for transfer of user data between the eNB and S-GW
• X2 for transfer of user data between source eNB and target eNB during lossless
inter-eNB handover
• S4 for transfer of user data between the S-GW and SGSN during lossless inter-
system handover
• S5/S8a (3GPP version) for transfer of user data between S-GW and P-GW
g PMIP is used instead of GTP for the S5-PMIP and S8b reference points.
The use of IPSec is shown across the S5/S8 reference point. For RL09 and
RL10 the S-GW and P-GW are co-located and IPSec is not required. This is also
the case when the network between them is trusted.
Id:0900d805806f2b91 55
UE eNB S-GW P-GW End User
Application Application
TCP/UDP TCP/UDP
IPv4/IPv6 IPv4/IPv6
IETF IETF
PDCP PDCP GTP-U GTP-U
GTP-U GTP-U
Data Link Data Link
UDP UDP UDP
RLC RLC UDP
IPSec IPSec IPSec IPSec
MAC MAC IP inc. Diffserv IP inc. Diffserv IP inc. Diffserv IP inc. Diffserv
PHY PHY
Data Link Data Link Data Link Data Link
PHY PHY
PHY PHY PHY PHY
LTE-Uu S1-U S5/S8
Figure 30 User plane protocols

User data transport for the E-UTRAN comprises:
• LTE-Uu user plane transport
• S1-U user plane transport
• X2 user plane transport
6.3.1 LTE-Uu user plane transport

The Radio Bearer is responsible for transport of data between UE and eNB over the
LTE-Uu interface using the PDCP protocol (see Figure 30).
User data transport over the Radio Bearer is managed by Packet Data Convergence
Protocol (PDCP) [TS36.323] and Radio Link Control (RLC) [TS36.322] in the UE and
eNB. Figure 31 illustrates the processing performed on packets within PDCP and RLC.
56 Id:0900d805806f2b91
To/From S1-U
Data Header
PDCP Header Compression (RoHC)
Data Header
U-Plane Security
Encrypted Data with Compressed Header
PDCP Packet Reordering
RLC SDU (Encrypted Data with Compressed Header & PDCP SN)
RLC
Segmentation and Re-assembly
RLC PDU
RLC PDU
RLC PDU
RAN Packet Re--ordering
Outer Assured Delivery
To/From MAC Layer
Figure 31 U-plane operation of PDCP and RLC

For U-plane traffic the PDCP layer is responsible for:
• management and assignment of PDCP sequence numbers which are attached to
packets
• in-sequence delivery of upper layer SDUs during inter-eNB handover via the X2 ref-
erence point using the PDCP
• detection and elimination of duplicate lower layer SDUs during inter-eNB handover
via the X2 reference point
• IP header compression and decompression for data transferred over the LTE-Uu,
using RoHCv2 [RFC 4995]
• application of U-plane security (if required) which encrypts or decrypts U-plane data
transferred over the LTE-Uu
• forwarding of PDCP SDUs at inter-eNB handover via the X2 reference point
The RLC layer is responsible for:
• Segmentation and re-assembly of RLC SDUs into RLC PDUs whose size match the
block size used by the physical radio layer. (This may involve the concatenation of
small RLC SDUs into larger blocks.)
• RAN Packet Reordering of packets that are received out of sequence so that RLC
PDUs are concatenated in the correct order before delivering the SDU to PDCP.
• Outer Assured Delivery which provides a high level of confidence that RLC PDUs
were successfully delivered to the receiver.
Id:0900d805806f2b91 57
6.3.2 S1-U user plane transport

The S1 Bearer is used for transport of user data between eNB and S-GW over the S1-
U using GTP-U protocol (see Figure 30). Each S1-Bearer consists of a pair of GTP-U
tunnels (one for uplink and one for downlink). The eNB performs mapping between
Radio Bearer IDs (RBID) and GTP-U tunnel endpoints.
6.3.3 X2 user plane transport

From a U-plane perspective the X2 reference point is used for forwarding user data
between the source eNB and target eNB during lossless inter-eNB handover. A GTP-U
tunnel is established across the X2 reference point between the source eNB and the
target eNB. Thus the protocol stack is the same as that over the S1-U (see Figure 28
and Figure 30).
The source eNB forwards uplink PDCP SDUs received out of sequence and all downlink
PDCP SDUs to the target eNB via the X2 GTP-U tunnel. Any uplink PDCP SDUs
received in sequence by the source eNB are forwarded directly to the S-GW in the
normal manner. Uplink PDCP SDUs are reordered by PDCP in the target eNB, based
on PDCP sequence number, similarly downlink PDCP SDUs are reordered by PDCP in
the UE.
6.4 Transport interface options

The Nokia Siemens Networks LTE/EPC architecture supports a wide range of physical
interfaces and will not preclude the use of any physical medium with which it is econom-
ical to build a transport network.
The Network Elements (NEs) support Ethernet Interfaces. Other transport technologies
such as DSL and Microwave are supported by the use of external equipment.
Ethernet
Ethernet will be the main eNB backhaul option as illustrated in Figure 32. Commonly, a
network terminating device (leased line termination, MWR IDU, xDSL CPE, etc.) is
present at the eNB site, so an electrical connection is most economical. If fiber access
is available at the site, the Flexi Multiradio BTS LTE can be connected directly.
The following interface types are supported:
• Fast Ethernet (FE) 100Base-TX, electrical
• Gigabit Ethernet (GE) 1000Base-T, electrical
• Gigabit Ethernet (GE) 1000Base-SX/LX/ZX through optional SFP module, optical
58 Id:0900d805806f2b91
E th IP/Ethe rne t IP/Ethe rne t MM E
Flexi IP Router
Multiradio (S ecurity G W )
B TS
S-G W/P-GW
S 1/X 2 U/-plane S 1 U/C-plane
IP /IPS ec IP /IPS ec IP
E thMac E thMac E thMac E thMac
E thP hy E thP hy E thP hy E thP hy
Figure 32 Ethernet backhaul for LTE/EPC

The Ethernet interfaces, based on the IEEE 802.3-2002 standard (with type interpreta-
tion of the type length field, Ethernet II/DIX frame), support the following features:
• full-duplex transmission mode
• auto-negotiation and forced mode for the duplex mode (only full duplex advertised)
• auto-negotiation and forced mode for the data rate
• auto-negotiation and forced mode for MDI/MDIX
• VLAN tagging according to IEEE 802.1q
• Ethernet priority bits (p-bits) according to IEEE 802.1p
• IPv4 over Ethernet
• ICMPv4
• Address Resolution Protocol (ARP)
U-plane IP packets may exceed the maximum MTU size of the Ethernet backhaul link
due to additional packet overhead (GTP-U, UDP, IP/IPSec). Jumbo frames are not sup-
ported by all Ethernet transport equipment, thus not a generic solution. Instead, the Flexi
Multiradio BTS LTE supports IP fragmentation and reassembly (including IPSec over-
head).
Id:0900d805806f2b91 59
6.5 Traffic engineering

The following traffic engineering concepts are considered:
• Traffic prioritization
• Traffic separation
• Traffic shaping
• Multi-layer optimization
6.5.1 Traffic prioritization

Traffic prioritization on IP layer
In order to avoid over-dimensioning in the backhaul network, Flexi Multiradio BTS LTE
supports QoS differentiation between user, control and management plane traffic as
outlined in Figure 33. DiffServ is the most common way of traffic prioritization on IP layer.
DSCP values for different U/C/M-plane traffic types are configurable and will be applied
based on an operator specific IP network plan. Traffic end points (eNB, S-GW, MME,
O&M/NetAct) will set DSCP values, while intermediate network elements have to handle
the packets accordingly.
The Flexi Transport sub module performs packet scheduling using 6 queues with SPQ
(Strict Priority Queuing) and WFQ (Weighted Fair Queuing). Each Service Data Flow
(SDF) is associated with a QoS Class Identifier (QCI). The mapping between QCI and
DSCP values is configurable.
MM E
any IP
Flexi IP Router
(S ecurity G W )
Multiradio
B TS S-G W/P-GW
U-plane C-plane M-plane U-plane C-plane M-plane

(User) IP (User) IP
Q oS
G TP -U S 1AP /X 2A P B TS O M mapp ing G TP -U S 1A P B TS O M
(DS CP )
UD P S CTP TCP UD P S CTP TCP
IP IP IP IP IP
L2 L2 L2 E thMac E thMac E thMac
L1 L1 L1 E thP hy E thP hy E thP hy
Figure 33 QoS differentiation between user, control and management plane traffic
60 Id:0900d805806f2b91
Traffic prioritization on the Ethernet layer

If traffic aggregation is performed by Ethernet switching rather than by IP routing, the
transport network may not be IP QoS (DiffServ) aware. In this case, Flexi Multiradio BTS
LTE supports traffic prioritization on the Ethernet layer, using packet marking methods
(code points) applicable to Ethernet as illustrated in Figure 34. Ethernet priority bits
(IEEE 802.1p) and/or VLAN IDs (IEEE 802.1q) can be set per packet, based on the
DiffServ Code Point (DSCP). The mapping table is configurable.
MM E
Eth Ethe rne t
IP Router
Flexi (S ecurity G W )
Multiradio
B TS S-G W/P-GW
U-plane C-plane M-plane U-plane C-plane M-plane

(User) IP (User) IP
Q oS
G TP -U S 1AP /X 2A P B TS O M marking G TP -U S 1A P B TS O M
UD P S CTP TCP UD P S CTP TCP
IP IP IP IP
E thMac E thernet S witching E thMac E thMac E thMac
E thP hy E thP hy E thP hy E thP hy E thP hy E thP hy
Figure 34 Traffic prioritization on the Ethernet layer, using packet marking methods
6.5.2 Traffic separation

It is common practice that M-plane and U/C-plane networks are logically (and in the core
network also physically) separated. This concept supports a security oriented IP
network design (different routing domains). With Flexi Multiradio BTS LTE, M-plane
(O&M) traffic can be separated from U/C-plane traffic, using another IP address from a
different subnet. On the Ethernet layer, traffic can be assigned to different VLANs as
illustrated in Figure 35.
g Layer 2 traffic separation is not restricted to separation between U-plane and M-
plane traffic, but may also be applied in a flexible manner, for example between U-
plane and C-plane traffic.
Id:0900d805806f2b91 61
V LA N1 M-P lane
E th Ethe rne t
V LA N2
Flexi IP Router
Multiradio
B TS U/C-P lane
IP/ MM E
Ethe rne t
S-G W/P-GW
Figure 35 M-plane separation using VLAN over Ethernet
6.5.3 Traffic shaping

The Flexi Multiradio BTS LTE Ethernet interface (FE or GE) supports data rates (100
Mbit/s or 1000 Mbit/s) and burst sizes which may be higher than the capacity of the
Ethernet backhaul link (for example, leased line or capacity limited microwave radio
link). Traffic shaping is required to ensure conformance to the link capacity in order to
minimize packet loss. This applies in particular to Ethernet leased lines where the link
capacity is governed by a Service Level Agreement (SLA).
Traffic shaping reduces the burstiness of Ethernet or IP traffic in conformance with a
given:
• maximum average output rate on Ethernet or IP layer
• maximum burst size on Ethernet or IP layer
If packets need to be dropped despite traffic shaping, this will be done based on priori-
ties (QoS aware). Flexi Multiradio BTS LTE performs single-stage shaping according to
MEF 10.1.
62 Id:0900d805806f2b91
6.5.4 Multi-layer optimization

Multi-layer optimization is a concept which provides optimized application of different
types of network elements, working on L1, L2 or L3 at different locations in the network
topology.
Figure 36 shows a sample network architecture which is split as follows:
• Access
The access network is purely implemented on L2 (Ethernet). For scalability reasons
(limiting broadcast traffic), the network may be partitioned into different VLANs
where bridging takes place at intermediate nodes (for example. microwave radio
hubs). Partitioning should take handover probabilities into account, that is, neighbor-
ing eNBs (eNB1 and eNB2 in the figure) should be assigned to the same VLAN. This
has the advantage that X2 traffic can be switched with low latency close to the eNBs.
• Aggregation
The aggregation network could also be built upon L2. As one solution, VPLS-TE with
one VPLS instance per VLAN can be provisioned. The logical point-to-point struc-
ture allows for sophisticated traffic engineering while high availability can be sup-
ported through physical ring or mesh topologies.
• Core
The core network is IP/MPLS based. As seen from the eNB perspective, the nearest
router will be found here. If a handover has to be performed between eNBs which
do not have L2 connectivity (eNB2 and eNB3 in the figure), X2 traffic will go through
the nearest IP router. However, this should be only occasional since handover prob-
abilities have been considered with the definition of the eNB clusters.
eNB 1
VLAN 1 VP LS-TE IP/M PLS
GW
X 2-u/c
eNB 2
LS P
VLAN 2 LS P
eNB 3
S 1-u
Figure 36 Multi-layer network architecture
Id:0900d805806f2b91 63
6.6 Synchronization
As per 3GPP requirement, the air interface at an eNB in FDD mode needs to be fre-
quency synchronized with an accuracy of 50 ppb.
The following synchronization concepts are considered:
• Synchronization from PDH interface
• Synchronization from 2.048 MHz signal
• Synchronization from GPS
• Timing over Packet
• Synchronous Ethernet
6.6.1 Synchronization from PDH interface

Synchronization from PDH interface is the conventional method applied for legacy base
stations (2G, 3G). The synchronization signal is recovered from a selected E1/T1/JT1
line, the clock of which is traceable to a Primary Reference Clock (PRC). PRC synchro-
nization is usually injected at the core site.
With respect to the Flexi Multiradio BTS LTE, the selected PDH line could carry U/C/M-
plane traffic, as illustrated in the upper part of Figure 37, or it could be dedicated to syn-
chronization purposes only. The latter option is a usual scenario where a PDH con-
nected legacy base station is co-located and forwards the synchronization signal
appropriately.
Flexi
Multiradio
B TS
E 1/T 1 TDM
Flexi
Multiradio
B TS
IP/
E th E 1/T 1 Ethernet
BTS
E 1/T 1
TDM
Figure 37 Synchronization from PDH interface
6.6.2 Synchronization from 2.048 MHz signal

Instead of forwarding the synchronization signal through an E1/T1/JT1 line, co-located
legacy equipment may provide a 2.048 MHz G.703 signal for synchronizing Flexi Multi-
radio BTS LTE as illustrated in Figure 38.
64 Id:0900d805806f2b91
Flexi
Multiradio
B TS
IP/
E th
Ethernet
SY N C
2.048 Mhz
G .703 BTS
SY N C E 1/T 1 TDM
Figure 38 Synchronization from 2.048 MHz signal
6.6.3 Synchronization from GPS

Synchronization from GPS interface is a field-proven technology, applicable if the Flexi
Multiradio BTS LTE is Ethernet connected and PDH connectivity is not available at the
site.
6.6.4 Timing over Packet

Timing over Packet (ToP), based on IEEE 1588v2, is another method to support syn-
chronization if Flexi Multiradio BTS LTE is connected through Ethernet backhaul, as
illustrated in Figure 39. ToP provides CAPEX and OPEX savings as separate PDH links
or GPS are not needed. However, the Ethernet/IP network has to be of sufficient quality
(low frame/packet delay variation).
The Timing over Packet (ToP) solution consists of a Timing Master at the core site and
Timing Slaves implemented in the Flexi Multiradio BTS LTE. The master and slaves
communicate through the IEEE 1588 v2 protocol. The master sends synchronization
messages via the Ethernet/IP network to the slaves. The slaves recover the synchroni-
zation reference from the synchronization messages sent by the master.
Flexi
Multiradio Top
BTS Master
Timing over Packet (IEEE 1588 v2)
Eth
MME
Eth Ethernet
S-GW/P-GW
Figure 39 ToP based synchronization
Id:0900d805806f2b91 65
6.6.5 Synchronous Ethernet

In contrast to ToP, which is essentially a L3 technology, frequency synchronization can
also be extracted directly from the Ethernet interface at the Flexi Multiradio BTS LTE if
the other end supports the Synchronous Ethernet feature as per G.8261.
66 Id:0900d805806f2b91
LTE RAN system description Operability
7 Operability
This chapter provides information about the following operability issues:
• NetAct ™ framework
• Managing the LTE/EPC system with NetAct ™
• BTS Site Manager
• Flexi Multiradio BTS LTE management functions
• Flexi Multiradio BTS supplementary OAM features
• Flexi Multiradio BTS diagnosis
• Self organizing network support
7.1 NetAct ™ framework

NetAct ™ provides advanced applications and services for multi technology and multi
vendor network and service management; for example monitoring, reporting, configur-
ing and optimizing. NetAct ™ provides seamless management not only of LTE access
networks but also of different network technologies with integrated and inter working
tools, which enables the operator to control costs while redeploying competencies and
resources from 2G to 3G, HSPA, I-HSPA and LTE. Textual and graphical presentation
of measurement data reporting can be based on default Nokia Siemens Networks
formats or a format customized by the operator.
The Flexi Multiradio BTS LTE can be managed on two different levels:
• on single site level by the BTS Site Manager (BTSSM) comprising both the manage-
ment for the radio part and the transmission part for a single Flexi Multiradio BTS
LTE. The BTSSM provides FCAPS functionality required for local element manage-
ment. The BTSSM is a Java application running on Windows (XP, Vista) or Linux PC
installed either on a PC/Notebook - named Local Maintenance Terminal (LMT) for
site local usage and/or on a NetAct ™ GUI Server for remote access to a Flexi Mul-
tiradio BTS LTE.
• on regional and national level by the NetAct ™ Operations Support framework.
The NetAct ™ OSS framework provides both the capability to act as the Element Man-
agement System (EMS) / Domain Manager (DM) for a certain number of Flexi Multiradio
BTS LTEs and the capability to be configured as a Network Management System (NMS)
for the whole network (access, core, transport,..) on regional and national levels (with
the help of several underlying EMS).
An integrated Operation Mediation System (iOMS) mediates between the transport opti-
mized multiple Flexi Multiradio BTS LTE management interfaces and the CORBA NW3I
Management Interface used by several NetAct ™ Applications. In addition iOMS
supports the FCAPS applications with concentration and aggregation functions for SW
distribution and PM data collection.
The interface between the Flexi Multiradio Base Station and iOMS is based on the
BTSOM protocol. It carries all the necessary data and commands (for example, alarms,
measurements, configuration and new software data) to control the network element
behavior remotely.
Id:0900d805806f2b93 67
Operability LTE RAN system description
Examples of functionality provided by NetAct ™ for LTE:

• graphical topology presentation
• basic administration, time management and access to local node/element
managers
• centralized software management
• alarm data and measurement data collection and storing
• alarm filtering and reclassification, modifiable alarm manual
• performance management tools and administration of measurements
• network configuration visualization
• current radio network configuration as well as planned configuration of the radio
network can be viewed, searched and modified
• exporting actual configuration to an external tool and importing plans from external
tools
• plan provisioning, plan and template management, operations scheduling
• uploading radio network configuration from Flexi Multiradio BTS and core network
into a NetAct ™ database
• plan actual compare - for reviewing changes what is expected when plan is provi-
sioned to the network or for verifying that planned changes were implemented cor-
rectly to the network
• site configuration tool - for providing an easy-to-access storage for Flexi Multiradio
BTS site configuration files and other commissioning data. The application supports
network rollout by enabling effective commissioning of Flexi Multiradio BTS.
All O&M services are managed by using a Graphical User Interface (GUI), either via
local access or from a remote location. GUIs are provided by
• NetAct ™ OSS framework
• BTS Site Manager (BTSSM)
7.2 BTS Site Manager

The BTS Site Manager (BTSSM) is the Element Manager for a single Flexi Multiradio
BTS LTE, featuring a single SW application used for managing one or more network
elements in the BTS site. As illustrated in Figure 40 the application integrates Transmis-
sion and BTS Management to one site level management tool.
68 Id:0900d805806f2b93
NetAct User Workstations Web User

Tier-1 Interface
NetAct
System BTS Site Manager
Application
Java Application Topology
Tier-2 Launcher
(J2AA)
Tier-3 Persistency Services
XML
over HTTPS Local Maintenance Terminal /
local connected Notebook
BTS Site Manager Web User

Java Application Interface
Figure 40 Functional overview of the BTS Site Manager

The BTS Management provides all the SW functionality needed to manage, configure
and monitor the Flexi Multiradio BTS LTE.The TRS Management provides all the SW
functionality to manage, configure and monitor the transmission configurations between
the Flexi Multiradio BTS LTE and other BTSs and the peer core and management
nodes.
Basic Node Manager functionality

Node Managers are Java-based applications built for multi platform usage supporting
both Windows and Linux platforms. Node Managers are used for performing configura-
tions and O&M tasks on network elements. Designed for use in both local and remote
management, the basic functionality of all Node Managers is the same and includes the
following:
• commissioning network elements
• taking units/configurations into use
• turning interfaces on/off
• turning channels on/off
• setting the synchronization sources
• activating and deactivating loops for testing purposes
• troubleshooting alarms
Id:0900d805806f2b93 69
BTS Site Manager launch

The BTSSM can be launched in different ways:
• at local site hosted on a Local Maintenance Terminal/Notebook connected to the
Flexi Multiradio BTS
• remotely via Node Managers from NetAct ™
Local host requirements

• Windows 2000, XP, Windows Server 2003 or Linux (RedHat Enterprise)
• recommended processor speed 800 MHz or more
• recommended memory 512 Mbyte or more
• recommended hard disk space 260 Mbyte
• 1024x768 display resolution for optimum viewing
• mouse or trackball for best user interface interaction
• Ethernet connection (10/100/1000 Mbit/s Ethernet card)
• communication cable (10/100/1000 Base-T Ethernet cable with an RJ-45 connector)
• CD-ROM (optional)
• printer (optional)
Basic BTS Site Manager functionality

The BTSSM supports the following basic functionality (see also Table 7 BTS Site
Manager local and remote functionality):
• integration and commissioning of BTS and TRS
• supervision of BTS (alarm and performance monitoring, system diagnostics)
• transmission management (alarm and performance monitoring)
• maintenance of BTS (SW upgrades, BTS site parameters modification)
• testing and monitoring of LTE BTS and TRS
70 Id:0900d805806f2b93
Manager Functionality Local Remote

File based commissioning x x
Manual site commissioning x x
Detailed Site Information retrieval x x
Site Configuration Planning File (SCF) creation x x
System Snapshot creation /saving & analysis x x
Trace Logging x x
User and Access Control Management x x
SW Update, Download and Management x x
Performance Monitoring x x
Alarm Management x x
NetAct ™ Launch and Integration N/A x
License Management x x
Table 7 BTS Site Manager local and remote functionality
7.3 Flexi Multiradio BTS LTE management functions

Flexi Multiradio BTS LTE management comprises the following fuctions which are
described in the following sections in more detail:
• Fault management
• Configuration management
• Software management
• Performance management
• Hardware/inventory management
• Feature/license management
• User account management
• User event log management
7.3.1 Fault management

Alarms are reported to the management systems, including the cause of the service
loss. The alarms themselves are supplemented with the alarm manual pages to
describe the conditions in more details. The fault detection also leads if needed to auto-
matic recovery actions. The Flexi Multiradio BTS alarm system gathers alarm reports
from the application software in the Flexi Multiradio BTS and reports them to the NetAct
™. On NetAct ™ a graphical user interface provides a view for active alarms and accord-
ing reports as well as an alarm history and enables the operator to modify Alarm param-
eters.
Fault management comprises the following functions:
• General alarm management functions
• Alarm severity change in BTS
• Alarm management for transport modules
Id:0900d805806f2b93 71
• Alarm management for antenna line management
General alarm management functions

The complete functionality of the Flexi Multiradio BTS LTE is supervised via alarms. The
Flexi Multiradio BTS LTE detects faults, localizes them, generates Failure Event
Reports (FER) and sends them to NetAct ™. Also via the BTSSM the alarms can be
managed locally for a single Flexi Multiradio BTS LTE. The alarm is generated immedi-
ately when a fault situation occurs, and includes the cause of the service loss. The
alarms are supplemented with the alarm manual pages to describe the conditions in
more details.
On NetAct ™ a graphical user interface provides a view for active alarms and associated
reports as well as an alarm history, and enables the operator to modify alarm parame-
ters like alarm severity. The report gives details on how the fault affects the services of
logical objects in the network and, if available, the physical unit that caused the service
loss. The report contains also the alarm number which is an entry to the alarm reference
manual, and an alarm text which explains shortly the fault and gives information on the
severity level and time.
The alarm is generated immediately when a fault situation occurs. The alarm information
is assembled according to ITU X.733 and 3GPP TS 32.111 and comprises:
• alarm type (for example, communications alarm, resource shortage, equipment
alarm, quality of service alarm, etc.)
• emitting object
• severity (critical, major, minor)
• probable cause
• specific problem
• notification ID
• alarm time
• additional text
This information is valuable to the operator to track down the source of the alarm and
eliminate the trouble. To cope with the strong demand of operators that alarms shall
contain information about the necessary maintenance measures resulting from an
alarm, or that this maintenance information can be retrieved offline (e.g. by means of the
probable cause), Flexi Multiradio BTS LTE provides this maintenance information wher-
eever possible.
Within the Flexi Multiradio BTS LTE it is possible to filter alarms based on criteria like
alarm type, emitting object and perceived severity. Filtered alarms are not forwarded
towards the NetAct ™ monitoring system.
The Flexi Multiradio BTS LTE can identify each generated alarm and has mechanisms
to keep track of the state of individual faults. It knows the active alarm situation and what
the current faults and related alarms are. The severity level classifies the alarms accord-
ing to their priorities and effects on services. The assignments of severity levels within
the Flexi Multiradio BTS LTE are fixed and cannot be modified from NetAct ™ or BTS
Site Manager. Critical alarms require immediate actions by the maintenance personnel;
all other alarms require actions during working hours. The handling of alarms is carried
out at different levels of the alarm system to simplify the pre-processing of the fault
observations and to reduce the load on the whole alarm system.
72 Id:0900d805806f2b93
Alarms with severity "warning" are not treated as permanent faults. Hence these alarms
are not stored as active alarms in the Flexi Multiradio BTS LTE and are also not aligned
to NetAct ™ when an alarm alignment is requested by the Management System.
The Flexi Multiradio BTS LTE maintains the currently active alarms. It sends these
alarms to the NetAct ™ on request, independent of autonomous alarm reporting. (Defi-
nition of Active Alarm: An alarm event reported for a faulty condition with the severity
minor, major or critical, which has not been already cleared by the Flexi Multiradio BTS).
As soon as a fault condition is not active any more, the Flexi Multiradio BTS sends a
clearing alarm notification. Exceptions for automatic alarm clearing are security alarms,
this kind of alarms needs to be cleared by the operator personnel even if the fault con-
dition no longer exists. The emitted alarm clearing notification unambiguously identifies
the corresponding original alarm(s).
After a Flexi Multiradio BTS LTE restart the alarm situation is verified and only alarms
still active are reported, all others are automatically cleared.
The generation of more than one alarm per fault, that is, the generation of induced
alarms, is avoided. However, exceptions may appear in the following two cases:
• alarming of key services with high importance for the operator
• the primary fault is outside the scope of the NE and the current NE has no knowl-
edge about it
An example for a key service is a cell that - as a consequence to some board failures -
goes out of service. An alarm is generated for the board failure, and induced alarms are
generated for the affected cells. Each alarm has a unique notification identifier.
The suppression of toggling alarms is supported. The configurable toggling conditions
can be browsed, added and modified via BTSSM or NetAct ™.
Alarm severity change in BTS

The Flexi Multiradio BTS LTE can determine and change the severity level by operator
command in the Flexi Multiradio BTS LTE (minor, major, and critical). The severity level
classifies the alarms according to their priorities and effects on services. Critical alarms
require immediate actions by the maintenance personnel; all other alarms require
actions during working hours. The handling of the alarms is carried out at different levels
of the alarm system to simplify the pre-processing of the fault observations and to
reduce the load on the whole alarm system.
Alarms with severity "warning" are not treated as permanent faults. Hence these alarms
are not stored as active alarms in the Flexi Multiradio BTS LTE and are also not aligned
to NetAct ™ when an alarm alignment is requested by the Management System.
Alarm management for transport modules

The transport module alarms are collected in the Flexi Multiradio BTS alarm system and
reported to the management system as radio Flexi Multiradio BTS LTE alarms. The
transport module alarms are also included in the Flexi Multiradio BTS LTE alarm upload.
Alarm management for antenna line management

Fault Management also supports Antenna Line Management by including VSWR alarm-
ing.
Id:0900d805806f2b93 73
7.3.2 Configuration management

Planning Tools provide the site configuration, the radio configuration and the transmis-
sion configuration data for the Flexi Multiradio BTS LTE. These configurations are down-
loaded, stored and activated to single Flexi Multiradio BTS LTE via NetAct ™ or BTSSM.
In addition, management of states and features is provided.
Configuration management comprises the following functions:
• Configuration handling
• Direct changes with send to network functionality
• Direct parameter operations on transport configurations
• Consistency checks
• Feature management
• State management
• Performance Counter Group Management / Administration of Measurements
• Plan file data up/download
• Configuration data backup and synchronization
• SON initiated configurations
Configuration handling
The BTS site configuration plan (SCF) portion, radio network (RNW) portion, perfor-
mance counter group plan portion (PCG) and transmission (TRS) plan portion were
usually generated by off-line planning. The plans contain the attribute values for
managed HW and SW objects of the Flexi Multiradio BTS.
The Nokia Siemens Networks solution for LTE Configuration Management (CM) is
based on the NetAct ™ Configurator application. It comprises a CM Editor, a CM Oper-
ations Manager and a CM Analyzer. The NetAct ™ Configurator application is used to
manipulate parameters and to export/import parameter data. It can check validity of
neighbor related parameters between cells and nodes automatically. The NetAct ™
Configurator application outputs plan portions in XML format (RAML2.1 or newer) and
distributes them to the Flexi Multiradio BTS within a single file. The CM function in the
Flexi Multiradio BTS downloads the file and saves the configuration information to its
flash memory.
All of the radio, transmission, antenna and general parameters are included in this plan
of managing parameters. If no NetAct ™ is available/reachable then the provisioning of
all the plan portions can be done via the BTS Site Manager locally from the LMT's file
storage. In addition the BTS Site Manager provides a GUI for creating, editing, verifying
and storing all types of plan file portions either on-line when connected to a Flexi Multi-
radio BTS or off-line.
The NetAct ™ Configurator application offers means to import the configuration data
from other planning tools or from a Flexi Multiradio BTS itself. If needed, configuration
data can be modified and sent to the Flexi Multiradio BTS within a single plan file. If the
configuration data was uploaded before and then modified, only the modified objects are
sent to the Flexi Multiradio BTS as delta file.
Updated or new BTS site configurations, radio and transmission plan portions are
merged into one file after editing or creation and downloaded to the Flexi Multiradio BTS.
There the BTS site configuration plan, radio plan and transmission plan portion data is
separated again, checked and activated via NetAct ™. If the data is consistent and fits
to the available hardware it is distributed to the internal databases. Otherwise the Flexi
Multiradio BTS issues an alarm and continues with the old configuration.
74 Id:0900d805806f2b93
After downloading a new configuration, it can be activated separately via a single

command.
A Flexi Multiradio BTS restart will be applied dependent on modified data but as far as
possible, activation is attempted without interruption. When the operator activates the
plans, the Flexi Multiradio BTS checks whether the changed parameters (for example
parameters which impact HW behavior, like frequency band modifications) require a
restart of modules or not.
If restarts are required then traffic downtime caused by the configuration updating is kept
to a minimum. If a plan update comes along with HW expansions (module) then this is
possible without noticeable service interruption under normal conditions, for example,
stable connections are maintained and new connections are processed.
Direct changes with send to network functionality

With the NetAct ™ Configurator Application the operator is able to modify only few or
even one single parameter. With a single user interaction the update is sent to the Flexi
Multiradio BTS as a short delta file followed by the activation command. If the consis-
tency checks are passed successfully, the parameter(s) go into service without any acti-
vation procedure triggered by the operator.
Direct parameter operations on transport configurations

With the BTS Site Manager the operator is able to modify dedicated transport parame-
ters. The BTS Site Manager performs all consistency checks and if they are passed suc-
cessfully, the parameter(s) go into service without any additional activation procedure
triggered by the operator. The transfer to the Flexi Multiradio BTS happens via com-
mand/respond messages instead of a file transfer.
Consistency checks
Basic consistency check mechanisms to inhibit invalid configurations of database are
performed on NetAct ™ level as an integrated part of the NetAct ™ Configurator appli-
cation. In addition the operator may use the optional consistency packages add-on
available for the NetAct ™ Configurator application to configure more complex checks
(for example, checking of parameter and feature dependencies). On the Flexi Multiradio
BTS side, HW capability, parameter ranges and consistency between parameters are
checked before a plan is activated. If one of the checks fails, the plan file is rejected.
Feature management
Before a feature (SW or capacity) is activated, the Flexi Multiradio BTS requires that it
is explicitly enabled within the configuration database. Via the Configuration Manage-
ment the status of the features can be managed within the respective BTS Site Config-
uration plan portion, the Radio Network plan portion and the Transmission plan portion.
Each Feature is unambiguously identified by a feature code which correlates with the
dependent feature license. This enables the Flexi Multiradio BTS to request missing
licenses, allowing the NetAct ™ License Manager to assemble the desired licenses cor-
rectly.
With a switch in the configuration data base controlling the automated license assign-
ment, the operator may choose between manual or operator controlled license file
download, or the automatic license assignment function, or the autonomous license file
creation and download.
for SW related features, the status of a feature is either "Enabled" or "Disabled" and for
capacity related features a distinct capacity value is given.
Id:0900d805806f2b93 75
A feature can be used by the Flexi Multiradio BTS as soon as the appropriate license is
available (with the exception of the license free period). The feature may be enabled
from NetAct ™ or BTS Site Manager either immediately or sometime later.
When a SW feature is configured to "Enabled" and its related license file is not available,
the Flexi Multiradio BTS requests licence delivery from the NetAct ™ License Manager,
and the feature is temporarily activated until the license free period expires.
When a feature is successfully activated, a notification is automatically sent to NetAct ™
for updating the network wide view of activated features. A feature is automatically de-
activated if the license is deleted or expires, and an alarm is issued towards NetAct ™.
A feature activation or deactivation usually does not require a restart of the Flexi Multi-
radio BTS.
State management
For a set of its managed objects, the Flexi Multiradio BTS maintains state and status
attributes. Such managed objects are the "eNB" Object and the "Cell" objects. State
changes on these externally visible objects are reported by the Flexi Multiradio BTS to
NetAct ™.
The state handling in NetAct ™ follows ITU-T X.731 and 3GPP TS 32.111.
Administrative states (AST) are reset-safe. For example a locked cell will not be acti-
vated during a Flexi Multiradio BTS restart if the usage of the cell is administratively pro-
hibited. Transitional state changes taking only a few seconds are not reported. Locally
the Flexi Multiradio BTS can initiate operational state information changes for network
object due to Flexi Multiradio BTS faults and recovery actions.
Independent of this autonomous reporting of state changes, the Flexi Multiradio BTS
can send the state attributes of a Managed Object Instance (MOI) to NetAct ™ on
request. Additionally, an alignment of Flexi Multiradio BTS states to NetAct ™ is initiated
after a recognized interruption and re-establishment of the OAM-link.
Performance Counter Group Management / Administration of Measurements

Groups of counters are activated / deactivated within a Flexi Multimode BTS with the
help of the performance counter group plan portion. Only counters belonging to acti-
vated groups are reported to NetAct ™ or to the BTS Site Manager.
g If some counters within a counter group belong to a feature which needs a dedicated
license then these counters are only reported if the feature is licensed and enabled.
Plan file data up/download

The RNW and TRS plan portion and SCF portion are provided in RAML 2.1 format for
download and upload. This bulk data file transfer has no impact on the service quality
and does not degrade the services of operating Flexi Multiradio BTS.
Configuration data backup and synchronization

The actual CM configuration can be uploaded on demand into a NetAct ™ data base,
for example to store a security backup or to serve as an actual input for NetAct ™ to
generate a new plan file. The backup interval can be varied between the sites and site
BTS types as needed.
If local configuration modifications were done by the BTS Site Manager, the Flexi Multi-
radio BTS sends a notification to NetAct ™ to inform the operator about the demand to
upload the new configuration into the NetAct ™ database.
76 Id:0900d805806f2b93
SON initiated configurations

Initiated by Self Organizing Network functions, several attributes values may be
modified by the Flexi Multiradio BTS itself, and even new objects may be created on
BTS level autonomously. Such changes are notified to NetAct ™.
7.3.3 Software management

The SW Management provided by NetAct ™ SW Management Services or by the BTS
Site Manager consists of software management functions focused to the Flexi Multiradio
BTS. Those functions are downloading SW builds, activating SW builds and uploading
SW configurations. Several downloads and uploads may run in parallel for multiple Flexi
Multiradio BTSs. A SW build consists of several files. Also Change Deliveries are
handled as builds consisting of one or more files which update the impacted SW seg-
ments.
When a SW build is downloaded it can be activated immediately, or later by a dedicated
activation request. The SW configuration upload function is used to keep the NetAct ™
back-up database up-to-date.
Software management comprises the following functions:
• SW download/update procedure
• SW file download
• SW fallback/rollback possibility
• SW download progress indicator/supervision
• SW activation
• SW inventory/change notification
• Combined SW management for the Flexi Multiradio BTS modules and antenna line
devices
• Software integrity protection
SW download/update procedure
The possibility to download and activate new software generations from remote NetAct
™ as well as from the BTSSM is provided. SW Update is done by delivering SW builds,
by replacing one or more single files or through the installation of the whole SW system.
If a new version is available, NetAct ™ notifies the Flexi Multiradio BTS and the Flexi
Multiradio BTS downloads a build descriptor file (XML) including file descriptions, file
versions, HW units, and the address of the SW File Server. The Flexi Multiradio BTS
makes a cross-check and downloads only the missing files from the SW file server to
the Flexi Multiradio BTS. During and after downloading the SW is marked as “pas-
sive/not in use” in non-volatile memory accessible through a file system.
SW file download
NetAct ™ can handle multiple SW downloads to groups of Flexi Multiradio BTS, and the
operator can control the amount of ongoing SW mass download operations. The SW is
delivered as zipped files. After reception, each file is unpacked and distributed to the
correct directories, followed by the verification of the SW build by an integrity check.
SW fallback/rollback possibility
After commissioning and a subsequent SW update, there are two SW versions present
in the Flexi Multiradio BTS. Each of them can be in use / activated. The Flexi Multiradio
BTS is usually controlling which SW version is in use but in addition, the selection can
Id:0900d805806f2b93 77
be done manually from NetAct ™ or BTSSM. If a new package is not working properly
after activation then the Flexi Multiradio BTS raises an alarm and continues with the
previous SW version by putting it again into active state.
SW download progress indicator/supervision

The Progress Indicator eases operator work for SW download mass operations. While
such mass operations may need some time, it is important that the user triggering the
operation can verify that the operation has been properly started, and find out what the
estimated elapsed/time left for the download is.
The information of the progress per Flexi Multiradio BTS is collected from the Flexi Mul-
tiradio BTS and the real situation with estimates of the time left is shown in the NetAct
™ SW Manager application.
With a requirement of 512 kbit/s minimum throughput for O&M links, examples for the
SW download time are as follows:
• 5 MB + 15% overhead = 46 Mbit
512 kbit/s minimum throughput -> approx. 1.5 min
• 40 MB + 15% overhead = 368 Mbit
512 kbit/s minimum throughput -> approx. 12 min
In practice (1Mbit/s) SW download times would be even halved.
SW activation
If the SW files are verified successfully, the activation of the new SW can either be done
automatically by the Flexi Multiradio BTS itself or by a separate NetAct ™ command
afterwards. The activation of SW by the Flexi Multiradio BTS on request is possible from
NetAct ™ in a scheduled way, for example, during night time. As soon as the new SW
is in service, the Flexi Multiradio BTS sends a notification to NetAct ™.
With activation of the SW currently in passive state the actual running SW is set to
passive state. The activation of the SW build may require a reset of the Flexi Multiradio
BTS. In this case the Flexi Multiradio BTS resources are cleared in a controlled way
when a new Flexi Multiradio BTS SW is activated.
SW inventory/change notification
The Flexi Multiradio BTS sends a notification message to NetAct ™ after restart or when
it activates a new SW build. The message includes SW version information. This SW
Change Notification is used to inform NetAct ™ for keeping SW registers and backups
up-to-date, for example when SW modifications are done via the BTS Site Manager.
NetAct ™ may upload the notified SW build into its backup storage. It is also possible to
obtain a current view of Flexi Multiradio BTS SW build version and the versions of
installed SW objects on request via NetAct ™.
Combined SW management for the Flexi Multiradio BTS modules and antenna
line devices
The SW management functionality of the Flexi Multiradio BTS handles all SW compo-
nents for the System-, RF-, Transport Module and 3rd party modules within a single
process.
Software integrity protection

Integrity protection of the Flexi Multiradio BTS software provides assurance that the SW
was not corrupted on its way from the SW repository to the Flexi Multiradio BTS. The
Software integrity verification is done by calculating a checksum (Adler32 checksum
78 Id:0900d805806f2b93
algorithm) for each file during SW packet creation. The Flexi Multiradio BTS verifies the
checksum when a new SW file is downloaded. If the verification fails, the Flexi Multiradio
BTS sends an alarm to NetAct ™, and discards the SW file.
7.3.4 Performance management

The Radio Network Performance Management provides the operator with continuous
up-to-date information, enabling them to maintain a high standard of network operability
for their customers. With Threshold Based PM Alarming it makes it easier to detect
faults, identify bottlenecks, and optimize the network. Flexible KPIs provide a quick view
about the actual network performance.
The Performance management architecture is illustrated in Figure 41.
Data
Export
NetAct Data
NetAct Processing Network
Tools Storage
Mediation
Function
BTS Site
Manager Measurement Data Collection
Adminstration Interfaces
Administration
Data Flow
Data Producer Data Producer
Figure 41 Performance management architecture

Performance management comprises the following functions:
• Radio network monitoring statistics
• KPI calculations
• PM data transfer and supervision by NetAct ™
• PM counter licenses
• Performance data file formats
Id:0900d805806f2b93 79
Radio network monitoring statistics

The Radio Network Monitoring Statistics provide operators with continuous up-to-date
information, enabling them to maintain a high standard of network operability for their
customers.
This feature consists of the following operability aspects:
• measurement management via NetAct ™ measurements application
• collecting and storing the measurement data in the Flexi Multiradio BTS
• storing the measurement data to a NetAct ™ management database for viewing the
data
• display of counters and KPI values calculated by NetAct ™ performance application
NetAct ™ can collect measurement data from all correlated Flexi Multiradio BTSs. When
the Flexi Multiradio BTS sends notification about PM data files ready for transport,
NetAct ™ fetches the files and stores them in a data base.
KPI calculations
As NetAct ™ provides means to calculate Key Performance Indicators (KPIs), network
performance can be evaluated based on KPIs, which present vital information regarding
the network.
KPIs are either represented by an individual counter or calculated from a combination
of several counters, for well defined radio and transport KPIs. They are variably defin-
able with KPI formulas on NetAct ™ level. KPI formulas for NetAct ™ can be browsed,
added and updated and calculated KPIs can be viewed like any other PM counter value.
PM data transfer and supervision by NetAct ™

The PM counter file upload to NetAct ™ or the BTS Site Manager is done via file based
interface and the bulk data file transfer has no impact on the service quality and does
not degrade the services of operating Flexi Multiradio BTS.
There are various built-in mechanisms for problem recovery, so the alarms are only gen-
erated for situations that:
• result in loss of data
• require explicit action for resolution
• indicate a problem in performance of measurement data processing or transfer
These PM related alarms are only intended to cover the PM specific aspect of the data
pipe. There are separate mechanisms to detect, for example, general problems with
DCN connections.
PM data reliability is important for reporting and managing the network. A clear indica-
tion is given if data for some measurements, intervals or measured objects is lost. In
normal operation no data is lost between Flexi Multiradio BTS and NetAct ™. Temporary
malfunctions in SW or temporary loss of backhaul connectivity are handled by means
such as buffering/retransmission. However it may happen that a restart of the Flexi Mul-
tiradio BTS will lose the PM data that was not yet transferred, due to unavailability of
suitable non-volatile data storage.
Administration of measurements
Groups of counters are activated/deactivated within a Flexi Multiradio BTS with NetAct
™ tools. Only counters belonging to activated groups are reported to NetAct ™ or to the
BTS Site Manager.
80 Id:0900d805806f2b93
g If some counters within a counter group belong to a feature which needs a dedicated
license then these counters are only reported if the feature is licensed and enabled.
In the initial release, the reporting interval for the upload towards NetAct ™ is set to 60
minutes. When the reporting interval has expired, a notification is sent to NetAct ™ indi-
cating that one or more PM files are ready for transfer. The reporting intervals are closely
following the measurement interval timing, that is, they are delayed by the time needed
to compress the previously closed file.
PM counter licenses
PM counters are license based on counter categories. There are 3 granularities for
licensing:
• Counter Category "Basic Counter Package"
No separate license is needed because the counters belong to the basic feature
package of a Flexi Multiradio BTS.
• Counter Category "Feature Counter Package"
Counters belong to a Telecom or Transmission feature. Here a corresponding
feature license is needed, or a dedicated counter license is needed (enhanced
counter license). When a feature is licensed and enabled, the related counters are
licensed automatically (indirectly via the feature).
• Enhanced counter packages which are not part of one of the Feature Counter Pack-
ages.
Such a package needs an own license and is enabled by a related feature enabling
flag in the configuration data base.
g Counters for non-licensed features are not reported if they do not belong to the basic
counter package. Also if the counters are not activated by NetAct ™ AoM, no mea-
surements are collected.
Performance data file formats

The Flexi Multiradio BTS delivers the files in Omes XML format. NetAct ™ can generate
the performance data in XML schema based format (3GPP TS 32.435) and supports as
default the Nokia Siemens Networks "Measurement Data Export" (MDE) export inter-
face based on Omes XML which is the mostly used NetAct ™ export format. In case of
3GPP schema export, NetAct ™ follows the file naming convention for the result files
according to 3GPP TS 32.432.
7.3.5 Hardware/inventory management

The Hardware Management of the Flexi Multiradio BTS consists of an automatic HW
detection and notification/upload function to NetAct ™ or the NetAct ™ Hardware
Browser.
Hardware/inventory management comprises the following functions:
• HW installation and configuration
• Inventory management
HW installation and configuration

HW components are automatically detected and tested when the system is starting up
or when a new component is plugged in. HW management is done by using the BTSSM
either locally or from a remote site. HW installation has been made as automated as
possible in order to avoid user interaction. The HW management system keeps the Flexi
Id:0900d805806f2b93 81
Multiradio BTS HW configuration information up-to-date and provides the Flexi Multira-
dio BTS with the appropriate configuration parameters. The Flexi Transport Module
(FTM) HW configuration information is stored in the Flexi Multiradio BTS as part of the
BTS HW inventory.
Inventory management
The Flexi Multiradio BTS automatically detects its installed and commissioned active
hardware, and generates a remote inventory data file. Changes of active hardware
(replacement) is detected and notified to NetAct ™. NetAct ™ then automatically
uploads the Inventory Data File and stores it for further processing by an Inventory Appli-
cation. It is also possible to initiate the IDF upload on demand from NetAct ™ side.
Passive Hardware is maintained manually via list entries. The Flexi Transport Module
(FTM) HW information is reported to NetAct ™ HW inventory with the same mechanism
as issued for other Flexi Multiradio BTS HW.
With the BTSSM the operator / service personnel can insert entries for passive units into
the IDF, and at any time enerate a new complete IDF by command. Service personnel
will use the BTSSM for local maintenance tasks such as hardware replacement, and will
trigger an IDF update after completion of the task. In this way NetAct ™ is instantly
notified when hardware has been changed.
82 Id:0900d805806f2b93
7.3.6 Feature/license management

Flexi Multiradio BTS license management for application software features from NetAct
™ service applications enables simultaneous distribution of licenses towards the access
network. The Flexi Multiradio BTS determines the needed licenses automatically when
a feature is activated.
Feature Management is enabled by the SW licenses that bind Flexi Multiradio BTS func-
tional features, for example hardware capacity, to a customer license. System function-
ality changes or capacity upgrades can then be done remotely by updating the license
keys. To license a feature, a license file from Nokia Siemens Networks is required before
it can be used.
Licenses are applied to:
• SW features like telecom enhancements related to the control and user plane of the
system
• capacity enhancements, for example number of active users, data throughput
• performance monitoring, for example specific counter support
To get a license, the operator orders the desired feature (sale item) from the Nokia
Siemens Networks Product Information Center (PIC) where license files are created by
the License Generator (LG). The licenses for the sales items are delivered and installed
in the NetAct ™ centralized License Management application. These license files may
contain a huge number of licenses (license pool) that can be distributed freely by the
operator to the Flexi Multiradio BTS, that is, these licenses do not contain site-specific
information.
The license generation process comprises:
• ceation and delivery of license authorization codes (part of order)
• creation, storage and delivery of licenses
The main functions of the NetAct ™ License Manager are:
• importing licenses into the pool and to NetAct ™ license archives
• assembling license files, on request of a Flexi Multiradio BTS in real time
• assembling license files manually, for example if a license was accidentally deleted
• distributing license files to Flexi Multiradio BTS, either automatically subsequent to
a Flexi Multiradio BTS license request or manually triggered
• deleting licenses
• license reporting and information bookkeeping, for example for monitoring the avail-
able number of licenses per feature and for notifying the operator in case of shortage
Assembled license files can also be downloaded to the Flexi Multiradio BTS from the
BTS Site Manager, for example during local commissioning.
The following feature/license management topics are described in more detail below:
• Automatic license assignment
• Feature status / feature activation
• License types
• License free period
• Pool licenses
• Synchronization of license information in NetAct ™
• Deletion of licenses
• Scope of licenses for Flexi Multiradio BTS
• License handling case of HW failure or HW exchange
Id:0900d805806f2b93 83
• Pool substitute process
Automatic license assignment

The automatic license assignment is a complementary way to the manual assignment
and eases the license management significantly.
By means of a switch in the configuration data base controlling the automated license
assignment, the operator may choose between:
• manual or operator-controlled license file download
• automatic license assignment function or autonomous license file creation and
download
The license requests are triggered by enabled features. For each sales feature license,
there is an entry in the configuration data base.
When the Flexi Multiradio BTS receives a new configuration file, it checks which features
are enabled, and whether the related licenses are already available. For missing
licenses, the Flexi Multiradio BTS requests license delivery from the NetAct ™ License
Manager. The License Management application assembles the missing site specific
licenses, or takes a license file from the pool, and sends the file to the target Flexi Mul-
tiradio BTS were the features can now be finally activated.
g As long as the licenses are not available, the features are temporarily activated until
the license-free period expires.
Feature status / feature activation

Before a feature can be activated, the Flexi Multiradio BTS requires that the (SW or
capacity) feature is explicitly enabled within the configuration data bases. The status of
the features can be managed via Configuration Management.
The status of a feature is either "Enabled" or "Disabled", and for capacity related
features a distinct capacity limit is given. Each feature is unambiguously identified by a
feature code which correlates with the dependent feature license. This enables the Flexi
Multiradio BTS to request missing licenses, and allows the NetAct ™ License Manager
to assemble the desired licenses correctly.
License types
There are "On/Off type" licenses (use of a feature is allowed or not) or "value" licenses
(for example, capacity). Some features with capacity license may have basic capacity
that is available without any license. Capacity expansion is done by installing another
capacity license into the element. Capacity is expanded incrementally, that is, previous
license files are still valid and the capacity values are summed up. If a capacity based
license exceeds the installed HW capability, an alarm is issued.
License free period

The Flexi Multiradio BTS is delivered from factory without any licenses. During commis-
sioning it cannot be ensured that all/any licenses are available. In this situation, all acti-
vated features can be used for a 14 days license free period. Capacity based licenses
are set to maximum capacity. If all or some of the missing license files are not received
within the license free period, the related features are disabled automatically. In addition
an alarm is sent towards NetAct ™. The same procedure is applied to features which
are activated later on via a plan file update.
84 Id:0900d805806f2b93
Pool licenses
In LTE, only pool licenses are applied, and no NE based licenses are supported. Oper-
ators can for example buy a pool of a certain license and assign each license to a Flexi
Multiradio BTS of their choice. The NetAct ™ License Manager is used to assign
licenses from the pool to specific Flexi Multiradio BTS by creating the proper license
files. The licenses are “non-floating” which means that the Flexi Multiradio BTS does not
return licences when any of its enabled features are switched off sometime later.
g A pool license is limited to a regional NetAct ™ area, that is, for covering a multi-
regional network a common pool license needs to be portioned into one pool license
per regional NetAct ™ cluster.
Synchronization of license information in NetAct ™

The synchronize operation keeps the NetAct ™ license database up-to-date. If some
license management operations have been done by the BTS Site Manager, the syn-
chronization operation is normally needed to update the NetAct ™ license database
accordingly. Synchronization may also be needed after some other operational proce-
dures, such as network element re-hosting.
With every license acceptance or deletion, the Flexi Multiradio BTS sends a notification
to NetAct ™ to trigger an on-demand upload of the status file (XML-file).
Deletion of licenses
Expired, corrupted, and irrelevant or even active license files can be removed from the
Flexi Multiradio BTS if desired. The license files are deleted only from the Flexi Multira-
dio BTS but they remain in the NetAct ™ license archive.
g If the operator manually deletes licenses within a Flexi Multiradio BTS, the related
features must be disabled too by the operator. Otherwise the licenses will be
requested again if the automated license request mode is enabled.
Scope of licenses for Flexi Multiradio BTS

The smallest granularity of a license validity scope is the Flexi Multiradio BTS and not
on parented cell level. Capacity based licenses are treated in a cumulative way: the
limits are controlled by aggregating the corresponding values from all parented cells.
License handling case of HW failure or HW exchange

A license file is identified by its Target-ID. A Target-ID of a license file for the Flexi Mul-
tiradio BTS is identical with the Node-ID given to the Flexi Multiradio BTS and not to any
HW-ID or serial number of a Flexi module.
The following cases are handled:
• Licenses lost within a broken unit:
If a System Module with stored license files needs to be swapped, then copies of the
old license files need to be distributed to the Flexi Multiradio BTS again. After the
new equipment has been exchanged, the NetAct ™ operator issues a Flexi Multira-
dio BTS license synchronization command or the BTS automatically requests the
licenses.
• BTS LTE site is removed from Access Network:
In this case the Target-ID is not longer in use and the linked licenses are not needed
anymore, and can be released back to the pool by using the pool substitute process.
There should always be license pools available, so that new licenses can be deliv-
Id:0900d805806f2b93 85
ered to the Flexi Multiradio BTS as soon as a new BTS LTE site has been planned
and the BTS is installed.
Pool substitute process

By means of the pool substitute process, the license files tied to a Target-ID that is
unused or no longer needed can be released back to the pool for further use. Depending
on the available pool size, this process is required only once a week or even only once
a month.
The pool substitute process includes the following steps:
1. The request to substitute licenses related to a removed site is recorded (including a
reason code) to the NetAct ™ License Manager.
2. A pool substitute request file is generated using the NetAct ™ Network License
Manager.
3. The substitute request file is send to Nokia Siemens Networks.
4. Nokia Siemens Networks sends back the pool substitute permission file.
5. The pool substitute permission file is imported to the NetAct ™ Cluster in question.
6. Licenses related to the removed site are released back to the pool.
7.3.7 User account management

This feature enables the centralized user account management for the Flexi Multiradio
BTS from NetAct ™ together with the Remote User Information Management applica-
tion (RUIM) application. It also provides a mass updating function of local user pass-
words.
The system administrator can manage the access to the Flexi Multiradio BTS with a cen-
tralized authentication and authorization server in NetAct ™. In the login phase, the
network checks the user access rights from an LDAP server which provides the authen-
tication and authorization information. The access rights can be managed separately for
each group or individual of the maintenance personnel. In the User Information Manage-
ment system, the operator can define different access classes for different user groups
and network elements. User account management enables also the possibility for
logging the user actions in the NW with the same user ID (per user) in each NW entity
(the LTE667: User Event Log Management feature). Security alarms are raised if an
illegal access attempt using wrong credentials is done to Flexi Multiradio BTS.
Mass update
Updating the local passwords in the network elements is a time consuming operation,
which needs to be performed frequently. Mass updating functionality helps keeping the
network element local passwords up to date. With this feature it is possible to update the
local user account passwords for Flexi BTS remotely from NetAct ™.
Password aging
With this function the Operator can select if password aging and account locking shall
be enabled. The Flexi Multiradio BTS informs users about an expired password and the
users can change their own central account passwords during login if their password is
locked due to expiration.
86 Id:0900d805806f2b93
7.3.8 User event log management

User event log management enables auditing of user actions in the Flexi Multiradio BTS
and enables fast means to start corrective actions and prevention of possible configura-
tion damages.
User event logs from all the Flexi Multiradio BTS can be centrally aggregated with the
NetAct ™ “Audit Trail” tool. The operator can trace and correlate changes for a Flexi
BTS created by the BTS Site Manager (uploaded from Flexi Multiradio BTS) and from
network management level (log files stored on management nodes).
The upload of Flexi Multiradio BTS log files is triggered from NetAct ™. An XML file
format is used as the log file format. NetAct ™ can also produce the data in the User
Event Collection in the same XML format. The XML coding is made available for 3rd
party applications. A secure File Transfer Protocol is applied for the log file collection
from the Flexi Multiradio BTS, and NetAct ™ provides tools for processing the collected
log files.
With the NetAct ™ applications, the operator can create reports from the data collection,
for example, based on the user or Flexi Multiradio BTS identity. Centralized user
auditing increases the system security.
7.4 Flexi Multiradio BTS supplementary OAM features

The Flexi Multiradio BTS supplementary features comprise the following:
• GPS location retrieval
• NTP clock time synchronization
• DHCP server for BTS site equipment
7.4.1 GPS location retrieval

The GPS module in the Flexi Multiradio BTS provides an interface to fetch geographical
coordinates and, optionally, the UTC Time information.
If a fixed mounted GPS module is available on site, the Flexi Multiradio BTS can be con-
figured to use the control interface (SW management interface) to access the GPS infor-
mation:
• fetch the GPS coordinates in terms of Longitude, Latitude and Altitude values
• fetch the accurate GPS time
This GPS time is calculated to UTC time. The time information may be used to synchro-
nize the BTS internal clocks (time of day, not intented to be used as frequency reference
for oscillators) or used for example as time stamps in messages, alarms, notifications,
trace records, and so on. The external GPS device that is connected in MDR26 connec-
tor which accepts NMEA 0183 data.
g The configuration of time zone and Summer and Winter time can be derived via
GPS and is done during site commissioning.
Id:0900d805806f2b93 87
7.4.2 NTP clock time synchronization

The Network Time Protocol (NTP) is a standard which makes it possible to synchronize
the clocks / timestamps between Network Management nodes and the Flexi Multiradio
BTS over an IP backhaul network.
NTP Server(s) are introduced to provide the setting and adjustment of the internal clocks
via the NTP protocol without degradation of the load processing by Flexi Multiradio BTS.
A DNS server within the operator's network is used by Flexi Multiradio BTS to look up
the IP addresses of NTP server(s). The NTP server(s) used for the Flexi Multiradio BTS
shall be of stratum level 2 or better (higher stratum levels are offset from a Stratum-1
server over a network path. As such, a Stratum-2 server would get its time over an NTP
link from a Stratum-1 server which provides the Universal Coordinated Time (UTC)).
The derived time is used, for example, in O&M time stamps to allow alarm correlation or
for log entries and their evaluation.
g The configuration of time zone and summer and winter time is done during site com-
missioning.
7.4.3 DHCP server for BTS site equipment

An internal DHCP server enables a dynamic IP host configuration for IP devices con-
nected to the Flexi Multiradio BTS subnet at the Flexi Multiradio BTS site.
Devices like antenna tilt controllers or local management tools such as the BTSSM
receive an IP configuration from the DHCP server located in the Flexi Transport Module
(FTM). Along with the IP address, other network parameters are also given. The mean-
ingful parameters are: Default gateway IP-address, lease time and subnet mask. The
DHCP server in the FTM is configured with the Transport Element Manager (TRSEM)
or with the site commissioning file during installation.
DHCP functionality is supported according to [RFC2131] and [RFC2132]. Ports UPD
#/67 and #68 are reserved for DHCP. The DHCP lease time is one week. The DHCP
lease is renewed before lease time ends.
7.5 Flexi Multiradio BTS diagnosis

For the current release, only general tracing functionality is supported. In future
releases, Flexi Multiradio BTS diagnosis will also comprise the following applications:
• Trace data support for external usage
• Cell traffic trace
• Subscriber and equipment trace
7.5.1 Tracing
General tracing functions comprise the following:
• Trace management
• Trace data collection and reporting
• Reporting modes
Trace management
The Nokia Siemens Networks solution follows the general definitions recommended by
3GPP TS 32.421 and 32.422. It is assembled by four building blocks:
88 Id:0900d805806f2b93
• TraceViewer is the central tool within the NetACT application for trace activation
and trace result evaluation. NetAct ™ TraceViewer also offers centralized adminis-
trative functions for the trace data reporting mode (real time and non-real time).
• CentralTraceControl is the central generic trace management function block
across the network. It supports the forwarding of administrative commands to the
affected Network Entities (NE) like the Flexi Multiradio BTS and is the central part
for handling of trace data collected from different NEs.
• Flexi Multiradio BTS LocalTraceControl is the local generic trace management
function inside the BTS. It is responsible for storing the trace parameters locally and
for informing the TraceDataProducer to start the trace data collection of the specific
call based on the trace parameters. It is also responsible for handling the trace data
sent from the TraceDataProducer, temporarily storing it in the specific trace log file
(in case of non-real time trace reporting mode, file based trace) or for generating the
trace reports and sending them to the CentralTraceControl at NetAct ™ (in case of
real time trace reporting mode).
• Flexi Multiradio BTS TraceDataProducer is the BTS specific trace data collection
functionality located on each call processing function block which delivers the trace
data. It is responsible for collecting the trace data of the specific call, based on the
LocalTraceControl requests.
Trace data collection and reporting

The trace records are generated in each Flexi Multiradio BTS where a trace session has
been started, and are sent to the NetAct ™ network data storage. The NetAct ™
TraceViewer has access to all collected data of the entire network nodes.
Trace records can be sent over the northbound interface to further network manage-
ment trace evaluation tools. The file format is XML based following the schema defined
in TS 32.423. The transfer goes from Flexi Multiradio BTS to the NetAct ™ element
manager and from there via the northbound interface to another network management
system.
If the received trace control and configuration parameters include an external IP
address, NetAct ™ retrieves the IP address from the trace records and transfers them
to the given IP address or based on the configured external IP address for this trace
session.
g Direct transfer of trace records from Flexi Multiradio BTS to another network man-
agement system or external IP address is not supported.
Reporting modes
Non-real time and real time reporting is supported. In case of non-real time trace report-
ing mode, the records are collected into files which are uploaded either on demand, or
time- controlled, to the CentralTraceControl at NetAct ™. In real time reporting mode,
each record is sent immediately to the CentralTraceControl.
Id:0900d805806f2b93 89
7.6 Self organizing network support

Self organizing network support comprises the following fuctions which are described in
the following sections in more detail:
• Auto connectivity
• Auto configuration
• LTE neighbor cell configuration with preplanned identities
• Automated adjacent cell configuration for LTE
For overall information on the self organizing network concept, see LTE/EPC system
overview.
7.6.1 Auto connectivity

The Flexi BTS Auto Connectivity function supports faster preparation of remote commis-
sioning of new or re-homed base stations by an automated IP connectivity setup and an
unambiguous Flexi Multiradio BTS LTE identification.
The Auto Connectivity procedure follows different phases:
• Step 1: Pre-planning and HW installation
• Step 2: Start of Auto Connection
• Step 3: Connect
• Step 4: Register
• Manual intervention
Step 1: Pre-planning and HW installation

• Factory:
The Flexi Multiradio BTS LTE is delivered from the factory with an initial basic SW
to allow at least the basic boot process, the SW for the connectivity agent and the
transmission software which enables the establishment of a connection to the IP
backhaul, and the self configuration agent SW.
• Site plan preparation:
The planning data related to new Flexi Multiradio BTS LTE is prepared. It is not
needed for the auto-connection phase itself, but it may be needed for the unambig-
uous Flexi Multiradio BTS LTE detection for the subsequent auto-configuration step.
• DHCP server preparation:
Since auto connection relies on the usage of standard DHCP services, the DHCP
servers are preconfigured with suitable options and Nokia Siemens Networks Flexi
Multiradio BTS LTE specific data (vendor specific attributes) like
– IP address of the Identity Management System (IDM) or another 3rd party PKI
Certificate Server providing a CMPv2 interface
– IP address of the VPN/Security Gateway protecting the responsible NetAct ™
OAM system
– IP address of the management peer of the responsible NetAct ™ system
– optionally, an IP address of a dedicated LDAP server for Certificate Manage-
ment issues
Identity Management System (IDMS) server (if deployed): The IDM's certificate
server and related data base directory are preconfigured with the Nokia Siemens
Networks device serial numbers of the ordered Flexi System Modules, the Nokia
90 Id:0900d805806f2b93
Siemens Networks signing Factory CA root certificate, and potentially other operator
trust certificates (trust anchors) that shall be installed on the BTS.
3rd party PKI Certificate Server (if deployed): The 3rd parties certificate server or the
data base directory are preconfigured with the Nokia Siemens Networks signing
Factory CA root certificate and potentially other operator trust certificates (trust
anchors) that shall be installed on the BTS.
g To allow the minimum auto connectivity procedure, at least the IP address of the
management peer of the responsible NetAct ™ OAM system has to be delivered
as DHCP vendor specific attribute. If this is not received by the Flexi Multiradio
BTS LTE, the auto configuration procedure fails. If no PKI certificate server
and/or VPN Gateway IP address is provided, the Flexi Multiradio BTS LTE tries
to connect to NetAct ™ without encryption. If this fails, it waits for manual or file
based delivery of the missing IP connectivity information with the help of the BTS
Site Manager.
• HW plan generation:
It includes all details that are needed to install BTS components (like antennas) and
cabling.
• BTS HW installation:
As a precondition, the power cable, transmission link, antenna and actual base
station are installed on site. The 3D map coordinates shall be available to the BTS
installer.
• Booting / power-on the Flexi Multiradio BTS LTE:
Each time the BTS is booted, it automatically runs a self test and the results of the
test are stored and also shown as LED indication. The power-on-self-test tests the
functionality of element internal units.
Step 2: Start of Auto Connection
• Check commissioning state:
The connectivity agent checks if the BTS is already commissioned
– If it is not yet commissioned, the auto connection procedure starts.
– If the commissioning state is set but there is no IP address for the management
plane available then the Auto Connection starts too.
– If the Flexi Multiradio BTS LTE is already commissioned, the regular start-up /
recovery is carried out.
g It is possible to reset the commissioning state from NetAct ™ or BTS SM when
running in operational mode, to force a repeated Auto-Connection with the next
start-up.
• Establishment of IP connectivity:
The Flexi Multiradio BTS LTE transport module is automatically configured to enable
the Flexi Multiradio BTS LTE to communicate with the network backhaul. It includes
the following steps:
– L1/L2 auto negotiation
– prepare IP address assignment
• IP address assignment:
To retrieve all information necessary for the IP connection establishment between
Flexi Multiradio BTS LTE and NetAct ™, the Flexi Multiradio BTS LTE acts as DHCP
client. The DHCP server assigns a public IP address, netmask and default gateway
IP address to the Flexi Multiradio BTS LTE and delivers further information as
vendor specific attributes, like the IP address of the Identity Management System
(IDM) or a 3rd party PKI Certificate Server as listed above.
Id:0900d805806f2b93 91
g It is up to the operator's network planning policy if a new static BTS IP address

is assigned during a later phase of auto configuration. If the DHCP assigned IP
address is kept then it is mandatory to assign the same address again in case
of renewal or lifetime expiry.
• Retrieval of operator certificate and trust anchors:
After receiving IP address information, the Flexi Multiradio BTS LTE starts the auto-
matic acquisition of the operator Flexi Multiradio BTS LTE node certificate and trust
anchors by contacting the operators IDMS / PKI certificate server. The CMPv2
protocol defined in RFC 4210 is followed.
The auto connection flow is illustrated in Figure 42.
IDM Certificate Security

Backhaul DHCP
Gateway
NetAct
server repository
Manual
Manual Site
Site
Installation
Installation
self tests
self tests (POST)
(POST)
Establish Ethernet Connectivity
DHCP: eN-IP@ & operator specific

IDM-IP@ / SEG-IP@ / NetAct-IP@
Authenticate to Operator’s IDM with NSN eNB

vendor Certificate & key signing request
Create, sign & download operator’s eNB Certificate
Establish IPsec tunnel to the Network Management’s Security Gateway

iOMS
Operation
Establish TLS connection to Operation & Mediation
& Mediation Subsystem
Subsystem (application
(application security) security)
Register to NetAct Topology Manager (eNB Registration)
connected ready for remote manual or automated commissioning
IDM: Identity Management POST: Power-on Self test DHCP: Dynamic Host Configuration Protocol
Figure 42 Auto connection flow

Step 3: Connect
As soon as the final certificates are available in the Flexi Multiradio BTS LTE, it starts
the secure O&M plane connection to the NetAct ™ framework.
– If an IP address of a VPN/Security Gateway protecting the responsible NetAct ™
OAM system was received from the DHCP server before, an IPsec connection is
established to the NetAct ™ VPN/SEG gateway.
– A TLS connection to secure the OAM management plane is established between the
Flexi Multiradio BTS LTE OAM application and the responsible NetAct ™ OAM
system.
92 Id:0900d805806f2b93
The TLS connection may be tunneled in addition within a previously established IPsec
tunnel towards a given VPG Gateway at the operator domain border; this depends on
the operator’s transport security concept.
g The mutual node authentication by public certificates is recommended by 3GPP but
not mandatory if the operator runs a trusted network. Therefore the auto connection
procedure is able to continue if no certificates are downloaded. In particular the auto-
mated certification retrieval step is skipped if no IP address of the Identity Manage-
ment System (IDM) or PKI Certificate Server was received from the DHCP server.
Step 4: Register
When the TLS connection is established, the Registration Request is sent to NetAct ™
to trigger either the self-configuration sequence or manual remote commissioning.
For proper configuration, the provision of the geographical site location is essential.
• Automatic identification
If there is a fixed mounted GPS receiver available on site, the registration includes
both a serial number and the automatically determined geographical coordinates of
the BTS. These 3D map coordinates are sent to Net Act's Auto configuration appli-
cation to support the automatic site identification.
• Manual identification
If there is no fixed mounted GPS receiver available on site, the registration can
include only a serial number. Therefore the field engineer delivers the geographical
site information together with the serial number outbound to the remote integration
center; via SMS, phone call, mail etc.
Manual intervention
There may be certain circumstances which hinder a full automated set-up of IP connec-
tivity. To cope with those situations, an installer on site can help or finalize the procedure
with the help of the BTS Site Manager:
• If the Flexi Multiradio BTS LTE recognizes a locally connected BTS Site Manager
during initial start-up, it halts before the DHCP server is asked and hands over
control to the BTS Site Manager.
• At this early stage, the installer can apply some site specific settings, such as:
– optional antenna and filter configurations
– IP address of the IDM server and/or NetAct ™ VPN/SEG if required because
they are not deliverable by the DHCP server
– whole configuration of IP connectivity because the DHCP server was not in
operation
– transfer the operator device certificates and trust anchors if required because
the automated download is not possible
• The Auto configuration process continues after prompted by the installer.
7.6.2 Auto configuration

The Flexi BTS Auto configuration provides automated configuration of new or relocated
base stations from a remote network operation center with minimized manual interven-
tion.
Auto configuration comprises the following steps:
• Pre-planning
Id:0900d805806f2b93 93
• Auto-configuration
• Network integration
The automated configuration is initiated by the Flexi Multiradio BTS LTE auto configu-
ration agent and controlled by the NetAct ™ Auto Configuration application which
belongs to the overall NetAct ™ SON Coordinator application. The agent SW is part of
the initial basic SW build delivered from the factory which provides also the basic boot-
strap process and the self-connectivity procedure. On NetAct ™ side the SON Coordi-
nator coordinates the execution of the existing common functions required to bring the
Flexi Multiradio BTS LTE into service, that is, it does not re-implement functions like SW
and License file download which are also needed during normal operation.
The auto-configuration can be run fully autonomously, or certain stop points can be
defined with the NetAct ™ Auto Configuration application. At a stop point, the configu-
ration stops and continues to the next stop point when prompted by the operator.
Pre-planning
• Factory:
The Flexi Multiradio BTS LTE is delivered from the factory with a basic SW which
includes all functions needed to operate as LTE Flexi BTS but without operator
specific parts and adaptations.
• Flexi Multiradio configuration plan preparation:
The planning data which is needed to integrate a new or relocated Flexi Multiradio
BTS LTE into the network is prepared in advance, that is, site configuration, radio
network configuration, and transmission configuration (except all configuration data
which are configured by SON procedures during operation).
Auto-configuration
• Check of commissioning state
The Flexi Multiradio BTS LTE auto configuration agent initiates the auto configura-
tion sequence when the IP connectivity on top of TLS to the NetAct ™ is established
as last part of the Auto Connection Feature. When NetAct ™ receives the triggering
Registration Request, the Auto Configuration application checks first whether the
BTS is already commissioned. If not, it starts the configuration sequence. If yes, then
it resets the state to unconditioned and starts the configuration too.
g The operator can reset the commissioning state from NetAct ™ or BTS Site
Manager while running in operational mode, to force a repeated Auto-Configu-
ration with the next start-up.
• Selection of the appropriate configuration plan file
The assignment of a pre-planned data to a certain Flexi Multiradio BTS LTE is done
with the help of a logical eNB ID and/or BTS Site ID. These IDs are unique within the
operator's network and are used to address the appropriate SW and configuration
files for that particular Flexi Multiradio BTS LTE site. During the network planning
phase, also the geographical map coordinates are evaluated and stored in each
plan file.
With this information, a Flexi Multiradio BTS LTE site location can be identified auto-
matically or manually during registration.
– Automatic identification
If there is a fixed mounted GPS receiver available on site the registration
included both a serial number and the measured geographical coordinates of
the BTS. The delivered 3D map coordinates are sent to Net Act's Auto configu-
94 Id:0900d805806f2b93
ration application. NetAct ™ automatically identifies the appropriate deliverables

with the help of coordinates.
g In some cases it may not be possible to accomplish BTS detection using
only map coordinates, for example if two Flexi Multiradio BTS LTE are co-
located. In this case, the auto configuration is stopped until the operator
manually resolves the ambiguity. So using the System Module serial number
together with shipping lists can be combined with the 3D map coordinates
for unambiguous identification.
– Manual identification
If there is no fixed mounted GPS receiver available on site, the registration
includes only a serial number. Therefore the field engineer delivered geograph-
ical site information together with the serial number outbound to the remote inte-
gration center; via SMS, phone call, mail etc. Here the mapping between the
Flexi Multiradio BTS LTE asking for registration and the appropriate deliverables
is done manually with the help of the serial number. For this task, the remote
integration center interworks with the NetAct ™ System.
g The manual mapping may take some time. As long as the registration is not
confirmed the Flexi Multiradio BTS LTE waits for an appropriate time. If this
time expires, the registration request is repeated.
• Configuration
– Software Update
The Flexi Multiradio BTS LTE agent receives the pre-configured SW configura-
tion list from NetAct ™ and connects, if necessary, to the SW Repository Server
to download all required SW build files.
– Configuration plan file download
Then the Flexi Multiradio BTS LTE configuration file is downloaded. It includes
all needed site, radio and transport configuration.
– Activate software and configuration
If the SW and configuration data verification is successful, the Flexi Multiradio
BTS LTE auto configuration agent activates the downloaded SW and configura-
tion data. This will cause re-starts of the Flexi Multiradio BTS LTE.
After the re-start the secure IPsec and TLS connections towards NetAct ™ are
established again.
– Re-connect to NetAct ™
If the transport configuration includes a new outer Flexi Multiradio BTS LTE IP
address then the Flexi Multiradio BTS LTE re-establishes the secure IPsec and
TLS connections to NetAct ™ with the new IP configuration, and the previous
DHCP-assigned one is discarded.
g It is up to the operator's network planning policy whether new IP addresses
are assigned. If the DHCP-assigned IP address is kept then it is mandatory
to assign the same address again in case of renewal or lifetime expiry.
• Tests
After the new start-up the configuration agent continues its BTS tests (antenna line
communication tests, Ethernet tests, EAC tests). Test results and active alarms are
included in the commissioning report.
• Licenses
After re-connection to NetAct ™, the Flexi Multiradio BTS LTE inspects its enabled
features and requests the needed license files from NetAct ™. If the files are not
Id:0900d805806f2b93 95
available at that time, or not received during the auto configuration process, the
license free period is applied and the license files are requested to be prepared.
• HW Inventory
The HW inventory identifies the available components, assembles the IDF file and
sends a notification to NetAct ™ to initiate the inventory upload.
• SW Inventory
The auto configuration agent sends an event to NetAct ™ which may trigger an
upload of the activated and properly running SW build with migrated patches and
available configuration data for back-up reasons. Also the commissioning report is
offered for upload.
The auto configuration flow is illustrated in Figure 43.
Security NetAct
Gateway
Topology SW CM3 License SON
Manager Configuration Inventory
Manager manager Coordinator
IPsec Pre-planned
configuration
Auto configuration request

eNB Registration (Site-ID, HW-ID, location..)
Initiate SW-Download Sequence

SW-Download
Initiate Configuration Download

Configuration File Download ( Site Creation, Radio & Transport Plans)
Request License File Assembly

Online File created
File
creation
Initiate License DL
Download License File
Initiate Inventory
upload
UploadInventory
Upload Inventory
Commissioned
ready for Network Integration
Figure 43 Auto configuration flow
Network integration
When the Flexi Multiradio BTS LTE is successfully configured, the network integration
starts either automatically or by a dedicated operator command. During the integration
phase all preconfigured X2 interface and S1 interface relations are established, that is,
IPsec associations are done and SCTP peers are connected.
The network integration flow is illustrated in Figure 44.
96 Id:0900d805806f2b93
SCTP: Streaming Control Protocol

GTP: GPRS Tunnel Protocol
Backhaul Neighbor Security MME EPC-GW

Sites Gateway*) Pool Pool
Pre-
Configured
neighbors
X2 : Establish IPsec Tunnels
Establish SCTP Associations (C-Plane)
Pre-
Configured
MME / GW
S1:Establish IPsec Tunnels
Establish SCTP Associations (C-Plane)
Operation Multi Mode BTS on Air
Establish GTP Tunnels (U-Plane) for active UE
Establish GTP Tunnels for HO (U-Plane)
*) here a simplified architecture is shown were all MME and SAE-GW are behind a single SEG
Figure 44 Network integration flow
7.6.3 LTE neighbor cell configuration with preplanned identities

For all adjacent LTE neighbor cells, the needed configuration data to establish the
required IP connectivity towards the hosting BTS site is done by off-line pre-planning. It
is limited in a way that only the BTS ID of the related logical eNB ID of the neighbor LTE
eNB hosting the excepted adjacent cells need to be configured. All other configuration
information for cells of adjacent base stations is automatically derived and updated via
the X2 interface.
During start-up of the Flexi Multiradio BTS LTE, X2 connections are established to all
planned neighbor base stations. All further needed cell configuration information is
exchanged between the requesting Flexi Multiradio BTS LTE and the neighbor eNB.
g This neighbor cell configuration planning does not take into account the real geo-
graphical neighbor relation, that is, there are more neighbor cell relations stored and
maintained as are given by real coverage borders. Multi-vendor support is not pro-
vided.
Id:0900d805806f2b93 97
LTE Neighbor cell configuration with preplanned identities comprises the following:
• Managing the IP connectivity configuration
• "Fast Mode" neighbor cell configuration with OAM
• Neighbor cell configuration via X2 initiated by a neighbor site
In LTE networks, UE mobility relies on information given by neighbor cell relations and
neighbor cell configurations. To support and allow a flexible pre-planning and update of
neighbor cell information, an automatic mechanism is implemented to complete a
probably partly done off-line plan with the help of X2 information exchange.
Managing the IP connectivity configuration

Given by the nature of the auto connectivity feature, the initial IP address of a newly
deployed Flexi Multiradio BTS LTE is assigned by a DHCP service. Therefore it is not
always possible or intended to pre-plan the IP connectivity configuration or IP addresses
for own sites and also not for expected neighbor sites. The used initial main identifier for
a site within a configuration plan file is the eNB global ID.
To derive and include the related IP connectivity information of the own site and of listed
neighbor sites, the following procedure is applied:
• During the auto configuration process, each Flexi Multiradio BTS LTE registers itself
with its eNB global ID and given IP configuration at NetAct ™.
• NetAct ™ uses the eNB Global ID to access the related configuration plan file of the
newly registered BTS and completes the transport configuration entries with the
received IP configuration.
• NetAct ™ searches for given pre-planned neighbor configurations (or their eNB
global IDs)
• NetAct ™ checks if the listed neighbor sites are already registered. For all sites in
operation, NetAct ™ queries the database for the assigned IP configurations.
• NetAct ™ stores the found IP configurations into the according neighbor cell config-
uration area within the plan file of the newly registered Flexi Multiradio BTS LTE.
• The updated configuration plan file is now ready to be downloaded automatically as
part of the auto-configuration process.
The operator can start the neighbor site scan, and the plan file update also manually on
demand for a single Flexi Multiradio BTS LTE or a list of BTSs.
g If the transport configuration already includes some IP configuration then these attri-
bute value(s) are not overwritten with the received ones. With this mechanism the
operator can assign a kind of "final" IP configuration substituting the DHCP assigned
ones.
"Fast Mode" neighbor cell configuration with OAM

As an option to minimize the operator effort for neighbor cell planning, it is sufficient to
plan only the eNB global ID of the new neighbor BTSs hosting the expected neighbor
cells. Before the configuration plan file is downloaded to the Flexi Multiradio BTS LTE,
NetAct ™ checks if the listed neighbor site is already in operation. If yes, NetAct ™
updates the related IP connectivity information within the configuration file. If not, the
configuration file is downloaded as it is, and the Flexi Multiradio BTS LTE has to wait
until it is contacted by the neighbor site. (See chapter "Managing the IP connectivity con-
figuration "and "Neighbor cell configuration via X2 initiated by a neighbor site").
98 Id:0900d805806f2b93
When the Flexi Multiradio BTS LTE receives a new configuration plan file including both
eNB Global ID and IP connectivity information of a neighbor site, it tries to connect to
the neighbor site if there is no X2 relation already established:
• The Flexi Multiradio BTS LTE first establishes the IPsec layer (if network domain
security is applied between eNB), followed by the SCTP connection establishment.
After successful X2 connectivity set-up, the Flexi Multiradio BTS LTE exchanges the
list of served cells with the new neighbor BTS, as defined by 3GPP TS 36.423. The
exchanged cell information contains all served cells of a site.
• With successfully including the new neighbor cell configurations into the local con-
figuration database, the Flexi Multiradio BTS LTE sends a notification to NetAct ™
to inform the operator about the modified configuration.
• If a neighbor site does not respond to a requested X2 Setup, the site is marked as
temporarily not reachable. The Flexi Multiradio BTS LTE repeats the attempt on a
regular basis. The time interval for the re-attempts is adjustable between 1 hour and
24 hours.
Neighbor cell configuration via X2 initiated by a neighbor site

If a new neighbor site goes into operation when some or all of its surrounding sites are
already on air, an operating Flexi Multiradio BTS LTE site may receive an X2 setup
request from this new site and has to react as responder:
• The already operating Flexi Multiradio BTS LTE is asked to establish the IPsec layer
(if network domain security is applied between eNB) followed by the SCTP connec-
tion setup, before the neighbor site sends the X2 setup request. If it accepts the
neighbor, the Flexi Multiradio BTS LTE responds with the own served cell informa-
tion as defined by 3GPP TS 36.423 and creates the neighbor cell configurations for
all reported cells.
• With successfully including the new neighbor cell configurations into the local con-
figuration data base, the Flexi Multiradio BTS LTE sends a notification to NetAct ™
to inform the operator about the modified cell configuration.
g The Flexi Multiradio BTS LTE accepts incoming IPSec and subsequent SCTP con-
nection even if no IP connectivity information about the peer is available in the own
neighbor site configuration data. If IPsec is enabled, the public certificate received
from the neighbor site must be valid. Otherwise the connection is refused.
7.6.4 Automated adjacent cell configuration for LTE

In LTE networks, the UE mobility in RRC Connected State relies on information given
by an explicit neighbor cell list.
To support and allow the automated configuration and update of neighbor cells without
the need for complete pre-planning the neighbor cell configurations, a special mecha-
nism is implemented to discover unknown cells:
• The UE reports all detected/strongest cells and therefore it may report cells whose
physical IDs are not known to the Flexi Multiradio BTS LTE. If this is the case, the
Flexi Multiradio BTS LTE sends a request to the UE to determine and report the
Global Cell IDs for the cells in question.
• If the Global Cell ID can be determined, it is forwarded to the operability function
responsible for the maintenance of the Neighbor Cell relations. This function then
tries to resolve the IP address of the newly found neighbor and to establish the X2
connectivity to derive all further relevant neighbor cell information.
Id:0900d805806f2b93 99
Security LTE RAN system description
8 Security
For mobile IP network security, it is important that the infrastructure network elements
and users are securely authenticated and authorized to access to the network. Nokia
Siemens Networks provides a comprehensive set of security controls in order to mitigate
the risks caused by the threats and to reduce the potential losses.
8.1 Impact of LTE architecture on security

LTE maintains the same level of security as the WCDMA or HSPA networks. It provides
strong physical security of the LTE site, and in particular, the eNB. LTE protects all
network segments with IPSec encryption and authentication mechanism. It uses strong
IPlevel security and it protects the eNB operation and management flows from the core
network to the eNB.
8.2 Physical security

Equipment
The core network elements are located in secure premises. The eNB is typically located
in the field (usually in a locked cabin), allowing relatively easy physical access for
anyone. The eNB is tamper resistant, this means it features tamper resistant enclo-
sures, tamper alarms, and unreachability alarms when an adapter does not send the
expected responses to the core network. The iOMS maintains the operation and main-
tenance connection supervision to the LTE site.
Network links
LTE connects the eNB to the core network, and eNBs to each other, with cryptographic
techniques. It protects the link from the adapter down to the UE with 3GPP encryption.
8.3 Access security

LTE RAN access security involves authentication, authorization, user event logging and
log collection, and the provision of user accounts and groups. The LTE/EPC perspective
is described in LTE/EPC system overview.
8.3.1 Authentication
eNB C-plane
Authentication is based on the standard username/password pairs involving the follow-
ing events.
1. HTTP
2. FTP
3. BTS Operation and maintenance
For all the events above, authentication uses the same program block.
A user is authenticated with a local username/password file, or with a NetAct ™ LDAP
server.
100 Id:0900d805806f2b95
LTE RAN system description Security
eNB U-plane
In LTE there is no authentication on the U-plane. Local operation and maintenance
connects to the U-plane through C-plane.
iOMS
LTE uses standard Linux username/password authentication.
Remote authentication
Centralized user information management is supported by iOMS and Flexi Multiradio
BTS LTE support, where the remote authentication server at the NetAct ™ site authen-
ticates users.
As an integral part of NetAct ™ the iOMS mediates between Flexi Multiradio BTS LTE
and the NetAct ™ LDAP server through NWI3. NWI3 sessions are authenticated with an
own username/password pair for each network element. NWI3 traffic itself is open text.
If NetAct ™ is not present in the system, remote authentication is not possible, and
therefore the system uses local authentication.
Password requirements
Password requirements include length, complexity level, and the aging policy. Pass-
words for local users follow the NET Security Hardening Guide. NetAct ™ controls
password for the NetAct ™ users.
8.3.2 Authorization
Authorization of local users
In Flexi Multiradio BTS LTE, there is no user rights separation. The system executes all
processes with the same privileges.
In iOMS, LTE uses standard Linux authorization.
Centralized user information management

Centralized User Information Management defines an authorization mechanism that the
remote authentication server at the NetAct ™ site manages. It is an optional feature and
can be present only when NetAct ™ is present in the system.
8.3.3 User event logging and log collection

The “Centralized user event log management” feature implements support for the user
event log collection in the eNB.
Id:0900d805806f2b95 101
8.4 BTS security

The key in the BTS security solution is to build all sites as separate secure entities.
Securing inter-site traffic involves traffic separation and authenticating and/or encrypting
the traffic between the sites. Traffic separation can be established by means of physi-
cally separated networks, or by establishing secure virtual networks (VLANs) within a
single backbone network shared among various types of traffic.
BTS security comprises the following features:
• Physical security
• Locally stored user ID and password
• Remote user information management
• Remote user event log management
• Centralized user information management for BTS
• Secure file transfer for Flexi Multiradio BTS LTE
• Network element certificate management for Flexi Multiradio BTS LTE
• Secure management interface for Flexi Multiradio BTS LTE
Physical security
The BTS units are in locked cabinets to secure them physically against break-in. If the
cabinet is opened by force, the BTS sends an alarm to the network management
system. The cabinets also protect the BTS units from rain and other hazardous weather
conditions. There are also fan units fitted into the cabinet to protect the units from over-
heating.
Locally stored user ID and password

The BTS units can be accessed from BTSSM or remotely from NetAct ™. A configurable
user ID and password can be used for accessing the network elements via BTSSM. This
user account has full administrator rights. The local user name and password is stored
in the flash (non-volatile) memory of the BTS. To access the BTS, the user must know
both the user ID and the password. The local user accounts of the Flexi Multiradio BTS
LTE can be mass-changed remotely.
Remote user information management

Remote user information management (RUIM) provides centralized user authentication
and authorization for NetAct ™ and BTSSM users. With this feature, the LTE RAN
administrator can manage access to the network and BTSSM with a centralized authen-
tication and authorization server. In the log-in phase, the network entity checks the user
access rights from the authentication and authorization server. The access rights can be
managed separately for each group or individual of the maintenance personnel. In the
User Information Management system, the operator can define different access classes
for different user groups and network elements. This feature enables also the possibility
for logging the user actions in the network with the same user ID (per user) in each
network entity (the “Remote user event log management” feature).
Remote user event log management

The “Remote user event log management” feature enables the centralized aggregation
of user event logs from the BTSes in NetAct ™. The operator can trace changes in the
network, based on user or network element information. The upload is triggered from
NetAct ™. An XML file format is used for the log file. NetAct ™ can also produce the
data in the User Event Collection in the same XML format. The XML coding is made
102 Id:0900d805806f2b95
available for third-party applications. Secure File Transfer for Flexi Multiradio BTS LTE
is used for the log file collection from network elements. NetAct ™ provides tools for pro-
cessing the collected log files. The operator can collect user event data from all BTSs.
With NetAct ™ applications, the operator can create reports from the data collection, for
example, reports based on the user or network element identity.
Centralized user information management for BTS

The “Centralized user information management for BTS” feature enables a centralized
user account management for BTS from NetAct ™, enabling the operator to manage the
access to the O&M network separately for each group or individual of the maintenance
personnel on a BTS access level.
Both BTS element manager user and the BTS host are identified to fulfill the security
requirements. Authentication is done in the centralized authentication server located in
NetAct ™.
Secure file transfer for Flexi Multiradio BTS LTE

The “Secure file transfer for Flexi Multiradio BTS LTE” feature enables protected
transfer of the O&M data files between RAN network elements and NetAct ™. O&M data
files transmitted using secure file transfer feature are encrypted and integrity protected.
Content of the transferred files cannot be eavesdropped or modified, for example, no
man-in-the-middle attacks are possible.
Network element certificate management for Flexi Multiradio BTS LTE

The “Network element certificate management for Flexi Multiradio BTS LTE” feature
defines the usage of Certificate Management (CMP) in LTE RAN. Digital certificates are
used to authenticate communicating peers and to encrypt sensitive data. They are
essential for Transport Layer Security (TLS) operation used in Secure BTS Manage-
ment Interface and Secure File Transfer features. Also IPSec feature uses certificates.
Secure management interface for Flexi Multiradio BTS LTE

The “Secure management interface for Flexi Multiradio BTS LTE” feature enables pro-
tected O&M communication between Flexi BTS and NetAct ™. It is activated by install-
ing a centralized license in the Flexi Multiradio BTS LTE. If no license is present, the
management interface is used in an insecure way.
Id:0900d805806f2b95 103
8.5 System security

As specified by 3GPP (see Figure 45) the LTE/EPC security architecture provides dif-
ferent security levels.
UE eUu eNB S1-MME MME eNB eNB
NAS signaling
(ciphered and integrity protected using NAS signaling security)
C-plane
S1-AP signaling X2-AP signaling
RRC signaling
(ciphered and integrity protected (ciphered and integrity protected
(ciphered and integrity protected)
with IPsec) with IPsec)
S1-U S-GW/
P-GW
U-plane data
U-plane U-plane data packets forwarded over X2
U-plane data
(ciphered and integrity protected (ciphered and integrity protected
(ciphered using PDCP)
with IPsec) with IPsec)
EMS/
O&M NMS
M-plane M-plane data

(ciphered and integrity protected
with Ipsec & TLS)
Figure 45 LTE/EPC security architecture

For more information on the LTE/EPC security architecture see also LTE/EPC System
Overview.
System security for the LTE RAN comprises:
• Firewall support
• IPsec support
• Transport layer security support
• IP based filtering for BTS site support equipment
• Secure network element identity and authentication
• Identity management
• Public key infrastructure support
• Certificate management
104 Id:0900d805806f2b95
8.5.1 Firewall support

The Flexi LTE BTS includes inhost firewall / packet filtering functionality in order to
prevent traffic, services and applications from unwanted sources. The firewall examines
all data to see if it meets certain criteria. If it does, it is routed between the networks,
otherwise it is dropped.
The firewall filters packets based on their source, destination addresses and port
numbers. It also blocks network-level attacks such as DoS, oversized packets, SYN
floods, and fragmentation attacks. The implementation is fully software based. The
packets are treated with fixed, nonconfigurable rules. These rules are created automat-
ically based on the configuration and are permanently active.
The rate of ICMP messages is limited to protect against Denial of Service (DoS) attacks
using faked ICMP messages.
It is possible to enable and disable the eNB to respond to "ping" and "traceroute" via the
BTS Site Manager or via NetAct Configurator.
8.5.2 IPsec support

Secure eNB control and bulk data communication between the Flexi Multiradio BTS LTE
and other eNBs and Core Nodes is enabled by using IPsec to secure transport and
application protocols. With IPsec there is also support for separation between different
types of traffic, like control plane traffic and user plane traffic from management traffic,
by own transport tunnels. The security of Flexi Multiradio BTS LTE control, user and
management plane interfaces is increased by providing encryption, integrity protection
and communication peer authentication with IPsec according RFC 4301. Compared to
TLS, IPsec does also allow, even though not recommended, using UDP for transport
and also unsecured protocols like FTP on top of TCP or UDP. It is possible to enable/dis-
able 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's recommendation TS 33.210 for inter-
working purposes and further appliance rules given by TS 33.401 and TR 33.821. Since
IPSec standards include high numbers of selectable security parameters and options,
3GPP has recommended to cut down the number of these options, in order to guarantee
interoperability between different security domains.
Table 8 summarizes the supported IPsec capabilities:
Id:0900d805806f2b95 105
Services Data integrity protection, origin authentication and anti-

replay protection
Protocol ESP (RFC 4303)
Confidentiality mandatory
Encryption/Ciphering 3DES-192-CBC, AES-128-CBC, NULL
Modes CBC, random chosen IV
Integrity HMAC-SHA-1-96
Identification IP addresses and Fully Qualified Domain Names (FQDN)
are supported for identification
Authentication Digital certificates in X.509v3 format
Key exchange • Dual stack IKEv1 (RFC 2409) / IKEv2 (RFC 4306)
• Key Management: ISAKMP (utilizes IKEv2 for key
exchange)
• Diffie-Hellman key exchange: Group 2 (1024-bit MODP)
• For prevention of certain type DoS attacks IPSec/IKEv2
is applied for LTE - IKEv2 uses initiator's and
responder's Cookies for authentication of legitimate
connections. Connections without proper Cookie will be
dropped off.
• ISAKMP SA and the IPsec SA(s) are regulary updated,
the ISAKMP SA life time is set to 24 hours/86400 s and
the IPsec child SA(s) lifetime is adjustable from 5 Min-
utes/300 s up 24 hours/86400 s, common for all IPsec
child SA(s).
Table 8 IPsec capabilities
Nokia Siemens Networks suggestion on IPsec configuration

IPSec implementation is optimized to provide best throughput and strongest security
levels when using ESP encapsulation with AES-CBS (128 or 256 bit key size) ciphers
together with SHA-1 HMAC algorithm. There is no significant performance/throughput
difference between AES-CBC-128 and AES-CBC-256, but 3DES is marginally slower
than any AES algorithm, and because of this should be avoided when possible.
IPsec for Traffic Separation

Control plane traffic, user plane traffic and management traffic can be separated with
IPsec VPN 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 sep-
aration in LTE, IPSec VPN tunnels as per 3GPP NDS/IP are supported.
g If some other external transport technology is in use providing also authentication
and encryption end-to-end between the Flexi Multiradio BTS LTE and other sites,
the IPsec based ciphering feature in LTE may be disabled, since ciphering twice
does not create additional security but will significantly increase overhead. But if
IPsec is used for tunnel provisioning then multiple encryption may happen anyway.
106 Id:0900d805806f2b95
Parallel usage of IPsec and other secure transport protocols

Depending on the transport network configuration, 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 like TLS can be used and con-
figured in parallel. For instance it is possible to run TLS connections within a common
IPsec tunnel or in parallel to IPsec tunnel(s).
8.5.3 Transport layer security support

Secure Flexi LTE BTS O&M control and bulk data communication between BTS and
NetAct ™ related other management systems including PKI infrastructure is enabled by
using secure protocols utilizing Transport Layer Security (TLS). CAPEX savings are
given as not having to invest into any external HW. Applied together with LDAP, TLS
takes care of confidential user credentials exchange.
The security of Flexi LTE BTS element manager interfaces and the network manage-
ment systems is increased by providing encryption, integrity protection and server
authentication with the Transport Layer Security Protocol (TLS) and HTTPS on top of it.
Unsecured protocols like 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 can also be used for authentication of the hosts and
servers providing a service.
Transport layer security support comprises the following:
• Digital certificates according to X.509v3 format are used to mutually authenticate
Flexi LTE BTS and network servers.
• Data encryption is used to prohibit against internal and external hostile attacks.
• OAM messages and commands are encrypted and integrity protected by TLS, for
example, user names and passwords are not delivered as plain text.
• Bulk data transfer is encrypted and integrity protected.
• The LDAP interface to authenticate user and fetch permission information for a user
is secured.
The Transport Layer Security Protocol (TLS, former/equivalent to Secure Socket Layer
Protocol SSL) provides both encryption and authentication features and consist of two
layers:
• The TLS/SSL record protocol takes care of encryption and integrity protection of
the message exchange.
• The TLS/SSL handshake protocol provides the mutual authentication of the com-
munication peers using digital certificates.
LDAP secured with TLS

The Centralized/Remote user information management (RUIM) feature and other
services like Certificate Management use an LDAP interface to authenticate users and
fetch permission information for a user. Using insecure connections on the LDAP link
between the BTS and the LDAP servers leads to a situation where a user's username
and password are transferred in plain text across the O&M network.
To avoid that the user credentials and permissions are transferred in plain text, the
LDAP interface is secured by means of TLS, using an AES-128 encryption and the
related integrity protection according to LDAPv3 as specified in RFC 4513.
Id:0900d805806f2b95 107
LDAP operation modes

The Flexi Multiradio BTS LTE can be configured to either allow towards LDAP servers
• only secured LDAP connections or
• both secured and unsecured LDAP connections
The configuration can be done by means of the BTS Site Manager or from NetAct ™.
g The Flexi Multiradio BTS LTE always attempts to establish a secured LDAP connec-
tion with the LDAP server. If the LDAP server denies a secure connection then the
Flexi Multiradio BTS LTE accepts unsecured LDAP connections only if configured
in the operation mode that allows both secured and unsecured LDAP connections.
Authentication and encryptions of TLS connections

The Flexi Multiradio BTS LTE authenticates LDAP servers with digital certificates
according to X.509v3 and encrypts all traffic that is sent via LDAP interface, if activated.
The same Flexi Multiradio BTS LTE device certificate that is used to authenticate IPSec
and other TLS connections is also applied for LDPA/TLS authentication.
Parallel usage of TLS and other secure transport protocols

Depending on the transport network configuration andthe number of network manage-
ment 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.
8.5.4 IP based filtering for BTS site support equipment

It is possible to selectively access the IP DCN towards site support equipment and vice
versa. Filtering is done based on IP addresses improvings the protection of:
• site support equipment from harmful IP DCN traffic
• IP DCN from harmful IP traffic originated from site support equipment
IP based filtering for BTS site support equipment is an extension to the internal firewall,
based on a static filter for BTS Site Support Equipment (SSE). Examples for such
external systems are solar power and battery backup systems. SSE can be connected
to the SS port of the Flexi System Module.
It is possible to define IP addresses or IP subnets that have access to any site support
equipment, as well as to assign the IP address of an SSE by the internal DHCP, from
out of the subnet address space. IP packets from/to any site support equipment which
are not targeted to/originated from any of the given IP addresses will be dropped.
The configuration can be done using the Site Element Manager from local or remote site
or via the plan file managed by NetAct ™.
8.5.5 Secure network element identity and authentication

With device authentication procedures, a network element such as the Flexi Multiradio
BTS LTE aims at ensuring that its communicating peer NE or system is the one that it
claims to be, and not a malicious other party, for example a hacker's computer. In LTE,
mutual authentication of the NEs is required, that is, both peers are authenticated.
Authentication can take place remotely and preferably also in an automated way without
human involvement.
108 Id:0900d805806f2b95
8.5.6 Identity management

Nokia Siemens Networks Identy Management (IDM) solution complies with 3GPP
security architectures of the UMTS and LTE/EPC. These architectures include IP
security and requirements of data origin authentication of mobile base stations and Core
elements. Using a digital public certificates infrastructure offers a secure and scalable
authentication method. The Flexi Multiradio BTS LTE and other nodes to be authenti-
cated have a certificate and a securely stored private key.
The Nokia Siemens Networks Secure Device Identity solution comprises two main func-
tions:
• NE authentication
The operator can verify that the NE is exactly the NE that it claims to be.
• NE authorization
Operators can decide which of the authenticated NEs they authorize to connect to
their network - typically only those they have ordered from the vendor.
8.5.7 Public key infrastructure support

Public Key Certification based authentication and authorization within the access
network and management network requires the provisioning of a Public Key Infrastruc-
ture on the sides of both the operator and Nokia Siemens Network as vendor. The Nokia
Siemens Networks Identity Management solution integrates the Nokia Siemens
Networks PKI manufacturing and delivery chain with the operator’s PKI infrastructure.
The Flexi Multiradio BTS LTE Certificate Management for digital certificates (cert) in
X.509v3 format is embedded in the Nokia Siemens Networks Networks Identity Man-
agement (IDM) solution as illustrated in Figure 46. It provides the needed infrastructure
including computer systems and applications for handling certificate requests and
aligned processes for certificate implementation.
Id:0900d805806f2b95 109
CD/DVD
Certificate Operator
Files
Factory Certification
Ordering & Delivery Chain

Authority – CA
Certificate
Certificate
request
signing
Centralized NSN Email
Certificate Repository
Certificate
CLicS
Certificate
Factory Registration Files
Authority – RA (FSM serial #)
Order #
FSM serial #
Public key
Certificate
Certificate Flexi System ● Nokia Siemens Networks

Signing Req. Operator Identity
(Public key)
Module
Management (IDM) Solution
Certificate
FSM serial # ● CA / automation tools
● Certificate Database
● Revocation management
Production Control System

Note: order # usually refers to many Certificate Files
Figure 46 Nokia Siemens Network device certificate delivery
SDI concept on Nokia Siemens Networks side

To comply with the IDM, Nokia Siemens Networks has introduced a Factory Certification
Authority (Factory-CA) and Registration Authority (Factory-RA) which creates and signs
a vendor device certificate for each individual BTS.
The private and public key pairs are created during Flexi Multiradio BTS LTE System
module assembly. This certificate is delivered to the operator when ordering a Flexi Mul-
tiradio BTS LTE System module.
IDM concept on operator side

On operator side, the IDM provides the Identity Management which comprises a certifi-
cation authority for:
• creation and management of the public operator device certificates
• additional authorization modules for automated checks of Nokia Siemens Networks
public device certificates against deployed Flexi Multiradio BTS LTE hardware.
• deployment of operator device certificates into the Flexi Multiradio BTS LTE
• renewal and revocation of operator certificates, if necessary.
The infrastructure is multi vendor capable as long as other products support the certifi-
cate exchange procedures and the related protocols, such as the Certificate Manage-
ment Protocol (CMPv2) which is used to derive the operator certificate from the
operator's IDM CA portal.
110 Id:0900d805806f2b95
Deployment of Operator Certificates without IDM

If the operator runs no 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 Flexi
Multiradio BTS LTE, either locally or remotely with the BTS Site Manager.
8.5.8 Certificate management

The Flexi Multiradio BTS LTE Certificate Management feature provides the handling of
the private and public key pair as well as digital certificates in X.509v3 format. Keys and
certificates are used for mutual authentication between IPsec and/or TLS protocol peers
and ciphering but may be also used for the verification of SW loads, configuration data
and und license validity. This feature represents the BTS local/peer part of the Nokia
Siemens Networks Identity Mangement System (IDM) as illustrated in Figure 47.
NSN Factory
Femto Certificate
Certificate Authority (CA) Repository
Lifecycle Authentication
WCDMA/ management Module
I-HSPA services Device
CMP Certificate
Database
LTE
SCEP Device
Certificate
web Converter
iOMS/
OMS
Engine
NetAct CRL
Policies
OCSP
Validation DB
MME services
X.509/LDAP
Directory
(certificate and
SAE-GW CRL publishing) Registration Authority (CA)
VPN
SEG NSN specific/proprietary PKI functions Integration to existing
PKI infrastructure (e.g.
Standard PKI function via cross-certification)
Figure 47 Nokia Siemens Networks Identity Mangement System

The Certificate Management feature is needed for enrollments, update and revocation
of operator certificates when public operator certificates are used in the network.
It comprises the following:
• Factory key and certificate provisioning
• Supported certificates
• Flexi Multiradio BTS LTE self-signed certificate
• Remote operator certificate enrollment
• Local certificate enrollment
• Upgrade of deployed system modules
• Certificate revocation
Id:0900d805806f2b95 111
• Certificate renewal / Re-keying
Factory key and certificate provisioning

To comply with the Nokia Siemens Networks Identity Mangement System (IDM)
concept, the manufacturing process of a Flexi Multiradio BTS LTE is extended by key
pair and certificate creation steps:
1. At a certain point in the BTS manufacturing process, a unique public and private key
is generated within the Flexi BTS System Module (FSM) in a highly secure environ-
ment, and stored within the BTS System Module in a secure key storage, such as a
trusted platform module (TPM) or SW based secure key storage.
2. The Nokia Siemens Networks Factory Certification Authority (Factory-CA) together
with the Factory Registration Authority (Factory-RA) creates and signs a Nokia
Siemens Networks device certificate for each individual BTS which is linked to the
serial number of the FSM.
3. The public Nokia Siemens Networks device certificate is stored together with the
Factory CA Certificate in the FSM secure key storage before modules are shipped
to warehouses and/or customers.
4. When an FSM module is delivered to the operator, it also gets also the public Nokia
Siemens Networks device certificate including the serial number of the shipped
module as identifier.
Using the Nokia Siemens Networks public device certificate as input, operators can
use the Nokia Siemens Networks Identity Management System:
– to create their own operator device certificate
– to verify / cross-check if the FSM belongs to the HW they have really ordered.
Both Nokia Siemens Networks certificates and new operator device certificates are
stored in the corresponding certification databases of the IDM.
Supported certificates
The Flexi Multiradio BTS LTE supports certificates in X.509v3 format. A single certificate
is used for both IPSec and TLS authentication needs.
Flexi Multiradio BTS LTE self-signed certificate

During start-up the Flexi Multiradio BTS LTE creates a self-signed certificate. This cer-
tificate is used to establish the TLS connection to the BTS Site Manager if there is no
certificate like an operator device certificate or Nokia Siemens Networks device certifi-
cate available in the Flexi Multiradio BTS LTE.
g As a fallback, the BTS Site manager accepts a self-signed BTS certificate, and the
Flexi Multiradio BTS LTE accepts a self-signed certificate from the BTS Site
Manager.
Remote operator certificate enrollment

When a newly deployed Flexi Multiradio BTS LTE connects to the transport network, it
is provided with the address of the operator's IDM server (as vendor/operator specific
attribute from the DHCP server or manually configured) as the first point of contact. As
the IDM server already knows the Flexi Multiradio BTS LTE (because it has already
received and stored its public node certificate) each peer can verify if the BTS belongs
to the pool of ordered devices.
The Flexi Multiradio BTS LTE creates a new key pair and establishes a Certificate Man-
agement Protocol (CMP) connection, to get the public key portion signed within a new
112 Id:0900d805806f2b95
operator device certificate for this BTS, and to download further trust anchors like the
operator's public signing CA certificate.
Once the Flexi Multiradio BTS LTE knows the final operator node certificate to be used,
it is able to establish secure connections to all of its communication partners via IPsec
or TLS with the correct operator node identity.
g Trust anchors are certificates of Certification Authorities the operator trusts in, like
the Nokia Siemens Network Factory CA, 3rd party trust CA like VeriSign and oper-
ator's own CA. These trust anchors are used for authentication issues for example
during the process of exchanging the vendor certificate for the operator certificate.
Local certificate enrollment

If the operator runs no IDM or similar PKI infrastructure then it is possible to introduce
the operator certificates and trust anchors by a manual procedure into the secure key
storage of the Flexi Multiradio BTS LTE either locally or remotly with the BTS Site
Manager. Certificate and Key Interchange according to PKCS#12 is supported between
Flexi Multiradio BTS LTE and BTS Site Manager.
Upgrade of deployed system modules

In an upgrade scenario where already deployed system modules without a PKI capable
SW need to be upgraded to support PKI, a manual procedure is applied which allows
the protected generation of a key pair within the BTS, and the secured transfer or export
of the public part of the key pair to the BTS Site Manager. This serves as input for vendor
node certificate creation or for operator node certificate creation. The outbound created
and signed certificates can be loaded into the secure key storage of the Flexi Multiradio
BTS LTE either locally or remotely with the BTS Site Manager.
Certificate revocation
Certificate revocation is done in circumstances when properties of end entity change,
such as private key compromise, change in affiliation, and name change. When certifi-
cates are identified for revocation, they are listed in the Certificate Revocation List (CRL)
in the operator's IDM. The CRL is either downloaded regularly into the CRL repository
of the Flexi Multiradio BTS LTE or interactively checked using the Online Certificate
Status Protocol (OCSP).
Certificate renewal / Re-keying

Certificate renewal is done when a certificate's lifetime ends and needs to be renewed.
A key update can be done simultaneously. This functionality is triggered from the Flexi
Multiradio BTS LTE or operator's IDM.
Id:0900d805806f2b95 113

LTE RAN System Description

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

LTE RAN System Description

Încărcat de

Drepturi de autor:

Formate disponibile

Nokia Siemens Networks LTE

Radio access, rel. RL10,

LTE RAN system description

f Important Notice on Product Safety

The same text in German:

1 Introduction to Nokia Siemens Networks LTE/EPC system. . . . . . . . . . 11

3 Network and service management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Radio resource management and telecom . . . . . . . . . . . . . . . . . . . . . . 47

6 Transport and transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2.1 RRC Signaling Protocol (eNB <> UE). . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.3 Access security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Figure 43 Auto configuration flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Issue Date of Issue Reason for Update

1 Introduction to Nokia Siemens Networks

Service Control and Data Bases

IMS PCRF HSS/AAA

Access Core Switching & Transport

Figure 1 LTE/SAE high-level architecture

Simplified network architecture

High-performance air interface

scalable Hybrid ARQ 64 QAM Fast Link Adaptation

DL: OFDMA UL: SC-FDMA 1

Advanced Scheduling Time

Figure 2 LTE air interface technology

• Superior inter-technology mobility

Operator benefits Subscriber benefits

Table 1 Summary of customer benefits

Network evolution and migration

Leverage existing handset base Exploit core network synergies

GSM/WCDMA Enabling flat broadbandarchitecture

Figure 3 Architectural evolution of existing 2G/3G networks to LTE

Direct tunnel Internet HSPA

HSPA R6 HSPA R7 HSPA R7 LTE R8

Direct Direct Direct

Control plane User plane Capacity expansions

Figure 4 Smooth migration towards EPS

Nokia Siemens Networks LTE/EPC product portfolio

2.1 LTE architecture

2.1.1 LTE overview

Figure 5 Functional split between radio access and core network

eNB MME P-GW

Figure 6 E-UTRAN and EPC with S1-flex

2.1.2 eNB functionality

– Radio Admission Control

2.2 LTE multiple access radio interface

Different technologies for uplink and downlink

Downlink: OFDMA Uplink: SC-FDMA

Table 2 Benefits of OFDMA and SC-FDMA

Modulation schemes for uplink and downlink

Figure 7 OFDMA and SC-FDMA modulation schemes

Signal generation and reception

Unique to SC-FDMA Common with OFDMA

Map data to Generate Perform Map Perform

Time domain Frequency domain Time domain

De-map Perform De-map Perform

Key ingredients of the LTE radio interface

2.2.1 OFDM concept

Figure 9 Orthogonal frequency division multiplex principle

2.2.2 OFDMA principles

Figure 10 OFDM and OFDMA subcarrier allocation

2.2.3 SC-FDMA principles

UE data after Q-point

Figure 11 DFT pre-coding and principle of SC-FDMA

2.3 LTE Radio protocol architecture