Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
An Analysis of VoIP Service Using 1 EV-DO

An Analysis of VoIP Service Using 1 EV-DO



|Views: 220|Likes:
Published by api-3699476

More info:

Published by: api-3699476 on Oct 17, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





An Analysis of VoIP Service Using 1 EV-DO
Revision A System
Qi Bi, Senior Member, IEEE, Pi-Chun Chen, Yang Yang, and Qinqing Zhang, Senior Member, IEEE
Abstract\u2014While voice-over-Internet protocol (VoIP) on wireline

network is maturing, VoIP on wireless mobile network is still in its infancy. This disparity is due to the fact that the wireline band- width is abundant and can be traded off for delay performance and overhead, whereas bandwidth in wireless mobile network is still a scarce resource. With the deployment of 1EV-DO revision 0 (DOr0) worldwide, the spectrum ef\ufb01ciency has been signi\ufb01cantly improved. However, DOr0 still lacks of features essential for VoIP. For this reason, 1EV-DO revision A (DOrA) has been standard- ized in the 3GPP2 with many improvements favorable for VoIP implementation. In this paper, we identify challenges and explore the feasibility of implementing VoIP using DOrA. We develop both analytical and simulation models to evaluate the VoIP capacity and delay performance over the air interface.

Index Terms\u2014Air interface capacity, CDMA2000, voice-over-
Internet protocol (VoIP), wireless communication, 1EV-DO.
OICE-over-Internet protocol (VoIP) has made consider-

able progress in wireline networks in the last decade [1], [2]. VoIP in wireless has drawn much interest recently because of the convergence of all IP architecture in wireless and wireline networks. Initial VoIP efforts [3], [4] were focused on the wire- less local area networks (LANs) since the achievable data rate is close to that of the wireline network. Call admission and band- width allocation are designed to support large voice capacity and to meet the delay requirements.

Despite the success of VoIP in wireline and wireless LAN net- works, little progress was made on wireless cellular networks. This is because VoIP implementation adds considerable IP and other overhead, which decreases spectral ef\ufb01ciency. In addi- tion, VoIP service requires stringent end-to-end quality-of-ser- vice (QoS) support that is not yet available to ensure the tight delay constraint. With the deployment of 1EV-DO revision 0 (DOr0) [5], [6] worldwide, the spectrum ef\ufb01ciency for wire- less mobile data applications has been signi\ufb01cantly improved. However, DOr0 still lacks the capabilities essential to VoIP im- plementation. Recognizing this, 1EV-DO revision A (DOrA) [7] has been standardized with many improvements favorable to VoIP implementation.

In this paper, we explore the possibility of implementing VoIP using DOrA. We identify the challenges that hinder the imple- mentation of VoIP on wireless network in general, and inves- tigate possible solutions to meet these challenges. We develop

Manuscript received October 7, 2004; revised June 3, 2005.

The authors are with Bell Laboratories, Lucent Technologies, Whippany, NJ 07981 USA (e-mail: qbi@lucent.com; pc2000@lucent.com; yyang7@ lucent.com; qinqing@lucent.com).

Digital Object Identi\ufb01er 10.1109/JSAC.2005.858882

simulation and analytical models to evaluate the expected per- formance including voice capacity and resultant delays when VoIP is implemented using DOrA.


When VoIP is implemented using DOrA, the coverage, ca- pacity, and voice quality should be similar to that provided by the CDMA2000 system. These requirements present challenges to system designs. In this section, we examine some of the so- lutions and establish assumptions, design criteria, and the resul- tant system model to facilitate the analysis that follows.

A. Speech Coder and Silence Suppression

In this paper, we assume that an enhanced variable rate codec (EVRC) speech coder [8] is used for VoIP. The EVRC speech encoder generates frames with four variable data rates, i.e., full, 1/2, 1/4, and 1/8 rate, with the probabilities of 38%, 5%, 0%, and 57%, respectively. Further, silence suppression is assumed by not or rarely transmitting the 1/8 rate packets, resulting in a 43% voice activity factor.

B. IP and Other Packet Overhead

For VoIP applications, voice frames have to be placed into IP packets. The added protocol overhead represents an in- tolerable amount of spectral inef\ufb01ciency for wireless mobile networks. For this reason, IP header compression is necessary. Header compression algorithms have been standardized for CDMA2000 network and DOrA. We assume that header com- pression is utilized for both forward link (FL) and reverse link (RL). To demonstrate the importance of header compression, consider a full rate EVRC frame that has 171 bits. Together with 24 cyclic redundancy bits and six coding tail bits, the total payload is 201. Without header compression, the overhead will be about 360 bits, which is more than the payload, reducing the spectral ef\ufb01ciency signi\ufb01cantly. If the header compression is designed in such a way that all overhead including IP overhead can be \ufb01t into 55 bits, the encoder packet size will be 256 bits, resulting in an overhead of only 33% when compared with circuit-switched voice frame.

C. End-to-End QoS Support

To ensure end-to-end QoS in a packet-switched network, a series of features have been de\ufb01ned in DOrA to meet the need for different applications. Main QoS support can be categorized into two categories: signaling mechanisms [9] to support the call features similar to the current cellular voice calls, and trans- port mechanisms [10] to meet comparable quality of the cellular

0733-8716/$20.00 \u00a9 2006 IEEE

voices. The end-to-end QoS framework for DOrA is currently under standardization by 3GPP2. In this paper, we assume that the QoS architecture and mechanism [11], [12] are in place to differentiate the VoIP\ufb02ow from other applications.

D. FL Multiple Packet Size Support

In DOr0 [5], each requested data rate is associated with only one packet size. When the sector schedules a packet, it must transmit the speci\ufb01c packet size corresponding to the mobile requested data rate regardless of the data backlog situation. As- sume that a mobile is at a good RF location and indicates that a high data rate corresponding to 4096-bit packet size can be used. Since VoIP is a low data rate service, only a few hun- dred bits will be in the buffer at each transmission. In this case, the scheduler will have to pad the rest frame till 4096 bits. This mismatch causes inef\ufb01cient use of FL RF resource. DOrA has the improvement by de\ufb01ning multiple packet sizes associated with each requested data rate. The shorter packets have stronger channel coding structure and, hence, better performance. The sector has the\ufb02exibility to choose a packet size to match the data backlog and reduce the packet transmission delay.

E. FL Packets Multiplexing From Multiple Users

The DOr0 system is optimized to support a small number of users downloading large amounts of data from the network. For VoIP, this assumption is violated since there might be many users transmitting at a very low data rate. For example, an EVRC speech coder generates 50 packets/s, and there are a total of 600 time slots per second on the FL. Therefore, each sector can only support less than 12 VoIP users if each voice packet needs to be transmitted within a 20 ms delay.

To overcome the shortage of time slots, DOrA introduces a multiuser packet (MUP) feature that allows packets from up to eight users to be packed into a single physical-layer packet. The decision to transmit a MUP is dynamically made by the sector on a packet-by-packet basis. Considering a VoIP packet, a MUP packet of 1024 bits can practically accommodate up to four-user packets, while MUP of larger sizes can support a maximum of eight packets. Since certain data rates only support MUP packets up to 1024 bits, it presents a practical limit of four-user MUP packets capacity. In addition, a user\u2019s data rate needs to be at least 153.6 kb/s to qualify for any MUP operation. At lower rate, only a single-user packet (SUP) can be transmitted.


One of the major improvements of DOrA over DOr0 is the adoption of the hybrid ARQ feature on the RL. Each subframe (SF) spans four time slots, and is associated with an interlace channel index of 1, 2, and 3. The maximum number of allowed SF transmissions is four SFs per packet. To minimize delay for the VoIP application however, each VoIP packet needs to com- plete its transmission within three SF transmissions. This is be- cause there may be three voice frames arriving every 60 ms from the EVRC source and there are nine SF in the same time period. If each packet requires no more than three SF to complete, these three voice frames can be completed in nine SF. Otherwise, the

voice frame following these three voice frames will incur addi-
tional queuing delay.
G. RL Resource Management Control

The RL link of the DOrA system is designed to tolerate a given received interference power level. The interference power is measured by the ratio of total received power to thermal noise power, and is referred to as rise-over-thermal (RoT). Gener- ally, a system operated at a higher RoT will have higher RL capacity; however, the tradeoffs in operating at a high RoT are higher user transmit power and a greater chance for power con- trol instability.


To study the delay and capacity performance of VoIP using DOrA, theoretical analysis and computer simulations were car- ried out. In this section, we summarize the assumptions and the system model used for the VoIP performance investigation.

A. VoIP Performance Criteria

For voice service, the acceptable delay guideline has been studied extensively and been summarized in the G.114 Stan- dard. At this point, it is not yet clear what guideline will be appropriate for the VoIP latency bound. The complication stems from the fact that VoIP packet delay varies on a packet basis, whereas the guideline from G.114 is obtained with\ufb01xed end-to-end delay. To proceed with this study, we assume that the frame erasure rate (FER) due to packet loss and packet delay exceeding the target latency bound be kept within 2%. Further, at least 98% of VoIP users in the network should meet the above criterion, and the interference level in terms of RoT should be kept below a given threshold.

B. Simulation Setup

A computer simulation was carried out to verify the theoret- ical analysis and provide more comprehensive and detailed in- formation regarding VoIP performance and system capacity. In each run of the simulation, a certain number of mobiles are ran- domly placed into the network with uniform area distribution. The number of users per sector is, thus, a Poisson random vari- able. Erlang capacity for VoIP is de\ufb01ned as the average number of users per sector. The values of the system parameters used in the simulations follow the standard recommendation [13].

A. Analytical Model

In this section, we utilized the\ufb01eld measurements of the ex- isting DOr0 system as reported in [19] to estimate VoIP capacity. A simpli\ufb01ed\ufb01rst-in\u2013\ufb01rst-out (FIFO) scheduling model with ex- tended bulk-service was proposed to analyze the delay and ca- pacity performance on the FL. The FIFO scheduler was selected to provide consistent delay and jitter performance for all VoIP users across the RF conditions. As shown in Fig. 1, a Poisson arrival with raterepresents the aggregate traf\ufb01c destined for all VoIP users in the sector.

Activity (5)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
Abhishek Sahu liked this
vire_tia liked this
gargee502 liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->