^^^^^^^^^^
.. 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.
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
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.
Code Review / o-du / l2.git / blobdiff