专利名称：协作基站上行链路的混合arq机制的制作方法
技术领域：
本发明涉及一种执行网络接入节点与用户终端之间的反馈过程的方法和适合执行这种方法的网络接入节点以及相应用户终端。
背景技术：
一般能够在若干基站接收一个用户终端的上行链路传输(多点接收)，但是通常单个基站控制那个终端的上行链路传输。按照传统方式，那个传输的预计接收方是这个控
制基站。例如，在UMTS中，采用一种表示为宏分集的技术。NodeB间宏分集(软切换)意味着，在多于一个基站处接收和检测信号，并且在中心节点(在UMTS的情况下，是在无线电网络控制器(RNC))处利用来自所有所涉及基站的相关信息。通过NodeB内宏分集(更软切换)，在全部由同一基站提供服务的不同小区中接收的信息在那个特定基站内部被组合和利用。一种新兴技术是利用来自不同基站(协作基站)的所接收信号。与NodeB间宏分集相似，这降低块错误率，并且提高传输的谱效率。但是，NodeB间宏分集要求涉及UE，而协作基站对于终端而言是透明的。在3GPP中，正将LTE高级BS协作论述为eNB间协调多点传输和接收(CoMP)，例如在以下文献中规定3GPP TR 36. 814，第三代合作伙伴项目；技术规范组无线电接入网；E-UTRA物理层方面的进一步发展，VO. 3. 1，2009年1月。按照这个文献，还对于LTE高级论述eNB内CoMP。其中协作基于逻辑上属于同一 eNB或者甚至同一小区的多个天线。这些天线可在地理上分开。通过eNB内CoMP，来自不同天线的信号无需在基站之间交换。但是，天线与基站之间的信息交换也引入延迟。由于基站或者基站中的多个小区的小区控制器通常在物理上分开，所以它们之间的信息交换引入某个延迟。取决于小区控制器之间的连通性和部署，延迟可能是例如大约几微秒至数毫秒。现有技术无线接入系统通常在链路层采用自动重复请求机制、例如混合自动重复请求(HARQ)机制，以便提高系统的谱效率。这种机制使用从数据接收方发送到数据发送方的反馈消息，以便在先前传输失败时触发重传。增量冗余和Chase合并是防止这类传输错误的两种典型策略。为了使ARQ和/或HARQ反馈的传输成本和延迟为最小，现有技术ARQ/HARQ机制采用信号(从发送方到接收方的)传输与(从接收方到发送方的)ARQ/HARQ反馈的传输之间的固定定时关系。固定定时取代的传送信号与对应反馈之间的其它参考、例如序列号，这要求明显更多的传输资源。如上所述，现有技术无线电ARQ/HARQ协议通常假定ARQ/HARQ协议的固定和恒定往返时间(RTT)。其示例是如MAC协议规范(3GPP TS E-UTRA MAC规范36. 321)中定义的 LTE中的HARQ协议。对于LTE FDD，HARQ RTT为8ms，参见图1中的第1传输块与冗余形式之间的时间。对于LTE TDD,HARQ RTT根据TDD配置以及根据其它定时方面而改变，但也是预先确定的。对于LTE还规定，HARQ反馈需要在一定数量的TTI (或者等效地为子帧)之后被发送。例如，对于LTE FDD，反馈需要在传输之后的4个TTI被发送，参见图1。这表示对于上行链路HARQ协议操作存在严格的定时限制。如果协作基站的概念将在LTE中实现，则HARQ定时对于物理上分开的接收方(基站或地理上分开的天线/小区)之间的传输和处理延迟提出非常严格的延迟要求。具有极低延迟的连接(例如专用光纤)通常成本极高，而廉价解决方案不能满足HARQ定时要求。图2和图3示出LTE FDD的上下文中的协作BS的消息序列图的示例。图2中，服务基站(BS)向支持基站(BS)发送对支持的请求，此后，传输的接收 (Rx)在服务BS和支持BS中发生。在接收到传输之后，支持BS处理该信号，并且响应服务 BS。特别是预计响应消息的传递(信息和/或IQ数据传递)是费时的。在已经接收到响应(信息传递)的情况下，服务BS需要组合它自己的接收和支持BS的接收(处理步骤)。 然后，HARQ反馈由服务BS在4个TTI之后传送。取决于实际实现，请求之前的潜在后续请求和附加处理(虚线所示)也耗费时间。按照图3，主要接收器(主要RX)和协作接收器(comp RX)在对所传送数据进行解码方面协作。在TTI n-1中的上行链路(UL)调度之后，准予传输，并且对协作的请求在TTI η被发送给协作接收器。在TTI η+4，数据传输发生，此后，所接收信号的处理(例如A/D转换、FFT等)必须在两个接收器中发生(TTI η+5)。然后，IQ数据按照协作过程来传递，并且发生处理、解码等。在TTI η+8(即，按照HARQ协议所规定的数据传输之后的4个ΤΤΙ)， 发送反馈、即确认(ACK)或否定确认(NACK)。因此，在大多数情况下不可能使用协作基站的概念，因为采用基站之间通常所使用的传输基础设施、例如微波链路、以太网、DSL、E1/T1等无法满足延迟限制。注意，与本文的示例中所述的、对于不同传输系统可能是不同的TTI的数量无关，在任何情况下，时间限制通过所述反馈过程引入。
发明内容
本发明的目的是克服所述问题，特别是允许协作基站的概念的使用，同时采用反馈过程、例如HARQ反馈过程。按照本发明，提供一种执行网络接入节点与用户终端之间的反馈过程的方法，其中包括收集支持信息并且将传输块的传输延缓到收集了支持信息和/或进行了关于是请求新传输还是重传的判定，以及提供一种在从用户终端接收传输块的传输的网络接入节点中控制反馈过程的方法，其中包括使用户终端将传输块的传输延缓到接收到用于对这个或前一个传输块进行解码的支持信息和/或进行了关于是请求新传输还是重传的判定。按照本发明，还提供一种网络接入节点，包括接收器，用于从用户终端接收传输块的传输；发射器，用于将消息发送给用户终端；以及接收器，用于接收支持信息，所述网络接入节点适合执行上述方法。此外，提供一种用户终端，包括发射器，用于向网络接入节点发送传输块的传输；以及接收器，用于从网络接入节点接收消息，所述用户终端可配置成在多点接收环境中延缓传输块的传输。
通过在附图中作为非限制性实例所示的对具体但非排它的实施例的详细描述，本发明的其它特性和优点将变得更为明显，附图包括图1示出LTE FDD上行链路的HARQ定时方案；图2是示出协作基站的上下文中的LTE FDD的上行链路HARQ定时方面的信令图；图3示出协调多点传输和接收(CoMP)中的通信流程；图4示出移动通信网络中的示范CoMP环境；图5示出采用传输的延缓的协调多点传输和接收(CoMP)中的通信流程；图6示出采用协作的HARQ操作；图7示出采用TTI成束(TTI bundling)的HARQ操作的示例；以及图8示出采用协作的增强HARQ操作的示例。
具体实施例方式可使用下列缩写词
PDCCH物理下行链路控制信道
PHICH物理HARQ指示符信道
C-RNTI小区无线电网络临时标识符
HARQ混合自动重复请求
MAC媒体接入控制
TTI传输时间间隔
UE用户设备
FDD频分双工
TDD时分双工
RB资源块
BS基站
eNB增强(演进)NodeB
NDI新数椐指示符
CoMP 协调多点传输和接收本文所述的方法、网络接入节点和用户终端能够用于无线通信系统中，其中发送方传送数据单元，多个接收器尝试接收该数据单元并且将其转发给控制接收器，由此提高控制接收器能够成功地对该数据单元进行解码的概率。该系统还包括反馈机制(例如混合 ARQ机制)，所述反馈机制将关于所接收数据单元的成功或不成功接收的反馈从控制接收器返回给发送方。无线通信系统可以是WCDMA、WiMAX或LTE或者任何其它无线电系统。发送方可以是用户终端，并且接收可在同一基站(BQ的多个小区处或者在不同基站的小区处发生。在任何情况下，接收信号的装置可在物理上分开。执行反馈过程的上述方法基于如下思路在已经选择用于基站之间的协作的某个 HARQ过程中将传输块的传输延缓到支持基站已经提供支持信息以及服务基站已经利用这个信息并且判定是请求新传输还是重传。当(起服务基站的作用的)一个单一 BS从一个或多个地理上分散的(起支持基站的作用的)接收器或天线接收经延迟的信号时，相同原理能够适用。上述方法可在与支持网络节点、接收器或天线协作的服务网络节点中执行，其中从与服务网络节点关联或者位于其中的接收器或天线采集传输块的信息的第一部分，并且从支持网络节点、接收器或天线之一采集传输块的信息的第二部分。正如本领域的技术人员已知，与网络节点关联或者属于网络节点的天线可在物理上与网络节点分开并且例如通过光纤链路连接到这个网络节点。这种分开的天线可在逻辑上被看作处于关联网络节点之内。所述反馈过程尤其可以是HARQ过程。反馈(HARQ)过程的延缓提供足够时间来接收和处理支持信息。在处理信息之后， 重新开始反馈(HARQ)过程操作。这允许显著地增强传输质量。例如，块错误率能够降低，并且谱效率或系统容量能够提高。正如下面更详细地进一步说明，反馈过程的延缓可通过特别是当采用HARQ过程时发送肯定确认来实现。该方法还可包括接收和处理支持信息，并且在支持信息的处理之后重新开始反馈过程。可考虑在尚未收集支持信息的情况下开始传输块的解码；在这种情况下，仅当没有支持信息的解码不成功时，才必须延缓反馈过程。每个反馈过程可使用多个传输块。在这种情况下，同一传输块能够在多个连续TTI 中传送。在协作传输和处理正进行的同时交织第二传输块的传输会是有利的。相应地，例如通过交织两个或更多传输块的传输，因所述延缓而未使用的传输资源可用于另一个传输块的传输。作为补充或替代，可在第一反馈过程中延缓传输块的传输，并且因所述延缓而未使用的传输资源用于第二反馈过程的传输。在这种情况下，所述第一反馈过程可由第一用户终端来传送，而所述第二反馈过程可由第二用户终端来传送。另外，可交织来自一个用户终端的多个反馈过程。在任何情况下，在所述支持信息的传输和处理正进行的同时，可在已经延缓第一传输块时交织第二传输块的传输。对于反馈(HARQ)过程和/或传输块的交织，尤其给出下列可能性1.(来自一个单一用户终端的)一个单一反馈(HARQ)过程的多个传输块的交织，2.来自一个单一用户终端的不同反馈(HARQ)过程的多个传输块的交织，以及3.来自不同用户终端的(不同反馈(HARQ)过程的)多个传输块的交织。在所有情况下，术语“多个”可包括两个或更多中的任何数量。当交织不同反馈 (HARQ)过程时(在情况2和3中)，可包括两个或更多过程。
交织一般允许延迟反馈过程的执行，因而延长可用于接收和处理支持信息的时间，以便对一个传输块的信息进行解码，同时留下较少或者没有留下未使用的传输时间间隔。在第二情况下，因此，一个用户终端遇到较高总数据速率，而在第三情况下，单个用户终端所遇到的数据速率不一定得到提高，而是更有效地使用(例如无线电网络小区的)传输介质的传输资源。当然，也可采用三种情况的组合或者其子集的组合。当使用交织时，可选地任一个传输块或两个传输块能够在单个传输时间间隔 (TTI)中传送。这例如可用于MIMO设定。此外，(例如对于协作情况)能够提供控制多个(例如两个)传输块的传输的控制信令。还能够提供允许对多个(例如两个)传输块和/或将使用单个反馈(HARQ)过程来交织的不同(例如两个)传输块的每个进行寻址的(PDCCH)信令。可考虑提供发信号通知应当发送新传输还是重传的标志和/或允许对任一个传输块进行寻址的标志。用户终端和网络接入节点可在两个传输块之间自主地切换。这例如可在使用MIMO 设定时提供。此外，同一传输块可在多个连续传输时间间隔(TTI成束)中传送。传输块在多个连续传输时间间隔中的这种传输隐式地延迟同一传输块的重传。这允许服务节点接收和处理支持信息，并且进行关于是请求新传输还是重传的判定。当然，这种TTI成束还可与交织相结合；在这种情况下，两个或更多传输块的束 (各属于一个反馈(HARQ)过程)可再次按照上述情况之一来交织。还提出，协作基站交换来自多个接收基站的取样复信号值，以便允许更加增强的信号处理，参见 Hoymann、Falconetti、Gupta 的“Distributed Uplink Signal Processing of Cooperating Base Station based on Sample Exchange" (ICC conference,Dresden, Germany, 2009年6月)(在本申请的优先权日期之后发表)。备选地，基站交换编码位的编码软信息或者编码位，参见 Falconetti、Hoymann, Gupta 的 “Distributed Uplink Macro Diversity for Cooperating Base Stations" (International Workshop on LTE Advanced, Dresden, Germany, 2009年6月)(在本申请的优先日期之后发表)。LTE调度和HARQ互配成使得如果无线电接入节点(eNB)知道具有可用于传输的数据的用户终端(UE)，则它发送上行链路准予(例如PDCCH上行链路准予)，以便发信号通知该UE关于执行传输的时间和方式。待使用的HARQ过程捆绑到这个(PDCCH)准予的定时。UE在上行链路准予中指配的无线电资源上发送传输块，然后等待HARQ反馈，并且继续监听(PDCCH)是否有另外的准予或指配。具体来说，对于LTE FDD, UE在数据传输之后的第四TTI中监听PHICH和PDCCH。另外的细节能够从3GPP 36.213 E-UTRA MAC规范中得到。通过eNB间CoMP(协作工作)，服务基站向相邻基站(支持BS)发送对支持的请求。这个请求可在永久性的基础上或者按上行链路传输。请求的定时不是非常时间关键的， 但它应当相当及时到达，以便允许支持基站接收预计传输，即，它必须在相应TTI中监听相应无线电资源。当传输发生并且支持基站(例如eNB)对数据进行高达预期等级的处理(例如 FFT、解调、解码等)时，它将所请求信息发送给服务基站(eNB)。这能够是IQ数据、编码软位或者甚至是已解码数据。LTE HARQ协议按照如下方式来指定如果服务基站(eNB)在PHICH信道上发送 HARQ ACK，则对应HARQ过程不执行重传，除非对应PDCCH准予对此忽略并且请求重传。这意味着，隔离的ACK通知HARQ过程将相关信息、即传输块和状态变量保存在缓冲器中。这允许在稍后时间点重新开始这个HARQ过程，S卩，实现HARQ过程的延缓。具体来说，发信号通知重传的PDCCH上行链路准予重新开始这个HARQ过程的操作。备选地，请求新传输的PDCCH准予引起HARQ缓冲器刷新以及对应状态变量的重置。此后，这个HARQ过程用于新数据的传输。在LTE中，eNB (服务基站)可始终能够发送延缓上行链路HARQ过程的ACK。已知的是，当接收ACK时，UE不刷新其HARQ过程，因为ACK可能是NACK (ACK-NACK错误)。eNB可故意发送ACK，只是为了延缓HARQ过程(例如当重传会与RACH、寻呼或测量间隙冲突时)。另外的细节例如能够从3GPP规范36. 321 (E-UTRA MAC规范)和36213 (E-UTRA物理层规程)中得到。示范CoMP环境如图4所示。在这里，各具有所指配的若干天线A1至A4(BS1)和/ 或A5和A6 (BS2)的两个基站BS1和与用户终端UE进行通信。基站BS1和将被看作是网络接入节点，并且在LTE的情况下例如可以是eNB。相应天线A1至A6充当用户终端UE 所传送的数据(传输块)的接收器，以及充当发送给用户终端UE的消息(例如控制信令、 反馈消息等)的发射器，并且当然还用于发送给用户终端UE的有效载荷数据。如图4所示，各基站可具有所指配的若干天线(虚线所示)，但是，还有可能的是， 各基站仅具有一个天线，例如基站BS1的天线A2和基站的天线A50基站BS1和通过与上述传输基础设施对应的通信链路来连接，如虚线所示，它可以是例如微波链路、以太网、DSL、E1/T1等。用户终端UE还配备有充当到一个或多个基站的上行链路中的数据(传输块)的发射器以及充当来自基站的数据、信令和其它消息的接收器的天线A 。本领域的技术人员会理解，本文所使用的术语“发射器”和“接收器”不一定仅包括天线，而是还可包括用于生成和/或感测将要传送和接收的电磁信号的、可能具有相应功率放大器等的电路，并且还可包括至少用于对那些信号的基本处理(例如调制/解调、滤波、编码/解码等)的部件，它可包括硬件结构以及其上运行的软件功能。为了清晰起见， 附图中省略了这些元件的再现。此外，这些元件可至少部分地与相应天线定位在一起，或者可分布在天线与所指配基站之间。各天线可定位在相应基站处或相应基站之内，或者可定位成与其分离，从而产生地理上分散的天线，如图4所示。在图4所示的示例中，(指配给基站BS1的)天线A2、A3和(指配给基站BS2的)A5 处于用户终端UE的接收/传输范围之中，并且因而能够从这个用户终端UE接收数据(传输块)。在这个示例中，基站BS1控制与用户终端UE的通信以及多点接收和协作的过程，并且因此可被看作是控制或服务基站或者网络节点。这个事实如相应天线与用户终端UE之间的箭头所示，它在(指配给基站BS1的)天线A2、A3的情况下是双向的，S卩，在基站BS1与用户终端UE之间，发生两个方向上的通信，而它对于(指配给基站路2的)天线A5是单向的，即，仅发生从用户终端UE到基站的传输。当然，这种情况不一定是静态的，而是另一个基站、例如基站可能例如在用户终端UE移动时接管对过程的控制，并且于是成为控制或服务基站或者网络节点。
服务基站BS1经由通信链路(虚线)从不同源、即从直接指配给它的天线A2和A3 以及从基站接收与所传送数据(传输块)有关的信息。至少从基站所接收的信息可被看作是支持信息。当然，如果没有涉及基站BS2,而是基站BS1从指配给它自己的多个天线、例如天线 A2和A3接收与用户终端UE所传送的传输块有关的信息，则本文所述的过程也可适用。在这种情况下，经由这些天线中的一个或多个天线所接收的信息可被看作是支持信息。下面将假定已经按照图2和图3请求协作。另外，(例如通过PDCCH准予)已经触发数据传输，并且发生该传输。已经由所涉及基站接收来自UE的传输。大家还会理解，基础设施不允许在HARQ协议的延迟预算(例如对于LTE FDD小于:3ms)之内发送支持信息， 因为还需要一些时间用于控制节点中的处理。要注意，这些假设将不是限制本发明的范围， 它们而是用于便于描述以下所述的实施例。图5示出与图3相似的协调多点传输和接收(CoMP)中的通信流程。但是，在这种情况下，来自支持基站(comp RX)的支持数据(IQ数据)没有由控制或服务基站(主要RX) 在HARQ过程中提供充分反馈所需的时间之内接收。因此，由于服务基站不能够对传输块的信息(TTI n+4的数据传输)成功解码，所以在所示示例中它通过向用户终端发送肯定确认 (ACK)，使用户终端延缓当前反馈(HARQ)过程中的传输。当然，这种延缓还可能通过其它方式来引起，例如通过送往用户终端的关于基站之间的协作发生并且因此若非明确要求否则必须延缓所有传输的通知或者通过专用信令。在第一实施例(实施例1)中，服务基站(例如在PHICH上)向终端发送HARQ ACK, 而与实际接收的成功无关，参见图5和图6。基于HARQ ACK,UE不执行对应HARQ过程的重传。但是，它将数据保存在HARQ缓冲器中，并且调整这个HARQ过程的状态变量(例如递增对HARQ传输进行计数的变量(CURRENT TX NB))。与(延缓的)HARQ操作并行，服务基站(eNB)从一个或多个支持基站接收支持信息，并且执行对本地接收的信息和支持信息的联合处理。这例如能够是在解码过程中使用来自所有源的编码软位。另一个可能性是，来自所有源的IQ数据用于解调并且得出编码软位，编码软位然后被馈入信道解码器中。一旦处理已经进行，则能够判定传输是否正确接收。在后一种情况下，可向移动终端请求另一个重传。按照示范参数，协作(包括后续传输的潜在解码、调度)必须在11个TTI之内完成，参见图6。在任何情况下，这时正确的HARQ反馈在PHICH上发送，在成功接收的情况下为 ACK，而在不成功接收的情况下为NACK。另外，发送请求重传、下一个传输或者对这个终端不进行请求的对应PDCCH上行链路准予。从图6能够看到，在TTI 0，用户终端(UE)在上行链路(UL)上发送传输块(TB，黑方框)的初始传输，之后跟随来自基站(eNB)的、下行链路(DL)上的确认(ACK)，它被发送以便在尚未对TB完全解码时延缓HARQ过程。相应地，UE将TB保存在HARQ过程中，而在 TTI 8(空TTI，加阴影线)中不执行任何传输。在下一个TTI 2，eNB (在PDCCH DL信道上) 发送最后一个TB的准予，这意味着，(最初在TTI 0中发送的)这个TB可能没有被解码，之后在TTI 6中跟随相应第一重传(加阴影线)。此外，在下一个TTI 0，ACK接着出现，以便延缓传输，从而产生另一个空TTI 4(加阴影线)以及在TTI 8中的最后一个TB的另一个准予，它在下一个TTI 2 (加阴影线)中被第二次重传，并且在TTI 6中再次通过ACK得到应答。在这个实施例中，将描述两个示范变体1.服务基站(eNB)在没有来自支持基站的支持的情况下开始对数据进行解码。如果对数据成功解码，则发送HARQ ACK和潜在地发送PDCCH上行链路准予，以便请求新传输。 如果数据没有基于在服务基站处所接收的信息成功地被接收，则服务基站(eNB)在从支持基站(接收器)所接收的信号及时变为可用时尝试对它进行使用。如果它不能准时可用， 则它发送HARQ ACK，但是没有伴随PDCCH上行链路准予。由此，服务基站(eNodeB)在下一个往返时间通过在解码成功时对新数据传输或者否则对重传提供上行链路准予，来重新激活被延缓的HARQ过程。2.服务基站(eNB)在开始处理所考虑的HARQ过程之前等待支持数据，S卩，它在接收到支持信号之前不尝试对它自己的接收进行解码。如果支持信息的传输超过HARQ定时限制，则在PHICH上发送HARQACK，以便延缓HARQ过程。服务基站(eNodeB)在下一个往返时间通过在解码成功时对新数据传输或者否则对重传提供上行链路准予，来重新激活被延缓的HARQ过程。这个实施例的实现不要求对实际LTE标准的任何变更。该机制能够在eNB中实现， 而在UE实现中不需要变更。在上述变体2中，反馈在传输之后始终是ACK ；因此ACK实际上不提供任何信息。 如果UE通过某种形式的配置知道基站之间的协作应用于其传输，则反馈可能被省略。通知 UE关于该协作的对应信令需要包含在RRC信令、PDCCH信令或者其它信令机制中(例如用于这个目的的特定物理控制信道)。如果需要甚至更多时间用于允许协作，则这在所述实施例中也是可能的。HARQ过程的重新开始能够在与所考虑的HARQ过程对应的任何子帧处通过PDCCH准予来调用。在那种情况下，与非协作地服务的UE相比，BS应当将协作中的UE配置成在刷新该过程之前具有更大数量的最大HARQ重传。这个实施例的限制可能在于，在延缓对应HARQ过程的同时，TTI无法由给定UE使用(在第二变体中，每个第二 TTI为空)。但是，服务基站(eNB)可向其它UE指配空资源块 (RB)。这会提高小区谱效率，但是不会提高特定用户所遇到的性能。当没有其它UE具有可用于传输的数据或发射功率时，这种方式除了降低的小区间干扰(在被延缓的TTI中没有干扰)之外不提供任何其它增益。在另一个实施例(实施例2)中提出另一个标准化特征、即TTI成束，以便获得协作的时间。TTI成束的目的是增强小区边缘UE的性能。允许这类UE在多个、例如4个连续 TTI中传送同一传输块，而无需等待HARQ反馈。TTI成束降低信令开销与用户数据的比率。 类似地，具有受限发射功率的UE能够增加每个用户数据位的能量，并且因而增加小区边缘位率。通过TTI成束，仅对于该束的最后一个TTI、例如第4个TTI预计HARQ反馈。与常规传输相似，HARQ过程能够通过传送ACK来延缓。在该束的第一 TTI之后的一定数量、例如12个TTI传送请求最后一个TB的重传的调度准予或者请求下一个TB的准予。如果服务基站(eNB)传送NACK或者如果它传送最后一个TB的准予，则再次作为例如4个TTI的束，在初始传输之后的另一一定数量、例如16个TTI之后重传该TB。可对与HARQ延缓模式相结合的TTI成束起杠杆作用，以便获得协作的时间。与第一实施例中相似，服务基站(例如在PHICH上)向终端发送HARQ ACK，而与实际接收的成功无关，参见图7。但是，UE将数据保存在HARQ缓冲器中。同时，服务基站(eNB)从一个或多个支持基站接收支持信息，并且执行协作。按照以上所使用的示范数量、第一传输之后的 12个TTI，如果协作解码失败，则服务基站(eNB)能够请求重传最后一个TB，参见图7。如果它正确接收到数据，则服务基站(eNB)能够请求下一个TB或者对这个终端不进行请求。 对于这个实施例，服务基站(eNB)具有8ms进行协作。如图7所示，在TTI 0，TB被传送，并且在TTI 1至3自主地被重传。TTI 7中的 ACK延缓该HARQ过程，因为服务eNB仍然不可能对TB进行解码，并且仍然等待支持信息。 在下一个TTI 2，最后一个TB的准予在DL PDCCH信道上发送，之后跟随TTI 6至9中的重传(加阴影线)。当再次不可能及时对TB完全解码时，另一个ACK在下一个TTI 3中发送， 之后跟随TTI 8中的新TB的准予(加阴影线)，指示实际上可能对前一个TB进行解码。相应地，在删除前一个TB的同时，下一个传输在后续TTI 2至5中接着出现。与第1实施例相比，第二实施例的优点在于，没有TTI保持为未使用，但是协作的时间稍微更短(例如与Ilms相比的8ms)。延缓模式的一个备选方案可能是，eNB在接收到TTI的束之后始终传送NACK而不是ACK。如果协作解码实际上失败，则UE将重传该束而无需附加信令(这是良好的)。如果协作解码成功，则服务基站(eNB)可能通过发出下一个TB的调度准予(其中具有所切换的 NDI位)，来请求下一个TB。如果协作解码成功并且服务基站(eNB)已经发出准予，但UE缓冲器为空，则UE将只是发送指示没有余下数据的缓冲器状态报告。TTI的束未被使用(这可能是不太优选的)。上述实施例的优点之一在于，它们能够在当前LTE标准中实现。但是，第2实施例基于TTI成束，TTI成束通过分配多个连续TTI来限制调度灵活性。此外，当前标准、例如 E-UTRA物理层规程36. 213将TTI成束限制到最多3个资源块的小的分配和QPSK调制。这些限制可能使它成为不良覆盖条件下小区边缘UE的感兴趣备选方案。但是，它在具有小的小区的部署中可能不太适合，其中甚至小区边缘用户也取得高位率，并且预计因上行链路 CoMP而取得甚至更高的位率。第1实施例的效应在于，至少在需要协作的情况下，没有使用 UE的一个传输时机，这可能导致非最佳性能。以下实施例(实施例3)能够被看作通过增强解决方案来克服第1实施例中的未使用的TTI的问题。这个实施例在每个HARQ过程使用多个(例如两个)传输块，这允许在协作传输和处理正进行的同时交织其它传输块的传输。因此，这个解决方案具有还增加(例如在FDD 的情况下加倍)HARQ RTT的可能，但是能够通过这个实施例来利用(如实施例1中发生的) 未使用的TTI。这个解决方案要求对应控制信令到位。从下行链路的LTE中的MIMO传输模式了解每个HARQ过程具有两个传输块的概念。其中，一个或两个传输块能够在单个TTI中传送。到目前为止没有规定上行链路多流传输。用于控制信令以便控制协作情况的两个传输块的传输的所需方式的示例为信令(例如PDCCH信令)必须允许对将使用单个HARQ过程来交织的两个传输块的每个进行寻址。这可能涉及发信号通知应当发送新传输还是重传的标志(例如NDI标志) 和/或允许对任一个传输块进行寻址的标志。备选地，如果例如由RRC相应地来配置，则UE和eNB可在两个传输块之间自主地切换。通过这些方式，对于如图8所示的所考虑HARQ过程，有可能在两个传输块之间进行交替。按照图8，交织两个传输块TBl和TB2。在TTI 0，传送TB1，之后跟随TTI 4中的 TBl的ACK，这延缓TBl的HARQ过程，并且在这种情况下伴随着TB2的准予。这个准予之后， 在TTI 8，TB2的初始传输发生，同时TBl保存在HARQ过程的缓冲器中。在下一个TTI2，发送TB2的ACK (延缓这个HARQ过程)连同TBl的传输的准予一起，这在TTI 6中发送(第 1重传，同时TB2保存在缓冲器中)。在下一个TTI 0，发送TBl的ACK (再次延缓这个HARQ 过程)；由于没有发送另外的准予，所以可能对TB2已经成功解码，并且下一个TTI 4保持为空。此外，没有对TBl成功解码，使得在TTI 8，发送TBl的新准予，重复进行延缓、解码等的过程。能够看到，又在这种情况下，在对TB2解码时，TTI保持为空，而对TB1，另一个重传是必要的。即使在图8中未示出，当然也可以想到，在这种情况下，另一个传输块(TB3，未示出)的传输可能由基站(eNB)发起，以便避免使TTI为空。通过所述过程，交织的不同TB 能够源自单个用户终端或者源自两个或更多不同用户终端。这例如可由基站按照通常调度来进行，或/和如果第一用户终端除了尚未成功解码的一个(一些)之外没有留下要传送的TB，并且它因而对原本未使用的TTI转换到第二用户终端时进行。显然，本领域的技术人员非常清楚并且可易于在没有背离本发明的范围的情况下进行若干修改。因此，权利要求书的范围不受说明书中以示例形式给出的说明或优选实施例限制，相反，权利要求书将包含存在于本发明中的具有可获得专利的新颖性的全部特征， 其中包括由本领域的技术人员看作是等效的所有特征。
权利要求
1.一种在从用户终端接收传输块的传输的网络接入节点中控制反馈过程的方法，包括使所述用户终端将传输块的传输延缓到接收到用于对这个或前一个传输块进行解码的支持信息和/或进行了关于请求新传输还是重传的判定。
2.如权利要求1所述的方法，其中，所述网络接入节点从至少一个支持网络节点、接收器或天线接收所述支持信息，并且从与所述服务网络节点关联或者处于其中的接收器或天线采集所述传输块的信息的第一部分，并且从所述至少一个支持网络节点、接收器或天线采集所述传输块的信息的第二部分。
3.如权利要求1或2所述的方法，还包括接收和处理所述支持信息，并且在所述支持信息的处理之后重新开始所述反馈过程。
4.如权利要求1至3中的任一项所述的方法，其中，在尚未接收到所述支持信息的情况下开始所述传输块的解码，并且仅当没有支持信息的所述解码不成功时，才使所述用户终端延缓传输。
5.如权利要求1至4中的任一项所述的方法，其中，因所述延缓而未使用的传输资源用于另一个传输块的传输。
6.如权利要求5所述的方法，其中，在第一反馈过程中延缓传输块的传输，并且因所述延缓而未使用的传输资源用于第二反馈过程中另一个传输块的传输。
7.如权利要求6所述的方法，其中，控制所述第一反馈过程用于由第一用户终端进行的传输，而控制所述第二反馈过程用于由第二用户终端进行的传输。
8.如权利要求6所述的方法，包括交织来自一个用户终端的多个反馈过程。
9.如权利要求5至8中的任一项所述的方法，其中，下列之一一个传输块和两个传输块，在单个传输时间间隔中传送。
10.如权利要求5至9中的任一项所述的方法，还提供用于控制多个传输块的所述传输的控制信令。
11.如权利要求5至10中的任一项所述的方法，还提供允许对将使用单个反馈过程来交织的所述多个传输块中的每个传输块进行寻址的信令。
12.如权利要求1至11中的任一项所述的方法，包括发信号通知关于应当发送新传输还是重传。
13.如以上权利要求中的任一项所述的方法，其中，所述同一传输块在多个连续传输时间间隔中传送。
14.如以上权利要求中的任一项所述的方法，其中，所述反馈过程是HARQ过程。
15.一种执行接入网节点(基站)与终端(用户设备)之间的HARQ过程的方法，包括 将传输块的传输延缓到已经收集所述对应支持信息并且进行了基于这个信息的、关于请求新传输还是重传的判定。
16.如权利要求15所述的方法，在与支持网络节点、接收器或天线协作的服务网络节点中执行，其中，从所述服务网络节点中的接收器或天线采集所述传输块的信息的第一部分，并且从所述支持网络节点、接收器或天线之一采集所述传输块的信息的第二部分。
17.如权利要求15或16所述的方法，还包括接收和处理所述支持信息，并且在所述支持信息的处理之后重新开始所述HARQ过程。
18.如权利要求15至17中的任一项所述的方法，在每个HARQ过程还使用多个传输块， 并且在所述协作传输和处理正进行的同时交织第二传输块的所述传输。
19.如权利要求1至18中的任一项所述的方法，其中，通过向所述用户终端发送肯定确认，来使所述用户终端延缓所述传输块的传输。
20.如权利要求1至18中的任一项所述的方法，其中，通过配置设定来使所述用户终端延缓传输块的传输。
21.—种网络接入节点，包括接收器，用于从用户终端接收传输块的传输； 发射器，用于向用户终端发送消息；以及接收器，用于接收支持信息；所述网络接入节点适合执行如以上权利要求中的任一项所述的方法。
22.—种用户终端，包括发射器，用于向网络接入节点发送传输块的传输；以及接收器，用于从网络接入节点接收消息；所述用户终端可配置成在多点接收环境中延缓传输块的传输。
全文摘要
执行网络接入节点与用户终端之间的反馈过程的方法包括收集支持信息并且将传输块的传输延缓到收集了支持信息和/或进行了关于请求新传输还是重传的判定。该方法可在与支持网络节点、接收器或天线协作的服务网络节点中执行，其中从服务网络节点中的接收器或天线采集传输块的信息的第一部分，并且从支持网络节点、接收器或天线之一采集传输块的信息的第二部分。
文档编号H04L1/18GK102428669SQ200980159442
公开日2012年4月25日 申请日期2009年7月27日 优先权日2009年3月20日
发明者C·霍伊曼, H·魏曼, L·法尔科内蒂, M·迈耶 申请人:瑞典爱立信有限公司