發表文章

5G O-RAN 正面臨什麼資安挑戰? | 蔡秀吉

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

Kubernetes (K8S) 基本介紹

圖片
 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 | SMO(服務管理和編排) 介面功能介紹

圖片
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 介面,請

5G O-RAN | INT 的 部屬教程及操作方法翻譯 -自動化部署和測試 使用 SMO 套件 和 ONAP Python SDK

圖片
Automated deployment and testing -Using SMO package and ONAP Python SDK 自動化部署和測試 - 使用 SMO 套件及 ONAP Python SDK 簡報: https://reurl.cc/oZLy9D 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、啟動模擬器、卸載等…. 這些腳本已分為

5G O-RAN | INT(Integration and Testing) 整合與測試介面介紹文

圖片
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

5G O-RAN | INT(Integration and Testing) 整合與測試介面介紹文 | INT D 版本中的 Closed Loop 用例測試介紹

圖片
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