WO2012155441A1 - 一种处理重传数据的方法及基站 - Google Patents

一种处理重传数据的方法及基站 Download PDF

Info

Publication number
WO2012155441A1
WO2012155441A1 PCT/CN2011/080689 CN2011080689W WO2012155441A1 WO 2012155441 A1 WO2012155441 A1 WO 2012155441A1 CN 2011080689 W CN2011080689 W CN 2011080689W WO 2012155441 A1 WO2012155441 A1 WO 2012155441A1
Authority
WO
WIPO (PCT)
Prior art keywords
retransmission
hardware
queue
data
base station
Prior art date
Application number
PCT/CN2011/080689
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 中兴通讯股份有限公司
Publication of WO2012155441A1 publication Critical patent/WO2012155441A1/zh

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/1874—Buffer management

Definitions

  • the present invention relates to the field of communications, and in particular, to a method and a base station for processing retransmitted data.
  • the RLC (Radio Link Control) protocol layer is a sublayer of L2 (Layer 2, Layer 2) in the radio interface protocol stack of the LTE (Long Term Evolution) system. It is located in the MAC (Media Access). Above the Control, Media Access Control layer, the RLC protocol layer provides segmentation and retransmission services for user and control data.
  • the functions of the RLC protocol layer include: link control, encapsulation and reassembly, cascading, user data transmission, error correction, protocol error detection and repair.
  • Each RLC protocol entity is configured by RRC (Radio Resource Control) and operates in three modes: TM (Transparent Mode), UM (Unacknowledged Mode), and AM. (Acknowledged Mode, Confirmation Mode).
  • the transmitting side adds the necessary control protocol overhead to the higher layer data and transmits it, and guarantees delivery to the peer entity.
  • the RLC layer protocol instance in the acknowledgment mode (AM), when processing the local PDU (Protocol Data Unit), performs the next processing on the local PDU according to the status report sent by the peer layer. If the received status report indicates that some or all of the previously sent PDUs are not successfully sent, the RLC layer protocol instance in the acknowledgment mode (AM) splits the local PDU according to the indication in the status report. Retransmission.
  • the protocol defines maxRetxThreshold (the maximum number of retransmissions), which is used to constrain the maximum number of retransmissions of this service.
  • the current implementation software performs PDU cutting and completes the packet according to the scheduling resource of each TTI (Transmission Time Interval), and needs to complete the moving of the data in the memory by the CPU instruction.
  • TTI Transmission Time Interval
  • the operation of this instruction to complete the memory transfer itself is very inefficient, and it is an indisputable fact. It is also a system designer who needs to avoid a line when designing the system. For. Especially when the retransmission operation is frequently operated, it will cause a heavy load on the CPU and the memory bus to complete these tasks.
  • Such a processing mode has a problem that the retransmission processing efficiency is not high, and the base station processor resources are constantly being used by a small number of services. Occupied, causing other users' business processing to be affected, and even causing the base station to crash.
  • the present invention provides a method for processing retransmission data, the method comprising:: in a process of initializing, a base station sets a hardware retransmission ⁇
  • the management mechanism reassembles and transmits the retransmitted data specified by the first hardware retransmission queue.
  • the step of reassembling and transmitting the retransmission data specified by the first hardware retransmission queue by using the hardware queue management mechanism includes: the base station scheduling the transmission block, according to the size of the transmission block Deriving a descriptor corresponding to the retransmitted data in a hardware retransmission queue is hooked into the second hardware retransmission queue, and then retransmitting the retransmission data indicated by the second hardware retransmission queue into the transport block, and sending the padding The data block of the retransmitted data indicated by the second hardware retransmission queue.
  • the step of the base station reassembling and transmitting the retransmission data specified by the first hardware retransmission queue by using the hardware queue management mechanism further includes: if the base station determines the If the transport block is smaller than the threshold, the descriptor of the corresponding retransmission node is obtained from the first hardware retransmission queue according to the size of the minimum hardware retransmission queue, and is connected to the minimum hardware retransmission queue, and then the minimum hardware retransmission is sent. The retransmitted data indicated by the queue.
  • the step of the base station filling the retransmission data indicated by the second hardware retransmission queue into the transport block includes: determining, by the base station, whether the length of the retransmission node in the second hardware retransmission queue is Less than the remaining length of the transport block, if yes, directly retransmit the retransmission data of the retransmission node to the transport block; if not, intercept the retransmitted data from the retransmission node to fill the transport block.
  • the base station stores, in the step of the first hardware retransmission queue, the descriptor of the status report indicating the data to be retransmitted, the method further includes: saving the queue identifier of the first hardware retransmission queue and the retransmission Corresponding relationship of descriptors of data, storing a descriptor of the descriptor of the retransmitted data in a first hardware retransmission queue, and storing a header address of the retransmitted data stored in the memory and a descriptor of the retransmitted data Corresponding relationship, storing a link relationship of the address of the retransmitted data stored in the slice in the memory, and storing a correspondence between the slice descriptor of the retransmitted data and the slice storage address.
  • the present invention further provides a base station, comprising: a setting module, configured to: set a hardware retransmission queue of different storage capacity according to a service type in an initialization process; an application module, which is set to After receiving the status report for constructing the retransmission packet, requesting the first hardware retransmission queue according to the indication of the status report;
  • a storage module configured to: store, by the status report, a descriptor indicating data that needs to be retransmitted in a first hardware retransmission queue; and a transmission module, configured to: retransmit the queue to the first hardware by using a hardware queue management mechanism The specified retransmitted data is reassembled and transmitted.
  • the transmission module includes: a scheduling unit, configured to: schedule a transport block; and connect the unit, configured to: obtain a corresponding retransmission from the first hardware retransmission queue according to the size of the transport block a descriptor of the data is hooked into the second hardware retransmission queue; and a transmission unit is configured to: fill the retransmission data indicated by the second hardware retransmission queue into the And transmitting, in the transport block, the data block filled with the retransmitted data indicated by the second hardware retransmission queue.
  • the transmitting unit includes: a determining subunit, configured to: sequentially determine whether a length of the retransmission node in the second hardware retransmission queue is smaller than a remaining length of the transport block; The setting is: filling the retransmission data in the retransmission node directly into the transport block if the judgment subunit determines yes;
  • the transmission module further includes: a determining unit, configured to: determine whether the transport block is smaller than a threshold; the hooking unit is further configured to: determine, at the determining unit, the transport block If the value is less than the threshold, the descriptor for obtaining the corresponding retransmission node from the first hardware retransmission queue according to the size of the minimum hardware retransmission queue is hooked into the minimum hardware retransmission queue; the transmission unit is further configured to: Transmitting the retransmission data indicated by the minimum hardware retransmission queue.
  • the storage module is further configured to: save a correspondence between a queue identifier of the first hardware retransmission queue and a descriptor of the retransmitted data, and save the descriptor of the retransmitted data in the first hardware Retransmitting a link relationship in the queue, storing a correspondence between a header address stored in the memory and a descriptor of the retransmitted data, and storing a link relationship of the address of the retransmitted data stored in the memory And storing a correspondence between the slice descriptor of the retransmitted data and the slice storage address.
  • the base station is a micro base station or a femto base station.
  • the method and the base station for processing retransmission data provided by the present invention can significantly reduce the situation that processor resources are continuously occupied by a small number of services, can improve the processing capability of a single chip, and reduce product cost, and the application of the present invention. Can reduce chip size while improving processing power.
  • the invention can also flexibly set different types of hardware retransmission queues, and can effectively utilize hardware resources. Source.
  • FIG. 1 is a schematic diagram of a base station according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a hardware queue manager for managing retransmission data according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of processing retransmission according to an embodiment of the present invention
  • FIG. 4 is a flowchart of a base station retransmitting a message according to an embodiment of the present invention
  • FIG. 5 is a flowchart of constructing a retransmission data by using an RLC protocol layer according to an embodiment of the present invention.
  • the embodiment of the present invention utilizes a hardware queue manager to reduce the implementation complexity of the process in the process. Considering that the implementation of the hardware queue manager needs to be done inside the processor and the hardware resource usage is very large when supporting a very large number of services, the present invention is mainly applied to the PICO (micro) base station and the FEMTO (nano ) in the base station.
  • the base station provided by the embodiment of the present invention includes: a setting module, which is configured to: set a hardware retransmission queue of different storage capacity according to a service type during initialization;
  • the application module is configured to: after receiving the status report for constructing the retransmission message, apply for the first hardware retransmission queue according to the indication of the status report;
  • a storage module configured to: store, by the status report, a descriptor indicating data that needs to be retransmitted in a first hardware retransmission queue;
  • a transmission module configured to: specify a first hardware retransmission queue by using a hardware queue management mechanism The retransmitted data is reassembled and transmitted.
  • the base station may set various types according to the service type according to the actual application.
  • TTYPE hardware retransmission queue.
  • the hardware retransmission queue of each TYPE corresponds to a unit storage unit of different storage capacity. For example, if the base station pushes online movies and takes care of the download function, the main packet size of these services is 1400 bytes. Then, a hardware retransmission queue with a unit storage capacity of 1400 bytes can be set in the initialization process of the base station; if the daily application of the user is a very small service such as mail download and fax, the unit storage can be set in the initialization process of the base station.
  • the transmission module includes: a scheduling unit, configured to: schedule a transport block; and a hook unit, configured to: obtain a corresponding weight from the first hardware retransmission queue according to the size of the transport block The descriptor of the transmitted data is hooked into the second hardware retransmission queue; and the transmission unit is configured to: fill the retransmission data indicated by the second hardware retransmission queue into the transport block, and send the second pad The retransmission data indicated by the hardware retransmission queue is transmitted fast.
  • the transmitting unit may include: a determining subunit, configured to: sequentially determine whether a length of the retransmission node in the second hardware retransmission queue is smaller than a remaining length of the transport block; and the first filling unit is configured to : in the case that the judgment subunit determines yes, the retransmission data in the retransmission node is directly filled into the transport block; and the second padding unit is set to: in a case where the judgment subunit determines NO, The retransmission data is intercepted from the retransmission node to fill the transport block.
  • the transmission module may further include: a determining unit, configured to: determine whether the transport block is smaller than a threshold; the attaching unit is further configured to: determine, by the determining unit, that If the transport block is smaller than the threshold, the descriptor of the corresponding retransmission node is obtained from the first hardware retransmission queue according to the size of the minimum hardware retransmission queue and is connected to the minimum hardware retransmission queue; The transmitting unit is further configured to: send retransmission data indicated by the minimum hardware retransmission queue. In this way, the base station can ensure the continuous operation of the service in the case of poor channel quality, and at the same time, improve the user's feeling.
  • a determining unit configured to: determine whether the transport block is smaller than a threshold
  • the attaching unit is further configured to: determine, by the determining unit, that If the transport block is smaller than the threshold, the descriptor of the corresponding retransmission node is obtained from the first hardware retransmission queue according to the size of the minimum hardware
  • the storing, by the storage module, the descriptor of the retransmitted data is further set to: save a correspondence between a queue identifier of the first hardware retransmission queue and a descriptor of the retransmitted data, and save the weight Transmitting a data descriptor in a first hardware retransmission queue, storing a correspondence between a header address stored in the memory and a descriptor of the retransmitted data, and saving the retransmitted data in a memory
  • 2 is a schematic diagram of the hardware queue manager managing retransmission packets provided in this embodiment. As shown in FIG.
  • P1 to P4 form a retransmission queue
  • PI, P2, P3, and P4 are respectively a PDU ( Protocol Data Unit, protocol data unit)
  • P1 and P3 are a queue
  • P2 and P4 are a queue.
  • the right part of Figure 2 (a) shows how the retransmission data is stored in the memory.
  • Each PDU is sliced according to the size of the unit storage unit. For example, P1 is divided into P1—cells—1, PI. — Cell— 2, and PI—Cell-3, and then stored in different storage units, such that PI—Cell-1, PI—Cell-2, and PI—Cell-3 are respectively in the address of each storage unit. -1, Add-2, and Add-3.
  • the list stored in the five RAMs includes:
  • the identification table, as shown in Figure 2 (b), represents a queue, corresponding to a queue number, and puts the group identifiers of the same queue in the same row.
  • P1 and P3 Divided into one team, then one queue number corresponds to the group descriptor of the same queue, that is, Q-1 corresponds to the identifiers P-1 and P-3 of P1 and P3, and the queue list is used to describe the group represented by each group descriptor.
  • the link relationship between, for example, P-1 is followed by P-3, and P-2 is followed by P-4.
  • a packet identification table for describing a correspondence between a packet descriptor and a header address of each packet, for example, P1 corresponds to Add-1, P-2 corresponds to Add-6, P-3 corresponds to Add-11, etc.;
  • a packet linked list is used to describe the link relationship between each fragment address, for example, Add-1 link Add- 2, Add-2 link Add-3.
  • a data table is used to describe the correspondence between each fragment address and each sub-component slice descriptor.
  • the queue Q-1 is taken as an example for description: First, the idle header address Add-1 is obtained, and the fragment PI_Cell-1 is written in the data table by using Add-1, and the sub-component descriptors are sequentially written into the data table.
  • the process of dequeue includes the following steps: 1. According to the scheduling queue number, read the "queue identification table" to obtain the queue head address identifier (ie, the packet descriptor);
  • FIG. 3 is a flowchart of a method for processing retransmission data according to an embodiment of the present invention. As shown in FIG. 3, the method includes the following steps:
  • the base station sets a hardware retransmission queue with different storage capacity according to the service type
  • the base station After receiving the status report for constructing the retransmission packet, the base station applies for the first hardware retransmission queue according to the indication of the status report, and stores the descriptor indicating that the status report needs to be retransmitted data in the first hardware retransmission queue. And reassembling and transmitting the retransmitted data specified by the first hardware retransmission queue by using a hardware queue management mechanism.
  • the base station reassembles and transmits the retransmission data, where the base station schedules the transport block, and obtains a descriptor corresponding to the retransmitted data from the first hardware retransmission queue according to the size of the transport block.
  • the base station transmitting, in the second hardware retransmission queue, the retransmission data indicated by the second hardware retransmission queue to the transport block to send the transport block filled with the retransmission data indicated by the second hardware retransmission queue.
  • the base station determines that the transport block is smaller than a threshold, the descriptor of the corresponding retransmission node is obtained from the first hardware retransmission queue according to the size of the minimum hardware retransmission queue.
  • the retransmission data indicated by the minimum hardware retransmission queue is then sent. In this way, the base station can ensure the continuous operation of the service in the case of poor channel quality, and at the same time, improve the user's feeling.
  • An example of the present invention is based on the existing software implementation technology.
  • the base station When receiving a status report to construct a retransmission message, the base station first determines the size of the retransmission data included in the NACK information received, and retransmits the data according to the retransmission data.
  • the size applies for the corresponding retransmission queue node, and according to the size of the retransmitted data, the application reattaches the retransmission queue to a different hardware queue.
  • the invention can obviously reduce the situation that the processor resources are continuously occupied by a small number of services, can improve the processing capability of the single chip, and reduce the product cost, and the application of the invention can reduce the chip size while improving the processing capability.
  • the present invention can set different types of hardware retransmission queues according to actual business conditions in advance, and can utilize hardware resources more effectively.
  • the RLC sender entity under the AM allows retransmission, it is unrealistic to retransmit without restriction in consideration of the actual application scenario.
  • the size of the TB Transport Block
  • the RLC layer reassembles the 819 PDU according to the TB size and sends the reassembled PDU to the peer.
  • the PDU is recorded as PDU-1.
  • the channel quality deteriorates (that is, the scheduled TB is less than the preset threshold), and the sender selects the appropriate weight according to the current scheduling result.
  • the transfer queue completes the data block hardware queue hook and transmits. If the channel quality is further reduced during the transmission process, the TB size of the scheduling result given by the MAC layer will be scheduled according to the size of the minimum storage unit (for example, 128 kByte), that is, only one type of retransmission queue is selected.
  • the retransmission packet is split into 128-byte queues to complete the retransmission. If the number of retransmissions is set to 8 times, when the retransmission is not completed, the re-establishment service flow is triggered.
  • the hardware retransmission queue is designed to save and manage the retransmission packets. Different queue groups correspond to different sizes of hardware retransmission queues. The size of the packets can be as much as possible according to the actual situation.
  • the present invention will be further described in detail below as an application example with the retransmission data structure of the radio link control layer in the LTE system.
  • the hardware queue resources are estimated.
  • the reserved retransmission information will occupy a certain amount of on-chip RAM resources, and an average of 1.5 DRBs (dedicated service bearers) can be allocated for each user, and AM is used, and the transmission window is 512 bytes (bytes).
  • the 64-bit register can be used to complete the description of the retransmission queue. Assumption:
  • the RLC transmitting side sends three PDUs of size 8192, which are recorded as PDU_1, PDU_2 and PDU3. Because of the link, the PDU-1 is lost during transmission, and the receiving side of the RLC does not receive the PDU-1.
  • the base station configures a hardware retransmission queue of different storage capacity according to the service type, for example, a hardware retransmission queue with a unit storage capacity of 1400 bytes, 512 bytes, or 64 bytes. As shown in FIG.
  • Step 101 The base station receives the status report Status-1 sent by the peer end, parses the status report Status-1, and obtains NACK information, where the NACK information indicates the PDU— 1 Overall not received.
  • the RLC protocol layer acquires the resources of the hardware retransmission queue according to the size of the retransmission data indicated by the status report, and requests to attach the retransmission queue to different types of hardware retransmission queues.
  • Step 102 Because the NACK information is not received last time, the base station saves the NACK information of the PDU-1, and uses the PDU-1 as a retransmission PDU according to the indication of the NACK information, and applies for corresponding hardware retransmission according to the size of the PDU-1.
  • the queue node stores the PDU-1, and hangs the queue descriptor corresponding to the PDU-1 into the retransmission queue TYPE1 (type 1) (the process of re-transmitting the packet is as described above), and the PDU_1 The number of retransmissions (PdulRetransCount) is incremented by one;
  • Step 103 The RLC layer of the base station receives the scheduling result of the MAC layer. For example, the size of the TB is 4000 BYTE, and the base station intercepts the retransmission packet of 1-4000 BYTE in the PDU-1. The hook is connected to the TYPE2 retransmission queue, and then the software participates in the scheduling and joins the TB block and sends it out.
  • Step 104 The base station receives the status report Status_2 sent by the peer end, parses the status report Status-2, and obtains NACK information, indicating that 4001-8192 bytes are not received.
  • Step 105 The base station compares the current NACK information with the previous NACK information, and finds that the length of the retransmission part indicated by the current NACK information is smaller than the length of the retransmission part indicated by the previous NACK information, and indicates according to the current NACK information.
  • the data part of the 4001-8192 constructs a retransmission PDU; Step 106, the base station receives the scheduling result of the MAC, for example, the size of the TB is 5000, which will be heavy.
  • the byte of 4001-8192 of the transmitted data is added to the TB block and sent out; however, because the link is lost, the TB block is lost during transmission, and the RLC receiving side does not receive, then in step 107, the base station receives the peer to send.
  • the status report Status — 3 parsing status report Status — 3 , obtaining NACK information, indicating that 4001-8192 bytes have not been received.
  • Step 108 The base station compares the current NACK information with the previous NACK information, and if it finds that the length of the retransmission part indicated by the current NACK information is equal to the length of the retransmission part indicated by the last NACK information, the number of retransmissions is first (PdulRetransCount The operation of adding 1 is performed, and it is judged that PdulRetransCount is 2, less than 3, and no reconstruction is initiated, and the retransmitted PDU is constructed according to the 4001-8192 data part indicated by the current NACK information.
  • Step 109 The base station receives the scheduling result of the MAC. For example, the size of the TB is 5000.
  • the RLC adds the bytes of the retransmitted data 4001-8192 to the TB block and sends it out;
  • Step 110 the base station receives the status report Status-4 sent by the peer end, parses the status report Status-4, and finds that the PDU-1 has been completely received. To, delete the NACK information corresponding to the saved PDU-1.
  • the base station determines that the channel quality is lower than the predetermined bandwidth, the smallest transport block will retransmit the data that needs to be retransmitted multiple times to ensure that the service can continue.
  • Figure 5 is a flowchart of constructing retransmission data by the RLC protocol layer.
  • Step 201 The RLC protocol layer obtains the scheduling result of the MAC layer, that is, the length of the TB that can be sent this time;
  • Step 202 The RLC protocol layer obtains the hardware resource of the retransmission queue according to the status report, and obtains a retransmission node from the retransmission queue.
  • Step 203 The RLC protocol layer determines whether the scheduled TB is less than a threshold. If yes, go to step 204, if no, turn Step 205: Step 204: The RLC protocol layer attaches the descriptor of the retransmission node to the minimum hardware retransmission queue, and then sends the retransmission data indicated by the minimum hardware retransmission queue.
  • Step 205 The RLC protocol layer determines the remaining Whether the TB length is greater than the obtained retransmission node If yes, go to step 206, if no, go to step 207; Step 206, the RLC protocol layer directly fills the data of the retransmission node into the TB block, and then returns to step 202; Step 207, RLC protocol layer splitting Retransmit the node, fill the remaining TB blocks, and then send the TB block.
  • the present invention can significantly reduce the situation that processor resources are constantly occupied by a small number of services, can improve the processing capability of a single chip, and reduce the product cost, and the application of the present invention can reduce the chip size while improving the processing capability.
  • the invention can also flexibly set different types of hardware retransmission queues, and can effectively utilize hardware resources.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明公开了一种处理重传数据的方法，该方法包括：基站在初始化的过程中，根据业务类型设置不同存储容量的硬件重传队列；以及基站接收到构造重传报文的状态报告后，根据该状态报告的指示申请第一硬件重传队列，将所述状态报告指示需要重传的数据的描述符存储在第一硬件重传队列，利用硬件队列管理机制对第一硬件重传队列指定的重传数据进行重组和传输。本发明还公开了一种基站。本发明可以明显地减少处理器资源不断被少数业务占用的情况。

Description

一种处理重传数据的方法及基站
技术领域 本发明涉及一种通信领域， 特别涉及一种处理重传数据的方法及基站。
背景技术
RLC ( Radio Link Control, 无线链路控制）协议层在 LTE ( Long Term Evolution, 长期演进） 系统的无线接口协议栈中， 是 L2 ( Layer 2, 层 2 ) 的 一个子层， 位于 MAC ( Media Access Control, 媒体接入控制）层之上， RLC 协议层为用户和控制数据提供分段和重传业务。 RLC协议层的功能包括： 链 接控制、 封装和重组、 级联、 用户数据传输、 纠错、 协议错误检测和修复等。 每个 RLC协议实体由 RRC ( Radio Resource Control, 无线资源控制） 配置， 并以三种模式进行操作， 分别为： TM ( Transparent Mode, 透明模式）、 UM ( Unacknowledged Mode, 非确认模式） 、 以及 AM ( Acknowledged Mode , 确认模式） 。 在确认模式中， 发送侧在高层数据上添加必要的控制协议开销后进行传 送， 并保证传递到对等实体。 确认模式（AM ) 下的 RLC层协议实例在处理 本端 PDU ( Protocol Data Unit, 协议数据单元 ) 时， 根据对等层发送的状态 报告作出对于本端 PDU进行下一步的处理。如果收到的状态报告中指示前一 次发送的 PDU中一部分或者全部未发送成功， 那么， 确认模式（AM )下的 RLC层协议实例会根据状态报告中的指示对本端 PDU进行拆分， 并进行重 传。 在确认模式重传过程中， 为了对不同的业务进行可靠性区分， 协议定义 了 maxRetxThreshold (最大重传次数 ) ,用来约束这个业务最多可重传次数。 当前实现釆用软件根据每个 TTI ( Transmission Time Interval, 传输时间 间隔） 的调度资源进行 PDU切割并完成组包， 需要通过 CPU指令完成内存 中数据的搬移工作。 然而这种指令完成内存搬移的操作本身效率就非常差， 是不争的事实， 也是作为系统设计人员在设计系统时需要尽量避免得一种行 为。尤其是当重传操作频繁操作时，会对 CPU以及内存总线造成很重的负荷 去完成这些工作， 这样的处理模式存在重传处理效率不高的问题， 并且导致 基站处理器资源不断被少数业务占用，从而导致其他用户业务处理遭到影响， 甚至导致基站瘫痪。
发明内容 本发明的目的是提供一种处理重传数据的方法及基站， 以解决如何减小 占用处理器资源， 并提高重传处理效率的问题。 为了解决上述技术问题， 本发明提供了一种处理重传数据的方法， 该方 法包括： 基站在初始化的过程中， 根据业务类型设置不同存储容量的硬件重传队 歹 |J ; 以及 基站接收到构造重传报文的状态报告后， 根据该状态报告的指示申请第 一硬件重传队列 , 将所述状态报告指示需要重传的数据的描述符存储在第一 硬件重传队列， 利用硬件队列管理机制对第一硬件重传队列指定的重传数据 进行重组和传输。 本发明的方法中， 所述基站利用硬件队列管理机制对第一硬件重传队列 指定的重传数据进行重组和传输的步骤包括： 所述基站调度传输块， 根据所述传输块的大小从第一硬件重传队列中获 取对应重传数据的描述符挂接到第二硬件重传队列中， 然后将第二硬件重传 队列指示的重传数据填充到所述传输块中， 发送填充有第二硬件重传队列指 示的重传数据的所述数据块。 本发明的方法中， 所述基站调度传输块之后， 所述基站利用硬件队列管 理机制对第一硬件重传队列指定的重传数据进行重组和传输的步骤还包括： 所述基站若判断所述传输块小于门限值， 则根据最小硬件重传队列的大 小从第一硬件重传队列中获取对应重传节点的描述符挂接到最小硬件重传队 列中， 然后发送所述最小硬件重传队列指示的重传数据。 本发明的方法中， 所述基站将第二硬件重传队列指示的重传数据填充到 所述传输块的步骤包括： 所述基站依次判断第二硬件重传队列中的重传节点的长度是否小于所述 传输块的剩余长度， 若是， 则直接将所述重传节点的重传数据填充到所述传 输块； 若否， 从该重传节点中截取重传数据填充满所述传输块。 所述基站将所述状态报告指示需要重传的数据的描述符存储在第一硬件 重传队列的步骤中， 所述方法还包括： 保存第一硬件重传队列的队列标识与所述重传数据的描述符的对应关 系， 保存所述重传数据的描述符在第一硬件重传队列中链接关系， 保存所述 重传数据在内存中存储的头地址与所述重传数据的描述符的对应关系， 保存 所述重传数据在内存中分片存储的地址的链接关系， 及保存所述重传数据的 分片描述符与分片存储地址的对应关系。 为了解决上述技术问题， 本发明还提供了一种基站， 其包括： 设置模块， 其设置为： 在初始化的过程中， 根据业务类型设置不同存储 容量的硬件重传队列； 申请模块， 其设置为： 接收到构造重传报文的状态报告后， 根据该状态 报告的指示申请第一硬件重传队列；
存储模块， 其设置为： 将所述状态报告指示需要重传的数据的描述符存 储在第一硬件重传队列； 以及 传输模块， 其设置为： 利用硬件队列管理机制对第一硬件重传队列指定 的重传数据进行重组和传输。 本发明的基站中， 所述传输模块包括： 调度单元， 其设置为： 调度传输块； 挂接单元， 其设置为： 根据所述传输块的大小从第一硬件重传队列中获 取对应重传数据的描述符挂接到第二硬件重传队列中； 以及 传输单元， 其设置为： 将第二硬件重传队列指示的重传数据填充到所述 传输块中， 并发送填充有第二硬件重传队列指示的重传数据的所述数据块。 本发明的基站中， 所述传输单元包括： 判断子单元， 其设置为： 依次判断第二硬件重传队列中的重传节点的长 度是否小于所述传输块的剩余长度； 第一填充单元， 其设置为： 在判断子单元判断是的情况下， 直接将所述 重传节点中的重传数据填充到所述传输块； 以及
第二填充单元， 其设置为： 在判断子单元判断否的情况下， 从该重传节 点中截取重传数据填充满所述传输块。 本发明的基站中， 所述传输模块还包括： 判断单元， 其设置为： 判断所述传输块是否小于门限值； 所述挂接单元还设置为： 在所述判断单元判断所述传输块小于门限值的 情况下， 根据最小硬件重传队列的大小从第一硬件重传队列中获取对应重传 节点的描述符挂接到最小硬件重传队列中； 所述传输单元还设置为： 发送所述最小硬件重传队列指示的重传数据。 本发明的基站中， 所述存储模块还设置为： 保存第一硬件重传队列的队 列标识与所述重传数据的描述符的对应关系， 保存所述重传数据的描述符在 第一硬件重传队列中链接关系， 保存所述重传数据在内存中存储的头地址与 所述重传数据的描述符的对应关系， 保存所述重传数据在内存中分片存储的 地址的链接关系， 及保存所述重传数据的分片描述符与分片存储地址的对应 关系。 本发明的基站中， 所述基站为微型基站或毫微型基站。
综上， 本发明提供的一种处理重传数据的方法及基站， 可以明显地减少 处理器资源不断被少数业务占用的情况， 可以提高单芯片的处理能力， 降低 产品成本， 而且本发明的应用可以减少芯片尺寸同时提高处理能力。 另外通 过本发明还可以灵活设置不同类型的硬件重传队列， 能够有效地利用硬件资 源。
附图概述 图 1为本发明实施例的基站的示意图； 图 2a和图 2b是本实施例提供的硬件队列管理器管理重传数据的示意图； 图 3为本发明实施例的一种处理重传数据的方法的流程图； 图 4为本发明实施例的基站重传报文的流程图； 以及 图 5为本发明实施例 RLC协议层构造重传数据的流程图。
本发明的较佳实施方式 为使本发明的目的、 技术方案和优点更加清楚明白， 下文中将结合附图 对本发明的实施例进行详细说明。 需要说明的是， 在不冲突的情况下， 本申 请中的实施例及实施例中的特征可以相互任意组合。 为了提高 AM模式下的重传处理效率， 本发明实施例利用硬件队列管理 器以减少处理过程中流程的实现复杂度。 考虑到在支持非常多业务数量的情 况下， 硬件队列管理器的实现需要在处理器内部完成， 且硬件资源占用量会 非常大， 所以本发明主要应用于 PICO (微型）基站和 FEMTO (毫微型）基 站中。
如图 1所示， 本发明实施例提供的基站包括： 设置模块， 其设置为： 在初始化的过程中， 根据业务类型设置不同存储 容量的硬件重传队列；
申请模块， 其设置为： 接收到构造重传报文的状态报告后， 根据该状态 报告的指示申请第一硬件重传队列；
存储模块， 其设置为： 将所述状态报告指示需要重传的数据的描述符存 储在第一硬件重传队列； 以及
传输模块， 其设置为： 利用硬件队列管理机制对第一硬件重传队列指定 的重传数据进行重组和传输。 本实施例中基站可以事先根据实际应用， 根据业务类型设置不种各类
( TPYE )的硬件重传队列，每种 TYPE的硬件重传队列对应不同存储容量的 单位存储单元， 例如， 基站主推在线电影， 兼顾下载功能， 则这些业务主要 的报文大小都为 1400字节，那么可以在基站初始化过程中设置单位存储容量 为 1400字节的硬件重传队列；若用户日常应用就是邮件下载和传真等一些报 文非常小的业务， 则可以在基站初始化过程中设置单位存储容量为 512字节 或 64字节等的硬件重传队列。 在一优选实施例中， 所述传输模块包括： 调度单元， 其设置为： 调度传输块； 挂接单元， 其设置为： 根据所述传输块的大小从第一硬件重传队列中获 取对应重传数据的描述符挂接到第二硬件重传队列中； 以及 传输单元， 其设置为： 将第二硬件重传队列指示的重传数据填充到所述 传输块中， 并发送填充有第二硬件重传队列指示的重传数据的传输快。 其中， 所述传输单元可以包括： 判断子单元， 其设置为： 依次判断第二硬件重传队列中的重传节点的长 度是否小于所述传输块的剩余长度； 第一填充单元， 其设置为： 在判断子单元判断是的情况下， 直接将所述 重传节点中的重传数据填充到所述传输块； 以及 第二填充单元， 其设置为： 在判断子单元判断否的情况下， 从该重传节 点中截取重传数据填充满所述传输块。 在一优选实施例中， 所述传输模块还可以包括： 判断单元， 其设置为： 判断所述传输块是否小于门限值； 所述挂接单元还设置为： 在所述判断单元判断所述传输块小于门限值的 情况下， 根据最小硬件重传队列的大小从第一硬件重传队列中获取对应重传 节点的描述符挂接到最小硬件重传队列中； 所述传输单元还设置为： 发送所述最小硬件重传队列指示的重传数据。 这样， 基站在信道质量差的情况下， 也能够保证业务的持续进行， 同时 还能提高用户的感受度。 本实施例中， 所述存储模块存储重传数据的描述符的过程中还设置为： 保存第一硬件重传队列的队列标识与所述重传数据的描述符的对应关系， 保 存所述重传数据的描述符在第一硬件重传队列中链接关系， 保存所述重传数 据在内存中存储的头地址与所述重传数据的描述符的对应关系， 保存所述重 传数据在内存中分片存储的地址的链接关系， 及保存所述重传数据的分片描 述符与分片存储地址的对应关系。 图 2是本实施例提供的硬件队列管理器管理重传报文的示意图， 如图 2 所示， P1至 P4构成一个重传队列， PI、 P2、 P3、 以及 P4分别是一个 PDU ( Protocol Data Unit,协议数据单元 ) ,根据不同用户， P1和 P3为一个队列， P2和 P4为一个队列。 图 2 ( a )的右部分， 表示重传数据在内存中的存储方式， 按照单位存储 单元的大小将各个 PDU进行分片存储， 例如， 将 P1分为 P1—单元（ Cell ) —1、 PI— Cell— 2、 以及 PI— Cell— 3 , 然后分别存储在不同的存储单元中， 这样 PI— Cell— 1、 PI— Cell— 2、 以及 PI— Cell— 3在各存储单元的地址分别为 Add-1、 Add-2、 以及 Add-3。 本实施例中， 需要配置 5个 RAM ( Random Access Memory, 随机存储 器）分别存储 1个列表， 用以保存重传信息， 如图 2 ( b )所示， 5个 RAM 中存储的列表包括： 队列标识表， 如图 2 ( b )所示， 一行表示一个队列， 分别对应一个队列 号， 将同队列的分组标识放在同一行中， 例如， 如图 2 ( a ) 所示， 将 P1和 P3分为一队， 则一个队列号与同一队列的分组描述符对应， 即 Q-1对应 P1 和 P3的标识 P- 1和 P-3 , 队列链表，用于描述各分组描述符所代表的分组之间的链接关系，例如， P-1之后是 P-3 , P-2之后是 P-4。 分组标识表，用于描述分组描述符与各分组的头地址的对应关系，例如， P-l与 Add-1对应， P-2与 Add-6对应、 P-3与 Add- 11对应等; 分组链表， 用于描述各分片地址之间的链接关系， 例如， Add-1 链接 Add-2, Add-2链接 Add-3。 数据表， 用于描述各分片地址与各分组分片描述符的对应关系。 本发明实施例进行緩存及队列管理的实现原理如下： 入队过程包括：
( 1 ) 、 读空闲资源， 得到空闲头地址； 若硬件存储单元中具有空闲资源， 则可以用来存储重传数据。
( 2 )、利用空闲地址写 "数据表"， 同时用该空闲地址更新 "分组链表"； 根据重传报文的大小以及使用的不同类型（TPYE )的硬件队列，根据单 位存储单元的大小将重传数据进行切片保存在数据表中， 产生多个地址。
( 3 ) 、 根据分组数量， 重复（2 ) 多次；
( 4 )、 根据该分组所属的队列号， 读 "队列标识表" ， 依次得到该队列 中的其他的分组描述符；
( 5 )、 利用非队首的分组描述符， 将对应各分组的第一个分片地址更新 到 "分组标识表" 和 "队列链表" ； 以及
( 6 ) 、 更新队列标识表。 这里以队列 Q— 1为例进行说明： 首先，获得空闲头地址 Add-1 ,利用 Add-1在数据表中写分片 PI— Cell— 1 , 依次将分组分片描述符写入数据表中， 在队列标识表中保存所有队列标识与 分组描述符的对应关系， 在队列链表中存储各分组描述符相关的连接关系， 在分组标识表中存储分组描述符与对应的头地址的对应关系； 在分组链表中 进行索引将分组分片地址连接关系建立起来， 数据表中保存的是所有的待处 理数据的地址， 通过这些地址完成真正数据的获取。 出队过程包括下面步骤： 1、 根据调度队列号， 读 "队列标识表" ， 得到队列头地址标识（即分组 描述符 ) ；
2、利用队列头地址标识，读 "分组标识表"，得到对应的存储单元地址；
3、 利用队列头地址标识， 读 "队列链表" ， 更新队列头（写 "队列标识 表，， ） ；
4、 用存储单元地址读 "数据表" ， 读出第一个分片；
5、 用存储单元地址读 "分组链表" ， 进而读出其他分片； 以及
6、 每读出一个分片， 更新空闲链表（写分组链表） 。
图 3为本发明实施例的一种处理重传数据的方法的流程图，如图 3所示， 包括下面步骤：
S10、 基站在初始化的过程中， 根据业务类型设置不同存储容量的硬件 重传队列； 以及
S20、 基站接收到构造重传报文的状态报告后， 根据该状态报告的指示 申请第一硬件重传队列 , 将所述状态报告指示需要重传数据的描述符存储在 第一硬件重传队列； 并利用硬件队列管理机制对第一硬件重传队列指定的重 传数据进行重组和传输。 步骤 S20中， 基站对重传数据进行重组和传输具体实施为： 所述基站调度传输块， 根据所述传输块的大小从第一硬件重传队列中获 取对应重传数据的描述符挂接到第二硬件重传队列中， 然后将第二硬件重传 队列指示的重传数据填充到所述传输块中发送填充有第二硬件重传队列指示 的重传数据的所述传输块。 在另一优选实施例中， 所述基站若判断所述传输块小于门限值， 则根据 最小硬件重传队列的大小从第一硬件重传队列中获取对应重传节点的描述符 挂接到最小硬件重传队列中， 然后发送所述最小硬件重传队列指示的重传数 据。 这样， 基站在信道质量差的情况下， 也能够保证业务的持续进行， 同时 还能提高用户的感受度。 本发明示例是在现有软件实现技术的基础上， 基站在每次收到状态报告 构造重传报文的时候， 首先判断本次收到的 NACK信息包含的重传数据大 小， 根据重传数据大小申请相应的重传队列节点， 并且根据重传数据大小的 不同， 申请将重传队列挂接在不同的硬件队列中。 本发明可以明显地减少处 理器资源不断被少数业务占用的情况， 可以提高单芯片的处理能力， 降低产 品成本， 本发明的应用可以减少芯片尺寸同时提高处理能力。 另外， 本发明 可以事先根据实际业务情况来设置不同类型的硬件重传队列， 可以更有效地 利用硬件资源。 虽然 AM下的 RLC发送端实体允许重传， 但处于对实际应用场景的考 虑， 无限制地重传是不现实的。 假设， RLC层收到 MAC层的调度结果， TB ( Transport Block, 传输块） 的大小为 8192BYTE (字节） ， RLC层按照 TB 的大小重组了 8192大小的 PDU, 并发送重组的 PDU到对端， 记该 PDU为 PDU— 1 , 若该 TB在传输过程中丟失， 此时信道质量变差 （即调度的 TB小 于预设的门限值） ， 发送端会根据当前的调度结果选取合适的重传队列完成 数据块硬件队列挂接，并进行传输。如果在传输过程中信道质量进一步降低， 此后， MAC层每次给的调度结果的 TB大小都会按照最小存储单元（例如， 128kByte ) 的大小来调度， 也就是说重传队列的选择只有一种， 将重传报文 拆分为 128字节的队列完成重传， 若重传次数设置为 8次， 当重传还没有完 成的话， 会触发重建业务流程。 设计硬件重传队列完成重传报文的保存和管理， 不同的队列分组对应不 同大小的硬件重传队列， 分组的大小可以根据实际情况尽可能的多。 下面以 LTE 系统中无线链路控制层的重传数据构造作为应用示例对本 发明作进一步的详细描述。 首先，对硬件队列资源进行估算，保留重传信息会占有一定的片内 RAM 资源， 可以为每用户平均分配 1.5个 DRB (专用业务承载） ， 并釆用 AM, 发送窗口为 512Byte (字节） ， 可以釆用 64 bit寄存器完成重传队列的描述。 假设：
( 1 ) RLC发送侧发送了 3个 8192大小的 PDU, 记为 PDU_1 , PDU_2 和 PDU3 , 因为链路原因， 该 PDU— 1在传输过程中丟失， RLC的接收侧未收 到该 PDU— 1。 ( 2 ) 假设最大重传次数配置为 8。 首先， 基站在初始化的过程中， 根据业务类型配置不同存储容量的硬件 重传队列， 例如， 单位存储容量为 1400字节、 512字节或 64字节的硬件重 传队列。 如图 4所示， 基站重传报文的具体步骤如下： 步骤 101 , 基站收到对端发送的状态报告 Status— 1 , 解析状态报告 Status— 1 , 获取 NACK信息， 所述 NACK信息指示 PDU— 1整体未收到。
RLC协议层根据状态报告指示的重传数据大小， 来获取硬件重传队列的 资源， 申请将重传队列挂接在不同类型的硬件重传队列中。 步骤 102, 因为上次未收到 NACK信息， 基站将 PDU— 1的 NACK信息 保存下来， 按照 NACK信息的指示将 PDU— 1 整体作为重传 PDU, 并根据 PDU— 1大小申请相应的硬件重传队列节点来存储 PDU—1 , 并将该 PDU— 1对 应的队列描述符挂入重传队列 TYPE1 (类型 1 ) 中 （重传报文的入队过程如 上文所述） ， 并将该 PDU_1的重传次数 ( PdulRetransCount )加 1 ; 步骤 103 ,基站的 RLC层收到 MAC层的调度结果， 例如， TB的大小为 4000 BYTE, 基站将在 PDU— 1 中截取 1-4000 BYTE 的重传报文的挂接到 TYPE2重传队列中， 后续由软件参与调度加入到 TB块中发送出去（重传报 文的出队过程如上文所述） ， 具体流程如图 5所示。 步骤 104 , 基站收到对端发送的状态报告 Status— 2 , 解析状态报告 Status— 2, 获取 NACK信息， 指示 4001-8192字节未收到。 步骤 105,基站比较本次的 NACK信息和上次的 NACK信息，发现本次 的 NACK信息指示的重传部分长度小于上次的 NACK信息指示的重传部分 长度， 按照本次的 NACK信息指示的 4001-8192数据部分构造重传 PDU; 步骤 106, 基站收到 MAC的调度结果， 例如， TB的大小为 5000, 将重 传数据的 4001-8192的字节加入到 TB块中发送出去； 但是， 因为链路原因， 该 TB块在传输过程中丟失， RLC接收侧未收到， 则 步骤 107 , 基站收到对端发送的状态报告 Status— 3 , 解析状态报告 Status— 3 , 获取 NACK信息， 指示 4001-8192字节未收到。 步骤 108,基站比较本次的 NACK信息和上次的 NACK信息，若发现本 次的 NACK信息指示的重传部分长度等于上次的 NACK信息指示的重传部 分长度， 首先对重传次数 ( PdulRetransCount ) 进行加 1 操作， 判断 PdulRetransCount为 2, 小于 3 , 不发起重建， 按照本次的 NACK信息指示 的 4001-8192数据部分构造重传 PDU。 步骤 109 , 基站收到 MAC的调度结果， 例如， TB的大小为 5000。 RLC 将重传数据的 4001-8192的字节加入到 TB块中发送出去； 步骤 110 , 基站收到对端发送的状态报告 Status— 4 , 解析状态报告 Status— 4, 发现 PDU— 1 已经完全收到， 则删除保存的 PDU—1对应的 NACK 信息。 在重传报文的过程中， 若基站判断信道质量低于预定带宽， 则调度最小 的传输块将需要重传的数据进行多次重传， 以保证业务能够持续进行。 图 5 为 RLC协议层构造重传数据的流程图， 如图所示， 包括下面步骤： 步骤 201 , RLC协议层获取到 MAC层的调度结果， 即本次可发送的 TB 的长度； 步骤 202, RLC协议层根据状态报告获取重传队列的硬件资源， 从重传 队列中获取一个重传节点； 步骤 203 , RLC协议层判断调度的 TB是否小于门限值， 若是， 转向步 骤 204, 若否， 转向步骤 205; 步骤 204, RLC协议层将重传节点的描述符挂接到最小硬件重传队列中， 然后发送所述最小硬件重传队列指示的重传数据； 步骤 205, RLC协议层判断剩余的 TB长度是否大于获取到的重传节点 的长度， 若是， 则转向步骤 206, 若否， 则转向步骤 207; 步骤 206, RLC协议层直接将重传节点的数据填充到 TB块中， 然后返 回步骤 202; 步骤 207 , RLC协议层拆分重传节点， 将剩余 TB块填充满， 然后发送 TB块。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现。 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明不限制于任 何特定形式的硬件和软件的结合。
以上仅为本发明的优选实施例， 当然， 本发明还可有其他多种实施例， 在不背离本发明精神及其实质的情况下， 熟悉本领域的技术人员当可根据本 发明作出各种相应的改变和变形， 但这些相应的改变和变形都应属于本发明 所附的权利要求的保护范围。
工业实用性 本发明可以明显地减少处理器资源不断被少数业务占用的情况， 可以提 高单芯片的处理能力， 降低产品成本， 而且本发明的应用可以减少芯片尺寸 同时提高处理能力。 另外通过本发明还可以灵活设置不同类型的硬件重传队 列， 能够有效地利用硬件资源。

Claims

权 利 要 求 书
1、 一种处理重传数据的方法， 该方法包括： 基站在初始化的过程中， 根据业务类型设置不同存储容量的硬件重传队 歹 |J ; 以及 基站接收到构造重传报文的状态报告后， 根据该状态报告的指示申请第 一硬件重传队列 , 将所述状态报告指示需要重传的数据的描述符存储在第一 硬件重传队列， 利用硬件队列管理机制对第一硬件重传队列指定的重传数据 进行重组和传输。
2、如权利要求 1所述的方法， 其中， 所述基站利用硬件队列管理机制对 第一硬件重传队列指定的重传数据进行重组和传输的步骤包括： 所述基站调度传输块， 根据所述传输块的大小从第一硬件重传队列中获 取对应重传数据的描述符挂接到第二硬件重传队列中， 然后将第二硬件重传 队列指示的重传数据填充到所述传输块中， 发送填充有第二硬件重传队列指 示的重传数据的所述数据块。
3、 如权利要求 2所述的方法， 其中， 所述基站调度传输块之后， 所述基 站利用硬件队列管理机制对第一硬件重传队列指定的重传数据进行重组和传 输的步骤还包括： 所述基站若判断所述传输块小于门限值， 则根据最小硬件重传队列的大 小从第一硬件重传队列中获取对应重传节点的描述符挂接到最小硬件重传队 列中， 然后发送所述最小硬件重传队列指示的重传数据。
4、如权利要求 2所述的方法， 其中， 所述基站将第二硬件重传队列指示 的重传数据填充到所述传输块的步骤包括： 所述基站依次判断第二硬件重传队列中的重传节点的长度是否小于所述 传输块的剩余长度， 若是， 则直接将所述重传节点的重传数据填充到所述传 输块； 若否， 从该重传节点中截取重传数据填充满所述传输块。
5、如权利要求 1-4中任一项所述的方法， 所述基站将所述状态报告指示 需要重传的数据的描述符存储在第一硬件重传队列的步骤中， 所述方法还包 括： 保存第一硬件重传队列的队列标识与所述重传数据的描述符的对应关 系， 保存所述重传数据的描述符在第一硬件重传队列中链接关系， 保存所述 重传数据在内存中存储的头地址与所述重传数据的描述符的对应关系， 保存 所述重传数据在内存中分片存储的地址的链接关系， 及保存所述重传数据的 分片描述符与分片存储地址的对应关系。
6、 一种基站， 其包括： 设置模块， 其设置为： 在初始化的过程中， 根据业务类型设置不同存储 容量的硬件重传队列；
申请模块， 其设置为： 接收到构造重传报文的状态报告后， 根据该状态 报告的指示申请第一硬件重传队列；
存储模块， 其设置为： 将所述状态报告指示需要重传的数据的描述符存 储在第一硬件重传队列； 以及 传输模块， 其设置为： 利用硬件队列管理机制对第一硬件重传队列指定 的重传数据进行重组和传输。
7、 如权利要求 6所述的基站， 其中， 所述传输模块包括： 调度单元， 其设置为： 调度传输块； 挂接单元， 其设置为： 根据所述传输块的大小从第一硬件重传队列中获 取对应重传数据的描述符挂接到第二硬件重传队列中； 以及 传输单元， 其设置为： 将第二硬件重传队列指示的重传数据填充到所述 传输块中， 并发送填充有第二硬件重传队列指示的重传数据的所述数据块。
8、 如权利要求 7所述的基站， 其中， 所述传输单元包括： 判断子单元， 其设置为： 依次判断第二硬件重传队列中的重传节点的长 度是否小于所述传输块的剩余长度； 第一填充单元， 其设置为： 在判断子单元判断是的情况下， 直接将所述 重传节点中的重传数据填充到所述传输块； 以及
第二填充单元， 其设置为： 在判断子单元判断否的情况下， 从该重传节 点中截取重传数据填充满所述传输块。
9、 如权利要求 7所述的基站， 其中， 所述传输模块还包括： 判断单元， 其设置为： 判断所述传输块是否小于门限值； 所述挂接单元还设置为： 在所述判断单元判断所述传输块小于门限值的 情况下， 根据最小硬件重传队列的大小从第一硬件重传队列中获取对应重传 节点的描述符挂接到最小硬件重传队列中； 所述传输单元还设置为： 发送所述最小硬件重传队列指示的重传数据。
10、 如权利要求 6所述的基站， 其中： 所述存储模块还设置为： 保存第一硬件重传队列的队列标识与所述重传 数据的描述符的对应关系， 保存所述重传数据的描述符在第一硬件重传队列 中链接关系， 保存所述重传数据在内存中存储的头地址与所述重传数据的描 述符的对应关系， 保存所述重传数据在内存中分片存储的地址的链接关系， 及保存所述重传数据的分片描述符与分片存储地址的对应关系。
11、 如权利要求 6-10中任一项所述的基站， 其中， 所述基站为微型基站或毫微型基站。
PCT/CN2011/080689 2011-05-18 2011-10-12 一种处理重传数据的方法及基站 WO2012155441A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110129173.X 2011-05-18
CN201110129173.XA CN102790668B (zh) 2011-05-18 2011-05-18 一种处理重传数据的方法及基站

Publications (1)

Publication Number Publication Date
WO2012155441A1 true WO2012155441A1 (zh) 2012-11-22

Family

ID=47155976

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/080689 WO2012155441A1 (zh) 2011-05-18 2011-10-12 一种处理重传数据的方法及基站

Country Status (2)

Country Link
CN (1) CN102790668B (zh)
WO (1) WO2012155441A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110620639B (zh) * 2019-10-09 2022-01-21 中科睿微(宁波)电子技术有限公司 一种用于数据子帧聚合重传的硬件重传电路及方法
CN111147198B (zh) * 2020-01-02 2021-05-25 中科驭数（北京）科技有限公司 数据重传方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101018110A (zh) * 2006-02-10 2007-08-15 中兴通讯股份有限公司 一种基于重传次数的harq协议的重传调度方法
CN101277175A (zh) * 2007-03-30 2008-10-01 国际商业机器公司 改进会话启动协议服务器性能的方法和装置
CN101895372A (zh) * 2010-06-29 2010-11-24 中国科学院计算技术研究所 无线链路控制层确认模式下的数据传输方法
CN101931516A (zh) * 2009-06-25 2010-12-29 中兴通讯股份有限公司 一种无线链路控制层确认模式下快速重传的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101018110A (zh) * 2006-02-10 2007-08-15 中兴通讯股份有限公司 一种基于重传次数的harq协议的重传调度方法
CN101277175A (zh) * 2007-03-30 2008-10-01 国际商业机器公司 改进会话启动协议服务器性能的方法和装置
CN101931516A (zh) * 2009-06-25 2010-12-29 中兴通讯股份有限公司 一种无线链路控制层确认模式下快速重传的方法及装置
CN101895372A (zh) * 2010-06-29 2010-11-24 中国科学院计算技术研究所 无线链路控制层确认模式下的数据传输方法

Also Published As

Publication number Publication date
CN102790668A (zh) 2012-11-21
CN102790668B (zh) 2016-08-03

Similar Documents

Publication Publication Date Title
US10986653B2 (en) Method and system for sending and receiving data
US11122152B2 (en) Data processing method and apparatus to reduce an overhead in a layer two protocol
TWI220832B (en) A scheme to prevent HFN un-synchronization for UM RLC in a high speed wireless communication system
US9397791B2 (en) Transmitting data in a mobile communication system
EP2130387B1 (en) Cross-layer error recovery optimisation in wireless systems
JP4625044B2 (ja) ウィンドウ制御及び再送制御方法、及び、送信側装置
CN103782569B (zh) 数据处理装置和方法
TW201238294A (en) System for efficient recovery of node-B buffered data following MAC layer reset
KR101379408B1 (ko) 재송요구 송신방법 및 수신측장치
WO2009022877A2 (en) A method of transmitting and processing data block of specific protocol layer in wireless communication system
WO2017185941A1 (zh) 一种数据传输方法及相关设备
US10972923B2 (en) Information processing method and device
WO2016127666A1 (zh) 一种rlc数据包分流方法及基站
CN107276727A (zh) 一种进行反馈的方法和设备
WO2018127220A1 (zh) 一种数据转发方法及装置
CN107359972B (zh) 一种数据接收方法及装置
WO2011116577A1 (zh) 数据重传方法及装置
WO2012155419A1 (zh) 一种处理重传数据的方法及基站
WO2012155441A1 (zh) 一种处理重传数据的方法及基站
WO2018077195A1 (zh) 数据重传方法及装置、mac设备
WO2019015487A1 (zh) 一种数据重传处理方法、rlc实体和mac实体
WO2020087477A1 (zh) 用于传输数据分组的设备、方法、装置以及计算机可读存储介质
WO2011145474A1 (ja) 送信装置および再送制御方法、並びにコンピュータプログラム
WO2011144094A2 (zh) 数据重传方法及装置
CN118018629B (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: 11865618

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11865618

Country of ref document: EP

Kind code of ref document: A1