4G/LTE - MCS

 

 

 

MCS for Retransmission

 

A retransmission carries the same transport block as the first transmission, so the scheduler does not need to signal its size again. LTE uses that freedom in the MCS field. The top three MCS indices, 29 to 31, carry no transport block size, and they signal something else instead. On the downlink that is the modulation order, and on the uplink it is the redundancy version.

Followings are the topics to be covered in this page.

MCS for Retransmitted PDSCH

How does the eNB schedule a PDSCH retransmission without repeating the transport block size? The downlink DCI carries a separate 2-bit redundancy version field, so the MCS field is free to signal only what may change, which is the modulation order.

For retransmitted PDSCH (according to 36.213 Table 7.1.7.1-1),  MCS  is determined only by Qm and is not affected by RV.

  • When Qm for the first transmission is 2, Retransmitted MCS become 29
  • When Qm for the first transmission is 4, Retransmitted MCS become 30
  • When Qm for the first transmission is 6, Retransmitted MCS become 31

The table below is 36.213 Table 7.1.7.1-1. The green rows at the bottom are the three indices used for retransmission, and they have no TBS index.

36.213 Table 7.1.7.1-1 Modulation and TBS index table for PDSCH, MCS 29 to 31 reserved

36.213 Table 7.1.7.1-1. IMCS 29, 30 and 31 give only the modulation order Qm of 2, 4 and 6, and the TBS index is reserved.

With IMCS 29 to 31, the UE takes the transport block size from an earlier DCI (36.213 v19.4.0 clause 7.1.7). That is the latest PDCCH or EPDCCH for the same transport block with IMCS 0 to 28. The eNB can therefore change the modulation order of a retransmission, for example after a change in the channel, while the size stays fixed. The redundancy version comes from the 2-bit Redundancy version field of DCI formats such as 1A (36.212 v19.3.0 clause 5.3.3.1.3), so any RV can go with any of the three indices.

The three reserved rows move when the UE uses another MCS table. With the 256QAM table, 36.213 Table 7.1.7.1-1A, the reserved indices are 28 to 31, and they give Qm of 2, 4, 6 and 8. So a retransmission of a 256QAM transport block in 256QAM uses IMCS 31 there, not 29 to 31 as in the table above.

  • IMCS 29 to 31 on PDSCH : modulation order 2, 4 and 6, no TBS index.
  • Size from the earlier DCI : the latest DCI of the same transport block with IMCS 0 to 28.
  • RV in its own 2-bit field : independent of the MCS index.
  • 256QAM table 7.1.7.1-1A : reserved indices 28 to 31, with 31 for Qm 8.

MCS for Retransmitted PUSCH

The uplink grant has no separate RV field. DCI format 0 carries a single 5-bit field for both, Modulation and coding scheme and redundancy version (36.212 v19.3.0 clause 5.3.3.1.1). So the three reserved indices must carry the RV instead of the modulation order.

For retransmitted PUSCH (according to 36.213 Table 8.6.1-1),  MCS  is determined only by RV and is not affected by Qm.

  • When RV = 1, Retransmitted MCS become 29
  • When RV = 2, Retransmitted MCS become 30
  • When RV = 3, Retransmitted MCS become 31

The table below is 36.213 Table 8.6.1-1. Its extra column gives the redundancy version, and the green rows at the bottom give the RV of an adaptive retransmission.

36.213 Table 8.6.1-1 Modulation, TBS index and redundancy version table for PUSCH, MCS 29 to 31 reserved

36.213 Table 8.6.1-1. IMCS 0 to 28 always mean RV 0, and IMCS 29, 30 and 31 mean RV 1, 2 and 3 with the modulation order and the TBS reserved.

So a UE cannot receive a new transmission with any RV other than 0 through DCI 0. For IMCS 29 to 31, the modulation order and the transport block size come from an earlier DCI (36.213 v19.4.0 clause 8.6). That is the latest DCI for the same transport block with IMCS 0 to 28. The 256QAM uplink table, Table 8.6.1-3, keeps the same three rows: IMCS 29, 30 and 31 still mean RV 1, 2 and 3.

This table applies only to an adaptive retransmission, which the eNB schedules with a new DCI 0. A non-adaptive retransmission has no DCI at all. The UE receives a NACK on the PHICH and retransmits on the same resource. Its MAC takes the next RV from the sequence 0, 2, 3, 1 (36.321 v19.3.0 clause 5.4.2.2). An adaptive retransmission with an explicit RV resets the position in that sequence, and the next non-adaptive retransmission continues from there. The example below shows both kinds.

  • IMCS 29 to 31 on PUSCH : RV 1, 2 and 3, with the modulation and TBS reserved.
  • One 5-bit field in DCI 0 : MCS and RV share it, so the RV takes the reserved indices.
  • Non-adaptive retransmission : no DCI, RV sequence 0, 2, 3, 1 from 36.321.
  • 256QAM table 8.6.1-3 : the same RV rows 29 to 31.

PUSCH Retransmission Example

The tables above describe single grants, and a live log shows how they combine. In this log, one uplink transport block needs four transmissions, and the eNB uses both non-adaptive and adaptive retransmissions before the CRC passes.

Now let's look at a real life example, which might look more complicated and confusing but hopefully look more interesting :). This shows an example of what's happening during the initial process (RACH process) after you turn on your mobile phone.

Again, the log and background RB map is from Amarisoft LTE Network simulator. All the labels were put manually (If you roll over the mouse pointer onto each channel it shows some detailed information, but it would not show information on the exact contents. This is understandable.. because Physical channel by itself does not have any detailed knowledge on the contents).

In this example, you can see almost every cases that might happen in the real communication. You may ses SR and DCI 0 in response to SR and PUSCH retransmission due to CRC failure.

The map below shows the downlink channels in the upper half and the uplink channels in the lower half, over system frames 509 to 515. The labels mark the RACH procedure on the left and the PUSCH retransmissions in frames 512 to 515.

Amarisoft RB map of RACH procedure and PUSCH retransmissions with labelled PDCCH, PHICH, PDSCH, PUCCH and PUSCH

RB map from the Amarisoft log. The three red PHICH arrows mark subframes 513.2, 514.0 and 514.8, although the log shows an ACK at 514.0, sent together with a new DCI 0.

How can I figure out all the details printed on each labels shown above ? It came from the text based log as shown below. (The current log viewer does not show the MCS value for PUSCH, it show RV index as marked below)

It took me almost an hour to pul all the lables shown above based on the log below. However, this can be a good practice if you are at learning phase of LTE protocol.. or you HAVE TO go through this tedious process when you are in troubleshooting situation.

Amarisoft PHY and MAC log of the RACH procedure and PUSCH retransmissions with rv_idx marked

Continuation of the Amarisoft log with the last PUSCH retransmission passing CRC

Amarisoft log. The rv_idx of the PUSCH goes 0, 2, 3 and 1, and the fourth transmission passes CRC.

The log gives each event as system frame and subframe, so 512.8 is subframe 8 of SFN 512. The table below lists the events of HARQ process 0 from the log, with the kind of each transmission.

 

SFN.subframe

Channel

Log

Meaning

512.0

PUCCH

format=1 sr=1

Scheduling request

512.4

PDCCH

dci=0

UL grant for a new transmission

512.8

PUSCH

rb_start=2 rv_idx=0 crc=KO

First transmission

513.2

PHICH

hi=0

NACK

513.6

PUSCH

rb_start=2 rv_idx=2 crc=KO

Non-adaptive retransmission 1

514.0

PHICH and PDCCH

hi=1 and dci=0

ACK with a new grant

514.4

PUSCH

rb_start=8 rv_idx=3 crc=KO

Adaptive retransmission 2

514.8

PHICH

hi=0

NACK

515.2

PUSCH

rb_start=8 rv_idx=1 crc=OK

Non-adaptive retransmission 3

515.6

PHICH

hi=1

ACK

 

Every step keeps the FDD timing of synchronous uplink HARQ. The PHICH comes 4 subframes after the PUSCH, and the next transmission 4 subframes after the PHICH or the DCI 0. So the transmissions follow each other every 8 subframes: 512.8, 513.6, 514.4 and 515.2.

The first retransmission at 513.6 is non-adaptive. There is no DCI, the PUSCH stays on RB 2, and the RV moves from 0 to 2 along the sequence 0, 2, 3, 1. At 514.0 the eNB switches to an adaptive retransmission, and the log gives the reason as avoiding a collision. The new DCI 0 moves the PUSCH to RB 8 and sets RV 3, which in Table 8.6.1-1 means IMCS 31. The log still shows mod=4, because the modulation order comes from the first grant.

The PHICH at 514.0 carries an ACK, although the transport block has failed. The UE follows the DCI 0 whenever it receives one, so the ACK matters only if the UE misses the grant. In that case the ACK stops a non-adaptive retransmission on RB 2, and the data stays in the HARQ buffer (36.321 clause 5.4.2.2, NOTE 1). The label in the RB map above calls this PHICH a NACK, which the log does not support.

The last retransmission at 515.2 is non-adaptive again. The adaptive grant set the position in the RV sequence to RV 3, so the next RV is 1, as the log shows. The CRC passes, and the MAC PDU carries the PHR and SBSR that the map labels at 515.2.

  • PUSCH every 8 subframes : PHICH at n+4, retransmission at n+8.
  • RV 0, 2, 3, 1 : two non-adaptive steps and one adaptive step with RV 3, or IMCS 31.
  • ACK with a new DCI 0 : the grant decides, and the ACK only protects against a missed grant.
  • Modulation kept : mod=4 in every retransmission, from the first grant.

Reference

[1] 3GPP TS 36.213 v19.4.0 - Tables 7.1.7.1-1, 7.1.7.1-1A, 8.6.1-1 and 8.6.1-3, and clauses 7.1.7 and 8.6

[2] 3GPP TS 36.212 v19.3.0 - clause 5.3.3.1.1, DCI format 0, and clause 5.3.3.1.3, DCI format 1A

[3] 3GPP TS 36.321 v19.3.0 - clause 5.4.2.2, HARQ process