CN105992360A - 一种资源分配方法及装置 - Google Patents

Abstract

本发明公开了一种资源分配方法及装置，用以提升CoMP协作成功率，对现有的协作资源分配流程进行改进，实现对同一UE的同一次请求的协作资源进行多次分配的过程，无需设置较大的协作资源预留门限，从而能够在提高协作资源分配率的同时，又使得中心用户吞吐量不受影响。本发明提供的一种资源分配方法，包括：当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；当满足预设条件时，再次为该用户设备进行协作资源分配。

Description

一种资源分配方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种资源分配方法及装置。

背景技术

协作多点传输和接收(Coordinated Multi-Point transmission/reception，CoMP)技术通过多个小区的联合调度或者协作传输，提高用户设备(UserEquipment，UE)接收信号质量，降低小区间的干扰，从而有效提高系统容量和边缘用户频谱效率。而实现协作多点传输的核心问题是如何让多个逻辑独立的小区实现资源的协作分配和调度。目前，已有的协作和分配调度算法可以分为两大类：集中式分配和分布式分配方式。前者集中式分配，即网络中存在一个集中的控制节点，为CoMP用户设备在多个协作小区统一分配资源；而后者，即分布式资源分配方式，则是需要多小区之间进行协商调度，即通过小区间互相协商调度信息实现协作多点传输。

但不管是哪种分配方式，现有的分配方法中，对于同一UE请求的协作资源仅进行一次分配过程，若一次分配失败，则后续不会再对该UE的本次请求的协作资源进行分配。譬如，假设为了保证一个小区内中心用户的调度资源不会被边缘用户过多抢占，通常会设立一个给协作用户可用资源门限。若协作资源分配过程中，已经用于协同调度的资源超过了最大协作资源预留门限，则将拒绝后续的UE协作调度请求，即便后续因为中心UE调度完成后系统存在大量剩余资源也不可以再次为协作UE所利用。因此导致协作资源成功率不高的问题。另一方面，若优先考虑协作资源分配，配置一个较大的协作资源预留门限，使得协作资源分配率提高，但同时又会对中心用户造成影响。

综上所述，现有技术中的协作资源分配方案，分配方式不够合理，无法在提高协作资源分配率的同时，使得中心用户吞吐量不受影响。

发明内容

本发明实施例提供了一种资源分配方法及装置，用以提升CoMP协作成功率，对现有的协作资源分配流程进行改进，实现对同一UE的同一次请求的协作资源进行多次分配的过程，无需设置较大的协作资源预留门限，从而能够在提高协作资源分配率的同时，又使得中心用户吞吐量不受影响。

本发明实施例提供的一种资源分配方法，包括：

当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

当满足预设条件时，再次为该用户设备进行协作资源分配。

因此，通过该方法，当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；当满足预设条件时，再次为该用户设备进行协作资源分配，从而提升CoMP协作成功率，与现有的对同一UE的同一次请求的协作资源进行一次分配的方案相比，本发明实施例提供的该方法实现了对同一UE的同一次请求的协作资源进行多次分配的过程，并且无需设置较大的协作资源预留门限，从而能够在提高协作资源分配率的同时，又使得中心用户吞吐量不受影响。

较佳地，将该用户设备的协作调度请求进行缓存，包括：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

较佳地，所述预设条件包括：

针对非协作用户设备的资源调度完成。

较佳地，再次为该用户设备进行协作资源分配，包括：

若该用户设备请求的协作资源已经被非协作用户设备占用，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

较佳地，当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在当满足预设条件时，再次为该用户设备进行协作资源分配之前，该方法还包括：

降低该用户设备请求的协作资源的调度优先级。

本发明实施例提供的一种资源分配装置，包括：

第一单元，用于当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

第二单元，用于当满足预设条件时，再次为该用户设备进行协作资源分配。

较佳的，第一单元将该用户设备的协作调度请求进行缓存时，具体用于：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

较佳的，所述预设条件包括：

针对非协作用户设备的资源调度完成。

较佳的，第二单元再次为该用户设备进行协作资源分配时，具体用于：

若该用户设备请求的协作资源已经被非协作用户设备占用，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

较佳的，第一单元还用于：

当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在第二单元当满足预设条件时，再次为该用户设备进行协作资源分配之前，降低该用户设备请求的协作资源的调度优先级。

附图说明

图1为本发明实施例提供的一种资源分配方法的流程示意图；

图2为本发明实施例提供的资源分配方法中的非协作资源的调度流程示意图；

图3为本发明实施例提供的资源分配方法中的第二次资源分配流程示意图；

图4为本发明实施例提供的一种资源分配装置的结构示意图；

图5为本发明实施例提供的第二种资源分配装置的结构示意图。

具体实施方式

本发明实施例提供了一种资源分配方法及装置，用以提升CoMP协作成功率，对现有的协作资源分配流程进行改进，实现对同一UE的同一次请求的协作资源进行多次分配的过程，无需设置较大的协作资源预留门限，从而能够在提高协作资源分配率的同时，又使得中心用户吞吐量不受影响，最终提升CoMP传输的性能。本发明实施例提供的技术方案，既可用于上行链路的资源分配，也可用于下行链路的资源分配。

本发明实施例提出的技术方案，实现对同一UE的同一次请求的协作资源进行多次分配的过程，较佳地，对同一UE的同一次请求的协作资源可以进行两次的协作资源分配，即协作资源第一次分配失败后，并不意味该UE的CoMP协作调度请求会被立即拒绝，而是会将CoMP协作调度请求先缓存起来，等到在完成对非协作UE的非协作资源调度后，如果还有剩余资源，仍可以继续考虑是否接受先前缓存的CoMP协作调度请求，如果在该时刻，CoMP协作调度请求仍然不能被接受，则确定该CoMP协作调度请求被拒绝。该方案可以提高CoMP UE(使用CoMP传输的UE)的资源分配成功率，最终提升CoMP传输的性能。该方案既可用于上行链路的资源分配，也可用于下行链路的资源分配。

参见图1，本发明实施例提供的一种资源分配方法，包括步骤：

S101、当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

其中，所述用户设备为CoMP UE，所述协作调度请求即CoMP协作调度请求。

执行该资源分配方法的主体(资源分配节点)，可以是基站，也可以是基站的上一级节点，即集中控制节点。例如，若具体的资源分配方式为集中式分配方式，则资源分配节点为处于网络中的集中控制节点，统一进行资源分配；若具体的资源分配方式为分布式分配方式，服务小区在收到邻区的用户设备发送的CoMP协作调度请求消息后(此时，服务小区被邻区视为其协作小区)，将为该邻区的用户设备进行资源分配，此时服务小区中的基站为资源分配节点。

S102、当满足预设条件时，再次为该用户设备进行协作资源分配。

因此，通过该方法，当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；当满足预设条件时，再次为该用户设备进行协作资源分配，从而提升CoMP协作成功率，与现有的对同一UE的同一次请求的协作资源进行一次分配的方案相比，本发明实施例提供的该方法实现了对同一UE的同一次请求的协作资源进行多次分配的过程，并且无需设置较大的协作资源预留门限，从而能够在提高协作资源分配率的同时，又使得中心用户吞吐量不受影响。

本发明实施例中，可以将用户设备的协作调度请求缓存到预设队列(以下可以称为队列Qsuspend)中，在该队列中，可以按照接收到用户设备的协作调度请求的时间的先后顺序进行排列，在再次的协作资源分配过程中，可以按照该时间的先后顺序分别进行再次分配，对于再次分配失败的用户设备，可以从该队列中删除缓存的该用户设备的协作调度请求，也可以暂时保留，后续可以继续尝试对其进行协作资源分配。对于再次分配成功的用户设备，可以从该队列中删除缓存的该用户设备的协作调度请求。

较佳地，将该用户设备的协作调度请求进行缓存，包括：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

其中，所述协作资源，例如为物理资源块(Physical Resource Block，PRB)，那么将该用户设备请求的协作资源进行缓存，具体包括缓存该用户设备请求的PRB的个数以及位置(或者称为编号)等信息。

较佳地，所述预设条件包括：

针对非协作用户设备的资源调度完成。

其中，可以是等到所有或者一部分的非协作用户设备的资源调度完成后，再次为缓存队列中的用户设备进行协作资源分配。或者，所述预设条件也可以为时间条件，例如可以预设一等待时长，将用户设备的协作调度请求添加到预设队列中的同时启动一定时器，当该定时器超时时，再次处理该用户设备的协作调度请求，即再次为该用户设备进行协作资源分配。该定时器的定时时长为所述预设的等待时长。

较佳地，再次为该用户设备进行协作资源分配，包括：

若该用户设备请求的协作资源已经被非协作用户设备占用，即在为协作用户设备进行协作资源分配后，会进行非协作用户设备的非协作资源的分配，若在该分配过程中，协作用户设备请求的资源被分配给了非协作用户设备，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

需要说明的是，本发明实施例中所述的协作资源和非协作资源可以为同一资源，在资源分配节点中不作区分，本发明实施例只是为了区分表述，针对协作UE分配的资源称为协作资源，针对非协作UE分配的资源称为非协作资源，但资源分配节点中不会预先分配好哪些资源是协作资源，哪些资源是非协作资源。

