CN101646202B - 一种半静态调度下行传输的实现方法 - Google Patents

Abstract

本发明公开了一种半静态调度下行传输的实现方法，该方法中，eNB仅为每一个用户终端预留一个HARQ进程用于半静态调度下行传输，并将半静态调度的数据包进行绑定传输，使每个数据包在其对应的传输周期中的最大可传输次数大于等于四次。应用本发明可以在保证HARQ的正常合并的同时，将半静态调度下行传输的HARQ机制对LTE下行峰值速率的影响降至最低，并节省RRC的信令开销，以及在保证下行动态数据传输速率的同时降低下行调度的复杂度。

Description

一种半静态调度下行传输的实现方法

技术领域

本发明涉及LTE技术，特别涉及一种半静态调度下行传输的实现方法。 

背景技术

为了应对宽带接入技术的挑战，同时为了满足新型业务的需求，国际标准化组织3GPP在2004年底启动了其长期演进(LTE)技术的标准化工作。 

LTE***采用下行正交频分多址接入(OFDMA)、上行单载波频分复用(SC-FDMA)的接入方式，同时引入了多输入输出(MIMO)技术，很大程度地提高了***的传输能力，有效地抵抗了多径干扰，并且，可以灵活地配置不同的带宽。在20M带宽的情况下，LTE的目标是达到上行50Mbps、下行100Mbps的峰值传输速率。 

另外，LTE的演进目标为全IP的通信网络，支持丰富的多媒体、IP语音(VoIP，Voice over IP)、数据下载等业务。其中，VoIP也是LTE***一个主推的特色业务。 

LTE的特点在于高速，而VoIP业务是低速业务，但是VoIP业务的数据到达时间比较均匀固定，从而对于这类特殊业务，LTE***采用了一种在以往的通信***中所没有的调度方式——半静态调度(SPS，semi-persistentscheduling)方式，来控制这类业务的传输。 

LTE***中，半静态调度是指：基站给特定业务的数据包分配固定的时频资源，而该特定业务的数据包周期性的在该固定的时频资源位置传输，即在预分配的资源上传输，不需额外的物理下行控制信道(PDCCH，PhysicalDownlink Control Channel)调度信息。通过一个半静态配置好的传输周期，一次调度以后，用户终端(UE)即按照配置的周期和初始调度的资源进行 数据的发送和接收。如，对于VoIP业务而言，目前下行传输的默认配置周期为20ms，使用半静态调度方式传输VoIP业务，假设业务初始调度是在资源编号为n的资源上，则UE会每20ms在同样的资源n上进行发送/接收动作。 

对于半静态调度方案而言，除了调度算法以外，最重要的步骤有三步，分别为：半静态调度传输的启动、半静态调度传输的重传过程以及半静态调度传输的释放。 

由于半静态调度是一次配置、多次按照配置进行传输的方式，所以对于配置信息传输的准确性有很高的要求，以避免错误地接收配置信息而之后的每次传输都对其他用户造成严重干扰的情况。目前的LTE标准中明确指出：半静态调度的启动是通过半静态调度传输-小区无线网络临时标识(SPS-C-RNTI)掩码的分组数据控制信道(PDCCH)来指示的。为了提高可靠性，还规定了PDCCH中用于启动半静态调度的一些固定的比特位。其中包括：下行半静态调度传输的PDCCH中，混合自动重传请求(HARQ)进程ID必须设置为全0。 

为了提高半静态调度的可靠性而采取的上述固定PDCCH比特位的方法，同样也带来一些问题。对于下行传输而言，HARQ进程号是通过PDCCH来指示的。即使演进基站(eNB)自己维护了HARQ进程，但是，由于半静态调度的启动过程中eNB并未向UE给出相应的HARQ进程号，使得UE无法同步地获知当前半静态调度所使用的HARQ进程，如此，导致在存在重传的情况下，UE无法对重传下来的数据进行软合并。 

