cd l2/build/odu
b. Building ODU binary
make odu MACHINE=BIT64 MODE=FDD
-
- Build with O1 module enabled:
- make odu MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
-
c. Cleaning ODU binary
make clean_odu MACHINE=BIT64 MODE=FDD
4. Cleaning ODU, CU Stub and RIC Stub:
make clean_all
-5. Building O1 binary:
+5. Building ODU binary with O1 interface enabled:
a. Build folder
+ cd l2/build/odu
+ b. Building ODU with O1 module enabled:
+ make odu MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
+ c. Cleaning ODU binary
+ make clean_odu MACHINE=BIT64 MODE=FDD
+
+ d. Build folder
cd l2/build/o1
- b. Building O1 binary
+ e. Building O1 binary
make o1 MACHINE=BIT64
- c. Cleaning O1 binary
+ f. Cleaning O1 binary
make clean_o1
b. ifconfig <interface name>:CU_STUB "192.168.130.82"
c. ifconfig <interface name>:RIC_STUB "192.168.130.80"
-2. Execute CU Stub:
+2. Execute O1 (only if O-DU is built with O1 interface enabled):
+ a. O1 execution folder:
+ cd l2/build/o1/bin/o1
+ b. Run O1 binary:
+ ./o1
+
+3. Execute CU Stub:
a. CU execution folder:
cd l2/bin/cu_stub
b. Run CU Stub binary:
./cu_stub
-3. Execute RIC Stub:
+4. Execute RIC Stub:
a. RIC execution folder:
cd l2/bin/ric_stub
b. Run RIC Stub binary:
./ric_stub
-4. Execute DU:
+5. Execute DU:
a. DU execution folder:
cd l2/bin/odu
b. Run ODU binary:
./odu
-5. Execute O1
- a. O1 execution folder:
- cd l2/build/o1/bin/o1
- b. Run O1 binary:
- ./o1
-
PS: CU stub and RIC stub must be run (in no particular sequence) before ODU
If O1 module is enabled it must be run before ODU
c. Run ODU binary
./odu
+
+G. How to execute the Health Check : get alarm-list
+----------------------------------------------------
+
+ Steps:
+
+ 1. Start Netconf netopeer client
+
+ 2. Connect to the server with
+
+ user: netconf
+ pwd: netconf
+
+ 3. Send a Netconf get request for alarms xpath
+
+ Here are the steps as executed in the terminal
+
+ netopeer2-cli
+ > connect --login netconf
+ Interactive SSH Authentication
+ Type your password:
+ Password:
+ > get --filter-xpath /o-ran-sc-odu-alarm-v1:odu/alarms
+ DATA
+ <odu xmlns="urn:o-ran:odu:alarm:1.0">
+ <alarms>
+ <alarm>
+ <alarm-id>1009</alarm-id>
+ <alarm-text>cell id [1] is up</alarm-text>
+ <severity>2</severity>
+ <status>Active</status>
+ <additional-info>cell UP</additional-info>
+ </alarm>
+ </alarms>
+ </odu>
+
+ The XML output is a list of active alarms in the O-DU High system.
+
c. DL RRC Message Response - Informs DU APP if a DL RRC Message was successfuly processed at RLC and sent to MAC.
+3. DU APP - O1 Interface
+
+ a. DU sends alarms to O1 for cell up and cell down events using the alarm interface API
+
.. figure:: LicHeader.jpg
:width: 600
- :alt: Figure 6 License Header and Footer
+ :alt: Figure 8 License Header and Footer
- Figure 6 : License Header and Footer
+ Figure 8 : License Header and Footer
O-DU High code
---------------
.. figure:: ModeofCommunication.jpg
:width: 600
- :alt: Figure 7 Mode of communication between O-DU High entities
+ :alt: Figure 9 Mode of communication between O-DU High entities
- Figure 7: Mode of communication between O-DU High entities
+ Figure 9: Mode of communication between O-DU High entities
Steps of Communication
++++++++++++++++++++++
.. figure:: StepsOfCommunication.jpg
:width: 600
- :alt: Figure 8 Communication between entities
+ :alt: Figure 10 Communication between entities
- Figure 8: Steps of Communication between O-DU High entities
+ Figure 10: Steps of Communication between O-DU High entities
Communication with Intel O-DU Low
- cnt - number of bytes to be copied
- ccnt - number of bytes copied
+O1 Module
+----------
+
+Coding Style
+^^^^^^^^^^^^
+
+O1 uses GNU C++ language.
+
+ODU - O1 Communication
+^^^^^^^^^^^^^^^^^^^^^^
+
+O-DU High and O1 module communicate on a TCP 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
| **Date** | **Ver.** | **Author** | **Comment** |
| | | | |
+--------------------+--------------------+--------------------+--------------------+
+| 2020-12-04 | 1.0.1 | HCL Technologies | Cherry Release |
+| | | Ltd. | |
++--------------------+--------------------+--------------------+--------------------+
| 2020-12-04 | 1.0 | Radisys | Cherry Release |
| | | | |
+--------------------+--------------------+--------------------+--------------------+
- Ubuntu : sudo apt-get install -y libpcap-dev
- CentOS : sudo yum install -y libpcap-devel
+Following libraries are required to compile and execute O1 module:
+
+- Netconf:
+ libssh, libyang, libnetconf2, sysrepo, netopeer2
+
+ Script is provided in the following folder to install these libraries
+
+ - Ubuntu :
+
+ | cd <O-DU High Directory>/l2/build/o1
+ | sudo ./install_lib.sh
+
+
Cloning code
--------------
- Clean O-DU High binary
make clean_odu MACHINE=BIT64 MODE=FDD
+
- Build O-DU High binary
make odu MACHINE=BIT64 MODE=FDD
+
+ To build with O1 interface enabled:
+
+ make odu MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
- Build CU Stub :
make ric_stub NODE=TEST_STUB MACHINE=BIT64 MODE=FDD
+- Build O-DU High with O1 interface enabled:
+
+ - Navigate to o1 Build folder
+
+ cd <O-DU High Directory>/l2/build/o1
+
+ - Clean O1 binary
+
+ make clean_o1 MACHINE=BIT64
+
+ - Build O1 binary
+
+ make o1 MACHINE=BIT64
+
+ - Navigate to odu Build folder
+
+ cd <O-DU High Directory>/l2/build/odu
+
+ - Clean O-DU High binary
+
+ make clean_odu MACHINE=BIT64 MODE=FDD
+
+ - Build O-DU High binary
+
+ make odu MACHINE=BIT64 MODE=FDD O1_ENABLE=YES
+
+
The above generated images can be found at:
- CU Stub - <O-DU High Directory>/l2/bin/cu_stub
- RIC Stub - <O-DU High Directory>/l2/bin/ric_stub
+
+- O1 - <O-DU High Directory>/l2/build/o1/bin/o1
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
======================
:width: 600
:alt: O-DU High Interfaces
- Figure 2 - O-DU High Interfaces
+ Figure 3 - O-DU High Interfaces
-As shown in Figure 2, O-DU High interfaces with the following modules:
+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
:width: 720
:alt: Cell Up and Broadcast Procedure
- Figure 3 - O-DU High Cell Up and Broadcast Procedure
+ Figure 4 - O-DU High Cell Up and Broadcast Procedure
-As seen in the Figure 3,
+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.
- RRC Reconfiguration Complete
-Figure 4 below depicts the above call flow, inclusive of all interfaces:
+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 4 - 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
=========================
| **Date** | **Ver.** | **Author** | **Comment** |
| | | | |
+--------------------+--------------------+--------------------+--------------------+
-| 2020-12-04 | 3.0.0 | Radisys | Cherry Release |
-| | | | |
+| 2020-12-04 | 3.0.0 | Radisys, HCL | Cherry Release |
+| | | Technologies Ltd. | |
+--------------------+--------------------+--------------------+--------------------+
| 2020-06-17 | 2.0.0 | Radisys | Bronze Release |
| | | | |
- O-DU High has not been integrated with O-DU Low and O-CU.
+- O-DU High O1 module has not been integrated with SMO/OAM so a Netconf CLI client is used to demo the get alarm-list flow
+
Known Issues
^^^^^^^^^^^^^
None
b. ifconfig <interface name>:CU_STUB "192.168.130.82"
c. ifconfig <interface name>:RIC_STUB "192.168.130.80"
-2. Execute CU Stub:
+2. Execute O1 (only if O-DU is built with O1 interface enabled):
+
+ a. Navigate to O1 build folder
+
+ - cd <O-DU High Directory>/l2/build/o1
+
+ b. Create a new netconf user and install the YANG module
+
+ Switch to root user and run following commands
+
+ | adduser --system netconf && \\
+ | echo "netconf:netconf" | chpasswd
+
+ | mkdir -p /home/netconf/.ssh && \\
+ | ssh-keygen -A && \\
+ | ssh-keygen -t dsa -P '' -f /home/netconf/.ssh/id_dsa && \\
+ | cat /home/netconf/.ssh/id_dsa.pub > /home/netconf/.ssh/authorized_keys
+
+ sysrepoctl -i ./yang/o-ran-sc-odu-alarm-v1.yang
+
+ c. Navigate to O1 execution folder
+
+ - cd <O-DU High Directory>/l2/build/o1/bin/o1
+
+ d. Run O1 binary
+
+ - ./o1
+
+3. Execute CU Stub:
a. Navigate to CU execution folder
- ./cu_stub
-3. Execute RIC Stub:
+4. Execute RIC Stub:
a. Navigate to RIC execution folder
- ./ric_stub
-4. Execute O-DU High:
+5. Execute O-DU High:
a. Navigate to ODU execution folder
- ./odu
-PS: CU stub and RIC stub must be run (in no particular sequence) before ODU
+PS: CU stub and RIC stub must be run (in no particular sequence) before ODU. If O-DU High is built with O1 interface enabled, the O1 binary must be run before all other binaries.
II. Execution - Using Docker Images
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. figure:: O-DU_High_Low_Flow.jpg
:width: 600
- :alt: Figure 1 O-DU High - O-DU Low Message Flow Diagram
+ :alt: Figure 7 O-DU High - O-DU Low Message Flow Diagram
- Figure 5 - O-DU High - O-DU Low Message Flow Diagram
+ Figure 7 - O-DU High - O-DU Low Message Flow Diagram
Note: UL IQ-Sample request and response are needed by Intel O-DU Low in timer mode(testing mode) only. Code changes for
these are guarded under INTEL_TIMER_MODE flag which can be enabled using compilation option "PHY_MODE=TIMER", as
mentioned in section B.I.1.d .
+
+
+D. Health Check execution: get alarm-list
+-------------------------------------------
+
+To execute the get alarm-list flow, following steps are required to be executed:
+
+ 1. Start Netconf netopeer client
+
+ 2. Connect to the server with
+
+ | user: netconf
+ | pwd: netconf
+
+ 3. Send a Netconf get request for alarms xpath
+
+Here are the steps as executed in the terminal
+
+ | netopeer2-cli
+ | > connect --login netconf
+ | Interactive SSH Authentication
+ | Type your password:
+ | Password:
+ | > get --filter-xpath /o-ran-sc-odu-alarm-v1\:odu/alarms
+ | DATA
+ | <odu xmlns=\"urn\:o-ran\:odu\:alarm\:1.0\">
+ | <alarms>
+ | <alarm>
+ | <alarm-id>1009</alarm-id>
+ | <alarm-text>cell id [1] is up</alarm-text>
+ | <severity>2</severity>
+ | <status>Active</status>
+ | <additional-info>cell UP</additional-info>
+ | </alarm>
+ | </alarms>
+ | </odu>
+
+The XML output is a list of active alarms in the O-DU High system.
+
+Note: Integration with SMO/OAM is not yet done so a Netconf CLI client(netopeer2-cli) is used to connect to the Netconf server and send the get request.
Code Review / o-du / l2.git / commitdiff
