發表文章

目前顯示的是有「RIC」標籤的文章

O-RAN Traffic Steering xApp 相關網路功能組件介紹

圖片
由於在 O-RAN 架構中 Traffic Steering(TS) 的實現主要交由 RIC 來處理,本文將簡介 O-RAN 負責實施 Traffic Steering 的網路功能元件們,它們的職權有什麼? O-RAN Traffic Steering xApp 簡介 Traffic Steering(TS) xApp 是部屬於 O-RAN RIC 平台上的應用程式。電信業者會使用 TS xApp 來引導流量,並且優化其服務的終端裝置(UE)在跨不同網路環境移動時的換手,但並非僅需考量基地台間的換手,同時也要考慮 NAT (如:4G,EN-DC NSA,5G)以及接入的頻段和載波,藉由讓 UE 或是網路切片組,能接入最合適的網路,來提高網路使用效率,並確保終端用戶通訊品質,總而來說,下世代通訊的 TS 設計已然成為一項挑戰。 > 電信業者對於特定類型的用戶終端,會有不同的無線電資源分配策略 Traffic Steering 操作時主要涉入的網路功能元件 執行 TS 時主要涉入的網路功能元件(實體) TS 相關網路功能組件工作職權 Non-RT RIC 制定策略指導 :Non-RT RIC 提供一種聲明式策略,用於指導 Near-RT RIC 中的 TS xApp 及相關 xApps。(舉例:提供一種優化策略,引導基站的載波/頻段的服務特定 UE 或網路切片)。 資料雙向協調 :提供 Near-RT RIC  豐富資料(Enrichment Information) ,用以輔助 TS 功能,同時也將測量配置參數傳輸給 RAN node。 (豐富資料:基於 UE 測量報告  Measurement Report(MR)  的  RF fingerprints ,像是正在服務中的Cell / 相鄰 Cell,它們的 RSRP/RSRQ/CQI 資訊。) 看不懂的專有名詞這邊有介紹: https://hackmd.io/@thc1006/B1pLKMAUh Near-RT RIC 解譯並執行 Non-RT RIC 傳來的策略。 使用 Non-RT RIC 提供的豐富資料,來優化 TS 和 其他 xApps 控制功能。 E2-Node 收集 E2 node 上 (O-eNB、O-CU、O-DU) 的細粒度資料,並藉由 O1 介面傳輸...

O-RAN Y1介面簡介

圖片
一句話介紹:這是 O-RAN 新增的介面(2023/03),允許 Y1 consumers 訂閱或請求 Near-RT RIC 提供的 RAN 分析資訊 (RAN analytics information)。 圖(一) O-RAN Y1介面(圖中紅框處) O-RAN Y1介面功能介紹: Near-RT RIC 透過 Y1 介面,提供 RAN 分析資訊 (RAN analytics information) 的服務,而 Y1 consumers 可以藉由訂閱或請求 RAN 分析資訊 ,來使用 RAN 分析資訊 服務。 當 Y1 consumers 在 O-RAN 可信域 (Trusted Domain) 時,可以作為應用程式功能 (Application Functions,AFs);或  RAN 分析資訊 可以透過網路曝光功能 (Network Exposure Function,NEF) 以安全的方式提供給 (Application Functions,AFs) 速記:在 O-RAN Trusted Domain 時 , Y1 consumers == (Application Functions,AFs) 安全的網路曝光方式(NEF) 詳見:3GPP TS 23.501, Clause 5.20 (External Exposure of Network Capability),連結如下: Release 17:  https://reurl.cc/ml7Y6W Release 16:  https://reurl.cc/7RnV2y 秀吉 MurMur: Y1 consumers  使用 RAN 分析資訊 服務,出發點一定是好的啦~,得以提供不同情境的使用者裝置更適合的服務,但 新介面的出現,同時也意味著新的資安威脅,學術界又有新的研究領域了(誤 綜觀 O-RAN 的高級架構 (High Level Architecture;HLA)   圖(一): 圖(一) 顯示 O-RAN 架構中主要的四個介面 (A1、O1、Open Fronthaul M-plane、O2)。 SMO(服務管理和編排)透過 A1、O1、Open Fronthaul M-plane 連結 O-RAN Network Func...

聯邦學習結合O-RAN 開放基站的發展與展望

圖片
雖然本文打的可能會稍微得過於“在烏托邦紙上談兵”,但是我還是覺得聯邦學習結合 O-RAN 超有前景,適合應用在有 Diversity UEs 的專網! (像是醫院場域,ICU 需要高頻寬量的 video surveillance、又需要 NB-IOT 的穿戴式裝置) BTW: NB-IOT 在 5G 稱為 Redcap 標準 看了一些聯邦學習 (FL) 用於通訊的論文,瞭解聯邦學習的一些痛點 UE 端的算力不一,加上連線狀態不穩定,有高延遲問題 每個 UEs 的資料異質性 (Heterogeneity) 太大(因為使用者的習慣都不一樣),造成聚合伺服器 train 出來的 model 不能用。 Attck 資安問題(UE 傳送惡意資料給伺服器,來搗亂伺服器的 model) 有關 藉由逆向工程 擷取 gradient 或是 paramerter 來反推用戶資訊,這部分我還沒有相關 Solution 或想法 因為由於聯邦學習的隱私保護,我們無法知道 UE 回傳給聚合伺服器的 gradient 是否為惡意。 但是關於要阻止 UE 傳輸惡意資料, 我們一開始就先做 UE 認證~ UE 要接取 O-RAN 的 5G 訊號,就會需要 SIM 卡,那如果先做 SIM 卡/ eSIM+ 裝置認證 , 讓認證的裝置才能擁有 5G 網路接取權。 然後 UE APP 跟 MEC APP(就是 UE APP 跟 MEC Platform 當中的 Servise registry 和 traffic rules control App 進行認證和授權) 圖源: https://devopedia.org/multi-access-edge-computing 然後其實 UPF 後端還可以再防一層,讓 SMF 和 PCF 來控管數據流,沒通過認證的 UE 或 App 無法 Access MEC 及其後端服務。 (這部分可否用於聯邦學習待研究,因為聯邦學習隱私源則,我們無法得知 gradient 是否為惡意,但是是可以擋一下搗亂聚合伺服器 model 的 DDoS 攻擊,應該是沒問題的) 聯邦學習的痛點是什麼?UEs 系統異質性太大(系統算力不一、有人傳很快、有人低延遲)的問題嘛! 如果我們進行了 UE 認證,所以 MEC 就知道它下面註冊了哪些裝置, 那我們都知道 O-RAN RIC plat...

O-RAN Near-RT RIC 介紹

圖片
Near-RT RIC 概述 是開放基站(O-RAN) 架構中,專為網路智慧化而設計創新元件,用於促進無線電資源管理(RRM)。 支援第三方控制應用程式 xApp 部屬。 藉由收集 E2 介面提供的數據,透過 Non-RT RIC 提供 Near-RT RIC 的網路資源智慧分配 AI/ML模型以及 Policy,來進一步優化 RAN(如: RAN 對網路元件(elements)的即時控制、即時網路資源分配智慧化。)達成 QoS 管理、連接管理和無縫切換(handover)控制 Near-RT RIC 架構圖 圖源: O-RAN.WG3.RICARCH-v03.00 基本上所有實體 (CU, DU, eNB) 都可以作為 E2 節點 (E2 Node)。 O-RAN 架構兼容 5G 和 LTE。所以這邊要注意,此處顯示的 E2 Node 的定義包含 CU/DU (5G NR) 以及 LTE eNB (O-eNB) 5G NR 系統中,基地台稱為 gNB(Next. Generation Node B) LTE 系統中,基地台稱為 eNB(Evolved Node B) RIC 部屬位置 非即時智慧控制器(Non-RT RIC),被部屬在服務管理與編排(SMO) 當中。 近即時智慧控制器(Near-RT RIC),部屬在歸類於網路邊緣(edge of the network) 的部分,通常歸類在和 CU 在同樣的位置。 圖源: https://arxiv.org/pdf/2202.01032.pdf 圖源: Near_RT_RIC_for_ONS (PDF) 可以看到兩個 RIC 部屬的位置是不同的 Near-RT RIC 位在圖中央 REC(Radio Edge Cloud) 的地方 Near-RT RIC 閉迴路控制(Control Loop Control) 這項功能引入了數據驅動(data-driven)的閉控制,可以自動優化網路資源和 RAN 的切片、負載平衡、切換、調度策略(Policy) 等…,這項功能實現了網路智慧化。 Near-RT RIC 閉迴路的決策時間週期為(10ms-1s) Near-RT RIC 通常會連結多個 RAN Node,因此閉控制會影響成百上千個用戶設備(UE) 的 QoS。 Near-RT RIC 介面 A1介面 :SMO 當中...