WO2011079777A1 - 数据传输的方法和网络侧设备 - Google Patents

数据传输的方法和网络侧设备 Download PDF

Info

Publication number
WO2011079777A1
WO2011079777A1 PCT/CN2010/080366 CN2010080366W WO2011079777A1 WO 2011079777 A1 WO2011079777 A1 WO 2011079777A1 CN 2010080366 W CN2010080366 W CN 2010080366W WO 2011079777 A1 WO2011079777 A1 WO 2011079777A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
request process
retransmission request
retransmission
status information
Prior art date
Application number
PCT/CN2010/080366
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 EP10840566A priority Critical patent/EP2521299A4/en
Publication of WO2011079777A1 publication Critical patent/WO2011079777A1/zh
Priority to US13/535,503 priority patent/US20120266038A1/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
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1896—ARQ related signaling
    • 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/1822—Automatic repetition systems, e.g. Van Duuren systems involving configuration of automatic repeat request [ARQ] with parallel processes

Definitions

  • ARQ automatic repeat request
  • Hybrid ARQ Hybrid ARQ, HARQ for short
  • ARQ has time diversity gain, and the sender sends one frame of data. If the receiver finds that the frame has an error, it will notify the sender to resend. At this time, the sender resends the same data as the previous frame; usually the receiver will discard it.
  • HARQ has merge gain and time diversity gain. If the receiving end receives an unrepairable error frame, it will notify the sender to retransmit the frame, but the receiver will not discard the error frame, but store it and wait for the sender.
  • the transmitted frames are combined according to a certain strategy and then decoded.
  • HARQ combines the information useful in the error frame with the information in the retransmission frame to obtain maximum efficiency, and the timeliness and reliability of feedback are higher than ARQ.
  • the receiver may not receive the correct data even after HARQ retransmission. Therefore, after the HARQ operation, a certain bit error rate will remain, and these error rates have an adverse effect on the normal operation of the upper layer protocol (such as TCP).
  • the Partnership Program (3GPP) system combines ARQ and HARQ to supplement the lack of HARQ transmission through ARQ, which together ensure the reliability of data transmission in the wireless link.
  • the prior art combines ARQ and HARQ to serially retransmit the same data, such as using HARQ sequencing and ARQ sequencing.
  • HARQ first performs data retransmission, and after HARQ retransmission fails, ARQ The data is retransmitted based on the feedback information of the receiving end (such as a NACK message).
  • the prior art combines ARQ and HARQ to perform parallel retransmission of the same data, such as: HARQ is not sorted and ARQ sorting, HARQ retransmission and ARQ are retransmitted in parallel, or ARQ is only based on timeout retransmission, not based on the receiving end.
  • the NACK message retransmits the data.
  • the present invention provides a data transmission method and a network side device for improving the utilization of spectrum resources in the process of reliable data transmission.
  • An embodiment of the present invention provides a data transmission method, including:
  • the requesting process is located at a different layer that performs the transmission processing on the data, and the layer where the first retransmission request process is located is higher than the layer where the second retransmission request process is located;
  • the second retransmission request process sends the data, the second retransmission request process, according to the sending status of the data and the mapping relationship, updating the sending status information of the data in the first retransmission request process, so that the first The retransmission request process determines whether to retransmit the data according to the transmission status information of the data.
  • the embodiment of the invention further provides a network side device, including:
  • mapping module configured to establish a mapping relationship between a first identifier of the data to be sent in the first retransmission request process and a second identifier of the data in the second retransmission request process, where the first retransmission request process and the The second retransmission request process is located at a different layer that performs the transmission processing on the data, and the layer where the first retransmission request process is located is higher than the layer where the second retransmission request process is located;
  • a sending status update module configured to send the data, where the second retransmission request process updates the sending status information of the data in the first retransmission request process according to the sending status of the data and the mapping relationship And determining, by the first retransmission request process, whether to retransmit the data according to the sending status information of the data.
  • the first retransmission request process and the second retransmission request process share the transmission status information of the same data, and the first retransmission request process located at the upper layer needs to be located at the lower layer.
  • the second retransmission request process data transmission state determines a retransmission mechanism, thereby reducing the dependency of the first retransmission request process on the feedback information in determining the retransmission mechanism, and further reducing the secondary retransmission request process.
  • FIG. 1 is a flowchart of a method for data transmission according to a first embodiment of the present invention
  • FIG. 2 is a flowchart of a method for data transmission according to a second embodiment of the present invention.
  • FIG. 3 is a flowchart of a method for data transmission according to a third embodiment of the present invention.
  • FIG. 4 is a schematic structural diagram of a network side device according to a fourth embodiment of the present invention.
  • the technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of them. Example. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without any inventive effort are within the scope of the present invention.
  • FIG. 1 is a flowchart of a method for data transmission according to a first embodiment of the present invention. As shown in FIG. 1, the data transmission method in this embodiment includes:
  • Step 11 Establish a mapping relationship between the first identifier of the data to be sent in the first retransmission request process and the second identifier of the data in the second retransmission request process, where the first retransmission request process and the second The requesting process is located at a different layer for transmitting data, and the layer of the first retransmission request process is higher than the layer where the second retransmission request process is located.
  • the data layering processing model may also be different according to the actual application communication protocol.
  • the first retransmission request process and the second retransmission request process are located at different layers of the data transmission processing, and the first retransmission request process is located.
  • the layer is higher than the layer where the second retransmission request process is located.
  • a mapping relationship is established between the layer where the first retransmission request process is located and the identifier used by the second retransmission request process for the same data packing process, so that the second retransmission request process is based on the mapping relationship.
  • locating the transmission status information of the same data in the first retransmission request process where the transmission status information includes status information such as first transmission or retransmission.
  • Step 12 Send the foregoing data, and the second retransmission request process updates the sending status information of the data in the first retransmission request process according to the sending status of the data and the mapping relationship, so that the first retransmission request process sends the data according to the data.
  • Status information determine whether to retransmit the data.
  • the second retransmission request process starts the monitoring of the data sending state, and updates the sending status information of the data in the first retransmission request process according to the sending status of the data and the mapping relationship, where the sending status information includes the first transmission or the retransmission. status information.
  • the sending status information of the data in the first retransmission request process includes: a first status or a second status or a third status, where the first status indicates that the second retransmission request process is processing the data, and the second status Indicates that the second retransmission request process has successfully sent the data, and the third state indicates that the second retransmission request process reaches the maximum number of retransmissions and discards the retransmission of the data, or an exception occurs and the data is retransmitted.
  • Whether the first retransmission request process needs to retransmit the data is determined according to the sending status information of the data in the first retransmission request process. If the sending status information of the data in the first retransmission request process is the first state or the second state, the data is not retransmitted to the terminal regardless of whether the first retransmission request process receives the ARQ NACK message fed back by the terminal. If the sending information of the data in the first retransmission request process is in the third state, the operation of retransmitting data to the terminal is triggered immediately regardless of whether the ARQ receives the IJ ARQ NACK message.
  • the first retransmission request process and the second retransmission request process share the transmission status information of the same data at the transmitting end, and the first retransmission request process located at the upper layer needs to be based on the lower layer.
  • the retransmission request process data transmission state determines the retransmission mechanism, thereby reducing the dependency of the first retransmission request process on the feedback information in the process of determining the retransmission mechanism, and avoiding the secondary retransmission request process to retransmit the resources in parallel. Waste, improve the utilization of spectrum resources in the process of reliable data transmission, and improve the reliability and effectiveness of data transmission.
  • the technical solution of the embodiments of the present invention can be applied to technologies with both ARQ and HARQ standards, and can also be used in cross-layer design, such as HARQ and TCP proxy, or ARQ and TCP proxy, or between HARQ & ARQ and TCP proxy.
  • the mechanism of level or multi-level retransmission feedback it is used to improve the utilization of spectrum resources in the process of reliable data transmission.
  • the first retransmission request process is an ARQ process
  • the second retransmission request process is an HARQ process.
  • the retransmission request process that constitutes the secondary or multi-level feedback mechanism is the other mechanism described above.
  • the manner in which the data transmission status information is shared on the transmitting end is similar, and is not described here.
  • FIG. 2 is a flowchart of a method for data transmission according to a second embodiment of the present invention.
  • the hierarchical structure of the data encapsulation process includes: an application layer/TCP layer/IP layer/media access control (MAC) layer/physical layer, and the first retransmission request process is an ARQ process.
  • the second retransmission request process is a HARQ process, the ARQ process is located at the MAC layer, and the HARQ process is located at the physical layer.
  • the data transmission method in this embodiment includes:
  • Step 21 Establish a mapping relationship between the ARQ block (BLOCK) and the HARQ fragment (Subburst) for the data to be sent.
  • ARQ packs data with BLOCK granularity
  • the service data unit (SDU) obtained by the high-level packet processing of the data to be transmitted enters the MAC layer, and the MAC layer performs packetization and block processing according to the BLOCK size of the ARQ, for example, the SDU is added with the MAC header and the CRC check bit to form the MAC layer.
  • PDU each BLOCK in the PDU has a corresponding ARQ BSN number.
  • the PDUs that have been processed by the MAC layer are processed into the physical layer.
  • the physical layer multiplexes the PDUs of the MAC layer into the granularity of the Subburst size of the HARQ.
  • the PDUs are cascaded (Padding) and 16 bits are added.
  • the CRC check bit which forms the Subburst of HARQ.
  • each PDU in the Subburst carries the ARQ BSN number corresponding to the BLOCK, which is equivalent to establishing a mapping relationship between the ARQ BLOCK and the HARQ Subburst.
  • Step 22 Send the foregoing data to the terminal, and the HARQ process actively updates the status bit information of the descriptor of the BLOCK in the ARQ process according to the sending status of the BLOCK of the data in the HARQ Subburst and the mapping relationship, where the status bit information is used to indicate The HARQ process is about the sending status of the BLOCK.
  • a status bit is added in the ARQ BLOCK descriptor to indicate three states of the BLOCK under the HARQ: the first state, the second state, or the third state, optionally
  • the above three states can be represented by three different status bits, for example, status bit "01", status bit “10” and status bit "11", and status bit information corresponding to status bit "01” is " HARQ". Processing".
  • the status bit information corresponding to the status bit "10” is " HARQ sent successfully", which is used to indicate that the HARQ has been sent or retransmitted successfully.
  • the status bit information corresponding to the status bit "11" is " HARQ Abandoned Transmission", which is used to indicate that the HARQ reaches the maximum number of retransmissions and discards the retransmission of the data, or an exception occurs and the retransmission of the data is abandoned.
  • the status bits and their meanings are shown in Table 1: Table 1
  • the HARQ can update the ARQ process at the following timing.
  • the HARQ process updates the mapping relationship, if the HARQ process completes the reassembly of the MAC PDU, the HARQ process may locate the status descriptor of the corresponding BLOCK according to the ARQ BLOCK BSN number corresponding to the HARQ Subburst, and write in the status descriptor of the BLOCK.
  • the status bit "01" is used to indicate that the HARQ process sends status information to the data as "HARQ is processing".
  • the HARQ process can be based on the ARQ BLOCK corresponding to the HARQ Subburst.
  • the BSN number locates the status descriptor of the corresponding BLOCK, and writes the status bit to "10" in the status descriptor of the BLOCK, which is used to indicate that the HARQ process sends the status information to the data as " HARQ transmission succeeded”.
  • the HARQ process may locate the status descriptor of the corresponding BLOCK according to the ARQ BLOCK BSN number corresponding to the HARQ Subburst, and write in the status descriptor of the BLOCK.
  • the incoming status bit is "11", which is used to indicate that the HARQ process sends status information to the data as "HARQ Abandoned Send".
  • the HARQ process may locate the status descriptor of the corresponding BLOCK according to the ARQ BLOCK BSN number corresponding to the HARQ Subburst, and write the status descriptor in the BLOCK.
  • the status bit is "11", which is used to indicate that the HARQ process sends status information to the data as " HARQ Abandoned Send".
  • Step 23 The ARQ process determines, according to the status bit information in the BLOCK descriptor, whether the ARQ process retransmits the data to the terminal.
  • Whether the ARQ process needs to retransmit the BLOCK to the terminal is determined according to the status bit information in the BLOCK descriptor in the ARQ process. If the status bit information in the BLOCK descriptor in the ARQ process is the first state or the second state, the ARQ process does not retransmit the data to the terminal whether the ARQ process receives the ARQ NACK message fed back by the terminal. If the status bit information in the BLOCK descriptor in the ARQ process is in the third state, the operation of retransmitting data to the terminal is triggered immediately regardless of whether the ARQ receives the ARQ NACK message.
  • the ARQ when receiving the BACK NACK message fed back by the terminal, the ARQ needs to determine whether the BL0CK needs to be retransmitted to the terminal according to the BLOCK status bit information.
  • the status bit information in the BLOCK descriptor, and the ARQ retransmission processing of the ARQ when the ARQ receives the NACK message of the BLOCK fed back by the terminal is as shown in Table 2:
  • Packet loss such as ARQ's analog packet loss, ARQ still does not retransmit
  • the HARQ process is based on the HARQ Subburst and the ARQ BLOCK.
  • the state of the HARQ transmission BLOCK is written in the status bit of the BLOCK state descriptor in the ARQ process, and the ARQ process and the HARQ process are shared with the same BLOCK transmission state information at the transmitting end, and the ARQ process located at the upper layer needs Determining a retransmission mechanism according to the BLOCK transmission state of the lower layer HARQ process, thereby reducing the dependency of the feedback NACK information in the ARQ determining retransmission mechanism, and reducing the feedback delay due to the ARQ NACK information and the roughness of the lost data details.
  • the probability of occurrence of inaccurate ARQ retransmission and inaccurate retransmission is avoided, which avoids waste of resources caused by parallel retransmission of the secondary retransmission request process, and improves the utilization of spectrum resources in the process of reliable data transmission.
  • FIG. 3 is a flowchart of a method for data transmission according to a third embodiment of the present invention.
  • the difference between the embodiment and the embodiment of FIG. 2 is that the state of the BLOCK sent by the HARQ process to the ARQ process is different.
  • the HARQ process performs feedback by constructing a feedback message of the ARQ. As shown in FIG. 3, this embodiment includes:
  • Step 31 Establish a mapping relationship between the ARQ BLOCK and the HARQ Subburst for the data to be sent. This step is similar to step 21 and will not be described here.
  • Step 32 Send the foregoing data to the terminal, and the HARQ process sends a feedback message to the ARQ according to the BLOCK transmission status of the data in the HARQ Subburst and the mapping relationship.
  • the feedback messages originally included in the ARQ process include: ACK (acknowledgement) message and NACK (no acknowledgement) message. If the terminal successfully receives the data, it will feed back the ACK message to the ARQ process. If the terminal receives the data error or discards, it will feed back the NACK message to the ARQ process to request the ARQ to retransmit the data.
  • ACK acknowledgement
  • NACK no acknowledgement
  • the HARQ constructs a feedback message of the ARQ according to the state of the Subburst transmitted by itself and the BLOCK BSN number corresponding to the Subburst.
  • the format of the feedback message sent by the HARQ process to the ARQ process is the same as the format of the original feedback message of the ARQ process (such as an ACK message or a NACK message).
  • a flag bit may be added to the original feedback message format, where the flag bit is used to indicate that the feedback message is from a HARQ process.
  • the feedback message of the HARQ process may be in a state of “0” or “1”, and is used to notify the ARQ process that the HARQ process sends a BLOCK. Is "failed” or "successful".
  • Step 33 When receiving the feedback message sent by the HARQ process, the ARQ process parses the content of the feedback message, and updates status bit information of the corresponding BLOCK descriptor in the ARQ process according to the parsing result, where the status bit information is used to indicate that the HARQ process is related to the BLOCK. The status of the transmission.
  • the status bit information of the BLOCK descriptor is as shown in Table 1 above.
  • the ARQ process parses the content of the feedback message. For example, if the value of the newly added flag bit in the feedback message is "1", it indicates that the HARQ process has successfully sent the BLOCK, and the ARQ process will The state of the BLOCK is in the second state, such as "HARQ sent successfully.” If the value of the newly added flag bit in the feedback message is “0”, it indicates that the HARQ process fails to send the BLOCK, and the ARQ process sets the state of the BLOCK to the second state, such as “HARQ abandons retransmission”.
  • Step 34 The ARQ process determines, according to the status bit information in the BLOCK descriptor, whether the ARQ process retransmits the data to the terminal.
  • This step is similar to step 23 and will not be described here.
  • the HARQ process constructs the state of the HARQ transmission BLOCK into an ARQ feedback message according to the mapping relationship between the HARQ Subburst and the ARQ BLOCK, and sends the status to the ARQ process, and the ARQ process updates the corresponding message according to the HARQ feedback message.
  • the ARQ process and the HARQ process are shared with the same BLOCK transmission state information at the transmitting end, and the ARQ process located at the upper layer needs to be determined according to the BLOCK transmission state of the lower layer HARQ process.
  • FIG. 4 is a schematic structural diagram of the network side device according to the fourth embodiment of the present invention.
  • the network side device in this embodiment includes: a mapping module 41 and a sending status updating module 42.
  • the mapping module 41 is configured to establish a mapping relationship between the first identifier of the data to be sent in the first retransmission request process and the second identifier of the data in the second retransmission request process, the first retransmission request process and the second retransmission
  • the request process is located at a different layer for transmitting data, and the layer of the first retransmission request process is higher than the layer where the second retransmission request process is located.
  • the sending status update module 42 is configured to send data, and the second retransmission request process updates the sending status information of the data in the first retransmission request process according to the sending status of the data and the mapping relationship, so that the first retransmission request process Determining whether to retransmit the data based on the transmission status information of the data.
  • the sending status information of the foregoing data includes a first status or a second status or a third status.
  • the first state indicates that the HARQ process is processing the data; the second state indicates that the HARQ process successfully retransmits the data; the third state indicates that the HARQ process reaches the maximum number of retransmissions and discards the retransmission of the data, or an exception occurs and the retransmission is abandoned. data.
  • the transmission status update module 42 may include at least one of the following: a first update unit 421, a second update unit 422, a third update unit 423, and a fourth update unit 424.
  • the first update unit 421 is configured to update, when the second retransmission request process updates the mapping relationship, the sending status information of the data in the second retransmission request process to the first status.
  • the first update unit 421 is specifically configured to: when the HARQ process updates the foregoing mapping relationship, update the sending state information of the data in the ARQ process.
  • the second update unit 422 is configured to update, when the second retransmission request process successfully retransmits the data, the sending status information of the data in the first retransmission request process to the second status.
  • the optional second update unit 422 is specifically configured to update the sending status information of the data in the ARQ process when the HARQ process successfully retransmits the data.
  • the third update unit 423 is configured to update the transmission status information of the data in the first retransmission request process to the third state when the second retransmission request process retransmits the data to the maximum number of times and discards the retransmission of the data.
  • the third update unit 423 is specifically configured to update the sending status information of the data in the ARQ process when the HARQ process retransmits the data to the maximum number of times and discards the retransmission of the data.
  • the fourth updating unit 424 is configured to update the transmission state information of the data in the first retransmission request process to the third state when the second retransmission request process sends the data abnormality and discards the retransmission of the data.
  • the fourth update unit 424 is specifically configured to update the sending status information of the data in the ARQ process when the HARQ process sends an abnormality in the data and discards the retransmission of the data.
  • the ARQ process retransmits the data to the terminal. If the status information of the data sent in the ARQ process is the first state or the second state, the ARQ process does not retransmit the data to the terminal.
  • the first retransmission request process and the second retransmission request process share the transmission status information of the same data, and the first retransmission request process located at the upper layer needs to be based on the lower layer.
  • the retransmission request process data transmission state determines the retransmission mechanism, thereby reducing the dependency of the first retransmission request process on the feedback information in the process of determining the retransmission mechanism, and avoiding the secondary retransmission request process to retransmit the resources in parallel. Waste, improve the utilization of spectrum resources in the process of reliable data transmission.
  • modules in the devices in the embodiments may be distributed in the devices of the embodiments according to the embodiments, or may be correspondingly changed in one or more devices different from the embodiment.
  • the modules of the above embodiments may be combined into one module, or may be further split into a plurality of sub-modules.
  • the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

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

