CN102594418A - 基于正交覆盖码的多点协作数据传输方法 - Google Patents

Abstract

本发明涉及基于正交覆盖码的多点协作数据传输方法。在本发明的一个实施例中，提出了一种在多输入多输出系统的基站中用于下行数据传输的方法，包括以下步骤：A.在多个多点协作小区的天线中确定多个天线组；B.对各个天线组的跨区多点协作下行数据符号分别采用不同的正交覆盖码进行调制；其中，正交覆盖码的长度不超过天线组数的两倍。通过采用本发明中所提出的方法，基站和用户设备可以根据正交覆盖码来区分不同多点协作小区、不同天线组或不同多点协作小区群的信号，降低了不同多点协作小区、不同天线组或不同多点协作小区群之间的信号干扰。

Description

基于正交覆盖码的多点协作数据传输方法

技术领域

本发明涉及无线通信技术，尤其涉及多输入多输出(MIMO)系统中的多点协作(Coordinate Multiple Point，CoMP)数据传输的方法。

背景技术

多点协作已被作为LTE-A(long term evolution-advanced)候选技术提出以改进小区边缘用户的体验。多点协作的主要挑战包括诸如回程(backhaul)时延、回程容量、下行链路CSI(信道状态指示)反馈、等。大多数挑战来自于在用户设备(User Equipment，UE)侧结合地合并多个小区的发射信号。在LTE-A中，有两种CoMP方案已被确定，一种是协作调度(Coordinated Scheduling，CS)，另一种是联合处理(Joint Processing，JP)。

典型的联合处理(JP)多点协作要求UE报告其自身与CoMP小区之间的下行链路CSI，其可以表示为一个KM×N矩阵(K、M、N分别为小区数量、每小区天线数量、UE的天线数量)。该类CSI反馈提供了在eNB(evolved Node B)侧全局预编码的可能性。然而，反馈开销和码本搜索复杂性可能过大而难以被接受。

一个松散的条件是使得UE为K个小区中的每一个反馈一个独立的M×N矩阵，并执行宏分集传输。如某些公司所提出的，可以使用几个附加比特来表示小区之间的CSI相位/幅度关系。跨小区的反馈要求UE知道活动CoMP集合，其可能影响调度复杂性并造成过多的反馈。

发明内容

现有的下行多点协作数据传输方案虽然使得小区边缘用户的频谱效率得到改善，但代价是较低的平均频谱效率，因为小区边缘用户相比于非多点协作传输情况下占用了更多的资源。

为了部分地或全部地克服上述问题，改善系统性能，本发明中提出了使用正交覆盖码(Orthogonal Covering Code，OCC)来区分多点协作小区的天线分组、多点协作小区或多点协作小区群的技术方案。

在本发明的一个实施例中，提出了一种在多输入多输出系统的基站中用于下行数据传输的方法，包括以下步骤：A.在多个多点协作小区的天线中确定多个天线组；B.对各个天线组的跨区多点协作下行数据符号分别采用不同的正交覆盖码进行调制；其中，正交覆盖码的长度不超过天线组数的两倍。

在本发明的另一个实施例中，提供了一种在多输入多输出系统的基站中用于下行数据传输的方法，包括以下步骤：a.确定一个用户设备是否位于多点协作小区群的边缘；b.如果所述用户设备位于多点协作小区群的边缘，对该用户设备的下行数据符号采用正交覆盖码进行调制；其中，相邻的多点协作小区群采用不同的正交覆盖码。

在本发明的又一个实施例中，提供了一种在多输入多输出系统的用户设备中用于上行数据传输的方法，包括以下步骤：I.确定所述用户设备是否位于多点协作小区或多点协作小区群的边缘；II.如果所述用户设备位于多点协作小区或多点协作小区群的边缘，采用与该用户设备所处的多点协作小区或多点协作小区群对应的正交覆盖码对该用户设备的上行数据符号进行调制；其中，相邻的多点协作小区或多点协作小区群对应不同的正交覆盖码。

通过采用本发明中所提出的方法，基站和用户设备可以根据正交覆盖码来区分不同多点协作小区、不同天线组或不同多点协作小区群的信号，降低了不同多点协作小区、不同天线组或不同多点协作小区群之间的信号干扰。本发明的各实施例部分地或全部地取得以下技术效果：降低了多点协作数据传输对回程容量、反馈开销的要求，保持了相干合并增益。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更加明显：

图1示出了根据本发明的一个实施例的在多输入多输出系统的基站中用于下行数据传输的方法流程图；

图2a、图2b分别示出了采用正交覆盖码对数据符号进行调制的一个例子；

