msg= "No info find in HARQ buffer for UE"

[Belghoul Djamel Eddine]

Hey every-one :

I simulate a scenario of A2A4Rsrq Handover Algorithm with 4 EnodB  and 160 UE  which moves randomly in a Box with constant velocity 100 m/s and  I got this message  error :

msg="No info find in HARQ buffer for UE 6", file=../src/lte/model/pf-ff-mac-scheduler.cc, line=728

terminate called without an active exception

Can you  help me Please 

[Belghoul Djamel Eddine]

Any suggestions ?!!

[Nicola Baldo]

Which ns-3 version are you using? One HARQ bug was fixed in ns-3-dev since the ns-3.20 release. Some other HARQ-related fixes are pending with the merge of Piotr's GSoC 2014 work.

[Ziyi He]

hi Djamel

Did you find a way to solve this problem? I am also stuck in this problem?

Thank you so much

[Md Mehedi Hasan]

I am also stuck in this problem? I am using ns3 version 3.23.

[Marco Miozzo]

Hi,

it seems a bug, try to reproduce it an example or test and post it in bugzilla.

Best,

marco.

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[newns3user]

hi, i have a similar error in my simulation.

msg="No info find in HARQ buffer for UE 21", file=../src/lte/model/rr-ff-mac-scheduler.cc, line=707

terminate called without an active exception

i am trying to simulate an LTE network with 16 UEs moving with constant velocity and varying the number of eNBs according to its transmission power.
this error does not occur always but only when i increase the number of eNBs and depending on the simulation time. For example, using 16 eNBs it works correctly until 3800 seconds ( the time i set)  while using 20 eNBs at about 1900 seconds it stops to work and the error above occurs.

have you solved ?? can you help me in order to understand where i am wrong??

thanks

[newns3user]

I am using  the ns-3.24.1 version

[Serkan Buhurcu]

Hi, I am facing the same problem. Has anyone could find a solution after all these years?

I am using ns-3.37. I have had some modifications to the lena-x2-handover-measures.cc example. The problem occurs when I increase the number of UEs to 100 for example. Could it be the initial state where all UEs try to attach to an eNB, and they cause an overflow?

Thanks in advance.

[Çağrı DEMİR]

Hello, 

I have faced with the same problem in ns-3.36 while my simulation perform mobility scenario with 40 UEs and 8 eNBs. It happened right after "HandoverLeavingTimeout" occured in 75th sec. of the simulation. Before that, most of the handovers were successful. 

Any idea and/or help would be appreciated!

.....................

/NodeList/10/DeviceList/0/LteEnbRrc/HandoverStart +68.2689s eNB CellId 7: start handover of UE with IMSI 16 RNTI 7 to CellId 11
/NodeList/14/DeviceList/0/LteEnbRrc/HandoverEndOk +68.2909s eNB CellId 11: completed handover of UE with IMSI 16 RNTI 7
/NodeList/10/DeviceList/0/LteEnbRrc/NotifyConnectionRelease +68.2909s eNB CellId 7 Released UE with IMSI 16 RNTI 7
/NodeList/14/DeviceList/0/LteEnbRrc/HandoverStart +68.8689s eNB CellId 11: start handover of UE with IMSI 16 RNTI 7 to CellId 7
/NodeList/10/DeviceList/0/LteEnbRrc/HandoverEndOk +68.9089s eNB CellId 7: completed handover of UE with IMSI 16 RNTI 8
/NodeList/14/DeviceList/0/LteEnbRrc/NotifyConnectionRelease +68.9089s eNB CellId 11 Released UE with IMSI 16 RNTI 7
/NodeList/8/DeviceList/0/LteEnbRrc/HandoverStart +72.6689s eNB CellId 5: start handover of UE with IMSI 9 RNTI 13 to CellId 4
/NodeList/7/DeviceList/0/LteEnbRrc/HandoverEndOk +72.6929s eNB CellId 4: completed handover of UE with IMSI 9 RNTI 16
/NodeList/8/DeviceList/0/LteEnbRrc/NotifyConnectionRelease +72.6929s eNB CellId 5 Released UE with IMSI 9 RNTI 13
/NodeList/7/DeviceList/0/LteEnbRrc/HandoverStart +73.2689s eNB CellId 4: start handover of UE with IMSI 9 RNTI 16 to CellId 5
/NodeList/26/DeviceList/0/LteEnbRrc/HandoverStart +73.2689s eNB CellId 23: start handover of UE with IMSI 40 RNTI 4 to CellId 19
/NodeList/22/DeviceList/0/LteEnbRrc/HandoverEndOk +73.2889s eNB CellId 19: completed handover of UE with IMSI 40 RNTI 8
/NodeList/26/DeviceList/0/LteEnbRrc/NotifyConnectionRelease +73.2889s eNB CellId 23 Released UE with IMSI 40 RNTI 4
/NodeList/8/DeviceList/0/LteEnbRrc/HandoverEndOk +73.2939s eNB CellId 5: completed handover of UE with IMSI 9 RNTI 14
/NodeList/7/DeviceList/0/LteEnbRrc/NotifyConnectionRelease +73.2939s eNB CellId 4 Released UE with IMSI 9 RNTI 16
/NodeList/8/DeviceList/0/LteEnbRrc/HandoverStart +75.0689s eNB CellId 5: start handover of UE with IMSI 9 RNTI 14 to CellId 4
/NodeList/8/DeviceList/0/LteEnbRrc/RrcTimeout +75.2689s eNB CellId 5: RRC Timeout due to HandoverLeavingTimeout UE with IMSI 9 RNTI 14
/NodeList/8/DeviceList/0/LteEnbRrc/NotifyConnectionRelease +75.2689s eNB CellId 5 Released UE with IMSI 9 RNTI 14
msg="No info find in HARQ buffer for UE 14", +75.269000000s 8 file=/home/demir/Desktop/ns3/ns-3-dev/src/lte/model/rr-ff-mac-scheduler.cc, line=808

