CN101828364A - 用于数据通信的方法和装置以及包括这种装置的通信系统 - Google Patents

Abstract

本发明提供了用于第一实例和第二实例之间的数据通信的方法和装置，该方法包括步骤：第一实例通过第三实例或者直接地向第二实例发布第一状态报告。

Description

用于数据通信的方法和装置以及包括这种装置的通信系统

技术领域

本发明涉及用于数据通信的方法和装置并且涉及包括这种装置的通信系统。

背景技术

在将来的公共陆地移动网络(PLMN)中，除常规基站(BS)之外可以部署中继节点(RN)以提供具有均匀的数据速率的无缝移动性。

3GPP LTE中所提出的在基站和用户终端之间的用户平面(user-plane)协议架构具有按照图1的结构。在基站和用户终端处的协议栈每个都包括为用户平面业务提供例如报头压缩、加密、调度、自动重传请求(ARQ)和/或混合自动重发请求(HARQ)等功能的分组数据会聚协议(PDCP)层、无线链路控制(RLC)层、媒体访问控制(MAC)层和物理(PHY)层。

在用于将来的无线接入网络(RAN)的中继增强小区(REC)拓扑结构中，一个小区可以包括一个基站和几个中继节点。中继节点可以被无线地连接到同一小区的基站。

根据特定位置和无线传播条件，小区内的用户终端可以通过中继节点连接到基站或者它可以直接连接到基站。

基本上，对于译码转发(decode-and-forward)型中继来说，可能存在其中中继节点被部署成带有或者不带有RLC层的情况(scenario)，如图2和图3所示。

如在3GPP TS 35.322-700中所标准化的那样，RLC层可以有三种操作模式，即透明模式、未确认模式(UM)和确认模式(AM)。只有确认模式包括自动重传请求(ARQ)操作。

如果在中继节点处没有RLC(子)层(参见图3)，那么RLC操作仅在基站和用户终端之间被提供。在这种情况下，RLC层ARQ操作，例如轮询的传输、状态报告和数据重发都要通过两个中继段(hop)，这使得错误恢复非常慢。

如果RLC功能在中继节点上可用(参见图2)，那么这两个中继段可以具有独立的RLCARQ操作用于本地错误恢复，这通常较快。下文中把这称作每中继段(per-hop)RLC。

但是，在从中继节点到基站的移动移交的情况下，如果选择每中继段RLC，那么在中继节点的RLC上用于特定用户终端的缓存数据将被删除并且可能不会被基站恢复，因为它们可能已经被中继节点上的RLC实体确认。因此，两种移交可能导致数据丢失：第一，在同一小区内从中继节点到基站的用户终端的移交。第二，从中继节点到另一小区(例如另一个基站)的用户终端的移交。

因此，尤其存在这样的问题：被提供给中继节点的RLC层在从中继节点到基站的移交操作期间无法在没有丢失数据风险的情况下支持快速本地错误恢复。

这个问题根据独立权利要求的特征被解决。另外的实施例由从属权利要求产生。

发明内容

为了解决该问题，提供了用于第一实例和第二实例之间的数据通信的方法，其包括以下步骤：

-第一实例通过第三实例或者直接地向第二实例发布第一状态报告。

注意到，所建议的方法可以应用于下行链路以及上行链路方向。

例如，可以应用以下类似物(analogy)：

	下行链路	上行链路
			第一实例	用户终端UT	基站BS
第二实例	基站BS	用户终端UT
			第三实例	中继节点RN	中继节点RN

特别关于移交情况，第三实例可以是服务基站并且第二实例可以是目标基站，或者反之亦然。

还应当注意，用户终端可以是各种类型的移动终端，它还可以是包括移动终端的功能的装置。移动终端也可以是用户设备UE。

本文提供的方法可应用于任意类型的通信环境，特别在3GPP或者WiMAX的情况中。

根据提供的这种方案，RLC协议可以被修正以更好地适应中继增强小区(REC)的各种需要。

