异频组网站点解决抖音用户视频加载卡顿问题.docx
《异频组网站点解决抖音用户视频加载卡顿问题.docx》由会员分享，可在线阅读，更多相关《异频组网站点解决抖音用户视频加载卡顿问题.docx（12页珍藏版）》请在冰点文库上搜索。
异频组网站点解决抖音用户视频加载卡顿问题
杭州电信网络维护中心异频组网站点解决抖音用户视频加载卡顿问题
杭州电信网络维护中心
陈一铭
2019年5月
一、问题描述3
二、分析过程5
三、解决措施8
四、经验总结11
异频组网站点解决抖音用户视频加载卡顿问题
陈一铭
【摘要】随着抖音等短视频APP盛行和普及，现在用户终端的流量占比从原先通信软件及网络游戏为主，逐渐向短视频APP方向倾斜增长。
由于短视频APP独特的长时间持续高流量的话务模型，在低用户数前提下，依然能产生较高的流量峰值，对基站扇区负荷产生巨大压力，同时对于异频组网站点，由于默认负载均衡触发模式为用户数模式触发（MLBTRIGGERMODE=UE_NUMBER_ONLY），过低的用户数不会触发负载均衡，导致对于这类用户引起的高话务量，即使扩容2.1G异频，对用户感知亦无明显提升。
此类问题需通过修改触发模式为PRB模式或用户数模式触发（PRB_OR_UE_NUMBER），同时合理修改异频负载平衡门限才能解决。
【关键字】高话务低用户数用户视频加载卡顿负荷分担短视频
【业务类别】优化方法、参数优化、负荷均衡
一、问题描述
杭州市西湖区学院路107号浙江工人日报社网络编辑部有用户投诉，表示在办公室刷新抖音等短视频APP时经常卡顿，重复刷新依然无法缓冲等问题反复出现，且集中于早9点至晚9点的工作时段内。
我方工作人员上门测试后，发现该点无线环境良好，RSRP为-81dBm，SINR为15dB，但网速缓慢，主占用LF_H_杭州九莲新村_50，下载速率为5Mbps左右，用户现场演示打开抖音APP后首页加载视频失败，多次刷新后才加载成功。
用户现场测试照片
查询LF_H_杭州九莲新村_50小区，忙时用户体验下行平均速率较低，但最忙时用户数仅30个时，用户体验下行平均速率却已低至为5Mbps左右，具体用户体验下行平均速率与最大用户数趋势分布如下：
二、分析过程
LF_H_杭州九莲新村站点用户投诉区域距离该站点仅50米左右，用户办公室区域主占用该站点LF_H_杭州九莲新村_5和LF_H_杭州九莲新村_50信号，无线环境良好，排除无线链路问题导致网速缓慢的可能性。
同时由于该站点位于人流量较大的主城区，已于2017年做过2.1G载频扩容工作，且忙时用户数也较少，按以往的工作经验，基本不可能会出现拥塞问题，用户体验下行平均速率不应该低至5M左右。
查询LF_H_杭州九莲新村站点的下行PRB利用率后发现该站点的2扇区1.8G跟2.1G的PRB利用率极不平衡，1.8G载频的PRB利用率工作时段基本稳定在50%左右，峰值时段甚至超过了80%，而同时刻2.1G载频的PRB利用率却仅在30%左右，再查询LF_H_杭州九莲新村_5与LF_H_杭州九莲新村_50的下行流量，发现1.8G载频的忙时流量在8GB左右，而同时刻2.1G载频的流量在4~5GB左右，与下行PRB利用率的趋势基本一致。
由此，我们得出了以下初步结论：
①LF_H_杭州九莲新村站点2扇区下存在一批特定用户，此类用户虽然人数较少，但单用户的日均流量巨大，根据忙时流量及最大用户数换算，单用户忙时流量也稳定在280MB以上，远超普通用户。
同时此类用户终端行为为持续性数据下载，业务态占比高，导致站点PRB利用率居高不下。
②LF_H_杭州九莲新村站点2扇区的负载均衡基本没有发挥效果，1.8G频点流量及PRB利用率稳定为2.1G频点的2倍，且1.8G频点用户体验速率明显恶化后依然不会向2.1G频点均衡负载。
针对结论①，我方查询了LF_H_杭州九莲新村站点2扇区的话单，并按用户话单条数汇总排序后发现，确实存在一批异常用户话单数量远远多于其他用户，侧面印证了结论①的正确性，同时发现此批用户中就包含了浙江工人日报社网络编辑部的那位投诉用户。
向该用户了解详细情况后，用户反映自己由于是负责报社网络板块编辑工作，需要经常刷新抖音等短视频APP发现新闻素材，每日需要刷新大量的短视频，但视频加载卡顿严重影响工作效率，同时编辑部负责相同工作的同事使用电信网络也出现相同问题，才向我方反映该问题。
随机获取这批电信用户号码与异常用户清单比对，发现均在异常用户清单内，确认结论①的异常用户行为模式就是由于抖音等短视频APP频繁刷新引起。
针对结论②，我方查询了LF_H_杭州九莲新村站点的均衡负载均衡策略，发现该站点负载均衡触发方式为用户数模式触发，同时异频负载平衡门限为60%。
由于该扇区下用户数较少，远远低于60%最大负载这一门限，因此根本不会触发负载均衡，导致1.8G频点下拥塞严重的同时，话务不会向2.1G转移。
综合以上分析，我们可以做出结论：
LF_H_杭州九莲新村_50下用户加载视频卡顿现象的发生，是由于该扇区下大量抖音用户产生的高流量引起，同时由于不满足负载均衡触发条件，高流量无法向异频分摊导致。
不难发现，抖音等短视频APP不同于一般的视频网站APP，用户的观看方式不是通过图片文字等缩略信息来决定是否观看视频内容，而是先观看视频内容开头再决定是否继续观看，由此产生的随机刷新播放机制，使用户容易在短时间内创建大量的视频缓冲队列；同时由于视频持续时间短，不存在分段缓冲机制，点开视频后必定会缓冲完整视频文件，导致缓冲队列中每个文件都较大，使终端始终处于下载中的状态。
短视频APP的业务模型更接近于FTP服务器队列下载，对基站流量的占比也远远高于通信软件、网页浏览、手机游戏等其他业务。
短视频用户占用的PRB个数更多，在负载均衡中应有更高的权重，此时再使用所有用户权重相等的用户数模式来触发负载均衡，明显不符合实际，因此改用PRB模式触发，或者PRB与用户数混合触发的负载均衡策略，更适合有批量短视频用户聚集的场景。
三、解决措施
1、优化思路
①设置1.8G频点均衡负载触发方式为PRB模式或用户数模式触发（PRB_OR_UE_NUMBER），确保抖音用户产生高PRB利用率时，能正确触发均衡负载，同时保证高人流量时也能根据用户数触发均衡负载；
②根据每日PRB利用率峰值计算出合适的异频负载平衡门限（%），具体方法为统计1.8G频点每日PRB利用率峰值均值与2.1G频点每日PRB利用率峰值均值，两数值的平均数即为最佳异频负载平衡门限（%）。
本案例中1.8G频点每日PRB利用率峰值均值为80%，2.1G频点每日PRB利用率峰值均值为30%，因此异频负载平衡门限设定为55%最为合适。
③设定异频负载均衡转移UE类型为同步态用户和PRB模式负载均衡同步态用户，不使用空闲态用户异频负载均衡转移，只对同步态用户进行异频负载均衡转移，避免空闲态用户反复异频转移影响接入感知。
④改用PRB模式触发后，鉴于PRB利用率峰值较高，异系统负载平衡门限也应相应调整，从默认75%修改至85%，避免过早触发异系统负载平衡，导致用户转移至异系统。
⑤鉴于本案例站点下用户总体流量高，即使使用负载均衡分摊后，对单载频的负荷依然较高，因此两频点不特意区分容量层与覆盖层，2.1G均衡负载策略与1.8G配置一致，容量上做到完全均衡，保证用户分布不会向某一频点上倾斜，从而影响某一载频性能。
2、负载均衡参数设置
修改后LF_H_杭州九莲新村2扇区1.8G频点与2.1G频点负载均衡参数设置如下表:
1.8G频点参数
2.1G频点参数
异频负载平衡门限（%）
55
55
异系统负载平衡门限（%）
85
85
负载偏置（%）
8
8
负载差门限（%）
15
15
异系统MLB用户数门限（%）
15
15
Utran空闲态负载平衡初始生效时间（秒）
10
10
负载均衡触发模式
PRB模式或用户数模式触发
PRB模式或用户数模式触发
异频负载均衡用户数门限
100
100
负载均衡用户数偏置
20
20
负载均衡最大选择用户数
10
10
负载均衡用户选择PRB门限（%）
10
10
用户数差值门限（%）
15
15
MLB最小用户数门限
0
0
MLB最小用户数偏置
0
0
异频负载均衡转移UE类型
同步态用户:
开
空闲态用户:
关
PRB模式负载均衡同步态用户:
开
PRB模式负载均衡空闲态用户:
关
同步态用户:
开
空闲态用户:
关
PRB模式负载均衡同步态用户:
开
PRB模式负载均衡空闲态用户:
关
异频空闲态MLB用户数门限
100
100
异频负载评估周期（秒）
10
10
负载均衡频点选择策略
公平选择策略
公平选择策略
重要负载均衡参数设置如下图所示:
【结果验证】
修改负载均衡策略后，2.1G小区有效的分担了原1.8G小区的话务负荷，1.8G小区工作日忙时用户感知速率由4.95Mbps提升至17.43Mbps，忙时流量从8GB左右下降到6GB左右，用户感知得到了明显的提升，详细指标如下：
1）用户数均衡分布
用户在2.1G小区和1.8G小区基本平均承载，两小区最大激活用户数都基本稳定在18个左右，前后对比可见明显的峰值下降，具体各时段用户趋势如下：
2）用户感知速率提升
修改负载均衡策略后，1.8G忙时用户体验下行平均速率由4.93mbps提升至17.43mbps，同时2.1G忙时用户体验下行平均速率无明显变化，优化效果良好，用户上网感知提升明显，各时段用户体验下行平均速率趋势如下。
3）数据流量提升
在用户数基本持平的情况下，1.8G小区忙时用户流量由8GB降低至6GB左右，2.1G小区忙时用户流量由4G提升至6GB左右。
修改前1.8G小区每日总流量均值为103GB左右，2.1G小区每日总流量均值为68GB左右，总计171GB；修改后1.8G小区每日总流量均值为95GB左右，2.1G小区每日总流量均值为92GB左右，总计187GB，对比修改前用户流量增长9.9%，优化效果良好，而且对1.8G小区流量峰值的抑制效果明显，各时段流量趋势如下：
四、经验总结
随着抖音等短视频APP盛行和普及，用户的话务模型也出现相应的变化，因此分析用户话务模型，根据用户话务模型特点确定合适的负载均衡策略，对于启用负载均衡站点的容量优化尤为重要。
在本次案例中，出现抖音用户比较集中的高话务场景，此类低用户数的同时又产生高PRB利用率的站点，通过本文中提供的负载均衡参数设置的考量方法，可以定制出适合的负载均衡策略，从而利用同覆盖异频小区进行负载均衡，进而抑制峰谷比，提高用户感知速率。
升级会员 