White Paper

Evaluation of LTE-M towards

5G IoT requirements

Contributing and Supporting Companies:

V1.1 March 2018

 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Executive Summary
LTE-M, a machine-focused variant of the 3GPP LTE standard, is designed to meet the high-coverage, low-cost, and low-
power consumption requirements of the Internet of Things (IoT). In January 2017, a group of more than a dozen industry
players evaluated LTE-M’s coverage performance, and published a white paper which concludes that LTE-M supports the
very deep coverage required for IoT applications [1]. This follow-up paper takes the next step to evaluate the message
latency, battery life, and capacity performance for LTE-M category-M1 devices.
More specifically, this paper evaluates LTE-M performance against the initial Cellular IoT (CIoT) requirements in 3GPP TR
45.820 [2], but – perhaps more importantly – also compares LTE-M performance to the more recently published 3GPP
5G IoT or massive Machine-Type Communications (mMTC) requirements. The 5G IoT requirements for coverage, message
latency, and battery life are specified in 3GPP TR 38.913 [3] and the capacity requirements are defined by the two ITU
reports IMT-2020 evaluation guidelines [4] and IMT-2020 requirements [6].
Starting with the CIoT requirements, the message latency for LTE-M in extremely deep coverage conditions was found to
be 6.2 seconds, which is well under the stated goal of 10 seconds. Battery life in extremely deep coverage conditions was
determined to be 10.4 years, which is over the 10-year requirement assuming one 200 byte uplink message per day. At the
edge of normal coverage (i.e. where your smart phone stops working today), the performance improves significantly, where
message latency was found to be 0.1 seconds and battery life to be 35.7 years.
As for 5G IoT requirements, even though the 5G coverage requirements are up to 4 dB more difficult than the CIoT
requirements, the analysis in this paper shows that LTE-M also gets a passing grade for 5G. The results are summarized in
Table 1.

5G REQUIREMENT 5G TARGET LTE-M PERFORMANCE

Bandwidth required to serve a capacity of 1 million devices per km 2
50 MHz 70% of a 5 MHz system

Data rate at the maximum coupling loss of 164 dB 160 bps UL 363 bps & DL 1200 bps*

Message latency at the maximum coupling loss of 164 dB 10 seconds 6.7 seconds*

Battery life at the maximum coupling loss of 164 dB 10 years 10.9 years*
Table 1: Performance Summary
* Assumes four receive and two transmit antennas at the base station and +4 dB downlink PSD boosting

Keep in mind the above performance is for extremely deep coverage. In normal coverage, the performance will be improved
significantly.
The evaluation is based on the Release 13 LTE-M specifications (along with uplink control channel repetitions from Release
14). However, 3GPP’s work on Release 15 LTE-M enhancements promises to improve the coverage, message latency,
battery life, and capacity results shown in this paper. If the early indications hold true, Release 15 enhancements can be
expected to support the 5G IoT requirements in all system configurations, including base station antenna configurations
with just two receive antennas and two transmit antennas, without the need for downlink Power Spectral Density (PSD)
boosting.
When these results for coverage, message latency, battery power, and capacity are taken into account, it becomes clear that
LTE-M is on track to support the future 5G IoT and mMTC application requirements. What’s more, LTE-M is a very versatile
Low Power Wide Area (LPWA) technology, since it also supports higher data rates, real-time traffic, full mobility, and voice.

2 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Table of Contents
Executive Summary ..................................................................................................................................................... 2
1 Introduction and Scope .......................................................................................................................................... 4
2 Abbreviations............................................................................................................................................................... 5
3 Maximum Coupling Loss (MCL) .......................................................................................................................... 6
4 Coverage ................................................................................................................................................................ 7
4.1 Uplink Data Channel (PUSCH) ...................................................................................................... 8
4.2 Downlink Data Channel (PDSCH) ............................................................................................... 8
4.3 Control Channels ............................................................................................................................... 9
4.4 Coverage Summary .......................................................................................................................... 10
5 Message Latency ...................................................................................................................................................... 10
5.1 Message Sequence .......................................................................................................................... 10
5.2 Message Latency at CIoT 164 dB MCL...................................................................................... 12
5.3 Message Latency at 5G 164 dB MCL ........................................................................................ 12
6 Battery Life................................................................................................................................................................... 13
6.1 Battery Life at CIoT 164 dB MCL................................................................................................... 13
6.2 Battery Life at 5G 164 dB MCL .................................................................................................... 14
7 Capacity ......................................................................................................................................................................... 14
7.1 Evaluation Assumptions ................................................................................................................ 14
7.2 Evaluation Results ............................................................................................................................ 15
8 LTE-M Enhancements in Releases 14 and 15 ............................................................................................ 17
9 Summary ...................................................................................................................................................................... 18
10 References ................................................................................................................................................................ 19
Contacts ............................................................................................................................................................................ 20

3 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

1 Introduction and Scope

In addition to serving a versatile set of LPWA use cases, LTE-M has been designed to support
KEY MESSAGE requirements on data rate, latency, battery life, and system capacity, even under the most
This paper evaluates all stringent coverage requirements. This guarantees that LTE-M can serve large-scale IoT
the ITU and 3GPP 5G deployments, covering the last mile and beyond with guaranteed quality of service and
requirements and the minimum maintenance requirements.
Cellular IoT requirements. This white paper is a follow-up to the LTE-M coverage white paper [1] published in January
2017. The LTE-M coverage white paper focused on the CIoT coverage requirement defined in
3GPP TR 45.820 [2] but there are several other performance aspects in TR 45.820 which were
not covered in the first white paper. Also, since January 2017, the ITU and 3GPP have published
new 5G IoT/mMTC requirements which need evaluation. This paper evaluates all these
remaining requirements:
yy CIoT TR 45.820 [2] requirements:
yy Message latency
yy Battery life
yy 5G IoT requirements from IMT-2020 [4][6]:
yy Connection density (i.e. capacity)
yy 5G IoT requirements from TR 38.913 [3]:
yy Coverage
yy Message latency
yy Battery life
The evaluation was done assuming LTE-M category-M1 Release 13 [7], unless otherwise
stated.

