srsran/srsran_project

Open source O-RAN 5G CU/DU solution from Software Radio Systems (SRS) https://docs.srsran.com/projects/project

srsRAN Project

The srsRAN Project is a complete 5G RAN solution, featuring an ORAN-native CU/DU developed by SRS.

The solution includes a complete L1/2/3 implementation with minimal external dependencies. Portable across processor architectures, the software has been optimized for x86 and ARM. srsRAN follows the 3GPP 5G system architecture implementing the functional splits between distributed unit (DU) and centralized unit (CU). The CU is further disaggregated into control plane (CU-CP) and user-plane (CU-UP).

See the srsRAN Project for information, guides and project news.

Build instructions and user guides - srsRAN Project documentation.

Community announcements and support - Discussion board.

Features and roadmap - Features.

Build Preparation

• Build tools:

  • cmake: https://cmake.org/

• Mandatory requirements:

  • libfftw: https://www.fftw.org/
  • libsctp: https://github.com/sctp/lksctp-tools
  • yaml-cpp: https://github.com/jbeder/yaml-cpp
  • PolarSSL/mbedTLS: https://www.trustedfirmware.org/projects/mbed-tls/
  • googletest: https://github.com/google/googletest/

You can install the build tools and mandatory requirements for some example distributions with the commands below:

Ubuntu 22.04

sudo apt-get install cmake make gcc g++ pkg-config libfftw3-dev libmbedtls-dev libsctp-dev libyaml-cpp-dev libgtest-dev

Fedora

sudo yum install cmake make gcc gcc-c++ fftw-devel lksctp-tools-devel yaml-cpp-devel mbedtls-devel gtest-devel

Arch Linux

sudo pacman -S cmake make base-devel fftw mbedtls yaml-cpp lksctp-tools gtest

The srsRAN Project supports split-8 and split-7.2 fronthaul.

Split-8 fronthaul is supported via UHD for USRP devices.

• UHD: https://github.com/EttusResearch/uhd
  • See UHD documentation for installation instructions.

Split-7.2 is supported via DPDK:

• DPDK: https://www.dpdk.org/

Build Instructions

Download and build srsRAN:

git clone https://github.com/srsran/srsRAN_Project.git
cd srsRAN_Project
mkdir build
cd build
cmake ..
make
make test

PHY layer tests use binary test vectors and are not built by default. To enable, see the docs.

How to deploy a 5G network?

Check our tutorials that describe how to set up an end-to-end 5G SA system with srsRAN Project.

srsran_project's Issues

srsRAN gNB with srsUE - UE stability issues

Issue Description

I'm following the recent tutorial 'srsRAN gNB with srsUE' from here https://docs.srsran.com/projects/project/en/latest/tutorials/source/srsUE/source/index.html. The UE attached and got and IP from the 5G core. In addition, ping from UE to gw was working fine. However, we observed some stability issues on the UE side, specifically, the UE lost connection and tried the random access several times.

Setup Details

2 USRP b210 as RF frontend
Open5gs
srsRAN_Project for gnb
srsRAN_4G for the UE
Leo Bodnar GPSDO (you recommend it)

Expected Behavior

The UE does not need to repeat the random access several times

Actual Behaviour

The UE losses connection and repeat the random access. See a screenshot of the UE terminal below

Steps to reproduce the problem

I follow the tutorial

Additional Information

Find below the logs of the UE and gNB.
ue.log

gnb.log

Error with SCTP Socket on ARM64 Build

Question

1. Is there a procedure to build srsRAN_Project source code for ARM64?
2. Does the srsRAN_Project's "gnb" use the sctp.ko file instead of the .so files?
   i. What is the cause of this issue?

Issue Description

When running srsRAN_Project "gnb" executable, the following error is produced:
"Failed to create SCTP socket: {}. Hint: Please ensure 'sctp' kernel module is available on the system."

Setup Details

1. Connect Xilinx ARM64 board to laptop (for access to the board via SSH).
2. SSH into the board and run the "gnb" executable with the TDD default configuration in srsRAN_Project's "configs" directory.
3. Error is output.

Expected Behavior

A session starting on the USRP b205-mini and showing the output of a correct setup with the RF device.

Actual Behaviour

"gnb" program outputs the following:
"Failed to create SCTP socket: {}. Hint: Please ensure 'sctp' kernel module is available on the system."

Steps to reproduce the problem

/path/to/srsRAN_Project/apps/gnb/gnb -c /path/to/srsRAN_Project/configs/gnb_rf_b200_tdd_n78_20mhz.yml

Does srsue can connect srsgnb and open5Gs

I am currently working on a 5G SA project that requires that I deploy nrUE and gNB with TDD frontends. I have already deployed the gNB from the srsRAN project andOpen5gs as CN.

However, I wonder if the existing srsUE code will attach with the gNB? The documentation states that the gNB can work with any third-party UE or COTS UE, is there support of srsUE already? If anyone has tried, kindly let me know.

This is discussed further in the relevant app note.

If you plan to connect the gNB to a COTS UE we recommend that you use an external clock source such as an Octoclock of GPSDO that is compatible with your RF-frontend, as the on-board clock within the USRP is not accurate enough to enable a connection with the UE. This is discussed further in the relevant app note.

https://docs.srsran.com/projects/project/en/latest/user_manuals/source/1_getting_started.html

Is the other way round also true, i.e. is an external clock needed if the srsue is to be connected to a cots gNB

GNB failed to bind SCTP socket, Cannot assign requested address

Hello everyone!

I'm trying to run the ZQM setup with Open5GS. I used the conf files from the docs, and obtained this:

Hope someone can help me with this.

slicing capabilities

Does srsRAN enable any slicing capabilities? In the config files, it is stated that the eMBB and URLLC slices are directed to the gNodeB.
Is it implemented yet? is there any way to test this capability yet?

Cannot connect srsUE to gNB through ZMQ. Gets stuck on RRC Connected.

Discussed in #92

^{Originally posted by fabio-patrizi June 7, 2023}
Hi all,
I'm having troubles in connecting the srsUE to the gNB via ZMQ.

I've followed the steps in the tutorial. I have built open5gs, srsRAN_Project and srsRAN_4G from sources on Ubuntu 22.04.2 LTS (actually, I'm on a Mac M1 Max). Each of them seems to work fine and apparently the gNB and open5gs connect with each other. However, the srsUE seems to fail in connecting. Details follow.

gNB commit is 56a771d
srsUE commit is 921f17484

(Expected behavior)
As per the tutorial, the srsUE output should end by something as follows:
...
RRC Connected
PDU Session Establishment successful. IP: 10.45.10.2
RRC NR reconfiguration successful.

(Observed behavior)
Instead, I get the following:

Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so
Inactive RF plugins:
Reading configuration file ./srsRAN_4G/build/ue_zmq.conf...

Built in Release mode using commit 921f17484 on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://127.0.0.1:2001,rx_port=tcp://127.0.0.1:2000,base_srate=11.52e6
Supported RF device list: UHD zmq file
CHx base_srate=11.52e6
Current sample rate is 1.92 MHz with a base rate of 11.52 MHz (x6 decimation)
CH0 rx_port=tcp://127.0.0.1:2000
CH0 tx_port=tcp://127.0.0.1:2001
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Complete. c-rnti=0x4601, ta=0
RRC Connected

In particular, I do not get the lines:

PDU Session Establishment successful. IP: 10.45.10.2
RRC NR reconfiguration successful.

which indicate successful connection (according to the tutorial).

When I test the connection with ping, it doesn't work.

gNB output is:
Lower PHY in executor blocking mode.

--== srsRAN gNB (commit 56a771d) ==--

Connecting to AMF on 127.0.0.5:38412
Available radio types: uhd and zmq.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type to view trace

Configuration files are attached below:

open5gs:
amf.yaml.txt
upf.yaml.txt

gNB:
gnb_zmq.yaml.txt

UE:
ue_zmq.conf.txt

Subscriber configuration is attached below. I tried AMF both 8000 and 9000, none work. BTW, where do I get the correct value?

To reproduce the issue, just run the open5gs, followed by the gNB, then by the srsUE. If needed, I can provide the specific command lines used, as well as the logs.

Thank you in advance for any help you can provide.
Best!

UE context release does not happen after UE goes to 'emergency calls only'.

Issue Description

I am using srsRAN gNB and Open5GS core with COTS UE. I see PDUSessionResourceSetupResponse and UE then goes to 'emergengy calls only' state. There is no gNB crash and as I toggled the flight mode, I see registration request gain and then UE context release happens. I tried toggling the flight mode before the UE goes 'emergency calls only' state but same thing happened.

Setup Details

Core- Open5GS
srsRAN gNB in TDD mode band 78, BW- 20 MHz
USRP- x310 and b210 (tested with both USRPs)
e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

Expected Behavior

context release should happen when UE is put in fight mode.

Actual Behaviour

context release is not initiated when UE is put in fight mode. It is initiated after same UE again attempts registration.

Steps to reproduce the problem

Toggle flight mode On on UE.

Logs and PCAP:
gnb and core logs.zip

ERROR Late: 0; Underflow: 1; Overflow: 0;

I am trying to set up a network using B210, srsRAN_Project, Open5gs, and COTS UE. Although I can see the network (001 01), when I try to connect, it fails after a few seconds. From my UE's perspective, this situation is similar to when the gnb is turned off. I suspect that my UE's uplink signal may not be reaching the gnb, but I am not sure. Additionally, I have noticed underflows and errors in the gnb logs.

gnb.log:
Real-time failure in FAPI: Received late DL_TTI.request. Current slot is 883.17 while message corresponds to 883.16
Real-time failure in FAPI: Received UL_TTI.request message out of time. Current slot is 883.17 while message corresponds to 883.16
Real-time failure in FAPI: Received late DL_TTI.request. Current slot is 884.1 while message corresponds to 884.0
Real-time failure in FAPI: Received UL_TTI.request message out of time. Current slot is 884.1 while message corresponds to 884.0

gnb.log

e320 Tx while waiting for EOB, timed out

Issue Description

Hello all, I am trying to run my x300 as a gNB and my e320 as a UE. I followed the tutorial on the documentation page and the X300 starts the gNB with no errors. It also displays a solid red light with no flashing; so I assume it's working.

However, when I start srsUE, my e320's LED constantly flashes and I receive a lot of Tx EOB errors. It naturally doesn't connect to the gNB. Is the e320 supported? Or am I just not configuring it correctly (most likely the latter)?

Setup Details

Asus ROG Laptop (i9-8950HK, 2.5gbe, nvidia rtx 2080 mobile) UHD 4.3.0-HEAD-0-g1f8fd345 Rocky Linux 8.7 Ettus E320 and Ettus X300

Expected Behavior

e320 UE connects to X300 gNB

Actual Behaviour

This is the output I am receiving from the srsUE

