专利名称：用于上行链路多点协作信令的混合自动重复请求操作的方法和系统的制作方法
技术领域：
本公开涉及多点协作(CoMP)发送和接收，以及具体涉及多点协作发送和接收中的混合自动重复请求信令。
背景技术：
用于移动网络的多点协作发送和接收涉及从多个网元与单个移动设备或用户设备(UE)的通信。网元可以是基站、演进的通用陆地无线接入网(E-UTRAN)节点B(eNB)、eNB 内的小区或者其他类型的网络节点。例如，在高级长期演进(LTE-A)中，将支持多点协作发送和接收。对于上行链路传输，当UE向第一和第二网元都发送分组时，如果任一网元正确接收来自UE的分组，则认为该分组已经被成功接收。在混合自动重复请求(HARQ)系统中，UE在一个时间段中发送一个HARQ传输，以及当接收到来自网元的否定应答时，UE在后续时间段发送第二或后续HARQ传输。当与基站有关的两个网元接收到分组时，它们均尝试解码该分组。然而，为了网元正确地协作，需要在两个网元之间传送分组状态。该握手发生在回程链路上，并且为了上行链路多点协作传输正确操作，回程链路上的握手必须发生。在当前的HARQ系统下，该回程链路信令所需的时间可能不足以正确协调网元。
参考附图将更好地理解本申请，在附图中图1是示出在用户设备和网元之间的示例性多点协作通信的框图；图2是示出长期演进版本8的HARQ定时的定时图；图3是示出用于UL CoMP的异步HARQ定时的顶视图；图4是UE上的用于UL CoMP的异步HARQ定时的过程的流程图；图5是网元上的用于UL CoMP的异步HARQ定时的过程的流程图；图6是示出用于UL CoMP的同步HARQ定时的顶视图；图7是示出用于协作UE的HARQ处理索引的的框图；图8是网元上的用于提供针对UL CoMP的同步HARQ定时的过程的流程图；图9是示出用于使用倍数2的UL CoMP的扩展的同步HARQ定时的定时图；图10是示出扩展的用于使用倍数3的UL CoMP的扩展的同步HARQ定时的定时图；图11是示出扩展的用于使用倍数4的UL CoMP的扩展的同步HARQ定时的定时图；图12是UE上的用于解码HARQ响应的过程的流程图；图13是UE上的用于解码HARQ响应的另一过程的流程图；图14是示出使用了终止指示符的用于UL CoMP的HARQ定时的定时图15是示出使用了终止指示符或重传的用于UL CoMP的HARQ定时的定时图16是示出用于UL CoMP的HARQ定时的定时图，其中仅向一个网元发送重传；
图17是示出用于UL CoMP的HARQ定时的定时图，其中仅向一个网元发送重传，并且重传使用了终止指示符；
图18是示出用于UL CoMP的HARQ定时的定时图，其中交替地向网元发送重传；
图19是示出示例性的用于虚拟小区的多点协作通信的框图20是示例性用户设备的框图。
具体实施方式
下文关于长期演进(LTE)和高级长期演进(LTE-A)系统提供本公开。然而，这并不意味着对本发明的限制，LTE和LTE-A的使用仅是示例性的。此处提供的方法和系统可以容易地与其他多点协作发送和接收系统一起使用。
下文关于演进的通用陆地无线接入网(E-UTRAN)节点B(eNB)多点协作发送和接收提供了本公开。然而，这并不意味着对本发明的限制，并且eNB的使用仅是示例性的。此处提供的方法和系统可以容易地与其他类型的网元(诸如基站、eNB中小区或者其他类型的网元)一起使用。
现在参考图1，图1示出了示例性的多点协作传输系统的框图。在图1中，用户设备(UE) 110与演进的通用陆地无线接入网(E-UTRAN)节点B(eNB) 120通信。在图1的示例中，eNB 120是服务eNB。
UE 110还与第二 eNB 130通信，在图1的示例中，eNB 130是协作eNB。
如图1中所示，从UE 110向eNB 120和eNB 130 二者发送数据。这通过箭头140 和142表示。此外，在图1的示例中，接收自eNB 120的控制信息如箭头150所示。然而， 这并不旨在作为限制，并且在一些情形下还可以从eNB 130接收数据或控制。
利用图1的示例，如果UE 110需要发送数据分组，则eNB 120和eNB 130都尝试接收该数据分组。如果eNB 120和eNB 130中的任一个成功接收并解码了分组，则认为已经成功接收该分组。
eNB 120和eNB 130的协作在回程链路上完成，回程链路在图1中由线160示出。 该链路可以用若干方式实现，包括光连接、有线连接和无线连接。
现在参考图2，图2示出了 LTE版本8的HARQ定时图。在图2中，eNB 210与UE 220通信。
如图2中所示，在子帧0中，eNB在箭头230所示的物理下行链路控制信道 (PDCCH)上发送控制信息。在子帧4中，UE 220经由箭头232所示的物理上行链路共享信道(“PUSCH” )发送传输1 (初始传输)。
如果eNB能够解码HARQ传输1，则其在子帧8中发送肯定应答(ACK)，如箭头234 所示。相反，如果eNB不能够解码HARQ传输1，则其在子帧8中发送否定应答(NACK)作为消息234。
如果UE接收到子帧8中的NACK，则其在子帧12中发送HARQ传输2 (重传)，如箭头^6所示。
本领域普通技术人员应该理解，图2中的单个eNB 210允许上述定时。基于上面的内容，HARQ信令要求每4个子帧传输一次信息，这得到近似4毫秒的时间来评估接收的信息，确定应该发送ACK还是NACK，以及准备ACK或NACK以供发送。然而，当两个eNB用于 CoMP时，通常4毫秒的时间不足以通过回程链路在eNB之间进行协调。在实践中，12-20毫秒是针对这种操作的更合理的估值。为了允许多点协作通信，以及更具体地为了允许多点协作传输中的混合自动重复请求，此处提供了各种方法。针对上行链路CoMP的异步HARQ在第一实施例中，上行链路HARQ使用异步操作模式。现在参考图3。在图3的实施例中，经由eNB 310和UE 320之间的控制信道(由箭头330所示) 发送控制指示。这在子帧0中完成。在子帧4中，UE 320经由PUSCH(由箭头332所示)发送HARQ传输1。第一 eNB 310和第二 eNB 312都接收该传输，并且都尝试对其进行解码。在子帧4和子帧η之间(其中η是变量)，eNB 310和eNB312经由回程链路传送 ACK/NACK状态，并且还可能传送新的调度信息。在图3的实施例中，η是14个子帧。然而， 这并不旨在作为限制，并且可以静态地或动态地使用或配置其他η值。在图3的示例中，eNB 310是服务eNB。一旦eNB 310和eNB 312之间出现协作， 则eNB 310发送新数据指示符作为控制信道传输(如箭头340所示)的一部分。响应于在340的控制消息中接收到其值指示重传(即，LTE版本8中的不触发 (toggle))的新数据指示符，则如箭头342所示UE 320在子帧n+4中向两个eNB发送HARQ 传输2，在图3的示例中，子帧n+4是子帧22。应该理解，箭头340的消息中的新数据指示符可以命令也可以不命令在子帧n+4 中重传。如果成功接收HARQ传输1 (箭头33 ，则HARQ传输2 (箭头34 将包含新数据而不是重传。参考图4，从UE的角度说明上述方案。图4的过程开始于步骤410，并且前进到步骤412，在步骤412中UE接收数据或 PDCCH上的控制传输。响应于接收到PDCCH上的控制指示，过程前进到步骤414，在步骤414中在PUSCH
上发送第一传输。然后，过程前进到步骤416，在步骤416中UE等待接收控制指示。应该理解，步骤 416中的检查确定是否已经接收数据指示符。例如，图3中，控制指示符被包括在箭头340 所示的消息中。如果还没有接收到任何控制指示，则过程回到步骤416，并且继续等待控制指示。一旦在步骤416中已经接收到控制指示，则过程前进到步骤418，在步骤418中进行检查，以确定新数据指示符是否指示应该重传该传输。如果是，则过程前进到步骤420，在步骤420中，重传发生；并且如果不是，则过程前进到步骤422，在步骤422中可以开始发送另一数据分组。从步骤420出发或从步骤422出发，该过程回到步骤416继续等待控制指示。应该理解，上述实施例中的解决方案要求必须将HARQ处理索引添加到下行链路控制信息(DCI)格式0 (或等价地，新的DCI格式)，以允许对HARQ处理的协作。而且，eNB需要发送更多的物理下行链路控制信道消息，其可能涉及控制信道开销的增加。然而，上述方案允许可变的回程定时。因此，如果回程使用很繁重，定时可以变化，并且上述方案适应该变化。
而且，在上述方案中，可能不一定需要物理混合HARQ指示符信道(PHICH)。在LTE 版本8中，PHICH用于从eNB向UE信号通知HARQACK/NACK信息。
现在参考图5。图5示出了关于eNB的上述实施例。图5的过程开始于步骤510， 并且前进到步骤512，在步骤512中在物理下行链路控制信道上发送控制指示符。
在后一时间，从UE接收数据，如步骤514所示。
在步骤514中从UE接收数据需要与任意其他eNB进行协作，这在步骤516中示出。
基于协作(如步骤516所示)，在步骤518中在PDCCH上向UE发送控制指示。应该理解，如果在协作之后所有eNB已经发现它们都没有成功解码数据，则控制指示指示重传是必需的。
从步骤518出发，该过程前进到步骤520，并且结束。
针对UL CoMP 的异步 HARQ
在另一实施例中，可以以同步HARQ定时模型来扩展HARQ定时。现在参考图6。
在图6的实施例中，服务eNB 610和协作eNB 612都与UE 620通信。在子帧0中， 服务eNB 610发送PDCCH(控制)。此后，UE在子帧4中经由PUSCH向服务eNB 610和协作 eNB 612都发送HARQ传输1，如箭头632所示。服务eNB 610和协作eNB 612都接收HARQ 传输1并且尝试对其进行解码。在子帧4和子帧c之间(其中c是固定常数，其可以是数字方式指定的，或者可以经由上层信令半静态地配置)，服务eNB 610和协作eNB 612经由回程链路传送ACK/NACK状态，并且还可能传送新的调度信息。
在子帧c处，经由PHICH向UE 620发送ACK或NACK。，如消息6；34所示。如果UE 620接收到子帧c处的NACK，则UE在子帧c+4中发送HARQ传输2 (如箭头636所示)。
在图6的示例中，c被指定为18，并且因此基于子帧18处接收的NACK，重传将发生在子帧22处。这并不旨在作为限制，并且其他c值是可能的。
本领域普通技术人员应该理解，在一些实施例中，HARQ传输的相对定时可以是 LTE版本8的定时的倍数。例如，可以在HARQ传输1之后M子帧发生HARQ传输2。
此外，如果HARQ传输2的相对定时是16，则其将有利于不同UE在同一 HARQ处理中的协作，而不需要附加的信令。
现在参考图7。图7示出了多个UE的情况下针对UL同步CoMP的LTE定时。
具体地，示出了上行链路处理索引，其中不同UE的传输发生在指定的索引处。第一 UE 710可以在索引0处通信。第二 UE 720可以在8个子帧之后通信。然后，第一 UE可以在这之后的8个子帧处通信，依此类推。这样的优点是可以在不使用附加信令的情况下完成针对不同UE的协作。
根据上面的实施例，PDCCH开销与LTE版本8相一致，原因是仅存在图6的第一 PDCCH消息630，而不需要附加的PDCCH信令(诸如上文参考图3描述的PDCCH信令)。
此外，不需要对DCI格式0进行任何改变。
在又一实施例中，如本领域普通技术人员应该理解的，回程链路可能不能被严格控制，其可能需要灵活的同步定时。或者将必须保守地提供该定时以应对回程链路的最坏情形，或者eNB可以能够基于回程负载改变同步HARQ定时。例如，这种对同步定时的改变可以通过无线资源控制(RRC)信令来完成。
现在参考图8。图8示出了用于重新配置HARQ定时的流程图。具体地，图8的过程开始于步骤810，并且前进到步骤812，在步骤812中进行检查以确定回程负载是否要求定时调整。本领域普通技术人员应该理解，回程负载可以允许定时调整，取决于负载级别来增加或减小HARQ定时。例如，在步骤812中，可以进行检查以确定回程负载是否大于预定阈值，在回程负载大于预定阈值的情况下HARQ定时可能需要增加。相反，如果HARQ定时在过去已经增加，则一旦回程负载落到预定阈值之下，则可以减小HARQ定时。
在其他实施例中，HARQ定时可以取决于不同的回程负载级别。因此，可以存在多于2个HARQ定时选择。例如，如果存在非常小的负载，则HARQ定时可以是第一定时级别； 如果存在中等的回程负载，则HARQ定时可以稍有增加；以及如果存在繁重的回程负载，则 HARQ定时可以进一步增加。本公开并不旨在限于两个或三个定时级别。
从步骤812出发，如果检查确定回程负载级别要求对定时进行调整，则过程前进到步骤814，在步骤814中既在eNB上配置新HARQ定时，还通过信令将该新HARQ定时发送给UE。此外，在一些实施例中，该信令还出现在服务eNB和协作eNB之间的回程上，以确保两个eNB都具有相同的定时。
从步骤814出发，过程回到步骤812，继续检查回程负载级别是否要求定时调整。
本领域普通技术人员应该理解，用于上行链路CoMP UE的PHICH区域可能与非 CoMP UE的PHICH区域相冲突。为此，对于上行链路CoMP UE，可能需要不同的PHCIH区域。 备选地，eNB可以为上行链路CoMP UE分配不同的解调参考信号循环移位值，以避免冲突。
对已扩展的同步定时(其中，对传输进行了扩展)的使用可能导致HARQ处理数目的增加。具体地，对于Rel-8信令，上行链路中可以有效地存在8个HARQ处理。参考上面的图6，需要c个HARQ处理。在图6的示例中，因此需要18个HARQ处理。例如，为了利用整个时域，针对子帧4-21中的每个子帧将需要单独的HARQ处理。然而，因为HARQ处理标识符不在上行链路中进行显式的信号通知，且软缓冲区位于eNB中，所以增加HARQ处理的数目可能不会成为问题。
使用现有UL HARQ设计的扩展同步HARQ定时
另一备选实施例在eNB处对UL调度强加约束，使得可以扩展针对具体HARQ处理的HARQ处理使用周期。在一个实施例中，该扩展可以是当前8毫秒UL同步HARQ周期的倍数。该扩展通过扩展UL HARQ周期(可将其视为有效的往返时间)来允许重用现有UE结构，而不要求任何的改变。因此，用于UL CoMP回程通信和组合的附加时间变得可获得。
现在参考图9。图9示出了与特定子帧920关联的UL HARQ处理索引910。在图9 的示例中，如图上部标记的，存在8个UL HARQ处理。这些HARQ处理以8毫秒的同步周期长度进行重复。
在子帧920中示出了采样子帧号。
UL处理910和子帧920之间的箭头示出了在具体子帧中使用的特定HARQ处理之间的联系。仅在阴影标记的子帧中允许来自具体UE的PUSCH传输或重传。此外，可以看出， 在每个16毫秒的周期内，每个UL HARQ处理仅使用一次，以及PUSCH传输通常仅在一系列子帧中每两个子帧出现一次。因此，例如，UL HARQ处理O在子帧O中发送，以及接下来在子帧16中发送。此外，UL HARQ处理1直到子帧9才发送，因此留下子帧1为空。上面的结果是将UE的最大可获得峰值数据速率减为一半。此外，扩展的UL HARQ 周期可以导致由系统的无线链路组件所引入的更大的等待时间。然而，可能的传输时机的规则间隔(假设UL授权是由eNB提供的)允许到达UE的层2子层的任何新分组潜在地以最小的延迟进行发送。针对UE的每个PUSCH传输，eNB将总是需要在PHICH上信号通知ACK，原因是非自适应重传(其由PHICH上发送的NACK进行触发)将是不可能的。任何所需的HARQ重传可能必须是自适应的，并且通过PDCCH上的DCI消息(例如，DCI 0)来支配。参考图10，该图示出了与图9相似的例子，其中UL HARQ周期是M毫秒。在图10， PUSCH传输或重传在一系列子帧的每三个子帧发生一次，并且因此UE的最大可获得峰值速率将被降到正常值的1/3。因此，在图10中，UL HARQ处理索引1010被链接到子帧1020。 可以看出，HARQ处理0在子帧0和子帧M上发送。此外，在传输UL处理索引0和UL处理索引3之间存在两个(UE)不使用的子帧。此外，参考图11，图11示出了针对32毫秒的UL HARQ周期的类似示例，其将允许相当大的余量来处理用于eNB间通信的回程延迟。此处，PUSCH传输或重传平均而言在一系列子帧中每四个子帧发生一次。然而，UE的最大可获得峰值数据速率将被降到正常值的 1/4。因此，在图11中，UL HARQ处理索引1110被链接到子帧1120。此外，如图11所示，HARQ处理0在子帧0和子帧32上发送。在上面的图9、10、11的示例中，利用诸如介绍的那些方案调度的UE将不在每个子帧中发送PUSCH。然而，可以向不同的UL CoMP UE指派针对其UL HARQ周期的不同开始点。 这样的指派可以通过下述方式半静态地出现经由高层信令，或者基于一些UE标识参数， 诸如国际移动订户标识(IMSI)或者小区无线网络临时标识符(C-RNTI)。利用每个小区内的多个UE, UL资源的使用将针对每个子帧维持在近似相等的级别，而不是每几个子帧具有突然的峰值。另外，相同小区内的不同UE可以配置为取决于它们各自的需求具有不同长度的UL HARQ周期。因此，具有少量业务的UE可以能够处理32毫秒的UL周期，而需要较高数据速率的UE可以配置为具有16毫秒的UL周期。在这样的情况下，对于具有较短UL HARQ 周期的UE，协作的eNB之间的回程传输可以具有优先级，以确保可以满足调度的时间限制。在具有较长的UL HARQ周期的情况下，可能需要在eNB向UE提供的任何无线资源配置中增加UL传输尝试的数目。该量可以是第三代合作伙伴计划(3GPP)技术规范 (TS) 36. 331的第6. 3. 2章节中的MAC-MainConf ig信息元中的HiaxHARQ-iTx字段，通过引用将该规范的内容并入本文。该量提供用于UL HARQ的传输尝试的最大数目，其中传输尝试每8毫秒出现一次。 然而，如果UL HARQ周期增加，则传输尝试的有效最大数目将必须根据maxHARQ-Tx提供的值适当地进行缩放(scale)。例如，如果maxHARQ-h具有值24，但是UL HARQ周期增加到 16毫秒，则UL HARQ传输尝试的有效最大数目将是对/2或者12次传输尝试。在一个实施例中将在eNB处执行参数缩放。在该情况下，现有的UE设计不需要任何改变。例如，如果 eNB希望特定UE具有等于8的UL HARQ传输尝试的有效最大值，且UL HARQ周期是M毫秒，则eNB将UE配置为具有等于M的maxHARQ-Tx。
本领域普通技术人员应该明白，图9、10和11的方案维持了 UE的现有UL HARQ设计，并且因此可以与LTE版本8 (Rel-8)UE 一起使用。此外，取决于本地eNB回程延迟，不同配置可以用于获得不同的UL HARQ周期。
图9、10和11的方案也要求对技术规范的最小改变，并且仅有的改变是对eNB调度算法的改变。
本领域普通技术人员应该理解，图9、10和11的方案也可以与本文描述的其他方案一起使用。此外，不同UE可以使用不同方案进行配置，其可以有助于促进与Rel-SUE的后向兼容，原因是那些UE能够使用上述的解决方案，同时以后版本的UE可以配置为使用本文介绍的其他解决方案。
本领域普通技术人员应该明白，使用图9、10和11的解决方案，对具体小区的总小区容量和小区吞吐量将没有影响。然而，如上所述，给定UE的峰值可获得数据速率将被减小。此外，如上面指示的，非自适应重传是不可能的，因此潜在地将存在PDCCH上的DCI 0 信令的增加。
对Rel-8UE 的支持
上面的内容可以扩展以在长期演进(LTE)Rel_8HARQ协议的上下文内支持CoMP。 在该情况下，UE可能不知道任何协作eNB。
对于UE不知道任何协作eNB的情况，服务eNB在来自协作eNB的ACK/NACK状态可用时使用该ACK/NACK状态。本领域普通技术人员应该理解，这样的机制可能导致一些无线资源被浪费，原因是协作eNB可能在解码分组，同时服务eNB可能分配另外的资源进行重传。
对同步和异步HARQ的混合支持
在一些实施例中，既操作在同步HARQ也操作在异步HARQ中是可能的，其中根据 Rel-8定时来设置同步HARQ。在这些实施例中，取决于其将使用CoMP、中继或为UE服务的某种其他传输技术，eNB可以配置UE使用HARQ或异步HARQ。
对于配置为使用异步HARQ的UE，UE将利用新传输格式解码PDCCH，以使得其搜索新DCI格式，即经由盲解码处理。例如，新DCI格式可以定义为DCI格式OA。该新DCI格式可以具有用于指示HARQ处理的附加比特。
UE辅助的协作
在又一个实施例中，UE可以辅助服务eNB和协作eNB的协作。这可以通过服务eNB 和协作eNB都向UE发送ACK或NACK来完成。
在一个实施例中，每个eNB在其位于子帧的第一正交频分复用(OFDM)符号中的小区特定PHICH资源上发送其ACK/NACK。小区特定的加扰被用于PHICH。每个eNB使用的 PHICH索引对应于UE发送的PUSCH上的UL资源块(RB)位置。UE可以首先尝试解码来自服务eNB的PHICH。如果解码出的数据是ACK，则UE不需要解码来自其他协作eNB的PHICH 信道。如果UE接收到来自服务eNB的NACK，则其可以继续解码来自其他协作eNB的PHICH， 直到接收到ACK。如果UE从来自协作eNB的所有PHICH信道都没有接收到ACK，则可以开始重传。
现在参考图12。图12的过程开始于步骤1210，并且前进到步骤1212，在步骤1212 中从UE向eNB发送传输。
响应于步骤1212中的传输，过程前进到步骤1214，在步骤1214中接收HARQ响应。从步骤1214出发，过程前进到步骤1216，在步骤1216中解码服务eNB的PHICH。 在步骤1218中，进行检查以确定服务eNB的HARQ响应是否是ACK。如果是，则过程前进到步骤1220并且结束。否则，过程前进到步骤1230，并且解码来自协作eNB的PHICH的HARQ 响应。从步骤1230出发，过程前进到步骤1232，在步骤1232中做出检查以确定HARQ响应是否是ACK。如果该响应是ACK，则过程从步骤1232前进到步骤1220并且结束。否则，过程前进到步骤1240以检查是否正在使用其他协作eNB。本领域普通技术人员应该理解，CoMP可以包括2个或更多的eNB。如果存在更多的eNB，则过程前进到步骤1230，并且针对下一个协作eNB解码PHICH。从步骤1240出发，如果没有任何其他协作eNB存在，则过程前进到步骤1250，在步骤1250中对该传输进行重传，并且过程然后返回步骤1214以检查HARQ响应。在又一实施例中，每个eNB在针对DL CoMP定义的特定控制信道区域上发送ACK/ NACK。在该特定控制区域，为每个eNB预留单独的PHICH空间。每个eNB在其预留的PHICH 空间内使用的PHICH索引对应于UE发送的PUSCH上的UL资源块位置。CoMP特定的ID被用于对PHICH进行加扰。在又一个实施例中，每个eNB在DL CoMP区域内的相同资源上发送其ACK/NACK。 来自协作节点的传输在与所指派的UL传输的位置对应的相同资源上叠加。UE仅在两个eNB 都发送NACK时才重传。这可以看成是4状态ACK，其中2个比特用于该ACK/NACK。每个eNB 可以针对其ACK/NACK使用相同的发射分集方案。例如，每个eNB可以使用2-tx SFBC(空频分组码)作为发射分集，以及因此对于UE而言，需要使用双STBC(空时分组码)接收器来从每个eNB接收这样的ACK/NACK。在又一实施例中，每个eNB可以在PHICH信道的不同重复期间发送其ACK/NACK。例如，服务eNB可以在PHICH重复#1和#3期间发送其ACK/NACK，同时协作eNB可以在PHICH 重复#2期间发送其ACK/NACK。在又一个实施例中，每个eNB仅在正确接收UL传输或者不需要立即的非自适应重传时，才发送其ACK。不发送NACK。如果UE没有检测到ACK，则UE进行重传。在该情况下， 如果eNB都正确接收数据，则针对ACK获得宏分集合并增益。应该理解，上面的备选实施例可以与图12的实施例一起使用。具体地，在针对每个eNB预留单独的PHICH空间的实施例中，可以如上提供地那样使用图12的过程。此外，其中eNB在不同PHICH信道的不同重复期间发送其ACK/NACK的实施例也可以使用上述图12的过程。参考图13，描述了其中eNB仅在正确接收UL传输或者不需要立即的非自适应重传时才发送ACK的实施例。具体地，图13的过程开始于步骤1310，以及前进到步骤1312，在步骤1312中从UE向eNB发送传输。接着，在步骤1314中UE检查是否接收到ACK。应该理解，选项是没有收到任何 ACK、收到一个ACK、或者收到两个ACK。在收到两个ACK的情况下，针对ACK获得宏分集合
并增 ο如果没有收到任何ACK，则过程前进到步骤1320，并且在UE处发起重传。过程回到步骤1314，以检查是否收到针对重传的ACK。
从步骤1314出发，如果收到ACK，则过程前进到步骤1330并且结束。
对于上述实施例中的每一个，UE可以在PUCCH发送终止指示符，以终止HARQ传输。 这在下文中参考图14示出。终止指示符提供用于指示不需要回程通信来传送ACK/NACK状态的空中(over-the-air)解决方案，由此允许稍微地更紧凑的定时。
参考图14，UE 1410与服务eNB 1420和协作eNB 1422通信。在子帧0中，服务 eNB 1420发送PDCCH (控制)。这通过消息1430示出。
在子帧4中，UE经由PUSCH发送HARQ传输1，如消息1432示出。服务eNB 1420 和协作eNB 1422都接收HARQ传输1并且尝试对其进行解码。
在子帧8中，服务eNB 1420和协作eNB 1422都向UE发送ACK/NACK状态。这通过消息1434和1436示出。
在子帧12中，UE 1410向服务eNB 1420、协作eNB 1422或这二者发送HARQ终止指示符1440。
本领域普通技术人员应该理解，子帧12被用作示例，并且取决于精确的定时要求，有可能在子帧10或11中发送HARQ终止指示符1440。
在一个实施例中，如果UE收到来自服务eNB 1420或协作eNB 1422的ACK，则HARQ 终止指示符1440被设为1。如果没有收到任何ACK，则HARQ终止指示符1440被设为0。
在子帧12和子帧16之间，服务eNB 1420和协作eNB 1422经由回程链路传送新调度信息。如果任一 eNB都不需要适配或修改传输资源，则不需要在子帧16中发送任何东西，以及基于子帧8中接收的ACK/NACK信息，UE传输HARQ传输2，如消息1450所示。
应该理解，如果eNB 1420或eNB 1422需要适配传输资源，则eNB1420或eNB 1422 可以在子帧16中发送新DCI消息。(在图14中未示出)。
上面关于图12、13和14的实施例不依赖于回程通信来传送ACK/NACK状态，其有利于一致的定时。
在又一实施例中，如果UE确定两个eNB都发送NACK，则UE不需要发送HARQ终止指示符。
现在参考图15。在图15中，UE在子帧12中发送第二 HARQ传输，如图15的消息 1510所示。剩余编号与上面的图14类似。
对于子帧12中的消息1510，如果没有eNB发送ACK，则UE重传第二 HARQ传输以及终止指示符。另一方面，如果UE确定至少一个eNB发送ACK，则UE在子帧12中仅发送 HARQ终止指示符。在一些实施例中，在子帧12中，如果没有eNB发送ACK，则UE仅发送第二 HARQ传输。
从eNB的角度看，如果eNB发送ACK，则其仅监听HARQ传输指示符，原因是其已经正确解码了数据。如果eNB发送NACK，其监听HARQ终止指示符以确定另一 eNB是否已经正确接收了分组。如果eNB没有检测到任何HARQ终止指示符，则eNB对重传进行解码。
此外，从每个eNB的角度看，如果eNB发送ACK，eNB知道它可以将子帧12的资源重用于另一 UE,因为它知道UE在原始传输之后的8毫秒将不进行重传。如果eNB发送 NACK,则存在另一 eNB发送ACK/NACK的可能性，在该情况下UE可以针对传输2发送PUSCH 也可以不针对传输2发送PUSCH。在该情况下，发送NACK的eNB可以选择当在虚拟多入多出(MIMO)中时有可能使用不同的参考信号来将该资源调度给另一 UE，或者可以选择保守方式，以及在另一 eNB发送ACK的情况下让该资源保持为未使用，对相邻小区造成较小的干扰。对于eNB选择针对子帧12发送另一授权的情况，eNB仍可以检查HARQ终止指示符以确定另一 eNB处发生的情况，由此允许eNB智能地解码子帧12处的PUSCH。可能需要定义用于PUCCH HARQ终止指示符的索引。该索引可以使用与Rel_8相同的基于PDCCH控制信道单元(CCE)位置的映射，以及可以位于不同的区域中。在另一方案中，与Rel-8中的半持久性调度(SPS)或HARQ-ACK重复类似，eNB可以利用无线资源控制(RRC)信令或物理层信令明确地指派所需的PUCCH资源。而且，可能存在将HARQ传输指示符和PUSCH传输组合的方式。应该理解，上面提供了 LTE Rel_8HARQ定时，其降低了 HARQ往返时间。此外，该解决方案保持了现有的(Rel-S)HARQ处理结构。针对初始传输的CoMP和针对重传的非CoMP在另外的解决方案中，CoMP可以用于初始HARQ传输，而非CoMP用于其他传输(例如，重传)。在第一实施例中，CoMP用于新数据传输，诸如通过SPS授权或DCIO定义并且利用新数据指示符(NDI)标记触发的新数据传输。重传仅由服务eNB来处理。与全部CoMP的情形相比，将CoMP仅用于新数据传输允许稍微改进定时。下面参考图16。在图16中，UE 1610与服务eNB 1620和协作eNB1622通信。在子帧O中，服务eNB 1610针对SPS授权发送PDCCH (控制)，如箭头1630所示。在子帧4中，UE经由PUSCH发送HARQ传输1，分组1，如消息1632所示。服务eNB 1620和协作eNB 1622都接收HARQ传输1并且尝试对其进行解码。在子帧4和子帧16之间(其中，在一个实施例中子帧16的位置是固定的)，服务 eNB 1620和协作eNB 1622经由回程链路传送ACK/NACK状态，以及通过PHICH向UE 1610 传送ACK/NACK，由消息1640示出。应该理解，在上面的示例中，因为仅在服务eNB 1620处接收传输2 (由消息1650 所示)，所以不需要向协作eNB 1622传送用于HARQ传输2的调度信息。如果UE 1610在子帧16中接收作为消息1640的一部分的NACK，则UE在子帧20中提交对分组1的HARQ重传，如1650所示。在子帧M中，UE经由PUSCH向服务eNB 1620和协作eNB 1622发送分组2的HARQ 传输1，由箭头1660所示。因此，基于上面的内容，重传仅出现于eNB 1620。在一些实施例中，eNB和UE可以协商用于CoMP接收的HARQ传输的数目。例如， 使用高层信令(诸如RRC信令)，eNB和UE可以协商是否针对特定数目的HARQ传输、特定的冗余版本集合等等来使用CoMP方案。HARQ终止指示符在又一实施例中，CoMP可以用于新数据传输(SPS授权定义的那些)，以及重传由服务eNB处理。另外，UE可以向服务eNB发送HARQ终止指示符。现在参考图17，其中UE 1710与eNB 1720和协作eNB 1722通信。在子帧O中，服务eNB 1710发送PDCCH(控制)，如箭头1730所示。该示例以20ms的时间段激活SPS授权(即，每隔20ms发送新数据)。
在子帧4中，UE经由PUSCH发送分组1的HARQ传输1，如消息1732所示。
服务eNB 1720和协作eNB 1722都接收HARQ传输1并且尝试对其进行解码。
在子帧8处，eNB 1和eNB 2都向UE 1710发送ACK/NACK状态，由消息17；34和 1736所示。
在子帧12处，如果UE确定已经成功解码分组，则其向服务eNB1720发送HARQ终止指示符。这通过消息1740示出。否则，UE经由PUSCH向eNB 1720发送分组1的HARQ传输2。
在子帧16处，服务eNB 1720向UE 1710发送分组1的ACK/NACK状态，由消息1750 所示。如果UE接收NACK，则它在子帧20中向服务eNB 1720发送分组1的HARQ传输3，如消息1760所示。
在子帧M中，UE通过经由PUSCH向服务eNB 1720和协作eNB 1722都发送分组2 的HARQ传输1，开始新数据传输，如消息1780所示。
在又一方案中，当UE从服务eNB收到NACK但是从协作eNB 1722收到ACK时，UE 利用预留的PUSCH资源发送下一个数据分组的初始传输，这是因为服务eNB 1720应该为UE 1710预留资源。如果服务ΘΝΒ1720既检测到HARQ终止指示符也检测到PUSCH资源中的信号，则eNB 1720可以假设PUSCH数据代表下一个数据分组的新传输。例如，当二进制移相键控(BPSK)符号用作对终止指示符的调制时，UE 1710可以指示如下不同的情况
1 =HARQ终止，而在PUSCH中没有任何数据
0 下一个分组数据的初始传输
DTX:重传
交替的顺序
在又一实施例中，CoMP用于新数据传输(诸如SPS授权定义的那些)，以及重传由服务eNB和协作eNB以交替的顺序处理。另外，UE向服务eNB、协作eNB、或者二者发送 HARQ终止指示符。
现在参考图18。在图18中，UE 1810与服务eNB1820和协作eNB1822通信。
在子帧0中，服务eNB 1810发送PDCCH (控制)，如箭头1830所示。这以20ms的时间段激活SPS授权。
在子帧4中，UE 1810经由PUSCH向eNB 1820和eNB 1822发送分组1的HARQ传输1，如消息1832所示。
服务eNB 1820和协作eNB 1822都接收消息1832并且尝试对其进行解码。在子帧 8处，服务eNB 1820和协作eNB 1822都向UE 1810发送ACK/NACK状态，分别由消息18；34 和1836所示。
在子帧12处，如果UE 1810确定已经成功解码分组，则其向服务eNB 1820和协作 eNB 1822都发送HARQ终止指示符，分别由消息1840和1842所示。
否则，UE 1810经由PUSCH向服务eNB 1820发送分组1的HARQ传输2，作为消息 1840。
在子帧16处，服务eNB 1820向UE 1810发送分组1的ACK/NACK状态，由消息1850 所示。如果UE 1810接收NACK，则它在子帧20中向协作eNB 1822发送分组1的HARQ传输3，如消息1860所示。在子帧M中，UE通过经由PUSCH向服务eNB 1820和协作eNB1822都发送分组2 的HARQ传输1，如消息1880所示。向两个eNB交替传输的好处是两个eNB都参与传输的接收，以及调度的协作不需要与初始传输相分离。转发用于CoMP传输的分组判决信息在上面描述的解决方案中，在涉及UL上的CoMP接收的两个eNB处尝试解码分组。 如果解码不成功，则eNB可以保留分组信息，以与根据HARQ处理的将来的HARQ重传相结
口 O另外，针对给定UE的非服务eNB还可以向服务eNB转发判决信息。转发的信息可以包括软或硬比特判决、分组、符号或比特的品质因素、或者其他格式的量化判决数据。来自其他eNB的分组判决信息可能按不规则的间隔到达服务eNB，其可能在HARQ 过程中的任何时间导致正确的分组判决。因此，在一个实施例中，允许服务eNB在每个反馈时机都发送ACK/NACK响应可能是有用的。应该理解，即使服务eNB不处理最近一次UE传输的空中接收，这也可以是有用的。虚拟小区在标题为"System and Method for a Virtual Carrier for a Multi-Carrier and Coordinated Multi-Point Network Operation” 的美国专利申请 NO. 12/537，867 中介绍了虚拟载波和虚拟小区的概念，在此通过引用将其内容并入本文。虚拟载波是被通报 (advertise)在一个eNB中存在但实际上是由其他eNB发送和接收的载波。这允许实现高效使用资源的部署。当不同节点和虚拟载波被用于UL和DL传输时，可以创建虚拟小区。例如，UE可以在UL上向其服务节点进行发送。服务节点可以在协作节点的载波上针对DL传输调度UE, 该协作节点的载波对于服务节点而言是虚拟载波。下面参考图19示出该例子。参考图19。在图19中，UE 1910与服务eNB 1920和eNB 1922通信。针对两个 eNB创建虚拟小区1930。对于虚拟小区1930中的UL HARQ，存在关于图1到18的实施例概述的相同问题。 具体地，服务eNB 1920对UL传输进行解码，并且协作eNB 1922经由PUCCH和用于ACK/NACK 的PHICH控制UE。因此，服务eNB 1920必须经由回程向协作eNB 1922发送分组的ACK/ NACK状态。该操作与CoMP操作类似，并且因此上面概述的解决方案可以同等地应用于虚拟小区的情况。上面的方案可以实现在任何用户设备和任何网元(诸如演进的节点B)上。图20是示出能够与本发明的设备和方法一起使用的UE的框图。UE 2000通常是具有语音和数据通信能力的双向无线通信设备。取决于所提供的确切的功能，无线设备例如可以称为数据消息递送设备、双向寻呼机、无线电子邮件设备、具有数据消息递送能力的蜂窝电话、无线互联网设备、或者数据通信设备。在支持双向通信的UE 2000中，其将合并通信子系统2011，包括接收机2012和发射机2014，以及关联部件，诸如一个或多个嵌入的或内部的天线元件2016和2018、本地振荡器(LO) 2013、以及处理模块320，诸如数字信号处理器(SDP)2020。通信领域的普通技术人员应该明白，通信子系统2011的具体设计将取决于设备旨在操作于的通信网络。
网络接入要求还将取决于网络2019的类型发生变化。LTE UE可以要求订户标识模块(SIM)卡，以便在LTE或LTE-A网络中操作。SIM接口 2044通常与卡槽类似，SIM卡可以向盘或PCMCIA卡那样插入该卡槽和从中取出。SIM卡可以保存密钥配置2051，以及其他信息2053，诸如标识以及订户相关的信息。
当网络注册或激活过程已经完成，UE 2000可以在网络2019上发送和接收信号。 如图20中所示，网络2019可以包括多个天线，与UE进行通信。这些天线继而连接到eNB 2070。
天线2016通过通信网络2019接收的信号被输入接收机2012，接收机2012可以执行诸如信号放大、下变频、滤波、信道选择等公共的接收机功能，并且在图20的示例系统中还执行模数变换。对接收到的信号的模数转换允许在DSP 2020中进行更复杂的通信功能，例如解调和解码。以类似的方式，由DSP 2020对将要发送的信号进行处理(例如包括调制和编码)，然后提供给发射机2014以进行数模转换、上变频、滤波、放大并经由发射天线2018发送到通信网络2019上。DSP 2020不仅处理通信信号，还提供对接收机和发射机的控制。例如，可以通过DSP 2020中执行的自动增益控制算法来自适应地控制应用到接收机2012和发射机2014中的通信信号的增益。
UE 2000通常包括处理器2038，其控制设备的总体操作。通过通信子系统2011 执行通信功能，包括数据和语音通信。处理器2038还与其他设备子系统交互，诸如显示器2022、闪存20M、随机存取存储器(RAM) 2026、辅助输入/输出(I/O)子系统20 、串口 2030、一个或多个键盘或小键盘2032、扬声器2034、麦克风2036、其他通信子系统2040 (诸如短程通信子系统)、以及一般地标为2042的任何其他设备子系统。串口 2030可以包括 USB端口或本领域已知的其他端口。
图20中示出的一些子系统执行通信相关的功能，而其他子系统可以提供“常驻” 或者设备上的功能。显然，一些子系统，如键盘2032和显示器2022，例如可以用于通信相关的功能(如输入用于通过通信网络传输的文本消息)和设备常驻功能(如计算器或者任务列表)。
处理器2038使用的操作系统软件一般存储在永久性存储器中，该永久性存储器如闪存20M，可以备选地是只读存储器(ROM)或类似的存储单元(未示出)。本领域技术人员应该明白，操作系统、专用设备应用、或者其部分，可以临时加载到易失性存储器(如RAM 2026)中。接收的通信信号也可以存储在RAM 20 中。
如图所示，闪存20M可以分成不同的区域，用于计算机程序2058和程序数据存储 2050、2052、20M和2056。这些不同的存储类型指示每隔程序可以针对它们的自身数据存储要求分配闪存20M的一部分。除了其操作系统功能之外，处理器2038还支持UE上的软件应用的执行。通常在其制造期间在UE 2000上安装控制基本设备操作的预定应用集合， 例如至少包括数据和/或语音通信应用。也可以后续或动态安装其他应用。
一个软件应用可以是个人信息管理器(PIM)应用，该应用具有组织和管理与UE的用户相关的数据项的能力，该数据项例如但不限于电子邮件、日历事件、语音邮件、约会、以及任务项。自然地，UE上将有可用的一个或多个内存存储器以利于存储PIM数据项。这样的PIM应用通常具有经由无线网络2019发送和接收数据项的能力。在一个实施例中，经由无线网络2019将PIM数据项与主计算机系统存储和/或与主计算机系统关联的UE用户的对应数据项无缝地集成、同步、和更新。还可以通过网络2019、辅助I/O子系统20 、串行端口 2030、短程通信子系统2040、或者任何其他合适的子系统2042将另外的应用加载到 UE2000上，以及由用户安装到RAM 2026或者非易失性存储器(未示出)中，以供微处理器 2038执行。这样的应用安装方面的灵活性提高了设备的功能，并且可以提供增强的设备上功能、通信相关的功能、或者二者兼有。例如，安全通信应用可以支持电子商务功能以及要使用UE 2000执行的其他这种金融交易。
在数据通信模式下，通信子系统2011处理接收的信号，如文本消息或者网页下载，以及将其输入微处理器2038，微处理器238优选地进一步针对基本属性处理接收的信号，以输出给显示器2022或备选地输出给辅助I/O设备2(^8。
UE 2000的用户还可以编写诸如电子邮件消息之类的数据项，例如使用键盘2032 结合显示器2022和可能的辅助I/O设备2038来编写，其中键盘2032可用是全字母数字键盘或电话类型的小键盘。这样编写的项于是可以通过通信子系统2011在通信网络上传输。
对于语音通信，UE 2000的总体操作是类似的，区别在于接收的信号将输出到扬声器2034，以及用于发送的信号由麦克风2036生成。还可以在UE 2000上实现备选的语音或音频I/O子系统，如语音消息记录子系统。尽管语音或音频信号输出优选地主要通过扬声器2034来完成，但是还可以使用显示器2022来提供对例如呼叫方的身份、语音呼叫持续时间、或者语音呼叫相关的其他信息的指示。
图20中的串口 2030通常实现在个人数字助理(PDA)类型的UE中，对于这些UE 与用户的台式计算机(未示出)的同步是期望的，但是其是是可选的部件。串口 2030将支持用户通过外部设备或者软件应用来设置首选项，以及不通过无线通信网络，而通过向UE 2000提供信息或软件下载来扩展UE 2000的能力。备选的下载路径可以例如用于通过直接并从而可靠和可信的连接将加密密钥加载到设备上，由此提供安全的设备通信。本领域普通技术人员应该理解，串口 2030还可以用于将UE连接到计算机以充当调制解调器。
其他通信子系统2040，诸如短程通信子系统，是提供UE 2000和不同系统或设备 (不一定是类似设备)之间的通信的其他部件。例如，子系统2040可以包括红外设备和关联的电路和部件，或者包括BLUETOOTH 通信模块，用于提供与支持类似功能的系统和设备的通信。子系统2040还可以用于WiFi或WiMAX通信。
此处描述的实施例是具有与本申请的技术的要素对应的要素的结构、系统、或者方法的示例。所书写的说明可以使得本领域普通技术人员能够实现和使用具有类似地与本申请的技术的要素对应的备选要素的实施例。因此，所要保护的本申请的技术的范围包括与此处描述的本申请的技术无区别的其他结构、系统或方法，并且还包括与此处描述的本申请的技术无显著区别的其他结构、系统或方法。
权利要求
1.一种用于上行链路多点协作信令的混合自动重复请求操作的方法，包括 从用户设备向多个网元发送数据分组；等待来自所述多个网元中的至少一个的控制指示；以及如果所述控制指示指定需要重传，则向所述多个网元重传所述数据分组。
2.根据权利要求1所述的方法，其中，所述控制指示是在物理下行链路控制信道上接收的。
3.根据权利要求1所述的方法，其中，所述发送还包括将混合自动重复请求处理指示符添加到控制指示。
4.一种用户设备，用于上行链路多点协作信令的混合自动重复请求操作，所述用户设备包括处理器；以及通信子系统，其中，所述用户设备配置为使用所述通信子系统向多个网元发送数据分组；等待来自所述多个网元中的至少一个的控制指示；以及如果所述控制指示指定需要重传，则向所述多个网元重传所述数据分组。
5.一种在网元处用于上行链路多点协作信令的混合自动重复请求操作的方法，所述方法包括在所述网元处接收来自用户设备的数据分组； 与接收所述数据分组的其他网元协作；当完成所述协作时，向所述用户设备发送控制指示，所述控制指示指示是否需要重传所述数据分组。
6.一种网元，用于上行链路多点协作信令的混合自动重复请求操作，所述网元配置为在所述网元处接收来自用户设备的数据分组； 与接收所述数据分组的其他网元协作；当完成所述协作时，向所述用户设备发送控制指示，所述控制指示指示是否需要重传所述数据分组。
7.根据权利要求6所述的网元，其中，所述网元是演进的通用陆地无线接入网节点B。
8.一种用于上行链路多点协作信令的混合自动重复请求操作的方法，所述方法包括 从用户设备向多个网元发送数据分组；在预定间隔之后从所述多个网元中的至少一个接收肯定应答或否定应答；以及如果收到否定应答，则向所述多个网元重传所述数据分组。
9.根据权利要求8所述的方法，其中，所述预定间隔是能够通过所述用户设备和网元之间的信令配置的。
10.根据权利要求8所述的方法，其中，将所述预定间隔选择为允许所述多个网元在回程链路上通信。
11.根据权利要求8所述的方法，其中，所述肯定应答或否定应答是通过物理混合自动重复请求指示符信道接收的。
12.根据权利要求11所述的方法，其中，所述物理混合自动重复请求指示符信道为用户设备提供利用上行链路多点协作信令的区域。
13.根据权利要求8所述的方法，其中，将所述预定间隔选择为长期演进版本8混合自动重复请求定时的整数倍。
14.一种用户设备，用于上行链路多点协作信令的混合自动重复请求操作，所述用户设备包括处理器；以及通信子系统，其中，所述用户设备配置为 从用户设备向多个网元发送数据分组；在预定间隔之后从所述多个网元中的至少一个接收肯定应答或否定应答；以及如果收到否定应答，则向所述多个网元重传所述数据分组。
15.一种用于上行链路多点协作信令的混合自动重复请求操作的方法，所述方法包括以整数倍扩展混合自动重复请求处理的周期；利用已扩展的混合自动重复请求处理的周期，从用户设备向多个网元发送数据分组。
16.根据权利要求15所述的方法，还包括基于所述网元中的至少一个提供的值，增加上行链路传输尝试的次数。
17.一种用于上行链路多点协作信令的混合自动重复请求操作的方法，所述方法包括发送数据分组；从多个网元中的每个网元接收混合自动重复请求响应； 解码来自服务网元的混合自动重复请求响应；如果来自服务网元的混合自动重复请求响应不是肯定应答，则解码来自协作网元的混合自动重复请求响应；以及如果来自协作网元的混合自动重复请求响应不是肯定应答，则重传所述数据分组。
18.根据权利要求17所述的方法，其中，对来自服务网元或协作网元的混合自动重复请求响应的解码利用了物理混合自动重复请求指示信道。
19.根据权利要求17所述的方法，其中，对来自服务网元或协作网元的混合自动重复请求响应的解码利用了控制信道区域内的物理混合自动重复请求指示信道。
20.根据权利要求17所述的方法，其中，对来自服务网元或协作网元的混合自动重复请求响应的解码利用了针对每个网元具有分开的物理混合自动重复请求指示信道空间的下行链路多点协作信令区域。
21.根据权利要求17所述的方法，还包括发送终止指示符，以信号通知不需要所述服务网元和协作网元之间的回程通信。
22.根据权利要求21所述的方法，还包括如果对来自服务网元和协作网元的混合自动重复请求响应的解码都得到否定应答，则发送第二混合自动重复请求传输而不是终止指示符。
23.根据权利要求17所述的方法，其中，所述接收仅接收肯定应答。
24.一种用于上行链路多点协作信令的混合自动重复请求操作的方法，所述方法包括向多个网元发送数据分组； 从多个网元之一接收混合自动重复请求响应；以及如果所述混合自动重复请求响应是否定应答，则向唯一一个网元重传所述数据分组。
25.一种用于上行链路多点协作信令的混合自动重复请求操作的方法，所述方法包括向多个网元发送数据分组；从多个网元中的每个网元接收混合自动重复请求响应；以及如果来自所述多个网元中的每个网元的混合自动重复请求响应是否定应答，则向唯一一个网元重传所述数据分组。
26.根据权利要求25所述的方法，还包括在所述重传之后，从所述唯一一个网元接收混合自动重复请求响应。
27.根据权利要求沈所述的方法，还包括如果来自所述唯一一个网元的混合自动重复请求响应是否定应答，则向所述唯一一个网元重传另一数据分组。
28.根据权利要求沈所述的方法，还包括如果来自所述唯一一个网元的混合自动重复请求响应是否定应答，则向与所述唯一一个网元不同的网元重传另一数据分组。
29.根据权利要求沈所述的方法，还包括 如果接收到肯定应答，则发送终止指示符。
全文摘要
本发明公开了用于上行链路多点协作信令的混合自动重复请求操作的方法和系统，在一个实施例中所述方法包括从用户设备向多个网元发送数据分组；等待来自所述多个网元中的至少一个的控制指示；以及如果所述控制指示指定需要重传，则向所述多个网元重传所述数据分组。
文档编号H04L1/18GK102498688SQ201080041344
公开日2012年6月13日 申请日期2010年9月17日 优先权日2009年9月18日
发明者房慕娴, 罗伯特·诺瓦克, 苏菲·弗利兹克, 蔡志军, 西恩·迈克尔·马克白, 许允亨, 许华, 马克·厄恩肖 申请人:捷讯研究有限公司