<!-- title: NR SCell激活去激活MAC CE与定时器博弈 -->
<!-- domain: ran -->

# NR SCell激活去激活MAC CE与定时器博弈

## 1. 为什么SCell激活/去激活是CA性能的命门

载波聚合（Carrier Aggregation, CA）是5G NR提升吞吐量的核心手段。一个UE最多可配置31个SCell（TS 38.331 Section 6.3.2），但UE的射频能力有限——同时维持多个载波的收发意味着功耗飙升、热量堆积。3GPP因此设计了**SCell激活/去激活机制**（TS 38.321 Section 5.9），允许网络按需动态开关辅载波，在吞吐量与功耗之间博弈。

这个机制看似简单——一个MAC CE搞定激活，一个定时器管住去激活——但实际上涉及MAC CE格式选择、激活时延约束、定时器重启策略、Rel-16引入的休眠BWP中间态，以及与CSI报告、BWP切换的联动。一条MAC CE的bitmap写错、一个定时器配置不合理，就可能导致SCell"假激活"或"过度去激活"，直接影响CA增益。

## 2. SCell三态模型：从去激活到休眠

在Rel-15中，SCell只有两个状态：**去激活（Deactivated）**和**激活（Activated）**。Rel-16引入了**休眠态（Dormant）**作为中间态，形成三态模型：

```mermaid
stateDiagram-v2
    [*] --> Deactivated : RRC配置SCell\n默认去激活
    Deactivated --> Activated : MAC CE激活\n(LCID 58/59)
    Activated --> Deactivated : MAC CE去激活\n或sCellDeactivationTimer超时
    Activated --> Dormant : DCI休眠指示\n或scellDormancyTimer超时\n(Rel-16)
    Dormant --> Activated : DCI激活指示\n或MAC CE激活
    Dormant --> Deactivated : MAC CE去激活
    note right of Activated
        PDCCH监听 ✓
        CSI报告 ✓
        SRS传输 ✓
        数据收发 ✓
    end note
    note right of Dormant
        PDCCH监听 ✗
        CSI测量 ✓(受限)
        保持时频同步 ✓
        功耗降低~40%
    end note
    note right of Deactivated
        PDCCH监听 ✗
        CSI报告 ✗
        SRS传输 ✗
        仅RRM测量
    end note
```

三态的核心差异在于**PDCCH监听义务**和**CSI报告能力**：

| 行为 | Deactivated | Dormant (Rel-16) | Activated |
|------|-------------|-------------------|-----------|
| PDCCH监听 | ✗ | ✗ | ✓ |
| CSI报告 | ✗ | 仅周期性（受限） | ✓ |
| SRS传输 | ✗ | ✗ | ✓ |
| PDSCH/PUSCH收发 | ✗ | ✗ | ✓ |
| 时频同步 | ✗ | ✓ | ✓ |
| RRM测量 | ✓（最小间隔） | ✓ | ✓ |
| 功耗（相对值） | 基准（最低） | ~40%激活态 | 100% |

**设计意图**：去激活→激活的切换需要SCellSwitchTiming时延（FR1约3~8 slot），而休眠→激活只需切换BWP（通常1~2 slot），相当于用极小的额外功耗换取更快的SCell恢复速度。

## 3. MAC CE格式：1字节还是4字节的bitmap博弈

### 3.1 两种MAC CE格式

TS 38.321 Section 6.1.3.9定义了两种SCell激活/去激活MAC CE：

**格式一：单字节bitmap（LCID = 58）**

```
   Octet 1:
   Bit:  7    6    5    4    3    2    1    0
        +----+----+----+----+----+----+----+----+
        | C7 | C6 | C5 | C4 | C3 | C2 | C1 | A  |
        +----+----+----+----+----+----+----+----+
```

- **Ci (i=1~7)**：控制SCellIndex=i的SCell，1=激活，0=去激活
- **A位**：固定为1（区分两种格式）
- **适用**：SCell数量≤7的场景

