Category: UMTS

My recent trip to Italy produced quite a large amount of measurement data while I was using Telecom Italia Mobile’s (TIM) HSDPA network for everyday work and pleasure. In part 1, I’ve been giving a general overview of the performance of HSDPA in an operational network. Part 2 then focused on analyzing IP packet inter-spacing and revealed a number of interesting details of the HSDPA MAC layer. In part 3 I showed how antenna position and placement can have a tremendous impact on performance. This part now picks up the thread and shows how the HSDPA MAC layer adapts to the antenna position changes tested in part 3.

The picture on the left shows the packet inter-spacing diagram generated from the same data as the throughput graph presented in part 3. If you haven’t read part 2 which gives an introduction of how to read this type of diagram I strongly recommend you to do so before reading on. The throughput graph in part 3 starts off with a speed of around 500 kbit/s. In the packet inter-spacing graph the reason for this slow speed becomes apparent. Instead of most packets being transmitted with a inter-spacing of 10 ms or less, most packets are rather on the 20 ms and 30 ms lines. This either means that the Node-B has sent the packets with a more robust coding scheme or that most packets were retransmitted at least once. No exact telling without a L1 tracer but I guess it’s a more robust coding scheme.

By changing the antenna position the data rate suddenly increases to over 1.500 kbit/s. In the packet inter-spacing graph this is reflected by most packets being transmitted with the least robust coding scheme on the 10 ms. A certain percentage of the packets are retransmitted and show up on the 20 ms line but they are not many, around 20% I would say.

This interval with good signal conditions and the resulting  good transmission speed is then followed by vary bad signal conditions. Here, the data rate drops to around 350 kbit/s. In the packet inter-space graph there are almost no frames transmitted on the 10 ms and 20 ms line. The first major line is at 30 ms. Surprisingly there is not only major additional line at 40 ms but also at 50 ms. Some packets even have an inter-space time of 70 ms. I was quite surprised by this at first. I did some reading in the meantime, however, and saw that Harri Homa and Antti Toskala in their book "HSDPA/HSUPA for UMTS" describe in figure 7.32 that during bad signal conditions their test system did not select only a single but more robust coding like in good signal conditions but diverged between 700 and 1700 bits of user data per 2 ms frame.

There remain those packets during good signal conditions to be explained which are between 2 ms and 10 ms. An interesting point here is that there is not a single IP packet between 0 and 2 ms. A clear indication of the 2 ms MAC layer frame duration. My best guess concerning these packet inter-space times is that they follow a packet which had a transmission error and were transmitted before the faulty MAC layer frame could be retransmitted. This is one of the strengths of the HARQ (Hybrid Automatic Retransmission Requests) used by HSDPA on the MAC layer which continues sending higher layer packets even if a previous one has not yet been transmitted successfully.

And this thought concludes today’s HSDPA entry. Should my German Vodafone prepaid SIM for data roaming have arrived when I come back home more entries will follow soon on HSDPA performance in other countries. So stay tuned…

In previous blog entries on HSDPA (for links see below), I’ve been looking at HSDPA performance in operational networks from several different angles. Todays entry focuses on how sensitive an HSDPA card reacts to changes in antenna orientation.

For my tests, I’ve been using a Sierra Wireless 850 PCMCIA notebook HSDPA adapter. The card has a maximum throughput of 1.8 MBit/s and has an external antenna which can be swiveled back and forth at the side of the notebook and also tilted 180 degrees to and from the notebook. This design is not new and all Sierra Wireless cards I’ve seen so far use this kind of antenna.

While antenna adjustments seem to have no big impact on GPRS performance, a huge difference can be observed with HSDPA during medium reception conditions (3 out of 5 bars on the RX meter). As shown in the graph produced with Wireshark on the left, throughput during a file download varied dramatically between 50 kbyte/s and 150 kbyte/s depending just on the antenna position and orientation. I have to admit that I was quite surprised by this result. I tried again a couple of days later just to ensure that this was not a freak occurrence but I could easily reproduce the behavior again.

Users will probably not spend a lot of time experimenting with antenna position and orientation whenever they log on to the Internet. Thus, I think HSDPA card manufacturers have to work hard on antenna and receiver design in order to reduce such effects in the future. 3GPP standards already give some guidance for the work ahead as the standard describes optional HSDPA terminal features such as multiple antenna designs and advanced receiver algorithms for more throughput and to counter these effects. For people using the HSDPA network in a stationary or semi-stationary setup, for example with a 3.5G to Wifi bridge, I highly recommend using an external antenna or at least to place the bridge close to a window.

Designing notebooks with built in HSDPA chips might also help to reduce this effect. In such a setup the antenna can use space inside the notebook which means antennas can be bigger and thus more sensitive and less susceptible to radio interference effects.

