07 NB-IoT C&P Impact Summary

NB-IoT C&P Impact
Compiled by Zhang Jennie

Basically based on LTE3071
1 © Nokia Networks 2017

Table of Contents
- Peak Throughput
- Coverage
- Traffic Model
- Capacity
- Latency
- Impact to Legacy
- KPIs
- Counters
2
Peak Throughput

Timing Relationship (DL Data Transmission) max{3ms, time until the beginning of
the next search space}
12ms + time offset given in DCI
3.75 kHz – {0,8}ms
15 kHz – {0,2,4,5}ms
NPDCCH NPDSCH NPDCCH
4ms + kdelay valid subframes given in DCI NPUSCH (A/N)

If Rmax <128, {0,4,8,12,16,32,64,128}
If Rmax>=128, {0,16,32,64,128, 256,512,1024}
36.213 16.6
If a NB-IoT UE has a NPUSCH transmission ending in subframe n , the UE is not required to monitor NPDCCH in any
subframe starting from subframe n+1 to subframe n+3.

NPDSCH
ITBS 11 and 12 are valid only in stand-alone and guard-

band operation modes
For LTE3071 inband NB-IoT, NSF is fixed to 4(e.g. ISF=3),
max TBS is 680 bits.

DL Peak Throughput
• Timing diagram for NB-IoT downlink data transmission
4ms* FN 0 1 2
SFN 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
NPDCCH
MIB SIB1 PSS SSS MIB SIB1 PSS SSS MIB SIB1 PSS SSS
NPDCCH NPDSCH Valid SF
680 bits * 4ms is the best case; actual timing

depends on the number of free subsequent
NPDCCH TTI=2, subframes dictated by SIB1 occurrence
NPUSCH NPUSCH Format 2 TTI=2 ms
(A/N)
27ms
• Instantaneous peak rate (in-band) is is given by:

TBSmax/TNPDSCH = 170 kbps (TBS=680 bytes, TTI=4ms)
• Sustained throughput:
TBSmax/(TNPDCCH + 4ms + TNPDSCH + 12ms + TNPUSCH + 3ms) kbps
Sustained peak rate is approximately 25.2 kbps without considering NPBCH/NPSS/NSSS overhead,
and 18.9 kbps(25.2*0.75) when 25% DL overhead is taken into account (PBCCH, SIBx, PSS, SSS)
6 © Nokia 2017 Nokia Internal Use

DL Peak Throughput
• NPDSCH transmission starts in the valid DL subframe at least 4 ms after the end of associated DCI
format N1 conveyed via NPDCCH. The reason of such gap is reduced computing capability of low cost
IoT devices, they need time for NPDCCH decoding.
• After NPDSCH transmission completed, the UE needs to send back HARQ acknowledgement using
NPUSCH Format 2. The allocation of NPUSCH resources for HARQ are indicated in DCI.
• Again, due to the limited computing resources of IoT device, time offset between the end of NPDSCH
and the associated HARQ ACK is needed. At least 12 ms, since NPDSCH transport block is up to
680 bits, while DCI is only 23 bits.
• Next scheduling request conveyed by NPDCCH is expected not earlier than 3ms, in the next search
space.

Timing Relationship (UL Data Transmission)
max{3ms, time until the beginning of
the next search space}
NPDCCH NPDCCH
NPUSCH
{8,16,32,64}ms as indicated in DCI
36.213

NPUSCH TBS 36.213
For multi tone, ITBS support 0-12.
For single tone, ITBS support 0-10.

LTE3071 only supports NPUSCH 15KHz single tone,
NRU is fixed to 4(e.g IRU =3), max TBS is 680 bits.

UL Peak Throughput
• Timing diagram for NB-IoT uplink data transmission
NPDCCH NPDCCH
32ms
680 bits
NPDCCH TTI=2,
NPUSCH NPUSCH Format 1 TTI=32 ms
45ms*
• Instantaneous throughput is given by:

TBSmax/TNPDSCH = 21.25 kbps (TBS=680 bytes, TTI=32ms)
• Sustained throughput:
TBSmax/(TNPDCCH + 8ms + TNPUSCH + 3ms) kbps
Approximately 15.1 kbps (680/45)without considering NPRACH overhead
NPRACH occasion is every 160 ms and lasts for 25.6 ms, 16%(25.6/160) overhead reduces
sustained peak rate to 12.7 kbps

UL Peak Throughput
• A grant for NPUSCH transmission is indicated in the NPDCCH via DCI format N0.
• Start time of the NPUSCH, the number of repetitions (hardcoded to 1 in
LTE3071), the number of RUs used for one transport block (hardcoded to 4 for
format 1 in LTE3071) and subcarrier position
• MCS index and the transport block size
• For normal coverage supported with LTE3071 no NPUSCH repetition is foreseen
• The time offset between the end of NPDCCH and the beginning of the associated
NPUSCH is at least 8 ms. After completing the NPUSCH transmission, the UE
monitors NPDCCH to learn whether NPUSCH is received correctly by the base
station, or a retransmission is needed.
• The ACK/NACK is transmitted in NPDCCH by the new data indicator (NDI) in the
DCI format N0. Positive UL HARQ feedback is signaled via toggled NDI, or for the
last UL data transmission no feedback at all. Negative UL HARQ feedback is
signaled via non-toggled NDI.
11 .
© Nokia 2017 Nokia Internal Use
Coverage

UL Link Budget
Link Budget is performed for one mobile located at cell edge transmitting at
max power and requiring a given service
Link Budget
Principles
Uplink Path
Device
BTS
Device
Transmit Losses and Receiver

Power Margins
Gains
Sensitivity
Interference = MAPL
eNode-B Derived from Maximu
UE Transmit Feeder losses Interference
Antenna SINR m
power Penetration Loss Margin
Gain performance Allowable
(23dBm) Shadowing Margin UE Antenna s Path Loss
Handoff Gain Gain
Body Loss
14 © 2017 Nokia Internal

UL MAPL
where
MAPL – maximum allowable path loss
EIRP – equivalent isotropic radiated power
SRx – receiver sensitivity
LNF – log normal fading margin
IM – interference margin
Gantenna – antenna gain
Gshad – gain against shadowing
Lpen – penetration loss
Lfeeder – feeder loss
Lbody – body loss

DL MAPL
where
MAPL – maximum allowable path loss
EIRP – equivalent isotropic radiated power
SRx – receiver sensitivity
LNF – log normal fading margin
IM – interference margin
Gantenna – antenna gain
Gshad – gain against shadowing
Lpen – penetration loss
Lfeeder – feeder loss
Lbody – body loss

Link Budget
Sensitivity computation
Thermal noise level
SensitivitydBm = 10.log10(Nth.W.F) + SINRdB
• Nth: thermal noise density, 10log(KB.T) = -174 dBm/Hz

Service dependent
KB=Boltzmann Constant, T=293 ̊ K
• WRB: bandwidth
• F: eNode-B Noise figure (which specifies the performance of the receiver)
• SINRdB: ratio of received power by the noise power per Rx antenna
17 © 2016 Nokia
Dimensioning
Link Budget
• LTE3071 supports only first level coverage, in the range of legacy LTE. Further coverage
enhancements are subject of subsequent FL17SP features.
Note that selected bands are
Downlin allowed for NB-IoT within Rel 13
k Uplink
Operating band [MHz] 900
General Sensors deployment Stationary Only TM2 for LTE3071
parameter NB-IoT carrier configuration In-band
s Legacy LTE channel bandwidth [MHz] 10
Legacy LTE DL transmission scheme 2Tx MIMO (TM2/3/4) Host legacy LTE cell power
Tx antenna power [dBm] 43.0 23.0
Power per PRB [W] 0.40 - DL power boosting up to 6 dB
Antenna gain [dBi] 18.0 0.0
Feeder loss [dB] 0.5 - Legacy cell power reduction due
Transmitti
DL NB-IoT Power Boosting [dB] 6.0 - to power boost
ng end Legacy Cell Power Reduction per PRB
[dB] 0.1 - EIRP per NB-IoT UE calculated
Tx power increase [dB] 3.0 0.0 from the PSD and power boost
Effective NB-IoT EIRP per user [dBm] 52.5 23.0 for 1PRB
Feeder loss [dB] - 0.5 Preliminary values
Receiving Antenna gain [dBi] 0.0 18.0
end Noise figure [dB] 5.0 3.0
Additional gains [dB] 0.0 0.0
Dimensioning
Link Budget
Reference Signal (legacy LTE) [%] 9.52% - numSib1RepNB

PDCCH (legacy LTE) [%] 19.05% -
NB Primary Synchronization Signal (NPSS) [%] 7.20% - Depends on the SIB2 TBS: 56/120 bits
NB Secondary Synchronization Signal (NSSS) [%] 3.93% - TBS 2 subframes, remaining
NB Reference Signal (NRS) [%] 9.52% - 8 subframes
NB Broadcast Channel (NPBCH) [%] 5.95% -
SIB1-NB repetitions 4 - sib2RepPatternNB
NB System Information Block 1 (SIB1-NB) [%] 0.77% -
SIB2-NB length [subframes] 8 - sib2PeriodicityNB
SIB2-NB repetition pattern [radio frames] 16 -
SIB2-NB periodicity [ms] 2560 - siWindowLenNB
SIB2-NB window length [ms] 160 -
System
NB System Information Block 2 (SIB2-NB) [%] 0.19% -
overhead
Maximum number of NPDCCH repetitions (R_max) 4 -
npdcchMaxNumRepRa
NPDCCH starting subframe period (G) 2 -
NPDCCH repetition level 2 - npdcchStartSfRa; LTE3071=2
Number of subscribers per cell 50000 -
Assumed for NPDCCH overhead
Subscriber BHCA 0.47 -
calculations
NPDCCH overhead [%] 13.00% -
NPRACH periodicity [ms] - 160 Assumed for NPDCCH overhead
NPRACH repetition level - 4 calculations
NPRACH overhead [%] - 16.25% nprachPeriod
Additional overhead [%] 0.00% 0.00%
Total system overhead [%] 69.15% 16.25%

nprachNumRepPreamble

Dimensioning
Link Budget
LTE3071 supports only UE

Message size [bytes] 10 200
originated UL messages. Please
Number of NPDSCH subframes / NPUSCH align DL message size with
Resource Units 4 4 limited link.
Number of NPUSCH tones per user - 1
Modulation and coding scheme (User
defined) 2-QPSK 2-QPSK There is no link adaptation for
Residual BLER target rBLER = 10% LTE3071, selected MCS is used
Number of message repetitions 1 1 for all the transmission. It
Service Transport Block Size for NPDSCH / NPUSCH impacts TBS size, and thus
[bits] 176 144 achievable throughputs and
Number of TBSs required to send the overheads
message 1 13
Estimated user throughput (single UE) MCSs can be used to balance UL
and DL links.
[kbps] 0.50 2.11
Modulation efficiency (data bits/modulated
symbol) 0.85 0.38
Effective Coding Rate 0.42 0.19

Dimensioning
Link Budget
LTE3071 supports only single

Enhanced antenna at UE and 2 antennas at
Channel model Pedestrian A 1Hz eNB
NB-IoT transmission scheme 2Tx-1Rx 1Tx-2Rx
Required SINR @ BLER10% [reference] [dB] 9.05 1.78
Repetitions gain [dB] 0.00 0.00
Required SINR at cell edge [dB] 9.05 1.78
Interference Margin [dB] 3.00 3.00
Channel Thermal noise density [dBm/Hz] -173.93
DL is weaker since there is just
Subcarrier bandwidth [kHz] 15 single antenna at UE. MCS can
Noise power per subcarrier [dBm] -132.17 be selected accordingly to
Receiver sensitivity [dBm] -107.33 -127.39 balance links.
Maximum Allowable Path Loss [dB]
(clutter not considered) 156.85 164.89
Link used for cell range calculations Limiting link Allows for checking UL or DL cell
RSRP (clutter not considered) [dBm] -118.13 -126.17 ranges independently
Note: 3GPP Normal coverage pathloss (144dB) has different assumptions

Dimensioning
Link Budget
Rural
Dense Urban Urban Suburban
(quasi)
Maximum Allowable Path Loss (limiting
link) [dB] 161.58
(clutter not considered) Differs from the legacy LTE, since
eNB antenna height [m] 30 30 30 50 IoT devices (e.g. Smart meters )
Sensor antenna height [m] 0.5 0.5 0.5 0.5 are expected at lower heights
Average penetration loss [dB] 18.0 13.0 8.0 3.0
Standard deviation outdoor [dB] 9.0 8.0 8.0 7.0
Standard deviation of penetration loss [dB] 0.0 0.0 0.0 0.0 Improved NB-IoT coverage is not
Combined standard deviation [dB] 9.00 8.00 8.00 7.00 considered yet, since LTE3071
cope with first level coverage
Location probability
only
Cell area probability [%] 99.00% 99.02% 99.02% 99.02%
Propagation Location / Cell edge probability [%] 96.90% 96.70% 96.70% 96.50%
Log first level Fading margin [dB] 16.80 14.71 14.71 12.68
Gain Against Shadowing [dB] 0.00 0.00 0.00 0.00
Maximum Allowable Path Loss [dB]
(clutter considered) 126.78 133.87 138.87 145.90
RSRP (clutter considered) [dBm] -94.07 -101.15 -106.15 -113.18
Intercept Point (w/o clutter correction) [dB] 128.16 128.16 127.56 124.50
Slope 1 [dB] 35.22 35.22 35.22 33.77
Slope 2 [dB] 39.92 39.92 39.92 38.11
Clutter correction factor [dB] 3.00 0.00 -9.64 -23.01
Cell Range [km] 0.78 1.45 3.93 20.66

