Castle on a Cloud

本文所指的 RIS 通道模型, 參考自以下論文:  H. Zhang et al., "MetaRadar: Indoor Localization by Reconfigurable Metamaterials,"  in IEEE Transactions on Mobile Computing, vol. 21, no. 8, pp. 2895-2908, 1 Aug. 2022 在 上一篇文章 中, 我們介紹了如何投過訊號的疊加建立一個訊號強度模型, 此模型基於每一個 RIS 元件狀態對於固定位置的訊號變化, 並將各 RIS 元件狀態導致的訊號差異進行疊加作為最終的訊號模型. 在這一篇論文中, 除了提出並驗證此訊號強度模型之外, 另一個值得注意的成果就是透過實驗的訊號量測,  對於 RIS 的反射訊號強度進行各種實驗與分析, 並提出目前 RIS 的實作限制. 先從結論說起, 此 RIS 通道模型的限制大致上可以分成下列 3 項: 多裝置之間的干擾: 多個定位目標, 將導致新的 multipath 效應, 影響收到的訊號強度 在實驗中, 越多裝置在目標區域內, 通道模型的誤差上升, 同時, 遮蔽相對 RIS 的 LoS 的影響 (裝置沿入射方向擺放) 非常顯著. 距離對於通道場型的影響: 根據實驗結果, 訊號強度的變化隨著和 RIS 間的距離上升而下降, 在 3 公尺後, RIS 在目標量測空間中的效果就不顯著. RIS 的物理限制 (窄頻): RIS 的設計對於操作頻率很敏感 只可以操作在極窄的頻帶上 (本篇論文只使用單一頻率作為訊號源) 除了第三點之外, 我們以下以 RIS 的不同實驗作為說明, 在這篇研究中, 討論的是定位的問題, 因此, 實驗的統計結果的是定位的誤差, 不過, 考慮到定位中參考的資訊就是接收的訊號強度, 定位的結果也可以延伸為 RIS 對於通道產生的影響強度. 實驗一: 不同距離的訊號強度差異 在此實驗中, 測試在不同距離 (1, 2, 3 公尺) 處 RIS 對通道產生的變化, 其中, 有兩個測試結果值得注意,  第一, 在右圖 (c) 比較了訊號源為指向性天線和全向性天線的定位結果, 可以看到全向性天線 (有直視路徑到接收立方) 的定位結果較差, 這也代表 RIS 在有其他直視路徑時, 能夠藉由...

本文所指的 RIS 通道模型, 參考自以下論文:  H. Zhang et al., "MetaRadar: Indoor Localization by Reconfigurable Metamaterials,"  in IEEE Transactions on Mobile Computing, vol. 21, no. 8, pp. 2895-2908, 1 Aug. 2022 在上一篇文章中, 我們介紹了 RIS 的實作, 也說明了用以建立 RIS 通道模型時的各種變因, 作為結論而言, 在目前的實作限制下, 我們的確可以透過 RIS 改變通道, 但考慮到入射的相位無法控制, 以及入射角度無法控制的前提下, 我們無法像是 beamforming 一樣, 準確的調控反射訊號的方向響應. 若我們考慮的是接收的訊號強度, 此問題就變得更加困難, 因為所收到的訊號不只是來自於 RIS 反射,  同時還包含了直視路徑 (訊號較強), 以及其他的反射訊號 (多路徑效應). 考慮到上述的問題, 這篇文章以一個實驗驗證 RIS 對通道的影響, 實驗環境圖如下所示: 在其實驗環境中, 我們可以看到一些特殊的設計: 1) 使用指向性天線 (horn antenna) 對準 RIS 產生一個方向固定, 能量集中的訊號. 2) 避免訊號源和量測區域 (綠色立方) 有直視路徑. 3) 量測區域 (綠色立方) 和 RIS 相距 1 公尺, 以無線傳輸而言, 算近距離 4) 量測立方中, 每一點距離相距 5 公分, 代表 RIS 反射在小區間內變化 基於上述的實驗環境, 論文作者假設每個 RIS 反射單元的變化是可疊加的, 換句話說, 相對於一個相同的基準 (例如: 所有 RIS 單元都在初始狀態), 我們可以個別調動每一個 RIS 單元的狀態, 量測其和基準的差異, 作成紀錄. 而通道的接收訊號模型, 也就表示為基準加上每一個 RIS 單元產生的差異的總和. 下圖則是其驗證的結果:   在圖中, 我們可以看到針對不同的設定 (RIS 單元操作於不同狀態), 根據訊號強度疊加所重建的訊號強度和量測值吻合, 不過需要注意的是, 其表示數值的單位為 Watt, 而非常見的 dBm, 若是換算成 dBm 的單位, 在上圖左中的 1 Watt 和...

