How To Top-Up A Vodafone Prepaid SIM for Websessions

A final piece of information for users of Vodafone Germany Prepaid SIMs for Websessions has so far been missing: How to top-up without scratch cards that can only be bought in Germany!?

Here’s a link to an online service here that allows to top-up German prepaid SIM cards. The pages itself are in German but pretty easy to figure out for non natives as well. To top-up a Vodafone SIM card, select "Vodafone CallNow", create an account by typing in your eMail address, specifiy the SIM card’s phone number, select the amount to top-up and enter your credit card details. After a minute the selected amount is on the SIM card and can then be used for WebSessions. All quite straight forward and works well.

Deactivating the Vodfone Websession Compression Proxy

I am quite happy with Vodafone Germany’s Web Session offer that gives me fast 3G Internet access in most European countries and in some countries overseas. I’ve reported about this extensively here. One of the things that bothered me, however, was the automatic compression of pictures in web pages. This reduces the amount of data to be transmitted but in the times of HSDPA that’s not necessary anymore. When buying a PCMCIA card and the required software from Vodafone for the service there is an option in the software to deactivate the compression. If you buy a standalone prepaid SIM card however, things are a big more tricky.

One way to get around the compression is to use a VPN software that tunnels all traffic and thus Vodafone’s transparent HTTP proxy can not touch the pictures. In some circumstances, such a solution is not practicable or not even available to all users. So I searched a bit on the web to see if there are ways to deactivate the proxy without the Vodafone software. And indeed, there is! Here and here are two links to the original German articles that describe how the proxy can be instructed not to compress the picture. In essence this is done by including extra HTTP header lines in each page request which are picked up by the proxy and tell it not to compress the images. According to one article, this works for  Vodafone Germany and also for E-Plus, another German operator.

Header_modify_configuration_2To get these extra header lines into a request, an add-on called "Modify Headers" is required for Firefox. The add-on can be installed into the browser right from the Mozilla Add-On Web Page. Once installed, a new menu entry called "Modify Headers" is available in the "Tools" menu of Firefox. In the configuration tab, select "Always On: Enable Modify Headers when this window is closed". Afterwards, two new header fields have to be added manually. In the "Headers" tab, one new header called "Cache-Control" has to be created and another one called "Pragma". Both headers have to be set to contain "no-cache". That’s it!

Header_modify_headers
Restart Firefox and the nasty compression is gone. If you go to pages that have previously been loaded, they are probably still in the local cache and thus still look ugly. In that case, press "STRG" or "SHIFT" together with the reload button of Firefox and the images are refreshed to their non compressed state. Below are two screen shots of HTTP request packets traced with Wireshark that show how HTTP headers look before the tool is switched on and afterwards when they include the two additional header lines.

Http_headers_not_modified
Http_modified_headers

HSDPA On A High Speed Train – Part 2

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.

200kmh_throughput
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.

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

200kmh_round_trip
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.

Summary

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.

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.

Vodafone WebSessions Tested in A1’s 3G Network in Austria

As a frequent traveler I often use Vodafone Germany’s Websession offer which lets me connect wirelessly to the Internet in most countries in Europe and also in some countries overseas using 3G UMTS or 3.5G HSDPA. I’ve first reported about the details of the offer here and also posted reports of how well it performs in Italy, France and Switzerland in the meantime. This blog entry takes a look at how the offer performs in Austria:

A1’s 3G network (Mobilikom) coverage area throughout Austria is excellent and even in areas without 3G coverage, EDGE capable GSM base stations deliver throughput good enough for work and play. While in 3.5G HSDPA coverage, I reached top speeds of about 2 MBit/s when downloading three files simultaneously.

Single file download top speeds where at about 800 kbit/s. As in previous cases I am still a bit puzzled to why that happens as round trip delay time for the file download was around 230 ms. Together with a TCP window size of 65k, the throughput of a single TCP session should be 2.2 MBit/s. Note: For background information on the effect of the TCP window size and round trip delay times on throughput see here.

Nevertheless, 800 kbit/s per file is more than what I observed in Italy and France where bandwidth is throttled to around 500 kbit/s overall, independently of how many files are downloaded at the same time. Looks like Vodafone A1 does something differently with Vodafone Germany then the roaming partners in Italy (Vodafone Italy) and France (SFR).

