IP Library Granted Patent US 8,155,058
Granted Patent B2
US 8,155,058 · App. 12/363,611 · Granted Apr 10, 2012

Client balancing in wireless networks

View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 8,155,058
App. No.
12/363,611
Granted
Apr 10, 2012
Kind
B2
Abstract

Client balancing in a wireless digital network comprising a plurality of access nodes connected to a controller. Access nodes collect client density information and periodically report that client density information to the controller. The controller uses the client density information from the access nodes to compute Virtual RF Neighborhoods, identifying Virtual RF neighboring access nodes. Two access nodes are Virtual RF neighbors if a client which can connect to one access node can also connect to the other access node. The controller then identifies which nodes are overloaded by comparing the client loading of a target access node to the client loading of its Virtual RF neighbors. If an access node is identified as overloaded and selected for client balancing on a particular channel, it will initially refuse new association requests from client devices on that channel.

Claims (17)

1. A method of client balancing in a wireless digital network comprising a plurality of access nodes connected to a controller, the method comprising:

identifying a Virtual RF neighborhood for each of the plurality of access nodes connected to the controller, the Virtual RF neighborhood of one access node being a subset of a RF neighborhood of the one access node, the RF neighborhood of the one access node including one or more access nodes that hear beacons from the one access node;

using the Virtual RF Neighborhood information for a target access node to determine if the target access node is overloaded; and

enabling client load balancing on the target access node if the target access node is overloaded, the target access node being overloaded if a load on the target access node exceeds a load in the Virtual RF neighborhood by a first predetermined threshold, whereby the target access node initially rejects new association requests from a wireless client;

wherein the step of identifying the Virtual RF neighborhood comprises the steps of:

collecting for a predetermined period of time client density data in each of the plurality of access nodes connected to the controller,

sending the client density data from the each of the plurality of access nodes to the controller on a periodic basis, and

computing at the controller the Virtual RF neighborhoods for each of the plurality of the access nodes by: selecting the client density data for pairs of access nodes, and testing the pairs of client density data to see if the client density overlap between the pairs of client density data exceeds a second predetermined threshold, and identifying the pair of access nodes as Virtual RF neighbors if the second threshold is exceeded.

2. The method of claim 1 where the step of determining if an access node is overloaded comprises:

selecting, at the controller, an access node as the target node,

computing at the controller a loading figure for the target node and those nodes which are Virtual RF neighbors of the target node, and

enabling or disabling client load balancing on the target node based on the load figure of the target node in comparison to the load figures of other access nodes in the target node's Virtual RF neighborhood.

3. The method of claim 1 where the step of initially rejecting new association requests from a wireless client by the target node further comprises:

if the wireless client has been rejected two or more times by an access node connected to the controller, accept the client association request at the target node,

if the client has been rejected once by the target node and sends a further association request to the target node, accept the client association request to the target node, and

if the association request is the first one to the target node, reject the request.

4. The method of claim 3 where the step of rejecting the request further comprises signaling a “resource constrained” code in the rejection.

Assignments (4)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Apr 11, 2018
From: ARUBA NETWORKS, INC.
To: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP
Reel/Frame 045921/0055 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Aug 10, 2015
From: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.
To: ARUBA NETWORKS, INC.
Reel/Frame 036379/0274 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 3, 2015
From: ARUBA NETWORKS, INC.
To: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.
Reel/Frame 035814/0518 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Feb 6, 2009
From: IYER, PRADEEP; GANU, SACHIN
To: ARUBA NETWORKS, INC.
Reel/Frame 022220/0660 →