Hi, Binita,
Thanks for tackling this! I have some comments on your presentation, and a comment on the question below (and these are all related).
I have a similar question to the one below. From what I can see in Figure xx2 versus Figure xx3, the difference seems to be an implementation detail, and not an architecture difference. The only real difference between these figures is whether the “SMD Upper MAC Sublayer 2” is handling the distribution of DL data from the DS to the AP MLDs, or not. (The rest of the operation of the SMD Upper MAC Sublayer 2 – handling authentication/association, keys, etc., - seems to be the same, right?) So, the difference is really a question of whether the DS itself is “distributed” into the SMD Upper MAC Sublayer, per Figure xx3 – and this is an implementation detail of how the DS is built not an architectural difference. Note that, within 802.11, we have a very narrow _architectural_ view of the DS, and we intentionally don’t get into these discussions about how/whether the DS function is “distributed” or collected into a single entity – those details are left open to implementation, and there are lots of different implementations in real-world deployments.
This leads to similar comments I have on the overall approach in the submission:
- Do we all have agreement that a mobility domain (FT) is necessarily a subset (could be equal to) an ESS? And, do we have agreement that an SMD is a subset of an FT mobility domain? If we have agreement so far, then I would propose that seamless roaming is an optimization of FT, to reduce signaling and delay. Do we have agreement on this?
- Perhaps this is a nit, but perhaps it is important to our terminology and clarity in our discussions: In our architecture, the DS is _not_ an upper layer to 802.11. The DS is a service _used_ by APs (through the DSAF) and the Portal for distribution of data frames, and it is within the 802.11 scope. We need to be careful about where 802.11 interacts with “upper layers” (above it), versus the fact that the DS could be implemented using what we all know as upper layer protocols, but where that is an implementation detail inside the “black box” that is the DS. I’ve copied an architecture picture from the baseline (802.11be), which perhaps helps:
- Related, we also have this in 802.11-2024, where the concept of the DS and ESS are first introduced (emphasis is mine):
“The key concept is that the ESS appears to be a single IEEE Std 802™ access domain to the LLC sublayer. STAs within an ESS can communicate and mobile STAs might move from one BSS to another (within the same ESS) transparently to the LLC sublayer.”
- That is, we model transitions within 802.11, explicitly, as being invisible to the upper layers. Details, like needing to “train the switches”, are implementation details of how the DS itself may be designed, and are not part of how 802.11 provides service to an upper layer.
- Also, of particular note, it is not possible within 802.11 architecture (being very strict) for a non-AP STA’s IP address to change as it moves within the ESS. And, further, a Reassociation is by definition within the same ESS. Thus, at a Reassociation, the IP address cannot change.
- That said, I realize that there are real implementations which don’t quite fit the architecture, and allow a “Reassociation” to happen (literally, accept a Reassociation Frame) when changing ESSs (and therefore upper layers could see the transition, and the IP address could change). So, real-world client implementations have found it necessary to check their IP Address assignment upon transition, as a way to determine if they have in fact changed ESSs and need to take appropriate corrective action to continue end-user session continuity.
- I would strongly suggest that we avoid this with seamless roaming, however. The whole point of seamless roaming is to optimize the case where context is _known_ to be preserved, and the parts of the overall “context” that have the biggest impact on client roaming are the upper layers having (transparent) session continuity. If the upper layers need to do any recovery, or even if they need to check to see if recovery is needed, then there is little point in putting much effort into optimizing the Layer 2 context (security keys, etc.), as the end-user will experience session discontinuity anyway. So, I think we want to reinforce the architectural concept that an SMD is where roaming can be done that is truly transparent to the upper layers.
- Another nit, but Figures xx2 and xx3 are mixing up data plane and management plane a bit, in that it appears that the data plane (for example, the links between the DS and the MAC SAPs in Figure xx2) are going through the SMD-ME. I’d be happy to help with this, off-line.
Mark
From: 杨云朋 <0000390f890e7d9e-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, 24 July, 2025 3:48
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] Request to queue 25/1238 - Seamless roaming CR for clause 4
Dear Binita：
Thank you for preparing this Draft.
Please find my comments as below:
1．Could you please explain in detail the differences between Sublayer1 and Sublayer2?
2．Why in the centralized SMD mode, the MAC-SAP is on Sublayer 2, while in the distributed SMD mode, it is on Sublayer 1?
Best regards 祝工作顺利！
===========================================================
Philip Yang 杨云朋
Mail: yangyunpeng@xxxxxxxxxxxxxx
Tel: +86 15620949838
发件人: Binita Gupta <bingupta.ieee@xxxxxxxxx>
发送时间: 2025年7月24日 16:27
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBN] Request to queue 25/1238 - Seamless roaming CR for clause 4
Hi Alfred,
Could you please queue following document in the MAC queue:
- 25/1238: CR for seamless roaming clause 4
All - please review and provide any comments you have on this doc.
Thanks,
Binita
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