Page Comparison

Scope

This page discusses the requirements, concepts and ideas about the deployment options  and initial configuration of O-RAN Components in different cloud instances.

O-RAN Components are:

• Near-RT-RIC (near real time RAN intelligent controller)
• O-CU-UP (O-RAN centralized unit - user plane)
• O-CU-CP (O-RAN centralized unit - control plane)
• O-DU (O-RAN distributed unit)

According to the O-RAN architecture such components needs to be instantiated in different cloud location creating the RAN. In addition several interfaces between the O-RAN components,  between O-RAN components and the Service Management and Orchestration Framework (SMO) and between O-RAN components and the Mobile core must be instantiated, configured and functionality tested, before the RAN is functional end-to-end.

The bases of such functionally was made in ONAP Frankfurt release and demonstrated several times. 

Requirements

• Pulling CNF images/containers from a centralized catalog
  • Konrad Bańka - Currently it's not possible to include docker images (or others) inside NS/xNF Model, however as long as image is downloadable from registry accessible by cloud region (for example: LF nexus), there is no problem to run it
• Instantiation of a CNF in an cloud environment
  • same environment as the SMO/ONAP is running (done)
  • different cloud locations (regional clouds) 
• Initial configuration of the CNF including 
  • Security settings  - Konrad Bańka  - could be managed with CDS Day0/1 config - see below
    
    • Certificates
    • Access control
  • Interface end points for topological neighbors (A1, O1, E2, F1, N2, N3, ...)
    
    • Konrad Bańka - could be managed with CDS Day0/1 config - see below

Diagrams

• Possible onboarding package content organisation
  • 
     
  • Non-RT-RIC Handled within ONAP thus R-APPS provided as DCAE mS
  • O-RAN sa ONAP Network Service composed of several xNF models
    • Each model could scale to different cloud regions creating new instances
• Cross-References solving with CDS
  • Workflows
    • 
    • Static configuration that either xNF can't update on runtime or is rarely updated could be provisioned with Resource Assignment flow (For example initial replica numbers, interface versions or 5G Core Network endpoints). That config is (typically) gathered in the form of variables that are used during instantiation as Helm Variables (dedicated per vf-module)
    • Some configuration can be also processed just before (config assign) and just after (config deploy) xNF instantiation. This typically includes resolving payload and applying with Netconf/Ansible/Restconf calls to xNFs
  • Configuration Store - AAI (Runtime Instance (meta)data), C&PS (Configuration store)
    • Konrad Bańka C&PS is (I think) supposed to allow cross-instance configuration view/edit and can be a good store for dynamic information such as related to dynamic number of xNF instances