O-RAN 科普教育

本文整理並逐一說明目前電信產業雲原生轉型，可能會面臨到的眾多挑戰，此外，說明為何電信產業已經引入了雲原生技術，卻仍舊無法真正地享受到雲原生轉型所帶來的各項好處。期望鼓勵更多莘莘學子投入 O-RAN 領域研發新議題，以助我國在半導體領域之外，再創國際新巔峰！ Cloud RAN Automation 發展的現況和議題 1. 命令式機制在 RAN Automation 中的缺點 目前，要實現 RAN Automation，會需要先制定用於優化 Policy 以及觸發執行 Policy 的門檻(threshold) 。這些 Policy 可以用來自動調整 Network Function 的 Configuration 參數，以俾提高網路的效能，或讓佈署在 O-Cloud 上的 NFs 可以根據資源的負載狀況自動進行 scale-out、scale-in。 但由於目前的 NFs 仍是採用經典的 CNF、VNF，因此需要撰寫 helm chart 或 docker compose 來執行用於優化 Policy。然而，helm chart 和 docker compose 這些工具都還屬於命令式機制(imperative programming)，這是一種開發人員早已制定好，明確要求 RAN 需執行的步驟，而非根據即時情況自動做出的決定；綜合以上所述，我們了解目前要實現 RAN Close loop Automation ，可以說是非常繁瑣。 2. 採用 Helm chart 部署 RAN 的侷限性 使用 Helm chart 部署 O-RAN 時存在一些侷限性。例如 Helm chart 的可重複利用率較低，因為它通常是針對特定使用場景來定制的，而且通常只會在 Day 1 部署時使用。而 RAN 這種東西，是需要長期維護的，而且部署在不同的使用場景(Scenario) 的 RAN，就必須有不同的 Helm chart，並且當服務需要升級時，就還會需要使用另一組 Helm chart 來進行升級和管理。 以台灣任一電信業者為例，它們通常會需要佈署大量的 RAN（基地台）在不同地點，因此僅 Day 1 的部署就會生成大量的 Helm chart。並且隨著時間的推移，管理和維護這些 Helm chart 的成本都會變得非常高昂。 用熱力學的概念來總結的話，就是說，想用 He...

隨著新世代行動通訊技術標準的不斷更新，為了追求更高的網路速度、更大的網路容量，適應更複雜的使用場景，同時還須兼顧設備成本、APRU 和敏捷性管理，電信網路架構的演進，引入了DevOps 概念。一路從 核心網路 (Core Network；CN) 開始著手，緊接著是 無線電接取網路(Radio Access Network；RAN)，開始了一連串的開放原始碼、虛擬化，甚至是全雲原生 (Cloud-Native) 的遷移之旅。 電信網路產業朝向全雲原生的轉型已經開始（圖源：自製） 開放式無線電接取網路 (O-RAN) 的出現，驅動下世代行動通訊技術的高速發展，藉由其標準化的開放介面、新增支援 AI/ML Workflow 的 RAN 智慧控制器 (RIC) 、支援雲原生網路功能的部屬等…創新技術，為下世代電信網路管理帶來了新的機會，有望翻轉傳統電信生態圈。而其中「支援雲原生網路功能部屬」，也意味著 Cloud RAN 時代即將來臨，雲原生網路功能 (CNF) 儼然成為一種趨勢。 雲原生網路功能(CNF) 部屬帶來許多新機會的同時，也意味著我們也即將面臨新的電信資安挑戰。過去面對IT與OT的資安攻防，好厲駭學員早已做好備戰準備，但是現在新型態 CT (Communication Technology) 通訊資安的挑戰即將來臨，試問台灣好厲駭學員該如何處置，就讓我們接著看下去！ 雲原生技術帶來的優點與資安威脅 近年來，雲原生技術的應用逐漸興起，不僅帶動了產業界的發展，雲轉型的概念也衍生了許多的商業機會，許多產業界紛紛投入大把資金，期望藉由引入雲原生技術以俾產業轉型順利，雲原生已然成為一股潮流! 承如前段提及，電信網路功能往 Cloud-Native 的過渡已經開始，那麼網路功能在雲原生的過程，勢必會面臨一些既存的 虛擬化/雲原生 資安威脅。 因此本專題海報將針對於 O-RAN O-Cloud 以及部屬在其上面的雲原生網路功能(CNF)，可能會遇到的 Migration Attacks 資安威脅進行說明，並提出可能的解決方案。 O-RAN簡介 O-RAN 功能簡介（高級架構圖）圖源：自製 （由於網路功能雲原生已成趨勢，因此後段提及的NF已全部視為CNF） 首先進行 O-RAN 的簡介 SMO 會透過 O1介面進行 NFs 的配置管理，同時透過 O1 介面獲得來自 NFs 的 ...

由於在 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 介面傳輸...

MnS，英文全名為(Management Services) 中文譯為管理服務，是來自 3GPP TS 28.533: Management and orchestration; Architecture framework，而本文將會著重於不同 MnS component 的類別進行介紹 MnS Component type A MnS Component type A 是一組管理操作(和/或)通知，但它與所管理的實體無關。因此，這些操作和通知不會涉及與被管理網路有關的任何訊息。 這些操作和通知被稱為通用(generic)或稱為網路無關(network agnostic)。 舉例一下，MnS Component type A 可能包含以下操作： 建立一個新的管理實體(managed entity) 刪除管理實體 獲取被管理實體的狀態 更新被管實體的設置 記錄故障 發出警報 MnS Component type A 通常使用 RESTful API 來實現。這使得它可以很容易地被其他管理系統和應用程式使用。 MnS Component type A 是 5G 管理架構中很重要的部分。它提供了一種通用的方式來管理 5G 網路。 這使得 5G 網路與現有的管理系統和應用程式整合，變得更加容易。 MnS component type B MnS component type B 是由被管理實體們(managed entities)的資訊模型作為表示的一組管理資訊。它也被稱為網路資源模型（Network Resource Model，NRM）。 NRM 提供了一種通用的方法來表示 5G 網路中的被管理的實體。NRM 包括有關網路結構的資訊，管理實體之間的關係，以及管理實體的屬性(attribute)。 而 NRM 通常使用標準的 XML schema 來實現；這也使得它可以在不同的管理系統和應用程式間輕鬆交換。NRM 的通用性使得不同的管理系統和應用的整合，以及開發新的管理應用成為可能。 以下舉例一些可包含在 NRM 內的資訊的： 被管理實體的名稱 被管理實體的類型 被管理實體的位置 被管理實體的設置 被管理實體的效能 被管理實體的故障 老生常談，具體還是要看網路營運商的需求，會有不同的資訊內容以及變化 MnS Component type C MnS Component ...