CN102006602B - 一种发送协同数据的方法、系统和装置 - Google Patents

一种发送协同数据的方法、系统和装置 Download PDF

Info

Publication number
CN102006602B
CN102006602B CN 200910092134 CN200910092134A CN102006602B CN 102006602 B CN102006602 B CN 102006602B CN 200910092134 CN200910092134 CN 200910092134 CN 200910092134 A CN200910092134 A CN 200910092134A CN 102006602 B CN102006602 B CN 102006602B
Authority
CN
China
Prior art keywords
equipment
data
synergistic data
synergistic
mac pdu
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.)
Active
Application number
CN 200910092134
Other languages
English (en)
Other versions
CN102006602A (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.)
China Academy of Telecommunications Technology CATT
Datang Mobile Communications Equipment Co Ltd
Original Assignee
China Academy of Telecommunications Technology CATT
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 China Academy of Telecommunications Technology CATT filed Critical China Academy of Telecommunications Technology CATT
Priority to CN 200910092134 priority Critical patent/CN102006602B/zh
Publication of CN102006602A publication Critical patent/CN102006602A/zh
Application granted granted Critical
Publication of CN102006602B publication Critical patent/CN102006602B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

本发明实施例涉及无线通信技术,特别涉及一种发送协同数据的方法、系统和装置,用以在LTE-A系统引入Relay节点后,可以采用CoMP传输数据,从而提高系统的传输效率。本发明实施例的方法包括:第一设备收到来自第二设备的协同数据后,对所述协同数据进行解调;所述第一设备在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。采用本发明实施例的方法可以提高系统的下行传输效率,增加高数据速率的覆盖范围,以及提高小区边缘的吞吐量和系统吞吐量。

Description

