Page 331 - From GMS to LTE
P. 331
Long Term Evolution (LTE) and LTE-Advanced Pro 317
system information as well as the control and the shared channel. All devices in RRC
idle state camp on this carrier. Devices in RRC connected state can then either be served
on the anchor carrier or instructed to transmit or receive data on a non‐anchor carrier.
Uplink and downlink transmissions for a device can even be scheduled on different
non‐anchor carriers due to the half‐duplex transmission used in NB‐IoT. Once devices
return to RRC idle state they fall back to the anchor carrier. This way, capacity in a sec-
tor can be increased without requiring more complex mobile device hardware or result-
ing in higher power consumption. At any time, a mobile device is listening or transmitting
on only one 180 kHz carrier.
4.19.9 NB‐IoT Throughput and Number of Devices per Cell
Based on the physical characteristics of an NB‐IoT carrier the raw datarate per channel
can be calculated as follows. There are 12 subcarriers on the frequency axis and seven
symbols per 0.5 millisecond slot. Multiplied by 2000 (1/s) and two bits per transmission
step (QPSK modulation), the raw channel datarate is 336 kbit/s. Not all symbols are avail-
able for user data transmission however. If the NB‐IoT channel is embedded in a larger
LTE channel, the first one to three symbols per subframe are not usable as they carry LTE
control channel information, which reduces the overall channel capacity by about 10–20%
depending on how many symbols are used by LTE. In addition, capacity is required for the
narrowband reference signals, by the LTE reference signals if the NB‐IoT channel is used
in‐band, by the MIB, by the narrowband control channel and the System Information
messages that are periodically broadcast. In practice the downlink capacity of an NB‐IoT
channel that is available to transfer user data is thus around 200 kbit/s if no data is repeated.
While the calculated throughput sounds very low, the system has been designed to
support up to 50,000 devices per eNode‐B sector. This makes it clear once more that
NB‐IoT has been specifically designed for devices that send very little data. 3GPP TR
45.820 chapter 7.3.6 contains a network simulation that confirms that such a high num-
ber of devices is feasible with a single 180 kHz NB‐IoT channel. In the simulation,
devices sent 105 bytes of data per transmission, which included 20 user data bytes and
all IP and radio network overhead. Furthermore, the simulation took many system
parameters such as the network setup, network access procedures, uplink grants, down-
link assignments and radio conditions into account.
A simple calculation to cross‐check the number can be performed as follows: 50,000
devices sending 105 bytes five times an hour produce 26,250,000 bytes of data per hour.
Divided by 60 minutes, 60 seconds and multiplied by eight bits per byte results in a datarate
of 58,333 bits per second. This means that the amount of data fits well into an NB‐IoT
channel even if all other overhead mentioned above is subtracted from the overall datarate.
Another interesting number is how often a random access request will occur with
50,000 devices in a sector communicating five times an hour. Multiplying the number
of devices by five attempts an hour and dividing by 60 minutes and 60 seconds results
in 70 RACH attempts per second, or one every 14 milliseconds.
4.19.10 NB‐IoT Power Consumption Considerations
Another requirement the NB‐IoT air interface was designed for is battery lifetime of at
least 10 years for NB‐IoT devices sending very little data. 3GPP came to the conclusion
in TR 45.820 chapter 7.3.6.4 that this is feasible under the following conditions: