Provide environment for End-to-End testing and demonstration of MVP-C Features from O-RAN.
O-DU Server 192.168.50.191 is not networked correctly. It has limited availability/use.
Lab Access Request Instructions
Editable Lab Diagram (Powerpoint)
Elements in the lab use various networks for both developer access and for operational end-to-end integrations. The following table describe the various lab networks.
Network | Subnet | VLAN ID | Port Range | Purpose |
LabNet | 192.168.50/24 | Odd | General purpose server access network used for project developers to develop, install, and test new contributions. This network is also used for the O2 interface. | |
iDRAC | 192.168.4/24 | LabNet+1 | Out-of-Band management network used to remotely access servers that are no longer accessible due to configuration or power. | |
OAM Plane | 10.0.1/24 | 21 | 1-16 | Network used for communications between the SMO and the network function for configuration and data collection (O1, A1, FH-MPlane) |
Control Plane | 10.0.2/24 | 22 | 17-32 | Network Control interface for communications between network control functions. |
User Plane | 10.0.3/24 | 23 | 33-48 | Network for passing user plane data through the network. |
Custom | Custom | Custom | Custom | These networks are on specialty functions such as the CPRI or eCPRI interface between the O-DU and the O-RU. |
Physical infrastructure within the labs is allocated to an OSC project and is administrated by the PTL or delegated to an individual on the team. Having access to the lab does not equate to access to a server. Individuals are expected to have unique logins to servers such that traceability of activities on the server can be done when errant behavior is detected. To gain access to a server, contact the PTL for the server.
Since lab resources are often reassigned or reused for new functions, they are built according to a template. This allows repurposing without always requiring a lab change request. The following figure shows the two general pattern for server deployments.
The server is configured with all networks, even if not currently needed. Server host are named sequentially when provisioned. Likewise, the ports for the 3 data networks are aligned with their correlative port assignments. IP assignment is also correlated, 10 is added to the number in the host server name to identify the last IP value. For the illustrative example the OSC-INF-01 server has an OAM IP of 10.0.1.11, the Control IP of 10.0.2.11, and a User IP of 10.0.3.11.
The New Jersey lab also uses Openstack Virtual Machines for the SMO, OAM, and Non-RT RIC projects. These machines are connected to both the LabNet and OAM network. Since they are the SMO components they do not need access to the Control and User networks.
The Infrastructure (INF) project builds the O-Clouds. These can be used to deploy on through the O2 interface. An independent Cloud Control Plane network does not exist. Instead the LabNet is used to connect to the O2ims and O2dms endpoints.
The O-Cloud is intended, when complete to support 3 different clusters patterns. The Simplex, Duplex, and Duplex patterns are defined more deeply on the project wiki: https://wiki.o-ran-sc.org/display/IN/INF+Project+Hardware+Requirements. The generalized pattern is shown in the figure below.
The figure also depicts the Integration (INT) Project Server. This server host the INT Open Test Framework (OTF) in which all projects can use to create automated test for unit/feature testing, pairwise testing, end-to-end test/demonstrations. It can also execute a suite of tests such as Release and Certification tests.
As previously noted the SMO, OAM, and Non-RT RIC including rApps run on VMs. We are currently exploring the idea of deploying this on the O-Cloud Duplex Cluster.
The O-DU is a physical server with specialty hardware from Intel to run the FlexRan software as the ODU-Low. The ODU-High is deployed on the server manually and launched. The O-DU has a custom interface through a Fronthaul Gateway to an O-RU simulator.
The O-CU is being converted from a monolithic application on a Centos VM to a bare metal container-based implementation. It will be deployed on the O-Cloud Simplex Cluster.
The Near-RT RIC is currently in an isolated portion of the lab. Simulation (SIM) software is used as element functionality to support the E2 service model is not yet available. We are looking to migrate this to the O-Cloud Duplex+ Cluster in a future release.
The SIM software is currently deployed on VMs but will migrate to the O-Cloud such that either a simulated element or one under development can be placed into the integrated service path.
Currently two hardware platforms are used as simulators. Both are from Viavi. First to the 5G Core simulator which simulates the AMF and UPF elements. The second is an O-RU simulator which can provide messages over the Fronthaul interface to the O-DU simulating UEs in a cell provided by an O-RU.
There are two specialty devices in the lab.