[srsran-users] Requesting RRC Reestablishment as 0x46. Cause: otherFailure

Thu Aug 11 10:42:56 UTC 2022

Hi Antonio, 

Is it possible to share the details of the srsRAN code/implementation of eNB - UE distance estimation exploiting the DMRS. 
I am also looking at such studies based on srsRAN and it will be a great help if you could please share some insights in this regard. 
Thank you. 

Best Regards, 
Debashisha Mishra 

----- On Nov 27, 2021, at 8:56 PM, Antonio Albanese <antonioalbanese15 at gmail.com> wrote: 

> Hi Andre,

> Thanks for your reply.

> [ https://mega.nz/folder/vldThKoJ#Zmk0drON5S4lnWpKK_XUCQ | Here  ] 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 [
> https://ark.intel.com/content/www/us/en/ark/products/130394/intel-nuc-board-nuc7i7dnbe.html
> | Intel NUC7i7DNBE ] 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 < [ mailto:andre.puschmann at srs.io
> | 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
>>> < [ mailto:antonioalbanese15 at gmail.com | antonioalbanese15 at gmail.com ] <mailto:
>> > [ mailto:antonioalbanese15 at gmail.com | 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
>> > [ mailto:srsran-users at lists.srsran.com | srsran-users at lists.srsran.com ]
>>> [ https://lists.srsran.com/mailman/listinfo/srsran-users |
>> > https://lists.srsran.com/mailman/listinfo/srsran-users ]

>> --
>> Andre Puschmann

>> Software Radio Systems (SRS)
>> [ https://www.srs.io/ | https://www.srs.io ]
>> [ mailto:andre at srs.io | andre at srs.io ]

>> PGP/GnuPG key: 0x204A85DFEA324D58
>> fingerprint: 3924 1C60 D52E 81A2 1F2E 0C9D 204A 85DF EA32 4D58

> _______________________________________________
> 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/20220811/44254675/attachment.htm>