So all things taken together the Websession performance in Austria is quite convincing, too.

HSDPA Performance Of Vodafone’s 3G Network in Italy Has Me Puzzled

Back I am in Italy for a while. I’ve grown quite accustomed to the great performance of the TIM HSDPA network, which I’ve described in a number of previous posts. This time around, I set out to test the Vodafone HSDPA network in Rome and to compare it with the results achieved in TIM’s (Telecom Italia Mobile) network. The results were quite a surprise.

I had two SIM cards to test the network. For the first tests, I used my German Vodafone SIM card and a Roamer WebSession, described in more detail here, to establish an Internet connection. As already experienced in the SFR network in France, file download speeds were capped at around 45 kBytes/s. While already quite good it falls far short of 160 kBytes/s that are reachable with my category 12 Sierra Wireless 850 HSDPA card in the TIM network.

Viws
In France I was quite uncertain if and where the speed was throttled down. With the help of the Vodafone Italy network, I can now add a further piece to the puzzle which unfortunately raises more questions then it answers. To find out more, I bought a local Vodafone prepaid SIM card for direct access to the Internet and not via the GGSN of Vodafone in Germany used by the German Vodafone SIM card. To my great surprise the download speed of the file was almost the same as with the German SIM card. In the IP packet inter-spacing diagram (for an introduction of how to interpret the diagram see here), however, the download of the same file with the two different SIM cards in the same network looks completely different. As can be seen in the first graph on the right side, the file download via the German Web Session in the Italian Vodafone network shows IP packet inter-spacing mostly around the 30 ms line. A clear but not yet conclusive indication for throttling. With the Italien SIM card however, most packets of the same file are transmitted with a packet inter-spacing time of 10 ms as can be seen on the left side of the graph. So the transmission would be much faster if it were not for the randomly distributed packet inter-spacing of quite a lot of packets between 50 ms and 200 ms. To be honest, I have no idea why some packets take such a long time to arrive. I don’t think it can be RLC retransmissions as the automatic retransmission of packets discarded by the Node-B’s HARQ process usually takes around 80 to 100 milliseconds. Also these inter-spacings were not caused by IP layer retransmissions.

More clues

Performance_comparison_vodafone_vs_
I then went on to do a direct comparison of the performance of the TIM network and the Italian Vodafone network by downloading two files from different servers to exclude the possibility that the Vodafone network has a problem with the connection to one file server. The result is shown in the second graph. On the left, the download speed for file 1 and file 2 are shown for the Vodafone network. Note the constantly changing top speeds. Afterwards I replaced the Vodafone SIM card with the TIM SIM card in the wireless card and performed the same downloads in the TIM network. The result is shown on the right side of the graph. The throughput is fairly constant and much higher than in the Vodafone network. When looking into the Wireshark trace the Vodafone throughput suffers from two things. First, the random packet inter-spacing times described above. Second, I have observed IP layer retransmissions every couple of seconds which also greatly reduce the download speed. The TIM network does not suffer from any of those.

Conclusions

As I repeated the tests over several days and at different times of the day a temporary error or network overload can be excluded as the reason. There are two likely causes for the problems observed in the Vodafone network. The most probable one is that there is an incompatibility between my Sierra Wireless 850 HSDPA card and Vodafone’s HSDPA network. It’s still early days for HSDPA so I would not be surprised if this were the case. Another possible cause could be that Vodafone has a big IP routing problem somewhere in the network. A good way to verify this would be to repeat the tests with a different HSDPA card or mobile phone. If the situation improves it’s an interoperability issue. If not, well, then it could still be both.

Vodafone WebSessions Tested At HSDPA Speeds

Websessions
A couple of weeks ago, Vodafone Germany announced during the CeBit that they will launch/lower their data roaming prices for their WebSession offer. On both prepaid and post paid Vodafone Germany SIM cards, WebSessions can be bought for €14.95 for a 24 hour period while roaming in many countries (for a list see below). While unlimited for now, Vodafone’s fine print says that a web session will be limited to 50 MB of data traffic starting in Seprember 2007. Definitely not on the cheap side for private travelers, the price will work for many business travelers when abroad for a couple of days. As I am one of those it was time to get a Voda prepaid SIM and give it a try.

How To Get A SIM