并且，本发明实施例资源分配节点在对任一UE进行具体的资源分配时所采用的分配规则或者分配算法与现有技术相同，即本发明实施例中为该用户设备进行首次协作资源分配所采用的具体分配方式，以及再次为该用户设备进行协作资源分配所采用的具体分配方式，与现有技术相同，在此不再进行赘述。

较佳地，当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在当满足预设条件时，再次为该用户设备进行协作资源分配之前，该方法还包括：

降低该用户设备请求的协作资源的调度优先级，具体降低的幅度，可以根据实际需要而定，具体的降低方式，可以是预设一固定值，对于所有资源，当需要降低其调度优先级时，都按照该固定值进行降低，或者也可以划分多个区间段，对于不同的调度优先级的资源，可以降低不同幅度，因此具体实现起来更加灵活，使得资源分配方案更加合理。

通过降低该用户设备请求的协作资源的调度优先级，从而可以使得协作用户设备请求的协作资源，不会轻易分配给非协作用户设备，相当于先为该协作用户设备预留其请求的资源，以尽量保证满足该协作用户设备的请求。

关于上述步骤S101中的首次协作资源分配，若分配失败，则之后进行非协作资源的调度，具体包括的步骤，例如，参见图2，包括：

查询队列Qsuspend，并判断队列Qsuspend是否为空，若为空，则调用现有LTE调度算法为非协作用户设备进行资源分配。若不为空，则确定队列Qsuspend中的UE所请求预留的资源构成的资源集合R1，并降低资源集合R1中的PRB的调度优先级，然后，调用现有的LTE调度算法为非协作用户设备进行资源分配。

其中，降低资源集合R1中的PRB的调度优先级，是为了使得缓存的PRB尽量不会后续非协作用户占用，需要人为将该缓存的PRB进行调度权值降低。即在后续进行非协作用户调度时，对于该非协作用户而言，缓存的PRB的调度需要人为降低一个deltaP(该值为正)，即若某缓存PRB其调度权值初始为P，则经过人为降低后变为P-deltaP，使得该非调度用户调度过程中，优先选择未被缓存的PRB，尽量避开被缓存的PRB资源。

关于协作资源进行再次分配的过程，通常在所有非协作用户调度完成后，再来处理该流程。参见图3，其流程如下：

资源分配节点获取缓存的队列Qsuspend。

判断队列Qsuspend是否为空，若队列Qsuspend非空，则依次对该队列中的每一个UE执行以下步骤：若预先缓存的PRB指示的资源已经被非协作用户设备占用，则确认协作资源分配失败；否则，确认再次协作资源分配成功，事先缓存的资源此时真正变成协作资源。

若队列Qsuspend为空，则说明不需要对协作UE进行再次的协作资源分配，则结束该流程。

综上所述，下面给出分布式分配方式的一个实施例来说明：

假设：在10MHz带宽的LTE-TDD系统中，频率上分为50个基本调度单元，有3个小区。假设各小区优先进行协作资源分配，再进行非协作资源分配。

实施步骤如下：

步骤一：各小区限定最多用于邻区协作传输的资源(即协作资源)数目为15个PRB。

步骤二：各个小区分别确定本小区协作用户设备并对本小区协作用户设备进行协调资源调度，对应的协调资源调度结果举例如下：

假设第一小区有协作用户设备：第一UE，对应的协作小区为{第一小区,第二小区}；为第一UE分配的资源为PRB1-15，即编号从1到15的PRB资源；

假设第三小区有协作用户设备：第三UE，对应的协作小区为{第二小区,第三小区}；为第三UE分配的资源为PRB16-30，即编号从16到30的PRB资源；

步骤三：分配协作资源后，第二小区将收到从第一小区的第一UE和第三小区的第三UE的资源协作请求(即协作调度请求)，第一UE因为正好满足资源门限，因此第一UE的协作调度请求接纳成功。而对于第三UE，因协作资源占用已经达到门限，因此该第三UE的协作调度请求将被暂时预留，即PRB16-30将被预留。后续第二小区再进行非调度资源分配。假设其仅有一个第二UE，此时PRB16-50都是空闲的，PRB16-30的调度优先级要低。若该第二UE的非协作资源的调度过程中，需要15个PRB，且PRB分配占用了PRB31-45，则PRB16-30依然为空闲，则后续还可以对第三UE再次协作资源分配，且可以成功。若第二UE的资源调度过程中，需要的资源较多，将为第三UE预留的PRB16-30也都占用，则第三UE的再次协作资源分配无法成功，导致第三UE的协作调度请求最终无法成功。