为了解决对重传的数据进行软合并的问题，3GPP提出了为半静态调度预留一些HARQ进程的方法。即：只要是半静态调度，eNB发送的用于启动半静态调度传输的PDCCH中就不需要携带HARQ进程的相关信息，UE自动地将预留的HARQ进程作为半静态传输的HARQ进程，并据此进行相关的软合并。 

然而，对于下行半静态调度而言，预留HARQ进程会导致UE下行峰值 速率的降低。这是因为：半静态调度算法主要是为一些低速率、数据包到达间隔比较固定的业务设计的，目前主要面向的是VoIP业务，但是，LTE的峰值速率主要是靠突发性的动态业务来实现，因此，为半静态调度预留HARQ进程会使UE的下行峰值速率降低n/m。这里，n表示预留的HARQ进程数，m表示最大的HARQ进程数。原则上来讲，为半静态调度预留的HARQ进程数应该刚刚满足其需求，这样既能够保证半静态传输的HARQ，又不会过多地影响UE的下行峰值速率。目前，LTE标准中规定，采用无线资源控制(RRC)消息为UE配置下行半静态调度所预留的HARQ进程数。 

以频分复用(FDD)为例，采用现有技术，如果仅为半静态调度预留一个HARQ进程，则会因为时间不足而导致每个UE的下行数据最多只能进行两次重传。这主要是因为：第一次传输和下一次重传之间至少需要间隔基站往返时延(RTT)ms，即：对FDD而言是8ms的时间，而VoIP的半静态调度周期为20ms，在20ms内，只能进行2次重传。如图1所示： 

数据包1、数据包2和数据包3分别是对应于第一个、第二个和第三个半静态调度传输周期的数据包； 

重传包1是当数据包1没有传输正确时，eNB重传的数据包1； 

UE预留了一个HARQ进程用于重传，进程ID为x。 

假设数据包1的第一次传输没有传输正确，其经过两次重传之后，第二个半静态调度的数据包2已经发送，则对于在数据包2和数据包3之间重传的重传包1，UE将无法将其与数据包1合并。这是因为：当UE接收到数据包2后，将清空半静态调度预留的HARQ进程中的缓存数据，并将新接收到的数据包2存入缓存。这样不仅导致数据包1的重传次数受到限制从而影响传输准确性，并且，eNB在数据包2和数据包3之间进行数据包1的重传还有可能带来HARQ合并失败。 

同样的问题，在时分复用(TDD)LTE***中会更为明显和严重。 

目前，3GPP倾向于预留2个或2个以上的HARQ进程，如图2所示： 

数据包1、数据包2和数据包3分别是对应于第一个、第二个和第三个 半静态调度传输周期的数据包； 

重传包1是当数据包1没有传输正确时，eNB重传的数据包1，重传包2是当数据包2没有传输正确时，eNB重传的数据包2； 

UE预留了两个HARQ进程用于重传，进程ID分别为x和y。 

假设数据包1的第一次传输没有传输正确，其第二次重传的数据包在重传时，第二个半静态调度的数据包2已经发送；并且，假设数据包2的第一次传输也没有传输正确，那么，在数据包2和数据包3之间重传的将有两个数据包：重传包1和重传包2。对于这两个重传的数据包，UE可以根据进程ID将其区分开来，并顺利进行合并。 

如此，通过预留2个或者更多的HARQ进程，并按照一定的规则进行循环使用，则重传通过PDCCH指示相应的HARQ进程号，可以避免图1所示现有技术的问题。 

考虑到大部分情况下，半静态调度的数据包不需要传输到最大次数就可以正确传输，同时，出于节省进程资源的考虑，LTE标准目前支持动态业务和半静态业务的调度共享资源的方式。即：如果***为半静态业务预留了多个HARQ进程，并且对应于某一个进程的半静态业务已经传输正确，在下次使用该进程传输新的半静态数据之前，可以在该进程上调度动态业务的数据，但是，一旦到达半静态调度周期，该进程就被收回用作半静态调度传输，而不管当前的动态业务是否已经传输正确。 

上述现有的预留多个HARQ进程用于半静态调度的下行传输方法，存在如下缺点： 

1、LTE作为3G***的长期演进，主推的一个功能即为高速的传输性能。对于VoIP而言，其典型速率在10～20Kbps范围内，而LTE在20M带宽的下行峰值速率为100Mbps，因此，半静态调度这种业务的传输速率相对于峰值速率几乎可以忽略，而预留n个(n≥2)HARQ进程会使LTE用户的下行峰值速率降低n/m。尤其是对于TDD模式而言，上下行子帧配置为0的情况，可能造成峰值速率损失一半或者更多。 

2、对于预留多少个HARQ进程，目前协议规定由RRC配置，即：需要额外的3bit RRC信令开销来配置预留多少个HARQ进程。 

3、上述现有半静态调度和动态调度共享HARQ进程的方案，增加了调度的复杂度和不可控因素。 

发明内容

有鉴于此，本发明的主要目的在于提供一种半静态调度下行传输的实现方法，以避免HARQ合并失败，降低半静态调度下行传输的HARQ机制对LTE下行峰值速率的影响，节省RRC的信令开销，以及在保证下行动态数据传输速率的同时降低下行调度的复杂度。 

为达到上述目的，本发明的技术方案具体是这样实现的： 

一种半静态调度下行传输的实现方法，该方法包括： 

A、演进基站为用户终端预留一个混合自动重传请求HARQ进程用于半静态调度下行传输； 

B、演进基站将半静态调度的数据包进行绑定传输，使每个数据包在其对应的传输周期中的最大可传输次数大于等于四次。 

较佳地，对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包连续发送两次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包连续发送两次。 

对应于上述较佳方案，该方法可以进一步包括： 

用户终端在所述第一次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息； 

用户终端在所述第二次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。 

较佳地，对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包发送一次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包连续发送三次。 

对应于上述较佳方案，该方法可以进一步包括： 

用户终端在所述第一次传输中接收一次数据包，并对所述数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息； 

用户终端在所述第二次传输中连续接收三次数据包，并对所述三次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。 

较佳地，对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包发送三次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包发送一次。 

对应于上述较佳方案，该方法可以进一步包括： 

用户终端在所述第一次传输中连续接收三次数据包，并对所述三次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息； 

用户终端在所述第二次传输中接收一次数据包，并对所述数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。 

较佳地，对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包发送一次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包连续发送两次，如果演进基站没有接收到用户终端返回的确认信息，则进行第三次传输，在第二次传输时，演进基站将所述数据包连续发送两次。 

对应于上述较佳方案，该方法可以进一步包括： 

用户终端在所述第一次传输中接收一次数据包，并对所述数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息； 

用户终端在所述第二次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果至少解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息； 

用户终端在所述第三次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码。 

由上述技术方案可见，本发明中，演进基站通过将半静态调度的数据包进行绑定传输，并保证每个数据包在其对应的传输周期中的最大可传输次数大于等于四次，使得演进基站只需为用户终端预留一个HARQ进程用于半静态调度下行传输即可。这是因为：传输次数大于等于四次可以认为已经能够将数据包正确传输，而本发明对同一数据包的多次传输均在该数据包所对应的传输周期中进行，对应于某一传输周期的数据包不会出现在该传输周期的下一传输周期中，因此，即使只预留一个HARQ进程也能够使用户终端分辨出当前接收到的数据包属于哪一个传输周期，不会使对应于不同传输周期的数据包之间混淆，从而避免了HARQ合并失败。 

由于采用本发明实现半静态调度下行传输只需预留一个HARQ进程，使得半静态调度下行传输中的HARQ机制对LTE下行峰值速率的影响降至最低。 

