# WG5
###### tags: `Spec`

The Open F1/W1/E1/X2/Xn Interface Workgroup
# O1 Interface specification for O-DU
(O-RAN.WG5.MP.0-v01.00)
* This version of the O1 Interface specification for O-DU is primarily aimed at providing support those mandatory and optional features defined in version 1.0 of the C-Plane, U-Plane and S-Plane specification.
* The present document specifies the O1 Interface specification for O-DU used over the interface linking the O-DU with other management plane entities, that may include the O-CU as well as Service Management and Orchestration (SMO).
* O1 interface facilitates the initialization, configuration and management of the O-DU to support the functional split.
* O1 interface for O-DU is used for supporting the management features including “start up” installation, software management, configuration management, performance management, fault management and file management towards the O-DU.

### O-RAN OAM Architecture on architecture and functional split
* The O-RAN OAM Architecture identifies management services, managed functions and managed elements supported in O-RAN, including the interworking between service management and orchestration and other O-RAN components such as infrastructure management. Requirements are derived from end-to-end OAM use cases, initially using the initial provisioning of O-RAN service across VNFs and PNFs as the primary use case.

參考：O-RAN-WG1.OAM-Architecture-v03.00
## 2.2 Interfaces
This interface is defined between the management system and the O-DU. The protocol stack of the interface is shown in Figure 1. The transport network layer is built on IP transport and TCP/TLS is used to carry the messages between the management system and the O-DU.

## 2.3 YANG Module
The data models representing the O1 interface are organized as a set of reusable YANG modules, defined according to RFC 7950.
* O-RAN WG4 Management Plane Specification YANG models will be re-used for configuring the O-RU functionality.
* Because an O-DU managed function will likely support multiple O-RU functions, the O-RAN O1 Interface specification for O-DU defines new models which are used to aggregate the configuration of individual O-RU instances.
* Figure 2 illustrates how the SMO is responsible for aggregating the individual configuration databases for separate O-RU instances and how the O-DU is responsible for de-aggregating the configuration prior to configuring individual O-RU instances.
* 

## Chapter 3 Startup and Registration Management
The overall start-up mechanism from the power-on of O-DU to being ready to be configured.

**Pre-condition:**
* O-DU is physically installed
* Power-ON for O-DU/NETCONF Server or O-DU restart operation.
* Power-ON for NETCONF Client(s).
* Physical interface(s) is(are) connected.

**Post-condition:**
* The SMO is able to determine whether the configuration of the O-RU occurs using hybrid or hierarchical approach.
* Via the connection to the SMO, the O-DU can receive further configuration to enable it to support NETCONF client functionality to enable hierarchical configuration of independent O-RU(s).
* SMO can determine the O-RU instance identifiers that may be provisioned via the O-DU.
**Figure 3: Overall of Start-Up Installation**