**格式二：四字节bitmap（LCID = 59）**

```
   Octet 1:                        Octet 2:
   Bit:  7  6  5  4  3  2  1  0   Bit:  7  6  5  4  3  2  1  0
        +--+--+--+--+--+--+--+--+      +--+--+--+--+--+--+--+--+
        |C7|C6|C5|C4|C3|C2|C1|R |      |C15|C14|C13|C12|C11|C10|C9|C8|
        +--+--+--+--+--+--+--+--+      +--+--+--+--+--+--+--+--+
   Octet 3:                        Octet 4:
        +--+--+--+--+--+--+--+--+      +--+--+--+--+--+--+--+--+
        |C23|C22|C21|C20|C19|C18|C17|C16|  |C31|C30|C29|C28|C27|C26|C25|C24|
        +--+--+--+--+--+--+--+--+      +--+--+--+--+--+--+--+--+
```

- **Ci (i=1~31)**：控制SCellIndex=i的SCell
- **R位**：保留位，固定为0
- **适用**：大规模CA场景（8个以上SCell）

```mermaid
flowchart TD
    A[gNB决定激活/去激活SCell] --> B{SCell数量}
    B -->|≤7个SCell| C[使用LCID 58\n单字节MAC CE]
    B -->|>7个SCell| D[使用LCID 59\n四字节MAC CE]
    C --> E[Bitmap写入Ci位\n1=激活 0=去激活]
    D --> F[32-bit Bitmap写入\nCi位 1=激活 0=去激活]
    E --> G[MAC PDU组包\nSubheader + CE]
    F --> G
    G --> H[PCell PDSCH发送\nUE解码MAC CE]
    H --> I{A位=?}
    I -->|A=1| J[单字节格式解析]
    I -->|A=0| K[四字节格式解析]
    J --> L[逐bit执行激活/去激活]
    K --> L
```

**关键细节**：gNB可以**同时**在一条MAC CE中激活部分SCell、去激活另一部分SCell。这意味着bitmap中不同位可以有不同的值——这是批量管理SCell的核心手段。运营商在配置SCell时，应避免跨格式混用（即不要在同一个MAC PDU中同时发送两种格式的MAC CE），虽然协议未明确禁止，但实现上可能引发竞争条件。

## 4. 完整信令时序图：从RRC配置到激活再到定时器去激活

```mermaid
sequenceDiagram
    participant gNB
    participant UE

    Note over gNB,UE: 阶段一：RRC配置SCell
    gNB->>UE: RRCReconfiguration
    Note right of UE: scellToAddModList:<br/>SCellIndex=1, SCellConfig<br/>sCellDeactivationTimer=ms2048<br/>initialState=deactivated

    Note over gNB,UE: 阶段二：MAC CE激活
    gNB->>UE: PDCCH DCI 1_1 (PCell)
    gNB->>UE: PDSCH: MAC CE (LCID=58, C1=1)
    Note right of UE: slot n: 接收MAC CE PDSCH<br/>解码MAC CE: SCellIndex=1 激活
    Note right of UE: slot n + SCellSwitchTiming<br/>SCell正式激活

    Note over UE: 激活后UE行为：
    Note right of UE: 1. 启动sCellDeactivationTimer=2048ms
    Note right of UE: 2. 开始PDCCH监听（SCell）
    Note right of UE: 3. 执行AGC、时频同步
    Note right of UE: 4. 激活active BWP
    Note right of UE: 5. 启动CSI测量和报告

    Note over gNB,UE: 阶段三：数据传输（定时器持续重启）
    loop 每次SCell上有PDCCH调度
        gNB->>UE: PDCCH (SCell) → PDSCH/PUSCH调度
        Note right of UE: 重启sCellDeactivationTimer
    end

    Note over gNB,UE: 阶段四：无业务，定时器超时
    Note right of UE: 2048ms无PDCCH调度<br/>sCellDeactivationTimer超时
    Note right of UE: SCell自动去激活
    Note right of UE: 停止PDCCH监听<br/>停止CSI报告<br/>清除HARQ缓冲区

    Note over gNB,UE: 阶段五（可选）：Rel-16 Dormant态
    gNB->>UE: DCI Dormancy指示
    Note right of UE: SCell切换到dormant BWP
    Note right of UE: 停止PDCCH监听<br/>保持时频同步<br/>继续受限CSI测量
```

