aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorkrishnaa96 <krishna.moorthy6@wipro.com>2021-09-15 14:47:33 +0530
committerkrishna moorthy <krishna.moorthy6@wipro.com>2021-09-15 09:30:23 +0000
commit66d62e02e7bfeefbc727300a6dd2a02555a9a22a (patch)
treec23cbfcfff92e6515ad0790570d6a03404871b86 /docs
parentf11748cfe6b1b40e793da413e1729de086e229a3 (diff)
Update docs for OOF-SON use case
- Update name to be oof-son instead of oof-pci - Added a few lines about primary/secondary yang models - Updated known issues Issue-ID: REQ-910 Signed-off-by: krishnaa96 <krishna.moorthy6@wipro.com> Change-Id: Ife4fec1448a28a7cb6ddead8527fe80fc9643ea6
Diffstat (limited to 'docs')
-rw-r--r--docs/docs_5G_oof_pci.rst36
1 files changed, 25 insertions, 11 deletions
diff --git a/docs/docs_5G_oof_pci.rst b/docs/docs_5G_oof_pci.rst
index bd71d7f41..695521026 100644
--- a/docs/docs_5G_oof_pci.rst
+++ b/docs/docs_5G_oof_pci.rst
@@ -1,22 +1,22 @@
.. This work is licensed under a Creative Commons Attribution 4.0
International License. http://creativecommons.org/licenses/by/4.0
-.. _docs_5G_oof_pci:
+.. _docs_5G_oof_son:
:orphan:
-OOF-PCI
+OOF-SON
--------
Description
~~~~~~~~~~~
-The 5G OOF-PCI use case is an implementation of a **SON (Self-Organizing Networks)**
+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 Dublin release.
+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.
@@ -31,12 +31,29 @@ In Frankfurt release, the following are the main enhancements:
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>`_
-The end-to-end setup for the use case requires a Config DB which stores the cell related details of the RAN.
-This is updated by SDN-C (R), and is accessed by SON-Handler MS and OOF for fetching (e.g., neighbor list, PNF id, etc):
+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
+- Alignment with 3GPP NRM/O-RAN yang models for SON use case
+- Use CPS for storing/retrieving RAN config data for this use case (stretch goal)
+- Configuration Management (CM) notifications over VES based on VES 7.2 (stretch goal)
+
+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>`_
- `Swagger JSON API documentation <https://github.com/onap-oof-pci-poc/sdnc/blob/master/ConfigDB/Dublin/SDNC_ConfigDB_API_v3.0.0.json>`_
+As part of Istanbul release work, progress was made towards the goal of transitioning from ConfigDB to CPS DB.
+CPS DB is fully based on yang models, and we have developed a modeling approach using two yang models:
+- Primary model: (e.g., ran-network). This is a modular sub-set of, and fully aligned with, ORAN/3GPP 28.541 NRM yang model
+ This aligns with Device models, Vendor models (base and extensions)
+- Secondary model: (e.g, cps-ran-schema-model) This model captures ata 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:
@@ -83,8 +100,5 @@ Known Issues and Resolutions
(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 Guilin release, and tracked via
- https://jira.onap.org/browse/POLICY-2581 and https://jira.onap.org/browse/POLICY-2583.
-(c) For Adaptive SON, the functionality in SON-Handler and OOF is implemented, however the OOF functionality is not
- fully tested (this was anyhow a stretch goal). Further, the DCAE-CL-RSP message is not sent by Policy in Frankfurt release.
- This is tracked via https://jira.onap.org/browse/POLICY-2580 and shall be part of Guilin release.
+ 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