Nb-Iot Basics (FDD) (Eran15.1 - Draft A)

eRAN
NB-IoT Basics (FDD) Feature

Parameter Description
Issue Draft A
Date 2019-01-05
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. i

eRAN
NB-IoT Basics (FDD) Feature Parameter Description Contents
Contents
1 Change History.............................................................................................................................. 1
1.1 eRAN15.1 Draft A (2019-01-05)................................................................................................................................... 1
2 About This Document.................................................................................................................. 5

2.1 General Statements......................................................................................................................................................... 5
2.2 Applicable RAT.............................................................................................................................................................. 6
2.3 Features in This Document.............................................................................................................................................6
2.4 Feature Differences Between NB-IoT and FDD............................................................................................................ 8
3 Overview....................................................................................................................................... 15
3.1 NB-IoT Spectrum Deployment Modes.........................................................................................................................16
3.2 Physical Layer.............................................................................................................................................................. 18
3.2.1 Physical Layer Management..................................................................................................................................... 18
3.2.2 Frequency-Domain Structures of Physical Channels................................................................................................ 19
3.2.3 Time-Domain Structures of Physical Channels.........................................................................................................20
3.2.4 Single-Tone Transmission......................................................................................................................................... 22
3.3 Data Transmission Optimization.................................................................................................................................. 22
3.3.1 Data over NAS...........................................................................................................................................................22
3.3.2 Data over User Plane................................................................................................................................................. 23
3.4 NB-IoT UE Requirements............................................................................................................................................ 24
3.4.1 NB-IoT UE Categories.............................................................................................................................................. 24
3.4.2 Compatibility............................................................................................................................................................. 25
4 Principles.......................................................................................................................................26
4.1 Cell Management..........................................................................................................................................................26
4.1.1 NB-IoT Cell............................................................................................................................................................... 26
4.1.2 PRB............................................................................................................................................................................26
4.2 Idle Mode Management................................................................................................................................................28
4.2.1 Cell Selection and Reselection.................................................................................................................................. 30
4.2.2 System Information Broadcast.................................................................................................................................. 32
4.2.3 Paging........................................................................................................................................................................ 32
4.3 Random Access............................................................................................................................................................ 34
4.3.1 Overview................................................................................................................................................................... 34
4.3.2 Random Access Procedure........................................................................................................................................ 35
4.3.3 NPRACH Resource Configuration............................................................................................................................37
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. ii

eRAN
4.3.4 NPRACH Detection Threshold................................................................................................................................. 40

4.3.5 Optimization Against NPRACH False Detection..................................................................................................... 40
4.4 Connection Management.............................................................................................................................................. 41
4.4.1 RRC Connection Setup..............................................................................................................................................41
4.4.2 RRC Connection Resume.......................................................................................................................................... 42
4.4.3 RRC Connection Reestablishment............................................................................................................................ 44
4.4.4 MME Selection for NB-IoT...................................................................................................................................... 48
4.4.5 Data Transmission..................................................................................................................................................... 48
4.4.6 Signaling Connection Release................................................................................................................................... 52
4.4.7 DRB Management..................................................................................................................................................... 54
4.4.8 UE Information Retrieval Procedure......................................................................................................................... 56
4.5 Scheduling.................................................................................................................................................................... 58
4.5.1 Definition...................................................................................................................................................................58
4.5.2 Scheduler Principles.................................................................................................................................................. 59
4.5.3 Uplink Scheduling..................................................................................................................................................... 60
4.5.3.1 Uplink Scheduling Procedure................................................................................................................................. 60
4.5.3.2 Uplink Scheduling Triggering................................................................................................................................ 61
4.5.3.3 Uplink Scheduling for Initial Transmissions.......................................................................................................... 61
4.5.3.4 Uplink Scheduling for Retransmissions................................................................................................................. 64
4.5.4 Downlink Scheduling................................................................................................................................................ 64
4.5.4.1 Downlink Scheduling Procedure............................................................................................................................ 64
4.5.4.2 Downlink Scheduling Triggering........................................................................................................................... 65
4.5.4.3 Downlink Scheduling for Initial Transmissions..................................................................................................... 65
4.5.4.4 Downlink Scheduling for Retransmissions............................................................................................................ 70
4.6 Power Control...............................................................................................................................................................70
4.6.1 Downlink Power Control...........................................................................................................................................71
4.6.1.1 NRS Power Allocation........................................................................................................................................... 71
4.6.1.2 NPDSCH Power Calculation..................................................................................................................................71
4.6.1.3 NPSS Power Calculation........................................................................................................................................ 73
4.6.1.4 NSSS Power Calculation........................................................................................................................................ 74
4.6.1.5 NPBCH Power Calculation.................................................................................................................................... 74
4.6.1.6 NPDCCH Power Calculation................................................................................................................................. 75
4.6.2 Uplink Power Control................................................................................................................................................75
4.6.2.1 NPRACH Power Control........................................................................................................................................75
4.6.2.2 NPUSCH Power Control........................................................................................................................................ 76
4.7 Access and Congestion Control....................................................................................................................................77
4.7.1 Admission Control.....................................................................................................................................................78
4.7.2 Congestion Control....................................................................................................................................................79
4.7.3 Overload Control....................................................................................................................................................... 81
4.7.4 Application Examples................................................................................................................................................83
4.8 DRX..............................................................................................................................................................................83
4.8.1 DRX-related Concepts...............................................................................................................................................83
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iii

eRAN
4.8.2 Startup of a DRX Cycle.............................................................................................................................................84

4.8.3 Operation in a DRX Cycle.........................................................................................................................................84
4.9 Cell Access Radius up to 35 km................................................................................................................................... 88
5 Network Analysis........................................................................................................................ 89
5.1 Standalone Deployment................................................................................................................................................89
5.1.1 Benefits...................................................................................................................................................................... 89
5.1.2 Impacts.......................................................................................................................................................................89
5.2 LTE Guard Band Deployment...................................................................................................................................... 90
5.2.1 Benefits...................................................................................................................................................................... 91
5.2.2 Impacts.......................................................................................................................................................................91
5.3 LTE In-Band Deployment............................................................................................................................................ 92
5.3.1 Benefits...................................................................................................................................................................... 93
5.3.2 Impacts.......................................................................................................................................................................93
6 Requirements............................................................................................................................. 102
6.1 Licenses...................................................................................................................................................................... 102
6.2 Software......................................................................................................................................................................102
6.3 Hardware.................................................................................................................................................................... 105
6.4 Networking................................................................................................................................................................. 106
6.4.1 NB-IoT PRB Planning.............................................................................................................................................106
6.4.2 NB-IoT Power Planning.......................................................................................................................................... 115
6.4.3 NB-IoT Site Planning.............................................................................................................................................. 115
6.5 Others..........................................................................................................................................................................115
7 Operation and Maintenance....................................................................................................116

7.1 Data Configuration..................................................................................................................................................... 116
7.1.1 Data Preparation...................................................................................................................................................... 116
7.1.1.1 Data Preparation for Activation............................................................................................................................116
7.1.1.2 Data Preparation for Optimization....................................................................................................................... 140
7.1.2 Using MML Commands.......................................................................................................................................... 152
7.1.2.1 Activation Command Examples (for DBS3900 LampSite and DBS5900 LampSite)......................................... 152
7.1.2.2 Activation Command Examples (for Base Stations Other Than DBS3900 LampSite and DBS5900 LampSite)
.......................................................................................................................................................................................... 155
7.1.2.3 Optimization Command Examples.......................................................................................................................158
7.1.2.4 Deactivation Command Examples....................................................................................................................... 159
7.1.3 Using the CME........................................................................................................................................................ 159
7.2 Activation Verification............................................................................................................................................... 159
7.3 Network Monitoring................................................................................................................................................... 159
8 Parameters................................................................................................................................... 162
9 Counters...................................................................................................................................... 163
10 Glossary..................................................................................................................................... 164
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iv

eRAN
11 Reference Documents............................................................................................................. 165
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. v

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 1 Change History
1 Change History
This chapter describes changes not included in the "Parameters", "Counters", "Glossary", and
"Reference Documents" chapters. These changes include:
l Technical changes
Changes in functions and their corresponding parameters
l Editorial changes
Improvements or revisions to the documentation
1.1 eRAN15.1 Draft A (2019-01-05)

This issue introduces the following changes to eRAN13.1 04 (2018-10-30).
Technical Changes
Change Description Parameter Change Base Station Model
Added the UE RLC status Added parameters: l 3900 and 5900 series
reporting function. For RECEPTION_FAIL_STA base stations
details, see 4.4.5 Data TUS_RPT_SW and l DBS3900 LampSite and
Transmission. ENODEB_TX_BYTE_PO DBS5900 LampSite
LLING_SW options of the
l BTS3912E
CellAlgoExtSwitch.NbCell
AlgoExtSwitch parameter l BTS3911E
Enabled the configuration of Added parameters: l 3900 and 5900 series

a guard band between UlGuardBandCfg.Nprach base stations
NPUSCH and NPRACH. NpuschGuardBand l DBS3900 LampSite and
For details, see Intra-PRB DBS5900 LampSite
Guard Bands.
l BTS3912E
l BTS3911E
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 1

eRAN
Added the uplink reverse None l 3900 and 5900 series

RU adjustment function. For base stations
details, see 4.5.3.3 Uplink l DBS3900 LampSite and
Scheduling for Initial DBS5900 LampSite
Transmissions.
l BTS3912E
l BTS3911E
Optimized cell selection and None l 3900 and 5900 series

reselection. For details, see base stations
4.2.1 Cell Selection and l DBS3900 LampSite and
Reselection. DBS5900 LampSite
l BTS3912E
l BTS3911E
Improved RRC connection Added parameters: l 3900 and 5900 series

release signaling RELEASE_PERFM_IMP base stations
performance. For details, ROVE_SWITCH option of l DBS3900 LampSite and
see 4.5.4.3 Downlink the DBS5900 LampSite
Scheduling for Initial CellAlgoExtSwitch.NbCell
Transmissions. l BTS3912E
AlgoExtSwitch parameter
l BTS3911E
Optimized uplink AMC. For None l 3900 and 5900 series

details, see 4.5.3.3 Uplink base stations
Scheduling for Initial l DBS3900 LampSite and
Transmissions. DBS5900 LampSite
l BTS3912E
l BTS3911E
Optimized downlink AMC. Added parameters: l 3900 and 5900 series

For details, see 4.5.4.3 DL_AMC_OPT_SWITCH base stations
Downlink Scheduling for option of the l DBS3900 LampSite and
Initial Transmissions. CellAlgoExtSwitch.NbCell DBS5900 LampSite
AlgoExtSwitch parameter l BTS3912E
l BTS3911E
Added the uplink None l 3900 and 5900 series

interference randomization base stations
function. For details, see l DBS3900 LampSite and
4.5.3.3 Uplink Scheduling DBS5900 LampSite
for Initial Transmissions.
l BTS3912E
l BTS3911E

eRAN
Added the NPDCCH and Modified parameters: l 3900 and 5900 series
NPDSCH interference Added the base stations
randomization function. For DL_INTRF_RANDOMIZ l DBS3900 LampSite and
details, see 4.5.4.3 ATION_SWITCH option DBS5900 LampSite
Downlink Scheduling for to the
Initial Transmissions. l BTS3912E
CellAlgoSwitch.NbCellAlg
oSwitch parameter. l BTS3911E
Added the RRC connection Modified parameters: l 3900 and 5900 series
reestablishment function in Added the base stations
control plane CIoT EPS CP_RRC_CONN_REEST l DBS3900 LampSite and
optimization mode. For ABLISHMENT_SW DBS5900 LampSite
details, see 4.4.3 RRC option to the
Connection l BTS3912E
CellAlgoSwitch.NbCellAlg
Reestablishment. oSwitch parameter. l BTS3911E
Optimized the NPDCCH Modified parameters: l 3900 and 5900 series

repetition count adjustment Enabled the base stations
mechanism. For details, see CellPdcchAlgo.PDCCHAg l DBS3900 LampSite and
4.5.4.3 Downlink gLvlAdaptStrage parameter DBS5900 LampSite
Scheduling for Initial to apply not only to TDD
Transmissions. l BTS3912E
but also to NB-IoT.
l BTS3911E
Optimized uplink power Modified parameters: l 3900 and 5900 series

control. For details, see Extended the value range of base stations
4.6.2.1 NPRACH Power the l DBS3900 LampSite and
Control and 4.6.2.2 RACHCfg.PreambInitRcv DBS5900 LampSite
NPUSCH Power Control. TargetPwr parameter. l BTS3912E
Added parameters: l BTS3911E
RACHCfg.PreambInitRcv
TargetPwrCE1 and
RACHCfg.PwrRampingSte
pCE1
Retained the function of None l 3900 and 5900 series

MLBFD-12100242 Active base stations
Queue Management (AQM) l DBS3900 LampSite and
while not presenting it as a DBS5900 LampSite
feature.
l BTS3912E
l BTS3911E
Editorial Changes
This document is split from NB-IoT Radio and Performance Basics (FDD) and optimized in
terms of the organization and description.

eRAN
NB-IoT Radio and Performance Basics (FDD) is split into NB-IoT Basics (FDD) and NB-IoT
Enhancements (FDD). The former is used for basic service deployment, and the latter is used
for performance optimization.
The descriptions of some features in NB-IoT Radio and Performance Principles (FDD) are
moved to other documents. Specifically:
l The descriptions of MLBFD-12000238 UL 2-Antenna Receive Diversity,
MLBFD-12100240 DL 4-Antenna Transmit Diversity, and MLOFD-121202 UL 4-
Antenna Receive Diversity are moved to MIMO.
l The descriptions of MLOFD-131205 Intra-eNodeB UL CoMP are moved to UL CoMP.

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 2 About This Document
2 About This Document
2.1 General Statements

Purpose
This document is intended to acquaint readers with:
l The technical principles of features and their related parameters
l The scenarios where these features are used, the benefits they provide, and the impact
they have on networks and functions
l Requirements of the operating environment that must be met before feature activation
l Parameter configuration required for feature activation, verification of feature activation,
and monitoring of feature performance
NOTE
This document only provides guidance for feature activation. Feature deployment and feature
gains depend on the specifics of the network scenario where the feature is deployed. To achieve
the desired gains, contact Huawei professional service engineers.
Software Interfaces
Any parameters, alarms, counters, or managed objects (MOs) described in this document
apply only to the corresponding software release. For future software releases, refer to the
corresponding updated product documentation.
Trial Features
Trial features are features that are not yet ready for full commercial release for certain
reasons. For example, the industry chain (terminals/CN) may not be sufficiently compatible.
However, these features can still be used for testing purposes or commercial network trials.
Anyone who desires to use the trial features shall contact Huawei and enter into a
memorandum of understanding (MoU) with Huawei prior to an official application of such
trial features. Trial features are not for sale in the current version but customers may try them
for free.
Customers acknowledge and undertake that trial features may have a certain degree of risk
due to absence of commercial testing. Before using them, customers shall fully understand not

eRAN
only the expected benefits of such trial features but also the possible impact they may exert on
the network. In addition, customers acknowledge and undertake that since trial features are
free, Huawei is not liable for any trial feature malfunctions or any losses incurred by using the
trial features. Huawei does not promise that problems with trial features will be resolved in
the current version. Huawei reserves the rights to convert trial features into commercial
features in later R/C versions. If trial features are converted into commercial features in a later
version, customers shall pay a licensing fee to obtain the relevant licenses prior to using the
said commercial features. If a customer fails to purchase such a license, the trial feature(s)
will be invalidated automatically when the product is upgraded.
Feature Differences Between RATs

The feature difference section only describes differences in switches or principles.
Unless otherwise stated, descriptions in this document apply to all RATs. If a description does
not apply to all RATs, the specific RAT that it does apply to will be stated.
For example, in the statement "TDD cells are compatible with enhanced MU-MIMO", "TDD
cells" indicates that this function cannot be used in non-TDD cells.
2.2 Applicable RAT

This document applies to NB-IoT.
2.3 Features in This Document

This document describes the following NB-IoT features.
Feature ID Feature Name Section
MLBFD-120001 NB-IoT Network 3.1 NB-IoT Spectrum

Deployment Deployment Modes
MLBFD-12000101 Standalone Deployment 3.1 NB-IoT Spectrum

Deployment Modes
MLBFD-12000102 LTE Guardband 3.1 NB-IoT Spectrum

Deployment Deployment Modes
MLBFD-12000103 LTE In-band Deployment 3.1 NB-IoT Spectrum

Deployment Modes
MLBFD-120002 3GPP NB-IoT 4 Principles

Specifications Compliant
MLBFD-12000202 Single-tone 3.2.4 Single-Tone Transmission
MLBFD-12000203 Support of NB-IoT UE 3.4 NB-IoT UE Requirements
MLBFD-12000204 Data over NAS 3.3.1 Data over NAS
MLBFD-12100205 Data over User Plane 3.3.2 Data over User Plane

eRAN
MLBFD-12000223 Physical Channel 3.2.1 Physical Layer

Management Management
3.2.2 Frequency-Domain
Structures of Physical Channels
3.2.3 Time-Domain Structures of
Physical Channels
MLBFD-12000224 DL Asynchronous HARQ 4.5.4.4 Downlink Scheduling for

Retransmissions
MLBFD-12000225 UL Asynchronous HARQ 4.5.3.4 Uplink Scheduling for

Retransmissions
MLBFD-12000226 Modulation: DL QPSK, 3.2.1 Physical Layer

UL QPSK/BPSK Management
MLBFD-12000227 AMC 4.5.3.3 Uplink Scheduling for

Initial Transmissions
4.5.4.3 Downlink Scheduling for

Initial Transmissions
MLBFD-12000228 RRC Connection 4.4 Connection Management

Management
MLBFD-12000229 Broadcast of system 4.2 Idle Mode Management

information 4.2.2 System Information
Broadcast
MLBFD-12000230 Random Access 4.3 Random Access
MLBFD-12000231 Paging 4.2 Idle Mode Management

4.2.3 Paging
MLBFD-12000232 Cell Access Radius up to 4.9 Cell Access Radius up to 35

35 km km
MLBFD-12000233 Admission Control 4.7.1 Admission Control
MLBFD-12000234 Basic Scheduling 4.5 Scheduling
MLBFD-12000235 Uplink Power Control 4.6.2 Uplink Power Control
MLBFD-12000236 DRX 4.8 DRX
MLBFD-12000237 Cell Selection and Re- 4.2 Idle Mode Management

selection 4.2.1 Cell Selection and
Reselection
MLBFD-12100243 Congestion Control 4.7.2 Congestion Control
MLBFD-13100245 NB-IoT Channel 3.2.1 Physical Layer

Estimation Enhancement Management

eRAN
MLBFD-15000246 RRC Connection 4.4.3 RRC Connection

Reestablishment for Reestablishment
Control Plane
2.4 Feature Differences Between NB-IoT and FDD

NB-IoT NB-IoT FDD FDD Difference Section
Feature Feature Feature Feature
ID Name ID Name
MLBFD- Physical LBFD-0 Physical NB-IoT and LTE 3.2.1

1200022 Channel 02003 Channel FDD use different Physical
3 Management Management physical channels: Layer
l NB-IoT: Managem
Uplink: ent
NPRACH and
NPUSCH
Downlink:
NPBCH,
NPDCCH, and
NPDSCH
l LTE FDD:
Uplink: PRACH,
PUCCH, and
PUSCH
Downlink:
PBCH, PCFICH,
PHICH,
PDCCH,
PDSCH, and
PMCH

eRAN

ID Name ID Name
MLBFD- DL LBFD-0 DL NB-IoT: 4.5.4.4

1200022 Asynchronou 02005 Asynchronou Only one downlink Downlink
4 s HARQ s HARQ asynchronous Schedulin
HARQ process is g for
supported. To Retransmi
support two HARQ ssions
processes,
MLOFD-131252
Dual HARQ needs
to be enabled.
LTE FDD:
A maximum of
eight HARQ
processes are
supported.
MLBFD- UL LBFD-0 UL NB-IoT: 4.5.3.4

1200022 Asynchronou 02006 Synchronous Only one uplink Uplink
5 s HARQ HARQ asynchronous Schedulin
HARQ process is g for
supported. To Retransmi
support two HARQ ssions
processes,
MLOFD-131252
Dual HARQ needs
to be enabled.
LTE FDD:
A maximum of
eight uplink
synchronous HARQ
processes are
supported.

eRAN

ID Name ID Name
MLBFD- Modulation: LBFD-0 Modulation: NB-IoT: 3.2.1

1200022 DL QPSK, 01005 DL/UL In the downlink, Physical
6 UL QPSK/ QPSK, only QPSK is Layer
BPSK DL/UL supported. Managem
16QAM, DL ent
64QAM In the uplink, both
QPSK and BPSK
are supported.
LTE FDD:
In the downlink,
QPSK, 16QAM,
and 64QAM are
supported.
In the uplink, QPSK
and 16QAM are
supported.
MLBFD- AMC LBFD-0 AMC NB-IoT: 4.5.3.3

1200022 01006 In both uplink and Uplink
7 downlink, the initial Schedulin
MCS is selected as g for
configured for the Initial
corresponding Transmiss
coverage level. ions
LTE FDD: 4.5.4.3
Downlink
In the uplink, the Schedulin
initial MCS is g for
selected based on Initial
the measured SINR. Transmiss
In the downlink, the ions
initial MCS is
selected based on
the UE-reported
CQI.

eRAN

ID Name ID Name
MLBFD- RRC LBFD-0 RRC NB-IoT: 4.4

1200022 Connection 02007 Connection The PDCP layer is Connectio
8 Management Management not involved in n
control plane CIoT Managem
EPS optimization. ent
NAS messages can
carry data.
The PDCP layer is
involved in user
plane CIoT EPS
optimization, which
is the same as in
LTE FDD.
LTE FDD:
The PDCP layer is
involved. NAS
messages do not
carry data.
MLBFD- Broadcast of LBFD-0 Broadcast of NB-IoT: 4.2 Idle

1200022 system 02009 system The information Mode
9 information information that can be Managem
broadcast includes ent
MIB-NB, SIB1-NB,
SIB2-NB, SIB3-
NB, SIB4-NB,
SIB5-NB, SIB14-
NB, and SIB16-NB.
LTE FDD:
The information
that can be
broadcast includes
MIB and SIB1 to
SIB20.
MLBFD- Random LBFD-0 Random NB-IoT: 4.3

1200023 Access 02010 Access Access can be Random
0 performed at three Access
coverage levels.
LTE FDD:
Access can be
performed at only
one coverage level.

eRAN

ID Name ID Name
MLBFD- Paging LBFD-0 Paging NB-IoT: 4.2 Idle

1200023 02011 Common paging is Mode
1 supported. In Managem
addition, extended ent
paging is supported.
UEs can be paged
based on coverage
levels and
recommended cell
lists.
LTE FDD:
Only common
paging is supported.
MLBFD- Cell Access N/A N/A This feature is 4.9 Cell

1200023 Radius up to supported only by Access
2 35 km NB-IoT. Radius up
to 35 km
MLBFD- Admission LBFD-0 Admission NB-IoT: 4.7.1

1200023 Control 02023 Control Admission control Admission
3 is performed mainly Control
based on RRC
connection setup
causes.
LTE FDD:
Admission control
is performed mainly
based on ARPs.
MLBFD- Congestion LBFD-0 Congestion NB-IoT: 4.7.2

1210024 Control 02024 Control Congestion control Congestio
3 can be based on n Control
SIB14-NB.
LTE FDD:
Congestion control
can be based on
SIB2.

eRAN

ID Name ID Name
MLBFD- Basic LBFD-0 Basic NB-IoT: 4.5

1200023 Scheduling 02025 Scheduling Initial scheduling is Schedulin
4 based on coverage g
levels. In the
downlink,
measurement
reporting is not
supported and
ACK/NACK
reports are used in
MCS and repetition
count adjustment.
LTE FDD:
Only one coverage
level is supported.
In the downlink,
measurement
reporting is
supported and
measurement
reports can be used
in MCS adjustment.
MLBFD- Uplink Power LBFD-0 Uplink Power NB-IoT: 4.6.2

1200023 Control 02026 Control Power control is Uplink
5 performed for Power
NPUSCH and Control
NPRACH. Only
open-loop power
control is supported.
LTE FDD:
Power control is
performed for
PUSCH, PUCCH,
PRACH, and SRS.
Both open-loop
power control and
closed-loop power
control are
supported.

eRAN

ID Name ID Name
MLBFD- DRX LBFD-0 DRX NB-IoT: 4.8 DRX

1200023 02017 Only long-cycle
6 DRX is supported.
LTE FDD:
Both long-cycle
DRX and short-
cycle DRX are
supported.
MLBFD- Cell Selection LBFD-0 Cell Selection NB-IoT: 4.2 Idle

1200023 and Re- 0201803 and Re- Cell reselection is Mode
7 selection selection not based on Managem
priorities, for the ent
purpose of UE
power saving.
LTE FDD:
Cell reselection can
be based on
priorities.
MLBFD- NB-IoT N/A N/A This feature is 3.2.1

1310024 Channel supported only by Physical
5 Estimation NB-IoT. Layer
Enhancement Managem
ent
MLBFD- RRC N/A N/A This feature is 4.4.3 RRC

1500024 Connection supported only by Connectio
6 Reestablishm NB-IoT. n
ent for Reestablis
Control Plane hment

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 3 Overview
3 Overview
The Internet of Things (IoT) is an important part of the information technology of the future.
IoT aims to enable people-thing and thing-thing interconnections using communications
technologies and networks. IoT applications can be divided into three layers based on data
transmission requirements, as shown in Figure 3-1.
Figure 3-1 IoT applications
Low-rate services account for the largest proportion of IoT services. However, conventional
wireless networks are not specially designed or optimized for these services. Due to high
power consumption and high costs, these networks are not applicable to low-rate services.
3GPP introduced Narrowband Internet of Things (NB-IoT) to meet the requirements of these
services for massive connections, low rates, low power consumption, and low costs.

eRAN
NB-IoT is a narrowband IoT technology based on the LTE network. The operating bandwidth
is 200 kHz (the actual effective bandwidth is 180 kHz). It can be deployed in three modes, as
shown in 3.1 NB-IoT Spectrum Deployment Modes. It can be deployed on a GSM, UMTS,
or LTE network. The deployment cost is low and the network can be smoothly upgraded.
Figure 3-2 shows the NB-IoT network architecture.
Figure 3-2 NB-IoT network architecture
This figure is described as follows:

l NB-IoT and LTE FDD cells are independent of each other. Unlike LTE FDD cells, NB-
IoT cells comply with NB-IoT specifications, which are briefly described as follows:
– The physical layer is redefined for low-rate services. The upper layers (including
MAC, RLC, PDCP, and RRC layers) are adjusted based on FDD protocols and NB-
IoT service characteristics. For details about the physical layer, see 3.2 Physical
Layer.
– Data transmission is optimized based on FDD protocols and NB-IoT service
characteristics. For details, see 3.3 Data Transmission Optimization.
l NB-IoT UEs are customized low-cost NB-IoT terminals. With an operating bandwidth of
200 kHz, they are mainly oriented to services with data rates lower than 200 kbit/s.
NB-IoT terminals have more types than traditional wireless service terminals. There are
only a few types of traditional wireless service terminals such as mobile phones and
datacard terminals. By contrast, there are a large number of types of smart terminals
oriented to vertical industries of IoT. Terminals equipped with NB-IoT modules can act
as NB-IoT terminals for data reporting, communication, or control. Currently, mature
NB-IoT terminals include water meters, street lamps, gas meters, and vehicle detectors.
The requirements for NB-IoT terminals are defined in 3GPP TS 36.306 R13. For details,
see 3.4 NB-IoT UE Requirements.
This document describes the basic principles of NB-IoT mainly from the perspective of
eNodeBs.
3.1 NB-IoT Spectrum Deployment Modes

NB-IoT requires only 180 kHz bandwidth for a single carrier. 3GPP TS 36.104 R13 defines
the following three spectrum deployment modes for NB-IoT to fully utilize the spectrum
resources of live networks.
l Standalone deployment: Part of the spectrum of an existing RAT can be planned for NB-
IoT, under the precondition that the functionality of that RAT is not affected.

eRAN
l LTE guard band deployment: A guard band of LTE FDD can be used for NB-IoT.
l LTE in-band deployment: Physical resource blocks (PRBs) within an LTE FDD band can
be used for NB-IoT.
Figure 3-3 illustrates the deployment modes.
Figure 3-3 NB-IoT spectrum deployment modes
The actual deployment mode is specified by the Prb.DeployMode parameter on the eNodeB
and sent in system information to the UE.
In LTE in-band deployment mode, downlink PRB resources used to deploy NB-IoT must be
punctured for the LTE FDD PDCCH and cell-specific reference signal (CRS) according to
3GPP TS 36.211 R13, as shown in Figure 3-4. As fewer REs can be used in this mode than in
other modes, the cell throughput and UE throughput are also relatively lower.
Figure 3-4 Downlink PRB resource allocation in LTE in-band deployment mode
In LTE in-band deployment mode, you also need to perform the following operations:
l Set the Prb.LteCellId parameter to specify the LTE FDD cell where the PRBs are
located.
l Set the CellRbReserve MO to reserve uplink and downlink PRBs in the LTE FDD cell.

eRAN
3.2 Physical Layer

NB-IoT redefines the physical layer based on the characteristics of narrowband technologies.
This section briefly describes the physical layer. For details, see 3GPP TS 36.211 R13.
3.2.1 Physical Layer Management

Table 3-1 lists the physical channels and signals of NB-IoT. Downlink channels support only
quadrature phase shift keying (QPSK). Uplink channels support binary phase shift keying
(BPSK) and QPSK.
Table 3-1 Physical channels and signals

Categ Name Description
ory
Downli Narrowband physical The NPBCH carries the network- and cell-
nk broadcast channel (NPBCH) specific information that must be broadcast.
channel
Narrowband physical The NPDCCH carries downlink control
downlink control channel information (DCI).
(NPDCCH)
Narrowband physical The NPDSCH carries downlink data.

downlink shared channel
(NPDSCH)
Downli Narrowband reference signal The NRS is used for downlink channel
nk (NRS) estimation and data demodulation of NB-IoT
signal cells.
Narrowband synchronization The NSS is used for NB-IoT cell search. There
signal (NSS) are two types: narrowband primary
synchronization signal (NPSS) and
narrowband secondary synchronization signal
(NSSS).
Uplink Narrowband physical uplink The NPUSCH carries uplink data.

channel shared channel (NPUSCH)
Narrowband physical random The NPRACH is used by UEs to send access

access channel (NPRACH) information.
Uplink Narrowband demodulation The NDMRS is used for uplink channel

signal reference signal (NDMRS) estimation and data demodulation of NB-IoT
cells.
The eNodeB uses NDMRS for NPUSCH estimation. It can process signals collected in a
longer time domain, use more reference signals to reduce noise in the transform domain, and
take measures against frequency offset in the frequency domain. This improves the accuracy
of estimated frequency offsets, signals, and channels, and therefore expands NPUSCH
coverage.

eRAN
Figure 3-5 illustrates the mapping between the physical and transport channels of NB-IoT.
Figure 3-5 Mapping between the physical and transport channels
3.2.2 Frequency-Domain Structures of Physical Channels
Downlink Frequency-Domain Structure

The downlink bandwidth of a single carrier of NB-IoT is 180 kHz. A single carrier is divided
into 12 subcarriers with 15 kHz spacing, as shown in Figure 3-6.
Figure 3-6 Downlink frequency-domain structure
Uplink Frequency-Domain Structure

The uplink bandwidth of a single carrier of NB-IoT is 180 kHz. A single carrier can be
divided into subcarriers with 15 kHz or 3.75 kHz spacing, as shown in Figure 3-7.

eRAN
Figure 3-7 Uplink frequency-domain structure
The uplink structure is described as follows:

l If 15 kHz subcarriers are used, there will be a maximum of 12 subcarriers. Only the
NPUSCH supports 15 kHz subcarriers in the current version.
l If 3.75 kHz subcarriers are used, there will be a maximum of 48 subcarriers. Only the
NPRACH supports 3.75 kHz subcarriers in the current version.
Uplink physical channels support single-tone and multi-tone transmission, where tone means
subcarrier.
l Both 3.75 kHz and 15 kHz subcarriers support single-tone transmission. For details
about single-tone transmission, see 3.2.4 Single-Tone Transmission.
l Only 15 kHz subcarriers support multi-tone transmission. Multi-tone transmission can be
3-, 6-, or 12-tone transmission. For details about multi-tone transmission, see the
description of MLOFD-120230 Multi-tone in NB-IoT Enhancements (FDD).
3.2.3 Time-Domain Structures of Physical Channels

Downlink Time-Domain Structure
The basic scheduling unit of downlink channels for NB-IoT is subframe. Each subframe lasts
1 ms and corresponds to two timeslots. 10 subframes compose a system frame (also called
frame). 1024 system frames compose a hyper system frame. Figure 3-8 shows the downlink
time-domain structure.

eRAN
Figure 3-8 Downlink time-domain structure
Uplink Time-Domain Structure

The basic resource unit of NPUSCH is timeslot in the time domain.
l For 3.75 kHz subcarriers, one timeslot lasts 2 ms.
l For 15 kHz subcarriers, one timeslot lasts 0.5 ms.
The basic scheduling unit of NPUSCH is resource unit (RU). Table 3-2 provides how long an
RU lasts in various scenarios.
Table 3-2 RU durations

NPUSC Subcarri Subcarri Timeslot Duration Duration Scenario
H Format er er Count Count per per RU
Spacing per RU Timeslot (ms)
(ms)
Format 1, 3.75 kHz 1 16 2 32 Single-

for tone
common 15 kHz 1 16 0.5 8
data 15 kHz 3 8 0.5 4 Multi-tone
15 kHz 6 4 0.5 2
15 kHz 12 2 0.5 1
Format 2, 3.75 kHz 1 4 2 8 Single-

for uplink tone
control 15 kHz 1 4 0.5 2
informatio
n (UCI)

eRAN
NOTE
The current version does not support 3.75 kHz single-tone transmission for the NPUSCH.
The total preamble duration of NPRACH is equal to the duration of an NPRACH preamble
multiplied by the repetition count. Table 3-3 provides the duration of an NPRACH preamble
in different situations.
Table 3-3 Duration of an NPRACH preamble
Preamble Format Subcarrier Subcarrier Preamble Duration (ms)

Spacing Count
Format 0 3.75 kHz 1 5.6
Format 1 3.75 kHz 1 6.4
3.2.4 Single-Tone Transmission

Single-tone and multi-tone transmission can be used for NB-IoT in the uplink according to
3GPP TS 36.211 R13. Single-tone transmission is mandatory for UEs while multi-tone
transmission is optional.
Single-tone transmission uses only one subcarrier for uplink transmission. The subcarrier
bandwidth can be one of the following:
l 3.75 kHz, currently applicable to the NPRACH
l 15 kHz, currently applicable to the NPUSCH
For details about multi-tone transmission, see the description of MLOFD-120230 Multi-tone
in NB-IoT Enhancements (FDD).
3.3 Data Transmission Optimization

Data transmissions are optimized for NB-IoT based on characteristics such as low data
reception and transmission frequencies and small data packet sizes. Data transmission
optimizations are protocol-defined as "CIoT EPS optimizations" and divided into Data over
NAS and Data over User Plane. This section provides a brief description. For details, see
3GPP TS 24.301 R13.
3.3.1 Data over NAS

Data over NAS is also called "control plane CIoT EPS optimization" in this document, which
is a protocol-defined name. This function involves only the control plane. No data radio
bearers (DRBs) are required between eNodeBs and UEs. The RLC and RRC layers exchange
information directly, with no PDCP layer involved, as shown in Figure 3-9. Data security is
ensured at the NAS.

eRAN
Figure 3-9 Control plane protocol stack for control plane CIoT EPS optimization
Uplink and downlink data are carried in NAS messages in uplink and downlink RRC
messages, respectively.
Control plane CIoT EPS optimization is a mandatory function. For details, see 3GPP TS
24.301 R13. The requirements for NEs are as follows:
l MMEs of NB-IoT cells need to support control plane CIoT EPS optimization.
l NB-IoT UEs need to support control plane CIoT EPS optimization.
l eNodeBs support control plane CIoT EPS optimization. Control plane CIoT EPS
optimization must be enabled by setting the MmeCapInfo.NbCiotEpsOptCap parameter
on the eNodeBs.
3.3.2 Data over User Plane

Data over User Plane is also called "user plane CIoT EPS optimization" in this document,
which is a protocol-defined name.
Compared with control plane CIoT EPS optimization, user plane CIoT EPS optimization
involves the PDCP layer between the RLC and RRC layers, as shown in Figure 3-10. The
PDCP layer performs encryption and integrity protection for air interface data at the access
stratum.
Figure 3-10 Control plane protocol stack for user plane CIoT EPS optimization
Service data is carried on DRBs in the user plane. Before data transmission for a UE, one or
two DRBs need to be set up between the UE and the network side. When the UE is released,

eRAN
user plane CIoT EPS optimization allows the eNodeB and UE to suspend the RRC connection
and retain the UE context. When the UE accesses the network again, the eNodeB and UE can
acquire the UE context rapidly. As security mode activation and RRC connection
reconfiguration are not performed, information exchanges over the air interface are reduced.
If the UE moves between the coverage areas of different eNodeBs, the UE context is
transmitted over the X2 interface for RRC connection resume.
User plane CIoT EPS optimization is an optional function. For details, see 3GPP TS 36.300
R13. User plane CIoT EPS optimization has the following requirements for NEs:
l MMEs of NB-IoT cells need to support user plane CIoT EPS optimization.
l NB-IoT UEs need to support user plane CIoT EPS optimization. When NB-IoT UEs that
support user plane CIoT EPS optimization access the network, the eNodeB preferentially
selects MMEs that support user plane CIoT EPS optimization for the UEs. If no such
MMEs are available, the eNodeB selects MMEs that support control plane CIoT EPS
optimization for the UEs.
l eNodeBs support user plane CIoT EPS optimization. User plane CIoT EPS optimization
must be enabled by setting the MmeCapInfo.NbCiotEpsOptCap parameter on the
eNodeBs.
3.4 NB-IoT UE Requirements
3.4.1 NB-IoT UE Categories

NB-IoT UE categories, NB1 and NB2, are defined in 3GPP TS 36.306.
l NB1 is introduced in 3GPP R13. NB-IoT UEs have NB1 capabilities by default.
l NB2 is introduced in 3GPP R14. It supports TBS extension. That is, the maximum TBS
is extended to 2536 bits and the maximum MCS index is increased to 13 in both uplink
and downlink. This increases uplink and downlink single-UE peak rates and reduces UE
power consumption. For NB-IoT UEs, NB2 capabilities are optional.
NB2 capabilities can take effect only when the eNodeB identifies as follows that the
eNodeB itself and UEs both support TBS extension:
a. When the TBS_EXTENSION_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, the eNodeB supports
TBS extension and can schedule NB2 UEs in TBS extension mode.
b. UE information retrieved by the eNodeB from the MME or UEs indicates that the
UEs support TBS extension. For details about the UE information retrieval
procedure, see 4.4.8 UE Information Retrieval Procedure.
Table 3-4 describe the capabilities of NB-IoT UEs of different categories.
Table 3-4 UE capabilities
UE Capability NB1 NB2
Maximum number of bits in 680 2536

DL-SCH TBs received
within a TTI

eRAN
UE Capability NB1 NB2

a DL-SCH TB received
within a TTI
Number of soft channel bits 2112 6400

UL-SCH TBs transmitted
within a TTI

a UL-SCH TB transmitted
within a TTI
Layer-2 buffer size (bytes) 4000 8000
Half-duplex FDD operation Type B Type B

type
3.4.2 Compatibility
3GPP TS 36.213 V13.3.0 (2016-09) made an incompatibility change for NB-IoT. The
eNodeB implements the change using the DCI_SF_REP_NUM_COMP_SWITCH option
of the CellAlgoSwitch.NbCellAlgoSwitch parameter.
l If there are NB-IoT UEs that comply with 3GPP TS 36.213 V13.3.0 (2016-09) in a cell,
this option needs to be selected. If this option is deselected, these NB-IoT UEs cannot
access the cell.
l After this option is selected, all the NB-IoT UEs that do not comply with 3GPP TS
36.213 V13.3.0 (2016-09) must be upgraded. If they are not upgraded, they cannot
access the cell.

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 4 Principles
4 Principles
This chapter describes the radio resource management functions provided by the eNodeB for
NB-IoT to ensure the normal running of NB-IoT services.
4.1 Cell Management

The concepts of NB-IoT cell and PRB are introduced for NB-IoT. The concepts of others
(including cell, sector, sector equipment, RF module, and baseband equipment) are the same
as those used in LTE. For details, see Cell Management.
4.1.1 NB-IoT Cell

An NB-IoT cell is an independent logical cell. The Cell.NbCellFlag parameter of an NB-IoT
cell must be set to TRUE. The Cell.NbCellFlag parameter of an LTE cell must be set to
FALSE.
An NB-IoT cell is divided into different coverage levels. UEs can select appropriate levels
based on signal strength. At a low level, signals are strong and transmission rates are
preferentially ensured. At a high level, signals are weak and coverage takes precedence over
transmission rates. For details about coverage levels, see the description of MLOFD-120201
NB-IoT Coverage Extension in NB-IoT Enhancements (FDD).
4.1.2 PRB
A physical resource block (PRB) is a carrier of an NB-IoT cell. The information about a PRB
includes the NB-IoT cell ID, deployment mode, and frequency-related information. A PRB is
added using the ADD PRB command.
If a cell has only one PRB, the PRB must be set as an anchor carrier. If a cell has two PRBs,
one PRB must be set as an anchor carrier and the other a non-anchor carrier. The frequency of
an NB-IoT cell is determined by the frequency of the anchor carrier.
PRB Deployment Mode

The deployment mode of a PRB is specified by the Prb.DeployMode parameter on the
eNodeB and delivered in system information to UEs. For details about deployment modes,
see 3.1 NB-IoT Spectrum Deployment Modes.
In LTE in-band deployment mode, you also need to perform the following operations:

eRAN
l Set the Prb.LteCellId parameter to specify the LTE FDD cell where PRBs are located.
l Set the CellRbReserve MO to reserve uplink and downlink PRBs in the LTE FDD cell.
PRB Frequency Band

The frequency band to which a PRB belongs is specified by the Prb.FreqBand parameter
according to 3GPP TS 36.104 R13.
PRB Center Frequency

The center frequency of a PRB is determined by factors such as the EARFCN and frequency
offset, according to 3GPP TS 36.104 R13. The EARFCN and frequency offset can be set on
the eNodeB.
l Downlink
The downlink EARFCN and frequency offset are specified by Prb.DlEarfcn and
Prb.DlFreqOffset, respectively.
l Uplink
– When the Prb.UlEarfcnCfgInd parameter is set to CFG, the uplink EARFCN and
frequency offset are specified by Prb.UlEarfcn and Prb.UlFreqOffset,
respectively.
– When the Prb.UlEarfcnCfgInd parameter is set to NOT_CFG, the uplink
EARFCN and frequency offset are calculated by the system based on an uplink-
downlink symmetry principle, without manual configuration.
Intra-PRB Guard Bands

Guard bands within a PRB include a high frequency edge guard band, a low frequency edge
guard band, and a guard band between NPRACH and NPUSCH. The intra-PRB high and low
frequency edge guard bands are used to reduce uplink interference caused by NB-IoT to other
RATs. The guard band between NPRACH and NPUSCH is used to reduce inter-channel
interference within NB-IoT.
l The intra-PRB high frequency edge guard bandwidth is specified by the

UlGuardBandCfg.HighFreqGuardBand parameter.
l The intra-PRB low frequency edge guard bandwidth is specified by the
UlGuardBandCfg.LowFreqGuardBand parameter.
l The intra-PRB guard bandwidth between NPRACH and NPUSCH is specified by the
UlGuardBandCfg.NprachNpuschGuardBand parameter.
When NB-IoT causes a small interference to other RATs, the intra-PRB high and low
frequency edge guard bandwidths are set to 0 by default. As there are situations where
NPRACH subcarriers and NPUSCH subcarriers are not orthogonal, the guard bandwidth
between NPRACH and NPUSCH is set to 4 by default.
PRB Sector Equipment

The sector equipment of a PRB is added using the ADD EUPRBSECTOREQM command.
The baseband equipment may be specified or not; if not specified, it uses the baseband
processing unit (BBP) directly connected to the RF module by default.

eRAN
4.2 Idle Mode Management

The main activities of a UE in idle mode are PLMN selection, cell selection, cell reselection,
and tracking area (TA) registration. Figure 4-1 illustrates the relationships between them.
Figure 4-1 Relationships among PLMN selection, cell selection and reselection, and TA
registration
Idle mode management also involves cell reservation, access control, system information
broadcast, and paging. For details, see Table 4-1.
Table 4-1 Idle mode management
Item Description Reference
Related LTE UEs support access class 0 (AC0) to Idle Mode Management
concepts AC15. NB-IoT UEs do not support AC10
(emergency call).
LTE UEs support normal service, operator
service, and limited service. NB-IoT UEs do
not support limited service.
LTE UEs support redirection. NB-IoT UEs
do not support redirection.
PLMN The processing for NB-IoT is the same as Idle Mode Management
selection that for LTE.

eRAN
Item Description Reference
TA registration The processing for NB-IoT is the same as

that for LTE.
Cell reservation The processing for NB-IoT is the same as

and access that for LTE.
control
Cell selection LTE UEs: For NB-IoT-specific

and reselection l Support intra-frequency, inter-frequency, descriptions, see 4.2.1
inter-RAT, priority-based, or speed- Cell Selection and
based cell reselection. Reselection. For other
basic information, see
l Support neighboring cell RSRP and Idle Mode Management.
RSRQ measurement.
NB-IoT UEs:
l Do not include the Qrxlevminoffset and
Qqualminoffset variables in the S-
criteria, compared with the S-criteria
used in LTE.
l Support only intra-frequency or equal-
priority inter-frequency cell reselection.
l Do not differentiate neighboring cell
priorities.
l Support only RSRP (but not RSRQ)
measurement for neighboring cell
measurement.
System LTE UEs: For NB-IoT-specific

information Support the MIB and SIB1 to SIB16. descriptions, see 4.2.2
broadcast System Information
NB-IoT UEs: Broadcast. For other
l Support the MIB-NB (indicating basic information, see
deployment modes), SIB1-NB to SIB5- Idle Mode Management.
NB, SIB14-NB, and SIB16-NB. (Their
scheduling periods are different, and
SIB4-NB and SIB5-NB do not include
cell blacklists.)
l Do not support SIB6 to SIB13 and
SIB15.
Paging LTE UEs: For NB-IoT-specific

l Support specified paging cycles. descriptions, see 4.2.3
Paging. For other basic
l Do not support extended paging. information, see Idle
NB-IoT UEs: Mode Management.
l Do not support specified paging cycles.
l Support extended paging.

eRAN
4.2.1 Cell Selection and Reselection

Cell Selection
A UE selects a cell to camp on only when the cell meets the S-criteria (Srxlev > 0 and Squal >
0).
l Srxlev = Qrxlevmeas – Qrxlevmin – Pcompensation – Qoffsettemp
l Squal = Qqualmeas – Qqualmin – Qoffsettemp
where
l Qrxlevmeas is the receive (RX) level measured based on signals received from the cell.
It is represented by reference signal received power (RSRP).
l Qrxlevmin is the minimum RX level required for the cell. It is broadcast in SIB1-NB and
specified by the CellSel.QRxLevMin parameter.
l Pcompensation = max{PMax – UE Maximum Output Power, 0}
– PMax is the maximum transmit power that the UE can use for uplink transmission
in the cell. It is broadcast in SIB1-NB and set by the Cell.UePowerMax parameter.
– UE Maximum Output Power is the maximum RF output power of the UE. It is the
UE capability, not a configured parameter value.
l Qqualmeas is the RX quality measured based on signals received from the cell. It is
represented by reference signal received quality (RSRQ).
l Qqualmin is the minimum RSRQ required for the cell. It is broadcast in SIB1-NB and
specified by the CellSel.QQualMin parameter.
l Qoffsettemp is an offset used only when an RRC connection fails to be set up. It is
broadcast in SIB2-NB.
NOTE
In the current version, Qoffsettemp cannot be delivered over the air interface.
Cell Reselection
1. The UE determines whether to measure neighboring cells based on the serving cell
RSRP.
– Intra-frequency measurement
The intra-frequency measurement threshold is specified by the
CellResel.SIntraSearch parameter and indicated by the s-IntraSearchP-r13 or s-
IntraSearchP-v1360 IE in SIB3-NB. The UE compares the current Srxlev with the
intra-frequency measurement threshold:
n If Srxlev is greater than the threshold, the UE does not measure intra-frequency
neighboring cells.
n If Srxlev is not greater than the threshold, the UE measures intra-frequency
neighboring cells.
– Inter-frequency measurement
The inter-frequency measurement threshold is specified by the
CellResel.SNonIntraSearch parameter and broadcast in SIB3-NB. The UE
compares the current Srxlev with the inter-frequency measurement threshold:
n If Srxlev is greater than the threshold, the UE does not measure inter-frequency
neighboring cells.

eRAN
n If Srxlev is not greater than the threshold, the UE measures inter-frequency

neighboring cells.
Neighboring cells to be broadcast are selected in sequence. The broadcast specifications
of SIB4-NB/SIB5-NB are as follows:
– 16 intra-frequency neighboring cells
– 8 inter-frequency carrier frequencies, and 16 inter-frequency neighboring cells on
each frequency
2. After the measurement, the UE can reselect a neighboring cell only when its RSRP
meets the S-criteria and its signal quality ranking (R_n) is higher than that of the serving
cell (R_s). If multiple neighboring cells meet the requirements, the one with the highest
R_n is selected.
a. Determining whether the neighboring cell meets the S-criteria:
n For an intra-frequency neighboring cell, the Srxlev value is calculated using
the following parameters broadcast in SIB3-NB:
○ Qrxlevmin is the minimum RX level required for the cell. It is broadcast
in SIB3-NB and specified by the CellResel.QRxLevMin parameter.
○ Qqualmin is the minimum RSRQ required for the cell. It is broadcast in
SIB3-NB and specified by the CellResel.QQualMin parameter.
○ PMax is the maximum uplink transmit power allowed for a UE in the
neighboring cell. It is broadcast in SIB3-NB and specified by the
CellResel.PMax parameter.
n For an inter-frequency neighboring cell, the Srxlev value is calculated using
the following parameters broadcast in SIB5-NB:
○ Qrxlevmin is the minimum RX level required for the cell. It is broadcast
in SIB5-NB and specified by the EutranInterNFreq.QRxLevMin
parameter.
○ Qqualmin is the minimum RSRQ required for the cell. It is broadcast in
SIB5-NB and specified by the EutranInterNFreq.QQualMin parameter.
○ PMax is the maximum uplink transmit power allowed for a UE in the
neighboring cell. It is broadcast in SIB5-NB and specified by the
EutranInterNFreq.PMax parameter.
b. Determining whether R_n is higher than R_s:
n R_s = Qmeas,s + Qhyst – Qoffsettemp
n R_n = Qmeas,n – Qoffset – Qoffsettemp
where
n Qmeas,s is the serving cell RSRP measured by the UE.
n Qhyst is the reselection hysteresis for the serving cell. It is broadcast in SIB3-
NB and specified by the CellResel.Qhyst parameter.
n Qmeas,n is the neighboring cell RSRP measured by the UE.
n Qoffset:
○ For an intra-frequency neighboring cell, Qoffset is equal to q-OffsetCell,
which is broadcast in SIB4-NB and specified by the
EutranIntraFreqNCell.CellQoffset parameter. If q-OffsetCell is not
broadcast in SIB4-NB, the UE sets q-OffsetCell to 0.
○ For an inter-frequency neighboring cell, Qoffset is equal to q-OffsetFreq,
which is broadcast in SIB5-NB and specified by the

eRAN
EutranInterNFreq.QoffsetFreq parameter. If q-OffsetFreq is not

broadcast in SIB5-NB, the UE sets q-OffsetFreq to 0.
n Qoffsettemp is not supported in the current version and not delivered over the
air interface. The UE sets this field to 0.
c. Cell reselection is triggered when R_n is always greater than R_s throughout the
cell reselection period.
n The intra-frequency neighboring cell reselection period is broadcast in SIB3-
NB and specified by the CellResel.TReselForNb parameter.
n The inter-frequency neighboring cell reselection period is broadcast in SIB5-
NB and specified by the CellResel.TReselInterFreqForNb parameter.
4.2.2 System Information Broadcast

NB-IoT system information is scheduled as follows:
l The MIB-NB is scheduled every 640 ms and repeated 8 times in each scheduling period.
The MIB-NB occupies subframe 0 in eight consecutive radio frames.
l SIB1-NB is scheduled every 2560 ms and repeated 4, 8, or 16 times, depending on the
CellSiMap.NbSib1RepetitionNum parameter value indicated in the scheduling
information in the MIB-NB. SIB1-NB occupies 8 subframes in each transmission.
Specifically, it occupies subframe 4 of every other radio frame in 16 consecutive radio
frames.
l The scheduling periods of SIB2-NB to SIB5-NB, SIB14-NB, and SIB16-NB are
specified by the parameters listed in Table 4-2 and indicated in the scheduling
information in SIB1-NB.
Table 4-2 Parameters for setting system information scheduling periods

SIB Parameter
SIB2-NB CellSiMap.NbSib2Period
System information is updated periodically. The period is determined based on the

BcchCfg.ModifyPeriodCoeffForNb parameter value.
4.2.3 Paging
UEs in idle mode receive paging information in discontinuous reception (DRX) mode to save
power. Paging information is transmitted at fixed positions over the Uu interface. These
positions are indicated by paging frames (PFs) and paging occasions (POs). In PF and PO
calculation formulas, the following parameters need to be set for NB-IoT:
l T: length of a DRX cycle, specified by the PCCHCfg.DefaultPagingCycleForNb
parameter and broadcast using the defaultPagingCycle IE in SIB2-NB.

eRAN
l nB: specified by the PCCHCfg.NbForNbIoT parameter.
Paging can work with eDRX in addition to DRX. For details about eDRX, see eDRX in Idle
Mode.
In the S1 setup procedure, the eNodeB reports an S1 default paging DRX cycle (specified by
the GlobalProcSwitch.S1DefaultPagingDrxForNb parameter) to the MME so that the MME
can determine the paging response timeout period. It is recommended that this S1 default
paging DRX cycle be greater than or equal to any of the defaultPagingCycle values.
Most NB-IoT UEs are not very mobile. To save air interface resources and reduce UE power
consumption, NB-IoT UEs are preferentially paged in the last cells they camp on. If the
paging fails, they are paged in extended areas to ensure the paging success rate. The following
figure shows an extended paging procedure.
Figure 4-2 Extended paging procedure
1. The eNodeB sends the following information in the UE Context Release Complete
message to the MME when releasing a UE:
– Information about the camp-on cell and the coverage level
– Recommended cell list and eNodeB list
The recommended cell list includes the intra-frequency neighboring cells of the
current cell. The eNodeB list includes the eNodeBs of the cells in the recommended
cell list.
2. The MME stores the received information. When paging the UE, the MME can send the
recommended cell list and coverage level information to the eNodeB. When determining
the paging scope, it can refer to the recommended eNodeB list.
3. After receiving a paging message, the eNodeB checks the number of current paging
times and the number of planned paging times indicated in the paging message sent from
the MME. A maximum of three levels of extended paging can be tried in sequence to
increase the paging success rate.

eRAN
Figure 4-3 Extended paging sequence
The paging transmission repetition counts for the preceding three paging levels on the
NPDSCH are determined as follows:
– If ENodeBNbPara.NbExtendedPagingOptSwitch is turned off, the paging
transmission repetition counts are determined by the downlink initial transmission
repetition count corresponding to the current coverage level or the highest coverage
level.
– If ENodeBNbPara.NbExtendedPagingOptSwitch is turned on, the paging
transmission repetition counts are determined by the downlink initial transmission
repetition count corresponding to the current coverage level or determined by the
downlink initial transmission repetition counts corresponding to coverage levels 0,
1, and 2 in sequence. Turning on this switch reduces the paging transmission
repetition counts and saves cell resources, compared with turning off this switch.
If the number of planned paging times is not indicated in the paging message or the
indicated number is less than 3, at least one paging is performed in the tracking area list
(TAL) range.
4.3 Random Access

4.3.1 Overview
Random access is performed before a UE communicates with the network. During random
access, the UE sends an access request to the eNodeB and then the eNodeB responds to the
request and allocates a RACH. After random access, the UE achieves uplink synchronization
with the network and obtains dedicated resources for data transmission.

eRAN
An NB-IoT UE initiates a random access procedure when one of the following conditions is
met:
l In idle mode, the UE performs an initial access or responds to a paging.
l In connected mode, the UE is out of synchronization in the uplink when downlink data
arrives.
l In connected mode, the UE has uplink data to send but has no uplink grant. The specific
random access procedure depends on the PrbUlSchCeAlgo.NbLogicChSrProhibitTimer
parameter:
– If this timer parameter is set to NOT_CFG, the UE immediately initiates a random
access procedure, which decreases the eNodeB's preallocation success rate.
– If this timer parameter is set to another value (for example, a recommended value
PP2), the UE starts the timer and initiates a random access procedure after the timer
expires. Such parameter setting increases the eNodeB's preallocation success rate.
However, a too large parameter value will prolong the UE's access delay.
4.3.2 Random Access Procedure

In the current version, NB-IoT supports only contention-based random access, which is
illustrated in Figure 4-4.
Figure 4-4 Contention-based random access procedure
1. The UE reads NPRACH configuration information from SIB2-NB, selects a coverage

level based on the RSRP measurement results and the RSRP threshold indicated in SIB2-
NB, and sends a random access preamble to the eNodeB at the selected coverage level.
The RSRP threshold is specified by the RACHCfg.NbRsrpFirstThreshold and
RACHCfg.NbRsrpSecondThreshold parameters.
The UE sends the preamble with the transmit power PNPRACH. For details about how to
calculate PNPRACH, see 4.6.2 Uplink Power Control.
2. Upon receiving the preamble, the eNodeB assigns a temporary cell RNTI (C-RNTI) and
allocates uplink and downlink resources. Then, the eNodeB sends a random access
response (RAR) over a downlink shared channel (DL-SCH) to the UE. One DL-SCH can
carry RARs for multiple UEs. The specific information carried includes:

eRAN
– RA-preamble identifier
– Timing alignment information
– Initial uplink grant
– Temporary C-RNTI
After sending the preamble, the UE monitors the NPDCCH within the RAR window
until it receives the RAR. The RAR window size is specified by the
CellRachCECfg.RaResponseWindowSize parameter and broadcast in SIB2-NB.
– If the RAR includes the same RA-preamble identifier as that the UE sent, the UE
considers the response successful and performs scheduled uplink transmission.
– If the UE does not receive a response within the RAR window or the received
response fails a verification, the UE considers the response unsuccessful. The UE
continues to initiate random access attempts at the current coverage level. If the
response still fails when the number of attempts reaches the maximum allowed at
the current level, the UE continues the attempts at a higher coverage level. The UE
stops random access when the coverage level cannot be further increased or the
total number of attempts reaches the maximum allowed in a cell. Table 4-3 lists the
related parameters.
Table 4-3 Parameters for setting the numbers of random access attempts
Maximum Number of Random Parameter ID
Access Attempts
Maximum number of random access CellRachCECfg.MaxNumPreambleA

attempts at a coverage level ttempt
Maximum number of random access RACHCfg.preambleTransMax

attempts in a cell
3. The UE sends Msg3 using the resources indicated in the RAR. Specifically, the UE sends
uplink scheduling information over the uplink shared channel (UL-SCH). The transport
block size (TBS) is 88 bits, which is specified in the RAR. The UE sends different
information in different random access scenarios:
– Initial RRC connection setup
The UE sends an RRC Connection Request message over the CCCH. This message
carries the RRC connection setup cause and NAS UE_ID. The RRC connection
setup cause may be one of the following:
n mt-Access
n mo-Signalling
n mo-Data
n mo-Exception-Data
n delayTolerantAccess-v1330
In addition, the message carries a MAC control element (CE) consisting of a data
volume indicator (DVI) and power headroom report (PHR). This MAC CE is used
to apply for uplink data transmission resources.
– Other scenarios
The UE sends at least its C-RNTI.

eRAN
4. After sending Msg3, the UE starts the contention resolution timer. The contention
resolution timer value is specified by the CellRachCECfg.ContentionResolutionTimer
parameter and broadcast in SIB2-NB.
The eNodeB performs contention resolution at the MAC layer. It uses the C-RNTI to
scramble the NPDCCH or sends the UE Contention Resolution Identity over the DL-
SCH to indicate a successful contention resolution.
If the UE obtains the indication before the contention resolution timer expires, the
contention-based random access procedure is completed.
If the contention resolution timer expires, the UE considers that the contention resolution
fails. If the number of random access attempts has not reached the maximum value, the
UE can make another random access attempt; otherwise, the random access procedure
fails.
4.3.3 NPRACH Resource Configuration

NPRACH resource configuration involves the configuration of the NPRACH subcarrier
offset, subcarrier quantity, duration, start time, and transmission period for each coverage
level.
NPRACH resources can be configured for a maximum of three coverage levels. In this
version, NPRACH resources are allocated in time division mode. The number of NPRACH
subcarriers is specified by the PrbRachCeConfig.PrachSubcarrierNumber parameter. The
NPRACH subcarrier offset is specified by the PrbRachCeConfig.PrachSubcarrierOffset
parameter.
NOTE
If the available frequency domain resources of a cell cannot support a 15 kHz NPUSCH, UEs at
coverage level 2 may fail to access the cell. The available resources refer to resources rather than the
NPRACH subcarriers, low frequency edge guard band, high frequency edge guard band, and guard band
between NPRACH and NPUSCH.
The NPRACH duration for each coverage level is calculated based on the
RACHCfg.NbCyclicPrefixLength parameter:
l If this parameter is set to 66DOT7, the NPRACH duration is equal to 5.6 ms multiplied
by the value of PrbRachCeConfig.PrachRepetitionCount.
l If this parameter is set to 266DOT7, the NPRACH duration is equal to 6.4 ms multiplied
by the value of PrbRachCeConfig.PrachRepetitionCount.
The following describes how to configure the NPRACH start time and transmission period in
different scenarios.
Scenario 1
When the RACHCfg.PrachStartTimeCfgInd parameter is set to NOT_CFG:
l The eNodeB automatically sets the NPRACH start time for each coverage level
according to the following rules:
– The NPRACH start time offset for coverage level 0 (CL0) is 8 ms.
– The NPRACH start time for a coverage level is not less than the sum of the
NPRACH start time for the previous level and the NPRACH duration for the
previous level.
– The difference in NPRACH start time between coverage levels is not less than 40
ms. This is to avoid access problems due to the same RA-RNTI calculated for

eRAN
different coverage levels. According to 3GPP TS 36.321 R13, RA-RNTI = 1 +

SFN/4.
– The start time must be in the value range {8 ms, 16 ms, 32 ms, 64 ms, 128 ms, 256
ms, 512 ms, 1024 ms}. If multiple values meet the preceding conditions, the
smallest value is used.
l The NPRACH transmission period is specified by the
PrbRachCeConfig.PrachTransmissionPeriod parameter. This parameter must be set to
the same value for all coverage levels. The NPRACH transmission period cannot be less
than the sum of the NPRACH duration and start time configured for the highest coverage
level, as shown in Figure 4-5.
If the NPRACH transmission period does not meet the preceding requirements, the NB-
IoT cell cannot be activated.
Figure 4-5 Relationships among the NPRACH transmission period, duration, and start
time
For example, the PrbRachCeConfig.PrachRepetitionCount parameter is set to REP_2,

REP_8, and REP_32 for CL0, CL1, and CL2, respectively. If the
RACHCfg.NbCyclicPrefixLength parameter is set to 66DOT7, the NPRACH duration is 5.6
x 2 ms, 5.6 x 8 ms, and 5.6 x 32 ms for CL0, CL1, and CL2, respectively. The start time offset
for CL0 is 8 ms, which can be calculated based on the preceding conditions. Accordingly:
l The start time for CL1 is not less than the start time offset for CL0 (8 ms) plus max{40
ms, 5.6 x 2 ms}. That is, the start time is not less than 48 ms. As 64 ms is the smallest
value that meets the requirement in the value range, it is selected as the start time for
CL1.
l The start time for CL2 is not less than the start time for CL1 (64 ms) plus max{40 ms,
5.6 x 8 ms}. That is, the start time is not less than 108.8 ms. As 128 ms is the smallest
value that meets the requirement in the value range, it is selected as the start time for
CL2.
l The NPRACH transmission period is not less than the sum of the NPRACH duration and
start time configured for the highest coverage level. The NPRACH duration is 5.6 x 32

eRAN
ms, and the NPRACH start time is 128 ms. Therefore, the NPRACH transmission period
is not less than 307.2 ms.
Scenario 2
When the RACHCfg.PrachStartTimeCfgInd parameter is set to CFG:
l The NPRACH start time for each coverage level is specified by the
PrbRachCeConfig.PrachStartTime parameter.
l The NPRACH transmission period is specified by the
PrbRachCeConfig.PrachTransmissionPeriod parameter. This parameter can be set to
different values for different coverage levels.
l The NPRACH start time and transmission period must meet all of the following
conditions:
If any condition is not met, cell activation fails.
– The difference in NPRACH start time between coverage levels is not less than 40
ms.
– The NPRACH transmission period for each coverage level is not less than the
NPRACH start time for the corresponding coverage level. In addition, it is not less
than the NPRACH duration for the corresponding coverage level.
– The NPRACH start time, transmission period, and duration must meet the
requirement that the NPRACH resources of all coverage levels do not overlap in a
hyper system frame. Specifically, the NPRACH resources allocated to a coverage
level cannot overlap those allocated to any other coverage level.
Figure 4-6 presents an example of how to determine whether the NPRACH resources for
CL0 in period i (CL0i) overlap those for CL1j.
Figure 4-6 Example of NPRACH resource overlap evaluation
The following describes how to calculate the center points of CL0i and CL1j, and the spacing
between these two center points:
Center point of CL0i = NPRACH transmission period for CL0 x i + NPRACH start time
offset for CL0 + Half of NPRACH duration for CL0

eRAN
Center point of CL1j = NPRACH transmission period for CL1 x j + NPRACH start time
offset for CL1 + Half of NPRACH duration for CL1
Spacing between these center points (L) = Center point of CL1j – Center point of CL0i. If the
calculated result of the spacing is a negative value, the absolute value is used for NPRACH
resource overlap evaluation.
l If the spacing is at least half of the sum of NPRACH durations for CL0 and CL1, the
NPRACH resources for CL0i do not overlap those for CL1j.
l If the spacing is less than half of the sum of NPRACH durations for CL0 and CL1, the
NPRACH resources for CL0i overlap those for CL1j.
4.3.4 NPRACH Detection Threshold

When setting the PrbRachCeConfig.PrachRepetitionCount parameter for each coverage
level, you also need to set the corresponding PrbRachCeConfig.PrachDetectionThld
parameter to specify the level of the NPRACH detection threshold for the corresponding
repetition count.
l Setting the PrbRachCeConfig.PrachDetectionThld parameter to a high level results in
a lower probability of NPRACH missing detection but a higher probability of false
detection.
l Setting the PrbRachCeConfig.PrachDetectionThld parameter to a low level results in a
lower probability of NPRACH false detection but a higher probability of missing
detection.
4.3.5 Optimization Against NPRACH False Detection

This function is an enhanced NPRACH algorithm. It separates effective signals and
interference signals through optimized frequency offset and time offset algorithms and
interference identification. This reduces the NPRACH false detection rate and increases the
NPRACH access success rate in interference scenarios.
The benefits of optimization against NPRACH false detection are as follows:
l The false detection rate decreases and the spectrum resources consumed by false
detection decrease.
l The NPRACH access success rate increases. The gain generally fluctuates between 5%
and 30%, depending on network interference and traffic volume.
l When the overall traffic volume of a cell is high (the total number of scheduled TBs is
large), the RBLER decreases because the number of residual TBs decreases.
The network impacts of optimization against NPRACH false detection are as follows:
l Under light load, the false detection rate increases slightly at coverage level 0.
l When the overall traffic volume of a cell is low (the total number of scheduled TBs is
small), there is a decrease in the number of TBs scheduled for UEs that falsely detect the
NPRACH, which further decreases the total number of scheduled TBs. As a result, the
proportion of residual TBs in normal scheduling may increase and the RBLER may
increase
This function is enabled by default. No data configuration is required. When the RBLER
increases noticeably, it is recommended that uplink IBLER optimization be used together with
optimization against NPRACH false detection.

eRAN
4.4 Connection Management
4.4.1 RRC Connection Setup

SRB1bis and SRB1 are established during RRC connection setup.
In control plane CIoT EPS optimization mode, SRB1bis is used. There is no PDCP layer for
SRB1bis. Security mode activation is not required, and data encryption and integrity
protection are not performed during RRC connection setup.
In user plane CIoT EPS optimization mode, SRB1bis is used before security mode activation,
and SRB1 is used after security mode activation. There is a PDCP layer for SRB1, unlike
SRB1bis.
Figure 4-7 shows the RRC connection setup procedure.
Figure 4-7 RRC connection setup procedure
1. The UE sends an RRC Connection Request-NB message with a setup cause to the
eNodeB.
RRC connection setup causes are related to NAS procedures and NAS session types. For
details, see 3GPP TS 24.301 R13.
The RRC Connection Request-NB message contains the UE_ID. If the upper layer
provides the S-TMSI, the UE sends the S-TMSI to the eNodeB. If no S-TMSI is
available, the UE sends a random value ranging from 0 to (240 – 1) to the eNodeB. In
NB-IoT, the IMSIs of UEs are unknown to eNodeBs.
2. The eNodeB sets up the context for the UE.
If the eNodeB receives multiple RRC Connection Request-NB messages from the UE
within a specified time window, the eNodeB handles only the most recent one. The time
window size is equal to the sum of the values of UeTimerConst.T300ForNb and
RrcConnStateTimer.FilterReptRrcConnReqTimer.
If the number of RRC Connection Request-NB messages (excluding the messages for
exception data) received from a UE within a specified time window is greater than the

eRAN
value of GlobalProcSwitch.NbRrcConnPunishmentThld, the eNodeB sends an RRC

Connection Reject-NB message to the UE. The time window size is equal to the sum of
the values of UeTimerConst.T300ForNb and
RrcConnStateTimer.FilterReptRrcConnReqTimer. After receiving the RRC
Connection Reject-NB message, the UE has to wait for the extended time indicated in
this message before it can send again the RRC Connection Request-NB message. The
extended wait time is specified by the RrcConnStateTimer.ExtendedWaitTime
parameter.
NOTE
The GlobalProcSwitch.NbRrcConnPunishmentThld parameter is introduced in eRAN13.1. The

GlobalProcSwitch.RrcConnPunishThd parameter will be disused in later versions. It is
recommended that the GlobalProcSwitch.RrcConnPunishThd parameter be set to 0.
In the current version, when the GlobalProcSwitch.RrcConnPunishThd parameter is set to a
non-zero value, it takes effect while the GlobalProcSwitch.NbRrcConnPunishmentThld
parameter does not. The GlobalProcSwitch.NbRrcConnPunishmentThld parameter takes effect
only when the GlobalProcSwitch.RrcConnPunishThd parameter is set to 0.
3. The eNodeB performs admission and SRB1bis/SRB1 resource allocation.
– If resource allocation is successful, the subsequent steps proceed. If resource
allocation fails, the eNodeB responds to the UE with an RRC Connection Reject
message.
– If the system is overloaded, the eNodeB responds to the UE with an RRC
Connection Reject message.
If the eNodeB sends an RRC Connection Reject-NB message to the UE, the UE can send
another RRC connection request only after a period specified by the
RrcConnStateTimer.ExtendedWaitTime parameter.
4. The eNodeB sends an RRC Connection Setup-NB message containing SRB1bis/SRB1
resource configurations to the UE.
5. The UE configures radio resources based on the SRB1bis/SRB1 resource information
indicated by the RRC Connection Setup-NB message, and then sends an RRC
Connection Setup Complete-NB message to the eNodeB. After the eNodeB receives the
RRC Connection Setup Complete-NB message, the RRC connection setup procedure is
complete.
The wait time for an RRC Connection Setup Complete-NB message depends on the
PrbDlSchCeAlgo.UuMessageWaitingTimer parameter:
– If this parameter is set to 0, the wait time is equal to the
ENodeBConnStateTimer.UuMessageWaitingTimer parameter value.
– If this parameter is not set to 0, the wait time is equal to the
PrbDlSchCeAlgo.UuMessageWaitingTimer parameter value of the carrier of the
UE.
4.4.2 RRC Connection Resume

In user plane CIoT EPS optimization mode, the RRC connection of a UE can be suspended
and the UE context can be stored upon connection release and the RRC connection can be
resumed using the stored UE context. Figure 4-8 shows the RRC connection resume
procedure.

eRAN
Figure 4-8 RRC connection resume procedure
1. The UE sends an RRC Connection Resume Request-NB message with an RRC

connection setup cause to the eNodeB.
RRC connection setup causes are related to NAS procedures and NAS session types. For
The RRC Connection Resume Request-NB message carries the ResumeIdentity
allocated by the eNodeB to the suspended UE when the RRC connection is released.
2. The eNodeB searches for the UE context based on the ResumeIdentity.
If the eNodeB receives multiple RRC Connection Resume Request-NB messages from
the UE within a specified time window, the eNodeB handles only the most recent one.
The time window size is equal to the sum of the values of UeTimerConst.T300ForNb
and RrcConnStateTimer.FilterReptRrcConnReqTimer.
If the number of RRC Connection Resume Request-NB messages (excluding the
messages for exception data) received from a UE within a specified time window is
greater than the value of GlobalProcSwitch.NbRrcConnPunishmentThld, the eNodeB
sends an RRC Connection Reject-NB message to the UE. The time window size is equal
to the sum of the values of UeTimerConst.T300ForNb and
RrcConnStateTimer.FilterReptRrcConnReqTimer. This message indicates an
extended wait time, which is specified by the RrcConnStateTimer.ExtendedWaitTime
parameter. After receiving the RRC Connection Reject-NB message, the UE has to wait
for this extended time before it can send again the RRC Connection Resume Request-NB
message.
NOTE
The GlobalProcSwitch.NbRrcConnPunishmentThld parameter is introduced in eRAN13.1. The

GlobalProcSwitch.RrcConnPunishThd parameter will be disused in later versions. It is
recommended that the GlobalProcSwitch.RrcConnPunishThd parameter be set to 0.
In the current version, if the GlobalProcSwitch.RrcConnPunishThd parameter is not set to 0, it
preferentially takes effect. Only if it is set to 0 does the
GlobalProcSwitch.NbRrcConnPunishmentThld parameter take effect.
For the inter-eNodeB resume procedure, the cells of the target eNodeB need to be configured as
external cells at the source eNodeB. Otherwise, the cells of the target eNodeB cannot obtain the
UE context from the source eNodeB.
The eNodeB searches for the UE context based on the ResumeIdentity.

eRAN
– If the eNodeB finds out the UE context, it proceeds with 3.

– If the eNodeB (new eNodeB) does not find out the UE context but acquires the ID
of the old eNodeB (which suspended the UE context) based on the ResumeIdentity,
then the new eNodeB sends a Retrieve UE Context Request message to the old
eNodeB over the X2 interface between the eNodeBs. If the old eNodeB has
buffered the UE context, it sends a Retrieve UE Context Response message to the
new eNodeB.
– If the eNodeB (new eNodeB) neither finds out the UE context nor acquires the ID
of the old eNodeB (which suspended the UE context) based on the ResumeIdentity,
then the new eNodeB triggers an RRC connection setup procedure. For details, see
4.4.1 RRC Connection Setup.
3. The eNodeB performs admission and SRB1bis/SRB1 resource allocation.
– If resource allocation is successful, the subsequent steps proceed. If resource
allocation fails, the eNodeB responds to the UE with an RRC Connection Reject
message.
– If the system is overloaded, the eNodeB responds to the UE with an RRC
Connection Reject message.
Upon receiving the RRC Connection Reject-NB message, the UE has to wait for a period
before it can send again the request. The wait time is specified by the
RrcConnStateTimer.ExtendedWaitTime parameter.
4. The eNodeB restores the DRB if it can find the UE context. The eNodeB instructs the
UE to configure radio resources and activate security mode by sending the RRC
Connection Resume-NB message on SRB1. This message carries dedicated radio
resource configurations and the NextHopChainingCount IE.
5. The UE configures radio resources according to the RRC Connection Resume-NB
message. After the configuration, the UE notifies the eNodeB of the PLMN information
by sending the RRC Connection Resume Complete-NB message. After the eNodeB
receives the RRC Connection Resume Complete-NB message, the RRC connection
resume procedure is complete. The wait timer for an RRC Connection Resume
Complete-NB message is specified by the
ENodeBConnStateTimer.WaitRrcConnSetupCmpTimer parameter.
4.4.3 RRC Connection Reestablishment

3GPP R13 supports RRC connection reestablishment only in user plane CIoT EPS
optimization mode.
3GPP R14 introduces RRC connection reestablishment in control plane CIoT EPS
optimization mode. If a source eNodeB fails to send downlink NAS data to a UE, it returns
the data to the MME. The MME then instructs a target eNodeB to send the data to the UE.
This decreases downlink packet loss but prolongs UE access delay and downlink data
transmission delay.
Control Plane CIoT EPS Optimization

In control plane CIoT EPS optimization mode, RRC connection reestablishment can take
effect only when it is supported by the MME, eNodeB, and UE.
If the CP_RRC_CONN_REESTABLISHMENT_SW option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, the eNodeB uses the optional field
cp-Reestablishment-r14 in SIB2-NB to indicate that it supports RRC connection
reestablishment in control plane CIoT EPS optimization mode.

eRAN
A UE in connected mode triggers RRC connection reestablishment in the following scenarios:

l The UE detects a radio link failure when any of the following conditions is met:
– The timer specified by the UeTimerConst.T310ForNb parameter expires.
– The maximum number of retransmissions at the RLC layer reaches the threshold
specified by the RlcPdcpParaGroup.NbUeMaxRetxThreshold parameter.
– In resynchronization scenarios, the number of random access attempts reaches the
maximum value or the contention resolution timer expires.
l An integrity check failure indication is received from the physical layer.
The RRC connection reestablishment procedure in control plane CIoT EPS optimization
mode is presented in blue text in Figure 4-9.

eRAN
Figure 4-9 RRC connection reestablishment procedure in control plane CIoT EPS
optimization mode
The RRC Connection Reestablishment Request-NB message does not contain operator
information. The MMEC indicated by the S-TMSI and the operator information of the cell
that admits the UE may correspond to multiple S1 links. If this is the case, the eNodeB
randomly selects an S1 link to send an eNodeB CP Relocation Indication message to the
MME. If the selected MME is not the serving MME of the UE, the RRC connection
reestablishment fails.
In addition, if the CellRachCECfg.ContentionResolutionTimer parameter setting is
improper, the RRC connection reestablishment fails.

eRAN
User Plane CIoT EPS Optimization

A UE that supports user plane CIoT EPS optimization can reconfigure SRB1 in an RRC
connection reestablishment procedure. The UE can perform transmission again on this radio
bearer and activate security mode again for the access stratum without algorithm adjustment.
It can restore the DRB after completing the RRC connection reconfiguration procedure.
An RRC connection reestablishment procedure is triggered to retain the RRC connection for a
UE in connected mode and security mode in one of the following situations:
l The UE detects a radio link failure when any of the following conditions is met:
– The timer specified by the UeTimerConst.T310ForNb parameter expires.
– The maximum number of retransmissions at the RLC layer reaches the threshold
specified by the RlcPdcpParaGroup.NbUeMaxRetxThreshold parameter.
– In resynchronization scenarios, the number of random access attempts reaches the
maximum value or the contention resolution timer expires.
l An integrity check failure indication is received from the physical layer.
l The RRC connection fails to be reconfigured.
Figure 4-10 shows the RRC connection reestablishment procedure.
Figure 4-10 RRC connection reestablishment procedure in user plane CIoT EPS optimization
mode
1. The UE sends an RRC Connection Reestablishment Request-NB message with a setup

cause to the eNodeB.
2. The eNodeB checks whether the context of the UE exists.
– If so, it performs 3.
– If not, it rejects the RRC connection reestablishment request of the UE.
3. The eNodeB performs admission and resource allocation.
– If the security parameter information of the UE is consistent with that of the
eNodeB, the UE passes the authentication. The eNodeB releases original resources
and performs admission and resource allocation again for the UE.

eRAN
– If the security parameter information of the UE is inconsistent with that of the

eNodeB, the UE does not pass the authentication. The eNodeB rejects the RRC
connection reestablishment request of the UE.
4. The eNodeB sends an RRC Connection Reestablishment-NB message to the UE,
indicating the newly allocated resources.
5. The UE reconfigures radio resources and activates encryption and integrity protection.
The UE sends an RRC Connection Reestablishment Complete-NB message to the
eNodeB, indicating that the reestablishment is completed.
4.4.4 MME Selection for NB-IoT

MMEs must support control plane or user plane CIoT EPS optimization for NB-IoT.
Otherwise, NB-IoT cells cannot be used. The specific optimization mode depends on MME
capabilities and parameter settings on the MME and eNodeB sides.
On the eNodeB side, the MmeCapInfo.NbCiotEpsOptCap parameter is used to specify
whether an MME supports control plane or user plane CIoT EPS optimization and the
MmeCapInfo.NbLteSupportCap parameter is used to specify whether an MME supports
LTE FDD/TDD.
When NB-IoT UEs that support user plane CIoT EPS optimization access the network, the
eNodeB preferentially selects MMEs that support user plane CIoT EPS optimization for the
UEs. If no such MMEs are available, the eNodeB selects MMEs that support control plane
CIoT EPS optimization for the UEs.
The eNodeB can select appropriate MMEs for UEs by using the NAS node selection function
(NNSF). For example, the eNodeB can select MMEs based on priority, capacity, load, cell
configuration, or dedicated core network (DCN) range. For details about the NNSF, see S1-
flex.
4.4.5 Data Transmission

Data Transmission in Control Plane CIoT EPS Optimization Mode
After an RRC connection is set up, the UE and EPC can perform data transmission between
them, as shown in Figure 4-11.

eRAN
Figure 4-11 Data transmission in control plane CIoT EPS optimization mode
1. The UE sends an RRC Connection Setup Complete-NB message to the eNodeB.

2. After receiving the RRC Connection Setup Complete-NB message, the eNodeB sends an
Initial UE Message to the MME, including the NAS PDU, TAI, and E-UTRAN cell
global identifier (ECGI).
3. The MME sends a Connection Establishment Indication message to the eNodeB,
including the MME UE S1AP ID and eNB UE S1AP ID, for data transmission between
the UE and EPC.
4. The MME and UE perform data transmission between them.
Data Transmission in User Plane CIoT EPS Optimization Mode

After an RRC connection is set up or resumed, the UE and EPC can perform data
transmission between them.
Figure 4-12 illustrates data transmission after an RRC connection is set up.

eRAN
Figure 4-12 Data transmission in user plane CIoT EPS optimization mode after an RRC
connection is set up
1. The UE sends an RRC Connection Setup Complete-NB message to the eNodeB.

2. After receiving the RRC Connection Setup Complete-NB message, the eNodeB sends an
Initial UE Message to the MME, including the NAS PDU, TAI, and ECGI.
3. The MME sends an Initial Context Setup Request message to the eNodeB, requesting the
eNodeB to set up a UE context. After receiving the message, the eNodeB triggers UE
context setup.
4. The eNodeB and UE exchange RRC security mode messages to activate security mode,
providing security and integrity protection for access stratum data transmitted over the
air interface.
5. The eNodeB and UE exchange RRC connection reconfiguration messages to set up a
DRB.
6. The eNodeB sends an Initial UE Context Setup Complete message to the MME,
indicating that the UE context has been set up.
7. The MME and S-GW exchange bearer modification messages to set up the E-UTRAN
radio access bearer (E-RAB) on the EPC side.
8. The S-GW and UE perform data transmission between them on the E-RAB.

eRAN
Figure 4-13 illustrates data transmission after an RRC connection is resumed.
Figure 4-13 Data transmission in user plane CIoT EPS optimization mode after an RRC
connection is resumed
1. The UE sends an RRC Connection Resume Complete-NB message to the eNodeB.

2. After receiving the RRC Connection Resume Complete-NB message, the eNodeB
resumes the UE context. If the resume succeeds, the eNodeB sends a UE Context
Resume Request message to the MME, requesting the MME to resume the UE context.
If some bearers fail to be resumed, the eNodeB includes an E-RAB Failed To Resume
List in this message.
3. After receiving the request, the MME resumes the UE context on itself. Then, the MME
and S-GW exchange bearer modification messages to resume the E-RAB bearer for the
UE on the EPC side.
4. If the UE context resume succeeds, the MME sends a UE Context Resume Response
message to the eNodeB. If some bearers fail to be resumed, the MME includes an E-
RAB Failed To Resume List in this message.
If the UE security context has changed, the UE Context Resume Response message will
carry a Security Context IE. The eNodeB buffers the UE security context for future
suspend or resume.

eRAN
5. The eNodeB and UE complete context and DRB resume using an RRC Connection
Reconfiguration message.
6. The S-GW and UE perform data transmission between them on the E-RAB.
Data Transmission Priority

UEs are prioritized for uplink and downlink data transmissions between UEs and the EPC.
UEs that monitor common search space 1 (CSS1) have the highest priority, UEs that monitor
common search space 2 (CSS2) the second, and UEs that monitor the UE-specific search
space (USS) the third. For details about search spaces, see 4.5 Scheduling.
UE RLC Status Reporting

When the eNodeB sends the last data packet in the TX buffer or TX window, it includes a
polling bit in the packet to trigger UE status reporting.
When the ENODEB_TX_BYTE_POLLING_SW option of the
CellAlgoExtSwitch.NbCellAlgoExtSwitch parameter is selected and the data volume sent by
the eNodeB reaches the UE L2 RX buffer size, the eNodeB uses a polling bit to trigger UE
status reporting.
NOTE
The UE L2 RX buffer size is determined by the UE category. The size is 4 KB for NB1 and 8 KB for
NB2. If the UE category is not obtained by the eNodeB, it is considered as NB1 by default.
When the RECEPTION_FAIL_STATUS_RPT_SW option of the

CellAlgoExtSwitch.NbCellAlgoExtSwitch parameter is selected, the UE sends a status report
if detecting a reception failure and the expiration of the corresponding t-Reordering timer.
NOTE
l t-Reordering timers are specified by the SrbRlcPdcpCfg.UeAmReorderingTimer and

RlcPdcpParaGroup.UeAmReorderingTimer parameters. The timers take effect only in dual
HARQ scheduling. In other scenarios, the timer values are always 0.
l If the eNodeB sends a downlink data packet to the UE but the UE is in the access procedure for
sending a status report, the UE may fail to receive the downlink data packet and need to send a new
status report.
4.4.6 Signaling Connection Release

Figure 4-14 shows a signaling connection release procedure.

eRAN
Figure 4-14 Signaling connection release procedure
A signaling connection release procedure can be triggered by the MME or eNodeB:

l Triggered by the MME
The MME sends a UE Context Release Command message to the eNodeB when the UE
and MME complete a service at the NAS layer or the MME decides to abort a service.
l Triggered by the eNodeB
The eNodeB sends a UE Context Release Request message to the MME after detecting
exceptions and then waits for the UE Context Release Command message from the
MME. For example:
– The UE inactivity timer expires.
When the RETRIEVE_UE_INFO_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, different inactivity timer
values can be set for different QoS class identifiers (QCIs) using the
QciPara.NbUeInactivityTimerForQci parameter. If a UE has multiple services
with different QCIs, the largest one of the inactivity timer values set for the QCIs
with the highest priority is taken as the UE inactivity timer value. In other
situations, the UE inactivity timer value is determined by the
RrcConnStateTimer.NbUeInactiveTimer parameter by default.
– The timer specified by the PrbDlSchCeAlgo.UuMessageWaitingTimer parameter
expires.
– The timer specified by the ENodeBConnStateTimer.S1MessageWaitingTimer
parameter expires.

eRAN
– The number of RLC ARQ retransmissions in AM mode reaches the maximum

number.
For a signaling radio bearer (SRB), the maximum numbers of retransmissions on
the eNodeB and UE sides are specified by the
SrbRlcPdcpCfg.NbEnodebMaxRetxThreshold and
SrbRlcPdcpCfg.NbUeMaxRetxThreshold parameters, respectively. For a DRB,
these numbers are specified by the
RlcPdcpParaGroup.NbEnodebMaxRetxThreshold and
RlcPdcpParaGroup.NbUeMaxRetxThreshold parameters, respectively.
– The UE supports release assistance indication defined by the rai-Support-r14 field
and the MAC buffer status report (BSR) from the UE indicates that the buffer is
empty. In this situation, the eNodeB immediately triggers an RRC connection
release, regardless of whether the UE inactivity timer expires. For details about UE
capabilities, see section 6.7.3 "NB-IoT information elements" in 3GPP TS 36.331
V14.4.0.
– The UE supports data inactivity monitoring defined by the dataInactMon field. In
this situation, the eNodeB triggers an inactive connection release when the data
inactivity timer expires, in case the UE does not receive an RRC connection release
message. The eNodeB can deliver the dataInactivityTimer IE in Msg4.
dataInactivityTimer = UE inactivity timer + RRC connection release timer + 10s. If
the calculated value is greater than the maximum protocol-defined value 180s, it is
not delivered. For details about UE capabilities, see section 6.7.3 "NB-IoT
information elements" in 3GPP TS 36.331 V14.4.0.
The eNodeB performs the following operations during a signaling connection release
procedure:
1. Releases transport resources and initiates an RRC connection release over the air
interface.
2. Sends an RRC Connection Release-NB message to the UE, instructing the UE to release
air interface resources.
The UE may not respond to the RRC Connection Release-NB message in some
situations (for example, when the UE is powered off or the air interface fails to work
correctly). To avoid the UE from occupying radio resources all the time, the eNodeB
releases the radio resources when the wait timer expires. The wait timer value is equal to
the RRC connection release timer value plus 10s.
3. Releases radio resources.
4. Sends a UE Context Release Complete message to the MME, indicating that the
resources have been released.
5. Releases UE resources, indicating that the UE transits from the connected mode to the
idle mode.
4.4.7 DRB Management

DRB management is required only in user plane CIoT EPS optimization mode and performed
by the eNodeB after security mode is set up.
DRB Setup
A DRB can be set up after encryption and integrity protection are complete and the UE
context is created. DRB setup is triggered when the MME sends an E-RAB Setup Request
message to the eNodeB.

eRAN
The RRC Connection Reconfiguration-NB message contains DRB-ToAddModList-NB-r13 in

the RadioResourceConfigDedicated-NB IE.
The UE performs the following operations based on the received message:
l Sets up a PDCP entity and configures related security parameters.
l Sets up and configures an RLC entity.
l Sets up and configures a logical channel.
Figure 4-15 illustrates the procedure.
Figure 4-15 DRB setup procedure
DRB Resume
A DRB is resumed when an RRC connection is resumed and the suspended UE context
contains DRB information.
DRB Modification
Figure 4-16 illustrates the DRB modification procedure. If DRB modification has an impact
on the UE, the UE reconfigures the PDCP entity, RLC entity, and logical channel based on the
RRC Connection Reconfiguration-NB message.

eRAN
Figure 4-16 DRB modification procedure
DRB Release
DRB release is triggered when the MME sends an E-RAB Release Command message to the
eNodeB, as shown in Figure 4-17. It can also be triggered when a signaling link is released.
When a DRB is released, the RRC Connection Reconfiguration-NB message contains DRB-
ToReleaseList-NB-r13 in the RadioResourceConfigDedicated-NB IE. Based on this message,
the UE releases all the resources related to the DRB.
Figure 4-17 DRB release procedure
4.4.8 UE Information Retrieval Procedure

In control plane CIoT EPS optimization mode, when the RETRIEVE_UE_INFO_SWITCH
option of the CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, the eNodeB can

eRAN
retrieve UE capability information from the UE or retrieve UE information from the MME.
UE information includes UE capability information and QoS parameters.
l The eNodeB retrieves UE capability information from the UE when the MME does not
include the information in the Connection Establishment Indication message or
DOWNLINK NAS TRANSPORT message that appears as the first downlink message.
l The eNodeB requests UE information from the MME as illustrated in Figure 4-18. For
– After receiving Msg3 (such as RRC Connection Request-NB or RRC
Reestablishment Request-NB) from the UE, the eNodeB sends a Retrieve UE
Information message to an MME based on the S-TMSI carried in Msg3.
– If the eNodeB receives a UE Information Transfer message from the MME, it
successfully obtains the UE information. If the eNodeB does not receive this
message from the MME before the corresponding message response timer expires,
it fails to obtain the UE information. For the timer setting suggestions, see the
description of CellRachCECfg.ContentionResolutionTimer in 7.1.1.2 Data
Preparation for Optimization.
Figure 4-18 UE information exchange procedure
NOTE
The Retrieve UE Information and UE Information Transfer information messages are newly added
S1 messages. The UE information can be obtained only when both the eNodeB and MME support
this procedure. If the MME does not support this procedure, S1 message responding will time out
and access performance will deteriorate.
The retrieval procedure includes the following special processing:
– If Msg3 does not include the S-TMSI, the eNodeB does not send a Retrieve UE
Information message to the MME.
– If a newly admitted UE has the same S-TMSI as an already admitted UE, the
eNodeB does not send a Retrieve UE Information message to the MME for the new
UE.

eRAN
– As Msg3 does not contain operator information, the MMEC indicated by the S-
TMSI and the operator information of the cell that admits the UE may correspond
to multiple S1 links. In this case, the eNodeB randomly selects an S1 link to send a
Retrieve UE Information message to the MME.
In user plane CIoT EPS optimization mode, UE information is stored in the UE context.
When a UE is released, its RRC connection can be suspended. After the UE re-accesses the
network, the eNodeB can directly obtain UE information in the RRC Connection Resume-NB
procedure.
4.5 Scheduling
4.5.1 Definition
Scheduling
Scheduling in NB-IoT is a process of dynamically allocating uplink and downlink time-
frequency resources among UEs for transmission and reception over shared channels.
Scheduler
Schedulers are located at the MAC layer. Uplink and downlink schedulers allocate appropriate
resources to UEs for transmission and reception.
Huawei schedulers are designed to achieve an optimal balance between single-UE

performance and overall network capacity.
RU
RU is the basic scheduling unit in the uplink. The duration of an RU depends on subcarrier
spacing and other factors, as listed in Table 3-2.
MCS
Modulation and coding schemes (MCSs) that can be used include BPSK and QPSK:
l BPSK encodes one bit per symbol. It is suitable for uplink channels.
l QPSK encodes two bits per symbol. It is suitable for both uplink and downlink channels.
eNodeBs and UEs select modulation schemes based on channel conditions, balancing user
data rates against frame error rates (FERs) during transmission. High-order modulation
schemes can be used under favorable channel conditions. If the modulation order (indicating
the number of bits per symbol) is higher, the transmission efficiency will be higher. For details
about modulation schemes, see 3GPP TS 36.211 R13.
Search Space
Search space for the NPDCCH is divided into CSS and USS. CSS is further divided into
CSS1 (for paging) and CSS2 (for RAR, Msg3 retransmission, and Msg4). For details, see
section 16.6 "Narrowband physical downlink control channel related procedures" in 3GPP TS
36.213 R13.

eRAN
4.5.2 Scheduler Principles

Schedulers are located at the MAC layer. They mainly allocate UL-SCH and DL-SCH
resources to UEs. In addition, they select appropriate MCSs and repetition counts for system
information or user data transmission.
Figure 4-19 illustrates the downlink scheduler principle.
Figure 4-19 Downlink scheduler principle
Figure 4-20 illustrates the uplink scheduler principle.

eRAN
Figure 4-20 Uplink scheduler principle
4.5.3 Uplink Scheduling
4.5.3.1 Uplink Scheduling Procedure

The uplink scheduler schedules UEs based on the UE priority in each TTI, as shown in
Figure 4-21.
Figure 4-21 Uplink scheduling procedure

eRAN
4.5.3.2 Uplink Scheduling Triggering

Uplink scheduling can be triggered in the following scenarios:
l The eNodeB receives a non-zero DVI carried in Msg3.
l The eNodeB receives a non-zero BSR indication carried in a MAC CE in a message
other than Msg3.
4.5.3.3 Uplink Scheduling for Initial Transmissions

Uplink scheduling for initial transmissions includes UE selection, MCS selection, repetition
count selection, and resource allocation.
MCS selection, repetition count selection, and resource allocation are performed for
scheduling of common data, UCI, and Msg3 on the NPUSCH.
UE Selection
UEs to be scheduled are sorted in descending order of priority. UEs that monitor CSS1 have
the highest priority, UEs that monitor CSS2 the second, and UEs that monitor the USS the
third.
MCS and Repetition Count Selection

Common Data Scheduling on the NPUSCH
SINR adjustment is required before MCS and repetition count selection.
[SINR adjustment]
The uplink channel quality of a UE can be indicated by the SINR, based on which the MCS
and repetition count can be determined for uplink scheduling. The SINR at the measurement
time may be significantly different from that at the scheduling time due to the impact of
channel fading on signals. Therefore, the SINR needs to be adjusted based on HARQ ACK/
NACK information about uplink data.
The principles of SINR adjustment are as follows:
l If the current channel quality is lower than that required by the MCS selected by the
scheduler, the BLER of data packets increases. In this case, the SINR is decreased based
on the HARQ NACK feedback.
l If the current channel quality is higher than that required by the MCS selected by the
scheduler, the BLER of data packets decreases. In this case, the SINR is increased based
on the HARQ ACK feedback.
[MCS and repetition count selection]
The MCS and repetition count are selected using the adaptive modulation and coding (AMC)
algorithm based on the uplink SINR and the numbers of ACKs and NACKs.
l If the eNodeB has not acquired the SINR measurement value, it selects the MCS and
repetition count respectively specified by the PrbUlSchCeAlgo.UlInitialMcs and
PrbUlSchCeAlgo.UlInitialTransRptCount parameters of the carrier of the UE.
l If the eNodeB has acquired the SINR measurement value, it selects the MCS and
repetition count based on the SINR and ACK/NACK.

eRAN
l When the UlPAMCSwitch option of the CellAlgoSwitch.UlSchExtSwitch parameter is

selected, the eNodeB uses an uplink AMC enhancement algorithm to select MCS
indexes and repetition counts that will result in high spectral efficiency based on uplink
SINRs. This algorithm increases the uplink UE throughput but may increase the uplink
bit error rate (BER).
NOTE
If the UE supports only single-tone transmission, MCS index 10 is used even when the MCS index is set
or adjusted to 11, 12, or 13.
Msg3 Scheduling
The MCS and repetition count are specified by PrbUlSchCeAlgo.InitialMsg3Mcs and
PrbUlSchCeAlgo.UlInitialTransRptCount, respectively.
UCI Scheduling
Only the repetition count needs to be determined:
l For the UCI related to Msg4 transmission, the repetition count is specified by
PrbUlSchCeAlgo.AckNackTransRptCountMsg4.
l For the UCI related to common data transmission, the repetition counts for different
coverage levels depend on the UCI_REP_NUM_ADAPTIVE_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter:
– If this option is selected, the repetition counts are adaptively adjusted.
– If this option is deselected, the repetition counts are determined by
PrbUlSchCeAlgo.AckNackTransRptCount.
Resource Allocation
NPUSCH scheduling consists of the scheduling of common data, UCI, and Msg3, as
described in the following table.
NPUSCH Description
Scheduling Type
Common data The required duration is determined by the buffer status and the
scheduling SINR (including an adjustment) after filtering.
UCI scheduling The required duration is determined by the repetition count.
Msg3 scheduling The required duration is determined by the coverage level, MCS,
and repetition count.
The following describes resource allocation in common data, UCI, and Msg3 scheduling.
Common Data Scheduling
The available NPUSCH start position and duration are determined for allocating NPUSCH
resources based on NPDCCH preallocation results, uplink timing constraints, start position
constraints, and uplink gap constraints. When the UlSmallRBSpectralEffOptSw option of
the CellAlgoSwitch.UlSchSwitch parameter is selected and there are no continuous
NPUSCH RUs for allocation, the number of RUs to be allocated is adjusted to adapt to the
available NPUSCH resources. This function increases the uplink resource usage in uplink

eRAN
congestion scenarios. As the resource usage increases, the number of uplink scheduling times
increases in a unit time, user-perceived rates may decrease, and uplink interference may
increase.
l Uplink timing constraints: The interval between the NPUSCH start position and the
corresponding DCI end position is at least 8 ms, according to 3GPP TS 36.213 R13.
l Start position constraints: The NPUSCH start position is determined by the
corresponding DCI end position (Sn), according to section 6.4.3.1 "DCI Format N0" in
3GPP TS 36.212 R13. It can be one of the following:
Start position = Sn + 1 + 8
l Uplink gap constraints: A 40 ms gap is required each time NPUSCH transmission lasts
256 ms for a UE, according to section 10.1.3.6 "Mapping to physical resources" in 3GPP
TS 36.211 R13. In the gap, this UE cannot be scheduled in either uplink or downlink but
other UEs can be scheduled for uplink data transmission.
l When the CellUlschAlgo.UlInterfRandomMode parameter is set to
THREE_MODE_BASED_ON_PCI, different NPUSCH search start positions and
sequences are arranged for UEs in different cells to achieve uplink subcarrier allocation
randomization and uplink interference randomization.
UCI Scheduling
The available UCI start position and NPUSCH duration are determined for allocating ACK/
NACK resources to UEs to be scheduled in the downlink, based on NPDSCH preallocation
results, downlink timing constraints, start position constraints, and uplink gap constraints.
When the UlSmallRBSpectralEffOptSw option of the CellAlgoSwitch.UlSchSwitch
parameter is selected, common data transmission may occupy UCI resources. As a result, the
available UCI resources are reduced, UCI scheduling delays increase slightly, and downlink
user-perceived rates may decrease.
l Downlink timing constraints: The interval between the UCI start position and the
corresponding NPDSCH end position is at least 12 ms, according to 3GPP TS 36.213
R13.
l Start position constraints: The UCI start position is determined by the corresponding
NPDSCH end position (Sn), according to 3GPP TS 36.212 R13. It can be one of the
following:
Start position = Sn + 1 + 12 + 2
l Uplink gap constraints: A 40 ms gap is required each time UCI transmission lasts 256 ms
for a UE, according to section 10.1.3.6 "Mapping to physical resources" in 3GPP TS
36.211 R13. In the gap, this UE cannot be scheduled in either uplink or downlink but
other UEs can be scheduled for uplink transmission.
Msg3 Scheduling
The available Msg3 start position and NPUSCH duration are determined based on NPDCCH
preallocation results, uplink timing constraints, start position constraints, and uplink gap
constraints.

eRAN
l Uplink timing constraints: The interval between the Msg3 start position and the
corresponding RAR end position is at least 12 ms, according to 3GPP TS 36.213 R13.
l Start position constraints: The Msg3 start position on the NPUSCH indicated in the RAR
is determined by the RAR end position (Sn), according to 3GPP TS 36.212 R13. It can
be one of the following:
l Uplink gap constraints: A 40 ms gap is required each time Msg3 transmission lasts 256
ms for a UE, according to section 10.1.3.6 "Mapping to physical resources" in 3GPP TS
36.211 R13. In the gap, this UE cannot be scheduled in either uplink or downlink but
other UEs can be scheduled for uplink transmission.
4.5.3.4 Uplink Scheduling for Retransmissions

Uplink scheduling for retransmissions uses asynchronous adaptive HARQ:
l Adaptive HARQ
The eNodeB determines whether a UE needs to retransmit data, based on uplink data
demodulation results. If a retransmission is required, the eNodeB performs scheduling
for the retransmission in the subsequent scheduling period. The transport block size
(TBS) used in the retransmission is the same as that assigned in the initial transmission.
If the new data indicator (NDI) value carried by the DCI is not toggled, the UE needs to
retransmit data.
UCI is not retransmitted. Common data and Msg3 may require retransmissions, and
retransmission methods for them are the same.
l Asynchronous HARQ
Uplink asynchronous HARQ can be performed at least a fixed time (a protocol
constraint) after the initial transmission or the previous retransmission finishes. It
enhances network robustness, reduces transmission errors, and expands system capacity.
The maximum number of uplink HARQ transmissions is specified by the
CellUlschAlgo.NbUlHarqMaxTxCount parameter. When the number of uplink HARQ
transmissions reaches the maximum, uplink HARQ retransmissions are stopped.
4.5.4 Downlink Scheduling
4.5.4.1 Downlink Scheduling Procedure

The downlink scheduler schedules UEs based on the UE priority in each TTI, as shown in
Figure 4-22.

eRAN
Figure 4-22 Downlink scheduling procedure
4.5.4.2 Downlink Scheduling Triggering

Downlink scheduling is triggered when the eNodeB has downlink data or signaling (such as
paging messages or RRC signaling) to send to UEs.
4.5.4.3 Downlink Scheduling for Initial Transmissions

Downlink scheduling for initial transmissions includes UE selection, MCS selection,
repetition count selection, and resource allocation.
UE Selection
UEs to be scheduled are sorted in descending order of priority. UEs that monitor CSS1 have
the highest priority, UEs that monitor CSS2 the second, and UEs that monitor the USS the
third.
For CSS1, no start position offset is involved.
For CSS2, the start position offset of a UE is specified by the
PrbPdcchCeConfig.PdcchOffset parameter of the UE's carrier.
For the USS, when the NPDCCH_OFFSET_ADAPTIVE_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, the start position offsets of
different UEs are adaptively configured to increase the downlink control channel resource
usage. When this option is deselected, the start position offsets are the same as those specified
for CSS2.
MCS and Repetition Count Selection

NPDSCH-related Processing Mechanism

eRAN
The MCS and repetition count during initial access are respectively specified by the
PrbDlSchCeAlgo.DlInitialMcs and PrbDlSchCeAlgo.DlInitialTransRptCount parameters
of the carrier of the UE. The initial MCS for RAR and Msg4 depends on the setting of the
DL_SCHEDULING_OPT_SWITCH option of the CellAlgoSwitch.NbCellAlgoSwitch
parameter.
l If this option is selected, the initial MCS index is equal to the smaller one between 4 and
the value of PrbDlSchCeAlgo.DlInitialMcs.
l If this option is deselected, the initial MCS index is equal to the value of
PrbDlSchCeAlgo.DlInitialMcs.
The MCS and repetition count are selected using the AMC algorithm based on the numbers of
ACKs and NACKs during service processing.
l If the current channel quality is lower than that required by the MCS the scheduler
selects, the BLER of data packets increases. In this case, the MCS index is decreased
based on the HARQ NACK feedback. If the MCS index has been adjusted to 0, the
repetition count is adjusted.
l If the current channel quality is higher than that required by the MCS the scheduler
selects, the BLER of data packets decreases. In this case, the MCS index is increased
based on the HARQ ACK feedback. If the MCS index has been adjusted to the largest
value, the repetition count is adjusted. When the ADAPTIVE_STEP_SWITCH option
of the CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, MCS and repetition
count adjustment can be accelerated to match channel conditions if multiple HARQ
ACKs are received consecutively. This increases downlink UE throughput and reduces
cell resource consumption, but may increase the downlink IBLER and RBLER.
l When the DL_AMC_OPT_SWITCH option of the
CellAlgoExtSwitch.NbCellAlgoExtSwitch parameter is selected, the eNodeB performs
joint adjustment on MCS indexes and repetition counts based on the number of HARQ
ACKs. This accelerates the adaptation to channel conditions, increases the downlink
rates of non-cell-center UEs, and reduces cell resource consumption, but may increase
the downlink IBLER and RBLER.
l When the RELEASE_PERFM_IMPROVE_SWITCH option of the
CellAlgoExtSwitch.NbCellAlgoExtSwitch parameter is selected, the RRC connection
release signaling repetition count is adjusted based on signaling transmission conditions
to improve the signaling demodulation success rate.
NOTE
l It is recommended that the MCS index not be set to 11, 12, or 13 in LTE in-band deployment
mode. This is because MCS index 10 is used even when the MCS index is set or adjusted to
11, 12, or 13.
l When the COVERAGE_EXTENSION_SWITCH option of the
CellDlschAlgo.NbCellAlgoSwitch parameter is deselected, the MCS index will be 0 and the
repetition count will be 1.
NPDCCH-related Processing Mechanism
During initial access, the initial repetition count and aggregation level of the NPDCCH are
determined by the product of the PrbPdcchCeConfig.PdcchMaxRepetitionCnt and
PrbPdcchCeConfig.PdcchTransRptCntFactor parameters of the UE's carrier.
l If the calculated value is 1/2, the initial repetition count of the NPDCCH is 1 and the
initial aggregation level is 1. Aggregation level 1 indicates that a DCI transmission
requires one control channel element (CCE) (that is, one half of the frequency-domain
resources of a PRB).

