wifi: EMLSR client drops ICF if received while terminating a TXOP on another link

This commit is contained in:
Stefano Avallone
2023-06-29 11:00:04 +02:00
committed by Stefano Avallone
parent 91f781d842
commit e97cab8ab8

View File

@@ -786,6 +786,46 @@ EhtFrameExchangeManager::ReceiveMpdu(Ptr<const WifiMpdu> mpdu,
return;
}
/**
* It might happen that the AP MLD has not yet received a data frame being transmitted
* by us on another link and starts sending an ICF on this link. The transmission of
* the ICF might be long enough to terminate after the subsequent acknowledgment, which
* terminates the TXOP on the other link. Consequently, no TXOP is ongoing when the
* reception of the ICF ends, hence the ICF is not dropped and a DL TXOP can start on
* this link. However, even if the aux PHY is able to receive the ICF, we need to allow
* enough time for the main PHY to switch to this link. Therefore, we assume that the
* ICF is successfully received (by an aux PHY) if the TXOP on the other link ended
* before the padding of the ICF. In order to determine when the TXOP ended, we can
* determine when the medium sync delay timer started on this link.
*
* TXOP end
* │
* ┌───┐ another
* AP MLD │ACK│ link
* ───────────┬─────────┬┴───┴───────────────────────────────────────
* EMLSR │ QoS │ │ main PHY
* client │ Data │ │
* └─────────┘ │
* │- medium sync delay timer -│
* ┌─────┬───┐ this
* AP MLD │ ICF │pad│ link
* ────────────────────┴─────┴───┴───────────────────────────────────
* aux PHY
*/
if (auto elapsed =
m_staMac->GetEmlsrManager()->GetElapsedMediumSyncDelayTimer(m_linkId))
{
TimeValue padding;
m_staMac->GetEmlsrManager()->GetAttribute("EmlsrPaddingDelay", padding);
if (*elapsed < padding.Get())
{
NS_LOG_DEBUG("Drop ICF due to not enough time for the main PHY to switch link");
return;
}
}
NS_ASSERT(m_staMac->GetEmlsrManager());
Simulator::ScheduleNow(&EmlsrManager::NotifyIcfReceived,
m_staMac->GetEmlsrManager(),