并且，采用本发明实现半静态调度下行传输只需预留一个HARQ进程，无需通过RRC信令配置预留多少个HARQ进程，从而节约了RRC的信令开销。 

此外，由于采用本发明实现半静态调度下行传输只需预留一个HARQ进程，无需将该预留的HARQ进程与动态业务共享使用，因此，无需涉及复杂的调度算法进行相应的资源调度，在保证下行动态数据传输速率的同时降低了下行调度的复杂度。 

附图说明

图1为现有为下行半静态调度预留1个HARQ进程的数据重传示意图； 

图2为现有为下行半静态调度预留2个HARQ进程的数据重传示意图。 

图3为本发明实施例一中对半静态调度的下行数据包进行绑定传输的示意图； 

图4为本发明实施例二中对半静态调度的下行数据包进行绑定传输的示意图； 

图5为本发明实施例三中对半静态调度的下行数据包进行绑定传输的示意图； 

图6为本发明实施例四中对半静态调度的下行数据包进行绑定传输的示意图； 

图7为在TDD模式、上下行子帧配置为0的情况下采用本发明实施例二中的方法对半静态调度的下行数据包进行绑定传输的示意图； 

图8为在TDD模式、上下行子帧配置为1的情况下采用本发明实施例二中的方法对半静态调度的下行数据包进行绑定传输的示意图； 

图9为在TDD模式、上下行子帧配置为6的情况下采用本发明实施例二中的方法对半静态调度的下行数据包进行绑定传输的示意图； 

图10为将本发明实施例二应用于下行半静态调度传输过程的传输流程示意图。 

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明作进一步详细说明。 

本发明的主要思想是：演进基站将半静态调度的数据包进行绑定传输，并保证每个数据包在其对应的传输周期中的最大可传输次数大于等于四次，使得演进基站只需为每一个用户终端预留一个HARQ进程用于半静态调度下行传输即可。 

基于本发明上述主要思想，本发明提供了四种将半静态调度的下行数据包进行绑定传输的方式，下面通过实施例一至实施例四分别予以详细说明。由于本发明涉及下行传输，如无特殊说明，本发明所述的数据包均为下行数据包。 

实施例一： 

本实施例中，对于每一个半静态调度的数据包，在第一次传输时，演进基站将该数据包连续发送两次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将该数据包也连续发送两次。也就是说：本实施例中，演进基站的两次传输都采用绑定传输的方式。 

在UE侧，UE在第一次传输中连续接收两次数据包，并对这两次接收的数据包进行合并，然后对合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息(ACK)，否则，向演进基站返回非确认信息(NACK)；如果存在第二次传输，那么UE在第二次传输中也是连续接收两次数据包，并对这两次接收的数据包进行合并，然后对合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。 

也就是说，UE并非每接收到一个数据包就对其进行解码，并产生相应的ACK/NACK信息，而是在接收到每一次绑定传输的两个数据包之后才进行合并、解码，并根据解码结果产生ACK/NACK信息。 

图3为本发明实施例一中对半静态调度的下行数据包进行绑定传输的示意图。参见图3： 

数据包1、数据包2和数据包3分别是对应于第一个、第二个和第三个半静态调度传输周期的数据包； 

重传包1和重传包2分别是数据包1和数据包2的重传数据包； 

UE预留了一个HARQ进程用于重传，进程ID为x。 

通过图3可以看到，每一个半静态调度的数据包的最大可传输次数为四次，这与现有技术中预留两个和以上的HARQ进程的传输效果相同。 

根据现有相关参考文献，VoIP发生重传的概率为10％～15％，在此，简单地假设每次传输都以上述概率发生重传，可以按照(1)式计算传输次数的期望值： 

a×(1-(error_rate)^a)+b×(error_rate)^a    (1) 

(1)式中，error_rate表示重传的概率； 