eRAN
l If the calculated value is greater than or equal to 1, the initial repetition count of the
NPDCCH is equal to the calculated value and the initial aggregation level is 2.
Aggregation level 2 indicates that a DCI transmission requires two CCEs (that is, all
frequency-domain resources of a PRB).
The subsequent adjustment policy is controlled by the
CellPdcchAlgo.PDCCHAggLvlAdaptStrage parameter.
l If this parameter is set to STRATEGYBASEDONCOVERAGE, the coverage-based
policy is used. The adjustment of the repetition count and aggregation level of the
NPDCCH to smaller values is relatively slow.
l If this parameter is set to STRATEGYBASEDONCAPACITY, the capacity-based
policy is used. The adjustment of the repetition count and aggregation level of the
NPDCCH to smaller values based on channel quality is relatively fast.
Resource Allocation
To calculate the downlink resources to be allocated, the scheduler determines the required
duration based on the UE buffer status, coverage level, and repetition count in each
scheduling period.
NPDCCH/NPDSCH Scheduling
Downlink scheduling must be under protocol constraints, including downlink timing
constraints, start position constraints, and downlink gap constraints.
l Downlink timing constraints defined in 3GPP TS 36.213 R13:
– The interval between the NPDSCH start position and the corresponding DCI end
position must be at least 4 ms, according to section 16.4 "Narrowband physical
downlink shared channel related procedures" in the protocol.
– The interval between the NPDCCH start position that the NB-IoT UE monitors and
the previous NPDCCH end position must be at least 4 ms, according to section 16.6
"Narrowband physical downlink control channel related procedures" in the
protocol.
Therefore, the PrbPdcchCeConfig.PdcchMaxRepetitionCnt and
PrbPdcchCeConfig.PdcchPeriodFactor parameters cannot be set to REP_4 and
G_2 respectively for the same coverage level at the same time. Otherwise, there
will be a high probability that UEs at the corresponding coverage level fail to access
the cell. If the PrbPdcchCeConfig.PdcchOffset parameter is set to
ONEFOURTH, UEs cannot access the cell.
l Start position constraints: The NPDSCH start position is determined by the
corresponding DCI end position (Sn) and the maximum repetition count, according to
section 6.4.3.2 "DCI Format N1" in 3GPP TS 36.212 R13.

eRAN
Maximum Relationship Between NPDSCH Start Position and

Repetition Count Sn
Rmax < 128 Start position = Sn + 1 + 4

Or start position = Sn + 1 + 4 + 128
Rmax ≥ 128 Start position = Sn + 1 + 4

Or start position = Sn + 1 + 4 + 1024
l Downlink gap constraints

NPDCCH/NPDSCH resource allocation is postponed when encountering a downlink
gap, according to sections 10.2.3.4 "Mapping to resource elements" and 10.2.5.5
"Mapping to resource elements" in 3GPP TS 36.211 R13. The main purpose is to avoid
UEs at a certain coverage level from exclusively occupying NPDCCH/NPDSCH
resources for a long time and affecting UEs at other coverage levels. According to the
protocol, NPDCCH/NPDSCH resource allocation is postponed when encountering a
downlink gap only for UEs whose maximum NPDCCH repetition count reaches or
exceeds the downlink gap threshold. Table 4-4 describes the parameters related to the
interval between downlink gaps and the duration of a downlink gap.
Table 4-4 Downlink gap parameters

Parameter ID Description
PrbSchConfig.DlSche The DL_GAP_SWITCH option of this parameter specifies

dulingSwitch whether to enable the downlink gap function of NB-IoT.
PrbDlGapConfig.DlG This parameter specifies a downlink gap threshold for NB-

apThreshold IoT. It is used for comparison with the maximum NPDCCH
repetition count
(PrbPdcchCeConfig.PdcchMaxRepetitionCnt) to
determine whether NPDCCH/NPDSCH resource allocation
is postponed when encountering a downlink gap for UEs at
the corresponding coverage level.

eRAN
Parameter ID Description
PrbDlGapConfig.DlG This parameter specifies the interval between downlink

apPeriod gaps for NB-IoT.
PrbDlGapConfig.DlG This parameter specifies a downlink gap duration

apDurationCoeff coefficient for NB-IoT. The downlink gap duration is equal
to the downlink gap interval multiplied by this coefficient.
Interference Randomization for the NPDCCH and NPDSCH

When the DL_INTRF_RANDOMIZATION_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, the eNodeB performs interference
randomization on the signals transmitted over the NPDCCH and NPDSCH for NB-IoT UEs
with the capability indicated by the interferenceRandomisationConfig-r14 IE. The eNodeB
sends an instruction in the interferenceRandomisationConfig IE in Msg4 to the UE. This
function improves the anti-interference capability and downlink performance of the NPDSCH
and NPDCCH.
In control plane CIoT EPS optimization mode, the obtaining of the UE capability information
from the interferenceRandomisationConfig-r14 IE depends on the procedure described in
4.4.8 UE Information Retrieval Procedure.
In user plane CIoT EPS optimization mode, UE information is stored in the UE context.
When a UE is released, its RRC connection can be suspended. After the UE re-accesses the
network, the eNodeB can directly obtain the UE information in the RRC connection resume
procedure.
RAR Scheduling
The RAR window size is specified by the CellRachCECfg.RaResponseWindowSize
parameter. In NB-IoT:
l For coverage level 0, the RAR window size is 10 times the NPDCCH period by default.
l For coverage levels 1 and 2, the RAR window size is 5 times the NPDCCH period by
default.
NPDCCH period = PrbPdcchCeConfig.PdcchMaxRepetitionCnt x
PrbPdcchCeConfig.PdcchPeriodFactor
Timer Adjustment
If the NPDCCH period is adjusted, determine whether the related timers need to be adjusted:
l If a timer uses the NPDCCH period as its unit, the timer does not need to be adjusted
generally.
l If a timer uses second or millisecond as its unit, you are advised to adjust it. The ratio of
the adjusted timer value to the adjusted NPDCCH period should equal or approach the
pre-adjustment ratio.
[Example]
The NPDCCH period for coverage level 0 is 16 ms, the contention resolution timer lasts for 8
NPDCCH periods, and the NB-IoT timer T300 lasts for 10,000 ms.
If the NPDCCH period is adjusted to 64 ms, then the contention resolution timer does not
need to be adjusted generally but the NB-IoT timer T300 needs to be adjusted, for example, to

eRAN
40,000 ms. If the NPDCCH period is adjusted to a very large value while the timers that use
second or millisecond as their unit are not adjusted, UEs may fail to access the cell.
Paging Message Scheduling
To ensure that a paging message can be delivered to a UE without delay, the start position of
the resource scheduled for this UE cannot be occupied by other UEs. You are advised to set
parameters as follows:
l If the PrbSchConfig.MaxNumRepetitionForPaging parameter is set to NULL, the
enumeration number of the PCCHCfg.NbForNbIoT parameter value must be greater
than or equal to that of the PrbPdcchCeConfig.PdcchMaxRepetitionCnt parameter
value. For example, if the PCCHCfg.NbForNbIoT parameter value is HALF_T, the
enumeration number is 3.
l If the PrbSchConfig.MaxNumRepetitionForPaging parameter is not set to NULL, the
enumeration number of the PCCHCfg.NbForNbIoT parameter value must be greater
than or equal to that of the PrbSchConfig.MaxNumRepetitionForPaging parameter
value.
4.5.4.4 Downlink Scheduling for Retransmissions

Downlink scheduling for retransmissions uses asynchronous adaptive HARQ:
l Adaptive HARQ
The eNodeB determines whether it needs to retransmit data, based on ACK/NACK
demodulation results about downlink data transmission. If NACK is received or no
feedback is received, a retransmission is required. The eNodeB performs scheduling for
the retransmission in the subsequent scheduling period. The TBS used in the
retransmission is the same as that assigned in the initial transmission.
l Asynchronous HARQ
Downlink asynchronous HARQ can be performed at least a fixed time (a protocol
constraint) after the initial transmission or the previous retransmission finishes. (For
details, see section 16.6 "Narrowband physical downlink control channel related
procedures" in 3GPP TS 36.213). It enhances network robustness, reduces transmission
errors, and expands system capacity.
Downlink scheduling determines the repetition count used in HARQ retransmission as

follows:
l If the DL_SCHEDULING_OPT_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is deselected, the repetition count used in
adaptive HARQ retransmission is the same as that assigned in the initial transmission.
l If the DL_SCHEDULING_OPT_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter is selected, the repetition count is
increased after the first retransmission fails. This repetition count will be used in the
subsequent retransmissions (if there are).
The maximum number of downlink HARQ transmissions is specified by the

CellDlschAlgo.NbDlHarqMaxTxCount parameter. When the number of downlink HARQ
transmissions reaches the maximum, downlink HARQ retransmissions are stopped.
4.6 Power Control

eRAN
4.6.1 Downlink Power Control

Fixed power allocation is used in downlink power control of NB-IoT. Different channels use
the time division multiplexing (TDM) mode. Only one type of channel exists in each
subframe. The total power of each PRB is the same. Downlink power can be calculated based
on narrowband reference signal (NRS) power.
4.6.1.1 NRS Power Allocation

An NB-IoT cell can have a maximum of two NRS ports. The NRS is transmitted in downlink
subframes and used for downlink channel estimation and data demodulation. NRS power is
indicated by the energy per resource element (EPRE). It is generally specified by the
EuPrbSectorEqm.ReferenceSignalPwr parameter. However, if this parameter is set to
32767, NRS power is specified by the PDSCHCfg.ReferenceSignalPwr parameter.
The eNodeB broadcasts NRS power in SIB2-NB. The NRS power broadcast in SIB2-NB is
calculated as follows:
l If repeaters are used to amplify the RRU output power, the AntRsPwrSwitch option of
the CellAlgoSwitch.RepeaterSwitch parameter needs to be selected. The value
broadcast in SIB2-NB is calculated based on the configured NRS power,
CellChPwrCfg.AntOutputPwr, and CellChPwrCfg.OutputPowerRate.
l If no repeaters are used, the AntRsPwrSwitch option of the
CellAlgoSwitch.RepeaterSwitch parameter needs to be deselected. The value broadcast
in SIB2-NB is equal to the configured NRS power.
4.6.1.2 NPDSCH Power Calculation

The NPDSCH and other downlink channels are transmitted in TDM mode in an NB-IoT cell.
NPDSCH OFDM symbols in a timeslot are classified into types NPDSCH_A and
NPDSCH_B (also called types A and B). Type A symbols are those without NRS, and type B
symbols are those with NRS. The following table describes the two types of symbols.
Number of Type A Symbol Type B Symbol Number of NRS

Antenna Ports Index Index REs in a Type B
Symbol
1 0, 1, 2, 3, 4 5, 6 2
2 0, 1, 2, 3, 4 5, 6 4
All REs on the NPDSCH except NRS REs have the same power.
l When a cell has one antenna port, the RE power is equal to the NRS power.
l When a cell has two antenna ports, the RE power is half of the NRS power.
The following tables provide the power calculation formulas used in standalone deployment
and LTE guard band deployment.
l Formulas used when a cell has one antenna port

eRAN
Scenario Formula
EuPrbSectorEqm.Reference P(NPDSCH_A) = P(NPDSCH_B) =

SignalPwr is set to 32767. (PDSCHCfg.ReferenceSignalPwr/10 + 10 x lg12)
dBm

SignalPwr is not set to 32767. (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
lg12) dBm
l Formulas used when a cell has two antenna ports

Scenario Formula

SignalPwr is set to 32767. (PDSCHCfg.ReferenceSignalPwr/10 + 10 x lg12
– 3) dBm

lg12 – 3) dBm
In LTE in-band deployment, the first three symbols in each NB-IoT subframe must be
punctured for LTE FDD PDCCH transmission. These symbols do not consume the NB-IoT
cell power.
If there are LTE FDD CRS REs in a symbol of a subframe, the symbol must be punctured and
a maximum of four REs can be reserved for CRS transmission. These reserved REs do not
consume the NB-IoT cell power. The following table lists the symbols that can be punctured
for CRS transmission under different LTE FDD antenna configurations.
Number of LTE FDD CRS Symbol Index

Antenna Ports
1, 2 0, 4, 7, 11
4 0, 1, 4, 7, 8, 11
The actual output power for an NB-IoT symbol punctured for CRS transmission is calculated
using the following formulas. The output power for other symbols is calculated in the same
way as that in standalone and LTE guard band deployment.
l Formulas used when an LTE FDD cell has one antenna port
Scenario Formula
EuPrbSectorEqm.Reference NPDSCH_Inband =
SignalPwr is set to 32767. (PDSCHCfg.ReferenceSignalPwr/10 + 10 x lg10)
dBm

eRAN
Scenario Formula
lg10) dBm
l Formulas used when an LTE FDD cell has two or four antenna ports
Scenario Formula
SignalPwr is set to 32767. (PDSCHCfg.ReferenceSignalPwr/10 + 10 x lg8 –
3) dBm
lg8 – 3) dBm
4.6.1.3 NPSS Power Calculation

The NPSS and other downlink channels are transmitted in TDM mode in an NB-IoT cell.
NPSS subframes need to be punctured for LTE FDD PDCCH in any deployment mode.
Therefore, the first three symbols in each NPSS subframe do not consume the NB-IoT cell
power. The methods of calculating the output power for other symbols are related to
deployment modes.
l Standalone and LTE guard band deployment

– Formulas used when a cell has one antenna port
Scenario Formula
EuPrbSectorEqm.Re P(NPSS) = (PDSCHCfg.ReferenceSignalPwr/10 + 10

ferenceSignalPwr is x lg11) dBm
set to 32767.
EuPrbSectorEqm.Re P(NPSS) =
ferenceSignalPwr is (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
not set to 32767. lg11) dBm
– Formulas used when a cell has two antenna ports
Scenario Formula
EuPrbSectorEqm.Re P(NPSS) = (PDSCHCfg.ReferenceSignalPwr/10 + 10

ferenceSignalPwr is x lg11 – 3) dBm
set to 32767.
EuPrbSectorEqm.Re P(NPSS) =
ferenceSignalPwr is (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
not set to 32767. lg11 – 3) dBm

eRAN
l LTE in-band deployment (Note: the calculated power includes the LTE FDD CRS
transmit power)
Scenario Number of LTE FDD Formula

Cell PCI mod 3
Antenna = 2?
Ports
EuPrbSector 1 Yes NPSS_Inband =

Eqm.Referenc (PDSCHCfg.ReferenceSignalPwr/1
eSignalPwr is 0 + 10 x lg10) dBm
set to 32767.
1 No NPSS_Inband =
(PDSCHCfg.ReferenceSignalPwr/1
0 + 10 x lg9) dBm
2 Yes NPSS_Inband =
0 + 10 x lg8 – 3) dBm
2 No NPSS_Inband =
0 + 10 x lg7 – 3) dBm
EuPrbSector 1 Yes NPSS_Inband =

Eqm.Referenc (EuPrbSectorEqm.ReferenceSigna
eSignalPwr is lPwr/10 + 10 x lg10) dBm
not set to
32767. 1 No NPSS_Inband =
(EuPrbSectorEqm.ReferenceSigna
lPwr/10 + 10 x lg9) dBm
2 Yes NPSS_Inband =
lPwr/10 + 10 x lg8 – 3) dBm
2 No NPSS_Inband =
lPwr/10 + 10 x lg7 – 3) dBm
4.6.1.4 NSSS Power Calculation

The NSSS and other downlink channels are transmitted in TDM mode in an NB-IoT cell.
NSSS subframes need to be punctured for LTE FDD PDCCH in any deployment mode.
Therefore, the first three symbols in each NSSS subframe do not consume the NB-IoT cell
power. The power of other symbols is calculated in the same way as that of the NPDSCH.
4.6.1.5 NPBCH Power Calculation

The NPBCH and other downlink channels are transmitted in TDM mode in an NB-IoT cell.
NPBCH subframes need to be punctured for the LTE FDD PDCCH and CRS in any
deployment mode. The NPBCH power is calculated in the same way as the NPDSCH power
in LTE in-band deployment mode.

eRAN
4.6.1.6 NPDCCH Power Calculation

The NPDCCH and other downlink channels are transmitted in TDM mode in an NB-IoT cell.
In an NPDCCH subframe:
l When the NPDCCH aggregation level is 2, each NPDCCH scheduling unit occupies all
of the frequency-domain resources of a PRB. The NPDCCH power is calculated in the
same way as for the NPDSCH.
l When the NPDCCH aggregation level is 1, each NPDCCH scheduling unit occupies half
of the frequency-domain resources of a PRB. NPDCCH resources can be allocated to
two UEs in a subframe. If only one NPDCCH scheduling unit is allocated to a UE in a
subframe, the NPDCCH power is half of the NPDSCH power.
4.6.2 Uplink Power Control

Only open-loop power control can be used in the uplink according to NB-IoT protocols, to
reduce UE power consumption and system overhead.
4.6.2.1 NPRACH Power Control

NB-IoT supports only open-loop power control for the NPRACH.
NPRACH power control aims to ensure the random access success rate, minimize the
preamble transmit power, reduce interference to neighboring cells, and conserve UE power.
The NPRACH transmit power for UEs at coverage level 0 is calculated using the following
formula:
NPRACH transmit power = min{PCMAX,
NARROWBAND_PREAMBLE_RECEIVED_TARGET_POWER + PL}
where
l PCMAX is the maximum transmit power of the UE. It is equal to the smaller value
between the Cell.UePowerMax parameter value and the maximum transmit power
supported by the UE.
l NARROWBAND_PREAMBLE_RECEIVED_TARGET_POWER is the target power
expected by the eNodeB for preamble detection. It is specified by the
RACHCfg.PreambInitRcvTargetPwr parameter.
l PL is the downlink path loss estimated by the UE based on the RSRP measurement
values and NRS transmit power.
– The alpha filtering coefficient used for RSRP measurement value filtering is
specified by the CellUlpcDedic.FilterRsrp parameter.
– The NRS transmit power is specified by the
EuPrbSectorEqm.ReferenceSignalPwr parameter of the anchor carrier and
broadcast in SIB-NBs.
l The UE increases the NPRACH transmit power gradually if it does not receive the RAR
message. The power ramping step is specified by the RachCfg.PwrRampingStep
parameter.
When the RACHCfg.PreambInitRcvTargetPwrCE1 and RACHCfg.PwrRampingStepCE1
parameters are not set to NOT_CFG, the open-loop power control procedure for coverage-
level-1 UEs with the capability indicated by the PowerRampingParameters-NB-v1450 IE is

eRAN
the same as that for coverage-level-0 UEs. The NPRACH transmit power is calculated based
on the RACHCfg.PreambInitRcvTargetPwrCE1 and RACHCfg.PwrRampingStepCE1
parameters. For details, see section 6.7.3 "NB-IoT information elements" in 3GPP TS 36.331
V14.6.0.
In other cases, PCMAX is used as the NPRACH transmit power and not adjusted. For details,
see section 16.2.1 "Uplink power control" in 3GPP TS 36.213 and section 5.1.3 "Random
Access Preamble transmission" in 3GPP TS 36.321.
4.6.2.2 NPUSCH Power Control

NB-IoT supports only open-loop power control for the NPUSCH.
PCMAX is used by the UE as the transmit power and not adjusted when the following
conditions are met:
l The currently scheduled NPUSCH repetition count is greater than 2.
l The RACHCfg.PreambInitRcvTargetPwrCE1 and RACHCfg.PwrRampingStepCE1
parameters are both set to NOT_CFG, or the UE does not have the capability indicated
by the PowerRampingParameters-NB-v1450 IE.
Otherwise, the NPUSCH transmit power (dBm) is calculated using the following formula:
where
l i indicates the current timeslot.
l c indicates the serving cell.
l PCMAX is the maximum transmit power of the UE. It is equal to the smaller value
between the Cell.UePowerMax parameter value and the maximum transmit power
supported by the UE.
l MNPUSCH is the number of subcarriers.
– It is set to 1/4 for single-tone transmission using 3.75 kHz subcarriers.
– It is set to 1 for single-tone transmission using 15 kHz subcarriers.
– It can be set to 3, 6, or 12 for multi-tone transmission.
l PL is the downlink path loss estimated by the UE based on the RSRP measurement
values and NRS transmit power.
– The alpha filtering coefficient used for RSRP measurement value filtering is
specified by the CellUlpcDedic.FilterRsrp parameter.
– The NRS transmit power is specified by the PDSCHCfg.ReferenceSignalPwr or
EuPrbSectorEqm.ReferenceSignalPwr parameter and broadcast in SIB-NBs.
l P0_NPUSCH is the eNodeB's RX power that meets the requirements for NPUSCH
demodulation.
P0_NPUSCH,c = P0_NORMINAL_NPUSCH,c + P0_UE_NPUSCH,c
where
P0_NORMINAL_NPUSCH is the RX power expected by the eNodeB for NPUSCH
demodulation.

eRAN
– If the NPUSCH carries Msg3 in the random access procedure, then:
where
n P0_PRE is specified as follows:
○ When the RACHCfg.PreambInitRcvTargetPwrCE1 and
RACHCfg.PwrRampingStepCE1 parameters are not set to NOT_CFG,
P0_PRE is specified by the RACHCfg.PreambInitRcvTargetPwrCE1
parameter for coverage-level-1 UEs that have the capability indicated by
the PowerRampingParameters-NB-v1450 IE. For details, see section
6.7.3 "NB-IoT information elements" in 3GPP TS 36.331 V14.6.0.
○ In other cases, P0_PRE is specified by the
RACHCfg.PreambInitRcvTargetPwr parameter.
n is specified by the CellUlpcComm.DeltaPreambleMsg3

parameter.
– The UE increases the NPUSCH transmit power gradually if it does not receive a
response. The power ramping step is specified as follows:
n When the RACHCfg.PreambInitRcvTargetPwrCE1 and
RACHCfg.PwrRampingStepCE1 parameters are not set to NOT_CFG, the
power ramping step is specified by the RACHCfg.PwrRampingStepCE1
parameter for coverage-level-1 UEs that have the capability indicated by the
PowerRampingParameters-NB-v1450 IE. For details, see section 6.7.3 "NB-
IoT information elements" in 3GPP TS 36.331 V14.6.0.
n In other cases, the power ramping step is specified by the
RACHCfg.PwrRampingStep parameter.
– If the NPUSCH does not carry Msg3 in the random access procedure,
P0_NORMINAL_NPUSCH is specified by the CellUlpcComm.P0NominalPUSCH
parameter.
P0_UE_NPUSCH is the offset of the UE transmit power relative to P0_NORMINAL_NPUSCH.
The UE transmit power can be adjusted slightly but currently the offset is always 0.
l α is a path loss compensation factor.
– It is always set to 1 if the NPUSCH carries UCI or Msg3 in the random access
procedure.
– It is specified by the CellUlpcComm.PassLossCoeff parameter in other situations.
The value AL1 is recommended.
This is because, according to current protocols, NPUSCH format 1 and NPUSCH
format 2 (for UCI) use the same P0_NORMINAL_NPUSCH. If the
CellUlpcComm.PassLossCoeff parameter value is inappropriate, the RX power for
NPUSCH format 2 may be much higher than that for NPUSCH format 1, causing
strong interference to adjacent subcarriers. For details about NPUSCH format 1 and
NPUSCH format 2, see Table 3-2.
4.7 Access and Congestion Control

Access and congestion control is performed in scenarios such as random access for new
services or RRC connection setup based on system load to relieve network congestion. It

eRAN
improves user experience, ensures the performance of high-priority services, and maximizes
system capacity. However, it may decrease the access success rate and increase the service
drop rate.
4.7.1 Admission Control

When a UE initiates a service request in a cell, the admission control algorithm checks
whether the system load and UE number exceed the limits. The specific process is as follows:
1. If CPU resources are insufficient, the UE is rejected. For details about how to check
whether CPU resources are insufficient, see Flow Control.
2. If the number of admitted UEs reaches one of the following numbers, the UE is rejected:
– Number specified by the CellRacThd.AcUserNumber parameter
– Maximum number of UEs in connected mode allowed in a cell
– Maximum number of UEs in connected mode supported by a main control board or
BBP
For the maximum number of UEs in connected mode allowed in a cell or supported by a
main control board or BBP, see technical descriptions in base station product
documentation.
3. If the UE is rejected, it can preempt other UEs. When the NbUeNumPreemptSwitch
option of the ENodeBAlgoSwitch.UeNumPreemptSwitch parameter is selected, high-
priority UEs can preempt low-priority UEs, increasing the access success rate of high-
priority UEs. If all priorities are the same, the eNodeB randomly selects a UE for
preemption. Preemption priorities are determined based on RRC connection setup
causes. For UEs with the same cause, the priorities are determined based on allocation
and retention priority (ARP). The smaller the ARP value, the higher the priority. The
following provides the RRC connection setup causes in descending order of preemption
priority:
a. Mobile Originated Exception Data (mo-Exception-Data)
b. Paging
c. Mobile Terminated Access (mt-Access)
d. Mobile Originated Signaling (mo-Signaling)
e. Mobile Originated Data (mo-Data)
f. delayTolerantAccess-v1330
UEs with the Pre-emption Vulnerability IE set to "not pre-emptable" cannot be
preempted.
For a preempted UE, the RRC connection reject or release message includes an
extendedWaitTime IE with the value equal to the
RrcConnStateTimer.ExtendedWaitTime parameter value plus a random value.
Preempted UEs can then access the cell again on different occasions, depending on the
extendedWaitTime values.
4. If NB-IoT and LTE FDD are co-sited, the total number of their UEs in connected mode
cannot exceed the maximum permissible number. When an LTE FDD UE accesses the
cell but resources are insufficient:
– NB-IoT UEs can be preempted by the LTE FDD UE if
ENodeBAlgoSwitch.LTEPreemptNbSwitch is turned on.
– NB-IoT UEs with low priorities are preempted preferentially. NB-IoT UEs with the
RRC connection setup cause "delayTolerantAccess-v1330" have the lowest priority

eRAN
and therefore are preempted first. NB-IoT UEs with the Pre-emption Vulnerability
IE set to "not pre-emptable" are preempted last.
– To prevent NB-IoT UEs from failing to access the cell due to excessive RRC
resource preemption, a minimum number of UEs in connected mode can be set for
NB-IoT. The minimum number of UEs in connected mode set for NB-IoT equals
the product of ENodeBNbPara.NbRsvMinUserNumRatio and the maximum
number of UEs in connected mode supported by the eNodeB. When the number of
NB-IoT UEs in connected mode is less than or equal to this minimum number, NB-
IoT UEs cannot be preempted by the LTE FDD UE.
4.7.2 Congestion Control

This section describes the congestion control functions.
Backoff
A large number of random access requests at the same time lead to a high load or even a reset
of the system. To address this issue, the eNodeB sends different backoff indications to
different UEs based on the NPRACH congestion status to control the number of simultaneous
random access requests. The UEs randomly select access retry occasions based on the backoff
indications, reducing collisions. The backoff function is controlled by the BackOffSwitch
option of the CellAlgoSwitch.RachAlgoSwitch parameter.
If some UEs on the live network do not support the maximum backoff index 12 defined in
3GPP TS 36.321 R13, the PreambleSchEnhSwitch option of the
CellAlgoSwitch.UlSchExtSwitch parameter needs to be selected.
Access Barring
Access barring aims to protect the system and admitted UEs from the possible impact of a
sudden spike in UE access. Access barring is defined in 3GPP TS 36.331 R13.
When a cell is congested or the MMEs connected to the eNodeB are all overloaded, the
eNodeB broadcasts access class (AC) control parameters to UEs using the access barring
(AB) IE in SIB14-NB. The SIB14-NB broadcast period is specified by the
CellSiMap.NbSib14Period parameter. The UEs determine whether to initiate access to the
cell based on the received parameters. Access barring is controlled by the EABAlgoSwitch
option of the CellAlgoSwitch.MTCCongControlSwitch parameter.
The eNodeB supports manual and dynamic access barring.
l If the CellEABAlgoPara.ACCountForManualBarring parameter is set to a valid value,

manual access barring is used. The number of barred access classes for UEs of AC0 to
AC9 is broadcast in SIB14-NB.
l If the CellEABAlgoPara.ACCountForManualBarring parameter is set to an invalid
value, dynamic access barring is used.
The CellEABAlgoPara.ABForSpecialAC parameter specifies whether NB-IoT UEs of
AC11 to AC15 can initiate access.
The eNodeBFlowCtrlPara.DynAcBarPolicyMode parameter specifies whether cell
congestion judgment is made based on flow control status or CPU load.
The CellEABAlgoPara.ABForExceptionData parameter specifies whether NB-IoT
UEs can initiate access with the cause "mo-Exception-Data" when the cell is congested.

eRAN
The CellEABAlgoPara.EABCategory parameter specifies which type of UEs can be

barred when the cell is congested. The eNodeB determines whether to bar such UEs
during a statistical period. The period starts when the access barring function is enabled,
and the duration is specified by the CellEABAlgoPara.EABStatPeriod parameter.
– Access barring triggering
Access barring is triggered when the percentage of cell congestion duration reaches
or exceeds the CellEABAlgoPara.EABTriggerThd parameter value. UEs that meet
barring conditions are barred for a period specified by the
CellEABAlgoPara.EABStatPeriod parameter. If the cell is still congested after the
access barring period, not only these UEs but also other types of UEs are barred.
– Access barring canceling
Access barring can be cancelled when the percentage of cell congestion duration
reaches or drops below the CellEABAlgoPara.EABCancelThd parameter value.
The specified type of UEs can access the cell when the canceling condition is met
for N consecutive statistical periods. N is specified by the
CellEABAlgoPara.EABCancelCondSatiPeriod parameter.
Figure 4-23 illustrates access barring by using the parameter values provided in Table 4-5.
1. If the percentage of cell congestion duration within 20s exceeds 90% or all the MMEs
connected to the eNodeB deliver overload messages, the eNodeB will send SIB14-NB to
UEs.
2. AC0 UEs are barred from accessing the cell, according to the bit information in SIB-NB.
The barring duration is 20s.
3. If the canceling condition (that is, the proportion of cell congestion duration within 20s is
less than 70%) is met for two consecutive periods, the eNodeB will not send SIB14-NB
and will stop access barring on UEs.
Figure 4-23 Access barring
Table 4-5 Example values of access barring parameters
Parameter Name Parameter ID Example Value
EAB Control Statistic CellEABAlgoPara.EABSta 20s

Periods tPeriod

eRAN
Parameter Name Parameter ID Example Value
EAB Control Trigger CellEABAlgoPara.EABTri 90%

Threshold ggerThd
EAB Control Cancel CellEABAlgoPara.EABCa 70%

Threshold ncelThd
EAB Cancel Condition CellEABAlgoPara.EABCa 2

Satisfied Period ncelCondSatiPeriod
EAB Category CellEABAlgoPara.EABCat CATEGORY_A

egory
NB-IoT SIB14 Period CellSiMap.NbSib14Period RF512
NB-IoT Access Barring For CellEABAlgoPara.ABFor BOOLEAN_FALSE

Exception Data ExceptionData
NB-IoT Access Barring For CellEABAlgoPara.ABForS AC11BARSTATE:Permit,

AC11-15 pecialAC AC12BARSTATE:Permit,
AC13BARSTATE:Permit,
AC14BARSTATE:Permit,
AC15BARSTATE:Permit
Access Class Count for CellEABAlgoPara.ACCou 255

Manual Access Barring ntForManualBarring
Low-Priority UE Rejection
When there are no sufficient cell resources for processing Msg3, the eNodeB rejects UEs with
the cause "delayTolerantAccess-v1330."
4.7.3 Overload Control

Overload control is performed when there is a sudden spike in external services. It controls
incoming flows to prevent overload and improve equipment stability. Overload control
improves NE stability by reducing the possibility of NE resets. It can also reduce the risk of a
decreased access success rate and provide a more stable user experience.
l MME-overload-triggered flow control
The objective of MME-overload-triggered overload control is to relieve the impact of
MME overload caused by a large number of UEs accessing the network.
When an MME is overloaded, it sends an OVERLOAD START message to the eNodeB,
indicating that the eNodeB needs to start flow control. The eNodeB then limits UE
access based on their RRC connection setup causes. When the MME is no longer
overloaded, it sends an OVERLOAD STOP message to the eNodeB, instructing the
eNodeB to stop flow control. For detailed principles, see 3GPP TS 36.413 R13.
In control plane CIoT EPS optimization mode, the eNodeB rejects UEs with the RRC
connection setup cause "mo-Data" or "delayTolerantAccess-v1330" when the MME
delivers an OVERLOAD START message with the cause "not accept mo-data or delay
tolerant access from CP CIoT."
When the ExtendedwaittimeSwitch option of the
CellAlgoSwitch.MTCCongControlSwitch parameter is selected, the RRC connection

eRAN
reject message carries an extendedWaitTime IE for UEs with the RRC connection setup
cause "delayTolerantAccess-v1330". The IE value is the sum of the
RrcConnStateTimer.ExtendedWaitTime parameter value and a random value. By
adjusting the extendedWaitTime value, the eNodeB randomizes the access of UEs.
l Random access message flow control
A large number of random access messages lead to a high load or even a reset of the
system.
The eNodeB adjusts the number of random access UEs based on the control plane CPU
usage of BBPs or the air interface congestion status of cells.
When the air interface is congested in a cell, random access message flow control is
controlled by the UlRaUserSchOptSw option of the CellAlgoSwitch.UlSchSwitch
parameter. The specific processing is as follows:
– Msg2 MAC headers are preferentially scheduled to ensure backoff indications are
promptly delivered to UEs. This decreases the number of random access messages
and reduces network load.
– The number of random access messages is controlled.
l RRC connection request or resume request message flow control
This function is controlled by the UlRaUserSchOptSw option of the
CellAlgoSwitch.UlSchSwitch parameter and the ExtendedwaittimeSwitch option of
the CellAlgoSwitch.MTCCongControlSwitch parameter.
An RRC Connection Request-NB or RRC Connection Resume Request-NB message is
the initial message of a procedure. After an RRC connection request or resume request
message is successfully received, a series of subsequent operations are required, causing
high overhead. Therefore, flow control is required at the beginning of the signaling
procedure. The RRC connection reject or release message carries the extendedWaitTime
IE. The IE value is the sum of the RrcConnStateTimer.ExtendedWaitTime parameter
value and a random value. By adjusting the extendedWaitTime value, the eNodeB
randomizes the access of UEs and reduces the system load from the beginning.
Services with different access causes are prioritized so that high-priority services can be
ensured by control-plane flow control. The following lists the services in descending
order by priority:
a. Mobile Originated Exception Data (mo-Exception-Data)
b. Mobile Terminated Access (mt-Access)
c. Mobile Originated Signaling (mo-Signaling)
d. Mobile Originated Data (mo-Data)
e. delayTolerantAccess-v1330
When an eNodeB is overloaded, it rejects or discards some RRC connection or resume
request messages based on the CPU usage of the main control board or BBP.
If the eNodeB load is continuously heavy, the eNodeB controls the number of signaling
messages received from peer NEs to reduce the load as follows:
– A reduction of the SCTP buffer threshold can decrease the amount of signaling
from the MMEs to the eNodeB and reduce downlink load from the MMEs to the
eNodeB.
– Access barring is used to reduce the frequency of UE access to cells and reduce
uplink load on the eNodeB.
l Paging message flow control

eRAN
If there are too many paging messages, they cannot be promptly delivered over the air
interface. Therefore, paging messages require flow control. To ensure high-priority
services, paging messages for low-priority services are restricted first. The priorities are
indicated in paging messages. For services with the same priority, the eNodeB identifies
their paging scopes according to the paging messages delivered by the MME. It then
delivers the paging messages in the sequence of local area > extended area > TAL-
indicated area.
l In user plane CIoT EPS optimization mode, traffic flow control can be performed based
on the PDCP packet buffer usage. When the buffer usage is excessively high, flow
control is performed.
4.7.4 Application Examples

When a large number of UEs attempt to access a network, the air interface will be congested,
it will be hard for the UEs to access the network, and the network performance will
deteriorate. Under these circumstances, operators are advised to:
l Enable the backoff function.
l Enable the access barring function.
l Enable the random access message flow control function.
l Allow the extendedWaitTime IE to be included in RRC connection release messages,
postponing the access of UEs and relieving air interface congestion. This function is
controlled by the ExtendedwaittimeSwitch option of the
CellAlgoSwitch.MTCCongControlSwitch parameter.
4.8 DRX
DRX is a work mode for the purpose of reducing UE power consumption. UEs turn on their
receivers only in necessary periods to enter the active state and receive downlink data. The
UEs turn off their receivers in other periods to enter the sleep state and stop receiving
downlink data. This function can reduce UE power consumption but may prolong UE service
delays.
4.8.1 DRX-related Concepts

On Duration
In DRX mode, a UE in connected mode does not constantly keep its receiver off. It
periodically turns on its receiver and then continuously monitors signaling that may arrive
within a period. This period is called On Duration and controlled by the On Duration Timer.
The length of this period is specified by the CellDrxPara.NbOnDurationTimer parameter.
DRX Cycle
A DRX cycle is the interval between two On Durations. A DRX cycle consists of active time
and sleep time. NB-IoT supports only a long DRX cycle. A DRX cycle consists of an On
Duration and a possible period of sleep time, as shown in Figure 4-24.

eRAN
Figure 4-24 DRX cycle
The On Duration does not last a fixed time because the On Duration Timer will stop after
certain conditions are met.
Active Time
The time during which the UE can monitor the NPDCCH is called active time. The UE turns
on its receiver in active time. Active time consists of On Duration and other possible periods
during which the UE needs to turn on its receiver, for example, when other DRX timers are
running. DRX timers include the DRX Inactivity Timer, DRX Retransmission Timer, and
DRX UL Retransmission Timer.
If the duration of a DRX cycle is specified:
l A longer active time results in a shorter service delay but increased UE power
consumption because the receiver works for a longer time in a cycle.
l A shorter active time results in reduced UE power consumption but a longer service
delay because the receiver is turned off for a longer time in a cycle.
Sleep Time
Inactive time in a DRX cycle is called sleep time. In sleep time, the UE does not monitor the
NPDCCH but can send/receive the NPUSCH/NPDSCH information scheduled in active time.
The UE can turn off its receiver when there is no data transmission.
4.8.2 Startup of a DRX Cycle