mgmt_addr=192.168.10.3,type=e3xx,product=e320,fpga=1G,claimed=False,addr=192.168.10.3
[INFO] [MPM.PeriphManager] init() called with device args `fpga=1G,mgmt_addr=192.168.10.3,name=ni-e320-325EA60,product=e320'.
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[INFO] [UHD RF] Tx while waiting for EOB, timed out... 0.696468 >= 0. Starting new burst...
[INFO] [UHD RF] Tx while waiting for EOB, timed out... 2.83964 >= 2.82837. Starting new burst...
[INFO] [UHD RF] Tx while waiting for EOB, timed out... 4.85771 >= 4.85487. Starting new burst...
[INFO] [UHD RF] Tx while waiting for EOB, timed out... 6.94006 >= 6.92813. Starting new burst...
[INFO] [UHD RF] Tx while waiting for EOB, timed out... 8.95937 >= 8.95532. Starting new burst...
[INFO] [UHD RF] Tx while waiting for EOB, timed out... 11.0552 >= 11.0295. Starting new burst...

Steps to reproduce the problem

I followed the online tutorial srsRAN gNB with srsUE. I then started the srsRAN gNB with the X300. It connects to my open5gs core, with the number of gNBs becoming 1. and I receive the following line like in the tutorial:
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

I then start the srsRAN UE with the e320 and receive the tx EOB info warnings.

Additional Information

The e320 is started with type=e3xx, sampling_rate=11.52e6, lo_freq_offset_hz=11.52e6, addr=192.168.10.3

Cannot build tests

Issue Description

[Describe the issue in detail]
Cannot build tests. It happens with commit 56a771d but also with previous.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions
Just clone and build

git clone https://github.com/srsran/srsRAN_Project
mkdir build && cd build
cmake ..
make

It fails with the following log:

[ 52%] Building CXX object tests/unittests/du_high/CMakeFiles/paging_du_high_test.dir/test_utils/du_high_test_bench.cpp.o
In file included from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.h:25,
                 from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.cpp:23:
/home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h: In constructor 'constexpr srsran::du_high_worker_manager::du_high_worker_manager()':
/home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h:32:8: error: use of deleted function 'srsran::task_worker::task_worker(srsran::task_worker&&)'
   32 | struct du_high_worker_manager {
      |        ^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h:28,
                 from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.h:25,
                 from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.cpp:23:
/home/phenarejos/srsRAN_Project/include/srsran/support/executors/task_worker.h:57:3: note: declared here
   57 |   task_worker(task_worker&&)                 = delete;
      |   ^~~~~~~~~~~
In file included from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.h:25,
                 from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.cpp:23:
/home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h:32:8: error: use of deleted function 'srsran::task_worker::task_worker(srsran::task_worker&&)'
   32 | struct du_high_worker_manager {
      |        ^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h:28,
                 from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.h:25,
                 from /home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.cpp:23:
/home/phenarejos/srsRAN_Project/include/srsran/support/executors/task_worker.h:57:3: note: declared here
   57 |   task_worker(task_worker&&)                 = delete;
      |   ^~~~~~~~~~~
/home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.cpp: In constructor 'srsran::srs_du::du_high_test_bench::du_high_test_bench()':
/home/phenarejos/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_test_bench.cpp:176:58: note: synthesized method 'constexpr srsran::du_high_worker_manager::du_high_worker_manager()' first required here
  176 |   next_slot(0, test_rgen::uniform_int<unsigned>(0, 10239))
      |                                                          ^
make[2]: *** [tests/unittests/du_high/CMakeFiles/paging_du_high_test.dir/build.make:63: tests/unittests/du_high/CMakeFiles/paging_du_high_test.dir/test_utils/du_high_test_bench.cpp.o] Error 1
make[2]: Leaving directory '/home/phenarejos/srsRAN_Project/build'
make[1]: *** [CMakeFiles/Makefile2:8948: tests/unittests/du_high/CMakeFiles/paging_du_high_test.dir/all] Error 2
make[1]: Leaving directory '/home/phenarejos/srsRAN_Project/build'
make: *** [Makefile:141: all] Error 2

Of course, if I disable test build it builds successfully:

cmake .. -DBUILD_TESTS=0

Expected Behavior

[What you expect to happen]
Build should success without errors with tests.

Actual Behaviour

[What happens instead e.g. error message]
It cannot build all tests. Tests du_high_test, paging_du_high_test and cu_du_test fail with the same error.

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]

git clone https://github.com/srsran/srsRAN_Project
mkdir build && cd build
cmake ..
make

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

• Debian 11.7
• gcc 10.2.1-6

Related with #12

As highlighted, copy constructor of task_worker is deleted, but struct in du_high_worker_manager.h initializes task_worker members with constant objects (which use copy constructor in turn). I do not know why the copy constructor is deleted and if is safe to put it back. Cannot figure out the consequences of putting back.

When will srsRAN Project support srsUE?

Issue Description

[Describe the issue in detail]

srsUE is not working with the new gNB. Do you know when we can anticipate the functionality?

We dont use any radios for our research, so we are kind of blocked without the zmq support in the new gNB. Is there a work around using any other non-radio UE?

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

• Run srsRAN Project gNB
• Use srsUE from srsRAN_4G

Expected Behavior

[What you expect to happen]
srsUE successfully connect to gNB

Actual Behaviour

[What happens instead e.g. error message]
srsUE doesnt connect to the gNB

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]
Already mentioned above.

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

INI was not able to parse common_cell.++

I was getting this error. Although gut pulls and updated.
Can anyone suggest solutions, please
.

Error, Band is not Valid: NR Band 46

Issue Description

When configuring a gnb .yml file under the cell_cfg: section with various dl_arfcn values from table 5.4.2.3-1 and 5.4.2.3-2 of 3GPP TS 38.101-1 version 16.5.0 Release 16 for NR Band N46 and then running the gnb with -c argument pointed at the .yml, the following error occurs:

Invalid DL ARFCN=7xxxxx for band 46. Cause: Band is not valid.
srsGNB ERROR: Invalid configuration detected.

Is NR Band 46 (5150 to 5925 MHz) currently supported by srsRAN_Project as Feature List lists "FDD/TDD supported, all FR1 bands"?

Using the supplied example TDD config with various dl_arfcn, this error does not occur (e.g. 620000, 78, 20Mhz, 30kHz).

Setup Details

Open5gs core on external server, x86 machine running Debian 11.6.0 with UHD drivers, B200 and compiled GNB.

Expected Behavior

Proceed to "Making USRP Object" with n46 config .yml, just like the n78 example.

Actual Behaviour

Invalid DL ARFCN=785668 for band 46. Cause: Band is not valid.
srsGNB ERROR: Invalid configuration detected.

Steps to reproduce the problem

cell_cfg:
dl_arfcn: 785668
band: 46
channel_bandwidth_MHz: 20
common_scs: 15
plmn: "99970"
tac: 7
pci: 1

Additional Information

srsUE attempts cell searching only once and fails to connect to the srsgnb

Issue Description

[Describe the issue in detail]

srsUE cannot connect to srsgNB since srsUE does not attempt cell searching repeatedly. Compared to the LTE cell searching, which keeps trying to connect to LTE BS, srsUE with 5G setting only tries cell selection once.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

OS: gNB for ubuntu 22.04, UE for ubuntu 20.04
Hardware: both with i9-10940X CPU
RF: both with USRP2943R (X310)
library: UHD 4.4.0
srsRAN version:
srsUE for commit fa56836b14dc6ad7ce0c3484a1944ebe2cdbe63b in srsRAN_4G
srsgNB for commit 549d121 in srsRAN_project

Expected Behavior

[What you expect to happen]

srsUE should attempt to attach to the srsGNB until it connects to it.

Actual Behaviour

[What happens instead e.g. error message]

srsUE does not attempt to connect to srsGNB.

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]

ue.log.txt

ue.conf.txt

gnb.conf.txt

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

Setting SD and SST

Is there a way to set the SD and SST (NSSAI) in the configuration file?

showing late/underflow/overflow while running gnb

--== srsRAN gNB (commit fbe73a4) ==--

Connecting to AMF on 127.0.0.5:38412
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.0-0ubuntu1~focal1
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Making USRP object with args 'type=b200,num_recv_frames=64,num_send_frames=64'
[INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
[INFO] [B200] Detected Device: B210
[INFO] [B200] Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Detecting internal GPSDO....
[INFO] [GPS] Found an internal GPSDO: GPSTCXO , Firmware Rev 0.929a
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [MULTI_USRP] Setting master clock rate selection to 'manual'.
[INFO] [B200] Asking for clock rate 23.040000 MHz...
[INFO] [B200] Actually got clock rate 23.040000 MHz.
Cell pci=1, bw=10 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=632640, ul_freq=3489.42 MHz

==== gNodeB started ===
Type to view trace
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 2; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;

fyi : im using open5gs as core and Usim from sysmocom and USRP B210

what should i do to fix this problem?

Payload protocol identifier is not specified in SCTP

Issue Description

Payload protocol identifier is not specified in SCTP

Setup Details

The latest code was built, USRP B200, UHD 4.1

Expected Behavior

Payload protocol identifier should be specified as NGAP for N2 in SCTP

Steps to reproduce the problem

This case can be found in any NGAP packet from gNB to AMF

• gNB to AMF
  

• AMF to gNB
  

zmq tutorial and examples

Hi srsran,
It seems the entire project just underwent major changes and all old resources are now 404. I wonder what happened to srsRAN? And is there a renewed version on connecting srsUE with gNB via zmq?

Is an external clock necessary?

Issue Description

When 5G is used as gnb and 4G is used as ue, the two cannot be connected. Is an external clock necessary? If no external clock is needed, how to modify the configuration file? Look forward to your reply. Thank you

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

Expected Behavior

[What you expect to happen]

Actual Behaviour

[What happens instead e.g. error message]

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

usrp x300 not running

Issue Description

[Describe the issue in detail]
after command
gnb -c gnb_rf_x300_fdd_n3_20mhz.yml

stdout:

Available radio types: uhd.

--== srsRAN gNB (commit 77be7d339) ==--

[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.3.0.HEAD-0-g1f8fd345
Making USRP object with args 'type=x300,master_clock_rate=184.32e6,send_frame_size=8000,recv_frame_size=8000'
Error: failed to read sensors. 
Error: setting gain for transmitter 0. Tx gain (i.e., 35.0 dB) is out-of-range. Range is [0.0, 31.5] dB in steps of 0.5 dB.
Error: setting gain for receiver 0. Rx gain (i.e., 60.0 dB) is out-of-range. Range is [0.0, 37.5] dB in steps of 0.5 dB.
srsGNB ERROR: Unable to create radio session.

Is there any specific gcc, g++ version requirement?

Issue Description

Unable to build the project

Setup Details

Ubuntu 18.04.6 LTS
cmake 3.25.2(I manually installed)
gcc 7.5.0
g++ 7.5.0

Expected Behavior

Build Success

Actual Behaviour

Build Fail

Steps to reproduce the problem

Just tried build as you told me.

Additional Information

Although I successfully build with manullay installed g++-11 and gcc-11, it would be nice to have minimum version requirement.

stdout and log file empty until exit

Issue Description

Hello thanks for the work here!

While running command:
sudo gnb -c config.yml

the problem is that there is no stdout and log files are empty until i quit, ctrl+c command.
Its look like also that usrp doesn't work properly (tx/rx leds are off).

Looks like also no connection is made with AMF (looking at the amf logs) but on in the log it says [GNB ] [I] AMF connection established thats sounds strange.

I'm little bit lost.

Setup Details

make test runs ok

Os: Ubuntu 20.04.5 LTS
USRP: x310 (also tested with b210)
gnb: 0.1
UHD: 3.15.0.0-2build5
gnuradio: 3.8.1.0
something more needed?

Expected Behavior

Log file and stdout output while running

Actual Behaviour

no output on the stdout or logfile while running

Steps to reproduce the problem

config file:
gnbconf.log

gnb.log:
gnb.log

Additional Information

The usrp and gnuradio stack seems to be functional cause I've tested it with the command:
./rx_ascii_art_dft --freq 98e6 --rate 5e6 --gain 20 --bw 5e6 --ref-lvl -30

Thanks for any help

About new config file

Hi

• Is it possible to have two separate interface binding for NGAP LOCAL ADDRESS & GTPU LOCAL ADDRESS ?
• Is there plan to network slicing support ?

srsRAN Project Documentation can not be downloaded

The documentation to srsRAN Project can not be downloaded anymore, which i found to be a helpful feature. Is it possible to bring the function back?

Low data transfer bandwith

Issue Description

I have low values (specially in upload speed): DL: 15.6Mb/s and UL: 0.56 Mb/s.
In the trace of the gnb I can see most of the packets are using MCS 28, but in the mobile phone using NSG, i see 64QAM modulation is used (shouldnt it be 256?).

Setup Details

Xiaomi Redmi Note 10 5G, Open5Gs, i7 vPro CPU, band n7, b200 mini.
bw=20 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=632544, ul_freq=3489.42 MHz

Expected Behavior

Higher speeds.

Actual Behaviour

Low speeds.

Additional Information

What parameters can be modified for improving this bandwith? I have seen in documentation that 140 Mbps for DL and 120 Mbps have been achieved...

Thanks in advance

example config file doesn't exists

Hi srsRAN,

Thanks a lot for this project,
I cannot find configs/ folder in codes, can you please share or update source codes?

Question about dynamic MCS adaptation

Issue Description
[Describe the issue in detail]
Only fixed MCS is available

Setup Details
5G gNB

Expected Behavior
Dynamic MCS adaptation

Actual Behaviour
No functions for dynamic MCS adaptation

Steps to reproduce the problem
Missing feature.

Additional Information
Is there any support for adaptive MCS? I guess it is the one of the most importatnt feature for RAN, but I cannot find such feature.

COTS UE can not connect

Issue Description

UE can not connect

I only used the internal b210 clock - may that the issue for the connection problem?

That would not explain the missing network name on the UE GUI side

How can I get more relevant debug data? The phone is an unrooted android with adb access

Setup Details

amf:
  addr: 127.0.0.5                 # The address or hostname of the AMF.
  bind_addr: 127.0.0.1              # A local IP that the gNB binds to for traffic from the AMF.

rf_driver:
  device_driver: uhd                # The RF driver name.
  device_args: type=b200            # Optionally pass arguments to the selected RF driver.
  clock:                            # Specify the clock source used by the RF.
  sync:                             # Specify the sync source used by the RF.
  srate: 30.72                      # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 50                       # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 60                       # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
  dl_arfcn: 632628                  # ARFCN of the downlink carrier (center frequency).
  band: 78                          # The NR band.
  channel_bandwidth_MHz: 20         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 30                    # Subcarrier spacing in kHz used for data.
  plmn: "90170"                     # PLMN broadcasted by the gNB.
  tac: 1                            # Tracking area code (needs to match the core configuration).
  pci: 1                            # Physical cell ID.
      
log:
  filename: /tmp/gnb.log            # Path of the log file.
  all_level: debug                # Logging level applied to all layers.

pcap:
  mac_enable: true                 # Set to true to enable MAC-layer PCAPs.
  mac_filename: /tmp/gnb_mac.pcap   # Path where the MAC PCAP is stored.
  ngap_enable: true                # Set to true to enable NGAP PCAPs.
  ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.

amf.yaml

logger:
    file: /var/log/open5gs/amf.log
sbi:
    server:
      no_tls: true
      cacert: /etc/open5gs/tls/ca.crt
      key: /etc/open5gs/tls/amf.key
      cert: /etc/open5gs/tls/amf.crt
    client:
      no_tls: true
      cacert: /etc/open5gs/tls/ca.crt
      key: /etc/open5gs/tls/amf.key
      cert: /etc/open5gs/tls/amf.crt
amf:
    sbi:
      - addr: 127.0.0.5
        port: 7777
    ngap:
      - addr: 127.0.0.5
    metrics:
      - addr: 127.0.0.5
        port: 9090
    guami:
      - plmn_id:
          mcc: 901
          mnc: 70
        amf_id:
          region: 2
          set: 1
    tai:
      - plmn_id:
          mcc: 901
          mnc: 70
        tac: 1
    plmn_support:
      - plmn_id:
          mcc: 901
          mnc: 70
        s_nssai:
          - sst: 1
    security:
        integrity_order : [ NIA2, NIA1, NIA0 ]
        ciphering_order : [ NEA0, NEA1, NEA2 ]
    network_name:
        full: Test
    amf_name: open5gs-amf0
scp:
    sbi:
      - addr: 127.0.1.10
        port: 7777
parameter:
max:
usrsctp:
time:
  t3512:
    value: 540     # 9 mintues * 60 = 540 seconds

Expected Behavior

UE sees "Test" and connects to it

Actual Behaviour

UE sees "90170 5G" and can not connect to it

Steps to reproduce the problem

sudo /usr/bin/gnb -c gnb.conf

Additional Information

Available radio types: uhd.

--== srsRAN gNB (commit 0523be699) ==--

[INFO] [UHD] linux; Clang version 14.0.0 ; Boost_107400; UHD_4.4.0.0-68-g02558b69
Making USRP object with args 'type=b200'
Cell pci=1, bw=20 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=632544, ul_freq=3489.42 MHz

==== gNodeB started ===
Type <t> to view trace
Late: 0; Underflow: 16; Overflow: 0;
Late: 1; Underflow: 4; Overflow: 0;

tail -f /tmp/gnb.log /var/log/open5gs/*log |  grep -v Low-PHY

2023-03-22T13:15:44.078121 [NGAP    ] [I] Sending NgSetupRequest
2023-03-22T13:15:44.078187 [NGAP    ] [D] Tx NGAP PDU: {
  "initiatingMessage": {
    "procedureCode": 21,
    "criticality": "reject",
    "value": {
      "NGSetupRequest": {
        "protocolIEs": {
          {
            "id": 27,
            "criticality": "reject",
            "value": {
              "globalGNB-ID": {
                "pLMNIdentity": "09f107",
                "gNB-ID": {
                  "gNB-ID": "0000000000000110011011"
                }
              }
            }
          },
          {
            "id": 82,
            "criticality": "ignore",
            "value": "srsgnb01"
          },
          {
            "id": 102,
            "criticality": "reject",
            "value": [
              {
                "tAC": "000001",
                "broadcastPLMNList": [
                  {
                    "pLMNIdentity": "09f107",
                    "tAISliceSupportList": [
                      {
                        "s-NSSAI": {
                          "sST": "01"
                        }
                      }
                    ]
                  }
                ]
              }
            ]
          },
          {
            "id": 21,
            "criticality": "ignore",
            "value": "v256"
          }
        }
      }
    }
  }
}
2023-03-22T13:15:44.078553 [NGAP    ] [D] Handling PDU of type "successfulOutcome.NGSetupResponse"
2023-03-22T13:15:44.078572 [NGAP    ] [D] Rx NGAP PDU: {
  "successfulOutcome": {
    "procedureCode": 21,
    "criticality": "reject",
    "value": {
      "NGSetupResponse": {
        "protocolIEs": {
          {
            "id": 1,
            "criticality": "reject",
            "value": "open5gs-amf0"
          },
          {
            "id": 96,
            "criticality": "reject",
            "value": [
              {
                "gUAMI": {
                  "pLMNIdentity": "09f107",
                  "aMFRegionID": "00000010",
                  "aMFSetID": "0000000001",
                    "s-NSSAI": {
                      "sST": "01"
                    }
                  }
                ]
              }
            ]
          }
        }
      }
    }
  }
}
2023-03-22T16:01:03.728919 [NGAP    ] [D] Received PDU with successful outcome
2023-03-22T16:01:05.649001 [SCHED   ] [I] [     0.0] Cell with cell_index=0 was configured.
2023-03-22T16:01:06.750368 [RF      ] [W] Radio realtime event: Type=start-of-burst Source=tx Timestamp=80011086
2023-03-22T16:02:49.089853 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089857 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089858 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089858 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089859 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089861 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089862 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089864 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089865 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089866 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089868 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089869 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089870 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089871 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089872 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089873 [RF      ] [W] Radio realtime event: Type=underflow Source=tx Timestamp=na
2023-03-22T16:02:49.089884 [RF      ] [W] Radio realtime event: Type=end-of-burst Source=tx Timestamp=3223895884
2023-03-22T16:02:49.090919 [RF      ] [W] Radio realtime event: Type=start-of-burst Source=tx Timestamp=3223927716

gNb gets down on reconnection

Issue Description

When the UE is connected and the data is going without problem through ogstun interface, if I turn off the mobile data in UE, and turn on again, the gNb gets down with the following message:

--== srsRAN gNB (commit 56a771d) ==--

Connecting to AMF on 127.0.0.5:38412
Available radio types: uhd.
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.HEAD-0-g5fac246b
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Making USRP object with args 'type=b200'
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [MULTI_USRP] Setting master clock rate selection to 'manual'.
[INFO] [B200] Asking for clock rate 38.400000 MHz...
[INFO] [B200] Actually got clock rate 38.400000 MHz.
Cell pci=1, bw=20 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=632544, ul_freq=3489.42 MHz

==== gNodeB started ===
Type to view trace
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
terminate called after throwing an instance of 'std::out_of_range'
what(): map::at
Aborted

without more details in gnb.log or open5Gs amf.log.

Also, I am having problems getting the data through ogstun interface, I have to restart everything many times until get it working, even though the UE equipment is connected to the network always. I can see it by looking the arrows in the network icon not working and also in wireshark, seeing that no packets are seen in ogstun interface.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
USRP B200mini, external GPSDO, Open5gs, xiaomi redmi note 10 5g.

Expected Behavior

Reconnection without problems in the case of activating back the data.}
Data transmission working everytime the UE is connected to the network.

gNB not able to run using x300

Issue Description

I wanted to give srsgNB a try. I am currently testing srsgNB (w/ USRP X300) and with OAI5GC. The problem I am having is, I am unable to create a radio session. I tried to look at the gNB logs, but it seems like there is nothing there.

I can reproduce the issue mentioned in #7, but changing the mentioned parameters did not help. If anyone knows what I may be doing wrong, please do let me know.

Available radio types: uhd.
--== srsRAN gNB (commit 0523be6) ==--
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; UHD_4.2.0.HEAD-0
Making USRP object with args 'type=x300,master_clock_rate=184.32e6,send_frame_size=8000,recv_frame_size=8000'
srsGNB ERROR: Unable to create radio session.

amf:
  addr: 192.168.70.132                # The address or hostname of the AMF.
  bind_addr: 192.168.70.129              # A local IP that the gNB binds to for traffic from the AMF.

rf_driver:
  device_driver: uhd                # The RF driver name.
  device_args: type=x300            # Optionally pass arguments to the selected RF driver.
  clock: gpsdo                      # Specify the clock source used by the RF.
  sync: gpsdo                       # Specify the sync source used by the RF.
  srate: 11.52                      # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 20.5                       # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 50.0                       # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
  dl_arfcn: 632628                  # ARFCN of the downlink carrier (center frequency).
  band: 78                          # The NR band.
  channel_bandwidth_MHz: 10         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 30                    # Subcarrier spacing in kHz used for data.
  plmn: "99970"                     # PLMN broadcasted by the gNB.
  tac: 1                            # Tracking area code (needs to match the core configuration).
  pci: 1                            # Physical cell ID.
log:
  filename: /tmp/gnb.log            # Path of the log file.
  all_level: warning                # Logging level applied to all layers.
pcap:
  mac_enable: true                 # Set to true to enable MAC-layer PCAPs.
  mac_filename: /tmp/gnb_mac.pcap   # Path where the MAC PCAP is stored.
  ngap_enable: true                # Set to true to enable NGAP PCAPs.
  ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.

The output of _uhd_find_devices

[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; UHD_4.2.0.HEAD-0
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    serial: 3243FD3
    addr: 192.168.40.2
    fpga: HG
    name:
    product: X300
    type: x300

srsue and gnb compatibility with ZMQ

Issue Description

UE does not attach with gNodeB using srsue.

Setup Details

srsue: 22.10
gnb: 0.1
RF front-end: libzmq.so.5 (ZMQ)
5G core: open5gs

Expected Behavior

gNodeB attaches with open5gs core and the srsue UE too.

Actual Behaviour

gNodeB attaches with open5gs but srsue UE doesn`t.

Steps to reproduce the problem

$ srsue ue.conf

ue.conf.zip

$ gnb -c gnb_rf_zmq_tdd_n78_10mhz.yml

gnb_rf_zmq_tdd_n78_10mhz.yml.zip

Additional Information

Test pcap in the gNodeB host:

test-srs.pcapng.zip

External GPSDO Error

Issue Description

When configuring for using external clock, the radio session cannot be created:

sudo gnb -c gnb_avag.yml 
Available radio types: uhd.

--== srsRAN gNB (commit 0523be699) ==--

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.HEAD-0-g5fac246b
Making USRP object with args 'type=b200'
srsGNB ERROR: Unable to create radio session.

Same external GPSDO function is working on srsRAN 4G gnb by using device_args = clock=external in config file, so it should not be a problem related to this external clock...

Setup Details

I am using a OnePlus Nord 2 as UE, USRP b200 mini and Open5Gs as 5G Core.
For using the external clock, I am configuring the yaml with the following lines:

rf_driver:
  device_driver: uhd                # The RF driver name.
  device_args: type=b200        # Optionally pass arguments to the selected RF driver.
  clock: external             # Specify the clock source used by the RF.
  sync: external                       # Specify the sync source used by the RF.
  srate: 30.72                   # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 60                       # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 50   

