CN101615988B - 混合自动重传请求的调度方法 - Google Patents

Abstract

本发明提供了一种HARQ的调度方法，包括以下步骤：为半持久调度预留至少一个HARQ进程；UE解码预留HARQ进程中的一个HARQ进程的一次HARQ传输失败，且在该HARQ进程上至下一次HARQ重传的时机之间存在半持久调度时机；使用动态调度代替半持久调度或者仍然使用半持久调度而取消下一次HARQ重传。本发明的HARQ调度方法简单清晰、处理方便、可靠性高、延迟小。

Description

混合自动重传请求的调度方法

技术领域

本发明涉及通信领域，具体而言，涉及一种混合自动重传请求的调度方法。

背景技术

图1示出了第三代移动通信长期演进(Long Term Evolution，简称为LTE)系统的“演进的通用陆地无线接入网(Evolved UniversalTerrestrial Radio Access Network，简称为E-UTRAN，由基站eNB组成，因此也可以称为基站eNB)”的无线接口协议下行层2结构。在媒体接入控制(Media Access Control，简称为MAC)协议层，存在调度/优先级处理(Scheduling/Priority handling)功能实体，其中，调度功能支持动态调度(Dynamic scheduling)和半持久调度(或称为半静态调度)(Semi-persistent Scheduling)；优先级处理功能支持同一用户设备(User Equipment，简称为UE，即终端)不同逻辑信道之间的优先级处理，也支持通过动态调度进行不同UE之间的优先级处理。

E-UTRAN(Evolved UMTS Terrestrial Radio Access Network，陆地无线接入网)支持混合自动重传请求(Hybrid ARQ，简称为HARQ)功能。HARQ采用N道并行进程停等方式在层1(指物理层)对等实体间对传输块(Transport Block，简称为TB)进行发送和重传，用于提高传输块成功发送的可靠性。这些HARQ进程和HARQ实体相关联，HARQ实体在下行支持异步自适应重传，指重传的时机需要通过层1/层2(L1/L2)控制信道进行调度，而且可以使用和首传不同的无线资源、调制编码方案(MCS)等。在LTE系统中，层1/层2控制信道指物理下行控制信道(Physical DownlinkControl Channel，简称为PDCCH)。HARQ首传时发送传输块的初始冗余版本(Redundancy Version，简称为RV)，HARQ重传时发送传输块的其它冗余版本，HARQ首传和HARQ重传使用同一个HARQ进程，接收端在该HARQ进程缓冲区将接收到的重传的冗余版本和接收到的首传的冗余版本执行软合并操作。HARQ环回时间(HARQ Round Trip Time，简称为HARQ RTT)指HARQ首传和HARQ重传之间的最短时间间隔，HARQ首传之后，HARQ重传至少要在HARQ RTT时间之后才可以被调度。在下行，每个HARQ进程有一个显式的标识符，称为HARQ进程标识(HARQ Processidentifier)。E-UTRAN执行动态调度时，需要通过PDCCH指示HARQ进程标识以指定UE使用哪个HARQ进程处理相应的传输块。

下行动态调度功能是指，在下行，E-UTRAN能够通过PDCCH上的小区无线网络临时标识(Cell Radio Network TemporaryIdentifier，简称为C-RNTI)在每个传输时间间隔(Transmit TimeInterval，简称为TTI，对应于一个子帧(subframe))向UE动态分配资源，例如，物理资源块(Physical Resource Block，简称为PRB)和调制编码方案(Modulation and Coding Scheme，简称为MCS)等。在允许进行下行接收时(由不连续接收功能(DRX)所控制)，UE总是监控PDCCH，从而为下行接收发现可能的资源分配。PDCCH用于下行调度时主要携带下行资源分配信息，主要内容包括资源块RB分配信息、传输格式(Transport Format，简称为TF)或调制编码方案(MCS)、HARQ信息、发送功率控制TPC信息、无线网络临时标识RNTI/循环冗余校验CRC等信息。UE通过物理上行控制信道(Physical Uplink Control Channel，简称为PUCCH)对下行数据发送反馈混合自动重传请求的确认/非确认响应消息ACK/NACK。

