一种进行协同传输的方法和设备的制造方法

文档序号:10627434阅读:487来源:国知局
一种进行协同传输的方法和设备的制造方法
【专利摘要】本发涉及无线通信技术领域,特别涉及一种进行协同传输的方法和设备,用以在收到多个针对同一帧的协同请求后实现进行协同传输。本发明实施例针对一个子帧对应的请求队列,按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;确定成功的协同请求的优先级;在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。由于能够按照优先级顺序传输对应同一个子帧的协同请求的数据,从而在收到多个针对同一帧的协同请求后实现进行协同传输,提高了系统性能。
【专利说明】
_种进行协同传输的方法和设备
技术领域
[0001]本发明涉及无线通信技术领域,特别涉及一种进行协同传输的方法和设备。
【背景技术】
[0002]多点协同传输(CoordinatedMultipoint Transmiss1n/Recept1n,CoMP)技术是地理位置上分离的多个传输点之间的协作,一般来说,多个传输点是不同小区的基站。多点协同传输技术方案主要分为两类:联合调度和联合传输。联合调度是通过小区之间的时间、频率和空间资源的协调,为不同的UE(终端)分配互相正交的资源,避免相互之间的干扰。小区间的干扰是制约小区边缘UE性能的主要因素,因此联合调度可以降低小区间的干扰,从而提高小区边缘UE的性能。如图1A所示,通过3个小区的联合调度,将可能会相互干扰的三个UE调度了到相互正交的资源上(以不同的颜色表示不同的资源),有效的避免了小区之间的干扰。
[0003]与联合调度方案只有一个小区与UE之间传输数据不同,联合传输方案中有多个小区同时与UE发送/接收数据,以增强UE接收/发送信号。如图1B所示,三个小区在相同的资源上向一个UE发送下行数据,UE同时接收多个小区的信号。如果所有的服务小区发送相同的数据给UE,来自多个小区的有用信号叠加可以提升UE接收的信号质量,从而提高系统性能。反之当UE发送上行数据时有多个小区联合接收并合并处理,也可以达到相同的目的。
[0004]服务小区向目标协同小区发送CoMP协同请求,携带请求的PRB资源。而后协同小区处理该协同请求,判定为协同请求成功或请求失败。如果可以发送反馈,则协同小区向服务小区发送协同响应消息。对于联合传输,协同数据可能随着CoMP协同请求发送到协同小区,或者在服务小区收到协同响应后,再发送到协同小区。对于联合调度则没有协同数据发送。
[0005]目前如果收到多个针对同一帧的协同请求,如何进行协同传输还没有一个方案。

【发明内容】

[0006]本发明提供一种进行协同传输的方法和设备,用以在收到多个针对同一帧的协同请求后实现进行协同传输。
[0007]本发明实施例提供一种进行协同传输的方法,该方法包括:
[0008]针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧;
[0009]按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;
[0010]确定成功的协同请求的优先级;
[0011]在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据
[0012]较佳地,所述确定所述请求队列中需要进行判断的协同请求之前,还包括:
[0013]在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。
[0014]较佳地,将所述协同请求加入到确定的所述子帧对应的所述请求队列中,包括:
[0015]按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0016]随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0017]按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0018]较佳地,所述确定所述请求队列中需要进行判断的协同请求,包括:
[0019]将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。
[0020]较佳地,依次判断协同请求是否成功,包括:
[0021]针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;
[0022]判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;
[0023]若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。
[0024]较佳地,确定成功的协同请求的优先级,包括:
[0025]针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。
[0026]较佳地,确定成功的协同请求的优先级之后,需要传输所述协同请求对应的数据之前,还包括:
[0027]若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
[0028]本发明实施例提供的一种进行协同传输的设备,该设备包括:
[0029]请求确定模块,用于针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧;
[0030]判断模块,用于按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;
[0031]优先级确定模块,用于确定成功的协同请求的优先级;
[0032]传输模块,用于在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。
[0033]较佳地,所述请求确定模块还用于:
[0034]确定所述请求队列中需要进行判断的协同请求之前,在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。
[0035]较佳地,所述请求确定模块具体用于:
[0036]按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0037]随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0038]按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0039]较佳地,所述请求确定模块具体用于:
[0040]将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。
[0041]较佳地,所述判断模块具体用于:
[0042]针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。
[0043]较佳地,所述优先级确定模块具体用于:
[0044]针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。
[0045]较佳地,所述传输模块还用于:
[0046]需要传输所述协同请求对应的数据之前,若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
[0047]本发明实施例提供的另一种进行协同传输的设备,该设备包括:
[0048]处理器,用于读取存储器中的程序,执行下列过程:
[0049]针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧;按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;确定成功的协同请求的优先级;在需要传输所述协同请求对应的数据时,通过收发机在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。
[0050]收发机,用于在处理器的控制下接收和发送数据。
[0051]较佳地,所述处理器还用于:
[0052]确定所述请求队列中需要进行判断的协同请求之前,在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。
[0053]较佳地,所述处理器具体用于:
[0054]按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0055]随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0056]按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0057]较佳地,所述处理器具体用于:
[0058]将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。
[0059]较佳地,所述处理器具体用于:
[0060]针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。
[0061]较佳地,所述处理器具体用于:
[0062]针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。
[0063]较佳地,所述处理器还用于:
[0064]需要传输所述协同请求对应的数据之前,若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
[0065]本发明实施例针对一个子帧对应的请求队列,按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;确定成功的协同请求的优先级;在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。由于能够按照优先级顺序传输对应同一个子帧的协同请求的数据,从而在收到多个针对同一帧的协同请求后实现进行协同传输,提高了系统性能。
【附图说明】
[0066]图1A为【背景技术】中协同调度的示意图;
[0067]图1B为【背景技术】中协同传输的示意图;
[0068]图2A为本发明实施例一进行协同传输的方法流程示意图;
[0069]图2B为本发明实施例协同请求示意图;
[0070]图3为本发明实施例二进行协同传输的设备结构示意图;
[0071]图4为本发明实施例三进行协同传输的设备结构示意图。
【具体实施方式】
[0072]本发明实施例针对一个子帧对应的请求队列,按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;确定成功的协同请求的优先级;在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。由于能够按照优先级顺序传输对应同一个子帧的协同请求的数据,从而在收到多个针对同一帧的协同请求后实现进行协同传输,提高了系统性能。
[0073]下面结合说明书附图对本发明实施例作进一步详细描述。
[0074]如图2A所示,本发明实施例一进行协同传输的方法包括:
[0075]步骤201、针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧;
[0076]步骤202、按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;
[0077]步骤203、确定成功的协同请求的优先级;
[0078]步骤204、在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。
[0079]其中,终端在有协同需求或者终端所在的服务小区在确定需要协同为终端传输时,可以由终端所在的服务小区或者终端向每个协同小区发送协同请求。
[0080]每个协同请求需要占用至少一个子帧。而每个子帧有可能对应多个协同请求。也就是说,每个子帧会对应一个请求队列,请求队列里面包括的所有请求对应同一个子帧。如果协同请求对应多个子帧,该协同请求会在多个请求队列中。
[0081 ] 本发明实施例的执行主体是协同小区所属的网络侧设备,比如宏基站、家庭基站等。
[0082]在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。
[0083]在实施中,会按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功,所以在将协同请求加入到确定的所述子帧对应的所述请求队列中时,可以设定一些顺序条件,将协同请求加入到请求队列中。
[0084]下面列举几种顺序条件:
[0085]顺序条件一、按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0086]这种方式就是先收到的协同请求先加入到队列前面,后收到的协同请求放到先收到的协同请求的后面。
[0087]顺序条件二、随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;
[0088]顺序条件三、按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0089]较佳地,测量量可以是反映信号质量的任何参数,比如RSRP(Reference signalreceived power,参考信号接收功率)或RSRQ (Reference Signal Received Quality,参考信号接收质量)。
[0090]由于测量量说明终端与协同小区之间的信号质量更好,协同传输成功率更高,所以可以将测量量大的协同请求排到测量量小的协同请求前面。
[0091]上述三种顺序条件可以由协同小区自身根据需要确定使用哪种;也可以根据高层通知确定使用哪种。
[0092]需要说明的是,上述顺序条件只是举例说明,任何能够将协同请求加入到请求队列的顺序条件都适用本发明实施例。
[0093]较佳地,可以周期确定所述请求队列中需要进行判断的协同请求,也可以在有协同请求加入到请求队列后,确定所述请求队列中需要进行判断的协同请求。
[0094]基于此,确定所述请求队列中需要进行判断的协同请求为所述请求队列中未进行判断的协同请求。也就是说,所述请求队列中没有判断是否成功的协同请求。
[0095]较佳地,在判断协同请求是否成功时,根据请求队列中协同请求的顺序依次确定。
[0096]针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;
[0097]判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;
[0098]若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。
[0099]对于失败的协同请求,不对其进行优先级排序,也不进行数据传输。
[0100]比如子帧A对应的请求队列中一个需要进行判断的协同请求B需要的资源为子帧A的PRB1、PRB2和PRB3。子帧A对应的请求队列中的特定协同请求为协同请求C和协同请求D。已分配给协同请求C的资源为PRBl和PRB4,已分配给协同请求D的资源为PRB5、PRB6、PRB7 和 PRB8。
[0101]其中,PRBl与已分配给特定协同请求的资源重叠,PRB2和PRB3不重叠,所以确定的资源和已分配给特定协同请求的资源的重叠比例为1/3 ;假设设定门限值为50%,则确定所述协同请求B成功。
[0102]还比如:比如子帧A对应的请求队列中一个需要进行判断的协同请求B需要的资源为子帧A的PRB1、PRB2和PRB3。子帧A对应的请求队列中的特定协同请求为协同请求C和协同请求D。已分配给协同请求C的资源为PRBl和PRB4,已分配给协同请求D的资源为 PRB2、PRB6、PRB7 和 PRB8。
[0103]其中,PRBl与已分配给特定协同请求的资源重叠,PRB3不重叠,所以确定的资源和已分配给特定协同请求的资源的重叠比例为2/3 ;假设设定门限值为50%,则确定所述协同请求B失败。
[0104]在确定了一个协同请求成功后,需要在确定该协同请求的优先级。
[0105]较佳地,针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。
[0106]比如协同请求B的资源为子帧A的PRBUPRB2和PRB3。协同请求C的资源为PRBl和 PRB4。
[0107]如果协同请求C的优先级已经确定,现在需要确定协同请求B的优先级。
[0108]由于协同请求B与协同请求C有重叠资源,所以协同请求B重叠比例不为0,则协同请求B的优先级比协同请求C低。假设优先级O最高,如果协同请求C的优先级是1,则协同请求B的优先级是2。
[0109]还比如协同请求B的资源为子帧A的PRB1、PRB2、PRB3、PRB4和PRB5。协同请求C的资源为PRBl和PRB4,协同请求D的资源为PRB2、PRB6、PRB7和PRB8。
[0110]如果协同请求C和协同请求D的优先级已经确定,现在需要确定协同请求B的优先级。
[0111]由于协同请求B与协同请求C和协同请求D均有重叠资源,所以协同请求B重叠比例不为0,则协同请求B的优先级比协同请求C和协同请求D都低。假设优先级O最高,如果协同请求C的优先级是I,协同请求D的优先级是2,则协同请求B的优先级为3。
[0112]还比如协同请求B的资源为子帧A的PRB3、PRB4和PRB5。协同请求C的资源为PRBl和PRB2,协同请求D的资源为PRB6、PRB7和PRB8。
[0113]由于协同请求B与协同请求C和协同请求D都没有重叠资源,所以协同请求B重叠比例为O。假设优先级O最高,则协同请求B的优先级为O。
[0114]较佳地,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据时,可以按照优先级顺序选取可用资源的位置进行数据传输。如果有一个协同请求的部分资源重叠,且该协同请求与资源重叠的其他协同请求相比优先级不是最高的,则在该子帧不传输该协同请求的数据。
[0115]比如协同请求B的资源为子帧A的PRB1、PRB2、PRB3、PRB4和PRB5。协同请求C的资源为PRBl和PRB4,协同请求D的资源为PRB4、PRB5、PRB6、PRB7和PRB8。
[0116]协同请求C的优先级是I,协同请求D的优先级是2,协同请求B的优先级为3。
[0117]按照优先级传输顺序,在子帧A的PRBl和PRB4传输协同请求C的数据,由于PRB4已经被优先级高的协同请求C占用,所以协同请求D的数据不在PRB4上传输,只能在PRB5、PRB6、PRB7和PRB8上传输;由于PRBl和PRB4、PRB5已经被优先级高的协同请求C与D占用,所以协同请求B的数据不在PRB1、PRB4、PRB5上传输,只能在PRB2、PRB3上传输。
[0118]在实施中,有可能因为某些原因会取消协同传输,下面列举几种取消的情况。
[0119]1、需要发送重传“
[0120]考虑重传数据不进行CoMP传输,即重传数据块只以Μηω(多输入多输出)方式(即非协作传输方式)进行重传,因此,如果服务小区在某协同传输子帧需要发送重传数据,则服务小区会向协作小区发送协作取消消息。
[0121]2、没有可用 HARQ (Hybrid Automatic Repeat reQuest,混合自动重传请求)进程:
[0122]此外,在组织MACPDU(Medium Access Control Packet Data Unit,媒体接入控制协议数据单元)时刻,需要预先占用一个HARQ进程,以保证对协同传输子帧的实际调度时刻(是指向UE发送下行调度授权)到达时,可以成功进行CoMP传输。如果在组织MAC PDU时刻,没有可用HARQ进程,则服务小区也会向协作小区发送协作取消消息。
[0123]3、发送数据缓存为空:
[0124]如果在组织MAC PDU时刻,存在空闲HARQ进程,但恰好此时UE缓存数据量为空,没有数据可以下发,则此时也无法组织MAC rou,那么服务小区也会向协作小区发送协作取消消息。
[0125]所以若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
[0126]释放的资源可以给优先级在后的协同请求使用。
[0127]比如协同请求B的资源为子帧A的PRB1、PRB2、PRB3、PRB4和PRB5。协同请求C的资源为PRBl和PRB4,协同请求D的资源为PRB4、PRB6、PRB7和PRB8。
[0128]协同请求C的优先级是I,协同请求D的优先级是2,协同请求B的优先级为3。
[0129]假设需要释放协同请求C:
[0130]本来按照优先级传输顺序,在子帧A的PRBl和PRB4传输协同请求C的数据,由于PRB4已经被优先级高的协同请求C占用,所以协同请求D的数据不在PRB4上传输;由于PRBl已经被优先级高的协同请求C占用,所以协同请求B的数据不在PRBl上传输。但是由于需要释放协同请求C,则协同请求C占用的子帧A的PRBl和PRB4也会释放;相应的,在子帧A的PRB4、PRB6、PRB7和PRB8就可以传输协同请求D的数据;但是由于协同请求D的优先级高于协同请求B,则在子帧A的PRB1、PRB2、PRB3和PRB5就可以传输协同请求B的数据,而在PRB4上仍不可传输协同请求B的数据。
[0131 ] 下面列举几个实例,对本发明的方案进行详细说明。
[0132]实例1、协同小区处理协同请求消息方法I。
[0133]一个eNB内有三个小区,UE测量请求协同的小区可能处于本eNB内,也可能处于本eNB外的其他eNB内。
[0134]由于eNB之间存在X2/S1接口,信令与数据在接口上传递存在时延。此时eNB站内的协同请求发送速度快于eNB站间的发送速度,并且不同的eNB站间传输速度也不一样。
[0135]为了保证协同请求消息的公平性,设置协同消息处理周期。当一个周期结束时,处理该周期收到的所有协同请求。
[0136]处理协同请求的方式,可以使随机顺序。该方法最大程度保证了所有协同请求的公平,避免总是站内优先处理的弊端。
[0137]实例2、协同小区处理协同请求消息方法2。
[0138]为了尽量提高系统的总吞吐量,可以尽量将在服务小区较边缘的UE排在前面优先分配资源。当UE在服务小区处于较边缘的位置时,则更近的接近了进行协同传输的邻小区,该UE测量协同邻区的RSRP值也就更高。
[0139]如图2B所示,对于UEl和UE2,服务小区属于eNBl,而协同小区属于eNB2。由于UEl更接近服务小区边缘,该UE更需要进行CoMP传输以提高边缘吞吐量。而UE2相比于UEl稍微靠近服务小区中心,虽然也可以进行CoMP传输,但传输需求没有UEl大。
[0140]由于UEl更靠近eNB2,此时UEl测量协同小区的RSRP大于UE2测得的协同邻区RSRP0
[0141]当eNB2同时收到来自eNBl的这两个UE的协同请求后,可以根据其中携带的各UE针对该协同邻区的RSRP测量量进行排序,以获得对于协同邻区信号质量更优的UE进行CoMP传输。此时排在前面的UE测量得到的RSRP更优,意味着该UE与协同邻区之间传输的信号质量更好,传输成功概率较高。并且该UE离服务小区较远的可能性较高,更需要进行CoMP协同传输来提高边缘吞吐量。
[0142]实例3:协同小区处理单个UE请求。
[0143]当协同小区按照一定顺序处理协同请求时,来自不同服务小区的UE请求的PRB可能有交置。
[0144]当UE请求的资源位置与已经分配出去的资源位置有重叠时,如果重叠比例低于一定门限,允许该协同成功。如果重叠比例过高,意味着协同小区只能在极少的资源上传输数据,这样即使多小区信号合并处理后的增益也不高,则直接判决为协同失败。
[0145]协同小区在每次判决该UE协同成功后,需要确定UE的优先级。
[0146]较佳地,需要确定UE的优先级时,可以将UE加入到优先级队列中。
[0147]比如协同小区在每次判决该UE协同成功后,将UE排入优先级队列。优先级的设置方式如下:
[0148]-针对该UE的所有协作子帧进行遍历。针对每个协作子帧,将该UE放入保存的UE队列:如果请求的所有PRB与当前子帧已经分配的所有PRB均不冲突,则将优先级记为O ;如果存在部分PRB冲突,则将优先级记为所有与之冲突的记录的UE优先级中的最大值+1 (数值越大优先级越低);
[0149]-按照优先级从低到高的顺序传输。
[0150]当进行数据传输时,如果多于I个UE均请求占用相同的PRB资源,则按照优先级顺序,优先级取值最小的UE在该资源上进行数据传输,其他UE则需避开该资源,在剩余的其他资源上进行传输,保证在一块资源上数据传输的唯一性。
[0151]实施例4:收到取消消息后的处理.
[0152]由于一些情况可能服务小区会发送取消消息到协同小区,取消某UE的CoMP传输。当协同小区收到了取消消息之后,删除相应UE在UE列表中保存的记录。
[0153]如果UE在该位置上允许传输数据,则该资源位置将释放给其后次高优先级的UE使用;
[0154]如果UE在该位置上为优先级稍低的候选UE,则其后优先级的UE的优先级次数往前顺延。
[0155]由于同一块资源上可能有交叠的UE存在,根据优先级可以判定取消的UE是当前排在优先级最高的使用该资源传输数据的UE,还是该资源上较低优先级的备选UE。由于不同UE在交叠的PRB资源上保存有完全不同的优先级,则可以确定后续选择在该资源上进行传输的UE的唯一性。
[0156]基于同一发明构思,本发明实施例中还提供了一种进行协同传输的设备,由于该设备解决问题的原理与本发明实施例进行协同传输的方法相似,因此该设备的实施可以参见方法的实施,重复之处不再赘述。
[0157]如图3所示,本发明实施例二进行协同传输的设备包括:请求确定模块300、判断模块301、优先级确定模块302和传输模块303。
[0158]请求确定模块300,用于针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧;
[0159]判断模块301,用于按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;
[0160]优先级确定模块302,用于确定成功的协同请求的优先级;
[0161]传输模块303,用于在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。
[0162]较佳地,所述请求确定模块300还用于:
[0163]确定所述请求队列中需要进行判断的协同请求之前,在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。
[0164]较佳地,所述请求确定模块300具体用于:
[0165]按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0166]随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0167]按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0168]较佳地,所述请求确定模块300具体用于:
[0169]将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。
[0170]较佳地,所述判断模块301具体用于:
[0171]针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。
[0172]较佳地,所述优先级确定模块302具体用于:
[0173]针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。
[0174]较佳地,所述传输模块303还用于:
[0175]需要传输所述协同请求对应的数据之前,若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
[0176]如图4所示,本发明实施例三进行协同传输的设备包括:
[0177]处理器401,用于读取存储器404中的程序,执行下列过程:
[0178]针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧;按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;确定成功的协同请求的优先级;在需要传输所述协同请求对应的数据时,通过收发机402在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。
[0179]收发机402,用于在处理器401的控制下接收和发送数据。
[0180]较佳地,所述处理器401还用于:
[0181]确定所述请求队列中需要进行判断的协同请求之前,在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。
[0182]较佳地,所述处理器401具体用于:
[0183]按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0184]随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或
[0185]按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。
[0186]较佳地,所述处理器401具体用于:
[0187]将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。
[0188]较佳地,所述处理器401具体用于:
[0189]针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。
[0190]较佳地,所述处理器401具体用于:
[0191]针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。
[0192]较佳地,所述处理器401还用于:
[0193]需要传输所述协同请求对应的数据之前,若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
[0194]在图4中,总线架构(用总线400来代表),总线400可以包括任意数量的互联的总线和桥,总线400将包括由处理器401代表的一个或多个处理器和存储器404代表的存储器的各种电路链接在一起。总线400还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口 403在总线400和收发机402之间提供接口。收发机402可以是一个元件,也可以是多个元件,比如多个接收器和发送器,提供用于在传输介质上与各种其他装置通信的单元。经处理器401处理的数据通过天线405在无线介质上进行传输,进一步,天线405还接收数据并将数据传送给处理器401。
[0195]处理器401负责管理总线400和通常的处理,还可以提供各种功能,包括定时,外围接口,电压调节、电源管理以及其他控制功能。而存储器404可以被用于存储处理器401在执行操作时所使用的数据。
[0196]可选的,处理器401可以是CPU(中央处埋器)、ASIC(Applicat1n SpecificIntegrated Circuit,专用集成电路)、FPGA (Field — Programmable Gate Array,现场可编程门阵列)或CPLD (Complex Programmable Logic Device,复杂可编程逻辑器件)。
[0197]从上述实施例可以看出:本发明实施例针对一个子帧对应的请求队列,按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功;确定成功的协同请求的优先级;在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。由于能够按照优先级顺序传输对应同一个子帧的协同请求的数据,从而在收到多个针对同一帧的协同请求后实现进行协同传输,提高了系统性能。
[0198]显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
【主权项】
1.一种进行协同传输的方法,其特征在于,该方法包括: 针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧; 按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功; 确定成功的协同请求的优先级; 在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。2.如权利要求1所述的方法,其特征在于,所述确定所述请求队列中需要进行判断的协同请求之前,还包括: 在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。3.如权利要求2所述的方法,其特征在于,将所述协同请求加入到确定的所述子帧对应的所述请求队列中,包括: 按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或 随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。4.如权利要求1所述的方法,其特征在于,所述确定所述请求队列中需要进行判断的协同请求,包括: 将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。5.如权利要求1所述的方法,其特征在于,依次判断协同请求是否成功,包括: 针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源; 判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求; 若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。6.如权利要求5所述的方法,其特征在于,确定成功的协同请求的优先级,包括: 针对一个成功的协同请求,若成功的协同请求重叠比例不为O,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为O,则确定所述成功的协同请求的优先级为最高优先级。7.如权利要求5所述的方法,其特征在于,确定成功的协同请求的优先级之后,需要传输所述协同请求对应的数据之前,还包括: 若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。8.一种进行协同传输的设备,其特征在于,该设备包括: 请求确定模块,用于针对一个子帧对应的请求队列,确定所述请求队列中需要进行判断的协同请求,其中所述子帧对应的请求队列中的每个协同请求对应所述子帧; 判断模块,用于按照需要进行判断的协同请求在所述请求队列中的位置,依次判断协同请求是否成功; 优先级确定模块,用于确定成功的协同请求的优先级; 传输模块,用于在需要传输所述协同请求对应的数据时,在所述子帧的每块资源上传输对应的成功的协同请求中优先级最高的协同请求对应的数据。9.如权利要求8所述的设备,其特征在于,所述请求确定模块还用于: 确定所述请求队列中需要进行判断的协同请求之前,在收到一个协同请求后,确定收到的所述协同请求对应的子帧,并将所述协同请求加入到确定的所述子帧对应的所述请求队列中。10.如权利要求9所述的设备,其特征在于,所述请求确定模块具体用于: 按照接收所述协同请求的时间,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或 随机将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上;或 按照接收到的所述协同请求中的终端测量小区的测量量大小,将所述协同请求加入到确定的所述子帧对应的所述请求队列对应的位置上。11.如权利要求8所述的设备,其特征在于,所述请求确定模块具体用于: 将所述请求队列中未进行判断的协同请求作为需要进行判断的协同请求。12.如权利要求8所述的设备,其特征在于,所述判断模块具体用于: 针对一个需要进行判断的协同请求,确定需要为所述协同请求分配的资源;判断确定的资源和已分配给特定协同请求的资源的重叠比例,其中所述特定协同请求为与所述需要进行判断的协同请求对应同一个子帧的所有协同请求;若所述重叠比例小于设定门限值,则确定所述协同请求成功;否则,确定所述协同请求失败。13.如权利要求12所述的设备,其特征在于,所述优先级确定模块具体用于: 针对一个成功的协同请求,若成功的协同请求重叠比例不为0,则确定所述成功的协同请求的优先级比与其资源重叠的所有所述特定协同请求的优先级低;若成功的协同请求重叠比例为0,则确定所述成功的协同请求的优先级为最高优先级。14.如权利要求12所述的设备,其特征在于,所述传输模块还用于: 需要传输所述协同请求对应的数据之前,若需要取消成功的协同请求,删除所述需要取消成功的协同请求的优先级,并释放分配给所述需要取消成功的协同请求的资源。
【文档编号】H04W24/02GK105992253SQ201510085060
【公开日】2016年10月5日
【申请日】2015年2月16日
【发明人】彦楠, 李天宬
【申请人】电信科学技术研究院
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1