Page Comparison

11/08 - SON Use Case Jakarata plan presented in Requirements Subcommittee on 11/08/20201 call

Jakarta release - functional requirements proposed list#5GOOFSONUseCase 

2/1

We are presenting SON Use Case in the Arch Comm meeting today 2/1 at 10:30am ET.
There is no impact on Jakarta since we had to descope some requirements.
We are blocked on work that is needed before we can proceed.

M3 Update: We have reduced scope in SON Use case. Following have been removed from Jakarta
so that there is no committed requirement. But work will continue to plan for these items since they remain important.

- CMNotification update processing
- Modification of SON Handler for new VES message
- Inclusion of A1-based actions in SON use case

We had a good discussion about overall objective of SON use case.

ONAP use cases are primarily involved for functions in the SMO.
There are two broad aspects to work:

1. Improve O-RAN alignment for ONAP SON use cases with O1-based actions using information received over O1
2. Plan for ONAP SON use cases providing A1-based guidance and receiving using information received over O1

3/1: Test case for CCSDK-3532 will be added to plan.

Also discussed email (forwarded to Niranjana Y ) from Michał Jagiełło to Malarvizhi Paramasivam about 

automation of test cases for SON use case. Changes are already made to 

https://lf-onap.atlassian.net/wiki/display/DW/Setup+details+-+Integration+test+for+SON+use+case+in+Istanbul

12/09: Yashwanth clarified that he is working on one part of CCSDK-3532 - the DG in SDN-R which use the new yang model.
Created a separate JIRA

12/16:

Good discussion on mapping of SDNR messages to O-RAN yang model and modification of the SDNR DGs.

Details are document in Mapping netconf edits to O-RAN yang model 

3/1:

Changes to SDNR are ongoing. Changes are committed for edit-config change in SDNR

Started making changes in RAN-Sim and re-use models (gnbsim) from Slicing use case and ensure it works for SON Use Case edit-config.

12/09 notes:

Discussion focused on PM VES messages. Thanks to information from Martin and Alex.

There is very relevant work in O-RAN WG10. 

See https://oranalliance.atlassian.net/wiki/spaces/OAMWG/pages/2227307301/PM+Coordination+Team 

In particular, see the Excel table with a list of PM metrics relevant to O-RAN FCAPS

https://oranalliance.atlassian.net/wiki/download/attachments/1608515800/PM-Counter-and-KPI-Repository.xlsx?api=v2

There is consensus in ONAP/OSC/O-RAN to use VES stndDefined domain.

We believe that this will be acceptable to 3GPP and O-RAN. stndDefined domain
requires a schema.

Note that the sample PM message uploaded in

Note that OSC smo project is using VES measurement domain now but wants to move to stndDefined.

Lot of detail about PM metrics and schema have been added in comments in

There are two approaches to provide a reference to the metrics to the systems processing the PM VES message:

1) Current OSC approach: VES message refers to schema and yang model which points to the measurements in the VES message

payload

2) Current ONAP approach: VES message assumes that a PM Dictionary is loaded  initially and this provides a reference for the

measurements in the VES payload. This is supported by the ONAP VES Collector.

In either case, there is more work needed to align with the PM metrics being defined in O-RAN WG10 (based on 3GPP).

Good discussion on including A1-based action. Vishal Varvate is interested in contributing. He will work with John Keeney (Ericsson EST) .
We discussed following plan:

1. Implement A1 instance in SDN-R. Leverage past work in A1, including work for Slicing use case, and OSC.
2. A1-policy trigger will be based on Control Loop msg sent from SON-Handler MS via Policy over DMaaP.
3. RAN-Sim needs enhancement to have xApp abstraction to receive A1 message and update CU/DU state and send VES msg. If A1 policy
   message is about ANR/HO state, it can trigger xApp to make change to CU property. This chain replaces a direct O1 action for current ANR action.
4. RAN-Sim update can leverage work for Slicing. The target for RAN-SIm work is to align with OSC and also plan to move to netopeer due to Honeycomb being archived.
   Possible approach is to add a netopeer-based server for near-rt-roc and xApp abstraction. Implementation of E2 to CU/DU can be abstracted. Details TBD.