### 4.1 阶段一：RRC配置（TS 38.331 Section 6.3.2）

SCell通过`RRCReconfiguration`消息的`scellToAddModList`添加。关键字段：

| IE字段 | 说明 | 取值示例 |
|--------|------|----------|
| SCellIndex | SCell编号 | 1~31 |
| sCellDeactivationTimer | 去激活定时器 | ms1~ms61440 |
| ServingCellConfig | 完整物理层/MAC配置 | BWP、CSI、功率控制等 |
| firstActiveDownlinkBWP-Id | 首次激活的DL BWP | BWP-Id |
| defaultDownlinkBWP-Id | 默认DL BWP | BWP-Id |

**初始状态**：RRC添加SCell后，除非RRC明确指定`SCellState=activated`，否则SCell默认为去激活态。

### 4.2 阶段二：MAC CE激活与时延

UE在slot n接收到MAC CE PDSCH后，需要等待**SCellSwitchTiming**个slot才能正式激活SCell。这个时延由UE能力决定（TS 38.306 Section 4.2.10），在不同频段和SCS下差异巨大：

| 条件 | SCS | SCellSwitchTiming | 绝对时延 |
|------|-----|-------------------|----------|
| FR1 带内CA | 15 kHz | 3 slots | ~3 ms |
| FR1 带内CA | 30 kHz | 6 slots | ~3 ms |
| FR1 带间CA | 15 kHz | 5~8 slots | ~5~8 ms |
| FR2 带内CA | 120 kHz | 10~20 slots | ~0.8~1.6 ms |
| FR2 带间CA | 120 kHz | 15~30 slots | ~1.25~2.5 ms |

**设计意图**：激活时延包含MAC CE解码、射频重调、AGC收敛、时频同步、波束测量（FR2）等多个步骤。FR2虽然slot更短但波束扫描需要额外时间，所以slot数量更多但绝对时间反而更短。

### 4.3 阶段三：定时器管理

`sCellDeactivationTimer`是整个机制中最容易出问题的环节。核心规则：

- **启动/重启条件**（TS 38.321 Section 5.9）：
  - MAC CE激活SCell时启动
  - SCell上收到**任何PDCCH调度**（DL assignment或UL grant）时重启
  - 注意：仅PDCCH计费，PDSCH/PUSCH本身不计费

- **超时动作**：
  - SCell去激活
  - 清空该SCell所有DL/UL HARQ进程缓冲区
  - 停止该SCell上所有配置的定时器（如bwp-InactivityTimer）
  - 释放该SCell的CSI报告资源

```mermaid
flowchart TD
    A[SCell已激活] --> B{sCellDeactivationTimer<br/>是否配置?}
    B -->|未配置| C[SCell保持激活<br/>直到MAC CE显式去激活]
    B -->|已配置| D[启动Timer]
    D --> E{收到SCell PDCCH?}
    E -->|是| F[重启Timer]
    F --> E
    E -->|否| G{Timer超时?}
    G -->|否| E
    G -->|是| H[SCell自动去激活<br/>清空HARQ缓冲区<br/>停止CSI报告]
```

## 5. sCellDeactivationTimer配置博弈：运营商的头疼选择

定时器值的配置直接影响CA增益与UE功耗的平衡：