下行半持久调度是指，在下行，E-UTRAN可以为UE的首次HARQ发送分配持久下行资源即预定义资源，包括物理资源块PRB、调制编码方案MCS等。需要时，重传信息通过PDCCH用显式信令指示，即HARQ重传使用动态调度。在UE具有持久资源的子帧(Subframe)期间，如果UE没有在PDCCH上发现其C-RNTI，则认为在相应的TTI有根据持久分配的资源所进行的下行发送。另外，在UE具有持久资源的子帧期间，如果UE在PDCCH上发现了其C-RNTI，则UE在相应的TTI使用PDCCH指示的资源分配替代(Override)持久资源的分配，且不对持久资源进行解码。典型地，半持久调度应用于VoIP业务，为其分配的持久资源以20ms为周期。半持久调度由无线资源控制(Radio Resource Control，简称为RRC)信令进行初始配置，例如分配半持久调度的周期(Periodicity)。半持久调度的激活(Activation)由PDCCH控制，PDCCH通过特殊的C-RNTI进行指示，该特殊的C-RNTI与动态调度时所使用的C-RNTI不同。

在下行半持久调度中，HARQ首传使用持久资源，仅在激活持久资源时使用一次PDCCH信令，UE将所分配到的持久资源存储起来，以后的HARQ首传不再需要通过PDCCH指示HARQ进程标识等信息。HARQ重传使用异步自适应方式进行动态调度，每次重传均需要通过PDCCH指示HARQ进程标识等信息。在接收HARQ重传时，UE无法知道HARQ首传时所使用的HARQ进程，因此也无法在所期望的HARQ进程缓冲区执行软合并操作。上述问题描述如图2所示，为持久调度预分配的资源用于HARQ首传，位于子帧N1、N2、N3，设上述每两个相邻子帧之间的时间间隔均为20ms；通过动态调度进行HARQ重传，由PDCCH指示重传所使用的HARQ进程标识，HARQ重传位于子帧X1、X2、X3。由于HARQ首传时没有HARQ进程标识信息，UE不知道HARQ首传时使用的HARQ进程，尽管HARQ重传时在PDCCH上指示了HARQ进程标识信息，UE却无法把两者关联起来。

为解决上述问题，目前主要有如下一些可行的方案：

方案一：不为半持久调度预留HARQ进程，对于HARQ首传，使用一块空闲的缓冲区和一个内部临时HARQ标识相关联。该方案需要对HARQ重传的调度进行一些限制，例如，基站eNB在收到使用持久资源进行HARQ首传的非确认响应消息NACK后，需要首先调度其对应的HARQ重传，然后将临时的HARQ标识和该HARQ重传时所使用的HARQ标识关联；如果有多个根据持久资源的HARQ首传均需要重传，则按照HARQ首传的次序依次调度对应的HARQ重传；该方案在和动态调度交互时还存在一些异常情况需要额外的限制。总体而言，尽管该方案不需要预留HARQ进程，在一定程度上对于提高吞吐量和峰值数据速率有利，但复杂性较高，可靠性相对较低。

方案二：为半持久调度预留一个HARQ进程，将该HARQ进程的缓冲区分为两部分用以存储两个存储块，并用HARQ重传时PDCCH信令中的新数据指示字段(NDI)的不同值区分上述两个传输块。预留一个HARQ进程存在的问题是：当根据某持久资源进行的HARQ首传需要进行多次HARQ重传，且HARQ重传所位于的子帧超过下一个持久资源的所占用的子帧位置时，如果有新数据需要利用该持久资源执行HARQ首传，则对应的HARQ缓冲区需要被清空以存储新的传输块，从而其前一个持久资源所对应的HARQ重传不得不放弃。例如，HARQ实体支持8个并行的HARQ进程，HARQ RTT为8ms，当半持久调度用于VoIP业务时，持久资源每20ms为可用状态。则两次持久资源所位于的子帧之间最多可以允许2次HARQ重传，在上一次HARQ首传之后20ms的子帧位置，即在下一次持久资源可用的子帧位置，如果有新的传输块需要发送，则HARQ进程缓冲区需要被清空以进行新的HARQ首传。这时如果前一个传输块的HARQ重传已经进行了2次，但仍然没有成功，也无法进行第3次以及更多次HARQ重传。上述问题的描述如图2所示，设为半持久调度预留HARQ进程X，该预留的HARQ进程号可以通过RRC信令或PDCCH信令由基站eNB通知UE，于是UE知道HARQ首传和HARQ重传均会使用HARQ进程X，解决了HARQ首传和HARQ重传的关联问题。但是，在子帧N1和N2之间仅允许进行两次HARQ重传，如果在子帧N2处有新的传输块，则需要在该位置进行新的HARQ首传，于是对于子帧N1的HARQ重传即使没有成功也需要使用新接收的传输块替换原来HARQ缓冲区的内容，从而导致对于子帧N1的传输块接收失败。如果要在子帧X3处继续重传子帧N1所对应的传输块的冗余版本，则可能导致对于子帧N2的传输块也接收失败，因为在子帧N2及之后，HARQ缓冲区中的内容是对应于子帧N2的HARQ首传的冗余版本。本方案将HARQ进程的缓冲区分为两部分解决了上述问题。由于使用半持久调度的业务其传输块所需要的缓冲区较小，因此将对应的HARQ缓冲区分为两部分是可行的。该方案预留一个HARQ进程对吞吐量和峰值数据速率的影响也相对较小，缺点是对于HARQ缓冲区的操作相对复杂，需要额外定义与现有HARQ流程不同的特殊行为。

