A Statistical Estimation of Average IP Packet Delay
in Cellular Data Networks
Hubert GRAJA, Philip PERRY and John MURPHY
Performance Engineering Laboratory, Computer Science Department,University College Dublin, Dublin 4, Ireland {grajah,perryp,murphyj}@eeng.dcu.ie
Abstract— A novel technique for estimating the average delay experienced by an IP packet in cellular data networks with an SR-ARQ loop is presented. This technique uses the following input data: a statistical description of the radio channel, ARQ loop design parameters and the size of a transported IP packet. An analytical model is derived to enable a closed form mathematical estimation of this delay. To validate this model, a computer based simulator was built and tests showed good agreement between the simulation results and the model. This new model is of particular interest in predicting the packet delay for conversational traffic such as that used for VoIP applications.
Index Terms— ARQ, IP packet delay, wireless QoS, mobile multimedia
I. INTRODUCTION
Wireless networks and cellular data networks in particular have become a significant Internet access technology. The first widely deployed cellular data network, the General Packet Radio Service (GPRS), offers relatively small bandwidth of about 50 kbps. However, upcoming technologies like Enhanced General Packet Radio Service (EGPRS) and Universal Mobile Telephone Service (UMTS) will offer much higher throughput to try to satisfy user demands for browsing the Internet and sending files between remote places [4], [11]. Nevertheless, customers’ demands will grow with time and eventually it is expected that streaming or conversational traffic will be transmitted over cellular data networks [5], [9]. These two traffic classes are quite demanding in terms of network delay performance, so, some Quality of Service (QoS) techniques to improve this need to be implemented.
The conversational traffic of Voice over IP (VoIP) in par-ticular is characterized by a small IP packet size with a low tolerance to delay. It seems that any QoS mechanism having a delay oriented approach should focus on the delay of an IP packet, but, this is not the case in current cellular data networks. Due to the fragmentation of a VoIP packet into a number of radio blocks, it is difficult to analyze the delay performance of IP packets. A number of publications address the issue of radio block throughput and delay [10], [1], [2], however it cannot be easily extended to the delay of the entire IP packet.
Streaming and other time-sensitive traffic types would benefit from having a knowledge about the expected delay of its packets. Thus, the applicability of our work is not limited to
The support of both the Research Innovation Fund (RIF) and the Advanced Technology Research Programme (ATRP) from the Informatics Research Initiative of Enterprise Ireland is gratefully acknowledged.
VoIP traffic only, but rather, VoIP is chosen as the test load due to its critical delay demand.
Modern cellular systems consist of two main parts: the IP core network, with all additional services inherited from the GSM standard, and wireless elements, dealing with radio transmission related issues. Hence, the delay analysis of IP packets may be split into two sub-domains, delay in the IP core network and delay in the wireless part. The analysis of the delay caused by the wireless part of cellular systems is the focus of this paper.
The contribution of the wireless part to the delay of an IP packet, under a certain radio condition, depends mainly on the performance of two layers: Medium Access Control (MAC) and Radio Link Control (RLC). The MAC schedules the access to the radio resources while the RLC focuses on assuring a good radio link quality between a transmitter and a receiver. There is a huge number of publications addressing the influence of the MAC protocol on throughput and delay issues [12], [6]. Simply speaking, more frequent access to the radio channel yields better throughput and delay performance for a particular user.
The RLC on the other hand, has to assure the best possible use of a current radio channel. It comprises a set of Link Quality Control (LQC) techniques, which use Forward Error Correction (FEC) and Backward Error Correction (BEC) techniques to improve throughput and reliability of a particular connection [7], [8]. Additionally, in some advanced systems, like EGPRS, LQC may also adjust the modulation scheme.
One of the most widely used BEC techniques is Selective Repeat Automatic Repeat reQuest (SR-ARQ). This technique is superior to other BECs in terms of throughput, however, the delay aspect of SR-ARQ is its main drawback. Retransmitted radio blocks introduce additional delay to the transmitted IP packets. In addition, the retransmitted radio blocks occupy bandwidth which could be used for transmission of the other radio blocks.
It is difficult to improve the delay aspect without degrading the reliability of the transmission and this is not the goal of this paper. Instead, our aim is to find a technique to predict the SR-ARQ delay behavior. So, having a description of the traffic, the radio channel and the SR-ARQ loop design, we want to be able to forecast the delay of transmitted IP packets in a delay sensitive data stream. This information can then be used by other layers to adapt their behavior in order to try to maintain an agreed QoS level.
Due to architectural reasons, all IP packets are queued at the Logical Link Control (LLC) buffer and are send one by one to the RLC. Such queuing occurs at the LLC when the packet arrival rate is greater than the service rate. The delay sensitive traffic considered here can only tolerate such a circumstance for very short periods of time. So, the LLC queuing delay is set to zero here.
The paper is organized as follows: in Section II the analysis of the transmission of IP packets over a wireless network together with the methodology of IP packet delay analysis is presented, while in Section III the delay estimation algorithm is proposed. Section IV presents the results, being a comparison between the output from computer simulation and analytical calculation. Finally in Section V the main conclusions are expressed.
II. IPPACKET DELAY ANALYSIS METHODOLOGY[3] In order to chose the methodology of analysis of IP packet delay it is necessary to examine the nature of the process being investigating. Having QoS issues in mind for traffic that demands low delays, it seems that knowledge about an average delay of transported IP packets is the most important question to be answered. Consequently, the analysis of the average delay of an IP packet being transmitted by a cellular data network is our main aim.
The process of transporting IP packets over the wireless part of the cellular networks relies on the protocol stack’s structure. As shown on Figure 1, the wireless protocol stack consists of the following parts: LLC, RLC, MAC and the Physical Layer (PHY).
Firstly, every IP packet is mapped into an LLC frame - in the case studies here, each packet fits into one LLC frame, hence, the LLC layer influence is omitted from this study. Next, each LLC frame is fragmented into a number of radio blocks. The number of radio blocks required to transmit one LLC frame depends on the Modulation and Coding Scheme (MCS) used and the size of the particular packet.
At the next step, the radio blocks are queued at the MAC and wait for access to the radio channel. In already deployed sys-tems, GPRS has only one available MCS for data transmission, while EGPRS uses the Incremental Redundancy (IR) technique, which again uses only one MCS. In these cases the IP packet delay in the radio part will be dominated by the number of times that its constituent blocks need to be retransmitted before decoding. Following that, a radio block is transmitted to a receiver through the PHY layer.
To separate the delay caused by the RLC from that caused by the MAC, the MAC’s dynamical influence on the transmission rate has been omitted from this study. Instead, it is assumed that every user has a fixed policy of obtaining access to the radio resources - in the case of GPRS it will be a fixed number of time-slots shared fairly with other users. This approach allows the RLC influence to be studied in isolation and allows the possible future development of MAC strategies that can compensate for these effects.
IP
LLC
RLC
MAC
PHY
Mapping IP packet into LLC frame(s)
Segmentation of LLC frame into a number of radio blocks
Assigning radio blocks to relevant frequency and timeslot
Sending a radio block, bit by bit ,over a radio channel Introducing the coding (FEC) and ARQ (BEC) to the radio blocks
Tx Rx
Fig. 1: Typical cellular networks’ protocol stack
The influence of the PHY layer on the transmission process is a more complex problem and is normally focused on modeling Bit Error Rates. However, due to the FEC mechanism imple-mented in the RLC it seems that the PHY can be considered here as an entity for transporting radio blocks and having its own radio block error characteristic, dependent on the radio channel condition and chosen MCS.
So, in summary:
1) LLC influence is omitted
2) RLC influence is analyzed and it is the main topic of this methodology
3) MAC influence is neglected
4) PHY influence is considered at the radio block level The SR-ARQ technique assures high reliability data trans-mission over an errored channel by repeating the transtrans-mission of radio blocks that have not successfully reached the receiver. The transmitter sends a few radio blocks to the receiver and after a period of time, determined by the transmission window size, expects to get a report from the receiver telling which radio blocks were successfully transmitted and which were not. The size of the transmission window is denoted by NP oll. When
the report is received, the transmitter sends again those radio blocks that have been errored. This improves the reliability of the connection, however, it introduces additional delay to transmitted radio blocks. The delay associated with the first retransmission does not have to be the same as the delay associated with the second retransmission attempt. Therefore instead of one number describing the delay, a vector of delays, called ∆, is introduced. This vector represents the additional average delay associated with the first, second, third and error transmission attempt, δ1,δ2,δ3,δe, respectively.
∆ = δ1 δ2 δ3 δe (1)
Selecting an appropriate level of modeling accuracy of the PHY layer is crucial to this work as a bit based model is overly cumbersome for our purposes. Even modelling the PHY as a simple Block Error Rate (BLER) is not a sufficient solution if more advanced BEC, in the form of Hybrid Type-II or ”Incremental Redundancy” (IR), is deployed. In IR, the receiver combines information from all transmission attempts, so that the first transmission attempt has less chance of success than the second and third one. Hence, the BLER is different for each transmission attempt. Thus, we allow a different BLER for first, second and third transmission attempt by counting the number of radio blocks successfully received at the first, second and third attempt. This data gives a statistical description of the channel from a radio block perspective, which simplifies and generalises the methodology. The probabilities vector is denoted byP and has the following form:
P = p1 p2 p3 pe (2)
Where its elements: p1,p2,p3,pe represent the probability
of successful transmission of a certain radio block at the first, second, third attempt or unsuccessful transmission after the third try, respectively.
The pe represents the probability of error after three
trans-mission attempts andδe is the additional delay related to such
a scenario. However, this paper does not address the issue of reliability, so it is assumed that pe is small enough to be
considered to be zero. Therefore, δe is assumed to be zero
valued.
The methodology chosen then uses the following input information:
• Traffic is described by the size of a single IP packet, being transported in the data stream, denoted by IPsize. The
stream contains packets with fixed size as a result of the assumption that VoIP, as an example of Conversational traffic, is the traffic source.
• ARQ loop design is described by a vector of extra delay associated with each transmission attempt, called∆. This vector stores information about the extra delay experienced by a radio block if retransmission is necessary. This time covers the period between the recognition of a failed trans-mission at the receiver and the subsequent retranstrans-mission attempt at the transmitter.
• Radio channel influence is represented by a vector of probabilities of successful transmission at the first, second, third time and probability of non-successful transmission, namedP . The number of transmission attempts is limited to three, due to the assumption that conversational traffic is
being transported. This class of traffic is characterized by strict delay limits. Therefore, further transmission attempts would occupy radio resources without any additional ben-efit, as the delay would be too large for a VoIP packet to be played out by the application layer.
Having the problem defined in this way,a computer simula-tion model has been built as shown in Figure 2. The simulasimula-tions generated a series of statistics that are used for comparison purposes to validate the results from the IP packet delay estimation technique that will now be presented.
Y ... 2 1 Y ... 2 1 IP[x-4] IP[x-3] IP[x-2] IP[x-1] Point A Point B ARQ loop IP[x+4] IP[x+3] IP[x+2] IP[x+1] Point C IP packet delay Stream of IP packets with equal size
Tx Rx
Transmission buffer Service queue
Y ... 2 1 e d 3 d 2 d 1 d ds pe p3+pe p2+ p3+pe p1+p2+p3+pe
Fig. 2: Methodology description model
III. PROPOSAL OFIPDELAY ESTIMATION TECHNIQUE
Considering the IP packet delay mechanisms presented above, the process of transportation of an IP packet is as follows. First an IP packet is mapped into a number of radio blocks. The number of radio blocks, called Y, depends on the relationship between the size of the packet, IPsize, and the
payload size of selected MCS, RBP ayloadsize, as shown in
equation 3. Y = IPsize RBP ayloadsize (3) After mapping the packet into this number of radio blocks, these blocks are sent to a receiver over the radio channel. Some of them successfully reach the receiver at the first transmission attempt, but a fraction of these Y radio blocks have to be transmitted two or three times before being successfully received. This creates the situation where3Y different IP packet
transmission scenarios exist. Consequently, the following ques-tions come up:
1) How to mathematically describe all possible scenarios? 2) What is the probability of a particular scenario
happen-ing?
3) What IP packet delay is expected for a particular sce-nario?
A. The mathematical representation of all scenarios
The mathematical representation of all possible scenarios chosen here is a matrix, named R. Each row, denoted by ’i’, represents one possible transmission scenario, the columns, denoted ’j’, show the order of radio blocks in the transmission buffer. Each element takes the value of the number of trans-mission attempts associated with the specific radio block within each scenario. Hence the matrix has the following form:
R = r1,1 r1,2 · · · r1,Y r2,1 r2,2 · · · r2,Y .. . ... . .. ... r3Y,1 r3Y,2 · · · r3Y,Y (4) Where:
• ri,j represents the number of transmission attempts
ex-perienced by the j’th radio block of the i’th possible transmission scenario. In the case of a retransmission free scenario, allri,j of a particular ’i’ will be equal to one. • i ∈ 1, 2, 3, · · · , 3Y represents one of the 3Y possible
scenarios of transporting an IP packet which has a size of Y radio blocks.
• j ∈ {1, 2, 3, · · · , Y } represents the position of the radio block in the transmission queue, in the i’th transporting scenario.
B. Probability of different scenarios
Knowing all possible scenarios, we can now create a vector of order 3Y, denoted by S, that stores the probabilities of occurrence for each scenario. The probability of the i’th trans-mission scenario occurring is the product of the probabilities of successful transmission of all its constituent radio blocks.
The probabilities of successful transmission of a radio block at a particular attempt is stored in the vectorP , which is one of the initial parameters. However, these probabilities have to be linked appropriately with the status of a particular radio block. Therefore, the matrixR, is used to determine the number of transmission attempts associated with this particular radio block. Consequently, each element of R is an index of an element of vectorP . Hence, S has the following form:
S = s1 s2 .. . s3Y (5) Where: • si = Y j=1pri,j
represents the probability that i’th constel-lation of radio blocks will occur during the transmission of IP packet.
C. Delay associated with different scenarios
When the IP packet is fragmented into radio blocks, these radio blocks are sent to the transmission buffer where they wait for access to the radio channel. The scale of the associated
queuing delay depends on the position of a radio block in the transmission buffer, as the last radio block has to wait at least Y-1 time-slots to be transmitted while the first radio block experiences zero delay. Secondly, the retransmission of errored blocks will not be performed instantaneously and the radio block will experience some additional delay related to this phenomena. Finally, the radio block with a larger number of transmission attempts has a higher priority to obtain access to the radio resources, in comparison to a radio block with a lower number of transmission attempts. This priority mechanism prevents dead lock situations from happening, yet, it postpones the transmission of all radio blocks queuing in the transmission buffer. These three phenomena have different effects on the total delay of transported IP packet.
Starting with the representation of the total delay. Since all possible scenarios have to be considered, the natural represen-tation of the total delay is a vector that stores delays for every possible constellation of Y radio blocks. The vector size is3Y and the row index ’i’ indicates a particular scenario. Thus,
∆T otal = δT otal 1 δT otal 2 .. . δT otal 3Y (6) Where:
• δT otali represents the delay of an IP packet when its radio
blocks have experienced the transmission attempt scenario stored the i’th row of theR matrix.
The radio blocks queuing in the transmission buffer expe-rience a delay that is determined by the place of a particular block in the queue. Consequently, the delay associated with this phenomena, denoted by δi,js , is equal to the index of the
radio block decremented by 1, since the delay of the first radio blocks is zero. Hence,δsi,j= j − 1.
The process of sending a request for the retransmission of errored transmitted radio blocks takes time and this delay has to be taken into the account as well. The data to model this problem is stored in the vector∆. If a radio block is transmitted once, then it experiences a delay of δa
1 = δ1+ δs, whereδs
represents the time necessary for the medium for a successful transmission. This time is normalised to one, and any other delay is expressed as a multiple of it. For higher number of the transmission attempts the situation looks the following: δa
2 = δa 1+ δ2+ δs,δa3 = δ2a+ δ3+ δs,δae = δ3a+ δe. ∆a = δa 1 δa 2 δ3a δea (7)
The vector∆atherefore represents the accumulated influence
of the retransmission delay on the radio blocks being transmit-ted once, twice, etc..
Having this vector, it is easy to find the delay of radio blocks caused by the non-instantaneous retransmission phenomena.
For a particular transmission scenario, indicated by ’i’, and a particular radio block labeled by ’j’, we can find the associated number of transmission attempts, ri,j. Hence, by linking the
number of transmission attempts with the relevant delay asso-ciated with it, we can obtain the retransmission influence on the delay of the considered radio block. Thus,δr
i,j = δrai,j.
To combine the influence of these two phenomenon on the total IP packet delay, let’s create a matrix, denoted by Dt,
representing the sum of these delays. Accordingly, the element of this matrix isδi,jt = δsi,j+ δri,j.
Dt= δt 1,1 δ1,2t · · · δ1,Yt δ2,1t δ2,2t · · · δ2,Yt .. . ... . .. ... δt 3Y,1 δ3tY,2 · · · δt3Y,Y (8)
The last radio block to reach the receiver effectively deter-mines the total delay of a particular IP packet. Thus, if each row of the matrixDtis searched for the largest element, then this element represents the delay of the last radio block related to the i’th transmission scenario. Let’s create a vector∆M ax−row−t storing these delays.
∆M ax−row−t= δ1M ax−row−t δ2M ax−row−t .. . δ3M ax−row−tY (9) Where:
• δiM ax−row−tis the maximum value from the ith row of
theDtmatrix.
In the case where the retransmitted radio blocks compete for access to the radio resources with the radio blocks in the transmission buffer, they slow down other radio blocks.
Retransmission of a radio block has priority access, and takes one slot, thus, the entire IP packet is slowed by one time-slot. Moreover, in the case of a radio block experiencing two retransmission attempts, which is equal to three transmission attempts, the IP packet is slowed by two time-slots. Hence, knowing the number of transmission attempts of a particular radio block, the influence of this radio block on the IP packet transmission delay can be calculated.
Since every radio block causing the priority stop will slow down the entire transmission of the packet, the influence of all such radio blocks needs to be accumulated. Therefore, the following vector, named ∆Sum−q, storing this accumulated
delay caused by priority retransmission is created:
∆Sum−q = δ1Sum−q δ2Sum−q .. . δ3Sum−qY (10) Where: • δiSum−q= Y j=1 (ri,j− 1)
These different contributions can now be combined to find a technique of calculating∆T otal vector.
Now, by adding the vector ∆M ax−row−t, to the vector
∆Sum−q the total delay for each possible transmission case
is obtained.
∆T otal= ∆Sum−q+ ∆M ax−row−t (11)
D. Main formula
Since vectors S and ∆T otal are defined and can be
calcu-lated, then the average delay of the transported IP packet can be computed as well. It is done by calculation of the weighted average of delays of all possible scenarios. Thus, the final formula looks like:
delayIP −packet= 3Y i=1 δiT otal· si (12) IV. RESULTS
Since the formula allowing for analytical calculation of the estimation of average IP packet delay is known, the comparison of results obtained from simulation and calculation is required for validation. Simulation results come from the system that was built in a general purpose simulator environment, called SES workbench, and is shown in Figure 2. The simulations are made with the same values ofP , ∆ and IPsizeas the relevant
calculation. For space reasons, all vectors in the result section are expressed in the transposed form.
The results shown below represent simulations and calcula-tions for the following settings:
• IP packet size, IPsize, varying in the range of 1 to 12
radio blocks, with 10,000 transmissions performed for each packet size.
• The P vector is represented in five forms, and each of them represents a different radio channel condition. The first case, called T0, represents a situation where only 10 percent of radio blocks have to be retransmitted, while cases T1, T2, T3 and T4 represent worsening retransmis-sion scenarios.
1) T0 - P = [0.9; 0.07; 0.03; 0.0]T, which means that we assume that 90 percent of radio blocks will reach the receiver at the first transmission attempt, 7 percent at the second attempt, and 3 percent at the third attempt. The last position is zero and it indicates that in this scenario there are no errors experienced by any of the radio blocks after the second retransmission. The other cases, T1 to T4, can be interpreted in the same way.
2) T1 - P = [0.6; 0.3; 0.1; 0.0]T 3) T2 - P = [0.3; 0.4; 0.3; 0.0]T 4) T3 - P = [0.1; 0.3; 0.6; 0.0]T 5) T4 - P = [0.03; 0.07; 0.9; 0.0]T
Using a memoryless receiver, it is expected to see a relation between the transmission attempts looking like: p1, p2 = p1∗ p1 and p3 = p1∗ p1∗ p1. However, soft
decoding, and Incremental Redundancy (IR) in particular, breaks this relationship. Nevertheless, the case T4 may still look unrealistic, but, it is expected that the progress in cod-ing theory may cause very different relationship between following transmission attempts. Thus, for underlining the generality of our method, the different configurations of theP vector have been investigated.
• ∆ = [0; 8; 13; 0]T, which means that it is assumed that the delay is caused by the interaction between the ARQ system and lower level transmission delays. This vector represents the design of the SR-ARQ loop, and here it is assumed that the Transmission WindowNpoll, is set to 10 radio blocks.
The zero means that the first transmission of a radio block experiences only the delay caused by queuing in the RLC layer and the transmission delay is one block period. The eight represents the time necessary for the ARQ feedback for the first radio block retransmission and is composed of one block period for reception and decoding, five block periods as the average occupancy of the polling buffer at the receiver, another block period is required for the return of the ACK message and another block period for reception and processing at the transmitter. The thirteen represents the time delay due to the feedback delay for the second retransmission which is similar to that of the first retransmission, except that this block was errored during the last polling period so that it will have been inserted at the head of the transmission queue. It will, therefore, be the first errored block in the polling buffer at the receiver, so that its polling buffer delay will be equal to the full length of that queue, rather than its mean occupancy. Zero in the last position indicates that in this scenario there is no delay due to the error of radio block after the second retransmission. 0 10 20 30 40 50 60 70 0 2 4 6 8 10 12
Delay [radio block periods]
IP packet size [radio blocks] Sim for T0 Calc for T0 Sim for T1 Calc for T1 Sim for T2 Calc for T2 Sim for T3 Calc for T3 Sim for T4 Calc for T4
Fig. 3: Simulated and calculated average IP packet delay vs its size for five different settings ofP vector.
The results, shown in Figure 3, indicate that the proposed methodology performs very well in all cases. Interestingly, for the cases representing high levels of retransmission, T3 and T4, the proposed technique overestimates the average delay of small IP packets, between one and four blocks long, while for larger packets the technique underestimates the delay. This phenomena distinguishes the last two cases from the first three, where the error is an offset having a different value.
Since it is unlikely that the system will transport data under heavy retransmission conditions, it seems likely that real-life scenarios will be somewhere between case T0 and T3. Thus, the general accuracy of the introduced method is good, as the difference between simulation and calculation is less than 2 radio block periods for cases T0, T1, T2 and T3.
V. CONCLUSIONS
A novel technique for the statistical estimation of the average delay of IP packets transported over a wireless channel with an SR-ARQ loop is proposed. This method represents a practical approach since the data required for the vectors∆ and P may be easily collected in real-time.
The accuracy of the technique is assessed by comparison to a simulation with identical system architecture. The results of this comparison are promising, as the differences between simulation and calculation are marginal. The highest error is experienced for an exceptionally high ratio of retransmissions, case (T4), although for low and medium retransmission levels the error introduced by the proposed technique is small.
Since the size of the matrices used here grow exponentially with the size of the transported IP packet, the practical use of the proposed technique is limited to small packets. Further work will address the issue of large IP packet size.
The values of delay analyzed in this work represent the most optimistic scenario, as, queuing at the LLC buffer and core IP network delays are not considered. Additionally, each cellular network has its own protocol mechanisms that may affect the delay. For example, the time unit in GPRS/EGPRS is 20 ms, while in UMTS it is 10 ms. That simple issue greatly affects the delay of IP packets. If the RLC delay budget is 100ms, then from case T0 in Figure 3, VoIP packets in GPRS/EGPRS must have less than two radio blocks, while in UMTS the packets can be greater than four radio blocks long. Thus, UMTS can send higher quality VoIP than GPRS/EGPRS within the same delay budget and independent of the higher bandwidth offered by UMTS.
The knowledge about the RLC influence on the IP packet can be passed into the MAC. It can enrich the performance description of a channel, since the MAC may have access to the C/I and BLER statistics that represent a bit and radio block level of performance description. Therefore, the MAC can have a better radio channel description and may use more advanced scheduling algorithms to deliver better Quality of Service. The IP packet predicted delay performance may be passed as well to higher protocol layers, and be used by the Radio Resource Management unit (RRM) or even higher by some application layer adaptation mechanisms.
REFERENCES
[1] M. E. Anagnostou and E. N. Protonotarios, “Performance analysis of the Selective Repeat ARQ protocol,” IEEE Transactions on Communications, vol. 34, no. 2, pp. 127 – 135, February 1986.
[2] H. Bruneel and M. Moeneclaey, “On the throughput performance of some continuous ARQ strategies with repeated transmissions,” IEEE
Transactions on Communications, vol. 34, no. 3, pp. 244 – 249, March
1986.
[3] H. Graja, P. Perry, and J. Murphy, “A statistical analysis of IP packet delay and jitter in cellular networks,” in in press IEEE PIMRC, Barcelona,
Spain, September 2004.
[4] T. Halonen, J. Romero, and J. Melero, GSM, GPRS and EDGE
Perfor-mance: Evolution Toward 3G/UMTS, First ed. John Wiley & Sons, Ltd,
2002.
[5] H. Holma and A. Toskala, WCDMA for UMTS Radio Access for Third
Generation Mobile Communications, First ed. John Wiley & Sons, Ltd,
2000.
[6] P. Hosein, “Data throughput model for CDMA2000 supplemental chan-nels,” in IEEE Wireless Communications and Networking Conference,
New Orleans, Louisiana, USA, vol. 4, no. 1, March 2003, pp. 502 – 507.
[7] S. Lin, D. J. C. Jr., and M. J. Miller, “Automatic-Repeat-reQuest error-control schemes,” IEEE Communications Magazine, vol. 22, no. 12, pp. 5 – 17, December 1984.
[8] H. Liu, H. Ma, M. E. Zarki, and S. Gupta, “Error control schemes for networks: An overview,” Mobile Networks and Applications, vol. 2, no. 2, pp. 167–182, 1997.
[9] H. Liu and M. E. Zarki, “Performance of H.263 video transmission over wireless channels using Hybrid ARQ,” IEEE Journal on Selected Areas
in Communications, vol. 15, no. 9, pp. 1775–1786, December 1997.
[10] D.-L. Lu and J.-F. Chang, “Performance of ARQ protocols in noninde-pendent channel errors,” IEEE Transactions on Communications, vol. 41, no. 5, pp. 721 – 730, May 1993.
[11] N. Shankaranarayanan, Z. Jiang, and P. Mishra, “Performance of a shared packet wireless network with interactive data users,” Mobile Networks and
Applications, vol. 8, no. 3, pp. 279–293, June 2003.
[12] Y.Cao, H.R.Sun, and K.S.Trivedi, “Performance analysis of reservation Media-Access protocol with access and serving queues under bursty traffic in GPRS/EGPRS,” IEEE Transactions on Vehicular Technology, vol. 52, no. 6, pp. 1627–1641, December 2003.