Inter Site Distance for 3-sector grid [km] 1.17 2.18 5.90 30.98

Traffic Model

3GPP IoT traffic model (45.820 Annex E)
Report type Packet size Inter-arrival time
Mobile Autonomous Reporting (MAR) UL: 20 bytes Months to years (reaction

exception reports time up to 10 second latency)
 E.g. smoke detectors, power failure notifications from
smart meters, tamper notifications etc.
Mobile Autonomous Reporting (MAR) UL: 20 - 200 bytes 40%: Once per day
periodic reports Pareto distributed 40%: Once every 2 hours
15%: Once per hour
 E.g. smart utility (gas/water/electric) metering
5%: Once per 30 min
reports, smart agriculture etc. DL: Ack => Mean = 0.47 times per
hour
Network originated reports DL: 20 bytes 40%: Once per day
 E.g. trigger the device to send an uplink report as a 40%: Once every 2 hours
15%: Once per hour
result of the network command e.g. request for a UL: 20 – 200 bytes 5%: Once per 30 min
smart meter reading Pareto distributed => Mean = 0.47 times per
hour
Software update/reconfiguration model DL: 200 - 2000 bytes 180 days
 Software updates or patches of Cellular IoT devices. Pareto distributed
Rare, but large payload sizes expected for complete
software updates

Traffic model
• As paging is not supported in LTE3071, only UE initiated Mobile autonomous repor
ting MAR are expected. Network cannot initiate connection for a NB-IoT cell.
• 3GPP target of 50k UE served per cell is fulfilled under 45.820 traffic model, w
here distribution of messages size and their periodicity is defined. Generally N
B-IoT supports infrequent, small messages.
• From 3GPP distribution of MAR reports 0.47 BHCA is obtained with Pareto distribu
ted message size of 20-200 bytes.
• Number of attempts during BH:
= = 6.8

Capacity

Capacity
Device density per cell (45.820 Annex E)
NB-IoT was defined by 3GPP taking into account typical inter site distance and household density
for urban area. Each location should handle up to 40 IoT devices.
Capacity target is 52547 devices within a cell site sector
Calculation:
Inter-site Distance (ISD) = 1732m
Cell site sector radius, R = ISD/3 = 577.3m
Area of cell site sector (assuming a regular hexagon) = 0.86587 Sq Km
Number of devices per cell site sector = Area of cell site sector*Household density
per Sq km*number of devices per household = 52547

Dimensioning
NPRACH capacity
• RACH attempts per cell due UE transition from idle to connected depends on the number of devices
per cell and BHCA.
• We can assume certain probability for correct NPRACH reception PNPRACH which impacts number of
NPRACH messages needed.
= = 7.6
• The number of NPRACH preambles is limited, and RACH channel can be accessed by number of
UEs simultaneously, so when estimating NPRACH capacity expected RACH load and allowed
collision probability Pcoll should be assumed.
NPRACH slot
• RACH occasion is repeated every NPRACH periodicity nprachPeriod
4xNPUSCH 4xNPRACH 4xNPUSCH 4xNPUSCH 4xNPUSCH 4xNPUSCH 4xNPUSCH 4xNPRACH 4xNPUSCH
32ms 25.6ms 32ms 32ms 32ms 32ms 32ms 25.6ms 32ms
NPRACH repetitions 160ms
−1 𝑃 𝑐𝑜𝑙𝑙
𝑅𝐴𝐶𝐻 𝑜𝑐𝑐𝑎𝑠𝑖𝑜𝑛𝑠 / 𝑠= ( 𝑛𝑝𝑟𝑎𝑐h𝑃𝑒𝑟𝑖𝑜𝑑 [𝑠 ]) (
48 ∙ ln 1 −
100 )
Dimensioning
NPRACH capacity
• Offered RACH traffic should not be higher than NPRACH occasions/s
• For the default traffic model and 90% of NPRACH reception probability the target of the offered RACH
traffic of 7.6 RACH/s can be guaranteed with collision probability lower than 2.5%
(48 preambles, NPRACH repetition every 160 ms).
NPRACH periodicity [ms] 160

NPRACH bandwidth (tones) 48
RACH collision probability [%] 2.5
NPRACH
NPRACH reception probability [%] 90
capacity
RACH attempts (from traffic model) [1/s] 7.6
NPRACH occasions [1/s] 7.6
Max #UEs (RACH) 52733
52733

Dimensioning
NPDCCH capacity
• NPDCCH is used for UL and DL scheduling during call UE eNB
setup and further message transmission. Random Access
msg1
NPRACH
• Call setup requires at least 3 NPDCCH messages, RAR scheduling
NPDCCH
• When transmitted UL message is fragmented into TBSs, Random Access Response
msg2
each NPUSCH scheduling needs separate DCI, so NPDSCH
RRC: Connection Request

additionally #TBS NPDCCHs are needed, without HARQ NPUSCH msg3
repetition RRCConnectionSetup scheduling

NPDCCH
• In UL direction 11 UEs can be scheduled simultaneously, RRCConnectionSetup-NB

NPDSCH msg4
providing that they are using different subcarriers RRCSetupComplete scheduling
NPDCCH
RRCConnectionSetupComplete-NB
msg5
NPUSCH

Dimensioning
NPDCCH capacity
• Max NPDCCH repetition can be 4, 8 or 16 subframes, what corresponds search spaces of 8, 16
and 32 subframes respectively. Maximum number of scheduled UEs:
1000

𝑅𝑚𝑎𝑥 ∙ 𝐺
𝑀𝑎𝑥 𝑈𝐸 𝑁𝑃𝐷𝐶𝐶𝐻 ¿=
3 + ¿ 𝑇𝐵𝑆
• Additional overhead for common channels have to be considered as well.
G 2 2 2 npdcchStartSfRa Example: Message size 200 bytes,

Rmax 4 8 16 npdcchMaxNumRepRa MCS3, BLER = 10%, TBS size 208
Search space [SF] 8 16 32 bits, #TBS=9
1000/(search space Call setup requires at least 3
DCI # /s
125 63 31 [ms])
NPDCCH messages
# scheduled UEs /s
8 4 2 (0.75*DCI/s)/12 So totally 12 DCI per UE call
(w/overhead)

Dimensioning
Total MAR message transmission time
• Average NB-IoT Call duration:
T= TCS + TTx
- TCS call setup time to establish the RRC connection
- TTx time for data transfer
• Each scheduled UL and DL transmission follows timings for NPDSCH (27ms) and NPUSCH (45ms)
• In case message content does not fit into the single TBS (max 680 bits @MCS10) it is split into
subsequent transmissions, hence total transmission time is multiplication of the single
NPDSCH/NPUSCH process duration. It is assumed that the issue is only for NPUSCH since NPDSCH
is used here (MAR reporting) only for RACH signaling, with content fitting into single TBS.
NPDCCH NPDCCH
32ms 32ms
680 bits 680 bits

NPUSCH NPUSCH
45ms* 45ms*

Dimensioning UE eNB
Call setup time
Random Access
• 27 ms is needed for the whole NPRACH
Random Access
msg1
NPDSCH message, including NPRACH
Random Access
25.6 ms
NPDCCH time, 45 ms for NPUSCH NPRACH
Random Access
• Each NPDCCH have to be scheduled 8 ms

NPRACH
RAR scheduling
in the separate search space 27 ms
NPDCCH
Random Access Response msg2

• Total 194 ms for RACH procedure NPDSCH
45 ms?
(without HARQ and NPRACH RRC: Connection Request
NPUSCH
repetitions) 8 ms
RRCConnectionSetup scheduling
msg3
NPDCCH
27 ms
RRCConnectionSetup-NB
NPDSCH msg4
8 ms RRCSetupComplete scheduling
NPDCCH
45 ms
RRCConnectionSetupComplete-NB
NPUSCH
Total: 194 ms msg5

Dimensioning
Call setup time
NPDCCH transmission length [ms] 2
• NPRACH sequence can be repeated up to NPDCCH ->NPDSCH gap [ms] 4
nprachMaxNumPreambleCE settings (default 5), we can TBS transmission time on NPDSCH [ms] 4
assume certain probability for correct NPRACH reception NPDSCH ->NPUSCH (A/N) gap [ms] 12
NPUSCH (A/N) length [ms] 2
PNPRACH which impacts average time for NPRACH.
NPUSCH (A/N) / NPUSCH ->NPDCCH gap [ms] 3
TNPRACH = (25.6 ∙ PNPRACH ) + (2∙ 25.6 ∙ (1 - PNPRACH ) ∙ PNPRACH) HARQ percentage [%] 10
Total DL TBS transmission time [ms] 30
+ (3∙ 25.6 ∙ (1 - PNPRACH )2 ∙ PNPRACH) …. = 25.6 ∙ PNPRACH ∙ NPDCCH transmission length [ms] 2
1/[1-(1- PNPRACH)2] = 25.6/PNPRACH NPDCCH ->NPUSCH gap [ms] 8
TBS transmission time on NPUSCH [ms] 32
• Assuming PNPRACH = 90%, TNPRACH = 28.4 ms NPUSCH ->NPDCCH (A/N) gap [ms] 3
HARQ percentage [%] 10
• The same approach can be selected for HARQ procedure Total UL TBS transmission time [ms] 50
for NPUSCH and NPDSCH: NPRACH transmission lenght [ms] 26

NPDCCH scheduling time [ms] 8
• PNPUSCH = 90%, TNPUSCH = 45 / 0.9 = 50 ms Number of NPDCCH per RACH procedure 3
DL message transmission lenght [ms] 30
• PNPDSCH = 90%, TNPDSCH = 27 / 0.9 = 30 ms UL message transmission lenght [ms] 50
NPRACH reception probability 90
Total Call setup time [ms] 211
• Hence modified RACH procedure time: 211 ms

Dimensioning
Total MAR message transmission time
• 3GPP specifies MAR message size Pareto distributed, with 20-200 bytes size. For simplification only the
worst case 200 bytes will be considered.
• NPUSCH TBS size depends on the UL MCS selected, number of TBSs to be transmitted can be then
calculated, taking into account BLER
𝐵𝐿𝐸𝑅
8 ∙ 𝑀𝑒𝑠𝑠𝑎𝑔𝑒 𝑈𝐿 [𝑏𝑦𝑡𝑒𝑠 ] ∙ (1 + )
100
¿ 𝑇𝐵𝑆=
𝑇𝐵𝑆 𝑠𝑖𝑧𝑒 [𝑏𝑖𝑡𝑠 ] 4RU
ITBS
Bits
• Having number of needed TBSs one can easily calculate Ttx taking into account
0 88
transmission process duration: TTX [ms]= #TBS ∙ TNPUSCH [ms] 1 144
BHCA 0.47
2 176
Traffic #UE 52547 3 208
model #UE attempts/cell/s 6.8 4 256
UL message size (bytes) 200 5 328
UL MCS (User defined) 2-QPSK 6 392
TBS index 1 7 472
UL
Transport Block Size for NPUSCH [bits] 144 8 536
UL BLER [%] 10 9 616
settings
Number of TBSs required to send the message 13 10 680
NPUSCH transmission duration [ms] 644
Average NB-IoT Call duration (including CS) [ms] 855
Dimensioning
NPUSCH capacity
• Average throughput for NB-IoT UE can be estimated taking into account amount of data to be
transmitted and total time needed for the transmission (with call setup and TBS fragmentation)
A 𝑣𝑒𝑟𝑎𝑔𝑒 [ 𝑘𝑏𝑝𝑠 ]= 8 ∙ 𝑀𝑒𝑠𝑠𝑎𝑔𝑒 𝑈𝐿 [ 𝑏𝑦𝑡𝑒𝑠 ]
¿
𝑇 𝐶𝑆 +¿ 𝑇𝐵𝑆 ∙ 𝑇 𝑇𝑋
• NB-IoT capacity in terms of served subscribers in BH can be estimated considering average time
of resources occupation by single UE. Providing that NPDCCH and NPRACH limits are met
NPUSCH resources should be analyzed assuming certain utilization factor (11 subcarriers
available for NPUSCH). NPRACH overhead should be considered as well.
1000 −
1000 𝑈𝐸 = 11 ∙ 3600∙ (1− 𝑁𝑃𝑅𝐴𝐶 𝐻 𝑜𝑣𝑒𝑟h𝑒𝑎𝑑 )∙ 𝑈𝐿 𝑢𝑡𝑖𝑙𝑖𝑠𝑎𝑡𝑖𝑜𝑛
∙ 25.6 [ ms ¿]
𝑁𝑃𝑅𝐴𝐶𝐻 𝑃𝑒𝑟𝑜𝑑𝑖𝑐𝑖𝑡𝑦 [ 𝑚𝑠 ] 𝐵𝐻
𝑁𝑃𝑅𝐴𝐶𝐻𝑜𝑣𝑒𝑟h𝑒𝑎𝑑 = 𝑇 𝐶𝑆 [ 𝑠]+(¿𝑇𝐵𝑆 ∙ 𝑇 ¿ ¿𝑇𝑋 [ 𝑠]) ¿
1000
Average throughput per NB-IoT UE (Tx) [kbit/s] 3.59
NPUSCH overhead [%] 16
UL resources utilisation factor [%] 90
Average number of UEs/Cell (TX) 64398
1000 ∙11 ∙ 3600 ∙ ( 1 −16 % ) ∙ 90 %

¿ 𝑈𝐸 𝐵𝐻 54818=
36 © Nokia 2017 Nokia Internal Use 2 ∙50+ 9∙ 50
RRC Connected UE and UE/TTI in LTE3071
NB-IoT RRC_CONNECTED UE
The maximum number of RRC connected NB-IoT UE supported by an in-band or standalone
NB-IoT cell on FSMr3 platformis is 420. Note that the cell maximum capacity is shared by
legacy and NB-IoT UEs so that the total number of legacy and NB-IoT UEs shall be equal to or
less than the cell limit
NB-IoT Scheduling UE/TTI

The maximum number of NB-IoT scheduled UE/TTI is 1
· Either DL or UL can be scheduled but not both
· The cell level number of scheduled UE/TTI is consumed accordingly similar to legacy UEs
NB-IoT UEs and CA Capacity

NB-IoT UEs indirectly impact the legacy CA configured UE capacity because NB-IoT devices
consume cell level RRC_CONNECTED UE capacity similar to legacy users. Because the same
capacity pool is consumed by legacy UEs, NB-IoT UEs, and visiting CA configured UEs (from
sCell perspective), therefore consumption by one category reduces available capacity to
other categories

Supported configurations in LTE3071
FSMF configuration with inband NB-IoT

Each FSMF or FBBA/FBBC supports:
· 3*5/10/15/20MHz 2Tx/2Rx cells + 3 NB-IoT cells

Per CR15334, additional configurations are supported:

Each FSMF or FBBA/FBBC
· 3*5/10/15/20MHz 2Tx/2Rx cells + 3 NB-IoT cells OR
· (2*15/20MHz 2Tx/2Rx cells + 2 NB-IoT cells) + 2*5/10MHz 2Tx/2Rx cell
FSMF + FBBA/C
· 2*15/20MHz 2Tx/2Rx cells + 2*5/10MHz 2Tx/2Rx cell + 4 NB-IoT cells OR
· (4*15/20MHz 2Tx/2Rx cells + 4 NB-IoT cells) + 4*5/10MHz 2Tx/2Rx cells
FSMF + 2xFBBA/C
· 4*15/20MHz 2Tx/2Rx cells + 4*5/10MHz 2Tx/2Rx cell + 8 NB-IoT cells OR
· (6*15/20MHz 2Tx/2Rx cells + 6 NB-IoT cells) + 6*5/10MHz 2Tx/2Rx cells


Latency

