CN101471756A - 集中式调度的多跳中继下行***中的harq方法 - Google Patents

集中式调度的多跳中继下行***中的harq方法 Download PDF

Info

Publication number
CN101471756A
CN101471756A CN 200710173386 CN200710173386A CN101471756A CN 101471756 A CN101471756 A CN 101471756A CN 200710173386 CN200710173386 CN 200710173386 CN 200710173386 A CN200710173386 A CN 200710173386A CN 101471756 A CN101471756 A CN 101471756A
Authority
CN
China
Prior art keywords
relay station
ack
nack
decoding
packet
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
Application number
CN 200710173386
Other languages
English (en)
Other versions
CN101471756B (zh
Inventor
周婷
徐景
王海峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Yan Jing Information Technology Co ltd
Original Assignee
Shanghai Research Center for Wireless Communications
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 Shanghai Research Center for Wireless Communications filed Critical Shanghai Research Center for Wireless Communications
Priority to CN2007101733866A priority Critical patent/CN101471756B/zh
Publication of CN101471756A publication Critical patent/CN101471756A/zh
Application granted granted Critical
Publication of CN101471756B publication Critical patent/CN101471756B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)
  • Radio Relay Systems (AREA)

Abstract

一种集中式调度的多跳中继下行***中的HARQ方法,采用非自适应性HARQ及相应的信令反馈方式与流程时,HARQ重传不需要重新调度而是在第一次传输所分配的资源块上进行,并为提高资源利用率设计信令反馈尽可能早地通知基站释放已经成功的链路的资源,从而大大减小重传时延。中继站采用流水线式的HARQ及自适应混合转发模式。中继站在接收到数据包后一边进行译码的同时一边可以把数据包转发,即像流水线的模式,中继站在时隙允许译码并且译码成功的情况下采用译码转发,否则采用放大转发或者解调转发,即中继站自适应根据情况选取转发模式,从而使端到端时延大大减小、不受译码时延的影响,从而为实时业务提供更好的服务。

Description

