IEEE 802.11-20/0136r2: Virtual Carrier Sense in Multi-Link Networks

Virtual Carrier Sense in Multi-Link
Date:
 2020-02-19
February 2020
Thomas Handte (Sony)
Slide 1
Authors:
Introduction
Multi-link is key feature of EHT
Allows exchange of frames over multiple links concurrently or non-concurrently
Multi-link enhances throughput and latency
Several submissions analyzed operation of multi-link [1, 2, 3]
Asynchronous or quasi-/semi-asynchronous operation provides higher gains than synchronous
Asynchronous operation requires multiple contention channels [4]
Contention is performed independently on each link
This presentation addresses virtual carrier sense (CS) in context of multiple links
How to determine NAV in asynchronous multi-link
Throughout this presentation, we assume that multiple links are formed by different channels
Slide 2
Thomas Handte (Sony)
February 2020
Advantages of NAV specific to asynchronous multi-link
Avoid hidden node problem
As in single link
Advantages of multi-link arise because of fast link switching
Waiting for a NAV setting frame or a time period equal to probe delay in the recently switched
link is often unacceptable
Simulation results in [5] show gain in throughput and latency if NAV conditions in all links are
known
~50% improvement in latency (50%ile)
~25% improvement in throughput
Multi-link NAV helps to switch from asynchronous to synchronous or quasi
synchronous operation
NAVs getting zero at same time is a necessary condition for successful synchronous operation
Slide 3
Thomas Handte (Sony)
February 2020
Primary channel in single link and multi-link
Single link (today’s operation)
Primary/ secondary channel concept
Full backoff on primary channel, PIFS backoff on secondary channels
A STA maintains NAV based on observation of primary channel
Multi-link
Assume straight forward application of single link concept to multi-link
Each link has its own primary channel
i.e. multi-link has multiple primary channels
Each STA needs to observe the primary channel of each link to maintain NAV information for that link
Slide 4
Thomas Handte (Sony)
February 2020
Virtual CS implications of multiple primary channels
Low power efficiency
STA needs to listen to multiple primary channels (i.e. listen to each primary channel of each link)
Restrictions on simultaneous transmit or receive operation may disallow to
observe multiple primary channels at all times [3]
E.g. STA is transmitting on 1
st
 link but needs to listen on primary channel of 2
nd
 link at same time
Single radio STAs, i.e. STAs that can listen to only one link at a time, can’t do
simultaneous reception on multiple primary channels
Slide 5
Thomas Handte (Sony)
February 2020
Proposal (1/3)
Sharing of NAV information
On each primary channel the NAV information of the other primary channel(s) of the other
link(s) is shared
The definition of a multi link primary channel where NAV information of all links is shared may be
envisioned as well [6]
NAV sharing should preferably be done by AP MLD
AP has typically best multi-link hardware capabilities in BSS
It may access all channels of multi-link setup
It may have least restrictions regarding simultaneous transmit or receive operation
AP has reliable NAV information of all links at all times
Example for sharing NAV(link1) over link2
Slide 6
Thomas Handte (Sony)
February 2020
Proposal 
(2/3)
Envisioned AP operation
Once AP obtains NAV information of a link, it shares on the other link(s) as soon as
possible
AP could enforce restrictions on max. PPDU or TXOP length to limit sharing delay
AP doesn’t share if sharing delay exceeds NAV time that is to be shared
Implementation of NAV sharing
Frame of CTS-type (“multi-link CTS”)
Pros: simple, well-known
Cons: rare update if long TXOPs present, detection MCS depended
Include multi-link NAV information in 11be PHY preamble (preferred)
Pros: update every time an AP transmits 11be preamble, detection MCS independent
Cons: need to compress NAV info, need BSS identifier in PHY preamble (could reuse BSS Color)
Slide 7
Thomas Handte (Sony)
February 2020
Proposal (3/3)
Envisioned STA operation
STA listens on the primary channel of a link or on the multi-link primary channel
STA obtains NAV for this link as usual
STA obtains NAV for all other links based on shared NAV
Before shared NAV of a link reaches zero, a STA shall either
switch to that link and determine NAV
as usual
or
 
stay on the current link and await new
 
shared NAV information
If STA decides to transmit on a link that
doesn’t include the currently observed
primary channel, it should switch to that
channel as early as possible and before
shared NAV of that link reaches zero.
Slide 8
Thomas Handte (Sony)
February 2020
Benefits
Proposal avoids reception on multiple links at same time for NAV maintenance
High power efficiency
No impact of joint transmission and reception restrictions
Single radio STAs may participate in and benefit from multi-link operation
Enable fast transmission after link switching
Shared NAV may reduce the waiting time before a non-observed channel may be accessed
Robust NAV detection in frames that are transmitted in non-duplicate non-HE format
AP can demodulate any PPDU format that is used in BSS
If AP has restrictions for responding independently on different links [7,8], it may implement
restrictions via shared NAV
AP may alter shared NAV such that restrictions are fulfilled
Slide 9
Thomas Handte (Sony)
February 2020
Simulation (1/3)
Analysis of sharing delay and remaining NAV
Remaining NAV is the value of shared NAV once it is shared, i.e. after
sharing delay passed
Simulation setup
2 links, fully asynchronous operation
Link 1 shares NAV of link 2
Each link: 1 AP entity, 5 STAs, EDCA (best effort)
No implementation delay, i.e. zero sharing delay between AP entities
Link 1
Limits
TXOP {3.2ms or 6.5ms}
PPDU {2ms or 3ms}
Mainly UL traffic (type of worst case scenario because AP entity transmits rarely)
UL: full buffer traffic
DL: BAck
Link 2
Variable TXOP length between 0.5ms and 6.5ms (uniform distribution)
Slide 10
Thomas Handte (Sony)
February 2020
Simulation (2/3)
Sharing delay
Preamble based vs. frame based NAV sharing
Preamble based shows smaller sharing delay
because AP entity has more opportunities to
share NAV
Sharing delay larger than respective limit in
≈10% of cases
Caused by collisions
May be avoided by trigger based channel access
Slide 11
Thomas Handte (Sony)
February 2020
Simulation (3/3)
Remaining NAV
Remaining NAV smaller zero doesn’t provide
any benefit
AP shares NAV only when remaining NAV>0
In case of preamble based sharing with PPDU
limit of 2ms, AP shares NAV in 85% of the cases
In case of frame based sharing with TXOP limit
of 6.5ms, AP shares NAV in 45% of the cases
Slide 12
Thomas Handte (Sony)
February 2020
Area of interest
OBSS scenario
NAV info of AP is not complete in OBSS scenario
Shared NAV may differ from the NAV that a STA would obtain on a channel
Potential solutions
STAs may report NAV that has been set by a OBSS PPDUs to AP in order to improve
shared NAV information (similar to [9])
Sharing delay may increase
Reported NAV may not be applicable for all STAs of BSS
APs share shared NAV info via multi-AP concepts
Requires OBSS to be part of multi-AP group
Reported NAV may not be applicable for all STA of BSS
STAs may switch link early and listen for OBSS PPDUs
May define a minimum listening time for STAs and links that are subject to OBSS interference
Slide 13
Thomas Handte (Sony)
February 2020
Summary
Virtual carrier sense is important in multi-link
~50% improvement in latency (50%ile), ~25% improvement in throughput [5]
Maintaining NAV from multiple primary channels of multiple links has drawbacks
Low power efficiency
Not feasible if STAs have restrictions on simultaneous transmit or receive operation
Proposal: Share NAV information among links
On each primary channel of a link the NAV information of the other primary channel(s) of other link(s) is shared
Sharing may preferably be implemented by NAV information within PHY preamble
Main benefits
High power efficiency, no restrictions on simultaneous transmit/ receive operation
Simulation results
Restrictions to TXOP length or PPDU length help to achieve small sharing delay
Preamble based sharing with a max. PPDU length of 2 ms achieves successful NAV sharing in 85% of the cases
Slide 14
Thomas Handte (Sony)
February 2020
References
[1] 11-19/1291r3 Performance aspects of Multi-link operations
[2] 11-19/1405r7 Multi-Link Operation Channel Access Discussion
[3] 11-19/
1541r1 Performance aspects of Multi-link operations with constraints
[4] 11-19/1144r6 Channel Access for Multi-link Operation
[5] 11-19/1930r2 AP assisted ML operation
[6] 11-19/1526r1 Multi-Link Power-save
[7] 11-19/1836r1 Multi-link Channel Access Discussion Follow-up
[8] 11-19/1548r1 
Channel access design for synchronized multi-links
[9] 11-19/1918r0 UL MU efficiency enhancement using multi-link
Slide 15
Thomas Handte (Sony)
February 2020
Straw Poll
Do you support that an AP entity which is part of a AP MLD may transmit
network state information of the other AP entities which are part of the
same AP MLD?
Note 1: Definition of network state information is TBD
Note 2: R1 or R2 is TBD
Slide 16
Thomas Handte (Sony)
February 2020
Slide Note

