控制面资源调度方法和装置与流程

本发明涉及无线通信领域，特别是涉及一种控制面资源调度方法和装置。

背景技术：

随着移动互联应用的发展，移动实时通讯等OTT应用广泛普及，由于移动实时通讯软件表现出数据传输非连续但又存在频繁发送数据的需求，为了降低频繁发送导致初始接入压力过大等问题，现时移动通信网络中采用拉长终端失同步判定时长来克服该问题，即使得终端在完成数据传输后，下次数据传输假如在失同步时长范围内，则终端可以直接发送数据，无需重新执行接入过程，有效克服大量终端频繁接入导致空口侧及核心侧压力过大的问题。

然而，在拉长终端的失同步时长后，待调度的用户存在一个特征，那就是实际有调度需求的用户数不变，但数据调度完毕而失同步时长还没到的用户，依然在待调度用户队列中，导致调度过程需要检测的待调度用户数成倍激增。调度过程需检测在失同步时长内的所有接入用户，进而造成控制面(媒体接入控制层控制面)调度压力大。

技术实现要素：

基于此，有必要针对降低调度压力的控制面资源调度方法的装置。

一种控制面资源调度方法，包括：

获取调度请求；

将所述调度请求对应的用户放入业务队列中；

在对应的调度时刻，采用预设的调度算法，根据所述业务队列中的用户进行资源调度；

根据调度结果，将调度完成的用户从所述业务队列中删除，并放入空闲队列中。

在其中一个实施例中，还包括：

对所述空闲队列中的用户进行失同步判定；

若所述空闲队列中的用户在预设时长内未发送调度请求，则将所述用户从所述空闲队列中删除。

在其中一个实施例中，所述将所述调度请求对应的用户放入业务队列中的步骤为：

当获取到的调度请求为新用户的调度请求时，将对应的用户添加到业务队列；或

当获取到的调度请求为空闲队列中的用户的调度请求时，将对应的用户添加到业务队列。

在其中一个实施例中，在所述获取调度请求的步骤之前，还包括：

建立业务队列和空闲队列。

在其中一个实施例中，所述预设的调度算法包括比例平均调度算法、QoS调度算法、最大载干比算法和轮询调度算法中的任意一种。

一种控制面资源调度装置，包括：

获取模块，用于获取调度请求；

队列管理模块，用于将所述调度请求对应的用户放入业务队列中；

调度模块，用于在对应的调度时刻，采用预设的调度算法，根据所述业务队列中的用户进行资源调度；

所述队列管理模块，还用于根据调度结果，将调度完成的用户从所述业务队列中删除，并放入空闲队列中。

在其中一个实施例中，还包括：

失同步判定模块，用于对所述空闲队列中的用户进行失同步判定；

所述队列管理模块用于在所述失同步判定模块判定所述空闲队列中的用户在预设时长内未发送调度请求时，将所述用户从所述空闲队列中删除。

在其中一个实施例中，所述队列管理模块，用于当获取到的调度请求为新用户的调度请求时，将对应的用户添加到业务队列；或当获取到的调度请求为空闲队列中的用户的调度请求时，将对应的用户添加到业务队列。

在其中一个实施例中，所述队列管理模块，还用于在所述获取模块获取调度请求之前，建立业务队列和空闲队列。

在其中一个实施例中，所述预设的调度算法包括比例平均调度算法、QoS调度算法、最大载干比算法和轮询调度算法中的任意一种。

上述的控制面资源调度方法，将有调度需求的用户放入业务队列中，并对业务队列中的用户采用预设的调度算法进行资源调度，调度需求完成的用户放入空闲队列中。通过采用业务队列与空闲队列分离管理的机制，将有调度需求的用户和调度需求完成的用户分离管理，在调度过程中仅需要对业务队列中用户进行检测，避免检测在线而又调度完毕的用户的开销，大大提升了控制面调度能力。

附图说明

图1为一个实施例的控制面资源调度方法的流程图；

图2为一个实施例的控制面调度过程示意图；

图3为一个实施例的控制面资源调度装置的结构示意图；

图4为另一个实施例的控制面资源调度装置的结构示意图。

具体实施方式

在一个实施例中，提供一种控制面资源调度方法，该方法由基站执行，如图1所示，具体包括以下步骤：

S102：获取调度请求。

本实施例中的调度请求包括已接入的用户在其失同步时长内发送的调度请求和新用户在接入过程中产生的调度请求。调度请求分为上行调度请求和下行调度请求。

S104：将调度请求对应的用户放入业务队列中。

S106：在对应的调度时刻，采用预设的调度算法，根据业务队列中的用户进行资源调度。

本实施例中，预设的调度算法包括比例平均调度算法、QoS调度算法、最大载干比算法和轮询调度算法中的任意一种。

其中，轮询调度算法的基本思想就是认为小区内所有用户的调度优先级都是相等的，所有用户周期性地被调度，保证每个用户被调整概率相同。例如小区中有3个用户，采用轮询算法的调度器不会考虑每个用户所处的位置以及之前被调度的情况，只是简单地按照某个固定的调度顺序，如用户1、用户2、用户3、用户1、用户2、用户3……周期性地调度每个用户。因此轮询算法是一种典型的追求公开最大化的调度算法，实现起来比较简单。

最大载干比算法的基本思想是在每一个调度时刻，调度器会对所有待调度用户进行载干比的排序，然后调度器会选择信道质量最好的用户进行调度，这样保证系统总是能够调度到最好的用户，保证系统性能的最大化，资源利用率最高。可见，最大载干比算法是一种追求系统性能最大化的调度算法，在调度周期内把所有资源仙女湖给信号质量最好的终端，保证系统吞吐量可以达到最大值。

比例公平调度算法在尽量满足信道质量较好的终端的高速数据业务需求的同时，也兼顾信道质量状况不好的终端的使用体验，该算法的基本思想是选择用户时考虑瞬时速率和长期平均速率的比值，同时利用权重值对不同用户进行调整，达到同时兼顾系统性能和用户体验的目的。

QoS(Quality of Service，服务质量)调度算法通过控制不同类型的分组对链路带宽的使用，使不同的数据流得到不同等级的服务，包括先进先出队列、严格优先级调度算法、通用处理器共享算法和加权公平队列算法等。

预算的调度算法为以上中的任意一个。

S108：根据调度结果，将调度完成的用户从业务队列中删除，并放入空闲队列中。

本实施例中，有调度需求的用户放入业务队列中，并对业务队列中的用户采用预设的调度算法进行资源调度，调度需求完成的用户放入空闲队列中。通过采用业务队列与空闲队列分离管理的机制，将有调度需求的用户和调度需求完成的用户分离管理，在调度过程中仅需要对业务队列中用户进行检测，避免检测在线而又调度完毕的用户的开销，大大提升了控制面调度能力。

在另一个实施例中，还包括以下步骤：

步骤1：对空闲队列中的用户进行失同步判定。

步骤2：若空闲队列中的用户在预设时长内未发送调度请求，则将用户从空闲队列中删除。

由于业务队列中的用户在完成调度需求后，会从业务队列中被删除，被放入空闲队列中，因而本实施例的失同步判定只针对空闲队列的用户进行。若空间队列中的用户在预设时长内未发送调度请求，则将用户从空闲队列中删除。从而完成失同步判定。并且，由于失同步判定只针对空闲队列中的用户，无需对接入的全部用户进行失同步判定，从而提高了判定效率。

在另一个实施例，步骤S104包括：

当获取到的调度请求为新用户的调度请求时，将对应的用户添加到业务队列；或

当获取到的调度请求为空闲队列中的用户的调度请求时，将对应的用户添加到业务队列。

即，调度请求包括新用户在接入过程中产生的调度请求和已接入的位于空闲队列中用户产生的调度请求。

在另一个实施例中，在步骤S102之前，还包括步骤：建立业务队列和空闲队列。

建立的业务队列用于放入有调度需求的用户，空闲队列用于放入调度需求完成的用户。

在另一个实施例中，该步骤还可以为：建立上行业务队列、上行空闲队列、下行业务队列和下行业务队列。

