Lte Ran and Epc System

Nokia Networks

Flexi Network Gateway, Rel. 3.2 1.0, Operating Documentation, v1 LTE RAN and EPC System Description DN0991589 Issue 04 Approval Date 2014-03-24

LTE 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 © 2014 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

DN0991589

Issue: 04


Table of Contents This document has 179 pages

Summary of changes................................................................... 12

1

Introduction to the NSN LTE/EPC system....................................18

2 2.1 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2

Network architecture.................................................................... 24 LTE overview................................................................................24 Network elements in LTE............................................................. 27 eNB function.................................................................................27 EPC architecture.......................................................................... 28 Portfolio........................................................................................ 30 Flexi Multiradio BTS LTE..............................................................31 Flexi Lite BTS 750........................................................................34 Flexi Network Server.................................................................... 35 Flexi Network Gateway (Flexi NG)............................................... 36 EPS overall architecture...............................................................37 EPS architectures for 3GPP access with GTP-based S5............ 38 EPS architectures for 3GPP access with PMIP-based S5/S8 (IETF variants)............................................................................. 38 EPC architecture for interworking with Gn/Gp SGSN.................. 39 Non-roaming architectures for EPS for Non-3GPP access..........40 Roaming architectures for EPS for 3GPP access (GTP variants)... 41 Roaming architectures for EPS for non-3GPP access.................43 Reference points.......................................................................... 45 LTE/SAE interfaces...................................................................... 47 Radio network interfaces..............................................................48 LTE-Uu interface.......................................................................... 48 S1 interface.................................................................................. 48 X2 interface.................................................................................. 49 Core network interfaces............................................................... 50 Protocol stacks.............................................................................51 Radio protocol architecture.......................................................... 51 EPS protocol architecture............................................................ 56 Protocol architecture for interfaces for legacy 3GPP interworking... 60 LTE multiple access radio interface (TDD)...................................61 Differences between TDD and FDD.............................................62 Beamforming................................................................................63 LTE multiple access radio interface (FDD)...................................64 OFDM concept............................................................................. 66 OFDMA principles........................................................................ 67 SC-FDMA principles.....................................................................68 LTE radio protocol architecture.................................................... 69

2.4.3 2.4.4 2.4.5 2.4.6 2.5 2.6 2.6.1 2.6.1.1 2.6.1.2 2.6.1.3 2.6.2 2.7 2.7.1 2.7.2 2.7.3 2.8 2.8.1 2.8.2 2.9 2.9.1 2.9.2 2.9.3 2.10

Issue: 04

DN0991589

3


4

2.11 2.11.1 2.11.2 2.11.3 2.11.3.1 2.11.3.2 2.12 2.13 2.14 2.15 2.15.1 2.15.2

Multi-antenna techniques............................................................. 70 Receive diversity.......................................................................... 71 Transmit diversity......................................................................... 72 MIMO techniques......................................................................... 72 Downlink MIMO techniques......................................................... 74 Multi-user MIMO techniques........................................................ 74 Radio network optimization.......................................................... 75 Interference mitigation..................................................................76 RAN sharing.................................................................................76 Single RAN introduction............................................................... 78 Nokia Single RAN enablers..........................................................79 Single RAN features.....................................................................80

3 3.1 3.2 3.3

Network and service management...............................................82 Network management architecture.............................................. 82 Managing the LTE/EPC system with NetAct................................ 83 Element management tools......................................................... 83

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Mobility......................................................................................... 85 Mobility scenarios.........................................................................85 Mobility anchors........................................................................... 86 Inter-eNB handover......................................................................87 Inter-RAT handover (3GPP)......................................................... 89 Optimized 3GPP2 (HRPD) inter-RAT handover...........................91 Inter-frequency handover............................................................. 92 Open Access Home eNB Mobility................................................ 93 Roaming.......................................................................................93 Location services......................................................................... 96

5 5.1 5.2 5.3 5.4 5.5 5.6 5.6.1 5.6.2 5.6.3 5.7 5.7.1 5.7.2 5.8

Radio resource management and telecom.................................. 99 RRM functions..............................................................................99 State transitions......................................................................... 103 Connection states for intra-RAT mobility.................................... 105 Tracking Areas........................................................................... 107 Tracking Area Update................................................................ 108 Paging........................................................................................ 110 Paging on S1.............................................................................. 111 Paging on Uu/RRC paging function............................................111 Paging of system information changes.......................................111 EPS bearers............................................................................... 112 Bearer management...................................................................113 Quality of service........................................................................ 114 Additional services......................................................................116

6 6.1 6.2

Transport and transmission........................................................ 118 LTE transport overview...............................................................118 Transport interface options.........................................................120

DN0991589

Issue: 04


Issue: 04

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

Transport switching in eNB........................................................ 122 IP transport addressing.............................................................. 123 Traffic engineering......................................................................124 Traffic prioritization..................................................................... 124 Traffic differentiation................................................................... 125 Traffic shaping............................................................................126 Synchronization..........................................................................126 Synchronization from GPS.........................................................127 Synchronization from 2.048 MHz signal.....................................127 Synchronous Ethernet................................................................127 Timing over Packet.....................................................................128 Synchronization from PDH interface.......................................... 128 Transport admission control....................................................... 129

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 7.5.3 7.5.4 7.6 7.6.1 7.6.2 7.6.2.1 7.6.2.2 7.7

Operability.................................................................................. 130 Operability architecture.............................................................. 130 NetAct framework.......................................................................131 BTS Site Manager......................................................................133 Flexi Multiradio BTS LTE management functions...................... 135 Fault management..................................................................... 136 Configuration management........................................................136 Software management............................................................... 136 Performance management.........................................................137 Hardware/inventory management.............................................. 137 Feature/license management.....................................................138 User account management........................................................ 138 User event log management...................................................... 138 Flexi Multiradio BTS supplementary OAM features................... 139 GPS location retrieval................................................................ 139 NTP clock time synchronization................................................. 139 Automatic iOMS resiliency......................................................... 140 DHCP server for BTS site equipment........................................ 140 Flexi Multiradio BTS diagnosis...................................................140 Trace data support for external usage....................................... 141 Tracing....................................................................................... 142 Cell traffic trace.......................................................................... 143 Subscriber and equipment trace................................................ 145 Self Organizing Network support............................................... 147

8 8.1 8.1.1 8.1.2 8.1.3 8.1.4 8.2

Security...................................................................................... 149 Security requirements and methods.......................................... 149 Security categories.....................................................................149 Security threats.......................................................................... 150 Security areas............................................................................ 150 Security features........................................................................ 151 LTE/EPC M/C/U/S-plane security...............................................152

DN0991589

5


6

8.2.1 8.2.2 8.2.3 8.2.4 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

C-plane security......................................................................... 154 U-plane security......................................................................... 155 M-plane security.........................................................................156 S-plane security......................................................................... 156 User security.............................................................................. 157 BTS security...............................................................................157 NetAct security........................................................................... 159 Network security.........................................................................160 Firewall support..........................................................................160 IPsec support............................................................................. 160 Transport Layer Security support............................................... 162 IP-based filtering for BTS Site Support Equipment.................... 163 Certificate management............................................................. 163 Support of a Public Key Infrastructure....................................... 164

9 9.1 9.2 9.3

AAA and charging...................................................................... 165 LTE/EPC authentication............................................................. 165 Authorization.............................................................................. 166 Accounting and charging............................................................166

10

Migration to LTE VoIP.................................................................170

11

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

12

Nokia environmental issues....................................................... 177

DN0991589

Issue: 04


List of Figures

Issue: 04

Figure 1

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

Figure 2

LTE air interface technology............................................................... 20

Figure 3

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

Figure 4

Smooth migration towards EPS..........................................................23

Figure 5

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

Figure 6

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

Figure 7

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

Figure 8

CRAN functionality............................................................................. 27

Figure 9

Flexi Multiradio BTS site solution....................................................... 31

Figure 10

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

Figure 11

Flexi Multiradio RRH 60 W................................................................. 33

Figure 12

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

Figure 13

Flexi Network Server.......................................................................... 36

Figure 14

Flexi NG..............................................................................................37

Figure 15

Non-roaming architecture for 3GPP access within EPS using GTPbased S5............................................................................................ 38

Figure 16

Non-roaming architecture for 3GPP access within EPS using PMIPbased S5............................................................................................ 38

Figure 17

Roaming architecture for 3GPP access within EPS using PMIP-based S8....................................................................................................... 39

Figure 18

Non-roaming architecture for interoperation with Gn/Gp SGSNs.......39

Figure 19

Non-roaming architecture with EPS using S5, S2a, S2b....................40

Figure 20

Non-roaming architecture with EPS using S5, S2c............................ 41

Figure 21

Roaming architecture for 3GPP access (GTP-based) - home routed.... 41

Figure 22

Roaming architecture for 3GPP access (GTP-based) - local breakout with home operator’s application functions only................................. 42

Figure 23

Roaming architecture for 3GPP access (GTP-based) - local breakout with visited operator’s application functions only................................42

Figure 24

Roaming architecture for EPS using S8, S2a, S2b - home routed.....43

Figure 25

Roaming architecture for EPS using PMIP-based S8, S2a, S2b (chained PMIP-based S8-S2a/b) - home routed................................ 43

Figure 26

Roaming architecture for EPS using S8, S2c - home routed............. 44

Figure 27

Roaming architecture for EPS using S5, S2c - local breakout........... 45

Figure 28

EPS architecture.................................................................................48

Figure 29

Uu user plane protocol stack.............................................................. 51

Figure 30

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

Figure 31

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

Figure 32

Uu control plane protocol stack.......................................................... 54

Figure 33

C-plane operation of PDCP................................................................ 55

DN0991589

7


8

Figure 34

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

Figure 35

X2 user plane protocol stack.............................................................. 56

Figure 36

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

Figure 37

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

Figure 38

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

Figure 39

X2 control plane protocol stack.......................................................... 58

Figure 40

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

Figure 41

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

Figure 42

S10 control plane protocol stack........................................................ 59

Figure 43

S11 control plane protocol stack.........................................................59

Figure 44

S6a control plane protocol stack........................................................ 59

Figure 45

S13 control plane protocol stack........................................................ 59

Figure 46

SBc control plane protocol stack........................................................ 60

Figure 47

S4 user plane protocol stack.............................................................. 60

Figure 48

S12 user plane protocol stack............................................................ 60

Figure 49

S3 control plane protocol stack.......................................................... 60

Figure 50

S4 control plane protocol stack.......................................................... 61

Figure 51

Calculation of antenna weights for beam forming.............................. 63

Figure 52

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

Figure 53

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

Figure 54

Orthogonal frequency division multiplex principle.............................. 67

Figure 55

OFDM and OFDMA subcarrier allocation...........................................68

Figure 56

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

Figure 57

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

Figure 58

2x2 MIMO configuration..................................................................... 73

Figure 59

Operator modules in RAN sharing......................................................77

Figure 60

RAN sharing architecture................................................................... 78

Figure 61

LTE/EPC network management architecture..................................... 82

Figure 62

Mobility scenarios for LTE/EPC.......................................................... 86

Figure 63

Mobility anchor point...........................................................................87

Figure 64

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

Figure 65

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

Figure 66

3GPP inter-RAT mobility.....................................................................90

Figure 67

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

Figure 68

Roaming scenario with home routed traffic........................................ 94

Figure 69

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

Figure 70

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

Figure 71

EMM state transitions....................................................................... 103

DN0991589

Issue: 04


Issue: 04

Figure 72

ECM state transitions....................................................................... 104

Figure 73

RRC state transitions........................................................................105

Figure 74

Intra-RAT mobility in ECM_IDLE...................................................... 106

Figure 75

Intra-RAT mobility in ECM_CONNECTED....................................... 107

Figure 76

Multiple-TA registration concept....................................................... 109

Figure 77

LTE/EPC service data flows..............................................................112

Figure 78

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

Figure 79

Architecture of LTE transport............................................................ 118

Figure 80

Transport Protocol Stack Overview.................................................. 119

Figure 81

Transport Protocol Stack Overview.................................................. 119

Figure 82

Ethernet backhaul for LTE/EPC........................................................121

Figure 83

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

Figure 84

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

Figure 85

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

Figure 86

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

Figure 87

Synchronization from 2.048 MHz signal........................................... 127

Figure 88

ToP based synchronization...............................................................128

Figure 89

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

Figure 90

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

Figure 91

Cell trace concept.............................................................................145

Figure 92

Cell subscriber and equipment trace concept.................................. 146

Figure 93

SON architecture.............................................................................. 148

Figure 94

LTE/EPC M/C/U/S-plane security..................................................... 153

Figure 95

LTE/EPC M/C/U/S-plane security..................................................... 153

Figure 96

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

Figure 97

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

Figure 98

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

Figure 99

S-plane security architecture for LTE/EPC....................................... 156

Figure 100

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

Figure 101

LTE/EPC AKA procedure................................................................. 166

Figure 102

Retrieval of LTE authorization information........................................166

Figure 103

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

Figure 104

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

Figure 105

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

Figure 106

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

Figure 107

LTE/EPC architecture CS fallback.................................................... 171

Figure 108

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

Figure 109

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

DN0991589

9


10

Figure 110

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

Figure 111

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

DN0991589

Issue: 04


List of Tables