集中式调度的多跳中继下行***中的HARQ方法
技术领域
本发明是集中式调度的多跳中继下行***中的新型的HARQ(混合自动请求重传)方案。它是为了解决多跳中继***中数据传输时延、集中式调度中信令传输时延等问题而提出的。
背景技术
在传统的无线通信***中,数据传输是在基站(BS)和移动台(MS)之间直接进行的,又叫做单跳***。然而随着未来无线通信***向更高数据率、更宽频带和更高端频谱的不断发展,它已经逐渐不能满足需求。于是,多跳中继***由于其增加覆盖和提高频谱效率的优点获得越来越多的关注。在多跳中继***中有两种资源管理方式,集中式和分布式调度。在集中式调度中,BS负责所有上下行链路的资源分配,而在分布式调度中,BS和每个中继站(RS)都具备资源分配的能力。因为集中式调度具有更简单的协议结构和干扰管理,所以它是目前多跳中继***的首选研究假设。
多跳中继***的一大缺点是端到端时延大,因为在BS和MS之间的传输要经过一个或者多个RS。特别是对于集中式调度这一问题更加严重,任何一段链路的带宽请求都必须经多跳递交给BS来进行资源调度然后再经多跳通知相关节点,增大了HARQ重传时延和信令开销。因此在多跳中继***中,如何减小端到端时延,从而为实时业务,如视频点播、多媒体视频流、交互游戏等,提供更好的服务是一大挑战性问题。
现有技术中提出了一种集中式调度的多跳中继下行***的HARQ方法。由于集中式调度中,任何带宽请求需要递交给BS进行资源调度,所以如果在多跳链路中特别是不与BS直接相邻的链路发生了传输失败需要请求HARQ时,需要特别设计的反馈机制通知BS哪一段链路出错,从而BS才能够分配资源给该段链路进行重传。因此该方法还特别提出了一种在上行反馈ACK信道进行正交编码向BS指示不同链路的传输失败与否情况,从而请求带宽进行重传。其具体方法如下:
首先,BS对从BS到用户终端(UE)的所有链路分配好带宽用于数据包的第一次HARQ传输;
然后,位于该路径上的RS接收下行数据包并进行译码。如果译码失败,例如CRC校验失败,则该RS则发送上行正交编码的NACK0反馈给前一跳并且停止该错误的数据包的继续转发,等候重传;如果译码成功,则RS把该数据包转发给下一跳,并且暂不进行上行反馈,而是等候下一跳的反馈信令。当该RS接收到下一跳的上行反馈为NACKk,则发送另一正交编码的NACKk+1给前一跳;当该RS接收到下一跳的上行反馈为ACK,则仍然转发ACK给前一跳。
接着,当UE接收到数据包并且译码正确,则反馈ACK给前一跳的RS,否则反馈NACK0
最后,当BS收到NACKK反馈,表明数据包在第(K+1)跳出错,从而BS对第(K+1)跳及后面所有链路重新分配资源进行重传,并通过下行信令通知相应节点。当BS收到ACK反馈,则表明数据包已经被UE正确接收,该数据包传输结束。
上述方法具有两大特点:1)每次重传都需要BS重新进行资源分配,即自适应性HARQ方案。该方案具有频谱利用率高的优点,但是在集中式调度的多跳中继***中,任何带宽请求都要通知BS进行资源调度,因而该方案会增加HARQ重传时延;2)RS只有正确译码才把数据包转发下一跳,即选择性转发协议。该协议前提是RS首先对数据包进行译码再判断是否进行转发,由于译码时延使得RS不可能在收到数据包后紧接的时隙进行转发,从而增大了端到端传输时延。
图1、图2给出了现有方法的两个实例。本发明说明书中均假设BS到UE中间需要3个RS,分别用R1、R2、R3表示,t1、t2、……、tn表示时隙。由于数据包译码时延,所以每个RS即使译码正确也要至少延迟1个时隙转发数据。实心圆表示RS进行信道译码。
例一:数据Data1第一次传输均成功。如图1所示,其过程如下:
R1在时隙t1收到Data1,译码正确后重编码,由于R1的译码时延,数据包不能在t2转发,最快只能在t3时隙转发数据Data1给R2。往后的RS进行类似的操作。当UE正确译码,在t8反馈ACK,经R3、R2、R1传递给BS。Data1传输正确结束。在例一情况下,UE最快的情况下在时隙t7才能收到Data1,端到端时延为7个时隙。
例二:数据Data2在R1、R3的第一次传输失败。如图2所示,其过程如下:
R1在时隙t1收到数据Data2,译码出错,则在t2反馈NACK0向BS请求重传,并不再往下转发数据。BS最快在t3重传Data2。R1把两次接收的版本合并后正确译码,在t5把Data2转发给R2。R2正确译码后,在t7转发给R3。此时R3译码出错,则在t8反馈NACK0请求重传。R2收到NACK0则重新编码转发NACK1,R1收到NACK1则重新编码转发NACK2。BS收到NACK2,BS知道在R2至R3链路出错,则重新为该链路往后的所有链路调度资源,并通过信令通知相关节点。R2收到资源分配信令后在t13重传Data2,R3把两次接收版本合并后正确译码,则在t15转发给UE。UE正确译码,在t16反馈ACK,经R3、R2、R1传递给BS。Data2传输正确结束。在例二中,Data2的端到端时延最快为15个时隙。
值得注意的是,上述例子的时隙安排均表示最快可能的情况,实际***可能根据***负载情况、调度情况时隙有所不同。
发明内容
针对集中式调度的多跳中继下行***的问题以及现有HARQ方法的缺陷,本发明提供一种新型的集中式调度的多跳中继下行***中的HARQ方法,并具体提供以下三种技术方案:
一种集中式调度的多跳中继下行***中的HARQ方法,包括以下步骤:
首先,基站对从基站到用户终端的所有链路分配好带宽,并且该资源预留到数据包传输成功为止;
然后,位于该路径上的中继站接收下行数据包并进行译码,如果译码失败,该中继站则发送上行正交编码的NACK反馈给前一跳并且停止该错误的数据包的继续转发,等候重传;如果译码成功,中继站则把该数据包转发给下一跳,并且发送上行正交编码的ACK0反馈给前一跳;
当该中继站接收到的上行反馈为ACKk,则发送另一正交编码的ACKk+1给前一跳;当该中继站接收到的上行反馈为NACK,则接收到NACK的中继站在预留的资源块上进行数据包重传;
接着,当用户终端接收到数据包并且译码正确,则反馈ACK0给前一跳的中继站,否则反馈NACK;
最后,当基站收到ACKK反馈,表明数据包在第K+1跳已经成功,则释放第K+1跳及前面所有链路所预留的资源,当基站收到NACK反馈,则在基站预留的资源块上进行数据包重传。
一种集中式调度的多跳中继下行***中的HARQ方法,包括以下步骤:
首先,基站对从基站到用户终端的所有链路分配好带宽用于数据包的第一次HARQ传输;
然后,位于该路径上的各中继站接收下行数据包,采用放大转发(Amplif-and-Forward,简写为“AF”)或者解调转发(Demodulate-and-Forward,简写为“DmF”)的模式转发给下一跳,中继站监听前一跳发出的信令,如果听到ACK0,说明前一跳译码正确,则该中继站也对数据包进行译码;如果听到NACK0,说明前一跳译码错误,则该中继站把数据包缓存;
当中继站进行译码,如果译码失败,该中继站发送正交编码的NACK0,否则发送正交编码的ACK0,它的前一跳和下一跳节点同时监听该信令;
如果中继站收到来自下一跳的信令是NACKk,则发送另一正交编码的NACKk+1给前一跳;如果中继站收到来自下一跳的信令是ACK0,则不采取任何操作;中继站收到来自下一跳的信令是ACK1,则仍然转发ACK1给前一跳;
接着,当用户终端接收到数据包,它首先监听前一跳的信令,如果听到ACK0,说明前一跳译码正确,则用户终端也对数据包进行译码;如果听到NACK0,说明前一跳译码错误,则用户终端只需把数据包缓存而不再进行译码。当用户终端进行译码,如果正确,则反馈ACK1给前一跳的中继站,否则反馈NACK0
最后,当基站收到NACKK反馈,表明数据包在第K+1跳出错,从而基站对第K+1跳及后面所有链路重新分配资源进行重传,并通过下行信令通知相应中继站,相应中继站收到下行资源分配信令则采用译码转发(Decode-and-Forward,简写为“DcF”)模式重传数据包,当基站收到ACK0反馈,则不采取任何操作;当基站收到ACK1反馈,则表明数据包已经被用户终端正确接收,该数据包传输结束。
一种集中式调度的多跳中继下行***中的HARQ方法,包括以下步骤:
首先,基站对从基站到用户终端的所有链路分配好带宽,并且该资源预留到数据包传输成功为止;
然后,位于该路径上的各中继站接收下行数据包,采用放大转发或解调转发的模式转发给下一跳,中继站监听前一跳发出的信令,如果听到ACK0,说明前一跳译码正确,则该中继站也对数据包进行译码;如果听到NACK,说明前一跳译码错误,则该中继站只需把数据包缓存而不再进行译码;
当中继站进行译码,如果译码失败,该中继站则发送正交编码的NACK,否则发送正交编码的ACK0,它的前一跳和下一跳节点同时监听该信令;
如果中继站收到来自下一跳的信令是ACKk,则发送另一正交编码的ACKk+1给前一跳;如果中继站收到来自下一跳的信令是NACK,则在预留的资源块上采用译码转发模式重传数据包;
接着,当用户终端接收到数据包,它先监听前一跳的信令,如果听到ACK0,说明前一跳译码正确,则用户终端也对数据包进行译码;如果听到NACK,说明前一跳译码错误,则用户终端只需把数据包缓存而不再进行译码。当用户终端进行译码,如果正确,则反馈ACK0给前一跳的中继站,否则反馈NACK;
最后,当基站收到ACKK反馈,表明数据包在第K+1跳已经成功,从而释放第K+1跳及前面所有链路所预留的资源,当基站收到NACK反馈,则在预留的资源块上进行数据包重传。
本发明提出的集中式调度的多跳中继下行***中的HARQ方法,应用于集中式调度的多跳中继***下行链路MAC层的HARQ传输协议。与现有技术相比,本发明所能够有效的减小集中式调度的多跳中继***端到端传输时延,弥补现有方案的缺陷和不足。为实时业务提供更好的服务。
附图说明
图1、图2为现有集中式调度的多跳中继下行***的HARQ方法在两种情况下的流程图;
图3、图4为本发明实施例一在两种情况下的实例流程图;
图5、图6为本发明实施例二在两种情况下的实例流程图;
图7、图8为本发明实施例三在两种情况下的实例流程图。
具体实施方式
一种集中式调度的多跳中继下行***中的HARQ方法的三个实施例,分别是:
实施例一、选择性转发RS的非自适应型HARQ方法,步骤如下:
首先,BS对从BS到UE的所有链路分配好带宽,并且该资源预留到数据包传输成功为止。
然后,位于该路径上的RS接收下行数据包并进行译码。如果译码失败(如CRC校验),该RS则发送上行正交编码的NACK反馈给前一跳并且停止该错误的数据包的继续转发,等候重传;如果译码成功,RS则把该数据包转发给下一跳,并且发送上行正交编码的ACK0反馈给前一跳。
当该RS接收到的上行反馈为ACKk,则发送另一正交编码的ACKk+1给前一跳;当该RS接收到的上行反馈为NACK,则接收到NACK的RS在预留的资源块上进行数据包重传,且不需要把NACK转发给前一跳。
接着,当UE接收到数据包并且译码正确,则反馈ACK0给前一跳的RS,否则反馈NACK。
最后,当BS收到ACKK反馈,表明数据包在第(K+1)跳已经成功,从而释放第(K+1)跳及前面所有链路所预留的资源。当BS收到NACK反馈,则在BS预留的资源块上进行数据包重传。
该方法中任何链路出现错误,相应的发送节点将在指定的时隙在预留的资源块上进行HARQ重传,而不需要向BS重新请求资源;为了提高资源利用率,已经成功的链路将反馈正交编码的ACK信令,尽可能早地通知BS释放掉对应的资源,从而大大减小重传时延。
其具体实例如下:
例一:数据Data1第一次传输均成功。如图3所示,其过程如下:
R1在时隙t1收到Data1,译码正确,在t2反馈ACK0给BS,由于译码时延,R1最快只能在t3时隙转发Data1给R2。BS收到ACK0,知道R1正确接收,则释放预留给BS至R1链路的资源。R2收到Data1,译码正确,在t4反馈ACK0给R1,并在t5把Data1转发给R3。R1收到后ACK0后重新编码在t5反馈ACK1给BS。BS收到ACK1,知道R2正确接收,则释放预留给R1至R2的资源。往后的RS进行类似的操作。UE正确译码,在t8反馈ACK0,经R3、R2、R1分别重新编码最后把ACK3传递给BS,BS知道UE成功接收,释放所有资源。Data1传输正确结束。例一中端到端时延为7个时隙。
例二:数据Data2在R1和R3第一次传输失败。如图4所示,其过程如下:
R1在时隙t1收到Data2,译码出错,则在t2反馈NACK向BS请求重传,并不再往下转发数据。BS收到NACK,则在预留的资源块上在t3重传Data2。R1把两次接收的版本合并后正确译码,在t4反馈ACK0给BS,并在t5把Data2转发给R2。BS收到ACK0,知道R1正确接收,则释放预留给BS至R1链路的资源。R2收到Data2,正确译码,则在t6反馈ACK0给R1并在t7转发Data2给R3。R1收到后ACK0重新编码在t5反馈ACK1给BS。BS收到ACK1,知道R2正确接收,则释放预留给R1至R2链路的资源。R3收到Data2,译码出错,则在t8反馈NACK请求重传。R2收到NACK则在预留的资源块上在t9重传Data2。R3把两次接收版本合并后正确译码,则在t10反馈ACK0给R2并在t11转发Data2给UE。R2收到ACK0则重新编码转发ACK1给R1,R1收到ACK1则重新编码转发ACK2给BS。BS收到ACK2,知道R3正确接收,则释放预留给R2至R3链路的资源。UE收到Data2,正确译码,在t12反馈ACK0,经R3、R2、R1分别重新编码最后把ACK3传递给BS,BS知道UE成功接收,释放所有资源,Data2传输正确结束。例二中端到端时延为11个时隙。
实施例二、流水线式RS的自适应性HARQ方法,步骤如下:
首先,BS对从BS到UE的所有链路分配好带宽用于数据包的第一次HARQ传输。
然后,位于该路径上的各RS接收下行数据包,最快可在下一紧接的时隙采用AF或DmF的模式转发给下一跳。RS监听前一跳发出的信令,如果听到ACK0,说明前一跳译码正确,则该RS也对数据包进行译码;如果听到NACK0,说明前一跳译码错误,则该RS只需把数据包缓存而不再进行译码。
当RS进行译码,如果译码失败(如CRC校验),该RS发送正交编码的NACK0,否则发送正交编码的ACK0,它的前一跳和下一跳节点同时监听该信令。
如果RS收到来自下一跳的信令是NACKk,则发送另一正交编码的NACKk+1给前一跳;如果RS收到来自下一跳的信令是ACK0,则不采取任何操作;RS收到来自下一跳的信令是ACK1,则仍然转发ACK1给前一跳。
接着,当UE接收到数据包,它首先监听前一跳的信令,如果听到ACK0,说明前一跳译码正确,则UE也对数据包进行译码;如果听到NACK0,说明前一跳译码错误,则UE只需把数据包缓存而不再进行译码。当UE进行译码,如果正确,则反馈ACK1给前一跳的RS,否则反馈NACK0
最后,当BS收到NACKK反馈,表明数据包在第(K+1)跳出错,从而BS对第(K+1)跳及后面所有链路重新分配资源进行重传,并通过下行信令通知相应RS,相应RS收到下行资源分配信令则采用DcF模式重传数据包。当BS收到ACK0反馈,则不采取任何操作;当BS收到ACK1反馈,则表明数据包已经被UE正确接收,该数据包传输结束。
该方法中RS在接收到数据包后一边进行译码的同时一边可以把数据包转发,像流水线的模式,RS在时隙允许译码并且译码成功的情况下采用DcF,否则采用放大转发AF或者解调转发DmF,从而使端到端时延大大减小、不受译码时延的影响。
其具体实例如下:
例一:数据Data1第一次传输均成功。如图5所示,其过程如下:
R1在时隙t1收到Data1,一边译码的同时采用放大转发或者解调转发把数据包在t2时隙转发下去。R1译码正确反馈ACK0,BS和R2同时监听。R2接收Data1时监听到R1的ACK0信令,则对Data1一边进行译码一边采用AF或DmF把数据包在t3时隙转发下去。往后各RS进行类似的操作。UE正确译码,在t5反馈ACK1,经R3、R2、R1传递给BS。Data1传输正确结束。例一中端到端时延为4个时隙。其中ACK0由各RS发送,ACK1由UE发送。
例二:数据Data2在R1、R3的第一次传输失败。如图6所示,其中空心圆表示因RS监听到前一跳为NACK0而不译码。其过程如下:
R1在时隙t1收到Data2,一边译码的同时采用AF或DmF把数据包在t2时隙转发下去。R1译码出错,在t2反馈NACK0,BS和R2同时监听。R2接收Data2时监听到R1的NACK0信令,则把收到的Data2缓存而不译码,同时采用AF或DmF把Data2和NACK0在t3时隙转发下去。往后各RS进行类似的操作。BS收到NACK0,则为所有链路重新调度资源,在t3重传Data2。R1把两次接收的版本合并译码的同时采用AF或DmF把数据包在t4时隙转发下去。R1译码正确反馈ACK0,BS和R2同时监听。R2接收Data2时监听到R1的ACK0信令,则把两次接收的Data2版本合并译码,同时采用AF或DmF把数据包在t5时隙转发下去。R2译码正确反馈ACK0,R1和R3同时监听。R3接收Data2时监听到R2的ACK0信令,则把两次接收的Data2版本合并译码,同时采用AF或DmF把数据包在t6时隙转发下去。R3译码出错,在t6反馈NACK0,R2和UE同时监听。UE接收Data2时监听到R3的NACK0信令,则把收到的Data2缓存而不译码。R2收到NACK0则重新编码转发NACK1,R1收到NACK1则重新编码转发NACK2。BS收到NACK2,知道R2至R3链路出错,则重新为该链路往后的所有链路调度资源,并通过信令通知相关节点。R2收到资源分配信令后在t11采用DcF模式重传Data2,R3把三次接收版本合并译码,同时在t12采用AF或DmF模式转发给UE。R3译码正确,在t12反馈ACK0,R2和UE同时监听。UE接收Data2时监听到R3的ACK0信令,则把三次接收版本合并译码。UE译码正确,反馈ACK1,经R3、R2、R1传递给BS。Data2传输正确结束。例二中端到端时延为12个时隙。
实施例三、流水线式RS的非自适应型HARQ方法
首先,BS对从BS到UE的所有链路分配好带宽,并且该资源预留到数据包传输成功为止。
然后,位于该路径上的各RS接收下行数据包,最快可在下一紧接的时隙采用AF或DmF的模式转发给下一跳。RS监听前一跳发出的信令,如果听到ACK0,说明前一跳译码正确,则该RS也对数据包进行译码;如果听到NACK,说明前一跳译码错误,则该RS只需把数据包缓存而不再进行译码。
当RS进行译码,如果译码失败(如CRC校验),该RS则发送正交编码的NACK,否则发送正交编码的ACK0,它的前一跳和下一跳节点同时监听该信令。
如果RS收到来自下一跳的信令是ACKk,则发送另一正交编码的ACKk+1给前一跳;如果RS收到来自下一跳的信令是NACK,则在预留的资源块上采用DcF模式重传数据包。
接着,当UE接收到数据包,它先监听前一跳的信令,如果听到ACK0,说明前一跳译码正确,则UE也对数据包进行译码;如果听到NACK,说明前一跳译码错误,则UE只需把数据包缓存而不再进行译码。当UE进行译码,如果正确,则反馈ACK0给前一跳的RS,否则反馈NACK。
最后,当BS收到ACKK反馈,表明数据包在第(K+1)跳已经成功,从而释放第(K+1)跳及前面所有链路所预留的资源。当BS收到NACK反馈,则在预留的资源块上进行数据包重传。
该方法是第一种方法和第二种方法的综合方案,同时具备第一、第二方法的优点。
其具体实例如下:
例一:数据Data1第一次传输均成功。如图7所示,其过程如下:
第三种解决方法是第一种方法和第二种方法的综合方案,同时具备第一、第二方法的优点。其例一如图7所示,其端到端时延只有4个时隙。其例二如图8所示,端到端时延只有8个时隙。