在该实施方式中，上行业务队列用于放入上行调度过程中有调度需求的用户，上行空闲队列用于放入上行调度过程中调度需求完成的用户，下行业务队列用于放入下行调度过程中有调度需求的用户，下行空闲队列用于放入下行调度过程中调度需求完成的用户。

可以理解的是，在该实施方式中，后续的调度请求的处理，应当根据调度请求的类型，例如，是属于上行调度过程还是下行调度过程的需求，放入对应的队列中。例如，步骤S104为：根据调度请求确定调度请求的类型，并将调度请求对应的用户放入对应的上行业务队列或下行业务队列中。又例如，步骤S108为：根据调度结果，将调度完成的用户从对应的上行业务队列或下行业务队列中删除，并放入对应的上行空闲队列或下行空闲队列中。又例如，对上行空闲队列和下行空闲对列中的用户进行失同步判定，其它的队列处理类似，在此不再赘述。

本实施通过对上下行调度分别建立空闲队列和业务队列，上行的空闲队列和上行的业务队列管理上行调度过程中的调度请求的用户，下行的空闲队列和下行的业务队列管理下行调度过程中的调度请求的用户，从而能够避免上下行数据的相互干扰，并且，上下行调度数据分开进行管理，便于对上下行数据根据实际情况进行需要调整，适应性好。

下面，结合具体的实施方式对本发明的控制面资源调度方法进行详细说明。

在本实施例中包括三个用户，依次为用户0、用户1、用户2，用户失同步时长为(T3-T0)，从图2中可以看到，假如按照现有技术方案，用户完成调度之后，就把用户释放，则图2中从T0时刻到T3时刻这段时间，会由于三个用户反复释放而后又有调度需求而发起随机接入，而导致T0至T3这段时间总共发生了12次初始接入处理，因此，为了降低随机接入频度，降低用户有频繁发送需求导致初始接入压力过大等问题，现时移动通信网络中把失同步时间设置为(T3-T0)，此时可以看出，用户0在T0时刻做初始接入后，在T3时刻之前的另外3次调度请求，则无需做初始接入就能得到调度，有效降低系统初始接入压力，同样的，用户1在T1时刻完成初始接入后，后续三次调度请求无需做初始接入，用户2也是后续在T2时刻完成初始接入后，后续三次调度请求无需做初始接入，因此，采用拉长用户的失同步时长判定门限后，图2中初始接入次数由原来的12次降低到3次，有效降低用户有频繁发送需求导致初始接入压力过大等问题。

相应的，由于把用户的失同步时间判定门限拉长，因此，在T0到T3这段时间，三个用户都处于同步状态，也就是说，每个调度时刻，按照现有技术做法，得检测3个用户的调度请求，而后才能确定调度结果，这样势必由于没有实际调度需求而又处于同步状态的用户给调度过程造成检测的开销，进而导致调度效率下降，在密集的覆盖区域，由于人数较多，这种影响是难以承受的。

为了解决该问题，本发明创新性提出了队列分管方案，即先创建两个队列，一个为业务队列(对应还没调度完毕的用户)，一个为空闲队列(对应当前已调度完毕的用户)，T0时刻，用户0初始接入后，添加到业务队列，并完成调度，而后把用户0移到空闲队列。T1时刻，用户1完成初始接入后，添加到业务队列，此时虽然用户0处于同步状态，但是由于T0时刻已经确定其当前调度需求已调度完毕并移到空闲队列，因此T1时刻无需去检测用户0是否有调度需求，T1时刻只需检测业务队列中仅有的用户1，就可以实现调度，有效降低无谓的检测开销。同样的，T1时刻完成用户1的调度需求调度完毕后，调度模块把用户1从业务队列移到空闲队列；T2时刻，用户2完成初始接入后，添加到业务队列，此时虽然用户0、用户1处于同步状态，但是由于用户0、用户1当前调度请求已调度完毕而被移到空闲队列，因此，T2时刻只需检测业务队列中仅有的用户2，就可以实现调度，有效降低无谓的检测开销。依次类推，从而完成后续各个时刻的调度，当某用户在空闲队列中停留的时间大于失同步时长，则直接删除该用户。

因此，在拉长用户失同步时长降低初始接入压力的应用模式下，采用本发明的方法，通过引进业务队列与空闲队列分离管理的机制，避免了检测在线而又调度完毕之用户状态的开销，大大提升了控制面调度能力，有效适应拉长用户失同步时长的应用需求。

在一个实施例中，提供一种控制面资源调度装置，如图3所示，包括：

获取模块302，用于获取调度请求。

本实施例中的调度请求包括已接入的用户在其失同步时长内发送的调度请求和新用户在接入过程中产生的调度请求。调度请求分为上行调度请求和下行调度请求。

队列管理模块304，用于将调度请求对应的用户放入业务队列中。

调度模块306，用于在对应的调度时刻，采用预设的调度算法，根据业务队列中的用户进行资源调度。

本实施例中，预设的调度算法包括比例平均调度算法、QoS调度算法、最大载干比算法和轮询调度算法中的任意一种。

队列管理模块，还用于根据调度结果，将调度完成的用户从业务队列中删除，并放入空闲队列中。

本实施例中，有调度需求的用户放入业务队列中，并对业务队列中的用户采用预设的调度算法进行资源调度，调度需求完成的用户放入空闲队列中。通过采用业务队列与空闲队列分离管理的机制，将有调度需求的用户和调度需求完成的用户分离管理，在调度过程中仅需要对业务队列中用户进行检测，避免检测在线而又调度完毕的用户的开销，大大提升了控制面调度能力。

在另一个实施例中，如图4所示，控制面资源调度装置还包括失同步判定模块308。

失同步判定模块308，用于对空闲队列中的用户进行失同步判定。

队列管理模块304用于在失同步判定模块判定空闲队列中的用户在预设时长内未发送调度请求时，将用户从空闲队列中删除。

由于业务队列中的用户在完成调度需求后，会从业务队列中被删除，被放入空闲队列中，因而本实施例的失同步判定只针对空闲队列的用户进行。若空间队列中的用户在预设时长内未发送调度请求，则将用户从空闲队列中删除。从而完成失同步判定。并且，由于失同步判定只针对空闲队列中的用户，无需对接入的全部用户进行失同步判定，从而提高了判定效率。

在另一个实施例中，队列管理模块304，用于当获取到的调度请求为新用户的调度请求时，将对应的用户添加到业务队列；或当获取到的调度请求为空闲队列中的用户的调度请求时，将对应的用户添加到业务队列。

在另一个实施例中，队列管理模块304，还用于在获取模块获取调度请求之前，建立业务队列和空闲队列。

建立的业务队列用于放入有调度需求的用户，空闲队列用于放入调度需求完成的用户。

在另一个实施例中，队列管理模块304，用于建立上行业务队列、上行空闲队列、下行业务队列和下行业务队列。

在该实施方式中，上行业务队列用于放入上行调度过程中有调度需求的用户，上行空闲队列用于放入上行调度过程中调度需求完成的用户，下行业务队列用于放入下行调度过程中有调度需求的用户，下行空闲队列用于放入下行调度过程中调度需求完成的用户。

可以理解的是，在该实施方式中，后续的调度请求的处理，应当根据调度请求的类型，例如，是属于上行调度过程还是下行调度过程的需求，放入对应的队列中。例如，队列管理模块304用于根据调度请求确定调度请求的类型，并将调度请求对应的用户放入对应的上行业务队列或下行业务队列中。又例如，队列管理模块304根据调度结果，将调度完成的用户从对应的上行业务队列或下行业务队列中删除，并放入对应的上行空闲队列或下行空闲队列中。又例如，对上行空闲队列和下行空闲对列中的用户进行失同步判定，其它的队列处理类似，在此不再赘述。

本实施通过对上下行调度分别建立空闲队列和业务队列，上行的空闲队列和上行的业务队列管理上行调度过程中的调度请求的用户，下行的空闲队列和下行的业务队列管理下行调度过程中的调度请求的用户，从而能够避免上下行数据的相互干扰，并且，上下行调度数据分开进行管理，便于对上下行数据根据实际情况进行需要调整，适应性好。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。