在本文中特别讨论了在RLCAM操作时对REC拓扑结构的影响和对它的增强。

在一实施例中，第二实例是数据的主要发送方。

在另一个实施例中，如果第一实例之前连接到第三实例，那么第一实例直接发布第一状态报告。

这使第二实例传输轮询命令或者请求所需要的总体时间能显著地减少。它还使第二实例在移交完成后能基本上立即被通知第一实例的状态。

在另外的实施例中，第三实例是中继节点。

在下一个实施例中，第三实例是具有减少的协议栈的网络元件。

还有一实施例是第三实例包括物理层、MAC层和RLC层。

根据另一个实施例，第三实例包括物理层和MAC层。

根据一实施例，第一状态报告包括关于已经在第一实例处被接收的数据的信息。

根据另一个实施例，第一状态报告包括RLC状态报告。

还有，在另一个实施例中，第一状态报告被用于移交的目的。

根据下一个实施例，第一实例到第三实例的连接被移交到第二实例。

还有，根据一实施例，第三实例轮询第一实例的状态并将其转发到第二实例。

根据另外的实施例，第三实例将由第二实例进行的轮询中继到第一实例。

还有，根据另外的实施例，在移交完成之后，第一实例将第一状态报告发送到第二实例。

另一个实施例是第一状态报告被用于流控制的目的。

根据一特定实施例，第三实例将第二状态报告发布到第二实例。

因此，第一状态报告和第二状态报告在第二实例处可用。

还有一实施例是第二状态报告包括RLC状态报告。

根据一实施例，第三实例的缓存状态由第二实例通过利用由第一实例发布的第一状态报告和由第三实例发布的第二状态报告来确定，特别是计算。基于这种信息，第二实例可以通过提高或者降低特别地朝向第一实例的发送速率来调整第三实例的缓存状态。这特别地被称作流控制。

根据一实施例，第二实例通过调整其RLC发送窗和/或通过指示它的MAC层调度更多/更少的数据到第一实例来进行流控制。

上述的问题还由包括处理器单元的装置解决，该处理器单元被装备和/或布置使得本文所描述的方法在所述处理器单元上可执行。

根据-实施例，该装置是通信装置，特别是网络元件。

还有，根据另一个实施例，装置是用户终端、基站和/或中继节点，或者与用户终端、基站和/或中继节点相关联。

上述问题进一步由包括本文所描述的装置的通信系统解决。

附图说明

本发明的实施例在以下附图中被示出和阐明：

图4示出中继节点状态报告转发机制，其描绘了基站BS、中继节点RN和用户终端UT，其中每一个都包括特别具有MAC层和RLC层的协议栈；

图5A使服务BS(例如，中继节点RN)、用户终端UT和目标BS(例如，基站BS)之间的消息流直观化；

图5B示出了中继节点RN、服务BS和用户终端UT之间的小区内RN-BS移交的情况；

图6示出了包括3位PDU类型域的3GPP版本7的RLC状态PDU结构。

图7示出图6的PDU类型域的可能值。

具体实施方式

根据一实施例，特别描述了在确认模式(AM)中的下行链路RLC数据传输。然而，所描述的情况就上行链路数据传输而言也是可用的。

本文提供的方法特别包括以下机制：

a.通过中继节点(RN)的RLC状态报告转发；

b.用于两个中继段通信区段的知道RN缓存状态的RLC发送方侧流控制；

c.允许几个中继段，特别是所有中继段之间的均匀负载分配的多中继段系统的知道拓扑结构的状态报告；

d.直接在移交之后的即时状态报告，即移交触发的状态报告。

通过中继节点(RN)的RLC状态报告转发

为了在“RN-BS移交”期间，即在中继节点和用户终端之间的呼叫线路(call-leg)到基站和用户终端之间的呼叫线路的移交期间具有无损数据传送，基站RLC实体有利地可以被通知在用户终端处的RLC的接收状态。

这可以通过让中继节点将由用户终端发布的RLC状态报告转发回至基站来完成(为示意的目的参见图4)。

