docs/sections/services/son-handler/son_handler_overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0\r
   2    International License. http://creativecommons.org/licenses/by/4.0\r
   3    \r
   4 .. _docs_SON_Handler_MS:\r
   5 \r
   6 Architecture\r
   7 ------------\r
   8 The architecture below depicts the SON-Handler MS as a part of DCAE. Only the relevant interactions and components are shown.\r
   9 \r
  10 .. image:: ./dcae_new.jpg\r
  11 \r
  12 The internal architecture of SON-Handler MS is shown below.\r
  13 \r
  14 .. image:: ./son_handler.jpg\r
  15 \r
  16 Description\r
  17 ~~~~~~~~~~~\r
  18 The SON-Handler MS has a REST interface towards OOF as well as DMaaP interface towards Policy, VES-Collector and SDN-R. It has a database and core logic.\r
  19 \r
  20 Core logic\r
  21 ~~~~~~~~~~\r
  22 The core logic is implemented as 3 threads - main thread, child thread(s) for handling neighbor-list updates and collision/confusion alarms from the RAN (via SDN-R), and a separate child for handling handover measurements (PM) inputs from the RAN (via VES-Collector). The Main Thread is responsible for spawning and terminating the Child Threads. The core logic is responsible for:\r
  23 (a) Performing all the pre-processing that is required before triggering OOF for PCI as well as PCI/ANR joint-optimization\r
  24 (b) Autonomously taking actions for ANR updates\r
  25 (c) Preparing the message contents required by SDN-R to re-configure the RAN nodes with PCI/ANR updates\r
  26 \r
  27 The logic may not be 100% fool-proof (i.e., cover all possible scenarios and boundary-conditions as in real field deployments), as well as the most efficient one. An attempt has been made to balance the usefulness for a PoC versus the complexity of handling all possible scenarios. It is intended to provide a good base for the community/users to enhance it further as required.\r
  28 \r
  29 The details of the state machines of all the threads in the core logic are available in https://wiki.onap.org/pages/viewpage.action?pageId=56131985.\r
  30 \r
  31 Database\r
  32 ~~~~~~~~\r
  33 This is a PostgreSQL DB, and is intended to persist information such as the following:\r
  34 - PCI-Handler MS Config information (e.g., thresholds, timer values, OOF algorithm name, etc.)\r
  35 - Pre-processing results and other related information (e.g., neighbor list)\r
  36 - Buffered notifications (i.e., notifications not yet processed at all)\r
  37 - State information\r
  38 - Association between PNF-name and CellId\r
  39 - PM/FM data\r
  40 - Etc.\r
  41 \r
  42 DMaaP Client\r
  43 ~~~~~~~~~~~~\r
  44 This is responsible for registering with the DMaaP client for the DMaaP notifications from SDN-R and VES-Collector, and to Policy.\r
  45 \r
  46 Deployment aspects\r
  47 ------------------\r
  48 The SON-Handler MS will be deployed on DCAE using the mechanism described in "Option 3 - On-Demand deployment through DCAE-Controller cli" at https://wiki.onap.org/display/DW/Dublin+Deployment+Strategy.\r
  49 \r
  50 Known Issues and Resolutions\r
  51 ----------------------------\r
  52 The scope and scenarios addressed are documented in the SON use case page for Dublin - https://wiki.onap.org/display/DW/OOF-PCI+Use+Case+-+Dublin+Release+-+ONAP+based+SON+for+PCI+and+ANR.