:::success
**Project Topic: OSC DU High + OAI L1 by FAPI**
:::

# E-mail Question list

:::info
Dear Irfan,

The problem for OAI CU and OSC DU High integration is due to the lack of UE to finish the Security Command.

Hence, we may try to adopt your split 7.2 version and replace OSC O-DU Low (PHY) by OAI L1. That is, we want to have
UE <--> LiteON RU <--> OSC fronthaul <--> OAI L1 <--> OSC O-DU High <--> OAI CU

My student is working with LiteON to duplicate the OAI split 7.2 version. Please give us the contact window for this part. If possible, you can show us how to add the nFAP module to OSC O-DU High to connect OSC L1.

Dear Bimo,
Please add Ming and Richard to the loop.
:::

:::success
Dear Ray, Bimo,

Thanks for the short precise message. This is very clear.

**1st topic**: You are proposing is to abandon the OSC low O-DU and replace that with OAI low O-DU. The FAPI interface is significant work, and I cannot understand the purpose of this integration. If you are abandoning the OSC low-CU, why not use the entire OAI O-DU (low and high)? What is the value of the high OSC O-DU? Bimo @fransiscus bimo, could you please explain why we cannot use the entire OSC O-DU (low and high)?

**Second topic**: The 7.2 split with fronthaul library integrated in OAI low O-DU is available in the OAI codebase. Integration with Lite-On has already been done and is deployed in our lab – some debugging and testing is ongoing . Raphael in charge of that from the OAI team and will help with your team. I have invited all of you to Slack. I suggest we add your colleagues to the relevant Slack channel for participating in the discussions. Please give us the names of who we should add (Bimo + who else?)

P.S. I am only adding the relevant people to this discussion, i.e., Raymond, Raphael, and Robert from our team. I am not copying Navid since his team is currently not involved in this work, and there is no point to add to clutter for Navid – he is very busy.  We shall also add other participants from our team as need arises.

Regards,
:::

:::info
Hi Irfan,

To answer your question in case of using the entire OSC O-DU (low and high). In summary the OSC O-DU is split into two parts, and the development is led by different companies. Our role in the OSC community lab involves assisting in the integration of OSC O-DU. In integration we need to test the message procedures, but it requires the existence of a testing unit in our env. One of the issues we now have is due to availability and operation of the testing unit which makes the integration time longer than expected.

Best Regards,

Bimo
:::

:::info
Dear Irfan,

1. **1st topic**: **The integration of OSC O-DU Hign and Low is still ongoing.**
It's an alternative option to test the rest of the procedures between OAI CU and OSC O-DU High by integrating OSC O-DU Low and OAI O-DU Low (split 7.2 version).

2\. 2nd topic: The installation guide provided by OAI still have some problems. Here is the errors found by Ming. Please share us your solutions. Thank you.

[https://hackmd.io/7kBOXVsLTAm2DMikAtZ3PQ?view#install-lack-lib-from-build-rpm%E2%80%A6](https://hackmd.io/7kBOXVsLTAm2DMikAtZ3PQ?view#install-lack-lib-from-build-rpm%E2%80%A6)

Dear Ming,
Please reach Raphael if you have any questions.
:::
:::success
Thanks for the short precise message. This is very clear.

**1st topic**: You are proposing is to abandon the OSC low O-DU and replace that with OAI low O-DU. The FAPI interface is significant work, and I cannot understand the purpose of this integration. If you are abandoning the OSC low-CU, why not use the entire OAI O-DU (low and high)? What is the value of the high OSC O-DU? Bimo [@fransiscus bimo](mailto:[e-mail]), could you please explain why we cannot use the entire OSC O-DU (low and high)?

**Second topic**: The 7.2 split with fronthaul library integrated in OAI low O-DU is available in the OAI codebase. Integration with Lite-On has already been done and is deployed in our lab – some debugging and testing is ongoing . Raphael in charge of that from the OAI team and will help with your team. I have invited all of you to Slack. I suggest we add your colleagues to the relevant Slack channel for participating in the discussions. Please give us the names of who we should add (Bimo + who else?)

P.S. I am only adding the relevant people to this discussion, i.e., Raymond, Raphael, and Robert from our team. I am not copying Navid since his team is currently not involved in this work, and there is no point to add to clutter for Navid – he is very busy.  We shall also add other participants from our team as need arises.

Regards,
:::
:::success
Hello Ray,

nice to hear from you again :)

Hello Ming, can you please point me which branch / commit on OAI you are using? I will try to reproduce your error.

I got that you are working on a CentOS-8 server. Am I right?

Regards
:::

:::success
The installation guide has already been updated. Can you try again with a more
recent DPDK version as described here?
[https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge\_requests/2284#note\_93922](https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2284#note_93922)

And also the latest version of that branch. FYI there will be more changes in
the near future from the branch use\_msgq\_new\_fhidriver\_build_fix, you might
want to try that as well (but it could be that documentation etc is missing)

Robert
:::

:::info
Dear Raphael and Robert,

Thanks for your reply. We will try to fix it.

By the way, I found that you sill used the fronthaul library from Rel B that my student installed for EURECOM two years ago. Do you plan to upgrade it to a newer version?

Dear Raphael,

We use RHEL 8.7 as suggested on the page

[https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use\_msgq/doc/ORAN\_FHI7.2_Tutorial.md#1-prerequisites](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use_msgq/doc/ORAN_FHI7.2_Tutorial.md#1-prerequisites)

:::

:::success
As Robert mentioned, Raymond and us are working now on this new branch use\_msgq\_new\_fhidriver\_build_fix that should support releases F and G.
:::

:::info
\+ Add engineers from LiteON.

Dear Raphael and Robert,

We should start with this version, right?

[https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge\_requests/2284#note\_93922](https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2284#note_93922)

Dear Ming and Richard,
1\. Please remember to add the branch / commit on OAI you use at the beginning of your installation guide.
2\. Please follow the new installation guide and try it again. 
3\. You should copy your error log in the email in case of any questions.
4\. Please check it with Ian and Bimo and follow the template to prepare your installation guide.

Ray
:::

:::success
The starting point for O-RAN 7.2 should be this:
[https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/1907/](https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/1907/)
:::
:::info
Dear Robert,

It seems that you did not have formal installation guide for this page yet.

What's the difference between your new version and the. old version you gave us before?

[https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use\_msgq/doc/ORAN\_FHI7.2_Tutorial.md#1-prerequisites](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use_msgq/doc/ORAN_FHI7.2_Tutorial.md#1-prerequisites)

Ray
:::

:::success
That is work in progress, and not stable yet. It is subject to change in the
future, sorry about that.

\> What's the difference between your new version and the. old version you
\> gave us before?
> [https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use\_msgq/doc/ORAN\_FHI7.2_Tutorial.md#1-prerequisites](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use_msgq/doc/ORAN_FHI7.2_Tutorial.md#1-prerequisites)

I updated and tested with a recent version of DPDK. Also, I fixed some bugs
IIRC.
:::

Here is a summary of the key points from the email thread:

- Ray's team is working on integrating OAI CU with OSC O-DU High, but facing issues due to lack of UE.
- As an alternative, they propose using OAI low O-DU (split 7.2 version) instead of OSC O-DU Low to test integration between OAI CU and OSC O-DU High.
- Ray's student Ming is trying to set up the OAI 7.2 split version but facing some build issues.
- Irfan suggests Ming reach out to Raphael from OAI for help with setup. Also invites Ray's team to join relevant Slack channel.
- Robert and Raphael explain they are working on updating the 7.2 split version and branch "use\_msgq\_new\_fhidriver\_build_fix". Guide is still work in progress.
- Suggested starting point is MR 1907 for O-RAN 7.2 integration.
- Ray requests Ming and Richard to follow template, include commit details, update installation guide with errors.
- Ray also asks if OAI plans to upgrade the fronthaul library they provided earlier from Release B.
- LiteON engineers added to thread for collaboration on 7.2 split version.

Please let me know if I have missed any important details or if you need any clarification on the summary.

# OAI list of questions

:::info
各位好
關於OAI FAPI目前進度回報：
有找到一個P5 傳資料的func，不確定是否用於MONOLITHIC
找不到For MONOLITHIC 的 P5 init(初始分配記憶體)
只有看到 For VNF、PNF的，因此我整理了幾個問題想要詢問：

---
1. 在source code 哪邊可以找到nFAPI(MONOLITHIC mode) P5 Initial (我目前尚未找到，僅有找到VNF、PNF-P5 initial 的function code)
2. 在source code 哪邊可以找到nFAPI(MONOLITHIC mode)初始化shared memory(記憶體分配) (目前沒有看到使用 C原生的shared memory library)
想詢問 @或 您之前提到的OAI 使用shared memory是在source code哪邊實現的
3. 關於以上兩點，我有一點想確認，是位於`\openairinterface5g-use_msgq\nfapi\open-nFAPI\pnf\src\pnf.c` > `pnf_send_message()`的function，裡面可以看到分別使用兩個function：sctp_sendmsg()、write()
想請問這邊call write() 是不是就是用來shared memory的呢？

This file source code link:
https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/use_msgq/nfapi/open-nFAPI/pnf/src/pnf.c#:~:text=int%20pnf_send_message(,1972)


以及我找到的這份有關OAI FAPI Interface的PPT，圖片中最後一段提到，P5 在 registration期間是使用function pointers，怎麼似乎跟shared memory大不相同？請問有人對於這方面有更多的膫解嗎
:::

:::info
I have a few questions to address:

1. The first question I want to clarify is, within OAI's choice of this mode (MONOLITHIC), where is the P5 INIT function designed located in the source code? Or is it actually shared with the code related to PNF?

2. I'd like to ask where the initialization of shared memory used in nFAPI mode (MONOLITHIC) is located in the source code.

3. When it comes to shared memory usage in nFAPI mode (MONOLITHIC) for P5 parameters and configuration, is the file path `\openairinterface5g-use_msgq\nfapi\open-nFAPI\pnf\src\pnf.c` \> `pnf_send_message()` used for sending? Additionally, in this function, does nFAPI utilize SCTP (`sctp_sendmsg()`) while FAPI employs shared memory (`write()`)?

:::

## 1. nFAPI mode _MONOLITHIC with PNF、VNF
:::danger
The first question I want to clarify is, within OAI's choice of this mode (MONOLITHIC), where is the P5 INIT function they designed located in the source code? Or is it actually shared with the code related to PNF?
:::

## 2. write() function
:::info
**Target:**
- Use nFAPI_mode: NFAPI_MONOLITHIC
:::
**File path:** `\openairinterface5g-use_msgq\nfapi\open-nFAPI\pnf\src\pnf.c` > pnf_send_message()

:::danger
I want to validate my idea. The function in the above file path uses two functions: nFAPI uses SCTP: sctp_sendmsg() FAPI uses shared memory: write() Is this correct?
:::

## 3. Shared Memory INIT
:::danger
If I choose to use the mode nFAPI\_mode: NFAPI\_MONOLITHIC, I have learned from online documentation that it seems to be implemented using Shared Memory. However, I am curious about where in the source code the memory is allocated and initialized.
:::

## Response
:::success
**NCU student’s reply**
- 根據第三點 - write是用來寫進memory沒錯
1. MONOLITHIC mode不是指VNF與PNF皆在同一台伺服器上嗎?所以它也是用VNF、PNF-P5 initial 的code
2. 可能幫不太上忙，因為我們沒有用過shared memory，只知道有這件事，要找的話需要花點時間
:::

:::success
**Robert’s reply**

:::

# Professor Ray's List of Questions

## 1. Difference between FAPI and nFAPI
:::success
- According to [This Reference](https://www.fiercewireless.com/wireless/small-cell-forum-promotes-new-standards-to-foster-open-ran-avoid-fragmentation#:~:text=So%2C%20FAPI%20is%20an%20%E2%80%9Cinternal,Split%20RAN%2FSC%20network%20solution.), It may be true that
- FAPI is considered an **internal** interface
- whereas nFAPI is considered as **Network** interface.

:::
The 5G network functional application platform interface (5G nFAPI) is an initiative that extends for 5G the functional split between the MAC and PHY functions that enables virtualization of the MAC function. On the other hand, FAPI is an ‘internal’ interface. 5G-nFAPI (network FAPI) is a ‘network’ interface and is between a Distributed Unit and Centralised Unit of a Split RAN/Small Cell network solution. [An open specification of this interface (nFAPI) will help network architects by allowing them to mix distributed and central units from different vendors](https://www.telecomsinfrastructure.com/2019/07/small-cell-forum-releases-5g-fapi-api.html)[1](https://www.telecomsinfrastructure.com/2019/07/small-cell-forum-releases-5g-fapi-api.html).

## 2. Use of FAPI or nFAPI in OSC and OAI respectively
:::success
- In **OAI**, you can ++**optionally**++ choose to use `FAPI` or `nFAPI`.

- In **OSC**, however, you can only use `FAPI`.
:::

## 3. Current compilation process for OSC and interfacing High, Low layers
- Use Intel C/C++ Compiler (ICX)
- [Use TM with Intel](https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/fapi_5g_tm_overview.html)
- WLS is a library uses DPDK, libhugetlbfs and pthreads to provide memcpy less data exchange between an L2 application, API Translator Module and a L1 application by sharing the same memory zone from the DPDK perspective.

## 4. Current compilation process for OAI and interfacing L2, L1 layers
- Use gcc、makefile
- can ++**optionally**++ choose to use `FAPI` or `nFAPI`.
:::success
**Outcome**
- [Trace OAI L1 CMakeLists file](https://hackmd.io/@MingHung/OAI_TraceCodeBook/%2F%40MingHung%2FOAI_L1_CMakeLists)
:::

## 5. How to invoke DPDK
- DPDK 是用於 eCPRI 介面上 處理大量資料流
- Option 7.2 O-RAN FH 的介面是 eCPRI （PHY-H 接 PHY-L) 才會需要 DPDK 加速
:::warning
- 若不想處理大量 FH 資料流，採 Option 6，使用完整的 OAI PHY(包含 High+Low)，就不會用到 DPDK 。
- 使用 nFAPI ，上面跑的不是取樣的soft data 資料流，是處理過後的 hard data 資料流，所以透過 socket 收送的資料量並不多。為了加速，我們把 ODU-High 與 ODU-Low 放在同一台電腦上，使用 local loop IP 降低進出網卡的延遲。這是我們這邊的做法。
:::

## 6. How to invoke DPDK in OSC
- Inter Process Communication (IPC) in OSC is used
DPDK使用（Huge Page）技術來管理共享物理記憶體，DPDK會從系統中申請一段連續的物理記憶體，並將其映射到虛擬地址空間中，來實現OSC的high and low shared memory。

> 補充說明第三點

## 7. Entry point of PHY program and how it is called by MAC
:::success
**Outcome**
- [Trcae Code with OAI L1](https://hackmd.io/@MingHung/OAI_TraceCodeBook/https%3A%2F%2Fhackmd.io%2F%40MingHung%2FTrcaeCode_OAIL1)
:::

---

# My List of Questions
## 1. FAPI and nFAPI
:::info
**Understanding to be verified:**
- [ ] In OAI, they (FAPI and nFAPI) coexist and can be selectively executed (default: FAPI).
- [ ] The main difference: FAPI needs to run on the same host, while nFAPI can run on different hosts via Socket.
:::

:::danger
**Questions to be clarified:**
- [ ] What is the delivery method of OAI FAPI? Is OSC through WLS (shared memory)?
- [ ] Where can I find the OAI L1 FAPI Interface file and function?
- [ ] Where can I find the OSC DU High FAPI Interface file and function?
:::

---

# Some conclusions

:::success
**Robert's reply**

I think the first starting point could be
openair2/NR_PHY_INTERFACE/NR_IF_Module.c. This file has callbacks that are
called by the L1 in order to trigger L2/L3, i.e. the scheduler in particular.

Also, there is the functions nr_scheduler_response() which copies data into L1
structures. You could also have a look at that, and find out how the data is
passed down.

Note that in particular NR_IF_Module.c is not very clean; it has many "queues"
which are for the L2 simulator. I think you can ignore it for the time being.

Robert
:::

:::success
**Akmal's reply**
> [name=akmalns]
> [time=Wed, Jul 5, 2023 1:49 PM]
* According to [This Reference](https://www.fiercewireless.com/wireless/small-cell-forum-promotes-new-standards-to-foster-open-ran-avoid-fragmentation#:~:text=So%2C%20FAPI%20is%20an%20%E2%80%9Cinternal,Split%20RAN%2FSC%20network%20solution.), It may be true that FAPI is considered an **internal** interface whereas nFAPI is considered as **Network** interface.

:::

:::success
**Prof.Ray's reply:**
- You need to know how OAI L2 connects OAI L1 using FAPI. Then replace OAI L2 by OSC O-DU High
- Starting with OAI but NOT OSC.
- Your architecture should be the SAME as OAI.
- 看一下Nick, Tony等人的筆記，包括Akmal, 他們對MAC都已有一定的理解，剩下的就是透過FAPI介面定期收送出資料給PHY而已
- 所以只要把O-DU的FAPI與OAI L1對起來即可，剩下就是記憶體的存取問題
:::

---

# Other

:::info
On 7/7/23 04:41, 柏田大貴 wrote:
> Dear All,
>
> I am looking for a way to compile and run only each layer (MAC,RLC,...)
> of OAI individually.
> Is there a program included in the git source that will only run each layer?
>
> Appreciate any helps.
> Warm regards,
> Daiki Kashiwada
:::

:::success
\-\-\-\-\-\-\-\-\-\- Forwarded message ---------
From: **Cedric Roux** <[[e-mail]](mailto:[e-mail])>
Date: Fri, 7 Jul 2023 at 16:49
Subject: Re: About the test environment for each layer
To: 柏田大貴 <[[e-mail]](mailto:[e-mail])>, <[[e-mail]](mailto:[e-mail])>

Hi,

no we don't have separate programs for this.

There is an L2 simulator that will bypass the PHY.
There are some tests for RLC, but it's not what you're
after I think.

:::

:::info
**On 23-07-04, John Achkar wrote:**
is it possible to add PDSCH data with the --phy-test, because I see that not
all the bandwidth is used on the spectrum.
:::
:::success
**Robert's reply**
the scheduler fills everything after the padding with random data in the case of phytest or do-ra modes. See the block starting at gNB_scheduler_dlsch.c:1271.

Before that, it should fill with data coming through RLC. So in theory you should either be able to pipe in something yourself (maybe from /dev/urandom?).

You need to make sure that the phy-test scheduler uses all RBs, from ./nr-softmodem -h:

-M: Set the number of PRBs used for DLSCH in PHYTEST mode
-T: Set the number of PRBs used for ULSCH in PHYTEST mode
:::