一种IEEE 802.16上行链路实时业务改进调度方法

摘要

一种IEEE 802.16上行链路实时业务改进调度方法，其特征在于，包括如下步骤：步骤一、基站与用户端建立M个rtPS业务连接；步骤二、基站统计本轮轮询周期内M个业务连接所要求的总带宽Bm，并比较B0与Bm，并比较B0与Bm，基站按照对用户端轮询。本发明能够有效调度变速率实时业务，优化带宽请求发送条件，满足业务的急迫性需求。

说明书

技术领域

本发明基于IEEE 802.16建议的rtPS和ertPS调度机制处理变速率实时业务，是一种能够有效调度多用户变速率实时业务的上行链路调度方法，具体涉及一种IEEE 802.16上行链路实时业务改进调度方法。 

背景技术

IEEE 802.16标准提供了五种上行调度服务以满足不同业务的QoS要求。调度机制是实现不同业务QoS保障的关键，包括基站和用户站的调度，同类型业务队列内和不同类型业务队列间的调度，甚至轮询间隔都会影响调度性能。 

随着VoIP，视频电话等实时业务的快速发展，实时业务的QoS要求越来越高，对IEEE 802.16建议的变速率实时业务调度机制rtPS和ertPS提出了更高的要求。rtPS在每一次数据传输前都需要进行参数协商，需要较多的MAC层开销和时延，如果在多个数据传输周期中传输数据都保持不变或者渐进式变化，rtPS的多个带宽请求完全相同，那么用于带宽请求的开销将降低上行链路资源利用率。另一种调度服务ertPS结合了UGS实时性和rtPS带宽利用率高的优点，ertPS可以动态地选择在轮询间隔发送数据或者带宽请求，相比rtPS上行资源利用率得到了提高。但是对于传输长度连续变化或者渐进变化的情况，ertPS仍然会按规定实时发送带宽请求，上行资源的利用率也很难达到最大化。 

现有技术的缺点是：IEEE 802.16建议的rtPS和ertPS调度机制处理变速率实时业务时MAC层开销大，导致时延增大。 

发明内容

本发明的目的就是针对变速率实时业务的特性，通过在ertPS调度机制的工作流程上优化带宽请求发送条件，并结合业务的急迫性分配带宽，提出了一种能够有效调度变速率实时业务的IEEE 802.16上行链路实时业务改进调度方法。 

本发明的技术方案是：一种IEEE 802.16上行链路实时业务改进调度方法，其关键在于，包括如下步骤： 

步骤一、基站与用户端建立M个rtPS业务连接，并在用户端为每条连接设置一个数据监控器，基站对每个用户端进行轮询，在每个轮询周期内，上行链路可传输数据的总带宽为B₀； 

步骤二、基站统计本轮轮询周期内M个业务连接所要求的总带宽B_m，并比较B₀与B_m： 

当B₀≤B_m时，所述基站保持对所有用户端轮询； 

当B₀＞B_m时，所述基站建立一个带宽请求队列BQ，每当收到一个用户端的上行带宽请求，这个带宽请求队列BQ就会更新一次，该带宽请求队列BQ是按照每条所述rtPS业务连接的紧急值E来排序的，使最急迫的连接排在前面，即优先获得调度服务，紧急值E定义如下： 

E＝W/D                        (1) 

其中W代表该连接未获得足够带宽分配的帧数，D代表该连接换算成帧数的最大时延，基站按照所述带宽请求队列BQ的排列顺序对用户端轮询。 

在分组通信中，当多个用户竞争带宽资源时，就需要一种机制来确定服务次序，有效地分配带宽资源。BS为每类活跃的上行连接维持一个带宽请求队列，每当收到一个上行带宽请求，这个队列就会更新一次，具体的更新规则如下： 

BS端维持的rtPS宽请求队列是按照每条rtPS连接的紧急值E来排序的。对于紧急值相同的连接，带宽请求次数多的排在前面，即优先获得调度服务。 

对于实时轮询业务，最大时延与实时性有很大的关系，实时性要求越高，最大时延越小。W越大，说明该连接滞留的未发送数据也就越多，需要服务的急迫程度也就越大。 

所述基站对某一用户端的轮询是按如下步骤进行： 

第一步：基站向该用户端分配带宽轮询时隙，并等待该用户端回复带宽请求； 

第二步：该用户端统计本次轮询周期内需要上传数据的总带宽为L，获取利用带宽轮询时隙直接传输数据所能获得的带宽为L1，并获取上一次轮询周期内上传数据的带宽为L2，其中L1为定值； 

第三步：用户端判断： 

L＜L1+L2且L≥L2，或L≥L1+L2，或L＜L2； 

当L＜L1+L2且L≥L2时，用户端通过带宽轮询时隙直接上传总量为L1的数据，并等待授权给自己的数据传输时隙； 

当L≥L1+L2时，用户端通过带宽轮询时隙发送带宽请求，请求基站提供带宽为L的带宽资源； 

