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

Thu Jul 11 10:19:58 UTC 2019

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190711/0eef7ed3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: figA.png
Type: image/png
Size: 40982 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190711/0eef7ed3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: figB.png
Type: image/png
Size: 18050 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190711/0eef7ed3/attachment-0001.png>