Method and arrangement for tcp flow control

ES 2 397 629 T3

DESCRIPTION

Method and arrangement for TCP flow control.

Field of the invention

The present invention relates to TCP (Transmission Control Protocol) flow control, and particularly (though not exclusively) to TCP flow control in wireless communication systems.

Background of the invention

TCP is a transport protocol from the collection of Internet protocols (see, for example, WR Stevens' publication, "TCP / IP illustrated, Volume 1: The protocols," Addison-Wesley, Reading, Massachusetts, November 1994 ). It is used in applications such as telnet FTP (File Transfer Protocol) and HTTP (Hypertext Transfer Protocol). TCP is designed for wired networks that have very low error rates.

Flow control in TCP is governed by two windows: the congestion window ("cwnd") of the sender and the announced window ("awnd") of the receiver. Flow control is based on the minimum of these 2 windows. The "cwnd" is dynamically modified to match the capacity of the network. Most importantly, it is reduced whenever packets are lost as this is an indication of network congestion. The "awnd" is based on the receiver's ability to temporarily store data that it receives and can be dynamically reduced if the receiver cannot cope with the data reception rate. The initial value of "awnd" is controlled by parameters configured in the TCP protocol stack.

As mentioned above, TCP is designed for networks with a low error rate. Therefore, any packet losses that occur in TCP are considered to be due to network congestion and, therefore, are followed by a reduction in the “cwnd” and consequently in the sender's data rate such as It has been mentioned above. However, this is not appropriate for wireless networks that are inherently high error rate systems. Therefore, the standard of the 3GPP (3^to Generation) provides ARQ (Automatic Replay Request) functionality, known as RLC (Radio Link Control - see, for example, the 3GPP technical specification, 3GPP TS 25.322) that allows packets that have experienced errors to be retransmitted due to transmission over the air interface. However, the use of ARQ schemes results in packets arriving out of order, so they must be temporarily stored before they can be passed to TCP. The use of temporary storage introduces an increase in delay and this can result in an increase in RTT (Round Trip Time).

Assuming the highest speed services are provided on the downlink, this means that large buffer storage is likely to be required at the network node, i.e. the RNC (Radio Network Controller) in the case of systems 3GPP. The following considers this downlink (DL) problem. However, the present invention is also suitable for controlling uplink TCP flows.

The maximum DL speed specified in the 3GPP technical specification, 3GPP TS 34.108, is 2 Mbps. Assuming that it is not possible to modify the TCP protocol stack at the receiver (that is, the UE), it is therefore necessary that the UE advertise a window that is at least equal to the product of bandwidth times delay, appropriate for the 2 Mbps service. If the UE is to support the maximum speed of 2 Mbps, then the advertised window must be extremely large. If in that case a lower speed is provided to the UE (due, for example, to the fact that many UEs are requesting service at the same time), then a buffer overflow could occur. If there is no buffer overflow, the round trip time (RTT) will be very high as the data will be temporarily stored on the network node for a long time.

A high RTT will have a negative impact on the performance perceived by the user. This is particularly the case when the user wishes to continue browsing the web while downloading a large file via FTP; the web browsing session will appear extremely slow. Therefore, it is desired to provide a flow control technique in order to maintain a target RTT for any speed provided by the network while maintaining the ability to download data at speeds up to the maximum speed of 2 Mbps.

As previously mentioned, flow control is provided by the emitter "cwnd" and the receiver "awnd". Since control of the sender's "cwnd" resides on the server, it can be remotely located and is in no way controllable. Therefore, flow control needs to be provided by the “awnd”.

ES 2 397 629 T3

Various schemes (described briefly below) have been suggested for flow control for TCP over 3G wireless systems. However, the issue most of them take care of is preventing the buffer in the network node from overflowing (i.e. the sending node in the case of data download).

In the publication of Koga, Kawahara and Oie, “TCP flow control using link layer information in mobile networks”, Proceedings of SPIE Conference of Internet Performance and Control of Network Systems III, Boston, Massachusetts 7, 2002, it is proposed that the receiver, that is, the UE in the most probable case of file download, modify the TCP window that is advertised by it, based not on the capacity of the receiver buffers as conventionally done but on measurements obtained from the RLC. This approach is extremely troublesome as it means a modification of the TCP protocol stack in the UE and it may not be possible to gain control of this stack. This is particularly true in the case where a PC (Personal Computer) is connected to a UE (effectively acting as a modem) and the TCP protocol stack resides on the PC.

Seok, Joo, and Kang's publication, “A-TCP: A mechanism for improving TCP performance in wireless environments,” IEEE broadband wireless summit, May 2001, suggests a scheme whereby two completely split connections are made, one between the server and the network node and another between the network node and the UE. This requires considerable additional complexity and may not produce any benefit for transfers using UDP (User Datagram Protocol). Bakre and Badrinth's publication, “I-TCP: indirect TCP for mobile hosts”, Proceedings of the 15th International conference on distributed computer systems, May 1995, suggests modifying the TCP window size in ACKs (acknowledgment packets). receipt) TCP. However, in this post, the goal is simply to change the TCP window size to the available buffer size on the network node. Limiting the buffer occupancy, as in this publication, does not guarantee a specified RTT.