图3a至图3d分别示出了四个不同实施例的下行数据传输拓扑；

图4示出了根据本发明的另一个实施例的在多输入多输出系统的基站中用于下行数据传输的方法流程图；

图5示出了根据本发明的一个实施例的多点协作小区群的拓扑图；

图6示出了根据本发明的一个实施例的在多输入多输出系统的用户设备中用于上行数据传输的方法流程图；

在图中，贯穿不同的示图，相同或类似的附图标记表示对应的特征。

具体实施方式

本发明中提出的方法适用于蜂窝通信系统，尤其适用于LTE、LTE-A系统。本发明中所称的“基站”例如但不限于LTE系统、LTE-A系统中的节点B(Node B)或演进型节点B(eNB)。

图1示出了根据本发明的一个实施例的在多输入多输出系统的基站中用于下行数据传输的方法流程图。如图所示，该方法包括步骤S11和S12。

在步骤S11中，基站将在多个多点协作小区的天线中确定多个天线组(group)。例如但不限于，这里的多个多点协作小区属于同一个多点协作小区群(cluster)，多点协作数据传输通常在一个多点协作小区群之内执行。优选地，不同的天线组之间没有交集。存在着关于天线组的不同的系统设定：一个天线组可以仅包括一个小区的天线，例如每一个小区的天线形成一个天线组；一个天线组也可以包括多个小区的天线，则这样的天线组成为跨区天线组。在步骤S11中，基站能够根据系统设定来确定所述多个天线分组。

在步骤S12中，基站对各个天线组的跨区多点协作下行数据符号分别采用不同的正交覆盖码进行调制；其中，正交覆盖码的长度不超过天线组数的两倍。正交覆盖码的长度不超过天线组数的两倍可以避免因为正交覆盖码过长而导致被同一个正交覆盖码所调制的数据符号之间的信道畸变。优选地，正交覆盖码的长度等于天线组数，正交覆盖码的数量等于天线组数。

正交覆盖码可以采用Walsh码。Walsh码为二元序列，长度通常为2的整数次幂。长度为4的Walsh码表示为

$\left(\begin{array}{cccc}1& 1& 1& 1\\ 1& 1& -1& -1\\ 1& -1& 1& -1\\ -1& 1& 1& -1\end{array}\right).$

正交覆盖码还可以采用复值序列，其长度无需受到2的整数次幂的限制。例如，正交覆盖码可以采用长度为3的Zad-off Chu码，表示为x(m)＝exp(-jπm(m+1)/3)，其中m＝[0 1 2]，[1 2 0]，[2 0 1]。

正交覆盖码可以映射到时域、频域、时-频域。

图2a示出了采用正交覆盖码对数据符号进行调制的一个例子。该例中，正交覆盖码的长度为4，仅数据符号(不包括DMRS符号)采用正交覆盖码调制。图中相同标记的方格表示由正交覆盖码调制一个数据符号所形成的符号。如图所示，每一个数据符号被一个正交覆盖码调制后形成四个符号，多个被调制后的数据符号按照先时域、后频域的顺序依次映射到为这些数据符号所分配的资源块(resource block)中。

图2b示出了采用正交覆盖码对数据符号进行调制的另一个例子。该例中，正交覆盖码的长度为4，仅数据符号(不包括DMRS符号)采用正交覆盖码调制。图中相同标记的方格表示由正交覆盖码调制一个数据符号所形成的符号。如图所示，每一个数据符号被一个正交覆盖码调制后形成四个符号，多个被调制后的数据符号按照先频域、后时域的“Z”字型顺序依次映射到为这些数据符号所分配的资源块中，这样使得同一个数据符号调制后形成的符号在频域上彼此靠近而不会遭受明显的频率响畸变，如图中标号为8的方格所示。

在上述两例中，当所分配的资源块中的资源块中用于数据符号的资源元素(resource element)并非4的整数倍，映射完整数个数据符号之后残余的资源元素可以采用打孔(puncturing)或速率匹配的方式进行处理。

经过正交覆盖码的调制，用户设备能够区分来自不同天线组的下行数据，从而改善接收性能。

图3a示出了一个实施例的下行数据传输拓扑。如图所示，小区11a、12a、13a属于同一个多点协作小区群。例如，小区11a、12a、13a可以是同一个eNB管辖的三个扇区。该例中的系统设定为：每一个小区的天线各为一个天线组。这样，由小区11a、12a、13a组成的多点协同小区群包括三个天线组。

在步骤S11中，基站将根据系统设定确定这三个天线组。

