Lte Syd Ranepc

Nokia Networks

LTE Radio Access, Rel. CL15A, Operating Documentation, issue 02 LTE Centralized RAN and EPC System Description DN0993921 Issue 02B Approval Date 2015-07-31

LTE Centralized RAN and EPC System Description

The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein. This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks (“Agreement”) under which this document is distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Solutions and Networks. If you have not entered into an Agreement applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this document in any manner and You are obliged to return it to Nokia Solutions and Networks and destroy or delete any copies thereof. The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility when using it. Nokia Solutions and Networks welcome Your comments as part of the process of continuous development and improvement of the documentation. This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on an “as is” and “as available” basis in this document, and Nokia Solutions and Networks reserves the right to change any such information and statements without notice. Nokia Solutions and Networks has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But, Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia Solutions and Networks does not warrant that the use of the software in the Product will be uninterrupted or error-free. NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT. This document is Nokia Solutions and Networks’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © 2016 Nokia Solutions and Networks. All rights reserved.

f

Important Notice on Product Safety This product may present safety risks due to laser, electricity, heat, and other sources of danger. Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product. The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components. If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Solutions and Networks for any additional information.

2

DN0993921

Issue: 02B


Table of Contents This document has 173 pages

Summary of changes....................................................................11

1 1.1 1.2 1.3 1.4 1.5

Introduction to the LTE/EPC system............................................ 14 LTE architectural specification......................................................14 LTE system benefits .................................................................... 15 LTE network evolution and migration........................................... 16 Network deployment towards LTE/EPS....................................... 17 LTE/EPC product portfolio............................................................18

2 2.1 2.2 2.3 2.3.1 2.3.2 2.3.2.1 2.3.2.2 2.3.2.3 2.3.2.4 2.4 2.4.1 2.4.1.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.5 2.5.1 2.5.1.1 2.5.1.2 2.5.1.3 2.5.2 2.6 2.6.1 2.6.2 2.6.3

LTE network architecture..............................................................19 Functional split in the LTE system................................................19 Flexibility in LTE system............................................................... 20 Network elements in the LTE system........................................... 22 eNB function.................................................................................22 EPC architecture.......................................................................... 23 Mobility management entity (MME)..............................................23 Serving gateway (S-GW)............................................................. 24 Packet data network gateway (P-GW)......................................... 25 The legacy network elements in the LTE system......................... 25 LTE/EPC product portfolio............................................................26 Flexi Multiradio BTS LTE (macro eNB)........................................ 26 External interfaces of the Flexi Multiradio BTS LTE..................... 29 Flexi Zone Controller (FZC)......................................................... 30 Flexi Zone Micro BTS (micro eNB).............................................. 31 Flexi Zone Pico BTS (pico eNB).................................................. 31 Flexi Network Server (Flexi NS)................................................... 32 Flexi Network Gateway (Flexi NG)............................................... 33 LTE/SAE interfaces...................................................................... 34 Radio network interfaces..............................................................36 LTE-Uu interface.......................................................................... 36 S1 interface.................................................................................. 36 X2 interface.................................................................................. 37 Core network interfaces............................................................... 38 Protocol stacks.............................................................................38 Radio protocol architecture.......................................................... 38 EPS protocol architecture............................................................ 42 Protocol architecture for interfaces for legacy 3GPP interworking... 46 LTE multiple access radio interface (FDD)...................................47 OFDM concept............................................................................. 49 OFDMA principles........................................................................ 50 SC-FDMA principles.....................................................................51

2.7 2.7.1 2.7.2 2.7.3

Issue: 02B

DN0993921

3


4

2.8 2.9 2.9.1 2.9.2 2.9.3 2.9.3.1 2.9.3.2 2.9.4 2.10 2.11 2.12 2.13 2.13.1 2.13.2 2.14 2.14.1 2.14.2 2.14.3

LTE radio protocol architecture.................................................... 52 Multi-antenna techniques............................................................. 53 Receive diversity.......................................................................... 54 Transmit diversity......................................................................... 55 MIMO techniques......................................................................... 55 Downlink MIMO techniques......................................................... 57 Multi-user MIMO techniques........................................................ 57 The uplink intra-eNB Coordinated Multipoint (CoMP).................. 57 Radio network optimization.......................................................... 58 Interference mitigation..................................................................59 RAN sharing.................................................................................60 Single RAN introduction............................................................... 62 Nokia Single RAN enablers..........................................................63 Single RAN features.....................................................................64 Zone eNB solution........................................................................65 Overview of Flexi Zone Controller within Zone eNB solution....... 65 Zone eNB network deployment overview.....................................65 Flexi Zone Controller instructions and references........................66

3 3.1 3.2 3.3 3.4

Network and service management...............................................68 Network management architecture.............................................. 68 Managing the LTE/EPC system with NetAct................................ 69 Element management tools......................................................... 69 CRAN network management....................................................... 70

4 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.4 4.5 4.6

Mobility......................................................................................... 71 Mobility scenarios.........................................................................71 Mobility anchors........................................................................... 72 Handovers....................................................................................73 Measurements and measurement reports................................... 74 Inter-eNB handover......................................................................76 Inter-RAT handover (3GPP)......................................................... 78 Optimized 3GPP2 (HRPD) inter-RAT handover...........................80 Inter-frequency handover............................................................. 81 Zone eNB inter-cell handover...................................................... 82 Open Access Home eNB Mobility................................................ 82 Roaming.......................................................................................82 Location services......................................................................... 85

5 5.1 5.2 5.3 5.4 5.5 5.6 5.6.1

Radio resource management and telecom.................................. 87 RRM functions..............................................................................87 State transitions........................................................................... 91 Connection states for intra-RAT mobility...................................... 93 Tracking Areas............................................................................. 94 Tracking Area Update.................................................................. 95 Paging.......................................................................................... 97 Paging on S1................................................................................98

DN0993921

Issue: 02B


Issue: 02B

5.6.2 5.6.3 5.7 5.7.1 5.7.2 5.8

Paging on Uu/RRC paging function............................................. 98 Paging of system information changes........................................ 98 EPS bearers.................................................................................99 Bearer management.................................................................. 100 Quality of service........................................................................101 Additional services..................................................................... 103

6 6.1 6.2 6.3 6.4 6.4.1 6.4.2 6.5 6.5.1 6.5.2 6.5.3 6.6 6.6.1 6.6.2 6.6.3 6.6.4 6.6.5 6.6.6 6.7 6.8 6.8.1 6.8.2

Transport and transmission........................................................105 LTE transport overview...............................................................105 Transport interface options.........................................................107 Transport switching in eNB........................................................ 109 IP addressing..............................................................................111 Addressing at the eNB side........................................................ 112 Addressing external peer nodes from the eNB side................... 115 Traffic engineering...................................................................... 115 Traffic prioritization..................................................................... 115 Traffic differentiation................................................................... 117 Traffic shaping............................................................................ 118 Synchronization.......................................................................... 118 Synchronization from GPS......................................................... 119 Synchronization from 2.048 MHz signal..................................... 119 Synchronous Ethernet................................................................120 Timing over Packet.....................................................................120 Synchronization from PDH interface.......................................... 121 Hybrid synchronization...............................................................121 Transport admission control....................................................... 121 Architecture of LTE datapath management................................122 S1 transport architecture............................................................123 X2 transport architecture............................................................124

7 7.1 7.2 7.3 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 7.4.8 7.5 7.5.1 7.5.2

Operability.................................................................................. 125 Operability architecture.............................................................. 125 NetAct framework.......................................................................126 BTS Site Manager......................................................................128 Flexi Multiradio BTS LTE management functions...................... 130 Fault management..................................................................... 131 Configuration management........................................................131 Software management............................................................... 131 Performance management.........................................................132 Hardware/inventory management.............................................. 132 Feature/license management.....................................................133 User account management........................................................ 133 User event log management...................................................... 133 Flexi Multiradio BTS supplementary OAM features................... 134 GPS location retrieval................................................................ 134 NTP clock time synchronization................................................. 134

DN0993921

5


6

7.5.3 7.6 7.6.1 7.6.2 7.6.2.1 7.6.2.2 7.7 7.7.1

Automatic iOMS resiliency......................................................... 135 Flexi Multiradio BTS diagnosis...................................................135 Trace data support for external usage....................................... 135 Tracing....................................................................................... 137 Cell traffic trace.......................................................................... 138 Subscriber and equipment trace................................................ 140 Self Organizing Network support............................................... 141 Automatic neighbor relation (ANR)............................................ 142

8 8.1 8.1.1 8.1.2 8.1.3 8.1.4 8.2 8.2.1 8.2.2 8.2.3 8.3 8.4 8.5 8.6 8.6.1 8.6.2 8.6.3 8.6.4 8.6.5 8.7

Security...................................................................................... 144 Security requirements and methods.......................................... 144 Security categories.....................................................................144 Security threats.......................................................................... 144 Security areas............................................................................ 145 Security features........................................................................ 146 LTE/EPC M/C/U/S-plane security...............................................147 C-plane security......................................................................... 149 U-plane security......................................................................... 149 M-plane security.........................................................................150 User security.............................................................................. 151 BTS security...............................................................................151 NetAct security........................................................................... 153 Network security.........................................................................154 Firewall support..........................................................................154 IPsec support............................................................................. 154 Transport Layer Security support............................................... 156 IP-based filtering for BTS Site Support Equipment.................... 156 Certificate management............................................................. 157 Support of a Public Key Infrastructure....................................... 157

9 9.1 9.2 9.3

AAA and charging...................................................................... 159 LTE/EPC authentication............................................................. 159 Authorization.............................................................................. 160 Accounting and charging............................................................160

10

Migration to LTE VoIP.................................................................164

11

Nokia service solutions – key benefits and customer values..... 169

12

Nokia environmental issues....................................................... 171

DN0993921

Issue: 02B


List of Figures

Issue: 02B

Figure 1

LTE/SAE high-level architecture......................................................... 15

Figure 2

Architectural evolution of existing 2G/3G networks to LTE.................17

Figure 3

Migration toward EPS.........................................................................18

Figure 4

LTE/EPC flat network architecture and direct tunnel.......................... 19

Figure 5

Functional split between radio access and core network................... 20

Figure 6

E-UTRAN and EPC with S1 Flex........................................................20

Figure 7

E-UTRAN and EPC with S1 Flex........................................................21

Figure 8

CRAN functionality............................................................................. 22

Figure 9

Flexi Multiradio BTS site solution....................................................... 27

Figure 10

Flexi Multiradio BTS site solution for the 2TX MIMO in a 3-sector configuration....................................................................................... 28

Figure 11

Flexi Multiradio RRH 60 W................................................................. 29

Figure 12

External interfaces of the Flexi Multiradio BTS LTE........................... 30

Figure 13

Flexi Zone Controller.......................................................................... 30

Figure 14

Example of Flexi Zone Outdoor Micro BTS (micro eNB)....................31

Figure 15

Example of Flexi Zone Indoor Pico BTS (pico eNB)...........................32

Figure 16

Flexi Network Server.......................................................................... 33

Figure 17

Flexi NG..............................................................................................34

Figure 18

EPS architecture.................................................................................35

Figure 19

EPS architecture.................................................................................35

Figure 20

Uu user plane protocol stack.............................................................. 39

Figure 21

U-plane operation of PDCP and RLC.................................................39

Figure 22

Uu control plane protocol stack.......................................................... 40

Figure 23

C-plane operation of PDCP................................................................ 41

Figure 24

S1-U user plane protocol stack.......................................................... 42

Figure 25

X2 user plane protocol stack.............................................................. 42

Figure 26

S5/S8 user plane protocol stack (GTP variant).................................. 43

Figure 27

S5/S8 user plane protocol stack (IETF variant)..................................43

Figure 28

S1-MME control plane protocol stack.................................................43

Figure 29

X2 control plane protocol stack.......................................................... 44

Figure 30

S5/S8 control plane protocol stack (GTP variant).............................. 44

Figure 31

S5/S8 control plane protocol stack (IETF variant).............................. 44

Figure 32

S10 control plane protocol stack........................................................ 45

Figure 33

S11 control plane protocol stack.........................................................45

Figure 34

S6a control plane protocol stack........................................................ 45

Figure 35

S13 control plane protocol stack........................................................ 45

Figure 36

SBc control plane protocol stack........................................................ 45

Figure 37

S4 user plane protocol stack.............................................................. 46

Figure 38

S12 user plane protocol stack............................................................ 46

DN0993921

7


8

Figure 39

S3 control plane protocol stack.......................................................... 46

Figure 40

S4 control plane protocol stack.......................................................... 46

Figure 41

OFDMA and SC-FDMA modulation schemes.................................... 48

Figure 42

OFDMA and SC-FDMA signal generation and reception (simplified model).................................................................................................48

Figure 43

Orthogonal frequency division multiplex principle.............................. 50

Figure 44

OFDM and OFDMA subcarrier allocation...........................................51

Figure 45

DFT pre-coding and principle of SC-FDMA........................................51

Figure 46

Mapping of physical, transport and logical channels.......................... 53

Figure 47

2x2 MIMO configuration..................................................................... 56

Figure 48

Operator modules in RAN sharing......................................................61

Figure 49

RAN sharing architecture................................................................... 62

Figure 50

Basic schema of Flexi Zone deployment ...........................................65

Figure 51

Zone deployment overview.................................................................66

Figure 52

LTE/EPC network management architecture..................................... 68

Figure 53

Mobility scenarios for LTE/EPC.......................................................... 72

Figure 54

Mobility anchor point...........................................................................73

Figure 55

Functional units of an inter-eNB handover procedure........................ 74

Figure 56

Inter-eNB handover with X2 interface.................................................77

Figure 57

Inter-eNB handover without X2 interface............................................77

Figure 58

3GPP inter-RAT mobility.....................................................................79

Figure 59

Architecture for optimized LTE-HRPD mobility................................... 81

Figure 60

Roaming scenario with home routed traffic........................................ 83

Figure 61

Roaming scenario for local breakout with home operator's application functions............................................................................................. 83

Figure 62

Roaming scenario for local breakout with visited operator's application functions............................................................................................. 84

Figure 63

EMM state transitions......................................................................... 91

Figure 64

ECM state transitions......................................................................... 92

Figure 65

RRC state transitions..........................................................................93

Figure 66

Intra-RAT mobility in ECM_IDLE........................................................ 93

Figure 67

Intra-RAT mobility in ECM_CONNECTED......................................... 94

Figure 68

Multiple-TA registration concept......................................................... 96

Figure 69

LTE/EPC service data flows............................................................... 99

Figure 70

LTE/EPC EPS high level bearer model............................................ 100

Figure 71

Architecture of LTE transport............................................................ 105

Figure 72

Transport Protocol Stack Overview.................................................. 106

Figure 73

Transport Protocol Stack Overview.................................................. 106

Figure 74

Ethernet backhaul for LTE/EPC........................................................108

Figure 75

Example of E-UTRAN transport topologies...................................... 110

Figure 76

Network configuration with four VLANs.............................................111

DN0993921

Issue: 02B


Issue: 02B

Figure 77

Network configuration without VLANs.............................................. 112

Figure 78

Connection of SSE to eNB............................................................... 114

Figure 79

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

Figure 80

Traffic prioritization on the Ethernet layer, using packet marking methods............................................................................................ 117

Figure 81

M-plane traffic differentiation using VLAN over Ethernet.................. 118

Figure 82

Synchronization from 2.048 MHz signal........................................... 119

Figure 83

ToP based synchronization...............................................................120

Figure 84

Architecture of LTE datapath management...................................... 122

Figure 85

S1 transport architecture.................................................................. 123

Figure 86

X2 transport architecture.................................................................. 124

Figure 87

LTE/EPC Operation and maintenance concept................................ 125

Figure 88

Functional overview of the BTS Site Manager................................. 128

Figure 89

Cell trace concept.............................................................................139

Figure 90

Cell subscriber and equipment trace concept.................................. 141

Figure 91

SON architecture.............................................................................. 142

Figure 92

LTE/EPC M/C/U-plane security........................................................ 148

Figure 93

C-plane security architecture for LTE/EPC....................................... 149

Figure 94

U-plane security architecture for LTE/EPC....................................... 150

Figure 95

M-plane security architecture for LTE/EPC...................................... 150

Figure 96

Layered security association structure of the LTE/EPC................... 159

Figure 97

LTE/EPC AKA procedure................................................................. 160

Figure 98

Retrieval of LTE authorization information........................................160

Figure 99

EPC charging - 3GPP access - non roaming................................... 161

Figure 100

EPC charging - 3GPP access - roaming, home routed traffic.......... 162

Figure 101

EPC charging - 3GPP access - roaming with local breakout........... 162

Figure 102

LTE/EPC architecture with PS & CS domains completely separated..... 164

Figure 103

LTE/EPC architecture CS fallback.................................................... 165

Figure 104

Single radio voice call continuity (SRVCC) principle........................ 165

Figure 105

LTE/EPC SRVCC architecture for 3GPP accesses..........................166

Figure 106

LTE/EPC SRVCC architecture for 1xRTT.........................................166

Figure 107

LTE/EPC architecture with all-IP network deploying LTE................. 167

DN0993921

9


List of Tables

10

Table 1

CRAN customer benefits.................................................................... 16

Table 2

Benefits of OFDMA and SC-FDMA.................................................... 47

Table 3

Multi-antenna options in LTE.............................................................. 53

Table 4

Mobility scenarios and anchor points................................................. 73

Table 5

Selected content of the “MeasResults” IE.......................................... 76

Table 6

LCS requirements...............................................................................85

Table 7

Scope of RRM functions.....................................................................88

Table 8

QoS scheme for LTE........................................................................ 101

Table 9

Standard QCI characteristics............................................................102

Table 10

BTS Site Manager local and remote functionality.............................130

Table 11

Security termination points............................................................... 148

Table 12

IPsec capabilities..............................................................................155

DN0993921

Issue: 02B


Summary of changes

Summary of changes Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues. Changes between issues 02A (2015-07-31, CL15A) and 02B (2016-01-29, CL15A) CRAN specific information added to the document: •

Timing over Packet (6.6.4.) section has been updated; the Timing over Packet with frequency synchronization feature has been added.

Changes between issues 02 (2015-06-19, CL15A) and 02A (2015-07-31, CL15A) CRAN specific information added to the document: •

Flexibility in LTE system (2.2) chapter has been updated (support for 1RX per cell in CRAN).

Changes between issues 01C (2015-05-29, CL10 EP1) and 02 (2015-06-19, CL15A) CRAN specific information added to the document: • • • •

Flexibility in LTE system (2.2) chapter has been updated. Interference mitigation (2.11) chapter has been updated. CRAN network management (3.4) chapter has been updated. BTS Site Manager (7.3) chapter has been updated.

Information about Flexi Zone Controller and Zone eNB have been added to the document. Details: In the Network architecture (2) chapter, the Flexibility in LTE sytem (2.2) section has been updated. In the LTE/EPC product portfolio (2.4) section, a new Flexi Zone Controller (2.4.2) subsection has been added. The Flexi Zone Micro BTS (micro eNB) (2.4.3) subsection has been updated. The LTE/SAE interfaces (2.5) section has been updated. The Zone eNB solution (2.14) section has been added. In the Mobility (4) chapter, a new Zone eNB inter-cell handover (4.3.6) section has been added. LTE network architecture (2) •

Information about LTE1691: Uplink intra-eNB CoMP 4Rx feature has been added.

Mobility (4) •

Issue: 02B

Section 4.3 Handovers has been added. Information from a legacy Handover document has been moved to this chapter. The Handover document has been removed from this release.

DN0993921

11

Summary of changes


• • •

Information about LTE2050: Load triggered Idle Mode Load Balancing feature has been added. Information about LTE1768: MRO Ping Pong feature has been added. Information about LTE1127: Service Based Mobility Trigger feature has been added.

Radio resource management and telecom (5) • • • • • • • • • • • •

Information about the following features has been added to the RRM functions (5.1) subsection: LTE1042: Nominal Bitrate for non-GBR bearers LTE1113: eICIC – macro LTE1496: eICIC – micro LTE1140: Intra-Frequency Load Balancing LTE1562: Carrier aggregation for multi-carrier eNodeBs LTE1800: Downlink interference shaping LTE1803: Downlink carrier aggregation 3 CC - 40 MHz LTE1841: Inter-Frequency Load Equalization LTE2133: eICIC for HetNet eNode B Configurations Information about the LTE1321: eRAB Modification - GBR feature has been added to the Quality of service (5.7.2) subsection. Information about the LTE1117: LTE MBMS feature has been added to the Additional services (5.8) subsection.

Transport and Transmission (6) •

• • • • •

The IP addressing (6.4) section has been updated. Information from a legacy LTE Transport document has been moved to this chapter. The LTE Transport document has been removed from this release. Information about theLTE1710: Sync Hub Direct Forwardfeature has been added. Information about the LTE1771: Dual U-plane IP addresses feature has been added to theAddressing at the eNB side (6.4.1) subsection. Information about the LTE891: Timing over Packet with Phase Synch feature has been added to the new Timing over packet (6.6.4) subsection. Information about the LTE942: Hybrid Synchronization feature has been added to the new Hybrid synchronization (6.6.6) subsection. The Architecture of LTE datapath management (6.8) section has been added. Information from a legacy LTE Datapath Management document has been moved to this chapter. The LTE Datapath Management document has been removed from this release.

Operability (7) •

•

•

12

Section 7.7 Self Organizing Network support has been updated. Information from a legacy Automatic Neighbor Relation (ANR) document has been moved to this chapter. The Automatic Neighbor Relation (ANR) document has been removed from this release. Section 7.7.1 Automatic neighbor relation (ANR) has been added. Information from a legacy Automatic Neighbor Relation (ANR) document has been moved to this chapter. Information about the LTE1053: Real-time KPI-monitoring with Traffica feature has been added to the Performance management (7.7.4) subsection.

DN0993921

Issue: 02B


• • • •

Summary of changes

Information about the LTE908: ANR Inter-RAT UTRAN - Fully UE-based feature has been added to the Automatic neighbor relation (ANR) (7.7.1) subsection. Information about the LTE1821: Neighbor Detection Optimization for HetNet feature has been added to the Automatic neighbor relation (ANR) (7.7.1) subsection. Information about the LTE1822: PCI Assignment Optimization for HetNet feature has been added to the Automatic neighbor relation (ANR) (7.7.1) subsection. Information about the LTE1823: Neighbor Prioritization Optimization for HetNet feature has been added to the Automatic neighbor relation (ANR) (7.7.1) subsection.

Security (8) Chapter S-plane security (8.2.4) has been removed. Information about LTE1076: Support of TLS 1.2 feature has been added. In the whole, document editorial changes were made. The document has been updated with information about a Flexi Zone Pico BTS (pico eNB). Changes between issues 01B (2015-02-24, CL10 EP1) and 01C (2015-05-29, CL10 EP1) • • •

Issue: 02B

Flexibility in LTE system (2.2) chapter has been updated. Interference mitigation (2.11) chapter has been updated. BTS Site Manager (7.3) chapter has been updated.

DN0993921

13

Introduction to the LTE/EPC system


1 Introduction to the LTE/EPC system The long-term evolution/system architecture evolution (LTE/SAE) technology in the 15ARL70 release is based on 3GPP Release 113GPP Release 10 and introduces more LTE-Advanced features.

g

Note: This document provides an overview of the long-term evolution/evolved packet core (LTE/EPC) system. Functions and features are described without reference to the system releases. This information can be found in the Nokia LTE roadmap. LTE/SAE is designed to: •

•

•

make the most of scarce spectrum resources Deployable with bandwidths that range up to 20 MHz, LTE/SAE provides up to four times the spectral efficiency of HSDPA. enable users to experience today’s best residential broadband access LTE/SAE delivers theoretical peak data rates ranging up to 173 Mbps per cell 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 further improving performance For instance, a 4x4 multiple input multiple output (MIMO) scheme will boost downlink rates up to 326 Mbps.

CRAN Centralized RAN (CRAN) is a Nokia innovative solution, specialized for mass events. Mobile operators worldwide need to provide not only mobile broadband coverage but also a variety of services during mass events held at stadiums, concert halls, train stations, festivals in parks, convention centers, etc It is characteristic of such venues that a number of people are gathered together in a small area. At the same time, people in such situations are using the mobile broadband services in ever-increasing amounts, causing data traffic to increase as never before.

1.1 LTE architectural specification The LTE/SAE high-level architecture. Based on performance targets, 3GPP defines the air interface, network architecture, and system interfaces. All services are packet-based; this includes voice services that are implemented as voice over IP (VoIP). Figure 1: LTE/SAE high-level architecture shows an LTE/SAE network’s high-level architecture. The 3GPP envisages fully IP-based transmission. The IP backbone network supports guaranteed quality of service (QoS) on demand with a simplified, but backwardcompatible QoS concept. Carrier-grade Ethernet is used where possible; in particular, to connect the evolved node B (eNB), the LTE’s base station.

14

DN0993921

Issue: 02B


Figure 1


LTE/SAE high-level architecture ServiceControlandDataBases

IMS

Access

PCRF

HSS/AAA

CoreSwitching& Transport

MME

Internet eNodeB S-GW

P-GW

1.2 LTE system benefits The introduction of LTE provides key benefits compared to existing 3G deployments. Key benefits: •

•

•

•

•

Issue: 02B

Maximal 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 the 2G spectrum. Scalable bandwidth allows flexible deployment with a limited spectrum. Reduced cost of ownership because of simplified network architecture The flat IP-based, packet-only architecture lowers operators' capital expenditure (CAPEX) and operating expenditure (OPEX) by simplifying network architecture from four nodes (NB, RNC, SGSN, and GGSN) to just an eNB, two logical user plane gateways (the serving gateway and PDN gateway (S-GW/P-GW)), and one control plane gateway (MME). Gateway functions can 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, which allows the use of cheap equipment and infrastructure.The access network operates without a central controller (BSC, RNC). All functions of a central controller have been moved to the base stations (eNBs). The eNBs interconnect and connect directly to the S-GW/PGW and MME to exchange control and user information. 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 high bandwidth and low latency. 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, etc LTE can support terminal speeds of 150 to 350 km/h and cell ranges of up to 100 km. 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 non3GPP (for example WLAN). High-performance air interface

DN0993921

15



The LTE air interface differs markedly from the legacy technology. Advanced applied orthogonal frequency-division multiplexing (OFDM) technologies achieve performance and savings goals based on low total cost of ownership. Many OFDMA subcarriers can be allocated according to carrier bandwidth available in the downlink. The uplink employs a single carrier FDMA technology (SC-FDMA) to preclude high peak-to-average power ratios, thereby streamlining the radio frequency (RF) design and extending the battery life of the terminals. OFDM ensures improved interference control, advanced scheduling techniques and ease of implementation of MIMO concepts. MIMO antenna technology, and higher order modulation (64OAM), combined with fast link adaptation methods, maximize the spectral efficiency. The LTE air interface is designed to operate in the same spectrum as the legacy wideband code division multiple access/high-speed packet access (WCDMA/HSPA) air interface. The LTE radio interface for the UE and for the eNB supports both FDD and TDD modes, each with their own frame structures. 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. Subscriber benefits Beneficial from the subscriber’s point of view are enriched user experience with realtime interactive services and seamless connectivity, broadband mobility at a decreasing cost, and a wide variety of devices and services.

•

Table 1: CRAN customer benefits presents CRAN customer benefits which create an add-on value to the LTE benefits. Table 1

CRAN customer benefits Operator benefits

•

turning interference into usable traffic

•

providing 100–200% average UL capacity gain in dense deployment during heavilyloaded mass events eliminating cell edge performance degradation preventing additional hardware investments and operational costs due to the fact that no additional HW or modification of the existing one is required ensuring system flexibility as a result of its unlimited scalability

• •

•

Subscriber benefits • •

enhancing the LTE user's experience by increasing throughput and service quality improving UE battery life

1.3 LTE network evolution and migration Nokia 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. For more information, see Figure 2: Architectural evolution of existing 2G/3G networks to LTE).

16

DN0993921

Issue: 02B


•

• •

•

•

•


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) accommodates LTE/EPC’s flat IP-based network architecture while supporting legacy WCDMA/HSPA handsets. The operator can perform transport and network scaling and upgrade the network to LTE/EPC later. 3G operators who have deployed I-HSPA have a 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 introducing mobile broadband services and the spectrum they have available. Because LTE supports bands as small as 1.4 MHz, spectrum can be re-farmed gradually from GSM to LTE. CDMA operators can introduce LTE/EPC networks directly or follow one of the above paths. GSM/EDGE is a good choice for strategies that are more immediately focused on a 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, and quickly optimize mobile broadband performance. Operators with WiMAX can migrate to LTE. Both technologies share common characteristics, namely, a physical layer based on orthogonal frequency-division multiplexing (OFDM), a flat IP architecture, and the use of multiple antenna system techniques (MIMO) to achieve high data rates. Operators with TD-SCDMA networks, which are currently deployed in China only, can migrate directly to LTE, preferably using the TDD mode of LTE.

Figure 2

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

Leverageexistinghandsetbase

Exploitcorenetworksynergies

GSM/WCDMA handsetbase

Enablingflatbroadbandarchitecture

LTE I-HSPA WCDMA/ HSPA GSM/ (E)GPRS

TD-SCDMA

CDMA

1.4 Network deployment towards LTE/EPS For 3GPP operators, the evolved packet system (EPS) solution enables optimized steps from 2G/3G legacy infrastructure to reach the target EPS architecture as illustrated in Figure 3: Migration toward EPS: 1. Introduction of direct tunnel between RNC and GGSN

Issue: 02B

DN0993921

17


2. 3. 4. 5.


Introduction of RNC functionality and direct tunnel between NB and GGSN Introduction of EPC Upgrade ability of legacy SGSN with MME functionality Upgrade ability of legacy GGSN with P-GW functionality

Figure 3

Migration toward EPS Directtunnel

InternetHSPA

HSPA R6

HSPA R7

HSPA R7

LTER8

GGSN

GGSN

GGSN

P-GW S-GW

SGSN

Direct tunnel

SGSN

RNC

RNC

NB

NB Controlplane

SGSN

Direct tunnel

NBwith RNCfunct. Userplane

Direct tunnel

MME

eNB

Capacityexpansions

1.5 LTE/EPC product portfolio The LTE/EPC system comprising the logical entities eNB, S-GW, P-GW, and MME is implemented in Nokia products. This section contains information on Nokia products. The LTE/EPC portfolio comprises the following network elements: •

eNB products: – – – –

•

MME: –

•

Flexi Network Server (Flexi NS)

S-GW/P-GW: –

18

Flexi Multiradio BTS LTE (macro eNB) Flexi Zone Controller (FZC) Flexi Zone Micro BTS (micro eNB) Flexi Zone Pico BTS (pico eNB)

Flexi Network Gateway (Flexi NG)

DN0993921

Issue: 02B


LTE network architecture

2 LTE network architecture The LTE/SAE solution, known as the LTE/EPC system, applies flat network architecture as illustrated in Figure 4: LTE/EPC flat network architecture and direct tunnel. The radio network consists of a single node, the eNB (or Flexi Zone Micro/Pico BTS also called a micro/pico eNB). In the core network, the Mobility Management Entity (MME) takes the role of SGSN in current GPRS networks, it is a control plane element. Management system traffic to and from LTE/EPC network elements always goes through NetAct. For more information, see Network and service management section. Direct tunnel between eNB and S-GW/P-GW allows user plane traffic to bypass the MME. Different gateway elements in EPC take the role of GGSN providing connectivity to operator service networks and the Internet. There are two gateway functions which are usually integrated into a single network element: • •

Serving Gateway (S-GW), the user plane (U-plane) gateway to the E-UTRAN Packet Data Network Gateway (P-GW), the user plane (U-plane) gateway to the Packet Data Network (PDN)

Between the eNB and core network entities there is Security Gateway (SEG), which provides security for the control plane, user plane, management plane, and synchronization plane. Figure 4

LTE/EPC flat network architecture and direct tunnel eNB micro/picoeNB

MME S-GW/P-GW

Directtunnel

The micro/pico eNB uses the same core network that is used by the eNB (also called a macro eNB). The interface between the micro/pico eNB and the core network is the same as the interface between the macro eNB and the core network. The interface between the micro/pico eNB and an eNB is the same as the interface between eNBs. The micro/pico eNB can be deployed inside the eNB to help cover a large demand for mobile data in a specific area. From the point of view of function, the Zone eNB, which comprises the Flexi Zone Controller (FZC) and Flexi Zone Access Point (FZAP), is a counterpart of the eNB.

2.1 Functional split in the LTE system LTE fully implements a radio function in the eNB. The radio function is illustrated in Figure 5: Functional split between radio access and core network. Communication between an eNB and S-GW/MME is done via transport network, see Uu user plane protocol stack and Uu control plane protocol stack.

Issue: 02B

DN0993921

19



Figure 5

Functional split between radio access and core network

eNB InterCellRRM RBControl ConnectionMobilityCont. RadioAdmissionControl

S-GW eNBMeasurement Configuration&Provision

P-GW

S1-U

UEIPAddressallocation

S5/S8 MobilityAnchoring

DynamicResource Allocation(Scheduler)

PacketFiltering

RRC PDCP

MME NASSecurity

RLC

IdleState MobilityHandling

S1-MME

MAC

ActiveState MobilityHandling

PHY

SAEBearerControl

E-UTRAN

EPC

2.2 Flexibility in LTE system A single eNB can connect to multiple MMEs. This ability provides flexibility and reliability and is referred to as S1 Flex. The eNB connection options are illustrated in Figure 6: EUTRAN and EPC with S1 FlexFigure 7: E-UTRAN and EPC with S1 Flex. Figure 6

E-UTRAN and EPC with S1 Flex LTE_Uu

S1

S5/S8a

EUTRAN

EPC S1-U S1-MME

eNB

S-GW

S11

X2

MME S1-MME

S11

S1-MME

eNB

P-GW

S1-U

X2 S1-U

S10

S-GW S11 S1-MME

eNB

20

MME

DN0993921

Issue: 02B


Figure 7


E-UTRAN and EPC with S1 Flex

LTE_Uu

S1

S5/S8a

EUTRAN

EPC S1-U S1-MME

eNB

S11

S-GW

X2

MME S1-MME

P-GW

S1-MME

micro/pico

S11

S1-U

X2 eNB S1-U

S10

S11

S-GW

S1-MME

MME

FZC Z1

Z1

FZAP FZAP

Z1

FZAP

FlexiZone AccessPointsCluster

The eNB can be connected simultaneously to the different Evolved Packet Cores (EPCs) of different operators. This means that the LTE E-UTRAN can be shared between mobile network operators. This is done via the S1 Flex mechanism which allows eNB establishing multiple S1 links. Different core networks can be connected to the commonly shared eNBs. The operators are able to share the resources of a single Flexi Multiradio BTS. This means that the operators can reduce CAPEX and OPEX. CRAN functionality The CRAN functionality perfectly meets customers' needs, which are best noticeable during mass events such as musical concerts or sporting events in places such as stadiums, where throughput limitations often appear in the uplink. The solution is based on an extended intra-eNB uplink CoMP functionality. The individual eNBs are interconnected in a linear chain/loop to exchange uplink I/Q data for inter-eNB uplink CoMP. One eNB can be connected to two adjacent neighbor eNBs. The eNBs are operated as independent entities. The maximum UL CoMP set size for this feature is six; that is, up to six cells with 1 RX and 2 RX paths. The uplink signal from up to 12 RX antennas is measured; up to 8 RX antennas are selected for IRC processing. The eNB selects eight paths, out of a maximum of 12 RX paths, for optimal throughput. The RX path selection is performed per UE and per TTI, based on uplink SINR measurements. The CRAN functionality is supported by the LTE HW standard. That is why no additional expenditure on the infrastructure is needed. CRAN works with all existing R8 LTE terminals. It also supports a dedicated eNB configuration with each FSMF containing two FBBCs and with pre-defined Inter-FSM cabling rules.

Issue: 02B

DN0993921

21



With a CRAN feature, up to five FSMFs can be chained/looped inside one CRAN system, supporting a maximum of 20 cells. Larger configurations are built with groups of CRAN systems. For more information, see the LTE1900: Centralized RAN feature description. The LTE1900: Centralized RAN feature does not support Flexi Zone Micro and Zone eNB. The CRAN functionality is presented in the picture below. The FSMF sees all six cells with 12 receivers and performs Dynamic inter-eNB UL-CoMP. Figure 8

4A

Fxxx

CRAN functionality

4B

3A

3B

Fxxx

2B

2A

Fxxx

1A

1B

Fxxx

12A

Fxxx

12B

11A

11B

Fxxx

FSMF

10A

Fxxx

10B

9A

9B

Fxxx

FSMF

Fxxx-radiomodule

2.3 Network elements in the LTE system The evolved packet system (EPS) is made up of the evolved UTRAN (E-UTRAN), evolved packet core (EPC), and connectivity to legacy 3GPP access and non-3GPP access systems.

2.3.1 eNB function The eNB hosts functions on three layers. The eNB hosts the following functions: Radio Network Layer 1 (Physical Layer) • • • • • • • • •

22

Error detection on the transport channel and indication to higher layers FEC encoding/decoding of the transport channel Hybrid ARQ soft-combining Rate matching of the coded transport channel to physical channels Mapping of the coded transport channel onto physical channels Power weighing of physical channels Modulation and demodulation of physical channels Frequency and time synchronization Radio characteristics measurements and indication to higher layers

DN0993921

Issue: 02B


• • • •


Multiple inputs multiple outputs (MIMO) antenna processing Transmit diversity (TX diversity) Beamforming RF processing

Radio Network Layer 2 • • • • • •

PDCP: robust header compression (RoHC); ciphering RLC: RLC segmentation; automatic repeat request (ARQ) MAC: MAC multiplexing Hybrid automatic repeat request (HARQ) Uplink timing alignment Packet scheduling

Radio Network Layer 3 Radio resource control: • • • • • •

Radio bearer control Radio admission control Idle and connected mode mobility control Inter-cell interference coordination Load balancing Inter-RAT RRM

Network related functions • •

Routing of U-plane to S-GW Uplink QoS support at transport and bearer level

2.3.2 EPC architecture The EPC network architecture is composed of the following main elements compliant with 3GPP Release 8 specifications and with open interfaces: • • • • • •

2.3.2.1

Mobility Management Entity (MME) Serving gateway (S-GW) Packet data network gateway (P-GW) Home Subscriber Server (HSS) Policy Charging and Rules Function (PCRF) Authentication, Authorization and Accounting function (AAA)

Mobility management entity (MME) The 2G/3G SGSN evolves into the LTE MME. As a pure control plane element, it handles non-access stratum (NAS) signaling and NAS signaling security. The MME also handles the signaling between core network nodes to support handovers between LTE and other 3GPP access networks such as GSM or WCDMA. The MME implements idle mode user equipment tracking and reachability. It performs:

Issue: 02B

DN0993921

23


• • •


packet data network (PDN) gateway and serving gateway selection MME selection for handovers that include a change of MME SGSN selection for handovers to 2G or 3G 3GPP access networks.

The MME supports subscriber roaming. It implements an interface with the user’s home subscriber server (HSS). It authenticates the subscriber’s right to access operator network resources. It also handles bearer management functions, including dedicated bearer establishment. MME functionality: • • • • • • • •

• • • • • •

2.3.2.2

authenticates and authorizes the user provides roaming support with the S6a interface manages and stores UE context generates temporary identities and allocates them to UEs manages mobility (idle and active mode) manages intra-LTE mobility manages inter-RAT mobility (between LTE and 2G/3G access networks) provides optimized inter-system signaling for mobility between LTE and HRPD (applicable to PP2 operators): SRVCC support for 1X CS-voice, and SRVCC for 3GPP (UTRAN/GERAN) provides CS fallback (CSFB) functionality towards GERAN, UTRAN, or CDMA2000 provides support for MME and S-GW relocation manages EPS bearers terminates for non-access stratum (NAS) signaling provides NAS signaling security and delivery of security keys to an eNB supports lawful interception for the signaling traffic

Serving gateway (S-GW) The S-GW terminates the LTE core user plane interface with E-UTRAN. User equipment (UE) is assigned to a single S-GW at a given point in time. The S-GW acts as a userplane gateway • •

for the LTE radio network in inter-eNB handovers for inter-3GPP mobility (relaying traffic between the 2G/3G system and the PDN GW)

The S-GW manages packet routing and forwarding. It handles idle mode downlink packet buffering and initiates the network-triggered service request procedure. In roaming cases, the serving GW offers roaming support to home-routed traffic and lawful interception and charging capability in the visited network. S-GW functionality: • • • • •

24

serves as an anchor point both for an inter-eNB handover and for intra-3GPP mobility (that is, a handover to and from 2G or 3G). provides default EPS bearer termination (applicable only to the IETF variant). provides dedicated non-GBR/GBR EPS bearer termination (applicable only to the IETF variant). provides roaming support with the S8 interface. is responsible for packet forwarding, routing, and buffering of downlink data for UEs that are in an LTE-IDLE state.

DN0993921

Issue: 02B


• • •

2.3.2.3


is responsible for data forwarding to HSGW in the case of a handover from LTE to HRPD (applicable only to pp2 operators and available in future releases). is responsible for data forwarding from source the S-GW to target S-GW in the case of indirect data forwarding. provides lawful interception support in roaming cases.

Packet data network gateway (P-GW) P-GW acts as a user plane anchor. It allocates an IP address for the UE. P-GW applies policy enforcement to subscriber traffic and performs packet filtering at the level of individual users (for example, by deep packet inspection). The gateway interfaces the operator’s online and offline charging systems. It also provides home agent functionality for interworking between non-3GPP networks (for example, the Internet or the operator's IP multimedia subsystem (IMS)) and when the interface between the S-GW and P-GW is implemented using a mobile IP-based protocol. The P-GW functionality: •

serves as a global mobility anchor for mobility between – –

• • • • • • •

2.3.2.4

3GPP and non-3GPP access LTE and Pre-release 8 3GPP access

provides default EPS bearer termination and IP address allocation provides dedicated non-GBR/GBR EPS bearer termination provides roaming support with the S8 interface supports S-GW relocation is responsible for policy enforcement and AMBR-based bandwidth management provides policy and charging control support with relevant PCRF interfaces provides charging support

The legacy network elements in the LTE system This section contains general information on legacy network elements in LTE. The legacy network elements of interest to LTE/EPC are the following: home subscriber server (HSS), policy and charging rules function (PCRF), authentication, authorization and accounting function (AAA), aerving GPRS support node (SGSN). Home subscriber server (HSS) HSS is the core network entity responsible for managing user profiles, and performing the authentication and authorization of users. The user profiles managed by HSS consist of subscription and security information as well as details on the physical location of the user. The HSS functionality: • • • • •

Issue: 02B

provides the user authentication and authorization information to the MME manages user profiles preserves user location at an MME level stores mobility and service data for every subscriber serves as a permanent and central subscriber database

DN0993921

25



Policy and charging rules function (PCRF) PCRF is responsible for brokering QoS policy and charging policy on a per-flow basis. In roaming scenarios, it provides such services as hPCRF and vPCRF. Authentication, authorization and accounting function (AAA) AAA is responsible for relaying authentication and authorization information to and from non-3GPP access network connected to EPC. Serving GPRS support node (SGSN) SGSN is responsible for transferring packet data between the core network and the legacy 2G/3G RAN. For LTE/EPC, this node is only of interest from the perspective of inter-system mobility management.

2.4 LTE/EPC product portfolio The LTE/EPC system comprising the logical entities eNB, S-GW, P-GW, and MME is implemented in Nokia products. This section contains information on Nokia products. The LTE/EPC portfolio comprises the following network elements: •

eNB products: – – – –

•

MME: –

•

Flexi Multiradio BTS LTE (macro eNB) Flexi Zone Controller (FZC) Flexi Zone Micro BTS (micro eNB) Flexi Zone Pico BTS (pico eNB)

Flexi Network Server (Flexi NS)

S-GW/P-GW: –

Flexi Network Gateway (Flexi NG)

2.4.1 Flexi Multiradio BTS LTE (macro eNB) The 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 is operating in an LTE SW mode. With the LTE447: SW Support for RF Sharing GSM-LTE feature, it is possible for Flexi Multiradio RF module to operate in a concurrent GSM and LTE mode. This means that one Flexi Multiradio RF module is transmitting both GSM/EDGE RF carriers, and the LTE RF carrier signals at the same 3GPP frequency band. The operator can run both GSM and LTE concurrently with the same Flexi Multiradio RF module. With the LTE435: RF Sharing WCDMA-LTE feature, it is possible for Flexi Multiradio RF module to operate in a concurrent WCDMA and LTE mode. This means that the Flexi Multiradio RF module is transmitting both WCDMA RF carrier and LTE RF carrier signals on a 2100-MHz band.

26

DN0993921

Issue: 02B



RF-sharing features bring OPEX savings on spare part stock, logistics, and maintenance. Figure 9

Flexi Multiradio BTS site solution

MultiradioSystemModule 3-sectorRFModule AC/DC+BatteryModule

As shown in Figure 9: Flexi Multiradio BTS site solution, 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 configurations, 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 the Flexi 210 W 3-sector radio module. In the 3-sector BTS, all RF functions are integrated to one single outdoor installable 3 U high module. With two 3-sector RF modules in 2TX MIMO configuration, the TX power is 120 W per sector/cell (60 W + 60 W).

Issue: 02B

DN0993921

27



Figure 10

Flexi Multiradio BTS site solution for the 2TX MIMO in a 3-sector configuration RX3 Tx1/RX1

RX4 Tx2/RX2

Sector1

Sector2

Sector3

Optional TMA/MHA

MultiradioSystemModule

Two3-sectorRFModule

Optional AC/DC+Battery

Another option, especially for feederless and distributed LTE BTS sites, is the Flexi Multiradio remote radio head (RRH), which can support one sector with the following integrated features: • • • • • • • • • •

28

two transceivers to support 2TX MIMO 40 W + 40 W output power at antenna connectors two linear power amplifiers two RF filters for TX/RX two-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

DN0993921

Issue: 02B


Figure 11


Flexi Multiradio RRH 60 W

The Flexi Multiradio BTS provides the following installation options: • • • • •

2.4.1.1

wall installation floor installation any legacy cabinet installation pole installation inside constructions

External interfaces of the Flexi Multiradio BTS LTE The external interfaces (see Figure 12: External interfaces of the Flexi Multiradio BTS LTE) of the Flexi Multiradio BTS LTE include: • • • • • • •

Issue: 02B

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 EUTRAN and MME S1-U interface between eNBs and S-GW, carrying user plane traffic between EUTRAN and S-GW O&M interface between eNBs and NetAct via iOMS O&M interface between eNB and BTS SM O&M interface between eNB and public key infrastructure (PKI) X2 interface between eNBs

DN0993921

29


Figure 12


External interfaces of the Flexi Multiradio BTS LTE PublicKey Infrastructure

UserEquipment LTE-Uu

IntegratedOperation MediationSystem

O&M O&M

ServingGateway

O&M

S1-U

BTS SiteManager

X2 S1-MME

othereNBs

MobilityManagement Entity

2.4.2 Flexi Zone Controller (FZC) Flexi Zone Controller (FZC) is a highly scalable controller platform designed to meet the growing capacity demand of dense small cell deployments.. Flexi Zone Controller aggregates Flexi Zone Access Points and acts as a single eNB towards the core network, providing mobility anchoring to all UEs within the Zone eNB. For more information, see Zone eNB solution. The Flexi Zone Controller hardware is based on the BCN platform. It boasts significant processing capability designed to handle control and user plane traffic to/from a large number of small cells and EPC. For more details on the hardware platform, please refer to the FZC operational guides. Figure 13

30

Flexi Zone Controller

DN0993921

Issue: 02B



Flexi Zone Controller (FZC) is capable of supporting FDD and TD Flexi Zona Access Points (FZAPs), but not simultaneously. It means that all FZAPs connected with FZC are either FDD FZAPs or TD FZAPs.

2.4.3 Flexi Zone Micro BTS (micro eNB) The Flexi Zone Micro BTS (micro eNB) has been created to enhance the macro LTE network (for example, it helps cover a large demand for mobile data in a specific area). The Flexi Zone Micro BTS hardware can be re-purposed as a Flexi Zone Access Point (FZAP) under the Flexi Zone Solution. Flexi Zone Micro BTS (micro eNB) is part of the second generation of Nokia LTE BTS; the small cell BTS is optimized for an outdoor micro-cell environment. The Flexi Zone Micro BTS hardware can be re-purposed as a Flexi Zone Access Point (FZAP) under the Flexi Zone Solution, where several FZAPs are aggregated under a Flexi Zone Controller. The design of the Flexi Zone Micro BTS is based on the Flexi Multiradio BTS platform. Most of the functions of this element are the same as a traditional eNB's; they are discussed in the Flexi Multiradio BTS LTE (macro eNB) section. The main roles of the micro eNB are: • •

providing a high mobile data capacity in the serving area, which displays a large demand for mobile data providing coverage in an unserved area within the existing eNB cell

Figure 14

Example of Flexi Zone Outdoor Micro BTS (micro eNB)

The Flexi Zone Micro is available in many variants. The picture presented may serve as an example.

2.4.4 Flexi Zone Pico BTS (pico eNB) The Flexi Zone Pico BTS (pico eNB); the indoor solution. The pico eNB has been created to enhance the macro LTE network (for example, it helps to cover a large demand for mobile data in a specific area).

Issue: 02B

DN0993921

31



Flexi Zone Pico BTS (pico eNB) is part of the Nokia's second generation of LTE BTS; the small cell BTS is optimized for an indoor micro-cell environment. The design of the Flexi Zone Pico BTS is based on the Flexi Multiradio BTS platform. Most of the functions of this element are the same as a traditional eNB's; they are discussed in the Flexi Multiradio BTS LTE (macro eNB) section. The main role of the pico eNB are: • •

providing a high mobile data capacity in the serving area, which displays a large demand for mobile data providing coverage in an unserved area within the existing eNB cell

Figure 15

Example of Flexi Zone Indoor Pico BTS (pico eNB)

Bottom

Front

Slide

Back

The Flexi Zone Pico BTS is available in many variants. The picture presented may serve as an example.

2.4.5 Flexi Network Server (Flexi NS) The MME functionality is provided by the Flexi NS, which is a high transaction capacity product based on the AdvancedTCA (ATCA) standard. It is optimized for a flat all-IP architecture. Flexi Network Server (Flexi NS) is a high transaction capacity product on top of the AdvancedTCA (ATCA) hardware (see Figure 16: Flexi Network Server). It is optimized for all-IP flat architecture and used for the control-plane-only mobility management entity (MME) functionality. Flexi NS is an essential part of the LTE and EPS end-to-end offering. The MME has a similar role in LTE as 2G/3G SGSN does in 2G/3G networks. Flexi NS implements high transaction and connectivity capacity to accommodate the increased signaling load and higher service penetration in an operators’ subscriber base. The product footprint is small, so you can install up to three high capacity units in a standard 19” rack. Flexi NS is power efficient, offering reduction in energy consumption.

32

DN0993921

Issue: 02B



Innovative control-plane-only architecture of Flexi NS allows implementing session redundancy within a single Flexi NS network element. In case of a failure of any single hardware unit, the subscriber session can be preserved. SGSN has demonstrated market leading reliability levels in live networks over a time period of several years. The same DMX software platform is applied also as a basis for the Flexi NS. Flexi NS can be used as an SGSN, as an MME, or as an SGSN/MME in the networks. Figure 16

Flexi Network Server

External interfaces of the Flexi Network Server The external interfaces of the Flexi Network Server are fully described in Flexi Network Server Operating Documentation (see Flexi Network Server, Operating Documentation in NOLS).

2.4.6 Flexi Network Gateway (Flexi NG) The S-GW/P-GW functionality is provided by the Flexi Network Gateway (Flexi NG), which is based on the ATCA hardware platform and Flexi Platform operating software and middleware. The Flexi NG product targets current and future mobile networks. It supports a variety of access network types, including long-term evolution (LTE), high-speed packet access (HSPA), evolved high-speed packet access (HSPA+), 2G/3G GPRS access, WLAN access, internet high-speed packet access (I-HSPA), and a direct tunnel. Different applications such as the serving gateway (S-GW), packet data network gateway (P-GW), or the gateway GPRS support node (GGSN) can be installed on the same hardware, using the same software. Flexi NG provides excellent throughput and signaling capacity to accommodate the traffic growth in the next generation networks. The key to Flexi NG's performance is in the use of multi-core packet processor (MPP) technology in the control plane and the

Issue: 02B

DN0993921

33



user plane. MPPs are designed for fast networking applications and contain several hardware units that accelerate packet data processing. The MPP technology is highly flexible and scalable, and enables faster development cycles. The use of the MPP technology also allows, for example, changes between signaling and the user plane's processing capacity. The high availability options, available in Flexi NG, enable 99.999% reliability at different redundancy levels, including session continuity through the use of session replication in active-standby service blade pairs. Flexi NG is based on the AdvancedTCA (ATCA) hardware platform (see Figure 17: Flexi NG) and Flexi Platform operating software and middleware. Flexi Platform is a robust, carrier grade Linux-based platform, offering versatile services for operation and maintenance (O&M), networking and platform services using the latest technologies available. Figure 17

Flexi NG

External interfaces of the Flexi NG The external interfaces of Flexi NG are fully described in Flexi Network Gateway Operating Documentation (see Flexi NG, Operating Documentation in NOLS).

2.5 LTE/SAE interfaces Figure 18: EPS architectureFigure 19: EPS architecture presents the overall evolved packet system (EPS) architecture, not only including the evolved packet core (EPC) and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), but also other elements, to show the relationship between them.

34

DN0993921

Issue: 02B


Figure 18


EPS architecture

LTE_Uu

S1

S5/S8a

EUTRAN

EPC S1-U S1-MME

MME

eNB S11 X2

S10 S11

P-GW

S-GW MME

S1-MME S1-U

eNB

Figure 19

EPS architecture

LTE_Uu

S1

S5/S8a EPC

EUTRAN S1-U

S1-MME

eNB

S-GW

S11

X2

MME S1-MME

P-GW

S1-MME

micro/pico

S11

S1-U

X2 eNB S1-U

S10

S11

S-GW

S1-MME

FZC

MME Z1

Z1

Z1

FZAP FZAP

FZAP ZoneeNB FlexiZoneAccess PointsCluster

Interfaces shown in Figure 18: EPS architectureFigure 19: EPS architecture are logical interfaces; they have no close relation to the physical network structure and transmission. The connectivity between nodes is handled by an IP network. Interfaces are divided into radio network interfaces (including LTE-Uu, S1, and X2 interfaces) and core network interfaces.

Issue: 02B

DN0993921

35



2.5.1 Radio network interfaces 2.5.1.1

LTE-Uu interface The LTE UMTS air interface (that is, LTE-Uu interface) is the radio interface between the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and the user equipment (UE). The Uu interface ensures the communication between an eNB and the UE. It comprises the control plane (C-plane) for signaling and the user plane (U-plane) for the transfer of user data. The Uu interface is needed to set up, reconfigure, and release radio bearer services including the LTE frequency division duplex (FDD) and LTE time division duplex (TDD) services. For more information on the Uu interface protocol stack, see Protocol stacks.

2.5.1.2

S1 interface The S1 interface connects the E-UTRAN to the core network (CN). It is specified as an open interface that divides the system into radio-specific E-UTRAN and evolved packet core (EPC) which handles switching, routing, and service control. The S1 interface has two different instances: • •

S1-U (S1 user plane) for connecting the eNB and the serving gateway (S-GW) S1-MME (S1 control plane) for connecting the eNB and the mobility management entity (MME)

The following functions are supported over S1-MME and S1-U to fulfill the S1 interface capabilities: •

•

•

S1 UE context management function, which supports the establishment of the necessary overall initial UE context including E-RAB context, security context, roaming restriction, UE S1 signaling connection IDs, in the eNB to enable fast idle-toactive transition. E-RAB management functions are responsible for establishing, modifying, and releasing E-UTRAN resources for user data transport once a UE context is available in the eNB. The establishment and modification of E-UTRAN resources are triggered by the MME and require respective QoS information to be provided to the eNB. The release of E-UTRAN resources is triggered by the MME either directly or following a request received from the eNB (optional). S1 link management function –

–

•

Mobility functions for UEs in LTE_Active –

36

GTP-U tunnels management function This function is used to establish and release GTP-U tunnels between the EPC and the E-UTRAN upon an E-RAB service request. This involves assigning a tunnel identifier for each direction. S1 signaling link management function The S1 signaling link management function provides a reliable transfer of the radio network signaling between E-UTRAN and EPC.

Intra-LTE handover This function supports mobility for UEs in LTE_ACTIVE and comprises the preparation, execution, and completion of handover via the X2 and S1 interfaces.

DN0993921

Issue: 02B


–

–

•

•

• • • • • •


Inter-3GPP-RAT handover This function supports mobility to and from other 3GPP-RATs for UEs in LTE_ACTIVE and comprises the preparation, execution, and completion of handover via the S1 interface. Mobility to CDMA2000 system This function supports mobility to and from other non-3GPP radio technologies for UEs in LTE_ACTIVE, namely to and from the CDMA2000 systems.

Paging function enables sending paging requests to the eNBs having one or more cells which correspond to one of the tracking areas (TAs) in which the UE is registered. Roaming and area restriction support functions The S1 interface enables transferring restriction information from the EPC to the eNB in terms of restricted TAs for the UE in the network. S1 interface management function Coordination functions Security function Service and network access function UE tracing function which allows tracing various events related to the UE and its activities; this is an O&M functionality RAN information management function

For more information on the Uu interface protocol stack, see Protocol stacks.

2.5.1.3

X2 interface The X2 interface is used to logically connect two eNBs within the E-UTRAN. It is specified as an open interface in order to facilitate: • • •

Inter-connection of eNBs supplied by different manufacturers Support of continuation between eNBs of the E-UTRAN services offered via the S1 interface Separation of the X2 interface radio network functionality and the transport network functionality to facilitate the introduction of future technologies

The main functions of the X2 interface are: •

Intra-LTE-access-system mobility support for a UE in LTE_ACTIVE allows the eNB to hand over the control of a certain UE to another eNB. –

–

–

•

Issue: 02B

Context transfer from a source eNB to a target eNB allows transferring information required to maintain the E-UTRAN services for a UE in LTE_ACTIVE from a source to target eNB. Control of user plane tunnels between a source eNB and a target eNB allows establishing and releasing tunnels between a source and target eNB to allow data forwarding. Handover cancellation allows informing an already prepared target eNB that a prepared handover will not take place. It allows releasing the resources allocated during a preparation.

Load management allows exchanging overload and traffic load information between eNBs so that the eNBs can control the traffic load appropriately.

DN0993921

37


•


Inter-cell interference coordination allows keeping inter-cell interference under control. For this, neighboring eNBs exchange appropriate information allowing those eNBs to make radio resource assignments to mitigate the interference. –

–

•

•

•

Uplink interference load management allows indicating an uplink interference overload and resource blocks especially sensitive to inter-cell interference between neighboring eNBs so that neighbor eNBs can co-ordinate with each other such that the mutual interference caused by their uplink radio resource allocations is mitigated. Downlink interference avoidance allows an eNB to inform its neighbor eNBs about downlink power restrictions in its own cells, per resource block for interference aware scheduling by the neighbor eNBs.

General X2 management and error handling functions allow managing signaling associations between eNBs, surveying the X2 interface, and recovering from errors. Error indication allows reporting general error situations at the level of applications. Trace recording sessions on E-UTRAN interfaces for a particular UE are initiated by the EPC. The trace initiation information is also propagated to the target eNB during a handover, attached to a certain handover messages on X2. Application level data exchange between eNBs. This function allows two eNBs to exchange application level data when an X2 connection is set up and to update this information at any time.

2.5.2 Core network interfaces The evolved packet core (EPC) architecture is compliant with 3GPP specifications [TS23.401] and [TS23.402]. The EPC network architecture is composed of the following main elements compliant with 3GPP Release 8 specifications and with open interfaces: • • •

Mobility management entity (MME) Serving gateway (S-GW) Packet data network gateway (P-GW)

The LTE/EPC architecture portfolio comprises the following network elements: • •

Flexi Network Server - MME Flexi Network Gateway (Flexi NG)

All core interfaces are supported either by Flexi Network Server–MME or Flexi NG. For a detailed description of all supported interfaces, see Flexi Network Server–MME or Flexi NG in NOLS.

2.6 Protocol stacks The protocol stacks examples for the control and user plane of the most important reference points of the LTE/EPC system.

2.6.1 Radio protocol architecture Uu user plane protocol stack

38

DN0993921

Issue: 02B


Figure 20


Uu user plane protocol stack

UE

eNB

S-GW

IP

IP

PDCP

PDCP

GTP-U

GTP-U

RLC

RLC

UDP

UDP

MAC

MAC

IP

IP

PHY

PHY

L1/L2

L1/L2

LTE-Uu

S1-U

The radio bearer is responsible for transporting data between a UE and eNB over the LTE-Uu interface, using the PDCP protocol (see Figure 20: Uu user plane protocol stack). 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 21: U-plane operation of PDCP and RLC illustrates the processing performed on packets within PDCP and RLC. Figure 21

U-plane operation of PDCP and RLC

UE/E-UTRAN

RadioInterface(Uu)

Transmitting PDCP entity PDCP

E-UTRAN/UE

Receiving PDCP entity PDCP

Sequencenumbering

HeaderCompression(u-planeonly)

Inorderdeliveryandduplicatedetection

HeaderDecompression(u-planeonly)

U-PlaneSecurity

U-PlaneSecurity

Deciphering

Ciphering

RemovePDCPheader

AddPDCPheader Transmitting RLCentity RLC

SAP

SAP

Receiving RLCentity RLC

TransmissionBuffer

SDUreassembly

SegmentationandConcatenation

RemoveRLCheader

AddRLCheader

ReceptionbufferandHARQreordering

FromMACLayer

ToMACLayer

For U-plane traffic, the PDCP layer is responsible for:

Issue: 02B

DN0993921

39


• • • • • •


management and assignment of PDCP sequence numbers that are attached to packets in-sequence delivery of upper layer service data units (SDUs) during an inter-eNB handover via the X2 interface, using the PDCP detection and elimination of duplicate lower layer SDUs during an inter-eNB handover via the X2 interface 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 an inter-eNB handover via the X2 interface

The RLC layer is responsible for: •

• •

segmentation and re-assembly of RLC SDUs into RLC PDUs, whose size matches 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 have been successfully delivered to the receiver.

The S1-U bearer is used for transport of user data between an eNB and S-GW over the S1-U, using the GTP-U protocol (see Figure 20: Uu user plane protocol stack). Each S1U 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. Uu control plane protocol stack Figure 22

Uu control plane protocol stack

UE

eNB

MME NAS

NAS RRC

RRC

PDCP

PDCP

RLC

RLC

MAC

MAC

IP

IP

PHY

PHY

L1/L2

L1/L2

S1-AP

S1-AP

SCTP

SCTP

LTE-Uu

S1-MME

The RRC protocol (eNB <> UE) [TS36.331] is responsible for transferring 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: • • • • • • • • •

40

AS signaling connection control Radio bearer control signaling Mobility handling UE measurement UE power control UE security signaling Transport of NAS messages Distribution of cell and system information broadcast Distribution of paging signaling

DN0993921

Issue: 02B


Figure 23


C-plane operation of PDCP

To/From RRC RRCMessage Sequence Numbering/Packet Reordering

PDCP PDCP SN

RRCMessage

IntegrityProtection PDCP SN

RRCMessage

MAC* C-PlaneCiphering

RLCSDU(Ciphered+IntegrityProtected) To/from MAC RRC signaling is transported over the LTE-Uu interface using the Packet Data Convergence Protocol (PDCP) and the radio link control (RLC) protocol in a similar way to U-plane data. This is illustrated in Figure 23: C-plane operation of PDCP. Note that MAC* is the message authentication code added by integrity protection in PDCP, and ciphering is optional. For more details on RLC, see Figure 21: U-plane operation of PDCP and RLC. For C-plane signaling, the PDCP layer is responsible for: • • •

maintenance and assignment of PDCP sequence numbers that are attached to packets application of C-plane integrity protection application of C-plane ciphering

The S1AP protocol (eNB <> MME) [TS36.413] is responsible for transferring signaling information between the eNB and MME over the S1-MME interface. The LTE440: S1 Overload Handling feature introduces a mechanism designed to prevent network congestion in case of an S1-MME link overload. If an MME is in an overload state, it indicates its condition to either all or a randomly selected number of its eNBs. These eNBs are instructed to reject connection establishment requests that require interaction with the MME. Such behavior allows to lower the packet rate on the overloaded S1-MME link. S1AP is carried using the Stream Control Transmission Protocol (SCTP) [RFC 4960]. It is used for: •

Issue: 02B

QoS bearer management (activation, modification, and aeactivation of EPS bearers)

DN0993921

41


• • • • • • • •


UE context management (release, modification) Paging distribution signaling Mobility signaling Security mode signaling S1 interface management (setup, reset, reset resource, overload and error indication) Tracking area control signaling Trace configuration signaling Transport of NAS messages

NAS signaling protocols (MME <> UE) 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 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 protocols. 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

2.6.2 EPS protocol architecture S1-U user plane protocol stack Figure 24

S1-U user plane protocol stack

UE

eNB

S-GW

IP

IP

PDCP

PDCP

GTP-U

GTP-U

RLC

RLC

UDP

UDP

MAC

MAC

IP

IP

PHY

PHY

L1/L2

L1/L2

LTE-Uu

S1-U

X2 user plane protocol stack Figure 25

X2 user plane protocol stack

eNB

eNB

GTP-U

GTP-U

UDP

UDP

IP

IP

L1/L2

L1/L2 X2

42

DN0993921

Issue: 02B



