1. General

This clause provides the overall start-up mechanism from the power-on of O-RU to available in service.

Pre-condition:

• Power-ON for O-RU
• Power-ON for O-RU controller
• Physical interface connected.

Post-condition:

• O-RU is ready for the radio transmission to the air 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.
• At least one O-RU Controller with either "super-user" or "hybrid-odu" access privileges can control the carrier configuration of the O-RU/NETCONF server

At the power-on of O-RU, the following procedures are performed

1. O-RU performs M-Plane transport layer resolution and recovers IP address of O-RU controller. (Clause 6)
2. O-RU begins synchronization. (NOTE 1: Step 2 may be in parallel with step 1) （Clause 13 Synchronization）
3. O-RU performs NETCONF Call Home to discovered O-RU controller (Clause 6)
4. O-RU controller performs SSH or TLS connection establishment. (Clause 6)
5. [Auto] O-RU and O-RU controller perform NETCONF capability discovery. (Clause 6)
6. O-RU controller performs optional provisioning of new management accounts (Clause 6)
7. O-RU and O-RU controller perform supervision of NETCONF connection (Clause 6)
8. O-RU controller performs retrieval of O-RU information. （Clause 9 Configuration）
9. O-RU controller performs SW management. (Clause 8 SW)
10. [EDIT-CONFIG] O-DU performs CU-Plane transport configuration
11. (opt) O-DU performs LBM configuration (CU-Plane over ETH) or enables UDP Echo (CU-Plane over IP).
12. (opt) O-DU performs initial C/U-Plane transport connectivity checking between O-DU and O-RU. (Clause 7 Interface)
13. O-RU controller retrieves the O-RU delay profile from the O-RU. (Clause 7 Interface)
14. O-RU controller performs U-Plane configuration between O-DU and O-RU. (Clause 15 O-RU Operations)
15. O-DU optionally performs C/U-Plane delay measurements between O-DU and O-RU if the O-RU supports it.
16. O-RU controller performs Fault Management activation. (Clause 11 Fault)
17. O-RU controller activates performance measurement (if required at start-up timing). （Clause 10 Performance）
18. [GET-STATE RPC] O-RU controller retrieves O-RU state, including synchronization information, from O-RU.
19. O-RU controller configures the O-RU operational parameters. (Clause 15 O-RU Operations)
20. Service available.

總體來說伴澄，1~7 主要與 connectivity 相關(guān)泊交。 8~19 主要與 get寒瓦、set 相關(guān)。
The synchronization procedures started in step 2 needs to be completed before service is available. (需要在開始服務(wù)前檢查同步狀態(tài))

2. Transport aspects

2.1 Establishment

This clause describes the transport layer address of M-plane. Transport aspects of the C-plane and U-plane are covered in clause 7.

Pre-condition:

• Physical interface is connected.
• When using call-home, 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 (if there are multiple ports in O-RU)
• O-RU is aware of the VLAN(s) to be used for M-Plane (if VLANs are used)
• O-RU is ready to establish TCP connection for NETCONF call home

For the transport establishment, there are the following alternatives:

1. Manual transport layer address configuration of O-RU and NETCONF client.
   The NETCONF server shall be able to recover this configured information and use the o-ran-mplane-int.yang model to communicate this operational-state to a NETCONF client.
2. If IPv4 is supported, DHCP server provides O-RU’s transport layer address information and the identity of the NETCONF client. This identity encodes either the transport layer address or FQDN of the NETCONF client. If an FQDN is signalled, the O-RU shall use the DNS server address provided by the DHCP server to recover the IP address corresponding to FQDN of the NETCONF client.
3. If IPv6 is supported, Stateless Address Auto-Configuration (SLAAC) is used to configure the O-RU’s transport address. The DHCPv6 server provides the identity of the NETCONF client

A NETCONF client can receive info about whether an O-RU supports a particular IP version by <get-rpc> to recover the interfaces information and checking the presence of the augmented ipv4 container or ipv6 container in the o-ran-interfaces module.

