在NR系统中,UE的发射功率是最稀缺的上行资源之一。gNB调度器在分配MCS、RB数、空间层数时,必须精确掌握UE还有多少功率余量可用——否则分配了UE"买不起"的资源,只会导致上行BLER飙升、HARQ重传风暴。PHR(Power Headroom Report)就是UE向gNB汇报"功率家底"的MAC CE机制,定义于TS 38.321 Section 5.4.6(触发逻辑)和Section 6.1.3.6~6.1.3.9(MAC CE格式)。
NR相比LTE引入了三种PHR类型,分别对应PUSCH、PUCCH、SRS三条上行物理信道,配合载波聚合(CA)场景下的Multiple Entry PHR MAC CE,构成了一套精密的功率状态报告体系。
| PHR类型 | 对应信道 | 计算公式核心 | RRC配置开关 | 设计意图 |
|---|---|---|---|---|
| Type 1 | PUSCH | PCMAX,f,c - PPUSCH,f,c | 默认使能 | 反映数据信道的功率裕量,调度器据此调整MCS/RB |
| Type 2 | PUCCH | PCMAX,f,c - PPUCCH,f,c | phr-Type2-OtherSCell | 反映控制信道的功率裕量,PUCCH SCell场景 |
| Type 3 | SRS | PCMAX,f,c - PSRS,f,c | phr-Type3-OtherSCell | 反映探测参考信号的功率裕量,SRS-only场景 |
graph TB
subgraph "PHR三类型体系"
T1["Type 1 PH<br/>PUSCH信道<br/>PCMAX - PPUSCH"]
T2["Type 2 PH<br/>PUCCH信道<br/>PCMAX - PPUCCH"]
T3["Type 3 PH<br/>SRS信道<br/>PCMAX - PSRS"]
end
subgraph "触发条件"
TR1["phr-PeriodicTimer超时"]
TR2["路径损耗变化 ≥ dl-PathlossChange"]
TR3["SCell激活"]
TR4["RRC重配置PHR参数"]
TR5["FR2 MPE P-MPR变化"]
end
subgraph "MAC CE封装"
SE["Single Entry PHR<br/>仅PCell<br/>LCID=56"]
ME["Multiple Entry PHR<br/>PCell+SCells<br/>LCID=54/57"]
end
TR1 & TR2 & TR3 & TR4 & TR5 --> T1 & T2 & T3
T1 & T2 & T3 --> SE & ME
SE --> gNB["gNB调度器<br/>调整MCS/RB/层数"]
ME --> gNB
TS 38.321 Section 5.4.6定义了PHR的完整触发逻辑。理解这套逻辑的关键在于把握三个定时器和五个触发事件之间的博弈关系。
| 参数 | 取值范围 | 典型配置 | 作用 |
|---|---|---|---|
phr-PeriodicTimer |
sf10, sf20, sf50, sf100, sf200, sf500, sf1000, ∞ | sf200 | 周期性触发PHR上报的时间间隔 |
phr-ProhibitTimer |
sf0, sf10, sf20, sf50, sf100, sf200, sf500, sf1000 | sf50 | 两次PHR之间的最小间隔,防止频繁上报 |
phr-Tx-PowerFactorChange |
dB1, dB3, dB6, ∞ | dB3 | 路径损耗变化阈值,超过此值触发PHR |
sequenceDiagram
participant UE as UE MAC层
participant Timer as 定时器管理
participant gNB as gNB调度器
Note over UE: PHR触发条件评估
rect rgb(240, 248, 255)
Note over UE,Timer: 触发条件1: phr-PeriodicTimer超时
Timer->>UE: phr-PeriodicTimer expiry
UE->>UE: 触发PHR → periodicPHR-Timer重启
end
rect rgb(255, 248, 240)
Note over UE,Timer: 触发条件2: 路径损耗变化
UE->>UE: 测量下行路损变化
UE->>UE: ΔPathloss ≥ dl-PathlossChange?
Timer->>UE: phr-ProhibitTimer已超时或未运行?
UE->>UE: 两条件同时满足 → 触发PHR
end
rect rgb(240, 255, 240)
Note over UE,Timer: 触发条件3: SCell激活
UE->>UE: 收到Activation MAC CE
UE->>UE: 该SCell配置了PHR → 触发PHR
end
rect rgb(255, 255, 230)
Note over UE,Timer: 触发条件4: RRC重配置
UE->>UE: 收到RRCReconfiguration<br/>包含PH-Config修改
UE->>UE: 触发PHR + 重启所有定时器
end
rect rgb(248, 240, 255)
Note over UE,Timer: 触发条件5: FR2 MPE P-MPR变化
UE->>UE: FR2场景 P-MPR变化 ≥ dl-PathlossChange
Timer->>UE: phr-ProhibitTimer已超时或未运行?
UE->>UE: 触发PHR
end
Note over UE,gNB: PHR已触发,等待UL Grant
UE->>UE: 构造PHR MAC CE
UE->>gNB: PUSCH携带PHR MAC CE
gNB->>gNB: 解析PH值,调整调度策略
这是最复杂的触发条件。TS 38.321 Section 5.4.6规定:
当phr-ProhibitTimer超时或未运行时,如果以下任一条件满足,则触发PHR:
dl-PathlossChange dB——这是最常见的触发场景,UE移动或遮挡导致路损剧烈变化dl-PathlossChange dB——这是NR新增的触发条件,LTE中不存在关键博弈:phr-ProhibitTimer与dl-PathlossChange的配对关系决定了PHR上报的灵敏度:
- 高频小步长配置(sf10 + dB1):适合高速移动或信道快速变化的场景,但开销大
- 低频大步长配置(sf1000 + dB6):适合静止或低速场景,节省开销但gNB对功率状态的感知滞后
Type 1 PH是NR PHR的基础类型,其核心公式为:
PH = PCMAX,f,c - ˆPPUSCH,f,c
其中: - PCMAX,f,c:服务小区c载波f上的UE最大配置发射功率(TS 38.101-1/2) - ˆPPUSCH,f,c:PUSCH实际或虚拟发射功率估计值
关键区别在于"实际"与"虚拟":
| 场景 | 计算方式 | MAC CE中C字段 |
|---|---|---|
| 该PUSCH上有实际传输 | PH = PCMAX - 实际PPUSCH | C = 0 |
| 该PUSCH上无实际传输(仅PUCCH或仅SRS) | PH = PCMAX - 虚拟PPUSCH(按参考格式计算) | C = 1 |
虚拟PH的设计意图:当某服务小区只有PUCCH或SRS传输而没有PUSCH传输时,gNB仍然需要知道如果调度PUSCH,UE还有多少功率裕量。因此协议定义了"虚拟PUSCH功率"——按参考格式(0 RB, 参考MCS)计算出的假设功率。
PH = PCMAX,f,c - ˆPPUCCH,f,c
Type 2 PH专门针对PUCCH信道的功率裕量。在CA场景中,某些SCell可能配置了PUCCH(PUCCH SCell),此时gNB需要独立了解PUCCH的功率使用情况,以便合理配置PUCCH格式和重复次数。
Type 2 PH只在phr-Type2-OtherSCell被RRC配置时才会上报。典型场景:EN-DC或NE-DC中PUCCH分流到SCell。
PH = PCMAX,f,c - ˆPSRS,f,c
Type 3 PH针对SRS传输的功率裕量。在某些SCell上,可能仅配置了SRS而没有PUSCH/PUCCH(用于波束管理或CSI获取),此时gNB无法从Type 1/2 PH中获取该小区的功率状态,Type 3 PH填补了这一空白。
最简格式,仅报告PCell的Type 1 PH:
| Bit 7 | Bits 6-1 |
| R | PH (6 bits) | Oct 1
| Bit 7 | Bits 6-1 |
| R | PCMAX,f,c (6b) | Oct 2
| 字段 | 比特数 | 说明 |
|---|---|---|
| PH | 6 | 功率余量值,映射到-32dB ~ +38dB |
| PCMAX,f,c | 6 | UE最大发射功率,用于gNB校验PH值 |
| R | 1 | 保留比特,置0 |
PH值映射表(TS 38.133 Table 10.1.17.1-1):
| PH Index | 映射值(dB) | 实际含义 |
|---|---|---|
| 0 | -32 | 严重功率不足,UE已"透支" |
| 1 | -31 | ... |
| 32 | 0 | 刚好用完功率预算 |
| 33 | +1 | ... |
| 62 | +37 | ... |
| 63 | +38 | 功率充裕,gNB可大胆调度 |
在CA场景下,Single Entry显然不够用——UE可能同时有多个激活的SCell。Multiple Entry PHR MAC CE通过位图机制一次报告多个服务小区的PH值。
Oct 1: | C7 | C6 | C5 | C4 | C3 | C2 | C1 | C0 | (SpCell + SCell 1~7)
Oct 2: | C15| C14| C13| C12| C11| C10| C9 | C8 | (SCell 8~15, 如需要)
...
每个Ci位表示该服务小区是否包含PHR条目: - Ci = 1:该服务小区包含PH + PCMAX条目 - Ci = 0:该服务小区不包含条目
graph LR
subgraph "Multiple Entry PHR MAC CE"
B["Bitmap<br/>C0|C1|C2|C3<br/>1byte"]
PH1["SpCell Type2 PH<br/>+ PCMAX<br/>2bytes"]
PH2["SpCell Type1 PH<br/>+ PCMAX<br/>2bytes"]
PH3["SCell1<br/>PH+PCMAX<br/>2bytes"]
PH4["SCell2<br/>PH+PCMAX<br/>2bytes"]
PH5["SCell3<br/>PH+PCMAX<br/>2bytes"]
end
B --> PH1 --> PH2 --> PH3 --> PH4 --> PH5
每个PH条目(2字节)的内部结构:
| C | PH (6 bits) | R | Oct N (PH字段)
| PCMAX,f,c (6 bits) | R|R | Oct N+1 (PCMAX字段)
| 字段 | 说明 |
|---|---|
| C (1 bit) | 0=实际PH(有PUSCH传输),1=虚拟PH(无PUSCH传输,按参考格式计算) |
| PH (6 bits) | 功率余量索引值 |
| PCMAX,f,c (6 bits) | 对应的最大发射功率 |
| R (1~2 bits) | 保留比特 |
Release 17/18为FR2场景引入了MPE(Maximum Permissible Exposure)报告增强。当mpe-Reporting-FR2被配置时,Multiple Entry PHR MAC CE中增加了P字段和MPE字段:
| 新增字段 | 比特数 | 说明 |
|---|---|---|
| P (1 bit) | 1 | 指示是否应用了P-MPR功率回退 |
| MPE (2 bits) | 2 | P-MPR值的范围指示(0: 0dB, 1: 0~3dB, 2: 3~6dB, 3: >6dB) |
sequenceDiagram
participant RRC as RRC层
participant MAC as MAC层
participant PHY as PHY层
participant gNB as gNB
Note over RRC,gNB: 阶段1: RRC配置PHR参数
gNB->>RRC: RRCReconfiguration<br/>包含PH-Config
Note over RRC: phr-PeriodicTimer = sf200<br/>phr-ProhibitTimer = sf50<br/>dl-PathlossChange = dB3<br/>multiplePHR = true<br/>phr-Type2-OtherSCell = true
RRC->>MAC: 配置PHR参数<br/>启动phr-PeriodicTimer
Note over MAC,gNB: 阶段2: 定时器超时触发
MAC->>MAC: phr-PeriodicTimer超时
MAC->>MAC: 触发PHR<br/>PHR-State = triggered
MAC->>MAC: 重启phr-PeriodicTimer
Note over MAC,gNB: 阶段3: 等待UL Grant
gNB->>MAC: DCI Format 0_1<br/>UL Grant
MAC->>MAC: 检查PHR-State = triggered
Note over MAC,PHY: 阶段4: 构造PHR MAC CE
MAC->>MAC: 遍历所有激活服务小区
MAC->>MAC: 构造Bitmap (C0~Cn)
MAC->>MAC: 计算SpCell Type2 PH
MAC->>MAC: 计算SpCell Type1 PH
MAC->>MAC: 计算SCell1 PH (Type1)
MAC->>MAC: 计算SCell2 PH (Type1)
MAC->>MAC: 组装Multiple Entry PHR MAC CE
MAC->>MAC: 复用到PUSCH<br/>LCID=54(MCG)
MAC->>PHY: MAC PDU (含PHR CE)
PHY->>gNB: PUSCH传输
Note over gNB: 阶段5: gNB处理
gNB->>gNB: 解析PHR MAC CE
gNB->>gNB: 更新每小区功率状态
gNB->>gNB: 调整后续调度决策<br/>MCS/RB/层数/功率控制TPC
PHR的完整配置位于TS 38.331中的PH-Config IE:
PH-Config ::= SEQUENCE {
phr-PeriodicTimer ENUMERATED {sf10, sf20, sf50, sf100, sf200, sf500, sf1000, spare},
phr-ProhibitTimer ENUMERATED {sf0, sf10, sf20, sf50, sf100, sf200, sf500, sf1000, spare},
phr-Tx-PowerFactorChange ENUMERATED {dB1, dB3, dB6, spare},
multiplePHR BOOLEAN,
dualCellPHR BOOLEAN, -- 仅EN-DC场景
...
}
-- CA场景下SCell的PHR类型配置
phr-Type1-OtherSCell BOOLEAN, -- 为SCell使能Type1 PH
phr-Type2-OtherSCell BOOLEAN, -- 为SCell使能Type2 PH (PUCCH)
phr-Type3-OtherSCell BOOLEAN, -- 为SCell使能Type3 PH (SRS)
stateDiagram-v2
[*] --> NotConfigured: 初始状态
NotConfigured --> Configured: RRC配置PH-Config
Configured --> WaitingTrigger: 启动phr-PeriodicTimer
WaitingTrigger --> Triggered: phr-PeriodicTimer超时
WaitingTrigger --> Triggered: 路损变化≥阈值<br/>& prohibitTimer超时
WaitingTrigger --> Triggered: SCell激活
WaitingTrigger --> Triggered: RRC重配置
Triggered --> WaitingGrant: 设置PHR=triggered
WaitingGrant --> Constructing: 收到UL Grant
Constructing --> WaitingTrigger: PHR MAC CE已发送<br/>重启periodicTimer<br/>启动prohibitTimer
WaitingTrigger --> NotConfigured: RRC释放/重配置清除
| 配置策略 | phr-PeriodicTimer | phr-ProhibitTimer | dl-PathlossChange | 适用场景 | 开销影响 |
|---|---|---|---|---|---|
| 高频灵敏 | sf50 | sf10 | dB1 | 高速移动、FR2 | MAC CE开销增加3~5倍 |
| 均衡配置 | sf200 | sf50 | dB3 | 一般eMBB | 基准开销 |
| 低频省电 | sf1000 | sf200 | dB6 | 静止/低速IoT | 开销最小,gNB感知滞后 |
| 事件驱动 | ∞ | sf50 | dB1 | 仅靠路损变化触发 | 适合信道稳定的室内场景 |
| 维度 | Single Entry PHR | Multiple Entry PHR |
|---|---|---|
| 覆盖范围 | 仅PCell | PCell + 所有激活SCell |
| MAC CE大小 | 固定2字节 | 变长:2 + 2×N(N=服务小区数) |
| LCID | 56 | 54(MCG)/ 57(SCG in EN-DC) |
| 开销 | 最小 | 4CC场景约10字节 |
| 配置条件 | multiplePHR = false | multiplePHR = true |
| 典型场景 | 非CA场景 | CA或EN-DC场景 |
场景1:5G广覆盖eMBB
- 通常配置:phr-PeriodicTimer = sf200,dl-PathlossChange = dB3
- 博弈点:gNB需要足够快的PHR更新来适应小区边缘用户的路损变化,但过于频繁的PHR会挤占上行资源
- 实测数据:PHR MAC CE约占上行MAC PDU的1%~3%
场景2:FR2毫米波覆盖
- 必须配置mpe-Reporting-FR2,因为MPE功率回退可能达到10dB以上
- dl-PathlossChange建议配置为dB1,因为FR2路损变化剧烈(人体遮挡可在100ms内导致20dB路损变化)
- 需要同时使能Type 3 PH(SRS-only场景在波束管理中很常见)
场景3:4CC CA + PUCCH SCell
- 必须使用Multiple Entry PHR
- 如果PUCCH被分流到SCell,必须使能phr-Type2-OtherSCell
- 典型MAC CE大小:2(Bitmap)+ 2×4(PH+PCMAX)= 10字节
在Wireshark中解析5G NR MAC层PHR的方法:
MAC CE LCID识别: - LCID = 56 → Single Entry PHR - LCID = 54 → Multiple Entry PHR (MCG) - LCID = 57 → Multiple Entry PHR (SCG)
关键字段解析: - PH值 → 换算为dB(PH Index映射表) - C字段 → 判断是实际PH还是虚拟PH - PCMAX,f,c → UE最大功率配置
典型抓包特征: - PHR MAC CE通常出现在PUSCH MAC PDU的最后一个或几个子PDU - 在CA场景下,只有PCell的PUSCH会携带PHR MAC CE(SCell的PH通过PCell上报)
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| gNB调度MCS过高导致BLER上升 | PHR未及时上报,gNB高估了UE功率裕量 | 检查phr-PeriodicTimer是否过大;检查phr-ProhibitTimer是否抑制了路损触发的PHR |
| UE上行覆盖受限,速率低 | PHR上报PH=0或负值 | 检查PCMAX配置;检查功率控制参数(P0、alpha);检查是否MPE回退过大 |
| SCell激活后调度异常 | SCell激活触发的PHR未正确上报 | 检查SCell是否配置了phr-Type1-OtherSCell;检查Multiple Entry PHR的Bitmap是否正确 |
| EN-DC场景PHR缺失 | SCG的PHR未配置或LCID错误 | 检查dualCellPHR配置;检查SCG MAC实体的PH-Config |
| FR2场景功率突然下降 | MPE回退导致PCMAX大幅降低 | 检查MPE报告;检查mpe-Reporting-FR2是否配置;分析P-MPR值 |
| ## 9. PHR与上行功率控制的联动 |
PHR不是孤立存在的,它与NR上行功率控制机制(TS 38.213 Section 7.1~7.3)形成闭环反馈:
graph TD
subgraph "UE侧"
PC["上行功率控制<br/>PUSCH/PUCCH/SRS<br/>TS 38.213"]
PH["PHR计算<br/>PCMAX - 实际功率"]
MPE["MPE功率回退<br/>FR2场景"]
end
subgraph "gNB侧"
SCH["调度器<br/>MCS/RB/层数决策"]
TPC["TPC命令<br/>DCI中的功率调整"]
POL["策略引擎<br/>PHR阈值判断"]
end
PC --> PH
MPE --> PC
PH -->|"PHR MAC CE"| POL
POL --> SCH
POL --> TPC
TPC -->|"DCI"| PC
SCH -->|"调度决策"| PC
联动机制: 1. gNB通过TPC命令调整UE的P0目标功率 2. UE根据功率控制公式计算实际发射功率 3. UE通过PHR上报功率裕量 4. gNB根据PHR调整调度策略(如PH接近0则降低MCS或减少RB) 5. 形成闭环控制
Q1: Type 1 PH中"实际PH"和"虚拟PH"有什么区别?什么时候上报虚拟PH?
A: 实际PH(C=0)是UE在该服务小区有PUSCH传输时,用实际发射功率计算出的PH值。虚拟PH(C=1)是UE在该服务小区没有PUSCH传输时,假设按参考格式(0 RB,默认MCS)计算的假设功率来推算的PH。虚拟PH的意义在于:即使某个SCell当前没有PUSCH调度,gNB也能预判如果在该SCell上调度PUSCH,UE是否有足够的功率。
Q2: 为什么NR需要三种PHR类型而LTE只有两种?
A: LTE只定义了Type 1(PUSCH)和Type 2(PUCCH+PUSCH联合)。NR新增Type 3(SRS)的原因是:NR中SRS的用途远比LTE广泛(波束管理、天线切换、CSI获取),某些SCell可能仅配置SRS而没有PUSCH/PUCCH。如果只依靠Type 1/2,gNB在这些SRS-only SCell上将完全失去功率状态感知。Type 3 PH填补了这一空白。
Q3: FR2场景的MPE报告为什么如此重要?
A: FR2(毫米波频段)的发射功率受到人体电磁辐射暴露限制的约束(FCC/ICNIRP标准)。当UE检测到人体靠近天线时,必须大幅降低发射功率(P-MPR可达10~15dB)。如果不通过PHR上报这个功率回退信息,gNB会基于错误的PCMAX假设进行调度,导致上行覆盖急剧恶化。Release 17引入的MPE报告字段正是为了解决这个问题。
Q4: phr-ProhibitTimer和phr-PeriodicTimer是什么关系?为什么要配两个定时器?
A: phr-PeriodicTimer是周期触发PHR的时间间隔,保证gNB定期获得UE功率状态更新。phr-ProhibitTimer是防止路损变化事件过于频繁触发PHR的保护机制——即使路损频繁变化(如快速移动场景),两次PHR之间也必须间隔至少phr-ProhibitTimer。两者配合实现"定期保底+事件触发+频率限制"的平衡。phr-ProhibitTimer只在路损变化触发和MPE变化触发时起作用,周期触发不受其限制。
Q5: 多个MAC实体的PHR如何协调(EN-DC场景)?
A: EN-DC中UE有两个MAC实体:MCG MAC(NR)和SCG MAC(LTE或NR)。每个MAC实体独立维护自己的PHR触发和上报。MCG的Multiple Entry PHR使用LCID=54,SCG使用LCID=57。当dualCellPHR = true时,PHR MAC CE中会增加额外的字段报告另一个MAC实体的功率余量,实现跨MAC实体的功率协调。这在功率共享场景下尤为重要——两个MAC实体共享UE总功率预算,一个实体的大功率传输会影响另一个实体的可用功率。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
