LA3608E设备4G上网流量与WLAN流量差异大问题

LA3608E设备作为车载型无线网关，被放置在公交车上，上行通过4G拨号与运营商机房内的AC建立连接，建立LWAPP隧道，可以通过本地转发或集中转发的方式，为下连通过WIFI接入的用户提供无线上网服务。

在该应用场景中，运营商使用我们的设备作为内容提供商，为用户提供各种本地缓存的视频、音乐或是新闻等内容，并推送一些广告页面的链接，以此来实现盈利。对于该功能，就要求设备支持本地播存更新的功能：设备定时会去访问运营商指定的服务器，确认设备本地缓存的内容是否与服务器上最新的内容一致，若不一致，则下载更新的文件内容。

知客宝业务是第三方平台为运营商提供的一向服务：设备为客户推送植入的广告页面，在客户点击进入后，会采集用户的个人信息，如手机号码、本次接入位置、个人行为偏好等数据，并返回给后端的应用服务器，以便之后为客户更精准的推送其偏好的广告内容。

设备还支持GPS回传功能，能够实时记录设备的位置，并将数据发回给监控平台，确认车辆的行驶位置和状态是否正常。

由于LA3608E设备通过4G上行的业务流量较为复杂，有些业务流量可能不会通过AC进行转发，就可能会出现4G卡的上网流量与AC上面统计的WLAN流量有差异的问题。

运营商将某一路公交车（车载款型是LA3608E-DB）上4G卡的流量数据以及WLAN上网流量的数据导出对比后发现，两个流量差距过大。从某一月份的数据来看，4G上网卡的总流量为699G，但是统计的WLAN流量只有17G。

理论上来说，4G卡流量=LTE-AP与AC交互报文+上网流量。WLAN流量=上网流量，所以有一些差距是可以接受和理解的，但是相差太多就觉得有问题了。

其中的4G卡流量统计是移动自己内部BOSS平台提供的，所以可以认定为是准确的；WLAN上网流量，是我司AC作为PORTAL网关送给省移动3A计费平台的，这里AC和3A平台之间的交互出现问题，也是有可能的。

与客户确认了WLAN的 流量统计数据来自于3A平台，AC向3A平台发送计费报文时携带流量信息字段，包括上线、下线，以及每隔一段时间（15分钟）的计费中继信息中。客户怀疑可能是此部分信息不准确造成的流量差异。客户反馈现场目前只是单独统计了访问互联网的流量节点，而不确认该节点描述的数据和计费报文的是否一致。

经我们内部分析确认，排查可能涉及到流量异常的几个点：本地播存的内容更新；AP和AC之间隧道建立；Log日志回传；GPS的数据上送；AP版本更新升级。

根据客户反馈的计费统计，发现AP 的4G接口每小时上行流量平均都达到100MB，但下行流量却基本不变只有3MB。根据现有情况分析，基本可以断定异常流量是由于知客宝功能会不断的通过无线探针获取用户信息，而设备不断的向服务器回传数据，导致上行流量远远大于下行的业务流量。

实验室复现问题，在设备上打开了探针功能后，使用4-5个终端在其他AP上和LA3608E同一频段11上网，统计了4G接口的数据，此时LA3608上并没有任何无线用户在线。

[ap5]display interface Cellular-Ethernet 2/0

Cellular-Ethernet2/0 current state: UP

Line protocol current state: UP (spoofing)

Description: Cellular-Ethernet2/0 Interface

The Maximum Transmit Unit is 1500

Link delay is 180(sec)

Internet Address is cellular allocated, 10.157.225.177/32

IP Packet Frame Type: PKTFMT_ETHNT_2,  Hardware Address: 00a0-d5ff-ff02

IPv6 Packet Frame Type: PKTFMT_ETHNT_2,  Hardware Address: 00a0-d5ff-ff02

Output queue : (Urgent queuing : Size/Length/Discards)  0/100/0

Output queue : (Protocol queuing : Size/Length/Discards)  0/500/0

Output queue : (FIFO queuing : Size/Length/Discards)  0/75/0

