Table of Contents
| Table of Contents |
|---|
Sub pages
| Child pages (Children Display) |
|---|
Scope
This wiki describes the test environment for OAM specific test cases focusing on D-Release Closed Loop O-RU recovery use case.
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Components
The following Component diagram shows the most relevant components and their associations from O-RAN-SC OAM project point of view.
The different software components can be deployed with Docker-Compose or Kubernetes technologies.
As O-RAN Alliance targets IPv6 please ensure the Docker IPv6 functionality is enabled (see O-RAN-SC Documentation Docker: Enable IPv6) or use Kubernetes version 1.19 or higher.
Diagram
Imported from Please see Closed loop use case
Descriptions
O-RU - NETCONF-Server-OFH
For D-Release the O-RU operates in "hybrid" mode. This means that the O-RU exposes O-RAN OpenFronthaul NETCONF/YANG interface directly to the OAM functions of the SMO.
For OAM test environment it is recommended to use the O-RU FH simulation from O-RAN-SC Sim project. The docker imager can be loaded directly from O-RAN-SC Nexus (nexus3.o-ran-sc.org:10004/o-ran-sc/nts-ng-o-ran-ru-fh:1.2.3).
The simulation must be configured in a way that is support NETCONF call-home to the SMO-OAM-Controller and supports NETCONF <create-subscriptions/> RPC for stream "NETCONF".
The simulation must not expose any VES messages.
Depending on the OAM controller capabilities TLS certs of the O-RU must be configured at the OAM-Controller.
The following protocols from O-RU to OAM controller are under test:
- NETCONF-Callhome/SSH/IPv4
- NETCONF-Callhome/TLS/IPv4
- NETCONF-Callhome/SSH/IPv6
- NETCONF-Callhome/TLS/IPv6
- NETCONF/SSH/IPV4 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
- NETCONF/TLS/IPv4 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
- NETCONF/SSH/IPV6 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
- NETCONF/TLS/IPv6 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
O-DU - NETCONF-Server-O1
For D-Release the O-DU operates in "hybrid" mode. This means that the O-DU does not expose any management plane functions of connected O-RUs. To reduce the development effort on O-DU it was decided in RSAC meetings that the O-DU at minimum exposes the o-ran-sc-hello-world.yang (see
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
For OAM test environment it is recommended to use the O-DU O1 simulation from O-RAN-SC Sim project. The docker imager can be loaded directly from O-RAN-SC Nexus (nexus3.o-ran-sc.org:10004/o-ran-sc/nts-ng-o-ran-du:1.2.3).
The simulation must be configured in a way that is support NETCONF for configuration management only and VES for heartbeat, fault and pnfRegistration.
Depending on the OAM controller capabilities TLS certs of the O-DU must be configured at the OAM-Controller.
The following protocols from O-RU to OAM controller are under test:
- VES:pnfRegistration https/IPv4
- VES:heartbeat https/IPv4
- VES:fault https/IPv4
- VES:pnfRegistration https/IPv6
- VES:heartbeat https/IPv6
- VES:fault https/IPv6
- NETCONF/SSH/IPV4 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
- NETCONF/TLS/IPv4 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
- NETCONF/SSH/IPV6 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
- NETCONF/TLS/IPv6 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)