4 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

2 Abbreviations
ABBR. TERM ABBR. TERM ABBR. TERM
3GPP Third Generation Partnership Project LPWA Low Power Wide Area PUCCH Physical Uplink Control Channel

5G Fifth Generation Cellular LTE Long Term Evolution PUSCH Physical Uplink Shared Channel

ACK Acknowledge LTE-M Long Term Evolution for QAM Quadrature Amplitude Modulation
Machine-Type Communications

AM Acknowledged Mode MAC Media Access Control RAI Release Assistance Information

bps Bits Per Second MCL Maximum Coupling Loss RAN Radio Access Network

BLER Block Error Rate MHz Megahertz RLC Radio Link Control

BW Bandwidth MIB Master Information Block RRC Radio Resource Control

CloT Cellular IoT MO Mobile Originated RX Receive

dB Decibel MPDCCH MTC Physical Downlink Control sec Second

Channel

dBm Power ratio in decibels referenced MTC Machine Type Communications SF Sub-frame
to one milliwatt

DL Downlink (from eNB to UE) mMTC Massive Machine Type SIB System Information Block
Communications

eNB Enhanced Node B (LTE base station) NF Noise Figure SIB1-BR System Information Block
1 Bandwidth Reduced

ETU Extended Typical Urban PA Power Amplifier SSS Secondary Synchronization Signal

EVAL Evaluation PAPR Peak-to-Average-Power Ratio SNR Signal to Noise Ratio

FDD Frequency Division Duplex PBCH Physical Broadcast Channel TBS Transport Block Size

GERAN GSM Edge Radio Access Network PDCP Packet Data Convergence Protocol TM Transmission Mode

HARQ Hybrid Automatic Repeat Request PDSCH Physical Downlink Shared Channel TR Technical Report

IMT International Mobile PDU Packet Data Unit TX Transmit

Telecommunications

IP Internet Protocol PRACH Physical Random Access Channel UE User Equipment

ITU International Telecommunication PRB Physical Resource Block UL Uplink (from UE to eNB)
Union

km Kilometer PSD Power Spectral Density Wh Watt Hour

LNA Low Noise Amplifier PSM Power Saving Mode

LLS Link Layer Simulation PSS Primary Synchronization Signal

5 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

FACT 3 Maximum Coupling Loss (MCL)

MCL is a very common
Support for a high coverage range is one of the most fundamental requirements for IoT
measure to describe
the amount of coverage technologies aiming to provide ubiquitous coverage. In this paper, coverage is referred to in
a system can support terms of Maximum Coupling Loss (MCL). MCL is a convenient metric since it is defined as the
but depends on the difference in output power at the antenna connector of a transmitting node and the input power
assumed noise figures. at the antenna connector of a receiving node required to provide a targeted quality of service.
This paper analyzes three sets of requirements: one set from the initial 3GPP study on CIoT
described in TR 45.820 [2], one set from the 3GPP 5G requirement study in TR 38.913 [3],
and one set from the ITU requirements on IMT-2020 systems as captured in ITU reports
IMT-2020 evaluation guidelines [4] and IMT-2020 requirements [6]. The achievable MCL is
highly dependent on the assumed device (i.e. user equipment or UE) and LTE base station (i.e.
Enhanced Node B or eNB) noise figure which defines the level of intrinsic thermal noise in
these nodes. Unfortunately, the base station and the device noise figure (NF) assumptions are
different for all three mentioned sets of requirements, and this affects the MCL requirements.
Table 2 summarizes how MCL is calculated (for more on calculating MCL see [1]):

MCL INPUT VALUE

Transmitter

(0) Max TX power (dBm) PA power of UE or eNB

(1) Power in channel bandwidth (dBm) Calculated

Receiver

(2) Thermal noise density (dBm/Hz) Constant -174 dBm/Hz

(3) Receiver noise figure (dB) Depends on LNA

(4) Occupied channel bandwidth (Hz) Bandwidth of signal

(5) Effective noise power

Calculated
= (2) + (3) + 10 log((4)) (dBm)

Value comes from link

(6) Required SNR (dB)
simulation

(7) Receiver sensitivity

Calculated
= (5) + (6) (dBm)

(8) MCL
Calculated
= (1) - (7) (dB)
Table 2: MCL Calculation
FACT
The assumed noise
figures for 5G and As seen from the above calculation, the receiver’s NF is a direct input into the MCL calculation,
CIoT requirements are so any difference in the NF directly affects the resulting MCL calculated. NF is based on the
different so the MCL is quality of the receiver’s front end, including its Low Noise Amplifier (LNA), so the assumed NF
different. can be a subjective choice. Table 3 gives the NFs used in each set of requirements.

6 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

FACT RECEIVER NOISE FIGURES APPLICABILITY BASE STATION DEVICE

The 3GPP 5G 164 3GPP GERAN Study TR 45.820 (“CIoT”) Sections 5 & 6 3 dB 5 dB
dB MCL requirement 3GPP 5G RAN Study TR 38.913 (“5G”) Sections 4, 5 & 6 5 dB 9 dB
from TR 38.913 is 4
dB more difficult in 5G IMT-2020 Evaluation Guides (“5G IMT”) Section 7 5 dB 7 dB
the DL and 2 dB more Table 3: Receiver Noise Figures
difficult in the UL than
The difference in NFs means that the 164 dB MCL requirement from the 3GPP 5G RAN Study
the 3GPP CIoT 164 dB
MCL requirement from TR 38.913 is 4 dB more difficult in the downlink (DL) and 2 dB more difficult in the uplink (UL)
TR 45.820. than the 164 dB MCL requirement from the 3GPP GERAN Study TR 45.820.
For clarity, MCL requirements from the CIoT study TR 45.820 have a “CIoT” prefix (e.g. “CIoT 164
dB MCL”) and MCL requirements from the 3GPP 5G study in TR 38.913 have a “5G” prefix (e.g.
“5G 164 dB MCL”).

4 Coverage
The main goal of the LTE-M coverage white paper [1] was to show that LTE-M could support
extremely deep coverage conditions at CIoT 164 dB MCL with at least a data rate of 160 bps.
This section’s aim is to show that LTE-M can provide even further coverage, and meet the even
more difficult 5G IoT coverage requirement, while providing a minimum data rate of 160 bps
at the 5G 164 dB MCL. As with [1], to determine the coverage that the LTE-M specification
can support, Link-Level Simulation (LLS) analysis of every LTE-M channel was conducted. For
consistency, the simulation assumptions across the different channels are as common as
possible as shown in Table 4.

PARAMETER PSS/SSS PBCH SIB1-BR MPDCCH PDSCH PUSCH PUCCH PRACH

Max TX power 46 dBm 23 dBm

System bandwidth 5 or 10 MHz

Configuration Half Duplex FDD

Carrier frequency 2 GHz

Antenna configuration 2 TX and 1 RX, low correlation 1 TX and 2 RX, and 1 TX and 4 RX, low correlation

Channel model ETU 1 Hz

Number of PRBs N/A N/A 6 6 6 1 1 6

PBCH with 208-bit TBS DCI format PUCCH format PRACH format
Physical channel format N/A Various TBSs Various TBSs
repetition every 5 ms 6-1A (18 bits) 1A 2

Random Beam
Transmission mode N/A TM2 TM2 TM2 TM1 N/A N/A
- Forming

Frequency tracking error 1 kHz 30 Hz 30 Hz 30 Hz 30 Hz 30 Hz 30 Hz 30 Hz

Channel estimation N/A Cross SF Cross SF Cross SF Cross SF Cross SF Cross SF N/A

Frequency hopping No No Yes Yes - 16 SF

Acquisition Acquisition Acquisition SNR at 1% Data speed Data speed Misdetection Misdetection
time versus time versus time versus BLER at 10% BLER at 10% BLER probability probability
Performance target SNR at 0.1% SNR at 0.1% SNR versus SNR versus SNR at 1% false at 0.1% false
false detection false detection detection detection
probability probability probability probability
Table 4: LLS Assumptions

7 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

4.1 UPLINK DATA CHANNEL (PUSCH)

This section includes the LLS results for the Physical Uplink Shared Channel (PUSCH) which
carries the UL user data. Table 5 shows the UL data rate at the 5G 164 dB MCL for various
system configurations.

SYSTEM
Base Station System MPDCCH PSD DATA RATE
HARQ
RX Antennas BW Boost
2 10 MHz Yes No 201 bps

4 10 MHz Yes No 313 bps

4 5 MHz Yes No 363 bps

4 10 MHz Yes +4 dB 363 bps

Table 5: PUSCH Data Rates at the 5G 164 dB MCL

Note: The calculation of the above physical layer data rate doesn’t include the impacts of header
overhead for Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence
Protocol (PDCP), or Internet Protocol (IP), or MPDCCH scheduling delays.
Note also that Hybrid Automatic Repeat Request (HARQ) was used in all configurations as it was
found to improve the average data rate. In all cases, the initial transmission had 512 repeats
and then a maximum of two HARQ re-transmissions of 512 repeats were sent. The resulting
or residual Block Error Rate (BLER) in every case was less than 10%. The calculated data rate
includes the average time to schedule the additional HARQ re-transmissions. The average data
rate is calculated based on the BLER achieved after each HARQ cycle.
Since the 5G IoT requirements do not specify a system configuration, different system
KEY MESSAGE bandwidths (BWs), base station antenna configurations, and downlink PSD boost configurations
At 363 bps, LTE-M were simulated. As can be seen from Table 5, usage of four receive antennas at the base station
meets the 5G IoT UL significantly improves the UL data rate. Also, using +4 dB of downlink PSD boost or having a
data rate coverage 5 MHz system bandwidth reduces the number of required MPDCCH repeats from 256 to 128
requirement of 160 repeats, which decreases HARQ scheduling time and marginally improves the UL data rate.
bps at the 5G 164 dB
MCL.
4.2 DOWNLINK DATA CHANNEL (PDSCH)
This section includes the LLS results for the Physical Downlink Shared Channel (PDSCH) which
carries the DL user data. Table 6 shows the DL data rate at the 5G 164 dB MCL for various
system configurations.

SYSTEM
Base Station System DATA RATE
HARQ DL PSD Boost
TX Antennas BW
2 10 MHz No No 300 bps

2 10 MHz Yes No 372 bps

2 5 MHz No No 1000 bps

2 10 MHz No +4 dB 1200 bps

Table 6: PDSCH Data Rates at the 5G 164 dB MCL

