CN103987120B - Lte公网下集群多媒体业务下行无线资源调度方法 - Google Patents

Abstract

LTE公网下集群多媒体业务下行无线资源调度方法，涉及无线资源调度技术。本发明为了实现在LTE公网下传输集群多媒体业务，在满足集群通信用户优先级特点的前提下，同时支持多媒体业务的QoS特性。按用户优先级对业务流进行依次调度，选择用户优先级P＝1的业务流，优先保证实时多媒体业务流的QoS特性，判断对选择的实时业务流使用PF算法进行调度；用户优先级为1的实时业务流的调度后，PRB还有剩余由高到低依次对其他用户优先级的实时业务流进行调度；按用户优先级高低的顺序完成对实时业务流的调度后，开始调度非实时业务流。本发明基于DTLCP算法实现的，在保障高用户优先级实时业务的丢包率和延时等QoS特性上，有更好的性能。

Description

LTE公网下集群多媒体业务下行无线资源调度方法

技术领域

本发明涉及一种LTE公网下集群多媒体业务下行无线资源调度方法，涉及无线资源调度技术。

背景技术

DTLC(Discrete Time Line Control)理论，如图1所示，令t_k,i为第i个实时业务流的第k个帧开始的时间，于是有采样间隔△t(k)＝t_k+1,i-t_k,i等于LTE帧的持续时间。由框图可得：q_i(k+1)-q_i(k)＝d_i(k)-u_i(k)。其中，q_i(k)为第i个队列在t_k,i时刻的长度，u_i(k)为在第k个帧时间内要传输的数据量，d_i(k)表示在第k个帧时间内新填充到队列中的数据量。我们假设有以下的一般控制法则：u_i(k)＝h_i(k)^*q_i(k)，其中“*”运算为离散时间卷积。H_i(z)为h_i(k)的Z变换，即用h_si(k)表示系统的冲击响应，所以有q_i(k)＝h_si(k)*d_i(k)。我们设计的目的是找到合适的函数H_i(z)，来确保系统的BIBO(Bounded InputBounded Output，有限输入有限输出)稳定性，并保证队列的时延。

利用这样一个定理：在BIBO稳定的系统下，为了保障第i个队列的延时小于M_i+1个采样间隔，那么有系统的冲击响应有如下的表达式：

M_i是冲击响应的长度，并且满足c_i(n)≥c_i(n+1)，n≥1；c_i(n)∈R。考虑到采样间隔为T_f，假设队列时延的上限为τ_i，那么通过τ_i＝(M_i+1)T_f计算得到M_i，并通过设置合适的c_i(n)，可以得到h_si(k)。进一步可以得到H_i(z)，同时可以得到：所以使用DTLC算法，就能通过计算一个无线帧内需要传输的数据量u_i(k)，来保证实时业务的时延不超过上限值。

PF(Proportional Fair，比例公平)算法是一种经典的信道感知调度算法，对调度的公平性和系统频谱效率进行了很好的折中，当用户较多的时候，该算法能够选择信道质量较好的用户进行调度，从而能够带来多用户分集增益(即当信道环境糟糕时多个用户中极可能存在一个信道质量比较好的用户，选择此用户进行调度会提高系统的频谱利用效率)。算法的表达式为其中代表PF算法第i个业务流调度第k个子信道的权值，这个值越大表明第k个子信道被第i个业务流调度的概率就越高。表示当前子帧时刻t第i个业务流在第k个子信道上的数据速率，表示第i个业务流过去的平均速率。

MLWDF(Modified Largest Weight Delay First，修改的最大权值延时优先)算法：该算法是一种经典的多媒体实时业务调度算法，既考虑了信道特点又考虑了业务的QoS特性。其表达式为其中τ_i为第i个业务流的包延时上限，δ_i定义为D_HOL,i(第i个业务流队头(Head of Line)等待时延)超过τ_i的最大概率。

EXP/PF(Exponential/Proportional Fair，指数比例公平)算法：该算法也是一种经典的实时多媒体业务无线资源调度算法，其表达式为其中N_rt为激活的下行实时业务流的个数。我们可以看到，对于非实时业务，或者D_HOL,i都相近的实时业务来说，指数项趋近于1，此时就变成简单的PF算法。

