3G and HSDPA Internet Access On A High Speed Train

So far I’ve tested HSDPA all across Europe and have enthusiastically reported the great results on this blog (see here). Usually, I use HSDPA in a nomadic fashion, i.e. while being at home, in hotel rooms, on customer sites, etc. This is simple for the network, not much mobility management, no handover, stable radio environments, thus not much of a challenge. But how does HSDPA perform on a high speed train? I didn’t know until recently when I took a German ICE high speed train on the brand new LGV Est Européenne (Ligne à Grande Vitesse) from Paris to Frankfurt.

From a radio point of view the line is kind of black and white. On the French side, UMTS / HSDPA radio coverage is almost non existent. Even while still in Paris, my mobile frequently lost the 3G network once we got out of the train station. Once on the German part of the track, however, I had HSDPA coverage about 70% of the time during the 2h trip between Saarbrücken and Frankfurt. During the rest of the time, my connection fell back to the 2G network and there were only very few places without any network coverage at all.

The Network Under Test: Vodafone Germany’s 3.5G network

The Test Equipment: No fancy stuff, just a notebook and a Motorola V3xx HSDPA category 6 mobile phone, bought back in Rome a couple of weeks ago.

The Result:

During the 2 hours I ran a lot of throughput tests and downloaded around 75 MB of data. The Train speed during most of the tests ranged between 150 and 200 km/h. Very surprisingly, speed did not seem to have a great impact on the data rates. No matter how fast the train was going I always got peak data rates of about 1.5 MBit/s while radio coverage was good.

As there was no dedicated 3G radio coverage for the track there were of course also periods during which radio coverage was poor. Here, data rates dropped but were still at a respectable level of around 250 – 500 kbit/s.

I was also very positively surprised of the handover performance. Shortly before a handover occurred, radio conditions usually got quite bad so the file downloads slowed considerably. Then there’s a gap of around 1 or 2 seconds before the situation improves and the transfer speeds recovered within a few seconds. Downloads of 6 MByte files had an average throughput according to Wireshark statistics of 850 kbit/s with peak data rates of around 1.5 MBit/s. Not a single download failed!

To get a better feeling for the handover behavior I checked the link stability during handovers by sending pings to the network. Packet loss was minimal and seldom were two ping responses lost in a row which would have pointed to a prolonged network outage. To see how many packets are lost during handover I set the ping timeout to 500 ms. Here, single packet loss started to increase which points to a connection interruption during handovers or multiple failed RLC retransmissions during bad radio conditions. Most packets that were reported as lost due to the reduced timeout where nevertheless delivered, just a bit too late to be counted as a valid response. A Wireshark trace revealed that almost all ping responses eventually made it back to the notebook. This test indicates therefore, that HSDPA handovers take between 0.5 and 1 seconds. Sounds almost too good to be true. When analyzing some of the Wireshark traces in which I recorded the throughput tests, however, I could see that at some points the radio connection was lost for about 2.5 seconds (more about this in the next episode). Whether this was due to handovers or simply very bad radio conditions is difficult to say. But even if this can be attributed to handovers only it’s not too bad for a start. It’s probably also important to point out that it’s still early days for HSDPA and optimal handover performance was surely not very high on the R&D agenda so far.

File downloads and ping experiments are not the typical network usage so I also tested sending and receiving eMails and web browsing. I have to say I felt little to no difference in page download times compared while moving at high speed in a train compared to sitting at my desk at home.

Also worth mentioning is the software stability of the Motorola V3xx mobile. While most other mobiles I used in the past have sooner or later become confused by the many handovers and 2G/3G network changes with an active Internet connection, the V3xx was rock stable. Not a single reboot was required during the whole trip and the mobile even performed 2G to 3G network reselections during file transfers.

Apart from the good HSDPA performance, Vodafone has made a good job engineering their network between Saarbrücken and Frankfurt. During the two hours the Internet connection did not drop once  (e.g. due to missing datafill on the SGSNs for intersystem handovers). This is rather exceptional as on other lines, like for example between Munich and Stuttgart, my Internet connection usually drops a couple of times. So whoever did the network verification along that track, please Vodafone, send him to optimize the Munich – Stuttgart line as well. And while you are at it, install additional 3G base stations along the line, I’d really appreciate the same performance as between Saarbrücken and Frankfurt.

Summary

Before doing the tests I was a bit skeptical about the outcome. The good results, however, speak for themselves and certainly answered a lot of questions concerning high speed Internet access on high speed trains. The results also indicate that dedicated 3G train line coverage would fill the gaps observed and result in a very smooth user experience independent of train speed and also without any on board equipment such as 3G/Wifi bridges.

Stay tuned for the technical deep dive once I have analyzed the Wireshark trace I took in more detail.

6 thoughts on “3G and HSDPA Internet Access On A High Speed Train”

  1. Hi Martin,
    thanks for your answer.
    Is there any bluetooth-connection that meets HSDPA speed possibilities?

  2. Hi Martin

    Here you have tested for external pdp context. Is it possible for you to test for an internal PDP context, where TCP/IP layers of phone would be coming into picture, rather that that of PC.

    Regards,
    Gopi

  3. Hi Martin

    Here you have tested for external pdp context. Is it possible for you to test for an internal PDP context, where TCP/IP layers of phone would be coming into picture, rather that that of PC.

    Regards,
    Gopi

Comments are closed.