4G/LTE - Measurement Report

 

 

 

NOTE : At high level view, it would not be difficult to understand overall concept of CSI. However, getting deeper into the details.. it would become much complicated .. and tooooooooooooo confusing (at least very confusing to me). That is one of the reason why I wrote multiple pages for the same topic (CSI). Multiple pages for the same topic can be additional confusion to some readers (even to me). However, I thought the page would get too big for download if I put everything in single page and I also thought it would not be bad to provide a little bit different aspect for the same topic with multiple post. But as I add more pages (post), I thought it would be good to write a page to provide high level view and help readers combine all those multiple pages that I wrote. Refer to CSI Overview page if you are not familiar with big picture of the CSI report.

 

CQI

 

CQI stands for Channel Quality Indicator. As the name implies, it is an indicator carrying the information on how good/bad the communication channel quality is. This CQI is for HSDPA. (LTE also has CQI for its own purpose).

CQI is the information that UE sends to the network and practically it implies the following two

    i) Current Communication Channel Quality is this-and-that..

    ii) I (UE) wants to get the data with this-and-that transport block size, which in turn can be directly converted into throughput

Followings are the topics that I will talk about in this page.

What would happen if UE send inaccurate CQI ?

In HSDPA, the CQI value ranges from 0 ~ 30. 30 indicates the best channel quality and 0,1 indicates the poorest channel quality. Depending which value UE reports, network transmit data with different transport block size. If network gets high CQI value from UE, it transmit the data with larger transport block size and vice versa.

What if network sends a large transport block even though UE reports low CQI, it is highly probable that UE failed to decode it (cause CRC error on UE side) and UE send NACK to network and the network have to retransmit it which in turn cause waste of radio resources.

What if UE report high CQI even when the real channel quality is poor ? In this case, network would send a large transport block size according to the CQI value and it would become highly probable that UE failed to decode it (cause CRC error on UE side) and UE send NACK to network and the network have to retransmit it which in turn cause waste of radio resources.

The size of the penalty is worth putting a number on. Both tables above turn a CQI index into an efficiency, and that column is the scale the mistake is paid on.

  • The alphabet spans a factor of thirty six : efficiency runs from 0.1523 to 5.5547. Those are index 1 and index 15 of Table 7.2.3-1.
  • One index is worth roughly two decibels : the table in the section below covers fourteen steps in about 27 dB. That is for a single antenna UE.
  • Reporting low wastes capacity quietly : nothing fails, so nothing in a log points at it. The only symptom is throughput below what the radio could carry.
  • Reporting high fails loudly : the block is not decoded, a NACK goes back. The retransmission costs the air time the larger block was meant to save.
  • Accuracy is a property of the distribution : the histograms further down this page show a real UE spreading over about three indices. The signal to noise ratio was held fixed while it did.

How UE estimate CQI ?

How UE can measure CQI ? This is the most unclear topic to me. As far as I know, there is no explicit description in any standard on the mechanism by which the CQI is calculated, but it is pretty obvious that the following factors play important roles to CQI measurement.

  • signal-to-noise ratio (SNR)
  • signal-to-interference plus noise ratio (SINR)
  • signal-to-noise plus distortion ratio (SNDR)

It is not defined in the specification on how these factors are used and whether there is any other factors being involved. The implementation is all up to chipset makers. In most case, the chipset maker derives a complicated mathemtical formula called channel model and derive SNR/SINR/SNDR from the channel model. And then, they do a lot of testing to correlate the measured SNR and the measured BLER by the chipset and create some internal table (or equation) for the correlation. And the mapping table(function) would eventually used to determine CQI value.

One thing is worth separating out of that. The specification fixes what a CQI index means, and leaves open what produces it.

  • The output alphabet is fully specified : both tables above give a modulation, a code rate and an efficiency. Every one of the sixteen values gets all three.
  • The input mapping is not specified at all : nothing says which measurement, over which bandwidth, or with what averaging.
  • The table in the section below shows the consequence : five antenna and transmission mode combinations reach the same index. Their signal to noise ratios are nine decibels apart.
  • So an index is a statement about a receiver, not about a channel : two UEs in the same place can report differently. Both of them are right.
  • Retransmission barely matters : the two single antenna columns were measured at zero and at three retransmissions. They never differ by a decibel.

