具体实施方式
本发明实施例第一设备收到来自第二设备的协同数据后，确定用于传输协同数据的协同资源；采用物理层直接转发方式，通过协同资源向需要进行协同传输的用户终端发送协同数据。由于本发明实施例中在LTE-A系统引入Relay节点后，可以采用CoMP传输数据，从而提高系统的下行传输效率。
其中，本发明实施例可以应用于引入Relay节点的LTE-A(Long TermEvolution-Advanced，长期演进升级)系统。
需要说明的是，本发明实施例并不局限于上述系统，其他含有RN设备的通信系统也同样适用于本发明实施例
本发明实施例中的协同资源是用于承载协同数据的资源，协同资源与协同数据对应的服务端发送协同数据所使用的资源相同，由于第一设备和协同数据对应的服务端使用相同的资源(即相同的时域资源和频域资源)，所以可以保证第一设备和协同数据对应的服务端同时向用户终端发送协同数据。
物理层直接转发方式是指协同端不对收到的协同数据进行解调处理，转发的物理层协同数据符号即为接收到的物理层协同数据符号；也就是说，第一设备的物理层对收到的协同数据不进行解调处理，只是将收到的协同数据进行转发，其中协同数据符号是协同数据在物理层的表现形式。
下面结合说明书附图对本发明实施例作进一步详细描述。
如图2A所示，本发明实施例第一种发送协同数据的系统包括：第一设备10和第二设备20。
第一设备10，用于收到来自第二设备20的协同数据后，确定用于传输协同数据的协同资源，采用物理层转发方式通过协同资源向需要进行协同传输的用户终端发送协同数据。
第二设备20，用于向第一设备10发送协同数据。
其中，第一设备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 DataUnit，下行媒体接入控制协议数据单元)中，通过DL backhaul(下行回程链路)子帧向第一设备10发送MAC PDU；
其中，协同数据标识用于表示MAC PDU中的数据是协同数据。
相应的，第一设备10收到含有协同数据标识的调度命令，再收到MACPDU后，就知道该MAC PDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中的数据是协同数据，所以承载协同数据的MAC PDU中只能有协同数据，不能有其他的常规数据，也就是说，不能将协同数据和常规数据复用到一个TB(Transport Block，传输块)中。
针对情况一，由于RN设备是协同端，所以可以设定RN设备优先传输协同数据。
情况二、第一设备10是基站，第二设备20是RN设备。
其中，第二设备20在有协同数据时，向第一设备10发送协同数据缓存报告，该协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识。
具体的，第二设备20需要通过协同数据缓存报告等方法通知第一设备10自身需要发送上行传输(协同数据缓存报告中包括协同数据量和用于传输协同数据的资源信息所占比特数)，并要求第一设备10为自身分配上行传输所需的资源。为了提高资源利用率，将采用协同数据缓存报告对应的特定逻辑信道组号，该逻辑信道组号为协同数据的逻辑信道分组标识。
相应的，第一设备10在收到该缓存报告后，向第二设备20发送包含分配资源信息的调度命令，用于通知第二设备20采用哪些上行资源；
其中，分配资源信息包括发送协同数据所需的PRB(physical resourceblock，物理资源块)个数和位置等信息。
还有一种较佳的方式是明确分配的资源用于发送协同数据，具体的第一设备10还可以根据协同数据标识，对调度命令进行加扰(即将协同数据标识置于调度命令中)，用于指示第二设备20根据调度命令确定的UL backhaul(上行回程链路)子帧发送协同数据；
协同数据标识可以是特殊的CoMP-RNT。
当然，也可以不用协同数据标识进行加扰，而是在协议中规定，比如规定第二设备20将在发送包含协同数据信息的缓存报告后接收到的第一个用于新传输的资源分配作为用于传输协同数据的资源分配。
第二设备20在收到的调度命令后，根据分配资源信息确定UL backhaul子帧，然后将协同数据置于MAC PDU中，通过确定的UL backhaul子帧向第一设备10发送MAC PDU；
第一设备10收到MAC PDU后就知道该MAC PDU中的数据是协同数据。
具体的，第二设备20根据调度命令发送时刻就可以找到UL backhaul子帧；
如果采用了CoMP-RNTI进行加扰，相应地，第二设备20检测到对应该用户CoMP-RNTI的调度命令，则清楚该资源专用于传输CoMP数据，不能用于传输其他数据。
由于协同数据标识表示MAC PDU中的数据是协同数据，所以承载协同数据的MAC PDU中只能有协同数据，不能有其他的常规数据，也就是说，不能将协同数据和常规数据复用到一个TB中。
对于情况二，由于第二设备20(RN设备)需要将协同数据先发送给第一设备10(需要上行子帧)，然后第一设备10将协同数据发送给用户终端(需要下行子帧)，而上行子帧和下行子帧可用的资源不一致，比如使用的符号数不一样，一般上行子帧符号数为14个，下行子帧由于前几个符号要承载PDCCH(Physical Downlink Control Channel，下行物理控制信道)，可用符号数为14-(1～3)个；还比如上行参考信号和下行参考信号的位置不一样，所以需要进行特殊处理。具体可以采用两种方式。
方式一、第二设备20按上行数据物理层映射方式将数据映射到上行资源上发送给第一设备10，由于第一设备10不用解调该数据，可以不放上行参考信号。第一设备10给用户终端发送下行数据的时候将协同数据根据下行资源情况进行打孔，用于放置控制信道和下行参考信号。
第二设备20给用户终端发送下行数据的时候也将协同数据根据下行资源情况进行打孔。
具体的，第一设备10将协同数据进行打孔处理后，通过协同资源向需要进行协同传输的用户终端发送。
由于进行了打孔处理，用户终端在接收到CoMP数据的时候需要考虑数据打孔情况，在具体实施过程中可以在协议中规定是否进行打孔处理；也可以由协同数据的服务端向需要进行协同传输的用户终端发送第二通知消息，用于通知用户终端收到的协同数据是经过打孔处理的数据。
方式二、第二设备20将协同数据发送给第一设备10的时候不按常规上行数据映射方式，前几个符号和下行参考符号位置不参与数据映射。
具体的，第二设备20将MAC PDU映射到UL backhaul子帧中的承载符号上，向第一设备发送MAC PDU；
其中，承载符号是除下行控制符号和下行参考符号之外的符号。
协同数据的服务端还可以向需要进行协同传输的用户终端发送第一通知消息，用于通知用户终端收到的协同数据承载符号不包括下行控制符号和下行参考符号。
具体采用方式一还是方式二可以在协议中规定，也可以由第一设备10和第二设备20协商确定。
其中，第一设备10将收到协同数据后的第一个下行子帧或收到协同数据后并经过设定时间之后的第一个下行子帧作为协同下行子帧，采用物理层直接转发方式通过协同下行子帧传输协同数据
具体时间可以根据需要进行设定。
具体将收到协同数据后的第一个下行子帧作为协同下行子帧，还是将收到协同数据后并经过设定时间之后的第一个下行子帧作为协同下行子帧可以在协议中规定，也可以由协同传输的服务端和协同端协商后确定。
在具体实施过程中，如果协同数据的服务端是RN设备，则下行子帧是非DL backhaul子帧。也就是说，第一设备10将收到协同数据后的第一个非DLbackhaul的下行子帧或收到协同数据后并经过设定时间之后的第一个非DLbackhaul的下行子帧作为协同下行子帧。
在具体实施过程中，第一设备10可以根据预先设定的资源信息，确定协同下行子帧中用于传输协同数据的资源，以及采用物理层直接转发方式通过确定的协同下行子帧中用于传输协同数据的资源，传输收到的协同数据。
例如可以将一定周期内的指定的PRBs作为预定义资源。
需要说明的是，本发明实施例并不局限于上述指定资源的方式，其他指定资源的方式同样适用本发明实施例。
还有一种方式是第二设备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中的数据是协同数据。
进一步的，第二发送模块120还可以将资源信息向协同传输的RN设备发送，用于指示协同传输的RN设备根据资源信息确定协同资源。
如果本发明实施例的网络侧设备是服务端，则第二发送模块120发送的协同数据是自身的；如果网络侧设备是协同端，则第二发送模块120发送的协同数据是来自其他基站(比如图2C或2E的场景)或其他RN设备(比如图2D的场景)。
情况二、网络侧设备是RN设备，且网络侧设备作为服务端，则本发明实施例的网络侧设备还可以进一步包括：第三发送模块130。
第三发送模块130，用于向与自身连接的基站发送协同数据缓存报告，协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识，并根据收到的来自与自身连接的基站的包含分配资源信息的调度命令，确定ULbackhaul子帧，将协同数据置于MAC PDU中，通过确定的UL backhaul子帧向与自身连接的基站发送MAC PDU。
进一步的，第三发送模块130还可以将资源信息向与自身连接的基站发送。
由于上行子帧和下行子帧的可用资源不同，第三发送模块130还可以将MAC PDU映射到UL backhaul子帧中的承载符号上，向第一设备发送MACPDU；
其中，承载符号是除下行控制符号和下行参考符号之外的符号。
进一步的，如果本发明实施例的网络测设备是协同数据的服务端，则本发明实施例的网络测设备还可以进一步包括：
第一通知模块140，用于向需要进行协同传输的用户终端发送第一通知消息，用于通知用户终端收到的协同数据承载符号不包括下行控制符号和下行参考符号。
如果不采用上述方式，还可以采用打孔处理的方式，具体的，如果协同数据的服务端是RN设备，且收到的协同数据是按上行数据物理层映射方式映射到上行资源的，则第一发送模块100将协同数据进行打孔处理后，通过协同资源向需要进行协同传输的用户终端发送。
进一步的，如果本发明实施例的网络测设备是协同数据的服务端，则本发明实施例的网络测设备还可以进一步包括：
第二通知模块150，用于向需要进行协同传输的用户终端发送第二通知消息，用于通知用户终端收到的协同数据是经过打孔处理的数据。
其中，资源确定模块100将收到协同数据后的第一个下行子帧或收到协同数据后并经过设定时间之后的第一个下行子帧作为用于传输协同数据的协同下行子帧。
如果协同数据的服务端是RN设备，下行子帧是非DL backhaul子帧。
进一步的，资源确定模块100根据预先设定的资源信息，确定协同下行子帧中用于传输协同数据的资源；或根据收到的资源信息，确定协同下行子帧中用于传输协同数据的资源。
如图4B所示，本发明实施例第二种网络侧设备包括：数据确定模块200和协同数据发送模块210。
数据确定模块200，用于确定协同数据；
协同数据发送模块210，用于向其他网络侧设备发送确定的协同数据，指示其他网络侧设备通过协同资源向需要进行协同传输的用户终端发送协同数据。
其中，本发明实施例协同数据发送模块210具体发送协同数据的方式与本发明实施例第一种网络侧设备中的第二发送模块120和第三发送模块130发送协同数据的方式相同，在此不再赘述。
协同数据发送模块210对于上行子帧和下行子帧的可用资源不同的处理方式与本发明实施例第一种网络侧设备中的第三发送模块130对于上行子帧和下行子帧的可用资源不同的处理方式相同，在此不再赘述。
如图5所示，本发明实施例发送协同数据的方法包括下列步骤：
步骤501、第一设备收到来自第二设备的协同数据后，确定用于传输协同数据的协同资源。
步骤502、第一设备采用物理层直接转发方式，通过协同资源向需要进行协同传输的用户终端发送协同数据。
其中，步骤501之前还可以进一步包括：
步骤500、第二设备向第一设备发送协同数据。
第一设备可以是基站或RN设备；第二设备可以是RN设备或基站。
下面分别对不同情况进行说明。
情况一、第一设备是RN设备，第二设备是基站。
步骤500中，第二设备在有协同数据时(该协同数据根据不同的场景，有可能是第二设备自身的协同数据，也有可能是收到其他网络侧设备的协同数据，具体可以参见图2B～2E)，需要先向第一设备发送调度命令，用于将协同数据以规定的调制编码方式映射到指定的物理资源上。具体包括让信息比特如何映射成物理资源和对应的进程号等信息，比如资源指示、调制编码信息、冗余版本信息、进程号等。
在具体实施过程中，第二设备可以在调度命令中携带协同数据标识，比如特殊的CoMP-RNTI，然后将协同数据置于MAC PDU中，通过DL backhaul(下行回程链路)子帧向第一设备10发送MAC PDU；
其中，协同数据标识用于表示MAC PDU中的数据是协同数据。
步骤501中，第一设备收到含有协同数据标识的调度命令，再收到MACPDU后，就知道该MAC PDU中的数据是协同数据。
由于协同数据标识表示MAC PDU中的数据是协同数据，所以承载协同数据的MAC PDU中只能有协同数据，不能有其他的常规数据，也就是说，不能将协同数据和常规数据复用到一个TB(Transport Block，传输块)中。
针对情况一，由于RN设备是协同端，所以可以设定RN设备优先传输协同数据。
情况二、第一设备是基站，第二设备是RN设备。
步骤500中，第二设备在有协同数据时，向第一设备发送协同数据缓存报告，该协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识。
具体的，第二设备需要通过协同数据缓存报告等方法通知第一设备自身需要发送上行传输(协同数据缓存报告中包括协同数据量和用于传输协同数据的资源信息所占比特数)，并要求第一设备为自身分配上行传输所需的资源。为了提高资源利用率，将采用协同数据缓存报告对应的特定逻辑信道组号，该逻辑信道组号为协同数据的逻辑信道分组标识。
相应的，步骤500中第一设备在收到该缓存报告后，向第二设备发送包含分配资源信息的调度命令，用于通知第二设备采用哪些上行资源；
其中，分配资源信息包括发送协同数据所需的PRB个数和位置等信息。
还有一种较佳的方式是明确分配的资源用于发送协同数据，具体的第一设备还可以根据协同数据标识，对调度命令进行加扰(即将协同数据标识置于调度命令中)，用于指示第二设备根据调度命令确定的UL backhaul子帧发送协同数据；
协同数据标识可以是特殊的CoMP-RNTI。
当然，也可以不用协同数据标识进行加扰，而是在协议中规定，比如规定第二设备将在发送包含协同数据信息的缓存报告后接收到的第一个用于新传输的资源分配作为用于传输协同数据的资源分配。
步骤500中，第二设备在收到的调度命令后，根据分配资源信息或协同数据标识确定UL backhaul子帧，然后将协同数据置于MAC PDU中，通过确定的UL backhaul子帧向第一设备发送MAC PDU；
步骤501中，第一设备收到MAC PDU后就知道该MAC PDU中的数据是协同数据。
具体的，步骤500中第二设备根据调度命令发送时刻就可以找到ULbackhaul子帧；
如果采用了CoMP-RNTI进行加扰，相应地，第二设备检测到对应该用户CoMP-RNTI的调度命令，则清楚该资源专用于传输CoMP数据，不能用于传输其他数据。
由于协同数据标识表示MAC PDU中的数据是协同数据，所以承载协同数据的MAC PDU中只能有协同数据，不能有其他的常规数据，也就是说，不能将协同数据和常规数据复用到一个TB中。
对于情况二，由于第二设备(RN设备)需要将协同数据先发送给第一设备(需要上行子帧)，然后第一设备将协同数据发送给用户终端(需要下行子帧)，而上行子帧和下行子帧可用的资源不一致，比如使用的符号数不一样，一般上行子帧符号数为14个，下行子帧由于前几个符号要承载PDCCH(Physical Downlink Control Channel，下行物理控制信道)，可用符号数为14-(1～3)个；还比如上行参考信号和下行参考信号的位置不一样，所以需要进行特殊处理。具体可以采用两种方式。
方式一、步骤500中，第二设备按上行数据物理层映射方式将数据映射到上行资源上发送给第一设备，由于第一设备不用解调该数据，可以不放上行参考信号。
步骤502中，第一设备给用户终端发送下行数据的时候将协同数据根据下行资源情况进行打孔，用于放置控制信道和下行参考信号。
第二设备给用户终端发送下行数据的时候也将协同数据根据下行资源情况进行打孔。
具体的，步骤502中第一设备将协同数据进行打孔处理后，通过协同资源向需要进行协同传输的用户终端发送。
由于进行了打孔处理，用户终端在接收到CoMP数据的时候需要考虑数据打孔情况，在具体实施过程中可以在协议中规定是否进行打孔处理；也可以由协同数据的服务端向需要进行协同传输的用户终端发送第二通知消息，用于通知用户终端收到的协同数据是经过打孔处理的数据。
方式二、步骤500中，第二设备将协同数据发送给第一设备的时候不按常规上行数据映射方式，前几个符号和下行参考符号位置不参与数据映射。
具体的，第二设备将MAC PDU映射到UL backhaul子帧中的承载符号上，向第一设备发送MAC PDU；
其中，承载符号是除下行控制符号和下行参考符号之外的符号。
协同数据的服务端还可以向需要进行协同传输的用户终端发送第一通知消息，用于通知用户终端收到的协同数据承载符号不包括下行控制符号和下行参考符号。
具体采用方式一还是方式二可以在协议中规定，也可以由第一设备和第二设备协商确定。
步骤501中，第一设备将收到协同数据后的第一个下行子帧或收到协同数据后并经过设定时间之后的第一个下行子帧作为协同下行子帧，采用物理层直接转发方式通过协同下行子帧传输协同数据
具体时间可以根据需要进行设定。
具体将收到协同数据后的第一个下行子帧作为协同下行子帧，还是将收到协同数据后并经过设定时间之后的第一个下行子帧作为协同下行子帧可以在协议中规定，也可以由协同传输的服务端和协同端协商后确定。
在具体实施过程中，如果协同数据的服务端是RN设备，则下行子帧是非DL backhaul子帧。也就是说，步骤501中第一设备将收到协同数据后的第一个非DL backhaul的下行子帧或收到协同数据后并经过设定时间之后的第一个非DL backhaul的下行子帧作为协同下行子帧。
步骤501中，第一设备可以根据预先设定的资源信息，确定协同下行子帧中用于传输协同数据的资源，以及采用物理层直接转发方式通过确定的协同下行子帧中用于传输协同数据的资源，传输收到的协同数据。
例如可以将一定周期内的指定的PRBs作为预定义资源。
需要说明的是，本发明实施例并不局限于上述指定资源的方式，其他指定资源的方式同样适用本发明实施例。
还有一种方式是步骤500中，第二设备将资源信息和协同数据一起向第一设备发送(其中，资源信息根据不同的场景，有可能是第二设备自身确定的，也有可能是收到来自其他网络侧设备的，具体可以参见图2B～2E)；
相应的，步骤501中第一设备根据收到的资源信息，确定协同下行子帧中用于传输协同数据的资源，以及采用物理层直接转发方式通过确定的协同下行子帧中用于传输协同数据的资源，传输收到的协同数据。
如果第一设备是基站，第二设备是RN设备，则第二设备还可以将资源信息与协同数据缓存报告一起发送给第一设备。
具体采用预先设定还是通知的方式，可以在协议中设定也可以由协同端和服务端协商确定。
不管采用哪种方式，都需要保证协同端和服务端可以同时向用户终端发送协同数据。
本发明实施例中协同端和服务端向用户终端发送的协同数据也可以叫做下行数据。
从上述实施例中可以看出：第一设备收到来自第二设备的协同数据后，确定用于传输协同数据的协同资源；第一设备采用物理层直接转发方式，通过协同资源向需要进行协同传输的用户终端发送协同数据。
由于本发明实施例中在LTE-A系统引入Relay节点后，可以采用CoMP传输数据，从而提高系统的下行传输效率；进一步增加高数据速率的覆盖范围，提高小区边缘的吞吐量和系统吞吐量。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。