<!-- title: L1/L2触发移动性LTM切换拆解 -->
<!-- domain: ran -->

# L1/L2触发移动性LTM小区切换信令全链拆解

## 一、为什么需要LTM：传统切换的"毫秒级"天花板

在5G网络的移动性管理中，连接态切换（Handover）长期以来都由**RRC层（L3）**主导决策与执行：UE通过`MeasurementReport`上报L3测量结果，gNB经`RRCReconfiguration`（含`reconfigurationWithSync`）下发目标小区完整配置，UE再回`RRCReconfigurationComplete`。这条链路涉及多次L3处理与空口信令交互，整体时延通常在**数十毫秒量级**，其中连接中断时间（interruption time）是用户感知最强的部分。

对于普通eMBB业务，这个时延几乎无感；但对于**URLLC工业自动化、远程医疗、FR2毫米波高频小区频繁切换、高速列车**等场景，几十毫秒的中断会导致丢包、控制指令超时甚至链路失败。传统L3切换存在三个固有瓶颈：

1. **决策滞后**：必须等待L3层测量上报与滤波，测量周期长（数百ms），无法捕捉快速信道变化；
2. **执行沉重**：切换瞬间才下发完整目标配置，UE需要完整解析RRC、重建RLC/PDCP、重新同步下行；
3. **中断不可压缩**：下行同步（T_DL-sync）+ 随机接入（T_RA + T_RAR）串行执行，是中断的主要来源。

3GPP在**Release 18**（5G-Advanced）引入的**L1/L2 Triggered Mobility（LTM，层1/层2触发移动性）**正是为击穿这道天花板而生：它把小区切换的"扳机"从L3下沉到L1/L2层，用一条MAC CE（MAC Control Element）在毫秒甚至亚毫秒级完成服务小区切换。爱立信与联发科在2024年的联合测试中验证了LTM对切换中断时间的显著压缩。

本文聚焦**TS 38.321 §6.1.3.75（LTM Cell Switch Command MAC CE）+ §5.18.35（执行流程）+ TS 38.331 §5.3.5.18.6（cell switch execution）+ TS 38.300 Annex G（时延建模）**，逐IE拆解这条关键信令。

## 二、LTM的设计哲学：预配置 + 早同步 + MAC CE扳机

LTM的核心设计可归纳为三个动作的解耦，这与CHO（条件切换）、DAPS（双活协议栈）有本质不同：

```mermaid
flowchart LR
    A[RRC准备阶段<br/>预配置候选小区] -->|提前完成| B[L1测量+早期同步<br/>持续跟踪候选]
    B -->|L1测量报告<br/>MAC CE| C{gNB决策}
    C -->|LTM Cell Switch<br/>Command MAC CE| D[毫秒级切换执行<br/>RACH-less]
    style A fill:#e8f5e9
    style B fill:#fff3e0
    style D fill:#fce4ec
```

- **预配置（Pre-configuration）**：gNB在UE尚未需要切换时，就通过一条`RRCReconfiguration`把若干**LTM候选小区**的完整配置（含TCI状态、BWP、RACH资源、SR配置）下发给UE并存储。这样切换瞬间无需再传庞大RRC消息。
- **早期同步（Early Synchronization）**：UE在切换触发之前，就对候选小区做下行同步和L1测量（RSRP/RSRQ/SINR），把T_DL-sync"提前消费"掉。
- **MAC CE扳机**：gNB基于L1测量报告决策后，仅发一条**LTM Cell Switch Command MAC CE**（带目标配置ID），UE在MAC层直接套用预存配置，跳过RRC信令往返。

下表对比LTM与几种主流移动性机制的本质差异：

| 维度 | 传统HO（L3） | CHO（条件切换） | DAPS（双活栈） | **LTM（层间触发）** |
|------|------|------|------|------|
| 触发/执行层 | L3 RRC | L3 RRC（UE自评估） | L3 RRC | **L1/L2（MAC CE）** |
| 切换命令承载 | RRCReconfiguration | RRCReconfiguration w/ CHO | RRCReconfiguration | **LTM Cell Switch MAC CE** |
| 目标配置下发时机 | 切换瞬间 | 预配置 | 切换瞬间 | **预配置** |
| 是否需RACH | 必须 | 视配置 | 必须 | **RACH-less可省** |
| 中断时间量级 | 数十ms | ~10ms | 接近0（双收） | **亚ms~数ms** |
| 信令开销 | 高 | 中 | 高 | **低** |
| 复杂度/功耗 | 低 | 中 | 高（双协议栈） | 中 |