RSSI Standby State: Normal

Transfer time: 01:00:02

Last clearing of counters: 16:39:34 utc Wed 09/23/2015

    Last 300 seconds input rate 132.81 bytes/sec, 1062 bits/sec, 3.15 packets/sec                    //下行数据基本不变

    Last 300 seconds output rate 11357.16 bytes/sec, 90857 bits/sec, 130.88 packets/sec            //上行速度如下。以此数据来计算的话，每小时的上行流量可以达到40MB，与现网环境比较吻合。

    Input: 11181 packets, 475748 bytes

           0 broadcasts, 0 multicasts

           0 errors, 0 runts, 0 giants

           0 CRC, 0 align errors, 0 overruns

           0 dribbles, 0 aborts, 0 no buffers

           0 frame errors

    Output:160387 packets, 14772481 bytes

           0 errors, 0 underruns, 0 collisions

           0 deferred

 在AC的ap模板视图下关闭了无线探针功能后，统计的4G接口数据如下：

[ap5]display interface Cellular-Ethernet 2/0

Cellular-Ethernet2/0 current state: UP

Line protocol current state: UP (spoofing)

Description: Cellular-Ethernet2/0 Interface

The Maximum Transmit Unit is 1500

Link delay is 180(sec)

Internet Address is cellular allocated, 10.157.225.177/32

IP Packet Frame Type: PKTFMT_ETHNT_2,  Hardware Address: 00a0-d5ff-ff02

IPv6 Packet Frame Type: PKTFMT_ETHNT_2,  Hardware Address: 00a0-d5ff-ff02

Output queue : (Urgent queuing : Size/Length/Discards)  0/100/0

Output queue : (Protocol queuing : Size/Length/Discards)  0/500/0

Output queue : (FIFO queuing : Size/Length/Discards)  0/75/0

RSSI Standby State: Normal

Transfer time: 01:23:27

Last clearing of counters: 17:48:43 utc Wed 09/23/2015

    Last 300 seconds input rate 133.03 bytes/sec, 1064 bits/sec, 3.13 packets/sec

    Last 300 seconds output rate 669.90 bytes/sec, 5359 bits/sec, 3.65 packets/sec        //这时流量明显就少了很多了，按照这个计算，每小时上行流量是2.4MB，和上面差20倍。

    Input: 2717 packets, 115364 bytes

           0 broadcasts, 0 multicasts

           0 errors, 0 runts, 0 giants

           0 CRC, 0 align errors, 0 overruns

           0 dribbles, 0 aborts, 0 no buffers

           0 frame errors

    Output:3161 packets, 579397 bytes

           0 errors, 0 underruns, 0 collisions

           0 deferred

关于知客宝功能的上送频率问题，默认情况上报频率取决于周围无线终端的发包频率，每接收到一个无线终端发送的包就上报一次，没有固定参数。上报的信息包括AP MAC地址、厂商ID、BSSID、Radio类型、信道、是否关联本机、时间戳、终端类型、信号强度、终端MAC等信息。该数据单次上报的话也只有几十个字节，流量大的原因应该是无线终端数量多、发包频率高导致的上报频率高。

在设备的知客宝功能开启后，不开启稀释功能的情况下，设备每收到一个无线终端（无论该终端是否通过认证、是否上线）发送的无线报文，都会向服务器上报一次。

所以无线终端流量越大，知客宝上报的流量就越大。比如，未通过认证的客户端访问本地播存流量的同时，也会不断的向服务器上报，这时就可能产生很大的流量。

由于知客宝部分占用的流量比较大，可以关闭知客宝功能，也可以开启稀释功能来减小上报流量，对比一下流量差值。如下：

知客宝功能开/关命令：

[undo] wlan rfid-tracking enable

稀释功能：

wlan rfid-tracking dilution factor M(范围1-10000) timeout N（范围1-60）

配置稀释后，针对每个无线终端，M个报文或N秒才上报一次。

rfid-tracking engine-address 112.124.8.206

去掉指定AP的上面命令，该AP就没有知客宝功能了。