图中所示用户设备24a享受跨区多点协作下行传输服务。在步骤S12中，基站分别经小区11a、12a、13a的天线组向同一个跨区多点协作用户设备24a发送不同的跨区多点协作下行数据符号。其中，小区11a的天线组发往用户设备24a的跨区多点协作下行数据符号采用正交覆盖码1a进行调制，小区12a的天线组发往用户设备24a的跨区多点协作下行数据符号采用正交覆盖码2a进行调制，小区13a的天线组发往用户设备24a的跨区多点协作下行数据符号采用正交覆盖码3a进行调制。优选地，该例中采用长度为3的Zad-offChu码作为正交覆盖码。三个小区发往用户设备24a的下行数据符号分别采用不同的码来调制，彼此之间具有良好的正交性，因此用户设备24a能够区分出来自不同天线组的数据符号。尽管采用正交覆盖码调制后来自每个天线组的码率将为约1/3，但每个天线组发往用户设备24a的是不同的下行数据符号，因此用户设备24a接收的总体下行数据速率并未下降。而且用户设备24a对来自每个天线组的接收信号进行正交覆盖码解调制时，符号合并带来的增益比得上传统多线协作下行数据传输中的相干合并增益。

在该例中，基站对每一小区内的非多点协作用户设备，诸如用户设备21a、22a、23a，的下行数据符号并不采用正交覆盖码调制。考虑到正交覆盖码调制(类似于扩频调制)带来的接收功率增益，基站可以对多点协作用户设备的下行数据分配较少的功率，这样可以获得较高的平均吞吐量。当用户设备不反馈小区之间的信道状态信息时，该例中的方法也可以不受影响地使用，同时也降低了回程(backhaul)容量和反馈开销的要求。

图3b示出了一个实施例的下行数据传输拓扑。如图所示，小区11b、12b、13b属于同一个多点协作小区群。例如，小区11b、12b、13b可以是同一个eNB管辖的三个扇区。该例中的系统设定为：每一个小区的天线各为一个天线组。这样，由小区11b、12b、13b组成的多点协同小区群包括三个天线组。

在步骤S11中，基站将根据系统设定确定这三个天线组。

图中所示用户设备24b享受跨区多点协作下行传输服务。在步骤S12中，基站分别经小区11b、12b、13b的天线组向同一个跨区多点协作用户设备24b发送不同的跨区多点协作下行数据符号。其中，小区11b、12b、13b的天线组发往用户设备24a的跨区多点协作下行数据符号分别采用正交覆盖码1b、2b、3b进行调制。

在步骤S12中，基站还对各天线组之一的小区内下行数据符号采用与这一个天线组的跨区多点协作下行数据符号不同的正交覆盖码进行调制。如图所示，基站对用户设备21b、22b、23b的下行数据符号均采用正交覆盖码4b进行调制。该方式适用于小区不知道其与用户设备之间的信道状态信息的情形，例如，小区11b可以通过正交覆盖码1b、4b来区分发往跨区多点协作用户设备24b是下行数据符号和发往小区内用户设备21b的下行数据符号，这样可以充分利用天线资源，提高每小区支持的用户数量。当用户设备不反馈其与小区之间的信道状态信息时，也降低了回程(backhaul)容量和反馈开销的要求。

或者，基站可以对用户设备21b的下行数据符号采用正交覆盖码2b或3b进行调制，对用户设备22b的下行数据符号采用正交覆盖码3b或1b进行调制，对用户设备23b的下行数据符号采用正交覆盖码1b或2b进行调制。这样，可以充分利用码资源，提高系统的平均吞吐量。

图3c示出了一个实施例的下行数据传输拓扑。如图所示，小区11c、12c、13c属于同一个多点协作小区群。例如，小区11c、12c、13c可以是同一个eNB管辖的三个扇区。该例中的系统设定为：每一个小区的天线各为一个天线组。这样，由小区11c、12c、13c组成的多点协同小区群包括三个天线组。

在步骤S11中，基站将根据系统设定确定这三个天线组。

在步骤S12中，基站还分别经各天线组向不同用户设备发送下行数据符号。如图所示，基站经由小区11c的天线组向用户设备21c发送下行数据符号并采用正交覆盖码1c进行调制，经由小区12c的天线组向用户设备22c发送下行数据符号并采用正交覆盖码2c进行调制，经由小区13c的天线组向用户设备23c发送下行数据符号并采用正交覆盖码3c进行调制。这样，相邻小区的下行数据分别采用不同的正交覆盖码进行调制，通过接收端(用户设备)的正交覆盖码解调制可以消除小区之间的信号干扰。

