發表文章

O-RAN Near-RT RIC 介紹

圖片
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 正面臨什麼資安挑戰? | 蔡秀吉

圖片
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、啟動模擬器、卸載等…. 這些腳本已分為