8 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Note: The above physical layer data rate doesn’t include MAC/RLC/PDCP/IP header overhead,
KEY MESSAGE
acknowledgement delays, or scheduling delays.
At 1200 bps, LTE-M
easily meets the 5G Note that for the HARQ configuration, the initial PDSCH transmission used 1024 repeats,
IoT DL data rate cov- and then one HARQ re-transmission of 512 repeats occurred. As with PUSCH, the calculated
erage requirement of data rate includes the average time to schedule the additional HARQ re-transmission and the
160 bps at the 5G 164 average data rate is calculated based on the BLER achieved after each HARQ cycle.
dB MCL.
4.3 CONTROL CHANNELS
This section includes the LLS results for all the control channels. Table 7 shows the performance
at the 5G 164 dB MCL for various system configurations.

CHANNEL SYSTEM BW DL PSD BOOST PERFORMANCE

10 MHz No Average acquisition time 880 ms

PSS/SSS 5 MHz No Average acquisition time 350 ms

10 MHz +4 dB Average acquisition time 220 ms

10 MHz No Average acquisition time 250 ms

PBCH 5 MHz No Average acquisition time 150 ms

10 MHz +4 dB Average acquisition time 125 ms

10 MHz No Average acquisition time 650 ms

SIB1-BR 5 MHz No Average acquisition time 200 ms

10 MHz +4 dB Average acquisition time 150 ms

10 MHz No 256 repeats achieve 10% BLER

MPDCCH 5 MHz No 128 repeats achieve 1% BLER

10 MHz +4 dB 128 repeats achieve <1% BLER

PRACH 10 MHz No 128 repeats achieve 3% misdetection

PUCCH 10 MHz No 128 repeats achieve <1% misdetection (Release 14)

Table 7: Control Channel Performance at the 5G 164 dB MCL

Note that the 128-repeat level of the Physical Uplink Control Channel (PUCCH) is a Release 14
feature. All other repeat levels are supported in Release 13.
Given the 5G IoT requirements do not specify a system configuration, the performance of the DL
control channels was analyzed for different system bandwidths and optionally with PSD boost.
For the Primary and Secondary Synchronization Signals (PSS/SSS), Physical Broadcast Channel
(PBCH), and System Information Block 1-Bandwidth Reduced (SIB1-BR), the MCL limit is not
defined by BLER but by an acceptable acquisition time. Given that IoT applications have different
acquisition time requirements, this limit is subjective. Therefore, the average acquisition time
is provided in Table 7. The PSS/SSS detection method analyzed is the same as in [1], which

9 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

combines PSS and SSS sequences for correlation used for re-synchronization. The PBCH
KEY MESSAGE
detection method analyzed is also the same as used in [1], which correlates the received rate
LTE-M control chan-
matched symbols against possible transmitted PBCH symbols and then tests the multiple
nels can effectively
hypotheses to look for a match.
operate at the 5G
164 dB MCL coverage For the remaining channels, a BLER or probability of missed detection is specified.
level.
As seen in Table 7, less than 10% BLER is achieved for all control channels; thus, all control
channels can effectively operate at the 5G 164 dB MCL. As can also be seen from Table 7,
downlink PSD boosting or a 5-MHz system bandwidth significantly reduces both acquisition
time and BLER for the DL channels.
Although not analyzed, a system configuration with four base station receive antennas would
significantly improve both the PRACH and PUCCH performance.
4.4 COVERAGE SUMMARY
KEY MESSAGE Given that the 160 bps data rate target is met by both the UL and DL data channels, and that
LTE-M meets the 5G the LTE-M control channels can effectively operate at the 5G 164 dB MCL coverage level, it can
164 dB MCL coverage be concluded that LTE-M meets the 5G 164 dB MCL coverage requirement.
requirement.

5 Message Latency
For the many IoT applications where small data transmission is common, the message latency
is an important metric for estimating the performance of the provided service. This section
considers the message delivery time or message latency that can be achieved by LTE-M at the
144 and 164 dBs coupling losses, which can be said to correspond to the edge of normal and
enhanced coverage, respectively. The analysis is based on LLS results with assumptions from
Table 4 (unless otherwise stated) and the message sequence described in Section 5.1. The
message latency is calculated up to and including the delivery of an 85-byte uplink message.
That is, message latency calculation doesn’t include any of the messages after the delivery
of the 85-byte uplink message. The 85-byte message includes the application message and
the transport and IP headers (e.g. the UDP/IP headers). In addition, 5 bytes for LTE headers
are assumed which is not included in the 85 bytes. The message latency is calculated using
the 90th percentile for each step, which is a conservative approach. The message latency was
analyzed for both the CIoT 164 dB MCL and the 5G 164 dB MCL.
It should be noted that neither the CIoT nor the 5G IoT requirements consider the boot time
of the modem which can, depending on implementation, be hundreds of milliseconds.
Furthermore, neither set of requirements considers any delays for the network to respond to
protocol control messages from the device. This delay depends on many factors, including any
congestion in the network. This delay is often on the order of 50 ms for commercially deployed
networks. Hence the practical latency may deviate from the estimates in this section depending
on factors specific to the implementation and load.
5.1 MESSAGE SEQUENCE
For the latency evaluations, the message sequence in Figure 1 was used. This corresponds to
the device waking up from Power Saving Mode (PSM) using the Radio Resource Control (RRC)
Resume procedure to resume a suspended RRC connection. The same message sequence was
used for the battery life evaluations in Section 6.