图3d示出了一个实施例的下行数据传输拓扑。如图所示，小区11d、12d、13d属于同一个多点协作小区群。例如，小区11d、12d、13d可以是同一个eNB管辖的三个扇区。该例中的系统设定为：每个小区的各一根天线组成一个跨区天线组(在交叉极化的情形下，每个小区的各一对天线组成一个跨区天线组)。如图所示每个小区包括两根天线，这样，由小区11d、12d、13d组成的多点协同小区群包括两个跨区天线组。

在步骤S11中，基站将根据系统设定确定这两个跨区天线组。

在步骤12中，基站还经所述至少一个跨区天线组向至少一个跨区多点协作用户设备发送跨区多点协作下行数据符号。图中所示用户设备21d、22d享受跨区多点协作下行传输服务。相应地，在步骤S12中，基站经由第一跨区天线组向跨区多点协作用户设备21d发送跨区多点协作下行数据符号并采用正交覆盖码1d进行调制，经由第二跨区天线组向跨区多点协作用户设备22d发送跨区多点协作下行数据符号并采用正交覆盖码2d进行调制。其中，每个跨区天线组中的各天线发送相同的数据符号。多点协作用户设备21d和22d应报告各自与三个小区11d、12d、13d之间的信道状态信息(CSI)，以便对这两个跨区天线组进行预编码处理。因为该例中由小区11d、12d、13d组成的多点协作小区群包括两个跨区天线组，正交覆盖码1d、2d可以采用长度为2的Walsh码。因为来自不同小区的天线之间相关性较低，所以由跨区天线组发送下行数据可以获得较好的空间增益。而用户设备21d、22d对接收到的来自跨区天线组的下行数据信号进行解调时，仍然可以获得相干合并增益。这多个跨区天线组能够服务于一个或多个用户设备，取决于基站调度和用户设备的能力。该例中的方法适用于同一个基站所辖的多个小区之间的多点协作下行数据传输，因为同一个基站所辖的多个小区能够通过总线或其他有线接口来传递CSI信息、其他控制信息、信令信息、数据、等，从而避免了过度的时延对跨区多点协作下行数据传输的不利影响。

图4示出了根据本发明的另一个实施例的在多输入多输出系统的基站中用于下行数据传输的方法流程图。如图所示，该方法包括步骤S41和S42。

在步骤S41中，基站将确定一个用户设备是否位于多点协作小区群的边缘。

具体地，基站可以通过用户设备反馈的信道质量指示(CQI)报告或者对于定位参考信号的接收功率来做出判断。当用户设备反馈的CQI值低于一个预定值时，表明该用户设备与基站之间的信道质量很差，则基站确定该用户设备位于多点协作小区群的边缘。或者当用户设备反馈的对于定位参考信号的接收功率低于一个预定值时，表明该用户设备远离基站，则基站确定该用户设备位于多点协作小区群的边缘。

在步骤S42中，如果所述用户设备位于多点协作小区群的边缘，则基站对该用户设备的下行数据符号采用正交覆盖码进行调制；其中，相邻的多点协作小区群采用不同的正交覆盖码。

图5示出了根据本发明的一个实施例的多点协作小区群的拓扑图。图中示出了三个相邻的多点协作小区群51、52、53，每个多点协作小区群包括三个小区(扇区)。结合上述步骤S42，三个相邻的多点协作小区群51、52、53分别采用不同的正交覆盖码。这样，位于小区群边缘的用户设备在对接收信号进行正交覆盖码解调制之后，能够区分来自于不同小区群的信号，从而可以降低相邻小区群之间的下行数据干扰。如图5所示，在该实施例中，如果所有多点协作小区群均以类似于小区群51、52、53的方式进行设置，多输入多输出系统中最少只需三个彼此正交的正交覆盖码即可。

如前面结合图1所描述的实施例中一样，这里的正交覆盖码可以采用Walsh码或Zad-off Chu码。

图6示出了根据本发明的一个实施例的在多输入多输出系统的用户设备中用于上行数据传输的方法流程图。如图所示，该方法包括步骤S61和S62。

在步骤S61中，用户设备将确定所述其是否位于多点协作小区或多点协作小区群的边缘。

具体地，用户设备可以通过信道质量指示(CQI)或者对于定位参考信号的接收功率来做出判断。当用户设备的CQI值低于一个预定值时，表明该用户设备与基站之间的信道质量很差，则该用户设备确定其位于多点协作小区或多点协作小区群的边缘。或者当用户设备对于定位参考信号的接收功率低于一个预定值时，表明该用户设备远离基站，则该用户设备确定其位于多点协作小区或多点协作小区群的边缘。