a表示第一次传输中，需要传输的数据包的次数，其发生的概率为1-(error_rate)^a； 

b表示在第一次传输失败，发生第二次传输时，需要传输的数据包的次数，由于必须是在第一次传输失败的情况下，才会进行b次数据包的传输，因此，其发生的概率为(error_rate)^a。 

对应到本实施例，a的取值为2，b的取值为4，error_rate的取值范围为10％～15％，因此，本实施例中，传输次数的期望值为：2.02～2.045次。 

实施例二： 

本实施例中，对于每一个半静态调度的数据包，在第一次传输时，演进基站仅将该数据包发送一次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将该数据包连续发送三次。也就是说：本实施例中，演进基站仅在第二次传输时采用绑定传输的方式。 

在UE侧，UE在第一次传输中接收一次数据包，并即刻对该数据包进行解码，如果解码正确，则向演进基站返回ACK，否则，向演进基站返回NACK；如果存在第二次传输，那么UE在第二次传输中连续接收三次数据包，并对这三次接收的数据包进行合并，然后对合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。 

也就是说，本实施例中，UE在接收到演进基站第一次传输的数据包时，即刻对其进行解码，并产生相应的ACK/NACK信息，而在第二次传输时，是在接收到绑定传输的三个数据包之后才进行合并、解码，并根据解码结果产生ACK/NACK信息。 

图4为本发明实施例二中对半静态调度的下行数据包进行绑定传输的示意图。参见图4： 

数据包1、数据包2和数据包3分别是对应于第一个、第二个和第三个半静态调度传输周期的数据包； 

重传包1和重传包2分别是数据包1和数据包2的重传数据包； 

UE预留了一个HARQ进程用于重传，进程ID为x。 

通过图4可以看到，每一个半静态调度的数据包的最大可传输次数为四次，这与现有技术中预留两个和以上的HARQ进程的传输效果相同。 

按照(1)式计算本实施例中传输次数的期望值，a的取值为1，b的取值为4，error_rate的取值范围为10％～15％，因此，本实施例中，传输次数的期望值为：1.3～1.5次。 

实施例三： 

本实施例中，对于每一个半静态调度的数据包，在第一次传输时，演进基站将该数据包连续发送三次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将该数据包仅发送一次。也就是说：本实施例中，演进基站仅在第一次传输时采用绑定传输的方式。 

在UE侧，UE在第一次传输中连续接收三次数据包，并对这三次接收的数据包进行合并，然后对合并得到的数据包进行解码，如果解码正确，则向演进基站返回ACK，否则，向演进基站返回NACK；如果存在第二次传输，那么UE在第二次传输中仅接收一次数据包，并即刻对该数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。 

也就是说，本实施例中，UE在接收到演进基站第一次绑定传输的三个数据包时，才对这三个数据包进行合并、解码，并产生相应的ACK/NACK信息，而在第二次传输时，由于只有一个数据包，接到该数据包就可以进行解码，并根据解码结果产生ACK/NACK信息。 

图5为本发明实施例三中对半静态调度的下行数据包进行绑定传输的示意图。参见图5： 

数据包1、数据包2和数据包3分别是对应于第一个、第二个和第三个半静态调度传输周期的数据包； 

重传包1和重传包2分别是数据包1和数据包2的重传数据包； 

UE预留了一个HARQ进程用于重传，进程ID为x。 

通过图5可以看到，每一个半静态调度的数据包的最大可传输次数为四次，这与现有技术中预留两个和以上的HARQ进程的传输效果相同。 

按照(1)式计算本实施例中传输次数的期望值，a的取值为3，b的取值为4，error_rate的取值范围为10％～15％，因此，本实施例中，传输次数的期望值为：3.0010～3.0034次。 

实施例四： 