> 设计取舍：DAPS用"双倍资源"换"零中断"，代价是UE复杂度和功耗极高；LTM用"预计算+MAC CE"换"低中断"，代价是前期信令开销和UE存储。LTM是**复杂度与性能的更优平衡点**，因此被3GPP选为5G-Advanced的主力移动性增强方向。

## 三、RRC准备阶段：候选小区预配置（IE级解析）

LTM是**可选UE功能**，UE需在`UECapabilityInformation`中上报LTM能力支持后，gNB才会为其配置。配置载体是一条标准的`RRCReconfiguration`消息，其核心是`reconfigurationWithSync`结构，内含`ltm-Config`及若干`LTM-Candidate`条目。

关键RRC IE（TS 38.331）及其作用如下表：

| RRC IE（TS 38.331） | 作用说明 |
|------|------|
| `ltm-CandidateId` | 候选小区唯一标识，1~8。MAC CE中的Target Configuration ID = 该值减1 |
| `ltm-Config` | LTM总配置容器，含候选列表、安全相关ID等 |
| `ltm-DL-OrJointTCI-StateToAddModList` | 候选小区的DL/联合TCI状态列表（波束指示） |
| `ltm-UL-TCI-StateToAddModList` | 候选小区的UL TCI状态列表（separate模式用） |
| `ltm-TCI-Info.unifiedTCI-StateType` | 取值`joint`或`separate`，决定MAC CE是否携带UL TCI |
| `ltm-SchedulingRequestConfig` | RACH-less期间的SRB1调度请求配置（嵌于reconfigurationWithSync） |
| `ltm-NoSecurityChangeID` / `ltm-ServingCellNoSecurityChangeID` | 安全上下文是否变化标识，决定用普通还是增强MAC CE |
| `tag-Id-ptr` / `tag-id` / `tag2-Id` | 时间对齐组（TAG）指针，用于12bit TA字段的TAG定位 |

**设计意图**：预配置本质上是把"切换瞬间要做的事"提前到"空闲期"做。每个候选小区携带的配置与一次普通`reconfigurationWithSync`等价，但被索引化（ltm-CandidateId）并冻结存储，切换时只需"按ID取货"。

值得注意的是，候选小区的测量参考信号需提前激活。TS 38.321专门定义了**§6.1.3.12a（SP CSI-RS/CSI-IM Resource Set Activation/Deactivation for Candidate Cell MAC CE）**和§5.18.38流程，让gNB为候选小区开启半持续CSI-RS，供UE进行L1测量。配合**§6.1.3.4b（LTM Candidate Timing Advance Command MAC CE）**，gNB还能提前把候选小区的时间提前量（TA）下发给UE——这正是实现RACH-less切换的前提。

## 四、L1测量与早期同步：把时延"提前消费"

准备阶段完成后，RRC层"退居二线"，UE进入持续的L1测量与早期同步状态：

1. UE对已激活CSI-RS的候选小区做L1测量（SSB或CSI-RS上的RSRP/RSRQ/SINR），测量周期远短于L3（典型为数十~数百符号级）；
2. UE通过**L1 Measurement Report MAC CE**周期性上报候选小区的L1测量结果（Rel-19引入**§5.35 + §6.1.3.84 Event Triggered L1 Measurement Report MAC CE**，支持事件触发的按需上报，进一步降低开销）；
3. 与此同时，UE对候选小区完成下行同步（锁定SSB、解析MIB/SIB），使T_DL-sync趋近于零。

gNB据此实时掌握候选小区质量，一旦判定某个候选更优，即可立即触发切换，无需等待L3滤波收敛。这正是LTM决策"快"的根源。

## 五、小区切换执行：MAC CE扳机（核心解析）

切换的"扳机"是**LTM Cell Switch Command MAC CE（TS 38.321 §6.1.3.75）**。它由MAC子头中的eLCID标识（Table 6.2.1-1b），长度可变。这条MAC CE之所以能压缩中断时间，是因为它把"切换所需的一切"都打包进了一条L2消息：目标是谁、用哪个波束、TA是多少、要不要RACH、RACH资源在哪。

下表逐字段解析这条MAC CE（这是LTM最关键的信令承载）：