### Inbound
當外部網路使用者欲傳送訊息進入內部網路，稱為『進入』（Inbound）封包；而內部使用者送往外部網路的訊息，則稱為『外出』（Outbound）封包。
[參考網站](http://www.tsnien.idv.tw/Linux_WebBook/chap6/6-6%20%E9%98%B2%E7%81%AB%E7%89%86%E8%A8%AD%E5%AE%9A.html)
### CA/RA
(1) RA-註冊管理系統 (Registration Authority server)
RA負責執行憑證申請、廢止及資料審核等作業，透過資料庫比對、臨櫃或書面資料審核等方式進行身分認證，以核發憑證。
* RA Server主要任務為轉送憑證申請訊息給CA、轉送憑證註銷訊息給CA、憑證到期通知發送、電腦機器安全及管理、列印寄發開卡密碼單、稽核RA client 是否有異常核發、憑證之情事、緊急應變處理 RA資料之備份
* RA Client主要任務為受理憑證申請、受理憑證註銷申請、驗證身份文件以識別憑證、申請者之身份、同意憑證。

(2) CA-憑證管理系統(Certificate Authority server)
CA負責執行憑證簽發、廢止、管理等核心作業，以及將簽發之憑證資料及憑證廢止清冊（Certificate Revocation List, CRL）公佈於目錄伺服器，以供外界查詢及下載。
參考網站：[Registration Authority](https://chenghsiu.wordpress.com/2009/06/23/%E5%89%8D%E7%AB%AF%E8%A8%BB%E5%86%8A%E7%AE%A1%E7%90%86%E4%B8%AD%E5%BF%83%EF%BC%88registration-authority%EF%BC%89/)
### TLS
TLS(Transport Layer Security) stands for Transport Layer Security and one of the Security Protocol that is most widely used these days. The most common application of TLS is HTTPS and SSL.
TLS是一種加密通訊協定，目的是在透過網路傳輸時保護資料的安全。
參考網站：[IP Security -TLS (Transport Layer Security)/HTTPS/SSL](http://www.sharetechnote.com/html/Handbook_IP_Network_TLS.html)
### CMPv2
Certificate Management Protocol (CMP) provides on-line interactions between Public Key Infrastructure(PKI) components, including an exchange between a Certification Authority (CA) and a client system.
在PKI體系中，CA負責頒發數位憑證，並作為伺服器端使用CMP協定。通過協定取得數位憑證的客戶端被稱為終端實體（end entity，EE）。EE和CA之間可以存在0個或者多個RA。EE可以利用CMP從CA取得憑證。這可以通過「初始註冊/認證」、「金鑰對更新」或「憑證更新」訊息序列完成。通過復原請求，它也可以取消其自己的一個憑證。使用「交叉認證請求」，CA可以獲得由另一個CA簽署的憑證。
參考網站：[RFC 4210](https://datatracker.ietf.org/doc/html/rfc4210)、[CMP](https://zh.wikipedia.org/wiki/%E8%AF%81%E4%B9%A6%E7%AE%A1%E7%90%86%E5%8D%8F%E8%AE%AE)
## 3.1 O1 Interface Transport aspects
The O1 interface transport establishment scenario, e.g., between O-DU and SMO.

### Stateful、Stateless DHCPv6
全狀態與無狀態的主要差別是全狀態需要一部伺服器來動態維護、存放組態資訊。例如Stateful DHCPv6，是由一部DHCP伺服器來維護每部機器所指派的IPv6位置等對應狀態訊息。
在 IPv4 中，DHCP 服務器通常為主機提供默認網關地址(default gateway addresses)。在 IPv6 中，只有發送 Router Advertisement 消息的路由器才能動態提供默認網關地址。
參考網站：[IPv6 Auto Configuration](https://www.lijyyh.com/2012/04/ipv6ipv6-auto-configuration.html)、[Stateful DHCPv6](https://www.networkacademy.io/ccna/ipv6/stateful-dhcpv6)
## 3.2 Certificate Enrolment
* 3GPP 33.310 specifies the use of CMPv2 used by base stations to obtain an operator-signed certificate for use in securing the NETCONF connection between the O-DU and the NETCONF client in the SMO as well as securing the JSON/HTTPS connection between the O-DU and the SMO/MnS Consumer.
* After enrollment has been performed, the O-DU can use the operator-signed certificate to authenticate itself to the SMO NETCONF client, which is pre-installed with the operator root certificate. The O-DU then authenticates the NETCONF client using the operator root certificate.

FDQN（Fully Qualified Domain Name）完整網域名稱
DNS（Domain Name System）[網域名稱系統](https://its-okay.medium.com/%E6%90%9E%E6%87%82-ip-fqdn-dns-name-server-%E9%BC%A0%E5%B9%B4%E5%85%A8%E9%A6%AC%E9%90%B5%E4%BA%BA%E6%8C%91%E6%88%B0-05-aa60f45496fb)
## 3.3 PNF Registration
* An O-DU realized as a Physical Network Function (PNF) is required to perform a PNF Registration. The pnfRegistration notification is a JSON encoded VES event sent from the O-DU to the discovered SMO/MnS Consumer using REST/HTTPS. When performing PNF Registrartion, the O-DU shall send the pnfRegistration notification to all discovered SMO/MnS Consumers.
* The pnfRegistration notification shall include the IP address information necessary for a NETCONF client to establish IP connectivity to the NETCONF Server in the O-DU, i.e., shall include the field oamV4IpAddress when the O-DU has a configured IPv4 interface and/or the field oamV6IpAddress when the O-DU has a configured IPv6 interface.

### PNF
* oamV4IpAddress - This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF itself can be accessed at.
* oamV6IpAddress - This is the IP address (IPv6) for the PNF itself. This is the IPv6 address that the PNF itself can be accessed at.

參考網站：[5G PNF Plug and Play](https://docs.onap.org/projects/onap-integration/en/latest/docs_5g_pnf_pnp.html)
### VES
Virtual Event Streaming (VES) Collector is RESTful collector for processing JSON messages into Data Collection, Analytics and Events(DCAE).
參考網站：[VES](https://docs.onap.org/en/elalto/submodules/dcaegen2.git/docs/sections/services/ves-http/index.html)
## 3.4 NETCONF Connection Establishment
* The identity of the TLS(Transport Layer Security) server (O-DU) shall be verified and authenticated by the TLS client (NETCONF client) according to local policy before password-based authentication data or any configuration or state data is sent to or received from the TLS server.
* In this version of O1 Interface Specification, the security of the NETCONF protocol is realized using TLS (RFC 5539).
* Mutual Public key-based client/server authentication shall be used for authenticating the server (RFC 4253) by the clients. and authenticating the client by the server.

### NETCONF
NETCONF（Network Configuration Protocol）是基於可擴展標記語言XML（Extensible Markup Language）的網絡配置和管理協議，使用簡單的基於RPC（Remote Procedure Call）機制實現客戶端和服務器之間通信。
Network Configuration Protocol (NETCONF): [rfc6241](https://datatracker.ietf.org/doc/html/rfc6241)、[rfc4741](http://www.netconfcentral.org/netconf_docs)
NETCONF over Transport Layer Security (TLS): [rfc5539](https://datatracker.ietf.org/doc/html/rfc5539)
參考網站：[Netconf協議學習筆記](https://cshihong.github.io/2019/12/29/Netconf%E5%8D%8F%E8%AE%AE%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/)
### YANG - A Data Modeling Language for the NETCONF
YANG是一種被用來爲NETCONF協議建模的語言。一個YANG module定義了具有垂直結構的數據，這些數據可以被用做基於NETCONF的operations，比如configuration，state date，RPCs，以及notifications。它使得NETCONF的client和server之間能有完整的數據描述。
參考網站：[rfc6020](https://datatracker.ietf.org/doc/html/rfc6020#section-7.9.7)、[rfc6020介紹](https://www.twblogs.net/a/5b80e6bc2b71772165aa03c0)

## 3.5 NETCONF Access Control
This subsection provides the access control for NETCONF client. Its motivation is when multiple NETCONF clients (users) exist, access control mechanism allows to limit some operation for one client but full access for the other client.

In order to support interoperable access control management, the NETCONF Server shall use the IETF NETCONF Access Control Model [RFC8341].

Four access control groups are defined per TLS session: “sudo”, “smo”, “fm-pm”, and “swm”. The table below maps the group name to different privileges. Privileges are defined per namespace for read “R”, write “W” and execute “X” rpc operations or subscribe to Notifications.

## 3.6 NETCONF Protocol Aspects
* The O-DU advertises its NETCONF capabilities in the NETCONF Hello message. The Hello message provides an indication of support for standard features defined in NETCONF RFCs as well as support for specific namespaces.
* An O-DU may have some features which are not supported by other O-DUs, i.e. optional feature(s). In this case, the O-DU needs to inform the SMO which features the O-DU can provide, and this can be achieved by exchanging NETCONF capabilities.
* A NETCONF client closes an existing NETCONF session by issuing the RPC close-session command. The O-DU shall respond and close the TLS session.

## Chapter 4 Heartbeat Management Services
Heartbeat MnS allow a Heartbeat MnS Provider to send heartbeats to the Heartbeat MnS Consumer and allow Consumer to configure the heartbeat services on Provider.

Stage 1 Heartbeat MnS is specified in [3GPP TS 28.537](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3718).
Stage 2 notifyHeartbeat notification is specified in [3GPP TS 28.532](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3427).
* This notification notifies the subscribed consumer(s) that the MnS producer heartbeat period has expired or that a MnS consumer requested the emission of an immediate heartbeat notification.
The emission of heartbeat notifications is controlled by the HeartbeatControl IOC.

Stage 2 HeartbeatControl IOC is specified in [3GPP TS 28.622](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1541).
* Information Object Class (IOC): An IOC represents the management aspect of a network resource. It describes the information that can be passed/used in management interfaces.

* MnS consumers (i.e. notification recipients) use heartbeat notifications to monitor the communication channels between them and data report MnS producers emitting notifications such as notifyNewAlarm and notifyFileReady.

Stage 3 Solution Sets for XML, JSON and YANG are specified in [3GPP TS 28.623](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1542).
- 3GPP Generic NRM IRP XML Definitions (28.623 Annex B).
- 3GPP Generic NRM IRP JSON Definitions (28.623 Annex C).
- 3GPP Generic NRM IRP YANG Definitions (28.623 Annex D).

## 4.1 Heartbeat Notification
* Description
Heartbeat MnS(Management Service) Provider sends asynchronous heartbeat notifications to Heartbeat MnS Consumer at a configurable frequency to allow Heartbeat MnS Consumer to supervise the connectivity to the Heartbeat MnS Provider.

* Operations and Notifications
An O-RAN heartbeat notification is a JSON encoded asynchronous notification sent from Heartbeat MnS Provider to Heartbeat MnS Consumer using REST/HTTPS.

An O-RAN heartbeat notification must be in one of the following formats:
1. 3GPP format:
o A 3GPP notifyHeartbeat notification as specified in 3GPP TS 28.532.
2. VES format:
o A harmonized stndDefined VES event, consisting of a VES commonEventHeader and stndDefinedFields with a “data” element that contains a 3GPP notifyHeartbeat notification.
o The stndDefined VES event is specified in the [ONAP VES Event Specification v7.2](https://docs.onap.org/projects/onap-vnfrqts-requirements/en/latest/Chapter8/ves_7_2/ves_event_listener_7_2.html#introduction). A VES common event header is added to the notification.

## 4.2 Heartbeat Control

Heartbeat Control for O-DU is aligned with O-RAN.WG1.O1-Interface.0-v03.00, Chapter 2.6.2 Heartbeat Control.
* Description
For Heartbeat MnS, a Heartbeat Control IOC includes attributes to Get/Set Heartbeat Period, (heartbeatNtfPeriod) and Trigger Immediate Heartbeat (triggerHeartbeatNtf).
* Requirements
NETCONF protocol and YANG data models are used to read and configure the heartbeatNtfPeriod and triggerHeartbeatNtf in the HeartbeatControl IOC.

## Chapter 5 PNF Software Management
O1 Interface Spec中規定的PNF software Management服務適用於O-DU的 software Management。而O-RU 的 Software Management分為Hierarchical Model及Hybrid Model。Hybrid Model: SMO根據O1 Interface Spec對O-DU進行軟體管理，根據O-RAN WG4管理平面規範對O-RU進行軟體管理。

這裡討論的是O-RU Software Management 的 Hierarchical Model:

O-DU provides the software inventory information of each connected O-RU to the SMO by o-ran-agg-software management.yang that has a mount point.
* Software Inventory
The SMO retrieves the software inventory information of O-RU by using the aggregated yang data model.
O-DU has the software inventory information of connected O-RUs, which is retrieved in startup with O-RU.


* Software Download
The SMO triggers the software download to O-RU by sending **software download rpc** defined in O1 Interface Spec with **ru-instance-id which identifies a target O-RU**. After software download for O-RU, O-DU performs the software install to O-RU according to WG4 Management Plane Spec.


* SW activate
When O-DU receives NETCONF <rpc><software-activate><softwarePackage> with ru-instance-id from the SMO, O-DU executes the software activation mechanism to O-RU indicated by ru-instance-id.

## Chapter 6 Performance Assurance Management
* Performance Data File Reporting function for O-DU is aligned with O1 Interface Specification except following part.

### 6.3 Performance Assurance Control
Performance Assurance Control for “O1 interface for O-DU” is aligned with WG1 O1 Interface Spec.

#### 6.3.1 Performance Assurance Control for O-RU performance counters
* **O-RU performance counters measured at O-DU:**
In the hierarchical architecture of O-RAN WG4 Management Plane Specification [4], O-DU as NETCONF client will measure the performance counters defined in Annex A.13. The measurementTypes and gPs for O-RU performance counters measured at O-DU are defined in aggregation model. A part of yang tree structure related to this subsection is shown as follows.

## Chapter 7 Fault Supervision Management
### 7.2 Definition of the Operations for Fault Events
>O-DU 是故障監督 MnS Provider ，負責管理 “getAlarmList” “clearAlarms” “acknowledgeAlarms”。

#### 7.2.1 Request for getAlarmList
The authorized consumer invokes this operation to request the service provider to provide the complete or filtered list of active alarms. The O-DU as Fault Supervision MnS Provider is responsible for managing the “getAlarmList” of O-DU.
When Fault Supervision MnS Consumer performs request to get AlarmList, O-DU responses AlarmList including AlarmRecords.

#### 7.2.2 Request for clearAlarms
The O-DU as Fault Supervision MnS Provider is responsible for managing the “clearAlarms” of O-DU. clearAlarms is only for ADMC (Automatically Detected, Manually Cleared) alarms. If the Service Provider supports ADMC alarms, then this operation should be supported. Otherwise, it is not required.

#### 7.2.3 Request for acknowledgeAlarms
The O-DU as Fault Supervision MnS Provider is responsible for managing the “acknowledgeAlarms” of O-DU.
However, there is no use case in O1 interface specification [47] to satisfy the request to acknowledge one or multiple alarms and report acknowledgement state change notifications of a MnS Provider. If use cases are defined for acknowledgeAlarms in O1 interface specification [47], then this Fault Supervision Management chapter will be updated.

### 7.3 Definition of Notifications as Fault Events
O-DU as for Fault Supervision Data Report service producer notifies the JSON encoded asynchronous notifications to Fault Supervision MnS Consumer using REST/HTTPS. In order to align with O1 interface specification [47], this chapter describes mandatory notification types excluding optional notification types among 3GPP fault notifications specified in TS 28.532

#### 7.3.1 Notification notifyNewAlarm
The Fault Supervision Data Report management service producer notifies the new alarms to the authorized consumer

#### 7.3.2 Notification notifyChangedAlarm
The Fault Supervision Data Report management service producer notifies the changed alarms to the authorized consumer.

#### 7.3.3 Notification notifyClearedAlarm
The Fault Supervision Data Report management service producer notifies the cleared alarms to the authorized consumer.

### 7.5 O-RU Alarms Management by O-DU in Hierarchical Model
In hierarchical model, O-DU is responsible for managing AlarmRecords in the AlarmList, including O-DU alarms and O-RU alarms. O-DU receives NETCONF based alarm notification from the O-RU, converts NETCONF based alarm notification to O-RAN fault notification, updates AlarmRecords and delivers it to SMO. O-DU alarms and O-RU alarms may have the same alarm-id, they are distinguished using nfcNamingCode in the VES common event header.

## Chapter 8 File Management
This chapter illustrate File Management between the O-DU and the SMO/OAM. The File Management Service is applied to manage file transfer for different types of data file such as Bulk CM file, Cell and UE trace file, Performance Measurement result file, etc. The following file management use cases are supported for the O-DU:
• List available files
• Transfer file
• Download file
• File ready notification

### 8.1 File Structure
The O-DU shall support **the standized folders** for files generated by the O-DU itself and files transferred from O-RUs.

The following standardized folders are defined:
› O-RAN/O-DU/PM/ for performance data files
› O-RAN/O-DU/CM/ for configuration files (except inventory),
› O-RAN/O-DU/NL/ for notification log file
› O-RAN/O-DU/CT/ for call trace files
› O-RAN/O-DU/OT/ for other files
› O-RAN/O-DU/O-RU<RC>/ for files from O-RU which shall follow [4] logical file structure. The RC parameter is a running count, starting with the value of "1", and shall be appended only if the filename is not unique, i.e. more than one file is generated, and all other parameters of the file name are identical.
› The O-DU may additionally support vendor defined folders which are out of scope of this specification.

### 8.2 Notification notifyFileReady

The file ready notification is applied when the management data files have been prepared in the O-DU. The O-DU will send notification using notifyFileReady VES event to subscribed SMO/OAM in order to notify the availability of the file(s).
The following input parameters are provided by the file ready notification:

When a file is available, the O-DU sends a notifyFileReady notification to the SMO using HTTP/TLS as defined in WG1 O1 Interface Spec.


### 8.3 File Management Operation: listAvailableFiles

This listAvailableFiles operation for the SMO/OAM is applied to obtain the available file list with files location and type from the O-DU by reading the AvailableFileList IOC. SMO/OAM may read the O-RU available files which are already stored in the O-DU and can be represented with AvailableFileList IOC.
The following rpc is used for listAvailableFiles operation.


### 8.4 File Management Operation: retriveveFileList

This retriveveFileList operation for the SMO/OAM is applied to retrieve the file list from the O-DU by given related file path. Especially for the O-RU files which are already stored in the O-DU specific file path, the SMO/OAM can retrieve the list with this operation. One or multiple files information can be retrieved by one operation (use of wildcard is allowed).
The SMO/OAM triggers the operation to the O-DU.
The following rpc is used for retriveveFileList operation.

### 8.5 File Management Operation: transferFile
The Transfer File Service provides the capability for the SMO/OAM to transfer files from or to the O-DU. The SMO/OAM may perform this action as a result of a FileReady notification from the O-DU informing SMO/OAM that a file is now available to transfer. In any case, the file transfer is performed using a secure file transfer protocol (SFTP or FTPeS) from or to the location provided by the O-DU. The SMO/OAM triggers file transfer operation to the O-DU.
Detailed procedure can be found in Chapter 2.5.3 of WG1 O1 interface.

### 8.6 File Management Operation: downloadFile
The Download File Service provides the capability for the SMO/OAM to request the O-DU to download the file(s) when the SMO/OAM has a file that needs to be downloaded. In any case, the file download is performed using a secure file transfer protocol (SFTP or FTPeS) from the location provided by the SMO/OAM. The O-DU replies to the SMO/OAM with the result of the download procedure. Detailed procedure can be found in Chapter 2.5.4 of WG1 O1 interface.

## Chapter 9 Synchronization Aspects

# NR C-plane profile
(O-RAN.WG5.C.1-v04.00)
# NR U-plane profile
(O-RAN.WG5.U.0-v04.00)
# Transport Specification
(O-RAN.WG5.Transport.0-v01.00)
# Interoperability Test Specification (IOT)
(O-RAN.WG5.IOT.0-v02.00)