Possible issue in NrSpectrumPhy, NrInterference in 5g-lena-v3.0.y

[George Frangulea]

Hello,

After upgrading to the latest ns-3-dev and NR module, I have the following issue when setting NrSpectrumPhy into UnlicensedMode. 

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 will schedule CheckIfStillBusy() accordingly. 
• Before CheckIfStillBusy() would have been called by the scheduler, 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? 

Is there something in the upgraded NR module that discards or resets the channel information more often? 

Can someone please give me some indication of what I should check further? 


Thank you.

[Gabriel Ferreira]

From the code, either the received power is less than the threshold energyW, or end=now (no NiEvents), or rounding error at GetEnergyDuration (end-now, a.k.a. bad luck due to scenario+seed+run).
Enabling NrInterference logs should help.
But I believe there wasn't any change that was supposed to impact that on nr or ns-3.

[George Frangulea]

Hi Gabriel,

Thanks for replying.

I forgot to mention that I upgraded from 5g-lena-v2.5y and ns-3.39 to the latest.
I don't think it's either scenario and/or seed because the error happens in the early stages of simulation and is consistent across any seed I've tried. 
Furthermore, I checked for an ED threshold of -100 dBm, and the same happened (see the annotated .png with traces that include the NrInterference).  However, a higher or lower ED threshold should not create an issue anyway. It will just lead to concurrent transmissions, or at least that is what was the case before upgrading.


I have also tested the NR-U/NR-U case, and the error persists, so it is not related to the wifi module...

I mostly work at the PHY layer, so I don't know how I could look into this issue in the spectrum further. 
Something I could try is to downgrade to 5g-lena-v2.6y and see if the issue persists. 
thank you!

[George Frangulea]

I just checked 5g-lena-v2.6y with ns-3.40, and this issue in the NrInterference does not happen. 

So, some changes must have been introduced in 5g-lena-v3.0y that resulted in the aforementioned issue when NrSpectrumPhy is set to UnlincesedMode.

[George Frangulea]

The issue occurs in the AppendEvent() function, which was modified from an iterator-based for loop to a range-based for loop in this commit: d2d331cfea678e1a830f68736e952ad59bf49d53.

I've reverted this change back to the original iterator-based loop, and the function now works correctly. Specifically, the energy detected on the channel is no longer erroneously erased, and the assert in MaybeCcaBusy() no longer triggers.

I have checked the cttc-nr-mimio-demo example, and it produces the same results with either loop type in AppendEvent(). If possible, maybe this specific change will be reverted. 
Thank you.

[Gabriel Ferreira]

Hmm, weird. Thank you for debugging this. I have created an issue for that, and will add a test to catch this kind of regressions in the future. 
https://gitlab.com/cttc-lena/nr/-/issues/188

[Gabriel Ferreira]

George, can you give me the exact parameters to trigger the issue with cttc-nr-mimo-demo? OS and compiler version help too.

[George Frangulea]

Hi Gabriel,

I am using Ubuntu 24.04 LTS with g++ (Ubuntu 13.2.0-23ubuntu4) 13.2.0.

The issue it will not occur in the nr-mimo example because it does not implement transmission with an interfering network on the same frequency channel while the NrSpectrumPhy is set to UnlincesedMode. 
Regarding the nr-mimo example, I mentioned that when switching to an iterator-based loop in AppendEvent, it did not change the achieved results. 

To see this issue, you will have to run an example using the NR-U module.

[George Frangulea]

However, even without hitting that assert you can see the difference in the AppendEvent behaviour as shown in the attached png. 

As you can see, the range-based loop is 1st adding the value and 2nd is adding the negative of that value. While in the iterator based loop this does not happen.


You can just add some comments as shown below and run the nr-mimo example as it is just for a few seconds. And loop at the prinout when it is first entering the loop for Summ the energy Delta.

if (!m_receiving)

{

NiChanges::iterator nowIterator = GetPosition(now);

for (NiChanges::iterator i = m_niChanges.begin(); i != nowIterator; i++)

{

m_firstPower += i->GetDelta();

NS_LOG_UNCOND("Summing energy. Delta: " << i->GetDelta()

<< ", m_firstPower: " << m_firstPower);

}

// for (auto& i : m_niChanges)

// {

// m_firstPower += i.GetDelta();

// NS_LOG_UNCOND("Summing energy. Delta: " << i.GetDelta()

// << ", m_firstPower: " << m_firstPower);

// }

// Remove all events up to the current moment

m_niChanges.erase(m_niChanges.begin(), nowIterator);

NS_LOG_UNCOND("Events up to the current moment removed.");

// Create an event that represents the new energy

m_niChanges.insert(m_niChanges.begin(), NiChange(startTime, rxPowerW));

NS_LOG_UNCOND("Inserted new energy event at startTime: " << startTime.GetSeconds()

<< ", rxPowerW: " << rxPowerW);

}

On Tuesday 2 July 2024 at 14:48:00 UTC+1 Gabriel Ferreira wrote:

[Gabriel Ferreira]

Fix for this was merged today and will be part of 5g-lena-v3.1.y. Thanks for spotting the issue and providing a fix.
We need to start adding more unit tests to catch these regressions, but I'm still trying to catch up.

[George Frangulea]

Thanks a lot for dealing with this issue!