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

Justin Tallon justin.tallon at softwareradiosystems.com
Tue Jul 16 14:14:49 UTC 2019 

Hey Carlo,

What version of UHD are you using?


____
Justin Tallon Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

+353-86-067-0753 | justin.tallon at softwareradiosystems.com


On Tue, Jul 16, 2019 at 2:58 PM Carlo Galiotto <galiotc at tcd.ie> wrote:

> 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
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190716/b9da20b0/attachment.htm>

More information about the srsran-users mailing list