fd rl40 desc

8/18/2019 Fd Rl40 Desc

http://slidepdf.com/reader/full/fd-rl40-desc 1/276

LTE Radio Access, Rel. FDD-LTE 15A, OperatingDocumentation, Issue 02,Documentation ChangeDelivery 2

LTE RL40, FeatureDescriptions and Instructions

DN09185979

Issue 01J

Approval Date 2015-12-16

Nokia Networks

8/18/2019 Fd Rl40 Desc


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 rightto 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 OFERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia Solutions and Networks’ proprietary and confidential information, which may not be

distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and

Networks.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document

may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © 2016 Nokia Solutions and Networks. All rights reserved.

f Important Notice on Product Safety This product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this

product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and

Environmental Information” part of this document or documentation set.

Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects of its

products and services. We would like to encourage you as our customers and users to join us in working

towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations

for power use and proper disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we

offer, please contact us at Nokia Solutions and Networks for any additional information.

LTE RL40, Feature Descriptions and Instructions

2 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table of Contents

This document has 276 pages

Summary of changes................................................................... 20

1 RL40 Features - not supported by Flexi Zone Micro....................21

2 Activating LTE RL40 Features......................................................22

2 Summary of changes................................................................... 22

2.1 Activating and deactivating LTE features using BTS Site Manager.22

2.2 LTE46: Channel Aware Scheduler (UL)....................................... 23

2.3 LTE48: Support of High Speed User s.......................................... 25

2.3.1 Activating LTE48: Support of High Speed Users..........................252.3.1.1 Steps............................................................................................ 26

2.3.2 Deactivating LTE48: Support of High Speed Users..................... 27

2.3.2.1 Steps............................................................................................ 27

2.4 LTE494: Commercial Mobile Alert System...................................27

2.5 LTE495: OTDOA..........................................................................29

2.6 LTE496: Support of QCI 2, 3 and 4; LTE497: Smart AdmissionControl; LTE534: ARP Based Admission Control.........................31

2.7 LTE519: E-RAB Modification........................................................33

2.8 LTE587: Multiple GBR EPS Bearers per UE................................34

2.9 LTE612: Synchronization Hub using BTS Site Manager..............36

2.10 LTE736: CS Fallback to UTRAN..................................................39

2.11 LTE843: ETWS broadcast............................................................40

2.12 LTE872: SRVCC to WCDMA....................................................... 42

2.13 LTE873: SRVCC to GSM............................................................. 45

2.14 LTE979: IRC for 2 RX paths.........................................................48

2.15 LTE984: GSM redirect with system information........................... 49

2.16 LTE1387: Intra eNodeB inter-frequency LB................................. 52

3 Descriptions of radio resource management and telecom features.54

3.1 LTE46: Channel Aware Scheduler (UL)....................................... 54

3.1.1 Benefits........................................................................................ 54

3.1.2 Requirements...............................................................................54

3.1.3 Functional description.................................................................. 54

3.1.4 System impact..............................................................................55

3.1.5 Management data........................................................................ 56

3.1.6 Sales information......................................................................... 57

3.2 Description of LTE48: Support of high speed users.....................57

3.2.1 Benefits........................................................................................ 57

3.2.2 Requirements...............................................................................57


3.2.4 System impact..............................................................................59


Issue: 01J DN09185979 3

8/18/2019 Fd Rl40 Desc


3.2.5 Management data........................................................................ 60


3.3 LTE440: S1 Overload Handling....................................................60

3.3.1 Benefits........................................................................................ 613.3.2 Requirements...............................................................................61

3.3.3 Functional description..................................................................61

3.3.4 System impact..............................................................................64

3.3.5 Management data........................................................................ 65


3.3.7 Configuration................................................................................65

3.4 LTE494: Commercial Mobile Alert System...................................66

3.4.1 Benefits........................................................................................ 66

3.4.2 Requirements...............................................................................66


3.4.4 System impact..............................................................................67

3.4.5 Management data........................................................................ 68


3.5 LTE495: OTDOA..........................................................................69

3.5.1 Benefits........................................................................................ 69

3.5.2 Requirements...............................................................................69


3.5.4 System impact..............................................................................71

3.5.5 Management data........................................................................ 72


3.6 LTE496: Support of QCI 2, 3 and 4..............................................733.6.1 Benefits........................................................................................ 75

3.6.2 Requirements...............................................................................76


3.6.4 System impact..............................................................................79

3.6.5 Management data........................................................................ 80


3.7 LTE497: Smart admission Control................................................84

3.7.1 Benefits........................................................................................ 86

3.7.2 Requirements...............................................................................86

3.7.3 Functional description.................................................................. 863.7.4 System impact..............................................................................88

3.7.5 Management data........................................................................ 89


3.8 LTE519: eRAB Modification......................................................... 90

3.8.1 Benefits........................................................................................ 90

3.8.2 Requirements...............................................................................90


3.8.4 System impact..............................................................................93

3.8.5 Management data........................................................................ 94


3.9 LTE534: ARP based admission control for E-RABs.....................94


4 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


3.9.1 Benefits........................................................................................ 94

3.9.2 Requirements...............................................................................95


3.9.4 System impact..............................................................................963.9.5 Management data........................................................................ 97


3.10 LTE587: Multiple GBR EPS Bearers per UE................................98

3.10.1 Description of LTE587: Multiple GBR EPS Bearers per UE.........98

3.10.1.1 Benefits........................................................................................ 99

3.10.1.2 Requirements...............................................................................99

3.10.1.3 Functional description.................................................................. 99

3.10.1.4 System impact............................................................................101

3.10.1.5 Management data...................................................................... 102

3.10.1.6 Sales information....................................................................... 102

3.10.2 Activating LTE587: Multiple GBR EPS Bearers per UE............. 103

3.10.3 Deactivating LTE587: Multiple GBR EPS Bearers per UE.........104

3.11 Description of LTE736: CS Fallback to UTRAN......................... 105

3.11.1 Benefits...................................................................................... 105

3.11.2 Requirements.............................................................................105

3.11.3 Functional description................................................................ 106

3.11.3.1 CSFB to UTRAN........................................................................ 106

3.11.3.2 CS-Fallback Mode and Target selection.................................... 106

3.11.3.3 New Managed Object Class (MOC)...........................................107

3.11.3.4 Licensing of CSFB to UTRAN.................................................... 107

3.11.3.5 User scenarios........................................................................... 1073.11.3.5.1 Activation/Deactivation CS fallback to UTRAN.......................... 107

3.11.3.5.2 CSFB with a UE in RRC IDLE (Mobile originated and Mobileterminated)................................................................................. 107

3.11.4 System impact............................................................................108

3.11.5 Management data...................................................................... 109

3.11.6 Sales information........................................................................ 111

3.12 Description of LTE843: ETWS broadcast...................................112

3.12.1 Benefits.......................................................................................112

3.12.2 Requirements............................................................................. 112

3.12.3 Functional description.................................................................112

3.12.3.1 Related parameters.................................................................... 114

3.12.4 System impact............................................................................114

3.12.5 LTE843: ETWS broadcast management data............................ 115

3.12.6 Sales information........................................................................116

3.13 LTE872: SRVCC to WCDMA......................................................116

3.13.1 Benefits.......................................................................................116

3.13.2 Requirements............................................................................. 116

3.13.3 Functional description.................................................................117

3.13.4 System impact............................................................................118

3.13.5 Management data...................................................................... 120

3.13.6 Sales information....................................................................... 121


Issue: 01J DN09185979 5

8/18/2019 Fd Rl40 Desc


3.14 LTE873: SRVCC to GSM........................................................... 122

3.14.1 Benefits...................................................................................... 122

3.14.2 Requirements.............................................................................122

3.14.3 Functional description................................................................ 1223.14.4 System impact............................................................................126

3.14.5 Management data...................................................................... 128


3.15 Description of LTE984: GSM Redirect with System Information......130

3.15.1 Benefits...................................................................................... 130

3.15.2 Requirements.............................................................................130


3.15.3.1 CSFB to GSM with system information......................................131

3.15.3.2 Licensing of CSFB to GSM with system information..................132

3.15.3.3 User scenarios........................................................................... 132

3.15.3.3.1 Activation and configuration CS Fallback with redirection to GSMwith system information..............................................................132

3.15.3.3.2 Performing CS Fallback with redirection to GSM with systeminformation................................................................................. 133

3.15.4 System impact............................................................................133

3.15.5 Management data...................................................................... 134


3.16 LTE979: IRC for 2 RX paths.......................................................136

3.16.1 Benefits...................................................................................... 136

3.16.2 Requirements.............................................................................137


3.16.4 System impact............................................................................139

3.16.5 Management data...................................................................... 140


3.17 LTE1014: X2 eNB Configuration Update .................................. 140

3.17.1 Benefits...................................................................................... 141

3.17.2 Requirements.............................................................................141


3.17.4 System impact............................................................................143

3.17.5 Management data...................................................................... 144

3.17.6 Sales information....................................................................... 1443.18 LTE1073: Measurement based redirect to UTRAN ...................144

3.18.1 Benefits...................................................................................... 145

3.18.2 Requirements.............................................................................145


3.18.3.1 Use case.................................................................................... 146

3.18.4 System impact............................................................................147

3.18.5 Management data...................................................................... 147


3.19 LTE1387: Intra eNodeB inter-frequency load balancing............ 148

3.19.1 Benefits...................................................................................... 148


6 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


3.19.2 Requirements.............................................................................149


3.19.4 System impact............................................................................152

3.19.5 Management data...................................................................... 1523.19.6 Sales information....................................................................... 154

4 Descriptions of transport and transmission features.................. 155

4.1 LTE612: Synchronization Hub....................................................155

4.1.1 Benefits...................................................................................... 155

4.1.2 Requirements.............................................................................155


4.1.4 System impact............................................................................157

4.1.5 Management data...................................................................... 157


4.1.7 Abbreviations............................................................................. 158

4.2 LTE628: FTIF Transport PDH / Ether net....................................159

4.2.1 Description of LTE628: FTIF Transport PDH/Ethernet ..............159

4.2.1.1 Benefits...................................................................................... 159

4.2.1.2 Requirements.............................................................................159

4.2.1.3 Functional description................................................................ 159

4.2.1.4 System impacts..........................................................................161

4.2.1.5 LTE628: FTIF Transport PDH/Ethernet management data........161


5 Descriptions of operability features............................................163

5.1 LTE162: Cell Trace with IMSI.....................................................163

5.1.1 Benefit........................................................................................163

5.1.2 Requirements.............................................................................163


5.1.4 System impact............................................................................164

5.1.5 LTE162: Cell Trace with IMSI management data.......................164


5.2 LTE524: Certificate Management for iOMS ...............................165

5.2.1 Benefits...................................................................................... 165

5.2.2 Requirements.............................................................................165


5.2.5 Certificate Management for iOMS management data................169


5.3 LTE593: Security for Ethernet Ports on FCT/FSM3 ..................170

5.3.1 Benefits...................................................................................... 170

5.3.2 Requirements.............................................................................171


5.3.4 System impact............................................................................172

5.3.5 LTE593: Security for Ethernet Ports on FCT/FSM3 managementdata............................................................................................ 172



Issue: 01J DN09185979 7

8/18/2019 Fd Rl40 Desc


5.4 LTE622: Local Link Layer Security.............................................173

5.4.1 Benefits...................................................................................... 173

5.4.2 Requirements.............................................................................173

5.4.3 Functional description................................................................1745.4.4 System impact............................................................................175

5.4.5 LTE622: Local Link Layer Security management data...............176


5.5 LTE623: Crypto Agent................................................................176

5.5.1 Benefits...................................................................................... 176

5.5.2 Requirements.............................................................................177


5.5.4 System impact............................................................................178

5.5.5 LTE623: Crypto Agent management data..................................179


5.6 LTE646: SW Monitoring Extension with PM Counters............... 179

5.6.1 Benefits...................................................................................... 180

5.6.2 Requirements.............................................................................180

5.6.3 Functional description................................................................180

5.6.3.1 Functional overview................................................................... 180

5.6.4 System impact............................................................................181

5.6.5 LTE646: SW Monitoring Extension with PM Countersmanagement data...................................................................... 181


5.7 ................................................................................................... 182

5.7.1 LTE771: Optimization of Intra-LTE Neighbor Relations..............1825.7.1.1 Benefits...................................................................................... 182

5.7.1.2 Requirements.............................................................................182


5.7.1.3.1 RAN system level scope............................................................ 184

5.7.1.3.2 Use case ANR optimization....................................................... 185

5.7.1.3.3 Use case scheduled workflow for LTE771: Optimization of Intra-LTE Neighbor Relations............................................................. 186

5.7.1.3.4 Use case manual triggered workflow for LTE771: Optimization of Intra-LTE Neighbor Relations.....................................................187

5.7.1.3.5 Use Case for the operator to manually clear the blacklist..........187

5.7.1.3.6 SON modus................................................................................1885.7.1.3.7 Reporting....................................................................................188

5.7.1.3.8 Operator interaction outside of LTE771: Optimization of Intra-LTENeighbor Relations.....................................................................189

5.7.1.4 System impact............................................................................189

5.7.1.5 LTE771:Optimization of neighbor relations management data.. 191


5.7.1.7 Abbreviations............................................................................. 192

5.8 LTE877: Adjustable Performance Upload.................................. 193

5.8.1 Benefits...................................................................................... 193

5.8.2 Requirements.............................................................................193


8 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



5.8.4 System impact............................................................................194

5.8.5 LTE877: Adjustable Performance Upload management data.... 195

5.8.6 Sales information....................................................................... 1955.9 LTE940: SW Verification Agent..................................................195

5.9.1 Benefits...................................................................................... 195

5.9.2 Requirements.............................................................................196


5.9.4 System impact............................................................................197

5.9.5 LTE940: SW Verification Agent management data.................... 197


5.10 LTE953: MDT (Minimization of Drive Test).................................198

5.10.1 Benefits...................................................................................... 198

5.10.2 Requirements.............................................................................199


5.10.4 System impact............................................................................200

5.10.5 LTE953: MDT (Minimization of Drive Test) management data...201


5.11 LTE1019: SON Reports..............................................................202

5.11.1 Description of LTE1019: SON Repor ts.......................................202

5.11.1.1 Benefits...................................................................................... 202

5.11.1.2 Requirements.............................................................................202


5.11.1.3.1 Change origin report.................................................................. 203

5.11.1.3.2 SON reporting mechanism.........................................................2045.11.1.3.3 SON reporting content............................................................... 205

5.11.1.4 System impact............................................................................208

5.11.1.5 Management data...................................................................... 209


5.12 LTE1045: Full SON support for distributed sites ....................... 210

5.12.1 Description of LTE1045: Full SON Support for Distributed Sites.....210

5.12.1.1 Benefits...................................................................................... 210

5.12.1.2 Requirements.............................................................................210

5.12.1.3 Functional description.................................................................211

5.12.1.3.1 NetAct Optimizer........................................................................ 212

5.12.1.3.2 NetAct use case......................................................................... 214

5.12.1.4 System impact............................................................................214

5.12.1.5 Management data...................................................................... 216


5.13 LTE1078: System Upgrade with Backward Compatibility.......... 217

5.13.1 Benefits...................................................................................... 217

5.13.2 Requirements.............................................................................217


5.13.4 System impact............................................................................220

5.13.5 Management data...................................................................... 220


Issue: 01J DN09185979 9

8/18/2019 Fd Rl40 Desc



5.14 Description of LTE1201: LTE iOMS HW, HP Blade Gen8..........221

5.14.1 Benefits...................................................................................... 221

5.14.2 Requirements.............................................................................2215.14.3 Functional description................................................................ 221

5.14.4 System impact............................................................................222

5.14.5 LTE1201: LTE iOMS HW, HP Blade Gen8 management data...222


5.15 LTE1222: Inter-RAT Auto Setup and Scheduled Optimization ..223

5.15.1 LTE1222: SON Automation Modes............................................ 223

5.15.1.1 Benefits...................................................................................... 223

5.15.1.2 Requirements.............................................................................223


5.15.1.3.1 LTE533: Mobility Robustness ....................................................224

5.15.1.3.2 LTE783: ANR for InterRAT UTRAN ...........................................225

5.15.1.3.3 LTE784: ANR for InterRAT GERAN .......................................... 226

5.15.1.3.4 LTE510: Synchronization of Inter-RAT neighbors...................... 228

5.15.1.3.5 LTE771: Optimization of Intra-LTE neighbor relations................230

5.15.1.4 System impact ...........................................................................231

5.15.1.5 Management data...................................................................... 232


5.16 LTE1340: Trace-based Real Time Monitoring............................232

5.16.1 Benefits...................................................................................... 232

5.16.2 Requirements.............................................................................233


5.16.5 LTE1340: Trace-based Real Time Monitoring management data....235


5.17 Description of LTE1457: Cell trace Configuration via ConfigurationManagement ............................................................................. 235

5.17.1 Benefits...................................................................................... 236

5.17.2 Requirements.............................................................................236


5.17.4 System impact............................................................................237

5.17.5 LTE1457: Cell trace Configuration via Configuration Managementmanagement data...................................................................... 237


6 Descriptions of BTS site solution features................................. 239

6.1 LTE179: Dual Band with One System Module ..........................239

6.1.1 Benefits...................................................................................... 239

6.1.2 Requirements.............................................................................239


6.1.4 System impact............................................................................243

6.1.5 LTE179: Dual Band with One System Module management data...

244


10 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


8/18/2019 Fd Rl40 Desc


6.8.2 Requirements.............................................................................264


6.8.4 System impact............................................................................265

6.8.5 LTE1125: GNSS Receiver FYGB management data.................2656.8.6 Sales information....................................................................... 266

6.9 LTE1148: FRIG Flexi RRH 4TX 1.7/2.1......................................266

6.9.1 Benefits...................................................................................... 267

6.9.2 Requirements.............................................................................267


6.9.4 LTE1148: FRIG Flexi RRH 4TX 1.7/2.1 management data........268

6.9.5 System impacts..........................................................................268


6.10 LTE1261: FHDB Flexi RRH 2TX 900......................................... 268

6.10.1 Benefits...................................................................................... 269

6.10.2 Requirements.............................................................................269


6.10.4 System impacts..........................................................................270


6.11 LTE1263: FRGV Flexi RRH 2TX 2100.......................................270

6.11.1 Benefits...................................................................................... 270

6.11.2 Requirements.............................................................................270


6.11.4 System impacts..........................................................................271

6.11.5 LTE1263: FRGV Flexi RRH 2TX 2100 management data.........272

6.11.6 Sales information....................................................................... 2726.12 LTE1306: FRMD Flexi 3-sector RF Module 800........................ 272

6.12.1 Benefits...................................................................................... 272

6.12.2 Requirements.............................................................................273


6.12.4 System impacts..........................................................................273

6.12.5 1306: FRMD Flexi 3-sector RF Module 800 management data.274


6.13 Description of LTE1514: Additional RF sharing ConfigurationsLTE-GSM....................................................................................274

6.13.1 Benefits...................................................................................... 274

6.13.2 Requirements.............................................................................275


6.13.4 System impact............................................................................275

6.13.5 Management data...................................................................... 276



12 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


List of FiguresFigure 1 Rejection of RRCConnectionRequest message (no MME identifier

provided) because MME overload...................................................... 63

Figure 2 Acceptance of RRCConnectionRequest (no MME identifier provided) with one MME in overload state......................................... 63

Figure 3 Rejection of RRCConnectionRequest message (MME identifier provided) because of MME overload..................................................64

Figure 4 Acceptance of RRCConnectionRequest (MME identifier provided)with MME in overload state................................................................ 64

Figure 5 OTDOA overview................................................................................70

Figure 6 Interaction of different function blocks................................................ 87

Figure 7 MSC: E-RAB Modify Request.............................................................91

Figure 8 The ETWS overview......................................................................... 114

Figure 9 Message flow during SRVCC handover........................................... 123

Figure 10 SRVCC handover scenario.............................................................. 126

Figure 11 BLER (SINR) for SDI, EPA30........................................................... 138

Figure 12 BLER (SINR) for SDI, ETU70...........................................................139

Figure 13 Overview of interfaces...................................................................... 141

Figure 14 X2 eNB Configuration Update - successf ul procedure.....................142

Figure 15 X2 eNB Configuration Update - failed procedure............................. 143

Figure 16 FTIF Transport sub-module front panel view - physical layer view...160

Figure 17 FTIF interfaces - logical layer view ..................................................160

Figure 18 Signaling flow of initial operator certificate enrollment......................167

Figure 19 Inter-secure environment communication........................................ 175

Figure 20 Secure storage support by Crypto Agent......................................... 178

Figure 21 LTE771: Optimization of Intra-LTE Neighbor Relations....................184

Figure 22 NetAct-originated parameter change................................................205

Figure 23 Top down upgrade approach............................................................ 218

Figure 24 Trace-based real time monitoring architecture................................. 234

Figure 25 Managed objects structure............................................................... 237

Figure 26 Dual Band configuration with four RF Modules................................ 240

Figure 27 Dual Band configuration with six RRHs, from which three are chained.241

Figure 28 Dual Band configuration with six RRHs, from which two are chained....242

Figure 29 Dual Band configuration with four RRHs, from which two are chained..243

Figure 30 Isometric view of FXFA RF Module.................................................. 247

Figure 31 FXFA front panel connectors and labels...........................................248

Figure 32 Front panel of the System Module (FSMF) with optional sub-modulesFPFD, FTIF, and two FBBAs............................................................ 254

Figure 33 FPFD sub-module............................................................................ 257


Issue: 01J DN09185979 13

8/18/2019 Fd Rl40 Desc


Figure 34 FPFC module................................................................................... 260

Figure 35 FXEB front panel connectors and labels.......................................... 263

Figure 36 Flexi BTS Synchronization with GNSS.............................................265


14 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


List of TablesTable 1 RL40 Features - not supported by Flexi Zone Micro.......................... 21

Table 2 Parameters used for activating and configuring LTE48: Support of high speed users................................................................................ 26

Table 3 Software requirements....................................................................... 54

Table 4 New parameters................................................................................. 56

Table 5 Modified parameters...........................................................................56

Table 6 Related existing parameters...............................................................57

Table 7 Sales information................................................................................57


Table 9 Maximum supported velocities depending on the carrier frequeny ... 58















Table 24 Standardized QCI characteristics.......................................................74


Table 26 Congestion Handling configured by gbrCongHandling.......................77

Table 27 Parameter ulsFdPrbAssignAlg........................................................... 78

Table 28 New counters......................................................................................80

Table 29 Parameters for the workaround for QCI = 2,3,4................................. 82




Table 33 Abbreviations of the figure above.......................................................87

Table 34 Thresholds and margins.....................................................................88






Issue: 01J DN09185979 15

8/18/2019 Fd Rl40 Desc




Table 41 New counters......................................................................................97



Table 44 Allowed maximum number of bearers ............................................... 99


Table 46 New parameters............................................................................... 102

Table 47 Modified parameters.........................................................................102

Table 48 Sales information..............................................................................102

Table 49 Software requirements..................................................................... 105

Table 50 New counters....................................................................................109


Table 52 New parameters for the “Primary PLMN identity in CGI of UTRANneighbor cell” list............................................................................... 111

Table 53 Related existing parameters............................................................. 111

Table 54 Sales information.............................................................................. 111

Table 55 Software requirements......................................................................112




Table 59 Modified parameters.........................................................................116Table 60 Sales information.............................................................................. 116




Table 64 Related existing parameters.............................................................121















16 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc











Table 87 Recovery of synchronization output clock........................................ 156









Table 96 Related existing alarms.................................................................... 169












Table 108 New counters....................................................................................181Table 109 Sales information.............................................................................. 181

Table 110 Software requirements for RL40.......................................................182




Table 114 Abbreviations.................................................................................... 192





Issue: 01J DN09185979 17

8/18/2019 Fd Rl40 Desc
































Table 148 FXFA front panel connectors, cable types and interfaces................ 249Table 149 FXFA dimensions and weight........................................................... 250



Table 152 Flexi Multiradio System Module FSMF peak throughput..................253







18 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc






Table 162 Related existing parameters............................................................. 266













Issue: 01J DN09185979 19

8/18/2019 Fd Rl40 Desc


Summary of changesChanges between 01I (2014-03-15, RL40) and 01J (2015-12-16, RL40)

The following feature description has been updated:

LTE1387: Intra eNodeB inter-frequency load balancing

Changes between 01H (2014-06-25, RL40) and 01I (2015-03-15, RL40)

The following feature descriptions have been added:

• LTE771: Optimization of Neighbor Relations

• LTE1019: SON Reports

• LTE1045: Full SON support for distributed sites

• LTE1222: SON Automation Modes

Changes between 01G (2013-07-22, RL40) and 01H (2014-06-25, RL40)

The following feature descriptions have been updated:

• LTE646: SW Monitoring Extension with PM Counters

Changes between 01F (2013-04-15, RL40) and 01G (2013-07-22, RL40)

The following feature description has been added:

• LTE1125: GNSS Receiver FYGB

The following feature description has been updated:

• LTE524: Certificate Management for iOMS

Summary of changes LTE RL40, Feature Descriptions and Instructions

20 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


1 RL40 Features - not supported by Flexi ZoneMicro

The following features are not supported by Flexi Zone Micro:

Table 1 RL40 Features - not supported by Flexi Zone Micro

Features Category

LTE179: Dual Band with One System Module BTS

LTE612: Synchronization Hub Operability

LTE621: Flexi 10 BTS Basic Configurations BTS

LTE622: Local Link Layer Security Operability

LTE628: FTIF Transport PDH / Ethernet BTS

LTE763: FXFA Flexi 3-sector RF Module 1900 BTS

LTE947: FSMF Flexi Multiradio 10 System Module BTS

LTE949: FPFD Flexi Power Distribution Sub-module BTS

LTE950: FPFC Flexi Power Distribution Module BTS

LTE1040: FXEB Flexi 3-sector RF Module 1800 BTS

LTE1078: System Upgrade Operability

LTE1148: FRIG Flexi RRH 4TX 1.7/2.1 BTS

LTE1261: FHDB Flexi RRH 2TX 900 BTS

LTE1306: FRMD Flexi 3-sector RF Module 800 BTS

LTE1514: Large LTE-GSM RF sharing Configurations BTS

LTE RL40, Feature Descriptions and Instructions RL40 Features - not supported by Flexi Zone Micro

Issue: 01J DN09185979 21

8/18/2019 Fd Rl40 Desc


8/18/2019 Fd Rl40 Desc


3 Modify the feature-specific eNB configuration settings.

The feature-related settings are found in the set of Commissioning pages. In the topright-hand corner of the BTSSM window, there is a location bar that shows at whichstage of the Commissioning process the user is. It is recommended that the user carefully reads the pages containing full eNB configuration information.

4 Send the commissioning plan file to the eNB.

Sub-steps

a) Go to the Send Parameters page.

b) In section Send, choose whether the BTSSM should send to the eNB onlythe changed parameters: Only changes (may require reset), or a whole setof parameters: All parameters (requires reset).

c) Click the Send Parameters button.

5 The new commissioning plan file is automatically activated in the eNB.

Sub-steps

a) After successful transmission of the parameters, the new configuration isautomatically activated.

The BTSSM automatically sends an activation command after finishing the filedownload.

b) If the configuration changes require restart, the eNB performs the restartnow.

g Note: For information on possible restarts, see section Before you start of everyfeature -specific procedure.

2.2 LTE46: Channel Aware Scheduler (UL)

Purpose

Follow these procedures to activate and deactivate the LTE46: Channel Aware

Scheduler (UL) feature.

LTE RL40, Feature Descriptions and Instructions Activating LTE RL40 Features

Issue: 01J DN09185979 23

8/18/2019 Fd Rl40 Desc


Activating LTE46: Channel Aware Scheduler (UL)

Before you start

Restart of the eNB is required after activation of this feature only if the Include SRS

measurements In CL power control (ulpcSrsEn) parameter value is

changed.

The Scheduling method of the UL scheduler (ulsSchedMethod)

parameter is used to activate the feature.

The following parameters are used to perform an additional configuration of the feature:

• SRS Configuration (srsConfiguration)

• Power offset for SRS transmission power calculation

(srsPwrOffset)

• Include SRS measurements In CL power control (ulpcSrsEn)

Steps

1 Follow the general procedure described in section Activating and deactivatingLTE features using BTS Site Manager .

In Step 3 (Modify the feature-specific eNB configuration settings) of the generalprocedure perform the steps described in this procedure.

2 Go to the Radio network configuration page.

a) Expand the LNBTS object.

b) Select the LNCEL object.

c) Set the Scheduling method of the UL scheduler(ulsSchedMethod) parameter value to channel aware (1).

g Note: This step activates the feature.

Power offset for SRS transmission power

calculation (srsPwrOffset) parameter must be configured.Periodic PHR timer (tPeriodicPhr) parameter must be set to valuedifferent from infinity.

Include SRS measurements In CL power control (ulpcSrsEn)parameter must be cofnfigured.UL scheduler FD type (ulsFdPrbAssignAlg) parameter must be set toMixed FD.SRS Configuration (srsConfiguration) parameter must beconfigured. Range of the SRS Configuration (srsConfiguration)

parameter depends on Uplink channel bandwidth (ulChBw)parameter.

Activating LTE RL40 Features LTE RL40, Feature Descriptions and Instructions

24 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Deactivating LTE46: Channel Aware Scheduler (UL)

Before you start

Restart of the eNB is required after deactivation of this feature only if the Include SRS

measurements In CL power control (ulpcSrsEn) parameter value is

changed.

Steps


In Step 3 (Modify the feature-specific eNB configuration settings) of the general

procedure perform the steps described in this procedure.




c) Set the Scheduling method of the UL scheduler(ulsSchedMethod) parameter value to channel unaware (0) or interferenceaware (2).If Scheduling method of the UL scheduler (ulsSchedMethod)parameter value is other that channel aware (1), Include SRSmeasurements In CL power control (ulpcSrsEn) parameter mustbe set to false.If Include SRS measurements In CL power control(ulpcSrsEn)is set to false, Power offset for SRS transmission powercalculation (srsPwrOffset)parameter must not be defined.

2.3 LTE48: Support of High Speed Users

Purpose

Follow these procedures to activate and deactivate the LTE48: Support of High Speed Users feature.

2.3.1 Activating LTE48: Support of High Speed Users

Before you start


Issue: 01J DN09185979 25

8/18/2019 Fd Rl40 Desc


Table 2 Parameters used for activating and configuring LTE48: Support of highspeed users

Parameter Purpose Requires eNB restart or object locking

PRACH high speed flag(prachHsFlag)

activation flag requires object locking

High speed Scenario (HsScenario) mandatory configuration requires object locking

PRACH cyclic shift (prachCS) mandatory configuration requires object locking

RACH root sequence(rootSeqIndex)

mandatory configuration requires object locking

2.3.1.1 Steps

1 Follow the general procedure described in section Activating and deactivating LTE features using BTS Site Manager .

In Step 3 (Modify the feature-specific eNB configuration settings) of the generalprocedure, perform the steps described in this procedure.

2 Set the activation flag.

a) Go to the Radio Network Configuration page.

b) Expand the MRBTS object.

c) Expand the LNBTS object.d) Select the LNCEL object corresponding to the cell where the LTE48: Support of high speed users feature will be activated.

e) Set the PRACH high speed flag (prachHsFlag) parameter value to true.

f) Set the Highspeed scenario (hsScenario) parameter value to scenario 1or scenario 3.

3 Configure the existing parameter (mandatory).



c) Expand the LNBTS object.d) Under the LNCEL object corresponding to the cell where the LTE48: Support of

high speed users feature will be activated, set the following parameters:

• RACH root sequence (rootSeqIndex)

• PRACH cyclic shift (prachCS)

4 Send the parameters to the eNB according to the procedure described insection Activating and deactivating LTE features using BTS Site Manager .


26 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


2.3.2 Deactivating LTE48: Support of High Speed Users

Before you start

The following parameters are used for deactivation:

• thePRACH high speed flag (prachHsFlag) parameter

• theHigh speed Scenario (HsScenario) parameter

Both of them require object locking.

2.3.2.1 Steps

1 Follow the general procedure described in section Activating and deactivating

LTE features using BTS Site Manager .

In Step 3 (Modify the feature-specific eNB configuration settings) of the generalprocedure, perform the steps described in this procedure.

2 Set the deactivation flag.



c) Expand the LNBTS object.

d) Select the LNCEL object corresponding to the cell where the LTE48: Support of high speed users feature will be deactivated.

e) Set the PRACH high speed flag (prachHsFlag) parameter value tofalse.

f) Set the High speed Scenario (HsScenario) parameter value to empty.

3 Send the parameters to the eNB according to the procedure described insection Activating and deactivating LTE features using BTS Site Manager .

2.4 LTE494: Commercial Mobile Alert System

Purpose

Follow these procedures to activate and deactivate the LTE494: Commercial Mobile Alert

System feature.

Activating LTE494: Commercial Mobile Alert System

Before you start

Restart of the eNB is not required after activation of this feature.

The Activation CMAS support (actCMAS) parameter is used to activate the

feature.


Issue: 01J DN09185979 27

8/18/2019 Fd Rl40 Desc


The following parameters are used to perform mandatory configuration of the feature:

• PWS with emergency area ID (pwsWithEmAreaId)

• Emergency area ID (emAreaId)

• System information scheduling list (sibSchedulingList)

It is not possible to enable LTE494: Commercial Mobile Alert System feature and

LTE843: ETWS broadcast feature simultaneously per one eNB.

Steps





b) Set the Activation CMAS support (actCMAS) parameter value to true.


c) If the LTE843: ETWS broadcast feature is activated, set the ActivationETWS support (actETWS) parameter to false.

d) Configure the PWS with emergency area ID (pwsWithEmAreaId)parameter.

e) Select the LNCEL object.

f) Configure the System information scheduling list(sibSchedulingList) parameter. The sibSchedulingList must containSIB12 configuration (siMessageSibType of one set must be set to SIB12).Periodicity, Repetition andSIB type for SIB12 must be configured.

g) If the PWS with emergency area ID (pwsWithEmAreaId) parameter isset to true, configure the Emergency area ID (emAreaId) parameter.

Deactivating LTE494: Commercial Mobile Alert System

Before you start

Restart of the eNB is not required after deactivation of this feature.


28 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Steps





b) Set the Activation CMAS support (actCMAS) parameter value to false.

2.5 LTE495: OTDOA

Purpose

Follow these procedures to activate and deactivate the LTE495: OTDOA feature.

Activating LTE495: OTDOA

Before you start


The PRS activation (actOtdoa) parameter is used to activate the feature.


• SI window length (siWindowLen)

• GPS connected to system module (gpsInUse)

• DRX on duration timer (drxOnDuratT)

• BTS network synchronization mode (btsSyncMode)

• PRS power boost (prsPowerBoost)

• PRS Tx diversity activation (actPrsTxDiv)

• PRS configuration index (prsConfigurationIndex)

• PRS bandwidth (prsBandwidth)

• PRS Number of DL frames (prsNumDlFrames)


Issue: 01J DN09185979 29

8/18/2019 Fd Rl40 Desc


Steps






c) Set the PRS activation (actOtdoa) parameter value to true.


SI window length (siWindowLen) must be set appropriately depending onthe individual PRS configurationDRX on duration timer (drxOnDuratT) in drxProfile2 and drxProfile3must be set to value greater than 3.The following parameters must be configured:

• PRS power boost (prsPowerBoost)

• PRS Tx diversity activation (actPrsTxDiv)

• PRS configuration index (prsConfigurationIndex)

• PRS bandwidth (prsBandwidth)

• PRS Number of DL frames (prsNumDlFrames)

d) Select the BTSSCL object.GPS connected to system module (gpsInUse) must be set to true.BTS network synchronization mode (btsSyncMode) must be se toPhaseSync.

Deactivating LTE495: OTDOA

Before you start


Steps




30 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc





c) Set the PRS activation (actOtdoa) parameter value to false.

2.6 LTE496: Support of QCI 2, 3 and 4; LTE497: SmartAdmission Control; LTE534: ARP Based AdmissionControl

Purpose

Follow these procedures to activate and deactivate the features: LTE496: Support of QCI

2,3 and 4, LTE497: Smart Admission Control, LTE534: ARP Based Admissiion Control.

Activating LTE496: Support of QCI 2, 3 and 4; LTE497Smart Admission Control; LTE534: ARP Based AdmissionControl

Before you start

The features

• LTE496: Support of QCI 2, 3 and 4

• LTE497: Smart Admission Control

• LTE534: ARP Based Admission Control

depend on each other and can only be activated together by setting the parameter

Activate enhanced AC and GBR services (actEnhAcAndGbrServices)

to true.

The feature LTE7: Support of Multiple EPS Bearer

must be activated before activation of the feature bundle above.

The following parameters must be activated or configured:

• LNBTS

– Activate multiple bearers (actMultBearers)

– Congestion weight algorithm (congWeightAlg)

– Activate multiple GBR bearers (actMultGbrBearers)

• LNCEL

UL scheduler FD type (ulsFdPrbAssignAlg)

Activate enhanced AC and GBR services (actEnhAcAndGbrServices)

can only be set to true if Activate multiple bearers (actMultBearers) is set

to true AND Congestion weight algorithm (congWeightAlg) is configured.


Issue: 01J DN09185979 31

8/18/2019 Fd Rl40 Desc


When LTE497 is activated the following RAC parameters must be configured appropriate

(all are LNCEL parameters):

• Maximum GBR-DBR Traffic Limit (maxGbrTrafficLimit)

• Add GBR-DRB Traffic for Radio Reason Handover

(addGbrTrafficRrHo)

• Add GBR-DRB Traffic for Time Critical Reason Handover

(addGbrTrafficTcHo)

A change of the activation of this feature bundle becomes valid at the next BTS restart.

Steps


LTE features using BTS Site Manager .


2 Go to the Radio Network Configuration page.

a) Expand the MRBTS object.

b) Select the LNBTS object.

c) Set the Activate Enhanced AC and GBR Services (actEnhAcAndGbrServices)parameter value to true.This step activates the features.

Deactivating LTE496: Support of QCI 2, 3 and 4; LTE497Smart Admission Control; LTE534: ARP Based AdmissionControl

Before you start

The features


• LTE497: Smart Admission Control


depend on each other and can only be deactivated together by setting the parameter

Activate enhanced AC and GBR services (actEnhAcAndGbrServices)to false.

(Activate enhanced AC and GBR services (actEnhAcAndGbrServices) can not be set to

false if ((Activate multiple GBR bearers (actMultGbrBearers) is set to

true)) OR ((UL scheduler FD type (ulsFdPrbAssignAlg) is set to MixedFD in any LNCEL

instance)

The deactivation of this feature bundle becomes valid at the next BTS restart


32 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Steps






c) Set the Activate Enhanced AC and GBR Services (actEnhAcAndGbrServices)

parameter value to false.This step deactivates the features.

2.7 LTE519: E-RAB Modification

Purpose

Follow these procedures to activate and deactivate the feature: LTE519: E-RAB

Modification.

Activating LTE519: E-RAB Modification

Before you start

The feature LTE519: E-RAB Modifi cation must be activated by setting the parameter

Activate E-RAB Modification (actERabModify) to true,

The feature LTE9: Service Differentiation must be activated (by setting the parameter

Activate nonGBR Service Differentiation (actNonGbrService Diff) to true) before the

feature LTE519: E-RAB Modifcation can be activated.

A change of the activation of this feature becomes valid at the next arriving S1AP

message E-RAB MODIFY REQUEST

Steps




Issue: 01J DN09185979 33

8/18/2019 Fd Rl40 Desc





c) Set the Activate E-RAB Modification (actErabModify)

parameter value to true.This step activates the feature.

Deactivating LTE519: E-RAB Modification

Before you start

The feature LTE519: E-RAB Modifcation can be deactivated by setting the parameter Activate E-RAB Modification(actERabModify) to false.


message E-RAB MODIFY REQUEST.

Steps






c) Set the Activate E-RAB Modifcation (actERabModify) parameter value to false.This step deactivates the feature.

2.8 LTE587: Multiple GBR EPS Bearers per UE

Purpose

Follow these procedures to activate and deactivate the feature: LTE587:Multple GBR

EPS Bearers per UE.


34 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Activating LTE587: Multiple GBR EPS Bearers per UE

Before you start

The feature LTE587: Multiple GBR EPS Bearers per UE must be activated by setting the

parameter Activate Multiple GBR Bearers (actMultGbrBearers) to true,

The features

• LTE7: Support of Multiple EPS Bearer



must be activated before activation of the feature LTE587: Multiple GBR EPS Bearers

per UE .


message INITIAL CONTEXT SETUP REQUEST or E-RAB SETUP REQUEST or at thenext handover preparation

Steps






c) Set the Activate multiple GBR bearers (actMultGbrBearers)

parameter value to true.This step activates the feature.

Deactivating LTE587: Multiple GBR EPS Bearers per UEBefore you start

The feature LTE587: Multiple GBR EPS Bearers per UE can be deactivated by setting

the parameter Activate multiple GBR Bearers (actMultGbrBearers)to

false.


message INITIAL CONTEXT SETUP REQUEST or E-RAB SETUP REQUEST or at the

next handover preparation


Issue: 01J DN09185979 35

8/18/2019 Fd Rl40 Desc


Steps






c) Set the Activate multiple GBR bearers (actMultGbrBearers)

parameter value to false.This step deactivates the feature.

2.9 LTE612: Synchronization Hub using BTS SiteManager

Purpose

Follow these procedures to activate or deactivate the LTE612: Synchronization Hub

feature.

Activating LTE612: Synchronization Hub

Before you start

The evolved NodeB must already be commissioned. The BTS Site Manager (BTSSM)

can be connected to the eNB either locally, or from a remote location.


The syncPropagationEnabled parameter ("Forward synchronization in co-siting") is

used to activate the feature.

Steps

1 Follow the general procedure described in section Activating and Deactivating LTE features using BTS site manager .



36 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


2 Go to the BTS Settings page.

Select “Forward synchronization in co-siting”.This step activates the feature. So the output of 1PPS, 2.048 MHz external signaland/or PDH synchronization sources is provided by the eNB.

3 In case of 2.048 MHz output signal: Go to the BTS Settings page.

To enable the 2.048 MHz output also in case of holdover mode.

Select “External 2.048 MHz synchronization output in use in HO mode”.

This step enables the 2.048 MHz output also in case of holdover mode. In case theparameter isn’t selected, the output signal is switched off, if the eNB is in holdover mode.

4 In case of PDH output signal: Go to the Physical Layer Configuration page.

Select “PDH Interfaces” IF number.

This step enables the PDH interfaces for the output PDH signal.

5 In case of PPS output signal: Go to the BTS Settings page.

Select “External 1pps clock out on”.

This step enables the 1 PPS output also in case of holdover mode.

g Note: Remark:

For FSME: cannot be configured (HW limitation). In case of holdover mode the outputsignal is switched-off.

For FSMF: cannot be configured in RL40 (prepared for future development)

Deactivating LTE612: Synchronization Hub

Before you start

The evolved eNB must already be commissioned. The BTS Site Manager (BTSSM) canbe connected to the eNB either locally, or from a remote location.


The syncPropagationEnabled parameter (“Forward synchronization in co-siting”) is

used to deactivate the feature.


Issue: 01J DN09185979 37

8/18/2019 Fd Rl40 Desc


Steps

1 Follow the general procedure described in section Activating and deactivating LTE features using BTS site manager .


2 Go to the BTS Settings page.

Unselect the “Forward synchronization in co-siting”.

This step deactivates the feature.

3 In case of PDH output signal: Go to the Physical Layer Configuration page.

Unselect “PDH Interfaces” IF number.

This step disables the PDH interfaces for the output PDH signal.

Configuration of the eNB receiving the synchronizationsignal from a synchronization hub eNB

Before you start

When Sync Hub configuration is active the Synchronization Hub eNB needs to beconnected to chained eNBs. Depending on the chosen synchronization signal either the

“sync out” needs to be connected to “sync in” (for PPS and 2 MHz) or the PDH interfaces

need to be connected. For “sync out” and “sync in” the different connector types need to

be considered (FSME: MDR14 out and MDR26 in; FSMF: HDMI).

Synchronization input for 2.048 MHz and PDH needs to be done in the usual manner.

1. In case of PPS output signal:

Go to the BTS Settings page.

2. Select “GPS in use”

This step enables the 1 PPS input.

3. Select Network synchronization mode: “Frequency synchronization” or “Phasesynchronization”

This step enables either frequency or phase synchronization.

4. Select “GPS control interface blocked for co-located BTS”

This step disables the control interface for the Synchronization Interface Protocol for

receiving and sending (for example day of time info). In case of synchronization

chained eNB, it needs to be disabled.

In case of “Phase synchronization”

The overall propagation delay needs to be compensated. This needs to include delay

of the line between the GPS antenna/receiver and the Synchronization hub eNB

1pps input and the line(s) between the input and output of the chained eNB(s). The

delay can be configured either via “GPS cable length” or via “GPS antenna line

delay”.Select “GPS cable length” and choose appropriate cable length in meter.


38 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


This step enables compensation of the antenna line in case well-defined cables are

used.

OR

Select “GPS antenna line delay” and enter the appropriate delay in ns.

This step enables compensation of the antenna line.

2.10 LTE736: CS Fallback to UTRAN

Follow these procedures to activate and deactivate the LTE736: CS Fallback to UTRAN

feature.

Activating LTE736: CS Fallback to UTRAN

Before you startRestart of the eNB is not required after activation of this feature.

The following parameters are used to activate the feature:

• Activate CS fallback with PS-HO to UTRA (actCsfbPsHoToUtra)

• Activate handover from LTE to WCDMA (actHOtoWcdma)

• Activate CS fallback via redirection (actCSFBRedir)

The following features need to be activated/configured before activation of LTE736: CS

Fallback to UTRAN :

• LTE56: Inter RAT Handover to WCDMA

• LTE562: CS Fallback with redirection

For more detailed information see System impact of LTE736: CS Fallback to UTRAN .

Steps






c) Set the Activate CS fallback with PS-HO to UTRA(actCsfbPsHoToUtra) parameter value to true.This step activates the feature.


Issue: 01J DN09185979 39

8/18/2019 Fd Rl40 Desc


Deactivating LTE736: CS Fallback to UTRAN

Before you start


Steps


In Step 3 (Modify the feature-specific eNB conf iguration settings) of the generalprocedure perform the steps described in this procedure.




c) Set the Activate CS fallback with PS-HO to UTRA(actCsfbPsHoToUtra) parameter value to false.This step deactivates the feature.

2.11 LTE843: ETWS broadcast

Purpose

Follow these procedures to activate and deactivate the LTE843: ETWS broadcast

feature.

Activating LTE843: ETWS broadcast

Before you start


The Activation ETWS support (actETWS) parameter is used to activate thefeature.


• ETWS primary notification broadcast duration

(etwsPrimNotifBcDur)

• PWS with emergency area ID(pwsWithEmAreaId)

• Emergency area ID (emAreaId)

• System information scheduling list (sibSchedulingList)

It is not possible to enable LTE843: ETWS broadcast feature and LTE494: Commercial

Mobile Alert System feature simultaneously per one eNB.


40 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Steps





b) Set the Activation ETWS support (actETWS) parameter value to true.

gNote: This step activates the feature.

c) If the LTE494: Commercial Mobile Alert System feature is activated, set theActivation CMAS support (actCMAS) parameter to false.

d) Configure the ETWS primary notification broadcast duration(etwsPrimNotifBcDur) parameter.

e) Configure the PWS with emergency area ID (pwsWithEmAreaId)parameter

f) Select the LNCEL object.

g) Configure the System information scheduling list(sibSchedulingList) parameter. The sibSchedulingList mustcontain SIB10 and SIB11 configuration.Periodicity, Repetition andSIBtype for SIB10 and SIB11 must be configured.

h) If the PWS with emergency area ID (pwsWithEmAreaId) parameter isset to true, configure the Emergency area ID (emAreaId) parameter

Deactivating LTE843: ETWS broadcast

Before you start


Steps




Issue: 01J DN09185979 41

8/18/2019 Fd Rl40 Desc




b) Set the Activation ETWS support (actETWS) parameter value to false.

2.12 LTE872: SRVCC to WCDMA

Purpose

Follow these procedures to activate and deactivate the LTE872: SRVCC to WCDMA

feature.

Activating LTE872: SRVCC to WCDMA

Before you start



• Activate SRVCC to WCDMA (actSrvccToWcdma)

• Activate handover from LTE to WCDMA (actHOtoWcdma)

• Activate support of conversational voice

bearer (actConvVoice)


• SRVCC HO indication (srvccHoInd)

• Single radio voice call continuity allowed (srvccAllowed)

• Frequency layer list for SRVCC to

WCDMA (freqLayListSrvccWcdma) in MODPR MOC

• Frequency layer list for SRVCC to

WCDMA (freqLayListSrvccWcdma) in MOPR MOC

• Target frequency (uTargetFreq)

• WCDMA neighbor relation identifier (lnRelWId)

• Primary PLMN identity in CGI of UTRAN neighbor cell (plmnId)• PS handover allowed (psHoAllowed)

• Target cell Id in UTRAN CGI of related neighbor

cell (uTargetCid)

• Target RNC Id (uTargetRncId)

The following features need to be activated/configured before activation of LTE872:

SRVCC to WCDMA:


• LTE10: EPS Bearers for Conversational Voice

• LTE56 Inter RAT Handover to WCDMA


42 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


For more detailed information see System impact of LTE872: SRVCC to WCDMA.

Steps

Expected outcome

LTE872: SRVCC to WCDMA is activated.






c) Set the Activate SRVCC to WCDMA (actSrvccToWcdma) parameter value to true.


d) Set the Activate handover from LTE to WCDMA (actHOtoWcdma)parameter value to true.

gNote: This step activates the feature.

e) Set the Activate support of conversational voice bearer(actConvVoice) parameter value to true.


3 Expand the MRBTS object, expand LNBTS object (optional).

• For each Neighbor WCDMA BTS cell (in LNADJW object) set Targerfrequency (InAdjWId)

• For each Neighbor WCDMA BTS cell (in LNADJW object) set SRVCC HOindication (srvccHoInd)

4 Expand the MRBTS object, expand LNBTS object, and select MODPR object(optional).

• Set the Frequency layer list for SRVCC to WCDMA(freqLayListSrvccWcdma) parameter.


Issue: 01J DN09185979 43

8/18/2019 Fd Rl40 Desc


5 Expand the MRBTS object, expand LNBTS object, and select MOPR object(optional).

• Set the Frequency layer list for SRVCC to WCDMA(freqLayListSrvccWcdma) parameter.

6 Expand the MRBTS object, expand LNBTS object, and for each LNCEL objectselect LNRELW obejct (optional).

• Set the WCDMA neighbor relation identifier (lnRelWId)parameter.

• Set the Primary PLMN identity in CGI of UTRAN neighbor cell(plmnId) parameter.

• Set the PS handover allowed (psHoAllowed) parameter.

• Set the Target cell Id in UTRAN CGI of related neighborcell (uTargetCid) parameter.

• Set the Single radio voice call continuity allowed(srvccAllowed) parameter.

Deactivating LTE872: SRVCC to WCDMA

Before you start


Steps

Expected outcome

LTE872: SRVCC to WCDMA is deactivated.






c) Set the Activate SRVCC to WCDMA (actSrvccToWcdma) parameter value to false.


44 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


2.13 LTE873: SRVCC to GSM

Purpose

Follow these procedures to activate and deactivate the LTE873: SRVCC to GSM feature.

Activating LTE873: SRVCC to GSM

Before you start


The Activate SRVCC to GSM (actSrvccToGsm) parameter is used to activate the

feature.


• DTM capability (dtm)

• Timer T304 for InterRAT GSM (t304InterRATGsm)

• Supervision timer for handover preparation to GSM

(tS1RelPrepG)

• Single radio voice call continuity allowed (srvccAllowed)

• Reference freq list for SRVCC to GSM (refFreqListSrvccGsm)

• Band indicator applied to reference ARFCN (bandIndicator)

• Reference ARFCN (referenceARFCN)

• Reference freq list for SRVCC to GSM (refFreqListSrvccGsm)

•Band indicator applied to reference ARFCN (bandIndicator)


• ARFCN value Geran (arfcnValueGeran)

• ARFCN value list (arfcnValueListGERAN)

• Activate support of conversational voice bearer

(actConvVoice)

• PLMN identity in CGI of GERAN neighbor cell (plmnId)

• MCC (mcc)

• MNC (mnc)

• MNC length (mncLength)

• Location area code (lac)

• Cell identity (ci)• Neighbour GERAN BTS cell identifier (lnAdjGId)

• GERAN neighbor relation identifier (lnRelGId)


SRVCC to GSM :


• LTE10: EPS Bearers for Conversational Voice

The configuration of the following features affects LTE873: SRVCC to GSM :

• LTE490: Subscriber Profile Based Mobility

• LTE784: ANR Inter RAT GERAN


Issue: 01J DN09185979 45

8/18/2019 Fd Rl40 Desc


• LTE442: Network Assisted Cell Change To GSM

• LTE872: SRVCC to WCDMA

Steps

Expected outcome

LTE873: SRVCC to GSM is activated.






c) Set the Activate SRVCC to GSM (actSrvccToGsm) parameter value totrue.This step activates the feature.

d) Set the Supervision timer for handover preparation to GSM(tS1RelPrepG) parameter (optional).

e) Set the Activate support of conversational voice bearer

(actConvVoice) parameter value to true (optional).f) Under LNBTS object create or select LNADJG object, and set the followingparameters (optional):

• DTM capability (dtm)

• ARFCN value Geran (arfcnValueGeran)

g Note: For the full configuration of LNADJG object, seeLTE442 Network Assisted Cell Change to GSM .

g) Under LNBTS object create or select MODPR object. Under the MODPR objectcreate Reference freq list for SRVCC to GSM, and set the following parameters(optional):

• Band indicator applied to reference

ARFCN (bandIndicator)


h) Under LNBTS object create or select MOPR object. Under the MOPR objectcreate Reference freq list for SRVCC to GSM, and set the following parameters(optional):

• Band indicator applied to reference

ARFCN (bandIndicator)



46 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


3 Expand the LNBTS object, and select the LNCEL object (optional).

a) Set the Timer T304 for InterRAT GSM (t304InterRATGsm)parameter.

b) Under the LNCEL object select or create the LNHOG object. Set the ARFCN

value list (arfcnValueListGERAN) parameter.

g Note: For the full configuration of the LNHOG object, seeLTE442 Network Assisted Cell Change to GSM .

c) Under the LNCEL object select or create the LNRELG object. In the LNRELGobject set the following parameters:

• Single radio voice call continuity

allowed (srvccAllowed)

• Location area code (lac)

• Cell identity (ci)

• GERAN neighbor relation identifier (lnRelGId)

Expand the LNRELG object and set PLMN identity in CGI of GERANneighbor cell (plmnId) parameters:

• MCC (mcc)

• MNC (mnc)

• MNC length (mncLength)

Deactivating LTE873: SRVCC to GSM

Before you start


Steps

Expected outcome

LTE873: SRVCC to GSM is deactivated.




a) Set the XX parameter value to YY.


Issue: 01J DN09185979 47

8/18/2019 Fd Rl40 Desc



c) Select the LNBTS object.d) Set the Activate SRVCC to GSM (actSrvccToGsm) parameter value tofalse.

2.14 LTE979: IRC for 2 RX paths

Purpose

Follow these procedures to activate and deactivate the LTE979: IRC for 2 RX paths

feature.

Activating LTE979: IRC for 2 RX paths

Before you start


The Uplink combination mode (ulCombinationMode) parameter is used to

activate the feature.


• GPS connected to system module (gpsInUse)

• BTS network synchronization mode (btsSyncMode)• PRACH high speed flag (prachHsFlag)

Steps



2 Go to the BTS settings page. (Optional)

a) It is recommended to set the GPS connected to system

module (gpsInUse) parameter to true.

b) It is recommended to set the BTS network synchronization

mode (btsSyncMode) parameter to PhaseSync.


48 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc





c) Set the Uplink combination mode (ulCombinationMode) parameter value to IRC.


g Note: PRACH high speed flag (prachHsFlag) can only be set to false if Uplink combination mode (ulCombinationMode) parameter is set toIRC.�

Deactivating LTE979: IRC for 2 RX paths

Before you start


Steps






c) Set the Uplink combination mode (ulCombinationMode) parameter value to MRC.

d) PRACH high speed flag (prachHsFlag) can only be set to true if Uplink combination mode (ulCombinationMode) parameter is set toMRC.

2.15 LTE984: GSM redirect with system information

Follow these procedures to activate and deactivate the LTE984: GSM redirect with

system information feature.


Issue: 01J DN09185979 49

8/18/2019 Fd Rl40 Desc


Activating LTE984: GSM redirect with system information

Before you start



• Activate GSM redirect with system

information (actGsmRedirWithSI)

and

• Activate emergency call via redirection (actEmerCallRedir)

or

• Enable UE context release with redirect (actRedirect)

or



LNBTS parameter:

• Enable UE context release with redirect (actRedirect)


• Activate emergency call via redirection (actEmerCallRedir)

MODRED parameter:

• RAT for redirection (redirRAT)

• Add GSM system information to redirection message

(addGsmSIToRedirMsg)

MORED parameter:

• RAT for redirection (redirRAT)



REDRT parameter:

• RAT for redirection (redirRat)



At least one of the following features need to be activated/configured before activation of

LTE984: GSM redirect with system information:

• LTE22: Emergency Calls handling

• LTE423: RRC Connection Release with Redirect

• LTE562: CS Fallback with redirection

There is no real interdependency between features.

For more detailed information see System impact of LTE984: GSM redirect with system

information.


50 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Steps






c) Set the Activate GSM redirect with system information

(actGsmRedirWithSI) parameter value to true.This step activates the feature.

Deactivating LTE984: GSM redirect with systeminformation

Before you start


Steps






c) Set the Activate GSM redirect with system information(actGsmRedirWithSI) parameter value to false.This step deactivates the feature.


Issue: 01J DN09185979 51

8/18/2019 Fd Rl40 Desc


2.16 LTE1387: Intra eNodeB inter-frequency LB

Purpose

Follow these procedures to activate and deactivate the LTE1387: Intra eNodeB inter-

frequency LB feature.

Activating LTE1387: Intra eNodeB inter-frequency LB

Before you start

The following feature needs to be activated/configured before activation of LTE1387:

Intra eNodeB inter-frequency LB:

LTE55: Inter-frequency handover

The parameter actIfHo must be set to enabled.

The parameters IFLBLoadThresholds,thresholdRsrpIFLBFilter,

thresholdRsrqIFLBFilter must be provided with values.


Steps


LTE features using BTS Site Manager .In Step 3 (Modify the feature-specific eNB configuration settings) of the generalprocedure perform the steps described in this procedure.




c) Set the Activation of inter frequency load balancing(IFLB)(actinterFreqLB) parameter value to true.This step activates the feature.

Deactivating LTE1387: Intra eNodeB inter-frequency LB

Before you start


52 DN09185979 Issue: 01J

http://localhost/var/www/apps/conversion/tmp/scratch_5/fd_rl20_desc-0900d80580a0365f.pdf

8/18/2019 Fd Rl40 Desc


Steps






c) Set the Activation of inter frequency load balancing

(IFLB)(actinterFreqLB) parameter value to false.

This step deactivates the feature.


Issue: 01J DN09185979 53

8/18/2019 Fd Rl40 Desc


3 Descriptions of radio resource managementand telecom features

3.1 LTE46: Channel Aware Scheduler (UL)Introduction to the feature

With Channel Aware Scheduler (UL), the evolved Node B supports channel aware uplink

scheduling in the frequency domain.

3.1.1 Benefits

The feature provides an improved uplink cell capacity.

3.1.2 Requirements

Software requirements

Table 3: Software requirements lists the software required for this feature.

System release

Flexi Multiradio BTS

Flexi Multiradio 10

BTS

iOMS

RL40 LBTS4.0 LBTS4.0 OMS4.0

Table 3 Software requirements

UE

NetAct

MME

SAE GW

OSS5.4 CD2 - -

Hardware requirements

This feature requires no new or additional hardware.

3.1.3 Functional description

With the LTE46: Channel Aware Scheduler (UL), the eNB provides an improved UL cell

capacity, allocating the PUSCH PRBs with the best channel conditions for the UEs

pending for scheduling. The eNB evaluates the Channel State Indicator (CSI) of the UEs

in which both the Sounding Reference Signal (SRS) and PUSCH transmission are taken

into account for an improved estimation of the channel quality. Based on these

measurements Channel Aware Scheduler (UL) optimally allocate the PRBs for the UEs

in the frequency domain.

The Channel Aware Scheduler (UL) is an alternative scheduling approach to the

Channel unaware UL scheduling and the LTE619: Interference aware UL scheduling.

Descriptions of radio resource management andtelecom features


54 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The Scheduling method of the UL scheduler (ulsSchedMethod)

parameter defines the scheduling method which is applied in the cell for the UL branch.

Three methods can be chosen:

• channel unaware (0)• channel aware (1)

• interference aware (2)

SRS Configuration

With the Channel Aware Scheduler (UL) capable SRS configurations are defined. The

SRS configurations take into account the conditions of the eNB and provide

measurements sufficient for the favorable scheduling of the UEs by two SRS classes

which are introduced with the feature:

• SRS class that assigns a multitude of SRS resources for a limited number of UEs

• SRS class that provides sufficient SRS resources for the proper scheduling of the

UEs

The operator can choose a SRS configuration from a given set of predefined

configurations tailored for the usable PUSCH spectrum (configuring the

srsConfiguration parameter; for more details, see Reference documentation). The

SRS resources which are selected for the UEs are assigned by means of the RRC

Connection Reconfiguration and RRC Connection Reestablishment messages.

The usage of measurements from SRS in closed loop uplink power control can be

enabled/disabled by setting the parameter Include SRS measurements In CL

power control (ulpcSrsEn) to true or false, accordingly.

PRB allocation

The PRB assignment procedure starts in each subframe at a certain starting point in the

PUSCH spectrum with the UE which offers the best channel conditions expressed by the

average relative signal strength parameter and continues the assignment of the physical

resources sequentially. Whenever the next UE has to be placed in the PUSCH, the

scheduler selects the UE with the best average relative signal strength related to the

next free PRBs from the set of the remaining UEs.

Furthermore, Channel Aware Scheduler (UL) improves the cell capacity by separating of

the PUSCH areas in adjacent cells. The PUSCH is split into PUSCH scheduling areas of

approximately equal size and the scheduler defines the best PUSCH scheduling area

with respect to the average interference and noise power.

3.1.4 System impact

Interdependencies between features

There are no interdependencies between this and any other feature.

Impact on interfaces

This feature has no impact on interfaces.

Impact on network and network element management tools

This feature has no impact on network management or network element management

tools.

Impact on system performance and capacity

LTE RL40, Feature Descriptions and Instructions Descriptions of radio resource management andtelecom features

Issue: 01J DN09185979 55

8/18/2019 Fd Rl40 Desc


Channel aware scheduling improves the average multi-user cell throughput.

3.1.5 Management data

For information on alarm, counter, key performance indicator, and parameter documents,

see Reference documentation.

Alarms

There are no alarms related to this feature.

Measurements and counters

There are no measurements or counters related to this feature.

Key performance indicators

There are no key performance indicators related to this feature.

Parameters

Table 4: New parameters lists parameters introduced with this feature.

Table 4 New parameters

Full name

Abbreviated name

Managed object

SRS Configuration srsConfiguration LNCEL

Include SRS measurements In CL

power control

ulpcSrsEn LNCEL

Table 5: Modified parameters lists parameters modified by this feature.

Range of the srsConfiguration parameter depends on ulChBw. For more details,


If ulpcSrsEn is set to false, srsPwrOffset must not be defined.

Table 5 Modified parameters

Full name

Abbreviated name

Managed object

Scheduling method of the UL scheduler ulsSchedMethod LNCEL

Table 6: Related existing parameters lists existing parameters related to this feature.

If ulsSchedMethod parameter is set to channel aware, srsConfiguration

parameter must be configured.

If ulsSchedMethod parameter is set to channel aware, srsPwrOffset parameter

must be configured.

if ulsSchedMethod parameter value is other that channel aware, ulpcSrsEn

parameter must be set to false.



56 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


f ulsSchedMethod parameter is set to channel aware or interference aware,

ulsFdPrbAssignAlg parameter must be set to Mixed FD.

if ulsSchedMethod is set to channel aware or interference aware, Periodic PHR

timer (PeriodicPhr) must be set to value different from infinity.

Table 6 Related existing parameters

Full name

Abbreviated name

Managed object

Power offset for SRS transmission

power calculation

srsPwrOffset LNCEL

3.1.6 Sales information

Table 7 Sales information

BSW/ASW

License control in network element

License control attributes

ASW - -

3.2 Description of LTE48: Support of high speed users

Introduction to the featureThanks to LTE48: Support of high speed users the evolved Node B (eNB) is able to

handle user equipment’s speed (UE) of up to 350 km/h in open space and 300 km/h in

tunnels.

3.2.1 Benefits

End-user benefits

This feature enables end-users using LTE network even if their speed in relation to the

eNB is up to 350km/h.

Operator benefits

This feature allows to serve more UEs.

3.2.2 Requirements



System release


Flexi Multiradio 10 BTS

iOMS

RL40 LBTS4.0 LBTS4.0 OMS4.0 (RL40)


Issue: 01J DN09185979 57

8/18/2019 Fd Rl40 Desc



UE

NetAct

MME

SAE GW

3GPP R8 mandatory OSS5.4 CD2 - -




Functional overview

The eNB supports high speed users up to maximum doppler spread (Fd) of 700 Hz and

a maximum doppler shift/offset (Fo) of 1400 Hz.

LTE48: Support of high speed users can be considered in two scenarios:

• Scenario with doppler spread: mainly non-line-of-sight (NLOS) scenarios where

there is no frequency offset (Fo=0) due to the velocity of the UE but the UE moves

with a certain velocity in a scattering environment leading to a doppler spread (Fd >

0). The maximum Fd is computed as follows (simplified formula):

Fd [Hz] = Fc [GHz] x V [km/h] x 0.926

where Fc - the carrier frequency, v - the velocity of the UE.

• Scenario with doppler shift/offset: mainly line-of-sight (LOS) scenarios where the

mobile has a velocity component into the direction of the eNB. Typical scenarios like

this are found in high speed trains, where the eNB is located near to the tracks or

some highway-scenarios, where cars go fast and the eNB is also located quite near to the highway. The simplified formula to calculate frequency offset is:

Fo [Hz] = 2 x Fc [GHz] x V [km/h] x 0.926

All requirements for both scenarios are listed in 3GPP RAN4, TS36.104 (section 8.2.1for

the scenario with doppler spread and section 8.2.3 for the scenario with doppler

shift/offset).

Table 9: Maximum supported velocities depending on the carrier frequeny shows an

overview of the maximum velocities that the eNB supports depending on the carrier

frequency.

Table 9 Maximum supported velocities depending on the carrier frequeny

Fc [GHz]

max V [km/h]

Fd

Fo

0.7 1079 700 1400

0.8 944 700 1400

0.9 839 700 1400

1.8 420 700 1400

2.1 360 700 1400



58 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 9 Maximum supported velocities depending on the carrier frequeny (Cont.)

Fc [GHz]

max V [km/h]

Fd

Fo

2.6 291 700 1400

Configuring LTE48: Support of high speed users

It is possible to configure a cell to support high-speed users by setting PrachHsFlag to

true. It makes that restricted set for physical random access channel (PRACH)

preambles is used and the PRACH radio receiver (Rx) algorithm is changed to high

speed receiver. In addition, the PRACH high speed receiver produces some frequency

offset estimation for each UE. These estimations are important to receive the following

PRACH msg3 on physical uplink shared channel (PUSCH).

g Note: When the eNB uses restricted set for PRACH preambles, the cell range is up to

33 km.

HsScenario is the second parameter, which configures LTE48: Support of high speed

users. It can have the following values:

• Scenario 1: when this value is selected Uplink physical layer (UL PHY) mainly

assumes that the cell should work for high speed users with either high Doppler

spread (up to 700 Hz) or high Doppler offset (up to 1400Hz).

Concerning the high Doppler offset the receiver is optimized for the RAN4 highspeed

train scenario 1.

• Scenario 3: when this value is selected UL PHY mainly assumes that the cell should

work for high speed users with either high Doppler spread (up to 700 Hz) or high

Doppler offset (up to 1400Hz).

Concerning the high Doppler offset the receiver is optimized for the RAN4 highspeed

train scenario 3.

• None of these scenarios should be selected if there is neither a big Doppler spread

(around 100Hz) nor a big Doppler offset (around 200Hz) expected. UL PHY does not

correct a fast time varying channel, for example within channel estimation.

g Note: It is recommended to have at least a periodic channel quality indicator (CQI)

configuration of 40 ms.

3.2.4 System impact







tools.



Issue: 01J DN09185979 59

8/18/2019 Fd Rl40 Desc


This feature enables handling UEs, which speed is up to 350 km/h in open space and

300 km/h in tunnels.




Alarms






Parameters



Full name

Abbreviated name

Managed object

High speed Scenario HsScenario LNCEL



Full name

Abbreviated name

Managed object

PRACH high speed flag PrachHsFlag LNCEL



BSW/ASW



ASW - -

3.3 LTE440: S1 Overload HandlingIntroduction to the feature



60 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


With LTE440: S1 Overload Handling feature an evolved Node B (eNB) can support

overload handling for:

• single MME

• MMEs in pool

• multiple MME pools (RAN sharing configuration)

3.3.1 Benefits

End-user benefits

This feature does not affect the end-user experience.

Operator benefits

LTE440: S1 Overload Handling feature ensures stable system operation in case of

MME overload by limiting load increase in a pool/single MME.

3.3.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

3GPP R8 OSS5.4 CD2 - -




MME can report its load situation to an eNB sending one of two messages:

• S1AP: OVERLOAD START

• S1AP: OVERLOAD STOP

The MME that is experiencing overload sends an S1AP: OVERLOAD START message

to either all of its eNBs or a set of its eNBs selected at random. MMEs can adjust: the

number of eNBs that are sent the S1AP: OVERLOAD START message, and the

instructions contained in this message. Following the eNB instructions can be included:

•

reject all RRC connection establishments for non-emergency mobile-originated datatransfer


Issue: 01J DN09185979 61

8/18/2019 Fd Rl40 Desc


• reject all RRC connection establishments for signaling

• permit only RRC connection establishments for emergency sessions and mobile-

terminated services

The MME sends S1AP: OVERLOAD STOP message to the eNB to indicate that the

overload situation has ended and normal operation can be resumed.

User scenarios

The scenarios presented in this section describe how a UE is handled when entering a

cell controlled by an eNB that received an overload message from one of its two

connected MMEs.

UE enters a cell without a valid MME identifier

Connection establishment procedure for above preconditions consist of the following

steps:

• The UE sends theRRCConnectionRequest containing a random value (no MMEidentifier) and the establishmentCause.

• The eNB recognizes that it must complete the RRC Connection Setup procedure to

get routing information from the UE and sends the RRCConnectionSetup

message.

• The UE confirms the setup of RRC connection by sending the

RRCConnectionSetupComplete message that contains PLMN identifier.

• The eNB finds all MMEs that support the provided PLMN identifier. In this case both

MME A and MMEB.

• The eNB selects MME A or MMEB for the new S1 connection using the load balancing

algorithm.

• If the eNB selects MME A and theestablishmentCause provided by the UE is inthe list of blocked causes sent by MME A inOverload Start message, the eNB

will send RRCConnectionRelease message. All the UE-related resources are

released (see Figure 1: Rejection of RRCConnectionRequest message (no MME

identifier provided) because MME overload).

• If the eNB selects MME A and theestablishmentCause provided by UE is not in

the list of blocked causes sent by MME A inOverload Start message, the eNB

sends the S1AP: Initial UE message to MME A (see Figure 2: Acceptance of

RRCConnectionRequest (no MME identifier provided) with one MME in overload

state).

• If the eNB selects MMEB it will send the S1AP: Initial UE message to that MME

(see Figure 2: Acceptance of RRCConnectionRequest (no MME identifier provided)with one MME in overload state).



62 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 1 Rejection ofRRCConnectionRequest message (no MME identifier provided) because MME overload

UE eNB

MME A

MME B

S1AP: Overload Start

RRC: RRCConnectionRequest

(random value, establishment cause)

RRC: RRCConnectionSetup

RRC: RRCConnectionRelease

RRC: RRCConnectionComplete

Figure 2 Acceptance ofRRCConnectionRequest (no MME identifier provided)with one MME in overload state

UE eNB

MME A

MME B



(random value, establishment cause)



S1AP: InitialUEMessage

UE with a valid MME identifier

• The UE sends theRRCConnectionRequest containing an S-TMSI (including a

relevant MME Code) and the establishmentCause message.

• The eNB extracts the MME Code and finds MME A by searching through the list of connected MMEs.

• The eNB compares the establishmentCause of the UE with the list of blocked

establishment causes of MME A.

• If theestablishmentCause of the UE is in the list of blocked establishment

causes of MME A the eNB sends RRCConnectionReject message containing the

waiting time for the UE and releases UE-related resources (see Figure 3: Rejection

of RRCConnectionRequest message (MME identifier provided) because of MME

overload).


Issue: 01J DN09185979 63

8/18/2019 Fd Rl40 Desc


• If theestablishmentCause of the UE is not in the list of blocked establishment

causes of MME A eNB performs the normal RCC Connection Setup procedure.

Finally the eNB sends the S1AP: Initial UE message to establish S1 connection

(see Figure 4: Acceptance of RRCConnectionRequest (MME identifier provided) withMME in overload state).

If the eNB rejects RRC connection, UE repeats the procedure after expiration of

specified waiting time.

Figure 3 Rejection ofRRCConnectionRequest message (MME identifier provided) because of MME overload

UE eNB

MME A

MME B


RRC: RRCConnectionRequest(MME code, establishment cause)



Wait time

Figure 4 Acceptance ofRRCConnectionRequest (MME identifier provided) with

MME in overload stateUE eNB

MME A

MME B



(MME code, establishment cause)



S1AP: InitialUEMessage

3.3.4 System impact


There are no prerequisite features for LTE440: S1 Overload Handling.


With this feature active the eNB will support the following Class 2 procedures:



64 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• Overload Start (S1AP: Overload Start message)

• Overload Stop (S1AP: Overload Stop message)


This feature allows to avoid network congestion by reducing the rate of sending packets

on an overloaded S1-MME link.


System resilience is improved.




AlarmsThere are no alarms related to this feature.





Parameters



Full name

Abbreviated name

Managed object

Activate S1 overload handling actS1OlHandling LNBTS



BSW/ASW



BSW - -

3.3.7 Configuration

LTE440: S1 Overload Handling can be deactivated by setting actS1OlHandling

parameter to “false”.


Issue: 01J DN09185979 65

8/18/2019 Fd Rl40 Desc


3.4 LTE494: Commercial Mobile Alert System

Introduction to the feature

With Commercial Mobile Alert System, it is possible to broadcast commercial warning

information to many UEs as quickly as possible.

3.4.1 Benefits

The operator is able to a support public warning service.

3.4.2 Requirements



System release


Flexi Multiradio 10

BTS

iOMS



UE

NetAct

MME

SAE GW

3GPP R9 UE

capabilities

OSS5.4 CD2 - -




The purpose of CMAS is to broadcast commercial warning information to many mobile

terminals as quickly as possible. The CMAS notification is sent by the MME to the eNBusing WRITE-REPLACE WARNING REQUEST message. UEs in RRC_IDLE and in

RRC_CONNECTED are informed by paging about the presence of CMAS notifications.

The warning notification contained in the WRITE-REPLACE WARNING REQUEST

message received by eNB is mapped to SIB12 and it is broadcasted to all active and idle

UEs.

The following scenarios are possible:

1. The eNB starts the broadcast.



66 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


When consistent WRITE-REPLACE WARNING REQUEST message is sent from

EPC via MME to eNB. If there are no inconsistencies, the eNB identifies the cells to

which sends the warning message, and starts the broadcast. The eNB

acknowledges the broadcast initiation by sending WRITE-REPLACE WARNING

RESPONSE message via MME to EPC.

If the received WRITE-REPLACE WARNING REQUEST message is inconsistent,

the eNB sends ERROR INDICATION message back to the MME from which the

WRITE-REPLACE WARNING REQUEST message was received.

2. The eNB stops the broadcast.To abort the broadcast of a warning message EPC can send a KILL REQUEST via

MME to eNB. The WRITE-REPLACE WARNING REQUEST content which is

included in the KILL REQUEST, is no longer broadcasted. Other warnings that have

been concurrently broadcasted in SIB12 are not terminated. The KILL RESPONSE

message is send back from eNB via MME to EPC. If the received KILL REQUEST

message is inconsistent, the eNB sends ERROR INDICATION message back to the

MME from which the KILL REQUEST message was received.

The eNB also stops broadcasting WRITE-REPLACE WARNING REQUEST

message when the message was sent the specified number of times.

The operator can activate or deactivate Commercial Mobile Alert System by setting the

parameter actCMAS (Activation CMAS support) to True or False accordingly.

The parameter pwsWithEmAreaId (PWS with emergency area ID) indicates if

the CMAS uses Emergency Area IDs to indicate in the WRITE-REPLACE WARNING

REQUEST message in which cells the warning is broadcasted.

• If a Warning Message including Emergency Area IDs is received by the eNB and the

parameter pwsWithEmAreaId is set to False, this Warning Message is not

broadcasted by the eNB.• IfpwsWithEmAreaId parameter is set to True, the configuration of emAreaId

parameter is required.

An Emergency Area ID may be used in signaling messages received via S1 interface to

indicate the set of cells which has the emergency impact (has to broadcast the warning

message). The parameter emAreaId (Emergency area ID) identifies the

Emergency Area ID of the eNB cell.

3.4.4 System impact


It is not possible to enable LTE494: Commercial Mobile Alert System feature andLTE843: ETWS broadcast feature simultaneously per one eNB.





tools.


This feature has no impact on system performance or capacity.


Issue: 01J DN09185979 67

8/18/2019 Fd Rl40 Desc


8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

SI window length siWindowLen LNCEL



BSW/ASW



ASW - -

3.5 LTE495: OTDOAIntroduction to the feature

The evolved node B supports OTDOA (Observed Time Difference of Arrival). The

location method OTDOA provides an improved location accuracy.

3.5.1 Benefits

The operator is able to provide location services better than cell ID where GPS

positioning is not working .

3.5.2 Requirements



System release


Flexi Multiradio 10

BTS

iOMS



UE

NetAct

MME

SAE GW

3GPP R9 UE

capabilities

OSS5.4 CD2 - -



Issue: 01J DN09185979 69

8/18/2019 Fd Rl40 Desc


GPS receiver is required.


Observed time difference of arrival (OTDOA) is one of the types of Location Services

(LCS) features. The support of LCS allows to determine the position of a UE within the

RAN. The network is able to localize a UE usually within the 2D grid (x and y dimension).

In LTE495:OTDOA, special signals in the DL are introduced (positioning reference

signals (PRS). The UEs are able to detect the PRS and derive measurements based on

the PRS (this ability will be described in the rest of the document as hereability).

In principle there are three unknowns, that is x, y and one absolute time or equivalently

one absolute distance to one of the eNBs. These unknowns can be obtained via time

difference measurements as shown in the Figure 5: OTDOA overview

Figure 5 OTDOA overview

The UE measures OTDOA of each

neighbor it detects relative to the serving cell

Cell 3

T1

Serving

eNB

Cell 2

T2

T3

iGMLC

E-SMLC/SLP

OTD = Observed Time Difference

PCI = Physical Cell IDMeasurement report:

T1-T2; Cell ID of cell2

T1-T3; Cell ID of cell3

Location server knows:

- location of each cell’s transmit antenna

- relative transmit frame timing of each cell

In this case the UE receives PRS from three cells, the serving cell, cell 1 and cell 2. The

serving cell, cell 1 and cell 2 must be synchronized. The UE takes the received timing of

the PRS from the serving cell as a reference and measures the time difference to the

PRS received from the other cells. If the UE is able to receive the PRS from 3 eNBs it

could happen that there is no unique solution for the equation system and some

assistance information needs to be used to sort out the correct position. If the UE is able

to receive the PRS from 4 or more eNBs the system is overdetermined as the number of

measurements is greater than the number of unknowns and one unique solution exists.

The UE is informed about the PRS configuration via the LPP (LTE Positioning Protocol).

The LPP is a protocol defined between the UE and the E-SMLC (enhanced Serving

Mobile Location Centre). It communicates the PRS settings of the network to the UEs as

well as the OTDOA measurements also called RSTD (reference signal time difference)

from the UEs to the E-SMLC. The LPP protocol entities are transparent to the eNBs and

the computation of the UE positions are done in the E-SMLC. The operator needs to

provide PRS settings of the network and antenna positions of eNBs to the E-SMLC.

Configuration



70 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The feature can be activated or deactivated by setting the actOtdoa to true or false

accordingly. When the feature is activated the following parameters have to be

configured:

• PRS Power Boost (prsPowerBoost)

Power Boosting for PRS increases hearability and allows for a more flexible use of

the DL Tx power

• PRS Configuration Index (prsConfigurationIndex)

Determines the periodicity and offset of the PRS occasions

• PRS Bandwidth (prsBandwidth)

The parameter determines on which resource blocks PRS is present within a PRS

subframe

• PRS Number of DL Frames (prsNumDlFrames)

The parameter specifies the number of consecutive downlink subframes with PRS.

With this PRS transmission can be repeated within a PRS occasion to increase the

hearability of PRS.

• PRS Tx Diversity Enable (actPrsTxDiv)

If Tx Diversity is enabled for PRS transmission, then precoding vector switching is

used and hence all configured Tx antennas are used for the transmission of the PRS

signal. If Tx diversity is disabled then the PRS signal is transmitted on a single

antenna (the physical antenna corresponding to antenna port {0}).

• SI window length (siWindowLen)

If the eNB supports OTDOA, the siWindowLength parameter is restricted to a

size, that guarantees a periodic gap in the system information broadcast schedule.

This gap is used for transmission of PRS. For details, see Reference documentation.

Furthermore, the parameter prsMuting defines the PRS Muting pattern that is

applied. Muting will be deactivated if the parameter is omitted. The structure contains the

following parameters:

• PRS muting info (prsMutingInfo) is a bit string consisting of 16 bit. Only the

first prsMutingInfoPatternLen bits will be taken into account starting from the

most significant bit (MSB). This means the first prsMutingInfoPatternLen bits

of the prsMutingInfo bit string will determine the PRS Muting Info pattern with a

given periodicity. Details of the description can be found in TS36.355. Muting

configuration allows to increase the reuse of the PRS signal. PRS of individual cells

can be muted to increase hearability of cells with the same frequency reuse.

• PRS muting info pattern length (prsMutingInfoPatternLen)

determines the number of bits that are used to describe the PRS Muting info

starting from the most significant bit (MSB) of the bit string with size 16 bit.

The parameter Max phase drifting (maxPhaseDrifting) defines maximum

allowed drifting value for the eNB timing source phase synchronization.

3.5.4 System impact


LTE80: GPS Synchronization must be enabled.


This feature impacts on air interface due to PRS transmission. Effects are described in

Impact on system performance and capacity chapter.



Issue: 01J DN09185979 71

8/18/2019 Fd Rl40 Desc



tools.


This feature reduces the number of available resource elements for DL traffic hence

affecting the DL throughput. Depending on the configuration the overhead at full data

traffic can vary. With default configuration the overhead at full usage of PDSCH reaches

approximately 0.6% (the overhead can increase if not the smallest PRS configuration is

used).




Alarms






Parameters



Full name

Abbreviated name

Managed

object

Structure

Max phase drifting maxPhaseDrifting BTSSCL

PRS activation actOtdoa LNCEL

PRS Tx diversity activation actPrsTxDiv LNCEL

PRS bandwidth prsBandwidth LNCEL

PRS configuration index prsConfigurationIndex LNCEL

PRS muting prsMuting LNCEL

PRS muting info prsMutingInfo LNCEL prsMuting

PRS muting info pattern length prsMutingInfoPatternLen LNCEL prsMuting

PRS Number of DL frames prsNumDlFrames LNCEL

PRS power boost prsPowerBoost LNCEL



72 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Parameter relationships:

• IfbtsSyncMode is set to PhaseSync, maxPhaseDrifting must be configured.

• IfactOtdoa is set to true:

– siWindowLen must be set appropriately depending on the individual PRS

configuration. For details on appropriate values, refer to parameter

siWindowLen in Reference documentation

– configuration of the following parameters is required: prsPowerBoost,

prsConfigurationIndex, prsBandwidth, prsNumDlFrames,

actPrsTxDiv

• IfnumOfTxPorts is set to 1, actPrsTxDiv must be set to false.

If actPrsTxDiv is set to true:

– drxProfile2-drxOnDuratT must be greater than 3

– drxProfile3-drxOnDuratT must be greater than 3

• prsBandwidth range depends on thedlChBw.



Full name

Abbreviated name

Managed

object

Structure


DRX on duration timer drxOnDuratT LNCEL drxProfile2,

drxProfile3



BSW/ASW



ASW - -

3.6 LTE496: Support of QCI 2, 3 and 4Introduction to the feature

This feature LTE496: Support of QCI 2,3 and 4 allows the operator to offer GBR

(guaranteed bit rate) features with higher bit rates as the QCI = 1 service.


Issue: 01J DN09185979 73

8/18/2019 Fd Rl40 Desc


The QCI (QoS class identifier) is an index that identifies a set of locally configured values

for three QoS (quality of service) attributes: priority, delay and loss rate. The QCI is

signalled instead the values of these parameters. Nine pre-configured classes have been

specified on two categories of bearers, GBR and Non-GBR bearers. In addition

operators can create their own classes that apply within their network.

Table 24: Standardized QCI characteristics lists the standardized QCI definitions

specified in 3GPP TS 23.203 v9.7.0.

Table 24 Standardized QCI characteristics

QCI

Resource

type

Priority

Packet delay

budget

(NOTE 1)

Packet error

loss rate

(NOTE 2)

Example services

1(NOTE 3)

GBR 2 100 ms 10-2

Conversational voice

2

(NOTE 3)

4 150 ms 10-3 Conversational video (live streaming)

3

(NOTE 3)

3 50 ms 10-3 Real time gaming

4

(NOTE 3)

5 300 ms 10-6 Non-Conversational video (buffered

streaming)

5

(NOTE 3)

Non-GBR 1 100 ms 10-6 IMS signaling

6

(NOTE 4)

6 300 ms 10-6 Video (buffered streaming)

TCP-based (e.g., www, e-mail, chat, ftp,

p2p file sharing, progressive video, etc.)

7

(NOTE 3)

7 100 ms 10-3 Voice, video (live streaming), interactive

gaming

8

(NOTE 5)

8 300 ms 10-6 Video (buffered streaming)

TCP-based (e.g., www, e-mail, chat, ftp,

p2p file sharing, progressive video, etc.)

9

(NOTE 6)

9

NOTE 1:

A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive

the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is

located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio base

station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast

is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting



74 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 24 Standardized QCI characteristics (Cont.)

QCI

Resourcetype

Priority

Packet delaybudget

(NOTE 1)

Packet error loss rate

(NOTE 2)

Example services

this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also,

note that the PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically be lower

than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.

NOTE 2:

The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be

regarded as negligible. A PELR value is specified for a standardized QCI therefore applies completely to the radio

interface between a UE and radio base station.

NOTE 3:

This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink /

downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is

the point in time when a corresponding dedicated EPS bearer is established / modified.

NOTE 4:

This QCI could be used for prioritization of specific services according to operator configuration.

NOTE 5:

This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber /

subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at the point in time

when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for

"premium subscribers".

NOTE 6:

This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used

as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI

on the default bearer.

g Note: Operator hint

When using the LTE496: Support of QCI 2,3 and 4 or LTE497: Smart Admission Control

it is highly recommended to set the following parameters:

• Enable restricted PRB assignment in uplink (reBwRpaEnUl)

•Enable reduced bandwidth DL (redBwEnDl)

to false. Otherwise, the packet scheduler limits the number of PRBs/TTI scheduled for

all UEs to the value configured with redBwMaxRbUl resp.redBwMaxRbDll and it

might be impossible to reach the high bit rates, which are expected to reach with

LTE496/LTE497.

3.6.1 Benefits

End-user benefits


Issue: 01J DN09185979 75

8/18/2019 Fd Rl40 Desc


This feature benefits the end user as follows: The end user can use the QCI (QoS class

identifier) 2,3 and 4. The resource types of these QCIs are all GBR, with higher

supported guaranteed bit rates (compared to QCI =1). The maximum guaranteed bit rate

is operator configurative with the maximum limit DL of 2Mbps and the maximum limit UL

of 512 kbps.

Operator benefits

This feature benefits the operator as follows: the operator can offer services with QCI 2,3

and 4 with higher GBRs than the QCI = 1 service.

3.6.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW





Functional overview

The eNB supports the following QCI values in RL40:

• QCI values 1..9 (accordingly 3GPP TS 23.203 v9.7.0, Table 24: Standardized QCI

characteristics)

• QCI values 128..254 (accordingly LTE518: Operator specific QCI)

This feature description LTE496: Support of QCI 2,3 and 4 handles bearers with QCI

value 2, 3 and 4. Accordingly 3GPP TS 23.203 v9.7.0, Table 24: Standardized QCI

characteristics these are GBR bearers.

The eNB targets to enforce the delay targets for the QCIs according to 3GPP ( Table 24:

Standardized QCI characteristics). To reach this goal the parameter delay_target

can be configured for each QCI (as part of the structure qcitab2, qcitab3, qcitab4). This

parameter is the maximum packet delay value used by the eNB MAC scheduling

algorithm.



76 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The maximum guaranteed bit rate is operator configurative by the parameter

maxGbrDlwith the maximum limit DL of 2Mbps and the parameter maxGbrUl with the

maximum limit UL of 840 kbps. These values define the maximum GBR values on the S1

interface that will be admitted by the eNB. Requests for the establishment of bearers with

higher GBR are rejected.

Furthermore these high bit rates can cause congestion. To prevent congestion on

guaranteed resources the LTE497: Smart admission Control feature is introduced. In

addition, congestion handling is supported which is based on congestion detection on

cell level (on PDSCH, PUSCH as well on PDCCH) as soon as the resource usage for the

guaranteed bit rate bearers exceed a configurative load limit (Parameter

maxGBRTrafficLimit).

The congestion handling in the eNB is configurative via the Parameter

gbrCongHandling. (Table 26: Congestion Handling configured by gbrCongHandling.)

Table 26 Congestion Handling configured by gbrCongHandling.

Value

Congestion Handling

0 no congestion handling

1 congestion handling within layer 2 only by applying congestion

priorization of bearers according to the congestion weight (Parameter:

congWeightAlg)

2 congestion handling on layer 2 and layer 3 by dropping bearers in

accordance with selection criteria defined in LTE534: ARP based

Admission Control for E-RABs

The Parameter congWeightAlg defines a priorization behaviour in layer 2 (MAC)

until either the congestion situation ends or until the congestion situation is resolved by

higher layers. There are two different algorithms possible:

• qciPrio: Bearers are prioritized in order of their QCI priority.

• arpPrioPerVul: First bearers with ARP vulnerability “preemptable” are prioritized in

order of the ARP priority, then the bearers with ARP vulnerability “not preemptable”

also in order of ARP priority.

The actual pre-emption is performed in higher layers according to rules and criteria as

beeing defined in LTE534: ARP based admission control.

The features LTE497: Smart Admission Control and LTE534: ARP based admission

control for E-RABs feature decide if an additional bearer (evolved radio access bearer

(E-RAB)) is established or rejected. The decision criteria are taken by the Allocation and

retention priority (ARP).

The features

• LTE496 Support of QCI 2,3 and 4

• LTE497: Smart admission Control

• LTE534: ARP based admission control for E-RABs


Issue: 01J DN09185979 77

8/18/2019 Fd Rl40 Desc


can only be enabled together by setting the actEnhAcAndGbrServices parameter to

true. By enabling this feature bundle only a single GBR bearer per UE is supported. The

establishing of multiple GBR EPS bearers per UE is supported by LTE587: Multiple GBR

bearers per UE and needs to be activated separately.

The number of users which can be supported with a certain guaranteed bit rate is

(considerably) limited. The actual limit depends for example on:

• type of user (mobile versus fixed wireless access)

• cell characteristics

– system bandwidth

– cell size/inter-site distance

• user channel characteristics

– fading profiles

– geometry factors

• QoS requirements

In consequence, it is not possible to give any explicit values regarding the number of

supported users with a certain required rate.

The eNB supports different RLC modes (radio link control modes) for QCI = 4. This is

configurative via the parameter rlcMode of qciTab4. Possible values are RLC_AM

(acknowledged mode) and RLC_UM (unacknowledged mode).

This feature brings also the support of periodic sub-band CQI reporting (channel quality

indicator) on PUCCH. Main benefit of this function is that if the system is dominated by

DL centric UDP traffic on RLC_UM mode, where the number of aperiodic CQI reports is

heavily reduced, the periodic sub-band CQI reports allow to have still some frequency

selective channel quality information.

To derive a guaranteed bit rate in layer 2 the parameters l2OHFactorDl and

l2OHFactorUL are introduced. These parameters specify the overhead factor of the

downlink/ uplink GBR in layer 2. The eNB increases the GBR in downlink/uplink direction

for radio layer 2 by the product of GBR in downlink/uplink direction and L2 Overhead

Factor GBR/100. While those parameters could be optimized to fit to the characteristics

of the traffic being mapped to a certain QCI - if those are really well known - it is

essential that the overhead is always estimated conservatively (that is, the overhead

factor shall correspond rather to the worst case).

The uplink FD scheduler type is determined by the parameter ulsFdPrbAssignAlg.

(Table 27: Parameter ulsFdPrbAssignAlg). If this feature LTE496: Support of QCI 2, 3

and 4 is activated, the parameter ulsFdPrbAssignAlg must be set to 2 (mixed

mode).

Table 27 Parameter ulsFdPrbAssignAlg

value

UL scheduler type

0 round robin: The Round Robin FD scheduler assigns the physical

resources equally fair to the UEs selected by the scheduler until the

PRBs are sufficient for the service or the physical resources of the cell

are exhaust.



78 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 27 Parameter ulsFdPrbAssignAlg (Cont.)

value

UL scheduler type

1 exhaustive: The FD Exhaustive FD scheduler assigns in the priority

sequence defined by the scheduler as many physical resources as

possible to the UEs until the number of PRBs are sufficient for the

service or the resources of the cell are exhaust.

2 mixed: The Mixed FD scheduler is a joint FD scheduler which assigns

the PRBs for SRB and GBR bearers by the exhaustive FD scheduler and

the PRBs for the nonGBR bearers by the Round Robin FD scheduler to

the UEs .

The feature LTE534: ARP based admission control. replaces the permanent admittance(from releases before) by a withdrawable acceptance. In case of a resource limitation,

the eNB may withdraw the admittance from an already admitted E-RAB to use its

resources for admittance of a more important (that is, with higher ARP priority) E-RAB

(evolved radio access bearer).

3.6.4 System impact


The features

• Lte496: Support of QCI 2, 3 and 4

• LTE497: Smart admission Control• LTE534: ARP based admission control for E-RABs

belong together and must be enabled together.

According to LTE587: Multiple GBR EPS bearers per UE , it is possible to establish up to

three GBR- bearers (for QCI 2,3, 4) per UE

The feature

LTE7: Support of multiple EPS bearer

is a prerequisite for these features and must be enabled.

These new features have impact on

• LTE9: Service differentiation

• LTE10: EPS bearers for conversational voice

• LTE144: Transport admission control


This feature impacts interfaces as follows:

NetAct, BTSSM:

• Additional parameters for enabling and configuring the feature

• Additional performance counters


Issue: 01J DN09185979 79

8/18/2019 Fd Rl40 Desc


This feature is managed by the parameters listed in management data.



tools.


This feature impacts system performance and capacity as follows:

• No effect on network connectivity

• Potential reduction of cell capacity

– Impact on cell capacity is determined by the volume, the characteristics and the

QoS parameters of the traffic flows requiring to be handled specifically.

– Cell capacity reduction is due to the amount of traffic with special requirements.

• No effect on network event capacity• No effect on O&M capacity and connectivity




Alarms



Table 28: New counters lists counters introduced with this feature.

Table 28 New counters

Counter ID

Counter name

Measurement

M8001C228 UEs with buffered DL data for QCI2 bearer LTE Cell Load



M8001C271 PDCP SDU delay on DL DTCH Mean for

GBR DRBs of QCI 2

LTE Cell Load


GBR DRBs of QCI 3

LTE Cell Load


GBR DRBs of QCI 4

LTE Cell Load

M8001C315 PDCP SDU DL QCI 2 LTE Cell Load




80 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 28 New counters (Cont.)

Counter ID

Counter name

Measurement


M8001C324 PDCP SDU discarded DL QCI 2 LTE Cell Load



M8006C162 Initial EPS Bearer setup attempts for GBR

DRBS of QCI2

LTE EPS Bearer


DRBS of QCI3

LTE EPS Bearer


DRBS of QCI4

LTE EPS Bearer

M8006C165 Additional EPS Bearer setup attempts for

GBR DRBs of QCI2

LTE EPS Bearer

M8006C166 Additional EPS Bearer setup attempts for

GBR DRBs of QCI3

LTE EPS Bearer

M8006C167 Additional EPS Bearer setup attempts for GBR DRBs of QCI4

LTE EPS Bearer

M8006C168 Initial EPS Bearer setup completions for

GBR DRBs of QCI2

LTE EPS Bearer


GBR DRBs of QCI3

LTE EPS Bearer


GBR DRBs of QCI4

LTE EPS Bearer

M8006C171 Additional EPS Bearer setup completions

for GBR DRBs of QCI2

LTE EPS Bearer



LTE EPS Bearer



LTE EPS Bearer



Parameters


Issue: 01J DN09185979 81

8/18/2019 Fd Rl40 Desc


The following parameters are defined for the workaround for QCI=2,3,4 in RL30 ( Table

29: Parameters for the workaround for QCI = 2,3,4 ) and remain valid:

Table 29 Parameters for the workaround for QCI = 2,3,4

Full name

Abbreviated name

Managed object

Structure

DRX profile index drxProfileIndex MRBTS/LNBTS qciTab2

DSCP dscp MRBTS/LNBTS qciTab2

Logical channel group identifier lcgid MRBTS/LNBTS qciTab2

QCI support qciSupp MRBTS/LNBTS qciTab2

Scheduling bucket size duration schedulBSD MRBTS/LNBTS qciTab2

Scheduling priority schedulePrio MRBTS/LNBTS q ciTab2






Scheduling priority schedulPrio MRBTS/LNBTS qciTab3






Scheduling priority schedulPrio MRBTS/LNBTS qciTab4

RLC profile Id rlcProfileId MRBTS/LNBTS rlcProf102

SN field length downlink snFieldLengthDL MRBTS/LNBTS rlcProf102

SN field length uplink snFieldLengthUL MRBTS/LNBTS rlcProf102

Timer reordering tReord MRBTS/LNBTS rlcProf102

PDCP profile Id pdcpProfileId MRBTS/LNBTS pdcpProf102



82 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 29 Parameters for the workaround for QCI = 2,3,4 (Cont.)

Full name

Abbreviated name

Managed object

Structure

Sequence number size snSize MRBTS/LNBTS pdcpProf102

Timer discard tDiscard MRBTS/LNBTS pdcpProf102

Table 30: New parameters lists parameters related to this feature.


Full name

Abbreviated name

Structure

Managed object

Activate enhanced AC

and GBR services

actEnhAcAndGbrServic

es

MRBTS/LNBTS

Congestion weight

algorithm

congWeightAlg MRBTS/LNBTS

Default profile index AM defProfIdxAM MRBTS/LNBTS

Default profile index UM defProfIdxUM MRBTS/LNBTS

PDCCH LA UL DL priority

tag 1, ..PDCCH LA UL DLpriority tag 16

pdcchUlDlPrioTag1,

..pdcchUlDlPrioTag16

pdcchUlDlPrio MRBTS/LNBTS

PDCP profile id pdcpProfileId pdcpProf103 MRBTS/LNBTS

Sequence number size snSize pdcpProf103 MRBTS/LNBTS

Timer discard tDiscard pdcpProf103 MRBTS/LNBTS

PDCP profile id pdcpProfileId pdcpProf104 MRBTS/LNBTS

Sequence number size snSize pdcpProf104 MRBTS/LNBTS

Timer discard tDiscard pdcpProf104 MRBTS/LNBTS

L2 overhead factor GBR

DL

l2OHFactorDL qciTab2,3,4 MRBTS/LNBTS

L2 overhead factor GBR

UL

l2OHFactorUL qciTab2,3,4 MRBTS/LNBTS

RLC profile id rlcProfileId rlcProf103 MRBTS/LNBTS

SN field length downlink snFieldLengthDL rlcProf103 MRBTS/LNBTS

SN field length uplink snFieldLengthUL rlcProf103 MRBTS/LNBTS


Issue: 01J DN09185979 83

8/18/2019 Fd Rl40 Desc


Table 30 New parameters (Cont.)

Full name

Abbreviated name

Structure

Managed object

Timer reordering tReord rlcProf103 MRBTS/LNBTS

RLC profile id rlcProfileId rlcProf104 MRBTS/LNBTS

SN field length downlink snFieldLengthDL rlcProf104 MRBTS/LNBTS

SN field length uplink snFieldLengthUL rlcProf104 MRBTS/LNBTS

Timer reordering tReord rlcProf104 MRBTS/LNBTS

Periodic CQI subbandscycles cqiPerSbCycK MRBTS/LNBTS/LNCEL

GBR congestion handling gbrCongHandling MRBTS/LNBTS/

LNCEL

Periodic CQI feedback

type

periodicCqiFeedbackTyp

e

MRBTS/LNBTS/

LNCEL

Maximum GBR downlink maxGbrDl qciTab2,3,4 MRBTS/LNBTS

Maximum GBR uplink maxGbrUl qciTab2,3,4 MRBTS/LNBTS

Delay target delayTarget qciTab2,3,4 MRBTS/LNBTS

UL scheduler FD type ulsFdPrbAssignAlg MRBTS/LNBTS/

LNCEL



BSW/ASW



ASW - -

3.7 LTE497: Smart admission ControlIntroduction to the feature

The task of the admission control (AC) is to admit or reject the establishment requests

for new radio bearers (signaling and data radio bearers). In order to do this, AC must

care about

• the resource consumption in a cell



84 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• the QoS requirements of DRBs (data radio bearers)

• levels of access priorities

• intra cell access

• handover access

The goal of AC is to allow high radio resource utilization (by accepting radio bearer

requests as long as radio resources are available) but considering guaranteed

transmission capacity for certain services (GBR traffic) of already admitted users.

This feature LTE497: Smart admission Control has the following characteristics:

• It is a feature enhancement only for GBR traffic and is required to prevent congestion

on “guaranteed” resources.

• The counter based radio admission control is replaced by a measurement based

function which leads to a more accurate and dynamic system behavior. Counting of

used resources and applying statistical methods on load schemes do not work when

serving high bit rate users (using QCI 2, 3, 4).• RAC (radio admission control) needs to predict the load as being caused by each

new GBR radio bearer in the cell reflecting the requested transmission rates (UL/DL)

under given radio conditions and considering the existing GBR load in the cell.

• Smart admission control offers a congesting handling to get rid of traffic (according to

ARP priorities) when an overbooking of resources is detected (in the scheduler):

Overbooking or overload may occur when

– radio conditions of high bit rate users getting worse

– a too optimistic admission was done

– bursting traffic cannot be served over time

• Adoption of transport admission control to consider various bit rates of QCI 2, 3, 4bearers (without congesting handling, without partial admission)

Partial admission means: If more than one DRB shall be admitted (for example 3),

and one of them can not be admitted, then the other 2 are admitted. On the contrary

all-or-nothing means: If more than on DRB shall be admitted (for example 3), and

one of them can not be admitted, all of them are rejected. TAC (transport admission

control) works always in all-or-nothing mode.

• RAC works for UEs in the cell in partial admission mode, for handovers in all-or-

nothing mode.

g Note: Operator hint

When using the LTE496: Support of QCI 2,3 and 4 or LTE497: Smart Admission Control

it is highly recommended to set the following parameters:

• Enable restricted PRB assignment in uplink (reBwRpaEnUl)

• Enable reduced bandwidth DL (redBwEnDl)

to false. Otherwise, the packet scheduler limits the number of PRBs/TTI scheduled for

all UEs to the value configured with redBwMaxRbUl resp.redBwMaxRbDll and it

might be impossible to reach the high bit rates, which are expected to reach with

LTE496/LTE497.


Issue: 01J DN09185979 85

8/18/2019 Fd Rl40 Desc


3.7.1 Benefits

This feature LTE497: Smart admission Control is driven by the introduction of GBR

traffic with QCI 2, 3 and 4, that is with high bit rate demands on single UEs.

End-user benefits

The end user does not see any difference due to the change of a system internal

admission algorithm. His communication request to the network is either admitted or

rejected.

Operator benefits

This feature benefits the operator as follows:

• Radio admission control reacts on measurements and must not consider worst case

scenarios all the time (statistic configuration), that is a more optimal system/resource

availability is expected.• A congestion control function allows more optimistic admission decisions, and the

system corrects overbooking situations using pre-emptions according allocation

priorities on radio interface.

3.7.2 Requirements



System release


Flexi Multiradio 10BTS

OMS



UE

NetAct

MME

SAE GW



This features requires no new or additional hardware.


Functional overview

With the introduction of high bit rate GBR bearer services the counting of resources and

applying statistical methods for admission control is not sufficient anymore and the

probability of congestion in the system increases. Only a few high bit rate users may

consume all radio resources and may lead the system into congestion. Smart admission

control functions work only for GBR traffic.



86 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Resources with respect to signalling bearers, active UEs and numbers of DRBs per cell

are still checked using counters and configured thresholds. For GBR traffic a forecast

calculation on needed resources for a new bearer is done and if there are enough

resources left in the cell the new admission request is admitted, Continuously the radio

resource consumption is measured and admission decisions take the measurements as

base for any decision,

An overview of the interaction of different function blocks is given in Figure 6: Interaction

of different function blocks

Figure 6 Interaction of different function blocks

MM: Radio

bearer

request

BM: Radio

bearer

request

BM: Radio

bearer

release

EPC

RAC

RB req.

RB req.

RB resp..

RB rel.

RB release

req

RB release

req

admitted

congestion

congestion

Admitted Rbs

PRB

allocation

Admitted Rbs

AMC&

IFFT

Measurements

Congestion

detection

Periodically: UE information (average PRB usage UL/DL, transm. efficiency UL/DL,availiable PBRs per system etc. )

Tx

The agenda of Figure 6: Interaction of different function blocks is given in the following

Table 33: Abbreviations of the figure above (starting from the left)

Table 33 Abbreviations of the figure above

Abbreviation

Long name

EPC evolved packet core

MM mobility management

BM bearer management

RAC radio admission control

RB radio bearer

PRB physical resource block

AMC adaptive modulation and coding

IFFT inverse fast fourier transformation


Issue: 01J DN09185979 87

8/18/2019 Fd Rl40 Desc


With the new challenges of the LTE496 with various QCI-dependant bit rates the

interface between eNB and S-GW (S1 interface) is also concerned. The admission

control of the S1 interface is the TAC (transport admission control). TAC works with a

configured packet size per QCI bearer on the S1 interface. The packet rates are

calculated using the requested guaranteed bit rates.

The following thresholds and margins are introduced with this feature (Table 34:

Thresholds and margins):

Table 34 Thresholds and margins

Parameter

Description

maxGbrTrafficLimit Specifies the limit in % of available radio resources.

Reaching the resource - limit ARP based pre-emption

is triggered. If pre-empted DRBs are available the newbearer may be admitted, otherwise it is rejected.

Example: 10Mhz - system => 50 PRBs,

maxGbrTrafficLimit is set to 70%, which leads to a

threshold of 35 PRBs. The remaining 15 PRBs are

reserved for HO traffic and non-GBR traffic and spare

in case of bad radio conditions of certain UEs.

addGbrTrafficRrHo Specifies a bonus margin in case of GBR - DRB

requests for handover with cause “radio reason”. RAC

uses then the threshold (maxGbrTrafficLimit +

addGbrTraffictRrHo)

addGbrTrafficTcHo Specifies a bonus margin in case of GBR - DRBrequests for handover with cause “time critical”. RAC

uses then the threshold (maxGbrTrafficLimit +

addGbrTraffictTcHo)

3.7.4 System impact


The features

• LTE496: Support of QCI 2,3 and 4

•

LTE497: Smart admission Control • LTE534: ARP based admission control for E-RABs

belong together and must be enabled together by setting the

actEnhAcAndGbrServices parameter to true.

The feature

LTE7: Support of multiple EPS bearer

is a prerequisite for these features and must be enabled.





88 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


This feature is managed by the parameters listed in the Management data section.



tools.






Alarms






Parameters



Full name

Abbreviated name

Managed object

Activate enhanced AC and GBR

services

actEnhAcAndGbrServices MRBTS/LNBTS

Add GBR-DRB Traffic for Radio Reason

Handover

addGbrTrafficRrHo MRBTS/LNBTS/L

NCEL

Add GBR-DRB Traffic for Time Critical

Reason Handover

addGbrTrafficTcHo MRBTS/LNBTS/L

NCEL

Maximum GBR-DRB Traffic Limit maxGbrTrafficLimit MRBTS/LNBTS/L

NCEL



BSW/ASW



ASW - -


Issue: 01J DN09185979 89

8/18/2019 Fd Rl40 Desc


3.8 LTE519: eRAB Modification


The eNB allows changing

• the QCI (QoS class indicator) value of non-GBR (guaranteed bitrate) QCIs

• the ARP (allocation and retention priority) value of all QCIs

• the UE-AMBR (aggregate maximum bitrate) of an UE

with the:

• S1AP: E-RAB MODIFY REQUEST

• S1AP: E-RAB MODIFY RESPONSE

message.

3.8.1 Benefits

End-user benefits

The end-user can use sophisticated tariff-models offered by the operator.

Operator benefits

The operator can offer a tariff like this: For the first 20 GB per month the user gets a data

rate of 42 mbps as golden user, for the remaining data he gets 384kbps as bronze user.

• If the user has consumed his data volume (the 20GB), the EPC starts an EPS bearer

modification to downgrade the QoS and bandwidth of the user.• The user can change his subscription, for example from bronze user to golden user.

3.8.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW






90 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Overview

According to 3GPP 23.401 the EPS bearer Modification Procedure is used to modify theQoS parameters QCI, ARP, GBR, MBR and UE-AMBR. Modification from a QCI of

resource type non-GBR to a resource type GBR and vice versa is not supported,

The Figure 7: MSC: E-RAB Modify Request shows the EPS Bearer Modification

procedure for QCI/ARP change triggered by the S1AP message E-RAB MODIFY

REQUEST.

Figure 7 MSC: E-RAB Modify Request

UE eNB MME

S1AP: E-RAB MODIFY REQUEST

S1AP: E-RAB MODIFY RESPONSE

(E-RAB Mod List ( QCI , ARP ,

NAS: MODIFY EPS BEARER CONTEXT REQUEST),

opt. UE-AMBR )

S1AP: UL NAS TRANSPORT

RRC: ULInformationTransfer

(NAS: MODIFY EPS BEARER CONTEXT ACCEPT )

(NAS: MODIFY EPS BEARER CONTEXT ACCEPT )

Local reconfigurations

RRC: RRCConnectionReconfiguration

(drbToAddModifyList,List (NAS: MODIFY EPS BEARER CONTEXT REQUEST))

LCH Reconfiguration&

NAS procedure

RRC: RRCConnectionReconfigurationComplete

MME initiates the procedure for an EPS Bearer Modification for UE-AMBR and optionally

QCI/ARP modification if:

• PDN GW request the modification of an existing EPS bearer by the Update Bearer

procedure (for all QoS parameters) - see [3GPP 23.401]: "PDN GW initiated bearer

modification with bearer QoS update"

• This covers also the case that the ARP values of a default bearer and IMS signaling

bearer are modified to support "Multimedia Priority Services" - see [3GPP 23.401]:

"IMS-based Multimedia Priority Services".

•

HSS initiates the procedure "Insert Subscriber Data" (for default QCI and ARP for default bearers and UE-AMBR). The MME receives the new subscriber data and

may start the EPS bearer modification procedure - see [3GPP 23.401]: "HSS

Initiated Subscribed QoS Modification".

• In both cases, MME sends the S1AP message E-RAB MODIFY REQUEST adding a

NAS PDU "MODIFY EPS BEARER CONTEXT REQUEST" for each EPS bearer to

be modified

When the eNB receives the S1AP message E-RAB MODIFY REQUEST from MME (for

one or several EPS bearers) the following steps are done:

• The eNB analysis the provided QoS parameters to derive the requested type of

modification.

• The eNB prepares the radio bearer modification for each EPS bearer to be modified.


Issue: 01J DN09185979 91

8/18/2019 Fd Rl40 Desc


– QCI modification: The eNB configures a new scheduling weight for the UL and

DL schedulers and a new transport DSCP for the EPS bearer. For Operator

defined QCIs the eNB may change the counter group.

–

ARP modification: The eNB informs admission and congestion control about thenew ARP value. Optionally the eNB configures a new congestion weight for GBR

bearers.

– No modification of bearer QoS parameters: The eNB accepts the modification

without reconfiguring the EPS bearer.

– For each EPS bearer for which the modification has been admitted: The eNB

repeats the current logical channel configuration. [3GPP 36.331] requires that

NAS PDUs can only be transmitted by the RRC message

RRCConnectionReconfiguration to UE if bearers are modified (or setup

or released).

– UE-AMBR modification: The eNB informs UL and DL schedulers about the

modified UE-AMBR.

– The eNB configures the local U-Plane and T-Plane for the DRB of the modifiedEPS bearer(s).

• The eNB sends the RRC message RRCConnectionReconfiguration to UE. This

message contains for each successful modified EPS bearer a logical channel

configuration and the NAS PDU of the EPS bearer received by the S1AP message

E-RAB MODIFY REQUEST.

• If the eNB receives the RRC message

RRCConnectionReconfigurationComplete, the eNB sends the S1AP

acknowledgment E-RAB MODIFY RESPONSE to the MME

• The UE sends in parallel NAS-PDU(s) containing the NAS acknowledgement of the

EPS bearer modification to the eNB by RRC message(s) ULInformationTransfer. The

eNB forwards this NAS-PDUs (non-access-stratum packet data unit) to MME by theS1AP message UL NAS TRANSPORT.

• The MME continues the Update Bearer procedure/Insert Subscriber Data procedure.

Activation

This feature is activated/deactivated by setting the parameter actERabModify to

true/false

QCI modification

By the QCI modification the old nonGBR Q CI of an EPS bearer is replaced by a new

nonGBR QCI and the configuration of the new QCI is applied to the EPS bearer.

The modification of a QCI is only allowed if all configuration parameters except for

• schedulWeight

• dscp

• counterGroup

• scheduling priority

• scheduling BSD

remain unchanged by the modification. An E-RAB Modify Request for QCI modification is

rejected if the QCIs differ in other parameters.

The QCI of EPS bearers with the QCI=5 and scheduling type “SIGNALLING” are not to

be changed because it has been reserved for IMS signaling.

ARP modifcation



92 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The ARP parameter of the bearers can be modified by the Bearer Management during

the life time of the bearers. With the modification of the ARP parameter the congestion

weight of the bearers change is taken into account immediately by the DL congestion

evaluation of the GBR bearers in DL.

An ARP modification to or from an emergency ARP is rejected.

UE- AMBR

The UE-AMBR is changed if the S1AP message E-RAB MODIFY REQUEST contains

the IE “UE Aggregate Maximum Bitrate”. The eNB informs the rate capping function of

MAC schedulers about the new UE-AMBR.

3.8.4 System impact


The following features have interdependencies to this feature:

• LTE9: Service Differentiation: The feature LTE519: eRAB Modification modifies the

scheduling weights introduced by LTE9: Service Differentiation.

• LTE10: EPS bearers for conversational voice: The feature LTE519: eRAB

Modification modifies the GBR values for QCI=1 introduced by LTE10: EPS bearers

for conversational voice (only for lower values).

• LTE13: Rate Capping: The feature LTE519: eRAB Modification modifies the UE-

AMBR introduced by LTE13: Rate Capping.

• LTE496: Support of QCI 2, 3 and 4: The feature LTE519: eRAB Modification modifies

the GBR values for QCI234 introduced by LTE496: Support of QCI 2, 3 and 4 (only

for lower values).

• LTE497: Smart admission Control : The feature LTE519: eRAB Modification modifiesthe GBR admitted by transport.

• LTE518: Operator Specific QCI: The feature LTE519: eRAB Modification modifies the

counter group introduced by LTE518: Operator Specific QCI. If a QCI is modified, it

may happen that the new QCI value belongs to a different counter group.

• LTE534: ARP based admission control for E-RABs: LTE534: ARP based admission

control for E-RABs uses internal ARP modification, the feature LTE519: eRAB

Modification describes how internal and S1AP ARP modification are coordinated.


This feature impacts interfaces as follows: LTE519: eRAB Modifcation introduces the

S1AP procedure E-RAB Modify including the messages

• E-RAB MODIFY REQUEST

• E-RAB MODIFY RESPONSE:

This feature is managed by the parameters listed in the Management Data section.


This feature impacts network management and network element management tools as

follows: The S1AP procedure E-RAB Modify is supported.




Issue: 01J DN09185979 93

8/18/2019 Fd Rl40 Desc





Alarms






Parameters



Full name

Abbreviated name

Managed object

Activate E-RAB Modification actERabModify LNBTS



BSW/ASW



ASW - -

3.9 LTE534: ARP based admission control for E-RABsIntroduction to the feature

This feature LTE534: ARP based admission control for E-RABs replaces the permanent

admittance (from releases before) by a withdrawable acceptance. In case of a resource

limitation, the eNB may withdraw the admittance from an already admitted E-RAB to use

its resources for admittance of a more important E-RAB (evolved radio access bearer).

The policy is based on ARP (Allocation and retention Policy), which is an E-RAB priority

concept defined by 3GPP TS 23.203.

3.9.1 Benefits

End-user benefits

This feature offers a priority controlled admission and pre-emption for GBR and non-

GBR bearers. This is important for the acceptance for high bit rate GBR features withQCI 2,3 and 4. The end user can use high bit rate GBR services.



94 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Operator benefits

The operator can offer services with higher bit-rates.

3.9.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW





Functional overview

This feature implements an admission and retention policy for E-RABs which

• admits E-RABs according to admission priority

• regards an admission only temporary, until an E-RAB with higher priorities needs its

resources

This policy is called ARP (Admission and retention Policy) and the framework for this

policy is defined by 3GPP TS 23.203 and TS 36.413. It is based on one E-RAB

parameter comprising the following three values:

• ARP priority level, defining the importance of the E-RAB. A more important E-RABgets and keeps needed resources more prioritized than less important E-RABs

• pre-emption vulnerability, defining if the E-RAB may be pre-empted by an E-RAB

with higher ARP priority

• pre-emption capability, defining if the E-RAB may pre-empt any E-RAB with lower

ARP priority

Pre-emption is a procedure by which a call with higher priority can cause the release of

an ongoing call with lower priority. Pre-emption is limited by the parameter

maxNumPreEmptions.This parameter limits the number of pre-emptions which the

admission of a set of E-RABs (e.g. at initial context setup, E-RAB setup, handover

request) may cause. If this number gets exceeded for an E-RAB set, the admission of

this set set will partly or completely fail.Because each pre-emption takes at least 5ms


Issue: 01J DN09185979 95

8/18/2019 Fd Rl40 Desc


(but may take more, depending on eNB load), the pre-emption number limitation should

be considered carefully to avoid timeouts of procedures which depend on E-RAB

admission (in particular handover preperations).

The timer timDelACContPreEmption delays the continuation of the admisisoncontrol for pre-empted bearers. If the eNB sends the S1AP message E-RAB RELEASE

INDICATION for pre-empted bearers to MME, MME needs time to release the indicated

bearers in the EPC. Until the release of a bearer S-GW may still send downlink data

packets for this bearer to the eNB. The expected avarage time is covered by this timer

that delays the continuation of the admisison control by the given timer value.

If an E-RAB is admitted, the eNB determines the needed resources and tries to allocate

them. If not enough free resources are available, the eNB tries to release them by pre-

emption of already admitted E-RABs according to the above ARP parameter.

3.9.4 System impact


The features

• LTE496: Support of QCI 2,3 and 4

• LTE497: Smart admission Control

• LTE534: ARP based admission control for E-RABs

belong together and must be enabled together by setting the

actEnhAcAndGbrServices parameter to true.

The feature

LTE7: Support of multiple EPS bearer is a prerequisite for these features and must be enabled.

The feature

LTE572: IMS emergency session

must be enabled for correct handling of emergency sessions.



This feature is managed by the parameters listed in the Management Data section



tools.


In case of E-RAB setup without pre-emption, the ARP based admission control does not

degrade the setup time against the setup time without LTE534: ARP based admission

control for E-RABs. In case of pre-emption, the E-RAB setup time may need longer than

without pre-emption.

For this feature LTE534: ARP based admission control for E-RABs no reserved

resources for IMS emergency session E-RABS are longer necessary. Therefore, the

eNB capacity for normal E-RABs can be used more effectively.



96 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc





Alarms





Counter ID

Counter name

Measurement

M8006C174 Pre-empted GBR bearers LTE EPS Bearer

M8006C175 Pre-empted non-GBR bearers LTE EPS Bearer

M8013C28 Pre-empted UE contexts due to pre-

emption of last non-GBR bearer

LTE UE State



Parameters



Full name

Abbreviated name

Structure

Managed object

Activate enhanced

AC and GBR

services

actEnhAcAndGbrService

s

MRBTS/LNBTS

Emergency

sessions ARP

emerSessArp imsEmerPlmnConfig M RBTS/LNBTS

Emergency

session ARP pre-

emption Capability

emerSessArpPreemCap imsEmerPlmnConfig MRBTS/LNBTS

Emergency

session ARP pre-

emption

Vulnerability

emerSessArpPreemVul imsEmerPlmnConfig MRBTS/LNBTS


Issue: 01J DN09185979 97

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Structure

Managed object

Emergency

sessions ARP

priority level

emerSessArpPrioLev imsEmerPlmnConfig MRBTS/LNBTS

Emergency

sessions limited

service mode

support

emerSessLimServ imsEmerPlmnConfig MRBTS/LNBTS

Emergency

sessions MCC

emerSessMcc imsEmerPlmnConfig MRBTS/LNBTS

Emergency

sessions MNC

emerSessMnc imsEmerPlmnConfig MRBTS/LNBTS

Emergency

sessions MNC

length

emerSessMncLen imsEmerPlmnConfig MRBTS/LNBTS

Maximum number

of pre-emptions

maxNumPreEmptions MRBTS/LNBTS

Timer delayed AC

continuation at

pre-emption

timDelACContPreempt MRBTS/LNBTS

Timer suppress

GTP-U error

indication at pre-

emption

timSuppGtpuErrIndPree

mpt

MRBTS/LNBTS



BSW/ASW



ASW - -

3.10 LTE587: Multiple GBR EPS Bearers per UE

3.10.1 Description of LTE587: Multiple GBR EPS Bearers per UE




98 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


With this feature LTE587: Multiple GBR bearers per UE the following combinations of

DRB bearers are supported:

Table 44 Allowed maximum number of bearers

Bearer

Maximum Number

DRB AM (Acknowledged Mode) 5

DRB UM (Unacknowledged Mode) 3

DRB GBR 3

DRB 6

3.10.1.1 Benefits

End-user benefits

The end user can use additional service combinations.

Operator benefits

The operator is able to offer additional service combinations.

3.10.1.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW




3.10.1.3 Functional description

Functional overview

The following radio bearer combinations are supported by UE:


Issue: 01J DN09185979 99

8/18/2019 Fd Rl40 Desc


• SRB1 + SRB2 + N x AM DRB

• SRB1 + SRB2 + N x AM DRB + 1 x UM DRB



with N= 1...5. (SRB: signaling radio bearer, DRB: data radio bearer, AM: acknowledged

mode, UM: unacknowledged mode) New with this feature is that two or three UM DRBs

are allowed. The rules are:

1. In total maximum 6 DRBs are allowed.

2. Of these 6 DRBs 5 AM DRBs are allowed.

3. Of these 6 DRBs 3 UM DRBs are allowed

4. Of these 6 DRBs 3 GBR DRBs are allowed.

The eNB provides checks for the total number of DRB per cell, the maximum number of

DRBs per UE and the bearer combination per UE.

The eNB supports the following scenarios for establishing and releasing EPS bearers:

• establish individual EPS bearers

• release individual EPS bearers

• add multiple EPS bearers to existing EPS bearers

• release multiple EPS bearers from existing EPS bearers

The different EPS bearers per UE can have the same or a different QCI (QoS class

identifier).

Mapping of multiple GBR bearers to LCGs

With this feature configurations of GBR bearers and non-GBR bearers assigned to thesame LCG (logical channel group) are now possible. The logical channel group identifier

(parameter lcgid) defines the mapping of the logical channels to the corresponding

LCGs.

UL scheduling

If the support of multiple GBR bearers per UE is activated, this becomes implicitly visible

for the time domain scheduler in UL as soon as more than one GBR bearer is

established for any UE. In UL the scheduler has to distinguish the scheduling of the

multiple GBR bearers depending on the mapping of the GBR bearers to the LCG. Two

alternatives are possible:

• GBR bearers mapped to a LCG serving only GBR bearers: Whenever this is thecase, the time domain scheduling criterion in UL is calculated separately for each of

the GBR bearers assigned to the UE. The highest of those criterion values for all

GBR bearers of an UE is then used in the determination of the scheduling candidate

set 2.

• GBR bearers mapped to a LCG serving non-GBR and GBR bearers: For this case

the GBR bearer is scheduled like a non-GBR bearer in the time domain scheduler.

Only the first alternative of both ensures the qualified scheduling of the GBR bearers and

is recommended.

DL scheduling

If the support of multiple GBR bearers per UE is activated, this becomes implicitly visible

for the DL scheduler as soon as more than one GBR bearer is established for any UE.



100 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Whenever this is the case, the DL time domain scheduling criterion for GBR bearers

needs to be calculated for every GBR bearer of a UE. The highest of those criterion

values is then used in determination of the scheduling candidate set 2.

Congestion handling for multiple GBR bearers

Congestion weights for each GBR bearer are calculated depending from the value of the

parameter conWeightAlg. According to the values “qciprio” or either “arpPrioPerVul”

different formulas (with the variables QCI-Priority or ARP-Vulnerability) are taken.

The GBR bearers to be de-prioritized in or excluded from scheduling or to be released

are determined in order of the following criteria:

1. Bearers of UEs in power limitation (only relevant for UL bearers)

2. From lower to higher congestion weight priority (lower congestion weight values

indicate higher priority)

3. Within the same congestion weight priority from higher to lower PUSCH or PDDCH

GBR resource usage of a bearer of a UE4. For the same PUSCH or PDDCH GBR resource usage from higher to lower

requested GBR.

5. For same requested GBR in random order.

Activation/Deactivation

This feature is activated / deactivated by setting the Parameter actMultGbrBearers

to true / false. It can only be activated when following feature flags are set to true:

• actMultBearers (LTE7: Support of Multiple EPS Bearers)

• actEnHAcAndGgbrServices (LTE496: Support of QCI 2, 3 and 4, LTE497:

Smart Admission Control, LTE 534: ARP Admission Control)

3.10.1.4 System impact




LTE587 is activated only if LTE496 is active.

• LTE7: Support of multiple EPS bearers

LTE587 is activated only if LTE7 is active.

• LTE10: EPS bearers for conversational Voice

With LTE587 more than one QCI = 1 bearers per UE is supported.Impact on interfaces




tools.




Issue: 01J DN09185979 101

8/18/2019 Fd Rl40 Desc


3.10.1.5 Management data



Alarms






Parameters



Full name

Abbreviated name

Managed object

Activate Multiple GBR bearers actMultGbrBearers MRBTS/LNBTS

Activate enhanced AC and GBR

services

actEnhAcAndGbrServices MRBTS/LNBTS

Table 47: Modified parameters lists parameters modified with this feature.


Full name

Abbreviated name

Structure

Managed object

Resource type resType qcitab2, qcitab3,

qcitab4

MRBTS/LNBTS

Logical channel group

identifier

lcgid qcitab2, qcitab3,

qcitab4

MRBTS/LNBTS

3.10.1.6 Sales information


BSW/ASW



ASW - -



102 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


3.10.2 Activating LTE587: Multiple GBR EPS Bearers per UE

Before you start

Restart of the eNB is required after activation of this feature only if the Activate

enhanced AC and GBR services (actEnhAcAndGbrServices) parameter

value is changed.

The Activate enhanced AC and GBR

services (actEnhAcAndGbrServices) and Activate multiple GBR

bearers (actMultGbrBearers) parameters are used to activate the feature.

The following sets of parameters are used to perform an additional configuration of the

feature:

• TheQCI translation table QCI 2 (qciTab2) parameters structure.




Multiple GBR EPS Bearers per UE :


• LTE7: Support of multiple EPS bearers

Steps

Expected outcome

When this feature is activated more than one GBR bearer can be established for any UE.




a) Expand the MRBTS object.b) Select the LNBTS object.

c) Set the Activate enhanced AC and GBRservices (actEnhAcAndGbrServices) parameter value to true.Set the Activate multiple GBR bearers (actMultGbrBearers)parameter value to true.



Issue: 01J DN09185979 103

8/18/2019 Fd Rl40 Desc


3 Expand the LNBTS object.

a) Expand the QCI translation table QCI 2 (qciTab2) object.

b) Select the QCI translation table QCI 2-1.

c) Set all parameters from the structure to define the translation of the S1APparameter QCI 2 into QCI characteristics.




c) Set all parameters from the structure to define the translation of the S1AP

parameter QCI 3into QCI characteristics.




c) Set all parameters from the structure to define the translation of the S1APparameter QCI 4 into QCI characteristics.

3.10.3 Deactivating LTE587: Multiple GBR EPS Bearers per UE

Before you start

Restart of the eNB is required after deactivation of this feature only if the Activate

enhanced AC and GBR services (actEnhAcAndGbrServices) parameter

value is changed.

Steps

Expected outcome

The eNB can establish ony one GBR bearer per UE.





104 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc





c) Set the Activate multiple GBR bearers (actMultGbrBearers)parameter value to false.

g Note: This step deactivates the feature.

3.11 Description of LTE736: CS Fallback to UTRANIntroduction to the feature

PS handover-based CS fallback from LTE to UTRAN (WCDMA) for mobile-originated

and mobile-terminated call setup is supported. The target cell selection is based on fast

measurement solicitation.

3.11.1 Benefits

Operator benefits

The CS core network investments can be reused in initial phase of LTE. The CSFB may

be further applied in roaming scenarios.

3.11.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW





Issue: 01J DN09185979 105

8/18/2019 Fd Rl40 Desc



Functional overview

This feature introduces a funcionality for CS Fallback to UTRAN via PS HO.

It is assumed that the eNB already supports PS HO to WCDMA and that this feature is

activated. Target frequencies for CSFB and PS-HO can be defined independently. Even

if a frequency is selected for both applications, whitelisting of target cells within this

frequency is done separately. Additionally target frequency might be restricted per

Subscriber Profile ID value with Mobility Profiles configuration. Mobile-originated and

mobile-terminated call setup is supported, for both RRC_IDLE andRRC_CONNECTED

states. Blind HO is not supported, so the eNB will trigger measurements before CS

Fallback to UTRAN. The feature can be switched on/off in the eNB by operator.

3.11.3.1 CSFB to UTRAN

From eNB point of view CS Fallback trigger is received from MME. Depending on feature

activation and UE capabilities, the eNB decides which type of CS Fallback will be

performed. Also priority of CS Fallback indicator will be taken into account: when it is CS

Fallback High Priority then the eNB will handle the call as Emergency Call, otherwise it

will be handled as a normal call. With the LTE736: CS fallback to UTRAN feature, the

eNB checks if B1 measurements are supported by the UE. If the UE supports B1 event,

the eNB starts measurement and additionally supervision timer for B1 will be started,

otherwise the eNB triggers CS Fallback with redirection to GERAN or UTRAN depending

on the configuration. When the UE provides B1 measurement results before supervision

timer expires, the eNB selects suitable target cell taking into account O&M configuration

for CS Fallback to UTRAN with PS HO targets, Mobility Profiles (already taken into

account during Measurement Configuration), CS domain in which UE is registered andHandover Restriction List (this will not be done for Emergency Calls) and perform PS HO

(as specified in LTE56: Inter RAT Handover to WCDMA for HO to WCDMA) to first cell

from Target Cell List (with CSFB Information indication to UE and MME). In case after all

applied restrictions Target Call List is empty or B1 supervision timer expired, the eNB

triggers CS Fallback with redirection to GERAN or UTRAN. If the UE is not supporting

PS HO or if the Operator has prohibitted PS HO, then the eNB performs CS Fallback

with redirection based on Measurements Results.

If CS Fallback with PS HO was executed, but Handover Preparation procedure failed,

the eNB tries again PS HO with next suitable cell from TCL.

3.11.3.2 CS-Fallback Mode and Target selection

Depending on feature activation, output from RRM Handover Algorithm and UE

Capabilities, the eNB decides which type of CS Fallback will be used. Possible modes

are:

• CS Fallback with PS HO to UTRAN

• CS Fallback with redirection to GERAN or UTRAN

CS Fallback with PS HO is only possible, if the UE supports B1 measurements,

otherwise CS Fallback with redirection will be used. Cells provided by the UE

measurements as suitable targets might be excluded from Target Cells List depending

on:

• Operator configuration of CSFB suitable UTRAN target cells



106 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• Mobility Profiles configuration (already during measurements)

• CS domain in which the UE is registered (if available)

• Handover Restriction List (if available)

3.11.3.3 New Managed Object Class (MOC)

LNRELW

The LNCEL parameter adjWInfList is replaced by instances of a new MOC LNRELW

(LTE Neighbor RELation to WCDMA cell) subordinate to LNCEL. In addition the

cardinality of WCDMA neighbor relations is increased from 32 to 256.

3.11.3.4 Licensing of CSFB to UTRAN

CSFB to UTRAN is an optional feature. When enabled, it is activated for the whole eNB.

To keep it activated, a license for the eNB is required. The license type is on/off. Thelicense is handled by the management system.

If activated, the eNB tries to use PS HO to UTRAN when CS Fallback is triggered. To

handover to the intended UTRAN target cell, the eNB configures the respective UE to

measure specific UTRAN target cells suitable for CS Fallback to UTRAN with B1

measurement. If suitable cells will be found in measurements, the eNB triggers PS HO

(including CS Fallback information indication to UE and target RNC) to chosen cell.

Otherwise CS Fallback with redirection will be performed.

If deactivated, the eNB performs CS Fallback with redirection (depending on LTE562: CS

Fallback with redirection activation).

3.11.3.5 User scenarios

3.11.3.5.1 Activation/Deactivation CS fallback to UTRAN

A new eNB level parameter actCsfbPsHoToUtra is introduced to activate and

deactivate the feature.

The feature is activated by setting the LNBTS parameter actCsfbPsHoToUtra to

‘true’. The feature is deactivated by setting the LNBTS parameter

actCsfbPsHoToUtra to ‘false’.

The activation of this feature is only allowed if:

• LTE562: CS Fallback with redirection is activatedand

• one of following is active:

– LTE56: Inter RAT Handover to WCDMA

– LTE898: TDD inter-RAT handover to TD-SCDMA

and

• LTE1441: CSFB to 1XRTT is disabled.

3.11.3.5.2 CSFB with a UE in RRC IDLE (Mobile originated and Mobile terminated)

Pre-condition


Issue: 01J DN09185979 107

8/18/2019 Fd Rl40 Desc


• UE is in Idle mode and registered to MSC for CS calls.

• In case of MTC: Request for CS service was coming to MME from MSC with Paging

Request for specific UE and MME sends Paging message via eNB towards the UE.

• In case of MOC: User initiates CS voice call on the UE.• Feature is enabled and properly configured in the eNB.

Description

• UE starts Initial Access procedure with Extended Service Request.

• MME sends Initial Context Setup Request message with CS Fallback

Indicator to the eNB.

• The eNB starts Measurements for configured UTRAN target cells and selects a

target based on Measurement Results.

• The eNB performs PS HO to UTRAN to chosen target cell.

• The UE is in UTRAN target cell and CS call is established in target system.

Post-condition

If the UE was handovered from LTE to UTRAN and CS call in the target UTRAN cell in

ongoing (PS service is continued in UTRAN cell as well).

Exceptions

In case there was no suitable cell found during measurements or measurements were

not performed due to lack of UE Capabilities, then the eNB will try to use CS Fallback

with redirection to UTRAN or GERAN as configured within LTE562: CS Fallback with

redirection.

3.11.4 System impactInterdependencies between features

LTE56: Inter RAT Handover to WCDMA

• This feature must be activated to activate LTE736: CS fallback to UTRAN .

LTE490: Subscriber Profile Based Mobility

• LTE736: CS fallback to UTRAN takes Mobility Profiles into consideration for selecting

UTRAN target frequencies used for CS Fallback with PS HO.

• Activation of LTE490: Subscriber Profile Based Mobility is optional to activate

LTE736: CS fallback to UTRAN .

LTE562: CS Fallback with redirection

• LTE736: CS fallback to UTRAN will use redirection mechanism specified in LTE562:

CS Fallback with redirection when performing PS HO to UTRAN will not be possible.

• Activation of LTE562: CS Fallback with redirection is mandatory to activate LTE736:

CS fallback to UTRAN .

LTE22: Emergency Calls handling

• When both features, LTE736: CS fallback to UTRAN and LTE22: Emergency Calls

handling are activated, then the UE with request for Emergency Call can use CS

Fallback to UTRAN with PS-HO if possible as specified in this feature.

LTE898: Inter RAT Handover to TD-SCDMA



108 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• This feature introduces handover to TD-SCDMA. CS Fallback to UTRAN will use

procedures specified within LTE898. The LTE898: Inter RAT Handover to TD-

SCDMA feature must be activated to activate the LTE736: CS Fallback to UTRAN

feature.

LTE1441: CSFB to 1XRTT

• The LTE1441: CSFB to 1XRTT feature shall not be activated concurrently with the

LTE736: CS Fallback to UTRAN feature. The operator do not support CDMA 1x

network and WCDMA/GSM network at the same time.





tools.






Alarms





Counter ID

Counter name

Measurement

M8016C32 CS Fallback attempts to UTRAN with PS

Handover

LTE Inter System Handover

(WBTS)



Parameters



Issue: 01J DN09185979 109

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

Activate CS fallback with PS-HO to

UTRA

actCsfbPsHoToUtra LNBTS

Filtering coefficient used for CSFB

Cpich-Ecn0

filterCoefficientCSFBCpichEcn

0

LNCEL

Filtering coefficient used for CSFB

Cpich-RSCP

filterCoefficientCSFBCpichRsc

p

LNCEL

Measurement quantity for UTRA-CSFB

FDD measurements

measQuantityCSFBUtra LNCEL

Threshold CSFB to UTRA-WCDMA for

EcN0 neighbor cell

b1ThresholdCSFBUtraEcn0 LNHOW

Threshold CSFB to UTRA-WCDMA for

RSCP neighbor cell

b1ThresholdCSFBUtraRscp LNHOW

Time to trigger UTRA-CSFB

measurement report

b1TimeToTriggerCSFBUtraMe

as

LNHOW

Related hysteresis of threshold B1 for

CSFB to WCDMA

hysB1ThresholdCSFBUtra LNHOW

Maximum number of CSFB target cells

per frequency

maxNumCsfbTargets LNHOW

Circuit switched fallback with PS

handover allowed

csfbPsHoAllowed LNRELW

WCDMA neighbor relation identifier lnRelWId LNRELW

Primary PLMN identity in CGI of UTRAN

neighbor cell

plmnId LNRELW

Target cell Id in UTRAN CGI of related

neighbor cell

uTargetCid LNRELW

Target RNC Id uTargetRncId LNRELW

Frequency layer list for high priority

CSFB to WCDMA

freqLayListCsfbHighWcdma MODPR

Frequency layer list for normal priority

CSFB to WCDMA

freqLayListCsfbNormWcdma MODPR

Frequency layer list for high priority

CSFB to WCDMA

freqLayListCsfbHighWcdma MODR



110 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

Frequency layer list for normal priority

CSFB to WCDMA

freqLayListCsfbNormWcdma MOPR

Table 52: New parameters for the “Primary PLMN identity in CGI of UTRAN neighbor

cell” list lists new parameters introduced with this feature.

Table 52 New parameters for the “Primary PLMN identity in CGI of UTRAN neighbor cell” list

Full name

Abbreviated name

Managed object

Structure

MCC in primary PLMN

identity of neighbor eNB

mcc LNRELW plmnId

MNC in primary PLMN

identity of neighbor eNB

mnc LNRELW plmnId

MNC length in primary

PLMN of neighbor eNB

mncLength LNRELW plmnId



Full name

Abbreviated name

Managed object

Neighbor WCDMA BTS cell identifier lnAdjWId LNADJW

Target frequency uTargetFreq LNADJW

Activate CS fallback via redirection actCSFBRedir LNBTS

Activate handover from LTE to WCDMA actHOtoWcdma LNBTS



BSW/ASW



ASW - -


Issue: 01J DN09185979 111

8/18/2019 Fd Rl40 Desc


3.12 Description of LTE843: ETWS broadcast


With the LTE843: ETWS broadcast , the eNB supports an Earthquake and Tsunami

Warning System (ETWS). Broadcast of primary and secondary notification is supported

by this feature.

3.12.1 Benefits

An emergency information provided by local or national government is broadcasted as

fast as possible to all the UEs that are in active or idle mode.

3.12.2 Requirements




System release Flexi Multiradio BTS Flexi Multiradio 10BTS

iOMS



UE NetAct MME SAE GW

3GPP R9 UEcapabilities

OSS5.4 CD2 - -




The purpose of the ETWS is to broadcast emergency information such as earthquake or

Tsunami warnings provided by local or national governments simultaneously to many

mobile terminals as quickly as possible. The warning notification is mapped on SystemInformation Broadcast: SIB10/SIB11 Information Elements and it is broadcasted to all

active and idle UEs

The following use cases are supported:

• a broadcast of primary notification as immediate warning about threat, likeearthquake and/or tsunami

• a broadcast of secondary notifications for delivering additional information, like whereto get help

• a broadcast of primary and secondary notification

• a stop delivering the notification



112 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


When the eNB is connected to multiple MMEs, than the warning message can come to

all of them. In this case, the eNB checks if the messages do not overlap. In this case

only one warning message is broadcasted. For more information on multiple MMEs, see

the LTE2: S1 Flex feature description.

The process of sending the warning message consists of two steps:

1. Sending of the primary notification

The notification is broadcasted as soon as possible to all camping and connected

UEs under the coverage of the eNB. The primary notification is broadcasted (as not

segmented) in the System Information Block 10 (SIB10). The broadcast duration is

set by the operator, using the etwsPrimNotifBcDur parameter.

2. Sending the secondary notification

This is broadcasted in SIB11 and might be segmented for transmission. The duration

is calculated by mapping the WRITE-REPLACE WARNING REQUEST (WRWR)

parameter to the LTE System Information Broadcast characteristics

The warning notification is contained in the WRITE-REPLACE WARNING REQUEST

message received by the eNB from the ePC (via MME). A WRWR message can contain

a primary and/or secondary notification. The warning notification might be updated (when

WRWR message contains a new primary and/or secondary notification, and the

notification is broadcasted). In that case, any broadcasted notifications are aborted and

new notifications are broadcasted.

The eNB acknowledges the broadcasting by sending the WRITE-REPLACE WARNING

RESPONSE message back to the ePC (via MME). With LTE2: S1 Flex feature, the eNB

acknowledges also delivery requests per message item while requested by multiple

MMEs.

The UEs are informed about newly arrived/broadcasted warning messages by means of paging including the ETWS notification bit.

When the LTE1755: Multiple emergency areas per cell is activated in an Emergency

Area ID might be used in signaling messages received via S1 interface to indicate the

set of cells that has the emergency impact. In this case, the eNB parameter

pwsWithEmAreaId indicates if the ETWS uses the Emergency Area IDs to indicate in

the WRWR message where cells the warning is broadcasted.

• If a Warning Message including Emergency Area IDs is received by the eNB and the

parameter pwsWithEmAreaId is set to False, this Warning Message is not

broadcasted by the eNB.

• IfpwsWithEmAreaId parameter is set to True, the configuration of

emAreaIdList Emergency area ID Listparameter is required.

When the Warning Area List IE is included and it contains the Cell ID list/Tracking Area

ID list/Emergency Area ID list, than the transmitted ETWS message is applied to the

eNB cell, in which the corresponding data are in line with these included in the List of the

received request message.

The Figure 8: The ETWS overview picture presents the overall functioning of the ETWS

message transmission and reception.


Issue: 01J DN09185979 113

http://localhost/var/www/apps/conversion/tmp/scratch_5/lte_feature_act20.pdf




8/18/2019 Fd Rl40 Desc


Figure 8 The ETWS overview

CBE/

CBC

MME1

ENBC

eNB1 cell1

(TAI1)

cell2

(TAI2)

cell3

(TAI2)

cell1

(TAI2)

cell2

(TAI3)

cell3

(TAI4)

eNB2

MME2

ENBC

BC sends Warning Message

to all MMEs serving the warning

area; for example:

Warning Message (M-Identifier;

TAI2, TAI5, ...)

Each MME distributes the

Warning Message to all eNBs

serving the warning area;

for example:

S1AP:WRW-REQUEST

(M-Identifier; TAI2, TAI5, ...)

eNB checks which cells have to

distribute the Warning Messageand initiates sending of SIB

10/11/12

eNB detects duplicated

Warning Messages

“old” Warning Message just

continues

(for

example that WM from MME1

is identical to the WM received

earlier from MME2);

eNB sends Warning Message out

on BCCH of all cells belonging to

the Warning area;

in the example only cells with TAI2

belong to the Warning Area

Used SIBs:

ETWS: SIB10/11

CMAS: SIB12

3.12.3.1 Related parameters

Emergency area ID

An Emergency Area ID may be used in signaling messages received via S1 interface to

indicate the set of cells which has the emergency impact (has to broadcast the warning

message). The parameter emAreaId identifies the Emergency Area ID of the eNB cell.

3.12.4 System impact


The LTE843: ETWS broadcast cannot be activated, when the following feature isactivated in the same eNB:

• LTE494: Commercial Mobile Alert System

The following feature can be used together with the LTE843: ETWS broadcast feature:

• LTE1755: Multiple emergency areas per cell

The Flexi Multiradio BTS allows to configure up to 15 emergency area IDs per cell for

CMAS or ETWS. The emergency area IDs are used to check if emergency

messages need to be broadcasted in a cell.





114 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc




tools.



3.12.5 LTE843: ETWS broadcast management data



Alarms



Table 57: New counterslists existing counters related to this feature:


Counter ID Counter name Measurement

M8000C39 Number of WRITE-REPLACEWARNING REQUESTmessages

8000 - LTE S1AP

M8000C40 Number of WRITE-REPLACEWARNING RESPONSEmessages

8000 - LTE S1AP

M8001C231 Number of primary ETWSnotifications

8001 - LTE Cell Load

M8001C232 Number of secondary ETWSnotifications

8001 - LTE Cell Load

M8008C16 Number of RRC Pagings for ETWS or CMAS

8008 - LTE RRC



Parameters



Full name Abbreviated name Managed object Structure

Activation ETWS support actETWS LNBTS

Emergency area ID List emAreaIdList LNCEL

ETWS primary notificationbroadcast duration

etwsPrimNotifBcDur LNBTS

PWS with emergency area ID pwsWithEmAreaId LNBTS


Issue: 01J DN09185979 115

8/18/2019 Fd Rl40 Desc


If Activation ETWS support (actETWS) is set to true, Activation CMAS

support (actCMAS) must be set to false.

Table 59 Modified parametersFull name Abbreviated name Managed object

GERAN frequency idle mode configuration identifier gfimId GFIM

IRFIM identifier irfimId IRFIM

Intra frequency idle mode configuration identifier iafimId IAFIM


Utran FDD idle mode configuration identifier uffimId UFFIM

System information scheduling list sibSchedulingList LNCEL

System Information 2 Scheduling sib2Scheduling LNCEL

System Information 3 Scheduling sib3Scheduling LNCEL

Periodicity siMessagePeriodicity LNCEL




BSW/ASW License control innetwork element

License controlattributes

Activated by default

ASW SW Asset Monitoring - No

3.13 LTE872: SRVCC to WCDMAIntroduction to the feature

Single radio voice call continuity (SRVCC) to WCDMA is a license-based feature that

introduces a handover (HO) variant from LTE to WCDMA allowing continuity for voice

calls. A voice call (including emergency session) in LTE, voice over IP (VoIP) using a

QoS class indicator (QCI) 1 bearer, might be transferred towards a call in the circuit

switched (CS) domain of UMTS if SRVCC is supported towards the target cell and if core

network (CN) and the user equipment (UE) support this feature too.

3.13.1 Benefits

End-user benefits

Seamless handover for voice services to WCDMA when leaving the LTE coverage.

3.13.2 Requirements





116 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW




Other requirements

This feature requires additionally that:

• LTE and WCDMA network are in the same geographical area.

• LTE RAN is VoIP-capable.

• LTE RAN and UTRAN are connected with an IP multimedia subsystem (IMS)-

capable CN.


The goal of this feature is to provide mechanism to HO UEs that have a QCI-1 bearer

(VoIP) activated when changing from an LTE cell to a WCDMA cell. The voice bearer,

which is the subject of HO, is served via the CS domain on WCDMA side. During HO two

different scenarios are possible: SRVCC can be executed with or without PS-HO support

depending on the capabilities of evolved packet core (EPC) and target UTRAN. All non-

voice services are handed over to the PS domain.

The selection of WCDMA target layers for SRVCC is independent from the WCDMA

target layers used for PS-HO to WCDMA.

g Note: The operator has to specify separately the target frequencies for SRVCC and

PS-HO. These two sets of frequencies may be disjunctive, partly overlapping or

identical. The selection of one of these two sets depends on the presence of an E-RABwith QCI-1 bearer.

If PS-HO is executed together with SRVCC, SRVCC determines the selection of target

layers. List of SRVCC to WCDMA Target Layers is calculated:

1. from the UE's Subscriber Profile ID (SPID) and the related managed object class

(MOC) MOPR parameter Frequency layer list for SRVCC to

WCDMA (freqLayListSrvccWcdma) if SPID is received and known in database,

otherwise

2. if Auto adaptation to freq. layers of all neighbour

cells (autoAdapt) flag is set to true, all configured WCDMA layers are selected,

otherwise


Issue: 01J DN09185979 117

8/18/2019 Fd Rl40 Desc


3. from the MOC MODPR parameter Frequency layer list for SRVCC to

WCDMA (freqLayListSrvccWcdma)

The functionality is applicable only for SRVCC-capable multimode devices supporting

both LTE and WCDMA at the corresponding frequency band. The SRVCC capability of the UE (including FGI bits) and the mobility management entity (MME) are achieved

within the context of the Initial Context Setup Procedure (for more detailed information,

see 3GPP 36.413). During intra-LTE handover the SRVCC Capability Indicator is

forwarded to the target evolved node B (eNB) either via the S1AP:HANDOVER

REQUEST message by the MME or via the X2AP:HANDOVER REQUEST message by

the source eNB.

If frequencies do not differ in Mobility Profile setting, the handover procedure itself is

identical to the LTE to WCDMA HO, that is the same neighbor cells list, measurements

and thresholds are used.

The eNB indicates the MME with the S1AP:HANDOVER REQUIRED message that

SRVCC should be initiated.

Parameter Activate SRVCC to WCDMA (actSrvccToWcdma) is introduced to

activate and deactivate this feature. It is deactivated by default because LTE872: SRVCC

to WCDMA is optional. To set actSrvccToWcdma to true Activate support of

conversational voice bearer (actConvVoice) and Activate handover

from LTE to WCDMA (actHOtoWcdma) also need to be set to true.

If the feature LTE872: SRVCC to WCDMA is activated, LTE1073: Measurement based

redirect to UTRAN must not be configured to move all UEs to WCDMA by redirect.

SRVCC HO

When the UE runs out of the LTE coverage, eNB activates UE measurements on the

WCDMA frequencies configured for SRVCC. To know which WCDMA cells support CS-HO a new, optional parameter SRVCC HO indication (SRVCC HO indication)

is introduced. This parameter selects if SRVCC to a WCDMA target is performed as a

combined PS and CS SRVCC or wether SRVCC is performed for the CS bearer only.

This parameter is stored in the eNB.

g Note: The HO capability is in principle a property of the UTRAN, however, no

information is provided by standardized interfaces.

It is also possible to allow/forbid SRVCC and/or PS-HO individually per LTE - WCDMA

neighbor relation. To define these

Single radio voice call continuity allowed (srvccAllowed) and

PS handover allowed (PS handover allowed) parameters are used.

When the UE reports that conditions for HO to WCDMA are met then eNB initiates HO

procedure towards WCDMA indicating to the EPC to apply SRVCC with or without PS-

HO support. EPC prepares UTRAN for an incoming dual mode HO (in case PS-HO is

also needed), whereas the VoIP bearer is converted to an CS-Voice bearer on Iu-CS.

The remaining bearers are mapped on Iu-PS. After this preparation the UE is

commanded to handover to UTRAN.

If the UE runs out of the LTE coverage and has at least one emergency VoIP bearer

(QCI=1) established then Handover Restriction List provided by MME is ignored.




118 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


This feature depends on the following features:

• LTE7: Support of Multiple EPS Bearer is a pre-condition to establish a VoIP bearer.

Without VoIP bearer SRVCC to WCDMA is not possible.

• LTE10: EPS Bearers for Conversational Voice is a pre-condition to establish a VoIP

bearer. Without VoIP bearer SRVCC to WCDMA is not possible.

• LTE56 Inter RAT Handover to WCDMA introduces handover towards WCDMA.

SRVCC to WCDMA reuses procedures specified for and activated with this feature.

Activation of LTE56 Inter RAT Handover to WCDMA is a prerequisite.

• LTE490 Subscriber Profile Based Mobility defines mobility profiles to select specific

subsets of frequency layers as a target for various mobility features. LTE872:

SRVCC to WCDMA uses mobility profiles to define the WCDMA target frequencies

used for SRVCC.

Only in case LTE490 Subscriber Profile Based Mobility is not activated and no

default mobility profile is configured, eNB uses any known WCDMA frequency as the

target for SRVCC.

• LTE507 Optimization of InterRAT neighbors changes the object model for WCDMA

neighbor cell objects and their relations to LTE cells. LTE507 Optimization of

InterRAT neighbors describes a method to configure required parameters for

LTE872: SRVCC to WCDMA, however, manual configuration of required parameters

by operator is also possible.

• LTE873: SRVCC to GSM and LTE872: SRVCC to WCDMA are competing features

for different target RAT. Both may be active in parallel. Prioritizing is done by

measurement thresholds.

• LTE1073 Measurement based redirect to UTRAN describes an alternative method to

send UE in LTE active mode to UTRAN by UE Context Release with Redirect.

This solution is mainly intended for UE which are capable to measure UTRAN but

not capable to perform PS handover towards UTRAN. However, the feature includesthe option to send all UE to UTRAN by redirection, independently whether they

would be able to execute PS handover.

Executing SRVCC and UE Context Release with Redirect for one UE in parallel

would be a contradiction. Therefore, the option to prohibit PS HO to WCDMA for all

UE is not allowed if SRVCC is activated.

g Note: Note that the UE which is SRVCC capable, is always capable to perform PS-HO,

so no contradiction can occur if redirection is applied only for UEs not capable of PS-

HO.



• S1-Interface

The existing messages:

– INITAL CONTEXT SETUP REQUEST

– HANDOVER REQUIRED

– HANDOVER REQUEST

are extended to support the new IE SRVCC Operation Possible and SRVCC HO

Indication.

• X2-Interface - the existing messages HANDOVER REQUEST is extended to support

new IE SRVCC Operation Possible.Impact on network and network element management tools


Issue: 01J DN09185979 119




8/18/2019 Fd Rl40 Desc



tools.






Alarms





Counter ID

Counter name

Measurement

M8016C29 Inter System Handover attempts to UTRAN

with SRVCC

8016 - LTE Inter System

Handover (WBTS)

M8017C11 Inter System Handover attempts to UTRAN

with SRVCC per neighbor cell relationship


Handover to UTRAN per

Neighbor Cell (WBTS)

M8016C30 Successful Inter System Handover

completions to UTRAN with SRVCC


Handover (WBTS)


completions to UTRAN with SRVCC per

neighbor cell relationship


Handover to UTRAN per

neighbor Cell (WBTS)

M8016C31 Failed Inter System Handover attempts to

UTRAN with SRVCC


Handover (WBTS)


UTRAN with SRVCC per neighbor cellrelationship


Handover to UTRAN per Neighbor Cell (WBTS)



Parameters




120 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

Activate SRVCC to WCDMA actSrvccToWcdma LNBTS

SRVCC HO indication srvccHoInd LNADJW

Single radio voice call continuity allowed srvccAllowed LNRELW

Frequency layer list for SRVCC to

WCDMA

freqLayListSrvccWcdma MODPR

Frequency layer list for SRVCC to

WCDMA

freqLayListSrvccWcdma MOPR



Full name

Abbreviated name

Managed object

Neighbor WCDMA BTS cell identifier lnAdjWId LNADJW

Target frequency uTargetFreq LNADJW

Activate support of conversational voice

bearer

actConvVoice LNBTS

Activate handover from LTE to WCDMA actHOtoWcdma LNBTS

WCDMA neighbor relation identifier lnRelWId LNRELW

Primary PLMN identity in CGI of UTRAN

neighbor cell

plmnId LNRELW

PS handover allowed psHoAllowed LNRELW

Target cell Id in UTRAN CGI of related

neighbor cell

uTargetCid LNRELW



BSW/ASW



ASW - -


Issue: 01J DN09185979 121

8/18/2019 Fd Rl40 Desc


3.14 LTE873: SRVCC to GSM


Single radio voice call continuity ( SRVCC ) to GSM provides mechanism to handover

(HO) user equipments (UEs), which have a QoS class indicator (QCI)-1 bearer, voice

over IP (VoIP), activated to GSM. The voice bearer which is the subject to handover is

served via the circuit switched (CS)-Domain on GERAN side.

3.14.1 Benefits

End-user benefits

Seamless handover for voice services to GSM when leaving the LTE coverage

3.14.2 RequirementsSoftware requirements


System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW



This feature requires that the UE has 3GPP R8 capabilities and supports LTE and GSM

at the according frequency band.

Other requirements

This feature requires additionally that:

• LTE and GSM networks are in the same geographical area (GSM has wider

coverage).

• LTE radio access network (RAN) is VoIP-capable.

• LTE RAN and GERAN are connected with an IP multimedia subsystem (IMS)-

capable core network (CN).


Functional overview



122 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The goal of this feature is to provide mechanism to HO UEs that have a QCI-1 bearer

(VoIP) activated when changing from an LTE cell to a GERAN cell. The voice bearer, that

is the subject to HO, is served via the CS domain on GERAN side. SRVCC is always

executed without packet switched (PS)-HO support (it means that established non-voice

bearers are not handed over to GSM). Depending on the dual transfer mode (DTM)

capabilities of the UE and the target GERAN, two different scenarios are possible:

resources can be either re-established via routing area update (RAU) (the operator

configurable switch) or suspended as long as the UE remains in GERAN.

The selection of GSM target layers for SRVCC is independent from the GSM target

layers used for network-assisted cell change (eNACC).

The functionality is only applicable for SRVCC-capable multimode devices supporting

both LTE and GSM at the corresponding frequency band. The SRVCC capability of the

UE (including FGI bits) and the mobility management entity (MME) are achieved within

the context of the Initial Context Setup Procedure (for more detailed information, see

3GPP 36.413). During intra LTE handover the SRVCC Capability Indicator is forwarded

to the target evolved node B ( eNB) either via the S1AP:HANDOVER REQUEST

message by the MME or via the X2AP:HANDOVER REQUEST message by the source

eNB.

Figure 9: Message flow during SRVCC handover shows whole SRCVCC HO process.

Figure 9 Message flow during SRVCC handover

UE Source

eNB

Target

BSS MME S-GW SDSN P-GW

UL&DL Payload PDUs

TS1RELOCprep

3. Handover Preparation

2.S1AP:HANDOVER REQUIRED

4.S1AP:HANDOVER COMMAND

TS1RELOCoverall

5.RRC:MOBILITY

FROM EUTRAN

6.D from old cell and complete handover to GERANetach

7.S1AP:CONTEXT RELEASE COMMAND

8.S1AP:CONTEXT RELEASE COMPLETE

H a n d o v e r

C o m p l e t i o n

H a n d o v e r

E x e c u t i o n

H a n d o v e r

P r e p a r a t i o n

1. Decision to perform

SRVCC to GSM

UL&DL Payload PDUs

Handover trigger

The SRVCC is a network controlled handover with support of the UE. The following

measurement events are used:

• A1 - deactivate inter-radio access technology (IRAT) measurements

• A2 - activate IRAT measurements

• B2 - IRAT measurements


Issue: 01J DN09185979 123

8/18/2019 Fd Rl40 Desc


The measurements events A2 and A1 are used to start and stop IRAT measurements

and they are configured by the operator. The eNB triggers IRAT measurements only if

the UE has a evolved packet system (EPS) bearer with QCI=1 established and the MME

and the UE are SRVCC capable.

The operator should configure:

• the target cells for the IRAT measurements

• blacklisting of target cells

• the measurement configuration such as:

– source cell thresholds (RSRP)

– target cell thresholds (RSSI)

– hysteresis

– time to trigger

– speed-dependent scaling

More information about the configuration can be found in LTE442: Network Assisted Cell

Change to GSM .

The UE capabilities are considered for the setup of the IRAT measurement configuration,

that is support of measurement gap and support of frequency bands.

Handover preparation

The eNB initiates a HO (after receiving a measurement report form the UE) by sending

the S1AP:HANDOVER REQUIRED message with the SRVCC HO indication to the

MME.

The eNB receives target cell list (TCL) indicated by the UE measurements for the

handover. All cells in the TCL are checked and those of them, which meet at least one of

the following conditions are deleted:

• The configuration table for the GERAN neighbor cells does not list the GERAN cell

as applicable for SRVCC.

• The frequency band of the GERAN cell is not listed as GERAN SRVCC target

frequency in the Mobility profile applicable to the specific UE.

• Neither the Serving PLMN of the UE nor one of the UEs equivalent PLMNs listed in

the Handover Restriction List (which was optionally provided by MME) is supported

in the GERAN Target Cell .

• The combination of PLMN-Identity of the GERAN target cell and LAC of the GERAN

target cell is contained in the Handover Restriction List provided by the MME.

• Handover Restriction list contains the IE Forbidden inter RATs which is set to ALL,

GERAN, or GERAN and UTRAN.

g Note: Mobility profile applicable to the UE is selected according to SPID if

LTE490: Subscriber Profile Based Mobility is activated. If

LTE490: Subscriber Profile Based Mobility is not activated but a Default Mobility Profile

is defined, this Default Mobility Profile is applied.

After TCL revision, the eNB takes the first target cell from TCL for the HO. The HO

Restriction List is not evaluated if the voice bearer is for an emergency service.

The MME responds to this with a S1AP:HANDOVER COMMAND message indicating

that the resources at the target have been reserved.



124 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Handover execution

When S1AP:HANDOVER COMMAND message is received, the eNB sends a

RRC:MobilityfromEUTRA command to the UE, which forces the UE to a GSM cell (see

step 5. in Figure 9: Message flow during SRVCC handover ).

The SRVCC functionality can be enabled/disabled per cell via operation and

maintenance (O&M)

Handover scenario

The UE is attached to the LTE network and has a VoIP bearer (QCI=1) established in

LTE in parallel to at least one PS bearer. From the Initial Context Setup it is known that

both the UE and the evolved packet core (EPC) are SRVCC capable. When the UE runs

out of the LTE coverage, eNB activates UE measurements on the GSM frequencies

configured for SRVCC. The GERAN measurement parameters for SRVCC targets,

except ARFCN Value List, are identical to that ones from LTE to GERAN eNACC. In

the measurement object the same NCC permitted bitmap (nccperm) and in report

configurations the same thresholds, hysteresis, time to trigger, and interval are used.

g Note: ARFCN Value List (arfcnValueListGERAN) together with the

Band indicator applied to reference ARFCN (bandindicator) define a

GERAN frequency band to be measured. The operator specifies Mobility Profiles for

eNACC and SRVCC seperately. These sets of GERAN bands may be disjunctive, partly

overlapping or identical.

When the UE reports that the conditions for HO to GSM are met, eNB initiates HO

procedure towards GSM indicating to the EPC to apply SRVCC without PS-HO support.

If the UE or GERAN target system does not support DTM in GERAN, the eNB indicates

to the EPC that the UE is not available for PS service, and then EPS performs bearer splitting and suspends all remaining PS bearers (when the UE supports DTM, the eNB

does not indicate to the EPC that the UE is not available for PS service, the EPS

performs bearer splitting, and PS bearers are not suspended). The next step which EPC

performs is the preparation of GERAN via MSC Server for an incoming CS-HO, whereas

the VoIP bearer is converted to an CS-Voice bearer. At this moment of time the UE is

commanded to handover to GERAN.

If the UE in GERAN is DTM capable, after HO completion, it performs RAU to establish

the PS bearers (which could not be established together with the CS-HO) via general

packet radio service (GPRS) using DTM.

If the UE GERAN capabilities does not support DTM, when CS Call is finished, the UE

triggers RAU and then EPC resumes suspended PS bearers. The UE's EUTRANcapabilities indicate the UE's GERAN DTM Capabilities only from 3GPP Rel'9 onwards,

so the eNB considers 3GPP Rel'8 UEs always as not DTM capable.

g Note: It depends on GERAN implementation/configuration whether RAU is executed

via GERAN or the UE is redirected to another RAT.

During an IMS emergency call the eNB does not restrict GERAN measurements from

activation in the UE if the corresponding carrier frequency is assigned to the SRVCC

target list in the Subscriber Profile ID (SPID) mobility profile used by the UE.

Figure 10: SRVCC handover scenario shows SRVCC HO scenario of the UE which

supports DTM in GERAN.


Issue: 01J DN09185979 125

8/18/2019 Fd Rl40 Desc


Figure 10 SRVCC handover scenario

MSC Server

/MGW

Source

MME

Source

E-UTRANUE

Target

MSC

TargetSGSN

Target

BSSIMSSGW/PGW

1.Measurement reports

2.Decision for HO

4.Bearer Splitting

5a.PS to CS Req

6.Prep HO

7.HO Req/Ack

8.Prep HO Resp

9.Establish cicuit

10.Initiation of Session Transfer (STN-SR or E-STN-SR)

11.Session transfer andUpdate remote leg

12.Release of IMS

Access leg

13.PS to CS Resp

14.Handover

CommandLast UL/DL data

15.HO from E-UTRAN

Command

16.UE tunes to

GERAN

17.HO Detection

19.HO Complete

20.SES

(HO Complet )e

21.Answer

22.PS to CS complet/Ack

23b.Update Loc

24.Subscriber Location Report

HSS/

HLR

GMLC

DL flow of voice

Packet is switched

towards the CS

access leg

23a.TMSI Reallocation

3. Handover Required

(UE available for PS in target cell)

Core GERAN

IMS

25.RAU inside GPRS, PS Bearers reestablishment

DL flow of voice

Packet is switched

towards the CS

access leg

UL speech circuit isconnected through

in MSC server

STOP PS

interruption

START PS

interruption


This feature depends on the following features:

• LTE7: Support of Multiple EPS Bearer is a pre-condition to establish a VoIP bearer.

Without VoIP bearer SRVCC to GSM is not possible.

• LTE10: EPS Bearers for Conversational Voice is a pre-condition to establish a VoIP

bearer. Without VoIP bearer SRVCC to GSM is not possible.

• LTE490: Subscriber Profile Based Mobility defines mobility profiles to select specific

subsets of frequency layers as a target for various mobility features. LTE873:

SRVCC to GSM uses mobility profiles to define the GSM target frequencies used for

SRVCC.



126 DN09185979 Issue: 01J



8/18/2019 Fd Rl40 Desc


Only in case LTE490: Subscriber Profile Based Mobility is not activated and no

default mobility profile is configured, eNB uses any known GSM frequency as the

target for SRVCC.

•

LTE784: ANR Inter RAT GERAN provides a method to derive GERAN neighbor cellconfiguration automatically from GERAN data base. The derived configurations may

be used by LTE873: SRVCC to GSM .

• LTE442: Network Assisted Cell Change To GSM and LTE873: SRVCC to GSM are

competing features to access GSM (eNACC to GSM is no prerequisite for SRVCC to

GSM ). Both may be active in parallel. Selection is made dependent on the actual

bearer combination.

• LTE872: SRVCC to WCDMA and LTE873: SRVCC to GSM are competing features

for different target RAT. Both may be active in parallel. Prioritizing is done by

measurement thresholds.



• S1-Interface

The existing messages:

– INITAL CONTEXT SETUP REQUEST - transfer and evaluation of GERAN-CS

capabilities

– HANDOVER REQUIRED: new HO Type "LTEtoGERAN", target ID coded for

GERAN cells, source to target transparent container coded according to the

definition of source base station system (BSS) to target BSS transparent

container (coding according to GERAN specification), support of MS classmark 2

and MS classmark 3, support of IE "PS Service Not Available", extension of the

source eNB to target eNB transparent container and the source RNC to target

RNC transparent container to forward GERAN-CS capabilities in case of intra-LTE HO or HO to WCDMA

– HANDOVER COMMAND: new HO type "LTEtoGERAN", target to source

transparent container coded according to the definition of target BSS to source

BSS transparent container

– HANDOVER REQUEST: transfer and evaluation of GERAN-CS capabilities

• X2-Interface - the existing HANDOVER REQUEST message is extended to support

new IE SRVCC Operation Possible.

• Air-Interface

– RRC message MOBILITY FROM EUTRAN COMMAND is extended to support

"purpose" HO with "targetRAT-Type" GERAN. – RRC messages UECapabilityEnquiry and UECapabilityInformation are extended

to support GERAN-CS capabilities.



tools.


This feature influences interruption time for voice bearers, see Figure 10: SRVCC

handover scenario.

This feature has no impact on system capacity.


Issue: 01J DN09185979 127

8/18/2019 Fd Rl40 Desc





Alarms





Counter ID

Counter name

Measurement

M8016C33 Inter System Handover attempts to GERAN

with SRVCC


Handover (WBTS)

M8019C3 Inter System Handover attempts to GERAN

with SRVCC per neighbour cell relationship


Handover to GSM per

Neighbour Cell (WBTS)


completions to GERAN with SRVCC


Handover (WBTS)


completions to GERAN with SRVCC per

neighbour cell relationship


Handover to GSM per



GERAN with SRVCC


Handover (WBTS)


GERAN with SRVCC per neighbour cell

relationship


Handover to GSM per




Parameters



Full name

Abbreviated name

Managed object

Structure

DTM capability dtm LNADJG

Activate SRVCC to GSM actSrvccToGsm LNBTS



128 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

Structure

Timer T304 for InterRAT GSM t304InterRATGsm LNCEL

Supervision timer for handover

preparation to GSM

tS1RelPrepG LNBTS

Single radio voice call continuity allowed srvccAllowed LNRELG

Reference freq list for SRVCC to GSM refFreqListSrvccGsm MODPR structure

Band indicator applied to reference

ARFCN

bandIndicator MODPR

Reference ARFCN referenceARFCN MODPR end of structure

Reference freq list for SRVCC to GSM refFreqListSrvccGsm MOPR structure

Band indicator applied to reference

ARFCN

bandIndicator MOPR

Reference ARFCN referenceARFCN MOPR end of structure



Full name

Abbreviated name

Managed object

Structure

ARFCN value Geran arfcnValueGeran LNADJG

ARFCN value list arfcnValueListGERAN LNHOG

Activate support of conversational voice

bearer

actConvVoice LNBTS

PLMN identity in CGI of GERAN

neighbor cell

plmnId LNRELG structure

MCC mcc LNRELG

MNC mnc LNRELG

MNC length mncLength LNRELG end of structure

Location area code lac LNRELG

Cell identity ci LNRELG


Issue: 01J DN09185979 129

8/18/2019 Fd Rl40 Desc


Table 69 Related existing parameters (Cont.)

Full name

Abbreviated name

Managed object

Structure

Neighbour GERAN BTS cell identifier lnAdjGId LNADJG

GERAN neighbor relation identifier lnRelGId LNRELG



BSW/ASW



ASW - -

3.15 Description of LTE984: GSM Redirect with SystemInformationIntroduction to the feature

The CS fallback with redirect to GSM as well as the regular redirect to GSM is enhanced

by system information.

3.15.1 Benefits

Operator benefits

The call setup time respectively the service interruption time is improved in comparison

to a basic redirect solution.

3.15.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS




130 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



UE

NetAct

MME

SAE GW





Functional overview

This feature introduces additional funcionality for CS Fallback with Redirection to

GERAN (LTE562: CS Fallback with redirection), Emergency calls handling (LTE22:Emergency Calls handling ) and UE Context Release with Redirection (LTE423: RRC

Connection Release with Redirect ). With this feature the eNB provides System

Information for GERAN cells inside redirection message. This reduces time needed to

access target GERAN cell, in which CS service will be performed, as the UE will not

need to read SIBs from air interface to access target cell. The cell selection algorithm in

the UE is not influenced by providing the GERAN system information, for example the

UE does not prefer GERAN cells for which system information has been provided.The

feature can be switched on/off in the eNB by the operator.

3.15.3.1 CSFB to GSM with system information

CS Fallback with redirection to GSM with system information is enhancing currentbehavior with respect to redirection message (used both for CS Fallback and UE Context

Release) when target system is GERAN. New funcionality will allow including in

redirection message (RRC: Connection Release) system information of GERAN

cells configured for chosen GERAN frequency band, for which support in redirection

message is allowed by operator configuration.

By setting the required O&M parameter, the operator can decide for which mobility type

GERAN SIBs will be added to redirection message (can be set to CSFB only, UE

Context Release only or both). CS Fallback is triggered by MME as specified in LTE562:

CS Fallback with redirection, Emergency Calls and handling as specified in LTE22:

Emergency Calls handling and RRC Connection Release with redirection as specified in

LTE423: RRC Connection Release with Redirect in MOC REDRT. LTE984: GSM redirect

with system information uses the same targets as specified in these three features

mentioned above in MOC REDRT or in corresponding Mobility Profile (MORED)/Default

Profile (MODRED) instance introduced in the LTE490: Subscriber Profile Based Mobility

feature.

Additionally, the operator can specify per GERAN relationship (MOC LNRELG) if the

system information is provided for this GERAN cell in redirection message or not. The

system information for GERAN cell can optionally be configured and stored in MOC

LNADJG. Furthermore, it is possible that the GERAN system information is not provided

by O&M configuration. If no SIs are available, then redirection without SIs to chosen

GERAN frequency band will be performed.


Issue: 01J DN09185979 131

8/18/2019 Fd Rl40 Desc


The system information in redirection message is provided only if the UE indicated in UE

Capabilities, that it is capable of enhanced redirection to GERAN. The eNB also checks

RegisteredLAI IE if provided by MME and exclude cells (SIs) not matching

RegisteredLAI. It will be excluded on GERAN neighboring cell basis, so if GERAN

neigboring cell is not matching RegisteredLAI then SI for this cell will not be added to

redirection message. If no SIs are available, then redirection without SIs to chosen

GERAN frequency band will be performed. The eNB will additionally allow up to 16

numbers of SIs included in redirection message. If the operator has specified more

System Information to be included, then the eNB will use only 16 values and others will

be ignored. The eNB also checks Handover Restriction List, if provided by MME. This

check is not necessary in case of emergency calls (LTE22: Emergency Calls handling ).

In case forbidden RATs are set to all or include GERAN, then redirection to GERAN will

not be possible.

3.15.3.2 Licensing of CSFB to GSM with system information

CSFB with redirection to GSM with system information is an optional feature. When

enabled, it is activated for the whole eNB.

If activated, the eNB tries to add system information to redirection message to GERAN

target RAT system, used for CS Fallback with redirection or UE Context Release with

redirection. If no suitable System Information for GERAN cells are configured then CS

Fallback with redirection/UE Context Release with redirection will be performed without

included System Information.

If deactivated, the eNB performs CS Fallback with redirection (depending on LTE562: CS

Fallback with redirection or LTE423: RRC Connection Release with Redirect activation

and configuration).

3.15.3.3 User scenarios

3.15.3.3.1 Activation and configuration CS Fallback with redirection to GSM withsystem information

Pre-condition

• At least one of following features has to be enabled: LTE423: RRC Connection

Release with Redirect or LTE562: CS Fallback with redirection or LTE22: Emergency

Calls handling .

• At least one object for redirection to GSM has been created in the LTE cell: the

REDRT or respective Mobility Profile for redirection when the LTE490: Subscriber Profile Based Mobility feature is activated and mappings for SPID are provided.

• At least one GERAN neighbor cell (LNADJG object) has been created.

Description

• Operator has to enable the feature by setting corresponding O&M flag

actGsmRedirWithSI on BTS level to true.

• Operator has to decide for which type of mobility GERAN SIBs will be added to

redirection message: CSFB only, A2 based redirection only, or both. The

addGsmSIToRedirMsg is responsible parameter on selected redirection object.

This parameter is need in all REDRT objects with the redirRAT parameter set to

geran.



132 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


If the LTE490: Subscriber Profile Based Mobility feature is activated and MORED or

MODRED objects with redirRAT set to geran are created, the MORED

respectively MODRED parameter addGsmSIToRedirMsg has to be set too.

•

Operator should provide indication which known GERAN target cells systeminformation can be included in redirection message (the

redirWithSysInfoAllowed is responsible parameter).

Selection of GERAN neighbor cells which shall provide system informationGERAN

neighbor cells are selected for each LTE cell by setting the

redirWithSysInfoAllowed parameter in according LNRELG object(s) to

allowed. For those GERAN cells the optional LNADJG parameters

systemInfoType andsystemInfoListGeran must be set.

• if system information is not configured in LNADJG, the operator has to configure it

using the systemInfoListGeran parameter.

With such prepared configuration plan file downloaded to the eNB LTE984: GSM redirect

with system information will be activated in the eNB software.

3.15.3.3.2 Performing CS Fallback with redirection to GSM with system information

Pre-condition

• The feature LTE984: GSM redirect with system information is enabled.

• CS Fallback request was received from MME.

• Operator configured the eNB that GERAN SIBs can be added to CSFB to GERAN,

see Activation and configuration CS Fallback with redirection to GSM with system

information.

Description

• The eNB decides to perform CS Fallback with redirection to GERAN system.

• The eNB buildsRRC: Connection Release message with redirection towards

GERAN system with included system information for GERAN cells that were

configured by operator and sends redirection message to UE.

• The UE accesses target GERAN cell without a need to read all system information

from air interface, but reuses those received from the eNB.

Post-condition

• The UE was redirected from LTE to GERAN and CS service in the target GERAN cell

can be performed.



LTE562: CS Fallback with redirection

There is no real interdependency. If both are activated then, LTE562: CS Fallback with

redirection is enhanced with LTE984: GSM redirect with system information behavior for

CS Fallback with redirection to GERAN. When both LTE984: GSM redirect with system

information and LTE562: CS Fallback with redirection are activated, then the UE can use

CS Fallback to GERAN with system information as specified in this feature. Activation of

LTE562: CS Fallback with redirection is optional to activate LTE984: GSM redirect with

system information.


Issue: 01J DN09185979 133

8/18/2019 Fd Rl40 Desc


LTE423: RRC connection release with redirect

If LTE984: GSM redirect with system information is activated then, LTE423: RRC

connection release with redirect is enhanced with LTE984: GSM redirect with system

information behavior for redirection to GERAN. When both LTE984: GSM redirect withsystem information and LTE423: RRC connection release with redirect are activated,

then the UE can use UE Context Release with redirection (due to coverage) with system

information as specified in this feature. Activation of LTE423: RRC connection release

with redirect is optional to activate LTE984: GSM redirect with system information.

LTE22: Emergency Calls handling

When both LTE984: GSM redirect with system information and LTE22: Emergency Calls

handling are activated, then the UE with request for Emergency Call can use CS

Fallback to GERAN with system information as specified in this feature. Activation of

LTE22: Emergency Calls handling is optional to activate LTE984: GSM redirect with

system information.


This feature impacts the Uu interfaces. The RRC:CONNECTION RELEASE message is

extended to carry GERAN SYSINFO.



tools.


This feature impacts system performance and capacity. The delay required by system

information reading by the UE in the other RAT is significantly reduced and the e2e call

setup time for MOC and MTC will be reduced accordingly.


Alarms






Parameters



Full name

Abbreviated name

Managed object

Activate GSM redirect with system

information

actGsmRedirWithSI LNBTS



134 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

Redirect with system information

allowed

redirWithSysInfoAllowed LNRELG

Add GSM system information to

redirection message

addGsmSIToRedirMsg MODRED


redirection message

addGsmSIToRedirMsg MORED


redirection message

addGsmSIToRedirMsg REDRT



Full name

Abbreviated name

Managed object

System info list GERAN systemInfoListGeran LNADJG

Activate CS fallback via redirection actCSFBRedir LNBTS

Activate emergency call via redirection actEmerCallRedir LNBTS

Enable UE context release with redirect actRedirect LNBTS

Cell Identity ci LNRELG

Location Area Code lac LNRELG

PLMN Identity in CGI of GERAN

neighbor cell

plmnId LNRELG

MCC in primary PLMN identity of

neighbor eNB

mcc LNRELG

MNC in primary PLMN identity of

neighbor eNB

mnc LNRELG

MNC length in primary PLMN of

neighbor eNB

mncLength LNRELG

RAT for redirection redirRAT MODRED

Redirection priority for CS fallback with

redirection

csFallBPrio MODRED


Issue: 01J DN09185979 135

8/18/2019 Fd Rl40 Desc


Table 73 Related existing parameters (Cont.)

Full name

Abbreviated name

Managed object

Redirection priority for UE context

release

redirectPrio MODRED

Redirection priority for emergency call emerCallPrio MODRED

RAT for redirection redirRAT MORED


redirection

csFallBPrio MORED


release

redirectPrio MORED

Redirection priority for emergency call emerCallPrio MORED

RAT for redirection redirRAT REDRT


redirection

csFallBPrio REDRT


release

redirectPrio REDRT

Redirection priority for emergency call emerCallPrio REDRT



BSW/ASW



ASW - -

3.16 LTE979: IRC for 2 RX pathsIntroduction to the feature

The interference rejection combining (IRC) improves mainly for highly loaded and

interference limited cells the uplink performance of cell edge users and slightly increases

the uplink cell capacity.

3.16.1 Benefits

End-user benefits

With IRC a better uplink cell performance can be achieved.



136 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Operator benefits

The same as for the end-user benefits: with IRC a better uplink cell performance can be

achieved.

3.16.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS

RL40 - LBTS4.0 OMS4.0


UE

NetAct

MME

SAE GW

n/a OSS5.4 CD2 - -



3.16.3 Functional descriptionFunctional overview

Interference in a dedicated cell in the UL can occur e.g. from UEs with a different serving

cell. Other sources of interference may be spurious emissions of other technologies

(GSM, WCDMA,..) Assuming there are only a few dominant interferers, IRC is a quite

good approach to suppress this type of interference. The basic rule of thumb is that the

number of RX antennas - 1 dominant interferers can be suppressed. This means, for 2

RX antennas one dominant interferer can be suppressed. This is only a rough rating

since also interference from more users can be suppressed but the suppressor gain will

decrease very rapidly.

If on the other hand the number of interferers is high, then the interference starts to looklike Gaussian noise and is no longer favorable for IRC.

Supporting IRC is mainly a RL1 (radio layer 1) issue. IRC is only applied to the PUSCH

(physical uplink shared channel). All other channels and signals like PUCCH (physical

uplink control channel), SRS (sounding reference signal) and PRACH (physical random

access channel) do not apply IRC.

g Note: IRC for 2RX paths performs best with GPS synchronization where all cells are

timely aligned (synchronized), even the cells belonging to different eNBs.

IRC with 2RX paths shows reduced gain if there is no special synchronization

mechanism(e.g. GPS) for cells belonging to different eNBs.


Issue: 01J DN09185979 137

8/18/2019 Fd Rl40 Desc


The following two figures (Figure 11: BLER (SINR) for SDI, EPA30, Figure 12: BLER

(SINR) for SDI, ETU70) show the gain of IRC in comparison to MRC (maximal ratio

combining) in a matlab - simulation. Both are done for a SDI (single dominant interferer).

The BLER (block error rate) is the ratio of erroneous blocks against the total number of

blocks. SINR is the signal to interference and noise ratio. It is plotted at the X-axis in dB.

Two ITU-defined fading scenarios are considered:

• EPA30: (enhanced pedestrian)

• ETU70: (enhanced typical urban)

Conclusion: The best curves for SDI in both figures show the IRC-method.

Figure 11 BLER (SINR) for SDI, EPA30



138 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 12 BLER (SINR) for SDI, ETU70




• LTE80: GPS Synchronization: A phase synchronized air interface is required to

achieve maximum performance of the IRC receiver.

• LTE134: Timing over Packet : The LTE134 Timing over Packet feature offers only

frequency synchronization and does not help for IRC.

• LTE899: Antenna line Supervision: The feature LTE899: Antenna line Supervision

offers broken antenna line detection. In case one of the Rx antenna lines gets broken

and the eNB L1 receives only Gaussian Noise from this antenna line, the IRC is ableto continue its operation.





tools.


So far, not known.


Issue: 01J DN09185979 139

8/18/2019 Fd Rl40 Desc





Alarms






Parameters

There are no parameters introduced with this feature.



BSW/ASW



ASW - -

3.17 LTE1014: X2 eNB Configuration UpdateIntroduction to the feature

With this feature LTE1014: X2 eNB Configuration Update the eNB updates an

established X2 link. Updates are carried out via the X2 eNB Configuration Update

procedure.

The X2 link is the interface between two different eNodeBs (Figure 13: Overview of

interfaces). The X2 interface is for example needed for,

• Intra - LTE handover

• MME configuration changes

The X2 eNB Configuration Update procedure provides configuration information of the

own eNB to the neighbor eNB in order to support handover via X2.

The eNB Configuration Update procedure allows the update of the X2-link configuration

data without restart of the X2-link. UE-associated signaling connections which might be

available on the X2-link are not impacted by the procedure.



140 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 13 Overview of interfaces

eNodeBUE LTE Uu

eNodeB

X2

S1-US-GW P-GW

S5/S8

MME

S11

S1-MME S4

S3

3G-SGSN PDN

Mobility anchor for

intra-LTE handoversMobility anchor for

intra-3GPP handovers

(SGSN rel. 8)

Mobility anchor for

non-3GPP handovers

(and 3GPP handovers via SGSN rel. <8)

U-plane data path

UTRAN

3.17.1 Benefits

End-user benefits

This feature benefits the end user by assuring higher mobility robustness.

Operator benefits

LTE1014: X2 eNB Configuration Update feature enables automatic alignment of X2

link configuration data without impacting ongoing telecom procedures (for example X2

handover). The eNB automatically gets configuration information about cells served by

eNB and of relevant MME configuration data.

3.17.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



Issue: 01J DN09185979 141

8/18/2019 Fd Rl40 Desc



UE

NetAct

MME

SAE GW





Functional overview

The purpose of the X2 eNB Configuration Update procedure is to update application

level configuration data needed for two eNBs to interoperate correctly over the X2interface. The X2 eNB Configuration Update procedure is applied for an available X2 link

as defined in [3GPP 36.423]. It will be triggered by the eNB if relevant configuration

information, which was transmitted earlier to a peer eNB, has changed (seeTriggering

conditions).

Figure 14 X2 eNB Configuration Update - successful procedure

Initiating eNB Responding eNB

ENB CONFIGURATION UPDATE


ACKNOWLEDGE

X2 eNB Configuration Update procedure is presented in Figure 14: X2 eNB

Configuration Update - successful procedure. The procedure consists of two steps:

• The initiating eNB transfers its modified configuration information to the responding

eNB via the X2AP: ENB CONFIGURATION UPDATE message.

• The responding eNB stores the modified configuration information of the initiatingeNB and reports successful storage of the information by sending X2AP: ENB

CONFIGURATION UPDATE ACKNOWLEDGE message back to the initiating eNB.



142 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 15 X2 eNB Configuration Update - failed procedure

Initiating eNB Responding eNB



FAILURE

g Note: If the responding eNB cannot accept the update it will respond with ENB

CONFIGURATION UPDATE FAILURE message (

Figure 15: X2 eNB Configuration Update - failed procedure). In such case the initiating

eNB will enforce repetition of X2 setup to align the X2 configuration data.

Triggering conditions

Configuration changes that trigger X2 eNB Configuration Update procedure fall into two

groups: S1 link-related changes, and cell-related changes. Two relevant cases are

presented below.

1. X2 eNB Configuration Update due to cell-related changes

The following cell-related events will trigger X2 eNB Configuration Update procedure:

•

The list of PLMN IDs supported by the eNB cell is modified

If the procedure is triggered by this of event X2AP CONFIGURATION UPDATE message

may include, respectively:

• IE that lists existing cells for which configuration has been modified and complete

information about their current configuration.

2. X2 eNB Configuration Update due to S1link-related changes

The following S1-related events will trigger X2 eNB Configuration Update procedure:

• S1 setup resulting in a new MME pool

• MME Configuration Update resulting in a new or removed MME pool

• closing of S1 link resulting in removed MME pool

If the procedure is triggered by one of these events X2AP CONFIGURATION UPDATE

message will include a list of GU Group IDs to add or delete.



This feature modifies triggering conditions of the X2 Setup procedure employed by

LTE654: LTE Configuration Management to create an X2 link. Prior to the introduction of

LTE1014: X2 eNB Configuration Update feature the eNB had to trigger the repetition of

X2 Setup procedure to update configuration data of an established X2 link in the peer


Issue: 01J DN09185979 143

8/18/2019 Fd Rl40 Desc


eNB. With LTE1014: X2 eNB Configuration Update feature the eNB will no longer use

the X2 Setup procedure and will start the X2 eNB Configuration Update procedure

instead.


The LTE1014: X2 eNB Configuration Update feature introduces three additional X2AP

interface messages:

• ENB CONFIGURATION UPDATE

• ENB CONFIGURATION UPDATE ACKNOWLEDGE

• ENB CONFIGURATION UPDATE FAILURE


The LTE1014: X2 eNB Configuration Update feature allows the eNB to persistently store

information received through the X2 eNB Configuration Update procedure and inform

NetAct and BTS Site Manager about changed configuration via notification.






Alarms






Parameters

There are no parameters related to this feature.



BSW/ASW



BSW - -

3.18 LTE1073: Measurement based redirect to UTRANIntroduction to the feature



144 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


This feature provides an extended packet-switched mobility function for UEs supporting

IRAT measurements but no PS handover.

LTE1073: Measurement based redirect to UTRAN provides the means to send an UE to

WCDMA by UE Context Release with Redirect after the UE has performedmeasurements on WCDMA. Measurement concepts and configuration for handover to

WCDMA are reused.

3.18.1 Benefits

Operator benefits

Higher reliability for LTE to UTRAN service continuity.

3.18.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW





Functional overview

The feature LTE1073: Measurement based redirect is specified as an enhancement toLTE56: Inter RAT Handover to WCDMA. After the trigger to handover to WCDMA is

received it is decided whether a classical handover to WCDMA according to LTE56: Inter

RAT Handover to WCDMA is applied or aUE Context Release according to

LTE1073: Measurement based redirect . The feature LTE1073: Measurement based

redirect is activated together with LTE56: Inter RAT Handover to WCDMA. There is no

separate activation and/or licensing needed. The feature LTE1073: Measurement based

redirect to UTRAN can be used in context with the feature LTE736: CS fallback to

UTRAN.

As the feature LTE872: SRVCC to WCDMA and the feature LTE1073: Measurement

based redirect to UTRAN may not be applied to the same UE in parallel, the operator

must not prohibit PS-HO for all UEs if he has activated SRVCC to WCDMA.


Issue: 01J DN09185979 145

8/18/2019 Fd Rl40 Desc


As this feature is an enhancement of LTE56: Inter RAT Handover to WCDMA the main

extensions are:

• WCDMA measurements are configured for all UEs which are capable of measuring

WCDMA not only for UE which are capable of performing handover to WCDMA.• When mobility to WCDMA is triggered by UE measurement the eNB decides whether

to execute a handover or UE Context Release with redirect considering UE

capabilities and Operator configuration.

• Procedure for UE Context Release with redirect is applied by selecting the

redirection target from previously received measurements.

Measurement-based redirect to UTRAN is composed of functions available from the

features LTE56: Inter RAT Handover to WCDMA and LTE423 RRC Connection Release

with Redirect . In the first step of the procedure measurements of WCDMA are performed

exactly in the same way as specified for Handover to WCDMA. The complete

configuration for WCDMA measurements (including all parameters and the Mobility

Profiles) is reused from LTE56: Inter RAT Handover to WCDMA. Measurements areperformed commonly for both features. The only extension is the check for UE

capabilities. Evaluation of measurement results and target cell selection are then again

executed commonly for both features including the consideration of every target cell

restriction defined for LTE56: Inter RAT Handover to WCDMA. The trigger to start

Handover to WCDMA is now more generally interpreted as a trigger to send the UE to

WCDMA. Now the eNB decides whether the UE is sent to WCDMA by handover

according to the existing feature LTE56: Inter RAT Handover to WCDMA or by UE

Context release. If either UE is not able to perform PS handover or the Operator has

prohibited PS handover by O&M configuration, UE Context Release is performed. In the

final step of the LTE1073: Measurement based redirect procedure UE Context Release

with redirect is executed as already defined for LTE423: RRC Connection Release with

Redirect . Differences are that:

• Redirect is triggered by UE measuring the event B2 of the WCDMA target frequency

instead of A2 measuring the event on the serving LTE frequency.

• Redirection target is taken from the reported WCDMA frequency of the B2 report

instead from a Operator configured parameter.

• The check of the UE capabilities for the redirection target can be skipped as the UE

has already measured the target.

With the new parameter Prohibit PS-HO to WCDMA (Table 80: New parameters)

the operater can force all UEs (independent of their capability to perform PS-HO) to go to

WCDMA by UE Context Release with Redirect message.

3.18.3.1 Use case

An Operator has deployed an LTE network and a WCDMA network in the same

geographical area whereas the WCDMA network provides a wider coverage than the

LTE network.

Pre-Condition

Operator has enabled the feature Handover to WCDMA in eNB. A UE is attached to an

LTE Network and the UE is capable of measuring WCDMA. The UE is not capable of

performing handover to WCDMA or the Operator has prohibited handover to WCDMA.

Description



146 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The UE runs out of the LTE Coverage and the eNB activates the UE measurements on

WCDMA frequencies. The UE reports that the conditions for a handover to WCDMA are

met. The eNB triggers the UE Context Release with redirection to the WCDMA

frequency, reported by the UE. The UE leaves LTE and performs cell selection and RRC

Connection Setup in WCDMA

Post-Condition

The UE is attached to UTRAN.



• LTE56: Inter RAT Handover to WCDMA

The LTE1073: Measurement based redirect is specified as an enhancement to

LTE56: Inter RAT Handover to WCDMA. After the trigger to handover to WCDMA is

received it is decided whether a classical handover to WCDMA according to LTE56:Inter RAT Handover to WCDMA is applied or a UE Context Release according to

LTE1073: Measurement based redirect . LTE1073: Measurement based redirect is

activated together with LTE56: Inter RAT Handover to WCDMA. There is no separate

activation and/or licensing.

• LTE423: RRC Connection Release With Redirect

The LTE423: RRC Connection Release With Redirect procedure to redirect an UE to

WCDMA is reused.

• LTE736: CS fallback to UTRAN





tools.





see Reference documentation.Alarms






Parameters



Issue: 01J DN09185979 147

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

This parameter enables the feature

Handover from LTE to WCDMA

actHOtoWcdma LNBTS

Prohibit PS-HO to WCDMA prohibitPsHOtoWcdma LNBTS



BSW/ASW



ASW - -

3.19 LTE1387: Intra eNodeB inter-frequency loadbalancingIntroduction to the feature

The LTE1387: Intra eNodeB inter-frequency load balancing feature provides means to

move load (in terms of air interface usage) to cells of another frequency/band within the

same eNodeB.

Therefore, multi-frequency supporting UEs are handed over to an intra-eNB neighbor cell

of the other frequency/band.

The following condition must be fulfilled:

• the source cell is in active load balancing state (after the load having exceeded the

high load threshold)

• at least one of the potential target cells has available capacity

• the UE reports sufficient RSRP (reference symbol received power) and RSRQ

(reference signal received quality) for the target cell

• the parameters fit to this feature, only UEs without QCI 1 bearer are handed over

3.19.1 Benefits

End-user benefits

The load balancing improves the intra-eNodeB air interface resources distribution. It

leads to a better overall air interface use. The available bit rate for non-GBR services is

increased.

Operator benefits

The air interfaces resources in case of a dual band LTE deployments are optimally used.



148 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


3.19.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW





Functional overview

The feature can be divided into 4 basic blocks:

1. Load Supervision and Exchange

If the feature is switched on (actInterFreqLB parameter set to true) each cell

measures and calculates constantly the load for load types GBR DL and non-GBR DL. If

one type of the load exceeds the high load threshold, the cell enters the active inter-

frequency load balancing (iF-LB) state. If the actual load of all load types becomes lower

than target load thresholds, the cell leaves again the active iF-LB state.

Actual load situation (available capacity (AC) per load type) is exchanged between all

cells of the eNB with a periodicity of iFLBLoadExchangePeriod. If a cell is barred, it

reports all AC = 0. This means all incoming load balancing handovers in a cell are

rejected. Outgoing load balancing handovers will not be barred.

The non-GBR load per TTI is calculated basically as follows:

LoadnonGBRdl(t)

minNomNumPrbNonGb *r max (0.01; avActDLnonBearerWeightSum)

avAvailPrbDLNonGbr100%= ; 1 *

The min() and max() functions serve to deal with borderline cases. Without these

functions and for data sampled for a single TTI, this formula basically reads:

LoadnonGBr(TTI) = nomNumPrbNonGbr * sum(weights of active non-GBR bearers) /

numOfPrbsAvailableToNonGbr

where:

• ThenumOfPrbsAvailableToNonGbr is obtained, per TTI, from:


Issue: 01J DN09185979 149

8/18/2019 Fd Rl40 Desc


– the number of PRBs in the system, depending on the system bandwidth (50

PRBs for a 10 MHz system)

– minus the number of PRBs used for SIB, broadcast, paging and so on

– minus the number of PRBs used for HARQ retransmissions (irrespective of whatever service class or type the initial transmission belongs to)

– minus the number of PRBs that were allocated to GBR traffic. If data is in the

buffers but the UE is not available (DRX sleep, measurement gap)

• The “sum(weights of active non-GBR bearers)” term, in the following shortened to

“sumOfWeights” adds up, per each TTI, the weights of non-GBR bearers that have

data (for initial transmissions) in their buffers. This means:

– A non-GBR bearer does not contribute to the non-GBR load figure if it is

established but has no data in its buffer. In that case the bearer is said to be

inactive. It also does not contribute to the non-GBR load figure, after the first

transmission of a packet (which does contribute to the load figure), further HARQ

retransmissions are required for correct transmission. HARQ retransmissions donot count.

– A non-GBR bearer contributes to the reporting of non-GBR load to a small

degree if it has few occurrences of incoming data (and therefore appears in

candidate set 2 (CS2) only rarely), and its buffer is emptied fast. Therefore, the

bearer’s weight contributes to the sum of weights only rarely, perhaps only once

per each occurrence of incoming data if the data is transferred right at the first

attempt (or with HARQ retransmissions thereof).

CS2 is a selection of UEs which is made by the packet scheduler in each TTI.

For further details see the FAD: Packet Scheduler.

– A non-GBR bearer contributes to the reporting of a high non-GBR load, if it is

present in CS2 more often. This means that either there is a constant ingress of

data for this bearer, or this bearer's buffer is not emptied. This happens if the UEis dropped from CS2, or only other, higher prioritized bearers of this UE were

served. An entry that was dropped from CS2 in one TTI will be present in a

subsequent TTI again because the reason for entering CS2 still exists.

Therefore, the bearer's weight is added to the sumOfWeights more often, and in

consequence, the average load reading increases. Note that presence of a UE in

CS2 is not a condition for considering its bearers.

Furthermore, a non-GBR bearer contributes to the reporting of a high non-GBR

load if only few resources are left over to non-GBR traffic. If the scheduler runs

out of resources, services with lower priority cannot be served, other CS2 entries

(or other bearers of the same UE) take precedence and more and more UEs with

bearers with lower weights are dropped from CS2.

And a non-GBR bearer contributes also to the reporting of a high non-GBR load,-if data is in the buffers but the UE is not available (DRX sleep, measurement

gap).

• The non-GBR load is in some way a measure of the overall load in the cell, because

the GBR load also enters into the non-GBR load figure by means of the number of

PRBs that are left over to nonGBR traffic, after HARQ, system services and GBR

bearers have been served. So, it is possible to get 100% non-GBR load by having

many/high-weighing bearers active and/or by leaving only a few PRBs for any non-

zero value of sumOfWeights

• NonGbrLoad versus Throughput

The cell's nonGBR load value is independent of the actual throughput achieved by a

nonGBR bearer: if the eNB is able to quickly empty the buffers of whatever volume of data is supplied from the remote end of the connection, the bearer's weight only



150 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


rarely enters into the load calculation. Conversely, if the bearer carries just a small

traffic volume but the eNB cannot empty its buffer, the bearer's weight will add to the

load in a higher number of TTIs. This can also be interpreted by seeing the

sumOfWeights (of bearers waiting to get serviced) as a measure of the demand (for

nonGBR traffic), while the number of PRBs available for nonGBR traffic represents

the supply (of nonGBR traffic resources), which finally allows the interpretation load =

(scaling factor nomNumPrb) * demand/suppliedResources that is adopted for non-

GBR traffic.

• The bearer’s scheduling weights (parameter scheduleWeight for QCI 5, QCI 6,

...QCI 9) see in the feature description LTE9: Service Differentiation. Operators can

configure scheduleWeights for the existing bearers and also can add new weights for

operator-defined QCI classes. Changing these weights also changes the

sumOfWeights and therefore changes the load that must be reached before load

balancing starts.

The loadNonGBR can reach 100% at maximum, then the cell will reject further incoming

load handovers and AC becomes 0.

The GBR load component is calculated from the averaged numbers of

• PRBs allocated to GBR traffic

• PRBs available for GBR traffic (after SIB, HARQ, etc.):

loadGbrDl = avPrbGbr / avAvailPrbGbr.

2. Candidate UE Selection

If the feature is switched on (actInterFreqLB parameter set to true), for each UE

that makes an idle-to-active transition a timer is started (iFLBBearCheckTimer). The

timer starts when S1AP sends back Initial Context Setup Response. When the timer

expires, the own cells load and the load of the potential target cells is checked. If own

cell is in active iF-LB state and at least one potential target cell has all load types AC > 0,

the UE might be handed over to the best target cell if:

• The UE has no QCI1 bearer (if IFLBBearCheckTimer=special value:Not Used (=

31), the QCI1 bearer check is omitted.

• The UE supports other frequency layer and A4 reporting.

• No inter-frequency/inter-RAT mobility HO measurements are ongoing for this UE.

If all conditions are met, the UE measures the radio conditions of the target cells.

3. Measurement Solicitation

• The UE is reconfigured to do A4 measurements (inclusive measurement gaps;Smeasure=0) and deliver one report.

• This configuration and the following actions are timer supervised

(reportTimerIFLBA4).

• The report is post-processed in the sense that for the reported target cells RSRP

(reference symbol received power) and RSRQ (reference signal received quality) are

checked if minimum requirements are met.

• Only potential target cells are considered.

• Only target cells with all AC > 0 (available capacity) are considered.

• If there are more than one cells left in the target cell list, they are ordered according

their AC (available capacity).


Issue: 01J DN09185979 151



8/18/2019 Fd Rl40 Desc


• If no A4 report is received or the reported cells are not usable, the UE is re-

reconfigured to the measurement configuration before the iF-LB attempt as soon as

the supervision timer ( reportTimerIFLBA4) expires.

•

If the UE starts inter-frequency/inter-RAT mobility HO measurements, the UE is re-reconfigured to the measurement configuration before the iF-LB attempt.

4. If-LB Execution

If all conditions are fulfilled, a regular HO to the best target cell is executed.



The feature LTE55: Inter-frequency handover is a prerequisite for this feature.

The feature LTE490: Subscriber profile based mobility is applied on the load balancing

target frequency carriers as already supported for the normal inter-frequency HO targets.





tools.


Due to better resource utilization the system capacity is enhanced.




Alarms






Parameters




152 DN09185979 Issue: 01J

http://localhost/var/www/apps/conversion/tmp/scratch_5/fd_rl40_desc.pdf

8/18/2019 Fd Rl40 Desc



Full name

Abbreviatedname

Managedobject

Structure

Inter Freq load bal

threshold for RSRP

target filter

thresholdRsrpIFL

BFilter

LNHOIF

Inter Freq load bal

threshold for RSRQ

target filter

thresholdRsrqIFL

BFilter

LNHOIF

Activation of inter

frequency load

balancing (iFLB)

actInterFreqLB LNBTS

Inter Freq load bal load

exchange periodicity

iFLBLoadExchang

ePeriod

LNBTS

Inter Freq load bal

supervision timer for A4

event

reportTimerIFLBA

4

LNBTS

Inter Freq load bal load

thresholds

iFLBLoadThreshol

ds

LNCEL

Inter Freq load bal QCI1

Bearer check timer

iFLBBearCheckTi

mer

LNCEL iFLBLoadThresholds

Inter Freq load bal GBR

high load DL

iFLBHighLoadGB

RDL


Inter Freq load bal non-

GBR high load DL

iFLBHighLoadNon

GBRDL


Inter-frequency load

balancing PDCCH high

load

iFLBHighLoadPdc

ch


Inter Freq Load BalRetry Timer iFLBRetryTimer LNCEL iFLBLoadThresholds

Load filtering coefficient lbLoadFilCoeff LNCEL

Intra- and inter-freq.

load bal. common load

settings

loadSettings LNCEL

Cell capacity class

value

cellCapClass LNCEL loadSettings


Issue: 01J DN09185979 153

8/18/2019 Fd Rl40 Desc



Full name

Abbreviatedname

Managedobject

Structure

Mode for calculating the

CAC in load bal. and

eICIC

mlbEicicOperMod

e

LNCEL loadSettings

Nominal number of

PRBs for load balancing

nomNumPrbNon

Gbr

LNCEL loadSettings

DL GBR resource target

load

targetLoadGbrDl LNCEL loadSettings

DL non-GBR resourcetarget load

targetLoadNonGbrDl

LNCEL loadSettings

PDCCH target load targetLoadPdcch LNCEL loadSettings

Uplink CAC source

selection

ulCacSelection LNCEL loadSettings

Static CAC for uplink ulStaticCac LNCEL loadSettings



Full name

Abbreviated name

Managed object

Enable inter Frequency handover actIfHo LNBTS



BSW/ASW



ASW - -



154 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


4 Descriptions of transport and transmissionfeatures

4.1 LTE612: Synchronization HubIntroduction to the feature

With this feature the eNB with valid sync input signal can provide frequency

synchronization to another eNB (as well as to 2G BTS and 3G NodeB in heterogeneous

networks). The network elements that receive synchronization via synchronization hub

can be either collocated or connected in a chain.

The output sync signal is provided for synchronization of the next equipment in the

synchronization chain. The reference clock synchronizing the output clock is provided by

sync reference input signal (also used by the eNB as a system clock recovery).Depending on the release different sync sources are available. See Table 87: Recovery

of synchronization output clock.

4.1.1 Benefits

Collocated or chained base stations can rely on the synchronization capabilities of the

eNB. Separate synchronization sources at the network elements are no longer needed.

This feature can be used to synchronize network elements, in LTE, WCDMA as well as

in other network technologies.

This translates to signficant cost savings, since the number of GPS receivers required at

each site can be reduced to just one.

4.1.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -



LTE RL40, Feature Descriptions and Instructions Descriptions of transport and transmission features

Issue: 01J DN09185979 155

8/18/2019 Fd Rl40 Desc



The eNB uses the selected sync source to keep the frequency accuracy of its air

interface within the specified bounds. Oven Controlled Quartz Oscillator (OXCO)generates the eNB system clock, which is synchronized with the active sync reference

signal. The feature Synchronization Hub generates synchronization outputs for other

eNB (NodeB or BTS in heterogeneous networks).

System clock recovery

System clock recovery for the eNB is possible from the following sources:

• PDH interface

• SynchE

• Timing over Packet 1588-2008

• Global Positioning System (GPS)/Pulse Per Second (PPS) external reference clock

Output clock recovery

The eNB recovers the output clock from a variety of sources, depending on the active

synchronization used for the eNB system clock recovery, see Table 87: Recovery of

synchronization output clock.

Table 87 Recovery of synchronization output clock

Active sync source for the eNB system

clock

Sync output interface

PDH signal synchronized to

2.048MHz signal synchronized to

PDH PDH input PDH input

2.048MHz 2.048 input 2.048 input

SyncE EEC EEC*

Timing over Packet IEEE1588-2008 eNB OXCO eNB OXCO

GPS/1PPS 1pps input 1pps input

None (hold-over mode) eNB OXCO eNB OXCO

*In case transport module is not in use the output signal is synchronized to eNB OXCO

Synchronization accuracy

In practice the number of chained eNBs depends on the input signal quality at the first

eNB. A maximum of 20 Flexi system modules can be used if the compensation of

propagation delay has been correctly configured in each of the chained Flexi system

modules.

In SyncE networks, SyncE-filtered Ethernet Equipment Clock (EEC) is more reliable than

ToP and fulfills Maximum Time Interval Error (MTIE) limit for E1 (G.823) and T1 (G.824).Therefore SyncE networks use EEC to synchronize PDH and 2.048MHz interfaces.

Descriptions of transport and transmission features LTE RL40, Feature Descriptions and Instructions

156 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Synchronizing PDH and 2.048MHz outputs with eNB OCXO guarantees that potential

disturbances caused for example by ToP (like extensive wander) are filtered

appropriately. However, output clock is no longer traceable to Primary Reference Clock

(PRC) in such case.

Hold-over mode

If eNB loses all sync sources, it switches to hold-over mode. Then the eNB OXCO keeps

running with the last known control value and the sync output becomes squelchable.

In holdover mode the 2.048MHz output signal can be squelched ads long as the

ext2M048ClkOutOn flag is set to false. Otherwise, the 1pps output signal is provided

also during holdover periods.

4.1.4 System impact




This feature impacts all the external transport interfaces and synchronization outputs.



follows:

• Separate synchronization sources at the network elements are no longer needed.

• The synchronization capabilities are aligned between WCDMA and LTE.






Alarms






Parameters



Issue: 01J DN09185979 157

8/18/2019 Fd Rl40 Desc



Full name

Abbreviated name

Managed object

Enables synchronization hub feature syncPropagationEnabled BTSSCL

External 1pps clock out on ext1ppsClkOutOn BTSSCL

External 2M048 clock out on ext2M048ClkOutOn BTSSCL



Full name

Abbreviated name

Managed object

BTS network synchronization mode btsSyncMode BTSSCL

GPS connected to system module gpsInUse BTSSCL

GPS control interface blocked for co-

located BTS

gpsCtrlBlockForCoLocatedBts BTSSCL

Total GPS antenna line delay gpsTotalAntennaLineDelay BTSSCL



BSW/ASW

License control in

network element


ASW - -

4.1.7 Abbreviations

EEC - Ethernet Equipment Clock

GPS - Global Position System

OCXO - Oven-Controlled Crystal Oscillator

MTIE - Maximum Time Interval Error

OXCO - Oven Controlled Quartz Oscillator

PDH - Plesiochronous Digital Hierarchy

PPS - Pulse Per Second


158 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


PRC - Primary Reference Clock

SyncE - Synchronous Ethernet

ToP - Timing over Packet

4.2 LTE628: FTIF Transport PDH / Ethernet

4.2.1 Description of LTE628: FTIF Transport PDH/Ethernet


FTIF is an optional Transport Sub-module for Flexi Multiradio 10 BTS System Module

(FSMF). It provides eight E1/T1/JT1 and two Gigabit Ethernet interfaces.

4.2.1.1 Benefits

FTIF provides support for the following:

• Synchronization from E1/T1 interface

• eNB transport chaining with optical (2 x SFP) or electrical GE connection

• Synchronization Hub (see: LTE612: Synchronization hub) function based on

Synchronous Ethernet input or output




System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -


This feature requires Flexi Multiradio 10 System Module FSMF.


Optional Outdoor Transport Sub-Module FTIF extends capabilities of Outdoor Flexi

Multiradio 10 System Module FSMF by:

• 2 x Combo Ports supporting following combinations:


Issue: 01J DN09185979 159

8/18/2019 Fd Rl40 Desc


– 2 x 100/1000Base-T or

– 2 x optional optical SFP or

– 1 x 100/1000Base-T and 1 x optional optical SFP

• Flexi Multiradio 10 System Module with FTIF supports QoS aware Ethernet

Switching across up to 3 interfaces

• 8 x E1/T1/JT1 (twisted pair) on 4 x “RJ48C-style” ports; coaxial connectivity can be

provided via baluns

FTIF is required:

Flexi Multiradio 10 System Module integrated Transport and FTIF build a single logical

Transport node.

Each "RJ48C-Style" port offers 2 x E1/T1/JT1 interfaces which are both accessible via

one FTCY cable. Other E1/T1/JT1 cables are supported, they provide one PDH interface

per RJ48C port (interfaces 1, 2, 3, and 4).

Figure 16 FTIF Transport sub-module front panel view - physical layer view

2 x Combo Ports,each operating as:

- 100/1000Base-T or - optical SFP

4 x "RJ48C-style" port,each provides 2 x E1/T1/JT1

EIF1EIF2EIF3EIF4 IF4/8 IF3/7 IF2/6 IF1/5

Combo Port 1Combo Port 2

Figure 17 FTIF interfaces - logical layer view

FSM EIF1 FSM EIF2 FTIF EIF1 FTIF EIF3 FTIF EIF2 FTIF EIF4

FSM (FSMr3) RP3-01/

EIF Shared Port

(when used as EIF)

FTIFCombo Port Combo Port

Single EIF Port

No dependencyOnly one EIF Port can be used Only one EIF Port can be used

EIF1/EIF3 and EIF2/EIF4 are paired as one combo port.


160 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• The usage of EIF1 and EIF3 as well as EIF2 and EIF4 is mutually exclusive.

• The usage of EIF1/EIF3 on this FTIF and EIF2 on FSMF is mutually exclusive.

• The supported optical SFP’s 1000Base-BX/LX/SX/ZX are not part of the FTIF

delivery.

When using the optional transmission sub-module (FTIF) the following number of

interfaces (provided by both System Module and FTIF) is possible:

• 3 x GE electrical

• 2 x GE electrical + 1 x GE optical

• 1 x GE electrical + 2 x GE optical

• 2 x GE optical

4.2.1.4 System impacts


LTE628: FTIF Transport PDH/Ethernet is needed when both Synchronous Ethernet as

an input and LTE612: Synchronization hub are used.

Impacts on interfaces


Impacts on network and network element management tools

This feature has no impact on network management and network element management

tools.

Impacts on system performance and capacity

This feature has no impact on system performance and capacity.

4.2.1.5 LTE628: FTIF Transport PDH/Ethernet management data



Alarms



There are no measurements and counters related to this feature.



Parameters



Issue: 01J DN09185979 161

8/18/2019 Fd Rl40 Desc




BSW/ASW



BSW - -


162 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


5 Descriptions of operability features

5.1 LTE162: Cell Trace with IMSIIntroduction to the feature

With this feature, the existing cell trace data reports can be mapped with the IMSI/IMEI

numbers of UEs located in the traced cell. This feature extends the scope of the LTE433:

Cell Trace feature. The current LTE433: Cell Trace functionality remains unchanged.

5.1.1 Benefit

End-user benefits


Operator benefits


• the existing cell trace records can be mapped with subscriber’s IMSI/IMEI number,

which makes the tracing function more accurate

• the traced data assists the troubleshooting and network optimization process

5.1.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- Planned for later

releases

Planned for later

releases

-




With this feature, the IMSI/IMEI information is correlated with the cell trace content. The

mechanism works as follows:

LTE RL40, Feature Descriptions and Instructions Descriptions of operability features

Issue: 01J DN09185979 163



8/18/2019 Fd Rl40 Desc


1. The eNB sends the Trace Recording Session Reference, the Trace Reference, and

the Trace Collection Entity address to the MME via the S1 connection.

2. When the MME receives this new S1 signaling message, it:

• checks the IMSI and IMEI of a certain call from its database• sends the IMSI and IMEI numbers together with the Trace Recording Session

Reference and Trace Reference to the trace collection entity

3. The trace collection entity handles this information and assigns the IMSI/IMEI

number to each trace record accordingly

g Note: The functionality can be used in multi-vendor networks, because it supports 3rd

party MME and TCE.

5.1.4 System impact


This feature extends the functionality of LTE433: Cell Trace feature.


The eNB sends the trace session details towards MME via S1 signaling message.


The trace data is presented in the trace collection entity.



5.1.5 LTE162: Cell Trace with IMSI management data



Alarms






Parameters


Descriptions of operability features LTE RL40, Feature Descriptions and Instructions

164 DN09185979 Issue: 01J


8/18/2019 Fd Rl40 Desc




BSW/ASW



ASW NetAct NetAct -

5.2 LTE524: Certificate Management for iOMSIntroduction to the feature

The iOMS certificate management feature provides the automatic handling of the private

and public key as well as digital certificates in X.509v3 format. The keys and certificates

are used for mutual authentication between iOMS and other network elements as a part

of secure connection establishment.

This feature offers automatic operator certificate and operator CA certificate (trust

anchor) initial enrollment to an iOMS.

5.2.1 Benefits

End-user benefits


Operator benefits

The LTE524: Certificate Management for iOMS feature provides centralized key and

certificate initial enrollment for the operator’s network. This offers operating expenditure

savings by using automated certificate management and security enhancement due to

mutual authentication of the remote peers before establishment of any secure

connection.

5.2.2 Requirements



System release


Flexi Multiradio 10

BTS

iOMS

RL40 OMS4.0


Issue: 01J DN09185979 165

8/18/2019 Fd Rl40 Desc



UE

NetAct

MME

SAE GW

OSS5.4 CD2




Functional overview

The LTE524: Certificate Management for iOMS feature provides automatic initial

enrollment of private and public keys as well as digital certificates in X.509v3 format. Thekeys and certificates are used for mutual authentication between peer network elements

in TLS handshake procedures. Certificate management can be used for initial

enrollments of operator certificates if public key infrastructure (PKI) is used in the

customer network.

g Note: This feature represents the iOMS part of certificate management. For more

information on certificate management on the eNB side, see

LTE665: LTE Certificate Management feature description.

Supported certificates

The iOMS supports X.509v3 certificates types in the following two formats:

• PEM, used for transferring certificates manually

• DER, used for transferring certificates over the CMP protocol

The operator certificate is used to authenticate the iOMS against the peer eNB for

HTTPS and secure BTS O&M connections or against the NetAct for HTTPS. The

operator certificate for iOMS is obtained either:

• automatically, from remote operator’s Certification Authority (CA) server with CMP

protocol during initial enrollment

or

• manually, by certificate file (PEM format) injections as a part of the iOMS softwareconfiguration

The iOMS authenticates itself against the operator PKI for initial key signing using Pre-

shared key and Reference number which are configured by the operator. If the Pre-

shared key and Reference number authentication method is not possible, the local

certificate enrollment must be used.

Remote operator certificate enrollment with CMP protocol

Certificate management between the iOMS and the operator’s public key infrastructure

(PKI) is based on CMPv2 protocol.


166 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


A newly deployed iOMS in the customer network is provided with the IP address and the

port number of the operator's Certification Authority (CA) server. The CA server is

responsible for validating new operator certificates requests, signing new operator

certificates, and delivering it back to the requestor network element. The configuration of

CMP related parameters for iOMS can be done either manually, using provided API and

CLI commands, or for some of them using mass configuration procedure triggered from

NetAct.

The following parameters can be configured either using iOMS CLI or mass configuration

procedure:

• Pre-shared key (in iOMS LDAP: fsCertManPSK)

• RefNum (in iOMS LDAP: fsCertManRefNum)

• CA server IP address (in iOMS LDAP: fsCertManCAIP)

• CA server port (in iOMS LDAP: fsCertManCAPort)

• CA server subject name (in iOMS LDAP: fsCertManCACertSubjectName)

The following parameters can be configured only using iOMS CLI:

• Server path (in iOMS LDAP: fsCertManServerPath)

• End entity subject name (in iOMS LDAP: fsCertManEndEntitySubjectName)

• Protocol version (in iOMS LDAP: fsCertManOptCompatibility)

For more information on certificate and certificate related parameters configuration in the

iOMS, see Administering and Security in LTE iOMS.

Figure 18 Signaling flow of initial operator certificate enrollment.

CertificationAuthority

CMP: Initialization Request

Operator's

CA rootNokia

CA rootConfigure

PKI related

parameters

Generate key pair

Sign cert request with private RSA key

Verify authentication

Verify signature

Sign iOMS operator's certificate

CMP: Initialization ResponseOperator'sCA root

iOMS Validate iOMS operator's certificate

CMP: Acknowledgements

iOMS


Issue: 01J DN09185979 167

8/18/2019 Fd Rl40 Desc


Before an iOMS connects to the CA server, it generates a new RSA key pair. The private

key is stored locally in the iOMS and is protected by the file system permissions. The

corresponding public key part is sent to the CA for signing. As a part of proof-of-

possession procedure, the certificate request is signed by iOMS with its private key and

sent via Certificate Management Protocol. The CMP message is integrity protected by

the iOMS using the Pre-shared key. The Pre-shared key and the Reference number are

part of the iOMS configuration.

g Note: PSK and Reference number are usually created by the CA and delivered in

advance to the personnel responsible for the iOMS configuration.

If iOMS authentication is successful, the CA verifies the iOMS possession of private key

(POP) and if successful, the CA signs the public key, creates a new operator certificate,

and sends the operator certificate back to the iOMS. Within the CMP initialization

procedure the iOMS receives also the CA certificate.The iOMS validates and stores

received certificates. Once the iOMS receives its operator certificate, it is able toestablish secure connections.

The trust anchor is delivered in the similar manner to operator certificates. The iOMS

receives operator CA certificate:

• automatically via the CMP protocol exchange procedure for public key part signing

request

• or manually via the iOMS CLI (files in PEM format)

Local certificate enrollment

If the operator runs no online PKI infrastructure, the local certificate enrollment is used.

The operator certificates and trust anchors are then introduced by a manual procedure

into the secure key storage of the iOMS. The iOMS provides API and CLI commands for manual injection and update of operator certificates and trust anchors.

g Note: The operator needs to generate a private and a public key off-line to get the

public key signed by the operator's CA. The PEM file containing the operator certificates

is then loaded into the iOMS.

Manual certificate/key update

Certificate update is done manually before the iOMS operator certificate's or operator CA

certificate’s lifetime is going to be expired. To update certificates/key in the iOMS, the

responsible personnel triggers initial enrollment procedure using iOMS CLI or NetAct.

The operator-configured Pre-shared key/Reference number values are used toauthenticate the iOMS against the CA.

Expired or no longer needed certificates can be removed from iOMS certificate pool

using iOMS CLI or NetAct.

For more information on certificate management and certificate-related parameters

handling in the LTE iOMS, see Command Line Interface Tools and Management Scripts

in LTE iOMS reference documentation.

5.2.4 System impact




168 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



This feature impacts all the interfaces/protocols that use certificates for secure

connection establishment.


This feature simplifies the certificate management of the iOMS and reduces the

managing personnel effort.



5.2.5 Certificate Management for iOMS management data



Alarms

Table 96: Related existing alarms lists existing alarms related to this feature.

Table 96 Related existing alarms

Alarm ID

Alarm name

71052 OMS FILE TRANSFER CONNECTION COULD NOT BE OPENED This

alarm is raised when the server certificate validation fails on iOMS for secure

file transfer (HTTPS) connection attempt.

71058 NE O&M CONNECTION FAILURE This alarm is raised when the client

certificate validation fails on iOMS for secure BTS O&M connection attempt.

71124 CMP CERT RETRIEVAL FAILURE This alarm is raised when there is

connectivity problem with the CA or the iOMS fails to validate its own

certificates related to CMP initialization or key update sequence.

71125 CERTIFICATE EXPIRING This alarm is raised, when its own operator

certificate or root CA certificate is about to expire.

71123 CERTIFICATE REVOKED This alarm is raised if the operator certificate

signed with CA certificate could not be validated.

71122 CRL UPDATE FAILURE This alarm is raised if iOMS cannot download or

validate the download CRL from the server.





Parameters



Issue: 01J DN09185979 169

8/18/2019 Fd Rl40 Desc



Full name

End entity subject name

Server path

Protocol version

CA server IP address and port

CR/LDAP server IP address and port

PSK/Refnum/CA subject name

Time for certificate expiry warning

Time for certificate expiry alarm

Time for periodic download of CRL

Time for operator certificate update sequence in advance

Time for operator CA certificate update in advance



BSW/ASW



BSW - -

5.3 LTE593: Security for Ethernet Ports on FCT/FSM3Introduction to the feature

The purpose of the LTE593: Security on Ethernet Ports on FCT/FSM3 feature is to

separate the sensitive and non-sensitive traffic by means of a proper virtual LAN (VLAN)

configuration.

5.3.1 Benefits

End-user benefits


Operator benefits


170 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


This feature increases the security of the data sent in the internal eNB network.

5.3.2 Requirements



System release


Flexi Multiradio 10

BTS

iOMS

RL40 LBTS4.0


UE

NetAct

MME

SAE GW


This feature requires Flexi Multiradio 10 BTS (FSM-r3) hardware.


The the following logical traffic types are switched by the Ethernet switch device inside

Flexi Multiradio 10 BTS (FSM-r3):

• Subscriber payload and any kind of control and management traffic between UE,

eNB and core nodes according 3GPP

This type of data is sensitive and must be properly protected.

• internal Ethernet traffic, which is exchanged between modules inside eNB

This type of data is also sensitive and must be properly protected.

• external Ethernet traffic to/from Local Management Port (LMP)

This type of data is assumed to be non-sensitive.

Because of Flexi Multiradio 10 BTS (FSM-r3) architectural concept all traffic types share

the same Ethernet switch. To secure the internal Ethernet traffic, the following security

requirements apply:

• The sensitive internal Ethernet traffic is separated from external Ethernet traffic by

means of VLAN separation.

• Intercepting internal Ethernet traffic on external ports is prevented.

• Rerouting of internal sensitive Ethernet traffic via external ports towards external

equipment and the way back is prevented.

The VLAN separation support can be configured locally or from a remote location by

user with proper rights. For security hardening, the local host CPU is always involved in

the configuration process.

Feature configuration


Issue: 01J DN09185979 171

8/18/2019 Fd Rl40 Desc


The LTE593: Security for Ethernet Ports on FCT/FSM3 feature can be configured to be

enabled or disabled either from NetAct or by the BTS Site Manager. The default

configuration is enable.

• When the feature is enabled:

– External traffic (non-sensitive data) is separated from internal traffic (sensitive

data) via VLAN tagging.

– BTS Site Manager (BTS SM) traffic is allowed from external Ethernet ports.

– Ethernet traffic from an external Ethernet port trying to access internal services is

discarded.

– Internal connections and services cannot be accessed by any local Ethernet port.

• When the feature is disabled:

– VLAN tag is not supported, there are no separation of sensitive and non-sensitive

data.

Deactivating the feature

Deactivating the feature is usually not needed.

If the operator chooses to deactivate the feature manually, it is possible to do it using

either NetAct or BTS Site Manager. To disable or re-enable LTE593: Security for

Ethernet Ports on FCT/FSM3 feature using BTS Site Manager, modify the eNB

configuration plan. Enabling/disabling the feature does not require eNB restart.

All the feature-related settings are found in the Radio network configuration page.

Switch to Radio network configuration page and configure the Activate Ethernet

security option in MRBTS-1 Properties section.

5.3.4 System impact







tools.



5.3.5 LTE593: Security for Ethernet Ports on FCT/FSM3management data


see Flexi Multiradio BTS LTE Commissioning, RNW and Transmission Parameters excel

in NOLS.

Alarms


172 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc







Parameters

Table 100: Related existing parameters lists parameters introduced with this feature.


Full name

Abbreviated name

Managed object

Activate ethernet security actEthernetSec MRBTS



BSW/ASW

License control in network

element


BSW - -

5.4 LTE622: Local Link Layer SecurityIntroduction to the feature

The Flexi Multiradio 10 BTS (FSM-r3) uses Serial Rapid I/O (sRIO) ports to

communicate with other modules. The LTE622: Local Link Layer Security feature

provides authentication and encryption for sRIO bus between Flexi10 BTS System

Module and Flexi10 Extension Modules when connected via sRIO.

5.4.1 BenefitsEnd-user benefits


Operator benefits

Enhanced risk management is achieved because of improved eNB software and

hardware security.

5.4.2 Requirements




Issue: 01J DN09185979 173

8/18/2019 Fd Rl40 Desc


System release


Flexi Multiradio 10

BTS

iOMS

RL40 LBTS4.0


UE

NetAct

MME

SAE GW


This feature requires Flexi Multiradio 10 BTS hardware.


In Flexi Multiradio 10 BTS (FSM-r3) hardware architecture, outdoor modules provide

Serial Rapid I/O ports (sRIO) on the front panel, e.g. to connect the extension boards, for

example FBBA module, to the system module. Indoor system modules provide sRIO

interface on the backplane for the same purpose. To protect these interfaces, module

authentication and link layer encryption is provided.

Local Link Layer Security (LLsec) setup procedure

Before a new module is connected via sRIO port to an already operating flexi system

module, the sRIO ports are open. Once the new module is connected, a discovery

process starts for the sRIO address allocation/assignment and module mutualauthentication, including the key-agreement, is performed. If the modules are

authenticated successfully, the confidentiality protection is enabled and communication

between modules starts. The confidentiality protection is performed on the link layer.

In case the connection is lost (due to cable unplug) an alarm is raised and the whole

setup procedure applies to re-establish the connection.

g Note: The LTE622: Local Link Layer Security provides protection only for Serial Rapid

I/O ports.

The link layer security is allocated between sRIO transport layer and the sRIO physical

layer. The sRIO transport layer adds the relevant header information to the payload. Thepayload and the sRIO transport header are confidentially protected.


174 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 19 Inter-secure environment communication

FSMF

sRIO switch

Link LayerSecurity

sRIO Transport

Layer O & M

, C on t r ol

FBBAApplication

sRIO switch

Link LayerSecurity

sRIO Transport

Layer

C o

n t r ol

Application

sRIO PHY sRIO PHY

optical sRIO

electrical sRIO

transmission line with

AES-128 cipheringIn RL25TD, the feature provide security between Flexi System Module (FSMF) and an

extension board FBBA.

The link layer algorithm is AES128-CTR compliant to 3GPP for air-link encryption. The

AES algorithm is hardware-implemented inside the sRIO switch. It is used only for Flexi

Multiradio 10 BTS internal transport security purposes (inter-secure environment

communication).

5.4.4 System impact




On the interfaces which use sRIO, LTE622: Local Link Layer Security provides mutual

authentication, key agreement and encryption between BTS10 modules.



tools.




Issue: 01J DN09185979 175

8/18/2019 Fd Rl40 Desc


5.4.5 LTE622: Local Link Layer Security management data



Alarms



Alarm ID

Alarm name

7650

7651

BASE STATION FAULTY

BASE STATION OPERATION DEGRADED

The above alarms are raised, if the below fault occurs:

• No connection to unit (10)





Parameters




BSW/ASW



BSW - -

5.5 LTE623: Crypto AgentIntroduction to the feature

The Crypto Agent is a software-based solution that provides support for secure key and

secure file storage.

5.5.1 Benefits

End-user benefits


Operator benefits


176 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Risk management for secrets is enhanced. The secrets are protected by personal secure

environment (PSE) and cryptographic services.

5.5.2 RequirementsSoftware requirements


System release


Flexi Multiradio 10

BTS

iOMS

RL40 LBTS4.0


UE

NetAct

MME

SAE GW


This feature requires Flexi Multiradio 10 BTS hardware.


A personal secure environment (PSE) within the eNB modules takes care about the

secure storage of secrets like private keys and sensitive files. It provides services on the

encapsulated execution of sensitive tasks like key creation, hash signing service and

data en/decryption. Such a personal secure environment can either be realized by a

software-based or hardware-based solution. The Crypto Agent provides the software-

based solution.

The Crypto Agent hides all secret information. Therefore, no secret information (for

example private keys) is stored unencrypted in the eNB. Private keys never leave the

Crypto Agent in unencrypted form and all private key operations are performed within the

Crypto Agent.


Issue: 01J DN09185979 177

8/18/2019 Fd Rl40 Desc


Figure 20 Secure storage support by Crypto Agent

Flexi Multiradio System Module

Applications

File System

key database

encrypted files

Crypto Agent

UNIX socket

For the application, the underlying secure storage mechanism is transparent.The information that needs to be protected is encrypted with the Storage Root Key and

then stored in a personal secure environment. The encrypted data can only be decrypted

by the Crypto Agent with the related Storage Root Key. Because of that, any transit from

one secure key/file storage to another requires first unbinding all secrets that are stored

in PSE. Afterwards, the transit of the information to the other secure key/file storage is

possible. Before the secrets are securely stored, they must be first bound with a new

personal environment and a Storage Root Key related to it.

The Crypto Agent provides also a secure file storage service where the file content is

de/encrypted within the personal secure environment, ciphered and then stored within

the file system. The Crypto Agent provides seamless integration into the OpenSSL

framework via a pluggable engine. It guarantees that the secrets are not corrupted if anapplication or operating system software is modified.

5.5.4 System impact


The features listed below use Crypto Agent for secure private keys storage:

• LTE150: LTE OAM Transport Layer Security (TLS) Support

• LTE622: Local Link Layer Security

• LTE665: LTE Certificate Management and LTE685: Infrastructures for Certification

Authority (CA) and Registration Authority (RA)

• LTE689: LTE IPsec Support


178 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• LTE940: SW Verification Agent





tools.



5.5.5 LTE623: Crypto Agent management data



Alarms






Parameters




BSW/ASW



BSW - -

5.6 LTE646: SW Monitoring Extension with PMCountersIntroduction to the feature

This feature extends the content of the software monitoring report.

The software monitoring module RL20 enables monitoring of Configuration Management

(CM)-based optional software features. In addition to the CM-based SW monitoring,

Performance Monitoring (PM) monitoring is introduced starting from RL40.


Issue: 01J DN09185979 179

8/18/2019 Fd Rl40 Desc


With this feature it is possible to include in the software monitoring report additional

information about the dedicated LTE PM counters that are important to calculate the

software price for customer on a usage basis.

CM based SW monitoring offers the keeping track of configured functionalities, whereasPM based monitoring really monitors used functionality.

5.6.1 Benefits

End-user benefits


Operator benefits

Software Monitoring module provides a complete picture of the network setup and

network usage.

5.6.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -




5.6.3.1 Functional overview

In addition to the report generated on basis of configuration data, now also dedicated

performance management (PM) counters are included into the software monitoring

report, for example the PM counter for counting the active users.

Every hour the counter’s value is stored in a daily report. If eNodeB’s reporting

granularity is less than 1 h (e.g. 15’) then SWAM takes the maximum value of values

provided within that hour. Monthly or quarterly reports show for each day the maximum

value. For invoicing the maximum value of all the days is taken. SWAM has configuration

parameters to enable monitoring according to commercial agreements.


180 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


5.6.4 System impact







tools.



5.6.5 LTE646: SW Monitoring Extension with PM Countersmanagement data



Alarms





Counter ID

Counter name

Measurement

M8018C1 Active UE per eNB max 8018 - LTE eNB Load (WBTS)



Parameters



This feature is a basic software feature.


BSW/ASW



BSW - -


Issue: 01J DN09185979 181

8/18/2019 Fd Rl40 Desc


5.7

5.7.1 LTE771: Optimization of Intra-LTE Neighbor Relations


The NetAct Optimizer supervises all registered cell relations between the neighboring

LTE cells if they are still valid and reliable candidates to be a handover destination.

When the outcome results is an inefficient neighbor relation, the according cell relation

might be blacklisted for handover.

The optimizer neighbor cell optimization is based on statistically reliable data derived

from the measurements collected by terminals and eNB during their normal operation.

In-line with a centralized SON function, it works in a mid to long term schedule.

The NetAct keeps an updated view of the network configuration. NetAct Optimizer evaluates the PM data for the identified neighbor relations and proposes blacklisting if

required.

The NetAct Optimizer forwards the proposed configuration in a plan file to NetAct

Configurator.

5.7.1.1 Benefits

End-user benefits

The LTE771: Optimization of Intra-LTE Neighbor Relations feature increases the grade of

service for the end user by maintaining well performing and robust handover

relationships (mobility procedures).

Operator benefits

The operator can reduce operating expenses (OPEX) due to the reduced workload in

managing neighbor relationships.



Table 110: Software requirements for RL40 lists the software required for the LTE771:

Optimization of Intra-LTE Neighbor Relations feature.

Table 110 Software requirements for RL40

System

release

eNodeB

MME

SAE GW

UE

NetAct

Release RL40 LBTS3.0 - - - OSS5.3

CD3


This feature requires the following hardware:

• LTE System Module


182 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Functional overview

The LTE771: Optimization of Intra-LTE Neighbor Relations is part of the overall ANR(3GPP 36.300: Automatic Neighbour Relation) functionality. LTE neighbor cells will be

discovered and added by ANR features or manual input by the operator.

The neighbor eNB and cell configuration is configured or exchanged, via the X2 set-up

procedure, in a bi-directional mode, so both peers can be the initiator. While the cell

neighbor relation itself is first of all a uni-directional linkage from the source cell to the

target cell. The eNB will establish cell neighbor relations based on UE events. The

LTE771: Optimization of Intra-LTE Neighbor Relations feature focuses on cell neighbor

relations in the following way:

• The NetAct Optimizer supervises all current cell relations between neighboring LTE

cells if they are still valid and reliable candidates to be a handover destination. When

the PM counters show an inefficient neighbor relation, the according cell relationmight be blacklisted for handover.

• The NetAct Optimizer uses Flexi BTS configuration information and performance

counters (intra-frequency and inter-frequency handovers) in order to perform the

analysis of the task. The evaluation might result in no action or blacklisting of a

neighbor cell relation.

The following use cases are supported:

• Neighbor cell relations that have been created by the operator (network planning) or

have been created by SON-mechanisms like ANR (automatic neighbor relation) and

that have an insufficient handover performance (weak handover success ratio;

threshold is operator configured) might be blacklisted by an optimization mechanism

or, optionally, manually by an operator.

• Neighbor cell relations that have been created by the operator or have been created

by SON-mechanisms like ANR that had been blacklisted, can be enabled again by

the operator (for example, if an operator wants to re-evaluate the performance of a

formerly blacklisted neighbor relation due to changed environment/topology).

• Neighbors cell relations that have been created by the operator or have been created

by SON-mechanisms like ANR can be marked by an operator in a way so that they

are excluded from optimization.

g Note: When neighbor cell is blacklisted, no outgoing handover to the target cell is

allowed, neither via X2 nor via S1-interface.

Possible results of optimization mechanism:

• No action: The analyzed relation showed suspicious not suspect

• Blacklisting: A given relation was identified as unreliable/weak performing. The

NetAct suggests a new configuration plan file with updated entries for appropriate

Telecom/RRM blacklists.

While scheduled execution, the changes proposed by optimization algorithms can be

taken over automatically (without any operator interaction) or after confirmation by the

operator. One or both is configured in the LTE771: Optimization of Intra-LTE Neighbor

Relations profile at the NetAct. When operated from the Optimizer GUI, the user makes

the decision before saving the proposed changes to a plan.


Issue: 01J DN09185979 183

8/18/2019 Fd Rl40 Desc


Figure 21: LTE771: Optimization of Intra-LTE Neighbor Relations gives an overview of

the feature.

Figure 21 LTE771: Optimization of Intra-LTE Neighbor Relations

No HO

Configurator

Monitor

PM

CM

Optimizer

5.7.1.3.1 RAN system level scope

The centralized SON feature LTE771: Optimization of Intra-LTE Neighbor Relations

operates on existing NR to intra-LTE neighbor cells. Those can be pre-configured, learnt

from ANR functions, or generated from off-line tools. The PM data administration is

expected to run for the whole NetAct cluster or even the whole network. The PM data are

checked for being representative, so that enough HO attempts are considered. As there

are a lot of NRs found by ANR functions, some of those are often used for HO others

less. The prerequisite for feature is that NR PM counters be available on weekly

granularity period for the last weeks at least. Each NR with at least the required HO

number will be checked to ensure that their HO success rate is better then the defined

threshold.

The operator controls the LTE771: Optimization of Intra-LTE Neighbor Relations feature

with a network/cluster profile setting. This includes the configuration of the scheduled

workflow as well as the thresholds for the SON function itself.

The LTE771: optimization of Intra-LTE Neighbor Relations features focuses on long term

supervision of the HO performance. This task requires keeping and aggregation of PM

data for a longer period of time at the NetAct. The feature blacklists bad performing NRs

at eNB. The feature does not remove NR. The eNB interprets this to blacklist those

neighbor cells in the measurement request and HO decision.


184 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The operator can trigger the LTE771: Optimization of Intra-LTE Neighbor Relations

feature manually, in which case the profile setting will be done interactively. The profile

for automatic execution is not changed by this operation. The operator can request set of

cells or eNBs optimization or eNBs.

If no or insufficient NR PM counters are available for a NR, it is treated as the exit

criterion for deciding on individual NR's performance.

The blacklisting improves the KPI short-term, but, for each blacklisted neighbor relation,

the operator should identify the root cause. The following situations can lead to a bad HO

performance in addition to a missing MRO and general threshold mis-configuration:

• PCI-confusion on cell level: for one reported PCI, there are several UEs different CGI

visible; this is a classical PCI collision. The eNB takes one PCI/CGI association and

will not recover from this situation. The SON function PCI management resolves

such situations.

• PCI-confusion on eNB level: There are for one reported PCI in different (mainly

distributed) cells, several UEs will different CGI visible. This is a 3GPP-compliant PCI

allocation, but the eNB will take one PCI/CGI association and will not recover from

this situation, if UE-based ANR is disabled. If UE-based ANR and PCI re-validation,

introduced with the LTE1685: Neighbor Relation Robustness feature is enabled, then

the eNB will autonomously select the correct PCI/CGI association. Another option is

to run the LTE468: PCI Management feature as this SON function also recovers from

such a situation.

• PRACH-collision: if the HO fails as a result of a bad RACH performance, a manual

execution of LTE581: PRACH Management feature is required to recover from this

situation.

• PRACH-range configuration: if the HO fails as result of a wrong RACH format for the

actual distance from the UE towards the target cell, a manual execution of the

LTE581: PRACH Management with a bigger ISD (Inter Cell Distance) is required to

recover from this situation.

5.7.1.3.2 Use case ANR optimization

This use case describes the optimization of the intra-LTE NRs. The operator does

configure a scheduled job at the NetAct that analyzes the LTE cells with respect to their

intra-LTE neighborship performance.

Preconditions

The operator has set the wanted operator policy values for optimization of intra-LTE NR

optimization.The operator has enabled the scheduled job at the NetAct.

The KPI data for the NR are available.

Description

The following steps are supported by the NetAct:

1. Triggered by SON scheduler or from user manually via WFE UI. WFE does start the

scheduled workflow.

2. The NetAct starts for all cells the performance evaluation of its NR.

3. The NetAct creates the new plan of the proposed blacklisted NR.


Issue: 01J DN09185979 185

8/18/2019 Fd Rl40 Desc


4. The NetAct provides the operator the feedback on the procedure, according to the

level of the details selected in the policy values.

5. In case of execution without break point, the NetAct downlowads and activates the

plan files to each eNB.6. In case of execution with break point, the NetAct Configurator SON Scheduler exits

at this break point. The operator can edit the plan and decide on the further steps.

Post conditions

In the network the NRs that are poorly performing will be blacklisted.

5.7.1.3.3 Use case scheduled workflow for LTE771: Optimization of Intra-LTENeighbor Relations

This workflow describes the HO performance optimization of intra-LTE NRs. The

operator configures a scheduled job at the NetAct that analyzes all the eNBs or LTE cellswith respect to their intra-LTE neighborship performance. The eNBs or the LTE cells will

be the whole network or the actual NetAct cluster. The operator cannot directly configure

the scope of LTE cells.

The operator can run the process autonomously or request break-points. In autonomous

mode, all the resulting blacklisting of badly performing NRs are configured with one

common plan file together for all the impacted eNB-cell-NRs.

Preconditions

The LTE cells and eNBs exist and are under the management of the NetAct. The

operator has set the wanted NetAct policy values for optimization of intra-LTE NR

optimization.

The operator has enabled the scheduled job at NetAct.

Description

The following steps are supported by the NetAct:

1. The NetAct starts the workflow according to the configured week-day and day-time.

2. The NetAct collects all eNBs and their cells in the current network, based on their

actual configuration. It is ignored, if the eNB or its cell are locked in reset or other

states.

3. The NetAct starts for the given list of cells, for each cell the performance evaluation

of its NR.

4. This step is repeated for the whole list of cells. The NetAct updates the SON reportof one eNB or cell. The NetAct informs the operator about the progress of the

procedure to run in background.

5. The NetAct creates the new plan of the proposed blacklisted NR.

6. In case of automatic execution, this means without active break point, the NetAct

downloads and activates the plan files to each eNB.

A SON report is generated and notified to the operator.

7. Confirmed execution, the NetAct stops at this break-point. The operator can access

the new plan of the proposed blacklisted NR(s). The operator can edit the plan and

decide on the further steps, either to withdraw the plan file or to implement it. A SON

report is generated and notified to the operator or stored at well-defined location.

Post-conditions


186 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


In the network the NR that perform badly will be blacklisted.

5.7.1.3.4 Use case manual triggered workflow for LTE771: Optimization of Intra-LTE

Neighbor Relations

This use case describes the manual triggered HO performance analysis of Intra-LTE

NRs. The operator selects a set of LTE cells. The operator starts for the selected set of

cells the analysis of their intra-LTE neighbor ship performance.

Preconditions

The LTE cells and eNBs exist and are under management of NetAct.

The operator has selected a set of cells, otherwise the LTE771: Optimization of Intra-LTE

Neighbor Relations option is not supported.

Description

The following steps are supported by NetAct:

1. The operator can modify the policy values for optimization of intra-LTE NR.

2. The NetAct collects all eNBs and their cells in the selected scope, based on their

current configuration. It is ignored, if the eNB or it cell are locked, in reset or other

states.

3. The NetAct starts for the given list of cells for each cell the performance evaluation of

its NR.

4. This step is repeated for the whole list of cells. NetAct updates the SON report of one

eNB or cell.

The NetAct informs the operator about the progress of the procedure.

5. The NetAct creates the new plan of the proposed blacklisted NR. A SON report is

generated and will be accessible by the operator.

The operator can access the new plan of the proposed blacklisted NR. The operator

can edit the plan and decide on the further steps, either to withdraw the plan file or to

implement it. The procedure execution report will not consider those manual

changes. NetAct provides SON context information (LTE1019: SON Reports) for CM

History support of the SON reports.

Result

In the selected set of cells the NRs that perform badly will be blacklisted.

5.7.1.3.5 Use Case for the operator to manually clear the blacklist

This use case describes the steps by operator to list all the actual blacklisted NRs and to

clear for individual NR the blacklisting.

Preconditions

NetAct controls the LTE network.

Description


1. NetAct lists all LNREL instances that have for HO-allowed the value Forbidden and

NR-control the value Automatic.

2. NetAct shows for the found LNREL instances the parameter HO-allowed and NR-control in a table.


Issue: 01J DN09185979 187

8/18/2019 Fd Rl40 Desc


3. The operator can edit for each NR the parameters HO-allowed.

4. Operator can save the the proposed changes to the NR parameters into a plan.

5. The operator can edit the plan and decide on the further steps, either to withdraw the

plan file or to implement it.

Result

For the desired set of Neighbor Relations (LNREL), the NR blacklisting is removed.

5.7.1.3.6 SON modus

The functionality required from LTE771: Optimization of Intra-LTE Neighbor Relations is

of the self-optimization type. The procedures optimize the neighborship relations based

on performance data.

The operator can execute the function of LTE771: Optimization of Intra-LTE Neighbor

Relations manually triggered, too.

The operator can influence the neighborship optimization algorithm with policies to adapt

the result towards his desire. The main control is the network-wide threshold of not

acceptable HO performance.

The procedures are designed to work automatically based on policy settings for all cells

and their NR on network or NetAct scope. By default LTE771: Optimization of Intra-LTE

Neighbor Relations considers all NR. The operator can switch to manual mode for each

NR. Then this NR is not considered by LTE771: Optimization of Intra-LTE Neighbor

Relations anymore.

The following NetAct based policies are applicable at network level:

• feature activation flag at NetAct• minimum number of HO attempts per day [#/day, {0..10000} default: 10]

• required success ratio for HO [%, {0..99.9} default: 50,0]

The following eNB based policies are applicable at NR level:

• NR-control per NR {automatic, manual} default automatic

• HO-allowed per NR {allowed, forbidden, S1only} default allowed

5.7.1.3.7 Reporting

The operator can investigate the output of the automated process and optionally verify

the proposed changes, or investigate the applied changes.

The operator is informed about the progress of the LTE771: Optimization of Intra-LTE

Neighbor Relations function for each cell or eNB. The following reports are shown:

• total and done number of cells or eNBs

• number of checked NR

• blacklisted NR

• ignored NR


188 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


After the execution of LTE771: Optimization of Intra-LTE Neighbor Relations, the

operator can have a look on the proposed neighborship relations blacklisting. The

operator can edit the lists in principle. If the operator wants a certain deviation with

respect to the ANR optimization result, this has to be changed at the NR characteristic

setting, for example to set this NR as whitelisted.

Any changes by the feature LTE507: InterRAT neighbor relation Optimization (LTE,

UTRAN, GERAN) will be marked with a SON context lable. This allows to generate SON

Reports (LTE1019: SON Reports) from CM History contents. The operator can retrieve

any changes done by LTE507: InterRAT neighbor relation Optimization (LTE, UTRAN,

GERAN).

5.7.1.3.8 Operator interaction outside of LTE771: Optimization of Intra-LTE Neighbor Relations

The MIB of the network is modified by the automated LTE771: Optimization of Intra-LTE

Neighbor Relations procedures, nevertheless, the operator himself can also access theMIB directly via NetAct. There is an NR-control parameter to avoid access collisions. If

the operator changes to manual control, then LTE771: Optimization of Intra-LTE

Neighbor Relations procedures ignore this NR. Then manual changes to the current

neighbor ship relations are considered by the automated procedures..

The operator value setting of:

• HO-allowedforbidden and NR-controlmanual -> blacklisting of NR.

• HO-allowedallowed and NR-controlmanual -> whitelisting of NR.

The operator can select for HO-allowed the value S1only. With respect to LTE771:

Optimization of Intra-LTE Neighbor Relations the HO-allowed values Allowed and

onlyS1 are treated equally. LTE771: Optimization of Intra-LTE Neighbor Relations mightchange it to “forbidden” . The operator can change these values manually to Allowed or

onlyS1.



• LTE651: Performance Monitoring The feature provides basic counters to verify basic

system functionality and performance. Support for basic network optimization for

coverage and performance. Internally provided performance counters can be

complemented by external tracing tools and drive test data

• LTE724: LTE Automatic Neighbor Cell Configuration The establishment of neighbors

is based on the information which is prepared in a pre-planning. Only a subset of

information to standard configuration is required. For all neighbor cells only the

Node-ID and the IP address of the neighbor LTE eNB hosting the expected neighbor

cells need to be configured by offline pre-planning. All other configuration information

for cells of neighbor LTE eNBs are automatically derived and updated via the X2

interface.


Issue: 01J DN09185979 189

8/18/2019 Fd Rl40 Desc


g Note: Operator hint:

Up to RL20 the neighbor eNBs are found, based on the IP address configured in

ADIPNO-adjEnbCPlaneIpAddress. With the upgrade to RL30 the IP address are

moved into the persistent object LNADJ. During upgrade the IP address has the

characteristic LNADJ-cPlaneIpAddrCtrl= oamControlled. As

LTE771: Optimization of Intra-LTE Neighbor Relations is based on the LNREL-eCGI to

identify the related LNADJ instance with the same eCGI, we recommend to enable

LTE782: ANR - Intra-LTE, Intra-frequency - Fully UE-based and change all IP address

characteristics to enbControlled. This ensures that the LNREL-eCGI is always

correctly assigned to the related LNADJ-global-eNB-ID. So that the correct PCI values

are blacklisted.

• LTE797: PM Counter Handover The PM Counter Handover feature provides more

detailed insight into handover performance.

• LTE492: ANR If an unknown physical cell ID (PCI) is detected by the Flexi MultiradioBTS, the corresponding C-plane IP-connectivity information (IP address) of the

neighbor site is resolved and the X2 signaling connection is set up in order to

exchange neighbor cell information; alternatively the X2 interface is opened for

control layer applications.

g Note: Operator hint: In RL20 the neighbor eNBs are found, and the IP address is

configured at ADIPNO-adjEnbCPlaneIpAddress. With the upgrade to RL30, the IP

address is moved into the persistent object LNADJ. During upgrade the IP address has

the characteristic LNADJ-cPlaneIpAddrCtrl= "oamControlled". As

LTE771: Optimization of Intra-LTE Neighbor Relations is based on the LNREL-eCGI to

identify the related LNADJ instance with the same eCGI, we recommend to enable

LTE492 and change all IPaddress characteristics to enbControlled. This ensures

that the LNREL-eCGI is always correctly assigned to the related LNADJ-global-eNB-ID.So that the correct PCI values are blacklisted. In addition for LTE492: ANR it is

mandatory to have an up-to-date PCI/IP address table in case of

LTE468: PCI Management - PCI changes.

• LTE782: ANR - Intra-LTE, Intra-frequency - Fully UE-based This feature covers Intra-

LTE, Intra-frequency automated neighbor relation configuration (ANR). In case an

unknown physical-layer cell ID (PCI) is detected and reported by a UE to the Flexi

Multiradio BTS, the corresponding EUTRAN Cell Global ID (ECGI) is derived with the

help of the UE-measurements. The Flexi Multiradio BTS resolves the corresponding

public IP address of the new found neighbor Flexi Multiradio BTS, and establishes

the X2 connection to exchange neighbor cell information; alternatively, opens the X2

interface for control layer applications.

g Note: Operator hint: As LTE771: Optimization of Intra-LTE Neighbor Relations is

based on the LNREL-eCGI to identify the related LNADJ instance with the same eCGI,

we recommend to enable LTE782 and change all IP address characteristics to

enbControlled. This ensures that the LNREL-eCGI is always correctly assigned to

the related LNADJ-global-eNB-ID. So that the correct PCI values are blacklisted.

Operation of LTE782: ANR - Intra-LTE, Intra-frequency - Fully UE-based requires MME

support for IP address resolution based on global-eNB-ID.


190 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• LTE53: Intra and Inter eNB Handover with X2 The Flexi Multiradio BTS supports

intra-frequency intra-LTE handover via X2. Both the intra-eNB handover and the

inter-eNB handover scenario are included. Downlink data forwarding over X2 is

applied for lossless data path switching.

• LTE54: Intra-LTE Handover via S1 The following S1 based intra-LTE handover

scenarios are supported by the Flexi Multiradio BTS:

– inter-eNB, intra-MME and intra-S-GW

– inter-eNB, inter-MME and intra-S-GW

– inter-eNB, inter-MME and inter-S-GW

• LTE55: Inter-frequency Handover The following inter-frequency handover scenarios

are supported by the Flexi Multiradio BTS:

– intra-eNB, inter-frequency band

– intra-eNB, intra-frequency band with different center frequency

– inter-eNB, inter-frequency band via X2 – inter-eNB, intra-frequency band with different center frequency via X2

– inter-eNB, inter-frequency band via S1 (if enabled)

– inter-eNB, intra-frequency band with different center frequency via S1 (if enabled)


This feature defines SON feature labels, that are automatically added as context

information for each change done by a SON function in the network configuration. In

the CM History tool it is possilbe to generate SON Reports showing the changes

done by LTE771: Optimization of Intra-LTE Neighbor Relations .

• LTE1222: ANR Auto Configuration and Scheduling

This feature is a summary of the scheduled activation use cases shifted from RL30

features to RL40 features.





tools.



5.7.1.5 LTE771:Optimization of neighbor relations management data



Alarms





Issue: 01J DN09185979 191

8/18/2019 Fd Rl40 Desc



Counter ID

Counter name

Measurement

M8015C1 Intra eNB HO attempts per neighbour cell HO attempts

M8015C8

(S1/X2)

Number of Inter eNB Handover attempts

per neighbour cell relationship

HO attempts

M8015C2 Intra eNB HO successes per neighbour cell successful HO

M8015C9

(S1/X2)

Number of successful Inter eNB Handover

completions per neighbour cell relationship

successful HO

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

Parameters



Full name

Abbreviated name

Managed object

Neighbor Relation Control nrControl LNREL

handover Allowed handoverAllowed LNREL



BSW/ASW

SW component

License control in

network element

License control

attributes

ASW NetAct - NetAct -

5.7.1.7 Abbreviations

Table 114 Abbreviations

Abbreviations

Description

ANR Automated Neighbor Relation

COC Cell Outage Compensation


192 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 114 Abbreviations (Cont.)

Abbreviations

Description

inter-RAT Inter Radio Access Technology

MOC Managed Object Class

MRO Mobility Robustness Optimization

TLA Transport Layer Address

NbEnb Neighbor eNB

NbCell Neighbor Cell

NR Neighbor Relation

NRT Neighbor Relation Table

NI Neighbor Information

RAT Radio Access Technology

5.8 LTE877: Adjustable Performance UploadIntroduction to the feature

This feature allows the operator to configure the interval of performance data upload

from Flexi Multiradio BTS to NetAct. In RL30 and earlier releases, the upload interval

was fixed to 60 minutes.

5.8.1 Benefits

End-user benefits


Operator benefits


• adjustment of performance data availability according to operator needs

• control of data transfer load distribution in the network

5.8.2 Requirements




Issue: 01J DN09185979 193

8/18/2019 Fd Rl40 Desc


System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -




The interval of performance data upload per Flexi Multiradio BTS can be configured to:

• 15 minutes

• 30 minutes

• 60 minutes

The interval period is set during the activation of Performance Measurement (PM) plan in

NetAct and BTS Site Manager. The period is configured with a new

reportingIntervalPm parameter. If the new file upload interval defined in PM planis longer than the current interval, the new value is scheduled when current upload

interval ends. If the new file upload interval is shorter than the current interval, the new

value is scheduled for the nearest triggering point of the new PM plan.

The eNB performs automatic upload of the result PM files towards NetAct according to

defined schedule right after the result PM file creation.

5.8.4 System impact






The upload interval is configured with a new parameter that is part of the system

configuration file.




194 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


5.8.5 LTE877: Adjustable Performance Upload management data



Alarms






Parameters



Full name

Abbreviated name

Managed object

LTE Performance Measurement Data

Reporting Interval

reportingIntervalPm PMCADM



BSW/ASW



BSW - -

5.9 LTE940: SW Verification Agent


The Flexi Multiradio 10 BTS provides a secured boot-up and the LTE940: SW

Verification Agent feature verifies the integrity of the eNB software before it is run.

5.9.1 Benefits

End-user benefits


Operator benefits

This feature offers significantly enhanced risk management. Only integrity-verified code

is accepted for execution.


Issue: 01J DN09185979 195

8/18/2019 Fd Rl40 Desc


5.9.2 Requirements



System release


Flexi Multiradio 10

BTS

iOMS

RL40 MP - LBTS4.0 -


UE

NetAct

MME

SAE GW

- - - -


This feature requires Flexi Multiradio 10 BTS with A.1xx or A.Mxx hardware version.


Secure boot enforces the verification and execution of integrity-verified software in a

predefined sequential order. The software that verifies the integrity of the next executable

software is called Software Verification Agent. Software Verification Agents ensure thatno malicious code is inserted.

eNB boot-up phase

At the eNB boot-up phase, the Software Verification Agent examines the software in the

following order:

1. boot loader

2. operating system

3. application software

Each part of the software is integrity-verified before executing and going to the next step.

The eNB behavior in case of verification error depends on the software the eNB isrunning on:

• eNB runs SW with hard security disabled

If any software integrity check fails, the eNB registers the event in the system log but

the boot-up process continues.

• eNB runs SW with hard security enabled

If the integrity verification of the primary boot loader fails, the alternative copy of the

software (passive boot loader) is integrity-verified and if successful, the boot-up

process continues. If the verification of the primary and passive boot loader fails, the

boot-up process cannot continue. At this phase, the eNB is not accessible yet by

BTS Site Manager and therefore must be sent back to the factory for repair.


196 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


If the verification of the boot loader software succeeded, but the integrity check of the

operating system failed, the eNB continues the boot-up process until “Integrated to

RAN” state. Because of integrity verification failure, the eNB is not operational but

this state allows for eNB restoration by new software installation using BTS Site

Manager.

Failed software integrity verification raises the Validation of signed file failed fault

in the eNB.

t Tip: Refer to Release Documentation included to software release to know if the

software package has hard security enabled or disabled.

Feature activation and configuration

This feature does not require activation and it is switched on by default. However, before

installing a software package with hard security enabled for the first time, make sure the

eNB is running software that signs new software (at least RL40 P8 MP version). For

detailed procedure, see Release Delivery Upgrade Instructions in ReleaseDocumentation included to each software package.

w NOTICE: Not following the upgrading procedure described in Release Documentation

might cause the eNB to stop working and in some cases the need to send the eNB to

the factory for repair.

5.9.4 System impact







tools.



5.9.5 LTE940: SW Verification Agent management dataFor information on alarm, counter, key performance indicator, and parameter documents,


Alarms



Issue: 01J DN09185979 197

8/18/2019 Fd Rl40 Desc



Alarm ID

Alarm name

7651 BASE STATION OPERATION DEGRADED*

7654 CELL OPERATION DEGRADED*

7655 CELL NOTIFICATION*

Above alarms are caused by the following BTS fault: BTS SW download or activation failed

(fault ids: 29, 30)

7650 BASE STATION FAULTY

The alarm is caused by the following BTS fault: Validation of signed filefailed (fault id: 4145) )





Parameters

There are no parameters related to this feature



BSW/ASW


element


BSW - -

5.10 LTE953: MDT (Minimization of Drive Test)Introduction to the feature

This feature is introduced as an alternative for expensive drive tests performed during

network deployment and optimization. The solution focuses on coverage optimization in

the intra-frequency LTE network.

5.10.1 Benefits

End-user benefits


Operator benefits


198 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



• a simple method to analyze the network behavior in a certain area for coverage

optimization purposes

• automated collection of trace data together with the UE measurements in form of

preconfigured profiles

• OPEX and CAPEX savings as a result of reducing resources needed to evaluate the

service and network performance (reduction of expensive drive tests)

5.10.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -




The feature offers a predefined set of MDT profiles available at the NetAct TraceViewer

application. The profiles were designed to cover the following use cases:

• detection of coverage problems in the neighbor cell

• detection of coverage problems in the traced cell

• monitoring the coverage quality of the traced cell

One predefined profile covers both detection use cases. The second profile covers the

monitoring use case. For each use case, there is a set of RRC, S1AP, and X2AP

protocol messages that need to be collected for further analysis. The solution is based

on data that is collected using the following features:

• LTE433: Cell Trace

• LTE644: Configurable cell trace content

• LTE570: Periodic UE Measurements

By selecting an MDT profile, the corresponding configuration of the trace feature

(together with the additional features) and the UE measurements is done for the selected

area. The monitoring use case is based on periodic UE measurements. Some


Issue: 01J DN09185979 199




8/18/2019 Fd Rl40 Desc


modifications to LTE570: Periodic UE Measurements feature configuration are

introduced (the reportAmount andreportInterval parameter value ranges are

extended) to collect either more measurements per UE with a longer interval or less

measurements with a shorter interval. As the UE measurement requests might cause

quite a big load in the network, it is not recommended to apply it in the whole network at

the same time. The collected data is available in the NetAct TraceViewer or a 3rd party

protocol analyzer.

The LTE953: MDT feature is active when the actMDTCellTrace parameter value is

set to true. If the actMDTCellTrace parameter value is set to false during an active

trace session, all the MDT trace sessions will be stopped and MTRACE objects are not

deleted. In this case, the TraceViewer might not show the correct status of the trace

session that has been stopped. Therefore, it is recommended to delete first the MTRACE

objects before setting the actMDTCellTrace parameter value to false.

g Note: In RL40, the same parameter enables the LTE570: Periodic UE Measurements

feature. In RL30, this feature has a separate enabling parameter (actPeriodicIntraUeMeas).



This feature is based on the following features:

• LTE433: Cell Trace

• LTE459: Timing Advance Evaluation

• LTE644: Configurable cell trace content

• LTE162: Cell Trace with IMSI• LTE570: Periodic UE Measurements

The LTE953: MDT feature replaces LTE570: Periodic UE Measurements, so if the

LTE953 is deployed in the network, the LTE570 is not available. The activation of

periodic UE measurements is done together with the activation of cell trace with the MDT

profile.




The MDT profiles can be selected using the NetAct TraceViewer application. The user selects the profile during the trace session creation. The profile includes:

• the selection of protocol messages to be traced

• the configuration of periodic intra-frequency UE measurements (in the monitoring

use case)


The impact on system performance and capacity is comparable to the impact caused by

LTE570: Periodic UE Measurements and LTE433: Cell Trace.


200 DN09185979 Issue: 01J


8/18/2019 Fd Rl40 Desc


5.10.5 LTE953: MDT (Minimization of Drive Test) managementdata



Alarms






Parameters



Full name

Abbreviated name

Managed object

Activate MDT cell trace actMDTCellTrace LNBTS



Full name

Abbreviated name

Managed object

Periodic UE measurements (structure) periodicUeMeas LNCEL

Activate measurement activateMeas LNCEL

Measurement type measurementType LNCEL

Report amount reportAmount LNCEL

Report interval reportInterval LNCEL

g Note: With the introduction of LTE953: MDT, the reportAmount and

reportInterval parameter value ranges are extended.

The previous enabling parameter for LTE570: Periodic UE

Measurements (actPeriodicIntraUeMeas) is replaced with actMDTCellTrace

in RL40.


Issue: 01J DN09185979 201

8/18/2019 Fd Rl40 Desc




BSW/ASW



ASW NetAct - -

5.11 LTE1019: SON Reports

5.11.1 Description of LTE1019: SON Reports


The LTE1019: SON Reports feature provides a report mechanism for the parameter

changes made in the network, especially with a focus on automatic changes made for

configuration parameters.

5.11.1.1 Benefits

End-user benefits


Operator benefits

The operator gets an overview of which parameter changes have been executed in thenetwork by which (SON) functionality.





System release


Flexi Multiradio 10

BTS

OMS


UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -




202 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



Functional overview

In the LTE releases the set of SON features executing automatic parameter changes isincreasing.

The LTE1019: SON Reports feature provides a report mechanism for the parameter

changes done in the network, especially with focus to automatic changes done for

configuration parameters.

The NetAct originated SON features, which generate automatic changes to parameters

that are kept in the eNB CM database can make use of this feature and include

additional information about the applied change to the user.

This reporting mechanism is not limited to SON features only, but SON features are the

ones using it first.

5.11.1.3.1 Change origin report

The change origin report provides the possibilities to retrieve information for the operator

about:

• which feature has changed the value of a parameter

• which parameters have been changed by which feature

• who (feature/operator) changed that related parameter and which change has been

done

• which changes have been done in a specified time frame

This solution is applied in the same way for NetAct originated SON features and as well

applicable to other features outside of SON.

In case of manual operator-driven changes for these parameters, these changes are

included in the report with the operator as the owner of the change.

Depending on the parameter change, the origin of the change has to be given in a

manner to allow operators understanding which functionality changed the value. If it is

not possible to assign a dedicated feature, then also a kind of placeholder is allowed

(which at least still allows to distinguish operator/eNB-driven changes and central-driven

changes).

NetAct provides the means for the operator to access this change origin information and

to generate reports.

The following features apply the change origin report mechanism:

• LTE539: Central ANR

• LTE783: ANR Inter-RAT UTRAN

• LTE784: ANR Inter-RAT GERAN

• LTE510: Synchronization of Inter-RAT Neighbors

• LTE771: Optimization of Intra-LTE Neighbor Relations

• LTE581: PRACH Management

• LTE533: Mobility Robustness

• LTE502: Cell Outage Triggered Reset

• LTE468: PCI Management

• LTE507: InterRAT Neighbor Relation Optimization (LTE, UTRAN, GERAN)


Issue: 01J DN09185979 203

8/18/2019 Fd Rl40 Desc


• LTE962: RACH Optimization

• LTE1367: Automatic Cell Combination Assignment for Carrier Aggregation

• LTE1808: Automatic PUCCH Capacity Optimization

• LTE1951: Automatic Configuration Support for CA for Multi-carrier eNBs• LTE2020: PRACH Management Optimization for HetNet

Configurable change history storage time

The user is able to configure how long is the NetAct CM history stored. The time is

related to the NetAct capacity and details are defined in NetAct documentation.

5.11.1.3.2 SON reporting mechanism

In Figure 22: NetAct-originated parameter change the orange line describes the NetAct-

originated SON parameter change where the Optimizer sends the SON feature

information in addition with the plan to the Configurator (contains CM plan prepare, CM

operations, CM mediator, CM event handler, RAC Access and CM history UI). The

Configurator prepares and activates the plan into eNB(s). When the plan is activated the

eNB(s) sends the configuration change notifications to the NetAct Configurator.

g Note: With the planID the NetAct is able to map configuration changes done in the eNB

to SON changes (SON report) activated from NetAct.

The Configurator correlates the SON feature information into changed parameters. From

the CM history the user is able to obtain the information which SON feature has changed

the parameter(s).


204 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 22 NetAct-originated parameter change

Optimizer

CMPlan

Prepare

CM

Operations

change payload

change contextEM

eNBCM

Mediator

CM EventHandlerRACAccess

CM

History

UI

Netact

Reporting

Suite

SON Reports

CM Change History

SON Reports

CM+PM KPI

ConfDB ChlogDB

Correlator

5.11.1.3.3 SON reporting content

NetAct originated SON features

are features that:

• NetAct is responsible for the parameters optimization, decision for triggering specific

behavior for the optimization/organization of NEs

• NetAct has/implements dedicated functions/algorithms for the

optimization/organization purpose

• for example:

– LTE539: Central ANR

NetAct Optimizer generates adjacency information and generates parameter

configuration providing for the automatic creation and establishment of neighbor

relations between Flexi Multiradio BTS. The NetAct manages the feature

parameter change information into NetAct CM History.

– LTE783: ANR Inter-RAT UTRAN

The automated planning of neighbor relation to UTRAN cells is done on NMS

level with the help of NetAct Configurator and Optimizer. This feature prepares

neighbor relations for each LTE cell in the optimization scope and UTRAN

automatically based on current LTE and legacy UTRAN network configuration

data with an intelligent algorithm in Optimizer to identify possible UTRAN

neighbor cells. The NetAct manages the feature parameter change information

into NetAct CM History.


Issue: 01J DN09185979 205

8/18/2019 Fd Rl40 Desc


– LTE784: ANR Inter-RAT GERAN

The automated planning of neighbor relation to GERAN cells is done on NMS

level with the help of NetAct Configurator and Optimizer. This feature prepares

neighbor relations for each LTE cell in the optimization scope and GERAN

automatically based on current LTE and legacy GERAN network configuration

data with an intelligent algorithm in Optimizer to identify possible GERAN

neighbor cells. The NetAct manages the feature parameter change information


– LTE510: Synchronization of Inter RAT Neighbors ANR Inter-RAT GERAN

Feature LTE783: ANR Inter-RAT UTRAN and LTE784: ANR Inter-RAT GERAN

enable an operator to configure Inter-RAT neighbor relations when new LTE

eNBs are existing/created using pre-planned data (network planning and

configuration file download onto Flexi Multiradio BTS). The established Inter RAT

neighbor relations are also updated/synchronized automatically. Feature LTE510:

Synchronization of Inter-RAT Neighbors adds mechanism to establish new Inter-

RAT neighbor relations also in case new UTRAN/GERAN cells are created to

optimization scope of an existing LTE cell. The NetAct manages the feature

parameter change information into NetAct CM History.

– LTE581: PRACH Management

An automatic assignment of PRACH settings is provided. NetAct Optimizer

derives out of input parameters the output parameters that are used in selected

eNB's. This process is embedded into the LTE720: Auto Configuration frame

work. The NetAct manages the feature parameter change information into NetAct

CM History.

– LTE533: Mobility Robustness

This feature aims to enable improvements of the system performance by

optimizing the Intra-LTE radio network HO-configuration. Base for evaluating

suboptimal HO performance will be the existing new PM counters, collected bythe Flexi Multiradio BTS and reported to NetAct. NetAct will visualize the PM-

counters, indicate performance problems and, possibly, propose new settings for

the above listed parameters at specific Flexi Multiradio BTS. In case of

parameter change NetAct manages the feature parameter change information


– LTE502: Cell Outage Triggered Reset

The detection mechanism of the existing feature: Cell Outage Detection will raise

dedicated quality of service alarm for a cell in case it has been detected as

"sleepy cell". Based on this specific alarm an action will be triggered

automatically to get the cell back into service. In case of parameter change

(restart request) NetAct manages the feature parameter change information into

NetAct CM History.

– LTE468: PCI Management

The Physical Cell ID assignment is done automatically and collision detection

does allow operator to optimize the network settings. Automatic optimization is

supported with Optimizer. In case of parameter change NetAct manages the

feature parameter change information into NetAct CM History.

– LTE771: Optimization of Intra-LTE Neighbor Relations

NetAct Optimizer supervises all registered cell relations between neighboring

LTE cells if they are still valid and reliable candidates to be a hand over

destination. When the outcome results in an inefficient neighbor relation the

corresponding cell relation may be blacklisted for handover. In case of parameter

change NetAct manages the feature parameter change information into NetAct

CM History.


206 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


– LTE507: InterRAT neighbor relation Optimization (LTE, UTRAN, GERAN)

NetAct Optimizer supervises all registered Inter Radio Access Technology (inter-

RAT) neighbor cell relations between LTE cells and non-LTE cells. Their

performance is good enough so they are used for a handover (HO) execution.

When the outcome results in an inefficient neighbor relation (NR), the individual

mobility procedures of NRs might be blacklisted for an HO.

– LTE962: RACH Optimization

The LTE962: RACH Optimization feature offers an automated solution for

optimization of RACH parameters used in LTE cells. It identifies and resolves

conflicts and inconsistencies arising due to incorrect configuration of RACH

parameters. The NetAct Optimizer supports the RACH conflict and inconsistency

detection and resolution.

– LTE1367: Automatic cell combination assignment for Carrier Aggregation

The LTE1367: Automatic cell combination assignment for carrier aggregation

feature introduces an automatic algorithm to detect and configure cell pairs of a

certain eNB appropriate for a carrier aggregation functionality. It can be usedduring planning activities in the NetAct Optimizer.

– LTE1808: Automatic PUCCH Capacity Optimization

The automatic Physical Uplink Control Channel (PUCCH) capacity optimization is

a SON feature working in a hybrid manner. Based on performance management

data and actual configuration information, an iSON manager determines a new

optimized PUCCH and dependent configuration changes. These changes may

result in configuration changes that are automatically downloaded and activated

if requested.

– LTE1951: Automatic Configuration support for CA for multi-carrier eNBs

The LTE1951: Automatic Configuration support for CA for multi-carrier eNBs

feature is a NetAct SON solution offering an automatic assignment of the cells for

the usage of the LTE1562: Carrier aggregation for multi-carrier eNBs feature.The NetAct Optimizer provides an algorithm that automatically determines the

cells of one eNB that are appropriate for the LTE1562: Carrier aggregation for

multi-carrier eNodeB and LTE2033: Additional carrier aggregation band

combinations - I features. The algorithm detects overlapping cells in exactly the

same manner as in the LTE1367: Automatic cell combination assignment for

Carrier Aggregation feature.

– LTE2020: PRACH Management Optimization for HetNet

The LTE2020: PRACH Management Optimization for HetNet feature is an

addition to PRACH Management algorithms (LTE581: PRACH Management and

LTE962: RACH Optimization) and thus the main rules and use cases for these

features still remain in place.

SON parameter change content in the eNB

g Note: In case of a plan originated SON change in the eNB, the eNB includes the Plan

ID and the change origin in the confChangeOrigin information in the CM event.

The Plan Id and the changeOrigin in the confChangeOrigin improves the usability of the

change origin information in the NetAct. The SON history feature in NetAct is able to

correlate CCN's with activated plan when the plan ID is included in CCN's. The eNB fills

in the plan ID and changeOrigin into CCN's.

The NetAct configuration management is able to correlate plan ID to relevant SON

feature in case the change is made by NetAct Optimizer.


Issue: 01J DN09185979 207

8/18/2019 Fd Rl40 Desc


g Note: For the LTE1019: SON Reports the data are covered by the specific feature

impacted by the generic feature itself.

• LTE507: Inter-RAT Neighbor Relation Optimization

• LTE1383: Cell-specific Neighbor Relation/PCI Hangling

• LTE556: ANR Intra-LTE Inter-frequency UE Based

• LTE1708: Extend Maximum Number of X2 Links

• LTE908: ANR Inter-RAT UTRAN - Fully UE Based

• LTE1685: Neighbor Relation Robustness

• LTE1821: Neighbor Detection Optimization for NetNet

• LTE1822: PCI Assignment Optimization for HetNet

• LTE1823: Neighbor Prioritization Optimization for NetNet

Change origin information listed for all NetAct SON features

The change origin information indicated to the operator is listed for all NetAct SON

features:








• LTE502: Cell Outage Triggered Reset• LTE468: PCI Management

• LTE492: ANR

• LTE720: SON LTE BTS Auto Configuration

• LTE507: InterRAT neighbor relation Optimization (LTE, UTRAN, GERAN)


• LTE1367: Automatic cell combination assignment for Carrier Aggregation


• LTE1951: Automatic Configuration support for CA for multi-carrier eNBs

• LTE2020: PRACH Management Optimization for HetNet



SON features making use of change origin reports.

The following features apply the change origin report mechanism:







208 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc




• LTE502: Cell Outage Triggered Reset

• LTE468: PCI Management • LTE507: InterRAT neighbor relation Optimization (LTE, UTRAN, GERAN)


• LTE1367: Automatic cell combination assignment for Carrier Aggregation


• LTE1951: Automatic Configuration support for CA for multi-carrier eNBs






follows:

• NWI3 managed object extension is taken into use in eNB and NetAct




For the LTE1019: SON Reports feature the data are covered by the specific feature

impacted by the generic feature itself.



Alarms






Parameters




BSW/ASW



BSW - -


Issue: 01J DN09185979 209

8/18/2019 Fd Rl40 Desc


5.12 LTE1045: Full SON support for distributed sites

5.12.1 Description of LTE1045: Full SON Support for DistributedSites


The LTE1045: Full SON Support for Distributed Sites feature introduces differentiation of

information at an antenna site's location for distributed site deployments.

The SON algorithms calculating possible neighbor sites are adapted to consider the site

location information from antenna.

Most of the SON features are based in 3 sector site deployment with:

•

common site location for all cells• handling of all cells of one eNB commonly

• up to 200m distance between system module and RF unit

• outdoor macro network deployment

5.12.1.1 Benefits

End-user benefits

The LTE1045: Full SON Support for Distributed Sites feature does not affect the end-

user experience.

Operator benefits

The distributed sites specifics are considered in SON algorithms, allowing a full featuresupport.



Table 127: Software requirements lists the software required for the LTE1045: Full SON

Support for Distributed Sites feature.

System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

not relevant OSS5.4 CD2 not relevant not relevant



210 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The LTE1045: Full SON Support for Distributed Sites feature requires the following

hardware:

• FSM R2

• FSM R3


Functional overview

This feature includes the introduction of antenna location information differentiation for

distributed site deployments.

• support of RRH (remote radio head) configurations

• support of BTS hotel configurations

The SON algorithms calculating possible neighbor sites are adapted to consider the site

location info from antenna.

The following SON features are enhanced by LTE1045: Full SON support for distributed

sites feature:

• LTE468: PCI management


• LTE492: ANR

• LTE581: PRACH management

• LTE783: ANR InterRAT UTRAN

• LTE784: ANR InterRAT GERAN

• LTE510: Synchronisation of InterRAT neighbors

• LTE1821: Neighbor Detection Optimization for HetNet

• LTE1822: PCI Assignment Optimization for HetNet

• LTE1823: Neighbor Prioritization Optimization for HetNet


to support:

• geo-location per cell

• the input of antenna geo-location data is done manually by the operator

• check for distributed site deployment via the LNBTS - parameter

actDistributedSite = <true, false>

The approach is also applicable for RF chaining with separate cells.

g Note: Distributed GERAN and UTRAN sites are out of scope of this feature. The

correct provision of GERAN and UTRAN cell geo-location data is a basic requirement

for the LTE783: ANR InterRAT UTRAN/LTE784: ANR InterRAT GERAN feature.

User scenarios

The following user scenarios are part of this feature and are supported by basic NetAct

functionality. For those features no additional SW requirements are required:


Issue: 01J DN09185979 211

8/18/2019 Fd Rl40 Desc


• Setting of site geo-locations (minimum requirement for SON features) The network

operator wants to store at NetAct the site geo-locations before the LTE eNB are

installed or during the operation of an eNB. He wants to enter the geo-locations

manually or import via tool at Itf-N. He wants to identify an eNB with its global eNB

ID, site name or cell name.

• Finding of distributed RRH configurations with antenna geo-locations and missing

geo-location data. The network operator wants to list cells for those no antenna geo-

location is available. He wants to see, for what cells some data is still missing. Those

eNBs with a site geo-location that is equal to the antenna geo-location are marked

accordingly.

• Finding of antenna geo-locations with distributed antenna geo-locations. The network

operator wants to list cells with different antenna geo-location than the site geo-

location. He wants to see the distance between site and antenna, to verify quickly the

correct setting at an eNB.

• Re-execution of SON features with updated antenna geo-locations. The network

operator wants to have updated parameter settings for those SON features that arebefore executed on site geo-locations, and are later on executed with the newly set

of antenna geo-locations. In addition any update of geo-location data (corrected

values) is considered for the next execution of a SON function.

5.12.1.3.1 NetAct Optimizer

For support of distributed RRH and BTS hotel configuration the service area of a cell can

be up to 20 km (LTE614:Distributed Site) away from the BTS location. The service area

is defined rather by the location of the antenna than the BTS hardware. To take the

difference in location into the account, the NetAct cell supports the usage of antenna

coordinate information in the centralized SON solutions where applicable.

If the antenna coordinate is missing, NetAct uses the site coordinate information instead.

If also the site coordination is missing, the related object is excluded from SON

algorithms, the process aborts and the user is informed. For distributed sites the

antenna/cell geo-location data are mandatory. If those are not available, the eNB plan file

is not consistent and the download is not allowed by NetAct. The SON function running

in auto-configuration or scheduled mode aborts.

For PRACH and PCI management, the NetAct requires geo-location data for distributed

site configurations. If those are missing, the SON function is stopped and the operator is

informed. The NetAct identifies a distributed site configuration by the value of LNBTS

actDistributedSite parameter to be set to true.

The NetAct supports the usage of the antenna coordinate information for:


The NetAct Optimizer considers the antenna coordinates when optimizing the PCI

reuse distance. Consistency check function.


The NetAct Optimizer considers antenna coordinates when creating the list of

preconfigured neighboring eNBs (LNAJDLs).

• LTE492: ANR

The NetAct Optimizer considers antenna coordinates when building the PCI-RF-IP

address mapping table entries from within the search distance based on the ranking

(priority function).



212 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The NetAct Optimizer includes information into the feedback messages, where

antenna coordinates were missing, the fallback to site coordinates has happened

and where coordinate information in total is missing. For distributed sites the

antenna/cell geo-location data are mandatory. If those are not available the eNB plan

file is not consistent and download is not allowed by the NetAct.


The NetAct Optimizer considers antenna coordinates when determining the PRACH

configuration reuse distance.

Consistency check function.


The NetAct Optimizer considers antenna coordinates in ranking the neighbor relation

candidates (priority function) and defining the search distance.


The LTE1045: Full SON Support for Distributed Sites feature uses LTE site and/or

LTE antenna geo-locations, instead of currently the site geo-location only. The

GERAN geo-locations are provided as site locations. The LTE feature makes use of GERAN cell/antenna geo-locations as input.

• LTE510: Synchronization of InterRAT Neighbors

The NetAct Optimizer considers antenna coordinates when automatically defining

the LTE scope for which synchronization is executed.

• In all manual, interactive execution of relevant above feature components, the NetAct

Optimizer informs the user up-front about missing coordinate information. The user

can then decide to fix the missing information or to continue with fallback or skipping

the objects with missing information (exclude from SON operation). For distributed

sites the antenna/cell geo-location data are mandatory. If those are not available, the

eNB plan file is not consistent and download is not allowed by the NetAct.

gNote: The LTE614: Distributed Sites feature requires a correct upgrade in RL40. Herethe antenna/cell geo-location data will be mandatory and need to be correctly

referenced by the cell object. A SON function based on geo-locations (as

LTE539: Central ANR , LTE468: PCI Management , LTE492: ANR ,

LTE510: Synchronisation of InterRAT Neighbors, LTE783: ANR InterRAT UTRAN ,

LTE784: ANR InterRAT GERAN ) checks a lot of (potential) neighbors; therefore not only

the defined scope of cell need to have consistent data, but also the other cells. In

numerous cases NetAct scans through all cells. For example the PCI values of an new

eNB's cells can only be correctly assigned, if all potential neighbors can be identified by

their antenna geo-location to obtain the list of used PCI values in the neighborhood.

gNote: The eNB-based ANR features LTE492: ANR and LTE782: ANR Fully UE based

are based on the basic mobility handling of the eNB. The mobility management requires

unique PCI values for all neighbor cells of one eNB. This is for distributed site

deployments not considered in standard 3GPP compliant PCI management. The ANR

function will find in one cell a PCI/CGI. Distributed cells might have other PCI/CGI

assignments. It depends on the first UE reporting the PCI in one cell, and therefore this

PCI/CGI assumptions might be wrong. The LTE468: PCI Management feature knows

this eNB behavior and assigns PCI unique on eNB level as well.


Issue: 01J DN09185979 213

8/18/2019 Fd Rl40 Desc


g Note: The LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU) or similar

LTE1106: FHCB Flexi RRH 2TX 850 Low Power for Optical Repeater Interface and

LTE1337: FHEC Flexi RRH 2TX 1800 Low Power features represent repeater units that

are usually installed within the same covarage area as the macro cell. Therefore, theLTE1045: Full SON Support for Distributed Sites feature has to check only for the

macro cell. As repeater supports a dedicated mode, where a repeater is configured like

a normal cell with up to 20 km distance, the operator needs to configure the correct

antenna geo-location data at NetAct. The

LTE1045: Full SON Support for Distributed Sites feature does not check consistency of

such special deployments, as those are often 3rd party products.

g Note: For Repeater configurations (the

LTE1195: FHCC Flexi 850 Repeater Interface Unit (RIU)feature) working in dedicated

repeater mode, the operator has to care for the correct antenna geo-location data

setting. The repeater configurations are not considered in the deployment compatibility

check (as for theLTE614: Distributed Site).

5.12.1.3.2 NetAct use case

This use case describes the preparation phase for the installation of a new eNB with

distributed cell configuration. The operator does select one or more eNBs to be auto-

configured within the next planned network roll-out phase.

Preconditions

The eNB plan file is containing the transport and the equipment configuration. The

planned radio configuration without any SON feature generated content is available and

the required cells and PLMN configuration is in place. No antenna/cell coordinates areprovided, but the site coordinates are available at NetAct from planning data. The

planned site have a distributed cell configuration.

Description


1. The operator starts at NetAct Configurator the SON workflow for this planned eNB.

2. The operator activates the feature distribute site configuration (the LTE614:

Distributed Site) for this site.

3. NetAct checks the availability of cell/antenna geo-location data. NetAct informs the

operator about the missing data and blocks the download of the eNB plan file. NetAct

does not allow the execution of SON functions for this eNB.

4. The operator configures all required cell/antenna geo-location data.

5. NetAct checks the availability of cell/antenna geo-location data. NetAct allows the

activation of SON functions for this eNB.

6. The operator can continue the execution of SON functions for this eNB.

Post conditions

For distributed sites the cell/antenna geo-location are available and all SON function in

the auto-configuration suite can operate as defined.




214 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The following SON features consider the new location information:

• LTE614: Distributed Site

The Distributed Site Solution is a LTE BTS site where the distance between the

System Module and RF Module or RRH can be up to 20 km. The single mode opticalcables and single mode optical transceivers (SFP) need to be used to connect the

System Module to the RF Module or RRH.

• LTE977: RF Chaining

RF units can be chained in Distributed LTE BTS configurations to support extended

and optimized coverage and capacity. In feeder less LTE BTS configurations the

length of optical cables can be minimized. Up to two RF Units (one cell RRH or RF

Module with 2TX MIMO) per chain and up to 3 chains hence maximum 6 RF units

and LTE cells per one System Module (FSME).

• LTE973: Flexi RF Module 4TX 2500 FZOB

One cell Flexi RF Module is able to support 4-branch beam forming. It enables easy

installation outdoors close to antennas thus maximizing BTS site capacity and

coverage for one sector. The distance between the RF module and the System

module up to 200m (Multimode SFP) and up to 40 km (Single mode SFP) is

supported by the hardware.


This feature uses site and/or antenna geo-location. Today, the eNB call processing,

does consider all configured PCI value on eNB level, to decide on unknown PCI

values for ANR features. The assumption is, that the learning of one cell can be

reused for the other cells. For distributed cells, it is better to have only the own cell's

relationships considered for PCI collision or confusion detection and sending the

eNB alarm. On NetAct level the reuse distance is based today on the site location,

but when the antenna locations are provided those are used, this is prepared for

LTE1045: Full SON Support for Distributed Sites.


This feature uses site and/or antenna geo-locations, instead of currently the site geo-

location only. The best cell of the neighbor will define the eNB neighbor ship.

• LTE492: ANR


location only. Because of the re-use of the LTE539: Central ANR algorithm, also here

an eNB aspect is considered, as the best cell of the neighbor will add also all other

cells immediately. Possibly with distributed cell locations only the relevant cells need

to be added.


This feature expects compliant eNB plan file to be downloaded and activated. A

missing geo-location does lead to sub-optimal configuration of LTE468: PCI Management and LTE581: PRACH Management parameter. Therefore,LTE1045:

Full SON Support for Distributed Sites has impact on LTE720: Auto Configuration to

abort the auto-configuration and to give feedback to the operator about this

incompliant situation



location only. This feature does work on cell level yet. As soon as the cell data are

given for distributed deployments, then intrinsically the algorithm works correctly.


This feature uses LTE site and/or LTE antenna geo-locations, instead of currently the

site geo-location only. The UTRAN geo-locations are provided as site locations. The

LTE feature uses UTRAN cell/antenna geo-locations as input.


Issue: 01J DN09185979 215

8/18/2019 Fd Rl40 Desc




site geo-location only. The GERAN geo-locations are provided as site locations. The

LTE feature makes use of GERAN cell/antenna geo-locations as input.

• LTE510: Synchronisation of InterRAT neighbors


site geo-location only. The UTRAN/GERAN geo-locations are provided as site

locations. The LTE feature makes use of UTRAN/GERAN cell/antenna geo-locations

as input.

The approach is also applicable for RF chaining with separate cells.

The feature has no influence on the following features:

• LTE154: SON LTE BTS Auto Connectivity

• LTE663: GPS Location and Time Retrieval


The auto-connection features support site geo-location mapping to the prepared eNB

plan file at NetAct. They don’t support antenna geo-location configuration. The setting of

the antenna geo-location data is not generating a SON Report ( LTE1019: SON Reports,

as setting of those data is manual configuration.


The LTE1045: Full SON Support for Distributed Sites feature has no impact on

interfaces.

The LTE1045: Full SON Support for Distributed Sites feature has no impact on network

management or network element management tools.


The LTE1045: Full SON Support for Distributed Sites feature has no impact on system

performance or capacity.


For the LTE1045: Full SON Support for Distributed Sites feature the data are covered by

the specific feature impacted by the generic feature itself.



Alarms






Parameters



216 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc




BSW/ASW



BSW - -

5.12 Variable Definitions

5.13 LTE1078: System Upgrade with Backward

CompatibilityIntroduction to the feature

This feature enables the smooth upgrade from major release RL30 to release RL40 in

the overall network.

5.13.1 Benefits

Operator benefits

This feature benefits the operator in smooth remote upgrade path from major release

RL30 to release RL40.

5.13.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 plus PCD - -



This feature does not include the upgrade of Flexi System Module FSME/FSMD to

FSMF.


Issue: 01J DN09185979 217

8/18/2019 Fd Rl40 Desc



Functional overview

The system upgrade is performed in a top down approach starting with NetAct followedby OMS and followed by an eNB SW upgrade as shown in the Figure 23: Top down

upgrade approach. Service outages are minimized by using available resiliency features

and hardware redundancy as far as possible. It is not possible to take the whole system

out of service to introduce the new SW release.

As a consequence of this approach, NetAct supports at least two OMS releases and two

eNB releases (LBTS4.0, LBTS3.0). OMS of SW release RL40 supports two eNB

releases (LBTS4.0, LBTS3.0). Also mixed eNB and OMS configurations are supported

by OMS and NetAct.

g Note: It is possible also to perform system upgrade from RL30 to RL40 MP1 directly.

Figure 23 Top down upgrade approach

OMS (1)

release n

OMS(2)

release n-1

NetAct

release n

OMS (1)

release n

eNB(1)

release n

OMS (1)

release n

eNB(2)

release n-1

OMS (1)

release n

eNB(3)

release n-1

eNB4)

release n-1

NetAct

release nStep 1

Step 2

Step 3

t o p d o w

n

Upgrade path

• NetAct upgrade

– OSS5.3 MP1 -> OSS5.3 MP2 -> OSS5.4 CD2 plus PCD

– OSS5.3 MP1 -> OSS5.4 CD1 -> OSS5.4 CD2 plus PCD

For more information on NetAct upgrade see Description of the Commissioning

andUpgrade Procedure, available in NOLS at the following path.

Product Information -> Product Finder -> Operations Support Systems -> Network

and Service Management -> NetAct (OSS5): Documentation -> NetAct, Rel. OSS5.4

CD Set 2 Priority CD, Operating Documentation, issue 01

• OMS upgrade

LTE OMS 3.0 -> LTE OMS 4.0

• eNB upgrade

SW upgrade LBTS3.0 -> LBTS4.0The following functionality is supported with the upgrade from RL30 to RL40:


218 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


1. Supported RL30 SW versions for one step upgrade towards RL40 are listed in the

RL40 Release Documentation.

2. All operator configured data is maintained in the system. Configuration data is

converted into a new format. This implies that the data from the previous release canbe reused after the upgrade. No manual intervention is required.

This data includes:

a) all configuration data of the Flexi Multiradio BTS

b) adaptations done by operator for different (graphical) presentations in BTS SM or

NetAct (for example top level user interface: topology view)

The eNB data migration is performed automatically by the eNB during the

startupphase of the new SW. The migration operation includes:

a) copying configuration data from release LBTS3.0

b) checking data compatibility

c) preparing data for the new SW release, like conversion of parameters to the newformat and/or provision of defaults for parameters or parameter value where

necessary

The data migration includes all configurable data like eNB, TRS and RNW

configuration data. OMS is required to provide conversion for internal OMS

configuration data like LDAP parameters (including user accounts) and

autoconnection data.

No conversion for topology and alarms is needed, because this data is regained from

eNB after restart.

While the eNB data conversion logging is enabled, the data conversion exceptions

can be analyzed from the log file. This is possible even if data conversion caused

fallback. Log file is kept reset safe. Different log files are in use for Transport and

BTS/RNW data conversion logging.3. System data is stored before system upgrade. The data is available after upgrade.

This data includes:

a) user security, for example user accounts/passwords, log files

b) network security, for example certificates, keys

No manual activities to reconfigure or reload system related data is necessary.

4. BTS SM is prepared to handle both eNB releases, at least as co-existing versions of

BTS SM with release RL40.

5. The downtime of a network entity during the system upgrade is reduced to the

activation of the new software. The switch to the new release (activation of the

software) is performed on operator request from NetAct or BTS SM.6. In case of an upgrade failure an automatic fallback to the original release takes

place. The automatic fallback avoids a situation where an eNB is completely out of

service and service personnel is needed on site for repair action. In addition the

fallback can be initiated on operator command from NetAct or BTS SM.

Automatic fallback

The eNB performs automatic fallback to former SW version and former configuration

data in case of critical SW exceptions. No manual interaction is necessary.

Critical exceptions are for example:

• SW does not start up (restart loop), the limit is three restarts in a short period of time

• data conversion exceptions - at least critical ones


Issue: 01J DN09185979 219

8/18/2019 Fd Rl40 Desc


While some abnormal exeption occures service interruption must be minimized. When

eNB does not startup with new SW version it is not possible to enter manual commands

(like manual fallback). To avoid need for on-site repair the automatic fallback is provided.

It is important to fallback to former SW as well as DB, to cover exceptions caused by

faulty data also.

During SW fallback no log files are lost. Those data is stored for error analysis purpose.

Manual fallback

While SW upgrade is not finished, it is possible to trigger the eNB fallback to former SW

release and configuration remotely.

Manual fallback is possible as long as connection to eNB is established.








tools.






Alarms



Alarm ID

Alarm name

7651 BASE STATION OPERATION DEGRADED





Parameters



220 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc




BSW/ASW



BSW - -

5.14 Description of LTE1201: LTE iOMS HW, HP BladeGen8Introduction to the feature

This feature introduces new HW for LTE iOMS to replace HP ProLiant BL460c G6 in new

deliveries with HP ProLiant BL460c Gen8.

5.14.1 Benefits

End-user benefits


Operator benefits


• It lowers site costs.• OMSs are located at the NetAct site, which minimizes the maintenance costs and

saves space.

5.14.2 Requirements




System release

eNode B

NetAct

MME

SAE GW

Release RL40 - - - -


This feature requires the HP Blade BL460c Gen8.


Functional overview

With this feature OMS HW can be replaced with the new HP BL460c Blade Gen8. The

new HW allows reaching new efficiency values otherwise unavailable.


Issue: 01J DN09185979 221

8/18/2019 Fd Rl40 Desc







Impact on commands

There are no commands related to this feature.



tools.

Impact on system performance and capacityThe new HW increases computing power comparing to the BL460c G6.

5.14.5 LTE1201: LTE iOMS HW, HP Blade Gen8 management data



Alarms






Parameters




BSW/ASW



BSW - -


222 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


5.15 LTE1222: Inter-RAT Auto Setup and Scheduled

Optimization5.15.1 LTE1222: SON Automation Modes


With the LTE1222: SON Automation Modes feature the inter-RAT neighbor-related

features and optimization of intra-LTE are executed in an automatic manner.

The feature LTE1222: SON Automation Modes itself is a basic feature adding

functionality for the existing centralized SON features. The interaction with LTE1019:

SON Reports and LTE1045: Support of Distributed Sites is described at the specific

features.

The execution of the features in scheduled mode during auto-configuration are controlledwith preference settings, generically applicable for every execution of the work-flow.

Details are explained at the specific features.

5.15.1.1 Benefits

End-user benefits


Operator benefits


The operator can execute inter-RAT neighbor relation related features and optimizationof Intra-LTE in an automated way.




System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -




Issue: 01J DN09185979 223

8/18/2019 Fd Rl40 Desc



Functional overview

The LTE1222: SON Automation Modes itself is a basic feature adding functionality for the existing centralized SON features. The interaction with the LTE1019: SON Report

and the LTE1045: Support of Distributed Sites features is described in the specific

feature description.

The execution of the features in scheduled mode during auto-configuration are controlled

with preference settings, generically applicable for every execution of the work-flow.

Details are explained with the specific features.

The following SON features will be supported in Optimizer in an automated manner:

1. The auto-configuration can include the automatic execution of:



The execution depends on the operator settings for auto-configuration. Additionally

the features can be started manually as before.

2. Time scheduled execution of:

• LTE510: Synchronization of InterRAT Neighbor Relations



The operator can define time schedules when the mentioned features are executed.

Additionally the features can be started manually as before.

g Note: The LTE1222: SON Automation Modes feature is handled as a basic feature

adding additional functionality to the existing features for:

LTE533: Mobility Robustness

LTE771: Optimization of Intra-LTE Neighbor Relations

LTE510: Synchronization of InterRAT Neighbors

LTE783: ANR InterRAT UTRAN

LTE784: ANR InterRAT GERAN

Therefore, there are no specific SON Reports, CM parameter or PM counters or other

preparation for the LTE1222: SON Automation Modes feature itself.

5.15.1.3.1 LTE533: Mobility Robustness

The feature MRO is executable in a time scheduled manner. The scope of cells or eNBs

is the whole network respectively the scope of NetAct.

The operator defines the time schedules when the feature MRO has to be executed.

Additionally the feature MRO can be started manually as before.

NetAct supports preference settings to keep the network profile for the workflow-based

execution of MRO:

Preference settings:


224 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• Execution of the workflow (enabled, disabled)

• Scheduler configuration (day-of-week, time,...)

• stop point (none, active)

• MRO thresholds and weights• Network freeze mode (none, direct neighbors, all neighbors,...)

The operator setting of the network profile data during the interactive activation of MRO

does not change the preference setting for the automated execution of MRO.

The operator can trigger the execution of the automated MRO workflow manually or

abort the running workflow.

The operator can activate a stop point. If this function is activated, then the automated

MRO work-flow stops before the new plan file is downloaded and activated. The operator

can control the further steps manually.

5.15.1.3.2 LTE783: ANR for InterRAT UTRAN

The new functionality:

“new neighbors generation during LTE auto configuration”

enriches the existing optional feature LTE783: ANR for InterRAT UTRAN.

The LTE783 profile settings are configured as preference settings and are available for

each automated execution of the LTE783 work-flow during auto-configuration. The

interactive entered profile settings, during manual execution of LTE783, are independent

of the preference settings.

For each automated generation of UTRAN neighbor ship relations these preference

settings are applied.

For LTE783 there is no specific break-point. The operator can activate the LTE720

break-point to stop the work-flow and allow the operator to have a look on the results of

the whole auto-configuration workflow.

NetAct does allow modifications of the results of the algorithm, before the new delta

configuration is downloaded and activated.

The feature LTE720: SON LTE BTS Auto Configuration is required to run LTE783: ANR

for InterRAT UTRAN at auto-configuration time.

New neighbors generation during LTE auto-configuration

The feature LTE783: ANR for InterRAT UTRAN provides for a new installed eNB, duringthe execution of the feature LTE720: SON LTE BTS Auto Configuration, the most

suitable inter-RAT UTRAN neighbor ship relations. The LTE783 procedure considers the

actual inter-RAT NR UTRAN profile. The NetAct Configurator keeps an actual know-

ledge of the inter-RAT cell configuration data.

Support at NetAct Optimizer

NetAct Optimizer supports the feature LTE783 during auto-configuration.

NetAct Optimizer checks the status of the LTE783 activation. If the feature is activated,

then the feature LTE783 is executed for all the cells of all new eNBs.


Issue: 01J DN09185979 225

8/18/2019 Fd Rl40 Desc


8/18/2019 Fd Rl40 Desc


The LTE784 profile settings are configured as preference settings and are available for

each automated execution of the LTE784 work-flow during auto-configuration. The

interactive entered profile settings, during manual execution of LTE784, are independent

of the preference settings.

For each automated generation of GERAN neighbors relations these preference settings

are applied.

For LTE784 there is no specific break-point. The operator can activate the LTE720

break-point to stop the work-flow and allow the operator to have a look on the results of

the whole auto-configuration work-flow.

NetAct does allow modifications of the results of the algorithm, before the new delta

configuration is downloaded and activated.

The feature LTE720: SON LTE BTS Auto Configuration is required to run LTE784: ANR

for InterRAT GERAN at auto-configuration time.

New neighbors generation during LTE auto-configuration

The feature LTE784: ANR for InterRAT GERAN provides for a new installed eNB, during

the execution of the feature LTE720: SON LTE BTS Auto Configuration, the most

suitable inter-RAT GERAN neighbors relations. The LTE784 procedure considers the

actual inter-RAT NR GERAN profile. The NetAct Configurator keeps an actual know-

ledge of the inter-RAT cell configuration data.


NetAct Optimizer supports the feature LTE784 during auto-configuration.

NetAct Optimizer checks the status of the LTE784 activation. If the feature is activated,

then the feature LTE784 is executed for all the cells of all new eNBs.

NetAct Optimizer supports the management of policy values for InterRAT GERAN cell

selection as preference settings. For each execution of the LTE784 work-flow, these

preference settings are applicable. Profile setting, with different values, during interactive

execution of the feature LTE784 do not change the preference settings.

NetAct supports the following policy settings as preference settings:

• black- and white-listings of NR to GERAN cells per LTE cell

• minimum/maximum number of neighbor GERAN cells per LTE cell

• neighbors assignment (LTE to GERAN)

Support at NetAct Configurator

NetAct Configurator starts for the new eNBs the LTE720 auto-configuration process. TheLTE720 work-flow is covering the feature LTE784: ANR for interRAT GERAN too.

Use case: LTE784 new GERAN neighbors generation during LTE auto-configuration

This procedure describes the establishment of neighbors relations for inter-RAT GERAN

cells. The operator can run the process autonomous or define the LTE720 break point in-

line with the LTE720 management. The automatic inter-RAT configuration of the eNB is

based on LTE784 for the given cells of the new/planned eNB. Within the auto

configuration process LTE784 does not support a break point itself.

Preconditions


Issue: 01J DN09185979 227

8/18/2019 Fd Rl40 Desc


inter-RAT cell geo-location information is available. The own LTE cells for the

new/planned eNB are assigned in the LTE720 process. The operator has set the wanted

NetAct policy values for inter-RAT cell selection as preference settings. All features are

activated.

Description


1. The LTE720 process starts the auto-configuration process, that includes the "ANR

for Inter-RAT GERAN" algorithm.

2. Based on the information generated by NetAct Optimizer, NetAct updates the eNB

configuration plan. At the LTE720 break point the operator can modify the found NR.

3. NetAct Configurator completes the configuration plan for the impacted eNBs and

does, within the LTE720 process, download and activate the delta plan file

Post conditions

The LTE cells are configured with neighbor inter-RAT GERAN cells for support of HO

and other mobility procedures from LTE to inter-RAT GERAN via S1 interface and UE

idle mode mobility.

5.15.1.3.4 LTE510: Synchronization of Inter-RAT neighbors

The feature LTE510 does automatically keep inter-RAT neighbor relations up-to-date in

case of inter-RAT cell additions. The intrinsic algorithm to identify neighbors is based on

LTE783 and LTE784 functionality. Similar as an operator defines manually the scope of

eNBs or LTE cells, the feature LTE510 identifies automatically those eNB and LTE cells

that need update of their neighbors relation.

There are two additional use cases to be considered by LTE510 :

• Scheduled workflow execution by workflow engine for neighborship reconfiguration

from LTE view point

• Manually triggered workflow execution by workflow engine for neighborship

reconfiguration from LTE view point.

To avoid ping-pong effects between LTE510 on the one hand and execution of the

LTE783 and LTE784 feature, the same LTE783 and LTE784 policy values for the

selection of inter-RAT neighbor ship relation are applied. In addition the same black- and

white-listings are used. Therefore the design of LTE510 does aim to reuse the existing

LTE783 and LTE784 functionality and policy setting. The LTE510 feature is designed to

be responsible to identify those eNB and LTE cells that need to update their inter-RATneighbor relation. This approach defines a clear scope of the feature activation for each

of the individual features LTE510 , LTE783 and LTE784.

Scheduled neighborship reconfiguration

Periodically or manually triggered, Optimizer

• finds new inter-RAT cells.

• finds affected LTE cells.

• starts LTE783 and/or LTE784 for those LTE cells.

• NetAct Optimizer stores the new identified inter-RAT NR and exchanges the plan to

configurator.

• If no break-point is set NetAct Configurator proceeds with the provisioning.


228 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• If a break-point is set, the work-flow exists and the user can verify the results and

proceed with the provisioning manually

The NetAct keeps the operator informed about the progress and outcome of the

scheduled job.


NetAct Optimizer does support the identification of the LTE cells that are impacted by cell

additions in the inter-RAT networks, based on their geo-locations and the direction of the

antenna main lobe. The identification of impacted LTE cells considers the same LTE783

and LTE784 geo-location criteria. NetAct Optimizer does run the features LTE783 and

LTE784 for update of the LTE network for those eNB or LTE cells.

The following policy is supported:

Scheduler execution control for the start of feature LTE510

• Disabled (feature LTE510 is disabled)• Enabled (manual trigger)

Options for scheduler periodicity:

• Daily at certain time

• Weekly at certain day/time

• Bi-weekly at certain day/time

• Optional monthly at certain day/time

The configuration plan containing the new inter-RAT NR is forwarded to NetAct

Configurator. NetAct Optimizer generates one configuration plan for all activated RATs.

Use case: Scheduled neighborship reconfiguration

This procedure describes the management of NRs for Inter-RAT UTRAN and/or GERAN.

The operator does optionally configure a scheduled job at NetAct that does update the

configuration of the impacted eNBs or LTE cells with respect to inter-RAT cell additions.

The operator can schedule “to run the process autonomously” with or without a break

point for verifications.

The operator can trigger execution of this procedure manually.

Preconditions

inter-RAT cell geo-location information is available. The operator has set the wanted

operator policy values for inter-RAT cell selection. All features are activated.

NetAct Configurator keeps all eNB or LTE cells up-to-date.


Description


1. Optimizer identifies all new inserted inter-RAT cells (inter-RAT cells that do not have

yet incoming LTE neighbor relations).


Issue: 01J DN09185979 229

8/18/2019 Fd Rl40 Desc


2. The scheduled process starts the "ANR for Inter-RAT UTRAN” algorithm for the list of

eNB or LTE cells that need UTRAN NR update. The scheduled process starts the

“ANR for Inter-RAT GERAN” algorithm for the list of eNB or LTE cells that need

GERAN NR update. The order or the RATs is arbitrary.

3. Based on the information generated by NetAct Optimizer, NetAct Optimizer has to

update the existing eNB plan file. At the LTE510 break point the operator can still

modify the found NR.

4. The NetAct Configurator has to complete the configuration plan file for the impacted

eNBs and downloads and activates the delta plan files.

Post conditions

The LTE cells are configured with NR to newly added neighbor UTRAN and/or GERAN

cells for support of HO and other mobility procedures from LTE to UTRAN via S1

interface and to broadcast to the UE for idle mode mobility.

5.15.1.3.5 LTE771: Optimization of Intra-LTE neighbor relations


If the feature is disabled, no LTE771 options to automatically trigger LTE771 functionality

are provided to the operator. If the feature is activated, LTE771 functionality is provided.

If LTE771 is newly activated, the profile setting starts with default values.

NetAct Optimizer supports the activation of the LTE771 function as a scheduled work-

flow that is executed automatically based on profile settings.

Scheduled LTE771 execution

NetAct Optimizer supports within a pre-set profile the scheduled execution of LTE771

related workflow by the workflow engine within the scope of all NetAct controlled LTEcells.The profile supports the following settings:

• feature activation/deactivation, the license management follows the general NetAct

approach

• scheduler time control (start/stop, periodic start time/day/week/month)

• LTE771 controls parameter (# of HO attempt per day, required HO success ratio,

threshold for black-listed NR per cell to notify to the operator)

• Execution control (break-point).

• Execution report generation (level of details).

NetAct starts periodically, upon the profile, the analysis of the NR performance based on

the latest generated KPI data. NetAct Optimizer supports a periodically retriggered SONfunction that operates without further operator activity.

NetAct Optimizer considers the operator decision to exclude certain NR from being

changed by LTE771. NetAct Optimizer generates an LTE771 execution report to inform

the operator online or off-line about the performance or problems of the SON function.

The execution report shows the result of the operator controlled NR too. NetAct

Optimizer forwards the newly found NR that need to be blacklisted towards NetAct

Configurator to implement this in the actual network.

Manual LTE771 workflow execution:

The start of the scheduled workflow can be triggered manually as well.

Support at NetAct Configurator


230 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


NetAct Configurator or Optimizer optionally stops and terminates the work-flow at the

defined break-point, to allow the operator to verify and modify the generated plan file

before implementing in the network.

Use case for ANR Optimization

This use case describes the optimization of Intra-LTE NRs. The operator does configure

a scheduled job at NetAct that analyses LTE cells with respect to their intra-LTE

neighborship performance.

Preconditions

The operator has set the wanted operator policy values for optimization of intra-LTE NR

optimization.


The KPI data for the NR are available.

Description


1. Triggered by SON scheduler or from user manually via WFE UI, WFE does start the

scheduled workflow.

2. NetAct starts for all cells the performance evaluation of its neighborship relation.

3. NetAct creates the new plan of the proposed blacklisted neighborship relation.

4. NetAct provides to the operator the feedback of the procedure, according to the level

of details selected in the policy values.

5. In case of execution without break point, NetAct downloads and activates the plan

files to each eNB.

6. In case of execution with break point, NetAct Configurator SON Scheduler exits atthis break point. The operator can edit the plan and decide on the further steps.

Post conditions

In the network the NR that are badly performing will be blacklisted.



The interdependencies between the changes of this feature and other features are

described in the feature descriptions:

LTE533: Mobility Robustness

LTE771: Optimization of Intra-LTE neighbor relations

LTE510: Synchronization of InterRAT Neighbors

LTE783: ANR InterRAT UTRAN

LTE784: ANR InterRAT GERAN





Issue: 01J DN09185979 231

8/18/2019 Fd Rl40 Desc



tools.




For the LTE1222: SON Automation Modes feature the data are covered by the specific

feature impacted by the generic feature itself.



Alarms






Parameters




BSW/ASW



BSW - -

5.15 Variable Definitions

5.16 LTE1340: Trace-based Real Time MonitoringIntroduction to the feature

This feature offers a real time network monitoring solution based on the Flexi Multiradio

BTS trace interface. The collected trace data is sent to the Layer 3 Data Collector

(L3DC) that transfers the data to Traffica for visualization.

5.16.1 Benefits

End-user benefits


Operator benefits


232 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



• it offers an efficient method of monitoring a significant number of Flexi Multiradio

BTSs in real time

• real time monitoring allows the operator to quickly react to potential network

problems which, as a result, brings OPEX savings

5.16.2 Requirements



System release


Flexi Multiradio 10 BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -


The Layer 3 Data Collector is a standalone network element (NE) based on the HP

DL380 Gen 7 server.


Real time monitoring solution overview

This feature allows the operator to visualize real time monitoring data in Traffica. The

data is collected from the Flexi Multiradio BTS using the existing cell trace interface. The

L3DC network element is introduced to gather data from multiple BTSs. One L3DC NE is

able to handle up to 200 Flexi Multiradio BTSs. One Traffica instance is able to handle

up to 10 L3DCs.

Once the data is created in the Flexi Multiradio BTS, it is sent to L3DC. The timebetween trace record generation in the BTS and its availability in the L3DC should be

less than 20 seconds. The L3DC converts the L3 messages to Traffica-compatible

format. On request, the Traffica retrieves these reports from L3DC to display statistics

about the monitored cell. The reports consist of bearer and mobility management-related

information (C-plane events).

Basic configuration and software management tasks for L3DC can be performed locally

via an on-site terminal.

The whole end-to-end functionality is presented on Figure 24: Trace-based real time

monitoring architecture.


Issue: 01J DN09185979 233

8/18/2019 Fd Rl40 Desc


Figure 24 Trace-based real time monitoring architecture

Security

Gateway

(optional)

Traffica

TraceViewer

L3 Data CollectorFlexi Multiradio BTS

B T S

O & M

Cell trace

interface

L 3 D C O & M

Reports

Local terminal

L 3 D C O &

M

NetAct

FM

Cell trace configuration

The cell trace configuration is done using the TraceViewer application. The L3DC needs

to be selected as the Trace Collection Entity during the cell trace configuration (the

L3DC’s IP address put as the tceIpAddress parameter value).

L3DC fault management

If the L3DC is faulty or the connection between the Flexi Multiradio BTS and the L3DC is

not working, respective alarms are reported in NetAct. The Traffica user is notified by

alarm if the connection towards L3DC fails.

The L3DC can be added to network topology based on the existing external object

modeling in NetAct. It is added to the database as an external element to which alarms

can be mapped.



LTE1340: Trace-based Real Time Monitoring requires the LTE433: Cell trace feature.


The existing cell trace interface introduced with the LTE433: Cell trace feature is used

between Flexi Multiradio BTS and L3DC.

The NE3S interface is used between L3DC and NetAct (for connection supervision and

fault management). The L3DC uses the UDP messages for sending event reports

towards Traffica.



234 DN09185979 Issue: 01J



8/18/2019 Fd Rl40 Desc



tools.



5.16.5 LTE1340: Trace-based Real Time Monitoring managementdata



Alarms

This information will be available in further deliveries.





Parameters

There are no new parameters related to this feature.

There are no modified parameters related to this feature.



Full name

Abbreviated name

Managed object

Trace Collection Entity IP Address tceIpAddress MTRACE



BSW/ASW



BSW - -

5.17 Description of LTE1457: Cell trace Configurationvia Configuration ManagementIntroduction to the feature


Issue: 01J DN09185979 235

8/18/2019 Fd Rl40 Desc


The LTE1457: Cell trace Configuration via Configuration Management feature allows the

operator to configure the cell trace using NetAct Configuration Management (CM) and

the BTS Site Manager. This solution is an alternative to the existing method using NetAct

TraceViewer application.

5.17.1 Benefits

End-user benefits


Operator benefits


• repetitive work is reduced by supporting plan-based mass configuration

• cell trace configuration is also possible with 3rd party management system (using

available CM northbound interface)

5.17.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS

RL40 - - -


UE

NetAct

MME

SAE GW

- OSS5.4 CD set 2 - -




This feature introduces the possibility to activate/deactivate and configure cell trace

using NetAct Configuration Management tool set. The previous method of configuration

using NetAct TraceViewer is still supported. However, it is recommended to use either

Configuration Management or TraceViewer.

Activating and configuring one cell trace means (in practice):

• creating an MTRACE object under a particular eNB

• setting the object-related parameters

The hierarchy of trace-related objects is shown on Figure 25: Managed objects structure.


236 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 25 Managed objects structure

LNBTS

CTRLTS

(Trace Control)

MTRACE

(Cell Trace Session)

With this new feature the configuration can be done with the standard CM mechanism,that is:

1. Creating/updating a configuration plan using the NetAct CM Editor application.

In this step, the MTRACE objects are created and the relevant parameter values are

defined.

2. Provisioning and activating the plan using the NetAct CM Operations Manager

application.

The cell traces can also be configured via the northbound interface of NetAct

Configuration Management.

Support for advanced trace configuration (used, for example, to setup MDT) is still

available only in the TraceViewer.



The cell trace was introduced with the LTE433: Cell Trace feature.




This feature has no impact on network management or network element managementtools.



5.17.5 LTE1457: Cell trace Configuration via ConfigurationManagement management data



Alarms


Issue: 01J DN09185979 237


8/18/2019 Fd Rl40 Desc







Parameters




BSW/ASW



BSW - -


238 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


8/18/2019 Fd Rl40 Desc


Feature supported configurations

• 2 x (1 + 1 + 1) 2TX/2RX Dual Band with four 3-sector RF Modules, two per each RF

band.

Figure 26 Dual Band configuration with four RF Modules

Descriptions of BTS site solution features LTE RL40, Feature Descriptions and Instructions

240 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• 2 x (1 + 1 +1) 2TX/2RX Dual Band with six one cell RRH (or RFM as one sector

RRH)

– two optical chains, 2 RRHs per chain

– two RRHs with own link

Figure 27 Dual Band configuration with six RRHs, from which three are chained

Band A

an

ANT 2 RXOut 2 RET RXOut 1 ANT 1

ANT 2 ANT 1

EAC LMP OPT IF 1 OPT IF 2

CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 2


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 1 Sector 3 Sector 5

Sector 6Sector 4

LTE RL40, Feature Descriptions and Instructions Descriptions of BTS site solution features

Issue: 01J DN09185979 241

8/18/2019 Fd Rl40 Desc


• 2 x (1 + 1 + 1) 2TX/2RX Dual Band with six one cell RRH (or RFM as one sector

RRH)

– three RRHs per RF band

– three optical chains, 2 RRHs per chain

Figure 28 Dual Band configuration with six RRHs, from which two are chained

Band A

an


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 2


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 1 Sector 3 Sector 5

Sector 6Sector 4


242 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• 2 x (1 + 1) 2TX/2RX Dual Band with four one cell RRH (or RFM as one sector RRH)

– two RRHs per RF band

– two optical chains, 2 RRHs per chain

Figure 29 Dual Band configuration with four RRHs, from which two are chained

ANT 2 RX Out 2 RET RX Out 1 ANT 1

ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 2Sector 2


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 1Sector 1


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 4Sector 4


ANT 2 ANT 1


CLASS1

LASERPRODUCTION

Sector 3Sector 3

Band A

Band B

One System Module can support six cells up to 10 MHz bandwidth (with 1TX or with 2TX

MIMO).

RF bandwidths at two RF bands must be the same in first phase (that is 5MHz or 10MHz

bandwidth on both RF bands).

All supported RF band combinations and cell and RRH and RFM configurations are

listed in the LTE RL release documentation.

For more details on the configurations, see Creating LTE Configurations and Flexi

Multiradio and Multiradio 10 BTS LTE Supported Configurations .

6.1.4 System impact


LTE106: 6 cell support with one System Module is pre-requisite feature.





Issue: 01J DN09185979 243

8/18/2019 Fd Rl40 Desc



tools.



6.1.5 LTE179: Dual Band with One System Module managementdata

For parameters, see Flexi Multiradio BTS LTE Commissioning, RNW and Transmission

Parameters excel in NOLS.

Alarms






Parameters



Full name

Abbreviated name

Managed object

Activate support for dual band operation actDualBand LNBTS



Full name

Abbreviated name

Managed object

Downlink channel bandwidth dlChBw LNCEL

Uplink channel bandwidth ulChBw LNCEL


244 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc




BSW/ASW


element


ASW - -

6.2 LTE621: Multiradio System Module basic LTEconfigurations


This feature introduces basic LTE configurations with Flexi Multiradio FSMF core System

Module.

6.2.1 Benefits

Operator benefits

One Flexi Multiradio FSMF core System Module (1U unit in 3U Module casing) can

replace FSMD and FSME thus leaving two extension baseband sub-module capacity

slots space for LTE or Multiradio (for example for GSM or WCDMA) evolution.

6.2.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS

RL40 - LBTS4.0 -


UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -


Functional overview

The following LTE FDD cell configurations are supported with one Flexi Multiradio core

FSMF System Module configuration without baseband extension sub-modules:


Issue: 01J DN09185979 245

8/18/2019 Fd Rl40 Desc


• maximum 3-cell configurations for 15 MHz or 20 MHz bandwidth with all supported

LTE RF Modules and RRHs

• maximum 6-cell configurations for maximum 10 MHz bandwidth with all supported

LTE RF Modules and RRHs

FSMF System Module will replace FSME and FSMD System Modules for all RL40 Site

configurations.

All configurations are supported with 1TX or 2TX MIMO and with 2 RX-paths.

6.2.4 System impacts


There are no interdependencies between features.





tools.


New configurations are available.

6.2.5 LTE621: Flexi 10BTS Basic Configurations managementdata



Alarms






Parameters




BSW/ASW



BSW - -


246 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


6.3 LTE763: FXFA Flexi 3-sector RF Module 1900


The Flexi Multiradio Radio Frequency Module FXFA is a 3-branch multicarrier, multi-

standard radio transceiver module. The module consists of three independent branches,

capable of transmitting and receiving signals of multiple radio technologies concurrently:

• Up to six GSM carriers with 400 KHz minimum carrier separation

• Up to four WCDMA carriers with 4.6 MHz minimum carrier separation

• Multi-carrier LTE signal with 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, and 20

MHzcarrier bandwidth

• Multi RAT operation with combination of GSM, WCDMA, and LTE

Each branch consists of a transmitter, two receiver chains, and front end software

tunable filters (STuF). FXFA is a 3U high module with an integrated, replaceable 3-fanassembly for module cooling.

Figure 30 Isometric view of FXFA RF Module

6.3.1 Benefits

End-user benefits


Operator benefits

3-sector Flexi Multiradio RF Module 1900 (FXFA) introduces industry leading RF

integration level and the smallest power consumption combined with flexible GSM-

WCDMA-LTE site evolution.

6.3.2 Requirements




Issue: 01J DN09185979 247

8/18/2019 Fd Rl40 Desc



System release

eNode B

NetAct

MME

SAE GW

RL40 LBTS4.0 - - -


Functional overview

FXFA Flexi Multiradio RF Module supports 3GPP Band II:

• UL: 1850 - 1910MHz,

• DL: 1930 - 1990MHz

In 1900MHz band one Flexi Multiradio RF Module supports the following WCDMA

configurations:

Flexi Multiradio RF Module FXFA supports the following LTE configurations:

• 1, 1+1, or 1+1+1 at the maximum of 20 MHz LTE bandwith and 1TX/2RX

• 8, 20, 40, or 60 W mode per sector (controlled by SW licenses)

• 1 sector with the maximum of 60 + 60 W 2TX/2RX MIMO

• HW ready for 1 sector with the maximum of 60 + 60 W 2TX/4RX MIMO

Front panel view of the RF Module

Figure 31 FXFA front panel connectors and labels

RxO 2

Groundingpoints

LED Modulestatus

LED

Fan/TX Off status

PWR IN

ANT 6RX

ANT 4RX ANT 3

TX/RX

ANT 2RX ANT 1

TX/RX

EACOPT 1

OPT 2OPT 3

RxO 6 RxO 4TX/RX

RxO 1RxO 3

RxO 5

RF Module front panel descriptions


248 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 148 FXFA front panel connectors, cable types and interfaces

Label nameon module

Description

Connector type

Cable types andInterface(s)

Signaldirection

Ant 1 Tx/Rx RF signal interface to

antenna (Tx and Rx

main)

7/16 (female) Antenna jumper or

feeder cables

To and from

the module

Ant 2 Rx RF signal interface to

antenna (Rx diversity)

7/16 (female) • Antenna jumper or

feeder cables

• Other module when

antenna sharing

(co-siting) is used

To the

module

Ant 3 Tx/Rx RF signal interface(Tx and Rx main)

7/16 (female) Antenna jumper or feeder cables

To and fromthe module

Ant 4 Rx RF signal interface

(Rx diversity)


feeder cables


antenna sharing

(co-siting) is used

To the

module

Ant 5 Tx/Rx RF signal interface

(Tx and Rx main)

7/16 (female) Antenna jumper or

feeder cables

To and from

the module

Ant 6 Rx RF signal interface

(Rx diversity)


feeder cables


antenna sharing

(co-siting) is used

To the

module

RxO 1/ ANT

1 Rx Out

Provides an external

BTS or module with

the RX signal from

Ant 1 when antenna

sharing (co-siting) is

used

QMA (female) External BTS or module From the

module

RxO 2 Provides an externalBTS or module with

the RX diversity signal

from Ant 2 when

antenna sharing (co-

siting) is used

QMA (female) External BTS or module From themodule

RxO 3/ ANT

3 Rx Out


BTS or module with

the RX signal from

Ant 3 when antenna

sharing (co-siting) is

used


module


Issue: 01J DN09185979 249

8/18/2019 Fd Rl40 Desc


Table 148 FXFA front panel connectors, cable types and interfaces (Cont.)

Label nameon module

Description

Connector type

Cable types andInterface(s)

Signaldirection

RxO 4 Provides an external

BTS or module with


from Ant 4 when


siting) is used


module

RxO 5 /ANT

5 RxOut


BTS or module with

the RX signal from

Ant 5 when antennasharing (co-siting) is

used


module

RxO 6 Provides an external

BTS or module with


from Ant 6 when


siting) is used


module

PWR IN -48 V DC input power

with fuse protection

Multi-Beam

XL (female)

System Module To the

module

OPT 1 Control interface to

the module (OBSAI

RP3-1)

Duplex LC

connector

System Module or RF

Module

To and from

the module


the module (OBSAI

RP3-1)

Duplex LC

connector

System Module or RF

Module

To and from

the module


the module (OBSAI

RP3-1)

Duplex LC

connector

System Module or RF

Module

To and from

the module

EAC External alarminterface (four alarm

inputs)

RJ45 femaleshielded

System Module or external alarm interface

To and fromthe module

RF Module dimensions and weight

Table 149 FXFA dimensions and weight

Property

Value

Width 1) 447/492 mm

(17.6/19.4 in.)


250 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Table 149 FXFA dimensions and weight (Cont.)

Property

Value

Height 133 mm/ 3U

(5.2 in.)

Depth 2) 422/560 mm

(16.6/22.1 in.)

Weight 25 kg

(55.1 lbs)

1) Width of the casing without front covers/with front covers

2) Depth of the casing without front covers/with front covers








tools.




This module has same power and Multicarrier licenses as previous modules. It requires

a branch license.


BSW/ASW



BSW - -

6.4 LTE947: FSMF Flexi Multiradio 10 System ModuleIntroduction to the feature


Issue: 01J DN09185979 251

8/18/2019 Fd Rl40 Desc


Flexi Multiradio BTS System Module FSMF is a highly integrated 3U high outdoor

System Module of the Flexi Multiradio BTS. It hosts the telecom control, system

operation and maintenance, baseband application, transmission, and power distribution

functionality. The System Module can be also equipped with optional capacity extension

sub-modules which bring additional signal processing power and/or allow the system to

support different radio access technology. Adding the capacity sub-modules in the field

does not affect ongoing traffic.

The System Module can also act as a System Extension Module operating in a

baseband extension mode. Flexi Multiradio BTS architecture supports chaining up to

nine System Modules enabling to build very high capacity sites and different redundancy

solutions.

Flexi Multiradio System Module hardware supports the following software operating

modes:

• GSM/EDGE mode

• WCDMA mode

• LTE in FDD and TDD mode

6.4.1 Benefits

End-user benefits


Operator benefits

The FSMF is a successor of the FSMD and FSME System Modules providing enhanced

capacity, connectivity and expansion possibilities in the same form factor. FSMF is IP

ingress protected and operates at the temperature range from -35 to + 55 °C.

6.4.2 Requirements


Table 151: Software requirements lists software required for this feature.

System release


Flexi Multiradio 10

BTS

OMS



UE

NetAct

MME

SAE GW

- OSS5.4 CD2 - -


Functional overview


252 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


The Flexi Multiradio BTS System Module FSMF consists of a 3U high casing, which can

accommodate in addition to the base module, optionally

• up to two baseband sub-modules (FBBA),

• one additional transport sub-module (FTxx),

• one power distribution sub-module (FPFx).

The following functions are integrated in the FSMF:

• ethernet transport,

• clock and control functions,

• baseband processing,

• fan control,

• status LEDs.

Table Table 152: Flexi Multiradio System Module FSMF peak throughput shows the total

throughput of a Flexi Multiradio System Module, which can vary depending on thecombination of the modules used. Note that MIMO is supported for both HSPA and LTE.

Table 152 Flexi Multiradio System Module FSMF peak throughput

Capacity

FSMF

GSM/EDGE

[transceivers]

72

WCDMA

[channel elements]

528

HSDPA

[Mbps]

756

HSUPA

[Mbps]

115

LTE DL

[Mbps]

450

LTE UL

[Mbps]

150

LTE BW/cell

[MHz]

20

LTE cells

[cell count]

3

MIMO (HSPA/LTE) yes


Issue: 01J DN09185979 253

8/18/2019 Fd Rl40 Desc


One FSMF System Module provides a hardware baseband capacity for up to three 20

MHz LTE cells.

Figure 32: Front panel of the System Module (FSMF) with optional sub-modules FPFD,

FTIF, and two FBBAs presents the front view of the Flexi Multiradio BTS System ModuleFSMF.

Figure 32 Front panel of the System Module (FSMF) with optional sub-modulesFPFD, FTIF, and two FBBAs

Optional power distributionsub-module

Optional transportsub-module

Optional capacity extensionsub-module

DC Input

DC Output

LMP

EIF2/RF/EXT6 RF/EXT1-3

Sync Out

Sync In

EAC

EIF1

BB EX1-2

SRIO

Interfaces

The FSMF provides the following interfaces:

• Three optical OBSAI RP3-01 interfaces with up to 6 GBit/s or CPRI

• One optical interface which can be used as OBSAI RP3-01 interface with up to 6

Gbit/s (or CPRI) or as 1000Base-X as network interface

• One electrical interface 100/1000Base-T as transport backhaul interface

• One electrical interface 10/100Base-T as local management interface

• One Sync In interface

• One Sync Out interface

• One EAC (External Alarm and Control) interface (6 alarm signals, 6 SW-controllable

signals that can be assigned to be either Alarm or Control signals). The interface

includes also a CAN interface.

• One SRIO (Serial Rapid Input/Output) interface for an external baseband extension,

for example additional System Module

• Two baseband extension interfaces for optional sub-modules

• One -48 VDC input and one -48 VDC output

More information, see Flexi Multiradio 10 BTS, Multiradio System Module Description.


254 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc






New interfaces available.



tools.



6.4.5 LTE947:Flexi Multimode System Module FSMFmanagement data



Alarms






Parameters




BSW/ASW



BSW - -

6.5 LTE949: FPFD Flexi Power Distribution Sub-moduleIntroduction to the feature

The FPFD is a highly integrated optional power distribution sub-module for the Flexi

Multiradio 10 BTS System Module.


Issue: 01J DN09185979 255

8/18/2019 Fd Rl40 Desc


6.5.1 Benefits

End-user benefits


Operator benefits

Outdoor Power distribution unit with fuses is integrated into the 3U high System Module

casing. The FPFD is installed into the Flexi Multiradio System Module and requires

therefore no dedicated power distribution unit thus no need for additional space or

cabinet.

6.5.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS

- - - -


UE

NetAct

MME

SAE GW

- - - -


This feature requires Flexi Multiradio 10 BTS.


Functional overview

Optional integrated FPFD outdoor sub-module is a size optimized power distribution unit

(PDU). It is located at the top left of the outdoor Flexi Multiradio System Module.

It can be used for stacked configuration and feederless configuration the same way as

earlier Flexi integrated Power distribution units. In feederless configuration FPFD can be

used with optional Over Voltage Protection units (OVP with FSEC or FSES).

It can be installed together with new Flexi Multiradio System Module in one 3U casing.

FPFD Power distribution sub-module provides four external -48 V DC outlets for Flexi

Modules (RF Module, RRH, or external System Module) or any standard 48 V DC device

at site and one internal DC output to System Module itself.

The FPFD has integrated basic Over Voltage Protection on input (OVP Type approval

level with +/- 1 kV (L-L) 8/20 µs and +/- 2 kV (L-N) 8/20 µs), EMC filtering and reverse

polarity protection. It protects the connected units against short circuit, overcurrent (fixed

trip points), and high voltage transients.


256 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 33 FPFD sub-module

Interfaces

The FPFD provides the following external interfaces:

• One -48 V DC input

• Four external -48 V DC outputs

• One internal DC output to the System Module

• Control panel with the following elements:

– one LED for each output (RF1, RF2, RF3, EXT, SYS)

– SELECT and SET buttons to control their status

Communication with Flexi Multiradio System Module is done via serial interface.

For more information, see:

• Installing Flexi Multiradio 10 BTS Power Distribution Sub-Module (FPFD) in Installing

Flexi Multiradio 10 BTS for Stack, Wall, and Pole Configurations.

• Connecting Flexi Multiradio 10 BTS Power Distribution Sub-Module (FPFD) cabling

in Cabling Flexi Multiradio 10 BTS.








tools.



Issue: 01J DN09185979 257

8/18/2019 Fd Rl40 Desc



6.5.5 LTE949: Flexi power distribution sub-module FPFD

management data



Alarms






Parameters




BSW/ASW



BSW - -

6.6 LTE950: FPFC Flexi Power Distribution ModuleIntroduction to the feature

The optional FPFC is a stand-alone 19 inch rack wide power distribution module for Flexi

Multiradio BTS configurations.

6.6.1 BenefitsEnd-user benefits


Operator benefits

The general-purpose FPFC can be flexibly used at larger outdoor and indoor Flexi BTS

sites, or up on a tower, together with Radio Modules or RRHs. It provides six -48V DC

outputs with improved Over Voltage Protection (OVP).

6.6.2 Requirements



258 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc



System release


Flexi Multiradio 10BTS

OMS

- - - -


UE

NetAct

MME

SAE GW

- - - -




Functional overview

Optional FPFC is a stand-alone outdoor general purpose Power Distribution Unit (PDU)

with Class II Over Voltage Protection, with 15 kA protection level. External overvoltage

protection (using, for instance, units of type FSEC or FSES) might be needed with RF

parts if the PDU is located more than ten meters away from the powered unit.

FPFC is a stand-alone external 19 inch wide 2U high outdoor module. Power distributionmodule FPFC provides six outlets for Flexi Modules (Radio Modules, RRHs, or System

Module), or any standard -48 V DC device at site. It can also be used, for example, at

the top of the antenna mast to distribute power to several RF Modules or Remote Radio

Heads. It has one External alarm to indicate Over Voltage Protection (OVP) device

condition.

To provide more than six outputs, it is possible to chain two FPFCs using the same DC

power source.


Issue: 01J DN09185979 259

8/18/2019 Fd Rl40 Desc


Figure 34 FPFC module

FPFC EAC connector On/Off Bar

Input connector IP boot

Input connector Output connector IP boot

Interfaces

FPFC provides the following external interfaces:

• one DC input

• six DC outputs

– CH1-2: maximum fixed output 30A

– CH3-6: maximum adjustable output 4A/15A/30A

Additionally, each output has On/Off bar.• one EAC connector

EAC connector (RJ45) informs about any abnormal situation, for example, when the

protective component(s) have been damaged. It indicates SPD alarm via two alarm

signals - Normal Open (NO) and Normal Closed (NC):

– NO

Alarm is active when the connection is closed. 5V alarm detection line is pulled

down during alarm: Active = 0, Inactive = 1.

– NC

Alarm is active when the connection is open. 5V alarm detection line is pulled up

during alarm: Active = 1, Inactive = 0.

For more information, see

• Flexi Power Distribution and Fuses Outdoor (FPFC) description in Flexi Multiradio

BTS LTE Optional Items Description

• Installing Flexi Power Distribution and Fuses Outdoor (FPFC) in Installing Flexi

Multiradio BTS LTE Optional Items






260 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc





tools.



6.6.5 LTE950: Flexi power distribution module FPFCmanagement data



Alarms






Parameters




BSW/ASW



BSW - -

6.7 LTE1040: FXEB Flexi 3-sector RF Module 1800Introduction to the feature

Flexi Multiradio RF Module for 1800 MHz (FXEB) supports one, two, or three sectors

with the maximum of 3 x 80 W output power at the BTS antenna connectors. RF Module

HW TX bandwidth is 35 MHz and RX 75 MHz for efficient GSM, WCDMA, and LTE

Multiradio configurations.

FXEB can be used as one sector Remote RF Head (RRH) with the maximum of 80 W +

80 W 2TX MIMO. Size and visual outlook are similar to the existing Flexi 3-sector RF

Modules. The environmental protection class is IP65.


Issue: 01J DN09185979 261

8/18/2019 Fd Rl40 Desc


6.7.1 Benefits

End-user benefits


Operator benefits

FXEB Flexi 3-sector RF Module 80 W 1800 MHz has full 20 MHz LTE bandwidth support

at 3GPP bands 3 and 9.

LTE1040: FXEB Flexi 3-sector RF Module 1800 provides the following benefits:

• the most cost-, size-, and weight-optimized three-sector BTS site, easier installation,

less visual impact

• industry-leading RF integration level

• SW configurable radio: the same RF Module for LTE, HSPA+, and WCDMA, and

GSM/EDGE• the widest ambient temperature range: -35... +55 C

• the smallest power consumption and OPEX

• 3 sector RF Module in one outdoor IP65 protected box

• less wind load

• can also be used as a feederless site with one DC and one or two optical cables

• TX diversity and MIMO 2TX can be built using two 3-sector RF Modules

• RF redundancy option comes as an additional advantage

• in feederless installations one 3-sector RF Module is more cost effective than three

Remote Radio Heads (RRHs)

• typically, only one third of DC and optical cabling required, compared to the Remote

Radio Heads• can be used as a powerfull one sector RRH : 40 + 40 W 2TX MIMO with HW

prepared for 4RX

6.7.2 Requirements




System release

eNodeB

MME

SAE GW

UE

NetAct

Release RL40 LBTS4.0 - - - OSS5.4

CD2


Functional overview

Flexi Multiradio RF Module HW supports LTE at the 3GPP Band 3 and 9.

Flexi Multiradio RF Module FXEB supports the following LTE configurations:

• 1, 1+1, or 1+1+1 at the maximum of 20 MHz LTE bandwith and 1TX/2RX


262 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


• 8, 20, or 40 W mode per sector (controlled by SW licenses)

• 1 sector with the maximum of 80 + 80 W 2TX/2RX MIMO

• HW ready for 1 sector with the maximum of 40 + 40 W 2TX/4RX MIMO

Flexi Multiradio RF Module FXEB can be used in Feederless (DC up to 200 m) and

Distributed BTS sites.

Front panel view of the RF Module

Figure 35 FXEB front panel connectors and labels








tools.




This module has same power and Multicarrier licenses as previous modules. It requires

a branch license.


BSW/ASW



BSW - -


Issue: 01J DN09185979 263

8/18/2019 Fd Rl40 Desc


6.8 LTE1125: GNSS Receiver FYGB

Introduction

This feature introduces a standalone, combined GNSS/GPS satellite receiver for BTS

timing synchronization. It uses GNSS (Global Navigation Satellite System) as the

primary source for frequency and time synchronization providing the 1pps input signal to

the FSM.

6.8.1 Benefits

End-user benefits


Operator benefits

LTE1125: GNSS Receiver FYGB provides support for two operationally available global

navigation satellite systems GNSS - GPS and GLONASS. The feature decreases the

probability of losing satellite coverage in dense urban areas. FYGB also enhances

stability of 1pps synchronization signal with fallback capability to GNSS-mode or GPS

-only mode.

6.8.2 Requirements




System release

eNode B

NetAct

MME

SAE GW

Release RL40 - - - -




The standalone FYGB GNSS receiver is an optional synchronization solution for sites

requiring external timing synchronization.

FYGB introduces following modes of operation:

1. only GPS satellites are in use,

2. only GLONASS satellites are in use,

3. both GPS & GLONASS satellites are in use (default).


264 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


Figure 36 Flexi BTS Synchronization with GNSS

6.8.4 System impact






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



6.8.5 LTE1125: GNSS Receiver FYGB management data



Alarms


Issue: 01J DN09185979 265

8/18/2019 Fd Rl40 Desc




Alarm ID

Alarm name

7651 BASE STATION OPERATION DEGRADED

7652 BASE STATION NOTIFICATION





Parameters

Table 162: Related existing parameters lists parameters introduced with this feature.


Full name

Abbreviated name

Managed object

Cable Length Between GPS and eNB gpsCableLength BTSSCL

GPS In Use gpsInUse BTSSCL

Total GPS Antenna Line Delay gpsTotalAntennaLineDelay BTSSCL

Air Frame Timing As For 1PPS

Reference

ppsTimingOffset BTSSCL



BSW/ASW



BSW - -

6.9 LTE1148: FRIG Flexi RRH 4TX 1.7/2.1Introduction to the feature

This feature introduces Flexi Multiradio Remote RF Head (RRH) FRIG with 4TX for

3GPP band IV 2100 MHz (downlink)/1700 MHz (uplink).


266 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


6.9.1 Benefits

End-user benefits


Operator benefits

One sector Flexi Remote Radio Head is able to support 4TX MIMO with high output

power for hot spot dense urban capacity sites. It enables easy outdoor installation close

to antennas by maximizing BTS site capacity and coverage for one sector.

6.9.2 Requirements



System release

Flexi

Flexi Lite

Flexi 10

RL40 LBTS4.0 support not needed LBTS4.0


OMS

UE

NetAct

MME

SAE GW

OMS4.0 support not

needed

OSS5.4 CD2 support not

needed

support not

needed


Functional overview

FRIG Flexi RRH 4TX 1.7/2.1 GHz provides the following features:

• 4 x 30 W with four power amplifiers active

• 2 x 60 W with two power amplifiers active

• optimized for single sector deployment with 4TX MIMO

• one LTE cell with 4TX MIMO up to 2 x 20 MHz LTE per sector

• IP65 with -35 to +50 °C with convection cooling

• LTE-A ready

• CPRI ready

• AISG2.0 Antenna tilt support with external connector (RS485)

• 4-way Uplink RX Maximum Ratio Combining (MRC) HW support

• external alarms input

• optical chaining supported by HW (three optical connectors with 6 Gbit/s interfaces)

• MHA and 3GPP Antenna tilt power feed and control capable (Antenna port 1 and

port 3)


Issue: 01J DN09185979 267

8/18/2019 Fd Rl40 Desc


6.9.4 LTE1148: FRIG Flexi RRH 4TX 1.7/2.1 management data



Alarms






Parameters








This feature has no impact on network management and network element managementtools.




This module has same power and Multicarrier licenses as other earlier modules. It

requires Branch license.


BSW/ASW



BSW — —

6.10 LTE1261: FHDB Flexi RRH 2TX 900Introduction to the feature


268 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


This feature introduces FHDB Flexi Multiradio Remote Radio Head (RRH) with 2TX

downlink MIMO and 2 RX receiver uplink diversity for world market LTE operation at

3GPP band VIII:

• UL: 880 - 915 Mhz• DL: 925 - 960 Mhz

6.10.1 Benefits

End-user benefits


Operator benefits

One sector Flexi Remote Radio Head supports 2 TX MIMO with high output power (2 x

60W) for hot spot dense urban capacity sites. It enables easy outdoor installation close

to antennas by maximizing BTS site capacity and coverage for one sector.

6.10.2 Requirements



System release

Flexi

Flexi Lite

Flexi 10



OMS

UE

NetAct

MME

SAE GW

OMS4.0 support not

needed


needed

support not

needed


Functional overview

FHDB Flexi RRH 2TX 2RX 900 MHz provides the following features:

• 2x60 W with two power amplifiers


• optical chaining supported by HW (two optical connectors with 6 Gbit/s interfaces)

• IP65 with -40°C to +50°C with convection cooling

• external alarms and outputs

• AISG2.0 Antenna tilt support with external connector (RS485)

FHDB supports up to 20 MHz bandwidth.


Issue: 01J DN09185979 269

8/18/2019 Fd Rl40 Desc









tools.







BSW/ASW



BSW — —

6.11 LTE1263: FRGV Flexi RRH 2TX 2100Introduction to the feature

FRGV Flexi Multiradio Remote RF Head (RRH) with 2TX MIMO and 2RX receiver for

world market WCDMA/HSPA and LTE operation at 2100 MHz 3GPP band I.FRGV is an

enhancement to FRGQ with lower weight and improved power consumption.

6.11.1 Benefits

End-user benefits


Operator benefits

One sector Flexi Remote RF Head supports 2TX MIMO with high output power. It

enables easy outdoor installation close to antennas by maximizing BTS site capacity and

coverage for one sector.

6.11.2 Requirements




270 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


System release

Flexi

Flexi Lite

Flexi 10



OMS

UE

NetAct

MME

SAE GW

OMS4.0 support not

needed


needed

support not

needed


Functional overview

FRGV Flexi RRH 2TX 2RX 2100 MHz provides the following features:

• 40 W + 40 W with two power amplifiers


• optical chaining supported by HW(two optical connectors)

• IP65 with -35 to +50°C with convection cooling

• two external RX outputs (main and div with small SMA connectors) for future use

(e.g. device location)

• external alarms and outputs

• AISG2.0 Antenna tilt support with external connector (RS485)• MHA supported by both RX branches with adjustable 0...30 dB LNAsother TX/RX

branch with integrated BiasT to support AISG2.0 MHA (or antenna tilt in future

possible by the same HW)MHA SW support via integrated BiasT

• VSWR monitoring on both TX branches








tools.




Issue: 01J DN09185979 271

8/18/2019 Fd Rl40 Desc


6.11.5 LTE1263: FRGV Flexi RRH 2TX 2100 management data



Alarms






Parameters






BSW/ASW



BSW — —

6.12 LTE1306: FRMD Flexi 3-sector RF Module 800Introduction to the feature

FRMD is Flexi Multiradio RF Module variant for 800 MHz 3GPP band 20:

• DL 791-806 MHz

• UL 832-847 MHz

FRMD supports the lowest 15 MHz (A + 1/2B-block) for three sectors with 60 W output

power at the BTS antenna connector. It can be used as powerful one sector RRH with

max 60 W + 60 W 2TX MIMO.

6.12.1 Benefits

End-user benefits


Operator benefits


272 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


One sector Flexi Remote RF Head supports 2TX MIMO with high output power. It

enables easy outdoor installation close to antennas by maximizing BTS site capacity and

coverage for one sector.

6.12.2 Requirements



System release

Flexi

Flexi Lite

Flexi 10



OMS

UE

NetAct

MME

SAE GW

OMS4.0 3GPP R10 UE

capabilities


needed

support not

needed


Functional overview

FRMD Flexi RRH 2TX 2RX 2100 MHz provides the following features:

• the most cost and size and weight optimized 3-sector BTS site

• SW configur able radio module: the same RF Module for LTE, HSPA+ and WCDMA

• IP65 with -35 to +50 °C with convection cooling

• smallest size and weight

• smallest power consumption and OPEX

• can be used as feederless site as well with one DC and 1...2 optical cables

• TX div and MIMO 2TX can be build using two 3-sector RF Modules

• typically 1/3 of DC and optical cabling compared to site with Remote RF Heads

(RRH)

• easy installation








tools.


Issue: 01J DN09185979 273

8/18/2019 Fd Rl40 Desc




6.12.5 1306: FRMD Flexi 3-sector RF Module 800 managementdata



Alarms






Parameters






BSW/ASW



BSW — —

6.13 Description of LTE1514: Additional RF sharingConfigurations LTE-GSMIntroduction to the feature

This feature introduces additional LTE-GSM RF Sharing configurations, including larger

GSM setups and four-RF Module configurations.

6.13.1 Benefits

End-user benefits


Operator benefits

Lower sites costs, reduced need to split the sites.


274 DN09185979 Issue: 01J

8/18/2019 Fd Rl40 Desc


6.13.2 Requirements



System release


Flexi Multiradio 10

BTS

OMS

RL40 LBTS4.0 LBTS4.0 not relevant


UE

NetAct

MME

SAE GW

not relevant not relevant not relevant not relevant




Functional overview

g Note: Note that for configurations with more than 36 GSM TRXs an additional GSM

System Module is needed.

The following configurations are introduced:

• Configurations with three RF Modules (two shared + one GSM-dedicated):

– 3 x FXEB, 1+1+1 LTE 10/20 MHz plus up to 8+8+8 (4+4+4+4+4+4) GSM

– 3 x FXEB, 1+1+1 LTE 20 MHz plus 6+6+6 GSM

• Configuration with four RF Modules (two shared + two GSM-dedicated):

4 x FXEB, 1+1+1 LTE 10/20MHz plus up to 12+12+12 (4+4+4+8+8+8) GSM


Feaure LTE447/BSS21250: SW Support for RF sharing GSM-LTE is required.





tools.



Issue: 01J DN09185979 275

8/18/2019 Fd Rl40 Desc




fd rl40 desc

Documents