Expected Behavior

Gnb executes using the external GPSDO as reference.

Actual Behaviour

Gnb has an error when tryin to use the external clock.

long duration data test dont work

Issue Description

I am trying iperf in DL but data session wont last more than 10 -20 seconds , I tried external clock 10 Mhz also but results are same , can someone help

Setup Details

I am using USRP 205mini and below is config for clock .

rf_driver:
  device_driver: uhd                # The RF driver name.
  device_args: type=b200            # Optionally pass arguments to the selected RF driver. 
clock: external                      # Specify the clock source used by the RF. 
sync: external  

Could not find valid 5QI 5

Issue Description

2023-03-02T10:01:33.390175 [CU-CP ] [W] Could not find valid 5QI 5. QoS map size 2
2023-03-02T10:01:33.390176 [CU-CP ] [E] ue=2: "PDU Session Creation Routine" QoS flow 5QI is not configured. id 1 5QI 5
2023-03-02T10:01:33.390177 [CU-CP ] [E] ue=2: "PDU Session Creation Routine" failed.

Setup Details

I connected Fibocom FM150 with srsran + open5gs.

The problem occurs when creating pdusession for dnn="IMS"

gNB with b210

I'm trying to connect srsue with the gnB (each running a B210 sdr) but can not achieve that.
(for the core I basically followed https://open5gs.org/open5gs/docs/guide/01-quickstart/, but I guess that is irrelevant at this point since the connection between gnB and UE is not even built)

gNB

amf:
  addr: 10.10.0.5                 # The address or hostname of the AMF.
  bind_addr: 127.0.0.1              # A local IP that the gNB binds to for traffic from the AMF.
rf_driver:
  device_driver: uhd                # The RF driver name.
  device_args: type=b200            # Optionally pass arguments to the selected RF driver.
  clock:                            # Specify the clock source used by the RF.
  sync:                             # Specify the sync source used by the RF.
  srate: 11.52                      # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 50                       # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 60                       # Receive gain of the RF might need to adjusted to the given situation.
cell_cfg:
  dl_arfcn: 632628                  # ARFCN of the downlink carrier (center frequency).
  band: 78                          # The NR band.
  channel_bandwidth_MHz: 10         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 30                    # Subcarrier spacing in kHz used for data.
  plmn: "00101"                     # PLMN broadcasted by the gNB.
  tac: 7                            # Tracking area code (needs to match the core configuration).
  pci: 1                            # Physical cell ID.
log:
  filename: /tmp/gnb.log            # Path of the log file.
  all_level: debug                # Logging level applied to all layers.
pcap:
  mac_enable: true                 # Set to true to enable MAC-layer PCAPs.
  mac_filename: /tmp/gnb_mac.pcap   # Path where the MAC PCAP is stored.
  ngap_enable: true                # Set to true to enable NGAP PCAPs.
  ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.

 sudo build/apps/gnb/gnb -c gnb.conf
Available radio types: uhd.

--== srsRAN gNB (commit 77be7d339) ==--

[INFO] [UHD] linux; Clang version 14.0.0 ; Boost_107400; UHD_4.4.0.0-0-g5fac246b
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Making USRP object with args 'type=b200'
[DEBUG] [B200] the firmware image: /usr/share/uhd/images/usrp_b200_fw.hex
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[DEBUG] [AD936X] baseband bandwidth too large for current sample rate. Setting bandwidth to: 5e+07
[INFO] [B200] Performing register loopback test... 
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test... 
[INFO] [B200] Register loopback test passed
[DEBUG] [AD936X] Performing CODEC loopback test... 
[DEBUG] [AD936X] CODEC loopback test passed.
[DEBUG] [AD936X] Performing CODEC loopback test... 
[DEBUG] [AD936X] CODEC loopback test passed.
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz... 
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[DEBUG] [CORES] Performing timer loopback test... 
[DEBUG] [CORES] Timer loopback test passed.
[DEBUG] [CORES] Performing timer loopback test... 
[DEBUG] [CORES] Timer loopback test passed.
[INFO] [MULTI_USRP] Setting master clock rate selection to 'manual'.
[INFO] [B200] Asking for clock rate 11.520000 MHz... 
[INFO] [B200] Actually got clock rate 11.520000 MHz.
[DEBUG] [CORES] Performing timer loopback test... 
[DEBUG] [CORES] Timer loopback test passed.
[DEBUG] [CORES] Performing timer loopback test... 
[DEBUG] [CORES] Timer loopback test passed.
[DEBUG] [CONVERT] get_converter: For converter ID: conversion ID
  Input format:  fc32
  Num inputs:    1
  Output format: sc16_item32_le
  Num outputs:   1
 Using best available prio: 3
[DEBUG] [CONVERT] get_converter: For converter ID: conversion ID
  Input format:  sc16_item32_le
  Num inputs:    1
  Output format: fc32
  Num outputs:   1
 Using best available prio: 3
Cell pci=1, bw=10 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=632640, ul_freq=3489.42 MHz

==== gNodeB started ===
Type <t> to view trace
Late: 79; Underflow: 211; Overflow: 2;
Late: 77; Underflow: 227; Overflow: 0;
...

UE

[rf]
freq_offset = 0
tx_gain = 50
rx_gain = 60
[rat.eutra]
dl_earfcn = 3350
nof_carriers = 1
[rat.nr]
bands = 78
dl_nr_arfcn = 632628
ssb_nr_arfcn = 632640
[pcap]
enable = none
mac_filename = /tmp/ue_mac.pcap
mac_nr_filename = /tmp/ue_mac_nr.pcap
nas_filename = /tmp/ue_nas.pcap
[log]
all_level = warning
phy_lib_level = none
all_hex_limit = 32
filename = /tmp/ue.log
file_max_size = -1
[usim]
mode = soft
algo = milenage
opc  = 63BFA50EE6523365FF14C1F45F88737D
k    = 00112233445566778899aabbccddeeff
imsi = 001010123456780
imei = 353490069873319
[rrc]
[nas]
[gw]
[gui]
enable = false
[channel.dl]
[channel.dl.awgn]
[channel.dl.fading]
[channel.dl.delay]
[channel.dl.rlf]
[channel.dl.hst]
[channel.ul]
[channel.ul.awgn]
[channel.ul.fading]
[channel.ul.delay]
[channel.ul.rlf]
[channel.ul.hst]
[phy]
[phy.nr]
[cfr]
[sim]
[general]

sudo srsue ue.conf
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so
Inactive RF plugins: 
Reading configuration file ue.conf...
WARNING: cpu0 scaling governor is not set to performance mode. Realtime processing could be compromised. Consider setting it to performance mode before running the application.

Built in Debug mode using commit 80cc511 on branch main.

Opening 1 channels in RF device=default with args=default
Supported RF device list: UHD zmq file
Trying to open RF device 'UHD'
[INFO] [UHD] linux; Clang version 14.0.0 ; Boost_107400; UHD_4.4.0.0-0-g5fac246b
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Opening USRP channels=1, args: type=b200,master_clock_rate=23.04e6
[INFO] [UHD RF] RF UHD Generic instance constructed
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test... 
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test... 
[INFO] [B200] Register loopback test passed
[INFO] [B200] Asking for clock rate 23.040000 MHz... 
[INFO] [B200] Actually got clock rate 23.040000 MHz.
RF device 'UHD' successfully opened
Waiting PHY to initialize ... done!
Attaching UE...
.
.
Found Cell:  Mode=FDD, PCI=445, PRB=100, Ports=2, CP=Normal, CFO=-7.3 KHz
RF status: O=6, U=0, L=0
.
Found Cell:  Mode=FDD, PCI=445, PRB=100, Ports=2, CP=Normal, CFO=-5.6 KHz
.
.
RF status: O=15, U=0, L=0
..
...
.
Found Cell:  Mode=FDD, PCI=445, PRB=100, Ports=2, CP=Normal, CFO=-7.7 KHz
.
.

spectrum analyzer

I would further expect a peak around 3489.42 MHz; but I only see noise

 /usr/lib/uhd/examples/rx_ascii_art_dft --freq 3489420000 --rate 5e6 --gain 60 --bw 5e6 --ref-lvl -30

But as the cell is found I guess that is a wrong assumption

srsRAN gNB crash after UE trying to establish multiple pdu sessions

Hi,

I am trying to establish multiple pdu sessions from COTS UE to srsRAN gNB. My cots UE (OnePlus Nord & Sierra Wireless 5g modem) work perfect when there is only one pdu session. However, when I try to establish the second PDU session via AT commands, the gNB crashes and throws the error:

terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Does srsRAN support multiple pdu sessions so far?

Thanks
Hai

Failed to connect SCTP socket to 127.0.1.100:38412. error="Connection refused"

Issue Description

unable establish srsrRAN gNB

amf:
addr: 127.0.1.100 # The address or hostname of the AMF.
bind_addr: 127.0.0.1 # A local IP that the gNB binds to for traffic from the AMF.
what is addr of amf here and how can i find it in my local computer

Setup Details

os Ubuntu 22.04 ,usrp B200, latest srsran project 5g and uhd software versions installed

Expected Behavior

Available radio types: uhd.

--== srsRAN gNB (commit 77be7d3) ==--

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.2.0.HEAD-0-g197cdc4f
Making USRP object with args 'type=b200'
Cell pci=1, bw=10 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=632640, ul_freq=3489.42 MHz

==== gNodeB started ===
Type to view trace

Actual Behaviour

Lower PHY in dual executor mode.
Available radio types: uhd.

--== srsRAN gNB (commit 16cd388) ==--

Connecting to AMF on 127.0.1.100:38412
Failed to connect SCTP socket to 127.0.1.100:38412. error="Connection refused" timeout=0ms
srsGNB ERROR: Failed to create SCTP gateway.

Steps to reproduce the problem

sudo gnb -c /home/raju/srsRAN_Project/configs/gnb_rf_b200_tdd_n78_20mhz.ym

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

srsRAN gNB with srsUE failed to assgin UE IP address

Issue Description

I am trying to do the example in 'srsRAN gNB with srsUE' with zeroMQ and open5GS. UE always get stuck at RRC Connected and fail to get an IP address. PS: gNB can get started correctly, but it shows"lower PHY in executor blocking mode", not sure what this is.

Setup Details

ubuntu 22.04LTS,
srsue commit version 'af4b9589b',
srsran gNB commit version '56a771dfe',
open5GS release-17,
libzmp 4.3.4-2

Expected Behavior

UE finishes the RRC connection successfully and get an IP address so that I can do iperf on it

Actual Behaviour

zikun@zikunP1:~/srsRAN_Project/configs$ sudo srsue ./ue_zmq.conf 
[sudo] password for zikun: 
Active RF plugins: libsrsran_rf_zmq.so
Inactive RF plugins: 
Reading configuration file ./ue_zmq.conf...

Built in Release mode using commit af4b9589b on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://127.0.0.1:2001,rx_port=tcp://127.0.0.1:2000,base_srate=11.52e6
Supported RF device list: zmq file
CHx base_srate=11.52e6
Current sample rate is 1.92 MHz with a base rate of 11.52 MHz (x6 decimation)
CH0 rx_port=tcp://127.0.0.1:2000
CH0 tx_port=tcp://127.0.0.1:2001
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Complete.     c-rnti=0x4601, ta=0
RRC Connected
t
Enter t to stop trace.

zikun@zikunP1:~/srsRAN_Project/configs$ sudo gnb -c ./gnb_zmq.yaml 
[sudo] password for zikun: 
Lower PHY in executor blocking mode.

--== srsRAN gNB (commit 56a771dfe) ==--

Connecting to AMF on 127.0.1.100:38412
Available radio types: zmq.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type <t> to view trace

Steps to reproduce the problem

Config files and logs are here

Additional Information

Late, Overflow and underflow error

Hello,
I am trying to run a private network using USRP B210. Our licenced frequency band is 3700-3800 MHz, n78, TDD. I integrated USRP B210 to one pc as gNb and having late, overflow and underflow error. I would like to have suggestion to overcome these errors. My gNb configuration -
amf:
addr: 127.0.0.2 # The address or hostname of the AMF.
bind_addr: 127.0.0.1 # A local IP that the gNB binds to for traffic from the AMF.

rf_driver:
device_driver: uhd # The RF driver name.
device_args: type=b200 # Optionally pass arguments to the selected RF driver.
clock: external # Specify the clock source used by the RF.
sync: # Specify the sync source used by the RF.
srate: 11.52 # RF sample rate might need to be adjusted according to selected bandwidth.
tx_gain: 50 # Transmit gain of the RF might need to adjusted to the given situation.
rx_gain: 60 # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
dl_arfcn: 653332 # ARFCN of the downlink carrier (center frequency).
band: 78 # The NR band.
channel_bandwidth_MHz: 10 # Bandwith in MHz. Number of PRBs will be automatically derived.
common_scs: 30 # Subcarrier spacing in kHz used for data.
plmn: "00101" # PLMN broadcasted by the gNB.
tac: 7 # Tracking area code (needs to match the core configuration).
pci: 1 # Physical cell ID.

log:
filename: /tmp/gnb.log # Path of the log file.
all_level: warning # Logging level applied to all layers.

pcap:
mac_enable: false # Set to true to enable MAC-layer PCAPs.
mac_filename: /tmp/gnb_mac.pcap # Path where the MAC PCAP is stored.
ngap_enable: false # Set to true to enable NGAP PCAPs.
ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.

I am having following output after starting the gNb
--== srsRAN gNB (commit 0523be6) ==--

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.0-47-gd18647dd
Making USRP object with args 'type=b200'
Cell pci=1, bw=10 MHz, dl_arfcn=653332 (n78), dl_freq=3799.98 MHz, dl_ssb_arfcn=653376, ul_freq=3799.98 MHz

==== gNodeB started ===
Type to view trace
Late: 94; Underflow: 452; Overflow: 40;
Late: 116; Underflow: 507; Overflow: 43;
Late: 120; Underflow: 529; Overflow: 43;
Late: 123; Underflow: 550; Overflow: 45

build fails

Issue Description

build fails for commit 0523be6

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
clean build fails, when building tests

Expected Behavior

build should succeed

Actual Behaviour

Scanning dependencies of target du_high_test
[ 54%] Building CXX object tests/unittests/du_high/CMakeFiles/du_high_test.dir/du_high_test.cpp.o
In file included from /home/srs/srsRAN_Project/tests/unittests/du_high/du_high_test.cpp:27:
/home/srs/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h: In constructor 'constexpr srsran::du_high_worker_manager::du_high_worker_manager()':
/home/srs/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h:29:8: error: use of deleted function 'srsran::task_worker::task_worker(srsran::task_worker&&)'
29 | struct du_high_worker_manager {
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/srs/srsRAN_Project/lib/du_high/du_high.h:35,
from /home/srs/srsRAN_Project/tests/unittests/du_high/du_high_test.cpp:23:
/home/srs/srsRAN_Project/include/srsran/support/executors/task_worker.h:55:3: note: declared here
55 | task_worker(task_worker&&) = delete;
| ^~~~~~~~~~~
In file included from /home/srs/srsRAN_Project/tests/unittests/du_high/du_high_test.cpp:27:
/home/srs/srsRAN_Project/tests/unittests/du_high/test_utils/du_high_worker_manager.h:29:8: error: use of deleted function 'srsran::task_worker::task_worker(srsran::task_worker&&)'
29 | struct du_high_worker_manager {
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/srs/srsRAN_Project/lib/du_high/du_high.h:35,
from /home/srs/srsRAN_Project/tests/unittests/du_high/du_high_test.cpp:23:
/home/srs/srsRAN_Project/include/srsran/support/executors/task_worker.h:55:3: note: declared here
55 | task_worker(task_worker&&) = delete;
| ^~~~~~~~~~~
/home/srs/srsRAN_Project/tests/unittests/du_high/du_high_test.cpp: In function 'void test_f1_setup_local()':
/home/srs/srsRAN_Project/tests/unittests/du_high/du_high_test.cpp:42:30: note: synthesized method 'constexpr srsran::du_high_worker_manager::du_high_worker_manager()' first required here
42 | du_high_worker_manager workers;
| ^~~~~~~
make[2]: *** [tests/unittests/du_high/CMakeFiles/du_high_test.dir/build.make:82: tests/unittests/du_high/CMakeFiles/du_high_test.dir/du_high_test.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:9892: tests/unittests/du_high/CMakeFiles/du_high_test.dir/all] Error 2
make: *** [Makefile:160: all] Error 2

srsUE cannot attach with latest commit

Issue Description

[Describe the issue in detail]
With commit 56a771d, srsUE cannot connect to gNB anymore. With previous release_23_5 works properly.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]

• 2 USRP X300
• Wires and attenuators to connect both USRP
• 2 GPP with Debian 11 for gNB and UE sides
• UHD driver version 4.4.0.0

This setup is identical for both releases (56a771d and 49a07c7)

Expected Behavior

[What you expect to happen]
UE should attach to core and get an IP.

Actual Behaviour

[What happens instead e.g. error message]
Multiple PRACH are sent and attachment cannot continue.

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]
1- Start gNB release_23_5 with config gnb_ok.yml from https://gist.github.com/polhenarejos/8687de5f21b9b5537f10e31e61473781
2- Start UE (af4b958) with config ue.conf from https://gist.github.com/polhenarejos/8687de5f21b9b5537f10e31e61473781
3- UE attaches and get ip 10.45.0.7
Log gNB:

phenarejos@castle-jupiter:~/.config/srsran$ sudo gnb -c gnb_ok.yml
Lower PHY in dual executor mode.
Available radio types: uhd.

--== srsRAN gNB (commit 49a07c710) ==--

Connecting to AMF on 10.100.1.1:38412
[INFO] [UHD] linux; GNU C++ version 10.2.1 20210110; Boost_107400; DPDK_20.11; UHD_4.4.0.HEAD-0-g5fac246b
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Making USRP object with args 'addr=10.100.40.2,type=x300,num_recv_frames=64,num_send_frames=64,master_clock_rate=184.32e6,send_frame_size=8000,recv_frame_size=8000'
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type <t> to view trace

Log srsUE:

phenarejos@castle-mars:~/.config/srsran$ sudo srsue ue.conf
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_soapy.so libsrsran_rf_blade.so libsrsran_rf_zmq.so
Inactive RF plugins:
Reading configuration file ue.conf...

Built in Release mode using commit af4b9589b on branch master.

Opening 1 channels in RF device=default with args=sync=external,clock=external,addr=10.100.30.2,num_recv_frames=64,num_send_frames=64
Supported RF device list: UHD soapy bladeRF zmq file
Trying to open RF device 'UHD'
[INFO] [UHD] linux; GNU C++ version 10.2.1 20210110; Boost_107400; DPDK_20.11; UHD_4.4.0.HEAD-0-g5fac246b
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Opening USRP channels=1, args: sync=external,addr=10.100.30.2,num_recv_frames=64,num_send_frames=64,type=x300,master_clock_rate=184.32e6
[INFO] [UHD RF] RF UHD Generic instance constructed
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
RF device 'UHD' successfully opened
Setting manual TX/RX offset to 300 samples
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=6894
Random Access Complete.     c-rnti=0x4601, ta=0
RRC Connected
PDU Session Establishment successful. IP: 10.45.0.7
RRC NR reconfiguration successful.

Next trial with latest commit:
1- Start gNB (56a771d) with config gnb_nok.yml from https://gist.github.com/polhenarejos/8687de5f21b9b5537f10e31e61473781
2- Start UE (af4b958) with config ue.conf from https://gist.github.com/polhenarejos/8687de5f21b9b5537f10e31e61473781
3- UE sends multiple PRACH and does not attach anymore

Log gNB:

phenarejos@castle-jupiter:~/.config/srsran$ sudo gnb -c gnb_nok.yml
Lower PHY in dual executor mode.

--== srsRAN gNB (commit 56a771dfe) ==--

Connecting to AMF on 10.100.1.1:38412
Available radio types: uhd.
[INFO] [UHD] linux; GNU C++ version 10.2.1 20210110; Boost_107400; DPDK_20.11; UHD_4.4.0.HEAD-0-g5fac246b
Making USRP object with args 'addr=10.100.40.2,type=x300,num_recv_frames=64,num_send_frames=64,master_clock_rate=184.32e6,send_frame_size=8000,recv_frame_size=8000'
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type <t> to view trace

Log srsUE:

phenarejos@castle-mars:~/.config/srsran$ sudo srsue ue.conf
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_soapy.so libsrsran_rf_blade.so libsrsran_rf_zmq.so
Inactive RF plugins:
Reading configuration file ue.conf...

Built in Release mode using commit af4b9589b on branch master.

Opening 1 channels in RF device=default with args=sync=external,clock=external,addr=10.100.30.2,num_recv_frames=64,num_send_frames=64
Supported RF device list: UHD soapy bladeRF zmq file
Trying to open RF device 'UHD'
[INFO] [UHD] linux; GNU C++ version 10.2.1 20210110; Boost_107400; DPDK_20.11; UHD_4.4.0.HEAD-0-g5fac246b
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Opening USRP channels=1, args: sync=external,addr=10.100.30.2,num_recv_frames=64,num_send_frames=64,type=x300,master_clock_rate=184.32e6
[INFO] [UHD RF] RF UHD Generic instance constructed
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
RF device 'UHD' successfully opened
Setting manual TX/RX offset to 300 samples
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=8334
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=8494
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=8654
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=8814
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=8974
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=9134
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=9294
^CStopping ..
---  exiting  ---

I enabled debug log for phy_level at gNB side. Logs can be found at https://gist.github.com/polhenarejos/8687de5f21b9b5537f10e31e61473781 (gnb_ok.log and gnb_nok,log)

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]
Things I observed:

• Lots of crc=NOK in gnb_nok.log for PUSCH. So, since first PUSCH sent after PRACH-PDSCH sequence fails, it cannot continue with attachment. I do not why it fails with latest commit, whilst it works with release_23_5.
• Starting sequence at gNB for USRP changed. I am not sure if something is different there (missing setting RX gain or similar)
• gnb_nok.log starts with 2023-06-14T10:58:53.007650 [FAPI ] [W] [ 0.0] Real-time failure in FAPI: Received late DL_TTI.request. Current slot is 192.7 while message corresponds to 192.6, which does not happen with release_23_5 (see gnb_ok.log). Perhaps this desynchronization is related with crc decoding.
• Debian 11 / gcc 10.2.1

LimeSDR and bladeRF support

There's any plane to extend the support to LimeSDR and bladeRF?

USRP X410 Configs

USRP X410 Configs

Hi there,
I have been trying to work with the new srsRAN-project with our USRP devices. We have USRP B210, and X410. We have successfully run the gNB using the default configurations with B210, but encountered underflow errors when running the gNB with the X410 (the UE is able to attach to the network, but the connection is unstable). I believe that there should be specific configuration files for the X410 that could potentially resolve these errors.

Setup Details

Core Platform: Open5GS
RF device: USRP X410
UHD version: 4.4.0
Os: Ubuntu 20.04.5 LTS
(CPU scaling governor is set to maximum performance)

