CN102006601A - 一种发送协同数据的方法、系统和装置 - Google Patents
一种发送协同数据的方法、系统和装置 Download PDFInfo
- Publication number
- CN102006601A CN102006601A CN2009100921335A CN200910092133A CN102006601A CN 102006601 A CN102006601 A CN 102006601A CN 2009100921335 A CN2009100921335 A CN 2009100921335A CN 200910092133 A CN200910092133 A CN 200910092133A CN 102006601 A CN102006601 A CN 102006601A
- Authority
- CN
- China
- Prior art keywords
- equipment
- synergistic data
- data
- synergistic
- resource
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 230000005540 biological transmission Effects 0.000 claims abstract description 91
- 230000002195 synergetic effect Effects 0.000 claims description 342
- 241001269238 Data Species 0.000 claims description 17
- 238000005259 measurement Methods 0.000 claims description 12
- 238000004080 punching Methods 0.000 claims description 12
- 230000001174 ascending effect Effects 0.000 claims description 6
- 238000011144 upstream manufacturing Methods 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims description 4
- 238000005516 engineering process Methods 0.000 abstract description 4
- 230000007774 longterm Effects 0.000 abstract description 4
- 238000004891 communication Methods 0.000 abstract description 3
- JZEPSDIWGBJOEH-UHFFFAOYSA-N 4-decylbicyclo[2.2.1]hept-2-ene Chemical compound C1CC2C=CC1(CCCCCCCCCC)C2 JZEPSDIWGBJOEH-UHFFFAOYSA-N 0.000 description 11
- 238000010586 diagram Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 6
- 238000013468 resource allocation Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 101150071746 Pbsn gene Proteins 0.000 description 2
- 238000013506 data mapping Methods 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 1
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
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可以是基站或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传输数据，从而提高系统的下行传输效率；进一步增加高数据速率的覆盖范围，提高小区边缘的吞吐量和系统吞吐量。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (38)
1.一种发送协同数据的方法，其特征在于，该方法包括：
第一设备收到来自第二设备的协同数据后，确定用于传输协同数据的协同资源；
所述第一设备采用物理层直接转发方式，通过协同资源向需要进行协同传输的用户终端发送协同数据。
2.如权利要求1所述的方法，其特征在于，所述第一设备是中继节点RN设备，所述第二设备是基站；
所述第二设备向所述第一设备发送协同数据包括：
所述第二设备向所述第一设备发送包含协同数据标识的调度命令，以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中，通过下行回程链路DL backhaul子帧向所述第一设备发送MAC PDU，其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据。
3.如权利要求1所述的方法，其特征在于，所述第一设备是基站，所述第二设备是RN设备；
所述第二设备向所述第一设备发送协同数据之前还包括：
所述第二设备向所述第一设备发送协同数据缓存报告，所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识；
所述第一设备向所述第二设备发送包含分配资源信息的调度命令；
所述第二设备向所述第一设备发送协同数据包括：
所述第二设备根据所述分配资源信息，确定上行回程链路UL backhaul子帧，将所述协同数据置于MAC PDU中，通过确定的UL backhaul子帧向所述第一设备发送MAC PDU。
4.如权利要求3所述的方法，其特征在于，所述第一设备向所述第二设备发送根据协同数据标识加扰后的调度命令，用于指示所述第二设备根据调度命令确定的UL backhaul子帧发送协同数据。
5.如权利要求3所述的方法，其特征在于，所述第二设备通过确定的ULbackhaul子帧向所述第一设备发送MAC PDU包括：
所述第二设备将所述MAC PDU映射到所述UL backhaul子帧中的承载符号上，向所述第一设备发送MAC PDU；
其中，所述承载符号是除下行控制符号和下行参考符号之外的符号。
6.如权利要求5所述的方法，其特征在于，该方法还包括：
协同数据的服务端向需要进行协同传输的用户终端发送第一通知消息，用于通知所述用户终端收到的协同数据承载符号不包括下行控制符号和下行参考符号。
7.如权利要求3所述的方法，其特征在于，所述第一设备发送协同数据包括：
所述第一设备将协同数据进行打孔处理后，通过协同资源向需要进行协同传输的用户终端发送。
8.如权利要求7所述的方法，其特征在于，该方法还包括：
协同数据的服务端向需要进行协同传输的用户终端发送第二通知消息，用于通知所述用户终端收到的协同数据是经过打孔处理的数据。
9.如权利要求2或3所述的方法，其特征在于，所述第一设备确定用于传输协同数据的协同资源包括：
所述第一设备将收到协同数据后的第一个下行子帧或收到协同数据后并经过设定时间之后的第一个下行子帧作为用于传输协同数据的协同下行子帧。
10.如权利要求9所述的方法，其特征在于，如果协同数据的服务端是RN设备，所述下行子帧是非DL backhaul子帧。
11.如权利要求9所述的方法，其特征在于，所述第一设备确定用于传输协同数据的协同资源包括：
所述第一设备根据预先设定的资源信息，确定所述协同下行子帧中用于传输协同数据的资源。
12.如权利要求9所述的方法，其特征在于，所述第一设备收到来自第二设备的协同数据之前还包括：
所述第二设备向所述第一设备发送资源信息；
所述第一设备确定用于传输协同数据的协同资源包括：
所述第一设备根据收到的所述资源信息，确定所述协同下行子帧中用于传输协同数据的资源。
13.一种发送协同数据的系统，其特征在于，该系统包括：
第一设备，用于收到来自第二设备的协同数据后，确定用于传输协同数据的协同资源，采用物理层直接转发方式通过协同资源向需要进行协同传输的用户终端发送协同数据；
第二设备，用于向所述第一设备发送协同数据。
14.如权利要求13所述的系统，其特征在于，所述第一设备是中继节点RN设备，所述第二设备是基站；
所述第二设备用于：
向所述第一设备发送包含协同数据标识的调度命令，以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中，通过下行回程链路DLbackhaul子帧向所述第一设备发送MAC PDU，其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据。
15.如权利要求13所述的系统，其特征在于，所述第一设备是基站，所述第二设备是RN设备；
所述第二设备用于：
所述第二设备向所述第一设备发送协同数据缓存报告，所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识，并根据收到的来自所述第一设备的包含分配资源信息的调度命令，确定上行回程链路ULbackhaul子帧，将所述协同数据置于MAC PDU中，通过确定的UL backhaul子帧向所述第一设备发送MAC PDU；
所述第一设备用于：
在收到所述协同数据缓存报告后，发送调度命令。
16.如权利要求15所述的系统，其特征在于，所述第一设备还用于：
向所述第二设备发送根据协同数据标识加扰后的调度命令，用于指示所述第二设备根据调度命令确定的UL backhaul子帧发送协同数据。
17.如权利要求15所述的系统，其特征在于，所述第二设备还用于：
将所述MAC PDU映射到所述UL backhaul子帧中的承载符号上，向所述第一设备发送MAC PDU；
其中，所述承载符号是除下行控制符号和下行参考符号之外的符号。
18.如权利要求15所述的系统，其特征在于，所述第一设备还用于：
将协同数据进行打孔处理后，通过协同资源向需要进行协同传输的用户终端发送。
19.如权利要求14或15所述的系统，其特征在于，所述第一设备用于：
将收到协同数据后的第一个下行子帧或收到协同数据后并经过设定时间之后的第一个下行子帧作为用于传输协同数据的协同下行子帧。
20.如权利要求19所述的系统，其特征在于，如果协同数据的服务端是RN设备，所述下行子帧是非DL backhaul子帧。
21.如权利要求19所述的系统，其特征在于，所述第一设备还用于：
根据预先设定的资源信息，确定所述协同下行子帧中用于传输协同数据的资源。
22.如权利要求19所述的系统，其特征在于，所述第二设备还用于：
向所述第一设备发送资源信息；
所述第一设备还用于：
根据收到的所述资源信息，确定所述协同下行子帧中用于传输协同数据的资源。
23.一种网络侧设备，其特征在于，该网络侧设备包括：
资源确定模块，用于在收到协同数据后，确定用于传输协同数据的协同资源；
第一发送模块，用于采用物理层直接转发方式，通过协同资源向需要进行协同传输的用户终端发送协同数据。
24.如权利要求23所述的网络侧设备，其特征在于，如果所述网络测设备是基站；
所述网络侧设备还包括：
第二发送模块，用于向协同传输的中继节点RN设备发送包含协同数据标识的调度命令，以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中，通过下行回程链路DL backhaul子帧向所述协同传输的中继节点RN设备发送MAC PDU，其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据。
25.如权利要求24所述的网络侧设备，其特征在于，所述第二发送模块还用于：
将资源信息向所述协同传输的RN设备发送，用于指示所述协同传输的RN设备根据所述资源信息确定协同资源。
26.如权利要求23所述的网络侧设备，其特征在于，如果所述网络测设备是RN设备；
所述网络侧设备还包括：
第三发送模块，用于向与自身连接的基站发送协同数据缓存报告，所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识，并根据收到的来自所述与自身连接的基站的包含分配资源信息的调度命令，确定上行回程链路UL backhaul子帧，将所述协同数据置于MAC PDU中，通过确定的UL backhaul子帧向所述与自身连接的基站发送MAC PDU。
27.如权利要求26所述的网络侧设备，其特征在于，所述第三发送模块还用于：
将资源信息向所述与自身连接的基站发送。
28.如权利要求26所述的网络侧设备，其特征在于，所述第三发送模块还用于：
将所述MAC PDU映射到所述UL backhaul子帧中的承载符号上，向所述第一设备发送MAC PDU；
其中，所述承载符号是除下行控制符号和下行参考符号之外的符号。
29.如权利要求28所述的网络侧设备，其特征在于，如果所述网络测设备是协同数据的服务端，所述网络测设备还包括：
第一通知模块，用于向需要进行协同传输的用户终端发送第一通知消息，用于通知所述用户终端收到的协同数据承载符号不包括下行控制符号和下行参考符号。
30.如权利要求26所述的网络侧设备，其特征在于，协同数据的服务端是RN设备，且收到的协同数据是按上行数据物理层映射方式映射到上行资源的，所述第一发送模块还用于：
将协同数据进行打孔处理后，通过协同资源向需要进行协同传输的用户终端发送。
31.如权利要求30所述的网络侧设备，其特征在于，如果所述网络测设备是协同数据的服务端，所述网络测设备还包括：
第二通知模块，用于向需要进行协同传输的用户终端发送第二通知消息，用于通知所述用户终端收到的协同数据是经过打孔处理的数据。
32.如权利要求24或26所述的网络侧设备，其特征在于，所述资源确定模块用于：
将收到协同数据后的第一个下行子帧或收到协同数据后并经过设定时间之后的第一个下行子帧作为用于传输协同数据的协同下行子帧。
33.如权利要求32所述的网络侧设备，其特征在于，如果协同数据的服务端是RN设备，所述下行子帧是非DL backhaul子帧。
34.如权利要求32所述的网络侧设备，其特征在于，所述资源确定模块还用于：
根据预先设定的资源信息，确定所述协同下行子帧中用于传输协同数据的资源；或
根据收到的资源信息，确定所述协同下行子帧中用于传输协同数据的资源。
35.一种网络侧设备，其特征在于，该网络侧设备包括：
数据确定模块，用于确定协同数据；
协同数据发送模块，用于向其他网络侧设备发送确定的协同数据，指示其他网络侧设备采用物理层直接转发方式通过协同资源向需要进行协同传输的用户终端发送协同数据。
36.如权利要求35所述的网络侧设备，其特征在于，如果所述网络测设备是基站；
所述协同数据发送模块用于：
向协同传输的中继节点RN设备发送包含协同数据标识的调度命令，以及将所述协同数据置于下行媒体接入控制协议数据单元MAC PDU中，通过下行回程链路DL backhaul子帧向所述协同传输的中继节点RN设备发送MACPDU，其中所述协同数据标识用于表示所述MAC PDU中的数据是协同数据。
37.如权利要求35所述的网络侧设备，其特征在于，如果所述网络测设备是RN设备；
所述协同数据发送模块用于：
向与自身连接的基站发送协同数据缓存报告，所述协同数据缓存报告对应的逻辑信道组号是协同数据的逻辑信道分组标识，并根据收到的来自所述与自身连接的基站的包含分配资源信息的调度命令，确定上行回程链路ULbackhaul子帧，将所述协同数据置于MAC PDU中，通过确定的UL backhaul子帧向所述与自身连接的基站发送MAC PDU。
38.如权利要求37所述的网络侧设备，其特征在于，所述协同数据发送模块还用于：
将所述MAC PDU映射到所述UL backhaul子帧中的承载符号上，向所述第一设备发送MAC PDU；
其中，所述承载符号是除下行控制符号和下行参考符号之外的符号。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910092133.5A CN102006601B (zh) | 2009-09-02 | 2009-09-02 | 一种发送协同数据的方法、系统和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910092133.5A CN102006601B (zh) | 2009-09-02 | 2009-09-02 | 一种发送协同数据的方法、系统和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102006601A true CN102006601A (zh) | 2011-04-06 |
| CN102006601B CN102006601B (zh) | 2014-03-19 |
Family
ID=43813581
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910092133.5A Active CN102006601B (zh) | 2009-09-02 | 2009-09-02 | 一种发送协同数据的方法、系统和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102006601B (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103269491A (zh) * | 2013-04-02 | 2013-08-28 | 东南大学 | 一种基于毫米波高速通信的中继覆盖选择算法 |
| CN103368931A (zh) * | 2012-03-30 | 2013-10-23 | 富士通株式会社 | 数据处理设备、计算装置、用于数据处理设备的控制方法 |
| CN103875297A (zh) * | 2011-08-03 | 2014-06-18 | 黑莓有限公司 | 分配回程资源 |
| CN108632825A (zh) * | 2012-09-13 | 2018-10-09 | 华为技术有限公司 | 通信方法、基站、无线通信节点和用户设备 |
| WO2019218359A1 (zh) * | 2018-05-18 | 2019-11-21 | 北京小米移动软件有限公司 | 上行数据传输方法、装置及计算机可读存储介质 |
| CN114762366A (zh) * | 2019-11-29 | 2022-07-15 | 华为技术有限公司 | 下行传输方法及通信装置 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101516063A (zh) * | 2008-02-21 | 2009-08-26 | 中兴通讯股份有限公司 | 多媒体广播和组播业务传输方法 |
-
2009
- 2009-09-02 CN CN200910092133.5A patent/CN102006601B/zh active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101516063A (zh) * | 2008-02-21 | 2009-08-26 | 中兴通讯股份有限公司 | 多媒体广播和组播业务传输方法 |
Non-Patent Citations (1)
| Title |
|---|
| 3GPP: "《3GPP TSG RAN1 #57 R1-091710》", 8 May 2009 * |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103875297A (zh) * | 2011-08-03 | 2014-06-18 | 黑莓有限公司 | 分配回程资源 |
| CN103368931A (zh) * | 2012-03-30 | 2013-10-23 | 富士通株式会社 | 数据处理设备、计算装置、用于数据处理设备的控制方法 |
| CN108632825A (zh) * | 2012-09-13 | 2018-10-09 | 华为技术有限公司 | 通信方法、基站、无线通信节点和用户设备 |
| CN108632825B (zh) * | 2012-09-13 | 2021-12-03 | 华为技术有限公司 | 通信方法、基站、无线通信节点和用户设备 |
| US11419106B2 (en) | 2012-09-13 | 2022-08-16 | Huawei Technologies Co., Ltd. | Communication method, base station, radio communication node, and user equipment |
| CN103269491A (zh) * | 2013-04-02 | 2013-08-28 | 东南大学 | 一种基于毫米波高速通信的中继覆盖选择算法 |
| CN103269491B (zh) * | 2013-04-02 | 2015-06-17 | 东南大学 | 一种基于毫米波高速通信的中继覆盖选择算法 |
| WO2019218359A1 (zh) * | 2018-05-18 | 2019-11-21 | 北京小米移动软件有限公司 | 上行数据传输方法、装置及计算机可读存储介质 |
| CN114762366A (zh) * | 2019-11-29 | 2022-07-15 | 华为技术有限公司 | 下行传输方法及通信装置 |
| CN114762366B (zh) * | 2019-11-29 | 2023-09-01 | 华为技术有限公司 | 下行传输方法及通信装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102006601B (zh) | 2014-03-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102474465B (zh) | 用于回程链路的增强型控制信令的方法和装置 | |
| CN101939941B (zh) | 用于分配确认信道的方法和设备 | |
| JP5472656B2 (ja) | 中継通信システム | |
| CN103001749B (zh) | 传输数据的方法、物联网设备和网络侧设备 | |
| CN102014503B (zh) | 中继系统控制信道配置方法、检测方法及设备 | |
| CN102013961B (zh) | 一种发送上行反馈信息的方法、系统和设备 | |
| CN102045773B (zh) | 中继节点的数据传输冲突的处理方法和装置 | |
| CN104349491A (zh) | 一种物理下行共享信道传输的方法、系统和网络侧设备 | |
| CN104350796A (zh) | 无线通信系统、无线基站装置、终端装置以及无线资源的分配方法 | |
| CN102036398A (zh) | 一种中继节点及其传输数据的方法 | |
| CN102742338A (zh) | 用于无线回程链路上的多个传输块的资源映射的方法和装置 | |
| CN102781095B (zh) | 数据传输的方法、基站、用户设备及系统 | |
| KR20110095060A (ko) | 중계 네트워크 시스템에서 채널 상태 정보 참조 심볼 송수신 방법 및 장치 | |
| CN102006601B (zh) | 一种发送协同数据的方法、系统和装置 | |
| CN101753198A (zh) | 通信方法、中继器和通信系统 | |
| EP1892976A2 (en) | Radio base station | |
| CN101931960B (zh) | 一种避免上行传输冲突的方法、系统和装置 | |
| CN101814944B (zh) | 一种数据传输方法、系统及装置 | |
| CN104303578A (zh) | 数据传输处理方法、装置和系统 | |
| CN108809532A (zh) | 一种数据传输方法、装置和系统 | |
| CN102209392B (zh) | 一种下行控制资源分配方法和设备 | |
| CN102148673A (zh) | 下行确认/非确认信息处理方法及系统 | |
| CN102006602B (zh) | 一种发送协同数据的方法、系统和装置 | |
| CN102111214A (zh) | 基站、中继节点、中继子帧配置信息的通知方法及系统 | |
| CN102149131A (zh) | 下行确认/非确认信息处理方法及系统 |
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. |
|
| GR01 | Patent grant | ||
| 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: 20210609 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 |