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-Timer、dl-PathlossChange、periodicPHR-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