Performance of UMTS Radio Link Control

Transcription

1 Performance of UMTS Radio Link Control Qinqing Zhang, Hsuan-Jung Su Bell Laboratories, Lucent Technologies Holmdel, NJ 77 Abstract- The Radio Link Control (RLC) protocol in Universal Mobile Telecommunication System (UMTS) contains a suite of features and options which make the protocol very flexible and adaptive to operation in different radio environments and for various applications. In this paper, we analyze the various features and functions associated with the RLC protocol and evaluate the performance over UMTS specific physical link through simulations. Specifically, we examine the detail behavior of the protocol under various conditions and options, including polling, status transmission mechanism, and packet discard functions. We compare different and examine their impacts on the delay and throughput as well as acknowledgement overhead. We also compare different discard parameters and service rates and evaluate their impacts on the overall performance. Finally we provide quantitative results for web-browsing traffic which is considered as one of the future applications in G wireless networks. I. INTRODUCTION Universal Mobile Telecommunication System (UMTS) is a rd generation (G) wireless system based on WCDMA technology to support voice, high-speed data and multimedia services. In UMTS, the Radio Link Control (RLC) stands on top of the physical and Media Access Control (MAC) layer to provide reliable data transmissions over the radio link. The RLC specification in GPP standards [] contains a suite of features and options which make the protocol very flexible and adaptive to operation in different radio environments and for various applications. This imposes a challenging task for protocol design and performance evaluation. In this paper, we analyze the various features and functions associated with the RLC protocol. We model four layers to pursue a comprehensive study, i.e., the physical layer, the MAC layer, the RLC layer and the upper layer. We focus on the acknowledged mode (AM) where retransmission is performed. The retransmission scheme in RLC specification for Release99 is Type I hybrid ARQ. For the purpose of performance evaluation, a simulation model was built to realize the full operations of the RLC protocol. The performance metric is throughput, delay, acknowledgment overhead and packet loss rate. We examine the behavior of the protocol under various conditions and options, including polling, status transmission mechanism and packet discard functions. We compare different and examine their impacts on the delay and throughput as well as acknowledgement overhead. We also compare different discard parameters and service rates, and evaluate their impacts on performance. Finally we provide quantitative results for web-browsing traffic which is considered as one of the future applications in G wireless networks. II. OVERVIEW OF UMTS RADIO LINK CONTROL PROTOCOL A. Retransmission schemes of RLC Basic concept The basic scheme consists of the transmitter sending polls to the receiver, and the receiver sending status report back to the transmitter indicating which of the RLC Protocol Data Units (PDU) have been successfully received and which have not. Upon receipt of the status report, the transmitter retransmits the PDUs which were negatively acknowledged. Many additional features have been included in RLC to reduce the retransmission delay, prevent unnecessary retransmission, reduce the overhead of acknowledgements, and prevent deadlock of the protocol. Type of retransmission The current UMTS RLC protocol uses type I hybrid ARQ as the error recovery scheme for the AM mode. There are three types of hybrid ARQ schemes, stop-and-wait (SAW), go-back-n (GBN) and selective repeat (SR), which have been studied and analyzed intensively in the past. RLC can use any one of the retransmission schemes by configuring the transmission window and acknowledgement format appropriately. Polling mechanism RLC is a transmitter driven protocol via the polling mechanism. The transmitter sends the polling request to the receiver by setting the poll bit in the AM mode data (AMD) PDU. The receiver responds by sending the status report (in a number of STATUS PDUs) back to the transmitter. Retransmission is triggered if a negative acknowledgement is indicated in a status report. There are total eight different polling triggers defined in the RLC specification: last PDU in transmission buffer, last PDU in retransmission buffer, Poll timer, every Poll_PDU PDU, every SDU, timer based, window based, polling prohibit. Last PDU in transmission buffer and last PDU in retransmission buffer polling triggers can avoid deadlock of the RLC entities. Polling request should be sent frequently to reduce the acknowledgment feedback delay. Upon receipt of the acknowledgment through status reports, the transmitter can either retransmit the lost PDUs, or remove the PDUs which are successfully received from the retransmission buffer and move the transmitter window to avoid protocol stalling. The delay performance will be improved with fast polling request. However, the more frequently the polling request is triggered, the more frequently the status report is generated. The status reports cause overhead by occupying the link bandwidth on the reverse direction. It also introduces interference to other users (other RLC entities) in a CDMA system. The throughput and delay performance of each individual entity will be degraded with more frequent status reports. Clearly there is a trade-off of the frequency polling //$7. IEEE

