gnb -c with USRPB210 on ubuntu22.04

[flaunay86]

Dear all

I am trying to test gnb on my VM (Virtualbox). I have a detected usrp

-- UHD Device 0

Device Address:
serial: 312900F
name: MyB210
product: B210
type: b200

and uhd_usrp_probe give me full details.

Nevertheless, when I want to run gnb -c gnb_rf_b200_tdd_n78_20mhz.yml the default config files I have the following error

ERROR =>

Number of UL threads (i.e., 1) must be in range [1..1).
srsGNB ERROR: Invalid configuration detected.

Could you help me?

Thanks

[ismagom]

Thanks for reporting. This is actually a bug. It will be fixed in the following days.

[flaunay86]

Ok thank's.

[joaquim-srs]

Hi @flaunay86, thank you for reporting this issue. We have pushed a fix to the repository. Can you pull the changes and test if the issue has been solved for you?

[flaunay86]

Dear Joaquim I upload srsRAN_project and I have the following message : Lower PHY in dual executor mode. /home/etudiant/srsRAN_Project/include/srsran/adt/bounded_bitset.h:1062: void srsran::bounded_bitset<N, LowestInfoBitIsMSB>::assert_within_bounds_(size_t, bool) const [with long unsigned int N = 1024; bool LowestInfoBitIsMSB = false; size_t = long unsigned int]: Assertion `pos < size() or (not strict and pos == size())' failed - ERROR: index='1' is out-of-bounds for bitset of size='1'. Abandon Best regard De: "Joaquim Broquetas" ***@***.***> À: "srsran/srsRAN_Project" ***@***.***> Cc: "Frederic Launay" ***@***.***>, "Mention" ***@***.***> Envoyé: Lundi 3 Juillet 2023 15:11:44 Objet: Re: [srsran/srsRAN_Project] gnb -c with USRPB210 on ubuntu22.04 (Discussion #107) Hi [ https://github.com/flaunay86 | @flaunay86 ] , thank you for reporting this issue. We have pushed a fix to the repository. Can you pull the changes and test if the issue has been solved for you? — Reply to this email directly, [ #107 (reply in thread) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AXTR7YDYXX3K44252VAKMQTXOLAJBANCNFSM6AAAAAAZZS3YX4 | unsubscribe ] . You are receiving this because you were mentioned. Message ID: ***@***.***>

[joaquim-srs]

Hi,

I have been able to reproduce the issue, it appears when the number of available CPU threads is less than 4. A fix for this issue will be included in the next release, which is due in a couple of weeks. In the meantime, can you try increasing the number of virtual CPU cores to at least 4? Let me know if this solves the issue for now.

[flaunay86]

On the previous version (I have not tested with the last version), increasing the CPU number at 4 fix the pb. Thank you Frédéric De: "Joaquim Broquetas" ***@***.***> À: "srsran" ***@***.***> Cc: "Frederic Launay" ***@***.***>, "Mention" ***@***.***> Envoyé: Mardi 4 Juillet 2023 11:19:26 Objet: Re: [srsran/srsRAN_Project] gnb -c with USRPB210 on ubuntu22.04 (Discussion #107) Hi, I have been able to reproduce the issue, it appears when the number of available CPU threads is less than 4. A fix for this issue will be included in the next release, which is due in a couple of weeks. In the meantime, can you try increasing the number of virtual CPU cores to at least 4? Let me know if this solves the issue for now. — Reply to this email directly, [ #107 (reply in thread) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AXTR7YGVNOIOT7QO7D4FGDTXOPNZ5ANCNFSM6AAAAAAZZS3YX4 | unsubscribe ] . You are receiving this because you were mentioned. Message ID: ***@***.***>

[flaunay86]

Dear Joaquim when I tested srsRAN_Project with 4 virtuals CPU, I was able to execute gNB -c file.yaml nevertheless, I tested it with Open5GS (modifying amf address in gNB config) but I have a SCTP connection refused. When I test with a simulated RAN (UERANSIM) and Open5GS there is no error. I will look forward, I may be wrong in my test (may be I forgot on step, if you have any documentation don't hesitate to send it to me). Best Regard. Frédéric De: "Joaquim Broquetas" ***@***.***> À: "srsran" ***@***.***> Cc: "Frederic Launay" ***@***.***>, "Mention" ***@***.***> Envoyé: Mardi 4 Juillet 2023 11:19:26 Objet: Re: [srsran/srsRAN_Project] gnb -c with USRPB210 on ubuntu22.04 (Discussion #107) Hi, I have been able to reproduce the issue, it appears when the number of available CPU threads is less than 4. A fix for this issue will be included in the next release, which is due in a couple of weeks. In the meantime, can you try increasing the number of virtual CPU cores to at least 4? Let me know if this solves the issue for now. — Reply to this email directly, [ #107 (reply in thread) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AXTR7YGVNOIOT7QO7D4FGDTXOPNZ5ANCNFSM6AAAAAAZZS3YX4 | unsubscribe ] . You are receiving this because you were mentioned. Message ID: ***@***.***>

[joaquim-srs]

Hi,

You can check our COTS UE application note for a step by step guide that includes how to use the srsRAN Project gNodeB with Open5GS. A first step towards finding the issue would be to check if all the relevant configuration parameters match in the gNB config and the Open5GS config, namely, the IP addresses, PLMN codes (MCC and MNC), and Tracking Area Code (TAC). If tou did not configure the TAC on the Open5GS, I suggest you take a look at it first, since we use a TAC of 7 by default, while Open5GS uses a different default value if I remember correctly.

If this does not help, share your gNB and Open5GS configs and I will take a look.

[s5uishida]

Hi @flaunay86 and community,

In my environment, SCTP connection failed when starting srsRAN_Project gNodeB with ZeroMQ on Virtualbox VM.
Open5GS log is as follows.

08/12 08:23:33.757: [amf] INFO: gNB-N2 accepted[192.168.0.121]:59953 in ng-path module (../src/amf/ngap-sctp.c:113)
08/12 08:23:33.757: [amf] INFO: gNB-N2 accepted[192.168.0.121] in master_sm module (../src/amf/amf-sm.c:741)
08/12 08:23:33.757: [amf] INFO: [Added] Number of gNBs is now 1 (../src/amf/context.c:1178)
08/12 08:23:33.757: [amf] INFO: gNB-N2[192.168.0.121] max_num_of_ostreams : 30 (../src/amf/amf-sm.c:780)
08/12 08:23:35.841: [amf] INFO: gNB-N2[192.168.0.121] connection refused!!! (../src/amf/amf-sm.c:793)
08/12 08:23:35.841: [amf] INFO: [Removed] Number of gNBs is now 0 (../src/amf/context.c:1205)

gnb_zmq.yaml is set as follows.

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

At this time, the status of the SCTP connection on the gNodeB VM changed as follows.

# ss -a -S
State      Recv-Q   Send-Q        Local Address:Port         Peer Address:Port    Process
UNCONN     0        0             192.168.0.121:57527       192.168.0.111:38412
`- ESTAB   0        0          10.0.2.15%enp0s8:57527       192.168.0.111:38412
                               ~~~~~~~~~~~~~~~~~~~~~~

The local address at connecting for a moment is strange.
After that, it immediately changed as follows.

# ss -a -S
State    Recv-Q    Send-Q        Local Address:Port         Peer Address:Port    Process

The status of each network interface is as follows.

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:51:0e:2c brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86237sec preferred_lft 86237sec
    inet6 fe80::a00:27ff:fe51:e2c/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:89:81:b8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.121/24 brd 192.168.0.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe89:81b8/64 scope link 
       valid_lft forever preferred_lft forever

# ip route
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100 
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100 
10.0.2.3 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100 
192.168.0.0/24 dev enp0s8 proto kernel scope link src 192.168.0.121 

In my environment, each network interface is as follows.

• enp0s3 - Default NAT set by Virtualbox (not used)
• enp0s8 - Bridge adapter added to my environment (using)

Therefore, when I down enp0s3 and tried again, SCTP connection succeeded.

# ip link set enp0s3 down

# ss -a -S
State      Recv-Q   Send-Q            Local Address:Port       Peer Address:Port   Process
UNCONN     0        0                 192.168.0.121:34495     192.168.0.111:38412
`- ESTAB   0        0          192.168.0.121%enp0s8:34495     192.168.0.111:38412
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~

FYI.

[pgawlowicz]

See here: #172