| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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> 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:
Thanks Best Regards Jay Yang From: huangguogang <huangguogang1@xxxxxxxxxx> 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]
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>
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>
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>
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>
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:
Thanks Best Regards Jay Yang From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
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:
Best wishes Ming Gan 发件人:
Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
Hi, Address 1 field set to BSSID is also covered (highlighted in yellow). Thanks Laurent An MLD probe request is a Probe Request frame:
From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
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>
Hi Laurent, Ming also sent an email to you. Maybe you missed it. Regards Guogang Huang 发件人:
Ganming (Ming) [mailto:ming.gan@xxxxxxxxxx]
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:
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]
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>
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