华为园区网络CampusInsight 技术白皮书
目录
1产品概述 (1)
2关键技术说明 (2)
2.1整体架构 (2)
2.2Telemetry (3)
2.3数据采集 (3)
2.4数据流 (4)
2.5AI 动态基线 (5)
2.6问题分析 (5)
2.6.1接入类问题 (6)
2.6.2性能类问题 (7)
2.6.2.1高信道利用率 (7)
2.6.2.2弱覆盖 (9)
2.6.2.3非5G 优先接入 (10)
2.6.2.4空口拥塞 (12)
2.6.3问题列表 (12)
2.7协议回放 (14)
2.8质差用户相关性分析 (15)
2.9音视频应用质量感知 (16)
3典型案例 (18)
3.1用户全旅程体验可视 (18)
3.2弱信号覆盖问题 (19)
3.3空口拥塞问题 (21)
3.4高干扰问题 (22)
3.5高信道利用率问题 (24)
3.6PoE 供电问题 (25)
1 产品概述
大数据时代，传统的基于指定规则的运维模式已经支撑不了用户对网络的运维需求，自
动化运维的不足，日益凸显：
●传统网管分钟级数据采集，无法实时、精准采集；有可能错过故障发生时间
●传统网管仅监控性能指标，无法准确感知用户体验，缺少用户和网络的关联分析
●传统网管缺少有效的结合场景的问题识别及分析能力，只能监控、统计失败事件利
用网络产生的大量数据进行智能运维，提升用户运维效率已经刻不容缓。
华为CampusInsight 网络智能分析平台，颠覆传统聚焦资源状态的监控方式，将人工智
能应用于运维领域，基于已有的运维数据（设备metrics、终端日志等数据），通过大数
据、人工智能算法及更多高级分析技术，将网络中的用户体验数字化，辅助客户及时
发现网络问题，改善用户体验。
每时刻每用户全旅程体验可视
●每时刻：基于Telemetry 技术，动态秒级抓取网络KPI 数据，故障可回溯。
●每用户：通过多维度采集数据，实时呈现每个用户的网络画像，全旅程网络体验
（谁、何时、连接至哪个AP、体验、问题）可视。
网络问题自动识别，主动预测
●通过大数据和AI 技术，自动识别连接类、空口性能类、漫游类和设备类问题，提
升潜在问题识别率85%。
●利用机器学习历史数据动态生成基线，通过和实时数据对比分析从而预测可能发生
的故障。
网络问题智能定界，分析根因
●基于网络运维专家系统和多种AI 算法，智能识别故障模式以及影响范围，协助管
理员定界问题。
●基于大数据平台，分析问题可能发生的原因并给出修复建议。
2 关键技术说明
2.1整体架构
CampusInsight 基于华为大数据分析平台构建，采用Telemetry 技术方案接收设备上报
的数据，通过智能算法对网络数据进行分析、呈现。
CampusInsight 分析器采用微服务架构，各个业务服务采用多实例部署，外部HTTP 请
求由消息总线进行分发到各个节点实例处理，并可通过扩充实例节点实现服务容量动态
扩容，具备高可靠性和伸缩性。
2.2Telemetry
Telemetry 是设备新增的一个特性，基于Google 主导的GPB（Google Protocol Buffer）
来主动上报数据，它是用来做性能和故障监控的一个系统，包括数据生成、数据采
集、存储和分析，能有效解决传统网络遇到的数据获取问题。
当前网络监控数据上报过程中存在的问题：
1.随着网络日益庞大，传统的监控模式（例如snmp、syslog）越来越束缚监控网络的
规模和监控效率。
2.SNMP 和CLI 的“拉”模式（即查询等待响应），需要采集器通过轮询方式处理
每一个网络元素，随着网络的增大，采集器的增多，网元设备要接收越来越多的查
询，对网元设备的正常工作带来严重的干扰。
3.传统监控模式也提供有“推”模式（例如snmp 的Trap 上报、syslog 上报，终端
的告警回显），但这些“推”模式提供的数据格式不同厂家不一样，给采集器分析
数据增加了复杂度。
Telemetry 解决方案：
1.提供“推”模式（即订阅一次，持续返回数据流），避免轮询方式对采集器自身以
及网络流量的影响
2.提供统一的数据流格式，简化采集器分析监测数据的难度与
传统的网络管理协议对比如下：
2.3数据采集
数据采集范围：
当前采集数据包括两大类：
用户接入类数据：用户在接入网络过程中产生的接入类日志信息，主要包括：关联、认
证、DHCP IP 获取这三个阶段的日志（包括成功与失败日志，以及接入失败的各种原
因）。设备采用syslog 协议上报日志数据。
用户性能类数据：AP 设备上报的终端、射频、AP 的性能metrics 数据，主要包括：终
端的信号强度、丢包率等；射频的干扰率、信道利用率等；AP/AC/交换机的CPU、内存、
接入用户数等。设备采用GPB 协议主动上报性能类数据。
2.4数据流
从设备数据上报到页面呈现，数据经过数据接入、数据采集、数据分发/缓冲、数据分析
/AI 运算（过滤、合并、专家库分析、AI 机器学习）、数据存储5 个部分：
数据接入：无线AP 设备、AC 设备、交换机接入分析器产品，并设置metrics 数据与
日志数据的上报通道
数据采集：采集服务接收无线AP 设备、交换机GPB 协议周期上报的metrics 数据，
AC、AP、交换机上报的syslog 日志数据
数据分发/缓冲：Kafka 接收采集服务上报的设备原始数据，提供数据订阅消费能力，供
上层系统获取数据进行分析处理
数据分析/AI 计算：分析器根据采集的设备原始数据对数据做多方面，多维度的分析和处
理，比如对接入日志按阶段分类、统计用户接入成功/失败次数，根据用户性能metrics
评估终端用户上网质量（好、中、差），终端用户补齐厂商信息等。并基于原始用户数
据结合AI 机器学习算法，离线分析识别典型业务问题，主要包括：接入类问题、性能
类问题、设备类问题、漫游类问题。
数据存储：数据经过预处理后存储到Druid 表中，并做高粒度自动汇聚。
1、Kafka 是一个高吞吐、分布式、基于发布订阅的消息系统。
2、Spark Streaming 是Spark Core API 的一个扩展, 它支持弹性的、高吞吐的、容错的实时数据流的
分布式计算处理。
3、Druid 是一个快速的列式分布式数据存储系统，支持高速聚合和次秒级查询，同时支持每秒百万
级事件接入。
4、HDFS（Hadoop Distribute FileSystem）是一个分布式的文件系统，提供高吞吐量的数据访问，
适合大规模数据集上的应用。
2.5AI 动态基线
动态基线主要用于对某一指标未来变化趋势的预测，是基于历史大量数据通过AI 机器
学习算法所得，是系统判定指标是否异常的标准之一。动态基线不是一条固定不变的
基准线，而是一条会根据各时间点指标（比如网络流量）不断变化的基准线。
如下图所示，基于动态基线预测的范围（灰色阴影部分）与实际网络产生的数据（趋势
折线图）对比，对于超出范围内的数据时刻，初步判定为网络的异常事件。
动态基线当前采用高斯回归作为异常事件的预测算法。
2.6问题分析
无线信道频段的开放性，接入终端类型的千差万别，无线干扰多种多样且持续不断，导
致无线Wi-Fi 是一张不稳定的网络。用户接入的异常或失败是一个长期存在的现象，
单点的没有造成用户体验感知的失败事件无需关注。而网络或设备问题（比如认证服务
器高负荷导致失败率持续冲高）导致的持续异常直接影响大量用户体验，则需上升为重
点问题，须运维人员关注并解决。
2.6.1接入类问题
接入类问题识别整体算法设计
1.异常事件：根据设备上报的关联、认证、DHCP 三阶段日志，识别异常事件，包括
关联失败/超时/慢、认证失败/超时/慢、DHCP 失败/超时/慢
2.异常聚类：关联类异常事件按照AP 聚类，认证/DHCP 类异常事件按照AC 聚
类，识别疑似AC、疑似AP
3.AI 机器学习：基于历史海量数据，采用AI 机器学习训练所得的学习基线值作为
判定基准
4.基线比对、问题识别：疑似设备与学习基线值比较分析，得出最终的问题AC，问题
AP
接入类问题分析
1.异常检测：用户接入网络过程中经常存在失败，然而并不一定是故障。使用机器
学习算法，通过大量历史数据训练生成基线，智能检测异常。
2.模式识别：针对相同的问题现象（如用户认证超时）可能有不同的原因，通过识
别模式找出可能的原因。将接入失败终端的相关特征进行抽象，运用聚类算法进行
群分析
3.根因分析：基于终端上线日志，提炼可能的故障根因并给出修复建议，帮助运维人
员实现问题闭环
2.6.2性能类问题
2.6.2.1高信道利用率
问题描述
无线信道为公共资源，同一时刻每个信道只能有一个用户在传输数据，当信道占满
（包括正常数据传输占用，无线干扰占用）导致信道利用率冲高时，影响用户体验。
问题分析
1.Benchmark：基于历史数据学习，关联分析信道利用率对用户体验指标（时延、
丢包率）的影响，动态建立Benchmark
2.异常识别：基于Benchmark 自动识别持续高负载或突发的空口问题
3.相关性分析：自动选取影响信道利用率的根因指标进行相关性分析
2.6.2.2 弱覆盖
问题描述
用户数：是否因高负载导致问题？ 干扰率：是否因高干扰导致问题？
协商速率：是否因低效空口占用导致问题？
网络中由于网规不当或 AP 发射功率较低导致信号覆盖不全，影响用户长时间处于弱信号接入状态
问题分析
1. 数据集去噪是基础：去除 “休眠的、短时接入的、业务量少”的终端和“业务量
稀少（用户数很少）” 的 AP
噪声数据不能如实反应网络的真实状态（比如终端休眠，丢包率必然很高），所以对于群障的识别，必须去除噪声数据
2. AI 算法自动识别：基于故障特征库在秒级采集的用户性能数据中，自动识别信号强
度异常模式数据，并识别多发时段与多发
AP
2.6.2.3非5G 优先接入
问题描述
非5G 优先接入是一类典型的5G 信号覆盖问题，双频终端接入2.4G 信号导致速率较
低，干扰较大
问题分析
1.数据去噪：去除“只支持
2.4G 的、休眠的、短时接入的、业务量少”的终端和
“仅发射2.4G 信号的、业务量稀少（用户数很少）”的AP
2.AI 算法自动识别：基于故障特征库在秒级采集的大数据仓库中自动比对、挖掘，识
别异常数据
3.空间维度对比分析：同一批用户在“问题AP”上的2.4G 接入比例普遍较高，在
“其他AP”上比例很低；问题AP 按非5G 接入用户数排名第一，严重程度高
4.时间维度对比分析：第一行的设备长时间频发问题且数量较多，严重程度高；其他
设备属于偶发问题，需要继续观察
2.6.2.4空口拥塞
问题描述
空口拥塞是空口过载导致的数据积压问题。无线用户上传、下载等操作产生的超大流量
可能导致空口数据积压，产生空口拥塞问题
问题分析
1.异常识别：基于历史数据学习，分析流量基线；对比基线自动识别突发或持续的
空口拥塞问题
2.异常模式：基于用户粒度分析流量模式，识别大流量用户对带宽占用导致的空口
拥塞
2.6.3问题列表
2.7协议回放
基于AP 设备上报的用户接入三阶段（关联、认证、DHCP）的协议报文，分析器细化
分析各个协议交互阶段结果与耗时，提供用户接入过程个障的精细化分析，从之前的
识别用户问题的接入阶段到问题产生的协议阶段，具体协议各个阶段如下：
●关联阶段：
1、Associate Request：关联请求
2、
Associate Response：关联响应
●认证阶段
1、EAP Identity：身份识别
2、PEAP Start：认证开始
3、Server Hello Certificate：加密算法协商
4、Client Key Exchange：密钥交换
5、Change Cipher Spec：密钥生成
6、EAP Result：认证结果
7、EAPoL Key Message：密钥配置
当前认证协议仅支持Dot1X 认证协议
●DHCP 阶段：
1、DHCP Discover：客户端请求广播
2、DHCP Offer：DHCP 服务器回应
3、DHCP Request：客户端IP 地址请求
4、DHCP ACK：DHCP 服务器回应地址请求成功
5、DHCP NAK：DHCP 服务器回应地址请求失败
2.8质差用户相关性分析
分析器基于用户的历史KPI，使用动态学习算法学习指标劣化的阈值，从而分析用户
的质差时长，同时，对用户的质差情况进行分析，将用户的质量问题进行分类，并呈现
每类问题对用户质差的相关性。AI 算法会针对每一类问题，分析网络侧指标的相关性。
质差用户问题分类、个障标签、相关网络侧指标如下表所示：
问题分类个障标签相关网络侧指标
覆盖类弱信号RSSI
上行协商速率
下行协商速率
问题分类个障标签相关网络侧指标干扰类同频干扰同频干扰率
吞吐类非5G 优先
弱终端
容量超限
空口拥塞射频ID
信道利用率反压计数
上行协商速率下行协商速率
硬件类CPU 超限
内存超限CPU 占用率内存占用率
2.9音视频应用质量感知
分析器支持主动感知音视频质量，通过SIP Snooping 技术主动感知SIP+RTP 音视频
流，实时探测音视频会话的建立与结束，自动启用eMDI(Enhanced Media Delivery
Index，增强型媒体传输质量指标)技术监控会话过程中的音视频流质量，识别质差音视频
流。
音视频会话统计区域能够展现整网的音视频应用统计数据，包括音视频质量MOS 值的分布占比、SIP 会话成功、建链失败、异常掉线的数目统计，以及音视频流量趋势。
通过统计数据，可以更精确地了解整网音视频应用的情况。
音视频会话列表区域，以列表的形式展现每一条音视频会话的信息，包括音视频会话流
的五元组、发起方/响应方的终端MAC、会话的类型、开始/结束时间、会话状态，以及
会话上行/下行的质量MOS 值。
Campus Insight 支持查看音视频会话的详细信息。基本信息区域、质量概述区域描述了
音视频会话的概况，路径描述区域可视化地展现了会话发起方、响应方的接入设备。
通过点击设备图标，可以自由查看设备上音视频流的质量情况，分析音视频流MOS 值
与丢包率、最大连续丢包数、重传率、抖动等质量指标的相关性，从而分析音视频质量问题。
3 典型案例3.1用户全旅程体验可视
问题现象
某公司VIP 用户XXX 报障，某天在下午4 点15 左右Wi-Fi 不稳定，时常掉线，网络
无法正常使用
问题分析
1.获取此用户MAC 地址，在用户中搜索找到此用户
2.进入用户全旅程页面，发现此用户当天的平均场强较差，平均时延也较高
3.用户全旅程中找到用户报障的对应时段（16:15左右），发现用户在时段前后频繁发
生漫游，且漫游前后的AP 上平均场强都较低