For secondary model handling:
Ideally, See CPS-1434: VES Message to update CPS DB - Developer Wiki - Confluence (onap.org) for a dynamically maintained wiki for CPS DB update.
CPS DB provides a central database to keep track of Configuration of RAN and other elements. CPS Core DB is based on yang models. The CPS NCMP (Network Function CM Proxy) provides mapping and translation function to use CPS Core DB for a particular NF. There is also a Data Model Inventory (DMI ) plug-in which facilitates the identification of particular NF elements and their yang models.
The yang model of the NF device is the primary yang model in CPS DB. If there is additional information that needs to be augmented for a particular use case, such augmentation is in a secondary yang model. TBDMT (Template Based Data Model Transformation) is a module that enables read/write queries on the secondary yang model.
(From Ahila P ).. Ideally, the secondary yang model is used for some internal references like e.g., to get the cell neighbors. The secondary yang model data used in SON use case is dynamic, is dynamic - it needs to be keep changing based on the changes in primary the changes in primary yang model i,.e. for every CM notification. A CM VES Notification trigger triggers the primary yang model update in CPS DB. The entity/module who is going to perform the CPS update for primary model need also needs to do the secondary model update with the data available from primary yang model. Primary As shown in the figure below, the primary model update can happen though DMI Plugin and NCMP and secondary model update still uses the CPS-E-02 interface which happens via CPS-TBDMT. Below is the sequence prepared for Network Slicing use case. We planned to make use of SDN-C for triggering CPS update for primary-model, as mentioned already. You might need to introduce a new module in place of SDN-C.
(Shankar) Update from 12/13 SON call discussion with CPS team (Toine Siebelink and Tony Finnerty ). It may be possible/preferred to collapse and combine steps 4 and 5 in the figure below and have DMI plug-in receive the VES message directly. This assumes the VES message has information to identify the attributes, and update them in an efficient manner. In this case, step 8 trigger to TBDMT will come from CPS NCMP.
Update: Consensus from the team was to have an ONAP DMI Plug-in which receives the VES message over DMaaP, parses the message, and publishes a DMI AVC (Attribute Value Change) message to be received by NCMP (step 6). See the figure in https://lf-onap.atlassian.net/wiki/display/DW/CPS-1434%3A+VES+Message+to+update+CPS+DB
For London release, steps 1,2,3 are being implemeneted. Step 4 to update CPS Core based on DMI-AVC message may be deferred.
