Replies: 10 comments 6 replies
-
|
Hi @rgeeva, |
Beta Was this translation helpful? Give feedback.
-
|
@SebastianCa Thanks for your help! Here you go... |
Beta Was this translation helpful? Give feedback.
-
|
Do you use the default config? Can you run the same config in rfsim mode? There seems to be an issue with the AMF connection; this shouldn't cause the issue; did you start the Core network? |
Beta Was this translation helpful? Give feedback.
-
|
As far as I understand, I'm using the default config. I can certainly try the rfsim mode but as you can see from the screen cap, the AMF seems to be coming up fine. Is there something I can check from an AMF connectivity? |
Beta Was this translation helpful? Give feedback.
-
|
You can check the amf logs via Do you use a cabled setup? |
Beta Was this translation helpful? Give feedback.
-
|
I'm using a setup with physical antenna on both the USRP and Quectel module in a RF shielded box. As for the AMF logs, here they are... Analysis of the AMF Logs: The AMF starts up, loads its configuration from config.yaml. The AMF successfully establishes an SCTP association with a gNB at 192.168.71.140. The most striking observation is the UEs' Information table, which consistently shows no registered UEs (Index | - | - | - | - | - | - | -). |
Beta Was this translation helpful? Give feedback.
-
|
I agree; the AMF log looks fine. I would suggest to test the rfsim mode next. |
Beta Was this translation helpful? Give feedback.
-
|
@SebastianCa Tried the RFSim mode and get similar results. Critical errors exist between them both..... [LOADER] library libtelnetsrv_gnb.so is not loaded: This is the most critical issue. This library is essential for the gNB to properly interface with the RF hardware or manage network functions. Even though the gNB appears to proceed through RACH, RRC, and initial NGAP steps, the absence of this library likely prevents the final, successful registration acceptance or full operational capability required by the network. The system might be able to perform some basic connection steps without it, but it's a fundamental dependency failure. Any suggestions? I'm a little confused as to why I'm seeing this as I've gone through the outlined setup procedures on the Sionna github quickstart instructions. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @rgeeva, |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.



Uh oh!
There was an error while loading. Please reload this page.
-
Hello community. Looking to get some advice from more experienced users. Trying to establish my first call with my DGX Spark/B210 USRP/Quectel Module and having some issues. The core of the problem, as seen in the logs (Received a MAC CE for C-RNTI with [Y] while processing a TC-RNTI for a new RA attempt), is that the gNB's MAC layer is receiving a MAC Control Element (CE) containing a C-RNTI that belongs to an already established UE context, but it's attempting to process this CE during an RA procedure for a new UE (identified by its TC-RNTI). This suggests a severe logic error in how the MAC layer manages its UE contexts and handles incoming MAC CEs.
Has anyone seen this before? I believe I'm using OAI version is 2025.w34
Beta Was this translation helpful? Give feedback.
All reactions