在步骤S61中，如果所述用户设备位于多点协作小区或多点协作小区群的边缘，其采用与该用户设备所处的多点协作小区或多点协作小区群对应的正交覆盖码对该用户设备的上行数据符号进行调制；其中，相邻的多点协作小区或多点协作小区群对应不同的正交覆盖码。

在该例中，系统中的多点协作小区或多点协作小区群可以采用例如图5所示的拓扑。图5中示出了三个相邻的多点协作小区群51、52、53，每个多点协作小区群包括三个小区(扇区)。结合上述步骤S62，三个相邻的多点协作小区群51、52、53分别对应不同的正交覆盖码。这样，位于小区群边缘的用户设备采用与其所处的多点协作小区或多点协作小区群对应的正交覆盖码对其上行数据符号进行调制。基站在对接收信号进行正交覆盖码解调制之后，能够区分来自于不同小区或小区群的用户设备的信号，从而可以降低相邻小区群之间的上行数据干扰。如图5所示，在该实施例中，如果所有多点协作小区群均以类似于小区群51、52、53的方式进行设置，多输入多输出系统中最少只需三个彼此正交的正交覆盖码即可。

如前面结合图1所描述的实施例中一样，这里的正交覆盖码可以采用Walsh码或Zad-off Chu码。

在本发明的各实施例中，由一个正交覆盖码调制之后的数据符号受到边缘用户的干扰所带来的影响比信道变化带来的影响严重得多，而对接收信号进行正交覆盖码解调制时的符号合并增益应该淹没来自信道变化的错误结果。

本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；不定冠词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。

Claims (13)

1.一种在多输入多输出系统的基站中用于下行数据传输的方法，包括以下步骤：

A.在多个多点协作小区的天线中确定多个天线组；

B.对各个天线组的跨区多点协作下行数据符号分别采用不同的正交覆盖码进行调制；

其中，正交覆盖码的长度不超过天线组数的两倍。

2.根据权利要求1所述的方法，其特征在于，

步骤A中，确定出的每个天线组仅包括一个小区的天线；

步骤B还包括：经各天线组向同一个跨区多点协作用户设备分别发送不同的跨区多点协作下行数据符号。

3.根据权利要求2所述的方法，其特征在于，

步骤B还包括：对各天线组之一的小区内下行数据符号采用与这一个天线组的跨区多点协作下行数据符号不同的正交覆盖码进行调制。

4.根据权利要求1所述的方法，其特征在于，

步骤A中，确定出的每个天线组仅包括一个小区的天线；

步骤B还包括：分别经各天线组向不同用户设备发送下行数据符号。

5.根据权利要求1所述的方法，其特征在于，

步骤A中，确定出至少一个跨区天线组，所述跨区天线组包括多个小区的天线；

步骤B还包括：经所述至少一个跨区天线组向至少一个跨区多点协作用户设备发送跨区多点协作下行数据符号。

6.根据权利要求1至5中任一项所述的方法，其特征在于，正交覆盖码的长度等于天线组数。

7.根据权利要求1至5中任一项所述的方法，其特征在于，所述正交覆盖码包括Walsh码或Zad-off Chu码。

8.一种在多输入多输出系统的基站中用于下行数据传输的方法，包括以下步骤：

a.确定一个用户设备是否位于多点协作小区群的边缘；

b.如果所述用户设备位于多点协作小区群的边缘，对该用户设备的下行数据符号采用正交覆盖码进行调制；

其中，相邻的多点协作小区群采用不同的正交覆盖码。

9.根据权利要求8所述的方法，其特征在于，所述步骤a中，根据定位参考信号或CQI报告来确定用户设备是否位于多点协作小区群的边缘。

10.根据权利要求8或9所述的方法，其特征在于，所述正交覆盖码包括Walsh码或Zad-off Chu码。

11.一种在多输入多输出系统的用户设备中用于上行数据传输的方法，包括以下步骤：

I.确定所述用户设备是否位于多点协作小区或多点协作小区群的边缘；

II.如果所述用户设备位于多点协作小区或多点协作小区群的边缘，采用与该用户设备所处的多点协作小区或多点协作小区群对应的正交覆盖码对该用户设备的上行数据符号进行调制；

其中，相邻的多点协作小区或多点协作小区群对应不同的正交覆盖码。

12.根据权利要求11所述的方法，其特征在于，所述步骤I中，根据定位参考信号或CQI报告来确定用户设备是否位于多点协作小区或多点协作小区群。

13.根据权利要求11或12所述的方法，其特征在于，所述正交覆盖码包括Walsh码或Zad-off Chu码。

Images