srsRAN RU emulator #517
Replies: 9 comments 17 replies
-
|
Thanks for the detailed tutorial. Is the utilization of DPDK a prerequisite for operating an RU emulator? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, for running the RU emulator app the DPDK is mandatory |
Beta Was this translation helpful? Give feedback.
-
|
After the release of srsRAN-24.04, I have noticed an update that introduces UNIX sockets in this commit. Just an information update in case anyone needs it. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, For the gNB I get the following log: and for the ru_emulator: Could you please provide reference configuration for the gNB and the ru_emulator. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @mmailand , Thanks for your interest!
This warning is expected since the RU emulator doesn't send U-Plane packets with PRACH. It can be safely ignored when running the gNB in test mode. Another option is disabling PRACH C-Plane in the Can you see a counter of received UL C-Plane in the RU console output? If not, then either the packets do not arrive or they are being discarded. Capturing the traffic on the NIC and checking a pcap may help here. Here is an excerpt from the configuration files used in the example command above that was working with the example RU emulator config: |
Beta Was this translation helpful? Give feedback.
-
|
Hello @sauka, I got it working, but I think there is a bug in the vlan handling of the ru_emulator. Thanks for your time. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reporting this @mmailand, we will provide a fix in the next release. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sauka, in our environment, the RU_emulator works with no throughput. According to the log, the packets are dropped by DPDK. More details are here. Thanks you very much if you could provide some guidance. |
Beta Was this translation helpful? Give feedback.
-
|
problem solved, thanks |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sauka. Taking advantage of the post, I would like to know if there is a tutorial for running and configuring |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mateusomattos , Using the The goal is to find such t1a* values that make transmission window as wide as possible to minimize the probability of late packets. The t1a_max value is easier to find, as it defines when the transmission window opens and when most OFH traffic will actually be sent. If it is misconfigured, i.e. the value is too high, your RU will complain instantly about 'early' packets. The t1a_min is harder to find: it defines when the transmission window closes, and since the probability of sending traffic right at the end is much lower, your RU may not give you any feedback while you change this parameter. The approach can be to first make the tx window as narrow as possible and move it as late as possible (so set low values for t1a* and make the difference between min and max as small as possible, i..e. one OFDM symbol duration): Start moving this initial tx window (i.e. increase both min and max |
Beta Was this translation helpful? Give feedback.
-
|
Hello @mmailand , I'm having some trouble with the configuration of my srsRAN setup. Could someone please assist me by providing the configuration files for 'cell_cfg.yml', 'ru_emulator.yml', and 'ru_em.yml'? I believe there might be an issue with my current configuration. Thank you in advance for your help! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @aliasadi2001 Did you try with one of the examples shared above? Can you share your configs and what issues do you have with them? I can take a look and give an advise what to change to make it working |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sauka , noticed some new parameters of test mode in the official Configuration Reference: test_mode:
enable: false # Optional BOOLEAN (false). Set to true to enable CU-UP test mode. Supported: [true, false].
integrity_enable: false # Optional BOOLEAN (false). Set to true to enable PDCP integrity testing. Supported: [true, false].
ciphering_enable: false # Optional BOOLEAN (false). Set to true to enable PDCP ciphering testing. Supported: [true, false].
nea_algo: 2 # Optional UINT (2). Sets the NEA algo to use for testing. Supported: [0, 1, 2, 3].
nia_algo: 2 # Optional UINT (2). Sets the NIA algo to use for testing. Supported: [1, 2, 3].It seems that CU-UP is supported in test mode. If I'm correct, the original version of test mode included only the MAC and PHY layers. Is there a tutorial on deploying the new version of test mode? Thank you in advance. |
Beta Was this translation helpful? Give feedback.
-
|
There seems to be some confusion here. The CU-UP test mode is more intended to be used with the CU app. It allows users to investigate performance bottlenecks in the PDCP security and networking, but it cannot integrate with the test mode of the lower layers. I will cleanup the arguments so that is more clear. Sorry for the confusion. |
Beta Was this translation helpful? Give feedback.
-
|
@alvasMan It helps a lot. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sauka , Unfortunately, I don’t have a working VM at the moment. I’ll reimplement everything from scratch and share my configuration with you to get guidance on resolving the issue. Thanks for your support! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sauka , Noticing in the srsRAN documents, it says DPDK is not a requirement for the RU emulator while here in the comment section you described it as a prerequisite. Could you do some clarification about this? Thank you for your support! |
Beta Was this translation helpful? Give feedback.
-
|
Before version 24.04, DPDK is mandatory. See here |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sauka, sudo ./gnb -c srs-new-40Mhz.yml -c testmode.yml
[sudo] password for :
--== srsRAN gNB (commit 9d5dd742a) ==--
The PRACH detector will not meet the performance requirements with the configuration {Format B4, ZCZ 0, SCS 30kHz, Rx ports 1}.
Initializing the Open Fronthaul Interface for sector#0: ul_compr=[BFP,9], dl_compr=[BFP,9], prach_compr=[BFP,9], prach_cp_enabled=true, downlink_broadcast=true
Cell pci=1, bw=40 MHz, 2T1R, dl_arfcn=628032 (n78), dl_freq=3420.48 MHz, dl_ssb_arfcn=627072, ul_freq=3420.48 MHz
Warning: Configured PRACH occasion collides with PUCCH RBs ([0..1) intersects [0..12)). Some interference between PUCCH and PRACH is expected.
Warning: Configured PRACH occasion collides with PUCCH RBs ([0..1) intersects [0..12)). Some interference between PUCCH and PRACH is expected.
==== gNB started ===
Type <h> to view help
t
|--------------------DL---------------------|-------------------------UL------------------------------
pci rnti | cqi ri mcs brate ok nok (%) dl_bs | pusch rsrp mcs brate ok nok (%) bsr ta phr
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/a
1 44 | 15 1.0 28 105M 1600 0 0% 10M | 99.9 -99.9 28 28M 400 0 0% 81.5M 0 n/aand for the RU emulator: sudo ./ru_emulator -c emu.yml
[sudo] password for :
Running. Waiting for incoming packets...
| TIME | ID | RX_TOTAL | RX_ON_TIME | RX_EARLY | RX_LATE | RX_SEQ_ERR | RX_ON_TIME_C | RX_EARLY_C | RX_LATE_C | RX_SEQ_ERR_C | RX_ON_TIME_C_U | RX_EARLY_C_U | RX_LATE_C_U | RX_SEQ_ERR_C_U | RX_SEQ_ERR_PRACH | RX_CORRUPT | RX_ERR_DROP | TX_TOTAL |
| 07:34:20 | 0 | 0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 07:34:21 | 0 | 0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 07:34:22 | 0 | 0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 07:34:23 | 0 | 0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 07:34:24 | 0 | 0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
^C| 07:34:25 | 0 | 0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0/0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |I'm not running with DPDK and my configuration files are below. Could you kindly take a look and point out what is the issue here if there were any. |
Beta Was this translation helpful? Give feedback.
-
|
@cohlezzz From what I can tell there are no packets being sent between the RU and the DU. You should see some values under RX_ON_TIME_C. I have included configurations that work for us, however we are still having the same problem when running with DPDK. |
Beta Was this translation helpful? Give feedback.
-
|
@cueltschey I am able to run them using real NICs in one single server but without DPDK. And I have the following output from the RU emulator: sudo ./ru_emulator -c emu.yml
[sudo] password for :
Running. Waiting for incoming packets...
| TIME | ID | RX_TOTAL | RX_ON_TIME | RX_EARLY | RX_LATE | RX_SEQ_ERR | RX_ON_TIME_C | RX_EARLY_C | RX_LATE_C | RX_SEQ_ERR_C | RX_ON_TIME_C_U | RX_EARLY_C_U | RX_LATE_C_U | RX_SEQ_ERR_C_U | RX_SEQ_ERR_PRACH | RX_CORRUPT | RX_ERR_DROP | TX_TOTAL |
| 07:26:41 | 0 | 7142 | 6213 | 274 | 0 | 0 | 379 | 121 | 0 | 0 | 0 | 155 | 0 | 0 | 0 | 0 | 0 | 1722 |
| 07:26:42 | 0 | 22904 | 19832 | 972 | 0 | 0 | 1209 | 391 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:43 | 0 | 22903 | 19873 | 930 | 0 | 0 | 1209 | 391 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:44 | 0 | 22900 | 19868 | 932 | 0 | 0 | 1206 | 394 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:45 | 0 | 22905 | 19864 | 940 | 0 | 0 | 1203 | 398 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:46 | 0 | 22903 | 19863 | 940 | 0 | 0 | 1209 | 391 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:47 | 0 | 22904 | 19869 | 935 | 0 | 0 | 1207 | 393 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:48 | 0 | 22900 | 19952 | 848 | 0 | 0 | 1210 | 390 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
| 07:26:49 | 0 | 22903 | 19981 | 822 | 0 | 0 | 1210 | 390 | 0 | 0 | 0 | 500 | 0 | 0 | 0 | 0 | 0 | 5600 |
...There is an unexpected proportion of early received packets. I have included my configurations and please let me know if you or anyone have a clue of the cause. |
Beta Was this translation helpful? Give feedback.
-
|
We also got it working on our end. We used your configs with some slight modifications. As far as I can understand PTP is required when using a NIC, due to synchronization issues. This explains why there are no late packets when using lo. We will test this further and attempt to fix it. Here is our log |
Beta Was this translation helpful? Give feedback.
-
|
I also got the emulator working with dpdk. Here are my configs if it helps: Here is the output from We used igb_uio rather than vfio-pci since it makes two device files, one for each port. with vfio-pci two processes on the same machine cannot access two ports on one NIC. Additionally, we used an argument --file-prefix in the EAL arguments to specify that two processes will be using DPDK, and tell EAL to create seperate files for them. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing your experience with I've seen you tried first using the same interface for both the Using different ports of the same NIC, like you did in other configs, sounds better. I believe the NIC driver is smart enough to route outgoing traffic to another interface based on the MAC address.
@cueltschey yes, when the In our tests the typical approach is to use a physical function (PF) of the NIC port for PTP traffic and to create a virtual function (VF) on that port for the OFH traffic. This VF can be bound also to DPDK. Using the same NIC port for OFH traffic and PTP packets degrades the synchronization.
Thanks for sharing this info, it is very useful! Regarding the |
Beta Was this translation helpful? Give feedback.
-
Hey,
In the recent release we have added O-RAN radio unit (RU) emulator in srsRAN. It allows to perform end-to-end tests of the srsRAN CU/DU software solution in a 7.2 split scenario using the test mode.
The RU emulator implements some basic RU functionalities and can be run in a separate PC. Its current version performs the following tasks:
Configuration
Dummy U-Plane UL packets can be generated using static IQ data compression parameters. Allowed options include:
The RU emulator accepts a configuration file in the YAML format just like the gNB application. Below you can find an example of such file:
It is important to provide matching network configurations for both the gNB application (please refer to
ru_ofhconfiguration parameters) and the RU emulator.For the details on installing DPDK and binding a NIC port to it please refer to this srsRAN tutorial:
https://docs.srsran.com/projects/project/en/latest/tutorials/source/dpdk/source/index.html
Running end-to-end test
Here are the example commands for running the gNB application in test mode and the RU emulator:
run the gNB:
sudo apps/gnb/gnb -c cell_cfg.yml ru_emulator.yml amf --no_core true test_mode test_ue --rnti 0x1 --ri 4(all
test_modeconfiguration parameters)run the RU emulator:
sudo tests/integrationtests/ofh/ru_emulator -c ru_em.ymlIf everything is configured correctly, you should be able to see an output from the RU emulator similar to the following one:
At the gNB side, press
tto enable the trace and observe reported DL and UL throughput.Beta Was this translation helpful? Give feedback.
All reactions