In the previous blog entry (here) I have started to report my experiences while using Vodafone Germany’s 3G HSDPA network on board of a high speed train from Saarbrücken to Frankfurt. On this line the 3G network experience is quite positive and for the general remarks see my first entry. In this second entry I’ll now show some information retrieved from Wireshark traces I took during the ride. They reveal stuff that is very difficult to simulate in the lab without special equipment. In short, a treasure chest for the TCP researcher.
All figures shown in this blog entry were made at a train speed of about 200 km/h and come from a trace of a 6MB file download. Figure one on the left shows the throughput during the file download. Total transmission for the file was about 75 seconds, top throughput about 1.5 MBit/s and average throughput about 800 kbit/s. During the file download three transmission outages can be seen at 25s, 43s and 64s. Each of them lasted about about 2.3 seconds. These timeouts where either caused by a handover or by very bad network coverage at these times.
The trace behind the graph reveals that despite the outage no TCP packets where lost so obviously the RLC layer of the radio network recovered all packets. On the TCP layer, however, such prolonged outage times without acknowledgments provoked a TCP timeout resulting in the automatic retransmission of about 15 kBytes of data (11 packets). This is shown in figure 2 on the left. Packet 2796 marked in black is the last packet received before the outage at 23.52s. Communication resumes at 25.76 seconds and it can be seen that no packet is missing by looking at the ACK numbers. The green packets that follow must thus have been saved by the RNC in the radio network. Starting with packet 2809 the sender suddenly retransmits packets (the black block in figure 2) that have already been received and ACK’d after the outage. However, the ACK’s were not received by the sender of the data in time which provoked the TCP timeout and the automatic retransmission.
Figure 3 on the left shows the packet interspacing diagram for the file download which tells a lot about HSDPA HARQ (Hybrid Automatic Retransmission Requests) operation on layer 2 of the air interface between the Node-B and the mobile. I was quite surprised to see that even at such high user speeds most packets where delivered without retransmission, and only about 20 – 30% going through one retransmission. This is quite similar to the traces I made when not moving as shown for example in this blog entry.
The trace discussed above shows impressively that high speed Internet access on board high speed trains without any on board equipment is possible. The radio network used for the test was certainly not optimized to give the best coverage along the railway. Nevertheless, overall throughput and recovery behavior on the TCP layer are impressive.
2 thoughts on “HSDPA On A High Speed Train – Part 2”
Here in the performance, there was one thing which also mattered was handling of out of order(OOO) TCP packets by your PC. As RFC 793 is silent on what needs to be done with OOO TCP packets. Had your PC dropped them, then it would have ended up in a loop where retransmissions are retransmitted again and again, as your PC keeps dropping OOO packets and on NW side TCP retransmission time keeps firing out for each packet.
But for UEs, as RAM is at premium, dont think they have so much of enough size to queue OOO packets. Would like to know, what would be the performance for internal contexts.
unfortunately tracing from the mobile phone is not possible as there is on api to capture the ip packets in a file. concerning he traces I will gladly make
them available to you when I return good next week.
TITLE: Compare High Speed Internet Services
BLOG NAME: Compare High Speed Internet Services
DATE: 07/30/2007 10:58:24 PM
instantly finds the best High Speed Internet. Use our guide to locate the best DSL, Cable, Sa
Comments are closed.