[srslte-users] Radio-link failure (out-of-sync)
Carlo Galiotto
galiotc at tcd.ie
Tue Jul 16 14:47:09 UTC 2019
HI Justin,
Right now we use the UHD version 3.13.0.1.
Would you recommend us to update it?
Carlo
On Tue, 16 Jul 2019 at 15:15, Justin Tallon <
justin.tallon at softwareradiosystems.com> wrote:
> 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
>>
>
--
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/6dab0db0/attachment.htm>
More information about the srsran-users
mailing list