Hi Binita,
Thanks for the further comments and please see my responses embedded. All the changes should be reflected in R3 on mentor now.
BR,
Duncan
From: Binita Gupta <bingupta.ieee@xxxxxxxxx>
Sent: Monday, January 6, 2025 2:56 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-Seamless-Roaming
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Duncan,
Thanks for your efforts on revising the PDT draft and addressing my previous set of comments.
Attached please find my further comments on r01.
Hi Renlong,
Thanks for your comments. I agree with you if you translate the Motion literally. However, I believe the intention of the Motion is to say that the
serving AP MLD is allowed to tx DL fames to the non-AP MLD during the time between the Req and Resp as well so if we only capture the TBD after the response, it may not be clear whether the serving AP MLD is allowed to tx DL frames to the non-AP MLD between
the Req/Resp.
BR,
Duncan
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Duncan,
Thanks for the effort on the PDT.
I have a question on the text of "37.12.3 Roaming execution procedure [M#27, 44]",
The first paragraph includes:
"The current AP MLD may transmit individually addressed downlink Data frames to the non-AP MLD for a period
of TBD time. The period of TBD time starts from the time the TBD Request frame is successfully transmitted."
While the corresonding text in Motion 27 is as follows:
"after the request/response exchange that initiates notification of the DS mapping change from the current AP MLD to the target AP MLD,The current AP MLD may deliver buffered DL data
frames for a TBD period of time."
There is a clear difference in the starting point for calculating the TBD time between the PDT text and the Motion text.
The starting point in the Motion is defined as sending the TBD time after the Response frame, rather than immediately after the Request frame.
Thanks ,
Renlong
Original
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-Seamless-Roaming
Dear SR TTT members,
Happy New Year!
Thanks Mark, Mike and Guogang for your review of the draft and all your thoughtful comments. Much appreciated! I just uploaded the R1 of the PDT
here based on all the comments I’ve received so far.
Mark, I’ve addressed your comments in the attached “11-24-1881-01-011bn-PDT-mac-seamless-roaming-v5-mgr+DH” and “11-24-1881-00-00bn-pdt-mac-seamless-roaming-mgr+DH-mgr+DH”.
Guogang, I’ve addressed your comments in the attached “11-24-1881-00-00bn-pdt-mac-seamless-roaming-HGG+DH”,
Mike, I’ve added the “To be done” you suggested.
For the sentence about notifying the DS about the DS mapping change, I’m keeping it for now since “DS mapping change” is in the Motion and it is one
of the important aspects of seamless roaming. However, I do understand that we may need to modify it or add clarifications later as we have further discussion on the SR framework and DS mapping updates.
Thanks,
Duncan
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
- "The non-AP MLD may transmit Class 3 frames to the target AP MLD after receiving the TBD Response frame sent by the current
AP MLD." seems meaningless since "after" can mean a very long period and the non-AP surely will send class 3 frame after it moves under target AP. Maybe the intention is to use "when"?
[DH] The sentence specifies the EARLIEST time the non-AP MLD can transmit Class 3 frames so it seems correct to me. Are you saying some may interpret the “after” can mean a very long time (which is not specified)? That does not
seem like a natural interpretation of spec language. Note we cannot use “when” because at the time the Response frame is received, the non-AP MLD may or may not have frames to transmit immediately.
It would be clearer to express this as "The non-AP MLD shall not transmit Class 3 frames to the target MLD until
it has received the TBD Response frame."
- "In addition, by this time, the DS has been notified about the update of the destination mapping for the non-AP MLD if necessary,
from the currently AP MLD to the target AP MLD."
"by the time" is confusing since the sentence above uses "may" so there can be 2 possible cases.
[DH] This sentence is a bit problematic. I’ll try to reword it in the next revision of the draft.
This appears to be some kind of hidden "shall". The "shall" should be made explicit.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
Hi Haorui,
Thanks for your comments and please see my responses inline below.
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Thanks for the updated draft.
I have the below comment:
- "The non-AP MLD may transmit Class 3 frames to
the target AP MLD after receiving the TBD Response frame sent by the current AP MLD." seems meaningless since "after" can mean a very long period and the non-AP surely will send class 3 frame
after it moves under target AP. Maybe the intention is to use "when"?
[DH] The sentence specifies the EARLIEST time the non-AP MLD can transmit Class 3 frames so it seems correct to me. Are you saying some may interpret
the “after” can mean a very long time (which is not specified)? That does not seem like a natural interpretation of spec language. Note we cannot use “when” because at the time the Response frame is received, the non-AP MLD may or may not have frames to transmit
immediately.
- "In addition, by this time, the DS has been notified
about the update of the destination mapping for the non-AP MLD if necessary, from the currently AP MLD to the target AP MLD."
"by the time" is confusing since the sentence above uses "may" so there can be 2 possible cases.
[DH] This sentence is a bit problematic. I’ll try to reword it in the next revision of the draft.
Thanks,
Duncan
---- Replied Message ----
Hi Duncan,
Thanks for the update. I have two comments:
1) The text I added (To be done: Define the framework for seamless transition needs to be a placeholder in this contribution.)
2) I believe the following text is contentious and should not be included in this draft text at this time (pending the discussion
on framework above).
"In addition, by this time, the DS has been notified
about the update of the destination mapping for the non-AP MLD if necessary, from the currently AP MLD to the target AP MLD"
I would suggest that you delete it at this time.
Dear Seamless Roaming TTT members,
Thanks Mark, Binita, John, and Mike for all your good comments! I’ve
addressed them in the attached files “…-mgr+DH”
and “_bg_JRW-mm+DH”.
For the comments that I’ve accepted, I marked them
“resolved”
so they are hidden. For those comments that need more explanation and/or discussion, I’ve
embedded my responses.
All the changes are implemented in the attached v5 of the R1 draft.
I hope I’ve
resolved your comments satisfactorily. Please let me know if you have any further comments.
BR,
Duncan
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Duncan,
Thanks for starting this work. Attached are my comments posted on top of the latest document I could find in this thread.
This is the initial email for:
Proposed Draft Text for Seamless Roaming
As the PoC for Seamless Roaming, I have created the initial PDT document
11-24-1881r0 for Seamless Roaming. This document includes proposed text based on the motions up to and including the 2024 November IEEE 802 Plenary. We will update the PDT as additional motions are passed. The current version r0 is at a high level.
The author list in r0 is based on the 1:1 TTT requests received to me after the TGbn Chair’s
guideline to send TTT request to PoCs. The author list will be updated based on the list of members in the TTT for Seamless Roaming (about 70 members) mentioned in the document by Ross
11-24/1698r12. If you wish to be removed from the TTT or the current (and future) author list, please e-mail me at
dho@xxxxxxxxxxxxxxxx. I will update the author list accordingly in the next revised version (r1).
Please send any comments on the draft text (excluding the author list) in 11-24-1881r0
to this e-mail thread. This allows all TTT members to see and discuss your comments, facilitating debate on any changes to the document. This will be our general process for including text in the document.
At some point, as the group passes more motions to Seamless Roaming, we will try to find volunteers to create draft text sections
corresponding to those motions. Depending on the size/complexity of that text, it should appear for discussion
within this e-mail thread either as:
-
Text included directly in an email (for small additions/changes)
-
Text in a new WORD document sent as an attachment (not an official 802.11 submission)
-
Text in a copy of the 11-24/1881rx WORD document showing additions and changes, attached to the email thread.
We will aim to discuss any new proposed draft text within this thread and reach a super-majority agreement (e.g., 75% of the
TTT membership). However, even 75% is challenging due to the fluid nature of TTT membership. Deciding when to close the debate on new text will be a judgment call, typically when objections reduce to a small number (e.g., less than 25%, or about 15-20 people).
If objections persist, we may need to conduct a straw poll in TGbn and update our document 11-24-1881rx based on the outcome. Future text additions will follow a similar process, aiming for super-majority agreement.
Thank you for your cooperation.
P.S. credits go to Matthew Fisher/Sanket for the above great model instructions for PDT development. Not much black hair to
save but it’s saved me a ton of time
😊
BR,
Duncan
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
|