NB IOT Session

NB-IOT
Prepared by: Somnath Ray Chowdhury

Internet of Things
2 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

IOT available solutions:

NB-IoT Use Cases

NB-IoT Overview

Objective and Techniques
The main design objectives of NBIoT are:
• Increased coverage,
• Long battery life (between 10 and 15 years), and
• Low user equipment (UE) device complexity.
To achieve these targets, several techniques have been

adopted:
• Repetitions,
• power spectral density boosting,
• Coverage Enhancement,
• eDRX,
• Power saving mode,
• phase rotated modulations (e.g π/2 -BPSK and π/4 -QPSK) to reduce peak-to-
average power ratio in the uplink, leading to low cost power amplifier.

Content
• Narrow Band Frame Structure
• NB-IoT UE Categories
• NB-IoT Channels
• RACH Process
• Enhanced Coverage
• Wireshark Traces for CP-IOT and UP-IOT
• PSM
• eDRX
• NB-IOT Deployment types
• PRB, CRS sequence and Tx/Rx Freq Calculation.

NB-IoT basic details

NB-IoT Deployment Types
• In-band Operation using one PRB of a LTE carrier
• Guard band Operation by using used Resource Blocks
within LTE carrier Guard Band
• Standalone Operation by using a GSM 200KHz carrier

LTE CAT-M1 vs NB-IoT

NB-IoT: Focus areas
• NB-IoT focusses on low-cost devices with lower-energy
consumption and higher coverage requirements. NB-IoT
meets these key demands by means of
• i) the use of a small portion of the existing available
spectrum.
• ii) a new radio interface design.
• iii) simplified LTE network functions.

NB-IoT Operating Bands (Rel 13 and 14 supports NB-IoT in HD-FDD only, Rel 15 introduced
NB-IoT in TDD ass well with Frame Type 2)

Narrow Band IoT UE Categories
TBCC: To reduce UE complexity, all the downlink channels use the LTE tail-biting convolutional code (TBCC).
Furthermore, the maximum transport block size of NPDSCH is 680 bits. In comparison, LTE without spatial multiplexing
supports maximum TBS greater than 70,000 bits.

Narrow Band IoT Frame Structure
• At the highest level, it starts with hyperframe cycle where one hyperframe cycle
has 1024 hyperframes and each consisting of 1024 frames.
• The hyperframe is introduced to achieve higher values of EDRX timer.
• One frame consists of 10 sub-frames and each subframe is dividable into two
slots each of 0.5 ms which is similar to traditional LTE system. In the DL and UL,
the NB-IoT design supports a sub-carrier spacing of 15 KHz, for which each frame
contains 20 slots. In the UL, the NB-IoT design supports an additional sub-carrier
spacing of 3.75 KHz. For this alternative sub-carrier spacing, each frame is
directly divided into five slots, each of 2 ms, there is no subframe concept.
• Each NB-IoT subframe spans over one PRB (i.e. 12 subcarriers) in the frequency
domain and 1 ms in the time domain

• The hyperSFN is running on top of SFN. When SFN hits the max (1023) and
rollover to the beginning the hyperSFN gets incremented by 1. It means 1
hyperSFN corresponds to 1024 SFN (1024*1024* 10 ms = 3 hours).
• SIB1 would carry a special IE called hyperSFN to carry the current hyperSFN
number.
• Hyperframe: Hyper System Frame Number (H-SFN), Range : 0 – 1023
• Frame System Frame Number (SFN), Range : 0 – 1023
• Subframe: Subframe Number (SN), Range : 0 – 9
• Each subframe can therefore be uniquely identified by an H-SFN, an SFN, and a
subframe number (SN).

Case #1 Downlink and Uplink Subcarrier Spacing 15KHz

• Cycle Duration:
• Duration of a Frame cycle =(No. of Frame in one cycle) x
(Duration of one frame)
= 1024 x 10 ms =10240 ms =
10.24 seconds
• Duration of a Hyperframe cycle = (No. of Hyperframe in
one cycle) x (Duration of one Hperframe)
= 1024 x 10.24 s =104857.60
ms = 2 Hours, 54 minutes and 46 seconds

Case #2 Uplink Subcarrier Spacing 3.75 KHz

Narrow Band IoT UE Categories
• Narrow Band IoT specifications was first introduced in
3GPP release 13 and then further enhanced in 3GPP
release 14 with some essential features.
• Release 13 NB-IoT device category is referred as Cat NB1
and Release 14 devices are referred as Cat NB2

Benefits of Cat NB2 device over Cat NB1 device
• Support of Positioning of Device using OTDOA
• Mobility enhancement from seamless cell re-selection
• Push to talk voice messaging
• New Device Power Class (14 dBm)
• Multicast transmission
• Note: Observed Time Difference Of Arrival (OTDOA) is a Release 9 positioning

method, in which the UE measures the downlink Positioning Reference Signal
(PRS) time difference of arrivals of several neighbor cells in comparison to a
reference cell. The positioning estimation is based on multilateration of these
measurements, also known as Reference Signal Time Difference (RSTD).

Modulation and TBS index table for NPUSCH with

Transport block size (TBS) table for NPUSCH

NB-IOT Channels and Signals
Downlink Channels and Signals
• Narrowband Primary Synchronization Signal (NPSS)
• Narrowband Secondary Synchronization Signal (NSSS)
• Narrowband Physical Broadcast Channel (NPBCH)
• Narrowband Physical Downlink Control Channel (NPDCCH)
• Narrowband Physical Downlink Shared Channel (NPDSCH)
• Narrowband Reference Signal (NRS)
Time multiplexing between NB-IoT downlink physical channels and signals

Upnlink Channels
• Narrowband Physical Random Access Channel (NPRACH)
• Narrowband Physical Uplink Shared Channel (NPUSCH)

NB-IOT Channels and Signals

NB-IOT DL Channel description
• NPSS and NSSS are used by an NB-IoT UE to perform cell search, which includes time and frequency
synchronization, and cell identity detection. Since the legacy LTE synchronization sequences occupy 6 PRBs, they
cannot be reused for NB-IoT.
• NPBCH carries the master information block (MIB) and is transmitted in subframe #0 in every frame. A MIB
remains unchanged over the 640 ms transmission time interval (TTI). (64 subframe * 10 ms).
• NPDCCH carries scheduling information for both downlink and uplink data channels. It further carries the HARQ
acknowledgement information for the uplink data channel as well as paging indication and random access response
(RAR) scheduling information. Also it caries the DCI information.
• NPDSCH carries data from the higher layers as well as paging message, DL Shared channel, system information,
and the RAR message.
• NRS is used to provide phase reference for the demodulation of the downlink channels. NRSs are time-and
frequency multiplexed with information bearing symbols in subframes carrying NPBCH, NPDCCH and NPDSCH, using
8 resource elements per subframe per antenna port.

Synchronization Channels: NCellID
NSSS sequence is generated from a length-131 frequency domain Zadoff-Chu sequence, binary scrambled and
cyclically shifted depending on the radio frame number.are transmitted in the last SF of each even numbered radio
frame
NPSS generation is done by a length 11 Zadoff-Chu sequence in frequency domain. This sequence is fixed and
therefore carries no information about the cell. It is transmitted in SF5 of each radio frame, so that its reception
allows the UE to determine the frame boundary.

Narrowband Physical Broadcast Channel
NPBCH carries the Narrowband Master Information Block (MIB-NB).
The MIB-NB contains 34 bits and is transmitted over a time period of
640ms, i.e. 64 radio frames. The following information is provided
therein:
• 4 bits indicating the most significant bits (MSBs) of the System Frame Number
(SFN), the remaining least significant bits (LSBs) are implicitly derived from the
MIB-NB start
• 2 bits indicating the two LSBs of the hyper frame number
• 4 bits for the SIB1-NB scheduling and size
• 5 bits indicating the system information value tag
• 1 bit indicating whether access class barring is applied
• 7 bits indicating the operation mode with the mode specific values
• 11 spare bits for future extensions

• After physical layer baseband processing, the resulting MIB-NB is split into 8 blocks. The first block is
transmitted on the first subframe (SF0) and repeated in SF0 of the next 7 consecutive radio frames,
respectively. In SF0 of the following radio frame, the same procedure is done for BL2. This process is
continued until the whole MIB-NB is transmitted. By using SF0 for all transmissions, it is avoided
that NPBCH collides with a potential MBSFN transmission on LTE, if NB-IoT is deployed as
in-band operation.

• Symbols are mapped around the NRS and the LTE CRS, where it is always assumed that two antenna
ports are defined for NRS and 4 antenna ports for CRS. This assumption is necessary, because the UE
gets the actual antenna port information only from reading the MIB-NB. The reference signal location
in the frequency range is given by the NCellID, provided by the NSSS. Although the NCellID may be
different to the PCI in the in-band operation, its range is restricted so that it points to the same
frequency locations, hence the CRS's cyclic shift in the frequency range is known to the UE. Again, the
first 3 OFDM symbols are left out in order to avoid a possible conflict with the LTE's control channel.

NPDCCH:

NPDCCH Format:

DCI:
When the UE receives the NPDCCH, it can distinguish the different formats in the
following way:
DCI format N2 is implicitly indicated in the way that the CRC is scrambled with the P-RNTI.
If the CRC is scrambled with the C-RNTI, then the first bit in the message indicates whether DCI format
N0 or N1 is contained.
For the case that the CRC is scrambled with the RA-RNTI, the content is a restricted DCI format N1
including only those fields required for the RACH response

NPDSCH
• SIB1-NB is transmitted over the NPDSCH. Its has a period of 256 radio frames and is repeated 4, 8 or
16 times.
• The transport block size and the number of repetitions is indicated in the MIB-NB. 4, 8 or 16
repetitions are possible, and 4 transport block sizes of 208, 328, 440 and 680 bits are defined,
respectively.
• The radio frame on which the SIB1-NB starts is determined by the number of repetitions and the
NCellID.
• SF4 is used for SIB1-NB in all radio frames transmitting SIB1-NB.
• As the other transmission parameters are also fixed, there is no associated indication in the control
channel.
• SIB1-NB content may only be changed on each modification period, which has a length of 4096 radio
frames, i.e. 40.96 seconds.
• This corresponds to 4 SFN periods, which is why the 2 LSBs of the hyper frame number are indicated
in MIB-NB. If such a modification occurs, it is indicated in the NPDCCH using DCI format N2.

NB-IOT UL Channel description
• NPRACH is a newly designed channel since the legacy LTE Physical Random Access Channel (PRACH>.
One NPRACH preamble consists of 4 symbol groups, with each symbol group comprising of one CP
and 5 symbols. The CP length is 66.67 micro second (Format 0) for cell radius up to 10 km and 266.7
micro second (Format 1) for cell radius up to 40 km. Each symbol, with fixed symbol value 1, is
modulated on a 3.75 kHz tone with symbol duration of 266.67 micro second. The tone frequency
index changes from one symbol group to another. The waveform of NPRACH preamble is referred to
as single-tone frequency hopping. To support coverage extension, a NPRACH preamble can be
repeated up to 128 times.
• NPUSH Format is of two types:
• NPUSCH Format 1 is used for carrying uplink data and uses the same LTE turbo code for error
correction. The maximum transport block size of NPUSCH Format 1 is 1000 bits, which is much lower
than that in LTE.
• NPUSCH Format 2 is used for signaling HARQ acknowledgement for NPDSCH, and uses a repetition
code for error correction.
Note: 1> The DM-RS is transmitted in every NPUSCH slot with the same bandwidth as the associated NPUSCH. The
reference signals depend on the number of subcarriers NscRU, the narrowband cell ID NNcellID and the NPUSCH format.
The RE positions depend on the NPUSCH format and subcarrier spacing. For NPUSCH format 1 with subcarrier spacing
of 3.75kHz, the DM-RS is transmitted on symbol 4 and with subcarrier spacing of 15kHz, the DM-RS is transmitted on
symbol 3. For NPUSCH format 2 with subcarrier spacing of 3.75kHz, the DM-RS is transmitted on symbols 0,1,2 and with
subcarrier spacing of 15kHz, the DM-RS is transmitted on symbols 2,3 and 4 in the slot.
Note: 2> PUCCH, PHICH, PCFICH are not present in NB-IoT.
NPRACH Transmission(Spec Ref: TS 136 211 V14.2.0, section:10.1.6)
• NPRACH can be transmitted only at one specific timing within a NPRACH period as illustrated
below. nprach-StartTime, nprach-Periodicity is configured by Higher Layer (SIB2): -

NB-IOT UL Channel description

NPUSCH Format 1 vs NPUSCH Format 2

NB-IoT Uplink Frame Structure
The above table shows the Tone allowed in formats

Preamble (Spec Ref: TS 136 211 V14.2.0, section:10.1.6)
• The physical layer random access preamble is based on single-subcarrier frequency-hopping symbol
groups. A symbol group is illustrated below, consisting of a cyclic prefix of length TCP and a sequence
of 5 identical symbols with total length TSEQ .
• The preamble consisting of 4 symbol groups transmitted without gaps, shall be transmitted for
NPRACH Nrep times. In NB-IOT, there are only two Preamble formats. the length of Sequence part of
Preamble format 0 and 1 are same. The difference lies in the length of CP.

Preamble (Spec Ref: TS 136 211 V14.2.0, section:4)
• TSEQ= 5* 8192* Ts, where , Ts= 1/(15000*2048) seconds ,

i.e. Ts= 0.0325 * 10^-6 seconds, So, Ts= 0.0325 micro seconds.
So, TSEQ = 5* 8192* 0.0325 microseconds= 13331.2 microseconds = 1.333 milliseconds.
• TCP= 2048* Ts, where , Ts= 0.0325 microsecond. ------------------------Preamble Format 0

So, TCP = 2048* 0.0325 = 66.67 microseconds.
• TCP= 8192* Ts, where , Ts= 0.0325 microsecond. ------------------------Preamble Format 1

So, TCP = 8192* 0.0325 microseconds= 266.24 microseconds.
The CP length is 66.67 micro second (Format 0) for cell radius up to 10 km

and 266.7 micro second (Format 1) for cell radius up to 40 km

NPUSCH Format and Tone discussion
To understand more about Tone please refer the
below two examples: 36.213 Table 16.5.1.1-1
1> It is for NPUSCH format 1, Sub Carrier Spacing = 15 Khz, the number of
sub carrier in one RU is 1 and the number of slots within the RU is 16. The
graphical representation that is interpreted is as shown below the table.



NB-IOT Downlink Scheduling Spec: 11.1.1, 36 300 V14.2.0
• Scheduling information for downlink data is transmitted on the downlink physical control
channel NPDCCH. The scheduled downlink data is transmitted on the shared data channel
NPDSCH;
• Only cross-subframe scheduling is supported, cross-carrier scheduling is not supported.
The transmission duration in number of sub-frames for the NPDCCH and the NPDSCH is
variable;
• The transmission duration in number of sub-frames is semi-static for the NPDCCH and is
indicated for the NPDSCH as part of the scheduling information transmitted on the
NPDCCH;
• The start time of the NPDSCH relative to the NPDCCH is signaled as part of the
scheduling message.

NB-IOT Uplink Scheduling Spec: 11.1.2, 36 300 V14.2.0
• Scheduling information for uplink data is transmitted on the downlink physical control
channel NPDCCH. The scheduled uplink data is transmitted on the shared data channel
NPUSCH;
• The transmission duration in number of sub-frames for the NPUSCH is variable;
• The transmission duration in number of sub-frames is semi-static for the NPDCCH and is
indicated for the NPUSCH as part of the scheduling information transmitted on the
NPDCCH;
• The start time of the NPUSCH relative to the NPDCCH is signaled as part of the
scheduling message.

NB-IOT DL Throughput Calculation
eNodeB transmitted NPDCCH (DCI) indicating that there will be downlink data
over NPDSCH for the device. Since the NB-IOT devices are expected to have reduced
compute capability, there is a time offset given between end of NPDCCH transmission
and beginning of NPDSCH transmission which is at least 4 ms.
Once the device receives NPDSCH block carrying DL data, it take 4 ms to decode in good
radio condition with Modulation coding scheme (MCS) 10 and maximum transport block
(TB) 680 bits and transmit HARQ acknowledgement on NPUSCH. The time offset
between end of NPDSCH and start of NPUSCH is at least 12 ms.
The device send HARQ acknowledgement on NPUSCH and to listen the next NPDCCH if
there is more data on the way. It takes at least 3 ms before device starts listen to the
next NPDCCH.

NB-IOT Downlink Throughput calculation:
Peak Throughput=
Maximum Transport Block / Transmission Time Interval = 680 bits /4 ms
170 kbps

Throughput (With out NPBCH/PSS/SSS)
680 bits/ NPDCCH duration (1 ms) + offset (4 ms) + NPDSCH duration (3ms) + offset
(12 ms) + NPUSCH duration (2ms) + offset (3ms)
So, 680 bits / 1 ms +4 ms +4 ms + 12 ms + 2 ms + 3ms = 680 bit / 26 ms = 26.15 kbps
Throughput (With NPBCH/PSS/SSS) : within 20 ms NPBCH and NPSS is transmitted

two time, NSSS is transmitted one time. It makes total as 25% as an overhead
0.75 x 26.15 kbps = 19.6 kbps.

NB-IOT UL Throughput Calculation
eNodeB sends a NPDCCH (DCI) to device, signaling about the scheduled grant.
It takes at least 8 ms before the device sends NPUSCH for uplink data transmission
Assuming good radio conditions.
Maximum Transport Block (TB) of 1000 bits and all 12 tone (subcarriers) are used, it
takes 4 ms time to send data over NPUSCH and receives its acknowledgement from
eNodeB over NPDCCH. The time offset between the end of the NPUSCH and beginning
of the NPDCCH at least 3 ms
The device receives HARQ acknowledgement on NPDCCH and possible next grant

NB-IOT Uplink Throughput calculation:
Peak Throughput=
Maximum Transport Block / Transmission Time Interval = 1000 bits /4 ms
250 kbps

Throughput (With out NPRACH) - Single User
1000 bits/ NPDCCH duration (1 ms) + offset (8 ms) + NPUSCH duration (4ms) +
offset (3ms)
1000 bits / 1 ms + 8 ms + 4 ms + 3ms = 1000 bit / 16 ms = 62.5 kbps
Throughput (With NPRACH) : Assuming NPRACH is a 10% overhead - Single User
0.9 x 66.5 kbps = 56.25 kbps

Explanation for DL TP and Latency Calculation:
NPDCCH (DCI) === Table 16.6-3: Type 2, 36.213 R =1 is the lowest value, so 1 ms.
NPDCCH to NPDSCH ==== 4ms , 16.4.1, 36.213 (starting in n+5 DL subframe, ni with i = 0, 1, …, N-1
according to the NPDCCH information) NPDSCH === 4ms It is 4 The TBS is given by the ( TBS I , SF I )
entry of Table 16.4.1.5.1-1. For the value of the higher layer parameter operationModeInfo set to
‘00’ or ‘01’, 0 ≤ ITBS ≤ 10.
NPDSCH to NPUSCH format2 =12 ms , spec: 36.213 version 13.7.0, section 16.4.2, The UE shall upon
detection of a NPDSCH transmission ending in NB-IoT subframe n intended for the UE and for which
an ACK/NACK shall be provided, start, after the end of n + k −1 DL subframe transmission of the
NPUSCH carrying ACK/NACK response using NPUSCH format 2 in N consecutive NB-IoT UL slots
NPUSCH Format 2 = 2 ms, Table 10.1.2.3-1, 36.211. [ Subcarrier can be max 1 for this, and that will
use 4 slots, so, 2 ms.]
NPUSCH to NPDCCH======3ms , Spec Ref: 16.6, 36.213 version 13.7.0(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).

Explanation for UL TP and Latency Calculation:
NPDCCH (DCI) ===Table 16.6-3: Type 2, 36.213
NPDCCH to NPUSCH ==== 8 ms, Section: 16.5.1, Table 16.5.1-1: k0 for DCI format N0, 36.213,
starting n+k0, k0 min value is 8.
NPUSCH format 1=== 4ms, Table 16.5.1.2-2, of 36.213 version 13.7.0, (Table 10.1.2.3-1 of 36.211),
[IRU can be of max 4 Subframes and with 12 subcarriers there will be 2 slots, 2 slots= 1 ms. and 4
subframes * 1ms = 4 ms]
NPUSCH to NPDCCH======3ms , Spec Ref: 36.213 version 13.7.0(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).

Carrier frequency and EARFCN for NB1 and NB2:
DL Carrier Frequency:
FDL = FDL_low + 0.1(NDL – NOffs-DL) + 0.0025*(2MDL+1)
FDL = is the downlink carrier frequency of category NB1/NB2
NDL = downlink EARFCN,
MDL = Offset of category NB1/NB2 Channel Number to downlink EARFCN.
NOffs-DL Offset used for calculating downlink EARFCN
FDL_low = The lowest frequency of the downlink operating band
NOffs-DL and FDL_low are to be calculated from the below table.
UL Carrier Frequency:
FUL = FUL_low + 0.1(NUL – NOffs-UL) + 0.0025*(2MUL)
FUL = is the uplink carrier frequency of category NB1/NB2,
NUL = uplink EARFCN,
MUL = Offset of category NB1/NB2 Channel Number to uplink EARFCN.
NOffs-UL = The lowest frequency of the uplink operating band
FUL_low The lowest frequency of the uplink operating band
NOffs-UL and FUL_low are to be calculated from the below table.
Section: 5.7.3F, TS 36 101 V14.5.0.

Carrier frequency and EARFCN for NB1 and NB2:
MDL {-10,-9,-8,-7,-6,-5,-4,-3,-2,-1,-0.5,0,1,2,3,4,5,6,7,8,9}
MUL {-10,-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9}
NOTE 1: For category NB1/NB2, NDL or NUL is different than the value of EARFCN that
corresponds to E-UTRA downlink or uplink carrier frequency for in-band and guard band
operation.
NOTE 2: MDL = -0.5 is not applicable for in-band and guard band operation.
NOTE 3: For the carrier including NPSS/NSSS for in-band and guard band operation, MDL
is selected from {-2,-1,0,1}.
NOTE 4: For the carrier including NPSS/NSSS for stand-alone operation, MDL = -0.5.

DL PRB Calculation Process: Spec Ref: 36.213, Section: 16.8
To calculate the DL PRB CRS-Sequence info is important parameter: which set by MIB.

DL PRB Calculation Process: Spec Ref: 36.213, Section: 16.8
Formula to Calculate the DL PRB:
Now, for 20 MHz is 100, if crs-sequence info set to max, then the
has to be 45.
is 95 (the max Possible, NB-IOT PRB)
So the Calculated value will be, = = 95 – (100/2) = 95- 50 = 45
Note: For uplink carrier and non anchor carrier, there are no limitations.

NB-IOT Data CallFlow
4.3.17.8.2 ESM Procedures, 23.401 v 14.03

The UE indicates in the ESM connection request, e.g. in Attach or PDN Connectivity Request, that a Non-IP PDN type shall be used.
The subscription information has a default APN for PDN Type Non-IP, which the MME uses for the first received Non-IP connectivity
request unless the UE has included an APN in the request.

LTE User Plane Protocol Stack

NB-IOT Control Plane Non-IP Connection with SCEF Spec: 23 682 V13.9.0
When the UE performs the EPS attach procedure with PDN type of "Non-IP",
and the subscription information corresponding to either the default APN for
PDN type of "Non-IP" or the UE requested APN includes the "Invoke SCEF
Selection" indicator, then the MME initiates a T6a connection towards the SCEF
corresponding to the "SCEF ID" indicator for that APN

NIDD Configuration (NB-IOT Control Plane Non-IP) Connection with SCEF Spec: 23
682 V13.9.0
The SCS/AS sends an NIDD Configuration Request (External Identifier or MSISDN, SCS/AS Identifier,
SCS/AS Reference ID, NIDD Duration, NIDD Destination Address, SCS/AS Reference ID for Deletion)
message to the SCEF

NB-IOT Control Plane MO non-IP data with SCEF Spec: 23 682 V13.9.0

NB-IOT Control Plane MO non-IP data with SCEF Spec: 23 682 V13.9.0

NB-IOT Control Plane Protocol Stack Over Sgi 23.401, 14.03

NB-IOT Attach CallFlow

COMPLETE NPRACH

NPRACH Parameters (Spec Ref: TS 136 211 V14.2.0, section:10.1.6)
• A NPRACH configuration provided by higher layers contains the following: -
NB-IO_Full_Parameter_Details.txt

MasterInformationBlock-NB (Spec Ref: 36 331 V13.9.1, section:6.7.2)

SystemInformationBlockType1-NB (Spec Ref: 36 331 V13.9.1, 6.7.2)


The IE RadioResourceConfigCommonSIB-NB is used to specify common radio resource

configurations in the system information, e.g., the random access parameters and the
static physical layer parameters.

RadioResourceConfigCommonSIB-NB (Spec Ref: 36 331 V13.9.1, 6.7.3)

NPRACH-ConfigSIB-NB (Spec Ref: 36 331 V13.9.1, 6.7.3)
The IE NPRACH-ConfigSIB-NB is used to specify the NPRACH configuration in the
system information.

NPUSCH-Config-NB (Spec Ref: 36 331 V13.9.1, 6.7.3)
The IE NPUSCH-ConfigCommon-NB is used to specify the common NPUSCH configuration.
The IE NPUSCHConfigDedicated-NB is used to specify the UE specific NPUSCH configuration.

UplinkPowerControl-NB (Spec Ref: 36 331 V13.9.1, 6.7.3)
The IE UplinkPowerControlCommon-NB and IE UplinkPowerControlDedicated-NB are used to
specify parameters for uplink power control in the system information and in the dedicated
signalling, respectively.

PDCP-Config-NB (Spec Ref: 36 331 V13.9.1, 6.7.3)
The IE PDCP-Config-NB is used to set the configurable PDCP parameters for data radio
bearers.

NPRACH FACTs (Spec Ref: TS 136 300 V14.2.0, section:10.1.5)
• NB-IoT Contention resolution:
-Contention based [Applicable to all six events, but the sixth event(i.e. positioning purpose during
RRC_CONNECTED requiring random access procedure), for positioning is applicable for NB-IoT only]
-Non-contention based (applicable to only handover, DL data arrival, positioning and obtaining
timing advance alignment for a sTAG), except for NB-IoT.
• For NB-IoT, the random access procedure is performed on the anchor carrier or
on a non anchor carrier based on system information.
• In the Procedure to setup the RRC Connection in Msg3 (During Contention Based
RACH)
-An indication of the amount of data for subsequent transmission(s) on SRB or DRB can be indicated.
Note: Non-anchor carrier: in NB-IoT, a carrier where the UE does not assume that
NPSS/NSSS/NPBCH/SIB-NB are transmitted. And The IE CarrierConfigDedicated-NB is used to specify a
non-anchor carrier in NB-IoT.

Narrow Band IoT- Radio Bearers
• SRB 0: It is used for RRC messages using the CCCH logical channel. SRB0
can be used for exchanging of the RRCConenctionRequest,
RRCConnectionSetup, RRCConnectionResumeRequest,
RRCConnectionReject, RRCConnectionReestablishmentRequest, and
RRCConnectionReestablishment messages with eNodeB.
• SRB1bis: It is for RRC messages (which may include a piggybacked NAS

message) as well as for NAS messages prior to the activation of security,
all using DCCH logical channel. It is established implicitly when
establishing SRB1 after the UE, receives the RRCConnectionSetup.
SRB1bis is the same as SRB1 except that it bypasses the PDCP layer.
SRB1bis is used as long as security is not activated. If security is
activated, SRB1bis is not used but only SRB1 is used.

Narrow Band IoT- Radio Bearers
• SRB1: Used for RRC signalling message transfer after the security is
activated. SRB0 is used before Access Stratum (AS) security is
activated and only SRB1 is supported after AS security is activated.
• DRB0 and DRB1: A maximum of two data radio bearers are used
for exchanging data messages with the eNodeB. For a UE to
support two DRBs, it must have its multi-DRB capability enabled;
otherwise, UE supports only a single DRB
SRB0 and SRB1bis both use Transparent Mode (TM) at RLC sublayer

NB-IoT operating modes to provide deployment flexibility:
• Stand-alone: utilizing, for example, one or more GSM

carriers.
• Guard-band: utilizing the unused resource blocks within
an LTE carrier’s guard-band.
• In-band: utilizing resource blocks within an LTE carrier.
• Additionally, NB-IoT uses the concept of repetitions and signal combining

techniques to improve coverage extension. To serve UEs in different coverage
conditions that have different ranges of path loss, there may be up to three
coverage enhancement (CE) configurations in the random access with their
specific settings. After that, the eNodeB selects the configuration of the radio
resources, the Modulation and Coding Scheme (MCS) and repetitions depending
on UE’s coverage.

Control Plane CIoT EPS optimizations Spec: 7.3a.2, 36 300 V14.2.0
The RRC connection established for Control Plane CIoT EPS optimizations:
• A UL NAS signaling message or UL NAS message carrying data can be transmitted in a
UL RRC container message (see Figure 7.3a.2-1). A DL NAS signaling or DL NAS data
can be transmitted in a DL RRC container message;
• RRC connection reconfiguration and RRC connection re-establishment are not supported
• Data radio bearer (DRB) is not used;
• AS security is not used;
• There is no differentiation between the different data types (i.e. IP, non-IP or SMS)
in the AS.

User Plane CIoT EPS optimizations Spec: 7.3a.3, 36 300 V14.2.0
The RRC connection established for User Plane CIoT EPS optimizations:
• A RRC connection suspend procedure is used at RRC connection release, the eNB may
request the UE to retain the UE AS context including UE capability in RRC_IDLE;
• A RRC connection resume procedure is used at transition from RRC_IDLE to
RRC_CONNECTED where previously stored information in the UE as well as in the eNB
is utilised to resume the RRC connection. In the message to resume, the UE provides a
Resume ID to be used by the eNB to access the stored information required to resume the
RRC connection;
• At suspend-resume, security is continued. Re-keying is not supported in RRC connection
resume procedure. The short MAC-I is reused as the authentication token at RRC
connection reestablishment procedure and RRC connection resume procedure by the UE.
The eNB provides the NCC in the RRCConnectionResume message as well. And also the
UE resets the COUNT;
• Multiplexing of CCCH and DTCH in the transition from RRC_IDLE to RRC
CONNECTED is not supported;
• A non-anchor carrier can be configured when an RRC connection is re-established,
resumed orreconfigured additionally when an RRC connection is established.


RRC Connection Suspend procedure:
• Due to some triggers, e.g. the expiry of a UE inactivity timer, the eNB decides to suspend
the RRC connection.
• The eNB initiates the S1-AP UE Context Suspend procedure to inform the MME that the
RRC connection is being suspended.
• The MME requests the S-GW to release all S1-U bearers for the UE.
• MME Acks step 2.
• The eNB suspends the RRC connection by sending an RRCConnectionRelease message
with the releaseCause set to rrc-Suspend. The message includes the Resume ID which is
stored by the UE.
• The UE stores the AS context, suspends all SRBs and DRBs, and enters RRC_IDLE.


RRC Connection Resume procedure:
• At some later point in time (e.g. when the UE is being paged or when new data arrives in
the uplink buffer) the UE resumes the connection by sending an
RCConnectionResumeRequest to the eNB. The UE includes its Resume ID, the
establishment cause, and authentication token. The authentication token is calculated in
the same way as the short MAC-I used in RRC connection re-establishment and allows the
eNB to verify the UE identity.
• Provided that the Resume ID exists and the authentication token is successfully validated,
the eNB responds withan RRCConnectionResume. The message includes the Next Hop
Chaining Count (NCC) value which is required in order to re-establish the AS security.
• The UE resumes all SRBs and DRBs and re-establishes the AS security. The UE is now in
RRC_CONNECTED.
• The UE responds with an RRCConnectionResumeComplete confirming that the RRC
connection was resumed successfully.
• The eNB initiates the S1-AP Context Resume procedure to notify the MME about the UE
state change.
• The MME requests the S-GW to activate the S1-U bearers for the UE.
• MME Acks step 5.

CP-IOT supported UE (Spec Ref: 23.401, 5.3.2)

CP-IOT supported by EPC (Spec Ref: 23.401, 5.3.2)

UP-IOT supported UE (Spec Ref: 23.401, 5.3.2)

UP-IOT supported by EPC (Spec Ref: 23.401, 5.3.2)

Timers in Attach Request

Timers in Attach Accept

CP-IOT Data going Over S1AP/NAS (SpecRef : ETSI TS 123 401 V14.3.0, Section 5.3.4B.2)

UP-IOT Data going Over GTP Tunnel

RRC Connection Suspend Procedure (SpecRef : ETSI TS 123 401 V14.3.0, Section 5.3.4A)
• This procedure is used by the network to suspend the connection if the UE and
the network support User Plane CIoTEPS Optimization.

UE Context Suspend
• The purpose of the UE Context Suspend procedure is to suspend the UE context,
the UE-associated logical S1- connection and the related bearer contexts in the
E-UTRAN and the EPC.
• Upon receipt of the UE CONTEXT SUSPEND REQUEST the MME enters ECM-IDLE.
• Data related to the S1AP association, UE Context and bearer context, necessary
to resume the connection is kept in the eNB, UE and the MME.
• Upon receipt of the UE CONTEXT SUSPEND RESPONSE message the eNB shall
suspend the UE context, the UEassociated logical S1-connection and the related
bearer contexts and send the UE to RRC_IDLE.

RRC Connection Resume Procedure (SpecRef : ETSI TS 123 401 V14.3.0, Section 5.3.4)
• This procedure is used by the UE to resume the ECM-connection if the UE and the network support
User Plane CIoT. EPS Optimization and the UE has stored the necessary information to conduct the
Connection Resume procedure.

RRC Suspend followed by Paging, MIB….

RRC Suspend to…Resume Process

S1-U Release Control Plane CIoT EPS optimizations Spec: 5.3.5, 23.401, 14.3

UE Context Release for CP-IoT
• UE Context Release due to User Inactivity, similar as LTE.

UE Context Release for CP-IoT
• Paging followed by Service Request without Ping Data over NAS. ---In case of
core triggered Data.

S1-U establishment during Control Plane CIoT EPS optimizations Spec: 5.3.4B.4, 23.401, 14.3

Service Request for CP-IoT
• Service Request with Ping Data over NAS. ---------------In case UE Triggered Data

UE Context Release, Paging, Service Req for CP-IoT

UE RACH during the reconnection process for CP-IoT

UE Service Accept and Data Resume over NAS for CP-IoT

Control Plane CIoT EPS optimization (CP)
• This optimization uses the control plane to forward the UE’s data
packets. To do that, the data packets are sent encapsulated in Non
Access Stratum (NAS) signaling messages to the MME
• For NB-IoT UEs, the support of this procedure is mandatory.
• Since CP uses control plane to forward data packets, the
transmission or reception of messages is sent as NAS signaling
messages between the UE and MME. Compared to conventional SR
procedure, the UE avoids AS security setup and user plane bearers
establishment required in each data transfer. Hence, it is more
suitable for short data transactions.

3.2 Control Plane CIoT EPS optimization (CP)
• When a UE transmits data in uplink, the NAS signaling message
encapsulating the data packet can include a Release Assistance
Information (RAI) field. This RAI field allows the UE to notify the
MME if no further uplink or downlink data transmissions are
expected, or only a single downlink data transmission subsequent
to this uplink data transmission is expected. In such case, the MME
can immediately trigger the S1 Release procedure (unless user
plane bearers between eNB and Serving Gateway (SGW) are
established). Hence, the RAI field enables the MME to reduce the
period the UE is in DRX waiting for possible additional
transmissions. Unfortunately, CP does not currently allow the
application servers to notify the MME if no further data
transmissions are expected.

3.2 Control Plane CIoT EPS optimization (CP)
• Additionally, the UE or MME can trigger the establishment of the
user plane bearers between eNB and SGW during data
transmissions in CP. For example, if the size of the 7
• data transferred with CP exceeds a limit, the MME can initiate this
procedure. This change of functionality implies the release of the
specific CP user plane bearer between the MME and SGW, the
establishment of the user plane bearers, and the setup of the AS
security.

3.3 User Plane CIoT EPS optimization (UP)
• The alternative data transmission procedure optimization is UP. It
requires an initial RRC connection establishment that configures
the radio bearers and the AS security context in the network and
UE. After this, UP enables the RRC connection to be suspended and
resumed by means of two new control procedures: Connection
Suspend and Resume
• The support of this optimization is optional for NB-IoT UEs.

3.3 User Plane CIoT EPS optimization (UP)
• When the UE transits to RRC Idle state, the Connection Suspend
procedure enables to retain UE’s context at the UE, eNB, and MME.
Later, when there is new traffic, the UE can resume the connection.
To resume the RRC connection, the UE provides a Resume ID to be
used by the eNB to access the stored context. By means of
preserving the UE context instead of release it, the UE avoids AS
security setup and RRC reconfiguration in each data transfer,
compared to conventional SR procedure.
• As the UP optimization utilizes the usual user plane connectivity,
subsequent data packets can be transferred through the data
paths. Therefore, UP is suitable for short or large data transactions.

Basic Description on Power Spectral Density
Contributions of Power Distributed over Frequency
S(w)= Power per Frequency in Radian

S(f)= Power per Frequency in Hz

Power Boosting Spec Ref (TS 36 141 V14.3.0, Section 6.1.6)

Enhanced Coverage:
• NB-IoT requires 20 dB of maximum coupling loss (MCL), higher than LTE, and
then reaches up to 164 dB of MCL in order to serve the end devices in deep
coverage such as basements.
• CE level 0: normal coverage with MCL≈ 144 dB and 15 kHz sub-carrier spacing.
• CE level 1: robust coverage with MCL≈ 154 dB and 15 kHz sub-carrier spacing.
• CE level 2: extreme coverage with MCL≈ 164 dB and 3.75 kHz sub-carrier
spacing.
• Depending on the coverage level, the serving cell indicates to the UE to repeat the
transmission {1, 2, 4, 8, 16, 32, 64, 128} times for uplink communication, 2048 for the
downlink. Using the same transmission power on each repetition.
• Combining the different retransmissions, allows a coverage extension.

Enhanced Coverage: Altiostar Implementation
Configurations
Coverage NPRACH NPDCCH (Type2 - RAR) NPDCCH (UE specific)
Rep: 8 R_max: 8 R_max: 8
Period: 2560 G: 64 G: 16
T=8x5.6=49.8 ms T=R_max x G = 512ms T=R_max x G = 128ms
FreqOffset: n12/n24 (n0/n36) alpha=1/4 alpha=1/4
EC1 () based on ULSubcarrier spacing offset=alpha x T = 128ms offset=alpha x T = 32ms
Ncarriers: 12
MaxAttempts: 4
Nstart: 8ms
RAR window: pp5 (=5 NPDCCH=2.56sc)
Rep: 32 R_max: 128 R_max: 128
Period: 2560 G: 4 G: 4
T=32x5.6=179.2ms T=R_max x G = 512ms T=R_max x G = 512ms
FreqOffset: n12/n24 (n0/n36) alpha=0 alpha=0
Ncarriers: 12
MaxAttempts: 4
Nstart: 64ms
RAR window: pp5 (=5 NPDCCH=2.56sec)
Rep: 64 R_max: 1024 R_max: 1024
Period: 2560 G: 2 G: 2
T=64x5.6=358.4 ms T=R_max x G = 2048ms T=R_max x G = 2048ms
FreqOffset: n24/n12 (n0/n36) alpha=3/8 alpha=3/8
Ncarriers: 12
MaxAttempts: 4
Nstart: 8ms
RAR window: pp5 (=5 NPDCCH=10.24sec)

Enhanced Coverage:
• R_max: It specifies the maximum number of repetition allowed for that particular EC
level. Actual number of repetition could be less than R_max and is specified in DCI.
• G : For UE specific search Space, G is given by npdcch-StartSF-USS, which specifies
starting subframe configuration for an NPDCCH UE-specific search space.
• And for NPDCCH common search Space, G is given by npdcch-StartSF-CSS-RA. It specifies
the starting subframe configuration for NPDCCH common search space (CSS), including
RAR, Msg3 retransmission, and Msg4. It is used to compute the starting subframe for
NPDCCH candidate.
• E,g.for EC1 for UE specific search Space, R_max = 8, G = 16, T = 8*16 = 128 ms and alpha is
¼, hence
K0 = (10*nf + floor(ns/2))mod T = floor(alpha*T) [‘nf’ is System Frame Number and ‘ns’ is slot)
So, if nf is 3, (10*3 + sf) mod 128 = 32, so one valid value is Subframe 2.

PSM
• Power Saving Mode (PSM) is designed to help IoT devices conserve
battery power and potentially
• achieve a 10-year battery life.
• energy consumption of reattaches can become significant over the
lifetime of a device. Therefore, battery
• life could be extended if this procedure could be avoided.
• When a device initiates PSM with the network, it provides two
preferred timers (T3324 and T3412)
• PSM time is the difference between these timers (T3412-T3324).
The network may accept these values or set different ones. The
network then retains state information and the device remains
registered with the network. If a device awakes and sends data
before the expiration of the time interval it agreed with the
network, a reattach procedure is not required.
PSM

PSM T3412 extended value: (Spec Ref 24 008, 10.5.7.4a)

T3324
• T3324 is a timer which determines for how long the UE will monitor
paging before entering in PSM.
• Its value is requested by the UE during Attach and TAU procedures and
allocated by the MME.
• The T3324 active timer defines the time for which the device will remain
reachable for mobile terminated services on transition from Connected to
Idle mode.
• UE is not reachable by the Network in PSM and all modules are turned off.
UE exits PSM after T3412 expires (TAU) or with a Mobile Originated
transfer.
• The MME allows '0' value to be set for the T3324 timer, in which case the
UE enters the Power Saving Mode immediately.
• T3324 active timer is an integer value in the range 0 up to 11160 seconds.

T3412
• The T3412 timer is also called the periodic Tracking Area Update
(TAU) timer.
• Periodic tracking area update is used to periodically notify the
network the availability of the UE.
• The value of timer T3412 is sent to the UE by the network in the
Attach Accept message or Tracking Area Update Accept message.
• The UE shall apply this value in all tracking area included in the list of
tracking areas assigned to the UE, until a new value is received.
• Using T3412 extended timer, a longer periodic TAU timer is possible.
• When the T3324 value IE is included by the UE and the UE supports
extended periodic timer value in the MS network feature support IE,
it can also include the T3412 extended value IE.

Long battery life –Power Saving Mode
• Many device types just need to send periodic (or aperiodic)
reports, and do not need to be able to receiving paging messages
• One approach is to power the device off (i.e. the application
powers the LTE modem off) after each transmission, but this
introduces additional signaling (attach/detach, EPS bearer setup
and release), which also eats into the battery life
• As alternative, Release 12 introduces Power Saving Mode (needs
support from MME, HSS, UE, transparent to the RAN)
• After each transmission from the UE (data or Periodic TAU), it
continues to listen for paging messages during T3324 and then
goes into deep sleep for the duration of T3412_extended (up to
413 days for NB-IoT)
• The maximum time for which a device is reachable is 186
minutes (equivalent of the maximum value of the Active timer
T3324
NB-IoT Deployment
• NB-IoT or NB-LTE is a new 3GPP radio-access technology. It is
designed to achieve excellent co-existence performance with
legacy GSM, GPRS and LTE technologies.
• NB-LTE requires 200 kHz minimum system bandwidth for both
downlink and uplink, respectively.
• The choice of minimum system bandwidth enables a number of
deployment options like a GSM operator can replace one GSM
carrier (200 kHz) with NB-IoT or a LTE operator can deploy NB-LTE
inside an LTE carrier by allocating one of the Physical Resource
Blocks (PRB) of 180 kHz to it.
• This minimum bandwidth 200 KHz requirement enables three
possible modes of operation of NB-LTE which are mentioned as
below and illustrated in figure.

NB-IoT Deployment
• NB-IoT or NB-LTE is a new 3GPP radio-access technology. It is designed to
achieve excellent co-existence performance with legacy GSM, GPRS and
LTE technologies.
• NB-LTE requires 200 kHz minimum system bandwidth for both downlink
and uplink, respectively.
• The choice of minimum system bandwidth enables a number of
deployment options like a GSM operator can replace one GSM carrier
(200 kHz) with NB-IoT or a LTE operator can deploy NB-LTE inside an LTE
carrier by allocating one of the Physical Resource Blocks (PRB) of 180 kHz
to it.
• This minimum bandwidth 200 KHz requirement enables three possible
modes of operation of NB-LTE which are mentioned as below and
illustrated in figure.
• NB-IoT reuses the conventional LTE design extensively, including the
numerologies, downlink OFDMA, uplink SC-FDMA, channel coding, rate
matching, interleaving, etc.
PRB configurations
• NB-IoT technology occupies a frequency band of 180 kHz
bandwidth, which corresponds to one resource block in LTE
transmission.
• For in-band deployment, not all frequencies, i.e. resource blocks
within the LTE carrier, can be used for NB-IoT cell connection. For
the UE to synchronise and acquire the NB-IoT cell, for an in-band
downlink anchor carrier, the PRB is restricted to the values set out:
For uplink carrier and non anchor, there is no limitation.

For standalone and guard-band operation mode, the downlink and uplink carrier
should be set symmetrically.
We Support only In-Band as of now
NB-IoT
• NB-IoT radio design
• The new NB-IoT radio interface design is derived from the legacy
LTE. The NB-IoT carrier has a 180 kHz bandwidth with support for
multi-carrier operation. In downlink, Orthogonal Frequency-
Division Multiple Access (OFDMA) is applied using a 15 kHz
subcarrier spacing over 12 subcarriers with 14 symbols used to
span a subframe of 1 ms. In uplink, Single Carrier Frequency
Division Multiple Access (SC-FDMA) is applied, using either 3.75
kHz or 15 kHz subcarrier spacing.
• NB-IoT physical channels and signals are primarily multiplexed in
time. Figure 1 shows an example of NB-IoT subframes design. For
more information on NB-IoT.

Energy efficiency
• NB-IoT is designed for long-life devices and targets a battery lifetime of more
than 10 years. To this end, NB-IoT reuses LTE’s power saving mechanisms but
extending the timers involved to achieve longer battery lifetime. In LTE, there are
two key power saving mechanisms: Discontinuous Reception (DRX) and Power
Saving Mode (PSM). Both mechanisms modify the way the UE communicates
with the network.
• This communication requires a Radio Resource Connection (RRC) established
between the UE and the eNB. There are two possible RRC connection states:
Connected and Idle. A UE in RRC Connected state has an active RRC connection.
Therefore, the eNB can directly allocate resources to the UE. Otherwise, a UE is
in RRC Idle state. The UE can transit from RRC Connected to RRC Idle state
because of different causes, such as UE’s inactivity or detach. To detect UE’s
inactivity, the eNB uses an Inactivity Timer that restarts after a data packet
transfer.

EDRX
eDRX is a mechanism that can extend the cycle (sleeping duration) of the two
DRX (Idle mode DRX and C-DRX). The concept of eDRX can be illustrated as
shown above.
eDRX Spec Ref (36.304 section 7.1)
TeDRX TeDRX
TPTW TPTW
PF
P
O
T T
Subframe Patterns
Subframe Patterns(Paging) SpecRef (36.304 section 7.2)
• If P-RNTI is transmitted on PDCCH or NPDCCH, or if P-RNTI
is transmitted on MPDCCH with system bandwidth >
3MHz:

DRX operation in IDLE : Spec Ref (36.304 section 7.1)
• Ns: max(1,nB/T)
• nB: 4T, 2T, T, T/2, T/4, T/8, T/16, T/32, T/64, T/128, and T/256, and for NB-IoT also T/512,
and T/1024.
• N: min(T,nB), T is DRX cycle of the UE.
• Index i_s pointing to PO from subframe pattern and is derived from following
calculation:
i_s = floor(UE_ID/N) mod Ns

• Paging Transmission Window(PTW) : UE monitors Paging occasion
during this period. PTW is UE specific and is determined by PH, PTW_START,
PTW_END. Value is in 2.56s. Configuration S1 corresponds to 2.56seconds and so
on.
Possible config for TPTW(L) : s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13,
s14, s15, s16
• Paging HyperFrame(PH): Hyperframe in which PTW starts.
PH is H-SFN satisfying beow condition:
H-SFN mod TeDRX,H = UE_ID_H mod TeDRX,H
UE_ID_H = 12 MSB of hashed ID.
TeDRX,H = eDRX-cycle in hyperframes. TeDRX = hf2 => TeDRX, h = 2

• Paging Transmission Window(PTW) :
PTW_START: First Radio frame of PTW.
PTW_START = SFN = 256 * ieDRX ;
ieDRX = floor (UE_ID_H / TeDRX,H) mod 4
• PTW_END: Last Radio frame of PTW.
PTW_END = (PTW_START + L * 100 -1) mod 1024
• Paging Frame(PF): One system frame which may contain one or multiple
PO(s).
PF is SFN, which is satisfying below condition,
SFN mod T = (T / N) * (UE_ID mod N)
N = min (T, nB)
• UE_ID:
• IMSI mod 1024, if P-RNTI is monitored on PDCCH.
• IMSI mod 4096, if P-RNTI is monitored on NPDCCH.
• IMSI mod 16384, if P-RNTI is monitored on MPDCCH or if P-RNTI is monitored on NPDCCH and the UE supports paging on a non-anchor carrier, and if paging
configuration for non-anchor carrier is provided in system information.

Energy efficiency
• NB-IoT is designed for long-life devices and targets a battery lifetime of more
than 10 years. To this end, NB-IoT reuses LTE’s power saving mechanisms but
extending the timers involved to achieve longer battery lifetime. In LTE, there are
two key power saving mechanisms: Discontinuous Reception (DRX) and Power
Saving Mode (PSM). Both mechanisms modify the way the UE communicates
with the network.
• This communication requires a Radio Resource Connection (RRC) established
between the UE and the eNB. There are two possible RRC connection states:
Connected and Idle. A UE in RRC Connected state has an active RRC connection.
Therefore, the eNB can directly allocate resources to the UE. Otherwise, a UE is
in RRC Idle state. The UE can transit from RRC Connected to RRC Idle state
because of different causes, such as UE’s inactivity or detach. To detect UE’s
inactivity, the eNB uses an Inactivity Timer that restarts after a data packet
transfer.

Energy efficiency
• For NB-IoT, an extended DRX cycle of 10.24s is supported in RRC
Connected. In RRC Idle, the maximum DRX cycle is 2.91 hours. For
PSM, the maximum PSM time is 310 hours. The extension of both
mechanisms implies a higher latency as the network will wait a
longer period until it is able to reach the UE. However, it reduces
power consumption of the UE.

Data transport in CIoT
• In order to support mMTC communications, CIoT requires
minimizing the signaling overhead, especially over the radio
interface. In this section, we provide a description of the two CIoT
EPS optimized procedures the 3GPP has introduced in Release 13
for that purpose: CP and UP. Additionally, we describe the SR
procedure as a reference.
• During our description, we will differentiate between Mobile

Originated (MO) and Mobile Terminated (MT) cases. In the MO
case, a UE in RRC Idle state triggers the data transmission
procedure because it has new traffic to send in uplink. In the MT
case, it is the network that has new traffic to send in downlink to a
UE in RRC Idle state.

3.1 Service Request (SR) procedure
• For MO case, the UE in RRC Idle initiates the SR procedure. As the
UE 6
• does not have an RRC connection active, it first needs to
communicate with the network through a contention-based
Random Access (RA). Then, the UE and eNB establish the RRC
connection. Furthermore, to be able to send packets securely
through the radio interface, the UE and eNB configure Access
Stratum (AS) security. After successful setup of the AS security, the
eNB reconfigures the RRC connection to finally establish a data
radio bearer for the UE.
• From this point on, the UE can send uplink data packets. Finally,
the eNB and other core entities establish the rest of the user plane
bearers to enable downlink data path. Later, if there are no user
plane packets exchanged for a period, the eNB detects UE’s
inactivity and initiates the S1 Release procedure.
3.1 Service Request (SR) procedure
• For MT case, there are two possibilities to reach the UE in RRC Idle, depending
on whether it is using DRX or PSM mechanism. If the UE is using DRX, it will
listen to the network periodically. In this case, the network can send a Paging
message to notify there is pending downlink traffic to deliver to the UE. After the
UE recognizes the Paging message, it initiates the SR procedure as described for
MO. However, if the UE is using PSM, it will be unreachable until the UE initiates
either a MO transmission or the TAU procedure. In the latter case, the network
benefits from the fact that the UE is in RRC Connected after performing the TAU
to activate the SR procedure. In such case, after performing the TAU, the UE and
the network perform the remaining steps to establish user plane bearers and AS
security setup as for SR in MO case.
• For downlink traffic, the performance of periodic TAUs to exit PSM may imply a
higher latency than DRX. This is because of the period in deep sleep of PSM can
be longer than the DRX cycle. However, PSM could extend the UE’s battery
lifetime if the traffic is sporadic, compared to DRX.

Pioneering Network Transformation

NB IOT Session

Uploaded by

Copyright:

Available Formats

NB IOT Session

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NB IOT Session

Uploaded by

Copyright:

Available Formats

NB-IOT

Prepared by: Somnath Ray Chowdhury

2 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

3 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

4 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

5 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

To achieve these targets, several techniques have been

6 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

7 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

8 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

9 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

10 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

11 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

12 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

13 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

14 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

15 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

16 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

17 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

18 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

19 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

• Note: Observed Time Difference Of Arrival (OTDOA) is a Release 9 positioning

20 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

21 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

22 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

Time multiplexing between NB-IoT downlink physical channels and signals

23 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

24 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

25 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

26 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

27 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

28 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

29 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

30 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

31 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

32 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

33 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

35 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

36 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

37 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

The above table shows the Tone allowed in formats

38 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

39 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

• TSEQ= 5* 8192* Ts, where , Ts= 1/(15000*2048) seconds ,

• TCP= 2048* Ts, where , Ts= 0.0325 microsecond. ------------------------Preamble Format 0

• TCP= 8192* Ts, where , Ts= 0.0325 microsecond. ------------------------Preamble Format 1

The CP length is 66.67 micro second (Format 0) for cell radius up to 10 km

40 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

41 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

42 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

43 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

44 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

45 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

46 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

So, 680 bits / 1 ms +4 ms +4 ms + 12 ms + 2 ms + 3ms = 680 bit / 26 ms = 26.15 kbps

Throughput (With NPBCH/PSS/SSS) : within 20 ms NPBCH and NPSS is transmitted

47 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA

48 COMPANY PROPRIETARY & CONFIDENTIAL – UNDER NDA