EP1119954A2 - Method and system for data communication - Google Patents

Method and system for data communication

Info

Publication number
EP1119954A2
EP1119954A2 EP99946532A EP99946532A EP1119954A2 EP 1119954 A2 EP1119954 A2 EP 1119954A2 EP 99946532 A EP99946532 A EP 99946532A EP 99946532 A EP99946532 A EP 99946532A EP 1119954 A2 EP1119954 A2 EP 1119954A2
Authority
EP
European Patent Office
Prior art keywords
host
data packets
network entity
receiving
sending
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.)
Withdrawn
Application number
EP99946532A
Other languages
German (de)
English (en)
French (fr)
Inventor
Jan Kullander
Christofer Kanljung
Anders Svensson
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP1119954A2 publication Critical patent/EP1119954A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/22Traffic shaping
    • H04L47/225Determination of shaping rate, e.g. using a moving window
    • 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/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/267Flow control; Congestion control using explicit feedback to the source, e.g. choke packets sent by the destination endpoint
    • 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/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
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Definitions

  • the present invention relates generally to data communication between computers. More particularly the invention relates to the problem of efficiently communicating data packets over a network including both a sub-network, which is substantially error-immune and has a low latency, and an access link, which is comparatively error-prone and has a substantial latency.
  • TCP Transmission Control Protocol
  • TCP Transmission Control Protocol
  • This protocol is optimised for wired connections, which, have a high transmission quality and a low latency.
  • TCP is not very efficient for transmitting data over links that are error prone, have long delays and/or a high latency.
  • Wireless links constitute typical examples of such non-optimal links.
  • Mobile communication typically imposes a wireless link.
  • two computers, of which at least one is mobile cannot communicate efficiently via a standard TCP- connection, since the transmission algorithms in TCP postulate a much higher link quality than what a wireless connection normally can offer. Therefore, the comparatively poor quality of the wireless connection, in most cases, severely degenerates the performance of the connection. This is particularly true if the wireless link is a high-speed link with a considerable latency.
  • the protocol prescribes that a piece of information indicating the status of received data packets must be fed back from the receiving host to the sending host.
  • a simple positive acknowledgement protocol awaits an acknowledgement for each particular data packet before sending another data packet.
  • An example of a more efficient protocol is the so-called sliding window protocol.
  • Figure 1 illustrates a known method of using a sliding window protocol to make it possible for a sending host to transmit multiple data packets DPI - DP3 before obtaining feed-back information Ackl - Ack3 on the status of the transmitted data packets from a receiving host.
  • the sending host is represented to the left and the receiving host to the right.
  • a time scale is symbolised vertically, with increasing time downwards.
  • a congestion_window has the size W of three data packets. This means that three data packets DPI - DP3 may leave the sending host before a first status message Ackl from the receiving host arrives. Once such a message Ackl has come, the congestion_window slides one data packet and a fourth data packet DP4 may be sent.
  • each data packet is associated with a retransmission timer.
  • the retransmission timer is started when a data packet leaves the sending host. At the expiry of the retransmission timer the sending host retransmits the data packet.
  • the protocol may also be defined such that the receiving host returns a negative acknowledgement message for a data packet, if the data packet has been received, however incorrectly.
  • the data packet is, of course, retransmitted also when such a negative acknowledgement message arrives at the sending host.
  • a data packet will be retransmitted either at reception of a negative acknowledgement message or when the retransmission timer expires, whichever happens first.
  • the procedure is then repeated for all data packets in the message until the sending host has obtained positive acknowledgement messages for each data packet in the message.
  • the size W of the congestion_window thus corresponds to the number of data packets that may be sent out unacknowledged into the network between the sending and the receiving host.
  • the sending host can thus transmit data packets as fast as the network can transfer them. Consequently, a well-tuned sliding window protocol keeps the network completely saturated with data packets and obtains substantially higher throughput than a simple positive acknowledgement protocol (which is also known under the name stop-and-wait protocol) .
  • Slow Start the congestion_window is gradually increased as described above.
  • Slow Start is applied whenever a new connection is set up or when packet loss has been detected by the retransmission timer, e.g. after a period of congestion.
  • the congestion_window is initially set to one data packet.
  • the congestion_window is then increased to two data packets at reception of the first acknowledgement message.
  • the sending host then sends two more data packets and awaits the corresponding acknowledgement messages. When those arrive they each increase the congestion_window by one, so that four data packets may be sent unacknowledged, and so on.
  • Slow Start may sometimes be a misnomer, because under ideal conditions, the transmission rate is ramped up exponentially.
  • the receiving host always has a window limit, a so-called advertised_window, which ultimately restricts the transmission rate. Once this limit has been reached the congestion_window cannot be increased any further.
  • TCP includes one additional restriction.
  • a third window is applied for this purpose.
  • the size of the allowed_window is determined by the following expression:
  • allowed_window min (advertised_window, congestion_window) .
  • the congestion_window in its turn is set according to the following strategy.
  • the congestion_window and the advertised_window are of equal size.
  • the congestion_window is reduced by half (down to a minimum of one data packet) upon loss of data packets. For those data packets that remain in the allowed_window, the retransmission time is reduced exponentially.
  • the advertised_window will be increased until a packet is lost due to congestion.
  • the congestion_window will then be reduced radically to decrease the total load on the network. After that, the congestion_window will once more be increased until a data packet loss occurs and so on. In this case, a steady state will never be reached.
  • Congestion Avoidance is a second algorithm included in TCP, which is applied after Slow Start .
  • the congestion_window is increased until either (i) a steady state is reached or (ii) a data packet is lost.
  • the communicating hosts may be informed of the loss of a data packet in one of two alternative ways. Either because a retransmission timer expires or because a third algorithm called Fast Retransmi t is activated. This algorithm will be described after discussing the different methods applied upon data packet loss detection. If a data packet loss is discovered through expiration of a retransmission timer, the congestion_window is immediately reduced to one data packet.
  • the congestion_window is thereafter increased under the Slow Start algorithm until it reaches one half of the size it had before the retransmission timer expired. Then, the Congestion Avoidance algorithm is _ activated. During Congestion Avoidance the congestion_window is increased by one data packet only when all the packets in one window have been positively acknowledged.
  • the congestion_window is instantaneously decreased to half the size it had before the data packet was lost.
  • the Congestion Avoidance algorithm is then activated and applied as described above.
  • the Fast Retransmi t algorithm will be illustrated by means of an example.
  • a sending host transmits 10 data packets to a receiving host. All these data packets arrive correctly.
  • the receiving host returns a positive acknowledgement message for data packet number 10 to the sending host.
  • This message indicates to the sending host that all 10 data packets have been received correctly.
  • the sending host transmits data packet number 11. This data packet is however lost somewhere in the network. Later, the sending host transmits data packet number 12, which reaches the receiving host correctly. Since the positive acknowledgement messages are cumulative, the receiving host cannot now return a positive acknowledgement message for data packet number 12. Instead, another positive acknowledgement message for data packet number 10 is sent.
  • the sending host transmits data packet number 13. This data packet also reaches the receiving host correctly.
  • the receiving host feeds back yet another positive acknowledgement message for data packet number 10.
  • the sending host thus has received a third positive acknowledgement message for the 10th data packet, this is interpreted as a loss of data packet number 11.
  • This data packet is therefore retransmitted and if it reaches the receiving host correctly, a positive acknowledgement message for data packet number 13 will be returned.
  • a general and more detailed description of the Fast Retransmit algorithm can be found in W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", Internet RFC 2001, Network Working Group, NOAO, January 1997.
  • FACK Forward Acknowledgement
  • TCP Transmission Control Protocol
  • Snoop is a protocol that improves TCP in wireless networks.
  • the protocol modifies network-layer software mainly at a base station, while preserving the end- to-end TCP semantics.
  • the general idea of the protocol is to cache data packets at the base station and perform local retransmissions across the wireless link.
  • S. Biaz et al "TCP over Wireless Networks Using Multiple Acknowledgements", Department of Computer Science at Texas A&M University, Technical Report 97-001, January 1997.
  • Unnecessary retransmissions are here avoided in the network by feeding back a partial acknowledgement for a data packet that has reached the base station, if it experiences difficulties on the wireless link.
  • the base station is responsible for retransmissions on the wireless link, while it delays timeout of the retransmission timer via the partial acknowledgement.
  • the Slow Start-, the Congestion Avoidance-, the Fast Retransmit- and the Fast .Recovery-algorithms are all applied in most modern implementations of TCP.
  • the FACK- and the Snoop algorithms are still not very frequently used.
  • the patent document EP, A2, 0 695 053 discloses an asymmetric protocol for wireless data communications with mobile terminals, according to which the terminals only transmit acknowledgement messages and requests for retransmission upon inquiry or when all data packets within a data block have been received.
  • base stations store channel information for the wireless links and status information of received and transmitted data packets.
  • a base station may also combine acknowledgements for multiple data packets into a single acknowledgement code, in order to reduce the power consumption in the mobile terminals.
  • wireless connections cause longer round- trip delays than wired connections.
  • the transmission rate increase for a wireless connection must, according to the prior art transport protocols, be much slower than for a corresponding wired connection. This is particularly true for wireless connections where the bandwidth-delay product is comparatively high.
  • the prior art protocols always seek to increase the throughput of a connection as far as the interconnecting networks permit.
  • the possible transmission rate increase for a particular connection is inversely correlated to the round- trip delay for the connection.
  • the shorter the round- trip delay the faster the increase rate.
  • the combination of characteristics typical for a wireless connection of high bandwidth-delay product and long round-trip delay consequently also constitutes a problem.
  • the present invention relates generally to data communication between host computers, and more particularly to the problems discussed above.
  • the means of solving these problems according the present invention are summarised below.
  • Another object of the invention is to minimise the influence of data packet losses in relatively error-prone access links, in a substantially less error-prone network.
  • One further object of the present invention is to increase the efficiency of the less error-prone links of a data communication system, and thereby admit transmission of a larger amount of data through the total system.
  • the proposed method for communicating data packets over a packet switched network via at least one wireless access link includes the following assumptions and steps.
  • the packet switched network is presumed to offer a connectionless delivery of data packets.
  • the protocol used by the sending host and the receiving host is a reliable sliding window transport protocol, through which data packets, whenever necessary, may be retransmitted from the sending to the receiving host.
  • the communicating hosts also take measures to protect the packet switched network from congestion.
  • the receiving host generates status messages indicating the condition of received data packets to the sending host. In response to the status messages the sending host takes appropriate data flow control measures.
  • a buffering network entity interfaces both the wireless access link and the packet switched network. During communication of data packets the buffering network entity performs the following steps. First, receiving data packets from the sending host.
  • a method of communicating data packets between two hosts according to the invention is hereby characterised by what is apparent from claim 1.
  • a proposed system includes a buffering network entity, which interfaces both a wireless access link and a packet switched network and thus directly or indirectly brings a sending host in contact with a receiving host.
  • the sending and the receiving hosts are assumed to operate according to a reliable sliding window transport protocol through which lost or erroneously received data packets may be retransmitted from the sending host to the receiving host.
  • the packet switched network is further assumed to offer a connectionless delivery of data packets.
  • the buffering network entity includes a receiving means for receiving data packets. This means also generates and returns to the sending host a first status message, which (i) indicates whether a particular data packet must be retransmitted or not and (ii) indicates whether a data packet has been lost or erroneously received in the packet switched network.
  • the buffering network entity also includes a means for storing correctly received data packets and a means for retrieving the stored data packets and transmitting them to the receiving host. Moreover, the buffering network entity includes a processing means for receiving the first status message from the receiving means and for receiving a second status message from the receiving host. The processing means generates a third status message in response to the first and second status messages and returns the third status message to the sending host.
  • the stored data packets are retransmitted to the receiving host whenever that proves to be necessary. Typically, such retransmission is initiated after the expiry of a retransmission timer or at reception of an explicit or implicit notification of loss.
  • the present invention thus prevents congestion control algorithms from being activated in a substantially error- immune network when data packets are lost in thereto connected and comparatively error-prone access links for other reasons than congestion. This of course, increases the efficiency not only in the substantially error-immune network per se, but also in systems, which include both substantially error-immune links and comparatively error-prone access links.
  • Figure 1 illustrates the known method of using a sliding window protocol being described above
  • Figure 2 illustrates the general method according to the invention by means of a sequence diagram
  • Figure 3 depicts a block diagram over a proposed system
  • Figures 4a-d illustrate embodiments of the proposed method for communicating data packets and generating status information
  • Figure 5 shows a flow diagram over an embodiment of the proposed method being performed by a buffering network entity
  • Figure 6 depicts a block diagram over a system according to the invention.
  • a sequence diagram in figure 2 gives a general illustration of the method according to the invention.
  • a sending host is here represented to the left in the diagram and a receiving host is represented to the right.
  • the part of the connection between the sending host and a buffering network entity IWU is referred to as a first leg A and the part of the connection between the buffering network entity and the receiving host is identified as a second leg B.
  • a time scale is symbolised vertically, with increasing time downwards. Data packets DPn up to a number n are assumed to have reached the receiving host correctly.
  • the receiving host therefore returns a positive acknowledgement message Ack n indicating this to the buffering network entity IWU.
  • the buffering network entity IWU receives the positive acknowledgement message Ack n.
  • a data packet DPm with number m arrives correctly at the buffering network entity IWU a few moments later.
  • the buffering network entity IWU subsequently feeds back to the sending host a first status information message S (A n , B n ) indicating that the receiving host has received all data packets DPn up to number n correctly, i.e. no errors or losses have occurred for any of those n data packets, neither in the first leg A nor the second leg B.
  • the buffering network entity IWU may also, simultaneously with this or at any other time after reception of the data packet DPm, send back a second status information message Ack m, which indicates to the sending host that all data packets DPm up to number m have reached the buffering network entity IWU successfully.
  • the first and second data packet status information messages S (A n , B n ) ; Ack m are preferably effectuated according to a selective acknowledgement algorithm, such as SACK.
  • SACK selective acknowledgement algorithm
  • the buffering network entity IWU feeds back data packet status information messages indicating this fact to the sending host.
  • the buffering network entity IWU could already have fed back a positive acknowledgement message Ack+, through which correct reception of the data packet at the buffering network entity IWU was announced.
  • a block diagram over a proposed system is depicted in figure 3.
  • a first mobile host 305 is here connected to a first base station 315 via a first access link 310.
  • the access link 310 is typically constituted by one or more wireless radio links in a cellular system. However, it may be an arbitrary kind of connection, which is suitable for the specific application.
  • the access link 310 may, for instance, be a satellite link, an optical link, a sonic link or a hydrophonic link.
  • the first base station 315 is further connected to a first buffering network entity 320, generally termed IWU (InterWorking Unit) .
  • IWU InterWorking Unit
  • the first base station 315 can either be separated from the first buffering network entity 320 (as shown in the figure 3) or be co-located with it, whichever is technically and/or economically the most appropriate.
  • the first buffering network entity 320 also interfaces a packet switched network 325.
  • the packet switched network 325 is presupposed to offer a connectionless delivery of data packets on a best-effort basis. This means briefly, that every data packet that is technically feasible to deliver will be delivered as soon as possible.
  • the Internet is a well-known example where many networks together provide a connectionless, best-effort datagram delivery. Further details as to the definition of the best-effort datagram can be found in the Internet RFC 1504.
  • At least one fixed host 330, at least one second buffering network entity 335 and a third base station 365 may be connected to the packet switched network 325.
  • the second buffering network entity 335 interfaces a second base station 340 and a second mobile host 350 via a second access link 345 in a manner corresponding to what has been described in connection with the first buffering network entity 320 above.
  • the third base station 365 which communicates with a third mobile host 355 over a third access link 360, may either be directly connected to the packet switched network 325 or be connected via a unit, which is not a buffering network entity.
  • a sending host may be arbitrary host 305, 330, 350; 355 and receiving host(s) may be one or more of the other hosts 305, 330, 350; 355.
  • the reliable sliding window transport protocol used by the sending and the receiving hosts is of a TCP-type (specified in the Internet RFC793) or of a type specified in the standard document ISO8073. Yet, any alternative sliding window transport protocol is naturally workable.
  • the sending host 310, 330, 350; 355 is notified of a data packet status for each of its transmitted data packets via a specific status message fed back from the buffering network unit 320; 335.
  • the status message (which e.g. may be TCP acknowledgement) is generated at the buffering network unit being closest to the sending host, i.e. the buffering network unit 320 or 335 respectively.
  • the first mobile host 305 sends data packets the first buffering network unit 320 generates the status information.
  • the fixed host 330 sends data packets to one of the mobile hosts 305 or 350 either the first 320 or the second 335 buffering network unit generates the status information depending on which host 305 or 350 is the receiving host.
  • the fixed host 330 should send data packets to the third mobile host 355, no such status information would be generated.
  • the buffering network unit 335 When the host 350 sends data packets the buffering network unit 335 generates the status information. If the mobile host 355 sends data packets the status information in question will only be generated if the receiving host is connected to the packet switched network 325 via a buffering network unit such as 320 or 335.
  • the data packet status information may e.g. be communicated to the sending host according to a selective acknowledgement algorithm (SACK) or according to a so-called TP4 algorithm. Further description of the TP4 algorithm can be found in the standard specification ISO 8073.
  • the fixed host FH is assumed to be the sending host and the second mobile- host MH2 is assumed to be the receiving host.
  • Data packets DP thus pass from the fixed host FH through the packet switched network to the second buffering network entity IWU2.
  • This part of the connection will be referred to as a first leg B.
  • the second buffering network entity IWU2 then forwards the data packets DP to the second mobile host MH2 via the second base station and the second access link.
  • This part of the connection will be referred to as a second leg C.
  • the second buffering network entity IWU2 here functions as the end receiver of the data packets DP from the packet switched network's point-of-view. This means that once a data packet DP has succeeded in reaching the second buffering network entity IWU2 correctly it will not be retransmitted from the fixed host FH.
  • a data packet DP is lost on the second access link between the second base station and the second mobile host MH2, that data packet DP will be retransmitted from the second buffering network entity IWU2 until the data packet DP has been received correctly at the second mobile host MH2.
  • a first part of the status message S(B, C) here corresponding to the first leg B, indicates if a data packet DP has been lost or degenerated in the packet switched network.
  • a second part of the status message S(B, C) here corresponding to the second leg C, indicates if a data packet DP has been lost or degenerated over the second access link.
  • the data packet rate from the fixed host FH will be reduced via at least one data flow control algorithm, otherwise not.
  • the first mobile host MH1 is the sending host and the fixed host FH is the receiving host.
  • Data packets DP hence leave the first mobile host MH1 over the first access link and pass via the first base station to the first buffering network entity IWU1.
  • This part of the connection will be referred to as a first leg A.
  • the first buffering network entity IWU1 then forwards the data packets DP to the fixed host FH through the packet switched network, which corresponds to a second leg B of the connection.
  • Such degenerated or lost packets DP must naturally be retransmitted from the first mobile host MH1 to the first buffering network entity IWU1.
  • the first buffering network entity IWU1 may also have to retransmit data packets DP to the fixed host FH. This is the case when, for instance, congestion in the packet switched network has caused the retransmission timer to expire.
  • a status message S (A, B) related to each data packet DP is generated in the first buffering network entity IWU1 and returned to the first mobile host MHl.
  • a first part of the status message S (A, B) here corresponding to the second leg B indicates if a data packet DP has been lost or degenerated in the packet switched network, while a second part, here corresponding to the first leg A, indicates if a data packet DP has been lost or degenerated in over the first access link.
  • the data packet rate from the first mobile host MHl will be reduced via at least one data flow control algorithm. The loss or degradation of a data packet DP over the first access link will, however, not influence the data packet rate from the first mobile host MHl in this way.
  • the first mobile host MHl is the sending host and the second mobile host MH2 is the receiving host.
  • the first mobile host MHl now transmits data packets DP over the first access link, via the first base station to the first buffering network entity IWU1.
  • This part of the connection will be referred to as a first leg A.
  • the first buffering network entity IWU1 subsequently passes the data packets DP via the packet switched network to the second buffering network entity IWU2.
  • This part of the connection will be referred to as a second leg B.
  • the second buffering network entity IWU2 sends the data packets DP to the second mobile host MH2 through the second base station and the second access link.
  • This last part of the connection constitutes a third leg C.
  • data packets DP may, if necessary, be retransmitted over any of the legs A, B and C respectively.
  • a data packet DP can either be retransmitted from the first mobile host MHl to the first buffering network entity IWU1, from the first buffering network entity IWU1 to the second buffering network entity IWU2 or from the second buffering network entity IWU2 to the second mobile host MH2. Regardless of what caused the loss or degrading of a particular data packet DP, retransmission of the data packet will always only be performed over the leg A, B; C where the data packet DP was either lost or degenerated.
  • Status messages S (A, B) ; S(B, C) indicating the status of each communicated data packet DP are generated in both the buffering network entities IWU1; IWU2.
  • the status messages S (A, B) ; S(B, C) indicate in which leg A, B; C a loss or degrading of a particular data packet DP has occurred. If the status messages S (A, B) ; S(B, C) announce that a data packet DP has been lost or degenerated in the packet switched network, here leg B, at least one data flow control algorithm will be triggered.
  • the data packet rate from the first mobile host MHl will, as a result of such an algorithm, be decreased.
  • a loss or degradation of a data packet DP in any of the other legs A or C will, on the other hand, not lead to a reduction of the data transmission rate from the first mobile host MHl.
  • the first mobile host MHl is here the sending host and the third mobile host MH3 is the receiving host.
  • the first mobile host MHl this time transmits data packets DP over the first access link, via the first base station to the first buffering network entity IWU1.
  • This part of the connection will be referred to as a first leg A.
  • the first buffering network entity IWU1 then passes the data packets DP via the packet switched network to the third mobile host MH3, via the third base station and the third access link.
  • This part of the connection will be referred to as a second leg B.
  • a retransmission of a lost or degenerated data packet DP can here either be carried out over the first leg A or over the second leg B.
  • a status message S (A, B) indicating the status of each communicated data packet DP is generated in the first buffering network entity IWU1 and returned to the first mobile host MHl.
  • the status message thus indicates S (A, B) if a certain data packet DP has been lost or degenerated over the first access link, i.e. leg A, or somewhere between the first buffering network entity IWU1 and the third mobile host MH3, i.e. leg B.
  • Only the loss or degeneration of a data packet DP in leg B will trigger data flow control algorithms and thus decrease the data packet rate from the first mobile host MHl.
  • Such loss or degrading is most likely to depend on poor quality of the third access link between the third base station and the third mobile host MH3, but since this fact is impossible to verify data flow control algorithms will nevertheless be activated.
  • a buffering network entity over a certain period of time receives more data packets via one of its interfaces than what can be delivered over its other interface, the superfluous data packets will be discarded by the buffering network entity.
  • the buffering network entity will then feed back status messages S(X, Y) to the sending host indicating that the superfluous data packets were lost in the packet switched network. This will in its turn trigger at least one data flow control algorithm, which directs the sending host to reduce its data packet rate. The rate will thus be gradually reduced until it meets the transmission capacity of the limiting interface at the buffering network entity.
  • Figure 5 illustrates an embodiment of the inventive method being carried out in a buffering network entity, when data packets are transmitted from a sending host to a receiving host via the buffering network entity.
  • the figure illustrates the possible fate of a particular data packet DP or a certain
  • SUBST ⁇ UTE SHEET (RULE 26) group of data packets DPs when passing through the buffering network entity. It is nevertheless important to bear in mind that since the reliable sliding window transport protocol allows many data packets to be outstanding in the network between the sending and the receiving host, the buffering network unit will at any given moment be carrying out many of the following steps simultaneously and in parallel. The procedure will thus be in different steps with regard to different data packets DPs.
  • a first step 500 the buffering network entity receives one or more data packets DP(s) from the sending host.
  • a following step 505 checks whether the data packet (s) DP(s) is (are) correct. If so, the procedure continues to step 520. Otherwise, a request is made in a step 510 for retransmission of the incorrectly received data packet(s) DP(s).
  • a status message S(X,-) indicating the erroneous reception of the data packet (s) DP(s) is fed back to the sending host in a subsequent step 515. The procedure then returns to step 505 in order to determine whether the retransmitted data packet (s) DP(s) arrive (s) correctly.
  • steps 510 and 515 are most efficiently being carried out as one joint step, where the status message S(X,-) per se is interpreted as a request for retransmission.
  • the steps 510 and 515 may, of course, also be carried out in reverse order or in parallel. Their relative order is nevertheless irrelevant for the result.
  • the buffering network entity in the steps 500 and 505 receives data packets DP(s) in an out-of-sequence order, so that a loss of earlier data packet (s) DP(s) likely to have occurred a retransmission of the assumedly lost data packet (s) is requested in the steps 510 and 515.
  • the step 520 checks whether the connection at the buffering network entity' s output interface has enough bandwidth BW, i.e. can transport data packets DPs at least as fast as data packets DPs arrive to the buffering network entity at the input interface. In case of insufficient bandwidth BW one or more data packets DP(s) are discarded in a step 525. The procedure then returns to the step 510, where retransmission is requested for the discarded data packet (s). If, on the other hand, in the step 520 it is found that the output interface has sufficient bandwidth BW the procedure continues to a step 530.
  • BW bandwidth
  • a status message S(X,-) indicating correct reception of the data packet (s) DP(s) may be fed back to the sending host. If there is a packet switched network between the sending host and the buffering network entity, a status message S(X,-) regarding the result of the transmission is regularly fed back from the buffering network entity to the sending host. If, however, there is no packet switched network between the sending host and the buffering network entity (but e.g. an access link) the step 530 may be empty. Step 530 namely provides information to the sending host, which is necessary to control the data flow from the sending host, and such information need only be communicated if the data packet (s) DP(s) has/have been transmitted over a packet switched network.
  • step 535 the correctly received data packet (s) DP(s) is/are stored in the buffering network entity.
  • a thereafter following step 540 forwards the data packet (s) DP(s) to the receiving host.
  • a step 545 checks whether a status message relating to the sent the data packet (s) DP(s) has been returned from the receiving host. If such a status message reaches the buffering network entity before the expiration of a retransmission timer a step 555 checks whether the status message indicates correct or incorrect reception of the data packet (s) DP(s).
  • a step 550 determines if the retransmission timer has expired, and in case the timer is still running the procedure is looped back to the step 545.
  • step 555 If however, no status message has been received when the retransmission timer expires or if it in step 555 is found that one or more data packets DP(s) have been received incorrectly, the data packet (s) DP(s) in question are retransmitted in a step 560.
  • a following step 565 returns a status message S(X, Y) to the sending host indicating the fact that retransmission of data packet (s) DP(s) was necessary. If there is a packet switched network between the buffering network entity and the receiving host, flow control algorithms triggered by the status message S (X, Y) will cause the sending host to reduce its data flow, otherwise the data flow from the sending host will not be affected.
  • the steps 560 and 565 are carried out reverse order or in parallel. Their relative order is irrelevant for the effect of the steps.
  • the procedure returns to the step 545, which checks whether a status message for the retransmitted data packet (s) DP(s) has been received. As soon as a status message indicating correct reception of the data packet (s) has/have reached the buffering network entity the procedure continues for this/these data packets DP(s) from the step 545, via the step 555, to a final step 570.
  • This final step 570 feeds back a status message S (X, Y) to the sending host, which indicates that the data packet (s) has/have been received correctly by the receiving host.
  • FIG. 6 depicts a block diagram over an arrangement according to the invention.
  • a sending host which may be either fixed or mobile, is here represented by a first general interface 600.
  • a receiving host which likewise may be either fixed or mobile, is correspondingly represented by a second general interface 650.
  • a buffering network entity IWU interfaces both the first and the second interface 600; 650.
  • the buffering network entity IWU in its turn includes a means 610 for receiving data packets DP from the first interface 600, a storage means 620 for storing data packets DP, a means 630 for transmitting data packets DP over the second interface 650 and a processing means 640 for generating status messages S(X, Y) and controlling the over all operation of the entity buffering network IWU in accordance with the method described in connection with figure 5 above.
  • the receiving means 610 Apart from receiving data packets DP the receiving means 610 also determines whether the data packets DP are received correctly and .generates in response to the condition of the received data packets DP a first status message S(X,-).
  • the receiving means 610 may have to discard data packets DP on instruction from the processing means 640. This happens if the processing means has found that the bandwidth / capacity over the interface 600 exceeds the capacity over the interface 650.
  • the discarded data packets DP are regarded as lost data packets.
  • a first status message S(X,-) indicating such a loss is therefore generated and returned after having discarded data packets in the receiving means 610.
  • This first status message S(X,-) is returned to the sending host.
  • the first status message S(X,-) is also forwarded to the processing means 640.
  • the means 610 generates requests for retransmission of data packets DP whenever that becomes necessary.
  • the status message S(X,-) itself may, of course, be interpreted as a requests for retransmission at the sending host.
  • Data packets DP having been received correctly by the means 610 are passed on to the storage means 620 for temporary storage.
  • the means for transmitting 630 retrieves data packets DP from the storage means 620 and sends them over the interface 650 to the receiving host.
  • the receiving host returns a second status message e.g.
  • the processing means 640 receives the second status message Ack ⁇ and generates a third and combined status message S (X, Y) , which is determined from the content of the first status message S(X,-) and the second status message Ack ⁇ .
  • the third status message S(X, Y) thus gives a total representation of how successfully a certain data packet or a certain group of data packets was passed over the respective communication legs before and after the buffering network entity.
  • the third status message S (X, Y) is transmitted from the processing means back to the sending host over the interface 600.
  • a particular data packet DP having been temporarily stored in the storage means 620 may be deleted as soon as a second status message Ack+ has been received for the data packet DP indicating that the data packet has been received correctly by the receiving host.
  • the data packet DP may of course also be deleted at any later, and perhaps more suitable, moment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
