3GPP RAN TSG#102闭幕及R19启动项目-11(On AI/ML for Air Interface））1/2

On AI/ML for Air Interface bjectives-主体提案编号：RP-232747

一、文档摘要（AI生成）

这是我为您生成的摘要：

本文主题：本网页是一个关于 AI/ML 在 5G 物理层的技术文档，由 Ericsson 提交给 3GPP TSG-RAN 第 102 次会议。

本文目的：本网页的目的是讨论和决定在 Rel.19 中开展 AI/ML 的规范工作的范围和组织方式，以及提出一些具体的建议和观察。

网页内容：本网页分为三个部分，分别是：

引言和范围：介绍了本文的背景和目标，以及在 Rel.18 研究项目中发现的一些结论和建议。

讨论：针对不同的 AI/ML 子用例，分析了它们的性能、复杂度、可行性、规范影响和开放问题，以及是否适合进行规范工作。根据分析，提出了一些选择和排除某些子用例的建议。

结论：总结了本文的主要观察和建议，包括：

建议 1：考虑以下内容作为 Rel.19 AI/ML 规范工作的范围：

波束管理：支持单侧模型的下行波束预测和定位用例。

CSI 预测：支持 UE 侧模型的 CSI 预测用例。

LCM 组件：支持这些子用例所需的 LCM 组件，如数据收集、性能监测和模型推理等。

需求和测试：支持这些子用例的需求和测试用例，包括 UE 测量精度和 RAN4 测试用例等。

建议 2：在 Rel-19 中不进行模型传输的规范工作。只考虑 UE 侧或 OTT 站点作为 UE 侧模型的可行训练位置。

建议 3：在 Rel-19 中不进行基于模型 ID 的 LCM 的规范工作。

建议 4：为了限制 Rel-19 定位用例的规范工作范围，不考虑 AI/ML Case 2b 和 3b 的直接定位用例。

建议 5：为了限制 Rel-19 定位用例的规范工作范围，建议 Rel-19 定位用例的范围限制为 Case 1 和 Case 3a。

建议 6：在 Rel.19 中不进行基于 AI/ML 的 CSI 压缩的规范工作。

建议 7：如果继续研究双侧模型，那么应该考虑在研究中使用标准化的推理编码器的解决方案。

建议 8：开始 Rel.19 UE 侧 CSI 预测的规范工作。

建议 9：为 Rel.19 物理层 AI/ML，在 RAN1 中分配 3 TU 用于单侧 AI/ML 模型的 WI，以及 1 TU 用于 CSI 压缩的双侧模型的单独 SI，以及相应的 RAN2 和 RAN4 中的 TU。

建议 10：根据用例的数量，在 RAN4 中分配最多 3 TU。

建议 11：考虑在 RAN4 雅典会议中分配 0.5 TU 继续讨论 AI/ML。

二、引言和范围

为了总结本次贡献中的讨论，并基于研究项目的结果和我们的内部分析，我们建议将 Rel.19 物理层 AI/ML 工作项目设定以下目标：
提案 1: 考虑将以下内容纳入 Rel.19 AI/ML 规范化工作范围：
指定支持单边模型用于：
信令/机制，用于辅助 UE 侧数据收集、性能监控和模型推理 [RAN1, RAN2]
UE 向 gNB 报告推理输出相关信息的程序 [RAN1]
基于 UE 的定位，采用 UE 侧模型，直接 AI/ML 或 AI/ML 辅助定位（Case 1）
NG-RAN 节点辅助定位，采用 gNB 侧模型，AI/ML 辅助定位（Case 3a）
信令/机制，用于辅助 UE 侧数据收集、性能监控和模型推理 [RAN1, RAN2]
信令/机制，用于辅助数据收集、性能监控和模型推理 [RAN1, RAN2, RAN3]
网络侧模型：
UE 侧模型：
信令/机制，用于辅助数据收集、性能监控和模型推理 [RAN1, RAN2]
信令/机制，用于辅助 UE 侧数据收集、性能监控和模型推理 [RAN1, RAN2]
UE 向 gNB 报告推理输出相关信息的程序 [RAN1]
波束管理：下行空间和时间下行传输预测（BM-Case 1 和 2），采用：
定位用例，包含：

