Restructure O1 module to run as a thread in O-DU High binary [Issue-Id: ODUHIGH-297]

[o-du/l2.git] / docs / overview.rst

diff --git a/docs/overview.rst b/docs/overview.rst
index f41bc1d..371aab8 100644 (file)
--- a/docs/overview.rst
+++ b/docs/overview.rst
@@ -2,10 +2,12 @@
 .. SPDX-License-Identifier: CC-BY-4.0
 
 
+O-DU High Overview
+*********************
+
 O-DU High Architecture
 ======================
 
-
 O-DU implements the functional blocks of L2 layer of a 5G NR protocol stack in SA(StandAlone) mode.
 These layers primarily include NR MAC, NR Scheduler and NR RLC layers.
 
@@ -96,6 +98,30 @@ O-DU Utility and Common Functions
 These modules contain platform specific files and support O-DU High functionality and message exchanges.
 
 
+O1 Module
+^^^^^^^^^^
+
+.. figure:: ODU-O1-Arch.jpg
+  :width: 554
+  :alt: Figure 2 O1 Architecture
+
+  Figure 2 - O1 Architecture 
+
+As shown in figure 2 the O1 module runs as a thread in O-DU High. Alarm communication happens over a Unix socket between the O1 and O-DU threads. O1 module uses API calls for interacting with the Netconf server(Netopeer) and datastore(sysrepo) for providing the Netconf interface. 
+
+O1 architecture has following components:
+
+- Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
+
+- Alarm Manager: Stores and manages(add/updated/delete) alarms.
+
+- Unix socket server: Receives the alarm messages sent from O-DU High thread over Unix socket.
+
+- Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
+
+- Netopeer server: Serves the northbound SMO/OAM Netconf requests.
+
+
 O-DU-High Interfaces
 ======================
 
@@ -106,10 +132,10 @@ This section describes the other modules that O-DU High interfaces with, as show
   :width: 600
   :alt: O-DU High Interfaces
 
-  Figure 2 - O-DU High Interfaces
+  Figure 3 - O-DU High Interfaces
 
 
-As shown in Figure 2, O-DU High interfaces with the following modules:
+As shown in Figure 3, O-DU High interfaces with the following modules:
 
 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
   data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
@@ -202,10 +228,10 @@ This section describes the cell-up procedure within O-DU High.
   :width: 720
   :alt: Cell Up and Broadcast Procedure
 
-  Figure 3 - O-DU High Cell Up and Broadcast Procedure
+  Figure 4 - O-DU High Cell Up and Broadcast Procedure
 
 
-As seen in the Figure 3,
+As seen in the Figure 4,
 - The DU APP module of O-DU High sends F1 Setup Request to O-CU. This message contains a list of cells that the O-DU High has been configured with.
 
 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
@@ -281,15 +307,39 @@ The above channels are used to achieve the below messages:
 
   - RRC Reconfiguration Complete
 
-Figure 4 below depicts the above call flow, inclusive of all interfaces:
+Figure 5 below depicts the above call flow, inclusive of all interfaces:
 
 .. figure:: UeAttach.png
   :width: 800
   :alt: O-DU High UE Attach Flow
 
-  Figure 4 - UE Attach Flow
+  Figure 5 - UE Attach Flow
+
+
+O1 Netconf get-alarm list procedure
+-----------------------------------
+
+This section describes the *Health Status Retrieval* scenario of O-DU High health-check. It enables a northbound client(SMO) to retrieve the health of the O-DU High based on the last self-check performed. The alarm-list is provided as the response to the request via O1 Netconf interface.
+
+
+.. figure:: ODU-O1-GetAlarmListFlow.jpg
+  :width: 869
+  :alt: Figure 6 O1 get alarm-list flow  
+
+  Figure 6 - O1 get alarm-list flow
+
+ 
+As seen in the Figure 6,
+
+- On the cell state change from de-active to activate, DU APP module raises a cell up alarm message and sends it over the Unix socket using the Alarm Interface API.
+
+- On other side a Unix socket server, running as a thread, in O1 module receives the cell up alarm message and it passes on the alarm information to the Alarm Manager.
+
+- Alarm Manager stores the alarm data in a list.
 
+- Whenever SMO/OAM requires the current alarm list, it sends a Netconf get request. The request is received by the Netopeer Server and a callback method, registered with the Session Handler, is invoked.
 
+- The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface. 
 
 OSC Testcases Supported
 =========================