38.300-J30
流程描述
⻅38.423
字段描述
⻅38.423
- 源侧主动发起更新，携带 LTM Updates to Candidate Node Information / LTM Updates to Candidate Cell Information List。
- 目标侧发起更新，携带 LTM Updates to Source Node Information List。
TS 38.423 j 系列（Rel‑19 较新草案，如 j30 等）中，除了早期版本就存在的 "LTM Updates to Candidate Node Information" 和 "LTM Updates to Candidate Cell Information List" 之外，确实还定义了 "LTM Updates to Source Node Information List" 。这个新增 IE 与 Rel‑19 引入的"候选侧发起 LTM 配置更新"能力相配套，专门用于承载候选 gNB → 源 gNB 方向的更新内容。
下面基于三个 IE 并存的事实，说明它们的命名含义与分工。
"to" 的统一含义：信息流向，而不是角色归属
XnAP 中所有以 "Updates to X" 命名的 LTM IE 遵循同一条规则："to" 表示这条更新信息"被发往"节点 X，X 是接收方 。 IE 名称并不描述信息内容"属于"哪个节点------内容始终是候选小区的 LTM 相关配置（分节点级和小区级）------只是告诉你"由谁来应用这个更新"。
按这个规则，三个 IE 的方向和作用就非常清晰：
| IE 名称 | 方向 | 更新对象 |
|---|---|---|
| LTM Updates to Candidate Node Information | 源 gNB → 候选 gNB | 节点级 ：源侧把 LTM 参考配置、LTM 配置 ID 映射列表、公共 CSI 资源配置、LTM 安全信息等"节点公共配置"推给候选节点 |
| LTM Updates to Candidate Cell Information List | 源 gNB → 候选 gNB | 小区级 ：源侧把每个候选小区的 NR CGI、早期同步信息、CFRA 资源、UE Based TA 配置、AS 安全信息、数据转发信息等推给候选节点 |
| LTM Updates to Source Node Information List | 候选 gNB → 源 gNB | 小区级（反向） ：候选 gNB 把属于它的候选小区的 LTM 配置变更推回源节点 ，源节点据此刷新其维护的候选集 |
为什么要新增 "to Source Node" 这个 IE
这个新增 IE 对应 38.300 V19.2.0 中通过 CR 1166（Tdoc R2‑2604426）引入的步骤 11c/11d 语义：
The candidate gNB may initiate an LTM CONFIGURATION UPDATE message to inform the source gNB about the update of LTM configurations for one or more candidate cells belonging to the candidate gNB.
在此之前，LTM CONFIGURATION UPDATE 只有源 → 候选一个方向，因此只需要 "to Candidate Node" / "to Candidate Cell" 两个 IE。Rel‑19 引入候选侧发起能力后，消息本身可能出现相反方向，但 IE 命名规则希望保持一致------仍然是"看到 to X 就知道要更新 X 侧维护的信息"。为了不打破这一规则，新增了一条反向 IE，命名为 "to Source Node"，让接收方（源 gNB）在解析消息时能明确知道这些内容要应用到自己这边维护的候选集上。
三个 IE 的工程分工总结
把三个 IE 放在同一张表里看，它们的分工可以概括为两维：一维是"节点级 vs 小区级"（是否对所有候选小区共用），另一维是"源推送 vs 候选推送"（更新由谁发起）。
- 节点级 + 源推送 → LTM Updates to Candidate Node Information：适用于"对所有候选小区都一样的公共配置"，一次下发即可；
- 小区级 + 源推送 → LTM Updates to Candidate Cell Information List：适用于"每个候选小区各自的配置"，按小区逐条列出（SIZE 1...maxnoofLTMCells）；
- 小区级 + 候选推送 → LTM Updates to Source Node Information List：候选 gNB 因自身变化（节能、去激活候选小区、CFRA 资源调整等）而主动反向告知源 gNB，对应 38.300 中步骤 11c 的实际内容。
一句话理解
把 "to" 读作"更新要落到哪个节点本地"：
- to Candidate Node / to Candidate Cell 都表示"落到候选节点侧"，
- to Source Node 则表示"落回源节点侧"。
- IE 名称本身就完整表达了方向 + 作用对象两层信息，不需要再结合上下文判断。
场景分析
（1）源侧配置更新-站级（物理资源、承载变更）
- 源站发送：LTM CONFIGURATION UPDATE->LTM Updates to Candidate Node Information/ ltm-ReferenceConfiguration
- ⽬标站响应：ACK中携带⽤LTM Updates from Candidate Cell Information List
典型场景：LTM准备阶段源侧获取 **** CSI report configuration for early CSI acquisition。
（2）源侧配置更新-⼩区级（更新⽬标⼩区其他配置：传输地址、UE BASED TA 配置、安全
变更等）
- 源站发送：LTM CONFIGURATION UPDATE->LTM Updates to Candidate Cell Information List
- ⽬标站响应：ACK中携带LTM Updates from Candidate Cell Information List（⽬标站收后需要更新后的配置，如果涉及空⼝的重配就通过LTM CONFIGURATION UPDATE ACKNOWLEDGE->LTM Updates from Candidate Cell Information List->LTM Candidate Cell Information Item->LTM Candidate Configuration给源侧，然后源侧配置空⼝。 如果不涉及LTM Candidate Configuration，⽬标侧直接⽣效就可以）
** 典型场景：subsequent LTM场景****，服务⼩区变更，所以给⽬标⼩区更新相关配置**
（3）⽬标侧配置更新（物理资源、CSI资源变更等）
- ⽬标站发送：LTM CONFIGURATION UPDATE->LTM Updates to Source Node Information List
- 源站响应：ACK中不需要携带⽤LTM Updates from Candidate Cell Information List