WLAN产品形态之分层架构

随着移动互联网时代的来临,无线数据流量呈现爆发式增长,各大运营商也越来越多依靠WLAN来承载这些无线数据流量,大规模进行WLAN网络建设,分担3G网络的压力,让客户体验更加美好、无处不在的优质无线网络服务。百万规模的WLAN网络建设,对于网络架构提出了新的要求。针对上述需求,分层AC架构应运而生。一、WLAN产品架构背景介绍

随着无线网络的不断发展,WLAN产品构架形态的演变主要经历了三个时期。

1. Fat AP架构

Fat AP是传统的WLAN组网方案,AP本身承担了用户认证、漫游切换、用户数据加密、QoS、网络管理等复杂功能,相对来说AP的功能较重因此称为Fat AP。

 



图1 Fat AP组网方案

 

Fat AP产品的管理平面、控制平面、数据平面都集成在同一个系统中,这种架构非常适用于简单小型无线网络部署。缺点是网络规模大的情况下,较难集中管理。2. AC+Fit AP架构

AC+Fit AP架构相对于Fat AP架构,新增无线控制器(AC)作为中央集中控制管理设备,原先在Fat AP自身上承载的用户认证、漫游切换、动态密钥等复杂功能转移到无线控制器,AP与AC之间通过隧道方式通信,可以跨越L2、L3网络甚至广域网进行连接,大大提高了整网的工作效率。

 



图2. Fit AP组网方案

 

AC+Fit AP架构具有更强的适应性,能够支持不同规模的无线网络部署。Fit AP仅提供数据与控制平面的部分功能,剩下的另一半数据与控制平面功能以及全部管理平面功能由AC完成。AC与Fit AP间通过CAPWAP隧道传递控制与数据报文。以最终用户的视角来看,Fit AP可视为AC的远端Radio。AC+Fit AP架构能够提供更为专业和丰富的无线功能,可适用于大型无线网络,相对于Fit AP架构来讲,解决了Fat AP难于集中管理的问题。此外,这周架构具有三层漫游、基于用户下发权限优势功能。缺点是往往AC和AP需要跨越广域网通信,需要消耗更大的链路带宽和保证低时延,同时也会出现诸如用户认证慢、漫游性能低下等问题。3. 有线无线一体化架构

当前,大数据及云计算已得到了广泛应用,其需要网络具有非常强大的计算能力和实时业务处理能力,而AC+Fit AP架构面对这种需求也显得力不从心。因此,有线无线一体化分层架构应运而生。这种架构在AC+Fit AP分层基础上升级,进一步将AC功能拆分,使网络层次变为网络控制层、本地控制层和物理层。其中,网络控制层提供专业的有线无线控制功能,主要负责全网集中控制管理业务、大数据量及大计算量的非实时性业务及全网数据共享业务;本地控制层提供有线无线一体化的本地控制管理功能,主要负责本地业务处理以及实时性的跨AP业务;物理层则提供底层实时性业务,主要负责单一设备节点的实时性业务及无线报文收发。

 



图3. 分层组网方案

 

综上所述,有线无线一体化分层架构可以支持超大规模有线无线一体化网络部署,从而能够更好地为大数据及云计算等新兴应用提供服务。二、分层架构解析

WLAN产品架构形态朝着分层架构的方向发展,从最初的Fat AP的单一层次架构演变为AC+Fit AP的两层架构,直到有线无线一体化分层架构,逐渐演变成了由网络控制层、本地控制层和物理层组成的三层架构。1. 网络控制层

网络控制层主要负责统一管理下发配置、版本升级、集中认证、整网数据管理等;对设备的计算能力要求较高,因此既可以是传统的高性能物理AC,也可以是以软件形态运行于服务器上的虚拟AC;如果将虚拟AC运行在公有云之上,则可以称之为云AC;2. 本地控制层

本地控制层主要负责本地认证、CAPWAP隧道终结、漫游等;本地控制层采用一体化的用户策略,同时支持有线及无线用户接入网络,本层设备可以根据实际应用场景不同进行不同的选择,既可以是普通AC,也可以是集成多种业务功能的All In One设备,例如支持路由、DPI、交换机等。3. 物理层

物理层对应的设备即AP,主要负责无线报文收发及单一节点的实时性业务,例如:攻击检测、信道扫描、逐包功率调整、本地数据转发等。三、分层AC架构的组网及特点

1. 分层AC之组网形态

分层AC架构主要由Central AC、Local AC、AP三层组成,适用于总部和分支机构场景或大型企业网络。在这种情况下,Central AC和Local AC之间可能存在Internet广域网,也可能处于网络的不同层次(例如Central AC位于核心层,Local AC处于接入层)。

 



图4 分层AC架构基础组网图

 

Central AC,分层AC架构中的Central AC负责其它Local AC和AP的无线相关配置,收集整网无线相关信息,对用户呈现统一管理界面。根据用户配置,Central AC可以只负责管理方面的工作(如配置无线参数或网管接口),也可以负担无线客户端的认证相关功能(如Portal认证)。由于Central AC通常层次较高,所以一般不负担无线客户端的数据转发。Local AC,Local AC可以与Central AC组成AC池,也可以作为独立AC位于接入层或用户侧。此时的Local AC一般会同时集成多种业务功能(All In One),例如支持路由、DPI甚至是交换机的功能。因此,Local AC的形态多种多样,根据实际应用场景不同,可以选择不同款型不同功能的Local AC。2. 分层AC之技术特点

统一管理,Local AC及AP的无线配置和版本文件均由Central AC集中下发,Central AC、Local AC及AP之间建立控制隧道连接,可以将相关配置信息统一下发至其它Local AC和AP上,大大简化了网络配置工作量。另外,在Central AC上会保存当前整网AC、AP及终端的信息,因此管理员能集中查看整网无线信息,运维相对简单;认证方式灵活,分层AC架构下可以灵活选择认证点,既支持集中认证也支持分布式认证;集中认证时由Central AC负责客户端认证,认证服务器只需和Central AC进行交互,管理一个NAS IP即可;如果Local AC处有认证服务器,也可以由Local AC负责客户端认证,实现分布式认证;高可靠性,Local AC异常时可由Central AC独立提供功能,提高网络可靠性。高性能,由Local AC终结AP的CAPWAP隧道,通过分布式操作分担Central AC性能压力,提高整网性能;另外,在分层AC架构下,漫游性能也得到了提高,终端在AP之间的切换由Local AC负责。由于Local AC更靠近AP,因此可以更迅速响应漫游事件,更快地实现终端漫游。可扩展性,通过增加Central AC或Local AC即可对网络进行扩容。

3. 3.3分层AC架构之应用场景

总部分支场景

某大型家电连锁卖场计划在其全国所有门店实现无线网络覆盖,主要有如下需求:认证服务器部署在总部由总部集中认证,总部可以进行统一管理,分支规模较大的卖场可以根据其需求进行个性化的配置,各地分支卖场的AC出现故障,可以由总部AC继续提供服务。分层AC架构天然支持总部和分支的应用场景,如组网图5所示。管理方面,,位于分支的Local AC则负责管理和接入本地AP和无线客户端。用户的认证授权由总部Central AC负责,数据流量由Local AC本地转发。如果分支卖场有个性化配置需求,可以在Central AC上开启不同管理权限对分支Local AC和本地AP进行配置,实现分级分权管理功能;另外,如果分支的Local AC出现故障,本地AP可以自动寻找到总部AC,由总部AC继续提供管理功能。

 



图5 总部分支场景分层AC组网图

 

本地园区场景

某大型企业需要在其工业园区部署无线网络,供员工日常上网及办公使用,主要有如下需求:统一管理、集中认证、满足大量用户使用。通过部署分层AC架构可以完美解决上述需求,其组网图如图6所示。管理方面由Central AC负责统一管理和集中认证,Local AC负责接入AP,由于有大量AP需要接入,Central AC可以根据Local AC的实时负载,协调其余AP负载分担,充分利用多个Local AC的能力,使整个无线网络达到最优性能。

 


 

图6 大型企业园区场景分层AC组网图

四、结束语

未来,随着网络的发展, WLAN产品架构形态与逐渐凸显优势的SDN网络架构相结合。相应的,分层架构中的网络控制层可以进一步演变,由SDN Controller提供网络控制层功能,真正做到网络设备控制平面与数据平面相分离,增强无线网络的灵活性和简易性,最终使整套网络变得更加智能和人性化。

本文转自d1net(转载)

时间: 2024-11-06 03:44:30

WLAN产品形态之分层架构的相关文章

基于.NET平台的分层架构实战

基于.NET平台的分层架构实战(十一)-表示层的实现 基于.NET平台的分层架构实战(十)-业务逻辑层的实现 基于.NET平台的分层架构实战(九)-数据访问层的第三种实现:基 基于.NET平台的分层架构实战(八)-数据访问层的第二种实现:SQ 基于.NET平台的分层架构实战(七-外一篇)-对数据访问层第一种 基于.NET平台的分层架构实战(七)-数据访问层的第一种实现:Acc 基于.NET平台的分层架构实战(六)-依赖注入机制及IoC的设计 基于.NET平台的分层架构实战(五)-接口的设计与实现

EntityFramework之领域驱动设计实践(二):分层架构

在引入实例以前,我们有必要回顾,并进一步了解分层架构."层"是一种体系结构模式[POSA1],也是被广大软件从业人员用得最为广泛而且最为灵活的模式之一.记得在CSDN上,时常有朋友问到:"分层是什么?为什么要分层?三层架构是不是就是表现层.业务逻辑层和数据访问层?" 到这里,你可能会觉得这些朋友的问题很简单,分层嘛,不就是将具有不同职责的组件分离开来,组成一套层内部高聚合,层与层之间低耦合的软件系统吗?不错!这是分层的目标.但是,我们应该如何分层呢? 领域驱动设计的

基于.NET平台的分层架构实战(九)—数据访问层的第三种实现:基于NBear框架

基于.NET平台的分层架构实战(九)-数据访问层的第三种实现:基于NBear框架的ORM实现 前面的文章讨论了使用SQL语句和存储过程两种数据访问层的实现方式,这一篇里,将讨论使用ORM方式实现数据访问层的方法. 对象-关系映射(Object/Relation Mapping,简称ORM),是随着面向对象的软件开发方法发展而产生的.面向对象的开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级应用环境中永久存放数据的主流数据存储系统.对象和关系数据是业务实体的两种表现形式,业务实

基于.NET平台的分层架构实战(八)—数据访问层的第二种实现:SQLServer+存储

基于.NET平台的分层架构实战(八)-数据访问层的第二种实现:SQLServer+存储过程 在上一篇中,讨论了使用SQL构建数据访问层的方法,并且针对的是Access数据库.而这一篇中,将要创建一个针对SQLServer数据库的数据访问层,并且配合存储过程实现. 曾经有朋友问我使用SQL和存储过程在效率上的差别,惭愧的是我对这方面没有研究,也没有实际做过测试.通过查阅资料,发现在一般情况下,存储过程的效率由于使用SQL,但是也不绝对,也发现有的朋友测试时发现在特定情况下SQL的效率优于存储过程,

基于.NET平台的分层架构实战(七-外一篇)—对数据访问层第一种实现(Access+

基于.NET平台的分层架构实战(七-外一篇)-对数据访问层第一种实现(Access+SQL)的重构 昨天的文章基于.NET平台的分层架构实战(七)--数据访问层的第一种实现:Access+SQL发布后,很多朋友对我的程序提出了意见和建议,在这里先谢谢你们!!!尤其是金色海洋(jyk),对我的程序提出了很多建设性的意见. 我大体总结了一下,昨天程序的主要缺点有: 1.Connection对象没有关闭 2.DataReader对象没有关闭 3.相似代码太多,造成代码冗余. 其中第一点问题,目前还没有

基于.NET平台的分层架构实战(六)—依赖注入机制及IoC的设计

我们设计的分层架构,层与层之间应该是松散耦合的.因为是单向单一调用, 所以,这里的"松散耦合"实际是指上层类不能具体依赖于下层类, 而应该依赖于下层提供的一个接口.这样,上层类不能直接实例化下层中的类, 而只持有接口,至于接口所指变量最终究竟是哪一个类,则由依赖注入机制决定 . 之所以这样做,是为了实现层与层之间的"可替换"式设计 ,例如,现在需要换一种方式实现数据访问层,只要这个实现遵循了前面定义的 数据访问层接口,业务逻辑层和表示层不需要做任何改动,只需要改一下

基于.NET平台的分层架构实战(五)—接口的设计与实现

接下来,将进行接口的设计.这里包括数据访问层接口和业务逻辑层接口.在 分层架构中,接口扮演着非常重要的角色,它不但直接决定了各层中的各个操作 类需要实现何种操作,而且它明确了各个层次的职责.接口也是系统实现依赖注 入机制不可缺少的部分. 本项目的接口设计将按如下顺序进行: 1.首先由前文的需求分析,列出主要的UI部分. 2.分析各个UI需 要什么业务逻辑支持,从而确定业务逻辑层接口. 3.分析业务逻辑层接口 需要何种数据访问操作,从而确定数据访问层接口. 另外,为保证完全的 面向对象特性,接口之

基于.NET平台的分层架构实战(三)—架构概要设计

架构基本原则: 这里,将描述一些在这个架构设计中的基本原则,其 中很多都是经典的设计原则,不过针对分层架构的特点,用我自己的语言进行了 描述.其中也有我自己提出的原则. 逐层调用原则及单向调用原则 现在约定将N层架构的各层依次编号为1.2.-.K.-.N -1.N,其中层的编号越大,则越处在上层.那么,我们设计的架构应该满足以下 两个原则: 1.第K(1<K<=N)层只准依赖第K-1层,而不可依赖其他 底层. 2.如果P层依赖Q层,则P的编号一定大于Q. 其中第一个原 则,保证了依赖的逐层性,

基于.NET平台的分层架构实战(一)—综述

通过浏览博客园的文章发现,很多朋友对分层架构特别感兴趣,刚好我刚做完 的毕业设计就是专门研究.NET平台上分层架构的(题目叫"基于.NET平台的 分层架构与设计模式应用研究").通过做这篇论文,我对分层架构有了一 定的了解,所以,就萌发了想写一个文章系列,详述一下分层架构.然而,论文 的理论性太强,不适合在网上发布,尤其不适合初学者理解,所以,我想在这个 文章系列中,少讲理论,而是通过做一个完整的案例来讨论分层架构的基本方法 ,这样会直观很多.希望在这个文章系列的写作过程中,能和朋友们