Beruflich Dokumente
Kultur Dokumente
Issue Draft A
Date 2019-01-05
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.
Website: http://www.huawei.com
Email: support@huawei.com
Contents
1 Change History.............................................................................................................................. 1
1.1 eRAN15.1 Draft A (2019-01-05)................................................................................................................................... 1
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
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
8 Parameters................................................................................................................................... 162
9 Counters...................................................................................................................................... 163
10 Glossary..................................................................................................................................... 164
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
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
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
Editorial Changes
This document is split from NB-IoT Radio and Performance Basics (FDD) and optimized in
terms of the organization and description.
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.
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
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.
MLBFD-12100205 Data over User Plane 3.3.2 Data over User Plane
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.
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.
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.
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.
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.
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)
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).
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.
Figure 3-5 illustrates the mapping between the physical and transport channels of NB-IoT.
15 kHz 6 4 0.5 2
15 kHz 12 2 0.5 1
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.
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).
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.
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,
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.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.
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.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.
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.
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.
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.
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.
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.
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.
SIB2-NB CellSiMap.NbSib2Period
SIB3-NB CellSiMap.NbSib3Period
SIB4-NB CellSiMap.NbSib4Period
SIB5-NB CellSiMap.NbSib5Period
SIB14-NB CellSiMap.NbSib14Period
SIB16-NB CellSiMap.NbSib16Period
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.
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.
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.
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.
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.
– 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
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.
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.
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
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
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:
– 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.
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
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.
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.
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
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.
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 RRC connection reestablishment procedure in user plane CIoT EPS optimization
mode
Figure 4-11 Data transmission in control plane CIoT EPS optimization mode
Figure 4-12 Data transmission in user plane CIoT EPS optimization mode after an RRC
connection is set up
Figure 4-13 Data transmission in user plane CIoT EPS optimization mode after an RRC
connection is resumed
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.
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.
NOTE
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.
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.
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.
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
details, see 3GPP TS 36.413 R14.
– 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.
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.
– 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.
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.
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.
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.
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
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
Start position = Sn + 1 + 16
Start position = Sn + 1 + 32
Start position = Sn + 1 + 64
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
Start position = Sn + 1 + 12 + 2
Start position = Sn + 1 + 12 + 4
Start position = Sn + 1 + 12 + 5
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.
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:
Start position = Sn + 1 + 12
Start position = Sn + 1 + 16
Start position = Sn + 1 + 32
Start position = Sn + 1 + 64
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.
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.
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.
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).
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.
Parameter ID Description
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.
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.
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.
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.
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
Scenario Formula
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.
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
Scenario Formula
EuPrbSectorEqm.Reference NPDSCH_Inband =
SignalPwr is not set to 32767. (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
lg10) dBm
l Formulas used when an LTE FDD cell has two or four antenna ports
Scenario Formula
EuPrbSectorEqm.Reference NPDSCH_Inband =
SignalPwr is set to 32767. (PDSCHCfg.ReferenceSignalPwr/10 + 10 x lg8 –
3) dBm
EuPrbSectorEqm.Reference NPDSCH_Inband =
SignalPwr is not set to 32767. (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
lg8 – 3) dBm
Scenario Formula
EuPrbSectorEqm.Re P(NPSS) =
ferenceSignalPwr is (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
not set to 32767. lg11) dBm
Scenario Formula
EuPrbSectorEqm.Re P(NPSS) =
ferenceSignalPwr is (EuPrbSectorEqm.ReferenceSignalPwr/10 + 10 x
not set to 32767. lg11 – 3) dBm
l LTE in-band deployment (Note: the calculated power includes the LTE FDD CRS
transmit power)
2 Yes NPSS_Inband =
(PDSCHCfg.ReferenceSignalPwr/1
0 + 10 x lg8 – 3) dBm
2 No NPSS_Inband =
(PDSCHCfg.ReferenceSignalPwr/1
0 + 10 x lg7 – 3) dBm
2 Yes NPSS_Inband =
(EuPrbSectorEqm.ReferenceSigna
lPwr/10 + 10 x lg8 – 3) dBm
2 No NPSS_Inband =
(EuPrbSectorEqm.ReferenceSigna
lPwr/10 + 10 x lg7 – 3) dBm
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
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.
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.
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.
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.
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.
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.
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.
Low-Priority UE Rejection
When there are no sufficient cell resources for processing Msg3, the eNodeB rejects UEs with
the cause "delayTolerantAccess-v1330."
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
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.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.
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.
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.
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.
5 Network Analysis
Different deployment modes have different impacts. For details, see the descriptions of these
deployment modes.
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.
Function Impacts
Function Function Reference Description
Name Switch
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
Function Function Reference Description
Name Switch
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.1 Benefits
LTE in-band deployment utilizes PRBs within an LTE FDD band for NB-IoT.
5.3.2 Impacts
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.
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)
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
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:
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
Function Function Reference Description
Name Switch
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%.
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
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.
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.
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.
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-3 illustrates the requirements for NB-IoT 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.
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
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
l The cell bandwidth is 15 MHz, and the indexes of downlink PRB deployment positions
are in the range of 2, 7, 12, 17, 22, 27, 47, 52, 57, 62, 67, and 72.
l The cell bandwidth is 20 MHz, and the indexes of downlink PRB deployment positions
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.
3 MHz 2 -2
12 1
5 MHz 2, 7 -2
17, 22 1
10 MHz 4, 9, 14, 19 0
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.
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
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
255 71 0 -1 Recommended
360 72 1 0 Recommended
450 73 -1 -2 Recommended
555 74 0 -1 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
105 92 0 -1 Recommended
210 93 1 0 Recommended
300 94 -1 -2 Recommended
405 95 0 -1 Recommended
510 96 1 0 Recommended
600 97 -1 -2 Recommended
705 98 0 -1 Recommended
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.
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.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.
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.
Sector ID SECTOREQM.sectorId -
CN Operator ID CnOperator.CnOperatorId -
CN Operator ID CnOperatorTa.CnOperator -
Id
S1 ID MmeCapInfo.S1Id -
S1 Interface ID MmeCapInfo.S1InterfaceI -
d
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.
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.
Cell ID Cell.CellId -
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.
Note for (1): Set the parameter based on the CellRbReserve.RbRsvType parameter setting.
PRB ID Prb.PrbId -
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.
For DBS3900 LampSite and DBS5900 LampSite, set PRB sector equipment group
parameters for the NB-IoT anchor carrier.
For DBS3900 LampSite and DBS5900 LampSite, add PRB sector equipment group members
for the NB-IoT anchor carrier.
Set NPRACH power parameters and the NPRACH start time configuration indication.
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.
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.
eNodeB ID EutranExternalCell.eNode -
BId
Cell ID EutranExternalCell.CellId -
eNodeB ID EutranIntraFreqN- -
Cell.eNodeBId
Cell ID EutranIntraFreqN- -
Cell.CellId
eNodeB ID EutranInterFreqN- -
Cell.eNodeBId
Cell ID EutranInterFreqN- -
Cell.CellId
Set the SIB16-NB broadcast switch, RACH backoff control switch, NB-IoT cell algorithm
switch, and other switches.
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 parameters to allow LTE FDD UEs to preempt NB-IoT UEs when NB-IoT and LTE FDD
are co-sited.
Set the minimum proportion of RRC_CONNECTED UEs allowed for NB-IoT when NB-IoT
and LTE FDD are co-sited.
Set an eNodeB frame offset when NB-IoT and LTE cells share the same RF modules or
BBPs.
Set a cell frame offset when NB-IoT and LTE cells share the same RF modules or BBPs.
Set cell antenna power information when repeaters are used to amplify the RRU output power.
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.
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.
PRB ID PrbSchConfig.PrbId -
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.
PRB ID PrbPdcchCeConfig.PrbId -
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.
Parameter Name Parameter ID Setting Notes
PRB ID PrbUlSchCeAlgo.PrbId -
PRB ID PrbDlSchCeAlgo.PrbId -
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.
PRB ID PrbDlGapConfig.Prbid -
To optimize inactivity timers for different service types, adjust the following parameters.
Parameter Name Parameter ID Setting Notes
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:
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
neighbor relationship with this cell.
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.
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.
MOD QCIPARA: Qci=5, NbRlcPdcpParaGroupId=130;
MOD QCIPARA: Qci=6, NbRlcPdcpParaGroupId=130;
MOD QCIPARA: Qci=7, NbRlcPdcpParaGroupId=130;
MOD QCIPARA: Qci=8, NbRlcPdcpParaGroupId=130;
MOD QCIPARA: Qci=9, NbRlcPdcpParaGroupId=130;
//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.
ADD CELLRBRESERVE: LocalCellId=1, Index=0, RbRsvMode=NB_DEPLOYMENT,
RbRsvType=DOWNLINK_MODE, RbRsvStartIndex=44, RbRsvEndIndex=44;
ADD CELLRBRESERVE: LocalCellId=1, Index=1, RbRsvMode=NB_DEPLOYMENT,
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,
----End
L.NB.Traffic.User.Max.CoverageLevel2
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.Traffic.UL.SCH.TB
L.NB.Traffic.UL.SCH.ErrTB.Rbler
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 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
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 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
10 Glossary
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"
9. 3GPP TS 36.304, "Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode"
10. 3GPP TS 36.306, "Evolved Universal Terrestrial Radio Access (E-UTRA); User
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