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
From: Renlong Zhou <zhou.renlong@xxxxxxxxxxxxxxxx>
Sent: Sunday, January 5, 2025 7:29 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 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
From: DuncanHo <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2025年01月03日 07:01
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
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, December 23, 2024 6:01 AM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; 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.
- "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
From: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, 21 December 2024 01:14
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-Seamless-Roaming
Hi Haorui,
Thanks for your comments and please see my responses inline below.
From: Haorui Yang(Rae) <yanghaorui0217@xxxxxxx>
Sent: Monday, December 16, 2024 10:05 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 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
BRs,
Haorui Yang(Rae)
China Mobile
---- Replied Message ----
From
Date
12/17/2024 00:30
To
Subject
Re: [STDS-802-11-TGBN] PDT-MAC-Seamless-Roaming
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.
Cheers,
Mike
On Fri, Dec 13, 2024 at 11:59 PM Duncan Ho <dho@xxxxxxxxxxxxxxxx> wrote:
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
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, December 11, 2024 8:10 AM
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 starting this work. Attached are my comments posted on top of the latest document I could find in this thread.
Cheers,
Mike
On Fri, Nov 15, 2024 at 9:33 PM Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
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