一种发送协同数据的方法、系统和装置
技术领域
本发明涉及无线通信技术,特别涉及一种发送协同数据的方法、系统和装置。
背景技术
LTE-A(Long Term Evolution-Advanced,长期演进升级)系统引入Relay(中继)节点后,定义了以下节点、接口和链路,如图1所示,
节点包括:
Donor-eNB:与RN(中继节点)设备有无线连接的eNB(演进基站),简写为DeNB;
Relay-Node:存在于DeNB与UE(用户终端)之间的实体,简写为RN设备;
Relay-UE:与RN设备进行数据交互的UE,简写为R-UE;
宏UE:直接与DeNB进行数据交互的UE。
接口包括:
Un接口:RN设备和DeNB之间的接口;
Uu接口:UE和RN设备之间的接口。
无线链路包括:
Backhaul link:回程链路,与Un接口对应的链路;
Access link:接入链路,与Uu接口对应的链路;
Direct link:直射链路,DeNB与宏UE进行数据传输的链路。
引入RN设备后的下行传输:到达RN设备下UE的数据需要由DeNB经下行回程链路发送到RN设备,再由RN设备经下行接入链路发送到UE。
引入RN设备后的上行传输:RN设备下UE的上行传输先由UE经上行接入链路发送到RN设备,再由RN设备经回程链路发送到DeNB。
LTE-A系统中可以通过协作多点(Coordinated multi-point,CoMP)发送和接收技术来增加高数据速率的覆盖,提高小区边缘的吞吐量和系统吞吐量。所谓协作多点是指地理位置上分离的多个传输点(是归属于一个或多个基站的不同小区)协同参与对一个UE传输/接收数据。
但是目前在LTE-A系统引入Relay节点后,还没有一种CoMP传输数据的方案。
发明内容
本发明实施例提供一种发送协同数据的方法、系统和装置,用以在LTE-A系统引入Relay节点后,可以采用CoMP传输数据,从而提高系统的传输效率。
本发明实施例提供的一种发送协同数据的方法,该方法包括:
第一设备收到来自第二设备的协同数据后,对所述协同数据进行解调;
所述第一设备在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
本发明实施例提供的一种发送协同数据的系统,该系统包括:
第一设备,用于收到协同数据后,对所述协同数据进行解调,在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据;
第二设备,用于向所述第一设备发送协同数据。
本发明实施例提供的一种网络侧设备,该网络侧设备包括:
调制模块,用于在收到协同数据后,对所述协同数据进行解调;
第一发送模块,用于在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
本发明实施例提供的另一种网络侧设备,该网络测设备包括:
数据确定模块,用于确定协同数据;
协同数据发送模块,用于向其他网络侧设备发送确定的协同数据,指示其他网络侧设备对所述协同数据进行解调,并在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
本发明实施例第一设备收到来自第二设备的协同数据后,对协同数据进行解调,在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。由于本发明实施例中在LTE-A系统引入Relay节点后,可以采用CoMP传输数据,从而提高系统的下行传输效率;进一步增加高数据速率的覆盖范围,提高小区边缘的吞吐量和系统吞吐量。
附图说明
图1为引入Relay节点的LTE-A系统示意图;
图2A为本发明实施例第一种发送协同数据的系统结构示意图;
图2B为本发明实施例第二种发送协同数据的系统结构示意图;
图2C为本发明实施例第三种发送协同数据的系统结构示意图;
图2D为本发明实施例第四种发送协同数据的系统结构示意图;
图2E为本发明实施例第五种发送协同数据的系统结构示意图;
图3A为本发明实施例RN作为协同端的传输示意图;
图3B为本发明实施例RN作为服务端的传输示意图;
图4A为本发明实施例第一种网络侧设备的结构示意图;
图4B为本发明实施例第二种网络侧设备的结构示意图;
图5为本发明实施例发送协同数据的方法流程示意图。
具体实施方式
本发明实施例第一设备收到来自第二设备的协同数据后,对协同数据进行解调,在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。由于本发明实施例中在LTE-A系统引入Relay节点后,可以采用CoMP传输数据,从而提高系统的下行传输效率。
其中,本发明实施例可以应用于引入Relay节点的LTE-A(Long TermEvolution-Advanced,长期演进升级)系统。
需要说明的是,本发明实施例并不局限于上述系统,其他含有RN设备的通信系统也同样适用于本发明实施例
本发明实施例中的协同资源是用于承载协同数据的资源,协同资源与协同数据对应的服务端发送协同数据所使用的资源相同,由于第一设备和协同数据对应的服务端使用相同的资源(即相同的时域资源和频域资源),所以可以保证第一设备和协同数据对应的服务端同时向用户终端发送协同数据。
下面结合说明书附图对本发明实施例作进一步详细描述。
如图2A所示,本发明实施例第一种发送协同数据的系统包括:第一设备10和第二设备20。
第一设备10,用于收到来自第二设备20的协同数据后,对协同数据进行解调,在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
第二设备20,用于向第一设备10发送协同数据。
其中,解调是指将调制编码后的数据按照对应的调制编码规则还原成信息比特。
第一设备10可以对解调的数据进行CRC(Cyclic Redundancy Check,循环冗余码校验),如果CRC成功,则确定解调正确;否则,确定解调失败。
需要说明的是,本发明实施例并不局限于上述校验方式,其他能够确定解调数据是否正确的方式都适用本发明实施例。
其中,第一设备10可以是基站或RN设备;第二设备20可以是RN设备或基站。
下面分别对不同情况进行说明。
情况一、第一设备10是RN设备,第二设备20是基站。
其中,第二设备20在有协同数据时(该协同数据根据不同的场景,有可能是第二设备20自身的协同数据,也有可能是收到其他网络侧设备的协同数据,具体可以参见图2B~2E),需要先向第一设备10发送调度命令,用于将协同数据以规定的调制编码方式映射到指定的物理资源上。具体包括让信息比特如何映射成物理资源和对应的进程号等信息,比如资源指示、调制编码信息、冗余版本信息、进程号等。
在具体实施过程中,第二设备20可以在调度命令中携带协同数据标识,比如特殊的CoMP-RNTI(Radio Network Temporary Identity,无线网络临时识别),然后将协同数据置于MAC PDU(Medium Access Control Packet Data Unit,下行媒体接入控制协议数据单元)中,通过DL backhaul(下行回程链路)子帧向第一设备10发送MAC PDU;
其中,协同数据标识用于表示MAC PDU中的数据是协同数据。
相应的,第一设备10收到含有协同数据标识的调度命令,再收到MACPDU后,就知道该MAC PDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中的数据是协同数据,所以承载协同数据的MAC PDU中只能有协同数据,不能有其他的常规数据,也就是说,不能将协同数据和常规数据复用到一个TB(Transport Block,传输块)中。
第二设备20也可以不在调度命令中携带协同数据标识,而是将协同数据置于MAC PDU中,并将特殊逻辑信道号置于协同数据的MAC SDU(MediumAccess Control Service Data Units,下行媒体接入控制协议业务数据单元)对应的MAC子头中,通过DL backhaul子帧向第一设备10发送MAC PDU;
其中特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
相应的,第一设备10在收到MAC PDU后,根据MAC子头中的特殊逻辑信道号,就知道MAC子头对应的MAC SDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中MAC子头对应的数据是协同数据,所以承载协同数据的MAC PDU中除了可以有协同数据,还可以有其他的常规数据,也就是说,可以将协同数据和常规数据复用到一个TB中。
情况二、第一设备10是基站,第二设备20是RN设备。
其中,第二设备20在有协同数据时,向第一设备10发送协同数据缓存报告,该协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识。
具体的,第二设备20需要通过协同数据缓存报告等方法通知第一设备10自身需要发送上行传输(协同数据缓存报告中包括协同数据量和用于传输协同数据的调度信息所占比特数),并要求第一设备10为自身分配上行传输所需的资源。为了提高资源利用率,将采用协同数据缓存报告对应的特定逻辑信道组号,该逻辑信道组号为协同数据的逻辑信道分组标识。
相应的,第一设备10在收到该缓存报告后,向第二设备20发送调度命令,用于通知第二设备20采用哪些上行资源,比如包括发送协同数据所需的PRB(physical resource block,物理资源块)个数和位置等信息。
在具体实施过程中,第一设备10可以在调度命令中携带协同数据标识,比如采用特殊的CoMP-RNTI对调度命令进行加扰;
第二设备20在收到的调度命令中包含协同数据标识时,将协同数据置于MAC PDU中,通过UL backhaul(上行回程链路)子帧向第一设备10发送MAC PDU;
第一设备10收到MAC PDU后就知道该MAC PDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中的数据是协同数据,所以承载协同数据的MAC PDU中只能有协同数据,不能有其他的常规数据,也就是说,不能将协同数据和常规数据复用到一个TB中。
第一设备10还可以不在调度命令中携带协同数据标识;
相应的,第二设备20在收到的调度命令中不包含协同数据标识时,将协同数据置于MAC PDU中,并将特殊逻辑信道号置于协同数据的MAC SDU对应的MAC子头中,通过UL backhaul子帧向第一设备10发送MAC PDU,其中特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据;
第一设备10在收到MAC PDU后,根据MAC子头中的特殊逻辑信道号,就知道MAC子头对应的MAC SDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中MAC子头对应的数据是协同数据,所以承载协同数据的MAC PDU中除了可以有协同数据,还可以有其他的常规数据,也就是说,可以将协同数据和常规数据复用到一个TB中。
其中,第一设备10将解调后的第一个下行子帧或解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧,通过协同下行子帧传输协同数据
具体时间可以根据需要进行设定。
具体将解调后的第一个下行子帧作为协同下行子帧,还是将解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧可以在协议中规定,也可以由协同传输的服务端和协同端协商后确定。
在具体实施过程中,如果协同数据的服务端是RN设备,则下行子帧是非DL backhaul子帧。也就是说,第一设备10将解调后的第一个非DL backhaul的下行子帧或解调后并经过设定时间之后的第一个非DL backhaul的下行子帧作为协同下行子帧。
对应协同数据,第一设备10只需要解码到MAC层识别出对应的MACSDU即可。
在具体实施过程中,第一设备10可以根据预先设定的调度信息,确定协同下行子帧中用于传输协同数据的资源,以及根据预先设定的调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
例如可以将一定周期内的指定的PRBs作为预定义资源,MCS(Modulationand Coding Scheme,调制编码方式)可以是QPSK(Quadrature Phase ShiftKeying,四相相移键控),1/3编码方式。
需要说明的是,本发明实施例并不局限于上述指定资源和调制编码方式,其他指定资源和调制编码方式同样适用本发明实施例。
其中,物理资源映射是指将进入物理层的信息比特通过加扰、调制编码等一系列过程生成对应的OFDM(Orthogonal Frequency Division Multiplexing,正交频分复用)符号,放置到分配的物理资源块上。
还有一种方式是第二设备20将调度信息和协同数据一起向第一设备10发送(其中,调度信息中的调制方式根据不同的场景,有可能是第二设备20自身确定的,也有可能是收到来自其他网络侧设备的,具体可以参见图2B~2E);
相应的,第一设备10根据收到的调度信息,确定协同下行子帧中用于传输协同数据的资源,根据收到的调制方式,对解调后的协同数据进行调制编码和物理资源映射,通过确定的协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
如果第一设备10是基站,第二设备20是RN设备,则第二设备20还可以将调度信息与协同数据缓存报告一起发送给第一设备10。
具体采用预先设定还是通知的方式,可以在协议中设定也可以由协同端和服务端协商确定。
不管采用哪种方式,都需要保证协同端和服务端可以同时向用户终端发送协同数据。
本发明实施例中协同端和服务端向用户终端发送的协同数据(cooperativedata)也可以叫做下行数据(transmitting data)。
在RN设备参与CoMP时,有4中场景,具体可以参见图2B~2E:
图2B中,RN设备与DeNB(即与该RN设备连接的基站)进行CoMP传输,协同数据要在backhaul链路上实现共享。
图2C中,RN设备与non-DeNB(即不与该RN设备连接的其他基站)进行CoMP传输,协同数据要经过backhaul链路、eNB之间接口实现共享。
图2D中,RN与DeNB下其他RN进行CoMP传输,协同数据要经过两条backhaul链路实现共享。
图2E中,RN与non-DeNB下的RN进行CoMP传输,协同数据要经过两条backhaul链路和eNB间接口实现共享。
上述四种场环境中,RN设备和基站都按照本发明实施例发送协同数据的系统中方式传输,区别在于:
如果是图2C和图2E的场景,与该RN设备连接的基站还需要将RN设备发送的协同数据通过S1或X2接口转发给对应的基站(RN设备是服务端);或者通过S1或X2接口收到的协同数据转发给RN设备(RN设备是协同端)。
如果是图2D的场景,与该RN设备连接的基站还需要将RN设备发送的协同数据转发给自身连接的其他RN设备。
其中,当用户终端向服务端反馈NACK时,如果规定协同端缓存协同数据,则服务端可以通知协同端重新发送协同数据;
如果规定协同端不缓存协同数据,则服务端可以重新向协同端发送发送协同数据,具体参见图3A和3B。
如图4A所示,本发明实施例第一种网络侧设备包括:调制模块100和第一发送模块110。
调制模块100,用于在收到协同数据后,对协同数据进行解调。
第一发送模块110,用于在调制模块100解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
其中,网络侧设备可以是基站,也可以是RN设备。
下面分别对不同情况进行说明。
情况一、网络侧设备是基站,且网络侧设备是协同端或服务端,本发明实施例的网络侧设备还可以进一步包括:第二发送模块120。
第二发送模块120,用于向协同传输的RN设备发送包含协同数据标识的调度命令,以及将协同数据置于下行媒体接入控制协议数据单元MAC PDU中,通过DL backhaul子帧向RN设备发送MAC PDU,其中协同数据标识用于表示MAC PDU中的数据是协同数据;或
将协同数据置于MAC PDU中,并将特殊逻辑信道号置于协同数据的MACSDU对应的MAC子头中,通过DL backhaul子帧向RN设备发送MAC PDU,其中特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
进一步的,第二发送模块120还可以将调度信息向RN设备发送。
如果本发明实施例的网络侧设备是服务端,则第二发送模块120发送的协同数据是自身的;如果网络侧设备是协同端,则第二发送模块120发送的协同数据是来自其他基站(比如图2C或2E的场景)或其他RN设备(比如图2D的场景)。
情况二、网络侧设备是RN设备,且网络侧设备是服务端,则本发明实施例的网络侧设备还可以进一步包括:第三发送模块130。
第三发送模块130,用于向与自身连接的基站发送协同数据缓存报告,协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识;
在收到来自基站的调度命令中包含协同数据标识时,将协同数据置于MAC PDU中,通过UL backhaul子帧向基站发送MAC PDU;
在收到来自基站的调度命令中不包含协同数据标识时,将协同数据置于MAC PDU中,并将特殊逻辑信道号置于协同数据的MAC SDU对应的MAC子头中,通过UL backhaul子帧向基站发送MAC PDU,其中特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
进一步的,第三发送模块130还可以将调度信息向RN设备发送。
其中,第一发送模块110可以对解调的数据进行CRC,如果CRC成功,则确定解调正确;否则,确定解调失败。
需要说明的是,本发明实施例并不局限于上述校验方式,其他能够确定解调数据是否正确的方式都适用本发明实施例。
第一发送模块110还可以将解调后的第一个下行子帧或解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧,通过协同下行子帧传输解调后的协同数据。
在具体实施过程中,如果协同数据的服务端是RN设备,则下行子帧是非DL backhaul子帧。也就是说,第一发送模块110将解调后的第一个非DLbackhaul的下行子帧或解调后并经过设定时间之后的第一个非DL backhaul的下行子帧作为协同下行子帧。
第一发送模块110根据预先设定的调度信息,确定协同下行子帧中用于传输协同数据的资源,根据预先设定的调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
还有一种方式是第一发送模块110根据收到的调度信息,确定协同下行子帧中用于传输协同数据的资源,根据收到的调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
如图4B所示,本发明实施例第二种网络侧设备包括:数据确定模块200和协同数据发送模块210。
数据确定模块200,用于确定协同数据;
协同数据发送模块210,用于向其他网络侧设备发送确定的协同数据,指示其他网络侧设备对协同数据进行解调,并在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
其中,本发明实施例协同数据发送模块210具体发送协同数据的方式与本发明实施例第一种网络侧设备中的第二发送模块120和第三发送模块130发送协同数据的方式相同,在此不再赘述。
如图5所示,本发明实施例发送协同数据的方法包括下列步骤:
步骤501、第一设备收到来自第二设备的协同数据后,对协同数据进行解调。
步骤502、第一设备在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
步骤502中,第一设备可以对解调的数据进行CRC,如果CRC成功,则确定解调正确;否则,确定解调失败。
需要说明的是,本发明实施例并不局限于上述校验方式,其他能够确定解调数据是否正确的方式都适用本发明实施例。
其中,步骤501之前还可以进一步包括:
步骤500、第二设备向第一设备发送协同数据。
第一设备可以是基站或RN设备;第二设备可以是RN设备或基站。
下面分别对不同情况进行说明。
情况一、第一设备是RN设备,第二设备是基站。
步骤500中,第二设备在有协同数据时(该协同数据根据不同的场景,有可能是第二设备自身的协同数据,也有可能是收到其他网络侧设备的协同数据,具体可以参见图2B~2E),需要先向第一设备发送调度命令,用于将协同数据以规定的调制编码方式映射到指定的物理资源上。
在具体实施过程中,第二设备可以在调度命令中携带协同数据标识,比如特殊的CoMP-RNTI,然后将协同数据置于MAC PDU中,通过DL backhaul子帧向第一设备发送MAC PDU;
其中,协同数据标识用于表示MAC PDU中的数据是协同数据。
相应的,步骤501中第一设备收到含有协同数据标识的调度命令,再收到MAC PDU后,就知道该MAC PDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中的数据是协同数据,所以承载协同数据的MAC PDU中只能有协同数据,不能有其他的常规数据,也就是说,不能将协同数据和常规数据复用到一个TB中。
步骤500中,第二设备也可以不在调度命令中携带协同数据标识,而是将协同数据置于MAC PDU中,并将特殊逻辑信道号置于协同数据的MAC SDU对应的MAC子头中,通过DL backhaul子帧向第一设备发送MAC PDU;
其中,特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
相应的,步骤501中第一设备在收到MAC PDU后,根据MAC子头中的特殊逻辑信道号,就知道MAC子头对应的MAC SDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中MAC子头对应的数据是协同数据,所以承载协同数据的MAC PDU中除了可以有协同数据,还可以有其他的常规数据,也就是说,可以将协同数据和常规数据复用到一个TB中。
情况二、第一设备是基站,第二设备是RN设备。
步骤500中,第二设备在有协同数据时,向第一设备发送协同数据缓存报告,该协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识。
具体的,第二设备需要通过协同数据缓存报告等方法通知第一设备自身需要发送上行传输(协同数据缓存报告中包括协同数据量和用于传输协同数据的调度信息所占比特数),并要求第一设备为自身分配上行传输所需的资源。为了提高资源利用率,将采用协同数据缓存报告对应的逻辑信道组号,该逻辑信道组号为协同数据的逻辑信道分组标识。
相应的,步骤500中第一设备在收到该缓存报告后,向第二设备发送调度命令,用于通知第二设备采用哪些上行资源。
在具体实施过程中,第一设备可以在调度命令中携带协同数据标识,比如采用特殊的CoMP-RNTI对调度命令进行加扰;
第二设备在收到的调度命令中包含协同数据标识时,将协同数据置于MAC PDU中,通过上行回程链路UL backhaul子帧向第一设备发送MAC PDU。
相应的,步骤501中第一设备收到MAC PDU后就知道该MAC PDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中的数据是协同数据,所以承载协同数据的MAC PDU中只能有协同数据,不能有其他的常规数据,也就是说,不能将协同数据和常规数据复用到一个TB中。
步骤500中,第一设备还可以不在调度命令中携带协同数据标识;
第二设备在收到的调度命令中不包含协同数据标识时,将协同数据置于MAC PDU中,并将特殊逻辑信道号置于协同数据的MAC SDU对应的MAC子头中,通过UL backhaul子帧向第一设备发送MAC PDU,其中特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据;
相应的,步骤501中第一设备在收到MAC PDU后,根据MAC子头中的特殊逻辑信道号,就知道MAC子头对应的MAC SDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中MAC子头对应的数据是协同数据,所以承载协同数据的MAC PDU中除了可以有协同数据,还可以有其他的常规数据,也就是说,可以将协同数据和常规数据复用到一个TB中。
步骤502中,第一设备将解调后的第一个下行子帧或解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧,通过协同下行子帧传输协同数据。
具体时间可以根据需要进行设定。
具体将解调后的第一个下行子帧作为协同下行子帧,还是将解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧可以在协议中规定也可以由协同传输的服务端和协同端协商后确定。
在具体实施过程中,如果协同数据的服务端是RN设备,则下行子帧是非DL backhaul子帧。也就是说,步骤502中第一设备将解调后的第一个非DLbackhaul的下行子帧或解调后并经过设定时间之后的第一个非DL backhaul的下行子帧作为协同下行子帧。
对应协同数据,第一设备只需要解码到MAC层识别出对应的MAC SDU即可。
步骤502中,第一设备可以根据预先设定的调度信息,确定协同下行子帧中用于传输协同数据的资源,以及根据预先设定的调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
其中,物理资源映射是指将进入物理层的信息比特通过加扰、调制编码等一系列过程生成对应的OFDM符号,放置到分配的物理资源块上。
还有一种方式是步骤500中,第二设备将调度信息协同数据向第一设备发送(其中,调度信息根据不同的场景,有可能是第二设备自身确定的,也有可能是收到来自其他网络侧设备的,具体可以参见图2B~2E);
相应的,步骤502中第一设备根据收到的调度信息,确定协同下行子帧中用于传输协同数据的资源,根据收到的调制方式,对解调后的协同数据进行调制编码和物理资源映射,通过确定的协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
如果第一设备是基站,第二设备是RN设备,则第二设备还可以将调度信息和协同数据缓存报告一起发送给第一设备。
具体采用预先设定还是通知的方式,可以在协议中设定也可以由协同端和服务端协商确定。
不管采用哪种方式,都需要保证协同端和服务端可以同时向用户终端发送协同数据。
本发明实施例中协同端和服务端向用户终端发送的协同数据也可以叫做下行数据。
从上述实施例中可以看出:本发明实施例第一设备收到来自第二设备的协同数据后,对协同数据进行解调;第一设备在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据。
由于本发明实施例中在LTE-A系统引入Relay节点后,可以采用CoMP传输数据,从而提高系统的下行传输效率;进一步增加高数据速率的覆盖范围,提高小区边缘的吞吐量和系统吞吐量。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (23)