方案三：为半持久调度预留一个HARQ进程，并根据实际需要动态预留其他空闲HARQ进程用于半持久调度。该方案中动态预留其他HARQ进程也可以解决方案二中提到的仅预留一个HARQ进程时所存在的问题，对于吞吐量和峰值数据速率的影响相对较小，资源利用率较高；缺点是通过PDCCH动态预留以及释放HARQ进程的操作较复杂，可靠性较低，存在预留或释放失败的情况，从而导致HARQ重传失败或者无线资源浪费现象，而且检测上述错误情况需要额外的机制，也会带来新的复杂性和延迟。

方案四：预留两个或更多HARQ进程用于半持久调度，两个或更多HARQ进程轮流使用持久资源执行HARQ首传，用系统帧(System Frame Number，简称为SFN)+子帧(Subframe)来区分不同的HARQ进程发送时机，从而将各自的HARQ重传和HARQ首传相关联。该方案对于所预留的其中一个HARQ进程而言，相当于把持久资源所占用的子帧位置的周期扩大了。例如在预留了两个HARQ进程用于半持久调度时，两个HARQ进程轮流使用的情况，以VoIP业务为例，对于其中的一个HARQ进程，相当于持久资源的周期从20ms扩大为40ms，于是两次可用持久资源所占用的子帧之间最多可以允许4次HARQ重传，从而提高了HARQ重传成功的概率。在LTE系统中，1个SFN由10个子帧组成，每个子帧1ms，共10ms，于是VoIP业务的两次可用持久资源之间有2个SFN。当两个HARQ进程轮流使用持久资源时，对于其中一个HARQ进程而言，其持久资源的周期为4个SFN。上述方案如图3所示，预留HARQ进程x、y用于半持久调度，HARQ进程x的持久资源位于子帧N1、N3...等，用于执行HARQ首传；HARQ进程y的持久资源位于子帧N2...等，用于执行HARQ首传。子帧N1、N2、N3分别位于系统帧SFN1、SFN3、SFN5内。HARQ进程x的HARQ重传所在的子帧为N1_X1、N1_X2、N1_X3，HARQ进程y的HARQ重传所在的子帧为N2_X1。由于两个HARQ进程使用各自的HARQ缓冲区，因此跨越持久资源边界的HARQ重传N1_X3不影响HARQ重传N2_X1。该方案的优点是简单清晰，缺点是对吞吐量和峰值数据速率的影响较大。由于多数情况下不需要超过2次以上的HARQ重传，预留2个或更多HARQ进程用于半持久调度将浪费无线资源。对该方案进一步的优化为上述预留的HARQ进程在不用于半持久调度时可以分配给动态调度使用，但这很大地提高了该方案的复杂度，且带来的增益有限。

方案二、方案三、方案四的共同特征是为半持久调度预留HARQ进程以解决HARQ重传和HARQ首传的关联问题，不同点是对于HARQ重传越过持久资源所在的子帧边界情况下的处理。

上述四种方案尽管都可以解决下行半持久调度所存在的上述问题，但是这四种方案都存在复杂度高、可靠性低的缺点。

发明内容

本发明旨在提供一种HARQ的调度方法，以解决上述方案复杂度高、可靠性低的问题。