Issue: 04

Table 1

Summary of customer benefits...........................................................21

Table 2

CRAN customer benefits.................................................................... 21

Table 3

Subframe configurations in TDD (examples)......................................61

Table 4

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

Table 5

Multi-antenna options in LTE.............................................................. 70

Table 6

Mobility scenarios and anchor points................................................. 87

Table 7

LCS requirements...............................................................................97

Table 8

Scope of RRM functions.....................................................................99

Table 9

QoS scheme for LTE.........................................................................114

Table 10

Standard QCI characteristics............................................................ 115

Table 11

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

Table 12

Security termination points............................................................... 154

Table 13

IPsec capabilities..............................................................................161

DN0991589

11

Summary of changes


Summary of changes Changes between issues 03 (2013-09-03, RL50) and 04 (2014-03-17, RL60) Mobility scenarios (4.1) Information about LTE807: Idle Mode Mobility From LTE To CDMA/1xRTT and LTE870: Idle Mode Mobility From LTE To CDMA/eHRPD feature has been added. Inter-RAT handover (3GPP) (4.4) Information about LTE57: Inter RAT handover from UTRAN has been added. Optimized 3GPP2 (HRPD) inter-RAT handover (4.5) Information about LTE60: Inter RAT handover to eHRPD/3GPP2 has been added. Quality of service (5.7.2) Information about LTE1231: Operator-specific GBR QCIs feature has been added. LTE transport overview (6.1) Information about LTE125: IPv6 for U/C-Plane feature has been added. IPsec support (8.6.2) Information about LTE1390: IPSec Emergency Bypass feature has been added. Migration to LTE VoIP (10) Information about LTE1441: Enhanced CS fallback to CDMA/1xRTT (e1xCSFB) and LTE874: CSFB to CDMA/1xRTT for dual RX UEs feature has been added. Changes between issues 02C (2013-07-09, RL40) and 03 (2013-09-03, RL50) Flexi Multiradio BTS LTE (2.3.1) •

Support of LTE435: RF sharing WCDMA-LTE feature has been added.

Receive diversity (2.9.1) •

Information about Interference Rejection Combining (IRC) has been added.

RAN sharing (2.12) •

Short description of LTE505: Transport Separation for RAN Sharing has been added.

Single RAN features (2.13.2) •

Support of LTE435: RF Sharing WCDMA-LTE feature has been added.

Mobility (4) • • • •

Short description about LTE487: Idle Mode Mobility Load Balancing has been added. Short description of LTE1060: TDD - FDD handover has been added. Short description of LTE1170: Inter-eNB Inter-Frequency Load Balancing feature has been added. New feature LTE1442: Open Access Home eNB Mobility has been described.

RRM functions (5.1)

12

DN0991589

Issue: 04


• •

Summary of changes

Short description of LTE907: TTI Bundling has been added. Short description of LTE1089: Downlink Carrier Aggregation - 20 MHz has been added.

State transitions (5.2) •

Short description of LTE585: Smart DRX has been added.

LTE transport overview (6.1) •

Short description of LTE505: Transport Separation for RAN Sharing has been added.

LTE/EPC M/C/U/S-plane security (8.2) • • •

Figure LTE/EPC M/C/U/S-plane security has been updated. Figure C-plane security architecture for LTE/EPC has been updated. Section S-plane security has been added.

NetAct security (8.5) •

Section NetAct security has been updated.

Certificate management (8.6.5) •

Description of LTE523: Multi-Layered Certificate Authorities feature has been updated.

Certificate management (8.6.5) •

Information about LTE523: Multi-Layered Certificate Authorities and LTE1260: iOMS Certificate Update and Revocation Support features has been added.

Changes between issues 02B (2013-01-22, RL40) and 02C (2013-07-09, RL40) Single RAN introduction (2.13) •

Additional explanation added in the section.

LTE multiple access radio interface (FDD) (2.7) •

Section has been updated, figure OFDMA and SC-FDMA modulation schemes has been updated.

Changes between issues 02A (2012-10-12, RL40) and 02B (2013-01-22, RL40) Single RAN introduction (2.13) •

Section Single RAN introduction has been added.

Changes between issues 02 (2011-12-02, RL40) and 02A (2012-10-12, RL40) NSN portfolio (2.3) •

Flexi Lite is not supported. The Flexi Lite description has been removed.

LTE/SAE interfaces (2.5) •

Issue: 04

Section LTE/SAE interfaces is new and includes content of the LTE/SAE Interfaces document which has been removed from the library.

DN0991589

13

Summary of changes


This section replaces also section Reference points which was visible in the previous release. Mobility (4) •

Information about LTE48: Support of high speed users has been added.

Inter-RAT handover (3GPP) (4.4) •

Information about two new features: LTE1073: Measurement based redirect to UTRAN and LTE984: GSM redirect with system information has been added.

RRM functions (5.1) •

Information about LTE979: IRC for 2 RX paths feature has been added.

Cell traffic trace (7.6.2.1) •

Information about LTE162: Cell Trace with IMSI feature has been added.

Changes between issues 01A (2011-09-21, RL30) and 02 (2011-12-02, RL40) NSN portfolio (2.3) •

Flexi Lite BTS 750 is supported in RL40.

Radio protocol architecture (2.6.1) •

S1 overload handling functionality has been added.

EPS protocol architecture (2.6.2) •

X2 configuration update functionality has been shortly described.

LTE multiple access radio interface (FDD) (2.7) •

Short description about LTE46: Channel Aware Scheduler (UL) feature has been added


Description of the Single Radio Voice Call Continuity (SRVCC) to WCDMA and GSM functionality has been added.

Location services (4.8) •

Information about Observed Time Difference of Arrival location method has been added.

RRM functions (5.1) •

Information about smart admission control functionality and ARP based admission control have been added.

EPS bearers (5.7) • •

Information about number of supported EPS bearers has been updated. Information about E-RAB modification has been added.

Additional services (5.8)

14

DN0991589

Issue: 04


•

Summary of changes

The section “Additional services” has been added.

Synchronization (6.6) •

Information about synchronization priorities has been added.

LTE/EPC C/U/M-plane security (8.2) •

Crypto Agent functionality has been shortly described.

BTS security (8.4) •

The SW Verification Agent functionality has been shortly described.

Migration to LTE VoIP (10) •

Information about features which supports Single radio Voice Call Continuity (SRVCC) has been added.

Changes between issues 01 (2011-06-17, RL30) and 01A (2011-09-21, RL30) All chapters - editorial changes. Introduction to the NSN LTE/EPC system (1) •

Information about migration from WiMAX to LTE has been added.

Radio protocol architecture (2.6.1) •

Figure U-plane operation of PDCP and RLC has been updated.

Transport admission control (6.7) •

Note that in RL30 for admission control only QCI=1 is supported has been added.

Changes between issues 01 DRAFT(2011-04-20, RL30) and 01 (2011-06-17, RL30) All chapters - editorial changes. Introduction to the NSN LTE/EPC system (1) • • •

LTE is also Release 9, so this information has been added. Information about WCDMA core network has been deleted. There is no need for describing WCDMA. Information about FDD and TDD mode has been added.

Network architecture (2) •

Short description about Security Gateway has been added.

LTE overview (2.1) •

Short description that management system traffic always goes through NetAct has been added.

eNB function (2.2.1) •

Issue: 04

Headers has been changed as follows: Radio Network Layer 1 (Physical Layer), Radio Network Layer 2, Radio Network Layer 3.

DN0991589

15

Summary of changes


EPC architecture for interworking with Gn/Gp SGSN (2.4.3) •

Short description about inter access mobility has been added.

OFDMA principles (2.7.2) •

Additional explanation to figure “OFDM and OFDMA subcarrier allocation” has been added.

RAN sharing (2.12) •

Section has been modified.

Network and service management (3) •

Short introduction in Network and service management section has been added.

Mobility scenarios (4.1) •

Short description of Subscriber Profile Based Mobility functionality has been added.


Description of the Network Assisted Cell Change to GSM functionality has been added.

Location services (4.8) •

Short description that cell ID based location service support emergency calls has been added.

State transitions (5.2) • •

Short description that the Flexi Multiradio BTS supports DRX with long DRX cycles has been added. RRC Connection Re-establishment has been added.

EPS bearers (5.7) • •

This section has been rearranged in order to be more readable. Figure “LTE/EPC EPS high level bearer model” has been updated.

Bearer management (5.7.1) •

Bearer management functions has been modified.

Transport and transmission (6) • •

Short introduction in Transport and transmission section has been added. Multiple S1-MME interfaces are supported.

LTE transport overview (6.1) •

Explanation that transport sub-modules support both LTE and WCDMA SW applications (multi-radio) with single mode operation has been added.

Transport interface options (6.2) •

16

Sentence that the eNB supports the configuration of up to 16 BFD sessions has been added.

DN0991589

Issue: 04


•

Summary of changes

It has been specified that Bidirectional Forwarding Detection (BFD) is used for L3 path failure detection.

Transport switching in eNB (6.3) •

The heading has been changed into Traffic aggregation towards mobile backhaul instead of Concept of eNB chaining. The heading was misleading.

Traffic prioritization (6.5.1) •

Clarification that the DSCP-to-PCP (Priority Code Points) mapping table is configurable has been added.

Traffic differentiation (6.5.2) •

Description of the traffic differentiation has been modified.

Migration to LTE VoIP (10) •

Emergency Call Handling functionality has been added.

This is the first issue of the document for RL30. This document is a combined version of two documents, LTE/EPC System Overview and LTE RAN System Description, which were available in the previous releases.

Issue: 04

DN0991589

17

Introduction to the NSN LTE/EPC system


1 Introduction to the NSN LTE/EPC system

g

This document provides an overview of the LTE/EPC (Long Term Evolution/Evolved Packet Core) system. Functions and features are described without the reference to the system releases. This information can be found in the NSN LTE roadmap. NSN expects five billion people to be connected to the Internet by 2015. Wireless access plays a major role in realizing this target. Wireless networks will be used to extend broadband penetration beyond the reach of wireline networks. Evolution of terminals and networking technology coupled with Internet access as a global phenomenon allow advanced operators to report double-digit growth in mobile data usage in this moment. With a view to taking the next step up, the evolutionary ladder beyond HSPA, 3GPP Release 8 and Release 9 has standardized a technology called Long Term Evolution/System Architecture Evolution (LTE/SAE). The RL50 release is based on 3GPP Release 10 and introduces LTE-Advanced.The RL35TD release is based on 3GPP Release 10 and introduces LTE-Advanced. It is designed to: •

•

•

make the most of scarce spectrum resources: Deployable with bandwidths ranging from 1.4 MHz to 20 MHz, LTE/SAE provides up to four times the spectral efficiency of HSDPA Release 6. afford users an experience with today’s best residential broadband access: LTE/SAE delivers theoretical peak data rates ranging up to 173 Mbps and reduces latency to as low as 10 ms. leverage flat all-IP network architecture and a new air interface to significantly cut per-Mbyte costs, with later product innovations potentially improving performance even further: For instance, a 4x4 Multiple Input/Multiple Output (MIMO) scheme will boost downlink rates up to 326 Mbps.

CRAN Centralized RAN (CRAN) is Nokia innovative solution specialized for: mobile operators worldwide providing mobile broadband coverage to stadiums, concert halls, train stations, festivals in parks, convention centers. Venues like that, bring a large concentration of people in a small areas. At the same time people in such places are using the mobile broadband services in ever-increasing amounts causing data traffic to increase as never before.

System approach Based on these performance targets 3GPP is defining the air interface, network architecture, and system interfaces. All services are packet-based; this includes voice services which are implemented as voice over IP (VoIP). Figure 1: LTE/SAE high-level architecture shows an LTE/SAE network’s high-level architecture. LTE/SAE does not entail a circuit-switched domain. 3GPP envisages fully IP-based transmission. The IP backbone network supports guaranteed QoS on demand with a very simplified, but backward compatible QoS concept. Carrier-grade Ethernet is used where possible; in particular to connect the evolved node B (eNB), the LTE’s base station.

18

DN0991589

Issue: 04


Figure 1


LTE/SAE high-level architecture ServiceControlandDataBases

IMS

Access

PCRF

HSS/AAA

CoreSwitching& Transport

MME

Internet eNodeB S-GW

P-GW

In the following, the NSN solution of the LTE/SAE architecture is referred to as NSN LTE/EPC system.

Simplified network architecture The NSN LTE/EPC system is streamlined to optimize network performance, maximize data throughput, and minimize latency. Rather than four nodes (NB, RNC, SGSN, GGSN), the LTE/EPC system comprises a far simpler configuration of just eNB, two logical user plane gateways, Serving Gateway and PDN Gateway, collectively called the S-GW/P-GW, and one control plane gateway (MME). Gateway functions may be provided in common or separate physical nodes. All entities are connected by standardized interfaces to support multi-vendor configurations. Transport is fully IPbased. The access network operates without a central controller (BSC, RNC). All functions of central controller have been moved to the base stations (eNBs). The eNBs interconnect and connect directly to the S-GW/P-GW and MME to exchange control and user information.

High-performance air interface The LTE air interface differs markedly from legacy technology. Advanced applied Orthogonal Frequency Division Multiplexing (OFDM) technologies achieve performance and savings goals based on low total cost of ownership. Figure 2: LTE air interface technology summarizes the technological approach to the projected air interface. Many orthogonal OFDM sub-carriers may 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 RF design and extending the battery life of the terminals.