本实施例中，对于每一个半静态调度的数据包，在第一次传输时，演进基站仅将该数据包发送一次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将该数据包连续发送两次，如果演进基站仍然没有接收到用户终端返回的确认信息，则进行第三次传输，在第三次传输时，演进基站将该数据包连续发送两次。也就是说：本实施例中，演进基站在第二次传输和第三次传输时采用绑定传输的方式。 

在UE侧，UE在第一次传输中接收一次数据包，并即刻对该数据包进行解码，如果解码正确，则向演进基站返回ACK，否则，向演进基站返回NACK；如果存在第二次传输，那么UE在第二次传输中连续接收两次数据包，并对这两次接收的数据包进行合并，然后对合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息；如果存在第三次传输，那么UE在第三次传输中连续接收两次数据包，并对这两次接收的数据包进行合并，然后对合并得到的数据包进行解码，这一次，UE不产生相应的ACK/NACK信息，演进基站也认为该数据包已经达到最大传输次数。 

图6为本发明实施例四中对半静态调度的下行数据包进行绑定传输的 示意图。参见图6： 

数据包1、数据包2和数据包3分别是对应于第一个、第二个和第三个半静态调度传输周期的数据包； 

重传包1和重传包2分别是数据包1和数据包2的重传数据包； 

UE预留了一个HARQ进程用于重传，进程ID为x。 

通过图6可以看到，每一个半静态调度的数据包的最大可传输次数为五次，比现有技术中预留两个和以上的HARQ进程的最大可传输次数还要多一次。 

对应于本实施例，可以按照(2)式计算传输次数的期望： 

1×(1-error_rate)+3×(error_rate-(error_rate)³)+5×(error_rate)³(2) 

根据error_rate的取值范围：10％～15％，可以得出：本实施例中，传输次数的期望值为：1.202～1.3067次。 

根据上面的分析，我们可以看出：首先，实施例二和实施例四在平均传输次数上具有比较明显的优势。其次，在实施例二和实施例四之间，二者具有相近的平均传输次数，但是，一方面，由于LTE下行传输为异步HARQ，而实施例四对于重传的时间限制比较严格，将会导致调度灵活性的损失；另一方面，实施例四在第三次传输中UE不反馈ACK/NACK信息，这对UE和eNB的行为改变较大。鉴于以上原因，在本发明所提供的诸实施例中，实施例二应当是下行半静态调度传输的最佳实现方案。对比目前LTE协议版本中的方案，其平均传输次数的数学期望为1.1111～1.1764次，本发明实施例二为1.3～1.5次，可见，实施例二在节省HARQ进程的同时并不会带来严重的***资源浪费。 

以上实施例一～实施例四中的图3～图6以FDD模式为例，示意性说明了本发明对半静态调度的下行数据包如何进行绑定传输。本发明同样也适用于TDD模式，下面以实施例二所提供的方案为例，结合附图，举例进行说明。 

对于TDD模式，现有协议规范确定支持的上下行子帧配置如表1所示，目前共存在7种配置方式。表1中，D表示下行子帧、U表示上行子帧、S表示特殊子帧。 

表1 

假设将本发明实施例二所提供的技术方案应用于上下行子帧配置为0的LTE TDD***中，将可以得到如图7所示的绑定传输示意图。参见图7： 

数据包1和数据包2分别是对应于第一个和第二个半静态调度传输周期的数据包；重传包1是数据包1的重传数据包。 

假设演进基站分配给本例中UE使用的下行半静态调度资源对应为子帧0、子帧20、子帧40......。 

在第一个半静态调度传输周期的第一次传输中，数据包1将在子帧0中传输。根据实施例二所提供的方法，UE接收到数据包1之后将进行解码，假设解码不正确，UE可以在子帧4中向eNB返回NACK信息。当然，也可以在其它上行子帧中返回NACK信息，考虑到传输时延、解码所需要的时间等因素，这里，以在子帧4中返回NACK信息为例进行说明。eNB收到该NACK信息后，确定需要进行第二次传输，因此，需要将子帧5～子帧19之间的连续三个下行子帧调度给该UE使用。考虑到传输时延的因素，假 设演进基站调度了子帧10、子帧11和子帧15给该UE，那么，在第二次传输中，重传包1将在子帧10、子帧11和子帧15中连续传输三次，UE将在对应的时间连续接收三次数据包。 

假设将本发明实施例二所提供的技术方案应用于上下行子帧配置为1的LTE TDD***中，将可以得到如图8所示的绑定传输示意图。参见图8： 

数据包1和数据包2分别是对应于第一个和第二个半静态调度传输周期的数据包；重传包1是数据包1的重传数据包。 

假设演进基站分配给本例中UE使用的下行半静态调度资源对应为子帧0、子帧20、子帧40......。 

在第一个半静态调度传输周期的第一次传输中，数据包1将在子帧0中传输。根据实施例二所提供的方法，UE接收到数据包1之后将进行解码，假设解码不正确，UE可以在子帧4中向eNB返回NACK信息。eNB收到该NACK信息后，确定需要进行第二次传输，因此，需要将子帧5～子帧19之间的连续三个下行子帧调度给该UE使用。假设演进基站调度了子帧9～11给该UE，那么，在第二次传输中，重传包1将在子帧9～11中连续传输三次，UE将在对应的时间连续接收三次数据包。 

假设将本发明实施例二所提供的技术方案应用于上下行子帧配置为6的LTE TDD***中，将可以得到如图9所示的绑定传输示意图。参见图9： 

数据包1和数据包2分别是对应于第一个和第二个半静态调度传输周期的数据包；重传包1是数据包1的重传数据包。 

假设演进基站分配给本例中UE使用的下行半静态调度资源对应为子帧0、子帧20、子帧40......。 

在第一个半静态调度传输周期的第一次传输中，数据包1将在子帧0中传输。根据实施例二所提供的方法，UE接收到数据包1之后将进行解码，假设解码不正确，UE可以在子帧4中向eNB返回NACK信息。eNB收到该NACK信息后，确定需要进行第二次传输，因此，需要将子帧5～子帧19之间的连续三个下行子帧调度给该UE使用。假设演进基站调度了子帧 9～11给该UE，那么，在第二次传输中，重传包1将在子帧9～11中连续传输三次，UE将在对应的时间连续接收三次数据包。 

将本发明实施例二提供的方法应用于下行半静态调度传输过程中，可以得到如图10所示的传输流程。参见图10，该传输流程从演进基站的角度进行描述，包括以下步骤： 

步骤1001：进行RRC配置。 

如前所述，采用本发明只需预留一个HARQ进程即可，无需通过RRC配置来告知UE预留多少个HARQ进程，因此，本步骤中的RRC配置只需按照现有技术执行除配置预留多少个HARQ进程之外的操作即可。 

步骤1002：通过PDCCH指示UE将要进行下行半静态调度传输。 

步骤1003：初始化变量n，置n＝0。 

步骤1004：进行第n个数据包的第一次传输。 

步骤1005：判断是否收到ACK，如果收到，执行步骤1008，否则，执行步骤1006。 

步骤1006：进行第n个数据包的三次绑定传输。 

步骤1007：判断是否收到ACK，如果收到，执行步骤1008，否则，执行步骤1009。 

步骤1008：得出第n个数据包传输正确的结论，执行步骤1010。 

步骤1009：得出第n个数据包传输失败的结论，执行步骤1010。 

步骤1010：n自加1。 

步骤1011：判断全部数据包是否传输完毕，如果尚未传输完毕，返回步骤1004，如果传输完毕，结束本传输流程。 

由于本发明各实施例均基于同一主要思想，且前面已对各实施例已进行详细介绍，因此，以上举例仅以实施例二为例进行说明，本发明其它实施例参照实施即可。 