本发明的技术方案提供了一种HARQ的调度方法，包括以下步骤：为半持久调度预留至少一个HARQ进程；UE解码预留HARQ进程中的一个HARQ进程的一次HARQ传输失败，且在该HARQ进程上至下一次HARQ重传的时机之间存在半持久调度时机；使用动态调度代替半持久调度或者仍然使用半持久调度而取消下一次HARQ重传。

优选的，为半持久调度预留至少一个HARQ进程具体包括：将预留HARQ进程的相关信息通过无线资源控制信令或者PDCCH配置给UE。

优选的，为半持久调度预留至少一个HARQ进程具体包括：配置预留HARQ进程的个数为固定值；或者根据半持久调度的周期配置预留HARQ进程的个数。

优选的，所述预留的HARQ进程可以被动态调度完全共享，即动态调度在任意子帧可以使用所述预留的HARQ进程，包括持久资源存在期间以及持久资源被释放以后。

优选的，下一次HARQ重传使用预留HARQ进程。

优选的，下一次HARQ重传使用预留HARQ进程具体包括：UE将下一次HARQ重传的冗余版本与预留HARQ进程的缓冲区中的现有数据执行软合并。

优选的，使用动态调度代替半持久调度具体包括：动态调度使用不同于预留HARQ进程的其他HARQ进程；其中，如果至下一次HARQ重传的时机之间存在多个半持久调度时机，则对于多个半持久调度时机的动态调度分别使用不同的HARQ进程；或者动态调度使用预留HARQ进程。

优选的，至下一次HARQ重传的时机之间存在多个半持久调度时机，使用动态调度代替半持久调度具体包括：动态调度在两次半持久调度时机之间发生。

优选的，使用动态调度代替半持久调度具体包括：基站在半持久调度时机使用动态调度覆盖半持久调度；UE在半持久调度时机监控PDCCH，根据PDCCH上所指示的资源分配信息处理新的HARQ首传或者HARQ重传。

优选的，根据PDCCH上所指示的资源分配信息处理新的HARQ首传或者HARQ重传具体包括：基站重新动态分配半持久调度所预先配置的持久资源，将持久资源分配给原UE或者分配给其他UE；UE根据PDCCH上所指示的所述重新动态分配的资源处理HARQ首传或者HARQ重传。

优选的，资源分配信息包括以下至少之一：资源块分配信息、调制编码方案信息、HARQ信息。

优选的，根据PDCCH上所指示的资源分配信息处理新的HARQ首传具体包括：UE接收资源分配信息所指示的传输块的冗余版本时，使用PDCCH上所指示的HARQ进程的缓冲区。

优选的，根据PDCCH上所指示的资源分配信息处理新的HARQ首传具体包括：取消前一次半持久调度时机的HARQ首传所对应的进一步的HARQ重传。

优选的，根据PDCCH上所指示的资源分配信息处理HARQ重传具体包括：UE根据PDCCH上所指示的HARQ进程处理新的HARQ首传时，如果解码失败，则使用PDCCH上所指示的HARQ进程处理进一步的HARQ重传。

优选的，UE在半持久调度时机监控PDCCH时没有接收到PDCCH信令，还包括：UE向HARQ实体指示新的发送及其关联的HARQ信息，处理该次半持久调度的HARQ首传；在处理该次半持久调度的HARQ首传时，使用预留HARQ进程，并用所接收到的数据替代缓冲区中的当前数据；如果解码失败，则进一步的HARQ重传使用预留HARQ进程，并用所接收到的数据替代缓冲区中的当前数据。

本发明的调度方法因为采用动态调度覆盖半持久调度，所以克服了现有技术方案复杂度高、可靠性低的问题，进而达到了简单清晰、处理方便、可靠性高、延迟小的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1示出了E-UTRAN无线接口协议下行层2结构的示意图；

图2示出了半持久调度HARQ重传与HARQ首传的关联问题以及为半持久调度预留一个HARQ进程时的问题示意图；

图3示出了现有为半持久调度预留两个HARQ进程解决方案示意图；

图4示出了根据本发明实施例的HARQ调度方法的流程图；

图5示出了根据本发明优选实施例的HARQ调度方法的示意图；

图6示出了根据本发明优选实施例的HARQ调度方法的流程图。

具体实施方式

下面将参考附图并结合实施例，来详细说明本发明。

图4示出了根据本发明实施例的HARQ调度方法的流程图，包括以下步骤：

步骤S10，为半持久调度预留至少一个HARQ进程；