From a U-plane's perspective, the X2 interface is used for forwarding user data between the source eNB and target eNB during a lossless inter-eNB handover. A GTP-U tunnel is established across the X2 interface between the source eNB and the target eNB. Thus, the protocol stack is the same as that over the S1-U. The source eNB forwards all outstanding downlink PDCP SDUs and still incoming S1 downlink SDUs in the original sequence to the target eNB via the X2 GTP-U tunnel. The target eNB will start to transmit downlink user data received at S1 in the usual way after all forwarded data has been transmitted. Any uplink PDCP SDUs received in sequence by the source eNB are forwarded directly to the S-GW in the normal manner, but any uplink PDCP SDUs received by the source eNB out of sequence will be discarded (the UE will retransmit them). S5/S8 user plane protocol stack (GTP variant) Figure 26

S5/S8 user plane protocol stack (GTP variant)

S-GW

P-GW

GTP-U

GTP-U

UDP

UDP

IP

IP

L1/L2

L1/L2 S5/S8

S5/S8 user plane protocol stack (IETF variant) Figure 27

S5/S8 user plane protocol stack (IETF variant)

S-GW

P-GW

Tunneling layer

Tunneling layer

IPv4/IPv6

IPv4/IPv6

L1/L2

L1/L2 S5/S8

S1-MME control plane protocol stack Figure 28

S1-MME control plane protocol stack

UE

eNB

MME NAS

NAS RRC

RRC

PDCP

PDCP

S1-AP

S1-AP

RLC

RLC

SCTP

SCTP

MAC

MAC

IP

IP

PHY

PHY

L1/L2

L1/L2

LTE-Uu

S1-MME

X2 control plane protocol stack

Issue: 02B

DN0993921

43



Figure 29

X2 control plane protocol stack

eNB

eNB

X2-AP

X2-AP

SCTP

SCTP

IP

IP

L1/L2

L1/L2 X2

The X2 interface is used during handovers and to exchange cell/eNB-specific information between the eNBs. IPSec is contained within the IP part of the protocol stack. LTE uses the IPSec tunnel mode. For QoS provision in the IPSec tunnel mode, the DiffServ code point (DSCP) is available in plain text in the outer IP header. NAS messages are not transferred between eNBs during a handover; therefore, there is no need for NAS in the X2 protocol stack. The X2AP protocol (eNB <> eNB) [TS36.423] is responsible for transferring signaling information between neighboring eNBs over the X2 interface. X2AP is carried using SCTP. This signaling is used for handover signaling, inter-cell RRM signaling, and X2 interface management (setup, reset, reset resource, and error indication). The X2 eNB configuration update functionality allows the eNB to send and receive updated configuration information without the need for an X2 link re-establishment when application-level configuration information transmitted during the establishment of an X2 link has changed. S5/S8 control plane protocol stack (GTP variant) Figure 30

S5/S8 control plane protocol stack (GTP variant)

S-GW

P-GW

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S5/S8

S5/S8 control plane protocol stack (IETF variant) Figure 31

S5/S8 control plane protocol stack (IETF variant)

S-GW

P-GW

PMIPv6

PMIPv6

IPv4/IPv6

IPv4/IPv6

L1/L2

L1/L2 S5/S8

S10 control plane protocol stack

44

DN0993921

Issue: 02B


Figure 32



MME

MME

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S10

S11 control plane protocol stack Figure 33


S-GW

MME

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S11

S6a control plane protocol stack Figure 34

S6a control plane protocol stack

MME

HSS

DIAMETER

DIAMETER

SCTP

SCTP

IP

IP

L1/L2

L1/L2 S6a



MME

EIR

DIAMETER

DIAMETER

SCTP

SCTP

IP

IP

L1/L2

L1/L2 S13

SBc control plane protocol stack Figure 36

SBc control plane protocol stack

eNB

MME

CBC

Interworking S1-AP

S1-AP

SBc-AP

SBc-AP

STCP

STCP

STCP

STCP

IP

IP

IP

IP

L1/L2

L1/L2

L1/L2

L1/L2

S1-MME

Issue: 02B

SBc

DN0993921

45



2.6.3 Protocol architecture for interfaces for legacy 3GPP interworking S4 user plane protocol stack Figure 37

S4 user plane protocol stack

S-GW

SGSN

GTP-U

GTP-U

UDP

UDP

IP

IP

L1/L2

L1/L2 S4

S12 user plane protocol stack Figure 38

S12 user plane protocol stack

S-GW

UTRAN

GTP-U

GTP-U

UDP

UDP

IP

IP

L1/L2

L1/L2 S12



MME

SGSN

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S3



S-GW

SGSN

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S4

46

DN0993921

Issue: 02B



2.7 LTE multiple access radio interface (FDD) The LTE radio interface, as specified in [3GPP TS 36.101] for the UE and in [3GPP TS 36.104] for the eNB, supports both the FDD and TDD mode, each with their own frame structures. The FDD LTE multiple access is based on OFDMA in the downlink direction (see OFDMA principles) and SC-FDMA in the uplink direction (see SC-FDMA principles). Different technologies for uplink and downlink The main benefits of each technology are summarized in Table 2: Benefits of OFDMA and SC-FDMA. Table 2

Benefits of OFDMA and SC-FDMA

Downlink: OFDMA •

improved spectral efficiency

•

reduced interference

•

very well suited for MIMO

Uplink: SC-FDMA

•

power-efficient uplink which increases battery lifetime improved cell-edge performance

•

reduced terminal complexity

•

Modulation schemes for uplink and downlink The different modulation schemes of OFDMA and SC-FDMA are illustrated in Figure 41: OFDMA and SC-FDMA modulation schemes. 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 major 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 SC-FDMA signal appears to be more like a single-carrier with each data symbol being represented by one wide signal.

Issue: 02B

DN0993921

47



Figure 41 Q

-1,1

OFDMA and SC-FDMA modulation schemes 1,1

1,1

-1,-1

-1,1

1,-1

-1,-1

1,-1

1,1

-1,1

I SequenceofQPSKdatasymbolstobetransmitted 1,-1

-1,-1

er ow rp MA rr ie FD ca C- d ub S rio s h n t ac p e ta g e bol s n in m Co dur sy

QPSKmodulating datasymbols

V SC sy -F m DM bo A l

O sy FD m M bo A l

V

e Ti m

Ti m fc

Frequency

15kHz

SC sy -F m DM bo A l

CP

O sy FD m M bo A l

e

CP

Frequency

60kHz

fc

OFDMA

SC-FDMA

Datasymbolsoccupy15kHzfor oneOFDMA symbolperiod

DatasymbolsoccupyM*15kHzfor 1/MSC-FDMA symbolperiods

Signal generation and reception OFDMA and SC-FDMA partly share the same signal generation and reception steps. Different from OFDMA, SC-FDMA begins with a special precoding process from the time domain to the frequency domain but then continues in a manner similar to OFDMA, as illustrated in Figure 42: OFDMA and SC-FDMA signal generation and reception (simplified model). After that, an IDFT is performed to convert the frequency-shifted signal to the time domain and cyclic prefix (CP) is inserted to provide fundamental robustness of OFDMA against the multipath. Figure 42

OFDMA and SC-FDMA signal generation and reception (simplified model)

UniquetoSC-FDMA

Mdata bitsin

Mapdatato constellation

Generate timedomain waveform

Timedomain

Mdata bits out

De-map constellation todata

Generate constellation

CommonwithOFDMA

Perform M-pointDFT (timetofreq)

Map symbolsto subcarriers

Perform N-pointIFFT N>M

Frequencydomain Perform M-pointIDFT (freqtotime)

De-map subcarriers tosymbols

Upconvert andtransmit

Timedomain Perform N-pointDFT N>M

Receiveand downconvert

Key components of the LTE radio interface In addition to the OFDMA and SC-FDMA concepts there are the following key components of the LTE radio interface: • • • •

48

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 conventional convolutional coder. LTE Rel-8 supports multi antenna schemes for MIMO and TX diversity. For details, see Multi-antenna techniques. Inter-cell interference coordination and interference cancellation enable exploiting multi antenna configurations. For details see Interference mitigation.

DN0993921

Issue: 02B


•

•


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. With LTE46: Channel Aware Scheduler (UL) feature, the scheduling criterion in the frequency domain is defined by the relative signal strength. Additionally the UL scheduler takes into account the number of assigned PRBs for the calculation of the scheduling criterion. 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.7.1 OFDM concept OFDM makes use of a large number of closely spaced orthogonal subcarriers that are transmitted in parallel, rather than to transmit a high-rate stream of data with a single carrier. 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 thousands 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 a very high spectral efficiency allows 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 multipath propagation (thereby establishing orthogonality in the time domain) benefit from simplified equalization and simplified channel estimation in the frequency 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 multipath delay spread in the radio channel.

Issue: 02B

DN0993921

49



Figure 43

Orthogonal frequency division multiplex principle Availablebandwidth Sub-carriers

... OFDM symbols

Frequency

...

Guard intervals

Time

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.7.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 orthogonal 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 narrowband 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 LTE the downlink OFDMA is used, 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 44: OFDM and OFDMA subcarrier allocation. As a fundamental principle of E-UTRA, the data channels are shared channels, that is, for each transmission time interval, a new scheduling 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 because of the trunking efficiency of multiplexing low rate users and the ability to schedule users by frequency, which provides resistance to multipath fading.

50

DN0993921

Issue: 02B


Figure 44


OFDM and OFDMA subcarrier allocation Subcarriers

Subcarriers

User2 User3

Symbols(Time)

Symbols(Time)

User1

OFDM

OFDMA

Note that not all of Physical Resource Blocks (PRBs) can be allocated to users, because some of PRBs are reserved for synchronization and common channels.

2.7.3 SC-FDMA principles The E-UTRA system uses Single Carrier Frequency Division Multiple Access (SCFDMA) for the Uplink, which combines the low Peak-to-Average Power Ratio (PAPR) techniques of single-carrier transmission systems, such as GSM and CDMA, with the multipath resistance and flexible frequency allocation of OFDMA. The single carrier signal has a PAPR that is about 4 dB lower than a corresponding OFDM signal; this extends the UE battery life time. Thanks to transform precoding, each UE creates a single carrier signal. As illustrated in Figure 45: DFT pre-coding and principle of SC-FDMA, data symbols in the time domain are converted to the frequency 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 converted back to the time domain using an inverse FFT (IFFT). Finally, the CP is inserted. Figure 45

UEdata after modulation mapping

DFT pre-coding and principle of SC-FDMA

Q-point DFT Q

Add 0s

NFTT-point IFFT (NFTT ≥ Q)

CP Add

RF Gen

Q-pointDFT (TransformPre-coding) ResultsinSingle-CarrierFDMA: SystemBW

Issue: 02B

DN0993921

51



2.8 LTE radio protocol architecture The LTE UMTS air interface (LTE-Uu interface) is the radio interface between the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and the User Equipment (UE). The Uu interface adopts the communication between eNB and the UE. It comprises the Control Plane (C-plane) for signaling and the User Plane (U-plane) for the transfer of user data. The Uu interface is needed to set up, reconfigure, and release radio bearer services including the LTE Frequency Division Duplex (FDD) service. 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. Physical downlink control channel (PDCCH) Informs the UE about the resource allocation. 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/NACKs 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 46: Mapping of physical, transport and logical channels.

52

DN0993921

Issue: 02B


Figure 46


Mapping of physical, transport and logical channels

DL LogicalChannel

BCCH CCCH DTCH

DL TransportChannel

BCH

DL PhysicalChannel

DCCH

DL-SCH

PACH

UL LogicalChannel

PCCH

PCH

PDSCH

DTCH

UL TransportChannel

RACH

UL-SCH

UL PhysicalChannel

PRACH

PUSCH

PDCCH

DCCH

PCFICH

PHICH

CCCH

PUCCH

2.9 Multi-antenna techniques Overview of an example of multi-antenna options in LTE. A key ingredient of the LTE air interface is the Multiple-Input Multiple-Output (MIMO) support to achieve the ambitious requirements for throughput and spectral efficiency. 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 the 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 used. Table 3: Multiantenna options in LTE provides an overview of an example of LTE multi-antenna configurations. Table 3

Multi-antenna options in LTE

DL

BS

UE

TX

RX

1x2

1

2

2x2

2

2

UL

Gain to smaller configuration

+ 4 ... 5 dB DL link budget

UE

BS

TX

RX

Configuration type


1x2

1

2

minimum

1x2

1

2

standard

+ 100% peak data rate

Issue: 02B

DN0993921

53


Table 3


Multi-antenna options in LTE (Cont.)

DL

BS

UE

TX

RX

UL


UE

BS

TX

RX

Configuration type


+ user experience + 20% spectrum efficiency 4x2

4

2

+ 3 ... 4 dB DL link budget

1x4

1

4

+ moderate capacity gains

+ 3 .. 4 dB UL link budget

high-performance

+ user experience + 50% spectrum efficiency

4x4

4

4

+ 100% peak data rate

1x4

1

4

high-performance

+ user experience + 50% spectrum efficiency

The “standard” configuration at the LTE base station is strongly recommended. In addition to two RX antennas (RX diversity), it also provides two 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 one TX. In a “high performance” scenario, one 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 to avoid combing losses. Typically, the LTE UE has two RX antennas and one TX chain. The Centralized RAN can be used to mitigate UL interferences impact on UL performance and finally to improve UL average cell throughput potentially up to 100% (compared to 2-Rx single cell MRC) in case of stadium type mass events and dense RRH/RFM deployments.

2.9.1 Receive diversity Two-branch (2Rx) and four-branch (4Rx) receive diversity is supported and based on Maximum Ratio Combining (MRC). MRC means to combine the two (or four) 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. Receive diversity with two receive branches requires two uncorrelated receive antennas using a single cross-polar antenna or two vertically polarized spatially separated antennas; four-branch receive diversity requires four uncorrelated receive antennas using for example two spatially separated cross-polar antennas. Alternatively, 4 partially uncorrelating receiver antennas may be applied, for example, two closely spaced cross-polar antennas. Such a choice may be motivated for example because of desired four-transmit-antenna behavior, or because of mechanical integration inside one radome.

54

DN0993921

Issue: 02B



Receive diversity is compliant with LTE Rel-8 terminals and supported on all Uplink channels. Besides traditional MRC, Interference Rejection Combining (IRC) receiver is also implemented in UL. The IRC receiver provides a better performance than an MRC-based receiver in case of medium or high interference. The IRC algorithm supports different RX configurations: two RX, four RX, or eight RX (in future).

2.9.2 Transmit diversity LTE solution supports four-branch Single Stream Downlink 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 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 two branches and by 6 dB for four branches. This yields both 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 DRXVoIP users, however, transmit diversity slightly enhances cell capacity by approximately 5% for two transmit branches. Transmit diversity with up to four 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.9.3 MIMO techniques The typical MIMO configuration encompassing Dual-Codeword 2x2 DL Single-User (SU) MIMO Spatial Multiplexing is illustrated in Figure 47: 2x2 MIMO configuration. This MIMO scheme targets at a duplication of the Downlink peak user data rate by allowing two independent parallel data streams to a single UE. This is also called Spatial Multiplexing. The two base station transmit signals, two UE receive signals, and four channels form (for each and every subcarrier) a system of two equations with two unknown transmit signals. The two unknown transmit signals can be calculated from the estimated four channels, the possible transmit alphabet(s), and the two receive signals.

Issue: 02B

DN0993921

55



Figure 47

2x2 MIMO configuration

TXantennas

Channel(s)

RXantennas

H1,1 X1 Data

H2,1

Y1

TX

RX

Data

H1,2 X2

Y2 H2,2 A

k: kkkkk

Y 11,111,22 =HX+HX

kkkkk

Y 22,112,22 =HX+HX

Whether or not two 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 two data streams decorrelate. Decorrelation of the channels strongly depends on the antenna characteristics. Antennas are uncorrelated if they: • • •

are spatially separated by about ten or more wavelengths use orthogonal polarization planes (cross-polarity) 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 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 to fall back to Transmit Diversity. In case of Closed Loop SU-MIMO Spatial Multiplexing, UE feedback is required. Mapping of data to the transmit antenna ports follows the Codebook entry recommended 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 a fallback to Transmit Diversity. MIMO techniques comprise the following: • •

56

Downlink MIMO techniques Multi-user MIMO techniques

DN0993921

Issue: 02B


2.9.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 (statically) configure Transmit Diversity, MIMO Spatial Multiplexing, or adaptive mode. In 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 Transmit Diversity, MIMO Spatial Multiplexing, or adaptive mode. In 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 macrocellular to 40% for micro-cellular deployment scenarios. Closed Loop SU-MIMO is wellsuited 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 two to four 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.9.3.2

Multi-user MIMO techniques The uplink Multi-User MIMO means that two different UEs exploit the same physical Uplink air interface resources. Uplink MU-MIMO is supported in the 3GPP standard LTE Rel-8. The uplink MU MIMO is a capacity enhancement feature effective for loaded networks. For evaluation purposes, a Proportional Fair scheduler and a frequency-selective MIMO scheduler have been compared, indicating various performance gains achievable with two or four receive antennas. Results are better for higher system loads, as an advanced eNB receiver can exploit best Uplink MU MIMO if there are sufficient appropriate pairings of UEs. An initial implementation of the Uplink MU MIMO scheduler starts from semistatic pairing of UEs to allow for smooth integration with Hybrid Automatic Repeat Request (HARQ) processing. The uplink multi-user MIMO functionality improves the spectral efficiency by up to 10~20%.

2.9.4 The uplink intra-eNB Coordinated Multipoint (CoMP) With the LTE1691: Uplink intra-eNB CoMP 4Rx feature, the LTE supports uplink intraeNB CoMP that is applied in the eNB for cells with 4Rx paths. The eNB selects automatically, per UE and per TTI, the most suitable neighbor cell out of the CoMP set. The selection of the neighbor cell for the joint reception is based on uplink SINR measurement before combining. The CoMP set, consisting of neighbor cells

Issue: 02B

DN0993921

57



considered for selection, is operator-configurable. It is possible to have either 4Rx CoMP sets or 2Rx CoMP sets (as introduced in the LTE1402: Uplink Intra-eNB CoMP feature) in the same eNB. Mixing two types of CoMP sets is not supported. This feature is supported with 4Rx antennas in a cell, and the operator configures the UL CoMP set consisting of a maximum of three cells. This means that one cell, belonging to the UL CoMP set, monitors up to 12Rx antennas. From these 12Rx antennas, the eNB can use two sets of 4Rx antennas (one set of antennas from the serving cell and another set from one of the cells in the UL CoMP set), depending on the measured SINR in the neighbor cells. The uplink intra-eNB CoMP improves the average cell throughput and the cell edge performance by considering uplink information from neighbor cells' antennas.

2.10 Radio network optimization Nokia has extensive 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 (that is Antenna Tilting/Azimuth, Tx Power, Frequency Reuse), plus specific parameters related to advanced features like PF Scheduler, Interference Coordination. Nokia 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 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 downtilting Flexi BTS configuration parameters

The Flexi Multiradio BTS supports an uplink coverage improvement algorithm as an extension to the uplink link adaptation. The coverage extension is achieved by controlling the uplink packet segmentation. This leads to an improvement of the coverage throughput; also PDCCH is more optimally utilized as a result of balancing new transmissions and retransmissions. The enhancement in coverage throughput comes at the cost of cell throughput. For a given modulation code scheme (MCS) as determined by the uplink link adaptation and configured transport block size (TBS), the uplink scheduler determines the PRB allocation. 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.

58

DN0993921

Issue: 02B



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

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 downtilting 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 maximizing the signal strength at the receiver without taking into account the strong cochannel 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.11 Interference mitigation Interference mitigation for up to four receiving 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. In a dense radio deployment, it is difficult to manage interference. The UEs' antennas radiate 360 degrees, causing interference in neighbor cells. When the CRAN is in use, the harmful interference is transferred into useful traffic by introducing intelligent cooperative cells that are formed across the interconnected eNBs. The eNB with the serving cell uses IRC algorithm to combine the Physical Uplink Shared Channel (PUSCH) signals in such a way that the overall post-equalizer signal to interference and noise ratio is maximized. Based on the IRC algorithm, the feature selects eight paths (out of 12) for the UL joint PUSCH reception. In this procedure, the paths having the best SINR ratios are selected to get the optimal UL transmission path. For more information on the CRAN functionality and the interference, see the LTE1900: Centralized RAN feature description.

Issue: 02B

DN0993921

59



2.12 RAN sharing The operators are able to share the resources of a single Flexi Multiradio BTS. This means that the operators can reduce CAPEX and OPEX. In this solution both operators share: • • • • • •

system module RF module parametrization NetAct transport I/F: physical S1 and X2 interface RF feeder line

The Flexi Multiradio BTS can be connected simultaneously to different EPCs of different operators - Public Land Mobile Networks (PLMNs). This is done via the S1 Flex mechanism which allows eNB establishing multiple S1 links. For each eNB cell, the operator provides a list of PLMN identities that are supported by this eNB cell. The first element of this list is always equal to the eNB primary PLMN ID. The eNB is able to provide services to UEs only if the configured PLMN ID is also supported by at least one MME with an available S1 link. If the S1 link becomes unavailable (for example, because of transport network layer problems), it might happen that not all PLMN IDs configured by the operator for an eNB cell are also supported on the S1 interface. The eNB broadcasts only those PLMN IDs, which are supported also on S1 interface (list of PLMN IDs supported by EPC) to avoid service degradation for the subscriber. During the UE connection establishment, eNB selects MME from the set of active MMEs. The choice is based on: • • •

60

PLMN IDs (MME support of PLMNs, which UE wants to connect to) registered MME value (available if the UE has already registered with a MME) S-Temporary Mobile Subscriber Identity (S-TMSI)

DN0993921

Issue: 02B


Figure 48


Operator modules in RAN sharing RFFeederLine A +B

PLM

NA

,B

RFModuleOperator A+B RFModuleOperator A+B SystemModuleOperator A+B

S1Operator A S1OperatorB

Issue: 02B

DN0993921

61


Figure 49


RAN sharing architecture SGi S1

MME

IMS Operator A

S-GW

X2

P-GW

PDN PublicIP Services

MME OperatorB S-GW

P-GW

IMS

X2

MME OperatorC S-GW

P-GW

IMS

For Inter-RAT mobility, it is assumed 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 configuration for the two operators will be visible in the different configuration of the S1 interfaces. With LTE505: Transport Separation for RAN Sharing, operators which share the RAN can distinguish within the transport network the S1 traffic (U-plane and C-plane) of the different operators. In other words, independent transport network configuration is possible. The eNB supports two U-plane IP addresses and two C-plane IP addresses.

2.13 Single RAN introduction Single RAN solution consists of multipurpose hardware. It is able to support GSM, WCDMA, LTE FDD and TDD just by SW update. The Single RAN solution aims at reducing the amount of equipment and effort required to operate one site. To achieve this, uniform equipment is used throughout the largest network area possible and the used radio access technologies are defined by the software packages installed. Large, quantifiable operator savings on hardware equipment, power, installation, maintenance, and operational costs are the main advantages of introducing Single RAN. Additionally, the introduction of the Single RAN results in an increase of capacity and range per site. Because of a short commissioning phase, common management interface, and easy upgrade procedures, the network

62

DN0993921

Issue: 02B



becomes flexible and is able to respond to the rapidly changing traffic demand of the market. Single RAN features, such as RF sharing, introduce additional CAPEX and OPEX savings for operators, thanks to the use of shared hardware.

2.13.1 Nokia Single RAN enablers Flexi Multiradio 10 BTS Flexi Multiradio 10 BTS is a part of Nokia macro BTS site solution. From a BTS site installation and hardware point of view, Flexi Multiradio 10 BTS proceeds with the Nokia unique way to build BTS sites using modules, without a specific BTS cabinet. Because its small weight and size, modular design, and full frontal accessibility, Flexi Multiradio 10 BTS is easy to install in various locations. Flexi Multiradio 10 BTS is compact, high capacity, and software-defined base station for GSM, WCDMA, and LTE (TDD and FDD) technologies supporting CDMA migration to LTE. It can be shared between two or more technologies by simple SW reinstallation. Flexi Multiradio 10 BTS modules can be used with different BTS configurations for an integrated and small site solution. The existing site support and auxiliary cabinets can be used to house Flexi Multiradio 10 BTS modules, or modules can be installed, for example, on a wall. The same multiradio modules are used in both indoor and outdoor sites. Flexi Multiradio System Module Flexi Multiradio 10 BTS System Module is responsible for data transmission, baseband processing, system operation and maintenance, and power distribution. Any Radio Access Technology is supported by installing the respective software package. Depending on the System Module variant, various capacity of baseband processing is offered. Flexi Multiradio 10 BTS System Module hardware has been prepared to support the System Sharing functionality, which makes it highly future-proof. System Module will support concurrent operation of two radio access technologies (RATs) on the same System Module, which also means more space efficient sites. Smooth migration from one technology to another will be provided. Flexi RF Modules/Remote Radio Heads Flexi RF Modules support all the three radio access technologies (RAT) (GSM/WCDMA/LTE) serving one to three sectors at a time. One Flexi RF Module can serve up to two RAT System Modules. That brings operators significant savings as operating two RF Modules is no longer needed. The hardware architecture of Flexi RF Modules/RRH differs in the filters used and the input power required by the module. The choice of the filter depends on the operating bandwidth frequency. The power required by the module depends on site characteristics and the operator needs. The System Modules are installed close to the RF Modules, so that there is no need to use feeders. Therefore, additional cost savings are introduced. Active Antenna System The Flexi Multiradio Antenna System is the next step in the evolution of radio networks, providing higher capacity and coverage while reducing site costs. The Nokia Multiradio Antenna System enhances mobile network performance by integration of the base station's radio frequency elements into the antenna. It provides an alternative to Flexi RF Modules and RRHs or can be used in combination with traditional Flexi RF units.

Issue: 02B

DN0993921

63



The Flexi Multiradio Antenna System is a complete radio unit with integrated antenna arrays, transceivers, power amplifiers, and filter modules, including the integrated Common Module (CM) for processing the Active Antenna System (AAS) specific functions. The integrated antenna array supports active and passive combinations. Box Controller Node Both mcBSC and mcRNC products can be hosted on the same Box Controller Node (BCN) hardware platform. Using the same hardware units allows to host 2G and 3G controller modules in the same cabinet, reducing the site costs. The network element type depends on the software package installed on the BCN. Therefore, the upgrade from 2G to 3G network is easy, requiring only software update. BCN’s modular architecture allows increase of capacity by connecting several nodes in a stack. Such scalability allows to expand the network only when the number of users increases and to actively react to growing traffic demands. The BCN is a generic, scalable hardware platform suitable for implementing a wide range of processing-intensive products serving as controller-, gateway- or server-type entities in telecommunication networks. Although the network context varies, the products have much in common so that a common hardware platform is viable. Network elements can consist of one BCN module (small network elements) or several BCN modules (large network elements with large processing power requirements). Availability requirements have strong impact on the BCN module hardware configuration and interconnection solutions. The power feed operates in load-sharing mode and the BCN module is operational even if one of the power supply modules breaks down. Processors within a BCN module are independent of each other so that a faulty processor has no effect on the performance of the rest of the module.

g

Note: For more information, see Multicontroller RNC Hardware Description in WCDMA RAN Operating Documentation and Multicontroller BSC and Multicontroller TC Hardware Description in GSM/EDGE BSS Operating Documentation.

2.13.2 Single RAN features The current shared Single RAN features are the following: • • • • • •

QoS aware Ethernet Switching (BSS101417, RAN1769, LTE649) Synchronization Hub (BSS21439, BSS30450, RAN1707, LTE612) RX Diversity Sharing GSM-WCDMA (BSS21403, RAN2514) RF Sharing GSM-WCDMA (BSS21403, RAN1770) RF Sharing GSM-LTE (BSS21520, LTE447) RF Sharing WCDMA-LTE (RAN2126, LTE435)

For more information on the features, see the Feature Descriptions documentation in WCDMA RAN Operating Documentation, GSM/EDGE BSS Operating Documentation and LTE Radio Access Operating Documentation.

64

DN0993921

Issue: 02B



2.14 Zone eNB solution From the point of view of function, the Zone eNB, which comprises the Flexi Zone Controller (FZC) and Flexi Zone Access Point (FZAP), is a counterpart of the eNB.

2.14.1 Overview of Flexi Zone Controller within Zone eNB solution The Flexi Zone Controller is a new product within Nokia's LTE small cells portfolio. It enables the aggregation of multiple small cells into a single Zone eNB. The Zone eNB has been designed as a cost-effective and high-performing capacity solution for the deployment of a large number of coordinated small cells. Flexi Zone is a heterogeneous network solution that makes use of LTE and Wi-Fi to offload, add capacity, and boost subscriber experience in both indoor (public/enterprise) and outdoor street-level hot-zone environments. The introduction of the Flexi Zone Controller into the Zone eNB enables deploying large numbers of mixed indoor and outdoor cells within a single Zone cluster. Each of the small cells is supported by a Flexi Zone Access Point (FZAP) based on a re-purposed Flexi Zone Micro BTS. Flexi Zone Controller aggregates Flexi Zone Access Points and acts as a single eNB towards the core network, providing mobility anchoring to all UEs within the Zone eNB. Figure 50

Basic schema of Flexi Zone deployment

FZAP

FZAP

FZAP

FZAP

FZAP

FZC

FZAP

CoreNetwork The current implementation of the Zone eNB supports up to 100 FZAPs under an individual FZC. The aggregation of all access point interfaces under the FZC simplifies integration and IP addressing, reduces signaling back to the core network, and simplifies the backhaul by enabling one single feed to the controller rather than to many access points.

2.14.2 Zone eNB network deployment overview The Zone eNB deployment allows for a cluster of access points covering a hot zone to be deployed under a Flexi Zone Controller (FZC).

Issue: 02B

DN0993921

65



FZC terminates all standard (S1, X2) and O&M interfaces (BTS-OM, NE3S) within a Zone eNB. The NE3S interface on FZC is primarily used for FZC platform/transport management and does not go through iOMS. The Zone appears as an eNB with a large number of cells both from a network management and call processing point of view. It is expected that operators would want to transition to the eNB Zone mode of operation as their small cell deployments expand and their need for capacity grows. Existing Flexi Zone Micro BTS hardware works under the FZC as a Flexi Zone Access Point (FZAP). The proprietary interface between FZC and FZAP is termed Z1. Figure 51: Zone deployment overview presents the Nokia LTE Small Cell reference architecture with the two supported LTE Small Cell deployments: standalone Flexi Zone Micro and Zone eNB. Figure 51

Zone deployment overview NetAct ZoneeNB Deployment

FZM Deployment S-GW

MME NWI3 NE3S

iOMS

S1-U

S1-MME

BTSOM +NE3S

FZC

BTSOM

Z1 FlexieNB

FZM X2

FZAPs X2

UE Uu

Uu

2.14.3 Flexi Zone Controller instructions and references This chapter lists procedural and reference documents related to the Flexi Zone Controller and Zone eNB product. Instructions and procedures • • • •

66

Administering Flexi Zone Controller (DN09210669) Commissioning Flexi Zone Controller (DN09210645) Flexi Zone Controller Installation Quick Guide (DN09132606) Installing BCN Hardware to 19-inch commercial cabinet (DN09127238)

DN0993921

Issue: 02B


•


Installing BCN Hardware to CAB216SET-B and CAB216SET-D (DN0995261)

Reference documents • • • • • • • • • •

Flexi Zone Controller HW Revision List (DN09133862) Installation Site Requirement for BCN Hardware (DN0969093) Flexi Zone Controller Environmental Product Declaration (DN09104428) Flexi Zone Controller Alarms (DN09210684) Flexi Zone Controller Parameters (DN09210727) Flexi Zone Controller SCLI Commands (DN09210703) Flexi Zone Controller Measurements and Counters (DN09210766) Open Source and Third Party Software Terms in Flexi Zone Controller (DN09210742) Integrating Flexi Zone Controller to NetAct (DN09188976) Configuring Flexi Zone Controller LTE Transport (DN09224449)

Related Features • • •

LTE1996: Flexi Zone Controller Application LTE2017: IPsec Support for Flexi Zone Controller LTE2346: Flexi Zone Controller Shared Backhaul Support - Phase I

Other documents relevant to the Flexi Zone Controller • • • • • • • • • • • • •

Issue: 02B

LTE RAN and EPC System Description Flexi Multiradio Base Station and Flexi Multiradio 10 Base Station Optional Items Description LTE RAN O&M Security eNB External Interface Changes: New IEs in S1AP and X2AP Flexi BTS Commissioning Overview Configuring LTE RAN Transport Specifications of LTE RAN Key Performance Indicators LTE/EPC RAN Compatibility LTE System Management Integrating Flexi Multiradio BTS LTE to NetAct Flexi Zone Indoor BTS Environmental Product Declaration LTE Radio Dimensioning Guideline LTE Performance Measurements

DN0993921

67

Network and service management


3 Network and service management This chapter provides information about the following issues: • • •

Network management architecture Managing the LTE/EPC system with NetAct Element management tools

3.1 Network management architecture The LTE/EPC network management system is easily scalable; all network sizes are supported. From user perspective, managing by the NetAct is similar in the WCDMA and in LTE/EPC network. The LTE/EPC network management architecture is described in Figure 52: LTE/EPC network management architecture. Figure 52

LTE/EPC network management architecture NMS

3rdparty NMS