Actual Behaviour

--== srsRAN gNB (commit 77be7d3) ==--

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.0-0ubuntu1~focal1
Making USRP object with args 'type=x4xx'
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 25000000 bytes.
Actual sock buff size: 1048576 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=25000000
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 25000000 bytes.
Actual sock buff size: 1048576 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=25000000
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 25000000 bytes.
Actual sock buff size: 1048576 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=25000000
Cell pci=1, bw=20 MHz, dl_arfcn=368640 (n3), dl_freq=1843.2 MHz, dl_ssb_arfcn=368670, ul_freq=1748.2 MHz

==== gNodeB started ===
Type to view trace
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;
Late: 0; Underflow: 1; Overflow: 0;

Steps to reproduce the problem

The gNB logs and configs are attached.

gnb_rf_X410.txt

gnb.log

Thank you!

COTS UE Cannot find the network

Using the default configuration file, the network can be found in srsRAN_4G, but not in srsRAN_Project. The log is as follows.
gnb.log
pcap.zip

AMF-UE-NGAP-ID mismatch between the authentication request and response messages

Issue Description

An issue previously discovered in the srsRAN 4G 21.10 (previous discussion here) has been encountered again. The srsGNB appears to be truncating the AMF-UE-NGAP ID in the Authentication Response. This results in the AMF responding with an ErrorIndication message containing the error: radioNetwork: unknown-local-UE-NGAP-ID. (14)

