The Radio Edge Cloud blueprint is member of the Telco Appliance blueprint family which is designed to provide a fully integration tested appliance tuned to meet the requirements of the RAN Intelligent Controller (RIC). When complete it will include automated configuration and integration testing from the below the OS up through RIC (from https://gerrit.oran-osc.org/r/#/admin/projects/). As a member of the Telco Appliance blueprint family it shares many hardware and software components, including installation, configuration management and APIs with other family members. Each family member will be a separate appliance with a close family resemblance to its siblings.

Key Attributes

  • Specific hardware configuration that are automatically tested via continuous deployment automation. Multiple hardware variations may be tested in parallel, but each tested configuration will be fully specified and reproducible.
  • Specific pre-boot software (e.g. firmware/BIOS) will be specified as part of the CD tested configuration
  • Reproducible software installation and configuration - an opinionated deployer will allow deployment of large numbers of sites with versioning that is traceable back to automated CD testing
  • Modular building blocks assembled and tested (via CD automation) to ensure a guaranteed level of performance of the target application (RAN Intelligent Controller) while allowing other members of the family to assemble and tune the same modular building blocks to other target applications
  • May be extended in the future to integrate RIC+other application, but still in an appliance with tested/guaranteed performance of the combined application set

Code

Target Hardware

Radio Edge Cloud is intended as a bare metal deployment system, so it does hardware detection using the code in the Hardware Detector repository (ta/hw-detector (tree view)) and therefore may need updates in order to support hardware other than what the active blueprint contributors are using. Such contributions are welcome, but it is worth knowing that the primary contributors are doing all testing on the hardware described in Radio Edge Cloud Validation Lab and Radio Edge Cloud Validation Lab (ARM64) so these are what we have the most experience with. The REC Installation Guide does provide some information on installing on other hardware and we welcome contributions to either the installation guide or the hardware detector repository if there is an interest in improving support for other hardware.

Child Pages

Objective and Context of REC Blueprint

The goal of the REC blueprint is to eventually perform fully automated bare metal deployment of the RIC. Currently The RIC must be installed on top of the REC after the REC's automated installation completes. In order to be useful, the RIC requires a 4G and/or 5G RAN that supports the O-RAN specified interfaces that are used by the RIC. The REC is intended to be deployed into a radio operator's management network with connectivity to the operator's eNodeB/gNodeB radios. The RIC provides a platform as a service environment for running "xApps" which interact with the radios to control them in useful and intelligent ways. For more details about the RIC and xApps refer to O-RAN and the O-RAN Software Community documentation.


Historical Information

Original Proposal Presentation:

  • No labels

1 Comment

  1. Srinivasa Addepalli

    Hi, I am going through the blueprint. I have few questions


    • I understand E2 interface is for both configuration of CU-CP as well as for the transfer of metrics/statistics information for AI based analytics.  Few questions on this:
    1.  I guess RIC will do the inferncing and non-RT system (could be ONAP) do the training. As part of E2 interface,I guess RIC will  read the metrics and store the data in memory for inferencing. Is there any need for any persistent DB in RIC? If so, what DB would be used in this blueprint? 
    2.  Training at non-RT system also require metrics data.  Is the expectation that RAN would send the data to both non-RT and near-RT (RIC) systems? Or does RIC play a role of dispatcher to multiple training non-RT systems?
    3. Does this blueprint specify the E2 messaging (like Kafka or MQTT etc...)?  If it is messaging protocols, where would broker (kafka broker or MQTT broker) get instantiated. In RIC?
    4. Would there be multiple RICs for the same RAN?
    •  Are training and inferencing frameworks part of this blueprint? If so, what are frameworks being thought in this blueprint?


    On Infrastructure Orchestration: 

    • It appears that RIC has K8S orchestrator.  But, Airship does only bring up Openstack today, not K8S clusters for end applications. Is the expectation that Airship is enhanced to deploy K8S cluster for applications?  If so, is the work going to be done in Airship or in Akraino?
    • I also see that OVS-DPDK mentioned as SDN.  Is the intention to use OVN CNI to leverage OVS-DPDK or smartNICs?