XML

NetAct

NE3S/SNMP

BTSOM

MME

eNB S1-MME

S11

X2

S5

S1-U eNB EvolvedUTRAN

S-GW

P-GW

EvolvedPacketCore

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. In addition to the BTSOM protocol, the Zone eNB use the NE3S protocol.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 graphic presentation of measurement data reporting is based on 3GPP formats.

68

DN0993921

Issue: 02B



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.

3.2 Managing the LTE/EPC system with NetAct NetAct, the network management application for the 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, Security) functionality comprising: • • • • • • • •

fault management performance management configuration management accounting 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 subscriber 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 Element Manager (EM) or by the BTS Site Manager (BTSSM).

Issue: 02B

DN0993921

69



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 offered by the network elements. 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). eNB management The BTS Site Manager is used for both local and remote management. For local management, a PC with the 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 NetAct site. The BTS Site Manager comprises the following main features: • • • • • • •

g

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 Note: The Zone eNB has different BTS Site Manager capabilities.

3.4 CRAN network management CRAN can be activated, configured, and deactivated from the BTSSM tool or NetAct. Managing the BTS FSMs amount and chain can be performed both from the level of the BTSSM and NetAct. NetAct can be used for all CRAN statistics gathering purposes and fault management. The operator should follow configuration guidelines when connecting FSMFs to a certain CRAN configuration. A CRAN system topology view is not available in NetAct.

70

DN0993921

Issue: 02B


Mobility

4 Mobility EPS mobility management comprises functions and procedures that maintain the connectivity between UE and EPS as the UE moves between the coverage areas of different base stations or access networks. As far as possible, seamless mobility is provided so that the mobility is transparent to UEs and the applications they use. For applications that require it, the mobility is “lossless”. In other words, the packet loss probability is very low. Thanks to LTE48: Support of high speed users feature, the eNB is able to handle the UE's movement speed of up to 350 km/h in an open space and up to 300 km/h in tunnels.

4.1 Mobility scenarios A number of mobility scenarios is supported as illustrated in Figure 53: Mobility scenarios for LTE/EPC. •

LTE Intra-RAT mobility comprises: – –

•

Intra-eNB mobility (handover between the cells within a certain eNB) Inter-eNB mobility (handover between the adjacent eNBs).

Inter-RAT mobility comprises: – –

mobility between LTE and other 3GPP RATs (GERAN or UTRAN) mobility between LTE and non-3GPP RATs (3GPP2 access network (HRPD))

With LTE490: Subscriber Profile Based Mobility feature it is possible to assign subscriber profile IDs (SPID) to mobility profiles. A mobility profile is a set of O&M configured target frequency layers for enabled inter-frequency and inter-RAT mobility functions, for example handover, NACC, RRC connection release with redirect, SRVCC, or CSFB. Up to eight mobility profiles can be defined per eNB by O&M settings. This functionality is mostly used during national roaming where the SPID provided by the MME is used to identify own subscribers and national roaming subscribers. The LTE487: Idle Mode Mobility Load Balancing feature enhances mobility profiles with idle mode mobility targets and SPID range with new 3GPP reserved values (254, 255, and 256). With LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT feature, the eNB sends information about CDMA2000 frequencies and neighboring cells to all UEs in RRC-IDLE and RRC-CONNECTED states. On the basis of this information, the UE is able to make an inter-RAT cell re-selection from LTE to CDMA/1xRTT. With LTE807: Idle Mode Mobility from LTE to CDMA/1xRTT feature, the eNB supports the cell reselection from LTE to CDMA/1xRTT. The eNB broadcasts the information about CDMA2000/1xRTT frequencies and CDMA2000/1xRTT neighboring cells on SIB8. Based on that information, the UE is able to make an inter-RAT cell re-selection from LTE to CDMA/1xRTT.

Issue: 02B

DN0993921

71

Mobility


With LTE870: Idle Mode Mobility from LTE to CDMA/eHRPD feature, the eNB sends information about CDMA2000 frequencies and neighboring cells to all UEs in RRC-IDLE and RRC-CONNECTED states in the broadcast. This information is needed for inter-RAT cell re-selection from LTE to CDMA evolved High Rate Packet Data (eHRPD). With LTE870: Idle Mode Mobility from LTE to CDMA/eHRPD feature, the eNB supports the cell reselection from LTE to CDMA/eHRPD. The eNB broadcasts the information about CDMA2000/eHRPD frequencies and CDMA2000/eHRPD neighboring cells on SIB8. Based on that information, the UE is able to make an inter-RAT cell re-selection from LTE to CDMA/eHRPD. Figure 53

Mobility scenarios for LTE/EPC

3GPP PSCore

EvolvedUTRAN UTRAN GERAN TD-SCDMA

eNB

Non-3GPP 3GPP2

SGSN

NBorBTS

P-GW

eNB S-GW

P-GW

Packet Data Network

EvolvedPacketCore

With the LTE1060: TDD - FDD handover feature, handover between TDD and FDD is possible. The operator can offer service continuity between two technologies. The following TDD/FDD handover scenarios are supported by the Flexi Multiradio BTS: • • •

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

Both handover directions FDD - TDD and TDD - FDD are supported. With the LTE2050: Load triggered Idle Mode Load Balancing feature, the eNB triggers the Idle Mode Load Balancing algorithm only when load conditions are met. In low load conditions, the Idle Mode Load Balancing is not triggered. This allows the operator to avoid frequent cell reselections under low load conditions.

4.2 Mobility anchors During mobility, the U-plane data path continuity to the PDN is maintained using mobility anchors as illustrated in Figure 54: Mobility anchor point. These are network element instances which are permanent members of the U-plane path and located such that the path from the anchor to the PDN does not change.

72

DN0993921

Issue: 02B


Figure 54

Mobility

Mobility anchor point PDN

S-GW

S5/S8a

S2

P-GW

non-3GPP

Gp/Gn S5/S8a eNB

S1-U

S12

3GPP

S-GW S4 S1-U

SGSN PreRel-8

SGSN Rel-8

eNB

cell

cell

U-Planepath

Mobilityanchor

The mobility anchors for each mobility scenario are summarized in Table 4: Mobility scenarios and anchor points. Table 4

Mobility scenarios and anchor points

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

4.3 Handovers A handover is a change of a radio connection between the network and a UE which is already in a connected mode (idle mode mobility is covered by a cell selection and reselection). During the handover procedure, running services are maintained; a call is not interrupted and for an intra-LTE handover no data is lost.

Issue: 02B

DN0993921

73

Mobility


Handovers in LTE are network controlled and UE assisted. The goal of the handover procedure is to allocate the same resources for the UE in the target cell after the handover as those used prior to the handover. From the UE's point of view, a handover is always “hard,” meaning that a connection exists to only one cell at a time. Handovers result from such factors as: •

•

Quality: Handovers due to quality are typically initiated as a result of a UE measurement report indicating that the UE can communicate with a neighbor cell with a better channel quality than that of the current serving cell. Coverage: Handovers due to coverage are also initiated as a result of a UE measurement report indicating that the serving cell becomes worse than an absolute threshold.

Figure 55: Functional units of an inter-eNB handover procedure shows major functional units of an inter-LTE handover procedure. Figure 55

Functional units of an inter-eNB handover procedure

SourceeNB

UE Measurementreport (Targetcells)

Measurements

Handoverdecision Targetcellselection

TargeteNB

Reconfig. command

Handoverpreparation

Radiolinkestablishment Reconfig. complete

Finishingactions Releaseofresources

Data

4.3.1 Measurements and measurement reports The UE continuously performs measurements of downlink reference signals in the current cell and, depending on configurations and conditions, in neighboring cells. The UE assists the eNB regarding a handover by sending measurement reports. In case of verifying radio conditions due to the UE mobility (for example when the UE moves from one LTE cell to another or because of limited LTE coverage), measurement reports may initiate handover. The type of measurements to be made by the UE, and the details

74

DN0993921

Issue: 02B


Mobility

of reporting them to the eNB can be configured (measurement configuration and report configuration), and the eNB informs the UE about the configurations via the RRC CONNECTION RECONFIGURATION message. Measurements The measurement configuration sent by the eNB to the UE includes thresholds controlling the UEs' measurement activities. The UE continuously monitors the RSRP (reference signal received power) of the current (serving) cell; further measurements depend on the relation of the RSRP value of the serving cell to the TH1 and TH2 thresholds: • •

•

•

If the RSRP value exceeds the upper TH1 threshold, no measurements of neighbor cell signals are performed. If the RSRP value is between the upper TH1 threshold and the lower TH2 threshold, RSRP measurements of LTE neighbor cell signals belonging to the same frequency band are performed (currently, TH2 = 0). If the RSRP value is below the TH1 threshold (also referred to as S-measure in the standard of the measurement configuration), RSRP measurements of LTE neighbor cell signals belonging to the same frequency layer are performed. If the RSRP value is below the lower TH2 threshold, measurements of neighbor cell signals belonging to other RATs are performed.

Measurement reports In order to limit the amount of signaling, the UE only sends measurement reports (MEASUREMENT REPORT messages) to the eNB when certain conditions (events) are met by the UEs' measurements. The following events are defined in the standard: • • • • • • •

Event A1: The serving cell becomes better than an absolute threshold. Event A2: The serving cell becomes worse than an absolute threshold. Event A3: An LTE neighbor cell becomes better than an offset relative to the serving cell. Event A4: An LTE neighbor cell becomes better than an absolute threshold. Event A5: The serving cell becomes worse than an absolute threshold and an LTE neighbor cell becomes better than another absolute threshold. Event B1: A non-LTE neighbor cell becomes better than an absolute threshold. Event B2: The serving cell becomes worse than an absolute threshold and a nonLTE neighbor cell becomes better than another absolute threshold.

The events from A1 to A5 are related to intra-LTE handovers, B1 and B2 events are related to inter-RAT handovers. A1 is useful for restricting UE measurements to the serving cell only, A3 is connected with a better cell handover, A5 with a coverage handover. The events correspond with the type of measurements the UE performs. Currently, tA1, A2, A3, A5, and B2 events are supported. The measurement reports contain a list of target cells for a handover. The target cells are listed in order of decreasing value of the reporting quantity, that is, the best cell is reported first. As a consequence of the definition of the events, the target cell list cannot be empty. Handover conditions due to A5 get a higher priority than handovers due to A3.

Issue: 02B

DN0993921

75

Mobility


One MEASUREMENT REPORT message contains one “MeasResults” IE (information element) which includes measurement results of one single measurement, that is, measurements are not combined for reporting purposes. The “MeasResults” IE contains a “MeasResultListEUTRA” IE if potential LTE target cells are available; “MeasResults” includes the following content: Table 5

Selected content of the “MeasResults” IE

IE

Subordinate IE

measResultServCell

MeasResultListEUTRA-> measResultNeighCells

Comment

rsrpResult

-

rsrqResult

-

physCellId (1)

-

cgi-Info

not used

measResult

contains: rsrpResult rsrqResult

physCellId (2)

-

...

-

4.3.2 Inter-eNB handover Inter-eNB handovers are typically handovers that aim to minimize service interruption and packet loss. Based on the 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 56: Inter-eNB handover with X2 interface and Figure 57: Inter-eNB handover without X2 interface. 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, the UE will switch to the target cell and then re-transmit all packets which were not acknowledged in the sequence before the handover. The Serving Gateway performs late path switching. This means that the downlink path is not switched to the target eNB before the handover is completed. This prevents packet bi-casting.

76

DN0993921

Issue: 02B


Figure 56

Mobility

Inter-eNB handover with X2 interface Pathswitch

S-GW

S-GW

Packetforwarding fornotacknowledgedSDUs, useofPDCPsequencenumber

S1

S1

S1

S1

X2 Source eNB

eNB

X2

X2

DLprioritization ofpacketsforwarded fromsourceeNB

UE

Target eNB

ULreordering basedonPDCP sequencenumbers

Figure 57: Inter-eNB handover without X2 interface depicts how data forwarding between source and target eNB takes place via S-GW, if direct data forwarding is not possible via X2 interface. Figure 57

Inter-eNB handover without X2 interface S-GW

S-GW

2xadditional transmissionsonS1add backhaulandload

S1

S1

S1

S1

X2 source eNB

eNB X2

UE

target eNB

Handover via S1 With S1-based handover, a UE can be handed over from one LTE cell to another LTE cell (of another eNB) without the usage of an X2 interface. X2 interface between Source and Target eNB may be not existing, not operable or its use for handover may be

Issue: 02B

DN0993921

77

Mobility


forbidden by O&M. S1-based handover is routed via the Core Network and therefore provides the possibility for the Core to change the serving MME and/or the serving SGW. Inter-eNB Inter-Frequency Load Balancing The Flexi Multiradio BTS supports load-based inter-frequency handover between different eNBs connected via X2 or S1. The eNB monitors the source cell load to initiate a load-based handover. With LTE1170: Inter-eNB Inter-Frequency Load Balancing feature, it is possible to avoid overload situations for specific cells by steering the traffic into less loaded cells at a different frequency layer or balance load between frequency layers. Mobility Robustness Optimization Mobility Robustness Optimization (MRO) also considers the radio handover situations which produce Ping Pongs between two cells. The LTE1768: Ping Pong MRO feature allows to reduce the number of unnecessary handovers, also known as PingPong events, and ensure the eNB Mobility Robustness performance.

4.3.3 Inter-RAT handover (3GPP) 3GPP inter-radio-access-technology (inter-RAT) handovers differ from intra-LTE intereNB 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. Inter-RAT handovers apply to UEs in RRC_CONNECTED mode only. UEs in idle mode apply cell reselection procedures, also towards the other RATs. Like inter-eNB handovers, 3GPP inter-RAT handovers are typically backward handovers. 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 redirection: to force the UE to idle state and to 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 58: 3GPP inter-RAT mobility.

78

DN0993921

Issue: 02B


Figure 58

Mobility

3GPP inter-RAT mobility S12 U-TRAN

Iu 3GPPPSCore Backwardhandover

Gb

GERAN

SGSN

S4

oror ForceUEtoidlestateand performTAUorRAU

S3

Nodirectsignallinginterface betweenUTRANandeNB eNB

MME

S1-MME S11 X2 S1-U

S5 S-GW

eNB EvolvedUTRAN

SGi

PacketData Network

P-GW

EvolvedPacketCore

Together with some new features it is possible to enhance inter-RAT handover performance. With LTE1073: Measurement based redirect to UTRAN feature, the eNB supports a measurement-based redirect to UTRAN as an extension of the PS handover function. The eNB uses the same neighbor cells as configured for the PS handover to UTRAN. The measurement configurations are common for the redirect and the PS handover. This results in higher reliability for LTE to UTRAN service continuity. The RRC: RRC CONNECTION RELEASE message with redirect to UTRAN is triggered by the UE measurement report in case that: • •

the UE does not support the FGI8 the handover is deactivated by an O&M flag

With LTE984: GSM redirect with system information feature, redirection message to GSM is enhanced with system information. New functionality reduces time needed to access target GERAN cell, as the UE will not need to read SIBs from air interface to access the target cell. Network Assisted Cell Change to GSM The LTE to GSM Network Assisted Cell Change (NACC) functionality of the Flexi Multiradio BTS allows for a service continuity of data services when changing from an LTE cell to a GSM cell. NACC is only applicable to NACC capable multimode devices supporting both LTE and GSM at the according frequency band. The UE capabilities are provided to the eNB by the feature group indicator. Single Radio Voice Call Continuity (SRVCC) to WCDMA The LTE to WCDMA Single Radio Voice Call Continuity (SRVCC) functionality of the Flexi Multiradio BTS allows for a service continuity of voice services to the CS domain when changing from an LTE cell to a WCDMA cell. All non-voice services will be handed over to the PS domain.

Issue: 02B

DN0993921

79

Mobility


The functionality is only applicable for SRVCC-capable multimode devices supporting both LTE and WCDMA at the corresponding frequency band. The eNB will trigger SRVCC only if the UE has an EPS bearer with QCI=1 established and the MME and UE are SRVCC-capable. Single Radio Voice Call Continuity (SRVCC) to GSM The LTE to GSM Single Radio Voice Call Continuity (SRVCC) functionality of the Flexi Multiradio BTS allows for a service continuity of voice services to the CS domain when changing from a LTE cell to a GSM cell. The SRVCC functionality does not support DTM/PSHO, that is established non-voice bearers are not handed over to GSM. An operator-configurable switch is supported, which determines whether to suspend the data session or not. The functionality is only applicable for SRVCC capable multimode devices supporting both LTE and GSM at the according frequency band. Inter RAT handover from UTRAN The LTE57: Inter RAT handover from UTRAN feature provides a better service quality experience for the end user, for example peak rates and latency, in LTE as in UTRAN. An inter-RAT handover for an UE from UTRAN (WCDMA and TD-SCDMA) to LTE is possible.

4.3.4 Optimized 3GPP2 (HRPD) inter-RAT handover In principle, the handover between LTE and HRPD can be realized by following the generic principles specified for mobility between LTE and non-3GPP accesses, that is, by carrying out IP mobility signaling ((P)MIP procedure) without optimizations at radio access network level to improve the performance of the handover. However, some 3GPP2 operators are requiring 3GPP2 inter-RAT handover performance that is comparable to 3GPP inter-RAT handover performance and for that purpose 3GPP is specifying an optimized LTE-HRPD mobility solution comprising of S101 reference point between MME and HRPD access node and S103 reference point between S-GW and HRPD Serving Gateway (HSGW) and the associated additional functionality in MME. The architecture for optimized LTE-HRPD mobility is illustrated in Figure 59: Architecture for optimized LTE-HRPD mobility. With LTE60: Inter RAT handover to eHRPD/3GPP2 feature the Flexi Multiradio BTS allows for a service continuity of data services with minimal interruption time when changing from an LTE cell to a CDMA2000 eHRPD cell. The functionality is only applicable for multimode devices supporting both LTE and CDMA2000 eHRPD for the according frequency band and the according feature support. S101 enables preregistration and HO preparation with EV-DO Rev-A significantly reducing the HO delay (from 3 s to 300-500 ms). S103 enables data forwarding from SGW to HSGW reducing the number of lost packets for data traffic, thus also impacting VoIPISHO performance by minimizing breaks in VoIP traffic.

80

DN0993921

Issue: 02B


Figure 59

Mobility

Architecture for optimized LTE-HRPD mobility EvolvedPacketCore

AAA

Gx

Gxa PCRF Gxc

S2a

HRPDSystem

STa

HSGW

S8b

P-GW

S103

Swx

EvolvedUTRAN S101 S1-MME eNB

MME

S1-U

S11

S5 S-GW

S6a

HSS

ControlplaneforEPSintroduction UserplaneforEPSintroduction Controlplanefor2ndphaseEPS Userplanefor2ndphaseEPS ControlplaneforRev.Asystem UserplaneforRev.Asystem

4.3.5 Inter-frequency handover The eNB supports inter-frequency handover in which the handover decision is based on reference symbol received power (RSRP) or reference signal received quality (RSRQ) (DL measurement). Triggers can be "coverage HO" and "Better Cell HO". Typically UE requires measurement gaps for doing inter-frequency measurements, depending on the UE capability. Typically, the UE performance measurements are done while data transmission between the UE and source eNB are still performed. Therefore, KPIs like U-plane break duration or C-plane break duration do not depend on these UE performance measurements and the system performance of inter-frequency HO is expected to be the same as for intrafrequency HO. Inter-frequency handover allows service continuity for LTE deployment in different frequency bands as well as for LTE deployments within one frequency band but with different center frequencies. These center frequencies can also cover cases with different bandwidths, for example 5 MHz and 10 MHz. The LTE1127: Service Based Mobility Trigger feature introduces a mechanism for a service-triggered inter-frequency handover. With this feature, it is possible to configure specific VoLTE services target frequency layers within mobility profiles. The operator can deploy and configure his network with the LTE1127: Service Based Mobility Trigger feature so that certain specific frequency layers are preferred over other layers for VoLTE

Issue: 02B

DN0993921

81

Mobility


calls, and the eNB will try to steer the UE with VoLTE calls to those preferred layers with Service Based Handover. Because of their priority, voice calls are not blocked; the lower priority non-GBR traffic will decrease.

4.3.6 Zone eNB inter-cell handover A new type of handover is introduced to handle any handoffs that occur between the Flexi Zone Access Points under the same Flexi Zone Controller. These handovers are handled in a similar way to inter-cell handovers on the Macro level.

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

4.5 Roaming Roaming support will not be required for initial network launch, but only in a later phase with wider scale of EPS deployment. Three main roaming scenarios can be built on EPS architecture depending on which services are accessed: • • •

Roaming for home routed traffic Roaming architecture for local breakout with home operator's application functions Roaming architecture for local breakout with visited operator's application functions

Roaming for home routed traffic In this scenario all traffic is routed from VPLMN to HPLMN to get access to any of the services (see Figure 60: Roaming scenario with home routed traffic). The VPLMN EPC entities include MME and S-GW. The MME fetches subscription information via S6a roaming reference point from the HSS located in HPLMN. The S-GW performs accounting on user and QCI granularity for inter-operator charging purposes. This scenario mandates the split of EPC GW functionality into S-GW and P-GW with an S8 reference point between them. If Dynamic PCRF functionality is deployed, it is fully controlled by HPLMN.

82

DN0993921

Issue: 02B


Figure 60

Mobility

Roaming scenario with home routed traffic VPLMN

HPLMN EvolvedPacketCore

EvolvedPacketCore

EvolvedUTRAN

Gx MME

PCRF

S1-MME

HSS

S6a

eNB

Rx

S11 SGi

S8 S1-U P-GW

S-GW

Controlplane

OperatorServices, Internet, CorporateServices

Userplane

Roaming architecture for local breakout with home operator's application functions In this scenario all traffic breaks out locally from VPLMN, but the Application Function (AF) is located in HPLMN (see Figure 61: Roaming scenario for local breakout with home operator's application functions). The VPLMN includes all EPC entities except for HSS and H-PCRF (and AF in also located in HPLMN). The MME fetches subscription information via S6a roaming reference point from HSS located in HPLMN. The EPC-GW gets dynamic PCRF policies related to AF via Gx reference point from V-PCRF, which has received policies from H-PCRF via S9 reference point. This scenario enables the combined EPC-GW functionality (S-GW and P-GW) without need for S8 reference point. If AF/PRCF infrastructure is not deployed for local breakout traffic, S6a remains the only roaming reference point for this scenario. Figure 61

Roaming scenario for local breakout with home operator's application functions

VPLMN EvolvedUTRAN

EvolvedPacketCore Gx

EvolvedPacketCore V-PCRF

MME

S1-MME

HPLMN

S9

H-PCRF Rx

S6a S-GW S11

HSS SGi

eNB S1-U

VPLMN PDN

HPLMN IPServices

P-GW

Controlplane

Issue: 02B

Userplane

DN0993921

83

Mobility


Roaming architecture for local breakout with visited operator's application functions In this scenario all traffic breaks out locally from VPLMN, but the Application Function (AF) located in VPLMN gets dynamic policy information from both VPLMN and HPLMN (see Figure 62: Roaming scenario for local breakout with visited operator's application functions). The VPLMN includes all EPC entities except for HSS and H-PCRF. The MME fetches subscription information via S6a roaming reference point from the HSS located in the HPLMN. The EPC-GW gets dynamic PCRF policies related to AF from both V-PCRF and H-PCRF via Gx reference point. V-PCRF receives policies from H-PCRF via S9 reference point. This scenario enables the combined EPC-GW functionality (S-GW and P-GW) without the need for an S8 reference point. As in the above scenario, if AF/PRCF infrastructure is not deployed for local breakout traffic, S6a remains the only roaming reference point for this scenario. Thus, this scenario and the scenario with home operator's application functions become identical. Figure 62

Roaming scenario for local breakout with visited operator's application functions

VPLMN EvolvedUTRAN

EvolvedPacketCore

EvolvedPacketCore Gx MME

V-PCRF

S9

H-PCRF

Rx

S6a

S1-MME

HPLMN

S-GW S11

HSS SGi

eNB S1-U

HPLMN IPServices

P-GW

Controlplane

Userplane

Another dimension to the roaming support is brought by the existence of two variants for the S8 roaming interface: S8b IETF variant (PMIP based) using the newly specified [GSMA IR.34] IRX roaming infrastructure (IRX is an evolution of GPRS roaming exchange (GRX) supporting end-to-end QoS, multi-lateral interconnect agreements and advanced billing models) at pre-commercial trial phase and S8a GTP variant using the well-established GRX roaming infrastructure. IRX roaming infrastructure has mainly attracted operators with 3GPP2 background, whereas operators with 3GPP have preference for the GRX infrastructure, which they have already in place. GRX based roaming infrastructure will dominate still for some time, as it takes time to fully setup working roaming infrastructure and due to roaming arrangement with 3GPP operators. Therefore, 3GPP2 operators need to support S8a reference point utilizing GRX roaming infrastructure in any case. However, in the long term the evolution of GRX is required for supporting end-to-end QoS and new billing models to provide roaming support for applications such as VoIP.

84

DN0993921

Issue: 02B


Mobility

4.6 Location services Location services (LCS) support in EPS is mainly driven by regulatory services (locating emergency calls, lawful interception, etc.). Some countries require location information to be available only while the call is up, while others may allow PSAPs (Public Safety Answering Point) to decide how long the location must be made available. Location information is needed for two main reasons in emergency services. It serves to enable: the selection of which PSAP serves the area where a UE is currently located, so that the emergency session can be routed to the correct PSAP the PSAP to get more accurate or updated location information for the terminal during or after the emergency session

• •

Table 6: LCS requirements lists the LCS requirements per service category as agreed by 3GPP (TS 22.071) for legacy 3GPP accesses and also applicable for LTE: Table 6

LCS requirements

Location-independent

Most existing cellular services, stock prices, sports reports

PLMN or country

Services that are restricted to one country or one PLMN

Regional (up to 200 km)

Weather reports, localized weather warnings, traffic information (pre-trip)

District (up to 20 km)

Local news, traffic reports

Up to 1 km

Vehicle asset management, targeted congestion avoidance advice

500 m to 1 km

Rural and suburban emergency services, manpower planning, information services

100 m (67%)1), 300 m (95%)2)

U.S. FCC mandate (99-245) for wireless emergency calls using network based positioning methods

75 m - 125 m

Urban SOS, localized advertising, home zone pricing, network maintenance, network demand monitoring, asset tracking, information services

50 m (67%) 150 m (95%)

U.S. FCC mandate (99-245) for wireless emergency calls using handset based positioning methods

10 m - 50 m

Asset Location, route guidance, navigation

Currently there are two high level alternatives to support Location Services in EPS: •

User-plane based solution transparent to eNB

1) 2)

Issue: 02B

In UE based method 50 m (67%) In UE based method 150 m (95%)

DN0993921

85

Mobility


•

Control-plane based solution impacting EPS functionality

From the EPS point of view, the simplest way would be to have a user-plane based solution only, which would be a generic solution applicable for all access technologies, but some operators claim that only the control-plane based solution is able to meet regulatory requirements in all circumstances. Therefore, the outcome is that controlplane LCS solutions are specified for EPS in the 3GPP Release 9 time frame (U-plane solution can be transparent for EPS). For 3GPP Release 8 it has been already agreed that for Lawful Interception and Location dependent charging purposes, the eNB reports the UE's current Cell ID to the MME (included in each S1AP message). The cell ID based location service functionality also supports emergency calls. When end users initiate an emergency call, they can be easily located. Observed Time Difference of Arrival The location method Observed Time Difference of Arrival (OTDOA), which is introduced with LTE495: OTDOA feature, provides an improved location accuracy. The operator is able to provide location services better than cell ID where GPS is not working. Additional positioning reference symbols (PRS) are inserted in the downlink to increase the hearability for the OTDOA measurements.

86

DN0993921

Issue: 02B


Radio resource management and telecom

