Castle on a Cloud

在上一篇文章中, 我們介紹了 dApp 和 E3 介面在 O-RAN 框架中的定位. 接著, 我們介紹一下 E3 的資料格式與參數, 接著我們來介紹 E3 介面的細節, 說明此介面設定如何乘載大量且即時的感測資訊. 首先, E3 interface 目前是 dApp 架構中的延伸介面, 用來讓部署在 O-DU / O-CU 附近的 dApp 與 RAN function 做 超低延遲資料交換與控制. 和 E2 介面連結 nearRT-RIC 和 RAN 不同, E3 直接實作於 RAN (CU/ DU) 之中, 不過在 E3 介面的設計上, 和 E2 有許多雷同之處, E3 也可以拆成 3 層來看: E3 logical interface: E3 是整體 southbound 介面，連接 dApp <=> RAN node E3AP (E3 Application Protocol): E3AP 負責程序與封包類型, 類似 E2AP 在 E2 裡扮演的角色 E3SM (E3 Service Models): E3SM 負責 dApp 資料/控制的定義, 類似 E2SM 也和 E2 介面類似, E3 介面主要有兩個建立關聯的步驟: E3 Setup, E3 Subscription. 我們先從 E3 Setup 開始說明: 這張流程交換的圖示, 應該很有印象,  基本上, 把 xApp/ dApp 以及 E3 Agent/ E2 Agent 的角色調換一下, 就是 E2 介面的 Setup 流程,  在 E3 介面中用來做初始配對, 認證, 建立 dApp 與 RAN node 關聯. 考慮到我們主要要介紹 E3 介面的資料格式與 dApp 功能,  我們先略過 Setup 的介紹, 來花篇幅介紹更重要的 E3 Subscription. 和 E2 介面類似, E3 Subscription 的流程也是先定義了需要的資源, 此處的資源可以是回報的數值, 例如: SRS 回報, 也可以是被控制的功能, 例如: PRB 分配. 在確保了 CU/ DU 有 dApp 所需的支援之後, 接著進行以下的流程: E3 Indication MessageRAN => dApp: 傳遞 tele...

很就沒有來看 O-RAN 的變革, 雖說知道有 dApp 的出現, 提供 realtime App 的應用, 但沒有發現到針對 dApp 也有一個專屬的介面: E3 interface. 我想就找個機會來整理並介紹. 首先, dApp 和 E3 interface 是 O-RAN 社群在 nGRG / research report 中提出的延伸架構, 不是像 E2/ O1/ A1/ F1/ Open Fronthaul 那樣已經是大家熟知的介面. 它的目的是補足現有 rApp/xApp 架構兩個缺口: 無法直接處理 user-plane/ IQ symbol/ reference-signal 級資料 難以做到 10 ms 以下的 real-time control. 我們先以一張圖來表示 dApp, E3 以及其他元件的關係: 在這張圖中, 我們介紹一下各個元件的關係: rApp 在 Non-RT RIC，時間尺度通常 > 1 s xApp 在 Near-RT RIC，時間尺度通常 10 ms ~ 1 s dApp 不在 RIC 裡，而是直接部署在 O-DU / O-CU-CP / O-CU-UP  E3 是 dApp <=> DU/CU 的即時資料與控制介面 E2 仍然是 Near-RT RIC/xApp <=> E2 node (DU/CU) 的介面 如果用角色來分, 各元件的功能如下: rApp: 慢速策略, 模型管理, 長時間尺度 (>1s) 最佳化 xApp: 近即時控制, 跨 cell/RU 之間的協調 dApp: 超低延遲, 貼近協定堆疊, 直接處理 SRS/IQ/CIR/封包等即時大量資料 DU/CU/RU: 真正執行無線與協定功能的 RAN 節點 接著, 我們來看各元件之間的資料交換流程, 並以 SRS 回報為例, 在相關論文中, 明確寫到 SRS 可由 O-DU 透過 E3 提供給 dApp, 定位 use case 則是使用 UL CIR. 所以整體的流程是: SRS => O-DU channel estimation => CIR/features => dApp inference. 我們以下圖來表示整體資料交換流程: 整體的流程可分成 6 步驟: dApp 先用...

在 上一篇文章 中, 我們介紹了 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...

在開始介紹 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 d...

在開始介紹這次的 NCR 內容前, 我們先介紹另一個相似的概念: IAB, IAB 全名為 Integrated Access and Backhaul, IAB 也是 3GPP 針對 5G NR (特別是 mmWave 段) 提出的新技術, 其技術的示意圖如下: 來自:  https://www.rcrwireless.com/20200727/5g/iab-the-cost-effective-solution-to-quickly-expand-5g-mmwave-coverage-analyst-angle IAB 技術的提出, 很明顯地是在 5G NR 初始時對 mmWave 充滿期待的時期, 考慮到 mmWave 在空氣中的衰減快, 但擁有高通訊頻寬的特性, 就有人提出了這種以 mmWave 延伸 mmWave 的概念, 簡單來說, 就是把 mmWave 當作光纖使用, 用以作為延伸小基站間的連線, 而資料傳輸的斷點設在 DU 中間 (PDCP-RLC層), 如下圖所示: 來自:  https://nccnews.com.tw/202209/ch4.html 如果說 NCR 是 Amplify-and-Forwarding (AF) 的技術延伸, IAB 就是 Decode-and-Forwarding (DF) 的技術延伸, 一方面, DF 可以避免在多個基站轉傳過程中造成的雜訊放大, 另一方面, IAB 技術的接收端為特殊設計的小基站, 有較佳的計算能力, 以及穩定的電源供應, 可以負擔 DF 的需求. 考慮到 IAB 為 DU 內分割 (intra-DU) 的框架, 所有分支節點皆可視為原有 DU 的延伸, 當結點的階層數大於一時, 則會產生對應的樹狀結構, 並避免迴圈產生, 至於干擾, 考慮到 mmWave 的指向性波束以及 IAB 位置為預先規劃,  IAB 結點之間的干擾應該不嚴重, 或是以空間多工即可避免, 比較需要注意的反而是因為天線無法同頻收法所導致的資源分配問題, 在目前 IAB 架構中, 簡單的作法即是以分時多工的方式進行. 考慮到 mmWave 在目前 5G NR 中並不算太成功, 對應的 IAB 發展仍是有限,   在目前各式的 Use Case 中, 最引人注目的應該是空中基地台...

在之前的文章中, 我們介紹了 RIS 的功能, 對於通訊研究而言, RIS 是一個新穎也陳舊的概念, 新穎的地方在於: 透過被動反射, 我們可以改變通道的特性, 陳舊的地方在於: 類似的訊號增強概念, 我們之前在中繼器 (Relay) 中, 已經在 3G/4G 時代轉了一大圈, 最後並沒有被實踐. 也或許是因為這樣的原因, 3GPP 對於 RIS 實現並沒有特別熱衷, 但是, 仍然組成了一個研究團隊, 以 Repeater 的角度切入, 並引入控制的概念, 這也就是我們今天要介紹的: Network-Controlled Repeater. 相關 3GPP 文件為: TR 38.867 Study on NR Network-Controlled Repeater (NCR) 我們先以一張示意圖說明 NCR 的概念: 在 NCR 的架構中, Repeater 受控於 gNB (基地台), 並有兩條路徑: Control Link: 基地台對應的控制信令, 由 NCR-MT 接收. Backhual/Access Link: 轉傳/增益的通道, 將訊號增強後傳至 UE. 在初始的討論中, Control Link 和 Backhual/Access Link 使用相同的頻帶, 同時, Control Link 透過 Uu Interface 進行控制,  因此,  NCR 對基地台的角色接近於一個特殊的 UE, 另一方面, Backhual/Access Link 可以視為在 RIS 構架下, BS-RIS, RIS-UE 這兩條直視路徑的無線通道, 在 3GPP NCR 的框架中, 轉傳單元 (NCR-Fwd) 類似於 RIS 反射板的角色, 但是不同於一般 RIS 為被動元件, NCR-Fwd 提供 Amplify-and-Forwarding (AF) 的功能, 換句話說, NCR-Fwd 會將接收到的訊號增強後, 再轉傳至 UE. 這樣的框架, 的確類似於 3GPP 之前對 Relay 的討論, 在類似於 RIS 的部分則在於對 NCR 加入的 beamforming 功能, 透過 beamforming 技術, NCR 可以減低一些 AF 遭詬病的雜訊放大問題, 同時, 也可以更有效的增強使用者接收訊號的強度....

在 2023 年的最後一天, 也就把這一系列文章做個總結吧, 近來幾個月, 因為工作的堆積與忙碌, 許多手邊待看的文章都是半完成品狀態, 尚未系統性的整理, 時間的缺少, 與缺乏整理, 多少也影響了撰寫的文章品質... 新的 2024 年, 雖說預期應該是越來越忙碌,  但還是希望可以分享更多有趣的無線通訊內容. 雖然, 在 blogger 文章中, 盡量不提演算法部分的內容, 不過對於通訊問題來說, 在進行問題討論前, 最重要的兩件事就是: 1) 定義模型: 描述觀察值與待測物之間的關係 2) 定義情境: 給定位提的討論設定, 提供公平比較的基準 在上一篇文章中, 我們說到網路節能的目標情境, 雖說不太完整, 但至少有些方向, 在這一篇文章中, 我們就來討論一下基地台的能源消耗模型. 首先, 為什麼是基地台? 如前所述, 無線接取網路佔 80% 能源消耗, 而基地台又是其中的要角, 所以, 當討論能源消耗模型時, 自然是從基地台下手. 至於此能源模型的定義, 則是由 3GPP TR 38.864 進行, 其文件名稱為:  “Study on network energy savings for NR (Release 18)” 來自: MTK 吳威德博士演說 在 3GPP 的能源消耗模型中, 按照慣例, 不會給每個參數明確數值, 但是, 我們可以看到, 有哪些因子會影響基地台的能源消耗: 其中, 我們先看功率項, 包含: 靜態 (static), 天線 (ante), 資源分配 (joint), 靜態功率可以想像是基地台開機就需要的作工, 包含: 冷卻, 電源供應, 等. 天線功率則包含每一組天線的射頻模組功耗, 包含, 放大器, 振盪器等, 最後, 資源分配相關功率則包含了使用的頻譜大小, 以及頻譜功率密度. (*PSD = Power Spectral/Spectrum Density) 此三個項次, 又可以對應於四種節能的方式: 空間: 漸少活躍的天線個數, 天線功率對應的 Sa 下降. 時間: 有一段時間不傳資料, 等校的 Sa 下降. (若是關機可以省下靜態功率) 傳輸功率: 減少天線的發送功率, 頻譜功率密度對應 Sp 下降. 頻寬: 減少使用的通訊頻寬, 頻譜大小對應的 Sf 下降. 透過上述能源使用模型, 由於 Sp 和 Sf 都...

在前述的文章中, 我們介紹了能源節省的各種面向, 然而, 針對一個工程問題, 我們首先要定義的是如何評量節能效率, 換句話說, 我們要定義在甚麼情境下進行節能效率的評估, 我們以兩份 ITU 文件作為參考: ITU-R M.2410-0, ITU-R M.2412-0 在第一份文件 (ITU-R M.2410-0), 名稱為: "Minimum requirements related to technical performance for IMT-2020 radio interface(s)", 定義了 IMT-2020 (5G NR) 中, 對於無線技術 (Radio Interface Technology, RIT) 所需要作出的評估, 其中, 關於能源效率的部分定義於 4.9 Energy efficiency, 以下是原文: Network energy efficiency is the capability of a RIT/SRIT to minimize the radio access network energy consumption in relation to the traffic capacity provided. Device energy efficiency is the capability of the RIT/SRIT to minimize the power consumed by the device modem in relation to the traffic characteristics. Energy efficiency of the network and the device can relate to the support for the following two aspects:     a) Efficient data transmission in a loaded case;     b) Low energy consumption when there is no data. Efficient data transmission in a loaded case is demonstrated by the average spec...

除了 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 也提供了資訊交換的流程...

在之前文章中, 我們仔細地討論了 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);  ...

在 FlexRIC 的架構中,  其 Service Model (SM) 包裝成 library 供 xApp 和 E2 Agent 使用, 因此, 在使用 SM 進行資料交換前, 必須先定義 SM, 並將定義好的 SM 封裝, 使得 xApp 和 E2 Agent 皆可使用. 詳細的說明, 可以參考官網建立 SM 的教學文件: https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create-a-service-model 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create-a-service-model 為了要建立 SM, 首先我們要建立相對應的檔案系統, 方法為執行: cd flexric/src/sm && python3 gen_sm.py 執行後輸入 SM 名稱 (default 為 new), 產生 new_sm 的資料夾與對應程式, 其資料結構如下圖所示:   產生完新的 SM 之後, 我們就要修改 CMakeLists, 將新的 SM 加入編譯路徑, 一共有兩層 CMakeLists.txt 需要修改: ~/flexric/src/sm/CMakeLists.txt ## 在此文件中, 加入新的 SM 路徑: add_subdirectory(kpm_sm_v2.02) .... add_subdirectory(new_sm) #在文件尾端加入產生的資料夾名稱 ~/flexric/CMakeLists.txt ####### ## Service Models ####### # KPM service Model encoding definitions set(SM_ENCODING_KPM "ASN" CACHE STRING "The KPM SM encoding to use") set_property(CACHE SM_ENCODING_KPM PROPERTY STRINGS "PLAIN" "ASN" "FLATBUFFERS") message(STATUS "Selected...

這一篇文章主要是介紹如何在 VM 中建立一個 FlexRIC 的測試環境, 主要依據 FlexRIC 的官方教程: https://gitlab.eurecom.fr/mosaic5g/flexric#1-installation 在 FlexRIC 的官方網站中, 有許多有用的資源, 可以參考. 和 O-RAN SC 的網站相比, 指引較為明確. 在以下的操作中, 我們使用 VirtualBox 7.1 的版本, Linux 的基底採用 ubuntu 20.04 的版本進行. * VirtualBox 6.X 版本對 ubuntu 20.04 有機率遇到顯示的問題 * 由於對 gcc 的版本需求, 需要 ubuntu 20.04 以上的版本 以下是 FlexRIC 的相依套件的版本需求: CMake: 3.15, Python: 3.8 SWIG (提供 python, Java 操作介面): 4.0 [A] 我們就先從 CMake 開始, 參考此份安裝文件: https://apt.kitware.com/ 1) 安裝認證套件與 wget sudo apt-get update sudo apt-get install ca-certificates gpg wget 2) 取得密鑰 wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor - | sudo tee /usr/share/keyrings/kitware-archive-keyring.gpg >/dev/null 3) 將 CMake 套件來源放入安裝庫 echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ focal main' | sudo tee /etc/apt/sources.list.d/kitware.list >/dev/null echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.g...

在 O-RAN 的架構下, 目前主流有兩個開發的平台: OSC (O-RAN Software Community): O-RAN 官方的開源軟體, 基於 K8S 進行實作, 持續更新不同版本:  https://wiki.o-ran-sc.org/ SD-RAN: ONF 軟體開發, Intel 提供支援硬體支援 (FlexRAN), 也是基於 K8S 進行開發: https://docs.sd-ran.org/master/index.html 此平台相較於 OSC, 更著重於 xApp 的開發, 尤其是和 SON 的功能整合 今天要介紹的 FlexRIC 相較之下就較為小眾, 背後發展的組織為 EURECOM, 也是 Open Air Interface (OAI) 的開發者, 因此, FlexRIC 平台最佳的硬體支援也就是 OAI 的 5G 基地台. EURECOM 的生態系 ( https://openairinterface.org/mosaic5g/ ) 如果這只是一個小眾的實作, 為什麼我們要特介紹呢? 事實上, FlexRIC 平台在作為實驗平台上有下列兩個優點: 硬體支援性: 相較 Intel FlexRAN 的平台, OAI 的環境較好搭建與取得, 這也是在缺乏商用 Small Cell 的情況下, 可能最簡單的實作方式 架構的簡易性: 相較 OSC 和 SD-RAN 以 K8S 的 RIC 實作, FlexRIC 使用平行的 c 程式進行 RIC 實作, 較容易 trace code 與修改. 以下是 FlexRIC 的架構圖 (我們之後還會看到許多次): FlexRIC 的架構 (來自: https://openairinterface.org/wp-content/uploads/2022/07/2022-07-13-EURECOM-FLEXRIC-SLIDES.pdf ) 在 FlexRIC 的架構中, 和 OSC 與 SD-RAN 不同, 是將兩者以 library 的方式分享, 而沒有透過 K8S 的機制, 將不同的 xApp 與管理單元隔離開來, 這樣的架構的好處, 是可以透過一個預先定義的 SDK, 簡化布建的複雜度, 但是相對的, 當今天服務模型改變, 整個 SDK 也需要重新定義與修改, 極端一點的說法, 就是當一...

在介紹此 Use Case 之前, 我們可能要先說明一下甚麼是 Network Slicing, Network Slicing 的概念, 是將網路分成許多虛擬的通路, 而每一條通路, 都有其分配下去的資源 (頻寬, 傳送優先權等), 因此, 對於有 QoS 需求的使用者, 就可以藉由非屬不同虛擬通路, 達成使用者的通訊分級, 並確保安全性與通訊品質. 這樣的概念, 在電腦網路中十分盛行, 尤其針對有線網路部分, 我們可以藉由 VLAN (Virtual Local Area Network) 的設置, 串起在不同國家的辦公室, 也可以賦予不同 VLAN 優先權進行傳輸. 假如我們想要把類似的概念套用在行動網路上, 我們就必須套用於行動網路中的兩個主要的部份:  Core Network (核心網路), Radio Access Network (無線接取網路). 原圖來自: https://teppeilog.com/whatisnwslicing_e/ 首先, 對於 Core Network 的 Sciling, 由於是有線網路的設置, 所以在現有的系統架構中, 就已有許多實作討論, 以 5G NR 網路來說, 通常會有 eMBB, URLLC, mMTC 這三種網路, 加上一個控制網路, 前三者是不同 QoS 的分群, 第4種是用來傳送網路的控制信令. 然而, 在實際的網路中, 無線通訊資源的分配實際上是在 RAN 中分配, (* 使用者實際透過 RAN 分配的 resource block 進行通訊) 因此, 若我們要真的進行針對使用者的通訊進行保證, 還必須針對 RAN 進行相對應的設置, 就稱為: RAN Slicing. 為了實作此功能, RAN 也必須向 Core Network 確認 Slice 的設置, 並據此進行 RAN slice 的設計.   在 O-RAN 的系統中, Core Network Slice 的資訊儲存於 SMO 中, 這些資訊以 SLA (Service Level Agreement) 的方式表示. 除了 Core Network Slice  的資訊之外, 為了對 RAN 網路進行配置最佳化, O-RAN 還收集了一些其他資訊, 主要包含下列兩項: 網路的效能參數 Performance M...

在 2022 年 11 月,  O-RAN 組織加入的一個新的介面稱為 Y1 interface, 此介面提供 Near-RT RIC 不只是可以透過 E2 介面和 RAN 中的元件溝通, 更可以繞過 Non-RT RIC 和 SMO 提供一個直接對外的方式, Y1 interface 和 RIC 和其他元件間的關係如下圖: 來自: O-RAN.WG1.OAD-R003-v08.00 (O-RAN Architecture Description) 在上圖中, 我們可以看到 Y1 interface 直接和 Y1 consumer 對接, 至於 Y1 consumer 可直接讀取 Near-RT RIC 的分析結果, 存取有以下兩種限制: Y1 consumers could be Application Functions (AFs) when they are in an O-RAN trusted domain.  The RAN analytics information could be provided to AFs in a secure manner via an exposure function. 在這邊給予一些解釋, 第一點限制了 Y1 consumers 必須在 O-RAN 的信賴網路內, 這邊的信賴網路通常就是 O-RAN 的內部網段 (或是預先設定過的內網), 若要提供第三方應用, 則必須透過曝光功能 (exposure function) 的方式進行, 這邊的曝光功能類似於 3GPP 定義的網路曝光功能 (Network Exposure Function, NEF), 基本想法即是保護 Y1 介面不會直接被外部網路存取, 而必須透過一信賴的元件轉傳, 透過這樣的機制, 可以確保遭受攻擊時, 不至於癱瘓整體的 Y1 服務. 在加入 Y1 interface 之後, Near-RT RIC 的架構可以表示如下圖: 來自: O-RAN.WG3.RICARCH-R003-v04.00 (Near-RT RIC Architecture) 在這份文件中, 我們可以更清楚的看到 Y1 interface 的實作方式, 基本上實作的邏輯會類似於 E2 和 A1 interface, 也就是: 透過 termin...

在 之前的文章 中, 我們介紹了 O-RAN 中室內定位的 use case, 在當時, 該 use case 仍定義在 WG1 的文件中,  只載明了動機與目的, 並沒有提出進一步的資料交換流程, 我們簡潔的整理如下: 目的: 改善原有 LMF 的定位框架, 提供低延遲定位響應 方法: 將定位計算放置於 xApp 中, 減少資料傳遞所需時間 在此框架下, 仍遺留下一些未解的問題, 像是: 定位需求由誰發起或轉達 (原有 LMF 架構中, 定義了 LMF 接收定位需求的機制), Near-RT RIC (xApp) 與 Non-RT RIC (rApp) 之間的分工, 等... 為了回答這些問題, 在 WG2 的更新文件中, 定義了兩個應用情境: Scenario 1: Only Near-RT RIC 在此應用情境中, 我們可以看到, 定位的計算是由 Near-RT RIC 負責, 量測的資料則主要由 E2 介面從 RAN 中取得, 至於定位的需求與回應, 則是由外部的應用 (也可以是核往) 所驅動, 在這邊值得注意的是, O-RAN 新定義了 Y1 介面, 提供一個 Near-RT RIC 和外界的溝通方式, 而不必透過 Non-RT RIC 轉介. Scenario 2: Only Near-RT RIC 在此應用情境中, 我們可以看到 Non-RT RIC 在其中的角色, 主要是透過 O1 介面收集資料, 並進行定位模型/演算法的訓練, 在與 Non-RT RIC 協作的情況下, xApp 也要支持模型的選擇與更新, 可能是考慮到定位的即時性, 定位的請求與更新, 仍是透過 Y1 直接和 xApp 溝通, 不過定位完的資訊也會存回 Non-RT RIC, 供其他應用取用.