+These modules contain platform specific files and support O-DU High functionality and message exchanges.
+
+
+O1 Module
+^^^^^^^^^^
+
+.. figure:: ODU-O1-Arch.jpg
+ :width: 600
+ :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.
+
+O1 architecture has following components:
+
+- Netconf Manager: 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.
+
+- 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.
+
+- Netopeer server: Serves the northbound SMO/OAM Netconf requests.
+
+
+O-DU-High Interfaces
+======================
+
+
+This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
+
+.. figure:: O-DUHighInterfaces.jpg
+ :width: 600
+ :alt: O-DU High Interfaces
+
+ Figure 3 - O-DU High Interfaces
+
+
+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
+ 3GPP 38.473-f60 v15.3:
+
+ - Interface Management
+
+ - F1 Setup
+
+ - gNB-DU Configuration Update
+
+ - F1 Reset
+
+ - UE Context Management
+
+ - UE Context Setup
+
+ - RRC Message Transfer
+
+ - Initial UL RRC Message Transfer
+
+ - DL RRC Message Transfer
+
+ - UL RRC Message Transfer
+
+ - RRC Delivery Report
+
+- Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
+ implemented, as per ORAN WG3.E2AP v01.00:
+
+ - Global Procedures
+
+ - E2 Setup
+
+ - Near RT RIC Functional Procedures
+
+ - RIC Subscription
+
+ - RIC Indication
+
+- O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported,
+ as per FAPI interface files shared by Intel:
+
+ - P5 messages - PHY mode control interface
+
+ - PARAM.request/PARAM.response
+
+ - CONFIG.request/CONFIG.response
+
+ - START.request
+
+ - STOP.request
+
+ - STOP.indication
+
+ - P7 messages - Main data path interface
+
+ - DL_TTI.request
+
+ - UL_TTI.request
+
+ - SLOT.indication
+
+ - UL_DCI.request
+
+ - TX_Data.request
+
+ - RX_Data.indication
+
+ - CRC.indication
+
+ - UCI.indication
+
+ - RACH.indication
+
+- OAM: O-DU High communicates with OAM on the O1 interface.
+
+
+
+O-DU High functionality
+========================
+
+
+Cell Up and Broadcast Procedure
+--------------------------------
+
+This section describes the cell-up procedure within O-DU High.
+
+.. figure:: CellUpAndBroadcast.png
+ :width: 720
+ :alt: Cell Up and Broadcast Procedure
+
+ Figure 4 - O-DU High Cell Up and Broadcast Procedure
+
+
+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.
+
+- The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
+
+- 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
+
+- On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
+ gNB DU Config Update ACK towards the O-DU High.
+
+- The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
+
+- DU APP sends Cell Start Req towards 5G NR MAC. This message is translated by the Lower MAC into the FAPI message START.request towards the O-DU
+ Low.
+
+- On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
+ The frequency of these slot indications is determined by the numerology(Mu) supported.
+ 5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
+
+- When the first slot indication reaches the DU APP, cell is marked as up.
+
+- The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications.
+ On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
+
+- The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
+
+
+
+UE Related Procedure
+-----------------------
+
+
+The O-DU High supports
+
+- All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
+
+- All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
+
+- All control transport channels - BCH, UL-SCH, DL-SCH, RACH
+
+The above channels are used to achieve the below messages:
+
+- Cell broadcast of System Information which includes SSB and SIB1.
+
+- RACH Procedure
+
+ - RACH Indication
+
+ - Random Access Response
+
+ - RRC Setup Request
+
+ - RRC Setup
+
+- UE attach signalling flow
+
+ - RRC Setup Complete
+
+ - Registraton Request
+
+ - Security Mode Command
+
+ - Security Mode Complete
+
+ - Registraton Accept
+
+ - Registraton Complete
+
+ - Several NAS Message Exchanges
+
+ - RRC Reconfiguration
+
+ - RRC Reconfiguration Complete
+
+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 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 ODU-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
+ :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 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.
+
+- 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.
+
+- 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
+=========================
+
+The O-DU High partially supports below use-cases:
+
+- Traffic Steering
+
+- Health Check