图4示出中继节点状态报告转发机制。它描绘了基站BS、中继节点RN和用户终端UT，它们每一个都包括特别具有MAC层和RLC层的协议栈。

基站BS接收由用户终端UT发布的状态报告401，其由中继节点RN转发402到基站BS。另外，基站BS接收由中继节点RN自身发布的状态报告403。

用户终端的RLC状态报告401可以由中继节点RN所发布的轮询请求触发。在基站BS处的RLC层可以(仅)轮询中继节点的RLC状态报告(两个轮询请求由图4中的虚线404和405指示)。

在基站BS侧，由中继节点RN发布的状态报告403和由用户终端UT发布的状态报告402必须被区分。这特别地可以通过在状态报告402、403的RLC报头中提供1位指示符来完成。有利地，这将仅造成对现有协议的较小修改。

在基站BS处的RLC确认模式(AM)操作仍然根据中继节点RN的状态报告发生(本地错误恢复)。然而，有利地，基站BS的RLC层不会删除已经由中继节点RN确认但是仍未被用户终端UT确认的协议数据单元(PDU)。

图5B示出小区内RN-BS移交的情况。当所述小区内RN-BS移交发生时，用户终端UT放弃它与中继节点RN的连接并且它建立起与基站BS的直接连接。

在这种情况下，中继节点RN可以为那个用户终端UT清除它的缓存，由此删除在其RLC层上的缓存数据而不管所述数据是否已经由用户终端UT确认。可能发生的是在小区内移交(HO)之前，RN将从服务BS到UT的RLC PDU重新分段。由RN造成的RLC上下文在移交之后可能不会保持(参见图5B)。

然而，基站BS可以清除其涉及与中继节点RN先前的连接的RLC上下文(计时器、发送窗等等)。由于基站BS依据从RN转发的UT状态报告而知道用户终端的接收状态，基站BS可以重新启动到用户终端UT的RLC传输，从第一未确认的PDU开始。

为了让基站BS保持对用户终端的接收状态的更新，中继节点RN可以足够频繁地轮询用户终端UT并且因此中继节点可以无显著延迟地将状态报告从用户终端UT转发回至基站BS。

作为替代，中继节点RN也可以将轮询从基站BS中继到用户终端UT，因此，当中继节点本身被基站BS轮询时，该中继节点可以向用户终端UT发起轮询请求。

作为轮询请求的结果从UT接收的状态报告可以通过数据PDU被中继节点RN独立地转发或者载运(piggyback)到基站BS。

当RN-BS移交被启动，有利地，中继节点RN可以无显著延迟地再次轮询用户终端UT以获得最新的状态报告。这个最新的状态报告被转发到基站BS。

然而，由于轮询需要通过数据PDU被传输，因此，在移交完成之前，它可能不具备充足的时间到达用户终端UT。

为了也覆盖这种情况，用户终端UT可以在移交完成之后立即将状态报告发送回至基站BS(有利地，没有显著的延时)。这也可以被称作“移交触发状态报告”并且在图5A中被描绘。

图5A使服务BS(例如，中继节点RN)、用户终端UT和目标BS(例如，基站BS)之间的消息流直观化。

目标BS通过由广播信道传递的导频序列(Pilot sequence)指示其可用性。用户终端UT发送移交请求到服务BS，服务BS依次将移交请求发送到目标BS。在移交请求已经被目标BS许可之后，它将许可确认消息发送回至服务BS。服务BS将移交命发送令到用户终端UT。

用户终端UT检查它之前是否已经被连接到中继节点(即，服务BS)。在肯定的情况，用户终端发送RLC状态报告501到服务BS，否则，它不发送这样的RLC状态报告到服务BS。

图5A特别示出了小区内移交的例子。这种由用户终端UT传递的自己发起(self-nitiated)的状态报告501为目标BS传输轮询命令502节省了时间。

因此，在移交被完成后，立即通知目标BS用户终端UT的状态。因此，特别归因于目标BS处过时的用户终端状态信息的任何重复数据分组的机会以及分组丢失被显著地减少。

