| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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:
·
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.
·
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.
·
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 |