srsRAN with native Open Front Haul (OFH) support

[andrepuschmann]

Hey,

very recently we've added support for O-RAN radio units (O-RUs) in srsRAN through our new in-house Open FrontHaul (OFH) implementation. This is something we are extremely excited about as it opens up a plethora of new use-cases, brings new players into the mix and thereby addresses a key bottleneck for O-RAN - the current de-facto vendor lock-in caused by a quasi-monopoly for OFH implementations. The srsRAN OFH library is open-source, portable and vastly simplifies the bring-up effort for a full end-to-end O-RAN solution as it has far fewer mandatory dependencies than alternative options.

Why

You might ask yourself why? Why have they reimplemented something that has already been open-sourced under a permissive license and is widely used by numerous other 5G RAN solutions?

The answer to this question is manifold but in brief, we believe the existing implementation didn't fit our needs in terms of simplicity, dependencies, portability and code structure.

Simplicity

Up until now it has been extremely difficult and also expensive to setup a full end-to-end ORAN testbed. Take any of the existing tutorials and check the bill of materials (BOM). It quickly becomes clear that an upfront investment of at least 20-30k Euro in pure hardware is needed to acquire the devices mentioned in those bring-up guides. We believe this shouldn't be the case and it doesn't need to be the case.

Once that investment has been made, there is a high degree of complexity involved in configuring your expensive hardware due to the reliance on mandatory third-party dependencies such as DPDK and painful instructions that require the application of patches to specific library versions to compile with a particular kernel, etc.

Our vision has always been to have an OFH implementation that just works with a vanilla Linux kernel using the standard socket interface. Because after all, OFH is just a protocol that sits on top of Ethernet. Nothing that should be needlessly complicated.

Dependencies

I am sure there are folks that now ask if we're serious about performance without a mandatory dependency on DPDK? Can you even sustain the required rates through the kernel's networking stack?

We understand and believe in the usefulness of DPDK - we just don't think it should be a mandatory dependency for an OFH implementation - or a RAN stack in general. Our entire software architecture has been designed such that it can take advantage of DPDK's kernel offloading techniques by using its buffer and memory management. But the key aspect is that it doesn't depend on it.

This simple design choice has a huge impact on the usability of the resulting solution. If you are targeting highest performance, you can achieve that by taking advantage of DPDK. However, if your use-case is more conservative, you don't need the added complexity for setup and configuration.

In our benchmarks we've found that for many workloads (like a 100 MHz TDD SISO cell) there are no dramatic performance hits using an OFH socket implementation without DPDK. Current machines can easily sustain the required network rates. Even initial tests with 4x4 MIMO using the same 100 MHz TDD configuration showed acceptable performance.

It should be noted that this approach also vastly simplifies debugging as third-party tools such as Wireshark can now simply run on the gNB/DU machine to sniff the front-haul traffic.

Portability

We want our software to run on a Raspberry Pi, a data center server, and anything in-between. We therefore developed an OFH library that is agnostic to the underlying instruction set - it runs efficiently on ARM as well as on x86-64 CPUs from Intel or AMD without making any compromises or preferring one or the other. We also look forward to seeing it further ported to other architectures in the future.

Code structure

Our OFH implementation follows the same design philosophy as the entire srsRAN 5G stack. Well-defined interfaces, clear dependency hierarchies and readable, well-documented code ensures extensibility is built into the software from day one.

Getting started

We've authored an application note that describes the entire setup procedure including the configuration steps for third-party components like the O-RU and the networking switch step by step here.

We are currently exploring ideas to further simplify and cut the BOM required for a basic end-to-end ORAN setup. Let us know if you have suggestions!

[HeroesLament]

Very very cool! Do you guys have a list of gNB's that support OFH currently? Or maybe an SDR application which exposes an OFH interface to the CU/DU?

[andrepuschmann]

Hey @HeroesLament - I am not sure I understood your question. Can you elaborate? Of course our gNB/DU support OFH to talk to RUs.

[HeroesLament]

Let me rephrase, I can see my mis-phrasing. Do you have a list of hardware RU's (Such as the Benetel 550/650) that support OFH which can speak to your CU/DU split gNB?

[ismagom]

Hi @HeroesLament , we are in the process of integrating other RUs, such as Foxconn.

[HeroesLament]

@ismagom I'll be watching with enthusiasm!

[wei-lou]

Do you have an example configuration file for using OFH for FDD O-RU?

[ismagom]

We don't have any example, since we don't have any O-RU that supports FDD, but you don't need anything special. Just set the band to an FDD one and set subcarrier spacing to 15 KHz. That should be enough.

[wei-lou]

great! thanks

[wei-lou]

Trying to test this one out with following configurations:

Quanta Server (Intel Xeon Gold 6148/RAM 128GB/NIC Intel XXV710 25Gb) to host CU/DU/open5GS
CISCO N540 CSR as the switch and timing source
Fujitsu oRAN radio (Deployed at DISH market)

Questions:

1. Where do DU and RU get IP address from? Do I need to install a DHCP server or can I assign static IP to DU and RU?
2. For the VLAN configuration, how do I assign particular VLAN ID to DU and RU NIC interfaces?

[ismagom]

HI @wei-lou ,

1. Yes you can assign static IP
2. On the RU side, you need to check the RU manual. On the DU side, you can use the parameter vlan_tag under ru_ofh.cells section. See example yml config files under config/ folder.

I also recommend following this App note

[wei-lou]

Hi @ismagom,

While I am still struggling to get ptp sync on my o-RU, at least from DU i can see it gets ptp packets. However the values are way larger than 100 from pyc2sys command (according to the application guide). How do I know it is ptp locked on DU side?

$ sudo ptp4l -2 -i ens16 -f ./srsRAN5G/configs/default.cfg -m
ptp4l[599.688]: selected /dev/ptp0 as PTP clock
ptp4l[599.719]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[599.719]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[600.473]: port 1: new foreign master 8c941f.fffe.564500-9
ptp4l[600.721]: port 1: received SYNC without timestamp
ptp4l[600.721]: selected best master clock 8c941f.fffe.564500
ptp4l[600.721]: updating UTC offset to 37
ptp4l[600.721]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[602.085]: port 1: received SYNC without timestamp
ptp4l[602.127]: port 1: minimum delay request interval 2^-4
ptp4l[602.457]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[603.201]: rms 51 max 69 freq -5508 +/- 34 delay 834 +/- 1
ptp4l[604.193]: rms 12 max 25 freq -5494 +/- 14 delay 834 +/- 1
ptp4l[605.185]: rms 8 max 13 freq -5468 +/- 8 delay 833 +/- 1
ptp4l[606.177]: rms 6 max 11 freq -5461 +/- 6 delay 834 +/- 1
ptp4l[607.169]: rms 3 max 6 freq -5464 +/- 5 delay 834 +/- 0
ptp4l[608.161]: rms 3 max 7 freq -5462 +/- 5 delay 835 +/- 0
ptp4l[609.153]: rms 3 max 6 freq -5467 +/- 5 delay 835 +/- 1
ptp4l[610.145]: rms 3 max 6 freq -5467 +/- 5 delay 835 +/- 0

