Performance of UMTS Radio Link Control

Qinqing Zhang, Hsuan-Jung Su Bell Laboratories, Lucent Technologies

Holmdel, NJ 07733

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 polling mechanisms 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 3G wireless networks.

I. INTRODUCTION Universal Mobile Telecommunication System (UMTS) is a

3rd generation (3G) 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 3GPP standards [1] 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 polling mechanisms 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 3G 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 Poll_SDU 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.

33460-7803-7400-2/02/$17.00 © 2002 IEEE

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 [1].

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 [2]. 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. 1) and determined using link layer simulation results.

Traffic

SDUBuffer

SegmentationConcatenation

New PDUBuffer

Retx PDUBuffer

MUX

SetPoll Bit

MAC

ForwardChannel

Receiver

ReverseChannel

StatusReport

PollTriggers

PDURequest

Fig. 1 Simulation block diagram

The simulation details are illustrated in Fig. 1. The transmitting side includes a Traffic module which can generate the incoming traffic. The incoming traffic packets are stored as SDUs in the SDU Buffer. These SDUs are then segmented or concatenated into PDUs, added RLC header, and stored in the New PDU Buffer. Padding of PDU is switched off. In addition to the New PDU Buffer, there is a Retransmission PDU Buffer. 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 Buffer 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 Buffer and placed in the Retransmission PDU Buffer 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

3347

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 Buffer, 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 delay1 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: 64 kbps and 384 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 [3] 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 23 and standard deviation of 166. The think time between packet calls is modeled by a Gamma distribution with mean of 26 seconds and standard deviation of 134 seconds. Packet:

1 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 102.75 ms. The number of packets per packet call is Pareto distributed with mean of 30.

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 1.

TABLE 1 Simulation Parameters Parameter Assumption

SDU Traffic model Web browsing Physical layer

channel UMTS link level results

RLC Block error rate 8.3% RLC PDU 40 bytes

TTI 20 ms Service Rate (PDUs

per TTI) 64 kbps or 384 kbps (4 or 24

PDUs per TTI) Tx_Window_Size 2047 Rx_Window_Size 2047

SDU Discard function

Timer based discard

Round Trip Delay 200 ms

3348

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. 2 and Fig. 3 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 2 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 50% from polling every 1 SDU to polling every 10 SDU. The delay performance also degraded with the increase of polling interval. The average packet call delay increases about 25% from polling every 1 SDU to polling every 10 SDU.

Packet Call Throughput

00.5

11.5

22.5

33.5

44.5

5

0 2 4 6 8 10

Poll_SDU

Kby

tes/

s

With Last PDU Triggers

Without Last PDU Triggers

Fig. 2 Comparison of packet call throughput with different

polling mechanisms

It is interesting to notice that with the two “last PDU” triggers, the performance degradation is not that much with large value of Poll_SDU, 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 Poll_SDU.

It is evident that frequent polling improves the performance. However it generates status reports which occupy the reverse link bandwidth. Fig. 4 shows the status report overhead versus different Poll_SDU. With the “poll every Poll_SDU” trigger alone, the status report overhead drops from 4% to 0.45% with polling interval of 1 SDU to 10 SDU. In conjunction of the “last PDU” polling triggers, the status report overhead drops from 5.3% to 1.6% 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 4 SDU.

Packet Call Delay

0500

10001500

20002500

30003500

40004500

5000

0 2 4 6 8 10Poll_SDU

ms

With Last PDU Triggers

Without Last PDU Triggers

Fig. 3 Comparison of packet call delay with different

polling mechanisms

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. 5 shows the SDU discard rate versus different polling interval. It is shown that the SDU discard rate increases from 12% to 27% with polling interval of 1 SDU to 10 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 Poll_SDU of 10.

Status Report Overhead

0

1

2

3

4

5

6

0 2 4 6 8 10Poll_SDU

%

With Last PDU Triggers

Without Last PDU Triggers

Fig. 4 Comparison of status report overhead with different

polling mechanisms

SDU Discard Rate

0

0.05

0.1

0.15

0.2

0.25

0.3

0 2 4 6 8 10Poll_SDU

With Last PDU Triggers

Without Last PDU Triggers

Fig. 5 Comparison of SDU discard rate with different

polling mechanisms

3349

Effect of SDU discard timer Next we evaluate the effect of SDU discard function on the

performance. Fig. 6 to Fig. 9 shows the performance results with different discard timer thresholds: 2 and 4 seconds. We can see that the throughput does not change much with different discard timer values. The status report overhead also remains the same2. However, the packet call delay increases from around 3.7 seconds to 4.2 seconds, more than 10% increase. The reason is that with the current traffic loading and 64 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 4% to 7%. With polling every SDU, the SDU discard rate is around 12%.

Packet Call Throughput

0

1

2

3

4

5

6

7

8

0 2 4 6 8 10Poll_SDU

Kb

ytes

/s

64K 2 sec Discard Timer

64K 4 sec Discard Timer

384K 4 sec Discard Timer

Fig. 6 Comparison of packet call throughput with different

discard timer values, and service rates.

Packet Call Delay

0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 2 4 6 8 10Poll_SDU

ms

64K 2 sec Discard Timer

64K 4 sec Discard Timer

384K 4 sec Discard Timer

Fig. 7 Comparison of packet call delay with different

discard timer values, and service rates.

Effect of service rate In these figures, we also examine the RLC performance

with a higher service rate, 384 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

2 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 384 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

0

1

2

3

4

5

6

0 2 4 6 8 10Poll_SDU

%

64K 2 sec Discard Timer

64K 4 sec Discard Timer

384K 4 sec Discard Timer

Fig. 8 Comparison of status report overhead with different

discard timer values, and service rates.

SDU Discard Rate

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 2 4 6 8 10

Poll_SDU

64K 2 sec Discard Timer

64K 4 sec Discard Timer

384K 4 sec Discard Timer

Fig. 9 Comparison of SDU discard rate with different

discard timer values, and service rates.

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

[1] 3GPP TS 25.322 v3.5.0, “RLC protocol specification”. [2] 3GPP TS23.321, “MAC protocol specification”. [3] Lucent Internal document, “UMTS Specific Traffic Model”.

3350