After the UE enters the DRX mode, the On Duration timer and the DRX cycle start only when
the following condition is met:
(SFN x 10 + SSFN) mod CellDrxPara.NbLongDrxCycle = DRX start offset
where
l SFN: system frame number
l SSFN: system subframe number
4.8.3 Operation in a DRX Cycle

A DRX cycle includes active time and sleep time, as shown in Figure 4-25.

eRAN
Figure 4-25 Switching between active and sleep time of DRX
Table 4-6 describes the related DRX timers.
Table 4-6 DRX timers

Timer Parameter ID Definition Description
On Duration CellDrxPara.N Function This timer starts at the beginning

Timer bOnDurationTi of a DRX cycle and specifies the
mer time during which the UE can
monitor the NPDCCH.
CellDrxPara.N Startup This timer starts at the first

bOnDurationTi subframe of a DRX cycle.
mer
CellDrxPara.N Timing The UE's NPDCCH period is used

bOnDurationTi as a measurement unit.
mer
CellDrxPara.N Stop l This timer stops when

bOnDurationTi NPDCCH message
mer transmission to this UE is
completed.
l This timer stops after it expires.
CellDrxPara.N Expiry After this timer expires, the UE

bOnDurationTi enters the sleep state, no longer
mer monitoring the NPDCCH.
DRX Inactivity CellDrxPara.N Function This timer determines whether to

Timer bDRXInactivity extend the UE active time due to
Timer the arrival of initially transmitted
or retransmitted data.
CellDrxPara.N Startup During uplink and downlink

bDRXInactivity scheduling, this timer can start or
Timer restart after the HARQ RTT Timer
expires.

eRAN

bDRXInactivity as a measurement unit.
Timer
CellDrxPara.N Stop l This timer stops when

bDRXInactivity NPDCCH message
Timer transmission to this UE is
completed.
l This timer stops after it expires.

bDRXInactivity enters the sleep state, no longer
Timer monitoring the NPDCCH.
DRX CellDrxPara.N Function This timer specifies the maximum

Retransmission BDRXReTxTi waiting time for downlink
Timer mer retransmission when the UE is in
active time. If the UE has not
received the downlink
retransmitted data before this timer
expires, the UE will no longer
accept it.

BDRXReTxTi scheduling, this timer can start or
mer restart after the HARQ RTT Timer
expires.

BDRXReTxTi as a measurement unit.
mer
CellDrxPara.N Stop This timer stops if the

BDRXReTxTi retransmitted data is received
mer before the timer expires.

BDRXReTxTi takes no further action.
mer
DRX UL CellDrxPara.N Function This timer specifies the maximum

Retransmission bDRXUlReTxT waiting time for uplink
Timer imer retransmission when the UE is in
active time. If the UE has not
received the uplink retransmission
scheduling indicator before this
timer expires, the UE will no
longer monitor the NPDCCH.

bDRXUlReTxT scheduling, this timer can start or
imer restart after the HARQ RTT Timer
expires.

eRAN

bDRXUlReTxT as a measurement unit.
imer
CellDrxPara.N Stop l This timer stops if the

bDRXUlReTxT retransmitted data is received
imer before the timer expires.
l This timer stops when
NPDCCH message
transmission to this UE is
completed.

bDRXUlReTxT takes no further action.
imer
HARQ RTT - Function This timer specifies the interval

Timer between the initial downlink data
transmission and the downlink
retransmission. This timer is used
to determine when to start a timer
related to a prolonged active time.
- Startup The HARQ RTT Timer starts after

the last repeated block of
NPDSCH or NPUSCH resources.
For details, see the following note.
- Timing Timing is based on the number of

subframes.
- Stop This timer stops after it expires.
- Expiry After this timer expires, the DRX

Inactivity Timer, DRX
Retransmission Timer, and DRX
UL Retransmission Timer start.
Note:
l Downlink HARQ RTT Timer value = k + N + 3 + deltaPDCCH
– k is the interval between the last transmission subframe and the first subframe of the
HARQ feedback.
– N is the transmission duration for HARQ feedback.
– 3 + deltaPDCCH is the interval between the HARQ feedback end subframe and the
subsequent NPDCCH occasion. The interval must be at least 3 ms.
l Uplink HARQ RTT Timer value = 4 + deltaPDCCH
4 + deltaPDCCH indicates the interval between the NPUSCH transmission end
subframe and the subsequent NPDCCH occasion. The interval must be at least 4 ms.

eRAN
4.9 Cell Access Radius up to 35 km

To improve radio network coverage, 3GPP TS 36.211 R13 defines two cyclic prefix (CP)
lengths for NPRACH subframes: 66.7 μs and 266.7 μs. When the CP length is 266.7 μs, the
maximum NB-IoT cell radius is 35 km.

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 5 Network Analysis
5 Network Analysis
The overall benefits of NB-IoT are as follows:

l Maximized spectrum resource utilization
NB-IoT can utilize the existing spectrum resources of operators. It can be deployed in
standalone, LTE guard band, and LTE in-band modes to improve spectral efficiency.
l Support of a large number of low-speed UEs
l Deep coverage
NB-IoT can improve coverage by 20 dB compared with LTE by repetition in the time
domain and boost in the power spectral density (PSD).
l Low UE power consumption
NB-IoT optimizes the protocol stacks based on application scenario analysis, simplifying
information processing and signaling interaction. It reduces UE power consumption and
prolongs standby time.
Different deployment modes have different impacts. For details, see the descriptions of these
deployment modes.
5.1 Standalone Deployment
5.1.1 Benefits
Standalone deployment improves spectral efficiency by refarming GSM spectrum or using
idle spectrum to deploy NB-IoT.
5.1.2 Impacts
Network Impacts
If NB-IoT and LTE FDD share RF modules in standalone deployment mode, power allocation
will change when NB-IoT has a higher power spectral density (PSD) than LTE FDD. For LTE
FDD cell center users (CCUs), the average throughput and average MCS index may be lower
and the RBLER may be higher than those before NB-IoT configuration. The peak throughput
of LTE FDD CCUs may also decrease; the higher the modulation order, the greater the
decrease.

eRAN
Function Impacts
Function Function Reference Description
Name Switch
Basic symbol SymbolShutdo Energy (Impact on LTE FDD) If NB-IoT

power saving wnSwitch Conservation and LTE FDD cells share the same
option of the and Emission power amplifier (PA), the symbol
ENodeBAlgoS Reduction power saving effect will be
witch.PowerSa reduced in the LTE FDD cell. This
veSwitch is because:
parameter l The pilot symbols of the NB-
IoT cell and those of the LTE
FDD cell are completely
staggered in the time domain.
l The NB-IoT cell uses more
symbols in the time domain for
NPSS, NSSS, MIB-NB, and
SIB-NB transmission than the
LTE FDD cell.
CPRI Cell.CPRICom CPRI (Impact on LTE FDD) If the

compression pression Compression LBBPd1, LBBPd2, or LBBPd3 is
used and the BBP.WM parameter
is set to FDD_NBIOT,
FDD_NBIOT_ENHANCE, or
FDD_NBIOT_CUSTOM, then
the Cell.CPRICompression
parameter must be set to
NO_COMPRESSION for the
LTE FDD cells carried on this
board. Otherwise, these LTE FDD
cells cannot be activated.
NB-IoT NB_OTDOA_ LCS The downlink rate of the NB-IoT

OTDOA-based SWITCH cell decreases because narrowband
positioning option of the positioning reference signal
CellLcsCfg.Cel (NPRS) transmission occupies
lLcsSwitch downlink resources.
parameter When the NPRS configuration
mode is Part B, downlink
scheduling reserves REs for NPRS
transmission, decreasing the MCS
index and increasing the downlink
BLER for UEs.
5.2 LTE Guard Band Deployment

eRAN
5.2.1 Benefits
LTE guard band deployment improves spectral efficiency by fully utilizing LTE guard bands.
5.2.2 Impacts
Network Impacts
If NB-IoT and LTE FDD share RF modules in LTE guard band deployment mode, power
allocation will change when NB-IoT has a higher PSD than LTE FDD. For LTE FDD CCUs,
the average throughput and average MCS index may be lower and the RBLER may be higher
than those before NB-IoT configuration. The peak throughput of LTE FDD CCUs may also
decrease; the higher the modulation order, the greater the decrease.
Function Impacts
Name Switch
Scalable None Cell The LTE FDD cell bandwidth

bandwidth Management must be at least 10 MHz for LTE
guard band deployment.
Compact Cell.Customize Compact Overlapping between NB-IoT

bandwidth dBandWidthCf Bandwidth resources and punctured guard
gInd (FDD) band resources should be avoided
in LTE guard band deployment so
as to prevent mutual interference.
Basic symbol SymbolShutdo Energy If NB-IoT and LTE FDD cells

power saving wnSwitch Conservation share the same PA, the symbol
option of the and Emission power saving effect will be
ENodeBAlgoS Reduction reduced in the LTE FDD cell. This
witch.PowerSa is because:
veSwitch l The pilot symbols of the NB-
parameter IoT cell and those of the LTE
symbols in the time domain for
NPSS, NSSS, MIB-NB, and
SIB-NB transmission than the
LTE FDD cell.

eRAN

Name Switch
CPRI Cell.CPRICom CPRI (Impact on LTE FDD) If the

compression pression Compression LBBPd1, LBBPd2, or LBBPd3 is
used and the BBP.WM parameter
is set to FDD_NBIOT,
board. Otherwise, these LTE FDD
cells cannot be activated.
NB-IoT NB_OTDOA_ LCS After NB-IoT OTDOA-based

OTDOA-based SWITCH positioning is enabled, the
positioning option of the downlink rate of the NB-IoT cell
CellLcsCfg.Cel decreases because NPRS
lLcsSwitch transmission occupies downlink
parameter resources.
When the NPRS configuration
scheduling reserves REs for NPRS
transmission, decreasing the MCS
index and increasing the downlink
BLER for UEs.
Flexible DdCellGroup. Flexible In LTE guard band mode, avoid

bandwidth DdBandWidth Bandwidth NB-IoT deployment on
based on based on overlapping RBs that are formed
overlapping Overlap by the "flexible bandwidth based
carriers Carriers (FDD) on overlapping carriers" function
so as to prevent mutual
interference.
UMTS and LTE DC_HSDPA_B UMTS and LTE This function punctures PRBs
Spectrum ASED_UL_SP Spectrum available to LTE, making the
Sharing Based ECTRUM_SH Sharing Based guard band unavailable for NB-
on DC-HSDPA R option of the on DC-HSDPA IoT deployment.
SpectrumClou
d.SpectrumClo
udSwitch
parameter
5.3 LTE In-Band Deployment

eRAN
5.3.1 Benefits
LTE in-band deployment utilizes PRBs within an LTE FDD band for NB-IoT.
5.3.2 Impacts
Impact of LTE FDD on NB-IoT

In LTE in-band deployment mode, the Prb.UlAllSymbolSendFlag parameter needs to be set
to FALSE to avoid a conflict between NPUSCH and LTE FDD sounding reference signal
(SRS) resources. This setting will lead to a decrease in the single-RU bit rate of NB-IoT. As a
result, the MCS index may be lowered and the uplink capacity of NB-IoT may be decreased
by 8% to 20%.
In LTE in-band deployment mode, NB-IoT PRBs are affected by uplink adjacent channel
leakage of LTE FDD. Consequently, the overall noise floor increases and the NB-IoT
coverage shrinks. The interference that NB-IoT experiences is related to the uplink received
signal strength in the LTE FDD cell and the adjacent channel leakage ratio (ACLR) of LTE
FDD UEs.
Impact of NB-IoT on LTE FDD

In LTE in-band deployment mode, each time a PRB in the LTE FDD cell is used to deploy
NB-IoT (additional uplink PRBs may be used as guard bands), fewer PRBs are available to
the LTE FDD cell and all existing LTE FDD KPIs are affected.
The following analyzes the theoretical decreases in the number of PRBs and the single-UE
peak rates:
l If uplink and downlink NB-IoT PRBs are positioned as recommended in 6.4.1 NB-IoT
PRB Planning, the decreases in the number of LTE FDD PRBs and the single-UE peak
rates are listed in Table 5-1.
l If uplink and downlink NB-IoT PRBs are not positioned as recommended, more PRBs
may be unavailable to LTE FDD. If uplink NB-IoT PRBs are not edge PRBs, uplink LTE
FDD PRBs are inconsecutive and the single-UE peak rate may decrease by up to 50%.
This is because some inconsecutive PRBs cannot be allocated, according to LTE-
protocol-defined PRB allocation principles (such as allocation of consecutive uplink
resources to a single carrier, allocation of an integer multiple of 2, 3, or 5 uplink PRBs,
symmetrical PUCCH resource allocation, and downlink resource block group (RBG)
based allocation). For the detailed principles of uplink and downlink PRB allocation in
LTE FDD, see Scheduling.
Table 5-1 Theoretical decreases in the number of PRBs and the single-UE peak rates in an
LTE FDD cell (each time a PRB is reserved)
Cell Decrease in Decrease in the Decrease in Decrease in the

Bandwidt the Number Downlink the Number Uplink Single-
h of Downlink Single-UE of Uplink UE Peak Rate
PRBs Peak Rate PRBs
3 MHz 6.7% 7% to 23% 6.7% 14.5% to 21.5%
5 MHz 4% 8% to 14.5% 4% 1% to 4.5%

eRAN
Cell Decrease in Decrease in the Decrease in Decrease in the

Bandwidt the Number Downlink the Number Uplink Single-
h of Downlink Single-UE of Uplink UE Peak Rate
PRBs Peak Rate PRBs
10 MHz 2% 6% to 10.5% 2% 3.5% to 7%
15 MHz 1.3% 5% to 7.5% 1.3% 3% to 12.5%
20 MHz 1% 4% to 7.5% 1% 3.5% to 7%
Table 5-2 presents the major impact on LTE FDD each time a PRB is reserved in a typical
scenario. In this scenario, the inter-site distance (ISD) is 500 m, there are 10 64QAM UEs in
each cell, the network load is around 20%, the ratio of large packets to small packets is 1:4,
and uplink and downlink NB-IoT PRBs are positioned as recommended in 6.4.1 NB-IoT
PRB Planning.
Table 5-2 Decrease in the average user-perceived rate each time a PRB is reserved
Cell Bandwidth Decrease in the Average User-Perceived Rate
3 MHz 15% to 30%
5 MHz 10% to 25%
10 MHz 8% to 20%
15 MHz 5% to 15%
20 MHz 3% to 10%
There will be a larger impact (possibly larger than that provided in the table) in the following
situations: the ISD is smaller, fewer online UEs are in LTE FDD cells, higher-order
modulation schemes are used for UEs, network load is lower, small packets account for a
larger proportion, or NB-IoT PRBs are not positioned as recommended.
Each time an additional PRB is reserved, the impact will be accumulated and the
accumulation may eventually lead to additional impact.
There will be also impacts on the average user-perceived rate in the following situations:
l If the CellPdcchAlgo.PdcchSymNumSwitch parameter is set to ON or
ECFIADAPTIONON, the control format indicator (CFI) will increase if the average
number of scheduled UEs increases due to fragmented allocable resources. As a result,
the average downlink user-perceived rate will further decrease by no more than 15%,
depending on the increase in the average CFI.
l If allocable resources are fragmented, there will be a larger number of scheduling times
for each UE and a longer scheduling delay excluding the last TTI. If network load is not
heavy and the total traffic volume remains unchanged, there will be decreases in the
average uplink and downlink user-perceived rates. The decrease degrees are about one to
four times the proportion of PRBs reserved in the cell bandwidth (in units of PRBs).
There will be also the following impacts on LTE FDD:

eRAN
l The 3.75 kHz subcarrier used by the NPRACH causes interference to adjacent LTE FDD
PRBs, leading to an increase in the BLER of LTE FDD. The influence depends on the
uplink signal strength and ACLR of NB-IoT UEs.
l Downlink NB-IoT PRB resources need to be punctured for the LTE FDD PDCCH in
LTE in-band deployment. When time synchronization is not achieved, NB-IoT will cause
interference to the PDCCH and have impacts on performance indicators such as the
PDCCH BLER, CFI, and CCE aggregation level. Under heavy load, the theoretical
impact (a relative value, in the unit of dB) is equal to 10 x lg[1 + (4 x Number of
reserved PRBs / Total number of PRBs)], and the BLER may increase by 1% to 5%.
l Parameter settings for scheduling of LTE FDD common messages (such as system
information and RAR messages) in LTE in-band deployment mode have impacts on
downlink common resource overhead and resource allocation. A shorter scheduling
period for LTE FDD system information or PRACH leads to a greater downlink common
resource overhead and a lower peak rate. A smaller LTE FDD cell bandwidth results in a
greater impact on the downlink peak rate.
l The average number of scheduled UEs may increase after NB-IoT is deployed. As a
result, there will be an increase in CCE usage in the LTE FDD cell and fluctuations in
the interference level and the average uplink and downlink MCS indexes. The specific
influence is related to reserved PRB positions and scheduled UE locations. In addition,
different fluctuations in the BLER, throughput, and MCS index will have the
corresponding impacts on their associated non-KPI indicators.
l If NB-IoT has a higher downlink PSD than LTE FDD, there will be a change in power
allocation between LTE FDD and NB-IoT. For LTE FDD CCUs, the average throughput
and average MCS index may be lower and the RBLER may be higher than those before
NB-IoT configuration. There will be a larger impact on LTE FDD CCUs for which
higher order modulation schemes are used.
l NB-IoT will cause interference to neighboring LTE FDD PRBs if NB-IoT has a higher
uplink PSD than these PRBs and NB-IoT is heavily loaded. The specific influence
depends on the difference in PSD.
l When NB-IoT is deployed continuously and co-sited with LTE FDD in 1:1 networking
mode, the power of neighboring cells decreases and the interference also decreases. The
impact on SINR, channel quality indicator (CQI), proportion of rank 2 transmission, and
MCS is smaller than the impact on RSRP.
l NB-IoT increases common channel resource overhead and may have a higher PSD than
LTE FDD. These factors will affect RRU transmit power and may increase RRU power
consumption.
Function Impacts
l Functions related to cell planning
Name Switch
SFN cell Cell.MultiRru SFN (Impact on LTE FDD) NB-IoT

CellMode causes interference to the LTE
FDD SRS and therefore affects
RSRP measurement.

eRAN

Name Switch
Adaptive SFN/ CellAlgoSwitc SFN (Impact on LTE FDD) NB-IoT

SDMA h.SfnDlSchSw causes interference to the LTE
itch FDD SRS and therefore affects
RSRP measurement.
When TM9 or TM10 is used in
the adaptive SFN/SDMA
function, some resource
elements (REs) of NB-IoT PRBs
are used for transmitting the
channel state information-
reference signal (CSI-RS) of
LTE FDD. Consequently, the
downlink capacity of NB-IoT
decreases.
Adaptive SFN/ TM9Switch or SFN (Impact on NB-IoT) When TM9

SDMA with TM10Switch or TM10 is used, some REs of
TM10 option of the NB-IoT PRBs are used for
CellAlgoSwitc transmitting the LTE FDD CSI-
h.EnhMIMOS RS. Consequently, the downlink
witch capacity of NB-IoT decreases.
parameter
Scalable None Cell (Impact on LTE FDD) The LTE

bandwidth Management FDD cell bandwidth must be at
least 3 MHz in LTE in-band
deployment.
Compact Cell.Customiz Compact (Impact on NB-IoT) In LTE in-

bandwidth edBandWidth Bandwidth band mode, avoid NB-IoT
CfgInd (FDD) deployment on punctured PRBs
so as to prevent mutual
interference.
Flexible DdCellGroup. Flexible (Impact on NB-IoT) In LTE in-

bandwidth DdBandWidth Bandwidth band mode, avoid NB-IoT
based on based on deployment on overlapping RBs
overlapping Overlap that are formed by the "flexible
carriers Carriers bandwidth based on overlapping
(FDD) carriers" function so as to
prevent mutual interference.
(Impact on LTE FDD) In LTE
in-band mode, if NB-IoT is
deployed on overlapping RBs
that are formed by the "flexible
bandwidth based on overlapping
carriers" function, the physical
channel resource allocation of
LTE is affected.

eRAN
l Functions related to mobility and load management

Name Switch
Congestion DlLdcSwitch Admission and (Impact on NB-IoT) When flow

control and Congestion control is triggered because of
UlLdcSwitch Control CPU overload, access barring is
options of the triggered in NB-IoT.
CellAlgoSwitc
h.RacAlgoSwi
tch parameter
High speed Cell.HighSpee High Speed (Impact on LTE FDD) NB-IoT

mobility dFlag Mobility causes interference to the LTE
FDD SRS. A measurement of
Ultra high Cell.HighSpee High Speed timing advance (TA) in a
speed mobility dFlag Mobility subband where NB-IoT is
deployed may fail.
Consequently, a longer
measurement time may be
required for uplink
synchronization.
NPREO Cell-level Channel State In LTE in-band mode, the

constant switch Management accuracy of neighboring cell
optimization CellDlpcPdsc interference calculation is
hPa.CellNpre affected and the performance of
oAdjThreshol UE-level NPREO constant
d and UE-level optimization is affected. The
switch larger the ratio of the NB-IoT
CellDlpcPdsc PRBs to the PRBs in the
hPa.UeNpreo configured LTE bandwidth, the
AdjThreshold lower the gains of NPREO
constant optimization.
l Functions related to resource management

Name Switch
Uplink UlEnhancedF Scheduling (Impact on LTE FDD) NB-IoT

frequency ssSwitch causes interference to the LTE
selective option of the FDD SRS, and therefore NB-IoT
scheduling CellAlgoSwitc PRBs need to be excluded from
h.UlSchSwitc measurement for frequency
h parameter selective scheduling.
Downlink FreqSelSwitc Scheduling (Impact on LTE FDD) NB-IoT

frequency h option of the PRBs need to be excluded from
selective CellAlgoSwitc subband CQI measurement.
scheduling h.DlSchSwitc
h parameter

eRAN

Name Switch
CSPC CspcAlgoPar CSPC (Impact on LTE FDD) NB-IoT

a.CspcAlgoSw causes interference to the LTE
itch FDD SRS and therefore affects
RSRP measurement.
SRS resource SRSCfg.SrsCf Physical When an LTE FDD cell has SRS
management gInd Channel resources (that is, when the
Resource SRSCfg.SrsCfgInd parameter is
Management set to BOOLEAN_TRUE),
perform one of the following
operations: 1) You are advised to
deploy uplink NB-IoT PRBs
closer to band edges than LTE
FDD PUCCH resources to avoid
interference between NB-IoT
and LTE FDD SRS resources. 2)
Set the Prb.UlAllSymbolSend-
Flag parameter to FALSE to
avoid NB-IoT conflict with LTE
FDD SRS resources. Under this
setting, however, the uplink
capacity of NB-IoT may
decrease by 8% to 20%.
Dynamic PucchSwitch Physical When the PucchSwitch option

PUCCH option of the Channel of the
resource CellAlgoSwitc Resource CellAlgoSwitch.PucchAlgoSwit
adjustment h.PucchAlgoS Management ch parameter is selected, it is
witch recommended that an uplink
parameter PRB of NB-IoT be deployed in
the first or last uplink PRB
position available to LTE FDD.
l Functions related to interference mitigation

Name Switch
Downlink CellAlgoSwitc ICIC Downlink scheduling needs to

interference h.InterfRandS allocate consecutive PRBs to
randomization witch LTE UEs during access. If there
are fewer than two RBGs
between the start position of
PRBs specified in interference
randomization and the start
position of PRBs reserved for
NB-IoT, the RRC connection
setup success rate at cell edges
will be affected.

eRAN
l Functions related to multi-RAT coordination

Name Switch
UMTS and UMTS_LTE_ UMTS and To prevent inter-RAT

LTE Zero ZERO_BUFF LTE Zero interference in LTE in-band
Bufferzone ER_ZONE_S Bufferzone mode, deployment on the UMTS
W option of preferential spectrum should be
the avoided and deployment on the
ULZeroBuffe LTE-dedicated spectrum is
rzone.ZeroBu recommended.
fZoneSwitch
parameter
UMTS and DC_HSDPA_ UMTS and This function punctures PRBs

LTE Spectrum BASED_UL_ LTE Spectrum available to LTE, consequently
Sharing Based SPECTRUM_ Sharing Based reducing the range of PRBs
on DC- SHR option of on DC-HSDPA available for NB-IoT
HSDPA the deployment.
SpectrumClo
ud.SpectrumC
loudSwitch
parameter
l Functions related to RAN services

Name Switch
NB-IoT NB_OTDOA_ LCS After NB-IoT OTDOA-based

OTDOA-based SWITCH positioning is enabled, the
positioning option of the downlink rate of the NB-IoT cell
CellLcsCfg.C decreases because NPRS
ellLcsSwitch transmission occupies downlink
parameter resources.
When the NPRS configuration
scheduling reserves REs for
NPRS transmission, decreasing
the MCS index and slightly
increasing the downlink BLER
for UEs.
PUSCH RB UlVoipRbRsv VoLTE In LTE in-band deployment,

reservation for Switch option uplink PRBs reserved for NB-
voice service of the IoT cannot be the same as uplink
UEs CellAlgoSwitc PUSCH PRBs reserved for voice
h.UlSchExtSw service UEs. Otherwise, voice
itch parameter service is affected.
l Functions related to CIoT

eRAN

Name Switch
eMTC EMTC_SWIT eMTC (Impact on eMTC) If NB-IoT is

introduction CH option of deployed on a PRB of a
the narrowband available to eMTC,
CellEmtcAlgo this PRB will not be allocated to
.EmtcAlgoSwi eMTC, affecting the uplink and
tch parameter downlink capacity of eMTC.
In LTE in-band deployment,
eMTC does not work in certain
scenarios.(1)
Note for (1): In LTE in-band deployment, when the CellRbReserve.RbRsvMode

parameter is set to NB_DEPLOYMENT, eMTC does not work in the following
scenarios:
– The cell bandwidth is 5 MHz, and the indexes of downlink PRB deployment
positions are in the range of 2 and 22.
positions are in the range of 4, 9, 14, 35, 40, and 45.
positions are in the range of 2, 7, 12, 17, 22, 27, 47, 52, 57, 62, 67, and 72.
positions are in the range of 4, 9, 14, 19, 24, 29, 34, 39, 60, 65, 70, 75, 80, 85, 90,
and 95.
l Functions related to network infrastructure

Name Switch
Basic symbol SymbolShutd Energy (Impact on LTE FDD) If NB-IoT

power saving ownSwitch Conservation and LTE FDD cells share the
option of the and Emission same PA, the symbol power
ENodeBAlgoS Reduction saving effect will be reduced in
witch.PowerS the LTE FDD cell. This is
aveSwitch because:
parameter l The pilot symbols of the NB-
IoT cell and those of the LTE
symbols in the time domain
for NPSS, NSSS, MIB-NB,
and SIB-NB transmission
than the LTE FDD cell.

eRAN

Name Switch
CPRI Cell.CPRICo CPRI (Impact on LTE FDD) If the

compression mpression Compression LBBPd1, LBBPd2, or LBBPd3
is used and the BBP.WM
parameter is set to
FDD_NBIOT,
board. Otherwise, these LTE
FDD cells cannot be activated.
l Functions related to other services

Name Switch
Uplink CellUlschAlgo None (Impact on LTE FDD) LTE in-

frequency .UlHoppingTy band deployment requires that
hopping pe uplink frequency hopping should
be disabled in the LTE FDD cell
and the resources for NB-IoT
deployment should not be
allocated to the LTE FDD cell.
For example, if LTE FDD
requires the allocation of
consecutive PRBs, the
scheduling algorithm needs to
consider the previous
constraints.

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 6 Requirements
6 Requirements
6.1 Licenses
NB-IoT-related hardware and capacity licenses are required for NB-IoT cell setup. For details,
see License Control Item Lists (CIoT).
6.2 Software
Prerequisite Functions
None
Mutually Exclusive Functions

l Functions related to RAN performance
Name Switch
Extended CP Cell.ULCyclicP Extended CP In LTE in-band deployment mode,

refix and the NB-IoT cell does not support
Cell.DlCyclicPr extended CP and therefore the
efix LTE FDD cell cannot be
configured with extended CP.
Cell radius None Extended Cell In LTE in-band deployment mode,

greater than 100 Range NB-IoT and LTE FDD cells need
km to share the same antenna system,
which cannot support both
extended and normal cell ranges.
As the maximum radius of an NB-
IoT cell is 35 km, the radius of the
corresponding LTE FDD cell
cannot exceed 100 km.

eRAN

Name Switch
Super combined SuperCombCe Super In LTE in-band deployment mode,

cell llSwitch option Combined Cell NB-IoT does not support high
of the (FDD) speed mobility currently, whereas
CellAlgoSwitc the super combined cell function is
h.SfnAlgoSwitc mainly used in high speed mobility
h parameter scenarios.
l Functions related to RAN services

Name Switch
eMBMS CellMBMSCfg eMBMS NB-IoT deployment in eMBMS

.MBMSSwitch MBSFN subframes cannot be
completely avoided in LTE in-
band mode and therefore eMBMS-
related functions cannot work in
this mode.
eMBMS service CellMBMSCfg eMBMS NB-IoT deployment in eMBMS

continuity .MBMSService MBSFN subframes cannot be
Switch completely avoided in LTE in-
band mode and therefore eMBMS-
related functions cannot work in
this mode.
l Functions related to CloudAIR

Name Switch
LTE FDD and LTE_NR_UPL LTE and NR None

NR uplink INK_SPECTR Spectrum
spectrum UM_SHR Sharing
sharing option of the
SpectrumClou
d.SpectrumClo
udSwitch
parameter

eRAN

Name Switch
GSM and LTE SpectrumClou GSM and LTE In LTE guard band deployment
Spectrum d.SpectrumClo Spectrum mode, when the GSM and LTE
Concurrency udSwitch Concurrency Spectrum Concurrency function is
(LTE FDD) used, the interference between
NB-IoT and LTE FDD is lower
than that between GSM and LTE.
When GSM, LTE FDD, and NB-
IoT all need to be deployed, the
best overall performance can be
achieved if GSM is deployed in
the LTE guard band. Therefore,
NB-IoT cannot be deployed in the
LTE guard band.
l Functions related to network infrastructure

Name Switch
Dynamic CellAlgoSwitc Energy None

voltage h.DynAdjVoltS Conservation
adjustment witch and Emission
Reduction
RF channel CellRfShutdo Energy LTE in-band deployment is not

intelligent wn.RfShutdow Conservation compatible with energy
shutdown nSwitch and Emission conservation functions because the
Reduction NB-IoT cell is unavailable when
the LTE FDD cell becomes
Intelligent InterRatCellS Energy unavailable in this deployment
power-off of hutdown.Force Conservation mode.
carriers in the ShutdownSwitc and Emission
same coverage h Reduction
as UMTS
networks
Intelligent CellShutdown. Energy

power-off of CellShutdownS Conservation
carriers in the witch and Emission
same coverage Reduction
Low power CellLowPower Energy

consumption .LowPwrSwitch Conservation
mode and Emission
Reduction

eRAN

Name Switch
Multi-RAT InterRatCellS Multi-RAT

Carrier Joint hutdown.Force Carrier Joint
Intelligent ShutdownSwitc Shutdown
Shutdown(eNo h
deB)
Enhanced MBSFNShutD Energy The enhanced symbol power

symbol power ownSwitch Conservation saving function is based on
saving option of the and Emission MBSFN subframes but NB-IoT
CellAlgoSwitc Reduction deployment in MBSFN subframes
h.DlSchSwitch cannot be completely avoided in
parameter LTE in-band deployment mode.
6.3 Hardware
Base Station Models
The compatible base stations are as follows:
l 3900 and 5900 series base stations
l DBS3900 LampSite and DBS5900 LampSite (Exception scenario: NB-IoT is deployed
in LTE in-band mode and the LTE FDD cell bandwidth is 3 MHz.)
l BTS3911E (Exception scenario: NB-IoT is deployed in LTE in-band mode and the LTE
FDD cell bandwidth is 3 MHz.)
l BTS3912E (Exception scenario: NB-IoT is deployed in LTE in-band mode and the LTE
FDD cell bandwidth is 3 MHz.)
Boards
The requirements for boards are as follows:
l Main control boards must be LMPT or UMPT.
l BBPs must be LBBPd1/LBBPd2/LBBPd3/LBBPd5, UBBPd3/UBBPd4/UBBPd5/
UBBPd6, or UBBPe1/UBBPe2/UBBPe3/UBBPe4.
l LBBPd boards are not compatible with uplink AMC optimization.
In LTE in-band deployment mode, there are also the following requirements:
l NB-IoT and LTE FDD must share the same main control board, RF module, and antenna
system.
l When the LTE FDD cell bandwidth is 3 MHz, neither the NB-IoT cell nor the
corresponding LTE FDD cell can be deployed on the LBBPd.
l When the LTE FDD cell becomes faulty, the NB-IoT cell also becomes unavailable.
However, when the NB-IoT cell becomes faulty, the LTE FDD cell can still work.

eRAN
RF Modules
For the models of RF modules that support NB-IoT, see technical descriptions in base station
product documentation.
Only RRU3652/RRU3653/RRU3662 can be used when NB-IoT is deployed in LTE in-band
mode and the LTE FDD cell bandwidth is 3 MHz.
6.4 Networking
When deploying an NB-IoT network, consider factors such as coverage objectives, frequency
bands, guard band requirements, and spectrum resources on the live network. This section
describes PRB deployment, power planning, and site planning from the perspective of a
single eNodeB.
6.4.1 NB-IoT PRB Planning

PRB Deployment Modes
An NB-IoT carrier requires only 180 kHz bandwidth. It can be deployed in standalone, LTE
guard band, or LTE in-band mode based on idle spectrum resources on the live network.
l Standalone deployment
– Figure 6-1 illustrates the requirements for NB-IoT deployment on GSM spectrum.
Figure 6-1 Deployment on GSM spectrum
NOTE
If a GSM frequency adjacent to the NB-IoT frequency is a BCCH frequency, a guard band of
300 kHz is required.
– Figure 6-2 illustrates the requirements for NB-IoT deployment on UMTS spectrum.
Figure 6-2 Deployment on UMTS spectrum
– Figure 6-3 illustrates the requirements for NB-IoT deployment on LTE spectrum.

eRAN
Figure 6-3 Deployment on LTE spectrum
If two NB-IoT carriers are both deployed in standalone mode, the 15 kHz subcarriers
between the two carriers are not orthogonal. A guard band (for example, 100 kHz) needs
to be reserved to make the carriers orthogonal and reduce inter-carrier interference.
l LTE guard band deployment
The LTE FDD cell bandwidth must be at least 10 MHz so that the guard bandwidth is
enough for NB-IoT. Figure 6-4 uses a 10 MHz bandwidth as an example.
Figure 6-4 LTE guard band deployment (LTE FDD 10 MHz bandwidth)
NOTE
l For details about the LTE spectrum template mentioned in the figure, see section 6.6
"Unwanted emissions" in 3GPP TS 36.104 R13.
l The minimum LTE FDD cell bandwidth required for LTE guard band deployment is 5 MHz
according to 3GPP TS 36.802 R13. However, deployment in this bandwidth will cause
interference to surrounding systems. In the current version, the corresponding LTE FDD cell
bandwidth needs to be greater than or equal to 10 MHz.
l LTE in-band deployment
Figure 6-5 illustrates the requirements for LTE in-band deployment.

eRAN
Figure 6-5 LTE in-band deployment
PRB Deployment Positions

PRB deployment positions need to be considered only in LTE in-band mode among the three
NB-IoT deployment modes.
LTE in-band deployment requires that the LTE FDD cell be established prior to the NB-IoT
cell and NB-IoT be deployed on uplink and downlink PRBs reserved in the LTE FDD cell.
NB-IoT positions must meet the requirements specified in 3GPP TS 36.101 R13.
Table 6-1 lists the downlink PRB positions available and recommended for the anchor carrier
of NB-IoT.
Table 6-1 Downlink PRB positions for the anchor carrier of NB-IoT in LTE in-band
deployment mode
LTE FDD Cell Available PRB Positions for Recommended PRB
Bandwidth NB-IoT Positions for NB-IoT
3 MHz 2, 12 2, 12
5 MHz 2, 7, 17, 22 7, 17
10 MHz 4, 9, 14, 19, 30, 35, 40, 45 19, 30
15 MHz 2, 7, 12, 17, 22, 27, 32, 42, 47, 52, 32, 42
57, 62, 67, 72
20 MHz 4, 9, 14, 19, 24, 29, 34, 39, 44, 55, 44, 55
60, 65, 70, 75, 80, 85, 90, 95
When the CellRbReserve.RbRsvMode parameter is set to NB_DEPLOYMENT in LTE in-

