2022-02-01 Meeting notes

Jakarata Release 

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

CCSDK-3532

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 CCSDK-3544: Modify SDN-R to use new yang models in netconf session with RAN-SimClosed as a task in CCSDK-3532

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 

DCAEGEN2-2986
(PM VES formats)

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 DCAEGEN2-2986: DCAE impacts for 5G OOF SON use case in Jakarta releaseClosed does not have a schema and is thus incomplete.

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 DCAEGEN2-2986: DCAE impacts for 5G OOF SON use case in Jakarta releaseClosed 

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).

12/16 notes:

We are making progress on the PM VES message formats. Comments are tracked in 
DCAEGEN2-2986: DCAE impacts for 5G OOF SON use case in Jakarta releaseClosed

and

VNFRQTS-1003: Develop new FM/PM/CM VES message formats aligned with O-RAN O1Closed

The child JIRA for VES has been moved under VNFRQTS project. At this time, we believe there is no impact on DCAE VES. 
As per Martin's comment in above JIRA, stndDefined is working with VES-Collector 1.10.1.

Wipro team has said that they are not able to support DCAEGEN2-2988: Modify SON-Handler MS to work with new FM/PM VES formatsClosed for Jakarta release. So this req (2988) is at risk for this release.

2/1 - We have reduced scope and modified requirements since DCAEGEN2-2988 cannot be supported for Jakarta.