« Yes, Video Calls over 3G are Cool! | Main | WiMAX details from Intel »



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?


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.



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.



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,

Stefan Blomeier

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,



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.


Arvind Padmanabhan

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.


The comments to this entry are closed.

My Photo

The Books to this Blog

Secure Hotel Wi-Fi Sharing

My Pictures on Flickr

  • www.flickr.com
    martin.sauter's photos More of martin.sauter's photos


  • Clicky
    Clicky Web Analytics