In the next part of this article series on HSDPA, I will discuss the packet inter-spacing graph for the scenario presented here and what can be deducted from it about layer 1 air interface MAC behavior and performance.

More on my recent HSDPA experiences:

• A real live comparison of UMTS and HSDPA
• A peek into the UMTS air interface with Wireshark
• A peek into the HSDPA air interface with Wireshark

This blog entry continues my reporting on HSDPA performance in
deployed networks. In part one I’ve been giving a general overview and
comparison of achievable speeds and delay times of UMTS and HSDPA. In part two I’ve presented an inter-packet space diagram for UMTS
to show how air interface bearer changes can be detected on the IP
layer. This part builds on the previous ones and discusses an inter-packet spacing diagram
for HSDPA.

So without further ado, let’s take a look at the inter-packet space diagram for a file download via HSDPA which is shown on the left. For details on how it was generated see the same analysis for UMTS. While the UMTS diagram shows the same spacing between each packet, the graph for HSDPA shows three distinctive horizontal lines. Inter-packet space for some packets is about 10 milliseconds, for others it is 20 milliseconds and for a few it is even 30 milliseconds. This is quite surprising at first as the throughput during the file transfer was stable at around 850 kbit/s.

At a speed of 850 kbit/s, the inter-spacing for IP packets with a size 1500 bytes (=12.000 bits as each byte has 8 bits) is 1 / (850.000 / 12.000) = 14 milliseconds. The diagram shows however, that some packets only have an inter-spacing of 10 milliseconds, while others have 20 or even 30. Taken the percental distribution into account that’s around 14 milliseconds on average.

So why three distinctive lines for HSDPA and not a single line as for the UMTS? My comments in the diagram already give a hint. On the air interface, HSDPA uses frames with a fixed length of 2 milliseconds. The amount of user data they carry (the transport block size) depends on the type of HSDPA terminal used and current transmission conditions. Based on the channel quality feedback of the terminal the base station (Node-B) selects an appropriate combination of modulation (QPSK or 16QAM) and coding. For this example I used a category 12 HSDPA card for which the highest transport block size is 3319 bits. For an IP packet with a length of around 12.000 bits at least 4 air interface transport blocks are required. At 2 milliseconds each the minimum time it takes to transfer a 1500 byte IP packet is thus 8 milliseconds. This is close to the first line in the diagram.

HSDPA has been designed to have a quick response time to packets which were not correctly decoded by the receiver. In fact the system even prefers a certain error rate over an error free transmission as it is more efficient to retransmit some packets than to reduce the transport block size to insert more error correction and detection bits. The time between reception, reporting the error and retransmission on the air interface is exactly 10 milliseconds. This is the explanation for the packets which were transmitted with an inter-packet space of 20 milliseconds and also for the few packets with 30 milliseconds. For the later ones at least one of the 4 required transport blocks had to be re-transmitted twice.

Note that it could also be possible that the scheduler in the base station could also have decided to change the transport block size during the transmission to produce these lines. However, I doubt this as the mobile station was not moving which means signal conditions were quite stable. When changing transport block sizes I would also expect a scheduler not to make such drastic changes which would result in some packets being transmitted in 4 or 5 blocks while others are transmitted in 10 (2 milliseconds each). Thus, I think my analysis above is more probable. No certainty, however, without a network analyzer on the HSDPA MAC layer.

In the next blog entry on this topic I will take a closer look at how small changes in antenna positioning can dramatically effect throughput and cell capacity. If you would like to find out more about UMTS and HSDPA in the meantime, my book is a good companion.

Since having arrived in Italy I’ve enjoyed using UMTS and HSDPA networks to connect to the Internet for my day to day work for reasonable prices. It has also allowed me to run a number of network traces to get some more insight into the performance of the UMTS and HSDPA air interface.  In the first part of this mini series, I’ve been looking at the data transfer rates and packet delay that I could get on some of the networks. While having been used to UMTS speeds for quite some time now I was even more positively surprised by HSDPA speeds of up to 1.5 MBit/s which I was able to reach in the network of Telecom Italia Mobile (TIM). For the details take a look here. Part two of the mini series focuses on how the network tracing tool Wireshark can be used to chase after some UMTS specific air interface phenomena.

Wireshark is a great tool to analyze any kind of network traffic over any kind of PC interface. The picture on the left (click to enlarge) shows a trace which was generated using Wireshark’s "TCP Round Trip Time Graph" statistics module and commented by me. In my opinion the name of this module is quite misleading as the graph does not show the TCP round tip time evolution during a transmission but rather the reception time delta between TCP packets over time. A better name for the analysis module would thus be TCP inter-packet spacing diagram. The y-axis of the diagram shows the time in seconds that has elapsed between two TCP packets while the x-axis represents the time. To generate the diagram I downloaded a large file from an FTP server.

