Load balancing of a wireless network By: Vered Britshtein Shai Michaeli Boaz Aizenshtark Instructor: Erez Biton
Background Wireless LAN (IEEE 802.11) will probably become the most popular networking solution in years to come The spec describes the system in layer 2 (MAC), so the higher levels of management are not defined This leaves room for management entities which reside above level 2, but below level 3 (the IP layer)
802.11 introduction A layer 2 protocol, very much compliant with Ethernet 802.3 It’s main purpose is to dynamically and transparently connect mobile/stationary units to an Ethernet segment, though it can be used in other configurations as well There are two entities in an ESS (Extended Service Set – Ethernet connectivity in mortal language): 1. AP – Access Point – provides Ethernet connection to the WLAN (acts as a switch) 2. MU – Mobile Unit – the customer Basically, A mobile unit can be associated with any AP within range, but must be associated with only one at any given time
802.11 introduction – contd. 802.3 Ethernet segment AP A AP B MU4 MU2 Wireless connection Wireless connection MU4 To which AP should I go? MU2 MU3 MU1
Project goals The given topology: several AP’s which can communicate with each other, many MU associated with them randomly Divide the MU between the AP’s so the load on each AP is equal We define “Load” as a combination of different parameters – e.g. number of MU’s, current throughput, history
Implementation - flow A server queries the AP’s of the MU which are associated with it, the load, history etc. The server then runs a load balancing algorithm and finds the optimal distribution of the MU The server commands the AP to disassociate with selected MU, forcing the MU to re-associate with another AP
Implementation – flow example Server Allow MU2 to join Get rid of MU2! AP1 AP2 AP2 sucks! MU2 MU3 MU4 MU1
Implementation – details The server communicates with the AP’s using SNMP (Simple Network Management Protocol) The server will track each AP’s load and number of MU The server holds an image of the AP’s ACL (Access Control List)
Implementation - Server Load balancing Algorithm Database Server API To be implemented Implemented OS SNMP stack Ethernet
Implementation - Algorithm First we intend to implement a simple algorithm (balance the number of MU in each AP) Second, we will implement a more complex algorithm which will take into account other parameters. We did not yet decide on this algorithm
Algorithm – costs & benefits MU is not connected to the closest AP – we may damage the MU communication with the AP. We should consider that MU may have difficulties finding another AP – in that case, we may want the algorithm to do only assignments when a new MU arrives, but not reassignments (moving MU between AP’s). Reassignment time – when disconnecting a MU, we should consider the roaming time (how long will the unit stay disconnected). This is another calculation in favor of choosing an algorithm which does assignments only. Reassignment policy – we can either force a MU to a specific AP, or just force it out of a specific AP, allowing it to reassociate with any other AP
Algorithm – cons an pros Assignment only Reassignment allowed Simple Complicated Overhead – a MU will be re-assigned only once at maximum Overhead – each cycle many MU may be reassigned Not flexible – the load between the AP’s may be unbalanced Flexible – for each given network state we can choose the optimal distribution of MU
Implementation – statistics Statistics given of the AP are for the load calculating: Packets Seen: packets received on Ethernet interface Packets Sent: total packets sent out Any Collision: packets affected by at least one collision Current Mus: Specifies the current number of MUs associated with this AP. Information given on each MU: Current Transmit Rate:The current rate the AP transmits data to the station Packets Sent: The packets sent by the AP to the MU. Packets Received: The packets received by the AP from the MU. Bytes Sent: The bytes sent by the AP to the MU. Bytes Received: The bytes received by the AP from the MU.
Schedule Wireless ramp-up – 2 weeks – done Hardware ramp-up – 1 week – done SNMP ramp-up – 3 weeks – in progress Implement SNMP manager – 4 weeks Implement a simple algorithm – 2 weeks Implement a complex algorithm – 3 weeks