1.一种发送协同数据的方法,其特征在于,该方法包括:
第一设备收到来自第二设备的协同数据后,对所述协同数据进行解调;
所述第一设备在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据;
若所述第一设备是中继节点RN设备,所述第二设备是基站,则所述第二设备向所述第一设备发送协同数据包括:
所述第二设备向所述第一设备发送包含协同数据标识的调度命令,以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中,通过下行回程链路DL backhaul子帧向所述第一设备发送MAC PDU,其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据;或
所述第二设备将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的下行媒体接入控制协议业务数据单元MAC SDU对应的MAC子头中,通过DL backhaul子帧向所述第一设备发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的是协同数据;
若所述第一设备是基站,所述第二设备是RN设备,则所述第二设备向所述第一设备发送协同数据之前还包括:所述第二设备向所述第一设备发送协同数据缓存报告,所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识;所述第一设备向所述第二设备发送调度命令;
所述第二设备向所述第一设备发送协同数据包括:所述第二设备在收到的所述调度命令中包含协同数据标识时,将所述协同数据置于MAC PDU中,通过上行回程链路UL backhaul子帧向所述第一设备发送MAC PDU;所述第二设备在收到的所述调度命令中不包含协同数据标识时,将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的MAC SDU对应的MAC子头中,通过UL backhaul子帧向所述第一设备发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
2.如权利要求1所述的方法,其特征在于,所述第一设备根据下列步骤确定解调是否正确:
所述第一设备对解调数据进行循环冗余码校验CRC,如果CRC成功,则确定解调正确;否则,确定解调失败。
3.如权利要求1所述的方法,其特征在于,所述第一设备发送收到的协同数据包括:
所述第一设备将解调后的第一个下行子帧或解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧;
所述第一设备通过协同下行子帧传输协同数据。
4.如权利要求3所述的方法,其特征在于,如果协同数据的服务端是RN设备,所述下行子帧是非DL backhaul子帧。
5.如权利要求3所述的方法,其特征在于,所述第一设备发送收到的协同数据包括:
所述第一设备根据预先设定的调度信息,确定所述协同下行子帧中用于传输协同数据的资源;
所述第一设备根据预先设定的所述调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的所述协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
6.如权利要求3所述的方法,其特征在于,所述第一设备收到来自第二设备的协同数据之前还包括:
所述第二设备向所述第一设备发送调度信息;
所述第一设备发送收到的协同数据包括:
所述第一设备根据收到的所述调度信息,确定所述协同下行子帧中用于传输协同数据的资源;
所述第一设备根据收到的所述调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的所述协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
7.一种发送协同数据的系统,其特征在于,该系统包括:
第一设备,用于收到协同数据后,对所述协同数据进行解调,在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据;
第二设备,用于向所述第一设备发送协同数据;
若所述第一设备是中继节点RN设备,所述第二设备是基站,则所述第二设备用于:
向所述第一设备发送包含协同数据标识的调度命令,以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中,通过下行回程链路DLbackhaul子帧向所述第一设备发送MAC PDU,其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据;或
将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的下行媒体接入控制协议业务数据单元MAC SDU对应的MAC子头中,通过DL backhaul子帧向所述第一设备发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据;
若所述第一设备是基站,所述第二设备是RN设备,则所述第一设备还用于:在收到来自第二设备的协同数据缓存报告后,向所述第二设备发送调度命令;
所述第二设备用于:向所述第一设备发送协同数据缓存报告,所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识;在收到的所述调度命令中包含协同数据标识时,将所述协同数据置于MAC PDU中,通过上行回程链路UL backhaul子帧向所述第一设备发送MAC PDU;在收到的所述调度命令中不包含协同数据标识时,将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的MAC SDU对应的MAC子头中,通过UL backhaul子帧向所述第一设备发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
8.如权利要求7所述的系统,其特征在于,所述第一设备还用于:
对解调数据进行循环冗余校验CRC,如果CRC成功,则确定解调正确;否则,确定解调失败。
9.如权利要求7所述的系统,其特征在于,所述第一设备还用于:
将解调后的第一个下行子帧或设定时间之后的第一个下行子帧作为协同下行子帧,通过协同下行子帧传输协同数据。
10.如权利要求9所述的系统,其特征在于,如果协同数据的服务端是RN设备,所述下行子帧是非DL backhaul子帧。
11.如权利要求9所述的系统,其特征在于,所述第一设备还用于:
根据预先设定的调度信息,确定所述协同下行子帧中用于传输协同数据的资源,根据所述调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的所述协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
12.如权利要求9所述的系统,其特征在于,所述第二设备还用于:
向所述第一设备发送调度信息;
所述第一设备还用于:
根据收到的所述调度信息,确定所述协同下行子帧中用于传输协同数据的资源,根据收到的所述调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的所述协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
13.一种网络侧设备,其特征在于,该网络侧设备包括:
调制模块,用于在收到协同数据后,对所述协同数据进行解调;
第一发送模块,用于在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据;
若所述网络侧设备是基站,则所述网络侧设备还包括:第二发送模块,用于向协同传输的中继节点RN设备发送包含协同数据标识的调度命令,以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中,通过下行回程链路DL backhaul子帧向所述协同传输的RN设备发送MAC PDU,其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据;或
将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的下行媒体接入控制协议业务数据单元MAC SDU对应的MAC子头中,通过DL backhaul子帧向所述协同传输的RN设备发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据;
若所述网络侧设备是RN设备,则所述网络侧设备还包括:第三发送模块,用于向与自身连接的基站发送协同数据缓存报告,所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识;在收到来自所述基站的调度命令中包含协同数据标识时,将协同数据置于MAC PDU中,通过上行回程链路UL backhaul子帧向所述与自身连接的基站发送MAC PDU;在收到来自所述与自身连接的基站的所述调度命令中不包含协同数据标识时,将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的MAC SDU对应的MAC子头中,通过UL backhaul子帧向所述与自身连接的基站发送MACPDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
14.如权利要求13所述的网络侧设备,其特征在于,所述第二发送模块还用于:
将调度信息向所述协同传输的RN设备发送,用于指示所述协同传输的RN设备根据所述调度信息发送协同数据。
15.如权利要求13所述的网络侧设备,其特征在于,所述第三发送模块还用于:
将调度信息向所述基站发送。
16.如权利要求13~15任一权利要求所述的网络侧设备,其特征在于,所述第一发送模块还用于:
对解调数据进行循环冗余校验CRC,如果CRC成功,则确定解调正确;否则,确定解调失败。
17.如权利要求13~15任一权利要求所述的网络侧设备,其特征在于,所述第一发送模块还用于:
将解调后的第一个下行子帧或解调后并经过设定时间之后的第一个下行子帧作为协同下行子帧,通过协同下行子帧传输协同数据。
18.如权利要求17所述的网络侧设备,其特征在于,如果协同数据的服务端是RN设备,所述下行子帧是非DL backhaul子帧。
19.如权利要求17所述的网络侧设备,其特征在于,所述第一发送模块还用于:
根据预先设定的调度信息,确定所述协同下行子帧中用于传输协同数据的资源,根据所述调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的所述协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
20.如权利要求17所述的网络侧设备,其特征在于,所述第一发送模块还用于:
根据收到的调度信息,确定所述协同下行子帧中用于传输协同数据的资源,根据收到的所述调度信息,对解调后的协同数据进行调制编码和物理资源映射,通过确定的所述协同下行子帧中用于传输协同数据的资源,传输调制编码后的协同数据。
21.一种网络侧设备,其特征在于,该网络侧设备包括:
数据确定模块,用于确定协同数据;
协同数据发送模块,用于向其他网络侧设备发送确定的协同数据,指示其他网络侧设备对所述协同数据进行解调,并在解调正确后,通过协同资源向需要进行协同传输的用户终端发送协同数据;
若所述网络侧设备是基站,则所述协同数据发送模块用于:
向协同传输的中继节点RN设备发送包含协同数据标识的调度命令,以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中,通过下行回程链路DL backhaul子帧向所述RN设备发送MAC PDU,其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据;或,
将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的下行媒体接入控制协议业务数据单元MAC SDU对应的MAC子头中,通过DL backhaul子帧向所述RN设备发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据;
若所述网络侧设备是RN设备,则所述协同数据发送模块用于:
向与自身连接的基站发送协同数据缓存报告,所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识;在收到来自所述基站的调度命令中包含协同数据标识时,将协同数据置于MAC PDU中,通过上行回程链路UL backhaul子帧向所述基站发送MAC PDU;在收到来自所述基站的所述调度命令中不包含协同数据标识时,将所述协同数据置于MAC PDU中,并将特殊逻辑信道号置于所述协同数据的MAC SDU对应的MAC子头中,通过ULbackhaul子帧向所述基站发送MAC PDU,其中所述特殊逻辑信道号用于表示MAC子头对应的MAC SDU中包含的数据是协同数据。
22.如权利要求21所述的网络侧设备,其特征在于,所述协同数据发送模块还用于:
向所述RN设备发送调度信息。
23.如权利要求21所述的网络侧设备,其特征在于,所述协同数据发送模块还用于:
向所述基站发送调度信息。
CN 200910092134 2009-09-02 2009-09-02 一种发送协同数据的方法、系统和装置 Active CN102006602B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 200910092134 CN102006602B (zh) 2009-09-02 2009-09-02 一种发送协同数据的方法、系统和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 200910092134 CN102006602B (zh) 2009-09-02 2009-09-02 一种发送协同数据的方法、系统和装置

