Re: [STDS-802-11-TGBF] CC40 CR for MLME

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

Thank you Ali for your response. However, I respectfully do not agree with your view point.

I fail to understand why it is ok to have “inconsistent” (w.r.t. the signaling shown in 11-41i) signaling between the two MACs. IMHO it is much clearer to show the exact signaling between the MACs and mention that one of the NDPs is not for sensing in the first two boxes. Even one does not need to refer to such text, rather one can infer it from the figure, since there is no report being generated for such cases.

Multiple MS setup Req and Resp are, in some sense, error or uncommon scenarios (probabilistic/depend on certain factor(s)). We should show the signaling for the most common scenario.

I do not see any no harm in showing the consistent signaling. I do not understand why we do not want to show it. Is it to make less clutter in the figure? Or is there a technical reason for it?

thanks and regards

-Anirud

Anirudha (Anirud) Sahoo (He/Him)

https://sites.google.com/view/a-sahoo

National Institute of Standards and Technology

Wireless Networks Division

Communications Technology Lab

100 Bureau Drive, Stop 6730

Gaithersburg, MD 20899

Ph: 301-975-4439

From: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Sent: Saturday, September 17, 2022 8:07 PM
To: Sahoo, Anirudha (Fed) <anirudha.sahoo@xxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: CC40 CR for MLME - Part 1

Hi Anirud, as I have tried to explain it Rajat during last week’s meeting, the SME/MLME interface/diagram shouldn’t care about how many frame exchanges (or direction of it) occur between two MACs to obtain the needed feedback (in this case report). In fact the transmission of request(s)/Response(s) *i.e. MS setup Request/Response) may occur many times due to retransmissions but we don’t show it in the associated diagram. Bottom line, I think the current diagram seems to be sufficient as it conveys the required exchange. And BTW, we’d discussed this issue once before and that was the direction that Naren to capture the diagram as shown. Of course, we can always bring it back up but my thinking is that such details are already in the normative section (i.e. 11.x.x.x) anyway so there should not be any ambiguity regardless.

Regards,

Ali

From: Sahoo, Anirudha (Fed) <00001823ca88828f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, September 16, 2022 3:57 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] CC40 CR for MLME - Part 1

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Naren,

I have the following concerns about the Non-TB case (Fig. 6-28b) in the document.

In box 1 and 2, we are hiding (not showing) one NDP transmission. For example, in box 1 SR2SI NDP is not shown. This makes it inconsistent with the actual signaling (as per NTB MI shown in Fig. 11-41i in D0.3). According to Naren, it is done this way to show the differences among the three variants of NDPA sounding (the top three boxes). But IMHO, we should not make the MLME diagram “inconsistent” with the actual signaling that happens.
The way the text for Fig. 6-28b is written, it talks about “if the sensing responder is assigned the role of receiver only .. blah blah.. “, but in the Figure it does not say in which box the responder is rcvr only. So, it is hard to “connect” the corresponding text to the appropriate box.

I suggest to address the above two concerns as follows.

There is no need to “hide” one NDP to bring out the differences among the three variants. In fact, the differences can be noticed by looking at when/how sensing report is generated. So, we should put the “hidden” NDPs back in box 1 and 2 and be consistent with the actual signaling. And then in the text we can say something like “in box 1 responder is rcvr only and hence, the SR2SI NDP is not used for sensing”. Similarly for box 2.
In the figure, we probably should indicate the role(s) of the responder in the boxes (or figure out some other way of pointing to the three cases/boxes), otherwise, it will be hard to “connect” the text to the figure.

thanks and regards

-Anirud

Anirudha (Anirud) Sahoo (He/Him)

https://sites.google.com/view/a-sahoo

National Institute of Standards and Technology

Wireless Networks Division

Communications Technology Lab

100 Bureau Drive, Stop 6730

Gaithersburg, MD 20899

Ph: 301-975-4439

From: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx> On Behalf Of narengerile
Sent: Friday, September 16, 2022 6:22 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Cc: Hanxiao (Tony, WT Lab) <tony.hanxiao@xxxxxxxxxx>
Subject: CC40 CR for MLME - Part 1

Hello TGbf friends

I’ve uploaded a revised version r3 of the CR document for MLME part 1 on the server: https://mentor.ieee.org/802.11/dcn/22/11-22-1365-03-00bf-cc40-cr-for-mlme-part-1.docx

All the modifications compared to r2 are indicated by edits. Both figures and texts are revised.

Please let me know if you have any comment or question. Any feedback is welcome.

Thanks,

Naren

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