| 字段 | 长度 | 取值含义 | 设计作用 |
|------|------|------|------|
| **Target Configuration ID** | 3 bit | = `ltm-CandidateId` − 1 | 指明切到哪个候选小区（支持最多8个候选） |
| **Timing Advance Command** | 12 bit | `FFF`=无有效TA（须RACH）；否则=TA索引`T_A`，UE可跳过RACH | **RACH-less的总开关**；FFF则走RACH-based |
| **TCI state ID** | 7 bit | `ltm-DL-OrJointTCI-StateToAddModList`中的TCI-StateId；joint时为联合TCI | 切换后立即可用的DL波束，省去切换后再激活 |
| **UL TCI state ID** | 6 bit | `ltm-UL-TCI-StateToAddModList`中；仅`separate`模式出现 | 切换后立即可用的UL波束 |
| **C** | 1 bit | 1=携带CFRA资源字段集 | 是否提供无竞争随机接入资源 |
| **S/U** | 1 bit | 1=SUL，0=NUL | RACH用哪个上行载波 |
| **Random Access Preamble index** | 6 bit | CFRA专用前导码（不可为0） | 无竞争接入的前导码 |
| **SS/PBCH index** | 6 bit | 用于确定RO的SSB | 把前导映射到具体RACH时机 |
| **PRACH Mask index** | 4 bit | RO子集 | 进一步约束RO |
| **RO** | 1 bit | 第一/第二类PRACH occasions | 选择RO类型 |
| **Repetition number** | 2 bit | Msg1重复次数（0/2/4/8） | 覆盖增强，重复传输Msg1 |
| **S** | 1 bit | 1=携带SR Config ID | RACH-less期间是否有SRB1的SR |
| **SR Configuration ID** | 3 bit | `ltm-SchedulingRequestConfig`中的schedulingRequestId | RACH-less时SRB1（含RRC完成消息）如何请求调度 |

**几条关键设计逻辑**值得工程师特别注意：

- **TA字段（12 bit）是RACH-less与RACH-based的分水岭**。当值为`FFF`时，UE知道当前没有有效时间对齐，必须用MAC CE中携带的CFRA资源做无竞争随机接入；当值非`FFF`时，UE直接套用该TA并跳过整个RACH过程（含T_RA、T_RAR），中断时间骤降。
- **TCI state在MAC CE中直接激活**，意味着UE切换到目标小区后波束已就绪，无需再发一条TCI激活MAC CE，省去一个往返。
- **NOTE 2（§6.1.3.75）**：若UE收到的Target Configuration ID与任何`ltm-CandidateId−1`都不匹配，则§5.18.35流程不适用——这是防止配置失步的安全阀，抓包时若出现"收到MAC CE却不切换"，应首先怀疑候选配置已被释放或ID不匹配。
- **NOTE（§5.18.35）**：UE应**尽快**（even before HARQ确认）向上层指示LTM触发——即不等这条MAC CE的HARQ-ACK就启动切换，这是极致压缩中断的细节。

## 六、完整信令时序图

下图完整呈现一次RACH-less LTM切换的全链路（结合TS 38.300 Annex G的时延建模）：

```mermaid
sequenceDiagram
    participant UE
    participant SN as Serving gNB
    participant CN as Candidate gNB/Cell
    Note over UE,CN: 阶段1：RRC准备（提前，T_RRC）
    SN->>UE: RRCReconfiguration<br/>(ltm-Config + 多个LTM-Candidate)
    UE->>SN: RRCReconfigurationComplete
    Note over UE,CN: 阶段2：L1测量+早期同步（持续）
    SN->>CN: 请求激活候选小区CSI-RS
    UE->>UE: 对候选小区DL早同步(Lock SSB)
    UE->>SN: L1 Measurement Report MAC CE<br/>(候选RSRP/RSRQ/SINR)
    SN->>UE: LTM Candidate TA Command MAC CE(可选)
    Note over UE,CN: 阶段3：MAC CE扳机触发切换（T_MAC）
    SN->>UE: LTM Cell Switch Command MAC CE<br/>(Target Config ID=2, TA=有效, TCI state)
    Note over UE: 收到即触发,不等HARQ-ACK
    UE->>UE: 套用候选配置(T_RRC-target≈0)<br/>MAC reset / RLC re-establish<br/>TA已就绪→RACH-less
    UE->>CN: (T_DL-sync≈0, 早同步)<br/>直接首传 PUSCH/PUCCH(T_first-data)
    UE->>SN: RRCReconfigurationComplete(SRB1, 经SR)
    Note over UE,CN: 中断时间 = T_MAC + T_RRC-target + T_first-data
```

## 七、RACH-less vs RACH-based：中断时间的两条路径

