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 to 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 specified 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: