X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=blobdiff_plain;f=docs%2Foverview.rst;h=371aab8a1ee2e3c176ef3afd96407511acaa7e19;hb=fec9ccb05a6f0d91127bc51eef34efbba795ec02;hp=61f8ff8c37295f3653839cca7adbc0999ebf5718;hpb=afa3f9350047a92dca19e04dc5181f368b281b8b;p=o-du%2Fl2.git

diff --git a/docs/overview.rst b/docs/overview.rst
index 61f8ff8c3..371aab8a1 100644
--- a/docs/overview.rst
+++ b/docs/overview.rst
@@ -102,22 +102,22 @@ O1 Module
 ^^^^^^^^^^
 
 .. figure:: ODU-O1-Arch.jpg
-  :width: 600
+  :width: 554
   :alt: Figure 2 O1 Architecture
 
   Figure 2 - O1 Architecture 
 
-As shown in figure 2 the O1 module in O-DU High runs a separate process and communicates with ODU-High process over a TCP interface. O1 module uses API calls for interacting with the Netconf server(Netopeer) and datastore(sysrepo) for providing the Netconf interface. 
+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:
 
-- Netconf Manager: Subscribe to Netconf YANG modules and events. Register callback handler methods.
+- Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
 
 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
 
-- TCP server: Receives the alarm messages sent from O-DU High over TCP socket.
+- Unix socket server: Receives the alarm messages sent from O-DU High thread over Unix socket.
 
-- TCP Client Alarm Interface : Integrates with O-DU High module and provides an interface for sending the alarm messages to O1 module over TCP 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.
 
@@ -319,11 +319,11 @@ Figure 5 below depicts the above call flow, inclusive of all interfaces:
 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 ODU-High based on the last self-check performed. The alarm-list is provided as the response to the request via O1 Netconf interface.
+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: 720
+  :width: 869
   :alt: Figure 6 O1 get alarm-list flow  
 
   Figure 6 - O1 get alarm-list flow
@@ -331,13 +331,13 @@ This section describes the *Health Status Retrieval* scenario of O-DU High healt
  
 As seen in the Figure 6,
 
-- On the cell state change from de-active to activate, ODU High process raises a cell up alarm message and sends it over the TCP socket using the TCP client Alarm Interface API.
+- 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 TCP server, running as a thread, in O1 module receives the cell up alarm message and it passes the alarm information to the Alarm Manager.
+- 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 Netconf Manager, is invoked.
+- 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.