当L＜L2时，用户端通过带宽轮询时隙发送带宽请求，请求基站提供带宽为L的带宽资源； 

第四步：基站判断： 

当用户端提出新的带宽资源请求时，基站向用户端提供新的带宽L； 

当用户端未提出新的带宽资源请求时，基站向用户端提供前次数据带宽L2； 

第五步：用户端获得基站带宽资源授权后，进行数据上传： 

当L＜L1+L2且L≥L2时，用户端向基站上传总量为L-L1的数据； 

当L≥L1+L2，或L＜L2时，用户端向基站上传总量为L的数据。 

将带宽请求的判决依据从传输周期内的数据长度变为传输的数据率的好处在于可以最小化带宽请求的次数，因为数据率的变化在短时间内是连续的，突发性小。 

由于基站周期分配的带宽到底用于带宽请求还是数据发送由用户决定，因此在用户端的优化主要是明确发送带宽请求的具体条件。实现的方法是在用户端为每条连接设置一个数据监控器。监控器实时地计算该连接在每个传输周期内的数据速率。计算方法为： 

${\bar{R}}_i=\frac{1}{T}\underset{j=1}{\overset{n}{\Sigma }}{S}_j---\left(1\right)$

表示第i个传输周期内的数据速率，T表示对应连接的轮询间隔，S_j表示第j个数据包的大小，n表示轮询间隔T内达到的数据包个数。将带宽请求的判决依据从传输周期内的数据长度变为传输的数据率的好处在于可以最小化带宽请求的次数，因为数据率的变化在短时间内是连续的，突发性小。 

为了避免未发送带宽请求的连接造成发送数据累积，对于直接发送数据的情况，数据监控器不做清零处理，而是累计监控，这样经过多个周期的传输数据长度的渐变，必然会触发一次带宽请求。 

本发明的显著效果是：通过分析rtPS和ertPS调度机制在服务传输长度连续变化或者渐进变化的业务时上行链路资源不能最大化的原因，在ertPS工作流程的基础上对用户站在带宽轮询时隙发送带宽请求的条件进行优化，尽量减少带宽请求次数，并将连接的急迫性考虑进基站上行链路的调度算法中，得到了改进的调度算法。改进算法在增加少量的计算开销，获得了上行时延的减少和系统吞吐量的增加，是一种适用于变速率实时业务的有效调度机制。能够有效调度变速率实时业务，优化带宽请求发送条件，满足业务的急迫性需求。 

附图说明

图1：不同带宽请求门限的时延性能图 

图2：用户数量与平均时延的关系图 

图3：用户数量与吞吐量的关系图 

具体实施方式：

下面结合附图和实施例对本发明作进一步的说明。 

一种IEEE 802.16上行链路实时业务改进调度方法，包括如下步骤： 

步骤一、基站与用户端建立M个rtPS业务连接，并在用户端为每条连接设置一个数据监控器，基站对每个用户端进行轮询，在每个轮询周期内，上行链路可传输数据的总带宽为B₀； 

步骤二、基站统计本轮轮询周期内M个业务连接所要求的总带宽B_m，并比较B₀与B_m： 

当B₀≤B_m时，所述基站保持对所有用户端轮询； 

当B₀＞B_m时，所述基站建立一个带宽请求队列BQ，每当收到一个用户端的上行带宽请求，这个带宽请求队列BQ就会更新一次，该带宽请求队列BQ是按照每条所述rtPS业务连接的紧急值E来排序的，使最急迫的连接排在前面，即优先获得调度服务，紧急值E定义如下： 

E＝W/D                        (1) 

其中W代表该连接未获得足够带宽分配的帧数，D代表该连接换算成帧数的最大时延，基站按照所述带宽请求队列BQ的排列顺序对用户端轮询。 

所述基站对某一用户端的轮询是按如下步骤进行： 

第一步：基站向该用户端分配带宽轮询时隙，并等待该用户端回复带宽请求； 

第二步：该用户端统计本次轮询周期内需要上传数据的总带宽为L，获取利用带宽轮询时隙直接传输数据所能获得的带宽为L1，并获取上一次轮询周期内上传数据的带宽为L2，其中L1为定值； 

第三步：用户端判断： 

L＜L1+L2且L≥L2，或L≥L1+L2，或L＜L2； 

当L＜L1+L2且L≥L2时，用户端通过带宽轮询时隙直接上传总量为L1的数据，并等待授权给自己的数据传输时隙； 

当L≥L1+L2时，用户端通过带宽轮询时隙发送带宽请求，请求基站提供带宽为L的带宽资源； 

当L＜L2时，用户端通过带宽轮询时隙发送带宽请求，请求基站提供带宽为L的带宽资源； 

第四步：基站判断： 

当用户端提出新的带宽资源请求时，基站向用户端提供新的带宽L； 

当用户端未提出新的带宽资源请求时，基站向用户端提供前次数据带宽L2； 

第五步：用户端获得基站带宽资源授权后，进行数据上传： 