| 定时器配置 | 优势 | 劣势 | 适用场景 |
|------------|------|------|----------|
| 短（ms64~ms256） | UE省电，SCell快速释放 | 频繁激活/去激活，信令开销大 | IoT、低业务量 |
| 中（ms1024~ms2048） | 平衡省电与CA增益 | 可能存在无效PDCCH监听 | 典型eMBB |
| 长（ms8192~ms61440） | CA增益最大化，减少重激活时延 | UE功耗高，射频持续工作 | 高速业务、固定宽带 |
| 不配置（infinity） | SCell永远不自动去激活 | 严重耗电 | 几乎不使用 |

**实际博弈**：某运营商实测数据显示，定时器设为ms2048时，SCell平均激活率约65%，UE功耗比单载波高约18%；设为ms512时，激活率降至30%，功耗仅增8%但CA增益损失40%。这是一个**非线性的代价曲线**——定时器从ms2048缩短到ms1024，功耗下降不多但CA增益损失明显。

## 6. Rel-16休眠BWP：激活与去激活之间的缓冲带

Rel-16引入SCell休眠态（TS 38.321 Section 5.13），通过**dormant BWP**实现。其核心思路是：与其让SCell在"全激活"和"完全去激活"之间跳变，不如引入一个"低功耗待命"状态。

### 6.1 休眠态的工作原理

休眠态通过配置一个特殊的BWP（dormant BWP）实现：

| 操作 | 正常激活态 | 休眠态 |
|------|-----------|--------|
| Active BWP | 正常业务BWP（如100MHz） | dormant BWP（如10MHz） |
| PDCCH监听 | 正常SearchSpace | 无（不监听） |
| CSI-RS测量 | 完整CSI测量 | 仅TRR/RRM测量 |
| AGC/同步 | 维持 | 维持 |
| 恢复时延 | — | BWP切换（1~2 slot） |

**关键优势**：从休眠态恢复到激活态只需要BWP切换，不需要经历完整的SCell激活时延（SCellSwitchTiming）。这意味着：

- 去激活→激活：约3~8 ms（FR1）
- 休眠→激活：约1~2 ms（BWP切换时延）

### 6.2 休眠态触发方式

| 触发方式 | 方向 | 机制 |
|----------|------|------|
| DCI Format 1_1/1_2中的dormancy指示 | 激活→休眠 | DCI中嵌入dormancy group bitmap |
| scellDormancyTimer超时 | 激活→休眠 | 独立于sCellDeactivationTimer |
| DCI激活指示 | 休眠→激活 | 同一DCI dormancy bitmap反转 |
| MAC CE激活 | 休眠→激活 | 传统MAC CE也可触发 |

```mermaid
flowchart LR
    subgraph Rel-15 二态模型
        D1[Deactivated] -->|MAC CE\nSCellSwitchTiming\n3-8ms| A1[Activated]
        A1 -->|Timer超时\nMAC CE\n即时| D1
    end

    subgraph Rel-16 三态模型
        D2[Deactivated] -->|MAC CE\nSCellSwitchTiming\n3-8ms| A2[Activated]
        A2 -->|DCI/Timer\nBWP切换\n1-2ms| DR[Dormant]
        DR -->|DCI\nBWP切换\n1-2ms| A2
        DR -->|MAC CE| D2
        A2 -->|Timer超时\nMAC CE| D2
    end
```

## 7. 抓包识别：如何从log中看到SCell激活/去激活

### 7.1 关键识别点

在UE log中（如QXDM、Qualcomm QCAT、Mediatek ELT），SCell激活/去激活的识别路径：

**RRC层**：
- 搜索`RRC_RECONFIGURATION`消息
- 定位`scellToAddModList`字段
- 确认`SCellIndex`和`sCellDeactivationTimer`值

**MAC层**：
- 搜索MAC CE LCID=58或LCID=59
- 读取bitmap，确认哪些SCell被激活/去激活
- 对比时间戳，确认激活生效时刻

**PHY层**：
- 观察SCell上是否出现PDCCH解码记录
- 检查SCell的CSI报告是否开始上报
- 确认SCell上PDSCH/PUSCH调度记录

