US20050144303A1 - System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network - Google Patents

System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network Download PDF

Info

Publication number
US20050144303A1
US20050144303A1 US10/510,696 US51069604A US2005144303A1 US 20050144303 A1 US20050144303 A1 US 20050144303A1 US 51069604 A US51069604 A US 51069604A US 2005144303 A1 US2005144303 A1 US 2005144303A1
Authority
US
United States
Prior art keywords
network element
congestion
size
handover
packets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/510,696
Inventor
Dongmei Zhang
Runtong Zhang
Zhigang Kan
Jian Ma
Chunan Li
Jing Dongfeng
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Assigned to NOKIA CORPORATION reassignment NOKIA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KAN, ZHIGANG, ZHANG, RUNTONG, DONGFENG, JING, LI, CHUNAN, MA, JIAN, ZHANG, DONGMEI
Publication of US20050144303A1 publication Critical patent/US20050144303A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/02Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/188Time-out mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/27Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0226Traffic management, e.g. flow control or congestion control based on location or mobility
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0273Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809Selective-repeat protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L2001/125Arrangements for preventing errors in the return channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24Transfer of terminal data
    • H04W8/245Transfer of terminal data from a network towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Definitions

  • the invention relates to a method and system for improving throughput in a communication network, preferably a Mobile IPv6-based network.
  • IPv6 stands for the Internet Protocol version 6 (as compared to the existing IPv4) and is a standardized protocol.
  • Mobile IPv6 is a standardized protocol which supports mobility in IPv6.
  • the present invention is related to a method and system to improve TCP (Transmission Control Protocol) performance, especially the throughput of TCP connection and utilization of the network resource, when a mobile node in the Mobile IPv6 network hands over between two subnets.
  • TCP Transmission Control Protocol
  • TCP Transmission Control Protocol
  • Mobile IPv6 networks will include wireless links and mobile hosts.
  • a mobile node MN
  • MN mobile node
  • CN Correspondent node
  • CN Correspondent node
  • TCP When TCP is used as the transport protocol, some types of delay and packet loss that are unrelated to congestion will be encountered during mobile node handing over between two subnets.
  • the problem with existing TCP is that the packets lost during handoff are interpreted as network congestion.
  • the typical congestion control mechanisms will misinterpret unexpected increase in delay as packet losses caused by congestion, and may degrade the network performance because the congestion state is followed automatically by the TCP slow start procedure.
  • packets may be lost due to the relatively frequent transmission errors suffered by wireless link.
  • packets may be lost due to the limited buffer in home agent buffering packets when a mobile node is attached to some foreign link away from home.
  • the typical TCP congestion control will interpret them as network congestion. Therefore, the congestion window shrinks to its minimum value (one segment) abruptly and begins to invoke the slow-start algorithm till an acknowledgment (ACK) reaches TCP transmitter.
  • ACK acknowledgment
  • slow-start algorithm begins to grow the congestion window exponentially until it reaches a threshold ssthresh, then grows it linearly.
  • the threshold ssthresh is set to one half of the congestion window size at the time of the retransmission timeout.
  • the slow start algorithm is effective when network congestions are indeed detected.
  • slow start usually is not triggered by network congestions, but by handovers.
  • the slow recovery of the congestion window due to slow start algorithm after each handover causes to the losses of throughput.
  • TCP assume that packet losses are indications of congestion, but sometimes losses are from corruption on a wireless link, and TCP assumes that significantly reordered packets are indications of congestions, but this is not always the case.
  • the typical congestion control mechanisms may degrade the network performance.
  • a MN hands over between two subnets will degrade TCP performance, especially throughput and the utilization of network resource.
  • FEC forward error correction
  • ARQ automatic repeat request
  • I-TCP indirect TCP
  • ELC explicit loss notification
  • SACK selective ACK
  • FACK forward ACK
  • new ECN new ECN
  • Full Rate FR+
  • the invention aims, among others, to improve performance, e.g. to provide TCP enhancements for solving handover-related problems.
  • the present invention provides a method, system and/or device as defined in the independent claims or any one of the dependent claims.
  • the invention preferably relates to IPv6 mobility and TCP optimization methods “fast retransmit” and “fast recovery”.
  • fast retransmit method lost packets are detected in TCP transmitter by means of three or more duplicate ACKs.
  • the invention further preferably relates to IPv6 handoff (or handover) between two subnets.
  • the invention provides a method and system for improving throughput in a communication network, preferably a Mobile IPv6-based network.
  • the invention relates to a case where e.g. CN is taken as the TCP transmitter and MN as the TCP receiver, or vice versa.
  • the binding update when a mobile node after the handoff and e.g. address autoconfiguration in the new subnet sends a binding update message towards the correspondent node, the binding update is interpreted as a signal to a congestion control means, e.g. a TCP layer.
  • the signal indicates to the congestion control means that fast recovery procedures should be initiated, instead of slow start.
  • the signal can be implemented as duplicating ACK packets by the IP layer to the TCP layer.
  • a congestion window size may be step-wise increased after handover, or a threshold value defining a change from exponential to linear increase of the congestion window size, may be set to a value which is more than one half of the window size value before handover.
  • One of the objective of the present invention is to provide a method for triggering the fast retransmit and fast recovery mechanism as fast as possible, by means of which the throughput of TCP connection and the utilization of the network resoure can be improved.
  • An advantage of the invention is to invoke fast retransmit and fast recovery mechanism other than slow start mechanism after handover completing, or to increase a congestion window size step-wisely after handover, or to increase a threshold value defining a change from exponential to linear increase of the congestion window size, so as to improve TCP performance, especially throughput.
  • Fast retransmit and fast recovery algorithms are known TCP congestion control methods. The idea is that if three or more duplicate ACKs are received by a TCP transmitter, the missing segment will be retransmitted immediately, without waiting for the retransmission timer to expire. Then instead of performing slow-start algorithm, congestion avoidance algorithm is invoked. Invoking fast retransmit and fast recovery algorithms other than slow start will improve throughput of TCP connection.
  • Another advantage of the invention is that there is one trigger mechanism to invoke fast retransmit and fast recovery algorithms.
  • fast retransmit and fast recovery algorithms could not be triggered automatically immediately after completion of handovers because ACKs could not be sent until the handover completed.
  • the invention thus provides a trigger to fast retransmit and fast recovery algorithms.
  • a further advantage of the invention is the ability to trigger fast retransmit and fast recovery algorithms as soon as possible.
  • Mobile IPv6 After the mobile node acquires its care-of address in foreign link, it will register this care-of address with home agent and correspondent node by sending the “Binding Update” destination option.
  • the “Binding Update” destination option is the earlist signal for the correspondent node to be informed that the handover is successful and will be completed soon. Hence, it is the earliest time for correspondent node to trigger fast retransmit and fast recovery algorithms.
  • Some of the provided advantages are: Improvement of the TCP performance, e.g of TCP throughput; Improvement of the utilization of network resource; Only minor modifications to the TCP and Mobile IPv6 software in TCP transmitter are be made.
  • FIG. 1 illustrates an embodiment of the invention and illustrates the basic operation in Mobile Ipv6 handover and the process between Mobile Node (MN) and Correspondent Node (CN), for initializing a “Binding Update” destination option;
  • MN Mobile Node
  • CN Correspondent Node
  • FIG. 2 shows a time scale for comparing flow charts of a first embodiment of a method and device in accordance with the invention, and of a method not using the first embodiment of the invention;
  • FIG. 3 shows a comparison of the behavior of a congestion window in response to handover with and without the first embodiment of the method and device in accordance with the invention
  • FIG. 4 illustrates another embodiment of the invention, showing the basic operation in Mobile Ipv6 handover with more details and the process between Mobile Node (MN) and Correspondent Node (CN), for initializing a “Binding Update” destination option;
  • MN Mobile Node
  • CN Correspondent Node
  • FIG. 5 shows a time scale for comparing flow charts of a second embodiment of a method and device in accordance with the invention, and of a method not using the second embodiment of the invention
  • FIG. 6 shows a comparison of the behavior of a congestion window in response to handover with and without the second embodiment of the method and device in accordance with the invention
  • FIG. 7 shows a time scale for comparing flow charts of a third embodiment of a method and device in accordance with the invention, and of a method not using the third embodiment of the invention.
  • FIG. 8 shows a comparison of the behavior of a congestion window in response to handover with and without the third embodiment of the method and device in accordance with the invention.
  • TCP sender can be any mobile equipments, such as mobile phones, Personal Digital Assistants (PDAs), laptops, which have e.g. mobile IPv6 stack.
  • PDAs Personal Digital Assistants
  • laptops which have e.g. mobile IPv6 stack.
  • a message e.g. Binding Update
  • TCP congestion control e.g. TCP congestion control
  • the subsequent congestion control changing processes after occurrence of the trigger can be different in the embodiments in accordance with the present invention.
  • a conventional Fast Retransmit and Fast Recovery procedure is invoked after the trigger.
  • a new trigger is provided for invoking this procedure at an earlier time.
  • a Slow-Start Threshold is increased after occurrence of the trigger.
  • the new SSTHRESH can be any value between old SSTHRESH and old Congestion Window size (CWND).
  • the actual value of the new SSTHRESH may depend on the network performance. In a network with good performance, a higher SSTHRESH can be set, and in a network with poor performance, a lower SSTHRESH may be set.
  • the Congestion Window size can be increased after occurrence of the trigger.
  • the value of new CWND can be any value from more than the minimum value (one segment) to old CWND.
  • the new CWND may also depend on the network performance. Different values will result in different CWND behavior.
  • the above measures can also be combined, that is the Slow-Start Threshold (SSTHRESH) and the Congestion Window size (CWND) can both be increased after occurrence of the trigger.
  • SSTHRESH Slow-Start Threshold
  • CWND Congestion Window size
  • a Mobile Node (MN) 1 is represented two times, once attached to its home link (upper position of FIG. 1 ), and once after moving to another location (lower position of FIG. 1 ) where the MN 1 is away from home and attached not to its home link but served by another serving entity, i.e. by a foreign link.
  • a Home Agent (HA) 2 is associated to the MN for traffic control.
  • HA Home Agent
  • a remote node such as the MN 1 after moving, may inform any other node such as the HA 2 or CN (Correspondent Node) 7 that all traffic sent to the remote node's home address should be currently sent to another address, the so called care-of-address.
  • BU Mobile IPv6 Binding Update
  • the Mobile Node (MN) 1 detects his movement e.g. by receiving a Routing advertisement from a router, and generates his Care-of-Address (COA) with a stateless or a stateful address allocating procedure. MN 1 sends this information to his Home Agent (HA) 2 by a Binding Update (BU) message 5 . HA 2 modifies the information on the address entry in its Binding Cache and e.g. returns a Binding Acknowledgement (BAck) message to MN 1 . A same Binding Update message 3 is also sent from MN 1 to CN 7 . This BU message 3 allows route optimization: The CN 7 sends the data directly to the MN 1 and vice versa.
  • COA Care-of-Address
  • Packets from a Correspondent Node (CN) 7 or any other node to the shadow of the Home Address of MN 1 are blocked by the HA 2 and are tunneled to the MN 1 for the destination in the Binding Cache.
  • the connection and traffic between MN 1 , HA 2 , and CN 7 is effected via the internet 6 .
  • Link 4 represents any connection between MN 1 and any other node handled via internet 6 .
  • FIG. 2 shows flow charts with a time scale for comparing the previous method and a first embodiment of the method/system according to the invention.
  • the time axis is shown at the right-hand side of FIG. 2 .
  • the left column S A represents the IP layer in the MN 1 .
  • the middle column S B shows the normal previous behaviour of CN 7 when not employing the embodiment according to the invention.
  • the right-hand column S C shows the behaviour of CN 7 when employing a first embodiment (embodiment 1) of the method and system according to the invention.
  • the indicated time points t 1 to t 5 represent the following: t 1 : Handover begin; t 2 : Binding Update trigger; t 3 : Arrival of first ACK; t 4 : Congestion window size back to the value before handover in the embodiments of the present invention; t 5 : Congestion window size back to the value before handover in prior art.
  • step S 1 of FIG. 2 it is assumed that the MN 1 moves into a foreign subnet, that is a handover is performed.
  • step S 2 the MN 1 acquires a new care-of address (CoA), and sends, in step S 3 , a message, preferably a binding update message, to HA 2 and/or CN 7 .
  • CoA new care-of address
  • step S 4 of the middle column S B showing the normal previous behaviour of CN 7 and of the right column S C showing the behaviour of CN 7 according to the first embodiment, the congestion window shrinks to the minimum value as a result of the handover.
  • step S 5 of the middle column S B showing the normal previous behaviour of CN 7 CN 7 receives the Binding Update message either directly from MN 1 , or from HA 2 , but does nothing to TCP.
  • step S 6 it is assumed that the CN 7 sends data and waits for receipt of an Acknowledgment message ACK confirming that MN 1 has received the sent data.
  • step S 8 TCP Timeout is checked as usual. Due to the handover, some packets will get lost so that the ACKs are not properly returned. As long as TCP has not timed out, the waiting loop is executed via steps S 8 , S 7 , for the set waiting period. After TCP timeout, the answer of checking step S 8 is “Yes” and the program proceeds to step S 9 , in which the data are resent. Thereafter, the routine jumps back to step S 7 . This loop may be repeated for a defined number.
  • step S 10 the congestion window is controlled to increase, returning gradually to the previous value before handover.
  • the customary slow start mechanism is effected.
  • step S 11 the congestion window has finally returned to the previous value before handover.
  • step S 12 the CN 7 receives the Binding Update message, and then informs its TCP software/structure thereon (step S 13 ).
  • the TCP software responds by executing step S 14 , i.e. it triggers its fast retransmit & fast recovery mechanism which may be the customary fast retransmit & fast recovery mechanism.
  • the CN 7 does not wait for TCP timeout but immediately starts the fast retransmit/recovery mechanism for bringing back the congestion window to its value before the handover as quickly as possible.
  • the value ssthresh may be increased or set to the previous value of the old congestion window in step S 12 .
  • step S 15 the congestion window has thus returned to the value before handover very fast.
  • FIG. 3 shows a comparison of the behavior of the congestion window in response to handover with and without employing the above discussed first embodiment of the system and method according to the invention.
  • the X axis of FIG. 3 represents time, and the Y axis represents the congestion window size and thus TCP throughput.
  • the solid line illustrates the behavior of the congestion window in response to handover when employing the first embodiment of the invention, i.e. when triggering the fast retransmit & fast recovery directly after handover detection, that is receipt of the message confirming handover completion such as the BU (Binding Update) message.
  • BU Biting Update
  • the dotted line of FIG. 3 shows the conventional behavior of the congestion window in response to handover when not using the invention, i.e when employing the slow start process.
  • the first embodiment of the invention provides a very fast growth of the congestion window size and thus system performance and throughput, in a step-wise and subsequent ramp-like fashion, after any handover occurrence.
  • the agent when the binding updates to the correspondent node should be handled by an agent acting on behalf of the correspondent node, the agent is preferably programmed to send either the binding update messages, or a command for starting the fast retransmit & fast recovery, to the correspondent node, i.e. to the TCP transmitter.
  • the CN is adapted to check, when it receives a Binding Update message, whether it has sent any not yet acknowledged data, i.e. it is waiting for acknowledgment messages, or whether it has any data to be sent actually.
  • the correspondent node may be programmed simply not to do anything special if it gets a Binding Update message.
  • the check should however reveal that the CN has sent any not yet acknowledged data, i.e. it is waiting for acknowledgment messages, or intends to send any data, the above mentioned fast retransmit & fast recovery method of the correspondent node is triggered.
  • the functioning of the method and system according to the invention can be tested by pretending to lose one or more packets, and checking the actions taken by the correspondent node when it gets a Binding Update message.
  • Buffer management might cause duplication of packets which can be dealt with in the MN, but wastes radio resources.
  • An option is to agree between the MN and the CN upon the use of the disclosed method. This approach can bypass problems with BM and hierarchic mobility management.
  • the present invention thus provides a method and system for improving TCP performance, especially throughput and utilization of network resource.
  • the slow start algorithm adds another window to the sender's TCP: the congestion window “cwnd”, so as to allow the rate of injecting new packets into the network to be the rate of returning acknowledgments by the other end.
  • the congestion window When a new connection is established with a host on another network, the congestion window is initialized to one segment. Each time an ACK is received, the congestion window is increased by one segment. The sender can transmit packets up to the minimum of the congestion window and the advertised window. The congestion window provides flow control imposed by the sender, while the advertised window is a flow control imposed by the receiver. The sender flow control is based on the sender's assessment of perceived network congestion.
  • the sender starts by transmitting one segment and waiting for its ACK. When that ACK is received, the congestion window is incremented to two so that two segments can be sent. When each of those two segments is acknowledged, the congestion window is increased to four, providing approximately exponential growth. When the capacity of the network is reached, packets may be lost. This informs the sender that its congestion window has grown too large.
  • Congestion avoidance deals with lost packets. Congestion can e.g. occur when high data rate input streams arrive at a router with insufficient output capacity. A loss of a packet signals congestion somewhere in the network between the source and destination. There are two possible indications of packet loss: occurrence of timeout, or receipt of duplicate ACKs. When congestion occurs TCP slows down its transmission rate of packets into the network, and invokes the slow start algorithm.
  • Congestion avoidance and slow start require that two variables be maintained for each connection: a congestion window, cwnd, and a slow start threshold size. Slow start continues until TCP is halfway to where it was when congestion occurred, and then congestion avoidance takes over. Congestion avoidance dictates that cwnd be incremented each time an ACK is received, with linear growth of cwnd.
  • the Fast Retransmit algorithm is a modification to the congestion avoidance algorithm.
  • TCP may generate an immediate acknowledgment (a duplicate ACK) when an out-of-order segment is received. This duplicate ACK should not be delayed. This duplicate ACK informs the other node that a segment was received out of order.
  • TCP Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. If there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, this will normally be caused by having lost a segment during transmission. TCP then performs a retransmission of the missing unacknowledged segment, without waiting for a retransmission timer to expire.
  • congestion avoidance (not slow start) is performed. This is the fast recovery algorithm. It is an improvement that allows high throughput under moderate congestion, especially for large windows.
  • the fast retransmit and fast recovery algorithms are usually implemented together as follows.
  • Preferred embodiments of the invention relate to TCP performance enhancement during handovers in MIP such as Mobile IPv6 network.
  • the embodiments propose a mechanism to undo an unnecessary congestion control triggered by reordered, delayed or lost packets due to handover.
  • the basic idea of some embodiments of the invention is to use a signal indicating handover completion, e.g. a binding update message, and then, recover the threshold ssthresh to a higher value than conventionally, e.g. to more than one-half of, up to the value of the previous congestion window, instead of only one half of this value.
  • a signal indicating handover completion e.g. a binding update message
  • recover the threshold ssthresh to a higher value than conventionally, e.g. to more than one-half of, up to the value of the previous congestion window, instead of only one half of this value.
  • the above embodiments may be considered as a conservative scheme, which changes the threshold in slow-start algorithm (ssthresh). It increases ssthresh to the value of the previous congestion window. Because the congestion window grows exponentially before ssthresh and grows linearly after ssthresh, higher ssthresh lets the congestion window grows faster.
  • This alternative 2. is a moderate scheme which changes the initial size of congestion window. It directly increases the congestion window to a high proper value. This value can be a predetermined value based on network performance or a dynamic value based on real-time network measurement. Better result on TCP throughput can be obtained.
  • the invention may be used in e.g. proxies and servers without standardization, in TCP terminals, such as mobile phone, PDA, laptop, or the like.
  • a fast retransmit and fast recovery mechanism is initiated instead of keeping slow-start initiate after handover completion message, e.g. Binding Update.
  • IPv6 Internet Protocol version 6
  • Mobile IPv6 is a research field, in which an Internet draft on mobile IPv6 is likely to become a RFC in the near future.
  • the MN is at some geographical and topological distance away from the HA and CN, the amount of time involved in sending the binding updates may be greater than hundred milliseconds. This latency in routing update may cause poor TCP performance.
  • the described embodiments provide TCP enhancement during handovers in mobile IPv6.
  • a mechanism is provided which recovers the slow-start threshold ssthresh to more than half of, up to the previous value of the old congestion window after a handover completion if the timeout is caused by the handover. This improves TCP throughput.
  • a halving of the congestion window can be a significant performance reduction as it takes at least W/2 round-trip times for the flow to recover its old congestion window.
  • MN acting as a receiver
  • MN as a sender
  • the CN acting as a receiver: If the CN determines that the packet loss, reordered packets and delayed packets are produced due to handover process and not to congestion, then the CN may implement the option of undoing the halving in the congestion window, by means of which the throughput of TCP connection and the utilization of network resource can thus be improved. When the CN receives the Binding Update from MN, this mechanism is triggered.
  • the MN acting as a sender: If the MN determines that packet loss, reordered packets and delayed packets are produced due to handover process but not to congestion, then the MN preferably has the option, means and functions of undoing the halving in the congestion window, that is of increasing the slow-start threshold ssthresh to a value of more than half of, up to the previous value of the old congestion window. Thereby, the throughput of TCP connection and the utilization of network resource can thus be improved.
  • this mechanism is triggered in the MN.
  • the (previous) slow-start threshold ssthresh value of the old congestion window may be stored in the MN and/or in the CN, e.g. if slow-start happens,
  • These embodiments of the invention present a mechanism to undo unnecessary congestion control responses to reordered or delayed or lost packets due to handover.
  • Mobile IPv6 After a MN acquires its care-of-address in a foreign link, it will register this care-of-address with its home agent and the CN by sending the “Binding Update” destination option.
  • the “Binding Update” destination option is the earliest signal for the CN to be informed that the handover is successful and will complete soon. Hence, it is the earliest time for CN and MN to be able to undo congestion control.
  • the proposed mechanism is preferably not in effect.
  • TCP terminals could be any mobile equipment, such as mobile phones, PDAs and laptops, which have mobile IPv6 stack.
  • the TCP performance can be improved when this method is used.
  • FIG. 4 shows another embodiment of the invention employing the above described means and functions of Mobile IP, preferably Mobile IPv6, basic operation.
  • Reference numerals identical to the reference numerals used in FIG. 1 designate identical or at least similar means and structures, as described above.
  • the network environment and handover process are as same as the embodiment shown in FIG. 1 .
  • FIG. 4 provides more details and shows some network elements which are not shown in FIG. 1 .
  • the MN 1 has a home network 10 providing home link, home address, and home subnet prefix, and comprising an home agent 2 .
  • MN 1 When the MN 1 has moved to another network, data/messages/information are exchanged between MN 1 and home agent 2 or CN 7 via internet 6 and foreign/visited or access networks 11 , 13 having access routers 12 , 14 , as shown in FIG. 4 .
  • Network 11 provides foreign link, care-of address, and foreign subnet prefix.
  • a Binding Update message is generated in and sent from the MN 1 via internet 6 to the home network 10 .
  • FIGS. 5 and 6 illustrate a second embodiment of the method/system according to the invention, and show flow charts with a time scale for comparing the prior method and the second embodiment.
  • the time axis is shown at the right-hand side of FIG. 5 .
  • the time points t 1 to t 5 represent the following: t 1 : Handover begin; t 2 : Binding Update trigger; t 3 : Arrival of first ACK; t 4 : Congestion window size back to the value before handover in the embodiments of the present invention; t 5 : Congestion window size back to the value before handover in prior art.
  • the left column S A of FIG. 5 represents the IP layer in the MN 1 .
  • the middle column S B shows the normal previous behaviour of CN 7 when not employing the embodiment according to the invention.
  • the left column S A and middle column S B of FIG. 5 are identical to the left and middle columns of FIG. 2 so that it is referred to the above description of the steps and functions of these columns, as well as of step S 4 of the right-hand column S C .
  • step S 12 the CN 7 receives the Binding Update message, and then informs its TCP software/structure thereon (step S 13 ).
  • the TCP software responds by executing step S 16 , i.e. it immediately increases the threshold value ssthresh to a value “New ssthresh” higher than the previous customary value “old ssthresh”, as shown in FIG. 6 .
  • the threshold value ssthresh is thus set to be higher than the value set according to the prior method (in which the ssthresh value was set to one half of the previous value before handover begin, see FIG. 6 “OLD ssthresh”), for example to a range of 1.1 to 2.0 of the value “old ssthresh”, more preferably 1.5 to 2.0 of the previous value.
  • the system then waits for acknowlegdments ACK as usual, similar to steps S 5 to S 10 of the middle column S B of FIG. 5 .
  • the congestion window size is exponentially increased up to the value “new ssthresh”. Thereafter, the congestion window size linearity increases up to the maximum value (value before handover), as shown in FIG. 6 . The congestion window size is hence returned to the value before handover much quicker than in the previous method.
  • FIG. 6 shows a comparison of the behavior of the congestion window in response to handover with and without employing the above discussed second embodiment of the system and method according to the invention.
  • the X axis of FIG. 6 represents time, and the Y axis represents the congestion window size and thus TCP throughput.
  • the solid line illustrates the behavior of the congestion window in response to handover when employing the second embodiment of the invention, i.e. when increasing the congestion window size directly after handover detection, that is after receipt of the message confirming handover completion such as the BU (Binding Update) message.
  • the dotted line of FIG. 6 shows the conventional behavior of the congestion window in response to handover when not using the invention, i.e when employing the old threshold value.
  • the width cwnd of the congestion window is reduced to the lowest value.
  • the width of the congestion window is exponentially increased to the ssthresh value.
  • the second embodiment of the invention provides a very fast growth of the congestion window size and thus system performance and throughput, after any handover occurrence.
  • the width of the congestion window is stepwise increased at the end of the handover, e.g. when sending or receiving a binding update message or packet.
  • the objective of this embodiment is to improve the throughput of TCP connection and the utilization of the network resource during the MN hands over.
  • the objective is achieved by immediately increasing the congestion window to a high proper value while the handover finished, not as usual which relies on the TCP slow-start mechanism to recover from the minimal initial window (usually the initial window is only 1 segment).
  • the method comprises the following steps:
  • the same function may also take place in the CN when it is informed on successful handover, e.g. by receiving a BU message.
  • FIGS. 7 and 8 illustrate this third embodiment of the method/system according to the invention, and show flow charts with a time scale for comparing the previous method and the second embodiment.
  • the time axis is shown at the right-hand side of FIG. 7 .
  • the time points t 1 to t 5 represent the following: t 1 : Handover begin; t 2 : Binding Update trigger; t 3 : Arrival of first ACK; t 4 : Congestion window size back to the value before handover in the embodiments of the present invention; t 5 : Congestion window size back to the value before handover in prior art.
  • the left column S A of FIG. 7 represents the IP layer in the MN 1 .
  • the middle column S B shows the normal previous behaviour of CN 7 when not employing this embodiment according to the invention.
  • the left column S A and middle column S B of FIG. 7 are identical to the left and middle columns of FIGS. 2 and 5 so that it is referred to the above description of the steps and functions of these columns, as well as of step S 4 of the right-hand column S C .
  • step S 12 the CN 7 receives the Binding Update message, and then informs its TCP software/structure thereon (step S 13 ).
  • the TCP software responds by executing step S 18 , i.e. it immediately increases the width or size of the congestion window in a stepwise manner to a proper value.
  • This value can be predetermined based on the network performance and/or can be dynamic updated based on network measurement. It may be equal to one half of the window size value before handover, or may be lower or higher than one-half of this value.
  • a value of at least one-half of the window size value before handover is preferred.
  • the system then waits for acknowlegdments ACK as usual, similar to steps S 5 to S 10 of the middle column S B of FIG. 5 .
  • the congestion window size is linearly increased up to the window size value before handover (time t 4 ).
  • the window size is very rapidly brought back to the maximum admissible size under the present conditions, as shown in FIG. 8 .
  • FIG. 8 shows a comparison of the behavior of the congestion window in response to handover with and without employing the above discussed third embodiment of the system and method according to the invention.
  • the X axis of FIG. 8 represents time, and the Y axis represents the congestion window size and thus TCP throughput.
  • the solid line illustrates the behavior of the congestion window in response to handover when employing the third embodiment of the invention, i.e. when increasing the congestion window size directly after handover detection, that is after receipt of the message confirming handover completion such as the BU (Binding Update) message.
  • the dotted line of FIG. 8 shows the conventional behavior of the congestion window in response to handover when not using the invention, i.e when employing the old threshold value and old window size.
  • the width cwnd of the congestion window is reduced to the lowest value.
  • the width of the congestion window is stepwise increased to the.
  • the third embodiment of the invention provides a very fast growth of the congestion window size and thus system performance and throughput, after any handover occurrence.
  • An advantage of the invention is to increase the transmitting rate immediately after the handover finish by increasing the initial window of slow-start mechanism, so as to improve the throughput just after the handover finish, and utilization of network resource.
  • Another advantage of the invention is to use a “handover successful” message or “handover completed” message such as the “Binding Update” message as the trigger to begin the transmission as soon as possible, instead of waiting for the recovery of TCP mechanism itself.
  • the duration time of handover of MN between two subnets is quite long, compared e.g. with the Round-trip time (RTT).
  • RTT Round-trip time
  • the handover time is still a multiple of RTT.
  • the long handover time usually will result in the timeout in the TCP sender, and the congestion window (CWND) in the TCP sender will decrease to 1 MSS and invoke the slow-start mechanism in prior art devices.
  • the timeout is the signal of network congestion.
  • the transmission rate i.e. the congestion window will be decreased dramatically, saying 1 segment.
  • misinterpreting the timeout due to handover as congestion will induce the throughput degrade and also underutilize the network resources.
  • MN begins a handover.
  • the handover will need some time until MN sends a “binding update” message at time t 2 .
  • the TCP sender does not know anything about the handover.
  • the timeout may happen several times, and he TCP sender retransmits one packet after each timeout.
  • the TCP sender could successfully retransmit the packets, with the congestion window size 1.
  • the congestion window increases one by one with every new ACK arriving. This prior art slow-start process is illustrated by the dotted lines in FIG. 8 (denoted “previous method”).
  • the congestion window size may be stepwise increased at the time of sending or receiving the indication of handover end, that is at time t 2 .
  • the congestion window size may be stepwise, i.e. immediately increased to a proper determined value.
  • the determined value may e.g. lie in the range of from 20% to 100% of the size of the congestion window immediately before handover begin at time t 1 .
  • a preferred determined value can for instance be one half (50%) of the previous congestion window size before handover begin at time t 1 .
  • the determined value can for instance also be higher than one half, e.g. 100% of the previous congestion window size before handover begin at time t 1 , t 4 .
  • TCP throughput is improved, the utilization of network resource is increased, and only minor modifications to the TCP and Mobile IPv6 software in TCP transmitter are needed, which are easy to implement in network elements such as mobile phones, terminals, nodes etc.
  • the congestion window will increase earlier and faster than in the normal situation.
  • the throughput is improved during handover.
  • the congestion window size may be stepwise increased to a predetermined value (lower than one-half of the window size value before handover) after the handover complete message, e.g. BU message, and thereafter be exponentially increased to another threshold value ssthresh higher than one-half of the window size value before handover, with a final linear increase up to the maximum admissible value.
  • the congestion control means of the first and second network elements may be implemented using TCP (Transport Control Protocol) software, preferably a Mobile IPv6 software.

