Castle on a Cloud

5G 網路尚未普及, 學界和業界已經開始討論 6G 的進展, 相較於 5G NR (New Radio) 的雄心壯志, 6G 的目標相對保守, 目前較確定技術變革的主軸大概有三項: NTN (Non-Terrestrial Networks) 網路: 包含低軌衛星, 無人機網路 ISAC (Integrated Sensing and Communications): 結合感知與通訊, 更動態的資源配置 Sustainable Networks: 對抗由於 mmWave 產生的高耗能與碳排放帶來的營運成本 其他, 還有一些尚待討論的項目, 像是: 更寬廣的頻寬 (Tara Hz), 智慧反射板 (RIS), 等. 當然, 也包含了 AI/ML 模型的引入, 用以支援這些新穎技術. 在上述的技術中, 最直接可用的就是 Sustainable Networks 帶來的節能, 不過, 我們首先要回答一個問題: 為什麼行動網路需要節能? 先撇開甚麼 "我們只有一個地球" 不談, 在 6G 這時刻強調節能的原因有兩個: mmWave 帶來的高能耗通訊成本, 大幅提升 RAN 端的能源使用 碳排稅對營運成本的疊加, 從固定成本變成累進成本 基於上述原因, 在 3GPP 討論 6G 的進程時,  營運商 (也是 3GPP 的主力) 自然對此議題投入大量興趣, 也很快的定調成 6G 的技術主軸之一. 那麼第二個問題是: 我們真的可以節能嗎? 可以節省多少能源? 在過去, 行動網路只考慮了手機 (裝置端) 的節能, 針對 RAN 端 (基地台, 射頻元件等) 的態度是反正有線不必考慮, 當節能需求被提出時, 第一個去實現的就是 Nokia/Ericsson 等業者, 而這些業者也針對節能提出一街解決方案, 我們以 Nokia 的為例,  根據 Nokia 的調查, 行動網路中多數的資源用於 RAN 端 (80%), 但是, 整體用於實際通訊的能源只有 15%. 圖片經作者修改, 原始來源: Nokia blog 當然, 這並不是說 85% 的能源都浪費了, 畢竟要知道使用者的通道, 要維持基本的通訊連線都需要資源消耗, 但是 85% 的巨大落差也表示了在網路節能上有巨幅的改進空間. 針對不同種類的能源消耗, 進行節能也需要不同解方, 比如說基地台的散熱能源消耗,

在之前文章中, 我們仔細地討論了 Indication 所需要做的修改, 在這篇文章中, 我們轉而討論另一種 E2 協定: Control, Control 在 O-RAN 的定義中, 用以乘載 RIC 對 E2 Node 的控制信令, 不同於 Indication 在 O-RAN SC 中有完整的定義, Control 的開源實作的進度較慢, 這可能主要來自兩個原因: Indication 可以回傳的資訊數量與格式相對明確, 可以定義並以模擬器實作 Control 所需承載的資訊需要硬體支援, 並和 Use Case 相關 而針對第二點, 也正是 FlexRIC 的優點, 在擁有 Open Air Interface 的硬體平台支援下,  FlexRIC 可以更容易實作 Control 的功能, 並結合硬體進行展示. Control 和 Indication 相同, 可以視為一個獨立定義的 Service Model, 需要預先定義其資料格式, 考慮到 O-RAN SC 並未有詳細定義實作, 我們通常以 plain-text 的方式定義 Control 的資料格式,  下圖為 FlexRIC 所實作的 Control 流程: 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric 在上圖中, 我們可以看到 Control 和 Indication 都需要 E2 和 E42 註冊流程, 這兩步驟建立起 E2 Node 以及 xApp 之間的通訊連線, 而對於 Control 和 Indication 兩者設計差異, 主要在於 Indication 是定期驅動, 所以需要設定驅動的週期, 相對的 Control 是依據 RIC 上的事件驅動, 送出 Control Request, 在 E2 Node 執行完後送回 Control Acknowledge, 這樣的設計邏輯在於 E2 Node 的回報應是頻繁且規律的, RIC 上的 xApp 透過這些收集的資料以及 AI/ML 的運算, 只有在必要的時候, 才透過 Control 更改 E2 Node 上的參數設定, 畢竟任何針對網路的修改都需要硬體反應時間,  同時, 太頻繁的修改也將導致網路的不穩定性, 要審慎進行.