Latency
Example MCS0 vs MCS10 latency, 200 bytes UL
message, no repetitions, default timings, no
HARQ Synchronisation and SI acquisition
• There is QoS constraints defined for transmission of Synchronization 20 [ms]
MAR reports MIB acquisition 640 [ms]
SIB1 acquisition 160 [ms]
• 3GPP 45.820 states 10s of delay for transmission of SIB2 acquisition 160 [ms]
Call setup
Exception report (e.g. smoke detector or alarm NPRACH waiting time 160 [ms]
NPRACH duration 26 [ms]
• Periodicity of such events is rare; it means that NPDCCH scheduling time 8 [ms]
synchronisation and SI messages acquisition have to NPRACH -> NPDCCH (RAR scheduling) 6 [ms]
DL: Random Access Response
be counted as well transmission
27 [ms]
UL: RRC Connectiion Request 45 [ms]
DL: RRC Connection Setup 27 [ms]
DL: RRC Connection Setup Complete 45 [ms]
Total call setup time 354 [ms]
UL Data transmission
UL MCS MCS0 MCS10
NACK + DCI (UL grant) 26 [ms]
TBS size 88 680 [bits]
Number of TBSs required to send the
20 3
message
Average UL transmission time 900 135 [ms]
UL Data transmission
Total UL message transmission time 2234 1469 [ms]

Impact to Legacy

Legacy LTE-UE, single user peak TP requirement
NB_IoT will consume a complete resource block group per cell. Therefore for legacy LTE-UEs, the single
peak TP(UL and DL) will be reduced by a factor of:
• (25-2)/25= 0,92 for a 5Mhz cell
• (50-3)/50= 0,94 for a 10Mhz cell
• (100-4)/100= 0,96 for a 20Mhz cell
Those factors shall be measured with a simple Mimo2*2 cell and with a margin of 10%. The test
assumptions are the usual peak-TP test assumptions:
• PDCCH (1 symbol)
• BLER: 1%
• 2 antennas at eNB
• channel model: no fading, ideal radio conditions
• number of layers: 2
• 64 QAM modulation for DL
• 16 QAM modulation for UL

Host Cell Throughput Impact
Host cell performance monitoring after NB-IoT activation
Feature impact How to measure
Decreased DL capacity in the host cell due to Average PDCP Layer Active Cell Throughput DL
PRB resources reserved for NB-IoT inband cell LTE_5292d
When NB-IoT carrier is deployed, the number of PRBs
available for PDSCH is reduced. Consequently, DL
capacity is in such a case decreased. Effect will be
visible only if the given cell has heavy DL load
Decreased UL capacity in the host cell due to Average PDCP Layer Active Cell Throughput UL
PRB resources reserved for NB-IoT inband cell LTE_5289d
When NB-IoT carrier is deployed, the number of PRBs
available for PUSCH is reduced. Consequently, UL
capacity is in such a case decreased. Effect will be
visible only if the given cell has heavy UL load

Host Cell Active/RRC Connected UE number
Host cell performance monitoring after NB-IoT activation
Feature impact How to measure
Decreased amount of mean/peak active Average number of active users per cell (LTE_717b)
UEs/RRC connected UEs served by the host Maximum number of active users per cell (LTE_718b)
cell.
If Average/Maximum number of RRC connected users
suggests that the AC limits will be soon met in the host
cell, RRC connected limit for NB-IoT have to verified.
Decreased UL peak UE throughput As there are no available counters or KPIs to check UE
NB-IoT carrier consumes UL PRB resources what may peak throughput, TTI traces need to be checked.
impact UL peak throughput.
Additionally, when allocation of UL NB-IOT carrier
yields UL resources fragmentation, PUSCH is
physically divided into several scheduling areas. Peak
UE throughput will be decreased as one user can be
scheduled in only one scheduling area at the same
time

KPIs

RRC Connection Setup Success Ratio for NB IoT UEs
LTE_6170a
Release: FL17SP
Legacy: LTE_5218f

Average RRC Connected NB IoT UEs
LTE_6171a
Release: FL17SP
Legacy: LTE_5242b

UE-associated logical S1-Connection Establishment Success Ratio for NB I
oT UEs
LTE_6172a
Release: FL17SP
Legacy: LTE_5526a

UE Transaction to ECM-IDLE State Drop Ratio for NB IoT UEs
LTE_6173a
Release: FL17SP
Legacy: LTE_5025h

Total Ratio of Successful NB IoT Sessions
LTE_6174a
Release: FL17SP

E-UTRAN UL Resource Utilization Ratio for NB IoT UEs
LTE_6175a
Release: FL17SP

E-UTRAN DL Resource Utilization Ratio for NB IoT UEs
LTE_6176a
Release: FL17SP

Average Session Duration for NB IoT UEs
LTE_6177a
Release: FL17SP

Counters

Dimensioning
New counters
• There are new, NB-IoT specific counters defined for monitoring of the feature
performance
• More than 20 counters in total, considering the following aspects:
• RRC connection establishment
• S1-Connection Establishments
• Number of RRC connected Cat-NB1 UE
• UE movement idle state reason
• MAC PDU volume
• NB-IoT resources and time
• Paging
• Measurement 8066 – LTE NB-IoT has to be started

Performance Aspects
New counters
Counter name Description

NB_IOT_RRC_CONN_MAX This counter represents the highest value for number of NB-IoT UEs in
(M8066C0) RRC_CONNECTED state over the measurement period.
#LTE NB-IoT Trigger event: This counter is updated after each sampling interval
with the peak number of NB-IoT UEs in RRC_CONNECTED state during
the measurement period.
Granularity: 1 sec
Use case:
Maximum number of RRC connected NB UEs
Monitoring of the number of RRC connected for NB UEs in the same way
as LTE_5242b, LTE_5842a for legacy UEs.

Performance Aspects
New counters
NB_IOT_RRC_CONN_SUM This counter provides the sum of sampled values for measuring the number of
(M8066C1) simultaneously RRC Connected NB-IoT UEs. This counter divided by the denominator
NB_IOT_DENOM_RRC_CONN_UE provides the average number of RRC Connected NB-IoT
UEs per cell.
#LTE NB-IoT
Trigger event: This counter is updated after each sampling interval with the sample
taken from the number of NB-IoT UEs in RRC_CONNECTED state.
Granularity: 1 sec
Use case:
Average number of RRC connected NB UEs
Monitoring of the number of RRC connected for NB UEs in the same way as LTE_5242b,
LTE_5842a for legacy UEs.
Average number of NB_IOT_RRC_CONN_SUM

=
RRC connected NB NB_IOT_RRC_CONN_UE_DENOM
UEs

Performance Aspects
New counters
NB_IOT_RRC_CONN_ESTAB_ This counter provides the number of attempted RRC Connection

ATT Establishment procedures. From UE's point of view, the transition from ECM-
(M8066C2) IDLE to ECM-CONNECTED is started.
#LTE NB-IoT Trigger event: The counter is updated on the receipt of an

RRC:ConnectionRequest-NB message.
Use case:
RRC Connection Setup Success Ratio
The KPI proposed is monitoring RRC Connection Setup Success Ratio in the
same way as LTE_5218f for non NB UEs.
Impact: due to limited UE power, some setup degradations may happen
more often for SRB1bis during RRC Connection Setup procedure.
RRC Connection Setup NB_IOT_RRC_CONN_ESTAB_SUCC

Success Ratio related
= ×100%
NB_IOT_RRC_CONN_ESTAB_ATT
to NB UEs
Performance Aspects
New counters
NB_IOT_RRC_CONN_ESTAB_S This counter provides the number of successful completions of an RRC

UCC connection establishment.
(M8066C3)
Trigger event: The counter is updated on the receipt of an
#LTE NB-IoT RRC:ConnectionSetupComplete-NB message.
Use case:
The KPI proposed is monitoring RRC Connection Setup Success Ratio in the
same way as LTE_5218f for non NB UEs.
Impact: due to limited UE power, some setup degradations may happen
more often for SRB1bis during RRC Connection Setup procedure.
RRC Connection Setup NB_IOT_RRC_CONN_ESTAB_SUCC

= ×100%
Success Ratio related NB_IOT_RRC_CONN_ESTAB_ATT
to NB UEs

Performance Aspects
New counters
NB_IOT_S1_SIGN_CONN_ES This counter provides the number of attempted UE-associated logical S1-
TAB_ATT connection establishments from eNB to MME
(M8066C4)
Trigger event: This counter is updated on the transmission of an
#LTE NB-IoT S1AP:INITIAL UE MESSAGE by the eNodeB to the MME.
Use case:
Logical S1 Signaling Connection Success Ratio
Above KPI is monitoring logical S1 Signaling Connection Success Ratio
between eNB and MME for NB UEs in the same way as LTE_5526a for non NB
UEs. Also it is used for pricing purposes.
Logical S1 Signaling NB_IOT_S1_SIGN_CONN_ESTAB_SUCC

= ×100%
Connection Success NB_IOT_S1_SIGN_CONN_ESTAB_ATT
Ratio

Performance Aspects
New counters
NB_IOT_S1_SIGN_CONN_ES This counter provides the number of successful UE-associated logical S1-
TAB_SUCC connection establishments from eNB to MME.
(M8066C5)
Trigger event: The counter is updated on receipt by the eNB of the first
#LTE NB-IoT message from MME which succeeds INITIAL UE MESSAGE message on a UE-
associated
logical S1-connection.
Use case:
Logical S1 Signaling Connection Success Ratio
Above KPI is monitoring logical S1 Signaling Connection Success Ratio
between eNB and MME for NB UEs in the same way as LTE_5526a for non NB
UEs. Also it is used for pricing purposes.
Logical S1 Signaling NB_IOT_S1_SIGN_CONN_ESTAB_SUCC
Connection Success
= ×100%
NB_IOT_S1_SIGN_CONN_ESTAB_ATT
Ratio

Performance Aspects
New counters
NB_IOT_RRC_CONN_UE_DE This counter provides the number of samples taken for counter
NOM NB_IOT_RRC_CONN_SUM. It is used as the denominator for the average
(M8066C6) calculation.
#LTE NB-IoT Trigger event: This counter is incremented by value 1 when the number of
RRC connected NB-IoT UEs - provided by a single sample - is added to
counter NB_IOT_RRC_CONN_SUM.
Use case:
Average number of RRC connected NB UEs
Monitoring of the number of RRC connected for NB UEs in the same way as
LTE_5242b, LTE_5842a for legacy UEs.
Average number of NB_IOT_RRC_CONN_SUM
=
RRC connected NB NB_IOT_RRC_CONN_UE_DENOM
UEs

Performance Aspects
New counters

NB_IOT_UE_CTX_REL_UE_IN This counter provides the number of transitions to ECM_IDLE due to "user inactivity"
ACTIVE
Trigger event: The counter is updated on transmission of an S1AP:UE CONTEXT
(M8066C7) RELEASE REQUEST message sent by the eNB to the MME with release cause "user
inactivity".
#LTE NB-IoT
Use case:
Abnormal UE movement to idle state
There is no possibility to monitor E-RAB Drop Ratio, because no data radio bearer is
going to be established, but at least with this counter operator will be able to see any
abnormal UE movement to ECM-Idle state.
NB_IOT_UE_CTX_REL_ENB_INIT + NB_IOT_UE_CTX_REL_MME_INIT - NB_IOT_UE_CTX_REL_UE_INACTIVE - NB_IOT_UE_CTX_REL_DETACH - NB_IOT_UE_CTX_REL_NORM

UE Transaction
to ECM-IDLE =
State Drop NB_IOT_UE_CTX_REL_ENB_INIT + NB_IOT_UE_CTX_REL_MME_INIT
Ratio

Performance Aspects
New counters

NB_IOT_UE_CTX_REL_RRNA This counter provides the number of transitions to ECM_IDLE due to "Radio resources not
(M8066C8) available".
Trigger event: The counter is updated on transmission of an S1AP:UE CONTEXT

#LTE NB-IoT RELEASE REQUEST message sent by the eNB to the MME with release cause "Radio
Network Layer Cause - Radio resources not available".
Use case:
NB_IOT_UE_CTX_REL_ENB_INIT + NB_IOT_UE_CTX_REL_MME_INIT - NB_IOT_UE_CTX_REL_UE_INACTIVE - NB_IOT_UE_CTX_REL_DETACH - NB_IOT_UE_CTX_REL_NO

UE Transaction
to ECM-IDLE =
Ratio

Performance Aspects
New counters

NB_IOT_UE_CTX_REL_DETA This counter provides the number of transitions to ECM_IDLE due to UE detach.
CH
Trigger event: The counter is updated on receipt of of an S1AP:UE CONTEXT RELEASE
(M8066C9) COMMAND sent by the MME to the eNB with release cause "detach"
#LTE NB-IoT Use case:


UE Transaction
to ECM-IDLE =
Ratio

Performance Aspects
New counters

NB_IOT_UE_CTX_REL_NORM This counter provides the number of transitions to ECM_IDLE due to normal call release.
AL
Trigger event: The counter is updated on receipt of of an S1AP:UE CONTEXT RELEASE
(M8066C10) COMMAND sent by the MME to the eNB with release cause "Normal release"
#LTE NB-IoT Use case:


UE Transaction
to ECM-IDLE =
Ratio

Performance Aspects
New counters
NB_IOT_UE_CTX_REL_ENB_I This counter provides the number of transitions to ECM_IDLE due to any kind of RAN
NIT reasons.
(M8066C11) Note: this includes the more specific release causes as well.
#LTE NB-IoT Trigger event: The counter is updated on transmission of an S1AP: UE CONTEXT
RELEASE REQUEST message sent by the eNB to the MME - irrespective of the release
cause.
Use case:

UE Transaction
to ECM-IDLE =
Ratio

Performance Aspects
New counters

NB_IOT_UE_CTX_REL_MME_I This counter provides the number of transitions to ECM_IDLE due to any kind of EPC
NIT reasons.
(M8066C12) Note: this includes the more specific release causes as well.
#LTE NB-IoT Trigger event: The counter is updated on receipt of of an S1AP:UE CONTEXT RELEASE
COMMAND sent by the MME to the eNB - irrespective of the release cause.
Use case:

UE Transaction
to ECM-IDLE =
Ratio

Performance Aspects
New counters
NB_IOT_RRC_CONN_TIME_S This counter provides the total time of NB-IoT UEs in RRC_CONNECTED state, i.e. from
UM the establishment of an RRC connection to its release.
(M8066C13) Trigger event: The counter is updated on the transmission of an
RRCConnectionRelease-NB message by the time difference between this
#LTE NB-IoT RRCConnectionRelease-NB message and the corresponding
RRCConnectionSetupComplete-NB message.
Use case:
Average session duration of NB UEs
The total time in the numerator of the formula considers only NB UEs which have
successfully completed RRC Connection Setup procedure.
Average Session NB_IOT_RRC_CONN_TIME_SUM

Duration
=
NB_IOT_RRC_CONN_ESTAB_SUCC

Performance Aspects
New counters
NB_IOT_MAC_PDU_VOL_UL This counter provides the size of transport blocks scheduled on NPUSCH. The
(M8066C14) volume of MAC PDUs is considered.
Trigger event: The counter is updated when such a MAC PDU is scheduled in UL.
#LTE NB-IoT
Retransmissions are included.
Use case:
MAC PDU volume related to NB UEs in UL and DL
Utilization Ratio in DL/UL
The above two KPIs proposed are monitoring MAC PDU volume and PRB Utilization
Ratio for NB UEs in the same way as NPO KPIs for non NB UEs. Both of these KPIs
can be used to monitor MAC PDU available throughput (MAC PDU volume /
measurement period / PRB Utilization Ratio).

Performance Aspects
New counters

NB_IOT_MAC_PDU_VOL_DL This counter provides the size of transport blocks scheduled on NPDSCH. The volume of
(M8066C15) MAC PDUs is considered.
Trigger event: The counter is updated when such a MAC PDU is scheduled in DL.
#LTE NB-IoT
Retransmissions are included.
Use case:
MAC PDU volume related to NB UEs in UL and DL
Utilization Ratio in DL/UL
The above two KPIs proposed are monitoring MAC PDU volume and PRB Utilization Ratio
for NB UEs in the same way as NPO KPIs for non NB UEs. Both of these KPIs can be used
to monitor MAC PDU available throughput (MAC PDU volume / measurement period / PRB
Utilization Ratio).

Performance Aspects
New counters

NB_IOT_RESOURCES_USED_ This counter provides the number of concurrently used NB-IoT
UL subcarriers in UL, which are measured during a 1 millisecond interval
(M8066C16) and accumulated over the measurement period.
#LTE NB-IoT Trigger event: This counter is updated after each 1 ms interval, in
which UL resources for NB-IoT UEs were reserved. It is incremented by
the number of subcarriers (granularity of 3.75 kHz) used in parallel by
any NB-IoT UE. (15 kHz subcarriers result in an increment of 4 per
interval).
Note: In case of NB-IoT inband mode, this 1 ms interval corresponds to a
subframe of the hosting WB cell, i.e. a subframe containing one or more
host PRBs allocated to NB-IoT UEs. These PRBs are considered unusable
from host cell perspective.

Performance Aspects
New counters
NB_IOT_TIME_RESERVED_U This counter provides the number of 1 millisecond intervals, in which UL resources for
L NB-IoT UEs were configured (NPRACH) or allocated (NPUSCH) in the cell.
(M8066C17) Trigger event: This counter is updated after each 1 ms interval, in which UL resources
for NB-IoT UEs were configured or allocated.
#LTE NB-IoT Note: In case of NB-IoT inband mode, this 1 ms interval corresponds to a subframe of the
hosting WB cell, i.e. contains one or more host PRBs allocated to NB-IoT UEs, which are
considered unusable from host cell perspective.
Use case:
Utilization Ratio in UL
PRB Utilization Ratio for NB UEs in the same way as NPO KPIs for non NB UEs. It can be
used to monitor MAC PDU available throughput (MAC PDU volume / measurement
period / PRB Utilization Ratio).
Utilization Ratio NB_IOT_TIME_RESERVED_UL

= ×100%
in UL NB_IOT_RRC_CONN_TIME_SUM

Performance Aspects
New counters

NB_IOT_RESOURCES_USED_ This counter provides the number of concurrently used NB-IoT PRB in DL, which are
DL measured during a 1 millisecond interval and accumulated over the measurement
period.
(M8066C18)
Trigger event: This counter is updated after each 1 ms interval, in which DL resources
#LTE NB-IoT for NB-IoT UEs were reserved. It is incremented by the number of PRB (granularity of 180
kHz) used in parallel by any NB-IoT UE.
Note: In case of NB-IoT inband mode, this 1 ms interval corresponds to a subframe of the
hosting WB cell, i.e. a subframe containing one or more host PRBs allocated to NB-IoT
UEs. These PRBs are considered unusable from host cell perspective.

