WO2013139165A1 - 确认包的处理方法、设备及系统 - Google Patents

确认包的处理方法、设备及系统 Download PDF

Info

Publication number
WO2013139165A1
WO2013139165A1 PCT/CN2012/087791 CN2012087791W WO2013139165A1 WO 2013139165 A1 WO2013139165 A1 WO 2013139165A1 CN 2012087791 W CN2012087791 W CN 2012087791W WO 2013139165 A1 WO2013139165 A1 WO 2013139165A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
packet
acknowledgement packet
acknowledgement
amount
Prior art date
Application number
PCT/CN2012/087791
Other languages
English (en)
French (fr)
Inventor
童长华
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP12871880.6A priority Critical patent/EP2819360B1/en
Priority to KR1020147029217A priority patent/KR101607583B1/ko
Priority to CN201280070272.8A priority patent/CN104137495B/zh
Priority to JP2015500748A priority patent/JP5928764B2/ja
Publication of WO2013139165A1 publication Critical patent/WO2013139165A1/zh
Priority to US14/491,744 priority patent/US9602410B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements 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/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H04L47/323—Discarding or blocking control packets, e.g. ACK packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method, a device, and a system for processing a confirmation packet. Background technique
  • the Transmission Control Protocol provides a connection-oriented byte stream service.
  • the terminal and the server can send data normally after establishing a connection, and the data transmission using the TCP protocol has a data packet. Confirmation mechanism and retransmission function.
  • the server sends a data packet to the terminal, and the terminal returns an acknowledgement packet to the server after receiving the data packet, and the server transmits the remaining data packet according to the received acknowledgement packet.
  • TCP has gradually been applied to wireless transmission services from traditional wired transmission services.
  • the Transmission Control Protocol/Internet Protocol (TCP/IP) is developed and designed for wired transmission.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • LTE Long Term Evolution
  • the limitation of the wireless communication itself may cause fluctuations in the air interface signal, and the server may not receive the terminal reply within a few milliseconds or hundreds of milliseconds. Confirm the package, and then after the air interface signal fluctuations disappear, the server receives a large number of confirmation packets in a short time. Therefore, the prior art lacks the distinguishing processing manner when the new arrival acknowledgement packet is received, which may cause the server to issue a large number of data packets to the terminal according to the received large number of acknowledgement packets. Similarly, on the uplink data transmission, the same problem occurs when the terminal uploads a data packet to the server. Summary of the invention
  • Embodiments of the present invention provide a method for processing an acknowledgement packet, a data transmission device, and a communication system to solve the technical problem of a large number of bursts of data packets.
  • an embodiment of the present invention provides a method for processing an acknowledgement packet, including: sending an acknowledgement packet; updating a total amount of data confirmed by a data receiving end reflected by all sent acknowledgement packets in a current transmission period; The total data amount and the data amount threshold; according to the comparison result, whether to continue to send the acknowledgement packet within the current transmission period.
  • an embodiment of the present invention provides a data transmission device, including: a receiving circuit, configured to receive an acknowledgement packet; a sending circuit, configured to send an acknowledgement packet; a memory, a data volume threshold; a processor, and the receiving a circuit, a transmitting circuit, and a memory connection, configured to update a total amount of data confirmed by the data receiving end reflected by all sent acknowledgement packets in the current sending period, and compare the updated total data amount with the data amount threshold, according to the comparison As a result, it is controlled whether the transmitting circuit continues to transmit the acknowledgement packet during the current transmission period.
  • an embodiment of the present invention provides a data transmission device, including: a sending unit, configured to send an acknowledgement packet, and an update unit, configured to update, by a data receiving end, that is confirmed by all sent acknowledgement packets in a current sending period.
  • the total data amount; the control unit is configured to compare the updated total data amount with the data amount threshold, and control whether to continue to send the acknowledgement packet in the current transmission period according to the comparison result.
  • the embodiment of the present invention provides a communication system, including a data transmitting end, a data receiving end, and the data transmission device according to the second aspect or the third aspect, wherein the data transmitting end passes the data transmission device Communicate with the data receiver.
  • an embodiment of the present invention provides a computer program product, comprising a computer readable medium, the computer readable medium comprising a set of program code for performing the method as described in the first aspect.
  • the data volume device is used to control the data transmission device to send data to each transmission period.
  • the acknowledgement packet of the sending end meets the total amount of data confirmed by the data receiving end reflected by all the transmitted acknowledgement packets within the data volume threshold, so that the acknowledgement packet received by the data transmitting end in each sending cycle satisfies all the received acknowledgement packets.
  • the total amount of data confirmed by the reflected data receiving end is within the data amount threshold, thereby solving the problem that the data receiving end sends a large number of data packets.
  • FIG. 1 is a flowchart of a method for processing an acknowledgement packet according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method for processing an acknowledgement packet according to another embodiment of the present invention.
  • FIG. 3 is a flowchart of a method for processing an acknowledgement packet according to another embodiment of the present invention.
  • FIG. 4 is a flowchart of a method for processing an acknowledgement packet according to another embodiment of the present invention.
  • FIG. 5 is a flowchart of a method for processing an acknowledgement packet according to another embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of a processing device for confirming a packet according to another embodiment of the present invention
  • FIG. 7 is a schematic structural diagram of a processing device for confirming a packet according to another embodiment of the present invention
  • FIG. 8 is a schematic diagram of data transmission according to Embodiment 1 of the present invention; Schematic diagram of the device;
  • FIG. 9 is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 2 of the present invention
  • FIG. 10 is a schematic flowchart of a method for updating a total data amount according to Embodiment 2 of the present invention
  • FIG. 12 is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 4 of the present invention
  • FIG. 13 is a detailed flowchart of step S122 of a method for processing an acknowledgement packet shown in FIG.
  • FIG. 14 is a schematic flowchart of a step S131 of the method for processing the confirmation packet shown in FIG. 13;
  • FIG. 10 is a schematic flowchart of a method for updating a total data amount according to Embodiment 2 of the present invention
  • FIG. 12 is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 4 of the present invention
  • FIG. 13 is a detailed flowchart of step S122 of a method for processing an acknowledgement packet shown
  • FIG. 15 is a schematic flowchart of a method for processing the confirmation packet according to the fifth embodiment of the present invention.
  • a schematic structural diagram of a data transmission device provided FIG. 17 is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 7 of the present invention
  • FIG. 18 is a schematic structural diagram of a data transmission device according to Embodiment 8 of the present invention.
  • TCP/IP is developed and designed for wired transmission.
  • the fluctuation of the air interface signal may be caused by the limitation of the wireless communication system itself.
  • the server may not receive the acknowledgement packet of the terminal reply within a few milliseconds or hundreds of milliseconds, and then after the air interface signal fluctuation disappears, the server receives a large number of confirmation packets in a short time, causing the server to receive the packet according to the receipt. A large number of confirmation packets and a large number of data packets are sent to the terminal.
  • the same problem occurs when the terminal uploads a data packet to the server.
  • a transmission period and a data amount threshold are set on the data transmission device, so that the data volume threshold is used to control the confirmation packet sent by the data transmission device to the data transmission end in each transmission period to satisfy all the transmission confirmations.
  • the total data amount confirmed by the data receiving end reflected by the packet is within the data volume threshold, so that the acknowledgement packet received by the data transmitting end in each transmission period satisfies the total acknowledged data received by all received acknowledgement packets.
  • the amount of data is within the data volume threshold, thereby solving the problem that the data receiving end sends a large number of data packets.
  • the node device may also be a data transmission device that is disposed on the access network side and is independent of the existing access network device, or is configured to be independent of the existing core network device on the core network side.
  • transmission device may be a base station in various communication systems.
  • BTS Base Transceiver Station
  • eNB Evolutional Node B
  • GSM Global System for Mobile Communications
  • the present invention does not impose any limitation on the base station controller (BSC) or the radio network controller (RNC) in the Universal Mobile Telecommunications System (UMTS).
  • BSC Base Transceiver Station
  • RNC radio network controller
  • the data sending end in the embodiment of the present invention may be a server or a terminal; the corresponding data receiving end may be a terminal or a server.
  • the data transmitting end in the uplink data transmission, the data transmitting end is the terminal and the data receiving end is the server; in the downlink data transmission, the data transmitting end is the server, and the data receiving end is the terminal.
  • the invention is not limited in any way.
  • the acknowledgement packet in the embodiment of the present invention may be an uplink acknowledgement packet or a downlink acknowledgement packet.
  • FIG. 8 is a schematic structural diagram of a data transmission device according to Embodiment 1 of the present invention.
  • the data transmission device 800 includes a receiving circuit 810 , a sending circuit 820 , a memory 830 , and a receiving circuit 810 , respectively.
  • the circuit 820 is coupled to the processor 840 of the memory 830.
  • the receiving circuit 810 is configured to receive the acknowledgement packet; the transmitting circuit 820 is configured to send the acknowledgement packet; the memory 830 stores the data volume threshold; and the processor 840 is configured to update the data receiver that is acknowledged by all the transmitted acknowledgement packets in the current transmission period.
  • the total amount of data controls whether the transmitting circuit 820 continues to transmit the acknowledgement packet during the current transmission period.
  • the data sender sends a large number of data packets, which may result in untimely packet loss and packet loss. For example, the sending capability of the server is usually relatively strong.
  • the data threshold can be set based on the bearer capability of the bearer network.
  • the bearer capability of the bearer network may be the bearer capability of the transport network element between the access network and the core network, for example, the bearer capability of the switch, the router, and the like.
  • the data volume threshold may also be limited by the rate limit of the bearer link, and the bearer link may be a link between the access network and the core network.
  • the data volume threshold may also be limited by the transmission bandwidth of the wireless network where the data transmission device is located. For example, once the processing capability of the data transmitting end or the data receiving end is limited, it may also be determined according to the processing capability of the data transmitting end or the data receiving end, for example, according to the transmission control protocol of the data transmitting end, the TCP sending window or the TCP receiving window of the data receiving end. determine.
  • updating the total amount of data acknowledged by the data receiving end reflected by all sent acknowledgement packets in the current transmission period it may be updated once for each acknowledgement packet, or may be updated every two or more acknowledgement packets sent. It is also possible to divide the transmission period into time slots, the previous time period, and the plurality of confirmation packets are updated once, and one confirmation packet is updated once in the subsequent time period. In addition, the number of confirmation packets separated by the next update can be determined based on the result of the previous update. In view of the simplicity of implementation, one acknowledgement packet may be sent for each update, but the invention does not impose any restrictions.
  • FIG. 9 is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 2 of the present invention. As shown in FIG. 9, the method includes the following steps:
  • S910 Send an acknowledgement packet
  • S940 Control whether to continue to send the total data amount confirmed by the data receiving end of the acknowledgement packet c in the current transmission period according to the comparison result, and compare the updated total data amount with the locally stored data volume threshold, and control the current transmission period according to the comparison result. Whether to continue to send the acknowledgement packet, so that the acknowledgement packet reaching the data sender end in a transmission period is not too much, thereby solving the problem that the data sender sends a large number of data packets.
  • the data sender sends a large number of data packets, which may result in untimely packet loss and packet loss. For example, the sending capability of the server is usually relatively strong.
  • the above total amount of data can be updated based on the confirmation packet number of the confirmation packet.
  • the acknowledgement packet number of the acknowledgement packet is the sequence number of the TCP ACK, and the sequence number of the TCP ACK indicates that the data before the sequence number has been confirmed by the data receiver. Therefore, each time an acknowledge packet is sent, the amount of data confirmed by the data receiving end reflected by the currently transmitted acknowledgement packet can be determined according to the difference between the currently transmitted acknowledgement packet and the sequence number of the previously transmitted acknowledgement packet. In this way, the total amount of data confirmed by the receiving end can be received by the data reflected by each acknowledgement packet.
  • the acknowledgement packet number sent by a certain one is 747337662, which indicates that the data before the 747337662 bytes has been confirmed by the data receiving end; and the confirmation packet number sent after the acknowledgement packet is 747340582, which indicates the 747340582 Bytes before data Have been received.
  • the total amount of data after the update the total amount of data before the update +
  • step S920: updating the total amount of data confirmed by the data receiving end reflected by all the transmitted acknowledgement packets in the current sending period may further include:
  • S101 determining, according to the difference between the acknowledgement packet number of the currently sent acknowledgement packet and the acknowledgement packet sequence number of the previously transmitted acknowledgement packet, the amount of data confirmed by the data receiving end reflected by the currently transmitted acknowledgement packet;
  • S102 Update the total data amount according to the amount of data confirmed by the data receiving end reflected by the currently sent acknowledgement packet.
  • the confirmation packet number of the confirmation packet is usually expressed in the form of n-bit binary. When the number reaches the maximum value that can be expressed, the number will be restarted. This is called the wrap-around phenomenon. When the confirmation packet number of the currently sent acknowledgement packet wraps around, the difference between it and the previous acknowledgement packet will have a negative value. If the update method is updated as described above, a problem will occur. Therefore, when the confirmation packet number of the currently sent acknowledgement packet wraps around, the update may not be performed, that is, the total data amount is kept unchanged. At this time, although the amount of data reflected by one confirmation packet is less calculated, it does not affect the effect of the implementation.
  • the sending of the acknowledgement packet within the current transmission period is stopped, and specifically, the processor 840 controls the sending circuit 820 to stop transmitting the acknowledgement packet within the current transmission period.
  • the acknowledgement packet may continue to be sent in the current transmission period, and may be implemented by the processor 840 controlling the sending circuit 820 to continue to send the acknowledgement packet within the current transmission period.
  • the following describes the processing method when the total amount of data after the update is equal to the data amount threshold.
  • the confirmation packet may be stopped during the current transmission cycle, or the confirmation packet may continue to be transmitted.
  • the processor 840 can control the transmitting circuit 820 to stop transmitting the acknowledgement packet during the current transmission period, and can also control the transmitting circuit 820 to continue transmitting the acknowledgement packet during the current transmission period. This is because the total amount of data confirmed by the data receiving end reflected by the implementation of the present invention is strictly controlled within the data amount threshold, but is controlled to be around the data amount threshold, even if the data amount threshold is exceeded by an acknowledgement packet. The quantity does not have a substantial impact on the effect of the solution.
  • the value including a certain range of the data amount threshold may also be used as a basis for stopping and continuing to transmit the acknowledgement packet. For example, when comparing the updated total data amount and the data amount threshold, it is found that the updated total data amount is close to the data amount threshold, but when it is not reached, the confirmation packet can also be stopped.
  • the present invention compares the updated total data amount with the data amount threshold, and according to the comparison result, the process of controlling whether the transmitting circuit continues to transmit the acknowledgement packet in the current transmission period according to the comparison result is not strictly limited, and only needs to be sent within one transmission period.
  • the total amount of data that has been confirmed by the data receiving end reflected by the data packet of the data transmitting end is controlled by the data amount threshold.
  • the present embodiment may have various implementations, which are exemplified below. However, these examples are not intended to limit the present invention.
  • FIG. 11 is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 3 of the present invention.
  • the execution body of the method is a data transmission device, and the data transmission device prestores a data volume threshold, and uses a transmission sequence number (SendSeq) to represent the total data amount confirmed by the data receiving end reflected by all the transmitted acknowledgement packets in one transmission period.
  • the method includes the following steps:
  • the SendSeq is updated once, and each time the SendSeq is updated, the relationship between the updated SendSeq and the data amount threshold is judged. That is, in the current transmission period, the following steps S111 to S113 are repeatedly performed until the current transmission period ends or The updated SendSeq is greater than the data volume threshold.
  • step S113 Determine the relationship between the updated SendSeq and the data volume threshold. If the updated SendSeq is less than the data amount threshold, then steps S111 to S113 are continued; if the updated SendSeq is greater than the data amount threshold, step S114 is performed.
  • S114 Suspend the transmission of the acknowledgement packet within the current transmission period until the end of the current transmission period, and continue to send the acknowledgement packet after the SendSeq is set to zero in the next transmission cycle.
  • the SendSeq may be determined by confirming the difference between the packet sequence numbers, wherein the acknowledgement packet sequence number is used to indicate that the data before the acknowledgement packet sequence number has been determined by the data receiving end, and the difference between the two acknowledgement packet sequence numbers may be reflected.
  • the determined amount of data corresponding to the currently sent acknowledgement packet is output, and each time an acknowledgement packet is sent, the SendSeq is updated by accumulating the determined amount of data corresponding to the sent acknowledgement packet, and the updated SendSeq can be reflected.
  • the number of acknowledgment packets sent in one transmission period is controlled, so as to solve the problem that the data transmitting end sends a large number of data packets, thereby solving the problem that the data packet transmission is not timely and the packet loss is caused.
  • the acknowledgement packet may be suspended until the end of the current transmission period, and the acknowledgement packet is continuously sent after the transmission sequence number is set to zero in the next transmission period. It is also possible to continue to send the confirmation packet for the same reason as the above embodiment, and details are not described herein again.
  • the updated SendSeq SendSeq + Max (0, the confirmation packet number of the first confirmation packet - the confirmation packet number of the second confirmation packet); wherein Max ( ) represents the maximum value, the first confirmation packet and
  • the second acknowledgement packet is two acknowledgement packets continuously sent by the data transmission device to the data sending end, where the first acknowledgement packet is an acknowledgement packet recently sent before the update of SendSeq, and the second acknowledgement packet is The confirmation packet sent before the first confirmation packet.
  • the stored acknowledgement packet sequence number is updated with the acknowledgement packet sequence number of the acknowledgement packet. That is, after updating the SendSeq, the method further includes: updating an acknowledgement packet sequence number of the stored acknowledgement packet; wherein, when updating the stored acknowledgement packet sequence number, if updating the acknowledgement packet sequence number of the recently sent acknowledgement packet before SendSeq is updated It is larger than the stored acknowledgment packet sequence number, or the difference between the acknowledgment packet sequence number of the most recently sent acknowledgment packet sent before SendSeq and the stored acknowledgment packet sequence number is less than the preset value, and the confirmation packet of the latest acknowledgement packet sent before the update SendSeq is updated.
  • the sequence number updates the currently stored acknowledgment packet sequence number; otherwise, if the two acknowledgment packet numbers sent before and after are the same, the stored acknowledgment packet sequence number can be kept unchanged, wherein the preset value is determined according to the number of digits of the acknowledgment packet sequence number. of.
  • the preset value is -2.
  • the acknowledgement packet number of the most recently sent acknowledgement packet and the stored acknowledgement packet sequence number When the difference between the acknowledgement packet number of the most recently sent acknowledgement packet and the stored acknowledgement packet sequence number is less than the preset value before updating the transmission sequence number, it indicates that the wraparound has occurred, that is, the acknowledgement packet is renumbered from "0" to The confirmation packet sequence number of the most recently sent acknowledgement packet before the update sequence number is updated to update the currently stored acknowledgement packet sequence number to facilitate subsequent SendSeq update.
  • the default value is -2147483648.
  • SendSeq may not be updated, but the stored confirmation packet sequence number is updated.
  • a timer can be set in the data transmission device to pass The timer is used to implement the control of the foregoing sending period, where the duration of the timer is equal to the sending period.
  • the above step S110 that is, at the beginning of the transmission period, setting the transmission sequence number to zero can be implemented by: starting the timer, and setting the transmission sequence number to zero.
  • the acknowledgement packet is suspended in the current transmission period until the end of the current transmission period, and the transmission of the acknowledgement packet after the SendSeq is set to zero in the next transmission period can be implemented by: when the timer expires, the timer is restarted. , after sending the serial number to zero, continue to send the confirmation packet.
  • FIG. 12 is a schematic flowchart of a method for processing an acknowledgement packet according to Embodiment 4 of the present invention.
  • the executor of the method is a data transmission device, and uses SendSeq to represent the total amount of data acknowledged by the data receiver reflected by all sent acknowledgment packets in a transmission period.
  • the method includes the following steps:
  • S122 Cache the new acknowledgement packet to send the new acknowledgement packet after sending the other acknowledgement packet to the data sender.
  • step S123 Determine the relationship between the current SendSeq and the data volume threshold. If the current SendSeq is greater than the data volume threshold, step S124 is performed; if the current SendSeq is less than the data volume threshold, step S125 is performed.
  • S124 Cache the new acknowledgement packet, and send the new acknowledgement packet to the data sending end after the SendSeq is zeroed in the next sending period;
  • S125 Send the new acknowledgement packet to the data sender.
  • the acknowledgement packet may be suspended until the current transmission period ends, and the transmission packet may be continuously sent after the transmission sequence number is set to zero in the next transmission period, and the acknowledgement packet may continue to be sent. package.
  • step S122 after transmitting the other acknowledgement packet to the data sender, may include the following steps: S131: sending the other confirmation package;
  • step S133 Determine a relationship between the updated SendSeq and the data volume threshold. If the updated SendSeq is smaller than the data volume threshold, execute step S134. If the updated SendSeq is greater than the data volume threshold, execute step S135. If the updated SendSeq is equal to the data volume threshold, step S134 may be performed, or step S135 may be performed. The reason is the same as the above description, and details are not described herein again.
  • S135 Suspend sending the new acknowledgement packet until the end of the current transmission period, and send the new acknowledgement packet after the transmission sequence number is set to zero in the next transmission period.
  • the data transmission device may cache another confirmation packet or may cache multiple. That is, the other confirmation packets may be plural or one.
  • the above step S131 that is, sending the other confirmation packets may include: sending the other confirmation packets one by one in a queue order, and repeating each time an acknowledgement packet is sent. The following steps, until the other confirmation packages are sent:
  • step S142 Determine a relationship between the updated SendSeq and the data volume threshold. If the updated SendSeq is less than the data volume threshold, step S143 is performed. If the updated SendSeq is greater than the data volume threshold, step S144 is performed. If the updated SendSeq is equal to the data volume threshold, step S143 may be performed, or step S144 may be performed. The reason is the same as the above description, and details are not described herein again.
  • S144 Suspend sending the acknowledgement packet until the end of the current transmission period, and continue to send the next acknowledgement packet after the transmission sequence number is set to zero in the next transmission cycle.
  • the timer may be set in the data transmission device to implement the control of the foregoing sending period by using a timer, where the duration of the timer is equal to the sending period.
  • SendSeq is set to zero at the beginning of the transmission period, and based on this, the SendSeq is updated according to the confirmed amount of data reflected by the transmission confirmation packet.
  • the SendSeq may be set to “ ⁇ or other values, and the data threshold may be adjusted accordingly, even if the SendSeq is set to a smaller value such as “1”, without affecting the effect of the present invention.
  • the data volume threshold may not be adjusted. In the embodiment of the present invention, no limitation is imposed on this.
  • SendSeq is set to a data amount threshold at the beginning of the transmission period, and SendSeq is updated in a decreasing manner after each acknowledgement packet is sent, and is decremented to zero or less than zero. Stop the transmission of the confirmation packet during this period. Please refer to Figure 15. At this point, confirm the processing method of the package, including the following steps:
  • S150 Set SendSeq to a data amount threshold at the beginning of the sending period
  • each time an acknowledgement packet is sent during the current transmission period the SendSeq is updated once, and each time the SendSeq is updated, the relationship between the updated SendSeq and zero is judged. That is, in the current transmission period, the following steps S151 to S153 are repeatedly executed until the current transmission period ends or the updated SendSeq is less than zero.
  • step S153 Determine the relationship between the updated SendSeq and zero. If the updated SendSeq is greater than zero, steps S151 through S153 are continued; if the updated SendSeq is less than zero, then step S154 is performed.
  • S154 Suspend sending the acknowledgement packet in the current transmission period until the end of the current transmission period, and continue to send the acknowledgement packet after setting SendSeq to the data volume threshold in the next transmission period.
  • the updated SendSeq SendSeq-Max before update (0, the confirmation packet number of the first confirmation packet - the confirmation packet number of the second confirmation packet); wherein Max ( ) represents the maximum value, the first confirmation packet and
  • the second acknowledgement packet is two acknowledgements that the data transmission device continuously sends to the data sender.
  • the stored acknowledgment packet sequence number is updated with the acknowledgment packet sequence number of the acknowledgment packet. That is, after updating the SendSeq, the method further includes: updating the acknowledgment packet sequence number of the stored acknowledgment packet; wherein, the updated acknowledgment packet number is the same as the third embodiment, and details are not described herein again.
  • the transmission of the acknowledgement packet may be suspended until the end of the current transmission period, and the transmission of the sequence number is set to the data amount threshold in the next transmission cycle to continue the transmission of the acknowledgement packet. You can also continue to send confirmation packets.
  • FIG. 16 is a schematic structural diagram of a data transmission device according to Embodiment 6 of the present invention.
  • the data transmission device 160 includes a receiving circuit 161 , a transmitting circuit 162 , a memory 163 , and a processor 164 . .
  • the receiving circuit 161 is configured to receive the acknowledgement packet; the transmit circuit 162 is configured to send the acknowledgement packet; the memory 163 stores the data volume threshold; the processor 164 is coupled to the receive circuit 161, the transmit circuit 162, and the memory 163, respectively, and the processor 164 is configured to update
  • the difference between the data amount threshold and the total data amount, the total data amount is the total data amount confirmed by the data receiving end reflected by all the sent acknowledgement packets in the current transmission period, and the processor 164 is further configured to use the updated data amount.
  • the difference between the threshold and the total amount of data controls whether the transmitting circuit 162 continues to transmit the acknowledgement packet during the current transmission period.
  • the difference between this embodiment and the first embodiment is that the processor 164 updates the difference between the data amount threshold and the total data amount based on the data amount threshold, and controls 162 whether to continue to send the acknowledgement packet in the current transmission period according to the difference. Since the data threshold is preset, the change in the difference between the data threshold and the total data actually reflects the change in the total amount of data. Therefore, using the difference to control whether to continue sending the acknowledgement packet during the transmission period can be achieved and implemented. Example 1 has the same effect.
  • the seventh embodiment of the present invention further provides a processing method for the confirmation packet. Please refer to FIG. 17, which is a schematic flowchart of a method for processing a confirmation packet according to Embodiment 7 of the present invention. As shown in FIG. 17, the method includes the following steps:
  • S172 Update a difference between a data volume threshold and a total data volume, where the total data volume is a total amount of data acknowledged by the data receiving end reflected by all sent acknowledgement packets in the current sending period;
  • S173 Control whether to continue to send the confirmation packet in the current transmission period according to the difference between the updated data volume threshold and the total data amount.
  • the descriptions of the data volume thresholds in the sixth and seventh embodiments are the same as those in the first embodiment, and are not described herein again.
  • the manner and frequency of updating the difference between the data volume threshold and the total data amount are, for example, the description of the first embodiment, and details are not described herein again.
  • the difference between the updated data volume threshold and the total data amount is a process of updating the total data amount based on the data amount threshold, and the total data amount is updated as in the above embodiment 1, and the data is updated after each total number is updated.
  • the difference between the quantity threshold and the total data amount can be obtained by the difference between the updated data amount threshold and the total data amount.
  • the update may also be omitted.
  • the update may be started based on the data amount threshold, and each time an acknowledgement packet is sent, the amount of data confirmed by the data receiving end reflected by the acknowledgement packet is decremented, when decremented to zero or close When it is zero, the acknowledge packet transmission in this transmission cycle is stopped.
  • FIG. 18 is a schematic structural diagram of a data transmission device according to Embodiment 8 of the present invention. As shown in FIG. 18, the device includes a transmitting unit 181, an updating unit 182, and a control unit 183, wherein the transmitting unit 181 is configured to send an acknowledgement packet; and the updating unit 182 is configured to update all acknowledged packets reflected in the current transmission period.
  • control unit 183 is configured to compare the updated total data amount with the data amount threshold, and control whether to continue to send the confirmation packet in the current transmission period according to the comparison result.
  • the description of the data volume threshold is the same as the first embodiment, and details are not described herein again.
  • update process of the update unit 182 and the control process of the control unit 183 are the same as those of the first embodiment, and are not described herein again.
  • the acknowledgement packet in the embodiments of the present invention may be an uplink acknowledgement packet, where the uplink refers to the terminal device to the base station, or the terminal device to the radio network controller (Radio Network Controller, abbreviated as RNC), or the terminal device to the server, etc. .
  • RNC Radio Network Controller
  • An embodiment of the present invention provides a method for processing an acknowledgement packet. As shown in FIG. 1, the method includes the following steps.
  • the first entity determines whether other acknowledgement packets have been cached. If other acknowledgement packets have been cached, step 102 is performed; otherwise, one of steps 103 to 105 is performed according to different situations.
  • the SendSeq is a total data amount of the acknowledgement packet sent by the first entity after the timer is started, and the acknowledgement packet sending threshold is that the first entity is allowed to send within the duration of the timer. The total amount of data for the confirmation package.
  • the method further includes: updating the SendSeq.
  • caching the new confirmation package includes: The acknowledgement packet is cached after the other acknowledgement packet; the sending the new acknowledgement packet after sending the other acknowledgement packet includes: when the timer of the first entity times out, the acknowledgement packet in the cache is queued Send one by one.
  • the method further includes: performing the update of the Sendseq one time each time an acknowledgement packet is sent.
  • the method further includes: after performing the updating of the Sendseq, determining whether the updated Sendseq is greater than the acknowledgement packet sending threshold; if the new acknowledgement packet is sent, after the update If the Sendseq is greater than the acknowledgement packet transmission threshold, stop sending the buffered acknowledgement packet in the first entity, restart the timer, and send the new acknowledgement packet before the timer expires.
  • Updated SendSeq SendSeq + Max before update (0, Confirmation packet number of the first confirmation packet - Second confirmation packet The confirmation packet sequence number); wherein the first confirmation packet and the second confirmation packet are two preceding and succeeding packets continuously transmitted by the first entity.
  • the method further includes: updating an acknowledgement packet sequence number of the acknowledgement packet; wherein, when updating the acknowledgement packet sequence number of the second acknowledgement packet, if the acknowledgement packet sequence number of the first acknowledgement packet If the difference between the sequence number of the first acknowledgement packet and the acknowledgement packet number of the second acknowledgement packet is less than -2147483648, the confirmation packet of the first acknowledgement packet is The sequence number is used as the confirmation packet number of the second confirmation packet; otherwise, the confirmation packet number of the second confirmation packet read by the first entity is used as the confirmation packet number of the second confirmation packet.
  • the product of the duration of the timer, the AvgSendByte is determined according to the aggregate maximum bit rate AMBR and the maximum throughput rate MaxThroughput, where:
  • AvgSendByte (MaxThroughput, AMBR) x0.97 ⁇ 8000 J , where the
  • the duration of the timer is a period in which the first entity sends an acknowledgment packet
  • the acknowledgment packet is an uplink packet that is not more than 80 bytes and includes an acknowledgment character.
  • the method further includes: establishing the first entity, where the first entity is located at the base station.
  • the first entity in this embodiment may be a base station, such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or an RNC.
  • a base station such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or an RNC.
  • the embodiment of the present invention can process the acknowledgement packet after receiving the acknowledgement packet, and set a transmission period and a data volume threshold for the acknowledgement packet, and control the acknowledgement sent to the server in each transmission period.
  • network throughput is reduced and network transmission efficiency is improved.
  • Another embodiment of the present invention provides a method of processing a confirmation packet. As shown in FIG. 2, the method includes the following steps.
  • the second entity determines whether there is a first entity for buffering and sending the new acknowledgement packet. If the first entity exists, performing step 202; otherwise, performing step 203 to step 205 according to different situations. One.
  • the first entity does not exist, the number of the existing third entity is less than the second threshold m, and the number of the third entity that has the acknowledgement packet cached is not greater than the third threshold n, The first entity sends the new acknowledgement packet to the first entity.
  • the first entity does not exist, the number of the existing third entity is not less than the second threshold m, and the number of the third entity that has the acknowledgement packet cached is not greater than the third threshold n, delete at least A third entity that does not have an acknowledgement packet cached, and the first entity is established, and the new acknowledgement packet is sent to the first entity.
  • the new acknowledgement packet is sent to the server.
  • the m is an upper limit of an entity that is allowed to be established for buffering and sending an acknowledgement packet
  • n is an upper limit of the number of third entities that are allowed to simultaneously cache the acknowledgement packet.
  • the first entity in this embodiment may be a base station, such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or an RNC.
  • a base station such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or an RNC.
  • the embodiment of the present invention can determine, when a new acknowledgement packet arrives at the second entity, the second entity, for the new acknowledgement packet, to determine the newly arrived acknowledgement packet to determine a cache and/or send process.
  • the first entity of the mode processes the acknowledgement packet by the first entity, so that the acknowledgement packet can be sent to the server at a steady rate, avoiding the sudden increase of the number of acknowledged packets, and the downlink packet transmission caused by it is not timely and lost. Packet issues, thereby avoiding network throughput degradation and improving network transmission efficiency.
  • Another embodiment of the present invention provides a method of processing a confirmation packet, the details of which may be considered as an example of the first two embodiments. As shown in FIG. 3, the method includes the following steps:
  • the second entity determines whether there is a first entity for buffering and sending the new acknowledgement packet. If the first entity does not exist, step 302 is performed; if the first entity exists, step 303 is performed. .
  • the acknowledgement packet should satisfy three conditions: the direction of the packet is uplink; the size of the packet is not greater than 80 bytes; and the packet contains an acknowledgement character (Acknowledgement, abbreviated as ACK).
  • ACK acknowledgement character
  • the first entity is an operation unit for processing an acknowledgement packet in the base station, and the entity is provided with source IP, destination IP, source port number, destination port number, timer, acknowledgement packet sequence number, and transmission sequence number SendSeq when being established. And other parameters.
  • LastSeq indicates the sequence number of the previous acknowledgement packet sent
  • SendSeq is the total data amount of the acknowledgement packet sent by the first entity after the timer is started. When initializing, the acknowledgement packet number and SendSeq are both 0.
  • the second entity establishes a corresponding first entity for the new acknowledgement packet.
  • the method further includes: if the first entity does not exist, the number of the existing third entity is less than the second threshold m, and the number of the third entity that has the acknowledgement packet cached is not greater than a third threshold n, the first entity is established, and the new acknowledgement packet is sent to the first entity;
  • the number of the existing third entity is not less than the second threshold m, and the number of the third entity that has the acknowledgement packet cached is not greater than the third threshold n, then at least one is deleted.
  • a third entity that has an acknowledgement packet cached, and the first entity is established, and the new acknowledgement packet is sent to the first entity.
  • the method further includes: if the first entity does not exist, and the number of the third entity that has cached the acknowledgement packet is greater than the third threshold, the new acknowledgement packet is sent to the server;
  • the m is an upper limit of an entity that is allowed to be established for buffering and sending an acknowledgement packet
  • n is an upper limit of the number of third entities that are allowed to simultaneously cache the acknowledgement packet.
  • the second entity sends the new acknowledgement packet to the first entity.
  • the new acknowledgement packet arrives, if the first entity has already cached other acknowledgement packets, the new acknowledgement packet is cached after other acknowledgement packets.
  • the first entity determines whether the timer expires. If the timer expires, go to step 307. If the timer does not expire, go to step 306.
  • the duration of the timer is a period in which the first entity sends an acknowledgement packet.
  • the first entity sends an acknowledgement packet to the server according to the queue order and the sending interval. Each time an acknowledgement packet is sent, the Sendseq is updated. When the updated Sendseq is greater than the acknowledgement packet sending threshold, the sending of the acknowledgement packet is stopped, and step 308 is performed. .
  • the sendingSeq is the total data volume of the acknowledgement packet sent by the first entity after the timer is started, and the acknowledgement packet sending threshold is that the first entity is allowed to send within the duration of the timer.
  • the total amount of data of the acknowledgement packet, and the value of the acknowledgement packet transmission threshold is the average transmission byte speed.
  • AvgSendByte (MaxThroughput, AMBR) x0.97 ⁇ 8000 J , where the
  • the relationship between the updated SendSeq and the SendSeq before the update is:
  • the updated SendSeq SendSeq + Max (0, the confirmation packet number of the first confirmation packet - the confirmation packet number of the second confirmation packet); wherein the first confirmation packet and the second confirmation packet are The first and second acknowledgement packets are continuously sent by the first entity.
  • updating the acknowledgement packet sequence number of the acknowledgement packet after updating the SendSeq, updating the acknowledgement packet sequence number of the acknowledgement packet; wherein, when updating the acknowledgement packet sequence number of the second acknowledgement packet, if the acknowledgement packet sequence number of the first acknowledgement packet is greater than The confirmation packet sequence number of the second confirmation packet, or the difference between the sequence number of the first confirmation packet and the confirmation packet number of the second confirmation packet is less than -2147483648, and the confirmation packet number of the first confirmation packet is used as The confirmation packet sequence number of the second confirmation packet; otherwise, the confirmation packet number of the second confirmation packet read by the first entity is used as the confirmation packet sequence number of the second confirmation packet.
  • the first entity sends the acknowledgement packets in the cache to the server one by one in a queue order. Each time an acknowledgement packet is sent, the Sendseq is updated once, until the updated Sendseq is greater than the acknowledgement packet sending threshold, and the acknowledgement packet is stopped.
  • the first entity restarts the timer, and sends a new acknowledgement packet in a next sending period. It should be noted that the first entity, the second entity, and the third entity in this embodiment may be located at the base station.
  • the second entity searches Or establishing a first entity, sending the new acknowledgement packet to the first entity, the first entity buffering the acknowledgement packet after another acknowledgement packet, and setting a sending period and a data volume threshold for the acknowledgement packet, and controlling each The total amount of data sent to the server during the transmission cycle, and thus the number of acknowledgment packets, so that the acknowledgment packet can be sent to the server at a steady rate, avoiding the sudden increase in the number of acknowledgment packets and the downstream packets caused by it.
  • the transmission is not timely and the packet loss problem, thereby avoiding the network throughput degradation and improving the network transmission efficiency.
  • Another embodiment of the present invention provides a method for processing an acknowledgement packet. The difference between the embodiment and the previous embodiment is that when a new acknowledgement packet arrives at the first entity, the first entity does not cache other acknowledgement packets, and The timer is not started. As shown in FIG. 4, the method includes the following steps:
  • the second entity sends a new acknowledgement packet to the first entity.
  • the searching and establishing process of the first entity refers to steps 301-302 of the previous embodiment.
  • the duration of the timer is a period in which the first entity sends an acknowledgement packet
  • the SendSeq is a total data volume of the acknowledgement packet sent by the first entity after the timer is started.
  • the acknowledgement packet sequence number of the acknowledgement packet after updating the SendSeq, updating the acknowledgement packet sequence number of the acknowledgement packet; wherein, when updating the acknowledgement packet sequence number of the second acknowledgement packet, if the acknowledgement packet sequence number of the first acknowledgement packet is greater than The confirmation packet sequence number of the second confirmation packet, or the difference between the sequence number of the first confirmation packet and the confirmation packet number of the second confirmation packet is less than -2147483648, and the confirmation packet number of the first confirmation packet is used as The confirmation packet sequence number of the second confirmation packet; otherwise, the confirmation packet number of the second confirmation packet read by the first entity is used as the confirmation packet sequence number of the second confirmation packet.
  • the first entity, the second entity, and the third entity in this embodiment may all be located at the base station.
  • the second entity searches for or establishes the first entity, and sends the new acknowledgement packet to the first entity, where the first entity does not cache other acknowledgements.
  • the packet does not start the timer
  • a timer is started for the new acknowledgement packet, and the new acknowledgement packet is sent to the server, and a sending period and a data volume threshold are set for the acknowledgement packet, and the control is sent to the server in each sending period.
  • Another embodiment of the present invention provides a method for processing an acknowledgement packet.
  • the difference between the embodiment and the first two embodiments is that when a new acknowledgement packet arrives at the first entity, the first entity does not cache other acknowledgement packets. And the timer is started. As shown in FIG. 5, the method includes the following steps:
  • the second entity sends a new confirmation packet to the first entity.
  • the searching and establishing process of the first entity refers to steps 301-302 of the third embodiment.
  • the first entity determines whether the send sequence number SendSeq is greater than the acknowledgement packet sending threshold, if the SendSeq is greater than the acknowledgement packet.
  • the threshold is sent, and step 506 is performed; if the SendSeq is not greater than the acknowledgement packet sending threshold, step 505 is performed.
  • the SendSeq is a total data amount of the acknowledgement packet sent by the first entity after the timer is started, and the acknowledgement packet sending threshold is that the first entity is allowed to send within the duration of the timer.
  • the total amount of data of the acknowledgement packet, the duration of the timer being the period in which the first entity sends the acknowledgement packet.
  • the AvgSendByte is based on the aggregated maximum bit rate AMBR and The maximum throughput rate is determined by MaxThroughput, where:
  • AvgSendByte (MaxThroughput, AMBR) x0.97 ⁇ 8000 J , where the
  • the first entity sends a new acknowledgement packet to the server, and updates the sending sequence number SendSeq.
  • the updated SendSeq is greater than the sending threshold, the subsequent sending of the confirmation packet is stopped.
  • the updated SendSeq SendSeq + Max (0, the confirmation packet number of the first confirmation packet - the confirmation packet number of the second confirmation packet); wherein the first confirmation packet and the second confirmation packet Two before and after confirmation packets are continuously sent for the first entity.
  • updating the acknowledgement packet sequence number of the acknowledgement packet after updating the SendSeq, updating the acknowledgement packet sequence number of the acknowledgement packet; wherein, when updating the acknowledgement packet sequence number of the second acknowledgement packet, if the acknowledgement packet sequence number of the first acknowledgement packet is greater than The confirmation packet sequence number of the second confirmation packet, or the difference between the sequence number of the first confirmation packet and the confirmation packet number of the second confirmation packet is less than -2147483648, and the confirmation packet number of the first confirmation packet is used as The confirmation packet sequence number of the second confirmation packet; otherwise, the confirmation packet number of the second confirmation packet read by the first entity is used as the confirmation packet sequence number of the second confirmation packet.
  • the first entity caches the new acknowledgement packet, and restarts the timer, and sends the new acknowledgement packet before the timer expires.
  • first entity, the second entity, and the third entity in this embodiment may be located at the base station.
  • the second entity searches for or establishes the first entity, and sends the new acknowledgement packet to the first entity, where the first entity does not cache other acknowledgements.
  • Another embodiment of the present invention provides a processing device for confirming a packet. As shown in FIG. 6, the device includes a first receiver 61, a first processor 62, a memory 63, a first transmitter 64, and a timer 65. , among them:
  • the first receiver 61 is configured to receive an acknowledgement packet
  • the memory 63 is configured to buffer an acknowledgement packet received by the first receiver 61;
  • the first transmitter 64 is configured to send an acknowledgement packet buffered by the memory 63;
  • the first processor 62 is configured to trigger the memory 63 to cache the new acknowledgement packet if it is determined that the memory 63 has been cached with other acknowledgement packets when the new acknowledgement packet arrives at the first receiver 61.
  • the timer 65 is not activated, the timer 65 is triggered to be started, and the The first transmitter 64 sends the new acknowledgement packet; or, when the new acknowledgement packet arrives at the first receiver 61, if it is determined that the memory 63 is not buffered with other acknowledgement packets, the timer 65 is started, and Sending sequence number SendSeq is greater than the acknowledgement packet transmission threshold, triggering said memory 63 to buffer said new acknowledgement packet, triggering said timer 65 to restart, and commanding said first transmitter 64 to transmit before said timer 65 times out Or a new acknowledgement packet; or, when the new acknowledgement packet arrives at the first receiver 61, if it
  • the SendSeq is the total data amount of the acknowledgement packet sent after the timer 65 is started, and the acknowledgement packet transmission threshold is the total data volume of the acknowledgement packet that is allowed to be sent within the duration of the timer 65.
  • the first processor 62 is further configured to: after the first transmitter 64 sends the new acknowledgement packet, update the SendSeq.
  • the memory 63 is specifically configured to: cache the new acknowledgement packet after the other acknowledgement packet; the first transmitter 64 is specifically configured to: when the timer 65 times out, the memory 63 The cached acknowledgement packets are sent one by one in queue order.
  • the first processor 62 is further configured to: after the first transmitter 64 sends an acknowledgement packet, perform an update of the Sendseq.
  • the first processor 62 is further configured to: determine, after each performing the updating of the Sendseq, whether the updated Sendseq is greater than the acknowledgement packet sending threshold; when the first transmitter 64 sends the new Before the acknowledgement packet, when the updated Sendseq of the first processor 62 is greater than the acknowledgement packet sending threshold, the first transmitter 64 is triggered to stop sending the buffered acknowledgement packet in the first entity, and the timing is triggered.
  • the device 65 restarts and commands the first transmitter 64 to send the new acknowledgement packet before the timer 65 times out.
  • the first processor 62 is further configured to: update an acknowledgement packet sequence number of the acknowledgement packet, where, when the acknowledgement packet sequence number of the second acknowledgement packet is updated, if the acknowledgement packet sequence number of the first acknowledgement packet is greater than The confirmation packet sequence number of the second confirmation packet, or the difference between the sequence number of the first confirmation packet and the confirmation packet sequence number of the second confirmation packet is less than -2147483648, and the confirmation packet number of the first confirmation packet is As the confirmation packet number of the second confirmation packet; otherwise, the confirmation packet number of the second confirmation packet read by the first entity is used as the confirmation packet number of the second confirmation packet.
  • the duration of the timer 65 is the period during which the acknowledgement packet is sent.
  • the device in this embodiment may be a base station, such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or may be an RNC.
  • the embodiment of the present invention can process the acknowledgement packet after receiving the acknowledgement packet, and set a transmission period and a data volume threshold for the acknowledgement packet, and control the acknowledgement sent to the server in each transmission period.
  • the total amount of data of the packet, and thus the number of acknowledgment packets so that the acknowledgment packet can be sent to the server at a steady rate, avoiding the sudden increase in the number of acknowledgment packets, and the delay in packet transmission and packet loss caused by it.
  • network throughput is reduced and network transmission efficiency is improved.
  • Another embodiment of the present invention provides a processing device for an acknowledgement packet. As shown in FIG. 7, the device includes a second receiver 71, a second processor 72, and a second transmitter 73, where:
  • the second receiver 71 is configured to receive an acknowledgement packet
  • the second transmitter 73 sends the acknowledgement packet received by the second receiver 71 to the first entity, where the first entity is used to buffer and send the new acknowledgement packet to the server;
  • the second processor 72 is configured to: when the new acknowledgement packet arrives at the second receiver 71, if it is determined that the first entity exists, trigger the second transmitter 73 to send the acknowledgement packet to the The first entity; or, when the new acknowledgement packet arrives at the second receiver 71, if it is determined that the first entity does not exist, the number of existing third entities is less than the second threshold m, and the acknowledgement is cached And the number of the third entity of the packet is not greater than the third threshold n , the first entity is established, and the second transmitter 73 is triggered to send the new acknowledgement packet to the first entity; or, when new When the acknowledgement packet arrives at the second receiver 71, if it is determined that the first entity does not exist, the number of existing third entities is not less than the second threshold m, and the third entity of the acknowledgement packet is already cached.
  • the third threshold n deleting at least one third entity that does not cache the acknowledgement packet, establishing the first entity, and triggering the second transmitter 73 to send the new acknowledgement packet to the first Entity; or, when the new confirmation packet arrives at the second connection 71, if determining that the first entity does not exist, and have confirmed that the number of buffers is greater than a third packet entity third threshold n, triggering the second transmitter 73 transmits the acknowledgment packet to the new server ;
  • the m is an upper limit of an entity that is allowed to be established for buffering and sending an acknowledgement packet.
  • n be the upper limit of the number of third entities that are allowed to simultaneously cache the acknowledgement packet.
  • the device in this embodiment may be a base station, such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or may be an RNC.
  • a base station such as a NodeB, an eNodeB, an HNodeB, or a HeNodeB, or may be an RNC.
  • the embodiment of the present invention can determine, when a new acknowledgement packet arrives at the second entity, the second entity, for the new acknowledgement packet, to determine the newly arrived acknowledgement packet to determine a cache and/or send process.
  • the first entity of the mode processes the acknowledgement packet by the first entity, so that the acknowledgement packet can be sent to the server at a steady rate, avoiding the sudden increase of the number of acknowledged packets, and the downlink packet transmission caused by it is not timely and lost. Packet issues, thereby avoiding network throughput degradation and improving network transmission efficiency.
  • the processing method and device for the acknowledgement packet provided by the embodiment of the present invention can be applied to data transmission in the TCP transmission service, but is not limited thereto.
  • the embodiment of the present invention further provides a system, which may include the device shown in FIG. 6 and/or the device shown in FIG.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本发明实施例公开了一种确认包的处理方法、设备及系统，涉及通信技术领域，通过在数据传输设备上设置发送周期与数据量门限，从而利用数据量门限控制每个发送周期内数据传输设备发送给数据发送端的确认包满足所有发送的确认包反映的数据接收端已确认的总数据量在数据量门限之内，使得数据发送端在每个发送周期所接收到的确认包满足所有接收到的确认包反映的数据接收端已确认的总数据量在数据量门限之内，从而解决了数据接收端发送大量的数据包的问题。

