.. figure:: LicHeader.jpg
:width: 600
- :alt: Figure 8 License Header and Footer
+ :alt: Figure 17 License Header and Footer
- Figure 8 : License Header and Footer
+ Figure 17 : License Header and Footer
O-DU High code
---------------
.. figure:: ModeofCommunication.jpg
:width: 600
- :alt: Figure 9 Mode of communication between O-DU High entities
+ :alt: Figure 18 Mode of communication between O-DU High entities
- Figure 9: Mode of communication between O-DU High entities
+ Figure 18: Mode of communication between O-DU High entities
Steps of Communication
++++++++++++++++++++++
.. figure:: StepsOfCommunication.jpg
:width: 600
- :alt: Figure 10 Communication between entities
+ :alt: Figure 19 Communication between entities
- Figure 10: Steps of Communication between O-DU High entities
+ Figure 19: Steps of Communication between O-DU High entities
Communication with Intel O-DU Low
1. **WLS_Open**
- *void\* WLS_Open(const char \*ifacename, unsigned int mode, unsigned long long nWlsMemorySize)*
+ *void\* WLS_Open(const char \*ifacename, unsigned int mode, uint64_t \*nWlsMacMemorySize, uint64_t \*nWlsPhyMemorySize)*
a. Description
- ifacename - pointer to string with device driver name (/dev/wls)
- mode - mode of operation (Master or Slave). Here, O-DU High acts as MASTER.
+ - nWlsMacMemorySize - returns the value of WLS MAC memory Size as O-DU High acts as MASTER
+ - nWlsPhyMemorySize - returns the value of WLS PHY memory Size as O-DU High acts as MASTER
c. Returns pointer handle to WLS interface for future use by WLS functions
b. Input - handle of WLS interface
c. Returns number of available blocks in slave to master queue
+Scheduler Framework with plug-in support
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+5G NR SCH module is encapsulated within 5G NR MAC of ODU-High. Any communication to/from SCH will happen only through MAC.
+The scheduler framework in ODU-High provides support to plug-in multiple scheduling algorithms easily.
+
+Design
++++++++
+
+.. figure:: 5G_NR_SCH_Design.PNG
+ :width: 600
+ :alt: 5G NR Scheduler Framework Design
+
+ Figure 20: 5G NR Scheduler Framework Design
+
+- The code for scheduler has been divided into 2 parts i.e. the common APIs and scheduler-specific APIs.
+- Any code (structure/API) which is specific to a scheduling algorithm must be within scheduler-specific files such as sch_rr.c and sch_rr.h for round-roubin scheduler.
+- Function pointers are used to identify and call APIs belonging to the scheduling algorithm in use at any given point in time.
+- All supported scheduling algorithm are listed in SchType enum in sch.h file.
+- All function pointers are declared in SchAllApis structure in sch.h
+- For each scheduling algorithm, function pointers must be initialised to scheduler-specific APIs during scheduler initialisation.
+
+Call Flow
++++++++++
+
+- In any call flow, a common API calls the scheduler-specific API using function pointer and its output is returned back to the common API, which will be further processed and communicated to MAC.
+
+.. figure:: Multi_Scheduling_Algorithm_Call_Flow.PNG
+ :width: 600
+ :alt: Call flow example of Multi-Scheduling Algorithm framework
+
+ Figure 21: Example of a call flow in multi-scheduling algorithm framework
+
Additional Utility Functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ODU - O1 Communication
^^^^^^^^^^^^^^^^^^^^^^
-O-DU High and O1 module communicate on a TCP socket.
+O1 module runs as a thread in O-DU High.
+
+Alarm communication between the threads happen on a Unix socket.
O-DU High sends alarm messages in the following structure using Alarm Interface APIs.