OnePlus Nord 5G cannot attach

[alejandroBlancoPizarro]

Issue Description

[Describe the issue in detail] Hi srsRAN community.

I have been following the tutorial "srsRAN gNB with COTS UEs". As a COST UE, I am using a OnePluss Nord5G which is one of the already tested UE.

I observed that the UE is able to detect the RAN but it cannot attach. I check the gnb logs and I could not see anything about random access, I suppose that the UE did not start the random access.

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

• Machine: Intel(R) Core(TM) i5-10500 CPU @ 3.10GHz
• srsRAN Project commit 583c92b16
• B210 USRP
• Open5GS 5G Core
• OnePlus Nord 5G
• Leo Bodnar GPS Reference Clock

Expected Behavior

[What you expect to happen] I expect the UE to do the random access

Actual Behaviour

[What happens instead e.g. error message] The UE does not do random access, it does not attach

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files] I just follow the tutorial

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue] I check the SIM information with the srsUE and it does attach, so the core is correctly setup.

Here are the logs gnb.log

And here are the pcap and the config file in the zip

gnb_pcap_config.zip

Any idea about why the UE does not attach?

Many thanks in advance and let me know if you need something more.

Best, Alejandro

[andrepuschmann]

What SIM do you use? Have you tried 00101? Maybe the phone sees the network but doesn't attempt to attach, it's possible.

[alejandroBlancoPizarro]

Hi Andre,

It is SysmoISIM-SJA2. I will reprogram it to have 00101, although it might not affect it, right?

I will let you know.

[robertfalkenberg]

It is SysmoISIM-SJA2. I will reprogram it to have 00101, although it might not affect it, right?

Yes, SysmoISIM-SJA2 should be fine. Please re-program the IMSI to start with 00101... instead of 99970... (or the olders 90170...). In addition, for the OnePlus Nord 5G, use a network PLMN different than the Test Network 00101, such that the device is roaming. E.g. we have been successful with:

uSIM IMSI: "00101..."
5GS+gNB PLMN: "90170"

[alejandroBlancoPizarro]

Hi Robert,

Thanks! I will try it and let you know.

Best, Alejandro

[alejandroBlancoPizarro]

Hi all,

The UE finally attaches, many thanks for your guidelines.

However, after attaching, the UE does not have any IP and I observed weird behavior on the gnb and core side. In particular, I observed that there are several prach detections looking at the gnb logs. This can be easily seen on the trace of the gnb.

On the core side, I observed several Initial UE messages on the AMF logs.

Do you know why the UE is constantly doing random access? The roaming is activated and VoLTE is off.

I am attaching the gnb logs as well as the pcap files gnb.zip

Just last one thing. I had some issues for disabling UST services 124 and 125 as the current Osmocom version does not support it. You need to apply this patch: https://gerrit.osmocom.org/c/pysim/+/33985

Please let me know. Alejandro

[ralfkundel]

Hi Alejandro, I have exactly the same pcap behavior as you have but with the following setup:

• machine: i9-9900k
• srsRAN based on U200 (commit: e043e1e)
• free5gc core (3.3.0)
• 3 non working UEs: Asus Zenfone 8 OR Robustel Modem OR Waveshare SIM 8200 (all Qualcomm based)

looking in your (or my) gnb_mac.pcap, I observe that the PDU session establishment accept is sent many times. Further, in the log files it seems like the rrc reconfiguration will be never successful.

My feeling is: this mac message cannot be sent successfully to the UE and after a timeout everything starts again from beginning.

I attached my pcaps here, however, nothing special new in there: gnbTraces_AsusZenfone.zip

exactly the same setup with an Huawei UE (P40) is working. Replacing the srsRAN with another RAN, it is working with the Asus Zenfone.

best, Ralf

[alejandroBlancoPizarro]

Hi Ralf, I am using --== srsRAN gNB (commit e043e1e40) ==--

I double check everything and it seems that the APN name in both sides (UE and core) are the same. Anything else that I need to check? Roaming is enabled and VoLTE is disabled. I also restarted the amf and the upd services

From your side Ralf, does the Huawei UE (P40) work fine?

Best, Alejandro

[ralfkundel]

Hi, the pcap says it is not an VoLTE/ims problem. it's more on the radio layer a wrong parameter and by that the comparable large DL message does not arrive successfully at the UE (just a guess)

P40: with free5gc and srsRAN it is working (after 3 minutes it is connecting without ims). with open5gs it is disconnecting (as described here: https://github.com/srsran/srsRAN_Project/discussions/73) as the huawei thinks there might be an ims.

[andrepuschmann]

Hey guys,

in the logs @alejandroBlancoPizarro shared it looks like the UE doesn't like the RRC Reconfiguration. It could be a regression. Could you confirm the precise model you use? The OnePlus Nord 5G is listed in https://docs.srsran.com/projects/project/en/latest/knowledge_base/source/cots_ues/source/index.html so it has worked at some stage. Maybe try with an the 23.5 version as well just to be sure.

@ralfkundel I agree your NGAP PCAPs show similar behaviour. Could you also test with 23.5 perhaps and see if that works better?

Meanwhile we also try to test again with the basebands that you guys use (X55 and Snapdragon 888).

Thanks Andre

[alejandroBlancoPizarro]

Hi Andre,

Concerning the phone. It is the OnePlus Nord 5G with Snapdragon 765G and the model is AC2003. I am confused, I think I have the lasted version of srsRAN project which corresponds to the 23.5 version, right?

[andrepuschmann]

Hey @alejandroBlancoPizarro,

23.5 is the latest officially tagged "release". However, we've done multiple pushes to the main branch in the meantime without doing an "officially" tagged release.

In any case we will reproduce the issue locally and report back then.

[alejandroBlancoPizarro]

Hi Andre,

I got the point. I will try to use old commits within the 23.5 version and let you know.

Thanks for reproducing this issue locally :)