由上述实施例可见，本发明中，演进基站通过将半静态调度的数据包进行绑定传输，并保证每个数据包在其对应的传输周期中的最大可传输次数大于等于四次，使得演进基站只需为用户终端预留一个HARQ进程用于半静态调度下行传输即可。这是因为：传输次数大于等于四次可以认为已经能够将数据包正确传输，而本发明对同一数据包的多次传输均在该数据包所对应的传输周期中进行，对应于某一传输周期的数据包不会出现在该传输周期的下一传输周期中，因此，即使只预留一个HARQ进程也能够使用户终端分辨出当前接收到的数据包属于哪一个传输周期，不会使对应于不同传输周期的数据包之间混淆，从而避免了HARQ合并失败。 

由于采用本发明实现半静态调度下行传输只需预留一个HARQ进程，使得半静态调度下行传输中的HARQ机制对LTE下行峰值速率的影响降至最低。 

并且，采用本发明实现半静态调度下行传输只需预留一个HARQ进程，无需通过RRC信令配置预留多少个HARQ进程，从而节约了RRC的信令开销。 

此外，由于采用本发明实现半静态调度下行传输只需预留一个HARQ进程，无需将该预留的HARQ进程与动态业务共享使用，因此，无需涉及复杂的调度算法进行相应的资源调度，在保证下行动态数据传输速率的同时降低了下行调度的复杂度。 

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。 

Claims (10)

1.一种半静态调度下行传输的实现方法，其特征在于，该方法包括：

A、演进基站为用户终端预留一个混合自动重传请求HARQ进程用于半静态调度下行传输；

B、演进基站将半静态调度的数据包进行绑定传输，使每个数据包在其对应的传输周期中的最大可传输次数等于四次。

2.根据权利要求1所述的方法，其特征在于，所述B包括：

对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包连续发送两次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包连续发送两次。

3.根据权利要求2所述的方法，其特征在于，该方法进一步包括：

用户终端在所述第一次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息；

用户终端在所述第二次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。

4.根据权利要求1所述的方法，其特征在于，所述B包括：

对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包发送一次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包连续发送三次。

5.根据权利要求4所述的方法，其特征在于，该方法进一步包括：

用户终端在所述第一次传输中接收一次数据包，并对所述数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息；

用户终端在所述第二次传输中连续接收三次数据包，并对所述三次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。

6.根据权利要求1所述的方法，其特征在于，所述B包括：

对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包发送三次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包发送一次。

7.根据权利要求6所述的方法，其特征在于，该方法进一步包括：

用户终端在所述第一次传输中连续接收三次数据包，并对所述三次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息；

用户终端在所述第二次传输中接收一次数据包，并对所述数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息。

8.一种半静态调度下行传输的实现方法，适用于长期演进计划频分复用LTE FDD***，其特征在于，该方法包括：

A、演进基站为用户终端预留一个混合自动重传请求HARQ进程用于半静态调度下行传输；

B、演进基站将半静态调度的数据包进行绑定传输，使每个数据包在其对应的传输周期中的最大可传输次数等于五次。

9.根据权利要求8所述的方法，其特征在于，所述B包括：

对于每一个半静态调度的数据包，在第一次传输时，演进基站将所述数据包发送一次，如果演进基站没有接收到用户终端返回的确认信息，则进行第二次传输，在第二次传输时，演进基站将所述数据包连续发送两次，如果演进基站没有接收到用户终端返回的确认信息，则进行第三次传输，在第三次传输时，演进基站将所述数据包连续发送两次。

10.根据权利要求9所述的方法，其特征在于，该方法进一步包括：

用户终端在所述第一次传输中接收一次数据包，并对所述数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息；

用户终端在所述第二次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码，如果解码正确，则向演进基站返回确认信息，否则，向演进基站返回非确认信息；

用户终端在所述第三次传输中连续接收两次数据包，并对所述两次接收的数据包进行合并，对所述合并得到的数据包进行解码。

Images