CQI Value and Expected PDSCH Modulation Scheme

In LTE, there are 15 different CQI values randing from 1 to 15 (4 bits) and mapping between CQI and modulcation scheme, transport block size is defined as follows (36.213)

 

< 36.213 Table 7.2.3-1 >

< 36.213 Table 7.2.3-2 >

36.213 Table 7.2.3-1, the 4-bit CQI table mapping each index to a modulation, a code rate and an efficiency

36.213 Table 7.2.3-2, the CQI table that adds 256QAM entries

The same alphabet twice. The table on the right adds four high end entries and drops entries at the bottom.

  • Index 0 is not a quality : both tables print out of range across the whole row. That says the channel carries nothing, not that it carries little.
  • The efficiency column is the ordering : it rises without a break from 0.1523 to 5.5547 on the left, and to 7.4063 on the right. The code rate column does not.
  • The code rate drops at every modulation change : 602 falls to 378 between index 6 and 7 on the left. Efficiency still rises from 1.1758 to 1.4766.
  • Efficiency is the code rate times the bits per symbol : 378 over 1024 times 4 is 1.4766. 948 over 1024 times 6 is 5.5547.
  • The right hand table thins out the bottom : QPSK keeps 78, 193 and 449. The left hand table has six QPSK rows.
  • The whole of the left hand table fits below index 12 on the right : 5.5547 is the top efficiency on the left. On the right it is the efficiency of index 12.
  • 256QAM occupies the four new rows : 711, 797, 885 and 948 over 1024, at 8 bits per symbol.

 

If you are an engineer in Network (eNodeB) programming, you need to know the number of resource blocks and MCS for each CQI value to properly allocate the resources for each of UEs. With the modulation scheme in the table, you would get a certain range of MCS you can use for each CQI index. But you cannot pinpoint a specific MCS and Number of RBs. You need another condition to get the proper MCS and N RBs and it is 'Code Rate' shown in the table. But still there is not a single formula that would give you a single/determined value for MCS and NRB. You have to come up with a set of MCS and N RB that meet the modulation scheme and Code Rate requirement in the table. One example case can be as follows.

 

CQI

Modulation

Bits/Symbol

REs/PRB

N_RB

MCS

TBS

Code Rate

1

QPSK

2

138

20

0

536

0.101449

2

QPSK

2

138

20

0

536

0.101449

3

QPSK

2

138

20

2

872

0.162319

4

QPSK

2

138

20

5

1736

0.318841

5

QPSK

2

138

20

7

2417

0.442210

6

QPSK

2

138

20

9

3112

0.568116

7

16QAM

4

138

20

12

4008

0.365217

8

16QAM

4

138

20

14

5160

0.469565

9

16QAM

4

138

20

16

6200

0.563768

10

64QAM

6

138

20

20

7992

0.484058

11

64QAM

6

138

20

23

9912

0.600000

12

64QAM

6

138

20

25

11448

0.692754

13

64QAM

6

138

20

27

12576

0.760870

14

64QAM

6

138

20

28

14688

0.888406

15

64QAM

6

138

20

28

14688

0.888406

One worked answer to the question above. The last column is computed, not quoted, and it does not reproduce the code rate column of Table 7.2.3-1.

  • Two columns are held still for every row : REs/PRB is 138 and N_RB is 20 from index 1 to index 15.
  • The formula in Note 3 reproduces the last column exactly : 536 plus 24, over 20 times 138 times 2, is 0.101449.
  • It holds at the other end too : 14688 plus 24, over 20 times 138 times 6, is 0.888406.
  • The mapping saturates at both ends : index 1 and index 2 both land on MCS 0. Index 14 and index 15 both land on MCS 28.
  • That saturation is the MCS range running out : 15 CQI indices are being fitted onto MCS 0 to 28. The ends have nowhere further to go.
  • This column is not the specification's code rate : index 1 gives 0.1014 here. Table 7.2.3-1 gives 78 over 1024, which is 0.0762.
  • The difference is the denominator : this column divides by the resource elements the author assumed. The table above divides by a reference the specification fixes.