5 Radio resource management and telecom RRM is responsible for the management of the available radio resources to enable provisioning of high quality services to users without compromising overall radio network capacity and performance. In order 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 This section contains general information on RMM functions. Radio Resource Management (RRM) provides the following Layer 3 (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 Uplane and RLC/MAC/PHY layers) and responsiveness (relatively slow or fast in comparison 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 7: Scope of RRM functions.

Issue: 02B

DN0993921

87


Table 7


Scope of RRM functions

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 Radio Admission Control Radio Configuration

Dynamic Resource Allocation (for example, Packet Scheduling) Congestion Control

E-UTRAN

Load Balancing Inter Cell Coordination

Inter-RAT

Inter RAT Handover

In comparison with the pre-LTE UMTS system, the main difference reflects decentralized RRM control moved to the edge of E-UTRAN (RRM resides in the 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 because of the different nature of LTE radio interface (WCDMA requires fast power control to address the “Near-Far” problem and intra-frequency 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, maintenance, 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 do not suffer because of 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.

88

DN0993921

Issue: 02B



Radio Admission Control supports emergency call handling feature. For emergency calls RAC uses a new threshold, which is near the system limits in order to allow as many emergency calls as possible, but which is low enough to prevent the system from reload in bursting situations. Feature LTE497: Smart Admission Control enhances the resource use of the Flexi Multiradio BTS and keeps the radio interface in a balanced state when congestion happens. The radio admission control checks the uplink and downlink resource situation for the admission of new GBR bearers. At admission control, an individual check per resource area (for example, PDSCH or PUSCH) is performed by considering the current resource usage, the expected additional resource need of the new EPS GBR bearer and the operator-configurable resource limit for GBR. With LTE534: ARP-based Admission Control for E-RABs feature, the Flexi Multiradio BTS supports ARP handling during admission control of GBR and non-GBR bearers. The eNB admission control considers the following ARP parameters provided during bearer establishment or handover via S1AP and X2AP: • • •

priority level pre-emption capability pre-emption vulnerability

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 because of heavy load. In ECM_CONNECTED state, CMC configures intra/inter RAT measurements 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 use resources efficiently under varying load and radio conditions (packet scheduling is not a part of the RRM functions). The LTE1042: Nominal Bitrate for non-GBR bearers feature introduces nominal bitrate (NBR) values that can be assigned to non-GBR bearers. The non-GBR bearers with NBR are treated similarly to GBR bearers until they have reached the NBR throughput value and can have additional throughput on best-effort basis (like non-GBR bearers). However, the packet scheduler allocates resources first to GBR and then to non-GBR bearers with NBR. Non-GBR bearers with NBR do not have an upper throughput limit (in contrast to GBR bearers). UEs at a cell border get the biggest benefits from NBR, but this happens at the expense of a lower cell throughput. The Inter-cell interference RRM & load management (ICR) function provides coordination of resource allocation between eNBs to minimize inter-cell interference. ICR may be part of O&M or it may 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 optimizing 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 under used cells.

Issue: 02B

DN0993921

89



The LTE1140: Intra-Frequency Load Balancing feature supports load balancing capabilities to other intra-eNB / inter-eNB cells. Based upon the load reported by the other cell, the load balancing algorithm calculates an adjustment to the Cell Individual Offset (CIO), which shifts the handover thresholds between selected (intra-eNB and inter-eNB) neighbor cells, that is, shrinks loaded cells and expands unloaded cells. The LTE1841: Inter-Frequency Load Equalization feature triggers load measurements and Composite Available Capacity (CAC) calculation for the own (serving) cell and requests the CAC from partner neighbor (target) cells. To equalize the CAC of the cells, the LTE1841: Inter-Frequency Load Equalization feature selects UEs in RRC active mode in cells with lower CAC and hands them over to cells with higher CAC (if all conditions for the LTE1841: Inter-Frequency Load Equalization feature activities are fulfilled). The enhanced inter-cell interference coordination function is introduced by the LTE1113: eICIC – macro and the LTE1496: eICIC - micro features. This function is intercell interference mitigation technique for applications in heterogeneous networks (HetNets), where micro eNBs' cells are deployed on the same frequency as macro eNBs cell that contains them. These features enable traffic offloading from a macro cell to micro cells, and interference reduction at the micro cells by coordinated time domain resource usage between the macro cell and micro cells (that is one out of 6 ABS muting patterns is chosen). These patterns control when the macro’s DL scheduler is not allowed to send data to its UEs and when as a consequence the small cell can reach UEs at bigger distance. Traffic offloading from the macro to the micro cells is accompanied by the setting of the HO thresholds between the cells in the eICIC area, resulting in cell range expansion (CRE) of the micro cells. The LTE1113: eICIC - Macro and LTE1496: eICIC - Micro features support the eICIC between macro and micro (FZM) cells. The LTE2133: eICIC for HetNet eNode B Configurations feature provides an enhanced inter-cell interference coordination (eICIC) support for the following eNB configurations: • • •

eNBs hosting both the macro and small cells eNBs hosting only the small cells eNBs hosting only the macro cells

The LTE1800: Downlink interference shaping feature gives a possibility of reducing the inter-cell interference by arranging respective allocation areas to non-overlapping in fractionally-loaded neighboring cells. The allocation of the cell edge UEs on less interfered resources is reached via frequency selective scheduling. 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.

90

DN0993921

Issue: 02B



With the new LTE979: IRC for 2 RX paths feature, the Interference Rejection Combining (IRC) function improves the uplink performance of cell edge users for highly loaded and interference limited cells and slightly increases the uplink cell capacity. An UL grant for a TTI bundle causes the automatic transmission of four redundancy versions taken from one MAC PDU, which constitute one initial and three HARQ retransmissions. The four transmissions of a TTI bundle are sent in four consecutive UL subframes. The automatic inclusion of retransmissions (without the need for further UL grants to collect retransmissions that are required for decoding in poor radio conditions) leads to a more robust transmission and reduced PDCCH usage.

5.2 State transitions Basic information on three sets of states defined for the UE, based on the information held by the MME: EPS Mobility Management (EMM) states, EPS Connection Management (ECM) States, and Radio Resource Control (RRC) States. EPS Mobility Management (EMM) states EMM-DEREGISTERED: in this state the MME holds no valid location information about the UE, though it may maintain some UE context when the UE moves to this state, for example to avoid the need for Authentication and Key Agreement (AKA) during every attach procedure. Successful Attach and Tracking Area Update (TAU) procedures lead to transition to EMM-REGISTERED. EMM-REGISTERED: in this state the MME holds location information for the UE at least to the accuracy of a tracking area and the UE can receive services that require registration in the EPS. In this state the UE performs TAU procedures, responds to paging messages and performs the service request procedure if there is uplink data to be sent. The state transition diagram for the EMM states is the same for the UE and for the MME and is shown in Figure 63: EMM state transitions. Figure 63

EMM state transitions SuccessfulAttachorTAU

EMMREGISTERED

EMMDEREGISTERED

DetachorTAUreject

EPS Connection Management (ECM) States ECM_IDLE: in this state there is no NAS signaling connection between the UE and the network and there is no context for the UE held in the E-UTRAN. The location of the UE is known within the accuracy of a tracking area and mobility is managed by tracking area updates. ECM_CONNECTED: in this state there is a signaling connection between the UE and the MME which is provided in the form of a Radio Resource Control (RRC) connection between the UE and the E-UTRAN and an S1 connection for the UE between the EUTRAN and the MME. The location of the UE is known within the accuracy of a cell and mobility is managed by handovers.

Issue: 02B

DN0993921

91


g


Note: In the E-UTRAN the UE can be seen to be in transitional states, for example with an RRC Connection (RRC_CONNECTED) but with no S1 connection. The state transition diagrams for the ECM states are different at the UE and the MME as shown in Figure 64: ECM state transitions. Figure 64

ECM state transitions SuccessfulAttachorTAU

EMMREGISTERED

EMMDEREGISTERED

DetachorTAUreject

Radio Resource Control (RRC) States RRC_IDLE: In this state no signaling connection between UE and network exists. UE performs cell reselections. Paging is needed when there is data in downlink direction. RACH procedure is used on RRC connection establishment. RRC_CONNECTED: In this state a signaling connection exists between UE and network. The mobility of UE is handled by the handover procedure. The UE performs the tracking area update procedure.

g

Note: UEs RRC connection can be maintained even if UE is inactive. RRC connection may be released because of the following reasons: • • •

UE is inactive for a long time high mobility When the maximum number of RRC connected UEs is reached, the longest inactive UE is released.

The Flexi Multiradio BTS supports discontinuous reception (DRX) in status RRCCONNECTED with long DRX cycles. The DRX functionality can considerably reduce the UE power consumption. Furthermore the eNB supports an extended range of 3GPP settings for the long DRX cycle, two additional operator-configurable DRX profiles, and uplink Out-of-Sync handling. The LTE585: Smart DRX feature is an extension to the existing LTE42: Support of DRX in RRC Connected Mode and LTE473: Extended DRX Settings, which improves power saving for always-on users by introduction of a short DRX cycle. Instead of keeping the UE DRX active for the duration of STIT and remaining DRX Inactivity Timer, the short DRX cycle is used to provide enough measurements to estimate Timing Alignments (TA). The new concept provides better battery savings as compared to legacy DRX. RRC Connection Re-establishment is supported as preferred resolution for temporary Radio link failure or due to physical link failure during handover execution. The Connection Re-establishment procedure is initiated by the UE in RRC connected in case of radio link failure detection due to for example: • • •

92

handover failure integrity check failure indication from lower layers RRC connection reconfiguration failure

DN0993921

Issue: 02B



The state transition diagrams for the RRC states is shown in Figure 65: RRC state transitions. Figure 65

RRC state transitions RRCConnectionEstablish RRCCONNECTED

RRC-IDLE RRCConnectionRelease

5.3 Connection states for intra-RAT mobility There are two states to be considered for intra-RAT mobility: ECM_IDLE Connection State ECM_CONNECTED Connection State

• •

ECM_IDLE Connection State In ECM_IDLE, the location of the UE is known only to the level of one or a small number of Tracking Areas (TAs), as illustrated in Figure 66: Intra-RAT mobility in ECM_IDLE. The UE will camp on a cell and perform measurements of this and other cells in the neighborhood. When it chooses to camp on a new cell, if it detects that the cell belongs to a new TA, it sends a Tracking Area Update (TAU) to the MME via the cell's eNB. If data from the PDN arrives at the S-GW, it signals the MME to page the UE. The UE is paged in all cells belonging to the TAs in which it is known. The UE is allowed to be registered in more than one TA in order to avoid frequent TAUs when it is moving in the region of TA boundaries. Figure 66

Intra-RAT mobility in ECM_IDLE DLpacket

S-GW

MME

MME

S-GW TAU

Tracking Area 1

Tracking Area 2

UEinIdleonlyperformsTrackingAreaUpdateonentrytoanew TrackingArea

Tracking Area 1

Tracking Area 2

OnarrivalofDLpacketasS-GW,MmepagesalleNBsinthe currentTrackingarea

ECM_CONNECTED Connection State In ECM_CONNECTED, the principal form of mobility management is backwards handover as illustrated in Figure 67: Intra-RAT mobility in ECM_CONNECTED which aims to minimize service interruption and packet loss. Based on measurements received from the UE, the current eNB (the source eNB) selects a target eNB and initiates the handover. The eNBs perform direct signaling over the X2 interface. The UE can access

Issue: 02B

DN0993921

93



the target eNB after the resources are reserved and the bearers are set up. In order to avoid packet loss, for those applications that require it, the source eNB will forward unreceived DL packets (those which have yet to be sent to the UE or yet be acknowledged by the UE) to the target eNB directly over X2. The target will not deliver packets received from the S-GW until it has delivered all forwarded packets. Between detaching from the source eNB and attaching to the target, the UE will buffer UL packets. The Serving Gateway performs late path switching. This means that the downlink path is not switched to the target eNB before the handover is completed. This avoids packet bicasting. If there is no X2 connectivity between the eNBs, signaling is performed via the MME(s) using S1. Figure 67 a)

Intra-RAT mobility in ECM_CONNECTED b)

eNB

source

eNB

source

target

eNB

UEcontext

Measurement Report

S-GW

S-GW target

c)

eNB

Handover Preparation

d)

eNB

source

IntereNB Signaling overX2

eNB

source

S-GW DLpackets forwarded overX2

target

S-GW Hardcover Complete

eNB target

eNB

BufferUIpacketswhile detachingfromsource eNBandattachingto targeteNB

e)

Hardcover Complete

source

MME

f)

eNB

source

eNB S-GW Release Resources

target

eNB

S-GW target

eNB

5.4 Tracking Areas If the network wishes to communicate with a UE that is in EMM-REGISTERED and ECM_IDLE states then it needs to have some information about where the UE is. This is handled using the tracking area concept as illustrated in Figure 68: Multiple-TA registration concept. Each cell belongs to a single tracking area (TA).

94

DN0993921

Issue: 02B


g


Note: Different cells in a single eNB can belong to different tracking areas; however, each cell can only belong to one tracking area. A UE registers with a TA and the information of which TA the UE is registered with is held in the MME which serves the TAs. An MME allocates the UE a Globally Unique Temporary UE Identifier (GUTI) which includes an identifier for the MME that allocated it and an identifier for the UE that is unique within the MME (and within the pool of MMEs). A shortened form of the GUTI is the S-TMSI which uniquely identifies the UE within a given TA. Thus when a UE is in ECM_IDLE state, the MME can request within a TA that the UE with the required S-TMSI (or IMSI) moves into ECM_CONNECTED state. This is done by Paging. When a UE moves TAs it has to perform the Tracking Area Update (TAU) procedure.

5.5 Tracking Area Update The Tracking Area Update (TAU) procedure enables the EPC to track the location of moving UEs while they are in the ECM_IDLE state. It takes place when a UE that is registered with an MME and/or a SGSN selects an E-UTRAN cell. The procedure is initiated by the UE if the UE changes thereby to a Tracking Area that the UE has not yet registered with the network or if the P-TMSI update status is “not updated” because of bearer configuration modifications performed between UE and SGSN when Idle-mode Signaling Reduction (ISR) is activated. This procedure is initiated by an ECM_IDLE state UE and may also be initiated if the UE is in ECM_CONNECTED state. The procedure is managed by the MME, which tracks the UE locations. NAS signaling is used here with AS support limited to conveying NAS signaling messages between the UE and MME. The UE needs to be attached to the network (be in EMM-REGISTERED state) before the TAU procedure, so that the UE is authenticated and NAS security context is established. ISR Concept The Idle-mode Signaling Reduction mechanism allows the UE remaining simultaneously registered in an UTRAN/GERAN Routing Area (RA) and an E-UTRAN Tracking Area (TA) list. This allows the UE to make cell reselections between E-UTRAN and UTRAN/GERAN without a need to send any TAU or RAU request, as long as it remains within the registered RA and TA list. Consequently, ISR is a feature that reduces the mobility signaling and improves the battery life of UEs. This is important especially in initial deployments when E-UTRAN coverage will be limited and inter-RAT changes will be frequent. The cost of ISR is more complex paging procedures for UEs in ISR, which need to be paged on both the registered RA and all registered TAs. The HSS needs also to maintain two PS registrations (one from the MME and another from the SGSN). Multiple-TA Concept The LTE system supports the concept of multi TA registration which is similar to the preLTE 3GPP routing area concept, with the extension that the UE can be registered in more than one TA. The MME is aware of the UE location to the granularity of one or more tracking areas (TA set). This is illustrated in Figure 68: Multiple-TA registration concept.

Issue: 02B

DN0993921

95


Figure 68


Multiple-TA registration concept

UE1triggers TAUprocedure viaeNB1

TA5

TA3 eNB

eNB

eNB

eNB

eNB

TA1 eNB

eNB

eNB

eNB2 UE1belongsto TA1,Ta3,Ta2

eNB eNB

eNB

x eNB

eNB

eNB1

TA2

eNB

UE1belongsto TA2,TA4,Ta3

eNB 3

eNB

UE3triggers TAUprocedure viaeNB3

eNB

TA4 UE2triggers TAUprocedure viaeNB2

x

eNB

x

UE1belongs toTa5

x=TAUprocedureistriggered

eNB

Triggers The TAU procedure is not triggered as long as the UE stays in any of its assigned tracking areas. As soon as the UE enters a tracking area which is not in the assigned set, the TAU procedure is initiated. As a result, the UE's set of TAs is updated or reassigned. The MME is responsible for the assignment which may vary on per-UE basis. This flexibility is beneficial in the sense that the TA load can be distributed within the network, and TAU signaling can be reduced at the TA borders (because of reduction of the so-called 'ping-pong' effect). The TAU procedure is also triggered periodically after expiration of the UE's internal timer. The UE discovers which tracking area it is in by listening to the broadcast channel. The cell broadcasts only one Tracking Area Identifier (TAI). It should be noted that a cell can belong to only one TA, but the eNB can support several cells, some of which could be in different TAs. The TAI consists of MCC, MNC and TAC identifiers which uniquely identify country, operator and UE location. The UE can also re-select a cell which belongs to UTRAN. In this case the UE is registered in LTE but not in UTRAN. When the UE selects a UTRAN cell, the routing area update procedure from E-UTRAN is also initiated. An MME can also force the UE to initiate the TAU procedure in order to re-allocate the GUTI, perform re-authentication, or to re-distribute load between MMEs by triggering the MME relocation procedure. These sub-procedures are optional parts of the TAU procedure. The TAU procedure involving MME relocation may also result in S-GW relocation; this decision is made by the target MME.

96

DN0993921

Issue: 02B



5.6 Paging A UE attached to the system and in ECM_IDLE state is traceable only to its registered TAs. Every time the EPC needs to contact such a UE, a paging procedure is initiated. This action provides the EPC with knowledge of the whereabouts of the UE (that is, which cell it belongs to). Paging consists of: • •

paging on S1 [3GPP-36.413] paging on Uu/RRC paging function [3GPP-36.331] – –

including scheduling of Paging messages in the time domain based on UE-specific and cell-specific DRX settings

Paging is also used to indicate System Information changes to idle UEs. Control By using the case where there is downlink data waiting at the S-GW to be delivered to a UE as an example, the S-GW requests the MME to page the UE. The MME then triggers a paging procedure as it is responsible for UE tracking. Its role involves control, execution and supervision of the procedure. These functions are realized using the S1AP protocol. The MME starts paging by distributing a paging request message to each eNB supporting cells corresponding to the UE's registered tracking areas. The MME also coordinates paging responses and supervises the process by scheduling retransmissions. Once the UE detects that it is being paged, a standard random access procedure is used and the UE enters RRC_CONNECTED state allowing the UE to send a NAS Service Request message which, once completed, enables the UE to receive U-plane data and to execute C-plane procedures. The eNB is entirely responsible for the scheduling and transmission of paging messages and for conveying a paging response to the MME. During such a procedure, the eNB allocates resources and schedules a two-stage paging process. Initially, a paging indication message is transmitted to alert all UEs in a paging group, and then a UE specific paging message is sent. Paging groups UEs are allocated to paging groups based on the UE identifier (IMSI or S-TMSI). UEs read L1 paging indication messages assigned to their paging group. A paging group is defined by an allocation of paging occasions. The UEs belonging to the group are required to listen to them. If a UE discovers that its group is being paged, it reads the paging message. This means that a UE only needs to listen to the full paging message if its group is being paged. Paging indication messages include information about how the paging message can be read and which physical resources have been allocated for it. The paging indication is repeated until the UE responds, or until the number of retries reaches a limit. UEs are configured with Paging Channel (PCH) DRX to enable periodic listening of the DL L1/L2 control channels. PCH DRX is UE specific, which means that DRX can vary per UE. UE paging

Issue: 02B

DN0993921

97



All UEs reading the paging indication assigned to their group read the paging message as well. If the UE's NAS Identity matches the one found in the paging message, the UE initiates the transition to ECM_CONNECTED.

5.6.1 Paging on S1 The paging function supports the delivery of paging requests to all cells of all TAs to which the UE is registered. Paging requests are sent to the relevant eNBs according to the mobility information kept in the UE's context in the serving MME. The MME initiates the paging procedure by sending the S1AP: PAGING REQUEST message to each eNB belonging to one of the TAs to which the UE is registered. The MME initiates paging when it wants a UE to perform a transition from ECM_IDLE to ECM_CONNECTED. Usually, this is triggered by the arrival of downlink data for an idle UE at the Serving Gateway (S-GW). Another reason could be that the MME wants to establish C-plane connectivity for other reasons, for example the network-initiated TAU procedure, or for location services. When the eNB receives an S1AP: PAGING REQUEST message, it forwards the paging request to each of its cells that support the UE's TA and PLMN ID. In each cell, the eNB collects all paging requests belonging to a single paging occasion and triggers the RRC paging function for that paging occasion.

5.6.2 Paging on Uu/RRC paging function In each paging occasion (in each cell), the eNB sends an RRC:PAGING message if at least one UE is scheduled for paging in that paging occasion. The RRC:PAGING message is sent via the PCCH logical channel using TM RLC. The paging occasion (schedule in time) of the paging messages is calculated, according to the following data: • • •

UE-specific information provided via S1AP cell-specific information configured by O&M and provided to the UE in System Information) current timing information in the eNB (that is, current System Frame Number)

In each cell the RRC paging function is executed independently of the other cells. Cellspecific and UE-specific settings of paging DRX are supported.

5.6.3 Paging of system information changes The eNB informs all UEs in RRC_IDLE and RRC_CONNECTED state about changes of System Information. It sends an RRC:PAGING message in each paging occasion during a System Information modification period N. The length of the modification period N is provided by System Information parameters. The modification period starts at the next SFN with (SFN mod N)=0. The paging occasions are derived by the cell-specific Paging DRX settings. In these paging occasions, the eNB provides the optional sysInfoModification IE in the RRC:PAGING message. In a single paging occasion, the RRC:PAGING message contains both the sysInfoModification IE and regular pagingRecords (if paging was triggered by S1AP); that is, the IEs are combined in one RRC message and are not sent in separate ones.

98

DN0993921

Issue: 02B



5.7 EPS bearers The EPS provides IP connectivity between a UE and a PLMN-external PDN. This is referred to as a PDN Connectivity Service. The PDN Connectivity Service supports the transport of one or more Service Data Flows (SDFs). For a GTP-based S5/S8 reference point it is provided simply by an EPS bearer running between the UE and the P-GW. Figure 69: LTE/EPC service data flows illustrates the LTE/EPC service data flow in more detail. Figure 69

LTE/EPC service data flows Application / Service Layer

UL Service Data Flows

DL Service Data Flows

UL-TFT

DL-TFT

UL-TFT → RB-ID

DL-TFF →

RB-ID ↔ S1-TEID

S1-TEID ↔

Radio Bearers

S5/S8a-TEID

GTP-U

GTP-U

GTP-U

GTP-U

S-GW

eNB

UE

S5/S8aTEID

S1 Bearers

P-GW S5 /S8 Bearers

The EPS bearers correspond to the PDP context in 2G/3G networks, being composed of the sub-bearers as illustrated in Figure 70: LTE/EPC EPS high level bearer model. The EPS bearer is used to transport user data between the UE and the P-GW/S-GW. •

• •

A radio bearer transports the packets of an EPS bearer between the UE and the eNB. If a radio bearer exists, there is a one-to-one mapping between an EPS bearer and this radio bearer. An S1 bearer transports the packets of an EPS bearer between the eNB and the Serving-Gateway (S-GW). An S5/S8a bearer transports the packets of an EPS bearer between the Serving GW and the PDN Gateway (P-GW).

An E-UTRAN Radio Access Bearer (E-RAB) refers to the concatenation of an S1 bearer and the corresponding radio bearer. When a data radio bearer exists, there is a one-toone mapping between the data radio bearer and the EPS bearer/E-RAB. Figure 70: LTE/EPC EPS high level bearer model shows the EPS bearer services layered architecture.

Issue: 02B

DN0993921

99


Figure 70


LTE/EPC EPS high level bearer model EPC

E-UTRAN

UE

eNB

S-GW

Internet

Peer Entity

P-GW

End-to-endService

EPSBearer E-RAB RadioBearer

ExternalBearer

S5/S8Bearer s1Bearer

Radio

S1

S5/S8

Gi

When the UE is active, all sub-bearers exist for the UE, but when it moves to idle state, S1 and radio bearers are released. However, EPS bearer and associated contexts in UE and EPS remain even though the UE is in idle state. A default EPS bearer is set up when UE attaches to the EPS network. There will be one default EPS bearer setup per PDN. The default EPS bearer is a Non-GBR bearer and it is “always-on”, that is, it is not released until the UE detaches from the PDN. The default EPS bearer's Traffic Flow Template (TFT) matches all packets, that is, it can be used for any kind of traffic. In addition to default the EPS bearer, dedicated EPS bearers can be set up for the UE. The dedicated EPS bearer can be either a GBR or a Non-GBR bearer and they are set up on network control, for example for VoIP calls. The Flexi Multiradio BTS supports up to three GBR EPS radio bearers per UE. Up to six data radio bearers (DRB) can be established per UE. Multiple DRB can be either multiple default EPS bearers or a combination of default and dedicated EPS bearers. The different EPS bearers per UE can have the same or a different QCI. The operator is able to offer additional service combinations.

5.7.1 Bearer management Bearer management provides the basic procedures to establish the default EPS bearer that provides an always-on service to the user. Bearer management is part of the LTE control plane and handles the establishment, modification, and release of bearers. Bearer management includes: • •

100

establishment and release of S1 bearers on the S1 interface establishment, modification, and release of data radio bearers on the air interface

DN0993921

Issue: 02B


•

•


translation of S1AP QoS parameters to configuration parameters of the U-Plane in eNB and UE, taking into account the UE capabilities and the QoS requirements of already established EPS bearers of the UE radio layer 2 configuration of SRB1 and SRB2

Bearer management supports: • • • • • • • • •

establishment of one non-GBR EPS bearer upon Attach and upon UE or EPC initiated Service Request preparation of one non-GBR EPS bearer and SRBs during handover provisioning of UE radio capabilities for radio bearer configuration activation of AS security (all security algorithms) service differentiation for non-GBR EPS bearers establishment and release for multiple default and dedicated EPS bearers support of the conversational voice EPS bearer that is mapped to a GBR with RLC UM control of robust header compression (ROHC) rate capping - support of the UE AMBR by the S1AP Initial UE Context Setup procedure

5.7.2 Quality of service LTE/EPC provides substantially optimized bearer handling and QoS model compared to 3G networks. In LTE/EPC, a single scalar label pointer, that is, the Quality Class Indicator (QCI), is used to a set of QoS parameters as highlighted in Table 8: QoS scheme for LTE. Table 8

QoS scheme for LTE

3G (QoS aware) Residual BER

LTE (Non-QoS aware) Quality Class Indicator (QCI)

SDU error rate Delivery of erroneous SDUs Max. SDU size Delivery order Transfer delay Traffic class Traffic priority handling ARP Max. bit rate

Issue: 02B

DN0993921

101


Table 8


QoS scheme for LTE (Cont.)

3G (QoS aware)

LTE (Non-QoS aware)

Guaranteed bit rate Aggregate max. bit rate (AMBR)

The following summarizes the main features of the LTE/EPC QoS model: network-centric QoS scheme deployed in LTE reduces complexity of UE implementations always on default EPS bearer available after initial access further dedicated EPS bearer setup on network control (e.g. for VoIP calls) no need to require support from terminal application clients or device operating system

• • • •

Table 9: Standard QCI characteristics shows some example standard QCI characteristics, identifying the possible packet delay budgets, packet loss rates, and appropriate services. Table 9

QCI

Resource Type

Priority

Packet Delay Budget

Packet Loss Rate

Example Services

2

100 ms

10-2

Conversational Voice (VoIP)

2

4

150 ms

10-3

Conversational Video (Live Streaming)

3

3

50 ms

10-3

Real Time Gaming

4

5

300 ms

10-6

Non-Conversational Video (Buffered Streaming)

1

100 ms

10-6

IMS Signaling

6

6

300 ms

10-6

