# Start up installation
###### tags: `WG4`
This page provides the overall start-up mechanism from the power-on of O-RU to available in service.

## start up procedure

**Pre-condition:**

- Power-ON for O-RU/NETCONF Server or O-RU restart operation.
- Power-ON for O-RU controller/NETCONF Client(s) and/or pnfRegistration event-collector
- Physical interface(s) is(are) connected

**Post-condition:**

- O-RU is ready for the radio transmission to the air on at least one carrier if packet transmission received from O-DU O-RU is ready for the packet transmission to the O-DU if radio reception received at the air on at least one carrier.
- At least one O-RU Controller/NETCONF client with either “super-user” or “hybrid-odu” access privileges can control the
- carrier configuration of the O-RU/NETCONF server in O-RU
- **Start up procedure**


1. 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.
2. O-RU begins synchronization of the O-RU against a Primary Reference Clock. `(Note: step 2 may be in parallel with step 1 for some O-RU implementation.)`
3. O-RU performs NETCONF Call Home to discovered O-RU controller(s) and/or performs pnfRegistration to discovered event-collector `(option)`

7. O-RU and O-RU controller perform supervision of NETCONF connection.

1. O-RU controller performs retrieval of O-RU information
2. O-RU controller performs SW management
3. O-DU performs CU-Plane transport configuration
4. .......

## Management Plane Transport aspects

This sub-section provides the M-plane transport establishment scenario between O-RU and O RU controller(s), such as O-DU and/or SMO.

**Pre-condition:**

- Physical interface is connected.
- When operating in an environment using call-home, the NETCONF server and NETCONF Client(s) have an identical NETCONF call home port configured, to ensure the NETCONF client listens on the same port used by the NETCONF Server.

**Post-condition:**

- Transport Layer address(es) for M-plane are known to O-RU and O-RU controllers.
- O-RU is aware of the physical port(s) for M-plane, e.g., if there are multiple ports in the O -RU.
- O-RU is aware of the VLAN(s) to be used for M-Plane, e.g., if VLANs are used in the transport network.
- Then O-RU is ready to establish TCP connection for NETCONF call home and/or for PNF registration
- **Transport Layer establishment M-plane**
1. Manual Configuration `(alternative)`
2. Automatic Configuration `(alternative)`
1. Stateful DHCP `(alternative)`
1. IPv6 `(option)`
2. Stateless DHCPv6 `(alternative)`


- O-RU identification in DHCP messages from O-RU.
- VLAN discovery aspect for M-plane.
- IP address assignment to O-RU.
- Discovery of address information of O-RU controller(s) and/or Event-Collector.

### O-RU identification in DHCP

---

O-RU shall identify itself to DHCP servers by using DHCP option(s) using the vendor-class-data string within the o-ran dhcp YANG model.

**DHCPv4 Vendor Class Option:**

Vendor Class Identifier Option 60: string

The format of the vendor class string shall be configured to one of the following three options:

1. ““o-ran-ru2/<vendor>
1. , e.g., “o-ran-ru2/vendorA”
2. “o-ran-ru2/<vendor>/<product-code>
1. ”, e.g., “o-ran-ru2/vendorA/ORUAA100”
3. “o-ran-ru2/<vendor>/<product-code>/<serial number>
1. ”,e.g. , “o-ran-ru2/vendorA/ORUAA100/FR1918010111”


## NETCONF call home [NETCONF](https://hackmd.io/KRliuRioS1yHU2OGDkvVug)

The O-RU aims to have NETCONF sessions with all of the known O-RU Controller(s), either discovered using the DHCP options defined in Section 3.1.4, 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
- because of Network Address Translation limitations, the O-RU shall call home to all known O-RU Controllers with which it does not already have an active NETCONF session.
- because of Network Address Translation limitations, the O-RU shall call home to all known O-RU Controllers with which it does not already have an active NETCONF session.

:::info
If the O-RU is unable to establish a NETCONF session with any of the O-RU Controller(s), the O-RU shall use the `“re-call home-no-ssh-timer”` to repeatedly re-perform the call home procedure to all with which is does not have an established NETCONF session.
:::


### [**RFC8071**](https://datatracker.ietf.org/doc/html/rfc8071)

### Motivation

---

Call home is generally useful for both the initial deployment and ongoing management of networking elements. Here are some scenarios enabled by call home:

- The network element may proactively "call home" after being powered on for the first time in order to register itself with its management system.
- The network element may access the network in a way that dynamically assigns it an IP address, but does not register its assigned IP address to a mapping service (e.g., dynamic DNS)
- SSH

public key-based host authentication shall be used for authenticating the server (RFC 4253) by the clients.

- TLS

certificate-based authentication shall be used for mutual authentication between the NECTONF client and NETCONF server.


   1.  The NETCONF/RESTCONF server begins by initiating a TCP connection
       to the NETCONF/RESTCONF client.

   2.  Using this TCP connection, the NETCONF/RESTCONF client initiates
       an SSH/TLS session to the NETCONF/RESTCONF server.

   3.  Using this SSH/TLS session, the NETCONF/RESTCONF client initiates
       a NETCONF/RESTCONF session to the NETCONF/RESTCONF server.

## User Account Provisioning

The NETCONF client with suitable privileges may provision user accounts on the O-RU, including the accounts (users) name, password, group (see Section 3.4 for details of groups/privileges) and whether a particular account is enabled or disabled.

- The account-type is an enumeration, indicating whether password or certificate-based authentication is used for this account

**o-ran-usermgmt.yang Module**


## NETCONF Access Control

This subsection defines the access control for NETCONF clients. Its motivation is that when multiple NETCONF clients (users) are defined, the NETCONF access control mechanism enables the NETCONF server to limit some operations for one client but allow full access for another client. In particular, for hybrid access configuration as introduced in Chapter 2, this allows the privileges associated with the NETCONF client in the O-DU to be distinct and different from the privileges associated with the NETCONF client in the SMO

**Currently six access control groups are defined per NETCONF session:**

`“sudo”`, `“smo”`, `“hybrid-odu”`, `“nms”`, `“fm-pm”`, and `“swm”`.


## Monitoring NETCONF connectivity

When having a session with a NETCONF client with `“sudo”` or `“hybrid-odu”` access privileges, the O-RU operates a watchdog supervision timer to ensure that the session to the NECTONF client is persistent, as described in section 3.4.

O-RU provides NETCONF Notifications to indicate to remote systems that its management system is operational.

The NETCONF client is responsible for automatically enabling the operation of the supervision watchdog timer by creating supervision-notification subscription, whenever the O-RU has an established NETCONF session to a client with `“sudo”` or `“hybrid-odu”` privileges.

**The O-RU uses two timers**

- **Notification timer:**
- **Value:** Equal to supervision-notification-interval (default value: 60s)
- **Operation:** The O-RU sends supervision-notification to those NETCONF clients that have subscribed to receive such notifications
- The O-RU sends supervision-notification, at the latest when the timer expires
- The O-RU Controller confirms that NETCONF connectivity to the O-RU is operational by receiving the notification
- **Supervision timer:**
- **Value :** Equal to supervision-notification-interval (default value: 60s) + guard-timer-overhead (default : 10s)
- **Operation:** The O-RU goes into supervision failure operation when the timer expires.
- This means that a NETCONF client with sudo privileges should repeatedly reset this supervision timer.
- The O-RU confirms that NETCONF connectivity to the O-RU Controller is operational.


### **Client:**

1. An O-RU Controller with `“sudo”` or `“hybrid-odu”` privileges shall be prepared to receive supervision-notification at any time when the watchdog timers are enabled
2. The NETCONF client is responsible for sending supervision-watchdog-reset RPC in order not to cause the Supervision timer to expire

### Server:

1. After the watchdog timers have been enabled, the O-RU is responsible for sending supervision-notification after the expiry of the notification timer.
2. When the O-RU receives an rpc supervision-watchdog-reset, it is responsible for resetting its supervision timer and notification timer

### supervision loop

1. Server send notification to Client
2. Client send <rcp `supervision-watchdog-reset`></rcp> to Server
1. **supervision-watchdog-reset RPC 用來設定timer的值**
3. Server send <rcp-reply><next-update-at>`date time`</next-update-at></rcp-reply> to Client


## Closing a NETCONF Session

A NETCONF client closes an existing NETCONF session by issuing the RPC close-sessioncommand. The O-RU shall respond and close the SSH session or TLS connection. The O-RU shall then re-commence call home procedures, as described in Section 3.2.