Castle on a Cloud

在 上一篇文章 中, 我們介紹了 CCC 這個 Service Model 的設計目的, 接下來, 我們將介紹一些細節, 並針對一些特殊功能進行介紹, 首先, 我們先看一下 Cell level 和 Node level 的功能定義: 來自:  WG3-E2SM-CCC-R003 在上述的欄位中, 我們可以看到 CCC 主要對應於 CU/DU 功能, 並不包含 RU 的部分 (E2 介面其實不直接和 RU 通訊) 針對 Node level 和 Cell level 的差異, 我們以 DU 為例, 看一下 Table 8.8.2.1 和 8.8.1.2, 來自:  WG3-E2SM-CCC-R003 在表中, 我們可以看到 CU 主要是可以控制換手資訊, 可以控制的欄位多半在 Node level, 對 CU 直接進行控制, 相對的, DU 的控制主要是無線通訊的信令, 則集中在 Cell level 進行, 除此之外, 在表格的欄位中, 我們可以看到一個特殊欄位: is writable, 如果此欄位為 FALSE, 則代表此設定和其他設定有相依性, 不能由 RIC 修改, 但是, 我們也可以看到出現支援 Control Service, 但 writable 為 FALSE 的狀況, 對此, CCC SM 的解釋為, 此類欄位只能作為 Control 的參照 (reference),  不能作為修改的目標. 在本文的最後, 我們來看一下 CCC SM 和節能控制的關係, 定義在 O-CESManagementFunction 中 (Table 8.8.2.5), 來自:  WG3-E2SM-CCC-R003 其中, CES 代表 Cell Energy Saving,  在此功能項之下有三個欄位: cesSwitch, energySavingState, 與 energySavingControl, 前兩者對應於功能的開啟與關閉, 是唯讀的欄位 (Report), 最後一個欄位則是 CCC SM 可以控制的項位,  並要在 energySavingState = "isEnergySaving" 的條件下, 可以透過設定 "toBeEnergySaving" 和 "toBeNotEnergySaving&quo

在開始介紹 CCC (Cell Configuration and Control) 這個 Service Model 之前, 我們先來回顧一下 Service Model 的定義, 在 O-RAN 標準中, Service Model 對應於 E2 介面, 定義了 E2 Node (接取網路) 到 Near-RT RIC (控制器) 之前的資料格式. 不同的 Service Model 對應於不同的應用情境, 舉例來說, KPI Monitir (kpimon) 對應於接取網路的資訊收集, RAN Control (rc) 則對應於接取網路的控制. 因此, 當我們看到一個新的 Service Model 時, 應當想到的第一個問題是: 這對應於甚麼應用情境? 在 O-RAN 文件 (WG3-E2SM-CCC-R003) 中, 對此 Service Model 描述如下: “Cell Configuration and Control” which performs the following functionalities: - E2 REPORT services used to expose node level and cell level configuration information - E2 CONTROL services used to initiate control and/or configuration of node level and cell level parameters  和舊有的 RAN Control Service Model 相比, CCC 更著重在 Cell/ Node level 的控制, Cell level 的控制, 對應到基地台的功能, 例如: BWP (Bandwidth Parts) Node level 的控制, 則對應到基地台中的不同元件, 例如: CU, DU, 接著, 下一個關鍵的字詞是 configuration 的定義, 在同一份文件中, 定義如下: RAN Configuration Structures are groupings of RAN configuration attributes, which can either be based on the NRM defin