Description

确认包的处理方法、 设备及系统 本申请要求于 2012年 03月 21 日提交的申请号为 PCT/CN2012/072726、 发明名称为 "确认包的处理方法、 设备及系统" 的国际专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信技术领域， 特别涉及一种确认包的处理方法、 设备及系 统。 背景技术
传输控制协议 ( Transmission Control Protocol, 英文缩写为 TCP )提供了 一种面向连接的字节流服务， 终端和服务器之间在建立连接后可以正常发送 数据， 并且使用 TCP协议进行的数据传输具有数据包确认机制以及重传功能。 在下行 TCP业务中，服务器向终端发送数据包，终端在接收数据包后向服务器 回复确认包，服务器根据收到的确认包来发送剩余的数据包。基于 TCP业务的 优点， TCP从传统的有线传输业务渐渐地运用到了无线传输业务上。
现有技术中， 由于传输控制协议 /因特网互联协议（ Transmission Control Protocol/Internet Protocol , 英文缩写为 TCP/IP )是针对有线传输进行开发和设 计的。 当引入到无线系统后， 例如长期演进（ Long Term Evolution , 英文缩写 为 LTE )系统， 无线通信自身的限制会导致空口信号的波动， 服务器可能在几 毫秒或几百毫秒内接收不到终端回复的确认包， 然后在空口信号波动消失后， 服务器在短时间内收到大量的确认包。 因此， 现有技术由于缺少在新到达确 认包时的区分处理方式， 可能导致服务器需要根据收到的大量确认包而向终 端下发大量的数据包的问题。 同样， 在上行数据传输上， 当终端向服务器上 传数据包的时候也会存在同样的问题。 发明内容
本发明实施例提供一种确认包的处理方法、 数据传输设备和通信系统， 以解决数据包大量突发的技术问题。
第一方面， 本发明实施例提供一种确认包的处理方法， 包括： 发送确认 包； 更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总 数据量； 比较更新后的总数据量与所述数据量门限； 根据比较结果控制在当 前发送周期内是否继续发送确认包。
第二方面， 本发明实施例提供一种数据传输设备， 包括： 接收电路， 用 于接收确认包； 发送电路， 用于发送确认包； 存储器， 存储数据量门限； 处 理器， 分别与所述接收电路、 发送电路、 存储器连接， 用于更新当前发送周 期内所有已发送的确认包反映的数据接收端已确认的总数据量， 且比较更新 后的总数据量与所述数据量门限， 根据比较结果控制所述发送电路在当前发 送周期内是否继续发送确认包。
第三方面， 本发明实施例提供一种数据传输设备， 包括： 发送单元， 用 于发送确认包； 更新单元， 用于更新当前发送周期内所有已发送的确认包反 映的数据接收端已确认的总数据量； 控制单元， 用于比较更新后的总数据量 与所述数据量门限， 根据比较结果控制在当前发送周期内是否继续发送确认 包。
第四方面， 本发明实施例提供一种通信系统， 包括数据发送端、 数据接 收端以及如第二方面或第三方面所述的数据传输设备， 其中所述数据发送端 通过所述数据传输设备与数据接收端进行通信。
第五方面， 本发明实施例提供一种计算机程序产品， 包括计算机可读介 质， 所述计算机可读介质包括一组程序代码， 用于执行如第一方面所述的方 法。
可见， 在以上各个方面， 通过在数据传输设备上设置发送周期与数据量 门限， 从而利用数据量门限控制每个发送周期内数据传输设备发送给数据发 送端的确认包满足所有发送的确认包反映的数据接收端已确认的总数据量在 数据量门限之内， 使得数据发送端在每个发送周期所接收到的确认包满足所 有接收到的确认包反映的数据接收端已确认的总数据量在数据量门限之内， 从而解决了数据接收端发送大量的数据包的问题。 附图说明
为了更清楚地说明本发明实施例中的技术方案， 下面将对实施例或现有 技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附 图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创 造性劳动的前提下， 还可以根据这些附图获得其它的附图。
图 1为本发明一个实施例提供的确认包的处理方法流程图；
图 2为本发明另一个实施例提供的确认包的处理方法流程图；
图 3为本发明另一个实施例提供的确认包的处理方法流程图；
图 4为本发明另一个实施例提供的确认包的处理方法流程图；
图 5为本发明另一个实施例提供的确认包的处理方法流程图；
图 6为本发明另一个实施例提供的确认包的处理设备结构示意图； 图 7为本发明另一个实施例提供的确认包的处理设备结构示意图； 图 8为本发明实施例一提供的数据传输设备的结构示意图；
图 9为本发明实施例二提供的一种确认包处理方法的流程示意图； 图 10为本发明实施例二提供的一种更新总数据量方法的流程示意图； 图 11为本发明实施例三提供的一种确认包处理方法的流程示意图； 图 12为本发明实施例四提供的一种确认包的处理方法的流程示意图； 图 13为图 12所示确认包的处理方法的步骤 S122的详细流程示意图； 图 14为图 13所示确认包的处理方法的步骤 S131的详细流程示意图； 图 15本发明实施例五提供的一种确认包的处理方法的流程示意图； 图 16为本发明实施例六提供的一种数据传输设备的结构示意图； 图 17为本发明实施例七提供的一种确认包处理方法的流程示意图； 图 18为本发明实施例八提供的一种数据传输设备的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行 清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而 不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有做 出创造性劳动前提下所获得的所有其它实施例， 都属于本发明保护的范围。
为使本发明技术方案的优点更加清楚， 下面结合附图和实施例对本发明 作详细说明。
TCP/IP是针对有线传输进行开发和设计的， 引入无线通信系统后， 由于 无线通信系统自身的限制会导致空口信号的波动。 在下行数据传输上， 服务 器可能在几毫秒或几百毫秒内接收不到终端回复的确认包， 然后在空口信号 波动消失后， 服务器在短时间内收到大量的确认包， 导致服务器根据收到的 大量确认包而向终端下发大量的数据包的问题。 同样， 在上行数据传输上， 当终端向服务器上传数据包的时候也会存在同样的问题。
本发明实施例考虑到此问题的存在， 在数据传输设备上设置发送周期与 数据量门限， 从而利用数据量门限控制每个发送周期内数据传输设备发送给 数据发送端的确认包满足所有发送的确认包反映的数据接收端已确认的总数 据量在数据量门限之内， 使得数据发送端在每个发送周期所接收到的确认包 满足所有接收到的确认包反映的数据接收端已确认的总数据量在数据量门限 之内， 从而解决了数据接收端发送大量的数据包的问题。 节点设备， 例如接入网设备、 核心网设备， 也可以是设置于接入网侧独立于 现有接入网设备的数据传输设备， 或者设置于核心网侧独立于现有核心网设 备的数据传输设备。 例如， 所述数据传输设备可以为各种通信系统中的基站， 如基站收发台 ( Base Transceiver Station, BTS )、 节点 B ( node B )、 演进型节 点 B ( Evolutional Node B , eNB或 eNodeB )等； 也可以是全球移动通信系统 ( Global System for Mobile Communications, GSM ) 中的基站控制器（Base Station Controller , BSC ) 或通用移动通信系统 ( Universal Mobile Telecommunications System, UMTS ) 中的无线网络控制器 （Radio Network Controller , RNC ), 本发明不做任何限制。
本发明实施例中的数据发送端可以为服务器， 也可以为终端； 相应的数 据接收端可以为终端， 也可以为服务器。 例如， 在上行数据传输中， 数据发 送端为终端、 数据接收端为服务器； 在下行数据传输中， 数据发送端为服务 器、 数据接收端为终端。 本发明不做任何限制。
相应的， 本发明实施例中的确认包可以为上行确认包， 也可以为下行确 认包。
请参考图 8 , 其为本发明实施例一提供的数据传输设备的结构示意图， 如 图所示， 该数据传输设备 800包括接收电路 810、 发送电路 820、 存储器 830以 及分别与接收电路 810、 发送电路 820和存储器 830连接的处理器 840。 其中， 接收电路 810用于接收确认包； 发送电路 820用于发送确认包； 存储器 830存储 数据量门限； 处理器 840用于更新当前发送周期内所有已发送的确认包反映的 数据接收端已确认的总数据量， 且根据更新后的总数据量与存储器 840存储的 数据量门限， 控制发送电路 820在当前发送周期内是否继续发送确认包。 接收端已确认的总数据量， 并比较更新后的总数据量与本地存储的数据量门 限， 根据比较结果控制当前发送周期内是否继续发送确认包， 使得一个发送 周期内达到数据发送端的确认包不至于太多， 从而解决了数据发送端发送大 量的数据包的问题。 而数据发送端发送大量的数据包， 可能会导致数据包传 输不及时和丟包问题。 例如， 服务器的发送能力通常比较强， 当其一定时间 内接收到较多的确认包时， 会根据接收到的确认包下发大量数据包， 导致数 据突发， 而中间传输网元的发送能力往往不够， 导致数据包传输不及时和丟 力， 从而解决了数据发送端数据突发引起的数据包传输不及时和丟包问题。
需要说明的是， 本领域技术人员可以根据实际需要或者运营商的需求， 自行设定数据量门限的取值或范围， 本发明不做任何限制。 例如， 在下行数 据传输中， 由于服务器的处理能力比较强， 而数据传输设备所在无线网络的 承载能力无法满足服务器数据突发时带来的冲击， 从而导致丟包和传输不及 时的问题。 此时， 可以以承载网络的承载能力为依据， 设置数据量门限。 所 述承载网络的承载能力可以为接入网与核心网之间的传输网元的承载能力， 例如， 交换机、 路由器等的承载能力。 再如， 该数据量门限也可以受限于承 载链路的限制速率， 所述承载链路可以为接入网与核心网之间的链路。 再如， 该数据量门限也可以受限于数据传输设备所在无线网络的传输带宽。 再如， 一旦数据发送端或数据接收端的处理能力有限时， 也可以根据数据发送端或 数据接收端的处理能力来确定， 例如， 根据数据发送端的传输控制协议 TCP 发送窗口或数据接收端的 TCP接收窗口确定。
另外， 关于更新当前发送周期内所有已发送的确认包反映的数据接收端 已确认的总数据量， 可以每发送一个确认包更新一次， 也可以每发送两个或 更多的确认包更新一次， 也可以将发送周期分时段， 前面时段， 多个确认包 更新一次， 后面时段一个确认包更新一次。 另外， 也可以根据上一次更新后 的结果， 确定下一次更新所隔的确认包的个数。 考虑到实现简单， 可以每发 送一个确认包更新一次， 但本发明不做任何限制。
相应于实施例一， 本发明实施例二还提供一种确认包的处理方法。 请参 考图 9 , 其为本发明实施例二提供的一种确认包处理方法的流程示意图。 如图 9所示， 该方法包括如下步骤：
S910: 发送确认包；
S920: 更新当前发送周期内所有已发送的确认包反映的数据接收端已确 认的总数据量；
S930: 比较更新后的总数据量与所述数据量门限；
S940： 根据比较结果控制在当前发送周期内是否继续发送确认包 c 数据接收端已确认的总数据量， 并比较更新后的总数据量与本地存储的数据 量门限， 根据比较结果控制当前发送周期内是否继续发送确认包， 使得一个 发送周期内达到数据发送端的确认包不至于太多， 从而解决了数据发送端发 送大量的数据包的问题。 而数据发送端发送大量的数据包， 可能会导致数据 包传输不及时和丟包问题。 例如， 服务器的发送能力通常比较强， 当其一定 时间内接收到较多的确认包时， 会根据接收到的确认包下发大量数据包， 导 致数据突发， 而中间传输网元的发送能力往往不够， 导致数据包传输不及时 送能力， 从而解决了数据发送端数据突发引起的数据包传输不及时和丟包问 关于数据量门限和更新总数据量的说明， 同实施例一， 在此不再赘述。 下面对处理器 840更新总数据量的过程或以上步骤 S920更新总数据量的 过程进行详细说明。
以上总数据量的更新， 可以根据确认包的确认包序号进行。 所述确认包 的确认包序号为 TCP ACK的序号， 该 TCP ACK的序号表示该序号以前的数据 均已被数据接收端确认。 因此， 每发送一个确认包便可以根据当前发送的确 认包与上一个发送的确认包的序号之差， 确定当前发送的确认包所反映的数 据接收端所确认的数据量。 如此， 便可以利用每个确认包所反映的数据接收 接收端所确认的总数据量。例如，假设某一个发送的确认包序号为 747337662, 其表示该第 747337662字节以前的数据均已被数据接收端确认； 且在该确认包 之后发送的确认包序号为 747340582 , 其表示该第 747340582字节以前的数据 均 已接收。 此时， 更新后的总数据量 =更新前的总数据量 +
( 747340582-747337662 )。
即， 如图 10所示， 以上步骤 S920: 更新当前发送周期内所有已发送的确 认包反映的数据接收端已确认的总数据量， 进一步可以包括：
S101 : 根据当前发送的确认包的确认包序号与上一个发送的确认包的确 认包序号之差， 确定当前发送的确认包反映的数据接收端所确认的数据量；
S102: 根据所述当前发送的确认包反映的数据接收端所确认的数据量， 更新所述总数据量。
需要说明的是， 确认包的确认包序号通常以 n位二进制的形式来表示， 当 编号到其所能表达的最大数值时， 将重新开始编号， 这种情况称为绕回现象。 当当前发送的确认包的确认包序号发生绕回时， 其与上一个确认包之差就会 出现负值， 按以上方法更新就会出现问题。 因此， 当当前发送的确认包的确 认包序号发生绕回时， 可以不做更新， 即保持总数据量不变。 此时， 虽然少 计算了一个确认包所反映的数据量， 但是并不影响实现的效果。 这是因为， 的总数据量严格控制在数据量门限以内， 而是要控制在数据量门限左右， 即 使超过数据量门限一个确认包所反映出的数据量， 并不会影响本发明的实质， 且也不会对方案的效果实现造成实质上的影响。
下面对处理器 840根据比较结果控制发送电路 820在当前发送周期内是否 继续发送确认包的过程或步骤 S940根据比较结果控制在当前发送周期内是否 继续发送确认包的过程进行详细说明。
当更新后的总数据量大于数据量门限时， 停止在当前发送周期内发送确 认包， 具体可以通过处理器 840控制发送电路 820在当前发送周期内停止发送 确认包来实现。 当更新后的总数据量小于数据量门限时， 可以继续在当前发 送周期内发送确认包， 具体可以通过处理器 840控制发送电路 820在当前发送 周期内继续发送确认包来实现。 下面对当更新后的总数据量等于数据量门限时的处理方式进行说明。 此 时， 可以在当前发送周期内停止发送确认包， 也可以继续发送确认包。 例如， 处理器 840可以控制发送电路 820在当前发送周期内停止发送确认包， 也可以 控制发送电路 820在当前发送周期内继续发送确认包。 这是因为， 本发明实施 所反映的数据接收端已确认的总数据量严格控制在数据量门限以内， 而是要 控制在数据量门限左右， 即使超过数据量门限一个确认包所反映出的数据量， 也不会对方案的效果实现造成实质上的影响。
另外， 也可以以包括数据量门限一定范围的取值作为停止和继续发送确 认包的依据。 例如， 在比较更新后的总数据量和数据量门限时， 发现更新后 的总数据量接近数据量门限， 但还未达到时， 也可以停止发送确认包。 总之， 本发明对比较更新后的总数据量与所述数据量门限， 根据比较结果控制所述 发送电路在当前发送周期内是否继续发送确认包的过程没有严格限制， 只要 将一个发送周期内发送给数据发送端的确认包所反映的数据接收端已确认的 总数据量控制在数据量门限左右即可， 本领域技术人员可据此做变通， 得到 不同实施例， 均在本发明的保护范围内。
因此， 在具体实现上， 本实施例可以有多种实现方式， 下面进行举例说 明， 然而， 这些例子并非用于限制本发明。
请参考图 11 , 其为本发明实施例三提供的一种确认包处理方法的流程示 意图。 该方法的执行主体为数据传输设备， 该数据传输设备预存有数据量门 限， 且利用发送序列号（SendSeq )体现一个发送周期内所有已发送的确认包 反映的数据接收端已确认的总数据量。 如图 11所示， 该方法包括如下步骤：
S110: 在发送周期开始时， 将 SendSeq置零；
而后， 在当前发送周期内每发送一个确认包， 更新一次 SendSeq, 且每次 更新 SendSeq之后， 判断更新后的 SendSeq与数据量门限之间的关系。 即在当 前发送周期内， 重复执行以下步骤 S111至 S113 , 直至当前发送周期结束或者 更新后的 SendSeq大于数据量门限。
S111 : 发送确认包；
S112: 更新 SendSeq;
S113 : 确定更新后的 SendSeq与数据量门限之间的关系。 如果更新后的 SendSeq小于数据量门限，则继续执行步骤 S111至 S113;如果更新后的 SendSeq 大于数据量门限， 则执行步骤 S114。
S114: 在当前发送周期内暂停发送确认包直至当前发送周期结束， 在下 一个发送周期将 SendSeq置零后继续发送确认包。
关于数据量门限的说明同实施例一， 在此不再赘述。
在本实施例中， SendSeq可以通过确认包序号之差确定的， 其中确认包序 号用于表示该确认包序号之前的数据均已被数据接收端确定， 那么两个确认 包序号之差便可以反映出当前所发送的确认包对应的已确定的数据量， 且， 每发送一个确认包， 通过发送的确认包对应的已确定的数据量进行累加来对 SendSeq进行更新， 更新后的 SendSeq便可以反映出一个周期内数据传输设备 已发送的确认包所反映的已确定的总数据量。 从而通过对 SendSeq的监控来控 制一个发送周期内发送的确认包数量， 以解决数据发送端发送大量的数据包 的问题， 进而解决了由其导致的数据包传输不及时和丟包问题。
需要说明的是， 如果更新后的 SendSeq等于数据量门限， 可以暂停发送确 认包直至当前发送周期结束， 在下一发送周期将发送序列号置零后继续发送 确认包。 也可以继续发送确认包， 其原因同以上实施例， 在此， 不再赘述。
在以上步骤 S112更新 SendSeq的过程中， 更新后的 SendSeq与更新前的 SendSeq之间的关系如下：
更新后的 SendSeq = 更新前的 SendSeq + Max ( 0 , 第一确认包的确认包序 号 - 第二确认包的确认包序号）； 其中， Max ( )表示取最大值， 所述第一确 认包和所述第二确认包为数据传输设备连续向数据发送端发送的两个确认 包， 其中第一确认包为更新 SendSeq之前最近发送的确认包， 第二确认包为在 第一确认包之前发送的确认包。 为了在更新 SendSeq可以使用第二确认包的确 认包序号 ， 需要在发送第二确认包之前存储该确认包序号， 故第二确认包的 确认包序号也即数据传输设备已存储的确认包序号。 即， 更新后的 SendSeq = 更新前的 SendSeq + Max ( 0, 更新 SendSeq之前最近发送的确认包的确认包序 号 - 已存储的确认包序号）。
可见， 在 SendSeq的更新过程中， 每发送一个确认包， 则以该确认包的确 认包序号更新已存储的确认包序号。 即， 在更新所述 SendSeq之后， 所述方法 还包括： 更新已存储的确认包的确认包序号； 其中， 更新已存储的确认包序 号时， 如果更新 SendSeq之前最近发送的确认包的确认包序号大于已存储的确 认包序号， 或者更新 SendSeq之前最近发送的确认包的确认包序号与已存储的 确认包序号的差值小于预设值， 以所述更新 SendSeq之前最近发送的确认包的 确认包序号更新当前已存储的确认包序号； 否则， 说明前后发送的两个确认 包序号相同， 则可以保持已存储的确认包序号不变， 其中所述预设值是根据 确认包序号的位数确定的。 当确认包序号利用 n位字符来表示时， 所述预设值 为 -2 。 当更新发送序列号之前最近发送的确认包的确认包序号与已存储的确 认包序号的差值小于预设值时， 则表明发生了绕回， 即确认包重新从 "0" 开 始编号， 以所述更新发送序列号之前最近发送的确认包的确认包序号更新当 前已存储的确认包序号， 以方便后续的 SendSeq更新。 另外， 在发生绕回的时 候， 可以不更新 SendSeq, 即更新后的 SendSeq = 更新前的 SendSeq + Max ( 0 , - Λ ) = 更新前的 SendSeq。 此时， 虽然会引起多发送一个确认包， 但并不会 对方案的效果实现造成实质上的影响。
例如， 利用 32位字符来表示， 此时所述预设值为 -2147483648。 当更新发 小于 -2147483648时， 则表明发生了绕回， 则可以不更新 SendSeq, 但更新已存 储的确认包序号。
在本发明一实施例中， 可以通过在数据传输设备内设置定时器， 以通过 定时器来实现以上发送周期的控制， 其中， 所述定时器的时长等于所述发送 周期。 此时， 以上步骤 S110 , 即在发送周期开始时， 将发送序列号置零可以 通过以下方式实现： 启动所述定时器， 将发送序列号置零。 以上步骤 S114 , 即在当前发送周期内暂停发送确认包直至当前发送周期结束， 在下一个发送 周期将 SendSeq置零后继续发送确认包可以通过以下方式实现： 在定时器到时 时， 重启所述定时器， 将发送序列号置零后继续发送确认包。
请继续参考图 12 , 其为本发明实施例四提供的一种确认包的处理方法的 流程示意图。 该方法的执行主体为数据传输设备， 且利用 SendSeq体现一个发 送周期内所有已发送的确认包反映的数据接收端已确认的总数据量。 如图 12 所示， 该方法包括如下步骤：
S120: 接收新确认包；
S121 : 确定是否已緩存有其他确认包； 如果已緩存有其他确认包则执行 步骤 S122, 否则执行步骤 S123。
S122: 緩存所述新确认包， 以在向数据发送端发送所述其他确认包之后 发送所述新确认包；
S123 : 确定当前 SendSeq与数据量门限之间的关系， 如果当前 SendSeq大 于数据量门限， 则执行步骤 S124; 如果当前 SendSeq小于数据量门限， 则执行 步骤 S125。
S124: 緩存所述新确认包， 并在下一个发送周期将 SendSeq置零后向数据 发送端发送所述新确认包；
S125: 向数据发送端发送所述新确认包。
需要说明的是， 当更新后的发送序列号等于数据量门限时， 可以暂停发 送确认包直至当前发送周期结束， 在下一发送周期将发送序列号置零后继续 发送确认包， 也可以继续发送确认包。
请继续参考图 13 , 以上步骤 S122在向数据发送端发送所述其他确认包之 后发送所述新确认包可以包括以下步骤： S131 : 发送所述其他确认包；
S132: 更新 SendSeq;
S133 : 确定更新后的 SendSeq与数据量门限之间的关系， 如果更新后的 SendSeq小于数据量门限， 则执行步骤 S134 , 如果更新后的 SendSeq大于数据 量门限， 则执行步骤 S135。 对于更新后的 SendSeq等于数据量门限时， 可以执 行步骤 S134, 也可以执行步骤 S135 , 理由同以上描述， 在此不再赘述。
S134: 发送所述新确认包；
S135: 暂停发送所述新确认包直至当前发送周期结束， 在下一发送周期 将发送序列号置零后发送所述新确认包。
需要说明的是， 数据传输设备在接收到新确认包时， 其内可能緩存一个 其他确认包， 也可能緩存多个。 即， 所述其他确认包可以是多个也可以是一 个。 且请参考图 14 , 当所述其他确认包为多个时， 以上步骤 S131 , 即发送所 述其他确认包可以包括： 按队列顺序逐一发送所述其他确认包， 且每发送一 个确认包， 重复以下步骤， 直至将所述其他确认包都发送完：
S141 : 更新 SendSeq;
S142: 确定更新后的 SendSeq与数据量门限之间的关系； 如果更新后的 SendSeq小于数据量门限， 执行步骤 S143 , 如果更新后的 SendSeq大于数据量 门限， 则执行步骤 S144。 对于更新后的 SendSeq等于数据量门限时， 可以执行 步骤 S143 , 也可以执行步骤 S144, 理由同以上描述， 在此不再赘述。
S143: 继续发送下一个确认包；
S144: 暂停发送确认包直至当前发送周期结束， 在下一发送周期将发送 序列号置零后继续发送下一个确认包。
关于 SendSeq的更新过程同实施例三， 在此不再赘述。
且在本实施例中， 也可以通过在数据传输设备内设置定时器， 以通过定 时器来实现以上发送周期的控制， 其中， 所述定时器的时长等于所述发送周 期。 需要说明的是， 在以上实施例三和四中， 均在发送周期开始时将 SendSeq 置零， 并以此为基础根据发送确认包反映的已确认的数据量来更新 SendSeq。 其仅为举例， 在其它实施例中， 也可以将 SendSeq置 "Γ 或其它数值， 并据 此调整数据量门限即可， 甚至在 SendSeq置 "1 " 等较小值， 而不影响本发明 效果实现时， 也可以 不调整数据量门限， 总之本发明实施例对此不做任何限 制。
例如， 在本发明实施例五中， 在发送周期开始时， 将 SendSeq设置为数据 量门限， 且在每发送一个确认包之后， 以递减的方式更新 SendSeq, 并在递减 至零或者小于零时， 停止本周期内确认包的发送。 请参考图 15 , 此时， 确认 包的处理方法， 包括以下步骤：
S150: 在发送周期开始时， 将 SendSeq设置为数据量门限；
而后， 在当前发送周期内每发送一个确认包， 更新一次 SendSeq, 且每次 更新 SendSeq之后， 判断更新后的 SendSeq与零之间的关系。 即在当前发送周 期内， 重复执行以下步骤 S151至 S153 , 直至当前发送周期结束或者更新后的 SendSeq小于零。
S151 : 发送确认包；
S152: 更新 SendSeq;
S153 : 确定更新后的 SendSeq与零之间的关系。 如果更新后的 SendSeq大 于零， 则继续执行步骤 S151至 S153 ; 如果更新后的 SendSeq小于零， 则执行步 骤 S154。
S154: 在当前发送周期内暂停发送确认包直至当前发送周期结束， 在下 一个发送周期将 SendSeq设置为数据量门限后继续发送确认包。
此时， SendSeq的更新如下：
更新后的 SendSeq= 更新前的 SendSeq - Max ( 0 , 第一确认包的确认包序 号 - 第二确认包的确认包序号）； 其中， Max ( )表示取最大值， 所述第一确 认包和所述第二确认包为数据传输设备连续向数据发送端发送的两个确认 包， 其中第一确认包为更新 SendSeq之前最近发送的确认包， 第二确认包为在 第一确认包之前发送的确认包。 为了在更新 SendSeq可以使用第二确认包的确 认包序号 ， 需要在发送第二确认包之前存储该确认包序号， 故第二确认包的 确认包序号也即接入网设备已存储的确认包序号。 即， 更新后的 SendSeq = 更 新前的 SendSeq - Max ( 0, 更新发送序列号之前最近发送的确认包的确认包序 号 - 已存储的确认包序号）。
可见， 在 SendSeq的更新过程中， 每发送一个确认包， 则以该确认包的确 认包序号更新已存储的确认包序号。 即， 在更新所述 SendSeq之后， 所述方法 还包括： 更新已存储的确认包的确认包序号； 其中， 更新已存储的确认包序 号同实施例三， 在此不再赘述。
另外， 关于当更新后的 SendSeq等于零的情况， 可以暂停发送确认包直至 当前发送周期结束， 在下一发送周期将发送序列号设置为数据量门限后继续 发送确认包。 也可以继续发送确认包。
请继续参考图 16 , 其为本发明实施例六提供的一种数据传输设备的结构 示意图， 如图 16所示， 该数据传输设备 160包括接收电路 161、 发送电路 162、 存储器 163和处理器 164。 其中， 接收电路 161用于接收确认包； 发送电路 162 用于发送确认包；存储器 163存储数据量门限；处理器 164分别与接收电路 161、 发送电路 162、 存储器 163连接， 处理器 164用于更新数据量门限与总数据量的 差， 所述总数据量为当前发送周期内所有已发送的确认包反映的数据接收端 已确认的总数据量， 且处理器 164还用于根据更新后数据量门限与总数据量的 差控制发送电路 162在当前发送周期内是否继续发送确认包。
可见， 本实施例与实施例一的区别在于处理器 164以数据量门限基础， 更 新数据量门限与总数据量的差， 并根据这个差来控制 162在当前发送周期内是 否继续发送确认包。 由于数据量门限是预设好的， 数据量门限与总数据量的 差的变化实际上就反映了总数据量的变化， 因此， 利用该差控制发送周期内 是否继续发送确认包可以达到与实施例一相同的效果。 相应于实施例六， 本发明实施例七还提供一种确认包的处理方法。 请参 考图 17 , 其为本发明实施例七提供的一种确认包处理方法的流程示意图。 如 图 17所示， 该方法包括如下步骤：
S171 : 发送确认包；
S172: 更新数据量门限与总数据量的差， 所述总数据量为当前发送周期 内所有已发送的确认包反映的数据接收端已确认的总数据量；
S173 : 根据更新后数据量门限与总数据量的差控制在当前发送周期内是 否继续发送确认包。
关于实施例六和七中数据量门限的说明， 同实施例一， 在此不再赘述。 而更新数据量门限与总数据量的差的方式与频率， 例如， 同实施例一的 描述， 在此不再赘述。
下面对处理器 164更新数据量门限与总数据量的差的过程或以上步骤 S172更新总数据量的过程进行说明。
更新数据量门限与总数据量的差， 就是以数据量门限为基础， 更新总数 据量的过程， 而该总数据量的更新同以上实施例一， 且在每次更新总数量之 后， 将数据量门限与总数据量作差， 便可以得到更新后的数据量门限与总数 据量的差。 且， 当当前确认包序号发生绕回时， 同样可以不做更新。
具体， 在发送周期开始时， 可以以数据量门限为基础， 开始进行更新， 且每发送一个确认包， 将该确认包反映的数据接收端所确认的数据量进行递 减， 当递减到零或者接近零时， 停止本发送周期内的确认包发送。 请继续参 考图 18 , 其为本发明实施例八提供的一种数据传输设备的结构示意图。 如图 18所示， 该设备包括发送单元 181、 更新单元 182和控制单元 183 , 其中， 发送 单元 181用于发送确认包； 更新单元 182用于更新当前发送周期内所有已发送 的确认包反映的数据接收端已确认的总数据量； 控制单元 183用于比较更新后 的总数据量与所述数据量门限， 根据比较结果控制在当前发送周期内是否继 续发送确认包。 关于数据量门限的说明， 同实施例一， 在此不再赘述。
另外， 关于更新单元 182的更新过程以及控制单元 183的控制过程， 同实 施例一的描述， 在此不再赘述。
本发明各实施例中的确认包可以为上行确认包， 这里的上行指终端设备 至基站）， 或者终端设备至无线网络控制器（Radio Network Controller, 英文 缩写为 RNC ), 或者终端设备至服务器等。
本发明的一个实施例提供一种确认包的处理方法， 如图 1所示， 所述方法 包括如下步骤。
100、 到达新确认包。
101、第一实体确定是否已緩存有其他确认包，如果已緩存有其他确认包, 则执行步骤 102; 否则， 视不同情况执行步骤 103至步骤 105中的一项。
Figure imgf000018_0001
103、 如果所述第一实体的定时器未启动， 则启动所述定时器， 并发送所 述新确认包。
104、 如果所述第一实体的定时器已启动， 且发送序列号 SendSeq大于确 认包发送门限， 则緩存所述新确认包， 并重启所述定时器， 在所述定时器超 时之前发送所述新确认包。
105、 如果所述第一实体的定时器已启动， 且发送序列号 SendSeq小于或 等于确认包发送门限， 则发送所述新确认包。
其中， 所述 SendSeq为所述第一实体在所述定时器启动后发送的确认包的 总数据量， 所述确认包发送门限为所述第一实体在所述定时器的时长内被允 许发送的确认包的总数据量。
可选的， 在所述定时器启动或重启时， 所述 SendSeq的取值为 0; 在发送 所述新确认包之后， 所述方法还包括： 更新所述 SendSeq。
例如， 如果已緩存有其他确认包， 则緩存所述新确认包包括： 将所述新 确认包緩存在所述其他确认包之后； 所述在发送所述其他确认包之后发送所 述新确认包包括： 在所述第一实体的定时器超时时， 将緩存中的确认包按队 列顺序逐一发送。
可选的， 在步骤 102之后， 所述方法还包括： 每发送一个确认包， 执行一 次更新所述 Sendseq。
可选的， 在步骤 102之后， 所述方法还包括： 每执行一次更新所述 Sendseq 之后， 确定更新后的 Sendseq是否大于所述确认包发送门限； 如果在发送所述 新确认包之前， 更新后的 Sendseq大于所述确认包发送门限， 则停止发送所述 第一实体中已緩存的确认包， 重启所述定时器， 在所述定时器超时之前发送 所述新确认包。
例如， 更新所述 Sendseq时， 更新后的 SendSeq与更新前的 SendSeq之间的 关系为： 更新后的 SendSeq = 更新前的 SendSeq + Max ( 0 , 第一确认包的确认 包序号 - 第二确认包的确认包序号）； 其中， 所述第一确认包和所述第二确认 包为所述第一实体连续发送的前后两个确认包。
进一步的， 在更新所述 SendSeq之后， 所述方法还包括： 更新确认包的确 认包序号； 其中， 更新所述第二确认包的确认包序号时， 如果所述第一确认 包的确认包序号大于所述第二确认包的确认包序号， 或者所述第一确认包的 序号与所述第二确认包的确认包序号的差值小于 -2147483648 , 则将所述第一 确认包的确认包序号作为所述第二确认包的确认包序号； 否则， 将所述第一 实体读取到的所述第二确认包的确认包序号作为所述第二确认包的确认包序 号。 述定时器的时长的乘积， 所述 AvgSendByte是根据聚合最大比特速率 AMBR和 最大吞吐率 MaxThroughput确定的， 其中：
当 MaxThroughput为 0时， AvgSendByte =L。.97xAMBR +8000」， 其中， |_ J符 号位表示向下取整； 当 MaxThroughput不为 0时，
AvgSendByte
Figure imgf000020_0001
(MaxThroughput , AMBR)x0.97 ÷ 8000 J , 其中， |_」符号位表 示向下取整。
其中， 所述定时器的时长为所述第一实体发送确认包的周期， 所述确认 包为不大于 80字节、 且包含确认字符的上行数据包。
进一步的， 当到达新确认包时， 如果不存在用于緩存和发送所述新确认 包的第一实体， 则所述方法还包括： 建立所述第一实体， 所述第一实体位于 基站。
可选的， 本实施例中的第一实体可以是基站， 例如 NodeB、 eNodeB、 HNodeB或 HeNodeB, 也可以是 RNC。
与现有技术相比， 本发明实施例能够在第一实体接收到确认包后， 对确 认包进行处理， 为确认包设置发送周期以及发送数据量门限， 控制每个发送 周期内向服务器发送的确认包的总数据量， 进而控制确认包的数量， 以使确 认包能够以平稳的速率发送到达服务器， 避免因确认包数量突增， 以及由其 导致的下行数据包传输不及时和丟包问题， 进而避免网络吞吐量下降， 并提 高网络传输效率。
本发明的另一个实施例提供一种确认包的处理方法， 如图 2所示， 所述方 法包括如下步骤。
200、 到达新确认包。
201、 第二实体确定是否存在用于緩存和发送所述新确认包的第一实体，， 如果存在所述第一实体， 则执行步骤 202; 否则， 视不同情况执行步骤 203至 步骤 205中的一项。
202、 将所述确认包发送给所述第一实体。
203、 如果不存在所述第一实体， 已存在的第三实体的个数小于第二门限 m, 且已緩存有确认包的第三实体的个数不大于第三门限 n, 则建立所述第一 实体， 并将所述新确认包发送给所述第一实体。 204、 如果不存在所述第一实体， 已存在的第三实体的个数不小于第二门 限 m, 且已緩存有确认包的第三实体的个数不大于第三门限 n, 则删除至少一 个未緩存有确认包的第三实体， 并建立所述第一实体， 将所述新确认包发送 给所述第一实体。
205、 如果不存在所述第一实体， 且已緩存有确认包的第三实体的个数 大于第三门限 n, 向服务器发送所述新确认包。
其中， 所述 m为允许建立的用于緩存和发送确认包的实体的个数上限， 所 述 n为允许同时緩存有确认包的第三实体的个数上限。
可选的， 本实施例中的第一实体可以是基站， 例如 NodeB、 eNodeB、 HNodeB或 HeNodeB, 也可以是 RNC。
与现有技术相比， 本发明实施例能够在有新确认包到达第二实体时， 第 二实体为所述新确认包设置针对新到达的确认包进行判断以决定緩存和 /或发 送等处理方式的第一实体， 通过第一实体对确认包进行处理， 以使确认包能 够以平稳的速率发送到达服务器， 避免因确认包数量突增， 以及由其导致的 下行数据包传输不及时和丟包问题， 进而避免网络吞吐量下降， 并提高网络 传输效率。 本发明的另一个实施例提供一种确认包的处理方法， 该实施例的细节可 视为前两个实施例的举例。 如图 3所示， 所述方法包括如下步骤：
301、 当到达新确认包时， 第二实体确定是否存在用于緩存和发送所述新 确认包的第一实体，如果不存在第一实体，执行步骤 302; 如果存在第一实体， 执行步骤 303。
其中， 确认包应满足三个条件： 数据包的方向为上行； 数据包的大小不 大于 80字节； 数据包包含确认字符（Acknowledgement, 英文缩写为 ACK )。
所述第一实体为基站中处理确认包的操作单元， 实体在被建立时带有源 IP、目的 IP、源端口号、目的端口号、定时器、确认包序号和发送序列号 SendSeq 等参数。 其中， LastSeq表示前面一个被发送的确认包的序号， SendSeq为所述 第一实体在所述定时器启动后发送的确认包的总数据量， 初始化时， 确认包 序号和 SendSeq均为 0。
302、 第二实体为新确认包建立对应的第一实体。
可选的， 所述方法还包括： 如果不存在所述第一实体， 已存在的第三实 体的个数小于第二门限 m,且已緩存有确认包的第三实体的个数不大于第三门 限 n, 则建立所述第一实体， 并将所述新确认包发送给所述第一实体；
如果不存在所述第一实体， 已存在的第三实体的个数不小于第二门限 m, 且已緩存有确认包的第三实体的个数不大于第三门限 n, 则删除至少一个未緩 存有确认包的第三实体， 并建立所述第一实体， 将所述新确认包发送给所述 第一实体。
可选的， 所述方法还包括： 如果不存在所述第一实体， 且已緩存有确认 包的第三实体的个数大于第三门限 n, 向服务器发送所述新确认包；
其中， 所述 m为允许建立的用于緩存和发送确认包的实体的个数上限， 所 述 n为允许同时緩存有确认包的第三实体的个数上限。
303、 第二实体将新确认包发送给第一实体。
304、 当新确认包到达时， 如果第一实体已緩存有其他确认包， 则将新确 认包緩存在其他确认包之后。
305、 第一实体判断定时器是否超时， 如果定时器超时， 执行步骤 307; 如果定时器未超时， 执行步骤 306。
其中， 所述定时器的时长为所述第一实体发送确认包的周期。
306、 第一实体按照队列顺序和发送间隔向服务器发送确认包， 每发送一 个确认包， 执行一次更新所述 Sendseq, 当更新后的 Sendseq大于确认包发送门 限后， 停止发送确认包， 执行步骤 308。
其中， SendSeq为所述第一实体在定时器启动后发送的确认包的总数据 量， 所述确认包发送门限为所述第一实体在所述定时器的时长内被允许发送 的确认包的总数据量， 确认包发送门限的取值为平均发送字节速度
AvgSendByte与所述定时器的时长的乘积， 所述 AvgSendByte是根据聚合最大 比特速率 AMBR和最大吞吐率 MaxThroughput确定的 , 其中：
当 MaxThroughput为 0时， AvgSendByte =L。.97xAMBR +8000」， 其中， |_ J符 号位表示向下取整；
当 MaxThroughput不为 0时，
AvgSendByte
Figure imgf000023_0001
(MaxThroughput , AMBR)x0.97 ÷ 8000 J , 其中， |_」符号位表 示向下取整。
具体的， 更新所述 Sendseq时， 更新后的 SendSeq与更新前的 SendSeq之间 的关系为：
更新后的 SendSeq = 更新前的 SendSeq + Max ( 0 , 第一确认包的确认包序 号 - 第二确认包的确认包序号）； 其中， 所述第一确认包和所述第二确认包为 所述第一实体连续发送的前后两个确认包。
可选的， 在更新所述 SendSeq之后， 还要相应更新确认包的确认包序号； 其中， 更新所述第二确认包的确认包序号时， 如果所述第一确认包的确认包 序号大于所述第二确认包的确认包序号， 或者所述第一确认包的序号与所述 第二确认包的确认包序号的差值小于 -2147483648 , 则将所述第一确认包的确 认包序号作为所述第二确认包的确认包序号； 否则， 将所述第一实体读取到 的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。
307、 第一实体将緩存中的确认包按队列顺序逐一发送给服务器， 每发送 一个确认包， 执行一次更新所述 Sendseq, 直至更新后的 Sendseq大于确认包发 送门限， 停止发送确认包。
308、 第一实体重启所述定时器， 在下一个发送周期发送新确认包。 需要说明的是， 本实施例中的第一实体、 第二实体和第三实体可以均位 于基站。
与现有技术相比， 本发明实施例中当有新确认包到达时， 第二实体查找 或建立第一实体， 将所述新确认包发送给第一实体， 第一实体将所述确认包 緩存在其他确认包之后进行发送， 同时为确认包设置发送周期以及发送数据 量门限， 控制每个发送周期内向服务器发送的确认包的总数据量， 进而控制 确认包的数量， 以使确认包能够以平稳的速率发送到达服务器， 避免因确认 包数量突增， 以及由其导致的下行数据包传输不及时和丟包问题， 进而避免 网络吞吐量下降， 并提高网络传输效率。 本发明的另一个实施例提供一种确认包的处理方法， 该实施例与上一实 施例相比区别在于， 当有新确认包到达第一实体时， 第一实体没有緩存其他 确认包， 并且未启动定时器， 如图 4所示， 所述方法包括如下步骤：
401、 第二实体将新确认包发送给第一实体。
其中， 第一实体的查找与建立过程参照上一实施例的步骤 301-步骤 302。
402、 当新确认包到达时， 如果第一实体未緩存有其他确认包， 且第一实 体的定时器未启动， 则向服务器发送新确认包， 并更新发送序列号 SendSeq。
其中， 所述定时器的时长为所述第一实体发送确认包的周期， 所述 SendSeq为所述第一实体在所述定时器启动后发送的确认包的总数据量。 具体 的， 更新所述 Sendseq时， 更新后的 SendSeq与更新前的 SendSeq之间的关系为： 更新后的 SendSeq = 更新前的 SendSeq + Max ( 0 , 第一确认包的确认包序 号 - 第二确认包的确认包序号）； 其中， 所述第一确认包和所述第二确认包为 所述第一实体连续发送的前后两个确认包。
可选的， 在更新所述 SendSeq之后， 还要相应更新确认包的确认包序号； 其中， 更新所述第二确认包的确认包序号时， 如果所述第一确认包的确认包 序号大于所述第二确认包的确认包序号， 或者所述第一确认包的序号与所述 第二确认包的确认包序号的差值小于 -2147483648 , 则将所述第一确认包的确 认包序号作为所述第二确认包的确认包序号； 否则， 将所述第一实体读取到 的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。 需要说明的是， 本实施例中的第一实体、 第二实体和第三实体可以均位 于基站。
与现有技术相比， 本发明实施例中当有新确认包到达时， 第二实体查找 或建立第一实体， 将所述新确认包发送给第一实体， 第一实体在没有緩存其 他确认包且没有启动定时器时， 为所述新确认包启动定时器， 并将所述新确 认包发送给服务器， 同时为确认包设置发送周期以及发送数据量门限， 控制 每个发送周期内向服务器发送的确认包的总数据量， 进而控制确认包的数量， 以使确认包能够以平稳的速率发送到达服务器， 避免因确认包数量突增， 以 及由其导致的下行数据包传输不及时和丟包问题， 进而避免网络吞吐量下降， 并提高网络传输效率。 本发明的另一个实施例提供一种确认包的处理方法， 该实施例与前两个 实施例相比区别在于， 当有新确认包到达第一实体时， 第一实体没有緩存其 他确认包， 并且定时器已启动， 如图 5所示， 所述方法包括如下步骤：
501、 第二实体将新确认包发送给第一实体。
其中，第一实体的查找与建立过程参照第三个实施例的步骤 301-步骤 302。
502、 当新确认包到达时， 如果第一实体未緩存有其他确认包， 且第一实 体的定时器已启动， 第一实体确定发送序列号 SendSeq是否大于确认包发送门 限， 如果 SendSeq大于确认包发送门限， 执行步骤 506; 如果 SendSeq不大于确 认包发送门限， 执行步骤 505。
其中， 所述 SendSeq为所述第一实体在所述定时器启动后发送的确认包的 总数据量， 所述确认包发送门限为所述第一实体在所述定时器的时长内被允 许发送的确认包的总数据量， 所述定时器的时长为所述第一实体发送确认包 的周期。 述定时器的时长的乘积： 所述 AvgSendByte是根据聚合最大比特速率 AMBR和 最大吞吐率 MaxThroughput确定的， 其中：
当 MaxThroughput为 0时， AvgSendByte =L0.97xAMBR +8000」， 其中， LJ符 号位表示向下取整；
当 MaxThroughput不为 0时，
AvgSendByte
Figure imgf000026_0001
(MaxThroughput , AMBR)x0.97 ÷ 8000 J , 其中， |_」符号位表 示向下取整。
503、 第一实体向服务器发送新确认包， 并更新发送序列号 SendSeq。 可选的，如果更新后的 SendSeq大于发送门限，则停止发送后续的确认包。 例如， 更新后的 SendSeq = 更新前的 SendSeq + Max ( 0 , 第一确认包的确 认包序号 - 第二确认包的确认包序号）； 其中， 所述第一确认包和所述第二确 认包为所述第一实体连续发送的前后两个确认包。
可选的， 在更新所述 SendSeq之后， 还要相应更新确认包的确认包序号； 其中， 更新所述第二确认包的确认包序号时， 如果所述第一确认包的确认包 序号大于所述第二确认包的确认包序号， 或者所述第一确认包的序号与所述 第二确认包的确认包序号的差值小于 -2147483648 , 则将所述第一确认包的确 认包序号作为所述第二确认包的确认包序号； 否则， 将所述第一实体读取到 的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。
504、 第一实体緩存所述新确认包， 并重启所述定时器， 在所述定时器超 时之前发送所述新确认包。
需要说明的是， 本实施例中的第一实体、 第二实体和第三实体可以均位 于基站。
与现有技术相比， 本发明实施例中当有新确认包到达时， 第二实体查找 或建立第一实体， 将所述新确认包发送给第一实体， 第一实体在没有緩存其 他确认包并且已经启动定时器后， 确定当前的发送序列号 Sendseq是否超过了 数据量门限， 如果没有超过门限则直接发送新确认包， 如果超过门限则重启 定时器， 在下一个发送周期发送新确认包。 通过控制每个发送周期内向服务 器发送的确认包的总数据量， 进而控制确认包的数量， 以使确认包能够以平 稳的速率发送到达服务器， 避免因确认包数量突增， 以及由其导致的下行数 据包传输不及时和丟包问题， 进而避免网络吞吐量下降， 并提高网络传输效 率。 例说明。 为描述方便， 下述举例涉及的可选描述和细节描述等未作详细说明， 可参照上述方法实施例中的举例。 本发明的另一个实施例提供一种确认包的处理设备， 如图 6所示， 所述设 备包括第一接收器 61、 第一处理器 62、 存储器 63、 第一发送器 64和定时器 65 , 其中：
所述第一接收器 61用于接收确认包；
所述存储器 63用于緩存所述第一接收器 61接收的确认包；
所述第一发送器 64用于发送所述存储器 63緩存的确认包；
所述第一处理器 62用于当新确认包到达所述第一接收器 61时， 如果确定 所述存储器 63已緩存有其他确认包， 则触发所述存储器 63緩存所述新确认包， 者， 当新确认包到达所述第一接收器 61时， 如果确定所述存储器 63未緩存有 其他确认包， 且所述定时器 65未启动， 则触发所述定时器 65启动， 并触发所 述第一发送器 64发送所述新确认包； 或者， 当新确认包到达所述第一接收器 61时， 如果确定所述存储器 63未緩存有其他确认包， 所述定时器 65已启动， 且发送序列号 SendSeq大于确认包发送门限， 则触发所述存储器 63緩存所述新 确认包， 触发所述定时器 65重启， 以及命令所述第一发送器 64在所述定时器 65超时之前发送所述新确认包； 或者， 当新确认包到达所述第一接收器 61时， 如果确定所述存储器 63未緩存有其他确认包， 所述定时器 65已启动， 且发送 序列号 SendSeq小于或等于确认包发送门限， 则触发所述第一发送器 64发送所 述新确认包；
其中， 所述 SendSeq为所述定时器 65启动后发送的确认包的总数据量， 所 述确认包发送门限为在所述定时器 65的时长内被允许发送的确认包的总数据 量。
可选的， 所述第一处理器 62还用于： 在所述第一发送器 64发送所述新确 认包之后， 更新所述 SendSeq。
例如， 所述存储器 63具体用于： 将所述新确认包緩存在所述其他确认包 之后； 所述第一发送器 64具体用于： 在所述定时器 65超时时， 将所述存储器 63中緩存的确认包按队列顺序逐一发送。
可选的， 所述第一处理器 62还用于： 在所述第一发送器 64发送每发送一 个确认包之后， 执行一次更新所述 Sendseq。
可选的， 所述第一处理器 62还用于： 每执行一次更新所述 Sendseq之后， 确定更新后的 Sendseq是否大于所述确认包发送门限； 当所述第一发送器 64发 送所述新确认包之前， 所述第一处理器 62更新后的 Sendseq大于所述确认包发 送门限时， 触发所述第一发送器 64停止发送所述第一实体中已緩存的确认包， 触发所述定时器 65重启， 并命令所述第一发送器 64在所述定时器 65超时之前， 发送所述新确认包。
可选的， 所述第一处理器 62还用于： 更新确认包的确认包序号； 其中， 更新所述第二确认包的确认包序号时， 如果所述第一确认包的确认包序号大 于所述第二确认包的确认包序号， 或者所述第一确认包的序号与所述第二确 认包的确认包序号的差值小于 -2147483648 , 则将所述第一确认包的确认包序 号作为所述第二确认包的确认包序号； 否则， 将所述第一实体读取到的所述 第二确认包的确认包序号作为所述第二确认包的确认包序号。
其中， 所述定时器 65的时长为发送确认包的周期。
需要说明的是， 本实施例中的设备可以是基站， 例如 NodeB、 eNodeB、 HNodeB或 HeNodeB, 也可以是 RNC。 与现有技术相比， 本发明实施例能够在第一实体接收到确认包后， 对确 认包进行处理， 为确认包设置发送周期以及发送数据量门限， 控制每个发送 周期内向服务器发送的确认包的总数据量， 进而控制确认包的数量， 以使确 认包能够以平稳的速率发送到达服务器， 避免因确认包数量突增， 以及由其 导致的下行数据包传输不及时和丟包问题， 进而避免网络吞吐量下降， 并提 高网络传输效率。 本发明的另一个实施例提供一种确认包的处理设备， 如图 7所示， 所述设 备包括第二接收器 71、 第二处理器 72和第二发送器 73 , 其中：
所述第二接收器 71用于接收确认包；
所述第二发送器 73用去向第一实体发送所述第二接收器 71接收的确认 包， 所述第一实体用于緩存和发送所述新确认包给服务器；
所述第二处理器 72用于当新确认包到达所述第二接收器 71时， 如果确定 存在所述第一实体， 则触发所述第二发送器 73将所述确认包发送给所述第一 实体； 或者， 当新确认包到达所述第二接收器 71时， 如果确定不存在所述第 一实体， 已存在的第三实体的个数小于第二门限 m, 且已緩存有确认包的第三 实体的个数不大于第三门限 n, 则建立所述第一实体， 并触发所述第二发送器 73将所述新确认包发送给所述第一实体； 或者， 当新确认包到达所述第二接 收器 71时， 如果确定不存在所述第一实体， 已存在的第三实体的个数不小于 第二门限 m, 且已緩存有确认包的第三实体的个数不大于第三门限 n, 则删除 至少一个未緩存有确认包的第三实体， 建立所述第一实体， 并触发所述第二 发送器 73将所述新确认包发送给所述第一实体； 或者， 当新确认包到达所述 第二接收器 71时， 如果确定不存在所述第一实体， 且已緩存有确认包的第三 实体的个数大于第三门限 n, 则触发所述第二发送器 73向服务器发送所述新确 认包；
其中， 所述 m为允许建立的用于緩存和发送确认包的实体的个数上限， 所 述 n为允许同时緩存有确认包的第三实体的个数上限。
需要说明的是， 本实施例中的设备可以是基站， 例如 NodeB、 eNodeB、 HNodeB或 HeNodeB, 也可以是 RNC。
与现有技术相比， 本发明实施例能够在有新确认包到达第二实体时， 第 二实体为所述新确认包设置针对新到达的确认包进行判断以决定緩存和 /或发 送等处理方式的第一实体， 通过第一实体对确认包进行处理， 以使确认包能 够以平稳的速率发送到达服务器， 避免因确认包数量突增， 以及由其导致的 下行数据包传输不及时和丟包问题， 进而避免网络吞吐量下降， 并提高网络 传输效率。 例， 具体功能实现请参见方法实施例中的说明， 在此不再赘述。 本发明实施 例提供的确认包的处理方法及设备可以适用于 TCP传输业务中的数据传输，但 不仅限于此。
本发明实施例还提供一种系统，可以包括上述如图 6所示的设备和 /或如图 7所示的设备。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流 程， 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储于 一计算机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施 例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（ Read-Only Memory, ROM )或随机存 己忆体 ( Random Access Memory, RAM )等。
以上所述， 仅为本发明的具体实施方式， 但本发明的保护范围并不局限 于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易 想到的变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的保 护范围应该以权利要求的保护范围为准。

Claims

权 利 要求 书
1、 一种确认包的处理方法， 其特征在于， 包括：
发送确认包；
更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数 据量；
比较更新后的总数据量与所述数据量门限；
根据比较结果控制在当前发送周期内是否继续发送确认包。
2、 根据权利要求 1所述的方法， 其特征在于， 更新当前发送周期内所有已 发送的确认包反映的数据接收端已确认的总数据量， 包括：
根据确认包的确认包序号， 更新所述总数据量， 其中， 当当前发送的确认包 的确认包序号发生绕回时， 保持所述总数据量不变。
3、 根据权利要求 2所述的方法， 其特征在于， 根据确认包的确认包序号， 更新所述总数据量， 包括：
根据当前发送的确认包的确认包序号与上一个发送的确认包的确认包序号 之差， 确定当前发送的确认包反映的数据接收端所确认的数据量；
根据所述当前发送的确认包反映的数据接收端所确认的数据量， 更新所述 总数据量。
4、 根据权利要求 1至 3任一项所述的方法， 其特征在于， 根据比较结果控制 在当前发送周期内是否继续发送确认包， 包括：
当更新后的总数据量大于所述数据量门限时， 控制在当前发送周期内停止 发送确认包；
当更新后的总数据量小于所述数据量门限时， 控制在当前发送周期内继续 发送确认包；
当更新后的总数据量等于所述数据量门限时， 控制在当前发送周期内停止 或继续发送确认包。
5、 根据权利要求 1至 4任一项所述的方法， 其特征在于， 所述数据量门限根 据承载网络的承载能力确定。
6、 一种数据传输设备， 其特征在于， 包括：
接收电路， 用于接收确认包；
发送电路， 用于发送确认包；
存储器， 存储数据量门限；
处理器， 分别与所述接收电路、 发送电路、 存储器连接， 用于更新当前发 送周期内所有已发送的确认包反映的数据接收端已确认的总数据量， 且比较更 新后的总数据量与所述数据量门限， 根据比较结果控制所述发送电路在当前发 送周期内是否继续发送确认包。
7、 根据权利要求 6所述的设备， 其特征在于， 所述处理器更新所述总数据 量， 包括：
根据确认包的确认包序号， 更新所述总数据量， 其中， 当当前发送的确认包 的确认包序号发生绕回时， 保持所述总数据量不变。
8、 根据权利要求 7所述的设备， 其特征在于， 所述处理器根据确认包的确 认包序号， 更新所述总数据量， 包括：
根据当前发送的确认包的确认包序号与上一个发送的确认包的确认包序号 之差， 确定当前发送的确认包反映的数据接收端所确认的数据量；
根据所述当前发送的确认包反映的数据接收端所确认的数据量， 更新所述 总数据量。
9、 根据权利要求 6至 8任一项所述的设备， 其特征在于， 所述处理器根据比 较结果控制所述发送电路在当前发送周期内是否继续发送确认包， 包括：
当更新后的总数据量大于所述数据量门限时， 控制所述发送电路在当前发 送周期内停止发送确认包；
当更新后的总数据量小于所述数据量门限时， 控制所述发送电路在当前发 送周期内继续发送确认包；
当更新后的总数据量等于所述数据量门限时， 控制所述发送电路在当前发 送周期内停止或继续发送确认包。
10、 根据权利要求 6至 9任一项所述的设备， 其特征在于， 所述数据量门限 根据承载网络的承载能力确定。
11、 一种数据传输设备， 其特征在于， 包括：
发送单元， 用于发送确认包；
更新单元， 用于更新当前发送周期内所有已发送的确认包反映的数据接收 端已确认的总数据量；
控制单元， 用于比较更新后的总数据量与所述数据量门限， 根据比较结果 控制在当前发送周期内是否继续发送确认包。
12、 根据权利要求 11所述的设备， 其特征在于， 所述更新单元具体用于根 据确认包的确认包序号， 更新所述总数据量， 其中， 当当前发送的确认包的确认 包序号发生绕回时， 保持所述总数据量不变。
13、 根据权利要求 11所述的设备， 其特征在于， 所述更新单元具体用于： 根据当前发送的确认包的确认包序号与上一个发送的确认包的确认包序号 之差， 确定当前发送的确认包反映的数据接收端所确认的数据量；
根据所述当前发送的确认包反映的数据接收端所确认的数据量， 更新所述 总数据量。
14、 根据权利要求 11至 13任一项所述的设备， 其特征在于， 所述控制单元 具体用于：
当更新后的总数据量大于所述数据量门限时， 控制在当前发送周期内停止 发送确认包；
当更新后的总数据量小于所述数据量门限时， 控制在当前发送周期内继续 发送确认包；
当更新后的总数据量等于所述数据量门限时， 控制在当前发送周期内停止 或继续发送确认包。
15、 根据权利要求 11至 14任一项所述的设备， 其特征在于， 所述数据量门 限根据承载网络的承载能力确定。
16、 一种通信系统， 其特征在于， 包括数据发送端、 数据接收端以及如权 利要求 6至 15任一项所述的数据传输设备， 其中所述数据发送端通过所述数据传 输设备与数据接收端进行通信。
17、 一种计算机程序产品， 包括计算机可读介质， 所述计算机可读介质包 括一组程序代码， 用于执行如权利要求 1-5中任意一项所述的方法。
PCT/CN2012/087791 2012-03-21 2012-12-28 确认包的处理方法、设备及系统 WO2013139165A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP12871880.6A EP2819360B1 (en) 2012-03-21 2012-12-28 Acknowledgement packet processing method, device and system
KR1020147029217A KR101607583B1 (ko) 2012-03-21 2012-12-28 수신확인 패킷 처리 방법, 장치 및 시스템
CN201280070272.8A CN104137495B (zh) 2012-03-21 2012-12-28 确认包的处理方法、设备及系统
JP2015500748A JP5928764B2 (ja) 2012-03-21 2012-12-28 肯定応答パケットを処理するための方法、装置、およびシステム
US14/491,744 US9602410B2 (en) 2012-03-21 2014-09-19 Method, device, and system for processing acknowledgement packet

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNPCT/CN2012/072726 2012-03-21
PCT/CN2012/072726 WO2013139010A1 (zh) 2012-03-21 2012-03-21 确认包的处理方法、设备及系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/491,744 Continuation US9602410B2 (en) 2012-03-21 2014-09-19 Method, device, and system for processing acknowledgement packet

Publications (1)

Publication Number Publication Date
WO2013139165A1 true WO2013139165A1 (zh) 2013-09-26

Family

ID=49221810

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/CN2012/072726 WO2013139010A1 (zh) 2012-03-21 2012-03-21 确认包的处理方法、设备及系统
PCT/CN2012/087791 WO2013139165A1 (zh) 2012-03-21 2012-12-28 确认包的处理方法、设备及系统

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/072726 WO2013139010A1 (zh) 2012-03-21 2012-03-21 确认包的处理方法、设备及系统

Country Status (6)

Country Link
US (1) US9602410B2 (zh)
EP (1) EP2819360B1 (zh)
JP (1) JP5928764B2 (zh)
KR (1) KR101607583B1 (zh)
CN (2) CN103548297A (zh)
WO (2) WO2013139010A1 (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9998360B2 (en) 2014-11-17 2018-06-12 Honeywell International Inc. Minimizining message propagation times when brief datalink interruptions occur
US9660719B2 (en) * 2014-11-17 2017-05-23 Honeywell International Inc. Minimizing propagation times of queued-up datalink TPDUs
GB2544321A (en) * 2015-11-12 2017-05-17 Vodafone Ip Licensing Ltd Router and message handler for providing scalable receipts of control messages
CN106411774A (zh) * 2016-09-06 2017-02-15 联动优势科技有限公司 一种控制交易数据量的方法和装置
JP6620891B2 (ja) * 2017-04-12 2019-12-18 住友電気工業株式会社 中継装置、中継方法、およびコンピュータプログラム
CN108307426A (zh) * 2017-12-19 2018-07-20 上海华为技术有限公司 一种基于无线tcp的资源调度方法和装置
CN108777607B (zh) * 2018-04-23 2021-08-31 上海华为技术有限公司 一种拦截确认包的方法以及接入网设备
CN108391289B (zh) * 2018-05-31 2021-05-18 京信通信系统（中国）有限公司 一种拥塞控制方法和基站
CN111726379B (zh) * 2019-03-20 2021-11-19 华为技术有限公司 一种通信方法及装置
CN113965307A (zh) * 2020-07-20 2022-01-21 广州汽车集团股份有限公司 一种基于仲裁线的全双工spi通信方法
CN113852445B (zh) * 2021-08-27 2023-06-16 山东云海国创云计算装备产业创新中心有限公司 一种提高数据传输可靠性的方法、系统、设备和存储介质
CN116261848A (zh) * 2021-09-02 2023-06-13 苹果公司 用于新无线电的无线电链路控制累积模式

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006027672A2 (en) * 2004-09-10 2006-03-16 Nortel Networks System and method for adaptive frame size management in a wireless multihop network
CN1989721A (zh) * 2004-06-16 2007-06-27 高通股份有限公司 用于无线通信中的链路控制的方法和设备
CN101090338A (zh) * 2006-06-14 2007-12-19 国际商业机器公司 用于对确认进行过滤的方法、系统和设备

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2853701B2 (ja) * 1997-03-18 1999-02-03 日本電気株式会社 Ａｔｍ網における端末間フロー制御方法
US6252851B1 (en) * 1997-03-27 2001-06-26 Massachusetts Institute Of Technology Method for regulating TCP flow over heterogeneous networks
US6215769B1 (en) * 1998-10-07 2001-04-10 Nokia Telecommunications, Inc. Enhanced acknowledgment pacing device and method for TCP connections
US6438108B1 (en) * 1999-03-11 2002-08-20 Telefonaktiebolaget L M Ericsson (Publ) System for improved transmission of acknowledgements within a packet data network
US6424626B1 (en) * 1999-10-29 2002-07-23 Hubbell Incorporated Method and system for discarding and regenerating acknowledgment packets in ADSL communications
US7000021B1 (en) * 2001-10-12 2006-02-14 Cisco Technology, Inc. ARQ (automatic repeat request) for broadband fixed wireless network
KR100419280B1 (ko) * 2001-10-26 2004-02-18 한국전자통신연구원 무선 링크의 상태에 따른 스누프 프로토콜의 간접 승인방법 및 이 방법을 수행하는 유무선 통합 망의 패킷 전송장치
CN1175624C (zh) 2001-11-01 2004-11-10 智邦科技股份有限公司 应用后确认控制进行tcp通信量的带宽管理装置及方法
JP4283589B2 (ja) * 2003-03-25 2009-06-24 株式会社エヌ・ティ・ティ・ドコモ 通信装置、通信制御方法及びプログラム
JP2004364217A (ja) * 2003-06-09 2004-12-24 Matsushita Electric Ind Co Ltd パケット通信装置
WO2005006673A1 (ja) * 2003-07-15 2005-01-20 Fujitsu Limited 帯域制御装置
US20070008884A1 (en) * 2003-10-08 2007-01-11 Bob Tang Immediate ready implementation of virtually congestion free guarantedd service capable network
US7639656B2 (en) 2004-04-28 2009-12-29 Symbol Technologies, Inc. Protocol for communication between access ports and wireless switches
CN1838583A (zh) * 2005-03-25 2006-09-27 松下电器产业株式会社 多入多出通信系统中执行数据重传的方法和设备
US7782901B2 (en) * 2007-01-09 2010-08-24 Alcatel-Lucent Usa Inc. Traffic load control in a telecommunications network
US8369348B2 (en) * 2008-01-28 2013-02-05 Broadcom Corporation Method, and system, and computer program product for dynamically adjusting acknowledgement filtering for high-latency environments
JP4513036B2 (ja) 2008-04-04 2010-07-28 ソニー株式会社 送信装置および方法、並びにプログラム
JP5185735B2 (ja) * 2008-08-28 2013-04-17 京セラ株式会社 無線通信装置および無線通信方法
CN101925195A (zh) * 2009-06-17 2010-12-22 中兴通讯股份有限公司 基于rlc协议确认模式中确认信息的处理方法及系统
JP2011193046A (ja) * 2010-03-11 2011-09-29 Mitsubishi Electric Corp 無線通信装置および優先制御方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1989721A (zh) * 2004-06-16 2007-06-27 高通股份有限公司 用于无线通信中的链路控制的方法和设备
WO2006027672A2 (en) * 2004-09-10 2006-03-16 Nortel Networks System and method for adaptive frame size management in a wireless multihop network
CN101090338A (zh) * 2006-06-14 2007-12-19 国际商业机器公司 用于对确认进行过滤的方法、系统和设备

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN104137495A (zh) 2014-11-05
CN104137495B (zh) 2017-10-27
JP5928764B2 (ja) 2016-06-01
KR20140146125A (ko) 2014-12-24
US9602410B2 (en) 2017-03-21
EP2819360A1 (en) 2014-12-31
EP2819360B1 (en) 2017-04-26
WO2013139010A1 (zh) 2013-09-26
JP2015512572A (ja) 2015-04-27
US20150023167A1 (en) 2015-01-22
CN103548297A (zh) 2014-01-29
KR101607583B1 (ko) 2016-03-30
EP2819360A4 (en) 2015-01-21

Similar Documents

Publication Publication Date Title
WO2013139165A1 (zh) 确认包的处理方法、设备及系统
US8014287B2 (en) Communications apparatus
CN111683019B (zh) 在通信设备中管理待发送的确认数据包
US20120201136A1 (en) Mechanisms to improve the transmission control protocol performance in wireless networks
US10111130B2 (en) Supporting delivery of data packets using transmission control protocol in a wireless communication network
US11671377B2 (en) System and method for reducing bandwidth usage of a network
WO2012126424A2 (zh) 一种数据包的转发方法和设备
US10524175B2 (en) Data transmission method and network device
CN113840342B (zh) 数据前转、重传方法及装置
CN107852372B (zh) 数据分组网络
JP2020507963A (ja) データ送信方法および装置、ならびに顧客宅内機器
CN111132225B (zh) 一种am模式下的rlc实体的接收侧及其接收数据的方法
WO2022183890A1 (zh) 帧抢占方法、装置、设备和存储介质
JP2006504290A (ja) Ｎａｃｋプロトコルの方法および装置
WO2016080871A1 (en) Active queue management for a wireless communication network
JP6010502B2 (ja) パケット処理方法及びパケット処理装置
KR101231793B1 (ko) Ｔｃｐ 세션 최적화 방법 및 네트워크 노드
JP2006279867A (ja) Ａｄｓｌ通信装置、プログラム及び方法
KR101685658B1 (ko) Yellow-Light TCP : 모바일 데이터 전송에서의 에너지 절감형 프로토콜 방법
WO2017051860A1 (ja) データ通信装置、データ通信制御方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12871880

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015500748

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2012871880

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2012871880

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20147029217

Country of ref document: KR

Kind code of ref document: A