Note 1 : Refer to Throughtput Calculation Example for determining N_RB, MCS, TBS determination.

Note 2 : REs/PRB varies depending on CFI value as follows.

 

CFI

REs/PRB

1

150

2

138

3

126

Three values, and the gap between them is the same each time. That gap is one OFDM symbol.

  • Each extra control symbol costs exactly 12 resource elements : 150, 138 and 126 for CFI 1, 2 and 3. That is one subcarrier column per symbol.
  • 138 is the value the table above uses : the worked rows assume CFI 2 throughout.
  • Changing CFI moves the code rate without touching the CQI : take the same transport block over 126 elements instead of 150. The code rate comes out about 19 percent higher.

Note 3 : I used the following formula explained in Code Rate section.

v_CodingRate := (int2float(p_TBSize + 24)) / (int2float(p_N_PRB * tsc_REs_Per_PRB * v_BitsPerSymbol));

CQI vs SNR

As mentioned earlier, the main criteria for UE to determined CQI value is SNR, but the exact mapping between the measured SNR and CQI may vary a little depending on each modem manufacturer, but overall correlation between CQI and SNR would be similar. Every modem manufacturer would keep their own mapping table in their physical layer protocol stack but in most case the venders would not open those tables in public. Fortunally, I found a data from Ref [3] as follows. This example would give you a concrete insight about CQI determination.

 

SNR plotted against CQI index for five transmission mode and antenna combinations, all rising roughly linearly

Five configurations, five different answers to the same question. The table below gives the numbers the traces are drawn from.

Following is the description of each of the traces shown in the graph.

  • 111 Tx Mode 0 re-tx:TM1, Number of Tx Antenna = 1, Number of Rx Antenna = 1, HARQ  Max retransmission = 0
  • 111 Tx Mode 3 re-tx:TM1, Number of Tx Antenna = 1, Number of Rx Antenna = 1, HARQ  Max retransmission = 3
  • 222 Tx Mode:TM2, Number of Tx Antenna = 2, Number of Rx Antenna = 2
  • 322 Tx ModeTM3, Number of Tx Antenna = 2, Number of Rx Antenna = 2
  • 342 Tx Mode:TM3, Number of Tx Antenna = 4, Number of Rx Antenna = 2

 

Following is the same data as shown in the above graph, but summarized in tabular format.

 

The same SNR against CQI data in a table, one column per transmission mode and antenna combination

Read a row rather than a column. The spread across one row is the whole reason a CQI index cannot be turned back into an SNR.

  • Every column rises with the index : none of the five ever goes backwards from one CQI value to the next.
  • One index spans nine decibels across the five columns : index 1 runs from -7.00 to 2.00. Those are the 222 column and the 111 3 re-tx column.
  • The spread is still there at the top : index 15 runs from 20.00 to 29.60.
  • The 222 column is the outlier at the top end : it reaches index 15 at 20.00 dB. The other four need about 29.
  • Retransmissions barely move the mapping : the 111 0 re-tx and 111 3 re-tx columns never differ by as much as one decibel.
  • The single antenna columns need the most signal at the bottom : index 1 costs about 2 dB with one antenna. Two or four antennas reach it below zero.
  • A step of one index is worth roughly two decibels : the 111 columns cover 14 steps in about 27 dB.

Which Physical Channel Carriers CQI Value ?

Two channels can carry a CQI report, and which one does is decided per subframe rather than per configuration. The log further down this page catches all three cases in three consecutive rows. It is worth re-reading once the rules below are clear.

CQI is carried by PUCCH or PUSCH depending on the situation as follows.

  • Carried by PUCCH : Periodic CQI
  • Carried by PUSCH : Aperiodic CQI (and Periodic CQI)

 

Regarding CQI report period and configuration, refer to CQI, PMI, RI Reporting Configuration part.

The split is not quite as clean as those two lines make it look. Periodic reporting has a second channel and a third outcome.

  • Periodic reporting moves to PUSCH when a grant collides : the report is not dropped. It travels in the uplink transmission that was already scheduled.
  • A positive scheduling request wins outright : the clause quoted in the SR section below drops the CSI rather than moving it.
  • DRX can suppress it entirely : the clause quoted in the DRX section below stops the report. That applies while the UE is outside its active time.
  • The log shows two PUCCH formats, not one : format 2 carries a CQI alone. Format 2A carries a CQI with an acknowledgement.
  • Aperiodic reporting has no such branching : it is requested in a grant. So the PUSCH it travels on is allocated by the same message that asked for it.