FLS(Frame Level Scheduler，帧级调度器)算法：这种算法是一种最新提出来的改进实时多媒体业务调度性能的算法，较其他几种方法更能保障多媒体业务的QoS特性。该算法是一个双层调度算法，在顶层采用DTLC原理，为了保障实时业务的时延特性，计算实时业务在一个无线帧内需要传输的数据量。在底层，首先使用PF算法在每个子帧内优先调度实时业务，当实时业务传输完毕，再使用PF算法调度非实时业务。

用户优先级用来区分用户使用无线资源的优先顺序，来保障某些特殊用户的通信性能。

在LTE系统中，一个无线帧的持续时间是10ms,包含10个子帧，每个子帧的持续时间为1ms，即一个TTI(Transmission Time Interval，传输时间间隔)。FLS算法顶层调度的时间单元为一个无线帧的持续时间，底层PF算法的调度时间为一个子帧持续时间。

PRB(Physical Resource Block，物理资源块)：一个PRB块由频域上12个连续的子载波和时域上的0.5ms组成。一个子载波带宽为15KHz，一个子信道是指在频域上12个连续的子载波，即180KHz的带宽。

为了表示方便，使用UEPriority代表用户优先级，我们使用UEPriority1表示用户优先级为1，同理UEPriority2,、UEPriority3、UEPriority4分别表示用户优先级2、3、4。

在一个存在干扰的单小区单基站区域，存在许多用户，不同用户有不同的用户优先级，每个用户从基站同时接收实时业务和非实时业务，如何解决高优先级用户优先抢占无线资源，以及实时业务保障其丢包率、时延等QoS需求，现有技术中没有提出这样的技术问题，更没有给出同时解决上述两个问题的技术方案。

发明内容

本发明的目的是提供一种LTE公网下集群多媒体业务下行无线资源调度方法，在LTE公网下传输集群多媒体业务，在满足集群通信用户优先级特点的前提下，同时支持多媒体业务的QoS特性，尤其是实时业务(时延敏感性业务)。

本发明为解决上述技术问题采取的技术方案是：

一种LTE公网下集群多媒体业务下行无线资源调度方法，所述方法基于单小区单基站，多个不同优先级的用户，下行传输(基站发，用户收)多媒体实时业务和非实时业务；所述方法的顶层调度以一个无线帧的持续时间为时间调度单元，底层调度的时间单元为一个子帧的持续时间；调度单元在频域上占180kHz的带宽，有12个带宽为15kHz的连续子载波；

所述方法是按照如下步骤实现的：

步骤1、开始下一个无线帧的调度：

步骤2、(为了保证实时业务的时延敏感特性)使用离散时间线性控制(DTLC)原理计算在一个无线帧时间内，所有待调度的实时业务流需要传输的数据量，从而估计当前帧实时业务流的数据传输量；

对于实时业务来讲，步骤2计算的数据量为在当前无线帧下的10个子帧总传输量，每执行完一次子帧调度，实时业务的待传输数据量会减少，所需要更新待传输数据量；更新平均速度，是为了使用PF调度算法计算各个业务流的调度权值。

步骤3、初始化子帧数量n为0；

步骤4、开始子帧的调度；

步骤5、更新业务流的传输量和平均速率；

步骤6、检测丢包：由于实时业务有时延敏感特性，每个实时业务的QoS特性中都需要定义可忍受的最大时延，当某实时业务迟迟未被调度，其数据包等待时间超过了可忍受的最大时延，该业务流的数据包被视为丢包；

步骤7、初始化业务流的用户优先级P，P＝1；按照用户优先级对业务流进行依次调度；

步骤8、首先选择用户优先级P＝1的业务流；

步骤9、优先保证实时多媒体业务流的QoS特性，选择P＝1的实时业务流；

步骤10、判断待调度业务流数量是否为0；如果是执行步骤13，否则执行步骤11；

步骤11、使用PF算法进行资源分配，对选择的实时业务流使用PF算法进行调度；

步骤12、完成用户优先级为1的实时业务流的调度后，进一步判断PRB是否还有剩余，

如果PRB还有剩余，依次执行步骤13、步骤14步，否则直接执行步骤19；