Therefore, there is a need for a method and an arrangement for a TCP control flow, where the aforementioned disadvantage (s) can be mitigated.

Jiang et al, in "TCP Reno and Vegas Performance in Wireless Ad Hoc Networks" ICC 2001, IEEE International Conference on Communications, Helsinki, Finland, June 11-14, 2001, vol. 1 of 10, June 11, 2001, pages 132-136, uses a simulation method to analyze TCP performance on ad hoc networks. A congestion window for a transmitter is determined from a round trip time (RTT) for TCP packets. The transmitter is provided with information about delays in intermediate node buffers and uses this in its determination of the RTT.

Igarashi et al, in "Mobility Aware TCP Congestion Control" IEEE, vol. 2, October 27, 2002 (10-27-2002), pages 338 to 342, describes the performance of TCP over wireless networks that use post-registration handover. According to the proposed scheme, either TCP flow control or congestion control functions are used according to a number of lost packets.

Summary of the invention

According to a first aspect of the present invention, there is provided an arrangement for TCP flow control according to claim 1.

According to a second aspect of the present invention, there is provided a method for TCP flow control according to claim 15.

Brief description of the drawings

A method and arrangement for TCP flow control incorporating the present invention will now be described, by way of example only, with reference to the attached drawing (s), in which:

FIG. 1 shows a schematic block diagram illustrating a 3GPP radio system in which the present invention can be used;

FIG. 2 shows a schematic block diagram illustrating the protocol architecture for the U-plane, showing the functional location of a TCP windowing function based on the present invention; and FIG. 3 shows a schematic block diagram illustrating steps performed in the TCP flow control method between a server and a user equipment client terminal through a radio network controller.

ES 2 397 629 T3

Description of preferred embodiment (s)

The following preferred embodiment of the present invention will be described in the context of a UMTS Radio Access Network (UTRAN) system operating in the TDD mode. Referring first to FIG. 1, a conventional UMTS Radio Access Network (UTRAN) system 100 is suitably considered to comprise: a user / terminal equipment domain 110; a Terrestrial Radiocommunication Access Network UMTS domain 120; and a domain of Red Central 130.

In the terminal / user equipment domain 110, the terminal equipment (TE) 112 is connected to the mobile equipment (ME) 114 via the wired or wireless R interface. The ME 114 is also connected to a User Service Identity Module (USIM) 116; ME 114 and USIM 116 are considered together as user equipment (UE) 118. The UE 118 communicates data with a Node B (base station) 122 in the radio access network domain 120 via the wireless Uu interface. Within the radio access network domain 120, Node B 122 communicates with a radio network controller (RNC) 124 through the lub interface. The RNC 124 communicates with other RNCs (not shown) through the lur interface. Node B 122 and RNC 124 together form UTRAN 126. The RNC 124 communicates with a serving GPRS serving node (SGSN) 132 in the core network domain 130 through the lu interface. Within the core network domain 130, the SGSN 132 communicates with a GPRS gateway support node (GGSN) 134 through the Gn interface; SGSN 132 and GGSN 134 communicate with a home location register (HLR) server 136 through the Gr interface and the Gc interface respectively. The GGSN 134 communicates with a public data network 138 through the Gi interface.