Issue: 04

DN0991589

19


Figure 2 scalable


LTE air interface technology Hybrid ARQ 1

64QAM Modulation

2 NACK

FastLink Adaptation

ACK

1

DL:OFDMA UL:SC-FDMA

Combined decoding Availablebandwidth

2 RXBuffer

Short TTI=1ms Transmissiontimeinterval

Sub-carriers

OFDM symbols

Frequency

Guard intervals

TX

RX

MIMO Channel TX

RX

AdvancedScheduling Time&Frequency (FrequencySelectiveScheduling)

Time

OFDM allows improved interference control, advanced scheduling techniques and ease of implementation of Multiple Input Multiple Output (MIMO) concepts. MIMO antenna technology and higher order modulation (64QAM), combined with fast link adaptation methods, maximize the spectral efficiency. In principle, operators do not need to acquire new spectrum. The LTE air interface is designed to operate in the same spectrum as, the legacy 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 FDD LTE multiple access is based on OFDMA in the downlink direction and SC-FDMA in the uplink direction. The system’s flexible spectrum allocation (including scalable bandwidth) allows carriers to be spread across any suitable spectrum licensed for 2G or 3G operation. Deployable in spectrum bands with bandwidths of 1.4, 3, 5, 10, 15, and 20 MHz, LTE offers unique spectrum flexibility. The small 1.4 and 3.0 MHz bandwidths are optimized for GSM and CDMA re-farming, where operators might not initially be able to free up more bandwidth.

Customer benefits The introduction of LTE provides the following key benefits to operators compared with existing 3G deployments: •

•

•

•

20

Maximized use of allocated frequency bands LTE provides high aggregate data rates per cell and supports flexible frequency bandwidths and in particular allows re-farming of 2G spectrum. Reduced cost of ownership LTE has a simpler architecture: it has fewer nodes and fewer node types, and is entirely IP-based. It also uses IP transport allowing the use of cheap equipment and infrastructure. The ability to run voice and data services on a unified infrastructure will also have an impact on reducing costs. Competitive mobile broadband packet access LTE is optimized for broadband IP packet access providing 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. LTE can support terminal speeds of 150 to 350 km/h and cell ranges of up to 100 km. Superior inter-technology mobility

DN0991589

Issue: 04



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). summarizes the main customer benefits. Table 1

Summary of customer benefits

Operator benefits •

• • •

•

Subscriber benefits

reduced complexity, flat IP-based packet-only • architecture lower operator CAPEX and OPEX interworking with legacy systems as an • integral part of service continuity • scalable bandwidth allows flexible deployment with limited spectrum significant improvements in spectral efficiency and data performance for multimedia services economies of scale leveraging existing assets meaning rapid availability for the mass market

enriched user experience with real time, interactive services and seamless connectivity broadband mobility at a decreasing cost wide variety of devices and services

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

CRAN customer benefits

Operator benefits • •

• •

•

g

Issue: 04

Subscriber benefits

turning interference into usable interface • environment reducing limitations of the throughput that typically manifest themselves on the uplink (rather than downlink) in stadiums and other sport complexes potentially doubling the UL aggregated cell throughput with UL-CoMP no additional HW or modification of existing HW needed, that saves additional hardware investments and avoids additional operational costs flexibility of the system provided by its unlimited scalability

enhancement of the LTE user experience by increase of throughput and service quality

Please note that this is the system description covering all the functionalities supported by the LTE release. Not all of the functionalities described here are supported by the CL10 release. For CL10 feature dependency, see the LTE1724 CL10: Centralized RAN 10 MHz.

DN0991589

21



Network evolution and migration NSN is committed to providing a smooth evolutionary path for every operator, following a roadmap that factors each operator’s installed base and strategy into the equation (see Figure 3: Architectural evolution of existing 2G/3G networks to LTE): •

• •

•

•

•

3G operators with a deployed WCDMA/HSPA network can migrate directly to LTE/EPC. Migrating to the flat network architecture of Internet High Speed Packet Access (I-HSPA) may also be beneficial because it accommodates LTE/EPC’s flat IP-based network architecture while supporting legacy WCDMA/HSPA handsets. The operator can thus enjoy the transport and network scaling benefits immediately, and easily upgrade the network to LTE/EPC later. 3G operators who have deployed I-HSPA have flat network architecture similar to LTE/EPC in place, and can thus cost-efficiently introduce LTE/EPC. Operators running 2G networks (GSM/GPRS) can introduce LTE/EPC directly or via one of the above WCDMA/HSPA paths, depending on their timetables for introducing mobile broadband services and the spectrum they have available. Because LTE supports bands as small as 1.4 MHz, spectrum may be re-farmed smoothly and gradually from GSM to LTE. CDMA operators can introduce LTE/EPC networks directly, or follow one of the above paths. GSM/EDGE may be a good choice for strategies more immediately focused on voice centric business. The same applies to Greenfield operators. Operators opting to take the I-HSPA path can capitalize on the ecosystem of HSPA terminals, benefit from the flat architecture today, and quickly optimize mobile broadband performance. Operators with WiMAX can easily migrate to LTE. Both technologies share common characteristics, namely, a physical layer based on Orthogonal Frequency Division Multiplexing (OFDM), a flat IP architecture, and use of multiple antenna system techniques (MIMO) to achieve high data rates. In LTE/EPC architecture the PDN Gateway (P-GW) serves as a mobility anchor for non-3GPP technologies. Operators with TD-SCDMA networks, which are currently deployed in China only, will probably migrate directly to LTE, preferably using the TDD mode of LTE.

Figure 3

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

22

DN0991589

Issue: 04



Network deployment 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 4: Smooth migration towards EPS: 1. Introduction of direct tunnel between RNC and GGSN (HSPA R7) 2. Introduction of RNC functionality and direct tunnel between NB and GGSN (I-HSPA R7) 3. Introduction of EPC (LTE R8) 4. Upgrade ability of legacy SGSN with MME functionality 5. Upgrade ability of legacy GGSN with P-GW functionality Figure 4

Smooth migration towards 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

NSN LTE/EPC product portfolio The LTE/EPC system comprising the logical entities eNB, S-GW, P-GW, and MME is implemented by the following NSN products: •

•

•

Issue: 04

Flexi Multiradio BTS LTE 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 operates in LTE SW mode, to become the Flexi Multiradio BTS LTE. It is possible for Flexi Multiradio RF module to operate in concurrent GSM and LTE mode. From a BTS site installation and hardware point of view, Flexi Multiradio BTS LTE enables operators to build BTS sites using modules, without the requirement for a specific BTS cabinet. Flexi Network Server (Flexi NS) The MME functionality is provided by the Flexi Network Server (Flexi NS) which is a high transaction capacity product based on AdvancedTCA (ATCA) standard. It is optimized for an all-IP flat architecture. Flexi Network Gateway (Flexi NG) S-GW/P-GW functionality is provided by the Flexi NG which is based on the AdvancedTCA (ATCA) hardware platform and Flexi Platform operating software and middleware.

DN0991589

23

Network architecture


2 Network architecture Long Term Evolution (LTE) is a 3GPP project that provides extensions and modifications of the UMTS system to allow implementing a high data rate, low latency, and packet optimized radio access networks. Service Architecture Evolution (SAE) is an associated 3GPP project working on 3GPP core network evolution. The focus is on the packet switched domain, where data and voice services are supported over the same packet switched network. The LTE/SAE solution, known as the LTE/EPC system, applies flat network architecture as illustrated in Figure 5: LTE/EPC flat network architecture and direct tunnel. The radio network consists of a single node, the 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. 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 may or may not co-exist within a single gateway 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 PDN (for example, the Internet or the operator's IP Multimedia Subsystem (IMS))

Figure 5

LTE/EPC flat network architecture and direct tunnel MME eNB

S-GW/P-GW

Directtunnel

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. LTE/EPC provides decreased cost per transmitted bit. This is achieved by: • • •

advanced modulation techniques that allow optimized use of radio frequency flat architecture that minimizes the number of network elements and optimizes the usage of the transmission network capability to serve high quality, low latency real-time traffic, allowing both voice and data services to be provided over a single all-IP network

2.1 LTE overview The LTE network architecture is called flat architecture. Flat architecture means that UE is connected to the eNB, and eNB is connected directly to the core network. All radio network controller functionalities are handled by the eNB. Management system traffic to and from LTE/EPC network elements always goes through NetAct. For more information, see Network and service management section.

24

DN0991589

Issue: 04



Functional split in LTE LTE fully implements radio function in the eNB, as illustrated in Figure 6: Functional split between radio access and core network. Communication between eNB and S-GW/MME is done via transport network, see Figure 29: Uu user plane protocol stack and Figure 32: Uu control plane protocol stack. Figure 6

Functional split between radio access and core network

eNB InterCellRRM RBControl ConnectionMobilityCont. Radio AdmissionControl

S-GW eNBMeasurement Configuration&Provision

S1-U

P-GW S5/S8

UEIP Addressallocation

Mobility Anchoring

DynamicResource Allocation(Scheduler)

PacketFiltering

RRC PDCP

MME NASSecurity

RLC

S1-MME

IdleState MobilityHandling

MAC

ActiveState MobilityHandling

PHY

SAEBearerControl

E-UTRAN

EPC

S1 flexibility in LTE 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 7: EUTRAN and EPC with S1 Flex.

Issue: 04

DN0991589

25



Figure 7

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

MME

The Flexi Multiradio BTS 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 function perfectly serves customers' needs that often appear during megaevents, like concerts, sport events in places such as stadiums where throughput limitations often appear on the uplink. The solution is based on an extended intra-eNB uplink CoMP functionality. The individual eNBs are interconnected in a linear chain to exchange uplink data for inter-eNB uplink CoMP. An eNB can be connected to two neighbor eNBs (and obtain nine CoMP set combinations). This approach creates a sixcell-configuration (including the serving cell). The CRAN functionality is supported by the standard LTE HW. That is why no additional expenditure on the infrastructure is needed. CRAN supports a dedicated eNB configuration with each FSMF containing two FBBAs and with pre-defined Inter-FSM cabling rules. With the CRAN feature, up to three FSMFs can be chained/looped (with RX operating on two 10 MHz bands). Larger configurations are built with groups of 3 FSMFs, and maximum CoMP size up to 12 antennas with two RX paths processed by eNB IRC receiver. For more information, see the LTE1724 CL10: Centralized RAN 10 MHz feature description. The CRAN functionality is presented in the picture below. The FSMF sees all six cells with 12 receivers, and performs Dynamic UL-CoMP.

26

DN0991589

Issue: 04


Figure 8

24A

FRxx


CRAN functionality

24B

25A

FRxx

25B

26A

26B

27A

FRxx

FRxx

FBBA

FBBA

27B

28A

28B

FRxx

29A

29B

FRxx

FSMF

2.2 Network elements in LTE 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.2.1 eNB function The eNB includes the majority of the LTE system function. The eNB hosts the following functions: Radio Network Layer 1 (Physical Layer) • • • • • • • • • • • • •

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 weighting of physical channels modulation and demodulation of physical channels frequency and time synchronization radio characteristics measurements and indication to higher layers multiple Input Multiple Output (MIMO) antenna processing transmit diversity (TX diversity) beamforming RF processing

Radio Network Layer 2 • • •

Issue: 04

PDCP: robust header compression (RoHC); Ciphering RLC: RLC segmentation; Automatic Repeat Request (ARQ) MAC: MAC multiplexing

DN0991589

27



• • •

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.2.2 EPC architecture 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) 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: • • •

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

28

authenticates and authorizes the user provides roaming support with the S6a interface

DN0991589

Issue: 04


• • • • • •

• • • • • •


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 for PP2 operators): SR-VCC support for 1X CS-voice (available in future releases and applicable for PP2 operators only), and SR-VCC for 3GPP (UTRAN/GERAN) provides CS Fallback (CSFB) functionality towards GERAN, UTRAN, or CDMA2000 provides support for MME and S-GW relocation (available in future releases) manages EPS bearers terminates for Non-Access Stratum (NAS) signaling provides NAS signaling security and delivery of security keys to eNB supports lawful interception for the signaling traffic

Serving Gateway (S-GW) The S-GW terminates the LTE core user plane interface with the E-UTRAN. User Equipment (UE) is assigned to a single S-GW at a given point in time. The S-GW acts as a user plane 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 takes care of 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: • • • • • • • •

serves as an anchor point both for inter-eNB handover and for intra-3GPP mobility (that is handover to and from 2G or 3G) provides default EPS bearer termination (applicable only for the IETF variant) provides dedicated non-GBR/GBR EPS bearer termination (applicable only for IETF variant) provides roaming support with S8 interface is responsible for packet forwarding, routing, and buffering of downlink data for UEs that are in LTE-IDLE state is responsible for data forwarding to HSGW in the case of handover from LTE to HRPD (applicable only for pp2 operators only and available in future releases) is responsible for data forwarding from source S-GW to target S-GW in the case indirect data forwarding provides lawful interception support in roaming case

Packet Data Network Gateway (P-GW) The P-GW acts as a user plane anchor. It allocates an IP address for the UE. The 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

