Castle on a Cloud

在 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 在偵測事件發生後, 自行根據準則進行相對應的程序. 值得注意的是, 在上圖中...

在 上一篇文章 中, 我們大致介紹了在 near-RT RIC 中和 E2 介面相關的單元, 包含了: xApp, Subscription Manager (SubMngr), Routing Manager (RMR), E2 Termination (E2T). 在這一篇文章中, 我們將繼續介紹 E2 介面的訂閱流程, 我們從上次的流程圖出發: 在這張流程圖中, 我們可以看到上述五個裝置的互動, 以及交換的訊息, 其中, 一開始 xApp 和 SubMngr 先透過 RESTful API 進行註冊與確認, 訊息格式如下: 在向 SubMngr 註冊的資訊中, 包含了以下的資訊: SubscriptionId: 此 ID 為 xApp 產生, 但不代表此次訂閱, 真正數值由 SubMngr 產生並回填. ClinetEndpoint: 提供給 RMR 的資訊, 包含 hostname, RMR port Meid, RANFunctionID: 和訂閱的 E2 Node 相關 E2SubscriptionDirectives: RMR 參數設定, 非必要 SubscriptionDetails->XappEventInstanceId: 真正的 xApp 產生的 ID, xApp 以此識別訊息 SubscriptionDetails->ActionToBeSetupList: 要透過 E2 介面進行的操作 當 SubMngr 收到註冊資訊, 會進行回報, 其中, 帶有兩個重要的資訊: SubscriptionId: 若成功回傳, 則用以代表此次註冊 E2EventInstanceId: 此 ID 用以建立 E2 連線 (如果需要), 也是後續 E2T 回報時的 ID 我們可以看到, 在 E2 資訊架構中, 註冊與資料傳輸是分開進行的, SubMngr 負責註冊, 並代理產生 E2EventInstanceId 向 RMR 和 E2T 溝通, 溝通完畢 (建立 E2 Node 至 xApp 連線後), 會以 Subscription Notification 方式告知, 其格式如下: 透過上述的資訊來回, xApp 獲得以下資訊: XappEventInstanceId: xApp 所給予的識別 ID, 用以判斷發起方 Subscriptio...

簡單記錄一下在 ubuntu 上進行時間同步的方法, 主要遇到的問題是在多台機器上架設叢集, 為了進行資料庫的存取, 需要同步一下系統的時間, 因此, 簡單記錄一下設定的過程: 1) 安裝並設定 ntp, ntpdate $ sudo apt-get install ntp ntpdate 2) 手動進行 ntp 對時, 更新系統時間 $ sudo ntpdate time.stdtime.gov.tw $ sudo hwclock -w # 若是需要更精確地同步時間, 可以透過設定 ntp 服務, 定時對時 # 可以參考:  https://blog.gtwang.org/linux/linux-ntp-installation-and-configuration-tutorial/ 3) 更改時區 (timezone) # 基本上, 對時完之後的時間對應的是 UTC 時間, # 程式執行時, 則是使用 local time, 對應到 timezone 的設定 首先, 我們先看一下當下的設定, 指令為: timedatectl 在設定中, 我們可以看到 timezone (Local time) 為 CST (Central Standard Time), 但是, 在設定時標準的格式為: 洲/城市 (Asia/Taipei), 我們可以透過指令, 查詢適合的設定: $ timedatectl list-timezones 最後可以以下列指令更新 timezone 的設定: $ sudo timedatectl set-timezone <your_time_zone> 詳細的可以參考:  https://linuxize.com/post/how-to-set-or-change-timezone-in-linux/ 

E2 介面目前是 O-RAN SC 開源軟體中定義比較完整的一塊, 為了進一步了解 E2 介面的運作方式, 我們將研讀相關的內容, 主要參考自: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-submgr/en/latest/user-guide.html 在 near-RT RIC 平台中, O-RAN SC 花了很多精神在這部分實作, 相關的套件包含: xApp, Subscription Manager, Routing Manager, E2 Termination. 其中, xApp 為 E2 介面資料交換的發起端, 可以向 E2 Node (O-CU, O-DU, O-eNB) 訂閱以下四種類型的 E2 Node 服務: REPORT, INSERT, CONTROL, POLICY   (目前已實作 REPORT, CONTROL, POLICY 三種服務) E2 Termination (E2T) 為 E2 介面在 near-RT RIC 上的入口, 負責接收來自 E2 Node 的各式訊息, 並透過 Routing Manager (RMR) 回報給 xApp. Subscription Manager (SubMngr) 則負責管理 E2 Node 服務的訂閱, 當不同 xApp 向 E2 Node 做出重複的訂閱時, SubMngr 不會重複發送訂閱需求, 而是向 RMR 和 E2T 溝通, 直接建立新的 E2T 和 xApp 連線.  當 xApp 發起 E2 需求時, 並不是直接發送給 E2 Node, 而是透過 RESTful API 發送給 SubMngr, 發送的訊息中, 帶有自己的 xApp ID, 以及多個 E2 Node 服務需求, SubMngr 會依序, 透過佇列, 進行處理, 並和既有的 E2 Node 服務整合. 在 near-RT RIC 的架構中, SubMngr 實際上管理了 E2 Node 與 xApp 的所有連線, 因此, 對於每一組 E2 Node 服務訂閱, SubMngr 給予一組獨特的 ID (InstanceId), 此 InstanceId 可以讓 xApp 用以判斷 E2 Node 回報的資訊, 除了 Insta...

在 上一篇文章 中, 我們介紹了 AI/ML 的大致流程, 其中, 我們可以看到 AI/ML 程式的不同布署位置 (例如: near-RT RIC, non-RT RIC), 在這篇文章中, 我們將說明不同布署位置的原因, 以及其設計準則, 在 O-RAN 的架構中, 控制的流程分成三個層級: O-DU, near-RT RIC, non-RT RIC, 分別對應於: <10 ms, 10 ms~ 1 sec, >= 1sec, 三個不同的時間等級. 針對不同應用的即時性需求,  會產生不同的資料回報速度, 以及相對應的計算即時性需求. 針對計算的即時性需求, 則會衍伸出運算能力的需求, 與硬體的限制, 在這裡, 我們會發現, 即時性的需求與運算資源的能力, 正好是相悖離的, 舉例來說, near-RT RIC 通常實作於 edge server, 只有有限的運算能力, 卻要負荷小於一秒的即時運算響應. 相較之下, non-RT RIC 通常有較高的運算能力, 但在企業專網的應用中, 可能沒有深度學習訓練網路時所需要的特殊硬體 (如: 高階 GPU 顯卡). 因此, 在 O-RAN 的設想中, 就針對這樣的限制, 提出一些想法, 例如在 Scenario 1.2 中, 可以利用 non-RT RIC 用以訓練多個 ML/AI 模型, 並在 near-RT RIC 中收集即時的量測回報, 根據回報執行 AI/ML 的運算, 當環境改變時, 這些即時回報也可以上傳給 non-RT RIC 進行模型的訓練, 或是透過 A1 介面, 通知 near-RT RIC 切換使用的 AI/ML 模型. 相對 Scenario 1.2, Scenario 1.1 是一個簡化的架構, 當響應需求的即時性不高時, 可以將所有的運算 (訓練/執行) 都放在 non-RT RIC 上, 此時, near-RT RIC 的角色就像是一個代理者, 負責資料的收集與控制指令的傳遞. 在 AI/ML 的設計中,  可以看出來 O-RAN 對於如何將 AI/ML 落實於電信網路有許多的討論, 然而, 到目前為止 (v1.02版) 似乎仍有許多待定項目, 我們就先在此暫停此系列討論, 若之後有更豐富內容, 再進行更新.