Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] 11-20/1045: "prioritized EDCA channel access" discussion



Hi, Graham:

 

Sorry the late replay. Thanks for your questions and sharing your thoughts.

See inline.

 

Thanks.

Chunyu

 

From: Graham Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Thursday, August 27, 2020 9:43 AM
To: chunyuhu07@xxxxxxxxx; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-20/1045: "prioritized EDCA channel access" discussion

 

I read with interest your 20/0408 and 20/1045 presentations. Forgive me for coming in late and for not hearing the original presentations and maybe I have not understood the proposal well.  I spent a lot of time in the past on QoS, EDCA, HCCA, Video and Voice.  I will start by stating that EDCA has served for over 15 years – its problem has always been that it is self- policing.  I spent some time proving that too many devices simply cheat.  Used correctly it might do better.

 

I also spent much time working with HCCA, which is uses an HC, and it was proved that it worked very well and increased the efficiency and throughput of networks.   The requirement for a TSPEC is often seen as a ‘problem’, but the TSPEC is a way to clearly define the QoS requirement.    So , splitting the time into allocated and free is not new. 

 

I want to make sure I understand your proposal.  The AP advertises the Slot Duration and number of slots, plus the EDCA parameters that can be used in the “priority slots”. Then STAs request assignments of slots.  The AP then advertises the allocations and timing. 

Contrast this with HCCA.  STAs request allocations based upon a set of parameters that describe their QoS requirements (TSPECs).  The AP/HC grants the allocations and advertises the schedule.  At allocated time, AP/HC starts the HCCA TXOP, if no traffic, or ends early, AP/HC releases the medium.  AP/HCs can negotiate with overlapping AP/HCs so as not to allocate over each other. 

 

On the face of it, your slotted scheme is very similar to HCCA where the AP/HC grants the allocations and advertises the schedule.  I can’t see in your presentation  how the STAs request their slots or the negotiation, but I would assume it is, or could be, very similar to the ADDTS scheme.  A major problem for Wi-Fi and QoS is OBSS and I would draw your attention to the work carried out in 11aa.  11ax should have sorted out Spatial Reuse better but in 11aa overlapping APs can exchange their allocations and negotiate if they have to share.  This is important in my view.

 

[Chunyu:] there is some similarity as you pointed out. One subtle but critical difference here is that, the scheme enables a STA to compute/request the resources it needs. The scheduling decision takes into account a more distributed input.
In HCCA / TSPEC-based admission control solution, the model is that STAs raises requirement, and AP grants with promised delivery. In practice, many reasons make this ‘promise’ and centralized computation  very difficult, if possible at all, esp. in real-time fashion and a dynamic wireless medium where a large range of operating range is defined per Wi-Fi technology.

The proposed scheme (pEDCA for short) doesn’t attempt to solve all the problem. But we try to improve in a few aspects:

  1. If a STA understands its application well, it can make an attempt to compute the resources (airtime in slots) it needs. It doesn’t necessarily require AP to “promise” requested QoS.
  2. It doesn’t require schedule before transmitting and tolerate mis-calculation in ‘scheduling’. If P-traffic overflows requested slots, it still can be transmitted as regular traffic. Vice versa, if the P-traffic in an interval completes early, the medium can be auto released to regular traffic.

In addition, one thing that helps the design of pEDCA is that, we specifically optimize for the mix of a type of traffic pattern (bursty, periodic) with regular traffic.

 

So for some specific basic questions:

  • What are the procedures for STAs to be allocated slots, how many and how often?  I suggest that the TSPEC should be used as a template for the parameters required.

 

[Chunyu:] Yes, TSPEC can be a template used.

I also think that for slot assignment/grant purpose,  parameters as specified TSPEC element are not quite directly useful – they are more like good-to-know (but what I’m gonna do about it …).

Information like Mean/Peak data rate might be useful for AP to monitor and policy the over-allocation of slots.

This is next level of details we can continue to work on.

 

  • Do you intend for overlapping APs to negotiate and share in a controlled manner?

 

[Chunyu:] The design leaves room for extension into an inter-BSS coordination scheme. Overlapping AP can negotiate the P-slot assignment. Might be more efficient to share in a group of P-slots fashion to avoid time being too fragmented.

It certainly requires all STAs including APs understand and comply to the protocol requirement if that’s what you mean by  “a controlled manner.”

 

  • Can you show that this slotted scheme is better than HCCA? 

 

[Chunyu:] In what aspect? Performance? Flexibility? Design/implementation complexity?

If you have specific traffic scenarios / KPIs to compare, we can try using our simulation. Architectural kind of evaluation including practicality, complexity, can be difficult to demo at this point. But I do believe this is a more practical approach for Wi-Fi technology to satisfy RTA requirement as well as serving regular traffic.

 

  • In HCCA if no traffic in the allocated TXOP, the HC releases the medium immediately.  In your slotted scheme I assume that STAs note that traffic has ceased and contend again.  Is the concept of a TXOP still maintained, i.e. the AP starts the TXOP in the slot or the STA simply takes it?

 

[Chunyu:] in pEDCA, STAs still obey CCA (physical as well as virtual/NAV) rules. STAs are still required to contend the medium even they are member of a P-slot. We don’t want to lose the listen-before-talk principal.

AP or the owner of P-slot can use whatever suitable NAV protection as they are doing now. 11ax provides more tools such as trigger-based frame sequences that a non-AP STA can let AP take responsibility of initiating the txop.

 

  • How reliant is this on the STAs accurately using the random back off?  STAs are still policing themselves.  One advantage of HCCA is that the AP starts the TXOP every time and hence controls the medium. Does the slotted scheme have this same advantage or is it still at the mercy of STAs using advantageous settings?

 

[Chunyu:] in pEDCA, AP can do so as well if AP and the non-AP STA agree to use the trigger-based frame exchange, e.g. but in case not, we count on the protection mechanism described in pEDCA:

  1. More aggressive EDCA parameter (P-EDCA params)
  2. The principal and rules described in slides 8-12.

 

I am not a regular 11be attendant so I would be grateful if you could let me know when this will be next discussed.

 

[Chunyu:] no problem, thanks for your interest. We were given 10 mins for Q/A in last Wed (08/26)’s meeting. I can schedule an offline meeting with you, and/or anyone else who are interested in.

 

Thanks

Graham

 

From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Sent: Wednesday, August 26, 2020 12:09 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-20/1045: "prioritized EDCA channel access" discussion

 

Hi, all:

 

Starting a thread for Q/A for the doc 11-20/1045r3 to cover remaining Q/As.

I captured Jay, Mohamed, Liangxiao, and Sharan. Other please also feel free to ask questions here or send me separate emails.

 

Thanks.

Chunyu


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1