步骤S20，UE解码预留HARQ进程中的一个HARQ进程的一次HARQ传输失败，且在该HARQ进程上至下一次HARQ重传的时机之间存在半持久调度时机；

步骤S30，使用动态调度代替(Override)半持久调度或者仍然使用半持久调度而取消下一次HARQ重传。

所述半持久调度时机指持久资源所位于的一个子帧或连续的多个子帧。所述HARQ重传时机指HARQ重传机会所位于的一个子帧或连续的多个子帧。所述HARQ传输指HARQ首传或HARQ重传。

该调度方法在解码失败时因为采用动态调度覆盖半持久调度，所以克服了现有技术方案杂度高、可靠性低的问题，该HARQ重传和HARQ首传的关联方案，仅需要预留一个HARQ进程，和预留两个HARQ进程的方案相比，对于吞吐量和峰值数据速率的影响较小，节省无线资源；和其他预留一个HARQ进程的方案相比，简单清晰、处理方便、可靠性高、延迟小。显然，本发明其他优选实施例的调度方法也支持预留两个或以上HARQ进程。

优选的，步骤S10具体包括：将预留HARQ进程的相关信息通过无线资源控制信令(RRC)或者层1/层2控制信道PDCCH配置给UE。

优选的，步骤S10具体包括：配置预留HARQ进程的个数为固定值；或者根据半持久调度的周期配置预留HARQ进程的个数。

优选的，所述预留的HARQ进程可以被动态调度完全共享，即动态调度在任意子帧可以使用所述预留的HARQ进程，包括持久资源存在期间以及持久资源被释放以后。

优选的，下一次HARQ重传使用预留HARQ进程。

优选的，下一次HARQ重传使用预留HARQ进程具体包括：UE将下一次HARQ重传的冗余版本与预留HARQ进程的缓冲区中的现有数据执行软合并。

优选的，步骤S30具体包括：动态调度使用不同于预留HARQ进程的其他HARQ进程；其中，如果至下一次HARQ重传的时机之间存在多个半持久调度时机，则对于多个半持久调度时机的动态调度分别使用不同的HARQ进程；或者动态调度使用预留HARQ进程。

优选的，至下一次HARQ重传的时机之间存在多个半持久调度时机，步骤S30具体包括：动态调度在两次半持久调度时机之间发生。

优选的，步骤S30具体包括：

基站在半持久调度时机使用动态调度覆盖半持久调度；

UE认为所述半持久调度时机将被动态调度所代替，在半持久调度时机监控PDCCH，根据PDCCH上所指示的资源分配信息处理新的HARQ首传或者HARQ重传。

优选的，根据PDCCH上所指示的资源分配信息处理新的HARQ首传或者HARQ重传具体包括：基站重新动态分配半持久调度所预先配置的持久资源，将持久资源分配给原UE或者分配给其他UE。UE根据PDCCH上所指示的所述重新动态分配的资源处理HARQ首传或者HARQ重传。

优选的，资源分配信息包括以下至少之一：资源块(RB)分配信息、调制编码方案(MCS)信息、HARQ信息。HARQ信息可以包括新的HARQ进程标识，该进程标识可以与为半持久调度所预留的HARQ进程标识相同或不同。

优选的，根据PDCCH上所指示的资源分配信息处理新的HARQ首传具体包括：UE接收资源分配信息所指示的传输块的冗余版本时，使用PDCCH上所指示的HARQ进程的缓冲区。

优选的，根据PDCCH上所指示的资源分配信息处理HARQ重传具体包括：UE根据PDCCH上所指示的HARQ进程处理新的HARQ首传时，如果解码失败，则使用PDCCH上所指示的HARQ进程处理进一步的HARQ重传。

优选的，UE在半持久调度时机监控PDCCH时没有接收到PDCCH信令，还包括：

UE向HARQ实体指示新的发送及其关联的HARQ信息，处理该次半持久调度的HARQ首传；

在处理该次半持久调度的HARQ首传时，使用预留HARQ进程，并用所接收到的数据替代缓冲区中的当前数据；如果解码失败，则进一步的HARQ重传使用预留HARQ进程，并用所接收到的数据替代缓冲区中的当前数据。

图5示出了根据本发明优选实施例的HARQ调度方法的示意图，说明如下：

预留一个HARQ进程用于半持久调度，HARQ进程标识为x。用于半持久调度的持久资源所位于的子帧为N1、N2、N3，分别位于系统帧SFN1、SFN3、SFN5内，用于执行HARQ首传。设在子帧N1处UE解码HARQ首传失败，在子帧N1_X1、N1_X2处UE解码HARQ重传均失败，UE期望的下一次HARQ重传位于子帧N2之后，假定为需要在子帧N1_X3的位置接收该次HARQ重传。根据本发明，UE不能在子帧N2位置处使用预先配置的持久资源处理HARQ首传，而是在子帧N2处根据PDCCH上所指示的HARQ进程y处理新的HARQ首传。并在子帧N1_X3位置处使用HARQ进程x处理针对子帧N1的HARQ首传所对应的进一步HARQ重传。如果UE在子帧N2使用HARQ进程y解码HARQ首传失败，则UE在子帧N2_X1根据PDCCH上所指示的HARQ进程y处理针对子帧N2的HARQ首传所对应的HARQ重传。由于子帧N1的HARQ首传及其对应的HARQ重传均使用HARQ进程x及其对应的HARQ缓冲区，子帧N2的HARQ首传及其对应的HARQ重传使用动态调度时PDCCH上所指示的新的HARQ进程y及其对应的HARQ缓冲区，因此跨越持久资源边界的HARQ重传N1_X3不影响子帧N2处的HARQ首传及子帧N2_X1处的HARQ重传。

进一步地，如果UE在子帧N2处未接收到PDCCH上的信令，则UE根据预先配置的持久资源用使用预留的HARQ进程x处理HARQ首传，用新接收到的传输块取代当前HARQ缓冲区中的数据。相当于针对子帧N1的HARQ首传所对应的HARQ重传N1_X3被强拆，导致的数据丢失由无线链路控制层RLC的自动重传请求ARQ进行恢复。

图6示出了根据本发明优选实施例的HARQ调度方法的流程图，步骤如下：

步骤110：为半持久调度预留HARQ进程，基站通过RRC信令或PDCCH通知UE所预留的HARQ进程号

步骤120：UE所期望的HARQ重传是否将越过下一个可用持久资源所在的子帧？如果是，转步骤140；否则转步骤130；

步骤130：在HARQ重传位于两次可用持久资源所在的子帧之间的情况下，UE使用预留的HARQ进程处理HARQ首传及HARQ重传，转步骤120；

步骤140：在该持久资源所位于的子帧，UE监控PDCCH信道，是否接收到PDCCH信令？如果是，转步骤160；否则转步骤150；

步骤150：对于该持久资源所在的子帧使用动态调度替代半持久调度，使用PDCCH上指示的其他HARQ进程处理其HARQ首传及进一步的HARQ重传；转步骤120；

步骤160：UE使用持久资源在预留的HARQ进程处理新的HARQ首传，放弃对于前一次持久资源的HARQ首传所对应的进一步的HARQ重传；转步骤120；

从以上的描述中可以看出，上述实施例的HARQ调度方法提出的HARQ重传和HARQ首传的关联方案，仅需要预留一个HARQ进程，和预留两个HARQ进程的方案相比，对于吞吐量和峰值数据速率的影响较小，节省无线资源；和其他预留一个HARQ进程的方案相比，本发明简单清晰、处理方便、可靠性高、延迟小。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种混合自动重传请求的调度方法，其特征在于，包括以下步骤：

终端为半持久调度预留至少一个混合自动重传请求进程；

终端解码失败，其中，所述终端解码所述预留混合自动重传请求进程中的一个混合自动重传请求进程的一次混合自动重传请求传输失败，且在该混合自动重传请求进程上至下一次混合自动重传请求重传的时机之间存在半持久调度时机，所述半持久调度时机为持久资源所位于的一个子帧或连续的多个子帧；

根据UE所期望的HARQ重传是否将越过下一个可用持久资源所在的子帧，以及在该可用持久资源所在的子帧是否接收到PDCCH信令，使用动态调度代替所述半持久调度或者仍然使用半持久调度而取消下一次混合自动重传请求重传，其中，该步骤如下：在上述两者判断结果均为是的情况下，使用动态调度代替所述半持久调度；在前者判断结果为是，后者判断结果为否的情况下，仍然使用半持久调度而取消下一次混合自动重传请求重传。

2.根据权利要求1所述的调度方法，其特征在于，为半持久调度预留至少一个混合自动重传请求进程具体包括：

