> [name=蔡秀吉]<br/>[time=June 9 2023][color=#F4B400]
>
本參考架構為 O-RAN Ｍanagement Ｄomain 定義了一組基礎架構**建置區塊**(Building Blocks)，包含了：
- **管理服務 -Management Services**
- **管理元件 -Managed Elements (ME)**
- **管理功能 -Managed Functions (MF)**

:::spoiler 目錄
[TOC]
:::
## OAM架構建置區塊 (Architectural Building Blocks)

### O-RAN管理服務(O-RAN Management Services)
O-RAN Management Services 提供**管理 ME 的功能** 和 **編排 ME 的功能**。
受管理的元件(ME)會將其管理服務(Management Services) 公開給 SMO；而SMO 會使用管理服務。
O-RAN 支援的管理服務(Management Services) 包括：
- 服務提供/供應 (Provisioning)
- 故障監視 (Fault Supervision)
- 效能保證 (Performance Assurance)
- 追蹤管理 (Trace Management)
- 檔案管理 (File Management)
- 軟體管理 (Software Management)
- 通訊監控 (Communication Surveillance)
- PNF[註1] 的啟動和註冊 (Startup and Registration of a PNF)
- VNF[註2] 的實例化[註3]和終止 (Instantiation and Termination of a VNF)
- 為 VNF 擴展管理服務 (Scaling Management Services for VNF)

> [註1] 物理網路功能(PNF) :Physical Network Function (PNF)
> [註2] 虛擬化網路功能(VNF) :Virtualized Network Function
> [註3] 實例化解釋 :Create an instance of a Network Function(NF).
> [註4] 擴展像是 scale-out [color=#F4B400]

支援的管理服務及其 API 的定義，通通寫在 O-RAN.WG10.O1-Interface Spec 當中。

### 管理元件(Managed Elements)
受管理元件 (ME) 的定義在 3GPP TS 28.622 當中的 第 4.3.3 節中提及。
ME 是一個 IOC，支援通過管理介面 (management interface(s)) 與 manager(SMO) 進行通訊，以進行控制和監視。
O-RAN 管理元件的包括：
- O-RAN 管理功能作為管理元件(ME)單獨部署（例如：Near-RT RIC ME、CU-CP ME、CU-UP ME、O-DU ME、O-RU ME）。
- 集中單元（CU）由 CU-CP 和 CU-UP 組成
- ME 由 Near-RT RIC、CU-CP、CU-UP、DU 和 RU 組成

在後面的章節中，將給出各種部署的實例以及其 OAM 介面；部署方案的選擇將取決於基於運營商(operator)的需求。

管理元件(ME)概念的一個關鍵動機是，一個 ME 是一個緊密整合(integrated)並經過測試的一組MF，它們被部署在一起。這對如何管理軟件更新有影響，因為所有的軟件更新都需要保留ME中的所有MF都經過測試的屬性。
根據部署情況和其他考慮，MF可以用不同的方式分組。每個ME都需要一個介面，它可以管理與包含在其中的每個MF的通信。以下各節介紹了O1介面如何連接到包含單個MF的ME或包含多個MF的集成ME的許多例子。

### 管理功能(Managed Functions)
受管功能 (MF) 的定義在 3GPP TS 28.622 [3] 第 4.3.4 節中給出。 MF 實例使用其包含的 ME 實例公開的管理介面進行管理。
O-RAN 管理的功能包括：
• 近實時無線電智能控制器（Near-RT RIC）
• O-RAN 中央單元 – 控制平面 (O-CU-CP)
• O-RAN 中央單元 – 用戶平面 (O-CU-UP)
• O-RAN 分佈式單元 (O-DU)

### 管理應用程式(Managed Applications)
ManagedApplication：此信息對像類 (IOC) 表示可以獨立測試並與其包含的 ManagedFunction 實例分開部署的軟件應用程式。 包含的 ManagedFunction 實例充當管理應用程式的管理服務。 ManagedFunction 實例可以有零個或多個管理應用程式實例。
xApp 在[19]中定義。 xApp的管理應當遵循以下原則：
- O1 介面終止於 Near-RT RIC 平台 ME，Near-RT RIC平台委託xApp的管理
- xApp可以由第三方提供，它與O-RAN節點解耦，O-RAN節點支援一個或多個xApp在其上運行
- 為了對多種不同類型的xApp 進行建模，需要擴展父類的共同功能，並且特定的xApp IOC 可以從其父類繼承。
根據上述原則，對xApp的建模可以描述如下：
- xApp IOC 代表xApp 的管理方面
- xApp IOC 繼承自ManagedApplication，並且可以擴展特定屬性。
MA 的細節將在 O-RAN 信息模型文檔 [23] 中定義。

### SMO(Service Management and Orchestration) Framework
服務管理和編排框架負責在其控制範圍內管理和編排被管理元件。 例如，該框架可以是第三方網絡管理系統（NMS）或編排平台。
服務管理和編排框架必須為管理功能提供集成結構和數據服務。 集成結構支援 O-RAN 域內管理功能之間的互操作和通訊。 數據服務為管理功能提供高效的數據收集、存儲和移動能力。 為了與RAN服務建模一起實現多種OAM架構選項，不同OAM部署選項和OAM服務（集成結構等）的建模必須得到SMO的支援。

### Non-Real Time Radio Intelligent Controller
非 RT RIC 是服務管理和編排框架的一部分，並使用 A1 介面與近 RT RIC 進行通訊。 [11]
非 RT 控制功能 (> 1s) 和近實時 (near-RT) 控制功能 (< 1s) 在 RIC 中解耦。 非 RT 功能包括服務和策略管理、一些近 RT RIC 功能的 RAN 分析和模型訓練以及非 RT RIC 優化。
### 控制循環支援(Control Loop Support)
O-RAN 定義了 3 個具有不同延遲帶的控制環路 [11]。 這些循環並不是分層的，而是並行運行的。 這並不意味著具有內循環的ME不會因內循環故障而生成其自己的事件，但它不會簡單地傳播內循環接收到的較低級別事件。 這三個循環大致定義為：
- 循環 1：在 DU 中進行每 TTI/毫秒資源調度（<10 毫秒）
- 循環2：在Near-RT RIC和CU中進行資源優化（10毫秒到1秒）
- 循環 3：在 ML 培訓、趨勢、編排的服務管理和編排框架中（> 1 秒）

### 基本OAM運維架構
圖 3.3.2-1 顯示了總體 O-RAN 邏輯架構，如[17]中定義。 O-RAN 架構描述中標識的 O1 介面用於 O-RAN 服務管理和編排框架與 O-RAN 網絡功能（O-RU 除外）之間的 OAM 功能。 當使用混合管理模型管理 O-RU 時，開放 FH M 平面用於 O-RAN 服務管理和編排框架與 O-RU 之間的 OAM 功能。 注意：該圖使用 5G 術語，但相同的原則也適用於 LTE/4G。 將來可能會添加到 LTE/4G 的映射。 O-RAN 架構還包括用於管理 O-Cloud 的 O2 介面，它與 O1 介面有不同的要求，如[21]中所定義。

O1 OAM 介面包括 O-RAN 網絡功能的故障、配置、計費、性能、安全 (FCAPS) 功能、文件管理和軟件管理功能的實現。 有關O1支援的管理服務的詳細信息，請參見[13]。

O2 OAM 介面支援 O-Cloud 基礎設施的管理以及 O-Cloud 上運行的 O-RAN 雲化 NF 的部署生命週期管理。 關於O2支援的功能的詳細信息，請參見[21]。

如圖所示，有一個到各個 O-RAN 受管功能的邏輯 OAM 介面，但實際上，將受管功能分組為受管元件將決定實際 O1 介面的終止位置。 更多詳細信息將在後續部分中進行解釋。 O1 介面可以直接在服務管理和編排框架上終止，或者在分層模型中可以在管理其他 O-RAN 受管功能的受管元件上終止。

開放式 FH M 平麵包括 O-RU 的故障、配置、計費、性能、安全 (FCAPS) 功能、文件管理和軟件管理功能的實現。 它還指定了載波管理方面並在 O-DU 和 O-RU 之間使用。

### O-RU Management Models and Managed Deployment Options
本節描述了一些可能的 O-RU 管理模型，提供了模型的高級描述及其在 O-RAN 架構中當前支援的狀態。 它還解釋了 O-RAN 支援本文檔第 3.3.1.2 節中定義的 O-RAN 管理功能和元件的多種部署選項，並引用了這些部署的示例。 O-RAN OAM 架構中不需要採用單一 O-RU 管理模型或管理部署選項。 網絡中可以支援多種部署組合。
#### 扁平化管理架構模型
Flat Management Architecture Model
在扁平模型中，所有實體/節點均由 SMO 直接管理。 O-RU 目前不支援此模型，供將來研究。
#### 分層管理架構模型
Hierarchical Management Architecture Model
在分層模型中，除O-Rus之外的所有實體/節點均由SMO直接管理，但O-RU由O-DU直接管理（並由SMO間接管理）。 WG4 前傳 M 平面規範 [12] 記錄了 O-RAN O-RU 分層模型的使用細節。 O-DU 的 WG5 O1 介面規範 [26] 提供了通過 O-DU 對 O-RU 進行分層管理的初始視圖。
#### 混合管理架構模型
Hybrid Management Architecture Model
在混合模型中，除 O-Rus 之外的所有實體/節點均由 SMO 直接管理。 O-RU 部分由 SMO 管理（用於 FCAPS 支援），部分由 O-DU 管理。 O-RU 混合模型的詳細信息（包括 SMO 和 O-DU 之間的權限劃分）可以在 WG4 前傳 M 平面規範 [12] 中找到。
#### 管理部署選項示例
Example Managed Deployment Options
O-RAN 還支援 O-RAN 管理功能和管理元件的多種部署選項。 O-RAN 架構文檔 [17] 有一個信息豐富的附件 A，它提供了 O-RAN 部署的幾個示例。 O-RAN 支援單獨的 MF（如本文檔第 3.3.1.2 節中定義）部署為 ME。 O-RAN 還支援部署為 ME 的 MF 組合。 部署選項的選擇由服務提供商自行決定。 由於允許多種組合，O-RAN 架構附件 A 提供了可能部署的示例。
### 部署在 NAT 後面的管理元件
Managed Elements Deployed behind a NAT
服務提供商不喜歡在 NAT 後面部署受管元件 (ME)，但在某些情況下這是無法避免的，例如：
• 公共 IPv4 地址耗盡
• 部署在不屬於服務提供商的大型綜合體（公寓、體育場館等）中的受管元件
• 使用 NAT 通過第三方網絡連接的受管元件

當服務提供商在 NAT 後面部署管理元件時，他們能夠保留對這些元件的完全管理控制至關重要。
O-RAN MEs behind a NAT
建議按優先順序推薦四種方法，使 O-RAN 管理器能夠尋址 NAT 後面的 ME 並識別從 NAT 後面的 ME 接收的數據：
1. ME 在可能的情況下使用 IPv6 作為回程傳輸，從而消除對 NAT 的需求 – 耗盡公共 IPv4 地址
2. ME 建立通往位於具有 NAT 的網絡外部的 VPN 集中器（網關）的持久 VPN 隧道（例如，IPSec）。 然後可以通過已建立的隧道訪問 ME。
3. ME 使用標準協議（UPNP 或 PCP）在防火牆上建立端口轉發規則並自動為自己分配端口。
4. 服務提供商手動配置防火牆，為受保護網絡內的每個 ME 分配端口。

#### 參考資料
3GPP TS 28.622: "Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)"