按照步骤7至步骤14，由高到低依次对其他用户优先级的实时业务流进行调度；

步骤13、P＝P+1；

步骤14、m代表实际设置用户优先级的个数，判断P是否小于或等于m，如果是则返回步骤8，否则执行步骤15；

步骤15、按照用户优先级高低的顺序完成对实时业务流的调度后，再进一步判断PRB是否有剩余，如果还有PRB剩余则执行步骤16，否则执行步骤19；

步骤16、选择非实时业务流，开始调度非实时业务流；

步骤17、判断待调度业务流数是否为0，如果是则直接执行步骤19，否则执行步骤18；

步骤18、选择PF算法进行调度，使用PF算法进行资源分配；

步骤19、当前子帧调度结束，传输已调度的业务流；

步骤20、子帧数n+1；

步骤21、判断已调度的子帧数是否小于10个，如果已调度的子帧数小于10个，那么返回步骤4开始下一个子帧的调度，否则，返回步骤1开始下一个无线帧的调度。

用户优先级m设置4个级别，即m分别为1,2,3,4，最高优先级为1，依次降低。

DTLCP(Discrete Time Line Control with Priority，带优先级的离散时间线性控制)算法是本发明提出的一种改进的调度方案，在FLS算法的基础上加入了用户优先级控制参数，顶层仍然使用DTLC算法，底层的实时业务调度部分加入了优先级控制参数，优先调度用户优先级高的实时业务，以保障LTE公网中集群通信用户多媒体业务的QoS性能，尤其在用户过载系统资源紧张的情况下，区分用户优先级更有必要。最后调度非实时业务。

本发明的有益效果是：

本发明的无线资源调度方法基于DTLCP算法实现的，在保障高用户优先级实时业务的丢包率和延时等QoS特性上，有更好的性能，这不仅由于该算法的实时业务具有较高的公平性指数，更因为加入了优先级控制参数，但是以牺牲低用户优先级业务的性能为代价的，同时无论是在吞吐量还是小区频谱效率整体性能上，相对于FLS算法，甚至其他两种经典算法，都有一定程度的下降。不过，在特定的应用场景下，这样的损失是值得的，可以保障高优先级用户的实时业务的性能，所以DTLCP算法服务于既考虑用户优先级特性又考虑多媒体业务QoS特性的应用，适用于集群多媒体实时业务。本发明利用DTLC算法计算实时业务的传输量来满足业务的qos特性，尤其是时延特性。本发明实现了在LTE公网下传输集群多媒体业务，在满足集群通信用户优先级特点的前提下，同时支持多媒体业务的QoS特性，尤其是实时业务(时延敏感性业务)。

附图说明

图1是现有技术中的DTLC控制框图，图2是本发明所述的DTLCP调度方案流程图，图3是多媒体流场景图；

图4为用户优先级为1的视频业务流的包丢失率图，图5为用户优先级为2的视频业务流的包丢失率图，图6为用户优先级为3的视频业务流的包丢失率图，图7为用户优先级为4的视频业务流的包丢图，图8为用户优先级为1的VOIP业务流的包丢失率图，图9为用户优先级为2的VOIP业务流的包丢失率图，图10为用户优先级为3的VOIP业务流的包丢失率图，图11为用户优先级为4的VOIP业务流的包丢失率图，图12为所有用户视频业务流的包丢失率图，图13为所有用户VOIP业务流的包丢失率图，图14为所有用户BE业务流的包丢失率图；

图15为用户优先级为1的视频业务流的时延图，图16为用户优先级为2的视频业务流的时延图，图17为用户优先级为3的视频业务流的时延图，图18为用户优先级为4的视频业务流的时延图，图19为用户优先级为1的VOIP业务流的时延图，图20为用户优先级为2的VOIP业务流的时延图，图21为用户优先级为3的VOIP业务流的时延图，图22为用户优先级为4的VOIP业务流的时延图，图23为所有用户的视频业务流的时延图，图24为所有用户的VOIP业务流的时延图，图25为所有用户的BE业务流的时延图；

图26为所有用户的视频业务流的吞吐量图，图27为所有用户的VOIP业务流的吞吐量图，图28为所有用户的BE业务流的吞吐量图；

