Operability Features Description - FL17A

Single RAN, Rel.
SRAN 17A,
Operating Documentation,
Issue 02
LTE17A Operability Features

DN181051332
Issue 01
Approval Date 2017-11-28

The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).
This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes defined in the agreement between You and Nokia (“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. 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 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 welcomes 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 reserves the right to change any such
information and statements without notice. Nokia has made all reasonable efforts to ensure that the
content of this document is adequate and free of material errors and omissions, and Nokia will correct
errors that You identify in this document. Nokia's total liability for any errors in the document is strictly
limited to the correction of such error(s). Nokia 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 BE LIABLE FOR ANY DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS
DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners.
Copyright © 2018 Nokia. 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 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 for any additional information.
2 © 2018 Nokia DN181051332 Issue: 01
Table of Contents
This document has 233 pages

1 LTE529: Dynamic X2 and S1 Firewall Configuration................... 14
1.1 LTE529 benefits........................................................................... 14
1.2 LTE529 functional description...................................................... 14
1.3 LTE529 system impact................................................................. 17
1.4 LTE529 reference data.................................................................18
1.5 Enabling dynamic firewall configuration....................................... 19
1.6 Disabling dynamic firewall configuration...................................... 22

2 LTE1523: Role-based BTS User Accounts.................................. 25
2.1 LTE1523 benefits......................................................................... 25
2.2 LTE1523 functional description.................................................... 25
2.3 LTE1523 system impact............................................................... 28
2.4 LTE1523 reference data...............................................................28
2.5 Activating and configuring local accounts.................................... 30
2.6 Deactivating role-based local accounts........................................32
2.7 Managing local accounts using NetAct........................................ 33

3 RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator
Owned Backhaul.......................................................................... 35
3.1 RAN3379 reference data............................................................. 46
3.2 Activating and configuring RAN3379: Enhanced Flexi Zone Plug
and Play for Non-Operator Owned Backhaul ..............................47
3.3 Deactivating RAN3379: Enhanced Flexi Zone Plug and Play for
Non-Operator Owned Backhaul .................................................. 50

4 LTE2487: Support for Distributed PKI Systems........................... 52
4.1 LTE2487 benefits......................................................................... 52
4.2.1 Lifecycle management of operator certificate in eNB/SBTS........ 54
4.5 Configuring secondary CMP server............................................. 57

5 RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade .................59
5.1 RAN3382 benefits........................................................................ 59
5.2 RAN3382 functional description...................................................59
5.3 RAN3382 system impact..............................................................62

6 LTE2734: Flexi Zone Discovery Mode Neighbor Information
Exchange..................................................................................... 65
6.1 LTE2734 benefits......................................................................... 65
DN181051332 Issue: 01 © 2018 Nokia 3
6.5 Activating LTE2734...................................................................... 68
6.6 Deactivating LTE2734.................................................................. 72
6.7 Other instructions......................................................................... 73

7 LTE3042: Cloud Flexi Zone Controller......................................... 78
7.1 LTE3042 benefits......................................................................... 78

8 RAN3358: OMS for CBIS.............................................................84
8.1 RAN3358 benefits........................................................................ 84
8.2 RAN3358 functional description...................................................84
8.3 RAN3358 system impact..............................................................85

9 LTE3296/SR001527: Harmonized Object Model for SRAN and
LTE............................................................................................... 88
9.1 LTE3296/SR001527 benefits....................................................... 88
9.2 LTE3296/SR001527 functional description.................................. 88
9.3 LTE3296/SR001527 system impact........................................... 115
9.4 LTE3296/SR001527 reference data........................................... 116

10 LTE3303: Enhanced VoLTE, CA, and RF Quality Monitoring.....118
10.1 LTE3303 benefits........................................................................118
10.2 LTE3303 functional description.................................................. 118
10.3 LTE3303 system impact............................................................. 118
10.4 LTE3303 reference data............................................................. 118

11 LTE3333: Per Call Measurement Data (PCMD).........................124
11.1 LTE3333 benefits....................................................................... 124
11.4 LTE3333 reference data.............................................................126
11.5 Activating LTE3333.................................................................... 130
11.6 Deactivating LTE3333................................................................ 132
11.7 Deactivating a single LTE3333 trace session............................ 133

12 LTE3334: Per Call Measurement Data (PCMD) - Per Bearer
Report........................................................................................ 136
12.1 LTE3334 benefits....................................................................... 136
12.5 Activating LTE3334: Per Call Measurement Data (PCMD) - Per
Bearer Report.............................................................................140
12.6 Deactivating LTE3334: Per Call Measurement Data (PCMD) - Per
Bearer Report.............................................................................140
4 © 2018 Nokia DN181051332 Issue: 01

13 LTE3335: Per Call Measurement Data (PCMD) - CA Report.....141
13.1 LTE3335 benefits....................................................................... 141
13.5 Activating LTE3335: Per Call Measurement Data (PCMD) - CA
Report........................................................................................ 146
13.6 Deactivating LTE3335: Per Call Measurement Data (PCMD) - CA
Report........................................................................................ 146

14 LTE3336: Per Call Measurement Data (PCMD) - Per Call Report
Extension................................................................................... 147
14.1 LTE3336 benefits....................................................................... 147
14.5 Activating LTE3336: Per Call Measurement Data (PCMD) - Per
Call Report Extension................................................................ 152
14.6 Deactivating LTE3336: Per Call Measurement Data (PCMD) - Per
Call Report Extension................................................................ 152

15 LTE3342/SR001534: Improved Combined FM Service............. 153
15.1 LTE3342/SR001534 benefits..................................................... 153
15.2 LTE3342/SR001534 functional description................................ 153
15.2.1 Introduction of category alarms..................................................153
15.2.2 Autonomous recovery actions improvement for SBTS and eNB.....
157
15.3 LTE3342/SR001534 system impact........................................... 159
15.4 LTE3342/SR001534 reference data...........................................159
15.5 Selecting alarms scheme using BTS Site Manager................... 161
15.6 Configuring autonomous reset using BTS Site Manager........... 162

16 LTE3356: PCMD - RRC Connection Establishment Failures.....165
16.1 LTE3356 benefits....................................................................... 165
16.5 Activating LTE3356: Per Call Measurement Data (PCMD) - RRC
Connection Establishment Failures............................................169
16.6 Deactivating LTE3356: Per Call Measurement Data (PCMD) -
RRC Connection Establishment Failures...................................169

17 LTE3357: PCMD - Measurement Report .................................. 170
17.1 LTE3357 benefits....................................................................... 170
DN181051332 Issue: 01 © 2018 Nokia 5
17.5 Activating LTE3357: Per Call Measurement Data (PCMD) -
Measurement Report ................................................................ 175
17.6 Deactivating LTE3357: Per Call Measurement Data (PCMD) -
Measurement Report................................................................. 175

18 LTE3361: FZM filesystem encryption......................................... 176
18.1 LTE3361 benefits....................................................................... 176

19 LTE3475: Additional KPIs for Performance Monitoring ............. 178
19.1 LTE3475 benefits....................................................................... 178

20 LTE3488: SFP Data Availability via BTS CLI............................. 185
20.1 LTE3488 benefits....................................................................... 185
20.2 ................................................................................................... 185
20.3 ................................................................................................... 189
20.5 LTE3488 standalone version start-up.........................................190

21 LTE3540: Descriptive BTS Parameters......................................195
21.1 LTE3540 benefits....................................................................... 195

22 LTE3627: Windows 10 Support for Network Element Manager. 199
22.1 LTE3627 benefits....................................................................... 199

23 LTE3701: Counter Profiles Enhancements Including the UE
Category.....................................................................................202
23.1 LTE3701 benefits....................................................................... 202

24 LTE3778: User throughput to include the Initial Burst Delay .....208
24.1 LTE3778 benefits....................................................................... 208

6 © 2018 Nokia DN181051332 Issue: 01
25 LTE3831: System Upgrade to FDD-LTE 17A and TD-LTE 17A.......
211
25.1 LTE3831 benefits........................................................................211
25.5 Upgrading the LTE eNB to LTE 17A...........................................217
25.6 Rolling back the LTE 17A upgrade.............................................228

26 LTE3841: Cloud Flexi Zone Controller and Wireless LAN
Controller All-In-One.................................................................. 230
26.1 LTE3841 benefits....................................................................... 230
DN181051332 Issue: 01 © 2018 Nokia 7
List of Figures
Figure 1 Differences in acceptance of incoming traffic before and after the
LTE529 feature................................................................................... 15
Figure 2 Overview of the new roles.................................................................. 27
Figure 3 Overview Flexi Zone Plug and Play Auto Connection........................ 35
Figure 4 Flexi Zone Plug and Play Auto-Connection........................................37
Figure 5 Deployment Scenario 1a: CA-server accessible only in operator's
private network AND the initial security gateway and the serving
security gateway are the same...........................................................40
Figure 6 Deployment Scenario 1b: CA-server is accessible only in operator's
private network AND the initial security gateway and the serving
security gateway are different.............................................................41
Figure 7 Deployment Scenario 2: CA-server accessible via the public network...
43
Figure 8 Certificate enrollment using synchronous and asynchronous API..... 54
Figure 9 Lifecycle management of operator certificate in eNB/SBTS (LTE17A)..
55
Figure 10 Software upgrade provided by the RAN3382 feature.........................60
Figure 11 The cFZC features distribution per release........................................ 78
Figure 12 Flexi Zone architecture....................................................................... 79
Figure 13 Adapting Flexi Zone solution to Radio Cloud..................................... 80
Figure 14 Mapping Nokia products to ETSI NFV reference architectural
framework...........................................................................................85
Figure 15 Top level objects in the hierarchy....................................................... 89
Figure 16 The EQM and EQM_R object trees....................................................90
Figure 17 The MNL tree......................................................................................91
Figure 18 The MNLENT subtree.........................................................................92
Figure 19 The LNBTS tree..................................................................................95
Figure 20 The LNCEL tree..................................................................................96
Figure 21 PCMD features distribution per release............................................124
Figure 22 Per call measurement data (PCMD) overview................................. 125
Figure 33 SFP Data Availability via BTS CLI.................................................... 188
8 © 2018 Nokia DN181051332 Issue: 01
Figure 34 Load the Gateway............................................................................ 191

Figure 35 Configure the Tunnel........................................................................ 192
Figure 36 Open the Tunnel............................................................................... 193
Figure 37 CM Operations Manager window..................................................... 219
Figure 38 Workflow Engine window..................................................................220
Figure 39 Upgrade-LTE BTS option................................................................. 221
Figure 40 Working set selection....................................................................... 222
Figure 41 Prepare for upgrade operation......................................................... 223
Figure 42 Software Manager selection............................................................. 224
Figure 43 Upload configuration data option......................................................225
Figure 44 Upload configuration data operation selection................................. 226
Figure 45 Update non-network data operation................................................. 227
Figure 46 cFZC features distribution................................................................ 230
Figure 47 Architecture overview....................................................................... 231
DN181051332 Issue: 01 © 2018 Nokia 9
List of Tables
Table 1 LTE529 hardware and software requirements....................................18
Table 2 New parameters introduced by LTE529............................................. 19
Table 3 LTE529 sales information................................................................... 19
Table 4 Roles and local accounts in the BTS..................................................25
Table 5 LTE1523 hardware and software requirements..................................29
Table 6 New parameters introduced by LTE1523........................................... 29
Table 7 LTE1523 sales information................................................................. 30
Table 8 RAN3379 hardware and software requirements................................ 46
Table 9 Existing parameters related to RAN3379........................................... 47
Table 10 RAN3379 sales information................................................................47
Table 11 Parameters used for activating and configuring RAN3379: Enhanced
Flexi Zone Plug and Play for Non-Operator Owned Backhaul .......... 48
Table 15 Summary of changes..........................................................................59
Table 16 RAN3382 hardware and software requirements................................ 63
Table 17 sales information................................................................................ 64
Table 21 Mandatory Parameters....................................................................... 69
Table 23 Existing parameters related to LTE3042............................................ 82
Table 25 Hardware profiles for vOMS............................................................... 86
Table 26 RAN3358: OMS for CBIS hardware and software requirements........86
Table 27 New alarms introduced by RAN3358: OMS for CBIS.........................86
Table 28 Existing SCLI commands related to RAN3358: OMS for CBIS.......... 87
Table 29 RAN3358: OMS for CBIS sales information....................................... 87
Table 30 Comparison of Cell Mapping configurations.......................................93
Table 31 Parameters moved or replaced by LTE3296...................................... 96
Table 32 Detected hardware parameters that may differ from their
commissioned values....................................................................... 113
Table 33 LTE3296/SR001527 software requirements..................................... 116
Table 34 LTE3296/SR001527 sales information............................................. 117
Table 35 LTE3303 hardware and software requirements................................ 118
Table 36 E-RAB release due to inter-RAT handovers to UTRAN or GERAN
counters introduced by LTE3303...................................................... 119
10 © 2018 Nokia DN181051332 Issue: 01
Table 37 E-RAB release due to S1 interface reasons counters introduced by
LTE3303............................................................................................119
Table 38 VoLTE PRB usage counter introduced by LTE3303......................... 120
Table 39 HARQ BLER counters introduced by LTE3303................................ 120
Table 40 UE context release counters introduced by LTE3303...................... 121
Table 41 VoLTE TTI bundling counters introduced by LTE3303..................... 121
Table 42 Carrier aggregation (CA) downlink deconfiguration counters
introduced by LTE3303.....................................................................122
Table 43 PMQAP profile counters introduced by LTE3303............................. 122
Table 44 New parameters introduced by LTE3303......................................... 122
Table 45 LTE3303 sales information............................................................... 123
Table 46 Summary of changes........................................................................124
Table 47 LTE3333/3334/3335/3336/3356/3357 hardware and software
requirements.....................................................................................126
Table 48 Alarms modified by LTE3333............................................................127
Table 49 Existing BTS faults related to LTE3333............................................ 127
Table 50 Types of measurements related to LTE3333: Per Call Measurement
Data (PCMD):................................................................................... 127
Table 52 Existing parameters related to LTE3333.......................................... 129
requirements.....................................................................................138
Table 56 Types of measurements collected and provided by the LTE3334: Per
Call Measurement Data – Per Bearer Report feature...................... 139
requirements.....................................................................................143
Table 60 Measurements/values collected and provided by the LTE3335: Per
Call Measurement Data – CA Report feature...................................144
requirements.....................................................................................150
Table 64 Types of measurements collected and provided by the LTE3336: Per
Call Measurement Data (PCMD) – Per Call Report Extension feature..
150
Table 66 New alarms introduced by LTE3342.................................................154
Table 67 Path attribute in category alarms......................................................155
Table 68 LTE3342/SR001534 hardware and software requirements..............159
Table 69 Software required for SR001534 SRAN FM combined Service....... 160
DN181051332 Issue: 01 © 2018 Nokia 11
Table 70 New alarms introduced by LTE3342.................................................160
requirements.....................................................................................167
requirements.....................................................................................172
Table 78 Measurement data related to LTE3357: PCMD – Measurement Report
feature.............................................................................................. 173
Table 80 LTE3361 hardware and software requirements................................177
Table 83 New counters introduced by LTE3475..............................................180
Table 85 Existing key performance indicators related to LTE3475................. 182
Table 89 LTE3488 summary of changes......................................................... 185
Table 90 SFP data description........................................................................ 185
Table 91 admin-cli command parameters................................................. 188
Table 94 LTE3488 getSfpData script credentials............................................ 194
Table 98 LTE3627 Summary of changes........................................................ 199
Table 101 Examples of counter profiles............................................................ 203
Table 103 Existing counters related to LTE3701............................................... 205
12 © 2018 Nokia DN181051332 Issue: 01
Table 110 ..........................................................................................................213
DN181051332 Issue: 01 © 2018 Nokia 13

LTE529: Dynamic X2 and S1 Firewall Configuration LTE17A Operability Features
1 LTE529: Dynamic X2 and S1 Firewall

Configuration
The LTE529: Dynamic X2 and S1 Firewall Configuration feature enhances the integrated
firewall by allowing traffic only from
• operator-configured neighbor sites and MME nodes
• neighbor sites learned by ANR
• operator-configured serving gateways (S-GW)
• serving gateways (S-GW) learned by S1 signalling E-RAB procedures
The firewall rules are automatically managed by the BTS.
1.1 LTE529 benefits

With the LTE529: Dynamic X2 and S1 Firewall Configuration feature, BTS security is
improved since the incoming traffic is allowed only from known and configured neighbor
eNBs, MMEs, and S-GWs, and is blocked from any other source. Before this feature,
incoming traffic was allowed from any source – only the destination address and
protocols were verified.
1.2 LTE529 functional description

Nokia BTS has an integrated software firewall, which cannot be turned off. The firewall
filters the traffic based on the rules automatically derived from the LTE IP topology. The
BTS firewall functionality applies to all external interfaces, for example S1-MME, S1-U,
X2-C, X2-U, O&M, and ToP. Before LTE529, firewall rules were defined as follows:
• user-plane traffic is allowed from any source
• control-plane traffic is allowed from any source
• all rules are common to X2 and S1
With the LTE529 feature, the above rules are removed and a new set of rules for X2 and
S1 is created.
14 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE529: Dynamic X2 and S1 Firewall Configuration
Figure 1 Differences in acceptance of incoming traffic before and after the LTE529
feature
WithLTE529disabled,BTSacceptstrafficfromallBTSs
andcorenodes
allowedtraffic
WithLTE529enabled,BTSacceptstrafficfromneighborBTSsand
authorizedcorenodes
allowedtraffic
not-allowedtraffic
X2 and S1 firewall rules

The LTE529: Dynamic X2 and S1 Firewall Configuration feature enhances the integrated
firewall by allowing:
• X2 traffic (control- and user-plane) only between eNBs with neighbor relations
(defined by the operator or automatic neighbor relation)
• S1 GTPu traffic (user-plane traffic) between the eNB and S-GW, only if its address
was provided by the MME or when the S-GW is configured as the subject of GTPu
path supervision
• S1 SCTP traffic (control-plane traffic) only between the eNB and operator-configured
MMEs (multi-homing is supported)
In addition, the operator is allowed to manually configure lists of S-GW IP addresses,
either for accepting responses to eNB-initiated GTP-U path supervision, or for accepting
S-GW-initiated GTP-U path supervision requests.
The BTS starts up with all incoming control-plane and user-plane blocked, except for the
traffic allowed by available stateless filter rules. The rules are updated in the following
cases:
• when a neighbor is added, modified, or removed by automatic neighbor relation
(ANR) (applies to “eNB controlled” neighbors)
DN181051332 Issue: 01 © 2018 Nokia 15

• when a neighbor is added, modified, or removed by the operator (applies to “O&M
controlled” neighbors)
• when a new S-GW is detected during E-RAB setup or handover scenarios
• when an S-GW is configured by the operator for GTP-U Path Supervision or as a
Trusted S-GW
• when an MME is added, modified, or removed by the operator
Firewall rules are updated automatically in runtime, without a reset or service break.
Rules creation
The following scenario takes place on a BTS start-up:
1. The BTS blocks incoming control-plane and user-plane traffic.
2. For each existing "O&M controlled" neighbor, the BTS creates a set of rules in the
firewall to allow incoming control-plane and user-plane traffic from that neighbor.
3. For each entry in the Trusted firewall S-GW IP address
list (trustedFirewallSgwIpAddrList) and SGW IP address
list (sgwIpAddressList) lists (created by the operator), the BTS creates rules
to allow incoming user-plane traffic from IP addresses defined on this list.
4. The BTS creates wildcard rules, which allow incoming M3 (MBMS) traffic interface
from any source.
If LTE529 is not enabled, the BTS creates wildcard firewall rules allowing incoming
control-plane and user-plane from any source.
New parameters
There are three new parameters introduced:
• IPNO Feature Activation Flag for dynamic X2 & S1 firewall
configuration (actDynamicFirewall)
• GTPU Trusted firewall S-GW IP address
list (trustedFirewallSgwIpAddrList)
The trustedFirewallSgwIpAddrList parameter contains the manually
configured list of remote Serving Gateway (S-GW) user plane IP addresses, which
are an allowed access in the firewall. If the transport separation for RAN sharing is
enabled, S-GW addresses for the other transport network can also be configured.
Configuration of this parameter is optional, if the firewall is wanted to allow S-GW-
initiated GTP-U path supervision.
• LNADJ U-Plane IPv4/v6 addresses of neighbor
eNB (uPlaneIpAddrList)
The uPlaneIpAddrList parameter represents the user plane IP address(es) of
the neighbor eNB. It is required to allow packets from that neighbor eNB to pass the
firewall during direct forwarding of an X2 handover. If this information is not
configured, user plane traffic from that eNB during the X2 handover will be dropped.
For “eNB controlled” neighbors that were discovered via ANR
(cPlaneIpAddrCtrl is set to “eNBControlled”), the IP address(es) are received
from the neighbor eNB during S1AP signaling (in the S1AP: MME Configuration
Transfer) and thus is managed automatically. Automation relies on the neighbor eNB
to include IP information (refer to TS 36.413 S1AP: eNB X2 Extended Transport
Layer Addresses information element). If the neighbor eNB does not include this
information, the LNADJ will need to be changed to an “O&M controlled” neighbor
and IP addresses will need to be managed manually as described below.
16 © 2018 Nokia DN181051332 Issue: 01

For “O&M controlled” neighbors (cPlaneIpAddrCtrl is set to “oamControlled”),
the IP address(es) must be managed manually. For Nokia eNBs, the operator will be
able to find this information in NetAct. However, for non-Nokia eNBs, the operator will
have to import this information via the Northbound Interface (NBI) first.
LNADJ objects must be symmetrically created, otherwise X2 link setup will fail. This
means that if eNB-1 has an LNADJ object pointing to eNB-2, then eNB-2 must have
LNADJ object pointing to eNB-1. For “O&M controlled” neighbors where the operator is
managing these objects, the operator must ensure that LNADJ is configured on each
eNB. For “eNB controlled” neighbors, ANR should result in symmetric LNADJ objects
being created. However, it is possible for the LNADJ to be created on one eNB and not
the other, for example, when the maximum number of these objects has been reached
on one eNB but not the other. In this case, the operator will either need to manually
manage the neighbors to allow this object to be created, or wait until the LTE1685:
Neighbor Relation Robustness feature automatically removes unused LNADJ objects.
1.3 LTE529 system impact

LTE529: Dynamic X2 and S1 Firewall Configuration impact on features
Interdependencies between features

The LTE529: Dynamic X2 and S1 Firewall Configuration feature should not be activated
together with the LTE492: ANR with OAM Extension feature. If both features are
activated, then X2 setup will fail for any neighbor eNB that is “discovered” using LTE492.
The LTE492 feature allows eNB discovery from any eNB, which is not a secure method
of discovering eNBs (there is no screening). X2 setup will fail for any neighbor eNB that
is discovered using LTE492, as the firewall will not have been updated for the neighbor
eNB’s X2 control plane address (since it is not considered a “trusted” eNB).
There may be cases for LTE1749 :Mobility Robustness Monitoring Inter RAT where an
eNB needs to forward an X2 RLF INDICATION message from one eNB to another,
where those eNBs may or may not be geographically located near each other. With
LTE529, the eNB will no longer just accept X2 setup requests from any eNB. Rather the
eNB will have to either be discovered via ANR or manually configured by the operator, so
that the firewall will allow incoming X2 setup messaging from that eNB (and thus allow
the reception of the X2 RLF INDICATION). In those cases where the eNB is not
geographically close, the operator will have to manually add the LNADJ object as an
“O&M controlled” neighbor.
System behaviour when upgrading from previous release

If LTE492 had been activated and the operator wants to activate LTE529, the operator
will need to take special care to minimize system impact (for example, handovers related
to these neighbors).
Neighbor eNBs that are discovered by LTE492 (due to the PCI mapping table,
pciIpAdrMap, or based on an incoming X2 SETUP REQUEST) will be treated as “eNB
controlled” neighbors. When LTE492 is deactivated, the eNB will initiate the S1AP SON
Configuration Transfer procedure for these LNADJ objects in preparation for setting up
the X2 link (requires LTE782 and/or LTE556 to be enabled). As part of this procedure,
DN181051332 Issue: 01 © 2018 Nokia 17

the cPlaneIpAddr and the new uPlaneIpAddrList parameter in the LNADJ will be
automatically populated (as long as the neighbor eNB includes it) and the firewall will be
appropriately updated. The X2 link is then re-established.
The suggested order of steps to minimize system impact is as follows:
1. Activate LTE529 - the operator will first activate LTE529, before deactivating LTE492.
This will cause the LTE492-created X2 links to go down (due to the firewall at the
“target” not having the “source” IP address) and the links will become unavailable.
2. Deactivate LTE492 - This will immediately trigger the SON Configuration Transfer for
each such neighbor which will result in the uplaneIpAddrList parameter being
exchanged, the firewall being updated, and the X2 link being re-established.
g Note: It is expected that each X2 link will automatically recover in at most 4 minutes
and 40 seconds.
3. For any eNB which may not provide the uplaneIpAddrList in the SON
Configuration Transfer, the operator will have to change the LNADJ to be "O&M
controlled" and manually populate the new uPlaneIpAddrList parameter in the
LNADJ object.
g Note: Any Nokia eNB that has been upgraded to LTE17A will support sending the
uplaneIpAddrList, and so this generally will not apply to Nokia eNBs. However, for
non-Nokia eNBs, the operator will have to import this information via the Northbound
Interface (NBI) first. These neighbors will become manually controlled by the operator
(as opposed to automatically managed/updated by SON/ANR) and the X2 links will be
established/maintained based on this.
The operator may deactivate LTE492 before activating LTE529, however in this case, the
SON Configuration Transfer may not be immediately initiated to recover each X2 link.
However, it is still expected that each X2 link will automatically recover in at most 4
minutes and 40 seconds. Note that if the operator leaves LTE492 activated, they will see
X2 setup failures for all neighbors that had been created due to LTE492.
Changing of an eNB’s local user plane address and necessary actions

When the operator changes the local U-Plane IP address of an eNB-1, they must also
change each corresponding LNADJ object, which represents that eNB-1 as neighbor of
a different eNB-2, either manually or via their own planning tools. For any neighbor eNB-
2 (represented by LNADJ) for which this uPlaneIpAddrList is not updated, direct
forwarding from eNB-1 to eNB-2 during X2 handover will not work and downlink packets
will be dropped.
1.4 LTE529 reference data

LTE529: Dynamic X2 and S1 Firewall Configuration requirements, alarms and faults,
commands, measurements and counters, KPIs, parameters, and sales information
Requirements
Table 1 LTE529 hardware and software requirements
FDD TDD
System release FDD-LTE 17A TD-LTE 17A
18 © 2018 Nokia DN181051332 Issue: 01

Table 1 LTE529 hardware and software requirements (Cont.)
FDD TDD
Flexi Multiradio 10 BTS FL17A TL17A
Flexi Multiradio 10 Indoor BTS not supported TL17A
Nokia AirScale BTS FL17A TL17A
Flexi Zone BTS not supported not supported
Flexi Zone Access Point not supported not supported
Cloud Flexi Zone Controller not supported not supported
OMS support not required support not required
NetAct 17.2 17.2
MME support not required support not required
SAE GW support not required support not required
UE support not required support not required
There are no alarms, commands, measurements and counters, and key performance
indicators to the LTE529: Dynamic X2 and S1 Firewall Configuration feature.
Parameters
Table 2 New parameters introduced by LTE529
Full name Abbreviated name Managed Parent structure FDD/TD
object D
Feature Activation actDynamicFirewa IPNO - common
Flag for dynamic X2 ll
& S1 firewall
configuration
Trusted firewall S- trustedFirewallS GTPU - common
GW IP address list gwIpAddrList
U-Plane IPv4/v6 uPlaneIpAddrList LNADJ - common
addresses of
neighbor eNB
For parameter descriptions, see LTE Operating Documentation/Reference/Parameters
Sales information
Table 3 LTE529 sales information
Product structure class License control Activated by default
Application software (ASW) pool licence No
1.5 Enabling dynamic firewall configuration

Instructions to activate and configure the LTE529: Dynamic X2 and S1 Firewall
Configuration feature using the BTS Site Manager
DN181051332 Issue: 01 © 2018 Nokia 19

Before you start

• Procedure notifications
– Activation procedure does not cause downtime, and the feature can be activated
at any time of the day.
– Before performing the procedure, make sure that you read all information in
LTE529 system impact.
• Feature interdependencies
The LTE529: Dynamic X2 and S1 Firewall Configuration feature should not be
activated together with the LTE492: ANR with OAM Extension feature. If both
features are activated, the X2 setup will fail for any neighbor eNB that is “discovered”
using LTE492.
Procedure
1 Start the BTS Site Manager application and establish the connection to the BTS.
2 Start commissioning.
Sub-steps
a) Select View ► Commissioning or click Commissioning on the View Bar on the
left.
The BTS Site checkbox, located in the Target section, is selected by default.
This is the recommended setting.
b) Use the Template, Manual, or Reconfiguration option, depending on the actual
state of the BTS.
3 Proceed to the Security page and select the TLS and firewall object.
4 Check the Enable dynamic X2 and S1 firewall checkbox.
This checkbox represents the actDynamicFirewall parameter.
Step example
20 © 2018 Nokia DN181051332 Issue: 01

5 Optional: Proceed to the Radio Network Configuration page.
6 Deactivate the LTE492: ANR feature
Sub-steps
a) Go to the LNBTS object
b) Set Activate ANR support for LTE with OAM extension (anrOmExtEnable) to
false.
7 Optional: Change “eNB controlled” LNADJ to “O&M controlled” for eNBs which do not
support uPlaneIpAddrList during SON Configuration Transfer.
The C-Plane IP address control (cPlaneIpAddrCtrl) in LNADJ

object should be set to oamControlled”
g Note: Any Nokia eNB that has been upgraded to LTE17A will support sending the
uplaneIpAddrList, and so this step applies to non-Nokia neighbor eNBs.
8 Optional: Update uPlaneIpAddrList for any "O&M controlled" LNADJ
Object path: LNBTS ► LNADJ
To create a new list, right-click the LNADJ object and select New ► U-Plane
IPv4/IPv6 addresses of neighbor eNB. This parameter is required to allow packets
from neighbor eNB to pass the firewall during direct forwarding of an X2 handover.
Maximum 16 U-Plane addresses of an neighbor eNB may be configured.
DN181051332 Issue: 01 © 2018 Nokia 21

9 Optional: Create a list of trusted firewall S-GW IP addresses.
g Note: The eNB receives the S-GW IP addresses from the MME, and these IP
addresses are not visible in the configuration. The firewall should automatically trust
them, therefore this step is required only in case of problems with this automatic
solution.
The eNB receives the S-GW IP addresses from the MME. These IP addresses are
not visible in the configuration, and the firewall will automatically trust them.
Optional: S-GW IP addresses have to be configured for GTP-U path supervision
purposes. Go to GTPU object LNBTS ► GTPU.
If eNB-initiated GTP-U path supervision is desired: Configure the S-GW IP address
in the S-GW IP address list, in order to let the firewall trust responses to eNB-initiated
GTP-U path supervision. Maximum 32 IP addresses may be configured.
If only S-GW-initiated GTP-U path supervision is desired: Configure the S-GW IP
address in the Trusted firewall S-GW IP address list, in order to let the firewall trust
S-GW-initiated GTP-U path supervision requests. Maximum 10 IP addresses may be
configured.
If GTPU object is not existing yet, you need to create it by right-clicking on LNBTS
object and selecting New ► GTPU.
10 Send the commissioning plan file to the BTS.
Sub-steps
a) Go to the Send Parameters page.
b) Select an appropriate Send option.
• If the BTS has not been commissioned, select All parameters.
• If the BTS has been already commissioned, select Only changes.
c) Click Send Parameters.
Result
The firewall allows traffic only from neighbor sites and serving gateways (S-GWs).
1.6 Disabling dynamic firewall configuration

Instructions to deactivate the LTE529: Dynamic X2 and S1 Firewall Configuration feature
using the BTS Site Manager
Before you start

Deactivation procedure does not cause downtime, and the feature can be deactivated at
any time of the day.
22 © 2018 Nokia DN181051332 Issue: 01

Procedure
Sub-steps
left.
state of the BTS.
3 Proceed to the Security page.
4 Go to the TLS and firewall object.
5 Uncheck the Enable dynamic X2 and S1 firewall checkbox.
This checkbox represents the actDynamicFirewall parameter.
Step example
6 Optional: Proceed to the Radio Network Configuration page.
7 Optional: Go to GTPU object.
Object path: LNBTS ► GTPU
DN181051332 Issue: 01 © 2018 Nokia 23

8 Optional: Delete the list of trusted firewall S-GW IP addresses.
If eNB-initiated GTP-U path supervision is still desired, the S-GW IP address list has
to be kept. The Trusted firewall S-GW IP address list may be deleted
(but could be kept, if a later re-enabling of LTE529 is possible).
Sub-steps
Result
The feature is deactivated and firewall exceptions rules do not take neighboring sites into
consideration.
24 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE1523: Role-based BTS User Accounts
2 LTE1523: Role-based BTS User Accounts

Benefits, functionality, system impact, reference data, instructions of the feature
The LTE1523: Role-based BTS User Accounts feature introduces the following

improvements to the BTS local user account:
• three new local user accounts (disabled by default)
• four new roles (each for one of the four local accounts)
• alias username
2.1 LTE1523 benefits

The LTE1523: Role-based BTS User Accounts feature provides the following benefits:
• the operator can define multiple accounts with specific permissions
• access to security-relevant configuration options can be restricted to authorized
personnel only
• the operator can separate the service duties for users who need to administer the
BTS and users who need read-only access
• the operator can modify the default names of local accounts

In addition to the already existing local account, the LTE1523 feature introduces three
new accounts. Each of the local accounts is assigned with a role. The roles and local
accounts are summarized in the table below.
Table 4 Roles and local accounts in the BTS
Role name System Security Application Read Only user
Administrator Administrator Administrator
Account Nemuadmin BTSSecurity BTSApplication BTSRead
name
Privileges full system read- restricted system restricted system read-only
write privileges read-write read-write privileges
privileges privileges
What can be can manage all can manage only can manage all can read all BTS
performed BTS applications the BTS security BTS applications applications and
and configuration applications and and configuration configuration
(including security configuration (BTS except the ones except security
configuration) local security and related to security credential data
hardening settings, such as SSH keys,
certificates) etc.
DN181051332 Issue: 01 © 2018 Nokia 25

LTE1523: Role-based BTS User Accounts LTE17A Operability Features
Table 4 Roles and local accounts in the BTS (Cont.)
Role name System Security Application Read Only user
Administrator Administrator Administrator
Account Nemuadmin BTSSecurity BTSApplication BTSRead
name
Which • can change • can change can change can change
accounts password of password and password of password of
can be Nemuadmin, alias of BTSApplication BTSRead
controlled and password BTSSecurity,
and alias of BTSApplicatio
BTSSecurity, n, BTSRead
BTSApplicatio • can
n, BTSRead activate/deacti
• can vate
activate/deacti BTSApplicatio
vate n, BTSRead
BTSSecurity,
BTSApplicatio
n, BTSRead
Activation always active must first be must first be must first be

activated by the activated by the activated by the
system system or security system or security
administrator administrator administrator
before it can be before it can be before it can be
used (disabled by used (disabled by used (disabled by
default) default) default)
26 © 2018 Nokia DN181051332 Issue: 01

Figure 2 Overview of the new roles
RemoteOperator
NetAct AccountDataBase BTS
LocalOperator
SystemAdmin AccountDataBase
unlimitedsystemaccess
SecurityAdmin
securitysettings
certificatemanagement
ApplicationAdmin
siteconfiguration
radioandtransportconfiguration
Read-onlyuser SWmanagement
performancemanagement
All four local accounts support all existing account policies, for example, aging, account
lockout, session login delay, password complexity. All four roles can also be assigned to
CNUM users (via NetAct).
The Nemuadmin account's default username and password can be changed using
Network Element Manager or NetAct NEAC, and it does not support the alias username
(which is an alternate username that can be set by the operator). The three new
accounts:
• BTSSecurity
• BTSApplication
• BTSRead
support the alias username, which can be set using Network Element Manager or NetAct
NEAC. It is not possible to change the default username for those accounts. The alias
username must range 4–16 characters. Once the alias is set, and an account is
activated, the user can log in to the BTS using either the default username or the alias
username with the correct password.
g Note: When setting the alias username/changing Nemuadmin username from NEAC,
the operator has to delete the existing NEAC entry for the specific account type and add
a new entry.
Introduction of the new local accounts impacts the number of sessions which can be
established simultaneously for Network Element Manager, Transport Web Page, WebUI,
or the ADMIN tool. The restrictions are:
DN181051332 Issue: 01 © 2018 Nokia 27

• five active sessions for Network Element Manager: one read-write access
(Nemuadmin, BTSSecurity or BTSApplication account can establish this session)
and four additional read-only sessions
• nine active TCP connections for Transport Web Page (regardless of user read-
only/read-write restrictions)
• multiple active sessions for the ADMIN tool (only the BTS System Administrator role
is allowed to access the ADMIN tool)
For the three new local user accounts, the following configurable parameters are
introduced:
• alias username
• password
• account activation status

LTE1523: Role-based BTS User Accounts impact on features

