Research Dual Cell HSDPA Application Performance in Unloaded Systems.v1.20110209 Original
-
Upload
muhammad-irfan-ul-haque -
Category
Documents
-
view
215 -
download
1
description
Transcript of Research Dual Cell HSDPA Application Performance in Unloaded Systems.v1.20110209 Original
Dual Cell HSDPA Application Performance in Unloaded Systems
Abstract Dual Cell HSDPA (DC-HSDPA), which was introduced in Release 8 of the WCDMA specifications, enables
the User Equipment (UE) to receive downlink data on two adjacent carriers simultaneously. We
implemented DC-HSDPA functionality in a prototype and evaluated its performance for various
applications in comparison with Single Carrier HSDPA (referred to as just HSDPA). Our results show that
realistic applications, such as web browsing, FTP and video streaming see significant gain at low and
medium geometries with DC-HSDPA compared to HSDPA.
1. Introduction Dual-Cell High Speed Downlink Packet Access (DC-HSDPA) was introduced by 3rd Generation Partnership
Project (3GPP) in Release 8 of the Wideband CDMA (WCDMA) specifications [1][2]. DC-HSDPA enables
the User Equipment (UE) to receive downlink data on two adjacent carriers simultaneously, thus
doubling the physical channel rate seen by the UE compared to Single Carrier HSDPA (referred to as just
HSDPA) at all locations in the cell.
In this paper, using a prototype implementation of DC-HSDPA, we evaluate the gain seen by real
applications when using DC-HSDPA compared to HSDPA. We focus on a few representative applications
that a typical user uses on the Internet today. Our preliminary results, which focus on UEs with a single
receive antenna, show that DC-HSDPA not only doubles the physical channel rate compared to HSDPA,
but also leads to significant gain seen by realistic applications which would translate to much better user
experience.
We perform comparisons between HSDPA and DC-HSDPA both under lab conditions as well as on
Qualcomm CR&D prototype over-the-air (OTA) network. Our lab tests span a range of geometries and
fading channels, whereas for OTA tests, we evaluate performance using a few different drive routes,
which cover a wide range of radio environments. The realistic applications we focus on are: FTP (File
Transfer Protocol) with very large file size (> 1 GByte) , FTP with limited file size, Web Browsing, Video
Streaming. We also consider the Bursty Traffic source (as defined by 3GPP in [3]), which provides a good
benchmark for comparison.
The paper is organized as follows. Section 2 gives an overview of DC-HSDPA introduced in 3GPP
specifications, while Section 3 describes the DC-HSDPA Prototype implementation. In Section 4, we
describe the various applications used for evaluating performance as well as their relevant metrics.
Section 5 describes details of our lab setup as well as lab results. Section 6 discusses our OTA setup and
results. In Section 7, we present our conclusions and outline future work.
2. DC-HSDPA in 3GPP Specifications DC-HSDPA was introduced by 3GPP in Release 8 of the WCDMA specifications. DC-HSDPA enables the UE
to receive downlink data simultaneously on two adjacent carriers. Each carrier’s downlink High Speed
Physical Downlink Shared Channel (HS-PDSCH) data transmission is accompanied by the High Speed
Shared Control Channel (HS-SCCH) control channel. Release 8 specifications do not provide support for
DC-HSDPA together with Multiple Input Multiple Output (MIMO) transmissions; the concurrent support
of DC-HSDPA and MIMO is included in Release 9.
An important characteristic of DC-HSDPA is that support of two downlink carriers does not require two
uplink carriers; rather, in Release 8 of the specifications, the channel quality information (CQI) and
Hybrid ARQ (HARQ) acknowledgement information for downlink data for both downlink carriers as well
as uplink data are sent on a single uplink carrier. The two uplink carriers corresponding to the two
downlink carriers in a FDD band can be used for uplink load balancing, e.g., half the users on one carrier
with the other half on the other carrier.
The choice of a single uplink carrier in Release 8 also leads to other design choices: the Fractional DPCH
(F-DPCH) channel used for carrying power control bits on the downlink for the purpose of power
controlling the uplink is present only on one downlink carrier. This downlink carrier is referred to as the
Anchor Carrier, while the other downlink carrier (which does not carry the F-DPCH bit) is referred to as
the Secondary Carrier. An important characteristic of the Anchor Carrier is that the UE carries out
measurements for the purpose of mobility only on the Anchor Carrier. Moreover, a single uplink also
means that a single Active Set is maintained by the UE (and the network), only on the Anchor Carrier.
3. DC-HSDPA Prototype Description Our DC-HSDPA prototype implements all the layers of the protocol stack (physical, MAC, RLC, PDCP) per
3GPP Rel 8 specifications. Some of the key features of the DC-HSDPA prototype system are the
following:
The DC-HSDPA prototype UE uses an Equalizer receiver.
The CQI reported by the UE is filtered through an IIR filter at the Node B, with a time constant of ~30
Transmission Time Intervals (TTIs).
The HS-PDSCH scheduler selects the transport block size based on the filtered CQI value and an
outer loop algorithm which targets 10% BLER after the first Hybrid ARQ (HARQ) transmission.
The power used on the HS-SCCH channel is fixed at 10% of the total cell power.
On the uplink, 10 ms TTI is used for the Enhanced Dedicated Physical Data Channel (E-DPDCH)
channel with a maximum of 2 HARQ transmissions. An outer loop power control algorithm, which
targets 10% BLER after the first HARQ transmission on the E-DPDCH channel, is implemented at the
Node B.
4. Applications Used for Performance Evaluation We focus on the following applications in this paper:
FTP with very large file size (1 GB): The key reason for choosing a very large file size is that the TCP Slow
Start has very little impact on the FTP throughput; rather, the expected throughput is close to the
physical layer throughput (minus the overheads due to MAC and RLC headers). The key metric is
throughput.
FTP with limited file size: 4 filesizes are chosen: 500 Kbyte, 2 Mbyte, 5 MByte and 10 MByte to reflect a
range of file sizes a user may encounter. The filesizes allow the impact of TCP Slow Start to be studied.
The key metric is file download time.
Web Browsing (CNN): A web browsing session consisting of downloading the main page of
www.cnn.com. To allow repeatability (since server load as well as content at www.cnn.com could vary
at different times), we copied a snapshot of www.cnn.com on a local server. The key metric is average
page download time.
Web Browsing (Google Maps): A web browsing session consisting of Google Maps sessions of the cities
San Diego, Las Vegas and Los Angeles. To allow repeatability, we copied snapshots of Google Maps
sessions of the 3 cities on a local server. The key metric is average page download time.
Video Streaming: Video sources at 3 different bitrates (256 Kbps, 768 Kbps and 2 Mbps) streamed from
a local server. The video sources are streamed at 15 frames/sec. The video playout buffer starts
buffering if the size of the buffer goes to 0 and then starts playing only when the playout buffer has
buffered 2.6 seconds worth of playout, which corresponds to a buffer size of (665 Kbits, 2 Mbits and 5.2
Mbits) at bitrates of (256 Kbps, 768 Kbps and 2 Mbps) respectively.
The key metrics are:
Average buffering duration: The average duration (in seconds) of a buffering event.
Frequency of buffering events: The number of buffering events per minute.
Ratio of Buffering to Playing Duration: The ratio of the time spent in buffering incoming frames
to the time taken for playing out the video frames. As mentioned above, during the time that
the playout buffer is buffering incoming frames, video frames are not played out. This would be
perceived as interruption in the video playout.
Closed Loop Bursty Traffic: Figure 1 shows the client/server interaction for closed loop bursty traffic.
After a request has been satisfied (i.e., the client has received all data corresponding to the burst size),
the client waits for a random amount of time and sends the next request. The client’s waiting time is
chosen from an exponential distribution with mean value of one second. The burst size is fixed and is set
to either 1 Mbit or 4 Mbit. The transport protocol used to carry the burst is either TCP or UDP.
Figure 1: Illustration of burst request and reception
In Figure 1, sk, fk, lk denote the size of the requested burst k, the time at which the first byte of burst k is
received, and the time at which the last byte of burst k is received respectively.
The key metric is:
Burst Rate: The expectation of each burst’s transmission rate, i.e., E[sk/(lk-fk)].
5. Lab Setup and Results
5.1 Lab Setup In the lab setup, the two main parameters we control are geometry and type of fading channel. Fading is
introduced using a channel emulator and each carrier goes through independent fading. Geometry is
controlled using a single source of interference. It should be noted that the lab setup uses a single
source of interference to create geometry, whereas in the field, there are typically multiple cells that
create interference.
A laptop is connected to the prototype UE, which can be either a DC-HSDPA or a SC-HSDPA UE. The
laptop is the client for all the applications evaluated.
5.2 Lab Results In this section, we present results from lab testing. Results are shown for the applications described in
Section 4. Note that all the results presented in this section are for a single UE, with a single receive
antenna, in the system.
FTP with large file size
Figure 2 shows the throughputs for the FTP application with large file size for dual carrier and single
carrier UEs. We can see that dual carrier UEs give twice the FTP throughput of single carrier UEs across a
range of geometries and fading channels.
Figure 2: FTP Throughput in PA3 and VA30 channels
FTP with limited file size
Figure 3 shows the file download times for SC-UE and DC-UE for a few file sizes and geometries in PA3
fading channel. We see more impact of TCP Slow Start at smaller file sizes and higher geometries, i.e.,
0
2000
4000
6000
8000
-5 0 5 10
Thro
ugh
pu
t (K
bp
s)
Geometry (dB)
PA3
SC UE DC UE
0
2
4
6
8
0dB 5dB 10dBFile
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
File Size = 500 KB
0
20
40
60
80
0dB 5dB 10dBFile
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
File Size = 5 MB
SC UE DC UE
0
1000
2000
3000
4000
5000
6000
7000
-5 0 5 10
Thro
ugh
pu
t (K
bp
s)
Geometry (dB)
VA30
SC UE DC UE
when the time to download the file is small. In this case, TCP Slow Start dilutes some of the gains
possible due to a DC-UE. For larger file sizes or lower geometries, the file download time for a SC-UE is
close to twice of that for a DC-UE.
Figure 3: File Download Times for SC-UE and DC-UE for different file sizes and geometries
Web Browsing (CNN)
Figure 4 shows the page download time for the CNN webpage described in Section 4 for DC-UE and SC-
UE for PA3 fading channel.
The CNN page download time for a DC-UE is significantly lower than that for a SC-UE at low geometries
(-3dB and 0dB). At higher geometries (5 dB), the page download times for a DC-UE and a SC-UE are
similar. Note that the request-response nature of HTTP leads to multiple round trip times being used for
sending HTTP requests, during which the channel may be under-utilized. This, coupled with browser
processing delays, leads to web browsing delays saturating once the channel rate is sufficiently high.
These results indicate that the cell edge user experience will be greatly enhanced with a DC-UE.
0
2
4
6
8
0dB 5dB 10dBFile
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
File Size = 500 KB
0
20
40
60
80
0dB 5dB 10dBFile
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
File Size = 5 MB
SC UE DC UE
0
10
20
30
0dB 5dB 10dBFile
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
File Size = 2 MB
SC UE DC UE
0
50
100
150
0dB 5dB 10dB
File
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
File Size = 10 MB
SC UE DC UE
Figure 4: Average CNN Page download times in PA3 and VA30 channels
Web Browsing (Google Maps)
Figure 5 shows the page download time for the Google Maps session described in Section 4 for dual
carrier and single carrier UEs.
The Google Maps page download times for a DC-UE are significantly lower than that for a SC-UE at all
the geometries considered (-3 dB, 0 dB and 5 dB). Google Maps typically generates data of larger bursts
and at higher rates compared to other web pages (such as CNN). This allows a DC-UE to achieve gains
over a SC-UE even at higher geometries.
Figure 5: Google Maps page download time averaged across multiple cities in PA3 and VA30 channels
Video Streaming
Figure 6 shows the buffering to playing duration ratio for the 256kbps and 768kbps Video Streaming
sources described in Section 4 for DC-UE and SC-UE.
0
2
4
6
8
10
12
14
16
-3dB 0dB 5dB
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
PA3
SC UE DC UE
0.0
5.0
10.0
15.0
20.0
25.0
30.0
-3dB 0dB 5dB
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
PA3
SC UE DC UE
0
2
4
6
8
10
12
14
16
-3dB 0dB 5dB
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
VA30
SC UE DC UE
0.0
5.0
10.0
15.0
20.0
25.0
-3dB 0dB 5dB
Do
wn
load
Tim
e (
seco
nd
s)
Geometry
VA30
SC UE DC UE
The results show that a DC-UE can support 256 kbps video without the user client having to pause for
buffering during playout. A SC-UE, on the other hand, will spend a significant amount of time buffering
at low geometries (-3 dB).
For 768 kbps video, a DC-UE can support such a video source without the user client having to pause for
buffering at geometries of 0 dB or above. A SC-UE, on the other hand, can support smooth playout of
the video only at higher geometries. Even at very low geometries (-3 dB) where a DC-UE is not able to
achieve smooth playout without buffering, it still performs significantly better than a SC-UE.
Figure 6: Ratio of buffering to playing duration for PA3, VA30 fading channels and different geometries
Figure 7 shows the average buffering duration for the 256kbps and 768kbps Video Streaming sources for
DC-UE and SC-UE. A DC-UE again shows significant performance gain compared to a SC-UE. Even when a
DC-UE requires buffering, the average buffering duration is significantly shorter compared to a SC-UE.
00.5
11.5
22.5
33.5
G=-3dB G=0dB G=5dB G=-3dB G=0dB G=5dB G=-3dB G=0dB G=5dB G=-3dB G=0dB G=5dB
PA3 VA30 PA3 VA30
256kbps Video 768kbps VideoBu
ffe
rin
g to
Pla
yin
g D
ura
tio
n R
atio
SC UE DC UE
0
2
4
6
8
10
12
G=-3dB G=0dB G=5dB G=-3dB G=0dB G=5dB G=-3dB G=0dB G=5dB G=-3dB G=0dB G=5dB
PA3 VA30 PA3 VA30
256kbps Video 768kbps Video
Ave
rage
Bu
ffe
rin
g D
ura
tio
n (
sec)
SC-UE DC-UE
Figure 7: Average buffering duration for PA3, VA30 fading channels and different geometries
Closed Loop Bursty Traffic
Figure 8 shows the burst rates (defined in Section 4) for closed loop bursty traffic for both UDP and TCP
as transports. With UDP, the burst rate for DC-UE is roughly twice that of a SC-UE. With TCP, on the
other hand, TCP Slow Start reduces the burst gain that can be achieved with a DC-UE compared to a SC-
UE, particularly at higher geometries.
Figure 8: Burst rates for SC-UE and DC-UE for different geometries and PA3 fading channel.
6. Over-the-Air (OTA) Setup and Results
6.1 OTA Setup Our OTA setup consists of 3 Node Bs, as shown in Figure 9. In all OTA tests, NodeB 2 is the HS-DSCH
serving cell all the time (the chosen routes do not have any serving cell change). The downlink coverage
of NodeB 2 is shown in Figure 9.
0
1000
2000
3000
G=0dB G=5dB
Bu
rst
Rat
e (
kbp
s)
UDP
SC UE DC UE
0
500
1000
1500
2000
G=0dB G=5dB
Bu
rst
Rat
e (
kbp
s)
TCP
SC UE DC UE
Figure 9: OTA Setup showing locations of three Node Bs and coverage of NodeB 2 (Image generated using Google EarthTM
)
The following drive routes were chosen for evaluating HSDPA and DC-HSDPA performance:
Low CQI, Low Speed Route: In this drive route, shown in Figure 11, the median CQI seen by a UE with a
single receive antenna is 11 (corresponding to a geometry of -3dB) and the typical average speed is 3 to
6 kmph.
Low CQI, High Speed Route: In this drive route, shown in Figure 11, the median CQI seen by a UE with a
single receive antenna is 11 (corresponding to a geometry of -3dB) and the typical average speed is 30 to
45 kmph.
High CQI, Low Speed Route: In this drive route, shown in Figure 11, the CQI seen by a UE with a single
receive antenna is 26 (corresponding to a geometry of 12dB) and the typical average speed is 3 to 6
kmph.
High CQI, High Speed Route: In this drive route, shown in Figure 10, the median CQI seen by a UE with a
single receive antenna is 22 (corresponding to a geometry of 8dB) and the typical average speed is 30 to
45kmph.
Average CQI Route: In this drive route, shown in Figure 10, the average CQI as well as the cdf of CQI seen
by a UE with a single receive antenna is similar to that seen in simulations based on the 3GPP simulation
framework [3].
The cdf of CQI, seen by a UE with a single receive antenna, in the 5 drive routes is shown in Figure 12.
Figure 10: Average CQI and High CQI High Speed drive routes (Image generated using Google EarthTM
)
High CQI High Speed Route
Average CQI Route
Figure 11: High CQI Low Speed, Low CQI High Speed, Low CQI Low Speed drive routes (Image generated using Google EarthTM
)
High CQI Low
Speed Route
Low CQI Low
Speed Route
Low CQI High
Speed Route
Figure 12: cdf of CQI of OTA Drive Routes
6.2 Over-the-Air Results In this section, we present results from OTA testing. Results are shown for the applications described in
Section 4. Note that all the results presented in this section are for a single UE, with a single receive
antenna, in the system.
FTP
Figure 13 shows the throughputs for the FTP application with large file size for dual carrier and single
carrier UEs. Results are presented for the OTA routes described previously. DC-UE is seen to have nearly
double the FTP throughput of a SC-UE.
0 5 10 15 20 25 300
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
CQI
CD
F
High CQI High Speed
High CQI Low Speed
Low CQI High Speed
Low CQI Low Speed
Average CQI
Figure 13: FTP Throughput in different OTA drive routes
Web Browsing (CNN)
Figure 14 shows CNN page download delays for DC-UE and SC-UE for the OTA routes. Similar to the lab
test cases, the CNN page download times are significantly lower for a DC-UE compared to a SC-UE at
low-medium range of CQIs. For high CQIs, the page download times for a DC-UE and a SC-UE are similar.
Figure 14: Average CNN Page download times in different OTA routes
Web Browsing (Google Maps)
Figure 15 shows the page download times for the Google Maps session described in Section 4 for dual
carrier and single carrier UEs.
Google Maps page download times for a DC-UE are significantly lower than those for a SC-UE for the
Low and Average CQI routes. For the high CQI routes, the page download times for a DC-UE and a SC-UE
are similar.
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
High CQI, High Speed route
High CQI, Low Speed route
Low CQI, High Speed route
Low CQI, Low Speed route
Average CQI route
Thro
ugh
pu
t (K
bp
s)
SC UE DC UE
0
2
4
6
8
10
12
High CQI, High Speed route
High CQI, Low Speed route
Low CQI, High Speed route
Low CQI, Low Speed route
Average CQI route
Do
wn
load
Tim
e (
seco
nd
s)
SC UE DC UE
Figure 15: Average Google Maps Page download times in different OTA routes
Video Streaming
Figure 16 shows the buffering to playing duration ratio and Figure 17 shows the average number of
buffering events per minute for the 768 Kbps and 2 Mbps Video Streaming sources described in Section
4 for DC-UE and SC-UE.
The video streaming performance in the high CQI routes is similar between SC-UE and DC-UE, but for the
low and average CQI routes, DC-UE shows significant gain compared to SC-UE in terms of reducing the
buffering to playing duration ratio as well as the frequency of buffering events. This translates to a
smoother user experience when viewing a video stream.
Figure 16: Ratio of buffering to playing duration for different OTA routes
0
5
10
15
20
25
High CQI, High Speed route
High CQI, Low Speed route
Low CQI, High Speed route
Low CQI, Low Speed route
Average CQI route
Do
wn
load
Tim
e (
seco
nd
s)
SC UE DC UE
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
lowCQI, lowSpeed
lowCQI, highSpeed
highCQI, lowSpeed
highCQI, highSpeed
average CQI route
lowCQI, lowSpeed
lowCQI, highSpeed
highCQI, lowSpeed
highCQI, highSpeed
average CQI route
768kbps Video 2Mbps Video
Bu
ffe
rin
g to
Pla
yin
g D
ura
tio
n R
atio
SC UE DC UE
Figure 17: Average number of buffering events per minute for different OTA routes
7. Conclusions We compared the performance of dual cell HSDPA and HSDPA UEs for various applications under lab
and OTA conditions using our prototype system. The UEs used in these tests had a single receive
antenna, and all tests were performed with a single UE in the system.
Results from lab and OTA tests have shown a significant gain for a DC-UE compared to a SC-UE at low
and medium geometries/CQIs. For FTP with limited file size, a DC-UE reduces the file download time by
a factor of 2 compared to a SC-UE, particularly for medium-large sizes files. For other applications such
as Web Browsing (CNN and Google Maps) as well as Video Streaming, user experience with a DC-UE
shows significant improvement compared to a SC-UE at low and medium geometries in the cell. At high
geometries/CQIs, the Video Streaming performance of a DC-UE and a SC-UE is seen to be closer.
Based on the results presented in this paper, one way to interpret the advantage of DC-HSDPA is that it
helps to provide uniform performance throughout the cell (i.e., at almost all geometries), particularly for
web browsing applications.
As part of future work, we plan to extend our evaluation to include UEs with dual receive antennas. We
also plan to include scenarios with multiple UEs per cell.
References [1] 3GPP TS 25.211, “Physical channels and mapping of transport channels onto physical channels (FDD)”
[2] 3GPP TS 25.214, “Physical layer procedures (FDD)”
[3] 3GPP TR 25.848, “Physical Layer Aspects of UTRA High Speed Downlink Packet Access”
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
lowCQI, lowSpeed
lowCQI, highSpeed
highCQI, lowSpeed
highCQI, highSpeed
average CQI route
lowCQI, lowSpeed
lowCQI, highSpeed
highCQI, lowSpeed
highCQI, highSpeed
average CQI route
768kbps Video 2Mbps Video
Ave
rage
nu
mb
er
of
bu
ffe
rin
g e
ven
ts p
er
min
ute
SC UE DC UE