图29为所有用户的视频业务流的公平性指数图，图30为所有用户的VOIP业务流的公平性指数图，图31为所有用户的BE业务流的公平性指数图；

图32为小区频谱效率图。

上述图中：M-LWDF、EXP/PF、FLS的含义参见背景技术的描述，DTLCP(DiscreteTime Line Control with Priority)是指带优先级的离散时间线性控制，即本发明提出的方法；PLR表示包丢失率(丢包率)，Delay表示延时，Users表示用户数。附图中所有的英文含义在说明书均能找到对应的含义，且均为本领域的公知常识。由于对本发明进行仿真所使用的软件为英文界面，故截图中含有英文。

具体实施方式

具体实施方式一：如图2所示，本实施方式对所述的LTE公网下集群多媒体业务下行无线资源调度方法进行描述：本方法的用户优先级设置了4个级别，即m分别为1,2,3,4，最高优先级为1，依次降低，但这并不代表实际情况，可以根据实际需要进行设置m的大小。本发明基于DTLCP算法工作流程图如图2所示。所述方法基于单小区单基站，多个不同优先级的用户，下行传输(基站发，用户收)多媒体实时业务和非实时业务。具体实现过程如下：

1.本方案顶层调度以一个无线帧的持续时间为时间调度单元，底层调度的时间单元为一个子帧的持续时间。调度单元在频域上占180kHz的带宽，有12个带宽为15kHz的连续子载波。

2.为了保证实时业务的时延敏感特性，使用离散时间线性控制(DTLC)原理，计算在一个无线帧时间内，所有待调度的实时业务流需要传输的数据量。

3.初始化n(子帧数量)为0。

4.开始子帧的调度。

5.对于实时业务来讲，第2步计算的数据量为在当前无线帧下的10个子帧总传输量，每执行完一次子帧调度，实时业务的待传输数据量会减少，所以需要更新。更新平均速度是为了使用PF调度算法计算各个业务流的调度权值。

6.由于实时业务有时延敏感特性，每个实时业务的QoS特性中都需要定义可忍受的最大时延，当某实时业务迟迟未被调度，其数据包等待时间超过了可忍受的最大时延，那么该业务流的数据包被视为丢包。

7-14.初始化P(业务流的用户优先级)，P＝1。按照用户优先级对业务流进行依次调度，第8步首先选择用户优先级P＝1的业务流，由于本方案优先保证实时多媒体业务流的QoS特性，故第9步选择P＝1的实时业务流，经过第10步的判断，对选择的实时业务流使用PF算法进行调度。完成用户优先级为1的实时业务流的调度后，如果PRB还有剩余，执行13、14步，按照上述步骤，由高到低依次对其他用户优先级的实时业务流进行调度。

15.按照用户优先级高低的顺序完成对实时业务流的调度后，如果还有PRB剩余，那么开始调度非实时业务流。

16-18.选择非实时业务流，经过第17步的判断，选择PF算法进行调度。

19-21.当前子帧调度完毕，传输已调度的业务流，并计算在当前无线帧内，已调度的子帧数，如果已调度的子帧数小于10个，那么开始下一个子帧的调度。否则，开始下一个无线帧的调度。

对本发明方法进行性能仿真：

1)、仿真环境

本次仿真分析了M-LWDF、EXP/PF、FLS和新算法DTLCP(本发明)四种算法在LTE中的性能，将前三种算法作为与新算法的对比。使用了带干扰的单小区模型，如图3所示，用户数量从10、20、30到40，本次仿真设置了4个用户优先级，故令流程图2中第14步的m等于4；每种优先级的用户数量从高到低呈金字塔形分布，分别占总用户数量的10％、20％、30％和40％。每个用户使用一个Video(视频)业务流，一个VoIP(Voice over Internet Protocol，IP语音)业务流，一个BE(Best Effort，尽力而为)业务流。用户持续以3km/h的速度沿任意方向移动。使用LTE-Sim仿真器来实现这个过程。LTE-Sim提供在时频域上的无线资源分配。下行仿真参数如表1。

表1 LTE下行仿真参数

2)、业务模型