The O-RU uses the o-ran-dhcp.yang model to expose information signalled by the DHCP server.

Interface related information contains (at least) the physical port number, the HW address of the Ethernet port, VLAN-ID, local IP address, remote IP address, Default Gateway address and Subnet mask.

In the case of option 2 and 3, 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).

2.2 O-RU identification in DHCP

The O-RU shall set the vendor-class-data string in the o-ran-dhcp.yang as the DHCP Vendor Class option(s) to identify itself as an O-RU to DHCP servers.

DHCPv4 Vendor Class Option:

• Option: 60
• 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>", e.g., "o-ran-ru2/vendorA" OR
2. "o-ran-ru2/<vendor>/<product-code>", e.g., "o-ran-ru2/vendorA/ORUAA100" OR
3. "o-ran-ru2/<vendor>/<product-code>/<serial-number>", e.g., "o-ran-ru2/vendorA/ORUAA100/FR1918010111"

The Vendor Class Identifier should be selected to avoid the likelihood that different vendors will select identical strings, e.g., using a vendor namespace registry or ensuring that the identifier includes the <product-code> information.

DHCPv4 Vendor-Identifying Vendor Class Option:

• Option: 124
• Enterprise number: O-RAN-alliance 53148
• Vendor-Class-Data: the format of the string shall follow the rules defined for the DHCPv4 Vendor Class Option

2.3 VLAN Discovery Aspects

Once an O-RU completes its boot-up and Ethernet connectivity is detected on its Ethernet interfaces, the O-RU starts connection establishment.
The O-RU shall determine whether it is connected to an access port or a trunk port.
In particular, when connected to a trunk port, the O-RU shall additionally determine the VLAN identity. The VLAN can be identified by the DHCP server replying to the DHCP DISCOVER message, as described in clause 6.2.5 and clause 6.2.7

An O-RU supporting IPv6 can infer that a VLAN is not used if it receives an IPv6 Router Advertisement without either the "managed address configuration" or "other configuration" bits set.

If the O-RU does not have previously configured management plane VLAN information, the O-RU shall attempt to discover DHCP servers on all its Ethernet ports using untagged Ethernet frames.

When the O-RU has been previously configured with m-plane VLAN information, the O-RU may use this information to optimize its discovery of the VLAN ID(s) used for m-plane connectivity.
Previously configured m-plane VLAN information includes an O-RU that stores the last VLAN(s) used for m-plane connectivity, and/or an O-RU which has been previously configured with a range of m-plane VLANs by a NETCONF client using the contents of the searchable-mplane-access-vlans-info container that have been stored in reset-persistent memory.

If the O-RU does not receive a DHCP OFFER from a DHCP server using untagged frames, or previously configured VLANs, the O-RU should attempt to contact a DHCP server using the full range of VLAN IDs (1~4094) on all its Ethernet ports.

The individual VLAN search algorithm used by an O-RU should ensure timely activation of the M-Plane, because there may be an temporary connectivity problem between the O-RU and the DHCP server causing no DHCP response to be received on the M-Plane VLAN.
The O-RU should repeatedly search using untagged frames and previously configured VLANs whenever it searches across the full range of VLAN IDs.
The O-RU controller is able to recommend the maximum interval between repeatedly scanning for M-Plane connectivity on the untagged and configured VLANs using the scan-interval schema node.
For example, the default scan-interval is 60 seconds. If the O-RU takes 1 second to scan an individual VLAN, then after scanning every 60 out of the full range of VLAN IDs, the O-RU should repeat the scan for M-Plane connectivity on untagged and configured VLANs.

2.4 IP Address Assignment

Automatic IP address assignment for the O-RU m-plane can be achieved using different techniques:

1. IPv4 configuration using DHCPv4

For O-RUs that support IPv6, both stateful and stateless address assignment procedures are supported:

2. IPv6 Stateless Address Auto-Configuration (SLAAC)
3. IPv6 State-full address configuration uses DHCPv6

The above does not restrict the realization of the DHCP server, which may be integrated with the O-DU, may be provided by the transport system, or may be accessed via a relay.

The DHCP server should operate using static bindings. For example, an O-RU identified by a particular hardware address will be re-allocated the same m-plane IP address when it restarts.

2.5 O-RU Controller Discovery

O-RUs that have obtained IPv6 addresses by stateless address auto-configuration, shall use stateless DHCPv6 to obtain m-plane configuration information.
Other O-RUs operating using stateful IPv4 or IPv6 address allocations shall obtain m-plane configuration information during IP address allocation.

The O-RU as NETCONF Server shall be able to recover NETCONF Client information using the following DHCP Options：

• DHCPv4 OPTION_V4_SZTP_REDIRECT (Option Code 143)
• DHCPv6 OPTION_V6_SZTP_REDIRECT (Option Code 136)

These options are defined in RFC 8572 [14] and are used to deliver bootstrap-server-list information to the O-RU.
The O-RU shall use these options to recover the NETCONF client information using the above IANA defined DHCP options.
The O-RU is not required to implement the remainder of the zerotouch capabilities specified in RFC 8572 [14].

The above DHCP option provided information is encoded as a list of server URIs, of the format "https://<ipaddress-or-hostname>[:<port>]", signalled to the O-RU.
The DHCP server shall ensure that all NETCONF client information is encoded with these options.
The O-RU shall use the included port information to decide whether to call home using NETCONF/SSH or NETCONF/TLS. If no call home port is provided, the O-RU shall attempt to call home using NETCONF/SSH.

Other O-RUs which have had their IP address manually configured, shall also have their O-RU Controller(s) manually configured.

For IPv4, the O-RU supporting SZTP shall request the OPTION_V4_SZTP_REDIRECT by including its option code in the Parameter Request List (55) in DHCP discover/request messages.

For IPv6, the O-RU supporting SZTP shall request the OPTION_V6_SZTP_REDIRECT option by including the requested option codes in the Option Request Option.

The DHCP server SHALL include the SZTP option in its response if it supports SZTP and if the DHCP client requested it.
The DHCP server MAY include the SZTP option in its response, if it supports SZTP, even if the client did not request it.

If the DHCP server has not been enhanced with IANA defined DHCP options for zero touch NETCONF capability, an O-RAN defined vendor specific option can be used to signal all NETCONF client information to the O-RU using option 43 for DHCPv4 and option 17 for DHCPv6.
The O-RU shall request this option.
Depending on the DHCP request of the client and its own capabilities, the DHCP server shall respond with either the SZTP option, the vendor specific option, or both. Multiple instances of NETCONF client information may be signalled, encoded as a sequence of type/length/value fields.

The definition of the types used within the DHCPv4 option 43/DHCPv6 Option 17 depends on the vendor-class option reported by the O-RU in its DHCP messages.

When a legacy O-RU reports its vendor-class using the "o-ran-ru" prefix, the following types are defined:
Type: 0x01 – O-RU Controller IP Address
Type: 0x02 – O-RU Controller Fully Qualified Domain Name

When the O-RU reports its vendor-class using the "o-ran-ru2" prefix, the following types are defined:
Type: 0x81 – O-RU Controller IP Address
Type: 0x82 – O-RU Controller Fully Qualified Domain Name
Type: 0x86 – O-RU Call home protocol

In all cases, the Type is followed by the length, which is the hexadecimal encoding of length of value field in octets, and the Value.

When Type corresponds to an O-RU Controller IP Address, the value encodes IPv4 address(es) in hexadecimal format. For example, a single server with IPv4 address 198.185.159.144 will be encoded in an option 43 TLV as
Type 0x81 (or 0x01 for legacy)
Length: 0x04
Value: C6 B9 9F 90

When Type corresponds to an O-RU Controller Fully Qualified Domain Name, this encodes the string representation of domain name. For example, a server with FQDN "controller.operator.com" will be encoded in an option 43 TLV as
Type 0x82 (or 0x02 for legacy)
Length: 0x17
Value: 63 6F 6E 74 72 6F 6C 6C 65 72 2E 6F 70 65 72 61 74 6F 72 2E 63 6F 6D

The format of the DHCPv6 option 17 follows the format of the DHCPv4, with an additional Enterprise Number prior to the TLV option data.
The IANA allocated private enterprise number to be used with DHCPv6 option 17 is 53148.

When Type corresponds to the call home protocol, the value encodes whether an O-RU shall call home using NETCONF/SSH or NETCONF/TLS using the IANA defined ports as specified in RFC 8071 [15].
If no call home protocol type is provided, the O-RU shall use NETCONF/SSH.
The format is encoded as follows:
Value 00 - O-RU shall attempt to call home using NETCONF/SSH
Value 01 - O-RU shall attempt to call home using NETCONF/TLS

For example, a DHCP server wanting to trigger the call home procedure using NETCONF/TLS will encode the option 43 TLV as
Type: 0x86
Length: 0x01
Value: 01

When responding with both SZTP and vendor specific options, a DHCP server implementation should ensure the information in the SZTP_REDIRECT option is consistent with the information in the vendor-specific option. If there is an inconsistency, an O-RU supporting SZTP shall use the information provided in the SZTP_REDIRECT option over the vendor-specific option.

2.6 Multi-Vendor Plug-and-Play

See Chapter 6.4.2 first.

An O-RU shall report any discovered multi-vendor plug-and-play servers using the o-ran-dhcp YANG model.

3GPP 33.310 [51] specifies the use of CMPv2 used by base stations to obtain an certificate.
While the approach has been defined for provisioning certificates for use in either IPSec or TLS, the same techniques defined for provisioning TLS certificates are specified to be re-used here to provision certificates for use in securing the SSHv2 based M-Plane connection as specified in RFC 6187 [31].

The handling of certificates, including certificate profiles, shall follow the rules defined in 3GPP 33.310 for TLS CA certificates. In addition:

• when an O-RU generates a certificate signing request it shall populate the Subject Distinguished Name field with a string that includes the O-RU manufacturer’s name, model and serial number. The exact Subject DN sub-field used is defined in the operator of the Certification Authority (CA/RA) server’s certificate policy.

2.7 Event-Collector Discovery

This clause describes how an O-RU discovers the Event-Collector to which it shall send its pnfRegistration notification.
The support by an O-RU of PNF Registration to a discovered Event-Collector is optional and hence this clause only applies to those O-RUs that support this capability.

O-RUs that have obtained their IPv6 addresses by stateless address auto-configuration, shall use stateless DHCPv6, as specified in RFC8415 [58], to obtain Event-Collector information.
Other O-RUs operating using stateful IPv4 or IPv6 address allocations shall obtain Event-Collector information during IP address allocation.
Other O-RUs which have had their IP address(es) manually configured, shall also have their Event-Collector(s) and Event-Collector Notification Format manually configured.

The O-RU supporting PNF Registration shall be able to recover Event-Collector information using O-RAN defined vendor specific option to signal Event-Collector information to the O-RU using option 43 for DHCPv4 and option 17 for DHCPv6.
To achieve that, the O-RU shall request the option 43 for DHCPv4 and option 17 for DHCPv6 as defined in clause 2.5.

The definition of the types used within the DHCPv4 option 43/DHCPv6 Option 17 are as follows:
Type: 0x83 – Event-Collector IP Address
Type: 0x84 – Event-Collector Fully Qualified Domain Name
Type: 0x85 – Event-Collector Notification Format

In this version of the specification, the operation of an O-RU when receiving multiple instances of the Event-Collector IP Address and/or Event-Collector FQDN information is not defined.
In all cases, the Type is followed by the length, which is the hexadecimal encoding of length of value field in octets, and the Value.
In this version of the specification, the operation of an O-RU when receiving an Event-Collector FQDN that is subsequently resolved by the O-RU to more than one IP address (i.e., returning multiple Address records) is not defined.

