基于用户体验交互的流媒体质量监测报告的实现方法

摘要

一种基于用户体验交互的流媒体质量监测报告的实现方法，先设置自定义的双向传输的体验质量QoE交互协议及其相关网络环境参数和业务性能参数，服务器监测流媒体的发送状况，客户端监测流媒体的接收状况并评价其用户体验质量，分别生成S-C报告和C-S报告再经由网络传输，在客户端和服务器之间实现流媒体质量监测报告的实时交互，从而对两者之间传输的流媒体业务质量实现实时监测。本发明是根据现有网络技术基础，再广泛吸取目前多种流媒体质量监测、监控技术的最新成果，进行综合优化而提出的。其操作步骤简单，占用的带宽资源少，计算难度低，也不用更改或升级现有网络，实现容易，对现有网络中流媒体的运营和管理有重要意义，有较好的推广应用前景。

说明书

技术领域

本发明涉及一种基于用户体验交互的流媒体质量监测报告的实现方法，属 于多媒体通信技术领域。

背景技术

流媒体是一种使音频、视频和其他多媒体元素在Internet及无线网络上以实 时的、无需下载等待的方式进行播放的技术。流媒体技术能给用户提供持续不 断的音视频数据流，满足用户在线观赏动态影音的需求。

随着计算机网络的快速发展，以及第三代移动通信技术3G(3rd-generation) 和无线局域网络WLAN(Wireless Local Area Network)等无线网络的迅速发展， 流媒体业务的应用越来越广泛。在有线网络中应用的重要领域为交互式网络电 视IPTV(Interactive Personal TV)，而在移动网络领域主要为移动流媒体。

但是，在现有网络中，尤其是在频谱资源非常紧张的无线网络上提供流媒 体业务时，网络延时、拥塞等网络恶劣环境往往会使多媒体数据包的传输产生 延时、丢包、抖动或乱序等情况，从而使流媒体的业务质量恶化，给用户体验 造成不利影响。对于网络运营商和服务提供商来说，需要采用有效、准确的流 媒体质量评测方案来监控其业务传输性能，进而优化网络性能，提高服务质量。

然而，目前的流媒体质量评测方法和流媒体传输与控制协议的实际使用都 不理想，没有真实地反应业务质量，也未能对流媒体业务实现实时评测和监控， 其主要原因是客户端与服务器未能及时进行信息交互：一方面，客户端不能及 时获知网络环境条件，更谈不上掌握网络环境对用户体验质量造成的影响；另 一方面，流媒体服务器也不能实时、准确地获知客户端的用户体验质量，以便 及时调整网络参数，这是当前流媒体业务质量监控中存在的两大问题。

下面介绍有关移动流媒体质量报告的现有技术简况：

(1)利用网络参数，直接在网络侧预测流媒体质量。例如，文献《Research  on Monitoring Quality of 3G Streaming Media Service》[C](刊于“International  Conference on Communication Systems，Networks and Applications”2010)，利用网 络端的丢包数、丢包率、包时延、包抖动等参数对流媒体质量进行评测。文献 《No-Reference Quality Assessment for Networked Video via Primary Analysis of  Bit Stream》[J](刊于“IEEE Transactions on circuits and video technology”2010)， 考虑了编码端量化步长、帧率和网络端丢包等参数的影响，并在时域进行加权， 最终实现对视频流质量的客观评价。IETF RFC4445还提出一种测量IPTV传输质 量的方法：MDI(Media Delivery Index)，也仅仅使用两种网络参数：DF(Delay  Factor)和MLR(Media Loss Rate)进行测量。

(2)利用报告的形式，将客户端的业务能力上报给流媒体服务器。例如， 中国发明专利申请《一种上报能力的方法及相关处理装置》(申请号 200810056281.7)介绍了一种上报方法，但该方法仅限于将客户端的业务能力标 识上报到服务器，不具有交互性；而且客户端的业务能力的判断不是以用户的 感知为标准，这种能力的判断结果只能为服务器调整网络状态提供参考，不能 作为完全依据。中国发明专利申请《用于交叉参考相关应用来报告流媒体质量 的方法和设备》(申请号200780048832.9)介绍了另一种交叉参考报告流媒体质 量的方法，该方法主要侧重于报告的方法，没有涉及报告的内容及其获取方式。 中国发明专利申请《网络电视业务管理方法及系统、服务质量管理节点》(申请 号201010174116.9)涉及的一种网络电视业务管理方法、系统和服务质量管理 节点，能够克服IPTV业务指标无法自动测量的缺陷，但是IPTV终端上报的参 数仅有收视率、请求成功率、丢包率、丢帧率和抖动等，没有涉及音视频业务 本身的传输与观赏的体验质量。

