|
Bugzilla – Full Text Bug Listing |
| Summary: | WifiPhyStateHelper reports false CCA_BUSY times at State trace source | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Karsten Roscher <sfx> |
| Component: | wifi | Assignee: | Nicola Baldo <nicola> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nikkipui, ns-bugs, ruben, sfx |
| Priority: | P5 | ||
| Version: | ns-3.16 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Fixed in 10210:674b7a1cb71e Thanks Karsten! |
The reported times at the trace source "State" of the WifiPhyStateHelper are not consecutive. Expected: The reported times should be without gaps, i.e., the previous state change start time plus the repported duration equals the next state change start time. However, with CCA_BUSY states, this is not always true. In some cases the reported start time is too late and the duration too short. Digging deeper through the code, I suppose I found the cause for this behavior: WifiPhyStateHelper::SwitchMaybeToCcaBusy () updates the internal m_startCcaBusy time with "now" on every call even if the state has already been CCA_BUSY. This leads to a truncation of the CCA_BUSY interval at the beginning if WifiPhyStateHelper::SwitchMaybeToCcaBusy () is called for a second time within a single CCA_BUSY phase. I suggest replacing (line 423 in wifi-phy-state-helper.cc): m_startCcaBusy = now with if (GetState () != WifiPhy::CCA_BUSY) { m_startCcaBusy = now; } This appears to fix it for me. However, I'm not sure if it won't introduce other subtle bugs that I'm not aware of.