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

Re: [STDS-802-11-TGBE] Some concern for DCN 1255r5 and 1256r3



Hi Laurent, didn’t get a chance to send this before the SPs; can be done after D0.1.

Payam

 

From: "Yang, Zhijie (NSB - CN/Shanghai)" <zhijie.yang@xxxxxxxxxxxxxxx>
Reply-To: "Yang, Zhijie (NSB - CN/Shanghai)" <zhijie.yang@xxxxxxxxxxxxxxx>
Date: Saturday, September 26, 2020 at 5:21 PM
To: "STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx" <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] Some concern for DCN 1255r5 and 1256r3

 

Hi Laurent,

 

I see you delete the last case in the definition of MLD probe request format in 1255r5. Since there is no motion on this point, it will be an open topic.

For the format of an MLD probe request, is it possible to delete the first bullet and only keep the second one? I think MLD probe request can be identified by the probe request carrying ML IE(or keep the sentence as TBD signaling ).

That’s to say, the probe request will be thought as normal probe request if not carrying ML IE. Otherwise, it will be thought as MLD probe request, and some specific information can be contained in ML IE of probe request if non-AP MLD wants to get some profiles of the AP MLD.

 

Anyway, I think the second bullet is enough to cover my ideas and identify the MLD probe request. What’s your take on this?

33.3.2.2 MLD Prob

An MLD probe request is a Probe Request frame:

  1. with the Address 1 field set to the broadcast address, the Address 3 field set to the BSSID of an AP, or with the Address 1 field set to the BSSID of an AP, or other addressing TBD.
  2. and that includes a TBD signalling that identifies that the Probe Request frame is an MLD probe request and that identifies which APs of the AP MLD are requested.

 

 

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: 2020916 14:50
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] Some concern for DCN 1255r4 and 1256r3

 

Hi Laurent,

 

I agree with Jay Yang’s comment.  The paragraph (33.3.4.1.3) didn’t pass motion indeed. Obviously, some members have technical concern on it.

 

Although you left that thing open (unless TBD), it still will cause other people misunderstanding. So I think it’s better to remove that paragraph from the PDT text.

 

 

Regards

Guogang Huang

 

发件人: Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
发送时间: 2020916 14:18
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi Laurent,

 

From your clarification, I think you also confirm there is no motion on MLD probe request concept , actually, I don’t know why we need such concept. And I’m also shocked why you can define it in the draft version since there is no baseline at all.

 

I’m not object to what you did, my intention is that we could make everything clear in the first draft version. I hope I can get your understanding.

 

If you still repeat it’s no need to do further discussion since the SP is passed unanimously, I won’t make any comment on this. It’s decided by the group.

 

I found the same issue on your another contribution(1256/r3). I’m also confused why we define the following strange behavior like this.  If you want to set up a another mail loop to talk it,

I would like to do it. If you persist the SP is passed, I think it’s no need to do it according to your intention.

 

33.3.4.1.3 Power state after enablement

When a link becomes enabled for a STA that is part of a non-AP MLD through multi-link setup sent on that link, the initial power management mode of the STA, immediately after the signaling exchange, is active mode.

When a link is enabled for a STA that is part of a non-AP MLD through signaling (multi-link setup or TID to link mapping update) send on another link, the initial power management mode of the STA, immediately after the exchange, is power save mode, and its power state is doze, unless TBD.

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Sent: 2020916 11:00
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Jay,

Every document is going slightly beyond what has been agreed, as you obviously add details when drafting the spec text. Otherwise, we would just stay with the SFD.

That’s why we have a review process on their spec documents, as this is what will be the spec in the end.

We always try and highlight what’s agreed and what’s additional, and I did that when I presented multiple times the document, and there were no objections, as people were seeing that it made sense or that it was fully in line with the agreed motions. You’ll have to admit that my documents are very in line with what has been agreed, compared to first revisions of other ones that are being proposed. That is fine, people can propose details, and if it is not agreeable, then we put a TBD and we discuss it later. When we pass the SP though, that means we agree with the content.

 

I’m glad you agree on the procedure. That’s the one we follow.

We’ll progressively work on the spec on no longer on the spec framework document, so you’ll see many proposals going through spec review. You’ll also be able to comment on the spec if you see something that is wrong or should be improved or to propose the definition of a new solution. So you’ll have plenty of opportunities to comment/modify/propose, but the process will progressively change.

 

In the future, please review carefully every document before it is SPed because it acts as agreement, as the entire document.

 

