Coordinated Roaming Proposal for IEEE 802.11 Networks

 
 Coordinated Roaming through Target AP MLD
 
Date:
 2024-02-26
 
February 2024
 
Binita Gupta et al (Cisco Systems)
 
Slide 1
 
Authors:
 
Introduction
 
UHR 
is aiming to provide improved support for roaming. Several 
roaming
proposals have highlighted seamless roaming operation through the current
serving AP MLD [1-4].
 
In [1] we presented a proposal for seamless roaming within a mobility domain
through the current serving AP MLD.
 
In this presentation, we extend that proposal to achieve coordinated roaming
through the target AP MLD, for the cases when roaming through the serving
AP MLD may not be possible.
 
Slide 2
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
Problem Statement
 
In Wi-Fi networks, there can be sudden RSSI drops (e.g.
due to concrete walls, elevator metal shaft etc.), leading to
connectivity disruption.
Also, a STA can be in sleep mode and not scanning, and
when it comes out of the power save mode then its RSSI
with serving AP has dropped significantly.
In such cases, STA can’t perform seamless roaming
through its (old) serving AP MLD. STA needs to quickly
roam to a target AP MLD to maintain connectivity.
For such scenarios, 11bn must define improved roaming
through coordination between the target AP MLD and the
serving AP MLD.
Here we propose a mechanism for coordinated roaming
through the target AP MLD.
 
February 2024
 
Binita Gupta et al (Cisco Systems)
 
Slide 3
 
Solution Considerations
 
Solution for coordinated roaming through a Target AP MLD should meet
following considerations:
Provide data continuity and preserve context
Similar to seamless roaming through serving AP MLD, solution should preserve data exchange context to
provide data continuity and preserve other control plane context/agreements to minimize reestablishment
of those context.
Feasibility across deployments
Solution should not mandate requirements (e.g. data transfer) which may not be supported/feasible in all
types of deployments. Some data loss will happen if data can’t be transferred.
Unified roaming architecture and signaling
Solution should be built upon the same roaming architecture as used for seamless roaming through the
serving AP MLD and should leverage same set of roaming signaling defined.
 
 
 
Slide 4
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
Roaming through the Target AP MLD (1)
 
We assume same roaming architecture as in [1] where a non-AP MLD establishes s single secure
association with an SMD (Seamless Mobility Domain) covering multiple AP MLDs
Same keys (PMK, PTK) are shared across AP MLDs. This enables a non-AP MLD to exchange PMF
protected roaming signaling with the Target AP MLD, without first requiring to establish a new PTK.
Sharing same keys enables better roaming experience through a target AP MLD. After roaming is completed,
PTK rekeying is initiated to generate a new PTK for the target AP. The old PTK is shared by the target AP
MLD only for a short period of time.
We also note that:
Roaming through serving AP MLD is strongly preferred and will provide more reliable and deterministic
roaming experience - minimal interruption and zero/minimal data loss (with dual DL path during roaming).
Decision to roam through a target AP MLD is made by the non-AP MLD based on RSSI and other factors and
may not necessarily be limited to only when the RSSI suddenly drops.
We consider two cases:
Case 1:
 Roaming through Target AP MLD when no roaming prep was done in advance with serving AP MLD
Case 2: 
Roaming through Target AP MLD when roaming prep was done in advance with serving AP MLD
 
 
 
Slide 5
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
Roaming through the Target AP MLD (2)
 
Case 1: Roaming through Target AP MLD, w/o
advance roaming preparation
STA sends Link Reconfiguration Request to target
AP MLD and signals old serving AP MLD
The frame is sent as PMF protected
Target AP MLD fetches keys (PMK, PTK) for the
non-AP MLD (if not already installed), and uses to
process received Link Reconfiguration Request
Target AP MLD requests context transfer (SN, PN,
BA, agreements)
Target AP MLD may optionally support & request
data transfer from serving AP MLD
Target AP MLD initiates DS mapping update and
sends Link Reconfiguration Response
Note: Same roaming signaling is used as for the
roaming through a serving AP MLD.
 
 
 
Slide 6
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
Roaming through the Target AP MLD (3)
 