Performance Aspects
New counters

NB_IOT_RESOURCES_AVAIL This counter provides the number of concurrently available NB-IoT PRBs
_DL in DL, which are measured during a 1 millisecond interval and
(M8066C19) accumulated over the measurement period.
#LTE NB-IoT Trigger event: This counter is updated after each 1 ms interval, in
which DL resources for NB-IoT UEs were reserved. It is incremented by
the number of available PRBs (granularity of 180 kHz) in parallel by any
NB-IoT UE.
Note: In case of NB-IoT inband mode, this 1 ms interval corresponds to a

subframe of the hosting WB cell, i.e. contains one or more host PRBs
allocated to NB-IoT UEs, which are considered unusable from host cell
perspective.

Performance Aspects
New counters

RRC paging requests This counter provides the number of RRC paging requests (records) for
(records) for NB-IoT UEs NB-IoT UEs.
(M8066C20)
#LTE NB-IoT Trigger event: This counter is updated for each paging record of an
RRC paging message triggered due to S1 paging.
User Case:
RRC Paging Records
The KPI proposed is monitoring RRC Paging Records in the same way as
LTE_5122b for non NB UEs.

Performance Aspects
New counters

Discarded RRC paging This counter provides the number of dropped RRC paging records for
requests (records) for NB- NB-IoT UEs due to paging record list overflow.
IoT UEs due to paging
record list overflow Trigger event: This counter is updated when the maximum number of
(M8066C21) paging records is reached for the next paging occasion that corresponds
to the paging request..
#LTE NB-IoT
User Case:
RRC Paging Records
The KPI proposed is monitoring RRC Paging Discard Ratio in the same
way as LTE_5031b for non NB UEs.