本次仿真使用的是数据速率为242kbps的视频业务，视频业务一种基于跟踪的业务，它基于可用的实时视频跟踪文件发送数据包。对于VOIP流，VOIP应用会产生G.729语音流。特别地，VOIP语音流使用开/关马尔可夫链模型，“开”的周期呈均值为3s的指数分布，而“关”的周期呈截断指数概率密度函数分布，上限值为6.9s，均值为3s。在“开”期间数据源每20ms发送20个字节的数据包(即数据源的速率为8.4kbps)，而在“关”期间数据速率为0因为这时假设不存在语音激活检测器。BE业务流从Infinite Buffer(无限缓存)应用产生，Infinite Buffer以理想贪婪数据源为模型，即总是有数据包传输。

LTE传播损耗模型由四个模型(衰落、多径、穿透损耗和路径损耗)组成。

路径损耗：PL＝128.1+37.6log(d)，d为用户和基站之间的距离，单位为km。

多径：Jakes模型。

穿透损耗：10dB。

衰落：对数正态分布(均值为0，标准方差为8dB)。

为了计算每个业务流的公平性指数，使用Jain公平性指数：

其中n代表用户个数，x_i表示第i个连接的吞吐量。

3)、仿真结果

(1)丢包率

将用户分为四个优先级，如图4、图5、图6和图7所示，分别表示各个优先级的用户在MLWDF、EXP/PF、FLS和DTLCP四种算法下视频业务的丢包率随用户数变化的曲线。如图4可以看到，用户优先级为1的视频业务流在DTLCP算法下的性能最好，基本不丢包。FLS算法在少于30个用户时，性能接近于DTLCP，当过载严重时，丢包率会提高。其他两种算法性能相近，在低于20个用户时，丢包率可以接受，当用户数过载时，丢包率会显著升高。结合图5、6、7，我们可以看到MLWDF、EXP/PF、FLS这三种算法的性能基本不随用户优先级改变，每种用户优先级的性能曲线变化趋势都是一致的，然而DTLCP算法的性能却与用户优先级有直接的关系，用户优先级为1和2的视频业务的丢包率基本为0，性能要优于FLS算法，用户优先级为3丢包率与FLS相近，当用户严重过载时，要稍微优于FLS算法，然而用户优先级为4的用户的视频业务丢包率却变化剧烈，当用户数少于30时，性能逊于FLS算法，但优于其余两种算法，当用户过载时，丢包性能急剧恶化，性能开始变得比其他算法要差。所以，显然可以看到，DTLCP算法能够优先保障高用户优先级实时视频业务的丢包性能，但代价是牺牲低用户优先级实时业务的性能。

从图8、9、10、11四个图中，我们可以看到不同用户优先级的VOIP业务在四种算法下的丢包率随用户数变化的曲线。可以看到图8和图9的曲线有些波动，这是因为UEPriority1和UEPriority2的用户所占比例较少，又由于VOIP实时业务流的“开/关”特性，并与Video视频流同时调度，相互抢占资源，导致高用户优先级的VOIP业务丢包性能的统计有一定的波动性。但这并不妨碍我们分析性能。从图8中我们可以看到，当小区用户数未过载时，四种算法性能相差不大，丢包率大致都在0.001以下，DTLCP波动稍大一些，但当小区用户过载时，即超过30后，DTLCP丢包率降低，性能渐渐达到最佳，而FLS算法丢包增加，这是由于在DTLCP算法中用户优先级高的用户优先调度，而FLS算法则无优先级控制，不同用户优先级的用户“一视同仁”，这对在小区过载条件下，保障集群特殊用户的性能至关重要。结合图9、10、11，我们可以看到其余三种算法在UEPriority2、UEPriority3、UEPriority4下VOIP业务的丢包率变化趋势基本一致，曲线平稳，性能相近，都优于DTLCP算法，丢包率皆在0.001以下。而对于DTLCP算法来说，随着用户优先级的降低，丢包率的曲线变化越来越剧烈，性能也越来越差，UEPriority2的丢包率在用户数少于30时，稳定在0.002左右，然而小区用户过载后，丢包增多，用户数为40时，已到达0.005，不过在可接受的范围内。UEPriority3的丢包率从10个用户的0.002提高到40个用户的0.01，UEPriority4的丢包率从10个用户的0.005缓慢提升到30个用户的0.02，而后飙升到40个用户的0.16。综上所述，可以看到DTLCP算法能够很好的保障UEPriority1用户的VOIP业务的丢包率性能，尤其在小区过载的环境下，表现出比其他算法要好的性能，但是低用户优先级的实时VOIP业务的丢包性能表现的很糟糕。