2 The different polling triggers defined in the standards provide the flexibility and allow the network to control the polling frequency based on the network conditions, such as traffic load, link quality, quality of service requirements, etc. Status transmission mechanism Upon receipt of a poll request, the receiver always sends back a status report which is carried by one or multiple STATUS PDUs. The following triggers are optional for the status transmission: detection of missing PDUs, timer based status transmission, Estimated PDU Counter (EPC) mechanism, status prohibit. Detection of missing PDUs and Timer based status transmission triggers are receiver driven and allow the receiver to send status reports more aggressively. The EPC mechanism and Status prohibit functions prohibit excessive status message exchange between the transmitter and the receiver. SDU discard function The Service Data Unit (SDU) is the data unit exchanged between the RLC layer and the upper layer. The SDU discard function allows the transmitter to discard the RLC PDUs associated with a SDU from the retransmission buffer in case the transmission of those RLC PDUs is unsuccessful for a long period. This function provides a mechanism to avoid buffer overflow and reduce the maximum transmission delay from an arbitrary large value. There are two SDU discard functions that are controlled by the network: timer based discard, with explicit signaling, SDU discard after MaxDAT number of retransmissions. Timer based discard function discards the SDU after a timer expires. It controls the exact maximum delay each SDU may experience. It is insensitive to the variation of the channel transmission rate and error rate. As such, the SDU loss rate increases as SDUs are discarded. SDU discard after MaxDAT number of retransmissions is an alternative discard function. It tries to keep the SDU loss rate constant. However, its delay performance is dependent on the channel condition. The network will decide which SDU discard function to be used according to the QoS requirement of the Radio Access Bearer. B. Interaction between RLC and other layers The interaction between RLC and other layers is performed by exchanging logical and control information through primitives. The detail definition of all the data and control primitives is described in the standard []. In general, upper layers send request to the RLC layer for transmission of higher layer SDUs. RLC confirms and delivers to the higher layers RLC SDUs that have been received. RLC also indicates to higher layers which RLC SDUs have been discarded. The procedure of communications between RLC and MAC layer can be found in []. In summary, MAC layer selects the appropriate Transport Format Combination (TFC) for each transport channel depending on the instantaneous source rate. MAC informs RLC the number of PDUs per Transmission Time Interval (TTI). MAC also schedules and coordinates the transmission of each RLC entity on common and shared channels. III. SIMULATION DESCRIPTION A. Overview In order to maintain simulation efficiency, the simulation focuses on the transmitting side. The major functions at the transmitter, such as segmentation/concatenation, padding, transmission and retransmission buffer management, acknowledgement handling, etc, are all implemented. The functions at the receiver side are fulfilled without explicitly implementing the individual modules. For example, the status reports in the reverse link are only given properties such as error probability and propagation and processing delay, which are defined in the Reverse Channel block (as shown in Fig. ) and determined using link layer simulation results. Traffic SDU Segmentation Concatenation New PDU Poll Triggers MUX Set Poll Bit MAC Retx PDU PDU Request Status Report Reverse Channel Forward Channel Receiver Fig. Simulation block diagram The simulation details are illustrated in Fig.. The transmitting side includes a Traffic module which can generate the incoming traffic. The incoming traffic packets are stored as SDUs in the SDU. These SDUs are then segmented or concatenated into PDUs, added RLC header, and stored in the New PDU. Padding of PDU is switched off. In addition to the New PDU, there is a Retransmission PDU. A Multiplexer (MUX) following the two PDU buffers can receive requests from the MAC layer to determine how many PDUs to output in a given TTI and which PDU buffer to take PDUs from. A PDU in the Retransmission PDU can be transmitted only when the corresponding NACK has been received. The retransmitted PDUs always have higher priority than new PDUs. If the MUX decides on a new PDU, this new PDU will be removed from the New PDU and placed in the Retransmission PDU after being transmitted. Before a PDU is handed to the MAC layer, the Poll Trigger conditions are checked to determined whether the Poll Bit should be set or not. Network decides which Poll Triggers to be switched on or off. In the simulation, the MAC module requests a constant number of PDUs for every TTI depending on the service rate. However, the actual number of PDUs 7

