O-RAN 科普教育

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 當中

5G O-RAN正面臨什麼資安挑戰？  O-RAN技術的出現，阻斷了傳統網路供應商壟斷市場的現象；開源開放的標準介面、基地台結構分解(RAN disaggregation) 創新技術等…，帶給了白牌台廠機會；但也因為開源開放，而產生介面通訊安全、軟硬體的整合等問題，5G O-RAN 當前正面臨資安挑戰！那台灣有什麼應變措施呢？ 不只「資安及國安」，產業經濟如果不安全，同樣動搖國本！ NCC孫委員雅麗於CYBERSEC 2021臺灣資安大會[1] 提及： 「5G 的價值不是在公網，而是在垂直場域。」 5G 專網(5G private network)若引進產業垂直場域，將帶來產業數位化及智能化等優點。O-RAN技術的出現，更是大大降低5G專網的建置成本，也供各產業更多設備選擇，降低各產業建置5G專網的門檻，O-RAN 帶來產業數位升級的美好前景，But, The scene behind the Hill，同時也帶來了威脅，國安及經濟需同時顧及，扶植台廠的下一步，就是替 5G 專網的資安風險尋找 MIT 的解方。註：MIT (Made in Taiwan) 擔心被誤解成授權 MIT。 O-RAN 是什麼？是「黑輪」嗎？可以吃嗎？ 先來簡單介紹O-RAN吧！為了阻斷網路供應商 (NOKIA,愛立信)獨佔市場的現象，世界電信龍頭組成了O-RAN ALLIANCE 並制定了 O-RAN （開放式無線接取網路）標準；O-RAN跟傳統LTE RAN架構比較，有重大的改變。Open RAN的亮點就是高彈性(flixable)及高開放性，使得RAN可以依網路的需求，進行軟硬體佈署；O-RAN分解了傳統 RAN 的架構，現在可以依所需功能，進行元件的切分(Functional split)，RAN的即時智能控制器佈署了AI/ML模型，使得RAN可以依照需求自動調節網路資源；5G的低延遲優勢，使得部分元件得以雲端化，如：軟體定義網路 (SDN) 及網路功能虛擬化 (NFV) 技術；現在僅需將雲軟體佈署在獨立的基礎硬體上，再利用標準開放介面將上述所有元件連接起來。 傳統LTE RAN 架構圖：自製 5G O-RAN架構圖：自製 資安是ICT的DNA！ 在以前，資安是替ICT創造更高價值的賦能工具，2019布拉格提案，使得2022的現在早已內捲化，資安即成為廠商標配，資安測試應納入開發的環

正版 Windows Movie Maker 程式集2012 下載 （Windows10/Windows11 皆可適用） 這是真的 Windows Movie Maker，就是 windows 7 推出的那個版本，後續有更新影片加速功能。 因為網路上充斥太多偽裝成 Movie Maker 的惡意軟體，需要一定數位力才找的到正版的軟體。 Windows Movie Maker簡潔的UI，真的讓剪輯門檻降低了很多 不廢話上雲端連結： https://reurl.cc/jGgXGp （Windows 8/Windows10/Windows11 皆適用） 試用結束請於24小時內刪除

 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 個不同的層，但根據您的設定，可以