CN103378953A - 混合自动重传请求方法与装置 - Google Patents
混合自动重传请求方法与装置 Download PDFInfo
- Publication number
- CN103378953A CN103378953A CN2012101138166A CN201210113816A CN103378953A CN 103378953 A CN103378953 A CN 103378953A CN 2012101138166 A CN2012101138166 A CN 2012101138166A CN 201210113816 A CN201210113816 A CN 201210113816A CN 103378953 A CN103378953 A CN 103378953A
- Authority
- CN
- China
- Prior art keywords
- harq
- data
- harq process
- indication message
- harq processes
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
一种混合自动重传请求方法与装置,所述方法通过至少两个HARQ进程来发送相同的数据,增加了反馈ACK信息的概率,且无论哪个HARQ进程上反馈ACK信息,就等同于其它HARQ进程也反馈了ACK信息,从而提前结束其它HARQ进程。整体来看,反馈ACK信息的概率增加,且基于其中一个HARQ进程的ACK反馈,其它进程可以提前结束,因此HARQ的时延得以降低。应用该方法的通信装置、终端、基站或系统也可以有效的降低HARQ的传输时延。
Description
技术领域
本发明涉及通信技术领域,特别是涉及一种混合自动重传请求(HybridAutomatic Repeat-reQuest,HARQ)方法与装置。
背景技术
HARQ是一种结合了前向纠错(Forward Error Correction,FEC)和自动重复请求(Automatic Repeat-reQuest,ARQ)技术的差错控制技术。FEC部分用来纠正信道中经常出现的错误以减少重传次数而提高系统的效率;ARQ部分用来纠正那些不常出现的、FEC不能纠正的错误,以提高系统的可靠性。
HARQ技术采用了停止-等待(Stop-And-Wait,SAW)的ARQ机制,这种机制下,发端必须在发送下一个数据分组前等待上一个数据分组的确认信息。在等待期间,信道闲置,导致系统资源的浪费。为此,出现了N信道停止-等待HARQ技术,通过设置并行停止-等待协议的信道数N来提高系统资源的利用率,例如,一个连续的传输流在时间上分为N个子信道,即N个HARQ进程(HARQ process),而每个进程独立地执行停止-等待重传协议,其中N为正整数。
HARQ技术由于采用了SAW机制,无可避免增加了传输时延,为此,如何有效的降低传输时延一直是HARQ技术的重要问题。
发明内容
本发明实施例提供了HARQ方法与装置,以降低HARQ的传输时延。
一方面,本发明实施例提供一种混合自动重传请求HARQ方法,包括:发射端通过至少两个HARQ进程发送相同的数据;所述发射端接收所述数据的反馈,且接收到肯定确认ACK反馈时,确定所述数据发送成功。
另一方面,本发明实施例提供一种通信装置,包括:发送单元,用于通过至少两个HARQ进程发送相同的数据;接收单元,用于接收所述数据的反馈;处理单元,当所述接收单元接收到所述数据的肯定确认ACK反馈时,用于确定所述数据发送成功。
可见,以上方法通过至少两个HARQ进程来发送相同的数据,增加了反馈ACK信息的概率,且无论哪个HARQ进程上反馈ACK信息,就等同于其它HARQ进程也反馈了ACK信息,从而提前结束其它HARQ进程。整体来看,反馈ACK信息的概率增加,且基于其中一个HARQ进程的ACK反馈,其它进程可以提前结束,因此HARQ的时延得以降低。则应用该方法的通信装置、终端、基站或系统也可以有效的降低HARQ的传输时延。
附图说明
图1为本发明实施例所提供的HARQ方法的流程示意图;
图2为一种现有的N信道停止-等待HARQ技术的原理示意图;
图3为另一种现有的N信道停止-等待HARQ技术的原理示意图;
图4为本发明实施例所提供的一种HARQ方法的信号流图;
图5为本发明实施例所提供的一种HARQ缓存调度流图;
图6为本发明实施例所提供的另一种HARQ方法的信号流图;
图7为本发明实施例所提供的另一种HARQ缓存调度流图;
图8为一种TDD帧结构示意图;
图9为另一种TDD帧结构示意图;
图10为本发明实施例所提供的另一种HARQ方法的流程示意图;
图11为本发明实施例所提供的一种通信装置的结构框图;
图12为本发明实施例所提供的另一种通信装置的结构框图;
图13为本发明实施例所提供的又一种通信装置的结构框图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本发明的一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
请参考图1,其为本发明一实施例所提供的一种HARQ方法的流程示意图。该方法的执行主体为发射端,当然该发射端可以位于网络侧,也可以位于终端侧。如图1所示,该方法包括:
S110:通过至少两个HARQ进程发送相同的数据;
S120:接收所述数据的反馈,且接收到肯定确认ACK反馈时,确定所述数据发送成功。
以上相同的数据是指传输数据块(Transport Block,TB),且每个HARQ进程上传输的TB所携带的数据相同,但冗余版本(Redundancy Version,RV)等冗余信息可以不同,也可以相同,本实施例不做任何限制。
以上方法通过至少两个HARQ进程来发送相同的数据,来增加反馈ACK信息的概率,且无论哪个HARQ进程上反馈ACK信息,就等同于其它HARQ进程也反馈了ACK信息,从而提前结束其它HARQ进程。整体来看,反馈ACK信息的概率增加,且基于其中一个HARQ进程的ACK反馈,其它进程可以提前结束,因此HARQ的时延得以降低。
以上方法可以适用于对通信时延要求高的通信系统,根据本发明的方法,可以满足对于通信时延的高要求。例如,在物联网(Internet of Things,IOT)的基于蜂窝无线通信的智能电网输配电系统中,因为智能电网中的配电网设备对于通信的时延有着非常高的要求,对于单向的端到端时延要求为99.5%的成功率下为100ms以内,99.7%的成功率下为200ms以内,99.8%的成功率下为400ms以内。根据本发明实施例提供的方法,可以有效满足物联网领域中对于时延要求较高的系统的需求。
请参考表1与表2,其进一步体现了以上方法对HARQ时延的降低效果优于现有技术。为使表1和表2便于理解,下面介绍两种现有的N信道停止-等待HARQ技术,分别为无线链路控制分段(Radio Link Controlsegmentation,RLC segmentation)技术和传输时间间隔绑定(TransmissionTime Interval bundling,TTI bundling)技术,分别如图2和图3所示。
如图2所示,第一种:RLC segmentation技术。
为了减少每个HARQ进程的重传次数,根据反馈的信道质量信息,按照误码率要求计算HARQ进程可以传输的比特数,将数据包拆成多个小数据包分别在多个HARQ进程中传输,等到收端全部正确接收后再进行合并重组为原始数据包。
在此以可以并行运行8个HARQ进程,且将一个业务数据单元(ServiceData Unit,SDU)110拆分成4个分组数据单元(Packet Data Unit,PDU)120为例进行说明。图1中第一排数字代表传输时间间隔序号(TTI#),第二排数字代表HARQ进程序号(HARQ#)。
首先,将一个RLC业务数据单元(Service Data Unit,SDU)110拆分成多个RLC分组数据单元(Packet Data Unit,PDU)120,而后将RLC PDU120通过传输信道映射到物理层,以TB130的形式分别在多个HARQ进程中传输。考虑到处理时延和传输时延的影响,TB发送出去后,通常在四个TTI后反馈确认信息,如果反馈ACK信息,在第八个TTI开始发送下一个TB;如果反馈否定确认(NACK)信息,则在第八个TTI开始进行重传。图1中序号为“0”的HARQ进程在序号为“0”的TTI发送TB1,在序号为“4”的TTI反馈NACK,在序号为“8”的TTI重传TB1,其它TB的发送类似,在此不再赘述。
如图3所示,第二种:TTI bundling技术。
在连续的TTI内将相同的TB分配给同一HARQ进程进行发送,只对最后发送的TB才进行反馈,以降低初传误块率(Block Error Ratio,BLER),从而降低重传次数。
在此同样以可以并行运行8个HARQ进程为例进行说明。其与第一种方式不同之处在于:无需再对SDU进行拆分,每个SDU210对应一个PDU220,且对应一个TB230;每个TB对应多个物理资源块(PhysicalResource Block,PRB)(例如,4个),且将这些PRB分配给同一HARQ进程(图中序号为“0”的HARQ进程),分别在多个连续TTI(图中序号为“0”至“3”的TTI)进行发送,且仅对最后一个PRB进行反馈。从图3中可以看出,这种机制,仍然存在未使用的HARQ进程(如图2中序号为“0”至“3”的HARQ进程)。
表1列出了图2和图3所示的两种方法以及图1所示实施例的方法在FDD系统下的时延和开销比较;表2列出了图2和图3所示的两种方法以及图1所示实施例的方法在TDD系统上行配置1(config 1)的情况下的时延和开销比较。表1和表2中,单进程所对应的行示出了RLC segmentation技术下的时延和开销;TTI bundling所对应的行示出了TTI bundling技术下的时延和开销;相邻双进程和相邻三进程所对应的行示出了图1所示的方法分别利用两个HARQ进程和三个HARQ进程发送相同的数据下的时延和开销。其中,第一个数字代表传输时延,第二个数字代表占用HARQ进程的累计数(包括序号相同或不同HARQ进程的累计),括号中的数字代表第几次反馈是ACK。例如,表1中的单进程所对应行的第一个单元格内的括号中的数字“1”代表初传反馈即为ACK,数字“5”代表初传时延为5个TTI,括号外的数字“1”代表初传占用1个HARQ进程;第二个单元格内的括号内的数字“2”代表第二次反馈为ACK,数字13代表第二次反馈为ACK时的传输时延为13个TTI,括号外的数字2代表占用2个HARQ进程。
表1
表2
结合图2和表1,在FDD系统下,对于每一个TB,初传调用1个HARQ进程,如果初传反馈即为ACK,则每个TB的传输将耗时5个TTI。以TB1为例,其在序号为“0”的TTI进行初传,在序号为“4”的TTI进行初传反馈,传输时延为5个TTI。若反馈为NACK,且每增加一次NACK的反馈,传输时延将增加8个TTI。
结合图3和表1,在FDD系统下,对于每个TB,由于在连续4个TTI内调用同一HARQ进程,为此存在未使用的HARQ进程(例如序号为“1”至“3”的HARQ进程),故虽然使用了一个HARQ进程,但实际上相当于占用了4个HARQ进程。若初传反馈为ACK,则传输时延为8个TTI(例如,在序号为“0”的TTI进行初传,在序号为“7”的TTI进行反馈)。若反馈为NACK,且每增加一次NACK的反馈,传输时延将增加16个TTI。
而图1所示实施例,无论是利用相邻双进程还是相邻三进程发送相同的TB,对于每一个TB,初传均调用1个HARQ进程,如果初传反馈即为ACK,则每个TB的传输将耗时5个TTI。但由于双进程通过一次冗余传送增加了反馈ACK的概率,故若传送反馈为NACK,且每增加两次NACK的反馈,传输时延才增加8个TTI。同样,由于三进程通过两次冗余传送增加了反馈ACK的概率,故若传送反馈为NACK,且每增加三次NACK的反馈,传输时延才增加8个TTI。
从以上分析可以看出,图1所示实施例的方法,在双进程的情况下,每增加两次NACK的反馈,传输时延才增加8个TTI(其中N为正整数);在三进程的情况下,每增加三次NACK的反馈,传输时延才增加8个TTI。而图2所示的方法每增加一次NACK的反馈,传输时延就增加8个TT1。图3所示的方法每增加一次NACK的反馈,传输时延就增加16个TT1。可见,相对于图2和图3所示的方法,本发明实施例所提供的方法使传输时延得到了显著的降低,尤其是在收到NACK反馈的次数越多时,本发明实施例所提供的方法的优点越是显著。
关于传送时延的分析,TDD系统下的分析与FDD系统下的分析类似,在此不再赘述。
需要说明的是,可以并行运行的HARQ进程的数量小于或等于RRT内的TTI数量,因此以上用于发送相同的数据的HARQ进程的数量小于或等于RTT内的TTI数量,且在RTT内通过所述至少两个HARQ进程发送相同的数据。
在以上方法的步骤S110中,所述至少两个HARQ进程可以在连续的TTI内发送相同的数据,也可以在非连续的TTI内发送相同的数据。下面分别对这两种情况描述如下:
在非连续的TTI内发送数据:
在以上步骤S110中,所述至少两个HARQ进程中的相邻HARQ进程发送相同的数据的时间间隔至少为4个TTI,即下一个HARQ进程在上一个HARQ进程发送数据之后的第4个TTI或第4个TTI之后发送数据。
请参考图4,由于FDD系统中上下行原理一致,故此处以终端通过物理上行共享信道(Physical Uplink Shared CHannel,PUSCH)向基站发送数据为例,对于下行信道上数据的发送将不再赘述。从图4可以看出,在本例中,分配了两个进程(process),分别为process1和process2发送相同的数据,且process2在process1发送数据之后的第4个TTI(即基站反馈确认消息时,亦即半个RTT时)发送数据,相对于process2在process1发送数据之后的第5个TTI、第6个TTI等发送数据的情况,传输时延更小,但本实施例对此不做任何限制。
由于process1和process2的第一次数据发送的反馈均为NACK,故process1进行了第二次数据发送,且process1的第二次数据发送的反馈为ACK,当终端收到该ACK反馈时,即认为该数据发送成功,故不再对process2进行第二次数据发送的反馈做出处理。且采用这种方式时,若传输次数为N(其中N为正整数,且包括初传),则传输时延为ceil(N/2)RRT,其中ceil()表示向上取整。
在本发明实施例中,传输间隔至少为4个TTI的设定可以兼容现有HARQ缓存调度机制。请参考图5,其示出了一种HARQ缓存调度流程。HARQ缓存调度机制是:第一次传输的数据经解码得到的第一软比特信息经循环冗余校验(Cyclic Redundancy Check,CRC)证明错误之后,反馈NACK,通知进行重传;重传数据经解码后得到第二软比特信息,需先与第一软比特信息合并再进行CRC校验(如步骤2和3所示)。这个过程对应到HARQ时序上即为4个TTI之后。
图4所示的方法可以在不改变图5所示的缓存调度顺序时保证合并时延的要求。如图5所示,process1发送的数据经天线逆映射、资源逆映射、解调、解码后得到第一软比特信息。缓存第一软比特信息(步骤1),以便与后续process2发送的数据的软比特信息进行合并。对第一软比特信息进行CRC校验(步骤2),并根据校验结果反馈ACK或NACK。在现有技术中,反馈了NACK后,才进行数据的第二次发送。而本实施例,并不等待反馈结果,而是在4个TTI或之后,process2对相同数据进行第二次发送。process1发送的数据经天线逆映射、资源逆映射、解调、解码后得到第二软比特信息。将第一软比特信息和第二软比特信息进行合并(步骤3),并对合并的软比特信息进行CRC校验(步骤4),并根据校验结果反馈ACK或NACK,以判断是否进行重传。
可见,在不改变现有HARQ缓存调度顺序的情况下,为了保证process2的软比特信息能够正确和process1的软比特信息进行合并,需要在完成process1的软比特信息CRC校验之后,调度process1的软比特信息并与process2的软比特信息进行合并,对应到HARQ时序上即为4个TTI之后。因此,process2在process1发送数据后的4个TTI或之后发送数据,每个process的RTT依然为8ms。
考虑到本实施例中,用于发送相同数据的HARQ进程之间的数据发送并不需要等待之前数据发送结果的反馈,因此,可以改变以上HARQ缓存调度顺序,允许后面的HARQ进程在上一HARQ进程的CRC之前调度缓存中的软比特信息并进行合并(如图7所示,相对于图5,其步骤2和步骤3顺序对调),使得相邻HARQ进程快速合并。
此时,在以上方法的步骤S110中,所述至少两个HARQ进程可以分别在连续的TTI内发送相同的数据。
同样以终端通过PUSCH向基站传递数据为例。如图6所示,分配两个以上HARQ进程process1,process2,process3...发送相同的数据。当HARQ进程process3上的反馈为ACK时,即视为该数据发送成功,故不再对后面发送的数据的反馈做出处理。且当终端收到该ACK反馈时,即结束该数据的发送。
以上两种情况虽然均以FDD系统为例进行说明,但其也适用于TDD系统。由于TDD系统的帧结构与FDD系统的帧结构不同,下面对以上方法在TDD系统的应用做一个简单说明。
FDD帧结构包括多个子帧,每个子帧均用于下行传输或上行传输;而TDD帧结构包括用于上行传输的上行子帧U、用于下行传输的下行子帧D,以及为上下行之间提供保护的特殊子帧S,其中特殊子帧S包括下行导频时隙(Downlink Pilot Time Slot,DwPTS)、保护间隔(Guard Period,GP)、上行导频时隙(Uplink Pilot Time Slot,UpPTS),其中GP不传送任何信号,为上下行之间提供保护,避免上下行之间出现交叉干扰。根据上行子帧U与下行子帧D的比例,TDD帧结构包括多种,图8和图9便示出了配置1和配置4两种TDD帧结构。那么在TDD系统中,在以上方法的步骤S310中,在连续的上行子帧或下行子帧中,所述至少两个HARQ进程可以在连续的TTI内发送相同的数据。当然,在不具备连续的上行子帧或下行子帧的条件下,也可以在非连续的TTI内发送相同的数据,且如果调整了接收端的HARQ缓存的调度顺序,则非连续的TTI内发送相同的数据的时间间隔不受限制。
另外,相比于FDD模式,TDD下的HARQ进程周期与上下行配置以及TTI位置都相关,对于相邻HARQ进程因上下行切换造成反馈等待时间大于生成ACK/NACK的时间时,对传输相同的数据的相邻HARQ进程的反馈进行‘或’逻辑的bundling,将有有助于缓解反馈资源紧张的技术问题。
本发明实施例还提供一种HARQ方法,其执行主体为接收端,且该接收端可以位于终端侧,也可以位于基站侧。如图10所示,该方法包括:
S101:对传输相同的数据的相邻HARQ进程的反馈信息进行逻辑或的运算;
S102:利用同一信道资源发送所述逻辑或运算后的结果。
以上行为例,请参考表3,表3中左边第一列的数字0~6分别代表TDD帧结构的配置类型,上面第二行的数字0~9分别代表子帧序号,序号为n的子帧对应的PHICH位置偏移表示在当前位置发送的上行PUSCH数据在多少个子帧后的位置接收ACK/NACK反馈。表3中带有括号的数值为按照本方法进行“或”的bundling所对应的数值,使得相邻的HARQ进程对应同一个PHICH资源。例如,对于TDD配置类型为“4”且序号为“2”和“3”的子帧,其对应的PHICH位置偏移分别为6(6)和6(5)。其中括号外的数字表示传统方案下的偏移值,即当前序号为“2”和“3”的子帧,其反馈位置为其后6个帧——序号为“8”和“9”的子帧所对应的下行PHICH位置;括号内的数字表示本实施例修改后的偏移值,即当前序号为“2”和“3”的子帧,其反馈位置分别为其后6和5个帧——序号为“8”的子帧所对应的下行PHICH位置。可见,本实施例中,帧“2”和帧“3”的PHICH反馈位置都在序号为“8”的子帧,因此可以实现逻辑“或”的运算。
表3
下行则更加简单,请参考表4,表中左边第一列的数字0~6分别代表TDD帧结构的配置类型,上面第二行的数字0~9分别代表子帧序号,序号为n的子帧对应的PUCCH ACK/NACK表示当前上行子帧发送的ACK/NACK是对前多少个子帧的物理下行共享信道(Physical Downlink Shared CHannel,PDSCH)的反馈。表4中具有多个数字的单元格表示这些数字所代表的多个下行PDSCH的反馈可以通过“或”的bundling在同一个物理上行控制信道(Physical Uplink Control CHannel,PUCCH)资源上进行传输。例如,TDD配置类型为1且子帧序号为2的PUCCH上的ACK/NACK对应上一个帧中序号为“6”和“7”的子帧的PDSCH的反馈,因为同一个PUCCH位置对饮多个PDSCH位置,因此本实施例可以对多个PDSCH的ACK/NACK进行逻辑“或”的运算。
表4
进一步,以TDD配置1(config1)和配置4(config4)帧结构为例,分别如图8和图9所示,无论是在上行链路(UL),还是在下行链路(DL),对于传输相同的数据的相邻HARQ进程的反馈信息可以进行逻辑或的运算;并利用同一信道资源反馈所述逻辑或运算后的结果。
另外,以上方法的执行主体在终端侧时,可以以进程通知的方式通知终端哪些HARQ进程用于发送相同的数据。此时,所述终端侧(即为发射端)还接收指示消息:所述指示消息包括HARQ进程号组合,所述HARQ进程号组合包括至少两个HARQ进程号,用于指示所述至少两个HARQ进程号对应的至少两个HARQ进程发送相同的数据;或者所述指示消息包括指示位,用于指示具有相同指示位的至少两个HARQ进程发送相同的数据;或者所述指示消息包括至少两个HARQ进程号字段,用于指示所述至少两个HARQ进程号所对应的至少两个HARQ进程发送相同的数据。例如,可以通过无线资源控制(Radio Resource Control,RRC)配置方式,也可以通过物理下行控制信道(Physical Downlink Control CHannel,PDCCH)通知或直接调度等方式通知终端哪些HARQ进程用于发送相同的数据,本发明实施例不做任何限制。
在通过RRC配置方式通知终端哪些HARQ进程用于发送相同的数据的方法中,可以在媒体接入层主要配置(MAC-MainConfig)消息中设置字段,用于通知终端需要发送相同的数据的HARQ进程号组合,例:{进程1,进程3}表示进程1和进程3为短时延组合。在通过PDCCH通知方式通知终端哪些HARQ进程用于发送相同的数据的方法中,在PDCCH消息中设置指示位,配合HARQ进程号通知终端是该HARQ进程应与相同指示位的HARQ进程用于发送相同的数据,例如:该指示位为表5中的HARQ进程合并指示位(HARQ process combination indicator)。
表5
在通过PDCCH直接调度方式通知终端哪些HARQ进程用于发送相同的数据的方法中,PDCCH调度多个HARQ进程,例如:在PDCCH消息中增加HARQ进程号(HARQ process number)字段,如表6中,除了HARQ processnumber字段以外,增加了HARQ process number 2字段,用于指示这两个进程用于发送相同的数据。
表6
本领域普通技术人员可以理解实现以上方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,所述的程序可以存储于一计算机可读介质中,所述可读介质,如:ROM/RAM、磁碟、光盘等。
例如,本发明实施例提供的一种计算机程序产品,包括计算机可读介质,该可读介质包括一组程序代码,用于执行以上实施例所描述的任一种HARQ方法。
本发明实施例还提供一种通信装置,如图11所示,该装置包括存储器111与处理器112,其中存储器111内存储一组程序代码,处理器112调用存储器111内的程序代码,执行以上方法实施例所描述的任一种HARQ方法。具体过程同图1、图2或图3所示的方法实施例,在此不再赘述。
本发明实施例还提供另一种通信装置,如图12所示,该装置包括发送单元121、接收单元122以及处理单元123。其中发送单元121可以是发射机,接收单元122可以是接收机,处理单元123可以是处理器;且发送单元121用于通过至少两个HARQ进程发送相同的数据;接收单元122通过所述至少两个HARQ进程接收所述数据的反馈;当所述接收单元接收到所述数据的肯定确认ACK反馈时,处理单元123用于确定所述数据发送成功。
另外,同图1所示的方法实施例,接收单元还可以用于接收所述指示消息。关于指示消息的类型或内容同图1所示方法实施例,在此不再赘述。
本实施例的装置的其它细节与技术效果与图1所示方法实施例类似,此处不再赘述。
请参考图13,本发明实施例还提供一种HARQ装置,位于接收端,可以用于执行图10实施例所示的方法。如图10所示,该装置包括逻辑运算单元131和发送单元132,其中逻辑运算单元131用于对传输相同的数据的相邻HARQ进程的反馈信息进行逻辑或的运算;发送单元132用于利用同一信道资源反馈所述逻辑或运算后的结果。
需要说明的是,以上实施例的通信装置中的各个单元可以作为分立组件存在于终端或接入网设备中,当然也可以将部分整合或全部整合为一个逻辑实体设置于终端或接入网设备中。本实施例不做任何限制。
以上图11、12和13中所示的任一种通信装置,可以位于终端也可以位于基站。因此,本发明实施例还提供一种终端、基站或通信系统,包括以上图11、12和13中所示的任一种通信装置。
综上所述,以上实施例通过至少两个HARQ进程来发送相同的数据,且只要有一个HARQ进程上反馈肯定确认(ACK)信息,即认为该数据发送成功。可见,该方法通过多发送一定冗余,来增加反馈ACK信息的概率,且无论哪个HARQ进程上反馈ACK信息,就等同于其它HARQ进程也反馈了ACK信息,从而提前结束其它HARQ进程。从而,整体来看,反馈ACK信息的概率增加,且基于其中一个HARQ进程的ACK反馈,其它进程可以提前结束,因此HARQ的时延得以降低。
其它实施例:
实施例1、一种混合自动重传请求HARQ方法,包括:
发射端通过至少两个HARQ进程发送相同的数据;
发射端接收所述数据的反馈,且接收到肯定确认ACK反馈时,确定所述数据发送成功。
实施例2、根据实施例1所述的方法,所述发射端通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程中的相邻HARQ进程发送所述数据的时间间隔至少为4个传输时间间隔TTI。
实施例3、根据实施例1所述的方法所述发射端通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程分别在连续的TTI内发送所述数据。
实施例4、根据实施例1至3任一项所述的方法,所述HARQ进程的数量小于或等于环回时间RTT内的TTI数量,且所述发射端在RTT内通过所述至少两个HARQ进程发送相同的数据。
实施例5、根据实施例1至4任一项所述的方法,还包括:
所述发射端接收指示消息,所述指示消息包括HARQ进程号组合,所述HARQ进程号组合包括所述至少两个HARQ进程号。
实施例6、根据实施例5所述的方法,所述指示消息为媒体接入层主要配置MAC-MainConfig消息。
实施例7、根据实施例1至4任一项所述的方法,还包括:
所述发射端接收指示消息,所述指示消息包括指示位,用于指示具有相同指示位的所述至少两个HARQ进程发送相同的数据。
实施例8、根据实施例7所述的方法,所述指示消息为物理下行控制信道PDCCH消息。
实施例9、根据实施例1至4任一项所述的方法,还包括:
所述发射端接收指示消息,所述指示消息包括所述至少两个HARQ进程号字段。
实施例10、根据实施例9所述的方法,所述指示消息为物理下行控制信道PDCCH消息。
实施例11、一种混合自动重传请求HARQ方法,包括:
接收端对传输相同的数据的相邻HARQ进程的反馈信息进行逻辑或的运算;
接收端利用同一信道资源发送所述逻辑或运算后的结果。
实施例12、一种通信装置,包括:
发送单元,用于通过至少两个HARQ进程发送相同的数据;
接收单元,用于接收所述数据的反馈;
处理单元,当所述接收单元接收到所述数据的肯定确认ACK反馈时,用于确定所述数据发送成功。
实施例13、根据实施例12所述的装置,所述发送单元通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程中的相邻HARQ进程发送所述数据的时间间隔至少为4个传输时间间隔TTI。
实施例14、根据实施例12所述的装置,所述发送单元通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程分别在连续的TTI内发送所述数据。
实施例15、根据实施例12至14任一项所述的装置,所述HARQ进程的数量小于或等于环回时间RTT内的TTI数量,且所述发射端在RTT内通过所述至少两个HARQ进程发送相同的数据。
实施例16、根据实施例12至15任一项所述的装置,还包括:
所述接收单元还用于接收指示消息,所述指示消息包括HARQ进程号组合,所述HARQ进程号组合包括所述至少两个HARQ进程号。
实施例17、根据实施例16所述的装置,所述指示消息为媒体接入层主要配置MAC-MainConfig消息。
实施例18、根据实施例12至15任一项所述的装置,还包括:
所述接收单元还用于接收指示消息,所述指示消息包括指示位,用于指示具有相同指示位的所述至少两个HARQ进程发送相同的数据。
实施例19、根据实施例18所述的装置,所述指示消息为物理下行控制信道PDCCH消息。
实施例20、根据实施例12至15任一项所述的装置,还包括:
所述接收单元还用于接收指示消息,所述指示消息包括所述至少两个HARQ进程号字段。
实施例21、根据实施例20所述的装置,所述指示消息为物理下行控制信道PDCCH消息。
实施例22、一种通信装置,包括:
逻辑运算单元,用于对传输相同的数据的相邻HARQ进程的反馈信息进行逻辑或的运算;
发送单元,用于利用同一信道资源反馈所述逻辑或运算后的结果。
实施例23、一种通信装置,包括存储器与处理器,其中所述存储器内存储程序代码,所述处理器调用所述存储器内的程序代码,执行如实施例1至11任一项所述的步骤。
实施例24、一种计算机程序产品,包括计算机可读介质,其内存储程序代码,所述程序代码用于执行如实施例1至11任一项所述的步骤。
实施例25、一种终端,包括如实施例12至23任一项所述的通信装置。
实施例26、一种基站,包括如实施例12至23任一项所述的通信装置。
实施例27.一种通信系统,包括如实施例12至23任一项所述的通信装置。
以上仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以作出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (14)
1.一种混合自动重传请求HARQ方法,其特征在于,包括:
发射端通过至少两个HARQ进程发送相同的数据;
所述发射端接收所述数据的反馈,且接收到肯定确认ACK反馈时,确定所述数据发送成功。
2.根据权利要求1所述的方法,其特征在于,所述发射端通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程中的相邻HARQ进程发送所述数据的时间间隔至少为4个传输时间间隔TTI。
3.根据权利要求1所述的方法,其特征在于,所述发射端通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程分别在连续的TTI内发送所述数据。
4.根据权利要求1至3任一项所述的方法,其特征在于,所述HARQ进程的数量小于或等于环回时间RTT内的TTI数量,且所述发射端在RTT内通过所述至少两个HARQ进程发送相同的数据。
5.根据权利要求1至4任一项所述的方法,其特征在于,还包括:
所述发射端接收指示消息,所述指示消息包括HARQ进程号组合,所述HARQ进程号组合包括所述至少两个HARQ进程号。
6.根据权利要求1至4任一项所述的方法,其特征在于,还包括:
所述发射端接收指示消息,所述指示消息包括指示位,用于指示具有相同指示位的所述至少两个HARQ进程发送相同的数据。
7.根据权利要求1至4任一项所述的方法,其特征在于,还包括:
所述发射端接收指示消息,所述指示消息包括所述至少两个HARQ进程号字段。
8.一种通信装置,其特征在于,包括:
发送单元,用于通过至少两个HARQ进程发送相同的数据;
接收单元,用于接收所述数据的反馈;
处理单元,当所述接收单元接收到所述数据的肯定确认ACK反馈时,用于确定所述数据发送成功。
9.根据权利要求8所述的装置,其特征在于,所述发送单元通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程中的相邻HARQ进程发送所述数据的时间间隔至少为4个传输时间间隔TTI。
10.根据权利要求8所述的装置,其特征在于,所述发送单元通过至少两个HARQ进程发送相同的数据的过程中,所述至少两个HARQ进程分别在连续的TTI内发送所述数据。
11.根据权利要求8至10任一项所述的装置,其特征在于,所述HARQ进程的数量小于或等于环回时间RTT内的TTI数量,且所述发射端在RTT内通过所述至少两个HARQ进程发送相同的数据。
12.根据权利要求8至11任一项所述的装置,其特征在于,
所述接收单元还用于接收指示消息,所述指示消息包括HARQ进程号组合,所述HARQ进程号组合包括所述至少两个HARQ进程号。
13.根据权利要求8至11任一项所述的装置,其特征在于,
所述接收单元还用于接收指示消息,所述指示消息包括指示位,用于指示具有相同指示位的所述至少两个HARQ进程发送相同的数据。
14.根据权利要求8至11任一项所述的装置,其特征在于,
所述接收单元还用于接收指示消息,所述指示消息包括所述至少两个HARQ进程号字段。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810252367.0A CN108574564A (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
CN201210113816.6A CN103378953B (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210113816.6A CN103378953B (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810252367.0A Division CN108574564A (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103378953A true CN103378953A (zh) | 2013-10-30 |
CN103378953B CN103378953B (zh) | 2018-04-17 |
Family
ID=49463545
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210113816.6A Active CN103378953B (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
CN201810252367.0A Pending CN108574564A (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810252367.0A Pending CN108574564A (zh) | 2012-04-18 | 2012-04-18 | 混合自动重传请求方法与装置 |
Country Status (1)
Country | Link |
---|---|
CN (2) | CN103378953B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015185021A1 (en) * | 2014-06-06 | 2015-12-10 | Huawei Technologies Co., Ltd. | System and method for forward error correction |
CN105765894A (zh) * | 2013-11-28 | 2016-07-13 | 瑞典爱立信有限公司 | 用于混合自动重复请求传输的方法、装置和用户设备 |
WO2018157406A1 (zh) * | 2017-03-03 | 2018-09-07 | 广东欧珀移动通信有限公司 | 一种传输数据的方法、终端设备和网络设备 |
CN110572247A (zh) * | 2015-10-27 | 2019-12-13 | 上海朗帛通信技术有限公司 | 一种窄带无线通信中的方法和装置 |
CN110875804A (zh) * | 2018-09-04 | 2020-03-10 | 成都华为技术有限公司 | 发送和接收反馈信息的方法以及装置 |
WO2020164110A1 (zh) * | 2019-02-15 | 2020-08-20 | 华为技术有限公司 | 通信方法、装置及系统 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SG11202107442PA (en) * | 2019-01-08 | 2021-08-30 | Beijing Xiaomi Mobile Software Co Ltd | Downlink data sending method, receiving method, device, and storage medium |
CN112787774B (zh) * | 2019-11-08 | 2022-06-14 | 华为技术有限公司 | 一种混合自动重传请求的处理方法及通信装置 |
WO2021142626A1 (zh) * | 2020-01-14 | 2021-07-22 | 华为技术有限公司 | 上行反馈的方法和装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1689262A (zh) * | 2002-08-13 | 2005-10-26 | 松下电器产业株式会社 | 多个混合自动重复请求进程处理方法 |
CN101938342A (zh) * | 2009-07-01 | 2011-01-05 | 中兴通讯股份有限公司 | 一种基于混合自动重发请求的数据传输方法及装置 |
CN102017702A (zh) * | 2008-04-25 | 2011-04-13 | 交互数字专利控股公司 | 用于在移动通信网络中进行小区重选的方法和设备 |
CN102281646A (zh) * | 2011-07-29 | 2011-12-14 | 电信科学技术研究院 | 一种上行数据的传输方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1983914B (zh) * | 2005-12-16 | 2011-04-13 | 株式会社Ntt都科摩 | 一种混合自动请求重传方法及系统 |
CN101345608B (zh) * | 2007-07-13 | 2011-08-17 | 电信科学技术研究院 | 管理多载波tdd上行的harq进程的方法及装置 |
-
2012
- 2012-04-18 CN CN201210113816.6A patent/CN103378953B/zh active Active
- 2012-04-18 CN CN201810252367.0A patent/CN108574564A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1689262A (zh) * | 2002-08-13 | 2005-10-26 | 松下电器产业株式会社 | 多个混合自动重复请求进程处理方法 |
CN102017702A (zh) * | 2008-04-25 | 2011-04-13 | 交互数字专利控股公司 | 用于在移动通信网络中进行小区重选的方法和设备 |
CN101938342A (zh) * | 2009-07-01 | 2011-01-05 | 中兴通讯股份有限公司 | 一种基于混合自动重发请求的数据传输方法及装置 |
CN102281646A (zh) * | 2011-07-29 | 2011-12-14 | 电信科学技术研究院 | 一种上行数据的传输方法及装置 |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105765894A (zh) * | 2013-11-28 | 2016-07-13 | 瑞典爱立信有限公司 | 用于混合自动重复请求传输的方法、装置和用户设备 |
US10778377B2 (en) | 2013-11-28 | 2020-09-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods, apparatuses and user equipment for hybrid automatic repeat request transmission |
CN105765894B (zh) * | 2013-11-28 | 2019-06-07 | 瑞典爱立信有限公司 | 用于混合自动重复请求传输的方法、装置和用户设备 |
WO2015185021A1 (en) * | 2014-06-06 | 2015-12-10 | Huawei Technologies Co., Ltd. | System and method for forward error correction |
US9923665B2 (en) | 2014-06-06 | 2018-03-20 | Huawei Technologies Co., Ltd. | System and method for forward error correction |
US10601545B2 (en) | 2014-06-06 | 2020-03-24 | Huawei Technologies Co., Ltd. | System and method for forward error correction |
CN110572247A (zh) * | 2015-10-27 | 2019-12-13 | 上海朗帛通信技术有限公司 | 一种窄带无线通信中的方法和装置 |
CN110572247B (zh) * | 2015-10-27 | 2022-03-01 | 上海朗帛通信技术有限公司 | 一种窄带无线通信中的方法和装置 |
CN109792312A (zh) * | 2017-03-03 | 2019-05-21 | Oppo广东移动通信有限公司 | 一种传输数据的方法、终端设备和网络设备 |
WO2018157406A1 (zh) * | 2017-03-03 | 2018-09-07 | 广东欧珀移动通信有限公司 | 一种传输数据的方法、终端设备和网络设备 |
CN110875804A (zh) * | 2018-09-04 | 2020-03-10 | 成都华为技术有限公司 | 发送和接收反馈信息的方法以及装置 |
WO2020048472A1 (zh) * | 2018-09-04 | 2020-03-12 | 华为技术有限公司 | 发送和接收反馈信息的方法以及装置 |
CN110875804B (zh) * | 2018-09-04 | 2021-04-09 | 成都华为技术有限公司 | 发送和接收反馈信息的方法以及装置 |
US11968047B2 (en) | 2018-09-04 | 2024-04-23 | Huawei Technologies Co., Ltd. | Method and apparatus for sending feedback information, and method and apparatus for receiving feedback information |
WO2020164110A1 (zh) * | 2019-02-15 | 2020-08-20 | 华为技术有限公司 | 通信方法、装置及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN103378953B (zh) | 2018-04-17 |
CN108574564A (zh) | 2018-09-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6564823B2 (ja) | セミパーシステントスケジューリングデータパケットの確認応答情報をフィードバックおよび受信する装置 | |
CN103378953A (zh) | 混合自动重传请求方法与装置 | |
EP2982074B1 (en) | Communication in the presence of uplink-downlink configuration change | |
CN101958777B (zh) | 正确/错误应答消息发送的处理方法及装置 | |
EP3454596B1 (en) | Method and apparatus for determining a feedback time sequence, and device and storage medium | |
CN103036657B (zh) | 一种数据传输方法和装置 | |
CN102104469B (zh) | 终端上/下行harq反馈信息调度方法及装置 | |
CN105934907A (zh) | 无线资源调度方法及装置 | |
WO2021213203A1 (zh) | 一种harq-ack反馈方法、终端及基站 | |
CN110061816A (zh) | 一种移动通信系统、网络设备、终端设备和数据调度方法 | |
CN103312473B (zh) | 减少harq合并失败的方法和装置 | |
CN114866204A (zh) | 一种传输方法、终端设备及基站 | |
CN101686556B (zh) | 资源释放方法、装置及系统 | |
EP3032901A1 (en) | Information transmission method and device | |
WO2018000373A1 (zh) | 一种数据传输方法、设备及系统 | |
CN109560896B (zh) | 一种5g系统中基于码块组进行数据传输的方法和系统 | |
CN108781135A (zh) | 物联网的传输优化方法、装置和设备 | |
CN101547069B (zh) | 一种数据接收反馈信号的发送方法、系统和装置 | |
CN113067681A (zh) | 一种混合自动重传请求处理方法、通信设备及介质 | |
CN102420682B (zh) | 中继链路下行反馈信息传输时序确定方法及装置 | |
WO2017075832A1 (zh) | 一种下行数据包、上行数据包传输方法及设备 | |
Wang et al. | Delay minimization of the adaptive go-back-N ARQ protocols for point-to-multipoint communication | |
CN102404095B (zh) | 一种混合自动重传请求的处理方法及装置 | |
US8625478B2 (en) | Hybrid automatic repeat request system and method thereof in a communication system | |
CN105637790A (zh) | 一种重传数据的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |