CN104641719B - 一种确认报文发送方法及其设备 - Google Patents

一种确认报文发送方法及其设备 Download PDF

Info

Publication number
CN104641719B
CN104641719B CN201380001014.9A CN201380001014A CN104641719B CN 104641719 B CN104641719 B CN 104641719B CN 201380001014 A CN201380001014 A CN 201380001014A CN 104641719 B CN104641719 B CN 104641719B
Authority
CN
China
Prior art keywords
rlc
tcp acknowledgment
acknowledgment message
tcp
communication equipment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201380001014.9A
Other languages
English (en)
Other versions
CN104641719A (zh
Inventor
庞伶俐
郑潇潇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN104641719A publication Critical patent/CN104641719A/zh
Application granted granted Critical
Publication of CN104641719B publication Critical patent/CN104641719B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • 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
    • 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
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

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

一种确认报文发送方法及其设备，用以减少空口确认报文的发送，提高空口的资源利用效率。通信设备的RLC协议实体单元接收到所述通信设备的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；所述通信设备的RLC协议实体单元接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备的TCP协议实体单元发送TCP确认报文。

Description

一种确认报文发送方法及其设备
技术领域
本发明涉及无线通信技术领域，尤其涉及一种确认报文发送方法及其设备。
背景技术
在数据无线传输的过程中，网络侧设备和用户侧设备一般遵循数据传输的分层模型，即，应用层、传输控制（Transfer Control Protocol，TCP）层、网络层、无线链路控制（Radio link Control，RLC）层、MAC（Media Access Control，媒体接入控制）层和物理（Physical，PHY）层。当网络侧设备向用户侧设备发送数据时，数据从网络侧设备的应用层出发，经网络侧设备的传输控制层、网络层、无线链路控制层、媒体接入控制层和物理层后，经由传输链路到用户侧设备的物理层，并经由用户侧设备的无线链路控制层和网络层，最后到达用户侧设备的应用层，反之亦然。
为避免在传输过程中出现数据缺失或数据错误的情况，在上述数据传输的过程中引入接收数据确认机制，其中TCP层的确认是为了确保TCP数据包传输的正确性，RLC层的确认是为了保证数据包在RLC层接收的正确性。在具备RLC和TCP两层确认的条件下，一个数据包传输的流程如图1所示。
目前TCP确认报文（TCP ACK；ACK：Aacknowledgement，确认）的发送具有两种形式：捎带发送（即与数据包一起发送）和单独发送（即TCP确认报文中不包含数据，只有头信息）。TCP数据包头的格式如图2所示，其中4bit（比特）的头部长度指示了TCP包头中32bit信息出现的数目，TCP包头最多为60byte（字节），通常为20byte。
在一次数据包传输时，采用RLC-AM模式（即RLC确认模式；AM：Acknowledged Mode，确认模式），接收端的RLC层和TCP层可能都会发送确认报文，并且TCP确认报文的接收还可能会再次触发RLC确认报文的发送。在单个数据包传输尤其是单个小数据包传输时上述一个应用层数据包最多对应3个空口（Air Interface，空中接口，即移动终端与基站之间的接口）的确认报文，其中出现单独的TCP确认报文时，数据包较大，导致对空口资源的浪费，并且大量的确认报文对其它通信数据形成干扰。
发明内容
本发明实施例提供了一种确认报文发送方法及其设备，用以减少空口确认报文的发送，提高空口的资源利用效率。
第一方面，提供一种确认报文发送方法，所述方法包括：
通信设备的RLC协议实体单元接收到所述通信设备的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；所述通信设备的RLC协议实体单元接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备的TCP协议实体单元发送TCP确认报文。
结合第一方面，在第一种可能的实现方式中，所述通信设备的RLC协议实体单元接收到所述通信设备的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文之后，还包括：所述通信设备的RLC协议实体单元向对端通信设备发送RLC确认报文。
结合第一方面，在第二种可能的实现方式中，根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，具体包括：若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备。
结合第一方面的第二种可能的实现方式，在第一种可能的实现方式中，所述通信设备的RLC协议实体单元接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备的TCP协议实体单元发送TCP确认报文，具体包括：所述通信设备的RLC协议实体单元接收对端通信设备的RLC协议实体单元发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述通信设备的TCP协议实体单元发送TCP确认报文。
结合第一方面，在第三种可能的实现方式中，根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，具体包括：若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备。
结合第一方面的第三种可能的实现方式，在第一种可能的实现方式中，所述方法还包括：若所述通信设备的RLC协议实体单元确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
结合第一方面，在第四种可能的实现方式中，根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，具体包括：所述通信设备的RLC协议实体单元在发送RLC确认报文的时机到达时，若当前缓存有从所述通信设备的TCP协议实体单元接收到的未携带有数据信息的TCP确认报文，则确定不向对端通信设备发送TCP确认报文，并将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
第二方面，提供一种通信设备，包括：TCP协议实体单元和RLC协议实体单元；
所述TCP协议实体单元，用于向所述RLC协议实体单元发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收所述RLC协议实体单元发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
所述RLC协议实体单元，用于接收到所述TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；以及，接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述TCP协议实体单元发送TCP确认报文。
结合第二方面，在第一种可能的实现方式中，所述RLC协议实体单元具体进一步用于，在接收到所述TCP协议实体单元发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文。
结合第二方面，在第二种可能的实现方式中，所述RLC协议实体单元具体用于，若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备。
结合第二方面的第二种可能的实现方式，在第一种可能的实现方式中，所述RLC协议实体单元具体用于，接收到对端通信设备的RLC协议实体单元发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述TCP协议实体单元发送TCP确认报文。
结合第二方面，在第三种可能的实现方式中，所述RLC协议实体单元具体用于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备。
结合第二方面的第三种可能的实现方式，在第一种可能的实现方式中，所述RLC协议实体单元还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
结合第二方面，在第四种可能的实现方式中，所述RLC协议实体单元具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从所述TCP协议实体单元接收到的未携带有数据信息的TCP确认报文，则确定不向对端通信设备发送TCP确认报文，并将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
第三方面，提供了一种通信设备，该通信设备包括：接口模块、存储器和处理器，所述接口模块与所述处理器连接，所述处理器与所述存储器连接，其中：
接口模块，用于接收对端通信设备发送的报文，发送给所述处理器；或者，接收所述处理器发送的报文，向对端通信设备发送；
存储器，用于存储所述处理器进行数据处理过程中生成的临时数据或中间数据；
处理器，用于根据数据传输模型中定义的各层协议对传输的数据进行处理，其中包括TCP协议实体单元和RLC协议实体单元，其中：
所述TCP协议实体单元，用于向所述RLC协议实体单元发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收所述RLC协议实体单元发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
所述RLC协议实体单元，用于接收到所述TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；以及，接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述TCP协议实体单元发送TCP确认报文。
结合第三方面，在第一种可能的实现方式中，所述RLC协议实体单元具体进一步用于，在接收到所述TCP协议实体单元发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文。
结合第三方面，在第二种可能的实现方式中，所述RLC协议实体单元具体用于，若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备。
结合第三方面的第二种可能的实现方式，在第一种可能的实现方式中，所述RLC协议实体单元具体用于，接收到对端通信设备的RLC协议实体单元发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述TCP协议实体单元发送TCP确认报文。
结合第三方面，在第三种可能的实现方式中，所述RLC协议实体单元具体用于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备。
结合第三方面的第三种可能的实现方式，在第一种可能的实现方式中，所述RLC协议实体单元还用于，若确认当前接收到的TCP确认报文所对应的所有RLC确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送。
结合第三方面，在第四种可能的实现方式中，所述RLC协议实体单元具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从所述TCP协议实体单元接收到的未携带有数据信息的TCP确认报文，则确定不向对端通信设备发送TCP确认报文，并将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
第四方面，提供了一种通信设备，包括：收发器和处理器；
所述收发器，用于向所述处理器发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收所述处理器发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
所述处理器，用于接收到所述收发器发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；
所述收发器，还用于接收到对端通信设备发送的RLC确认报文后，若所述处理器根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述收发器发送TCP确认报文。
结合第四方面，在第一种可能的实现方式中，所述处理器还用于，在接收到所述收发器发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文。
结合第四方面，在第二种可能的实现方式中，所述处理器具体用于，若当前时刻是RLC确认报文的发送时机，则将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中通过所述收发器发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后通过所述收发器发送给对端通信设备。
结合第四方面的第二种可能的实现方式，在第一种可能的实现方式中，所述处理器具体用于，接收到对端通信设备发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述收发器发送TCP确认报文。
结合第四方面，在第三种可能的实现方式中，所述处理器具体用于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文通过所述收发器发送给对端通信设备。
结合第四方面的第三种可能的实现方式，在第一种可能的实现方式中，所述处理器还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，通过所述收发器将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
结合第四方面，在第五中可能的实现方式中，所述处理器具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从所述收发器接收到的未携带有数据信息的TCP确认报文，则将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中通过所述收发器发送给对端通信设备。
结合第四方面的第一、第二、第三、第四或第五种可能的实现方式，在第一种可能的实现方式中，所述处理器具体用于，若根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则通过所述收发器向所述通信设备的收发器发送所述已经正确接收的TCP数据包的TCP确认报文。
结合第四方面的第一、第二、第三、第四或第五种可能的实现方式中的第一种可能的实现方式，所述处理器具体用于，根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
结合第四方面的第一、第二、第三、第四或第五种可能的实现方式，在第一种可能的实现方式中，所述处理器具体用于，根据当前接收到的RLC确认报文生成TCP确认报文，并通过所述收发器将生成的TCP确认报文发送给对端通信设备。
结合第四方面的第一、第二、第三、第四或第五种可能的实现方式中的第一种可能的实现方式，所述处理器生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是处理器生成的。
本发明的上述实施例中，由于通信设备的RLC协议实体单元接收到所述通信设备的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，因而与现有技术相比减少了确认报文的发送数量。另外，通信设备的RLC协议实体单元接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备的TCP协议实体单元发送TCP确认报文，从而在减少确认报文发送数量的基础上，实现了报文确认机制。
附图说明
图1为现有技术中数据包传输流程示意图；
图2为现有技术中TCP数据包头的格式示意图；
图3为本发明实施例一提供的确认报文发送流程示意图；
图4为本发明实施例中的TCP数据包与RLC数据包的对应关系示意图；
图5为本发明实施例二提供的确认报文发送流程示意图；
图6为本发明实施例三提供的确认报文发送流程示意图；
图7为本发明实施例四提供的确认报文发送流程示意图；
图8为本发明实施例中的RLC确认报文数据包的格式示意图；
图9为本发明实施例五提供的确认报文发送流程示意图；
图10为本发明实施例六提供的确认报文发送流程示意图；
图11为本发明实施例七提供的通信设备的结构示意图；
图12为本发明实施例八提供的通信设备的结构示意图；
图13为本方面实施例九提供的通信设备的结构示意图。
具体实施方式
针对现有技术中存在的缺陷，本发明实施例提出了一种在数据传输过程中减少数据确认信息的发送技术方案，具体而言，主要针对报文传输过程中的TCP层和RLC层减少TCP确认报文或/和RLC确认报文的传输。本发明实施例可应用于无线终端和网络设备间的空口数据传输过程，以减少空口中确认报文的发送，进而提高数据传输的效率和资源的利用率。
本发明实施例主要关注在报文传输过程中TCP层和RLC层的处理操作，省略了其它协议层的处理过程描述，例如：TCP和RLC之间的IP层，PDCP（Packet Data ConvergenceProtocol，分组数据汇聚协议）层等。为了便于理解，本发明各实施例的描述基于以下约定：
（1）TCP协议实体（本实施例中也可称为TCP协议实体单元）属于TCP层，与TCP层对应，即为执行TCP层协议的实体（或称功能模块）；RLC协议实体（本实施例中也可称为RLC协议实体单元）属于RLC层，与RLC层对应，即为执行RLC层协议的实体（或称功能模块）。
（2）实施例中的“发送端设备”是指发送数据包的设备，“接收端设备”是指接收该数据包的设备。
（3）发送端的TCP协议实体将TCP数据包发送给发送端设备的RLC协议实体只是一种简单的描述，在实际的操作中TCP数据包可能还需要经过IP层，PDCP层等，反之亦然。RLC协议实体将TCP数据包处理为RLC层的数据包是一种简单的描述，此时RLC可能接收到的是包含TCP数据包的PDCP数据包。
下面结合附图对本发明实施例进行详细描述。
实施例一
参见图3，为本发明实施例一提供的报文确认流程示意图，在发送端设备向接收端设备发送报文的过程中，执行以下流程：
步骤301～303：发送端设备的TCP协议实体发送TCP数据包到接收端设备的TCP协议实体。
该步骤中，发送端设备的TCP协议实体将TCP层的数据包（以下简称TCP数据包）发送给发送端设备的RLC协议实体，RLC协议实体将该TCP数据包处理为RLC层的数据包（以下简称RLC数据包）并发送。接收端设备的RLC协议实体接收到发送端设备RLC协议实体发送的RLC数据包后，发送给接收端设备的TCP协议实体。在该过程中，接收端设备的RLC协议实体在接收到发送端设备RLC协议实体发送的RLC数据包后，按照现有RLC确认报文发送规则发送RLC确认报文，即，如果此刻是RLC确认报文的发送时机，则发送RLC确认报文，如果此刻不是RLC确认报文的发送时机，则不发送RLC确认报文，等到RLC确认报文的发送时机到来时发送RLC确认报文。
这里RLC确认报文的发送时机是指需要发送RLC确认报文的时刻，该发送时机可能是根据RLC禁止发送的定时器确认的也可能是根据接收端的状态变量确认的，上述确认方式均是按照现有的RLC确认报文的发送准则定义的，具体的发送准则在TS25.322协议中有详细的定义。
步骤304：接收端设备的TCP协议实体接收到TCP数据包后，按照现有TCP确认报文发送规则发送TCP确认报文。本流程中，发送TCP确认报文的时机到达时且当前没有数据包需要发送时，接收端设备的TCP协议实体生成单独发送的TCP确认报文并发送到接收端设备的RLC协议实体。所述单独发送的TCP确认报文为包含下一次数据包的传输序列号的，仅有头信息而没有数据信息的TCP确认报文，该确认报文是为了确认上一个TCP数据包的正确的接收。
步骤305：接收端设备的RLC协议实体丢弃所接收到的单独发送的TCP确认报文。
可选地，如果该单独发送的TCP确认报文中除了确认上一个TCP数据包的正确的接收之外还包含其他的信息，则RLC协议实体不丢弃该TCP确认报文。
步骤306：发送端设备的RLC协议实体在接收到接收端RLC协议实体发送的RLC确认报文后，如果确认该RLC确认报文所对应的TCP数据包已经正确接收，则生成该TCP数据包的TCP确认报文，并向发送端设备的TCP协议实体发送生成的TCP确认报文。
进一步地，在步骤306中，发送端设备的RLC协议实体生成TCP确认报文时，为了避免发送端设备的TCP协议实体的错误的处理，可以在生成的TCP确认报文包中向发送端设备的TCP协议实体指示出该TCP确认报文是RLC协议实体生成的，例如：可以通过TCP确认报文中的保留位指示该确认报文是RLC协议实体生成的，或者可以认为只要收发双方约定采用本实施例中确认报文减少的方式，则发送端的TCP协议实体所接收到的确认报文都是由RLC协议实体构造的。
进一步地，在应用上述方案时，发送端设备的RLC协议实体需要记录TCP对应的端口号等信息，在生成TCP确认报文时用来填充数据包头。
进一步地，上述发送端设备生成（构造）TCP确认报文和/或记录TCP数据包对应的端口号等信息的功能可以在发送端设备的RLC协议实体实现，也可以由其它功能实体实现，而该功能实体可以在RLC层也可以在PDCP层或者IP层等，在此不做限制。当该功能实体在除了RLC层以外的其他协议实体时，可选地，RLC层需要将TCP数据包正确接收的信息告知该功能实体。
上述流程中，可选的，在步骤302中，发送端设备的RLC协议实体将该TCP数据包处理为RLC数据包后，还记录TCP数据包和RLC数据包的对应关系（比如记录TCP数据包的序列号以及RLC数据包的序列号及其对应关系）；在步骤306中，发送端设备的RLC协议实体在接收到接收端RLC协议实体发送的RLC确认报文后，根据记录的TCP数据包和RLC数据包的对应关系，判断当前接收到的RLC确认报文所对应的TCP数据包是否已经正确接收。
上述TCP确认报文是指TCP层发送的数据包接收的反馈信息，例如：TCP ACK，上述RLC确认报文是指RLC层发送的数据包接收的反馈信息，可能是RLC的正确确认（RLC ACK），也可能为RLC的非正确确认（RLC NACK）或者其它的确认信息，这里在确定数据包是否正确接收时通常使用的是RLC ACK信息。
下面以设备A向设备B发送数据报文的过程为例，来说明实施例一的具体实现过程。
设备A的TCP协议实体发送TCP层序列号为1002的数据包，该数据包到达设备A的RLC协议实体后，如图4所示，RLC协议实体将该数据包分段为4个RLC层序列号分别为3、4、5、6的数据包并依次发送，并记录TCP层序列号（1002）和对应的RLC层序列号（3、4、5、6）。
设备B的RLC协议实体接收设备A的RLC协议实体发送的数据包，并在发送RLC ACK的时机到来时，发送对应的RLC ACK；设备B的TCP协议实体在接收到TCP层的序列号为1002的数据包之后，如果TCP协议实体针对该数据包需要发送TPC ACK，则将所述TCP ACK发送给设备B的RLC协议实体；如果该TCP ACK为不包含数据信息的TCP ACK，则RLC协议实体丢弃所接收到的单独发送的TCP ACK。
设备A的RLC协议实体接收到RLC层序列号为3的数据包的RLC层的正确确认信息后，查询所记录的数据包的TCP层序列号（1002）和数据包的RLC层序列号（3、4、5、6）的对应关系，确认还没有全部接收到TCP层序列号为1002的数据包所对应的所有RLC层的数据包，因此继续等待其它RLC数据包的确认信息；同理，当设备A的RLC协议实体接收到RLC层序列号为4、5的数据包的RLC正确确认信息后，继续等待后续数据包的RLC层的正确确认信息，直到接收到RLC层序列号为6的数据包的RLC层的正确确认信息后，确认已经全部接收到TCP层序列号为1002的数据包所对应的所有分割块，即确认正确接收到TCP层序列号为1002的数据包，则生成该数据包的TCP ACK，并向设备A的TCP协议实体发送生成的TCP ACK。
进一步地，在接收端设备的RLC协议实体收到序列号为1002的TCP的数据包之后，根据TCP确认报文的发送规则发送TCP确认报文，比如，当前可能并不是TCP确认报文反馈的时机，因此不会发送TCP确认报文。发送端设备的RLC协议实体在确认接收到TCP层序列号为1002的数据包后，也可根据TCP确认报文的发送规则，在TCP确认报文的发送时机到来时，生成（构造）并发送TCP层序列号为1002的数据包的TCP确认报文，如果当前不是TCP确认报文的发送时机，则不生成（构造）TCP确认报文。
通过以上实施例一的描述可以看出，由于接收端设备的RLC协议实体接收到接收端设备的TCP协议实体发送的未携带数据信息的TCP确认报文后将其丢弃，减少了接收端设备向发送端设备传输TCP确认报文的过程，从而减少了接收端设备和发送端设备间空口确认报文的发送，进而提高数据传输的效率和资源的利用率。
实施例二
参见图5，为本发明实施例二提供的报文确认流程示意图，在发送端设备向接收端设备发送报文的过程中，执行以下流程：
步骤501～503：发送端设备的TCP协议实体发送TCP数据包到接收端设备的TCP协议实体。
该步骤中，发送端设备的TCP协议实体将TCP层的数据包（以下简称TCP数据包）发送给发送端设备的RLC协议实体，RLC协议实体将该TCP数据包处理为RLC层的数据包（以下简称RLC数据包）并发送。接收端设备的RLC协议实体接收到发送端设备RLC协议实体发送的RLC数据包后，发送给接收端设备的TCP协议实体。在该过程中，接收端设备的RLC协议实体在接收到发送端设备RLC协议实体发送的RLC数据包后，按照现有RLC确认报文发送规则发送RLC确认报文。
步骤504：接收端设备的TCP协议实体接收到TCP数据包后，按照现有TCP确认报文发送规则发送TCP确认报文。本流程中，发送TCP确认报文的时机到达时且当前没有数据包需要发送时，接收端设备的TCP协议实体生成单独发送的TCP确认报文并发送到接收端设备的RLC协议实体。所述单独发送的TCP确认报文为包含下一次数据包的传输序列号的，仅有头信息而没有数据信息的TCP确认报文，该确认报文是为了确认以前TCP数据包的正确的接收。
步骤505：接收端设备的RLC协议实体丢弃所接收到的单独发送的TCP确认报文，生成RLC数据包的确认信息RLC确认报文，并将生成的RLC确认信息向发送端设备的RLC协议实体发送。即，接收端设备的TCP协议实体发送的TCP确认报文触发了对应RLC数据包的RLC确认信息的发送过程。
比如，接收端设备的RLC协议实体从发送端设备RLC协议实体接收到4个RLC层序列号为3、4、5、6的数据包后解封装并装配为1个TCP层序列号为1002的数据包并发送给接收端设备的TCP协议实体，如果TCP协议实体针对该TCP层序列号为1002的数据包生成单独发送的TCP确认报文（TCP ACK）并发送给接收端设备的RLC协议实体，则RLC协议实体丢弃所接收到的单独发送的TCP ACK，并生成RLC数据包的RLC确认报文，发送给发送端设备的RLC协议实体。接收端设备RLC协议实体收到接收端设备TCP协议实体单独发送的TCP确认报文时，当前时刻可能不是RLC确认报文的发送时机，按照本实施例提供的上述流程，此刻会生成RLC确认报文并发送。
进一步地，接收端设备的RLC实体在发送RLC确认报文之后，接收端的RLC实体从该确认报文之后的一个数据包开始重新计数以确定下一个RLC确认报文的发送时机，例如：RLC确认报文为40毫秒发送一次，则在所述RLC确认报文（即由TCP确认报文所触发而发送的RLC确认报文）发送之后需要重新开始计时，直到40毫秒之后到达下一个RLC确认报文的发送时机。
可选地，如果该单独发送的TCP确认报文中除了确认该TCP数据包之前的TCP数据包的正确的接收之外还包含其他的信息，则RLC协议实体不丢弃该TCP确认报文。
步骤506：发送端设备的RLC协议实体在接收到接收端RLC协议实体发送的RLC确认报文后，如果确认该RLC确认报文所对应的TCP数据包已经正确接收，则生成该TCP数据包的TCP确认报文，并向发送端设备的TCP协议实体发送生成的TCP确认报文。
进一步地，在步骤506中，发送端设备的确认报文生成实体（这里以RLC协议实体为例）生成TCP确认报文时，为了避免发送端设备的TCP协议实体的错误的处理，进一步地可以在生成的TCP确认报文中向发送端设备的TCP协议实体指示出该TCP确认报文是RLC协议实体生成的，例如：可以通过TCP确认报文中的保留位指示该数据包是RLC协议实体生成的，或者可以认为只要收发双方约定采用本实施例中确认报文减少的方式，则发送端的TCP协议实体所接收到的确认报文都是由RLC协议实体构造的。
进一步地，在应用上述方案时，发送端设备的RLC协议实体需要记录TCP对应的端口号等信息，在生成TCP确认报文时用来填充数据包头。
进一步地，上述发送端设备生成（构造）TCP确认报文和/或记录TCP数据包对应的端口号等信息的功能可以在发送端设备的RLC协议实体实现，也可以由其它功能模块实现，而该功能实体可以在RLC层也可以在PDCP层或者IP层等，在此不做限制。当该功能实体在除了RLC层以外的其他协议实体时，可选地，RLC层需要将TCP数据包正确接收的信息告知该功能实体。
上述流程中，可选的，在步骤502中，发送端设备的RLC协议实体记录TCP数据包和RLC数据包的对应关系（比如记录TCP数据包的序列号以及RLC数据包的序列号及其对应关系）；在步骤506中，发送端设备的RLC协议实体在接收到接收端RLC协议实体发送的RLC确认报文后，根据记录的TCP数据包和RLC数据包的对应关系，判断当前接收到的RLC确认报文所对应的TCP数据包是否已经正确接收。
通过以上实施例二的描述可以看出，由于接收端设备的RLC协议实体在接收到接收端设备的TCP协议实体发送的未携带数据信息的TCP确认报文后放弃该TCP确认报文，并触发RLC确认报文的发送，减少了接收端设备向发送端设备传输TCP确认报文的过程，从而减少了接收端设备和发送端设备间空口数据接收确认报文的发送，进而提高数据传输的效率和资源的利用率。
实施例三
参见图6，为本发明实施例三提供的报文确认流程示意图，在发送端设备向接收端设备发送报文的过程中，执行以下流程：
步骤601～603：发送端设备的TCP协议实体发送TCP数据包到接收端设备的TCP协议实体。
该步骤中，发送端设备的TCP协议实体将TCP数据包发送给发送端设备的RLC协议实体，RLC协议实体将该TCP数据包处理为RLC层的数据包（以下简称RLC数据包）并发送。接收端设备的RLC协议实体接收到发送端设备RLC协议实体发送的RLC数据包后，发送给接收端设备的TCP协议实体。该过程中，接收端设备的RLC协议实体在接收到发送端设备RLC协议实体发送的RLC数据包后，按照现有RLC确认报文发送规则判断是否是发送RLC确认报文的时机，如果不是发送RLC确认报文的时机则不发送RLC确认报文；如果当前时刻是发送RLC确认报文的时机且当前还接收到接收端设备TCP协议实体单独发送的TCP确认报文，则按照以下步骤605的描述将RLC确认报文和TCP确认报文合并发送给发送端设备。
步骤604：接收端设备的TCP协议实体接收到TCP数据包后，按照现有TCP确认报文发送规则发送TCP确认报文。本流程中，发送TCP确认报文的时机到达时且当前没有数据包需要发送时，接收端设备的TCP协议实体生成单独发送的TCP确认报文并发送到接收端设备的RLC协议实体。所述单独发送的TCP确认报文为包含下一次数据包的传输序列号的，仅有头信息而没有数据信息的TCP确认报文，该确认报文是为了确认上一个TCP数据包的正确的接收。
步骤605：接收端设备的RLC协议实体接收单独发送的TCP确认报文，如果此刻是RLC确认报文的发送时机，则将RLC确认报文和TCP确认报文合并发送给发送端设备的RLC协议实体。
可选地，该步骤中，如果接收端设备的RLC协议实体接收到接收端设备的TCP协议实体单独发送的TCP确认报文，且此刻是RLC确认报文的发送时机，则RLC协议实体在将当前接收到的TCP确认报文以及当前需要发送的RLC确认报文合并发送时，可以通过修改RLC确认报文数据包的格式，在RLC确认报文数据包中包含TCP确认报文的下一个待接收的序列号的信息。图8示出了一种修改后的RLC确认报文数据包的格式，其中：
D/C表示：该数据包是数据包还是控制信息还是数据包；
PDU Type字段指示该RLC确认报文中包含了TCP确认信息；
SUFI字段用于承载RLC层的确认信息；
PAD（padding）表示填充信息，为了保证数据包满足预先定义的大小。
可选地，该步骤中，RLC确认报文和TCP确认报文合并发送的具体实现方式包括：接收端的RLC协议实体仅仅发送RLC确认报文（包含TCP确认信息）而丢弃TCP确认报文，或者接收端的RLC协议实体仅仅发送TCP确认报文（包含RLC确认信息）而丢弃RLC确认报文。进一步的为了标识RLC的确认报文或者TCP的确认报文被丢弃，在发送出去的确认报文中增加所丢弃的确认报文的指示信息。
步骤606：发送端设备的RLC协议实体在接收到接收端设备的RLC协议实体发送的合并的确认报文后，判断相应的TCP数据包已经被正确接收，则生成TCP确认报文，并向发送端设备的TCP协议实体发送生成的TCP确认报文。
进一步地，该步骤606中，发送端设备的RLC协议实体生成TCP确认报文时，为了避免发送端设备的TCP协议实体的错误的处理，可以在生成的TCP确认报文包中向发送端设备的TCP协议实体指示出该TCP确认报文是RLC协议实体生成的，例如：可以通过TCP确认报文数据包中的保留位指示该数据包是RLC协议实体生成的，或者可以认为只要收发双方约定采用本实施例中确认报文减少的方式，则发送端的TCP协议实体所接收到的确认报文都是由RLC协议实体构造的。
进一步地，在应用上述方案时，发送端设备的RLC协议实体需要记录TCP对应的端口号等信息，在生成TCP确认报文时用来填充数据包头。
进一步地，上述发送端设备生成（构造）TCP确认报文和/或记录TCP数据包对应的端口号等信息的功能可以在发送端设备的RLC协议实体实现，而该功能实体可以在RLC层也可以在PDCP层或者IP层等，也可以由其它功能模块实现，在此不做限制。当该功能实体在除了RLC层以外的其他协议实体时，可选地，RLC层需要将TCP数据包正确接收的信息（即合并发送的确认报文中携带的TCP确认信息）告知该功能实体。
以上流程是以接收端设备的RLC协议实体接收单独发送的TCP确认报文后，当前是RLC确认报文的发送时机为例描述的，如果当前不是RLC确认报文的发送时机，则RLC协议实体将接收到的TCP确认报文发送给发送端设备的TCP协议实体。进一步地，RLC协议实体将接收到的TCP确认报文向发送端设备发送时，可去除TCP确认报文中的端口号等信息，但需要保留TCP确认序列号，优选的，可仅保留TCP确认序列号，由RLC协议实体重新封装TCP确认报文并发送重新封装的TCP确认报文，以减少TCP确认报文的数据量。
上述TCP确认报文是指TCP层发送的数据包接收的反馈信息，例如：TCP ACK，上述RLC确认报文是指RLC层发送的数据包接收的反馈信息，可能是RLC的正确确认（RLC ACK），也可能为RLC的非正确确认（RLC NACK）或者其它的确认信息，这里在确定数据包是否正确接收时通常使用的是RLC ACK信息。
下面以设备A向设备B发送数据报文的过程为例，来说明实施例三的具体实现过程。
设备A的TCP协议实体发送TCP层序列号为1002的数据包，该数据包到达设备A的RLC协议实体后，如图4所示，RLC协议实体将该数据包分段为4个RLC层序列号分别为3、4、5、6的数据包并依次发送。
设备B的RLC协议实体接收到设备A的RLC协议实体发送的数据包后，在发送RLCACK的时机到来时且当前时刻还未接收到设备B的TCP协议实体发送的TCP ACK的情况下，针对接收到的RLC层数据包向设备A发送RLC ACK。设备B的RLC协议实体接收到TCP层序列号为3、4、5、6的数据包后解封装并发送给设备B的TCP协议实体，TCP协议实体针对该数据包生成单独发送的TCP ACK并发送给设备B的RLC协议实体；RLC协议实体接收该TCP ACK，确定当前是RLC层序列号5的数据包的RLC ACK的发送时机，则生成RLC层序列号5的数据包的RLCACK，其中，在生成的RLC ACK中除了携带RLC层的确认信息以外，还携带TCP层下一个待接收的序列号1003。
设备A的RLC协议实体接收到携带有TCP ACK信息的RLC ACK后，根据其中携带的TCP确认序列号1003，确认相应数据包已经正确接收，则生成数据包的TCP ACK，并向设备A的TCP协议实体发送生成的TCP ACK。
通过以上实施例三的描述可以看出，由于接收端设备的RLC协议实体在接收到接收端设备的TCP协议实体发送的TCP确认报文后，将TCP确认报文与RLC确认报文合并发送，减少了接收端设备向发送端设备传输RLC确认报文和/或TCP确认报文的过程。从而减少了接收端设备和发送端设备间空口数据接收确认报文的发送，进而提高数据传输的效率和资源的利用率。
实施例四
参见图7，为本发明实施例四提供的报文确认流程示意图，在发送端设备向接收端设备发送报文的过程中，执行以下流程：
步骤701～703：发送端设备的TCP协议实体发送TCP数据包到接收端设备的TCP协议实体。
该步骤中，发送端设备的TCP协议实体将TCP层的数据包（以下简称TCP数据包）发送给发送端设备的RLC协议实体，RLC协议实体将该TCP数据包处理为RLC层的数据包（以下简称RLC数据包）并发送。接收端设备的RLC协议实体接收到发送端设备RLC协议实体发送的RLC数据包后，发送给接收端设备的TCP协议实体。在该过程中，接收端设备的RLC协议实体在接收到发送端设备RLC协议实体发送的RLC数据包后，按照现有RLC确认报文发送规则发送RLC确认报文。
步骤704：接收端设备的TCP协议实体接收到TCP数据包后，按照现有TCP确认报文发送规则发送TCP确认报文。本流程中，如果发送TCP确认报文的时机到达时且当前没有TCP数据包需要发送时，接收端设备的TCP协议实体生成单独发送的TCP确认报文并发送到接收端设备的RLC协议实体。所述单独发送的TCP确认报文为包含下一次数据包的传输序列号的，仅有头信息而没有TCP数据信息的TCP确认报文，该确认报文是为了确认上一个TCP数据包的正确的接收。
步骤705：接收端设备的RLC协议实体接收到单独发送的TCP确认报文后，如果确认当前接收到的TCP确认报文对应的RLC确认报文已经发送，则RLC协议实体丢弃接收到的TCP确认报文。其中，TCP确认报文对应的RLC确认报文是指：TCP确认报文对应的TCP数据包所对应的RLC数据包的RLC确认报文。
优选的，接收端设备的RLC协议实体可通过以下方式确认当前接收到的TCP确认报文对应的RLC确认报文：根据当前接收到的TCP确认报文所确认的TCP数据包，确定该TCP数据包对应的所有的RLC数据包，该RLC数据包对应的RLC确认报文即为该TCP确认报文所对应的RLC确认报文。
可选地，如果该单独发送的TCP确认报文中除了确认上一个TCP数据包的正确的接收之外还包含其他的信息，则RLC协议实体不丢弃该TCP确认报文。
步骤706：发送端设备的RLC协议实体如果确认已接收到TCP数据包对应的RLC确认报文，则生成该TCP数据包的TCP确认报文，并向发送端设备的TCP协议实体发送生成的TCP确认报文。
该步骤中，进一步的，发送端设备的RLC协议实体生成TCP确认报文时，为了避免发送端设备的RLC协议实体的错误的处理，可以在生成的TCP确认报文中向发送端设备的TCP协议实体指示出该TCP确认报文是RLC协议实体生成的，例如：可以通过TCP确认报文中的保留位指示该确认报文是RLC协议实体生成的。
进一步的，在应用上述方案时，发送端设备的RLC协议实体需要记录TCP对应的端口号等信息，在生成TCP确认报文时用来填充数据包头。
进一步的，上述发送端设备生成（构造）TCP确认报文和/或记录TCP数据包对应的端口号等信息的功能可以在发送端设备的RLC协议实体实现，也可以由其它功能模块实现，在此不做限制。
可选的，上述步骤701～703中，发送端设备的RLC协议和接收端设备的RLC协议实体还可记录TCP数据包和RLC数据包的对应关系（比如记录TCP数据包的序列号以及RLC数据包的序列号及其对应关系）；接收端设备的RLC协议实体还根据接收到的RLC数据包获得TCP数据包与RLC数据包的对应关系（比如TCP数据包的序列号以及RLC数据包的序列号及其对应关系）并记录该对应关系信息。在步骤705中，接收端设备的RLC协议实体接收到单独发送的TCP确认报文后，根据记录的TCP数据包和RLC数据包的对应关系，判断当前接收到的TCP确认报文对应的RLC数据包的RLC确认报文是否已经发送。在步骤706中，发送端设备的RLC协议实体根据记录的TCP数据包和RLC数据包的对应关系信息，确认是否已接收到TCP数据包对应的RLC数据包。
上述流程的步骤705可替换为：如果接收端设备的RLC协议实体接收到单独发送的TCP确认报文后，判断当前接收到的TCP确认报文对应的RLC数据包的RLC确认报文还未发送（比如可根据记录的TCP数据包和RLC数据包的对应关系进行判断），则将当前接收到的TCP确认报文发送给发送端设备，进一步的，RLC协议实体对于尚未发送RLC确认报文的RLC数据包，不再发送RLC确认报文。相应的，步骤706可替换为：发送端设备的RLC协议实体接收到接收端设备发送的TCP确认报文后，将该TCP确认报文发送给发送端设备的TCP协议实体。
上述TCP确认报文是指TCP层发送的数据包接收的反馈信息，例如：TCP ACK，上述RLC确认报文是指RLC层发送的数据包接收的反馈信息，可能是RLC的正确确认（RLC ACK），也可能为RLC的非正确确认（RLC NACK）或者其它的确认信息，这里在确定数据包是否正确接收时通常使用的是RLC ACK信息。
下面以设备A向设备B发送数据报文的过程为例，来说明实施例四的具体实现过程。
设备A的TCP协议实体发送TCP层序列号为1002的数据包，该数据包到达设备A的RLC协议实体后，如图4所示，RLC协议实体将该数据包分段为4个RLC层序列号分别为3、4、5、6的数据包并依次发送，并记录TCP层序列号（1002）和RLC层序列号（3、4、5、6）的对应关系。
设备B的RLC协议实体接收设备A的RLC协议实体发送的数据包，从接收到的数据包获得TCP层序列号（1002）与RLC层序列号（3、4、5、6）及其对应关系，按照现有RLC ACK发送规则向设备A的RLC协议实体发送RLC ACK；当设备B的TCP协议实体接收到TCP层序列号为1002的数据包后，如果满足TCP ACK发送的时机且没有TCP数据需要发送，则针对该数据包生成单独发送的TCP ACK并发送给接收端设备的RLC协议实体；RLC协议实体接收所述TCP ACK，确认已经发送了RLC层序列号为3、4的数据包的RLC ACK，RLC层序列号为5、6的数据包的RLCACK还未发送，则将所述TCP ACK发送到设备A，并不再发送RLC层序列号为5、6的数据包的RLC ACK。
设备A的RLC协议实体接收到与RLC层序列号为3的数据包对应的RLC ACK后，查询所记录的TCP层序列号（1002）和RLC层序列号（3、4、5、6）的对应关系，确认还没有全部接收到TCP层序列号为1002的数据包所对应的所有RLC数据包，因此继续等待其它RLC ACK；同理，当设备A的RLC协议实体接收到与RLC层序列号为4、5对应的RLC ACK后，继续等待其它RLC ACK，直到接收到与RLC层序列号为6对应的RLC ACK后，确认已经全部接收到序列号为1002的数据包所对应的所有分段块，即确认接收到序列号为1002的数据包所对应的所有的RLC数据包都被正确接收，则生成针对TCP层序列号1002的数据包的TCP ACK，并向设备A的TCP协议实体发送所述TCP ACK。
另一实例中，如果设备B的RLC协议实体接收到TCP层序列号1002对应的TCP ACK后，判断RLC层序列号为3、4、5、6的数据包的RLC ACK还没有全部发送，则发送接收到的TCPACK，同时认为RLC层序列号为6之前的所有数据包的RLC确认报文均不再发送。设备A的RLC协议实体接收到该TCP ACK后，确认TCP层序列号1002的数据包正确接收，因此向设备A的TCP协议实体发送所述TCP ACK，同时认为RLC层序列号为6之前的所有数据包均已正确接收。
通过以上实施例四的描述可以看出，由于接收端设备的RLC协议实体在接收到接收端设备的TCP协议实体发送的TCP确认报文后，且对应的RLC确认报文已发送时，放弃该TCP确认报文的发送，减少了接收端设备向发送端设备传输TCP确认报文的过程。另外，接收端设备的RLC协议实体在发送TCP确认报文后，对于尚未发送的RLC确认报文不再发送，减少了接收端设备向发送端设备传输RLC确认报文的过程。从而减少了接收端设备和发送端设备间空口数据接收确认报文的发送，进而提高数据传输的效率和资源的利用率。
实施例五
参见图9，为本发明实施例五提供的报文确认流程示意图，在发送端设备向接收端设备发送报文的过程中，执行以下流程：
步骤901～903：发送端设备的TCP协议实体发送TCP数据包到接收端设备的TCP协议实体。
该步骤中，发送端设备的TCP协议实体将TCP层的数据包（以下简称TCP数据包）发送给发送端设备的RLC协议实体，RLC协议实体将该TCP数据包处理为RLC层的数据包（以下简称RLC数据包）并发送。接收端设备的RLC协议实体接收到发送端设备RLC协议实体发送的RLC数据包后，发送给接收端设备的TCP协议实体。在该过程中，接收端设备的RLC协议实体在接收到发送端设备RLC协议实体发送的RLC数据包后，在RLC确认报文的发送时机到达时，并且当前缓存中没有接收端设备的TCP协议实体发送的TCP确认报文的情况下，发送RLC确认报文给发送端设备。
步骤904：接收端设备的TCP协议实体接收到TCP数据包后，按照现有TCP确认报文发送规则发送TCP确认报文。本流程中，发送TCP确认报文的时机到达时且当前没有数据包需要发送时，接收端设备的TCP协议实体生成单独发送的TCP确认报文并发送到接收端设备的RLC协议实体。所述单独发送的TCP确认报文为包含下一次数据包的传输序列号的，仅有头信息而没有数据信息的TCP确认报文，该确认报文是为了确认以前TCP数据包的正确的接收。
步骤905：接收端设备的RLC协议实体在RLC确认报文的发送时机到达时，检测到当前缓存有接收端设备的TCP协议实体单独发送的TCP确认报文，则接收端设备的RLC协议实体将缓存的TCP确认报文和当前需要发送的RLC确认报文合并发送给发送端设备。
可选地，该步骤中，如果接收端设备的RLC协议实体检测到当前缓存有接收端设备的TCP协议实体单独发送的TCP确认报文，且此刻是RLC确认报文的发送时机，则RLC协议实体在将当前缓存的TCP确认报文以及当前需要发送的RLC确认报文合并发送时，可以通过修改RLC确认报文数据包的格式，在RLC确认报文数据包中包含TCP确认报文的下一个待接收的序列号的信息。
可选地，该步骤中，RLC确认报文和TCP确认报文合并发送的具体实现方式包括：接收端的RLC协议实体仅仅发送RLC确认报文（包含TCP确认信息）而丢弃TCP确认报文，或者接收端的RLC协议实体仅仅发送TCP确认报文（包含RLC确认信息）而丢弃RLC的确认报文。进一步的为了标识RLC的确认报文或者TCP确认报文被丢弃，在发送出去的确认报文中增加所丢弃的确认报文的指示信息。
可选地，在步骤中，如果接收端设备的RLC协议实体检测到当前缓存有TCP确认报文，且此刻是RLC确认报文的发送时机，则RLC协议实体在将当前缓存的TCP确认报文以及当前需要发送的RLC确认报文合并发送时，可以通过修改RLC确认报文数据包的格式，在RLC确认报文数据包中包含TCP确认报文的下一个待接收的序列号的信息。
步骤906：发送端设备的RLC协议实体在接收到接收端设备的RLC协议实体发送的合并的确认报文后，判断相应的TCP数据包已经被正确接收，则生成TCP确认报文，并向发送端设备的TCP协议实体发送生成的TCP确认报文。
进一步地，该步骤906中，发送端设备的RLC协议实体生成TCP确认报文时，为了避免发送端设备的TCP协议实体的错误的处理，可以在生成的TCP确认报文包中向发送端设备的TCP协议实体指示出该TCP确认报文是RLC协议实体生成的，例如：可以通过TCP确认报文数据包中的保留位指示该数据包是RLC协议实体生成的，或者可以认为只要收发双方约定采用本实施例中确认报文减少的方式，则发送端的TCP协议实体所接收到的确认报文都是由RLC协议实体构造的。
进一步地，在应用上述方案时，发送端设备的RLC协议实体需要记录TCP对应的端口号等信息，在生成TCP确认报文时用来填充数据包头。
进一步地，上述发送端设备生成（构造）TCP确认报文和/或记录TCP数据包对应的端口号等信息的功能可以在发送端设备的RLC协议实体实现，而该功能实体可以在RLC层也可以在PDCP层或者IP层等，也可以由其它功能模块实现，在此不做限制。当该功能实体在除了RLC层以外的其他协议实体时，可选地，RLC层需要将TCP数据包正确接收的信息（即合并发送的确认报文中携带的TCP确认信息）告知该功能实体。
以上各流程是以接收端设备的TCP协议实体接收到TCP数据包后生成单独发送的TCP确认报文（仅包含头信息而不包含数据信息）为例描述的，如果接收端设备的TCP协议实体接收到TCP数据包后生成捎带发送的TCP确认报文（包含头信息且还包含数据信息），则一种优选的实现方式为：接收端设备的RLC协议实体在接收到接收端设备的TCP协议实体发送的TCP确认报文后将其发送给发送端设备的对等协议实体（即TCP协议实体），并在需要发送RLC确认报文时，针对从发送端设备RLC协议实体接收到的RLC数据包返回RLC确认报文。接收端设备的RLC协议实体接收到TCP确认报文后，向发送端设备返回RLC确认报文。
以上各实施例主要描述了发送端设备和接收端设备之间的数据接收确认过程，即在该过程中如何处理RLC确认报文和TCP确认报文。在实际应用中，可将本发明实施例应用于终端和网络侧设备（如基站）之间的数据传输过程。为了提高灵活性以及与现有技术的兼容性，终端可向网络侧设备指示采用本发明实施例所描述的数据确认方式的能力，网络侧设备在承载配置时指示终端在数据传输过程中采用本发明实施例描述的数据确认方式，终端在数据的传输过程中应用根据该指示采用本发明实施例提供的数据接收确认方式进行数据传输，以减少RLC确认报文或/和TCP确认报文的发送。图10示出了上述流程的一种优选实施例的实现过程。
参见图10，为本发明实施例六提供的报文确认流程示意图，该流程可包括：
步骤1001：终端向网络设备（比如无线网络控制器）指示支持确认报文减少的能力。
该步骤中，终端可以在接入网络后向网络设备上报所述终端的相关信息时，将所述终端支持确认报文减少的能力上报给网络设备。或者，终端可在请求传输资源时，将所述UE支持确认报文减少的能力上报给网络设备。
步骤1002：网络设备对所述终端进行承载配置，指示终端在数据传输过程中采用确认报文减少的方式。
步骤1003：终端根据网络设备的指示，在数据传输过程中应用确认报文减少的方式进行数据传输，即，应用前述实施例的方式进行数据传输。
进一步的，网络设备可根据终端上报的能力信息，指示终端在数据传输过程中采用哪种确认报文减少的方式。比如，如果终端向网络设备指示出支持前述实施例一提供的确认报文减少的方式，则网络设备指示终端采用该种确认报文减少的方式；如果终端向网络设备指示出支持多种确认报文减少的方式，则网络设备可根据预先制定的策略为该终端选择一种确认报文减少的方式，比如可根据当前网络传输性能进行选择，网络传输性能较差时，可选择实施例四提供的方式以尽量减少确认报文的发送数量。
需要说明的是，本发明的上述各实施例中，优选的，发送端设备的RLC协议实体在接收到TCP层的数据包时，将数据包头的某些固定信息去除（如去除源、目的端口号等），在接收端设备的RLC协议实体接收到该TCP数据包时再将该信息填充到包头中。这样可以提高空口传输效率。
基于相同的技术构思，本发明实施例七还提供了一种通信设备，该通信设备可适用于上述各实施例所描述的流程。在将所述通信设备应用于用户设备和网络设备进行通信的过程中，所述通信设备为UE（User Equipment，用户设备），则对端通信设备为RNC（RadioNetwork Control，无线网络控制器）；或者所述通信设备为RNC，则对端通信设备为UE。
参见图11，为本发明实施例七提供的设备的结构示意图。如图所示，该通信设备10可包括：TCP协议实体11和RLC协议实体12，其中：
TCP协议实体11，用于向RLC协议实体12发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收RLC协议实体12发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
RLC协议实体12，用于接收到TCP协议实体11发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；以及，接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向TCP协议实体11发送TCP确认报文。
进一步的，RLC协议实体12在接收到所述TCP协议实体发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文。
具体的，RLC协议实体12具体用于：若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备。
具体的，RLC协议实体12具体用于：接收到对端通信设备的RLC协议实体发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述TCP协议实体发送TCP确认报文。
具体的，RLC协议实体12具体用于：若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备。
具体的，RLC协议实体12还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
具体的，RLC协议实体12具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从所述TCP协议实体接收到的未携带有数据信息的TCP确认报文，则确定不向对端通信设备发送TCP确认报文，并将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
具体的，RLC协议实体12具体用于，若根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则向所述通信设备的TCP协议实体发送所述已经正确接收的TCP数据包的TCP确认报文。
具体的，RLC协议实体12具体用于，根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
具体的，RLC协议实体12具体用于，根据当前接收到的RLC确认报文生成TCP确认报文，并将生成的TCP确认报文发送给对端通信设备。
具体的，RLC协议实体12生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是RLC协议实体生成的。
基于相同的技术构思，本发明实施例八提供了一种通信设备。在将所述通信设备应用于用户设备和网络设备进行通信的过程中，所述通信设备为UE，则对端通信设备为RNC；或者所述通信设备为RNC，则对端通信设备为UE。
参见图12，为本发明实施例八提供的设备的结构示意图。如图所示，该通信设备20可包括：接口模块21、处理器22和存储器23，其中，接口模块21与处理器22连接，处理器22和存储器23连接，上述各模块的连接方式也可以是总线方式，即各模块通过数据总线进行信息交互。
接口模块21可以由能够进行无线信号处理的电路实现，比如可包括天线、射频模块等，用于与其它通信设备进行空口通信，包括接收或/和发送空口报文，比如数据报文或协议报文。接口模块21接收到其它设备发送的报文并进行解调等处理后，发送给处理器22。接口模块21接收到处理器22发送的报文后，进行调制等处理并发送给其它通信设备。
存储器23可以由寄存器、ROM等存储器件实现，其中可以存储***数据，也可以存储处理器22处理过程中生成的临时数据或中间数据等。
处理器22可以由处理芯片实现，其中安装有通信应用软件，用于根据数据传输模型中定义的各层协议对传输的数据进行处理。根据数据传输模型定义的协议层，处理器22中可包含各协议层对应的协议实体（也即功能模块），用来实现对传输数据进行对应协议层的处理。处理器22在接收到接口模块21发送来的报文后，按照处理器22中的各层协议实体从底层到高层的顺序进行协议处理。处理器22将需要发送的报文，按照处理器22中的各层协议实体从高层到底层的顺序进行协议处理，并将处理后的报文发送给接口模块21，以便通过接口模块21发送出去。处理器22在进行数据处理过程中，将临时数据或中间数据存储在存储器23中，以便在需要时读取存储器23中存储的数据。
上述所列举的各模块的具体实现方式仅为举例说明，不构成对本发明实施例的限制。
处理器22中，与本发明实施例相关的协议实体包括RLC协议实体和TCP协议实体。处理器22中可安装如图11所示的协议实体，下面进行描述。
处理器22中安装如图11所示的RLC协议实体和TCP协议实体。此种情况下：
接口模块21用于接收对端通信设备发送的报文（比如数据报文或数据报文的确认报文），并发送给处理器22；或者，将向对端通信设备发送报文。
处理器22接收接口模块21发来的数据报文，按照数据传输模型定义的协议层，通过对应协议实体进行协议处理。其中：
处理器22中的TCP协议实体11，向RLC协议实体12发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包。处理器22中的TCP协议实体11还可以接收RLC协议实体12发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包。
处理器22中的RLC协议实体12，在接收到TCP协议实体11发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；以及，接收到对端通信设备发送的RLC确认报文（该RLC确认报文通过接口模块21接收）后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向TCP协议实体11发送TCP确认报文。
进一步的，RLC协议实体12在接收到所述TCP协议实体发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文（该RLC确认报文通过接口模块21发送给对端通信设备）。
具体的，RLC协议实体12具体用于：若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备（该RLC确认报文通过接口模块21发送给对端通信设备）；若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备（该TCP确认报文通过接口模块21发送给对端通信设备）。
具体的，RLC协议实体12具体用于：接收到对端通信设备的RLC协议实体发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述TCP协议实体发送TCP确认报文。
具体的，RLC协议实体12具体用于：若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备（该TCP确认报文通过接口模块21发送给对端通信设备）。
具体的，RLC协议实体12还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
具体的，RLC协议实体12具体用于，在发送RLC确认报文的时机到达时，若当前存储器22中缓存有从所述TCP协议实体接收到的未携带有数据信息的TCP确认报文，则将存储器22中缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
具体的，RLC协议实体12具体用于，若根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则向所述通信设备的TCP协议实体发送所述已经正确接收的TCP数据包的TCP确认报文（该TCP确认报文通过接口模块21发送给对端通信设备）。
具体的，RLC协议实体12具体用于，根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
具体的，RLC协议实体12具体用于，根据当前接收到的RLC确认报文生成TCP确认报文，并将生成的TCP确认报文发送给对端通信设备。
具体的，RLC协议实体12生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是RLC协议实体生成的。
基于相同的技术构思，本发明实施例九提供了一种通信设备。在将所述通信设备应用于用户设备和网络设备进行通信的过程中，所述通信设备为UE，则对端通信设备为RNC；或者所述通信设备为RNC，则对端通信设备为UE。如图13所示，该通信设备30可包括：收发器31和处理器32；
收发器31用于向处理器32发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收所述处理器发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
处理器32用于接收到收发器31发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；
收发器31还用于接收到对端通信设备发送的RLC确认报文后，若处理器32根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述收发器发送TCP确认报文。
进一步的，处理器32还用于，在接收到收发器31发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文。
具体的，处理器32具体用于，若当前时刻是RLC确认报文的发送时机，则将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中通过收发器31发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后通过收发器31发送给对端通信设备。
具体的，处理器32具体用于，接收到对端通信设备发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向收发器31发送TCP确认报文。
具体的，处理器32具体用于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文通过收发器31发送给对端通信设备。
进一步的，处理器32还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，通过收发器31将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
具体的，处理器32具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从收发器31接收到的未携带有数据信息的TCP确认报文，则将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中通过收发器31发送给对端通信设备。
具体的，处理器32具体用于，若根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则通过收发器31向所述通信设备的收发器发送所述已经正确接收的TCP数据包的TCP确认报文。
具体的，处理器32具体用于，根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
具体的，处理器32具体用于，根据当前接收到的RLC确认报文生成TCP确认报文，并通过收发器31将生成的TCP确认报文发送给对端通信设备。
具体的，处理器32生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是处理器生成的。
本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备（***）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (33)

1.一种确认报文发送方法，其特征在于，所述方法包括：
通信设备作为数据接收端时，所述通信设备的RLC协议实体单元接收到所述通信设备的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；
所述通信设备作为数据发送端时，所述通信设备的RLC协议实体单元接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备的TCP协议实体单元发送TCP确认报文。
2.如权利要求1所述的方法，其特征在于，所述通信设备的RLC协议实体单元接收到所述通信设备的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文之后，还包括：
所述通信设备的RLC协议实体单元向对端通信设备发送RLC确认报文。
3.如权利要求1所述的方法，其特征在于，根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，具体包括：
若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备；
若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备。
4.如权利要求3所述的方法，其特征在于，所述通信设备的RLC协议实体单元接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备发送TCP确认报文，具体包括：
所述通信设备的RLC协议实体单元接收对端通信设备的RLC协议实体单元发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述通信设备的TCP协议实体单元发送TCP确认报文。
5.如权利要求1所述的方法，其特征在于，根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，具体包括：
若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备。
6.如权利要求5所述的方法，其特征在于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文未发送，则将当前接收到的TCP确认报文发送给对端通信设备，具体包括：
若所述通信设备的RLC协议实体单元确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
7.如权利要求1所述的方法，其特征在于，根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理，具体包括：
所述通信设备的RLC协议实体单元在发送RLC确认报文时，若当前缓存有从所述通信设备的TCP协议实体单元接收到的TCP确认报文，则确定不向对端通信设备发送TCP确认报文，并将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
8.如权利要求1-7之一所述的方法，其特征在于，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述通信设备发送TCP确认报文，具体包括：
若所述通信设备的RLC协议实体单元根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则向所述通信设备的TCP协议实体单元发送所述已经正确接收的TCP数据包的TCP确认报文。
9.如权利要求8所述的方法，其特征在于，根据当前接收到的RLC确认报文，确认对应的TCP数据包是否已经正确接收，具体包括：
根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
10.如权利要求1-7之一所述的方法，其特征在于，所述根据当前接收到的RLC确认报文向所述通信设备发送TCP确认报文，具体包括：
所述通信设备的RLC协议实体单元根据当前接收到的RLC确认报文生成TCP确认报文，并将生成的TCP确认报文发送给对端通信设备。
11.如权利要求10所述的方法，其特征在于，所述通信设备的RLC协议实体单元生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是RLC协议实体单元生成的。
12.一种通信设备，其特征在于，包括：TCP协议实体单元和RLC协议实体单元；
所述TCP协议实体单元，用于向所述RLC协议实体单元发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收所述RLC协议实体单元发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
所述RLC协议实体单元，用于接收到所述TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；以及，接收到对端通信设备发送的RLC确认报文后，若根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述TCP协议实体单元发送TCP确认报文。
13.如权利要求12所述的通信设备，其特征在于，所述RLC协议实体单元进一步用于，在接收到所述TCP协议实体单元发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，向对端通信设备发送RLC确认报文。
14.如权利要求12所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，若当前时刻是RLC确认报文的发送时机，则确定不向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则确定向对端通信设备发送TCP确认报文，并将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后发送给对端通信设备。
15.如权利要求14所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，接收到对端通信设备的RLC协议实体单元发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述TCP协议实体单元发送TCP确认报文。
16.如权利要求12所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文发送给对端通信设备。
17.如权利要求16所述的通信设备，其特征在于，所述RLC协议实体单元还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
18.如权利要求12所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从所述TCP协议实体单元接收到的未携带有数据信息的TCP确认报文，则确定不向对端通信设备发送TCP确认报文，并将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中发送给对端通信设备。
19.如权利要求12-18之一所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，若根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则向所述通信设备的TCP协议实体单元发送所述已经正确接收的TCP数据包的TCP确认报文。
20.如权利要求19所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
21.如权利要求12-18之一所述的通信设备，其特征在于，所述RLC协议实体单元具体用于，根据当前接收到的RLC确认报文生成TCP确认报文，并将生成的TCP确认报文发送给对端通信设备。
22.如权利要求21所述的通信设备，其特征在于，所述RLC协议实体单元生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是RLC协议实体单元生成的。
23.一种通信设备，其特征在于，包括：收发器和处理器，所述处理器中包括RLC协议实体单元和TCP协议实体单元；
所述处理器中的TCP协议实体单元，用于向所述处理器中的RLC协议实体单元发送TCP确认报文，该TCP确认报文用于确认接收到对端通信设备发送的TCP数据包；以及，接收所述处理器中的RLC协议实体单元发送的TCP确认报文，该TCP确认报文表示对端通信设备已确认接收对应的TCP数据包；
所述处理器中的RLC协议实体单元，用于接收到所述处理器中的TCP协议实体单元发送的未携带有数据信息的TCP确认报文后，丢弃当前接收到的TCP确认报文，或者根据RLC确认报文的发送情况，确定是否通过所述收发器向对端通信设备发送TCP确认报文，并根据确定结果进行相应处理；还用于通过所述收发器接收到对端通信设备发送的RLC确认报文后，若所述处理器中的RLC协议实体单元根据当前接收到的RLC确认报文确定需要发送TCP确认报文，则根据当前接收到的RLC确认报文向所述处理器中的TCP协议实体单元发送TCP确认报文。
24.如权利要求23所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元还用于，在接收到所述处理器中的TCP协议实体单元发送的未携带有数据信息的TCP确认报文，并丢弃当前接收到的TCP确认报文之后，通过所述收发器向对端通信设备发送RLC确认报文。
25.如权利要求23所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体用于，若当前时刻是RLC确认报文的发送时机，则将当前接收到的TCP确认报文中的TCP确认信息携带于发送时机为当前时刻的RLC确认报文中通过所述收发器发送给对端通信设备；若当前时刻不是RLC确认报文的发送时机，则将当前接收到的TCP确认报文或者对当前接收到的TCP确认报文进行信息删减后通过所述收发器发送给对端通信设备。
26.如权利要求25所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体具体用于，通过所述处理器接收到对端通信设备发送的携带有TCP确认信息的RLC确认报文后，确定需要发送TCP确认报文，并根据当前接收到的RLC确认报文中携带的TCP确认信息，向所述收发器发送TCP确认报文。
27.如权利要求23所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体用于，若根据当前接收到的TCP确认报文确认对应的RLC确认报文已经发送，则丢弃当前接收到的TCP确认报文；否则，将当前接收到的TCP确认报文通过所述收发器发送给对端通信设备。
28.如权利要求27所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元还用于，若确认当前接收到的TCP确认报文所对应的所有RLC数据包的确认报文中还有尚未发送的RLC确认报文，则放弃对尚未发送的RLC确认报文进行发送，通过所述收发器将当前接收到的TCP确认报文发送给对端通信设备，根据当前发送的TCP确认报文所对应的RLC数据包的序列号确定下一个RLC确认报文。
29.如权利要求23所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体用于，在发送RLC确认报文的时机到达时，若当前缓存有从所述收发器接收到的未携带有数据信息的TCP确认报文，则将缓存的TCP确认报文中的TCP确认信息携带于当前时刻需要发送的RLC确认报文中通过所述收发器发送给对端通信设备。
30.如权利要求23-29之一所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体用于，若根据当前接收到的RLC确认报文，确认对应的TCP数据包已经正确接收，则通过所述收发器向所述通信设备的收发器发送所述已经正确接收的TCP数据包的TCP确认报文。
31.如权利要求30所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体用于，根据当前接收到的RLC确认报文所对应的RLC数据包，以及TCP数据包与RLC数据包的对应关系，确定与当前接收到的RLC确认报文对应的TCP数据包是否已经正确接收。
32.如权利要求23-29之一所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元具体用于，根据当前接收到的RLC确认报文生成TCP确认报文，并通过所述收发器将生成的TCP确认报文发送给对端通信设备。
33.如权利要求31所述的通信设备，其特征在于，所述处理器中的RLC协议实体单元生成的TCP确认报文中携带有指示信息，用于指示该TCP确认报文是所述处理器中的RLC协议实体单元生成的。
CN201380001014.9A 2013-05-20 2013-05-20 一种确认报文发送方法及其设备 Active CN104641719B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2013/075939 WO2014186944A1 (zh) 2013-05-20 2013-05-20 一种确认报文发送方法及其设备

Publications (2)

Publication Number Publication Date
CN104641719A CN104641719A (zh) 2015-05-20
CN104641719B true CN104641719B (zh) 2018-07-03

Family

ID=51932704

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380001014.9A Active CN104641719B (zh) 2013-05-20 2013-05-20 一种确认报文发送方法及其设备

Country Status (4)

Country Link
US (2) US9907112B2 (zh)
EP (1) EP2993954B1 (zh)
CN (1) CN104641719B (zh)
WO (1) WO2014186944A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017200435A1 (en) * 2016-05-17 2017-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Radio base station with tcp ack awareness
CN108886713B (zh) * 2016-08-11 2020-10-09 华为技术有限公司 一种数据传输方法、数据接收设备及数据发送设备
US10218484B2 (en) 2016-09-27 2019-02-26 Qualcomm Incorporated Enhanced transmission acknowledgment delivery and processing
EP3506540A4 (en) * 2016-09-28 2019-09-18 Huawei Technologies Co., Ltd. DATA TRANSMISSION METHOD, NETWORK DEVICE, AND TERMINAL DEVICE
WO2019196125A1 (en) * 2018-04-13 2019-10-17 Nokia Shanghai Bell Co., Ltd. Enhancement of medium access control subheaders
CN111181697A (zh) * 2018-11-13 2020-05-19 三星电子株式会社 用于tcp ack包的传输的方法和***
CN111435866B (zh) * 2019-01-14 2023-02-10 华为技术有限公司 数据传输方法及相关装置
CN111865828A (zh) * 2020-07-24 2020-10-30 展讯通信（上海）有限公司 数据传输方法、***、电子设备及存储介质
CN117335932A (zh) * 2021-09-02 2024-01-02 苹果公司 用于新无线电的无线电链路控制累积模式

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102007812A (zh) * 2008-02-12 2011-04-06 Ip无线有限公司 Tcp流控制的方法和设备
CN102017505A (zh) * 2008-03-04 2011-04-13 索尼公司 管理tcp数据段的传输的方法和设备

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6463055B1 (en) * 1998-06-01 2002-10-08 Telefonaktiebolaget L M Ericsson (Publ) Integrated radio telecommunications network and method of interworking an ANSI-41 network and the general packet radio service (GPRS)
EP1361721A1 (en) * 2002-05-06 2003-11-12 Alcatel Method for transporting data segments and corresponding transmitter and receiver
KR100802619B1 (ko) * 2002-11-07 2008-02-13 엘지전자 주식회사 무선 링크 제어 프로토콜에 따르는 수신기에서의 알엘씨데이터 수신 윈도우 처리 방법
JP5258791B2 (ja) * 2007-02-02 2013-08-07 インターデイジタル テクノロジー コーポレーション フレキシブルｒｌｃｐｄｕサイズのためにｒｌｃを機能強化する方法および装置
CN101267582B (zh) * 2007-03-15 2011-03-09 展讯通信（上海）有限公司 高速下行分组接入下省略rlc确认性状态报告的方法及***
EP2140632B1 (en) * 2007-03-16 2018-10-24 InterDigital Technology Corporation Wireless communication method and apparatus for supporting reconfiguration of radio link control parameters
EP1983698B1 (en) * 2007-04-20 2010-10-13 Panasonic Corporation Improved transmission scheme of protocol data units during a procedure that comprises the reset of the protocol layer
US9392504B2 (en) * 2007-06-19 2016-07-12 Qualcomm Incorporated Delivery of handover command
KR101513033B1 (ko) * 2007-09-18 2015-04-17 엘지전자 주식회사 다중 계층 구조에서 ＱｏＳ를 보장하기 위한 방법
TWM357138U (en) * 2007-09-28 2009-05-11 Interdigital Patent Holdings Wireless transmit receive unit
PL2208301T3 (pl) * 2007-10-01 2019-07-31 Interdigital Patent Holdings, Inc. Sposób i urządzenie do odrzucania pdcp
CN101335603B (zh) * 2008-07-17 2011-03-30 华为技术有限公司 数据传输方法和装置
CN101534573A (zh) * 2008-11-20 2009-09-16 上海交通大学 无线自组织网络中链路层实现传输层确认的方法
US8942192B2 (en) * 2009-09-15 2015-01-27 Qualcomm Incorporated Methods and apparatus for subframe interlacing in heterogeneous networks
US8279822B2 (en) * 2009-12-30 2012-10-02 Motorola Mobility Llc Method and apparatus for scheduling an acknowledgement in a wireless communication system
US10404427B2 (en) * 2010-06-09 2019-09-03 Samsung Electronics Co., Ltd. Mobile communication system and packet control method in the mobile communication system
KR101707271B1 (ko) * 2010-10-01 2017-02-15 인터디지탈 패튼 홀딩스, 인크 복수의 송신 포인트로부터의 수신을 가능케 하는 ｍａｃ 및 ｒｌｃ 아키텍쳐 및 프로시져
CN102761905B (zh) * 2011-04-26 2016-03-30 华为技术有限公司 消息处理方法、设备及***
US9294926B2 (en) * 2011-10-07 2016-03-22 Interdigital Patent Holdings, Inc. Method and apparatus for integrating different radio access technologies using carrier aggregation
EP2912879B1 (en) * 2012-10-26 2019-07-03 Telefonaktiebolaget LM Ericsson (publ) Introducing simple rlc functionality to node b
US10009212B2 (en) * 2013-06-11 2018-06-26 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for activation and deactivation of radio network functionality
US9648514B2 (en) * 2013-08-09 2017-05-09 Blackberry Limited Method and system for protocol layer enhancements in data offload over small cells
WO2015024215A1 (en) * 2013-08-21 2015-02-26 Qualcomm Incorporated Pucch resource mapping an harq-ack feedback
US20150085749A1 (en) * 2013-09-26 2015-03-26 Qualcomm Incorporated Mechanism to exchange proprietary signaling messages between a ue and a network
EP2854444A1 (en) * 2013-09-27 2015-04-01 Panasonic Intellectual Property Corporation of America Efficient uplink scheduling mechanism for dual connectivity
US20150173118A1 (en) * 2013-12-18 2015-06-18 Qualcomm Incorporated Flexible extended signaling

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102007812A (zh) * 2008-02-12 2011-04-06 Ip无线有限公司 Tcp流控制的方法和设备
CN102017505A (zh) * 2008-03-04 2011-04-13 索尼公司 管理tcp数据段的传输的方法和设备

Also Published As

Publication number Publication date
US9907112B2 (en) 2018-02-27
US20160073449A1 (en) 2016-03-10
US20180132306A1 (en) 2018-05-10
US10321514B2 (en) 2019-06-11
EP2993954B1 (en) 2019-10-02
EP2993954A4 (en) 2016-04-13
EP2993954A1 (en) 2016-03-09
CN104641719A (zh) 2015-05-20
WO2014186944A1 (zh) 2014-11-27

Similar Documents

Publication Publication Date Title
CN104641719B (zh) 一种确认报文发送方法及其设备
JP4906844B2 (ja) 無線移動通信システムで下位階層データブロックを生成する方法
JP4016032B2 (ja) 無線移動通信システムにおける受信ウインドウ移動方法
AU2007203852B2 (en) Transmitting data in a mobile communication system
JP4668207B2 (ja) 移動通信システムにおけるパケット再送方法及びそのプログラムが記録されたコンピュータで読取り可能な記録媒体
CN106027211B (zh) 在多层结构中确保QoS的方法
JP5572220B2 (ja) 断片化パッキング拡張ヘッダーを伴うｍａｃｐｄｕを伝送する方法及び装置
JP2008042935A5 (zh)
TWI425794B (zh) 在一行動通訊系統中傳輸資料的方法
CN107592329A (zh) 一种数据处理方法及装置
CN102739349B (zh) 一种用于帧确认的方法和装置
TWI489842B (zh) 無線通訊系統處理動態封包重傳的方法及其相關裝置
CN107172649A (zh) 一种数据传输方法及设备
CN107276727A (zh) 一种进行反馈的方法和设备
CN102158899A (zh) 中继网络中的数据转发方法、装置及***
WO2018027814A1 (zh) 一种数据传输方法、数据接收设备及数据发送设备
CN103716141B (zh) 在移动通信***中用于用户设备的信号传输方法和装置
CN103999394B (zh) 数据重传、反馈方法，以及相应的装置
CN102355328A (zh) 数据处理方法和设备
CN104618075B (zh) Tti集束的传输处理方法及装置、网络侧设备、ue
CN103840927B (zh) 数据传输的方法和相关设备
CN108173632A (zh) 数据处理的方法、发送设备和接收设备
JP5784834B2 (ja) ステータスレポートの処理方法、通信装置及び通信システム
CN105429737A (zh) 一种用于帧确认的方法和装置
CN101350836A (zh) 一种码分多址***中信息传输的联动方法和设备

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant