Till Release 8 (Honolulu) the SON use case stored RAN configuration information in ConfigDB with ConfigDB APIs used by SDNR, SON-Handler MS, and OOF. This was based on a BBF Yang Model. During Release 8, we prepared to transition to CPS DB for an ORAN/3GPP-aligned solution which supports both SON and Network Slicing Use cases. For Release 9 onwards, the RAN network modelling approach uses two yang models/trees:

Primary model: ran-network

• Fully aligned with ORAN/3GPP TS 28.541 NRM yang model

• Modular sub-set of ORAN yang model

• Same primary model for all RAN-related ONAP use cases

Secondary model: cps-ran-schema-model

• Data which is not present in ORAN model, e.g., region-to-cell (CU) mapping, latitude/longitude of DU

• Derived information for API/query efficiency, e.g., list of neighbor cells

• Intent to have alignment/efficiency in secondary model for all RAN-related ONAP use cases

Need to maintain consistency of data in primary & secondary model

• Based on CPS architecture

• Current plan: Use TBDMT to read/write to both models at same time

Yang Files:

(lead: @Sandeep Shah )

Primary Yang Model: ran-network

(Add link or file)

Secondary Yang Model - cps-ran-schema-model yang model and yang tree

CPS APIs

The legacy ConfigDB SON APIs used till Release 8 will change to Rel 9 CPS SON APIs. This is closely aligned with CSP APIs developed for Network Slicing.

Links for API information:

CPS APIs

CPS 5G-SON APIs