[srslte-users] srsenb disconnection problem
Ismael Gomez
ismael.gomez at softwareradiosystems.com
Tue Oct 31 19:17:07 UTC 2017
Ok so maybe there was some interference in that frequency?
On Tue, 31 Oct 2017 at 12:16 Nicola Bui <n.bui at northeastern.edu> wrote:
> Right now, I changed band: I was using band 8 (950MHz) because it is ISM
> in the US, but now I am using band 7 and, apparently, I don't see the issue
> any longer.
> Before eob today I will get the srsue/srsenb case tested in band 8 and
> band 7 and I will tell you about the outcome.
> However, if band 7 is working, I think I have a starting point.
>
> Best,
>
> 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 3:11 PM, Ismael Gomez <
> ismael.gomez at softwareradiosystems.com> wrote:
>
>> 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/49aa6c7a/attachment.htm>
More information about the srsran-users
mailing list