The LTE1523: Role-based BTS User Accounts feature interacts with the following
features:
• LTE679: LTE Local User Account Management – this feature introduces a local user
account management for the BTS
• LTE666: LTE User Account Management – this feature enables the Centralized
Network Element User Management for the BTS
• LTE643: Multiple Read Sessions for BTS Site Manager – this feature introduces
read-only access privileges and support for multiple sessions
• LTE580: Session Login Delay – this feature introduces a delay between consecutive
failed login attempts and an account locking period for operator's user accounts
• LTE967: Password Aging and Account Locking – this feature introduces password
aging and account locking for operator's user accounts
• LTE2883: Application of Diagnostic and Maintenance for Intelligent Network – this
feature introduces a web-based tool (ADMIN tool) for eNB diagnostic tasks
• LTE2360: Login Restriction with CNUM – this feature allows to disable the local
account if CNUM is in use
The LTE1523: Role-based BTS User Accounts feature has no impact on interfaces,

network management tools, and system performance and capacity.

LTE1523: Role-based BTS User Accounts requirements, alarms and faults, commands,
measurements and counters, KPIs, parameters, and sales information
Requirements
28 © 2018 Nokia DN181051332 Issue: 01

FDD TDD
NetAct 17.8 17.8
Alarms
There are no faults and alarms related to the LTE1523: Role-based BTS User Accounts
feature.
Measurements and counters

There are no measurements or counters related to the LTE1523: Role-based BTS User
Accounts feature.
Key performance indicators

There are no key performance indicators related to the LTE1523: Role-based BTS User
Accounts feature.
Parameters
Full name Abbreviated name Manage Parent structure FDD/TDD
d object
Alias username of appAdmAlias LUAC - common
BTS Application
Administrator local
user
Password of BTS appAdmPassword LUAC - common
Application
Administrator local
user
Activate BTS appAdmActivate LUAC - common
Application d
Administrator local
user
DN181051332 Issue: 01 © 2018 Nokia 29

Table 6 New parameters introduced by LTE1523 (Cont.)
d object
Alias username of readOnlyAlias LUAC - common
BTS Read-Only local
user
Password of BTS readOnlyPasswo LUAC - common
Read-Only local rd
user
Activate BTS Read- readOnlyActiva LUAC - common
Only local user ted
Alias username for secAdmAlias LUAC - common
BTS Security
Administrator local
user
Password of BTS secAdmPassword LUAC - common
Security
Administrator local
user
Activate BTS secAdmActivate LUAC - common
Security d
Administrator local
user
For parameter descriptions, see LTE Operating Documentation/Reference/Parameters
Sales information
Application software (ASW) SW Asset Monitoring No
2.5 Activating and configuring local accounts

In order to improve security, the operator should change the default credential of the
local account. With the LTE1523: Role-based BTS User Accounts feature, the operator
can further improve security of BTS by enabling local accounts with limited access
rights.
Before you start

Configuration of the local accounts can be performed for each eNB separately using the
BTS Site Manager. The mass configuration of local accounts for many eNBs can be
performed using NetAct Network Element Access Control (NEAC) tool. You can learn
more about local accounts in the LTE1523 feature description. To configure the local
accounts using BTS SM, do the following:
30 © 2018 Nokia DN181051332 Issue: 01

Procedure
2 From the upper menu select Configuration ► Change Local Account.
Step example
3 Change the default user name and/or password for System administrator account.
4 Enable role-based local accounts.
You can enable three additional local accounts:
• security administrator (manages only the BTS security applications and
configuration)
• application administrator (manages all BTS applications and configuration except
the ones related to security)
• read-only user (sees all BTS configurations except for security settings).
In order to enable an account, you need to check the Enable user account
checkbox and provide a password. You can also configure alias username (please
note that each alias user name must be unique).
Step example
5 Send the changes to the BTS.
Result
DN181051332 Issue: 01 © 2018 Nokia 31

The BTS local accounts are enabled and configured. The overall security of user
accounts is increased, thanks to the separation of different users and updated
credentials.
2.6 Deactivating role-based local accounts

It is possible to disable three types of local accounts: security administrator, application
administrator, and read-only user. The system administrator account is always active.
Before you start

To disable the local accounts, do the following:
Procedure
2 From the upper menu select Configuration ► Change Local Account.
Step example
3 Disable role-based local accounts.
In order to disable an account, you need to uncheck the Enable user account

checkbox.
Step example
4 Send the changes to the BTS.
Result
32 © 2018 Nokia DN181051332 Issue: 01

It is no longer possible to log in using role-based account.
2.7 Managing local accounts using NetAct

It is possible to configure the local BTS user account using the NetAct's NEAC tool.
Procedure
1 Open NetAct Start Page and navigate to the Security section.
2 Open the Network Element Access Control (NEAC) tool.
3 Open the Credential tab.
4 If you want to create a new account, press New.
Sub-steps
a) Select Service type: BTS Account Access.
b) Select correct type of account using Profile.
c) Configure username and password.
d) For Network Element, select the most suitable option.
e) Press Save.
Step example
DN181051332 Issue: 01 © 2018 Nokia 33

5 If you want to delete or modify the account, use the appropriate buttons.
Step example
34 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features RAN3379: Enhanced Flexi Zone Plug and Play for Non-
Operator Owned Backhaul
3 RAN3379: Enhanced Flexi Zone Plug and Play

for Non-Operator Owned Backhaul
Introduction to the feature
The RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator Owned Backhaul
feature supports the existing Plug and Play solution for the Flexi Zone Micro/Pico BTS.
The feature supports no-touch Plug and Play on non-operator owned backhaul, such as
enterprise and public backhaul deployments.
Benefits
End-user benefits
This feature does not affect the end-user experience.
Operator benefits
This feature enables operators to perform no-touch Plug and Play for small cells on non-
operator owned networks, such as enterprise and public backhaul deployments. The
Plug and Play is performed without the need to provision the external Dynamic Host
Configuration Protocol (DHCP) servers with BTS or operator specific information. There
is also an operational expense savings for operators since all that is needed is an
existing enterprise network connection.
Functional description
Functional overview
The feature allows the Flexi Zone BTS to perform no-touch Plug and Play on un-trusted,
non-operator owned backhaul, such as enterprise and public backhaul deployments.
For an overview of Flexi Zone Plug and Play auto connection, see Figure 3: Overview
Flexi Zone Plug and Play Auto Connection. The Flexi Zone small cell uses basic auto-
connection parameters to establish connection with the operator’s Security Gateway
(SeGW), Certificate Authority Server (CA Server), and Configuration Server (OMS).
Figure 3 Overview Flexi Zone Plug and Play Auto Connection
Operator’s!Network
DHCP DNS
CA!Server
?
Flexi!Zone SeGW RNC/OMS NetAct
Small!Cell
DN181051332 Issue: 01 © 2018 Nokia 35

RAN3379: Enhanced Flexi Zone Plug and Play for Non- LTE17A Operability Features
RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator Owned Backhaul
(indicated by the blue line in Figure 3: Overview Flexi Zone Plug and Play Auto
Connection) supports the following capabilities:
• Parameters are pre-configured in the small cell BTS
• Pre-stage Fully Qualified Domain Names (FQDN) at a warehouse or factory
• Supports no-touch Plug & Play
• Supports IPv4 networks, for example where the operator core network is IPv4 and
the non-operator network is also IPv4
• Release WCDMAFZ 17 SP1 RAN3379: Enhanced Flexi Zone Plug and Play for Non-
Deployment scenarios
Flexi Zone small cells are able to intelligently determine which auto-connection method
to utilize based on the deployment scenario and information made available, thereby
providing the most dynamic approach to Plug and Play. Nokia follows the Learn/Know
model for BTS initial network connectivity as follows:
Learn RAN1298: BTS Auto Connection
• Parameters are obtained from DHCP server
• Includes Nokia-specific DHCP options
• Supports no-touch Plug and Play
• Release WCDMAFZ15 (RAN1298: BTS Auto Connection)
Know RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator Owned
Backhaul
• Parameters are pre-configured in the small cell BTS
• Pre-stage FQDNs at a warehouse or factory
• Supports no-touch Plug & Play
• Release WCDMAFZ 17 SP1 RAN3379: Enhanced Flexi Zone Plug and Play for Non-
The Learn/Know model is described in Figure 4: Flexi Zone Plug and Play Auto-
Connection.
36 © 2018 Nokia DN181051332 Issue: 01

Figure 4 Flexi Zone Plug and Play Auto-Connection
Powerup
BTS Yes
commissioned? NormalStartup
Requestparametersfrom
DHCPserver
Vendorspecific Yes LEARN

parametersin RAN1298
DHCPOFFER? AutoConnection
No
RAN3379 Yes KNOW

parameters RAN3379
available? AutoConnection
g Note: This feature applies to both the Flexi Zone outdoor (Micro, Mini-Macro, Multiband
Outdoor BTSs) and Flexi Zone indoor (Indoor Pico and Multiband Indoor Pico BTSs)
products, but is not supported on the Flexi Zone Controller or Cloud Flexi Zone
Controller architecture.
Fully Qualified Domain Name (FQDN) format (instead of IP addresses) is used with
RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator Owned Backhaul.
The Flexi Zone BTS may be pre-provisioned prior to shipment with the operator-specific
transport information, or the operator enters the transport information. The operator-
specific transport information is as follows:
• The FQDN or the IP address of the certificate authority (CA) server
• The port number of the CA-server
• The subject name for the CA-server
• The certification management protocol (CMP) directory (URL) on the CA-server
• The FQDN(s) or the IPv4 address(es) of the initial security gateway (required only if
the operator's CA-server is only accessible through a security gateway)
DN181051332 Issue: 01 © 2018 Nokia 37

• The FQDN(s) or the IPv4 address(es) of the serving security gateway
• The FQDN(s) or IPv4 address(es) of the initial OMS
• The operator root certificate (required only if the operator's CA-server is only
accessible through a security gateway).
• MPlane IP Address Preference
This information is required to be preserved during a reset (including configuration reset
and factory reset). The operator has the ability to overwrite this information via the
Network Element Manager.
g Note:
Differences between the initial security gateway and the serving security gateway
• The initial security gateway information must be specified if the operator's CA-
server is behind a security gateway. If the operator's CA-server is accessible in the
public domain, the initial security gateway must NOT be specified.
• The serving security gateway information must ALWAYS be specified, irrespective
of the location of the CA-server. The operator can set the initial security gateway
differently from the serving security gateway, if the operator intends to limit the
access of the BTSs creating the IPSec tunnel using the vendor certificates with the
initial security gateway. If the operator does not plan to limit the access of such
BTSs (or plans to use other mechanisms to limit the access, for example, white
lists), the initial security gateway and the serving security gateway can be set to the
same values. Both of these must still be specified if the operator's CA-server is
behind a security gateway.
g Note: Primary and secondary FQDNs or IP addresses:

The primary and secondary FQDNs or IP addresses have been provided to allow
redundancy. If the primary device is not accessible, the eNB will automatically use the
secondary device.
The Flexi Zone BTSs that do not have this information pre-provisioned at shipment follow
existing Plug and Play procedures (RAN1298: BTS Auto Connection ).
DHCP process with Option 43
The DHCP process with Option 43 provides the Flexi Zone BTS in private backhaul
networks with an IP address and also provides information for the SeGW, CA server, and
the initial OMS. For the public backhaul case, DHCP Option 43 is not used and instead
relies on operator pre-comissioning of the parameters. The DHCP process steps are as
follows:
1. The BTS performs interface probing and broadcasts the DHCPDISCOVER message
untagged on the ports that are physically connected requiring Option 43 parameters.
The lease time requested by the BTS during auto-connection for private backhaul is
2 hours.
2. In parallel with step 1, the BTS starts the VLAN listening process and creates a list of
candidate VLAN IDs.
38 © 2018 Nokia DN181051332 Issue: 01

3. If a DHCPOFFER message with Option 43 parameters is received, then the BTS will
proceed with the rest of the auto-connection process. However, if no DHCPOFFER
message with Option 43 parameters is received on the untagged interface, the BTS
will send a DHCPDISCOVER message requiring Option 43 parameters on the
VLANs identified in step 2 for each of the physically connected ports in parallel.
4. If a DHCPOFFER message with option 43 parameters is received, then the BTS will
message with Option 43 parameters is received on the tagged VLANs identified in
step 3, then the BTS shall send a DHCPDISCOVER message requiring Option 43
parameters on all VLANs (from VLAN 1 to 4094 with 10 ms intervals between
consecutive VLANs), for each of the physically connected ports in parallel.
5. If a DHCPOFFER message with option 43 parameters is received, then the BTS will
message with Option 43 parameters is received, then the BTS checks if it is pre-
configured with operator-specific transport public backhaul information (that is,
SeGW info, CA server info, initial OMS info). If the BTS is not pre-configured with
operator specific transport information, then the BTS restarts the DHCP process with
Step 1.
6. If the BTS is pre-configured with operator-specific transport information, then the
BTS restarts the DHCP process, similar to the private backhaul setup as described
above. However, this time it will not require the DHCPOFFER message to contain
Option 43 parameters (though it will still request Option 43 parameters) since it now
considers itself to be in a public backhaul setup. The lease time requested by the
BTS during auto-connection for public backhaul is set to two hours, in order to
account for FQDN resolution, creation of bootstrap IPSec tunnel (using vendor
certificate), certificate enrollment, and subsequent creation of IPSec tunnel using
operator certificate.
If the Flexi Zone BTS receives appropriate information via Dynamic Host Configuration
Protocol (DHCP), it utilizes the existing Plug and Play procedures. Otherwise, if the Flexi
Zone BTS does not receive the necessary information via DHCP, it bypasses the existing
Plug and Play procedures and utilizes the modified procedures introduced with this
feature to obtain an IP address from the local DHCP server. The FZ BTS also connects
to the local DNS server to resolve the operator specific Fully Qualified Domain Names
(FQDN) into IP addresses and connects to the operator's transport network.
If an FQDN is provided for the OMS, the security gateway provides the IP address of the
operator's internal DNS via IKEv2 configuration payload in order to resolve the FQDN. If
the operator's security gateway does not support this function, an IP address is
provisioned for the initial OMS in the Flexi Zone BTS.
Once the Flexi Zone BTS has connected to the initial OMS, the remaining auto-
connection flow remains unchanged as does the auto-configuration flow.
If more than one FQDN (primary and secondary) are provided for the initial security
gateway, the Flexi Zone BTS will use the primary FQDN to connect. If that is not
successful, the Flexi Zone BTS will use the secondary FQDN for the connection. If more
than one IP address is returned when the FQDN of the initial security gateway is
resolved by the public DNS server, the Flexi Zone BTS will use the first IP address to
connect and ignore the rest. A similar approach is applied when connecting to the
serving security gateway and the initial OMS.
Use cases
The following use cases are described:
DN181051332 Issue: 01 © 2018 Nokia 39

Use case 1a: CA-server is accessible only in operator's private network AND the "initial
security gateway" and the "serving security gateway" are the same
Use case 1b: CA-server is accessible only in operator's private network AND the "initial
security gateway" and the "serving security gateway" are different
Use case 2: Plug and play deployment of FZ BTS in non-operator owned backhaul when
CA server resides in public (untrusted) network
Use case 3: Creation / Modification of auto-connection parameters for non-operator
owned (untrusted) backhaul
Use case 1a: CA-server accessible only in operator's private network AND the
"initial security gateway" and the "serving security gateway" are the same
Figure 5 Deployment Scenario 1a: CA-server accessible only in operator's private
network AND the initial security gateway and the serving security gateway
are the same
DHCP DNS
enterprise operator
network network
DHCP DNS CA
FlexiZoneBTS
enterprise Initialand
serving
transport security
network gateway
operator
transport
network
FlexiZoneBTS Internet
RNC/OMS NetAct
FlexiZoneBTS
public
DHCP DNS
network
RAN3379Plug&PlaySupport ExistingPlug&PlaySupport
Use case 1b: CA-server is accessible only in operator's private network AND the
initial security gateway and the serving security gateway are different
The operator can limit access from the initial security gateway to the CA server and
private DNS server (shown as a dotted red line in Figure 6: Deployment Scenario 1b:
CA-server is accessible only in operator's private network AND the initial security
gateway and the serving security gateway are different).
40 © 2018 Nokia DN181051332 Issue: 01

Figure 6 Deployment Scenario 1b: CA-server is accessible only in operator's private
network AND the initial security gateway and the serving security gateway
are different
DHCP DNS
enterprise operator
network network
Initialsecurity DHCP DNS CA

gateway
FlexiZoneBTS
enterprise Serving
transport security
network gateway
operator
transport
network
RNC/OMS NetAct
FlexiZoneBTS
public
DHCP DNS
network
Pre-conditions
• The BTS is physically installed in a non-operator owned backhaul network.
• The BTS is pre-configured with the following "minimum" operator-specific transport
information:
– The FQDN or the IP address of the primary initial security gateway (SeGW)
– The FQDN or the IP address of the primary serving SeGW
– The FQDN or the IP address of the CA-server
– The port number of the CA-server
– The subject name for the CA-server
– The CMP directory (URL) on the CA-server
– The FQDN or the IP address of the primary initial OMS (IPv4 for LTE2182, IPv6
for LTE3267)
– The operator's root certificate/trust anchor is installed
– The MPlane IP Address Preference parameter is set to IPv4
• If the FQDNs need to be resolved, the corresponding IP address(es) at the DNS
server(s) are specified.
• The BTS is pre-loaded with the WBTSZ17 1.0 or newer software.
• The OMS is pre-configured with the HW serial number and/or the GPS coordinates
for the BTS identification.
• The RAN3379 Enhanced Flexi Zone Plug and Play for Non-Operator Owned
Backhaul feature activation flag has been enabled.
Description
• The BTS is powered up.
DN181051332 Issue: 01 © 2018 Nokia 41

• The BTS is assigned an IP address by the public/enterprise DHCP server, which also
provides the public/enterprise DNS server's address(es).
• The BTS acquires the IP address of the initial SeGW (pre-configured on the BTS)
through the public/enterprise DNS server. (This step is not required if the IP address
of the initial SeGW is pre-configured on the BTS).
• The BTS establishes the IPSec tunnel to the initial SeGW using the vendor certificate
as well as the root CA.
• The inner IP addresses are obtained from the SeGW. Depending on the MPlane
IP Address Preference parameter value, the obtained IP addresses will be
either IPv4 or IPv6.
• The BTS acquires the IP address of the certificate authority server by resolving the
FQDN of the certificate authority server (pre-configured on the BTS) through the
private DNS server. (This step is not required if the IP address of the certificate
authority server is pre-configured on the BTS).
• The BTS performs the certificate enrollment and gets the operator's certificate from
the CA-server.
• The BTS tears down the initial IPSec tunnel created using the vendor's certificate.
• The BTS acquires the IP address of the serving SeGW by resolving the FQDN of the
SeGW (pre-configured on the BTS) through the public/enterprise DNS server. (This
step is not required if the IP address of the serving SeGW is pre-configured on the
BTS)
• The BTS establishes the IPSec tunnel to the serving SeGW using the operator
certificate obtained from the CA-server.
• The BTS acquires the IP address of the initial OMS by resolving the FQDN of the
OMS (pre-configured on the BTS) through the private DNS server. (This step is not
required if the IP address of the initial OMS is pre-configured on the BTS).
• The BTS establishes a connection to the initial OMS.
• The identification server on the initial OMS identifies the BTS based on the
identification parameters (HW serial number or GPS coordinates) and provides the
final OMS address from where the BTS acquires the software and configuration data
as part of the auto-configuration.
Post-condition
Once the auto-connection to the initial OMS is established, it is followed by the auto-
configuration procedure.
Exceptions
• If the FZ BTS does not receive the IP address after a suitable amount of time, it will
retry auto-connection.
• If MPlane IP Address Preference is not pre-configured, then NE requests an
IPv4 inner IP address from the SeGW.
• If the FQDN of the primary OMS does not resolve to IP Address Type of the inner IP
address provided by the serving SeGW, then the auto-connection procedure is
terminated and retried.
Use case 2: Plug and play deployment of FZ BTS in non-operator owned backhaul
network when CA server resides in public network
42 © 2018 Nokia DN181051332 Issue: 01

Figure 7 Deployment Scenario 2: CA-server accessible via the public network
DHCP DNS CA
enterprise operator
network network
DHCP DNS
FlexiZoneBTS
enterprise
transport Serving
network security
gateway
operator
transport
network
RNC/OMS NetAct
FlexiZoneBTS
public
DHCP DNS
network
Pre-conditions
• The BTS is physically installed in a non-operator owned backhaul network.
• The BTS is pre-configured with the following "minimum" operator-specific transport
information:
– The subject name of the CA-server
– The FQDN or the IP address of the primary initial OMS
– The MPlane IP Address Preference parameter is set to IPv4
• If the FQDNs need to be resolved, the corresponding IP address(es) at the DNS
server(s) are specified.
• The BTS is pre-loaded with the WBTSZ17 1.0 or newer software.
• The OMS is pre-configured with the HW serial number and/or GPS coordinates for
the BTS identification.
• The RAN3379 Enhanced Flexi Zone Plug and Play for Non-Operator Owned
Backhaul feature activation flag has been enabled.
Description
• The BTS is powered up.
• The BTS is assigned an IP address by the public/enterprise DHCP server, which also
provides the DNS server's address(es).
DN181051332 Issue: 01 © 2018 Nokia 43

• The BTS acquires the IP address of the certificate authority server by resolving the
FQDN of the certificate authority server (pre-configured on the BTS) through the
public/enterprise DNS server. (This step is not required if the IP address of the
certificate authority server is pre-configured on the BTS.)
• The BTS performs the certificate enrollment and gets the operator certificate from the
CA-server.
• The BTS acquires the IP address of the serving SeGW by resolving the FQDN of the
SeGW (pre-configured on the BTS) through the public/enterprise DNS server. (This
step is not required if the IP address of the SeGW is pre-configured on the BTS).
• The BTS creates the IPSec tunnel with the serving SeGW using the operator
certificate obtained from the CA-server.
• The BTS acquires the IP address of the initial OMS by resolving the FQDN of the
OMS (pre-configured on the BTS) through the private DNS server. (This step is not
required if the IP address of the initial OMS is pre-configured on the BTS.)
• The BTS establishes a connection to the initial OMS.
• The identification server on the initial OMS identifies the BTS based on the
identification parameters (HW serial # or GPS coordinates) and provides the final
OMS address from where the BTS acquires the software and configuration data as
part of the auto-configuration.
Post-condition
Once the auto-connection to the initial OMS is established, it is followed by the auto-
Use case 3: Creation / Modification of auto-connection parameters for non-

operator owned (untrusted) backhaul
Pre-conditions
• The Network Element Manager is connected to the BTS.
• The BTS is in an uncommissioned state.
Description
• The operator uses the Network Element Manager to launch the auto-connection user
interface for the non-operator owned (untrusted) backhaul.
• The operator modifies some or all of the auto-connection parameters for the non-
operator owned (untrusted) backhaul.
• If the auto-connection parameters for the non-operator owned (untrusted) backhaul
are not configured on the BTS, the information provided using the Network Element
Manager is used to create the configuration file on the BTS. The Network Element
Manager has to ensure that all the mandatory information is specified in this case. It
includes the following:
– The subject name for the CA-server
44 © 2018 Nokia DN181051332 Issue: 01

• If the auto-connection parameters for the non-operator owned (untrusted) backhaul
are already configured on the BTS, the information provided using the Network
Element Manager is used to modify the configuration file on the BTS. The Network
Element Manager has to ensure that once the modification is done, at least the
following set of information is present:
– The subject name of the CA-server
Post-conditions
The BTS has updated the auto-connection parameters for the non-operator owned
(untrusted) backhaul as specified by the operator using the Network Element Manager.
g Note:
• The operator is not required to populate IP addressing and VLAN identifiers into the
IEIF/IVIF objects in a public backhaul deployment.
• When configuring a site where dynamic IP or public backhaul is deployed, users
can optionally populate the local IP address and netmask of the Ethernet Interface
configuration (IEIF) for parameter validation purposes. These parameters will be
overwritten by the FZM with the values discovered via DHCP. It is recommended
that users not populate VLAN Interface (IVIF) attributes, including local IP address
and netmask of the IVIF configuration. In these deployment scenarios, the FZM will
discover whether the Ethernet interface is untagged or VLAN tagged and will use
the operator-configured values in IEIF’s QoS and shaper values for the VLAN
interface.
g Note: (Applicable to all Use Cases)
If the BTS is uncommissioned and deployed for public backhaul in the LTE3267
deployment, then the BTS will override the MTU value provided by the DHCP server if it
is received with a value less than 1500 bytes. In that case, the BTS will instead use an
MTU value of 1500 bytes. This helps to override network mis-configurations of MTU
values which have been observed in operator/public environments, since the minimum
MTU value for IPv6 is 1280 bytes. Once the BTS is commissioned, the setting of the
MTU value will be determined by the setting of the overrideMTUSize attribute.
System impact
The following features impact RAN3379: Enhanced Flexi Zone Plug and Play for Non-
Operator Owned Backhaul:
• LTE2182: Enhanced Flexi Zone Plug & Play for Non-Operator Owned Backhaul
The LTE2182: Enhanced Flexi Zone Plug & Play for Non-Operator Owned Backhaul
feature provides similar functionality for LTE-based Flexi Zone small cells as feature
RAN3379. Feature RAN3379 is based upon LTE2182.
Impact on interfaces
DN181051332 Issue: 01 © 2018 Nokia 45

The RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator Owned Backhaul
feature has no impact on interfaces.
Impact on network management tools

The feature impacts network management tools as follows:
• The Network Element Manager is required to provide the functionality to overwrite
the auto-connection information configured at the factory. This requires the ability to
deliver the auto-connection parameters from the Network Element Manager to the
BTS, which is overwriting the factory-configured information.
Impact on system performance and capacity

This feature has no impact on system performance or capacity.
3.1 RAN3379 reference data

RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator Owned Backhaul
requirements, parameters, and sales information
Requirements
Table 8 RAN3379 hardware and software requirements
System release WCDMAFZ 17 SP1
IPA-RNC Support not required
mcRNC Support not required
Flexi Multiradio BTS Support not required
Flexi Multiradio 10 BTS Support not required
Flexi Lite BTS Support not required
Flexi Zone WCDMA BTS WBTSZ17 1.0 (FZ Pico and FZ Micro)
OMS Support not required
NetAct NetAct17.2 SP06
MSC Support not required
SGSN Support not required
MGW Support not required
UE Support not required
Additional hardware requirements

This feature supports the Flexi Zone Micro, Indoor Pico BTSs.
Alarms
There are no alarms related to the RAN3379: Enhanced Flexi Zone Plug and Play for
Non-Operator Owned Backhaul feature.
BTS faults and reported alarms
46 © 2018 Nokia DN181051332 Issue: 01

There are no faults related to the RAN3379: Enhanced Flexi Zone Plug and Play for

Non-Operator Owned Backhaul feature.
Commands
There are no commands related to the RAN3379: Enhanced Flexi Zone Plug and Play
for Non-Operator Owned Backhaul feature.

There are no measurements or counters related to the RAN3379: Enhanced Flexi Zone
Plug and Play for Non-Operator Owned Backhaul feature.

There are no key performance indicators related to the RAN3379: Enhanced Flexi Zone
Plug and Play for Non-Operator Owned Backhaul feature.
Parameters
Table 9 Existing parameters related to RAN3379
Full name Abbreviated name Managed Parent structure
object
Activate Autoconnection actACNonOpBackhau IPNO -
in Non-Operator Owned l
Network
Sales information
Table 10 RAN3379 sales information
Basic Software (BSW) - No
3.2 Activating and configuring RAN3379: Enhanced

Flexi Zone Plug and Play for Non-Operator Owned
Backhaul
Instructions to activate and configure the RAN3379: Enhanced Flexi Zone Plug and Play
for Non-Operator Owned Backhaul
Before you start
– The BTS will automatically reboot after activation of this feature as part of the
Plug and Play procedure.
• Site Commissioning File (SCF)
DN181051332 Issue: 01 © 2018 Nokia 47

– The site configuration must be prepared prior to feature activation. See the
document NetAct Creating and Rolling out LTE BTS Sites, DN0969763, Section
1.2.3, "Creating BTS site configuration file using Workflow Engine", for
instructions on creating the SCF.
• BTS load
– NetAct must have a load available for the FZ BTS which is capable of
supportingRAN3379.
Table 11 Parameters used for activating and configuring RAN3379: Enhanced Flexi

Zone Plug and Play for Non-Operator Owned Backhaul
Parameter Purpose Requires BTS restart or
object locking
Activate Autoconnection in Non- Activation flag Yes
Operator Owned Network
(actACNonOpBackhaul)
The Activate Autoconnection in Non-Operator Owned

Network (actACNonOpBackhaul) parameter is used for activation. The BTS will
reboot after downloading the software/configuration file during the Plug and Play
procedure.
Procedure
1 Follow the general procedure described in section Activating and deactivating LTE

features using BTS Site Manager.
• See the "Before you begin" section for all the feature flags that need to be
activated.
• The operator can use NetAct instead of BTS Site Manager to activate the
feature.
• If the Public Backhaul parameters are pre-provisioned in the factory, this
activation procedure is completed after completion of Step 1.
2 If the Public Backhaul parameters are not pre-provisioned in the factory, start the BTS
Site Manager application and establish the connection to the BTS.
The Autoconfiguration window pops up automatically.
48 © 2018 Nokia DN181051332 Issue: 01

3 If the Public Backhaul parameters are not pre-provisioned in the factory, start
provisioning.
Sub-steps
a) In the Autoconfiguration window, select ► Enter parameters for non-

operator owned backhaul
The Autoconfiguration window will pop up after connecting to the BTS Site
Manager. If the window is closed or is not visible, it can also be accessed it by
selecting Configuration ► Autoconfiguration located at the top-right side of
the BTS Site Manager.
b) Enter the required parameters and, if needed, the optional parameters.
• Set the MPlane IP address preference parameter to IPv4 for

RAN3379 activation.
• Enter remaining required fields or select a file from Import from file.
• Optional: Enter non-required fields.
c) Press Send
d) Optional: If the CMP is in a private domain, the Trust Anchor certificate must be
installed.
• Proceed to the Autoconfiguration window. If the Autoconfiguration
window is not visible, it can be accessed by selecting Configuration ►
Autoconfiguration, located at the top-right side of the BTS Site Manager. It
can also be accessed by selecting Configuration ► Enter parameters for
Non-operator Owned Backhaul.
• From the Enter Parameters for Non-operator Owned Backhaul window,
select ► Certificate Management.
• In the Certificate Management window, BTS certificates tab, go to ►
Additional CA certificates and select ► Browse CA Certificate.
• Install the Trust Anchor certificates, then select ► Open.
• Press Send.
After performing these steps, closing the Certificate Management window will
provide a clear view of the Autoconnection window.
e) Monitor the progress of the autoconnection procedure on the Autoconfiguration
window.
Autoconnection is complete when the connection to the iOMS is established.
Expected outcome
The BTS is commissioned using a public BH environment.
DN181051332 Issue: 01 © 2018 Nokia 49

3.3 Deactivating RAN3379: Enhanced Flexi Zone Plug

and Play for Non-Operator Owned Backhaul
Deactivation of the RAN3379: Enhanced Flexi Zone Plug and Play for Non-Operator
Owned Backhaul .
Before you start
• Procedure notifications:
– Deactivation procedure does require restart - a configuration reset along with
clearing of the non-operator owned public backhaul parameters is required to
deactivate this feature.
• Preconfiguration:
– The RAN3379 (public backhaul) feature is activated (Activate
Autoconnection in Non-Operator Owned Network).
g Note: The Non-operator owned backhaul parameters field is used for deactivation.

Modification of this field requires BTS restart.
Procedure
1 Follow the general procedure described in section Activating and deactivating LTE

features using BTS Site Manager.
3 Deactivate the Activate Autoconnection in Non-Operator Owned

Network parameter.
4 Reset the configuration.
Sub-steps
a) From the Configuration tab select ► Configuration Reset.
b) Select Security credentials.
c) Select Non-operator owned backhaul parameters and ► Reset.
50 © 2018 Nokia DN181051332 Issue: 01

5 Start commissioning. Select View ► Commissioning or click Commissioning on the View
Bar on the left.
This it to recommission the BTS for operator-owned backhaul deployment.
6 Send the parameters to the BTS according to the procedure described in section
Activating and deactivating LTE features using BTS Site Manager.
Expected outcome
The autoconnection in non-operator owned network functionality is disabled. The BTS
can no longer be commissioned using a public BH environment.
DN181051332 Issue: 01 © 2018 Nokia 51

LTE2487: Support for Distributed PKI Systems LTE17A Operability Features
4 LTE2487: Support for Distributed PKI

Systems
The LTE2487: Support for Distributed PKI Systems feature enhances the certificates
management system by introducing:
• Possibility to configure registration authority (RA) and certification authority (CA) on
separate servers
• Possibility to configure secondary RA and CA servers
• Asynchronous interface (API) used by RA and CA servers

The LTE2487: Support for Distributed PKI Systems feature significantly increases the
PKI robustness, due to:
• Redundancy of the certificate management protocol (CMP)
• Minimization of the number of certificate management messages

PKI basics
A public key infrastructure (PKI) enables managing digital certificates, which confirm the
identity of certificate applicant and bind that identity to the public key contained in the
certificate. A typical PKI includes the following key elements:
• A trusted party, called a certification authority (CA), which acts as the root of trust
and provides X.509 certificates to applicatns that authenticate the identity of
individuals, computers, and other entities
• A registration authority (RA), which verifies the identity of an applicant before a
certificate signing or update request is forwarded to the CA
• A certificate database, which stores certificate requests, issues, and revokes
The certificate management protocol (CMPv2) is the protocol used to communicate
between applicant, RA and CA.
Distributed PKI
Prior to the LTE2487: Support for Distributed PKI Systems feature, the eNB supported
only one CA/RA server destination. This means that in case of a server failure, the whole
PKI system stops working. With LTE2487, it is possible to configure two separate
destinations, and create primary and secondary RA/CA servers. This solution enables an
automated fallback from a primary to a secondary PKI system, for example, in case of a
failure or prolonged maintenance break in one of the PKI systems. The supported
configuration options are:
• Co-located CA and RA servers (legacy configuration)
• Separate RA and CA servers, without redundancy
52 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE2487: Support for Distributed PKI Systems
• Separate RA and CA servers, with secondary servers configured
Configuration of the secondary CMP is performed using the following parameters:
• CMP Directory(cmpDirectory)
• Secondary CMP Directory(secCmpDirectory)
• Secondary CMP server IP address(secCmpServerIpAddress)
• Secondary CMP server subject name(secCaSubjectName)
• Secondary CMP server port number(secCmpServerPort)
• CMP Polling Timeout(cmpPollingTimeout)
It is possible to perform a mass configuration of eNBs using the NetAct CERMA tool.
When the eNB initiates a Certificate Initialization Request or Certificate Update Request,
it sends the CMP message first to the primary CMP front-end IP address (which could be
either an RA or CA). If the primary server does not respond, the eNB tries the secondary
CMP front-end IP address. If both front-end servers do not respond, the eNB raises an
alarm and repeats the request starting with the primary one again until one of the CMP
front-end servers answers. The eNB clears the alarm when one of the servers responds.
Support for asynchronous API (CMP waiting/ pooling)

Prior to the LTE2587: Support for Distributed PKI Systems feature, the eNB supported
only a synchronous API with the CMP servers. In some scenarios, this caused the
flooding of the RA/CA server with repeated messages and, as a result, CA service
degradation and PKI outages. With LTE2587, the eNB supports both synchronous and
asynchronous API with the CMP servers, which solves this problem. The BTS supports
CMP waiting indication received from the RA or CA. If waiting indication is received the
BTS regularly polls the RA or CA if the requested certificate is ready for download.
An example of synchronous and asynchronous API is shown in the figure below.
DN181051332 Issue: 01 © 2018 Nokia 53

Figure 8 Certificate enrollment using synchronous and asynchronous API
SYNCHRONOUS ASYNCHRONOUS
CERTIFICATEENROLLMENT CERTIFICATEENROLLMENT
eNB RA/CA eNB RA/CA
server server
CMPir CMPir/kur
CMPipstatus=accepted CMPip/kupstatus=waiting
CMPpoolReq
*
CMPcertconf
CMPpoolReq
checkAfter<time>
CMPpkiconf
CMPpoolReq
CMPip/kupstatus=accepted
* If cmpPollingTimeoutexpiredduring CMPcertconf
poolingwithoutsuccessfulCMPip/kur
response,thefailureisloggedandalarm
isgenerated. CMPpkiconf
4.2.1 Lifecycle management of operator certificate in eNB/SBTS

The figure below explains the lifecycle management of operator certificate from release
LTE17A onwards.
The lifecycle of certificate consists of three phases: enrollment, update, and revocation.
As a result, the certificate in the network element is always up-to-date.
54 © 2018 Nokia DN181051332 Issue: 01

Figure 9 Lifecycle management of operator certificate in eNB/SBTS (LTE17A)
ENROLLMENT REVOCATION certificate
nocertificate
compromized
certificate certificateadded
deployment toCRL
needed
networkelement
deployment downloadsCRL
automaticCMP automatically
initialization method
withvendor CMP FILE
certificates manual ALARM certificatein
triggerCMPinitialization YES
ifCMPIP/port deployment certificate owntrustchain
fromCLIor
isconfigured revoked compromised?
NetAct
NO
networkelement
performsCMP
initialization
CMP operatorcertificates
successfulwithprimary YES
areuptodateinNE
server
NO
ALARM
CMP YES
certificate NO
retrieval successfulwithsecondary CMP CMP
NO
server successfulwithprimary successfulwithsecondary
failure
server server
NO Operator
UPDATE NEperformsCMPKey ALARM
PKI
updateautomatically certificate
forNEcertificate doesnot Operatorroot
exist certificate
OperatorNEcertificateor
OperatorNEcertificate Operator
intermediateCA
orintermediateCA intermediateCA
certificate
certificateexpired certificate
closetoexpiry
ALARM
Operatorrootcertificate/ Operator
certificate
NEowntrustchainroot NEcertificate
expired
Alltrust closetoexpiry
anchorsexpired Operatoroldroot
Othercertificates certificate,2ndroot
closetoexpiry certificate,cross-signed
certificates
NE-networkelement(eNB/BTS),CRL-CertificateRevocationList,CMP-CetificateManagementProtocol