Issue: 04

DN0991589

29



operator’s online and offline charging systems. It also provides home agent functionality for interworking between non-3GPP networks and when the interface between the S-GW and P-GW is implemented using a mobile IP-based protocol. P-GW functionality: •

serves as a global mobility anchor for mobility between – –

• • • • • • •

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 S8 interface supports S-GW relocation 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 of interest to LTE/EPC are the following: •

Home Subscriber Server (HSS) The HSS is the Core Network entity responsible for managing user profiles, 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. HSS functionality: – – – – –

•

•

•

providing the user authentication and authorization information to the MME managing user profiles preserving user location at MME level storing of mobility and service data for every subscriber permanent and central subscriber database

Policy Charging and Rules Function (PCRF) The PCRF is responsible for brokering QoS Policy and Charging Policy on a per-flow basis. In roaming scenarios it provides services as hPCRF and as vPCRF. Authentication, Authorization and Accounting function (AAA) The AAA is responsible for relaying authentication and authorization information to and from non-3GPP access network connected to EPC. Serving GPRS Support Node (SGSN) is responsible for the transfer of 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.3 Portfolio The LTE/EPC architecture portfolio comprises the following network elements: • •

30

Flexi Multiradio BTS LTE Flexi Network Server

DN0991589

Issue: 04


•


Flexi Network Gateway (Flexi NG)

2.3.1 Flexi Multiradio BTS LTE 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 LTE SW mode. It is possible for Flexi Multiradio RF Module to operate in concurrent GSM and LTE mode. From a BTS site installation and hardware point of view, Flexi Multiradio BTS enables operators to build BTS sites using modules, without a specific BTS cabinet. With LTE447: SW support for RF sharing GSM-LTE feature it is possible for Flexi Multiradio RF Module to operate in concurrent GSM and LTE mode. This means that one Flexi Multiradio RF Module is transmitting both GSM/EDGE RF carriers and LTE RF carrier signals at the same 3GPP frequency band. Operator can run both GSM and LTE concurrently by the same Flexi Multiradio RF Module. With LTE435: RF sharing WCDMA-LTE feature it is possible for Flexi Multiradio RF Module to operate in 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 2100 MHz band. 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: •

Issue: 04

system module

DN0991589

31



• •

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 210W 3-sector Radio Module. In the 3-sector BTS, all RF functions are integrated to one single outdoor installable 3U high module. With two 3-sector RF Modules in 2TX MIMO configuration, TX power is 120W per sector/cell (60 W + 60 W). 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) that can support one sector with the following integrated features: • • • • • • • • • •

32

two transceivers to support 2TX MIMO 40W + 40W output power at antenna connectors two linear power amplifiers two RF filters for TX/RX 2 way RX diversity wide bandwidth support (up to 20 MHz depending on 3GPP band RF variant) -48 V DC input power supply no fans OBSAI optical interface to the BTS system module antenna tilt support

DN0991589

Issue: 04


Figure 11


Flexi Multiradio RRH 60 W

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

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

The LTE eNB is based on the Flexi Multiradio BTS. The modular architecture of Flexi Multiradio BTS enables a flexible evolution from the initial cost-effective roll-out coverage BTS site up to a high capacity BTS site solution. The modules are easy to install and move, and the modular structure allows network element to be installed anywhere.The Flexi Multiradio BTS consists of: • • • •

System Module FSMF containing baseband processing and transport. FSMF contains an in-built Ethernet transport capabilities one or two optional capacity extension sub-modules (FBBA) one to three RF Modules (FZHA or FZNC) one optional outdoor-capable Flexi Power Module (FPMA)

In RL35TD IR new Remote Radio Head modules are introduced. For more information see feature descriptions under BTS Site Solution category. The Flexi Multiradio BTS is flexible and easy to configure. The RL25TD release offers various configurations: • • •

up to six TD-LTE cells with optional 2TX MIMO, the Flexi Multiradio BTS supports 2way uplink maximum ratio combining (MRC) diversity as standard 2x2 MIMO site configurations with either 6-pipe RF Modules (FZNC) or 8-pipe RF Modules (FHZA) Flexi Multiradio BTS also supports beamforming, both single stream beamforming and dual stream beamforming

The Flexi Multiradio BTS is flexible and easy to configure. The RL35TD IR release supports legacy RL25TD configurations and offers new Single and Dual Mode configurations:

Issue: 04

DN0991589

33



• • • •

indoor and outdoor configurations up to six TD-LTE sectors per site up to 8x8 MIMO site configurations optionally RRH Chaining and Cell Combination available

For more information on supported configurations, see Creating TD-LTE Configurations document.LTE1483: RL35TD TD-LTE Site configuration with Ir interface feature description. All 10 MHz configuration are same as 20 MHz, there is no specific 10 MHz configuration.

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

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 BTSSM O&M interface between eNB and Public Key Infrastructure (PKI) X2 interface between eNBs

Figure 12

External interfaces of the Flexi Multiradio BTS LTE PublicKey Infrastructure

IntegratedOperation MediationSystem

UserEquipment O&M LTE-Uu

ServingGateway

O&M

O&M

S1-U

S1-MME

BTS SiteManager

X2

othereNBs

MobilityManagement Entity

2.3.2 Flexi Lite BTS 750 Flexi Lite BTS 750 is compact standalone one box Micro BTS for coverage and capacity enhancements. It is called Mini or Pico BTS as well. This Flexi Lite BTS RF variant supports 3GPP band 13 that is known also as upper 700 MHz or 750 MHz.

34

DN0991589

Issue: 04



Small complete mini BTS can be installed indoors or outdoors to give extra capacity for hot spots like office area, campus and shopping malls. With high output power and 2TX MIMO support it can be used as fill in and extension of network to coverage e.g. suburban areas. Flexi Lite BTS 750 operates at upper 700 MHz 3GPP band 13 with LTE support and comprises the following integrated features: • • • • • • •

750 MHz max 10 MHz bandwidth for one cell 5+5 W output power, 2TX MIMO support can be installed indoors and outdoors (IP65) AC power feed 100... 240 VAC transport: Ethernet (optical fiber or wireline) two N-type RF connectors for external antenna optional integrated cross polarized antenna

2.3.3 Flexi Network Server Flexi Network Server (Flexi NS) is a high transaction capacity product on top of Advanced TCA (ATCA) hardware (see Figure 13: Flexi Network Server). It is optimized for all-IP flat architecture, and is used for control plane-only mobility management entity (MME) functionality. The 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 has 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. 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. The 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.

Issue: 04

DN0991589

35



Figure 13

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.3.4 Flexi Network Gateway (Flexi NG) 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 (PGW), 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 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.

36

DN0991589

Issue: 04