3 NETCONF Call Home to O-RU Controller(s)

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 clause 6.2.5, provisioned by an existing NETCONF client, or statically configured.

If the O-RU is unable to establish a NETCONF session with some of the known O-RU Controller(s), the O-RU shall use the "re-call-home-no-ssh-timer" to repeatedly re-perform the call home procedure.

If the O-RU is unable to trigger the establishment of NETCONF session with at least one known O-RU Controller after having repeated the call home procedure a total of max-call-home-attempts per O-RU Controller, then the O-RU should perform an autonomous reset.

The O-RU shall use RFC 8071 [15] whereby the O-RU initiates a TCP connection to the NETCONF client.
The port used by the O-RU shall be the one signalled using the DHCP option as specified in RFC 8572 [14], else, if no port was signalled, the O-RU shall use the IANA-assigned port 4334 to indicate that the O-RU wants to use SSHv2 to secure the NETCONF connection and the IANA-assigned port 4335 to indicate that the O-RU wants to use TLS to secure the NETCONF connection.
When the NETCONF client accepts a TCP connection on the allocated port, it initiates an SSH session/TLS connection with the NETCONF Server. Using this SSH session/TLS connection, the NETCONF client initiates a NETCONF session.

The O-RU shall ensure that a persistent connection to any NETCONF client with "sudo" privileges is maintained by actively testing the aliveness of the connection using the keep-alive mechanism defined in [15]. The establishment of NETCONF client privileges is covered in clause 6.5.

4 NETCONF Connection Establishment

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/state data is sent to or received from the NETCONF server.

When using SSHv2, public key-based host authentication shall be used for authenticating the server (RFC 4253) by the clients. In addition, server authentication based on X.509 certificates may also be provided [31].
When using TLS, X.509 certificate-based authentication shall be used for mutual authentication between the NETCONF client and NETCONF server.

NOTE: Public key-based authentication requires that the SSH server (O-RU) public keys are provisioned in the NETCONF client. As an alternative, RFC4251 mentions that "a possible strategy is to only accept a host key without checking the first time a host is connected, save the key in a local database, and compare against that key on all future connections to that host. ". This option simplifies the procedure but obviously at the price of degraded security, therefore the support of this option shall be configurable and left to operator’s choice.

Security
This version of specification uses TLS 1.2, TLS 1.3, or SSHv2 for 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
This version of specification supports SSHv2 using password authentication as specified in RFC 4252 [6] and client authentication based on X.509 certificates as specified in RFC 6187 [31], and TLS 1.2, or TLS 1.3, using X.509 certificate-based authentication.

If authentication is based on X.509 certificates, for the purposes of user authentication, the mapping between certificates and user-name is provided by the SubjectAltName field of the X.509 certificate, which means that the user name is coded in the subjectAltName. The username is determined from the subjectAltName using the rules defined in RFC 7589 [41]. For the purposes of NETCONF server authentication, RFC 7589 [41] specifies server identity as specified in RFC 6125 [40].

Upon initial system initialization, the O-RU is configured with a default account.
The specific details of the default account are to be agreed between operator and vendor.
An example of a default user account for account-type PASSWORD is one with username "oranuser".
An example of a default user account for account-type CERTIFICATE is map type "san-rfc822-name" with an rfc822-name of "oranuser@o-ran.org".
The default account may be of account-type PASSWORD, in which case a default password also needs to be defined and configured in the O-RU, for example "o-ran-password".

As the default account may be operator specific, this may require that the O-RU provides facilities to configure securely this default account at installation time.

If user authentication is based on X.509v3 certificate during O-RU plug and play, to support zero touch for the first NETCONF connection, the O-RU shall support the default mapping between certificate and default NETCONF account which will map any authenticated X.509 v3 certificate to this default O-RAN account.

