The introduction of a wireless network in the path of a data exchange between two hosts presents a significant bottleneck to high-speed data transfer. Besides the fact that data rates are inherently slower with longer delays, a significant increase in errors due to noise must be expected.
Efficiency is greatly reduced by the upper-layer misinterpreting timeouts caused by degraded RF propagation conditions as network congestion. The transport control protocol (TCP) responds to this slowdown by invoking a congestion control algorithm which is designed to allow routers time to clear packets. The effect on the application layer could cause software performance to be reduced to an unacceptable level.
The solution is to test data throughput, both at the radio link and transport layers under varying data rates and noise or fading levels while the application is running. The sensitivity of the application to dropouts in data throughput can be observed allowing software designers to determine if improvements are needed.
In this article, we'll look at the flow of data in a cdma2000 system using the high-speed packet data service option 33 model, which allows CDMA networks to support the data transfer by specifying protocol requirements of different layers in each network entity along the way. During the discussion, we'll highlight the impact of performing data throughput tests at both the radio link protocol (RLP) and TCP layers.
Reliability
In a high-speed CDMA packet data network, reliability is achieved through connection-oriented protocols. These include TCP at the transport layer and RLP protocol at the physical layer.
TCP provides provide reliable, connection-oriented service over a network of fiber-optic and copper wire spanning the distance between communication endpoints. The packet data network, which includes routers that buffer data and send it on to its destination, is subjected to bursts of data that can cause congestion and eventual delay or complete loss of packets. This portion of the network seldom if ever experiences data loss due to line noise.
With the inclusion of an air interface, however, the primary cause of data loss shifts from congestion to noise and interference. Unfortunately, since TCP anticipates that data delivery problems will be caused by network congestion it has mechanisms in place that respond as if any and all problems come from the wireline portions of the network. One of these mechanisms is to keep track of the time it is taking for each packet of data to be delivered, and another is to respond to delays with packet retransmission. Ultimately TCP makes sure that no packets go undelivered.
RLP is part of the wireless link's physical layer, and is designed to provide reliable data transfer over a single hop—the air interface. The extent to which RLP will go to ensure data communication is referred to as a "best effort" delivery of frames in an environment where the RF channel is frequently impaired by aberrations such as multipath signals and fading conditions. If severe problems force RLP to give up on sending portions of the data, RLP will perform a reset and move on, effectively transferring the problem up the stack to TCP where errors will not be allowed to go uncorrected.
In the rest of the article to follow, we'll contrast the action between RLP and TCP in the presence of signal loss in the wireless link. To start, however, let's take a look at the protocol stack of a packet-enabled CDMA device.
Protocol Stack Description
Figure 1 illustrates the protocol stack of a cdma2000 wireless device. The shaded area shows the protocol entities used specifically with Service Option 33 (High Speed Packet Data) calls.
Figure 1: Typical data-enabled cdma2000 protocol stack.
When a high-speed packet data call is connected, application data can be exchanged between TCP peers. Since TCP includes the acknowledgement of data delivery by the receiver, if packets are lost, corrupted, or delayed, TCP will retransmit them. The failure of packets to be acknowledged within a pre-determined length of time prompts TCP to reduce the flow of data.
TCP relies on IP, the Internet Protocol, to manage delivery of its payload, encapsulated within IP datagrams, all the way to the destination endpoint. Along with other control protocols in the network layer, IP oversees the relay of datagrams through the various routers along the way. This journey will traverse different networks with different topologies, including the wireless link. IP does not, by default, perform error correction. Instead, it relies on the services of layers below it to detect and correct problems.
PPP is responsible for establishing a link between the mobile station and the packet data service node (PDSN). PPP requires the services of all layers below it to transfer data from the PDSN (a specialized router that serves as the wireless terminal's interface to the Internet) to the wireless device.
RLP provides a byte (or octet) stream service between the base station and a wireless terminal. The multiplex sublayer combines RLP data with other services (such as voice) and maps these to physical layer traffic channel frames. The physical channel below RLP performs the coding and modulation necessary to transmit and receive the resulting binary bit stream.
In many ways, RLP is similar to TCP:
- It is a connection-oriented byte stream service. Framing boundaries from upper layers are not preserved when the data is divided into smaller parts. It is left to the upper layers to reconstruct frames.
- Each block of data is assigned sequence numbers. If data arrives out of order it is inserted in its correct position in the byte stream.
- A mechanism is provided to retransmit data that does not arrive on time.
There are also some difference between RLP and TCP worth considering:
- RLP provides a best effort delivery. TCP provides guaranteed delivery.
- RLP frames are a fraction of the size of a TCP segment. A typical TCP segment is 1500 bytes, compared to a typical RLP frame size of around 30 bytes.
- RLP does not attempt to control the flow of data. Data transfer takes place at the rates defined by the service option and implemented in the MAC sublayer and physical channel.
Providing Wire-Like Services to PPP
RLP provides a best effort delivery service to PPP, the same protocol that is typically used in dial-up modem applications. In non-wireless instances PPP is often transported over high-speed, low-latency medium such as Ethernet, which is relatively immune to data losses caused by noisy transmission lines. It is not necessary for PPP to keep track of delivery by assigning sequence numbers and acknowledging the reception of packets. The same is true of wireless systems, but only because the RLP layer has error recovery capability and attempts to provide wire-like service to PPP.
When data is lost over the air interface, it is normally a result of degraded RF signal conditions. RLP responds by re-transmitting frames as quickly as possible. If channel conditions improve quickly enough, there is no data loss and the upper layers, TCP in particular, are shielded from the effects. To increase the likelihood that RLP will recover quickly, retransmitted frames are given a higher priority than new frames. If channel conditions do not improve in time, errors will go uncorrected. This level of service is robust enough to relieve PPP of the responsibility of fixing errors, but for guaranteed error free service, error recovery occasionally must be pushed up the stack to TCP.
If any frame of RLP data cannot be delivered, at least one1500-byte IP datagram will need to be retransmitted. Figure 2 shows typical data lengths for the different units of data each protocol layer exchanges.
Figure 2: Data lengths for data units exchanged at each protocol layer in a wireless stack.
TCP Flow Control Effects on Data Throughput
TCP limits the flow of data to avoid overloading network routers or exceeding the receiving end's ability to buffer incoming data. To avoid overloading the network, TCP monitors congestion by measuring the round-trip time (RTT) that it takes for data segments to be delivered to their destination and acknowledgements to be returned. Using this data, a retransmission timer value will be estimated that reflects the current conditions on the data pathway. Keep in mind that the air interface, even under ideal conditions, presents a data bottleneck.
If a segment is not acknowledged within the timeout period, that segment will be queued up for re-transmission. At the same time, a flow-control algorithm will decrease the data throughput to nearly zero to allow network congestion to clear up. Assuming that acknowledgements resume, the data rate will gradually increase. The rate of increase in throughput is dependant upon the RTT, which is an estimate of the data rate that TCP thinks the network can handle. As you can see, the TCP congestion control algorithm reacts to error conditions much differently than RLP, which as you might recall seeks to retransmit data as quickly as possible.
The other limit TCP places on the amount of data it sends is there to avoid overloading the receiver. The receiver's ability to accept additional data is advertised with every data acknowledgement it transmits back to the data sender. This is referred to as a "piggybacked" acknowledgement, since it gets a free ride with data flowing back to the sender. If the congestion control algorithm does not slow the data rate down, at some point the advertised receive window will.
Congestion control can be observed by setting up a high-speed packet data connection and monitoring IP data throughput (TCP segments are encapsulated within IP packets). Figure 3 shows a screen capture of a data throughput measurement.
Figure 3: Diagram of a data throughput measurement.
Figure 3 was taken from test equipment that displays the instantaneous, peak, and average IP data rates. A cdma2000 service option 33 call was set up using a mobile phone with a data connection to a PC. As data was being streamed at 153.6 kbit/s on the forward channel, the RF connection was removed momentarily to force a TCP retransmission timeout.
The magenta trace shows TCP throughput was nearly stopped at one point, then gradually increased until flow was once again controlled by the receiver window. The cyan trace shows RLP throughput did not slow down nearly as much as TCP, and recovered to its normal rate more quickly.
Another analysis of this delay can be observed on the protocol messages that flow between the base station and wireless terminal. With software that timestamps the occurrences of TCP messages, the number of retransmissions can be seen and the delay can be measured (Figure 4)
.
Click here for Figure 4
Figure 4: Analysis of delay in protocol messages flowing between the base station and mobile terminal.
In line number five of Figure 4, a 1500-byte segment beginning with byte 2099f33 was sent on the forward channel. After line 21, TCP transmissions paused for nearly a full segment before retransmitting the segment first sent in line five nearly two seconds earlier. In line 24, the receiver acknowledged receiving the retransmitted segment.
The RF conditions that cause data loss at the RLP layer and force the TCP congestion control algorithm to slow down data transmission can be simulated with a base station emulator. It is particularly useful to have counters that monitor RLP retransmissions. Figure 5 shows a display from test equipment that monitors RLP while simulating an actual base station while routing data to the wireless device.
Figure 5: Display showing the monitoring of RLP.
Data Loss Impacts on Layer 7
Intermittent data losses will affect different applications in different ways. The most predictable disturbance is long file download periods, for instance when running FTP in Layer 7.
Other affects could be more unacceptable to end users, such as disruption in video streaming sessions that rely on a minimum transfer rate for uninterrupted video streams. Graphics intensive software applications such as games may experience more serious problems as a result of data interruptions.
Testing application layer performance with measurable degrees of data throughput reduction can give the software designer a realistic idea of how well the software will perform on a real system. Test equipment should be flexible enough to simulate degraded RF propagation conditions and monitor IP throughput to and from a wireless device and log messages at various layers in the protocol stack.
Author's Note: Protocol logs and graphical data throughput figures shown in this article were obtained with Agilent's E5515C wireless communications test set using the E6702A cdma2000 lab application.
About the Author
Paul Dohrman is a customer education engineer at Agilent Technologies. He has written user documentation for IS-95 and now the IS-2000 mobile test market. Paul can be reached at paul_dohrman@agilent.com.
