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 中進行回報, 共享 RIC SUBSCRIPTION REQUEST 設定, Control 訊息和 Indication-Insert 訊息

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