Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] Request to queue 25/1238 - Seamless roaming CR for clause 4



Hi Mark,

Thank you for your detailed feedback and much appreciated! 
I will work with you offline to revise the proposed reference models per some of your feedback below.

Please also see my responses inline below.

Thanks,
Binita

On Fri, Jul 25, 2025 at 10:08 AM <mark.hamilton2152@xxxxxxxxx> wrote:

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?) 


<BG> You are right that the main difference between the two architectures is whether the SMD Upper MAC Sublayer 2 in the SMD-ME is handling DL/UL data from/to DS to AP MLDs. Other functions of handling authentication/association, keys, etc remain same for both modes.
 

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. 

 
<BG> Not sure I get the part of your comment on whether the DS itself is distributed. In distributed mode, each AP MLD has a MAC-SAP to the DS and in centralized mode, there is a single MAC-SAP to the DS for entire SMD. In my thinking, the concept of DS is the same for both cases. In which architecture are you saying that DS is distributed and how? 
 

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.

 

<BG> From 802.11 architecture PoC, the key difference is a single MAC-SAP to the DS vs multiple MAC-SAP to the DS. We do need to capture that difference, and it is not an implementation detail as we have discussed in past. It is part of architecture design for each mode.

 

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? 

<BG> Yes, there is general agreement that an ESS can consists of one or more FT MD and each FT MD can consist of one or more SMDs. ESS can also have SMDs without FT MD deployted.
 
  • 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?

<BG> See above. An ESS can have only SMDs deployed or can have both FT MD and SMDs deployed. 
 
  • 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:


<BG> Thanks for this picture, it is helpful to understand DS as s service involved by APs through DSAF and the Portal. This remains pretty much same as shown here for distributed SMD mode, where each AP MLD invokes the DS service. For centralized SMD mode, the SMD-ME entity would invoke the DS service for distribution of data through SMD MAC-SAP and SMD level Portal. 

 

  • 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). 
<BG> Do we have requirement in the spec that Reassociation "shall not" be used when changing ESSes? Looks like if that is there then implementations must not accept Reassociation frames when changing ESSes. Is this something that needs to be fixed in the baseline?

 
    • 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.
<BG> Is it really about changing ESSes? When doing FT, the ESS remains the same per baseline standard, since APs in an FT MD are part of the same ESS. When doing a Full Auth roaming then Yes ESS can change. So, I am bit confused with this analysis of STA behavior. Per FT, STAs can assume that they are moving to the same ESS and hence don't need to check IP address assignment? Need to better understand currebt STA behavior related to IP address assignment and why?
    • I would strongly suggest that we avoid this with seamless roaming, however. 
<BG> Again, with FT given that roaming is within the same ESS and per baseline if mobility within an ESS needs to be transparent to upper layers, then STAs do not need to check for IP address change for FT. Looks like we might need more clarity on this aspect in the baseline too. 

Having said that, fI agree for seamless roaming it does make sense to maintain IP continuity so upper layer sessions are not disrupted. In many cases though upper layers can recover from IP address change as well. So, I assume for FT it was never mandated to maintain IP continuity and left to implementations.

    • 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. 
<BG> I understand your point. Most desired is to maintain IP continuity within SMD. But based on your argument, are you implying that FT roaming optimization has no benefit if IP address continuity can't be maintained. 

    • 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.
<BG> Looks like this is the direction many members prefer and I totally agree that it provides the best end-user experience. My main concern was that since this was not required in FT, are there deployments constraint that need to be accounted for here? We should get input from other members that have more visibility into deployment aspects. 

  • 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.

<BG> Thanks, and yes we could further improve these figures. This was my first quick attempt. Happy to work with you offline on improving these. 

 

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:

 

1Could you please explain in detail the differences between Sublayer1 and Sublayer2?

 

2Why 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>
发送时间: 2025724 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