Model ID主題是AI/ML空口應解決的重要問題之一，就Model ID達成了以下協(xié)議：

• Model模型由Model ID標識。

• 當網(wǎng)絡需要了解UE AI/ML模型時，至少對于某些AI/ML操作，基于AI/ML模式具有相關(guān)信息和模型功能的Model ID

• Model ID可用于識別LCM中使用的AI/ML模型，包括模型交付。

• Model ID可以用于在模型選擇/激活/停用/切換期間識別一個或多個模型。

基于上述協(xié)議，迄今為止識別的Model ID使用用例包括模型選擇/激活/停用/切換/回退/交付，未來可能會添加其他典型用例。

Model ID的定義應該足夠通用，不僅涵蓋由PHY選定典型用例，而且還需要考慮未來的其他用途。針對空口的AI/ML SID的目標之一是找出B5G或6G AI主題的研究方法，除此之外，如何定義Model ID甚至對于6G AI也是非常重要和必要的。

所以，很多公司認為至少可以進一步考慮以下類型的Model ID定義方向：

Global unique model ID：一個Model ID以靜態(tài)方式分配給一個模型算法，即每個Model ID的含義在規(guī)范中預定義，并且Model ID是全局唯一的，這意味著同一通信系統(tǒng)中的所有UE都對相同的全局唯一Model ID的含義具有相同的理解，無論UE已注冊哪個運營商；

Operator unique model ID：一個Model ID以半靜態(tài)方式分配給一個模型算法，即每個Model ID的含義由運營商通過實現(xiàn)定義，并且一旦定義，Model ID是運營商唯一的，這意味著無論UE連接到哪個小區(qū)，特定運營商唯一Model ID的含義在同一運營商內(nèi)都是相同的；

Temporary model ID：一個Model ID被動態(tài)地分配給模型算法，并且臨時Model ID是UE內(nèi)部唯一的，如BWP ID的概念，一旦特定UE的服務小區(qū)已經(jīng)改變，就可以為同一模型算法向UE分配不同的Model ID。換句話說，臨時Model ID對于每個小區(qū)UE對是唯一的。

總之，下表1給出了每個Model ID定義類型的優(yōu)缺點：

OPPO公司就認為，至少應該支持global unique modelID定義，因為該定義類型簡單且經(jīng)得起未來考驗。

對于operator unique model ID定義，UE可能需要通過多運營商協(xié)議經(jīng)由實現(xiàn)來獲得每個運營商唯一的Model ID的含義，或者從網(wǎng)絡動態(tài)地獲得每個運營方唯一Model ID的意義。當引入更大的Model ID時，這種類型的Model ID定義也是未來的證明。

對于臨時Model ID定義，UE可能需要從網(wǎng)絡動態(tài)地獲得每個臨時Model ID的含義，并且應用的范圍通常是每個小區(qū)，這對于將來跨小區(qū)管理大規(guī)模的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字段

優(yōu)點：定義很簡單。

缺點：無論何時提供Model ID信息，都應包含完整的Model ID，這對減少開銷不友好。

方向2：一個Model ID至少包含兩個ID字段

優(yōu)點：靈活的模型管理是可能的，因為部分Model ID可以用于某些場景。

缺點：需要更多的規(guī)范工作來定義模型ID的每個子字段的含義。

第一個問題是關(guān)于在模型傳輸/交付過程中將傳輸什么類型的信息，最初的考慮是，至少在模型傳輸和交付過程中傳輸包括模型結(jié)構(gòu)和模型權(quán)重參數(shù)的模型算法數(shù)據(jù)。但是模型算法數(shù)據(jù)是不夠的，因為UE仍然不知道該模型算法數(shù)據(jù)用于什么功能以及模型使用所必需的其他基本模型描述參數(shù)。

如果UE想要在傳輸之后使用AI模型，那么至少Model ID和對應的模型算法數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系應該由UE知道/維護，但是如何獲取Model ID和相應的模型算法之間的關(guān)聯(lián)關(guān)系取決于選擇了哪種模型傳輸/交付解決方案。

如果從OTT服務器或OAM獲取模型算法數(shù)據(jù)，則如果任何模型LCM過程不涉及網(wǎng)絡動作，則不需要Model ID信息或通過UE實現(xiàn)維護Model ID信息以用于LCM目的。但如果至少一個型號LCM程序涉及網(wǎng)絡部署，則Model ID信息通過規(guī)格默認值確定或由網(wǎng)絡分配。

如果模型算法數(shù)據(jù)是從CP解決方案獲取的，為了區(qū)分不同的AI模型算法數(shù)據(jù)，可以通過CP信令將Model ID與相應的模型算法數(shù)據(jù)一起發(fā)送。

如果從UP解決方案獲取模型算法數(shù)據(jù)，可以考慮兩種方法來通知UE模型ID信息：

方法1：通過UP信令（例如通過DRB）將Model ID與對應的模型算法數(shù)據(jù)一起發(fā)送；

方法2：通過UP信令（例如通過DRB）傳輸模型算法數(shù)據(jù)，而通過CP信令（例如在添加/修改DRB資源時通過SRB配置）給出相應的Model ID，并且UE將建立通過SRB所配置的Model ID與通過相關(guān)聯(lián)的DRB傳輸?shù)哪Ｐ退惴〝?shù)據(jù)之間的關(guān)聯(lián)關(guān)系。

所以，如果傳輸/交付的模型需要網(wǎng)絡控制的模型管理過程，則在模型傳輸/交付之后，UE至少應該知道/維護Model ID和對應的模型算法數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系。

除了Model ID信息和模型算法數(shù)據(jù)之外，如果UE想要在模型傳輸/交付之后使用AI模型，則可能仍然需要其他模型描述參數(shù)。例如，模型輸入/輸出信息、模型版本信息、模型格式信息、模型精度信息等。這些模型元信息可能對模型使用至關(guān)重要，但需要注意的一點是，Model ID定義和上述其他模型描述參數(shù)中包含的參數(shù)之間可能存在一些信息重疊，因此，其他模型描述參數(shù)應該提供哪些額外信息可能取決于Model ID定義不能提供哪些信息，如果適用，可以在規(guī)范工作階段討論細節(jié)。

關(guān)于是否引入基于3GPP信令的模型傳輸/交付的要求可能取決于PHY的決定，但對模型傳輸/遞送的主要影響在層2的范圍內(nèi)。

列出了以下有關(guān)模型轉(zhuǎn)移/交付的解決方案：

解決方案1a：gNB可以通過RRC信令向UE傳輸/交付AI/ML模型。

解決方案2a:CN（LMF除外）可以通過NAS信令向UE傳輸/交付AI/ML模型。

解決方案3a:LMF可以通過LPP信令將AI/ML模型傳輸/交付給UE。

解決方案1b：gNB可以通過UP數(shù)據(jù)向UE傳輸/交付AI/ML模型。

解決方案2b：CN（LMF除外）可以通過UP數(shù)據(jù)向UE傳輸/交付AI/ML模型。

解決方案3b：LMF可以通過UP數(shù)據(jù)向UE傳輸/交付AI/ML模型。

解決方案4：服務器可以向UE傳輸/交付AI/ML模型（對3GPP透明）。

從層2的角度來看，上述所有解決方案可能都是可行的，但有不同的優(yōu)缺點。

模型更新是模型轉(zhuǎn)移/交付之外的另一個問題。從下行中的模型更新開始。模型更新可能有兩種類型：

• 型號更新類型1：更新完整型號相關(guān)數(shù)據(jù)；

• 模型更新類型2：部分模型相關(guān)數(shù)據(jù)已更新。

對于模型更新類型1，無需區(qū)分模型更新和模型傳輸/交付，因為規(guī)格影響幾乎相同。但是對于模型更新類型2，可以考慮增量信令進行優(yōu)化。通常，AI/ML模型相關(guān)數(shù)據(jù)至少包括模型結(jié)構(gòu)參數(shù)和模型權(quán)重參數(shù)，如果僅更改模型權(quán)重參數(shù)（即未更改模型結(jié)構(gòu)參數(shù)），則模型更新類型2可用于模型更新；否則，將使用模型更新類型1，因此將使用哪個模型更新類型取決于用例。這兩種類型都可以進一步考慮。