Video (Buffered Streaming) TCP-based (for example, www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

7

7

100 ms

10-3

Voice, Video (Live Streaming) Interactive Gaming

8

8

300 ms

10-6

9

9

Video (Buffered Streaming) TCP-based (for example, www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

1

5

102

Standard QCI characteristics

GBR

Non-GBR

DN0993921

Issue: 02B


g


Note: The standardized characteristics are not signaled on any interface. They should be understood as guidelines for the pre-configuration of node-specific parameters for each QCI. The goal of standardizing a QCI with corresponding characteristics is to ensure that applications/services mapped to that QCI receive the same minimum level of QoS in multi-vendor network deployments and in case of roaming. A standardized QCI and corresponding characteristics is independent of the UE's current access (3GPP or Non-3GPP). Operator specific QCI The operator can define up to 21 additional QCIs for non-GBR EPS bearers. The Flexi Multiradio BTS supports non-GBR QCI groups to combine QCI specific performance counters. The mapping from the standard QCIs and the operator specific QCIs onto the QCI group performance counters is operator configurable. With the LTE1231: Operator-specific GBR QCIs feature, up to 21 operator-specific QCIs for GBR EPS bearers are supported per eNB. The total maximum number of operatorspecific QCIs (GBR and non GBR) is 21. The support of operator-specific QCIs can be enabled/disabled per eNB by O&M settings. eRAB Modification With LTE519: eRAB Modification feature it is possible to change the following: • • •

the QCI (QoS class indicator) value of non-GBR (guaranteed bit rate) QCIs the ARP (allocation and retention priority) value of all QCIs the UE-AMBR (aggregate maximum bit rate) of an UE

With this feature it is possible to change the QoS of a eRAB dynamically. The QCI of an EPS bearer with QCI=5 can not be changed if it is used for signaling. The LTE1321: eRAB Modification – GBR feature enables adapting the bit rate for GBR bearers, based on current needs for resources. This feature is an enhancement of the LTE519: eRAB Modification feature.

5.8 Additional services The following additional services are valuable for the end-user experience. Commercial Mobile Alert System With LTE494: Commercial Mobile Alert System feature the Flexi Multiradio BTS supports Commercial Mobile Alert System (CMAS). The CMAS notifications are sent by the MME to the eNB via the S1AP:WRITE-REPLACE WARNING REQUEST. UEs in RRC_IDLE and in RRC_CONNECTED are informed via paging about the presence of CMAS notifications. With this functionality the operator is able to support public warning service. Earthquake and Tsunami Warning System

Issue: 02B

DN0993921

103



The Flexi Multiradio BTS supports Earthquake and Tsunami Warning System (ETWS) by a warning delivery procedure. Broadcast of primary and secondary notifications are supported. Broadcast of primary notification is an immediate warning about threat, like earthquake and/or tsunami, secondary notifications is for delivering additional information, like where to get help. Multimedia Broadcast Multicast Service (MBMS) The LTE1117: LTE MBMS feature introduces the Multimedia Broadcast Multicast Service (MBMS), which is a point-to-multipoint service allowing efficient multimedia delivery from a single source entity to multiple recipients, using broadcast services. The MBMS can be used, for example, for mobile TV and radio broadcasting.

104

DN0993921

Issue: 02B


Transport and transmission

6 Transport and transmission This chapter provides information about the following transport and transmission issues: • • • • • • •

LTE transport overview Transport interface options Transport switching in eNB IP addressing Traffic engineering Synchronization Transport admission control

•

6.1 LTE transport overview This section contains general information on LTE transport. The logical interfaces share the physical transport interface(s) at the eNB. Typically, several instances of the X2 interface are present, one per adjacent eNB. The eNB supports multiple S1-MME and multiple S1-U interfaces. The relevant logical interfaces are: • • • • •

X2-U, eNB to eNB for user plane traffic (GTP-U tunneling) X2-C, eNB to eNB for control plane traffic (X2AP protocol) S1-U, eNB to S-GW for user plane traffic (GTP-U tunneling) S1-MME, eNB to MME for control plane traffic (S1AP protocol) O&M i/f, eNB to O&M system for O&M data

Figure 71: Architecture of LTE transport below shows the SAE/LTE network architecture and the logical interfaces established in the transport layer. Figure 71

Architecture of LTE transport aGW S1_MME S1_U O&Mi/f

MME S11

eNB

S-GW

X2_U X2_C S1_MME S1_U O&Mi/f

O&M System

eNB

Issue: 02B

DN0993921

105



Protocol stacks for User (U), Control (C), Synchronization (S), and Management (M) planes are based on IPv4. The LTE125: IPv6 for U/C-Plane feature introduces option to use IPv6 in the protocol stack for User (U) and Control (C) planes. 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. Figure 72: Transport Protocol Stack OverviewFigure 73: Transport Protocol Stack Overview gives an overview on the eNB protocol stacks used on the S1, X2 and O&M interfaces. Layer 3 is always based on the IP protocol. Only Ethernet interfaces are supported, including electrical and optical layer 1 variants. Figure 72

Transport

Transport Protocol Stack Overview

S1_U X2_U

S1_MME X2_C

GTP-U

S1AP/X2AP

Mgmt.Appl.

UDP

SCTP

UDP/TCP

IPv4/IPv6

IPv4/IPv6

Ipv4

EthernetLayer2

EthernetLayer2

EthernetLayer2

EthernetLayer1

EthernetLayer1

EthernetLayer1

Figure 73

Transport

O&Mi/f

Transport Protocol Stack Overview S1_U X2_U

S1_MME X2_C

GTP-U

S1AP/X2AP

Mgmt.Appl.

UDP

SCTP

UDP/TCP

Ipv4/IPv6

Ipv4/IPv6

Ipv4

EthernetLayer2

EthernetLayer2

EthernetLayer2

EthernetLayer1

EthernetLayer1

EthernetLayer1

O&Mi/f

IP based protocol stacks enable lower transport cost and easier planning and configuration. 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 in M-, C-, S- and U-plane. The IPSec throughput performance is sufficient for even the largest possible eNB configuration even if very strong encryption and integrity protection algorithms are used. Flexi Multiradio BTS interfaces to the backhaul connection are provided by fieldreplaceable 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 applications (multi-radio) with single mode operation. 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. It is possible to configure up to four application addresses and up to four interface IP addresses independently.

106

DN0993921

Issue: 02B



The eNB must support at least one peer IP address per MME. With the SCTP Multihoming feature, the eNB supports two separate C-plane IP addresses of the MME. The eNB support multiple S1-MME interfaces towards up to 16 MME nodes (S1 Flex feature). With LTE505: Transport Separation for RAN Sharing, operators which share the RAN can distinguish within the transport network the S1 traffic (U-plane and C-plane) of the different operators. In other words: independent transport network configuration is possible. The eNB supports two U-plane IP addresses and two C-plane IP addresses. For more information about RAN sharing, see RAN sharing section.

g

Note: The Zone eNB does not support the LTE505: Transport Separation for RAN Sharing feature in the initial release. The FlexiPacket Radio Connectivity feature introduces the eNB capability to manage a FlexiPacket Radio (FPR) system connected to an eNB Ethernet interface. The FlexiPacket Radio is a microwave point-to-point radio for connecting: • •

eNB to the transport network eNB to other eNBs

FlexiPacket Radio can be installed at the Flexi Multiradio BTS site without indoor unit. Local commissioning and management does not require interrupting backhaul traffic or touching cabling between the BTS and FlexiPacket Radio.

g

Note: The Zone eNB supports different transport capabilities. For further details, see Flexi Zone Controller Product Description.

6.2 Transport interface options The LTE/EPC architecture supports a wide range of physical interfaces and will not preclude the use of any physical medium with which it is efficient 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. Link Supervision with Bidirectional Forwarding Detection (BFD) and Fast IP Rerouting The Link Supervision with BFD feature implements single-hop Bidirectional Forwarding Detection (BFD) and multihop BFD support. BFD establishes a session between the eNB and an Router. Both BFD peers send BFD control packets. If no BFD control packet is received from the peer within a negotiated BFD interval, BFD notifies a link failure. Only asynchronous mode of BFD is supported. BFD establishes a session between the two endpoints over a link. The direct route to an eNB is supervised by BFD. The eNB supports the configuration of up to 16 BFD sessions. The Fast IP Rerouting feature introduces path switchover mechanism that is able to: •

Issue: 02B

define Primary Path (preferred) and Alternative Path (redundant) in the L2 network

DN0993921

107


•


reroute traffic from failed path over working path (with switchover time tolerable for an end user

Bidirectional Forwarding Detection (BFD) is used for L3 path failure detection. IP Transport Network Measurements The IP Transport Network Measurements feature introduces a possibility to actively measure and supervise the conditions through the mobile backhaul transport network between two points, using RFC863 UDP Echo and RFC5357 TWAMP protocols. Measurements can be performed, for example, between the eNB and SEG, between the eNB and other site router or measuring equipment or between two eNBs (X2 interface measuring). The purpose of the measurement is to have an estimation of the quality and performance of the IP-based mobile backhaul. If the measured values fall under configurable thresholds, an alarm is raised. With this feature it is possible to carry out the measurements with different, configurable DiffServ Code points and packet sizes. All measurements are performed on IP layer. Ethernet In LTE, the backhaul transport network is composed of an Ethernet transport network as illustrated in Figure 74: Ethernet backhaul for LTE/EPC. Commonly, a network terminating device (leased line termination, MWR IDU, xDSL CPE) 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

Figure 74

Ethernet backhaul for LTE/EPC

MME Eth Flexi Multimode BTS

IP/ Ethernet

IP/ Ethernet IPRouter (SecurityGW)

S-GW/P-GW

S 1/X 2 U/C-plane

S 1 U/C-plane

IP /IPSec

IP

IP /IPSec

E thMac

E thMac

E thMac

E thMac

E thP hy

E thP hy

E thP hy

E thP hy

The Ethernet interfaces, based on the IEEE 802.3-2002 standard (with type interpretation of the type length field, Ethernet II/DIX frame), support the following features: • • •

108

full-duplex transmission mode auto-negotiation and forced mode for the data rate MDI/MDIX

DN0993921

Issue: 02B


• • • • •


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 because of additional packet overhead (GTP-U, UDP, IP/IPSec). The Flexi Multiradio BTS LTE supports IP fragmentation and reassembly. With the Ethernet Jumbo Frames feature, the value for transport IP packets size is configurable up to 1608 bytes. Thus, if the size of user IP packets is not larger than 1500 bytes, there would not be a need to fragment transport layer IP packets.The LTE931: Ethernet Jumbo Frames feature enables MTU sizes up to 1608 for the FSMr2 and up to 1644 for the FSMr3. Ethernet OAM There are two complementary Ethernet OAM (E-OAM) protocols: •

•

Link Layer OAM (IEEE 802.3 clause 57, L-OAM) offers point-to-point link monitoring. When L-OAM is active, the operator can check instantly if the link to the peer is working or faulty. After connectivity is established, remaining supported L-OAM capabilities are checked. L-OAM protocol can be used for monitoring any point-topoint link. For example, a link between two directly connected (chained) eNBs. Service OAM (IEEE 802.1ag, ITU-T Y.1731, S-OAM) offers: – – – –

end-to-end Ethernet connectivity monitoring network segment connectivity monitoring Ethernet fault localization possibility to monitor the network for compliance with service guarantees

Once LTE140: Ethernet OAM feature is activated, and S-OAM protocol is in use, particular service instances can be monitored within a pure L2 network. The following SOAM capabilities are available: • • • • •

g

Ethernet Continuity Check (ETH-CC) Ethernet Alarm Indication Signal (ETH-AIS) Ethernet Remote Defect Indication (RDI) Ethernet Link Trace Ethernet Loopback

Note: The Zone eNB does not support the LTE140 feature in the initial release.

6.3 Transport switching in eNB The eNB supports an Ethernet switching function which allows minimizing the transport costs in the E-UTRAN by supporting: •

Issue: 02B

local eNB topologies such as chains and trees at the periphery of the E-UTRAN, minimizing the number and length of transport links employed.

DN0993921

109


•

g


transport sharing at a multi-radio site, allowing the sharing of the transport network between the eNB and base stations belonging to other RATs. The Ethernet switching function integrated in the eNB allows non-LTE equipment with Ethernet interfaces to share a common transport. Note: If an IP routing function is required, this must be provided by separate equipment. Similarly, equipment that uses non-Ethernet interfaces must be supported by separate equipment. In particular, an IP router can be used to perform protocol conversion and interworking between different technologies where required.

An example of E-UTRAN transport topologies is illustrated in Figure 75: Example of EUTRAN transport topologies. Figure 75

Example of E-UTRAN transport topologies

EPC EPC EPC

chain

tree

Traffic aggregation towards mobile backhaul The LTE649: QoS aware Ethernet switching feature introduces integrated, QoS aware Ethernet switching between the external eNB Ethernet ports, or between the external ports and local eNB functions. The eNB transport sub-module has multiple Ethernet ports (FTLB supporting up to three ports, FTIB supporting up to two ports), connected through an integrated Ethernet switch. One port is typically used for the backhaul connection, while other ports may be connected to other radio equipment. The Ethernet switching can be used for aggregation of traffic from other eNBs, NBs or 2G BTSs which could be located at the same or other sites. It is also possible to daisy-chain several network devices if chained devices support Ethernet switching as well. This feature eliminates the need for a separate switch device for daisy-chaining at the eNB site. For more information, see Functional Area Description LTE Transport.

g

110

Note: The Zone eNB does not support the LTE649 feature.

DN0993921

Issue: 02B



6.4 IP addressing The eNB supports flexible addressing, which allows separate addressing of its network interfaces (transport interfaces) and eNB applications. Addressing scheme supports use cases with and without IPsec and with and without VLANs. The requirements to the addressing scheme are illustrated in Figure 76: Network configuration with four VLANs and Figure 77: Network configuration without VLANs. Network configurations are based on the following assumptions: each eNB application uses its own addresses separated core nodes separated SEG and VLAN GW nodes

• • •

Figure 76

Network configuration with four VLANs

eNB VLANGW

VLAN#1

Inter.IP Addr.#1

NetworkInterf. IPAddr.#1

UP

SEG S-GWIPSec Tunn.Addr.#1

S-GW S-GW IPAddr.

CP

InternalRouter/IPSec

32 Network Interface Termination

1 adj. eNB


MME MME IPAddr.

VLAN#2


SP

SEG MMEIPSec Tunn.Addr.

TransportNetwork NetworkInterf. IPAddr.#3

MP

VLANGW Inter.IP Addr.#2

VLAN#3


VLAN#4


SEG O&MIPSec Tunn.Addr. SEG ToPIPSec Tunn.Addr.

O&M IPAddr. SSEContr. IPAddr.

ToPMarker IPAddr.

SSE eNBSSE IPAddr.

IPSectunnelpair(onetunnelperdirection)

Figure 76: Network configuration with four VLANs presents a case where each plane (UP, CP, MP, and SP) is bound to a separate interface IP address. With this, in the IPsec tunnel mode, the inner and outer addresses of the packets are identical within each plane.

Issue: 02B

DN0993921

111



Figure 77

Network configuration without VLANs

eNB

UP

Network Interface Termination

SEG

Virtual.IP Addr.#1

S-GW

S-GWIPSec Tunn.Addr.#1

S-GW IPAddr.

SEG MMEIPSec Tunn.Addr.

MME MME IPAddr.

32

CP

MP

Virtual.IP Addr.#2

InternalRouter/IPSec

1 adj. eNB Network Interf.IP Addr.#1

TransportNetwork SEG O&MIPSec Tunn.Addr.

Virtual.IP Addr.#3

O&M IPAddr. SSEContr. IPAddr.

SEG SP

ToPIPSec Tunn.Addr.

Virtual.IP Addr.#4

SSE eNBSSE IPAddr.

ToPMarker IPAddr.

IPSectunnelpair(onetunnelperdirection)

IP addressing in the eNB is based on two parts: addressing at the eNB side, and addressing external peer nodes from the eNB side.

g

Note: The Zone eNB has specific configurations that are supported. For more information see Flexi Zone Controller Product Description and Commissioning Flexi Zone Controller.

6.4.1 Addressing at the eNB side The following types of IP addresses are supported: •

112

Network interface IP addresses (Interface IP addresses). These are assigned to network interfaces which are used for connecting the eNB to the external transport network (see Figure 76: Network configuration with four VLANs). The network interfaces are layer 2 interfaces such as, for example, Plain Ethernet or VLAN interfaces. The eNB supports the configuration of one to four Interface IP addresses. Each address includes a subnet mask. One separate Interface IP address is required per configured VLAN. All interface addresses must be from different subnets. In case of LTE132: VLAN Based Traffic Differentiation, each configured layer 2 interface is addressed at the IP layer by one separate network interface IP address. In case of the IPsec tunnel mode, these addresses are also used as IPsec tunnel endpoint addresses. When the VLAN function is deactivated (LTE132: VLAN Based Traffic Differentiation), a single Interface IP address is sufficient per eNB.

DN0993921

Issue: 02B


g


Note: The LTE491: FlexiPacket Radio Connectivity feature introduces the eNB capability to manage a FlexiPacket Radio (FPR) system connected to an eNB Ethernet interface. It includes the management of a near-end (NE) and the associated far-end (FE) radio termination from a Local Management Terminal (LMT) which is connected at the Local Management Port (LMP) of the eNB. The two main operating use cases for the FlexiPacket Radio management are possible: – –

The FPR management traffic uses the FPR Payload Channel together with the U/C/M/S-plane traffic period The FPR management traffic is carried through the so-called R-Channel which is dedicated to FPR management purposes period

If FPR management traffic is carried through the R-Channel, a dedicated VLAN has to be configured. The FPR VLAN can be configured regardless of whether the LTE132: VLAN Based Traffic Differentiation feature is enabled or disabled. A maximum of nine VLANs can be configured depending on the activated LTE features. •

•

g

Virtual addresses. These are IP addresses that are not assigned to network interfaces. Virtual addresses are typically assigned to individual applications of the eNB if these must be separately addressable from the mobile operator core network side (see Figure 77: Network configuration without VLANs). When using the IPsec tunnel mode, virtual addresses cannot be reached from the external transport network. When not using the IPSec tunnel mode, virtual addresses can only be reached indirectly from the external transport network. Between zero and four Virtual IP addresses may be configured per eNB. Dual U-plane IP Addresses. The LTE1771: Dual U-plane IP Addresses feature distributes the S1 U-plane traffic to two IP addresses, which enables the utilization of two physical Ethernet interfaces (2xGE or 2xFE) and/or different paths while keeping UE flows intact. Note: The Zone eNB does not support the LTE1771 feature.

The eNB supports the independent configuration of any combination of interface IP addresses and application IP addresses. Depending on the activated features, the operator is able to configure up to nine application IP addresses and up to nine interface IP addresses which may be completely independent from each other. Binding of eNB applications to eNB addresses In the simplest configuration, the eNB includes separate applications for the U-plane, Cplane, M-plane, and S-plane. Each application can be freely bound either to a virtual address or to an interface address. The binding is used in the transport subsystem for eNB internal forwarding of received DL packets to the addressed applications. In addition, the applications insert the address to which they are bound into the Source Address field of UL packets. To reduce the number of IP addresses, multiple applications can be bound to one common address. Received DL packets to an IP address to which multiple applications are bound must be forwarded towards the applications based on higher layer information, for example, Protocol ID, layer 4 port number, or IP source address. In the most extreme case, all applications of the eNB could be bound to a single address. The binding of an application to a virtual address does not determine the interface over which a UL packet will be sent out. This is determined by the IPsec policy database and/or the internal UL routing table.

Issue: 02B

DN0993921

113



When the transport network and mobile operator network use a common transport domain, it is possible to bind applications to Interface IP addresses. In that case, the applications are addressed by the interface addresses. When using IPsec in a tunnel mode, the “outer” and “inner” address fields of the IPsec header will carry the same address.

g

Note: The eNB supports up to nine network interfaces within one physical Ethernet interface. These can be used for up to nine VLAN interfaces or up to eight VLAN interfaces and one plain Ethernet interface. FPR VLAN is included here. Addressing Site Support Equipment (SSE) The eNB supports connecting Site Support Equipment (SSE) via one dedicated external interface. It is possible to configure an IP subnet at the eNB that allows routing of packets toward the SSE devices. The eNB supports connecting Site Support Equipment (SSE) devices via up to two local native Ethernet interfaces as shown in Figure 78: Connection of SSE to eNB. Figure 78

Connection of SSE to eNB eNB

SSE eNBSSE IPAddr.#1

SSE eNBSSE IPAddr.#n

External Ethernet switch (optional)

O&M

eNBMP IPAddr.

Internal Ethernet (switch)

SSE Interface IPADDR

IPSec/ Router

Interface IP Address

SEG

SSEControl

O&MIPSec Tunn.Addr.

SSEControl IPAddr.#1 SSEControl IPAddr.#n

LMT SSEDHCP Server

The Ethernet interfaces shall support the following sub-features: • •

Layer 1: 100BaseT, full-duplex Layer 2: Ethernet format according to IEEE 802.3-2005

The transport subsystem supports Dynamic Host Configuration Protocol (DHCP) server functionality (according to RFC2131, RFC2132 and RFC3004) for providing external SSE clients with IPv4 addresses and other DHCP-supported network parameters, if required. The DHCP server supports static and dynamic IP address assignment for any IP host attached to the SSE LAN. The DHCP protocol is supported exclusively at the SSE interface. The DHCP server configuration is done via an LMT client (connected over one of the external SSE interfaces), or Site Configuration File (SCF). SSE interfaces do not need to support: • •

shared MAC with half-duplex VLAN and Ethernet QoS support according to IEEE802.1q

All SSE devices at one eNB should be within one subnet. The number of SSE devices which can be connected depends on the configured subnet mask. If more than one SSE device needs to be attached to one eNB, it is recommended to use an external, local Ethernet switch. Furthermore, it is assumed that each SSE device is controlled in a point-to-point fashion by a dedicated control application within the SSE Control unit. Each of these applications is identified by a separate IP address.

114

DN0993921

Issue: 02B


g


Note: The Zone eNB and FZM do not support the Addressing Site Support Equipment (SSE).

6.4.2 Addressing external peer nodes from the eNB side External peer nodes of the eNB are: S-GW, MMEs, adjacent eNBs, O&M, SSE Control and ToP Master. The peer nodes can be addressed using: • •

•

IP addresses of the peer nodes IPsec Tunnel Addresses: In the IPsec tunnel mode, these addresses are the peer addresses corresponding to the eNB Interface IP addresses. In the eNB, you can independently configure separate IPsec Tunnel Address(es) for each core network IP address. Typically, the IPsec tunnels are terminated in a SEG node that is physically separated from the other elements at the core side. Next Hop IP address(es): These addresses are used to identify the next router, that is, the next node which has an IP layer. In case of VLANs, this would be a VLAN GW, and one address is required per configured VLAN. In a routed network, this is simply the address of the next hop router.

All Interface IP addresses of all eNBs and of the VLAN GW which are interconnected by one VLAN must be part of the same IP subnet. In typical scenarios, several peer nodes of an eNB at the core side coincide, and their addresses can be chosen within the same IP subnet, and common network addresses can be used for them.

6.5 Traffic engineering The following traffic engineering concepts are considered: • • •

Traffic prioritization Traffic differentiation Traffic shaping

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

Issue: 02B

DN0993921

115



Figure 79

QoS differentiation between user, control and management plane traffic

MME any

IP IP Router (S ecurity G W )

Flexi Multimode BTS

S-GW/P-GW

U-plane

C-plane

S-plane

M-plane

(User) IP G TP -U

S 1AP /X 2A P

PTP

B TS O M

UD P

S CTP

UDP

TCP

U-plane Q oS mapp ing (DS CP )

IP

116

C-plane

S-plane

M-plane

G TP -U

S 1A P

PTP

B TS O M

UD P

S CTP

UDP

TCP

(User) IP

IP

IP

IP

IP

L2

L2

L2

E thMac

E thMac

E thMac

E thMac

L1

L1

L1

thPhy hy EEthP

E thP hy

E thP hy

E thP hy

IP

DN0993921

Issue: 02B



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 80: Traffic prioritization on the Ethernet layer, using packet marking methods. 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 DSCP-to-PCP (Priority Code Points) mapping table is configurable. Figure 80

Traffic prioritization on the Ethernet layer, using packet marking methods

MME Ethernet

Eth

IP Router (S ecurity G W )

Flexi Multimode BTS

S-GW/P-GW

U-plane

C-plane

U-plane

M-plane

(User) IP

C-plane

M-plane

G TP -U

S 1A P

B TS O M

UD P

S CTP

TCP

(User) IP

G TP -U

S 1AP /X 2A P

B TS O M

UD P

S CTP

TCP

Q oS marking

IP E thMac E thP hy

IP E thernet S witching E thP hy

E thP hy

IP

IP

E thMac

E thMac

E thMac

E thP hy

E thP hy

E thP hy

6.5.2 Traffic differentiation It is common practice that M-plane and U/C/S-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 each application may be separated via VLANs. Figure 81: M-plane traffic differentiation using VLAN over Ethernet illustrates one example, that M-plane (O&M) traffic can be separated from U/C-plane traffic, using another IP address from a different subnet.

g

Issue: 02B

Note: Layer 2 traffic differentiation is not restricted to the differentiation between Uplane and M-plane traffic, but may also be applied in a flexible manner, for example between U-plane and C-plane traffic.

DN0993921

117



Figure 81

M-plane traffic differentiation using VLAN over Ethernet

V LA N1

M-P lane

Ethernet

Eth V LA N2

Flexi Multimode BTS

IP Router U/C-P lane

MME IP/ Ethernet

S-GW/P-GW

6.5.3 Traffic shaping The Flexi Multiradio BTS LTE Ethernet interface (FE or GE) may at times generate bursts of traffic which can exceed the capacity of the Ethernet backhaul link. In particular in Ethernet leased lines where the link capacity is governed by a Service Level Agreement (SLA), such bursts may not be accepted and the excessive packets are then dropped by equipment of the line’s operator. Traffic shaping in the Flexi Multiradio BTS LTE is required to ensure conformance to the link capacity in order to minimize packet loss in the network. It reduces the burstiness of outgoing 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 is done based on priorities (QoS aware). Flexi Multiradio BTS LTE performs single-stage shaping according to MEF 10.1. Traffic shaping can be performed per VLAN or at the Ethernet port level.

6.6 Synchronization By means of the air interface synchronization, the eNB keeps the frequency accuracy and the phase accuracy of its air interface within specified bounds. As per 3GPP requirement, the air interface at an eNB (in FDD or TDD mode) needs to be frequency synchronized with an accuracy of 50 ppb.In FDD mode, the Flexi Multiradio BTS LTE offers the configuration of several clock reference sources and a priority order among them. Synchronization source selection runs in two ways: •

With input at the system control module. The eNB system control module (FCM) supports two external synchronization sources: – –

118

Global Positioning System (GPS)/Pulse Per Second (PPS) external reference clock 2.048 MHz external reference clock; this signal is provided for the SYNC input at the eNB system control module, it has accuracy according to [ITU-TG.812]

DN0993921

Issue: 02B


•


When both GPS/PPS and 2.048 MHz clock signal are present at the external synchronization inputs of FCM, the eNB locks to GPS/PPS reference signal. When either GPS/PPS or 2.048 MHz clock signal is present at the external synchronization inputs of the FCM, the eNB clock generator locks to these synchronization signals. When no valid clock signal is present at the synchronization inputs of the FCM, the eNB locks to synchronization sources carried via the eNB transport subsystem (FTM). With input at the transport subsystem. The eNB supports selection of two synchronization sources out of the following sources, which are assigned to the different priority levels: – – –

Synchronous Ethernet Timing over Packet Synchronization from PDH interface

The Flexi Zone Access Point (FZAP) supports GPS, SyncE, and Timing over Packet (ToP). The LTE1710: Sync Hub Direct Forward feature provides a more efficient and accurate Phase/Time synchronization distribution to all BTSs at the same site, regardless if RF sharing is used or not. This allows all RF sharing sites to support applications that require Phase/Time Synchronization.

g

Note: The Zone eNB does not support the LTE1710: Sync Hub Direct Forward feature. Synchronization in CRAN CRAN supports all synchronization sources from the LTE1710: Sync Hub Direct Forward feature and utilizes them for synchronization.

6.6.1 Synchronization from GPS Synchronization from GPS interface is a field-proven technology.

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 signal for synchronizing Flexi Multiradio BTS LTE, as illustrated in Figure 82: Synchronization from 2.048 MHz signal. Figure 82

Synchronization from 2.048 MHz signal IP/ Ethernet

Eth SYNC

Flexi Multimode BTS

g Issue: 02B

2.048Mhz

E1/T1

SYNC

TDM

BTS

Note: The FZM does not support the synchronization from 2.048 MHz signal.

DN0993921

119



6.6.3 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, provided that all intermediate Ethernet nodes and the other end support the Synchronous Ethernet feature as per G.8261.

6.6.4 Timing over Packet Timing over Packet (ToP), based on IEEE 1588-2008, is another method to support synchronization if Flexi Multiradio BTS LTE is connected through Ethernet/IP backhaul, as illustrated in Figure 83: ToP based synchronization. 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 in terms of 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 the slaves communicate through the IEEE 1588-2008 protocol. The master sends synchronization messages via the Ethernet/IP network to the slaves. The slaves recover the synchronization reference from the synchronization messages sent by the master. All synchronization traffic is transported within the Synchronization plane, or S-plane. Figure 83

ToP based synchronization ToP Master TimingoverPacket(IEEE1588-2008)

Eth

Eth

IP/ Ethernet

Flexi Multimode BTS

MME

S-GW/P-GW

The following features are supported in order to provide the ToP synchronization: • •

LTE891: Timing over Packet with Phase Synchronization LTE134: Timing over Packet with Frequency Synchronization

The features provide synchronization of a BTS through the packet network based on IEEE 1588-2008. ToP with Phase Synchronization The ToP solution for phase synchronization consists of a PTP Grand Master at the core site, PTP Boundary Clocks (BC) on at least some selected nodes on the backhaul network, and a PTP Slave implemented in the eNB. The usage of BC in the backhaul network is needed in order to achieve the required phase synchronization accuracy. ToP with Frequency Synchronization

120

DN0993921

Issue: 02B



The ToP solution for frequency synchronization is one of the available methods to support synchronization if a Flexi Multiradio BTS LTE is connected through an IP/Ethernet backhaul. It consists of a master clock (ToP Master) at the core site and slave clocks (ToP Slaves) implemented in the eNBs. The master and slaves communicate through synchronization messages via the Ethernet/IP network. The slaves recover the synchronization reference from these messages. This synchronization is required to maintain a stable frequency of the eNB’s air interface.

6.6.5 Synchronization from PDH interface Synchronization from PDH interface is the conventional method applied at 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 synchronization is usually implemented at the core site. With respect to the Flexi Multiradio BTS LTE, the PDH line is used for synchronization purposes only.

g

Note: The FZM does not support the synchronization from the PDH interface.

6.6.6 Hybrid synchronization The LTE942: Hybrid Synchronization feature combines the application of two different and independent synchronization source modes in two variants: •

•

Timing over Packet for phase synchronization (ToP-P) as the primary phase synchronization source and Synchronous Ethernet (SyncE) as the secondary (frequency) synchronization source. GPS/1pps as the primary phase synchronization source and Synchronous Ethernet (SyncE) as the secondary (frequency) synchronization source.

6.7 Transport admission control Apart of the already described traffic prioritization, which provides relative QoS (see section Traffic prioritization), the LTE system relies in addition on the efficient use of system resources to provide end-to-end quality of service (QoS). This actually refers to a number of resource control mechanisms like flow control, congestion control, and admission control. With the Connection Admission Control (CAC) function the eNB can accept or reject a connection request based on the current load situation. Whereas air interface resources are being checked with Radio Admission Control (RAC), the Transport Admission Control (TAC) adds checking of available transport resources to accepting a bearer request. Basically, admittance to the system is granted if, at time of connection request, both RAC and TAC expect to have the resources available for the time the connection will be active. This is especially important for real-time applications like voice (VoIP), video streaming, online games, or IP-TV, which are delay sensitive and may require a guaranteed fixed bit rate. It is assumed that Guaranteed Bit Rate (GBR) traffic is handled on the transport network with higher priority than other kinds of traffic, and may pre-empt lower-priority traffic. In order to support a guaranteed bit rate, it is common practice to permit GBR connections (traffic) only up to a certain committed bit rate.

Issue: 02B

DN0993921

121



The LTE1401: Measurement based TAC feature grants or rejects requests based on measurement of the actually used transport bandwidth. It is a functional enhancement of the LTE144: Transport Admission Control feature which is based on book-keeping of estimated transport bearer bandwidths. This Transport Admission Control is done for Guaranteed Bit Rate (GBR) traffic only.

6.8 Architecture of LTE datapath management Figure 84: Architecture of LTE datapath management presents the architecture of an LTE network. The Serving Architecture Evolution Gateway (SAE GW) and Mobility Management Entity (MME) are shown as two separate nodes. Figure 84

Architecture of LTE datapath management EnvolvedPacketSystem(EPS) EvolvedPacketCore(EPC)

EvolvedUTRAN(E-UTRAN)

S1-C E-UTRANUu

S1-U MME

SAE-GW S11 X2-C

X2-U

S1-U

E-UTRANUu

S1-C

C-plane(S1-AP,X2-AP)

U-planeGTP-Utunnel U-planel

C-plane

S1-MME interface (C-plane) Traffic consists of S1 Application Protocol (S1-AP) signaling messages carried over the SCTP protocol. The interface transfers signaling data related to mobility management, (for instance, an inter-eNB handover) or to other management tasks such as S1 signaling bearer management. S1-U interface (U-plane) At S1-U, the GPRS Tunnelling Protocol for the user plane (GTP-U) encapsulates IP packets to be carried over the GTP tunnel between the eNB and the Serving Gateway (S-GW). This mechanism, called tunnelling, is used extensively in the LTE/SAE network architecture. X2 interface (C-plane and U-plane) Control plane traffic related to: •

122

handover signaling

DN0993921

Issue: 02B


• •


inter-cell RRM signaling X2 interface management signaling

consists of the X2 application protocol (X2-AP) signaling messages. On the user plane, X2 carries data between the source and target eNBs during a lossless inter-eNB handover. For this purpose, a GTP-U tunnel is established over the X2 interface. The X2-AP is defined in 3GPP36.423 technical specification.

6.8.1 S1 transport architecture Figure 85: S1 transport architecture presents: • • • •

GTP-U role within the S1 transport architecture unidirectional GTP-U datapath handling between S-GW and eNB bidirectional EPS bearers S1AP protocol setup by MME and eNB on top of SCTP (S1-MME)

Figure 85

S1 transport architecture

MME

SAE-GW

GTP-Ucontrol instance

IP

IP

GTP-U

GTP-U

S11 receiving tunnel entity

sending tunnel entity

S1-AP SCTP

S1-U

S1-MME eNB(receivingside)

eNB(sendingside)

GTP-U

SCTP

GTP-U receiving tunnel entity

S1-AP GTP-Ucontrol instance

R R C


PDCP

PDCP

RLC

RLC

MAC

MAC

RLC

PHY

C-plane U-plane(EPSbearer)

Issue: 02B

DN0993921

123



6.8.2 X2 transport architecture Figure 86: X2 transport architecture presents: • • • •

GTP-U role in inter-eNB handover within the X2 transport architecture unidirectional GTP-U datapath handling between S-GW and eNB U-plane forwarding principles at source and target eNBs if DL data is forwarded X2AP protocol setup by MME and eNB on top of SCTP (X2-C)

Figure 86

X2 transport architecture

SAE-GW IP

IP

GTP-U

GTP-U


S11


S1-U

TargeteNB

SourceeNB GTP-U


GTP-U


PDCP

PDCP

PDCP

PDCP

RLC

RLC

RLC

RLC

MAC

MAC

MAC

MAC

PHY

PHY

PHY

PHY

X2-U

receiving tunnel entity

receiving tunnel entity

eNBC-plane eNBC-plane

MME

GTP-U controlinstance

SCTP

124


S1-AP

X2-AP

SCTP

SCTP

C-plane

dataforwardingforhandover)

U-plane(EPSbearer)

alternativedataforwardingforhandover)

DN0993921

GTP-U controlinstance X2-C

S1-MME

S1-AP



X2-AP

X2-AP

SCTP

SCTP

Issue: 02B


Operability

7 Operability This chapter provides information about the following operability issues: • • • • • • •

Operability architecture NetAct framework 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 Operability architecture The LTE/EPC network management system based on the NetAct OSS framework has been designed for scalability, supporting different network sizes. From a user’s point of view, managing the LTE/EPC network is very similar to that of WCDMA when NetAct is in use. For an overview see Figure 87: LTE/EPC Operation and maintenance concept. Figure 87

LTE/EPC Operation and maintenance concept

NetAct

NetAct – NetworkManagement Optimizer

Traffica

MQA

EM: LTERAN

BTSSite Manager

SQM

Appn

Itf-N

EM:SAE GW

EM:MME

Integrated Operation&Mediation Function BTSOM ASN.1 &HTTPS

XML overHTTPS

NE3S/SNMP

LMT

LMT

BTSSite Manager LMT

Localconnected

eNB

eNB

MME

LMT

SAE-GW

The Zone eNB is based on the BTSOM and NE3S. For more information, see Flexi Zone Controller Product Description. Flat operability architecture

Issue: 02B

DN0993921

125

Operability


In a legacy 2G and 3G network, relevant parts of the BTS operation and maintenance task are located in the BSC or the RNC. With the new LTE/EPC control plane and user plane architecture, the OAM task needs to be split and allocated between eNB and the element- and network management layer. Nokia decided to go for a flat integrated NetAct solution for the eNB element management instead of a remaining stand-alone solution. As the NetAct frame is a multi-vendor management system by nature, it provides various mediation interfaces towards nodes to be managed. For the Flexi Multiradio BTS, this is done by the integrated Operation Mediation System (iOMS) as an integral part of NetAct. With the integrated Operation & Mediation Function, NetAct can: • •

handle thousands of eNB-IP relationships perform highly efficient parallel file transfer handling for: – –

•

• •

PM counter upload (Bulk) file download (for example, SW distribution)

do a highly efficient PM counter aggregation (absolute data volume is approximately the same as in distributed Architecture but the number of files multiplies by a factor>700 to 1000 compared with WCDMA) maintain thousands of Security Associations (TLS sessions) mediate thousands of BTSOM sessions (Base Station OAM protocol)

7.2 NetAct framework NetAct provides advanced applications and services for multi technology and multi vendor network and service management; for example monitoring, reporting, configuring 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 formats or a format customized by the operator. According to the LTE653: LTE Operability Architecture feature, the eNB can be managed on different levels: •

•

on single site level by the BTS Site Manager (BTSSM) providing the eNB element management application (BTSEM) for the radio part, and the transport element manager application (TRSEM) for the transmission part for a single eNB. The BTSSM provides FCAPS functionality required for local element management. The BTSSM SW application is 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 the eNB. on regional and national level where the NetAct OSS framework provides the following capabilities: –

126

It can act as element management system (EMS) / domain manager (DM) for a certain number of eNBs.

DN0993921

Issue: 02B


–

Operability

It can be configured as network management system (NMS) for the whole network (access, core, transport, etc.) with the help of several underlying EMS.

An integrated operation mediation system (iOMS) mediates between the transportoptimized eNB management interfaces and the Corba NWI3 management interface used by several NetAct applications. Further, iOMS supports the FCAPS applications with concentration and aggregation functions for SW distribution and PM data collection. 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 NetAct OSS framework provides both the capability to act as the Element Management 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, etc.) on regional and national levels (with the help of several underlying EMS). An integrated Operation Mediation System (iOMS) mediates between the transport optimized 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. Examples of functionality provided by NetAct for LTE: • • • • • • • • • • • •

•

•

Issue: 02B

graphic topology presentation basic administration, time management and access to local node/element managers centralized software management collection and storage of alarm and measurement data alarm filtering and reclassification, modifiable alarm manual performance management tools and administration of measurements network configuration visualization the current radio network configuration as well as the planned configuration of the radio network can be viewed, searched and modified exporting the 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 eNB and core network into NetAct database possibility to compare actual plans - for reviewing changes what is expected when the plan is provisioned to the network or for verifying that planned changes were implemented correctly in the network site configuration tool - for providing an easy-to-access storage for eNB site configuration files and other commissioning data. The application supports network rollout by enabling effective commissioning of eNB. graphical user interface:

DN0993921

127

Operability


All O&M services are managed by using a graphical user interface (GUI), either via local access or from a remote location. The NetAct comprises the functionality to launch a BTS Site Manager. GUIs are provided by: – –

•

the NetAct OSS framework the BTS Site Manager (BTSSM) for BTS element manager (BTSEM) and the transport manager (TRSEM)

as the NetAct frame is a multi vendor management system it provides various mediation interfaces on the south side towards nodes to be managed

7.3 BTS Site Manager The BTS Site Manager (BTSSM) is the Element Manager for a single Flexi Multiradio BTS LTE, featuring a single SW application that is used for managing one or more network elements in the BTS site. As illustrated in Figure 88: Functional overview of the BTS Site Manager, the application integrates Transmission and BTS Management into one site-level management tool. Figure 88

Functional overview of the BTS Site Manager

NetActUserWorkstations

WebUser Interface

Tier-1

NetAct System Tier-2

Tier-3

BTSSiteManager JavaApplication (J2AA)

Application Launcher

Topology

PersistencyServices XML overHTTPS

LocalMaintenanceTerminal/ localconnectedNotebook

BTSSiteManager JavaApplication

WebUser Interface

The BTS Management provides all SW functionality needed to manage, configure, and monitor the Flexi Multiradio BTS LTE. The TRS Management provides all 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. The BTS Site Manager (BTSSM) SW application is installed on a computer which is connected to the eNB either locally (through Ethernet) or remotely (via the IP backhaul network). The BTSSM SW application hosts two management applications:

128

DN0993921

Issue: 02B


• •

Operability

The eNB element manager (BTSEM) including antenna line and antenna equipment monitoring and remote electrical tilt management The transport manager (TRSEM) for transmission management

A newly downloaded file does not immediately overwrite the software or the active settings of the radio or transmission databases. This is done when the eNB receives the activation command and performs a restart. BTSSM sends this activation command when finalizing the eNB commissioning. After initial commissioning, further SW and plan updates can also be executed from a remotely connected BTSSM. An eNB restart is not required if changes in the eNB configuration are restricted to parameters that can be modified on-line. Local host requirements • • • • • • • • • •

Windows 7, 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 10: BTS Site Manager local and remote functionality): • • • • •

Issue: 02B

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

DN0993921

129

Operability


Table 10

BTS Site Manager local and remote functionality

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

The CRAN functionality is activated, configured, managed, and deactivated by the BTSSM or NetAct. For more information on activation, deactivation and, configuration of CRAN, see the LTE1900: Centralized RAN feature description.

7.4 Flexi Multiradio BTS LTE management functions Flexi Multiradio BTS LTE management comprises the following functions, which are described in the following sections in more detail: • • • • • • • •

130

Fault management Configuration management Software management Performance management Hardware/inventory management Feature/license management User account management User event log management

DN0993921

Issue: 02B


Operability

7.4.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 automatic recovery actions. The Flexi Multiradio BTS alarm system gathers alarm reports from the application software in the Flexi Multiradio BTS and reports them to NetAct. On NetAct, a graphical user interface provides a view for active alarms and according reports as well as an alarm history, and enables the operator modification of alarm parameters. Fault management comprises the following functions: • • • • •