Abstract

The invention relates to a method and system for managing a communication between a first mobile network element and a second network element, wherein the communication is performed via a network on a packet-switched basis with acknowledgment messages acknowledging receipt of packets being returned to the packet sending network element. A congestion control is provided for controlling the number of packets being allowed to be sent before receipt of acknowledgment messages for these packets. The congestion control is adapted to change, when the first network element performs a hand-over and sends a message informing on the I hand-over, so as to provide faster recovery rate after handover as compared to the normal recovery rate after packet loss. At least one of the first and second network element is adapted, when receiving the message, to trigger the invocation of a fast retransmit and fast recovery algorithm. As an alternative, in order to provide the faster recovery rate after handover, a congestion window size may be step-wise increased after handover, or a threshold value defining a change from exponential to linear increase of the congestion window size, may be set to a value which is more than one half of the window size value before handover.

Description

    FIELD AND BACKGROUND OF THE INVENTION
  • The invention relates to a method and system for improving throughput in a communication network, preferably a Mobile IPv6-based network. IPv6 stands for the Internet Protocol version 6 (as compared to the existing IPv4) and is a standardized protocol. Mobile IPv6 is a standardized protocol which supports mobility in IPv6.
  • In particular, the present invention is related to a method and system to improve TCP (Transmission Control Protocol) performance, especially the throughput of TCP connection and utilization of the network resource, when a mobile node in the Mobile IPv6 network hands over between two subnets.
  • TCP (Transmission Control Protocol) is a reliable transport protocol that has been tuned for networks composed of wired links and stationary hosts. It interprets an unexpected increase in delay as packet losses caused by congestion. The congestion control policies have been proved beneficial in improving the overall performance of the networks like the current Internet.
  • Mobile IPv6 networks, however, will include wireless links and mobile hosts. In Mobile IPv6, a mobile node (MN) is always addressable by its home address, whether it is currently attached to its home link or is away from home. While a mobile node is attached to some foreign link away from home, it is also addressable by one or more care-of addresses, in addition to its home address. Correspondent node (CN) is any node communicating with the mobile node. After the mobile node acquires its care-of address in a foreign link, it will register the association between the mobile node's home address and this care-of address with home agent and correspondent node by sending a packet containing a “Binding Update” destination option, as shown in FIG. 1.
  • When TCP is used as the transport protocol, some types of delay and packet loss that are unrelated to congestion will be encountered during mobile node handing over between two subnets.
  • The problem with existing TCP is that the packets lost during handoff are interpreted as network congestion. In more detail, the typical congestion control mechanisms will misinterpret unexpected increase in delay as packet losses caused by congestion, and may degrade the network performance because the congestion state is followed automatically by the TCP slow start procedure.
  • In Mobile IPv6, there are several types of delay and loss that are unrelated to congestion. First, communications may slow down while the handovers between two subnets occur, packets cannot again be routed to and from the mobile node until the handover completes. During the handover process, there is a time period when the MN is unable to send or receive IPv6 packets both due to link switching delay and IP protocol operations. This time period is referred to as handover latency. In many instances, the handover latency resulting from standard Mobile IPv6 handover procedures could be greater than what is acceptable to support real-time or delay sensitive traffic.
  • Second, packets may be lost due to the relatively frequent transmission errors suffered by wireless link. Third, packets may be lost due to the limited buffer in home agent buffering packets when a mobile node is attached to some foreign link away from home.
  • When these unexpected delays are due to handover happen, the typical TCP congestion control will interpret them as network congestion. Therefore, the congestion window shrinks to its minimum value (one segment) abruptly and begins to invoke the slow-start algorithm till an acknowledgment (ACK) reaches TCP transmitter. As ACK reach the TCP transmitter, slow-start algorithm begins to grow the congestion window exponentially until it reaches a threshold ssthresh, then grows it linearly. The threshold ssthresh is set to one half of the congestion window size at the time of the retransmission timeout. After handover completes for long time, the congestion window returns gradually to its previous level before the window shrinks, as shown in FIG. 3 by broken lines. Thus it takes a long time after handover completion until the congestion window returns gradually to its previous level.
  • Actually, the slow start algorithm is effective when network congestions are indeed detected. However in the handover scenario, slow start usually is not triggered by network congestions, but by handovers. Hence, the slow recovery of the congestion window due to slow start algorithm after each handover causes to the losses of throughput.
  • In Mobile IPv6, a handover of a mobile node between two subnets will degrade TCP performance, especially throughput and utilization of network resource.
  • Although a number of methods such as Fast Handover, G. Dommety (Editor), A. Yegin, C. Perkins, G. Tsirtsis, K. El-Malki, M. Khalil: “Fast Handovers for Mobile IPv6”, Internet Draft, Internet Engineering Task Force (IETF), September 2002, and LMM, Carl Williams, Editor: “Localized Mobility Management Requirements”, Internet Draft, Internet Engineering Task Force, December 2002, have been proposed to improve the handover performance in Mobile IPv6, it is a MUST that the packet loss, reordered packets and delayed packets are produced due to handover process not to congestion. According to the TCP principle, TCP assume that packet losses are indications of congestion, but sometimes losses are from corruption on a wireless link, and TCP assumes that significantly reordered packets are indications of congestions, but this is not always the case. Hence, the typical congestion control mechanisms may degrade the network performance. To sum up, in Mobile IPv6, a MN hands over between two subnets will degrade TCP performance, especially throughput and the utilization of network resource.
  • Because of the key roles of TCP in the Internet, through these years, various attempts have been made to enhance TCP functions. Recently, along with the rapidly development of satellite or mobile technologies, improving TCP's performance on wireless links has been becoming a challenge and an active research topic.
  • In wired link scenarios, there are many TCP enhancement methods, which are well applied. Among all the amendments to TCP, slow start, congestion avoidance, fast retransmission and fast recovery have been proven very efficient and mature, and well applied. Another example is the Explicit Congestion Notification (ECN). Fast-TCP has recently proposed, and its control philosophy is different from all previous methods.
  • However, some problems still exist when these methods are used in wireless environment.
  • Regarding the TCP enhancements on the wireless platform, considerable efforts are devoted to determining the cause of packet drops and accordingly taking control actions. Generally, forward error correction (FEC), automatic repeat request (ARQ), indirect TCP (I-TCP), snoop, explicit loss notification (ELC), selective ACK (SACK), forward ACK (FACK), new ECN, and Full Rate (FR+) are some possible solutions in this category.
  • SUMMARY OF THE INVENTION
  • The invention aims, among others, to improve performance, e.g. to provide TCP enhancements for solving handover-related problems.
  • The present invention provides a method, system and/or device as defined in the independent claims or any one of the dependent claims.
  • The invention preferably relates to IPv6 mobility and TCP optimization methods “fast retransmit” and “fast recovery”. In fast retransmit method lost packets are detected in TCP transmitter by means of three or more duplicate ACKs.
  • The invention further preferably relates to IPv6 handoff (or handover) between two subnets.
  • The invention provides a method and system for improving throughput in a communication network, preferably a Mobile IPv6-based network.
  • In accordance with one of the aspects of the invention, the invention relates to a case where e.g. CN is taken as the TCP transmitter and MN as the TCP receiver, or vice versa.
  • According to one of the aspects of the invention, when a mobile node after the handoff and e.g. address autoconfiguration in the new subnet sends a binding update message towards the correspondent node, the binding update is interpreted as a signal to a congestion control means, e.g. a TCP layer. The signal indicates to the congestion control means that fast recovery procedures should be initiated, instead of slow start. The signal can be implemented as duplicating ACK packets by the IP layer to the TCP layer. As an alternative, in order to provide the faster recovery rate after handover, a congestion window size may be step-wise increased after handover, or a threshold value defining a change from exponential to linear increase of the congestion window size, may be set to a value which is more than one half of the window size value before handover.
  • One of the objective of the present invention is to provide a method for triggering the fast retransmit and fast recovery mechanism as fast as possible, by means of which the throughput of TCP connection and the utilization of the network resoure can be improved.
  • The objective is achieved by a method, which, according to one of the embodiments, comprises the following steps:
    • 1) When a mobile node moves from one subnet into another foreign subnet, it acquires its care-of address in foreign link, e.g. according to the methods of IPv6 Neighbor Discovery;
    • 2) the mobile node registers the association between the mobile node's home address and this care-of address with home agent and correspondent node by sending a packet containing a “Binding Update” destination option;
    • 3) when the correspondent node receives the packet containing the “Binding Update”, the Mobile IPv6 software in the correspondent node signals the TCP software;
    • 4) the TCP software on correspondent node invokes the fast retransmit and fast recovery mechanism or threshold value setting when it receives the signal from the Mobile IPv6 software.
  • An advantage of the invention is to invoke fast retransmit and fast recovery mechanism other than slow start mechanism after handover completing, or to increase a congestion window size step-wisely after handover, or to increase a threshold value defining a change from exponential to linear increase of the congestion window size, so as to improve TCP performance, especially throughput. Fast retransmit and fast recovery algorithms are known TCP congestion control methods. The idea is that if three or more duplicate ACKs are received by a TCP transmitter, the missing segment will be retransmitted immediately, without waiting for the retransmission timer to expire. Then instead of performing slow-start algorithm, congestion avoidance algorithm is invoked. Invoking fast retransmit and fast recovery algorithms other than slow start will improve throughput of TCP connection.
  • Another advantage of the invention is that there is one trigger mechanism to invoke fast retransmit and fast recovery algorithms. In Mobile IPv6, fast retransmit and fast recovery algorithms could not be triggered automatically immediately after completion of handovers because ACKs could not be sent until the handover completed. The invention thus provides a trigger to fast retransmit and fast recovery algorithms.
  • A further advantage of the invention is the ability to trigger fast retransmit and fast recovery algorithms as soon as possible. In Mobile IPv6, after the mobile node acquires its care-of address in foreign link, it will register this care-of address with home agent and correspondent node by sending the “Binding Update” destination option. The “Binding Update” destination option is the earlist signal for the correspondent node to be informed that the handover is successful and will be completed soon. Hence, it is the earliest time for correspondent node to trigger fast retransmit and fast recovery algorithms.
  • There are key features, either to be provided isolated or in any arbitrary combination, of the present invention which improve earlier solutions: Invocation of fast retransmit and fast recovery mechanism other than slow start mechanism after handover completion; one trigger mechanism to invoke fast retransmit and fast recovery algorithms; triggering fast retransmit and fast recovery algorithms as fast as possible.
  • Some of the provided advantages are: Improvement of the TCP performance, e.g of TCP throughput; Improvement of the utilization of network resource; Only minor modifications to the TCP and Mobile IPv6 software in TCP transmitter are be made.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates an embodiment of the invention and illustrates the basic operation in Mobile Ipv6 handover and the process between Mobile Node (MN) and Correspondent Node (CN), for initializing a “Binding Update” destination option;
  • FIG. 2 shows a time scale for comparing flow charts of a first embodiment of a method and device in accordance with the invention, and of a method not using the first embodiment of the invention;
  • FIG. 3 shows a comparison of the behavior of a congestion window in response to handover with and without the first embodiment of the method and device in accordance with the invention;
  • FIG. 4 illustrates another embodiment of the invention, showing the basic operation in Mobile Ipv6 handover with more details and the process between Mobile Node (MN) and Correspondent Node (CN), for initializing a “Binding Update” destination option;
  • FIG. 5 shows a time scale for comparing flow charts of a second embodiment of a method and device in accordance with the invention, and of a method not using the second embodiment of the invention;
  • FIG. 6 shows a comparison of the behavior of a congestion window in response to handover with and without the second embodiment of the method and device in accordance with the invention;
  • FIG. 7 shows a time scale for comparing flow charts of a third embodiment of a method and device in accordance with the invention, and of a method not using the third embodiment of the invention; and
  • FIG. 8 shows a comparison of the behavior of a congestion window in response to handover with and without the third embodiment of the method and device in accordance with the invention.
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION
  • The invention can be implemented e.g. in a TCP sender with small modifications. TCP sender can be any mobile equipments, such as mobile phones, Personal Digital Assistants (PDAs), laptops, which have e.g. mobile IPv6 stack.
  • In the below described embodiments of the invention, a message, e.g. Binding Update, is used as a trigger to change the normal congestion control such as TCP congestion control. The subsequent congestion control changing processes after occurrence of the trigger can be different in the embodiments in accordance with the present invention. In a first embodiment, a conventional Fast Retransmit and Fast Recovery procedure is invoked after the trigger. Thus, a new trigger is provided for invoking this procedure at an earlier time.
  • In another embodiment, a Slow-Start Threshold (SSTHRESH) is increased after occurrence of the trigger. The new SSTHRESH can be any value between old SSTHRESH and old Congestion Window size (CWND). The actual value of the new SSTHRESH may depend on the network performance. In a network with good performance, a higher SSTHRESH can be set, and in a network with poor performance, a lower SSTHRESH may be set.
  • In a further embodiment, the Congestion Window size (CWND) can be increased after occurrence of the trigger. The value of new CWND can be any value from more than the minimum value (one segment) to old CWND. The new CWND may also depend on the network performance. Different values will result in different CWND behavior.
  • In other embodiments, the above measures can also be combined, that is the Slow-Start Threshold (SSTHRESH) and the Congestion Window size (CWND) can both be increased after occurrence of the trigger.
  • In all the embodiments, there are two different scenarios, i.e. MN acting as receiver and MN acting as transmitter (sender). In FIGS. 2, 5 and 7, only the flow chart of the first scenario, that is MN acting as receiver and CN acting as transmitter, is presented. The flow charts for the second scenario (CN acting as receiver and MN acting as transmitter) are almost the same and are therefore not shown. The invention covers both scenarios.
  • FIG. 1 illustrates a first embodiment of a communication system in accordance with the present invention and shows a MIP (Mobile IP, IP=Internet Protocol), e.g. mobile IPv6, basic operation during handover (Mobile IPv6 is the protocol that supports mobility in IPv6). A Mobile Node (MN) 1 is represented two times, once attached to its home link (upper position of FIG. 1), and once after moving to another location (lower position of FIG. 1) where the MN 1 is away from home and attached not to its home link but served by another serving entity, i.e. by a foreign link. A Home Agent (HA) 2 is associated to the MN for traffic control. With a Mobile IPv6 Binding Update (BU) message, a remote node such as the MN 1 after moving, may inform any other node such as the HA 2 or CN (Correspondent Node) 7 that all traffic sent to the remote node's home address should be currently sent to another address, the so called care-of-address.
  • The Mobile Node (MN) 1 detects his movement e.g. by receiving a Routing advertisement from a router, and generates his Care-of-Address (COA) with a stateless or a stateful address allocating procedure. MN 1 sends this information to his Home Agent (HA) 2 by a Binding Update (BU) message 5. HA 2 modifies the information on the address entry in its Binding Cache and e.g. returns a Binding Acknowledgement (BAck) message to MN 1. A same Binding Update message 3 is also sent from MN 1 to CN 7. This BU message 3 allows route optimization: The CN 7 sends the data directly to the MN 1 and vice versa.
  • Packets from a Correspondent Node (CN) 7 or any other node to the shadow of the Home Address of MN 1 are blocked by the HA 2 and are tunneled to the MN 1 for the destination in the Binding Cache. The connection and traffic between MN 1, HA 2, and CN 7, is effected via the internet 6. Link 4 represents any connection between MN 1 and any other node handled via internet 6.
  • FIG. 2 shows flow charts with a time scale for comparing the previous method and a first embodiment of the method/system according to the invention. The time axis is shown at the right-hand side of FIG. 2. The left column SA represents the IP layer in the MN 1. The middle column SB shows the normal previous behaviour of CN 7 when not employing the embodiment according to the invention.
  • The right-hand column SC shows the behaviour of CN 7 when employing a first embodiment (embodiment 1) of the method and system according to the invention.
  • In FIG. 2, as well as in FIGS. 3, and 5 to 8, the indicated time points t1 to t5 represent the following: t1: Handover begin; t2: Binding Update trigger; t3: Arrival of first ACK; t4: Congestion window size back to the value before handover in the embodiments of the present invention; t5: Congestion window size back to the value before handover in prior art.
  • In step S1 of FIG. 2, it is assumed that the MN 1 moves into a foreign subnet, that is a handover is performed. In step S2, the MN 1 acquires a new care-of address (CoA), and sends, in step S3, a message, preferably a binding update message, to HA 2 and/or CN 7.
  • In step S4 of the middle column SB showing the normal previous behaviour of CN 7, and of the right column SC showing the behaviour of CN 7 according to the first embodiment, the congestion window shrinks to the minimum value as a result of the handover. The size of the congestion window cwnd is set to 1 (cwnd=1).
  • In step S5 of the middle column SB showing the normal previous behaviour of CN 7, CN 7 receives the Binding Update message either directly from MN 1, or from HA 2, but does nothing to TCP.
  • In step S6, it is assumed that the CN 7 sends data and waits for receipt of an Acknowledgment message ACK confirming that MN 1 has received the sent data.
  • If no ACK is received in step 7, the routine proceeds to step S8 in which TCP Timeout is checked as usual. Due to the handover, some packets will get lost so that the ACKs are not properly returned. As long as TCP has not timed out, the waiting loop is executed via steps S8, S7, for the set waiting period. After TCP timeout, the answer of checking step S8 is “Yes” and the program proceeds to step S9, in which the data are resent. Thereafter, the routine jumps back to step S7. This loop may be repeated for a defined number.
  • If an ACK is received in step 7, the routine proceeds to step S10 wherein the congestion window is controlled to increase, returning gradually to the previous value before handover. Thus, the customary slow start mechanism is effected. In step S11, the congestion window has finally returned to the previous value before handover.
  • Now, the right-hand column SC is discussed which shows the behaviour of CN 7 when employing the first embodiment of the method and system according to the invention. In step S12, the CN 7 receives the Binding Update message, and then informs its TCP software/structure thereon (step S13). The TCP software responds by executing step S14, i.e. it triggers its fast retransmit & fast recovery mechanism which may be the customary fast retransmit & fast recovery mechanism. Thus, the CN 7 does not wait for TCP timeout but immediately starts the fast retransmit/recovery mechanism for bringing back the congestion window to its value before the handover as quickly as possible.
  • As an example, according to one of the preferred embodiments, the value ssthresh may be increased or set to the previous value of the old congestion window in step S12.
  • In step S15, the congestion window has thus returned to the value before handover very fast.
  • FIG. 3 shows a comparison of the behavior of the congestion window in response to handover with and without employing the above discussed first embodiment of the system and method according to the invention. The X axis of FIG. 3 represents time, and the Y axis represents the congestion window size and thus TCP throughput.
  • The solid line illustrates the behavior of the congestion window in response to handover when employing the first embodiment of the invention, i.e. when triggering the fast retransmit & fast recovery directly after handover detection, that is receipt of the message confirming handover completion such as the BU (Binding Update) message.
  • The dotted line of FIG. 3 shows the conventional behavior of the congestion window in response to handover when not using the invention, i.e when employing the slow start process.
  • As shown in FIG. 3, the first embodiment of the invention provides a very fast growth of the congestion window size and thus system performance and throughput, in a step-wise and subsequent ramp-like fashion, after any handover occurrence.
  • Contrary thereto, as shown by the dotted line in FIG. 3, the growth of the congestion window size as well as momentary window size, and thus system performance and throughput, is much slower with the conventional slow start technique after handover.
  • In this and the below described embodiments, when the binding updates to the correspondent node should be handled by an agent acting on behalf of the correspondent node, the agent is preferably programmed to send either the binding update messages, or a command for starting the fast retransmit & fast recovery, to the correspondent node, i.e. to the TCP transmitter.
  • According to another embodiment, the CN is adapted to check, when it receives a Binding Update message, whether it has sent any not yet acknowledged data, i.e. it is waiting for acknowledgment messages, or whether it has any data to be sent actually. When the CN does not have any unacknowledged data, i.e. it is not waiting for acknowledgment messages, or does presently not intend to send any data, the correspondent node may be programmed simply not to do anything special if it gets a Binding Update message. When the check should however reveal that the CN has sent any not yet acknowledged data, i.e. it is waiting for acknowledgment messages, or intends to send any data, the above mentioned fast retransmit & fast recovery method of the correspondent node is triggered.
  • The functioning of the method and system according to the invention can be tested by pretending to lose one or more packets, and checking the actions taken by the correspondent node when it gets a Binding Update message.
  • Buffer management (BM) might cause duplication of packets which can be dealt with in the MN, but wastes radio resources. An option is to agree between the MN and the CN upon the use of the disclosed method. This approach can bypass problems with BM and hierarchic mobility management.
  • The present invention thus provides a method and system for improving TCP performance, especially throughput and utilization of network resource.
  • In the following, some basic explanations on the algorithms mentioned above are given with reference to RFC 2001.
  • Slow Start Algorithm:
  • The slow start algorithm adds another window to the sender's TCP: the congestion window “cwnd”, so as to allow the rate of injecting new packets into the network to be the rate of returning acknowledgments by the other end.
  • When a new connection is established with a host on another network, the congestion window is initialized to one segment. Each time an ACK is received, the congestion window is increased by one segment. The sender can transmit packets up to the minimum of the congestion window and the advertised window. The congestion window provides flow control imposed by the sender, while the advertised window is a flow control imposed by the receiver. The sender flow control is based on the sender's assessment of perceived network congestion.
  • The sender starts by transmitting one segment and waiting for its ACK. When that ACK is received, the congestion window is incremented to two so that two segments can be sent. When each of those two segments is acknowledged, the congestion window is increased to four, providing approximately exponential growth. When the capacity of the network is reached, packets may be lost. This informs the sender that its congestion window has grown too large.
  • Congestion Avoidance:
  • Congestion avoidance deals with lost packets. Congestion can e.g. occur when high data rate input streams arrive at a router with insufficient output capacity. A loss of a packet signals congestion somewhere in the network between the source and destination. There are two possible indications of packet loss: occurrence of timeout, or receipt of duplicate ACKs. When congestion occurs TCP slows down its transmission rate of packets into the network, and invokes the slow start algorithm.
  • Congestion avoidance and slow start require that two variables be maintained for each connection: a congestion window, cwnd, and a slow start threshold size. Slow start continues until TCP is halfway to where it was when congestion occurred, and then congestion avoidance takes over. Congestion avoidance dictates that cwnd be incremented each time an ACK is received, with linear growth of cwnd.
  • Fast Retransmit:
  • The Fast Retransmit algorithm is a modification to the congestion avoidance algorithm. Note that TCP may generate an immediate acknowledgment (a duplicate ACK) when an out-of-order segment is received. This duplicate ACK should not be delayed. This duplicate ACK informs the other node that a segment was received out of order.
  • Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. If there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, this will normally be caused by having lost a segment during transmission. TCP then performs a retransmission of the missing unacknowledged segment, without waiting for a retransmission timer to expire.
  • Fast Recovery
  • After fast retransmit has resent the missing segment, congestion avoidance (not slow start) is performed. This is the fast recovery algorithm. It is an improvement that allows high throughput under moderate congestion, especially for large windows.
  • The fast retransmit and fast recovery algorithms are usually implemented together as follows.
    • 1. When the third duplicate ACK is received in succession, the slow start threshold size sst is set e.g. to one-half of the current congestion window, cwnd, and the missing segment is retransmitted. Then, cwnd is set to sst plus 3 times the segment size. This increases the congestion window by the number of segments received by the other end.
    • 2. Each time another duplicate ACK arrives, cwnd is incremented by the segment size, so as to increase the congestion window each time an additional segment has left the network.
    • 3. When a next ACK arrives that acknowledges new data, this ACK will normally be the acknowledgment of the retransmission performed in step 1. This ACK acknowledges all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK. The cwnd is then set to sst, e.g. to the value of sst set in step 1. This step provides congestion avoidance, since TCP is reduced to one-half of the rate before losing the packet.
  • Preferred embodiments of the invention relate to TCP performance enhancement during handovers in MIP such as Mobile IPv6 network. The embodiments propose a mechanism to undo an unnecessary congestion control triggered by reordered, delayed or lost packets due to handover.
  • The basic idea of some embodiments of the invention is to use a signal indicating handover completion, e.g. a binding update message, and then, recover the threshold ssthresh to a higher value than conventionally, e.g. to more than one-half of, up to the value of the previous congestion window, instead of only one half of this value. By this new higher ssthresh, the congestion window can be restored faster. Therefore, the TCP throughput and utilization of network resource are improved.
  • These or other embodiments of the invention basically belong to MIP focus area. A basic idea of these and some other but not necessarily all embodiments of the invention is:
    • 1. Using a message, e.g. Binding Update, as an indication of successfully completed handover, and/or
    • 2. After this message, e.g. Binding Update, triggering a mechanism to change the slow-start parameter in order to restore the congestion window faster than regular TCP.
  • The above embodiments may be considered as a conservative scheme, which changes the threshold in slow-start algorithm (ssthresh). It increases ssthresh to the value of the previous congestion window. Because the congestion window grows exponentially before ssthresh and grows linearly after ssthresh, higher ssthresh lets the congestion window grows faster.
  • This alternative 2. is a moderate scheme which changes the initial size of congestion window. It directly increases the congestion window to a high proper value. This value can be a predetermined value based on network performance or a dynamic value based on real-time network measurement. Better result on TCP throughput can be obtained.
  • The invention may be used in e.g. proxies and servers without standardization, in TCP terminals, such as mobile phone, PDA, laptop, or the like.
  • In one or more of the embodiments of the invention, a fast retransmit and fast recovery mechanism is initiated instead of keeping slow-start initiate after handover completion message, e.g. Binding Update.
  • The below described embodiment of the invention pays attention to the two scenarios that MN is taken as the TCP receiver and sender.
  • IPv6 [Internet Protocol version 6], especially Mobile IPv6, is a research field, in which an Internet draft on mobile IPv6 is likely to become a RFC in the near future. However, if the MN is at some geographical and topological distance away from the HA and CN, the amount of time involved in sending the binding updates may be greater than hundred milliseconds. This latency in routing update may cause poor TCP performance. The described embodiments provide TCP enhancement during handovers in mobile IPv6. According to some embodiments, a mechanism is provided which recovers the slow-start threshold ssthresh to more than half of, up to the previous value of the old congestion window after a handover completion if the timeout is caused by the handover. This improves TCP throughput. For a flow with a large congestion window W, a halving of the congestion window can be a significant performance reduction as it takes at least W/2 round-trip times for the flow to recover its old congestion window.
  • There are two scenarios described in the following, with MN acting as a receiver and MN as a sender.
  • MN acting as a receiver: If the CN determines that the packet loss, reordered packets and delayed packets are produced due to handover process and not to congestion, then the CN may implement the option of undoing the halving in the congestion window, by means of which the throughput of TCP connection and the utilization of network resource can thus be improved. When the CN receives the Binding Update from MN, this mechanism is triggered.
  • The objective is achieved by an algorithm, which comprises the following steps:
    • (1) When a MN moves from one subnet into another foreign subnet, it acquires its care-of-address in the foreign link, by using the IPv6 Neighbour Discovery or other methods;
    • (2) the MN registers the association between the MN's home address and the current care-of-address with its home agent and the CN by sending a packet containing a “Binding Update” destination option;
    • (3) whenever the CN receives a “Binding Update”, the software, e.g. Mobile IPv6 software, in the CN signals the TCP software;
    • (4) the TCP software on CN stepwisely increases the slow-start threshold ssthresh to a value of more than half of, up to the previous value of the old congestion window if slow-start happened, effectively slow starting until the congestion window has reached its old value. In addition to avoid the unnecessary retransmits, CN may preferably adjust the duplicate acknowledgement threshold or the retransmit timeout parameters so as to reduce retransmits.
  • MN acting as a sender: If the MN determines that packet loss, reordered packets and delayed packets are produced due to handover process but not to congestion, then the MN preferably has the option, means and functions of undoing the halving in the congestion window, that is of increasing the slow-start threshold ssthresh to a value of more than half of, up to the previous value of the old congestion window. Thereby, the throughput of TCP connection and the utilization of network resource can thus be improved. When the MN forms the Binding Update, this mechanism is triggered in the MN.
  • The objective is achieved by an algorithm, which comprises the following steps:
    • (1) When a MN moves from one subnet into another foreign subnet, it acquires its care-of-address in the foreign link, e.g. by using the IPv6 Neighbor Discovery;
    • (2) whenever the MN forms a “Binding Update”, the software, e.g. Mobile IPv6 software in the MN signals the TCP software;
    • (3) the TCP software on MN increases the slow-start threshold ssthresh to the previous value of the old congestion window if slow-start happens, effectively slow starting until the congestion window has reached its old value. In addition to avoid the unnecessary retransmits, MN may be equipped to adjust the duplicate acknowledgement threshold or the retransmit timeout parameters.
  • The (previous) slow-start threshold ssthresh value of the old congestion window may be stored in the MN and/or in the CN, e.g. if slow-start happens,
  • These embodiments of the invention present a mechanism to undo unnecessary congestion control responses to reordered or delayed or lost packets due to handover. In Mobile IPv6, after a MN acquires its care-of-address in a foreign link, it will register this care-of-address with its home agent and the CN by sending the “Binding Update” destination option. The “Binding Update” destination option is the earliest signal for the CN to be informed that the handover is successful and will complete soon. Hence, it is the earliest time for CN and MN to be able to undo congestion control.
  • If congestion control in TCP does not run during handover which performance is good enough, the proposed mechanism is preferably not in effect.
  • There are key actions in the present invention to improve earlier solutions:
      • Undo unnecessary congestion control due to handover after a handover completes,
      • Recover previous control parameters as fast as possible.
  • Some advantages of the embodiments are:
      • Improving the TCP throughput
      • Improving the utilization of network resource
      • Only minor modifications to the TCP and Mobile IPv6 software in TCP transmitter needed
  • The invention can be implemented in TCP terminals with small modifications. TCP terminals could be any mobile equipment, such as mobile phones, PDAs and laptops, which have mobile IPv6 stack. The TCP performance can be improved when this method is used.
  • FIG. 4 shows another embodiment of the invention employing the above described means and functions of Mobile IP, preferably Mobile IPv6, basic operation. Reference numerals identical to the reference numerals used in FIG. 1 designate identical or at least similar means and structures, as described above. The network environment and handover process are as same as the embodiment shown in FIG. 1. FIG. 4 provides more details and shows some network elements which are not shown in FIG. 1. The MN 1 has a home network 10 providing home link, home address, and home subnet prefix, and comprising an home agent 2. When the MN 1 has moved to another network, data/messages/information are exchanged between MN 1 and home agent 2 or CN 7 via internet 6 and foreign/visited or access networks 11, 13 having access routers 12, 14, as shown in FIG. 4. Network 11 provides foreign link, care-of address, and foreign subnet prefix. A Binding Update message is generated in and sent from the MN 1 via internet 6 to the home network 10.
  • FIGS. 5 and 6 illustrate a second embodiment of the method/system according to the invention, and show flow charts with a time scale for comparing the prior method and the second embodiment. The time axis is shown at the right-hand side of FIG. 5. As mentioned above, the time points t1 to t5 represent the following: t1: Handover begin; t2: Binding Update trigger; t3: Arrival of first ACK; t4: Congestion window size back to the value before handover in the embodiments of the present invention; t5: Congestion window size back to the value before handover in prior art. The left column SA of FIG. 5 represents the IP layer in the MN 1. The middle column SB shows the normal previous behaviour of CN 7 when not employing the embodiment according to the invention. The left column SA and middle column SB of FIG. 5 are identical to the left and middle columns of FIG. 2 so that it is referred to the above description of the steps and functions of these columns, as well as of step S4 of the right-hand column SC.
  • The right-hand column SC of FIG. 5 shows the functioning of CN 7 when employing the second embodiment (embodiment 2) of the method and system according to the invention. In step S12, the CN 7 receives the Binding Update message, and then informs its TCP software/structure thereon (step S13). The TCP software responds by executing step S16, i.e. it immediately increases the threshold value ssthresh to a value “New ssthresh” higher than the previous customary value “old ssthresh”, as shown in FIG. 6.
  • The threshold value ssthresh is thus set to be higher than the value set according to the prior method (in which the ssthresh value was set to one half of the previous value before handover begin, see FIG. 6 “OLD ssthresh”), for example to a range of 1.1 to 2.0 of the value “old ssthresh”, more preferably 1.5 to 2.0 of the previous value. The system then waits for acknowlegdments ACK as usual, similar to steps S5 to S10 of the middle column SB of FIG. 5.
  • Upon receipt of ACKs (step S17), the congestion window size is exponentially increased up to the value “new ssthresh”. Thereafter, the congestion window size linearity increases up to the maximum value (value before handover), as shown in FIG. 6. The congestion window size is hence returned to the value before handover much quicker than in the previous method.
  • FIG. 6 shows a comparison of the behavior of the congestion window in response to handover with and without employing the above discussed second embodiment of the system and method according to the invention. The X axis of FIG. 6 represents time, and the Y axis represents the congestion window size and thus TCP throughput. The solid line illustrates the behavior of the congestion window in response to handover when employing the second embodiment of the invention, i.e. when increasing the congestion window size directly after handover detection, that is after receipt of the message confirming handover completion such as the BU (Binding Update) message. The dotted line of FIG. 6 shows the conventional behavior of the congestion window in response to handover when not using the invention, i.e when employing the old threshold value. After handover begin the width cwnd of the congestion window is reduced to the lowest value. After handover end, the width of the congestion window is exponentially increased to the ssthresh value. As shown in FIG. 6, the second embodiment of the invention provides a very fast growth of the congestion window size and thus system performance and throughput, after any handover occurrence.
  • In accordance with a further embodiment of the invention illustrated in FIGS. 7 and 8, the width of the congestion window is stepwise increased at the end of the handover, e.g. when sending or receiving a binding update message or packet.
  • Similar to the above described embodiments, the objective of this embodiment is to improve the throughput of TCP connection and the utilization of the network resource during the MN hands over. The objective is achieved by immediately increasing the congestion window to a high proper value while the handover finished, not as usual which relies on the TCP slow-start mechanism to recover from the minimal initial window (usually the initial window is only 1 segment).
  • When the MN acts as the TCP sender, the method comprises the following steps:
    • 1) When MN moves from one subnet into another foreign subnet, it acquires its care-of address in foreign-link, according to the methods e.g. of IPv6 such as Neighbour Discovery or other methods;
    • 2) By sending “Binding Update” message, the MN registers the association between the MN's home address and its care-of address with home agent (HA) and CN;
    • 3) After MN sends “Binding Update” message, the Mobile IPv6 software in the MN informs the TCP software in the MN of the handover;
    • 4) The TCP software on MN increases the congestion window size to a proper value instead of 1 segment when it receives the signal from the Mobile IPv6 software.
  • The same function may also take place in the CN when it is informed on successful handover, e.g. by receiving a BU message.
  • FIGS. 7 and 8 illustrate this third embodiment of the method/system according to the invention, and show flow charts with a time scale for comparing the previous method and the second embodiment. The time axis is shown at the right-hand side of FIG. 7. As mentioned above, the time points t1 to t5 represent the following: t1: Handover begin; t2: Binding Update trigger; t3: Arrival of first ACK; t4: Congestion window size back to the value before handover in the embodiments of the present invention; t5: Congestion window size back to the value before handover in prior art. The left column SA of FIG. 7 represents the IP layer in the MN 1. The middle column SB shows the normal previous behaviour of CN 7 when not employing this embodiment according to the invention. The left column SA and middle column SB of FIG. 7 are identical to the left and middle columns of FIGS. 2 and 5 so that it is referred to the above description of the steps and functions of these columns, as well as of step S4 of the right-hand column SC.
  • The right-hand column SC of FIG. 7 shows the functioning of CN 7 when employing the third embodiment (embodiment 3) of the method and system according to the invention. In step S12, the CN 7 receives the Binding Update message, and then informs its TCP software/structure thereon (step S13). The TCP software responds by executing step S18, i.e. it immediately increases the width or size of the congestion window in a stepwise manner to a proper value. This value can be predetermined based on the network performance and/or can be dynamic updated based on network measurement. It may be equal to one half of the window size value before handover, or may be lower or higher than one-half of this value. A value of at least one-half of the window size value before handover is preferred. The system then waits for acknowlegdments ACK as usual, similar to steps S5 to S10 of the middle column SB of FIG. 5. After receipt of the first ACKs at time t3, the congestion window size is linearly increased up to the window size value before handover (time t4). Thus the window size is very rapidly brought back to the maximum admissible size under the present conditions, as shown in FIG. 8.
  • FIG. 8 shows a comparison of the behavior of the congestion window in response to handover with and without employing the above discussed third embodiment of the system and method according to the invention. The X axis of FIG. 8 represents time, and the Y axis represents the congestion window size and thus TCP throughput. The solid line illustrates the behavior of the congestion window in response to handover when employing the third embodiment of the invention, i.e. when increasing the congestion window size directly after handover detection, that is after receipt of the message confirming handover completion such as the BU (Binding Update) message. The dotted line of FIG. 8 shows the conventional behavior of the congestion window in response to handover when not using the invention, i.e when employing the old threshold value and old window size. After handover begin (t1) the width cwnd of the congestion window is reduced to the lowest value. After handover end (t2), the width of the congestion window is stepwise increased to the. As shown in FIG. 8, the third embodiment of the invention provides a very fast growth of the congestion window size and thus system performance and throughput, after any handover occurrence.
  • An advantage of the invention is to increase the transmitting rate immediately after the handover finish by increasing the initial window of slow-start mechanism, so as to improve the throughput just after the handover finish, and utilization of network resource.
  • Another advantage of the invention is to use a “handover successful” message or “handover completed” message such as the “Binding Update” message as the trigger to begin the transmission as soon as possible, instead of waiting for the recovery of TCP mechanism itself.
  • As mentioned above, in current Mobile IPv6 networks, the duration time of handover of MN between two subnets is quite long, compared e.g. with the Round-trip time (RTT). Even when using enhanced handover mechanisms, such as Fast Handover proposed in IETF, the handover time is still a multiple of RTT. The long handover time usually will result in the timeout in the TCP sender, and the congestion window (CWND) in the TCP sender will decrease to 1 MSS and invoke the slow-start mechanism in prior art devices. In fixed networks, the timeout is the signal of network congestion. In order to alleviate the network load during congestion, the transmission rate i.e. the congestion window will be decreased dramatically, saying 1 segment. However, in Mobile IPv6 networks, misinterpreting the timeout due to handover as congestion will induce the throughput degrade and also underutilize the network resources.
  • As shown in the Figures, at time t1, MN begins a handover. The handover will need some time until MN sends a “binding update” message at time t2. However, in the TCP layer, the TCP sender does not know anything about the handover. During the handover, the timeout may happen several times, and he TCP sender retransmits one packet after each timeout. In the prior art, until time t3, the TCP sender could successfully retransmit the packets, with the congestion window size 1. Then in the prior art slow-start process, the congestion window increases one by one with every new ACK arriving. This prior art slow-start process is illustrated by the dotted lines in FIG. 8 (denoted “previous method”).
  • The present invention improves the TCP performance in the current situation. The congestion window size may be stepwise increased at the time of sending or receiving the indication of handover end, that is at time t2. The congestion window size may be stepwise, i.e. immediately increased to a proper determined value. The determined value may e.g. lie in the range of from 20% to 100% of the size of the congestion window immediately before handover begin at time t1. A preferred determined value can for instance be one half (50%) of the previous congestion window size before handover begin at time t1. The determined value can for instance also be higher than one half, e.g. 100% of the previous congestion window size before handover begin at time t1, t4.
  • There are key actions in the present embodiments of the invention to improve earlier solutions: Taking advantage of, i.e. using a message, for example a MIP message such as the Mobile IPv6 message to trigger TCP optimisation, the transmission can begin earlier than usual. Further, fast or stepwise increase of the congestion window to a proper value after handover, eliminates the slow-start effect. The congestion window can be recovered to an appropriate value faster than usual.
  • Advantages are that the TCP throughput is improved, the utilization of network resource is increased, and only minor modifications to the TCP and Mobile IPv6 software in TCP transmitter are needed, which are easy to implement in network elements such as mobile phones, terminals, nodes etc.
  • From the congestion window curve, with this embodiment of the present invention the congestion window will increase earlier and faster than in the normal situation. With the present invention, the throughput is improved during handover.
  • The specific features of the above discussed embodiments can also be applied in any arbitrary combination. For instance, the congestion window size may be stepwise increased to a predetermined value (lower than one-half of the window size value before handover) after the handover complete message, e.g. BU message, and thereafter be exponentially increased to another threshold value ssthresh higher than one-half of the window size value before handover, with a final linear increase up to the maximum admissible value.
  • The congestion control means of the first and second network elements, i.e. the mobile node and the correspondent node, may be implemented using TCP (Transport Control Protocol) software, preferably a Mobile IPv6 software.
  • Although the invention has been described above with reference to specific embodiments, the scope of the invention also covers any alterations, additions, modifications, and omissions of the disclosed features.

Claims (43)

1. Method for managing a communication between a first network element and a second network element, wherein
the communication is performed via a network on a packet basis,
acknowledgment messages acknowledging receipt of packets are returned to the network element having sent these packets, and
a congestion control is performed which variably defines an allowable number of packets which can be sent before receipt of acknowledgment messages for these packets, wherein said allowable number of packets is reduced in case of packet loss during transmission,
wherein, when the first network element performs a hand-over and sends a message informing the network or a network element on the hand-over, the network or network element changes the congestion control to provide faster recovery rate of said allowable number after handover as compared to the recovery rate of said allowable number after packet loss.
2. Method according to claim 1, wherein
the congestion control provides a congestion window of variable size, the size of the congestion window defining said allowable number of packets which can be sent before receipt of acknowledgment messages for these packets, and the size being controlled dependant on the number of sent packets for which no acknowledgment messages have been received so that the window size is reduced in case of packet loss during transmission,
wherein, when the first network element performs a hand-over and sends a message informing the network or a network element on the hand-over, the network or network element changes the congestion window size control to provide faster recovery rate of the window size after handover as compared to the recovery rate of the window size after packet loss.
3. Method according to claim 1, wherein said congestion control is performed in at least one of the first and second network elements.
4. Method according to claim 1, wherein the first network element is a mobile node which, when moving from one subnet into another foreign subnet, acquires a care-of address, and sends said message to its home network and/or to a correspondent node informing the network or node on the care-of-address.
5. Method according to claim 1, wherein said message is a “Binding Update” message.
6. Method according to claim 1, wherein said second network element comprises a fast retransmit and fast recovery algorithm so as to provide said faster recovery rate, wherein, when the message is sent from the first network element to the second network element, the second network element, when receiving the message, triggers the invocation of said fast retransmit and fast recovery algorithm.
7. Method according to claim 1, wherein said first network element comprises a fast retransmit and fast recovery algorithm so as to provide said faster recovery rate, and is adapted to trigger, when generating said message, the invocation of said fast retransmit and fast recovery algorithm.
8. Method according to claim 1, wherein the faster recovery rate includes a step of increasing the size of a congestion window in a step-wise manner.
9. Method according to claim 8, wherein the size of the congestion window is step-wise increased to 20% to 100% of the size of the congestion value before start of the handover.
10. Method according to claim 9, wherein the size of the congestion window is step-wise increased to at least approximately 50% of the size of the congestion value before start of the handover.
11. Method according to claim 1, wherein the faster recovery rate is implemented by increasing the size of a congestion window in a step-wise manner to a value lying in a range from more than a minimum window size up to, and including the size of the window before handover, and by subsequent ramp-like or exponential increase of the congestion window size.
12. Method according to claim 1, wherein the congestion control includes increasing the size of a congestion window in an exponential manner up to a threshold value and a subsequent ramp-like increasing of the congestion window size, wherein the faster recovery rate is implemented by setting the threshold value to at least one-half of, and up to, the previous value of the congestion window before start of the handover.
13. Method according to claim 1, wherein the second network element is a correspondent node.
14. Method according to claim 1, wherein at least one of the first and second network elements comprises a congestion control means, and wherein when generating or receiving said message, the first and/or second network element informs its congestion control means which in response triggers the invocation of a fast retransmit and fast recovery algorithm.
15. Method according to claim 1, wherein at least one of the first and second network elements comprises a congestion control means, wherein the network element when generating or receiving said message, sends a signal to the congestion control means, the signal indicating to the congestion control means that the congestion control is to be changed so as to provide said faster recovery rate.
16. Method according to claim 15, wherein the signal is implemented by duplicating ACK packets by an IP layer function to a TCP layer function.
17. Method according to claim 1, wherein the communication between the first and second network elements is an Mobile IPv6-based communication.
18. System for managing a communication between a first network element and a second network element, wherein
the communication is performed via a network on a packet basis, and acknowledgment messages acknowledging receipt of packets are returned to the network element having sent these packets, comprising
congestion control means for performing a congestion control which variably defines an allowable number of packets which can be sent before receipt of acknowledgment messages for these packets, wherein said allowable number of packets is reduced in case of packet loss during transmission,
wherein, when the first network element performs a hand-over and sends a message informing the network or a network element on the hand-over, the congestion control means changes the congestion control to provide faster recovery rate of said allowable number after handover as compared to the recovery rate of said allowable number after packet loss.
19. System according to claim 18, wherein
the congestion control means provides a congestion window of variable size, the size of the congestion window defining said allowable number of packets which can be sent before receipt of acknowledgment messages for these packets, and the size being controlled dependant on the number of sent packets for which no acknowledgment messages have been received so that the window size is reduced in case of packet loss during transmission,
wherein, when the first network element performs a hand-over and sends a message informing the network or a network element on the hand-over, the congestion control means is adapted to change the congestion window size control to provide faster recovery rate of the window size after handover as compared to the recovery rate of the window size after packet loss.
20. System according to claim 18 or 19, wherein said congestion control means is provided in at least one of the first and second network elements.
21. System according to claim 18, wherein the first network element is a mobile node which, when moving from one subnet into another foreign subnet, acquires a care-of address, and sends said message to its home network informing the latter on the care-of-address.
22. System according to claim 18, wherein said message is a “Binding Update” message.
23. System according to claim 18, wherein said second network element comprises a fast retransmit and fast recovery algorithm so as to provide said faster recovery rate, wherein, when the message is sent from the first network element to the second network element, the second network element, when receiving the message, triggers the invocation of said fast retransmit and fast recovery algorithm.
24. System according to claim 18, wherein said first network element comprises a fast retransmit and fast recovery algorithm so as to provide said faster recovery rate, and is adapted to trigger, when generating said message, the invocation of said fast retransmit and fast recovery algorithm.
25. System according to claim 18, wherein the faster recovery rate includes a step of increasing the size of a congestion window in a step-wise manner.
26. System according to claim 25, wherein the size of the congestion window is step-wise increased to 20% to 100% of the size of the congestion value before start of the handover.
27. System according to claim 26, wherein the size of the congestion window is step-wise increased to at least approximately 50% of the size of the congestion value before start of the handover.
28. System according to claim 18, wherein the faster recovery rate is implemented by increasing the size of a congestion window in a step-wise manner to a value lying in a range from more than a minimum window size up to, and including the size of the window before handover, and by subsequent ramp-like or exponential increase of the congestion window size.
29. System according to claim 18, wherein the congestion control includes increasing the size of a congestion window in an exponential manner up to a threshold value and a subsequent ramp-like increasing of the congestion window size, wherein the faster recovery rate is implemented by setting the threshold value to at least one-half of, and up to, the previous value of the congestion window before start of the handover.
30. System according to claim 18, wherein the second network element is a correspondent node.
31. System according to claim 18, wherein at least one of the first and second network elements comprises a congestion control means, and wherein when generating or receiving said message, the first and/or second network element informs its congestion control means which in response triggers the invocation of a fast retransmit and fast recovery algorithm.
32. System according to claim 18, wherein at least one of the first and second network elements comprises a congestion control means, wherein the network element when generating or receiving said message, sends a signal to the congestion control means, the signal indicating to the congestion control means that the congestion control is to be changed so as to provide said faster recovery rate.
33. System according to claim 32, wherein the signal is implemented by duplicating ACK packets by an IP layer function to a TCP layer function.
34. System according to any one of the preceding system claim 18, wherein the communication between the first and second network elements is an Mobile IPv6-based communication.
35. Network element to be used in a system for managing a communication between network elements, preferably as defined in claim 18, wherein the communication is performed via a network on a packet basis, and acknowledgment messages acknowledging receipt of packets are returned to the network element having sent these packets, comprising
congestion control means for performing a congestion control which variably defines an allowable number of packets which can be sent before receipt of acknowledgment messages for these packets, wherein said allowable number of packets is reduced in case of packet loss during transmission,
wherein, when the network element performs a hand-over and sends a message informing the network or a network element on the hand-over, the congestion control means changes the congestion control to provide faster recovery rate of said allowable number after handover as compared to the recovery rate of said allowable number after packet loss.
36. Network element according to claim 35, wherein
the congestion control means provides a congestion window of variable size, the size of the congestion window defining said allowable number of packets which can be sent before receipt of acknowledgment messages for these packets, and the size being controlled dependant on the number of sent packets for which no acknowledgment messages have been received so that the window size is reduced in case of packet loss during transmission,
wherein, when the network element performs a hand-over and sends a message informing the network or a network element on the hand-over, the congestion control means changes the congestion window size control to provide faster recovery rate of the window size after handover as compared to the recovery rate of the window size after packet loss.
37. Network element according to claim 35 or 36, wherein said network element comprises a fast retransmit and fast recovery algorithm so as to provide said faster recovery rate, and is adapted to trigger, when generating said message, the invocation of said fast retransmit and fast recovery algorithm.
38. Network element according to claim 35, wherein the faster recovery rate includes a step of increasing the size of a congestion window in a step-wise manner, wherein the size of the congestion window is step-wise increased to 20% to 100% of the size of the congestion value before start of the handover.
39. Network element according to claim 37, wherein the size of the congestion window is step-wise increased to at least approximately 50% of the size of the congestion value before start of the handover.
40. Network element according to claim 35, wherein the congestion control includes increasing the size of a congestion window in an exponential manner up to a threshold value and a subsequent ramp-like increasing of the congestion window size, wherein the faster recovery rate is implemented by setting the threshold value to at least one-half of, and up to, the previous value of the congestion window before start of the handover.
41. Network element according to claim 35, wherein the network element comprises a congestion control means, and wherein when generating or receiving said message, the network element informs its congestion control means which in response triggers the invocation of a fast retransmit and fast recovery algorithm.
42. Network element according to claim 35, wherein the network element comprises a congestion control means, wherein the network element when generating or receiving said message, sends a signal to the congestion control means, the signal indicating to the congestion control means that the congestion control is to be changed so as to provide said faster recovery rate.
43. Network element according to claim 42, wherein the signal is implemented by duplicating ACK packets by an IP layer function to aTCP layer function.
US10/510,696 2002-04-12 2003-04-11 System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network Abandoned US20050144303A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PCT/IB2002/001181 WO2003088609A2 (en) 2002-04-12 2002-04-12 System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network
IB02/01181 2002-04-12
PCT/IB2003/001342 WO2003088622A1 (en) 2002-04-12 2003-04-11 System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network

