X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=blobdiff_plain;f=docs%2Fdeveloper-guide.rst;h=550784183264851913e4fe08342c277d474fe38e;hb=7be3f80c289304edaa42f6f46a30015aad04747a;hp=d25404950e47f4b093370911248866429ca8cfcb;hpb=ddcc8cc613851becbb4a0727b7c51db046a3998d;p=o-du%2Fl2.git diff --git a/docs/developer-guide.rst b/docs/developer-guide.rst index d25404950..550784183 100644 --- 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 17 License Header and Footer - Figure 6 : License Header and Footer + Figure 17 : 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 18 Mode of communication between O-DU High entities - Figure 7: Mode of communication between O-DU High entities + Figure 18: 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 19 Communication between entities - Figure 8: Steps of Communication between O-DU High entities + Figure 19: 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 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -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