3 transmitted depends on whether there are PDUs in the buffers that are eligible for transmission. The eligible PDUs are forwarded to a Forward Channel module which determines the forward link delay and whether the PDU is in error. If the PDU is deemed correctly received, the receiver counters, states and performance metrics are updated accordingly. Otherwise, no action is taken. If the Poll Bit of a correctly received PDU is set, a Status Report containing ACKs and NACKs of the PDUs in the current receiving window, up to the highest received sequence number, is initiated at the receiver and passed through the Reverse Channel. The Reverse Channel gives each Status Report a reverse link delay and determines whether it is correctly received. A correctly received Status Report is used to update the transmitter counters, states, SDU, and whether and when a PDU will become eligible for retransmission. An erroneous Status Report will not have any effect on the transmitter. To avoid redundant retransmissions and system instability, a NACK received within a round trip delay of the transmission of the corresponding PDU is ignored. B. MAC and Physical layer model We consider the UMTS specific physical layer model where the transport block error probabilities are obtained from the link level simulation results. Compared to the Additive White Gaussian Noise (AWGN) channel, the UMTS specific channel model has more bursty errors. We consider two service rates for packet data services: kbps and 8 kbps. We assume that only one service rate is applicable for a user and is chosen at the radio bearer setup procedure. The rate cannot be re-negotiated during the session once the connection is established. Once the service rate is determined, MAC selects the TFC, the size of transport block (TB) and the number of TBs per TTI. The detailed parameters are discussed in section V. C. Upper layer traffic model The SDU traffic arrival process is another important factor in the RLC performance. The traffic statistics affects the buffer occupancy distribution in conjunction with the transmission and retransmission methods. The performance metrics such as delay and throughput are related to the traffic characteristics as well. We use the traffic model [] for Web browsing application to study the performance of the RLC protocol. There are in total three phases to characterize the web browsing procedure. Session: The session arrival process is modeled as a Poisson process. The inter-arrival time depends on the cell loading and user behavior. Packet call: During a Web browsing session, each packet call corresponds to a user downloading a web page. The number of packet calls per session follows Log-Normal distribution with mean of and standard deviation of. The think time between packet calls is modeled by a Gamma distribution with mean of seconds and standard deviation of seconds. Packet: Round trip delay includes the propagation delay and processing time at both forward and reverse links. Each packet call generates a sequence of packets. For example, the information in a web page is transmitted through a number of packets. Each packet corresponds to a distinct object in a web page. The inter-arrival time between packets is Geometrically distributed with mean of.7 ms. The number of packets per packet call is Pareto distributed with mean of. For single RLC entity, we simulate two phases, packet call and packet, to generate the SDU traffic arrival. Each packet is treated as one SDU. Since the think time starts after a Web page (packet call) is completely downloaded, all the SDUs will be dismissed from the buffer before the user starts to download the next web page. In other words, for each page downloading, the user will see an empty RLC buffer. It should be noted that upper layer protocols, e.g., TCP/IP, may vary the SDU traffic characteristics at certain level. The interaction between RLC and TCP layer flow control will be included in our future study. D. Performance metrics The performance metrics is described as follows. Throughput Throughput is defined as the average number of information bits transmitted divided by the total time duration. Delay Packet call delay is defined as the difference between the first packet arrival time at the transmitter and the time the last packet in a packet call is received successfully at the receiver. The delay for packet calls corresponds to the average page downloading time. SDU Error Rate Because of the SDU discard function, the receipt of the SDUs will not be error free. The SDU error rate versus different parameter settings is given. Acknowledgement overhead The acknowledgment overhead is calculated as the average ratio of the number of status reports to the number of PDUs transmitted per TTI. IV. SIMULATION RESULTS A. Simulation parameters and assumptions The simulation parameters and assumptions are summarized in Table. TABLE Simulation Parameters Parameter Assumption SDU Traffic model Web browsing Physical layer UMTS link level results channel RLC Block error rate 8.% RLC PDU bytes TTI ms Service Rate (PDUs per TTI) kbps or 8 kbps ( or PDUs per TTI) Tx_Window_Size 7 Rx_Window_Size 7 SDU Discard Timer based discard function Round Trip Delay ms 8

4 B. Performance results We have performed intensive simulations to evaluate the performance of the RLC protocol by varying different parameters and choosing different options. In this section, we summarize and highlight the results. Effect of polling mechanism One of our main objectives is to investigate the effect of various polling triggers and examine their impacts on the performance. Since our main interest is the delay and throughput of web page downloading, we used the poll every POLL_SDU trigger. Other polling triggers, such as poll every POLL_PDU, periodic polling, etc, can achieve similar results with the right parameter settings. We are also interested in the other two polling triggers, last PDU in transmission buffer and last PDU in retransmission buffer, since these two triggers can prevent protocol deadlock. With the last PDU in retransmission buffer trigger, whenever a PDU is the last in the retransmission buffer that is eligible for retransmission, its poll bit is set to one. Fig. and Fig. shows the simulation results of packet call throughput and delay versus different value of POLL_SDU, with and without the other two last PDU polling triggers. The SDU discard timer is set to seconds. We can see that without the two last PDU polling triggers, the throughput decreases as the polling interval increases. The throughput drops more than % from polling every SDU to polling every SDU. The delay performance also degraded with the increase of polling interval. The average packet call delay increases about % from polling every SDU to polling every SDU. Kbytes/s Packet Call Throughput Fig. Comparison of packet call throughput with different It is interesting to notice that with the two last PDU triggers, the performance degradation is not that much with large value of, the reason being that although the polling interval is large, the two last PDU triggers happen quite frequently. They trigger enough polling messages and compensate the lack of polling by. It is evident that frequent polling improves the performance. However it generates status reports which occupy the reverse link bandwidth. Fig. shows the status report overhead versus different. With the poll every trigger alone, the status report overhead drops from % to.% with polling interval of SDU to SDU. In conjunction of the last PDU polling triggers, the status report overhead drops from.% to.% instead. This indicates that the polling messages generated by the two last PDU triggers have almost the same amount as those triggered by polling every SDU. ms Packet Call Delay 8 Fig. Comparison of packet call delay with different Another important performance metric is the SDU discard rate. As mentioned earlier, we use the timer based SDU discard function to reduce the protocol deadlock and stalling. Fig. shows the SDU discard rate versus different polling interval. It is shown that the SDU discard rate increases from % to 7% with polling interval of SDU to SDU. The waiting time of each outstanding PDU increases as the polling interval increases. As a result, the probability that a SDU waiting time exceeds the threshold and gets discarded increases. When the two last PDU triggers are enabled, the SDU discard rate decreases by as much as 9% with of. % Status Report Overhead 8 Fig. Comparison of status report overhead with different SDU Discard Rate 8 Fig. Comparison of SDU discard rate with different 9

5 Effect of SDU discard timer Next we evaluate the effect of SDU discard function on the performance. Fig. to Fig. 9 shows the performance results with different discard timer thresholds: and seconds. We can see that the throughput does not change much with different discard timer values. The status report overhead also remains the same. However, the packet call delay increases from around.7 seconds to. seconds, more than % increase. The reason is that with the current traffic loading and kbps link capacity, the delay is dominated by the queuing delay. The larger the discard timer is, more packets are waiting in the buffer. A newly arrived packet (SDU) has to wait longer before it can get the chance to be transmitted. Thus it results in a larger average delay per packet call. Larger discard timer can reduce the packet drop rate. This is evident in Fig. 9. We can see that the SDU discard rate drops % to 7%. With polling every SDU, the SDU discard rate is around %. Kbytes/s 8 7 Packet Call Throughput 8K sec Discard Timer 8 Fig. Comparison of packet call throughput with different ms Packet Call Delay 8K sec Discard Timer 8 Fig. 7 Comparison of packet call delay with different Effect of service rate In these figures, we also examine the RLC performance with a higher service rate, 8 kbps. It is shown that the both throughput and delay performance improve quite much with a higher service rate. The SDU discard rate drops tremendously. This is due to the fact that with a large link capacity, the queuing delay of each SDU is very small under the current loading of web browsing traffic. The SDU discard probability is thus very small. It is interesting to notice that We consider the status report generated from the receiver only. The status report associated with SDU discard from the transmitter is not included here. the status report overhead is actually higher with 8 kbps service rate, the reason being that the buffer is drained at a much higher rate which triggers the last PDU in transmission and retransmission buffer polling very frequently. The two last PDU triggers dominate the polling and cause the polling overhead almost invariant with different poll SDU intervals. % Status Report Overhead 8K sec Discard Timer 8 Fig. 8 Comparison of status report overhead with different SDU Discard Rate 8 8K sec Discard Timer Fig. 9 Comparison of SDU discard rate with different V. CONCLUSIONS In this paper, we have evaluated the various features and options of the UMTS RLC protocol through intensive simulations. We investigated the performance of the RLC layer for web browsing application. We found that with polling every SDU in conjunction with the last PDU in transmission and retransmission buffer polling, we could achieve very good performance results with limited amount of overhead. In addition, we found that large service rate can produce very good performance, especially for web browsing application. ACKNOWLEDGMENT The authors would like to thank Andrew Zaporozhets for providing UMTS link level simulation results. REFERENCES [] GPP TS. v.., RLC protocol specification. [] GPP TS., MAC protocol specification. [] Lucent Internal document, UMTS Specific Traffic Model.