CSI 预测，采用 UE 侧模型
指定对这些选定的子用例所需的/推荐的生命周期管理 (LCM) 组件的支持 [RAN1, RAN2, RAN3（用于定位）]
不考虑标准化模型转移。
不考虑基于模型 ID 的 LCM。
指定对这些选定的子用例的要求，包括 UE 测量精度和测试用例的支持 [RAN4]
在第 2 节中，我们将讨论提出 Rel.19 范围的理由。在第 3 节中，我们将讨论 Rel.19 物理层 AI/ML 的组织结构，因为可能需要进一步研究和理解某些组件，然后再进入规范化阶段。

三. 讨论

3.1 从 Rel.19 范围中排除的组件

在 Rel.18 SI 阶段研究的某些主题中，RAN1/RAN2 由于技术问题和必要性，无法为 WI 阶段提出任何具体建议。以下将讨论模型转移、UE 侧模型训练以及基于模型 ID 的生命周期管理（LCM）的主题。

3.1.1 Model Transfer

模型传输的话题与讨论在哪个实体执行UE侧模型训练紧密相关，即UE芯片组中AI/ML模型的训练位置。
有关将模型交付/传输到UE的不同选项已在（y,z1,z2,…,z5）中进行了讨论，并在RAN1/2/4中定义。然而，尚未就模型传输的必要性或可行性达成一致。
从RAN1的角度看，关于模型传输的必要性，特定于场景/配置（包括特定于站点的配置/信道条件）的模型可能在一些研究的用例中提供性能优势。然而，在RAN1中也承认模型传输不是唯一可行的方法。在设备上进行微调可能是模型传输的替代方案。此外，在一些用例中，单一模型可能能够很好地概括，而无需特定于场景的模型。此外，RAN1的共识仍然对其可行性提出了质疑。
以上RAN1的担忧在整个SI阶段也在RAN2中有所体现。特别是在RAN2#124会议中，RAN2指出在NW侧（gNB、LMF、CN、OAM）进行UE侧模型训练的情况尚未得到研究。与RAN1的讨论类似，对于由于需要存储大量数据/信息而导致的复杂性以及可行性的担忧也在RAN2中提出，即如何确保经过训练的数据集适用于在很大程度上取决于UE特定属性/设计的较低层推理。
鉴于上述情况，模型传输案例z2、z4和z5的可行性和必要性尚不清楚。在研究项目期间，不能为尚未进行深入研究且可行性未经评估的方面提供规范性工作的动机。
在RAN4中，尚未讨论模型传输。目前的基本原则是任何测试只能应用于设备/节点所有者完全控制的硬件/软件。对于动态模型传输，将转换为设备上的设备实现可能会影响性能。如果在一致性测试期间进行传输，那么对于性能测试失败，责任归属变得不清晰。在UE部署到实地后，尚不清楚传输到UE的模型是否能够满足性能要求，甚至是否能够满足法规要求。
观察1 研究项目既没有提供规范化模型传输的强烈动机，也没有得出关于模型传输可行性的结论。
因此，建议仅将UE侧或中立站点（例如OTT服务器）视为UE侧模型的可行训练位置。
提案2 在Rel-19中不进行模型传输的规范性工作。规范性工作中仅将UE侧或OTT站点视为UE侧模型的可行训练位置。
总结说明：
模型转移与 UE 侧模型训练实体紧密相关，即 UE 芯片组中 AI/ML 模型的训练位置。
[1] 中定义并讨论了向 UE 传递/转移模型的不同选项 (y,z1,z2,…,z5)，RAN1/2/4 也进行了讨论。然而，没有任何工作组就模型转移的必要性或可行性达成结论。
RAN1 视角：
场景/配置特定模型（包括特定位置配置/信道条件）在一些用例中可能带来性能提升，但并非唯一选择。
设备上的微调可以替代模型转移，且某些用例单个通用模型即可胜任。
RAN1 尚未完全肯定模型转移的可行性。
RAN2 视角：
网络侧（gNB、LMF、CN、OAM）训练 UE 侧模型尚未研究。
存储大量数据/信息以及模型适配 UE 特性的复杂性引发担忧。
基于上述，z2、z4 和 z5 的模型转移的可行性和规范化需求不明确。
RAN4 视角：
目前测试仅适用于设备/节点所有者完全控制的硬件/软件。
动态模型转移可能影响设备性能，导致责任划分模糊。
已部署的 UE 接收转移模型后是否满足性能/监管要求尚不明确。
观察 1：研究项目既没有提供强有力的理由对模型转移进行标准化，也没有得出模型转移的可行性结论。
提案 2：Rel-19 不进行模型转移的规范化工作。规范化工作中，只考虑 UE 侧或中立站点（例如 OTT 服务器）作为 UE 侧模型的可行训练位置。

