[srsran-users] Requesting RRC Reestablishment as 0x46. Cause: otherFailure
Antonio Albanese
antonioalbanese15 at gmail.com
Sat Nov 27 16:56:40 UTC 2021
Hi Andre,
Thanks for your reply.
Here <https://mega.nz/folder/vldThKoJ#Zmk0drON5S4lnWpKK_XUCQ>you can find
the full epc and eNB logs as well as the eNB configuration. I've been
playing with release 19.12 this week and I might have upgraded some
dependencies as, in this instance, the UE could retain the connection for
longer, although it started throwing RRC failures after a while on heavier
loads (iperf).
I normally encounter way fewer disconnections with 25 PRBs, although some
happen over longer runs, which is not the case with 25 PRBs on release
19.12. I could provide you with additional logs if needed.
My setup comprises an Intel NUC7i7DNBE
<https://ark.intel.com/content/www/us/en/ark/products/130394/intel-nuc-board-nuc7i7dnbe.html>
with
16GBs of RAM and a Samsung Galaxy TAB S2 as UE. I also tested it with an
iPhone 12, getting the same results.
Best,
Antonio
ᐧ
On Tue, 23 Nov 2021 at 13:30, Andre Puschmann <andre.puschmann at srs.io>
wrote:
> Hey,
>
> On 22/11/21 17:41, Antonio Albanese wrote:
> > from the knowledge I could gain browsing the mailing list, I believe
> > the problem is that I have quite a number of underruns or lates, which
> > should be a signal that my CPU can't keep up with the 100 PRB
> > configuration.
> > I have less problems with 50 PRBs (but still experience disconnections)
> > while it is almost completely stable with 25 PRBs.
>
> Yes, that is usually what you would observe, i.e. improving stability
> with decreasing bandwidth.
>
> Can you explain "almost completely stable"? Of course you're running the
> eNB on general purpose CPU and OS so some glitches are just expected but
> 25 PRB should be - DSP wise - ok for a machine that "almost" runs 100 PRB.
>
> >
> > I played with srsLTE already in the past and, as far as I remember, with
> > previous versions of srsLTE I could get much better stability by setting
> > the expert option /pregenerate_signals./
> > However, on srsRAN, though present in the enb.conf example, it leads to
> > /unrecognised//option "expert.pregenerate_signals"/.
> >
> > I see that it's been removed from the enb parser indeed. Is it
> intentional?
>
> Yes, we've removed that feature over the last release(s). We measured
> the performance gain and decided it's not worth the increase in RAM
> usage, extra code, etc. The DSP is optimized and you should not see a
> significant performance hit. Could you perhaps share your setup details
> and logs?
>
>
> It seems we forgot to remove the entry in the enb.conf.example. We'll
> fix that. Thanks for the hint.
>
> Thanks
> Andre
>
> >
> > Thanks a lot,
> > Antonio
> > ᐧ
> >
> > On Sun, 21 Nov 2021 at 19:02, Antonio Albanese
> > <antonioalbanese15 at gmail.com <mailto:antonioalbanese15 at gmail.com>>
> wrote:
> >
> > Hi guys,
> >
> > I'm experiencing the behavior in subject while running srsRAN with a
> > USRP B210 and an off-the-shelf UE.
> > I tested it with a Galaxy Tab S2 and an iPhone 12 with no
> > discernible difference.
> >
> > In particular, especially with /n_prb = 100/, I get RRC failures now
> > and then. I attached the eNB log right before and right after such a
> > disconnection.
> > I'm working on an application that requires high radio stability and
> > high bandwidth to estimate the distance between the eNB and the UE
> > via DMRS. While experimenting I could see that the estimated
> > distance by the crosscorrelation lag between the received DMRS and
> > the local DMRS copy kind of drifted with time, which I would ascribe
> > to one party not being able to keep its TTI-level synchronization.
> > The host is an /Intel NUC7i7DNBE/ and is completely dedicated to the
> > task. The behavior is still there even with a clean version of
> > srsRAN without any source code edits.
> >
> > I also attach the eNB configuration. I tried playing with the
> > /device_args /setting it to /num_recv_frames=64,num_send_frames=64
> > /with no luck.
> >
> > Any help would be much appreciated.
> >
> > Thank you,
> > Antonio
> >
> >
> -----------------------------------------------------------------------------------------------------------------------------
> >
> >
> > linux; GNU C++ version 5.4.0 20160609; *Boost_105800*;
> > *UHD_003.009.007-6-g9ebbb8eb
> > *
> > --- Software Radio Systems LTE eNodeB ---
> >
> > Couldn't open , trying /home/nuc/.config/srsran/enb.conf
> > Reading configuration file /home/nuc/.config/srsran/enb.conf...
> > Couldn't open sib.conf, trying /home/nuc/.config/srsran/sib.conf
> > Couldn't open rr.conf, trying /home/nuc/.config/srsran/rr.conf
> > Couldn't open rb.conf, trying /home/nuc/.config/srsran/rb.conf
> >
> > Built in Release mode using commit 5275f33 on branch master.
> >
> > /home/nuc/srsRAN/srsenb/src/enb_cfg_parser.cc:1216: Force DL EARFCN
> > for cell PCI=1 to 1800
> > Opening 1 channels in RF device=default with args=default
> > Available RF device list: UHD zmq
> > Trying to open RF device 'UHD'
> > Opening USRP channels=1, args: type=b200,master_clock_rate=23.04e6
> > -- Detected Device: B210
> > -- Operating over USB 3.
> > -- Initialize CODEC control...
> > -- Initialize Radio control...
> > -- Performing register loopback test... pass
> > -- Performing register loopback test... pass
> > -- Performing CODEC loopback test... pass
> > -- Performing CODEC loopback test... pass
> > -- Asking for clock rate 23.040000 MHz...
> > -- Actually got clock rate 23.040000 MHz.
> > -- Performing timer loopback test... pass
> > -- Performing timer loopback test... pass
> > RF device 'UHD' successfully opened
> >
> > ==== eNodeB started ===
> > Type <t> to view trace
> > Setting frequency: DL=1865.0 Mhz, UL=1770.0 MHz for cc_idx=0
> nof_prb=100
> > RACH: tti=10011, cc=0, preamble=44, offset=1, temp_crnti=0x46
> > User 0x46 connected
> > RACH: tti=5421, cc=0, preamble=22, offset=1, temp_crnti=0x47
> > User 0x47 requesting RRC Reestablishment as 0x46. Cause: otherFailure
> > Disconnecting rnti=0x46
> > ᐧ
> >
> >
> > _______________________________________________
> > srsran-users mailing list
> > srsran-users at lists.srsran.com
> > https://lists.srsran.com/mailman/listinfo/srsran-users
> >
>
>
> --
> Andre Puschmann
>
> Software Radio Systems (SRS)
> https://www.srs.io
> andre at srs.io
>
> PGP/GnuPG key: 0x204A85DFEA324D58
> fingerprint: 3924 1C60 D52E 81A2 1F2E 0C9D 204A 85DF EA32 4D58
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20211127/d49d7901/attachment.htm>
More information about the srsran-users
mailing list