Thus, the RNC 124, SGSN 132 and GGSN 134 elements are conventionally provided as discrete and independent units (in their own respective software / hardware platforms) divided between the radio access network domain 120 and the core network domain 130, as shown in FIG. 2.

The RNC 124 is the UTRAN element responsible for the control and allocation of resources for numerous Node Bs 122; an RNC can typically control between 50 and 100 Node B. The RNC also provides reliable delivery of user traffic over air interfaces. The RNCs communicate with each other (through the lur interface) to support handovers and macrodiversity.

The SGSN 132 is the UMTS Core Network element responsible for Session Control and interface communication with the HLR. The SGSN keeps track of the location of an individual UE and performs security and access control functions. The SGSN is a great centralized controller for many RNCs.

The GGSN 134 is the UMTS Core Network element responsible for concentrating and tunneling user data within the core packet network to the ultimate destination (eg, the Internet service provider ISP).

Such a UTRAN system and its operation are described in more detail in the 3GPP technical specification documents 3GPP TS 25.401, 3GPP TS 23.060, and related documents, available on the 3GPP website at www.3gpp.org, and not they need to be described in more detail here.

In the present example, all the functionality of the invention resides in the RNC 124 although it can alternatively be applied in the UE 118.

Referring now to FIG. 2, as will be explained in more detail below, in order to improve the TCP flow for data download to a UE 118, a modification 210 of the TCP window occurs at the radio bearer level, and the it is functionally located in the protocol architecture for the user plane (U plane). In the rNc 124, and the Node B 122 of the UTRAN 126 the modification of the TCP window 210 (which will be explained in more detail later) is followed by a PDCP (Packet Data Convergence) processing 220, a RLC (Radio Link Control) 230, a MAC (Medium Access Control) processing 240 and a PHY (Physical Layer) processing 250. It will be understood that the PDCP processing 220, the RLC processing 230, the MAC processing 240 are performed in accordance with the known 3GPP technical specifications TS 25 323, TS 25 322 and TS 25 321 respectively. PHY processing is described in 3GPP TS 25 2xx technical specifications (eg 221, 222, 223, 224 and 225 for TDD). In no case is it necessary to describe them in more detail here.

The processed information is communicated through the wireless Uu interface to the UE 118, where PHY processing 260, MAC processing 270, RLC processing 280, and complementary PDCP processing 290 are performed. As before, it will be understood that PDCP 290 processing, RLC 280 processing, MAC 270 processing, and PHY 260 processing are performed in accordance with known 3GPP technical specifications TS 25 323, TS 25 322 and TS 25 321 respectively. PHY processing is described in the 3GPP TS 25 2xx technical specifications (eg 221, 222, 223, 224 and 225 for TDD). In no case is there a need to describe them in more detail here.

ES 2 397 629 T3

Referring now also to FIG. 3, the modification of the TCP 210 window is based on the following steps:

• At 310, when a TCP packet (302) carrying data is received at RNC 124 from a server 140 for download to UE 118, a target buffer delay is specified and is known, and is performs a delay measurement within the RLC transmission buffer on downlink traffic. A TCP packet (304) carrying data is sent over the wireless Uu interface to the UE 118.

• At 320, in UE 118 an “awnd” value is calculated based on the UE's receiver buffer capacity and it is placed in the “win” field of the ACK (Acknowledgment) packet (306 ) which is sent back to RNC 124;

• In 332 to 336, in RNC 124 a new value of “awnd” is determined as follows:

or at 332, a target RLC buffer delay is subtracted from the RLC buffer delay measured in step 310, or at 334, apply a desired control loop gain multiplier, and or at 336, add the value of "awnd" previously determined in the RNC 124.

• At 340, the next available SDU (Service Data Unit) is identified that contains a TCP ACK packet. The value of the "win" field in the received ACK packet is compared with the value determined in step 330. If the value determined in step 330 is less than the value of "win" in the received ACK packet, then the value of "Win" of the packet is replaced with the one determined in step 330. However, if the value determined in step 330 is greater than that of the received ACK packet, no change is made.

• At 350, the TCP checksum is recalculated to account for the modified TCP ACK.

• At 360, the ACK packet is rebuilt and a TCP packet (308) with the modified ACK is sent to server 140.

No further changes are made to the TCP window until all current system data has been acknowledged (this can be conveniently measured by waiting until the number of ACKs reaches half the current number of SDUs in the system when The delayed ACK function is implemented in the TCP protocol stack.)

It will be appreciated that since the RLC buffer delay parameters must be signaled via PDCP, the PDCP protocol layer could be considered as a suitable location for this functionality to reside.

It will be understood that, ideally, it would be desirable to measure the total round trip time (RTT) for a packet and implement flow control accordingly. However, in practice, RTT measurement based on ACK and SEQ numbering can be difficult since there are typically multiple TCP streams at any one time. The total RTT is made up of the components shown in the following equation:

RTT = sender RLC buffer delay + sender-to-receiver air interface delay + receiver buffer delay + receiver-to-sender air interface delay.

The inventors of the present invention have observed that, considering that the volume of data associated with ACK is low compared to data sent from the sender to the receiver, the delay of the receiver buffer can be affected by the flow that the sender controls. . In addition, the time consumed through the air interface (although it is variable due to retransmissions, etc.) can also be considered as unaffected by flow control. Therefore, there is no need to monitor more than the time that an SDU spends in the RLC transmission queue.

Furthermore, simply measuring the time to pass through the RLC transmission queue can be problematic since, even when no new SDUs are added to the back of the queue, the time to pass through will be high for the last SDU. Therefore, the following method is conveniently used:

1. For each SDU in the RLC transmission queue, measure:

ES 2 397 629 T3

to. The current size of the buffer at the time the SDU enters the RLC transmission queue.

b. The time that elapses from the moment an SDU enters the RLC transmission queue to the moment it leaves the transmission queue (that is, all the PDUs that make up the SDU have been sent at least once ).

2. Determine the average of a predetermined number of latest SDUs for which the buffer size and buffer delay are available.

3. If the average buffer delay is relatively close to the target delay (within a predetermined range around the latter),

Modify the TCP "awnd" window by an amount related to (target buffer delay - mean buffer delay) * control loop gain as in steps 332 to 336 of FIG. 3. Note that a “dead band” can be applied, centered on the desired target delay, where no adjustment is made.

Four. If the average buffer delay is considerably greater than (outside of a predetermined range around) the target delay,

Adjust the TCP window to the amount indicated by the current average buffer size minus a predetermined magnitude.

5. When a modification is made to the TCP window size, no further changes to the TCP window size are allowed until this change has taken effect.

6. A minimum allowed calculated window can be configured so that the TCP window size determined in phases 3 and 4 above cannot fall below this value.

It will be appreciated that the process for TCP flow control described above will typically be carried out in software running on a processor (not shown), and that the software may be provided as a computer program item included on any medium. suitable data set (not shown), such as a magnetic or optical computer disk. It will also be appreciated that the TCP flow control scheme described above can alternatively be fabricated on an integrated circuit for use in a terminal or RNC of a communication system.

It will be appreciated that, although the TCP flow control scheme has been written above in the context of a downlink data transfer in a TDD UTRA system, the invention is not limited to such an application and can be used in a downlink and / or uplink data transfer in communication systems in general.

It will be understood that the method and arrangement for TCP flow control described above provide the advantage that RTT (ie system latency) can be substantially guaranteed, regardless of the throughput assigned to the user. In comparison, it should be noted that the use of a target buffer occupancy - as in the aforementioned prior art publication "I-TCP: indirect TCP for mobile hosts" - does not allow the above condition to be met since occupancy of the buffer varies with the throughput for a given RTT.