This post describes the operation of the MTC Physical Downlink Control Channel (MPDCCH) for sending downlink assignments and uplink grants to the client device.
Purpose of the MPDCCH
In LTE-M, radio resources assignments (the times and frequencies when a device is expected to receive or transmit) are dynamic, for both downlink (“DL”, network to device) and uplink (“UL”, device to network). Every bandwidth allocation covers a period of one subframe (which is 1 millisecond) and every bandwidth allocation is assigned independently. We need a special control channel to carry this control information that is moving in the downlink direction, which is called “downlink control information” or “DCI”. This is the purpose of the MPDCCH: to carry the DCI that describes UL grants and DL assignments. The MPDCCH is also used to carry other DCI, like paging information and information about changes to the cell configuration, but the focus of this article is the radio resource assignments. An LTE-M Category M1 device receives a fixed radio bandwidth of 1.4 MHz, which is 6 “resource blocks” (RB) in the frequency domain. This 6-RB span is called a “narrowband”, a term that we will use lot here. An LTE eNodeB that supports LTE-M will have up to 19 non-overlapping narrowbands.
Also, although the specifications normally refer to the LTE client device (smartphone, for example) as the User Equipment (“UE”), but here we will just refer to the LTE-M modem as the “device”, since there is normally no actual user present.
The MPDCCH is the most critical feature of the LTE-M design. It is the entry point that allows LTE-M to exist inside a standard LTE signal, sharing its radio resources efficiently, but without requiring any changes to the legacy LTE specifications. Legacy LTE is just scheduled around LTE-M, and a legacy LTE device is not affected by the presence of LTE-M in the signal.
LTE-M PDCCH versus LTE PDCCH
In standard LTE, DCI is sent on the PDCCH in the first 1-4 OFDM symbols of each DL subframe, and the DCI encoded there describes DL assignments (in the current subframe) and UL grants (4-6 subframes in the future). This standard PDCCH occupies the full radio bandwidth of the LTE signal, up to 20 MHz (100 resource blocks). This wide spread of frequencies gives a very robust signal for standard LTE handsets, but LTE-M devices are limited to a receiver bandwidth of 1.4 MHz (6 resource blocks), and therefore it is physically impossible for LTE-M devices to receive the PDCCH in most LTE configurations. To resolve this problem, LTE-M defines a new channel type, the MPDCCH, that can carry LTE-M DCI in a bandwidth of 1.4 MHz or less (no more than 6 resource blocks), but that fits into the standard LTE signal without changing the existing channel structures and PHY procedures.
This new MPDCCH is based on the EPDCCH (Extended Physical Downlink Control Channel), which was added to the LTE-A specifications to carry additional DCI in very busy cells, and can co-exist with legacy LTE in the same time-frequency grid. The MPDCCH is very similar to the EPDCCH, but with these changes:
- MPDCCH radio bandwidth can be 2, 4, or 6 (“4+2”) resource blocks.
- The DCI formats are different on MPDCCH, from the 6-x group.
- The timing relationships between the MPDCCH DCI and the LTE-M traffic are different.
- The MPDCCH supports repetition to improve reliability and coverage.
Using the MPDCCH in LTE-M
The “address” of an LTE or LTE-M device in the radio PHY is a 16-bit number called the Radio Network Temporary Identifier (RNTI). Every device that is connected with an eNodeB gets an RNTI assigned to it when the radio channel is created. DCI messages to the device are then scrambled with the destination device’s RNTI, making it very unlikely that one device will accidentally decode a message sent to some other device. At any given moment, an idle LTE-M Category M1 device is monitoring a single MPDCCH in a single narrowband, decoding specific sections of the signal that might carry messages addressed to it, using its own RNTI for descrambling.
Note: Scrambling based on the 16-bit RNTI is an addressing mechanism, not a security mechanism.
How the Device finds the MPDCCH
The LTE signal may contain up to 19 LTE-M narrowbands, each of which may carry the MPDCCH in any given subframe. Which narrowband is the device suppose to monitor for its MPDCCH? How does it know? The MPDCCH is assigned to the device during channel setup. But it is a multi-step process that might take the device through several different narrowbands along the way, so it is easy for a human reader (or developer) to get confused about which narrowband is being used for what purpose at each step. To add to the confusion:
- In some contexts the narrowbands are numbered starting from 0 in and other contexts they are numbered starting from 1.
- In some contexts, the bit field sizes are limited and only some subset of possible narrowbands can be specified.
- In some contexts, a narrowband index tells where to find the MPDCCH that will carry the DCI for a given message, while in other contexts, a narrowband index may tell where to find the message itself.
What follows is the complete LTE-M signal acquisition and radio channel setup procedure, as described in 3GPP Specifications 36.331 (multiple sections), 36.321 (Section 5.1), and 36.213 (Section 6). The specs spread this information across several sections of several documents, but here it is all together:
Step 1: PSS/SSS/MIB (DL)
The device detects and decodes the Primary Synchronization Signal (PSS) and Secondary Synchronization Signal (SSS) to get the PHY Identity (PID) and subframe synchronization of the eNodeB. Then it uses this information to decode the Master Information Block (MIB). From the MIB, the device determines the frame synchronization and the narrowband that is used for sending System Information Block Type 1 (SIB1).
Step 2: SIB1 (DL)
SIB1 indicates the operator network identity of the eNodeB and the timing, narrowband, and messaging encoding parameters that the device needs to receive System Information Block Type 2 (SIB2).
Step 3: SIB2 (DL)
SIB2 gives the configuration of the Physical Random Access Channel (PRACH), including which preambles are used for which CE modes, and the location of the narrowband used for LTE-M PRACH transmissions. It also tells the device which LTE-M narrowband is used for the MDPCCH that carries the downlink assignments for Msg2 during a PRACH procedure, the “RAR narrowband”. (Note that the RAR narrowband carries the MPDCCH that carries the DCI for Msg2, not Msg2 itself.)
Once the device has received SIB2, it has all of the information it needs to begin the channel setup procedure.
Step 4: PRACH (“Msg 1”, UL)
When the device is ready to access the network, it selects a PRACH preamble to indicate the CE mode it wants to use and then sends the PRACH using the selected preamble. From the selected preamble and the time when the message is sent, the device also calculates a 16-bit RA-RNTI that will be used to scramble the DCI for Msg2.
Step 5: MPDCCH DCI for RAR (DL)
The device monitors the MPDCCH on the RAR narrowband, looking for the DL assignment for Msg2, using a scrambling code based on the RA-RNTI. This Msg2 assignment must be sent by the eNB within a small time window of just a few subframes after the PRACH. If the device does not receive the RAR assignment within this window, it returns to Step 4.
Step 6: RAR (“Msg2”, DL)
Section 6.1.5 of 3GPP 36.321 describes the MAC message for Random Access Response (RAR). This is what the eNodeB sends to a device to grant UL bandwidth for the device to send an initial service request to the network. Table 6-2 of 36.213 describes the “uplink grant” part of the RAR message for LTE-M. For this discussion, these are the key parts of the RAR:
- The narrowband index that will be used for Msg3 on PUSCH, numbering from 0.
- The UL grant for Msg3, within that narrowband.
- The narrowband index that will be used to carry the DL assignment for Msg4, or used for additional UL grants of Msg3 if HARQ retransmissions are needed. This narrowband is called the “Msg34 narrowband”, and is numbered from 0.
- The newly assigned C-RNTI that will be used to scramble all future DCI addressed to this device on this connection.
Read closely and note the difference between the narrowband used for a message and the narrowband used for the MPDCCH that will carry the grant or assignment for a message. Here are some points that are critical but not obvious:
- The initial transmission of Msg3 has no associated grant on MDPCCH, because the RAR payload already gave the UL grant. This is the same principle as in legacy LTE.
- The Msg34 narrowband that is referenced in this MCE will be used for MPDCCH for UL grants for HARQ retransmissions of Msg3, if they are needed. Note that this is the narrowband that will carry the MPDCCH, and that the narrowband for the Msg3 retransmissions themselves will be given in the DCI on that MPDCCH.
- The Msg34 narrowband that is referenced in this MCE will be used for the MPDCCH that carries the DL assignment for Msg4. The narrowband to be used for Msg4 itself will be given in the DCI on that MPDCCH.
If the device fails to receive the RAR at the assigned time, it returns to Step 4.
Step 7: RRC Connection Request (“Msg3”, UL)
The device sends the Setup Request using the Msg3 narrowband assigned in Msg2. This request includes a “contention resolution identity”, a large number, usually random and unique to every request. This message is sent exactly 6 subframes after Msg2, following the UL grant in that message. The device also starts the timer T300 at this point, which is used to terminate stuck connection procedures.
Step 8: MPDCCH for Msg4 (DL)
The device monitors the Msg34 MPDCCH for DL assignment for Msg4, using a scrambling code based on the newly assigned C-RNTI. The DCI format will be 6-1A or 6-1B, depending on the CE level that the eNodeB has chosen for the device.
Step 9: Contention Resolution (DL)
It is possible that two devices sent PRACH with the same preamble at the same time. If this happens, these two devices will have the same RA-RNTI and receive the same RAR. This is called “contention”. To resolve possible contention, the MAC layer of the eNodeB sends to the devices a Contention Resolution (CR) MAC Control Element (MCE) containing the 48 lower bits from the contention resolution identity send in Msg3. If a device does not receive the CR MCE within a given time limit, or if it receives one that does not match the identity that it sent earlier in Msg3, the device abandons the procedure and goes back to Step 4. Because CR MCE is 48 bits, the probability of an accidental mismatch is so small that it will probably never happen, but if it does, the radio link will still fail once the mandatory security mechanisms start.
The CR MCE is normally sent together with Msg4 in the same transport block, but it can be sent separately, ahead of Msg4, in a procedure called “early contention resolution”. If the CR MCE is sent separately, it will need its own DCI, which will be sent in the same MPDCCH as the DCI for Msg4, adding even more steps to this procedure.
The contention resolution procedure is complete when the device receives a correct CR MCE.
Step 10: RRC Connection Setup (“Msg4”, DL)
The device receives Msg4, the RRC Setup message, which configures the PHY and MAC layers for the radio connection and also configures the RLC and PDCP layers for Signaling Radio Bearer #1 (SRB1) which is the logical channel used for low-level connection management. If T300 expires before Msg4 is received, or if it receives Msg4 before completing the contention resolution procedure of Step 9, the device will abort the procedure and start again from Step 4.
As part of the PHY configuration, the RRC Setup Message carries a final MPDCCH configuration that will be used for all future DCI to this device during this connection, including a narrowband index.
Step 11: SR for Msg5 on PUCCH (UL)
The PHY/MAC configuration in Msg4 also included a PUCCH configuration that the device can use to notify the eNodeB that it has data to send on UL. This procedure is called Scheduling Request (SR) and is described in 3GPP 36.213 Section 10.1.5. The device will use the SR procedure to request an UL grant for sending Msg5, which is the response to Msg4. The eNodeB cannot really schedule Msg5 without SR, since it does not know how long the device will need to complete the processing of Msg4, and to wait the maximum allowed time would be inefficient for most devices most of the time.
So if you do not already know about the LTE PHY, you are asking, “What is the PUCCH?” It is the Physical Uplink Control Channel, which is used to carry control information in the UL direction (UL Control Information or UCI). The PUCCH is a low-bandwith channel that is used to transmit a few bits at a time for certain MAC and PHY procedures. The LTE-M PUCCH is the same as the LTE PUCCH, except that it uses the same RB location in both slots to insure that the PUCCH stays inside the allowed 6-RB radio bandwidth.
Step 12: MPDCCH for Msg5 (DL)
The eNodeB will see the SR from the device and send an UL grant on the MDPCCH that was configured by Msg4. If the device does not receive this grant within the SR timeout period, it will abort the procedure and return to Step 4. The DCI format will be 6-0.
Step 13: Connection Setup Complete (“Msg5”, UL)
The device sends RR Setup Complete to the eNodeB on SRB1, confirming that the radio connection setup is successful. The transport block that carries this message usually also carries the so-called Initial UE Message that starts the connection between the device and the core network.
Note: If the UL grant from Step 12 is not large enough to carry the full payload, the device will segment the Initial UE Message in SRB1 RLC and also send a Buffer Status Report (BSR) MCE to the eNodeB informing it of how much data is waiting to be sent. The eNodeB will then need to send another grant on MPDCCH, adding even more steps to this procedure. But a smart scheduler can use knowledge of the procedure to set a sufficient UL grant size in Step 12.
And then what happens?
At this point, the radio channel is established and the device goes on to establish a connection to the core network and then to the IP network, all continuing to use the same MPDCCH assigned in the RRC Connection Setup message in Step 10. Note that the DCI will remain on the assigned MPDCCH narrowband, but the actual transport blocks (PDSCH and PUSCH) can be on any narrowband.
So why all of the complexity? Because it gives the scheduler a lot of flexibility in deciding where to put the MPDCCH, based on the kind of traffic that the network sees or what narrowbands are available at any given moment. This is critical for good LTE-M performance, since every LTE-M transmission, UL or DL, requires a DCI on the MPDCCH.