如图12、13、14，分别是不区分用户优先级的视频业务、VOIP业务和BE业务的丢包率整体性能曲线。如图12可以看到对于视频业务，DTLCP算法要优于MLWDF、EXP/PF这两种算法，但要差于FLS算法。如图13，对于DTLCP算法，VOIP业务的整体丢包性能要比其他三种差，但在用户数少于30的情况下，丢包率在0.01以下，过载后有严重的升高。这是由于DTLCP在FLS算法上加入了优先级控制，单纯地为了保障高优先级用户的实时业务性能，会导致实时业务整体的丢包率的下降。如图14是BE业务的丢包率情况，我们看到在小区用户没有过载时，四种算法的丢包率都较大，这是实时多媒体业务调度算法调度非实时业务的特点，且之间相差不大，这是因为对于非实时业务来说，四种算法都可近似于PF算法。小区用户过载后，MLWDF、EXP/PF、FLS算法的BE业务丢包率在下降，这是因为PF算法的多用户分集带来的增益。而DTLCP算法的尽力而为业务丢包率在升高，说明加入的优先级控制会抵消多用户分集产生的增益。

综上，我们看到了实时多媒体业务的调度性能是以牺牲非实时业务的性能为代价的，DTLCP算法能够较其他三种方法更适合保障高用户优先级用户的实时业务的丢包性能，但是以牺牲低用户优先级用户的性能为代价的，这就导致了整体丢包性能的损失是不可避免的。

(2)时延

如图15、图16、图17和图18所示，分别表示各个用户优先级的用户在MLWDF、EXP/PF、FLS和DTLCP四种算法下视频业务的时延随用户数变化的曲线。如图15可以看到，用户优先级为1的视频业务流在DTLCP算法下的性能最好，时延低于0.015s，且小区过载后，曲线仍平稳。FLS算法在过载时，延时会提高，其他两种算法性能相对较差，过载后变化更剧烈。结合图16、17、18，我们可以看到MLWDF、EXP/PF、FLS这三种算法的性能基本不随用户优先级改变，每种用户优先级的性能曲线变化趋势都是一致的，然而DTLCP算法的性能却与用户优先级有直接的关系，用户优先级为1和2的视频业务的时延都低于0.015s，曲线平稳，性能要优于FLS算法。用户优先级为3时延与FLS相近，然而用户优先级为4的用户的视频业务时延却变化剧烈，当用户数少于30时，性能逊于FLS算法，但优于其余两种算法，当用户过载时，时延性能急剧恶化，性能开始变得比其他算法要差。所以，显然可以看到，DTLCP算法能够优先保障高用户优先级实时视频业务的时延性能，但代价是牺牲低用户优先级实时业务的时延性能。

从图19、20、21、22四个图中，我们可以看到不同用户优先级的VOIP业务在四种算法下的丢包率随用户数变化的曲线。从图19中我们可以看到，对于UEPriority1的VOIP业务，DTLCP算法性能要优于FLS，要逊于其他两种算法，时延稳定在0.008s左右。结合图20、21、22，我们可以看到其余三种算法在UEPriority2、UEPriority3、UEPriority4下VOIP业务的丢包率变化趋势基本一致，EXP/PF算法的时延基本稳定在0.002s以下，MLWDF算法随着用户数的增加曲线变化的越来越剧烈，但时延在0.005s以下，而FLS曲线则平稳的维持在0.008s左右，这些算法都表现出了良好的时延性能。而对于DTLCP算法来说，随着用户优先级的降低，时延的曲线变化越来越剧烈，性能也越来越差，UEPriority2的丢包率在用户数少于30时，大部分时延稳定在0.008s以下，然而小区用户过载后，时延增加，用户数为40时，已到达0.0085s，表现出的性能开始差于FLS算法，不过在可接受的范围内。UEPriority3的时延从10个用户的0.008s提高到40个用户的0.013s，UEPriority4的时延从10个用户的0.008s缓慢提升到30个用户的0.02s，而后快速升到40个用户的0.035s。综上所述，可以看到DTLCP算法能够很好的保障高优先级用户的VOIP业务的时延性能，但是低用户优先级的实时VOIP业务的延时性能表现的相对较差。

