---
title: 5G O-RANService Management and Orchestration (SMO) 功能介紹
tags: nycu MIRC104
---

> [name=蔡秀吉]<br/>[time=May 29 2022] [color=#F4B400]
> https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20876079
- https://www.bsmi.gov.tw/wSite/public/Attachment/f1663807066975.pdf

[投影片](https://docs.google.com/presentation/d/125lxJpBUrnlUcH3s1BsI1rb1EDa4G6bL/edit?usp=sharing&ouid=113296565415234841307&rtpof=true&sd=true)

:::spoiler 目錄
[TOC]
:::

## 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) 溝通
- CUS-Plane：Control User Synchronization (連接至 DU)
- M-Plane：Management (連接至 Non-RT RIC 或 DU)

## O1 介面介紹：

- O1 介面支援 NETCONF 協議，對 O-RAN 解方中的網路元件進行設定和管理。 這些網路元件包括 Near RT-RIC、O-CU、O-DU 和 O-RU。
- SMO 使用數據模型驅動網路元件，進行設定及管理。
- 實現基於 OpenDayLight（ODL）的 NETCONF 。
- 實現基於 ODL Community GUI（DLUX）的用戶界面。
- 有關 SMO（NETCONF 客戶端）如何與 RIC、CU、DU 和 RU（每個都是 NETCONF 服務器）交互的示例，請參見下圖。
> **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 介面，請注意它需要支援 YANG 模型進行 NETCONF 監控。
- ietf-netconf-monitoring 支援，允許 NETCONF 客戶端列出和下載設備使用的所有 YANG Schemas（基模）。
- NETCONF 客戶端只有在知道使用的 Schema（或至少一個子集）的情況下才能與設備通訊。

## 數據模型測試 (Testing of Data Models)
- SMO 正在與 OAM 項目合作，測試、驅動數據模型，為 O-RAN 解決方案發布準備。
- 這些模型可能來自 3GPP 或 O-RAN 本身。
- 模型本身將駐留在 NETCONF 服務器中，例如：在 near RT RIC、O-CU-UP、O-CU-CP、O-DU 和 O-RU 中，將由 NETCONF 客戶端提出請求，例如 NETCONF 通信期建立時的 SMO。
- 此後，像 Postman 這樣的應用程式可以驅動 SMO 公開的北向 API。
- 這些設定片段的範例將出現在您附近的 Gerrit 資料庫中。
> the SMO at the time the NETCONF session is established. “session” 教育研究院 翻譯 通信期
- 有關測試框架的外觀，請參見下圖：
- 

## SMO and App Onboarding
### 介紹
- SMO 的目的之一是載入應用程式，無論它們是在non RT RIC 上運行的 rApp，還是在 Near-RT RIC 上運行的 xApp。 載入後，SMO 需要保留一個應用套裝程式，以了解哪些應用程序可供操作員部署或創建實例。可以充當模型推論 ( Model Inference ) 主機 ( others：Near-RT RIC、E2 節點 )。
- 為了能夠載入這些應用程式，SMO 需要能夠了解應用程式是如何打包的。其細節將在下文討論。 接下來是關於應用套裝程式的目錄，應該公開的內容的討論，以便操作員可以觸發應用程式的部署。
### 應用套裝程式基態 ( Application Package Schema )
SMO 項目正在嘗試為包定義架構。 有關提案的詳細信息和對提案的評論，請參閱此[連結](https://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/987562173/APP+LCM+Package+Structure)。 該提案遵循 ETSI NFV SOL 004 定義的包模式，該模式定義了用於打包 TOSCA 和 YANG 數據模型定義的 VNF 描述符 (VNFD) 的模式。 這個想法是建立在包定義的基礎上，並將其用於應用程序打包。

> application package 應用套裝程式

### 應用套裝程式目錄 (Application Package Catalog)
在[此處查看](https://oranalliance.atlassian.net/wiki/spaces/OAMWG/pages/1550256254/APP+LCM+Package+Structure)有關應用套裝程式目錄詳細訊息的更新。

## O1/VES 介面
O1/VES 介面支援 SMO 的監控端( monitoring side )。
下圖顯示了網路元件如何與 SMO 中的 O1/VES 介面交互作用。
目錄下圖中可以看到相同的另一個視圖。
在這種情況下，事件由 VES 代理撿走，這些代理以 VES 事件的形式對其進行格式化並將其發送到 VES 收集器。 VES 收集器將事件存儲在 InfluxdB 中，或者儲存到 Elasticsearch 引擎 和/或 Kafka 匯流排中。
然後，Grafana 或任何其他應用程式可以獲取事件數據，以對數據執行任何分析。