Best, Alejandro

[andrepuschmann]

Hey @alejandroBlancoPizarro, @ralfkundel ,

could you guys perhaps try the following quick fix based on the latest code in main?

diff --git a/lib/cu_cp/cell_meas_manager/cell_meas_manager_impl.cpp b/lib/cu_cp/cell_meas_manager/cell_meas_manager_impl.cpp
index 06d4c2793..9f6355c89 100644
--- a/lib/cu_cp/cell_meas_manager/cell_meas_manager_impl.cpp
+++ b/lib/cu_cp/cell_meas_manager/cell_meas_manager_impl.cpp
@@ -33,6 +33,10 @@ optional<rrc_meas_cfg> cell_meas_manager_impl::get_measurement_config(nr_cell_id
   }
   const auto& cell_config = cfg.cells.at(serving_nci);

+  if (cell_config.ncells.empty()) {
+    return meas_cfg;
+  }
+
   // Create fresh config.
   meas_cfg.emplace();

Thanks Andre

[alejandroBlancoPizarro]

Hi @andrepuschmann

Incredible! It is working like a charm

35Mbps and 17.5Mbps for downlink and uplink

Many thanks!

[ralfkundel]

Hi, I can confirm the fix. We have around 60 Mbit/s downstream and 30 Mbit/s upstream with 40MHz bandwidth with two different tested UEs (one not working before).

many thanks!

[alejandroBlancoPizarro]

Hi @andrepuschmann and @ralfkundel,

Before closing the issue, what are the changes to enable 40MHz? In the configuration file.

Best, Alejandro

[andrepuschmann]

Hey guys, glad that it's now working well for you. The regression was introduced recently and will be fixed in main with the next update - likely happening tomorrow or early next week.

Quick test with 40 MHz TDD using the default config with following change:

diff --git a/configs/gnb_rf_b200_tdd_n78_20mhz.yml b/configs/gnb_rf_b200_tdd_n78_20mhz.yml
index 097d2db1d..e1ff2d3b7 100644
--- a/configs/gnb_rf_b200_tdd_n78_20mhz.yml
+++ b/configs/gnb_rf_b200_tdd_n78_20mhz.yml
@@ -10,15 +10,15 @@ amf:
 ru_sdr:
   device_driver: uhd                                              # The RF driver name.
   device_args: type=b200,num_recv_frames=64,num_send_frames=64    # Optionally pass arguments to the selected RF driver.
-  srate: 23.04                                                    # RF sample rate might need to be adjusted according to selected bandwidth.
+  srate: 46.08                                                    # RF sample rate might need to be adjusted according to selected bandwidth.
   otw_format: sc12
-  tx_gain: 50                                                     # Transmit gain of the RF might need to adjusted to the given situation.
+  tx_gain: 80                                                     # 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.
+  channel_bandwidth_MHz: 40                                       # 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).

Should give you around 90 Mbit/s DL when all is perfect. With QAM256 it's above 100Mbit.

$ ./apps/gnb/gnb -c ../configs/gnb_rf_b200_tdd_n78_20mhz.yml -c ../configs/qam256.yml

--== srsRAN gNB (commit c46230a5c) ==--

Connecting to AMF on 10.53.1.2:38412
Available radio types: uhd and zmq.
Warning: Scheduling priority of UHD not changed. Cause: Not enough privileges.
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; UHD_4.4.0.0-0-g5fac246b
Making USRP object with args 'type=b200,num_recv_frames=64,num_send_frames=64'
Cell pci=1, bw=40 MHz, dl_arfcn=632628 (n78), dl_freq=3489.42 MHz, dl_ssb_arfcn=631968, ul_freq=3489.42 MHz

==== gNodeB started ===
Type <t> to view trace
           -----------------DL----------------|------------------UL--------------------
 pci rnti  cqi  ri  mcs  brate   ok  nok  (%) | pusch  mcs  brate   ok  nok  (%)    bsr
   1 4602   15   1   18    11k   13    0   0% |  23.6   26    35k    8    0   0%    0.0
   1 4603   15   1   18    15k   14    0   0% |  23.1   26    30k    7    5  41%    0.0
   1 4603   15   1   27    34M  380    1   0% |  24.6   28   176k   13    9  40%    0.0
   1 4601   15   1   27   102M 1001    1   0% |  19.3   25    46k   25    1   3%    0.0
   1 4601   15   1   27   123M 1200    0   0% |  18.0   24   139k  151    0   0%    0.0
   1 4601   15   1   27   123M 1198    2   0% |  18.1   24    20k   27    0   0%    0.0
   1 4601   15   1   27   123M 1200    0   0% |  18.2   24   118k  164    1   0%    0.0
   1 4601   15   1   27   123M 1199    0   0% |  23.6   27    29k    8    0   0%    0.0

From the core I was pushing UDP in the DL with iperf -c 10.45.1.2 -u -b 200M

Hope that works for you too.

[alejandroBlancoPizarro]

That works!

55Mbps and 30Mbps for DL and UL

Many thanks!

[FabianEckermann]

This should be fixed in main now.