### 7.2 常见故障排查表

| 故障现象 | 可能原因 | 排查思路 |
|----------|----------|----------|
| MAC CE已发送但SCell未激活 | SCellSwitchTiming未过 | 检查激活时延是否满足 |
| SCell频繁激活/去激活 | sCellDeactivationTimer太短 | 检查定时器配置值和PDCCH调度密度 |
| SCell激活后无数据调度 | gNB侧SCell未准备好 | 检查gNB SCell状态机 |
| SCell配置后无MAC CE激活 | gNB策略不激活 | 检查CA策略和负载均衡配置 |
| Rel-16休眠BWP未生效 | UE能力不支持 | 检查UE能力上报中的dormancy支持 |
| 定时器配置为infinity但SCell被去激活 | 收到了显式MAC CE | 检查是否有去激活MAC CE |
## 9. 与其他机制的联动

SCell激活/去激活不是一个孤立机制，它与多个NR过程紧密联动：

**与BWP切换的联动**（TS 38.321 Section 5.15）：
- SCell激活时，UE自动激活该SCell的`firstActiveDownlinkBWP-Id`
- SCell去激活时，UE将active BWP重置为默认BWP
- 如果Rel-16 dormant BWP配置，bwp-InactivityTimer超时后UE切换到dormant BWP而非直接去激活

**与CSI报告的联动**（TS 38.214 Section 5.2）：
- SCell去激活时，该SCell相关的所有CSI报告停止
- SCell激活后，UE需要至少完成一次CSI测量才能上报有效CQI
- 网络在SCell激活后立即调度数据可能面临CQI不准确的问题

**与HARQ的联动**（TS 38.321 Section 5.4）：
- SCell去激活时，该SCell所有HARQ进程被清空
- 未完成的HARQ重传直接丢失
- 这意味着gNB在发送去激活MAC CE前应确保所有HARQ进程已完成

```mermaid
sequenceDiagram
    participant gNB
    participant UE_MAC
    participant UE_PHY

    Note over gNB,UE_PHY: SCell激活后的联动时序

    gNB->>UE_MAC: MAC CE激活SCell (slot n)
    UE_MAC->>UE_PHY: 指令：激活SCell

    Note over UE_PHY: slot n → n+SCellSwitchTiming
    UE_PHY->>UE_PHY: RF重调谐 + AGC收敛
    UE_PHY->>UE_PHY: 时频同步（SSB/CSI-RS）
    UE_PHY->>UE_PHY: 激活BWP (firstActiveDownlinkBWP)

    Note over UE_MAC: slot n+SCellSwitchTiming: 正式激活
    UE_MAC->>UE_MAC: 启动sCellDeactivationTimer
    UE_MAC->>UE_PHY: 开始PDCCH监听

    UE_PHY->>UE_PHY: 执行CSI测量（至少1次）
    UE_PHY->>UE_MAC: CSI报告可用

    Note over gNB,UE_PHY: SCell可用于数据调度
    gNB->>UE_PHY: PDCCH调度 (SCell)
    UE_MAC->>UE_MAC: 重启sCellDeactivationTimer
```

## 10. 实战场景分析

### 场景一：视频流业务CA优化

某运营商5G网络中，视频流用户配置了3CC CA（PCell + 2 SCell）。初始配置sCellDeactivationTimer=ms512，导致视频缓冲期间SCell被频繁去激活。

**问题分析**：视频流特征是"突发下载+静默期"。下载阶段3CC全开，静默期（约500ms~2s）内无数据调度导致timer超时，SCell去激活。下次突发到来需重新激活，引入3~8ms额外时延。

**优化方案**：
1. 将sCellDeactivationTimer调整为ms2048，覆盖典型静默期
2. Rel-16启用dormant BWP：静默期进入dormant而非deactivated，恢复时延从3~8ms降至1~2ms
3. 效果：CA激活率从45%提升至78%，平均吞吐量提升23%，UE功耗仅增5%