terminate called without an active exception

Command 'build/scratch/ns3-dev-x2-handover-with-son-default' died with <Signals.SIGABRT: 6>.

Thanks,

Cagri

3 Ocak 2023 Salı tarihinde saat 09:25:16 UTC+1 itibarıyla Serkan Buhurcu şunları yazdı:

[Çağrı DEMİR]

For more detail, please find below the code block where the error was detected. (from rr-ff-mac-scheduler.cc)

Apparently, the problem is happening because the UE has already been deleted from the eNB due to "HANDOVER LEAVING TIMEOUT". When I checked to understand how the "m_dlHarqProcessesStatus" is filled/cleared, I also found a similar control exists in case of max. retransmission reached.

However, as far as I understand, this time, the FATAL_ERROR is not being triggered, but instead, an ERROR PRINT triggered. Maybe we should do the same in the first snippet in order to avoid the issue? Please advise.

Thanks,

Cagri

Çağrı DEMİR <cagri....@gmail.com>, 9 Nis 2023 Paz, 14:35 tarihinde şunu yazdı:

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---

You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/9ab48823-2d2a-46a2-b4c0-9fe7a9b4da6en%40googlegroups.com.

[Tommaso Pecorella]

Hi Cagri,

thanks for the detailed report. Please open an issue in our tracker (https://gitlab.com/nsnam/ns-3-dev/-/issues). I think that you're right, an error message is more appropriate than a fatal error, but I'm not expert enough in LTE to give a definite answer.

Moreover, the same fatal error is present in other schedulers as well, so perhaps it's better to fix them all together.

BTW, my best guess is that the fatal error was left there from a stage where handover wasn't handled. Moreover, even the "other" line (where only a warning is issued) is suspicious, as the code will continue after printing the error message, but the iterator is pointing past the end of the container - so it's a bug.

[Çağrı DEMİR]

Hello Tommaso,

Thank you for your reply. After digging this issue more, I have found that SchedDlTriggerReq function called with wrong "dlparams" parameters ie. passed information about the UE which has already been released from eNB. However, problem is not happening for the UEs released due to RLF or other reasons. Seems like only the HandoverTO (late or early HO timeout) reason is causing this issue.

After checking it in more detail, I have found that SchedDlTriggerReq is called in lte-enb-mac.cc in LteEnbMac::DoSubframeIndication function. After adding basic if-check as below, the problem was resolved for all types of schedulers. I am sharing my WA solution for those reading this and need urgent fix.

  if (m_dlInfoListReceived.size () > 0)
    {
 // additional check to make sure released UE will not be tried to be scheduled
  std::vector<DlInfoListElement_s>::iterator it1;
  for (it1 = m_dlInfoListReceived.begin(); it1 != m_dlInfoListReceived.end();)
  {
 if (m_rlcAttached.find(it1->m_rnti) == m_rlcAttached.end())
 {
NS_LOG_UNCOND (this << " WARNING! Deleted from DL info list because UE is not attached!! rnti =" << it1->m_rnti);
it1 = m_dlInfoListReceived.erase(it1);
 }
 else
 {
 ++it1;
 }
  }
      dlparams.m_dlInfoList = m_dlInfoListReceived;
      // empty local buffer
      m_dlInfoListReceived.clear ();
    }

  m_schedSapProvider->SchedDlTriggerReq (dlparams);

I will anyway create an issue for LTE experts to check it in more detail. They will probably provide the most appropriate solution.

Cagri

Tommaso Pecorella <tomm...@gmail.com>, 10 Nis 2023 Pzt, 00:02 tarihinde şunu yazdı:

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/b8924473-2907-41c6-9609-87fc9d72cee5n%40googlegroups.com.

[Paul Anderson]

Hello,

this seems to be a major IDLE_SELECTION Problem within the NS3-LTE module.

I have seen the same error message witch each example scenario that involves more then 50 UEs that move in/out or out of cell coverage with automatic cell attachment.

This can be reproduced by i.e. using the provided example "lena-radio-link-failure.cc" and changing from 1 to 60.

uint16_t numberOfUes = 60;

Is there any currently active development of the lte-module? 

@Cagri,

your quick fix did sadly not help in my case since the error message can be thrown in another line of the code.