# Chapter 4 O-RU to O-DU Interface Management
###### tags: `WG4`
## 4.1 O-RU Interfaces
the O-RU’s configuration for its interfaces is defined using the `o-ran-interfaces.yang` module
The O-RU’s interfaces are built on a layering principle where each interface has a unique name.
- All interfaces are referenced by their port-number and name.
- The base interface corresponds to the Ethernet interface.
- leaf
- **12-mtu :** maximum transmission unit
- **alias-macs :** transport the CU plane
- [CoS and DSCP marking](https://silverwind1982.pixnet.net/blog/post/351505688)
- u-plane, c-plane and m-plane traffic.
- As a default, all user-plane flows are marked identically by the O-RU
- Class of service (CoS) is a 3-bit field
- priority code point (PCP) when using 802.1 network
- A single RPC is defined in the o-ran-interfaces module, to enable these counters to be reset.

## 4.2 Transceiver
The o-ran-transceiver YANG module is used to define operational state for the pluggable transceiver module (like SFP, SFP+, SFP28, XFP and QSFP, QSFP+, QSFP28, QSFP56).
With QSFP form factor, the optical links may be multi-wavelengths (4xTx & 4xRx) and/or multi-fibers (MPO - Multifiber Parallel Optic).
- QSFP (Quad Small Form-factor Pluggable)用途:
1.交換機,路由器
2.企業存儲
3.高密度、高速的I/O
4.多通道互連
[什麼是 QSFP?](http://blog.sina.com.tw/optech/article.php?entryid=618856)
The O-RU stores data from the transceiver module on transceiver module detection during startup
The data from the transceiver module is saved in the file. A NETCONF client can upload it by using the File Upload procedure defined in chapter 9.
**The file name shall have the following syntax:**
sfp_{portNumber}.sffcap
**Examples:**
- sfp_0.sffcap
- sfp_1.sffcap
### D.3.3 o-ran-transceiver.yang Module
- unique interface-name
- port-number

### D.3.8 o-ran-ethernet-forwarding.yang Module

### 4.3 C/U Plane VLAN Configuration
Within the o-ran-interfaces YANG model, each named Ethernet interface includes a leaf to indicate whether VLAN tagging is supported. By default, VLAN tagging is enabled on all interfaces. This permits an O-RU to autonomously discover that it is connected to a trunk port, as described in Section 3.1.2.
- The VLAN(s) used to support C/U plane transport may be different from the VLAN(s) used to support management plane connectivity.
- The VLAN assigned to the U-Plane must be the same as the VLAN assigned to the C-Plane for any given `eAxC_ID`.
## 4.4 O-RU C/U Plane IP Address Assignment
the support for C/U plane transport over UDP/IP is optional and hence this section only applies to those O-RUs that support this optional capability.
A NETCONF client can receive a hint as to whether an O-RU supports a particular IP version
- using the `get` rpc to recover the list of interfaces
The IP interface(s) used to support UDP/IP based C/U plane transport may be different than the IP interface(s) used to support management plane connectivity.
When defined by the NETCONF client,this interface shall be configured using:
- Ethernet interface
- interface type is set to ianaift:ethernetCsmacd)
- VLAN interface
- interface type is set to ianaift:l2vlan)
depending upon whether VLANs are used to support IP based C/U plane traffic
[IPv6自動組態配置(IPv6 Auto configuration)](https://www.lijyyh.com/2012/04/ipv6ipv6-auto-configuration.html)
### IPv6 Auto configuration
- **Stateful Address Auto-configuration**
- using DHCP to dynamic obtin 128-bit IP address
- stateful 需要一部伺服器(DHCP server)來維護、存放報流主機的組態訊息
- **Stateless Address Auto-configuration ; SLACC**
- stateless: 無狀態位址自動設定,路由器不會存留對應的資訊
- 從路由器取得首碼(prefix)來產生自己的IP
- Host send `Router Solicitation` to Router
- Router send `Router Advertisemen`t to Host

## 4.5 Definition of processing elements
The CU-plane application needs to be uniquely associated with specific data flows.
This association is achieved by defining an O-RU “processing element” which can then be associated with a particular C/U plane endpoint address [2] or delay measurement operation.
A common processing element is required to be configured for the control and user-plane application components associated with any individual `eAxC_ID`
### supporting the following 3 options:
The O-RU management plane supports different options for defining the transport-based endpoint identifiers used by a particular processing element (used depending on transport environment),
**Processing element definition based on**
- usage of different (alias) MAC addresses
- a combination of VLAN identity and MAC address
- UDP-ports and IP addresses.
### D.3.2 o-ran-processing-elements.yang Module
The o-ran-processing-elements YANG model uses a processing-elements container to define a list of processing elements
Each processing element is identified by a unique element name.

## 4.6 O-DU Verification of C/U Plane Transport Connectivity
As described above, there will likely be multiple C/U-plane data flows being exchanged between the O-DU and the O-RU. In order to enable checks verifying end-to-end transport connectivity between the O-DU and O-RU, the O-RU shall support transport connectivity check capabilities using a request/reply function.
Using that connectivity monitoring procedure, reachability / connectivity checks between user plane endpoints can be performed by the O-DU
- During O-RU configuration, to validate the transport configuration
- At runtime to monitor network connectivity
Two different network protocols are defined for performing the transport connectivity check procedure:
- For C/U sessions over Ethernet: Loop-back Protocol (LB/LBM) as defined by IEEE 802.1Q (amendment 802.1ag) [17].
[What is a Loopback Address? - Definition from Techopedia](https://www.techopedia.com/definition/2440/loopback-address-ip-address)
[Unicast vs Multicast | NETGEAR](https://netgear.techgear.com.hk/pages/business-unicast-vs-multicast)
- When the O-RU supports C/U sessions over IP: UDP echo, RFC 862 [18]

## 4.6.1 Ethernet connectivity monitoring procedure
If the O-RU and O-DU are operating their C/U sessions on Ethernet, the transport connectivity verification checks operate at the Ethernet layer.
Ethernet connectivity monitoring is based on the Loop-back Protocol as defined by IEEE 802.1Q
For the purpose of connectivity monitoring all C/U -plane messaging endpoints in the fronthaul network are part of the same Maintenance Entity (ME).
[](https://www.alliedtelesis.com/sites/default/files/documents/configuration-guides/cfm_feature_overview_guide.pdf)
[802.1ag CFM (2)...](https://guiderworld.blogspot.com/2008/09/8021ag-cfm-2.html)
O-DU send request and O-RU response
- O-DU initiated and stopped the sending of Loop-back Messages (LBMs)
## L2 connection verified based on Loop-back
### Validating the transport configuration
1. starts sending out a predefined number of LBM requests to its O-RU(s) at a predefined interval,
2. storing the information received in LBM responses from the O-RU(s) in an internal database.
3. O-RU(s) are identified by both Ethernet MAC address and the CU plane VLAN.
### Monitor network connectivity
a further procedure may be executed continuously to maintain the connectivity status.
- O-DU continues to send out LBM requests at the configured interval.
- It also keeps track of LBM responses received.
### Managing Ethernet connectivity monitoring procedure
Based on the LBM responses received the O-DU shall decide on the connectivity status
**Connectivity shall be assumed not available**
if no LBM response from the particular O-RU has been received for an interval that is as long as 3 x the configured LBM request interval or longer.
The YANG module provided below supports the configuration and fault management of the Loop-back Protocol as defined by IEEE 802.1Q (amendment 802.1ag).
### D.2.4 o-ran-lbm.yang Module

## L3 connection verified based on UDP
### IP connectivity monitoring procedure
If the O-RU and O-DU are connected using IP (and UDP/IP is being used to transport the C/U plane), these transport connectivity verification checks operate at layer 3
The NETCONF client is responsible for enabling the UDP echo server in the O-RU, triggering the O-RU to listen for UDP datagrams on the well-known port 7.
### Managing IP Connectivity Monitoring Procedure
The NETCONF client uses the `enable-udp-echo leaf` in the udp-echo YANG model to control operation of the UDP echo server in the O-RU
The NETCONF client is able to control the DSCP marking used by the O-RU when it echoes back datagrams using the `dscp-config leaf`
the NETCONF client can recover the number of UDP Echo messages sent by the O-RU by using `echo-replies-transmitted` operational state
### D.2.5 o-ran-udp-echo.yang Module

## 4.7 C/U-Plane Delay Management
The O-RU shall monitor operation of its reception window, monitoring the arrival of packets received over the fronthaul interface relative to the earliest and latest allowable times as defined by the values of T2a_max and T2a_min respectively.

- **T2a_min**: Corresponding to the minimum O-RU data processing delay between receiving the last data sample over the fronthaul interface and transmitting the first IQ sample at the antenna.
- **T2a_max**: Corresponding to the earliest allowable time when a data packet is received before the corresponding firs IQ sample is transmitted at the antenna.
Using the above parameters, (T2a_max – T2a_min): The difference between these two parameters corresponds to the O-RU reception window range.
- **T2a_min_cp_dl**: Corresponding to the minimum O-RU data processing delay between receiving downlink real time control plane message over the fronthaul interface and transmitting the corresponding first IQ sample at the antenna.
- **T2a_max_cp_dl**: Corresponding to the earliest allowable time when a downlink real time control message is received before the corresponding first IQ sample is transmitted at the antenna.
- **Tcp_adv_dl**: Corresponding to the time difference (advance) between the reception window for downlink real time Control messages and reception window for the corresponding IQ data messages
## 4.9 Measuring transport delay parameters
An O-RU may optionally indicate that it supports the eCPRI based measurement of transport delays between O-DU and O-RU, as described in [2].

## 4.10 O-RU Monitoring of C/U Plane Connectivity
The O-RU is responsible for monitoring the C/U plane connection and raising an alarm if the logical C/U-plane connection associated with a processing-element fails
Because of the variety of PHY and C/U plane configurations, the O-RU cannot independently determine the minimum frequency of messages across the fronthaul interface.
- as a default, the O-RU shall use a timer value of 160 milliseconds for monitoring the C/U plane connection
- An O-RU may indicate that its C/U-plane monitoring timer is configurable, o-ran-supervision.yang model
### D.1.1 o-ran-supervision.yang Module