将所述预留混合自动重传请求进程的相关信息通过无线资源控制信令或者物理下行控制信道配置给所述终端。

3.根据权利要求1所述的调度方法，其特征在于，为半持久调度预留至少一个混合自动重传请求进程具体包括：

配置所述预留混合自动重传请求进程的个数为固定值；或者

根据半持久调度的周期配置所述预留混合自动重传请求进程的个数。

4.根据权利要求1所述的调度方法，其特征在于，为半持久调度预留至少一个混合自动重传请求进程具体包括：所述预留的混合自动重传请求进程被所述动态调度完全共享。

5.根据权利要求1所述的调度方法，其特征在于，所述下一次混合自动重传请求重传使用所述预留混合自动重传请求进程。

6.根据权利要求5所述的调度方法，其特征在于，所述下一次混合自动重传请求重传使用所述预留混合自动重传请求进程具体包括：

所述终端将所述下一次混合自动重传请求重传的冗余版本与所述预留混合自动重传请求进程的缓冲区中的现有数据执行软合并。

7.根据权利要求1所述的调度方法，其特征在于，使用动态调度代替所述半持久调度具体包括：

所述动态调度使用不同于所述预留混合自动重传请求进程的其他混合自动重传请求进程；其中，如果至下一次混合自动重传请求重传的时机之间存在多个所述半持久调度时机，则对于所述多个半持久调度时机的动态调度分别使用不同的混合自动重传请求进程；或者

所述动态调度使用所述预留混合自动重传请求进程。

8.根据权利要求1所述的调度方法，其特征在于，至下一次混合自动重传请求重传的时机之间存在多个所述半持久调度时机，使用动态调度代替所述半持久调度具体包括：

所述动态调度在两次所述半持久调度时机之间发生。

9.根据权利要求1所述的调度方法，其特征在于，使用动态调度代替所述半持久调度具体包括：

基站在所述半持久调度时机使用动态调度覆盖所述半持久调度；

终端在所述半持久调度时机监控物理下行控制信道，根据物理下行控制信道上所指示的资源分配信息处理新的混合自动重传请求首传或者混合自动重传请求重传。

10.根据权利要求9所述的调度方法，其特征在于，根据物理下行控制信道上所指示的资源分配信息处理新的混合自动重传请求首传或者混合自动重传请求重传具体包括：

所述基站重新动态分配所述半持久调度所预先配置的持久资源，将所述持久资源分配给原终端或者分配给其他终端；

所述终端根据物理下行控制信道上所指示的所述重新动态分配的资源处理混合自动重传请求首传或者混合自动重传请求重传。

11.根据权利要求10所述的调度方法，其特征在于，所述资源分配信息包括以下至少之一：

资源块分配信息、调制编码方案信息、混合自动重传请求信息。

12.根据权利要求9所述的调度方法，其特征在于，根据物理下行控制信道上所指示的资源分配信息处理新的混合自动重传请求首传具体包括：

所述终端接收所述资源分配信息所指示的传输块的冗余版本时，使用所述物理下行控制信道上所指示的混合自动重传请求进程的缓冲区。

13.根据权利要求9所述的调度方法，其特征在于，根据物理下行控制信道上所指示的资源分配信息处理新的混合自动重传请求首传具体包括：

取消前一次半持久调度时机的混合自动重传请求首传所对应的进一步的混合自动重传请求重传。

14.根据权利要求9所述的调度方法，其特征在于，根据物理下行控制信道上所指示的资源分配信息处理混合自动重传请求重传具体包括：

所述终端根据所述物理下行控制信道上所指示的混合自动重传请求进程处理所述新的混合自动重传请求首传时，如果解码失败，则使用所述物理下行控制信道上所指示的混合自动重传请求进程处理进一步的混合自动重传请求重传。

15.根据权利要求9所述的调度方法，其特征在于，终端在所述半持久调度时机监控物理下行控制信道时没有接收到物理下行控制信道信令，还包括：

所述终端向混合自动重传请求实体指示新的发送及其关联的混合自动重传请求信息，处理该次半持久调度的混合自动重传请求首传；

在处理该次半持久调度的混合自动重传请求首传时，使用所述预留混合自动重传请求进程，并用所接收到的数据替代缓冲区中的当前数据；如果解码失败，则进一步的混合自动重传请求重传使用所述预留混合自动重传请求进程，并用所接收到的数据替代缓冲区中的当前数据。

Images