Flexi NG is based on the AdvancedTCA (ATCA) hardware platform (see Figure 14: 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 14

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.4 EPS overall architecture EPS solutions for 3GPP access are typically selected by operators who want to introduce EPS as smooth evolution to their existing 2G/3G infrastructure. EPS solutions for non-3GPP access are typically selected by operators who want to maximize the deployment of generic, non-3GPP protocols and to minimize the deployment of 3GPP specific protocols. The EPS architecture has three key aspects which address the performance requirements for LTE/EPC: • • •

reduction of the number of network elements on the data path, compared to GPRS/UMTS streamlining of RAN function, by providing it in a single node separation of the control and user plane network elements (MME and S-GW).

There are various architecture reference models specified in 3GPP TS 23.402: • •

Issue: 04

EPS architectures for 3GPP access with GTP-based S5 EPS architectures for 3GPP access with PMIP-based S5/S8 (IETF variants)

DN0991589

37



• • • •

EPC architecture for interworking with Gn/Gp SGSN Non-roaming architectures for EPS for Non-3GPP access Roaming architectures for EPS for 3GPP access (GTP variants) Roaming architectures for EPS for non-3GPP access

2.4.1 EPS architectures for 3GPP access with GTP-based S5 The GTP-based (with GTP S5 reference point) EPS solution for 3GPP access is typically selected by the operators who want to introduce EPS as smooth evolution to their existing 2G/3G infrastructure. Figure 15

Non-roaming architecture for 3GPP access within EPS using GTP-based S5

3GPP Access

HSS SGSN

2G/3G

PCRF

S3 S6a

S1-MME MME S11

Gx

Rx

S12 S4

S10

Serving Gateway

E-UTRAN

S1-U

S5 GTP

PDN Gateway

SGi

Operator's IP Services (forexampleIMS, PSSand soon)

2.4.2 EPS architectures for 3GPP access with PMIP-based S5/S8 (IETF variants) The IETF based (with PMIPv6 S5/S8 reference point) EPS solution for 3GPP access is typically selected by the operators who want to maximize the deployment of generic, IETF defined protocols and to minimize the deployment of 3GPP-specific (for example, GTP) protocols. The IETF variant can be deployed for both 3GPP and non-3GPP access. Figure 16

Non-roaming architecture for 3GPP access within EPS using PMIP-based S5

3GPP Access

HSS SGSN

2G/3G

PCRF

S3 S1-MME

S6a MME S11 S10

E-UTRAN

S1-U

38

S12

Gxc

Gx

Rx

S4 Serving Gateway

DN0991589

S5 GTP

PDN Gateway

SGi


Issue: 04


Figure 17


Roaming architecture for 3GPP access within EPS using PMIP-based S8 hPCRF

Gx

Rx

HSS PDN Gateway

SGi

HPLMN


VPLMN

S9 3GPP Access

SGSN

2G/3G

vPCRF

S3 S6a

S1-MME MME S11

S12 S4

S10

S8

Serving Gateway

E-UTRAN

S1-U

Gxc

2.4.3 EPC architecture for interworking with Gn/Gp SGSN Intra PLMN roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S GW are enabled by: • •

Gn function as specified between two Gn/Gp SGSNs, which is provided by the MME Gn function as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the P GW

All this Gn function is based on GTP version 1 only. The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure 18: Non-roaming architecture for interoperation with Gn/Gp SGSNs. Inter access mobility can be build introducing overlay to existing Packet Core elements via Gn interfaces. The benefit is that there is no need to change the existing 2G/3G live deployment when introducing LTE. Figure 18

Non-roaming architecture for interoperation with Gn/Gp SGSNs

GERAN Gn/Gp SGSN

UTRAN

Gr HSS

Gn

Gn

PCRF S6a

S1-MME MME

Rx

Gx

S11 S10 E-UTRAN S1-U

Serving Gateway

S5

UE

Issue: 04

DN0991589

PDN Gateway

SGi


39



2.4.4 Non-roaming architectures for EPS for Non-3GPP access The following considerations apply to interfaces where they occur in Figure 19: Nonroaming architecture with EPS using S5, S2a, S2b, Figure 20: Non-roaming architecture with EPS using S5, S2c, Figure 24: Roaming architecture for EPS using S8, S2a, S2b home routed, Figure 25: Roaming architecture for EPS using PMIP-based S8, S2a, S2b (chained PMIP-based S8-S2a/b) - home routed, Figure 26: Roaming architecture for EPS using S8, S2c - home routed, and Figure 27: Roaming architecture for EPS using S5, S2c - local breakout: • • • • •

g

S5 can be GTP-based or PMIP-based. Gxc is used only in the case of PMIP variant of S5 or S8. Gxa is used when the Trusted non-3GPP Access network is owned by the same operator. Gxa is terminated in the Trusted non-3GPP access if supported. S2c is used only for DSMIPv6 bootstrapping and DSMIPv6 De-Registration (Binding Update with Lifetime equals zero) when the UE is connected via 3GPP access. Dashed lines are used in Figure 20: Non-roaming architecture with EPS using S5, S2c, Figure 25: Roaming architecture for EPS using PMIP-based S8, S2a, S2b (chained PMIP-based S8-S2a/b) - home routed and Figure 27: Roaming architecture for EPS using S5, S2c - local breakout to indicate this case.

SWu shown in Figure 19: Non-roaming architecture with EPS using S5, S2a, S2b also applies to architectural reference models in Figure 20: Non-roaming architecture with EPS using S5, S2c and Figure 24: Roaming architecture for EPS using S8, S2a, S2b - home routed to Figure 27: Roaming architecture for EPS using S5, S2c - local breakout, but is not shown for simplicity. Figure 19

Non-roaming architecture with EPS using S5, S2a, S2b HSS

S6a

SWx

Rx PCRF

Gxc


Gx

SGi 3GPP Access

Serving Gateway

PDN Gateway

S5

S6b

Gxb Gxa

S2b

SWm 3GPP AAA Server

ePDG HPLMN

S2a

SWn

Non-3GPP Networks

SWu Untrusted Non-3GPP IP Access

Trusted Non-3GPP IP Access

UE

40

DN0991589

SWa STa

Issue: 04


Figure 20


Non-roaming architecture with EPS using S5, S2c HSS

S6a

SWx

Rx Gxc

PCRF

Gxa


Gx

SGi Serving 3GPP Access Gateway

S5

PDN Gateway

S6b

Gxb S2c

Gxa

S2c

SWm 3GPP AAA Server

ePDG

S2c

HPLMN

SWn

Non-3GPP Networks Trusted Non-3GPP IP Access

S2c

Untrusted Non-3GPP IP Access

SWa

UE

S2c

STa

2.4.5 Roaming architectures for EPS for 3GPP access (GTP variants) Figure 21

Roaming architecture for 3GPP access (GTP-based) - home routed Gx

Rx PCRF

HSS

PDN Gateway

SGi


HPLMN VPLMN

3GPP Access

SGSN

2G/3G

S3 S6a

S1-MME MME S11 S10 E-UTRAN

S1-U

Issue: 04

S12 S4 Serving Gateway

S8

DN0991589

41



Figure 22

Roaming architecture for 3GPP access (GTP-based) - local breakout with home operator’s application functions only Rx HSS

HomeOperator's IP Services

hPCRF

HPLMN VPLMN

S9 3GPP Access

SGSN

2G/3G

vPCRF

S3 S6a

S1-MME MME S11

S12

S10

Serving Gateway

E-UTRAN

S1-U

Figure 23

Gx

S4

S5 GTP

PDN Gateway

VisitedOperator PDN

SGi

Roaming architecture for 3GPP access (GTP-based) - local breakout with visited operator’s application functions only hPCRF

HSS

HPLMN VPLMN

S9 3GPP Access

SGSN

2G/3G

vPCRF

S3 S6a

S1-MME MME S11 S10 E-UTRAN

S1-U

42

S12

Gx

Rx

S4 Serving Gateway

S5 GTP

DN0991589

PDN Gateway

SGi

Visited Operator'sIP Services

Issue: 04



2.4.6 Roaming architectures for EPS for non-3GPP access Figure 24

Roaming architecture for EPS using S8, S2a, S2b - home routed HSS

S6a

SWx Operator's IP Services (forexampleIMS, PSSand soon)

Rx hPCRF

Gx

SGi S8

PDN Gateway

HPLMN

3GPP Access

Serving Gateway

S9

S6b

3GPP AAA Server

Gxc vPCRF

S2b

SWd

Gxb

SWm ePDG

3GPP AAA PROXY

S2a VPLMN Non-3GPP Networks

Gxa

STa

SWn


Figure 25


SWa

Roaming architecture for EPS using PMIP-based S8, S2a, S2b (chained PMIP-based S8-S2a/b) - home routed HSS

S6a


Rx hPCRF

Gx

SGi PDN Gateway

S8

HPLMN

S9

S6b

3GPP AAA Server

Gxc vPCRF

SWd

Gxb 3GPP Access

Serving Gateway

SWm

S2b ePDG

3GPP AAA PROXY

VPLMN Non-3GPP Networks

S2a-PMIP

Gxa Trusted Non-3GPP IP Access

g

STa

SWn Untrusted Non-3GPP IP Access

SWa

Chained S2a/S2b and S8 are used when VPLMN has business relationship with Non-3GPP Networks and S-GW in VPLMN includes local non-3GPP Anchor. The following are some additional considerations for the use of Gxc: •

Issue: 04

Gxc is used only in the case of PMIP-based S8 and for 3GPP access.

DN0991589

43



•

Gxc is not required for Trusted Non-3GPP IP Access; Gxa is used instead to signal the QoS policy and event reporting.

Figure 26

Roaming architecture for EPS using S8, S2c - home routed HSS

S6a


Rx hPCRF

Gx

SGi PDN Gateway

S8

HPLMN

3GPP Access

S9

3GPP AAA Server

S6b

Gxc

Serving Gateway

vPCRF

SWd

Gxb

SWm

S2c

3GPP AAA PROXY

ePDG


Gxa

STa

SWn



SWa

S2c S2c

UE

44

DN0991589

Issue: 04


Figure 27


Roaming architecture for EPS using S5, S2c - local breakout HSS

S6a


Rx hPCRF

S9

3GPP AAA Server

HPLMN

Rx Gxc

vPCRF

SGi

3GPP Serving Access Gateway

S5

PDN Gateway

S2c

SWd

S6b

Gxb Gxa

VisitednetworkIP servicesorproxies tohomenetwork servicesorPDN

SWm 3GPP AAA PROXY

ePDG

S2c

SWn


S2c



UE

g

SWa STa

The two Rx instances in Figure 26: Roaming architecture for EPS using S8, S2c - home routed and Figure 27: Roaming architecture for EPS using S5, S2c - local breakout apply to different application functions in the HPLMN and VPLMN.

2.5 Reference points The EPS reference points as specified in [TS36.300], [TS23.401] and [TS23.402] include:

Issue: 04

S1-MME

Control plane reference point between E-UTRAN and MME

S1-U

User plane reference point between E-UTRAN and the SGW

X2

Control and user plane reference point between two EUTRAN nodes

DN0991589

45


46


S2

Group of reference points between P-GW and non-3GPP access network (for example, WLAN, cdma2000), used for control and mobility support for non-3GPP access interworking

S3

Reference point between MME and SGSN, used for user and bearer information exchange for inter-3GPP access network mobility

Gn

Reference point between pre-release 8 SGSN and MME/P-GW

Gp

Reference point between pre-release 8 SGSN and P-GW in roaming scenario

S4

Reference point between S-GW and release 8 SGSN, used for U plane tunnelling and related mobility support as S GW is anchor point for 3GPP handover

S5

Reference point between S-GW and P-GW but not crossing a PLMN boundary, used for U plane tunneling and tunnel management and for S-GW relocation. S5 includes both GTP and IETF variants

S6a

Reference point between MME and HSS, used for transfer of subscription and authentication data

S6b

Reference point between P-GW and 3GPP AAA Server/proxy for mobility related authentication and retrieval of mobility/QoS related parameters

Gx

Reference point between P-GW and the PCRF, used to transfer QoS policy and charging rules: Note that Gxc is reference point between S-GW and PCRF to transfer QoS policy and charging rules, if IETF variant is used for S5/S8

S8

Roaming reference point between S-GW and P-GW across a PLMN boundary, used for U-plane tunneling and tunnel management and S-GW relocation; similar to S5

S9

Reference point between the vPCRF and the hPCRF, used to transfer QoS policy and charging rules; similar to S7

S10

Reference point between MMEs, used for information transfer for example during MME relocation

S11

Reference point between MME and S-GW, used for control information such as EPS bearer management

S12

Reference point between S-GW and the UTRAN, used for U-plane tunnelling when Direct Tunnel is established

S13

Reference point between MME and EIR to enable UE identity check

DN0991589

Issue: 04


g


SGi

Reference point between P-GW and PDN, based on the UMTS Gi

STa

Reference point between trusted non-3GPP access and 3GPP AAA Server/Proxy to carry out AAA procedures

SWa

Reference point between untrusted non-3GPP access and 3GPP AAA Server/Proxy to carry out AAA procedures

SWd

Reference point between 3GPP AAA Server and 3GPP AAA Proxy

SWx

Reference point between 3GPP AAA Server and HSS for transfer of authentication data

Rx

Reference point between PCRF and AF in the PDN, based on the Rx interface of UMTS

There are several variants of the S2 reference point. The S2a is for trusted non3GPP access networks and the S2b is for un-trusted ones. The S2c extends to the UE for both types of access network. There are also multiple variants of Gx reference point. Gx is used for transfer of policy and charging information from PCRF to P-GW. Gxa is used for transfer of policy and charging information from PCRF to trusted non-3GPP access. Gxc is used for transfer of policy and charging information from PCRF to S-GW in case IETF variant of S5/S8 is used. There are 3GPP (GTP) and IETF (PMIP) variants of the S5 and S8 reference points. The protocol used over the S1-U is GTP-U. The protocols used over the S3, S4, S5 reference points are based on GTP. The protocol used over the S5-PMIP reference point is based on Proxy Mobile IP version 6 (PMIPv6). For details about the corresponding interfaces see LTE/EPC Interfaces.

2.6 LTE/SAE interfaces Figure 28: EPS architecture shows 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.

Issue: 04

DN0991589

47



Figure 28

EPS architecture

LTE_Uu

S1

S5/S8a

EUTRAN

EPC S1-U S1-MME

MME

eNB S11 X2

S10 S11

S-GW S1-MME

eNB

P-GW

MME

S1-U

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

2.6.1 Radio network interfaces 2.6.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 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) and LTE Time Division Duplex (TDD) services. Section Protocol stacks describes the Uu interface protocol stack.

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

48

DN0991589

Issue: 04


•

•

•

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 idleto-active 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 is triggered by the MME and requires 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 –

–

•

–

–

•

• • • • • •

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.

Mobility functions for UEs in LTE_Active –

•


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. The 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 CDMA2000 systems.

Paging function supports the sending of paging requests to the eNBs having one or more cells which correspond to one of the TAs in which the UE is registered. Roaming and area restriction support functions The S1 interface supports the transfer of restriction information from the EPC to the eNB in terms of restricted Tracking Areas 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 of various events related to the UE and its activities. This is an O&M functionality RAN Information Management function

Section Protocol stacks describes the Uu interface protocol stack.

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

Issue: 04

DN0991589

49



• • •

Inter-connection of eNBs supplied by different manufacturers Support of continuation between eNBs of the E-UTRAN services offered via the S1interface Separation of X2 interface radio network functionality and 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 UE in LTE_ACTIVE allows the eNB to hand over the control of a certain UE to another eNB. –

–

–

• •

Load management allows exchanging overload and traffic load information between eNBs, such that the eNBs can control the traffic load appropriately. 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 so that interference is mitigated. –

–

•

•

•

Context transfer from source eNB to target eNB allows transferring information required to maintain the E-UTRAN services for an UE in LTE_ACTIVE from source to target eNB. Control of user plane tunnels between source eNB and target eNB allows establishing and releasing tunnels between source and target eNB to allow for 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.

Uplink interference load management allows indicating an uplink interference overload and resource blocks especially sensitive to inter-cell interference between neighboring eNBs, such 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 for managing of signaling associations between eNBs, surveying X2 interface and recovering from errors. Error indication allows the reporting of general error situations on application level. 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 handover, attached to 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.

Section Protocol stacks describes the Uu interface protocol stack.

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

50

DN0991589

Issue: 04


• • •


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.7 Protocol stacks This section describes the protocol stacks for the control and user plane of the most important reference points of the LTE/EPC system.

2.7.1 Radio protocol architecture Uu user plane protocol stack Figure 29

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 transport of data between UE and eNB over the LTE-Uu interface using the PDCP protocol (see Figure 29: 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 30: U-plane operation of PDCP and RLC illustrates the processing performed on packets within PDCP and RLC.

Issue: 04

DN0991589

51



Figure 30

U-plane operation of PDCP and RLC

UE/E-UTRAN

RadioInterface(Uu)

Transmitting PDCP entity PDCP

E-UTRAN/UE

Receiving PDCP entity Sequencenumbering

PDCP

Inorderdeliveryandduplicatedetection

HeaderCompression(u-planeonly)

HeaderDecompression(u-planeonly)

U-PlaneSecurity

U-PlaneSecurity

Ciphering

Deciphering

AddPDCP header Transmitting RLCentity

RLC

SAP

RemovePDCP header Receiving RLCentity

RLC

TransmissionBuffer

SDUreassembly

SegmentationandConcatenation

RemoveRLCheader

AddRLCheader

ReceptionbufferandHARQreordering

ToMACLayer

52

SAP

FromMACLayer

DN0991589

Issue: 04


Figure 31


U-plane operation of PDCP and RLC To/From S1-U Data

PDCP

Header

Header Compression (RoHC) Data

Header

U-Plane Security Encrypted Data with Compressed Header PDCP Packet Reordering RLCSDU(Encrypted Data with Compressed Header &PDCP SN)

RLC

Segmentation and Re-assembly

RLC PDU RLC PDU

RANPacketRe-ordering

RLC PDU

Outer Assured Delivery To/From MACLayer

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

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

The RLC layer is responsible for: •

• •

Issue: 04

segmentation and re-assembly of RLC SDUs into RLC PDUs whose size match the block size used by the physical radio layer. This may involve the concatenation of small RLC SDUs into larger blocks. RAN Packet Reordering of packets that are received out of sequence so that RLC PDUs are concatenated in the correct order before delivering the SDU to PDCP. Outer Assured Delivery, which provides a high level of confidence that RLC PDUs have been successfully delivered to the receiver.

DN0991589

53



The S1-U Bearer is used for transport of user data between eNB and S-GW over the S1-U using GTP-U protocol (see Figure 29: Uu user plane protocol stack). Each S1Bearer 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 32

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 the transfer of signaling information between the eNB and UE. It consists of common “cell wide” broadcast information and dedicated signaling specific to an individual UE. It is used for: • • • • • • • • •

54

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

DN0991589

Issue: 04


Figure 33


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 33: 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 30: 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 avoid network congestion in case of S1-MME link overload. If an MME is in 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: 04

DN0991589

55



• • • • • • • • •

QoS Bearer Management (Activation, Modification, and Deactivation of EPS Bearers) 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.7.2 EPS protocol architecture S1-U user plane protocol stack Figure 34

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 35

X2 user plane protocol stack

eNB

eNB

GTP-U

GTP-U

UDP

UDP

IP

IP

L1/L2

L1/L2 X2

56

DN0991589

Issue: 04



From a U-plane perspective, the X2 interface is used for forwarding user data between the source eNB and target eNB during lossless inter-eNB handover. A GTP-U tunnel is established across the X2 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 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 was 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 36

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 37

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 38

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

Issue: 04

S1-MME

DN0991589

57



X2 control plane protocol stack Figure 39

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 IPSec tunnel mode. For QoS provision in 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 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 X2 link re-establishment when application-level configuration information transmitted during the establishment of X2 link has changed.

S5/S8 control plane protocol stack (GTP variant) Figure 40

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 41

S5/S8 control plane protocol stack (IETF variant)

S-GW

P-GW

PMIPv6

PMIPv6

IPv4/IPv6

IPv4/IPv6

L1/L2

L1/L2 S5/S8

58

DN0991589

Issue: 04



S10 control plane protocol stack Figure 42

S10 control plane protocol stack

MME

MME

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S10



S-GW

MME

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S11

S6a control plane protocol stack Figure 44

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

Issue: 04

DN0991589

59



SBc control plane protocol stack Figure 46

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

SBc

2.7.3 Protocol architecture for interfaces for legacy 3GPP interworking S4 user plane protocol stack Figure 47

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 48

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

60

DN0991589

Issue: 04





S-GW

SGSN

GTP-C

GTP-C

UDP

UDP

IP

IP

L1/L2

L1/L2 S4

2.8 LTE multiple access radio interface (TDD) 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 FDD and TDD modes, each with their own frame structures. In an FDD system, uplink and downlink are separated in frequency: there are different frequency bands allocated to uplink and downlink. In a TDD system, uplink and downlink are done on the same frequency band but separated in time: there are time slots allocated to uplink and downlink transmission on the air interface. This separation is done on the level of the subframes of the radio frame. As in FDD, the radio frame (10 ms duration) is divided into 10 subframes of 1 ms each. Table 3: Subframe configurations in TDD (examples) shows a range of frame structures that are possible in LTE TDD. Not all of these are supported in the current release. In RL15TD release only configuration 1 and configuration 2 are supported. Within a radio frame, the direction (UL/DL) can change once (configurations 3, 4, 5) or twice (configurations 0, 1, 2, 6). DL and UL periods are separated by a subframe (S) which is not used and provides a guard window to ensure that UL transmission from a UE does not interfere with DL transmission from the eNB. Table 3

Subframe configurations in TDD (examples)

UL/DL configuration

Switch-point periodicity

Subframe number

0

1

2

3

4

5

6

7

8

9

Configuration 0

5 ms

DL

S

UL

UL

UL

DL

S

UL

UL

UL

Configuration 1

5 ms

DL

S

UL

UL

DL

DL

S

UL

UL

DL

Configuration 2

5 ms

DL

S

UL

DL

DL

DL

S

UL

DL

DL

Configuration 3

10 ms

DL

S

UL

UL

UL

DL

DL

DL

DL

DL

Configuration 4

10 ms

DL

S

UL

UL

DL

DL

DL

DL

DL

DL

Issue: 04

DN0991589

61


Table 3


Subframe configurations in TDD (examples) (Cont.)

UL/DL configuration

Switch-point periodicity

Subframe number

0

1

2

3

4

5

6

7

8

9

Configuration 5

10 ms

DL

S

UL

DL

DL

DL

DL

DL

DL

DL

Configuration 6

10 ms

DL

S

UL

UL

UL

DL

S

UL

UL

DL

A chosen TDD frame configuration must be applied to the whole TDD network as far as coverage areas of the eNBs touch or overlap. All eNBs of this network then need to operate in +/-1.5 µs phase synchronized mode, on top of frequency synchronized mode required by the FDD system. These requirements can only be achieved by GPS-based synchronization. All eNBs of this network then need to operate in +/-1.5 µs phase synchronized mode, on top of frequency synchronized mode required by the FDD system. These requirements can be achieved by GPS based synchronization or Timing over Packet with Phase Sync.

2.8.1 Differences between TDD and FDD The different physical layer between TDD and FDD system affects O&M and both the UEs and eNBs. Towards the Core Network, the FDD-TDD differences are not visible. The subframes for DL and UL are defined mostly identical to the subframes in FDD mode. As exceptions, there are additional RACH modes (format #4) and it is possible to have more than one (up to six) PRACH per UL subframe. As 3GPP LTE standards attempt to keep FDD and TDD modes aligned, differences on higher layers (such as RRC) are mainly consequences of this modification in the physical layer. Schedulers need to take the different transmission and reception patterns into account and need to adapt to different time behavior. In consequence, the number of HARQ processes may differ depending on scenario and configuration, as well as the variance and the value of round trip time (RTT). This also entails more loose HARQ RTT latency requirements. Small additional options such as ACK/NACK bundling allow to counteract the different timing behavior in TDD mode, to avoid excessive delays. These differences in the physical operation lead to differences in the Control plane and O&M which need to support different configuration parameters and performance management counters. Owing to the reciprocal nature of the channel, TDD has distinctive advantages when deploying the Beam Forming feature. Beam Forming can boost spectrum efficiency, in particular at the cell edge. In general, system capacity and performance in TDD exhibit lower values than in FDD, as a consequence of sharing a single (maximum) 20 MHz band for uplink and downlink operation. An advantage of TDD over FDD is that FDD can adapt to permanent (or longduration) asymmetric UL/DL traffic demands by choosing UL /DL configuration modes with asymmetric capacity allocation for UL and DL.

62

DN0991589

Issue: 04



2.8.2 Beamforming Beamforming (BF) is a new technique in LTE, and is first introduced in the RL15TD release. A typical deployment will use a 4+4 cross-polarized directional antenna for each sector. BF is very demanding with respect to physical layer processing capacity. The radiation pattern of an antenna array is obtained as the product of the radiation pattern of the antenna elements, times the pattern of the whole group. The resulting radiation pattern can further be modified by multiplying the antenna input signals with antenna-specific weighting factors. These weights are calculated as a vector with one element per antenna. Each UE requires its own weight vector. The vector depends on the UE’s location in the cell and further wave propagation conditions. It is calculated from the Sounding Reference Signal (SRS) uplink transmission, where the co-variance between the RX antenna signals is observed. Figure 51: Calculation of antenna weights for beam forming illustrates the process of calculating the antenna weights. Figure 51

Calculation of antenna weights for beam forming DL-PHY

DRSinsertion

UE-1 TB fromMAC DL-Scheduling& Link Adaptation

UE-N TB fromMAC

Scrambler, FEC/RM, Interleaver, Modulation

Resource Mapping

Scrambler, FEC/RM, Interleaver, Modulation

Resource Mapping

BFvectors forUE-1

Storemost recent updatesof BFvectors

UE-1 symbol

Tx Ant#1 IFFT

UE-1 symbol

Beam Weights Application

Tx Ant#T IFFT

UL channelestimate UE-1(8x1)perRB

SRSReceiverUE-1 Beamweights computation BFvectors persubband UL channelestimate forUE-N foreachUE UE-N(8x1)perRB SRSReceiverUE-N

MAC

CPT

CPT

SRSUE-1

SRSUE-N

UL-PHY

Calculating the downlink (TX) vector from RX data is based on the assumption of reciprocity between downlink and uplink, that is, the assumption that measurements derived from one signal direction yield valid results for the other. Since wave propagation and multipath conditions are frequency-dependent, this assumption is much more justified in a TDD system which, in contrast to FDD, uses the same frequency for uplink and downlink. Common channels are handled in the “conventional” way, that is, without beam forming: they are radiated to the whole sector using the “sector beam”.

Issue: 04

DN0991589

63



Only dedicated communication towards a BF-capable UE is carried out in BF mode. UEs which support BF process the dedicated reference symbols (DRS) transmitted from the eNB, and provide the sounding reference signal (SRS) in uplink. Non-BF-capable UEs are served through the sector beam. The Flexible Sounding Configuration functionality allows customers flexible configuring the sounding bandwidth under different scenarios to optimize the beamforming performance. The benefits of Beam Forming are bought at the expense of higher effort in various areas of the system, such as: higher number of antennas, precise calibration needs, more antenna carriers to proceed, user specific reference signals, Beam Forming special precoding in downlink, Eigen Value calculation, and Direction-Of-Arrival (DOA) estimation.

2.9 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 FDD and TDD modes, 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 4: Benefits of OFDMA and SC-FDMA. Table 4

Benefits of OFDMA and SC-FDMA

Downlink: OFDMA

Uplink: SC-FDMA

•

improved spectral efficiency

•

reduced interference

•

very well suited for MIMO

•

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 52: 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 most obvious difference between the two schemes is that, the 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.

64

DN0991589

Issue: 04


Figure 52 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 nt ac pe 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 DatasymbolsoccupyM*15kHzfor 1/MSC-FDMA symbolperiods

Datasymbolsoccupy15kHzfor oneOFDMA symbolperiod

Signal generation and reception OFDMA and SC-FDMA partly share the same signal generation and reception steps. Different to OFDMA, SC-FDMA begins with a special pre-coding process from the time domain to the frequency domain but then continues in a manner similar to OFDMA, as illustrated in Figure 53: 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 CP (Cyclic Prefix) is inserted to provide fundamental robustness of OFDMA against the multipath. Figure 53

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

Issue: 04

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.

DN0991589

65



• •

•

Inter-cell interference coordination and interference cancellation enable exploiting multi antenna configurations. For details see Interference mitigation. The frequency-selective Packet Scheduler (PS) is channel-aware and dynamically allocates to the UE a certain number of PRBs in accordance to QoS criteria. 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.9.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 (note that 1.4 MHz and 3 MHz carrier bandwidth will be supported in future release).LTE (for TDD) supports carrier bandwidths of 10 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.

66

DN0991589

Issue: 04


Figure 54


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.9.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 55: 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.

Issue: 04

DN0991589

67



Figure 55

OFDM and OFDMA subcarrier allocation Subcarriers

Subcarriers

User2 User3

OFDM

Symbols(Time)

Symbols(Time)

User1

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.9.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 56: 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 56

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

68

DN0991589

Issue: 04



2.10 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 and Hybrid-ARQ information. It also contains the Uplink scheduling grant. Physical downlink shared channel (PDSCH) Carries the Downlink shared channel (DL-SCH) and the Paging Channel (PCH). Physical hybrid ARQ indicator channel (PHICH) Carries Hybrid ARQ ACK/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 57: Mapping of physical, transport and logical channels.

Issue: 04

DN0991589

69



Figure 57

Mapping of physical, transport and logical channels

DL LogicalChannel

BCCH CCCH DTCH

DL TransportChannel

BCH

DL PhysicalChannel

DL-SCH

PACH

DCCH

PCH

PDSCH

UL LogicalChannel

PCCH

DTCH

UL TransportChannel

RACH

UL-SCH

UL PhysicalChannel

PRACH

PUSCH

PDCCH

DCCH

PCFICH

PHICH

CCCH

PUCCH

For more information see LTE/EPC interfaces.

2.11 Multi-antenna techniques 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 5: Multiantenna options in LTE gives an overview on the typical LTE multi antenna configurations. Table 5

Multi-antenna options in LTE

DL

UL

BS

UE

TX

RX

1x2

1

2

2x2

2

2

Gain to smaller configuration

+ 4 ... 5 dB DL link budget

Configuration type

UE

BS


TX

RX

1x2

1

2

minimum

1x2

1

2

standard

+ 100% peak data rate + user experience

70

DN0991589

Issue: 04


Table 5


Multi-antenna options in LTE (Cont.)

DL

UL

BS

UE

TX

RX


Configuration type

UE

BS

TX

RX

1

4


+ 20% spectrum efficiency 4x2

4

2

+ 3 ... 4 dB DL link budget

1x4

+ 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

future

+ 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 event and dense RRH/RFM deployments.

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

Issue: 04

DN0991589

71



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.11.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.11.3 MIMO techniques The typical MIMO configuration encompassing Dual-Codeword 2x2 DL Single-User (SU) MIMO Spatial Multiplexing is illustrated in Figure 58: 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.

72

DN0991589

Issue: 04


Figure 58


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

Issue: 04

Downlink MIMO techniques Multi-user MIMO techniques

DN0991589

73


2.11.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.11.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. There is an implementation of the Uplink MU MIMO 8Rx in alignment with the four receive antenna configurations supported at the eNB. The uplink MU MIMO uses the two base station receive and four base station receive antennas depending on the actual antenna deployment. For evaluation purposes, a Proportional Fair scheduler and a frequency-selective MIMO scheduler have been compared, indicating various performance gains 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 UL MU MIMO 8Rx feature allows creation of a virtual UL MIMO by spatial multiplexing of UEs. The UL MIMO uses Txs of multiple UEs so that they can be seen as a virtual UE with 2Tx from the eNB's perspective. The mechanism is called UL MU MIMO because of the fact that multiple users are multiplexed. The UL MU MIMO is transparent for the UEs, that is, the UEs are not aware of UL multiplexing. The uplink multi-user MIMO functionality improves the spectral efficiency by up to 10~20%.

74

DN0991589

Issue: 04



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

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

Issue: 04

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.

DN0991589

75



•

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.13 Interference mitigation Interference mitigation for up to four receive antennas must be considered in LTE. In contrast to WCDMA or HSPA, however, intra-cell interference does not (or at least only in high mobility scenarios) occur in LTE. In 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 the 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 LTE1724 CL10: Centralized RAN 10 MHz feature description.

2.14 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: • • • • •

76

cell system module RF module parametrization NetAct

DN0991589

Issue: 04


• •


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

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)

Figure 59

Operator modules in RAN sharing RFFeederLine A +B

PLM

NA

,B

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

S1Operator A S1OperatorB

Issue: 04

DN0991589

77



Figure 60

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. The LTE4: RAN Sharing feature allows the configuration of multi-operator core network (MOCN) and multi-operator RAN (MORAN) sharing between up to six operators. The MOCN solution allows

2.15 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

78

DN0991589

Issue: 04



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

Issue: 04

DN0991589

79



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

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.15.2 Single RAN features The current shared Single RAN features are the following: • • • • • •

80

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)

