人工智能和机器学习在未来通信中的总体框架
Model ID主题是AI/ML空口应解决的重要问题之一，就Model ID达成了以下协议：
Model模型由Model ID标识。
当网络需要了解UE AI/ML模型时，至少对于某些AI/ML操作，基于AI/ML模式具有相关信息和模型功能的Model ID
Model ID可用于识别LCM中使用的AI/ML模型，包括模型交付。
Model ID可以用于在模型选择/激活/停用/切换期间识别一个或多个模型。
基于上述协议，迄今为止识别的Model ID使用用例包括模型选择/激活/停用/切换/回退/交付，未来可能会添加其他典型用例。
Model ID的定义应该足够通用，不仅涵盖由PHY选定典型用例，而且还需要考虑未来的其他用途。针对空口的AI/ML SID的目标之一是找出B5G或6G AI主题的研究方法，除此之外，如何定义Model ID甚至对于6G AI也是非常重要和必要的。
所以，很多公司认为至少可以进一步考虑以下类型的Model ID定义方向：
Global unique model ID：一个Model ID以静态方式分配给一个模型算法，即每个Model ID的含义在规范中预定义，并且Model ID是全局唯一的，这意味着同一通信系统中的所有UE都对相同的全局唯一Model ID的含义具有相同的理解，无论UE已注册哪个运营商；
Operator unique model ID：一个Model ID以半静态方式分配给一个模型算法，即每个Model ID的含义由运营商通过实现定义，并且一旦定义，Model ID是运营商唯一的，这意味着无论UE连接到哪个小区，特定运营商唯一Model ID的含义在同一运营商内都是相同的；
Temporary model ID：一个Model ID被动态地分配给模型算法，并且临时Model ID是UE内部唯一的，如BWP ID的概念，一旦特定UE的服务小区已经改变，就可以为同一模型算法向UE分配不同的Model ID。换句话说，临时Model ID对于每个小区UE对是唯一的。
总之，下表1给出了每个Model ID定义类型的优缺点：
OPPO公司就认为，至少应该支持global unique modelID定义，因为该定义类型简单且经得起未来考验。
对于operator unique model ID定义，UE可能需要通过多运营商协议经由实现来获得每个运营商唯一的Model ID的含义，或者从网络动态地获得每个运营方唯一Model ID的意义。当引入更大的Model ID时，这种类型的Model ID定义也是未来的证明。
对于临时Model ID定义，UE可能需要从网络动态地获得每个临时Model ID的含义，并且应用的范围通常是每个小区，这对于将来跨小区管理大规模的AI模型是不友好的。
但另一方面，如果人们认为公开全球唯一Model ID可能会导致某些隐私问题，则运营商唯一Model ID和临时Model ID可能仍然有用。此外，运营商唯一Model ID和临时Model ID可以定义为比全局唯一Model ID短，这从开销角度来看是有益的。运营商唯一Model ID和临时Model ID可以作为全局唯一Model ID的补充。
对于每个Model ID类型的详细定义，可以考虑以下两个方向：
方向1：一个Model ID仅包含一个ID字段
优点：定义很简单。
缺点：无论何时提供Model ID信息，都应包含完整的Model ID，这对减少开销不友好。
方向2：一个Model ID至少包含两个ID字段
优点：灵活的模型管理是可能的，因为部分Model ID可以用于某些场景。
缺点：需要更多的规范工作来定义模型ID的每个子字段的含义。
第一个问题是关于在模型传输/交付过程中将传输什么类型的信息，最初的考虑是，至少在模型传输和交付过程中传输包括模型结构和模型权重参数的模型算法数据。但是模型算法数据是不够的，因为UE仍然不知道该模型算法数据用于什么功能以及模型使用所必需的其他基本模型描述参数。
如果UE想要在传输之后使用AI模型，那么至少Model ID和对应的模型算法数据之间的关联关系应该由UE知道/维护，但是如何获取Model ID和相应的模型算法之间的关联关系取决于选择了哪种模型传输/交付解决方案。
如果从OTT服务器或OAM获取模型算法数据，则如果任何模型LCM过程不涉及网络动作，则不需要Model ID信息或通过UE实现维护Model ID信息以用于LCM目的。但如果至少一个型号LCM程序涉及网络部署，则Model ID信息通过规格默认值确定或由网络分配。
如果模型算法数据是从CP解决方案获取的，为了区分不同的AI模型算法数据，可以通过CP信令将Model ID与相应的模型算法数据一起发送。
如果从UP解决方案获取模型算法数据，可以考虑两种方法来通知UE模型ID信息：
方法1：通过UP信令（例如通过DRB）将Model ID与对应的模型算法数据一起发送；
方法2：通过UP信令（例如通过DRB）传输模型算法数据，而通过CP信令（例如在添加/修改DRB资源时通过SRB配置）给出相应的Model ID，并且UE将建立通过SRB所配置的Model ID与通过相关联的DRB传输的模型算法数据之间的关联关系。
所以，如果传输/交付的模型需要网络控制的模型管理过程，则在模型传输/交付之后，UE至少应该知道/维护Model ID和对应的模型算法数据之间的关联关系。
除了Model ID信息和模型算法数据之外，如果UE想要在模型传输/交付之后使用AI模型，则可能仍然需要其他模型描述参数。例如，模型输入/输出信息、模型版本信息、模型格式信息、模型精度信息等。这些模型元信息可能对模型使用至关重要，但需要注意的一点是，Model ID定义和上述其他模型描述参数中包含的参数之间可能存在一些信息重叠，因此，其他模型描述参数应该提供哪些额外信息可能取决于Model ID定义不能提供哪些信息，如果适用，可以在规范工作阶段讨论细节。
关于是否引入基于3GPP信令的模型传输/交付的要求可能取决于PHY的决定，但对模型传输/递送的主要影响在层2的范围内。
列出了以下有关模型转移/交付的解决方案：
解决方案1a：gNB可以通过RRC信令向UE传输/交付AI/ML模型。
解决方案2a:CN（LMF除外）可以通过NAS信令向UE传输/交付AI/ML模型。
解决方案3a:LMF可以通过LPP信令将AI/ML模型传输/交付给UE。
解决方案1b：gNB可以通过UP数据向UE传输/交付AI/ML模型。
解决方案2b：CN（LMF除外）可以通过UP数据向UE传输/交付AI/ML模型。
解决方案3b：LMF可以通过UP数据向UE传输/交付AI/ML模型。
解决方案4：服务器可以向UE传输/交付AI/ML模型（对3GPP透明）。
从层2的角度来看，上述所有解决方案可能都是可行的，但有不同的优缺点。
模型更新是模型转移/交付之外的另一个问题。从下行中的模型更新开始。模型更新可能有两种类型：
型号更新类型1：更新完整型号相关数据；
模型更新类型2：部分模型相关数据已更新。
对于模型更新类型1，无需区分模型更新和模型传输/交付，因为规格影响几乎相同。但是对于模型更新类型2，可以考虑增量信令进行优化。通常，AI/ML模型相关数据至少包括模型结构参数和模型权重参数，如果仅更改模型权重参数（即未更改模型结构参数），则模型更新类型2可用于模型更新；否则，将使用模型更新类型1，因此将使用哪个模型更新类型取决于用例。这两种类型都可以进一步考虑。
如果增量信令用于模型更新，则有两个方向：
方向1：通过基于3GPP信令的CP解决方案（即NAS/RRC信令）执行模型更新；
方向2：通过基于3GPP信令的UP解决方案（即类似DRB的解决方案）执行模型更新。
对于方向1，当增量信令用于模型更新时，需要指定3GPP定义的模型格式。方向1的优点：易于更新AI/ML模型的一部分。
方向1的缺点：需要定义基于3GPP信令的模型格式，并且模型细节可能会在空口暴露。
对于方向2，可以通过将整个AI/ML模型划分为若干部分来实现增量模型更新，并且每个部分与sub-block ID相关联，子sub-block ID和关联的AI/ML模块部分之间的映射关系应该由同一级别的UE和网络知道。该模型更新方法可以使用sub-block ID更新AI/ML模型的任何部分。
方向2的优点：增量模型更新可以在不暴露AI/ML模型细节的情况下实现，因为与sub-block ID相关联的AI/ML的每个部分都可以被视为一个容器。
方向2的缺点：需要为AI/ML模型引入sub-block ID概念。
基于以上，可以使用增量信令来更新AI/ML模型的一部分，如果采用不同的方法，规范的影响是不同的。
AI/ML模型可以被认为是一种新的服务类型，但在当前阶段，非AI/ML方法至少可以用作备份。如果AI/ML模型在未来广泛应用于通信系统，将遇到两种不同的解决方案应用于同一系统的情况。从UE供应商的角度来看，引入AI/ML模型交付/传输功能可能会在某些情况下改善用户体验，但从运营商的角度来看引入AI/MM模型交付/传递功能将显著增加管理工作。如果所有类型的UE都可以通过模型传输/交付程序自由地获得AI/ML模型，则运营商可能会对在空口中引入模型传输/传输功能失去兴趣。在该AI/ML SID中，还应考虑如何避免未经授权的UE通过模型传输/传递过程获得AI/ML模型，即使该UE正常注册到运营商网络。这个主题可能涉及CN工作，但仍值得讨论。
最后一部分是关于AI/ML能力报告，许多公司认为这一主题应该像其他SID一样在规范工作中讨论，也可以讨论规范工作中的细节，但也认为即使在SID期间，也可以先讨论一些高级框架来进行AI/ML能力报告。与其他UE能力（一旦报告通常是静态的）不同，AI/ML相关能力可以动态改变，例如，UE剩余存储和UE剩余计算资源，此动态UE能力概念在NR SID TR中提出，但在NR SID结束时被丢弃。认为这个AI/ML SID是一个重新考虑这个机制的好机会，可以在SID中同意这个高级要求。
另一个问题是关于AI/ML能力定义的框架，由于AI/ML部署与LCM中包含的子功能高度关联，因此总体AI/ML功能不足以反映UE可以部署的实际AI/ML相关功能。例如，如果UE仅报告支持的model ID，则网络将不知道UE是否支持模型训练，因此需要特定于特征的AI/ML能力。此外，如果UE能够为某些模型进行模型训练，则也不能假设UE能够为任何类型的AI/ML模型进行模型培训，因为不同模型之间的模型训练复杂度不同，因此应根据model ID报告特征特定AI/ML能力。