general alarm management functions alarm filtering in BTS alarm severity change in BTS alarm management for transport modules alarm management for antenna line management

For more information, see Functional Area Description Fault Management.

7.4.2 Configuration management Planning tools provide the site configuration, the radio configuration, and the transmission configuration data for the Flexi Multiradio BTS LTE. These configurations are downloaded, 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 parameter changes with direct activation direct parameter operations on transport configurations consistency checks feature management state management plan file data upload and download configuration data backup and synchronization SON-initiated configurations

For more information, see Functional Area Description Configuration Management.

7.4.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 that update the impacted SW segments.

Issue: 02B

DN0993921

131

Operability


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 SW integrity protection

7.4.4 Performance management The Radio Network Performance Management provides the operator with continuous upto-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 on the actual network performance. 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

The LTE1053: Real-time KPI-monitoring with Traffica feature provides real-time performance monitoring for the LTE Flexi Multiradio BTS. The Flexi Multiradio BTS is connected directly to Traffica using a new real-time data interface. This real-time data interface contains the results of ongoing performance measurements (PM-counter values) in real-time. These results are sent every minute. This helps operators to improve revenue by reducing problems in the network and provides more effective networks.

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

132

HW installation and configuration inventory management

DN0993921

Issue: 02B


Operability

7.4.6 Feature/license management Using hardware capacity features and optional software features require licenses to be purchased. 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 a 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.

7.4.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 application (RUIM) application. It also provides a mass updating function of local user passwords. The system administrator can manage the access to the Flexi Multiradio BTS with a centralized authentication and authorization server in NetAct. In the login phase, the network checks the user access rights from an LDAP server, which provides the authentication and authorization information. 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. 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 made 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 keep 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 should 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 because of expiration.

7.4.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 configuration damages.

Issue: 02B

DN0993921

133

Operability


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 third 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.5 Flexi Multiradio BTS supplementary OAM features The Flexi Multiradio BTS supplementary features comprise the following: • • •

GPS location retrieval NTP clock time synchronization Automatic iOMS resiliency

7.5.1 GPS location retrieval When the Flexi Multiradio BTS is synchronized by a GPS/GNSS receiver, the receiver serves also for retrieving the geographical coordinates and UTC time information. If a fixed mounted GPS module is available on site, the Flexi Multiradio BTS can be configured to use the control interface (SW management interface) to access the GPS information: • •

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 for example as time stamps in messages, alarms, notifications, trace records, and so on.

g

Note: Time zone information is not provided via GPS and must be configured during site commissioning.

7.5.2 NTP clock time synchronization The Network Time Protocol (NTP) is a standard that 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. The NTP server(s) used for the Flexi Multiradio BTS must be of stratum level 2 or better

134

DN0993921

Issue: 02B


Operability

(higher stratum levels are offset from a Stratum-1 server over a network path. As such, a Stratum-2 server gets 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

Note: Time zone information is not provided via GPS and must be configured during site commissioning.

7.5.3 Automatic iOMS resiliency This feature introduces a mechanism which supports continuous operability, even if an iOMS fails or a connection between the iOMS and the eNB is interrupted because of transport network problems. This feature works by introducing a redundancy concept, which allows the usage of a backup iOMS, called secondary iOMS, if the normally serving iOMS, called primary iOMS, cannot be used. In case of problems with the connection to the primary iOMS, the eNB tries to set up a connection with the secondary iOMS. When the connection is established successfully, the eNB identity, topology and alarms are transferred to the new iOMS.Multiple redundancy architectures are supported with this feature. One secondary iOMS can back up one primary iOMS or a group of iOMSs. Also, the one-toone configuration is possible.

7.6 Flexi Multiradio BTS diagnosis The Flexi Multiradio BTS diagnosis will also comprise the following applications: • • •

Trace data support for external usage Cell traffic trace Subscriber and equipment trace

It is possible to save a Flexi Multiradio BTS LTE snapshot file for troubleshooting purposes. This procedure describes how you can save a snapshot file that can be used for troubleshooting. The snapshot file can be saved in the connected mode. It contains the current status of elements and BTS Site Manager: used HW configuration, logs, alarms, HW and SW version information, for example.

7.6.1 Trace data support for external usage If operators apply network domain security within their own or 3rd party backhaul network then protocol testers as used in 2G/3G network can no longer be used because all communication on control, user and management plane is encrypted. With this feature, operators gain access to unciphered protocol trace information within the secure environment of the Flexi Multiradio BTS. This feature provides a new interface for trace data provisioning for external access, for example to protocol analyzers. Trace data support for external usage covers the following use cases: •

Issue: 02B

request external specific trace information to Flexi Multiradio BTS on demand

DN0993921

135

Operability


•

check a specific Flexi Multiradio BTS (in case of problems)

The following functions are supported by Flexi Multiradio BTS: •

•

The trace information is taken internally in Flexi Multiradio BTS, based on the Nokia specific internal interface trace request. The trace content request is a subset of the traces in the currently provided internal trace. Different trace levels are supported. The trace levels are aligned with the internal interface trace, but only a subset of the full information of the internal trace is provided to the external interface.

Trace levels follow the 3GPP RS32.421/32.422 definition: • • •

Maximum: all signaling messages on the different interfaces are retrieved Medium: data of minimum level plus a selected set of decoded radio measurement IEs is retrieved Minimum: a selected subset of IEs from the signaling interface messages is retrieved which covers most of the common use cases.

The following protocols are supported: • • • • •

PHY MAC RLC PDCP RRC

The following interfaces can be traced: • • •

LTE-Uu X2 S1

Depending on the request, data for external use are filtered in the Flexi Multiradio BTS for the different protocols, or only the requested data is collected. Possible parameters for the request are: • • • • • •

Cell identifier Protocol layers Measurement ID Measurement Type (which measurements are reported) Measurement Periodicity (how often reports are sent) Trace Level

Trace configuration Trace activation/deactivation and protocol tester IP address/port configuration are done via NetAct and BTS SM. The receiving protocol tester has no BTS configuration capabilities or management interface to the Flexi Multiradio BTS. Transport interface and security

136

DN0993921

Issue: 02B


Operability

The trace data is put to the external Ethernet interface on top of a transport protocol/port like TCP and is sent to a given IP address of the external protocol analyzer within the operator's domain. The trace data is sent via an IPsec security association to the defined VPN/SEG Gateway. If IPsec is not applied then the data is sent via plain IP. The trace date content may also be ciphered end-to-end independently of IPsec. In this case, the protocol tester needs to know the pre-shared key to support the ciphering.

7.6.2 Tracing General tracing functions comprise the following: • • •

Trace management Trace data collection and reporting Reporting modes

Tracing applications provide specific functionality for: • • •

Trace configuration Trace activation Trace data support

Trace management Our solution follows the general definitions recommended by 3GPP TS 32.421 and 32.422. It is assembled by four building blocks (see Figure 89: Cell trace concept and Figure 90: Cell subscriber and equipment trace concept): •

•

•

•

TraceViewer is the central tool within the NetAct application for trace activation and trace result evaluation. NetAct TraceViewer also offers centralized administrative 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 that 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.

Issue: 02B

DN0993921

137

Operability


Trace records can be sent over the northbound interface to further network management 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

Note: Direct transfer of trace records from Flexi Multiradio BTS to another network management system or external IP address is not supported. Reporting modes Non-real time and real time reporting is supported. In case of the non-real time trace reporting mode, the records are collected into files that 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.

7.6.2.1

Cell traffic trace Cell traffic tracing provides detailed resource oriented information at call level of a defined number of calls in one or more cells. The operator can activate cell traffic tracing for a limited period of time for specific analysis purposes, for example, advanced troubleshooting, optimization of resource usage and quality, RF coverage control, capacity improvement, or dropped call analysis in specific cells. The cell trace concept is illustrated in Figure 89: Cell trace concept. With LTE162: Cell Trace with IMSI additional feature, the existing cell trace data reports can be mapped with the IMSI/IMEI numbers of UEs located in the traced cell. Trace configuration Using the NetAct TraceViewer the operator can configure: • • • • • • • •

number of traced connections list of traced cells trace depth (min, med, max) trace schedule triggering events (that is, procedures such as call setup, HO etc) list of traced interfaces (S1-MME, X2, Uu) reporting type (file based, real time) external IP address for reporting (optional)

Trace activation Trace sessions can be activated for all calls that are active in one or more cells without knowledge of the subscribers' identification (IMSI, IMEI or IMEISV). The operator activates the trace via the NetAct TraceViewer by sending the trace control and configuration parameters directly to the Flexi Multiradio BTS. The NetAct CentralTraceControl starts the cell traffic trace at the BTS based on the configured trace schedule. The following parameters are forwarded to the BTS: •

138

trace reference

DN0993921

Issue: 02B


• • • • • •

g

Operability

number of traced connections list of traced cells trace depth in eNB (min, med, max) triggering events (that is, procedures such as call setup, HO, etc) list of traced interfaces in eNB (S1-MME, X2, Uu) external IP address for reporting (optional) Note: In real-time report mode, the LocalTraceControl in the Flexi Multiradio BTS always sends the trace reports to NetAct. NetAct forwards the trace reports to the external IP address. This approach is recommended to fit to a possible request having IMEI/IMSI to each traced calls in the trace reports, by which the IMEI/IMSI information is sent from MME to NetAct but not to Flexi Multiradio BTS. NetAct adds the IMEI info to the trace reports based on the call id and IMEI/IMSI number delivered from MME.

The received control and configuration parameters are saved in the Flexi Multiradio BTS. It starts collecting the trace data for a defined number of (or all) active connections within the defined cell(s) based on the configured trace depth. Trace data support Different “layers” of trace data can be supported based on the configured trace depth (trace depth minimum, medium and maximum). “Maximum” will contain complete signaling and control messages (encoded raw messages) of Flexi Multiradio BTS (incoming/ outgoing). All trace records contain timestamp and identification (“call ID”). The trace records include the measurements available from Flexi Multiradio BTS measurements and the events. Figure 89

Cell trace concept NetAct

Network Storage Data Processing

TraceView

Trace Viewer NetActTools Central TraceControl

DataFlow

Administrationand traceactivation

BTSOM

X2

S1

Local TraceControl Element Manager

eNB

Trace DataProducer

Local TraceControl eNB eNB

Trace DataProducer Uu

Issue: 02B

DN0993921

139

Operability


7.6.2.2

Subscriber and equipment trace Subscriber and equipment tracing provides detailed subscriber oriented information at call level for one or more specific UE(s). The operator can activate subscriber and equipment tracing for a limited period of time for specific analysis purposes, for example, for root cause determination of a malfunctioning UE, advanced troubleshooting, optimization of resource usage and quality, RF coverage control and capacity improvement, dropped call analysis or end-to-end procedure validation. The subscriber and equipment trace concept is illustrated in Figure 90: Cell subscriber and equipment trace concept. Trace configuring Using the NetAct TraceViewer the operator can configure: • • • • • • •

IMSI(s)/EMEI(s) of traced subscriber(s) trace depth (min, med, max) trace schedule triggering events (that is, procedures such as call setup, HO etc) list of traced interfaces reporting type (file based, real time) external IP address for reporting (optional)

The NetAct CentralTraceControl sends the trace control parameters to the Core Network, where the MME activates the subscriber trace within the Flexi Multiradio BTS. Trace activation Because the Flexi Multiradio BTS does not know the IMSI/IMEI of a subscriber, only the Signaling Based Approach can be applied for trace activation; the management based approach is not possible. The operator activates the trace via the NetAct TraceViewer by sending the trace control and configuration parameters to the core network (for example, the HSS). The core network forwards the activation to the selected base stations via the MME by sending invoke trace messages which contain the trace parameters. The MME sends the following information in the Trace Session Activation message to the Flexi Multiradio BTS: • • • •

trace depth in eNB (min, med, max) list of traced interfaces in eNB (S1-MME, X2, Uu) external IP address for reporting (optional) trace reference and trace recording session reference

The MME activates the recording session in the Flexi Multiradio BTS, based on the operator configured triggering events. The BTS starts the trace session after receiving the trace invoke message for the related connection. Trace data support Different “layers” of trace data can be supported based on the configured trace depth (trace depth minimum, medium and maximum). “Maximum” contains complete messages of Flexi Multiradio BTS (incoming/outgoing). All trace records contain time stamp and identification (“IMSI/IMEI”). The trace records include the measurements available from UE, the Flexi Multiradio BTS measurements, and the events. If available, the location information of UEs is included as well.

140

DN0993921

Issue: 02B


Figure 90

Operability

Cell subscriber and equipment trace concept NetAct

Network Storage Data Processing

TraceView

Trace Viewer NetActTools S-GW P-GW

Central TraceControl DataFlow

MME

Administration Subscriber TraceActivation

BTSOM

X2

S1

Local TraceControl Element Manager

eNB

Trace DataProducer

Local TraceControl eNB

Trace DataProducer Uu

7.7 Self Organizing Network support The Self Organizing Network (SON) concept reduces necessary human interaction and effort during network build and operation/maintenance phases to accelerate the operational processes during these phases, and to clearly decouple the processes between the manufacturer, field service, and operator. The Self Organizing Network support comprises features such as: • • • • • •

Flexi Multiradio BTS auto connectivity Flexi Multiradio BTS auto configuration neighbor cell configuration for LTE with pre-planned identities automated neighbor relation configuration (ANR) for LTE automated neighbor relation configuration (ANR) for UTRAN automated neighbor relation configuration (ANR) for GERAN

The introduction of 3G LTE/EPC, its concurrent operation with 2G and 3G networks together with the general cost pressure, forces the mobile network operators (MNO) to significantly reduce their operational expenses (OPEX). An important building block for OPEX reduction is the area of self-management (see Figure 91: SON architecture) which includes: • •

Issue: 02B

Self-configuration: 'plug and play' behavior of new installed network elements to reduce costs and simplify installation procedure Self-optimization: parameter optimization based on network monitoring and measurement data from terminals to minimize operational effort, and to increase quality and performance

DN0993921

141

Operability


• •

Self-healing: the system detects problems by itself and mitigates or solves these to avoid user impact and to significantly reduce maintenance costs Self-planning: derivation of initial network parameters (for example sub-channel, antenna parameters, neighbor list, IP configuration etc.) as input for selfconfiguration

Figure 91

SON architecture Measurements (gatheringandprocessing)

continuous loop Selfoptimization

Setting parameters

Selfplanning

Selfhealing

Selfconfiguration triggeredby incidental events

7.7.1 Automatic neighbor relation (ANR) ANR provides neighbor cell configuration data at the source eNB to support a handover to the target eNB. Basic functions of ANR ANR in LTE is defined by 3GPP TS32.511 Automatic Neighbor Relation (ANR) management. ANR consists of the following functions: •

142

Basic X2 Link Establishment The establishment of neighbors is based on information which is prepared in a preplanning phase. Only a subset of standard configuration information is required. For all neighbor cells, only the Node-ID and the IP address of the neighbor LTE eNB

DN0993921

Issue: 02B


•

•

•

Operability

hosting the expected neighbor cells need to be configured by an offline pre-planning. All other configuration information for cells of neighbor LTE eNBs are automatically derived and updated via the X2 interface. For the LTE782: ANR-UE-based feature, this info is autonomously retrieved by the eNB. ANR-Intra-LTE If an unknown physical cell ID is reported by a UE, the eNB derives the cell configuration information of the LTE neighbor cell (that is ECGI, TAC, and supported PLMNs) with the help of the UE. This information is stored for further use by mobility management in the eNB. ANR-Optimization of intra-LTE neighbor relations Optimization of intra-LTE neighbor relations is a part of the overall ANR functionality. LTE neighbor cells will be discovered and added by ANR features or manually by the operator. The NetAct Optimizer evaluates all current relations between neighboring LTE cells if they are still valid and reliable candidates to be a handover destination. When the outcome results in an inefficient neighbor relation, the according cell relation may be blacklisted for a handover. ANR to other Radio Access Technology (UTRAN) The features are requested as centralized SON features. The O&M based inter-RAT feature supports operator initiated and/or automatic set-up and the maintenance of neighborship to other RAT (radio access technology). The purpose of these features is to keep the operator's effort low for inter-RAT neighborship configuration based on site planning data.

ANR features The following features support ANR in a multi-layer heterogeneous network (HetNet) environment: • • •

LTE1821: Neighbor Detection Optimization for HetNet LTE1822: PCI Assignment Optimization for HetNet LTE1823: Neighbor Prioritization Optimization for HetNet

Additionally, the LTE908: ANR Inter-RAT UTRAN - Fully UE-based feature introduces a new mechanism for neighbor relations (NRs) between LTE and UTRAN cells, which allows eNBs to raise all needed UTRA cell data from the UE connected to these UTRA cells. ANR in NetAct Nokia supports ANR on a different level of interworking of eNB and NetAct to give the operator full control of the neighbor relation management. For all features, NetAct supports suitable means for activation, control, and monitoring of the ANR features. For more information on the management, see NetAct Customer Documentation or the online help support.

Issue: 02B

DN0993921

143

Security


8 Security Security forms a vital part of any application or network in all end-user segments. It is a key aspect of the system architecture. In particular, security is needed to provide the confidentiality of the user data and to mitigate the effects of attacks on the network. This chapter provides information on the following issues: • • • • • • •

Security requirements and methods LTE/EPC M/C/U/S-plane security User security BTS security NetAct security Network security Support of a Public Key Infrastructure

For detailed information on related security issues, see LTE RAN O&M Security.

8.1 Security requirements and methods This chapter provides information on: • • • •

Security categories Security threats Security areas Security features

8.1.1 Security categories Security requirements can be categorized in the following way: •

• • • •

Confidentiality and privacy Confidential (Ciphered) data is not interpretable without having the secrets (keys) to decrypt. Integrity Integrity protection ensures data have not been altered during transmission. Authentication and identification The person or system is the one they claim to be. Non-repudiation Proof of integrity and origin of data. Access control Access to a system has been restricted only to those person to which access permission has been granted.

8.1.2 Security threats Introduction of IP architecture into an LTE network brings along benefits, but also several security threats that need to be addressed to ensure high quality service delivery.

144

DN0993921

Issue: 02B


Security

Here are some of the most common security threats: •

•

•

•

•

Password attacks With this action, a person tries to determine valid user names and passwords through repeated trial-and-error user login attempts. A person can block access to the network through rapidly repeated login attempts. Sniffing Sniffing is electronic eavesdropping. With sniffing, a person aims to collect, for example, user ID and password information. One of the problems related to sniffing is that sniffing programs are publicly available on the Internet. IP address spoofing Spoofing means that a person uses someone else's IP address to access a network. In other words, the intruder replaces their own IP address with someone else's IP address. Man-in-the-middle attacks This type of attack is used to corrupt, modify, or delete information being sent over a network. This attack can also be used for taking over the existing connection or for denying service to servers or a whole network. Denial of service attacks The aim of this type of attack is not to collect information, but rather to cause harm and inconvenience to users and service providers. This is done through exhausting a network's resource limitation.

8.1.3 Security areas The following security areas are covered: •

•

•

•

Issue: 02B

Network security The basic security philosophy of the LTE solution is based on the concept of viewing sites and the backbone network as separate entities. Each entity forms its own security domain and security issues are resolved within that domain. Each entity also views other entities as inherently insecure. Within the secure sites, individual network elements provide an additional level of security. The network elements include tools for managing responsibilities within the operator's organization. The operator can use them to protect network elements against accidental modifications. NetAct provides capabilities for managing and improving security across the whole network. Security-related events can be monitored and preventive and corrective actions can be started. NetAct can also be used for backing up network element information and restoring it remotely, if necessary. UP/AS Security The UP/AS security is separated in UP security which handles user data which are transferred/exchanged via U-plane path between eNB and UE. The AS security is for the control/signaling protection, i.e. RRC (Radio Layer 3) message information which is transferred/exchanged between eNB and UE. Terminal security Security of the end user terminal is mostly dependent on the activities of the end user. The network can protect the end user from attacks coming from the network, but the end user is primarily responsible for ensuring terminal security. For example, the PIN code is one of the key methods to help protecting end user. Physical security A fundamental precondition for an effective security solution is physical security of premises and physical network element security.

DN0993921

145

Security


•

The operator is responsible for the physical security of the premises where network elements are located. Only authorized and trusted persons should be granted access to such premises. Application security Application security is a key issue in mobile environment. It can be further divided into securing telephony applications and server-based applications. Telephony applications security is mostly covered in network security, with concepts like authentication, subscriber data security, and authentication failure notification to the home network. In addition to IP-level security, service-based applications security contains trust, transaction and communications security, authentication, authorization, nonrepudiation, and virus protection.

8.1.4 Security features The most important security features in LTE/EPC network are the following: • • • • •

NE authentication Temporary identities Cipher protection Integrity protection Information security

NE authentication The NE authentication is verifying the authenticity of the NE before it can connect to operators RAN. The NE authentication is based on a public key infrastructure (PKI) using digital certificates in X.509 format. Temporary identities As in GSM and WCDMA, an international mobile subscriber identity (IMSI) is used in LTE RAN as the permanent identity of a subscriber. However, user identification in LTE RAN is mostly performed by temporary identities, TMSI and P-TMSI. This indicates that user confidentiality is almost always protected against passive eavesdroppers. Before the temporary identity can be used, the network must first identify the user's permanent identity. After the serving network has identified the user by means of the IMSI, the serving network allocates a temporary identity for the user and preserves the association between IMSI and (P-)TMSI. Temporary identities are significant only locally, and the network makes sure that the same temporary identity is not allocated to two users simultaneously. The temporary identity is used both in uplink and downlink direction until a new temporary identity is allocated by the network. Cipher protection Ciphering has a significant part in protection against attackers with more advanced capabilities, and it is also an effective protection from eavesdropping. The core of the ciphering mechanism on the air interface is the mask generation algorithm which is a one-way hash function based on the KASUMI algorithm, which is publicly available and approved by 3GPP. Integrity protection

146

DN0993921

Issue: 02B


Security

The purpose of integrity protection is to authenticate individual control messages. This is important since a separate authentication procedure gives an assurance of the communicating parties' identities at the time of authentication. Information security Information security consists of: •

• •

•

•

•

•

•

User IDs and passwords Users must know their user name and corresponding password to log into network elements. Authentication User names are authenticated with the appropriate password. User rights and authority User names can be given certain access rights or authority to perform certain tasks, but not others. This, for example, can prevent people from executing tasks which could harm the system when used improperly. User profiles and user groups User profiles and user groups can be used to assign users to previously designed access rights sets, instead of setting all the necessary access rights to each user name individually. User logs A log is kept of all actions carried out by each user. The logs can be used for troubleshooting in the event of a failure. The logs can also be used to track the actions of an unauthorized user. Centralized User Authentication and Authorization (CUAA) CUAA enables centralized user management and authorization. It is based on the use of a dedicated authentication server on which all necessary user information is stored. Remote User Event Log Management This feature enables the operator to trace operations and events done in the network elements by different users. O&M, user and control plane traffic protection with IPSec U-/C-/M-plane traffic can be aslo secured with an optional IPsec tunnel between the eNB and Security Gateway (SEG).

8.2 LTE/EPC M/C/U/S-plane security As specified by 3GPP (see Figure 92: LTE/EPC M/C/U-plane security) the LTE/EPC security architecture provides security for the M-, C-, U-plane. The protection of S-plane is not recommended. Different planes are defined to differentiate the different type of traffic. The following planes exist: U-plane (user data), C-plane (control data), M-plane (management data) and S-plane (Frequency and Time/Phase synchronization).

Issue: 02B

DN0993921

147

Security


Figure 92

LTE/EPC M/C/U-plane security eUu

UE

S1-MME

eNB

MME

eNB

X2C

eNB

NASsignaling (cipheredandintegrityprotectedusingNASsignalingsecurity) C-plane

S1-U

U-plane

X2-APsignaling (cipheredandintegrityprotected withIPsec)

S1-APsignaling (cipheredandintegrityprotected withIPsec)

RRCsignaling (cipheredandintegrityprotected)

X2U

SAE-GW

U-planedata packetsforwardedoverX2 (cipheredandintegrityprotected withIPsec)

U-planedata (cipheredandintegrityprotected withIPsec)

U-planedata (cipheredusingPDCP)

EMS/ NMS

O&M

M-planedata (cipheredandintegrityprotected withIpsec&TLS)

M-plane

U-plane security protects the transfer of user data over the LTE-Uu, S1-U and X2 reference points. Secure environment of the eNB provides a Secure Environment for Uplane and C-plane traffic. Security for eNB setup and configuration provides protection from “rogue” or invalid modifications. Table 11: Security termination points summarizes the security termination points. Table 11

Security termination points

Ciphering

Integrity protection

Required and terminated in NAS Signaling

MME

MME

U-Plane Data

eNB

S-GW 3)

RRC Signaling

eNB

eNB

Security associations for C-plane NAS security and security of the LTE-Uu interface (Cplane and U-plane traffic) are provided on a per-UE basis and are established/refreshed when the UE changes states (initial attach, transfer from ECM_IDLE to ECM_CONNECTED, handover etc.). Crypto Agent

3)

148

Integrity protection for U-Plane is not required, and thus it is not supported between the UE and the eNB on the Uu interface, but it is required for the transport of user plane data between the eNB and the Serving Gateway on the S1 interface.

DN0993921

Issue: 02B


Security

Radio networks evolving to all-IP architecture often require secure transport communication channels to protect user-, control- and management plane traffic. Flexi Multiradio module provides with the LTE623: Crypto Agent (CRA) feature a personal secure environment (PSE) to guarantee the secure storage of mid- and long-term security credentials like RSA keys and passwords.

8.2.1 C-plane security C-plane security protects NAS signaling, RRC signaling over the LTE-Uu. C-Plane security associations for the protection of NAS and RRC signaling are provided on a perUE basis. C-Plane signaling between the MME and eNB is protected using NDS, with the security associations being established on a per-interface basis. The C-plane security architecture as illustrated in Figure 93: C-plane security architecture for LTE/EPC comprises integrity protection and ciphering according to the following: • • • • •

• •

NAS signaling protection is transparent for the eNB. NAS signaling is ciphered and integrity protected between the UE and MME. RRC signaling is always integrity protected by PDCP in the eNB and UE. RRC signaling is ciphered by PDCP in UE and eNB. RRC security (integrity protection and ciphering) is applied to NAS messages carried by RRC in addition to the NAS signaling security between the MME and UE. This results in double protection of NAS signaling. S1-AP signaling is ciphered and integrity protected between the eNB and MME by an underlying transport network mechanism which is NDS/IPsec. X2-AP signaling is protected in the same way as S1-AP signaling.

Figure 93

C-plane security architecture for LTE/EPC

UE NAS

MME NASSignallingSecurity(authenticated,integrityprotectedandencrypted)

NAS

eNB RRC

C-PlaneSecurity (authenticated, integrityprotected andencrypted)

RRC

S1-AP X2-AP

S1-MME

S1-AP

NDS/IPSec, authenticated, integrityprotectedand encrypted)

X2C-PlaneSecurity asS1-MME eNB X2-AP

8.2.2 U-plane security U-plane security protects the transfer of user data over the LTE-Uu, S1-U and X2 reference points. U-Plane security over the LTE-Uu is provided on per-UE basis. U-Plane security over the S1-U is provided using NDS/IPsec, established on per-interface basis. The U-plane security architecture as illustrated in Figure 94: U-plane security architecture for LTE/EPC comprises integrity protection and ciphering according to the following:

Issue: 02B

DN0993921

149

Security


• • • • •

g

U-plane data is ciphered. Ciphering is performed on a 'hop-by-hop' basis (UE ↔ eNB, eNB ↔ S-GW and eNB ↔ eNB). Ciphering over the LTE-Uu is performed by PDCP in the eNB and UE. S1-U traffic is ciphered between the eNB and S-GW by an underlying transport network mechanism which is NDS/IPsec. X2-U plane traffic is protected in the same way as the S1-U reference point. Note: Note that integrity protection of U-plane data is not supported between the UE and the eNB on the Uu interface because the overheads involved (additional processing and network traffic) outweigh the benefits that would be provided. Integrity protection is required for the transport of user plane data between the eNB and the Serving Gateway on the S1 interface. In some countries, encryption of user data is illegal and/or there are restrictions on export/import of secure data/security algorithms. This means that the network operators can optionally use or rather disable U-plane ciphering.

Figure 94

U-plane security architecture for LTE/EPC

UE U-Plane DataStream

S-GW Security is provided by underlying layers (hopbyhop)

U-Plane DataStream

RadioandS1 BearersSAP

RadioandS1 BearersSAP

L1/L2

U-PlaneCiphering (NoIntegrityProtection)

eNB S1-U

L1/L2

S1-U

(performedbyPDCP)

S1-U

NDS/IPSec

X2data forwarding

X2U-PlaneSecurity AsS1-U

eNB

X2data forwarding

8.2.3 M-plane security M-plane security (see Figure 95: M-plane security architecture for LTE/EPC) protects O&M operations for the configuration and monitoring of the eNB over the BTS-OM interface. Figure 95 eNB

O&MSystem

Software Loads

Software Loads

Configuration Parameters Trace Functionality

150

M-plane security architecture for LTE/EPC

itf.-eNB TLSandNDS/IPsec (authenticated, integrityprotected&encrypted)

Configuration Parameters Trace Functionality

Performance Counters

Performance Counters

Alarms

Alarms

DN0993921

Issue: 02B


Security

8.3 User security User account management can be divided by the location of performing user authentication and authorization. There are two scenarios of managing user accounts: centralized user account management, and local user account management. Centralized user accounts of network elements are managed with NetAct. It allows users to log into different network elements with the same user ID and password. In local user account management there is no central entity like NetAct to administer the user-relevant information, that is, user name and password. The user-relevant information is administered locally in the network elements. In both cases the user can connect to a network element either locally via Local Management Port (LMP) or from a remote location. For more information see “O&M user security” section in LTE RAN O&M Security Functional Area Description.

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 physically separated networks, or by establishing secure virtual networks (VLANs) within a single backbone network shared among various types of traffic. The BTS security comprises the following features: • • • • • • • • •

Physical security Security for Ethernet ports Locally stored user ID and password Centralized Network Element User Management (CNUM) LTE User event log management 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 SW Verification Agent

Physical security The BTS units might be in locked cabinets to secure them physically against a break-in. 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 overheating. Security for Ethernet ports The BTS provides LMP and SSE Ethernet ports which can be used to access eNB. This feature protect against using these ports for: • •

Issue: 02B

eavesdropping, interception or modification BTS internal traffic misuse BTS services like telnet, ftp, R&D services

DN0993921

151

Security


•

implementation of malicious packets towards the core network

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 password HASH-file 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. Centralized Network Element User Management (CNUM) Centralized Network User Management (CNUM) 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 authentication 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 CNUM system, the operator can define different access classes for different user groups and network elements (not for the BTS, there is only one access class supported). 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 LTE667: LTE user event log management feature). LTE User event log management The LTE667: LTE user event log management feature enables the centralized aggregation of user event logs from the BTSs in NetAct. The operator can trace changes in the network, based on user or network element information. 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 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 processing the collected log files. With NetAct, the operator can create reports from the data collection, for example, reports based on the user or network element identity. Secure file transfer for Flexi Multiradio BTS LTE The LTE150: OAM Transport Layer Security (TLS) Support feature enhanced by LTE1076: Support of TLS 1.2 enables protected transfer of the O&M data files between BTS, iOMS/NetAct, and Syslog Servers as well as the protection of management protocol communication between BTS and iOMS. O&M data files and management plane protocol messages, which are transmitted using TLS 1.2 are encrypted and integrity protected. The content of the transferred payload cannot be eavesdropped on or modified; for example, no man-in-the-middle attacks are possible. The eNB uses HTTP/HTTPS for file transfer, FTP is not supported. In a secure transport mode, HTTPS uses TLS 1.2 for data protection. To use TLS 1.2, the user needs valid X.509 certificates, which are crucial for establishing TLS 1.2 connections which are then used by HTTP. The eNB uses HTTPS. HTTPS uses Transport Layer Security (TLS) for data protection. To use TLS, the user needs valid X.509 certificates. Certificates are crucial for establishing TLS connections which are then used by HTTP. Network element certificate management for Flexi Multiradio BTS LTE

152

DN0993921

Issue: 02B


Security

The LTE665: Network element certificate management for Flexi Multiradio BTS LTE feature defines the usage of Certificate Management Protocol (CMP). Digital certificates are used to authenticate communicating peers. They are essential for Transport Layer Security (TLS) operation used in secure BTS Management Interface and secure file transfer functions. Also the IPSec feature uses certificates. Secure management interface for Flexi Multiradio BTS LTE The secure management interface for Flexi Multiradio BTS LTE functionality enables protected O&M communication between Flexi BTS, NetAct and BTS Site Manager. SW Verification Agent The Flexi Multiradio BTS modules provide a secured bootstrap. Only integrity-checked code is allowed to go into the service. Secure boot enforces verification and execution of trusted SW in a predefined sequential order. It guarantees that a system boots only into a specific state and assures that integrity-violated code is refused. The LTE940: SW Verification Agent feature takes care that no malicious code can be inserted.