doc.: IEEE 802.11-yy/xxxxr0

Month Year

John Doe, Some Company

Page

Embed
Share

In this document presented in February 2020, the focus is on the implementation of virtual carrier sense (CS) in the context of multiple links in IEEE 802.11-20/0136r2. The advantages of NAC in asynchronous multi-link scenarios are discussed, emphasizing the mitigation of the hidden node problem and the benefits of multi-link configurations. The importance of proper NAV settings for achieving synchronization and enhanced throughput is highlighted.


Uploaded on Sep 07, 2024 | 0 Views


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. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. February 2020 doc.: IEEE 802.11-20/0136r2 Virtual Carrier Sense in Multi-Link Date: 2020-02-19 Authors: Name Affiliations Address Phone email Thomas Handte Dana Ciochina Mohamed Abouelseoud thomas.handte (at) sony.com Sony Corporation dana.ciochina (at) sony.com mohamed.abouelseoud (at) sony.com Submission Slide 1 Thomas Handte (Sony)

  2. February 2020 doc.: IEEE 802.11-20/0136r2 Introduction Multi-link is key feature of EHT Allows exchange of frames over multiple links concurrently or non-concurrently Multi-link enhances throughput and latency Several submissions analyzed operation of multi-link [1, 2, 3] Asynchronous or quasi-/semi-asynchronous operation provides higher gains than synchronous Asynchronous operation requires multiple contention channels [4] Contention is performed independently on each link This presentation addresses virtual carrier sense (CS) in context of multiple links How to determine NAV in asynchronous multi-link Throughout this presentation, we assume that multiple links are formed by different channels Submission Slide 2 Thomas Handte (Sony)

  3. February 2020 doc.: IEEE 802.11-20/0136r2 Advantages of NAV specific to asynchronous multi-link Avoid hidden node problem As in single link Advantages of multi-link arise because of fast link switching Waiting for a NAV setting frame or a time period equal to probe delay in the recently switched link is often unacceptable Simulation results in [5] show gain in throughput and latency if NAV conditions in all links are known ~50% improvement in latency (50%ile) ~25% improvement in throughput Multi-link NAV helps to switch from asynchronous to synchronous or quasi synchronous operation NAVs getting zero at same time is a necessary condition for successful synchronous operation Submission Slide 3 Thomas Handte (Sony)

  4. February 2020 doc.: IEEE 802.11-20/0136r2 Primary channel in single link and multi-link Single link (today s operation) Primary/ secondary channel concept Full backoff on primary channel, PIFS backoff on secondary channels A STA maintains NAV based on observation of primary channel Multi-link Assume straight forward application of single link concept to multi-link Each link has its own primary channel i.e. multi-link has multiple primary channels Each STA needs to observe the primary channel of each link to maintain NAV information for that link Submission Slide 4 Thomas Handte (Sony)

  5. February 2020 doc.: IEEE 802.11-20/0136r2 Virtual CS implications of multiple primary channels Low power efficiency STA needs to listen to multiple primary channels (i.e. listen to each primary channel of each link) Restrictions on simultaneous transmit or receive operation may disallow to observe multiple primary channels at all times [3] E.g. STA is transmitting on 1st link but needs to listen on primary channel of 2nd link at same time Single radio STAs, i.e. STAs that can listen to only one link at a time, can t do simultaneous reception on multiple primary channels Submission Slide 5 Thomas Handte (Sony)

  6. February 2020 doc.: IEEE 802.11-20/0136r2 Proposal (1/3) Sharing of NAV information On each primary channel the NAV information of the other primary channel(s) of the other link(s) is shared The definition of a multi link primary channel where NAV information of all links is shared may be envisioned as well [6] NAV sharing should preferably be done by AP MLD AP has typically best multi-link hardware capabilities in BSS It may access all channels of multi-link setup It may have least restrictions regarding simultaneous transmit or receive operation AP has reliable NAV information of all links at all times Example for sharing NAV(link1) over link2 Submission Slide 6 Thomas Handte (Sony)

  7. February 2020 doc.: IEEE 802.11-20/0136r2 Proposal (2/3) Envisioned AP operation Once AP obtains NAV information of a link, it shares on the other link(s) as soon as possible AP could enforce restrictions on max. PPDU or TXOP length to limit sharing delay AP doesn t share if sharing delay exceeds NAV time that is to be shared Implementation of NAV sharing Frame of CTS-type ( multi-link CTS ) Pros: simple, well-known Cons: rare update if long TXOPs present, detection MCS depended Include multi-link NAV information in 11be PHY preamble (preferred) Pros: update every time an AP transmits 11be preamble, detection MCS independent Cons: need to compress NAV info, need BSS identifier in PHY preamble (could reuse BSS Color) Submission Slide 7 Thomas Handte (Sony)

  8. February 2020 doc.: IEEE 802.11-20/0136r2 Proposal (3/3) Envisioned STA operation STA listens on the primary channel of a link or on the multi-link primary channel STA obtains NAV for this link as usual STA obtains NAV for all other links based on shared NAV Before shared NAV of a link reaches zero, a STA shall either switch to that link and determine NAV as usual or stay on the current link and await new shared NAV information If STA decides to transmit on a link that doesn t include the currently observed primary channel, it should switch to that channel as early as possible and before shared NAV of that link reaches zero. Submission Slide 8 Thomas Handte (Sony)

  9. February 2020 doc.: IEEE 802.11-20/0136r2 Benefits Proposal avoids reception on multiple links at same time for NAV maintenance High power efficiency No impact of joint transmission and reception restrictions Single radio STAs may participate in and benefit from multi-link operation Enable fast transmission after link switching Shared NAV may reduce the waiting time before a non-observed channel may be accessed Robust NAV detection in frames that are transmitted in non-duplicate non-HE format AP can demodulate any PPDU format that is used in BSS If AP has restrictions for responding independently on different links [7,8], it may implement restrictions via shared NAV AP may alter shared NAV such that restrictions are fulfilled Submission Slide 9 Thomas Handte (Sony)

  10. February 2020 doc.: IEEE 802.11-20/0136r2 Simulation (1/3) Analysis of sharing delay and remaining NAV Remaining NAV is the value of shared NAV once it is shared, i.e. after sharing delay passed Simulation setup 2 links, fully asynchronous operation Link 1 shares NAV of link 2 Each link: 1 AP entity, 5 STAs, EDCA (best effort) No implementation delay, i.e. zero sharing delay between AP entities Link 1 Limits TXOP {3.2ms or 6.5ms} PPDU {2ms or 3ms} Mainly UL traffic (type of worst case scenario because AP entity transmits rarely) UL: full buffer traffic DL: BAck Link 2 Variable TXOP length between 0.5ms and 6.5ms (uniform distribution) Submission Slide 10 Thomas Handte (Sony)

  11. February 2020 doc.: IEEE 802.11-20/0136r2 Simulation (2/3) Sharing delay Preamble based vs. frame based NAV sharing Preamble based shows smaller sharing delay because AP entity has more opportunities to share NAV Sharing delay larger than respective limit in 10% of cases Caused by collisions May be avoided by trigger based channel access Submission Slide 11 Thomas Handte (Sony)

  12. February 2020 doc.: IEEE 802.11-20/0136r2 Simulation (3/3) Remaining NAV Remaining NAV smaller zero doesn t provide any benefit AP shares NAV only when remaining NAV>0 In case of preamble based sharing with PPDU limit of 2ms, AP shares NAV in 85% of the cases In case of frame based sharing with TXOP limit of 6.5ms, AP shares NAV in 45% of the cases Area of interest Submission Slide 12 Thomas Handte (Sony)

  13. February 2020 doc.: IEEE 802.11-20/0136r2 OBSS scenario NAV info of AP is not complete in OBSS scenario Shared NAV may differ from the NAV that a STA would obtain on a channel Potential solutions STAs may report NAV that has been set by a OBSS PPDUs to AP in order to improve shared NAV information (similar to [9]) Sharing delay may increase Reported NAV may not be applicable for all STAs of BSS APs share shared NAV info via multi-AP concepts Requires OBSS to be part of multi-AP group Reported NAV may not be applicable for all STA of BSS STAs may switch link early and listen for OBSS PPDUs May define a minimum listening time for STAs and links that are subject to OBSS interference Submission Slide 13 Thomas Handte (Sony)

  14. February 2020 doc.: IEEE 802.11-20/0136r2 Summary Virtual carrier sense is important in multi-link ~50% improvement in latency (50%ile), ~25% improvement in throughput [5] Maintaining NAV from multiple primary channels of multiple links has drawbacks Low power efficiency Not feasible if STAs have restrictions on simultaneous transmit or receive operation Proposal: Share NAV information among links On each primary channel of a link the NAV information of the other primary channel(s) of other link(s) is shared Sharing may preferably be implemented by NAV information within PHY preamble Main benefits High power efficiency, no restrictions on simultaneous transmit/ receive operation Simulation results Restrictions to TXOP length or PPDU length help to achieve small sharing delay Preamble based sharing with a max. PPDU length of 2 ms achieves successful NAV sharing in 85% of the cases Submission Slide 14 Thomas Handte (Sony)

  15. February 2020 doc.: IEEE 802.11-20/0136r2 References [1] 11-19/1291r3 Performance aspects of Multi-link operations [2] 11-19/1405r7 Multi-Link Operation Channel Access Discussion [3] 11-19/1541r1 Performance aspects of Multi-link operations with constraints [4] 11-19/1144r6 Channel Access for Multi-link Operation [5] 11-19/1930r2 AP assisted ML operation [6] 11-19/1526r1 Multi-Link Power-save [7] 11-19/1836r1 Multi-link Channel Access Discussion Follow-up [8] 11-19/1548r1 Channel access design for synchronized multi-links [9] 11-19/1918r0 UL MU efficiency enhancement using multi-link Submission Slide 15 Thomas Handte (Sony)

  16. February 2020 doc.: IEEE 802.11-20/0136r2 Straw Poll Do you support that an AP entity which is part of a AP MLD may transmit network state information of the other AP entities which are part of the same AP MLD? Note 1: Definition of network state information is TBD Note 2: R1 or R2 is TBD Submission Slide 16 Thomas Handte (Sony)

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#