[srsran-users] help with UE join problem - srsRAN_4G
Johann T.
johann.tzt at gmail.com
Mon Jul 1 12:39:15 UTC 2024
Hi Rob,
The RSRP value of -117 dBm is indeed on the low side. Though most mobile
phones should still be able to connect at that level. Maybe you can try to
adjust your attenuator to get an RSRP value in the range of -80 dBm to -90
dBm. Also make sure you don't attenuate too much on the uplink (receive)
end.
Your spectrum is not necessarily bad. With 10 MHz bandwidth, you have 50
RBs and not all RBs need to be used (depending on the traffic load).
I only use B210 and B200/205 mini for eNB with srsRAN. They work fine.
Never played with LimeSDR.
Johann
On Fri, Jun 28, 2024 at 10:57 PM Rob Newberry <robthedude at mac.com> wrote:
> Hi -- sorry for the delay in replying. I've been pursuing a debug path
> with Quectel, as well as getting a spectrum analyzer and trying to see if I
> can understand the transmit power for the two transmitters in this system.
>
> So first -- I DID have pcap running when I took the logs below. On the
> eNB side, I see:
>
> - eNB receives RACH from UE
> - eNB sends DL-SCH/RAR
> - eNB receives rrcConnectionRequest
> - eNB sends rrcConnectionSetup
>
> And then nothing until timeout and the process repeats.
>
> Now, as I mentioned, I was also debugging with Quectel. In the logs of
> the UE, we see this:
>
> - UE sends RACH
> - UE receives DL-SCH/RAR
> - UE sends rrcConnectionRequest
> - UE receives rrcConnectionSetup
> - UE sends rrcConnectionComplete
>
> And then it times out waiting for the next thing to happen -- but as we
> can see from above, the eNB never gets the rrcConnectionComplete packet, so
> it's never going to proceed.
>
> The other thing that Quectel noticed was that their modem was indicating
> the signal quality was pretty low -- the RSRP being reported as -117. I
> don't actually know what these numbers mean, but the web seems to indicate
> this is pretty bad.
>
> So for the last week or so, I've been playing with a tinySA ULTRA to see
> if I could measure transmit power (as mentioned in my previous email, I've
> struggled with the appropriate amount of attenuation -- partly because I
> don't understand this stuff, but also because I had no way to know where
> things were).
>
> So I did two tests:
>
> 1) I performed a "continuous transmit" test of the Quectel modem, and used
> the spectrum analyzer to look (using a "max hold" function), measuring at
> the RX port of the LimeSDR-Mini. This is what the signal looks like, and I
> sort of think that it looks like it's supposed to? This is with a 30 dB
> attenuator (in Attenuator #1 slot from my previous diagram), and no other
> attenuation:
>
>
>
> 2) I don't know how to do a continuous transmit test of the
> srsRAN/Soapy/LimeSDR combination. So I just did the same "max hold"
> function while I started eNodeB and let it run for a minute or so,
> measuring at the RX port of the Quectel module. This signal doesn't look
> as good to me -- but, really, what do I know, and maybe it's not fair
> because I'm not doing continuous transmit in this case. But right off the
> bat I notice that the power is a lot lower (maxing out at -30 dBm to -40
> dBm, compared to the -20 dBm of the Quectel), but also the "curve" doesn't
> look like a nice solid band the way the Quectel modem does. Perhaps it's
> not even power that's my problem -- maybe it's just something wrong with
> the way the LimeSDR uses the spectrum? (Grasping here, sorry) Oh one more
> thing -- #1 was performed on LTE Band #3, but #2 was performed on LTE Band
> #5. But the results are similar on either band -- I just happened to be
> experimenting when I took the picture.
>
>
>
> As I dig deeper, I'm more suspicious of the LimeSDR-Mini being the culprit
> here. Perhaps using a more expensive SDR would give me better results.
> But before I do that, I feel like it's worth asking to see if others know
> how to make the LimeSDR-Mini v2 behave better -- it certainly seems
> possible that there are configuration options and parameters that can be
> tweaked that I don't know about.
>
> Thanks everyone.
>
> Rob
>
> P.S. I suspect there are other ways of using other software tools to
> figure out this LimeSDR stuff, but I really got into this PURELY for
> setting up an eNB with the least amount of effort :-). I don't actually
> WANT to get good at debugging RF issues :-). Still, if someone can tell me
> how to use some of these other tools to debug this problem, I'll do my best
> to learn.
>
>
>
>
> > On Jun 20, 2024, at 2:55 AM, Johann T. <johann.tzt at gmail.com> wrote:
> >
> > Hi Rob,
> >
> > Could you enable the PCAP logging on the eNB? As the UE sent many RACH
> messages, the eNB should send RAR back. Then the UE will initiate RRC
> Connection Request. You should be able to see these messages from the PCAP
> log.
> >
> > Johann
> >
> >
> > On Tue, Jun 18, 2024 at 11:39 AM Rob Newberry <robthedude at mac.com>
> wrote:
> > I'm using srsRAN_4G to test a Quectel EC200U client.
> >
> > The underlying reason I'm doing this is that this IoT device is made for
> Asia and African markets, and uses bands that are not supported by US
> carriers. So I've tried to create a very simple LTE gateway with
> conducted/cabled configuration.
> >
> > Linux + srsRAN_4G
> > |
> > USB
> > |
> > LimeSDR Mini 2.x
> > TX RX
> > | |
> > | |
> > | Attenuator #2 (have tried multiple sizes/combinations)
> > | |
> > XRDS-RF Wideband 2-Way Splitter 698-2700 MHz
> > |
> > Attenuator #1 (have tried multiple sizes/combinations)
> > |
> > Quectel EC200U-CN
> >
> >
> > The issue I'm having is that my UE won't seem to actually join the
> network (apologies for terminology -- I've got a lot of Wi-Fi experience,
> but EXTREMELY little LTE knowledge).
> >
> > From the log messages, it's as if something isn't happening during the
> join phase. I see these messages on the ENB:
> >
> >
> > RACH: tti=181, cc=0, pci=1, preamble=16, offset=32,
> temp_crnti=0x46
> > Disconnecting rnti=0x46.
> > RACH: tti=1471, cc=0, pci=1, preamble=14, offset=32,
> temp_crnti=0x47
> > Disconnecting rnti=0x47.
> > RACH: tti=1921, cc=0, pci=1, preamble=28, offset=32,
> temp_crnti=0x48
> > Disconnecting rnti=0x48.
> > RACH: tti=2161, cc=0, pci=1, preamble=1, offset=32,
> temp_crnti=0x49
> > Disconnecting rnti=0x49.
> > RACH: tti=1821, cc=0, pci=1, preamble=11, offset=32,
> temp_crnti=0x4a
> > Disconnecting rnti=0x4a.
> > RACH: tti=2901, cc=0, pci=1, preamble=24, offset=32,
> temp_crnti=0x4b
> > Disconnecting rnti=0x4b.
> > RACH: tti=2761, cc=0, pci=1, preamble=37, offset=32,
> temp_crnti=0x4c
> > Disconnecting rnti=0x4c.
> > RACH: tti=3001, cc=0, pci=1, preamble=9, offset=32,
> temp_crnti=0x4d
> > Disconnecting rnti=0x4d.
> > RACH: tti=4741, cc=0, pci=1, preamble=29, offset=32,
> temp_crnti=0x4e
> > Disconnecting rnti=0x4e.
> > RACH: tti=4981, cc=0, pci=1, preamble=30, offset=32,
> temp_crnti=0x4f
> > Disconnecting rnti=0x4f.
> > RACH: tti=5641, cc=0, pci=1, preamble=15, offset=32,
> temp_crnti=0x50
> > Disconnecting rnti=0x50.
> > RACH: tti=6511, cc=0, pci=1, preamble=3, offset=32,
> temp_crnti=0x51
> > Disconnecting rnti=0x51.
> >
> > On my EPC, I never see anything like the "Initial UE message" that is
> documented in the example.
> >
> > I've been working on this for several days, trying different ideas but
> nothing has panned out.
> >
> > I've tried changing the attenuators on the Lime RX path and the Quectel
> TX/RX path. So far, all I've determined is that with enough attenuation
> (30 dB on attenuator #1 above), I can make it where even the RACH messages
> don't happen.
> >
> > I've tried changing the n_prb from 50 to 25. That seemed to make the
> RACH messages happen more quickly, but still don't seem to proeed.
> >
> > I've considered tweaking the tx_gain and rx_gain values, but I don't
> know what to put there.
> >
> > I tried increasing the amount of logging (boy did that not help -- PHY
> at debug level is bad news :-)).
> >
> > Any advice for what to hunt for?
> >
> > Rob
> >
> > _______________________________________________
> > srsran-users mailing list
> > srsran-users at lists.srsran.com
> > https://lists.srsran.com/mailman/listinfo/srsran-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20240701/6e0588ce/attachment.htm>
More information about the srsran-users
mailing list