Two Important CQI Table

We have two different tables as shown below defined in 36.213. Now the question is in which situation the first table (Table 7.2.3-1) is used and in which situation the second table(Table 7.2-2) is used). Overall story is described in 36.213 section 7.2, I will just re-organize those statements in a little bit different structure.

 

36.213 Table 7.2.3-1 with its printed title, the 4-bit CQI table

 

The table shown above is used in following situation. In this table, 4 bit is used to indicate each CQI value.

    1) For transmission modes 1, 2, 3 and 5, as well as transmission modes 8, 9 and 10 without PMI/RI reporting, transmission mode 4 with RI=1, and transmission modes 8, 9 and 10 with PMI/RI reporting and RI=1

    2) For RI > 1 with transmission mode 4, as well as transmission modes 8, 9 and 10 with PMI/RI reporting, PUSCH based triggered reporting. In this case, one out of the 4 bit CQI (16 different value) is reported for each Codeword (CW0 and CW1).

 

Following is another table that is used for CQI report, but this is not the absolute value. It is a different value for two different CQI value. Then.. how this difference is defined ? It is defined as follows :

    Codeword 1 offset level = wideband CQI index for codeword 0 – wideband CQI index for codeword 1.

36.213 Table 7.2-2, mapping a three bit spatial differential CQI value to an offset level

Three bits, and only the first three rows read the way you expect. The other five carry the negative half.

  • Values 0, 1 and 2 map straight through : offset 0, 1 and 2.
  • Value 3 saturates upward : the offset column prints greater than or equal to 3 rather than a single number.
  • Value 4 saturates downward : less than or equal to -4, which is the other end of the same field.
  • Values 5, 6 and 7 are the small negatives : -3, -2 and -1, in that order.
  • The order is two's complement, not a ramp : 4 to 7 hold -4 to -1. That is why the column is not monotonic when read downward.
  • A positive offset means codeword 0 is the better one : the definition above this table does the subtraction. It takes the codeword 1 index away from the codeword 0 index.
  • Three bits is all a second codeword costs : the absolute index is sent once. The second one is sent as a difference.

 

This table is used in following case :

    1) For RI > 1 with transmission mode 4, as well as transmission modes 8, 9 and 10 with PMI/RI reporting, PUCCH based reporting includes reporting a 4-bit wideband CQI for codeword 0 according to Table 7.2.3-1 and a wideband spatial differential CQI

CQI Report and DRX

When you configure/enable CQI report, you need to take into consideration of other type of periodic acitivties that might be happening in UE. The most typicial type of periodic activities you have to consider is DRX(C-DRX : Connected Mode DRX).

There are a couple of points in 3GPP specification that you may refer to are as follows :

36.321 V11.5.0-5.7 Discontinuous Reception (DRX) states as follows :

if CQI masking (cqi-Mask) is setup by upper layers:

    in current subframe n, if onDurationTimer would not be running considering grants/assignments/DRX Command MAC control elements received until and including subframe n-5 when evaluating all DRX Active Time conditions as specified in this subclause, CQI/PMI/RI/PTI on PUCCH shall not be reported.

- else:

    in current subframe n, if the UE would not be in Active Time considering grants/assignments/DRX Command MAC control elements received and Scheduling Request sent until and including subframe n-5 when evaluating all DRX Active Time conditions as specified in this subclause, CQI/PMI/RI/PTI on PUCCH shall not be reported.

 

Simply put, this means 'If CDRX is eanbled and UE is in sleeping mode due to CDRX acitivity, UE shall not send CSI(CQI /PMI /RI).

The two branches of that quotation are worth reading against each other. They differ in one word, and that word is the whole of cqi-Mask.

  • Both branches look back the same distance : each evaluates the condition as of subframe n-5.
  • Without cqi-Mask the test is Active Time : the report is allowed whenever the UE is awake for any reason. A grant or a scheduling request it sent both count.
  • With cqi-Mask the test is onDurationTimer alone : the report is allowed only during the scheduled wake window. Activity that extended it does not count.
  • So cqi-Mask narrows the window rather than closing it : reports are still sent on the on duration, and stop for everything else.
  • The trade is power against freshness : fewer reports save the UE transmissions and leave the scheduler working from older information.

CQI Report and SR

Since CQI (especially periodic CQI) is carried by PUCCH, you need to consider another information that is carried by PUCCH. One important case you need to take into account is SR (Scheduling Request).

36.213 V12.7.0 - 7.2.2 Periodic CSI Reporting using PUCCH states as follows :

If the UE is not configured for simultaneous PUSCH and PUCCH transmission or, if the UE is configured for simultaneous PUSCH and PUCCH transmission and not transmitting PUSCH, in case of collision between CSI and positive SR in a same subframe, CSI is dropped.

It means .. if there is a case where UE needs to send both SR and CQI, SR transmission has higher priority and CQI gets dropped.

That clause has two arms, and both end the same way. The case it does not cover is the more useful one.

  • The first arm is a UE with no simultaneous transmission configured : PUCCH can carry one thing. The two requests therefore compete for it.
  • The second arm is a UE that has it configured but is not using it : no PUSCH is in flight. The same competition applies.
  • Both arms drop the CSI : the scheduling request survives. A request for resources is worth more than a description of the channel.
  • The case left out is the interesting one : take a UE configured for simultaneous transmission and already sending PUSCH. It has somewhere else to put the report.
  • That is the second row of the table two sections above : periodic CQI carried by PUSCH rather than by PUCCH.

How Network trigger UE to send CSI ?

I hope you got the general picture of CQI by now. Now a question that comes to your mind would be how the network trigger UE to send CQI (in other words, when UE is supposed to send CSI. CQI is a kind of CSI. So I would explain on triggering CSI here).

There are roughly two types of CQI triggering mechanism (i.e, Periodic and Aperiodic) and the detailed procedure are a little bit different between these two types.

  • Periodic Report : In this mode, UE is supposed to send CQI report periodically with a specified interval. The interval and specific subframe a UE is supposed to send the report is specified in RRC message. (Refer to CQI, PMI, RI Reporting Configuation-Details on Periodic Report for the details).
  • Aperiodic Report : In this mode, UE is supposed to send CSI report only when it gets a specific trigger from the network. What do you mean by 'specific trigger' ?  It means 'CSI Request field in DCI 0'. It means the direct trigger for Aperiodic CSI is DCI 0(UL Grant). However, this direct trigger is not enough for the UE. UE has to know what kind of CSI it should report (e.g, CQI only ? CQI and PMI ? CQI and PMI and RI ?). what about the case of carrier aggregation ? Do I (UE) have to report for PCC ? or SCC? or both PCC and SCC ? All of these detailed informations is configured by RRC message(Refer to CQI, PMI, RI Reporting Configuation-Details on Aperiodic Report and CQI/RI Feedback type for the details)

How to test CQI ?

How can we test CQI report functionality ? There are roughly two different types of test method. (The word 'type' is my personal expression.. it is not 3GPP term. Don't try to look for 'CQI test Type 1' or 'Type 2' in 3GPP document :)

 

Type 1 : Live Network Behavior Test

The first type may not be an accurate test for UE's CQI report functionality, but it is closer to live network behavior. Overall sequence of CQI report and eNB reaction to the report is as follows :

  • i) UE sends a CQI report with a certain value (e.g, 15)
  • ii) eNB sends PDSCH with the highest MCS (i.e, the highest code rate and the largest transport block)
  • iii) If UE can successfully decode it (meaning BLER lower than a certain limit), it sends the same or higher CQI.
  •      If UE fail to decode it(meaning BLER higher than a certain limit), it sends the CQI less than the previous one

  • iv) eNB sends PDSCH with the lower MCS(i.e, the lower code rate and the smaller transport block)
  • v) go to step iii)

With this procedure, eNB can transmit PDSCH with the code rate (MCS) that can be successfully decoded by UE (i.e, causing no CRC/no BLER).

 

Following is one example of CQI report and throughput change based on Radio Channel Quality between a UE and LTE Network Simulator from Amarisoft. It configures CQI configuration as follows by default. (If you are not familiar with the meaning of these parameters, refer to CQI Report Configuration page)

    cqi-ReportConfig as it was set on the author's LTE simulator for the run below, quoted as captured. It records one configuration rather than specification text, so none of its values have been corrected.

    cqi-ReportConfig {
      nomPDSCH-RS-EPRE-Offset 0,
      cqi-ReportPeriodic setup: {
        cqi-PUCCH-ResourceIndex 0,
        cqi-pmi-ConfigIndex 38,
        cqi-FormatIndicatorPeriodic widebandCQI: NULL,
        simultaneousAckNackAndCQI FALSE
      }
    },
    • Two fields of the structure are absent : cqi-ReportModeAperiodic and ri-ConfigIndex do not appear, and 36.331 marks both of them optional.
    • So this configuration is periodic and CQI only : nothing here asks for an aperiodic report or for a rank indication.
    • cqi-pmi-ConfigIndex is 38 : the conformance default further down this page sets the same field to 6.
    • simultaneousAckNackAndCQI is FALSE : a report and an acknowledgement will not share a subframe under this setting.

First I get UE camped on the LTE Simulator with a good radio channel and start downloading YouTube from the UE. While UE is downloading YouTube video, I changed cell power (Downlink Power) step by step. The upper plot is cell power change and the average CQI (Average of 50 subframes) in reaction to the cell power change and lower plot shows the throughput change in accordance to CQI changes. This throughput change is because eNB assigns different MCS in response to CQI report. Amarisoft WebInterface Logging/Analysis tool allow us to get this kind of graph with a couple of button click.

 

CQI and throughput against time over about 100 seconds, with six annotated changes of downlink power

One large fall and five small rises, all of them made by hand at the simulator. The lower pane is what the UE got for it.

  • Six changes are annotated and only one goes down : step 1 lowers the downlink power in a large step. Steps 2 to 6 raise it in small ones.
  • CQI answers each change as a plateau, not a spike : the trace settles on a new level. It stays there until the next change.
  • A plateau is a band rather than a line : the reported value keeps moving over two or three indices. The power is held still throughout.
  • Throughput follows the same staircase : about 16 Mbps at the start, then near zero after the large fall. A sustained band returns as CQI climbs back.
  • The window is about 100 seconds : the axis runs from 16:19:20 to about 16:21:00.
  • Nothing in the UE was changed : the only variable is the power the simulator transmits. That is what makes this a clean demonstration.

 

CQI report is carried by different channels (PUCCH or PUSCH) and in different format (e.g, PUCCH format 2 or 2A etc) depending on situation. Amarisoft logging captures all the PUCCH and PUSCH information as shown below.

Three log rows showing a CQI value carried on PUCCH format 2, on PUCCH format 2A and on PUSCH

Three rows, three different carriers, one field. The value is printed in binary, which is the clearest reminder that CQI is four bits.

  • The first row is PUCCH format 2 : cqi=1111 and nothing else, which is 15 in the table above.
  • The second row is PUCCH format 2A : cqi=0101 with ack=1 beside it, so the report and an acknowledgement share the transmission.
  • The third row is PUSCH : the same cqi=0101 arrives inside a full uplink transmission record.
  • All three rows carry the same RNTI : 0x61, so this is one UE reporting three different ways.
  • The PUSCH row carries its own measurements : tb_len, mod, rv_idx, crc and an snr figure. All of those describe the uplink being decoded, not the downlink being reported on.
  • Four binary digits is the whole payload : 1111 and 0101 are indices 15 and 5 of the 4-bit table.

 

Type 2 : RF Conformance Test : CQI Measurement Accuracy Test

Another type of CQI testing can be more accurate test for UE's CQI report capability (but you wouldn't see this kind of behavior in live network). Briefly speaking the overall procedure is as follows.

 

  • i) eNB sends a PDSCH with the condition for a certain CQI (e.g, CQI 8)
  • ii) UE sends a CQI report with a certain value (e.g, CQI 6)
  • iii) (if it is live network, eNB would send PDSCH with MCS corresponding to CQI 6, but) eNB sends PDSCH with the same CQI (same MCS) regardless of the CQI value from UE.
  • iv) Repeat this process many times (e.g, 2000 times) and calculate statistical distribution plot (e.g, histogram) using the CQI values from UE.