### 场景二：FR2 mmWave SCell激活优化

FR2波束管理使SCell激活时延更大——不仅需要AGC收敛，还需要波束扫描（P1/P2过程）。

**关键差异**：
- FR1 SCell激活：AGC + 同步 ≈ 3ms
- FR2 SCell激活：AGC + 同步 + 波束扫描 ≈ 5~10ms
- FR2场景下SCellSwitchTiming slot数更多但绝对时间因高SCS而缩短

**优化建议**：FR2场景应尽量使用dormant BWP避免完全去激活，同时利用SSB或CSI-RS维持波束跟踪。

## 11. Rel-18/19演进方向

Rel-18进一步增强了SCell管理：

- **DCI-based SCell activation**：通过DCI而非MAC CE激活SCell，减少MAC层处理时延
- **更细粒度的dormancy控制**：基于SCell group的dormancy管理
- **AI/ML辅助SCell激活预测**：基于业务模式预测提前激活SCell

## 常见问题

**Q1: sCellDeactivationTimer重启条件中"收到PDCCH调度"具体指什么？**
A: 指的是SCell上检测到针对该UE的PDCCH DCI（下行assignment或上行grant），且该DCI的CRC被C-RNTI/CS-RNTI加扰。PDCCH的纯存在（如公共搜索空间中的SI-RNTI DCI）不算。如果SCell处于DRX非激活期，收到PDCCH也算触发重启（如果PDCCH在DRX active time内）。

**Q2: Rel-15的UE能用dormant BWP吗？**
A: 不能。dormant BWP是Rel-16引入的特性，需要UE在能力上报中支持`scellDormancy`。Rel-15 UE只能使用二态模型（activated/deactivated）。但gNB可以在RRC配置时根据UE能力选择是否配置dormant BWP。

**Q3: 一条MAC CE能同时激活和去激活不同的SCell吗？**
A: 可以。MAC CE的bitmap中每个bit独立控制一个SCell。Ci=1表示激活SCellIndex=i，Ci=0表示去激活。所以一条MAC CE可以同时激活SCell 1、去激活SCell 2。但注意：同一个SCell不能同时被两条MAC CE操作（需要等待前一条MAC CE生效后再操作）。

**Q4: SCell去激活后HARQ缓冲区清空，正在进行的数据怎么处理？**
A: SCell去激活时该SCell所有HARQ进程的缓冲区被清空，未完成的重传直接丢弃。协议的设计假设是gNB在发送去激活MAC CE前已确保所有HARQ进程完成。如果因为timer超时导致去激活，未完成的传输确实会丢失——上层（RLC AM）会通过ARQ重传来恢复。

**Q5: SCell激活后网络应等多久才能调度数据？**
A: 理论上SCellSwitchTiming后即可调度，但实际建议等待至少一个CSI报告周期后再调度大量数据。因为激活后第一次CSI报告可能不够准确（UE刚完成时频同步，CQI测量样本不足）。通常建议等待2~4个CSI报告周期（约5~10ms）后开始密集调度。

## 参考来源
1. [3GPP TS 38.321 V19.x.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3193) — Section 5.9 SCell Activation/Deactivation, Section 5.13 SCell Dormancy, Section 6.1.3.9 MAC CE Format
2. [3GPP TS 38.331 V19.x.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3194) — Section 6.3.2 SCellConfig IE, sCellDeactivationTimer, dormantBWP-Config
3. [3GPP TS 38.133 V19.x.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3204) — Section 8.5 SCell Activation/Deactivation Delay Requirements
4. [NR Explained - SCell Activation](https://www.nrexplained.com/scell_act) — SCell activation timeline and SCellSwitchTiming details
5. [ShareTechnote - 5G MAC CE](https://www.sharetechnote.com/html/5G/5G_MAC_CE_Activation_Deactivation.html) — MAC CE format illustration and LCID mapping

---
> 本文由「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)