~$ sudo phc2sys -s ens16 -w -m -R 8 -f ./srsRAN5G/configs/default.cfg
phc2sys[640.699]: CLOCK_REALTIME phc offset 70989173475 s0 freq -7960 delay 650
phc2sys[640.825]: CLOCK_REALTIME phc offset 70989176434 s1 freq +15621 delay 636
phc2sys[640.950]: CLOCK_REALTIME phc offset 70998964139 s2 freq +100000000 delay 598
phc2sys[641.075]: CLOCK_REALTIME phc offset 70985054216 s2 freq +100000000 delay 571
phc2sys[641.200]: CLOCK_REALTIME phc offset 70971139503 s2 freq +100000000 delay 579
phc2sys[641.326]: CLOCK_REALTIME phc offset 70957226607 s2 freq +100000000 delay 585
phc2sys[641.451]: CLOCK_REALTIME phc offset 70943315812 s2 freq +100000000 delay 576
phc2sys[641.576]: CLOCK_REALTIME phc offset 70929407816 s2 freq +100000000 delay 584
phc2sys[641.701]: CLOCK_REALTIME phc offset 70915499457 s2 freq +100000000 delay 591
phc2sys[641.826]: CLOCK_REALTIME phc offset 70901586669 s2 freq +100000000 delay 586
phc2sys[641.951]: CLOCK_REALTIME phc offset 70887674099 s2 freq +100000000 delay 577
phc2sys[642.077]: CLOCK_REALTIME phc offset 70873762713 s2 freq +100000000 delay 580
phc2sys[642.202]: CLOCK_REALTIME phc offset 70859848872 s2 freq +100000000 delay 577
phc2sys[642.327]: CLOCK_REALTIME phc offset 70845935439 s2 freq +100000000 delay 575
phc2sys[642.452]: CLOCK_REALTIME phc offset 70832021670 s2 freq +100000000 delay 572
phc2sys[642.577]: CLOCK_REALTIME phc offset 70818109537 s2 freq +100000000 delay 580
phc2sys[642.702]: CLOCK_REALTIME phc offset 70804196280 s2 freq +100000000 delay 578
phc2sys[642.828]: CLOCK_REALTIME phc offset 70790285262 s2 freq +100000000 delay 579
phc2sys[642.953]: CLOCK_REALTIME phc offset 70776371828 s2 freq +100000000 delay 585

From Cisco N540 CSR switch, I do see DU sent Delay-req and received Delay-resp from N540.
RP/0/RP0/CPU0:ios#show ptp packet-counters TwentyFiveGigE 0/0/0/22
Thu Jul 6 20:42:43.209 UTC
Packets Sent Received Dropped

Announce 29777 0 0
Sync 59554 0 0
Follow-Up 0 0 0
Delay-Req 0 7034 0
Delay-Resp 7034 0 0
Pdelay-Req 0 0 0
Pdelay-Resp 0 0 0
Pdelay-Resp-Follow-Up 0 0 0
Signaling 0 0 0
Management 0 0 0
Other 0 0 0
----- ----- -----
TOTAL 96365 7034 0

[ninjab3s]

Hi wei-lou,

regarding phc2sys. For how long do you let it run? From our experience it sometimes takes some minutes to properly sync the local clock. We have also spotted this error message, which we dont see on our end:

ptp4l[602.085]: port 1: received SYNC without timestamp

Does this message appear again if you rerun ptp4l?

[wei-lou]

Hi @ninjab3s

I run the phc2sys for approx 10 minutes still have the large values never go down below 100.