如同中继节点RN状态报告转发机制，基站BS了解用户终端UT的状态，并且，有利地，可以避免基站删除任何由中继节点RN确认但是没有被用户终端UT确认的PDU。因此，在移交的情况下可以减少或者避免数据丢失。另外，每中继段RLC方案成功地保持中继增强小区(REC)中的错误恢复的效率。

应当注意，在每中继段RLC方案中，可以为在第一和第二RLC连接上传输的同一PDU保持同一RLC SN(序列号)。

此外，在两个中继段中任何一个上的RLC链接可能不独立于相应的另一中继段被重置，因为这会造成在两个中继段上的RLC状态的不一致。RLC操作可以仅被重置用于整个BS-RN-UT路径。

知道中继节点(RN)缓存状态的RLC发送方侧流控制

RLC层操作包括通过RLC发送/接收窗操作的流控制功能。

然而，在中继增强小区(REC)的情况中，正常的RLC发送窗仅仅控制从发送方RLC层到其接收方RLC层的一个单个中继段。在两个中继段上的信道状态十分不同的情况下，可能在中继节点RN上发生上溢出或者下溢出。

考虑例如图4，所描绘的第一中继段在基站BS和中继节点RN之间，第二中继段在中继节点RN和用户终端UT之间。根据该例子，应当将数据从基站BS传递到用户终端UT。

基站BS每次可能通过所述第一中继段传递太多的数据分组到中继节点RN，而中继节点RN不能以这种速率通过第二中继段转发这些数据分组。因此，在该例子中，第二中继段可能是瓶颈，造成中继节点RN缓存的上溢出。按照类似的方式，相反的情况可适用于下溢出的例子。

流控制的原理是让在中继节点RN上的RLC层具有合适大小的缓存数据PDU以避免下溢出以及上溢出的情况。

中继节点RN缓存大小依赖于由基站BS发送的数据的到达速率，并且依赖于朝向用户终端UT的该中继节点的MAC层的发送速率。

给定某一调度策略和信道状态，控制中继节点RN的缓存大小的一种可能性是控制基站BS处的发送速率。

由于基站BS接收中继节点RN的状态报告403和所转发的用户终端UT的状态报告402两者，基站BS能够基于两个状态报告402和403的区别确定中继节点RN处的缓存状态。

当中继节点RN为用户终端UT缓存了太多数据时，基站BS知道这个情况并且可以抑制以高速率向中继节点RN发送更多数据，直到这种上溢出情况得到缓解。

另一方面，基站BS也能够确定中继节点RN处的下溢出情况并且因此它可以通过增加RLC发送窗大小或者通过指示MAC层为这个用户终端UT调度更多的数据来为该特定的用户终端UT提高其发送数据速率。

将RLC缓存大小保持在合适的水平的另一好处是在RN-BS移交的情况下避免过量的重传。在这种情况下，特别地可以将更少的数据从中继节点RN缓存中删除。

其它优点

将由用户终端UT发布的状态报告转发回至基站BS的中继节点RN可具有很多好处，特别是：

-在RN-BS移交期间防止数据丢失；

-通过让基站BS了解(实际的)中继节点RN缓存状态来促进流控制。

本文提出的用于下行链路情况的相同原理适用于上行链路，根据该原理，中继节点RN将状态报告从基站BS转发回至用户终端UT。

仅一位的RLC报头扩展可以被用于实现这种功能。该单个位可以不必被加入到现有的RLC报头结构。相反，RLC报头的现有保留位可以被用于该目的。

例如，图6示出了包括3位PDU类型域的3GPP版本7的状态PDU结构(另参见3GPPTS 25.322)。该PDU类型域的可能值在图7中示出。

目前，仅定义了3个值(000，001，010)，剩余的5个值仅被保留，但是可以被用于指示该状态PDU属于中继节点RN还是属于用户终端UT。

本文提供的方法特别包括以下优点：

-在多中继段网络中不需要重传来自源终端的数据分组(快速本地错误恢复)；

