NB-IoT

NB-LTE stands for Narrow Band LTE. For the high level description of NB-LTE and some comparative view of other technology, refer to LTE-M/Category M/M1/M2 page. Early July in 2016 (around Jul 10), the first version of 3GPP TS documents on NB IoT were posted and I started working on note based on these documents. It is very early stages for now and these notes will keep being updated and still some of high level description based on TR 45.820 (Ref [2]) remain in some notes. (I see pretty big differences between the official TS and TR 45.820 in terms of the details).

The notes below were written from the first Release 13 specifications, and NB-IoT has grown a lot since then. 36.300 v19.2.0 now describes NB-IoT with anchor and non-anchor carriers, with TDD as well as FDD, and with an IoT NTN mode. The sections below keep the Release 13 view, and each one ends with what the current specifications add to it.

Followings are some of high level topics in this page

Followings are the list of the topics (pages) that I am working on now... usually my approach is to study on physical/MAC layers first and then RRC messages and then everything in between. I am writing these pages based on the assumption that readers are familiar with basic concepts used in legacy (normal) LTE. So I don't describe much on the basic concepts in these pages. If LTE-NB is your first experience of LTE and come across any concept/terminologies you are not familiar, I would recommend you to refer to pages for legacy (normal) LTE (Try "Search" menu at the top)

Questions before Study

When I first heard of a variation of LTE (NB-LTE) with using only 200 Khz (1 RB), I thought like this : "OK, I think I can understand the motivation is 200 Khz. It is same as basic channel bandwidth of GSM. So if we use this in LTE, we may be able to use GSM/GPRS spectrum for NB-LTE. Also, even the smallest bandwidth of the current LTE (1.4 Mhz) might be too much for such a super low throughput application like IoT. OK, so far so good. Then a question popped up in my mind.

How can we implement this bandwidth which is much smaller than the minimum bandwidth of the current LTE ?
Do we have redesign the whole system only for this ?
Do we need to invent new waveform, new slot/subframe structure and come up with new scheduling/high layer signaling ?"

OK.. I think 200 Khz (more accurately 180 Khz) is to utilize 1RB of legacy LTE as it is. Also, it is not difficult think of how we utilize this single RB because data transmission and reception in the single RB is possible even in legacy LTE. However, there are somethings that cannot be reduced to single RB bandwidth in legacy LTE. So you may have following questions.

In legacy LTE, PSS and SSS is spreaded across 6 RB bandwidth (i.e, 1.4 Mhz). How should we redesign PSS, SSS to be fit in 1 RB bandwidth ?
In legacy LTE, PBCH is spreaded across 6 RB bandwidth (i.e, 1.4 Mhz). How should we redesign PBCH to be fit in 1 RB bandwidth ?
In legacy LTE, PCFICH and PHICH are designed to spread across the whole system bandwidth and the minimum of the whole system bandwidth is 1.4 Mhz. Are we still going to use PCFICH and PHICH in LTE-NB ? If yes, how should we redesign it to be fit into single RB bandwidth. If no, just forget about it.
In legacy LTE, PDCCH are designed to spread across the whole system bandwidth and the minimum of the whole system bandwidth is 1.4 Mhz. You can easily guess that it would not be possible to completely get rid of PDCCH. Are we going to revise the legacy LTE PDCCH to be fit into single RB bandwidth ? or Are we going to come up with completely new PDCCH structure ?

I would not give you answers to any of these questions in this page. It is just my way of studying anything new. Coming up with my own question before jumping into textbook or specification documents.

If you want to check your own answers later, two of these questions have short answers in the current specifications. NB-IoT does not use PCFICH and PHICH at all. The downlink control channel is NPDCCH, which fits inside the single resource block, and the three DCI formats listed in the next section are carried on it. The other channels were redesigned the same way, and each one has its own page in the list above.

Similarities and Differences

Before the details, it helps to know which parts of LTE survive in NB-IoT and which do not. The two lists below separate them. Most of the similarity sits in the numerology, and most of the difference sits in the channels built on top of it.

The first impression that I got while I was reading Release 13 LTE-NB specification is that it is almost a new design except a few very fundamental factors/parameters.

Followings are some of parameters that remains same in LTE-NB comparing to normal (legacy) LTE

Subcarrier Spacing = 15 Khz (except that UL can have an option for 3.75 Khz subcarrier spacing)
Subframe Length = 1 ms
Number of slots in a subframe = 2
Radio Frame Length = 10 ms
Number of Subframes in a Radio Frame = 10
Downlink Waveform = OFDMA (There is a subtle differences in waveform generation formula, but almost same)

Followings are some of parameters that are different from legacy LTE. I would just put down a high level descriptions of the difference here. For the details, I would recommend you to each separate pages that I listed at the top.

System Bandwith = 200 Khz fixed (this is obvious)
Uplink Waveform = SC-FDMA (Still named as SC-FDMA, but pretty big difference in terms of waveform generation formula)
PSS, SSS resource element mapping and transmission pattern
PBCH (MIB) resource element mapping and transmission pattern
DCI Format = only three types (N0, N1, N2) and parameters in the DCI shows pretty big difference
Repetitive Transmission = performs repetitive transmission for almost every channel (in LTE, only TTI Bundling is the intentional repetitive transmission.. all other transmittion is intended for single transmission.)

36.300 v19.2.0 states the downlink part of this list in clause 5.1.1a. The downlink uses one resource block per NB-IoT carrier and always uses 15 kHz subcarrier spacing. In FDD, an NB-IoT UE supports only half duplex operation.

Clause 4.10 of 36.300 adds a list that the table above does not show: the LTE functions that NB-IoT leaves out. It includes inter-RAT mobility, handover, measurement reports, GBR, carrier aggregation, dual connectivity, emergency call, CS fallback and RRC_INACTIVE. So NB-IoT is simpler than LTE in its feature set, even where its physical layer is new.

The numerology stays close to LTE : 15 kHz subcarriers, 1 ms subframes and 10 ms radio frames, with a 3.75 kHz option in the uplink only.
The channels are new : synchronization, broadcast and control channels were redesigned to fit one resource block.
Repetition is the default : almost every channel is repeated, where LTE repeats only with TTI bundling.
Many LTE functions are left out : handover, measurement reports, carrier aggregation and CS fallback are not supported for NB-IoT.

Waveform : Modulation/Subcarrier Spacing/Symbol Length/System Bandwidth

NB-IoT keeps the LTE numerology wherever it can, so that an NB-IoT carrier fits inside an LTE carrier. The table below compares downlink and uplink parameter by parameter. Two uplink cells are blank, and they matter, because the 3.75 kHz option changes both the symbol and the slot.

In short, there is no changes at all in Downlink and small changes in Uplink as follows.

Parameters	Downlink	Uplink
Modulation	OFDMA (Same as Normal LTE)	SC-FDMA (Same as Normal LTE)
Subcarrier Spacing	15 Khz (Same as Normal LTE)	15Khz or 3.75 Khz
Symbol Length	Same as Normal LTE
Slot Duration	Same as Normal LTE
System Bandwidth	200 Khz	200 Khz
Number of Subcarriers	12 ( 180 Khz in Total)

36.300 v19.2.0 clause 5.2.1a fills in the two blank uplink cells. With 15 kHz subcarrier spacing, the uplink uses 12 subcarriers, like the downlink. With 3.75 kHz, it uses 48 subcarriers across the same 180 kHz. A 3.75 kHz slot lasts 2 ms and carries seven symbols. Each symbol is 8448 Ts with a cyclic prefix of 256 Ts, and the remaining 2304 Ts of the slot is a guard period. The 8448 Ts already include the cyclic prefix: 36.211 v19.3.0 Table 10.1.5-1 gives 8192 Ts for the symbol and 256 Ts for the cyclic prefix. Seven symbols therefore take 59136 Ts of the 61440 Ts in a 2 ms slot.

The resource unit changes with the numerology. For NPUSCH with UL-SCH data, a single-tone resource unit is one 3.75 kHz subcarrier for 32 ms, or one 15 kHz subcarrier for 8 ms. Multi-tone resource units use 15 kHz only: 3 subcarriers for 4 ms, 6 subcarriers for 2 ms, or 12 subcarriers for 1 ms.

The downlink never changes : 15 kHz subcarriers and one resource block per NB-IoT carrier.
3.75 kHz is single-tone only : multi-tone transmission always uses 15 kHz subcarriers.
A 3.75 kHz slot is four times longer : 2 ms with seven symbols, where a 15 kHz slot is 0.5 ms.
A resource unit trades bandwidth for time : fewer subcarriers mean a longer unit, from 1 ms for 12 subcarriers to 32 ms for one 3.75 kHz subcarrier.

LTE-NB Operation Mode / Why 200 Khz ?

As you know, LTE is originally designed to provide very high data rate. So it might sound ironic that we are trying to provide very low throughput service like IoT. However, as far as I experienced.. in engineering there is no such a thing like ironic.. engineers are always to try to come up with a solution when there is need. Even though LTE is originally designed for high throughput, there has been continuous effort for low throughput (low cost) solution for the past couple of years. This is why you start seeing UE Category running backward. Most of initial LTE implementation was implemented as Category 3 and kept incrementing the numbers. However, we started seeing backward numbers like Category 1 and Category 0. However, all of exisiting LTE categories still keep the lowest boundary of LTE specification as follows :

Minimum System Bandwidth in frequey domain = 1.4 Mhz, 6 RB
Minimum Scheduling Unit in Time Domain = 1 ms TTI

However, the industry realized that there would be limitation to make LTE perfectaly suitable for IoT / MTC crieteria (super simple, untra cheap, extremly low energy consumption). Finally the industry tried to break at least one of the LTE boundary. It is to break frequency domain boundary and decide to make it narrower.

Then the question is how narrow it should be. Probably the most practical answer they found seems to be the bandwidth of 1RB because 1 RB is the minimum scheduling unit of current (legacy) LTE in frequency domain. They might have tried to pick narrower bandwidth (e.g, 6 subcarriers etc). However, in this case it would require too much redesign from the legacy LTE.

The industry decided to time domain boundary as it is, meaning that we can use the most of time domain design of the legacy LTE as it is.

With 1RB Bandwidth selected, we can utilize(deploy) this system in various situation as illustrated below.

LTE-NB inband, guardband and standalone operation modes

The same 180 kHz NB-IoT carrier in three places. It sits inside an LTE carrier, in the guard band at its edge, or on its own in spectrum freed from another system such as GSM.

Inband Mode : In this mode, we can deploy LTE NB within a legacy LTE if you just reserve only 1 RB anywhere in the legacy LTE band.

Guardband Mode : As you know, every LTE band has at least 100 Khz guardband on each end of the band. It means that you can easily have around 200 Khz space between any two non-contiguous band even if they are sitting in the closest possible locations. Guardband mode is to deply LTE-NB in the space that are reserved for the guardband of legacy LTE band.

Standalone Mod : In previous two modes, LTE-NB coexists with an existing legacy LTE band. But we can think of another case where it is deployed completely independent from any legacy LTE. In an extreme case, we may deploy it in completely free space in the spectrum. However, in practical sense this mode of operation is intended to reserve (free up) a GSM channel and deploy LTE-NB in that space.

The UE learns the mode from MIB-NB. Its operationModeInfo-r13 field is a CHOICE of inband-SamePCI-r13, inband-DifferentPCI-r13, guardband-r13 and standalone-r13. So the specification splits the inband mode into two cases. With inband-SamePCI, the NB-IoT cell and the LTE cell share the physical cell ID and the number of NRS and CRS ports. With inband-DifferentPCI, the IDs differ, and MIB-NB tells the UE the number of LTE CRS ports instead.

The inband-DifferentPCI and guardband cases also carry rasterOffset-r13, which takes one of four values: -7.5, -2.5, +2.5 or +7.5 kHz. The inband-SamePCI case carries eutra-CRS-SequenceInfo-r13 instead, which associates the NB-IoT carrier with an LTE PRB index.

One more change affects all three modes. 36.300 v19.2.0 allows more than one NB-IoT carrier in a cell. The anchor carrier carries NPSS, NSSS, NPBCH and SIB-NB, while a non-anchor carrier can carry unicast data, paging, random access and SC-PTM. Table 5.5a-1 of 36.300 lists which combinations of anchor and non-anchor modes are valid in FDD, and Table 5.5a-2 does the same for TDD.

One carrier, three homes : inband, guardband and standalone all use the same 180 kHz carrier.
Inband comes in two variants : MIB-NB separates the same-PCI case from the different-PCI case.
MIB-NB tells the UE the mode : operationModeInfo-r13 is read before any other system information.
A cell can use more than one carrier : the anchor carrier carries the synchronization and broadcast channels, and non-anchor carriers carry the rest.

Reference

[1] 3GPP RP-151621

[2] 3GPP TR 45.820 V13.1.0 (2015-11) : Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT) (Release 13)

[3] NB-IoT concept demo by u-blox at Mobile World Congress 2016 (YouTube)

[4] 5G DEMO NB IOT v2 small (YouTube)

[5] Diversifying Cellular for Massive IoT - Live Demo: NB-IoT extended coverage (YouTube)

[6] NarrowBand IOT demonstration at MWC 2016 (YouTube)

[7] Internet of Things Conference: Vodafone's plans for NB-IoT (YouTube)

[8] RAN approved REL-13 NB_IOT CRs (RAN#72)

[9] 3GPP TS 36.211 V13.2.0 (2016-06) E-UTRA Physical channels and modulation

[10] 3GPP TS 36.331 V13.2.0 (2016-06) : E-UTRA RRC Protocol Specification

[11] 3GPP TS 36.300 v19.2.0 - clause 4.10, clause 5.1.1a, clause 5.2.1a and clause 5.5a on NB-IoT

[12] 3GPP TS 36.331 v19.3.0 - MasterInformationBlock-NB and its field descriptions