Issue in NrSpectrumPhy::MaybeCcaBusy whne upgrading to NR V3.0 and ns3.42

[George Frangulea]

Hello,

I performed the changes I needed for the NR-U module to work in the latest ns-3-dev and NR module. It compiles, but I can't figure out the following issue, which never happened before:

In the attached png I show traces from NrSpectrumPhy::MaybeCcaBusy() where the following happens:

• MaybeCcaBusy() will be called, and GetEnergyDuration() will return the duration of the CCA_BUSY. It will update the time at which this interference will end and schedule CheckIfStillBusy() accordingly. 
• Before CheckIfStillBusy() would have been reached, MaybeCcaBusy()  is called again. However, now when checking the energy on the channel, GetEnergyDuration() returns 0ns and then it hits the abort message. 
  • GetEnergyDuration()  returns 0ns within a duration where it previously detected the CCA_BUSY; how?
    

How and why GetEnergyDuration() can return 0ns since, in a previous measurement, it indicated that the channel will be busy during this time? 

Can someone please give me some indication of what I should check further? I do no know how this happens, so I don't know if it comes from the NR or wifi module. 

If anyone could have a look directly, I could put together a sample code. It will use slight modifications in ns-3-dev to set the Plannar antenna and a private nr and nr-u module. 

Thank you.

[Tom Henderson]

George, is this an NrSpectrumPhy issue (i.e., not ns-3-users issue but a
5g-lena-users issue)? It seems like whatever state variable is used to
track energy duration is getting reset for some reason-- I suggest to
use a debugger to catch the time that it gets reset to zero and then
look at the backtrace and logs to figure out the conditions that
triggered it.

- Tom

On 6/24/24 11:02 PM, George Frangulea wrote:
> Hello,
>
> I performed the changes I needed for the NR-U module to work in the
> latest ns-3-dev and NR module. It compiles, but I can't figure out the
> following issue, which never happened before:
>
> In the attached png I show traces from NrSpectrumPhy::MaybeCcaBusy()
> where the following happens:
>

> * MaybeCcaBusy() will be called, and GetEnergyDuration() will return

> the duration of the CCA_BUSY. It will update the time at which this
> interference will end and schedule CheckIfStillBusy() accordingly.

> * Before CheckIfStillBusy() would have been reached, MaybeCcaBusy()

> is called again. However, now when checking the energy on the
> channel, GetEnergyDuration() returns 0ns and then it hits the abort
> message.

> o GetEnergyDuration()  returns 0ns within a duration where it

> previously detected the CCA_BUSY; how?
>
>
> How and why GetEnergyDuration() can return 0ns since, in a previous
> measurement, it indicated that the channel will be busy during this time?
>
> Can someone please give me some indication of what I should check
> further? I do no know how this happens, so I don't know if it comes from
> the NR or wifi module.
>
> If anyone could have a look directly, I could put together a sample
> code. It will use slight modifications in ns-3-dev to set the Plannar
> antenna and a private nr and nr-u module.
>
> Thank you.
>
>

> --
> Posting to this group should follow these guidelines
> https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
> <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
> <mailto:ns-3-users+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ns-3-users/b3153caa-a959-489b-895b-14b61b74624dn%40googlegroups.com <https://groups.google.com/d/msgid/ns-3-users/b3153caa-a959-489b-895b-14b61b74624dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[George Frangulea]

Thanks Tom. I initially thought it might be due to the changes I made in ns-3-dev, but it is not. The error also persists in the NR-U/NR-U case, so you're right.
The issue is in the NrInterference. I provide backtraces and annotated logs here:
https://groups.google.com/g/5g-lena-users/c/Yhmc0T52sgY