[srslte-users] srsenb disconnection problem

Tue Oct 31 13:35:01 UTC 2017

Hi Ismael, all,

the disconnection issue happened without an hardware fault as well (no
warning late, underflow, overflow).
Please find attached a log showing it.

Best,

Nicola Bui
Senior Research Scientist
College of Computer and Information Science
655E Interdisciplinary Science and Engineering Complex
Boston, MA 02115

On Mon, Oct 30, 2017 at 2:02 PM, Ismael Gomez <
ismael.gomez at softwareradiosystems.com> wrote:

> Hi Nicola,
>
> I think this is a different issue than the one for 25 PRB, despite the
> result is the same. I've opened an issue in gtihub at
> https://github.com/srsLTE/srsLTE/issues/111. Could you please follow up
> with your results there?
>
> I've created a new branch that I think could fix the issue. I've pushed it
> to:
>
> https://github.com/srsLTE/srsLTE/tree/fix_issue_111
>
> Can you please test it?
>
> thanks
>
> On Mon, 30 Oct 2017 at 09:47 Nicola Bui <n.bui at northeastern.edu> wrote:
>
>> I tried a few more times and this time I noticed the following message
>> 12:30:56.148357 [RRC ] Warning User rnti=0x46 expired Activity deadline:
>> -1:-146192054>60:0 us
>> it seems like I have a problem with the deadlines (why the ms deadline is
>> 0?) and the use of tv variables (why negative?)
>> Can it be the cause of the disconnection?
>>
>>
>> Nicola Bui
>> Senior Research Scientist
>> College of Computer and Information Science
>> 655E Interdisciplinary Science and Engineering Complex
>> Boston, MA 02115
>>
>> On Sun, Oct 29, 2017 at 12:02 AM, Ismael Gomez <ismael.gomez@
>> softwareradiosystems.com> wrote:
>>
>>> Also, make sure you have the TX and RX antennas in cross polarization,
>>> e.g. one vertical and the other horizontal to avoid tx/rx cross-talk.
>>>
>>> On Sat, 28 Oct 2017 at 16:52 Nicola Bui <n.bui at northeastern.edu> wrote:
>>>
>>>> Sure, as soon I'm back in the lab on Monday
>>>>
>>>>
>>>> Nicola
>>>>
>>>> On Oct 28, 2017 19:50, "Ismael Gomez" <ismael.gomez@
>>>> softwareradiosystems.com> wrote:
>>>>
>>>>> Yes, could you send me the log for 50 PRB please?
>>>>> thanks
>>>>>
>>>>> El sáb., 28 oct. 2017 15:30, Nicola Bui <n.bui at northeastern.edu>
>>>>> escribió:
>>>>>
>>>>>> Thanks. Please let me know if I can help in any way.
>>>>>>
>>>>>>
>>>>>> Nicola
>>>>>>
>>>>>> On Oct 28, 2017 18:28, "Ismael Gomez" <ismael.gomez@
>>>>>> softwareradiosystems.com> wrote:
>>>>>>
>>>>>>> Let me look into it and get back to you. We havent seen that issue
>>>>>>> in our lab. We've done very high loads for hours without any random access
>>>>>>> or losing the connection.
>>>>>>>
>>>>>>> El sáb., 28 oct. 2017 15:21, Nicola Bui <n.bui at northeastern.edu>
>>>>>>> escribió:
>>>>>>>
>>>>>>>> CFI is always set to 3 and I already tried with 50 rb, with the
>>>>>>>> same result: during high load the mobile performs a random access which
>>>>>>>> succeeds and cause the misalignment between epc and enb.
>>>>>>>> How can I get the cause of the "DCI can't be scheduled"?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Nicola
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 28, 2017 18:17, "Ismael Gomez" <ismael.gomez@
>>>>>>>> softwareradiosystems.com> wrote:
>>>>>>>>
>>>>>>>> Hi Nicola,
>>>>>>>>
>>>>>>>> I see you are using 25 PRB, what value you have for
>>>>>>>> nof_ctrl_symbols in enb.conf? Can you try setting it to 3 if you haven't
>>>>>>>> already? If you have, can you try with 50 PRB?
>>>>>>>>
>>>>>>>> In the logs it looks like the DCIs can't be scheduled. You can see
>>>>>>>> log messages like this:
>>>>>>>>
>>>>>>>> 13:54:15.964584 [MAC ] Warning [05901] SCHED: Could not schedule DL
>>>>>>>> DCI for rnti=0x46, pid=0
>>>>>>>>
>>>>>>>> You can also see that the eNodeB receives no PUCCH in messages like
>>>>>>>> this:
>>>>>>>>
>>>>>>>> 13:54:15.965262 [PHY0] Info    [05898] PUCCH: rnti=0x46, corr=0.02,
>>>>>>>> n_pucch=20, n_prb=1, ack=0
>>>>>>>>
>>>>>>>> Look at corr value, it must be at least >0.8. This is because the
>>>>>>>> UE didn't receive the PDCCH grant and therefore is not sending the PUCCH
>>>>>>>> ACK signal.
>>>>>>>>
>>>>>>>> We use a quite conservative scheduler for PDCCH and it might try to
>>>>>>>> use highest aggregation level and it can't fit. I'll look into it, in the
>>>>>>>> meantime, can you try with 50 PRB and send me the log again if you see the
>>>>>>>> same issue?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> On Fri, 27 Oct 2017 at 12:32 Nicola Bui <n.bui at northeastern.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Another thing I just noticed is that the sequence of operations in
>>>>>>>>> the phone is as follows:
>>>>>>>>> - the phone is connected
>>>>>>>>> unknown trigger
>>>>>>>>> - the phone attempts a new random access
>>>>>>>>> - the random access succeeds and the phone gets a new c-RNTI from
>>>>>>>>> the eNB together with a new IP address
>>>>>>>>> - the eNB disconnects the old c-RNTI
>>>>>>>>> It looks to me that at this point the mobile phone is connected to
>>>>>>>>> the eNB on a TEID that mismatch the one it is using in the EPC.
>>>>>>>>> Is there a way to understand if a new random access procedure is
>>>>>>>>> perfomed by a terminal considered already connected to the eNB?
>>>>>>>>> Maybe I am just wrong.
>>>>>>>>>
>>>>>>>>> Looking forward to your interpretation.
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nicola Bui
>>>>>>>>> Senior Research Scientist
>>>>>>>>> College of Computer and Information Science
>>>>>>>>> 655E Interdisciplinary Science and Engineering Complex
>>>>>>>>> Boston, MA 02115
>>>>>>>>>
>>>>>>>>> On Fri, Oct 27, 2017 at 2:08 PM, Nicola Bui <
>>>>>>>>> n.bui at northeastern.edu> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Ismael,
>>>>>>>>>>
>>>>>>>>>> attached you can find the log. To get the error I did the
>>>>>>>>>> following:
>>>>>>>>>> - start the epc (OAI - hss, mme, spgw)
>>>>>>>>>> - start srsenb
>>>>>>>>>> - turn on the off
>>>>>>>>>> - some pings to 172.16.0.1 to check the connectivity
>>>>>>>>>> - speedtest (in the middle of the download test) the C-RNTI got
>>>>>>>>>> released
>>>>>>>>>> 13:54:16.034525 <0345%2025> [RRC ] Info    Disconnecting
>>>>>>>>>> rnti=0x46.
>>>>>>>>>> Before this, in the log you can find that there is another RRC
>>>>>>>>>> connection request, which should not be there to the best of my knowledge.
>>>>>>>>>> After the disconnection the mobile phone continue using the new
>>>>>>>>>> C-RNTI obtained with the strange connection request, but, apparently, only
>>>>>>>>>> the uplink is working.
>>>>>>>>>>
>>>>>>>>>> Please, let me know should you need other tests and thank you for
>>>>>>>>>> the support.
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nicola Bui
>>>>>>>>>> Senior Research Scientist
>>>>>>>>>> College of Computer and Information Science
>>>>>>>>>> 655E Interdisciplinary Science and Engineering Complex
>>>>>>>>>> Boston, MA 02115
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 27, 2017 at 11:28 AM, Ismael Gomez <ismael.gomez@
>>>>>>>>>> softwareradiosystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi nicola, can you send the enb.log?
>>>>>>>>>>>
>>>>>>>>>>> El vie., 27 oct. 2017 3:52, Nicola Bui <n.bui at northeastern.edu>
>>>>>>>>>>> escribió:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks Ishmael, Kewin,
>>>>>>>>>>>>
>>>>>>>>>>>> that's not my issue: the problem happens while the phone is
>>>>>>>>>>>> active, in particular when the last is high.
>>>>>>>>>>>> I already tried increasing the inactivity timer and the error
>>>>>>>>>>>> count in the configuration file.
>>>>>>>>>>>> The stranger thing is, as soon as the phone is disconnected (I
>>>>>>>>>>>> believe it is the enb starting the disconnection) it gets a new rnti and,
>>>>>>>>>>>> from the phone perspectives, the network is visible and connected. However,
>>>>>>>>>>>> nothing works anymore like the new rnti is not linked anymore to the proper
>>>>>>>>>>>> device in the epc.
>>>>>>>>>>>> Instead, if I toggle the network from the phone, everything is
>>>>>>>>>>>> resumed properly.
>>>>>>>>>>>> I cannot send a log right now but I'll try to generate one
>>>>>>>>>>>> containing the issue and send it to you.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>>
>>>>>>>>>>>> Nicola
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 27, 2017 04:00, "Kewin Rausch" <krausch at fbk.eu> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had a similar issue (dunno if it's really the same), and I
>>>>>>>>>>>>> partially resolved it by following Ismael answer and increasing the
>>>>>>>>>>>>> inactivity timeout period (now I set it at 60 seconds).
>>>>>>>>>>>>> Basically If i leave the UE connected to 4G but I do not
>>>>>>>>>>>>> generate traffic (for about the time the inactivity timeout value), it get
>>>>>>>>>>>>> disconnected by the eNB.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is not happening while I'm connected to a commercial base
>>>>>>>>>>>>> station, which means that something nasty is happening, and maybe paging is
>>>>>>>>>>>>> not correctly handled.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've tried the configuration with a Nexus 5, and once it get
>>>>>>>>>>>>> disconnected I need to reset everything by switching on and off the
>>>>>>>>>>>>> Airplane mode.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Kewin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Oct 27, 2017 at 8:35 AM, Ismael Gomez <ismael.gomez@
>>>>>>>>>>>>> softwareradiosystems.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi nicola, can you send us the enb.log? It is normal behavior
>>>>>>>>>>>>>> to release the connection after inactivity. You can extend the timeout in
>>>>>>>>>>>>>> the enb.conf file, expert section.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However the UE should reconnect when paging is received when
>>>>>>>>>>>>>> you ping it for instance. If you send me the log I can check it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> El jue., 26 oct. 2017 17:27, Nicola Bui <
>>>>>>>>>>>>>> n.bui at northeastern.edu> escribió:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am running srsenb using oai as EPC. My mobile phone (moto
>>>>>>>>>>>>>>> g5+) connects to the network and for a while behave normally (ping is ok,
>>>>>>>>>>>>>>> surfing is ok, speedtest is fine). However, after some time everything
>>>>>>>>>>>>>>> stops working even though the phone still has an IP address the enb says
>>>>>>>>>>>>>>> the UE is attached (c-RNTI assigned properly).
>>>>>>>>>>>>>>> Actually, in the enb log I can see the c-RNTI got released
>>>>>>>>>>>>>>> and a new one got assigned to the UE, but the new connection is not working
>>>>>>>>>>>>>>> anymore. The only way for recovering the connectivity is from the mobile
>>>>>>>>>>>>>>> toggling on and off the airplane mode.
>>>>>>>>>>>>>>> The only error message I can see is: Unhandled feature in
>>>>>>>>>>>>>>> RRC function: liblte_rrc_unpck_rrc_connection_setup_complete
>>>>>>>>>>>>>>> However this appears even when the connection has been
>>>>>>>>>>>>>>> properly setup.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It will be great if I can get a more stable connection or if
>>>>>>>>>>>>>>> the connection can be automatically reestablished.
>>>>>>>>>>>>>>> Any suggestion on how to debug this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Nicola Bui
>>>>>>>>>>>>>>> Senior Research Scientist
>>>>>>>>>>>>>>> College of Computer and Information Science
>>>>>>>>>>>>>>> 655E Interdisciplinary Science and Engineering Complex
>>>>>>>>>>>>>>> Boston, MA 02115
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> srslte-users mailing list
>>>>>>>>>>>>>>> srslte-users at lists.softwareradiosystems.com
>>>>>>>>>>>>>>> http://www.softwareradiosystems.com/
>>>>>>>>>>>>>>> mailman/listinfo/srslte-users
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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/20171031/652b6ffa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enb.log_disconnection_no_HW_faults.tar.gz
Type: application/x-gzip
Size: 560339 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20171031/652b6ffa/attachment.bin>