HSDPA, the 3.5G speed booster for UMTS networks is up and running in many neworks these days and data cards have been available for some time. Now, HSDPA phones have entered the market with Samsung’s SGH-ZV50 and Nokia in close pursuit with the N95. As an article in the latest C’T, a german computer magazine, points out, some tweaks are required for the TCP/IP stack of the notebook to achieve full performance.
The tweak mainly consists in increasing the "TCP Receive Window" to 128480 bytes. The window is used to throttle a data transfer by using receiver acknowledgements which advance the receive window. This prevents receiver buffer overflows in the routers between source and destination which would appear if the sender has a faster connection to the to the network than the receiver. As HSDPA has a delay time of about 150ms, which is about three times higher than an equally fast DSL connection, three times more unacklnowledged data can be in transit. An appropriate window size should be much higher than the bandwidth delay product (BDP) of the connection. Take a look here for further explanations. For a 1800 kbit/s HSDPA link and a round trip delay time of 150 ms plus let’s say an additional 80 ms delay in the Internet, the BDP is about 52 kBytes.
Other values Vodafone suggests to change is to increase the "Maximum MTU size" (packet size) to 1500 and to set the "Maximal TCP connect request retransmissions" parameter to 5.
The Test Run
To see if changing the values has a positive effect, I gave it a try myself. I don’t have an HSDPA mobile yet (it’s all in Nokia’s hand…) so
instead I tried the settings on my fast ADSL2+ Internet connection.
While the round trip times of the ADSL line are quicker than HSDPA, the total bandwidth of 7 MBit/s (7000 kbit/s) I get on the line is much higher than HSDPA. Thus, changing the TCP window size should have an impact as well. To compare, I went to a web site that does not throttle transmissions on its end and downloaded a file. I achieved a download speed of about 3.5 MBit/s. With
the new TCP window setting the speed went up to an amazing 7.000 kbit/s, i.e. the line was fully utilized. So if you
have an ADSL or ADSL2+ connection with a speed exceeding 3.5 MBit/s the
tweak is not only helpful for HSDPA but also for your ADSL connection
at home.
How to Change the TCP Window Size
The TCP Window Size for Windows XP can be optimized with programs like Tweakmaster or TCPOptimizer. While Tweakmaster is easier to handle, their registration process for the free version is somewhat dubious. TCPOptimizer is really free but only seems to be able to change the settings for all network cards at once instead of individually.
It’s also possible to change the parameters manually in the Windows registry. For network cards, the TCP receive window can be changed on a per adapter basis in the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersInterfacec{Interface ID}. If not already present, create a new DWORD called TcpWindowSize and assign it a value of 64240 (decimal). I also tried to set it to 128480 but for some reason the value is not accepted and the standard window size of 17520 bytes is still used after a restart.
For dial up connections things seem to be handled differently by the operating system. Here, global values which are valid for all network connections have to be changed. These can be found in the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters. If not already present, create the following DWORDs and assign them a value of 128480 (decimal): TcpWindowSize and MaxTcpWindowSize.
To activate network card specific changes the adapter has to be deactivated and activated again. For global values to take effect a reboot is required. If HSDPA is not always available it might be a good idea to remove these values before using a slower connection. This might proove to be somewhat impractical to do on a day to day basis due to the required restart.
To simplyfiy the process I’ve created to short scripts which add or remove the TcpWindowSize parameter from the list of global TCP parameters. Still, a reboot is required. You can find the two scripts at the end of this blog entry. The script to add the parameters is a .reg file so it can be executed by double clicking on the icon. The script to remove the parameters again is a .inf file which has to be executed by right clicking on the icon and selecting "execute" from the menu.
Bluetooth and HSDPA
A word to HSDPA mobile phone manufacturers: Make sure you put Bluetooth 2.0 into your phones as version 1.2’s top speed of 723 kbit/s is far too slow for HSDPA. I don’t want to be stuck with a cable again!
hi,
this question has been bothering me for some time.
ya, it is about the TCP/IP over the HSDPA.
HSDPA downlink data rate is going to increase 3.6 Mbps and higher, my question is – how much uplink data rate is required to ensure that sufficient “pipe” is provided for the TCP “ACK” to be sent to the sender host?
thanks!
I don’t have such a card yet so I tested the scenario with my 1 MBit/s DSL line. If fully utilized, I have about 24 kbit/s uplink utilization for TCP ack’s. Consequently if you get the full HSDPA 3.6 MBit/s you need 24 kbit/s * 3.6 = 86 kbit/s for the TCP ack’s in uplink direction. Thus, a 64 kbit/s uplink bearer is not sufficient, it takes at least a 128 kbit/s bearer. Many vendors have also increased uplink data rates to 384 kbit/s so their is enough “air”, so to speak, for further downlink enhancements, even before HSUPA hit’s the market.
Martin
hi Martin,
thanks for the response.
In your estimation above, you assumed that the wired TCP (DSL) and wireless TCP (HSDPA) are the same, in term of providing the physical pipe for the transport protocol.
/unwired
Yes, your statement is correct.
The difference between a DSL uplink bearer and a UMTS/HSDPA dedicated uplink bearer is, apart from the different maximum speeds, the latency. A 128 kbit/s UMTS/HSDPA uplink bearer is capable of transporting exactly this bandwidth on the IP layer. The latency of the wireless bearer, however, is much higher than that of a DSL link. This has an impact on the required TCP window size as discussed in the original blog entry.
Extra latency on the other hand has no impact on the bandwidth required for the TCP Acks. As notebooks use the same kind of TCP over both fixed and wireless links the required uplink bandwidth for TCP acks is the same for both fixed and wireless networks.
I mainly mentioned that I came to my conclusion with the help of a DSL connection instead of an HSDPA connection to be precise rather than to imply that the result for wireless would be different.
Best regards,
Martin
hi Martin,
I think that a 64 kbit/s bearer is sufficient in uplink as TCP uses in the laptop a Delayed ACK mechanism. So if the CAT6 data card of hsdpa gets a big IP-frame of 1500 bytes every 4 ms, then about every 8ms a TCP-ACK needs to be sent via UE in uplink. If the TTI = 20ms, then the MAC in UE will get about 2 x TCP-ACKs in those 20ms and then RLC-AM will delivery 3 RLC-PDU’s per 20ms because of the Length Indicator issue and assuming that the TCP-Acks are only 40 bytes gib – no special option.
In my opinion, 120 bytes per 20ms will lead to 48 kbit/s which is sufficient if you do not want to have uplink user data transfer in parallel.
What do you say?
kind regards,
Stefan
Hi Stefan,
I think your calculation is correct if no fragmentation is used. I have seen some cases of fragmentation though in which instead of a 1520 bytes packet a 104 byte and a 1464 packet is sent in sequence. The delayed ACK then acks those two packets instead of a long one which doubles the data rate. It might be that this is what happened in my initial test above.
In practice I usually get a 128 kbit/s bearer assigned and in some networks even a 384 kbit/s bearer (when radio quality is good). So no bottleneck here.
Cheers,
Martin
Hi Martin,
For better capacity utilization, shouldn’t the network be allocating the minimum BW to carry the UL ACKs? Even the example given by Stefan appears to be on the high side. If PDCP is using header compression, even a 32 kbps bearer ought to be sufficient. What is your opinion?
— Arvind
In uplink the mobile is allowed to select the spreading factor and coding. Thus even if the network allows the mobile to use a high bandwidth it can still select to conserve resources by doing the right selection. Thus it should have no impact on bandwidth availability for others.
Also, it seems that the uplink is power constrained rather than interference constrained so an ‘over-use’ of bandwidth by a mobile should not matter.
Cheers,
Martin
—–
PING:
TITLE: Default TCP window size of Windows Mobile devices
URL: http://blogs.msdn.com/zhengpei/archive/2006/11/07/default-tcp-window-size-of-windows-mobile-devices.aspx
IP: 209.34.241.63
BLOG NAME: Mobile Computing and Technologies
DATE: 11/08/2006 02:11:31 AM
Using remote registry tool, I can verify that the default maximum TCP window size (buffer size) of a