LTE资源调度(6)-功率余量报告PHR

1.什么是PH和PHR

PH,全称Power Headroom,中文为功率余量,即UE允许的最大传输功率与当前评估得到的PUSCH传输功率之间的差值,用公式可以简单的表示为:PH = UEAllowedMaxTransPower - PuschPower。它表示的是除了当前PUSCH传输所使用的传输功率之外,UE还有多少传输功率可以使用。PH的单位是dB,范围是[-23dB,+40dB],如果是负值则表示网侧给UE调度了一个高于其当时可用发送功率所能支持的数据传输速率。由于PH的计算需要用到PUSCH的传输功率,因此也只在PUSCH的发送子帧计算功率余量。

之所以定义PH值,原因之一在于它可以作为eNB分配上行RB资源的一个参考依据,不过这种参考依据的算法设计,或者说PH值怎么影响eNB的调度,是由各个设备厂家的算法决定的,比如:如果PH值为负,表示当前的PUSCH传输功率已经超过UE允许的最大传输功率,在下次调度时可以考虑减少该UE的RB资源分配;而如果PH值为正,那么后续分配的RB数目还可以继续增加。

有的朋友可能会奇怪为什么PH会有负数,这是因为“评估得到的PUSCH传输功率”是计算得到的,它的值不受UE最大发送功率的限制,并不是UE的实际传输功率,是有可能超过“UE允许的最大传输功率”的,所以PH的值是有可能为负数的。如图1所示。


(图1)

PHR,全称是Power Headroom Report,中文为功率余量报告,即UE向网侧报告功率余量的过程。这个功率余量的值是通过MAC层的控制单元发送的,所以与这个过程相关的MAC控制单元也被称作PHR控制单元。PHR控制单元固定占一个字节,其中高2位是R位即保留位,暂时不用,仅使用低6位存放0~63这64个PH等级值,如图2所示。


(图2)

每个PH等级值对应一个实际的dB值,如图3所示。比如UE需要上报的PH值为-22dB,那么只需要在MAC PDU的PHR控制单元中填写数值1即可。


(图3)

2.什么时候触发PHR

只要满足下面几个条件中的任何一个,UE就会触发一个PHR(注意“触发”和“发送”的区别):

(1)当UE有传输新数据的上行资源,prohibitPHR-Timer定时器超时或已经超时,并且在上一次传输功率余量报告之后,路径损耗的变化值已经超过了dl-PathlossChange dB。这个条件需要留意两个地方:第一,这里用的是路损的“变化值”,即不区分当前路损是变大还是变小,考虑的是路损的绝对差值。第二,如果定时器prohibitPHR-Timer仍然在运行,是不能触发PHR的,无论路损变化多大都没用。prohibitPHR-Timer的存在,是为了防止因路损变动频繁或者路损门限设置过低,导致UE频繁发送PHR的情况发生
(2)periodicPHR-Timer 定时器超时
(3)当RRC层配置或重配置PHR功能或参数,且这种配置或重配置并不是禁止PHR。比如说RRC重新配置了定时器的值。


(图4)

上面几个条件提到的参数prohibitPHR-Timerdl-PathlossChangeperiodicPHR-Timer,均由RRC在RadioResourceConfigDedicated -> MAC-MainConfig -> phr-Config中配置,如图5所示。prohibitPHR-Timer和periodicPHR-Timer的取值单位都是子帧,比如sf500表示500个子帧,如果是infinity表示不启动该定时器。dl-PathlossChange的取值单位是dB,比如dB3表示路径损耗的判断门限为3dB。


(图5)

3.发送PHR的条件

如果UE在该TTI内有传输新数据的上行资源,那么将按照下面的流程执行:

(STEP 1)如果这是MAC复位之后第一次为新传数据分配资源,那么启动周期定时器periodicPHR-Timer;
(STEP 2)如果功率余量上报过程判断自从上次传输PHR之后至少触发了一个PHR,或者当前本身就是第一次触发PHR;同时,如果在逻辑信道优先级的处理过程中,分配的上行资源可以容纳PHR控制单元与其对应的子头之和,那么继续按照下面的步骤执行:
--------(STEP 2.1)从物理层获取PH值
--------(STEP 2.2)基于PH值,生成一个PHR控制单元
--------(STEP 2.3)开始或重启periodicPHR-Timer周期定时器
--------(STEP 2.4)开始或重启prohibitPHR-Timer禁止定时器
--------(STEP 2.5)取消所有已经触发的PHR

流程示意如图6所示。


(图6)

参考文献:

(1)3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification

(2)3GPP TS 36.133 V9.22.0 (2014-12) Requirements for support of radio resource management 

(3)3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)

(4)3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures

猜你喜欢

转载自blog.csdn.net/m_052148/article/details/52356323