As for the error, re-run ptp4l error didn't show again. However some other errors but it recovered by it self.
$ sudo ptp4l -2 -i ens16 -f ./srsRAN5G/configs/default.cfg -m
[sudo] password for labuser:
ptp4l[58029.022]: selected /dev/ptp0 as PTP clock
ptp4l[58029.071]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[58029.071]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[58029.098]: port 1: new foreign master 8c941f.fffe.564500-9
ptp4l[58029.321]: selected best master clock 8c941f.fffe.564500
ptp4l[58029.321]: updating UTC offset to 37
ptp4l[58029.321]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[58030.044]: port 1: minimum delay request interval 2^-4
ptp4l[58030.214]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[58030.884]: rms 3 max 6 freq -5445 +/- 4 delay 835 +/- 0
ptp4l[58031.776]: rms 4 max 8 freq -5442 +/- 6 delay 836 +/- 1
...
ptp4l[58056.787]: rms 3 max 7 freq -5444 +/- 5 delay 835 +/- 1
ptp4l[58057.680]: rms 2 max 6 freq -5447 +/- 4 delay 835 +/- 0
ptp4l[58058.249]: timed out while polling for tx timestamp
ptp4l[58058.249]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[58058.249]: port 1: send delay request failed
ptp4l[58058.249]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[58074.311]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[58074.419]: port 1: new foreign master 8c941f.fffe.564500-9
ptp4l[58074.642]: selected best master clock 8c941f.fffe.564500
ptp4l[58074.642]: updating UTC offset to 37
ptp4l[58074.642]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[58074.698]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[58074.977]: rms 3 max 5 freq -5444 +/- 4 delay 835 +/- 0
ptp4l[58075.569]: port 1: minimum delay request interval 2^-4
ptp4l[58075.870]: rms 3 max 7 freq -5447 +/- 5 delay 835 +/- 0
ptp4l[58076.763]: rms 3 max 8 freq -5448 +/- 5 delay 836 +/- 0
ptp4l[58077.656]: rms 4 max 8 freq -5450 +/- 7 delay 836 +/- 1

Near the end of 10 minutes, those values as still pretty large.

phc2sys[58681.547]: CLOCK_REALTIME phc offset 70239527877 s2 freq +100000000 delay 582
phc2sys[58681.673]: CLOCK_REALTIME phc offset 70225613589 s2 freq +100000000 delay 578
phc2sys[58681.798]: CLOCK_REALTIME phc offset 70211704309 s2 freq +100000000 delay 585
phc2sys[58681.923]: CLOCK_REALTIME phc offset 70197790719 s2 freq +100000000 delay 585
phc2sys[58682.048]: CLOCK_REALTIME phc offset 70183876978 s2 freq +100000000 delay 582
phc2sys[58682.173]: CLOCK_REALTIME phc offset 70169963105 s2 freq +100000000 delay 582
phc2sys[58682.299]: CLOCK_REALTIME phc offset 70156049636 s2 freq +100000000 delay 578
phc2sys[58682.369]: CLOCK_REALTIME phc offset 70148266781 s2 freq +100000000 delay 585

[undeathkhaoz]

Hello, I'm new to the 5G area. I'm trying to use the Ettus USRP N210 as gNB/RU, but we had the sampling mismatch issue.
With OFH support, can we connect/using Ettus USRP N210 as gNB/RU?

Example:
ru_ofh:
ru_bandwidth_MHz: 50 # RU instantaneous bandwidth.

[wei-lou]

my understanding:

With USRP N210, you are using SDR as RU so it is using split 8 option.
With OFH, you need to have an O-RU radio which supports split 7.2 option.

So to your question, the answer is no.

[undeathkhaoz]

Oh, I get it. Thanks for the explanation about split 7.2.

Do you have any tips for starting the development of a resampling for the USRP N210 on srsRAN? Or maybe a connection between srsRAN and Simulink, before send the samples to USRP N210?
(I'm trying to create at least a resampling from 46.08 MS/s to 50.00 MS/s)

[wei-lou]

no, i don't have any SDR to play with, so I have no experience with USRP N210. Only RUs I have are the split 7.2 commercial o-RUs. I am still trying to figure out how to make those o-RU work with srsRAN via ofh

[wei-lou]

After some time tweaking around finally got timing display correct information. Things I did was change the default.conf's "network_transport" to L2 from UDPv4 and disable the system NTP.

me@vCUDU:~$ sudo ptp4l -f srsRAN5G/configs/default.cfg -2 -i ens16 -m
ptp4l[1575119.209]: selected /dev/ptp0 as PTP clock
ptp4l[1575119.265]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1575119.265]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1575119.338]: port 1: new foreign master 8c941f.fffe.564500-9
ptp4l[1575119.586]: selected best master clock 8c941f.fffe.564500
ptp4l[1575119.586]: updating UTC offset to 37
ptp4l[1575119.586]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1575120.912]: port 1: minimum delay request interval 2^-4
ptp4l[1575121.136]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1575121.880]: rms 45 max 67 freq -5281 +/- 44 delay 834 +/- 1
ptp4l[1575122.872]: rms 16 max 24 freq -5230 +/- 17 delay 834 +/- 0
ptp4l[1575123.864]: rms 15 max 24 freq -5205 +/- 7 delay 836 +/- 1
ptp4l[1575124.856]: rms 6 max 11 freq -5206 +/- 6 delay 835 +/- 1
ptp4l[1575125.848]: rms 4 max 7 freq -5209 +/- 7 delay 834 +/- 1
ptp4l[1575126.840]: rms 4 max 8 freq -5212 +/- 6 delay 835 +/- 0
ptp4l[1575127.832]: rms 3 max 6 freq -5214 +/- 4 delay 836 +/- 0

