TD-LTE视频业务端到端感知评估体系构建

古莉姗，邓也，储刘庆，宫晓强

（中国移动通信集团设计院有限公司安徽分公司，合肥 230031）

随着移动互联网的迅猛发展，智能设备的普及，再加上网络带宽的快速提升，人们越来越习惯使用视频来传递信息，相互交流。无论是人们的享受（娱乐视频），还是人们对环境的监控管理（行业视频），乃至人与人、人与物的通信（通信视频），都属于视频的范畴。在不远的将来，视频将贯穿人的一生，应用于各行各业，成为一种新的生活方式和人生体验。视频业务端到端感知也成为运营商亟需研究的一个课题，通过构建TD-LTE视频业务端到端感知评估体系，找出现网影响视频业务感知的痛点，再提供优化部门进行有针对性的优化，可以有效地提高工作效率。

TD-LTE视频业务端到端感知评估体系从接入性和流畅性两个方面入手进行构建。

1 接入性

视频用户接入可以细分成3个阶段（TCP建链、索引文件、下载分段视频），针对这3个阶段，分别定义为流媒体TCP建立成功率、流媒体Get响应成功率、初始缓冲成功率、流媒体播放成功率4个指标。

1.1 流媒体TCP建立成功率

流媒体TCP建立成功率指标包含会话建立成功率和时延，它们反映终端和视频服务器建立连接过程的性能。

会话建立成功率=会话建立成功次数（TCP_SYN_ACK)/会话建立申请次数（TCP_SYN) (1)

会话建立时延为会话建立成功（TCP_SYN_ACK）到会话建立申请（TCP_SYN）的平均时延。

发生了TCP建链不一定会Get，但是发生了Get一般肯定会发生缓冲（初始缓冲请求，要求下数据）。

1.2 流媒体Get响应成功率

流媒体Get响应成功率指标包含业务建立成功率和时延，他们反映会话连接到视频开始播放的性能。在信令中，业务建立申请标识为Get、Post（Get和Post最大的区别是一个是直接找视频源，一个是在服务器分析后得到视频源）、Respone，会话建立成功标识为第一个数据分组片成功传输。

业务建立成功率=业务建立成功次数（First_TCP_Segment_Data)/业务建立申请次数（HTTP_Get) (2)

业务建立时延=业务建立成功到业务建立申请的时延

1.3 初始缓冲成功率

初始缓冲成功率以发往内容服务的Get为请求次数，以真正完成缓冲respone为成功次数（实际上现网视频服务器与内容源服务器均不为同一服务器，所以还牵涉到DNS查询内容源服务器、TCP建链内容源服务器，真正下载视频内容源流程）。

现网此部分成功率为96.92%。对于失败原因进行大类细分，主要包括终端原因（2.29%）、上游原因（55.47%）、无线原因（36.33%）、其它原因（5.92%）。

初始缓冲成功率=完成缓冲次数（Respone)/发往内容服务的Get次数 (3)

现网所有的失败主要集中在这一步上面。

1.4 流媒体播放成功率

流媒体播放成功率=sum(传输足够初缓时间播放数据的次数)/sum(合成视频请求总次数) (4)

初缓时间：首次播放视频所需的缓存时间。不同网站模型略有不同。需要分网站做不同的配置。

合成视频：一个视频文件，根据不同网站的播放模型，可能分成多个会话和Get请求，需要对一个视频的多次请求进行关联合成。

图1为某些小区视频业务接入性能统计。

实际上，流媒体播放成功率=流媒体Get响应成功率×初始缓冲成功率，可以看出来视频播放失败的主要原因就是初始缓冲失败（TCP建立和Get响应成功率几乎都是100%）。

选择3天晚忙时的小区视频业务数据进行分析，找出视频请求次数大于50，成功率低于90%小区共计126个。对这些小区进行分析，其中高负荷占比65%，高干扰占比20%，弱覆盖占比25%，无法得到具体原因的占比24%。针对未找到原因的小区进行进一步分析，终端层面没有聚合性。视频源方面有一定聚合性，其中未找到原因的30个小区中，有60%小区（18个）缓冲失败视频源IP均有一定的汇聚性（同一时间段指向同一网站，如iqiyi，或者指向同一个IP段）。

因此在对TOP小区进行分析的时候，重点关注该小区失败时候对应内容源服务器是否相对集中，对应该内容源服务器的成功比例，对应该内容源的下载速率是否过低，如果过低，则需要查看该时段的利用率。

1.5 视频业务端到端接入性感知评估

通过上文分析，视频业务端到端感知评估之接入性评估体系如图2所示。

2 流畅性

视频业务观看过程中，主要关注首次播放时延、播放过程是否卡顿、用户拖拽后是否能够马上播放等感知，针对以上3个用户感知，分别构造指标一一对应。

图1 部分小区视频业务接入性能统计

图2 视频业务端到端接入性感知评估

2.1 首次播放等待时延

首次播放等待时延：当用户发起播放视频的行为之后，到终端设备开始播放视频所需的等待时间。

首次播放等待时延=TCP三次握手建立时延+TCP三次握手至Get时延+流媒体Get响应平均时延+Get的ACK到首数据分组的时延+视频流媒体初始缓冲时延 (5)

视频流媒体初始缓冲时延：由于视频终端开始播放视频时，并不会通知网络侧（客户端行为），因此认为当网络传输速率大于缓冲所需速率时，终端的等待时延为0。

Get响应时延主要观察与视频服务器时延关系。与前面的TCP建链时间进行比较，因为一般TCP建链时间与视频服务器是同一个地址，这样我们可以得到来回的RTT时间，一旦这个时间较小，那么Get响应时间长就是视频服务器自己处理时间的长度过长造成的，再看这个小区下面针对这个视频服务器是不是所有的内容源Get都比较慢，做进一步的确定。

在进行缓冲时延分析时，主要观察内容服务器时延和小区当时利用率。

2.2 卡顿

视频播放卡顿次数：当用户浏览视频网站播放视频时，当视频数据下载数据量小于播放需求数据量时，认为视频会产生卡顿。

卡顿判定：缓冲剩余数据量＜播放需求数据量

缓冲剩余数据量=下载数据量-已经播放数据量 (6)

针对卡顿现象，采用卡顿频次和卡顿时长占比二个维度进行评定。

2.2.1 卡顿频次

按照用户级或者小区级每分钟产生的卡顿次数为评定标准。能直接反应用户或者小区级的卡顿频次。安徽全网小区级卡顿频次为0.08。

2.2.2 卡顿时长占比

当客户端和服务器端的流媒体处理能力或者网络传输质量等原因导致用户业务出现卡顿后，待网络缓冲完成继续播放。一个视频播放过程可能会出现1次或多次卡顿。下载速率不同，每次卡顿到播放所需等待时间不同。视频卡顿时长占比指的是一次视频播放行为中，除去首次缓冲所需时间，其余播放时出现的暂停时间总和，占已经播放的时间比例，该比例越小，用户感知越好。

卡顿时长占比=卡顿累计时长/视频播放时长 (7)

卡顿累计时长：当检测到卡顿时启动定时器到缓冲数据量＞码率（具体秒数由视频服务器决定）时停止计时。该时间差的累计值。

安徽全网卡顿时长占比0.97%。

2.3 拖拽后表现

现网视频流多为HLS格式，Http Live Streaming是由Apple公司定义的用于实时流传输的协议，HLS基于HTTP协议实现，传输内容包括两部分，一是M3U8描述文件，二是TS媒体文件。

一旦用户发生拖拽，其实拖拽进度条前的视频不在下载，而是根据M3U对应的位置小视频段重新下载。此时如果用户下载速率高于码率（视频码率+音频码率），可以认为当网络传输速率大于缓冲所需速率时，终端的等待时延较低。

图3 视频业务端到端流畅性感知评估

视频速率指标反映用户播放视频时，多媒体文件在网络上传输的速率。视频文件在网络上以分段的形式进行传送，在用户终端上也以段的形式先后播放。视频格式以恒定的视频码流的形式通过终端处理器形成图像和声音，这种恒定的码流需求如果高于速率，则视频播放会出现卡顿以缓冲所需数据，对用户造成影响。

分析过程中，以用户或者小区为粒度，统计单用户或者单小区中码率需求大于下载速率的比例。以安徽为例，全网平均下载速率1.355 Mbit/s，视频码率平均615 kbit/s，音频码率平均64 kbit/s，对于网速要求平均为680 kbit/s，所以我们选定小区流媒体下载速率过低的标准定义为680 kbit/s。

2.4 视频业务端到端流畅性感知评估

通过上文分析，视频业务端到端感知评估之流畅性评估体系如图3所示。

3 TD-LTE视频业务端到端感知评估体系构建

从接入性和流畅性两个维度来构建TD-LTE视频业务端到端感知评估体系，体系评估结构图如图2、3所示。

使用这个评估体系，对合肥移动的视频业务端到端感知进行评估，发现现网在接入性能上，主要就是初始缓冲成功率存在问题；在流畅性方面，主要是存在卡顿的问题。

初始缓冲成功率的问题原因中，上游原因主要集中在视频源服务器侧分组丢失率高、传输受限。上游原因中在视频源方面有一定聚合性，有60%小区（18个）缓冲失败视频源IP均有一定的汇聚性（同一时间段指向同一网站，如iqiyi，或者指向同一个IP段）。无线侧原因主要集中在下行RTT时延过大、终端请求片段间请求时延（终端与视频源内容服务器之间采用长连接keepAlive是否决定片段间是否要再次建链/Get）过长。对部分高失败小区进行小时间详细分析，结论如下：根据合肥小区视频缓冲成功率（无线原因）与MRO覆盖率进行分析，TCPrtt时延与MR覆盖率相关性较强，相关度系数达到0.83。后期优化思路应该集中解决这些小区弱覆盖为主。

对卡顿原因进行大类细分，主要包括终端原因（6.36%）、上游原因（32.32%）、无线原因（58.7%）、其它原因（2.61%）。上游原因主要集中在视频源服务器侧分组丢失率高、传输受限。上游原因中在视频源方面有一定聚合性，有56%卡顿事件关联视频源IP均有一定的汇聚性（同一时间段指向同一个IP段）。无线侧原因主要集中在下行RTT时延过大、终端请求片段间请求时延（终端与视频源内容服务器之间采用长连接keepAlive是否决定片段间是否要再次建链/Get）过长。对此部分高失败小区进行小时间详细分析，结论如下：根据合肥小区视频缓冲成功率（无线原因）与MRO覆盖率进行分析，TCPrtt时延与MR覆盖率相关性较强，相关度系数达到0.65。后期优化思路应该集中解决这些小区弱覆盖为主。

本文提出了基于接入性和流畅性构建的一种TDLTE视频端到端业务评估体系，以此来定位现网中视频业务中影响用户感知的主要问题所在，以及一些感知较差的小区，进行有针对性的优化，提升系统性能。