Versions Compared

Old Version 1

changes.mady.by.user N.K. Shankaranarayanan

Saved on

compared with

New Version Current

changes.mady.by.user N.K. Shankaranarayanan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agenda

  1. RAN-Sim changes
  2. A1 Policy schema for ANR

Notes

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.

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

ItemWhoNotesJakarata Release 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://wiki.onap.org/display/DW/Setup+details+-+Integration+test+for+SON+use+case+in+Istanbul

3/15:

3 new REQ 1128, 1129, 1130 for M4.
Testing work is on track.
SDNR code changes committed and merged.
RAN-Sim changes need to be merged. Yashwanth to add comment in gerritt.

CCSDK-3532
Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCCSDK-3544
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 

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.

3/15

SDNR code changes committed and merged.
RAN-Sim changes need to be merged. Yashwanth to add comment in gerritt.

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

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyDCAEGEN2-2986
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

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyDCAEGEN2-2986
 

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 

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyDCAEGEN2-2986

and

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyVNFRQTS-1003

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
Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyDCAEGEN2-2988
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.

A1 - based actionGood discussion on A1 - based action

3/30 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.

4/19 Vishal needs info on A1 policy schema for ANR use case. Discussed details. Shankar to follow up.

RAN-Sim

3/8 Further discussion on including netopeer in RAN-Sim. See slides 2-6 in ppt attached here.

View file
nameONAP_RANSim_Enhancement.pptx
height250

3/30 

Vishal presented slides below. We had a good discussion. Option 2 gives a little more flexibility for future use. John said they are willing to help with the A1 termination.
Netconf option instead of Websocket to RAN-Sim controller will need some integration work in RAN-Sim controller. Vishal will work with Niranjana on that.
Also sent a request to present in the ONAP/OSC Harmonization call today 3/30.

View file
nameNearRT-implementation.pptx
height250

4/19 

Discussed change in terminology to avoid confusion. We are not implementing Near-RT RIC and xApp using OSC near-rt-ric.

Decision to change terminology to better capture the nature of the RAN-Sim enhancement.

Plan is to implement

  • A1-Termination
  • RAN App. (The App function is an abstraction which works with RAN-Sim, and does not implement E2 like an xApp on near-rt-ric )