基站和LTE***中处理下行HARQ反馈的方法、装置
技术领域
本发明涉及通信技术领域,尤其涉及一种基站和LTE***中处理下行HARQ反馈的方法、装置。
背景技术
为了适应未来移动通信***高速率和高可靠性数据传输以及满足新型业务需求,第三代合作伙伴计划(3GPP)启动了长期演进***(LTE,Long Term Evolution)。LTE作为第三代移动通信(3G)技术和***移动通信(4G)技术之间的一个过渡,被成为“准4G”技术。LTE具有高频率利用率、高峰值速率、高可靠性传输、低延时等特定,已经成为移动通信技术领域一项重大技术革新。
混合自动重传请求(HARQ,Hybrid Automatic Repeat Request)技术,则是高可靠性数据传输的有效保障,是LTE的关键技术之一。
LTE***采用异步自适应的HARQ机制,即:在任一帧的位置调用HARQ进程传输数据后,就等待接收端的确认。接收端接收到数据后,进行接收检测,如果检测结果为正确,则向发送端反馈一个成功应答信号,否则向发送端反馈一个非成功应答信号。发送端接收则根据接收端的反馈消息后,查找相应的HARQ进程并根据反馈消息是成功应答或者非成功应答来决定是否重新传输。为了充分利用时域资源,LTE***还进一步采用了多进程的HARQ技术,在一个子帧调用HARQ进程传输数据后,等待接收HARQ反馈消息的过程中,调用其他的HARQ进程传输其他数据,即有多个异步自适应的HARQ进程同时启动。
现有技术中,在进行LTE下行HARQ反馈处理时,会对每个小区内的通信终端维护两个数组或链表,分别用于存放空闲的HARQ进程和繁忙的HARQ进程。当基站接收到通信终端发送的反馈消息后,遍历查找繁忙的HARQ进程数组或链表,然后根据反馈消息决定下一步的操作:如果是成功应答,则将该HARQ进程从繁忙的HARQ进程数组或链表中取出放入空闲HARQ进程数组或链表,否则仍调用该HARQ进程进行重传。然而,对数组或链表的查找会占用大量的***开销,影响LTE***处理HARQ反馈的效率。尤其是在小区内的通信终端数量较多时,下行HARQ反馈的消息会非常多,上述问题也会更加突出。因此,迫切需要找到一种高效的处理下行HARQ反馈的方法。
相关技术可以参考公开号为US2010202369A1的美国专利申请。
发明内容
本发明解决的是现有技术中处理下行HARQ反馈时占用的***开销大、效率不高的问题。
为解决上述问题,本发明技术方案提供了一种LTE***中处理下行HARQ反馈的方法,包括:
对小区内通信终端设置各自对应的数据结构,所述数据结构包含n个指示数据,各指示数据包括的第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,所述第一数据为由比特组成的数,n为一个无线帧所包含子帧的个数;
当收到任一通信终端的HARQ反馈消息,则根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新。
可选的,所述第一数据指示的HARQ进程的进程号基于HARQ调度信息设置,所述HARQ调度信息包括调用HARQ进程传输数据时的子帧号以及调用的HARQ进程的进程号。
可选的,所述第一数据指示的HARQ进程的进程号基于HARQ调度信息设置包括:
在所述数据结构中查找与所述调用HARQ进程传输数据时的子帧号对应的指示数据;
使查找到的所述指示数据的第一数据的值等于所述调用的HARQ进程的进程号。
可选的,所述根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新包括:
基于接收所述HARQ反馈消息时的子帧号确定该HARQ反馈消息对应的传输数据时的子帧号;
在该通信终端的数据结构中查找与该HARQ反馈消息的传输数据时的子帧号对应的指示数据;
若所述HARQ反馈消息为成功应答,则将查找到的所述指示数据的第一数据的所有比特位重置,否则对该HARQ反馈消息对应的数据重新传输。
可选的,各指示数据还包括与各个第一数据对应的第二数据,分别用于指示调用HARQ进程传输数据的次数,所述第二数据为由比特组成的数;所述根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新还包括:当所述HARQ反馈消息为非成功应答时,将与查找到的所述指示数据的第一数据对应的第二数据的值加1。
可选的,所述LTE***中处理下行HARQ反馈的方法还包括:
若所述数据结构中任一指示数据包括的第二数据的值大于***允许的最大传输次数,则将该指示数据的所有比特位重置。
可选的,所述LTE***中处理下行HARQ反馈的方法还包括:
若在任一子帧调用HARQ进程传输数据时出现反馈超时,则对在该子帧调用HARQ进程传输的数据重新传输,并将所述指示数据中与该子帧相对应的第一数据对应的第二数据的值加1。
可选的,判断在任一子帧调用HARQ进程传输数据时出现反馈超时的步骤包括:
设置各子帧对应的超时定时器,所述超时定时器的超时门限基于各子帧的子帧号确定;
在任一子帧调用HARQ进程传输数据时,启动对应的超时定时器;
若所述超时定时器的计时长度等于对应的超时门限时仍未收到在该子帧调用HARQ进程传输数据的HARQ反馈消息,则判断在该子帧出现反馈超时。
可选的,判断在任一子帧调用HARQ进程传输数据时出现反馈超时的步骤包括:
若在任一子帧调用HARQ进程传输数据后在其对应的超时子帧处仍未接收到在该子帧调用HARQ进程传输数据的HARQ反馈消息,则判断在该子帧出现反馈超时,所述超时子帧的子帧号等于各子帧对应的接收HARQ反馈消息时的子帧号加超时门限,所述超时门限等于m个子帧长度,m∈[0,3]。
可选的,所述LTE***中处理下行HARQ反馈的方法还包括:
对小区内通信终端设置各自对应的第三数据和第四数据,所述第三数据用于指示空闲HARQ进程的进程号,所述第四数据用于指示待重传的HARQ进程的进程号,所述第三数据和第四数据为由比特组成的数;
在更新所述数据结构中相应的指示数据的比特位的同时对所述第三数据和第四数据进行设置。
可选的,所述在在更新所述数据结构中相应的指示数据的比特位的同时对所述第三数据和第四数据进行设置包括:
在与该通信终端对应的数据结构中查找与接收所述HARQ反馈消息时的子帧号对应的指示数据;
若收到HARQ反馈消息为成功应答,则将查找到的所述指示数据的第一数据指示的HARQ进程的进程号添加到所述第三数据的相应比特位;
若收到HARQ反馈消息为非成功应答,则将查找到的所述指示数据的第一数据指示的HARQ进程的进程号添加到所述第四数据的相应比特位。
可选的,所述第三数据和第四数据所包含的比特的位数基于所述LTE***支持的HARQ进程的数量确定。
可选的,所述LTE***为FDD-LTE***。
可选的,所述LTE***为TDD-LTE***且其下行最小HARQ重传间隔小于或者等于一个无线帧长度,基于所述TDD-LTE***的上下行配置确定所述TDD-LTE***支持的HARQ进程的数量。
为解决上述问题,本发明技术方案还提供一种LTE***中处理下行HARQ反馈的装置,包括:
存储单元,用于存储小区内通信终端各自对应的数据结构,所述数据结构包含n个指示数据,各指示数据包括的第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,所述第一数据为由比特组成的数,n为一个无线帧所包含子帧的个数;
第一更新单元,用于当收到任一通信终端的HARQ反馈消息时,根据所述HARQ反馈消息对所述存储单元中的该通信终端的数据结构中相应的指示数据的比特位进行更新。
为解决上述问题,本发明技术方案还提供一种基站,包括上述LTE***中处理下行HARQ反馈的装置。
与现有技术相比,本发明的技术方案具有以下优点:
由于所述数据结构中的各指示数据分别与各子帧相对应,就使得数据结构自带时间刻度,当接收到HARQ反馈消息后,就能根据接收到HARQ反馈消息时的子帧号快速确定对应的指示数据,以得到该HARQ反馈消息对应的传输数据时调用的HARQ进程的进程号,无需再进行对数组或者链表的查找过程,提高了处理速度,节省了***开销。并且,由于数据结构是由比特组成的数,就将现有技术中的对数组或链表的操作转换为对所述数据结构中指示数据的比特位的操作,进一步的使得LTE***的下行HARQ反馈的处理速度得到提高。
利用所述数据结构自带时间刻度的特点,当指示数据还包括由比特组成的第二数据时,在接收到HARQ反馈消息对指示数据的第一数据进行更新的同时,通过简单的比特级操作即可得到调用HARQ进程传输数据的次数,简化了传输次数达到***传输门限时的异常保护的过程,提高了处理效率。
利用所述数据结构自带时间刻度的特点,无需设置定时器,就能实现HARQ反馈的超时异常保护,进一步的节省了***资源,提高了下行HARQ反馈处理的效率。
当对各通信终端设置对应的由比特组成的第三数据和第四数据时,可以更加直观的反映出当前哪些HARQ进程是空闲的,哪些HARQ进程是待重传的,为***下一步的调度处理提供了便利。
附图说明
图1是LTE***中某一个通信终端调用HARQ进程进行下行数据传输的基本过程的示意图;
图2是TDD LTE***在各子帧调用HARQ进程进行下行数据传输时的时序示意图;
图3是本发明实施例一的LTE***中处理下行HARQ反馈的方法的流程示意图;
图4是本发明实施例一中的数据结构C的结构示意图;
图5是本发明实施例二的LTE***中处理下行HARQ反馈的方法的流程示意图;
图6是本发明实施例二中的数据结构D的结构示意图;
图7是本发明实施例三的LTE***中处理下行HARQ反馈的方法的流程示意图;
图8是本发明实施例四的LTE***中处理下行HARQ反馈的方法的流程示意图;
图9是本发明实施例五的LTE***中处理下行HARQ反馈的装置的结构示意图。
具体实施方式
如背景技术所述,LTE***下行采用异步自适应的HARQ机制,其中“异步”表示了采用不固定的重传时间间隔,即在大于最小重传间隔(RTT,Round Trip Time)的情况下,网络可以选择重传数据的发送时机;“自适应”表示了在数据重传的时候,可以根据链路自适应的情况,选择使用与首次传输时不相同的调制方式。对LTE小区内的某一个通信终端调用HARQ进程进行下行数据传输的基本过程如图1所示:
***调度在子帧i(向下的箭头表示该子帧为下行子帧)处调用HARQ进程进行下行数据传输,在子帧i+k(向上的箭头表示该子帧为上行子帧)处会接收到相应的HRAQ反馈消息。若该HARQ反馈消息为成功应答(ACK)时,表示本次下行传输的数据已被接收端(即通信终端)正确接收,则本次传输结束;若该HARQ反馈消息为非成功应答(NACK)时,表示本次下行传输的数据未被接收端成功接收,则需要进行重传。子帧j的位置即为该数据重传的位置,***将在子帧j+p的位置收到本次重传的HARQ反馈消息。依此类推,数据会被反复传输,直到发送成功为止。可见,单个HARQ进程是采用“停等”的机制,即一个下行数据的传输过程包括下行数据传输、上行HARQ反馈以及可能的重传,直至数据被通信终端正确接收。当然,考虑到实际情况,LTE***不会无休止的对一个数据进行反复的重传,当传输数据的次数达到***允许的最大传输次数时,会结束对该数据的重传,以便释放被占用的HARQ进程进行其他数据的传输。LTE的相关规范对***允许的最大传输次数为{1,2,3,4,5,6,7,8,9,10,12,16,20,24,28}中的任一值。具体实施时,可以根据***实际网络环境以及用户需求等来进行选择。
对于上述过程,现有技术中,采用数组或链表来存储空闲的HARQ进程(free HARQ)和繁忙的HARQ进程(busy HARQ),当LTE***接收到通信终端发送的HARQ反馈消息后,通过遍历查找busy HARQ数组或链表来决定下一步的操作:如果是ACK,则将查找到的busy HARQ进程从busy HARQ进程数组或链表中取出,放入free HARQ进程数组或链表中;如果是NACK,则进行重传。当小区内有大量的通信终端接入时,***需要处理的HARQ反馈消息会非常多,这时***会产生大量的查找开销,从而导致LTE***在进行下行HARQ反馈处理时效率不高,尤其是在接入的通信终端数量较多的时候显得尤为突出。另外,由于基站内部通讯异常等问题,还可能导致LTE调度***一直无法接收到HARQ反馈消息,还需要在每个子帧传输数据时设置一个定时器进行超时异常保护,当接入的通信终端数量较大时,也会占用大量的***资源。
针对上述问题,本发明实施方式提供了一种高效的LTE***中处理下行HARQ反馈的方法,通过对小区内的通信终端设置各自对应的、包含n个由比特组成的指示数据的数据结构,来指示各子帧传输数据时调用的HARQ进程的进程号。由于所述数据结构中的各指示数据与各子帧对应,就使得数据结构自带时间刻度,当接收到HARQ反馈消息后,可以根据接收HARQ反馈消息时的子帧号查找到对应的指示数,再根据HARQ反馈消息对该指示数进行比特级的更新操作。这样就将现有技术中对数组或链表的查找过程转换成了比特级的操作,使得LTE***用于查找的开销被大大减少,提高了下行HARQ反馈处理的效率。
为使本发明的上述目的、特征和优点能够更为明显易懂,下面结合附图对本发明的具体实施例做详细的说明。
首先,对LTE***的下行HARQ反馈处理中各环节的时序关系做一个简单的介绍:
(1)对频分双工(FDD,Frequency Division Duplexing)LTE***,图1中的k固定等于4,表示下行传输数据与上行HARQ反馈之间的时间间隔AN Timing固定的等于4个子帧,而j-i之间的差值固定等于8,表示下行传输数据与可能的数据重传之间的最小时间间隔RTTMIN固定等于8个子帧,具体的在每个下行子帧传输数据后接收HARQ反馈消息的时序以及HARQ重传时序可参考下表1。对应的,在FDD LTE***中,每个通信终端最多需要8个HARQ进程以支持下行数据的并行传输。例如,在第N个无线帧(下行)的子帧0的位置调用HARQ进程1进行下行数据初次传输,那么将在第N个无线帧(上行)的子帧4的位置接收到对应的HARQ反馈消息,若HARQ反馈消息为ACK,则本次传输结束,否则,最快可以在第N个无线帧(下行)的子帧8的位置对该数据进行重传。
表1
(2)对时分双工(TDD,Time Division Duplexing)LTE***,由于在时间资源上有上下行之间的分配,因此不同的上下行配置对应的时序关系也不同。具体的,不同的上下行子帧配置情况下的各子帧传输数据时对应的上行HARQ反馈之间的时间间隔AN TIMING值(即k的取值)、下行传输数据与可能的数据重传之间的最小时间间隔RTT MIN的值(即j与i的差值)的取值参见表2:
表2
以第一种配置(配置0)的TDD LTE***为例,共支持的HARQ进程的数量为4个,在各子帧调用HARQ进程进行下行数据传输的时序关系如图2所示,例如,在第N个无线帧的子帧0调用HARQ进程1进行下行数据传输,将在该无线帧的子帧4处收到对应的HARQ反馈消息,且当反馈消息为NACK时最快在第N+1个无线帧的子帧0的位置进行重传。从表2还可看出,对于TDD-LTE***来说,不同的上下行配置对应的进程数量也不同。
从上述分析可知,无论是FDD LTE***还是TDD LTE***,都可以根据接收HARQ反馈消息的位置,推算出发送与该HARQ反馈消息对应的数据的位置,以及当传输失败时可能的重传位置。因此,本发明技术方案对FDD LTE***和TDD LTE***均适用,但是需要说明的是,本发明技术方案所指的TDD LTE***为下行最小重传间隔(RTT MIN)小于或者等于LTE一个子帧长度的子帧位置。参照表2,即本发明技术方案适用于第一种上下行配置的TDDLTE***或者第二种上下行配置的TDD LTE***中除子帧5以外的其他子帧位置。
实施例一
如图3所示,为本实施例的LTE***中处理下行HARQ反馈的方法的流程示意图,包括:
步骤S100:对小区内通信终端设置各自对应的数据结构C,所述数据结构C包含n个指示数据,各指示数据包括的第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,所述第一数据为由比特组成的无符号数,n为一个无线帧所包含子帧的个数。目前LTE***中一个无线帧包含10个子帧,因此本实施例中n=10。如图4所示为本实施例的数据结构C的结构示意图,可以看出,所述数据结构C包含的10个指示数据分别为C0、C1、…、C9,其中各指示数据中包含由4个比特组成的第一数据(图中仅标示出指示数据C0的第一数据)。由于目前LTE***最多可支持15个HARQ进程,即对应的进程号为1~15,因此将第一数据中包含比特数确定为4,以表示这15个进程的进程号。若随着通信技术的发展,后续***可支持的HARQ进程个数发生变化时,第一数据包含的比特数进行相应的调整即可。相应的,各指示数所包含的第一数据的各比特位的初始值可以设置为1,若用十六进制表示即为0xFF。可以看出,通过数据结构中各指示数据的下标就可以将各指示数与传输数据时的子帧号对应起来,使得数据结构自带时间刻度。
LTE***在进行下行数据传输时,LTE***首先会进行HARQ调度,并发出HARQ调度信息,以指示LTE的物理层在哪个子帧、调用哪个HARQ进程进行数据的传输。也就是说,HARQ调度信息包括调用HARQ进程传输数据时的子帧号以及调用的HARQ进程的进程号。根据***发出的HARQ调度信息,会首先对数据结构中相应的指示数据中第一数据指示的HARQ进程号进行设置。具体的,根据HARQ调度信息对第一指示数据指示的HARQ进程的进程号进行设置的流程包括:首先,在所述数据结构中查找与所述调用HARQ进程传输数据时的子帧号对应的指示数据。由于调度信息中携带了传输数据时的子帧号,根据这个子帧号即可以在数据结构中找到对应的指示数据以及第一数据。以表2所示的第二种上下行配置的TDD LTE***为例,若***调度在第N个无线帧的子帧0调用HARQ进程1行数据传输,这时对应的指示数据就为C0,其中,C0通过其下标0与子帧0形成对应关系。然后,使查找到的所述指示数据的第一数据的值等于所述调用的HARQ进程的进程号。HARQ调度信息中包含的HARQ进程的进程号为1,就使C0的第一数据的4个比特位的值等于1,以表示在子帧0处调用了HARQ进程1进行了下行数据传输。
步骤S101:当收到任一通信终端的HARQ反馈消息,则根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新。首先,基于接收所述HARQ反馈消息时的子帧号确定该HARQ反馈消息对应的传输数据时的子帧号。参照表2,在第N个无线帧的子帧7收到的HARQ反馈消息,就能得到该HARQ反馈消息对应的传输数据时的子帧号为0或者1。然后,在该通信终端的数据结构中查找到与该HARQ反馈消息对应的传输数据时的子帧号对应的指示数。最后,根据HARQ反馈消息对该指示数据的第一数据进行更新:若HARQ反馈消息为ACK,则将查找到的指示数据的第一数据中所有比特位重置,否则,对该HARQ反馈消息对应的传输数据进行重传。例如,若在第N个无线帧的子帧7收到的HARQ反馈消息为ACK,就直接对C0重置,使其第一数据的比特位的值恢复初始值,全部为1,若用十六进制表示即为0xFF;若在第N个无线帧的子帧7收到的HARQ反馈消息为NACK,相应的第二指示数据加1,如果更新后的第二指示数据小于或等于最大传输次数,HARQ进程的进程号添加到所述第四数据的相应比特位;如果更新后的第二指示数据大于最大传输次数,释放该HARQ进程。
至此,在第N个无线帧的子帧0的一次下行数据传输过程就结束了,从表2可知,当本次数据传输不成功时,第一次的重传最快可以在第N+1个无线帧的子帧1的位置进行。
可以看出,各通信终端的数据结构通过其下标与各子帧建立一一对应的关系,使得数据结构本身带有时间刻度,可以根据接收HARQ反馈消息时的子帧号和***在下行传输数据时各环节之间的时序关系,直接找到对应的由比特组成的指示数据。然后,根据HARQ反馈消息的具体结果,直接对找到的指示数据中的第一数据的各比特位进行操作,释放传输成功的数据对应的HARQ进程,或者对传输失败的数据进行重传。这样就使得在LTE***进行下行HARQ反馈处理的过程中,跳过了对数组或链表的查找过程,为***节省了开销,提高了处理效率。另外,还将对数组或链表的操作转换成对所述数据结构的比特级的操作,简化了处理流程,进一步提高了处理效率。
实施例二
如图5所示,为本发明实施例二的LTE***中处理下行HARQ反馈的方法的流程示意图,包括:
步骤S200:对小区内通信终端设置各自对应的数据结构D,所述数据结构D包含n个指示数据,各指示数据包括第一数据和与其对应的第二数据,第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,第二数据用于指示调用HARQ进程传输数据的次数,所述第一数据和第二数据为由比特组成的数,n为一个无线帧所包含子帧的个数。本步骤的具体实施可参考实施例一的步骤S100,不同的是,本实施例中的指示数据还增加了用于指示调用HARQ进程传输数据的次数的第二数据。如图6所示,为数据结构D的示意图,所述数据结构D包含的10个指示数据分别为D0、D1、…、D9,每个指示数据都包含有第一数据和第二数据(图中仅标示出D0的第一数据和第二数据),且第一数据和第二数据均为由4个比特组成的无符号数,其中第二数据包含的比特数可以根据LTE***设置的最大传输次数来确定。例如,LTE***的最大传输次数为4时,可以将第二数据设置为包含4个比特,且各比特位的初始值设置为0,表示传输次数为0。由于第二数据的值用于指示调用HARQ进程传输数据的次数,因此在收到HARQ调度信息进行首次数据传输时,应根据HARQ调度信息,将其中包括的调用HARQ进程传输数据时的子帧号所对应的第一数据对应的第二数据的值初始化为1。
步骤S201:当收到任一通信终端的HARQ反馈消息,则根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新。本步骤的具体实施,可参考实施例一中的步骤S101。不同的是,在对指示数据中的第一数据的比特位进行更新的同时,还要对第二数据的比特位进行相应的更新。具体的,当HARQ反馈消息为非成功应答时,将与查找到的所述指示数据的第一数据对应的第二数据的值加1。例如,在第N个无线帧的子帧7收到了HARQ反馈消息,若接收到的HARQ反馈消息为NACK时,那么就要对第N个无线帧的子帧0处传输的数据进行重传,同时对C0的第二数据的比特位的值加1,表示在第N个帧的子帧0传输的数据需要一次重传。若这次重传仍然失败,则C0的第二数据的比特位的值再加1。
步骤S202:判断所述数据结构中任一指示数据包括的第二数据的值是否大于***允许的最大传输次数。前面已经提到,***为了避免无休止对数据进行重传,会设定一个最大传输次数,一旦传输数据的次数大于***允许的最大传输次数,则应该释放本次传输所调用的HARQ进程,为传输其他的数据预留资源。
若步骤S202的判断结果为是,则表示传输次数已经达到了***设定的最大传输次数,这时执行步骤S203:将该指示数据的所有比特位重置。例如,当D0=[00010101]时,其对应的第二数据的值等于5,就表示在第N个帧的子帧0首次传输的数据已经经过了4次的传输但仍未传输成功,需要调度第5次的传输。可以看出,第二数据的值减去1就是数据实际被传输的次数,因此,一旦检测到第二数据的值大于***设定的最大传输次数,就说明对数据的传输已经达到了***设定的最大传输次数,这时应当将该指示数据所有的比特位重置,以表示将传输该数据调用的HARQ进程释放掉,为传输其他数据预留资源。例如,当第二数据的值等于5,而***设定的最大传输次数为4时,就应当将D0的所有比特位重置,使D0的所有比特位的值恢复初始值。在其他实施例中,第二数据也可以用于指示调用HARQ进程进行重传的次数,这时在首次传输时就应使第二数据为初始值,即使第二数据的值为0。这时步骤S202的判断条件可以设置为:所述数据结构中任一指示数据包括的第二数据的值是否等于***允许的最大传输次数。
若步骤S202的判断结果为否,则表示传输次数还未达到***设定的最大传输次数,这时返回步骤S201,继续处理该传输数据对应的HARQ反馈消息。
至此,LTE***的一次HARQ下行反馈处理过程就完成了。
可以看出,本实施例的LTE***处理下行HARQ反馈的方法,由于所述数据结构自带时间刻度,使得在处理过程中省略了对数组或者链表的查找过程,节省了***开销,提高了处理速度。另外,比特级的操作也是的处理流程得到了简化,进一步节省了***资源。
进一步的,由于指示数据中还包含了用于指示HARQ进程传输数据的次数的比特位,因此在判断调用HARQ进程传输数据时是否达到了***允许的最大传输次数时,可以直接对由比特组成的数据结构进行查找,而不必对存储busy HARQ进程的数组或者链表进行查找,简化了传输次数达到***允许的最大传输次数时的异常保护流程,提高了处理的效率。
实施例三
如图7所示,为本发明实施例三的LTE***中处理下行HARQ反馈的方法的流程示意图,包括:
步骤S300:对小区内通信终端设置各自对应的数据结构C。所述数据结构C包含n个指示数据,各指示数据包括的第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,所述第一数据为由比特组成的无符号数,n为一个无线帧所包含子帧的个数。
步骤S301:当收到任一通信终端的HARQ反馈消息,则根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新。
步骤S300和步骤S301的具体实施可参考实施例一中的步骤S100和步骤S101,此处不再赘述。
步骤S302:判断是否有任一子帧调用HARQ进程传输数据时出现反馈超时。前面已经提到,由于基站内部通信异常等问题,可能出现LTE***一直无法接收到HARQ反馈消息的情况,因此在每个子帧传输数据时还需要进行接收超时的异常保护。考虑到LTE***在进行下行HARQ反馈处理的过程中,各个环节之间有相对固定的时序关系,因此从调用HARQ进程进行数据传输的子帧号,可以确定相应的接收HARQ反馈消息的子帧号。若在确定的子帧号之后延迟一段时间仍未接收到该数据的HARQ反馈消息,那么就认为物理层传输异常了,这时应该通过相应的超时异常保护功能,避免***停滞在等待接收HARQ反馈消息的状态。
具体的:首先,确定任一子帧调用HARQ进程传输数据时对应的超时子帧的子帧号。通常,任一子帧调用HARQ进程传输数据对应的接收HARQ反馈消息时的子帧号加超时门限,就是超时子帧的子帧号。其中超时门限可以为m个子帧的长度。m的取值范围为[0,3],具体的取值,可以根据***的要求来设定,本实施例不做具体限定。根据m的取值,就可以确定某一子帧对应的超时子帧。然后,若在某一子帧对应的超时子帧处是否仍未接收到该子帧对应的HARQ反馈消息,则可以判断该子帧出现了反馈超时。
若步骤S302的判断结果为是,则执行步骤S303:对在该子帧调用HARQ进程传输的数据重新传输,并将所述指示数据中与该子帧相对应的第一数据对应的第二数据的值加1。与接收到非成功响应的HARQ反馈消息类似的,这时需要对数据进行重新重传;若步骤S302的判断结果为否,则返回步骤S301。
本实施例的LTE***中处理下行HARQ反馈的方法,能够根据HARQ反馈消息,利用所述数据结构自带时间刻度的特点,直接在数据结构中查找对应的指示数,并对指示数进行比特级的操作,能够更加快速、高效的实现下行HARQ反馈的处理。另外,利用数据结构自带时间刻度的特点,无需对各子帧设置超时定时器,就能快速的确定在哪些子帧出现了反馈超时,以便***能做出快速响应,并启动重传。
需要说明的是,在***的处理能力和资源相对较多的情况下,也可以通过设置超时定时器的方式,来实现超时异常保护。具体的:首先,设置各子帧对应的超时定时器,所述超时定时器的超时门限基于各子帧的子帧号确定。各子帧对应的超时定时器的时长的确定可参照上述超时子帧的确定过程。当超时定时器的计时长度大于或者等于对应的超时门限时仍未收到在该子帧调用HARQ进程传输数据的HARQ反馈消息,则判断在该子帧出现反馈超时。由于在下行HARQ反馈处理的过程中,仍是对数据结构的比特级操作,因此在进行下行HARQ反馈处理时仍具有快速、高效的优点。
实施例四
如图8所示,为本发明实施例四的LTE***中处理下行HARQ反馈的方法的流程示意图,包括:
步骤S400:对小区内通信终端设置各自对应的数据结构C、第三数据和第四数据,其中,所述数据结构C包含n个指示数据,各指示数据包括的第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,所述第一数据为由比特组成的无符号数,n为一个无线帧所包含子帧的个数,所述第三数据用于指示空闲HARQ进程的进程号,所述第四数据用于指示待重传的HARQ进程的进程号,所述第三数据和第四数据为由比特组成的数。
LTE***在进行传输数据调度时,通常会在free HARQ进程选择,在现有技术中,就是通过查找free HARQ数组或链表来进行的,从前面的分析可知,对数组或者链表的查找会占用很多***资源。通过在数据结构C可以确定已经调用的HARQ进程的进程号是哪些,再结合***支持的HARQ进程的进程号,就可知到***当前free HARQ进程的进程号。例如,C中的指示数据C0和C7的第一数据不等于初始值,然后取C0和C7对应的第一数据的比特位的值,就可以知道当前***已经调用的HARQ进程的进程号,如C0的第一数据的值等于1,C7的第一数据的值等于4,若此时***支持的HARQ进程的进程号为1~7,那么free HARQ进程的进程号就为1,2,3,4,5,6,7。为了使LTE***在进行传输数据调度时,能够更加直观、快速的获得当前***free HARQ进程的进程号,在本实施例中,在对小区内任一通信终端设置数据结构的同时,还设置相应的第三数据,用于指示free HARQ进程的进程号,其所包含的比特数与***支持的HARQ进程的数量有关。例如,当***支持7个HARQ进程时,第三数据就可以设置为包含有28(4乘以7)个比特的无符号数,从低位到高位每4个比特的值用来指示一个freeHARQ进程的ID。***在初始状态时,所有的HARQ进程都是空闲的,因此,第三数据的初始值应包含所有的HARQ进程的进程号,仍以支持7个HARQ进程的***为例,第三数据的初始值应等于[0111 0110 0101 0100 0011 0010 0001]。当LTE***收到HARQ调度信息后,就可以将HARQ调度信息中携带的HARQ进程的进程号从第三数据中去掉,以表示该HARQ进程已不是free的状态。具体的,若接收到的HARQ调度信息中指示在第N个无线帧的子帧0处调用HARQ进程1来传输数据,这时就可以将第三数据中的低4个比特取出,然后其他比特位右移四位,第三数据就变为[1111 0111 0110 0101 0100 0011 0010],可以看出,这时第三数据中包含的HARQ进程的进程号就变为2~7,最高的4为比特位初始值,不指示任何HARQ进程的进程号。当然,也可以通过本领域常用的其他方法使得第三数据中不包含HARQ调度信息中指示的调用的HARQ进程的进程号。
同理,为了更加直观的反映出待重传的HARQ进程的进程号,在本实施例中,在对小区内任一通信终端设置数据结构的同时,还设置相应的第四数据,用于指示待重传的HARQ进程的进程号,其所包含的比特数与***支持的HARQ进程的数量有关。例如,与第三数据类似,当***支持7个HARQ进程时,第四数据就可以设置为包含有28(4乘以7)个比特的无符号数,从低位到高位每4个比特的值用来指示一个重传HARQ进程的进程号。***在初始状态时,所有的HARQ进程都是空闲的,因此,第四数据的初始值不包含任一HARQ进程的进程号,在本实施例中第四数据的初始值可以设置为等于[1111 1111 1111 1111 1111 11111111],表示初始状态时没有任何待重传的HARQ进程。
对数据结构C的设置则可以参考实施例一,此处不再赘述。
步骤S401:当收到任一通信终端的HARQ反馈消息,则根据所述HARQ反馈消息对该通信终端的数据结构中相应的指示数据的比特位进行更新,同时对第三数据和第四数据进行设置。
对数据结构中相应的比指示数据的比特位的更新,可参考实施例一,这里说明一下对第三数据和第四数据的设置过程。具体的,首先在数据结构中查找与接收所述HARQ反馈消息时的子帧号对应的指示数据,然后根据HARQ反馈消息的类型对第三数据和第四数据进行设置:若收到的HARQ反馈消息为成功应答,则将查找到的指示数据的第一数据指示的HARQ进程的进程号添加到第三数据的相应比特位;若收到HARQ反馈消息为非成功应答,则将查找到的所述指示数据的第一数据指示的HARQ进程的进程号添加到所述第四数据的相应比特位。也就是说,当传输数据成功时,就将传输数据时调用的HARQ进程释放掉,并放入指示free HARQ进程的第三数据中;当传输数据不成功时,则需要对该数据进行重传,这时就将待重传数据调用的HARQ进程的进程号添加到第四数据中,等待重传。可以理解的,若该重传数据被重新调度并重传后,则应将调用的HARQ进程的进程号从第四数据中去除。仍参考步骤S400中的例子,当在第N个无线帧的子帧0调用HARQ进程1传输数据时对应的HARQ反馈消息为ACK时,读取C0中第一数据的比特位的值,并将其添加到第三数据中,如,用指示HARQ进程1的四个比特位覆盖C0中全1的四个比特位,第三数据就变为[0001 0111 01100101 0100 0011 0010],其中包含的HARQ进程的进程号为1~7;当在第N个无线帧的子帧0调用HARQ进程1传输数据时对应的HARQ反馈消息为NACK时,就在第四数据中添加HARQ进程1对应的进程号,这时第四数据就应为[0001 1111 1111 1111 1111 1111 1111](假设此时没有其他待重传数据),表示此时调用HARQ进程1的数据在等待重传。
本实施例的LTE***中处理下行HARQ反馈的方法,能够根据HARQ反馈消息,直接在数据结构中查找对应的指示数,并对指示数进行比特级的操作,能够更加快速、高效的实现下行HARQ反馈的处理。另外,在本实施例中,设置了用于指示空闲HARQ进程的第三数据和用于指示待重传HARQ进程的第四数据,能够更加直观的反映出***等待重传的数据所调用的HRAQ进程的进程号以及空闲HARQ进程的进程号,使得***的调度、以及重传处理更加的简单快捷。
可以理解的,本领域的技术人员可以将上述实施例一至实施例四所描述LTE***中处理下行HARQ反馈的方法进行合理结合,以满足***不同的处理需求。
实施例五
本实施例提供了一种LTE***中处理下行HARQ反馈的装置,如图9所示,包括:存储单元U10、第一更新单元U20、第一设置单元U30、重传单元U40、第二更新单元U50、第三更新单元U60、第二设置单元U70和反馈消息接收单元U80。其中,存储单元U10,用于存储小区内通信终端各自对应的数据结构,所述数据结构包含n个指示数据,各指示数据包括的第一数据用于指示各子帧传输数据时调用的HARQ进程的进程号,所述第一数据为由比特组成的数,n为一个无线帧所包含子帧的个数;第一更新单元U20,用于当收到任一通信终端的HARQ反馈消息时,根据所述HARQ反馈消息对所述存储单元U10中的该通信终端的数据结构中相应的指示数据的比特位进行更新;第一设置单元U30,用于基于HARQ调度信息对所述第一数据指示的HARQ进程的进程号进行设置,所述HARQ调度信息包括调用HARQ进程传输数据时的子帧号以及调用的HARQ进程的进程号;重传单元U40,用于当所述HARQ反馈消息为非成功应答时,对该HARQ反馈消息对应的数据重新传输;第二更新单元U50,用于当所述存储单元U10的数据结构中任一指示数据包括的第二数据的值大于***允许的最大传输次数时,将该指示数据的所有比特位重置;第三更新单元U60,对在该子帧调用HARQ进程传输的数据重新传输,并将所述存储单元U10存储的数据结构的指示数据中与该子帧相对应的第一数据对应的第二数据的值加1;第二设置单元U70,用于在所述第一更新单元U20更新所述数据结构中相应的指示数据的比特位的同时对所述第三数据和第四数据进行设置;反馈消息接收单元U80用于接收所述HARQ反馈消息。
其中,所述第一更新单元U20包括:确定单元U201,用于基于接收所述HARQ反馈消息时的子帧号确定该HARQ反馈消息对应的传输数据时的子帧号;第二查找单元U202,用于在所述存储单元U10中的该通信终端的数据结构中查找与该HARQ反馈消息对应的传输数据时的子帧号对应的指示数据;第一更新子单元U203,用于当所述HARQ反馈消息为成功应答时,将所述第二查找单元U202查找到的所述指示数据的第一数据的所有比特位重置。在本实施例中,所述存储单元U10中还存储的各指示数据还包括与各个第一数据对应的第二数据,分别用于指示调用HARQ进程传输数据的次数,所述第二数据为由比特组成的数,因此所述第一更新单元还包括第二更新子单元U204,用于当所述HARQ反馈消息为非成功应答时,将与所述第二查找单元U202查找到的所述指示数据的第一数据对应的第二数据的值加1。
所述第一设置单元U30包括:第一查找单元U301,用于在所述数据结构中查找与所述调用HARQ进程传输数据时的子帧号对应的指示数据;赋值单元U302,用于使所述第一查找单元U301查找到的所述指示数据的第一数据的值等于所述调用的HARQ进程的进程号。
本实施例中的LTE***可以为FDD-LTE***,也可以是TDD-LTE***且其下行最小HARQ重传间隔小于或者等于一个无线帧长度。
对应的,本实施例还提供一种基站,包括上述LTE***中处理下行HARQ反馈的装置。
本实施例的LTE***中处理下行HARQ反馈的装置的具体实施可参考实施例一至实施例四,此处不再赘述。
本领域技术人员可以理解,实现上述技术方案的全部或部分是可以通过程序来指令相关的硬件来完成,所述的程序可以存储于可读存储介质中,所述存储介质可以是ROM、RAM、磁碟、光盘等。
虽然本发明披露如上,但本发明并非限定于此。任何本领域技术人员,在不脱离本发明的精神和范围内,均可作各种更动与修改,因此本发明的保护范围应当以权利要求所限定的范围为准。