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.

2 thoughts on “The HSDPA Air Interface – A Peek In With Wireshark”

  1. Hi Martin, very interesting analysis. I was wondering though, how can the dots around the 1,2,3ms etc be accounted for?

  2. Hello Mark,

    It’s difficult to say without a layer 1 tracer but here’s a likely explanation for the 1-3 ms packets: As described above a 1500 byte packet requires at least four 2 ms MAC frames. If a transmission error occurs, sometimes only one of these frames is affected. It takes 8 ms to report the transmission error and depending on if the first or the fourth of the 4 MAC frames was damaged there are is a gap of 1-4 frames before the erroneous frame can be retransmitted as seen from the end of the fourth frame. These are not left empty by the MAC layer but are instead filled with the data of the next IP packet already waiting in the transmission queue. This packet, however, can not be delivered to the IP layer unless the previous packet has been received correctly. So once the erroneous block has been delivered successfully, the MAC layer can then reconstruct the IP packet and deliver it to the IP layer. Then, the next packet is already there, too or at least most of it. Thus, the MAC layer can almost immediately or shortly afterwards, if one or two 2 ms frames are missing, deliver it to the IP layer. There are different scenarios depending on which of the four frames of an IP packet has to be retransmitted.

    And then there is also the possibility that one of the frames of the second IP packet was also not correctly transmitted and is interleaved with the next IP packet. You see where this leads 🙂

    Best regards,
    Martin

Comments are closed.