(3)在传统的RTP/RTCP/RTSP协议簇中，对业务传输质量起到控制作用 的是RTCP协议，RTCP协议利用网络参数来判断和评价业务质量，并以此调整 网络带宽等参数。但是，RTCP协议并没有对用户的业务体验质量进行监测与分 析，因此不能完全真实地反映客户端的流媒体业务质量。

从以上分析可以看出，在客户端独立进行流媒体体验质量评价的基础上， 结合网络参数实施综合评价，并将客户端相关参数实时上报给流媒体服务器的 方法，至今国内外都还未见有相关文献发表，同时，目前已有的协议在基于用 户体验的业务质量判断与控制方面也有诸多不足。

发明内容

有鉴于此，本发明的目的是提供一种基于用户体验交互的流媒体质量监测 报告的实现方法。本发明是针对目前出现的流媒体质量监控需求，并充分考虑 现有网络可实施的技术基础，再广泛吸取目前多种流媒体质量监测、监控技术 的最新成果，进行综合优化而提出的。与现有各种质量监控技术方案相比较， 本发明方法是在现有的网络技术基础上，充分利用网络中已经部署的相关先进、 成熟技术，通过自定义的双向传输的体验质量QoE(Quality of Experience)协议 传输流媒体的用户体验质量及相关参数，在客户端与服务器之间实现实时交互， 很好地解决了上述流媒体业务质量监控中的两大问题。

为了达到上述目的，本发明提出了一种基于用户体验交互的流媒体质量监 测报告的实现方法，其特征在于：首先设置自定义的双向传输的体验质量QoE 交互协议及其相关网络环境参数(Network Environment Parameters)和业务性能 参数(Service Performance Parameters)，服务器监测流媒体的发送状况，客户端 监测流媒体的接收状况并评价其用户体验质量，分别生成服务器到客户端的S-C 报告(Server-Client Report)和客户端到服务器的C-S报告(Client-Server Report)， 再经由网络传输，在客户端和服务器之间实现流媒体质量监测报告的实时交互， 从而对两者之间传输的流媒体业务质量实现实时监测。

本发明基于用户体验交互的流媒体质量监测报告的实现方法，利用自定义 的双向传输的QoE交互协议及相关参数，使流媒体客户端能够及时获取业务传 输时的网络环境参数，分析有线和无线网络条件对流媒体业务的传输影响，并 结合设定的流媒体业务质量评价方法获得业务用户的体验质量。流媒体服务器 又通过与客户端的实时交互，了解、获悉客户端用户对流媒体业务的体验质量， 以便对网络条件或流媒体业务参数适时做出调整，提高业务的服务质量。

从网络运营商的角度看，本发明方法占用的带宽资源很少，可以直接应用 于现有网络，不用对现有网络进行额外的更改与升级；从网络客户的角度看， QoE交互报告的传送并不会影响流媒体的传输播放，反而有利于业务质量的评 价和提升。

再者，本发明方法的操作步骤简单，计算难度低，容易实现，对流媒体业 务的实际运营和管理具有重要意义，在提升流媒体业务质量的应用中，具有较 好的推广应用前景与价值。

附图说明

图1是本发明基于用户体验交互的流媒体监测质量报告方法的流程图。

图2是本发明QoE协议实现示意图。

图3是本发明S-C报告结构示意图。

图4是本发明C-S报告结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图和实施例对 本发明作进一步的详细描述。

本发明是一种基于用户体验交互的流媒体质量监测报告的方法：首先设 置自定义的双向传输的体验质量QoE交互协议及其相关网络环境参数和业 务性能参数，服务器监测流媒体的发送状况，客户端监测流媒体的接收状况 并评价其用户体验质量，分别生成服务器到客户端的S-C报告和客户端到服 务器的C-S报告，再经由网络传输，在客户端和服务器之间实现流媒体质量 监测报告的实时交互，从而对两者之间传输的流媒体业务质量实现实时监测。

参见图1，介绍本发明方法的各个具体操作步骤：

步骤1，设置自定义的双向传输的QoE交互协议，并定义其中的网络环境 参数和业务性能参数，该双向传输的QoE交互协议规定：服务器到客户端的S-C 报告携带网络环境参数，客户端到服务器的C-S报告携带业务性能参数。

本发明自定义的双向传输的QoE交互协议在网络中的传输情况，如图2所 示，分别要求在服务器和客户端发送的S-C报告和C-S报告的结构组成如下：

