[srslte-users] Radio-link failure (out-of-sync)
Justin Tallon
justin.tallon at softwareradiosystems.com
Tue Jul 16 15:02:16 UTC 2019
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190716/607ddd72/attachment.htm>
More information about the srsran-users
mailing list