[ Jira id - ODUHIGH-593 ] Pack and unpack function nomenclature correction

[o-du/l2.git] / docs / developer-guide.rst

diff --git a/docs/developer-guide.rst b/docs/developer-guide.rst
index d254049..0dee609 100644 (file)
--- a/docs/developer-guide.rst
+++ b/docs/developer-guide.rst
@@ -26,9 +26,9 @@ O-DU High uses C languages. The coding guidelines followed are:
 
 .. figure:: LicHeader.jpg
   :width: 600
-  :alt: Figure 6 License Header and Footer
+  :alt: Figure 29 License Header and Footer
 
-  Figure 6 : License Header and Footer
+  Figure 29 : License Header and Footer
 
 O-DU High code
 ---------------
@@ -280,9 +280,9 @@ Here,
 
 .. figure:: ModeofCommunication.jpg
    :width: 600
-   :alt: Figure 7 Mode of communication between O-DU High entities
+   :alt: Figure 30 Mode of communication between O-DU High entities
 
-   Figure 7: Mode of communication between O-DU High entities
+   Figure 30: Mode of communication between O-DU High entities
 
 Steps of Communication
 ++++++++++++++++++++++
@@ -344,9 +344,9 @@ Below figure summarized the above steps of intra O-DU High communication
 
 .. figure:: StepsOfCommunication.jpg
    :width: 600
-   :alt: Figure 8 Communication between entities
+   :alt: Figure 31 Communication between entities
 
-   Figure 8: Steps of Communication between O-DU High entities
+   Figure 31: Steps of Communication between O-DU High entities
 
 
 Communication with Intel O-DU Low
@@ -357,7 +357,7 @@ the following APIs for communication.
 
 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
 
@@ -368,6 +368,8 @@ the following APIs for communication.
 
          - 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
 
@@ -599,6 +601,39 @@ the following APIs for communication.
        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 32: 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 33: Example of a call flow in multi-scheduling algorithm framework
+
 Additional Utility Functions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -752,3 +787,44 @@ Additional Utility Functions
          - cnt - number of bytes to be copied
          - ccnt - number of bytes copied
 
+O1 Module
+----------
+
+Coding Style
+^^^^^^^^^^^^
+
+O1 uses GNU C++ language.
+
+ODU - O1 Communication 
+^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+
+Alarm Structure
+   |   typedef struct
+   |   {
+   |        MsgHeader msgHeader;                           /\* Alarm action raise/clear \*/
+   |        EventType eventType;                           /\* Alarm event type \*/
+   |        char objectClassObjectInstance[OBJ_INST_SIZE]; /\* Name of object that raise/clear an alarm \*/
+   |        char alarmId[ALRM_ID_SIZE];                    /\* Alarm Id \*/
+   |        char alarmRaiseTime[DATE_TIME_SIZE];           /\* Time when alarm is raised \*/
+   |        char alarmChangeTime[DATE_TIME_SIZE];          /\* Time when alarm is updated \*/
+   |        char alarmClearTime[DATE_TIME_SIZE];           /\* Time when alarm is cleared \*/
+   |        char probableCause[TEXT_SIZE];                 /\* Probable cause of alarm \*/
+   |        SeverityLevel perceivedSeverity;               /\* Severity level of alarm \*/
+   |        char rootCauseIndicator[TEXT_SIZE];            /\* Root cause of alarm \*/
+   |        char additionalText[TEXT_SIZE];                /\* Additional text describing alarm \*/
+   |        char additionalInfo[TEXT_SIZE];                /\* Any additional information \*/
+   |        char specificProblem[TEXT_SIZE];               /\* Any specific problem related to alarm \*/
+   |   }AlarmRecord;
+
+
+O1 - Netconf Communication 
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+O1 communicates with the Netconf server using sysrepo and libyang APIs