Configuring Dynamic Carrier Frequency and Bandwidth for OFDMA Implementation in INET (Feature Request)

[gokulnathreach]

Details:
I am implementing Orthogonal Frequency Division Multiple Access (OFDMA) in INET and facing challenges configuring dynamic carrier frequency and bandwidth for each transmitted message. In the INET physical layer, I've modified the "apsk" module to pass the carrier frequency and bandwidth to the "ApskDimensionalTransmitter" for each packet sent from the MAC layer. However, at the receiver side, the static "centerFrequency" and "bandwidth" settings hinder the reception of dynamically transmitted packets, as they don't adapt to the changing frequency and bandwidth configurations set by the "ApskDimensionalTransmitter."
Attempted Solutions and Expectations:
I've computed the dynamic carrier frequency and bandwidth for each message at the MAC layer and have successfully passed this information to the "ApskDimensionalTransmitter" within the "apsk" module at the Physical layer. However, I'm uncertain about the necessary modifications at the receiver side to enable dynamic listening to the carrier frequency and bandwidth dynamically set at the "ApskDimensionalTransmitter."
Requested Assistance:
Which specific files or components at the receiver side should be modified or updated to ensure dynamic adaptation to the carrier frequency and bandwidth changes set by the "ApskDimensionalTransmitter" for successful reception?

[levy]

The APSK receiver model assumes that the center frequency and bandwidth are known before the signal arrives. It is not strictly required though, so you can implement the dynamic model. See the NarrowbandReceiverBase::computeIsReceptionPossible method, for example, which checks if the center frequency and bandwidth of the transmission matches the receiver's parameters. So basically it's the receiver model that you need to modify to allow receiving such signals.

I can't provide a complete list of necessary changes. I would simply put together an example and see why is the reception unsuccessful. Then I would change the model and repeat until the signal is received correctly.

[gokulnathreach]

@levy Thank you very much for answering the previous question and for accepting the Feature request

[gokulnathreach]

@levy
While implementing OFDMA, I encountered a problem and needed assistance to solve it. Please provide me with pointers to address the issue.

Details:
If two nodes transmit a packet at the same slot (with the same start and end time) and use different subchannels (different frequencies), the packets should not be considered interference. In this case, a neighboring receiver should be able to receive both packets.

Attempted Solutions and Expectations:
In the RadioMedium::isInterferingTransmission function, I obtained the subchannel information of the packet using 'check_and_cast.' I modified the return function as follows:

return transmission->getTransmitterId() != receiver->getId() &&
arrival->getEndTime() > reception->getStartTime() + minInterferenceTime &&
(transmission->getEndRB() >= reception->getStartRB() &&
transmission->getStartRB() <= reception->getEndRB()) &&
arrival->getStartTime() < reception->getEndTime() - minInterferenceTime &&
isInInterferenceRange(transmission, reception->getStartPosition(), reception->getEndPosition());

When debugging the isInterferingTransmission function, I can see that packets using different subchannels do not interfere with each other, even though they have the same "StartTime" and "EndTime." However, at the reception node, only one packet is received, and the other packet is always lost.

I also attempted to debug the RadioMedium::isPotentialReceiver function, but the problem persists. I checked other functions in "RadioMedium.cc" and "Radio.cc" but could not locate the function that prevents the other packets from being received when they have the same "StartTime" and "EndTime".

Requested Assistance:
Please provide pointers to the functions that I need to check to enable both packets to be received at the receiver when they use different subchannels.

[levy]

Different channels can still interfere with each other depending on the channel parameters. For example, in 802.11 subsequent channels still overlap in the frequency domain. There are many reasons why a packet reception can be unsuccessful. I cannot tell you what could be the reason in your case. If you suspect there is a bug in the code, then please provide a minimal example to demonstrate the problem.

[gokulnathreach]

@levy I apologize if my previous explanation was not clear. Let me clarify my implementation of OFDMA. In the given scenario, all nodes are configured with identical PHY layer parameters, including the same "centerFrequency," "bandwidth," and "Channel." Despite these similarities, I virtually divide the time domain into fixed slots and the frequency domain into Resource Blocks (RBs) within the MAC layer.

For each generated packet, I select a specific time slot (defined by start time and end time) and the number of RBs it occupies at the MAC. This information is then passed to the PHY layer. I modified the ApskDimensionalTransmitter::createTransmission and passed the packet's slot duration. In this case, interference occurs if two nodes choose the same slot (start time and end time) to transmit a packet, as determined by the RadioMedium::isInterferingTransmission function.

However, I've extended this function to consider the utilized RBs of the packet. The modified return statement looks like this:

return transmission->getTransmitterId() != receiver->getId() &&
arrival->getEndTime() > reception->getStartTime() + minInterferenceTime &&
(transmission->getEndRB() >= reception->getStartRB() &&
transmission->getStartRB() <= reception->getEndRB()) &&
arrival->getStartTime() < reception->getEndTime() - minInterferenceTime &&
isInInterferenceRange(transmission, reception->getStartPosition(), reception->getEndPosition());

Now, when two packets use the same slot but occupy different RBs, they do not interfere with each other.

However, during the simulation, if two packets use the same slot but use different RBs, still only one packet is received, and the other packet is consistently dropped. I'm uncertain which function, apart from RadioMedium::isInterferingTransmission, might be responsible for dropping the packet.

[levy]

I see. It's hard to tell why the other signal is not received successfully. Did you actually check if there are no interfering signals in the computed Interference object?

Please note that there are quite a few possible reasons why a signal is not received successfully. There are three questions the physical layer is trying to answer. Is the reception possible? Is it attempted? Is it successful?

For example, there's a minimum reception power requirement, and there's also a minimum SNIR requirement (note that the background noise is always there). A receiver can only receive one signal at a time, so received signals cannot overlap in time (independently of RBs). Besides, capturing a stronger signal while receiving a weaker one is not implemented, so the receiver can't switch to the second stronger signal.

I suggest debugging the reception process. Look for the computeIsReceptionPossible, computeIsReceptionAttempted, computeIsReceptionSuccessful, computeReceptionDecision and computeReceptionResult methods.

[gokulnathreach]

@levy Thank you very much for your suggestions. I have gained a better understanding of the PHY layer.

Regarding the following statement: "A receiver can only receive one signal at a time, so received signals cannot overlap in time (independently of RBs)."

Can you please tell me in which function this operation is performed? I need to allow it to receive other signals even if they overlap in time, and I will consider the RBs it uses."

[levy]

This is implemented in Radio.cc, see the methods handleSelfMessage, handleReceptionTimer, startReception, continueReception, and endReception. Also, see the fields receptionTimer and allReceptionTimers. I must say that what you want to achieve is not a simple change.