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

Ismael Gomez ismael.gomez at softwareradiosystems.com
Wed Jul 17 08:14:40 UTC 2019 

Hi carlo,

with that laptop, set nof_phy_threads = 2 in [expert] section and don't use
more than 25 PRB cell. Also, limit the pusch_max_mcs = 16 and set all_level
= warning in [log]

regards

On Tue, 16 Jul 2019 at 17:02, Justin Tallon <
justin.tallon at softwareradiosystems.com> wrote:

> Hey Carlo,
>
>
> I would recommend trying the 3.9.6 LTS.
>
> You need to install from source and it is one of the available branches
>
>
> Let me know how it goes,
>
> Justin
> ____
> 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 4:47 PM Carlo Galiotto <galiotc at tcd.ie> wrote:
>
>> 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
>>
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>


-- 
Ismael Gomez Ph.D.

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

ismael.gomez at softwareradiosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190717/5fef477b/attachment.htm>

More information about the srsran-users mailing list