-避免了对缓存的过早清除。

-不需要对当前的RLC协议做重大改变。

-归因于基于状态报告调整流控制的可能性，用于每中继段流控制明显信令不是必要的。

-减少了来自目标BS的下行链路轮询信令并且因此加快了移交过程。

-归因于隐含的流控制，多个中继段之间的均匀负载分配被允许。

缩写：

3GPP 第三代合作伙伴项目

AM   确认模式

ARQ  自动重传请求

BS   基站

HARQ 混合自动重发请求

LTE  长期演进

MAC  媒体访问控制

PDCP 分组数据会聚协议

PDU  协议数据单元

PLMN 公共陆地移动网络

REC  中继增强小区

RLC  无线链接控制

RN   中继节点

RRC  无线资源控制

SN   序列号

TCP  传输控制协议

UE   用户设备

UM   未确认模式

UMTS 全球移动通信系统

UT   用户终端

Claims (24)

1.一种用于第一实例(UE)和第二实例(BS)之间的数据通信的方法，其包括以下步骤：

-所述第一实例通过第三实例(RN)或者直接地向所述第二实例发布第一状态报告。

2.根据权利要求1所述的方法，其中所述第二实例是数据的主要发送方。

3.根据上述任意一项权利要求所述的方法，其中如果所述第一实例之前连接到所述第三实例，那么所述第一实例直接发布所述第一状态报告。

4.根据上述任意一项权利要求所述的方法，其中所述第三实例是中继节点。

5.根据上述任意一项权利要求所述的方法，其中所述第三实例是具有减少的协议栈的网络元件。

6.根据权利要求5所述的方法，其中所述第三实例包括物理层、MAC层和RLC层。

7.根据权利要求5所述的方法，其中所述第三实例包括物理层和MAC层。

8.根据上述任意一项权利要求所述的方法，其中所述第一状态报告包括关于已经在所述第一实例处被接收的数据的信息。

9.根据上述任意一项权利要求所述的方法，其中所述第一状态报告包括RLC状态报告。

10.根据上述任意一项权利要求所述的方法，其中所述第一状态报告被用于移交的目的。

11.根据上述任意一项权利要求所述的方法，其中第一实例到所述第三实例的连接被移交到所述第二实例。

12.根据上述任意一项权利要求所述的方法，其中所述第三实例轮询所述第一实例的状态并且将其转发到所述第二实例。

13.根据上述任意一项权利要求所述的方法，其中所述第三实例将由所述第二实例进行的轮询中继到所述第一实例。

14.根据上述任意一项权利要求所述的方法，其中在完成所述移交后，所述第一实例将所述第一状态报告发送到所述第二实例。

15.根据上述任意一项权利要求所述的方法，其中所述第一状态报告被用于流控制的目的。

16.根据上述任意一项权利要求所述的方法，其中所述第三实例将第二状态报告发布到所述第二实例。

17.根据权利要求16所述的方法，其中所述第二状态报告包括RLC状态报告。

18.根据权利要求16或17中任意一项所述的方法，其中所述第三实例的缓存状态由所述第二实例通过利用由所述第一实例发布的所述第一状态报告和由所述第三实例发布的所述第二状态报告确定。

19.根据权利要求18所述的方法，其中所述第二实例通过提高或者降低发送速率来调整所述缓存状态。

20.根据权利要求18或19中任意一项所述的方法，其中所述第二实例通过调整RLC发送窗和/或通过指示所述MAC层调度更多/更少数据到所述第一实例来调整所述缓存状态。

21.一种包括处理器单元的装置，所述装置被配置成使得根据前述任意一项权利要求所述的方法在所述处理器单元上可执行。

22.根据权利要求21所述的装置，其中所述装置是通信装置。

23.根据权利要求21或22中任意一项所述的装置，其中所述装置是用户终端、基站和/或中继节点，或者与用户终端、基站和/或中继节点相关联。

24.包括根据权利要求21到23中任意一项所述的装置的通信系统。

Images