10 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Device eNB Figure 1 depicts the RRC Resume procedure for transmitting a mobile
originated (MO) report including the following steps:
1 Synchonization (PSS/SSS)
2 System Information / MIB (PBCH) 1. Synchronizing to the PSS/SSS after waking up from PSM to
Device
3 System Information / SIB1-BR (PDSCH)
synchronizes achieve time and frequency synchronization, and to acquire
with network subframe timing, physical cell identity, and cyclic prefix length
4 Random Access Preamble (PRACH) information.
5 Random Access Response (PDSCH) 2. Reading Master Information Block (MIB), or PBCH, to acquire the
System Frame Number and SIB1-BR scheduling information.
6 RRC Connection Resume Request (PUSCH)
3. Reading SIB1-BR to acquire the Hyper System Frame Number
7 RRC Connection Resume (PDSCH) Connection
and system information value tag, and access barring status
8 RRC Connection Resume Complete, establishment
RLC ACK and Uplink Data (PUSCH) (more exactly the SIB14-BR scheduling information status).
Data to upper layers
9 RLC ACK for the Uplink Data (PDSCH)
4. Sending the random access preamble on PRACH.
Wait for
application ACK
5. Receiving Random Access Response (7 bytes), including grant for
ACK from upper layers
the next uplink transmission.
10 Application Downlink ACK (PDSCH)
6. Sending RRC Connection Resume Request message (MSG3: 7
11 RLC ACK Downlink Data (PUSCH)
bytes), including the device identity.
12 RRC Connection Release (PDSCH) Connection 7. Receiving RRC Connection Resume message (MSG4: 20 bytes),
13 RLC ACK for Connection Release (PUSCH)
release together with the device contention resolution identity.
8. Transmitting RRC Connection Resume Complete message,
Figure 1: Message sequence for together with Radio Link Control Acknowledge (RLC ACK) for the
battery life and latency evaluations previous transmission (total 22 bytes) and the uplink data (85
or 200 bytes) plus headers from the LTE radio protocol stack (5
bytes).
9. Receiving RLC ACK for RRC Connection Resume Complete (3
bytes)
10. Receiving downlink application ACK (20 or 65 bytes).
11. Transmitting RLC ACK for downlink application ACK (3 bytes)
12. Receiving RRC Connection Release (8 bytes).
13. Transmitting the RLC ACK for the RRC Connection Release
The RRC messages are assumed to be sent without optional fields
in them; if additional configuration information is added to a specific
message, the message size will be correspondingly larger. 5 bytes of
MAC, RLC, and PDCP headers are added to the RRC messages when
appropriate. Uplink data is sent in Step 8, together with the RRC
Connection Resume Complete message.

11 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Additionally, the evaluation takes into account the overheads from the HARQ and RLC
acknowledgements. The first message using HARQ for repeating the uplink transmission, if
needed, is Msg3 in step 6. RLC Acknowledged Mode (AM) is used for all messages starting
at Msg4 in step 7. In our analysis, we assume the RLC protocol does not need to ask for
retransmissions and that RRC connection and release procedures are always successful.
KEY MESSAGE 5.2 MESSAGE LATENCY AT CIOT 164 DB MCL
LTE-M easily meets The CIoT message latency requirement from TR 45.820 [2] is to be able to send an 85-byte
CIoT message latency message within 10 seconds at the CIoT 164 dB MCL coverage level. As per CIoT requirements,
requirements.
the evaluation was conducted assuming a 10-MHz system bandwidth and eNBs implementing
two transmit and two receive antennas at the base station. The LLS results are shown in
Table 8.
CIoT 164 dB MCL CIoT 144 dB MCL
6.2 sec 0.1 sec
Table 8: 90th Percentile Message Latency

Table 8 shows that the CIoT message latency requirement of 10 seconds is easily met by LTE-M.
As table 8 also shows, the message latency is highly dependent on coverage level, so in normal
coverage the message latency is much lower.

5.3 MESSAGE LATENCY AT 5G 164 DB MCL

The 5G IoT message latency requirement from TR 38.913 [3] is to be able to send an 85-byte
message within 10 seconds at the 5G 164 dB MCL coverage level. The results are shown in
Table 9.

KEY MESSAGE 5G 164 dB MCL

BASE STATION
LTE-M meets 5G ANTENNA 10 MHz 10 MHz 5 MHz
message latency CONFIGURATION
requirements for most No DL PSD Boost +4 DL PSD Boost No DL PSD Boost
system configurations. 2 RX, 2 TX 14.3 sec 9.6 sec 9.8 sec

4 RX, 2 TX 11.4 sec 6.7 sec 6.9 sec

Table 9: 90th Percentile Message Latency at the 5G 164 dB MCL

Given the 5G IoT requirements do not specify a system configuration, the message latency was
analyzed for different system bandwidths, different base station antenna configurations, and
with and without downlink PSD boosting.
From the results in Table 9, it can be concluded that a 5 MHz system, or a 10 MHz system using
downlink PSD boosting will meet the 5G message latency requirement. In addition, the results
indicate that with four instead of two receive antennas at the base station, the message latency
improves by approximately 20%, allowing a 10 MHz system without downlink PSD boosting to
almost meet the 5G message latency requirement.

12 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

6 Battery Life
In large-scale IoT deployments, it is important to be able to provide services to all types of use
cases, including those without access to a mains power supply. This section considers the
battery life that can be achieved for an LTE-M device powered by a 5-Wh AA battery when
used for daily reporting of 200-byte uplink messages coupled with 20 or 65-byte downlink
acknowledgements. The evaluation is based on the message sequence chart of Section 5.1,
LLS assumptions from Table 4 (unless otherwise stated), and the power consumption in various
modes shown in Table 10. The power consumption values in Table 10 are consistent with the
assumptions used in the CIoT Study except for the UL transmit Power. The CIoT Study assumed
500 mW but this study assumed 575 mW, translating to a power amplifier (PA) efficiency
difference of approximately 20% due to the higher Peak-to-Average-Power Ratio (PAPR) for
LTE-M single Physical Resource Block (PRB) transmissions.