Publications (2)

Publication Number Publication Date
CN102006602A CN102006602A (zh) 2011-04-06
CN102006602B true CN102006602B (zh) 2013-10-16

Family

ID=43813582

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 200910092134 Active CN102006602B (zh) 2009-09-02 2009-09-02 一种发送协同数据的方法、系统和装置

Country Status (1)

Country Link
CN (1) CN102006602B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2701418B1 (en) * 2011-05-10 2017-07-05 Huawei Technologies Co., Ltd. Method, device and base station for coordinated multi-point (comp) reception processing
WO2014082204A1 (zh) * 2012-11-27 2014-06-05 华为技术有限公司 通信的方法、装置和系统
CN110149711B (zh) * 2018-02-13 2022-09-16 成都华为技术有限公司 一种信号传输方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1849768A (zh) * 2003-09-12 2006-10-18 沃达弗纳控股有限公司 用于在无线中继电路中使用协作分集的方法和系统
CN101361296A (zh) * 2006-03-16 2009-02-04 三菱电机株式会社 多个节点的无线协作中继网络中的信息通信系统和方法
CN101516063A (zh) * 2008-02-21 2009-08-26 中兴通讯股份有限公司 多媒体广播和组播业务传输方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1849768A (zh) * 2003-09-12 2006-10-18 沃达弗纳控股有限公司 用于在无线中继电路中使用协作分集的方法和系统
CN101361296A (zh) * 2006-03-16 2009-02-04 三菱电机株式会社 多个节点的无线协作中继网络中的信息通信系统和方法
CN101516063A (zh) * 2008-02-21 2009-08-26 中兴通讯股份有限公司 多媒体广播和组播业务传输方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Huawei.Discussion on relay in CoMP.《3GPP TSG RAN WG1 meeting #57 R1-091800》.2009,全文. *
ZTE.Cooperation Scheme Considerations for Type II Relay.《3GPP TSG RAN1 #57 R1-091710》.2009,第1节,第2.2节. *

