[ORAN] Use Case: WG1-Traffic Steering

在 ORAN 的 SPEC 中, Use Case 的說明主要在以下三個文件:

其中, WG1-Use-Cases-Analysis-Report 範圍最廣, 定義可行的應用情境,

WG1-Use-Cases-Detailed-Specification 定義需求與基本的資料流,

WG2-Use-Case-Requirements 則進一步討論不同佈建下的實作, 更接近實際場景,

在應用案例的數量上, 因為 ORAN 採取的是並行的策略,

定義完成的應用情境, 也隨著要求細節的增加而逐漸減少,

我們先以三份文件中都出現的 Traffic Steering 為範例:

在 WG1 的討論中, 會將一個 Use Case 分成 4 項討論:

針對以上四點, 我們從 WG1 文件中整理出以下說明:

對於 Traffic Steering 而言, 其目標考慮的不只是換手與移動性問題,
還考慮在不同無線介面 (NR, LTE, WiFi) 之間的切換,
並考慮了各節點在不同負載下, 如何透過預先資源配置, 確保通訊品質.
為了達成上述目標, 需要 Non-RT RIC, Near-RT RIC 以及 E2 Node 參與,
其中, Non-RT RIC 負責產生 policy 予 Near-RT RIC 執行,
而 E2 node 則負責資料收集, 以及換手功能的執行
Non-RT RIC 透過 O2 介面定期取得系統效能的參數, 並發起 Traffic Steering,
當發起 Traffic Steering 後, 會再次收集資料, 運算出適合的 policy,
並將 policy 透過 A1 介面傳送給 Near-RT RIC 來執行 (如下圖)
為了完成上述功能, E2 Node 需要量測 UE 所聽到的 RSRP/RSRQ/CQI 資訊,
若是支援不同無線介面的切換, 則也需實作 inter-RAT 的量測,
為了平衡負載, 基地台也必須能回報其服務的使用者數, 資源使用率等資訊,
同時, 作為系統效能的標準, 也需要 UE 的換手成功率, 延遲與網速等資訊.

來自: O-RAN.WG1.Use-Cases-Detailed-Specification-v04.00

雖然從技術的觀點出發, 我們會先從元件與介面開始了解 ORAN,

但對於一個通訊協定而言, 除了要定義網路中的元件與資料介接的介面外,

也要定義此通訊協定的應用情境, 以及達成這些應用情境的技術需求,

作為此通訊協定的示範.

事實上, 在進行通訊協定的定義時, 順序通常相反,

以 3GPP 為例, 是從應用出發, 進一步定義技術規格,

最後再讓大家集思廣益, 提出各種方法, 以完成規格所列的需求,

當然, 這也造成了某種程度的不一致性,

以定位技術而言, 3GPP 在應用討論時的需求與技術規格定義就有落差,

更不用說最終如何在現實條件中到達目標的定位精確度,

這也是我們在看 SPEC 時要注意的部分.

讓我們回到 ORAN 的問題, 在 ORAN 中, 應用情境式和技術一起定義,

一方面, 是因為框架已定 (5G NR), 只剩下附加功能的撰寫,

另一方面, 也是因為其嚴謹度不如 3GPP, 留下較多廠商差異化空間,

因此, 其應用 (Use Case) 也就依賴廠商對於 E2 Node 的功能支援,
或者, 反過來說, 唯有透過 Use Case 的要求, 才能驅使硬體廠商在 ORAN 架構下,

更加開放其硬體的設定, 並將開放性形成各式應用情境支援的賣點.

Castle on a Cloud