The graph shows that at the beginning of the transfer the inter-packet time was around 0.1 seconds or 100 ms. The TCP packet size of the download was 1500 bytes. These two values can now be used to calculate the transmission speed. One packet every 0.1 seconds means that on average 10 packets are received per second. As each packet has a size of 1500 bytes, 10*1500 bytes = 15.000 bytes are received per second. As each byte has 8 bit the resulting transmission rate is 15.000 bytes/s * 8 bits = about 120 kbit/s. This corresponds quite nicely to the maximum transmission rate that can be reached with a 128 kbit/s radio bearer with a CDMA spreading factor of 16.

At about the middle of the diagram the inter-packet spacing suddenly becomes much smaller, about 35 milliseconds. Doing the same calculation again results to 1/0.035 = 28.5 packets/s. 28.5 packets/s * 1500 bytes = 42.857 bytes/s. 42.857 bytes/s * 8 bits = 342.857 bits/s. This is close to the maximum transmission rate of a 384 kbit/s radio bearer with a CDMA speading factor of 8. In practice this means that at this point there were fewer people using the UMTS cell which in turn reduced the load of the cell. The network then decided to upgrade my radio bearer from a spreading factor of 16 to 8. As can be seen in the diagram the fun didn’t last long as the bearer was reduced again to 128 kbit/s for a short time. Then, I was upgraded again to 384 kbit/s for the remainder of the trace.

The same behavior could also have been achieved by physically moving through the network during the download and thus change reception conditions. As I was not moving with the mobile during the test the effect was definitely caused by changing load and changing interference conditions in the cell. Whether the load was caused by other people doing data transfers or by voice calls can’t be told from the diagram. What can be told however is that the network at this time was highly loaded as the network always assigns the best possible radio bearer.

So much for now. In the next entry of this mini series I am going present the results of the same test performed in a 3.5G HSDPA network. I can already promise spectacular and thought provoking results! Watch this space!

These days I am totally unplugged but still always connected as I am staying in Italy for the moment, far away from my ADSL line back home. UMTS has kept me connected to the world in the past two weeks and I’ve been writing about my general experiences over at m-trends. So far, I’ve used a prepaid card from Wind to keep me connected. As Wind is not offering HSDPA (High Speed Data Packet Access) in their network yet the HSDPA card remained in the suitcase. Over the weekend, however, I’ve bought a prepaid card of Telecom Italia Mobile (TIM) where HSDPA is available. Their offer is not as good as Wind’s, giving me ‘only’ 500 MB for 20 euros over 30 days and an additional 1GB for an extra 20 euros should that not be enough. Still, for my purposes it should be more than enough. I am pretty much impressed by the speed increase HSDPA brings over plain UMTS. Also, responsiveness when clicking on a link in the web browser has noticeably increased as well. For the technical details read on.

The Hardware

HSDPA was standardized in a flexible way allowing data rates to grow as end user devices and networks become more capable. For my test, I used a Sierra Wireless Aircard 850, which supports HSDPA category 12 (inter-TTI of 1, QPSK only), i.e. a top speed of 1.8 MBit/s. Note that there are already category 6 mobiles and data cards available today promising speeds of up to 3.6 MBit/s by using 16QAM modulation in good coverage situations. However, my card is not capable of doing this yet. I am looking forward to compare the speeds of these two categories in a real network once I can get a hand on one. Enough about networks and terminal categories for the moment. For details you might want to take a closer look at my book 😉

Top Speed on Sunday Morning

There can be a big difference between theoretical maximum speeds and speeds that can be reached in a real environment. As I woke up early on Sunday morning I gave it a try when most other people were probably still sleeping, i.e. low overall radio network load from other people making phone calls and accessing the Internet. I was quite positively surprised in my first download test as the average speed for downloading a large file from the internet was about 1.5 MBit/s. Hey, that’s faster than my DSL line in Germany! It looks like TIM has not only upgraded their base stations to HSDPA but also ensured that the backhaul connection from the base station does not become the bottleneck.

I also downloaded the same file via the Wind UMTS network to be able to compare the behavior. As expected, the network load was also low and the download reached the highest possible UMTS download speed of 384 kbit/s. Also very nice but four times slower than via HSDPA.

The image above on the left shows a graph of the download as it happens. I started the download inside the apartment where radio coverage was far from ideal. Nevertheless, it can be seen in the graph that the download speed exceeded 1 MBit/s. Going to the balcony with the notebook after about half the download was finished improved the radio environment and the download speed even further.

Speeds at Other Times

To see how the network load impacts download speeds I ran the same test again at around noon on Sunday. This time my download speed was about 750 kbit/s or about 90 kbyte/s. The corresponding graph for the download is shown in the third image on the left. Note that I did not download the whole file which is why the download graph is not as long as in the previous image. Not quite as high in the morning but still quite respectable.

Web Browsing

The next test on my list was web browsing. I connected one notebook to the Internet via TIM’s HSDPA network and another one via Wind’s UMTS network. Then I surfed to a number of graphics intensive pages such as those from Nokia, CNN and a couple of German news magazines to compare first page display times and overall download times. While UMTS is by all means capable of delivering a good web browsing experience, HSDPA is by far quicker. All pages I tried always started to be shown a couple of seconds earlier on the notebook with the HSDPA connection than on the notebook with the UMTS connection. Needless to say that the time until the complete page is downloaded is also faster. I have to try again when at home with an ADSL connection in reach but I am pretty sure I would not be able to tell the difference between a DSL line and an HSDPA connection for web surfing except for the channel establishment delay described below.

Uplink Speed

TIM has also upgraded its radio network to support uplink speeds of 384 kbit/s. Note that this is not HSUPA (High Speed Uplink Packet Access) yet but plain 3G standards pushed to the limit. Even under average reception conditions, sending an eMail with a 2MB attachment was very quick with an average uplink data rate of about 350 kbit/s. Compare that to most 3G only networks today which usually support 64 kbit/s or 128 kbit/s at the most. 1 MBit/s ADSL connections usually have a 128 or 180 kbit/s uplink. So in this respect, current HSDPA even have a speed advantage in the uplink over a typcial 1 MBit/s DSL line.

Round Trip and Channel Establishment Delay

Round trip delays have also decreased a bit. While 3G connections usually have around 120-130 ms round trip delay times, I measured 90-100 ms to the first hop in the network over the HSDPA connection.

During the test it was also interesting to see that there is still a noticeable delay of 2.1 seconds in ping times or web page access time when no packets were transferred for some time. This is due to the fact that the network releases the HSDPA radio connection after some time of inactivity to reduce the power drain on the mobile’s battery and also the channel usage on the air interface. I experimented a bit and it seems TIM has set the transition timer to 15 seconds. Unless TIM has a stupid network implementation which drops the user to PMM IDLE state after this time, the 2.1 seconds are the time required for the transition from the FACH to HSDPA (DCH).

Summary

I am very impressed by the performance of HSDPA. Even my first generation category 12 data card exceeds a download speed of 1.5 MBit/s in a lightly loaded network and still over 700 MBit/s under normal network load conditions during the day. Uplink speeds beyond 350 kbit/s are very impressive as well. With further enhancements like category 6,7 and 8 handsets in the near future, multiple antennas in end user devices, enhanced receivers, improved signal processing, etc., etc., both end user speeds and overall wireless network capacity will continue to grow over the next couple of years. And beyond that, 3GPP Long Term Evolution is already in the pipe which ensures speeds will continue to rise. After all, the You-Tube generation needs as much bandwidth and speed as they can get!

Note: Click on the "HSDPA" category link below next to the date to see all articles on further tests which have followed afterwards.

In this press release Ericsson and Telstra (Australia) report that they have successfully tested a range update of Telstra’s W-CDMA UMTS/HSDPA network operating in the 850 MHz band to support cell ranges of up to 200 km. The press release says that downlink speeds of 2.3 MBit/s were achieved over this distance.

It would have been nice if the press release would have gone a bit more into the details of how this was achieved as that sort of range and speed can not be achieved with the typical cell site on a rooftop transmitting at 10 watts and a standard mobile phone in the hands of a user. It is more likely that a base station with high transmit power on an elevated position like a hill was used in combination with a stationary handset, power amplifier and directional antenna.

It would also have been interesting to hear some details from Telstra on where they plan to deploy this. Australia is a big country so I guess there is quite an opportunity this way to bring high speed internet to people living far away from cities where broadband Internet is available either by conventional UMTS coverage, DSL or cable. Also, this offers interesting opportunities to cover ship routes along costs.

The technical background: Looks like this is the result of Ericsson’s recent Release 7 work item in 3GPP on "Extended WCDMA Cell Range up to 200km" which was reported to completed in December 2006 in TSG#34. According to the work item, a Node-B (base station) so far was only able to report propagation delays on the random access channel in the order of 768 chips, or a range of about 60 km. The work item description further says that changing this parameter in the radio network has no impact on currently deployed terminals, hence, the measure is backwards compatible.

Note that for conventional network deployment scenarios, being able to report propagation delays for the random access channel of up to 60 km is more than enough given the fact that due to capacity reasons and propagation in urban environments, UMTS cells are usually spaced just 2 km or even less apart.