Claims (5)

1、一种集中式调度的多跳中继下行***中的HARQ方法,其特征在于包括以下步骤:
首先,基站对从基站到用户终端的所有链路分配好带宽,并且该资源预留到数据包传输成功为止;
然后,位于该路径上的中继站接收下行数据包并进行译码,如果译码失败,该中继站则发送上行正交编码的NACK反馈给前一跳并且停止该错误的数据包的继续转发,等候重传;如果译码成功,中继站则把该数据包转发给下一跳,并且发送上行正交编码的ACK0反馈给前一跳;
当该中继站接收到的上行反馈为ACKk,则发送另一正交编码的ACKk+1给前一跳;当该中继站接收到的上行反馈为NACK,则接收到NACK的中继站在预留的资源块上进行数据包重传;
接着,当用户终端接收到数据包并且译码正确,则反馈ACK0给前一跳的中继站,否则反馈NACK;
最后,当基站收到ACKK反馈,表明数据包在第K+1跳已经成功,则释放第K+1跳及前面所有链路所预留的资源,当基站收到NACK反馈,则在基站预留的资源块上进行数据包重传。
2、一种集中式调度的多跳中继下行***中的HARQ方法,其特征在于包括以下步骤:
首先,基站对从基站到用户终端的所有链路分配好带宽用于数据包的第一次HARQ传输;
然后,位于该路径上的各中继站接收下行数据包,采用放大转发或者解调转发的模式转发给下一跳,中继站监听前一跳发出的信令,如果听到ACK0,说明前一跳译码正确,则该中继站也对数据包进行译码;如果听到NACK0,说明前一跳译码错误,则该中继站把数据包缓存;
当中继站进行译码,如果译码失败,该中继站发送正交编码的NACK0,否则发送正交编码的ACK0,它的前一跳和下一跳节点同时监听该信令;
如果中继站收到来自下一跳的信令是NACKk,则发送另一正交编码的NACKk+1给前一跳;如果中继站收到来自下一跳的信令是ACK0,则不采取任何操作;中继站收到来自下一跳的信令是ACK1,则仍然转发ACK1给前一跳;
接着,当用户终端接收到数据包,它首先监听前一跳的信令,如果听到ACK0,说明前一跳译码正确,则用户终端也对数据包进行译码;如果听到NACK0,说明前一跳译码错误,则用户终端只需把数据包缓存而不再进行译码,当用户终端进行译码,如果正确,则反馈ACK1给前一跳的中继站,否则反馈NACK0
最后,当基站收到NACKK反馈,表明数据包在第K+1跳出错,从而基站对第K+1跳及后面所有链路重新分配资源进行重传,并通过下行信令通知相应中继站,相应中继站收到下行资源分配信令则采用译码转发模式重传数据包,当基站收到ACK0反馈,则不采取任何操作;当基站收到ACK1反馈,则表明数据包已经被用户终端正确接收,该数据包传输结束。
3、根据权利要求2所述的集中式调度的多跳中继下行***中的HARQ方法,其特征在于:所述中继站接收下行数据包后,在下一紧接的时隙采用放大转发或者解调转发的模式转发给下一跳。
4、一种集中式调度的多跳中继下行***中的HARQ方法,其特征在于包括以下步骤:
首先,基站对从基站到用户终端的所有链路分配好带宽,并且该资源预留到数据包传输成功为止;
然后,位于该路径上的各中继站接收下行数据包,采用放大转发或解调转发的模式转发给下一跳,中继站监听前一跳发出的信令,如果听到ACK0,说明前一跳译码正确,则该中继站也对数据包进行译码;如果听到NACK,说明前一跳译码错误,则该中继站只需把数据包缓存而不再进行译码;
当中继站进行译码,如果译码失败,该中继站则发送正交编码的NACK,否则发送正交编码的ACK0,它的前一跳和下一跳节点同时监听该信令;
如果中继站收到来自下一跳的信令是ACKk,则发送另一正交编码的ACKk+1给前一跳;如果中继站收到来自下一跳的信令是NACK,则在预留的资源块上采用译码转发模式重传数据包;
接着,当用户终端接收到数据包,它先监听前一跳的信令,如果听到ACK0,说明前一跳译码正确,则用户终端也对数据包进行译码;如果听到NACK,说明前一跳译码错误,则用户终端只需把数据包缓存而不再进行译码,当用户终端进行译码,如果正确,则反馈ACK0给前一跳的中继站,否则反馈NACK;
最后,当基站收到ACKK反馈,表明数据包在第K+1跳已经成功,从而释放第K+1跳及前面所有链路所预留的资源,当基站收到NACK反馈,则在预留的资源块上进行数据包重传。
5、根据权利要求4所述的集中式调度的多跳中继下行***中的HARQ方法,其特征在于:所述中继站接收下行数据包后,在下一紧接的时隙采用放大转发或者解调转发的模式转发给下一跳。
CN2007101733866A 2007-12-27 2007-12-27 集中式调度的多跳中继下行***中的harq方法 Expired - Fee Related CN101471756B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN2007101733866A CN101471756B (zh) 2007-12-27 2007-12-27 集中式调度的多跳中继下行***中的harq方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2007101733866A CN101471756B (zh) 2007-12-27 2007-12-27 集中式调度的多跳中继下行***中的harq方法