Case 2: Roaming through Target AP MLD,
with advance roaming preparation
Roaming preparation phase (steps 1-4) done in
advance to transfer near static contexts (e.g.
agreements, capabilities) to candidate Target AP
MLDs. Keys (PMK, PTK) for the non-AP MLD are
fetched, if not already installed.
STA selects one of the target AP MLDs where
roaming prep was done. Roaming execution steps
though the target AP MLD are same as in case 1.
Roaming execution (steps 6-9) is much faster:
Keys already installed; most context already transferred.
Only dynamic context (SN, PN, BA) need to be
transferred. Optionally data may be transferred.
Note: Same roaming signaling is used as for the roaming
through a serving AP MLD.
 
 
 
 
 
 
 
Slide 7
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
Data Transfer Considerations
 
To minimize data loss, it would be desirable to transfer data from old serving AP MLD to target AP MLD.
However, transferring data would require high throughput connection between all AP MLDs. Based on the
backhaul capability, this may or may not be supported in all deployments.
Furthermore, it is not straightforward to take out and transfer MPDUs buffered deep in the hardware queue.
It is much easier to transfer buffered MSDUs/A-MSDUs.
Hence requirement for data transfer need to be optional, based on these considerations.
Selective data transfer (e.g. MSDUs/A-MSDUs for specific TIDs or SCS flows) may be done either based
on the request from the non-AP MLD or determined by the AP MLDs
 
 
 
Slide 8
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
Summary
 
We highlighted that a non-AP MLD may not always be able to perform seamless roaming
through its serving AP MLD
We proposed a mechanism for coordinated roaming through the target AP MLD
It provides data continuity by transferring data exchange context, and preserves other control plane context
Roaming through target AP MLD is faster with the roaming preparation phase done (in advance)
Data transfer can be optionally (and selectively) done to minimize data loss, if supported by AP MLDs
We noted that sharing same keys (PMK, PTK) is strongly desirable to achieve better/seamless
roaming experience through a target AP MLD.
We also noted that still Roaming through the serving AP MLD is strongly preferred and will
provide more reliable and deterministic roaming experience. When that is not possible, the
roaming through target AP MLD can be done.
 
 
Slide 9
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
SP1
 
Do you agree to define a mechanism in 11bn that enables a non-AP MLD to
initiate roaming through a target AP MLD it roams to, where the target AP
MLD initiates context transfer from the previous serving AP MLD to the
target AP MLD such that the data exchange context is preserved for the
non-AP MLD?
 
 
Slide 10
 
Binita Gupta et al (Cisco Systems)
 
February 2024
 
References
 
[1] 11-23-2157 “Seamless Roaming within a Mobility Domain”
[2] 11-22-1910 “Seamless Roaming for UHR”
[3] 11-23-1996 “
Improve roaming between MLDs”
[4] 11-24-0052 “
Seamless Roaming Details”
 
Slide 11
 
Binita Gupta et al (Cisco Systems)
 
February 2024
Slide Note

doc.: IEEE 802.11-yy/xxxxr0

Month Year

John Doe, Some Company

Page

Embed
Share

This document presents a proposal for coordinated roaming through target AP MLD in IEEE 802.11 networks to address connectivity disruptions due to sudden RSSI drops or STA transition scenarios. The solution aims to ensure data continuity, preserve context, and minimize data loss during roaming handovers. Feasibility considerations and unified roaming architecture are key aspects highlighted in the proposal.


Uploaded on Jul 02, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. February 2024 doc.: IEEE 802.11-24/398r0 Coordinated Roaming through Target AP MLD Date: 2024-02-26 Authors: Name Binita Gupta Affiliations Cisco Systems Address San Diego, CA, USA Phone email binitag@cisco.com brianh@cisco.com Brian Hart Cisco Systems mmsmith@cisco.com Malcolm Smith Cisco Systems juzuniga@cisco.com Juan Carlos Zuniga Cisco Systems sorr@cisco.com Stephen Orr Cisco Systems jerhenry@cisco.com Jerome Henry Cisco Systems Submission Slide 1 Binita Gupta et al (Cisco Systems)

  2. February 2024 doc.: IEEE 802.11-24/398r0 Introduction UHR is aiming to provide improved support for roaming. Several roaming proposals have highlighted seamless roaming operation through the current serving AP MLD [1-4]. In [1] we presented a proposal for seamless roaming within a mobility domain through the current serving AP MLD. In this presentation, we extend that proposal to achieve coordinated roaming through the target AP MLD, for the cases when roaming through the serving AP MLD may not be possible. Submission Slide 2 Binita Gupta et al (Cisco Systems)

  3. February 2024 doc.: IEEE 802.11-24/398r0 Problem Statement In Wi-Fi networks, there can be sudden RSSI drops (e.g. due to concrete walls, elevator metal shaft etc.), leading to connectivity disruption. Also, a STA can be in sleep mode and not scanning, and when it comes out of the power save mode then its RSSI with serving AP has dropped significantly. In such cases, STA can t perform seamless roaming through its (old) serving AP MLD. STA needs to quickly roam to a target AP MLD to maintain connectivity. For such scenarios, 11bn must define improved roaming through coordination between the target AP MLD and the serving AP MLD. Here we propose a mechanism for coordinated roaming through the target AP MLD. TargetAP STA s RSSI drops Serving AP Binita Gupta et al (Cisco Systems) Submission Slide 3

  4. February 2024 doc.: IEEE 802.11-24/398r0 Solution Considerations Solution for coordinated roaming through a Target AP MLD should meet following considerations: Provide data continuity and preserve context Similar to seamless roaming through serving AP MLD, solution should preserve data exchange context to provide data continuity and preserve other control plane context/agreements to minimize reestablishment of those context. Feasibility across deployments Solution should not mandate requirements (e.g. data transfer) which may not be supported/feasible in all types of deployments. Some data loss will happen if data can t be transferred. Unified roaming architecture and signaling Solution should be built upon the same roaming architecture as used for seamless roaming through the serving AP MLD and should leverage same set of roaming signaling defined. Submission Slide 4 Binita Gupta et al (Cisco Systems)

  5. February 2024 doc.: IEEE 802.11-24/398r0 Roaming through the Target AP MLD (1) We assume same roaming architecture as in [1] where a non-AP MLD establishes s single secure association with an SMD (Seamless Mobility Domain) covering multiple AP MLDs Same keys (PMK, PTK) are shared across AP MLDs. This enables a non-AP MLD to exchange PMF protected roaming signaling with the Target AP MLD, without first requiring to establish a new PTK. Sharing same keys enables better roaming experience through a target AP MLD. After roaming is completed, PTK rekeying is initiated to generate a new PTK for the target AP. The old PTK is shared by the target AP MLD only for a short period of time. We also note that: Roaming through serving AP MLD is strongly preferred and will provide more reliable and deterministic roaming experience - minimal interruption and zero/minimal data loss (with dual DL path during roaming). Decision to roam through a target AP MLD is made by the non-AP MLD based on RSSI and other factors and may not necessarily be limited to only when the RSSI suddenly drops. We consider two cases: Case 1: Roaming through Target AP MLD when no roaming prep was done in advance with serving AP MLD Case 2: Roaming through Target AP MLD when roaming prep was done in advance with serving AP MLD Submission Slide 5 Binita Gupta et al (Cisco Systems)

  6. February 2024 doc.: IEEE 802.11-24/398r0 Roaming through the Target AP MLD (2) Case 1: Roaming through Target AP MLD, w/o advance roaming preparation STA sends Link Reconfiguration Request to target AP MLD and signals old serving AP MLD The frame is sent as PMF protected Target AP MLD fetches keys (PMK, PTK) for the non-AP MLD (if not already installed), and uses to process received Link Reconfiguration Request Target AP MLD requests context transfer (SN, PN, BA, agreements) Target AP MLD may optionally support & request data transfer from serving AP MLD Target AP MLD initiates DS mapping update and sends Link Reconfiguration Response Note: Same roaming signaling is used as for the roaming through a serving AP MLD. Serving AP MLD Target AP MLD STA UL/DL data 1. STA RSSI drops Select target AP MLD to roam 2. Link Reconfiguration Request (target AP MLD, old serving AP MLD, SMDE) 3. Fetch PMK and PTK keys (if not already installed) 4a. Roaming context transfer (SN, PN, BA, agreements etc.) 4b. Initiate DS mapping update 4c. (optional) data transfer 5. Link Reconfiguration Response (status, Group keys, AID) UL/DL data Submission Slide 6 Binita Gupta et al (Cisco Systems)

  7. February 2024 doc.: IEEE 802.11-24/398r0 Roaming through the Target AP MLD (3) Serving AP MLD Target AP MLD STA Case 2: Roaming through Target AP MLD, with advance roaming preparation Roaming preparation phase (steps 1-4) done in advance to transfer near static contexts (e.g. agreements, capabilities) to candidate Target AP MLDs. Keys (PMK, PTK) for the non-AP MLD are fetched, if not already installed. STA selects one of the target AP MLDs where roaming prep was done. Roaming execution steps though the target AP MLD are same as in case 1. Roaming execution (steps 6-9) is much faster: Keys already installed; most context already transferred. Only dynamic context (SN, PN, BA) need to be transferred. Optionally data may be transferred. Note: Same roaming signaling is used as for the roaming through a serving AP MLD. UL/DL data Roaming prep. Phase (done in advance) 1. Link Reconfiguration Notify (requested target AP MLDs, SMDE) 2. Roaming context transfer (near static context/agreements, capabilities) 3. Fetch PMK and PTK keys (if not already installed) 4. Link Reconfiguration Notify (candidate target AP MLDs, SMDE) 5. STA RSSI drops Select a target AP MLD to roam 6. Link Reconfiguration Request (target AP MLD, old serving AP MLD, SMDE) 7a. Roaming context transfer (dynamic context e.g. SN, PN, BA) 7b. Initiate DS mapping update 7c. (optional) data transfer 8. Link Reconfiguration Response (status, Group keys, AID, SMDE) UL/DL data Submission Slide 7 Binita Gupta et al (Cisco Systems)

  8. February 2024 doc.: IEEE 802.11-24/398r0 Data Transfer Considerations To minimize data loss, it would be desirable to transfer data from old serving AP MLD to target AP MLD. However, transferring data would require high throughput connection between all AP MLDs. Based on the backhaul capability, this may or may not be supported in all deployments. Furthermore, it is not straightforward to take out and transfer MPDUs buffered deep in the hardware queue. It is much easier to transfer buffered MSDUs/A-MSDUs. Hence requirement for data transfer need to be optional, based on these considerations. Selective data transfer (e.g. MSDUs/A-MSDUs for specific TIDs or SCS flows) may be done either based on the request from the non-AP MLD or determined by the AP MLDs Context transfer Serving AP MLD Target AP MLD Data transfer (optional/selective) Link Reconfig Req/Resp RSSI drops Non-AP MLD Submission Slide 8 Binita Gupta et al (Cisco Systems)

  9. February 2024 doc.: IEEE 802.11-24/398r0 Summary We highlighted that a non-AP MLD may not always be able to perform seamless roaming through its serving AP MLD We proposed a mechanism for coordinated roaming through the target AP MLD It provides data continuity by transferring data exchange context, and preserves other control plane context Roaming through target AP MLD is faster with the roaming preparation phase done (in advance) Data transfer can be optionally (and selectively) done to minimize data loss, if supported by AP MLDs We noted that sharing same keys (PMK, PTK) is strongly desirable to achieve better/seamless roaming experience through a target AP MLD. We also noted that still Roaming through the serving AP MLD is strongly preferred and will provide more reliable and deterministic roaming experience. When that is not possible, the roaming through target AP MLD can be done. Submission Slide 9 Binita Gupta et al (Cisco Systems)

  10. February 2024 doc.: IEEE 802.11-24/398r0 SP1 Do you agree to define a mechanism in 11bn that enables a non-AP MLD to initiate roaming through a target AP MLD it roams to, where the target AP MLD initiates context transfer from the previous serving AP MLD to the target AP MLD such that the data exchange context is preserved for the non-AP MLD? Submission Slide 10 Binita Gupta et al (Cisco Systems)

  11. February 2024 doc.: IEEE 802.11-24/398r0 References [1] 11-23-2157 Seamless Roaming within a Mobility Domain [2] 11-22-1910 Seamless Roaming for UHR [3] 11-23-1996 Improve roaming between MLDs [4] 11-24-0052 Seamless Roaming Details Submission Slide 11 Binita Gupta et al (Cisco Systems)

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#