如图23、24、25，分别是不区分用户优先级的视频业务、VOIP业务和尽力而为业务的时延整体性能曲线。如图23可以看到对于视频业务，DTLCP算法要优于MLWDF、EXP/PF这两种算法，但要差于FLS算法。如图24，VOIP业务的整体丢包性能要比其他三种差，但在用户数少于30的情况下，大部分时延在0.01s以下，过载后有一些升高，但总体低于0.02s。这是因为DTLCP在FLS算法上加入了优先级控制，单纯地为了保障高优先级用户的实时业务性能，会导致实时业务整体的时延的下降。如图25是BE业务的时延情况，因为尽力而为业务使用了无限缓存模型，所以它的延时恒定地为0.001s。

综上，DTLCP算法能够较适合地保障高用户优先级用户的实时业务的丢包性能，但是是以牺牲低用户优先级用户的性能为代价的，这就导致了整体时延性能的损失是不可避免的。

(3)吞吐量

由于不同用户优先级的用户数量是不同的，不同用户优先级的各类业务数据量也是不同的，所以我们不像评估丢包率和时延特性那样区分用户优先级，而是评估各类业务吞吐量的整体性能。如图26所示，对于视频业务，DTLCP算法和FLS算法的吞吐量接近，要高于其他两种算法，这是由DTLCP和FLS优先调度实时业务决定的。随着用户数的增多，DTLCP算法的吞吐量性能与FLS相差越来越大，这是因为DTLCP算法有优先级的概念，调度不仅仅决定于信道质量情况，还决定于用户优先级的高低，所以用户越多，高优先级的视频业务也就越多，若单单考虑信道质量，高优先级的业务不一定是信道最适合传输的业务流，故吞吐量之间的差距也就越大。对于DTLCP和FLS算法，当用户数达到30个后，吞吐量才开始下降，而对于另两种经典算法，当用户数超过20个时就已达到过载情况，所以DTLCP可以容纳较多的用户。

如图27所示，对于VOIP业务来说，其结果和视频业务基本一样，但各算法之间吞吐量的差距很小。图28是BE业务的吞吐量变化曲线，对于非实时业务，一个已知的效果是，系统饱和会导致尽力而为业务的吞吐量下降。同时可以看到，FLS和DTLCP两种算法要低于另外两种经典算法，这是由于FLS和DTLCP优先调度实时业务的缘故。并且，DTLCP算法的尽力而为业务的吞吐量要低于FLS，说明了DTLCP算法由于用户优先级的加入，在实时业务数据量相同的前提下，为实时业务分配了更多的资源，也从侧面表明了DTLCP的频谱利用率较低。

(4)公平性指数

与吞吐量相同，不去区分各类业务的用户优先级，我们也是评估各类业务公平性的整体性能。由图29所示，对于视频业务，DTLCP和FLS算法的公平性指数曲线相近，均高于其他两种经典算法。对于VOIP业务来说，如图30，四种算法的公平指数曲线没有太大差别。由图31可以看到，四种算法的BE业务的公平性指数都偏低，其中FLS和DTLCP算法在小区用户数超过20后，相比另外两种经典算法公平性指数更低，而且差距越来越大。其中，DTLCP的公平性表现的最差，这也进一步表明了DTLCP优先调度实时业务的特点，也就是对非实时业务来说极不公平。

需要注意的是，在对丢包率和时延性能分析的基础上，对于DTLCP算法，可以看出高用户优先级的实时业务流应该具有更高的公平性指数。

(5)小区频谱效率

最后，图32表明了本仿真使用的LTE场景下的小区频谱效率，小区频谱效率表示为所有用户获得的总吞吐量除以可用带宽。MLWDF和EXP/PF算法有更好的频谱利用率，而FLS和DTLCP表现的性能较差，这是因为后两种算法优先调度实时业务流，多媒体实时业务调度完毕之后才去调度非实时业务，这就极有可能导致优先调度的是信道环境比较差的业务流。其中DTLCP性能最差，这是因为其在FLS基础上又加入了优先级控制，导致优先调度信道环境比较差的业务流的可能性更大，从而信道利用率即小区频谱效率比较差。