8.5 NetAct security NetAct is the security center for user account management of the LTE/EPC system. It can monitor security-related issues and, if needed, initiate preventive and corrective actions. NetAct controls and provides secure user access to network elements. The NetAct security solution is divided into the following areas: •

• •

• •

•

•

Issue: 02B

User management The NetAct user management is based on the concept of Centralized User Management. It involves the management of user accounts, passwords, permissions, groups, and roles. User security User security involves user authentication and authorization. Security administration Security administration involves the management of digital certificates, SSH usage, and the IPSec management. Security monitoring The NetAct security monitoring is handled with NetAct Monitor and Audit Trail. Network security Network security involves principles on how applications communicate securely with other applications over the network. Network security is divided into traffic encryption and integrity protection (via SSH and TLS/SSL protocols), traffic filtering, and traffic separation areas. Data security Data security involves principles on how information can be stored securely in the cluster using different storage technologies. Data security covers file system security, database security, and secure key storage. Software security Software security involves principles on how software management must be designed to meet the necessary security level. Software security covers secure software upgrade and patching, and file integrity checking.

DN0993921

153

Security


For more information on NetAct security, see NetAct System Administration Principles document in NetAct Operating Documentation.

8.6 Network security System security for the LTE RAN comprises: • • • • •

Firewall support IPsec support Transport Layer Security support IP-based filtering for BTS Site Support Equipment Certificate management

8.6.1 Firewall support The Flexi LTE BTS includes inhost firewall/packet filtering functionality 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 and destination addresses, sources and destination port numbers, and protocols. 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, non-configurable rules. These rules are created automatically 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.6.2 IPsec support Communication between 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 dedicated transport tunnels. The security of eNB control, user, and management plane interfaces is increased by providing encryption, integrity protection and communication peer authentication with IPsec according RFC 4301. The supported IPsec capabilities follow 3GPP's recommendation TS 33.210 for interworking 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, to guarantee interoperability between different security domains. Table 12: IPsec capabilities summarizes the supported IPsec capabilities:

154

DN0993921

Issue: 02B


Table 12

Security

IPsec capabilities

Services

Data integrity protection, origin authentication and anti-replay protection, confidentiality

Protocol

ESP (RFC 4303)

IPsec mode

Tunnel mode

Encryption/Ciphering

•

AES-128-CBC

•

3DES-192-CBC

•

NULL

Integrity protection algorithm

HMAC-SHA-1-96

Identification

•

IP addresses

•

Fully Qualified Domain Names (FQDN)

•

distinguished name ID_DER_ASN1_DN

Authentication

Digital certificates in X.509v3 format

Key exchange

•

Dual stack IKEv1 and IKEv2

•

Diffie-Hellman: Group 2 (1024-bit MODP)

•

Diffie-Hellman: Group 14 (2048-bit MODP)

IPsec configuration IPSec implementation is optimized to provide best throughput and strongest security levels when using ESP encapsulation with AES-128-CBC encryption along with HMACSHA-1-96 integrity protection algorithm. IPsec for traffic separation C-, M, S-, U-plane 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 on the separated data paths. For traffic separation in LTE, IPSec VPN tunnels as per 3GPP NDS/IP are supported.

g

Note: 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 significantly increases overhead. But if IPsec is used for tunnel provisioning, multiple encryption may occur anyway. 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 configured in parallel. For instance, it is possible to run TLS connections within a common IPsec tunnel or in parallel to IPsec tunnel(s). IPsec Emergency Bypass

Issue: 02B

DN0993921

155

Security


In case the BTS detects a severe IPsec failure, the IPsec at the BTS can be switched off in an operator-controlled way, not requiring any site visit. Switching back from IPsec Emergency bypass mode to IPSec mode is exclusively controlled by operator. For more information, see LTE1390: Emergency Bypass functional description.

8.6.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 using Transport Layer Security (TLS 1.2). The security of Flexi LTE BTS element manager interfaces and the network management systems is increased by providing encryption, integrity protection, and server authentication with the Transport Layer Security Protocol (TLS 1.2) and HTTPS on top of it. Unsecured protocols like FTP are no longer used. Transport layer security support comprises the following: • • • • •

Digital certificates according to X.509v3 format are used to authenticate mutually 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 1.2, for example, user names and passwords are not delivered as plain text. Bulk data transfer is encrypted and integrity is protected. The LDAP interface to authenticate user and fetch permission information for a user is secured.

The Transport Layer Security Protocol (TLS 1.2) provides both encryption and authentication features and consists of two layers: • •

The TLS record protocol takes care of encryption and integrity protection of the message exchange. The TLS handshake protocol provides the mutual authentication of the communication peers using digital certificates.

8.6.4 IP-based filtering for BTS Site Support Equipment It is possible to access selectively the IP DCN towards site support equipment and vice versa. Filtering is done based on IP addresses and improves 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. IP packets from/to any site support equipment which are not targeted to/originated from any of the configured IP addresses will be dropped. Use the Site Element Manager to set up the configuration from a local or remote site, or via the plan file managed by NetAct.

156

DN0993921

Issue: 02B


Security

8.6.5 Certificate management The Flexi Multiradio BTS LTE Certificate Management functionality provides the handling of the private and public key pair and related digital certificates in X.509v3 format. Keys and certificates are used for mutual authentication between IPsec and/or Transport Layer Security (TLS) protocol peers but may be also used for the verification of SW loads, configuration data. The Certificate Management functionality is needed for enrollments, update, and revocation when operator certificates are used in the network. It comprises the following: • • • • •

factory (vendor) certificate provisioning remote operator certificate enrollment according 3GPP local operator certificate enrollment certificate revocation certificate renewal/key update

For more information, see Functional Area Description LTE RAN O&M Security. Multi-layered Certificate Authorities The LTE523: Multi-Layered Certificate Authorities feature supports operator certificate management for multi-layer hierarchical PKI structures by Flexi Multiradio BTS. Multi-layer PKI is an extension of single-layer PKI. It offers better flexibility by introducing the concept of multiple layers. In this model, the root CA is the highest certification authority in the operator’s network. The root CA is represented by a self-signed certificate (operator root CA certificate) that is used as trust anchor for the entire domain of PKI entities. The multi-layer PKI introduces the possibility to deploy up to 3 further certificate authorities as a subordinate to the root CA. iOMS Certificate update and revocation support With LTE1260: iOMS Certificate Update and Revocation Support feature the iOMS supports automatic certificate life cycle management by autonomous update of the operator certificates. The chain of trust comprising of up to three subordinate CA certificates and the root CA certificate on top, increase flexibility in choosing architecture of Public Key Infrastructure. Revocation list support provides better certificate examination before a secure connection establishment.

8.7 Support of a Public Key Infrastructure An evolved packet system (EPS) is an IP based network with architecture considerably more flat than for example a UMTS or GPRS network. While this makes the network very efficient, it also requires very well designed security measures for protection against the variety of threats that endanger mobile networks, in particular IP related attacks. To protect the EPS against such threats, sophisticated network security architecture has been specified by 3GPP, which enhances the concepts used already within UMTS. Naturally, the 3GPP security architecture focuses on aspects which require

Issue: 02B

DN0993921

157

Security


standardization (for example for interoperability of devices). However, complete security architecture for an EPS must also cover aspects that are mostly not standardized, like for example perimeter protection with firewalls. Certificate Authority A certificate authority (CA) is an entity that issues digital certificates for use by other parties. The CA issues digital certificates that contain a public key and the identity of the owner. The certificate is a confirmation or validation by the CA that the public key contained in the certificate belongs to the entity noted in the certificate. A CA's obligation is to verify an applicant's credentials, so that users and relying entities can trust the information in the CA's certificates. The Public Key Infrastructure (PKI) solution is based on Insta Certifier for issuing and managing digital certificates. The management of certificates is automated and compliant to standards. Strong network element authentication prevents from unauthorized access.

158

DN0993921

Issue: 02B


AAA and charging

9 AAA and charging This chapter provides information on the following issues: • • •

LTE/EPC authentication Authorization Accounting and charging

9.1 LTE/EPC authentication The LTE/EPC network provides a layered security association structure as illustrated in Figure 96: Layered security association structure of the LTE/EPC. Figure 96

Layered security association structure of the LTE/EPC AUC

USIM Root Key

Root Key

HSS/AAA

UE CK,IK

CK,IK

SubscriberAuthentication/Authorization(AKA) MME NASKeys

NASKeys

AK_ASME

NASSecurityAssociation eNB ASKeys

ASKeys

Oneway key derivations

UPSecurityAssociation UPKeys

UPKeys

UPSecurityAssociation

EPS Authentication and Key Agreement (EPS AKA) is based on UMTS AKA and provides the following features: • •

EPS AKA is based on USIM and (possible) extensions to UMTS AKA access to E-UTRAN with 2G SIM or a SIM application is not granted

EPS AKA produced keys are the basis for both C-plane and U-plane protection. EPS AKA is a challenge-response protocol that achieves mutual authentication between the user and the network by demonstrating knowledge of a pre-shared secret key K which is only known by the USIM and the AuC in the user's HSS. The EPS AKA procedure is illustrated in Figure 97: LTE/EPC AKA procedure.

Issue: 02B

DN0993921

159

AAA and charging


Figure 97

LTE/EPC AKA procedure

UE

eNB

MME

HSS

1.NAS:AttachRequest (UserID,UECapabilitiesetc.) 2.AuthenticationDataRequest

4.NAS:UserAuthenticationRequest (RAND[i]||AUTN[i])

3.AuthenticationDataResponse (AuthVectors-av[1...n])

5.NAS:UserAuthenticationResponse (RES[i])

The MME triggers AS security command procedure to eNB to enable ciphering of the Uplane traffic and ciphering & integrity protection of RRC signaling. Furthermore, the MME uses the NAS security command procedure established NAS SA between UE and MME.

9.2 Authorization Authorization is the process by which a functional entity validates the service request type to ensure that the user is authorized to use the particular network services. In EPS, the authorization function is located in MME and a network element including PCEF functionality (P-GW for GTP variant, P-GW/S-GW for IETF variant). The authorization functionality of MME is based on subscription data located in HSS. It is used, for example, in the context of attach and bearer management procedures. Figure 98: Retrieval of LTE authorization information shows how MME retrieves authorization information from HSS. Regional subscription restrictions are imposed by the user's home network operator and are signaled to the MME by HSS. PCEF receives authorization information from PCRF. Alternatively, authorization information may be pre-configured in PCEF. Figure 98

Retrieval of LTE authorization information HSS

MME 1.UpdateLocation (IMSI,MMEidentity) 2.UpdateLocationAck

9.3 Accounting and charging The Accounting and Charging mechanism employed by EPS will be an evolution of the PS Domain charging mechanisms for GPRS and will facilitate seamless interworking with legacy charging systems. The PS Domain accounting function is part of the overall architecture which comprises IMS and application charging, and additionally contributes

160

DN0993921

Issue: 02B


AAA and charging

access and transport information for cost calculation. Depending on charging filter rules, the transport information is either collected at the IP bearer level or at the IP service flow level. The charging filter rules are provided by the Policy and Charging Rule Function (PCRF) and deployed in the Policy and Charging Enforcement Function (PCEF) of PGW. Alternatively, the charging rules may be preconfigured in P-GW, which is the solution for Flexi NG based P-GW before PCRF support. Charging scenarios Charging for EPC as outlined in Figure 99: EPC charging - 3GPP access - non roaming, Figure 100: EPC charging - 3GPP access - roaming, home routed traffic, and Figure 101: EPC charging - 3GPP access - roaming with local breakout is performed on a per IP bearer basis which involves: • • •

PCRF for dynamic charging rule instructions P-GW's PCEF with its collection and credit control client functions S-GW with its collection functions for inter-operator charging

Figure 99

EPC charging - 3GPP access - non roaming

UTRAN

SGSN GERAN

HSS

S3

PCRF S6a

S1-MME

MME

Rx+

S7 S4

S11

UE

S10

LTE-Uu

PCEF

S-GW

E-UTRAN

S1-U

S5

P-GW Gz

CGF

Issue: 02B

DN0993921

SGi

Operator's IP Services (e.g.IMS,PSSetc.)

Gy

OCS

161

AAA and charging


Figure 100

EPC charging - 3GPP access - roaming, home routed traffic PCRF Rx+

S7

PCEF

P-GW

SGi


Gy

Gz HSS

CGF

OCS

S6a

HPLMN

VPLMN

UTRAN

SGSN G8a

GERAN

S3 S1-MME MME

UE

S4

S11 S10 E-UTRAN

S-GW

CGF

S1-U

LTE-Uu

Ga Maygenerate earerlevelinter-operator charging

Figure 101

EPC charging - 3GPP access - roaming with local breakout OCS

HSS

HPLMN

Gy

S6a

VPLMN UTRAN

SGSN GERAN

CGF

S3

PCRF

S1-MME

Gz

MME

UE

Rx+

S7 S4

S11 S10

PCEF E-UTRAN LTE-Uu

S-GW S1-U

S5

P-GW

SGi


Charging mechanisms There are two charging mechanisms employed by ePACS: •

162

Offline charging is applied to users who pay for their services periodically (for example, pay-monthly customers).

DN0993921

Issue: 02B


•

AAA and charging

Online charging is applied to users who pay for their services in advance (for example, pay-as-you-go customers) and for real time credit control of post paid services.

Offline charging If the user session cost is calculated using the Offline Charging function, the P-GW generates a CDR based on the charging rules (received from the PCRF). When the user session completes, the P-GW forwards the so-called enhanced G-CDR via the Gz interface with protocol GTP' to the Charging Gateway Function which collects CDRs from all local network entities involved in billing the call, and forwards them to the Billing System (BS). The Offline Charging function in S-GW is necessary for the roaming case with home routed traffic as outlined in Figure 100: EPC charging - 3GPP access - roaming, home routed traffic, that is, the P-GW is located in the home network. S-GW generates a CDR with access and bearer information. When the user session completes, the S-GW forwards the so-called S-CDR via the Ga interface with protocol GTP' to CGF and further to BS of the visited operator. The subscriber's bill is always calculated in the homelocated BS. In roaming cases, the visited operator generates a TAP3 Record based on S-CDR, or, if available, an eG-CDR to request the roaming charge to the home operator. Online charging If the user session cost is calculated using Online Charging, P-GW forwards usage information, and receives credit information to/from OCS, in real time, via Gy interface with DIAMETER based credit control application protocol (DCCA). At session start, the OCS authorizes the user session. During the session, information about granted and used volume, time or unit quotas is exchanged. The used quotas are the basis of cost calculation in OCS. If the user runs out of credits, the OCS can terminate the user session immediately. OCS is always home-located. In the “roaming with local breakout” scenario, as outlined in Figure 101: EPC charging 3GPP access - roaming with local breakout, the P-GW is located in the visited network and consequently an inter-operator Gy interface to OCS is necessary. In that scenario, a simple charging rule configuration is necessary to enable interworking with the visited PCRF. The policy and charging rules have to be based on the roaming agreements between the operators. It is recommended to use one single charge, represented by a “standardized” rating group, which in essence provides flat rate local breakout. Dynamic transfer of charging rules from home to visited-PLMN would not be needed. If such transfer were required, it would use the S9 reference point (between the HPCRF and the vPCRF). The charging rules may be preconfigured in the visited P-GW.

Issue: 02B

DN0993921

163

Migration to LTE VoIP


10 Migration to LTE VoIP This section describes circuit switch-packet switche (CS-PS) domain interworking steps that can be identified in the migration path to LTE voice. LTE/EPC is an entirely IP-based network, supporting normal voice calls using VoIP. However, LTE VoIP introduction will take place gradually, and not in parallel with initial LTE introduction for data connectivity. On the contrary, in most cases a smooth migration from circuit switch (CS) voice to LTE voice is assumed. This section describes CS-PS domain interworking steps that can be identified in the migration path to LTE voice. Depending on the operator strategy for voice and LTE rollout and its spectrum assets, some steps may be dropped. It is also possible that some steps may co-exist in parallel. The following migration steps are considered: • • • • •

1. LTE used for high speed packet data access, CS voice over 2G/3G 2. Fallback to CS voice 3. Single radio Voice Call Continuity (SRVCC) 4. LTE used for high speed packet data access only, VoIP over LTE 5. Emergency Call Handling

1. LTE used for high speed packet data access, CS voice over 2G/3G At this phase the operator voice service is solely provided over CS network (see Figure 102: LTE/EPC architecture with PS & CS domains completely separated). LTE access is used for data connectivity only and there will be different terminals for voice (handsets) and data (data cards, etc). No voice specific features need to be supported by the EPS system. Figure 102 Laptopwith LTEdatacard

LTE/EPC architecture with PS & CS domains completely separated Data

LTEradio network

MME

S-GW

Internet

P-GW

OperatorIPnetwork 2G/3G CSnetwork 2G/3G terminal

MSC

CSvoice

2. Fallback to CS voice At this phase the LTE network is still used for data only (see Figure 103: LTE/EPC architecture CS fallback). However, LTE capable Multiradio handsets emerge and these handsets can be simultaneously registered to both LTE and 2G/3G CS network. When voice calls are initiated or received, the handset is directed by the network to the CS network to complete both mobile terminated and mobile originated voice calls. The functionality to fallback from LTE to CS domain is referred to as CS Fallback (CSFB). The CS Fallback procedure requires that eNB, MME and MSC network elements are upgraded to support the procedure. The eNB decides which type of CS Fallback will be used.

164

DN0993921

Issue: 02B



For more information refer to the following feature descriptions: LTE22: Emergency Call Handling LTE562: CS fallback to UTRAN or GSM via redirect LTE736: CS fallback to UTRAN LTE874: CSFB to CDMA/1xRTT for dual RX Ues LTE984: GSM redirect with system information LTE1073: Measurement based redirect to UTRAN LTE1441: Enhanced CS fallback to CDMA/1xRTT (e1xCSFB) LTE498: RAN Information for GSM LTE1196: RAN Information Management for WCDMA

• • • • • • • • •

CS fallback procedure is standardized for 3GPP Rel-8 (TS 23.272). Figure 103

LTE/EPC architecture CS fallback Data

2G/3G terminal

Internet MME

LTEradio network

S-GW P-GW

SGs 2G/3G CSnetwork

OperatorIPnetwork

MSC

CSvoice

3. Single radio Voice Call Continuity (SRVCC) At this phase, the operator provides VoIP over LTE access and IMS is used as enabling SIP session control machinery for VoIP traffic (see Figure 105: LTE/EPC SRVCC architecture for 3GPP accesses). However, as shown in Figure 104: Single radio voice call continuity (SRVCC) principle, it is assumed that LTE coverage is not yet complete and thus interworking with underlying legacy access technology is required. From the voice traffic perspective this implies handing over LTE VoIP call to CS voice call provided by the legacy access technology. The handover functionality from VoIP to CS domain is referred to as Single Radio Voice Call Continuity (SRVCC). SRVCC procedure is standardized for 3GPP Rel-8 (TS 23.216). Features LTE872: SRVCC to WCDMA and LTE873: SRVCC to GSM support this functionality. Figure 104

Single radio voice call continuity (SRVCC) principle

UE

LTEVoIP

2G/3GCSvoice

Issue: 02B

LTEVoIP

2G/3GCSvoice

DN0993921

Singleradiovoice calcontinuity (SR-VCC)

2G/3GCSvoice

2G/3GCSvoice

165



The selection of the domain or radio access is under the network control in SRVCC. The SV interface between MSC Server and MME is used to enable interworking between PS and CS domains. Figure 106: LTE/EPC SRVCC architecture for 1xRTT shows the same with the S102 interface for the 1x interworking case. SRVCC functionality in MSC-Server acts as anchor MSC-Server towards target 2G/3G CS domain. SRVCC in MSC-Server together with VCC anchor hides any mobility between LTE VoIP and 2G/3G CS domain from other side of the call. The VCC anchor is located at the IMS application server and based on the same concept that was defined by 3GPP for Release 7 WLAN Voice Call Continuity. Figure 105 LTEPS/VoIP capable

LTE/EPC SRVCC architecture for 3GPP accesses OperatorVoIPcontrol forLTEandVCC

VoIP

S-GW

LTEradio network

MME

IMS

P-GW Internet

SV 2G/3G CSnetwork

OperatorIPnetwork

MSC

CSvoice

Figure 106 LTEPS/VoIP capable

LTE/EPC SRVCC architecture for 1xRTT OperatorVoIPcontrol forLTEandVCC

VoIP

S-GW

LTEradio network

MME

S102 1xCS IWS

IMS

P-GW Internet

A1 2G/3G CSnetwork

MSC

OperatorIPnetwork

CSvoice

In the case of SRVCC with legacy 3GPP access technologies, during LTE attach procedure the MME receives SRVCC Domain Transfer Number from HSS that is further given to MSC via SV interface. The MSC uses this number to establish connection to VCC anchor during the SRVCC procedure. When the LTE VoIP session is established, it is anchored within IMS in the VCC anchor to use SRVCC later on if needed during the VoIP session. This anchoring occurs in both originating and terminating voice sessions based on IMS subscription configuration and thus is not done per VoIP session. The SRVCC procedure is initiated by the eNB which starts inter-system measurements of the target system. The eNB recognizes voice bearer based QCI=1 and sends handover request with SRVCC indication to MME, which then triggers the SRVCC procedure via SV interface to MSC-Server with Forward Relocation Command. MSCServer initiates the session transfer procedure towards IMS by establishing new session towards VCC anchor that originally has anchored the session. The session is established by MSC-Server using the SRVCC number provided by MME. MSC-Server also

166

DN0993921

Issue: 02B



coordinates the resource reservation in the target cell together with target radio access network. MSC-Server then sends Forward Relocation Response to MME, which includes the necessary information for UE to access the target cell. After the SRVCC procedure has been completed successfully, the VoIP connection is present from the Media Gateway that is controlled by MSC-Server towards the other side of the ongoing session. The CS connection exists towards the radio access network to which UE was moved during the procedure. In case of simultaneous voice and non-voice data connection, the handling of a nonvoice bearer is done by the bearer splitting function in the MME. The MME may preserve the non-voice PS bearer during an SRVCC procedure if the target access system does not support simultaneous voice and data functionality. If the non-voice bearer is also handed over, the process is done in the same way as the normal inter-system handover for packet services. The MME is responsible for coordinating the Forward Relocation Response from SRVCC and packet data handover procedure. In the roaming case, the visited PLMN controls the radio access and domain change while taking into account any related Home PLMN policies. 4. LTE used for high speed packet data access only, VoIP over LTE Similar to step 3, at this phase the operator provides VoIP-over-LTE access and IP multimedia subsystem (IMS) is used as enabling (session initiation protocol) SIP session control machinery for VoIP traffic (see Figure 107: LTE/EPC architecture with all-IP network deploying LTE). However, the difference compared to step 3 is that LTE coverage is complete and thus no interworking with underlying legacy CS access technologies is required. Furthermore, IMS is used as a generic SIP session control machinery for all services, thus removing the need for a CS service infrastructure. At this time the need for CSFB and SRVCC solutions have disappeared. Figure 107

LTE/EPC architecture with all-IP network deploying LTE OperatorVoIP controlmachinery

LTEPS/VoIP capable MME

LTEradio network

IMS Internet

S-GW

OperatorIPnetwork P-GW

5. Emergency Call Handling At this phase the Emergency Call Handling functionality is introduced to provide regulatory requirements in initial phase of LTE implementation. To grant proper handling of emergency call UE will be redirected from LTE to another CS capable RAT (WCDMA or GSM). This action is triggered by MME sending CS Fallback High Priority indication to eNB. As a consequence UE will be redirected to another RAT. Additionally, the LTE572: IMS emergency sessions feature is introduced to provide support for IMS (IP Multimedia Subsystem) emergency sessions for UEs Release 9. Such functionality uses an Access Point Name (APN) that is dedicated for emergency and comprises typically one bearer for SIP signaling and one bearer for VoIP to provide a voice connection between the user and the emergency center.

Issue: 02B

DN0993921

167



An IMS emergency session is established and kept with preference compared to normal sessions. The Flexi Multiradio BTS admits all IMS emergency sessions, that is radio bearers, RRC connections and EPS bearers until operator-configurable thresholds are reached. Voice over LTE (VoLTE) The voice over LTE (VoLTE) service is done with an IP multimedia subsystem (IMS) as specified by 3GPP.

168

DN0993921

Issue: 02B


Nokia service solutions – key benefits and customer values

11 Nokia service solutions – key benefits and customer values The challenges facing operators in today’s business environment are well documented: Average revenue per user (ARPU) is declining in many markets, pressure to reduce operating expenditure (OPEX) is growing and an increase in customer churn is impacting the bottom line. Operators also have to implement a wide variety of security measures while coping with increased network complexity and the launch of new, differentiated services offerings. Nokia has a deep understanding of the customers’ networks, with more than 600 fixed and mobile customers around the world, over 20,000 services employees and 150 years experience in the telecommunications industry. Nokia Services business supports the entire technology life cycle and covers the full range of carrier network technologies. We understand your business and we have assembled a comprehensive portfolio of proven solutions that will help you meet the challenges of today’s market. Key benefits and value for the customers include the following: • • • •

Build competitiveness in a changing market place while at the same time reduce OPEX and optimize your operational performance Seize new business opportunities quickly and with reduced risk Leave the deployment to us and focus on your core business Keep your network at peak performance at all times

Build competitiveness in a changing market place while at the same time reduce OPEX and optimize your operational performance In a world of sharpening competition, it has never been more important for operators to focus on the essentials: identifying and deploying those elusive new value-added data services that hold the promise of profit, not to mention additional revenues, a competitive advantage and better customer relationships. In partnership with you, we can help to design and implement business models for your market situation, based on agile and efficient processes and technology infrastructure. Our Managed Services provide the most extensive portfolio of services and solutions that can help you win new business opportunities through higher efficiency and novel ways to generate new revenue. Our Global Networks Solutions Center brings together a unique talent pool of network planners, consultants and specialists who optimize your radio networks and deliver new levels of Managed Services which are second to none. Nokia track record of Managed Services references around the world is testament to its ability to operate networks and optimize their end-to-end performance, together with service platforms and terminals. We have more than 160 jointly managed services contracts globally – one of the strongest reference portfolios in this growing business field. Seize new business opportunities quickly and with reduced risk Our hosting solution allows you to respond rapidly to new market opportunities while minimizing the technical and financial risks of investment in software, equipment and people skills. We offer a pay-as-you-grow business model and flexible, affordable hosting solutions. Our strong track record, clear insight into global end-user behavior and a precise understanding of how devices work means we are able to offer a broad range of

Issue: 02B

DN0993921

169

Nokia service solutions – key benefits and customer values


hosted multimedia and converged services, including hosted trial and launch, outsourced messaging platforms, hosted mobile virtual network operator (MVNO) and also hosted content and applications. Our consultants are dedicated to work with you to generate new revenues and optimize your capital expenditure (CAPEX), as well as to reduce the risks involved when introducing new technologies (including multi-vendor equipment) or launching new services to your customers. We can also help you optimize your existing services and network, resulting in an increase in your customers’ quality of experience, leading to reduced churn. The constant innovation in our market means that we are required to manage increasingly complex service platforms in the network, while at the same time launching new services and applications quickly. Nokia Services provide the standardized Service Delivery Framework (SDF) to make the launch of new services and applications quicker and easier to integrate and operate. Leave the deployment to us and focus on your core business Our Network Implementation services can provide you an entire Turnkey solution, assuming responsibility as a general contractor for your complete network deployment, allowing you to deploy your resources. We can also provide our Implementation services separately – we offer project management, construction, logistics and network design solutions to cover your needs. Our expertise in this area, based on our experience of deploying hundreds of fixed and mobile networks around the world, as well as our local and global presence leads to high network quality, fulfilling the agreed KPIs. Keep your network at peak performance at all times Nokia Care solutions are designed to keep your network operating at peak performance at all times, 24 hours a day, seven days a week, 365 days a year with global on-site and remote support. A flexible portfolio always allows the right combination of services to achieve the agreed service levels at the right time, in the right place during all phases of the product and software life cycle. Global Care Centers and local experts are also onhand to resolve technical problems and to supplement your in-house experts. This, together with the Hardware Spare Part Management Services, will help you optimize your investments.

170

DN0993921

Issue: 02B


Nokia environmental issues

12 Nokia environmental issues The environmental goals and activities of Nokia are aimed at reducing the environmental impact of Nokia products over their entire life cycle. Life cycle thinking is based on understanding the interdependence of the environmental impacts at different stages of a product's life cycle. Based on the analysis of the environmental aspects and their impacts, Nokia has identified focus areas for its environmental work. The current focus areas in Nokia are environmental management systems at production sites, supplier network management, design for environment, substance management, environmental aspects of networks and sites and recycling of obsolete products. Environmental management systems All Nokia production sites have an ISO14001-certified environmental management system (EMS). With new facilities, the policy is first to build an ISO-certified quality management system as a basis for the EMS. Based on accumulated experience and expertise, an EMS can be built and certified at a new site within one year. The contents of the EMS in place vary somewhat depending on such local circumstances as legislation, regulations, and waste treatment capabilities. However, Nokia has decided to apply Nokia standards in places where they are higher than the prevailing local standards. Supplier network management Nokia purchases an increasing amount of components and assemblies from suppliers around the world. The suppliers' activities account for a substantial part of the environmental impact of Nokia products over their life cycle. Therefore, Nokia has formulated comprehensive environmental requirements for its suppliers, and they are an integral part of Nokia supply chain management practices. As a part of supplier qualification process, the environmental and ethical requirements are assessed. To ensure compliance to Nokia requirements, trained Nokia personnel conduct regular assessments as part of normal supplier assessment. Design for Environment Design for Environment (DfE) means systematic integration of environmental objectives into product design. The purpose of DfE is to satisfy the requirements of customers and other stakeholders in a way that causes less environmental impact. In practice DfE uses design practices that lead, for example, to • • •

minimized material and energy use maximized reuse and recycling minimized use of materials that are detrimental to the environment

DfE objectives have an impact on the product design specification along with other product features, such as performance, quality, usability, and cost effectiveness. In Nokia, environmental issues are a natural part of Product Process. Environmental issues are also a criterion when designing product packaging. Nokia designs its packaging to be recyclable and seeks to reduce the amount and weight of packaging materials without compromising the requirement for adequate protection. Substance management

Issue: 02B

DN0993921

171



An important part of designing environmentally compatible products is the management of the substances that the product contains. In addition to solid materials such as metals and plastics, Nokia and its suppliers use hundreds of substances, preparations and chemicals in the manufacture of components, products, and packaging. Detailed knowledge of their composition is helpful in designing products and manufacturing processes and in handling the manufacturing waste and used products at the end of life. Most components, for example, are inert and perfectly harmless in normal use, but some may have to be given special consideration in order to ensure proper end-of-life (EoL) treatment. Nokia has compiled a Nokia Substance List based on regulatory requirements and reasonable facts. Nokia Substance List identifies substances that have been banned, restricted, or targeted for reduction by Nokia. Environmental aspects of networks and sites Nokia supports the customers by enabling fast and easy site acquisition in an environmentally responsible way. In practice this means that: • • • •

Nokia supports the customer in minimizing the total impact of the network on the landscape and the environment. Nokia provides the customer with information about electromagnetic fields. Nokia assists the customer in dealing with local authorities and communities by providing material, advice, and training on electromagnetic fields. Nokia aims to offer low impact antenna and mast solutions systematically as options.

End-of-life practices Nokia customers can contract with Nokia for environmentally responsible end-of-life treatment of obsolete equipment. The purpose is to recover the material and energy content of the obsolete products and to ensure safe treatment of substances that can cause harm to people or the environment, if disposed of untreated. In a life-cycle perspective, EoL treatment can compensate for some of the environmental impacts of the earlier stages of the product’s life cycle. Nokia Equipment Take Back Service provides Nokia customers with an end-to-end service that includes the removal of end-of-life products from the customers' network and ensures end-of-life treatment in an environmentally responsible way. The Nokia Equipment Take Back Service is offered in several modules representing endto-end work flow of the process: • • • •

removal collection recycling project management

The customers may elect to perform one or more modules themselves and to procure services from Nokia to perform the remaining modules. In Nokia or Other Vendor HW Replacement, that is, SWAP cases, Take Back Service brings in Collection and Recycling Service as Removal and Project Management are already included. The pricing is scalable according to the modules. Product collection and disposal within European Union, WEEE directive

172

DN0993921

Issue: 02B



Product collection and disposal within the European Union Do not dispose of the product as unsorted municipal waste. The crossed-out wheeled bin means that at the end of the product’s life it must be taken to separate collection. Note: this is applicable only within the European Union (see WEEE Directive 2002/96/EC)

Restriction of hazardous substances The LTE/EPC System set complies with the European Union RoHS Directive 2002/95/EC on the restriction of the use of certain hazardous substances in electrical and electronic equipment. The directive applies to the use of lead, mercury, cadmium, hexavalent chromium, polybrominated biphenyls (PBB), and polybrominated diphenyl ethers (PBDE) in electrical and electronic equipment put on the market after 1st July 2006.

Issue: 02B

DN0993921

173

Lte Syd Ranepc

Recommend Documents