Castle on a Cloud

除了 3GPP 定義了網路節能的框架外, O-RAN 組織也定義了對應的節能功能, 稱為 Network Energy Saving (NES), 在 O-RAN 定義的架構下, NES 又可以分成以下的應用案例: Carrier and Cell Switch Off/On → 負載低時, 不影響 QoS 下, 關閉 Carrier 或是 Cell RF Channel Reconfiguration Off/On → Beamforming 下, 關閉部分 RF 陣列 Advanced Sleep Mode Selection → O-RU, O-DU, O-CU 的 Sleep Mode 選擇 O-Cloud Resource Energy Saving Mode → O-DU, O-CU 計算資源的能源節省 在 O-RAN 的 Use Case 中, 多數的功能都在 3GPP 的定義功能下, 但是相比 3GPP 的大基站節能框架, O-RAN Use Case 更著重在小基站的環境, 較不著重在底層無線傳輸的調整, 而著重在無線的設定調整, 因此, 在前兩個子項中, O-RAN 定義了不同層級的 ON/OFF 節能, 從 Cell, Carrier, RF array, 從大到小, 提供不同精細度的調整. 第三個子項, 則對應時間上的節能, 並實作於 3GPP 的框架中, O-RAN 扮演的角色像是不同基站的協調者, 同時滿足接取與解能的需求. 第四個子項, 則是目前看到 O-RAN 特有的項目, 透過 O-Cloud 與虛擬化技術, O-RAN 還可以調整 O-CU/O-DU 的計算資源, 提供計算資源上的節能成果. 針對 NES 的功能, O-RAN 也定義了對應的統計指標 (KPI), 包含: O-RU specific KPIs: Energy efficiency and power consumption  O-CU/O-DU hardware & software/ O-Cloud software & platform KPIs 在 O-RAN 所定義的 KPI 中明顯分成兩項:  RU 代表硬體的無線功率節省, O-CU/O-DU 代表的軟體耗能, 基於 KPI 的定義, O-RAN 也提供了資訊交換的流程...

在上一篇文章中, 我們介紹了網路節能的基本概念, 並從 Nokia 的角度出發, 說明了網路節能的好處與必要性, 接下來, 我們將基於聯發科吳威德博士在陽明交大的演講, 介紹從 3GPP 角度出發的網路節能功能探討. 在吳博士的演講中, 針對網路節能的必要性提出了兩個說明: 1) 5G NR 的通訊通率上升: 5G NR 中, 為了增加通訊容量, 大量使用多天線技術 (massive MIMO), 多天線技術, 尤其在 mmWave 的頻帶上, 可以有效增加通訊效能, 使得 5G 技術相對於 4G 更加耗電 (2 倍的通訊容量, 需要 8 倍天線個數), 根據 Ericsson 的調查, 從 2020 到 2030, 用於通訊能源的消耗將成長 61 倍.  2) 電費對於電信營運商的營運成本: 在現在電信營運商的營運成本中, 約略 20-40% 來自於電費, 以台灣三大營運商而言, 一年的電費約略是 20 億元, 在可見的未來, 由於綠能以及碳排稅的需求,  電費佔電信營運商的成本可能會將近 5 成, 甚至造成負擔. 考慮到上述的節能需求, 3GPP 從 R17 開始討論網路節能的功能, 在技術上的討論可以分成 3 個方向: 時間, 空間/功率, 頻率, 整體的進程可以以下圖表示: 來自: MTK 吳威德博士整理 針對每一項技術的細節, 我們會再找時間詳細介紹, 我們先從概念上了解 3GPP 在節能上的功能設計: 時間: 在基站加入類似手機休眠功能, 基地台也可以休眠, 根據 loading 決定工作時間 空間/功率: 透過功率和 beamforming 調整, 根據使用者位置與需求, 調整無線設置 頻率: 根據負載調整基地台的頻率使用,  類似反向的 Carrier Aggregation (CA) 在整體功能上, 由於 RF 是主要的能源消耗的部件, 因此, 直接的調整 RF 開關 (時間上多工), 或是 RF 功率調整 (空間上多工), 都比起頻率上多工來得更有節能效果, 整體的比較如下圖表: 來自: MTK 吳威德博士整理 以 3GPP 的角度來看,  主要的目標在於定義使用者 (UE) 和基站的共同協作機制, 因此, 特別著重的情境仍是大基站 (marco cell) 對使用者的節能功能,...

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 上的參數設定, 畢竟任何針對網路的修改都需要硬體反應時間,  同時, 太頻繁的修改也將導致網路的不穩定性, 要審慎進行.

在之前的說明中, 我們大致介紹了一個 Service Model (SM) 的建立, 以及所對應要進行的修改流程, 包含: SM 定義, RIC 以及 xApp 部分, 在這篇文章中, 我們會介紹一下其對應的流程以及背後參數設定原因, 首先, 我們先回顧一下在 O-RAN 架構中的 Indication 資料結構,  如下圖所示: 來自: Polese, Michele, et al. "Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges." IEEE Communications Surveys & Tutorials (2023). 在 O-RAN 的框架下, 其 Indication (其他型態也是) 傳送的資料結構分成兩層: E2 AP (Application Protocal): 可以視為信封, 標記了識別資訊與註冊流程 E2 SM (Service Model): 可以視為信紙, 收送雙方定義的資料結構 在 FlexRIC 中, 可以找到 xApp 的範例程式如下: https://gitlab.eurecom.fr/mosaic5g/flexric/-/blob/master/examples/xApp/c/monitor/xapp_kpm_moni.c 我們接下來會大略介紹一下程式碼, 並對應於 FlexRIC 的流程圖: 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp 以下是 xApp 接收 Indication 的程式 (稱為 monitor), 我們取最簡單的 xapp_kpm_moni.c 作為範例, 並以藍字為註解: examples/xApp/c/monitor/xapp_kpm_moni.c #include "../../../../src/xApp/e42_xapp_api.h" // FlexRIC 的 API #include "../../../../src/util/alg_ds/alg/defer.h" #include ...

在完成 Service Model 的定義之後, 我們需要透過程式對所定義的 Service Model 進行操作, 考慮到 FlexRIC 的實作架構, 我們在修改 xApp 和 E2 Agent 的程式前, 要先修改 FlexRIC 相關的程式, 以提供 xApp 和 E2 Agent 串接的支援, 在此實作中, 我們以 Indication 作為開發的應用, 此應用中, xApp 負責送出訂閱 Indication 的需求, E2 Agent 則將數值填入 Indication Message 中, 並定期發送. 在 FlexRIC 官方網站中, 提供教學的連結如下: https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Files%20need%20to%20be%20modified%20for%20developing%20xApp%20C%20binding 在 FlexRIC 中, 整體的資料交換流程如下: 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp 在上述的流程中, 我們可以歸類於以下 5 個步驟: E2 Agent 透過 E2 Setup 向 FlexRIC 註冊 (ID, 以及所支援的服務) xApp 向 FlexRIC 進行註冊 (為自定義的 E42 介面) xApp 向 E2 Agent 註冊 Indication 服務 (Subscription Request) E2 Agent 根據訂閱的資訊以及時間間隔, 進行資料回報 xApp 收到資料將數值存入 SQLite (不是標準的 O-RAN 流程, 在此先略去) xApp 向 E2 Agent 刪除 Indication 服務 (Subscription Delete Request) 在 FlexRIC 對應的 c-code 程式中, 為了加入一個新的 Service Model, 我們也要進行相對應的修改, 包含三個部分: xApp, RIC, 和 E2 Agent, 對應的資料夾位置為:...

在定義好 Service Model 的 Indication 之後, 我們接著去修改 Encode/Decode 的相關程式, 位置的路徑一樣是位於: ~/flexric/src/sm/new_sm 在此路徑下, 有兩個資料夾: dec, enc, 分別對應於 decode 和 encode 的功能 其中, 我們也可以看到, 在 encode/decode 中也對應了三種格式: ASN.1, fb (flatBuffer) 以及 plain, 對應於在 SM 建立的格式, 考慮到我們使用 plain 作為此次的範例, 相關的檔案就包括: enc/new_enc_plain.h, enc/new_enc_plain.c, dec/new_dec_plain.h, dec/new_dec_plain.c, 其中, header 檔 (.h) 只定義了程式,不須修改, 和 SM 相關修改的範例如下: enc/new_enc_plain.c: // 根據定義的 SM 資料格式長度宣告記憶體大小 // 並把 SM 中的資料直接 memcpy 至傳送的資料格式中 byte_array_t new_enc_ind_msg_plain(new_ind_msg_t const* ind_msg) {   assert(ind_msg != NULL);   byte_array_t ba = {0};   size_t const sz = sizeof(ind_msg->len) +                    sizeof(new_ng_u_tunnel_stats_t)*ind_msg->len +                    sizeof(ind_msg->tstamp); // 長度為 SM 定義的格式加上 timestamp 長度 //  printf("Size of the byte array = %lu\n", sz);   ba.buf = malloc(sz);  ...