3.1.2 基于模型 ID 的 LCM

在 RAN1 的讨论和协议中，基于模型的 LCM 的潜在好处尚未在任何协议中得到体现。然而，协议和观察已经概述了模型标识可以在以下场景中使用：
型号传输从 NW 到 UE 时进行型号标识
可以基于型号标识建立配对信息（双边型号）
模型标识实现 NW 侧和 UE 侧之间 NW 侧附加条件的对齐
正如前面部分所讨论的，RAN1 尚未得出关于模型传输的必要性或可行性的结论。也没有就支持双边 CSI 使用例达成共识。因此，除非同意将其作为 Rel-19 规范工作的一部分，否则这两个场景并不能证明需要指定基于模型 ID 的 LCM。
对于第三个要点，我们首先观察到，在使用案例中，对于附加条件（在 [1] 中定义）可以包含什么，没有任何协议或观察。据我们理解，如果识别到一个附加条件，则假设一个 UE 在标识模型时提供相关的元信息来处理附加条件。例如，元信息指示 NW 配置/场景，训练数据是为 UE 侧模型收集的。如何分类、定义和指定 NW 配置/场景是一个非常具有挑战性和复杂的任务。它还需要通过监控方法来补充，确保模型在暴露于其他未指定的条件（例如，UE、NW、场景相关）时仍然适用。我们的观点是，监控（由 UE/NW）作为确保训练和推理之间一致性的手段应该被作为起点，可以通过基于功能的方法来解决。

3.2 波束管理用例

RAN1 已经确认了 AI/ML 用于波束管理的优势，并且 DL Tx 波束预测规范化的理由 来自单边 AI/ML 模型相对简单的 LCM 和中间 KPI 结果，这些结果表明与基于 AI/ML 的波束管理相比，减少 UE 测量和 RS 冗余方面性能提升，无需进行全波束扫描。
基于 SI 期间进行的评估，RAN1 对 DL Tx 波束预测的可行性和推荐性做出了结论。
请注意，RAN1 没有任何关于支持 TX/RX 波束对预测的必要性结论。我们认为，TX/RX 波束对预测的可行性没有得到妥善解决。建议不将此子用例推荐用于规范化工作。
我们对支持 DL 波束预测（空间和时间）规范影响的高级评估：
RAN1/RAN2 规范影响:
对于 UE 侧模型推理，主要包括 UE 向 gNB 报告预测波束集以及相关置信信息的程序。
数据收集可能会对模型推理、训练和监控产生影响。例如，需要程序/信令来确保 UE 训练和推理操作之间的一致性，以及 UE 指示需要 RS 传输的程序。
对于 NW 侧模型，RAN1/RAN2 规范影响相对较小，主要包括从 UE (DL Tx 波束测量) 收集相关数据的办法，以及如何在推理操作期间用非测量（预测）波束配置 UE。
RAN2 规范影响:
RAN2 应该调查可能的信号强度数据收集方式，以及 UEs 如何发出运行波束预测模型的能力信号（UE 能力和适用条件信令）。
RAN4 规范影响:
RAN4 需要解决 L1-RSRP 作为模型输入的测量精度问题。与完美测量相比，Rel-18 SI 中的评估表明，考虑现有测量要求时的性能会显着下降。其他主题可能包括 RAN4 要求中可以捕获到多大程度的通用性，以及一致性测试可以在多大程度上涵盖它，以及如何确保可靠的 UE 报告预测置信度和可靠的性能监控 KPI 报告。RAN4 规范也将受到影响，需要指定与模型训练和测量报告相关的核心要求。