In a communication network system such as the UMTS terrestrial radio access network (UTRAN), there are two potential bottlenecks, namely, the air interface and the transport network (transport link) connecting the radio network controller (RNC) and Node B. The transport link between the RNC and Node B is a potential bottleneck when its capacity is smaller then the available maximal capacity of the Uu interface. For example, a typical scenario is that the Node B is connected to the RNC through an E1 link with a capacity of approximately 2 Mbps, and in this case the available Uu capacity for the high speed downlink packet access (HSDPA) may be significantly larger that 2 Mbps. This means that a single user equipment (UE) with good radio conditions can overload the transport network (TN).
The fair sharing of Uu resources is the task of the Uu scheduler, but the Uu scheduler can not cope with the TN bottleneck, i.e. the transport link bottleneck. In order to deal with the TN bottleneck a flow-control (FC) mechanism has been introduced. FIG. 2 shows the location of the FC in the protocol stack. The goal of the FC is to efficiently use the TN in a fair manner.
Lack of FC causes serious performance degradation when the transport network is the bottleneck. In this case the TN buffer is typically full, causing high TN delay and loss ratio. This causes exhaustive radio link control (RLC) retransmissions which results in a much lower throughput. In addition to this, an RLC reset and a consequent transmission control protocol (TCP) timeout may also occur.
The flow control operates per-flow basis, i.e. each HSDPA flow has its own (i) congestion detection, (ii) bitrate calculation and (iii) shaper part. The main tasks of these three parts are the following:
1) Congestion Detection Part in the Node B
Based on the arrived packets from the RNC there is an attempt to determine the congestion level of the transport network. If TN congestion is detected, the bitrate calculation part is informed. A gap in sequence numbers of arriving packets is interpreted as “hard” congestion, because with a very high probability this event is due to packet loss in the TN caused by serious congestion. In addition to this, the variation of the one-way packet delay between RNC and Node B is also measured, i.e. a given fraction of packets have a time-stamp. If this delay starts to increase, probably due to queue build up in the TN, then it is interpreted as “soft” congestion, but if this delay build up is getting too large, e.g. larger than 60 ms, it is interpreted as “hard” congestion. The bitrate calculation part will react on hard and soft congestions in different ways.
2) Bitrate Calculation Part in the Node B
This part of the flow control calculates the current maximum bitrate of the flow. This bitrate is allowed by the transport network for that flow. The applied algorithm is conformed with the additive increase multiplicative decrease (AIMD) property that guarantees convergence to fairness; all flows converge to an equal share of resources in steady state, where no flows join or leave. The FC maintains an internal variable for the maximum bitrate of the flow. This bitrate is increased linearly if there is no TN congestion, i.e. no reported congestion from congestion detection part. If congestion is reported, the bitrate is reduced by 50% in case of hard congestion and reduced by 10% in case of soft congestion. When a new flow arrives, in this way a new FC entity is created, a slow-start like mechanism is used to find out the proper starting bitrate of the flow. After the first congestion, the FC behaves the above described AIMD manner. If the calculated bitrate of the flow changes significantly, then the shaper is informed about the new bitrate through a control frame called a capacity allocation (CA). To avoid too high processing load, this part of the FC is executed periodically with a 100-ms period, i.e. the bitrate calculation part is executed every 100 ms.
3) Flow Shaper in the RNC
The task of the shaper is to shape the flow according to the signalled maximum flow bitrate. This bitrate is coming from the latest received CA control frame.
The current HSDPA flow control solution provides fairness only in long term due to the convergence of AIMD property in case of a TN bottleneck. Fairness is provided only among flows sharing the same TN bottleneck. The initial shaping rate calculated by the FC has significant effect of the fairness and the time of the convergence. If a new flow arrives into the cell, e.g. due to handover, the existing algorithm operates as follows:
Firstly, it estimates maximum achievable bandwidth on the transport network (maxHsRate) and the maximum achievable peak rate for HS in the given cell (maxUuRate).
Secondly, it counts the number of active flows belonging to the Node B (nPqsRbs) and to the cell (nPqsCell). Noticeable is that the new flow also is counted in these counters.
Finally, it calculates the average bitrate on the transport network and in the cell by dividing the bitrates by the number of ongoing flows respectively. Then it chooses the minimum of them as initial shaping rate of the new flow. Additionally, there is an upper limit (hsSsStartPointMax) for the initial shaping rate to avoid too high initial rates.
In another words, this calculation estimates the theoretical fair bandwidth share from the estimated maximum available bandwidth assuming the system is fully utilized and the flows share it equally. Then it sets this as the starting point of the new flow. For instance, if the maximum achievable bandwidth on the transport network is 2 Mbps, the maximum achievable peak rate in the cell is 3.6 Mbps, on the transport there are 5 parallel flows, but on the cell there are only 3 flows and the hsSsStartPointMax is 500 kbps then, the initial shaping rate of the new flow is:CAinitial=min(2 Mbps/6; 3.6 Mbps/4; 500 kbps)=333 kbps  (1)
Noticeable is that this calculation contradicts the per-flow manner, since the number of flows is aggregated information about the system. In case of steady state, when the HSDPA flow control entities have enough time to find the fair share of the flows, and there is unused capacity neither in the transport network nor in the cell, the above introduced methodology provides good estimation of the fair share, so the convergence will be very fast.
However, the above described solution requires an estimation of the maximum achievable transport network bitrate. One option for this estimate is a parameter configured based on knowledge about the transport network architecture.
Further, the initial bitrate calculation relies on rough estimations and, the initial bitrate calculation does not take fairness into account.
If the estimation of the maximum achievable bandwidth on transport network (maxHsRate) or the maximum achievable peak cell rate (maxUuRate) is not accurate, they typically overestimates the real ones, the initial shaping rate will be quite far from the optimal and also in terms of fairness. Typically the actual available bitrate for HSDPA is smaller than the maximum, due to the bitrate used by higher priority traffic.