OPERATING MODE POWER CONSUMPTION

UL TX power 575 mW

DL RX power 80 mW

C-DRX / I-DRX sleep power 3 mW

Deep sleep power 0.015 mW

Table 10: Power Consumption of LTE-M Device in Different Operating Modes

It should be noted that a 5-Wh battery without self-discharge was used for this evaluation.
Neither the CIoT nor 5G IoT requirements consider the battery self-discharge, even though
self-discharge occurs to some level with all battery technologies and is typically in the range
of one to four percent per year. Also, as mentioned in the section on message latency, neither
CIoT nor 5G IoT requirements consider the boot time of the modem, which can be hundreds of
milliseconds. A significant proportion of device power consumption is associated with the power
required to transmit data packets, so the PA efficiency assumption greatly affects the resulting
battery life. PA efficiencies of 50% were considered in the CIoT study and 40% in this analysis, but
the reality is that commercial modems are likely to use PAs with lower efficiencies to support
wider bands, and are likely to have losses associated with front-end filters, switches, and
printed circuit boards, which are not taken into consideration. Hence the practical battery life
may deviate from the estimates in this section depending on implementation-specific factors.
KEY MESSAGE 6.1 BATTERY LIFE AT CIOT 164 DB MCL
LTE-M meets CIoT This section evaluates the CIoT battery life requirement from TR 45.820 [2]. The years of use for
battery life require- LTE-M, for daily transmission of 200-byte UL messages and 65-byte DL messages are given in
ments.
Table 11. These battery life values were calculated assuming a 10-MHz system bandwidth and
eNBs implementing two transmit and two receive antennas.

CIoT 164 dB MCL CIoT 144 dB MCL

10.4 years 35.7 years
Table 11: Battery Life Based on CIoT MCL

13 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Table 11 shows that the CIoT battery life requirement of 10 years is met by LTE-M for the daily
reporting of 200-byte reports in the uplink, even at the extremes of coverage. The battery life
was also evaluated at CIoT 144 dB MCL, which is the extreme edge of normal coverage, to show
that battery life improves significantly where normal (non-coverage enhanced) devices operate.
As seen from Table 11, 10.4 versus 35.7 years of battery life is a large difference for the two
coverage cases, showing that battery life is highly dependent on coverage. As LTE networks
continue to be deployed and densified, network coverage is expected to improve, and this will in
turn significantly improve battery life.
KEY MESSAGE 6.2 BATTERY LIFE AT 5G 164 DB MCL
LTE-M meets 5G bat- This section evaluates the 5G IoT battery life requirement from TR 38.913 [3]. The years of use
tery life requirements.
for daily transmission of 200-byte UL messages and 20-byte DL messages at the 5G 164dB
MCL are given in Table 12.

5G 164 dB MCL
BASE STATION
ANTENNA 10 MHz 10 MHz 5 MHz
CONFIGURATION
No DL PSD Boost +4 DL PSD Boost No DL PSD Boost
2 RX, 2 TX 6.9 years 7.5 years 7.5 years

4 RX, 2 TX 9.6 years 10.9 years 10.8 years

Table 12: Battery Life at 5G 164 dB MCL

KEY MESSAGE From Table 12, it can be concluded that a 10-year battery life is possible for LTE-M when
LTE-M battery life the base station implements four receive antennas and either a 5-MHz system bandwidth
improves when eNBs (without the need for downlink PSD boosting) or a 10-MHz system bandwidth with downlink
implement four re- PSD boosting applied. An uplink message size of 100 instead of 200 bytes supports a 10-year
ceive antennas. battery life for all the two-receive antenna base station configurations in Table 12.

7 Capacity
7.1 EVALUATION ASSUMPTIONS
System capacity is an important performance indicator for LTE-M, since LTE-M strives to
provide connectivity for the mMTC usage scenario. mMTC spans a large variety of services
and applications, as described in [5]. ITU-R also specifies a concrete requirement on IMT-2020
systems in terms of a required connection density of 1,000,000 devices per square kilometer.
The full set of IMT-2020 requirements, including the connection density requirement, is
described in [6] while the methodology for evaluation of the IMT-2020 requirements appears in
[4].
In short, an IMT-2020 system should be capable of handling 1,000,000 devices per km2 that
perform a mobile originated access once every two hours, following a Poisson arrival process,
where each device is to deliver a 32-byte layer-2 Packet Data Unit (PDU) within 10 seconds. The
most important IMT-2020 requirements and configurations defining the connection density key
performance indicators are summarized in Tables 13 and 14. Since configuration B is the more
challenging configuration, as it needs to support a higher number of devices per cell, it is the
focus of this paper.

14 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

REQUIREMENT VALUE
Connection density ≥1,000,000 devices/km2

Grade of service ≥99%

Quality of service ≤10 seconds service latency

Table 13: IMT-2020 Connection Density Requirement

VALUE
PARAMETER
CONFIGURATION A CONFIGURATION B
Traffic model 32-byte mobile originated message every 2 hours

Carrier frequency 700 MHz

Inter-site distance 500 meters 1732 meters

Channel model Urban Macro A, Urban Macro B

Device deployment 80% indoor, 20% outdoor

Building type ratio for indoor users 20% high loss, 80% low loss

Mobility 3 km/h

Base station output power 46 dBm

Base station antenna configuration Up to 64 TX/RX

Base station antenna gain per 8 dBi

antenna element

Base station noise figure 5 dB

Device output power 23 dBm

Device antenna configuration Up to 2 TX/RX

Device antenna gain 0 dBi

Device noise figure 7 dB

