- Thread 1: O-DU thread
-- Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, EGTP Handler and ASN.1 Codecs
+- Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, and ASN.1 Codecs
- Thread 3: 5G NR RLC DL and MAC (inclusive of 5G NR SCH and Lower MAC)
- Thread 6: Lower MAC Handler
+- Thread 7: EGTP Handler
+
+- Thread 8: O1
O-DU High Modules
--------------------------
^^^^^^^^^^
.. 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.
+- Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
+
+- VES Agent : Sends the VES events to SMO
- Alarm Manager: Stores and manages(add/updated/delete) alarms.
-- TCP server: Receives the alarm messages sent from O-DU High over TCP socket.
+- Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module 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.
+- Config Interface : Interface to handle the configurations sent from SMO to the stack
- Netopeer server: Serves the northbound SMO/OAM Netconf requests.
- UE Context Setup
+ - UE Context Modification
+
+ - UE Context Release
+
- RRC Message Transfer
- Initial UL RRC Message Transfer
Figure 5 - UE Attach Flow
+- UE Release Signalling flow
+
+ - RRC Release
+
+Closed Loop Automation Procedure
+-----------------------------------
+
+This section describes the closed loop automation procedure within O-DU High.
+
+.. figure:: CLA_call_flow.png
+ :width: 720
+ :alt: Closed Loop Automation Procedure
+
+ Figure 6 - O-DU High Closed Loop Automation Procedure
+
+
+1. SMO commands ODU-High to bring the cell down via O1 interface.
+
+2. DU-APP module of ODU-High sends GNB-DU configuration update message to O-CU. It contains the details of cell to be deleted. O-CU acknowledges this message by sending GNB-DU configuration update acknowledgment.
+
+3. For each UE, DU APP sends UE Context Release Request to O-CU with information about the to be released. O-CU responds with UE Context Release request. It contains the RRC release message. O-DU high sends this RRC Release message to UE.
+
+4. DU APP then sends UE delete request to MAC and RLC. Once a confirmation is received from both MAC and RLC, DU APP deletes UE from its own database as well.
+
+4. Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.
+
+5. Once cell has stopped, DU APP sends cell delete request to MAC. On receiving confimation from MAC, DU APP deletes cell information from its own database as well and sends UE Context Release Complete.
+
+6. On receiving cell bring up command from SMO, the complete Cell bring up and UE attach procedure will be repeated (as explained in above sections)
+
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
+ Figure 7 - O1 get alarm-list flow
-
-As seen in the Figure 6,
+As seen in the Figure 7,
-- 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