# NETCONF and YANG

###### tags: `Frounthaul` `ORAN` `Network` `5G`

> Let study about RAN in ORAN Architecture. :book:

[ToC]
## M-Plane architecture model
A NETCONF/YANG based M-Plane 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-RU. The M-Plane supports two architectural models:
* Hierarchical model. As shown on the left side Figure 5.1.2-1, the O-RU is managed entirely by one or more O-DU(s) using a NETCONF based M-Plane interface.
* Hybrid model. As shown on the right side of Figure 5.1.2-1, the hybrid architecture enables one or more direct logical interface(s) between management system(s) and O-RU in addition to a logical interface between O-DU and the O-RU.
>NOTE: In the hybrid model, the NETCONF clients connecting to the O-RU may be of different privilege classes (e.g., "hybrid-odu", "smo", “swm” or “fm-pm”), allowing functions like O-RU software management, performance management, configuration management and fault management can be managed directly by the management system(s).

there is no explicit signalling to indicate that an O-RU is operating in a hierarchical or hybrid configuration. All NETCONF servers supporting this M-Plane specification shall support multiple NETCONF sessions. All O-RUs shall be able to support both hierarchical and hybrid deployment.
NETCONF/YANG is used as the network element management protocol and data modelling language . Use of such a standardized framework and common modelling language simplifies integration between O-DU and O-RU as well as operator network integration (in terms of running service) in case of elements sharing a common set of capabilities. The framework supports integration of products with differing capabilities enabled by well-defined published data models. NETCONF also natively supports a hybrid architecture which enables multiple clients to subscribe and receive information originating at the NETCONF server in the O-RU.

:::info
#### :bulb: M-Plane functional description
**SW management**
The M-Plane is used for software download, installation, validation and activation of new SW when requested by O-RU Controller. The software download is triggered by NETCONF RPC procedures, and the actual software download is performed using sFTP with SSH or FTPES with TLS as specified in RFC 4217 [54].
**Configuration management**
Configuration management covers various scenarios like Retrieve Resource State, Modify Resource State, Modify Parameters and Retrieve Parameters. NETCONF get-config and edit-config RPCs shall be used for configuration parameter retrieval and updates at the O-RU
**Performance management**
Performance management describes the measurements and counters used to collect data related to O-RU operations. The purpose of Performance Management is optimizing the operation of the O-RU.
>The measurement results are reported by two options:
>* YANG Notification: This option uses the stats definition of YANG model per measurement group. In this case, get RPC and/or notification are used (see clause 10 for more details).
>* File Upload: This option uses the file upload procedure defined in clause12. The measurement results are saved to a data file periodically.

**Fault Management**
Fault management is used for sending alarm notifications to the NETCONF Client. Fault Management allows alarm notifications to be disabled or enabled as well as alarm subscription.
**File Management**
File management allows the O-RU Controller to trigger an O-RU to perform upload of files stored on O-RU to O-RU Controller. The O-RU may provide different kinds of files and retrieved files can be used for various purposes. Simultaneous multiple file upload operations can be supported under the same sFTP or FTPES connection between O-RU to O-DU/SMO.

:::
## YANG module introduction
The data models representing the M-Plane are organized as a set of reusable YANG modules. It is also the intent to reuse the publicly available and generic YANG models as much as possible instead of developing customized O-RAN specific modules. Refer to the various clauses, Annex D and the repository of YANG models for more details on each of these modules.

## "Start-up" installation
At the power-on of O-RU or following an O-RU restart, the following procedures are performed, as illustrated in Figure 6.1-1.
1. (opt) Supplicant PAE is enabled on the port(s)
2. (opt) The O-RU initiates authentication and attempts to perform an EAP authentication dialogue with a peer Authenticator PAE.
NOTE: This does not limit the ability of an Authenticator PAE to initiate the authentication, as defined in clause 8.1 of [70]
3. (alt) EAP failure results in O-RU providing unauthenticated connectivity
4. (alt) EAP Success results in O-RU providing authenticated connectivity
5. O-RU performs M-Plane transport layer resolution (DHCP, MAC, VLAN, IP, etc.) and recovers IP address(es) of O-RU controller(s) and/or pnfRegistration event-collector.
6. The O-RU has not yet enrolled in an operator PKI and O-RU discovers a CA/RA server. O-RU attempts to enrol in operator PKI.
7. After installing the operator issued certificate, the O-RU re-initializes its start-up procedure (jump to step 1)
8. O-RU begins synchronisation of the O-RU against a Primary Reference Clock. Step 8 may be in parallel with step 5 for some O-RU implementation.
9. (opt) O-RU performs NETCONF Call Home to discovered O-RU controller(s)
10. (opt) O-RU performs pnfRegistration to discovered event-collector.
11. O-RU controller performs SSH or TLS connection establishment.
12. O-RU and O-RU controller perform NETCONF capability discovery.
13. (opt) O-RU controller retrieves O-RU schemas using (get-schema) RPC [67].
14. O-RU controller performs optional provisioning of new management accounts (typically only performed once during pre-staging). O-RU controller may perform provisioning of certificate-to-NETCONF username mapping information to the O-RU after account provisioning in case certificate-based client authentication is used.
15. O-RU and O-RU controller perform supervision of NETCONF connection.
16. O-RU controller performs retrieval of O-RU information. (opt) O-RU controller retrieves O-RU S-Plane information and if necessary, it updates the O-RU's S-Plane configuration. (This step may be started any time after step 15 but needs to be completed before step 28).
17. O-RU controller performs SW management.
>NOTE: If an O-RU is running with factory default software, the O-RU functionality is permitted to comprise a sub-set of a fully operating O-RU. In such scenarios, it is recommended that the O-RU controller triggers a software update to fully functioning O-RU software.

