O-RAN 科普教育

隨著新世代行動通訊技術標準的不斷更新，為了追求更高的網路速度、更大的網路容量，適應更複雜的使用場景，同時還須兼顧設備成本、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 架構由哪些組件組成？ (What components makes up the O-RAN architecture?) Ans: SMO、Non-RT RIC、Near-RT RIC、O-CU-CP、O-CU-UP、O-DU、O-RU、eNB、O-cloud OAM 功能的管理服務是什麼？ (What are the Management Services of OAM function?) Ans: FCAPS Management OAM 功能有哪些特點？ (What are the Management features of OAM function?) 追蹤並快速識別發出警報通知的組件所在以及警報的內容 (Trace and quickly identify problems) 監控狀態(Monitoring Status) 自我修復(Self-healing) OAM function 連接哪些介面？ (Which interfaces are connected to the OAM function? ) O-Cloud: Via O2-IMS interface and O2-DMS interface O-RU: Via Open FH M-Plane interface. Other (Managed Elements；MEs): Via O1interface. 您認為 OAM 的哪些 feature/function 更重要？ 原因又是什麼呢？ (Do you think which feature/function of OAM is more important? And what is the reason?) Ans: Alarm notifications，因為它可以幫助服務供應商快速識別 O-RAN NF 發生了什麼問題。 搜尋開源平台（O-RAN SC 或 ONAP）是否可用於支援 OAM 功能？ (Survey the open-source platform (O-RAN SC or ONAP) is available for OAM function?) 是的，MANO(ONAP)、NMS（上述的管理與編排系統在 O-RAN 中稱為 SMO）支持 OAM OAM 與 SMO的交互workflow 示意圖

O-RAN 架構中所提及的 Onboarding package 是一個檔案，其中包含了部署網路功能 (Network Function；NF) 所需的全部資訊。（包含：NF 的軟體、設置檔案(Configuration files)、註冊檔案(Registration file)[註1]，和其他特定功能的工件(artifacts)） 注意事項：本文件著重於（網路功能）NF Onboarding Package 的介紹 當然 SMO 也有執行 xApp 和 rApp 的 Onboarding。   NF Onboarding Package Workflow 簡述 Onboarding Package 通常會以壓縮檔的格式（如：CSAR、ZIP）進行軟體交付(delivery)，就是將 NF Onboarding package 傳送至 SMO（服務與管理編排系統）[註2]，SMO 會透過 O2 介面連結 O-Cloud 並開始進行下一步的 NF 部屬。 參考資料： Ericsson ONAP xNF Onboarding SMO 會使用 Onboarding Package 中的資訊，來建立 NF 的部署計劃，而部署計劃指定了部署 NF 所需的資源（如：計算 (Compute)、儲存 (Storage) 和網路資源 (Network Resources)。除此之外，部署計劃還指定了部署 NF 需要執行的步驟（如：安裝軟體、配置 NF、啟動/執行 NF） 接下來，SMO 會執行部署計劃來部署 NF。一旦部署了 NF，SMO (NETCONF client) 就會記錄下所有部署的 NF 的資訊 (NETCONF server)。 使用 Onboarding Package 的優點： Onboarding Package 使 NF 的部署和管理都變得更加容易，因為 Onboarding Package 包含了部署 NF 所需的全部資訊，因此 SMO 不必辛苦從不同來源收集資訊，使部署過程更容易，同時也提高了部署過程的效率，更一致且更易於管理，且不容易出錯。 Onboarding Package 提高了 NF 部署的一致性，同時確保所有 NF 能以相同的方式部署，提高了 O-RAN 網路的魯棒性和效能。 註釋： [註1]：Onboarding package 其實也有一個

由於在 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 介面傳輸至 SMO，後續透過數據閉環 clos

GNSS 和 GPS 都是全球導航衛星系統，但兩者不全然相同。 GNSS 是全球衛星導航系統的總稱，而 GPS 是由 美國開發 的特定系統。 主要區別 GNSS 和 GPS 之間的主要區別在於使用的衛星數量。 GNSS 系統通常使用 24 到 32 顆衛星，而 GPS 使用 24 顆衛星。 這表示 GNSS 系統可以提供比 GPS 更準確、更可靠的定位資訊。 GNSS 和 GPS 之間的另一個區別是所使用訊號（通訊）的頻率。 GNSS 系統使用比 GPS 更廣的頻率範圍，這使 GNSS 能夠應用在各種不同場景(scenario)，可以在更具有挑戰性的環境（如：海上和森林）中提供更好的效能。 最後，GNSS 系統比 GPS 應用更廣泛。 GPS 是使用最廣泛的 GNSS 系統，但不是唯一的系統。 還有其他幾個 GNSS 系統在運行，包括 GLONASS（俄羅斯）、伽利略（歐洲）和北斗（中國）。 圖（一） GNSS 和 GPS 之間的主要區別 總合以上所述，GNSS 是一個比 GPS 更先進、功能更強大的衛星系統。 然而，由於其歷史和廣泛的可用性，GPS 仍然是使用最廣泛的 GNSS 系統。 聯絡資訊（蔡秀吉） hctsai@linux.com https://www.facebook.com/thc1006

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