Equation for Long-Term Slot Sync in Greenfield Spectrum
Explore a third equation proposed for maintaining long-term slot synchronization in wireless channel access, addressing challenges in existing IEEE 802.11 standards. The solution introduces a novel approach to address slot synchronization issues in OBSS environments, enhancing performance and efficiency in wireless networks.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
doc.: IEEE 802.11-25/0434r0 Mar 2025 A Third Equation for Long-Term Slot Sync in Greenfield Spectrum Mar 2025 Authors: Name Affiliation Phone email Brian Hart Cisco Systems brianh@cisco.com Binita Gupta Cisco Systems Malcolm Smith Cisco Systems Juan Carlos Zuniga Cisco Systems Stephen Orr Cisco Systems Javier Contreras Cisco Systems Slide 1 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 Situation Slotted Access is regarded as a Good Thing in Wireless Channel Access Slotted ALOHA CSMA/CA (built on slots) ALOHA And certain technologies, like HiP EDCA, really lean into slot alignment [1] Ditto, Multi-AP Coordination would also benefit from slot alignment Slide 2 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 Problem: For 802.11 at 2.4/5/6 GHz, slot synchronization is quickly lost in OBSS environments with out-of-range nodes AP A AP B AP C Many simulations have most/all APs and STAs in range of each other, so don t encounter this slot asynchronism Since 24+16us != n*9us, BSSs are now slot asynchronous AP C cannot hear AP As TXOP, so continues counting slots After 4us of CCA, channel remains idle, so AP B transmits ... and collides with AP C Since all BSSs hear AP B, all BSSs are slot synchronized CCA CCA Busy TXOP AP A SIFS Slot SIFS Slot CCA CCA CCA Busy AP B TXOP TXOP SIFS Slot Slot SIFS Slot XXXXXXXX TXOP CCA CCA CCA CCA CCA CCA AP C Busy SIFS Slot Slot Slot Slot Slot Slot aSifs+n*aSlot aSifs T aSifs Time (1us/tick) Slide 3 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 Solution (1/3): For 802.11 at 2.4/5/6 GHz, slot synchronization can be retained for appreciably longer via a simple PPDU Extension with 1 sec granularity AP A AP B AP C AP C cannot hear AP As TXOP, so continues counting slots Since 24+5PE+16us == n*9us, BSSs remain slot synchronous After 4us of CCA, channel is busy, so AP B defers ... and doesnt collide with AP C Since all BSSs hear AP B, all BSSs are slot synchronized CCA 5us PE Busy TXOP AP A SIFS Slot SIFS Slot CCA CCA CCA Busy Busy AP B TXOP SIFS Slot Slot SIFS Slot CCA CCA CCA CCA CCA CCA AP C Busy TXOP SIFS Slot Slot Slot Slot Slot Slot Slide 4 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 Solution (2/3): The solution is a third design equation (but it is too hard to introduce at 2.4/5/6 GHz due to legacy PPDUs and products) Currently the MAC design rules (10.3.7 DCF timing relations, 10.23.2.4 Obtaining an EDCA TXOP) are based on two equations: aSlotTime, based on aCCATime, aMACProcessingDelay, aRxTxTurnaroundTime, aAirPropagationTime aSIFSTime, based on aRxPHYDelay, aMACProcessingDelay, aRxTxTurnaroundTime CSMA/CA powered by wide-area slot synchronization access needs a third equation: e.g., Option A (TXOP-level alignment): Duration(TXOP) needs to be an integer multiple of aSlotTime Minimizes padding, but slot sync is typically lost if PIFS or EIFS recovery is invoked (fail) Option B (PPDU-level alignment): TXTIME(TXOP) + aSIFSTime needs to be an integer multiple of aSlotTime EIFS becomes an integer multiple of aSlotTime too Adds extra padding, but this come in handy if PIFS or EIFS recovery need to be invoked Given the OFDM symbol duration is not an integer (sub)multiple of aSlotTime, this padding is most easily and robustly achieved by the PPDU Extension at the end of each PPDU having suitable granularity Slide 5 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 Solution (3/3) Since IMMW only needs to coexist with legacy, IMMW spectrum can be considered as greenfield, where the third constraint can be introduced Assume 8x overclocking is applied, to both PPDU clock and MAC clock Then we additionally want to achieve: TXTIME(TXOP) + aSIFSTime needs to be an integer multiple of aSlotTime For PPDUs, calculate TXTIME as usual, then append an extra Slot-Sync PE of duration: aSlotTime * ceil((TXTIME+aSIFSTime)/aSlotTime) - (TXTIME+aSIFSTime) This Slot Sync PE is globally applied to all PPDUs sent by IMMW STAs, so no additional SIG signaling is required Desirable spectral characteristics if constructed as a cyclic extension of the final OFDM symbol Required padding resolution is 1 sec / upclocking rate, or 0.125 sec for 8x overclocking Slide 6 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 Summary Slot synchronization is desirable to reduce collisions 802.11 CSMA/CA is not designed to preserve slot synchronization for out-of-range BSSs Many simulations have most/all APs and STAs in range of each other, so don t encounter this slot asynchronism We can provide for slot synchronism that is sustained and retained across multiple hops if we introduce a third design constraint TXTIME(TXOP) + aSIFSTime needs to be an integer multiple of aSlotTime This design constraint is readily achieved in greenfield bands, such as IMMW, by appending every PPDU with a Slot- Sync PE of duration: aSlotTime * ceil((TXTIME+aSIFSTime)/aSlotTime) - (TXTIME+aSIFSTime) Likely resolution is 0.125 sec Slide 7 Hart et al (Cisco Systems)
doc.: IEEE 802.11-25/0434r0 Mar 2025 References [1] 11-23/1065r0, 11-23/2126r0, 11-24/0467r1, 11-24/0840r0, 24/1144, Dmitry Akhmetov (Intel) et al Slide 8 Hart et al (Cisco Systems)
