Update docs for OOF-SON use case

- Added notes for Jakarta release

Issue-ID: REQ-1129
Signed-off-by: nkshankar <nkshankar@gmail.com>
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b

1 files changed, 45 insertions, 21 deletions

diff --git a/docs/docs_5G_oof_son.rst b/docs/docs_5G_oof_son.rst
index 5d97982f4..034d4c2d9 100644
--- a/docs/docs_5G_oof_son.rst
+++ b/docs/docs_5G_oof_son.rst
@@ -13,7 +13,25 @@ Description
 
 The 5G OOF-SON (earlier name was OOF-PCI) use case is an implementation of a **SON (Self-Organizing Networks)** algorithm for Physical Cell ID (PCI) optimization and the centralized Automatic Neighbor Relations (ANR) function (blacklisting a neighbor for handovers) in a 4G/5G network using the ONAP Optimization Framework (OOF).
 
-The use case is a multi-releases effort initiated in Casablanca release. This use case began with the implementation of PCI optimization in Casablanca. In Dublin release, the SON-Handler MS was onboarded as a micro-service in DCAE. Enhancements were made to Policy and SDN-C components.
+The use case is a multi-release effort. This use case began with the implementation of PCI optimization in the Casablanca release. In the Dublin release, the SON-Handler MS was onboarded as a micro-service in DCAE. Enhancements were made to Policy and SDN-C components.
+
+
+RAN Simulator
+~~~~~~~~~~~~~
+
+As part of this use case work, the SON Use Case team developed RAN-Sim, which is a RAN Simulator providing a simulated Radio Access Network (RAN) with a number of netconf servers simulating PNF elements representing gNodeBs. The functionality of the RAN Simulator includes:
+
+- Input of a sample topology of cells, with netconf servers (representing DUs) representing groups of cells
+- Represenation of cell locations and cell neighbor relations
+- Generation of neighbor-list-update messages
+- Generation of alarms for PCI collision/confusion and
+- Generation of handover metrics for different neighbor pairs (for the ANR use case).
+
+All above functionality are enabled using a simple UI.
+
+
+Frankfurt Release
+~~~~~~~~~~~~~~~~~
 
 In Frankfurt release, the following were the main enhancements:
 
@@ -22,6 +40,9 @@ In Frankfurt release, the following were the main enhancements:
 - In addition, the first step towards O-RAN alignment is being taken with SDN-C (R) being able to receive a DMaaP message containing configuration updates (which would be triggered when a neighbor-list-change occurs in the RAN and is communicated to ONAP over VES). `Details of this implementation <https://wiki.onap.org/display/DW/CM+Notification+Support+in+ONAP>`_
 
 
+Istanbul Release
+~~~~~~~~~~~~~~~~~
+
 In the Istanbul release, the following are the main enhancements:
 
 - Updates in FM reporting and fault handling to be in line with VES 7.2, 3GPP and smoother future alignment with O-RAN O1
@@ -29,8 +50,6 @@ In the Istanbul release, the following are the main enhancements:
 - Use CPS for storing/retrieving RAN config data for this use case (was stretch goal, partially addressed)
 - Configuration Management (CM) notifications over VES based on VES 7.2 (was stretch goal, partially addressed)
 
-
-
 The end-to-end setup for the use case requires a database which stores the cell related details of the RAN. This database is ConfigDB till we complete the transition to using CPS DB/TBDMT. The database is updated by SDN-C (R), and is accessed by SON-Handler MS and OOF for fetching (e.g., neighbor list, PNF id, etc):
 
 - `The Config DB implementation <https://github.com/onap-oof-pci-poc/sdnc/tree/master/ConfigDB/Dublin>`_
@@ -42,20 +61,32 @@ As part of Istanbul release work, progress was made towards the goal of transiti
 
 - Secondary model: (e.g, cps-ran-schema-model) This model captures information which is not present in ORAN model, e.g., region-to-cell (CU) mapping, latitude/longitude of DU. This also has derived information for API/query efficiency, e.g., list of neighbor cells. This aligns with operator network model for use cases and applications.
 
-As part of this use case work, a RAN Simulator providing a simulated Radio Access Network
-(RAN) with a number of netconf servers simulating PNF elements has been implemented. The
-functionality of the RAN Simulator includes:
 
-- Generation of neighbor-list-update messages
-- Generation of alarms for PCI collision/confusion and
-- Generation of handover metrics for different neighbor pairs (for the ANR use case).
+Jakarta Release
+~~~~~~~~~~~~~~~~~
 
-All above functionality are enabled using a simple UI.
+In the Jakarta release, the SON Use Case work was impacted by the fact RAN-Sim needed the following enhancements:
+
+- Update of the yang model to the O1 yang models (similar to the models used by the Slicing Use Case)
+- Implementation of an A1 termination with an abstracted xApp and Near-RT RIC which would accept an A1 message and update the CU/DU configuration
+- Planning for a replacement of the Honeycomb netconf engine (project is archived)
+
+The following are the enhancements in the Jakarta release:
+
+- Update of SDN-R netconf code to use the new O1 yang models
+- Update of RAN-Sim to use the new O1 yang models
+
+We have also made progress in the following areas in planning for the Kohn release. 
+
+- Convergence on the VES message formats to be used for FM/PM/CM
+- Inclusion of A1 based actions for the end-to-end SON Use Case
+- Enhancement of RAN-Sim to include abstraction of xApp and Near-RT RIC which would process an A1 message and update of a CU/DU
 
 Please see also `OOF (SON) wiki page <https://wiki.onap.org/display/DW/5G+-+OOF+%28ONAP+Optimization+Framework%29+and+PCI+%28Physical+Cell+ID%29+Optimization>`_.
 Additional information are available related to previous releases can be found
 in `El Alto & Frankfurt OOF (SON) wiki page <https://wiki.onap.org/display/DW/OOF+%28SON%29+in+R5+El+Alto%2C+OOF+%28SON%29+in+R6+Frankfurt>`_.
 
+
 How to Use
 ~~~~~~~~~~
 
@@ -73,20 +104,13 @@ For all instructions about installing the components, please see:
 Test Status and Plans
 ~~~~~~~~~~~~~~~~~~~~~
 
-OOF was enhanced with handling cells with fixed PCI values during the optimization,
-SON-Handler MS was functionally enhanced for adaptive SON functionality, SDN-C (R)
-was enhanced to include handling of DMaaP message for config changes in the RAN,
-and Policy was also enhanced with Control Loop Co-ordination function.
+OOF was enhanced with handling cells with fixed PCI values during the optimization, SON-Handler MS was functionally enhanced for adaptive SON functionality, SDN-C (R) was enhanced to include handling of DMaaP message for config changes in the RAN, and Policy was also enhanced with Control Loop Co-ordination function.
 
 See `test plans <https://wiki.onap.org/display/DW/Testing>`_ for details.
 
 Known Issues and Resolutions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-(a) It is intended to have the RAN Simulator support sufficient Honeycomb netconf server instances to simulate 2000 cells.
-    However, this number may be lower if there are hardware limitations.
-(b) For Control Loop Co-ordination, the denial of a second Control Loop based on Target Lock (i.e., when a second Control
-    Loop tries to operate on the same target (in this case, a PNF) is successfully tested. The CLC is also applied at Control
-    Loop level only. However, some code updates are required in Policy to properly update the Operations History DB entry, and
-    to check the existence of active Control Loops by Policy. This will be addressed in Jakarta release, and tracked via
-    https://jira.onap.org/browse/POLICY-2484
\ No newline at end of file
+(a) It is intended to have the RAN Simulator support sufficient Honeycomb netconf server instances to simulate 2000 cells. However, this number may be lower if there are hardware limitations.
+(b) For Control Loop Co-ordination, the denial of a second Control Loop based on Target Lock (i.e., when a second Control Loop tries to operate on the same target (in this case, a PNF) is successfully tested. The CLC is also applied at Control Loop level only. However, some code updates are required in Policy to properly update the Operations History DB entry, and to check the existence of active Control Loops by Policy. This will be addressed in Jakarta release, and tracked via    https://jira.onap.org/browse/POLICY-2484
+(c) Honeycomb netconf server project has been archived. We are planning to migrate to netopeer.