Split Mac Architecture Enterprise-Class Wireless LAN

Source: Internet
Author: User
Tags require switches

To meet the real-time requirements of WLAN networks, designers can refer to a segmented media access control (MAC) architecture introduced in this article to allocate MAC processing tasks between the access point and the central switch, and greatly improve the ability and security of WLAN systems to manage wireless resources.

WLANs increase the efficiency of enterprise networks and reduce the overall cost of network deployment and operations. However, wireless networks also pose management and security challenges for network managers. The key to a successful deployment of a wireless network is that IT managers gain control of the wireless domain just as they would control a wired network.

Wired networks rely on user authentication and physical access to the network to achieve access, while wireless networks require a strong authentication and encryption means. Because wireless domains are dynamic and are changing at any time, wireless networks are also a challenge in terms of operations. Wireless network operators must overcome these challenges if they want to deploy operating-level wireless networks.

A key design and deployment principle of wireless networks is the centralization of monitoring, control, and finger-pointing functions. The practice has proved that centralization is the best way to develop and implement uniform policies for a large number of network devices, whether they are concentrated in the same physical location or dispersed in different geographical areas.

A centralized WLAN architecture to be effective, the relevant information must be continuously fed to the central device (such as WLAN switches/devices) that manages the network. If there is no overall, accurate and update speed to the millisecond level of the wireless Environment state information, the central device can not make accurate decisions. At the same time, if the central controller participates in all access point operations, it may affect those features that are particularly sensitive to timing. Therefore, a balance must be sought among them.

One solution to the centralized architecture balancing problem is to provide a new 802.11 service delivery design that splits the processing tasks of the 802.11 mac layer between the two devices (the AP and the Central WLAN switch/device). Here we'll explore this Mac partitioning approach and its benefits for WLAN architecture. (Computer science)

Building an enterprise-class WLAN

The traditional WLAN consists of countless individual AP, they produce a lot of independent, autonomous RF domain, and these RF domains are managed alone. This is much like the initial cellular network, where each individual wireless receiving and sending tower manages their respective domains. Similarly, in a stand-alone 802.11 network, all Mac processing tasks are performed by the AP itself. For example, an AP can perform:

* Terminate 802.11 data and management protocols (note: Many management tasks come from switches/devices);

* Converting data between the wired and wireless parts of the network;

* Maintain statistical information about the client and wireless environment;

Maintaining information within a single wireless node makes it difficult to create a unified network that provides stable network performance, high performance roaming, and regardless of user location to ensure policy consistency. Finally, it is difficult for IT managers to manage each access point as a separate RF domain, especially as the size of the wireless network expands.

The centralized WLAN architecture overcomes the above drawbacks by centralizing system-wide information into a single switch/device, or concentrating on multiple coordinated switches/devices. Most scenarios, however, centralize all of the functionality into one central device, which means that various tasks and processes occur within the switch or device, including traffic forwarding, encryption, quality of service (QoS), and policy creation and management. In this architecture, the AP is just a wireless transceiver antenna that has no effect on 802.11 or other packet processing. The problem with this architecture is that all processing decisions are determined by the central device, can it handle real-time applications?

A WLAN system with a split Mac can solve the above problem by separating the processing tasks of the 802.11 data and management protocols from the AP and the WLAN switch or controller (see Figure 1).

Figure 1: A typical split Mac architecture schematic diagram.

With this method, the AP only deals with the protocol parts with real-time requirements, such as the sending of beacon frames, the "probing request (Probe Requests)" Frame from the client, the real-time signal quality information for the switch or controller, monitoring the appearance of other AP and the second layer encryption, etc.

All other features are handled by WLAN switches/devices because they are insensitive to time and require system-wide visibility. Some of the MAC layer features provided by WLAN controllers include: 802.11 authentication, 802.11 association and Re-association (mobility), 802.11 frame conversion and bridging.

Centralize the 802.11 management protocol, frame conversion, and bridging functionality into a central switch/device to achieve the specific information needed to collect the controller for system-wide management, such as network RF information, or seamless roaming between second and third tier clients.

Intelligent RF Management

A segmented Mac architecture can greatly improve the ability of WLAN systems to manage wireless resources. In the AP to provide monitoring functions can be real-time detection of RF changes (such as reception signal strength, signal quality, channel allocation and noise, etc.). This information is then fed to a centralized WLAN controller to provide decision support for optimizing WLAN performance. For example, a single WLAN switch or device can dynamically allocate channels, allocate bandwidth, and control AP transmission power across the enterprise network.

Successful RF management requires a "holistic" approach. If the information resides only within the AP, RF management decisions about the device may actually adversely affect the entire WLAN system. For example, reducing the transmission power of the AP may cause coverage vulnerabilities elsewhere. Similarly, increased transmission power may cause interference.

In addition, only the system-wide approach can be used to multiplex the channel to avoid noise and interference from one part of the network. If the RF management decision is made by a single AP, the problematic channel may be completely discarded, and in some cases using partial channels is beneficial to the overall network performance. By creating a centralized RF management "authority", the split Mac architecture can solve real running problems in real time

Real-time Load balancing

Traditional WLAN generally uses one of the following two methods to deal with mobility:

1. The AP communicates the load information to each other in a peer-to-peer manner, and the "best" AP is responsible for responding to client requests.

2. The AP broadcasts the load information directly to the clients responsible for autonomous decision-making.

Both of these methods have obvious flaws. The first method increases the flow of the WLAN, which consumes bandwidth and increases latency. If the AP has a delay in sharing information, it may make inaccurate load-balancing decisions or may encounter performance problems with time-sensitive traffic. In addition, this approach makes decisions in an ideal state, ignoring security, QoS, user mobility patterns, and other useful parameters that can make more accurate decisions on a system-wide basis.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.