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

[STDS-802-11-TGBE] 答复: Discussion on power save of AP MLD



Hi Brian,

 

Thanks for your discussion. Please find my response inline.

 

 

Regards

Guogang Huang

 

发件人: Brian Hart (brianh) [mailto:brianh@xxxxxxxxx]
发送时间: 202246 0:34
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussion on power save of AP MLD

 

Hi Guogang

 

Over the years, I’ve listened to lots of 802.11 discussions along the following lines:

 

  1. Individual writes some normative text such as “<preamble> AP <midamble> non-AP STA <postamble>”
  2. Commenter say “Why say ‘non-AP STA’ when only a non-AP STA can perform midamble/postamble? Just say STA”
  3. Group agrees to adopt “<preamble> AP <midamble> STA <postamble>”

 

In that light, I’m troubled by your choice to reuse the non-AP STA “power save” term for AP power save. I suspect the only way to do this safely is to carefully review the 3000+ pages in clauses 3-14, 26, and 34 and, every time we find a reference to “power save” in connection with “STA”, decide if this language:

  • Needs to be narrowed to “non-AP STA”
  • Can continue as “STA” (and now means both AP and non-AP STA)
  • Needs to be rewritten to allow some AP-related cases but exclude other AP-related cases.

… where in several / many cases, different experts might reasonably disagree about the right way forward.

[Guogang Huang] What we are talking about the AP power save should be AP MLD power save. And I don’t change the baseline, the legacy AP still doesn’t support the power save. For the current text on non-AP STA power save, we don’t need to make any change.

 

As a random example, consider: 9.6.12.6 “The TDLS Peer Traffic Indication Action field indicates the state of the power save buffer at the STA supporting TPU that is buffering data for a TDLS peer STA in power save mode.” This probably should be rewritten to apply to non-AP STAs only.

[Guogang Huang]For this example, I don’t think the text is ambiguous. Because it is TDLS.

 

Then there is the dual problem: there is a lot of language that assumes that only one party ? AP or non-AP STA ? needs to perform a task. Would this language need to be generalized to include the counterparty, with a similarly large potential scope of text needing review and a positive decision to change or not change the text:

 

As another random example, consider: 11.2.1, “A non-AP STA can be in one of two power management modes: - Active mode …” Here I think you’ll have to rewrite this language to account for both AP and non-AP STAs.

[Guogang Huang]Currently, I think it’s better to add a subclause 35.3.X AP MLD power save.

 

I haven’t done the work, so I’m not sure if we’re talking one or ten or a hundred or a thousand instances, but I wouldn’t be surprised if it was well over a hundred instances. I could imagine this might take an extended period of personal review time, then many hours or days of IEEE group time to review and debate the resulting work. In that light, can you share if you’ve started / completed this kind of analysis, and what is the ballpark ultimate number of pages of change-text that you foresee?

 

The alternative of course is to define a new and narrower term for “AP power save”. That alternative seems to have the benefit of not requiring such a broad and detailed analysis.

[Guogang Huang]It’s better to define as AP MLD power save.

 

Comments / contrasting opinions?

 

Best wishes

Brian

 

From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 30, 2022 9:01 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on power save of AP MLD

 

Hi all,

 

I have presented my contribution 22/356r5 in the call. But there is no time to take questions. I initiate this email thread to further discussion for doc 22/356. Please let me know your questions and comments.

 

 

Regards

Guogang Huang


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