# Chapter 6 Configuration Management
###### tags: `WG4`

# 6.1 Baseline configuration

This chapter describes NETCONF standard operation (edit-config/get-config/get) [3] which belongs to the CM in Module to modify/retrieve any parameters in YANG modules. Examples below use o-ran-hardware as an example YANG module

- 2 phase (modify/commit) operation using writable running datastore
- 3 phase (modify/commit/confirm) operation using candidate datastore.

### running data

contains the currently active configuration

### candidate datastore

The candidate datastore is used to store configuration prior to committing it to the running datastore. This helps users edit and validate large amounts of configuration without impacting the running database and therefore without impacting the system

All O-RUs shall support 2 phase operation, with 3 phase operations being optional.

## 6.1.1 Retrieve State

O-RU Controller is able to retrieve state which is defined in o-ran-hardware by using NETCONF `<get>` procedure:

### Preconditions:

O-RU Controller has completed exchange of NETCONF capabilities as part of connection establishment between O-RU and O-RU Controllers.

### Post conditions:

O-RU controller has retrieved O-RU state as per request.
## 6.1.2 Modify State

O-RU Controller is able to change state which can be configurable by using NETCONF `<edit-config>` procedure without reset.The configurable state are `admin-state` and `power-state` defined in o-ran-hardware.

- In case of a failure, an error will be returned. Please refer to RFC6241 Appendix A for error codes.
- The vendor can define the behavior after the error occurred.

### [admin-state]

- **locked:** This state indicates that any resource activation is prohibited for the O-RU and all resources have been deactivated administratively.
- **shutting-down:** That usage is administratively limited to current instances of use. It's not mandatory (will be optional).
- **unlocked:** This state indicates that any resource activation is allowed and any resources can be active. The state "unlocked" is the initial state after the reset of the O-RU.


### [power-state]

This state can be controlled by editing the parameter energy-saving-enabled.

- **awake:** This state indicates that the O-RU is operating normally, i.e. not in energy saving mode. The state "awake" is the initial state after the reset of the O-RU.
- **sleeping:** This state indicates that the O-RU is in energy saving mode. M-plane connection and functions are alive whereas other C/U/S functions may be stopped to reduce energy consumption. This state is **optional**


### [oper-state]

O-RU Controller is able to **change oper-state defined in o-ran-hardware** of the O-RU by using remote procedure call **reset**. In this case, the O-RU responds prior to reset operation. Whatever the previous state is, **the O-RU oper-state starts from disabled when O-RU receives reset.**


- **enabled**: O-RU is partially or fully operational
- **disabled**: O-RU is not operational. This is the initial state of oper-sate after the reset of the O-RU

O-RU Controller is able to reset the O-RU, even if the O-RU state is "disabled" or "enabled”.
### [availability-state]

The availability state is derived from detected and active faults and their impact to O-RU’s operation.

The availability state is not affected by faults caused by external reasons.

- **normal:** There is no fault.
- **degraded:** When major or critical fault affecting module or any of O-RU’s subcomponents (e.g. transmitter) is active.
- **faulty:** The critical fault affecting whole O-RU is active and O-RU can't continue any services.

### [usage-state]

**idle:** No carrier is configured in O-RU.
**active:** The carrier(s) is(are) configured in O-RU.
**busy:** No more carrier can be configured in O-RU

## 6.1.3 Retrieve Parameters

O-RU Controller is able to retrieve parameters of the YANG module by using NETCONF `<get>` or `<get-config>` procedure

### Preconditions:

O-RU Controller has completed exchange of NETCONF capabilities as part of connection establishment between O-RU and O-RU Controller(s).

### Post conditions:

O-RU controller has retrieved O-RU parameters as per `<get><source><running/><filter>` or `<get-config><source><running/><filter>` request.

## 6.1.4 Modify Parameters

Before an O-RU Controller modifies the configuration (candidate or running) of an O-RU, it shall first lock the target configuration.

- This prevents other NETCONF clients from changing the shared configuration database until the O-RU Controller releases the lock. I

If another NETCONF client has already locked the configuration datastore, then the O-RU will **respond with a NETCONF error** indicating that **the requested lock is denied**.

:::info
Note, in such circumstances, the O-RU controller should wait for a period of time before re-attempting to modify the O-RU’s configuration
:::

O-RU Controller is able to modify parameters of the YANG module by using the NETCONF `<edit-config>` procedure.

- **O-RU support the candidate configuration datastore**

When supported by an O-RU, the O-RU Controller shall perform any required modify operations **ONLY** on the **candidate configuration datastore** before committing the validated configuration to the **running configuration datastore.**

- **O-RU does not support the candidate configuration datastore**

the O-RU Controller should take extreme care whenever modifying the running configuration datastore as such will likely impact system operation.

### Note, validation of the modified configuration is based on:

1. basic YANG constraints (e.g., min-elements, range, pattern),
2. XPATH based YANG constraints (e.g., leafref, must and when statements),
3. external code which implements YANG constraints (e.g., defined in O-RAN specifications, YANG description statements, etc.).

### Preconditions:

O-RU Controller has completed exchange of NETCONF capabilities as part of connection establishment between the O-RU and O-RU Controller(s).

O-RU Controller has locked the target configuration

### Post conditions:

O-RU controller has retrieved O-RU resource state as per request Success case: The update is confirmed to O-RU Controller. Failure case: Failure reason is provided to O-RU Controller
- **Modify Parameters is used to:**

update parameters of existing leafs

After the modification procedure is complete, the O-RU Controller releases the lock on the target configuration.

# 6.2 Framework for optional feature handling

This section describes the common and optional features about Configuration Management.

## 6.1.5 Deleting Parameters

Before an O-RU Controller deletes any configuration (candidate or running) of an O-RU, it shall first lock the target configuration.

- This prevents other NETCONF clients from changing the shared configuration database until the O-RU Controller releases the lock.

O-RU Controller is able to delete parameters of the YANG module by using the NETCONF `<edit-config>` procedure with the “operation” attribute set to delete.

- If the configuration data does not exist, an <rpc-error> element is returned with an `<error-tag>` value of "data-missing"

### Preconditions:

- O-RU Controller has completed exchange of NETCONF capabilities as part of connection establishment between the O-RU and O-RU Controller(s)
- O-RU Controller has locked the target configuration

### Post conditions:

- O-RU controller has updated the O-RU resource state as per <edit-config> request

**Success case:** The delete is confirmed to O-RU Controller.

**Failure case:** Failure reason is provided to O-RU Controller

Sequential processing is assumed. Only a single `<edit-config>rpc` is allowed at a time. Next `<edit-config>rpc` shall be performed after previous rpc reply.

**Delete Parameters is used to:**

- delete parameters of existing configuration


# 6.3 M-Plane Operational State

The o-ran-mplane-int YANG model allows the O-RU to report the connectivity to NETCONF clients on a per sub-interface level. The client information includes the IP address(es) for the client(s) as well as the link-layer address used to forward packets towards the various management plane clients.

o-ran-mplane-int.yang Module

# 6.4 Notification of Updates to Configuration Datastore

## 6.4.1 Introduction

This sub-section defines an optional O-RU capability which allows O-RU Controllers to configure the O-RU to provide notifications of modifications to its YANG datastore

This capability can be used when the O-RU is operating in a hybrid environment with multiple simultaneous NETCONF sessions established to different O-RU controllers.

## 6.4.2 Subscribing to updates from an O-RU

When an O-DU receives an indication from an O-RU that it supports the optional capability to **support notification of updates** to its configuration data store, as a minimum, **it shall subscribe to the netconf-config-change notification**.