如果增量信令用于模型更新，則有兩個方向：

方向1：通過基于3GPP信令的CP解決方案（即NAS/RRC信令）執(zhí)行模型更新；

方向2：通過基于3GPP信令的UP解決方案（即類似DRB的解決方案）執(zhí)行模型更新。

對于方向1，當增量信令用于模型更新時，需要指定3GPP定義的模型格式。方向1的優(yōu)點：易于更新AI/ML模型的一部分。

方向1的缺點：需要定義基于3GPP信令的模型格式，并且模型細節(jié)可能會在空口暴露。

對于方向2，可以通過將整個AI/ML模型劃分為若干部分來實現(xiàn)增量模型更新，并且每個部分與sub-block?ID相關(guān)聯(lián)，子sub-block?ID和關(guān)聯(lián)的AI/ML模塊部分之間的映射關(guān)系應該由同一級別的UE和網(wǎng)絡知道。該模型更新方法可以使用sub-block?ID更新AI/ML模型的任何部分。

方向2的優(yōu)點：增量模型更新可以在不暴露AI/ML模型細節(jié)的情況下實現(xiàn)，因為與sub-block?ID相關(guān)聯(lián)的AI/ML的每個部分都可以被視為一個容器。

方向2的缺點：需要為AI/ML模型引入sub-block?ID概念。

基于以上，可以使用增量信令來更新AI/ML模型的一部分，如果采用不同的方法，規(guī)范的影響是不同的。

AI/ML模型可以被認為是一種新的服務類型，但在當前階段，非AI/ML方法至少可以用作備份。如果AI/ML模型在未來廣泛應用于通信系統(tǒng)，將遇到兩種不同的解決方案應用于同一系統(tǒng)的情況。從UE供應商的角度來看，引入AI/ML模型交付/傳輸功能可能會在某些情況下改善用戶體驗，但從運營商的角度來看引入AI/MM模型交付/傳遞功能將顯著增加管理工作。如果所有類型的UE都可以通過模型傳輸/交付程序自由地獲得AI/ML模型，則運營商可能會對在空口中引入模型傳輸/傳輸功能失去興趣。在該AI/ML SID中，還應考慮如何避免未經(jīng)授權(quán)的UE通過模型傳輸/傳遞過程獲得AI/ML模型，即使該UE正常注冊到運營商網(wǎng)絡。這個主題可能涉及CN工作，但仍值得討論。

最后一部分是關(guān)于AI/ML能力報告，許多公司認為這一主題應該像其他SID一樣在規(guī)范工作中討論，也可以討論規(guī)范工作中的細節(jié)，但也認為即使在SID期間，也可以先討論一些高級框架來進行AI/ML能力報告。與其他UE能力（一旦報告通常是靜態(tài)的）不同，AI/ML相關(guān)能力可以動態(tài)改變，例如，UE剩余存儲和UE剩余計算資源，此動態(tài)UE能力概念在NR SID TR中提出，但在NR SID結(jié)束時被丟棄。認為這個AI/ML SID是一個重新考慮這個機制的好機會，可以在SID中同意這個高級要求。

另一個問題是關(guān)于AI/ML能力定義的框架，由于AI/ML部署與LCM中包含的子功能高度關(guān)聯(lián)，因此總體AI/ML功能不足以反映UE可以部署的實際AI/ML相關(guān)功能。例如，如果UE僅報告支持的model ID，則網(wǎng)絡將不知道UE是否支持模型訓練，因此需要特定于特征的AI/ML能力。此外，如果UE能夠為某些模型進行模型訓練，則也不能假設(shè)UE能夠為任何類型的AI/ML模型進行模型培訓，因為不同模型之間的模型訓練復雜度不同，因此應根據(jù)model ID報告特征特定AI/ML能力。