HSDPA Performance in Operational Networks Part 4

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.

Hsdpa_packet_interspacing_different
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…

Outdated Wifi WEP Encryption Can Now Be Broken In Less Than 1 Minute

Wifi networks have been around for a number of years now. At first the WEP (wired equivalent privacy) encryption algorithm was used to protect network owners from eavesdropping and misuse of their networks by others. Due to a number of security flaws, however, WEP was superseded by WPA (Wireless Protected Access) and WPA2. Nevertheless, most Wifi networks deployed today in my experience still use the old WEP encryption. Over the years, ever more clever schemes have been devised to crack the WEP encryption. The latest combination of attacks can now break the encryption scheme in less than a minute.

WEP started to fall apart in 2001 when Scott Fluhrer, Itsik Mantin, and Adi Shamir published an attack which allowed to break the cipher by analyzing about 6.000.000 intercepted frames. The number sounds quite large at first. However, users in a highly loaded network can generate the required number of frames in a number of hours. In 2004 a hacker named KoReK devised a new attack which only required 500.000 to 2.000.000 frames.

Waiting for packets can be tiresome. Unfortunately, WEP is not secured against replay attacks. This can be exploited by inserting intercepted packets back into the network to trigger response frames with unique ciphering keys from computers attached to the network. Thus, an attacker no longer has to wait for clients to generate traffic but he can trick the attached computers to automatically create the frames for him. This additionally greatly reduces the time required for an attack.

Now, researches at the Technical University Darmstadt, Germany have refined an attack strategy by Andreas Klein, which is based on the original Fluhrer, Mantin and Shamir attack. This new attack now only requires 85.000 frames to calculate the cipher key with a success probability of 95%. Together with the key replay attack WEP can now be broken in less than a minute.

All these attacks are not only theoretical in nature. Tools are available for all of them to automate the process. As a proof of concept, the TU Darmstadt researches have extended one of these tools. More information about their work can be found here.

All of this is quite scary. So if you still operate a Wifi with WEP encryption it’s time to change to WPA. If you access point does not support it yet, it’s time to throw it away and buy a new one.

Via: Heise Online

3G Connections Over 15km

Some time ago I reported how Telstra and Ericsson have implemented UMTS cell ranges of 200km. This is mainly designed for very rural areas and I am not quite sure what kind of terminal is required at this distance to communicate with the cell tower. I very much doubt a normal cell phone will do. While I was trying out a new Vodafone data roaming offer, however, I tested a UMTS connection while being in Germany with a cell tower of Swisscom in Switzerland.

The place I live in Germany is close to the Lake of Constance and obviously the cell tower of Swisscom has to be on the other side of the lake. I am not sure of the exact distance to the UMTS base station but on a map the shortest direct line of sight from my veranda to the other side is 15 km. My veranda is also slightly elevated and I can see the other side of the lake from there. Thus, I have a direct line of sight connection over that distance and there are no blocking obstacles such as buildings or hills in between. Usually, the antennas of 3G cells are directed a bit downwards to only cover a range of 1 or 2 km. In this case, however, the antenna is adjusted differently to cover as much of the lake as possible. This has the interesting effect that I can still receive the network 5 km inland on German territory.

I didn’t only see the Swisscom 3G network in the network search screen but I could also connect to it, establish an Internet connection and surf on some web pages. The speed was not great but it worked o.k. So while it was certainly not 200km, it’s interesting to see that a "non turbo charged" UMTS network works over such distances.

At this distance, network coverage is not very strong. When I moved between the antenna of the HSDPA card and the lake, the connection was immediately lost. A clear sign that the only thing that keeps this connection going is the line of sight environment.

Mobile Roaming Strategies Conference in Barcelona, Spain