More accurately, you may refer to the test procedure described in 3GPP 36.521. Chapter 9 of 36.521-1 is all about CQI report test. There are many test cases in the chapter but test procedure are similar for all the test cases. They do the similar procedure with various different channel condition.  A most typical procedure is described as below.

 

36.521-1 9.2.1.1.4.2 Test procedure

The SS shall transmit PDSCH via PDCCH DCI format 1A for C_RNTI to transmit the DL RMC according to CQI value 8 and keep it regardless of the wideband CQI value sent by the UE. The SS sends downlink MAC padding bits on the DL RMC. Continue transmission of the PDSCH until 2000 wideband CQI reports have been gathered. In this process the SS collects wideband CQI reports every 5 ms and also cases where UE transmits nothing in its CQI timing are also counted as wideband CQI reports.

 

< 36.521-1 Table 9.2.1.1.4.3-1: PhysicalConfigDedicated-DEFAULT >

36.521-1 Table 9.2.1.1.4.3-1, the PhysicalConfigDedicated default for the CQI measurement accuracy test

This default overrides a single field. The table below says what it is set to.

 

< 36.521-1 Table 9.2.1.1.4.3-2: CQI-ReportConfig-DEFAULT >

36.521-1 Table 9.2.1.1.4.3-2, the CQI-ReportConfig default with its field values for the CQI measurement accuracy test

The same structure as the capture further up this page, filled in by the test specification instead of by a simulator.

  • The aperiodic half is switched off : cqi-ReportModeAperiodic reads Not present, so this test measures periodic reporting only.
  • RI reporting is off as well : ri-ConfigIndex reads NULL, which leaves CQI as the only thing being reported.
  • Two comments give the tables that decode the indices : Table 7.2.2-1A in 36.213 for cqi-pmi-ConfigIndex and Table 7.2.2-1B for ri-ConfigIndex.
  • cqi-pmi-ConfigIndex is 6 here : the capture further up this page uses 38 for the same field. So the two arrangements report at different rates.
  • The format is wideband : cqi-FormatIndicatorPeriodic selects widebandCQI, so one number covers the whole carrier.
  • The derivation path names where the rest comes from : 36.508 clause 4.6.3 holds the default that these values override.

 

Main purpose of this test is to check the accuracy of UE's CQI report (i.e, to check how accurantely UE estimate the radio channel condition and send the corresponding CQI report). Following is an example of test results shown in Reference 2.

 

Two CQI distribution histograms over 2000 samples, at 10 dB and at 16 dB signal to noise ratio

A UE does not report a number. It reports a distribution, and the test is whether that distribution sits where it should.

  • Each histogram is 2000 samples : the caption says so, and it matches the repeat count in the procedure above.
  • Neither distribution is a single bar : each spreads over about three adjacent indices even with the signal to noise ratio held fixed.
  • The left case is 10 dB and centres on index 10 : the tallest bar reaches about 0.38 of the samples.
  • The right case is 16 dB and centres on index 14 : the tallest bar reaches about 0.43.
  • Six decibels moved the centre by four indices : that is about 1.5 dB per index in this data.
  • The pass condition is about the centre, not the spread : the caption names the answer. The base station should use index 10 and index 14 respectively.

CQI Measurement in Livenetwork

The final goal of designing the concept of CQI and implementing it in such a complicated (confusing way) is to achieve the least amount of error and the best possible rate of throughput. There are many factors influencing the throughput and each of the factors would have some kind of correlations with other factors. In Lab test, it is relatively easy to figure out those correlations since you can control those factors (parameters) as fitting the best for analysis, but in live network it is not always that easy to figure out those correlations because most of those factors (parameters) changes dynamically. So the livenetwork test result would not be easily explainable but I think it always good to have some level of experience with livenetwork test result.