Performance Aspects
New counters

Discarded RRC paging This counter provides the number of dropped RRC paging records for
requests (records) for NB- NB-IoT UEs due to overlapping paging occasions (POs).
IoT UEs due to paging
occasion overlap
(M8066C22) Trigger event: This counter is updated when the next paging occasion
that corresponds to the paging request is overlapped by the previous
#LTE NB-IoT ongoing paging transmission.
User Case:
RRC Paging Records
The KPI proposed is monitoring RRC Paging Discard Ratio in the same
way as LTE_5031b for non NB UEs.

Performance Aspects
New counters

Attempted RRC Connection This counter provides the number of attempted RRC Connection
Establishments with cause Establishment requests with cause "mt-Access" for NB-IoT UEs.
"mt-Access" for NB-IoT Ues
(M8066C23)
Trigger event: This counter is updated on the receipt of an
#LTE NB-IoT RRCConnectionRequest-NB message with establishment cause "mt-
Access" for an NB-IoT UE.
User Case:
The KPI proposed is monitoring RRC Connection Setup Success Ratio in
the same way as LTE_5218f for non NB UEs.

Performance Aspects
New counters

Successful RRC Connection This counter provides the number of successful RRC Connection
Establishments with cause Establishments with cause "mt-Access" for NB-IoT Ues.
"mt-Access" for NB-IoT Ues
(M8066C24) Trigger event: This counter is updated on the receipt of an
RRCConnectionSetupComplete-NB message (UE -> eNB) in case that
#LTE NB-IoT this message was received from an NB-IoT UE and this UE requested the
connection with cause "mt-Access".
User Case:
The KPI proposed is monitoring RRC Connection Setup Success Ratio in
the same way as LTE_5218f for non NB UEs.


07 NB-IoT C&P Impact Summary

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

07 NB-IoT C&P Impact Summary

Transféré par

Droits d'auteur :

Formats disponibles

NB-IoT C&P Impact

Compiled by Zhang Jennie

1 © Nokia Networks 2017

3 © Nokia Networks 2017

4ms + kdelay valid subframes given in DCI NPUSCH (A/N)

4 © Nokia Networks 2016

ITBS 11 and 12 are valid only in stand-alone and guard-

5 © Nokia Networks 2016

680 bits * 4ms is the best case; actual timing

• Instantaneous peak rate (in-band) is is given by:

6 © Nokia 2017 Nokia Internal Use

7 © Nokia 2017 Nokia Internal Use

{8,16,32,64}ms as indicated in DCI

8 © Nokia Networks 2016

For multi tone, ITBS support 0-12.

For single tone, ITBS support 0-10.

9 © Nokia Networks 2016

• Instantaneous throughput is given by:

10 © Nokia 2017 Nokia Internal Use

12 © Nokia Networks 2017

Transmit Losses and Receiver

14 © 2017 Nokia Internal

15 © 2017 Nokia Internal

16 © 2017 Nokia Internal

Thermal noise level

SensitivitydBm = 10.log10(Nth.W.F) + SINRdB

• Nth: thermal noise density, 10log(KB.T) = -174 dBm/Hz

Reference Signal (legacy LTE) [%] 9.52% - numSib1RepNB

Total system overhead [%] 69.15% 16.25%

19 © Nokia 2017 Nokia Internal Use

LTE3071 supports only UE

20 © Nokia 2017 Nokia Internal Use

LTE3071 supports only single

Note: 3GPP Normal coverage pathloss (144dB) has different assumptions

21 © Nokia 2017 Nokia Internal Use

Cell Range [km] 0.78 1.45 3.93 20.66

22 © Nokia 2017 Nokia Internal Use

23 © Nokia Networks 2017

Report type Packet size Inter-arrival time

Mobile Autonomous Reporting (MAR) UL: 20 bytes Months to years (reaction

24 © Nokia 2017 Nokia Internal Use

25 © Nokia 2017 Nokia Internal Use

26 © Nokia Networks 2017

27 © Nokia 2017 Nokia Internal Use

NPRACH periodicity [ms] 160

29 © Nokia 2017 Nokia Internal Use

RRC: Connection Request

repetition RRCConnectionSetup scheduling

• In UL direction 11 UEs can be scheduled simultaneously, RRCConnectionSetup-NB

30 © Nokia 2017 Nokia Internal Use

• Additional overhead for common channels have to be considered as well.

G 2 2 2 npdcchStartSfRa Example: Message size 200 bytes,

31 © Nokia 2017 Nokia Internal Use

680 bits 680 bits

32 © Nokia 2017 Nokia Internal Use

• Each NPDCCH have to be scheduled 8 ms

Random Access Response msg2

33 © Nokia 2017 Nokia Internal Use

for NPUSCH and NPDSCH: NPRACH transmission lenght [ms] 26

• Hence modified RACH procedure time: 211 ms

1000 ∙11 ∙ 3600 ∙ ( 1 −16 % ) ∙ 90 %

NB-IoT Scheduling UE/TTI

NB-IoT UEs and CA Capacity