During O-RU Plug and Play, the trust anchor for O-RU shall be provisioned automatically with online CA server. And the trust anchor of the O-RU Controller(s) shall be the same, thus avoiding the need for manual configuration of the peer trust anchor for O-RU.

The default account is a member of the "sudo" group (see clause 6.5 for details of groups/privileges) as it can be used to create other accounts (see clause 6.4.3).

The identity of the SSH client (NETCONF client) shall be verified and authenticated by the SSH server (O-RU) according to local policy.

Upon initial system initialization, the NETCONF client can authenticate itself to the O-RU using SSH Authentication, with the agreed default username and password.

If authentication based on X.509 certificates according to [31] is supported by SSH client and server, the certificates need to be installed at initial system initialization, or can be obtained through certificate enrolment with operator’s PKI (certificate enrolment as defined by 3GPP with CMPv2 protocol between the NE and the operator’s CA).

User Account Provisioning
The NETCONF client with suitable privileges may provision user accounts on the O-RU, including the username, password, group (see clause 6.5 for details of groups/privileges) and whether a particular account is enabled or disabled.

• The name for the user is a string which should be between 3-32 characters.
• The account-type is an enumeration, indicating whether password or certificate-based authentication is used for this account.
• The password is a string between 8-128 characters. The password leaf is not present for those user accounts associated with certificate-based authentication.
• The access control group associated with an account
• Whether an account is enabled. The YANG model ensures that at least one user account is always enabled on the O-RU

The new account information (user name, password, access group and whether the account is enabled) shall be stored in reset-persistent memory in O-RU.

If certificate-based client authentication is used, at time of SSH connection, user’s authorization is done based on the X.509 certificate’s SubjectAltName field that codes the associated account’s name.

When other user account (sudo) is created, the NETCONF client closes existing NETCONF session as described in clause 6.8. Then, the O-RU disables the default account and default account stays disabled over the resets. The default account becomes enabled when the O-RU is reset to the factory default software by following the procedures defined in clause 8.8. Any other way to enable the default account is not precluded as O-RU vendor implementation matter.

5 NETCONF Access Control

This clause defines the access control for NETCONF clients.
Its motivation is that when multiple NETCONF clients 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.

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

Currently six access control groups are defined per NETCONF session: "sudo", "smo", "hybrid-odu", "nms", "fm-pm", and "swm". Table 6.5-1 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.

It is recommended that when operating in hybrid mode of operation, the NETCONF client in the O-DU is associated with the "hybrid-odu" privilege group and the NETCONF client in the SMO is associated with the "smo" privilege group.

6 NETCONF capability discovery

The O-RU 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.

7 Monitoring NETCONF connectivity

This clause provides description of NETCONF connectivity monitoring for persistent NETCONF session.
Additional procedures for O-RUs that support the optional NON-PERSISTENT-MPLANE feature to monitor the communication path between the O-RU and Event-Collector are defined in clause 18.6.

When having a session with a NETCONF client that has subscribed to receive the supervision-notification, the O-RU operates watchdog timers (supervision timer and notification timer) to ensure that the session to the NETCONF client is persistent.
The O-RU provides NETCONF Notifications to indicate to remote systems that its management system is operational.

An O-RU controller that has subscribed to the supervision-notification is expected to use the <supervision-watchdog-reset> RPC to indicate to O-RU the O-RU controller is operational.

Clause 6.5 describes which NETCONF clients have privileges to subscribe to the supervision-notification.

A NETCONF server shall support the operation of individual supervision watchdog timers for each NETCONF client which has subscribed to supervision-notification.

The privileged NETCONF client is responsible for automatically enabling the operation of the watchdog timers by creating supervision-notification subscription. After operation of watchdog timers is enabled - the timers are considered as running.

The O-RU uses two timers, referred generically as watchdog timers, to support the bi-directional monitoring of NETCONF connectivity:

• 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 value: 10s)
  Operation: The O-RU identifies supervision failure when the timer expires. To avoid supervision timer expiration, a NETCONF client who has subscribed to receive the supervision-notification should repeatedly reset this supervision timer. Such supervision timer reset is considered by O-RU as confirmation that NETCONF connectivity to the O-RU Controller is operational.

Notification timer 用于 O-RU controller 檢查它到 O-RU 的連接岛宦。
Supervision timer 用于 O-RU 檢查它到 O-RU controller 的連接。

The O-RU enables dedicated watchdog timers for specific NETCONF client when it receives a <create-subscription> RPC from a NETCONF client with required privileges.
The notification timer shall be started when the O-RU receives a <create-subscription> RPC, but how the O-RU treats the supervision timer is up to O-RU’s implementation based on the above definition.
After the watchdog timers have been enabled, the O-RU is responsible for sending supervision-notification after the expiry of the notification timer.

The NETCONF client is responsible for sending supervision-watchdog-reset RPC in order not to cause the Supervision timer to expire, and the O-RU should send next notification timestamp as next-update-at in reply.

next-update-at is just informative.

In the supervision-watchdog-reset RPC, the NETCONF client may configure new values for the watchdog timers using RPC parameters "supervision-notification-interval" and "guard-timer-overhead.
When the O-RU receives the supervision-watchdog-reset RPC, it is responsible for resetting its supervision timer and notification timer.
When the watchdog timers are running, the O-RU shall be prepared to receive supervision-watchdog-reset RPC at any time - also within supervision timer period.

The NETCONF client can set new value of watchdog timers without receiving supervision-notification from the O-RU.
The new values are taken into use immediately with respect to supervision-watchdog-reset RPC content.
The next notification should be expected not later than at the moment addressed in timestamp provided by RPC reply.

If another NETCONF client has locked the running configuration, and if the O-RU Controller attempts to configure the watchdog timer(s) by sending the supervision-watchdog-reset RPC, then the RPC operation to reset the watchdog timer will succeed, but the implementation to modify the watchdog timer(s) may fail. In such circumstances, the O-RU may use the error-message in the RPC output to indicate to the O-RU Controller that the configuration modification has failed.

If the supervision timer expires, the O-RU will enter "supervision failure" condition, as described in clause 14. If all NETCONF sessions to NETCONF clients with "sudo" privileges are closed, the O-RU shall immediately disable operation of the supervision timer.

8 Closing a NETCONF Session

A NETCONF client closes an existing NETCONF session by issuing the close-session RPC. 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 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.
NETCONF clients associated with other privilege groups are not expected to operate using persistent NETCONF sessions.

9 PNF Registration

The support by an O-RU of PNF Registration to a discovered Event-Collector is optional and hence clause 6.9 only applies to those O-RUs that support this optional capability.
An O-RU that support pnfRegistration shall also support the Monitoring the Communications Channel between O-RU and Event-Collector as defined in clause 18.6.

The pnfRegistration notification is a JSON encoded message sent from the O-RU to the discovered Event-Collector using REST/HTTPS.
As a pre-condition, the O-RU first receives the Event-Collector information encoded in a DHCP/DHCPv6 option as described in clause 6.2.7.
The O-RU shall attempt to establish a HTTP connection to the discovered Event-Collector using TLS to authenticate the connection. It shall then signal the pnfRegistration notification over the HTTP/TLS connection. The sending of the pnfRegistration notification is repeated periodically until the SMO establishes a NETCONF session with the O-RU.

An O-RU that is performing the PNF registration procedure and the call home procedure described in clause 6.3, shall be able to determine that the SMO has established a NETCONF session with the O-RU.
This is identified by the O-RU analysing the source IP. With the assumption that the NETCONF session from the SMO has an IP address that is distinct from the IP address(es) of the "known O-RU Controller(s)" to which the O-RU is performing the call home procedure.

In this version of the specification, the encoding of the pnfRegistration notification follows the ONAP definition [i.2].