<!-- title: PHR三类型上报与定时器触发博弈 -->
<!-- domain: ran -->

# NR PHR功率余量三类型上报与定时器触发博弈

## 1. PHR机制全景：gNB为何需要知道UE的"功率家底"

在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类型的设计意图

| 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场景 |

```mermaid
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
```

## 2. 触发条件深度拆解：五重触发与三重定时器的博弈

TS 38.321 Section 5.4.6定义了PHR的完整触发逻辑。理解这套逻辑的关键在于把握三个定时器和五个触发事件之间的博弈关系。

### 2.1 核心定时器参数（TS 38.331 PH-Config）

| 参数 | 取值范围 | 典型配置 | 作用 |
|------|---------|---------|------|
| `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 |

### 2.2 五重触发条件的精确时序

```mermaid
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值，调整调度策略
```

### 2.3 触发条件2的核心逻辑（路径损耗触发）

这是最复杂的触发条件。TS 38.321 Section 5.4.6规定：

**当`phr-ProhibitTimer`超时或未运行时**，如果以下任一条件满足，则触发PHR：

1. 对任何配置了PHR的服务小区，UE测量的下行路径损耗变化量（绝对值）超过`dl-PathlossChange` dB——这是最常见的触发场景，UE移动或遮挡导致路损剧烈变化
2. 在FR2场景下，为了满足MPE（Maximum Permissible Exposure）要求而施加的P-MPR（Power Management Maximum Power Reduction）变化量超过`dl-PathlossChange` dB——这是NR新增的触发条件，LTE中不存在

**关键博弈**：`phr-ProhibitTimer`与`dl-PathlossChange`的配对关系决定了PHR上报的灵敏度：
- **高频小步长配置**（sf10 + dB1）：适合高速移动或信道快速变化的场景，但开销大
- **低频大步长配置**（sf1000 + dB6）：适合静止或低速场景，节省开销但gNB对功率状态的感知滞后

## 3. PHR计算公式：实际值与虚拟值的博弈

### 3.1 Type 1 PH计算（TS 38.321 Section 5.4.6）

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）计算出的假设功率。

### 3.2 Type 2 PH计算

**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。

### 3.3 Type 3 PH计算

**PH = PCMAX,f,c - ˆPSRS,f,c**

Type 3 PH针对SRS传输的功率裕量。在某些SCell上，可能仅配置了SRS而没有PUSCH/PUCCH（用于波束管理或CSI获取），此时gNB无法从Type 1/2 PH中获取该小区的功率状态，Type 3 PH填补了这一空白。

## 4. MAC CE格式深度解析：从Single Entry到Multiple Entry

### 4.1 Single Entry PHR MAC CE（LCID=56）

最简格式，仅报告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可大胆调度 |

### 4.2 Multiple Entry PHR MAC CE格式

在CA场景下，Single Entry显然不够用——UE可能同时有多个激活的SCell。Multiple Entry PHR MAC CE通过位图机制一次报告多个服务小区的PH值。

#### 4.2.1 位图结构（Bitmap）

```
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**：该服务小区不包含条目

#### 4.2.2 完整MAC CE结构（以4个服务小区为例）

```mermaid
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) | 保留比特 |

### 4.3 R18增强：MPE报告字段

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） |

## 5. PHR上报完整信令流程

```mermaid
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
```

## 6. RRC配置参数与状态机

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)
```

### 状态转换模型

```mermaid
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释放/重配置清除
```

## 7. 关键博弈分析：参数配置对网络性能的影响

### 7.1 定时器配对博弈

| 配置策略 | 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 | 仅靠路损变化触发 | 适合信道稳定的室内场景 |

### 7.2 Single Entry vs Multiple Entry博弈

| 维度 | 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场景 |

### 7.3 运营商实际配置的博弈思考

**场景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字节

## 8. 抓包识别与故障排查实战

### 8.1 Wireshark抓包识别

在Wireshark中解析5G NR MAC层PHR的方法：

1. **MAC CE LCID识别**：
   - LCID = 56 → Single Entry PHR
   - LCID = 54 → Multiple Entry PHR (MCG)
   - LCID = 57 → Multiple Entry PHR (SCG)

2. **关键字段解析**：
   - PH值 → 换算为dB（PH Index映射表）
   - C字段 → 判断是实际PH还是虚拟PH
   - PCMAX,f,c → UE最大功率配置

3. **典型抓包特征**：
   - PHR MAC CE通常出现在PUSCH MAC PDU的最后一个或几个子PDU
   - 在CA场景下，只有PCell的PUSCH会携带PHR MAC CE（SCell的PH通过PCell上报）

### 8.2 常见故障场景

| 故障现象 | 可能原因 | 排查思路 |
|---------|---------|---------|
| 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）形成闭环反馈：

```mermaid
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总功率预算，一个实体的大功率传输会影响另一个实体的可用功率。

## 参考来源

1. [3GPP TS 38.321 V19.0.0](https://www.etsi.org/deliver/etsi_ts/138300_138399/138321/19.00.00_60/ts_138321v190000p.pdf) — Section 5.4.6 PHR触发机制, Section 6.1.3.6~6.1.3.9 MAC CE格式
2. [3GPP TS 38.331 V19.0.0](https://www.etsi.org/deliver/etsi_ts/138300_138399/138331/19.00.00_60/ts_138331v190000p.pdf) — PH-Config IE定义, RRC配置参数
3. [3GPP TS 38.133 V19.0.0](https://www.etsi.org/deliver/etsi_ts/138100_138199/138133/19.00.00_60/ts_138133v190000p.pdf) — Table 10.1.17.1-1 PH值映射表, PCMAX编码表
4. [TS 38.321 Section 5.4.6 — iTecSpec](https://itecspec.com/3gpp/38.321/s/5.4.6) — PHR触发条件在线解析
5. [5G NR MAC Power Headroom Report — 3GLTEInfo](https://www.3glteinfo.com/5g/protocols/mac/power-headroom-report/) — PHR MAC CE完整参考

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)