Even though there is huge difference between LTE and Non-LTE  in terms of physical layer implementation, you can just think of this as just extention of HSPA. Which means that in LTE you will have even bigger TBS than HSPA+ Dual Carrier. So in this case, very high performance IP data server is the most important factor for throughput test. For the detailed data path for LTE, you can refer to another pages of this site. Almost whole of this site is about LTE.

For example, if you are testing a Category 3 Max throughput case (System BW 20 Mhz, Number of RB = 100), the idea max throughput is around 100 Mbps. Even with PC to PC direct connect, it is not easy to achieve this level of throughput. So for this kind of extremely high throughput test, it would be the mandatory step to try the PC (both server and client) performance first by connecting the two PCs directly with a crossover LAN cable and try the throughput test. In rare case, even the quality of LAN cable would influence on the throughput. I recommend you to use Cat 6 LAN cable which support Gigabit data rate.

In addition, using 64QAM in downlink would be very common in LTE. In this kind of very high modulation scheme, the throughput is influenced greatly by channel quality (RF signal quality). Small change in downlink power, Fading, AWGN can create large changes in throughput.

This page answers two questions in that order. The first is what throughput you should expect from a given resource allocation. The second is why the IP throughput you measure stays below that number, even with a perfect RF condition.

• What is the ideal throughput for a given resource allocation ?
• Why is the measured throughput lower than the ideal value ?
• Reference

What is the ideal throughput for a given resource allocation ?

One of the most frequent questions that I get on the throughput test is "What is the ideal throughput with this condition ?"  In case of R99 or HSPA, the ideal throughput is described in a neat page of table and a lot of people knows what kind of throughput they have to expect, but in LTE the situation got much more complicated since there can be several factors determines the throughput and each of the factors can have so many different values. So the number of all the possible combinations for defining the throughput is so huge.

The most important factors to determine the ideal throughput are as follows :

• Number of RBs
• MCS (Modulation Coding Scheme) which determines I_TBS
• MIMO or SISO

The way to calculate the ideal throughput using these factors are explained in "Throughput Calculation Example" in Quick Reference page.

I made several examples of resource allocation and its ideal throughput as follows. These conditions are the most common condition for maximum throughput test. The values marked in gray cell is the one going over Category 3 LTE device capability. In most case, if I try the condition marked in gray cell with most commercial UEs that I tested (Category 3 UEs),  I got one of the following result.

i) The throughput degrade a lot (normally much lower than 100 M)

ii) It reaches almost 100 M, but does not go over.

(Thank God ! Call drop didn't happen even in this case)

Before you read the tables, check the unit. The SISO column is the TBS multiplied by 1000 and divided by 1024 x 1024. One transport block goes out in every 1 ms subframe, so TBS x 1000 is the rate in bit/s, and the division expresses it in units of 2²⁰ bits. In decimal Mbps, every row is about 4.9 percent higher. For example, 75376 bits in every subframe is 75.376 Mbps, while the table shows 71.88. The MIMO column is twice the SISO column, because two codewords each carry one transport block.

<< Downlink Resource Allocation and Throughput >>

The grey cells follow from TS 36.306 Table 4.1-1. A Category 3 UE receives at most 102048 DL-SCH transport block bits within a TTI, and at most 75376 bits in one transport block. The 75 RB row with MCS 28 needs 2 x 55056 = 110112 bits in MIMO, and the 100 RB row with MCS 28 needs 2 x 75376 = 150752 bits. Both are above the limit. The 100 RB row with MCS 23 needs 2 x 51024 = 102048 bits, which is exactly the Category 3 limit. So this row is the largest MIMO allocation that a Category 3 UE can take at 100 RB.

<< Uplink Resource Allocation and Throughput >>

Read the uplink table with the UE capability in mind too. In TS 36.213 Table 8.6.1-1, MCS 20 is the highest 16QAM index, with I_TBS 19, and MCS 21 to 28 use 64QAM. Among the categories in TS 36.306 Table 4.1-2, only Category 5 and Category 8 support 64QAM in the uplink. If the UE does not support 64QAM in PUSCH, TS 36.213 clause 8.6.1 limits the modulation order to 4, so an MCS 28 grant keeps its TBS but goes out in 16QAM. The code rate then becomes too high to decode. Also, a Category 3 UE sends at most 51024 UL-SCH bits within a TTI. So for a Category 3 UE, the MCS 20 rows are the realistic uplink targets.

• The ideal throughput is TBS per subframe : multiply the TBS by 1000 subframes per second, and double it for two codewords.
• The table uses 2²⁰ as one Mb : decimal Mbps values are about 4.9 percent higher than the numbers in the table.
• The UE category caps the table : a Category 3 UE cannot take more than 102048 bits in a downlink TTI, whatever the allocation.
• Uplink MCS 21 to 28 needs 64QAM support : without it, those rows are not reachable in the uplink.

Why is the measured throughput lower than the ideal value ?

Now I got what to expect for the throughput. Do I get this value if I just plug in my device into the test equipment and do FTP/UDP ?

In most case, the answer is NO.

Why not ?

There are couple of factors you have to keep in mind as follows :

i) The ideal throughput value in the table is on the basis of physical layer operation, not based on higher layer (e.g, IP layer) throughput.

ii) The ideal throughput value in the table is based on the assumption that there is no physical layer overhead and we can allocate these resource at every subframe

When a stream of data comes from IP layer to the physical layer, there are some overhead being added (e.g, PDCP header, RLC header, MAC header etc). So the IP layer throughput gets lower than the physical layer.

What kind of other overheads we can think of ? Followings are the most common overhead.

i) SIB transmission

ii) Symbols allocated for PCFICH and PDCCH.

At the subframe where SIB is transmitted, you cannot allocate the full bandwidth for data transmission. If you can dynamically allocate a little smaller No of RBs in these slots, you only have to sacrifice the number of RBs for SIB transmission.. but in most test equipment the situation is even worse. The equipment does not allow such kind of dynamic resource allocation just to avoid the overlapping of SIB and user data. In this case, the equipment does not tranmit any user data at the subframe where SIB is being tranmitted. In such a case, SIB transmission can be pretty huge overhead for the max throughput test.

The SIB cost is easy to estimate. TS 36.331 clause 5.2.1.2 fixes the schedule of SystemInformationBlockType1. It repeats in subframe #5 of every radio frame with an even SFN, which is once every 20 ms. If the equipment sends no user data in that subframe, the downlink loses 1 subframe out of every 20, which is 5 percent. The SI messages carry the other SIBs, in SI-windows that can use other subframes. Their cost therefore depends on the periodicity and the window length that the equipment configures.

Another overhead is the one by PCFICH and PDCCH. As you learned from Downlink Framestructure section, there is at least one symbols (max 3 symbols of each subframe are allocated for PCFICH and PDCCH). If you allocate three symbols for PCFICH and PDCCH, which means that you set PCFICH, 3 out of 14 symbols are allocated for non-user data. However, speaking purely in ideal sense this overhead would not influence the ideal throughput since the transport block size determined by 3GPP for each combination of resource allocation took this overhead into account. But in reality, if you allocate too large Transport block size (too high MCS and No of RBs) and allocate large PCFICH (e.g, 2 or 3), it normally reads to a lot of CRC error which in turn results in throughput degradation.

The header cost is small for large packets. With a 12 bit SN, the PDCP header is 2 bytes, and the RLC and MAC headers add a few bytes more. For a 1500 byte IP packet, that is well under 1 percent. For small packets, the same headers take a larger share. The number of packets that the UE and the equipment can process in one TTI can also become the limit.

As far as I tried with commercial device, the MAX IP layer throughput (UDP) that I achieved was around 90 Mbps with 20 Mhz system bandwith and MIMO condition. Physical layer throughput approaches almost 100 Mbps (only a couple of Mbps lower than 100 Mbps).

These numbers fit the 90 Mbps result above. Start from a physical layer rate close to 100 Mbps. Take away up to 5 percent for the SIB1 subframes and a little for the headers, and you get a rate in the low 90s. Any HARQ retransmission then takes a few more Mbps.

• The table is a physical layer number : PDCP, RLC and MAC headers and the IP headers come on top of it.
• SIB1 can cost 5 percent : equipment that skips user data in SIB1 subframes loses 1 subframe in every 20.
• Headers matter for small packets : for a 1500 byte packet they cost less than 1 percent.
• Too high an MCS with a large CFI leads to CRC errors : the code rate rises when the control region takes more symbols, and each CRC error costs a retransmission.

Reference

[1] 3GPP TS 36.213 v19.4.0 - E-UTRA, Physical layer procedures, Table 7.1.7.1-1, Table 7.1.7.2.1-1, clause 8.6.1 and Table 8.6.1-1

[2] 3GPP TS 36.306 v19.3.0 - E-UTRA, User Equipment radio access capabilities, Table 4.1-1 and Table 4.1-2

[3] 3GPP TS 36.331 v19.3.0 - E-UTRA, Radio Resource Control, clause 5.2.1.2 Scheduling