me@vCUDU:~$ sudo phc2sys -s ens16 -w -m -R 8 -f srsRAN5G/configs/default.cfg
phc2sys[1575122.754]: CLOCK_REALTIME phc offset -144 s0 freq -27350 delay 581
phc2sys[1575122.880]: CLOCK_REALTIME phc offset -144 s2 freq -27350 delay 589
phc2sys[1575123.005]: CLOCK_REALTIME phc offset -146 s2 freq -27496 delay 590
phc2sys[1575123.130]: CLOCK_REALTIME phc offset -127 s2 freq -27521 delay 586
phc2sys[1575123.256]: CLOCK_REALTIME phc offset -103 s2 freq -27535 delay 586
phc2sys[1575123.381]: CLOCK_REALTIME phc offset -79 s2 freq -27542 delay 588
phc2sys[1575123.506]: CLOCK_REALTIME phc offset -51 s2 freq -27538 delay 590
phc2sys[1575123.631]: CLOCK_REALTIME phc offset -28 s2 freq -27530 delay 587
phc2sys[1575123.757]: CLOCK_REALTIME phc offset -5 s2 freq -27515 delay 585
phc2sys[1575123.882]: CLOCK_REALTIME phc offset 17 s2 freq -27495 delay 586
phc2sys[1575124.007]: CLOCK_REALTIME phc offset 34 s2 freq -27473 delay 591
phc2sys[1575124.133]: CLOCK_REALTIME phc offset 48 s2 freq -27448 delay 590
phc2sys[1575124.258]: CLOCK_REALTIME phc offset 63 s2 freq -27419 delay 589

I configured the RU with all needed settings and matched the settings with srsRAN configuration file. However on the RU side I didn't receive any IQ data. From the /tmp/gnb.log, it has some FAPI timing errors.

2023-09-12T15:22:14.165683 [SCHED ] [I] [ 0.0] Cell with cell_index=0 was configured.
2023-09-12T15:22:14.169456 [DU-MNG ] [D] DU manager started successfully
2023-09-12T15:22:14.169459 [GNB ] [I] DU-High started successfully
2023-09-12T15:22:15.169670 [GNB ] [I] Starting Radio Unit...
2023-09-12T15:22:15.169673 [OFH ] [I] Starting the Open Fronthaul interface
2023-09-12T15:22:15.169675 [OFH ] [I] Starting the realtime timing worker
2023-09-12T15:22:15.169708 [OFH ] [I] Starting the ethernet frame receiver
2023-09-12T15:22:15.169722 [GNB ] [I] Radio Unit started successfully
2023-09-12T15:22:15.171680 [FAPI ] [W] [ 0.0] Real-time failure in FAPI: Received late DL_TTI.request. Current slot is 85.3 while message corresponds to 85.1
2023-09-12T15:22:15.171685 [FAPI ] [W] [ 0.0] Real-time failure in FAPI: Received UL_TTI.request message out of time. Current slot is 85.3 while message corresponds to 85.1
2023-09-12T15:22:15.171703 [FAPI ] [W] [ 0.0] Real-time failure in FAPI: Received late DL_TTI.request. Current slot is 85.3 while message corresponds to 85.2
2023-09-12T15:22:15.171705 [FAPI ] [W] [ 0.0] Real-time failure in FAPI: Received UL_TTI.request message out of time. Current slot is 85.3 while message corresponds to 85.2
2023-09-12T15:22:15.200084 [SCHED ] [D] [ 88.2] Slot decisions cell=0 t=3us:

Not sure why RU did not receive any IQ data from DU. (I am able to capture real time IQ data at RU side). Any suggestions how should I troubleshoot the problem? Thanks in advance!

[ismagom]

I see, thanks. We have never tried OFH with FDD, but it could work. This is why we added that validator. If you want to give it a try, can you comment this code:

// Open Fronthaul has not been tested yet in FDD mode.
   if (band_helper::get_duplex_mode(cell_cfg.band.value()) != duplex_mode::TDD) {
     fmt::print("Open Fronthaul implementation only supports TDD mode\n");
     return false;
   }

in the function validate_ru_ofh_appconfig() in gnb_appconfig_validators.cpp?

Thanks

[wei-lou]

great, thanks for the instructions

[doudoulail]

@wei-lou I have the same problem as you. Could you please send me your srsran configuration，tanks

[andrepuschmann]

Hey @doudoulail,
what do you mean by same problem? A FDD configuration? If so, please wait a bit and we update the code. We are currently working with a FDD RU vendor to verify compatibility. As soon as this is done we'll remove the hard-coded barriers. Needless to say that we'll inform everyone here in the forum.

[doudoulail]

@andrepuschmann Thanks, because of software configuration problems, I found that the pcap package of c/u plane sent by srsran was compressed, and I clearly configured it, but the wireshark analysis showed that compression and other operations were not displayed，It is possible that my configuration has gone wrong, causing the wrong message to be sent

[wei-lou]

@wei-lou I have the same problem as you. Could you please send me your srsran configuration，tanks
gnb_ru165_fuji_fdd_n71_10mhz_2x2.txt

So far my FDD RU did receive all the IQ data in time and RU is transmitting. However there are some other issues with it. I will wait for the FDD part of update as Andre has mentioned

[doudoulail]

Okay，thanks

[aruvic]

Hi Andre,

Thanks a lot for this post, great work and all the work that srs open sourced.
Maybe it’s not the right place to ask this off-topic question but it’s related to your statement above ”It quickly becomes clear that an upfront investment of at least 20-30k Euro in pure hardware is needed to acquire the devices mentioned in those bring-up guides.” I’m currently exploring and evaluating the needed hardware and budget to establish a Lab at our organization.
Would you be so kind to elaborate the hardware needed before (20-30K Euro) and hardware needed after native Open Front Haul (OFH) implementation?

I’m trying to find out what would be the bare minimum hardware needed to get the most juice out of for example Bentel RAN550 and RAN650.

In the recent presentation from Paul and Ismael “2023 Fall srsRAN Workshop - Paul Sutton Ismael Gomez (SRS)” I see that you guys use
Dell PowerEdge XR12 with Intel® Xeon® Gold 5317 Processor to achieve constant 1.4Gbps downlink in 24/7 continues testing with 32 UE.
I see also here that wei-lou uses Quanta Server (Intel Xeon Gold 6148/RAM 128GB/NIC Intel XXV710 25Gb) to host CU/DU.

• What would be the needed server CPU, RAM, Network and Disk -wise?

• I assume SSD disks are not so relevant, as most computation happens in CPU and RAM?

• Network card can be any SFP28 25GE?

• Are you using any hardware accelerators in form of Intel FPGA or similar?

• Is Falcon-RX/812/G/A the cheapest option on market to get the most out of 1 (one) O-RU Bentel RAN550 and RAN650 or are there other alternatives with build-in PTP Grandmaster and GNSS-receiver?

• What could such a setup (described above) handle? 64 active and additional 64 connected UEs?

• Is pure downlink 1.4 Gbps and uplink?

• Is my assumption that such a setup can cover an area up to 100m free space path propagation with reduced bandwidth (MHz) and throughput (Mbps)?

I know it’s a lot of questions in an off-topic thread, but still I would appreciate a lot and thank you in advance if you could address my questions.

I’m aware of the project ORAN 7.2 RU Guide tutorial and the knowledge base, but maybe it would be good if the srs team can add a hardware sizing and physical specification/sizing tutorial.

Thanks a lot in advance.

Alen

[ismagom]

Hi @Zplusless , at the moment ACC100 support is only available to our commercial licensees.

[Zplusless]

@ismagom Thanks for your timely reply!

[Sivanesh1992]

Hi team and @ismagom
As you mention ACC 100 support SRSRAN commercial licensees . Let me know the price to purchase licensees.

[ismagom]

Hi @Sivanesh1992, please contact [email protected]
Thanks

[Sivanesh1992]

Thankyou @ismagom

[Ali78k]

Hi community, I hope you are fine and doing well. I have two Questions:

1. Instead of using the Falcon-RX product, do you recommend any other product?
2. Is there any solution without using 5G xHaul Timing Aware O-RAN Switch & PTP Grandmasters? I’ve heard a little bit about Time Sync NICs. Telefonica has mentioned Time Sync NICs in this white paper.

[ninjab3s]

Hi @Ali78k,

1. We cannot recommend something else because we are only using FibroLAN switches in our lab. But I have seen plenty of other solutions (Microtik for example) that also works. I think if you google a little bit you will find other solutions that work for O-RAN applications!
2. Yes, for example there is the E810-XXVDA4T [1] from Intel that has GPS built in. You can use an LLS-C1 [2] configuration if you are only operating one CU/DU and one RU. In theory you could even drive 2RUs and 2CU/DUs if you can cable them, but that depends on the RUs.

[1] https://cdrdv2-public.intel.com/641626/Intel%20Ethernet%20Network%20Adapter%20E810-XXVDA4T%20Product%20Brief.pdf
[2] https://www.techplayon.com/o-ran-fronthaul-transport-synchronization-configurations/

[Ali78k]

thanks @ninjab3s

appreciate ur comment

[andrepuschmann]

Hey @Ali78k, @aruvic ,

thanks for those very interesting questions. We are indeed working on compiling a BoM for a much cheaper ORAN setup. But the challenge here, as with any engineering task, the answer is always: it depends. It depends on so many things, starting with the bandwidth, MIMO, users, number of cells, followed by lab setup, whether or not you have good GPS, etc., etc.

You certainly don't need a big Xeon or EPYC server. Compute performance is important but a recent desktop Ryzen for example will be enough (with all FEC running in software), especially for experimentation and if you don't plan to deploy anything and need to guarantee some level of performance 24/7.

The NIC is in fact quite important, especially because of the timing. It's a longer discussion around how NICs are built and how the timing works but in general the Intel NICs are fine. The E810 is particularly interesting. Whether you need GPS on board or use a switch plus external GM is again a "depends" matter. But you don't need the 25G. 10G is enough, a full 100MHz 4x4 DL will use approx 5.5Gbit/s.

As for the switch I can recommend the Mikrotik CRS326-24S+2Q+. It supports PTP transport on all ports but you do need an extra PTP GM.

Hope that helps.

[Ali78k]

thanks dear @andrepuschmann

ur opinion about NIC and switch devices are so much amazing
im going to search more about that and will inform u

[safwan2m]

We have a different RU which we tested with other CU/DU with 7.2 split. Can we test other 7.2 split RUs with this code?

[andrepuschmann]

Hey @safwan2m - sure as long as the RU is 7.2 compatible it'll work. Depending on how configurable the RU is you might have to fiddle a bit to find a working configuration.