band deployment, eMTC does not work in the following scenarios:
l The cell bandwidth is 5 MHz, and the indexes of downlink PRB deployment positions
are in the range of 2 and 22.
are in the range of 4, 9, 14, 35, 40, and 45.

eRAN
are in the range of 2, 7, 12, 17, 22, 27, 47, 52, 57, 62, 67, and 72.
are in the range of 4, 9, 14, 19, 24, 29, 34, 39, 60, 65, 70, 75, 80, 85, 90, and 95.
The uplink PRB position requirements for the anchor carrier are as follows:
l Uplink PRB positions recommended for NB-IoT are at band edges excluding the
positions for the LTE FDD PRACH and statically configured PUCCH. After NB-IoT
PRBs are deployed, there should be at least four consecutive PRBs available to the LTE
FDD PUSCH. Otherwise, both LTE FDD and NB-IoT cells may be affected.
l When the GSM and LTE Spectrum Concurrency function is used, anchor and non-anchor
carriers need to be deployed on LTE-dedicated PRBs. To avoid interference between
GSM and NB-IoT, a sufficient guard band needs to be reserved between them.
In LTE in-band deployment mode, NB-IoT PRB positions need to be reserved on the
BTS3203E if it is deployed in intra-frequency networking mode. This is because the
BTS3203E does not support NB-IoT and the reservation can avoid the interference between
LTE FDD and NB-IoT cells caused by the near-far effect.
In the downlink, NB-IoT subcarriers are orthogonal to LTE FDD subcarriers. Therefore, no
extra guard band needs to be reserved for the downlink. In the uplink, NB-IoT NPRACH
subcarriers are not orthogonal to LTE FDD subcarriers because an NPRACH can use only a
3.75 kHz subcarrier for single-tone transmission. PRBs adjacent to NB-IoT PRBs can be used
as guard bands for interference mitigation. In practice, however, PRBs are not reserved for
this purpose because the impact of interference is not greater than the impact of reservation of
one or two PRBs.
PRB Center Frequency Setting

The center frequency of a PRB is determined by the EARFCN and frequency offset. The
following describes how to determine the EARFCN and frequency offset.
l LTE in-band deployment
– Determine the downlink EARFCN and frequency offset.
i. Determine the downlink frequency offset. The specific offset is related to the
LTE FDD cell bandwidth and PRB position, as defined in 3GPP TS 36.101
R13 and described in the following table.
LTE FDD Cell PRB Position Downlink

Bandwidth Frequency Offset
3 MHz 2 -2
12 1
5 MHz 2, 7 -2
17, 22 1
10 MHz 4, 9, 14, 19 0
30, 35, 40, 45 -1
15 MHz 2, 7, 12, 17, 22, 27, 32 -2

eRAN
LTE FDD Cell PRB Position Downlink

Bandwidth Frequency Offset
42, 47, 52, 57, 62, 67, 72 1
20 MHz 4, 9, 14, 19, 24, 29, 34, 39, 0

44
55, 60, 65, 70, 75, 80, 85, -1

90, 95
ii. Calculate the downlink EARFCN.

○ For DlRBRsvIndex < NRB/2, NbDlEarfcn = LteDlEarfcn + (180 x
DlRBRsvIndex – 90 x NRB + 90 – 2.5 x (2 x NbDlFreqOffset + 1) –
7.5)/100
○ For DlRBRsvIndex ≥ NRB/2, NbDlEarfcn = LteDlEarfcn + (180 x
DlRBRsvIndex – 90 x NRB + 90 – 2.5 x (2 x NbDlFreqOffset + 1)
+ 7.5)/100
where
○ NRB: number of PRBs of the LTE FDD cell
○ DlRBRsvIndex: index of the downlink PRB reserved for deploying NB-
IoT
○ LteDlEarfcn: downlink EARFCN of the LTE FDD cell
○ NbDlEarfcn: downlink EARFCN of the NB-IoT PRB
○ NbDlFreqOffset: downlink frequency offset of the NB-IoT PRB
– Determine the uplink EARFCN and frequency offset.
i. Calculate the uplink EARFCN using the following formula and round down
the calculated value to the nearest integer.
NbUlEarfcn = LteUlEarfcn + (180 x UlRBRsvIndex – 90 x NRB + 90
+ 50)/100
ii. Calculate the uplink frequency offset based on the uplink EARFCN.
NbUlFreqOffset = 20 x LteUlEarfcn + 36 x UlRBRsvIndex – 18 x NRB + 18
– 20 x NbUlEarfcn
where
n NRB: number of PRBs of the LTE FDD cell
n UlRBRsvIndex: index of the uplink PRB reserved for deploying NB-IoT
n LteUlEarfcn: uplink EARFCN of the LTE FDD cell
n NbUlEarfcn: uplink EARFCN of the NB-IoT PRB
n NbUlFreqOffset: uplink frequency offset of the NB-IoT PRB
NOTE
When the Prb.UlEarfcnCfgInd parameter is set to NOT_CFG, the UlRBRsvIndex value must be
consistent with the DlRBRsvIndex value. In addition, the uplink EARFCN and uplink frequency
offset are automatically calculated using the preceding formulas.
l For LTE guard band deployment, the NB-IoT PRB EARFCN offset (relative to the LTE
FDD cell center EARFCN), downlink NB-IoT PRB frequency offset, and uplink NB-IoT
PRB frequency offset are listed in the following table.

eRAN
– When the LTE FDD cell bandwidth is 10 MHz:

LTE Guard NB-IoT Downli Uplink Description
FDD Band PRB nk NB- NB-IoT
Cell Between EARFC IoT PRB PRB
Bandwi NB-IoT N Offset Frequen Frequen
dth and LTE (Relativ cy cy
(kHz) e to the Offset Offset
LTE
FDD
Cell
Center
EARFC
N)
10 MHz 300 -49 0 2 Not

recommended
because of high
external
interference
210 -48 -2 0 Recommended
0 -46 0 2 Not
recommended
because of high
interference
between NB-IoT
and LTE
0 46 -1 -2 Not
recommended
because of high
interference
between NB-IoT
and LTE
105 47 0 -1 Recommended
210 48 1 0 Recommended
300 49 -1 -2 Not
recommended
because of high
external
interference

eRAN

LTE
FDD
Cell
Center
EARFC
N)
15 MHz 555 -74 -1 1 Not

recommended
because of high
external
interference
450 -73 0 2 Recommended
45 -69 1 3 Not
recommended
because of high
interference
between NB-IoT
and LTE
45 69 -2 -3 Not
recommended
because of high
interference
between NB-IoT
and LTE
150 70 -1 -2 Recommended
555 74 0 -1 Not
recommended
because of high
external
interference

eRAN

LTE
FDD
Cell
Center
EARFC
N)
20 MHz 810 -99 -2 0 Not

recommended
because of high
external
interference
0 -91 0 2 Not
recommended
because of high
interference
between NB-IoT
and LTE
0 91 -1 -2 Not
recommended
because of high
interference
between NB-IoT
and LTE

eRAN

LTE
FDD
Cell
Center
EARFC
N)
810 99 1 0 Not
recommended
because of high
external
interference
For LTE FDD cell center EARFCNs, see "Table 5.7.3-1: E-UTRA channel numbers" in
3GPP TS 36.104 V14.5.0.
NOTE
In LTE guard band deployment, the uplink and downlink EARFCNs and frequency offsets for NB-
IoT must be deployed in accordance with local laws and regulations. For the specific planning,
contact Huawei engineers.
When the Prb.UlEarfcnCfgInd parameter is set to NOT_CFG, the system obtains the downlink
NB-IoT PRB EARFCN offset relative to the downlink center EARFCN of the LTE FDD cell
based on the configured downlink NB-IoT PRB EARFCN. Then, the system obtains the uplink
NB-IoT PRB EARFCN based on the offset relative to the center EARFCN and the uplink center
EARFCN of the LTE FDD cell. In addition, the system obtains the uplink NB-IoT PRB frequency
offset corresponding to the offset relative to the center EARFCN based on the preceding table that
lists the EARFCN offset relative to the center EARFCN and the frequency offsets.
For example, assume that the cell bandwidth is 10 MHz, the guard bandwidth is 105 kHz, the
downlink center EARFCN of the LTE FDD cell is 6400, the downlink NB-IoT PRB EARFCN is
6353, and the downlink frequency offset is -1. The system obtains the following according to the
preceding method:
1. The offset relative to the center EARFCN is -47 = 6353 - 6400.
2. The uplink EARFCN of the LTE FDD cell is 24400 = 6400 + 18000. (This can be obtained by
querying the EARFCN relationship of band 20 in "Table 5.7.3-1: E-UTRA channel numbers.")
3. The uplink NB-IoT PRB EARFCN is 24353 = 24400 - 47.
4. The uplink NB-IoT PRB frequency offset is 1. (This can be obtained from the preceding table
that lists the EARFCN offset relative to the center EARFCN and the frequency offsets.)
l For standalone deployment, set the EARFCNs based on the network plan; set the
downlink and uplink frequency offsets to -0.5 and 0, respectively.

eRAN
6.4.2 NB-IoT Power Planning

In LTE in-band deployment mode, an NB-IoT cell and the corresponding LTE FDD cell share
the same RF channel power. The following requirements must be met:
l The total power of NB-IoT and LTE FDD cells cannot exceed the upper limit of the RF
channel power. For details about the power specifications of RF modules, see technical
descriptions in base station product documentation.
l The PSD of the NB-IoT cell minus the average PSD of LTE FDD and NB-IoT cells
cannot exceed 6 dB. However, the difference in PSD can be up to 9 dB if the RF module
in use is the RRU3268 (800 MHz) or the RRU3936/RRU3959 (900 MHz).
If NB-IoT shares RF modules with another RAT, the current power of RF modules must be
considered in NB-IoT RF planning.
l If RF modules have remaining power, NB-IoT can be directly deployed.
l If part of the GSM spectrum can be refarmed, NB-IoT can be directly deployed.
l If RF modules already work at full power, a small amount of the power needs to be taken
away for NB-IoT. This power back-off has only a small impact on the coverage of the
other RAT.
6.4.3 NB-IoT Site Planning

The constraints on NB-IoT site planning are as follows:
l NB-IoT and LTE FDD do not support separate-MPT. In addition, NB-IoT and LTE FDD
must share the same RF module and antenna system in LTE in-band deployment.
l NB-IoT requirements for CPRI 1T1R I/Q data bandwidth are listed in the following
table.
Deployment Mode 1T1R I/Q Data Bandwidth
Standalone 115.2 Mbit/s
LTE guard band 115.2 Mbit/s
LTE in-band 92.16 Mbit/s
6.5 Others
Other requirements are as follows:
l MMEs must support NB-IoT functions defined in 3GPP R13, including control plane or
user plane CIoT EPS optimization.
l UEs must support NB-IoT functions stipulated in 3GPP R13.
l NB-IoT UEs in the existing network must support the incompatibility changes made by
3GPP. For details, see 3.4 NB-IoT UE Requirements.
l The RETRIEVE_UE_INFO_SWITCH option of the
CellAlgoSwitch.NbCellAlgoSwitch parameter can be selected only when MMEs support
the Retrieve UE Information message newly defined in 3GPP R14. If the MMEs do not
support the message, S1 interface message responding will time out and access
performance will deteriorate.

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 7 Operation and Maintenance
7 Operation and Maintenance
7.1 Data Configuration
7.1.1 Data Preparation

Before configuring an NB-IoT cell, configure hardware, including the main control board,
BBPs, and RF modules. For details about how to configure device data for an eNodeB, see
the initial configuration guide in base station product documentation.
Then, configure transport data. For detailed operations, see the initial configuration guide in
base station product documentation. The S1.MmeRelease and S1Interface.MmeRelease
parameters must be set to Release_R13 or a later release.
7.1.1.1 Data Preparation for Activation

Set sector parameters.
Parameter Name Parameter ID Setting Notes
Sector ID SECTOR.SECTORID Ensure that each sector ID is

unique.
Sector Name SECTOR.SECNAME -
Location Name SECTOR.LOCATIONNA -

ME
User Label SECTOR.USERLABEL -
Antenna Number SECTOR.ANTNUM -
Cabinet No. of Antenna 1 SECTOR.ANT1CN -
Subrack No. of Antenna 1 SECTOR.ANT1SRN -
Slot No. of Antenna 1 SECTOR.ANT1SN -
Channel No. of Antenna 1 SECTOR.ANT1N -

eRAN
Cabinet No. of Antenna 2 SECTOR.ANT2CN -
Subrack No. of Antenna 2 SECTOR.ANT2SRN -
Slot No. of Antenna 2 SECTOR.ANT2SN -
Channel No. of Antenna 2 SECTOR.ANT2N -
Create Default Sector SECTOR.CREATESECTO -

Equipment REQM
Default Sector Equipment SECTOR.SECTOREQMI -

ID D
Set sector equipment parameters.
Sector Equipment ID SECTOREQM.sectorEqmI -

d
Sector ID SECTOREQM.sectorId -
Antenna Number SECTOREQM.ANTNUM -
Cabinet No. of Antenna 1 SECTOREQM.ANT1CN -
Subrack No. of Antenna 1 SECTOREQM.ANT1SRN -
Slot No. of Antenna 1 SECTOREQM.ANT1SN -
Channel No. of Antenna 1 SECTOREQM.ANT1N -
Antenna 1 RX/TX Mode SECTOREQM.ANTTYPE -

1
TX Antenna 1 Master/Slave SECTOREQM.TXBKPMO Set this parameter to

Mode DE1 MASTER.
Do not set this parameter to
SLAVE because the
eNodeB does not support
antennas working in master/
slave mode.
Cabinet No. of Antenna 2 SECTOREQM.ANT2CN -
Subrack No. of Antenna 2 SECTOREQM.ANT2SRN -
Slot No. of Antenna 2 SECTOREQM.ANT2SN -
Channel No. of Antenna 2 SECTOREQM.ANT2N -
Antenna 2 RX/TX Mode SECTOREQM.ANTTYPE -

2

eRAN
TX Antenna 2 Master/Slave SECTOREQM.TXBKPMO Set this parameter to

Mode DE2 MASTER.
Do not set this parameter to
SLAVE because the
eNodeB does not support
antennas working in master/
slave mode.
Set baseband equipment parameters.
Baseband Equipment ID BASEBANDEQM.BASEB Each baseband equipment

ANDEQMID ID indicates a piece of
baseband equipment.
Baseband Equipment Type BASEBANDEQM.BASEB -

ANDEQMTYPE
Set operator parameters.
CN Operator ID CnOperator.CnOperatorId -
CN Operator name CnOperator.CnOperatorN -

ame
CN Operator type CnOperator.CnOperatorTy -

pe
Mobile country code CnOperator.Mcc -
Mobile network code CnOperator.Mnc -
Set tracking area parameters.
Local tracking area ID CnOperatorTa.TrackingAr -

eaId
CN Operator ID CnOperatorTa.CnOperator -
Id
Tracking area code CnOperatorTa.Tac -

eRAN
NB-IoT TA Flag CnOperatorTa.NbIotTaFla Do not set the NB-IoT TAI

g to the same value as an
FDD/TDD TAI because NB-
IoT does not support inter-
RAT mobility according to
3GPP specifications. For
details, see section 5.3.3
"Tracking Area Update
procedures" in 3GPP TS
23.401 V13.7.0.
Set MME capability information for NB-IoT.
MME Capability MmeCapInfo.MmeCapCfg -

Configuration ID Id
S1 Configuration Type MmeCapInfo.S1CfgType -
S1 ID MmeCapInfo.S1Id -
S1 Interface ID MmeCapInfo.S1InterfaceI -
d
NB-IoT CIoT EPS MmeCapInfo.NbCiotEpsO Set this parameter based on

Optimization Capability ptCap the MME capability.(1)
MME Support LTE MmeCapInfo.NbLteSuppo Set this parameter based on

Capability rtCap the actual MME capability.
In RAN sharing scenarios, if
this parameter is set to
SUPPORT, then there must
be at least one tracking area
code (TAC) whose
CnOperatorTa.NbIotTaFla
g parameter is set to
BOOLEAN_FALSE for the
corresponding operator.
Note for (1): Set the parameter based on the MME capability.
l If the MME does not support control plane CIoT EPS optimization, set this parameter to
NOT_SUPPORT. The eNodeB will not transfer NB-IoT services to the MME.
l If the MME supports control plane CIoT EPS optimization, set this parameter to CP.
Before setting this parameter to CP, ensure that at least one NB-IoT TAI is configured
over the S1 interface of the MME.

eRAN
l If the MME supports both control plane and user plane CIoT EPS optimization, set this
parameter to CP_UP. Before setting this parameter to CP_UP, ensure that at least one
NB-IoT TAI is configured over the S1 interface of the MME.
Set parameters related to RLC and PDCP in user plane CIoT EPS optimization mode.
RLC PDCP parameter group RlcPdcpParaGroup.RlcPd -

ID cpParaGroupId
Category Type RlcPdcpParaGroup.CatTy Set this parameter to

pe NBIOT.
NB-IoT PDCP Discard RlcPdcpParaGroup.NbPdc Set this parameter to its

Timer pDiscardTimer default value.
NB-IoT Downlink PDCP RlcPdcpParaGroup.NbDlP Set this parameter to its

Discard Timer dcpDiscardTimer default value.
RLC-UM or RLC-AM RlcPdcpParaGroup.RlcMo Set this parameter to

mode de RlcMode_AM.
Max Retransmission Thld RlcPdcpParaGroup.NbUe Set this parameter to its

for NB-IoT UE MaxRetxThreshold default value.
Max Retransmission Thld RlcPdcpParaGroup.NbEn Set this parameter to its

for NB-IoT eNodeB odebMaxRetxThreshold default value.
NB-IoT Poll Retransmit RlcPdcpParaGroup.NbUe Set this parameter to its

Timer for UE PollRetxTimer default value.
NB-IoT Poll Retransmit RlcPdcpParaGroup.NbEn Set this parameter to its

Timer for eNodeB odebPollRetxTimer default value.
Discardtimer Separate RlcPdcpParaGroup.UlDlD The value OFF is

Config Switch iscardtimerSwitch recommended.
Set QCI-related parameters in user plane CIoT EPS optimization mode.
QoS Class Identifier QciPara.Qci Set this parameter in the

range of QCI 5 to QCI 9,
which indicate the non-GBR
services that NB-IoT
supports.
NB-IoT RLC PDCP Para QciPara.NbRlcPdcpParaG -

Group ID roupId
NB-IoT Coverage Level 0 QciPara.NbCe0RlcPdcpPa -

RLC PDCP Para Group ID raGroupId

eRAN
NB-IoT Coverage Level 1 QciPara.NbCe1RlcPdcpPa -

RLC PDCP Para Group ID raGroupId
Set cell parameters.
Local Cell ID Cell.LocalCellId -
Cell Name Cell.CellName -
NB-IoT Cell Flag Cell.NbCellFlag Set this parameter to TRUE

for an NB-IoT cell.
Coverage Level Type Cell.CoverageLevelType -
Uplink cyclic prefix length Cell.UlCyclicPrefix Set this parameter to

NORMAL_CP.
Downlink cyclic prefix Cell.DlCyclicPrefix Set this parameter to

length NORMAL_CP.
Cell ID Cell.CellId -
Physical cell ID Cell.PhyCellId Set this parameter to the

same value as that of the
corresponding LTE FDD
cell in LTE in-band
deployment.
Cell FDD TDD indication Cell.FddTddInd Set this parameter to

CELL_FDD.
Flag of Multi-RRU Cell Cell.MultiRruCellFlag Set this parameter to

BOOLEAN_TRUE for
DBS3900 LampSite and
DBS5900 LampSite. Set this
parameter to its
recommended value for
other models.
Mode of Multi-RRU Cell Cell.MultiRruCellMode Set this parameter only

when the
Cell.MultiRruCellFlag
parameter is set to
BOOLEAN_TRUE. Set it
to
MPRU_AGGREGATION
for DBS3900 LampSite and
DBS5900 LampSite. Set it
to SFN for other models.

eRAN
CRS Port Number Cell.CrsPortNum Set this parameter based on

the number of downlink
channels. For example, set
this parameter to
CRS_PORT_2 in 2T mode
and to CRS_PORT_1 in
1T1R mode.(1)
Cell transmission and Cell.TxRxMode Set this parameter based on

reception mode the number of antennas in
the sector where the cell is
located.
Work mode Cell.WorkMode Set this parameter to its

recommended value.
Note for (1): Do not set this parameter to CRS_PORT_1 for a 2T2R, 2T4R, or 4T4R NB-IoT
cell. For LTE in-band deployment, if the LTE FDD cell parameters Cell.CrsPortNum and
Cell.TxRxMode are set to CRS_PORT_4 and 4T4R, respectively, then the NB-IoT cell
parameters Cell.CrsPortNum and Cell.TxRxMode must be set to CRS_PORT_2 and 4T4R,
respectively. If the LTE FDD cell parameters Cell.CrsPortNum and Cell.TxRxMode are set
to other values, then the NB-IoT cell parameters Cell.CrsPortNum and Cell.TxRxMode must
be set to the same values as the LTE FDD cell parameters.
In LTE in-band deployment, configure PRBs reserved in the LTE FDD cell for NB-IoT
deployment. This configuration will cause reestablishment of the LTE FDD cell, and
consequently ongoing services in the cell will be interrupted.
Local Cell ID CellRbReserve.LocalCellId -
Index CellRbReserve.Index The value of each index

must be unique.
RB Reserve Type CellRbReserve.RbRsvType -
RB Reserve Start Index CellRbReserve.RbRsvStart Set this parameter based on

Index the
CellRbReserve.RbRsvType
parameter setting.(1) If the
PRB.UlEarfcnCfgInd
parameter is set to
NOT_CFG, the start
indexes must be the same
for uplink and downlink
PRBs reserved in the LTE
FDD cell for NB-IoT
deployment.

eRAN
RB Reserve End Index CellRbReserve.RbRsvEndI Set this parameter based on

ndex PRB reservation.
RB Reserve Mode CellRbReserve.RbRsvMod l If the PRBs are used for

e NB-IoT deployment, set
this parameter to
NB_DEPLOYMENT.
l If the PRBs are not used
for NB-IoT deployment
but used for uplink guard
bands or punctured for
downlink buffer zones,
set this parameter to
NB_RESERVED.
Note for (1): Set the parameter based on the CellRbReserve.RbRsvType parameter setting.
l If the CellRbReserve.RbRsvType parameter is set to DOWNLINK_MODE, the

reserved PRB positions must meet the requirements in 6.4.1 NB-IoT PRB Planning.
l If the CellRbReserve.RbRsvType parameter is set to UPLINK_MODE, the following
requirements must be met:
– Avoid using LTE FDD PRACH PRBs and statically configured PUCCH PRBs. It is
recommended that edge PRBs be reserved to reduce the impact on the uplink
single-UE peak rate of LTE FDD.
– Avoid using PUSCH PRBs reserved for voice users. This reservation function is
controlled by the UlVoipRbRsvSwitch option of the
CellAlgoSwitch.UlSchExtSwitch parameter. The start position of reserved PRBs is
specified by the CellUlschAlgo.UlVoipRsvRbStart parameter. The number of
reserved PRBs is specified by the CellUlschAlgo.UlVoipRsvRbNum parameter.
Set PRB parameters for the anchor carrier.
Local Cell ID Prb.LocalCellId -
PRB ID Prb.PrbId -
Anchor Carrier Flag Prb.AnchorCarrierFlag Set this parameter to TRUE

for the anchor carrier. Set
this parameter to FALSE for
a non-anchor carrier.
PRB Block Priority Prb.PrbBlockPriority Set this parameter to

UNBLOCKED for the
anchor carrier.
Deployment Mode Prb.DeployMode Set this parameter as

required.

eRAN
LTE Bandwidth Prb.LteBandWidth Set this parameter only in

LTE guard band deployment
mode. Set this parameter to
the bandwidth of the
cell.
LTE Downlink EARFCN Prb.LteDlEarfcn Set this parameter only in

LTE guard band deployment
the downlink EARFCN of
the corresponding LTE FDD
cell.
LTE Cell ID Prb.LteCellId Set this parameter only in

LTE in-band deployment
the cell ID of the
cell.
Frequency Band Prb.FreqBand -
Downlink EARFCN Prb.DlEarfcn Set this parameter to a

downlink EARFCN in the
specified frequency band.
In LTE guard band
deployment mode, the
parameter value must be in a
guard band of the LTE FDD
cell.
In LTE in-band deployment
mode, the parameter value
must be calculated based on
information about LTE FDD
PRBs reserved for NB-IoT
deployment.
Downlink Frequency Offset Prb.DlFreqOffset In standalone deployment

mode, set this parameter to
NEG_0DOT5.
In LTE guard band
deployment mode, set this
parameter to NEG_2,
NEG_1, POS_0, or POS_1.
mode, there are two cases.(1)

eRAN
Uplink EARFCN Prb.UlEarfcnCfgInd In standalone and LTE guard

Configuration Indicator band deployment modes, the
value NOT_CFG is
recommended.
mode, the value CFG is
recommended.
Uplink EARFCN Prb.UlEarfcn Set this parameter only

when the Uplink EARFCN
Configuration Indicator
parameter is set to CFG. Set
it to an uplink EARFCN in
the specified frequency
band.
mode, the parameter value
must be calculated based on
information about LTE FDD
PRBs reserved for NB-IoT
deployment.
Uplink Frequency Offset Prb.UlFreqOffset Set this parameter only

when the Uplink EARFCN
Configuration Indicator
parameter is set to CFG.
In standalone deployment
mode, set this parameter to
POS_0.
mode, set this parameter
based on the NB-IoT PRB
position.
Uplink All Symbol Send Prb.UlAllSymbolSendFlag In standalone deployment

Flag and LTE guard band
deployment, this parameter
does not need to be set.
In LTE in-band deployment,
the value FALSE is
recommended if the SRS is
configured for the LTE FDD
cell and may be sent using
the NB-IoT PRB. The value
TRUE is used in other
situations.
High Frequency Guard UlGuardBandCfg.HighFre -

Band qGuardBand

eRAN
Low Frequency Guard Band UlGuardBandCfg.LowFre -

qGuardBand
Guard Band Between UlGuardBandCfg.Nprach -

NPRACH and NPUSCH NpuschGuardBand
Note for (1): In LTE in-band deployment mode, there are two cases.
l If the corresponding LTE FDD cell bandwidth is 5 or 15 MHz, set this parameter to
NEG_2 when the NB-IoT PRB is positioned in the first half of the LTE FDD cell
bandwidth, or POS_1 for the NB-IoT PRB in the second half.
l If the corresponding LTE FDD cell bandwidth is 10 or 20 MHz, set this parameter to
POS_0 when the NB-IoT PRB is positioned in the first half of the LTE FDD cell
bandwidth, or NEG_1 for the NB-IoT PRB in the second half.
Configure PRB sector equipment parameters for the anchor carrier.
Local Cell ID EuPrbSectorEqm.LocalCe -

llId
PRB ID EuPrbSectorEqm.PrbId Set this parameter to the

PRB ID of the anchor
carrier.
Sector Equipment ID EuPrbSectorEqm.SectorE -

qmId
Reference Signal Power EuPrbSectorEqm.Referen Set reference signal power

ceSignalPwr for the PRB sector
equipment. If this parameter
is set to 32767, the reference
signal power is determined
by the
PDSCHCfg.ReferenceSign
alPwr parameter.
Baseband Equipment ID EuPrbSectorEqm.BaseBa If this parameter is set to

ndEqmId 255, no baseband equipment
is specified for the cell. In
this case, the cell can use
any baseband equipment of
the serving eNodeB.
Auto Config Flag eUCellSectorEqm.AutoCfg -

Flag

eRAN
For DBS3900 LampSite and DBS5900 LampSite, set PRB sector equipment group
parameters for the NB-IoT anchor carrier.
Local Cell ID EuPrbSectorEqmGroup.L -

ocalCellId
PRB ID EuPrbSectorEqmGroup.P Set this parameter to the

rbId PRB ID of the anchor
carrier.
Sector Equipment Group ID EuPrbSectorEqmGroup.S -

ectorEqmGroupId
Reference Signal Power EuPrbSectorEqmGroup.R Set reference signal power

eferenceSignalPwr for the PRB sector
equipment group. If this
parameter is set to 32767,
the reference signal power is
determined by the
PDSCHCfg.ReferenceSign
alPwr parameter.
Baseband Equipment ID EuPrbSectorEqmGroup.B If this parameter is set to

aseBandEqmId 255, no baseband equipment
is specified for the cell. In
this case, the cell can use
any baseband equipment of
the serving eNodeB.
Auto Config Flag EuPrbSectorEqmGroup.A -

utoConfigFlag
For DBS3900 LampSite and DBS5900 LampSite, add PRB sector equipment group members
for the NB-IoT anchor carrier.
Local Cell ID PrbSectorEqmGrpI- -

tem.LocalCellId
PRB ID PrbSectorEqmGrpI- Set this parameter to the

tem.PrbId PRB ID of the anchor
carrier.

eRAN
Sector Equipment ID PrbSectorEqmGrpI- Set this parameter to a

tem.SectorEqmId sector equipment ID. In LTE
in-band deployment, ensure
that the configuration of the
sector equipment in the PRB
sector equipment group is
consistent with that of the
sector equipment in the
sector equipment group of
the corresponding LTE cell.
Sector Equipment Group ID PrbSectorEqmGrpItem. Assign a PRB sector

SectorEqmGroupId equipment group ID for the
sector equipment.
Set cell operator information.
Local Cell ID CellOp.LocalCellId -
Local tracking area ID CellOp.TrackingAreaId -
Cell reserved for operator CellOp.CellReservedForOp Set this parameter to its

recommended value.
Set NPRACH power parameters and the NPRACH start time configuration indication.
Local Cell ID RACHCfg.LocalCellId -
Preamble Initial Received RACHCfg.PreambInitRcv The value DBM_112 is

Target Power TargetPwr recommended.
NB-IoT Cyclic Prefix RACHCfg.NbCyclicPrefix Set this parameter to its

Length Length recommended value.
NB-IoT RSRP First RACHCfg.NbRsrpFirstThr Set this parameter based on

Threshold eshold the radio plan, involving the
reference signal power, path
loss ranges of coverage
levels 0 and 1, and other
factors.

eRAN
NB-IoT RSRP Second RACHCfg.NbRsrpSecondT Set this parameter based on

Threshold hreshold the radio plan, involving the
reference signal power, path
loss ranges of coverage
levels 1 and 2, and other
factors.
PRACH Start Time Config RACHCfg.PrachStartTime Generally, set this parameter

Indication CfgInd to its recommended value.
However, if the NPRACH
start time needs to be
configured for each
coverage level, set this
parameter to CFG. For
details, see 4.3.3 NPRACH
Resource Configuration.
Set cell-level NPRACH parameters specific to a coverage level.
Local Cell ID CellRachCECfg.LocalCellI -

d
Coverage Level CellRachCECfg.Coverage -

Level
Contention Resolution CellRachCECfg.Contentio Set this parameter to its

Timer nResolutionTimer recommended value.
Maximum Number of CellRachCECfg.MaxNum Set this parameter to its

Preamble Attempt PreambleAttempt recommended value.
RA Response Window Size CellRachCECfg.RaRespon Set this parameter to its

seWindowSize recommended value.
Set PRB-level NPRACH parameters specific to a coverage level.
Local Cell ID PrbRachCeConfig.LocalC -

ellId
PRB ID PrbRachCeConfig.PrbId Set this parameter to the

PRB ID of the anchor
carrier.
Coverage Level PrbRachCeConfig.Covera -

geLevel

eRAN
PRACH Start Time PrbRachCeConfig.PrachSt Set this parameter to its

artTime recommended value.
PRACH Transmission PrbRachCeConfig.PrachT Set the same NPRACH

Period ransmissionPeriod transmission period for all
coverage levels of the cell if
the
RACHCfg.PrachStartTime
CfgInd parameter is set to
NOT_CFG. For details, see
4.3.3 NPRACH Resource
Configuration.
Set this parameter to its
recommended value if the
RACHCfg.PrachStartTime
CfgInd parameter is set to
CFG.
PRACH Subcarrier Offset PrbRachCeConfig.PrachS Set the same subcarrier

ubcarrierOffset offset for all coverage levels
of a cell in the current
version. This parameter
cannot be set to SC0 or SC2
in the current version to
avoid the large impact of
NPRACH and UCI resource
overlapping on cell access
performance.
PRACH Subcarrier Number PrbRachCeConfig.PrachS Set this parameter to its

ubcarrierNumber recommended value.(1)
PRACH Repetition Count PrbRachCeConfig.PrachR Set this parameter to its

epetitionCount recommended value. If this
parameter is set to an
inappropriate value, the
NPRACH resources for
different coverage levels
overlap or the RA-RNTIs
for different coverage levels
are the same. As a result, the
corresponding cell cannot be
activated.
PRACH Detection PrbRachCeConfig.PrachD Set this parameter to

Threshold etectionThld different values in different
scenarios as recommended.
Note for (1):

eRAN
l In any of the following cases, the number of NPRACH subcarriers can only be set to
SC_NUM_12:
– The coverage level is 2.
– The BBP is LBBPd.
l If coverage level 2 has been enabled for a cell, the number of NPRACH subcarriers
cannot be set to SC_NUM_48.
Set cell-level uplink power control parameters.
Local Cell ID CellUlpcComm.LocalCellI -

d
Path loss coefficient CellUlpcComm.PassLossC The value AL1 is

oeff recommended for an NB-
IoT cell.
P0 nominal PUSCH CellUlpcComm.P0Nomina The value -105 is

lPUSCH recommended for an NB-
IoT cell.
Set cell-level DRX parameters.
Local Cell ID CellDrxPara.LocalCellId -
DRX Algorithm Switch CellDrxPara.DrxAlgSwitch Set this parameter to ON if

there are power saving
requirements for UEs.
NB-IoT On Duration Timer CellDrxPara.NbOnDuratio Set this parameter to its

nTimer recommended value.
NB-IoT DRX Inactivity CellDrxPara.NbDrxInactiv The DRX cycle length

Timer ityTimer calculated based on this
parameter for each coverage
level must not exceed the
value of the NB-IoT Long
DRX Cycle parameter.
Otherwise, DRX cannot be
enabled for UEs at the
corresponding coverage
level.
NB-IoT DRX CellDrxPara.NbDrxReTxT Set this parameter to its

Retransmission Timer imer recommended value.

eRAN
NB-IoT Long DRX Cycle CellDrxPara.NbLongDrxC The duration calculated

ycle based on the NB-IoT On
Duration Timer parameter
for each coverage level must
not exceed the value of the
NB-IoT Long DRX Cycle
parameter. Otherwise, DRX
cannot be enabled for UEs
at the corresponding
coverage level.
NB-IoT DRX Uplink CellDrxPara.NbDrxUlReT Set this parameter to its

Retransmission Timer xTimer recommended value.
Set cell selection parameters.
Local Cell ID CellSel.LocalCellId -
Minimum required RX level CellSel.QRxLevMin A smaller value is

recommended for a larger
cell coverage.
Minimum required RX CellSel.QQualMin Set this parameter to its

quality level default value.
Set common information for cell reselection.
Local Cell ID CellResel.LocalCellId -
Hysteresis value for ranking CellResel.Qhyst When most NB-IoT UEs in

criteria a cell are stationary, cell
reselection caused by signal
fluctuation increases UE
power consumption. Set this
parameter to a larger value
to increase the cell
reselection difficulty and
reduce power consumption
for cell reselection.
Minimum required RX level CellResel.QRxLevMin A smaller value is

recommended for a larger
cell coverage.

eRAN
Ue max power allowed CellResel.PMaxCfgInd -

configure indicator
Max transmit power allowed CellResel.PMax -
Threshold for intra freq CellResel.SIntraSearchCfg Set this parameter to its

measurements configure Ind default value.
indicator
Threshold for intra CellResel.SIntraSearch A smaller value is

frequency measurements recommended for a larger
cell coverage.
NB-IoT Intra-Freq CellResel.TReselForNb Set this parameter to its

Reselection Time default value.
Threshold for non-intra freq CellResel.SNonIntraSearc Set this parameter to its

measurements configure hCfgInd default value.
indicator
Threshold for non-intra CellResel.SNonIntraSearc A smaller value is

frequency measurements h recommended for a larger
cell coverage.
NB-IoT Inter-Freq CellResel.TReselInterFreq- Set this parameter to its

