Castle on a Cloud

在 WiFi 的系統中, 我們通常想到得知 SSID 的方式, 都是 WiFi AP 透過 Beacon 封包進行廣播. 然而, 由於 Beacon 的傳送間隔不確定, 且需在同頻上進行接收, 對使用者而言, 若需要快速知道附近所有的 WiFi AP 列表, 就可以用 Probe 的方式進行主動掃描. 對於 Probe Request 封包而言, 其包含的資訊和 Beacon 類似, 主要有以下資訊: [header] 目標的 BSSID (若為廣播探索則填入 FF:FF:FF:FF:FF:FF) 裝置目前使用的通道 支援的通訊速度, 對 HT PHY 的支援 來自: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics 當 WiFi AP 收到 Probe Request 後, 會檢查其支持的速率,  若相符則會回覆 Probe Response, 其格式基本上和 Probe Request 一致, 只是在 SSID 欄位中會帶有 WiFi AP 對應的 SSID 的資訊. 來自:  http://csie.nqu.edu.tw/smallko/sdn/mininet-wifi_lab1.htm 由上述內容可知, Probe Request/ Response 基本上是一種反向的 Beacon, 不但目標一致: 讓 WiFi Client 得知 WiFi AP 的資訊, 連傳送的封包格式都類似, 唯一差別的地方應是發送的時機, 不同於 Beacon 為等時發送 (通常是 1 秒 10 次), Probe Request 為使用者發起, 例如, 在手機上進行 Scan WiFi, 因此, 其傳送的間隔不定, 根據 Cisco Meraki 的統計, 對於手機裝置約為下表: 來自:  https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics 針對未連線的使用者, 裝置會頻繁 (每分鐘 10-15 次) 的發送 Probe Request, 隨時準備更新要連線的目標, 進入休眠則保持約每分鐘探索一次的頻率, 節省電力. 但是對於已連線 (...

在 E2 Node 進行設定 , RIC 訂閱 RAN function 之後, RIC 和 E2 Node 之間的訊息交換就算完成, 兩者之後的互動, 就按照 RAN function 和其中的 Action 定義, 在所有的互動中, Indication 是最早被實作出來的項目. 事實上, Indication 並不是一種 E2 Application Protocol (E2 AP) 定義的功能, 在 E2 AP 中, 四種功能型態 分別為: REPORT, INSERT, CONTROL, POLICY. Indication 的資料通常被包含在 REPORT, INSERT 兩個功能項內, 其中的的差別在於, REPORT 為比較單純的資料回報, INSERT 則牽涉到 E2 Node 的控制 (回報後, 等待新的控制訊息下達). [註] 目前 xApp-bouncer 的實作就接近 INSERT 的方式, 換句話說, 就是 xApp 收到一個 Indication 後就送一個 CONTROL 給 E2 Node. 然而, xApp-bouncer 的實作並非標準的 INSERT 實作,  其 subscription 的 RAN function 仍為 REPORT,  CONTROL 也未按 E2 AP 格式, 而是以字串方式傳送. 回到這次的主題, 我們討論的應是 Indication-REPORT 的範例, 如第一張圖所示, Indication 所帶的資訊可以分成三類: 識別資訊: RIC Request ID IE, RAN Function ID IE, RIC Action ID IE 資訊內容: RIC Indication Type IE, RIC Indication Header IE, RIC Indication Message IE  其他資訊: RIC Indication SN IE, RIC Call Process ID IE 其中, 識別資訊是用以傳達目標的 xApp 與之後的資料處理, 資訊內容和其他資訊則是 xApp 向 E2 Node 所訂閱的資訊. 比較需要注意的是: RIC Indication Header IE, RIC Indication ...

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