Setup Details

srsRAN gNB used with USRP B210 and UHD 4.1.
OS: Ubuntu 22.04
COTS UE

Expected Behavior

srsRAN should return the correct id-AMF-UE-NGAP-ID assigned by the AMF/5GC in the authentication response message.

Actual Behaviour

srsRAN returns an incorrect id-AMF-UE-NGAP-ID in the authentication response message to the 5GC causing the authentication handshake to produce an error: unknown-local-UE-NGAP-ID (pcap below)

1. Registration request is sent from the UE to the AMF/5GC.
2. AMF/5GC responds with a DownlinkNASTransport, Authentication request which contains the AMF-UE-NGAP-ID.
3. srsRAN responds to AMF/5GC with a UplinkNASTransport, Authentication response containing the wrong AMF-UE-NGAP-ID.
4. AMF/5GC responds with ErrorIndication message with the error radioNetwork: unknown-local-UE-NGAP-ID (14).

Steps to reproduce the problem

1. Send Registration request from UE.
2. Verify that the AMF-UE-NGAP-ID is consistent between the authentication request and response messages.

Additional Information

Here are some partial logs for this issue:

Authentication Request

NG Application Protocol (DownlinkNASTransport)
	NGAP-PDU: initiatingMessage (0)
		initiatingMessage
			procedureCode: id-DownlinkNASTransport (4)
			criticality: ignore (1)
			value
				DownlinkNASTransport
					protocolIEs: 3 items
						Item 0: id-AMF-UE-NGAP-ID
							ProtocolIE-Field
								id: id-AMF-UE-NGAP-ID (10)
								criticality: reject (0)
								value
									AMF-UE-NGAP-ID: 4294969659

Authentication Response

NG Application Protocol (UplinkNASTransport)
	NGAP-PDU: initiatingMessage (0)
		initiatingMessage
			procedureCode: id-UplinkNASTransport (46)
			criticality: ignore (1)
				value
					UplinkNASTransport
						protocolIEs: 4 items
							Item 0: id-AMF-UE-NGAP-ID
								ProtocolIE-Field
									id: id-AMF-UE-NGAP-ID (10)
									criticality: reject (0)
									value
AMF-UE-NGAP-ID: 2364

Error Indication

NG Application Protocol (ErrorIndication)
	NGAP-PDU: initiatingMessage (0)
		initiatingMessage
			procedureCode: id-ErrorIndication (9)
			criticality: ignore (1)
			value
				ErrorIndication
					protocolIEs: 3 items
						Item 0: id-AMF-UE-NGAP-ID
							ProtocolIE-Field
								id: id-AMF-UE-NGAP-ID (10)
								criticality: ignore (1)
								value
									AMF-UE-NGAP-ID: 2364
						Item 1: id-RAN-UE-NGAP-ID
							ProtocolIE-Field
								id: id-RAN-UE-NGAP-ID (85)
								criticality: ignore (1)
								value
									RAN-UE-NGAP-ID: 0
						Item 2: id-Cause
							ProtocolIE-Field
								id: id-Cause (15)
								criticality: ignore (1)
								value
								        Cause: radioNetwork (0)
                                                                                radioNetwork: unknown-local-UE-NGAP-ID (14)

srsRAN gNB changes the AMF-UE-NGAP-ID from 4294969659 in the authentication request to 2364 in the authentication response.

When 5G is used as gnb and 4G is used as ue, the two cannot be connected. Is an external clock necessary? If no external clock is needed, how to modify the configuration file? Look forward to your reply. Thank you

Issue Description

[Describe the issue in detail]

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably]
e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

Expected Behavior

[What you expect to happen]

Actual Behaviour

[What happens instead e.g. error message]

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

UE doesn't reconnect correctly

Issue Description

When my UE is connected to the network and data DL and UL transmission is working fine, if I disconnect from the network ( I go out of coverage, turn off data or turn into airplane mode), when the device is connected after, the data transmission is not working, ialthough the RCC log seems to have worked and the UE shows me to be connected to the network.

Setup Details

USRP mini b200, Xiaomi Note 10 5G and Open5gs as 5G Core. Using band n77.

Expected Behavior

When the UE connects again, the data transmission starts working again.

Actual Behaviour

Data transmission doesnt work during second connection, I have to restart the UE to have it working again.

BladeRF Support

Issue Description

After start researching on prototyping with bladeRF and srsRAN I came across to the new srsRAN_Project.
I decided to try it but after building it, it does not recognize my bladeRF (I have xA9 and xA5).

Is there support for bladeRF 2.0?

When I use the gnb, the following output is shown:

sudo ./gnb -c ../../../configs/gnb_rf_b200_tdd_n78_10mhz.yml 
Available radio types: .

--== srsRAN gNB (commit 77be7d339) ==--

Factory for radio type soapy not found. Make sure to select a valid type.
srsGNB ERROR: Unable to create radio session.

As we can see, the available radio types is none. Of course I tried with soapy, and bladeRF to check if it inherited it.
I have in the same server (Ubuntu 22.10) the srsRAN project compiled by the sources and bladeRF and SoapySDR are recognized as available drivers.

srsUE with srsRAn_Project: nrof_harq_processes_for_pdsch not present

Issue Description

Configured srsUE and srsRAN_project gNB as per the srsRAN gNB with srsUE document. UE logs show nrof_harq_processes_for_pd not present and UE fails to initiate connect setup procedure.

UE console shows RRC connected:
Opening 1 channels in RF device=uhd with args=type=x300,serial=323DF3B,clock=external,sampling_rate=23.04e6,lo_freq_offset_hz=23.04e6,None
Supported RF device list: UHD zmq file
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Opening USRP channels=1, args: type=x300,serial=323DF3B,lo_freq_offset_hz=23.04e6,None=,master_clock_rate=184.32e6
[INFO] [UHD RF] RF UHD Generic instance constructed
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
[INFO] [GPS] No GPSDO found
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1291 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1308 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=5614
Random Access Complete. c-rnti=0x4601, ta=9
RRC Connected
t

srsUE log:
2023-04-27T15:07:55.182359 [UE ] [I] Using binary ./srsue with arguments: ue.conf
2023-04-27T15:07:55.213222 [UE ] [I] Built in Release mode using commit 00c972ac4 on branch master.
2023-04-27T15:07:58.637573 [ASN1 ] [W] [ 0] Option nrof_harq_processes_for_pdsch not present
2023-04-27T15:07:58.637573 [RRC-NR ] [W] Failed to make dl_harq_cfg_nr config
2023-04-27T15:07:58.637573 [RRC-NR ] [E] Failed to initiate connection setup procedure
nrof_harq_processes_for_pd

gNB console output and logs:
Connecting to AMF on 127.0.0.5:38412
Making USRP object with args type=x300,addr=192.168.40.2,master_clock_rate=184.32e6,send_frame_size=8000,recv_frame_size=8000'
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
[INFO] [LOGGING] Fastpath logging disabled at runtime.
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type to view trace
t

       -------------DL----------------|------------------UL--------------------

pci rnti cqi mcs brate ok nok (%) | pusch mcs brate ok nok (%) bsr
1 4601 n/a 1 6.8k 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | -21.0 5 20k 0 5 0% 0.0
1 4601 n/a 0 0 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | -20.4 5 20k 0 5 0% 0.0
1 4601 n/a 0 0 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | -21.2 5 20k 0 5 0% 0.0
1 4601 n/a 0 0 0 0 0% | n/a 0 0 0 0 0% 0.0
1 4601 n/a 0 0 0 0 0% | -22.7 5 41k 0 10 0% 0.0

Setup Details

Intel NUC-1: Open5GS and srsRAN_Project gNB using x310
Intel NUC-2: srsRAN_4G (srsUE)

Expected Behavior

The srsUE should attach to the network.

Actual Behaviour

With same srsRAN_project gNB and Open5GS core, COTS UE is able to do the attach and proceed upto PDU session response.

Steps to reproduce the problem

srsUE and srsRAN_project gNB as per the srsRAN gNB with srsUE document.

Additional Information

external clock is connected to UE but not gNB. ( However same gNB attach woroks fine with COTS UE)