[srslte-users] Radio-link failure (out-of-sync)

Carlo Galiotto galiotc at tcd.ie
Tue Jul 16 10:00:24 UTC 2019


Hi Andre,

Thanks a lot for your email.

Indeed, we are observing U and L being displayed on the terminal, but we
just didn't think that was the problem - as it works fine with the srsUE
and with another commercial phone.

After you warned us of the problem, we tried two laptops, one with i5-4200M
CPU @ 2.50GHz x2 and the second with i5-8250U CPU @ 1.60Ghz x4; we also
enabled the CPU performance mode in the laptops. We use USB3.0 and USRPs
B210. But "U"s and "L"s are still there.

Is there any other solution to fix this, apart from replacing the laptop
with a more powerful one?
In that case, would you suggest any specs for the hardware?

Thank you again for your help,
Carlo


On Thu, 11 Jul 2019 at 20:19, Andre Puschmann <
andre.puschmann at softwareradiosystems.com> wrote:

> Hi Carlo,
>
> we don't really implement the Reestablishment procedure in srsENB. What
> the eNB does instead is to send a reject and make the phone attach again
> through RRC connection request. So if the phone looses sync, what you
> see is expected.
>
> Regarding the sync losses on the phone, have you checked that the eNB
> does not report lates while transmitting? This is very crucial to avoid
> losing sync.
>
> Cheers
> Andre
>
>
>
> On 11/7/19 12:19, Carlo Galiotto wrote:
> > Hi all,
> >
> > We are currently testing the SRS eNB with a commercial phone (iPhone 6)
> > and a commercial EPC.
> >
> > ################################
> > ####    PROBLEM
> > ################################
> >
> >
> > After performing several tests, we are able to attach the phone
> > over-the-air to the network and connect to the internet.
> > However, we are facing stability problems, with the UE attempting
> > reestablishment.
> >
> > Specifically, once the attachment is complete, we are able to stream a
> > video for a short period of time - it could be 10-15 seconds or up to a
> > minute - but after that, the connection drops.
> > We observed the phone sends an RRCConnectionreestablishmentrequest,
> > which is rejected by the eNB by sending an RRCConnectionRelease.
> >
> > We are trying to understand the cause of this
> > RRCConnectionreestablishmentrequest sent by the phone, but we've had no
> > success so far.
> >
> > Below is the trace extract with (what we think is) the point of failure
> > (taken from the zipped logs in
> > https://www.dropbox.com/s/bhc41zre8v1q27a/reestabIssue.zip?dl=0 ).
> > Only PUCCH was assigned to the UE before new RACH attempt, so it was not
> > the case of MAX RLC UL retx.
> >
> > Our suspicion is that the UE goes out of sync and timer T310 expires.
> >
> > 13:52:26.960026 [PHY0] [I] [07440] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=8, corr=0.0
> > 13:52:26.961358 [PHY1] [I] [07441] PUCCH: rnti=0x46, f=1, n_pucch=0,
> > sr=no, corr=-0.1
> > 13:52:26.967693 [MAC ] [I] [07455] SCHED: Added user rnti=0x47
> > 13:52:26.967897 [RRC ] [I] Added new user rnti=0x47
> > 13:52:26.969049 [MAC ] [I] [07453] SCHED: RAR, ra_id=0, rnti=0x47,
> > rarnti_idx=2, start_rb=0, n_rb=3, rar_grant_rba=102, rar_grant_mcs=0
> > 13:52:26.969145 [PHY1] [I] [07449] PDSCH: rnti=0x2, nof_prb=3,
> > nof_re=378, tbs={7}, mod={2}, rv={0}, t=18 us, tti_tx_dl=7453
> > 13:52:26.971089 [MAC ] [I] [07459] SCHED: Msg3 tx rnti=0x47, pid=3,
> > dci=(0,0), prb=(2,5), n_rtx=0, tbs=7, bsr=0 (0-7)
> >
> > [see Fig.A in attachment]
> >
> > In the SIB, below are the values for the relevant RLF parameters:
> >
> >                       "ue-TimersAndConstants": {
> >                         "t300": "ms2000",
> >                         "t301": "ms100",
> >                         "t310": "ms1000",      # 2000 (ms)
> >                         "n310": "n1",      # 20
> >                         "t311": "ms1000",
> >                         "n311": "n1"
> >
> > We have tried the values commented above (for t310 and n310) to increase
> > the time to radio link failure, so that the connection would have a
> > bigger change of being retained.
> > We observed that the connection is kept longer, but it still breaks,
> > eventually.
> >
> > There might be an underlying cause for UE getting out-of-sync and not
> > recovering, as, for example, some issue with PDCCH decoding.
> >
> > [See Fig. B in attachment]
> >
> > From radio quality perspective, downlink signal strength should be okay,
> > as reported by CQI:
> >
> > 13:52:26.405247 [PHY0] [I] [06920] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=15, corr=1.0
> > 13:52:26.445206 [PHY0] [I] [06960] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=15, corr=1.0
> > 13:52:26.485290 [PHY0] [I] [07000] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=15, corr=1.0
> > 13:52:26.559936 [PHY0] [I] [07040] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=6, corr=0.0
> > 13:52:26.600090 [PHY0] [I] [07080] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=11, corr=0.0
> > 13:52:26.640086 [PHY0] [I] [07120] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=13, corr=0.0
> > 13:52:26.680081 [PHY0] [I] [07160] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=15, corr=0.0
> > 13:52:26.720087 [PHY0] [I] [07200] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=5, corr=0.0
> > 13:52:26.760125 [PHY0] [I] [07240] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=12, corr=0.0
> > 13:52:26.800167 [PHY0] [I] [07280] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=8, corr=0.0
> > 13:52:26.840176 [PHY0] [I] [07320] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=6, corr=0.0
> > 13:52:26.880036 [PHY0] [I] [07360] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=10, corr=0.0
> > 13:52:26.920060 [PHY0] [I] [07400] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=11, corr=0.0
> > 13:52:26.960026 [PHY0] [I] [07440] PUCCH: rnti=0x46, f=2, n_pucch=0,
> > cqi=8, corr=0.0
> >
> > ################################
> > ####    QUESTIONS
> > ################################
> >
> > - Do you know what the problem could be and if there is any way to fix
> it?
> > - We checked this post
> >
> http://www.softwareradiosystems.com/pipermail/srslte-users/2019-January/002210.html
> > . Do you think it's somehow related to what we experienced?
> >
> > ################################
> > ####    NOTE
> > ################################
> >
> > - The enb.log file is big, let us know if you prefer we filter it.
> > - In the link
> > https://www.dropbox.com/s/bhc41zre8v1q27a/reestabIssue.zip?dl=0  you can
> > find enb logs and pcaps.
> >
> >
> > Thank you in advance for your help.
> >
> >
> > --
> > Best regards,
> >
> > Carlo Galiotto
> >
> > CONNECT - Networks for the Future
> > Dunlop Oriel House
> > Trinity College
> > Dublin 2
> > Ireland
> >
> > _______________________________________________
> > srslte-users mailing list
> > srslte-users at lists.softwareradiosystems.com
> > http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> >
>
>

-- 
Best regards,

Carlo Galiotto

CONNECT - Networks for the Future
Dunlop Oriel House
Trinity College
Dublin 2
Ireland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190716/e029d9d8/attachment.htm>


More information about the srsran-users mailing list