2
Votes

Sequential Band Startup Logic to Eliminate Manual Intervention and "Sticky Client" Issues

 
2
Votes

Sequential Band Startup Logic to Eliminate Manual Intervention and "Sticky Client" Issues

Sequential Band Startup Logic to Eliminate Manual Intervention and "Sticky Client" Issues
Sequential Band Startup Logic to Eliminate Manual Intervention and "Sticky Client" Issues
a week ago - last edited a week ago
Tags: #Deco App #WebUI #Deco BE63
Model: Deco BE63  
Hardware Version: V2
Firmware Version: 1.2.10 Build 20251229 Rel. 42008

 

To the TP-Link Engineering and Product Team,
 

I would like to submit a formal technical proposal to optimize the recovery process of Deco Mesh systems (specifically high-density Wi-Fi 7 models like the Deco BE63) following a scheduled or manual reboot.


The Problem: The "Initial Association Trap" and Required Manual Intervention Currently, when a Deco unit reboots, all radio bands (2.4GHz, 5GHz, and 6GHz) are initialized and broadcasted simultaneously. Due to its superior physical penetration and faster discovery, the 2.4GHz signal is almost always the first to be captured by client devices.

This creates the "Sticky Client" phenomenon, where WI-FI 7/6E/6/5 ready devices associate with the 2.4GHz band just to regain immediate connectivity. This results in two critical failures:

  1. Algorithmic Strain: The Band Steering and Roaming processes must work unnecessarily hard to attempt migrating these clients later, often causing initial network instability.

  2. The Manual Burden: In high-density environments, the automated steering often fails to move these clients to the optimal band. This forces the user to perform tedious manual intervention—toggling Wi-Fi on each device or manually assigning bands in the App to restore the network to its peak state. For a network with 40+ devices, this is a significant and unnecessary maintenance chore that contradicts the "seamless" promise of the Deco line.
     

The Proposal: Tiered/Sequential Radio Activation I propose a firmware-level logic change where radios are initialized in descending order of performance to allow hardware-based "self-sorting" during the association phase:

  • Phase 1: 6GHz Activation. Initialize the 6GHz radio first. This allows Wi-Fi 7 and 6E devices to claim the cleanest spectrum immediately without interference.

  • Phase 2: 5GHz Activation (30-45s delay). Initialize the 5GHz band. Modern high-speed devices that lack 6GHz will associate here.

  • Phase 3: 2.4GHz Activation (Final stage). Finally, enable the 2.4GHz band for IoT and legacy devices.


Technical Benefits:

  • Zero-Touch Optimization: Clients are sorted into their optimal bands by their own hardware capability from the moment of association, eliminating the need for manual user intervention.

  • Reduced Logic Overhead: By ensuring high-performance clients are off the 2.4GHz band from the start, the system avoids the "churn" and logging noise associated with late-stage Band Steering.

  • Enhanced UX: The network achieves an "Optimal State" immediately upon recovery, rather than a "Suboptimal State" that requires user correction.


While I understand that "fast recovery" of the Wi-Fi icon is a priority, a "Smart Recovery" through sequential activation is the only way to ensure stability in modern, heterogeneous high-density environments.


I look forward to seeing this logic considered for future firmware updates.
 

Best regards,
Nelson Lora

#1
Options
1 Reply
Re:Sequential Band Startup Logic to Eliminate Manual Intervention and "Sticky Client" Issues
a week ago

  @Nelson_Lora 

 

This actually sounds like a great idea. 

I actually have a couple of Epson printers that automatically grab onto the 2.4 Ghz band upon Deco startup, whilst the Deco is literally right next to them.  These printers should actually grab onto the 5Ghz band for much better bandwidth and cleaner signal, but they don't since they are stuck on 2.4 Ghz from when the Decos first boot up.

 

I wonder if there are any technical challenges to implementing a phased wi-fi boot up or something like this that you are talking about.  Seems only the TP-Link firmware engineers may be able to provide us the answer to this question.

#2
Options