DN0991589

Issue: 04



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.

Issue: 04

DN0991589

81

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 61: LTE/EPC network management architecture. Figure 61

LTE/EPC network management architecture

Management system traffic to and from LTE/EPC network elements always goes through NetAct. The LTE RAN Element Manager has its own direct interface. The interface between the Flexi Multiradio Base Station and NetAct is based on the BTSOM protocol. It carries all the necessary data and commands (for example, alarms, measurements, configuration and new software data) to control the network element behavior remotely. The interface between the Element Managers for MME and EPC-GW is based on the NES3/SNMP protocol. NetAct offers an open northbound interface for other management systems and provides advanced tools for full-scale management functionality (FCAPS). Textual and graphic presentation of measurement data reporting is based on 3GPP formats.

82

DN0991589

Issue: 04



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

DN0991589

83



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

84

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

DN0991589

Issue: 04


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 62: 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: 04

DN0991589

85

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 62

Mobility scenarios for LTE/EPC

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

86

DN0991589

Issue: 04


Figure 63

Mobility

Mobility anchor point

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

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 Inter-eNB handover Inter-eNB handovers are typically handovers that aim to minimize service interruption and packet loss. Based on measurements received from the UE, the source eNB selects a target eNB and initiates the handover. The signaling takes place over the X2 interface. If there is no X2 connectivity between the base stations, the signaling must take place via the MME and via the S1-MME interface. These two alternatives are illustrated in Figure 64: Inter-eNB handover with X2 interface and Figure 65: Inter-eNB handover without X2 interface.

Issue: 04

DN0991589

87

Mobility


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 avoids packet bicasting. Figure 64

Inter-eNB handover with X2 interface

Figure 65: 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.

88

DN0991589

Issue: 04


Figure 65

Mobility

Inter-eNB handover without X2 interface

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

Issue: 04

DN0991589

89

Mobility


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 66: 3GPP inter-RAT mobility. Figure 66

3GPP inter-RAT mobility

Inter access mobility can be build introducing overlay to existing Packet Core elements via Gn interfaces. The benefit is that there is no need to change the existing 2G/3G live deployment when introducing LTE. 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: • •

90

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

DN0991589

Issue: 04


Mobility

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

Issue: 04

DN0991589

91

Mobility


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 67: 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. Figure 67

Architecture for optimized LTE-HRPD mobility

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

92

DN0991589

Issue: 04


Mobility

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 and 20 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 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.7 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.8 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 68: 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

Issue: 04

DN0991589

93

Mobility


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

Roaming scenario with home routed traffic

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

94

DN0991589

Issue: 04


Figure 69

Mobility

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

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

Issue: 04

DN0991589

95

Mobility


Figure 70

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

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.

4.9 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: • •

96

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

DN0991589

Issue: 04


Mobility

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

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 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 the end-user initiates an emergency call, he can be easily located.

1) 2)

Issue: 04

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

DN0991589

97

Mobility


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.

98

DN0991589

Issue: 04


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 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 8: Scope of RRM functions. Table 8

Issue: 04

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

DN0991589

99


Table 8


Scope of RRM functions (Cont.)

System Aspect

L3+ RRM functions

L1/L2 functions

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.

100

DN0991589

Issue: 04



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 packed 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: 04

DN0991589

101



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 LTE2210: Intra-frequency Load Balancing Extensions feature enhances the LTE1140: Intra-frequency Load Balancing feature by proving operator-controlled option for deltaCIO being set to zero during certain scenarios for inter-operability with other vendors' eNBs. It also handles interactions between enhanced inter-cell interference coordination (eICIC) and Mobility Load Balancing (MLB). 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. Dynamic HO threshold change is introduced in a later release. The LTE1113: eICIC - macro and LTE1496: eICIC - micro features support the eICIC between macro and micro (FZM) cells. The Radio Configuration (RC) function configures global parameters in the cell that provide information necessary for idle and active mode mobility by defining pools of resources available for dynamic allocations. RC enables operators to set up their network in a consistent manner, providing global strategies and policies to be applied in a more dynamic manner to RRM algorithms. In this way, operators can achieve dynamic capacity and coverage control of the cells according to traffic demands. The Inter-RAT RRM (IRR) function aids the management of resources during inter-RAT handover. Handover decisions may take into account UE capabilities, operator policies, availability of resources, and traffic load condition in the target system. Load balancing functions may also use IRR to obtain information, enabling them to redistribute users to other RATs. 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. UEs located at the cell edge often hit the maximum transmission power; nevertheless, because of poor radio conditions, the signal received by the eNB is getting worse. The LTE907: TTI Bundling feature allows transmitting the same transport block in four consecutive UL subframes, which leads to increased energy per transmitted bit and improved uplink link budget. The more robust transmission scheme leads to reduction of PDCCH traffic. 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

102

DN0991589

Issue: 04



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. The LTE1089: Downlink Carrier Aggregation - 20 MHz feature allows the operator to provide higher UE peak data rates by aggregation of two cells of 10 MHz each or of two cell of 5 MHz each (or 5 MHz + 10 MHz) in different bands. To use this bandwidth extension and to aggregate fragmented spectrum, the operator needs to enable and configure the feature in the sectors which support interband carrier aggregation. Only colocated cells which have antennas pointed to the same geographical area can be aggregated with this feature. For an eNB that has more than two cells at different frequencies per sector, the UEs can support downlink (DL) carrier aggregation (CA) in a multitude of two-cell combinations by means of the LTE 1562: Carrier aggregation for multi-carrier eNode Bs feature. However, the UE is still configured with only one SCell.

5.2 State transitions There are three sets of states defined for the UE based on the information held by the MME. These are: • • •

EPS Mobility Management (EMM) states EPS Connection Management (ECM) States 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 71: EMM state transitions. Figure 71

Issue: 04

EMM state transitions

DN0991589

103



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.

g

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 72: ECM state transitions. Figure 72

ECM state transitions

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

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

104

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.

DN0991589

Issue: 04



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

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

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

RRC state transitions

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

Issue: 04

DN0991589

105


Figure 74


Intra-RAT mobility in ECM_IDLE

ECM_CONNECTED Connection State In ECM_CONNECTED, the principal form of mobility management is backwards handover as illustrated in Figure 75: 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 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.

106

DN0991589

Issue: 04


Figure 75

Intra-RAT mobility in ECM_CONNECTED b)

eNB

source

Measurement Report

target

eNB

S-GW

source

eNB

UEcontext

a)


IntereNB Signaling overX2

S-GW target

c)

source

eNB

Handover Preparation

d)

eNB

eNB

source

S-GW DL packets forwarded overX2 target

S-GW Hardcover Complete

eNB target

BufferUL packetswhile detachingfrom sourceeNBand attachingto targeteNB

e)

eNB 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 76: Multiple-TA registration concept. Each cell belongs to a single tracking area (TA).

g

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.

Issue: 04

DN0991589

107



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 76: Multiple-TA registration concept.

108

DN0991589

Issue: 04


Figure 76


Multiple-TA registration concept

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.

Issue: 04

DN0991589

109



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.

110

DN0991589

Issue: 04



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

Issue: 04

DN0991589

111



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.

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 77: LTE/EPC service data flows illustrates the LTE/EPC service data flow in more detail. Figure 77

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 ↔ S5/S8a-TEID GTP-U

GTP-U

GTP-U

GTP-U

S-GW

eNB

UE Radio Bearers

S5/S8a TEID

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 78: 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 78: LTE/EPC EPS high level bearer model shows the EPS bearer services layered architecture.

112

DN0991589

Issue: 04


Figure 78


LTE/EPC EPS high level bearer model

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

Issue: 04

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

DN0991589

113


•

•


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 9: QoS scheme for LTE. Table 9

QoS scheme for LTE

3G (QoS aware)

LTE (Non-QoS aware)

Residual BER

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

114

DN0991589

Issue: 04


Table 9


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 10: Standard QCI characteristics shows some example standard QCI characteristics, identifying the possible packet delay budgets, packet loss rates, and appropriate services. Table 10

QCI

Resource Type

Priority

Packet Delay Budget

Packet Loss Rate

Example Services

1

GBR

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

5

Issue: 04

Standard QCI characteristics

Non-GBR

DN0991589

115


g


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.

5.8 Additional services The following additional services are valuable for the end-user experience. The following additional service is 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.

116

DN0991589

Issue: 04



Earthquake and Tsunami Warning System 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.

Issue: 04

DN0991589

117

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 transport addressing Traffic engineering Synchronization Transport admission control

6.1 LTE transport overview 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 79: Architecture of LTE transport below shows the SAE/LTE network architecture and the logical interfaces established in the transport layer. Figure 79

118

Architecture of LTE transport

DN0991589

Issue: 04



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 80: Transport Protocol Stack OverviewFigure 81: 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 80

Transport Protocol Stack Overview

Figure 81

Transport Protocol Stack Overview

Transport

S1_U

S1_MME

X2_U

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.

Issue: 04

DN0991589

119



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

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

120

define Primary Path (preferred) and Alternative Path (redundant) in the L2 network reroute traffic from failed path over working path (with switchover time tolerable for an end user

DN0991589

Issue: 04



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

Ethernet backhaul for LTE/EPC

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

Issue: 04

full-duplex transmission mode auto-negotiation and forced mode for the data rate MDI/MDIX VLAN tagging according to IEEE 802.1q

DN0991589

121


• • • •


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

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

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

122

local eNB topologies such as chains and trees at the periphery of the E-UTRAN, minimizing the number and length of transport links employed. 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.

DN0991589

Issue: 04


g


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 83: Example of EUTRAN transport topologies. Figure 83

Example of E-UTRAN transport topologies

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.

6.4 IP transport 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. Network configurations are based on the assumptions: • •

Issue: 04

each eNB application is using an own addresses separated core nodes

DN0991589

123


•


separated SEG and VLAN GW nodes

IP addressing in the eNB is based on two parts: addressing at the eNB side, and addressing external peer nodes from the eNB side. For more information, see Functional Area Description LTE Transport.

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 84: 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. Figure 84

124

QoS differentiation between user, control and management plane traffic

DN0991589

Issue: 04



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

Traffic prioritization on the Ethernet layer, using packet marking methods

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 86: 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: 04

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.

DN0991589

125


Figure 86


M-plane traffic differentiation using VLAN over Ethernet

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 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, TDD also requires phase synchronization accuracy at +/- 1.5 us. In a TDD system only synchronization from GPS is possible. In FDD mode, the Flexi Multiradio BTS LTE offers the configuration of several clock reference sources and a priority order among them. By means of the air interface synchronization, the eNB keeps the frequency accuracy and the phase accuracy of its air interface within the specified bounds. The eNB supports synchronization of the base station system clock (generated by an Oven Controlled Quartz Oscillator OXCO), to the reference signals. The eNB is able to recover the system clock from timing interfaces. The external synchronization source is Global Positioning System (GPS)/Pulse Per Second (PPS) external reference clock. With the feature LTE612: Synchronization Hub, an eNB can provide frequency and phase synchronized signal at the 1pps synchronization output. Synchronization source selection runs in two ways:

126

DN0991589

Issue: 04


•

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

•


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]

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

Synchronization in CRAN The CRAN supports synchronization by either GPS or Timing over Packet (ToP).

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 87: Synchronization from 2.048 MHz signal. Figure 87

Synchronization from 2.048 MHz signal

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.

Issue: 04

DN0991589

127



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 88: ToP based synchronization. ToP provides CAPEX and OPEX savings, as separate PDH links or GPS areGPS is 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 88

ToP based synchronization