本文所指的 RIS 通道模型, 參考自以下論文:  H. Zhang et al., "MetaRadar: Indoor Localization by Reconfigurable Metamaterials," in IEEE Transactions on Mobile Computing, vol. 21, no. 8, pp. 2895-2908, 1 Aug. 2022 在上一篇文章中, 我們討論了一個理想中的 RIS 通道模型, 事實上, 同一個研究團隊在之後也有了 RIS 的系統實作, 比對同一團隊的兩個不同研究, 我們可以更好的了解 RIS 在理論與實作上的差異, 並進一步的了解 RIS 在系統實作與操作上遇到的挑戰. 首先, 我們從 RIS 的硬體實作開始: 上圖描述了 RIS 的系統實作模型,  和理想的通道模型相比, 我們發現幾個差別: 有限且固定的 RIS 元件個數 (上圖為 16 個), 同時無法準確對應於所以反射路徑 RIS 元件需針對操作頻率 (3.2 GHz), 入射相位 (60, 90) 進行設計 設計後的 state 有限, 以此篇實作而言, 數量只有 4 個 RIS 整體反射板的大小偏大, 在實作中, 每個元件就 17 公分見方 考慮到上述的限制, 在這一篇實作的模型中, 所使用的 RIS 通道就改成以下的形式: 和上一篇的理想通道模型相比, 最大的差異是加入了未經 RIS 的 NLOS 路徑, 其中, RIS 的影響被放在 r(\phi^I, \phi^R_m, c_m) 的項次中,  代表的是 RIS 在某一設定 (c_m) 下, 針對給定入射相位 (\phi^I),  所產生的反射相位改變 (\phi^R_m), 此數值隨 RIS 的設定改變, 至於在此篇論文中, 4 個狀態所對應的相位改變設計數值, 可表示如下表: 相較上述和入射相位相關的通道模型, 在論文中只給出了入射-反射間的相位差,  考慮上下文的相關資訊, 此數值應該是在入射相位為 60 與 90 度所做的設計, 不過, 本文並未告知若入射相位偏離設計值所帶來的影響. 讓我們回到系統實作的通道模型,  事實上, 我們可以發現, 這個通道模型在模擬訊號強度上沒甚麼用.... 就算我們擁有 RI...

本文所指的 RIS 通道模型, 參考自以下論文: H. Zhang, H. Zhang, B. Di, K. Bian, Z. Han and L. Song, "Towards Ubiquitous Positioning by Leveraging Reconfigurable Intelligent Surface," in IEEE Communications Letters, vol. 25, no. 1, pp. 284-288, Jan. 2021 為了對 RIS 的系統進行分析, 首先, 我們要賦予其通道的模型. RIS 的通道模型是基於光線追踪模型 (ray tracing model), 在此通道模型下, 將接收端所收到的訊號表示成許多路徑的疊加, 按照其路徑的特性, 又可以分成 LoS (直視) 與 NLoS (非直視) 路徑, 透過上述假設, 我可以把通道模型描述如下: 在此通道模型中, c 代表的是位置的資訊, 接收的訊號表示為傳送的功率, 扣去來自路徑的衰減 (path-loss), 在 path-loss 的項次中, 又可以分成三項:  h_lo (直視路徑的通道), h_m,n (非直視路徑的通道), \xi 則是遮蔽效應的衰減, 我們可以把詳細的資訊如下: 其中, 我們先看 h_lo (直視路徑的通道),  在 RIS 的通道模型中, 直視路徑的通道不經過 RIS,  因此, 這項次就是一般的路徑衰減形式, 可以進一步分成兩項: 1. 強度變化: 包含傳送與接收端的增益, 以及在分母項的距離 (l), 2. 相位變化: 在 exp 項次內, 代表訊號的相位改變, 和距離 (l) 和波長 (\lambda) 相關 而在 h_m,n (非直視路徑的通道), 除了直視路徑的項次外, 也加入了 RIS 的對於相位的影響 (r_m(c_m)). 在 RIS 的通道模型中, 假設一個 RIS 反射板有 M 個 RIS 區塊, 每一個 RIS 區塊對應於一條反射路徑, 可以透過調整 C 個 RIS 元件, 來改變 RIS 所對應的通道變化, 如下所示: 在可以調整的項次中, 包含兩項:  Configuration ( c ): 代表的是 RIS 區塊的設定, 對應於相位變化 ON/OFF S...

