TDMA Radio Model interference question

[vivianchiong]

Hello,

Where is interference taken into account when we process packets upstream in the TDMA radio model? e.g. when 2 nodes B and C transmit at the same time to node A, how does node A deal with that?

Does the SINR calculation below take the Interference part of SINR into account in the dNoiseFloordB variable?

dSINR = frequencySegment.getRxPowerdBm() - dNoiseFloordB;

Thank you so much!

[sgalgano]

The receiving node locks on to the transmission with the earliest start-of-reception (SoR) time and if the SoRs are the same, the first transmission received by the receiving node. The other transmissions in the same slot are treated as noise along with any out-of-band signals (represented by the dNoiseFloordB term when calculating SINR).

[vivianchiong]

Thank you!

Another question I had was,

We're trying to model our waveform performance in EMANE using the open source TDMA radio model and EMANE Phy Layer as a starting point. We configured the EMANE Phy Layer to have our waveform parameters for the goal of mapping our understanding of the physical layer model of our waveform to the EMANE environment. To determine whether a receive was successful or not in our waveform, our physical layer model first 1) adds a processing gain to our calculated receive SINR, then 2) checks that new SINR value against a threshold.

We accomplished point 2) by utilizing PCR curves in the EMANE scenario and mapping "good" versus "bad" SINR values to their corresponding probability of reception. The reported Rx Power's in the EMANE Phy Layer's ReceivePowerTable, as well as the TDMA Radio Model's reported SINR's and noise floors from emane.log files all sync up to our physical model understanding exactly. However, the major problem arises when the EMANE Phy Layer drops packets prematurely before they can get flowed up to the Radio Model to do that successful vs. unsuccessful check in point 2) that accounts for processing gain pulling the signal up.

How could we account for the processing gain at the Phy Layer, OR at least be able to successfully account for it at the Radio Model level without the Phy Layer dropping packets that it might deem as not successful (due to "below receiver sensitivity"), but our Radio Model does?

We can't fidget with the bandwidth and systemnoisefigure parameters in the rxSensitivity calculation because that would break our other calculations up the upstream flow and desynchronize the two physical models we are trying to map together. I also looked at perhaps utilizing the rxsensitivitypromiscuousmodeenable parameter, but that doesn't send ControlMessages up to the Radio Model which doesn't seem like a good idea.

Do you have any suggestions on how best to get a workaround on this so that our physical layer model can match up with some configuration of EMANE's Phy Layer model, ideally without modifying the EMANE Phy Layer code?

[patelkb]

The simplest thing, as you mentioned, would be to adjust the noise figure in the PHY to lower you receiver sensitivity to allow for packets your radio model would expect to receive. Your radio model implementation can account for the actual noise figure as required.

Kaushik B. Patel Adjacent Link LLC

On 8/2/23 16:50, Vivian Chiong wrote:

Thank you!

Another question I had was

We're trying to model our waveform performance in EMANE using the open source TDMA radio model https://github.com/adjacentlink/emane/wiki/TDMA-Model and EMANE Phy Layer https://github.com/adjacentlink/emane/wiki/Physical-Layer-Model as a starting point. We configured the EMANE Phy Layer to have our waveform parameters for the goal of mapping our understanding of the physical layer model of our waveform to the EMANE environment. To determine whether a receive was successful or not in our waveform, our physical layer model first 1) adds a processing gain to our calculated receive SINR, then 2) checks that new SINR value against a threshold.

We accomplished point 2) by utilizing PCR curves https://github.com/adjacentlink/emane/wiki/TDMA-Model#packet-completion-rate in the EMANE scenario and mapping "good" versus "bad" SINR values to their corresponding probability of reception. The reported Rx Power's in the EMANE Phy Layer's ReceivePowerTable, as well as the TDMA Radio Model's reported SINR's and noise floors from emane.log files https://github.com/adjacentlink/emane/blob/master/src/models/mac/tdma/receivemanager.cc#L201 all sync up to our physical model understanding exactly. However, the major problem arises when the EMANE Phy Layer drops packets prematurely before they can get flowed up to the Radio Model to do that successful vs. unsuccessful check in point 2) that accounts for processing gain pulling the signal up.

How could we account for the processing gain at the Phy Layer, OR at least be able to successfully account for it at the Radio Model level without the Phy Layer dropping packets that /it/ might deem as not successful (due to "below receiver sensitivity"), but our /Radio Model does/?

We can't fidget with the bandwidth https://github.com/adjacentlink/emane/wiki/Physical-Layer-Model#bandwidth and systemnoisefigure https://github.com/adjacentlink/emane/wiki/Physical-Layer-Model#systemnoisefigure parameters in the rxSensitivity calculation https://github.com/adjacentlink/emane/wiki/Physical-Layer-Model#receive-power-calculation because that would break our other calculations up the upstream flow and desynchronize the two physical models we are trying to map together. I also looked at perhaps utilizing the rxsensitivitypromiscuousmodeenable https://github.com/adjacentlink/emane/wiki/Physical-Layer-Model#rxsensitivitypromiscuousmodeenable parameter, but that doesn't send ControlMessages up to the Radio Model which doesn't seem like a good idea.

Do you have any suggestions on how best to get a workaround on this so that our physical layer model can match up with some configuration of EMANE's Phy Layer model, ideally without modifying the EMANE Phy Layer code?

— Reply to this email directly, view it on GitHub https://github.com/adjacentlink/emane/issues/239#issuecomment-1662948688, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPLXM3UW2NNOZASVWL3N23XTK4THANCNFSM6AAAAAA2QVI7JY. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[vivianchiong]

Thank you, that workaround worked for me, however the noise floor calculation doesn't seem quite right.

I created a scenario that essentially has two nodes, 9 and 10, both transmitting at the same slot to node 1. Nodes 1 and 10 are close to each other, but I set the pathloss high. Nodes 1 and 9 are far from each other, but I set the pathloss low. Since TDMA locks onto the earliest start of reception transmission, we expected (and confirmed) that Node 1 locks onto Node 9 with the now lower pathloss. They both have the same txpower and antenna gains, so we expected (and confirmed) that rx power from Node 9 is a lot higher than that from Node 10. Rx sensitivity is -90.5 in our TDMA radio model.

Looking at the "max noise", the max noise printed from node 10 correctly indicates that the rxpower from node 9 is interference.

However, the noise floor reported from the POV of node 9 being received by 1 isn't what we expect. We expect the noise floor to be interference power (in this case rx power from node 10, -98.2) + noise (-90.5) = -89.6, but it looks like EMANE doesn't care about the interference if it's not significant enough and just uses the rx sensitivity value (in this case, -90.5).

What do you think is the best workaround for this? I'd love to have your insight in case there are software decisions or RF knowledge underlying the setting of the noise floor in the above link that I'm not aware of.

Again, thank you so much for your help!

[vivianchiong]

Regarding the answer of,

The receiving node locks on to the transmission with the earliest start-of-reception (SoR) time and if the SoRs are the same, the first transmission received by the receiving node.

For a particular TDMA slot, is there a way to lock onto the transmission with the highest energy (highest rx power) instead of the earliest SoR in the TDMA radio model? We don't want to solely correlate low pathloss with the signal we should receive for our waveform. e.g. if node A and B are both transmitting in a slot to node C, and node A's packet arrives with a smaller delay than B, but B has a much higher rx power, node C should lock on and receive node B's packet and flow it up the chain.

[sgalgano]

Since you updated the PHY NoiseFigure to lower the receiver sensitivity and allow lower signals to reach the radio model, you must account for that accordingly within the radio model, even when determining the total interference.

When the TDMA radio model queries the spectrum service for the noise floor, it will return one of two values:

1. RxSensitivity (no other signals were detected above the PHY receiver sensitivity).
2. Highest total energy within a single bin over the entire message span.

In your example, the latter should apply since you lowered the PHY receiver sensitivity to allow the -98.2 dB signal from node-10 to make it through. Now it is up to your implementation of the radio model to update the noise floor with this value. Your radio model implementation needs to add this to the actual RxSensitivity of -90.5 dB in order to determine the total noise/interference.

The TDMA model is a generic reference implementation, you will have to modify the model to achieve the desired result. You can change the code in the model to base lock on receive power instead of SoR here. Modify the test to compare the receive power of the pending message (pendingInfo_) with that of the current message and update pendingInfo_ accordingly.

You can use something similar to the below snippet to get the receive power from pendingInfo_ and similarly from the current message using the frequencySegments parameter of enqueue()

FrequencySegments & pendingFrequencySegments = std::get<4>(pendingInfo_);

auto & pendingFrequencySegment = *pendingFrequencySegments.begin();

double dPendingRxPowerdBm = pendingFrequencySegment.getRxPowerdBm();