The LTE891: Timing over Packet with phase synchronization feature is supported. This feature provides phase synchronization of BTS through the packet network based on IEEE 1588-2008. The Timing over Packet (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.

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.

128

DN0991589

Issue: 04



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.

g

In RL30 for admission control only one type of real time traffic is supported (QCI class 1).

g

In RL25TD for admission control only one type of real time traffic is supported (QCI class 1). 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. 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.

Issue: 04

DN0991589

129

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 89: LTE/EPC Operation and maintenance concept. Figure 89

130

LTE/EPC Operation and maintenance concept

DN0991589

Issue: 04


Operability

Flat operability architecture 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: –

Issue: 04

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

DN0991589

131

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

•

•

132

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:

DN0991589

Issue: 04


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 90: Functional overview of the BTS Site Manager, the application integrates Transmission and BTS Management into one site-level management tool. Figure 90

Functional overview of the BTS Site Manager

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:

Issue: 04

DN0991589

133

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

134

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

DN0991589

Issue: 04


Table 11

Operability

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. For more information on activation, deactivation and configuration of the CRAN, see the LTE1724 CL10: Centralized RAN 10 MHz 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: • • • • • • • •

Issue: 04

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

DN0991589

135

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.

136

DN0991589

Issue: 04


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

For more information, see Functional Area Description Software Management.

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 fast reporting for selected PM counters threshold-based PM alarming KPI calculations PM data transfer and supervision by NetAct PM counter licenses performance data file formats

For more information, see Functional Area Description Performance Management.

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

HW installation and configuration inventory management

For more information, see Functional Area Description Network Inventory.

Issue: 04

DN0991589

137

Operability


7.4.6 Feature/license management Using hardware capacity features and optional software features require licenses to be purchased. The RL20 release uses trust-base license control.License management is not supported in RL15, it will be supported in future releases.

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.

138

DN0991589

Issue: 04


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 DHCP server for BTS site equipment

7.5.1 GPS location retrieval The GPS module in the Flexi Multiradio BTS provides an interface to fetch geographical coordinates and, optionally, the UTC Time information. If a fixed mounted GPS module is available on site, the Flexi Multiradio BTS can be 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 to synchronize the BTS internal clocks (time of day, not intended to be used as frequency reference for oscillators) or used for example as time stamps in messages, alarms, notifications, trace records, and so on. The external GPS device is connected in a MDR26 connector which accepts NMEA 0183 data.

g

The configuration of time zone and Summer and Winter time can be derived via GPS and is done during site commissioning.

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.

Issue: 04

DN0991589

139

Operability


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

The configuration of time zone and Summer and Winter time is done 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.5.4 DHCP server for BTS site equipment An internal DHCP server enables a dynamic IP host configuration for IP devices connected to the Flexi Multiradio BTS subnet at the Flexi Multiradio BTS site. Devices like antenna tilt controllers or local management tools such as the BTSSM receive an IP configuration from the DHCP server located in the Flexi Transport Module (FTM). Along with the IP address, other network parameters are also given. The meaningful parameters are: Default gateway IP-address, lease time and subnet mask. The DHCP server in the FTM is configured with the Transport Element Manager (TRSEM) or with the site commissioning file during installation. DHCP functionality is supported according to [RFC2131] and [RFC2132]. Ports UDP #67 and #68 are reserved for DHCP. The DHCP lease time is one week. The DHCP lease is renewed before lease time ends.

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

140

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

DN0991589

Issue: 04


Operability

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

request external specific trace information to Flexi Multiradio BTS on demand 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:

Issue: 04

DN0991589

141

Operability


• • • • • •

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 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 91: Cell trace concept and Figure 92: Cell subscriber and equipment trace concept): •

•

•

142

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

DN0991589

Issue: 04


•

Operability

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

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 91: 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: • • • • •

Issue: 04

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)

DN0991589

143

Operability


• • •

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

g

trace reference 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)

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.

144

DN0991589

Issue: 04


Figure 91

7.6.2.2

Operability

Cell trace concept

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

Issue: 04

DN0991589

145

Operability


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

146

Cell subscriber and equipment trace concept

DN0991589

Issue: 04


Operability

7.7 Self Organizing Network support 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 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. 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 93: SON architecture) which includes: • •

• •

Issue: 04

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

DN0991589

147

Operability


Figure 93

SON architecture

The goals are to reduce 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 manufacturer, field service, and operator. For more information, see Functional Area Description SON Management.

148

DN0991589

Issue: 04


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 protect the confidentiality of the user data and to mitigate the effects of attacks on the network. The technology used brings together the best of mobile telephony and the best of the Internet, integrating them into a highly reliable and transparent service vehicle, but it also highlights the importance of security issues. 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: •

• • • •

Issue: 04

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.

DN0991589

149

Security


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. There are many ways to attack mobile network 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: •

•

•

150

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

DN0991589

Issue: 04


•

•

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

Issue: 04

DN0991589

151

Security


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

8.2 LTE/EPC M/C/U/S-plane security As specified by 3GPP (see Figure 94: LTE/EPC M/C/U/S-plane security) the LTE/EPC security architecture provides security for the M-, C-, U-plane. The protection of S-plane is not recommended

152

DN0991589

Issue: 04


Security

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). Figure 94 UE

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

S1-MME

eNB

MME

eNB

X2C

eNB

NASsignaling (cipheredandintegrityprotectedusingNASsignalingsecurity) C-plane

S1-AP signaling (cipheredandintegrityprotected withIPsec)

RRCsignaling (cipheredandintegrityprotected)

S1-U

U-plane

O&M

X2U

SAE-GW

U-planedata (cipheredandintegrityprotected withIPsec)

U-planedata (cipheredusingPDCP)

X2-AP signaling (cipheredandintegrityprotected withIPsec)

U-planedata packetsforwardedoverX2 (cipheredandintegrityprotected withIPsec)

EMS/ NMS

M-planedata (cipheredandintegrityprotected withIpsec& TLS)

M-plane

Figure 95 UE

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

S1-MME

eNB

MME

eNB

X2C

eNB

NASsignaling (cipheredandintegrityprotectedusingNASsignalingsecurity) C-plane RRCsignaling (cipheredandintegrityprotected)

S1-AP signaling (cipheredandintegrityprotected withIPsec)

S1-U

U-plane

U-planedata (cipheredusingPDCP)

U-planedata (cipheredandintegrityprotected withIPsec)

O&M M-plane

SAE-GW

X2-AP signaling (cipheredandintegrityprotected withIPsec)

X2U U-planedata packetsforwardedoverX2 (cipheredandintegrityprotected withIPsec)

EMS/ NMS

M-planedata (cipheredandintegrityprotected withIpsec& TLS)

ToP S-plane

Synch-packets(IEEE1588v2) (ciphered(optional)andintegrity protectedwithIpsec)

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.

Issue: 04

DN0991589

153

Security


Table 12: Security termination points summarizes the security termination points. Table 12

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

3)

154

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.

DN0991589

Issue: 04


Figure 96

Security

C-plane security architecture for LTE/EPC

UE

MME NASSignallingSecurity(authenticated,integrityprotectedandencrypted)

NAS

NAS

eNB RRC

C-PlaneSecurity (authenticated, integrityprotectedand encrypted)

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 97: U-plane security architecture for LTE/EPC comprises integrity protection and ciphering according to the following: • • • • •

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

Issue: 04

DN0991589

155

Security


Figure 97

U-plane security architecture for LTE/EPC

8.2.3 M-plane security M-plane security (see Figure 98: 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 98

M-plane security architecture for LTE/EPC

8.2.4 S-plane security The S-plane security (see Figure 99: S-plane security architecture for LTE/EPC) protects the timing packets transferred between ToP master and eNB (bi-directional). The timing packets include timestamps that are used for frequency and time/phase synchronization. Figure 99

S-plane security architecture for LTE/EPC

eNB

ToP Master

IEEE1588PTP v2

IEEE1588PTP v2 S1Interface NDS/IPsec (intregrityprotectedand encrypted(optional))

156

DN0991589

Issue: 04


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 “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 User Authentication and Authorization 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 are accessible BTS-externally. To access BTS you must know user ID and password. Open ports without any user ID and password protection can cause interception of User, Control and Management traffic. These feature protect against:

Issue: 04

DN0991589

157

Security


• • •

eavesdropping, interception or modification BTS internal traffic misuse BTS services like telnet, ftp, R&D services 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 User Authentication and Authorization Centralized User Authentication and Authorization (CUAA) 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 CUAA 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. The upload is triggered from NetAct. An XML file format is used for the log file. NetAct can also produce the data in the User Event Collection in the same XML format. The XML coding is made 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. The operator can collect user event data from all BTSs. With NetAct applications, the operator can create reports from the data collection, for example, reports based on the user or network element identity.

Secure file transfer for Flexi Multiradio BTS LTE The LTE150: OAM Transport Layer Security (TLS) Support feature enables protected transfer of the O&M data files between BTS and NetAct. O&M data files transmitted using secure file transfer feature are encrypted and integrity protected. Content of the transferred files cannot be eavesdropped or modified, for example, no man-in-the-middle attacks are possible. 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 secure 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

158

DN0991589

Issue: 04


Security

for file transfer, FTP is not supported. In a secure transport mode, HTTPS uses Transport Layer Security (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 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 and to encrypt sensitive data. 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 take 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: 04

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

DN0991589

159

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.

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 Secure eNB control and bulk data communication between the Flexi Multiradio BTS LTE and other eNBs and Core Nodes is enabled by using IPsec to secure transport and application protocols. With IPsec, there is also support for separation between different types of traffic, like control plane traffic and user plane traffic from management traffic, by dedicated transport tunnels. The security of Flexi Multiradio BTS LTE control, user,

160

DN0991589

Issue: 04


Security

synchronization and management plane interfaces is increased by providing encryption, integrity protection and communication peer authentication with IPsec according RFC 4301. It is possible to enable/disable IPSec per connection, for example, per neighbor eNB, or per core security gateway, and to configure each connection independently in terms of security settings for each remote IPsec peer. The supported IPsec capabilities follow 3GPP'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 13: IPsec capabilities summarizes the supported IPsec capabilities: Table 13

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.

Issue: 04

DN0991589

161

Security


g

If some other external transport technology is in use providing also authentication and encryption end-to-end between the Flexi Multiradio BTS LTE and other sites, the IPsec based ciphering feature in LTE may be disabled, since ciphering twice does not create additional security but 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 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: • •

162

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.

DN0991589

Issue: 04


Security

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.

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 and ciphering but may be also used for the verification of SW loads, configuration data and license validity. The Certificate Management functionality is needed for enrollments, update, and revocation of operator certificates when public 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.

Issue: 04

DN0991589

163

Security


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

164

DN0991589

Issue: 04


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 100: Layered security association structure of the LTE/EPC. Figure 100

Layered security association structure of the LTE/EPC AUC

USIM Root Key

Root Key

HSS/AAA

UE CK,IK

CK,IK

Subscriber Authentication/Authorization(AKA) MME NASKeys

NASKeys

AK_ASME

NASSecurity Association eNB ASKeys

ASKeys

Oneway key derivations

UP Security Association UP Keys

UP Keys

UP Security Association

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 101: LTE/EPC AKA procedure. For more information see also section LTE/EPC overall key hierarchy concept.

Issue: 04

DN0991589

165

AAA and charging


Figure 101

LTE/EPC AKA procedure

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

Retrieval of LTE authorization information

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 access and transport information for cost calculation. Depending on charging filter rules,

166

DN0991589

Issue: 04


AAA and charging

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 103: EPC charging - 3GPP access - non roaming, Figure 104: EPC charging - 3GPP access - roaming, home routed traffic, and Figure 105: 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 103

EPC charging - 3GPP access - non roaming UTRAN SGSN

GERAN S3

HSS PCRF S6a

S1-MME MME

S4

S11

UE

Rx+

S7

S10 PCEF E-UTRAN LTE-Uu

S-GW S1-U

S5

P-GW Gz

CGF

Issue: 04

DN0991589

SGi

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

Gy

OCS

167

AAA and charging


Figure 104

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

S7

PCEF

P-GW

SGi

Gz


Gy

HSS

CGF

OCS

S6a

HPLMN

VPLMN UTRAN SGSN GERAN

G8a S3

S1-MME MME S4

S11

UE

S10 E-UTRAN

S-GW

CGF

S1-U

LTE-Uu

Ga Maygenerate bearerlevelinter-operator charging

Figure 105

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

HPLMN

Gy

S6a

VPLMN UTRAN SGSN GERAN

CGF S3

PCRF

S1-MME

Gz

MME S4

S11

UE

Rx+

S7

S10 PCEF E-UTRAN LTE-Uu

S-GW S1-U

S5

P-GW

SGi


Charging mechanisms There are two charging mechanisms employed by ePACS:

168

DN0991589

Issue: 04


• •

AAA and charging

Offline charging is applied to users who pay for their services periodically (for example, pay-monthly customers). 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 104: 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 105: 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: 04

DN0991589

169

Migration to LTE VoIP


10 Migration to LTE VoIP 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 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 106: 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 106

LTE/EPC architecture with PS & CS domains completely separated

2. Fallback to CS voice At this phase the LTE network is still used for data only (see Figure 107: 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. For more information refer to the following feature descriptions:

170

DN0991589

Issue: 04


• • • • • • •


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)

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

LTE/EPC architecture CS fallback

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 109: LTE/EPC SRVCC architecture for 3GPP accesses). However, as shown in Figure 108: 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). This procedure is not supported yet and is planned for future release. Features LTE872: SRVCC to WCDMA and LTE873: SRVCC to GSM support this functionality. Figure 108

Issue: 04

Single radio voice call continuity (SRVCC) principle

DN0991589

171



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 110: 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 109

LTE/EPC SRVCC architecture for 3GPP accesses

Figure 110

LTE/EPC SRVCC architecture for 1xRTT

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

172

DN0991589

Issue: 04



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 IMS is used as enabling SIP session control machinery for VoIP traffic (see Figure 111: 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 111

LTE/EPC architecture with all-IP network deploying LTE

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

DN0991589

173



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.

174

DN0991589

Issue: 04


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

Issue: 04

DN0991589

175

Nokia service solutions – key benefits and customer values


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

176

DN0991589

Issue: 04


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.

Issue: 04

DN0991589

177



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

178

DN0991589

Issue: 04



Product collection and disposal within European Union, WEEE directive 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: 04

DN0991589

179

Lte Ran and Epc System

Recommend Documents