O-RAN O-Cloud 介紹

 O-Cloud 簡介

O-Cloud 是一個雲計算平台，這個平台整合了架設 O-RAN 基站所需的各種物理基礎設備節點(Node)，用於託管 O-RAN 的相關網路功能，此外，O-Cloud 也支援軟體組件（例如：操作系統 (OS)、虛擬機監視器 (Virtual Machine Monitor)、Container Runtime 等...）以及適當管理功能和編排功能(Orchestration functions)。

O-Cloud 物理基礎設備節點是什麼？ 

  • O-cloud 物理基礎設備節點 (Physical infrastructure nodes)包含像是：CPU、BIOS、記憶體、儲存(storage)、主機版管理控制器(BMC)、網卡(NIC)等... 
  • 未看先猜，未來 node 也會包含像是有硬體加速器、軟體定義硬體(SDH)、Switch 等...

O-RAN 的相關網路功能是什麼？

例如：Near-RT RIC、O-CU-CP、O-CU-UP 和 O-DU

有關什麼是 適當管理功能和編排功能(Orchestration functions)，本文下段有進一步著墨~

與 O-Cloud 連接的介面

O-RAN 的高級架構(High Level Architecture；HLA)

上圖顯示了 O-RAN 架構中主要的四個介面
  • A1介面
  • O1介面
  • Open Fronthaul M-plane 開放前傳 M-plane 介面
  • O2介面：SMO（服務管理和編排）透過 O2介面連接 O-Cloud

O-Cloud 通知介面(Notification interface)

  • 可使 O-RAN Network Function（如：Near-RT RIC、O-CU-CP、O-CU-UP 和 O-DU）接收來自 O-Cloud 的相關通知。
  • O-Cloud 通知介面允許事件消費者 (Event Consumers) 可以從 O-Cloud 訂閱事件/狀態。
    • （事件消費者：如部署在 O-Cloud 上的 O-DU）
  • 雲基礎設施 (Cloud Infrastructure) 將會提供事件生產者(Event Producer)啟用(cloud workloads)，用來接收可能只有基礎設施知道的事件/狀態。

O-Cloud 管理、編排以及工作流管理介紹

標題原文：O-Cloud Management, Orchestration and Workflow Management
  • SMO 利用與 O-Cloud 連接的 O2 介面，提供用於管理 O-Clouds 的功能，支援平台 (platform) 和應用程序元件(Application Elements) 的編排，以及工作流管理 (workflow management)。
  • O2 介面支援 (Cloud Infrastructure) 雲基礎設施的管理，O2 介面也可以使用分配給 RAN 的雲資源 (Cloud Resource)。

O-Cloud O2 介面具備的功能

Working Group 6 負責制定 O2 介面的完整標準以及規範，在規範當中的示範功能 (example functionality) 將會被支援（廢話），但不限於下述內容：
  • O-Cloud 資源的發現和管理 (Discovery and administration)
  • O-Cloud 的水平縮放、水平擴展 (Scale-In, Scale-Out for O-Cloud)
  • O-Cloud的FCAPS（PM、CM、FM、通訊監控(Communication Surveillance)）
  • O-Cloud的軟體管理
  • 創建、刪除已部署的O-Cloud 資源或其他已分配的相關資源
  • O-Cloud 資源的水平縮放、水平擴展
  • 部署和分配的 O-Cloud 資源的 FCAPS（PM、FM）
  • 部署的軟體管理

O-Cloud 中所謂適當的管理功能和編排功能

進一步敘述第一段 O-Cloud 簡介中提到的，適當管理功能和編排功能(Orchestration functions)，如下列：
  • 導出 O2 介面給Cloud 和工作負載管理(workload management)，用來提供以下功能
    （如：Infrastructure Discovery, Registration, Software Lifecycle Management, Workload Lifecycle Management, Fault Management, Performance Management, and Configuration Management, etc,.）
  • 將 O-RAN 加速器抽象層(Accelerator Abstraction Layer，AAL) 的API，導入由硬體加速器管理的 O-RAN 工作負載。(看不懂這三小對不對，[註1])
  • 導出 O-Cloud 通知介面(Notification interface) 給 O-RAN工作負載workloads，用於提供關鍵通知（如：PTP 同步狀態）。
  • 未來 O-Cloud 會因應一種或多種部署場景的需求，進行相關的技術演進。
  • RU 的虛擬化(O-RU)有待於未來研究。（等你來研究～）

註釋

註1：為了將 O-RAN 容器化網路功能或虛擬化的網路功能(如：O-CU 和 O-DU)，能夠與硬體完全解耦，O-RAN Working Group 6 制定了標準的加速抽象層 (AAL)的 API 介面，使得（如：PHY功能、加密算法等…計算密集型功能），得以卸載到硬體加速器上，交由硬體加速器處理這些功能。
那為什麼這樣做呢？因為通常我們在實作時，會把 O-CU 和 O-DU 當成是在 VM 或 Container 上跑的軟體，而在實際執行 Cloud stack (VM)時，想當然爾 高速通訊對於延遲是很敏感的，而且是計算密集的(compute-intensive)，並且使用通用的 CPU 來執行相隊來說比較耗電。

不同網路功能組件 O-RU、O-DU、O-CU 要執行的功能很不同

不同網路功能組件（如：RU 跟 CU）對於底層硬體需求也很不一樣，常見就像 RU 要做 FFT，CU 要做 PDCP 或其他進程。因此 O-RAN Working Group 6 就制定標準的 AAL API介面，這個 API介面隱藏了硬體差異，同時讓計算密集型功能等功能，得以卸載給硬體加速器（交由硬體加速器來處理這些功能），進一步優化 O-RAN 容器化網路功能或需虛擬網路功能的效能。

補充：AAL API介面隱藏硬體差異：就是讓 O-RAN 網路功能 O-CU、O-DU 以為我們都在同一艘船上，都在同一個硬體上面跑。


AAL、硬體加速器，這是一個很好的研究領域啦！有興趣的話，嘿嘿你聽過 DPDK 嗎？

本文部分內容是以抽象、類比的方式進行描述，這麼做是為了使讀者能夠理解具體的情形。若覺得有不精確的地方，歡迎留言指教，有任何想法，或是對於 O-RAN 有興趣的話，歡迎與我聯繫，可以共同討論交流~；現在時間 20:07 先打到這邊，我先來吃飯~

聯絡資訊（蔡秀吉）

位置： 300台灣新竹市東區光復路二段101號

留言

張貼留言

這個網誌中的熱門文章

生成式AI將電信業推向新紀元

圖片
電信產業如何應用生成式 AI？ 究竟電信產業該如何引入生成式 AI (Generative AI)，來解決業界長久以來的痛點呢？秀吉現在就報給你知！ 前言 這個學年來捷克訪問，無法實體參與  Google Cloud Summit Taipei ，但身為國外的 GDSC Lead ，進修和教學還是責無旁貸，畢竟人生的樂趣在學習，人生的收穫在於奉獻 www 所以就忙裡偷閒在國外補檔一下  Google Cloud Summit Taipei | (中華電信)解析 Next’23 最新雲端技術 ；可能是因為主題安排或是時間關係，這場演講比較像是產品成果發表，技術偏少。 但沒關係，本篇文章將科普電信業引入生成式 AI 的魅力在哪？，同時針對演講中提到的 Data Cloud 服務應用與挑戰 做進一步的說明和科普。 簡而言之，這是一篇科普文，所以即使你沒聽過演講也看得懂 （廢話結束，以下正文） 電信產業如何應用生成式 AI 電信產業究竟如何應用生成式 AI，主要可以分成兩大使用範例(Use Cases)： Customer Automation （用戶自動化） Network Automation （網路自動化） 一般人經常使用到的生成式 AI，大多都是 大型語言模型 (Large language model；LLM) ，那麼隨著越來越多人的使用和媒體的炒作，民眾對生成式 AI 衍生服務的接受度也將逐漸增加，而這點對於電信業者來說，是個非常好的機會，為什麼我會這樣說呢？讓我們繼續看下去！ Customer Automation（用戶自動化） 對於絕大部分天然呆的台灣用戶來說：「電信供應商的好壞，在於客戶服務！」 所以只要將客服的體驗優化好，萬事皆好談！ 以中華電信為例，它擁有全台 90% 的固網業務以及 1300萬個門號用戶；對於一間擁有如此龐大用戶的電信業者，最重要的就是導入生成式 AI（如：語音辨識模型、對話模型），用來實現 用戶自動化(Customer Automation) ，和以下目標： 更快解決客戶遇到的問題 減少客服中心收到的來電 確保電信業真的有善用自家強大的科技技術，實現用戶個人化的電信服務 所以台灣四大電信業者正面臨一個龐大的機會，透過導入生成式 AI 實現用戶自動化，即可徹底改變現狀（例如：使用機器學習來分析客訴情況的描述、處理客戶查詢等問題），同
閱讀完整內容

O-RAN Y1介面簡介

圖片
一句話介紹：這是 O-RAN 新增的介面(2023/03)，允許 Y1 consumers 訂閱或請求 Near-RT RIC 提供的 RAN 分析資訊 (RAN analytics information)。 圖(一) O-RAN Y1介面（圖中紅框處） O-RAN Y1介面功能介紹： Near-RT RIC 透過 Y1 介面，提供 RAN 分析資訊 (RAN analytics information) 的服務，而 Y1 consumers 可以藉由訂閱或請求 RAN 分析資訊 ，來使用 RAN 分析資訊 服務。 當 Y1 consumers 在 O-RAN 可信域 (Trusted Domain) 時，可以作為應用程式功能 (Application Functions，AFs)；或  RAN 分析資訊 可以透過網路曝光功能 (Network Exposure Function，NEF) 以安全的方式提供給 (Application Functions，AFs) 速記：在 O-RAN Trusted Domain 時 ， Y1 consumers == (Application Functions，AFs) 安全的網路曝光方式(NEF) 詳見：3GPP TS 23.501, Clause 5.20 (External Exposure of Network Capability)，連結如下： Release 17:  https://reurl.cc/ml7Y6W Release 16:  https://reurl.cc/7RnV2y 秀吉 MurMur： Y1 consumers  使用 RAN 分析資訊 服務，出發點一定是好的啦~，得以提供不同情境的使用者裝置更適合的服務，但 新介面的出現，同時也意味著新的資安威脅，學術界又有新的研究領域了（誤 綜觀 O-RAN 的高級架構 (High Level Architecture；HLA)   圖(一)： 圖(一) 顯示 O-RAN 架構中主要的四個介面 (A1、O1、Open Fronthaul M-plane、O2)。 SMO（服務管理和編排）透過 A1、O1、Open Fronthaul M-plane 連結 O-RAN Network Functions（如：Near-RT RIC、O-CU-CP、O
閱讀完整內容