Category: HSDPA

Some reflection on my use of wireless Internet access over the last couple of years: Since I started using the Internet over wireless networks on the go back in 1998 it was always slower than at home. Back in 1998 I still used dial up, but my 64 kbit/s ISDN line at home was several times faster than the 14.4 kbit/s circuit switched dial up connection over the GSM network. Until recently the difference has pretty much remained the same just the speeds have changed.

For every step wireless made, be it GPRS, EDGE or UMTS, fixed line technologies had already made a similar step two or three years before. In most cases it was o.k. to live with the slower speed while not at home traveling the world but I always wished it would be as fast at home. Well, with HSDPA now deployed pretty much everywhere I go these days, access to the Internet on the go is now just as fast or even faster than my DSL line at home. I still catch myself thinking, "no can’t download this, have to wait until I am back home" just to smile at myself afterwards because it makes no difference anymore.

It’s not that DSL hasn’t made progress and is available in flavors of 16-20 MBit/s already in many places, but except for downloading very large files or for IPTV I have very little use for 20 MBit/s right now. I don’t have a doubt, however, that this void will be filled in the next couple of years. Of course by this time both wireless and wireline Internet access technologies will have progressed to even higher data rates.

Most HSDPA tests in live networks presented on this blog so far were always performed in lightly loaded cells. In this blog entry I take a closer look at HSDPA performance in a cell that servers other non-HSDPA 3G users simultaneously.

For this test I’ve used one HSDPA terminal (a Sierra Wireless 850 PCMCIA card) to download a file and a second 3G only terminal (a Nokia 6680) to create "interference" by also downloading a file. The 3G only terminal can not use the HSDPA channels and is thus assigned a dedicated channel (DCH) by the network. In the test, the network assigns a 64 kbit/s DCH first, quickly followed by 128 kbit/s and 384 kbit/s bearer upgrades. From a CDMA code point of view, a 384 kbit/s bearer with a spreading factor of 8 takes similar resources than 16 simultaneous circuit switched voice calls (spreading factor of 128). Thus, the test not only shows how fast DCH and HSDPA bearers work together in practice but also what kind of impact a fair number of voice calls have on HSDPA throughput in the cell.

The first figure on the left shows the throughput of a file download via HSDPA. At the beginning no other users are in the cell. At about 20 seconds into the file transfer I started another file transfer via the 3G only terminal. The network then seems to modify resources in the cell between 25s and 45s. There are a number of characteristic downward spikes during that time which I was able to reproduce during each re-run of the test. As I can’t look into the network, I have no explanation for them. Finally at about 45s the throughput stabilizes at a slightly lower level than at the beginning where no interference was present.

The second figure on the left shows an inter-packet spacing graph (for an intro on this kind of graph see here) of the same download. For about half the download there is only a significant line at 10ms inter-packet spacing. Then, when the file transfer of the 3G mobile sets in the lines at 20 and 30ms get more dots. Lines at 20 and 30ms can have the following reasons:

• Retransmission because of faulty packets
• The network has started to use a different coding scheme for the packets due to interference, so packets take longer to be transmitted
• Other HSDPA users in the network with whom a terminal has to share the capacity.

In this test, the third reason can be discounted as there as no other HSDPA capable terminal in the cell at the time. So either the interference caused by the 3G mobile forced the network to increase the coding scheme or to accept more retransmissions. Both results in slower throughput for the HSDPA terminal. Whether it is one or the other for this test or a combination of both is difficult to say from a terminal perspective.

In total, this test shows that even a fair number of voice calls by other users in parallel to HSDPA has only little impact on throughput as long as reception conditions for the voice calls and HSDPA is good. In such conditions the noise generated by other users is still low enough for the HSDPA terminal to cope with. 

When I have time and opportunity I will run the same test again in an area with weaker coverage. Also, impact of DCH users on HSDPA networks supporting 16QAM modulation, which requires a higher signal to noise ratio than QPSK modulation used by the network for this test should be fun testing.

After some basic tests to see how HSDPA performs in a number of different networks I’ve now moved to a number of somewhat more complicated scenarios. The last article in this technical series on HSDPA focused on network and terminal HSDPA behavior for an incoming call. This article shows how the network behaves when several mobiles communicate simultaneously in a single cell.

In general, Internet applications usually have bursty traffic requirements. Web surfing is a good example. The time required to load a page is typically much shorter than the reading time during which no data is transfered. When downloading large chunks of data, think YouTube, podcast download, etc. the radio channel is occupied for a much longer time which increases the chances that the radio resources have to be shared with several other users. Sharing the radio channel with other users is a strength of HSDPA as users are not assigned dedicated channels anymore as in UMTS. Instead, the cell assigns short bursts on several High Speed Shared Channels. The duration of a burst is 2 ms and the system can flexibly assign those bursts to different users.

Figure one on the left shows the throughput graph of a file transfer. In the first part, the terminal is the only one in the cell. The throughput is constant and at its maximum value for the current radio conditions at around 1.2 MBit/s. At about the middle of the file transfer, I’ve started a second file transfer from a different notebook with a different HSDPA data card. Immediately the network reacts to the second independent download and reduces the speed for the first user. Quite interesting to see that the throughput is no longer constant but varies quite a bit. It’s likely that this is the effect of changing radio conditions (fading) to which the network reacts by assigning more bandwidth to the user with better radio conditions at a given moment.