Reselection Time ForNb default value.
If UEs (such as meters) in a cell are all stationary and not at cell edge, you are advised not to
configure neighboring cells for the cell to reduce overhead over the air interface; in this case,
UEs can reselect cells based on configured reselection thresholds. In other situations,
configure external cells and neighboring cells.
Set external cell information.
Mobile country code EutranExternalCell.Mcc -
Mobile network code EutranExternalCell.Mnc -
eNodeB ID EutranExternalCell.eNode -
BId
Cell ID EutranExternalCell.CellId -
Downlink EARFCN EutranExternalCell.DlEar Set this parameter as

fcn planned.
Physical cell ID EutranExternalCell.PhyCe -

llId
Tracking area code EutranExternalCell.Tac -

eRAN
Cell Name EutranExternalCell.CellN -

ame
Uplink Frequency Offset EutranExternalCell.UlFre Set this parameter as

qOffset planned.
Downlink Frequency Offset EutranExternalCell.DlFre Set this parameter as

qOffset planned.
NB-IoT Cell Flag EutranExternalCell.NbCel Set this parameter to TRUE,

lFlag indicating an NB-IoT cell.
Set an intra-frequency neighboring cell of the anchor carrier.
Mobile country code EutranIntraFreqN- -

Cell.Mcc
Mobile network code EutranIntraFreqN- -

Cell.Mnc
eNodeB ID EutranIntraFreqN- -
Cell.eNodeBId
Cell ID EutranIntraFreqN- -
Cell.CellId
Cell offset EutranIntraFreqN- -

Cell.CellQoffset
Local cell name EutranIntraFreqN- -

Cell.LocalCellName
Neighbour cell name EutranIntraFreqN- -

Cell.NeighbourCellName
Physical cell ID EutranIntraFreqN- -

Cell.PhyCellId
Set an inter-frequency neighboring cell of the anchor carrier.
Mobile country code EutranInterFreqN- -

Cell.Mcc
Mobile network code EutranInterFreqN- -

Cell.Mnc

eRAN
eNodeB ID EutranInterFreqN- -
Cell.eNodeBId
Cell ID EutranInterFreqN- -
Cell.CellId
Local cell name EutranInterFreqN- -

Cell.LocalCellName
Neighbour cell name EutranInterFreqN- -

Cell.NeighbourCellName
Set an inter-frequency carrier frequency of the anchor carrier.
Minimum required RX level EutranInterNFreq.QRxLe A smaller value is

vMin recommended for a larger
cell coverage. A smaller
value indicates a greater
difficulty for UEs to camp
on other cells.
PMAX configure indicator EutranInterNFreq.PmaxC Set this parameter to its

fgInd default value.
PMAX EutranInterNFreq.Pmax Set this parameter to its

default value.
Downlink EARFCN EutranInterNFreq.DlEarfc Set this parameter to a

n neighboring EARFCN of
the anchor carrier based on
the frequency plan.
Frequency offset EutranInterNFreq.Qoffset Set this parameter when

Freq there are different frequency
camping requirements.
You can set this parameter
to different values for
different neighboring
frequencies that have
different lowest coverage
levels.
Uplink Frequency Offset EutranInterNFreq.UlFreq Set this parameter as

Offset planned.
Downlink Frequency Offset EutranInterNFreq.DlFreq Set this parameter as

Offset planned.

eRAN
Set the SIB16-NB broadcast switch, RACH backoff control switch, NB-IoT cell algorithm
switch, and other switches.
Lte Utc Broadcast Switch CellAlgoSwitch.LteUtcBro Broadcast of the UTC time

adcastSwitch in SIB16-NB consumes air
interface resources.
SIB16-NB broadcast can be
disabled if UEs can achieve
time synchronization in
other ways, for example, by
obtaining time information
from the EMM information
of the MME or from the
timer server on the Internet
using NTP.
Congestion Control Switch CellAlgoSwitch.MTCCong Selecting the

for MTC UE ControlSwitch EABAlgoSwitch option of
this parameter is
recommended when the
cell's eNodeB or all
connected MMEs are
overloaded.
Selecting the
ExtendedwaittimeSwitch
option is recommended if
the air interface of the cell is
congested.
RACH algorithm switch CellAlgoSwitch.RachAlgoS Select the BackOffSwitch

witch option of this parameter.
NB-IoT Cell Algorithm CellAlgoSwitch.NbCellAlg It is recommended that the

Switch oSwitch SI_OFFSET_ADAPTIVE_
CFG_SWITCH option be
selected when time
synchronization is
implemented on the NB-IoT
network or there is a high
probability of UEs failing to
demodulate system
information(1). If downlink
resources are limited, it is
recommended that the
NPDCCH_OFFSET_ADA
PTIVE_SWITCH option
be selected.

eRAN
Uplink schedule switch CellAlgoSwitch.UlSchSwit Selecting the

ch UlRaUserSchOptSw option
is recommended if the air
interface of the cell is
congested.
Uplink Schedule Extended CellAlgoSwitch.UlSchExtS Select the

Switch witch PreambleSchEnhSwitch
option when there are UEs
that do not support the
maximum backoff index 12
defined in 3GPP TS 36.321
R13.
Repeater Switch CellAlgoSwitch.RepeaterS Select the AntRsPwrSwitch

witch option if repeaters are used
to amplify RRU output
power.
Note for (1): The DCI_SF_REP_NUM_COMP_SWITCH option of the

CellAlgoSwitch.NbCellAlgoSwitch parameter needs to be selected if there are NB-IoT UEs
in compliance with 3GPP TS 36.213 V13.3.0 (2016-09) in the cell. For details, see 3.4 NB-
IoT UE Requirements.
Set a dynamic access class barring policy mode.

Dynamic AC Barring Policy eNodeBFlowCtrlPara.Dyn The same access class

Mode AcBarPolicyMode control parameter settings
are recommended for the
cells belonging to the same
board.
Set access barring parameters.
EAB Category CellEABAlgoPara.EABCat By default, access barring

egory control is performed on all
UEs. To keep only roaming
UEs under access control,
CATEGORY_B or
CATEGORY_C.

eRAN
NB-IoT Access Barring For CellEABAlgoPara.ABFor Access is allowed by

Exception Data ExceptionData default. If there is a large
proportion of access with
the cause of exception data,
BOOLEAN_TRUE to bar
such access.
NB-IoT Access Barring For CellEABAlgoPara.ABForS UEs of AC11 to AC15 are

AC11-15 pecialAC allowed to access the
network by default. If there
are too many access requests
from UEs of an access class,
set this parameter to bar
their access.(1)
EAB Control Statistic CellEABAlgoPara.EABSta Set this parameter to its

Periods tPeriod recommended value.
EAB Control Trigger CellEABAlgoPara.EABTri Set this parameter to its

Threshold ggerThd recommended value.
EAB Control Cancel CellEABAlgoPara.EABCa Set this parameter to its

Threshold ncelThd recommended value.
EAB Cancel Condition CellEABAlgoPara.EABCa Set this parameter to its

Satisfied Period ncelCondSatiPeriod recommended value.
Access Class Count for CellEABAlgoPara.ACCou Set this parameter to its

Manual Access Barring ntForManualBarring recommended value.
Note for (1): AC12 to AC14 are valid only in the home country, and AC11 and AC15 are
valid only in the home PLMN (HPLMN) and equivalent HPLMN (EHPLMN), according to
3GPP TS 36.331 R13.
Set a user number threshold for admission control.
Admission Control User CellRacThd.AcUserNumbe Set this parameter to a small

Number r value when there are a large
number of online NB-IoT
UEs.
Set parameters to allow LTE FDD UEs to preempt NB-IoT UEs when NB-IoT and LTE FDD
are co-sited.

eRAN
LTE User Preempt NB-IoT ENodeBAlgoSwitch.LTEPr The value ON is

User Switch eemptNbSwitch recommended.
UE number preemption ENodeBAlgoSwitch.UeNu Set this parameter based on

switch mPreemptSwitch the network plan. Selecting
the NbUeNumPreemptS-
witch option is
recommended.
Set the minimum proportion of RRC_CONNECTED UEs allowed for NB-IoT when NB-IoT
and LTE FDD are co-sited.
NB-IoT Reserved Minimum ENodeBNbPara.NbRsvMi Set this parameter as

User Number Ratio nUserNumRatio required.
Set an eNodeB frame offset when NB-IoT and LTE cells share the same RF modules or
BBPs.
FDD Frame Offset ENodeBFrameOffset.Fdd Set the same eNodeB frame

FrameOffset offset for NB-IoT and LTE
cells.
Set a cell frame offset when NB-IoT and LTE cells share the same RF modules or BBPs.
Local Cell ID CellFrameOffset.LocalCell -

Id
Frame Offset Mode CellFrameOffset.FrameOff Set this parameter to its

setMode default value.
Frame Offset CellFrameOffset.FrameOff Set the same frame offset for

set NB-IoT and LTE cells.
Set cell antenna power information when repeaters are used to amplify the RRU output power.
Local Cell ID CellChPwrCfg.LocalCellId -

eRAN
Antenna Output Power CellChPwrCfg.AntOutput Set this parameter only

Pwr when the AntRsPwrSwitch
option of the
CellAlgoSwitch.RepeaterS
witch parameter is selected.
You are advised to set this
parameter based on the
actual repeater output
power.
Output Power Rate CellChPwrCfg.OutputPow Set this parameter only

erRate when the AntRsPwrSwitch
option of the
CellAlgoSwitch.RepeaterS
witch parameter is selected.
You are advised to set this
parameter to the proportion
of the corresponding cell
output power.(1)
Note for (1): In LTE in-band deployment, you are advised to set this parameter to 0 for both
NB-IoT and LTE FDD cells if the AntRsPwrSwitch option of the
CellAlgoSwitch.RepeaterSwitch parameter is selected for both NB-IoT and LTE FDD cells.
7.1.1.2 Data Preparation for Optimization

To optimize paging over the air interface, adjust the following parameters.
Local Cell ID PCCHCfg.LocalCellId -
NB-IoT Default Paging PCCHCfg.DefaultPagingC Set this parameter to its

Cycle ycleForNb default value.(1)
NB-IoT nB PCCHCfg.NbForNbIoT This parameter must work

together with the
PCCHCfg.DefaultPagingC
ycleForNb parameter. The
product of the values of
these two parameters must
be greater than or equal to 1.
Otherwise, UEs may fail to
receive paging messages.(2)
Paging Message Sending PCCHCfg.PagingStrategy Set this parameter to its

Strategy recommended value.

eRAN
Maximum Number of PrbSchConfig.MaxNumRe Set this parameter to its

Paging Repetition petitionForPaging recommended value.(3)
NB-IoT Extended Paging ENodeBNbPara.NbExtend It is recommended that this

Optimization Switch edPagingOptSwitch switch be turned on when
the NB-IoT paging capacity
needs to be improved.
However, the paging success
rate may decrease.
Note for (1): This parameter must work together with the PCCHCfg.NbForNbIoT parameter.
The product of the values of these two parameters must be greater than or equal to 1.
Otherwise, UEs may fail to receive paging messages. If eDRX is not supported, a long cycle
is recommended to reduce UE power consumption.
Note for (2): The value of this parameter is related to the maximum NPDCCH repetition
count. The larger the NPDCCH repetition count, the fewer the paging groups. The number of
paging groups can be set to the maximum value FOUR_T only when the maximum
NPDCCH repetition count is 1.
Note for (3): When the coverage of paging services is not less than that of mobile originated
(MO) services, it is recommended that this parameter be set to the initial NPDCCH repetition
count corresponding to the highest coverage level, that is, set to the product of
PrbPdcchCeConfig.PdcchMaxRepetitionCnt and
PrbPdcchCeConfig.PdcchTransRptCntFactor. When the coverage of paging services is less
than that of MO services, this parameter can be set to a small repetition count to reduce UE
power consumption in idle mode.
To change the maximum paging repetition count and optimize parameters related to downlink
invalid subframes, adjust the following parameters.
Local Cell ID PrbSchConfig.LocalCellId -
PRB ID PrbSchConfig.PrbId -
Maximum Number of PrbSchConfig.MaxNumRe Set this parameter to its

Paging Repetition petitionForPaging recommended value.(1)
NB-IoT DL Bitmap Size PrbSchConfig.NbDlBitmap Set this parameter to its

Size recommended value.
NB-IoT DL Bitmap10 PrbSchConfig.NbDlBitmap In the current version, this

10 parameter applies only to
NB-IoT OTDOA-based
positioning. You are advised
to set this parameter when
OTDOA-based positioning
is enabled.(2)

eRAN
NB-IoT DL Bitmap30 PrbSchConfig.NbDlBitmap In the current version, this

30 parameter applies only to
NB-IoT OTDOA-based
positioning. You are advised
to set this parameter when
OTDOA-based positioning
is enabled and the
PrbSchConfig.NbDlBitmap
Size parameter is set to
SF40.(3)
Note for (1): When the coverage of paging services is not less than that of mobile originated
(MO) services, it is recommended that this parameter be set to the initial NPDCCH repetition
count corresponding to the highest coverage level, that is, set to the product of
PrbPdcchCeConfig.PdcchMaxRepetitionCnt and
PrbPdcchCeConfig.PdcchTransRptCntFactor. When the coverage of paging services is less
than that of MO services, this parameter can be set to a small repetition count to reduce UE
power consumption in idle mode.
Note for (2): Do not configure many invalid subframes for the anchor carrier as invalid
subframes occupy downlink resources. Otherwise, the NPDCCH may have no resources to
use and the cell may work improperly. Do not configure more than one invalid subframe
when the PrbPdcchCeConfig.PdcchPeriodFactor parameter is set to G_2 and the
PrbPdcchCeConfig.PdcchMaxRepetitionCnt parameter is set to REP_8.
Note for (3): Do not configure many invalid subframes for the anchor carrier as invalid
subframes occupy downlink resources. Otherwise, the NPDCCH may have no resources to
use and the cell may work improperly. Do not configure more than one invalid subframe in
each 10 ms period when the PrbPdcchCeConfig.PdcchPeriodFactor parameter is set to G_2
and the PrbPdcchCeConfig.PdcchMaxRepetitionCnt parameter is set to REP_8.
To optimize the default setting for paging over the S1 interface in DRX mode, adjust the
following parameter.
S1 Default Paging DRX GlobalProcSwitch.S1Defa The value of this parameter

Value for NB-IoT ultPagingDrxForNb cannot be smaller than the
value of
PCCHCfg.DefaultPagingC
ycleForNb for any NB-IoT
cells served by the same
eNodeB. Otherwise, the
probability of paging
failures will increase.
To optimize UE control timers, adjust the following parameters.

eRAN
NB-IoT Ue inactive timer RrcConnStateTim- If there are a large number

er.NbUeInactiveTimer of online UEs (especially
online UEs at coverage level
2), then channel resources
will be insufficient, UEs
cannot be scheduled
promptly, and their
inactivity time is very likely
to reach the inactivity timer
value. In this scenario, it is
recommended that this
parameter be set to a large
value.
RRC Connection Release RrcConnStateTim- Set this parameter to its

Timer er.RrcConnRelTimer default value.
Filter Repeated RrcConnStateTim- Set this parameter to its

RRCConnReq Timer er.FilterReptRrcConnReq- default value.
Timer
Extended Wait Time RrcConnStateTim- Set this parameter to its

er.ExtendedWaitTime default value.
To optimize eNodeB timers, adjust the following parameters.

S1 Message Waiting Timer ENodeBConnStateTim- Set this parameter to its

er.S1MessageWaitingTimer default value.
UU Message Waiting Timer ENodeBConnStateTim- Set this parameter to its

er.UuMessageWaitingTim- default value.
er
To optimize NPDCCH resource allocation at different coverage levels in an NB-IoT cell,

adjust the following parameters.
Local Cell ID PrbPdcchCeConfig.LocalC -

ellId
PRB ID PrbPdcchCeConfig.PrbId -
Coverage Level PrbPdcchCeConfig.Covera -

geLevel

eRAN
PDCCH Maximum PrbPdcchCeConfig.Pdcch Set this parameter to its

Repetition Count MaxRepetitionCnt recommended value.(1)
PDCCH Period Factor PrbPdcchCeConfig.Pdcch Set this parameter to its

PeriodFactor recommended value.(2)
PDCCH Initial Trans Rept PrbPdcchCeConfig.Pdcch Set this parameter to its

Count Factor TransRptCntFactor recommended value.
PDCCH Offset PrbPdcchCeConfig.Pdcch Set this parameter to its

Offset recommended value.
Note for (1): A larger parameter value indicates a larger maximum NPDCCH repetition count,
a longer NPDCCH period, and a longer scheduling interval at the corresponding coverage
level. This parameter cannot be set to REP_4 for a coverage level when the
PrbPdcchCeConfig.PdcchPeriodFactor parameter is set to G_2 for this coverage level. For
details, see 4.5.4.3 Downlink Scheduling for Initial Transmissions.
Note for (2): The NPDCCH period for a coverage level is equal to the maximum NPDCCH
repetition count for this coverage level multiplied by the NPDCCH period factor for this
coverage level. In addition, consider related timers when setting the NPDCCH period for a
coverage level. For example, the maximum contention resolution timer value is 10.24s, as
stipulated in 3GPP specifications. If the sum of the NPDCCH period for a coverage level,
scheduling delay, Msg4 transmission duration over the NPDSCH, and Msg4 ACK/NACK
feedback duration exceeds 10.24s, the contention resolution will fail to be completed. This
parameter cannot be set to G_2 for a coverage level when the
PrbPdcchCeConfig.PdcchMaxRepetitionCnt parameter is set to REP_4 for this coverage
level. For details, see 4.5.4.3 Downlink Scheduling for Initial Transmissions.
To optimize uplink scheduling at different coverage levels, adjust the following parameters.
The parameters for coverage levels 1 and 2 take effect only after NB-IoT coverage extension
is activated.
Local Cell ID PrbUlSchCeAlgo.LocalCel -

lId
PRB ID PrbUlSchCeAlgo.PrbId -
Coverage Level PrbUlSchCeAlgo.Coverage -

Level
Uplink Initial MCS PrbUlSchCeAlgo.UlInitial Set this parameter to its

Mcs recommended value.

eRAN
UL Initial Transmission PrbUlSchCeAlgo.UlInitial Set this parameter to its

Repetition Count TransRptCount recommended value.
This parameter works with
other timers. If the uplink
initial transmission
repetition count is set to a
very large value,
transmission delays will be
prolonged and RRC
connections may be
abnormally released during
data transmissions.
ACK/NACK Transmission PrbUlSchCeAlgo.AckNack Set this parameter to its

Repetition Count TransRptCount recommended value.
This parameter works with
other timers. If the ACK/
NACK transmission
repetition count is set to a
very large value,
transmission delays will be
prolonged and RRC
connections may be
abnormally released during
data transmissions.
Msg4 ACK/NACK Trans PrbUlSchCeAlgo.AckNack Set this parameter to its

Repetition Count TransRptCountMsg4 recommended value.
If the Msg4 ACK/NACK
transmission repetition
count is set to a very large
value, transmission delays
will be prolonged and the
collaboration with other
timers needs to be
considered. For example,
the maximum contention
resolution timer value is
10.24s, as stipulated in
3GPP specifications. When
the NPDCCH period is long
and the Msg4 ACK/NACK
transmission repetition
count is set to a very large
value, the contention
resolution may fail to be
completed.

eRAN
NB-IoT Cell Algorithm CellAlgoSwitch.NbCellAlg For UEs with high RSRP

Switch oSwitch but low SINR at coverage
level 1 or 2, selecting the
UCI_REP_NUM_ADAPTI
VE_SWITCH option of
this parameter decreases the
UCI repetition count and
reduces interference to
neighboring cells.
Uplink Interference CellUlschAlgo.UlInterfRan Set this parameter to

Randomization Mode domMode THREE_MODE_BASED_
ON_PCI to enable uplink
interference randomization.
Uplink Schedule Extended CellAlgoSwitch.UlSchExtS To enable uplink AMC

Switch witch optimization, select the
UlPAMCSwitch option.
To optimize downlink scheduling at different coverage levels, adjust the following

parameters. The parameters for coverage levels 1 and 2 take effect only after NB-IoT
coverage extension is activated.
Local Cell ID PrbDlSchCeAlgo.LocalCel -

lId
PRB ID PrbDlSchCeAlgo.PrbId -
Coverage Level PrbDlSchCeAlgo.Coverage -

Level
Downlink Initial MCS PrbDlSchCeAlgo.DlInitial Set this parameter to its

Mcs recommended value.
DL Initial Transmission PrbDlSchCeAlgo.DlInitial Set this parameter to its

Repetition Count TransRptCount recommended value.(1)
Uu Message Waiting Timer PrbDlSchCeAlgo.UuMessa Set this parameter to its

geWaitingTimer recommended value.

eRAN
NB-IoT Cell Algorithm CellAlgoSwitch.NbCellAlg To accelerate MCS and

Switch oSwitch repetition count adjustment,
select the
ADAPTIVE_STEP_SWIT
CH option.
To increase the downlink
control channel resource
usage, select the
NPDCCH_OFFSET_ADA
PTIVE_SWITCH option.
NB-IoT Cell Algorithm CellAlgoExtSwitch.NbCell To enable downlink AMC

Extended Switch AlgoExtSwitch optimization, select the
DL_AMC_OPT_SWITCH
option.
To improve RRC connection
release signaling
performance, select the
RELEASE_PERFM_IMP
ROVE_SWITCH option.
Note for (1): A too large value increases the transmission delays, resource consumption, and
congestion level when there are a large number of UEs and the Coverage Level parameter is
set to a high level. If the downlink initial transmission repetition count is set to a very large
value, transmission delays will be prolonged and the collaboration with other timers needs to
be considered. For example, the maximum contention resolution timer value is 10.24s, as
stipulated in 3GPP specifications. When the NPDCCH period is long and the downlink initial
transmission repetition count is set to a very large value, the contention resolution may fail to
be completed.
To optimize the downlink gap function in downlink scheduling, adjust the following
parameters.

eRAN
Downlink Scheduling PrbSchConfig.DlSchedulin Selecting the

Switch gSwitch DL_GAP_SWITCH option
will slightly change packet
transmission delays when
UEs at coverage levels 2
and 0 are scheduled at the
same time. The delays for
UEs at coverage level 2 are
prolonged because resource
allocation is postponed
when encountering a
downlink gap, but the delays
for UEs at coverage level 0
are shortened.
Selecting this option is not
recommended when many
UEs are at coverage level 2.
This is because there are
small chances of scheduling
such UEs in this scenario.
As a result, RRC
connections cannot be set up
when the UEs request access
but no resources are
available, and the RRC
connection setup success
rate will decrease.
PRB ID PrbDlGapConfig.Prbid -
Local Cell ID PrbDlGapConfig.LocalCel -

lId
Downlink Gap Threshold PrbDlGapConfig.DlGapTh It is recommended that this

reshold parameter be set in the
following range:
{PrbPdcchCeConfig.Pdcch
MaxRepetitionCnt for
coverage level 0 or 1,
PrbPdcchCeConfig.Pdcch
MaxRepetitionCnt for
coverage level 2}
Downlink Gap Period PrbDlGapConfig.DlGapPe Set this parameter to its

riod default value.
Downlink Gap Duration PrbDlGapConfig.DlGapD Set this parameter to its

Coefficient urationCoeff default value.
To optimize NPUSCH power control, adjust the following parameters.

eRAN
Local Cell ID CellUlpcDedic.LocalCellId -
RSRP filtering coefficient CellUlpcDedic.FilterRsrp Set this parameter to its

recommended value.
To optimize system information mapping, adjust the following parameters.

Local Cell ID CellSiMap.LocalCellId -
NB-IoT SIB1 Repetition CellSiMap.NbSib1Repetitio When radio conditions are

Number nNum favorable, set this parameter
to a small value. Otherwise,
set this parameter to a large
value.
NB-IoT SIB2 Period CellSiMap.NbSib2Period It is not recommended that

these parameters be set to
NB-IoT SIB3 Period CellSiMap.NbSib3Period too large values. When there
NB-IoT SIB4 Period CellSiMap.NbSib4Period are many UEs, these
parameters can be set to
NB-IoT SIB5 Period CellSiMap.NbSib5Period large values.
NB-IoT SIB14 Period CellSiMap.NbSib14Period It is not recommended that

these parameters be set to
NB-IoT SIB16 Period CellSiMap.NbSib16Period too many different values.
To optimize inactivity timers for different service types, adjust the following parameters.
NB-IoT Cell Algorithm CellAlgoSwitch.NbCellAlg Select the

Switch oSwitch RETRIEVE_UE_INFO_S
WITCH option.

eRAN
NB-IoT UE Inactivity Timer QciPara.NbUeInactivityTi- Set the parameter to

for QCI merForQci different values for services
with different QCIs.
l For services sensitive to
power consumption
(such as smart meter
reading), set this
parameter to a small
value to reduce UE
power consumption in
connected mode.
l For services insensitive
to power consumption
but sensitive to delay
(such as services related
to white goods), set this
parameter to a large
value to reduce RRC
connection
reestablishment delays.
To improve the performance of NB2 UEs, adjust the following parameters.

NB-IoT Cell Algorithm CellAlgoSwitch.NbCellAlg Select the

Switch oSwitch TBS_EXTENSION_SWIT
CH and
RETRIEVE_UE_INFO_S
WITCH options of this
parameter.
For NB2 UEs, the maximum
TBS is extended to 2536
bits and the largest MCS
index is extended to 13 in
both uplink and downlink.
This increases the uplink
and downlink peak rates of
UEs and reduces UE power
consumption.
Adjust other performance optimization parameters.

eRAN
Parameter Parameter ID Option Setting Notes

Name
NB-IoT Cell CellAlgoSwitc CP_RRC_CON In control plane CIoT EPS

Algorithm h.NbCellAlgoS N_REESTABLI optimization mode, it is
Switch witch SHMENT_SW recommended that this option be
selected when the MMEs support
RRC connection reestablishment
and there are moving UEs that
support RRC connection
reestablishment in this mode.
CellAlgoSwitc DL_INTRF_R It is recommended that this option

h.NbCellAlgoS ANDOMIZATI be selected when there are NB-IoT
witch ON_SWITCH UEs that have the capability
indicated by the interferenceRan-
domisationConfig-r14 IE.
The Strategy Of CellPdcchAlgo N/A The value

PDCCH .PDCCHAggLv STRATEGYBASEDONCO-
Aggregation lAdaptStrage VERAGE is recommended when
Level there are UEs in deep coverage
Adaptation areas in a cell.
The value
STRATEGYBASEDONCAPAC-
ITY is recommended when the
downlink resources of a cell are
limited.
Contention CellRachCECf N/A The value PP_32 is recommended.

Resolution g.ContentionRe If the contention resolution timer
Timer solutionTimer is incorrectly configured, the RRC
connection reestablishment
procedure will fail in control plane
CIoT EPS optimization mode.(1)
Uplink schedule CellAlgoSwitc UlSmallRBSpe To enable uplink reverse RU

switch h.UlSchSwitch ctralEffOptSw adjustment for NB-IoT, select this
option.
Note for (1): If the contention resolution timer is incorrectly configured, the RRC connection
reestablishment procedure will fail in control plane CIoT EPS optimization mode. Consider
the following during the configuration:
l A Connection Establishment Indication message needs to be received from the MME

before the Connection Establishment Indication message response timer expires.
l Connection Establishment Indication message response timer value = min{Valid value of
the contention resolution timer – 3 x NPDCCH period, Valid value of the S1 message
waiting timer}
– Valid value of the contention resolution timer = min{Value of the
CellRachCECfg.ContentionResolutionTimer parameter, 10.24s}

eRAN
– Valid value of the S1 message waiting timer = min{Value of the

ENodeBConnStateTimer.S1MessageWaitingTimer parameter, 2s}
7.1.2 Using MML Commands
7.1.2.1 Activation Command Examples (for DBS3900 LampSite and DBS5900

LampSite)
When the eNodeB model is DBS3900 LampSite or DBS5900 LampSite, perform the
following configuration:
l Set the Cell.MultiRruCellFlag parameter to BOOLEAN_TRUE.
l Set the Cell.MultiRruCellMode parameter to MPRU_AGGREGATION.
l Configure a sector equipment group and add the corresponding PRB sector equipment to
the group.
The recommended values of some other parameters are different from those for other base
station models. The following provides command examples for DBS3900 LampSite and
DBS5900 LampSite.
//Set an MME compliance protocol release.
MOD S1INTERFACE:S1INTERFACEID=0,MMERELEASE=Release_R13;
MOD S1: S1Id=0,MMERELEASE=Release_R13;
//(Optional) For a newly installed pRRU, add a sector and a piece of sector
equipment. If the CREATESECTOREQM parameter is set to TRUE, the sector equipment
will be automatically added when the sector is added.
//Add a sector. For DBS3900 LampSite and DBS5900 LampSite, add multiple sectors
if there are multiple pRRUs.
ADD SECTOR: SECTORID=61, SECNAME="CPRI0_RHUB1_pRRU1", ANTNUM=6, ANT1CN=0,
ANT1SRN=61, ANT1SN=0, ANT1N=R0A, ANT2CN=0, ANT2SRN=61, ANT2SN=0, ANT2N=R0B,
ANT3CN=0, ANT3SRN=61, ANT3SN=0, ANT3N=R0C, ANT4CN=0, ANT4SRN=61, ANT4SN=0,
ANT4N=R0D, ANT5CN=0, ANT5SRN=61, ANT5SN=0, ANT5N=R0E, ANT6CN=0, ANT6SRN=61,
ANT6SN=0, ANT6N=R0F, CREATESECTOREQM=TRUE, SECTOREQMID=61;
ADD SECTOR: SECTORID=71, SECNAME="CPRI0_RHUB2_pRRU1", ANTNUM=6, ANT1CN=0,
ANT1SRN=71, ANT1SN=0, ANT1N=R0A, ANT2CN=0, ANT2SRN=71, ANT2SN=0, ANT2N=R0B,
ANT3CN=0, ANT3SRN=71, ANT3SN=0, ANT3N=R0C, ANT4CN=0, ANT4SRN=71, ANT4SN=0,
ANT4N=R0D, ANT5CN=0, ANT5SRN=71, ANT5SN=0, ANT5N=R0E, ANT6CN=0, ANT6SRN=71,
ANT6SN=0, ANT6N=R0F, CREATESECTOREQM=TRUE, SECTOREQMID=71;
//(Optional) If a cell requires binding to a piece of baseband equipment, add the
baseband equipment.
ADD BASEBANDEQM:
BASEBANDEQMID=0,UMTSDEMMODE=NULL,BASEBANDEQMTYPE=ULDL,SN1=2,SN2=1;
//(Optional) If no operator has been added, add an operator.
ADD CNOPERATOR: CnOperatorId=0, CnOperatorName="mobile",
CnOperatorType=CNOPERATOR_PRIMARY, Mcc="460", Mnc="01";
//(Optional) If no tracking area has been added, add a tracking area.
ADD CNOPERATORTA: TrackingAreaId=0, CnOperatorId=0, Tac=33,
NbIotTaFlag=BOOLEAN_TRUE;
//Set MME capability information for NB-IoT, for example, whether to support user
plane CIoT EPS optimization and whether to support LTE FDD and LTE TDD.
ADD MMECAPINFO: MmeCapCfgId=0, S1CfgType= S1_CFG, S1Id=0, NbCiotEpsOptCap=CP_UP,
NbLteSupportCap=SUPPORT;
//(Optional) For user plane CIoT EPS optimization, add an RLC/PDCP parameter
group.
ADD RLCPDCPPARAGROUP: RlcPdcpParaGroupId=130, CatType=NBIOT, RlcMode=RlcMode_AM,
UlDlDiscardtimerSwitch=OFF, NbEnodebMaxRetxThreshold=Maxretx_Threshold_t32,
NbUeMaxRetxThreshold=Maxretx_Threshold_t32;
//(Optional) For user plane CIoT EPS optimization, add the mapping relationships
between non-GBR service QCIs and RLC/PDCP parameter groups.
MOD QCIPARA: Qci=5, NbRlcPdcpParaGroupId=130;

eRAN

//Add an NB-IoT cell, for example, with the local cell ID of 0. Set the
MultiRruCellMode parameter to MPRU_AGGREGATION.
ADD CELL: LocalCellId=0, CellName="NB-IOT", NbCellFlag=TRUE,
CoverageLevelType=COVERAGE_LEVEL_0-1&COVERAGE_LEVEL_1-1&COVERAGE_LEVEL_2-1,
CellId=0, PhyCellId=213, FddTddInd=CELL_FDD, EuCellStandbyMode=ACTIVE,
CustomizedBandWidthCfgInd=NOT_CFG, EmergencyAreaIdCfgInd=NOT_CFG,
UePowerMaxCfgInd=NOT_CFG, MultiRruCellFlag=BOOLEAN_TRUE,
MultiRruCellMode=MPRU_AGGREGATION, TxRxMode=2T2R;
//(Optional) In LTE in-band deployment, reserve LTE FDD PRBs for NB-IoT. For
example, the LTE FDD cell bandwidth is 20 MHz; downlink PRB 44 and uplink PRB 0
are reserved for NB-IoT deployment.
ADD CELLRBRESERVE: LocalCellId=1, Index=0, RbRsvMode=NB_DEPLOYMENT,
RbRsvType=DOWNLINK_MODE, RbRsvStartIndex=44, RbRsvEndIndex=44;
RbRsvType=UPLINK_MODE, RbRsvStartIndex=0, RbRsvEndIndex=0;
//(Optional) In LTE in-band deployment, add a PRB for the NB-IoT cell. For
example, the frequency band is band 8, the uplink EARFCN is 21511, and the
downlink EARFCN is 3590.
ADD PRB: LocalCellId=0, PrbId=0, DeployMode=IN_BAND, FreqBand=8,
UlEarfcnCfgInd=CFG, UlEarfcn=21511, UlFreqOffset=NEG_2, DlEarfcn=3590,
DlFreqOffset=POS_0, LteCellId=1;
//(Optional) In standalone deployment, configure a PRB for the NB-IoT cell.
ADD PRB: LocalCellId=0,PrbId=0,DeployMode=STAND_ALONE,FreqBand=8,
UlEarfcnCfgInd=NOT_CFG, DlEarfcn=3600,DlFreqOffset=NEG_0DOT5;
//(Optional) In LTE guard band deployment, configure a PRB for the NB-IoT cell.
ADD PRB: LocalCellId=0,PrbId=0,DeployMode=GUARD_BAND,FreqBand=8,
UlEarfcnCfgInd=NOT_CFG, DlEarfcn=3552,DlFreqOffset=NEG_2, LteBandWidth=
LTE_SYSTEM_BW_10M,LteDlEarfcn=3600;
//(Optional) Configure an uplink intra-PRB guard band.
MOD ULGUARDBANDCFG: LocalCellId=0, PrbId=0, HighFreqGuardBand=0,
LowFreqGuardBand=0, NprachNpuschGuardBand=4;
//Add a sector equipment group and baseband equipment for the anchor carrier. Add
the corresponding PRB sector equipment to the group.
ADD EUPRBSECTOREQMGROUP: LocalCellId=0, PrbId=0, SectorEqmGroupId=0,
BaseBandEqmId=0;
ADD PRBSECTOREQMGRPITEM: LocalCellId=0, SectorEqmId=61, PrbId=0,
SectorEqmGroupId=0;
ADD PRBSECTOREQMGRPITEM: LocalCellId=0, SectorEqmId=71, PrbId=0,
SectorEqmGroupId=0;
//Add an operator to the cell.
ADD CELLOP: LocalCellId=0, TrackingAreaId=0;
//Set cell reference signal power based on the NB-IoT deployment mode and pRRU
power specifications.
MOD PDSCHCFG: LocalCellId=0, ReferenceSignalPwr=-21;
//Set RACH parameters.
MOD RACHCFG: LocalCellId=0,
PreambInitRcvTargetPwr=DBM_112,NbCyclicPrefixLength=66DOT7,
NbRsrpFirstThreshold=-110, NbRsrpSecondThreshold=-120,
PrachStartTimeCfgInd=NOT_CFG;
//Set PRACH parameters for the three coverage levels.
MOD
CELLRACHCECFG:LocalCellId=0,CoverageLevel=0,ContentionResolutionTimer=PP_8,MaxNumP
reambleAttempt=REP_4, RaResponseWindowSize=PP5;
MOD
CELLRACHCECFG:LocalCellId=0,CoverageLevel=1,ContentionResolutionTimer=PP_8,MaxNumP
reambleAttempt=REP_4, RaResponseWindowSize=PP5;
MOD
CELLRACHCECFG:LocalCellId=0,CoverageLevel=2,ContentionResolutionTimer=PP_32,MaxNum
PreambleAttempt=REP_4, RaResponseWindowSize=PP5;
MOD
PRBRACHCECONFIG:LocalCellId=0,PrbId=0,CoverageLevel=0,PrachStartTime=SF8,PrachTran
smissionPeriod=SF640,PrachSubcarrierOffset=SC36,PrachSubcarrierNumber=SC_NUM_12,Pr
achRepetitionCount=REP_2,PrachDetectionThld=LEVEL_3;
MOD
PRBRACHCECONFIG:LocalCellId=0,PrbId=0,CoverageLevel=1,PrachStartTime=SF64,PrachTra
nsmissionPeriod=SF640,PrachSubcarrierOffset=SC36,PrachSubcarrierNumber=SC_NUM_12,P
rachRepetitionCount=REP_8,PrachDetectionThld=LEVEL_2;
MOD