LTE2487: Support for Distributed PKI Systems feature has no impact on features,
interfaces, network management tools, and system performance and capacity.

Requirements
DN181051332 Issue: 01 © 2018 Nokia 55

FDD TDD
OMS OMS17 OMS17
NetAct 17.2 17.2

There are no measurements or counters related to the LTE2487: Support for Distributed
PKI Systems feature.

There are no key performance indicators related to the LTE2487: Support for Distributed
PKI Systems feature.
Parameters
d object
CMP Directory cmpDirectory CERTH - common
Secondary CMP secCmpDirector CERTH - common
Directory y
Secondary CMP secCmpServerIp CERTH - common
server IP address Address
Secondary CMP secCaSubjectNa CERTH - common
server subject name me
Secondary CMP secCmpServerPo CERTH - common
server port number rt
CMP Polling Timeout cmpPollingTime CERTH - common
out
For parameter descriptions, see LTE Operating Documentation/Reference
Sales information
56 © 2018 Nokia DN181051332 Issue: 01

Application software (ASW) Pool licence No
4.5 Configuring secondary CMP server

The LTE2487: Support for Distributed PKI server feature enables the configuraiton of a
secondary CMP server.
Before you start

Activation procedure does not cause downtime, and the feature can be activated at any
time of the day.
Procedure
Sub-steps
left.
state of the BTS.
3 Proceed to the Security page.
g Note: The Security page can also be reached without starting the commissioning, on
the left-hand side of BTS SM in the IP menu
4 Go to the Certificate management object.
5 Set the secondary CMP/CA server parameters to the correct values.
The parameters which can be configured are:
• Secondary CMP server IP address(secCmpServerIpAddress)
DN181051332 Issue: 01 © 2018 Nokia 57

• Secondary CMP server port number(secCmpServerPort)

• Secondary CMP directory(secCmpDirectory)
• Secondary CMP server subject name(secCaSubjectName)
• CMP Polling Timeout(cmpPollingTimeout)
Step example
g Note: Screenshot taken from LTE17A release.
Sub-steps
Result
The secondary CMP server is configured, and will be used by eNB in case of a primary
server failure.
58 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade
5 RAN3382: Flexi Zone BTS WCDMA to LTE

Upgrade
Table 15 Summary of changes
Date of change Section Change description
7.11.2017 Functional Information on Remote Upgrade Flexi Zone BTS from
description WCDMA to LTE procedure was changed.
The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature introduces an end to

end process to perform a remote upgrade of a WCDMA Flexi Zone Small Cell to LTE.
This feature covers the WCDMA part of the upgrade process and includes all associated
software changes.
5.1 RAN3382 benefits

The RAN3382: Flexi Zone BTS WCDMA to LTE upgrade feature provides the following
benefits:
• allows the WCDMA Flexi Zone Small Cell to be remotely upgraded to LTE
• allows operators to leverage installed hardware base, and provide best in class
service
5.2 RAN3382 functional description

The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature provides the software
upgrade of Flexi Zone 3G from WCDMA WBTSZ17 onwards to FDD LTE17A, including:
• Remote upgrade by NetAct SW Manager for BTS.
– Software upgrade of a network element, triggered by the user from NetAct
Software Manager.
• Local upgrade by Network Element Manager for BTS.
– Software upgrade of a network element, triggered by the user from the local
network element user interface.
• Rollback from FLF17A to WCDMA WBTSZ17, if needed.
– Manually return to previous SW version for node element, if a new SW version
does not work as expected.
• Fallback from FLF17A to WCDMA WBTSZ17, if needed.
– Automatic activation of an older/passive SW version that is stored on the node
element, and has been active before last SW upgrade/update was triggered.
DN181051332 Issue: 01 © 2018 Nokia 59

RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade LTE17A Operability Features
g Note: Fallback/rollback to WCDMA to restore service will be handled by LTE SW. LTE
side is covered by the LTE2641 feature.
Figure 10 Software upgrade provided by the RAN3382 feature

Localupgrade byNetworkElementManager
Remoteupgrade byNetActSWManager
FlexiZone FlexiZone
BTS BTS
Rollback
WCDMA LTE
Fallback
Features of the upgrade mechanism are as follows:
• All the necessary data conversion procedures and tools are provided to ensure a
smooth and reduced downtime for the Network Elements.
• Any transport and firewall changes are assumed to be completed by the operator
and/or enterprise, and excluded from the scope of this feature.
The scope is defined only for Flexi Zone 3G BTS, including both Indoor Pico and
Outdoor Micro variant:
• Indoor: FWGL, FWGM, FWGN, FWFE, FWFF, FWFG, FWFI.
• Outdoor: FWFJ, FWGP.
• Future HW variant that supports both WCDMA and LTE SW.
The remote upgrade capability assumes that no layer 1 physical cabling changes are
required, and that the unit will not be physically relocated with the migration from
WCDMA to LTE. The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature
provides support for the migration to a stand-alone small cell with an S1 connection for
the EPC. This feature excludes a conversion of the WCDMA configuration file to an LTE
compatible configuration file. The generation of the LTE configuration file is conducted
via existing means, such as Automated Site Creation (ASC).
Local upgrade Flexi Zone BTS from WCDMA to LTE via Network Element Manager
Upgrade Function
Preconditions:
• Network Element Manager is connected with BTS, WCDMA SW is running on Flexi
Zone BTS.
The following steps are executed:
1. Operator logs on to a WCDMA version of Network Element Manager, chooses an LTE
package via Network Element Manager upgrade function, downloads and activates
(optional) as normal SW upgrade procedure.
2. WCDMA BTS SW reads targetBD.xml file, which is included in LTE package, next
downloads files to passive partition as normal SW download procedure.
60 © 2018 Nokia DN181051332 Issue: 01

3. LTE SW is activated as normal SW activation procedure.
g Note: In case the LTE activation fails, BTS will automatically fallback to WCDMA SW.
4. BTS reset.
5. BTS startup with LTE SW running, BTS is in decommission state.
6. Operator installs LTE version of the Network Element Manager.
7. Operator logs on to Network Element Manager, configurates BTS as normal LTE
8. BTS is on air, if all configuration data in step 7 are valid.
9. (Optional) Operator logs on to Network Element Manager, rollbacks BTS to WCDMA
SW via rollback button on the LTE version of Network Element Manager.
g Note: In case another SW download/upgrade procedure is executed after LTE SW
running, rollback to WCDMA SW will fail.
Post-conditions:
• LTE SW is running on Flexi Zone BTS. BTS/eNB can be configured via normal LTE
Remote Upgrade Flexi Zone BTS from WCDMA to LTE via NetAct Upgrade
Function
Preconditions:
• WCDMA certificates are valid for the LTE.
• NetAct of WCDMA can store, download, and activate LTE SW load.
• WCDMA SW is running on Flexi Zone BTS, and BTS is managed by WCDMA
NetAct.
• (Required only if BTS is in enterprise or public network) WCDMA SW is running with
valid non-operator owned backhaul file.
• Operator uses the Auto Connection infrastructure in LTE.
The following steps are executed:
1. Operator/Commissioner makes LTE SW load available on WCDMA version NetAct.
2. Operator downloads LTE SW load to affected BTS using NetAct SW Management.
3. Operator blocks affected BTS.
g Note: This is required to make sure that upgrade is not disturbed by any automatic
recovery actions occurring in WCDMA.
4. If BTS is in enterprise or public network, operator modifies PREBTS in WCDMA initial
OMS from WCDMA configuration to LTE configuration (including AutoConnHWID or
AutoConnSiteID, BTSID, finalMediatorIPAddress, technologyInformation, and version)
via NetAct CM Editor & CM Operation Manager.
g Note: AutoConnHWID in WCDMA configuration can be either register SN or label SN.
In LTE configuration, only label SN is used.
5. Operator activates LTE SW using NetAct SW Management.
DN181051332 Issue: 01 © 2018 Nokia 61

g Note: In case the LTE SW activation fails, BTS will fallback to WCDMA SW. If fallback
occurred and WCDMA commission lost with exception, operator needs to change
PREBTS in step 4 back to WCDMA configuration via NetAct.
6. On activation, eNB detects that it has no valid configuration data. LTE SW ignores
WCDMA configuration file.
7. The eNB performs the existing LTE Auto Connection procedure, with vendor specific
information provided by DHCP server if BTS is in operator-owned network, or with the
configuration manually entered by the operator in step 4 if BTS is in enterprise or public
network.
g Note: Restrictions for the upgrade from 3G to 4G in enterprise/public network:
• After BTS is upgraded from 3G to 4G in public network, a site visit is needed if BTS
fallback/rollback from 4G to 3G again.
• The purpose of the site visit is to reconfigure the IP addresses of several WCDMA
network elements (OMS, Security Gateway, and CA server) via Network Element
Manager. This configuration is necessary to make BTS setup connection with OMS
in public network.
• Later feature will eliminate the site-visit under this scenario (3G upgrade to 4G, then
coming back to 3G again in public backhaul), by preserving IP addresses of
WCDMA network elements.
8. After connection with LTE NetAct via OMS has been established, eNB can be
commissioned manually (by file downloaded from LTE NetAct/Remote Network Element
Manager), or using the Auto Configuration feature.
g Note: Note that Auto Configuration includes SW download, which means that eNB SW
will be downloaded one more time. In case proper SW is not available for download, the
Auto Configuration procedure will fail.
9. (Optional) If needed, operator logs on to NetAct, rollbacks BTS to WCDMA SW via
rollback function on NetAct and change PREBTS in step 4 back to WCDMA
configuration.
10. (Optional) If needed, operator can manually delete WCDMA BTS data from WCDMA
RNC/OMS/NetAct via existing removal procedure.
Post-conditions:
• LTE SW is running on Flexi Zone BTS. The eNB is managed by LTE NetAct and go
on air if all LTE configuration data are valid.
g Note: After running upgrade procedure, as a result of the BTS maintaining only via
Network Element Manager, the Flexi Zone BTS is not integrated to NetAct via OMS
anymore. Operator has to manually switch from OMS (WCDMA) to iOMS (LTE) for
every single upgraded BTS. After the upgrade, the operator also has to remove every
single BTS configuration from RNC.
5.3 RAN3382 system impact

62 © 2018 Nokia DN181051332 Issue: 01

The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature is impacted by the

following features:
• RAN3217: 3G Flexi Zone Pico Indoor BTS
The RAN3217: 3G Flexi Zone Pico Indoor BTS feature introduces a small indoor
BTS, which reuses macro BTS SW enabling support for relevant macro features.
• RAN3349: FWFJ FZ BTS 2T2R 1900 3G/4G
The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature reuses the FWFJ
BTS hardware variant introduced in the RAN3349: FWFJ FZ BTS 2T2R 1900 3G/4G
feature.
• RAN3395: FWGP FZ BTS 2T2R 2100 3G/4G
The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature reuses the FWGP
BTS hardware variant introduced in the RAN3395: FWGP FZ BTS 2T2R 2100 3G/4G
feature.
The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature has no impact on
interfaces.

The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature impacts network
management tools as follows:
• Network Element Manager:
– allows to upgrade the BTS if NetAct upgrade tools cannot be used
• NetAct Software Manager:
– allows to upgrade the BTS easily from one place

The RAN3382: Flexi Zone BTS WCDMA to LTE Upgrade feature has no impact on
system performance or capacity.

Requirements
Table 16 RAN3382 hardware and software requirements
System release WCDMAFZ17
IPA-RNC Not supported
mcRNC Not supported
Flexi Multiradio BTS Not supported
Flexi Multiradio 10 BTS Not supported
Flexi Lite BTS Not supported
Flexi Zone WCDMA BTS WBTSZ17 1.0
DN181051332 Issue: 01 © 2018 Nokia 63

Table 16 RAN3382 hardware and software requirements (Cont.)
OMS Not supported
NetAct Not supported
MSC Not supported
SGSN Not supported
MGW Not supported
UE Not supported
Sales information
Table 17 sales information
64 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE2734: Flexi Zone Discovery Mode Neighbor
Information Exchange
6 LTE2734: Flexi Zone Discovery Mode

Neighbor Information Exchange
The LTE2734: Flexi Zone Discovery Mode Neighbor Information Exchange feature
enhances the exchange of neighbor cells information with neighboring eNBs via
standard X2 messaging. The neighbor information is used to prevent physical cell ID
(PCI) confusion and packet random access channel (PRACH) collision. The information
is used to optimize the PCI value and PRACH configuration locally at the small cell.

reduces the time and complexity of deploying and operating small cells by enhancing the
Flexi Zone centralized ZSON solution to support optimization of PCI confusion and
PRACH collision locally at the small cell.

Overview
The LTE1769: X2 Neighbor Information Exchange feature makes the neighbor
information of all cells of neighboring eNBs (neighbor’s neighbor) available.
The LTE2734 feature brings distributed SON functionality for the physical cell ID (PCI) to
the Flexi Zone small cells in both the stand-alone and controller-based deployments. The
feature supports both the discovery mode for the initialization of the small cell as well as
a normal operating mode.
The LTE1997: Discovery Mode Self Configuration for Flexi Zone AP feature algorithms
running on a small cell eNB already use PCI and PRACH information of all of its own
cells and the PCI information of all neighbors of all its own cells. Till now, the PCI
information of the neighbors of neighboring eNB has not been available to these
LTE1997 feature algorithms. The LTE2734 feature introduces the following new
functions:
• Pass the available neighbor information of all cells of neighboring eNBs to ZSON
whenever neighbor information is received from a neighboring eNB.
• Pass the packet random access channel (PRACH) of all cells of neighboring eNBs to
ZSON whenever PRACH is received from a neighboring eNB.
• Store the newly available PRACH information in the object model. This new
information is used by LTE2613: Plug & Play On Demand for Flexi Zone AP.
• Periodically forward the copy of X2:HANDOVER REQUEST ACKNOWLEDGE
message from the target eNB through source eNB transparent container to ZSON.
• ZSON uses the target to source container to extract PRACH information and store it
in the object model. This new information is used by LTE2613: Plug & Play On
Demand for Flexi Zone AP.
Neighbor list
The eNB is able to make use of neighbor information if it should be received from other
vendor eNBs during the X2 setup.
DN181051332 Issue: 01 © 2018 Nokia 65

LTE2734: Flexi Zone Discovery Mode Neighbor LTE17A Operability Features
The neighbor list includes information about all neighbor relations (LNREL) with statuses
available and invalid (invalid to allow neighbor BTS to detect possible PCI confusions).
Nokia-micro-eNB-specific information:
The neighbor information is not exchanged during the X2 setup request/response but
only in the X2 configuration update sent immediately after the X2 setup. Upon receiving
an X2 setup (request/response) or an eNB configuration update (request), the neighbor's
served/neighbor cell PCI is utilized by the micro eNB for PCI optimization.
The small cell also periodically uses incoming handover messages to identify neighbor
cell's PRACH and cell type. A configurable time-based window is supported when PCI
updates can be executed. This detection occurs at any time, but updates are limited to
an operator-specified maintenance window.

The following features have to be configured before activating the LTE2734: Flexi Zone
Discovery Mode Neighbor Information Exchange feature:
• LTE1769: X2 Neighbor Information Exchange
The LTE2734 feature is dependent on the LTE1769 feature. The LTE1769 feature
enables sending and receiving neighbor information via X2.
g Note: In order to use the LTE2734 feature, Nokia macro-eNBs have to provide
neighbor information to FZM. The following configuration is recommended:
– in FZM:
x2NbInfoTransMode=always
– in macro-eNB:
x2NbInfoTransMode=onDemand
• LTE1997: Discovery Mode Self Configuration for Flexi Zone AP

The LTE2734 feature is dependent on the LTE1997 feature. The LTE1997 feature
uses the neighbor information to optimize PCI of the receiving eNB.

impacts the following features:
• LTE2613: Plug & Play On Demand for Flexi Zone AP
The LTE2613 feature uses the PRACH information received in the X2 SETUP
REQUEST, X2 SETUP RESPONSE, ENB CONFIGURATION UPDATE messages
or extracted from the target eNB to the source eNB transparent container IE of the
X2 HANDOVER REQUEST ACKNOWLEDGE message.
The transmission of neighbor information might lead to a high performance load on X2
interfaces. To avoid this, the LTE2734 feature introduces mechanisms which limit the
maximum message size per X2 eNB configuration update. They also prevent the
occurrence of bursts of configuration update messages in the network.
66 © 2018 Nokia DN181051332 Issue: 01


The LTE2734: Flexi Zone Discovery Mode Neighbor Information Exchange feature has
no impact on network management tools.

The LTE2734: Flexi Zone Discovery Mode Neighbor Information Exchange feature has
no impact on system performance or capacity.

Requirements
FDD TDD
Flexi Multiradio 10 BTS Not supported Not supported
Flexi Multiradio 10 Indoor BTS Not supported Not supported
Nokia AirScale BTS Not supported Not supported
Flexi Zone BTS FL17A TL17A
Flexi Zone Access Point FL17A TL17A
Cloud Flexi Zone Controller FL17A TL17A
OMS Not applicable Not applicable
NetAct Eden-Net Eden-Net
MME Not applicable Not applicable
SAE GW Not applicable Not applicable
UE Not applicable Not applicable
Parameters
Full name Abbreviated name Managed Parent FDD/TDD
object structure
PRACH Configuration prachConfigura LNADJL - common
Resources of Served tion
Cell by Neighbor
eNB
PRACH Configuration prachConfIndex LNADJL prachConfigura common
Index of Served tion
Cell by Neighbor
eNB
PRACH cyclic shift prachCS LNADJL prachConfigura common
of Served Cell by tion
Neighbor eNB
DN181051332 Issue: 01 © 2018 Nokia 67

object structure
PRACH High Speed prachHsFlag LNADJL prachConfigura common
Flag of Served Cell tion
by Neighbor eNB
PRACH Frequency prachFreqOff LNADJL prachConfigura common
Offset of Served tion
Cell by Neighbor
eNB
Root Sequence Index rootSeqIndex LNADJL prachConfigura common
of Served Cell by tion
Neighbor eNB
Source of PRACH sourceOfPrachD LNADJL prachConfigura common
Configuration Data ata tion
of Served Cell by
Neighbor eNB
For parameter descriptions, see Flexi Multiradio BTS LTE Commissioning, RNW and

Transmission Parameters.
Sales information
Application software (ASW) - No
6.5 Activating LTE2734

Instructions to activate the LTE2734: Flexi Zone Discovery Mode Neighbor Information
Exchange.
Before you start

• procedure notifications
– PCI optimization of neighbor eNBs running in parallel requires extended time for
convergence of PCI values within each eNB. Therefore it is recommended to
activate LTE2734 on neighboring eNBs one after the other.
• feature interdependencies
The following features have to be configured before activating the LTE2734: Flexi
Zone Discovery Mode Neighbor Information Exchange feature:
– LTE1769: X2 Neighbor Information Exchange
The LTE2734 feature is dependent on the LTE1769 feature. The LTE1769
feature enables sending and receiving neighbor information via X2.
68 © 2018 Nokia DN181051332 Issue: 01

g Note: In order to use the LTE2734 feature, Nokia macro-eNBs have to provide
neighbor information to FZM. The following configuration is recommended:
• in FZM:
x2NbInfoTransMode=always
• in macro-eNB:
x2NbInfoTransMode=onDemand
– LTE1997: Discovery Mode Self Configuration for Flexi Zone AP

The LTE2734 feature is dependent on the LTE1997 feature. The LTE1997
feature uses the neighbor information to optimize PCI of the receiving eNB.
• preconfiguration
– The eNB is operational and the RNW database is up and running.
– NetAct is operational, and DCN connection to the eNB is available via OMS.
– The LNBTS-level feature activation flag actZson is set to false.
Mandatory parameters that need to be configured before feature activation:
Table 21 Mandatory Parameters
Managed Object Path Parameter Parameter Name
Abbreviation
MRBTS/LNBTS/ZSONPR zsonProfId ZSONPR Identifier
MRBTS/LNBTS mncLength MNC Length in PLMN
MRBTS/LNBTS mcc MCC in PLMN
MRBTS/LNBTS mnc MNC in PLMN
MRBTS/LNBTS enbName eNB name
MRBTS/LNBTS/FTM systemTitle Network element system name
MRBTS/LNBTS/FTM/PNO cPlaneIpAddress Control plane IP address
MRBTS/LNBTS/FTM/PNO oamIpAddress Transport network IP Address of the
O&M system
MRBTS/LNBTS/LNCEL phyCellId Physical Layer Cell Identifier
MRBTS/LNBTS/LNCEL siWindowLen SI Window length
MRBTS/LNBTS/LNCEL siMessagePeriodicity System Information 2 Scheduling
MRBTS/LNBTS/LNCEL IntraPresAntp Presence Antenna Port 1
MRBTS/LNBTS/LNCEL siMessagePeriodicity System Information 3 Scheduling
MRBTS/LNBTS/LNCEL qrxlevminintraF min. required RX level for intra-freq
neighboring cells
MRBTS/LNBTS/LNCEL prachFreqOff PRACH frequency offset
MRBTS/LNBTS/LNCEL tac Tracking area code
MRBTS/LNBTS/LNCEL rootSeqIndex RACH root sequence
MRBTS/LNBTS/LNMME ipAddrPrim Primery IPv4/v6 address
DN181051332 Issue: 01 © 2018 Nokia 69

Table 21 Mandatory Parameters (Cont.)
Managed Object Path Parameter Parameter Name
Abbreviation
MRBTS/SMOD/APMOD/AP systemTitle AP system name
FTM
Procedure
Sub-steps
left.
The BTS Site check box, located in the Target section, is selected by default.
state of the BTS.
3 Proceed to the Radio Network Configuration page.
4 Go to the LNBTS object.
Object path: MRBTS ► LNBTS
5 Set the actZSon parameter value to true.
6 At least one instance of the ZSONPR object must be configured.
Sub-steps
a) Select LNBTS ► New ► ZSONPR
7 Set the actUeBasedAnrInterFreqLte parameter value to true or the
actUeBasedAnrIntraFreqLte parameter value to true, or set both parameters to
true.
8 All LNCEL zsonProfileId parameters must be set to a valid Profile ID.
70 © 2018 Nokia DN181051332 Issue: 01

Sub-steps
Result
• The LTE2734 feature is enabled.
• LTE2734-related parameters have been configured correctly.
• The operator is able to invoke the Z-SON PCI optimization for all cells that are in the
normal operation mode of an FZC or FZM by setting the zsonOpMode parameter to
ForceFullOptimization.
• The operator is able to set the zsonOpMode parameter to ResetRFDiscMode.
• The operator is able to set the zsonEventTriggerEnable parameter to true.
Further information
After the LTE2734 feature is enabled, for all the cells that are going to be brought to
operational enabled state, the Z-SON PCI optimization needs to be run once through the
RF Discovery Mode if their zsonPciPrachControl flag is set to Automatic. There
are three states of the RF Discovery Mode:
• PreRFDiscMode
• InRFDiscMode
• PostRFDiscMode
If the RF Discovery Mode of a cell is not equal to PostRFDiscMode and the
zsonPciPrachControl flag is set to Automatic, the FZC or FZM performs the PCI
optimization during a cell setup through the RF Discovery Mode. After completing the
PCI optimization, the RF Discovery Mode of a cell is changed to PostRFDiscMode. If a
cell's RF Discovery Mode is set to PostRFDiscMode, the cell will be brought to
operational enabled state in the same way as before this feature was implemented.
If the operator wants to force the whole FZC or FZM to perform the PCI optimization
through the RF Discovery Mode again, they can set the zsonOpMode flag to
ResetRFDiscMode. The FZC or FZM sets the RF Discovery Mode for all its cells to
PreRFDiscMode, sets the zsonOpMode back to Auto and sends it to NetAct through
a CCN.
DN181051332 Issue: 01 © 2018 Nokia 71

g Note: The operator needs to activate or deactivate an active cell to cause
zsonOpMode to go back to Auto. It will not go back without operator making some
change.
6.6 Deactivating LTE2734

Instructions to deactivate the LTE2734: Flexi Zone Discovery Mode Neighbor Information
Exchange feature using the BTS Site Manager
Before you start

• preconfiguration
– The eNB is operational, and the RNW database is up and running.
– NetAct is operational, and the DCN connection to the eNB is available via OMS.
– The LNBTS-level feature activation flag actZson is set to true.
Procedure
Sub-steps
left.
state of the BTS.
5 Set the actZSon parameter value to false.
72 © 2018 Nokia DN181051332 Issue: 01

Sub-steps
Result
• The LTE2734 feature is disabled in the eNB (this means the management of the
PCI/PRACH settings optimization is only possible from the C-SON or is manually
changed by the operator).
• Z-SON PCI optimization will not be performed on any FZAP or FZM cells.
• The zsonOpMode flag can only be set to Auto.
• The zsonEventTriggerEnable parameter can only be set to false.
6.7 Other instructions

User scenarios
The following user scenarios are described:
Use case 1: PCI settings optimization while the FZAP or FZM cell is operating in the
normal mode, and the PCI settings optimization mode of the Z-SON (zsonOpMode) is
set to "Auto"
Use case 2: LTE2734 is enabled, cell is setup through RF Discovery Mode, neighbor
strength is calculated per UEs' ReportStrongestCells measurement reports, Z-
SON PCI optimization algorithm takes the neighbor strength into the consideration
Use case 3: the operator sets the zsonOpMode parameter to
ForceFullOptimization and pushes the change down to the eNB; there is no
ongoing Z-SON PCI optimization process
Use case 4: Z-SON PCI optimization while the FZAP or FZM cell is operating in the
normal mode; the PCI optimization event-trigger mode of the Z-SON is set to true
(zsonEventTriggerEnable is set to "True"), and a neighbor relation has been changed;
there is no ongoing Z-SON PCI optimization on the impacted cells due to this neighbor-
relation change
Use case 1
DN181051332 Issue: 01 © 2018 Nokia 73

Use case 1: PCI settings optimization while the FZAP or FZM cell is operating in the
normal mode, and the PCI settings optimization mode of the Z-SON (zsonOpMode) is
set to "Auto"
Actors:
Operator, System
Pre-conditions:
• The eNB is operational, and the RNW database is up and running.
• NetAct is operational, and the DCN connection to the eNB is available via OMS.
• The zsonOpMode is set to Auto.
• The FZAP cell is in the operational enabled state and operating in the normal mode.
g Note: The PCI change will lead to a cell lock/unlock.
Main Flow:
1. The ZSON manager detects PCI settings issue of the cell if a new cell is added. No
change on existing cells.
2. The ZSON manager resolves the issue and uploads the plan file to the FZC or FZM
to update the PCI settings.
Post-conditions:
PCI settings are changed per plan file in the FZAP or FZM cell.
Use case 2
Use case 2: LTE2734 is enabled, cell is setup through RF Discovery Mode, neighbor
strength is caculated per UEs' ReportStrongestCells measurement reports, Z-
SON PCI optimization algorithm takes the neighbor strength into the consideration
Actors:
• Operator, (BTSSM/NetAct)
• eNB
Pre-conditions:
• The eNB is operational and RNW database is up and running, and
• BTSSM/NetAct is operational and DCN connection to the eNB is available via OMS,
and
• The LNBTS-level feature activation flag actZson is set to True.
• a cell's RF Discovery Mode state is not equal to PostRFDiscMode, and
• a cell's zsonPciPrachControl flag is set to Automatic.
Description:
1. The eNB receives a request to change a cell's operational state to enabled.
2. The eNB reads the R&D parameter and finds out the corresponding power level to
bring up the cell.
74 © 2018 Nokia DN181051332 Issue: 01

3. The cell is brought to the operational enabled state with the operator assigned PCI
and corresponding power level.
g Note: The eNB configures the UE to perform the active UE based intra-freq ANR for
the UEs come to the cell after cell is in operational enabled state.
4. The eNB starts the power step up timer per parameter definition.
5. The eNB detects that it has received rfDiscNumUEMeasReports number of UE
measurement reports or the power step up timer has expired for this cell. It stops the
timer if it is still running, invokes the Z-SON PCI optimization algorithm to check
whether the currently used PCI is still safe to use or not, reset the per power level
measurement reports received counter.
6. Step up the power per parameter definition, go back to step 4 if there is no need to
swap the PCI, and there is a need to step up the power level (such as current power
level is less than pMax).
g Note: If after step up the power, the power level is greater than pMax, set the power
level to pMax.
7. If the eNB detects that the currently used PCI is not safe to use, it picks up a new
best suitable PCI which is safe to use, makes the UE leave the cell, locks/unlocks
the cell, puts the cell in the operational enabled state with the new PCI, informs the
BTSSM/NetAct with this new PCI, and goes back to step 4.
8. If the eNB detects it is the power level which needs to swap the PCI and PCI has not
been swapped at this power level previously, and the total measurement reports
received for this cell is greater than the R&D defined rfDiscNumUEMeasReports
number, it picks up a new best suitable PCI which is safe to use, makes the UE leave
the cell, locks/unlocks the cell, puts the cell in the operational enabled state with the
new PCI, informs BTSSM/NetAct with the new PCI, and goes back to step 4.
Otherwise if the total number of the measurement reports received for this cell has
not reached rfDiscNumUEMeasReports, the eNB goes back to step 4.
9. If the eNB detects it is the power level which needs to swap the PCI and the PCI has
been swapped at this power level previously, it is the same as step 6.
10. The eNB ends the Z-SON PCI optimization for this cell (sets the RF Discovery Mode
state to PostRFDiscMode). If the number of swap is greater than 0, and the eNB
has not received rfDiscNumUEMeasReports number of measurement reports for
this cell yet, it maintains the received measurement reports counter running and start
a Z-SON PCI swap timer (set the timer to expire in 24 hours) for this cell. Once
received the rfDiscNumUEMeasReports number of measurement reports or the
Z-SON PCI swap timer expiration happened, the eNB stops the timer if it is still
running, invokes the Z-SON PCI optimization algorithm, picks a best suitable PCI
which is safe to use, makes the UE leave the cell, locks/unlocks the cell, puts the cell
in the operational enabled state with the new PCI, and informs the NetAct/BTSSM
with the new PCI.
Post-conditions:
• The cell is in the operational enabled state.
• The best suitable PCI is assigned by the eNB to the cell (no conflict, not from
forbidden range, not violate IAFIM range, avoid confusion if it is possible, avoid
MOD3/MOD30 if it is possible) if the PCI swap number is greater than 0. Otherwise,
the operator assigned PCI can still be used if it is safe to use.
Exceptions:
DN181051332 Issue: 01 © 2018 Nokia 75

No measurement report is received, Z-SON PCI algorithm runs without neighbor strength
as the input.
Use case 3
Use case 3: the operator sets the zsonOpMode parameter to
ForceFullOptimization and pushes the change down to the eNB; there is no
ongoing Z-SON PCI optimization process
Actors:
Operator, System
Pre-conditions:
• The eNB is operational and the RNW database is up and running.
• NetAct is operational, and the DCN connection to the eNB is available via OMS.
• The operator sets the zsonOpMode parameter to ForceFullOptimization and
pushes the change down to the eNB.
• There is no ongoing Z-SON PCI optimization process.
Description:
1. The PCI(s) of all the FZAP and/or FZM cells are optimized.
2. For all the cells in the operational enabled state whose Z-SON control flag
(zsonPciPrachControl) has been set to Automatic, the FZC or FZM picks
and assigns a most suitable PCI if the currently used one is not in the group of the
most suitable PCIs (the lowest-penalty PCI is at least 3 dB better than the currently
used PCI).
3. Upon completion of the zsonOpMode-triggered Z-SON PCI optimization process,
the FZC or FZM sets the zsonOpMode parameter to Auto.
4. A CCN is sent to the NetAct, which includes the zsonOpMode parameter set back to
Auto plus all the changed PCIs (the same information is updated in the BTSSM as
well).
Post-conditions:
PCI for one or more cells could be optimized.
g Note: The ForceFullOptimization PCI optimization in a normal mode has to be
stored in the persistent memory in case of an FZC or FZM reset. Once an FZC or FZM
comes back from the reset, it checks whether this corresponding parameter is set to
ForceFullOptimization. The FZC or FZM performs the Z-SON PCI optimization
from the beginning.
Use case 4
Use case 4: Z-SON PCI optimization while the FZAP or FZM cell is operating in the
normal mode; the PCI optimization event-trigger mode of the Z-SON is set to true
(zsonEventTriggerEnable is set to "True"), and a neighbor relation has been changed;
there is no ongoing Z-SON PCI optimization on the impacted cells due to this neighbor-
relation change
Actors:
76 © 2018 Nokia DN181051332 Issue: 01

Operator, System
Pre-conditions:
• The eNB is operational and the RNW database is up and running.
• NetAct is operational and the DCN connection to the eNB is available via OMS.
• The PCI settings optimization event-trigger mode of the Z-SON is set to True.
• The FZC or FZM receives an event which indicates neighbor relations have been
changed.
• There is no ongoing Z-SON PCI optimization process on the impacted cells due to
this neighbor-relation change.
Description:
1. The FZC or FZM Z-SON updates its local storage with all the newly-changed
neighbor-relation information regardless of the zsonEventTriggerEnable
parameter being set to True or False.
2. The FZC or FZM triggers the Z-SON PCI optimization on the cells in the operational
enabled state that have been impacted due to the neighbor-relation change whose
zsonPciPrachControl flag is equal to Automatic and are not in the middle of
the RF discovery mode.
Post-conditions:
PCI for one or more cells could be optimized.
g Note: The ForceFullOptimization PCI optimization in a normal mode has to be
stored in the persistent memory in case of an FZC or FZM reset. Once an FZC or FZM
comes back from the reset, it checks whether this corresponding parameter is set to
ForceFullOptimization. The FZC or FZM performs the Z-SON PCI optimization
from the beginning.
DN181051332 Issue: 01 © 2018 Nokia 77

LTE3042: Cloud Flexi Zone Controller LTE17A Operability Features
7 LTE3042: Cloud Flexi Zone Controller

The Cloud Flexi Zone Controller (cFZC) is a virtual network function (VNF) running on a
fully featured, energy efficient 2-socket Nokia AirFrame server platform and interfaces
with the VNF Manager.
Figure 11 The cFZC features distribution per release
CloudFlexiZoneControllerfunctionality
FL17A
LTE3042-CloudFlexi LTE3841- CloudFlexiZone

ZoneController ControllerandWireless
LANControllerAll-In-One
The LTE3042: Cloud Flexi Zone Controller feature provides the basic capability to host

Flexi Zone Controller (FZC) Application on the Nokia Radio Cloud Platform (RCP) to
support distributed FZC deployment model.

The LTE3042: Cloud Flexi Zone Controller feature provides the following benefits:
• Hosts Flexi Zone Controller in a cloud environment.
• Enables migration of the Flexi Zone Access Point (FZAP) from the BCN-based FZC
to the Cloud FZC.

Feature overview
The LTE3042: Cloud Flexi Zone Controller feature leverages AirFrame hardware and
Flexi Zone Micro (FZM) BTS devices configured as Flexi Zone Access Points (FZAPs) to
implement a cloud-based Zone eNodeB (ZeNB). The cloud-based ZeNB is comprised of
a cFZC and one or more FZAPs. The FZAPs communicate with a cFZC over a wired
backhaul. This interface between cFZC and FZAPs is called Z1 interface and carries
control, bearer, and management information. The following figure shows an overview of
the Flexi Zone architecture.
78 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3042: Cloud Flexi Zone Controller
Figure 12 Flexi Zone architecture
Core Network
Controller
AP AP AP
AP AP
Zone
The Z1 interface, zone transport, and network management software from the current
Box Controlled Node (BCN)-based Flexi Zone Controller Application are leveraged for
the Cloud Flexi Zone Controller.
Architecture overview
The FZC application provides a framework and basic capability to support small cell
Access Points (APs). The controller application provides S1/X2 aggregation and mobility
anchoring/biasing. The Nokia Radio Cloud Platform enables the cFZC deployment. The
following figure shows a process of adapting the Flexi Zone solution to cFZC solution.
DN181051332 Issue: 01 © 2018 Nokia 79

Figure 13 Adapting Flexi Zone solution to Radio Cloud
BCN!based!Zone Cloud!FZC
FZC cFZC
TRS-IWF TRS-Apps TRS-IWF TRS-Apps
L3’ BTS-OM L3’ BTS-OM
eNB!SON Zone!Mgr eNB!SON Zone!Mgr
FxP RCP
Z1 ADAPT Z1
AP AP
BTS-OM(AP) Cell!SON
BTS-OM(AP) Cell!SON
L2 RFSW L3’
L2 RFSW L3’
L1 Sync TRSW
L1 Sync TRSW
PS!SW
PS!SW
Needed!for!Radio!Cloud
Modified
Existing!SW
The cFZC operates as a VNF containing two Virtual Machines (VMs), which run on the
host OS provided by Radio Cloud Platform (RCP). The FZC CPU (FCPU) VM contains
all the applications running in the BCN FCPU card plus the RCP management
applications. The FZC Zone Bearer Unit (FZBU) VM contains all the applications running
in the BCN FZBU card.
Cloud FZC distributed deployment (single blade)

The cFZC distributed deployment model introduced in the LTE3042: Cloud Flexi Zone
Controller feature is based on the Nokia Airframe Cloud Infrastructure for Real-time
applications (NCIR) Release 17 All-in-One (AiO) without server redundancy configuration
and has the following capabilities:
• Single node distributed cFZC configuration, which is the BCN replacement.
• Support for 100 cells.
80 © 2018 Nokia DN181051332 Issue: 01