Apart from being very flexible with a prepaid SIM and not having to pay a monthly fee or being bound for a certain period a prepaid SIM additionally offers assurance that I will not come home one day to find a €3000.- invoice because I mis-configured my kit. This is not unheard of… As Vodafone Germany wanted €20.- for a prepaid starter kit, I decided to give eBay a try and got one for €2.-. The SIM card included €10.- worth of calls and Internet access, enough for a first test. Important note: As far as I know only German Vodafone SIM cards support WebSessions.

How to Connect

The most important thing with the WebSession offer is to use the correct Access Point Name (APN) when connecting. For this offer it is "event.vodafone.de". If a different APN is used other fees will apply for the connection so be careful. After establishing the connection any web page access is redirected to the WebSessions portal page of Vodafone. Here, one can either select to begin a new session or browse the Vodafone.de page for free. Unlike advertised, the only payment option I had was to deduct the price for the WebSession from the prepaid account.

Once opening the web session is confirmed on the portal page the connection is put into transparent mode and full Internet access is possible. Before being forwarded to the initially selected page the portal tries to open a popup window to show the remaining online time. This fails in both Firefox and the Internet Explorer with standard pop-up blocker options enabled. No harm done, the Internet connection works anyway. However, it might be useful to have this information. To allow the pop-up window to open, the pop-up prevention can be manually deactivated in the browsers settings for the portal URL only.

Performance

For my tests I used the HSDPA notebook card I already used for my HSDPA tests in Italy. As in the Italien TIM network, HSDPA performance in the German Vodafone network were superb with maximum data rates of 180 kBytes/s, which is around 1.6 MBit/s. This is the maximum speed supported by the card. Round trip delay times were at around 100 ms and I had the same 2 seconds delay after some time of inactivity, just as in Italy. So it’s likely that TIM and Vodafone Germany use the same radio network manufacturer, who is most likely Ericsson. The maximum uplink speed was a remarkable 384 kbit/s.

While talking about performance I’d also like to note that my desk is about 300 meters and two concrete walls away from the 3G base station. Therefore my reception conditions were excellent and unlike in Italy with slightly less favorable reception conditions, changes in antenna orientation had no big impact on throughput speed.

I also used the WebSession with an N93 connected to the PC and also quickly connected to the Swiss UMTS network which is available when I am on my penthouse veranda. All worked as it should, I am very satisfied!

Logging In and Out, eMail, VoIP and IPSec

A WebSession can be left and entered again as often as one likes while the clock is ticking. I connected and disconnected several times to check this feature one out and it works flawlessly as well. After every login, the portal page is shortly visited for the pop-up box to open up to show the remaining online time. Afterwards, the browser is immediately redirected to the requested page. EMail SMTP and POP3 works as well over the connection and my IPSec connection establishment to my company was working. Even Skype calls worked without a glitch despite Vodafone stating in their fine print that VoIP calls are blocked.

Automatic Web Page and Picture Compression

The only thing that I don’t like is the automatic picture compression on web pages Vodafone performs. While it helps to reduce the total transfer volume it’s not required to improve page download times over HSDPA. After all, the HSDPA connection is much faster than my ADSL line. I heard that it’s possible to deactivate the automatic picture compression with the Vodafone software that comes with their branded HSDPA cards. As I don’t use any Vodafone software or hardware I can’t change the setting. However, I can deactivate split tunneling in my IPSec client. Afterwards all data traffic is sent through the encrypted tunnel to the corporate network. This prevents the transparent web proxy in the Vodafone core network to touch the pages and pictures and things look as they should. Not a perfect solution to the problem but it works for me.

Supported Roaming Countries

Belgium (Proximus), Denmark (TDK), Finland (Elisa), France (SFR), Greece (Vodafone), U.K.  (Vodafone), Ireland  (Vodafone), Italy (Vodafone), Lichtenstein (Mobilkom), The Netherlands (Vodafone), Austria (Mobilkom), Portugal (Vodafone), Switzerland (Swisscom), Spain  (Vodafone) and Germany (Vodafone).

Summary

For me, WebSessions are a great way to stay connected while traveling in other countries especially now that another program I previously used abroad has expired. It would be nice if the price comes down a bit more to also make it attractive for non-business travelers and if there was an easier way to deactivate picture compression. However, I can live with both drawbacks for the moment. I also used a WebSession with the built in applications of my Nokia N93. You can read about this in the next blog entry.