[srslte-users] srsenb disconnection problem

Tue Oct 31 19:11:32 UTC 2017

Can you run the same with srsUE and srsENB and send us both ue.log and
enb.log please? That would be more helpful I think.

I have uhd 3.9.2 and use B210. That would be the best platform.

What other phones have you tried and you couldn't connect? We have used
huawei dongles and phones, nexus 4 and 5, etc and never find any issue..

On Tue, 31 Oct 2017 at 10:12 Nicola Bui <n.bui at northeastern.edu> wrote:

> Hi,
>
> I tried with two different USRP B210 and different antennas. I never tried
> with a reference signal, not sure I can. I am trying with a different
> phone, but so far only the moto g5+ could see the network.
> The thing is the problem happened also if I tried connecting srsue to
> srsenb. Now I am also trying with a different version of the uhd driver
> (which version do you suggest?)
> I can also try with bladeRF if you believe it might be better.
> Just let me know which configuration has the highest chance of working.
>
> Thanks,
>
> Nicola Bui
> Senior Research Scientist
> College of Computer and Information Science
> 655E Interdisciplinary Science and Engineering Complex
> Boston, MA 02115
>
> On Tue, Oct 31, 2017 at 10:58 AM, Ismael Gomez <
> ismael.gomez at softwareradiosystems.com> wrote:
>
>> Now that's the same issue you saw with 25 PRB. For some reason it looks
>> like the USRP stops transmitting for a short period of time or the UE
>> disconnects. From the logs it looks like all is normal and good so I'm not
>> sure what could be happening.
>>
>> If you have access to another USRP, could you try swapping it? Are you
>> using B210? Do you have a GPSDO or 10 MHz reference signal? Can you try
>> with another phone?
>>
>> On Tue, 31 Oct 2017 at 06:35 Nicola Bui <n.bui at northeastern.edu> wrote:
>>
>>> 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 at 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 at 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 at 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 at 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 at 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 at 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/65dbf199/attachment.htm>