Publications (2)

Publication Number Publication Date
CN101471756A true CN101471756A (zh) 2009-07-01
CN101471756B CN101471756B (zh) 2011-05-25

Family

ID=40828900

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007101733866A Expired - Fee Related CN101471756B (zh) 2007-12-27 2007-12-27 集中式调度的多跳中继下行***中的harq方法

Country Status (1)

Country Link
CN (1) CN101471756B (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011020233A1 (zh) * 2009-08-17 2011-02-24 上海贝尔股份有限公司 多跳中继通信***中对下行数据传输控制的方法和装置
WO2011020314A1 (zh) * 2009-08-21 2011-02-24 富士通株式会社 中继节点、时分双工通信***及通信方法
CN102014498A (zh) * 2010-09-19 2011-04-13 电子科技大学 一种基于两跳中继站无线通信的传输方法
WO2012106842A1 (zh) * 2011-02-11 2012-08-16 富士通株式会社 一种数据传输方法、无线通信***、目的节点和中继节点
RU2574612C2 (ru) * 2009-08-21 2016-02-10 Фудзицу Лимитед Ретрансляционный узел, система дуплексной связи с временным разделением и способ осуществления связи
WO2018082073A1 (zh) * 2016-11-04 2018-05-11 华为技术有限公司 一种资源调度方法、调度节点、及被调度节点
WO2019148884A1 (zh) * 2018-01-31 2019-08-08 深圳市民泰科电子有限公司 报文传输方法、存储介质及计算机设备
EP4209090A4 (en) * 2020-09-04 2024-02-28 Huawei Tech Co Ltd MULTI-HOP COMMUNICATIONS WITH COOPERATION OF USER EQUIPMENT (UE)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1925382B (zh) * 2005-08-29 2010-06-16 中兴通讯股份有限公司 一种混合自动请求重传的方法
CN101094241B (zh) * 2006-06-23 2011-08-03 电信科学技术研究院 混合自动请求重传的传输方法及装置

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102449944A (zh) * 2009-08-17 2012-05-09 上海贝尔股份有限公司 多跳中继通信***中对下行数据传输控制的方法和装置
CN102449944B (zh) * 2009-08-17 2015-11-25 上海贝尔股份有限公司 多跳中继通信***中对下行数据传输控制的方法和装置
WO2011020233A1 (zh) * 2009-08-17 2011-02-24 上海贝尔股份有限公司 多跳中继通信***中对下行数据传输控制的方法和装置
RU2516252C2 (ru) * 2009-08-21 2014-05-20 Фудзицу Лимитед Ретрансляционный узел, система дуплексной связи с временным разделением и способ осуществления связи
CN102474339A (zh) * 2009-08-21 2012-05-23 富士通株式会社 中继节点、时分双工通信***及通信方法
CN101997598A (zh) * 2009-08-21 2011-03-30 富士通株式会社 中继节点、时分双工通信***及通信方法
AU2010285438B2 (en) * 2009-08-21 2014-06-12 Fujitsu Limited Relaying node, time division duplex communication system and communication method
CN102474339B (zh) * 2009-08-21 2014-07-23 富士通株式会社 中继节点、时分双工通信***及通信方法
WO2011020314A1 (zh) * 2009-08-21 2011-02-24 富士通株式会社 中继节点、时分双工通信***及通信方法
RU2574612C2 (ru) * 2009-08-21 2016-02-10 Фудзицу Лимитед Ретрансляционный узел, система дуплексной связи с временным разделением и способ осуществления связи
CN102014498A (zh) * 2010-09-19 2011-04-13 电子科技大学 一种基于两跳中继站无线通信的传输方法
CN102014498B (zh) * 2010-09-19 2013-04-03 电子科技大学 一种基于两跳中继站无线通信的传输方法
WO2012106842A1 (zh) * 2011-02-11 2012-08-16 富士通株式会社 一种数据传输方法、无线通信***、目的节点和中继节点
WO2018082073A1 (zh) * 2016-11-04 2018-05-11 华为技术有限公司 一种资源调度方法、调度节点、及被调度节点
WO2019148884A1 (zh) * 2018-01-31 2019-08-08 深圳市民泰科电子有限公司 报文传输方法、存储介质及计算机设备
EP4209090A4 (en) * 2020-09-04 2024-02-28 Huawei Tech Co Ltd MULTI-HOP COMMUNICATIONS WITH COOPERATION OF USER EQUIPMENT (UE)

Also Published As

Publication number Publication date
CN101471756B (zh) 2011-05-25

Similar Documents

Publication Publication Date Title
US11239901B2 (en) Method and apparatus for cooperative wireless communications
US8155013B2 (en) Synchronized multi-link transmission in an ARQ-enabled multi-hop wireless network
US8149757B2 (en) Bandwidth efficient HARQ scheme in relay network
US8010041B2 (en) Method and system for a reliable relay-associated and opportunistic cooperative transmission schemes
CN101471756B (zh) 集中式调度的多跳中继下行***中的harq方法
CN101296060B (zh) 多跳中继网络中对混合自动重传请求突发的下行发送方法
US20080068979A1 (en) Adaptive and preemptive scheduling of transmissions
KR20080068745A (ko) 통신 시스템, 송신측 통신 장치 및 수신측 통신 장치
US20110292866A1 (en) Method and device for adjusting sleep mode of mobile station
KR20080090352A (ko) 멀티-홉 중계 표준을 기반으로 다운링크 하이브리드 자동반복 요청 패킷들을 전송하기 위한 방법, 무선 통신시스템, 유형의 기계-판독가능한 매체, 및 통신 장치
EP2234301B1 (en) A method for relaying and forwarding the feedback information in harq scene
CN101383685A (zh) 下行混合自动重传的方法、***及装置
CN102573096B (zh) 回传链路上的半持续调度方法、接收方法、***及装置
CN101296167B (zh) 一种为上行混合自动重发请求突发分配传输带宽的方法
CN102035632B (zh) 一种无线中继场景下的数据传输方法和***
CN101527621A (zh) 一种中继网络下行链到链混合自动重传请求的方法
CN101568143A (zh) 数据传输方法
CN102036383A (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
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20180820

Address after: 201411 No. 2118 Fengxin Road, Fengcheng Town, Fengxian District, Shanghai.

Patentee after: SHANGHAI JINUOSHI AUTO PARTS CO.,LTD.

Address before: 200050, 32 tower, Zhaofeng building, 1027 Changning Road, Changning District, Shanghai.

Patentee before: SHANGHAI RESEARCH CENTER FOR WIRELESS COMMUNICATIONS

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20190603

Address after: 200120 118, 20, 1-42 Lane 83, Hongxiang North Road, Wanxiang Town, Pudong New Area, Shanghai.

Patentee after: Shanghai Yan Jing Information Technology Co.,Ltd.

Address before: 201411 No. 2118 Fengxin Road, Fengcheng Town, Fengxian District, Shanghai.

Patentee before: SHANGHAI JINUOSHI AUTO PARTS CO.,LTD.

CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20110525