Publications (1)

Publication Number Publication Date
US20050144303A1 true US20050144303A1 (en) 2005-06-30

Family

ID=29227340

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/510,696 Abandoned US20050144303A1 (en) 2002-04-12 2003-04-11 System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network

Country Status (6)

Country Link
US (1) US20050144303A1 (en)
EP (1) EP1495623B1 (en)
AT (1) ATE472888T1 (en)
AU (2) AU2002253437A1 (en)
DE (1) DE60333182D1 (en)
WO (2) WO2003088609A2 (en)

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040240413A1 (en) * 2003-05-29 2004-12-02 Kil-Lyeon Kim Method and system for controlling packet transmission using bind update message upon handoff of mobile node in IPv6 based wireless network
US20050228896A1 (en) * 2004-04-07 2005-10-13 Sony Corporation And Sony Electronics, Inc. TCP congestion control based on bandwidth estimation techniques
US20060133316A1 (en) * 2004-12-21 2006-06-22 Jagana Venkata R Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
US20070070892A1 (en) * 2005-09-23 2007-03-29 Samsung Electronics Co., Ltd. Method of controlling transmission rate and communication device using the same
WO2007068626A1 (en) 2005-12-16 2007-06-21 International Business Machines Corporation Method for faster mobility handoff of a mobile node
US20070147304A1 (en) * 2004-12-21 2007-06-28 Jagana Venkata R Method of Reestablishing Communication by a Mobile Node upon Recovery from an Abrupt Shut Down
US20080043621A1 (en) * 2004-01-08 2008-02-21 Hicham Hatime Systems and Methods for Improving Network Performance
US20080080426A1 (en) * 2006-09-29 2008-04-03 Samsung Electronics Co., Ltd. Mobile terminal and method for providing seamless service upon handover
WO2008048071A2 (en) * 2006-10-19 2008-04-24 Lg Electronics Inc. Methods of executing handover in a mobile communication system
US20080137629A1 (en) * 2006-12-08 2008-06-12 Electronics And Telecommunications Research Institute Communication method for using bandwidth efficiently in internet protocol version 6
US20100011270A1 (en) * 2006-10-05 2010-01-14 Ntt Docomo, Inc Communication system, communication device, and communication method
US20100103880A1 (en) * 2007-08-26 2010-04-29 Huawei Technologies Co., Ltd. Data transmission control method and data transmission device
US20110009158A1 (en) * 2006-05-13 2011-01-13 Lg Electronics Inc. Method of executing handover in a mobile communication system
US7895648B1 (en) * 2004-03-01 2011-02-22 Cisco Technology, Inc. Reliably continuing a secure connection when the address of a machine at one end of the connection changes
US20110153792A1 (en) * 2005-09-19 2011-06-23 Panasonic Corporation Enabling simultaneous use of home network and foreign network by a multihomed mobile node
US20110158253A1 (en) * 2009-12-25 2011-06-30 Cisco Technology, Inc., A Corporation Of California Increasing Transmission Rate to a Remote Device In Response to Attributing Information Loss as Not Being a Result of Network Congestion
US20110216648A1 (en) * 2010-03-05 2011-09-08 Microsoft Corporation Congestion control for delay sensitive applications
US20110219287A1 (en) * 2010-03-05 2011-09-08 Microsoft Corporation Remote presentation over lossy transport with forward error correction
US20110239073A1 (en) * 2008-12-05 2011-09-29 Ntt Docomo, Inc. Communication device and communication method
US20120195287A1 (en) * 2011-01-28 2012-08-02 Industry-Academic Cooperation Foundation, Yonsei University Communication method using duplicated acknowledgement
US20130155958A1 (en) * 2009-11-20 2013-06-20 Telefonaktiebolaget L M Ericsson (Publ) System, method and devices for enabling efficient hybrid route optimization between two mobile endpoints
US20140181140A1 (en) * 2010-11-15 2014-06-26 Samsung Electronics Co., Ltd. Terminal device based on content name, and method for routing based on content name
US20140304425A1 (en) * 2013-04-06 2014-10-09 Citrix Systems, Inc. Systems and methods for tcp westwood hybrid approach
US20150029863A1 (en) * 2013-07-23 2015-01-29 Cisco Technology, Inc. Network Congestion Control with Awareness of Random Packet Losses
US20150120882A1 (en) * 2012-05-30 2015-04-30 Canon Kabushiki Kaisha Information processing apparatus, program, and control method
US20170344960A1 (en) * 2014-12-18 2017-11-30 Ipco 2012 Limited A System, Method and Computer Program Product for Receiving Electronic Messages
US20180159779A1 (en) * 2016-12-07 2018-06-07 Cisco Technology, Inc. Load Balancing Eligible Packets in Response to a Policing Drop Decision
US10708213B2 (en) 2014-12-18 2020-07-07 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US10963882B2 (en) 2014-12-18 2021-03-30 Ipco 2012 Limited System and server for receiving transaction requests
US11080690B2 (en) 2014-12-18 2021-08-03 Ipco 2012 Limited Device, system, method and computer program product for processing electronic transaction requests
US20230308397A1 (en) * 2022-03-25 2023-09-28 Sandvine Corporation System and method for calibration of traffic flow acceleration

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005160054A (en) 2003-11-04 2005-06-16 Matsushita Electric Ind Co Ltd Method and device for mobile communication
CN100493082C (en) * 2004-10-25 2009-05-27 华为技术有限公司 Method for controlling SIP server congestion
US20080088408A1 (en) 2004-11-17 2008-04-17 Telefonaktiebolaget Lm Ericsson (Publ) Fast Resume Of Tcp Sessions
CN101369877B (en) * 2007-12-27 2012-08-22 华为技术有限公司 Wireless transmission control protocol processing method and equipment

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5912878A (en) * 1997-02-27 1999-06-15 Motorola, Inc. Method and end station with improved user reponse time in a mobile network
US6208620B1 (en) * 1999-08-02 2001-03-27 Nortel Networks Corporation TCP-aware agent sublayer (TAS) for robust TCP over wireless
US20030016655A1 (en) * 2001-01-29 2003-01-23 Docomo Communications Laboratories Usa, Inc. Fast dynamic route establishment in wireless, mobile access digital networks using mobility prediction
US20030035407A1 (en) * 2000-03-27 2003-02-20 Rangaprasad Govindarajan Packet retransmission in wireless packet data networks
US6526022B1 (en) * 1998-06-30 2003-02-25 Sun Microsystems Detecting congestion by comparing successive loss of packets in windows to provide congestion control in reliable multicast protocol
US20030219034A1 (en) * 2002-02-19 2003-11-27 Lotter Michiel Petrus Method and apparatus optimizing a radio link
US6704571B1 (en) * 2000-10-17 2004-03-09 Cisco Technology, Inc. Reducing data loss during cell handoffs
US6801512B1 (en) * 2000-03-23 2004-10-05 Motorola, Inc. Method and apparatus for providing a distributed architecture digital wireless communication system
US6876639B1 (en) * 2000-06-01 2005-04-05 Nortel Networks Limited Transmission control protocol handoff notification system and method
US6975591B1 (en) * 2000-11-22 2005-12-13 International Business Machines Corporation Methodology for improving TCP throughput over lossy communication links
US7187666B1 (en) * 2001-03-30 2007-03-06 Ipr Licensing, Inc. Employing simulated acknowledgment signals for efficient handoffs in cellular packet networks

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2249152C (en) * 1998-09-30 2003-07-08 Northern Telecom Limited Apparatus for and method of managing bandwidth for a packet-based connection
US6757248B1 (en) * 2000-06-14 2004-06-29 Nokia Internet Communications Inc. Performance enhancement of transmission control protocol (TCP) for wireless network applications

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5912878A (en) * 1997-02-27 1999-06-15 Motorola, Inc. Method and end station with improved user reponse time in a mobile network
US6526022B1 (en) * 1998-06-30 2003-02-25 Sun Microsystems Detecting congestion by comparing successive loss of packets in windows to provide congestion control in reliable multicast protocol
US6208620B1 (en) * 1999-08-02 2001-03-27 Nortel Networks Corporation TCP-aware agent sublayer (TAS) for robust TCP over wireless
US6801512B1 (en) * 2000-03-23 2004-10-05 Motorola, Inc. Method and apparatus for providing a distributed architecture digital wireless communication system
US20030035407A1 (en) * 2000-03-27 2003-02-20 Rangaprasad Govindarajan Packet retransmission in wireless packet data networks
US6876639B1 (en) * 2000-06-01 2005-04-05 Nortel Networks Limited Transmission control protocol handoff notification system and method
US6704571B1 (en) * 2000-10-17 2004-03-09 Cisco Technology, Inc. Reducing data loss during cell handoffs
US6975591B1 (en) * 2000-11-22 2005-12-13 International Business Machines Corporation Methodology for improving TCP throughput over lossy communication links
US20030016655A1 (en) * 2001-01-29 2003-01-23 Docomo Communications Laboratories Usa, Inc. Fast dynamic route establishment in wireless, mobile access digital networks using mobility prediction
US7187666B1 (en) * 2001-03-30 2007-03-06 Ipr Licensing, Inc. Employing simulated acknowledgment signals for efficient handoffs in cellular packet networks
US20030219034A1 (en) * 2002-02-19 2003-11-27 Lotter Michiel Petrus Method and apparatus optimizing a radio link

Cited By (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040240413A1 (en) * 2003-05-29 2004-12-02 Kil-Lyeon Kim Method and system for controlling packet transmission using bind update message upon handoff of mobile node in IPv6 based wireless network
US20080043621A1 (en) * 2004-01-08 2008-02-21 Hicham Hatime Systems and Methods for Improving Network Performance
US7895648B1 (en) * 2004-03-01 2011-02-22 Cisco Technology, Inc. Reliably continuing a secure connection when the address of a machine at one end of the connection changes
US20050228896A1 (en) * 2004-04-07 2005-10-13 Sony Corporation And Sony Electronics, Inc. TCP congestion control based on bandwidth estimation techniques
US7925775B2 (en) * 2004-04-07 2011-04-12 Sony Corporation TCP congestion control based on bandwidth estimation techniques
US7529207B2 (en) * 2004-12-21 2009-05-05 International Business Machines Corporation Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
US20060133316A1 (en) * 2004-12-21 2006-06-22 Jagana Venkata R Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
US7843871B2 (en) * 2004-12-21 2010-11-30 International Business Machines Corporation Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
US20070147304A1 (en) * 2004-12-21 2007-06-28 Jagana Venkata R Method of Reestablishing Communication by a Mobile Node upon Recovery from an Abrupt Shut Down
US20090185537A1 (en) * 2004-12-21 2009-07-23 International Business Machines Corporation Reestablishing Communication By A Mobile Node Upon Recovery From An Abrupt Shut Down
US7920513B2 (en) * 2004-12-21 2011-04-05 International Business Machines Corporation Reestablishing communication by a mobile node upon recovery from an abrupt shut down
US8219708B2 (en) * 2005-09-19 2012-07-10 Panasonic Corporation Enabling simultaneous use of home network and foreign network by a multihomed mobile node
US8606963B2 (en) * 2005-09-19 2013-12-10 Panasonic Corporation Enabling simultaneous use of home network and foreign network by a multihomed mobile node
US8429294B2 (en) 2005-09-19 2013-04-23 Panasonic Corporation Enabling simultaneous use of home network and foreign network by a multihomed mobile node
US20110153792A1 (en) * 2005-09-19 2011-06-23 Panasonic Corporation Enabling simultaneous use of home network and foreign network by a multihomed mobile node
US20130225163A1 (en) * 2005-09-19 2013-08-29 Panasonic Corporation Enabling simultaneous use of home network and foreign network by a multihomed mobile node
US7881200B2 (en) * 2005-09-23 2011-02-01 Samsung Electronics Co., Ltd. Method of controlling transmission rate and communication device using the same
US20070070892A1 (en) * 2005-09-23 2007-03-29 Samsung Electronics Co., Ltd. Method of controlling transmission rate and communication device using the same
US7899456B2 (en) 2005-12-16 2011-03-01 International Business Machines Corporation Method for faster mobility handoff of a mobile node
JP2009519645A (en) * 2005-12-16 2009-05-14 インターナショナル・ビジネス・マシーンズ・コーポレーション Method for fast mobile handoff of mobile nodes
KR101039227B1 (en) 2005-12-16 2011-06-03 인터내셔널 비지네스 머신즈 코포레이션 Method for faster mobility handoff of a mobile node
US20070140170A1 (en) * 2005-12-16 2007-06-21 Jagana Venkata R Method for faster mobility handoff of a mobile node
WO2007068626A1 (en) 2005-12-16 2007-06-21 International Business Machines Corporation Method for faster mobility handoff of a mobile node
US20110009158A1 (en) * 2006-05-13 2011-01-13 Lg Electronics Inc. Method of executing handover in a mobile communication system
US8538432B2 (en) 2006-05-13 2013-09-17 Lg Electronics Inc. Method of executing handover in a mobile communication system
US8116279B2 (en) * 2006-09-29 2012-02-14 Samsung Electronics Co., Ltd. Mobile communication terminal supporting multi-modal communications and method for providing seamless service upon handover to the mobile communication terminal
US8547936B2 (en) 2006-09-29 2013-10-01 Samsung Electronics Co., Ltd. Mobile communication terminal supporting multi-modal communications and methods for providing seamless service upon handover to the mobile communication terminal
US20080080426A1 (en) * 2006-09-29 2008-04-03 Samsung Electronics Co., Ltd. Mobile terminal and method for providing seamless service upon handover
US20100011270A1 (en) * 2006-10-05 2010-01-14 Ntt Docomo, Inc Communication system, communication device, and communication method
US8418016B2 (en) * 2006-10-05 2013-04-09 Ntt Docomo, Inc. Communication system, communication device, and communication method
WO2008048071A3 (en) * 2006-10-19 2009-09-03 Lg Electronics Inc. Methods of executing handover in a mobile communication system
WO2008048071A2 (en) * 2006-10-19 2008-04-24 Lg Electronics Inc. Methods of executing handover in a mobile communication system
US20080137629A1 (en) * 2006-12-08 2008-06-12 Electronics And Telecommunications Research Institute Communication method for using bandwidth efficiently in internet protocol version 6
US7933241B2 (en) 2006-12-08 2011-04-26 Electronics And Telecommunications Research Institute Communication method for using bandwidth efficiently in internet protocol version 6
US8432806B2 (en) * 2007-08-26 2013-04-30 Huawei Technologies Co., Ltd. Data transmission control method and data transmission device
US20100103880A1 (en) * 2007-08-26 2010-04-29 Huawei Technologies Co., Ltd. Data transmission control method and data transmission device
US20110239073A1 (en) * 2008-12-05 2011-09-29 Ntt Docomo, Inc. Communication device and communication method
US8607114B2 (en) * 2008-12-05 2013-12-10 Ntt Docomo, Inc. Communication device and communication method
US9277478B2 (en) * 2009-11-20 2016-03-01 Telefonaktiebolaget Lm Ericsson (Publ) System, method and devices for enabling efficient hybrid route optimization between two mobile endpoints
US20130155958A1 (en) * 2009-11-20 2013-06-20 Telefonaktiebolaget L M Ericsson (Publ) System, method and devices for enabling efficient hybrid route optimization between two mobile endpoints
US20110158253A1 (en) * 2009-12-25 2011-06-30 Cisco Technology, Inc., A Corporation Of California Increasing Transmission Rate to a Remote Device In Response to Attributing Information Loss as Not Being a Result of Network Congestion
US9300589B2 (en) 2009-12-25 2016-03-29 Cisco Technology, Inc. Increasing transmission rate to a remote device in response to attributing information loss as not being a result of network congestion
US8625622B2 (en) * 2009-12-25 2014-01-07 Cisco Technology, Inc. Increasing transmission rate to a remote device in response to attributing information loss as not being a result of network congestion
US20110216648A1 (en) * 2010-03-05 2011-09-08 Microsoft Corporation Congestion control for delay sensitive applications
US8738986B2 (en) 2010-03-05 2014-05-27 Microsoft Corporation Remote presentation over lossy transport with forward error correction
US20110219287A1 (en) * 2010-03-05 2011-09-08 Microsoft Corporation Remote presentation over lossy transport with forward error correction
US9485184B2 (en) 2010-03-05 2016-11-01 Microsoft Technology Licensing, Llc Congestion control for delay sensitive applications
US8553540B2 (en) 2010-03-05 2013-10-08 Microsoft Corporation Congestion control for delay sensitive applications
US20140181140A1 (en) * 2010-11-15 2014-06-26 Samsung Electronics Co., Ltd. Terminal device based on content name, and method for routing based on content name
US20120195287A1 (en) * 2011-01-28 2012-08-02 Industry-Academic Cooperation Foundation, Yonsei University Communication method using duplicated acknowledgement
US10791202B2 (en) * 2012-05-30 2020-09-29 Canon Kabushiki Kaisha Information processing apparatus, program, and control method for determining priority of logical channel
US20150120882A1 (en) * 2012-05-30 2015-04-30 Canon Kabushiki Kaisha Information processing apparatus, program, and control method
US20140304425A1 (en) * 2013-04-06 2014-10-09 Citrix Systems, Inc. Systems and methods for tcp westwood hybrid approach
US9118569B2 (en) * 2013-04-06 2015-08-25 Citrix System, Inc. Systems and methods for TCP Westwood hybrid approach
US20150029863A1 (en) * 2013-07-23 2015-01-29 Cisco Technology, Inc. Network Congestion Control with Awareness of Random Packet Losses
US9485186B2 (en) * 2013-07-23 2016-11-01 Cisco Technology, Inc. Network congestion control with awareness of random packet losses
US10997568B2 (en) * 2014-12-18 2021-05-04 Ipco 2012 Limited System, method and computer program product for receiving electronic messages
US10708213B2 (en) 2014-12-18 2020-07-07 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US10963882B2 (en) 2014-12-18 2021-03-30 Ipco 2012 Limited System and server for receiving transaction requests
US10999235B2 (en) 2014-12-18 2021-05-04 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US20170344960A1 (en) * 2014-12-18 2017-11-30 Ipco 2012 Limited A System, Method and Computer Program Product for Receiving Electronic Messages
US11080690B2 (en) 2014-12-18 2021-08-03 Ipco 2012 Limited Device, system, method and computer program product for processing electronic transaction requests
US11521212B2 (en) 2014-12-18 2022-12-06 Ipco 2012 Limited System and server for receiving transaction requests
US11665124B2 (en) 2014-12-18 2023-05-30 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US10320686B2 (en) * 2016-12-07 2019-06-11 Cisco Technology, Inc. Load balancing eligible packets in response to a policing drop decision
US20180159779A1 (en) * 2016-12-07 2018-06-07 Cisco Technology, Inc. Load Balancing Eligible Packets in Response to a Policing Drop Decision
US20230308397A1 (en) * 2022-03-25 2023-09-28 Sandvine Corporation System and method for calibration of traffic flow acceleration

Also Published As

Publication number Publication date
DE60333182D1 (en) 2010-08-12
ATE472888T1 (en) 2010-07-15
AU2002253437A8 (en) 2008-02-28
WO2003088622A1 (en) 2003-10-23
WO2003088622A8 (en) 2004-11-04
WO2003088609A2 (en) 2003-10-23
AU2003226578A1 (en) 2003-10-27
EP1495623A1 (en) 2005-01-12
EP1495623B1 (en) 2010-06-30
WO2003088609A3 (en) 2008-01-03
AU2002253437A1 (en) 2003-10-27

Similar Documents

Publication Publication Date Title
EP1495623B1 (en) System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network
US7706269B2 (en) Method, system and device for controlling a transmission window size
US6876639B1 (en) Transmission control protocol handoff notification system and method
US7710921B2 (en) Transmitted packet replenishment system and transmitted packet replenishing method
US7277390B2 (en) TCP processing apparatus of base transceiver subsystem in wired/wireless integrated network and method thereof
US7710905B2 (en) Link latency determination for optimal mobile IP re-registration
US20120195287A1 (en) Communication method using duplicated acknowledgement
EP1278348A1 (en) Long-lived TCP connection using ICMP messages in wireless mobile communications
Eom et al. Improving TCP handoff performance in Mobile IP based networks
KR100534610B1 (en) method and system for controlling packet transmission using bind update message when mobile node performs hand-off in IPv6 based wireless network
Sardar et al. A novel enhancement of TCP for on-board IP networks with wireless cellular connectivity
Wang et al. A fast adaptive congestion control scheme for improving TCP performance during soft vertical handoff
Chou et al. Smooth handoff with enhanced packet buffering-and-forwarding in wireless/mobile networks
Daniel et al. Employing cross-layer assisted TCP algorithms to improve TCP performance with vertical handoffs
Daniel et al. Using cross-layer information to improve TCP performance with vertical handoffs
Mondal Improving performance of TCP over mobile wireless networks
Shamakumar et al. TCP for Wireless Networks
Le et al. A cross-layer approach for improving TCP performance in mobile environments
Onoe et al. A dynamic delayed ACK control scheme on MobileIP networks
KR20110013817A (en) Method of tcp congestion and error control for vertical handover
Aaron et al. Techniques to improve TCP over wireless links
Bonde et al. Wi-TCP: A TCP in Wireless Environment
Lee et al. TCP performance enhancement incorporating handoff analysis in mobile IPv6 networks
Le et al. Wlc47-6: Tcp performance improvement through inter-layer enhancement with mobile ipv6
Chandra et al. A Transport Protocol for Future Wireless Internets

Legal Events

Date Code Title Description
AS Assignment

Owner name: NOKIA CORPORATION, FINLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ZHANG, DONGMEI;ZHANG, RUNTONG;KAN, ZHIGANG;AND OTHERS;REEL/FRAME:016354/0298;SIGNING DATES FROM 20041109 TO 20041110

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION