| No. | Description | Involved components | Status | Remarks |
| 1 | Regression test - ensure basic PCI use case works from end-to-end perspective (the flow from RAN-Sim → VES → SON-HMS → OOF → SON-HMS → Policy → SDN-R → RAN-Sim → SDN-R → Policy → SON-HMS) | SON-Handler MS, VES, OOF, Policy, SDN-R, RAN-Sim | COMPLETED | This is required due to the functional enhancements done in SON-Handler MS and SDN-R, as well as the refactoring done in Policy. Note: Policy does not send a DCAE-CL-RSP to SON-Handler MS upon completion of the Control Loop. Hence this test case was done by simulating a DCAE-CL-RSP and checking the behavior in SON-Handler MS. However, it does not really affect this test case. |
| 2 | Regression test - ensure basic ANR use case works from end-to-end perspective (the flow from RAN-Sim → VES → SON-HMS → Policy → SDN-R → RAN-Sim → SDN-R → Policy → SON-HMS) | SON-Handler MS, VES, Policy, SDN-R, RAN-Sim | COMPLETED | This is required due to the functional enhancements done in SON-Handler MS and SDN-R, as well as the refactoring done in Policy. |
3 | Successful reception and handling of DMaaP message by SDN-R with CM notification. | DMaaP, SDN-R |
COMPLETED | The trigger for the DMaaP message shall actually come from RAN as a CM-Notify, but now the DMaaP message shall be simulated for the testing, since the CM-Notify VES format wasn't defined in time for Frankfurt, and hence not implemented in RAN-Simulator.
| ||||||||||||||||||
4 | Successful update of ConfigDB with CM notification updates by SDN-R (upon reception of CM notification over DMaaP from RAN) | SDN-R, DMaaP |
COMPLETED |
| ||||||||
5 | Control Loop co-ordination – denial of 2nd control loop trigger (by Policy) received from SON-Handler MS when first control loop is active | SON-Handler MS, OOF, Policy, SDN-R, RAN-Sim |
COMPLETED |
The following has been successfully tested:
With ref. to CLC Denial for 2 different CLs for different targets, there are some fixes to be done in Policy which will be submitted to the master branch, but won’t be part of Frankfurt code base. We will include it as part of the use case demo. The use case documentation will be updated to reflect this. | ||||||||||||||||
6 | Control Loop co-ordination – re-submitting of 2nd control loop trigger (by SON-Handler MS) and initiating appropriate actions (stretch goal) | SON-Handler MS, Policy, SDN-R, RAN-Sim | DEFERRED | This needs further interaction with Policy and the evolution of CLC functionality, it will be taken up in Guilin release. | |||||||||||||
7 | Keep track of PCI updates being successfully implemented in the RAN and update DB accordingly for future optimizations. | SON-Handler MS, Policy, SDN-R, RAN-Sim | COMPLETED | Note: Policy does not send a DCAE-CL-RSP to SON-Handler MS upon completion of the Control Loop. Hence this test case was done by simulating a DCAE-CL-RSP and checking the behavior in SON-Handler MS. | |||||||||||||
8 | Trigger OOF for adaptive SON with FixedPCI cell list (by SON-Handler MS) when previous PCI updates are not implemented in the RAN | OOF, SON-Handler MS | COMPLETED | When there is no further collision/confusion notified from RAN, SON-Handler MS triggers OOF after a timeout to ensure that the configuration is adapted to take into consideration the cells whose PCI values could not be updated (due to whatever reason). There is an issue with this scenario and shall be tracked via the Jira below for Guilin release. However, from a use case functional perspective, it is not needed to be considered for Frankfurt - since there is no collision/confusion reported, it is not "urgent" for the network to re-update the PCI values of other cells. So this scenario shall be taken up with a few other error cases.
| |||||||||||||
9 | Yang-model based schema and API generation for ConfigDB (PoC only) | ConfigDB | NOT APPLICABLE | It will be shown as a PoC demo as originally proposed. The actual work will be done only when O-RAN yang models are available |