Figure two on the left is also quite interesting. It shows the inter-packet spacing graph for the file transfer which was introduced here. In summary, this graph shows the time distance between two packets. HSDPA has typical lines at 10, 20 and 30 ms, explained in more detail here. In the second part of the graph where the second user comes in, inter-packet distance suddenly jumps to 20 and 30 milliseconds. In this case this is not due to a deteriorating radio channel but due to the file transfer of the second user.

The graphs were produced with a HSDPA category 6 Motorola V3xx terminal with a theoretical maximum speed of 3.6 MBit/s. As the top speed reached in the cell at the beginning of the file transfer is 1.2 MBit/s it’s likely that the cell of the Vodafone Germany network used for the test has not yet been upgraded for 16QAM modulation.

So that’s it for today. In case your are looking for an introduction to HSDPA, have a look at chapter 3 of my book. And for more real live measurement scenarios, click on the HSDPA tag next to the date below.

While testing the maximum transmission speed of my category 6 HSDPA terminal (Motorola V3xx, theoretical maximum of 3.6 MBit/s) I found out that Vodafone Italy is applying traffic shaping to file downloads to slow them down. Dear Vodafone, are you sure this is really necessary?

Each TCP connection seems to be limited to a speed of around 700 kbit/s. It sounds like a lot but nowhere near enough to test the maximum downlink speed of the connection. Only when downloading three files in parallel did I reach the ceiling of around 2 MBit/s with average network reception levels. Have a look at the picture on the right which shows how the accumulated transmission speed increases with 1, 2 and 3 simultaneous file downloads.

To make sure it was not a limitation on the server side I downloaded files from different servers. Also, I compared the download speed in the network of TIM where a single file download was enough to push download speed to over 1.4 MBit/s (with a category 12 terminal, theoretical maximum speed of 1.8 MBit/s).

Also I noted lots of TCP packet losses on the Vodafone Italy network during the day and in the evening while during the morning everything was all right. Strangely enough performance of the network was o.k. when I used a roaming SIM card from Vodafone Germany just minutes later. In this case the GGSN in Germany is used rather than a GGSN in Italy. Looks like they’ve got a huge bottleneck in that corner.

Looks like TIM will keep me as a customer when I am in Italy, their performance has been flawless over weeks.

In theory, 3GPP standards allows simultaneous HSDPA and circuit switched voice calls on a DCH. The standard even describes how the terminal can signal the maximum speed to the network it supports on a DCH while an HSDPA session is ongoing. In practice, however, this does not seem to be implemented yet.

While testing such a scenario with a Motorola V3xx in practice I noticed that an incoming circuit switched voice call makes the radio network interrupt the HSDPA session, put the data connection on a dedicated channel (DCH) and then opens an additional dedicated channel for the voice call. During the voice call data transmission is possible with 64 kbit/s in one network  (Tim, Italy) and 128 kbit/s in another (SFR, Paris). In a third network I tested this scenario the incoming call was not delivered at all. As this network has not officially launched HSDPA yet, I grant them anonymity.

After the voice call is over I would have expected that the networks put the data connection back onto HSDPA. I was quite surprised that this was not the case. Instead, the DCH was upgraded to 384 kbit/s. It would only go back into HSDPA mode once the data transfer is interrupted. While this is not a problem for web surfing, where many interruptions occur, this behavior is very undesired for file downloads. Here, the file download will continue but never be put back on a faster HSDPA connection.

The picture on the left shows the result of the test run. At first the download speed is around 75 kbyte/s. Then a voice call is started. This shows on the graph with the short interruption of the data traffic followed by a download speed of around 7 kbyte/s (64 kbit/s bearer). After the voice call is over the DCH speed increased to around 40 kbyte/s (384 kbits/s). The second part of the graph shows a repetition of the test (to make sure I was not dreaming).

Looks like it is still early days for HSDPA. While switching from HSDPA to DCH during a voice call could be both a network or a mobile implementation limitation, not switching back to HSDPA after the call very much seems like a network limitation to me.

Frequent readers of my blog might have noticed my fascination for real live HSDPA performance as of late. Here’s a paper from Ericsson on HSDPA performance with category 12 and 6 terminals in stationary and moving environments in live networks. Based on my own measurements I fully agree with their results. At the end it also contains a quick overview of enhancements to come to increase overall bandwidth of the network and per user. A well written paper!

Quite a surprise today in Rome when my data card suddenly showed HSDPA instead of 3G when I logged on to the Internet with a SIM card from WIND. I haven’t seen an announcement on their web page yet nor anywhere in the streets. So I checked Google news, but came up empty handed as well. Did anyone besides me notice as well?

The transmission speed, however, was far from what it could be (like for example in the TIM network, for measurement details see here) due to constant TCP retries which I’ve also experienced in 3G mode in the past. It doesn’t have a lot of impact on web browsing and Skype but downloads of larger files take 2-3 times longer than over a good connection. I tried with a second HSDPA terminal of a different manufacturer and got the same results. Let’s hope Wind fixes this issue before the official launch.