Description

数据传输的方法和网络侧设备
本申请要求于 2009年 12月 28日提交中国专利局、 申请号为 200910244073. 4、 发 明名称为 "数据传输的方法和网络侧设备"的中国专利申请的优先权， 其全部内容通过 引用结合在本申请中。 技术领域 本发明涉及通信技术领域， 特别是涉及一种数据传输的方法和网络侧设备。 背景技术 自动重传请求（Automatic Repeat Request,简称 ARQ)和混合自动重传请求（Hybrid ARQ, 简称 HARQ ) 是提高数据传输可靠性的有效手段。 ARQ具有时间分集增益， 发送端 发送一帧数据， 如果接收端发现这一帧出现错误， 就会通知发送端重发， 此时发送端重 新发送和上一帧相同的数据； 通常接收端会丢弃出错的帧并等待接收重新发送的数据。 HARQ具有合并增益和时间分集增益，如果接收端收到无法修复的错误帧，将会通知发送 端重传该帧， 但接收端不会丢弃错误帧， 而是把它存放起来等待与发送端重发的帧按照 一定的策略进行组合再进行解码。 HARQ通过将错误帧中有用的信息和重传帧中的信息进 行组合以获得最大的效率， 相对于 ARQ而言反馈的及时性和可靠性较高。 但是由于信道 变化或者信道自适应算法与信道不匹配的问题， 可能导致即使经过 HARQ重传后， 接收 端仍然没有正确的接收数据。 因此， 经过 HARQ操作后， 会残留一定的误码率， 这些误 码率对上层协议 （如 TCP ) 的正常运行造成了不良影响。
为了获得较好的数据可靠传输性能， 第三代合作组织 （Third Generation
Partnership Program , 简称 3GPP ) 系统将 ARQ和 HARQ结合起来， 通过 ARQ补充 HARQ 传输的不足， 二者共同保障无线链路中数据传输的可靠性。 现有技术将 ARQ与 HARQ配 合对同一数据进行串行重传， 如同时使用 HARQ排序和 ARQ排序， 在需要进行数据重传 时， HARQ首先进行数据重传， 且在 HARQ重传失败后， ARQ基于接收端的反馈信息 （如 NACK消息） 重传数据。 或者， 现有技术将 ARQ与 HARQ配合对同一数据进行并行重传， 如： HARQ不排序而 ARQ排序， HARQ重传与 ARQ并行重传，或者， ARQ只有基于超时重传， 而不基于接收端的 NACK消息重传数据。
发明人在实践现有技术的过程中发现， 如果采用 HARQ排序和 ARQ排序同时使能的 方式， 虽然能对同一数据进行串行重传， 但由于 ARQ重传依赖于接收端的反馈信息， 因 此引入的时延较大； 而如果采用 HARQ与 ARQ并行重传的方式， 则会导致重传带宽开销 较大， 降低了频谱资源的利用率。 发明内容
本发明提供一种数据传输的方法和网络侧设备，用以在数据可靠传输过程中提高频 谱资源的利用率。
本发明实施例提供了一种数据传输的方法， 包括：
建立第一重传请求进程中需发送的数据的第一标识与第二重传请求进程中所述数 据的第二标识的映射关系，所述第一重传请求进程和所述第二重传请求进程位于对所述 数据进行传输处理的不同层， 且所述第一重传请求进程所在的层高于所述第二重传请求 进程所在的层；
发送所述数据， 所述第二重传请求进程根据所述数据的发送状态以及所述映射关 系， 更新所述第一重传请求进程中所述数据的发送状态信息， 以使所述第一重传请求进 程根据所述数据的发送状态信息， 确定是否重传所述数据。
本发明实施例还提供了一种网络侧设备， 包括：
映射模块，用于建立第一重传请求进程中需发送的数据的第一标识与第二重传请求 进程中所述数据的第二标识的映射关系，所述第一重传请求进程和所述第二重传请求进 程位于对所述数据进行传输处理的不同层，且所述第一重传请求进程所在的层高于所述 第二重传请求进程所在的层；
发送状态更新模块， 用于发送所述数据， 所述第二重传请求进程根据所述数据的发 送状态以及所述映射关系， 更新所述第一重传请求进程中所述数据的发送状态信息， 以 使所述第一重传请求进程根据所述数据的发送状态信息， 确定是否重传所述数据。
本发明实施例在网络侧设备作为发送端时， 实现第一重传请求进程和第二重传请求 进程关于同一数据的发送状态信息的共享，位于高层的第一重传请求进程需要根据位于 低层的第二重传请求进程数据的发送状态确定重传机制， 从而降低了第一重传请求进程 确定重传机制过程中对反馈信息的依赖性， 并且， 进一步减少了因二级重传请求进程并 行重传造成的资源浪费， 在数据可靠传输的过程中提高了频谱资源的利用率。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施例或现有 技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本 发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明第一实施例提供的数据传输的方法流程图；
图 2为本发明第二实施例提供的数据传输的方法流程图；
图 3为本发明第三实施例提供的数据传输的方法流程图；
图 4为本发明第四实施例提供的网络侧设备的结构示意图。 具体实肺式 下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整 地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基 于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有 其他实施例， 都属于本发明保护的范围。
图 1为本发明第一实施例提供的数据传输的方法流程图。 如图 1所示， 本实施例数 据传输的方法包括：
步骤 11、建立第一重传请求进程中需发送的数据的第一标识与第二重传请求进程中 所述数据的第二标识的映射关系， 其中， 第一重传请求进程和第二重传请求进程位于对 数据进行传输处理的不同层， 且第一重传请求进程所在的层高于第二重传请求进程所在 的层。
网络侧设备作为发送端向接收端， 如向终端发送数据时， 需要对该数据进行多层的 封装。 根据实际应用的通信协议不同， 数据分层处理的模型也可能不同， 第一重传请求 进程和第二重传请求进程位于对数据进行传输处理的不同层， 且第一重传请求进程所在 的层高于第二重传请求进程所在的层。本步骤用于在第一重传请求进程所在的层与第二 重传请求进程所在的层对同一数据打包处理时使用的标识之间建立映射关系， 使得第二 重传请求进程根据该映射关系定位第一重传请求进程中的所述同一数据的发送状态信 息， 该发送状态信息包括首次发送或重传等状态信息。
步骤 12、发送上述数据，第二重传请求进程根据数据的发送状态以及上述映射关系， 更新第一重传请求进程中该数据的发送状态信息， 以使第一重传请求进程根据数据的发 送状态信息， 确定是否重传该数据。
网络侧设备对数据进行各层打包处理之后， 将最终打包处理后的数据发送给终端。 第二重传请求进程启动数据发送状态的监控， 并根据数据的发送状态以及上述映射关 系， 更新第一重传请求进程中该数据的发送状态信息， 该发送状态信息包括首次传输或 者重新传输的状态信息。
可选的， 第一重传请求进程中数据的发送状态信息包括： 第一状态或第二状态或第 三状态， 其中， 第一状态表示第二重传请求进程正在处理该数据， 第二状态表示第二重 传请求进程已成功发送该数据，第三状态表示第二重传请求进程达到最大重传次数且放 弃该数据的重传， 或者发生异常且放弃重传该数据。
第一重传请求进程是否需要重传该数据，是根据第一重传请求进程中数据的发送状 态信息确定的。 如果第一重传请求进程中数据的发送状态信息为第一状态或第二状态， 则无论第一重传请求进程是否接收到终端反馈的 ARQ NACK消息， 都不向终端重传该数 据。 如果第一重传请求进程中数据的发送状信息为第三状态， 则此时无论 ARQ是否接收 至 IJ ARQ NACK消息， 都立即触发向终端重传数据的操作。
本实施例数据传输的方法，在发送端实现第一重传请求进程和第二重传请求进程关 于同一数据的发送状态信息的共享，位于高层的第一重传请求进程需要根据位于低层的 第二重传请求进程数据的发送状态确定重传机制， 从而降低了第一重传请求进程确定重 传机制过程中对反馈信息的依赖性， 避免了二级重传请求进程并行重传造成资源的浪 费， 在数据可靠传输的过程中提高了频谱资源的利用率， 改善了数据传输的可靠性和有 效性。
本发明实施例的技术方案可应用在同时有 ARQ和 HARQ制式的技术中， 还可以用在 跨层设计中， 例如 HARQ与 TCP代理、 或者 ARQ与 TCP代理、 或者 HARQ&ARQ与 TCP代理 之间的二级或多级重传反馈的机制中，用以在数据可靠传输的过程中提高频谱资源的利 用率。下面各详述实施例仅以第一重传请求进程为 ARQ进程，第二重传请求进程为 HARQ 进程为例进行说明， 当组成二级或多级反馈机制的重传请求进程为上述其他机制时， 其 在发送端实现数据发送状态信息共享的方式相似， 在此不再赘述。
图 2为本发明第二实施例提供的数据传输的方法流程图。本实施例中将对数据的封 装处理的分层结构自上而下包括： 应用层 /TCP层 /IP层 /媒体访问控制 （MAC ) 层 /物理 层， 第一重传请求进程为 ARQ进程， 第二重传请求进程为 HARQ进程， ARQ进程位于 MAC 层， HARQ进程位于物理层。 如图 2所示， 本实施例数据传输的方法包括：
步骤 21、 对于待发送的数据， 建立 ARQ 块 （BLOCK) 与 HARQ分片（Subburst)之间 的映射关系。 ARQ以 BLOCK为粒度打包数据， HARQ以 Subburst为粒度打包数据。 待发送数据经 过高层打包处理得到的服务数据单元（SDU)进入 MAC层， MAC层以 ARQ的 BLOCK大小为粒 度进行打包分块处理， 如将 SDU加上 MAC头和 CRC校验位， 组成 MAC层的 PDU， 该 PDU 中每个 BLOCK都有对应的 ARQ BSN号。 经 MAC层打包处理后的 PDU进入物理层， 物理层 将 MAC层的 PDU以 HARQ的 Subburst大小为粒度进行打包分片处理， 如对各 PDU进行级 联绑定（Padding )后加上 16位的 CRC校验位， 组成 HARQ的 Subburst。 如此处理之后， Subburst中每个 PDU都携带各自 BLOCK对应的 ARQ BSN号， 即相当于建立了 ARQ BLOCK 与 HARQ Subburst 之间的映射关系。
步骤 22、 向终端发送上述数据， HARQ进程根据 HARQ Subburst中该数据的 BLOCK 的发送状态以及上述映射关系， 主动更新 ARQ进程中该 BLOCK的描述符的状态位信息， 所述状态位信息用于表示 HARQ进程关于 BLOCK的发送状态。
为了表示 BLOCK在 HARQ中的发送状态， 可选的， 在 ARQ BLOCK描述符中增加状态 位， 用于表示该 BLOCK在 HARQ下三种状态： 第一状态、 第二状态或第三状态， 可选的， 上述三种状态可分别采用三种不同的状态位进行表示， 例如状态位 " 01 "、 状态位 " 10 " 和状态位 " 11 "， 状态位 " 01 "对应的状态位信息为 " HARQ正在处理"。 状态位 " 10 "对 应的状态位信息为" HARQ发送成功"，用于表示 HARQ已经发送或重传成功。状态位 " 11 " 对应的状态位信息为 " HARQ放弃发送"，用于表示 HARQ达到最大重传次数且放弃该数据 的重传， 或者发生异常且放弃该数据的重传。 状态位各信息及其含义如表 1所示： 表 1
Figure imgf000007_0001
虽然 ARQ BLOCK的发送状态信息在 ARQ进程的 BLOCK描述符中， 但是其状态位的更 新可由 HARQ进程完成， 状态位的默认值为 " 01 "， 可选的， HARQ可在以下时机更新 ARQ 进程中该数据的发送状态信息： ( 1 ) HARQ进程更新映射关系时， 如 HARQ进程完成 MAC PDU 的重组之后， HARQ进 程可根据 HARQ Subburst对应的 ARQ BLOCK BSN号定位相应 BLOCK的状态描述符， 在该 BLOCK的状态描述符中写入状态位 " 01 "，用于表示 HARQ进程对该数据的发送状态信息 为 "HARQ正在处理"。
( 2 ) HARQ进程成功重传数据时， HARQ进程可根据 HARQ Subburst对应的 ARQ BLOCK
BSN号定位相应 BLOCK的状态描述符， 在该 BLOCK的状态描述符中写入状态位为 " 10 "， 用于表示 HARQ进程对该数据的发送状态信息为 " HARQ发送成功"。
( 3 ) HARQ进程重传该数据达到最大次数而放弃该数据的重传时， HARQ进程可根据 HARQ Subburst对应的 ARQ BLOCK BSN号定位相应 BLOCK的状态描述符， 在该 BLOCK的 状态描述符中写入的状态位为 " 11 "， 用于表示 HARQ 进程对该数据的发送状态信息为 "HARQ放弃发送"。
( 4 ) HARQ进程发送数据发生异常且放弃所述数据的重传时， HARQ进程可根据 HARQ Subburst对应的 ARQ BLOCK BSN号定位相应 BLOCK的状态描述符， 在该 BLOCK的状态描 述符中写入的状态位为 " 11 "， 用于表示 HARQ 进程对该数据的发送状态信息为 " HARQ 放弃发送"。
本领域的技术人员可以理解， 上述 （3 )和 （4 ) 描述的情况也可以分别用两种状态 信息来进行表示。
步骤 23、 ARQ进程根据 BLOCK描述符中的状态位信息， 确定 ARQ进程是否向终端重 传该数据。
ARQ进程是否需要向终端重传该 BLOCK, 是根据 ARQ进程中 BLOCK描述符中的状态 位信息确定的。 如果 ARQ进程中 BLOCK描述符中的状态位信息为第一状态或第二状态， 则无论 ARQ进程是否接收到终端反馈的 ARQ NACK消息， 都不向终端重传该数据。 如果 ARQ进程中 BLOCK描述符中的状态位信息为第三状态， 则此时无论 ARQ是否接收到 ARQ NACK消息， 都立即触发向终端重传数据的操作。
可选的， ARQ在接收到终端反馈的某 BLOCK的 NACK消息时， 需根据 BLOCK的状态位 信息， 确定是否需要向终端重传该 BL0CK。 BLOCK描述符中状态位信息， 与 ARQ接收到 终端反馈的该 BLOCK的 NACK消息时 ARQ的重传处理如表 2所示：
表 2
Figure imgf000008_0001
理
10 不重传（包括 HARQ和 ARQ之间可能发生错误或
HARQ发送成
丢包， 如 ARQ的模拟丢包等情形， ARQ仍然不重传， 功
可依赖超时机制重传）
11 HARQ放弃发 重传（包括 HARQ达到最大重传次数仍未重传成 送 功或发生异常而放弃重传等情形） 本实施例数据传输的方法， HARQ进程根据 HARQ Subburst与 ARQ BLOCK之间的映射 关系， 将 HARQ发送 BLOCK的状态写入 ARQ进程中该 BLOCK的状态描述符的状态位中， 在发送端实现 ARQ进程和 HARQ进程关于同一 BLOCK的发送状态信息的共享， 位于高层 的 ARQ进程需要根据位于低层的 HARQ进程的关于该 BLOCK发送状态确定重传机制， 从 而降低了 ARQ确定重传机制过程中对反馈 NACK信息的依赖性， 降低了由于 ARQ NACK信 息反馈延时以及丢失数据细节粗糙， 导致 ARQ重传不及时、 重传不准确的现象的发生几 率， 避免了二级重传请求进程并行重传造成资源的浪费， 在数据可靠传输的过程中提高 了频谱资源的利用率。
图 3为本发明第三实施例提供的数据传输的方法流程图。本实施例与图 2对应实施 例的区别在于， 本实施例 HARQ进程向 ARQ进程反馈的 BLOCK发送状态信息方式不同， 本实施例 HARQ进程以构建 ARQ的反馈消息的方式进行反馈。 如图 3所示， 本实施例包 括：
步骤 31、 对于待发送的数据， 建立 ARQ BLOCK与 HARQ Subburst之间的映射关系。 本步骤与步骤 21相似， 在此不再赘述。
步骤 32、 向终端发送上述数据， HARQ进程根据 HARQ Subburst中该数据的 BLOCK 的发送状态以及上述映射关系， 向 ARQ发送反馈消息。
ARQ进程原本包括的反馈消息包括： ACK (确认） 消息和 NACK (无确认） 消息。 如 果终端成功接收到数据， 则会向 ARQ进程反馈 ACK消息； 如果终端接收数据错误或丢弃 时， 则会向 ARQ进程反馈 NACK消息， 用于请求 ARQ重传该数据。
本步骤 HARQ根据自身发送 Subburst的状态以及 Subburst对应的 BLOCK BSN号， 构造 ARQ的反馈消息。 HARQ进程向 ARQ进程发送的反馈消息的格式与 ARQ进程原反馈消 息 （如 ACK消息或 NACK消息） 的格式相同。 可选的， 也可以在原反馈消息格式的基础 上增加一标志位， 该标志位用于表示该反馈消息来自 HARQ进程。进一步， 可选的， HARQ 进程的反馈消息可用 " 0 "或" 1 "两种状态，用于通知 ARQ进程所述 HARQ进程发送 BLOCK 是 "失败"或 "成功"。
步骤 33、 ARQ进程接收 HARQ进程发送的反馈消息时， 解析该反馈消息的内容， 并 根据解析结果更新 ARQ进程中相应 BLOCK描述符的状态位信息，所述状态位信息用于表 示 HARQ进程关于 BLOCK的发送状态。
BLOCK描述符的状态位信息如上述表 1所示。 ARQ进程接收到来自 HARQ进程的反馈 消息时， 解析该反馈消息的内容， 例如， 如果该反馈消息中新增标志位的值为 " 1 "， 则 表示 HARQ进程已经成功发送该 BLOCK, ARQ进程将该 BLOCK的状态位置于第二状态， 如 "HARQ发送成功"。如果该反馈消息中新增标志位的值为" 0 "， 则表示 HARQ进程发送该 BLOCK失败， ARQ进程将该 BLOCK的状态位置于第二状态， 如 "HARQ放弃重传"
步骤 34、 ARQ进程根据 BLOCK描述符中的状态位信息， 确定 ARQ进程是否向终端重 传该数据。
本步骤与步骤 23相似， 在此不再赘述。
本实施例数据传输的方法， HARQ进程根据 HARQ Subburst与 ARQ BLOCK之间的映射 关系， 将 HARQ发送 BLOCK的状态构造成 ARQ的反馈消息并发送给 ARQ进程， 由 ARQ进 程根据 HARQ的反馈消息更新相应 BLOCK的状态描述符的状态位中， 从而在发送端实现 ARQ进程和 HARQ进程关于同一 BLOCK的发送状态信息的共享，位于高层的 ARQ进程需要 根据位于低层的 HARQ进程的关于该 BLOCK发送状态确定重传机制， 因而降低了 ARQ确 定重传机制过程中对反馈 NACK信息的依赖性， 降低了由于 ARQ NACK信息反馈延时以及 丢失数据细节从而导致 ARQ重传不及时、 重传不准确的现象的发生几率， 避免了二级重 传请求进程并行重传造成资源的浪费，在数据可靠传输的过程中提高了频谱资源的利用 碎- 图 4为本发明第四实施例提供的网络侧设备的结构示意图。 如图 4所示， 本实施例 网络侧设备包括： 映射模块 41和发送状态更新模块 42。
映射模块 41用于建立第一重传请求进程中需发送的数据的第一标识与第二重传请 求进程中该数据的第二标识的映射关系，第一重传请求进程和第二重传请求进程位于对 数据进行传输处理的不同层， 且第一重传请求进程所在的层高于第二重传请求进程所在 的层。
发送状态更新模块 42用于发送数据， 第二重传请求进程根据数据的发送状态以及 上述映射关系， 更新第一重传请求进程中数据的发送状态信息， 以使所述第一重传请求 进程根据所述数据的发送状态信息， 确定是否重传所述数据。 在上述技术方案的基础上， 可选的， 上述数据的发送状态信息包括第一状态或第二 状态或第三状态。 第一状态表示 HARQ进程正在处理该数据； 第二状态表示 HARQ进程成 功重传该数据； 第三状态表示 HARQ进程达到最大重传次数且放弃该数据的重传， 或者 发生异常且放弃重传该数据。
在上述技术方案的基础上， 可选的， 第一重传请求进程为 ARQ进程， 第二重传请求 进程为 HARQ进程。发送状态更新模块 42可包括以下至少一个单元：第一更新单元 421、 第二更新单元 422、 第三更新单元 423和第四更新单元 424。
第一更新单元 421用于在第二重传请求进程更新上述映射关系时， 更新第二重传请 求进程中该数据的发送状态信息为第一状态。 可选的， 第一更新单元 421可具体用于在 HARQ进程更新上述映射关系时， 更新 ARQ进程中该数据的发送状态信息。
第二更新单元 422用于在第二重传请求进程成功重传该数据时， 更新第一重传请求 进程中该数据的发送状态信息为第二状态。可选的第二更新单元 422可具体用于在 HARQ 进程成功重传数据时， 更新 ARQ进程中该数据的发送状态信息。
第三更新单元 423用于在第二重传请求进程重传该数据达到最大次数而放弃该数据 的重传时， 更新第一重传请求进程中该数据的发送状态信息为第三状态。 可选的， 第三 更新单元 423可具体用于在 HARQ进程重传数据达到最大次数而放弃该数据的重传时， 更新 ARQ进程中该数据的发送状态信息。
第四更新单元 424用于在第二重传请求进程发送该数据发生异常且放弃该数据的重 传时， 更新第一重传请求进程中该数据的发送状态信息为第三状态。 可选的， 第四更新 单元 424可具体用于在 HARQ进程发送数据发生异常且放弃该数据的重传时，更新所 ARQ 进程中该数据的发送状态信息。
如果 ARQ进程中发送数据的状态信息为第三状态， 则 ARQ进程向终端重传该数据。 如果 ARQ进程中发送数据的状态信息为第一状态或第二状态， 则 ARQ进程不向终端 重传该数据。
本实施例网络侧设备作为发送端时， 实现第一重传请求进程和第二重传请求进程关 于同一数据的发送状态信息的共享，位于高层的第一重传请求进程需要根据位于低层的 第二重传请求进程数据的发送状态确定重传机制， 从而降低了第一重传请求进程确定重 传机制过程中对反馈信息的依赖性， 避免了二级重传请求进程并行重传造成资源的浪 费， 在数据可靠传输的过程中提高了频谱资源的利用率。 本实施例网络侧设备的实现机 理可参见图 1-图 3对应实施例的记载， 在此不再赘述。 本领域普通技术人员可以理解： 附图只是一个实施例的示意图， 附图中的模块或流 程并不一定是实施本发明所必须的。
本领域普通技术人员可以理解： 实施例中的装置中的模块可以按照实施例描述分布 于实施例的装置中， 也可以进行相应变化位于不同于本实施例的一个或多个装置中。 上 述实施例的模块可以合并为一个模块， 也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述， 不代表实施例的优劣。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤可以通过程 序指令相关的硬件来完成， 前述的程序可以存储于一计算机可读取存储介质中， 该程序 在执行时， 执行包括上述方法实施例的步骤； 而前述的存储介质包括： R0M、 RAM, 磁碟 或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其限制； 尽管 参照前述实施例对本发明进行了详细的说明， 本领域的普通技术人员应当理解： 其依然 可以对前述实施例所记载的技术方案进行修改， 或者对其中部分技术特征进行等同替 换； 而这些修改或者替换， 并不使相应技术方案的本质脱离本发明实施例技术方案的精 神和范围。

Claims

权利要求
1、 一种数据传输的方法， 其特征在于， 包括：
建立第一重传请求进程中需发送的数据的第一标识与第二重传请求进程中所述数 据的第二标识的映射关系，所述第一重传请求进程和所述第二重传请求进程位于对所述 数据进行传输处理的不同层， 且所述第一重传请求进程所在的层高于所述第二重传请求 进程所在的层；
发送所述数据， 所述第二重传请求进程根据所述数据的发送状态以及所述映射关 系， 更新所述第一重传请求进程中所述数据的发送状态信息， 以使所述第一重传请求进 程根据所述数据的发送状态信息， 确定是否重传所述数据。
2、 根据权利要求 1所述数据传输的方法， 其特征在于， 所述第一重传请求进程为 自动重传请求进程， 所述第二重传请求进程为混合自动重传请求进程。
3、 根据权利要求 2所述的数据传输的方法， 其特征在于，
所述数据的发送状态信息包括第一状态或第二状态或第三状态，所述第一状态表示 所述混合自动重传请求进程正在处理所述数据，所述第二状态表示所述混合自动重传请 求进程成功重传所述数据，所述第三状态表示所述混合自动重传请求进程达到最大重传 次数且放弃所述数据的重传， 或者发生异常且放弃重传所述数据。
4、 根据权利要求 3所述的数据传输的方法， 其特征在于， 所述混合自动重传请求 进程更新所述自动重传请求进程中所述数据的发送状态信息包括：
所述混合自动重传请求进程更新所述映射关系， 则更新所述自动重传请求进程中所 述数据的发送状态信息为第一状态； 或者
所述混合自动重传请求进程成功重传所述数据， 则更新所述自动重传请求进程中所 述数据的发送状态信息为第二状态； 或者
所述混合自动重传请求进程重传所述数据达到最大次数且放弃所述数据的重传， 则 更新所述自动重传请求进程中所述数据的发送状态信息为第三状态； 或者
所述混合自动重传请求进程发送所述数据发生异常且放弃所述数据的重传， 则更新 所述自动重传请求进程中所述数据的发送状态信息为第三状态。
5、 根据权利要求 3或 4所述的数据传输的方法， 其特征在于， 所述自动重传请求 进程根据所述数据的发送状态信息， 确定是否重传所述数据， 包括：
如果所述自动重传请求进程中发送所述数据的状态信息为所述第三状态，所述自动 重传请求进程确定所述自动重传请求进程重传所述数据； 如果所述自动重传请求进程中发送所述数据的状态信息为所述第一状态或第二状 态， 所述自动重传请求进程确定所述自动重传请求进程不重传所述数据。
6、 根据权利要求 1-4任一所述的数据传输的方法， 其特征在于， 所述第二重传请 求进程根据所述数据的发送状态以及所述映射关系， 更新所述第一重传请求进程中所述 数据的发送状态信息， 包括：
所述第二重传请求进程获取第一标识所表示的数据的发送状态信息， 并将所述发送 状态信息， 写入与所述数据的第二标识对应的状态描述位。
7、 根据权利要求 2所述的数据传输的方法， 其特征在于，
所述混合自动重传请求进程根据所述数据的发送状态以及所述映射关系， 更新所述 自动重传请求进程中所述数据的发送状态信息， 包括： 所述混合自动重传请求进程向所 述自动重传请求发送所述反馈消息，所述反馈消息用于表示所述混合自动重传请求进程 中所述数据的发送状态为成功或者失败。
8、 根据权利要求 2所述的数据传输的方法， 其特征在于，
所述自动重传请求进程根据所述数据的发送状态信息，确定所述自动重传请求进程 是否重传所述数据， 包括： 在所述反馈消息表示所述混合自动重传请求进程发送所述数 据的发送状态为失败时， 所述自动重传请求进程重传所述数据。
9、 一种网络侧设备， 其特征在于， 包括：
映射模块，用于建立第一重传请求进程中需发送的数据的第一标识与第二重传请求 进程中所述数据的第二标识的映射关系，所述第一重传请求进程和所述第二重传请求进 程位于对所述数据进行传输处理的不同层，且所述第一重传请求进程所在的层高于所述 第二重传请求进程所在的层；
发送状态更新模块， 用于发送所述数据， 所述第二重传请求进程根据所述数据的发 送状态以及所述映射关系， 更新所述第一重传请求进程中所述数据的发送状态信息， 以 使所述第一重传请求进程根据所述数据的发送状态信息， 确定是否重传所述数据。
10、 根据权利要求 9所述的网络侧设备， 其特征在于， 所述数据的发送状态信息包 括第一状态或第二状态或第三状态，所述第一状态表示所述混合自动重传请求进程正在 处理所述数据， 所述第二状态表示所述混合自动重传请求进程成功重传所述数据， 所述 第三状态表示所述混合自动重传请求进程达到最大重传次数且放弃所述数据的重传， 或 者发生异常且放弃重传所述数据；
所述发送状态更新模块包括以下至少一个单元： 第一更新单元， 用于在所述第二重传请求进程更新所述映射关系时， 更新所述第二 重传请求进程中所述数据的发送状态信息为第一状态；
第二更新单元， 用于在所述第二重传请求进程成功重传所述数据时， 更新所述第一 重传请求进程中所述数据的发送状态信息为第二状态；
第三更新单元，用于在所述第二重传请求进程重传所述数据达到最大次数而放弃所 述数据的重传时， 更新所述第一重传请求进程中所述数据的发送状态信息为第三状态； 第四更新单元，用于在所述第二重传请求进程发送所述数据发生异常且放弃所述数 据的重传时， 更新所述第一重传请求进程中所述数据的发送状态信息为第三状态。
PCT/CN2010/080366 2009-12-28 2010-12-28 数据传输的方法和网络侧设备 WO2011079777A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10840566A EP2521299A4 (en) 2009-12-28 2010-12-28 DATA TRANSMISSION METHOD AND NETWORK-SIDED DEVICE
US13/535,503 US20120266038A1 (en) 2009-12-28 2012-06-28 Data transmission method and network side device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910244073.4 2009-12-28
CN2009102440734A CN102111250A (zh) 2009-12-28 2009-12-28 数据传输的方法和网络侧设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/535,503 Continuation US20120266038A1 (en) 2009-12-28 2012-06-28 Data transmission method and network side device

Publications (1)

Publication Number Publication Date
WO2011079777A1 true WO2011079777A1 (zh) 2011-07-07

Family

ID=44175286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/080366 WO2011079777A1 (zh) 2009-12-28 2010-12-28 数据传输的方法和网络侧设备

Country Status (4)

Country Link
US (1) US20120266038A1 (zh)
EP (1) EP2521299A4 (zh)
CN (1) CN102111250A (zh)
WO (1) WO2011079777A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140128728A (ko) * 2013-04-29 2014-11-06 삼성전자주식회사 디바이스 대 디바이스 통신 시스템에서 재전송을 수행하는 방법 및 장치
CN103582048B (zh) * 2013-11-25 2016-06-01 重庆邮电大学 小蜂窝网络中p2p切换指令的保护性传输方法
US9661636B1 (en) * 2014-02-26 2017-05-23 Sprint Communications Company L.P. Actively dropping data packets during voLTE communication sessions
WO2016192761A1 (en) * 2015-05-29 2016-12-08 Telefonaktiebolaget Lm Ericsson (Publ) Transmission control of a multi-hop relay radio link
KR20180110071A (ko) * 2016-02-09 2018-10-08 텔레폰악티에볼라겟엘엠에릭슨(펍) 효율적인 harq 피드백
CN106713314A (zh) * 2016-12-22 2017-05-24 惠州Tcl移动通信有限公司 一种面向5g的协议栈多维度切分方法及其装置
WO2020133129A1 (zh) * 2018-12-28 2020-07-02 华为技术有限公司 一种信息传输的方法及装置
CN110138653A (zh) * 2019-05-30 2019-08-16 北京字节跳动网络技术有限公司 消息通知方法及装置
WO2021007830A1 (en) * 2019-07-18 2021-01-21 Qualcomm Incorporated Hybrid automatic repeat request design with unequal error protection

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101009538A (zh) * 2006-01-26 2007-08-01 华为技术有限公司 一种数据重传方法及装置
CN101127586A (zh) * 2007-09-25 2008-02-20 中兴通讯股份有限公司 一种自动重传请求状态报告触发方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1958367A4 (en) * 2005-11-30 2012-06-13 Nokia Corp APPARATUS, METHOD AND COMPUTER PROGRAM PRODUCT PROVIDING RETRANSMISSION USING MULTIPLE ARQ MECHANISMS
KR101313291B1 (ko) * 2006-03-22 2013-09-30 삼성전자주식회사 이동 통신 시스템에서의 재전송 방법
KR101224334B1 (ko) * 2006-05-08 2013-01-18 삼성전자주식회사 고속 데이터 처리를 위한 재전송 장치 및 방법
KR20070109313A (ko) * 2006-05-10 2007-11-15 삼성전자주식회사 고속 데이터 처리를 위한 효율적인 재전송 요청 장치 및방법
US8018916B2 (en) * 2006-10-25 2011-09-13 Intel Corporation Techniques to couple HARQ-ARQ in wireless networks
WO2008085908A1 (en) * 2007-01-05 2008-07-17 Interdigital Technology Corporation Method and apparatus for indicating a transmission status to a higher layer
US20090046641A1 (en) * 2007-08-13 2009-02-19 Interdigital Patent Holdings, Inc. Long term evolution medium access control procedures
KR20090116601A (ko) * 2008-05-06 2009-11-11 한국전자통신연구원 광대역 무선 접속 시스템에서의 효율적인 Ｈｙｂｒｉｄ ＡＲＱ 및 ＡＲＱ 동작 방안
US8306061B2 (en) * 2008-06-25 2012-11-06 Lg Electronics Inc. Method for retransmitting data unit using delivery status information
CN102113368B (zh) * 2008-08-08 2014-07-30 富士通株式会社 通信装置以及发送数据生成方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101009538A (zh) * 2006-01-26 2007-08-01 华为技术有限公司 一种数据重传方法及装置
CN101127586A (zh) * 2007-09-25 2008-02-20 中兴通讯股份有限公司 一种自动重传请求状态报告触发方法

Also Published As

Publication number Publication date
CN102111250A (zh) 2011-06-29
EP2521299A1 (en) 2012-11-07
EP2521299A4 (en) 2012-11-07
US20120266038A1 (en) 2012-10-18

Similar Documents

Publication Publication Date Title
US10623146B2 (en) Method and arrangements in a telecommunication system for handling status information of data units
WO2011079777A1 (zh) 数据传输的方法和网络侧设备
US8392616B2 (en) Method and apparatus for transmitting header-compressed packet based on retransmission mechanism
US20090319850A1 (en) Local drop control for a transmit buffer in a repeat transmission protocol device
US7904777B2 (en) Method and system for generating block acknowledgements in wireless communications
EP2238707B1 (en) Method of detecting and handling an endless rlc retransmission
JP5215413B2 (ja) 再送プロトコルのためのステータス報告
CN101030842B (zh) 移动通信系统中数据的重排方法及其装置
WO2015192322A1 (zh) 无线资源调度方法及装置
WO2007098676A1 (fr) Procédé de réassemblage de données dans un système de communication sans fil et appareil associé
WO2010121410A1 (zh) 一种采用arq机制的头压缩通信方法和装置
US20070253393A1 (en) Method of handling packet data in a wireless communications system and related apparatus
JP2013507826A (ja) ネットワークにおける信頼性の高いリアルタイム・データストリーミングのための効率的なアプリケーションレイヤの自動再送要求の再送信方法
KR20090075628A (ko) 재전송 데이터를 처리하는 ｈａｒｑ 동작 방법
WO2013139249A1 (zh) 数据包发送方法、模式转换方法及装置
JP2007181127A (ja) 通信装置、通信方法及びプログラム
WO2007033613A1 (fr) Procede destine a realiser un controle d'erreur et systeme et appareil associes
WO2010121409A1 (zh) 一种压缩数据包的传输方法及装置
WO2021208694A1 (zh) 一种数据传输方法及网络设备
JPWO2009044466A1 (ja) 無線通信装置、無線通信制御装置、無線通信方法、無線通信プログラム、無線通信制御方法、および無線通信制御プログラム
WO2011116577A1 (zh) 数据重传方法及装置
JP2012195836A (ja) データ通信システムにおける通信装置および通信制御方法
WO2021013026A1 (zh) 数据单元的发送方法、接收方法及装置
US12126451B2 (en) Method of enabling HARQ, network entity and computer program
WO2019127533A1 (zh) 确定反馈的方法、发送端、接收端及系统

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: 10840566

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010840566

Country of ref document: EP