EP99946532A 1998-10-07 1999-08-27 Method and system for data communication Withdrawn EP1119954A2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE9803423A SE513327C2 (sv) 1998-10-07 1998-10-07 System och metod för datakommunikation
SE9803423 1998-10-07
PCT/SE1999/001479 WO2000021231A2 (en) 1998-10-07 1999-08-27 Method and system for data communication

Publications (1)

Publication Number Publication Date
EP1119954A2 true EP1119954A2 (en) 2001-08-01

Family

ID=20412869

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99946532A Withdrawn EP1119954A2 (en) 1998-10-07 1999-08-27 Method and system for data communication

Country Status (6)

Country Link
EP (1) EP1119954A2 (ja)
JP (1) JP2002527935A (ja)
AU (1) AU751285B2 (ja)
CA (1) CA2346715A1 (ja)
SE (1) SE513327C2 (ja)
WO (1) WO2000021231A2 (ja)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9929882D0 (en) * 1999-12-18 2000-02-09 Roke Manor Research TCP/IP enhancement for long latency links
GB0018119D0 (en) * 2000-07-24 2000-09-13 Nokia Networks Oy Flow control
JP3377994B2 (ja) 2000-11-14 2003-02-17 三菱電機株式会社 データ配信管理装置およびデータ配信管理方法
GB2375001A (en) * 2001-04-06 2002-10-30 Motorola Inc Re-transmission protocol
WO2003041334A1 (en) 2001-11-07 2003-05-15 Cyneta Networks, Inc. Gb PARAMETER BASED RADIO PRIORITY
WO2003040735A1 (en) 2001-11-07 2003-05-15 Cyneta Networks Inc. Resource aware session adaptation system and method for enhancing network throughput
SE0103853D0 (sv) * 2001-11-15 2001-11-15 Ericsson Telefon Ab L M Method and system of retransmission
WO2003065663A1 (en) * 2002-01-25 2003-08-07 Cyneta Networks, Inc. Packet retransmission in wireless packet data networks
US20050102416A1 (en) * 2002-02-15 2005-05-12 Miller-Smith Richard M. Modifications of tcp/ip
US8533307B2 (en) 2002-07-26 2013-09-10 Robert Bosch Gmbh Method and device for monitoring a data transmission
DE10234348B4 (de) * 2002-07-26 2018-01-04 Robert Bosch Gmbh Verfahren und Vorrichtung zur Überwachung einer Datenübertragung
US7385926B2 (en) 2002-11-25 2008-06-10 Intel Corporation Apparatus to speculatively identify packets for transmission and method therefor
US7693058B2 (en) 2002-12-03 2010-04-06 Hewlett-Packard Development Company, L.P. Method for enhancing transmission quality of streaming media
US20040264368A1 (en) * 2003-06-30 2004-12-30 Nokia Corporation Data transfer optimization in packet data networks
KR101086397B1 (ko) * 2003-12-02 2011-11-23 삼성전자주식회사 Ip 패킷의 에러 처리 장치 및 방법, 그리고 상기 방법을실행하는 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체
EP1681792B1 (de) * 2005-01-17 2013-03-13 Nokia Siemens Networks GmbH & Co. KG Gesicherte Nachrichtenübertragung in einem Multi-Hop System
US7787463B2 (en) * 2006-01-26 2010-08-31 Broadcom Corporation Content aware apparatus and method
US8238242B2 (en) 2006-02-27 2012-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Flow control mechanism using local and global acknowledgements
GB0812770D0 (en) 2008-07-11 2008-08-20 Zbd Displays Ltd A display system
CN101631065B (zh) * 2008-07-16 2012-04-18 华为技术有限公司 一种无线多跳网络拥塞的控制方法和装置
CN107113242A (zh) * 2014-11-06 2017-08-29 诺基亚通信公司 改进通信效率

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0021231A2 *

Also Published As

Publication number Publication date
AU5892999A (en) 2000-04-26
CA2346715A1 (en) 2000-04-13
SE513327C2 (sv) 2000-08-28
JP2002527935A (ja) 2002-08-27
WO2000021231A3 (en) 2000-07-27
WO2000021231A2 (en) 2000-04-13
SE9803423D0 (sv) 1998-10-07
AU751285B2 (en) 2002-08-08
SE9803423L (sv) 2000-04-08

Similar Documents

Publication Publication Date Title
AU751285B2 (en) Method and system for data communication
US7013346B1 (en) Connectionless protocol
US7277390B2 (en) TCP processing apparatus of base transceiver subsystem in wired/wireless integrated network and method thereof
EP1195966B1 (en) Communication method
KR100785293B1 (ko) 다중 tcp확인응답을 이용한 tcp 혼잡 제어 시스템및 그 방법
EP1671424B1 (en) Fec-based reliability control protocols
US20040052234A1 (en) Method and system for dispatching multiple TCP packets from communication systems
US20030023746A1 (en) Method for reliable and efficient support of congestion control in nack-based protocols
EP1708400B1 (en) Loss tolerant transmission control protocol
WO2000055640A1 (en) Dynamic wait acknowledge for network protocol
US8018846B2 (en) Transport control method in wireless communication system
JP2006506866A (ja) データユニット送信機及びこの送信機の制御方法
WO2006027695A1 (en) Signaling a state of a transmission link via a transport control protocol
CN111193577A (zh) 使用传输超时的网络系统通信方法及通信装置
KR100392169B1 (ko) 통신 시스템에서 데이터 패킷을 전달하기 위한 방법 및 장치
WO2018155406A1 (ja) 通信システム、通信装置、方法およびプログラム
EP3939191B1 (en) Device and method for delivering acknowledgment in network transport protocols
KR100913897B1 (ko) 재전송 타임아웃 수를 줄이기 위한 전송 제어 프로토콜혼잡제어방법
JP4531302B2 (ja) パケット中継装置、及びその方法
CN116566920A (zh) 一种数据传输控制方法及相关装置
JP2006237968A (ja) 通信システムおよび通信方法
JP2003198612A (ja) パケット通信ネットワークにおけるファイル転送方法
JPH10200556A (ja) パケット通信システム

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010302

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SVENSSON, ANDERS

Inventor name: KANLJUNG, CHRISTOFER

Inventor name: KULLANDER, JAN

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

RBV Designated contracting states (corrected)

Designated state(s): DE GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20040302