运营级WiFi网络的网管平台构建

中AP异动后，需要在专业网管、综合网管、运维流程各环节均修改MAC地址，在海量AP的情况下，数据和资料准确性无法保障，造成运维流程、业务流程失控，因此，AP索引应该以AP编号做为关键字段，为每个AP定义一个AP编号，MAC地址只做为AC上的一个AP参数进行调整，流程各环节只识别AP编号，AP资料在工程验收时一次到位，运维过程中无需维护。网管在各功能模块设计时，均应围绕AP编号来进行处理，做到数据录入、采集时一次到位。最后，网管的数据库结构必须合理，符合数据库架构设计原则。网管数据库需要建立单独的外来源数据表、网管新增资源表(位置视图表)、数据处理最终表，将外来设备数据、自身新增数据、网管展示数据在结构上分开。避免在海量数据的情况下，造成额外的资源处理负担，同时避免在后期阶段的部分需求功能无法实现。

在网络建设阶段，网管功能主要满足工程建设的需求，同时满足基本的运维需求。定位在流程管控的综合网管，主要实现三类功能：网络指标的管控与分析、工程建设资源的管控和接口故障派单系统。而定位于技术处理的专业网管，也实现三类功能：建立位置视图，AP数据实现模糊查询和数据配置错误检查。图2和图3分别展示了两种网管的主要应用：

AC资源统计表提供给网络建设等相关部门辅助建设设计的工作。

图3 专业网管数据配置检查图

帮助建设、维护人员检查AC数据配置准确性，减少AC操作负担。可检查的错误类别包括：AP编号重复、AP编号配置错误、MAC、序列号、型号数据配置错误、业务VLAN准确性、AC来源准确性、割接数据未删除等。

2. 运维管控阶段的网管改造

该阶段的目标是保障网络运行的稳定性，因此，网管系统功能需要满足流程管控中优化调整的需求，满足故障维护中监控分析的需求。同时网管结构上还需要满足海量资源增长带来的负载分担需求，网管平台需要完成一系列改造工作。

网管平台结构需要完成服务器分布式运行改造

在运行维护阶段，网管平台的网络结构改造是首要工作。一般的大型城市运营级WiFi网络，AP数量达到数万，传统的集中式单机网管已不能满足资源处理的要求，容易造成数据丢失，状态错误，运行不稳定的问题。网管系统必须采用分布式结构，将各类功能模块交由专业服务器处理，一般划分为采集服务器、数据处理服务器、系统应用服务器，以达到大型运营商OSS系统的要求，提高数据更新的适时性，保障在流程运转、维护查询、业务分析中数据的准确性。

综合网管需要完成流程管控功能的改造

这个阶段，在流程运转中最大的问题是网络端对端资料准确率不高，其次问题是因工程、用户原因造成的AP不可维。综合网管做为流程管控的定位，需要帮助运营部门解决或规避此类问题，使流程能够正常运转。综合网管的主要改造内容包括：

1) 工程数据库、维护数据库分库管理

改造要点(如图4所示)：

分库管理：在综合网管上将工程资料库和维护资料库分开，通过一系列功能模块保障维护资料库的准确率，使各部门可以有效共用网管平台，同时保障各类流程的流畅化，解决因工程设计资料影响运维、业务流程的问题。

网管转维：实现自动转维和人工转维两种工程转维模式。新建的WiFi热点在观察期内达到网络指标的要求，进行自动转维;因用户断电等原因未满足网络指标，但满足设备可管率要求的热点，通过人工审核，进行人工转维。网管转维的模式，规避了因工程原因导致的AP网络不可维、海量的用户侧运营设备验收采样率不高的问题，提升了网络整体的可维性、可用性。网管转维的另一个重要作用是可以管控工程进度，解决工程拖期、工程质量的问题。

资料审核：在转维过程中加入资料自动审核模块，通过建设流程中一些关键部门关键资料的规范化审核，判定资料的准确率，决定转维是否成功，同时下发到相关部门更新准确的工程验收资料。资料审核功能有效的提升了维护资料的准确率。

维护回退：通过关键职能部门的审核，允许部分问题热点从维护库退回到工程库。WiFi网络运营级的主体AP在用户侧，因用户装修、电源等问题造成热点设备暂时不可维，可注明原因和时限回退到工程库，通过网管转维或时限过期后进入网管人工转维模式重新纳入到运维流程中进行运维和考核;同时在运维过程中发现的资料问题，也可以通过回退模式转入工程库，通过网管人工转维模式限定相关职能部门限期解决。通过维护回退，解决用户原因造成的运营级问题，规避维护资料错误的问题，使流程能够正常运转。

图4 综合网管分库管理、网管转维的流程图

2) 网络热点资料管理流程改造

当WiFi运营商向公众客户公布(含有)WiFi热点信息的