A New Method for Testing Link Adaptation_IP Network Testing Technology
Figure 1: The processing functions that each TTI must perform. Since TTI can be as short as 1ms, this scheduling technique provides great flexibility to match traffic routing and throughput with available resources. It is the key to high throughput, stability and efficient use of bandwidth. However, a fundamental problem in the implementation of link adaptation has been plaguing the development of mobile devices: conventional test setups cannot fully identify and locate errors and failures in link adaptation methods. This article presents a test setup that can detect and locate scheduling errors with accuracy to a specific TTI level. Test link adaptation routines Traditionally, functional and performance tests are two very different parts of the protocol and system verification process. Scheduling is usually included in the functional testing section, which also has a fundamental impact on performance (data throughput). Traditional functional test methods generate a large amount of log records because each TTI (ie every 1 ms) scheduling software receives input and makes decisions. This means that log analysis is both tedious and time-consuming and therefore does not do this work. In contrast, link adaptation is usually a functional test that is implemented using a simple but finite configuration (a considerable gap from meeting the requirements for covering real world use cases). Link-adapted performance testing is achieved by measuring data throughput. Because of the limited range of link adaptation functional tests, full functional verification cannot be performed until the performance test begins. Obviously, this is usually at the end of project development. In many cases, the performance problems associated with link adaptation are closely related to functional errors. If these functional problems are found during performance testing, they must be corrected. This may mean that certain parts of the equipment must be redesigned and re-validated. As a result, accurate performance test data becomes a valuable resource, allowing the development engineer to focus on debugging errors and verifying it repeatedly where it is really hard. Unfortunately, the output provided by today's regular performance test setup is very inaccurate. They include server applications running on PCs or UNIX workstations and client applications running on dial-up PCs. Server and client applications implement data communication protocols (such as FTP transfers), take measurements, and provide results. The problem is that the timing accuracy provided by the Windows or Unix operating system (OS) is approximately 500ms. The reality is that the actual transmission of packets in Windows applications usually uses NDIS technology, which has better timing accuracy than Windows itself, but the measurement of these transmissions is affected by the operating system. Worse, even with such hundreds of millisecond horizontal coarse timing accuracy, operating systems or computer manufacturers cannot guarantee it. Because the TTI of LTE (and some configurations of HSPA and HSPA+) is 1 ms, it is clear that Windows-based applications may provide data traffic that does not exceed the total throughput level of the OSI stack application plane. Therefore, detailed positioning information that is accurate to the specific TTI functional problem cannot be provided. To find out this kind of information that helps debug throughput problems, it is helpful to study a simplified example (see Figure 2). Figure 2: The consequences of packet retransmissions are reduced data throughput. For example, an IP data stream transmitted by a base station. With link adaptation, the scheduler uses the maximum and minimum free block sizes; each block size transmits the same number of blocks. If we use 256 bits and 7,480 bits as the minimum and maximum transmission block (TBS) respectively, this will achieve a total data throughput of about 1,948,000 bps (ie about 2 Mbps). (For simplicity, in the calculation, this example does not include the protocol header; the selected IP header and data size are assumed to be 128 bits.) Imagine that the next time the same measurement was implemented, the performance of the RF protocol has deteriorated (perhaps due to a reduction in the performance of the protocol software), causing every third-largest packet to be lost. The radio protocol stack must retransmit lost packets, which will reduce the data throughput to approximately 1,504,000 bps (approximately 1.5 Mbps). This is a 25% reduction from the first measurement. With conventional performance test setups, engineers do not understand the cause of the reduction in throughput or the fault, they see only the throughput rate. However, if the measurement system can provide accurate timing, then simply measuring the packet delay will make it easy to identify the problem. A new method for testing link adaptation An alternative method of measuring throughput in the field of data communications provides this capability. In the field of data communications (such as the mobile phone industry), throughput measurement is used to test performance. Precision instruments designed for this task can provide accurate data related to the performance of the system under test, such as throughput (frame count and packet size accuracy), delay, and jitter. Using such an IP test setup (see Figure 3) to test the performance of the RF protocol stack exposes errors hidden at the TTI level that cannot be verified by conventional server-based test systems. Figure 3: An example of test setup proposed by Anritsu. Anritsu's proposed test system performs the following operations: 1. The mobile device (mobile phone or other user equipment) uses a radio protocol stack to establish a dial for a base station simulator such as Anritsu's MD8430A for LTE. This creates a data link between the base station and dial-up PC. 2. An IP test instrument (such as Anritsu's MD1230B data flow generator and analyzer) generates a definitive IP data stream. The flow passes through the base station simulator to the radio protocol stack (responsible for scheduling data transmission) and the radio frequency transmission stage. Once the user device receives the IP data, the user device sends the data to the dial-up PC. 3. The IP soft- bridge in the dial-up PC sends IP data from the COM port (from dial-up) back to the IP instrument (via the Ethernet port). 4. The IP instrument receives the returned data stream. Now it can calculate round-trip time, jitter, throughput, and error rate by comparing the time and content of each received packet with the transmission. For uplink measurements, the process is the same but in the opposite direction. The advantages of the new setting For the measurement of timing measurements (round-trip time and jitter) and the number and size of packets (throughput and packet/bit error rate), IP tools are far more accurate than any PC/Unix application. Typically, this type of instrument provides timing accuracy accurate to μs (some measurements, even ns). In addition, the timing accuracy is guaranteed by the instrument manufacturer. Another advantage of IP instruments is the repeatability of IP data streams. When a PC/Unix-based solution implements a true data protocol stack (such as TCP in FTP applications), it dynamically reacts to changes in available transmission bandwidth. This makes it impossible to get information about the performance of the RF protocol without looking at the TCP log. This has caused trouble for the already cumbersome process: In this case, the user must analyze the TCP logs before analyzing the RF protocol logs. IP instruments can always send the same data pattern, allowing users to focus on RF protocol analysis. Another aspect of repetitiveness comes from the fact that when the protocol stack processes information, the RF protocol repeats the endorsement and format reassembly several times over the transmitted information. How the process works depends on the size of the initial IP packet provided to the radio protocol. Therefore, the key to achieve repeatability is not only to send the same number of packets with the same jitter characteristics, but also to repeat the IP packet size at each measurement. This can be done with an IP analyzer, but PC/Unix-based applications cannot be implemented. If the IP data flow is correctly defined and the RF protocol configuration is known, this measurement method can quickly give detailed information on the performance of the RF protocol stack used by the user equipment. IP test method in the field of RF transmission In this regard, one obvious question is: If the benefits of using existing commercial IP analyzers are so obvious, why is this technology not yet adopted by the mobile phone industry? The reason lies in the RF protocol. Compared with protocols in the field of data transmission, RF protocols are extremely complex; since they have adopted fast link adaptation techniques, they have become increasingly difficult to catch. Because of this greater complexity, in order to benefit from the previously described benefits of repeatability and accurate error location, when designing IP data flows and associating IP measurements with the performance of RF protocols, it must be Be careful. Therefore, in order to apply this technology from the field of data communication, mobile phone developers must have a learning process. However, if the mobile industry can successfully adopt IP analysis technology, the benefit is to improve handheld device performance through precise positioning and fault characterization at the protocol layer. By improving the device's functional integrity, developers can also complete carrier acceptance tests faster and get higher scores on their device benchmarks. Shenzhen Ruidian Technology CO., Ltd , https://www.wisonen.com
Link adaptation (also referred to as scheduling) was first introduced as a feature of the HSDPA technology under the 3GPP protocol, which is a method of radio frequency resource allocation for mobile wireless networks. In this way, the RF protocol used by the base station provides data for downlink transmissions and allocates resources for uplink transmissions at each transmission time interval (TTI) (see Figure 1). 
