NB-IoT - Data Rates and Latency

With NB-IoT networks eventually started to rollout, some developers are wondering how much data they can exchange between
sensor device and platform, what it takes to transfer this data etc.

If you have not gone through high level NB-IoT network architecture and deployment aspects, it will be helpful to better understand
NB-IoT network architecture and deployment/link budget aspects.

NB-IoT Data Transmission

NB-IoT is centralized system like LTE, where eNodeB controls the scheduling in downlink as well as in uplink to ensure co-
ordination of resources among the devices.

Uplink Communication

Uplink communication is more critical than downlink for LPWA IoT use cases. Typical NB-IoT uplink communication starts with a
request from device to eNB using RACH. Once the eNB receives the request for transmission, it sends back a Scheduling Grant t o
the device indicating the time and frequency allocation, followed by uplink data transfer in uplink and ACK/NACK in the downlink.

A device can select uplink Transport block size (TBS) on MAC layer from 2 bytes (16 bits) up to 125 bytes (1000 bits) as spec ified
by 3GPP TS36.213. The amount of payload it can accommodate depends upon higher layer protocol overhead; definitely smaller
TBS in Table 1 are more suitable for non-IP transmission while higher TBS are suitable for IP transmission to accommodate higher
overheads.

where Iru is the index corresponding to the number of Scheduling Resource Units (sub-frames) required to transfer this TBS,
offering different level of redundancy.

Thus, a 1000 bit TBS (MAC layer) will require a min of 4~10 resource units for single transmission (i.e. w/o repetition),
where scheduling Resource Unit is 8ms (15kHz single tone) or 16ms (3.75kHz tone).

Downlink Communication

Downlink communication starts with a paging message, sent from eNB to the device. To enhance battery autonomy, NB-IoT
supports configuration of eDRX (extended Discontinuous Reception) and PSM (Power Saving Mode) parameters which allows
device to go in deep sleep mode from few sec up to days. The device is no longer reachable by the network in sleep mode; thus a
choice of power consumption vs reachability.
 A device can select downlink Transport block size (TBS) on MAC layer from 2 bytes (16 bits) up to 85 bytes (680 bits) as specified
by 3GPP TS36.213. The TBS selected accommodates the data payload and headers (IP/non-IP, UDP, CoAP etc). A downlink TBS
of 16 bit will always take 1 sub-frame while 680 bit may take from 3~10 sub-frames (1 sub-frame = 1ms).

NB-IoT Communication Latency Bounds

NB-IoT, by design, is not meant to offer millisecond latency such as to simplify chipset and enhance battery autonomy. The latency
in NB-IoT depends upon:

1. Transport Block Size is directly linked to the number of scheduling resource units, and hence transmission time required as
explained above. Obviously the application payload and higher layer protocol overhead impact the size of TBS, and may even
require multiple TBS.

2. Number of Repetitions NB-IoT allows excessive repetitions (up to 2048 repetitions in downlink, up to 128 repetitions in
uplink). MME may configure up to 3 coverage enhancement (CE) levels, CE level 0 to CE level 2. The main impact of the different
CE levels is that the messages must be repeated several times depending upon UE location. If you are wondering why 3GPP allow
such excessive repetitions in downlink compared to uplink, it is because the link budget is not balanced in NB -IoT, more details
here.

3. Network Deployment Mode NB-IoT can be deployed in-band, guard-band and out-of-band modes, each having a different
link budget. MNOs will configure different number of repetitions depending upon the deployment mode (link budget).

What it means for a developer? Your device in country X operating at frequency Y located at distance Z meters from eNB will have
different delay and power consumption if network deployment modes are different.

4. eDRX and PSM configuration NB-IoT devices are not always listening, thus a downlink triggered action (e.g. reconfiguration,
status report etc) must wait for device to wake up per the eDRX/PSM configurations.
To summarize, uplink data communication (excluding RACH) can last:

Single tone 3.75kHz 141 ms to 45,121 ms

Single tone 15kHz 45 ms to 14,404 ms

and downlink data transmission (excluding paging) can take anywhere from:

Single tone 3.75kHz 26 ms to 23,556 ms

Single tone 15kHz 20 ms to 22,788 ms
Depending on your use case, you may need only uplink communication, downlink communication or both. The table below gives
more detailed calculation (with formulas and references) to the min and max bounds of NPDSCH and NPUSCH channels based on
tone and repetitions: