Castle on a Cloud

在 上一篇文章 中, 介紹了 E2 Setup 的流程以及資料傳遞的欄位, 透過上述資料交換流程, RIC 就可以得知 E2 Node 的能力以及識別方式, 之後, RIC 將透過 Subscription Procedure 向 E2 Node 訂閱相對應的資源, 相關的資料交換如下圖所示: 我們可以看到, 其訊息組合主要由 RIC Subscription Request 和 Response 組成, 其中, RIC Subscription Request 包含了下列資訊: 來自: O-RAN.WG3.E2AP-v02.00 其中, RIC Request ID 包含了 RIC 的訂閱時的識別資訊, 由 PLMN (Public Land Mobile Network) ID 和一組 RIC ID 組成, 用以表示 RIC 平台的電信營運商, 以及其對應的 RIC 編號, RAN Functional ID 包含了要向 E2 Node 訂閱服務, 在此假設 RIC 和目標 E2 Node 的連線已經透過 SubMngr 建立, 故不帶 E2 Node 識別資訊, 至於 RIC Event Trigger Definition 中則定義了驅動事件 (例如: 定時驅動), 在 E2AP 的格式中, 此欄位為 16 進位編碼, 其定義編寫於 E2SM 中. RIC Action ID /Type 則定義了當事件發生時要進行的動作 (例如: REPORT-indication), RIC Action Definition 的格式如同 RIC Event Trigger Definition 一樣, 定義於 E2SM. 另一方面, RIC Subscription Response 包含了下列資訊: 來自: O-RAN.WG3.E2AP-v02.00 除了在 Request 已經提過的 RIC Request ID, RAN Function ID 之外, 在 Response 中最重要的任務就是確認 RIC 要求的 Action 是否被接受, 若接受則放於 RIC Action Admitted List 中, 若不接受則放於 RIC Action Not Admitted List 中, 並加入原因.

在之前的一系列文章中, 介紹了 O-RAN 平台上, 如何透過 RESTful API 向 Subscription Management 註冊資訊, 在接下來的一系列文章中, 將介紹在目前 O-RAN 架構中的資料交換格式, 以及其在 E2 Application Protocal (E2AP) 標準中的規範. 首先, 我們先從 E2 Setup Request 和 E2 Setup Response 開始, E2 Setup 的流程是為了讓 RIC 知道 E2 Node 的識別方法與能力 (支援的功能), 其對應的資料交換流程如下圖所示: 來自: O-RAN.WG3.E2GAP-v01.01 在 RIC Setup Request 中, 包含以下的資訊 (Information Element, IE): Global E2 Node ID Optional: List of RAN Functions Added IE Optional: E2 Node Component Configuration Update List IE  其中, Global E2 Node ID 適用以辨別 E2 Node 的資訊, 包含了一組 gNB/eNB ID 以及其對應的 CU-DU, RU 的組成 (以 local ID 表示), 用以表示  gNB/eNB 和 CU-DU, RU 的組成,  可在 E2 Node Component Configuration Update List 中進行宣告. 我們可以看到其內容如下表所示: 來自: O-RAN.WG3.E2AP-v02.00 另一方面, RAN Functions 則代表了 E2 Node 所支援的功能, 每一個 RAN Function 包含了三項資訊: ID, Definition, Revision, 定義如下: 來自: O-RAN.WG3.E2AP-v02.00 其中, RAN Function Defination 的內容為 16 進位的字串,  並被定義於 E2 Service Model (E2SM) 中, 目前一共定有三種不同的 SM, 包含了: Network Interface (NI), KPM Monitor...

在目前的 O-RAN 環境 (e-version) 中, 最完整的 xApp 範例仍是 Traffic Steetring, 在之前的文章中, 我們有提及了 Traffic Steering 在 O-RAN 中的 流程 與 細節 ,  但並沒有詳述其在 O-RAN Software Community (OSC) 中的實作, 其中, 主要參考的內容為:  https://wiki.o-ran-sc.org/display/IAT/Traffic+Steering+Flows 在 OSC 實作中, 我們可以以下面這張圖來解說: 在流程圖中, 有4個 xApp (KPIMON, QPd, QP, TS), 我們列舉並說明其功能: KPIMON: 以 GO 撰寫, 負責向 E2Term 訂閱資訊, 存入 SDL QPd (QP driver): 讀取 SDL 的數值, 將數值給予 QP (後續實作已併入 QP) QP (QoS Predictor): 根據 TS 的需求, 預估目標 UE 在附近 gNB 可得到的 UL/DL 資源 TS (Traffic Steering): 進行換手的決策 (寫入 log 中) 在此實作中, 其實不只有 Use Case 5: Traffic Steering 的實作, 也包含了 Use case 4: QoE Optimization 的實作, 這部份我們會在之後解釋. 同時, 我們也可以看到在這個實作中, 為了當時 O-RAN 的限制, 做出許多奇怪的設計, 例如:  QPd, QP 都是使用 python xApp 撰寫,  由於 python xApp 不支援 E2 的資料交換, 因此有一個以 GO 撰寫的 KPIMON xApp 進行 E2 資料的訂閱, 並轉傳 SDL. QPd 和 QP 的分工, 一開始應該是為了把資料接取和計算框架分開, 所以寫了兩隻 xApp 進行分工, 這部分在 Dawn 版本中, 已整合至 QP xApp 中. TS xApp 由於當初並不支援 Control 的資料下行,  因此, 只能將資料寫入 log 中, 在 Dawn 版本以後, 這部分有加入一個新的 RC (RAN Control) xApp, 試圖將 Control 訊息下達 E...

在 上一篇文章 中, 我們介紹了 UAV 在未來通訊中的角色,  針對此類 3D 通訊應用, O-RAN 也設想了一個 Use Case,  並在此 Use Case 中明訂了三個對於通訊系統的挑戰: LOS propagation/uplink interference (直視路徑的衰減/上行的干擾),  Poor KPI caused by antenna side lobes for base stations (旁波效應造成的低通訊效能),  Sudden drop in signal strength (訊號強度的突然衰減).  上述的挑戰主要來自於 3D 波束通訊的兩難: 一方面, 我們希望波束集中, 加強使用者接收到的訊號強度, 另一方面, 集中的波束導致較小的服務範圍, 導致移動裝置通訊不穩定, 也因此, 引出了旁波 (side lope)* 低效能通訊 (訊號小幅失焦), 以及訊號強度突然衰減 (移動裝置離開可通訊的範圍). * 旁波 (side lope): 在設計通訊波束時, 主要波束方向稱為 main lope, 在 main lope 旁邊會有數個 side lope, 其訊號增益強度較低. 針對上述的挑戰, 對通訊系統而言, 可以用的手段包含: 配置額外的基地台, 提供備援的通訊波束 動態針對 UAV 進行波束的調整 此應用情境下的 UAV 作為空中的小基地台提供使用者通訊服務, 其所需要的通訊需求 (throughput) 為高頻寬的即時資料流, 需要高集中的波束服務, 另一方面, 考慮到 3D 波束通訊中, 每一個波束由多個天線所形成, 且波束間尚有因旁波造成的干擾, 需要進行整體的最佳化, 因此, 針對單一 UAV 進行波束配置的動態最佳化, 需要大量的通訊資源完成, 考慮到基站有限的通訊資源 (天線, 傳輸功率, 計算資源等),  如何配置這些資源給予不同 UAV 就形成一個問題. 考慮到在 O-RAN 的應用情境下, 無法針對 RU 提供 real-time 的控制, 取而代之的是使用 near-RT RIC 以 ML 模型的方式, 提供即時的通訊資源配置 (例如: 功率, 天線數, 頻譜) 給予其所管轄的 CU/DU,  RU 則根據通訊資源配置進行波束設計 ...

在 E2 的四種不同的訊息中, 可以分成兩類, 第一類是由 RIC 訂閱發起, 包含: Report, Policy, Inset, 在此類訊息中, 我們可以看到在訊息建立的開始,  都是由 RIC 發出  Subscrption 的訊息, 建立通訊後進行回報或下行資訊. 第二類訊息則為 Control 訊息, 在 Nokia 的整理圖中 (請參考 這裡 ), 和 Policy 不同, 此訊息的傳輸並沒有由 RIC 發出  Subscrption 的訊息發起, (Policy 的下行訊息基本上包含在 Subscrption 之中) 然而, 若沒有 Subscrption 的訊息, RIC 如何和 E2 Node 建立連線? 我們先來看 SPEC 中的定義: 來自: O-RAN.WG3.E2AP-v01.01 在圖中, 我們的確可以看到 Control 訊息的發起, 是由 Near-RT RIC 發出 RIC CONTROL REQUEST (如右表格所示), 其中, 我們可以看到其中帶有 RAN Function ID, 此訊息在 E2 interface 中, 也包含在 RIC SUBSCRIPTION REQUEST 中, 對應到我們之前讀的 RESTful API 欄位 , 應對應到 RANFunctionID. 來自: O-RAN.WG3.E2AP-v01.01 對比 RIC CONTROL REQUEST 和 RIC SUBSCRIPTION REQUEST 的格式, 在未來 xApp 應可以透過和 Subscription 相同的流程, 送出 Control 的訂閱. 不過, 目前 SubMngr 並沒有支援 Control 的訊息, 引述 來源 如下: Subscription Manager supports REPORT, POLICY and INSERT type subscriptions (E2 RIC Action Types). CONTROL is not supported.  因此, 在目前的實作中, Control 並沒有獨立發起的資料流, 而是依附在 Indication-Insert 中進行回報, 共享 RI...

在未來 6G 的應用中, 無人機組網一直是一個學界很喜歡, 但是, 真實實作方式以及未來應用情境存疑的議題, 其基本的想法是: 透過無人機作為基地台, 提供原本缺乏基礎建設的區域網路服務, 在這邊, 無人機不只是大家一般想像那種空拍機, 而是包含了平流層飛機, 甚至低軌道衛星, 形成的偕同系統, 如下圖所示: 來自: 6G Enabled Unmanned Aerial Vehicle Traffic Management: A Perspective 相較於既有的行動網路, 被稱為地面通訊系統 (Terrestrial Network), 透過無人機提供的直視路徑,  上述的系統可以提供廣泛的訊號覆蓋範圍, 並降低有線網路的布建成本, 先不論 UAV 本身的電源問題, 此網路架構可以針對基礎設施不足的地區, 像是鄉村或是沙漠地區, 或是緊急的通訊需求, 如災難或是戰爭通訊, 提供快速的大面積網路覆蓋. 縱使透過無人機和低軌道衛星的協作, 可以減少地面的基地台布建, 然而, 網路終究還是得回到地面與網際網路進行通訊. 因此, 在無人機構成的網路中, 又可以大略分成兩段: 第一段, 就像是無線的骨幹網路, 提供無人機和地面基地台之間的通訊, 第二段, 則為無人機和終端使用者的通訊. 考慮到無人機的覆蓋範圍廣泛, 為了提供覆蓋範圍內的使用者通訊服務, 其背後的無線骨幹網路必須擁有足夠的頻寬, 因此, 我們多半第一段通訊是以 mmWave 的指向波束進行, 第二階段的通訊, 考慮到 UAV 的電力需求, 也假設會以波束指向功率消耗, 而不以全向性的通訊進行傳輸. 考慮到上述的基於 UAV 通訊需求,  我們可以看到不論是第一段與第二段的通訊, 都為指向性, 同時, 由於 UAV 在空中, 還會額外引入高度的資訊,  所以原有的 2D 通訊, 會轉變成 3D 的通訊機制,  新增的高度維度, 會導致現有的波束學習機制的複雜度過高, (目前機制大致上是以: 掃描-回報 的方式進行, 若拓展至 3D, 導致學習所需要的時間過久...) 這些新引入的問題, 就會造成 6G 網路的新的需求以及挑戰, 我們會在之後的文章中進行介紹.

在目前 E2 介面的定義中, 一共可以分成 4 種功能: REPORT: RIC requests that RAN sends a REPORT message to RIC and continues further call processing in RAN after each occurrence of a defined SUBSCRIPTION INSERT: RIC requests that RAN sends an INSERT message to RIC and suspends further call processing in RAN after each occurrence of a defined SUBSCRIPTION CONTROL: RIC sends a Control message to RAN to initiate or resume call processing in RAN POLICY: RIC requests that RAN executes a specific POLICY during call processing in RAN after each occurrence of a defined SUBSCRIPTION 我們用 nokia 的圖片 (如下),  簡單說明這四種訊息的目的, 在這四種訊息中, Report 和 Insert 被歸類於 Indication 的子項, 此兩種訊息都是讓 E2 Node (上圖中的 RAN) 進行資料的回報, 兩這差別在於對於 Subscrption 中事件定義的反應,  Report 在偵測事件 (如: timer 計時) 後, 繼續所設定的流程, 可以進行定期回報, Insert 則在偵測事件發生後, 停止所設計的流程, 可以用來做 RAN 突發事件的通知, 在另一方面, Policy 和 Control 則與 RIC 對 E2 Node 的指令相關, Control 可以由 E2 Node 發起, RIC 偵測事件後, 直接下達需要執行的指令, Policy 則是由 RIC 向 E2 Node 註冊, 提供事件發生時的運作準則, E2 Node 在偵測事件發生後, 自行根據準則進行相對應的程序. 值得注意的是, 在上圖中...