General rule of thumb for the correlation between CQI and throughput can be summarized as follows.

  • i) High throughput does not necessarily mean high CQI. (High throughput depends not only on CQI, but also on transport block size (Number of RB and MCS. Even when CQI is high, eNB may assign small resources due to various other factors)
  • ii) Low throughput does not necessarily mean low CQI. (The reason is same as above)
  • iii) With low CQI, it is for sure that you cannot achieve the maximum throughput. So, it is very likely that you would see low CQI when you see throughput drop in livenetwork test.

 

Example 1 : Throughput, CQI, BLER while driving on a highway

Following plot is from the data captured by a drive test tool Azenqos Drive Test tool (AZQ Android). I got the log captured by the tool and exported the data as csv file and then plot it on Microsoft Excel. As mentioned above, you would not get always high throughput whever you have high CQI, but it is very likely to see low CQI when you see throughput dips (drops) as marked in shaded box.

One thing I notice from this specific example is that BLER is a little bit higher than I expected. As mentioned above, one of the main goal of CQI design/implementation is to minimize the BLER, but I think the BLER in this log seems to be a little bit too high. If this result is only for a specific UE, it might be the UE issue. However, this kind of result is observed for most of the UE tested in that area, it would be good to optimize the network parameters for that area.

 

Throughput, CQI and BLER against time from a drive test, with seven shaded bands marking CQI dips

Three traces and seven marked moments. The one that does not move is the interesting one.

  • The shaded bands are labelled A to G : each marks a moment where the CQI trace dips.
  • Throughput dips with CQI at every band : the widest band sits near 39:45. It takes CQI down to about 6 and throughput down with it.
  • BLER does not dip and does not spike : it stays scattered around the same band through every one of the seven.
  • A flat BLER is the loop working : the network answers a worse channel by sending less. So the error rate stays where it was and the throughput absorbs the change.
  • The level it holds is the point the author raises : the BLER sits around 10 percent. The note beside this plot calls that higher than expected.
  • CQI mostly runs between 8 and 14 : the dips reach 4 to 6. The trace never approaches the top of its own axis.

 

Example 2 : CQI vs MCS

Following plot is from the data captured by a drive test tool Azenqos Drive Test tool (AZQ Android). I got the log captured by the tool and exported the data as csv file and then plot it on Microsoft Excel.

Even in live network measurement, you may see pretty obvious correlation between CQI and MCS. This should be relatively obvious because network changes MCS dynamically based on CQI to minimize the MCS.

 

CQI and MCS index against time from a drive test, the two traces following the same shape

Two traces of the same drive. The shapes match closely enough that one could be used to predict the other.

  • The two axes have different ranges on purpose : CQI runs 0 to 16 and MCS runs 0 to 30. One field is four bits and the other is five.
  • The shapes track each other : the CQI dip near 36:00 and the rise after 40:19 both appear in the MCS trace.
  • MCS is noisier than CQI : it swings across its whole range within a few seconds, where CQI moves more slowly.
  • That noise is the scheduler, not the channel : MCS is also chosen by how much data is queued. CQI knows nothing about that.

 

The correlation between CQI and MCS would be more obvious if you plot the data in a scatter plot as shown below. Even though the data points are scattered around you may say it is relatively well aligned along a straight line (the green line). Of course it would be better to have those points spread less.

Scatter plot of MCS against CQI from a drive test, with a trend line drawn through it

The trend is real and the scatter is large. Both halves of that sentence matter when reading a live log.

  • The trend line rises about two MCS steps per CQI step : it starts near MCS 0 at CQI 3. It reaches about MCS 27 at CQI 15.
  • It meets zero at about CQI 3 : below that the lowest MCS is all there is to choose.
  • The slope comes from dividing one range into the other : 28 MCS values spread over about 12 usable CQI indices.
  • The scatter is wider than the trend : at CQI 10 the points run from about MCS 5 to about MCS 27.
  • The dots fall in horizontal rows : MCS is an integer, so every sample lands on one of 29 lines.
  • One CQI value never predicts one MCS : the trend holds across a drive and says little about any single subframe.

Reference

[1] LTE Channel State Information (CSI) - Keysight

[2] R&S®TS8980 test system analyzes LTE quality indicators: CQI, PMI and RI

[3] Downlink SNR to CQI Mapping for Different Multiple Antenna Techniques in LTE by Mohammad T. Kawser et al.