Page Comparison

SON use case weekly calls moved to Thursdays as discussed:

https://lists.onap.org/g/onap-meetings/viewevent?repeatid=32219&eventid=1290763&calstart=2021-10-21 

7/30:
Proposal for SDNR work to have flexibility in using old and new apis for ConfigDB/CPS DB.
Consensus that this approach makes sense.

https://jira.onap.org/browse/CCSDK-3401
 
https://gerrit.onap.org/r/c/ccsdk/distribution/+/122981

8/30 : Sandeep reported that there are some challenges in SDRN/CPS work. These are not hard REQ and so no impact to M3.

9/27 - Sent email to Sandeep asking for meeting to plan leftover JIRA items for J release. 

Presentation of CM Notify Use Case is relevant. See https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=41453037 for use of new O1-aligned CM VES message format.

Discussion on primary and secondary yang models. Idea continues to be "right" approach. 

On topic of geolocation of DU/RU:

1. location of RU is needed for some use cases.
2. If DU is cloud based, then location of DU is less critical.
3. IETF/3GPP have location property for ManagedFunction.
4. O-RAN O1 yang model does not have RU, only have DU.
5. Options:
   1. Add location to secondary model for DU. Assume DU/RU are co-located in integrated GNB
   2. Include RU in secondary model in "simple" manner for PoC and inherit ManagedFunction to bring in location.
   3. Align with OR-RAN WG4 and use both O1 and FH yang models as primary - makes sense if use cases need to address RU.

This topic for PM Streaming was also covered in the input to Req. Call re. ONAP/ORAN Harmonization. See above ppt.

9/27: Discussed requirement to use PM Streaming

10/21: Discussed PM Streaming / PM Data Reporting format. Also attended O-RAN OSC SMO call on 10/21.
Intent is to use stndDefined VES domain. O-RAN OSC is using measurements VES domain. Need to converge of a format and schema to use stndDefined. The objective is to be aligned with the CR being planned for O1 interface in WG10.
Update from OSC SMO call. Mahesh J said that plan in OSC was to use current measurements domain format due to short deadline for Release E and change to stndDefined in next Release F. 
Tentative plan for SON use case would be to work with others and use stndDefined domain.

8/16

Please see email chain about CM format. SON use case can change formats since it is generated

from RAN-Sim. Need to ensure that DCAE VES collector can support the O1-aligned CM message.

8/30 No new discussion

9/27 - Use new message formats in J release

8/9

Would like to have coordination of actions over A-1 and O-1.

Question. How can ONAP components can invoke and use A-1 Adapter.

DMaaP message on A1-P topic did not work with work done for Slicing use case.

Follow up with Dan Timoney about how components in ONAP can talk to A-1 adapter.

8/16

Shankar presented factors involved in determining role of A1 in ONAP-SON use case. Good discussion.

ONAP-SON use case has done a lot of work with O1 interface. We are discussing what is the right way

to add A1 interface. Important to identify the SON function which is suitable for A1 (assuming some abstraction

of A1-xApp-E2 flow). Current thoughts around handoff and neighbor relations as it relates to our work in PCI and ANR.

8/30: 

Note that we presented "Role of A1 and O1 in SON" in the Use Case Req. call.

Meeting link: Use Case Realization Call: Aug 23, 2021

Slides: https://wikilf-onap.onapatlassian.orgnet/wiki/download/attachments/10725183716481849/ONAP_SON_O1_A1_20210823.pptx?version=1&modificationDate=1629738791000&api=v2 

10/21: Discussion of O1 and A1 action. Key point is that if both actions originate from SON-Handler MS, the CM update will come via O1 VES. SON work flows need to explicitly think about how CM update is handled. Options are: (a) MS monitors FM and PM to see if more action is needed. (b) In addition to above, MS also monitors some CM to be aware of state change due to A1 action.

Discussed Krishna's slides on RANSim: See https://lf-onap.atlassian.net/wiki/download/attachments/16488693/A1-RANSIM.pptx?version=1&modificationDate=1634573170000&api=v2

Abstraction of xApp should be part of the Near-RT RIC process. Long-term goal is to see how RANSim can harmonize / integrate /aling with o-du, o-cu, and near-rt-ric work in OSC . It is well understood that different simulators have different function and so there can be different ones. But common areas can be aligned (e.g. use of message formats and netconf server instances etc).