服务器到客户端的S-C报告由报头与数据块组成，其中，报头包括：

协议版本号(Protocol Version)：当前QoE协议的版本号，字段长度：8bit， 本发明实施例中的版本号为1；

数据包类型(Packet Type)：当前报告的类型：1为S-C报告，2为C-S报 告，字段长度：8bit；

数据包长度(Packet Length)：当前报告的数据包长度，单位：byte，字段 长度：16bit；

数据块用于携带下述一个或多个网络环境参数：

多媒体编码类型(Code Type)：音频和/或视频数据的编码格式信息，即采 用设定的压缩技术，将某个音视频格式的文件转换成另一种音视频格式文件的 方式，字段长度：16bit；音频数据的常用编码类型有G.711、G.723，视频数据 的常用编码类型有MPEG-2、H.263、H.264；

多媒体文件长度(Length)：音频和/或视频文件的长度，单位：秒，字段长 度：16bit；

发送时间戳(Send Timestamp)：发送当前流媒体数据包的时钟信息，字段 长度：32bit；

服务器发包数(Packets Sent)：服务器累计发送到客户端的流媒体数据包数， 字段长度：32bit；

发送字节数(Bytes Sent)：服务器累计发送到客户端的流媒体字节数，字段 长度：32bit；

发送速率(Send Rate)：服务器发送流媒体业务数据的平均比特率，单位： 比特/秒；字段长度：32bit；

双向时延(Roundtrip Delay)：流媒体测试包从服务器发送到客户端，再返 回服务器的传输时间，单位：秒，精度为微秒；字段长度：32bit；

服务器扩展字段(Expand)：用于以后协议扩展时的备用字段，字段长度： 256bit；

客户端到服务器的C-S报告由报头与数据块组成，其中，报头包括的协议 版本号，数据包类型、长度的字段位长和涵义都与S-C报告相同，不再赘述； 数据块用于携带下述一个或多个业务性能参数：

接收包数(Packets Received)：客户端累计接收到的流媒体数据包数，字段 长度：32bit；

接收字节数(Bytes Received)：客户端累计接收到的流媒体字节数，字段长 度：32bit；

丢包率(Packets Loss Rate)：丢包数与服务器发包数之比，其中丢包数为服 务器发包数与接收包数的差值，字段长度：8bit；

抖动(Jitter)：两个流媒体数据包相对传输时间的差值，即两个流媒体数据 包的接收时间戳和发送时间戳之差的差值，单位：秒，精度为微秒；字段长度： 24bit；

接收时间戳(Receive Timestamp)：接收当前流媒体数据包的时钟信息，字 段长度：32bit；

接收速率(Receive Rate)：接收流媒体业务数据的平均比特率，单位：比特 /秒，字段长度：32bit；

音频质量QoA(Quality ofAudio)：利用基于抖动扩展改进的E-Model算法 在客户端评价音频质量，字段长度：32bit；

视频质量QoV(Quality of Video)：利用基于中国发明专利申请《基于关键 帧图像质量加权的无参考视频质量客观评价方法》(申请号：201110021600.2) 的修正方法在客户端评价视频质量，字段长度：32bit；

音视频时间差(Time Difference)：同一流媒体文件中原来同步的一对视频 包与音频包到达客户端的时间戳之差，用于衡量音视频的同步性，单位：秒， 精度为微秒；字段长度：32bit；

连接等待时间(Time Waiting)：从用户业务请求到客户端开始呈现业务的 延时时间，单位：秒，精度为微秒；字段长度：32bit；

客户端扩展字段(Expand)：用于以后协议扩展时的备用字段，字段长度： 256bit。

步骤2，服务器测试、记录与统计网络环境参数，并按照QoE协议规定生 成S-C报告，再发送给客户端。该步骤2包括下述操作内容：

(21)服务器测试、记录多媒体编码类型、多媒体文件长度和发送时间戳， 同时统计服务器发包数P_send和发送字节数B_send，并按照下述公式计算包括发送速 率和双向时延的网络环境参数，其中，

发送速率式中，B″_send和B′_send分别为服务器在T″_{server，send}和 T″_{server，send}两个不同时刻统计的发送字节数；

双向时延T_RD＝T_{server，recv}-T_{server，send}，式中，T_{server，recv}和T_{server，send}分别为服务器接收和 发送测试包的时间；

(22)服务器将获取的流媒体业务的上述网络环境参数写入QoE协议报文 的对应字段中，生成S-C报告，并通过网络发送给客户端。

步骤3，客户端测试、记录与统计接收的流媒体信息，并利用S-C报告计算 该流媒体的业务性能参数，同时，评价该流媒体业务的用户体验质量；然后按 照QoE协议规定生成C-S报告，再发送给服务器。

该步骤3包括下述操作内容：

(31)客户端测试、记录接收时间戳和连接等待时间，同时统计接收包数P_recv和接收字节数B_recv，并按照下述公式利用S-C报告信息计算包括丢包率、抖动、 接收速率和音视频时间差的业务性能参数，其中，

丢包率式中，P_loss＝P_send-P_recv；

抖动式中，自然数上标m、n分别为发 送流媒体的两个不同数据包的序号；

接收速率式中，B″_recv和B′_recv分别为T″_{client，recv}和T′_{client，recv}两 个不同时刻统计的接收字节数；

音视频时间差客户端接收同一流媒体文件中原来同步的 一对视频包的时刻与音频包的时刻之差，式中，自然数上标k为流媒 体文件中的数据包序号；

(32)客户端对流媒体业务的音频和/或视频的用户体验质量进行评价；其 中，

音频质量评价方法，采用基于抖动扩展修正的E-Model算法： QoA＝93.2-I_d-I_e-I_j，即引入抖动因子I_j描述抖动对语音质量的影响：式中，I_d和 I_e为原E-Model算法中分别因语音信号传输延时和丢包造成的语音质量损伤因 子，I_j为扩展修正而新增的抖动影响因子，且I_j＝I_jd+I_jl；式中，

I_jd是因网络传输时延造成的抖动影响因子：I_jd＝a₁×J+a₂×(J-a₃)×f(J-a₃)， 式中，参数a₁、a₂分别为反映网络性能的经验参数，实施例是根据原E-Model 算法中对传输时延造成的质量损伤因子的各种参数：回音响度、背景噪声、响 度评测值而计算得到：a₁＝0.029，a₂＝0.194；参数a₃为用双向时延描述抖动严重程 度的门限值，其数值取决于丢包率R_loss：当R_loss≤i时，当R_loss＞i 时，a₃＝0；式中，i为丢包率的阈值，此处设i＝5％；函数f为阶跃函数，其数 学表达式为：J≤a₃，f(J-a₃)＝0，J＞a₃，，f(J-a₃)＝1；该式表示：若抖动J大于a₃， 会对语音质量造成严重影响；

I_jl是因缓冲区溢出造成的抖动影响因子：式中，b为根据不同 音频编码器选取不同数值的系数，因实施例使用G.723.1.B-6.3编码器，故b＝10.3； T为缓冲区的字节容量，该实施例中的T＝1MB；c为该音频编码方式下占用缓冲 区的比例系数，c＝10.81％；R_recv为接收速率；

视频质量评价方法，利用中国专利申请《基于关键帧图像质量加权的无参 考视频质量客观评价方法》(申请号：201110021600.2)的方法进行评价，并利 用S-C报告与丢包率、抖动和/或接收速率修正评价结果。假设使用原来的专利 申请方法的视频质量评分为qov，再利用丢包率R_loss进行修正，即 QoV＝qov×(1+d×R_loss)。本发明实施例测试的视频为Foreman序列(总帧数为250 帧)，该视频分辨率为常用的标准化图像格式QCIF(Quarter Common Intermediate  Format，在H.323协议簇中，规定了视频采集设备的标准采集分辨率的大小为 176×144像素)，属于前景、背景均运动且运动相对缓慢的视频类型，设参数d＝10。

该步骤中，音频质量评价方法和视频质量评价方法都采用5分制评价质量 优劣，其中5分最好，1分最差。

(33)客户端将获取的上述参数写入QoE协议报文的对应字段中，生成C-S 报告，再通过网络传送到服务器。

步骤4，服务器将步骤2和3分别生成的一对QoE协议报文对应存储，以 供后续分析流媒体的用户体验质量与网络环境的关系，为后期监控流媒体业务 质量提供依据。该步骤4包括下述操作内容：

(41)服务器将其在步骤2生成的S-C报告和在步骤3接收的C-S报告， 作为一对QoE协议报文对应存储于数据库；

(42)利用模糊评价算法分析流媒体用户体验质量与网络环境的关系，为 后期监控移动流媒体业务质量提供依据：首先确定包括网络环境参数和业务性 能参数的各种评价指标，以及每个评价指标的衡量标准；再通过层次分析法分 别确定每个评价指标的权重，以便对评价对象的相关因素合理量化；最后构造 模糊隶属度函数，运用模糊数学方法进行分类决策，得到流媒体用户体验质量 与网络环境的关系。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在 本发明保护的范围之内。