Bandwidth ≤10 MHz ≤50 MHz

Table 14: IMT-2020 Connection Density Requirement

7.2 EVALUATION RESULTS

To show fulfilment of the IMT-2020 connection density requirement, an LTE-M dynamic
system-level simulator was configured according to the parameters summarized in Table 14.
In the simulation, a single LTE-M narrowband consisting of six PRBs was configured in 21 cells
defining the studied system. This narrowband did not carry any overhead from PSS/SSS or
MIB/SIB transmission. The total simulation bandwidth equals 1.08 MHz. Base stations were
configured with two cross-polarized transmit/receive antennas, each with 8 elements resulting
in an antenna gain of 17 dBi, whereas devices were configured with one transmit/receive
antenna.

15 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Figure 2 presents the supported service latency defined from the time the higher layers in a
device trigger a mobile originated access attempt to the time the base station receiver confirms
successful reception of the packet. Specifically, Figure 2 depicts the latency achieved at the 99th
percentile of the latency cumulative distribution function recorded across all simulated packet
deliveries during the life time of the simulation. The 99th percentile is of special interest since it
corresponds to the Grade of Service requirement.
Uplink MTC packet delay
15
KEY MESSAGE
Key Finding: For the Configuration B, Urban Macro A (42.91)
worst case IMT-2020 Configuration B, Urban Macro B (47.75)
configuration, LTE-M
can support 357,000
devices per 1.08-MHz
narrowband per km2.
99th percentile uplink MTC packet delay [s]

10

0
10 15 20 25 30 35 40 45 50
Arrival intensity [users/second/narrowband/cell]

Figure 2: Service latency measured at the 99th percentile

The system-level simulation (SLS) results in Figure 2 show that the most challenging channel
model is the Urban Macro A channel. Assuming an Urban Macro A channel, LTE-M can support
43 accesses per second per narrowband per cell, which equates to approximately 357,000
supported devices per 1.08-MHz narrowband per km2.
With 357,000 supported devices per narrowband, LTE-M can thus support more than
1,000,000 devices using four narrowbands. For a 5-MHz system bandwidth (see Figure 3) only
70% of the capacity is utilized to meet the requirement. The downlink PRB utilization is only
around 25% when the system operates at its capacity limit (43 accesses/second/narrowband/
cell), so it can be assumed that this spare downlink capacity can accommodate the overhead
from PSS, SSS, and PBCH, which is less than 5%. Compared to the 50-MHz bandwidth limitation
stipulated by IMT-2020 evaluation guidelines [4], 5 MHz fulfils the capacity requirement by a
large margin.

16 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

KEY MESSAGE LTE-M Narrowband

70% of a 5-MHz PSS, SSS, PBCH
LTE-M system meets
the IMT-2020 re-
quirement of 1 million
devices per km2 in 50
MHz.

fc Frequency
Figure 3: Arrangement of LTE-M narrowbands for a 5-MHz carrier

To ensure that systems are evaluated at a reasonable uplink load, IMT-2020 also requires that
the uplink Interference-over-Thermal is kept below 10 dB. In this case, this means that the
average noise and interference that the base station experiences in the uplink should be below
-106.4 dBm/PRB. For the Urban Macro A channel, the 99th percentile packet delay reaches
10 seconds at approximately 43 users/second/narrowband/cell, and at this point the uplink
interference is approximately -111 dBm/PRB and is thus well below -106.4 dBm/PRB.

KEY MESSAGE 8 LTE-M Enhancements in Releases 14 and 15

Several LTE-M
enhancements are As seen from the above results, the 5G battery life and message latency requirements are met
coming in Releases by LTE-M. In 3GPP releases 14 and 15 further enhancements are currently being developed
14 and 15 that will to improve battery life, message latency, and other aspects of performance, which will make it
improve the battery possible to meet the requirements with more system configurations.
life, message latency, Release 14 [8] introduces Release Assistance Information (RAI) which allows the device to
and capacity results
request it be released from the connected state after it has completed all its communications.
presented in this
This reduces the time the device spends in the connected state and thereby reduces power
paper.
consumption. In addition to this battery-life improvement, Release 14 features also include
increased data throughput, a new 5-MHz category-M2 device, multicast support, positioning
enhancements, voice optimizations, and improved mobility support. For a full description of the
LTE-M features introduced in Release 14, see the work item summary in [9].
Release 15 enhancements for LTE-M are ongoing and expected to be completed by June
2018 [10]. Key objectives for this release include improving latency, spectral efficiency, and
power consumption. To improve latency, potential enhancements include reducing system
acquisition time (e.g. by improving cell search or system information acquisition performance)
and supporting early data transmission (i.e. data transmission already during the random access
procedure). The spectral efficiency, and hence the system capacity, is improved in the downlink
by the introduction of higher-order modulation (64QAM) and in the uplink by the introduction
of finer-granularity (sub-PRB) resource allocation. To reduce power consumption, potential
enhancements include introducing the already mentioned early data transmission and sub-PRB
resource allocation as well as wake-up signals, new synchronization signals, improved HARQ
feedback, and relaxed measurements for cell reselection.

17 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

Supporting the features introduced in Releases 14 and 15 is optional for both the device and the
network. All UEs and networks are fully backward compatible with Release 13, meaning that
the new features can be introduced gradually.

KEY MESSAGE 9 Summary

LTE-M category-M1
meets all CIoT and 5G The LTE-M category-M1 performance is evaluated against the CIoT and 5G requirements for
IoT requirements from message latency, battery life, and capacity. Table 15 summarizes the results.
3GPP and ITU. As seen from Table 15, LTE-M meets all the CIoT and 5G IoT requirements. The 5G battery
life and message latency requirements are met for certain system configurations, and LTE-M
enhancements are currently being developed in 3GPP Release 15 to further improve the battery
life, message latency, and capacity. Preliminary indications suggest 5G requirements will be
supported for all system configurations with these new Release 15 enhancements.

REQUIREMENT LTE-M PERFORMANCE

CIoT Requirements

Message latency ≤10 seconds 6.2 seconds

Battery life ≥10 years 10.4 years

5G Requirements

Capacity 1 million devices per km2 ≤50 MHz 70% of a 5 MHz system

Coverage ≥160 bps UL 363 bps & DL 1200 bps*

Message latency ≤10 seconds 6.7 seconds*

Battery life ≥10 years 10.9 years*

Table 15: LTE-M Performance Summary

* Assumes four receive and two transmit antennas at the base station and +4 dB downlink PSD boosting

18 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

10 References
[1] “Coverage Analysis of LTE-M Category-M1” V1.0 Jan 2017,
https://sierrawireless.com/-/media/iot/pdf/LTE-M-White-Paper
[2] 3GPP TR 45.820 V13.1.0, “Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT)”
[3] 3GPP TR 38.913 V14.3.0, “Study on scenarios and requirements for next generation access technologies”
[4] ITU-R M.2412-0, “Guidelines for evaluation of radio interface technologies for IMT-2020”,
https://www.itu.int/pub/R-REP-M.2412-2017
[5] ITU-R M.2083, “IMT Vision - Framework and overall objectives of the future development of IMT for 2020 and beyond”,
https://www.itu.int/rec/R-REC-M.2083
[6] ITU-R M.2410-0, “Minimum requirements related to technical performance for IMT-2020 radio interface(s)”,
https://www.itu.int/pub/R-REP-M.2410-2017
[7] 3GPP RP-150492, Rel 13 Work Item Description “Further LTE Physical Layer Enhancements for MTC”
[8] 3GPP RP-170532, Rel 14 Work Item Description “Further Enhanced MTC for LTE”
[9] 3GPP RP-171441, Rel 14 Work Item Summary “Summary for WI Further Enhanced MTC for LTE”
[10] 3GPP RP-172811, Rel 15 Work Item Description “Even Further Enhanced MTC for LTE”

REVISION UPDATE
V1.0 Initial Release

V1.1 Corrected base station antenna and HARQ columns in Table 6

V1.1 Added additional supporting companies

V1.1 Update ITU references 4,5, and 6 and 3GPP reference 10

V1.1 Added clarifications in section 5 and 5.1 regarding the 85-byte message size

19 of 20
 Evaluation of LTE-M towards 5G IoT requirements for Category-M1 Devices
White Paper

CONTACTS
Sierra Wireless Gus Vos (Editor) gvos@sierrawireless.com

Ericsson Johan Bergman johan.bergman@ericsson.com

Altair Yigal Bitran yigal@altair-semi.com

Sony Martin Beale martin.beale@sony.com

Virtuosys Mark Cannon mark.cannon@virtuosys.com

AT&T Robert Holden rholden@att.com

Verizon Yee Sin Chan yeesin.chan@verizonwireless.com

Sequans Guillaume Vivier gvivier@sequans.com

Orange Ronan Le Bras ronan.lebras@orange.com

KDDI Toshiyasu Wakayama to-wakayama@kddi.com

Nokia Rapeepat Ratasuk rapeepat.ratasuk@nokia-bell-labs.com

NTT DOCOMO Naoto Okubo ookubona@nttdocomo.com

KT Kyujin Park kyujin.park@kt.com

SoftBank Yosuke Akimoto yosuke.akimoto@g.softbank.co.jp

SK Telecom Sangmin Lee lesam821@sk.com

Telenor Sofia Tropé sofia.trope@telenor.com

KPN Frank Mertz frank.mertz@kpn.com

China Unicom Yun Hu huyun9@chinaunicom.cn

Sprint George Cummings george.cummings@sprint.com

Singtel Thomas Chan chanthomas@singtel.com

Sierra Wireless is a registered trademark of Sierra Wireless Inc.

Ericsson is a trademark or registered trademark of Telefonaktiebolaget LM Ericsson.

Altair is a trademark of Altair Semiconductor Limited.

SONY is a registered trademark of Sony Corporation.

Virtuosys is a trademark of Virtuosys Limited.

AT&T is a trademark of AT&T Intellectual Property or AT&T affiliated company (“AT&T Marks”).

Verizon is a registered trademark of Verizon.

Sequans is a trademark of Sequans Communications SA.

The name ORANGE and the logo ORANGE displayed in this paper are trademarks owned by Orange Brand Services Limited, a company belonging to Orange.

KDDI is a trademark of KDDI Corporation.

Nokia is a registered trademark of Nokia Corporation.

NTT DOCOMO is a trademark of NTT DOCOMO, INC..

KT is trademark of KT Corporation.

SoftBank, SoftBank’s equivalent in Japanese and the SoftBank logo are registered trademarks or trademarks of SoftBank Group Corp. in Japan and other countries.

SK Telecom is a trademark of SK Telecom Corporation.

Telenor is a registered trademark of Telenor ASA.

China Unicom is a trademark or registered trademark of China United Network Communications Limited

The Singtel logo is the registered trademark of Singtel. Singtel agrees to the sole use of the Singtel logo on the cover page of Evaluation of LTE-M towards 5G IoT Requirements,
subjected to Singtel’s approval in all things including placement, colour etc. No further rights to use Singtel trademark is granted without Singtel’s express approval.

All other company and product names may be trademarks of the respective companies with which they are associated.