• Optional type/model of top of rack (ToR) switch, depending on customer
configuration.

The LTE3042: Cloud Flexi Zone Controller feature impacts the following features:
• LTE3841: Cloud Flexi Zone Controller and Wireless LAN Controller All-In-One
The LTE3841: Cloud Flexi Zone Controller and Wireless LAN Controller All-In-One
feature provides a cloud-based controller solution to host both FZC and Wireless
LAN Controller concurrently on a Nokia RCP.
The LTE3042: Cloud Flexi Zone Controller feature is impacted by the following features:

• LTE1996: Flexi Zone Controller Application
The LTE1996: Flexi Zone Controller Application feature provides basic FZC and
FZAP functionalities.
The LTE3042: Cloud Flexi Zone Controller feature impacts interfaces as follows:
• The cFZC provides the following external interfaces:
– FZC north bound interface (backhaul)
The FZC north bound interface consists of the S1, X2, BTSOM, and NE3S
interfaces.
– FZC south bound interface (fronthaul, called Z1 interface)
The FZC south bound interface carries C-Plane, U-Plane, and M-Plane
messages.

The LTE3042: Cloud Flexi Zone Controller feature impacts network management tools
as follows:
• NetAct and Network Element Manager
– Shows cFZC as a different icon and product type, in addition to changes
associated with the NE3S-based FM/PM/CM management from FxP to RCP.

The LTE3042: Cloud Flexi Zone Controller feature impacts system performance and
capacity as follows:
• The cFZC supports up to 100 cells for distributed deployment.
g Note: The cFZC has the same max number of Cell capacity as the BCN-based FZC.
DN181051332 Issue: 01 © 2018 Nokia 81


Requirements
FDD TDD
System release FDD-LTE17A TD-LTE17A
Flexi Zone BTS Not supported Not supported
Flexi Zone Access Point FL17A TD17A
Cloud Flexi Zone Controller FL17A TD17A
OMS Not supported Not supported
NetAct Not supported Not supported
MME Not supported Not supported
SAE GW Not supported Not supported
UE Not supported Not supported
Alarms
Cloud Flexi Zone Controller Alarms lists alarms introduced with this feature.

Flexi Zone BTS LTE Alarms and Faults lists BTS faults introduced with this feature.

Cloud Flexi Zone Controller Counters and Measurements lists counters introduced with
this feature.

There are no key performance indicators related to the LTE3042: Cloud Flexi Zone
Controller feature.
Parameters
Table 23 Existing parameters related to LTE3042
d object
BTS type of SFN Antenna btsType MRBTS/ - common
EQM_R/
APEQM
_R/
ANTMO
D_R
82 © 2018 Nokia DN181051332 Issue: 01

Table 23 Existing parameters related to LTE3042 (Cont.)
d object
BTS type of Access Point btsType MRBTS/ - common
EQM_R/
APEQM
_R/
APMOD
_R
BTS type btsType MRBTS/ - common
LNBTS
For parameter descriptions, see Cloud Flexi Zone Controller Parameters.
Sales information
ASW SW Asset Monitoring Yes
For more information about the Cloud Flexi Zone Controller, refer to the following
documents:
• Cloud Flexi Zone Controller Product Description
• Administering Cloud Flexi Zone Controller
• Commissioning Cloud Flexi Zone Controller
DN181051332 Issue: 01 © 2018 Nokia 83

RAN3358: OMS for CBIS LTE17A Operability Features
8 RAN3358: OMS for CBIS

The RAN3358: OMS for CBIS feature introduces WCDMA OMSs to be fully functional in

Cloudband Infrastructure Software (CBIS).
8.1 RAN3358 benefits

The RAN3358: OMS for CBIS feature provides the following benefits:
• The operator can run all Nokia management functions in the same CBIS cloud.
• The same hardware resources can be used for LTE and WCDMA OMSs.
• The hardware cost is lower, and it is easier to deploy more OMSs.
8.2 RAN3358 functional description

With the RAN3358: OMS for CBIS feature, WCDMA OMS is fully operational from the
Cloudband Infrastructure Software (CBIS). This feature includes basic support for
Cloudband Application Manager (CBAM) as Virtual Network Functions Manager (VNFM)
such as deployment, undeployment, and SW management operations (upgrade and
backup). The scale-in or scale-out operations are not supported because the OMS runs
on a single virtual machine (VM), thus, scaling by changing VM's number is not possible.
The Cloudband Network Director (CBND) consolidates data from multiple CBIS sources
to create a comprehensive, up-to-date view of the cloud state and provides Life-Cycle-
Management of multi-VNF services.
Hardware resources for CBIS are provided by Nokia AirFrame, but HW configurations
are based on HP ProLiant blade servers. The EMC storage is also supported.
84 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features RAN3358: OMS for CBIS
Figure 14 Mapping Nokia products to ETSI NFV reference architectural framework
NVFManagementandOrchestration
NetworkManagement
OSS/BSS
-FCAPSManagement
(FM,PM,CM,...) Cloud Orchestration
Network - Automated
NetworkService
Service,VNFandInfrastructure Director Management
Description
-SupportsSDN
Management
NokiaNetAct EMS2 EMS3

vOMS Cloud
Application
Manager
NokiaVNF VNF2 VNF3
Application
VirtualizedNetworkFunctions NVFI
Virtual Virtual Virtual VNFManager

- Automated
Computing Storage Network
IMS TAS Deploymentand
Lifecycle
managementvia
VirtualizationLayer Application
Virtualized Templates
MME S/P-GW Infrasturcture -Elasticity
Hardwareresources Manager(s) Management
Airframe
---
Computing Storage Network
IMS Hardware Hardware Hardware
NCIO
g Note: The Measurement Presentation (Application Launcher and Web GUI), PM
database, and Threshold KPI management are not available in
RAN3358: OMS for CBIS feature.
8.3 RAN3358 system impact

RAN3358: OMS for CBIS impact on features

The RAN3358: OMS for CBIS feature has no interdependencies between this and any
other feature.
In RAN3358: OMS for CBIS feature, the OMS will not act as NTP server in virtual OMS
(vOMS).

The RAN3358: OMS for CBIS feature has no impact on network management tools.

The RAN3358: OMS for CBIS feature provides three performance profiles for a virtual
OMS machine that define the NE connectivity.
DN181051332 Issue: 01 © 2018 Nokia 85

RAN3358: OMS for CBIS LTE17A Operability Features
Table 25 Hardware profiles for vOMS
Profiles CPU RAM (GB) HDD (GB) RAID Network
Interface
High Profile 20 24 1 x 92 GB* No RAID* 2/3 x Ethernet
IF (using
VIRTIO
network
adapter)
Medium 16 24 1 x 92 GB* No RAID* 2/3 x Ethernet
Profile IF (using
VIRTIO
network
adapter)
Low Profile 12 24 1 x 92 GB* No RAID* 2/3 x Ethernet
IF (using
VIRTIO
network
adapter)

RAN3358: OMS for CBIS requirements and sales information
Requirements
Table 26 RAN3358: OMS for CBIS hardware and software requirements
RAS IPA-RNC mcRNC Flexi Flexi Flexi Lite
Multiradio Multiradio 10 BTS
BTS BTS
WCDMA 17 Support not Support not Support not Support not Support not
required required required required required
OMS NetAct MSC SGSN MGW UE

WCDMA Support not Support not Support not Support not Support not
OMS17 required required required required required
Alarms
Table 27 New alarms introduced by RAN3358: OMS for CBIS
Alarm ID Alarm name
71139 GUEST HW MISCONFIGURATION
70443 INCOMPLETE CORRUPTED USER DATA FOR VIRTUAL OMS DEPLOYMENT
70452 BLOCK STORAGE FOR ADDITIONAL PARTITION MISSING

There are no faults related to the RAN3358: OMS for CBIS feature.
86 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features RAN3358: OMS for CBIS
Commands
Table 28 Existing SCLI commands related to RAN3358: OMS for CBIS

Command name
vomsswm_helper.py
For command descriptions, see Reference ► Commands ► OMS Related
Commands ► Command Line Interface Tools and Management Scripts in OMS.

There are no measurements or counters related to the RAN3358: OMS for CBIS feature.

There are no key performance indicators related to the RAN3358: OMS for CBIS feature.
Parameters
There are no parameters related to the RAN3358: OMS for CBIS feature.
Sales information
Table 29 RAN3358: OMS for CBIS sales information
Basic Software (BSW) - Yes
DN181051332 Issue: 01 © 2018 Nokia 87

LTE3296/SR001527: Harmonized Object Model for LTE17A Operability Features
SRAN and LTE
9 LTE3296/SR001527: Harmonized Object

Model for SRAN and LTE
Benefits, functionality, system impact, reference data of the feature
Introduction
The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature
introduces a new object model for both products that harmonizes the approach to
configuration and creates a more logical, expandable topology of Managed Object
Classes (MOCs) that easily supports adding future technologies.
The changes to the current object model reflect a new way of approaching configuration
that separates configured hardware from detected hardware, that consolidates
parameters according to their purpose, and distinguishes between common
management parameters and Radio Access Technology (RAT)-specific ones..
9.1 LTE3296/SR001527 benefits

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature provides
the following benefits:
• Reduced effort to configure and administrate a mixed technology network
• Less risk when upgrading a site to multi-RAT due to misconfiguration
9.2 LTE3296/SR001527 functional description
The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature alters the
structure of the Managed Object tree for configuration parameters of both LTE and
SRAN products to align them in one topology. The new model introduces new concepts
that entirely replace some configuration parameters, in addition to relocating and
reorganizing many others into a more logical structure. The major changes can be
summarized as follows:
• Commissioning parameters to configure hardware are separated from parameters
reporting hardware configuration detected at runtime. A new top-level MOC named
EQM holds the configuration of hardware specified by the operator, and a similar
MOC named EQM_R holds the reported configuration of hardware detected by the
eNB at runtime. The Distinguished Name (DN) of the object configuring a particular
piece of hardware in the EQM tree is used to map to the detected hardware in EQM_R
if it exists.
• Hardware topology is now defined by a new set of objects in the EQM/EQM_R trees.
Configured topology is now in the HWTOP tree, split into physical and logical links in
CABLINK and LOGLINK objects, and similarly the detected hardware topology is
stored in CABLINK_R and LOGLINK_R objects under HWTOP_R in EQM_R.
• FDD and TDD parameters are aligned into one common model. Technology-specific
parameters under LNCEL and LNBTS,are moved into new sub-MOCs of their parent
with the suffix _TDD or _FDD as appropriate.
88 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3296/SR001527: Harmonized Object Model for
SRAN and LTE
• Common management parameters are located in the MNL object tree on the top
level. Configuration parameters that trigger actions such as SW reset or calibration
and testing are located in this tree. The old BTSSCL/LCELL object is moved into the
MNL object, under the new CELLMAPPING tree to configure mapping between cells
and physical resources.
• For SRAN, the non-LTE parameters will have their own top-level subtrees: WNBTS
and GNBTS for WCDMA and GSM respectively. In both technologies the LNBTS
object is shared for LTE parameters.
New MOC tree overview
Figure 15 Top level objects in the hierarchy
Changes to hardware configuration and detection

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature
introduces a new way of presenting configured and detected hardware to the
administrator. Configured hardware is maintained separately in the object hierarachy
under the EQM object, and detected hardware is presented under the read-only EQM_R
hierarchy. Detected hardware that matches configured hardware is linked via an ID in the
relevant object under EQM_R.
DN181051332 Issue: 01 © 2018 Nokia 89

SRAN and LTE
Figure 16 The EQM and EQM_R object trees
For each MOC under the EQM subtree, there is a corresponding MOC with the suffix of
_R in the EQM_R subtree. The two MOCs are related to each other by their names and
also via the parameter configDN in the _R version of the object. The configDN
parameter contains the Distinguished Name (DN) of the MOC in EQM. For the DN format,
please refer to the RAML2.1 Specification, section 2.1.
It is possible that the two subtrees do not match each other exactly. Even in the normal
case, the EQM_R tree contains more objects than the configured tree because the BTS is
able to provide more information to the operator than is manually configured. There are
two cases where the discrepancies are reflected in the configDN and state attributes:
1. Hardware is installed but there is no configured EQM object. In this case, the _R
object will be present with configDN set to NULL. This _R object will not be
enabled until the corresponding EQM object is configured.
2. An object in EQM is configured but the hardware is not installed. In this case, the _R
object will be present with configDN set to the configured object. The states of the
_R object will reflect that it is not installed.
g Note: In certain parameters related to antennas under the ALD_R or ANTL_R objects,
the reported values may not match the configured values. This is not an error but may
be due to either hardware limitations of the device or sensor, or due to automatic
commissioning performed by the LTE2403: MHA Auto Commissioning feature. A full list
of affected parameters is given in Table : Reported configuration parameters that may
differ from their commissioning values.
These are the configurable objects and their usage for a macro BTS:
• EQM – The top object of the EQM tree. It must always be present.
• APEQM – Access point equipment subtree. This subtree consists of equipment that
makes up an access point. For macro, there is only 1 instance of it.
• CABINET – At least one is needed to house the system and baseband modules.
90 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
• SMOD – System Module. The controller of the BTS containing the management
interface towards NetAct. Depending on the hardware release, it may or may not
contain baseband processing. There may also be multiple SMODs but only one will be
the main controller. Additional SMODs are for expansion purposes. In AirScale this
refers to a Core Module.
• EAC_IN, EAC_OUT – these are optional environmental control for alarm inputs
(EAC_IN) or relay control (EAC_OUT). They can also be present under an RMOD.
• BBMOD – Baseband Module. Baseband processing module. Additional modules can
be added to a System module to expand the processing capacity.
• PASSDEV – a generic MOC for the operator to document equipment that cannot be
detected by the BTS. It can be used for modeling passive ALD devices or simply a
way for the operator to record inventory data of other passive devices (e.g. power
supply, fan) for the purpose of keeping track of HW inventory.
• RMOD – Radio module. This can be an RF module that is part of the system module
(as in small cell), locally connected to the System Module or remotely connected as
a Remote RF Head (RRH).
• SMOD_EXT – a virtual object to represent a system module from a peer BTS. In RF
sharing, the SMOD_EXT represents another BTS that shares resources of one or
more radio modules.
• HWTOP – Hardware Topology top object. It must always be present.
• CABLINK, LOGLINK – Hardware Topology objects defining physical and logical
connections between modules.
There are significant changes in the hardware topology area. New objects have been
introduced: CABLINK and LOGLINK. CABLINK represents the physical cable,
LOGLINK represents a logical connection between two points, without explicitly defining
the environment between them. Topology between System Modules and RF modules are
defined as CABLINKs specified only by the Distinguished Names of the endpoints. For
an antenna path specification, a full topology is required.
Common Management subtree MNL

The MNL tree contains three objects:
• CMD - Commands, such as hardware reset or RET unit calibration, are activated
here.
• NOTES - Contains NOTE objects that may be freely filled by the operator for any
purpose.
• MNLENT - System module specific objects are placed under MNLENT.
Figure 17 The MNL tree
DN181051332 Issue: 01 © 2018 Nokia 91

SRAN and LTE
The MNLENT (Management Layer Entity) object contains system module specific
parameters and is placed under MNL with one instance for each entity. The related
objects under MNLENT are as follows:
• BBADM - Baseband Administration. Contains BBPOOL objects.
• CAPADM - Capacity Administration. Capacity configuration and limitations are defined
here.
• CELLMAPPING - Cell Mapping. This replaces the cell mapping list that was
previously part of LNCEL.
• FMCADM - Fault Management Common Administration. Parameters related to fault
management are moved here.
• FEATCADM - Feature Common Administration. Parameters to activate and
administer specific features appear here.
• PMCADM - Performance and Monitoring Common Administration.
• SECADM - Security Common Administration. Security related parameters are found
here, and additional security information detected by the BTS is available in the
SECADM_R sub-object.
• SYNC - Synchronization. Time source and synchronization configuration is made
here.
• TEST - Tests. Testing is activated here and the results returned as objects under the
TEST object.
• TRBLCADM - Troubleshooting Common Administration. Contains troubleshooting
parameters.
Figure 18 The MNLENT subtree
Changes to Cell Mapping
92 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
The CELLMAPPING subtree contains the new scheme for mapping cells to antennas
that replaces the previous one in BTSSCL/LCELL. The new CELLMAPPING object
contains a number of LCELL objects equivalent to the old LCELL object, but each new
LCELL object contains a number of CHANNELGROUP objects that contain CHANNEL
objects. The CHANNELGROUP and CHANNEL objects replace the legacy
resourceList parameter in the old LCELL.
Each CHANNEL object is linked to an ANTL object in the EQM tree using the antlDN
parameter, and it also contains a direction parameter to specify whether the channel is
RX or TX. A TXRX antenna line is configured with two CHANNEL objects, one for each
direction. As the ANTL is a child object of an RMOD, there is no need to specify the old
rmodId or antId parameters. An example of how the old and new configurations
compare is given below.
Table 30 Comparison of Cell Mapping configurations
Old Configuration New Configuration
MRBTS-1/BTSSCL- antlId (1) .../MNLENT- antlDN: MRBTS-1/EQM-
1/LCELL- txRxUsage 1/CELLMAPPIN 1/APEQM-1/RMOD-1/ANTL-1
1/resourceList (TXRX) G-1/LCELL- channelId: 1
1/CHANNELGR direction: TX
antId (2) OUP-
txRxUsage 1/CHANNEL-1
(TXRX) .../MNLENT- antlDN: MRBTS-1/EQM-
1/CELLMAPPIN 1/APEQM-1/RMOD-1/ANTL-1
G-1/LCELL- channelId: 2
1/CHANNELGR direction: RX
OUP-
1/CHANNEL-2
.../MNLENT- antlDN: MRBTS-1/EQM-
OUP-
1/CHANNEL-3
.../MNLENT- antlDN: MRBTS-1/EQM-
1/CHANNELGR direction: RX
OUP-
1/CHANNEL-4
MRBTS-1/BTSSCL- antlId (3) .../MNLENT- antlDN: MRBTS-1/EQM-
1/LCELL- txRxUsage 1/CELLMAPPIN 1/APEQM-1/RMOD-2/ANTL-1
2/resourceList (TX) G-1/LCELL- channelId: 1
antId (4) OUP-
txRxUsage 1/CHANNEL-1
(TX) .../MNLENT- antlDN: MRBTS-1/EQM-
OUP-
1/CHANNEL-2
DN181051332 Issue: 01 © 2018 Nokia 93

SRAN and LTE
Unification of LNCEL for FDD and TDD technologies

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature unifies
the previously different hierarchies of the LNBTS/LNCEL tree into one form.
The LNCEL object has a new parameter cellTechnology that may be set as FDD or
TDD. TDD- and FDD-specific parameters in LNCEL are moved to technology-specific
objects LNCEL_TDD and LNCEL_FDD respectively, which contain technology-specific
objects for MPUCCH and APUCCH with the _TDD and _FDD suffix. LNCEL child objects
belonging to one specific technology are configured only if that technology is specified by
the cellTechnology parameter in the LNCEL parent, and objects common to both
technologies are consistency-checked according to that same parameter.
The LNBTS object has a similar controlling parameter named
supportedCellTechnology that applies to the whole eNB, and again TDD- and
FDD-specific parameters are moved to child objects named LNBTS_TDD and
LNBTS_FDD respectively. Common child classes are aligned and consistency-checked
according to that parameter, with the exception of MBSFNSYNCAREA and MBSFNSYNC
which are split into technology-specific classes with the _TDD and _FDD suffix.
94 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
Figure 19 The LNBTS tree
DN181051332 Issue: 01 © 2018 Nokia 95

SRAN and LTE
Figure 20 The LNCEL tree
Guide to finding relocated parameters

This section gives a general overview of the configuration parameters affected by this
feature, with their new location and comments about the changes affecting them. A
comprehensive list of all parameters for FDD is available in the reference document
FDD-LTE BTS Parameters, and for TDD in the document TDD-LTE BTS Parameters. A
list of parameters in EQM_R that may differ from their commissioned counterparts in
EQM, with reasons, is given in table Table 32: Detected hardware parameters that may
differ from their commissioned values.
Table 31 Parameters moved or replaced by LTE3296
Old Parameter New location Description of changes
The following parameters MRBTS/LNBTS/LNCEL/LNCE Technology-specific
under MRBTS/LNBTS/LNCEL: L_FDD parameters are moved to their
own sub-object of LNCEL.
act1TxIn2Tx (Activate 1TX in
2TX configuration)
actAutoPucchAlloc (Activation
of automatic PUCCH
allocation)
actCombSuperCell (Activate
combined supercell
configuration)
96 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
Table 31 Parameters moved or replaced by LTE3296 (Cont.)
actFastMimoSwitch (Activate
fast adaptive MIMO switch)
actLiquidCell (Activate liquid
cell configuration)
actNBIoT (Activate NB-IoT)
actPuschMask (Activate
PUSCH masking)
actRepeaterMode (Repeater
mode activation)
actSdlc (Activate supplemental
downlink carrier)
actSuperCell (Activate
supercell configuration)
actUciOnlyGrants (Activate
UCI only grant transmission)
actUlMultiCluster (Activate UL
multi-cluster Scheduling)
activatedMimoTM (Activated
MIMO transmission mode)
addNumDrbRadioReasHo
(Add number DRB
radioReasHo)
addNumDrbTimeCriticalHo
(Add number DRB
timeCriticalHo)
addNumQci1DrbRadioReasHo
(Add number QCI1 DRB for
radioReasHo)
addNumQci1DrbTimeCriticalH
o (Add number QCI1 DRB for
timeCriticalHo)
blankedPucch (Blanked
PUCCH resources)
csiRsConfigInfo (CSI-RS
configuration information)
dlChBw (Downlink channel
bandwidth)
dlMimoMode (Downlink MIMO
mode)
dlRsBoost (Downlink reference
signals transmission power
boost)
dlpcMimoComp (MIMO power
compensation)
DN181051332 Issue: 01 © 2018 Nokia 97

SRAN and LTE
earfcnDL (EARFCN downlink)
earfcnUL (EARFCN uplink)
liquidCellConfigInfo (Liquid cell
liquidCellCsiRsResInUse
(Liquid cell CSI-RS resource
configuration in use)
maxNrSymPdcch (Maximum
number of OFDM symbols for
PDCCH)
maxNumActDrb (Max number
act DRB)
maxNumActUE (Maximum
number of active UEs)
maxNumCaConfUe (Max
number carrier aggr configured
UEs)
maxNumCaConfUe3c (Max
UEs 3 Carriers)
maxNumCaConfUeDc (Max
number Carrier Aggr
configured UEs double carrier)
maxNumQci1Drb (Max
number QCI1 DRBs (GBRs))
maxNumUeDl (Maximum
amount of users per TTI in DL)
maxNumUeUl (Maximum
amount of users per TTI in UL)
maxPrbHighPrioUciGrant
(PRB limit for high prio UCI-
only grants per TTI)
mimoClConfig (MIMO Closed
Loop configuration)
mimoOlConfig (MIMO Open
Loop configuration)
multNumUeHighPrioUciGrant
(Adjust max number of high
prio UCI-only grants per TTI)
multUciGrant (Adjust timer for
low and high priority UCI-only
grants)
prachCS (PRACH cyclic shift)
98 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
prachConfIndex (PRACH
configuration index)
prachFreqOff (PRACH
frequency offset)
prachHsFlag (PRACH high
speed flag)
pref4LayerMimoVsCAggr
(Preference 4-layer MIMO
versus carrier aggregation)
prsConfigurationIndex (PRS
prsNumDlFrames (PRS
Number of DL frames)
pucchNAnCs (PUCCH cyclic
shift for mixed formats)
rfSensitivity (RF unit
sensitivity)
ripAlarmingConfig (RIP
alarming configuration)
rootSeqIndex (RACH root
sequence)
selectOuterPuschRegion
(Target UL outer scheduling
region)
srsActivation (SRS feature
activation/deactivation)
srsPwrOffset (Power offset for
SRS transmission power
calculation)
subCellConf (Subcell
Configuration)
superCellParSet (Supercell
parameter set)
syncSigTxMode
(Synchronization signals
transmission mode)
ulChBw (Uplink channel
bandwidth)
ulCombinationMode (Uplink
combination mode)
ulsPuschMask (PUSCH mask)
utranLbLoadThresholds
(UTRAN balancing load
thresholds)
DN181051332 Issue: 01 © 2018 Nokia 99

SRAN and LTE
The following parameters MRBTS/LNBTS/LNCEL/LNCE Technology-specific
under MRBTS/LNBTS/LNCEL: L_TDD parameters are moved to their
own sub-object of LNCEL.
a2TimeToTriggerActTdscdma
Meas (Time to trigger for A2 to
activate TD-SCDMA
measurement)
act1TxIn2Tx (Activate 1TX in
2TX configuration)
actAutoPucchAlloc (Activation
of automatic PUCCH
allocation)
actBfFallback (Beamforming
fallbacking activation)
actCEBB (Activate CEBB)
actDlMuMimo (Activate
Downlink MU-MIMO)
actDldynTargetBler (Activate
DL dynamic target BLER)
actDownSampling (Activate
down sampling)
actFastMimoSwitch (Activate
fast adaptive MIMO switch)
actPdcchLoadGen (Activate
PDCCH load generation)
actReduceWimaxInterference
(Activate reduced WiMax
interference)
actSuperCell (Activate
supercell configuration)
actTmSwitch (Active
transmission mode switch)
actUlMuMimo (UL MU-MIMO
activation)
actUlSps (Activate UL SPS)
actUpPtsBlanking (Activate
UpPTS blanking)
activatedMimoTM (Activated
MIMO transmission mode)
addNumDrbRadioReasHo
(Add number DRB
radioReasHo)
addNumDrbTimeCriticalHo
(Add number DRB
timeCriticalHo)
100 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
addNumQci1DrbRadioReasHo
(Add number QCI1 DRB for
radioReasHo)
addNumQci1DrbTimeCriticalH
o (Add number QCI1 DRB for
timeCriticalHo)
antCablingMappingConfig
(Antenna cabling mapping
configuration)
bfCqiThDown (CQI Threshold
Downgrade for TM8)
bfCqiThUp (CQI Threshold
Upgrade for TM8)
bfRankThDown (Rank
Threshold Downgrade for
TM8)
bfRankThUp (Rank Threshold
Upgrade for TM8)
chBw (Channel bandwidth
TDD)
cqiPerSbPeriodFactor (R10
periodicity factor)
csBIALeftNeighborCell (CSBIA
Left Neighbor Cell)
csBIARightNeighborCell
(CSBIA Right Neighbor Cell)
csiRepSubmode (CSI
reporting submode)
csiRsConfigInfo (CSI-RS
dlDynPcRange (Power
dynamic adjust range for DL
power allocation)
dlInterferenceSpatialMode
(Spatial Mode for Downlink
Interference)
dlInterferenceTxPowerOffset
(Transmission Power Offset for
Downlink Interference)
dlInterferenceUpdatePeriod
(Update Period for Downlink
Interference)
dlMimoMode (Downlink MIMO
mode)
DN181051332 Issue: 01 © 2018 Nokia 101

SRAN and LTE
dlMuMimoParSet (Downlink
MU-MIMO Parameter Set)
dlOlqcDeltaCqiStepDownQAM
(CQI offset decrease for
HARQ NACK/DTX response
for DL OLQC with 16QAM or
64QAM)
dlOlqcDeltaCqiStepDownQPS
K (CQI offset decrease for
HARQ NACK/DTX response
for DL OLQC with QPSK)
dlRsBoost (Downlink reference
signals transmission power
boost)
dlSectorBFWeightProfName
(Downlink sector beamforming
weight profile name)
dlSectorBeamformingMode
mode)
dlpcMimoComp (MIMO power
compensation)
dlsFdAlg (DL scheduler FD
algorithm)
dlsNgap (Distributed virtual
resource block gap value)
dlsSchedType (Downlink
scheduler type)
earfcn (EARFCN for both
Downlink and Uplink (TDD))
filterCoefficientCSFBPccpchRs
cp (Filter coefficient for CSFB
PCCPCH-RSCP)
filterCoefficientPccpchRscp
(Filtering coefficient used for
PCCPCH-RSCP)
hopBwPusch (Hopping
bandwidth of PUSCH)
hysThreshold2Tdscdma
(Related hysteresis of
threshold th2 TD-SCDMA for
RSRP)
maxNrSymPdcch (Maximum
number of OFDM symbols for
PDCCH)
102 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
maxNumActDrb (Max number
act DRB)
maxNumActUE (Maximum
number of active UEs)
maxNumCaConfUe (Max
UEs)
maxNumCaConfUe3c (Max
UEs 3 Carriers)
maxNumCaConfUeDc (Max
number Carrier Aggr
configured UEs double carrier)
maxNumQci1Drb (Max
number QCI1 DRBs (GBRs))
maxNumUeDl (Maximum
amount of users per TTI in DL)
maxNumUeDlDwPTS
(Maximum amount of users
per TTI in DL DwPTS)
maxNumUeUl (Maximum
amount of users per TTI in UL)
mimoBfCqiAvg (CQI averaging
constant in beamforming)
mimoBfCqidlComp (CQI
compensation in dual layer
beamforming)
mimoBfdlRiAvg (RI averaging
constant in dual layer
beamforming)
mimoBfslCqiThD (CQI
threshold from TxDiv to single
layer beamforming)
mimoBfslCqiThU (CQI
threshold from single layer
beamforming to TxDiv)
mimoClConfig (MIMO Closed
Loop configuration)
mimoOlConfig (MIMO Open
Loop configuration)
nSrsDtx (Consecutive SRS
DTX detections number)
nSrsRec (Consecutive SRS
DTX recovery number)
DN181051332 Issue: 01 © 2018 Nokia 103

SRAN and LTE
pdcchLoadLevel (PDCCH load
level)
pdcchLoadPsdOffset (PSD
offset for dummy PDCCH)
prachCS (PRACH cyclic shift)
prachConfIndex (PRACH
prachFreqOff (PRACH
frequency offset)
prachHsFlag (PRACH high
speed flag)
pref4LayerMimoVsCAggr
(Preference 4-layer MIMO
versus carrier aggregation)
prohibitTimerTmSwitch
(Prohibit timer for dynamic TM
mode switch)
prsConfigurationIndex (PRS
prsNumDlFrames (PRS
Number of DL frames)
pucchNAnCs (PUCCH cyclic
shift for mixed formats)
puschHopOffset (PUSCH
hopping offset)
ripAlarmingConfig (RIP
alarming configuration)
rootSeqIndex (RACH root
sequence)
rxCalibrationConfiguration (RX
calibration in UL subframe)
simUlSpsPf3 (Enable sim. UL
SPS and PUCCH format 3 for
a UE)
srsActivation (SRS feature
srsBwConf (SRS bandwidth
configuration)
srsDlMimoModeDepConf
(SRS downlink MIMO mode
dependant configuration)
srsDuration (SRS duration)
srsHoppingBw (SRS hopping
bandwidth)
104 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
srsOnTwoSymUpPts (SRS
transmission on 2 symbols of
UpPTS act/deact)
srsPwrOffset (Power offset for
SRS transmission power
calculation)
srsSimAckNack (SRS
simultaneous ack/nack
srsSubfrConf (SRS subframe
configuration)
superCellParSet (Super cell
parameter set)
syncSigTxMode
(Synchronization signals
transmission mode)
t304InterRatTd (Timer t304 for
handover to TD-SCDMA)
tddFrameConf (TDD subframe
configuration)
tddSpecSubfConf (TDD
special subframe
configuration)
threshold2Tdscdma
(Threshold th2 TD-SCDMA for
RSRP)
timeChInfoValid (Time Period
for Channel Information Valid)
tmSwitchProfileId
(Transmission mode switch
profile identifier)
tmSwitchThresholdDef (TM
switching threshold definition)
uciOnlyMaxCodeRate
(Maximum code rate for UCI-
only TX in UL)
ulCombinationMode (Uplink
combination mode)
ulMuMimoParaSet (UL MU-
MIMO parameter set)
ulSpsConfig (SPS
configuration)
voLteRedirTimer (Redirected
VoLTE call setup supervision
timer)
DN181051332 Issue: 01 © 2018 Nokia 105

SRAN and LTE
The following parameters MRBTS/LNBTS/LNBTS_FDD Technology-specific
under MRBTS/LNBTS: parameters are moved to their
own sub-object of LNBTS.
act1xSrvcc (Activate SRVCC
to CDMA/1xRTT)
actCaIntraCellHo (Activate CA
steering intra-cell handover)
actConvVoice (Activate
support of conversational voice
bearer)
actDedVoLteInterFreqHo
(Activate dedicated VoLTE
inter-frequency handover)
actDistributedSite (Activate
support for distributed site)
actDlIntShaping (Activate
downlink interference shaping)
actDualBand (Activate support
for dual band operation)
actFlexBbUsage (Activate
flexible base band usage)
actHighPrioServices (Activate
high priority services)
actHighRrc (Activate high
amount of RRC connected UE)
actIMSEmerSessR9 (Activate
support of IMS emergency
sessions for Rel 9 UE)
actInterFreqServiceBasedHo
(Activate inter-frequency
service based handover)
actMFBI (Activate MFBI
support)
actOptimizedBbUsage
(Activate optimized baseband
resource usage)
actPeriodicCarrierBlinking
(Activate periodic carrier
blinking)
actProSeComm (Activate
ProSe communication)
actPubSafetyBearers (Activate
public safety bearers)
actSrvccToGsm (Activate
SRVCC to GSM)
106 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
actSrvccToWcdma (Activate
SRVCC to WCDMA)
actTempRadioMaster (Activate
temporary radio master role)
actUtranLoadBal (Activate
inter-RAT UTRAN load
balancing)
actVoLteCallSteering (Activate
VoLTE call steering)
dataDivisionThrXCC (Data
Division Threshold xCC)
dlOlqcDeltaCqiMax (Maximum
CQI offset for DL OLQC)
hopBwPusch (Hopping
bandwidth of PUSCH)
numTxWithHighNonGbr
(Number of sampled
subframes with High Non-GBR
traffic)
pdcchUlDlPrio (PDCCH LA UL
DL priorities)
preventPsHOtoWcdma
(Prevent PS-HO to WCDMA)
puschHopOffset (PUSCH
hopping offset)
reportTimerUtranLbB1 (Inter-
system UTRAN load bal.
supervision timer B1 event)
rtwpThresholdValue10 (RTWP
threshold value for 10 Mhz)
threshold value for 1.4 Mhz)
threshold value for 20Mhz)
sdlcFreqList (Supplemental DL
carrier frequency list)
DN181051332 Issue: 01 © 2018 Nokia 107

SRAN and LTE
tempRadioMasterRecovTime
(Temporary radio master
recovery time)
tempRadioMasterTriggerTime
(Temporary radio master
trigger time)
ulsNumConsecutivePhr
(Number of consecutively
received PHRs)
utranLbB1actLim (LTE-UTRAN
Load Bal B1 active limit)
The following parameters MRBTS/LNBTS/LNBTS_TDD Technology-specific

under MRBTS/LNBTS: parameters are moved to their
own sub-object of LNBTS.
act1xSrvcc (Activate SRVCC
to CDMA/1xRTT)
actB2SupprTdscdmaWithVoLt
e (Activate B2 suppression for
HO to TD-SCDMA with VoLTE)
actCaIntraCellHo (Activate CA
steering intra-cell handover)
actConvVoice (Activate
support of conversational voice
bearer)
actCsBIA (Activate CSBIA)
actDedVoLteInterFreqHo
(Activate dedicated VoLTE
inter-frequency handover)
actDistributedSite (Activate
support for distributed site)
actDlIntShaping (Activate
downlink interference shaping)
actFlexBbUsage (Activate
flexible base band usage)
actHOtoTdscdma (Activate
handover from LTE to TD-
SCDMA)
actHighPrioServices (Activate
high priority services)
actIMSEmerSessR9 (Activate
support of IMS emergency
sessions for Rel 9 UE)
actInterFreqServiceBasedHo
(Activate inter-frequency
service based handover)
108 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
actMFBI (Activate MFBI
support)
actPMRIP (Activate RIP per
PRB counter)
actPubSafetyBearers (Activate
public safety bearers)
actRedirVoLte (Activate
redirect VoLTE)
actSrvccToGsm (Activate
SRVCC to GSM)
actSrvccToWcdma (Activate
SRVCC to WCDMA)
actUlSpsPrbSelection
(Activate UL SPS PRB
allocation start position
selection)
actUlSpsUESelectionCCEBas
e (Activate UL SPS UE
selection based on CCE
consumption)
actVoLteCallSteering (Activate
VoLTE call steering)
calibrationEnabled (Calibration
Enabled Flag)
calibrationParameters
(Calibration Parameters)
calibrationSet (Calibration Set)
csBIAPcellA3Reuse (CSBIA
Pcell A3 Reuse)
csBIAThreshold (CSBIA
Threshold)
deltaSinrPercentSpsMcsUpgra
de (SINR offset stated in
percentage for UL SPS MCS
upgrade)
deltaSinrSpsInitialMcs (SINR
offset for UL SPS initial MCS
selection)
dlInterferenceBFWeightSet
(Beamforming Weight for
Downlink Interference)
dlOlqcDeltaCqiMax (Maximum
CQI offset for DL OLQC)
DN181051332 Issue: 01 © 2018 Nokia 109

SRAN and LTE
dlSectorBFWeightCusProf
weight customized profile)
dlSectorBFWeightProf
weight profile)
dlSectorBFWeightProfConfig
weight profile config)
dynamicSchedConfig
(Dynamic scheduler
configuration)
m2ResetTimer (Timer M2
Reset Wait For Response)
m2SetupRspTimer (Timer M2
Setup Wait For Response)
maxM2ResetRetry (Max. M2
Reset retries)
maxM2SetupRetry (Max. M2
Setup retries)
maxeNBConfigUpdateRetry
(Max. eNB Configuration
Update retries)
mutingPatternCheckPeriod
(Muting Pattern Checking
Period)
nSpsDTX (Uplink SPS DTX
detection number)
numTxWithHighNonGbr
(Number of sampled
subframes with High Non-GBR
traffic)
p0UePuschSps (Power offset
for SPS UE PUSCH TX power
calculation)
pdcchUlDlPrio (PDCCH LA UL
DL priorities)
preventPsHOtoWcdma
(Prevent PS-HO to WCDMA)
prioUciOnlyUl (Scheduling
priority of UCI only UL report)
prohibitPsHOtoTdscdma
(Prohibit PS-HO to TD-
SCDMA)
110 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
srsMaxUpPts (SRS act/deact
of use of maximum bandwidth
on UpPTS)
systemInformationListWCDMA
(System information list
WCDMA)
tS1RelCanTd (S1 Handover
Cancel Supervision Timer for
HO to TD-SCDMA)
tS1RelOvDeltTd (Delta For
Supervision Timer For
Execution HO TD-SCDMA)
tS1RelPrepTd (Supervision
Timer For Preparation HO To
TD-SCDMA)
ulMaxSpsRetry (Uplink SPS
activation retry number)
ulSpsMaxExplicitReleaseRetry
(Uplink maximum SPS Explicit
release retry number)
ulsSrelFilterCst (Filtering
Constant Relative Signal
Strength)
All parameters under MRBTS/LNBTS/LNMCE/MBSF The parameters are

MRBTS/LNBTS/LNMCE/MBS NSYNCAREA_FDD or unchanged but the MO is
FNSYNCAREA MRBTS/LNBTS/LNMCE/MBSF divided into technology-specific
NSYNCAREA_TDD variants.
All parameters under MRBTS/LNBTS/LNMCE/MBSF The parameters are
MRBTS/LNBTS/LNMCE/MBS NSYNCAREA_FDD/MBSFN_F unchanged but the MO is
FNSYNCAREA/MBSFN DD or divided into technology-specific
MRBTS/LNBTS/LNMCE/MBSF variants.
NSYNCAREA_TDD/MBSFN_T
DD
All parameters under MRBTS/LNBTS/LNCEL/LNCE The parameters are
MRBTS/LNBTS/LNCEL/APUC L_FDD/APUCCH_FDD or unchanged but the MO is
CH MRBTS/LNBTS/LNCEL/LNCE divided into technology-specific
L_TDD/APUCCH_TDD variants.
All parameters under MRBTS/LNBTS/LNCEL/LNCE The parameters are
MRBTS/LNBTS/LNCEL/MPUC L_FDD/MPUCCH_FDD or unchanged but the MO is
CH MRBTS/LNBTS/LNCEL/LNCE divided into technology-specific
L_TDD/MPUCCH_TDD variants.
Parameters in MRBTS/MHA MRBTS/EQM/APEQM/ALD/LN Antenna Line Devices are
A configured using a different
concept than in previous
releases.
Parameters in MRBTS/RET MRBTS/EQM/APEQM/ALD/RA Antenna Line Devices are
EU or RETU configured using a different
releases.
DN181051332 Issue: 01 © 2018 Nokia 111

SRAN and LTE
Parameters in MRBTS/ANTL MRBTS/EQM/APEQM/RMOD/ Antenna Line Devices are
ANTL configured using a different
releases. In particular, antId is
no longer used to identify
antennas.
Parameters in MRBTS/EQM/APEQM/CABIN -
MRBTS/BBMOD ET/BBMOD
Parameters in MRBTS/RMOD MRBTS/EQM/APEQM/RMOD Alarm line configuration is
or moved into EAC_IN and
MRBTS/EQM/APEQM/CABIN EAC_OUT.
ET/RMOD/EAC_IN or
MRBTS/EQM/APEQM/CABIN
ET/RMOD/EAC_OUT
Parameters in MRBTS/MNL/MNLENT/FEATC Most parameters are moved
MRBTS/BTSSCL ADM or under the management
MRBTS/MNL/MNLENT/FMCA subtree, only parameter
DM btsName is moved to the top
level MRBTS object. Activation
parameters are moved to
FEATCADM.
Parameters in MRBTS/MNL/MNLENT/CELL The way that cells are mapped
MRBTS/BTSSCL/LCELL MAPPING/LCELL to devices has changed. In
particular, resourceList is
no longer used, and is
replaced by
CHANNELGROUP objects.
Parameters in MRBTS/EQM/APEQM/CABIN Detected values are separated
MRBTS/BBMOD ET/BBMOD and their _R from configuration values into
equivalents separate object trees EQM and
EQM_R
Parameters in MRBTS/SFP MRBTS/EQM_R/APEQM_R/C Detected SFP values are split
ABINET_R/BBMOD_R/SFP_R according to the type of unit
or they are from.
MRBTS/EQM_R/APEQM_R/C
ABINET_R/SMOD_R/SFP_R
or
MRBTS/EQM_R/APEQM_R/R
MOD_R/SFP_R
Parameters in MRBTS/MNL/MNLENT/BBAD Baseband pool configuration
MRBTS/BBPOOL M/BBPOOL parameters are moved into the
MNL subtree.
Parameters in MRBTS/MNL/MNLENT/PMCA Administration configuration
MRBTS/PMCADM DM parameters are moved into the
MNL subtree.
Parameters in MRBTS/MNL/MNLENT/SECA Security administration
MRBTS/SECADM DM configuration parameters are
moved into the MNL subtree.
Sync-related parameters in MRBTS/MNL/MNLENT/SYNC/ Synchronization configuration
MRBTS/SMOD and sub- CLOCK parameters are moved to the
objects SYNC/CLOCK object.
112 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
Parameter groups under MRBTS/MNL/MNLENT/TEST Self-test configuration
MRBTS/TEST parameters are moved into the
MNL subtree.
Parameters in MRBTS/MNL/MNLENT/TRBLC Troubleshooting configuration
MRBTS/TRBLCADM ADM parameters are moved into the
MNL subtree.
The following parameters from MRBTS/MNL or Reported values for
MRBTS: MRBTS/MNL/MNL_R management data are moved
to MNL_R, Configuration
cmSyncCheckPeriod values are moved to MNL.
(Configuration data
synchronization check period)
validatePlanAgainstDetectedH
W (Validate plan against
detected hardware)
cmSyncCheck (Configuration
data synchronization check)
configDataRevisionNumber
(Configuration data revision
number)
sharedRfTechnologies (Shared
RF technologies)
The following parameters from MRBTS/MNL/MNLENT/FEATC Activation parameters are

MRBTS: ADM moved into the MNL tree under
FEATCADM.
actAldSwUpdate (Activate ALD
software update)
actTransportConfigFallback
(Activate transport
configuration fallback)
Table 32 Detected hardware parameters that may differ from their commissioned
values
MO Class Parameter Parameter Full name Reason(s) for
abbreviation difference from
commissioned value
MRBTS/EQM_R/APE vswrMinorThreshold VSWR minor alarm VSWR Tuning
QM_R/RMOD_R/ANT threshold thresholds update.
L_R
vswrMajorThreshold VSWR major alarm
threshold
MRBTS/EQM_R/APE serialNumber Serial number Value updated due to
QM_R/ALD_R automatic Hardware
Replacement with a
device of the same
product code. Value
added/updated due to
enabled feature
LTE2403: MHA Auto
Commissioning.
DN181051332 Issue: 01 © 2018 Nokia 113

SRAN and LTE
values (Cont.)
commissioned value
productCode Product code Value added/updated
due to enabled feature
controlProtocol Control protocol LTE2403: MHA Auto
mhaType MHA Type Commissioning.
MRBTS/EQM_R/APE angle Angle Read only parameter -

QM_R/ALD_R/RETU_ Setting parameter
R antBandList Antenna band list values failed due to
antBeamwidth Antenna beamwidth hardware limitations.
antFreqBand Antenna operating
frequency band
antOperGain Antenna operation
gain
antBearing Antenna bearing
antSerial Antenna serial number
baseStationID Base station ID
installDate Installation date
installerID Installer ID
maxAngle Max angle
mechanicalAngle Mechanical angle
minAngle Min angle
subunitNumber Subunit number
sectorID Sector ID
antModel Antenna model
number
MRBTS/EQM_R/APE antAltitude Antenna altitude Read only parameter -
QM_R/ALD_R/RAEU_ Setting parameter
R antBandList Antenna band list values failed due to
antBeamwidth Antenna beamwidth hardware limitations.
antFreqBand Antenna operating
frequency band
antOperGain Antenna operation
gain
antLatitude Antenna latitude
antLongitude Antenna longitude
number
114 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
values (Cont.)
commissioned value
mechanicalAngle Mechanical angle
sectorID Sector ID
MRBTS/EQM_R/APE antBandList Antenna band list Read only parameter -
QM_R/ALD_R/LNA_R Setting parameter
antBeamwidth Antenna beamwidth values failed due to
antFreqBand Antenna operating hardware limitations.
frequency band Value added/updated
due to enabled feature
antOperGain Antenna operation LTE2403: MHA Auto
gain Commissioning.
number
gain Mast head amplifier
gain
sectorID Sector ID
MRBTS/EQM_R/HWT firstEndpointDN First endpoint runtime Value added/updated
OP_R/LOGLINK_R distinguished name in due to enabled feature
(LOGLINKs that runtime view LTE2403: MHA Auto
contain Distinguished Commissioning.
Name of an ANTL secondEndpointDN Second endpoint
object, ALD object or runtime distinguished
LNA object) name in runtime view
loglinkType Logical link type
9.3 LTE3296/SR001527 system impact

LTE3296/SR001527: Harmonized Object Model for SRAN and LTE impact on network
management tools

There are no interdependencies between the LTE3296/SR001527: Harmonized Object
Model for SRAN and LTE feature and any other feature.
DN181051332 Issue: 01 © 2018 Nokia 115

SRAN and LTE
The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature has no

impact on interfaces.

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature impacts
network management tools as follows:
• WebUI Element Manager
– The WebUI EM will display the new MOC tree in the parameter view

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature has no
impact on system performance or capacity.
9.4 LTE3296/SR001527 reference data

LTE3296/SR001527: Harmonized Object Model for SRAN and LTE requirements and
sales information
Software requirements
Table 33 LTE3296/SR001527 software requirements
FDD TDD
NetAct not supported not supported
SBTS SBTS17 SBTS17
BSC support not required support not required
RNC support not required support not required
Hardware requirements
This feature has no hardware requirements
116 © 2018 Nokia DN181051332 Issue: 01

SRAN and LTE
Faults and reported alarms

There are no faults related to the LTE3296/SR001527: Harmonized Object Model for
SRAN and LTE feature.

There are no measurements or counters related to the LTE3296/SR001527: Harmonized
Object Model for SRAN and LTE feature.

There are no key performance indicators related to the LTE3296/SR001527: Harmonized
Object Model for SRAN and LTE feature.
Parameters
There are no parameters directly related to the LTE3296/SR001527: Harmonized Object
Model for SRAN and LTE feature.
An overview of the parameter changes is in the Functional Description of this feature. An
up-to-date list of new and moved parameters can be found in the reference document
FDD-LTE BTS Parameters or TDD-LTE BTS Parameters, depending on the technology
used.
Sales information
Table 34 LTE3296/SR001527 sales information
DN181051332 Issue: 01 © 2018 Nokia 117

LTE3303: Enhanced VoLTE, CA, and RF Quality LTE17A Operability Features
Monitoring
10 LTE3303: Enhanced VoLTE, CA, and RF

Quality Monitoring
The LTE3303: Enhanced VoLTE, CA, and RF Quality Monitoring feature introduces new
counters and KPIs in the following areas:
• Voice over LTE (VoLTE)
• Carrier aggregation (CA)
• Radio frequency (RF) quality monitoring.

The LTE3303: Enhanced VoLTE, CA, and RF Quality Monitoring feature enables the
operator to monitor the LTE RAN network in more detail.

The LTE3303: Enhanced VoLTE, CA, and RF Quality Monitoring feature introduces
several new counters in a few categories. For more information, see the reference data
section.

The LTE3303: Enhanced VoLTE, CA, and RF Quality Monitoring feature has no impact
on features, interfaces, network management tools, and system performance and
capacity.

Requirements
FDD TDD
118 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3303: Enhanced VoLTE, CA, and RF Quality
Monitoring
FDD TDD
NetAct 17.8 17.8
g Note: Currently, counters introduced by LTE3303 are supported only on AirScale BTS.
Alarms
There are no alarms related to the LTE3303: Enhanced VoLTE, CA, and RF Quality
Monitoring feature.
Table 36 E-RAB release due to inter-RAT handovers to UTRAN or GERAN counters
introduced by LTE3303
Counter ID Counter name Measurement
M8006C303 Total number of released E-RABs due 8006 - LTE EPS
to successful IRAT HO to UTRAN Bearer
(ERAB_REL_SUCC_HO_UTRAN)
to successful IRAT HO to UTRAN QCI1 Bearer
(ERAB_REL_SUCC_HO_UTRAN_QCI1)
to successful IRAT HO to UTRAN QCI5 Bearer
( ERAB_REL_SUCC_HO_UTRAN_QCI5)
to successful IRAT HO to GERAN Bearer
(ERAB_REL_SUCC_HO_GERAN)
to successful IRAT HO to GERAN QCI1 Bearer
(ERAB_REL_SUCC_HO_GERAN_QCI1)
to successful IRAT HO to GERAN QCI5 Bearer
(ERAB_REL_SUCC_HO_GERAN_QCI5)
LTE3303
M8006C309 E-RAB releases due to eNB Initiated 8006 - LTE EPS
Global S1 Reset Bearer
(ERAB_REL_ENB_INI_S1_GLOB_RESET)
M8006C310 E-RAB releases due to MME Initiated 8006 - LTE EPS
Global S1 Reset Bearer
(ERAB_REL_MME_INI_S1_GLOB_RESET)
DN181051332 Issue: 01 © 2018 Nokia 119

Monitoring
LTE3303 (Cont.)
M8006C311 E-RAB releases due to eNB Initiated 8006 - LTE EPS
Partial S1 Reset Bearer
(ERAB_REL_ENB_INI_S1_PART_RESET)
M8006C312 E-RAB releases due to MME Initiated 8006 - LTE EPS
Partial S1 Reset Bearer
(ERAB_REL_MME_INI_S1_PART_RESET)
M8006C313 E-RAB releases due to S1 Outage 8006 - LTE EPS
(ERAB_REL_S1_OUTAGE) Bearer
M8006C314 E-RAB releases due to double S1 8006 - LTE EPS
detected (ERAB_REL_DOUBLE_S1) Bearer
M8006C315 E-RAB releases due to double S1 8006 - LTE EPS
detected QCI1 Bearer
(ERAB_REL_DOUBLE_S1_QCI1)
Table 38 VoLTE PRB usage counter introduced by LTE3303
M8011C208 Number of UL PRBs Used for VoLTE 8011 - LTE Cell
(PRB_USED_UL_VOLTE) Resource
Table 39 HARQ BLER counters introduced by LTE3303
M8026C273 Total number of Initial HARQ 8026 - LTE QoS
Transmission for SRB in Downlink
(TOT_N_INI_HARQ_TX_SRB_DL)
Transmission for nonGBR in Downlink
(TOT_N_INI_HARQ_TX_NONGBR_DL)
M8026C275 Total number of Failed Initial HARQ 8026 - LTE QoS
Transmission for SRB in Downlink
(TOT_N_FAIL_INI_HARQ_TX_SRB_DL)
Transmission for nonGBR in Downlink
(TOT_N_F_INI_HARQ_TX_NONGBR_DL)
M8026C277 Total number of NO Feedback for 8026 - LTE QoS
Initial HARQ Transmission for SRB in
Downlink (T_N_NO_FB_INI_HARQ_TX_SRB_DL)
Initial HARQ Transmission for nonGBR
in Downlink
(T_N_NO_FB_INI_HARQ_TX_NGBR_DL)
Transmission for GBR excluding VoLTE
in Downlink (TOT_N_INI_HARQ_TX_GBR_DL)
Transmission for VoLTE in Downlink
(TOT_N_F_INI_HARQ_TX_VOLTE_DL)
120 © 2018 Nokia DN181051332 Issue: 01

Monitoring
Table 39 HARQ BLER counters introduced by LTE3303 (Cont.)
Transmission for GBR excluding VoLTE
in Downlink
(TOT_N_F_INI_HARQ_TX_GBR_DL)
Initial HARQ Transmission for VoLTE
in Downlink
(T_N_NO_FB_INI_HARQ_TX_VOLTE_DL)
Initial HARQ Transmission for GBR
excluding VoLTE in Downlink
(T_N_NO_FB_INI_HARQ_TX_GBR_DL)
Table 40 UE context release counters introduced by LTE3303
M8013C76 eNB initiated UE Context releases 8013 - LTE UE
with radio network layer cause State
"Inter-RAT redirection" due to
coverage reasons
(UE_CTX_REL_ENB_RNL_IRAT_RED_CO)
M8013C77 eNB initiated UE Context releases due 8013 - LTE UE
to Global S1 Reset State
(UE_CTX_REL_ENB_GLOB_S1_RESET)
to Partial S1 Reset State
(UE_CTX_REL_ENB_PART_S1_RESET)
to S1 Outage State
(UE_CTX_REL_ENB_S1_OUTAGE)
M8013C80 MME initiated UE Context releases due 8013 - LTE UE
to Global S1 Reset State
(UE_CTX_REL_MME_GLOB_S1_RESET)
M8013C81 MME initiated UE Context releases due 8013 - LTE UE
to Partial S1 Reset State
(UE_CTX_REL_MME_PART_S1_RESET)
M8013C82 MME Initiated UE Context releases due 8013 - LTE UE
to detected double S1 State
(UE_CTX_REL_DOUBLE_S1)
Table 41 VoLTE TTI bundling counters introduced by LTE3303
M8011C209 Number of TTI Bundling Switch on 8011 - LTE Cell
attempts (TTI_BUNDLING_SWITCH_ON_ATTS) Resource
M8011C210 Number of TTI Bundling Switch on 8011 - LTE Cell
successes Resource
(TTI_BUNDLING_SWITCH_ON_SUCCS)
M8011C211 Number of TTI Bundling Switch off 8011 - LTE Cell
attempts (TTI_BUNDLING_SWITCH_OFF_ATTS) Resource
DN181051332 Issue: 01 © 2018 Nokia 121

Monitoring
Table 41 VoLTE TTI bundling counters introduced by LTE3303 (Cont.)
M8011C212 Number of TTI Bundling Switch off 8011 - LTE Cell
successes Resource
(TTI_BUNDLING_SWITCH_OFF_SUCCS)
M8011C215 Number of UL PRBs used for TTI 8011 - LTE Cell
Bundling (PRB_USED_UL_TTIB) Resource
Table 42 Carrier aggregation (CA) downlink deconfiguration counters introduced by
LTE3303
M8011C213 Downlink CA Deconfiguration Attempts 8011 - LTE Cell
(DL_CA_DECONFIG_ATT) Resource
M8011C214 Downlink CA Deconfiguration Successes 8011 - LTE Cell
(DL_CA_DECONFIG_SUCC) Resource
Table 43 PMQAP profile counters introduced by LTE3303
M8048C9 E-RABs attempted to release due to 8048 - LTE ERAB
outgoing Intra LTE Handover Statistics per
(ERAB_REL_INTRA_LTE_HO_ATT_PR) PMQAP Profile
M8048C10 E-RABs released due to successful 8048 - LTE ERAB
outgoing Intra LTE Handover Statistics per
(ERAB_REL_INTRA_LTE_HO_SUCC_PR) PMQAP Profile
M8048C8 E-RABs All Abnormal releases per 8048 - LTE ERAB
Profile Statistics per
(ERAB_REL_ALL_ABNORMAL_PROFILE) PMQAP Profile
M8048C3 E-RABs Abnormal releases per Profile 8048 - LTE ERAB
(ERAB_REL_ABNORMAL_ACT_PROFILE) Statistics per
PMQAP Profile
Parameters
object structure
PRB utilization cfgPRBUtilThre PMCCP — common
threshold shold
Performance pmCCPId PMCCP — common
Monitoring Counters
Configuration
parameters
identifier
Sales information
122 © 2018 Nokia DN181051332 Issue: 01

Monitoring
DN181051332 Issue: 01 © 2018 Nokia 123

LTE3333: Per Call Measurement Data (PCMD) LTE17A Operability Features
11 LTE3333: Per Call Measurement Data (PCMD)

09/20/2017 System Impact The section Impact on system performance and
capacity was updated. Notes about CPU usage rise
and BTS capacity reduction when PCMD set of
features is activated was added.
Per call measurement data (PCMD) is a new solution for LTE network monitoring and
maintenance. Specific PCMD features provide sub-records focused on the bearer, carrier
aggregation, key elements of the call, as well as RRC connection failures and UE
measurement reports.
Figure 21 PCMD features distribution per release
FL17A /TL18
LTE3333-PerCallMeasurementData(PCMD)
LTE3356-PCMD
LTE3336-PCMD LTE3357-PCMD
LTE3334-PCMD LTE3335-PCMD RRCConnection
PerCellReport Measurement
PerBearerReport CAReport Establishment
Extension Report
Failures
The LTE3333: Per Call Measurement Data (PCMD) feature introduces the PCMD

concept in the LTE network.

The LTE3333: Per Call Measurement Data (PCMD) feature provides the following
benefits:
• Evaluating UE performance by collecting PCMD data related to failures caused by
user equipment
• Quickly determining failure scenarios by collecting PCMD data associated with a
given call/connection
• Reducing the RF optimization and engineering cost by analyzing RF coverage and
signal strength at the end of calls

Functional overview
PCMD is collected in the eNB for each UE entering the cell, and is sent via the
transmission control protocol (TCP) to the network layer 3 data collector (L3DC). The
L3DC generates summary report per call/per visited cell and forwards it to network
PCMD correlation (NPC). NPC integrates eNB PCMD either with mobility management
entity (MME) PCMD or with cloud mobility manager (CMM) PCMD. The CMM performs
124 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3333: Per Call Measurement Data (PCMD)
the MME/SGSN functions within the packet core network. Once integrated, the data is
sent to the operator's tool and network performance optimizer (NPO). The NPO applies
advanced analytics to per call measurement data.
g Note: For detailed information regarding per call measurement data please see NPC
PCMD Reference Guide
Figure 22 Per call measurement data (PCMD) overview
MME
fALUorCMM Operator
Tools
IM
SI
M
/IM ield
M
Ef
EI s
+
NPC
ng
mi
ea
Str
Correlated 9959NPO
Proprietaryformat PCMDrecords
(includingPCMDfields)
1minutefiles
L3DC
AirScale,
FSMr3 FSMPCMD
collection
PCMDAnalysisGUI
KPIAnalysisGUI
integration
PM/PCMDcorrelation
Operator
Tools
g Note:
• L3DC and ‘Operators tools’ compatibility has to be confirmed individually for each
LTE project.
• Support for PCMD forwarding to other tools like Traffica is planed in a future
release.
The LTE3333: Per Call Measurement Data (PCMD) feature provides the information

related to advanced LTE network optimization and troubleshooting.
For types of measurements related to LTE3333: Per Call Measurement Data (PCMD)
feature, see Types of measurements related to LTE3333: Per Call Measurement Data
(PCMD) feature.

The LTE3333: Per Call Measurement Data (PCMD) feature impacts the following
features:
DN181051332 Issue: 01 © 2018 Nokia 125

• LTE955: IPv6 for Management Plane

If the LTE955: IPv6 for Management Plane feature is activated, the IP address
towards PCMD-CE can be use either in IPv4 or in IPv6 format.
• LTE1509: Call Session Logging (CSL) for Flexi Multiradio BTS
The LTE3333: Per Call Measurement Data (PCMD) and the LTE1509: Call Session
Logging (CSL) for Flexi Multiradio BTS feature are mutually exclusive.
The LTE3333: Per Call Measurement Data (PCMD) feature impacts interfaces as
follows:
• A new interface between an eNB and L3DC is added: ASN.1 over TCP.

The LTE3333: Per Call Measurement Data (PCMD) feature has no impact on network
management tools.

Activation of PCMD feature set:
• LTE3333: Per Call Measurement Data (PCMD)

• LTE3334: Per Call Measurement Data (PCMD) – Per Bearer Report
• LTE3335: Per Call Measurement Data (PCMD) – CA Report
• LTE3336: Per Call Measurement Data (PCMD) – Per Call Report Extension
• LTE3356: PCMD – RRC Connection Establishment Failures
• LTE3357: PCMD – Measurement Report
impacts system performance and capacity as follows:
• CPU usage rises when PCMD feature is activated due to BTS operation and
maintenance interface (BTSOM) processing.
g Note: When PCMD is enabled, BTS capacity may be reduced up to 20% compared to
regular capacity. It is recommended to observe C-Plane and U-Plane overload counters
when PCMD is enabled.

Requirements
Table 47 LTE3333/3334/3335/3336/3356/3357 hardware and software requirements
FDD TDD
System release FDD-LTE 17A TD-LTE 18
Flexi Multiradio 10 BTS FL17A TL18
Flexi Multiradio 10 Indoor BTS Not supported TL18
126 © 2018 Nokia DN181051332 Issue: 01

(Cont.)
FDD TDD
Nokia AirScale BTS FL17A TL18
Flexi Zone BTS FL17A TL18
Flexi Zone Access Point FL18 TL18
Cloud Flexi Zone Controller FL18 TL18
NetAct NetAct 17.2 NetAct 18
Alarms
Table 48 Alarms modified by LTE3333
Alarm ID Alarm name
7652 BASE STATION NOTIFICATION
For alarms descriptions, see LTE Operating Documentation/Reference/Alarms and

Faults
Table 49 Existing BTS faults related to LTE3333
Fault Fault name Reported alarms
ID
Alarm Alarm name
ID
6263 Failure in trace session 7652 BASE STATION NOTIFICATION
For faults descriptions, see LTE Operating Documentation/Reference/Alarms and Faults
Types of measurements related to LTE3333: Per Call Measurement Data (PCMD)

feature
Table 50 Types of measurements related to LTE3333: Per Call Measurement Data

(PCMD):
Measurement data Description
Call Start/End Time Start/end time of the call
Call Final Class For example release reason or reason for
outgoing HO
The number of TTIs UE scheduled The transmission time interval defines the
duration of a transport block
DN181051332 Issue: 01 © 2018 Nokia 127

Table 50 Types of measurements related to LTE3333: Per Call Measurement Data

(PCMD): (Cont.)
Initial/Residual BLER Ratio of the number of incorrectly received
blocks to the total number of blocks transferred
Average channel quality indicator (CQI) value In high-speed downlink packet access, this
indicates the relative instantaneous channel
quality that is calculated using the transmission
time interval and instantaneous and relative
channel throughput
Round-trip delay measurements Measurements related to round-trip delay
Signal-to-interference-plus-noise ratio (SINR) The ratio of the average received modulated
carrier power to the sum of the average co-
channel interference power (that is signals
other than the desired signal) and the noise
power from other sources (typically thermal
noise, modelled as Additive White Gaussian
Noise (AWGN)), which are received
simultaneously.
Transmitted data volume Volume of transmitted data
Average power headroom Power headroom indicates how much
transmission power is left for a UE to use in
addition to the power being used by the current
transmission.
UE release information UE release information
Physical resource block (PRB) usage A unit of transmission resource consisting of 12
sub- carriers in the frequency domain and 1
timeslot (0.5 ms) in the time domain.
Mobility failure cause Mobility failure root cause definition
Mobility trigger reason Mobility trigger reason
RRC establishment cause The RRC protocol handles the Layer 3 control
plane signalling by which the E-UTRAN
controls the UE behaviour. The RRC protocol
supports the transfer of both common and
dedicated Non-Access Stratum information. It
covers a number of functional areas including
System Information (SI) broadcasting,
connection control including handover within
LTE, network-controlled inter-Radio Access
Technology (RAT) mobility and measurement
configuration and reporting.
L3 message timing Network layer message timing
UE category Category information is used to allow the eNB
to communicate effectively with all the UEs
connected to it. The UE category defines a
combined uplink and downlink capability
HO target cell ID Hand over target cell identifier
Source/serving/target cell type Source/serving/target cell type
128 © 2018 Nokia DN181051332 Issue: 01

There are no measurements or counters related to the LTE3333: Per Call Measurement

Data (PCMD) feature.

There are no key performance indicators related to the LTE3333: Per Call Measurement
Data (PCMD) feature.
Parameters
Full name Abbreviated name Managed Parent structure FDD/TDD
object
Activate PCMD actPCMDReport LNBTS - Common
Report
Activate PCMD actPCMDReporting MTRACE - Common
Reporting
object
SDL activation actSdl LNBTS - Common
flag
3rd party cell extCellTraceRep CTRLTS extTraceRepo Common
trace reporting rting
NetAct IP address netActIpAddr CTRLTS - Common
Job type jobType MTRACE - Common
Local cell lcrId MTRACE - Common
resource
identifier
Trace collection tceIpAddress MTRACE - Common
entity IP address
Activate UE actUeThroughputMR MTRACE - Common
throughput
measurement
reports
Cell TA tracing cellTaTracing MTRACE cellVendorSp Common
ecTracing
For parameters descriptions, see LTE Operating Documentation/Reference/Parameters
Sales information
Application software (ASW) Pool license No
DN181051332 Issue: 01 © 2018 Nokia 129

11.5 Activating LTE3333

Instructions to activate the LTE3333: Per Call Measurement Data (PCMD) feature using
the BTS Site Manager
Before you start

• Preconfiguration
– The system is up and running and there are some active users equipment in the
cell.
– Two or more PCMD trace sessions for different cells are running and sending
PCMD data to the layer 3 data collector (L3DC).
– The SDL activation flag(actSdl)parameter is set to false.
– The CTRLTS managed object class exists and is configured.
Object path: MRBTS ► LNBTS ► CTRLTS
– The 3rd party cell trace reporting(extCellTraceRep)
parameter is set to true.
Object path: MRBTS ► LNBTS ► CTRLTS ► 3rd party trace reporting
– The maximum number of the UEs traced per cell is configured (for example,
Cell maximum active UEs traced(cellMaxActiveUEsTraced)is
set to 100).
Object path: MRBTS ► LNBTS ► CTRLTS ► MTRACE
– The Activate UE throughput measurement
reports(actUeThroughputMR)is set to false
– E-UTRAN trace identifier is configured.
Object path: MRBTS ► LNBTS ► CTRLTS ► MTRACE ► E-UTRAN trace
identifier
– The Cell TA tracing(cellTaTracing)parameter is set to false.
Object path: MRBTS ► LNBTS ► CTRLTS ► MTRACE ► Cell Vendor
Specific Tracing
Procedure
130 © 2018 Nokia DN181051332 Issue: 01

Sub-steps
left.
state of the BTS.
4 Set the Activate PCMD Report(actPCMDReport)value to true.
Sub-steps
• If the BTS has already been commissioned, select Only changes.
Result
Expected outcome
The PCMD trace session is started. The PCMD records for already existing and
incoming UEs are collected until the maximum number of traced UEs is reached.
Further information
This procedure is valid for the following PCMD features:
• LTE3334: PCMD - Per Bearer Report
• LTE3335: PCMD - CA Report
• LTE3336: PCMD - Per Call Report Extension
• LTE3356: PCMD - RRC Connection Failure
DN181051332 Issue: 01 © 2018 Nokia 131

• LTE3357: PCMD - Measurement Report
11.6 Deactivating LTE3333

Instructions to deactivate the LTE3333: Per Call Measurement Data (PCMD) feature
Before you start

– Deactivation procedure does not cause downtime, and the feature can be
deactivated at any time of the day.
• The system is up and running and there are some active UEs in the cell.
Procedure
Sub-steps
left.
state of the BTS.
4 Set the Activate PCMD Report(actPCMDReport)value to false.
Sub-steps
132 © 2018 Nokia DN181051332 Issue: 01

Result
Expected outcome
All of the PCMD trace sessions are stopped. The eNB sends stopTrace messages to
the L3DC for each trace session. Non-PCMD trace session are continuing to send data
as configured.
Further information
11.7 Deactivating a single LTE3333 trace session

Instructions to deactivate the LTE3333: Per Call Measurement Data (PCMD) feature
Before you start

– Deactivation procedure does not cause downtime, and the feature can be
deactivated at any time of the day.
– The system is up and running and there are some active UEs in the cell.
– Two or more PCMD trace sessions for different cells are running and sending
PCMD data to the layer 3 data collector (L3DC).
– The SDL activation flag(actSdl)parameter is set to false.
– The CTRLTS managed object class exists and is configured.
Object path: MRBTS ► LNBTS ► CTRLTS
DN181051332 Issue: 01 © 2018 Nokia 133

– The 3rd party cell trace reporting(extCellTraceRep)

parameter is set to true.
Object path: MRBTS ► LNBTS ► CTRLTS ► 3rd party trace reporting
– The maximum number of the UEs traced per cell is configured (for example,
Cell maximum active UEs traced(cellMaxActiveUEsTraced)is
set to 100).
– The Activate UE throughput measurement
reports(actUeThroughputMR)is set to false
– E-UTRAN trace identifier is configured.
Object path: MRBTS ► LNBTS ► CTRLTS ► MTRACE ► E-UTRAN trace
identifier
– The Cell TA tracing(cellTaTracing)parameter is set to false.
Object path: MRBTS ► LNBTS ► CTRLTS ► MTRACE ► Cell Vendor
Specific Tracing
Procedure
Sub-steps
left.
state of the BTS.
3 Proceed to the Send Parameters page.
Sub-steps
134 © 2018 Nokia DN181051332 Issue: 01

Result
Expected outcome
The PCMD trace session for the chosen cell is stopped. The eNB sends the
stopTrace message to the L3DC for the chosen cell. The other PCMD trace sessions
continue to send PCMD trace data to the L3DC. Non-PCMD trace sessions are
continuing to send trace data as configured.
Further information
DN181051332 Issue: 01 © 2018 Nokia 135

LTE3334: Per Call Measurement Data (PCMD) - Per LTE17A Operability Features
Bearer Report

- Per Bearer Report
FL17A /TL18
LTE3356-PCMD
Extension Report
Failures
The LTE3334: Per Call Measurement Data (PCMD) – Per Bearer Report feature extends

the LTE3333: Per Call Measurement Data (PCMD) feature with additional data for every
radio bearer (for example, transmission volume, total transmission time, and poor
performance indicators).

In addition to LTE3333: Per Call Measurement Data (PCMD) benefits the LTE3334: Per
Call Measurement Data (PCMD) – Per Bearer Report feature provides the following
benefits:
• PCMD – Per Bearer Report can be used to monitor call performance on a bearer
level (VoIP or video), offering granularity typical of a UE level and allowing to focus
on bearer configuration.

Functional overview
136 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3334: Per Call Measurement Data (PCMD) - Per
Bearer Report
MME
fALUorCMM Operator
Tools
IM
SI
M
/IM ield
M
Ef
EI s
+
NPC
ng
mi
ea
Str
Correlated 9959NPO
1minutefiles
L3DC
AirScale,
FSMr3 FSMPCMD
collection
PCMDAnalysisGUI
KPIAnalysisGUI
integration
PM/PCMDcorrelation
Operator
Tools
g Note:
LTE project.
release.
The LTE3334: Per Call Measurement Data – Per Bearer Report feature provides

measurements/values of every data bearer for every procedure of every user. The eNB
starts collecting and reporting PCM data for every data bearer after the feature has been
activated.
The LTE3334: Per Call Measurement Data – Per Bearer Report feature is always
activated together with the LTE3333: Per Call Measurement Data (PCMD) feature.
For information on types of measurements collected and provided by the LTE3334: Per
Call Measurement Data – Per Bearer Report feature, see Types of measurements
collected and provided by the LTE3334: Per Call Measurement Data – Per Bearer
Report feature.
DN181051332 Issue: 01 © 2018 Nokia 137

Bearer Report

The LTE3334: Per Call Measurement Data (PCMD) – Per Bearer Report feature is
activated when the LTE3333: Per Call Measurement Data (PCMD) is activated.
The LTE3334: Per Call Measurement Data (PCMD) – Per Bearer Report feature impacts
interfaces as follows:
• New interface between eNB and PCMD-CE has added; ASN.1 over TCP

The LTE3334: Per Call Measurement Data (PCMD) – Per Bearer Report feature has no
impact on network management tools.



Requirements
FDD TDD
138 © 2018 Nokia DN181051332 Issue: 01

Bearer Report
(Cont.)
FDD TDD
Alarms
There are no alarms related to the LTE3334: Per Call Measurement Data (PCMD) – Per
Bearer Report feature.

There are no faults related to the LTE3334: Per Call Measurement Data (PCMD) – Per
Bearer Report feature.
Commands
There are no commands related to the LTE3334: Per Call Measurement Data (PCMD) –
Per Bearer Report feature.
Types of measurements collected and provided by the LTE3334: Per Call

Measurement Data – Per Bearer Report feature
Table 56 Types of measurements collected and provided by the LTE3334: Per Call

Measurement Data – Per Bearer Report feature.
Measurement/value Field Description
Bearer ID The unique identifier of the data radio bearer.
Bearer QCI The Quality of Service Class Identifier of the
data radio bearer.
Transmitted Data Volume The number of Kbytes sent over the Radio Link
Control (RLC) interface in a downlink direction.
Received Data Volume The number of kilobytes sent over the RLC in
an uplink direction.
Transmitted PDU volume The total number of Uplink Radio Link Control
Protocol Data Units (UL RLC PDU) Kbytes
received.
DN181051332 Issue: 01 © 2018 Nokia 139

Bearer Report

Measurement Data – Per Bearer Report feature. (Cont.)
Scheduled TTIs
Amount of re-transmissions The number of Kbytes retransmitted in
downlink RLC.

There are no regular measurements or counters related to the LTE3334: Per Call
Measurement Data (PCMD) – Per Bearer Report feature.

Data (PCMD) – Per Bearer Report feature.
Parameters
There are no parameters related to the LTE3334: Per Call Measurement Data (PCMD) –
Per Bearer Report feature.
Sales information
12.5 Activating LTE3334: Per Call Measurement Data

(PCMD) - Per Bearer Report

activated when the LTE3333: Per Call Measurement Data (PCMD) feature is activated.
12.6 Deactivating LTE3334: Per Call Measurement Data

(PCMD) - Per Bearer Report

deactivated when the LTE3333: Per Call Measurement Data (PCMD) feature is
deactivated.
It is also possible to stop all PCMD trace sessions by deleting the corresponding trace
(MTRACE).
140 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3335: Per Call Measurement Data (PCMD) - CA
Report

- CA Report
FL17A /TL18
LTE3356-PCMD
Extension Report
Failures
The LTE3335: Per Call Measurement Data (PCMD) – CA Report feature extends the

LTE3333: Per Call Measurement Data (PCMD) feature with additional data for secondary
cells (SCells) at a UE level in case of carrier aggregation (CA). Such data includes, for
example, average throughput for UEs with a certain number of carrier components
(CCs), average number of CCs that are configured for a certain type of UEs, or
correlations of CA failures with some other UE characteristics.

Call Measurement Data (PCMD) – CA Report feature provides the following benefits:
• allows the customer to monitor CA performance for every single UE and to improve
the CA performance.

Functional overview
DN181051332 Issue: 01 © 2018 Nokia 141

LTE3335: Per Call Measurement Data (PCMD) - CA LTE17A Operability Features
Report
MME
fALUorCMM Operator
Tools
IM
SI
M
/IM ield
M
Ef
EI s
+
NPC
ng
mi
ea
Str
Correlated 9959NPO
1minutefiles
L3DC
AirScale,
FSMr3 FSMPCMD
collection
PCMDAnalysisGUI
KPIAnalysisGUI
integration
PM/PCMDcorrelation
Operator
Tools
g Note:
LTE project.
release.
The LTE3335: Per Call Measurement Data – CA Report feature provides

measurements/values of every configured SCell. In case the same cell is configured
multiple times, a single aggregated record is generated. The eNB starts collecting and
reporting PCM data for every configured SCell after the feature has been activated.
The LTE3335: Per Call Measurement Data – CA Report feature is always activated
together with the LTE3333: Per Call Measurement Data (PCMD) feature.
For information on measurements/values collected and provided by the LTE3335: Per
Call Measurement Data – CA Report feature, see Measurements/values collected and
provided by the LTE3335: Per Call Measurement Data – CA Report feature
142 © 2018 Nokia DN181051332 Issue: 01

Report

The LTE3335: Per Call Measurement Data (PCMD) – CA Report feature is activated
when the LTE3333: Per Call Measurement Data (PCMD) is activated.
The LTE3335: Per Call Measurement Data (PCMD) – CA Report feature impacts
• A new interface between an eNB and PCMD-CE has been added; ASN.1 over TCP

The LTE3335: Per Call Measurement Data (PCMD) – CA Report feature has no impact
on network management tools.



Requirements
FDD TDD
DN181051332 Issue: 01 © 2018 Nokia 143

Report
(Cont.)
FDD TDD
Alarms
There are no alarms related to the LTE3335: Per Call Measurement Data (PCMD) – CA
Report feature.

There are no faults related to the LTE3335: Per Call Measurement Data (PCMD) – CA
Report feature.
Commands
CA Report feature.
Measurements/values collected and provided by the LTE3335: Per Call

Measurement Data – CA Report feature
Table 60 Measurements/values collected and provided by the LTE3335: Per Call

Measurement Data – CA Report feature
Secondary Cell ID for Carrier The cell ID for the secondary cell used for CA.
Aggregation
Number of SCell Configurations This measurement counts the number of CA configuration
procedures that occur during the PCMD collection interval
for this secondary cell.
Number of SCell Deconfigurations This measurement counts the number of CA deconfiguration
SCell Configuration Duration This measurement provides the duration of CA configuration
procedure that occur during the PCMD collection interval for
this secondary cell.
144 © 2018 Nokia DN181051332 Issue: 01

Report
Table 60 Measurements/values collected and provided by the LTE3335: Per Call

Measurement Data – CA Report feature (Cont.)
Number of SCell Activations This measurement counts the number of CA activation
Number of SCell Deactivations The measurement counts the number of CA deactivation
SCell Activation Duration This measurement provides the duration of CA activation
procedure that occur during the PCMD collection interval for
this secondary cell.
Number of CA Activation Failures This measurement counts the number of CA activation
procedure failures that occur during the PCMD collection
interval for this secondary cell.
CA Deactivation Cause This measurement is used to identify the causes of a CA
deactivation attempt.
CA Deconfiguration Cause This measurement is used to identify the causes of a CA
deconfiguration attempt.
Number of Time Transmission This measurement indicates the total number of
Intervals (TTIs) UE Scheduled in transmission time intervals (TTIs) that the UE configured
an SCell with CA was scheduled in an SCell during the PCMD
collection interval.
Number of Hybrid Automatic This measurement indicates the number of DL HARQ
Repeat Request (HARQ) retransmissions for the previous transmissions scheduled by
Retransmissions in SCell the dynamic scheduler (DS) in an SCell for the
CAconfigured UE during the PCMD collection interval.
Average SCell Channel Quality This measurement provides the average CQI received for
Indicator (CQI) the SCell.
Maximum SCell Block Error Rate This measurement is the maximum downlink initial medium
(BLER) access control (MAC) BLER for the initial transmissions
scheduled in the SCell during the PCMD collection interval.
Number of physical resource This measurement provides the number of downlink PRBs
blocks (PRBs) used in SCell that have been used by the user in this SCell during the
PCMD collection interval.
CA Activation Duration with 2/3/4 This measurement provides the total duration of all phases,
DL Carriers where CA is activated with two SCells (2DL/3DL/4DL).
Data Volume Transmitted with This measurement provides the number of Kbytes sent in
2/3/4 DL Carriers the first RLC transmission in a downlink direction during the
PCMD collection interval, when CA is activated with one
SCell (2DL) / two SCells (3DL) / three SCells (4DL).
Amount of Retransmissions with This measurement provides the number of Kbytes during
2/3/4 DL Carriers RLC retransmission in a downlink direction during the
PCMD collection interval, when CA is activated with one
SCell (2DL) / two SCells (3DL) / three SCells (4DL).
UE Carrier Aggregation Capability This value indicates the UE’s band combination capabilities
with respect to CA combination supported by an eNB and
restricted to the CA cell group of the current cell.
DN181051332 Issue: 01 © 2018 Nokia 145

Report

Measurement Data (PCMD) – CA Report feature.

Data (PCMD) – CA Report feature.
Parameters
CA Report feature.
Sales information

(PCMD) - CA Report
The LTE3335: Per Call Measurement Data (PCMD) – CA Report feature is activated

when the LTE3333: Per Call Measurement Data (PCMD) feature is activated.

(PCMD) - CA Report
The LTE3335: Per Call Measurement Data (PCMD) – CA Report feature is deactivated

when the LTE3333: Per Call Measurement Data (PCMD) feature is deactivated.
(MTRACE).
146 © 2018 Nokia DN181051332 Issue: 01

Call Report Extension

- Per Call Report Extension
FL17A /TL18
LTE3356-PCMD
Extension Report
Failures
The LTE3336: Per Call Measurement Data (PCMD) – Per Call Report Extension feature
extends the LTE3333: Per Call Measurement Data (PCMD) feature with additional data
at a UE level. Such data includes, for example, UE capabilities, UE activity information,
information related to enhanced inter-cell interference coordination (eICIC),
discontinuous reception (DRX) statistics, measurements covering all handover (HO)
scenarios.

Call Measurement Data (PCMD) – Per Call Report Extension feature provides the
following benefits:
• allows the customer to analyze, estimate, and troubleshoot issues related to key
elements of the call (handovers, UL throughput, VoLTE) and provides the
measurement foundation for service improvements

Functional overview
DN181051332 Issue: 01 © 2018 Nokia 147

MME
fALUorCMM Operator
Tools
IM
SI
M
/IM ield
M
Ef
EI s
+
NPC
ng
mi
ea
Str
Correlated 9959NPO
1minutefiles
L3DC
AirScale,
FSMr3 FSMPCMD
collection
PCMDAnalysisGUI
KPIAnalysisGUI
integration
PM/PCMDcorrelation
Operator
Tools
g Note:
LTE project.
release.
The LTE3336: Per Call Measurement Data – Per Call Report Extension feature provides

a set of measurements/values at a UE level for every call. The eNB starts collecting and
reporting PCM data after the feature has been activated.
The LTE3336: Per Call Measurement Data – Per Call Report Extension feature is always
activated together with the LTE3333: Per Call Measurement Data (PCMD) feature.
For information on types of measurements collected and provided by the LTE3336: Per
Call Measurement Data – Per Call Report Extension feature, see Types of
measurements collected and provided by the LTE3336: Per Call Measurement Data
(PCMD) – Per Call Report Extension feature.
148 © 2018 Nokia DN181051332 Issue: 01


is activated when the LTE3333: Per Call Measurement Data (PCMD) is activated.
The LTE3336: Per Call Measurement Data (PCMD) – Per Call Report Extension will
provide the measurement Average UL DMRS SINR only after LTE3128: LTE-M is
activated.
The LTE3336: Per Call Measurement Data (PCMD) – Per Call Report Extension will
provide the measurement SRB Only State Transition only after LTE3582: LTE-
M Enhancements I is activated.
impacts interfaces as follows:
• A new interface between an eNB and PCMD-CE has been added; ASN.1 over TCP

has no impact on network management tools.



Requirements
DN181051332 Issue: 01 © 2018 Nokia 149

FDD TDD
Alarms
There are no alarms related to the LTE3336: Per Call Measurement Data (PCMD) – Per
Call Report Extension feature.

There are no faults related to the LTE3336: Per Call Measurement Data (PCMD) – Per
Call Report Extension feature.
Commands
Per Call Report Extension feature.
Types of measurements collected and provided by the LTE3336: Per Call

Measurement Data (PCMD) – Per Call Report Extension feature

Measurement Data (PCMD) – Per Call Report Extension feature
Maximum Medium Access Control This counter is the maximum downlink initial MAC BLER for
(MAC) Block Error Rate (BLER) the initial transmissions scheduled by the dynamic scheduler
(DS) during the PCMD collection interval.
Number of Bad Packet Data Units This measurement is the total number of downlink bad MAC
(PDUs) PDUs for the initial transmissions scheduled for the duration
in which the UE context is handled by the eNB.
Number of Hybrid Automatic This measurement indicates the number of downlink (DL)
Repeat Request (HARQ) HARQ retransmissions for the previous transmissions
Retransmissions scheduled for the UE during the PCMD collection interval.
Redirection Related These measurements indicates the time and statistics about
Statistics/Time the time when the UE was redirected to radio access
150 © 2018 Nokia DN181051332 Issue: 01


Measurement Data (PCMD) – Per Call Report Extension feature (Cont.)
systems other than Evolved Universal Terestrial Radio
Access Network (EUTRAN).
Aggregate Buffer Size These measurements indicates the aggregate values for the
buffer size of different network elements.
Discontinuous Reception (DRX) These measurements provide informations about DRX
Configuration During Handover during HO.
(HO)
Time Transmission Interval (TTI) These measurements provide informations about various
bundling configuration during HO TTI configurations during HO.
Radio Resource Control (RRC) This measurement provide the time when the RRC
Connection Setup Time connection request is received from a UE.
UE Capabilities This measurement indicates the UE capabilities for inter-cell
interference coordination (eICIC), cell specific reference
signal (CRS), interference handling and synchronisation
signal, and common channel interference handling.
DRX Statistics These measurements provide statistics about DRX.
QCI1 scheduling delay These measurements provides QCI1 bearer delay histogram
in DL / uplink (UL) for the duration of a voice over LTE
(VoLTE) call on the serving cell.
g Note: L3DC and ‘Operators tools’ compatibility has to be confirmed individually for
each LTE project.

Measurement Data (PCMD) – Per Call Report Extension feature.

Data (PCMD) – Per Call Report Extension feature.
Parameters
Per Call Report Extension feature.
Sales information
DN181051332 Issue: 01 © 2018 Nokia 151


(PCMD) - Per Call Report Extension
is activated when the LTE3333: Per Call Measurement Data (PCMD) feature is activated.

(PCMD) - Per Call Report Extension
is deactivated when the LTE3333: Per Call Measurement Data (PCMD) feature is
deactivated.
(MTRACE).
152 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3342/SR001534: Improved Combined FM Service
15 LTE3342/SR001534: Improved Combined FM

Service
The LTE3342/SR001534: Improved Combined FM Service feature consists of three main
fault management areas:
• The alignment of faults and alarms to Single Operation and Maintenace (SOAM)
architecture and the harmonization across SBTS and eNB
• The introduction of category alarms (a new alarm scheme)
• The improvement for Single BTS (SBTS) and eNB autonomous recovery actions and
the decrease in number of needed manual reset
15.1 LTE3342/SR001534 benefits

The LTE3342/SR001534: Improved Combined FM Service feature provides the following
benefits:
• The management of multi-RAT network is uniform and easier
• The reduction in number of the manual fault recovery resets executed by the
operator (as a result of increased number of the autonomous fault recovery resets).
Additionally, the operator can choose between the legacy and new alarm scheme and
decide which alarms to use in the network. The new alarm scheme (that is, category
alarms) results in the reduction of alarms reported by SBTS and eNB.
15.2 LTE3342/SR001534 functional description

The LTE3342/SR001534: Improved Combined FM Service feature consists of three main
fault management areas:
• The alignment of faults and alarms to SOAM architecture and the harmonization
across SBTS and eNB
With the LTE3342/SR001534 feature, SBTS and eNB have harmonized common
faults and alarms, in order to fit to the new Single-BTS OAM architecture.
g Note: The eNB can report legacy alarms or a new type of alarms — category alarms.
The SBTS can report only category alarms. The harmonization of alarms is possible for
category alarms when the same failure in eNB and SBTS will be reflected in the same
alarm.
• introduction of category alarms
• improvement for SBTS and eNB autonomous recovery actions and decrease in
number of needed manual reset.
15.2.1 Introduction of category alarms

Before the LTE3342/SR001534 feature, a single fault in the eNB may have resulted in
several disabled/degraded cells and several, separate for each affected cell, alarms.
With category alarms, the operator sees only one alarm and the content of the alarm
DN181051332 Issue: 01 © 2018 Nokia 153

LTE3342/SR001534: Improved Combined FM Service LTE17A Operability Features
shows the corresponding disabled/degraded cells. As a result, the number of alarms is

reduced and the information about the nature of failure detected in the BTS is more
clear.
Category alarms do not replace any legacy alarms — both legacy alarms and new
category alarms remain available in the eNB for the operator. The operator has a choice
if eNB should report legacy alarms or category alarms. Switching between alarm types is
performed using a configuration parameter (Activate Category
Alarms (actCategoryAlarms)). A default value of actCategoryAlarms in eNB is
false (by default, eNB will report legacy alarms). In SBTS only value true of the
parameter is allowed.
Fault name in legacy and category alarms
For some legacy alarms, the group fault name is visible in the alarm, for example, if a
radio fault is detected, the eNB does not report any alarm with an original fault name of
"TX out of order" or "Tuning frequency out of range", but in both cases a "RF Module
failure" name of a group fault is used. Group faults are not applicable to category alarms.
In the example, the original fault names ("TX out of order" or "Tuning frequency out of
range") are visible in the category alarm.
Numbers of category alarms

Category alarms have alarm numbers within the range 7100–7198. The legacy LTE
alarms have numbers within the ranges 7650-7658 and 7401-7426. Most of SRAN
alarms already have characteristics of category alarms, therefore they are retained and
updated. Transport alarms are numbered 61xxx, no matter if legacy alarms or category
alarms are configured. The table below lists all available category alarms.
Table 66 New alarms introduced by LTE3342
Alarm ID Alarm name
7100 BASE STATION HARDWARE PROBLEM
7101 BASE STATION/UNIT AUTONOMOUS RESET NOTIFICATION
7102 BASE STATION RESOURCE BLOCKED BY USER
7103 BASE STATION EXTERNAL ALARM NOTIFICATION
7107 BASE STATION CONNECTIVITY PROBLEM
7108 BASE STATION SYNCHRONIZATION PROBLEM
7109 BASE STATION SECURITY PROBLEM
7110 BASE STATION LICENSE LIMITATION
7111 BASE STATION SOFTWARE PROBLEM
7112 BASE STATION CONFIGURATION PROBLEM
7113 BASE STATION ANTENNA LINE PROBLEM
7114 CELL SERVICE PROBLEM
7115 BASE STATION INFORMATION
7116 BASE STATION SERVICE PROBLEM
Category alarms severity

Category alarm severity depends on how a fault impacts the availability of the cells:
154 © 2018 Nokia DN181051332 Issue: 01

• If a fault causes at least one cell to fail, alarm severity is critical.
• If a fault causes some cells to fail some of them to degrade, alarm severity is critical.
• If a fault causes cell(s) to degrade but not fail, alarm severity is major.
• If a fault not cause any cell to degrade or fail, alarm severity is minor or warning.
Most of minor and warning severity alarms, no matter what is their nature, are reported
as 7115 BASE STATION INFORMATION alarm. It enables the operator to easily filter
out the minor severity issues, for example, faults without impact on services. The 7115
alarm is reported also when a critical hardware problem is detected in BTS but the
hardware doesn't support any cell (for example, redundant, not commissioned radio
module connected to BTS is out of order). The 7101 alarm is always a marked as
warning, and 7102 alarm can be reported with minor severity.
Alarming objects
When the BTS raises category alarms, the following types of alarming objects are
supported:
• Hardware objects (for example, RMOD_R, SMOD_R, BBMOD_R, CABLINK_R)
• Synchronization objects (for example, GNSSE_R, GNSSI_R)
• Service objects (for example, LNBTS, LNCEL)
• Connectivity (for example, GTPU, LNMME)
• MRBTS
Path attribute update

Before the LTE3342/SR001534 feature, an alarm attribute "path" contained
commissioned objects instances ID. If a fault was reported for not commissioned
hardware, the instance was omitted in "path" attribute. With the LTE3342/SR001534
feature, "path" attribute contains runtime (_R) instances IDs, since _R object is created
for both commissioned and non-commissioned hardware modules.
Table 67 Path attribute in category alarms
Path before the LTE3342/SR001534 feature Path after the LTE3342/SR001534 feature
/SMOD-1/opt-rf1/RMOD-2 /SMOD_R-1/opt-rf1/RMOD_R-3
where 2 is RMOD ID in commissioning where 3 is runtime RMOD instance ID
Category alarms attributes

Category alarms contain three new attributes:
• faulty_cells
• degraded_cells
• affected_cells
These attributes will contain IDs of cells affected by the fault. The following parameters
are used as cell ID:
• LNCEL Identifier (lnCelId) as eNB cell ID
• Local Cell Resource ID (lcrId) as WCDMA cell ID
• btsObjId as GSM cell ID
Examples of category alarms

Example 1
DN181051332 Issue: 01 © 2018 Nokia 155

The SBTS that is configured for multi-RAT determines that some of its LTE cells are
faulty, some of its LTE cells are degraded, and some of its WCDMA cells are degraded
as a result of a radio hardware fault. In this scenario, the SBTS reports:
• 7100 BASE STATION HARDWARE PROBLEM alarm
• with alarming object: MRBTS-x/EQM_R-1/APEQM_R-1/RMOD_R-1,
• with event type: Equipment,
• with severity: Critical,
• with fault id: 1907,
• with fault name: TX out of order,
• with attribute: faulty_cells=LTE:1,3,5,
• with attribute: degraded_cells=LTE:2,4; WCDMA:8
Example 2
The eNB determines that some of its cells are faulty and some are degraded as a result
of a radio hardware fault. In this scenario, eNB reports:
• with alarming object: MRBTS-x/EQM_R-1/APEQM_R-1/RMOD_R-1,
• with event type: Equipment,
• with severity: Critical,
• with fault id: 1907,
• with fault name: TX out of order,
• with attribute: faulty_cells=LTE:1,3,5,
• with attribute: degraded_cells=LTE:2,4
Example 3
The SBTS determines that all LTE cells are faulty and some of its WCDMA cells are
degraded as a result of the fault. The SBTS reports alarm with following attributes (not
whole alarm content is shown):
• faulty_cells=LTE:all,
• degraded_cells=WCDMA:8
Example 4
The SBTS determines that all the LTE, WCDMA, and GSM cells/sectors are faulty as a
result of the fault. The SBTS reports with following attributes (not whole alarm content is
shown):
• faulty_cells=LTE:all;WCDMA:all;GSM:all
Example 5
The eNB determines that no cells are affected as a result of the fault. The BTS does not
report faulty_cells and degraded_cells. Instead, the BTS reports alarm with following
attribute (not whole alarm content is shown):
• affected_cells=none
Example 6
156 © 2018 Nokia DN181051332 Issue: 01

The eNB determines that one or more cells are affected, but the fault has only minor
severity. The BTS does not report faulty_cells and degraded_cells. Instead, the BTS
reports alarm with following attribute (not whole alarm content is shown):
• affected_cells=none
Example 7
If SBTS does not support a specific RAT (for example, GSM) or the RAT cell/sector is not
affected by the fault, the information that the fault has no impact on the RAT is not
presented in the alarm. For example, when SBTS supports WCDMA and LTE, only and
the fault has impact only on a single LTE cell, BTS reports alarm with following attribute
(not whole alarm content is shown):
• faulty_cells=LTE:3
and not with attribute: faulty_cells=LTE:3;WCDMA:none;GSM:none; degraded_cells=
none.
Example 8
If the eNB detects fault 2004, the fault alone will make cell with id 1 degraded. However,
if there is a previously reported fault that has already made the same cell faulty, eNB
does not report alarm with fault id 2004 and with degraded_cells attribute. Instead, the
BTS reports (not whole alarm content is shown):
• with fault id: 2004
• with attribute: affected_cells=LTE:1
15.2.2 Autonomous recovery actions improvement for SBTS and

eNB
Before the LTE3342/SR001534 feature, an autonomous recovery reset (for example
BTS reset, radio reset, or baseband card reset) was executed only if the reset had not
disabled any working cells (it was not possible to terminate the ongoing services due to
the autonomous recovery reset). When the autonomous recovery terminated the
services, only an alarm was reported to the operator, who then had to execute a manual
reset. The LTE3342/SR001534 feature introduces two parameters:
• Activate Force Unit Autonomous Reset (actForceUnitAutoReset)
• Activate Force Autonomous Reset (actForceAutoReset)
The parameters allow the operator to decide if eNB/SBTS can temporarily disable
working services due to a recovery reset. For more information about the parameters,
see LTE Operating Documentation/ Reference/Parameters.
The following rules for autonomous resets are defined in SBTS and eNB:
1. Autonomous FSP on system module or external baseband card reset
By default, the FSP/baseband card reset is initiated only if the reset does not disable
any cell. If actForceUnitAutoReset parameter is enabled, the reset is initiated
regardless of the impact on the corresponding cells. This reset can be initiated three
times within one hour. FSP/baseband card reset is executed only if it hosts LTE
applications exclusively. If the FSP/baseband card is hosting GSM or WCDMA
applications in SBTS, RAT reset is executed instead.
DN181051332 Issue: 01 © 2018 Nokia 157

2. Autonomous radio reset
By default, the radio reset is initiated only when all Rx paths are disabled, or all Tx
paths are disabled, or all cells on the radio are disabled. If
actForceUnitAutoReset is enabled, then the reset is initiated regardless of the
state of corresponding Rx/Tx path and cells. Radio autonomous recovery reset is
allowed only once within one hour.
3. Autonomous RAT reset
By default, the RAT reset is initiated only if the reset does not disable any cell. If
actForceAutoReset parameter is enabled, the reset is initiated regardless of the
impact on the working cells. This reset can be initiated two times within one hour in
case SBTS has only one RAT. Third reset is escalated to BTS site reset. In case the
SBTS has more RATs, the RAT reset can be initiated three times within one hour.
RAT reset as autonomous recovery is available in SBTS only (not in eNB)
4. Autonomous BTS site reset
g Note: Site reset means that also the transport unit is reset.
By default, the site reset is initiated only if the reset does not disable any cell. If
actForceAutoReset parameter is enabled, then the reset is initiated regardless
of the impact on the working cells. This reset can be initiated three times within one
hour.
5. Autonomous BTS reset
By default, the site reset is initiated only if the reset does not disable any cell. If
actForceAutoReset parameter is enabled, then the reset is initiated regardless
of the impact on the working cells. This reset can be initiated twice within one hour.
Third BTS reset is escalated to BTS Site reset. BTS reset is available in eNB only.
6. Autonomous GNSS reset
This reset can be initiated three times within one hour.
7. Autonomous BTS secondary core reset
This reset can be initiated three times within one hour. The reset is available in eNB
only.
8. Autonomous FSP shutdown and restart on overheating
When eNB/SBTS initiates an autonomous recovery reset, special alarm notification is
reported to inform the operator about an ongoing recovery reset. If
actCategoryAlarms is set to false, the alarm is 7652 BASE STATION
NOTIFICATION. If actCategoryAlarms is set to true, the alarm is 7101 BASE
STATION/UNIT AUTONOMOUS RESET NOTIFICATION. The fault name reported in
the alarm is:
• If FSP on system module reset is executed: "FSP on system module autonomous
reset as recovery action (x)"
• If radio module recovery reset is executed: "Radio autonomous reset as recovery
action (x)"
• If RAT recovery reset is executed: "RAT autonomous reset as recovery action (x)"
• If BTS site recovery reset is executed: "BTS site autonomous reset as recovery
action (x)"
• If BTS recovery reset is executed: "BTS autonomous reset as recovery action (x)"
• If GNSS reset is executed: "GNSS autonomous reset as recovery action (x)"
• If secondary core reset is executed: "BTS secondary core autonomous reset as
recovery action (x)"
where x is the ID of a fault which is the root cause of the recovery reset.
158 © 2018 Nokia DN181051332 Issue: 01

15.3 LTE3342/SR001534 system impact

The LTE3342/SR001534: Improved Combined FM Service feature depends on the
LTE3296/SR001527: Harmonized Object Model for LTE & SRAN feature and is a
prerequisite to LTE3332/SR001503: WebUI Element Manager for LTE & SRAN feature.
Impact on the system

The LTE3342/SR001534: Improved Combined FM Service feature has no impact on
interfaces, network management tools, and system performance or capacity.
15.4 LTE3342/SR001534 reference data

LTE3342/SR001534: Improved Combined FM Service requirements, alarms and faults,
commands, measurements and counters, KPIs, parameters, and sales information
Requirements
Table 68 LTE3342/SR001534 hardware and software requirements
FDD TDD
System release FDD-LTE17A TD-LTE17A
OMS LTE17A LTE17A
NetAct 17.2 17.2
g Note: The LTE3342 feature is not supported in the LTE17A release for cFZC/FZAP
products, beside the fact that the Activate Category
Alarms (actCategoryAlarms) feature activation flag is available – it will always be
set to false. As a result, for cFZC/FZAP products, the actCategoryAlarms equal
true sections in alarms description are not applicable to these products in the LTE17A
release.
DN181051332 Issue: 01 © 2018 Nokia 159

Table 69 Software required for SR001534 SRAN FM combined Service
System release SBTS Flexi Multiradio 10 Nokia AirScale BTS
BTS
SRAN 17A SBTS17A SBTS17A SBTS17A
Alarms
Table 70 New alarms introduced by LTE3342
Alarm ID Alarm name
7100 BASE STATION HARDWARE PROBLEM
7101 BASE STATION/UNIT AUTONOMOUS RESET NOTIFICATION
7102 BASE STATION RESOURCE BLOCKED BY USER
7103 BASE STATION EXTERNAL ALARM NOTIFICATION
7107 BASE STATION CONNECTIVITY PROBLEM
7108 BASE STATION SYNCHRONIZATION PROBLEM
7109 BASE STATION SECURITY PROBLEM
7110 BASE STATION LICENSE LIMITATION
7111 BASE STATION SOFTWARE PROBLEM
7112 BASE STATION CONFIGURATION PROBLEM
7113 BASE STATION ANTENNA LINE PROBLEM
7114 CELL SERVICE PROBLEM
7115 BASE STATION INFORMATION
7116 BASE STATION SERVICE PROBLEM
For alarm descriptions, see LTE Operating Documentation/Reference/Alarms and Faults

There are no faults related to the LTE3342/SR001534: Improved Combined FM Service
feature.

There are no measurements or counters related to the LTE3342/SR001534: Improved
Combined FM Service feature.

There are no key performance indicators related to the LTE3342/SR001534: Improved
Combined FM Service feature.
Parameters
160 © 2018 Nokia DN181051332 Issue: 01

object structure
Activate Category actCategoryAla FMCADM — common
Alarms rms
Activated Force actForceUnitAu FMCADM — common
Unit Autonomous toReset
Reset
Activated Force actForceAutoRe FMCADM — common
Autonomous Reset set
For parameter descriptions, see LTE Operating Documentation/Reference/Parameters.
Sales information
Basic Software (BSW) — N/A
15.5 Selecting alarms scheme using BTS Site Manager

The LTE3342/SR001534: Improved Combined FM Service feature introduces a new
alarming scheme called category alarms. You can choose between the legacy and new
alarming scheme using actCategoryAlarms parameter.
Before you start

– Procedure causes BTS restart
Procedure
Sub-steps
left.
DN181051332 Issue: 01 © 2018 Nokia 161

state of the BTS.
4 Go to the FMCADM object.
Object path: MNL ► MNLENT ► FMCADM
5 Set the Activate Category Alarms (actCategoryAlarms) to desired value.
Setting this parameter to true will enable the category alarms. Setting it to false will
retain the legacy alarm and faults scheme.
Sub-steps
Result
If the legacy scheme has been selected, a single fault in the BTS will result in several
disabled/degraded cells and several, several alarms, separate for each affected cell.
With category alarms, only one alarm will be reported, and the content of the alarm will
show the corresponding disabled/degraded cells.
15.6 Configuring autonomous reset using BTS Site

Manager
The LTE3342/SR001534: Improved Combined FM Service feature introduces two
parameters, which define how autonomous resets are performed.
Before you start

162 © 2018 Nokia DN181051332 Issue: 01

– Procedure does not cause downtime, and can be performed at any time of the
day.
– see Autonomous recovery actions improvement for SBTS and eNB for more
information on this topic
Procedure
Sub-steps
left.
state of the BTS.
4 Go to the FMCADM object.
Object path: MNL ► MNLENT ► FMCADM
5 Set parameters to desired values.
The Activated Force Autonomous Reset (actForceAutoReset)

parameter is related to the autonomous site and RAT reset. If set to true, the reset
will be initiated regardless of the impact on the working cells.
The Activated Force Unit Autonomous
Reset (actForceUnitAutoReset) parameter is related to the autonomous FSP
and radio reset. If set to true, the reset will be initiated regardless of the impact on
the cells and Rx/Tx paths.
Sub-steps
DN181051332 Issue: 01 © 2018 Nokia 163

Result
The autonomous recovery actions are changed, depending on the selected parameters.
164 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3356: PCMD - RRC Connection Establishment
Failures
16 LTE3356: PCMD - RRC Connection

Establishment Failures
FL17A /TL18
LTE3356-PCMD
Extension Report
Failures
The LTE3356: PCMD – RRC Connection Establishment Failures feature extends the

concept of PCMD introduced by the LTE3333: Per Call Measurement Data (PCMD)
feature by adding the information related to the radio resource control (RRC) connection
failures.

In addition to LTE3333: Per Call Measurement Data (PCMD), LTE3356: PCMD – RRC
Connection Establishment Failures provides the following benefits:
• More accurate measurements for troubleshooting RRC connection setup failures,
provided by the PCMD.

Functional overview
DN181051332 Issue: 01 © 2018 Nokia 165

LTE3356: PCMD - RRC Connection Establishment LTE17A Operability Features
Failures
MME
fALUorCMM Operator
Tools
IM
SI
M
/IM ield
M
Ef
EI s
+
NPC
ng
mi
ea
Str
Correlated 9959NPO
1minutefiles
L3DC
AirScale,
FSMr3 FSMPCMD
collection
PCMDAnalysisGUI
KPIAnalysisGUI
integration
PM/PCMDcorrelation
Operator
Tools
g Note:
LTE project.
release.
The LTE3356: PCMD - RRC Connection Establishment Failures provides information

related to RRC Connection Establishment Failures. The eNB sends a report whenever
RRC connection request is rejected. Two types of RRC connection requests are
supported with SAE-temporary mobile subscriber identity (S-TMSI) included in the
request and those in which no S-TMSI was provided. Each failure is reported separately
to the SAE-temporary mobile subscriber identity L3DC.
The LTE3356: PCMD - RRC Connection Establishment Failures feature is always
activated simultaneously with the LTE3333: Per Call Measurement Data (PCMD) feature.

166 © 2018 Nokia DN181051332 Issue: 01

Failures
The LTE3356: PCMD - RRC Connection Establishment Failures feature is impacted by

the following features:
If the LTE3333: Per Call Measurement Data (PCMD) feature is activated the
LTE3356: PCMD - RRC Connection Establishment Failures is also enabled.
The LTE3356: PCMD - RRC Connection Establishment Failures feature reuses the
same feature activation flagActivate PCMD Report (actPCMDReport)as the
LTE3333: Per Call Measurement Data (PCMD) feature.
The LTE3356: PCMD - RRC Connection Establishment Failures feature impacts

The LTE3356: PCMD - RRC Connection Establishment Failures feature has no impact



Requirements
FDD TDD
DN181051332 Issue: 01 © 2018 Nokia 167

LTE3356: PCMD - RRC Connection Establishment LTE17A Operability Features
Failures
(Cont.)
FDD TDD
Alarms
There are no alarms related to the LTE3356: PCMD - RRC Connection Establishment
Failures feature.

There are no faults related to the LTE3356: PCMD - RRC Connection Establishment
Failures feature.

There are no measurements or counters related to the LTE3356: PCMD - RRC
Connection Establishment Failures feature.

There are no key performance indicators related to the LTE3356: PCMD - RRC
Connection Establishment Failures feature.
Parameters
There are no parameters related to the LTE3356: PCMD - RRC Connection
Establishment Failures features.
Sales information
168 © 2018 Nokia DN181051332 Issue: 01

Failures

(PCMD) - RRC Connection Establishment Failures
Before you start
The LTE3356: Per Call Measurement Data (PCMD) – RRC Connection Failure feature is

(PCMD) - RRC Connection Establishment Failures
Before you start
The LTE3356: Per Call Measurement Data (PCMD) – RRC Connection Failure feature is
deactivated.
(MTRACE).
DN181051332 Issue: 01 © 2018 Nokia 169

LTE3357: PCMD - Measurement Report LTE17A Operability Features
17 LTE3357: PCMD - Measurement Report

FL17A /TL18
LTE3356-PCMD
Extension Report
Failures
The LTE3357: PCMD – Measurement Report feature extends the concept of PCMD

introduced by the LTE3333: Per Call Measurement Data (PCMD) feature by adding the
information related to the intra-LTE measurement reports received from the UE during
the PCMD collection interval. The information includes measurement report type and
purpose definition, as well as mobility and coverage related measurements.

In addition to LTE3333: Per Call Measurement Data (PCMD), LTE3357: PCMD –
Measurement Report provides the following benefits:
• Monitoring of the radio signal power and quality at the beginning and end of the UE's
connection to the serving cell.
• Accelerated UE mobility related failure determination via physical cell ID (PCI) and E-
UTRAN cell global identifier (ECGI) (optional) analysis.

Functional overview
170 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3357: PCMD - Measurement Report
MME
fALUorCMM Operator
Tools
IM
SI
M
/IM ield
M
Ef
EI s
+
NPC
ng
mi
ea
Str
Correlated 9959NPO
1minutefiles
L3DC
AirScale,
FSMr3 FSMPCMD
collection
PCMDAnalysisGUI
KPIAnalysisGUI
integration
PM/PCMDcorrelation
Operator
Tools
g Note:
LTE project.
release.
The LTE3357: PCMD – Measurement Report provides data for the UE measurement

report sub-record. PCMD captures the first and the last measurement report sent by the
UE during the PCMD collection interval. If the UE sends a single measurement report
during the connection, the first measurement report will be populated. If the UE sends
multiple measurement reports during the connection, the initial reports are captured in
the last measurement report.
The LTE3357: PCMD – Measurement Report feature is always activated simultaneously
with the LTE3333: Per Call Measurement Data (PCMD) feature.
For measurement data related to LTE3357: PCMD – Measurement Report feature, see
Measurement data related to LTE3357: PCMD – Measurement Report feature.

DN181051332 Issue: 01 © 2018 Nokia 171

The LTE3357: PCMD – Measurement Report feature is impacted by the following

features:
If the LTE3333: Per Call Measurement Data (PCMD) feature is activated the
LTE3357: PCMD – Measurement Report is also enabled.
The LTE3333: Per Call Measurement Data (PCMD) feature reuses the same feature
activation flag Activate PCMD Report (actPCMDReport)as the LTE3333:
Per Call Measurement Data (PCMD) feature.
The LTE3357: Per Call Measurement Data (PCMD) feature impacts interfaces as
follows:

The LTE3357: PCMD – Measurement Report feature has no impact on network
management tools.



Requirements
FDD TDD
172 © 2018 Nokia DN181051332 Issue: 01

(Cont.)
FDD TDD
Alarms
There are no alarms related to the LTE3357: PCMD – Measurement Report feature.

There are no faults related to the LTE3357: PCMD – Measurement Report feature.
Commands
There are no commands related to the LTE3357: PCMD – Measurement Report feature.
Measurement data related to LTE3357: PCMD – Measurement Report feature

feature
Number of cells Number of cells
Carrier frequency The carrier frequency is the central frequency
of a cell.
Down link E-UTRAN absolute radio frequency An dlEARFCN defines a Radio Frequency (RF)
channel number (dlEARFCN) channel frequencies for downlink use.
Report type UE measurement type
Report purpose UE measurement purpose
Number of cells in report Number of cells included in UE measurement
report
Physical cell ID (PCI) The identity of an LTE cell. It is included in the
LTE X2 setup procedure. The eNodeB can
choose the PCI from a list of possible identity
values. In LTE there are 504 unique physical
DN181051332 Issue: 01 © 2018 Nokia 173


feature (Cont.)
layer cell identities, grouped into 168 groups of
three identities. The Primary Synchronization
Sequence (PSS) and Secondary
Synchronization Sequence (SSS) in a given
cell are used to indicate the PCI to the UE.
E-UTRAN cell global identifier (ECGI) (optional) The globally unique identity of a cell in E-
UTRAN. The E-UTRAN cell global identifier
consists of a mobile country code, a mobile
network code, and an E-UTRAN cell identifier.
Reference signal received power (RSRP) An LTE measurement which provides a cell-
specific signal strength metric. This
measurement is mainly used to rank different
LTE cells according to their signal strength as
an input for handover and cell reselection
decisions. The RSRP of a cell is defined as the
linear average over the power contributions (in
Watts) of the Resource Elements (REs) which
carry cell-specific RS within the considered
measurement bandwidth.
Reference signal received quality (RSRQ) An LTE measurement which provides a cell-
specific signal quality metric. This
measurement is mainly used to rank different
LTE cells according to their signal quality as an
input for handover and cell reselection
decisions, for example in scenarios for which
RSRP measurements do not provide sufficient
information to perform reliable mobility
decisions. The RSRQ is defined as the ratio N ·
RSRP/(LTE carrier RSSI), where N is the
number of Resource Blocks (RBs) of the LTE
carrier Received Signal Strength Indicator
(RSSI) measurement bandwidth.

There are no measurements or counters related to the LTE3357: PCMD – Measurement
Report feature.

There are no key performance indicators related to the LTE3357: PCMD – Measurement
Report feature.
Parameters
There are no parameters related to the LTE3357: PCMD – Measurement Report feature.
Sales information
174 © 2018 Nokia DN181051332 Issue: 01


(PCMD) - Measurement Report
Before you start
The LTE3357: Per Call Measurement Data (PCMD) - Measurement Report feature is

(PCMD) - Measurement Report
Before you start
The LTE3357: Per Call Measurement Data (PCMD) - Measurement Report feature is
deactivated.
(MTRACE).
DN181051332 Issue: 01 © 2018 Nokia 175

LTE3361: FZM filesystem encryption LTE17A Operability Features
18 LTE3361: FZM filesystem encryption

Benefits, functionality, system impact, reference data of the feature
The LTE3361: FZM filesystem encryption feature introduces full encryption of the Flexi

Zone Micro (FZM) filesystem.

The LTE3361: FZM filesystem encryption feature provides improved protection of data
storage on the FZM.

In release LTE17A, FZM filesystem encryption functionality is introduced. It’s designed to
work seamlessly for the operator without the need of any prior configuration. An
authenticated user logged into an FZM unit is allowed to read/write ALL information
stored on the SSD, but offline access to SSD content is not possible.
g Note:
• FZM has two SSD partitions, an active and a passive, to support fallback scenarios
during upgrade. When first upgrading to LTE17A, only the LTE17A partition is
automatically encrypted. The passive partition which contains the old pre-LTE17A
release still remains unencrypted. An operator has to perform another upgrade to
LTE17A or later release to have both SSD partitions encrypted.
• Operator-initiated rollback will not work if a pre-RL17A release is in the active
partition and an RL17A or later release is in the passive partition.
• Automatic fallback to the passive partition due to repeated initialization failures will
work in all scenarios.

LTE3361: FZM filesystem encryption impact on features, interfaces, network
management tools, and system performance and capacity

There are no interdependencies between the LTE3361: FZM filesystem encryption
feature and any other feature.
The LTE3361: FZM filesystem encryption feature has no impact on interfaces.

The LTE3361: FZM filesystem encryption feature has no impact on network
management tools.
176 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3361: FZM filesystem encryption

The LTE3361: FZM filesystem encryption feature has no impact on system performance
or capacity.

LTE3361: FZM filesystem encryption reference data requirements and sales information.
There are no alarms, commands, measurements and counters, key performance
indicators, parameters related to the LTE3361: FZM filesystem encryption feature.
Requirements
FDD TDD
Cloud Flexi Zone Controller Not supported Not supported
Flexi Zone Controller Not supported Not supported
NetAct Not supported Not supported
Sales information
DN181051332 Issue: 01 © 2018 Nokia 177

LTE3475: Additional KPIs for Performance Monitoring LTE17A Operability Features
19 LTE3475: Additional KPIs for Performance

Monitoring
The LTE3475: Additional KPIs for Performance Monitoring feature extends the LTE3303:

Enhanced VoLTE, CA, and RF Quality Monitoring feature. This feature introduces
support for additional KPIs in the following areas:
• accessibility
• retainability
• throughput
• quality
• Carrier Aggregation (CA)
• Transmit Time Intervals (TTI) bundling

The LTE3475: Additional KPIs for performance monitoring feature enables the operator
to monitor the LTE RAN network in more detail.

The LTE3475: Additional KPIs for Performance Monitoring feature introduces new
counters for more detailed network monitoring in the following areas:
• accessibility – repeated RRC connection setup attempts and RRC failures
• retainability
– E-UTRAN Radio Access Bearer (ERAB) releases due to S1 reset S1 outage (for
QC1, QC5 and all QCI)
• throughput – maximum achievable throughput per UE and cell
• quality – initial Block Error Rate (BLER) for Guaranteed Bit Rate (GBR) and VoLTE
• Carrier Aggregation
– RLC data volume for PCell UL, DL
– throughput with 2CC, 3CC, 4CC CA
– deconfiguration failure rate
• Transmit Time Interval (TTI) Bundling – number of used Physical Resource Blocks
(PRBs) which are the smallest chunks of data transmitted by the eNB
Measurements
The LTE3475: Additional KPIs for Performance Monitoring feature introduced 53
counters in FL17A release. The counters are distributed through the five following
measurements:
178 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3475: Additional KPIs for Performance Monitoring
• #LTE EPS Bearer (M8006)
• #LTE UE State (M8013)
• #LTE Cell Throughput (M8012)
• #LTE Cell Resources (M8011)
• #LTE QoS (M8026)

LTE3475: Additional KPIs for Performance Monitoring feature has no impact on features,
interfaces, network management tools, and system performance and capacity.

LTE3475: Additional KPIs for Performance Monitoring feature requirements, counters,
parameters, and sales information
Requirements
FDD TDD
System release FL17A not supported
Flexi Multiradio 10 BTS FL17A* not supported
Flexi Multiradio 10 Indoor BTS not supported not supported
Nokia AirScale BTS FL17A not supported
Flexi Zone BTS FL17A not supported
Flexi Zone Access Point FL17A not supported
Flexi Zone Controller not supported not supported
OMS OMS 17 not supported
NetAct NetAct 17.8 not supported
MME support not required not supported
SAE GW support not required not supported
UE support not required not supported
g Note: * Counters from the Table 3 New counters introduced by LTE3475 are not
supported for FSM r.3. They are only supported for Airscale HW platform. The rest of
the counters are supported for FSM r.3.

There are no faults related to the LTE3475: Additional KPIs for Performance Monitoring
feature.
Commands
DN181051332 Issue: 01 © 2018 Nokia 179

There are no commands related to the LTE3475: Additional KPIs for Performance

Monitoring feature.
Table 83 New counters introduced by LTE3475
M8006C316 QCI1 E-RAB releases due to eNB Initiated Global LTE EPS Bearer
S1 Reset
M8006C317 QCI1 E-RAB releases due to MME Initiated LTE EPS Bearer
Global S1 Reset
M8006C318 QCI1 E-RAB releases due to eNB Initiated Partial LTE EPS Bearer
S1 Reset
Partial S1 Reset
M8006C320 QCI1 E-RAB releases due to S1 Outage LTE EPS Bearer
M8006C321 QCI5 E-RAB releases due to eNB Initiated Global LTE EPS Bearer
S1 Reset
Global S1 Reset
M8006C323 QCI5 E-RAB releases due to eNB Initiated Partial LTE EPS Bearer
S1 Reset
Partial S1 Reset
M8006C325 QCI5 E-RAB releases due to S1 Outage LTE EPS Bearer
M8013C67 Number of Signaling Connection Establishment LTE UE State
Requests rejected due to lack of PUCCH
resources
Requests rejected due to threshold for the
maximum number of RRC connections
M8013C75 Number of rejected Signaling Connection LTE UE State
Establishment Requests because C-Plane pool
limit is exceeded
M8013C83 Signaling Connection Establishment attempts due LTE UE State
to MO-Signaling including repetitions
to MT-Access including repetitions
to MO-Data including repetitions
M8013C86 Signaling Connection Establishment attempts for LTE UE State
emergency calls including repetitions
high priority calls including repetitions
delay tolerant access including repetitions
M8013C89 Signaling Connection Establishment attempts LTE UE State
repetitions
180 © 2018 Nokia DN181051332 Issue: 01

Table 83 New counters introduced by LTE3475 (Cont.)
M8013C90 Signaling Connection Fast Establishment LTE UE State
attempts repetitions
to others
to others
M8013C93 Signalling Connection Establishment attempts LTE UE State
due to MO-Voice Call
due to MO-Voice Call including repetitions
M8013C95 Total number of Signaling Connection LTE UE State
Establishment Requests rejected
Requests rejected due to eNB Internal failure
Requests rejected due to deprioritisation Upon
AC Failure
Requests rejected due to Other reasons
Counters from Table below are not supported for FSM r.3. They are only supported for
Airscale HW platform.
M8011C215 Number of UL PRBs used for TTI Bundling LTE Cell Resource
M8012C179 Average achievable MAC PDU Throughput in LTE Cell Throughput
Downlink per Cell
M8012C180 Maximum achievable MAC PDU Throughput in LTE Cell Throughput
Downlink per Cell
M8012C181 Average achievable MAC PDU Throughput in LTE Cell Throughput
Uplink per Cell
M8012C182 Maximum achievable MAC PDU Throughput in LTE Cell Throughput
Uplink per Cell
M8012C183 Average achievable MAC PDU throughput in LTE Cell Throughput
Downlink per User
M8012C184 Maximum achievable MAC PDU throughput in LTE Cell Throughput
Downlink per User
M8012C185 Average achievable MAC PDU throughput in LTE Cell Throughput
Uplink per User
M8012C186 Maximum achievable MAC PDU throughput in LTE Cell Throughput
Uplink per User
M8012C187 DL nonGBR IP throughput Data Volume for UEs LTE Cell Throughput
without CA
DN181051332 Issue: 01 © 2018 Nokia 181

with 2CC CA
with 3CC CA
with 4CC CA
M8012C191 DL nonGBR IP throughput time for UEs without LTE Cell Throughput
CA
M8012C192 DL nonGBR IP throughput time for UEs with 2CC LTE Cell Throughput
CA
CA
CA
M8012C195 PCell RLC data volume in DL LTE Cell Throughput
M8012C196 PCell RLC data volume in UL LTE Cell Throughput
M8026C279 Total number of Initial HARQ Transmission for LTE QoS
GBR excluding VoLTE in Downlink
M8026C280 Total number of Failed Initial HARQ Transmission LTE QoS
for VoLTE in Downlink
M8026C281 Total number of Failed Initial HARQ Transmission LTE QoS
for GBR excluding VoLTE in Downlink
M8026C282 Total number of NO Feedback for Initial HARQ LTE QoS
Transmission for VoLTE in Downlink
M8026C283 Total number of NO Feedback for Initial HARQ LTE QoS
Transmission for GBR excluding VoLTE in
Downlink
For counters descriptions, see LTE Radio Access Operating Documentation/

Reference/Counters.
Table 85 Existing key performance indicators related to LTE3475
KPI ID KPI name
LTE_6178a E-UTRAN Averaged DL nonGBR IP Throughput for UEs without CA
LTE_6179a E-UTRAN Averaged DL nonGBR IP Throughput for CA Active UEs with 2CC
LTE_6182a E-UTRAN RLC PDU Volume DL via PCell
LTE_6183a E-UTRAN RLC PDU Volume UL via PCell
LTE_5209f E-UTRAN E-RAB QCI1 Normal Release Ratio User Perspective
LTE_5572f E-UTRAN E-RAB QCI1 Drop Ratio, RAN View
182 © 2018 Nokia DN181051332 Issue: 01

Table 85 Existing key performance indicators related to LTE3475 (Cont.)
KPI ID KPI name
LTE_5571g E-UTRAN E-RAB Drop Ratio per Cause, E-RAB QCI1 with data in the queue
drop ratio, RAN View, RNL Failure with UE Lost
LTE_5707b E-UTRAN RRC Connection Setup Failure Ratio per Cause, RRC Connection
Setup Rejection from eNB due to Overload and Lack of Resources
LTE_6120b E-UTRAN RRC Connection Setup Failure Ratio per Cause unavailable PUCCH
resources
LTE_5249b E-UTRAN RRC Connection Setup Failure Ratio per Cause rejection from eNB
due to C-Plane pool limit is exceeded
LTE_6278a Total E-UTRAN RRC Connection Setup Attempts with Repetitions
LTE_6267a RRC Connection Setup Attempts
LTE_6160b Total E-UTRAN RRC Connection Setup Attempts
LTE_5218g Total E-UTRAN RRC Connection Setup Success Ratio
LTE_5383b Total E-UTRAN RRC Connection Setup Success Ratio for mobile originating
calls.
LTE_5229f E-UTRAN RRC Connection Setup Failure Ratio per Cause, RRC timer expiry
LTE_5230f E-UTRAN RRC Connection Setup Failure Ratio per Cause, RRC protocol error
LTE_5590d E-UTRAN RRC Connection Setup Failure Ratio per Cause, Rejection from eNB
LTE_6277a E-UTRAN RRC Connection Setup Failure Ratio per Cause internal failure or
other failure
LTE_5060j E-UTRAN Initial E-RAB Accessibility
LTE_5574g E-UTRAN Additional E-RAB Accessibility
LTE_6266a RRC Connection Setup Attempts
Parameters
d object
Fast repeated RRC cfgFastRRCConn PMCCP – FDD
connection setup SetReqThresh
request threshold
d object
PRB utilization cfgPRBUtilThre PMCCP – FDD
threshold shold
Performance pmCCPId PMCCP – FDD
Monitoring Counters
Configuration
parameters
identifier
Sales information
DN181051332 Issue: 01 © 2018 Nokia 183

BSW – Yes
184 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3488: SFP Data Availability via BTS CLI
20 LTE3488: SFP Data Availability via BTS CLI

The LTE3488 SFP Data Availability via BTS CLI feature extends the fiber optic links

parameters' attainability, earlier collected by the LTE2379: SFP Monitoring on RP3/CPRI
feature functionality. However, these data are also available through Network Element
Manager GUI and ADMIN WebUI (LTE2883: Application of Diagnostic and Maintenance
for Intelligent Network).
LTE3488 Summary of changes
Table 89 LTE3488 summary of changes
2017-09-08 Feature description Updated Admin-CLI table according to
Software version 2.0.6
2017-09-08 LTE3488 standalone version Added connection to eNB example
start-up
2018-01-19 LTE3488 standalone version Added information about software version
start-up

The LTE3488: SFP data availability via BTS CLI feature provides the following benefits:
• minimum operator involvement
• data collection automation
• optical link monitoring for possible failure prevention
• Windows and Linux platform support
• IPv6 support
20.2
Baseband Unit (BBU) can be located up to 23 km from Remote Radio Head (RRH). Data
transfer between BBU and RRH is performed with Common Public Radio Interface/Open
Base Station Architecture Initiative (CPRI/OBSAI) links. Due to this distance and the
significance of the connection, the CPRI/OBSAI links are equipped with SFP modules
supporting Digital Diagnostics Monitoring (DDM) functions. Acquisition of the SFP data is
provided by the LTE2379 feature, which collects all data in the InfoModel Data
Repository. Table 90: SFP data description shows SFP data collection.
Table 90 SFP data description
SFP Link Parameter Description [units] Example
Source / Destination Unit Parameters
DN181051332 Issue: 01 © 2018 Nokia 185

LTE3488: SFP Data Availability via BTS CLI LTE17A Operability Features
Table 90 SFP data description (Cont.)
id distName of the Managed /MRBTS-1/RAT-1/BTS_L-
Object representing the HW 1/EQM_L-1/CABINET_L-
unit 1/SMOD_L-1
productName Name of the source/destination Flexi System Module Outdoor
HW element FSMF
serialNumber Serial number of the L1142200724
source/destination HW
element
productCode Product code of the 472181A
source/destination HW
element
SFP parameters
id distName of the connector /MRBTS-1/RAT-1/BTS_L-
where SFP is installed 1/EQM_L-1/CABINET_L-
1/SMOD_L-
1/CONNECTOR_L-4
vendor Vendor of the SFP WTD_RTXM228-610
connectorType Type of the connector LC
wavelength Wavelength on which the link 850
is operating [nm]
transmissionMode Mode of the transmission -
transmissionRate Maximum bitrate of the 6100
transmission [Mb/s]
transmissionDistance Distance of the transmission 176
[m]
txPowerHighAlarmThreshold Transmitter power high alarm -1
threshold [dBm]
txPowerLowAlarmThreshold Transmitter power low alarm -6
threshold [dBm]
txPowerHighWarningThreshold Transmitter power high -2
warning threshold [dBm]
txPowerLowWarningThreshold Transmitter power low warning -5
threshold [dBm]
rxPowerHighAlarmThreshold Receiver power high alarm 0
threshold [dBm]
rxPowerLowAlarmThreshold Receiver power low alarm -20
threshold [dBm]
rxPowerHighWarningThreshol Receiver power high warning -1
d threshold [dBm]
rxPowerLowWarningThreshold Receiver power low warning -18
threshold [dBm]
temperatureHighAlarmThresho Temperature high alarm 90
ld threshold [°C]
temperatureLowAlarmThreshol Temperature low alarm -45
d threshold [°C]
186 © 2018 Nokia DN181051332 Issue: 01

Table 90 SFP data description (Cont.)
temperature Current temperature of the 35
connector [°C]
voltage Transciever TX supply voltage 3269
[mV]
current Transciever TX bias current 5
[mA]
opticalTxPower Transciever TX optical power 454
[uW]
opticalRxPower Transciever RX optical power 581
[uW]
Link Parameter
BER Bit Error Rate
LCV
type Type of the link RP3_01Link
Speed Transmission speed on the link 3072
[Mb/s]
endPointId distName of the destination /MRBTS-1/RAT-1/BTS_L-
point of the link 1/EQM_L-1/RMOD_L-
4/CONNECTOR_L-2
roundTripType Round Trip Type 865
LTE3488 feature provides the possibility to download parameters of the CPRI/OBSAI
links using Command Line (CLI). Direct access to the SFP data is performed by
getSfpData.bat command deployed in the CLI. Data transfer is prefaced by
authorization and transmission setup in the Network Management System (NMS).
Accordingly to the connection settings, data stream is issued by the BBU through
InfoModel Gateway (IMGW) IM Interface 3600 (IMI3600) or via Local Management Port
(LMP), and it can be addressed to a specific port or collected in the text file at the NMS
PC. Figure below shows the functionality of the LTE3488 feature.
g Note: This feature is applicable to SFPs that are used in the connections between the
radio and system, baseband, or chained radio modules.
In order to establish the connection, first the admin-cli command needs to be used to
configure the connection to the eNB.
admin-cli command is described in Table 91: admin-cli command parameters.
DN181051332 Issue: 01 © 2018 Nokia 187

Figure 33 SFP Data Availability via BTS CLI
Table 91 admin-cli command parameters
Parameter Description Type Parameter requirement
--bts-username BTS username string mandatory
--bts-password BTS password string mandatory
--bts-host BTS host string mandatory
--bts-port BTS port number mandatory
--data JSON format string mandatory
request
--debug Log file string optional
--bundles-dir Bundles directory string optional
default: '<admin-cli
dir>/bundles'
--format Output format string optional

('compact' or default: 'compact'
'human')
-h, --help Show help boolean optional

-v, --version Show version boolean optional
number
Once the connection to the eNB is established, the getSftData command can be
executed. As a result, proper output file is created containing the SFP data.
g Note: As admin-cli behavior is: send procedure → wait for and receive response →
terminate. The result can be visible in the output file if task is finished with "complete"
status. If error occurs, CLI will terminate and exit with 'failed' status.
During setup of the CLI connection, the operator can set the ––format option. If it is set
to 'human', then the human readable format is saved to the output file. If the output
needs to be parsed by automatic scripts, it is advised to use 'compact' option. The data
stream formatted that way does not contain unnecessary spaces or end line characters
and is easier for parsing.
188 © 2018 Nokia DN181051332 Issue: 01

20.3
has no impact on features, interfaces, network management tools, and system
performance and capacity

The following feature must be activated before activating the LTE3488 feature:
• LTE2379: SFP Monitoring on RP3/CPRI

LTE3488: SFP data availability via BTS CLI requirements, alarms and faults, commands,
Requirements
FDD TDD
Flexi Multiradio 10 Indoor BTS Not supported TL17A
Flexi Zone Access Point Not supported Not supported
Flexi Zone Controller Not supported Not supported
OMS Support not required Support not required
NetAct Support not required Support not required
MME Support not required Support not required
SAE GW Support not required Support not required
UE Support not required Support not required
Alarms
There are no alarms related to the LTE3488: SFP data availability via BTS CLI feature.

There are no faults related to the LTE3488: SFP data availability via BTS CLI feature.
Commands
There are no commands related to the LTE3488: SFP data availability via BTS CLI
feature.
DN181051332 Issue: 01 © 2018 Nokia 189


There are no measurements or counters related to the LTE3488: SFP data availability
via BTS CLI feature.

There are no key performance indicators related to the LTE3488: SFP data availability
via BTS CLI feature.
Parameters
There are no parameters related to the LTE3488: SFP data availability via BTS CLI
feature.
Sales information
Application software (ASW) - No
20.5 LTE3488 standalone version start-up

Start-up shows how to configure the getSfpData command and use it for SFP data
collection.
Before you start

Download latest software package (at least FL17SP_ BTS-CLI_2.0.6.zip)
Establish connection to eNB
Linux and Windows connection setup short guide.
Operating systems supported: Linux (x64), Windows (Windows 7 x64 or higher version)
• Linux OS connection example using built-in terminal:
– Open terminal
– Run command "ssh user@sshgateway.example.com -L
3600:192.168.255.1:3600"
• Windows OS connection setup example using PuTTY terminal v0.70:
– Load the Gateway:
Create and save the SSH gateway server. Select gateway from the Saved
Sessions list and click ‘Load’ as shown at the image below
190 © 2018 Nokia DN181051332 Issue: 01

Figure 34 Load the Gateway
– Configure the Tunnel:
In the left-hand side navigation tree, click Connection → SSH → Tunnels. Enter
the port that you want to connect to locally under “Source port”.
Supply the destination address (the server that is available from your SSH
gateway, but not from your local machine) as “Destination” as shown in the
following image
DN181051332 Issue: 01 © 2018 Nokia 191

Figure 35 Configure the Tunnel
Click “Add”, which will set the configuration
– Open the Tunnel:
Then, click “Open” to connect to your gateway.
192 © 2018 Nokia DN181051332 Issue: 01

Figure 36 Open the Tunnel
Now, as long as you leave that SSH terminal window open, all traffic to the
Source Port on your localhost will be forwarded on to the Destination.
Procedure
1 In the admin-cli-for-client file there are 2 separate scripts:
Select from the available options
• script for Linux users - .sh file
• script for Windows users - .bat file
2 Unzip the package containing getSfpData script.
3 Navigate to the place where you have unzipped your files.
DN181051332 Issue: 01 © 2018 Nokia 193

4 Edit getSfpData script with the credentials you will use for connection.
Table 94 LTE3488 getSfpData script credentials
Script variable name with assigned value Example
set ADMIN_CLI=.\admin-cmd-script.bat .\admin-cli.bat
set USERNAME=user-name Nemuadmin
set PASSWORD=user-password nemuuser
set HOST=host-address* 192.168.255.1 ( IPv6 is also supported )
set PORT=host-port 3600 ( LMP is also supported )
set TEXT_FORMAT=human or compact human
(default value)
set OUTPUT_FILE=file-name output.txt
User-name and user-password are used to connect to the eNB. Host-
address and host-port are identifying the eNB to which the connection is
established.
TEXT_FORMAT is set to human in this example, so that the generated output file can
be easily read by human being. However, you can also put value compact there to
have the format that can be easily used by automation scripts.
OUTPUT_FILE name can be changed as needed: in the example above it is
changed to output.txt
5 From the console/cmd navigate to the place where you have your scripts and execute
getSfpData command.
6 Check the output file for the SFP details.
Result
SFP data were transferred to the selected file or port.
194 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3540: Descriptive BTS Parameters
21 LTE3540: Descriptive BTS Parameters

The LTE3540: Descriptive BTS Parameters feature introduces additional descriptive
parameters in selected objects in the eNB, which can be used to store human-readable
object descriptions.

With the LTE3540: Descriptive BTS Parameters feature, the operator is able to use new
parameters to assign descriptions/tags to selected objects. Especially in management
tools the descriptions are useful to describe network elements (for example antenna
label: antenna TV tower).

Functional Overview
With the LTE3540: Descriptive BTS Parameters feature, free text parameters are
introduced in the eNB. The purpose of the new parameters is to describe network
objects like cell info (for example cell railway station). These labels are available in
network management tools.
Free text parameters (which can be used to store information for example alias
name/description/tag in human readable form) are introduced for the following objects in
the eNB:
• Multiradio BTS Site (MRBTS)
• LTE BTS Cell (LNCEL)
• Antenna Line parameters (ANTL)
• Radio Module (RMOD)
See Parameters to get an overview of the new text-parameters.
These parameters are not used/modified by the eNB. In other words, they are not going
to be manipulated by the eNB; however, the text-parameters are persistently stored
inside the eNB and available for Network Element Manager. There is no consistency
check or validation defined for these objects within the eNB.
Example: New MOC LNCELDESC with descriptive parameters
For descriptions of cells the new managed object class (MOC), LNCEL Descriptive
Parameters (LNCELDESC), is introduced as subordinate to the LNCEL object.
Location in the eNB object model: MRBTS/LNBTS/LNCEL/LNCELDESC
LNCELDESC instances are optional. One instance is supported per LNCEL.
LNCELDESC parameters:
• Cell configuration type: 3 sectors
• Cell info: urban
• Descriptive name: airport
DN181051332 Issue: 01 © 2018 Nokia 195

LTE3540: Descriptive BTS Parameters LTE17A Operability Features
• LNCELDESC identifier: Berlin
• Target parameters info: carrier aggregation

LTE3540: Descriptive BTS Parameters impact on features, interfaces, network
management tools, and system performance and capacity

There are no interdependencies between the LTE3540: Descriptive BTS Parameters
feature and any other feature.
The LTE3540: Descriptive BTS Parameters feature has no impact on interfaces.

The LTE3540: Descriptive BTS Parameters feature has no impact on network
management tools.

The LTE3540: Descriptive BTS Parameters feature has no impact on system
performance or capacity.

LTE3540: Descriptive BTS Parameters requirements, alarms and faults, commands,
Requirements
FDD TDD
System release FL17A TL17A
Flexi Multiradio 10 BTS FL17A Not supported
Flexi Zone Access Point Support not required Support not required
Cloud Flexi Zone Controller Support not required Support not required
OMS Support not required Support not required
NetAct NetAct 17.2 NetAct 17.2
196 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3540: Descriptive BTS Parameters
FDD TDD
Alarms
There are no alarms related to the LTE3540: Descriptive BTS Parameters feature.

There are no faults related to the LTE3540: Descriptive BTS Parameters feature.
Commands
There are no commands related to the LTE3540: Descriptive BTS Parameters feature.

There are no measurements or counters related to the LTE3540: Descriptive BTS
Parameters feature.

There are no key performance indicators related to the LTE3540: Descriptive BTS
Parameters feature.
Parameters
Full name Abbreviated name Managed object Parent FDD/TDD
structure
Group name groupName RMOD - common
Antenna label antennaLabel ANTL - common
Cell configuration type cellConfigType LNCELDESC - common
Cell info cellInfo LNCELDESC - common
Descriptive name descriptiveName LNCELDESC - common
LNCELDESC identifier LncelDescId LNCELDESC - common
Target parameters info targetParamInfo LNCELDESC - common
Assignee assignee MRBTSDESC - common
Descriptive name descriptiveName MRBTSDESC - common
Group name groupName MRBTSDESC - common
Integration info integrationInfo MRBTSDESC - common
MRBTS configuration type mrbtsConfigType MRBTSDESC - common
MRBTSDESC identifier mrbtsDescId MRBTSDESC - common
Region region MRBTSDESC - common
Subregion subregion MRBTSDESC - common
DN181051332 Issue: 01 © 2018 Nokia 197

LTE3540: Descriptive BTS Parameters LTE17A Operability Features
Full name Abbreviated name Managed object Parent FDD/TDD
structure
Target parameters info targetParamInfo MRBTSDESC - common
For parameter descriptions, see LTE Radio Access Operating
Documentation/Reference/Parameters.
Sales information
198 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3627: Windows 10 Support for Network Element
Manager
22 LTE3627: Windows 10 Support for Network

Element Manager
The LTE3627: Windows 10 Support for Network Element Manager feature introduces
Windows 10 workstation support for Network Element Manager.
Table 98 LTE3627 Summary of changes
17.08.2017 References Added note about FSME not
supported anymore
18.08.2017 References Changed 'not applicable' in the
table to 'not supported'

The LTE3627: Windows 10 Support for Network Element Manager feature provides the
following benefits:
The operator can use Network Element Manager with Windows 10 Enterprise 64-bit
version.

With this feature, Network Element Manager can be installed and used with Windows 10
Enterprise 64-bit version. All functionality available with earlier Operating System (OS)
versions is still supported.
Support for the following OSs remains unchanged:
• Windows 7
• Windows 8
• Windows Server 2008
• Red Hat Enterprise Linux
The following OS versions are no longer supported:
• Windows Vista (32-bit and 64-bit versions)

There are no interdependencies between the LTE3627: Windows 10 Support for Network
Element Manager feature and any other feature.
DN181051332 Issue: 01 © 2018 Nokia 199

LTE3627: Windows 10 Support for Network Element LTE17A Operability Features
Manager
The LTE3627: Windows 10 Support for Network Element Manager feature has no impact

on interfaces.


on system performance or capacity.

Requirements
FDD TDD
System release FL17A TL17A
Flexi Multiradio 10 BTS not supported TL17A
Flexi Multiradio 10 Indoor BTS FL17A TL17A
OMS not supported not supported
MME not supported not supported
SAE GW not supported not supported
UE not supported not supported
g Note: Flexi Multiradio BTS (FSME) is no longer supported.
Alarms
There are no alarms related to the LTE3627: Windows 10 Support for Network Element
Manager feature.

There are no faults related to the LTE3627: Windows 10 Support for Network Element
Manager feature.
Commands
There are no commands related to the LTE3627: Windows 10 Support for Network
Element Manager feature.
200 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3627: Windows 10 Support for Network Element
Manager

There are no measurements or counters related to the LTE3627: Windows 10 Support
for Network Element Manager feature.

There are no key performance indicators related to the LTE3627: Windows 10 Support
for Network Element Manager feature.
Parameters
There are no parameters related to the LTE3627: Windows 10 Support for Network
Element Manager feature.
Sales information

BSW - Yes
DN181051332 Issue: 01 © 2018 Nokia 201

LTE3701: Counter Profiles Enhancements Including the LTE17A Operability Features
UE Category
23 LTE3701: Counter Profiles Enhancements

Including the UE Category
The LTE3701: Counter Profiles Enhancements Including the UE Category feature
enhances LTE2766: Counter Profiling per Service providing the operator more
configuration options of the current counter profiles. The LTE3701 provides the operator
with a better visibility of eNB performance in specific areas due to the introduction of the
user equipment (UE) category criteria.

provides the following benefits:
• Allows the operator to configure the profiles with finer granularity by filtering certain
types of traffic and thus to monitor according to customer needs.
• Allows the operator to monitor on the network level the overall performace of different
traffic classes.

The LTE3701: Counter Profiles Enhancements Including the UE Category is an add-on
functionality which allows more configuration options of the current counter profiles.
A counter profile is defined as a combination of the following elements:
• QoS class indicator (QCI)

QCI is an indicator that is used as a reference to the acces node specific parameters
that control the treatment of bearer-level packet forwarding.
The QCI is preconfigured by the operator owning the access node.
• Allocation and Retention Priorities (ARP)
ARP is a value that is used to differentiate between bearers when allocation and
retention of a bearer is performed.
• Public Land Mobile Network (PLMN)
PLMN is a mobile network used for the specific purpose of providing land mobile
communication services to the public.
g Note: PLMN can be configured only if
LTE2915: Flexible QCI/PLMN-ID PM Counter Profiles is activated.
• UE category
UE category defines a combined uplink and downlink radio throughput capability.
A maximum number of 20 counter profiles can be defined using the following rules:
Profilex={single or multiple QCIy; single or multiple ARPz; PLMNs; UEk}
Possible values for all parameters:
• x - between 1 to 20
• y - between 1 to 9 or {65, 66, 69, 70} or between 128 to 254
202 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3701: Counter Profiles Enhancements Including the
UE Category
• z - between 1 to 15
• s - any PLMN ID
• k - 1 (Cat1), or 2 (CatM1), or 4 (Other)
g Note: The LTE3701 feature provide the flexibility to define more than one QCI and
ARP.
• QCI - can be a combination of multiple non-consecutive values and/or ranges
• ARP - can be a combination of multiple non-consecutive values and/or ranges
It is also possible to define a profile with all the above values empty. In such a profile the
counters will increment without checking any condition.
Table 101 Examples of counter profiles

QCI ARP UE category Counter increment for
5-9 1 Other (4) any match of QCI between 5 to 9 and ARP 1 for all UEs
in Other (4) category
- 1, 10, 15 Cat1 (1) any QCI with ARP 1 or 10 or 15 for all UEs in Cat1 (1)
category
1, 5, 9 2 - any match of QCI 1 or 5 or 9 and ARP 2 for all UEs
2, 9, 5-7 10 CatM1 (2) any match of QCI 2 or 9 or either QCI between 5 to 7
and ARP 10 for all UEs in CatM1 (2)
1-9 - Other (4) any match of either QCI between 1 to 9 and any ARP
for all UEs in Other (4) category
1-9 1-4, 10 - any match of either QCI between 1 to 9 and either ARP
between 1 to 4 or ARP 10 for all UEs
- - - all QCIs / ARPs / UE categories
g Note: Configuring a large number of profiles is not recommended as it has an impact
on the overall eNB capacity and performance. Keeping the number of counter profiles
as low as possible is advised.
The existing QCI Configuration (cfgQCI) and ARP Configuration

(cfgARP) parameters are removed from PMQAP managed objects class since 17A
release, due to LTE3701.
The removed parameters are replaced by QCI Configuration Range
(cfgQCIRange) and ARP Configuration Range (cfgARPRange) under the
PMQAP managed objects class.
A new parameter UE Category (cfgUECategory) is introduced under the PMQAP
managed objects class.

interacts with other features as follows:
DN181051332 Issue: 01 © 2018 Nokia 203

UE Category
• LTE2766: Flexible QCI/ARP PM Counter Profiles.

The LTE2766 feature provides a configurable selection or groups of counters with
certain QCIs and ARPs including the range of the operator-specific QCIs (128 to
254).
For the support of the Performance Monitoring QCI and ARP Profile (PMQAP)
counters the LTE2766 feature must be activated.
• LTE2782: RRC Re-establishment and RLF PM Counters per QCI Profile
This feature introduces counters for monitoring radio link failures (RLF) statistics
separately for every QCI-ARP profile (introduced in the LTE2766: Flexible QCI/ARP
PM Counter Profiles feature), which allows optimization of QCI-dependent
parameters.
For the support of the RLF counters the LTE2782 feature must be activated.
• LTE2915: Flexible QCI/PLMN-ID PM Counter Profiles
LTE2915 has to be activated if PLMN element will be used in one or more counter
profiles as defined by LTE3701.
The LTE3701: Counter Profiles Enhancements Including the UE Category feature has no
impact on interfaces.

The LTE3701: Counter Profiles Enhancements Including the UE Category feature has no
impact on network management tools.

impacts system performance and capacity.
g Note: A maximum of 20 counter profiles can be configured. Configuring a large number
of profiles is not recommended as it has an impact on the overall eNB capacity and
performance. Keeping the number of counter profiles as low as possible is advised.

Requirements

FDD TDD
System release FDD LTE 17A Not supported
Flexi Multiradio 10 BTS FL17A Not supported
Nokia AirScale BTS FL17A Not supported
Flexi Zone BTS FL17A Not supported
Flexi Zone Access Point FL17A Not supported
Cloud Flexi Zone Controller FL17A Not supported
OMS Support not required Not supported
204 © 2018 Nokia DN181051332 Issue: 01

UE Category

FDD TDD
NetAct NetAct 17.8 Not supported
MME Support not required Not supported
SAE GW Support not required Not supported
UE Support not required Not supported
Alarms
There are no alarms related to the LTE3701: Counter Profiles Enhancements Including
the UE Category feature.

There are no faults related to the LTE3701: Counter Profiles Enhancements Including
the UE Category feature.
Commands
There are no commands related to the LTE3701: Counter Profiles Enhancements
Including the UE Category feature.
Table 103 Existing counters related to LTE3701

Counter Counter name Measurement
ID
M8043C Number of times the RLF timer LTE RLF Statistics per PMQAP Profile
0 started per Profile
M8043C Number of times the RLF timer LTE RLF Statistics per PMQAP Profile
1 stopped per Profile
M8043C Number of successful RRC re- LTE RLF Statistics per PMQAP Profile
2 establishments before RLF
timer expiry per Profile
M8043C Number of failed RRC re- LTE RLF Statistics per PMQAP Profile
3 establishments before RLF
timer expiry per Profile
M8046C Avg Active UE per Cell per LTE Active Users and Latency Statistics
1 Profile per PMQAP Profile
M8046C Average PDCP SDU delay on DL LTE Active Users and Latency Statistics
2 DTCH for DRB per Profile per PMQAP Profile
M8046C Average HARQ transmission LTE Active Users and Latency Statistics
3 time per Profile per PMQAP Profile
M8047C IP Throughput data volume in LTE Data Volume and Throughput
0 DL per Profile Statistics per PMQAP Profile
M8047C IP Throughput data volume in LTE Data Volume and Throughput
1 UL per Profile Statistics per PMQAP Profile
M8047C IP Throughput time in DL per LTE Data Volume and Throughput
2 Profile Statistics per PMQAP Profile
DN181051332 Issue: 01 © 2018 Nokia 205

UE Category
Table 103 Existing counters related to LTE3701 (Cont.)

Counter Counter name Measurement
ID
M8047C IP Throughput time in UL per LTE Data Volume and Throughput
3 Profile Statistics per PMQAP Profile
M8047C PDCP SDU data volume on eUu LTE Data Volume and Throughput
4 Interface downlink per Statistics per PMQAP Profile
Profile
M8047C PDCP SDU data volume on eUu LTE Data Volume and Throughput
5 Interface uplink per Profile Statistics per PMQAP Profile
M8047C Number of TTIs in DL with at LTE Data Volume and Throughput
6 least one UE scheduled to Statistics per PMQAP Profile
receive user plane data per
Profile
M8047C Number of TTIs in UL with at LTE Data Volume and Throughput
7 least one UE scheduled to Statistics per PMQAP Profile
receive user plane data per
Profile
M8047C Initial burst scheduling LTE Data Volume and Throughput
8 delay in DL per Profile Statistics per PMQAP Profile
M8047C Number of initial bursts per LTE Data Volume and Throughput
9 Profile in DL Statistics per PMQAP Profile
M8048C Setup attempts for initial E- LTE ERAB Statistics per PMQAP Profile
0 RABs per Profile
M8048C Successfully established LTE ERAB Statistics per PMQAP Profile
1 initial E-RABs per QoS
Profile
M8048C E-RABs Normal releases per LTE ERAB Statistics per PMQAP Profile
2 Profile
M8048C E-RABs Abnormal releases per LTE ERAB Statistics per PMQAP Profile
3 Profile
M8048C In-session ERABs activity LTE ERAB Statistics per PMQAP Profile
4 time per Profile
M8048C Setup attempts for additional LTE ERAB Statistics per PMQAP Profile
5 E-RABs per Profile
M8048C Successfully established LTE ERAB Statistics per PMQAP Profile
6 additional E-RABs per QoS
Profile
M8048C Aggregated time for the LTE ERAB Statistics per PMQAP Profile
7 successful establishment of
additional E-RABs per profile
M8048C E-RABs All Abnormal releases LTE ERAB Statistics per PMQAP Profile
8 per Profile
M8048C E-RABs attempted to release LTE ERAB Statistics per PMQAP Profile
9 due to outgoing Intra LTE
Handover
M8048C E-RABs released due to LTE ERAB Statistics per PMQAP Profile
10 successful outgoing Intra LTE
Handover
206 © 2018 Nokia DN181051332 Issue: 01

UE Category
For counter descriptions, see LTE Radio Access Operating

Documentation/Reference/Counters and Key Performance Indicators.

There are no key performance indicators related to the LTE3701: Counter Profiles
Enhancements Including the UE Category feature.
Parameters
g Note: The following parameters are removed from PMQAP managed objects class
since 17A release, due to LTE3701:
• QCI Configuration (cfgQCI)
• ARP Configuration (cfgARP)

object
QCI Configuration cfgQCIRange PMQAP - FDD
Range
ARP Range cfgARPRange PMQAP - FDD
Configuration
UE Category cfgUECategory PMQAP - FDD

object
Priority cfgPri PMQAP - common
configuration
PLMN ID pLMNID PMQAP - common
configuration
MCC of PLMN ID cfgMCC PMQAP pLMNID common
MNC length of PLMN cfgMNCLength PMQAP pLMNID common
ID
MNC of PLMN ID cfgMNC PMQAP pLMNID common
g Note: The Priority configuration (cfgPRI) parameter was introduced by

the LTE2782: RRC Re-establishment and RLF PM Counters per QCI Profile feature.
For parameter descriptions, see LTE Radio Access Operating

Documentation/Reference/Parameters.
Sales information

BSW - Yes
DN181051332 Issue: 01 © 2018 Nokia 207

LTE3778: User throughput to include the Initial Burst LTE17A Operability Features
Delay
24 LTE3778: User throughput to include the

Initial Burst Delay
The LTE3778: User throughput to include the Initial Burst Delay feature introduces an
update to monitor user throughput allowing the operator to assess the Quality of Service
(QoS) of the eNodeB (eNB). The LTE3778 feature also provides visibility for the total
number of initial bursts, allowing operators to better assess the impact of traffic to
throughput from the end user's perspective.

The LTE3778: User throughput to include the Initial Burst Delay feature improves system
monitoring capabilities, particularly for the QoS.
The LTE3778 feature introduces new counters to improve QoS monitoring capabilities:
• visibility of the initial burst waiting for scheduling delay, regardless of Discontinuous
Reception (DRX) configuration or with DRX state off
• visibility of the initial burst scheduling delay
• visibility of the UL Grant after Scheduling Request delay
For the list of related counters, see Table 108: New counters introduced by LTE3778.

There are no interdependencies between the LTE3778: User throughput to include the
Initial Burst Delay feature and any other feature.
The LTE3778: User throughput to include the Initial Burst Delay feature impacts
• Network element external interfaces:
– Support for configuration of the counters in NetAct and eNB is introduced.
– Support for new counters between eNB, Operation and Management Server
(OMS), and NetAct is introduced.

The LTE3778: User throughput to include the Initial Burst Delay feature has no impact on
network management tools.
208 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3778: User throughput to include the Initial Burst
Delay

The LTE3778: User throughput to include the Initial Burst Delay feature has no impact on
system performance or capacity.

Requirements

FDD TDD
System release FDD-LTE 17A Not supported
Nokia AirScale BTS FL17A Not supported
Flexi Zone BTS FL17A Not supported
Flexi Zone Access Point FL17A Not supported
Cloud Flexi Zone Controller FL17A Not supported
OMS OMS 17 Not supported
NetAct NetAct 17.8 Not supported
MME Support not required Not supported
SAE GW Support not required Not supported
UE Support not required Not supported
Alarms
There are no alarms related to the LTE3778: User throughput to include the Initial Burst
Delay feature.

There are no faults related to the LTE3778: User throughput to include the Initial Burst
Delay feature.
Commands
There are no commands related to the LTE3778: User throughput to include the Initial
Burst Delay feature.

M8012C197 Number of initial bursts LTE Cell Throughput
in Downlink
DN181051332 Issue: 01 © 2018 Nokia 209

LTE3778: User throughput to include the Initial Burst LTE17A Operability Features
Delay

M8012C198 Initial burst waiting for LTE Cell Throughput
scheduling applicability
delay in DL with DRX
M8012C199 Initial burst waiting for LTE Cell Throughput
scheduling applicability
delay in DL without DRX
M8012C200 Initial burst scheduling LTE Cell Throughput
delay in DL
M8026C284 Number of bursts in UL LTE QoS
M8026C285 UL Grant after SR LTE QoS
reception delay
M8047C8 Initial burst scheduling LTE Data Volume and Throughput
delay in DL per Profile Statistics per PMQAP Profile
M8047C9 Number of initial bursts LTE Data Volume and Throughput
per Profile in DL Statistics per PMQAP Profile
g Note: The U-Plane counters listed are not supported with FZM one cell deployment.
g Note: The M8026C284 counter is named Number of bursts in UL. It is

implemented, however, as Number of UL Grants after SR.
For counter descriptions, see the LTE Measurements, Counters, and KPIs reference

document.

The key performance indicators related to the LTE3778: User throughput to include the
Initial Burst Delay feature will be available at a later release.
Parameters
There are no parameters related to the LTE3778: User throughput to include the Initial
Burst Delay feature.
Sales information

210 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3831: System Upgrade to FDD-LTE 17A and TD-
LTE 17A
25 LTE3831: System Upgrade to FDD-LTE 17A

and TD-LTE 17A
The LTE3831: System Upgrade to FDD-LTE 17A & TD-LTE 17A feature supports a
system upgrade for the following releases:
• From FDD-LTE 16 to FDD-LTE 17A (or FDD-LTE 17ASP1)
• From TD-LTE 16 to TD-LTE 17A
• From FDD-LTE 16A to FDD-LTE 17A (or FDD-LTE 17ASP1)
• From TD-LTE 16A to TD-LTE 17A
In addition, an upgrade from FDD-LTE 17A to FDD-LTE 17ASP1 is supported.
Please note that an upgrade to LTE 17ASP1 is only available for FDD-LTE.
A system upgrade from LTE 16 release or LTE 16A release to LTE 17A release (or FDD-
LTE 17ASP1 release) for Flexi Zone (FZ) stand-alone outdoor and indoor small cells and
controller configuration is also supported.
For AirScale, an upgrade from LTE 16A is supported.

The LTE3831: System Upgrade to FDD-LTE 17A & TD-LTE 17A feature provides the
option to upgrade the system in a single step.

The system upgrade is possible in one step, and an installation of intermediate software
version is not needed. The LTE3831: System Upgrade to FDD-LTE 17A & TD-LTE 17A
feature includes backward compatibility and enables an automatic fallback or rollback to
the previous release that had been activated before the upgrade. The following network
elements (NEs) are impacted:
• Flexi Multiradio BTS
• Flexi Zone (FZ)
• NetAct including the Optimizer, TraceViewer and Northbound interfaces
• Operation and management server
• Traffica
• Layer 3 Data Collector (L3DC) with its applications as layer 3 data analyzer
• Self-organizing network (SON) manager
g Note: The upgrade of all eNBs in the network may take up to several days, depending
on the upgrade procedure followed by the operator. During this transition period NetAct
and LTE OMS are able to manage eNBs of the former release (LTE 16, LTE 16A) and
the new one (LTE 17A) in parallel.
Software upgrade from FDD-LTE 16 to FDD-LTE 17A
The system upgrade supports the following software upgrades:
DN181051332 Issue: 01 © 2018 Nokia 211

LTE3831: System Upgrade to FDD-LTE 17A and TD- LTE17A Operability Features
LTE 17A
• NetAct 16.2 to NetAct 17.8 SP1711
• LOMS 16 to LOMS 17A
• Traffica 16 to Traffica 17.8
• L3DC 16 to L3DC DCAP17 FP4
• eNB upgrades:
– FL 16 to FL 17A
– FLF 16 to FLF 17A
– FLC 16 to FLC 17A
Software upgrade from FDD-LTE 16A to FDD-LTE 17A

• LOMS 16A to LOMS 17A
• Traffica 16.5 to Traffica 17.8
• L3DC 16.5 to L3DC DCAP17 FP4
• eNB upgrades:
– FL 16A to FL 17A
– FLF 16A to FLF 17A
– FLC 16A to FLC 17A
Software upgrade from TD-LTE 16 to TD-LTE 17A

• LOMS 16 to LOMS 17A
• Traffica 16 to Traffica 17.8
• L3DC 16 to L3DC DCAP17 FP4
• eNB upgrades:
– TL 16 to TL 17A
– TLF 16 to TLF 17A
– TLC 16 to TLC 17A
Software upgrade from TD-LTE 16A to TD-LTE 17A

• LOMS 16A to LOMS 17A
• Traffica 16.5 to Traffica 17.8
• L3DC 16.5 to L3DC DCAP17 FP4
• eNB upgrades:
– TL 16A to TL 17A
212 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
– TLF 16A to TLF 17A
– TLC 16A to TLC 17A
g Note: There are different L3DC packages for each eNB release as shown in the table:
FDD-LTE 17A FDD-LTE 17ASP1

DCAP17 FP4 DCAP18
f Once the software download has completed, it is recommended to activate the software
shortly afterwards. If a critical error causes the eNB to reboot and the eNB fails to boot
onto the file system with the current running software it boots on to the file system with
the inactivated software that was just downloaded. Although this is a double-fault
scenario, the eNB may end up uncommissioned.
Backward compatibility
Backward compatibility means that interworking between the upgraded and the non-
upgraded network elements is possible during the system upgrade.
g Note: All hardware related outages on a network element must be resolved before that
network element, or subtending network element's managed by that network element
can be upgraded. For example, any iOMS hardware issues should be resolved before
upgrading that LTE OMS or any eNBs currently assigned to that LTE OMS.
g Note: All network elements must run the same release before upgrade is started.
Software packages including the software files for the new release LTE 17A are
available.
g Note: If Traffica and L3DC are to be involved in the system upgrade, the interface
between them and L3DC and eNB is working. If Traffica is to be involved in the system
upgrade, a valid upgrade licence for Traffica shall be available.
Data migration
All operator-configured data is stored in the system. Configuration data created in the
earlier release is automatically converted into a new format that is valid for the new
release during the upgrade. The data includes the following:
• All configuration data of the Flexi Multiradio BTS
• Customized view in the Network Element Manager or NetAct user-specified accounts
and passwords
• User-specified accounts and passwords
The following system data should be uploaded or backed up before the upgrade:
• Network security-related system data (such as certificates and keys)
• User security-related data (such as user accounts and passwords)
• Performance measurement (PM) data
g Note: PM data which is not yet uploaded to NetAct before the activation of system
upgrade in a Flexi Multiradio BTS will be lost.
DN181051332 Issue: 01 © 2018 Nokia 213

LTE 17A
g Note: Software backup only applies to OMS. The operation does not cause an outage,
and it runs in the background.
If there are used command lines or scripts, they must be backward compatible, or a
converter must be available for the supported upgrade paths. The software converter is
available in an online or offline mode.
Software fallback
Software fallback is an automatic activation of an earlier software version that is active
before the software upgrade. Fallback is triggered when the eNB or OMS cannot activate
its new software version or use a new database configuration version. After a successful
fallback, the passive software build is active in all the hardware units. All of the
components activate the stored configuration data without reverse migrating or
converting to new configuration data.
g Note: In case of an upgrade failure, an automatic fallback to the original release takes
place. The log files include detailed information about the reasons, and the information
is logged into non-volatile memory.
The automatic fallback is available for Flexi Multiradio BTS, Flexi Zone.
g Note: In case of an inconsistent fallback, where the eNB does not locally store the
complete fallback software for all the hardware units, a software download from NetAct
is requested.
g Note: A software fallback causes an NE outage, and it causes the BTS to reset. The
outage time is approximately the same as reboot duration.
Software rollback
Software rollback is a manually initiated software fallback, using the Network Element
Manager or NetAct software management (SWM). The operator can trigger software
rollback when key services are not successfully activated after the software upgrade.
Any configuration updates done with the new software are lost as soon as software
rollback is triggered. Software rollback is only guaranteed if the source software version
has not been removed or overwritten in a non-volatile storage (NVS). Software rollback
is done with the software stored in the passive file system and when no software
download from the server is part of the operation. If the passive software has been
overwritten with a different software version, a rollback to the former release is not
possible.
g Note: Software rollback to the stored software load restores the earlier configuration. If
there has been a major network reconfiguration after the upgrade, such as
reconfiguring the eNB from IPv4 to IPv6 or updating operator certificates, then network
connectivity issues can occur after the rollback. Reconfigurations after the software
upgrade must be evaluated before triggering software rollback to avoid service outage.
Software rollback for a single eNB or for eNBs in bulk can be done using the NetAct
SWM. For more information, see the Software Manager Help document under Network
Administration in NetAct Operating Documentation. Software rollback for a single eNB
can also be done using the Rollback to Passive SW function in the Update SW to BTS
Site window on Network Element Manager.
If the operator selects a software version that is older than the current software version in
the Update SW to BTS Site window on Network Element Manager and clicks Update, a
software downgrade takes place.
214 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
g Note: Software downgrade must not be executed. A downgrade to an earlier software
version is not guaranteed and might end up in an uncommissioned state of the eNB.
g Note: A software rollback operation from NetAct might interrupt ongoing local
operations triggered from Network Element Manager such as commissioning without a
local user warning.
g Note: A software rollback causes an NE outage, and it causes the BTS to reset. The
outage time is approximately the same as reboot duration.

As specified in LTE2378: FSM D/E (FSMr2) Support after FDD-LTE 15A feature, the
FSMr2 software is frozen on FDD-LTE 15A. The LTE-FDD 17A software packages may
contain FDD-LTE 15A updates for FSMr2, but the FSMr2 will report its software version
as FDD-LTE 15A. Note that this depends on the latest FDD-LTE 15A always being
included in the LTE 17A eNB software build.
This feature uses requirements specified in previous LTE software management and
system upgrade features.
The following upgrade requirements/features of earlier FDD releases are supported :
• FDD-LTE 16A LTE2633
• FDD-LTE 16 LTE2341
• FDD-LTE 15A LTE2049
• RL70 LTE1854
• RL60 LTE1560
• RL50 LTE1368
• RL40 LTE1078
• RL30 LTE882
• RL20 LTE185
g Note: This feature utilizes both the OM_GEN_SFS_RNWINT and
OM_GEN_SFS_SWMGMNT SFS use cases and functional requirements created or
updated for LTE3831 as the use cases and functional requirements for the previous
release LTE system upgrade features listed above.
The following upgrade requirements/features of earlier TDD releases are supported :
• TD-LTE 16A LTE2658
• TD-LTE 16 LTE2326
• TD-LTE 15A LTE2053
• RL55 LTE1735
• RL45 LTE1675 (and LTE1758)
• RL35 LTE1473
DN181051332 Issue: 01 © 2018 Nokia 215

LTE 17A
The LTE3831: System Upgrade to FDD-LTE 17A & TD-LTE 17A feature has no impact

on interfaces.

The LTE3831: System Upgrade to FDD-LTE 17A & TD-LTE 17A feature impacts system
performance and capacity as follows:
• The end user will experience a service degradation and partial service loss during
the system upgrade.
• The downtime for the network entities is reduced to the activation of the new
software during the system upgrade.

The performance of the LTE 17A network elements during upgrade is expected to be the
same as the LTE 16A network elements. The existing LTE eNB and LTE OMS upgrade-
related performance requirements apply to the LTE 17A upgrade.
The existing LTE eNB and LTE OMS upgrade-related capacity requirements apply to the
LTE 17A upgrade.

Requirements

FDD TDD
Flexi Multiradio 10 Indoor BTS Not supported TL17A
Flexi Zone BTS FL17A Support not needed
OMS LTE OMS17A LTE OMS17A
UE Support not needed Support not needed
Alarms
There are no alarms related to the LTE3831: System Upgrade to FDD-LTE 17A & TD-
LTE 17A feature.
Commands
216 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
There are no commands related to the LTE3831: System Upgrade to FDD-LTE 17A &

TD-LTE 17A feature.

There are no measurements or counters related to the LTE3831: System Upgrade to
FDD-LTE 17A & TD-LTE 17A feature.

There are no key performance indicators related to the LTE3831: System Upgrade to
FDD-LTE 17A & TD-LTE 17A feature.
Parameters
There are no parameters related to the LTE3831: System Upgrade to FDD-LTE 17A &
TD-LTE 17A feature.
Sales information

Basic Software (BSW) Not supported Yes
25.5 Upgrading the LTE eNB to LTE 17A

Purpose
There have been changes to the eNB information model in the LTE17A release that
cause some of the existing (old LTE16/LTE16A) object instances to be removed and
modeled elsewhere. When an upgraded LTE17A version eNB is uploaded to NetAct
Configurator, the non-network configuration data is not available for the old object
instances that do not exist anymore. To retain all non-network parameter data,
maintenance region and site assignment configurations in the LTE17A eNB, the
Upgrade - LTE BTS workflow operations need to be executed in NetAct Configurator as
part of the LTE17A upgrade process.
The workflow supports the move of the following non-network configuration data:
• Maintenance region (MR) and Site assignment for the objects: MRBTS, ANTL,
APMOD, BBMOD, RMOD, SMOD, SRCU
• LNCEL: RACH density (rachDensity parameter)
• ANTL parameters:
– Altitude
– Antenna bearing
– Antenna Directivity
– Antenna Horizontal Beamwidth
– Antenna total tilt
– Antenna Vertical Beamwidth
– Height
– Latitude
DN181051332 Issue: 01 © 2018 Nokia 217

LTE 17A
– Line Loss
– Longitude
– User-defined state
– Antenna Type - Antenna Type
– Antenna Type - Deployment Mode
– Antenna Type - Transmission Type
• ECREL object and the Target cell DN parameter
g Note: This workflow does not need to be run in case the above non-network
configuration data in NetAct has not been used. The non-network parameter data of the
MRBTS object and LNBTS object tree (including all the children) is retained without
running the Upgrade-LTE BTS workflow operations.
Things that should be considered for the LTE 17A upgrade:
• Some objects are moved in the object hierarchy and these objects may contain a
somewhat different parameter set in the new LTE 17A model. If those objects had a
parameter template assigned in the old model, that assignment is not available for
the object in the new LTE 17A model. The parameter templates should be checked
and assigned manually for the objects, if needed.
• CM Reference delta resolution (reference alignment or network update) is not
possible for the parameters that change hierarchy in the LTE 17A model. Nokia
recommends that the CM Reference delta should be fully resolved before upgrading
the eNB to LTE 17A.
• Although there is no limit for the maximum number of eNBs that the workflow is able
to process, the capacity and performance of the workflow is tested with 500 eNBs.
• For more information about the LTE 17A model, see Upgrading to LTE17A in
Release Changes.
g Note: Please note that the Passive Software Version indicates both the latest active
and planned software versions when viewed in NetAct or Network Element Manager.
Both software versions on the passive side are visible if you do an upgrade only where
the planned load without activation was downloaded. This does not mean that you have
three loads now in eNB and that you can do rollback to last active load in this state,
because last active load is overwritten in the meantime with the planned load. This
function is part of a software enhancement feature planned for further releases. When
you activate the planned software and after eNB comes up with this new planned load,
only the last active load on passive side is visible again.
Before you start

The operation is supported for macro and micro eNBs releases:
• From FDD-LTE16 or FDD-LTE16A to FDD-LTE17A
• From TD-LTE16 or TD-LTE16A to TD-LTE17A
t Tip: Please note that in LTE 17A, the validation check is missing. Take care that during
configuration of the LTE 17A, the conditions described in the validation check must be
fulfilled. In case the configuration in LTE 17A does not meet the described conditions,
related parameters must be reconfigured to the desired needs and deployment
scenario, so that the conditions are fulfilled. This must be done before a future upgrade
to LTE 18, where the missing validation check is introduced.
218 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
Make sure that Intelligent Configuration Synchronization is disabled (recommended).
Working sets are done for grouping the eNBs as the scope for upgrade operations.
Procedure
1 In NetAct Start Page click on CM Operations Manager.
Step result
The CM Operations Manager window opens.
Figure 37 CM Operations Manager window
2 In the Tools menu choose Workflow Engine.
Step result
The Workflow Engine dialog opens.
DN181051332 Issue: 01 © 2018 Nokia 219

LTE 17A
Figure 38 Workflow Engine window
220 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
3 From the Operation list drop-down list, select Upgrade - LTE BTS.
Figure 39 Upgrade-LTE BTS option
DN181051332 Issue: 01 © 2018 Nokia 221

LTE 17A
4 In the Working set select the working set or sets containing LTE 16/LTE 16A MRBTSs to
be upgraded.
Figure 40 Working set selection
222 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
5 Run the Prepare for upgrade operation before the software upgrade to ensure that the

parameters are up to date.
Figure 41 Prepare for upgrade operation
Step result
LTE 16 and LTE 16A non-network data is stored into data export files.
DN181051332 Issue: 01 © 2018 Nokia 223

LTE 17A
6 In the NetAct Start Page click on Software Manager.
Figure 42 Software Manager selection
Step result
The Software Manager application opens.
7 Using Software Manager, upgrade the LTE 17A software build for the eNBs.
Note that you can use the same working set as the Configurator. For more details,
see Updating/upgrading software on network elements in Software Manager Help.
g Note: Network Element Manager can also be used for the upgrade.
224 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
8 In the Workflow Engine, continue the workflow by selecting Upload configuration data.
Figure 43 Upload configuration data option
DN181051332 Issue: 01 © 2018 Nokia 225

LTE 17A
9 Click the Start icon next to the operation. Click Start.
Figure 44 Upload configuration data operation selection
226 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
10 Update the Configurator non-network data to the LTE 17A MRBTSs by selecting Update
non-network parameter data and clicking Start icon next to the operation. Click Start.
Figure 45 Update non-network data operation
g Note: Cleanup obsolete LTE MRBTS data after upgrade is executed automatically

after a successful Update non-network parameter data operation and a similiar
operation is executed in case of a rollback. These operations remove MRBTS actual
data from the database that is not needed anymore.
If the cleanup operation fails, you can check the reason for the failure by executing the
doctor case in reporting mode in dmgr VM as the omc user.
[omc]$ /opt/oss/NSN-doctor-v2/bin/doctormx.sh -case --run
CMCleanMRBTSData --param action=report
Cleanup obsolete LTE MRBTS data after upgrade can also be executed manually in
dmgr VM as the omc user:
CMCleanMRBTSData --param action=correct
For more information about NetAct Doctor, see NetAct Doctor Usage.
Result
• The eNB is upgraded to LTE 17A software version.
• The eNB configuration (according to the new information model) is synchronized to
the Configurator configuration database.
DN181051332 Issue: 01 © 2018 Nokia 227

LTE 17A
• The non-network configuration is available in the Configurator in the LTE 17A version
eNB objects.
g Note: After the eNB upgrade to LTE 17A software version, you may see non-
operational objects in CM Editor object hierarchy view, for example: ANTL, RMOD or
RET. This is because you have the objects in an old configuration plan. Such a plan
may not be usable with the new LTE 17A model and therefore the plan should be
deleted.
25.6 Rolling back the LTE 17A upgrade

Before you start
• LTE 17A software upgrade has been completed for the eNB following the procedure
described in Upgrading the LTE eNB to LTE 17A.
• Intelligent Configuration Synchronization is disabled (recommended).
Operation is supported for macro eNB and micro eNB releases:
• From FDD-LTE17A to FDD-LTE16 or FDD-LTE16A
• From TD-LTE17A to TD-LTE16 or TD-LTE16A
Procedure
1 In NetAct Start Page click on Software Manager.
Step result
The Software Manager application opens.
2 Using the Software Manager, roll back the LTE 17A software build for the eNB. For more
details, see Software Manager Help.
g Note: Network Element Manager can also be used for the rollback procedure.
Step result
The software version of the eNB is rolled back to the one previously installed (LTE16
or LTE16A).
3 In NetAct Start Page click on CM Operations Manager.
Step result
The CM Operations Manager dialog opens.
228 © 2018 Nokia DN181051332 Issue: 01

LTE 17A
4 In the Tools menu choose Workflow Engine.
Step result
The Workflow Engine dialog opens.
5 From the Operation list drop-down list, select Upgrade - LTE BTS.
6 Drag and drop the eNB to the MO(s) window.
7 In the Start column, click the Start icon next to Upload configuration data after

rollback operation. Click Start.
Step result
LTE 16 or LTE 16A data is uploaded.
8 In the Start column, click the Start next to Update non-network parameter data after

data rollback operation. Click Start.
g Note: Cleanup obsolete LTE MRBTS data after upgrade is executed automatically

after a successful Update non-network parameter data operation and a similiar
operation is executed in case of a rollback. These operations remove MRBTS actual
data from the database that is not needed anymore.
If the cleanup operation fails, you can check the reason for the failure by executing the
doctor case in reporting mode in dmgr VM as the omc user.
CMCleanMRBTSData --param action=report
Cleanup obsolete LTE MRBTS data after upgrade can also be executed manually in
dmgr VM as the omc user:
CMCleanMRBTSData --param action=correct
For more information about NetAct Doctor, see NetAct Doctor Usage.
Step result
• LTE 16 or LTE 16A non-network data is restored
• Non-network configuration in Configurator has been restored to the earlier state
Result
• eNB is rolled back to LTE16/LTE16A software version
• eNB configuration is synchronized to the Configurator actual configuration database
• Non-network configuration in Configurator has been restored to the earlier state
DN181051332 Issue: 01 © 2018 Nokia 229

LTE3841: Cloud Flexi Zone Controller and Wireless LTE17A Operability Features
LAN Controller All-In-One
26 LTE3841: Cloud Flexi Zone Controller and

Wireless LAN Controller All-In-One
The cloud Flexi Zone Controller (cFZC) is a virtual function running on a fully featured,
energy efficient 2-socket Nokia AirFrame server platform and interfaces with the Virtual
Network Function (VNF) Manager.
Figure 46 cFZC features distribution
CloudFlexiZoneControllerfunctionality
FL17A
LTE3042-CloudFlexi LTE3841- CloudFlexiZone

ZoneController ControllerandWireless
LANControllerAll-In-One
feature provides a cloud-based controller solution to host both Flexi Zone Controller
(FZC) and Wireless LAN Controller (WLC) concurrently on a Nokia Radio Cloud Platform
(RCP) to support simultaneous LTE and WiFi deployments.

feature provides the following benefits:
• Allows the independent upgrade of the cFZC and cWLC Virtual Network Functions.
• Provides a single controller for both LTE and WiFi services simultaneously.

Feature overview
feature extends the architecture introduced by LTE3042: Cloud Flexi Zone Controller.
The Cloud Flexi Zone Controller feature leverages AirFrame hardware and Flexi Zone
Micro (FZM) BTS devices configured as Flexi Zone Access Points (FZAPs) to implement
a cloud-based Zone eNodeB (ZeNB). The cloud-based ZeNB is comprised of a cFZC
and one or more FZAPs.
provides a distributed cloud Flexi Zone Controller (cFZC) and cloud Wireless Lan
Controller (cWLC) on a single Nokia AirFrame hardware running RCP Guest operating
system and NCIR host operating system. The feature also provides application-scaling
capability, supporting deployments for up to 100 LTE pico/micro and up to 500 WiFi APs
concurrently.
230 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3841: Cloud Flexi Zone Controller and Wireless
The following figure shows an overview of the All-In-One (AiO) co-hosted Cloud Flexi
Zone Controller (cFZC) and Cloud Wireless LAN Controller (cWLC):
Figure 47 Architecture overview
iOMS/NetAct FZAP AAA/Captive Portal Nokia AP
FZAP Alarm/Event Manager Nokia AP
Local Mgr File Server NetAct
FZAP Nokia AP
NTP Server
EPC Up to 100
Up to 500
cFZC (Flexi Zone Controller VNF) cWLC (Wireless LAN Controller VNF)
RCP RCP RCP RCP RCP RCP
NCIR/Host Platform (Hypervisor, OpenStack, Accelerated vSwitch)
Cloud HW/Airframe
Cloud FZC distributed deployment (single blade)

The cFZC distributed deployment model introduced in the LTE3841: Cloud Flexi Zone
Controller and Wireless LAN Controller All-In-One feature is based on the Nokia
AirFrame Cloud Infrastructure for Real-time applications (NCIR) Release 17 All-in-One
(AiO) without server redundancy configuration, and has the following capabilities:
• Single node distributed cFZC configuration, which is the BCN replacement.
• Support for 100 cells.
• Optional type/model of Top of Rack (ToR) switch, depending on customer
configuration.

feature is impacted by the following features:
• LTE3042: Cloud Flexi Zone Controller
The LTE3042: Cloud Flexi Zone Controller feature provides the basic capability to
host Flexi Zone Controller (FZC) Application on the Nokia Radio Cloud Platform
(RCP).
feature impacts interfaces as follows:
• FZC north bound interface (backhaul)
– The FZC north bound interface consists of the S1, X2, BTSOM, and NE3S
interfaces.
• FZC south bound interface (fronthaul, called Z1 interface)
DN181051332 Issue: 01 © 2018 Nokia 231

LTE3841: Cloud Flexi Zone Controller and Wireless LTE17A Operability Features
– The FZC south bound interface carries the C-Plane, U-Plane, and M-Plane
messages.

feature has no impact on network management tools.

feature impacts system performance and capacity as follows:
• The cFZC supports up to 100 cells for distributed use cases.

Requirements

FDD TDD
Flexi Multiradio 10 BTS Support not required Support not required
Flexi Multiradio 10 Indoor BTS Support not required Support not required
Nokia AirScale BTS Support not required Support not required
Flexi Zone BTS Support not required Support not required
OMS LTE17A LTE17A
NetAct LTE17A LTE17A
Alarms
There are no alarms related to the LTE3841: Cloud Flexi Zone Controller and Wireless
LAN Controller All-In-One feature.

There are no faults related to the LTE3841: Cloud Flexi Zone Controller and Wireless
LAN Controller All-In-One feature.
Commands
There are no commands related to the LTE3841: Cloud Flexi Zone Controller and
Wireless LAN Controller All-In-One feature.
232 © 2018 Nokia DN181051332 Issue: 01

LTE17A Operability Features LTE3841: Cloud Flexi Zone Controller and Wireless

There are no measurements or counters related to the LTE3841: Cloud Flexi Zone
Controller and Wireless LAN Controller All-In-One feature.

There are no key performance indicators related to the LTE3841: Cloud Flexi Zone
Controller and Wireless LAN Controller All-In-One feature.
Parameters
There are no parameters related to the LTE3841: Cloud Flexi Zone Controller and
Wireless LAN Controller All-In-One feature.
Sales information

Basic Software (BSW) - No
Refer to the following documents for more information about the Cloud Flexi Zone
Controller and the Wireless LAN Controller:
• Cloud Flexi Zone Controller Product Description
• Commissioning Cloud Flexi Zone Controller
• Administering Cloud Flexi Zone Controller
• Installing Nokia AirScale Wi-Fi
DN181051332 Issue: 01 © 2018 Nokia 233

Operability Features Description - FL17A

Uploaded by

Copyright:

Available Formats

Operability Features Description - FL17A

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Operability Features Description - FL17A

Uploaded by

Copyright:

Available Formats

What is the document about?

What is the document about?

What interfaces does the Flexi Zone Controller impact?

What interfaces does the Flexi Zone Controller impact?

Single RAN, Rel.

LTE17A Operability Features

f Important Notice on Product Safety

Figure 34 Load the Gateway............................................................................ 191

1 LTE529: Dynamic X2 and S1 Firewall

1.1 LTE529 benefits

1.2 LTE529 functional description

X2 and S1 firewall rules

1.3 LTE529 system impact

Interdependencies between features

System behaviour when upgrading from previous release

Changing of an eNB’s local user plane address and necessary actions

1.4 LTE529 reference data

For parameter descriptions, see LTE Operating Documentation/Reference/Parameters

1.5 Enabling dynamic firewall configuration

Before you start

5 Optional: Proceed to the Radio Network Configuration page.

The C-Plane IP address control (cPlaneIpAddrCtrl) in LNADJ

1.6 Disabling dynamic firewall configuration

Before you start

6 Optional: Proceed to the Radio Network Configuration page.

2 LTE1523: Role-based BTS User Accounts

The LTE1523: Role-based BTS User Accounts feature introduces the following

2.1 LTE1523 benefits

2.2 LTE1523 functional description

Activation always active must first be must first be must first be

2.3 LTE1523 system impact

Interdependencies between features

The LTE1523: Role-based BTS User Accounts feature has no impact on interfaces,

2.4 LTE1523 reference data

Measurements and counters

Key performance indicators

For parameter descriptions, see LTE Operating Documentation/Reference/Parameters

2.5 Activating and configuring local accounts

Before you start

2 From the upper menu select Configuration ► Change Local Account.

2.6 Deactivating role-based local accounts

Before you start

2 From the upper menu select Configuration ► Change Local Account.

In order to disable an account, you need to uncheck the Enable user account

2.7 Managing local accounts using NetAct

3 RAN3379: Enhanced Flexi Zone Plug and Play

Vendorspecific Yes LEARN

RAN3379 Yes KNOW

g Note: Primary and secondary FQDNs or IP addresses:

Initialsecurity DHCP DNS CA

Use case 3: Creation / Modification of auto-connection parameters for non-

Impact on network management tools

Impact on system performance and capacity

3.1 RAN3379 reference data

Additional hardware requirements

BTS faults and reported alarms

There are no faults related to the RAN3379: Enhanced Flexi Zone Plug and Play for

Measurements and counters

Key performance indicators

Vendorspecific Yes LEARN

Initialsecurity DHCP DNS CA

LTE3042-CloudFlexi LTE3841- CloudFlexiZone