当L＜L1+L2且L≥L2时，用户端向基站上传总量为L-L1的数据； 

当L≥L1+L2，或L＜L2时，用户端向基站上传总量为L的数据。 

本实施例采用Matlab作为仿真平台，首先仿真了带宽请求门限α对调度算法性能的影响，然后对IEEE 802.16的推荐调度机制rtPS、ertPS和本发明改进算法从时延性、吞吐量方面进行了比对。具体的仿真参数如下表示。 

表1系统仿真参数 

  参数   参数值   MAC帧长   10ms   物理层   OFDM   复用方式   TDD   TTG   296PS   RTG   168PS   编码调制   RS+16-QAM 3/4   DL/UL radio   1/2   PDU最大长度   1024bits   Fragmentation/Packing   on/on   ARQ   off   视频数据流平均速率   200kbps

[0064] 由于本发明不考虑信道状况对调度算法的影响，仿真中数据传输均采用统一的调制方式。业务数据流是模拟的压缩编码后的视频数据流，这是一类可变信息速率的业务。假设所有用户具有相同的优先级，为了使各用户有相等的机会使用上行链路资源，rtPS和ertPS调度机制使用DRR算法来保证各用户之间的公平性。 

本发明以分组发送和到达(分段的数据包以最后一段到达时间为准)之间的时间间隔来计算传输时延，计算方式如下： 

D(i)＝RT(i)-ST(i) 

式中：D(i)表示第i个分组的传输时延，RT(i)表示第i个分组的接收时间，ST(i) 

表示第i个分组的发送时间。平均传输时延 的计算如下： 

$\bar{D}=\frac{1}{N}\underset{i=1}{\overset{N}{\Sigma }}D\left(i\right)$

以丢失分组的数量与发送分组的总量的比值来衡量丢包率的大小： 

$R=\frac{\mathrm{NSP}-\mathrm{NRP}}{\mathrm{NSP}}$

式中：NSP表示节点发送的分组数目，NRP表示节点接收到的分组数目。 

网络的吞吐量使用以下方式计算： 

$\mathrm{TH}{\left(i\right)}_m=\frac{\mathrm{TB}\left(i\right)-\mathrm{TB}\left(m\right)}{\mathrm{RT}\left(i\right)-\mathrm{RT}\left(m\right)}$

式中：TB(i)指到第i个分组被目的节点接收时已经传输的数据总量，RT(i)是第i个包的接收时间。i＞m表示计算从第m个分组到第i个分组的吞吐量，特别的，若取m＝1则是计算平均吞吐量。 

图1展示了对于不同带宽请求门限α(归一化)，α也就是前次数据带宽L2，改进算法的平均时延性能，其中α的值与带宽轮询时隙的有效传输量有关。可以看出在低负载，即用户数较少时，α越大时延越小，但是在高负载，即用户数较多情况下，α越大时延反而越小。α与发送带宽请求的机会密切相关，α越大请求机会越小。在低负载时，传输量即使有少量变化，利用带宽轮询时隙传输数据也可以缓解。而在高负载情况下，带宽轮询时隙已经无法传输过多的滞留数据，比较大的带宽请求门限α的带宽请求机会又较小，最终导致上行时延整体上的增大。出于折中考虑，对于后面的仿真α取0.5。 

图2展示了在不同用户数情况下，rtPS，ertPS和改进算法在平均时延上的对比。可以看出在低负载下三种调度算法的平均时延都比较平稳，而在高负载下时延均呈上升趋势，最后趋于相等。整体上，本算法在时延性能上表现最优，ertPS次之，rtPS最差。这是因为改进算法将带宽请求的次数优化到尽可能少，rtPS却是每次轮询都发送带宽请求，ertPS在传输量发生变化时发送带宽请求。 

当用户数逐渐增大，三种调度算法都会出现带宽不够用的情况，在轮询时隙发送带宽请求的机会也就越大，时延性能差异就不是很明显了。另外基站上行调度算法的优化，使得最急迫的连接优先获得服务，在很大程度上减小了数据包在用户缓冲中的等待时延。 

图3展示了在不同用户数情况下，rtPS，ertPS和改进算法在系统吞吐量上的对比。可以看出在低负载时，三种调度算法的吞吐量都呈线性增长。在高负载下，系统吞吐量趋于稳定，但各算法之间有差异，rtPS吞吐量最小，改进算法比ertPS略大。这是因为对于低负载情况，带宽资源足够每个用户使用，吞吐量仅与服务的数据流数量有关，所以吞吐量与用户数量成正比。当负载过大时，各用户都会由于带宽不够用而在轮询时隙发送带宽请求，不过改进算法比rtPS，ertPS发送带宽请求的条件更苛刻，使用轮询时隙发送数据机会比rtPS，ertPS大。另外基站上行调度对每条连接急迫性的考虑降低了因超过延时而丢包的可能性，最终使得改进算法在吞吐量上表现最优。