Ieee80211: add support for HT primary and secondary channels (HT40- and HT40+) - #1136
Open
mgonzalezlopezudc wants to merge 9 commits into
Open
Ieee80211: add support for HT primary and secondary channels (HT40- and HT40+)#1136mgonzalezlopezudc wants to merge 9 commits into
mgonzalezlopezudc wants to merge 9 commits into
Conversation
…nd HT40+) - Added primary, secondary, and bonded center frequency calculations in Ieee80211Channel with HT40+ and HT40- offsets per IEEE Std 802.11-2024 Table 9-134. - Implemented multi-threshold HT CCA sensing (-82 dBm HT20, -79 dBm HT40 bonded, -62 dBm energy detection) in Ieee80211Receiver per Clause 19.3.19.6. - Added IIeee80211CcaProvider interface and ccaStateChangedSignal in Ieee80211Radio for subchannel busy notification. - Implemented secondary channel DIFS idle sensing and EDCA channel access restart in Hcf and Edcaf per Clause 11.15.9. - Added unit tests for channel geometry and CCA sensitivities, and example scenario demonstrating HT20, HT40+, HT40-, and secondary interferer.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Comment on lines
+222
to
+226
| if (shouldRestartHt40ChannelAccess(edcaf)) { | ||
| EV_INFO << "Secondary channel was busy during DIFS before channel access for HT40 transmission, restarting backoff.\n"; | ||
| edcaf->restartChannelAccess(this); | ||
| return; | ||
| } |
There was a problem hiding this comment.
🟡 Other traffic queues can stall when a 40 MHz transmission restarts its backoff
When a queue wins channel access at the same instant another lower-priority queue also finished counting down, and the 40 MHz transmission then restarts its backoff because the secondary channel was busy (early return at src/inet/linklayer/ieee80211/mac/coordinationfunction/Hcf.cc:225), the losing queues are never re-armed, so they sit idle.
Impact: A traffic class that lost an internal tie can stop sending until new traffic happens to arrive for it, delaying or stalling its frames.
Skipped internal-collision handling on HT40 backoff restart
In the normal path, after a queue is granted the channel, Hcf::channelGranted calls edca->getInternallyCollidedEdcafs() and handleInternalCollision(...) (src/inet/linklayer/ieee80211/mac/coordinationfunction/Hcf.cc:228-233), which is the only place that re-invokes requestChannel/restarts contention for EDCAFs whose backoff expired simultaneously but lost the internal collision (their channelAccessGranted in Edcaf::channelAccessGranted at src/inet/linklayer/ieee80211/mac/channelaccess/Edcaf.cc:127 sees isInternalCollision() true and does nothing).
With the new HT40 logic, when shouldRestartHt40ChannelAccess(edcaf) is true the function calls edcaf->restartChannelAccess(this) and returns at line 225, before reaching getInternallyCollidedEdcafs()/handleInternalCollision. The internally-collided EDCAFs therefore never get their contention restarted and remain idle until a subsequent enqueue (Hcf::processUpperFrame) triggers a fresh requestChannelAccess. Under continuous traffic it self-heals on the next packet, but a low-rate/bursty AC can be stalled.
Prompt for agents
In Hcf::channelGranted (src/inet/linklayer/ieee80211/mac/coordinationfunction/Hcf.cc), the HT40 secondary-busy restart branch returns early before the internal-collision handling block (getInternallyCollidedEdcafs / handleInternalCollision). Because handleInternalCollision is the only place that restarts contention for EDCAFs that lost an internal collision at the same simulation time, returning early leaves those queues idle until the next frame enqueue. Consider processing (and clearing) the internally collided EDCAFs before performing the HT40 restart-and-return, or otherwise ensuring the losing EDCAFs' contention is restarted even when the winning EDCAF restarts its own backoff for the busy secondary channel.
Was this helpful? React with 👍 or 👎 to provide feedback.
- Processed internally collided EDCAFs and emitted edcaCollisionDetectedSignal before checking the shouldRestartHt40ChannelAccess condition in channelGranted. - Ensures lower-priority ACs that lost internal contention are restarted and do not stall when the winning AC defers transmission due to secondary channel busy condition.
…state and MIB - Fix Ieee80211Radio::handleUpperCommand to avoid resolving mode from fixed bitrate during channel-only reconfigurations - Order setModeSet before setMode in Ieee80211Radio and delegate to FlatRadioBase - Remove unused htShortGi40 and htMaxMcs parameters from Ieee80211Mib.ned - Clean up secondaryCcaIdleSince handling in Rx::ccaStateChanged - Add unit test Ieee80211RadioReconfiguration_1
- Contention: snapshot and clear callback before channelAccessGranted to safely support reentrant startContention upon secondary channel restart - Edcaf/Dcaf: harmonize assertions in restartChannelAccess - Ieee80211Radio: derive targetBand from configureCommand channel object when bandParam is not explicitly specified - Tests: add channel object band test case to Ieee80211RadioReconfiguration_1
…dary idle check, and rate reconfiguration - Rx: require receptionState == IDLE in HT40 primaryPhysicallyIdle calculation to prevent transmitting during in-progress frame reception - Hcf: apply DIFS in 2.4 GHz and PIFS in 5 GHz for secondary channel idle verification per IEEE Std 802.11-2024 clause 11.15.9 item b - Ieee80211Radio: restrict publishModeSet so bitrate-only reconfigurations do not reset receiver state or emit spurious listening signals
…nt for HT40 subchannels - NarrowbandReceiverBase: check signal band containment in listening band instead of exact center frequency match - ScalarReceiverAnalogModel / DimensionalReceiverAnalogModel: accept signals whose band is contained in listening band - ScalarMediumAnalogModel: treat receptions contained in listening band as full interference - Ieee80211LayeredOfdmReceiver / ApskLayeredReceiver: update reception possibility to use band containment - omnetpp.ini: add sameTransmissionStartTimeCheck = "ignore" in channelwidths example - Tests: add unit test Ieee80211Ht40SubchannelReception_1
…ub-band energy detection When using ScalarMediumAnalogModel, evaluating a 40 MHz signal across a 20 MHz sub-channel listening query triggered a cRuntimeError in computeNoise() because the signal was only partially overlapping. In Ieee80211Receiver::computeHtCcaBusy, directly compute the apportioned overlapping power for scalar medium models based on the frequency overlap fraction, and add a unit test validating sub-band power apportioning and ED detection.
…ckoff from secondary-only energy
…channel support Updating reference fingerprints (tplx, ~tNl, ~tND) in showcases.csv and tutorials.csv following the IEEE 802.11 HT40 primary and secondary channel enhancements. The changes in PHY/MAC channel sensing, band-containment matching in receiver analog models, flat background noise PSD calculations, and CCA state snapshot notifications shifted the simulation event trajectories for scenarios using Ieee80211RadioMedium (Dimensional analog model). Affected configurations (19 total): - showcases/routing/manet: Aodv, Dsdv - showcases/visualizer/canvas: instrumentfigures (General), datalinkactivity (Dynamic), routingtable (Dynamic), statistic (PacketErrorRate) - showcases/wireless/analogmodel: Distance - showcases/wireless/blockack: NoFragmentation, Fragmentation, MixedTraffic - showcases/wireless/fragmentation: DCFnofrag, DCFfrag, HCFfrag, HCFfragblockack - showcases/wireless/power: General - showcases/wireless/ratecontrol: NoRateControl, AarfRateControl - tutorials/configurator: Step10C, Step12 All 475 wireless/802.11 fingerprint tests and 6 IEEE 802.11 unit tests pass deterministically.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of Changes
This PR implements support for IEEE 802.11n High Throughput (HT) 40 MHz primary and secondary channel operation (HT40- and HT40+), multi-threshold subchannel Clear Channel Assessment (CCA), and EDCA secondary channel DIFS idle sensing and backoff restart per IEEE Std 802.11-2024.
1. Physical Layer & Channel Geometry
Ieee80211SecondaryChannelOffsetenum (none,above,below) and center frequency calculation methods (getSecondaryCenterFrequency(),getBondedCenterFrequency(),getSecondaryChannelNumber()) per Table 9-134.ccaStateChangedSignalwith subchannel busy snapshots.2. MAC & MIB Layers
isSecondaryChannelIdleFor()), and reflected primary CCA status in medium free recomputation.SIFS + 2 * slotTime) per Clause 11.15.9, retaining CW without bumping retry counters or dropping frames.htSecondaryChannelOffset,htShortGi40, andhtMaxMcsparameters.3. Verification & Tests
tests/unit/Ieee80211Ht40SecondaryChannel_1.test: Channel geometry, offsets, and out-of-bounds error handling.tests/unit/Ieee80211HtCcaSensitivity_1.test: Multi-threshold CCA sensitivities and mode set verification.examples/wireless/channelwidths/ChannelWidthsNetwork.ned&omnetpp.ini: Configs forHt20MHz,Ht40MHzSecondaryAbove,Ht40MHzSecondaryBelow, andHt40MHzSecondaryAboveWithInterferer.