参见图4，本发明实施例提供的一种资源分配装置，包括：

第一单元11，用于当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

第二单元12，用于当满足预设条件时，再次为该用户设备进行协作资源分配。

较佳的，第一单元将该用户设备的协作调度请求进行缓存时，具体用于：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

较佳的，所述预设条件包括：

针对非协作用户设备的资源调度完成。

较佳的，第二单元再次为该用户设备进行协作资源分配时，具体用于：

若该用户设备请求的协作资源已经被非协作用户设备占用，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

较佳的，第一单元还用于：

当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在第二单元当满足预设条件时，再次为该用户设备进行协作资源分配之前，降低该用户设备请求的协作资源的调度优先级。

以上各单元均可以由处理器等实体装置实现。

参见图5，本发明实施例提供的另一种资源分配装置，包括：

处理器500，用于读取存储器520中的程序，执行下列过程：

当通过收发机510接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

当满足预设条件时，再次为该用户设备进行协作资源分配。

较佳地，处理器500将该用户设备的协作调度请求进行缓存时，具体用于：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

较佳地，所述预设条件包括：

针对非协作用户设备的资源调度完成。

较佳地，处理器500再次为该用户设备进行协作资源分配时，具体用于：

若该用户设备请求的协作资源已经被非协作用户设备占用，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

较佳地，处理器500还用于：当通过收发机510接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在当满足预设条件时，再次为该用户设备进行协作资源分配之前，降低该用户设备请求的协作资源的调度优先级。

收发机510，用于在处理器500的控制下接收和发送数据。

其中，在图5中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器500代表的一个或多个处理器和存储器520代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机510可以是多个元件，即包括发送机和收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器500负责管理总线架构和通常的处理，存储器520可以存储处理器500在执行操作时所使用的数据。

本发明实施例所述的资源分配装置，可以是基站，也可以是集中控制节点。

综上所述，本发明实施例提出一种改进的用于提升CoMP协作成功率的方法和装置，对于现有的协作资源分配流程进行改进，在对协作资源分配过程中，进行再次分配过程，即协作资源第一次分配失败后，并不意味该用户的CoMP协作调度请求会被立即拒绝，而是会将CoMP协作调度请求先缓存起来，等到非协作资源在完成非协作用户调度后，如果还有剩余资源，仍可以继续考虑是否接受先前缓存的CoMP协作调度请求，如果在该时刻，CoMP协作调度请求仍然不能被接受，则确定该CoMP协作调度请求被拒绝。本发明可以提高CoMPUE(使用CoMP传输的UE)资源分配成功率，最终提升CoMP传输的性能。该方法既可用于上行链路的资源分配，也可用于下行链路的资源分配。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种资源分配方法，其特征在于，该方法包括：

当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

当满足预设条件时，再次为该用户设备进行协作资源分配。

2.根据权利要求1所述的方法，其特征在于，将该用户设备的协作调度请求进行缓存，包括：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

3.根据权利要求1所述的方法，其特征在于，所述预设条件包括：

针对非协作用户设备的资源调度完成。

4.根据权利要求3所述的方法，其特征在于，再次为该用户设备进行协作资源分配，包括：

若该用户设备请求的协作资源已经被非协作用户设备占用，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

5.根据权利要求1所述的方法，其特征在于，当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在当满足预设条件时，再次为该用户设备进行协作资源分配之前，该方法还包括：

降低该用户设备请求的协作资源的调度优先级。

6.一种资源分配装置，其特征在于，包括：

第一单元，用于当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，将该用户设备的协作调度请求进行缓存；

第二单元，用于当满足预设条件时，再次为该用户设备进行协作资源分配。

7.根据权利要求6所述的装置，其特征在于，第一单元将该用户设备的协作调度请求进行缓存时，具体用于：

将该用户设备的协作调度请求中携带的用户设备的标识以及该用户设备请求的协作资源进行缓存。

8.根据权利要求6所述的装置，其特征在于，所述预设条件包括：

针对非协作用户设备的资源调度完成。

9.根据权利要求8所述的装置，其特征在于，第二单元再次为该用户设备进行协作资源分配时，具体用于：

若该用户设备请求的协作资源已经被非协作用户设备占用，则确定为该用户设备协作资源分配失败；否则，将该用户设备请求的协作资源分配给该用户设备。

10.根据权利要求6所述的装置，其特征在于，第一单元还用于：

当接收到用户设备的协作调度请求，为该用户设备进行首次协作资源分配失败时，并且，在第二单元当满足预设条件时，再次为该用户设备进行协作资源分配之前，降低该用户设备请求的协作资源的调度优先级。