O-RAN 科普教育

 Kubernetes 是一個 自動化部署、擴展、管理應用程式的平台。 本文與 GDSC 計畫合作， 介紹  Kubernetes (K8S) 元件及原理。 3大優點介紹 同時部署多個容器到多台機器上（Deployment）。 服務的乘載量有變化時，可以對容器做自動擴展（Scaling）。 管理多個容器的狀態，自動偵測情況，若失效或錯誤，及重啟故障的容器 (self-healing) 。 Kubernetes 架構基礎元件介紹 Cluster -集群 多個 Worker 與 Master 的集合在一起的的組件 Master Node -Master 節點 運作的指揮中心 管理所有其他 Node Worker Node -worker 節點  運作的最小硬體單位 硬體資源的提供者  可以是 實體機器 或 虛擬機 Pod Kubernetes 當中最小的組件單元 可以有一個或是多個 Container，但通常都只有一個 同一個 Pod 中 Containers 共享資源及網路 Kubernetes 他管理著一系列的主機或伺服器(Worker Node)，，Node 當中有各自獨立運作的Pod。 Pod 的功能要比喻的話，可以說成是 container 的集合，這些 container 將一個 Pod 的應用 build 起來。 （例如：今天有一個網頁應用服務，我這個 Pod 應用中可能會需要哪些功能的  comtainer） 這麼多的 Pod ,Node，就會需要一個 coordinator （協調員）的角色來負責，調度、負載均衡，或是失效後重建，使服務能夠穩定運行。 這個協調員就叫做 Master Node，Master Node 透過與 Worker Node 上的 API 通道進行通訊，並藉由 API 即時監控 Node 及 Pod 的資源使用狀況 (satus)。 當 Pod 失效、崩潰時，負責重建的 Pod ，我們稱之為 Replica Set （副本集），他們是重要的功臣，就像伺服器上的乖乖一樣，讓我們的應用程式能夠長久且穩定的運行。 下圖展示 Kubernetes Architecture  上方紅色框框即為 協調工作的Master Node Kubernetes Architecture （整個黑框稱為一個 cluster） Master Node co

5G O-RAN Service Management and Orchestration (SMO) 服務管理和編排介面功能介紹 原始文檔： O-RAN SMO 首先先來看這張 O-RAN Architecture (SMO) 紅色框框 以下是 SMO 支援的介面介紹： O1 FCAPS：(Fault, Configuration, Accounting, Performance, Security) 的控制介面 O1/VES：用於將 JSON 消息處理成 DCAE 的 RESTful 收集器。 O2 和：O-Cloud 溝通。 A1：Non-RT RIC 和 Near-RT RIC 溝通。 R1：是 rApp 與 Non-RT RIC 和 SMO 之間的唯一介面，滿足 rApp 的所有功能需求。 Open Fronthaul: RU (Radio Unit) 溝通  M：Management (連接至 Non-RT RIC 或 DU) O1 介面： O1 介面支援 NETCONF 協議，對 O-RAN Solition 中的網路元件進行設定和管理。  這些網路元件包括 Near RT-RIC、O-CU、O-DU 和 O-RU。  SMO 使用數據模型驅動網路元件，進行設定及管理。 實現基於 OpenDayLight（ODL）的 NETCONF 。 實現基於 ODL Community GUI（DLUX）的用戶界面。 SMO (NETCONF client) Interacts with the RIC, CU, DU, RU (RIC, CU, DU and RU)  都是 NETCONF 服務器 (Server) 也稱為 ME ( ManagedElement ) SMO 提供 REST API，用於驅動 RIC、CU、DU 和 RU 上的設定。 Developer Notes (開發人員筆記)： SMO 在 O1 介面上充當 NETCONF 用戶端，網路元件充當 NETCONF 伺服器。 SMO 正在評估執行 NETCONF 用戶端的幾個選項。 NETCONF 伺服器在 Near RT-RIC、O-CU、O-DU 和 O-RU 等網路元件上的設備來源，有多種可使用方式或實現的選擇。  一種開源選項是 Netopeer2。 無論使用何種源來實現 O1 介面，請

Automated deployment and testing -Using SMO package and ONAP Python SDK 自動化部署和測試 - 使用 SMO 套件及 ONAP Python SDK 簡報： 點我前往 Introduction 本 wiki 介紹是基於 ONAP 自動部署和測試 ORAN SC SMO 包的方法和步驟，包括驗證示例用例。 Driver 自動化是當今的關鍵，部署和測試 需要具備可重複性及可移植性。 為了使用 ORAN SC 軟體實現一定程度的自動化，我們採取了以下步驟： 創建一個簡單的部署方法，重用 ONAP 已完成的工作：參見 SMO 包 ( https://jira.onap.org/browse/REQ-887 ) 重用在 ONAP 中已經成功使用的測試自動化工具：參見 Python-SDK ( https://python-onapsdk.readthedocs.io/en/master/ ) 擴展部署機制，以提供一個獨立的、可移植的設定，以驗證各類型部署的使用範例（稱為“flavors”） 最終目標是為 O-RAN SC 社群提供一種以最低基本需求，來部署 SMO 及其測試環境的方法，最終此設定可用於 lab 以自動驗證程式碼更改，並直接在程式碼審查工具中報告問題。 本 wiki 中所描述的設定絕不是封閉的，由於所選的所有工具有靈活性，所以它可以輕鬆擴展。 SMO Package based on ONAP SMO 套件可在 “it/dep” 儲存庫中的 ORAN gerrit 上訪問 。 它是基於 ONAP OOM 儲存庫，因為它被用作 Git Submodule。 ONAP 圖表沒有改變使用，也沒有重新定義，但顯然是通過使用 Helm 覆蓋機制進行設定的。 ORAN 圖表被主要用於定義部分 NON RT RIC ，其他圖表可以稍後增加。 定義的測試圖表包含網路模擬器（DU/RU/拓撲服務器）、jenkins 或 python SDK 測試的 helm 圖表。 ChartMuseum 用於儲存本地構建的圖表（因為目前無法遠程獲取 ONAP 和 ORAN 圖表） SMO 套件包含一些腳本來設定Node、安裝 smo/jenkins、啟動模擬器、卸載等…. 這些腳本已分為 3 個不同的層，但根據您的設定，可以

INT 主要的功能就是負責 測試 (test) ，為了 O-RAN SC 開發軟體元件的整合，所以要測試所有之前 release 版本中被記錄起來的需求，還有其他像是 端到端測試 (end to end test) 和 用例測試 (use case test)。 負責項目 (Project) 有： IT-DEP：部署作品（腳本、Helm 圖表等） // artifacts  國家教育研究院 翻譯成作品 IT-DEV：整合和測試項目使用此儲存庫來託管各種開發程式碼。 IT-OTF：開放測試框架。 IT-TEST ：這個 repo 維護了 O-RAN RIC 項目的端到端測試和驗證的源程式碼。 就簡單的來介紹這些項目吧！首先是 (it/dep)  it/dep 的概述：it/dep 儲存庫在 Cherry 版本說到，他負責託管部署和整合作品，例如腳本、Helm 圖表和其他用於部署 O-RAN SC 軟體的文件。 Cherry 版本的 repo 包含： 用於開發測試 1-node Kubernetes cluster 的部署腳本。 Near RT RAN 智能控制器平台的部署腳本和 Helm 圖表。 用於支援 Near RT RAN 智能控制器平台的基礎設施服務的部署腳本及 Helm 圖表。 用於操作 Near RT RAN 智能控制器平台的輔助服務和元件的部署腳本及 Helm 圖表。 O-DU High 項目的部署腳本。 SMO 的部署腳本。 it/dev 概述： 在 O-RAN SC 的 INT 項目，使用 it/dev 儲存庫來託管各種開發程式碼。 在 Amber 版本中提及： 此儲存庫包含用於開發 Near RT RAN 智能控制器應用程式 (xApps) 的整合作品。 由於 Near RT RIC xApp 的生命週期由 Near RT RIC 平台管理，因此 xApp 應符合某些行為型模式 (Behavioral pattern) 並提供 描述良好 (well-described) 的介面。 此處的作品可幫助 xApp 開發人員為他們的 xApp 生成（Near RT）RIC 平台部署就緒 Helm 圖表。 it/otf 概述： O-RAN SC 整合和測試項目使用此儲存庫來託管各種開發程式碼。 對於 Amber 版本： 此儲存庫包含用於開發 Near RT

Closed Loop 用例 OSC 社群 lab 部署 Demo 5G ORAN INT (D Release Integration and Testing) D 版本中的 Closed Loop 用例測試介紹 原始文檔： https://wiki.o-ran-sc.org/display/IAT/Closed+Loop+Use+Case+Testing 此部署的 VM IP 是192.168.130.90 正在運行的 docker 容器列表如下圖所示： ODLUX GUI 模擬拓撲結構，包括 暴露 o-ran-sc-hello-world.yang 的 O-DU 和 3 個 O-RU 暴露 O-RAN FH YANG 的模型 (2020/11 train)。 O-DU 使用 VES pnfRegistration 方法連接，而 O-RU 則通過 NETCONF Call Home 連接。 我們可以看到 NETCONF 服務器通過其 ODLUX GUI 連接到 OAM-Controller，如下圖所示： 故障管理 (Fault Management ) O-DU 和 O-RU 被設定為向 SMO 發送事件：O-DU 發送 VES 故障通知，而 O-RU 通過 NETCONF 通知發送故障。 下圖顯示了 OAM-Controller 捕獲的事件： NONRTRIC Dashboard NONTRIC 元件也已成功部署。 以下是其儀表板的一些螢幕截圖： NONRTRIC Dashboard 詳細日誌  我們還可以在 OAM 和 NONRTRIC 及其元件的日誌中看到正在處理故障：OAM Logs 詳細日誌  我們還可以在 OAM 和 NONRTRIC 及其元件的日誌中看到正在處理故障：NONRTRIC Logs O-DU-HIGH O-DU-HIGH 帶有 intel L1 和 netconf CLI 的 CLA 用例 Demo 這部影片包含使用 L1 和 netconf CLI 的 O-DU-HIGH CLA 用例 Demo。 Blocker： 1- L1 crash 得非常快 2- Multiple Slot indication 3- cell bring up 時沒有 Config response https://wiki.o-ran-sc.org/dow