LTM的执行根据TA是否可用分为两条路径，TS 38.300 Annex G用T_RRC、T_MAC、T_RRC-target、T_DL-sync、T_RA、T_RAR、T_first-data七个分量建模整体时延：

```text
flowchart TB
    subgraph RACH-less[路径A: RACH-less LTM]
        A1[T_MAC 处理切换MAC CE] --> A2[T_RRC-target 套用预存配置]
        A2 --> A3[T_first-data 目标小区首传]
        A3 --> A4[中断≈亚ms~数ms<br/>T_DL-sync≈0(早同步)<br/>无T_RA/T_RAR]
    end
    subgraph RACH-based[路径B: RACH-based LTM]
        B1[T_MAC] --> B2[T_RRC-target]
        B2 --> B3[T_DL-sync]
        B3 --> B4[T_RA 发前导]
        B4 --> B5[T_RAR 收响应]
        B5 --> B6[T_first-data]
        B6 --> B7[中断≈数ms~十余ms]
    end
    style A4 fill:#c8e6c9
    style B7 fill:#ffe0b2
```

**TS 38.300 Annex G给出的中断时间定义**："LTM的移动性中断时间，是从UE收到小区切换命令，到UE在目标小区指示波束上完成首次DL/UL收发的时间。" 对比传统L3切换，LTM通过**早同步消除T_DL-sync、RACH-less消除T_RA+T_RAR、预配置使T_RRC-target趋近于零**，把中断从数十ms压到亚ms级。具体的UE中断时间性能要求定义在**TS 38.133 §6.3**（RRM需求），按频段、子载波间隔、是否RACH-less给出不同门限。

§5.18.35的执行伪逻辑清晰展示了RACH-less判定（关键三条）：

> 1> 收到(Enhanced) LTM Cell Switch MAC CE →
> 2> 向上层指示"LTM触发" + Target Configuration ID →
> 2> 若执行MAC reset →
> 3> **若TA≠FFF**：处理TA，标记"RACH-less ongoing"，指示跳过RACH；
> 3> **否则若配置了UE-based TA测量且已测得**：用测得TA，RACH-less ongoing；
> 3> 若携带SR Config ID：将其作为RACH-less期间SRB1的SR配置；
> 3> 向下层指示TCI state信息。

注意第二条"UE-based TA测量"路径——这是Rel-18引入的**UE自主TA测量**能力（TS 38.331配置），即使gNB没提前下发TA，UE只要自己测准了也能RACH-less，进一步提升了RACH-less命中率。

## 八、增强LTM与安全上下文（Rel-19）

Rel-19引入了**Enhanced LTM Cell Switch Command MAC CE（§6.1.3.75a）**，用于处理切换中**安全上下文变化**的场景。判定规则（§5.18.35）：当目标候选的`ltm-NoSecurityChangeID`≠已存储的`ltm-ServingCellNoSecurityChangeID`时，使用增强MAC CE（额外携带NCC——next hop chaining count，用于密钥推演）；否则用普通MAC CE。

这意味着LTM已能支持**安全密钥变化的小区切换**，不再局限于"无安全变化"的简单场景。配合Rel-19的**Conditional LTM（§5.36）**——允许UE在满足条件时自主执行LTM切换、**inter-CU LTM**（跨中心单元，打破R18仅intra-CU的限制）以及**事件触发L1测量（§5.35）**，LTM在R19走向全面成熟，逐步逼近甚至替代部分L3切换场景。

## 九、抓包识别与故障排查

**如何用抓包识别LTM流程**（Wireshark/tshark解析NR MAC）：

- **准备阶段**：在`RRCReconfiguration`中查找`ltm-Config`、`ltm-Candidate` IE；若配置了候选小区但从未触发，说明UE能力或测量未满足；
- **L1测量上报**：MAC层查找LCID/eLCID对应"L1 Measurement Report MAC CE"，周期性出现多个候选测量值；
- **切换扳机**：定位"LTM Cell Switch Command MAC CE"，重点核对三个字段——Target Configuration ID是否在已配置候选范围内、TA字段是否为`FFF`（决定是否RACH-less）、TCI state ID；
- **RACH-less判定**：若MAC CE中TA≠`FFF`且后续无PRACH前导/Msg2，则为RACH-less成功；若出现前导却仍配了TA字段，需排查gNB/gNB间TA同步问题；
- **切换完成**：SRB1上的`RRCReconfigurationComplete`应在切换后短期出现。

**常见故障点与排错思路**：

| 现象 | 可能根因 | 排查方向 |
|------|------|------|
| 收到MAC CE却不切换 | Target Configuration ID无匹配候选（NOTE 2触发） | 核对候选是否被释放、ltm-CandidateId映射 |
| 应RACH-less却走了RACH | TA字段为FFF；或UE-based TA测量未配置/失败 | 检查Candidate TA MAC CE是否提前下发、UE能力 |
| 切换后波束异常 | TCI state ID配置错误或候选TCI列表缺失 | 核对ltm-DL/UL-TCI-State列表与MAC CE字段 |
| 候选测量值为空 | 候选小区CSI-RS未激活 | 检查§6.1.3.12a Candidate Cell CSI-RS激活MAC CE |
| 切换后安全失败 | 安全上下文变化但用了普通MAC CE | 确认ltm-NoSecurityChangeID逻辑、应触发Enhanced MAC CE |
## 常见问题

**Q1：LTM和CHO的本质区别是什么？**
A：CHO是L3（RRC）触发，UE自行评估执行条件后用预配置切换，决策在UE、命令承载仍是RRC概念；LTM是L1/L2（MAC CE）触发，决策在gNB（基于L1测量报告），命令是MAC CE、可RACH-less。LTM中断更短、更适合密集小小区频繁切换；CHO更自主、适合覆盖边缘。两者预配置机制相似但执行层完全不同。

**Q2：RACH-less LTM如何保证UE上行时间对齐？**
A：三条途径：(1) gNB通过LTM Candidate TA Command MAC CE提前下发候选小区TA，切换MAC CE中TA字段填该值；(2) UE配置UE-based TA测量，自主测准；(3) 任一有效则UE跳过RACH直接首传。若都不可用，TA字段填FFF，UE用MAC CE自带的CFRA资源做无竞争接入。

**Q3：为什么要有Enhanced LTM Cell Switch MAC CE？**
A：普通LTM MAC CE假设切换不改变安全上下文（密钥不变）。当目标候选的安全上下文需变化（ltm-NoSecurityChangeID不同）时，必须用Enhanced MAC CE携带NCC值供UE推演新密钥（TS 33.501密钥层级），这是Rel-19为扩大LTM适用范围（含安全变化场景）引入的。

**Q4：LTM为什么不直接用RRC命令而要用MAC CE？**
A：RRC消息处理时延（T_RRC，TS 38.331 §12规定数十ms级）远高于MAC CE（T_MAC，符号级）。LTM的目标是亚ms~数ms中断，必须绕开RRC处理时延。预配置已把RRC该做的事提前做完，切换瞬间只需MAC CE这一条L2"轻量扳机"。

**Q5：现网部署LTM的主要限制是什么？**
A：(1) UE需支持LTM能力（可选特性）；(2) Rel-18主要支持intra-CU，inter-CU需R19增强；(3) RACH-less依赖TA预下发/UE测量，命中率影响实际性能；(4) 频繁预配置带来信令开销。因此初期多在URLLC、工业专网、毫米波密集组网等高价值场景优先部署。

## 参考来源

1. [3GPP TS 38.321 §6.1.3.75 — LTM Cell Switch Command MAC CE](https://itecspec.com/3gpp/38.321/s/6.1.3.75) — MAC CE字段级定义（Target Config ID、TA、TCI、CFRA资源等）
2. [3GPP TS 38.321 §5.18.35 — (Enhanced) LTM Cell Switch Command](https://itecspec.com/3gpp/38.321/s/5.18.35) — MAC层执行流程与RACH-less判定逻辑
3. [3GPP TS 38.300 Annex G — Components of Mobility Latency](https://itecspec.com/3gpp/38.300/s/annex-g) — LTM中断时间T_RRC/T_MAC/T_DL-sync等建模
4. [Ericsson Technology Review — Reducing handover interruption with L1/L2 Triggered Mobility](https://www.ericsson.com/en/reports-and-papers/ericsson-technology-review/articles/reducing-handover-interruption-l1l2-triggered-mobility) — LTM设计动机与性能分析
5. [Ericsson Blog — 5G Advanced handover: L1/L2 Triggered mobility](https://www.ericsson.com/en/blog/2024/8/5g-advanced-handover-triggered-mobility) — 5G-Advanced切换增强解读
6. [TechPlayon — An Introduction to Lower-layer Triggered Mobility (LTM)](https://www.techplayon.com/an-introduction-to-lower-layer-triggered-mobility-ltm/) — LTM流程步骤与L1测量解读

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