对上述仿真结果进行分析：

本次仿真在LTE系统传输视频业务、VOIP和BE业务下，探讨了MLWDF、EXP/PF、FLS和DTLCP四种算法，来分析并验证我们所提出方案的性能和可行性。通过仿真结果的比较，使用实时业务流时FLS和DTLCP的性能优于M-LWDF和EXP/PF。特别地，DTLCP算法在保障高用户优先级实时业务的丢包率和延时等QoS特性上，有更好的性能，这不仅由于该算法的实时业务具有较高的公平性指数，更因为加入了优先级控制参数，但是以牺牲低用户优先级业务的性能为代价的，同时无论是在吞吐量还是小区频谱效率整体性能上，相对于FLS算法，甚至其他两种经典算法，都有一定程度的下降。不过，在特定的应用场景下，这样的损失是值得的，可以保障高优先级用户的实时业务的性能，所以DTLCP算法在服务于即考虑用户优先级特性又考虑多媒体业务QoS特性的应用时，如集群多媒体实时业务，会有很大的应用潜力。

Claims (2)

1.一种LTE公网下集群多媒体业务下行无线资源调度方法，所述方法基于单小区单基站，多个不同优先级的用户，下行传输多媒体实时业务和非实时业务；所述方法的顶层调度以一个无线帧的持续时间为时间调度单元，底层调度的时间单元为一个子帧的持续时间；调度单元在频域上占180kHz的带宽，有12个带宽为15kHz的连续子载波；

其特征在于：所述方法是按照如下步骤实现的：

步骤1、开始下一个无线帧的调度：

步骤2、使用离散时间线性控制原理计算在一个无线帧时间内，所有待调度的实时业务流需要传输的数据量，从而估计当前帧实时业务流的数据传输量；

步骤3、初始化子帧数量n为0；

步骤4、开始子帧的调度；

步骤5、更新业务流的传输量和平均速率；

步骤6、检测丢包：由于实时业务有时延敏感特性，每个实时业务的QoS特性中都需要定义可忍受的最大时延，当某实时业务迟迟未被调度，其数据包等待时间超过可忍受的最大时延，该业务流的数据包被视为丢包；

步骤7、初始化业务流的用户优先级P，P＝1；按照用户优先级对业务流进行依次调度；

步骤8、首先选择用户优先级P＝1的业务流；

步骤9、优先保证实时多媒体业务流的QoS特性，选择P＝1的实时业务流；

步骤10、判断待调度业务流数量是否为0；如果是执行步骤13，否则执行步骤11；

步骤11、使用PF算法进行资源分配，对选择的实时业务流使用PF算法进行调度；

步骤12、完成用户优先级为1的实时业务流的调度后，进一步判断PRB是否还有剩余，如果PRB还有剩余，依次执行步骤13、步骤14步，否则直接执行步骤19；

按照步骤7至步骤14，由高到低依次对其他用户优先级的实时业务流进行调度；

步骤13、P＝P+1；

步骤14、m代表实际设置用户优先级的个数，判断P是否小于或等于m，如果是则返回步骤8，否则执行步骤15；

步骤15、按照用户优先级高低的顺序完成对实时业务流的调度后，再进一步判断PRB是否有剩余，如果还有PRB剩余则执行步骤16，否则执行步骤19；

步骤16、选择非实时业务流，开始调度非实时业务流；

步骤17、判断待调度业务流数是否为0，如果是则直接执行步骤19，否则执行步骤18；

步骤18、选择PF算法进行调度，使用PF算法进行资源分配；

步骤19、当前子帧调度结束，传输已调度的业务流；

步骤20、子帧数n+1；

步骤21、判断已调度的子帧数是否小于10个，如果已调度的子帧数小于10个，那么返回步骤4开始下一个子帧的调度，否则，返回步骤1开始下一个无线帧的调度。

2.根据权利要求1所述的一种LTE公网下集群多媒体业务下行无线资源调度方法，其特征在于：用户优先级m设置4个级别，即m分别为1,2,3,4，最高优先级为1，依次降低。