在 5G/6G 的新通訊發展中, 有許多新的概念被提出, 當然, 也有很多曾經火紅的研究議題失寵, 今天要介紹的技術是 Reconfigurable Intelligent Surfaces (RIS), RIS, 也有人稱為 Intelligent Reflecting Surfaces (IRS), 其基本的想法就是: 透過一個可控制的反射平面, 改變訊號在不同方向的反射強度, 我們可以用下圖來表示其基本想法: 來自:  https://www.free6gtraining.com/2020/12/communications-using-intelligent.html 在上圖中, 介紹了 RIS 的基本構件以及基本的原理, 首先, RIS 是一個智慧反射平面, 其功能只限於電波的轉傳,  因此不帶有發送源 (Transmitter), 真實的傳送端位於左下角. 而接收端 (user 1, user 2) 則散布於此空間中,  透過直視 (LoS) 或是反射 (NLoS) 路徑, 接收來自於傳送端的訊號.  RIS 的目的就是透過改變反射訊號 (NLoS) 的通道特性,  改善接收端 (user 1, user 2) 的接收訊號強度. 如果只透過被動反射, RIS 如何改變反射訊號的通訊強度呢? 在上圖, 我們可以看到 RIS 為許多小型元件所組成. 每一個元件可以透過: 1) 改變阻抗, 2) 改變延遲, 3) 改變相位, 的方式m 等校上, RIS 可以對來自於遠場的電磁訊號 (遠場: 射線平行的來自於遠方),  進行反射時每一個射線 (ray) 的相位調整. 此處的調整, 則是透過控制器 (controller) 對 RIS 下達 configuration 達成. 而正如同我們之前在 beamforming 中所看到的, RIS 相當於一個被動的大型天線陣列, 雖然沒有主動的訊號源, 但是可以透過對反射訊號的相位設計, 達成對某一方向上訊號的增益. 這也是 RIS 這個想法讓無線通訊領域驚豔的原因. 在過去, 無線通訊主要透過改變傳送端和接收端的行為, 來增進整體通訊所達成的效能, 而通道, 通常是我們所必須克服的困難, RIS 則開啟了一扇"改變通道"的大門, 使無線通訊...

在 LTE 系統中, 支援了多種不同的傳輸方式, 透過多天線的傳輸, 與編碼技術, 用以增加傳輸的速率, 考慮到不同的技術, 就有不同的量測信號需求,  因此, 在 LTE 系統中就以不同的傳輸模式 (Transmission Mode, TM) 作為區分, 其中, 主要的兩項技術為: 透過 code book 的選擇進行 MIMO, 或是透過 phase shifter 和振幅的調變, 進行 beamforming, 基於 Rel. 12 的基準, 我們把 Transmission Mode 的表格與相對技術, 列於下表: 來自:  https://www.rohde-schwarz.com/ae/file/1MA186_2e_LTE_TMs_and_beamforming.pdf 在表中, 我們可以看到 TM 可以大概分成 4 類: TM 1: 原本全向性天線的傳輸 TM 2~6: MIMO 的通訊技術 TM 7~8: Beamforming 技術 TM 9~10: 8x8 MIMO/Beamforming 設計 其中, 需要注意的是第三個欄位,  顯示了 antenna port, 對應於不同的天線埠, antenna port 0~3 對應於真實的天線 0~3, 對應於 TM 1~6, 此部分是比較傳統的設置, 不同 port 的數值對應於不同的 RS (參考訊號), * 關於 RS 的部分, 我們會在下一篇文章中說明. 在 TM 1~6 的設計中, 每個 UE 接收基地台不同實體天線的訊號, 並回報估測通道. 至於對於 Beamforming 的 TM 7~8, 由於天線場型已被改變, 因此, 此處的參考訊號是針對每一個 UE 設計 (稱為 UE-RS), 在 UE 回報時, 也是針對不同的 Beamforming 場型設計進行回報. 考慮到此處的天線已經過 Beamforming 的調整,  因此, 在 TM 7 中, 對應到 antenna port 5 (作為一個虛擬的天線). 在 TM 8 中, 則可以把 8 根天線分成兩組, 分別進行兩次 Beamforming, 對應於 antenna port 7 和 8, 此兩組天線可對應於單一 UE 或是 2 個 UE. 延伸自 TM 8 的設計,  TM ...

在 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...

在未來 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版) 似乎仍有許多待定項目, 我們就先在此暫停此系列討論, 若之後有更豐富內容, 再進行更新.  

在之前的文章中,  我們介紹了 O-RAN 的 設計想法 , 以及 基本的組成元件 , 在這一篇文章中, 我們將繼續介紹 O-RAN 上的布署方式與資料流程. 我們先從資料流程開始, 可以用下圖總括說明: 相較於之前介紹的 5 大元件, 此圖中省略了 Model Compiling Host, 同時, 在流程中, 加入了 Continuous Operation 的功能方塊, 其定義為: Provides a series of online functionalities for the continuous improvement of AI/ML models within the whole AI/ML lifecycle. It includes Verification/ Monitoring/ Analysis/ Recommendation/ Continue Optimization. (在元件介紹中, Continuous Operation 在主要的資料交換流之外, 只提供效能反饋) 我們先不論為何兩者為何不一致, 但 Continuous Operation 的確可以提供很多功用, 在不考慮 online learning 下, Continuous Operation 可以透過即時的反饋進行 Model 的選擇, 此功能表現在 Continuous Operation 和 Model Management 的連線上, 在考慮 online learning 時, Continuous Operation 可以提供即時的系統效能反饋, 用以進行像是 Reinforcement Learning 這種可以隨著時間動態調整的 ML 框架. 在圖中, 另一個重要的區分為, Actor 所執行的 Action 明確分成三類: Configuration management over O1, subjects of actions: near-RT RIC, O-CU, O-DU/O-RU Control Action/ Guidance over E2 subjects of actions: O-CU, O-DU/O-RU Policy over A1, E2 subjects of actions: nea...

和 3GPP 不同, O-RAN 的標準並非兩階段的定義 (Study->Spec), 同時, 可能是因為組織相對沒有 3GPP 那麼龐大, 在 Spec 內容的呈現上, 出現許多像是在討論階段的文字, 例如, 在 AI/ML 這份討論中, 就說明了其想像的 AI/ML 設計準則. 這樣的文字, 因為過於模糊, 在 Spec 中其實不太適合, 但是反過來說, 也提供一種像是立法依據的角度讓我們了解 O-RAN 組織的想像. 以下就是 AI/ML 的設計準則, 會呈現原有的原文, 以及翻譯理解的內容: Principle 1: In O-RAN we will always have some offline learning as a proposed best practice (even for reinforcement learning type of scenarios). In the current document, offline training means a model is first trained with offline data, and trained model is deployed in the network for inference. Online training refers to scenarios such as reinforcement learning, where the model  ‘learns’ as it is executing in the network. However, even in the latter scenario, it is possible that some offline training may happen. [準則1] 在 O-RAN 中所有的 ML model 都應該被預先訓練過 (offline learning), 就算是 reinforcement learning 這種以即時反饋來進行學習的架構, 都應該先以預先收集的資料進行模型的學習.  [註] 這一條準則應該是因為 O-RAN 架構中, 實際的 Action 會影響一真實網路的通訊效能, 因此無法容忍一個尚未收斂的網路進行布建. Principle 2: A m...