EVDO网络的反向链路负荷控制算法.docx

EVDO网络的反向链路负荷控制算法
引言
DO系统的反向链路与前向链路不同，不存在调度器，反向以码分为主，用长码掩码区分不同的用户。从这一点上来说，DO的反向链路与1X系统相似，是一个反向干扰受限的系统。
在EVDORel.0版本中，AN根据扇区负荷的变化情况，通过各个扇区RA子信道下发RAB比特通知AT此扇区的负载情况，AT通过RAB比特提供的信息根据转移概率矩阵对自己的传送速率进行调整。这种速率控制机制，升速或降速需要多次倍速转换，传输突发数据流易造成较大的延迟，速率抬升较慢，造成反向链路可靠性差。因此，Rel.0达不到数据流的QoS应用要求。
在EVDORev.A中，为了保证不同QoS级别用户和用户内不同QoS级别的业务流，实现精准控制AT的反向发送优先级，提出了基于T2P桶算法的概念。Subtype3RLMAC协议提供了多个激活MAC流之间的QoS，通过对每个激活流的T2P（TraffictoPilotPowerRatio）控制来完成速率控制。AN根据扇区负荷情况决定RAB比特，AT根据RAB比特计算每个激活流可用的T2P资源来控制传输速率。
为了便于理解，先简要介绍一下QoS机制。为了提供高速实时多媒体分组数据业务，EVDORev.A版本增加了多流包应用协议MFPA（Multi-FlowPacketApplication），要求提供端到端的QoS业务，每个用户可以有多个不同QoS要求的业务流。这些业务流的数据包因为业务属性不同而具有不同的优先等级，表现在准入控制、负荷控制、优先级调度等无线资源管理和地面链路资源管理等各个方面。评价QoS的关键指标主要包括：可用性、带宽/吞吐量、时延、抖动和误包率。本文主要涉及到用户内（Intra-user）QoS。根据业务流对时延敏感性的不同，QoS分为以下三类：
EF（ExpeditedForwarding）：时延敏感，要求低误包率，如VoIP、视频电话；
AF（AssuredForwarding）：可容忍一定时延，有低速率要求，如视频点播；
BE（BestEffort）：对时延和速率不敏感，如FTP、HTTP、E-mail。
AN通过支持并发多流来支持不同业务应用的QoS，同样每个流都有对应的QoS。前向无线资源通过时分复用的方式被多用户共享，针对不同QoS要求的多个流分别分配前向时隙调度的优先级，AN优先保证EF，其次是AF，最后是BE；在反向，AT根据不同业务流的QoS需求申请反向功率资源，AN综合所有AT的请求，进行集中式资源分配。
反向负荷控制算法
概述
与EVDORel.0使用的基于转移概率的负荷控制算法不同，EVDORev.A使用的是基于T2P的漏桶算法，
先简单介绍一下T2P的概念。当终端没有数据需要传输时，终端在反向链路上仅仅发送导频信号。通过功率控制算法，在保证基站接收机可以正常监测和正确解调的前提下，终端发射最小功率的导频信号。当有数据在反向链路上面传输时，终端在反向业务信道上面也需要一定的发射功率。数据速率越高，终端需要的发射功率就越大。T2P就是指示了相对于导频信道功率终端需要多少额外的功率分配给反向业务信道。其算法实现过程如下图所示：

此例以仅以一个MAC流为例进行介绍。
此过程从基站测量反向链路激活比特(RAB)开始：
基站每个时隙向终端反馈反向激活比特RAB，终端通过相关算法计算每一个MAC流的QRAB和FRAB，确定扇区的负载情况；
终端根据扇区负载情况，计算T2PInflow的变化，即△T2PInflow；
终端更新T2PInflow；
根据需要传输数据的延迟要求，终端决定传输数据包的大小和传输模式；
如果待传数据适合用上一步确定的数据包大小传输，且T2P资源足够，终端则更新T2POutflow，准备传输数据。
终端更新BucketLevelSat（漏桶的大小）和BucketLevel（漏桶内T2P资源的数量）。
现网扇区激活比特RAB的确定（AN侧）
RAB是ReverseActivityBit的简称，即反向激活比特，用于反映扇区的忙闲。RAB的计算过程是：系统测试反向底噪，然后根据实际的RSSI和底噪相比，计算得到底噪抬升（ROT）,ROT再与我们设定的RAB门限做比较，大于则下发RAB=1，否则下发RAB=0。具体如下：
ROT的计算
DO系统中一个扇区的ROT是基站从系统中所有终端处接收的功率与热噪声功率的比值。在静默（ReverseLinkSilenceDuration）期间，系统中所有的终端都禁止发射功率，基站可以测量出热噪声功率，即静默噪声。在其他非静默时间，基站测量出总接收功率，两者之比就是ROT。基于ROT的测量可以实时获得系统反向链路上干扰情况，目前除MSC2下系统过载的门限值是9dB外，其余交换机均是12dB。

RAB的