Finally, the paragraph you mention below is part of another document, I don’t know why you include that in this thread (I’ve talked with the people who also commented late on that and they are fine with it. You’ll note that it includes a TBD in there because when I presented that in the contribution before there was a debate on the part that is TBD, for the rest, the group was ready to accept and that’s what happened. The fact that there is a TBD means that this will be discussed, and we’ll need agreement from the group to remove the TBD or adding something instead of the TBD.

 

 

Thanks

Laurent

 

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Tuesday, September 15, 2020 6:20 PM
To: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Subject: RE: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi Laurent,

 

The procedure your mentioned is correct, I agree with it. As you know, there are mess PDT documents, I can’t review all of them before the meeting.

Based on my understanding, all description in the PDT should follow the referenced motion and SP, correct? But I can’t find them in your contribution. I’m confused whether we still insist the basic rule to define the SPEC.

For the no motion _expression_ in PDT, is it possible to highlight them so that we could pay more attention on them?

For the MLD probe request format, I hope the group can achieve some agreement first other than we think it’s possible or impossible.

 

 

I believe there is no SP or motion on the following _expression_, correct?

 

33.3.4.1.3 Power state after enablement

When a link becomes enabled for a STA that is part of a non-AP MLD through multi-link setup sent on that link, the initial power management mode of the STA, immediately after the signaling exchange, is active mode.

When a link is enabled for a STA that is part of a non-AP MLD through signaling (multi-link setup or TID to link mapping update) send on another link, the initial power management mode of the STA, immediately after the exchange, is power save mode, and its power state is doze, unless TBD.

 

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Sent: 2020916 8:56
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi Jay,

You are aware that this doc passed SP with unanimous consent, and you had the opportunity to raise any issues for quite some time before this happened.

If we run SP and then everybody comes back after and asks to change the agreement, we will never finish this project, as we’ll never build on agreements. I’m therefore very reluctant in making changes like this, as it’s setting a precedence that I think you’ll agree it not great.

Note also that this is D0.1 and that there is still a very long way to go and many revisions and everytime you and all members will have the opportunity to raise issues and improve this.

 

Now, if we have to make a small change to doc 1255 as an exception, I’m trying to see with the chair and Editor what can be done to make addressing TBD.

I’ll get back to you on this.

 

For the sentence you highlight below: those are already 3 possible ways to do addressing to send a probe.

 

Thanks,

Laurent

 

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Tuesday, September 15, 2020 7:58 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi Laurent,

 

I didn’t find any reference SP or motion in your document 1255/R4 on the MLD probe request signaling, could you explain why we define it like this?

 

An MLD probe request is a Probe Request frame:

  1. with the Address 1 field set to the broadcast address, the Address 3 field set to the BSSID of an AP, or with the Address 1 field set to the BSSID of an AP, or with the Address 1 field set to the broadcast address, the Address 3 field set to wildcard BSSID and the SSID field set to the SSID of an AP

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: 2020910 16:54
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hello Laurent

 

Thanks for your replay. The key point is that AP can only send the MLD Probe Response frame with “broadcast address” in Address 1 field after it receives a MLD Probe Request frame. It seems we disallow the MLD Probe Response frame with “individual address” in Address 1 field. Please refer to the following text in your document

 

If an AP that is part of an AP MLD receives an MLD Probe Request from a non-AP STA, it shall respond with an MLD probe response, which is a Probe Response frame with the Address 1 field set to the broadcast destination address that includes an ML element with a STA profile with complete information for each of the APs that are affiliated to the same AP MLD as the AP and that are requested by the MLD probe request.

 

Moreover, regarding MLD Probe Request frame, the relationship among those combinations is not clear (a few “or”), it seems we only allow the following 3 settings with different color. Is there any restriction here? If no, could we just say follow the exiting baseline or copy baseline text here. Otherwise, we should have more discussion for this part.

 

An MLD probe request is a Probe Request frame:

  1. with the Address 1 field set to the broadcast address, the Address 3 field set to the BSSID of an AP, or with the Address 1 field set to the BSSID of an AP, or with the Address 1 field set to the broadcast address, the Address 3 field set to wildcard BSSID and the SSID field set to the SSID of an AP
  2. and that includes a TBD signalling that identifies that the Probe Request frame is an MLD probe request and that identifies which APs of the AP MLD are requested.

 

Best wishes

Ming Gan

 

发件人: Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
发送时间: 2020910 0:30
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi,

Address 1 field set to BSSID is also covered (highlighted in yellow).

Thanks

Laurent

 

An MLD probe request is a Probe Request frame:

  1. with the Address 1 field set to the broadcast address, the Address 3 field set to the BSSID of an AP, or with the Address 1 field set to the BSSID of an AP, or with the Address 1 field set to the broadcast address, the Address 3 field set to wildcard BSSID and the SSID field set to the SSID of an AP
  2. and that includes a TBD signalling that identifies that the Probe Request frame is an MLD probe request and that identifies which APs of the AP MLD are requested.

 

 

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Wednesday, September 9, 2020 1:07 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi Laurent,

 

I have the same concern with Ming, individual MAC address in Address 1 field in Probe Request/ Response is extensively used according to current SPEC, why do we change it in 802.11be SPEC?

 

Thanks

 

Best Regards

 

Jay Yang

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: 202099 15:30
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hi Laurent,

 

Ming also sent an email to you. Maybe  you missed it.

 

 

Regards

Guogang Huang

发件人: Ganming (Ming) [mailto:ming.gan@xxxxxxxxxx]
发送时间: 202091 21:02
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Some concern for DCN 1255r4

 

Hello Laurent,

 

I checked DCN 1255r4 again. Although the sp passed,  I found my previous comment was not reflected. I would like to confirm your intention for the following text with red color in 1255r4. Why is Address 1 field always set to broadcast address for ML Probe Request and Probe Response frames? Can we allow individual (unicast) MAC address in Address 1 field in Probe Request/ Response frame?

 

An MLD probe request is a Probe Request frame:

  1. with the Address 1 field set to the broadcast address, the Address 3 field set to the BSSID of an AP, or with the Address 1 field set to the BSSID of an AP, or with the Address 1 field set to the broadcast address, the Address 3 field set to wildcard BSSID and the SSID field set to the SSID of an AP
  2. and that includes a TBD signalling that identifies that the Probe Request frame is an MLD probe request and that identifies which APs of the AP MLD are requested.

 

An MLD probe request allows a non-AP STA to request an AP to include the complete set of capabilities, parameters and operation elements of other APs affiliated to the same AP MLD as the AP (Motion related text). It is TBD how the complete information of an AP affiliated to the same AP MLD as the AP identified in the Address 1 or Address 3 field of the Probe Request frame is requested.

The complete information of a requested AP sent by a reporting AP is defined as all elements that would be provided if the requested AP was transmitting the Probe Response frame, except the following elements, if present: the Reduced Neighbor Report element, the Multiple BSSID element, the ML element, other exceptions TBD.

 

If an AP that is part of an AP MLD receives an MLD Probe Request from a non-AP STA, it shall respond with an MLD probe response, which is a Probe Response frame with the Address 1 field set to the broadcast destination address that includes an ML element with a STA profile with complete information for each of the APs that are affiliated to the same AP MLD as the AP and that are requested by the MLD probe request.

 

 

Best wishes

Ming Gan

 

发件人: Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
发送时间: 2020831 8:45
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconferences [08/31/2020]: Agenda Posted

 

Hi Alfred,

Please put 1255 and 1256 in the agenda for SP on spec text for D0.1 for Monday August 31st.

Thanks,

Laurent

 

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Sunday, August 30, 2020 10:08 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] TGbe Teleconferences [08/31/2020]: Agenda Posted

 

Hello all,

 

I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Monday, August 31 (MAC/PHY), 19:00-22:00 ET.

 

The agendas can be found here:

The dial in details can be found in the IEEE 802.11 calendar in their respective entries. The calendar can be accessed from this webpage.

 

PS 1: Guidelines for scheduled PHY conf calls:

1.       Every time the agenda is sent the TG chair will ask if there are any submissions requests to be added to the PHY submissions queue. Requests can be regarding new submissions or regarding submissions with deferred SPs.

2.       Requests may explicitly indicate if the requestor prefers to discuss his/her submission at a particular PHY conf call. If there is no such explicit indication then the submission will be added by default to the PHY submissions queue and will be scheduled for presentation in a subsequent PHY conference call during which there are at least 3 submissions available for discussion.

3.       A scheduled PHY conference call will be cancelled if the planned PHY agenda for that particular conference call does not have queued at least 3 presentations or at least one presentation with an explicit request. The cancellation notice in this case will be sent at least 24 hours in advance.

PS 2: Please send requests for any deferred SPs that need to be added to the agendas at least 24 hours prior to the start of the conference call (same applies to the upload of submissions present in the agenda and that contains a SP, however in this case no explicit request is needed). Deadline for uploading the initial version of a submission present in the agenda is 7 days prior to that conference call.

 

Please let me know if you have any questions and/or suggestions.

 

Best Regards,

 

Alfred

 

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302


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


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


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


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


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


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

Attachment: 11-20-1255-05-00be-pdt-mac-mlo-discovery-discovery-procedures-including-probing-and-rnr-pt.docx
Description: 11-20-1255-05-00be-pdt-mac-mlo-discovery-discovery-procedures-including-probing-and-rnr-pt.docx