Next week, Barcelona will see a small but maybe quite influential conference on Mobile Roaming Strategies. From the 16th to the 19th of April, operators from around the world will discuss everything about GSM and UMTS voice and data roaming. Topics from the home page of the event:

  • "Develop innovative strategies to recoup lost roaming revenues due to regulatory pressures". My comment: Gee, there is a lot of explosive potential in that one…
  • "Build attractive voice and data pricing models which encourage roaming mobile usage". My comment: Hello, I can see the word ‘data’ in that sentence! Good!
  • "Focus on your VAS strategy to reduce roaming revenue leakage and increase usage". My comment: I wonder what ‘roaming revenue leakage‘ is. Anyone?
  • "Examining techniques to Increase take-up of roaming data services". My comment: Tip: Affordable prices would help tremendously. No need for discussion, just do it! Vodafone Germany has gone ahead and done a positive step with their WebSessions roaming offer. Let’s have some competition here!

It’s not only operators giving presentations, however. It looks like Stephen Banable, working for the Information Society and Media DG of the EU Comission will hold a presentation as well. Into the lion’s den Stepehen…

I’d really like to see the presentation material distributed at this event, especially for the first and second bullet points above. Anybody reporting from this event?

    • HSDPA Antenna Fine Tuning

    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.

    Aircard850
    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.

    Hsdpa_antenna_throughput
    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:

    Bearer Awareness Required for Fixed Mobile Convergence

    Dean Bubley over at Disruptive Wireless has written an interesting article describing why applications running on multi bearer mobile handsets (read GSM, UMTS, HSDPA, Wifi, UMA, Femtocells) must be aware of  which networks are available and react accordingly:

    • Some bearers are not terminated in the operator network: Think local network, phones interact with local equipment such as PCs, VCRs and home appliances in general.
    • Different bearer characteristics. Some bearers are fast, some are slow, some are cheap others are expensive. Applications should adapt to this.
    • To access web pages and services outside the operator’s domain it’s not necessary to tunnel the IP traffic through its backbone in case several bearers are available and one gives direct access to the Internet.

    A well researched article, I fully recommend to read the full piece. And a quote from it to finish:

    "A lot of people don’t understand all this [the points above], particularly if they work at a mobile operator and still fervently believe that anything you do on a handset is "a service", rather than understanding that sometimes you want to do non-service activities as well."

    Some US Operators Block UMA Wifi Access While Roaming Abroad

    Steve Shaw over at UMA Today posted an article already back in February on using your UMA (Unlicensed Mobile Access) GSM/Wifi phone abroad. Here’s what he had to say:

    "For me, making a call with my US [United States] SIM when I was in Barcelona cost about $1/minute. With
    a UMA-enabled phone, technically I should be able to connect to any
    Wi-Fi AP and calls would be local and therefore billed at my normal per
    minute.  But mobile operators like the roaming
    revenues, so most UMA service plans disable the use of Wi-Fi access
    outside the home country.    "

    UMA is a great technology. However, the above example shows once more what operators sometimes do to great technology when they and not the users are in control. Compare such an offer to what you can do with open GSM/UMTS/Wifi phones such as many Nokia N-series and E-series phones as well as many Microsoft Mobile equipped PDA phones these days that can run open, non operator restricted VoIP software that works anywhere around the world. You are the consumer, you have the choice…

    Background:

    Apple claims 802.11n Wide Channels Are Not Allowed In Some Countries

    Here’s a mystery for which the web doesn’t seem to have an answer for so far: Apple claims that the use of a 40 MHz Wide Channel for 802.11n Wifi is not allowed in Austria, Estonia, Germany, Japan, Latvia, Slovakia, Spain and Great Britain. Consequently, Apple.fr says the new Airport Extreme is 5x quicker than the previous product while Apple.de advertises the Airport Extreme as 2.5x quicker.

    I’ve done some research as to why this should not be allowed in Germany but came up empty handed. Other web sites such as this one have the same question. Anybody got an explanation for this?

    The HSDPA Air Interface – A Peek In 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.

    HsdpainterspacegraphaverageconditioSo 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.