18. O-DU performs CU-Plane transport configuration
19. (opt) O-DU performs LBM configuration (CU-Plane over ETH) or enables UDP Echo (CU-Plane over IP).
20. (opt) O-DU performs initial C/U-Plane transport connectivity checking between O-DU and O-RU.
21. O-RU controller retrieves the O-RU delay profile from the O-RU.
22. O-RU controller performs U-Plane configuration between O-DU and O-RU. C/U-Plane transport connectivity between O-DU and O-RU is configured as part of this step.
23. O-DU optionally performs C/U-Plane delay measurements between O-DU and O-RU if the O-RU supports it.
24. O-RU controller performs Fault Management activation by creating a subscription to the YANG notifications defined in the o-ran-fm.yang model. Additionally, the O-RU controller uses the same YANG model to retrieve the list of O-RU's active alarms. See Clause 11 for details.
25. O-RU controller activates performance measurement (if required at start-up timing).
26. O-RU controller retrieves O-RU state, including synchronisation information, from O-RU.
27. O-RU controller configures the O-RU operational parameters.
28. Service available.

## :memo: Transport establishment
Transport Layer interface related information for M-plane contains at least the physical port number, the hardware address of the Ethernet port, VLAN-ID, local IP address, remote IP address, Default Gateway address and Subnet mask.
>In the case of option b) and c), the following clauses are used:
>* O-RU identification in DHCP messages from O-RU (clause 6.2.2).
>* VLAN discovery aspect for M-plane (clause 6.2.3).
>* IP address assignment to O-RU (clause 6.2.4).
>* Discovery of address information of O-RU controller(s) and/or Event-Collector (clause 6.2.5 and/or clause 6.2.7).
## NETCONF call home to O-RU controller(s)
The O-RU aims to have NETCONF sessions with all of the call home O-RU Controller(s), either discovered using the DHCP options defined in clause 6.2.5, provisioned by an existing NETCONF client, or statically configured. An O-RU controller may attempt to autonomously initiate a NETCONF session with the O-RU, e.g., triggered by the pnfRegistration procedure. In order to support NETCONF clients corresponding to call home O-RU Controllers that either do not attempt to initiate a NETCONF session with the O-RU, or are prevented from doing so, e.g., because of Network Address Translation limitations, the O-RU shall call home to all call home O-RU Controller identities with which it does not already have an active NETCONF session.
## NETCONF connection establishment
### General
The identity of the NETCONF server (O-RU) shall be verified and authenticated by the NETCONF client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the NETCONF server.

### NETCONF security
As specified in clause 5.4, this version of the O-RU Management Plane Specification uses TLS 1.2, TLS 1.3, or SSHv2 for mutual authentication between the NETCONF server (O-RU) and the NETCONF client (O-DU or SMO).
If multiple NETCONF sessions are established to an O-RU, those sessions shall be established over separate SSH tunnels/TLS connections.

### NETCONF authentication
The identity of the NETCONF client (O-DU or SMO) shall be verified and authenticated by the NETCONF server (O-RU) according to local policy (X.509 certificate-based or username/password) to ensure that the incoming NETCONF client request is legitimate before any configuration or state data is sent to or received from the NETCONF client. The server shall also perform proper authorization of the client before accepting any request.
### User account provisioning
Each account name in o-ran-usermgmt YANG model is identical to the user-name used in ietf-netconf-acm YANG model. User account provisioning shall include using the ietf-netconf-acm module to define which groups are associated with a particular user-name (see clause 6.5 for details of groups/privileges).
## Monitoring NETCONF connectivity

## Closing a NETCONF session
A NETCONF client closes an existing NETCONF session by issuing the RPC close-session command. The O-RU shall respond and close the SSH session or TLS connection. If the NETCONF client is a Call home O-RU controller, the O-RU shall then re-commence call home procedures, as described in clause 6.3.
Under normal operations, it is expected that at least one NETCONF session with "sudo" or "hybrid-odu" privileges are long-lived and used to repeatedly reset the O-RU's supervision watchdog timer for the NETCONF session. NETCONF clients associated with other privilege groups are not required to operate using persistent NETCONF sessions.
If a NETCONF client has been previously become known to an O-RU by being configured using NETCONF, and the NETCONF client is subsequently removed from the O-RU's configuration, e.g., by a second NETCONF client with "sudo" privileges, the NETCONF server shall force the termination of the NETCONF session to the removed client.

---
:rocket: