LTE-BL/CE (LTE-M1)

BL stands for Bandwidth reduced Low complexity and CE stands for Coverage Enhancement. In release 13, you would see many statements about BL UE/CE UE, but I took me quite a while to find out what they stands for :) (I found it in 36.300).

In many Whitepaper or articles, you might have seen the term like MTC, LTE-M1. But in formal 3GPP Technical Specification, you would noticed that these terminology (e.g, MTC, LTE-M1) is not clearly defined. In 3GPP TS, the term BL/CE is usually used to indicate the implementation of LTE-M1.

Followings are topics / sections that I want to cover in this page.

Reference

Fundamental Features of LTE-M1

Before the channel details, it helps to know what LTE-M1 was asked to do. Three goals drove the design, and they pull against each other. Cheap hardware wants a narrow receiver, deep coverage wants more energy on the air, and a ten year battery wants the radio switched off. Almost every feature in this section is a compromise between those three.

In short, LTE-M1 (BL/CE) is an design / implementation that is to meet the MTC criteria in Figure 1.

MTC criteria diagram with Low Cost Low Complexity, Enhanced Coverage and Low Power Consumption around a central MTC Criteria label

Figure 1. The three MTC criteria LTE-M1 has to satisfy at the same time. None of them can be reached by tuning a legacy LTE UE, because each one asks a different part of the design to change.

Low Cost Low Complexity : a narrow receiver, one antenna and one layer, which is what removes most of the silicon area and most of the price.
Enhanced Coverage : the same message sent again and again, which buys link budget with time rather than with transmit power.
Low Power Consumption : long paging cycles and a radio that stays off between them, because the battery has to last years rather than days.

Followings are some of the major characteristics of LTE-M1.

LTE-M1 operate only in 1.4 Mhz (6 RB) bandwidth.
LTE-M1 operate in Half Duplex mode
LTE-M1 use the limited (reduced) max transmission power.
LTE-M1 would mainly operate with legacy LTE using wider system bandwidth (e.g, 10 Mhz, 20Mhz system bandwidth).
LTE-M1 divide the legacy LTE system bandwidth into multiple sections of 1.4 Mhz and use any one of those sections (theoretically, LTE-M1 can use different 1.4Mhz section within the system bandwidth at every subframe)
LTE-M1 does not use PCFICH, PHICH, PDCCH which is required to be spreaded across the whole system bandwidth of legacy LTE.
LTE-M1 use specially designed control channel called MPDCCH.
In LTE-M1, MPDCCH and the corresponding PDSCH (i.e, the PDSCH scheduled by the MPDCCH) is not in the same subframe. This is called 'Cross-subframe scheduling'.
LTE-M1 use specially designed DCI formats (6-0A,6-0B,6-1A,6-1B,6-2)
LTE-M1 can transmit PBCH, PRACH, M-PDCCH, PDSCH, PUCCH, PUSCH in repeating fashion. (This is to make these channels decodable even when the signal quality/power is very poor as in the harsh condition like basement. As a result, this kind of repeating transmission would make the effect of increasing cell radius and signal penetration)
LTE-M1 support only the limited number of transmission mode : TM 1,2,6,9 which can operate in single layer.
In LTE-M1, PDSCH scheduling (DCI) and transmission happens in different subframe (Cross Subframe Scheduling).
LTE-M1 utilize a new physical channel format that transmit SIB/RAR/Paging in repetitive mode without using control channel

All the resource allocation information (subframe, TBS, Subband Index) for SIB1 decoding is determined by a MIB parameter (No Control Channel is used for this)
All the resource allocation information (subframe, TBS, Subband Index) for SIB2 decoding is determined by several SIB1 parameters (No Control Channel is used for this)

LTE-M1 support the extended Paging (DRX) Cycle

One caution before moving on. The list above describes Release 13, which is where LTE-M1 started and where most of the design still sits. Two of those statements have since been relaxed. Release 14 raised the 1.4 MHz limit for a UE that supports the wider channel, and the transport block sizes grew with it. The release section further down says which item changed when.

Narrowband is the root of the design : a 6 PRB receiver is what forces MPDCCH, cross-subframe scheduling and the hopping narrowband, so most of the other items on the list follow from this one.
Repetition buys coverage with time : every channel can be sent again and again, which raises the link budget without raising transmit power or widening the receiver.
The control plane was rebuilt rather than reused : PCFICH, PHICH and PDCCH all spread across the full system bandwidth, so a 6 PRB UE can read none of them and MPDCCH replaces all three.

Compatibility with legacy LTE

How is LTE M1 compatitle with legacy LTE ? Actually this can be a pretty fundamental question and help you a lot to understand about LTE M1 and Legay LTE comparison, but I asked this question to myself with more practical reason. When I started to reading LTE M1 3GPP specification (I think it was around Aug 2016), I was eager to try something myself just to understand the specification itself. (I am not such a genious to understand the details just by reading the documents. There has been almost nothing that I got a detailed understanding without hands-on). Of course, at that time there was no LTE M1 device that I could try with and I didn't have any LTE-M1 capable test equipment either. Fortunately, However, I had access to a couple of pretty good toys : a LTE network simulator with super detailed controllability and high performance vector signal analyzer with LTE analysis feature. So my idea was :

Just based on a couple of initial reading it seemed as if LTE-M1 is very similar to legacy LTE.
It is just using 1.4 Mhz which is also supported by legacy LTE.
It is using half-dulplex. Half-duplex was there from day 1 of the legacy LTE.
It is using a special control channel called M-PDCCH, but this is very similar (almost same) concept to E-PDCCH which is also supported by the legacy LTE

And with some other reason, I thought I might tweak my super flexible LTE network simulator to act like LTE-M1 eNB at physical layer at least. But the hard reality that I realized was 'it SOUND very similar to legacy LTE, but not same. Not even at the level of similarity where the legacy LTE can be tweaked to emulate a small feature set of LTE-M1'. In short, followings LTE-M1 feature is same as legacy LTE.

PSS (Primary Synchronization Signal) is common to both legacy LTE and LTE M1
SSS (Secondary Synchronization Signal) is common to both legacy LTE and LTE M1
CRS (Cell Specific Reference Signal) is common to both legacy LTE and LTE M1

It means if you have LTE-M1 device, you may test with the legacy LTE equipment to check if it can detect the cell and decode physical cell ID and check if it can come up with reasonal measurement of RSRP, RSRQ.

However, the similarity ends here. All other things are not compatible with the legacy LTE even if they sound similar. Even for MIB (PBCH), LTE-M1 uses different resource element mapping from legacy LTE (See LTE-M1 PBCH). SIB1 decoding is not compatible either. LTE-M1 SIB1 scheduling is not determined by DCI. It is determined by a single parameter contained in MIB and a set of pretty complex predefined table. On top of it, the physical location of SIB1 hops among multiple locations (i.e, across the multiple narrowband index). See LTE-M1 SIB1 (i.e, SIB1-BR) page for the details. From here (from RACH), the differences diverges even further. The scheduling method is completely different and almost every transmission of PDSCH, PUSCH is being done in very specially designed repeating fashion.

In short, my final conclusion was to give up the attempt to try LTE-M1 by tweaking the legacy LTE protocol stack and decided to wait until I get a touch on real LTE-M1 device and LTE-M1 equipment. Now (as of Mar 2017) I got access to LTE-M1 test equipment and waiting to get a touch to LTE-M1 UE :)

There is a reason the shared part stops exactly where it does. LTE-M1 lives inside an ordinary LTE carrier, so it has to find that carrier the way any UE does. PSS and SSS occupy the centre 72 subcarriers, which is exactly 6 PRBs, so a narrowband receiver reads them unchanged. CRS is sent across the whole system bandwidth, but its pattern repeats in every resource block, so the UE can use whichever part falls inside the narrowband it is tuned to. Everything after cell search either spreads across the full bandwidth or depends on repetition, and neither survives on a legacy stack.

Cell search is the only fully shared part : PSS, SSS and CRS are identical, so legacy equipment can find the cell, read the physical cell ID and produce a sensible RSRP and RSRQ.
MIB is where the split begins : the PBCH resource element mapping differs, and the MIB carries the SIB1-BR scheduling that a legacy UE has no field for.
System information drops the control channel : a MIB parameter and a fixed table decide the subframe, the transport block size and the narrowband for SIB1-BR, so there is no DCI to follow.
A legacy stack cannot be tweaked into an LTE-M1 stack : the scheduling model, the repetition and the narrowband hopping are all new, so even a small feature set cannot be emulated.

What makes a UE a BL UE ?

This page has used BL UE and LTE-M1 as if they were the same thing, and for most purposes they are. The specification is stricter, though, and it keeps apart two ideas that are easy to merge. One is a device built with a narrow receiver. The other is any device that needs extra help to reach the cell at all. 36.300 defines them in separate clauses, and a UE can be the second without being the first.

A BL UE is the first idea. It can camp on any LTE system bandwidth, but its own channel bandwidth is limited to 6 PRBs in both directions, which is the widest channel a 1.4 MHz LTE system offers. That limit is a property of the hardware and it does not change with the radio conditions. A BL UE also has no interworking with NR at all, so NR measurement reporting, reselection, handover and redirection are all absent.

Enhanced coverage is the second idea, and it is a mode rather than a device class. 36.300 defines two of them, mode A and mode B. Support for mode A is mandatory for a BL UE, so every LTE-M1 device has it. Mode B is the one with the large repetition counts. An ordinary Category 0 or higher UE can also be put into enhanced coverage when its radio conditions demand it, and that UE is not a BL UE at any point.

Figure 2. A BL UE is always in the enhanced coverage framework, because CE mode A is mandatory for it. A non-BL UE enters the same framework only when it needs to, and leaves again. Both kinds need a cell whose MIB schedules SIB1 for BL UEs, and both treat any other cell as barred.

The two ideas meet in one table. How wide a UE may actually be scheduled depends on two things: the category it declared, and the CE mode it is in at the time. The network configures the two directions separately, by dedicated RRC signalling.

UE category / CE mode	CE mode A	CE mode B
BL (Category M1)	6 / 6	6 / 6
BL (Category M2)	24 / 24	24 / 6
Non-BL (Category 0 and higher)	96 (or 24) / 24	96 (or 24) / 6

36.300 Table 23.7a-1, maximum PDSCH / PUSCH bandwidth in PRBs. Read each cell as downlink over uplink. The uplink stays at 6 PRB in CE mode B for both BL categories, which is the row to check when an uplink throughput figure comes out lower than expected.

The category itself is defined in 36.306, and it fixes more than the bandwidth. The numbers below are what a UE signals when it reports ue-CategoryDL and ue-CategoryUL. A Category M2 UE has to indicate Category M1 as well, so a network that understands only M1 still sees a usable device.

Parameter	Category M1	Category M2
Maximum DL-SCH transport block bits per TTI	1000 or 1736	4008
Maximum UL-SCH transport block bits per TTI	1000 or 2984	6968
Total number of soft channel bits	25344 or 43008	73152
Layers for downlink spatial multiplexing	1	1
Half duplex FDD operation type	Type B	Type B
Maximum UE channel bandwidth	1.4 MHz	5 MHz

36.306 Tables 4.1A-1, 4.1A-2, 4.1A-5 and 4.1A-7. The Category M2 bandwidth is the smaller of 5 MHz and whatever the band allows in 36.101.

Two rows there deserve a second look. Both categories are half duplex FDD type B. Type B needs a guard subframe when the UE switches between receiving and transmitting, and that guard is what the Guard Period topic below covers. Both are also limited to a single layer, so no amount of extra bandwidth turns an LTE-M1 device into a MIMO device.

BL is a device class, enhanced coverage is a mode : the first is fixed when the device is built, and the network moves a UE into the second and out again as its radio conditions change.
CE mode A is mandatory for a BL UE : that is why the two ideas look like one in practice, even though 36.300 keeps them in separate clauses.
A cell without SIB1-BR scheduling is barred : the MIB has to say that scheduling information for SIB1 specific to BL UEs is present, and without it the UE will not even try.
Category M2 widens the channel but not the layer count : 24 PRBs and a 4008 bit downlink transport block raise the throughput, while spatial multiplexing stays at one layer.
A non-BL UE in enhanced coverage is not an LTE-M1 device : it keeps its own category and can be scheduled over 96 PRBs, so do not read every enhanced coverage log as an LTE-M1 log.

How did LTE-M1 change after Release 13 ?

Most of this page was written against Release 13, and Release 13 is still the core of LTE-M1. Every release since has added optional features on top of it rather than replacing anything, so a Release 13 device and a Release 17 network still interoperate. What changed is the limit rather than the design. Throughput, latency and battery life all improved, and the features below are the ones that did it.

Figure 3. The headline additions of each release. Nothing on this line is mandatory, so what a given deployment actually supports is a question for its UE capability and its SIBs rather than for its release number.

The table sets out the same list with the RRC field that carries each one. The release suffix on a field name is the reliable way to date a feature, because 36.331 stamps every addition with the release it arrived in.

Release	What it added	RRC field
Rel-13	Category M1, and the two coverage enhancement modes the rest of the page describes	ce-ModeA-r13, ce-ModeB-r13
Rel-14	A wider channel. 5 MHz for a BL UE, and 5 or 20 MHz for a non-BL UE in enhanced coverage. Also 10 downlink HARQ processes instead of 8 in FDD, a DCI controlled HARQ-ACK delay, and a switch between normal and enhanced coverage without a handover	ce-PDSCH-MaxBandwidth-r14, ce-PDSCH-TenProcesses-r14, ce-SchedulingEnhancement-r14, ce-SwitchWithoutHO-r14
Rel-15	64QAM for non-repeated unicast PDSCH in CE mode A, an uplink allocation smaller than one PRB, a flexible starting PRB, a wake-up signal, and early data transmission during random access	ce-PDSCH-64QAM-r15, ce-PUSCH-SubPRB-Allocation-r15, ce-PDSCH-FlexibleStartPRB-AllocConfig-r15, wakeUpSignal-r15, edt-Parameters-r15
Rel-16	One DCI scheduling several transport blocks, up to 8 in CE mode A and up to 4 in CE mode B. Also preconfigured uplink resources, so a UE can send without a random access, and CRS based channel estimation for MPDCCH	ce-PDSCH-MultiTB-Config-r16, ce-PUSCH-MultiTB-Config-r16, pur-Config-r16, crs-ChEstMPDCCH-CE-ModeA-r16
Rel-17	Non-terrestrial networks for BL UEs and UEs in enhanced coverage, and a 1736 bit downlink transport block for a half duplex Category M1 UE in CE mode A	ntn-ConfigCommon-r17, ce-PDSCH-maxTBS-r17
Rel-18	HARQ feedback that can be disabled for multi transport block scheduling on a non-terrestrial network, where the round trip is long enough to make a HARQ retransmission a poor trade	ntn-RRC-HarqDisableMultiTB-CE-ModeA-r18, ntn-DCI-HarqDisableMultiTB-r18

Each row is dated by the release suffix of the field that configures it in 36.331. The field names are worth keeping, because they are what a capability log or a SIB decode will actually show.

Two of these are worth a sentence more, because they change how the page above should be read. The Release 14 bandwidth field is the one that retires the flat 1.4 MHz statement. When ce-PDSCH-MaxBandwidth is absent, the maximum PDSCH channel bandwidth stays at 1.4 MHz. That is the Release 13 behaviour, so the original text is still right for a network that does not send the field.

The Release 16 multi transport block feature is the other one. Cross-subframe scheduling means every grant costs an MPDCCH decode, and repetition makes each decode expensive. Letting one DCI carry up to eight transport blocks spreads that cost over eight times as much data, which is why it helps throughput far more than the raw bit rate suggests.

Nothing here is mandatory : every feature is an optional capability, so the release number of a network says what it may support rather than what it does.
Release 14 is the one that dates the older text : the 1.4 MHz limit and the small transport blocks are Release 13 values, and a Category M2 device exceeds both.
The later releases cut overhead rather than raise the bit rate : multi transport block scheduling, preconfigured uplink resources and early data transmission all remove signalling rather than widen the channel.
Check the field name, not the marketing name : a capability log names ce-PDSCH-MaxBandwidth-r14 rather than Cat-M2, and the suffix tells you the release without any guessing.

List of the detailed topics

Followings are list of the detailed topics. I am assuming that readers already have knowledge on how legacy LTE works and I will describe these topics with focus on the differences from the legacy LTE.

The list runs roughly in protocol stack order, which is not the order to read it in. Three topics come first, because the rest assume them. CE Operation Mode is the split between mode A and mode B that the section above introduced. CE Level is how a UE decides which level it is in, and that level drives the repetition counts everywhere else. Narrowband is the 6 PRB window every physical layer topic below then works inside. After those three, the physical layer topics can be taken in any order.

Reference

The clauses and tables behind the two sections above.

TS 36.300 v19.2.0 : Overall description, Stage 2 - clause 23.7a Support of Bandwidth Reduced Low Complexity UEs, clause 23.7b Support of UEs in Enhanced Coverage, and Table 23.7a-1
TS 36.306 v19.3.0 : UE radio access capabilities - clause 4.1A, with Tables 4.1A-1, 4.1A-2, 4.1A-5 and 4.1A-7
TS 36.331 v19.3.0 : Radio Resource Control protocol specification - the ce- and ntn- coverage enhancement fields, and their release suffixes