This page shows the TFRI table of an HSDPA test setup on a 1.28 Mcps TDD cell, the TDD option that TD-SCDMA networks use. Each row ties one transport block size to a modulation, a number of codes and a set of timeslots. In every 5 ms TTI the Node B picks one row and signals its fields to the UE on the HS-SCCH. The table also gives the peak throughput that each row would deliver. The values on this page are checked against 25.321 v19.0.0, 25.222 v19.0.0 and 25.224 v19.0.0.

The topics on this page are listed below.

• What does the TFRI table configuration set?
• How are the two throughput columns calculated?
• How does each TFRI row map to the HS-SCCH fields?
• How close does each TFRI row come to the physical limit?
• Reference

What does the TFRI table configuration set?

Five settings apply to the whole table, and every row inherits them. They fix the MAC-d PDU size, the reordering queue and the MAC-hs header. So read them first, because the NumOfPDU and TP(PDU) columns of the large table depend on them. The table below lists them as the test setup shows them.

Most of these names are labels of the test setup, not 3GPP IE names. Each one still maps to a 3GPP parameter, and that mapping explains the numbers further down.

• MACHsWindowSize = 16 is the reordering window : it is the MAC-hs receiver window size of the reordering queue. RRC signals it in the IE "MAC-hs window size", whose Rel-5 values are 4, 6, 8, 12, 16, 24 and 32 in 25.331. The 6-bit TSN counts from 0 to 63, so a window of 16 covers a quarter of the TSN range.
• QueueID = 0 is the Queue ID field : the MAC-hs header carries it in 3 bits. All data in this test goes through this one reordering queue.
• HeaderFlag = WITH_HEADER keeps the MAC-hs header : in 25.321 every MAC-hs PDU starts with a MAC-hs header, so this is the 3GPP behaviour. The flag itself is a setting of the test setup and has no 3GPP IE. The header costs 21 bits in each transport block, as the next section shows.
• PDUSize[0] = 336 is the MAC-d PDU size : it is the size configured for SID 0 in this queue. When MAC-d adds no header, a 336-bit MAC-d PDU is one 42-octet RLC AM PDU. That is 40 octets of data and a 2-octet AM header.
• NumOfTFRI = 97 is the row count : the large table has the rows TFRI 0 to TFRI 96. Rows 0 to 41 use QPSK and rows 42 to 96 use 16QAM.

How are the two throughput columns calculated?

The large table carries two throughput columns, and they answer different questions. TP(TBS) is the rate of the whole transport block. TP(PDU) is the rate of the MAC-d PDUs inside that block, which is what RLC actually receives. Both assume a new transport block in every 5 ms sub-frame. The two formulas are below.

TP(PDU) : Throughput based on Number of PDU

             = PDUSize[0] x NumOfPDU x (1000 ms/5ms/subframe)

             = PDUSize[0] x NumOfPDU x 200

TP(TBS) : Throughput based on Number of TBS

             = TBS x (1000 ms/5ms/subframe)

             = TBS x 200, where TBS here is for 1.28 Mcps

The factor 200 comes from the 1.28 Mcps TDD frame structure. A 10 ms radio frame holds two 5 ms sub-frames, and one HS-DSCH TTI is one sub-frame. So there are 1000 / 5 = 200 TTIs per second, and each formula multiplies the bits of one TTI by 200. For example, TFRI 41 carries a 3541-bit transport block, so TP(TBS) = 3541 x 200 = 708,200 bit/s.

The NumOfPDU column links the two formulas. A MAC-hs PDU is one MAC-hs header followed by N MAC-d PDUs of the same size, and any bits left over are padding. With one SID in the header, 25.321 subclause 9.2.2 gives this header size:

    MAC-hs header = VF 1 + Queue ID 3 + TSN 6 + SID 3 + N 7 + F 1 = 21 bits

The TSN is 6 bits here. In 1.28 Mcps TDD multi-frequency HS-DSCH operation, RRC can extend it to 9 bits, and the header then grows by 3 bits. A row can carry N PDUs of 336 bits only when 21 + 336 x N is no larger than the TBS. Every row of the table follows this rule except one, as the list below shows.

• TFRI 0 to 6 and TFRI 42 to 48 carry no PDU : their transport blocks run from 240 to 355 bits. One 336-bit PDU plus the 21-bit header needs 357 bits, so TP(PDU) is 0 in these rows while TP(TBS) is not.
• Padding makes TP(PDU) lower than TP(TBS) : TFRI 16 has a 686-bit block but carries only one PDU, so 350 of its bits are header and padding. TFRI 96 carries 24 PDUs in 8313 bits and loses only 249 bits.
• TFRI 95 lists one PDU fewer than fits : its 7785-bit block can hold 23 PDUs, because 21 + 336 x 23 = 7749 bits. The table lists 22 PDUs and a TP(PDU) of 1,478,400 bit/s. With 23 PDUs the value would be 1,545,600 bit/s. The row is left as the test setup shows it.
• N stays well below its limit : 25.321 lets a 1.28 Mcps TDD UE assume at most 45 MAC-d PDUs per TTI. The largest row here, TFRI 96, uses 24.
• Both columns are peak values : they assume that the Node B schedules the UE in every sub-frame and that every block is decoded at the first attempt. A retransmission or an idle sub-frame lowers the real rate.

How does each TFRI row map to the HS-SCCH fields?

The TFRI number in the first column is only a row index of the test setup. The Node B never sends it over the air. Instead, the UE receives a set of HS-SCCH fields, and the other columns of each row give their values.

25.222 subclause 4.6 lists the HS-SCCH fields for 1.28 Mcps TDD. Four of them describe the transport format and the resources. The first is the channelisation code set xccs, in 8 bits. The second is the timeslot information xts, in 5 bits. The third is the modulation xms, in 1 bit. The fourth is the transport block size index xtbs, in 6 bits. The column names Xms, Xts and Xtbs follow these 25.222 names, and NumOfCode with CodeOffset gives xccs. The HS-SCCH page covers the remaining fields.

Read each row from left to right as one HS-SCCH grant. The columns map to the 25.222 fields as follows.

• NumOfCode and CodeOffset give xccs : 25.222 allocates HS-PDSCH codes contiguously from a start code kstart to a stop code kstop. If CodeOffset is the start code, a row with 10 codes uses codes 1 to 10 at SF 16. A row with 16 codes uses all 16. The 8-bit xccs then carries kstart - 1 and kstop - 1 in 4 bits each.
• Xms gives xms : for a UE without 64QAM, xms = 0 means QPSK and xms = 1 means 16QAM. For a UE with 64QAM, xms = 0 means QPSK or 64QAM, and the UE decides between them from the code rate. This table uses only QPSK and 16QAM.
• Xts gives xts : 25.222 maps bit xts,n to timeslot n+1, so xts,1 to xts,5 stand for TS2 to TS6. TS1 is always uplink and never carries HS-PDSCH. When higher layers allow TS0 for HS-PDSCH, xts,1 stands for TS0 instead. The number of set bits is the number of HS-PDSCH timeslots: 0x08 has one, 0x0c has two and 0x0e has three. If the test setup writes xts,1 as the most significant bit, these values select TS3, then TS3 and TS4, then TS3 to TS5.
• Xtbs gives xtbs : xtbs is the 6-bit TB size index k, sent MSB first. The TBS column is the size of index k in 25.321 Table 9.2.3.3-5. That is the bit aligned table for HS-DSCH categories 13 to 15, and all 97 rows match it. The same index gives a smaller block to a lower category. For example, k = 2 is 249 bits for categories 1 to 3 and 256 bits here.
• The CQI column is empty for a reason : a 1.28 Mcps TDD UE does not report a CQI index as an FDD UE does. It reports a recommended transport block size RTBS and a recommended modulation format RMF on the HS-SICH, as 25.224 subclause 5.9.2 defines. So there is no single CQI value to put against a row.

Two patterns appear across the whole table. They show how the test setup grows the rate from row to row.

• The TBS index starts again at 1 for 16QAM : rows 0 to 41 use k = 1 to 42 with QPSK. Rows 42 to 96 use k = 1 to 55 with 16QAM. So most block sizes appear twice, once per modulation, with different codes or timeslots.
• Codes grow first, then timeslots : within each modulation, the rows move from 10 codes to 16 codes, and then add a timeslot. The index k grows by about 6.8 percent per step, from 240 bits at k = 1 to 14043 bits at k = 63.

How close does each TFRI row come to the physical limit?

A row is usable only if its transport block fits into the physical bits that the row allocates. The effective code rate measures that fit, and it also explains where the table stops. 25.224 sets the upper bound: a UE never reports a CQI whose code rate is greater than 1.

The physical bits come from 25.221 Table 8KA. At SF 16, one HS-PDSCH code in one 1.28 Mcps TDD timeslot carries 88 data bits with QPSK and 176 bits with 16QAM. The HS-DSCH also adds a 24-bit CRC per TTI, as 25.222 subclause 4.5.1 defines. So the effective code rate of a row is:

    code rate = (TBS + 24) / (NumOfCode x number of timeslots x bits per code per timeslot)

The table below applies this formula to the last row before the codes, the timeslots or the modulation change. That row comes closest to the limit of its allocation, so the next row needs more resources.

• The table stops where the code rate would pass 1 : TFRI 96 already has a code rate of 0.99. The next index, k = 56, is 8877 bits, and 8877 + 24 = 8901 bits do not fit into 8448 physical bits. So a grant of 16 codes in 3 timeslots with 16QAM cannot carry a larger block.
• 16QAM can save a timeslot : rows 65 to 71 carry the same blocks as rows 23 to 29, at the same code rate. The 16QAM rows use 10 codes in one timeslot, while the QPSK rows use 10 codes in two timeslots. The 16QAM grant therefore leaves a timeslot free for another UE.
• A category 13 to 15 UE can go further : these categories allow 5 timeslots and 14043 bits per TTI in 25.306 Table 5.1c. That is 2,808,600 bit/s at 200 TTIs per second. This table uses at most 3 timeslots, so its peak is TP(TBS) = 1,662,600 bit/s at TFRI 96.
• A high code rate needs a good channel : the UE derives its RTBS for a BLER of no more than 10 percent. So the Node B reaches a row near a code rate of 1 only when the channel is very good, and it selects a lower row otherwise.

Reference

• 25.321 Medium Access Control MAC protocol specification - v19.0.0, subclause 9.2.2 MAC-hs header and Table 9.2.3.3-5
• 25.222 Multiplexing and channel coding TDD - v19.0.0, subclauses 4.5.1 and 4.6
• 25.224 Physical layer procedures TDD - v19.0.0, subclause 5.9.2 HS-DSCH channel quality indication
• 25.221 Physical channels and mapping of transport channels onto physical channels TDD - v19.0.0, 1.28 Mcps sub-frame structure and Table 8KA
• 25.306 UE Radio Access capabilities - v19.0.0, Table 5.1c
• 25.331 Radio Resource Control RRC protocol specification - v19.0.1, MAC-hs-WindowSize