eRAN
PRBRACHCECONFIG:LocalCellId=0,PrbId=0,CoverageLevel=2,PrachStartTime=SF128,PrachTr
ansmissionPeriod=SF640,PrachSubcarrierOffset=SC36,PrachSubcarrierNumber=SC_NUM_12,
PrachRepetitionCount=REP_32,PrachDetectionThld=LEVEL_0;
//Adjust the uplink power control parameters of the NB-IoT cell.
MOD CELLULPCCOMM: LocalCellId=0, PassLossCoeff=AL1, P0NominalPUSCH=-105;
//(Optional) To enable DRX for UEs in connected mode, turn on the DRX switch.
MOD CELLDRXPARA:LOCALCELLID=0, DrxAlgSwitch=ON;
//(Optional) Set DRX parameters.
MOD CELLDRXPARA: LocalCellId=0, NbDrxInactivityTimer=PP3, NbDrxReTxTimer=PP4,
NbDrxUlReTxTimer=PP4, NbLongDrxCycle=SF2048, NbOnDurationTimer=PP3;
//Set cell selection parameters.
MOD CELLSEL: LocalCellId=0, QRxLevMin=-70, QQualMin=-23;
//(Optional) Set cell reselection parameters.
MOD CELLRESEL: LocalCellId=0, Qhyst=DB2_Q_HYST, SNonIntraSearchCfgInd=CFG,
SNonIntraSearch=9, QRxLevMin=-65, PMaxCfgInd=CFG, PMax=-27,
SIntraSearchCfgInd=CFG, SIntraSearch=29, TReselForNb=5, TReselInterFreqForNb=6;
//(Optional) To support the reselection of an intra- or inter-frequency NB-IoT
cell, set this cell as an external cell.
ADD EUTRANEXTERNALCELL: Mcc="460", Mnc="20", eNodeBId=255, CellId=1, NbCellFlag
=TRUE, DlEarfcn=3000, DlFreqOffset=NEG_0DOT5, UlEarfcnCfgInd=CFG, UlEarfcn=21000,
UlFreqOffset=POS_0, PhyCellId=1, Tac=1;
//(Optional) To support the reselection of an intra-frequency NB-IoT cell, add a
neighbor relationship with this cell.
ADD EUTRANINTRAFREQNCELL: LocalCellId=0, Mcc="460", Mnc="20", eNodeBId=255,
CellId=1, CellIndividualOffset=dB1, CellQoffset=dB1;
//(Optional) To support the reselection of cells on another NB-IoT frequency, add
the frequency.
ADD EUTRANINTERNFREQ: LocalCellId=0, DlEarfcn=3106,
DlFreqOffset=NEG_0DOT5,UlEarfcnCfgInd=CFG, UlEarfcn=21106, UlFreqOffset=POS_0,
MeasBandwidth=MBW50, QoffsetFreq=dB2, QRxlevmin=-64, PmaxCfgInd=CFG, Pmax=23;
//(Optional) To support the reselection of an inter-frequency NB-IoT cell, add a
ADD EUTRANINTERFREQNCELL: LocalCellId=0, Mcc="460", Mnc="20", eNodeBId=2,
CellId=1, CellQoffset=dB2;
//Enable the backoff function.
MOD CELLALGOSWITCH:LOCALCELLID=0, RachAlgoSwitch=BackOffSwitch-1;
//(Optional) If some UEs on the live network do not support the maximum backoff
index 12 defined in 3GPP TS 36.321 R13, turn on PreambleSchEnhSwitch.
MOD CELLALGOSWITCH: LocalCellId=0, UlSchExtSwitch=PreambleSchEnhSwitch-1;
//(Optional) Turn on the UTC broadcast switch.
MOD CELLALGOSWITCH:LOCALCELLID=0, LteUtcBroadcastSwitch=ON;
//(Optional) Enable SI offset adaptation.
MOD CELLALGOSWITCH:LOCALCELLID=0,
NbCellAlgoSwitch=SI_OFFSET_ADAPTIVE_CFG_SWITCH-1;
//(Optional) If the air interface is congested, enable random access flow control
and allow the RRC Connection Release message to carry the extendedWaitTime IE.
MOD CELLALGOSWITCH: LocalCellId=0, UlSchSwitch=UlRaUserSchOptSw-1,
MTCCongControlSwitch=ExtendedwaittimeSwitch-1;
//(Optional) Enable the access barring function.
MOD CELLALGOSWITCH:LOCALCELLID=0,MTCCongControlSwitch=EABAlgoSwitch-1;
//(Optional) Optimize the dynamic access barring policy mode.
MOD ENODEBFLOWCTRLPARA: DynAcBarPolicyMode=FLOWCONTROL;
//(Optional) If the access barring function is enabled, set access barring
control parameters.
MOD CELLEABALGOPARA: LocalCellId=0, EABTriggerThd=80, EABStatPeriod=30,
EABCategory=CATEGORY_A, EABCancelThd=50, EABCancelCondSatiPeriod=1,
ABForExceptionData=BOOLEAN_TRUE,
ABForSpecialAC=AC11BARSTATE-1&AC12BARSTATE-1&AC13BARSTATE-1&AC14BARSTATE-1&AC15BAR
STATE-1;
//(Optional) If the access barring function is enabled, allow manual access
barring.
MOD CELLEABALGOPARA: LocalCellId=0, ACCountForManualBarring=1;
//(Optional) Set the maximum number of UEs that can be admitted to an NB-IoT cell.
MOD CELLRACTHD: LocalCellId=0, AcUserNumber=600;
//(Optional) When NB-IoT and LTE FDD are co-sited, you can allow LTE FDD UEs to
preempt the RRC connections of NB-IoT UEs.
MOD ENODEBALGOSWITCH: LTEPreemptNbSwitch=ON;
//(Optional) When NB-IoT and LTE FDD are co-sited, you can allow NB-IoT UEs to
preempt each other.

eRAN
MOD ENODEBALGOSWITCH: UeNumPreemptSwitch=NbUeNumPreemptSwitch-1;

//(Optional) After allowing LTE FDD UEs to preempt the RRC connections of NB-IoT
UEs, you can reserve a minimum number of RRC connections for NB-IoT UEs.
MOD ENODEBNBPARA: NbRsvMinUserNumRatio=10;
//(Optional) When NB-IoT and LTE FDD are co-sited, set an eNodeB frame offset.
MOD ENODEBFRAMEOFFSET: FDDFrameOffset=0;
//(Optional) When NB-IoT and LTE FDD are co-sited, set a cell frame offset.
ADD CELLFRAMEOFFSET: LocalCellId=0, FrameOffsetMode=CustomFrameOffset,
FrameOffset=0;
//Activate the NB-IoT cell.
ACT CELL: LocalCellId=0;
7.1.2.2 Activation Command Examples (for Base Stations Other Than DBS3900
LampSite and DBS5900 LampSite)
//Set an MME compliance protocol release.
MOD S1INTERFACE:S1INTERFACEID=0,MMERELEASE=Release_R13;
MOD S1: S1Id=0,MMERELEASE=Release_R13;
//(Optional) For a newly installed RRU, add a sector and a piece of sector
equipment. If the CREATESECTOREQM parameter is set to TRUE, the sector equipment
will be automatically added when the sector is added.
//Add a sector. For example, if the cell TX/RX mode is 1T2R, the ANTNUM parameter
must be set to 2.
ADD SECTOR: SECTORID=0, ANTNUM=2, ANT1CN=0, ANT1SRN=60, ANT1SN=0, ANT1N=R0A,
ANT2CN=0, ANT2SRN=60, ANT2SN=0, ANT2N=R0B, CREATESECTOREQM=TRUE, SECTOREQMID=0;
//(Optional) If a cell requires binding to a piece of baseband equipment, add the
baseband equipment.
ADD BASEBANDEQM:
BASEBANDEQMID=0,UMTSDEMMODE=NULL,BASEBANDEQMTYPE=ULDL,SN1=2,SN2=1;
//(Optional) If no operator has been added, add an operator.
ADD CNOPERATOR: CnOperatorId=0, CnOperatorName="mobile",
CnOperatorType=CNOPERATOR_PRIMARY, Mcc="460", Mnc="01";
//(Optional) If no tracking area has been added, add a tracking area.
ADD CNOPERATORTA: TrackingAreaId=0, CnOperatorId=0, Tac=33,
NbIotTaFlag=BOOLEAN_TRUE;
//Set MME capability information for NB-IoT, for example, whether to support user
plane CIoT EPS optimization and whether to support LTE FDD and LTE TDD.
ADD MMECAPINFO: MmeCapCfgId=0, S1CfgType= S1_CFG, S1Id=0, NbCiotEpsOptCap=CP_UP,
NbLteSupportCap=SUPPORT;
//(Optional) For user plane CIoT EPS optimization, add an RLC/PDCP parameter
group.
ADD RLCPDCPPARAGROUP: RlcPdcpParaGroupId=130, CatType=NBIOT, RlcMode=RlcMode_AM,
UlDlDiscardtimerSwitch=OFF, NbEnodebMaxRetxThreshold=Maxretx_Threshold_t32,
NbUeMaxRetxThreshold=Maxretx_Threshold_t32;
//(Optional) For user plane CIoT EPS optimization, add the mapping relationships
between non-GBR service QCIs and RLC/PDCP parameter groups.
//Add an NB-IoT cell, for example, with the local cell ID of 0.
ADD CELL: LocalCellId=0, CellName="NBCell0", NbCellFlag=TRUE,
CoverageLevelType=COVERAGE_LEVEL_0-1&COVERAGE_LEVEL_1-1&COVERAGE_LEVEL_2-1,
CellId=0, PhyCellId=0, FddTddInd=CELL_FDD, EuCellStandbyMode=ACTIVE,
CustomizedBandWidthCfgInd=NOT_CFG, EmergencyAreaIdCfgInd=NOT_CFG,
UePowerMaxCfgInd=NOT_CFG, MultiRruCellFlag=BOOLEAN_FALSE, TxRxMode=1T1R,
UserLabel="NBCell0";
//(Optional) In LTE in-band deployment, reserve LTE FDD PRBs for NB-IoT. For
example, the LTE FDD cell bandwidth is 20 MHz; downlink PRB 44 and uplink PRB 0
are reserved for NB-IoT deployment.
RbRsvType=DOWNLINK_MODE, RbRsvStartIndex=44, RbRsvEndIndex=44;
RbRsvType=UPLINK_MODE, RbRsvStartIndex=0, RbRsvEndIndex=0;
//(Optional) In LTE in-band deployment, add a PRB for the NB-IoT cell. For
example, the frequency band is band 8, the uplink EARFCN is 21511, and the
downlink EARFCN is 3590.
ADD PRB: LocalCellId=0, PrbId=0, DeployMode=IN_BAND, FreqBand=8,

eRAN
UlEarfcnCfgInd=CFG, UlEarfcn=21511, UlFreqOffset=NEG_2, DlEarfcn=3590,

DlFreqOffset=POS_0, LteCellId=1;
//(Optional) In standalone deployment, configure a PRB for the NB-IoT cell.
ADD PRB: LocalCellId=0,PrbId=0,DeployMode=STAND_ALONE,FreqBand=8,
UlEarfcnCfgInd=NOT_CFG, DlEarfcn=3600,DlFreqOffset=NEG_0DOT5;
//(Optional) In LTE guard band deployment, configure a PRB for the NB-IoT cell.
ADD PRB: LocalCellId=0,PrbId=0,DeployMode=GUARD_BAND,FreqBand=8,
UlEarfcnCfgInd=NOT_CFG, DlEarfcn=3552,DlFreqOffset=NEG_2, LteBandWidth=
LTE_SYSTEM_BW_10M,LteDlEarfcn=3600;
//(Optional) Configure an uplink intra-PRB guard band.
MOD ULGUARDBANDCFG: LocalCellId=0, PrbId=0, HighFreqGuardBand=0,
LowFreqGuardBand=0, NprachNpuschGuardBand=4;
//Bind the sector equipment and baseband equipment to the PRB of the anchor
carrier.
ADD EUPRBSECTOREQM: LocalCellId=0, PrbId=0, SectorEqmId=0, BaseBandEqmId=0;
//Add an operator to the cell.
ADD CELLOP: LocalCellId=0, TrackingAreaId=0;
//Set the reference signal power for the cell.
MOD PDSCHCFG: LocalCellId=0, ReferenceSignalPwr=272;
//Set RACH parameters.
MOD RACHCFG: LocalCellId=0,
PreambInitRcvTargetPwr=DBM_112,NbCyclicPrefixLength=66DOT7,
NbRsrpFirstThreshold=-110, NbRsrpSecondThreshold=-120,
PrachStartTimeCfgInd=NOT_CFG;
//Set PRACH parameters for the three coverage levels.
MOD CELLRACHCECFG:LocalCellId=0,CoverageLevel=0,ContentionResolutionTimer=
PP_8,MaxNumPreambleAttempt=REP_4, RaResponseWindowSize=PP5;
MOD
PRBRACHCECONFIG:LocalCellId=0,PrbId=0,CoverageLevel=0,PrachStartTime=SF8,PrachTran
smissionPeriod=SF640,PrachSubcarrierOffset=SC36,PrachSubcarrierNumber=SC_NUM_12,Pr
achRepetitionCount=REP_2,PrachDetectionThld=LEVEL_3;
MOD
PRBRACHCECONFIG:LocalCellId=0,PrbId=0,CoverageLevel=1,PrachStartTime=SF64,PrachTra
nsmissionPeriod=SF640,PrachSubcarrierOffset=SC36,PrachSubcarrierNumber=SC_NUM_12,P
rachRepetitionCount=REP_8,PrachDetectionThld=LEVEL_2;
MOD
PRBRACHCECONFIG:LocalCellId=0,PrbId=0,CoverageLevel=2,PrachStartTime=SF128,PrachTr
ansmissionPeriod=SF640,PrachSubcarrierOffset=SC36,PrachSubcarrierNumber=SC_NUM_12,
PrachRepetitionCount=REP_32,PrachDetectionThld=LEVEL_0;
//Adjust the uplink power control parameters of the NB-IoT cell.
MOD CELLULPCCOMM: LocalCellId=0, PassLossCoeff=AL1, P0NominalPUSCH=-105;
//(Optional) To enable DRX for UEs in connected mode, turn on the DRX switch.
MOD CELLDRXPARA:LOCALCELLID=0, DrxAlgSwitch=ON;
//(Optional) Set DRX parameters.
MOD CELLDRXPARA: LocalCellId=0, NbDrxInactivityTimer=PP3, NbDrxReTxTimer=PP4,
NbDrxUlReTxTimer=PP4, NbLongDrxCycle=SF2048, NbOnDurationTimer=PP3;
//Set cell selection parameters.
MOD CELLSEL: LocalCellId=0, QRxLevMin=-70, QQualMin=-23;
//(Optional) Set cell reselection parameters.
MOD CELLRESEL: LocalCellId=0, Qhyst=DB2_Q_HYST, SNonIntraSearchCfgInd=CFG,
SNonIntraSearch=9, QRxLevMin=-65, PMaxCfgInd=CFG, PMax=-27,
SIntraSearchCfgInd=CFG, SIntraSearch=29, TReselForNb=5, TReselInterFreqForNb=6;
//(Optional) To support the reselection of an intra- or inter-frequency NB-IoT
cell, set this cell as an external cell.
ADD EUTRANEXTERNALCELL: Mcc="460", Mnc="20", eNodeBId=255, CellId=1, NbCellFlag
=TRUE, DlEarfcn=3000, DlFreqOffset=NEG_0DOT5, UlEarfcnCfgInd=CFG, UlEarfcn=21000,
UlFreqOffset=POS_0, PhyCellId=1, Tac=1;
//(Optional) To support the reselection of an intra-frequency NB-IoT cell, add a
ADD EUTRANINTRAFREQNCELL: LocalCellId=0, Mcc="460", Mnc="20", eNodeBId=255,
CellId=1, CellIndividualOffset=dB1, CellQoffset=dB1;
//(Optional) To support the reselection of cells on another NB-IoT frequency, add
the frequency.

eRAN
ADD EUTRANINTERNFREQ: LocalCellId=0, DlEarfcn=3106,

DlFreqOffset=NEG_0DOT5,UlEarfcnCfgInd=CFG, UlEarfcn=21106, UlFreqOffset=POS_0,
MeasBandwidth=MBW50, QoffsetFreq=dB2, QRxlevmin=-64, PmaxCfgInd=CFG, Pmax=23;
//(Optional) To support the reselection of an inter-frequency NB-IoT cell, add a
ADD EUTRANINTERFREQNCELL: LocalCellId=0, Mcc="460", Mnc="20", eNodeBId=2,
CellId=1, CellQoffset=dB2;
//Enable the backoff function.
MOD CELLALGOSWITCH:LOCALCELLID=0, RachAlgoSwitch=BackOffSwitch-1;
//(Optional) If some UEs on the live network do not support the maximum backoff
index 12 defined in 3GPP TS 36.321 R13, turn on PreambleSchEnhSwitch.
MOD CELLALGOSWITCH: LocalCellId=0, UlSchExtSwitch=PreambleSchEnhSwitch-1;
//(Optional) Turn on the UTC broadcast switch.
MOD CELLALGOSWITCH:LOCALCELLID=0, LteUtcBroadcastSwitch=ON;
//(Optional) Enable SI offset adaptation.
MOD CELLALGOSWITCH:LOCALCELLID=0,
NbCellAlgoSwitch=SI_OFFSET_ADAPTIVE_CFG_SWITCH-1;
//(Optional) If the air interface is congested, enable random access flow control
and allow the RRC Connection Release message to carry the extendedWaitTime IE.
MOD CELLALGOSWITCH: LocalCellId=0, UlSchSwitch=UlRaUserSchOptSw-1,
MTCCongControlSwitch=ExtendedwaittimeSwitch-1;
//(Optional) Enable the access barring function.
MOD CELLALGOSWITCH:LOCALCELLID=0,MTCCongControlSwitch=EABAlgoSwitch-1;
//(Optional) Optimize the dynamic access barring policy mode.
MOD ENODEBFLOWCTRLPARA: DynAcBarPolicyMode=FLOWCONTROL;
//(Optional) If the access barring function is enabled, set access barring
control parameters.
MOD CELLEABALGOPARA: LocalCellId=0, EABTriggerThd=80, EABStatPeriod=30,
EABCategory=CATEGORY_A, EABCancelThd=50, EABCancelCondSatiPeriod=1,
ABForExceptionData=BOOLEAN_TRUE,
ABForSpecialAC=AC11BARSTATE-1&AC12BARSTATE-1&AC13BARSTATE-1&AC14BARSTATE-1&AC15BAR
STATE-1;
//(Optional) If the access barring function is enabled, allow manual access
barring.
MOD CELLEABALGOPARA: LocalCellId=0, ACCountForManualBarring=1;
//(Optional) Set the maximum number of UEs that can be admitted to an NB-IoT cell.
MOD CELLRACTHD: LocalCellId=0, AcUserNumber=600;
//(Optional) When NB-IoT and LTE FDD are co-sited, you can allow LTE FDD UEs to
preempt the RRC connections of NB-IoT UEs.
MOD ENODEBALGOSWITCH: LTEPreemptNbSwitch=ON;
//(Optional) When NB-IoT and LTE FDD are co-sited, you can allow NB-IoT UEs to
preempt each other.
MOD ENODEBALGOSWITCH: UeNumPreemptSwitch=NbUeNumPreemptSwitch-1;
//(Optional) After allowing LTE FDD UEs to preempt the RRC connections of NB-IoT
UEs, you can reserve a minimum number of RRC connections for NB-IoT UEs.
MOD ENODEBNBPARA: NbRsvMinUserNumRatio=10;
//(Optional) When NB-IoT and LTE FDD are co-sited, set an eNodeB frame offset.
MOD ENODEBFRAMEOFFSET: FDDFrameOffset=0;
//(Optional) When NB-IoT and LTE FDD are co-sited, set a cell frame offset.
ADD CELLFRAMEOFFSET: LocalCellId=0, FrameOffsetMode=CustomFrameOffset,
FrameOffset=0;
//(Optional) If repeaters are used to amplify the RRU output power and the NB-IoT
cell is deployed in LTE in-band mode, turn on the antenna reference signal power
switch for both the NB-IoT cell and the LTE FDD cell, set the proportion of NB-
IoT cell output power to 0, and set the proportion of LTE FDD cell output power
to 0.
MOD CELLALGOSWITCH: LocalCellId=0, RepeaterSwitch=AntRsPwrSwitch-1;
MOD CELLCHPWRCFG: LocalCellId=0, AntOutputPwr=20, OutputPowerRate=0;
//(Optional) If repeaters are used to amplify the RRU output power and the NB-IoT
cell is deployed in standalone or LTE guard band mode, turn on the antenna
reference signal power switch for the NB-IoT cell and set the proportion of NB-
IoT cell output power to 1000.
//Activate the NB-IoT cell.
ACT CELL: LocalCellId=0;

eRAN
7.1.2.3 Optimization Command Examples

//(Optional) Optimize paging over the air interface.
MOD PCCHCFG: LocalCellId=0, PagingStrategy=PAGING_STRATEGY_DIFFPRI,
DefaultPagingCycleForNb=rf512, NbForNbIoT=ONE_64TH_T;
MOD PrbSchConfig: LocalCellId=0, PrbId=0, MaxNumRepetitionForPaging=REP_32;
//(Optional) Adjust the S1 default paging DRX value for NB-IoT.
MOD GLOBALPROCSWITCH: S1DefaultPagingDrxForNb=512;
//(Optional) Adjust UE control timers.
MOD RRCCONNSTATETIMER: NbUeInactiveTimer=30;
//(Optional) Adjust the Uu message waiting timer.
MOD ENODEBCONNSTATETIMER: S1MessageWaitingTimer=20, UuMessageWaitingTimer=35;
//(Optional) To optimize NPDCCH resource allocation based on coverage levels in
the NB-IoT cell, set NPDCCH information for the three coverage levels.
MOD PRBPDCCHCECONFIG: LocalCellId=0, PrbId=0, CoverageLevel=0,
PdcchMaxRepetitionCnt=REP_8,PdcchPeriodFactor=G_2,PdcchTransRptCntFactor=ONER_EIGH
TR,PdcchOffset=0;
PdcchMaxRepetitionCnt=REP_16,PdcchPeriodFactor=G_2,PdcchTransRptCntFactor=ONER_EIG
HTR,PdcchOffset=0;
PdcchMaxRepetitionCnt=REP_32,PdcchPeriodFactor=G_2,PdcchTransRptCntFactor=QUARTERR
,PdcchOffset=0;
//(Optional) To optimize uplink scheduling based on coverage levels in the NB-IoT
cell, set uplink scheduling information for the three coverage levels.
MOD PRBULSCHCEALGO: LocalCellId=0, PrbId=0, CoverageLevel=0,
UlInitialMcs=MCS_9,UlInitialTransRptCount=REP_1,AckNackTransRptCount=REP_2,AckNack
TransRptCountMsg4=REP_4;
UlInitialMcs=MCS_0,UlInitialTransRptCount=REP_2,AckNackTransRptCount=REP_4,AckNack
TransRptCountMsg4=REP_8;
UlInitialMcs=MCS_0,UlInitialTransRptCount=REP_32,AckNackTransRptCount=REP_32,AckNa
ckTransRptCountMsg4=REP_64;
//(Optional) To optimize downlink scheduling based on coverage levels in the NB-
IoT cell, set downlink scheduling information and the Uu message waiting timer
for the three coverage levels.
MOD PRBDLSCHCEALGO: LocalCellId=0, PrbId=0, CoverageLevel=0,
DlInitialTransRptCount=REP_1, DlInitialMcs=MCS_10, UuMessageWaitingTimer=35;
//(Optional) Optimize the downlink gap scheme for coverage level 2.
PdcchMaxRepetitionCnt=REP_32,PdcchPeriodFactor=G_8;
MOD PRBSCHCONFIG: LocalCellId=0, PrbId=0, DlSchedulingSwitch=DL_GAP_SWITCH-1;
MOD PRBDLGAPCONFIG: LocalCellId=0, PrbId=0, DlGapThreshold=N_32,
DlGapPeriod=SF256, DlGapDurationCoeff=ONE_EIGHTH;
//(Optional) Enable downlink MCS adjustment step and NPDCCH offset adaptation.
MOD CELLALGOSWITCH: LocalCellId =0,
NbCellAlgoSwitch=ADAPTIVE_STEP_SWITCH-1&NPDCCH_OFFSET_ADAPTIVE_SWITCH-1;
//(Optional) Optimize downlink AMC and improve release signaling performance.
MOD CELLALGOEXTSWITCH: LocalCellId =0,
NbCellAlgoExtSwitch=DL_AMC_OPT_SWITCH-1&RELEASE_PERFM_IMPROVE_SWITCH-1;
//(Optional) Optimize uplink AMC.
MOD CELLALGOSWITCH: LocalCellId =0, UlSchExtSwitch=UlPAMCSwitch-1;
//(Optional) Enable uplink interference randomization.
MOD CellUlschAlgo: LocalCellId =0, UlInterfRandomMode=THREE_MODE_BASED_ON_PCI;
//(Optional) Optimize dedicated parameters related to power control on the NPUSCH.
MOD CELLULPCDEDIC: LocalCellId=0, FilterRsrp=UU_FC6_FILTER_COEFF;
//(Optional) Optimize system information mapping relationships.
MOD CELLSIMAP: LocalCellId=0, NbSib1RepetitionNum=16, NbSib2Period=RF512,
NbSib3Period=RF2048;
//(Optional) Set different inactivity timer values for different service types.
//Turn on the UE information retrieval switch.
MOD CELLALGOSWITCH:LocalCellId=0, NbCellAlgoSwitch= RETRIEVE_UE_INFO_SWITCH-1;
//For services sensitive to power consumption (for example, QCI 5 services)
MOD QCIPARA: Qci=5, NbUeInactivityTimerForQci = 20;
//For services insensitive to power consumption but sensitive to delay (for

eRAN
example, QCI 6 services)

MOD QCIPARA: Qci=6, NbUeInactivityTimerForQci = 60;
//(Optional) Enable uplink reverse RU adjustment.
MOD CELLALGOSWITCH: LocalCellId =0, UlSchSwitch=UlSmallRBSpectralEffOptSw-1;
7.1.2.4 Deactivation Command Examples

//To deactivate the NB-IoT function, you are advised to deactivate the NB-IoT
cell because the NB-IoT function cannot be deactivated using a function switch.
DEA CELL: LocalCellId=0;
7.1.3 Using the CME

For detailed operations, see CME-based Feature Configuration.
In LTE in-band deployment, ensure that the LTE FDD cell has been activated before
activating an NB-IoT cell.
7.2 Activation Verification

Step 1 Run the DSP CELL command to check cell status.
If the value of the Cell instance state parameter is Normal, the cell has been activated.
Step 2 Use a UE to access the cell.
If the UE successfully accesses the cell, the cell is working properly.
----End
7.3 Network Monitoring

After deploying NB-IoT, observe KPIs such as the access success rate, service drop rate, and
residual BLER (RBLER). In addition, observe counters related to, for example, the number of
UEs, throughput, and paging.
l Access success rate
RRC Setup Success Rate (NB-IoT)
RRC Resume Success Rate (NB-IoT)
l Service drop rate
Service Drop Rate (NB-IoT)
l RBLER
Uplink Residual Block Error Rate (NB-IoT)
Downlink Residual Block Error Rate (NB-IoT)
l Number of UEs
L.NB.Traffic.User.Avg
L.NB.Traffic.User.Avg.CoverageLevel0
L.NB.Traffic.User.Avg.CoverageLevel1
L.NB.Traffic.User.Max
L.NB.Traffic.User.Max.CoverageLevel0

eRAN
l Throughput
– Uplink UE throughput
Formula: L.NB.Thrp.bits.UL / L.NB.Thrp.Time.UL
– Downlink UE throughput
Formula: L.NB.Thrp.bits.DL / L.NB.Thrp.Time.DL
l Paging
Counter Name Counter Description
L.NB.Paging.S1.Rx This counter measures the number of paging messages

received over the S1 interface in a cell. This counter
reflects the signaling overhead brought by UEs in idle
mode.
L.NB.Paging.UU.Succ Paging success rate = L.NB.Paging.UU.Succ /

L.NB.Paging.UU.Att
L.NB.Paging.UU.Att
NOTE
NB-IoT UEs have low mobility. Generally, they are stationary
in a cell. The EPC preferentially sends paging messages to the
cell. Therefore, the paging success rate of the cell can be
estimated using the preceding formula.
If a paging fails, the EPC sends the paging messages to other
cells or eNodeBs. If this occurs frequently, the preceding
formula cannot be used to estimate the paging success rate.
The accurate paging success rate can be obtained from the
EPC.
L.NB.Paging.Dis.PchCong This counter measures the number of paging messages

discarded due to PCH congestion.
l DRX in connected mode

– The L.NB.Traffic.User.Cdrx.Avg counter can be used to measure the average
number of UEs that enter DRX mode.
– The L.NB.Active.Time and L.NB.Sleep.Time counters can be used to monitor the
UE power saving effect indirectly.
l Access barring
L.NB.AB.Trigger.Num
L.NB.AB.Cancel.Num
L.NB.AB.Adjust.Num
L.NB.AB.Control.Dur
l Optimization against NPRACH false detection
L.NB.RA.Att
L.NB.RA.Resp
L.NB.Thrp.bits.DL.Phy
L.NB.Thrp.bits.UL.Phy
L.NB.Traffic.DL.SCH.TB
L.NB.Traffic.DL.SCH.ErrTB.Rbler

eRAN
L.NB.Traffic.UL.SCH.TB
L.NB.Traffic.UL.SCH.ErrTB.Rbler

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 8 Parameters
8 Parameters
The following hyperlinked EXCEL files of parameter reference match the software version
with which this document is released.
l Node Parameter Reference: contains device and transport parameters.
l eNodeBFunction Parameter Reference: contains all parameters related to radio access
functions, including air interface management, access control, mobility control, and radio
resource management.
NOTE
You can find the EXCEL files of parameter reference for the software version on the live network from
the product documentation delivered with that version.
FAQ: How do I find the parameters related to a certain feature from parameter
reference?
Step 1 Open the EXCEL file of parameter reference.
Step 2 On the Parameter List sheet, filter the Feature ID column. Click Text Filters and choose
Contains. Enter the feature ID, for example, LOFD-001016 or TDLOFD-001016.
Step 3 Click OK. All parameters related to the feature are displayed.
----End

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 9 Counters
9 Counters
The following hyperlinked EXCEL files of performance counter reference match the software
version with which this document is released.
l Node Performance Counter Summary: contains device and transport counters.
l eNodeBFunction Performance Counter Summary: contains all counters related to radio
access functions, including air interface management, access control, mobility control,
and radio resource management.
NOTE
You can find the EXCEL files of performance counter reference for the software version used on the live
network from the product documentation delivered with that version.
FAQ: How do I find the counters related to a certain feature from performance counter
reference?
Step 1 Open the EXCEL file of performance counter reference.
Step 2 On the Counter Summary(En) sheet, filter the Feature ID column. Click Text Filters and
choose Contains. Enter the feature ID, for example, LOFD-001016 or TDLOFD-001016.
Step 3 Click OK. All counters related to the feature are displayed.
----End

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 10 Glossary
10 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 11 Reference Documents
11 Reference Documents
1. 3GPP TS 23.401, "General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access"
2. 3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for Evolved Packet System
(EPS); Stage 3"
3. 3GPP TS 36.101, "Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) radio transmission and reception"
4. 3GPP TS 36.104, "Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station
(BS) radio transmission and reception"
5. 3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation"
6. 3GPP TS 36.212, "Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
and channel coding"
7. 3GPP TS 36.213, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures"
8. 3GPP TS 36.300, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description"
Equipment (UE) procedures in idle mode"
Equipment (UE) radio access capabilities"
11. 3GPP TS 36.321, "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification"
12. 3GPP TS 36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification"
13. 3GPP TS 36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 Application Protocol (S1AP)"
14. 3GPP TS 36.802, "Evolved Universal Terrestrial Radio Access (E-UTRA); NB-IOT;
Technical Report for BS and UE radio transmission and reception"
15. License Control Item Lists (CIoT)
16. S1-flex
17. Scheduling
18. Base station technical description

eRAN
NB-IoT Basics (FDD) Feature Parameter Description 11 Reference Documents
19. Base station initial configuration guide

20. Base station alarm reference
21. eDRX in Idle Mode
22. Flow Control
23. Physical Channel Resource Management
24. Energy Conservation and Emission Reduction
25. CPRI Compression
26. LCS
27. Cell Management
28. Compact Bandwidth (FDD)
29. GSM and LTE Spectrum Concurrency
30. Admission and Congestion Control
31. CSPC
32. SFN
33. High Speed Mobility
34. VoLTE
35. ICIC
36. eMBMS
37. Extended CP
38. Extended Cell Range
39. Multi-RAT Carrier Joint Shutdown
40. NB-IoT Enhancements (FDD)
41. Idle Mode Management
42. S1-flex
43. UMTS and LTE Zero Bufferzone
44. eMTC
45. Super Combined Cell (FDD)
46. LTE and NR Spectrum Sharing
47. GSM and LTE Spectrum Concurrency

Nb-Iot Basics (FDD) (Eran15.1 - Draft A)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Nb-Iot Basics (FDD) (Eran15.1 - Draft A)

Încărcat de

Drepturi de autor:

Formate disponibile

eRAN

NB-IoT Basics (FDD) Feature

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. i

2 About This Document.................................................................................................................. 5

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. ii

4.3.4 NPRACH Detection Threshold................................................................................................................................. 40

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iii

4.8.2 Startup of a DRX Cycle.............................................................................................................................................84

7 Operation and Maintenance....................................................................................................116

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iv

11 Reference Documents............................................................................................................. 165

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. v

1.1 eRAN15.1 Draft A (2019-01-05)

Enabled the configuration of Added parameters: l 3900 and 5900 series

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 1

Change Description Parameter Change Base Station Model

Added the uplink reverse None l 3900 and 5900 series

Optimized cell selection and None l 3900 and 5900 series

Improved RRC connection Added parameters: l 3900 and 5900 series

Optimized uplink AMC. For None l 3900 and 5900 series

Optimized downlink AMC. Added parameters: l 3900 and 5900 series

Added the uplink None l 3900 and 5900 series

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 2

Change Description Parameter Change Base Station Model

Optimized the NPDCCH Modified parameters: l 3900 and 5900 series

Optimized uplink power Modified parameters: l 3900 and 5900 series

Retained the function of None l 3900 and 5900 series

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 3

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 4

2 About This Document

2.1 General Statements

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 5

Feature Differences Between RATs

2.2 Applicable RAT

2.3 Features in This Document

Feature ID Feature Name Section

MLBFD-120001 NB-IoT Network 3.1 NB-IoT Spectrum

MLBFD-12000101 Standalone Deployment 3.1 NB-IoT Spectrum

MLBFD-12000102 LTE Guardband 3.1 NB-IoT Spectrum

MLBFD-12000103 LTE In-band Deployment 3.1 NB-IoT Spectrum

MLBFD-120002 3GPP NB-IoT 4 Principles

MLBFD-12000202 Single-tone 3.2.4 Single-Tone Transmission

MLBFD-12000203 Support of NB-IoT UE 3.4 NB-IoT UE Requirements

MLBFD-12000204 Data over NAS 3.3.1 Data over NAS

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 6

Feature ID Feature Name Section

MLBFD-12000223 Physical Channel 3.2.1 Physical Layer

MLBFD-12000224 DL Asynchronous HARQ 4.5.4.4 Downlink Scheduling for

MLBFD-12000225 UL Asynchronous HARQ 4.5.3.4 Uplink Scheduling for

MLBFD-12000226 Modulation: DL QPSK, 3.2.1 Physical Layer

MLBFD-12000227 AMC 4.5.3.3 Uplink Scheduling for

4.5.4.3 Downlink Scheduling for

MLBFD-12000228 RRC Connection 4.4 Connection Management

MLBFD-12000229 Broadcast of system 4.2 Idle Mode Management

MLBFD-12000230 Random Access 4.3 Random Access

MLBFD-12000231 Paging 4.2 Idle Mode Management

MLBFD-12000232 Cell Access Radius up to 4.9 Cell Access Radius up to 35

MLBFD-12000233 Admission Control 4.7.1 Admission Control

MLBFD-12000234 Basic Scheduling 4.5 Scheduling

MLBFD-12000235 Uplink Power Control 4.6.2 Uplink Power Control