Also Published As

Publication number Publication date
CN102006602A (zh) 2011-04-06

Similar Documents

Publication Publication Date Title
CN102036398B (zh) 一种中继节点及其传输数据的方法
CN101939941B (zh) 用于分配确认信道的方法和设备
CN102461302B (zh) 基站、无线通信系统、无线资源分配方法以及无线通信方法
JP4974016B2 (ja) 制御チャネル要素ベースのインプリシットな指示の選択的使用のための方法及びシステム
CN102237989B (zh) 一种数据传输的方法及系统
CN102045773B (zh) 中继节点的数据传输冲突的处理方法和装置
CN104350796A (zh) 无线通信系统、无线基站装置、终端装置以及无线资源的分配方法
US8654781B2 (en) Method and device for downlink cooperation retransmission in a relay station
CN102215577B (zh) 回程链路上行控制信道的资源分配方法和系统
WO2010094579A1 (en) Methods and apparatuses for transmitting downlink control signaling on wireless relay link
CN102263616A (zh) 指示控制信道的方法及装置
CN102742338A (zh) 用于无线回程链路上的多个传输块的资源映射的方法和装置
CN101795169A (zh) 中继协助通信系统及其方法
CN104541561A (zh) 通信装置及方法
CN102013961A (zh) 一种发送上行反馈信息的方法、系统和设备
CN107295702B (zh) 一种窄带蜂窝通信的方法和装置
CN103731245A (zh) 确认/非确认反馈信息传输方法及装置
CN102006601B (zh) 一种发送协同数据的方法、系统和装置
CN102347823A (zh) 应答信息的合并反馈及其指示方法、装置及系统
CN108809532A (zh) 一种数据传输方法、装置和系统
CN102148673A (zh) 下行确认/非确认信息处理方法及系统
CN102006602B (zh) 一种发送协同数据的方法、系统和装置
CN102316495A (zh) Pdcch的资源映射及中继回传链路的盲检测方法、装置及系统
KR20110074266A (ko) 무선통신 시스템에서 자원 재할당 시 데이터 송·수신 방법 및 장치
JP5643852B2 (ja) 多重ホップ中継方式を使用する無線通信システムにおけるデータ再送信装置及び方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
ASS Succession or assignment of patent right

Owner name: INST OF TELECOMMUNICATION SCIENCE AND TECHNOLGOY

Free format text: FORMER OWNER: DATANG MOBILE COMMUNICATION EQUIPMENT CO., LTD.

Effective date: 20110425

C41 Transfer of patent application or patent right or utility model
COR Change of bibliographic data

Free format text: CORRECT: ADDRESS; FROM: 100083 NO. 29, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING TO: 100191 NO. 40, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING

TA01 Transfer of patent application right

Effective date of registration: 20110425

Address after: 100191 Haidian District, Xueyuan Road, No. 40,

Applicant after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY

Address before: 100083 Haidian District, Xueyuan Road, No. 29,

Applicant before: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd.

C14 Grant of patent or utility model
GR01 Patent grant
CP01 Change in the name or title of a patent holder
CP01 Change in the name or title of a patent holder

Address after: 100191 No. 40, Haidian District, Beijing, Xueyuan Road

Patentee after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY

Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road

Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210531

Address after: 100085 1st floor, building 1, yard 5, Shangdi East Road, Haidian District, Beijing

Patentee after: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd.

Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road

Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY