CN1839597B

CN1839597B - 对无线通信网络的质量体验(qoe)度量

Info

Publication number: CN1839597B
Application number: CN200480024040.4A
Authority: CN
Inventors: 加姆泽·塞奇金; 拉加文德拉·C·纳加拉吉; 拉利特·萨尔纳; 艾伦·曾; 贾扬克·M·巴洛德; 马彦达
Original assignee: Vidiator Enterprises Inc
Current assignee: Vidiator Enterprises Inc
Priority date: 2003-08-21
Filing date: 2004-08-23
Publication date: 2010-07-21
Anticipated expiration: 2024-08-23
Also published as: DE602004025490D1; US20050089043A1; EP1678888B1; EP1678888A1; TW200518532A; BRPI0413812A; ATE457574T1; WO2005022852A1; JP2007503741A; CN1839597A; MXPA06002026A; US7599307B2; CA2536391A1

Abstract

本发明涉及一种质量体验(QoE)架构，其提供一评估一终端用户在一诸如2.5G或3G网络的移动无线通信环境中，或在任何其它无线或固线通信环境中的体验的技术。所述架构可结合媒体流应用而使用，且使得能够在提取结果中组合网络层、传输层、编码解码层和应用层测量。所述提取结果可用于监控和改进(如果需要)终端用户在剧烈可变的网络条件下的体验。

Description

对无线通信网络的质量体验(QOE)度量

相关申请案的交叉参考

本申请案要求2003年8月21日提交的美国临时专利申请案第60/497，447号，和2004年1月26日提交的美国临时专利申请案第60/539，536号的权利，其中这两个临时申请案被让转让给相同的受理人作为本申请案，且其全文以引用的方式并入本文。

技术领域

本揭示一般涉及通信网络，且详细来说但非排外地，涉及评估终端用户在一移动无线和/或固线通信环境中的体验或质量体验(QoE)的技术。

背景技术

随着媒体压缩及无线网络基础结构的改进，媒体流成为终端用户、内容提供者、无线操作者及其它实体的有前途的技术领域。尽管将有更多可用于无线技术的带宽，诸如2.5G或3G，且尽管某些先进压缩技术可使非常低位率流成为可能，但对于无线环境仍存在固有问题。

遇到所述问题的无线流应用的领域包括实时媒体应用(包括音频和视频流)、实时音频应用(诸如现场音乐或体育广播)、离线媒体应用和离线音频应用。不同于有线网络，无线网络受高有效数据包丢失率和间歇数据包延迟影响。可由诸如网络阻塞、位错误率、或除诸如衰减(其为无线网络的固有特征)的效应外，在用户设备处的数据溢流的因素而导致数据包丢失和延迟。

除了数据包丢失外，还存在对终端用户所接收的媒体产生不利影响的其它因素。任一这些因素对用户体验的影响可极大地取决于通信信道条件、用户设备特征、环境条件、通信期间出现的有意或无意事件、或其它影响而变化。

所有上述和其它因素最终对终端用户在媒体传递和消耗的情况下的一移动无线通信环境中的质量体验(QoE)产生不利影响，其中流仅是媒体传递的一个实例。这些相同或其它因素还可对终端用户在一固线通信环境中的QoE产生影响。

发明内容

一方面提供一种可用于无线通信环境中的方法。所述方法包括定义指示影响无线通信环境中的质量的一特征的至少一个质量体验(QoE)度量。在客户端与服务器之间执行一协商，以确定在所述客户端与所述服务器之间的会话期间使用至少一个QoE度量中的哪个，且所述QoE度量表示为一个接受的QoE度量。在所述会话期间收集一个或多个接受的QoE度量的数据，且所述度量数据在所述客户端与所述服务器之间传送。

附图说明

参考下图而描述非限制性和非详尽的实施例，其中在各种视图中，除非另有指定，否则相同的参考数字指相同的部件。

图1是说明QoE架构组件和其根据一个实施例的操作的功能方框图。

图2说明了QoE协商的第一实施例。

图3说明了QoE协商的第二实施例。

图4是一更详细展示的用于图1的QoE架构的QoE模块的实施例的方框图。

具体实施方式

在以下描述中，给定许多特定细节以提供对实施例的彻底理解。然而所属领域的相关技术人员将认识到，本发明可脱离一个或多个特定细节或使用其它方法、组件、材料等实施。在其它实例中，未展示或详细描述众所周知的结构、材料或操作以避免使本发明的方面模糊不清。

整个此说明书的参考“一个实施例”指结合实施例而描述的特定特点、结构或特征包括在至少一个实施例中。因此，短语“在一实施例中”在整个此说明书中的出现不必都指相同的实施例。此外，在一个或多个实施例中，可以任何适当的方式组合所述特定特点、结构或特征。

除非本文另有规定，整个此说明书和随后的申请专利范围，词语“包含(comprise)”和其变化，诸如“包含(comprises)”和“包含(comprising)”可理解为一开放的包括意义，即“包括，但不限于”。

本文提供的标题仅出于便利目的，且不解释申请专利发明的范畴或涵义。

作为一概述，QoE架构的一个实施例提供一种技术以监控并解决在网络组件之间的通信期间可能出现的QoE问题。举例而言，当将媒体从服务器传送到客户端时，可能存在可在一服务器与一客户端(例如终端用户设备)之间的通信期间出现的QoE问题。一个实施例的QoE架构的组件包括起始和终止过程，其分别定义一个会话的开始和结束；一协商过程，其中服务器和客户端协商在会话期间使用哪个度量；一个或多个度量，其被定义和实施(例如度量值的收集/测量)；度量值的会话期间的传输，所述度量值与以一预定频率的度量相关且用于在协商期间接受的所有会话的预定范围；和对所述度量值的分析/应用以评估QoE和调整条件，使得如果需要，可改进所述QoE。

本文将描述在无线通信网络中的QoE架构的情况下的各种实施例。应了解本发明不限于无线环境。QoE架构的实施例可应用于固线通信网络(包括同时包含固线和无线元件的通信网络)或可体验QoE问题的任何其它网络。

仅出于说明和解释的原因，本文使用标准和/或协议特定的术语、过程、格式或其它协议特定的实施例来描述各种实施例。举例而言，关于会话描述协议(SDP)、实时流协议(RTSP)和其它标准/协议来描述某些实施例。这些特定描述的实施例不期望限制本发明。相反，所述标准/协议特定的描述仅用期望当结合众所周知的标准/协议而实施时，协助读者(或一所属领域的技术人员)理解某些实例实施例的操作和特点。通过本文这些特定描述，所属领域的技术人员能获得与对于其它标准/协议(当前存在或未来将开发)或对于出现QoE问题的其它应用来说如何制作和使用本发明的其它实施例相关的知识。

一个所述特定但非限制的QoE架构的实例实施例通过向其提供标准的兼容扩充而平衡诸如SDP(参阅例如RFC 2327：SDP：Session Description Protocol，Handley M.和Jacobson V.，1998年4月)[2]和RTSP(参阅例如RFC 2326：Real Time Streaming Protocol(RTSP)，Schulzrinne H.，Rao A.和Lanphier R.，1998年4月)[3]的现有流描述和控制协议。一实施例还允许供入现有的基于标准的报告机制，诸如RTCP(参阅例如RFC 3550：RTP：A Transport Protocol for Real-Time Applications，Schulzrinne H.等人，2003年7月)[4]和RTCP XR(参阅例如RFC 3611：RTP Control Protocol Extended Reports(RTCP XR))，T.Friedman等人，2003年11月)[5]。指派到每个这些参考的方括号[]中的数字将随后在整个此说明书中用作一简略技术以指代这些参考。

QoE架构的一实施例还定义一组QoE参数(度量)，诸如损坏持续时间、再缓冲持续时间、起始缓冲持续时间、连续丢失、帧速率偏差和/或抖动持续时间。这些或其它适当定义的度量可单独地或在任何实践组合中使用。

图1展示了根据一实施例的QoE架构中所包含的组件的图表。展示了以QoE和质量服务(QoS)协议的方式彼此通信的服务器100和客户端102。一适当但非限制的所述客户端102的实例是支持QoE协议的任何兼容3GPP版本6的手持机/播放器，且最小组的经定义的度量(例如在S4-040308工作草案26234-050，3GPP TSG-SA4会议#31，Montreal，Canada，2004年5月17-21日中定义的)[1]可与所述服务器100或网络组件通信。客户端102的实施例包括QoE客户端模块118，其将随后在下文中进一步详细描述。

服务器100的实施例将併入一动态带宽调节(DBA)模块104、一质量服务(QoS)模块106和一QoE服务器模块108。所述QoS模块106平衡协商的最大位率、保证位率和所述客户端102与所述网络间的最大传输延迟参数。其还平衡任何其它网络层数据，诸如丢失、延迟和其它。在2003年5月30日提交的题为“METHOD AND APPARATUS FORDYNAMIC BANDWIDTH ADAPTATION”的美国申请案第10/452,035号中进一步详细描述所述DBA模块104的实例实施例，其转让给相同受让人作为本申请案且其全文以引用的方式併入本文。

所有这些模块共同确保用户体验如同期望的那样，且在整个流会话过程中甚至在剧烈变化的网络条件下被监控。一服务提供者/操作者110向一***监控模块112、向一帐务处理模块114(假定手持机已被验证)或向任何其它模块馈入QoE服务器模块108输出。一个实施例的QoE服务器模块108可经定制以满足***其中的组件的需要，且可提供QoE度量和QoS参数的统计分析。

当所述实施例的QoE服务器模块108展示为驻存在服务器100中时，应了解，所述QoE模块(或任何其它模块)可适当地位于无线或固线网络中的其它地方。举例而言，所述QoE服务器模块108可位于一代理设备、路由器、交换机或其它网络组件，包括在某些实施例中的客户端102处。

QoE架构特点之一是向服务提供者110提供一评估终端用户体验的构件。一个实施例的QoE架构可用于帐务处理或手持机/播放器检测的目的。这个用途可被加强，其限制条件为可基本上确保受信任的度量反馈。

如下组织以下描述。部分I描述QOE协议方面。部分II描述QOE度量方面。部分III描述QOE服务器模块方面。部分IV描述QOE客户端模块方面。

I.QoE协议

在一特定但非限制的实施例中，基于RTSP和SDP的协议扩充用于在(例如)数据包交换流服务客户端(PSS)102与PSS服务器100之间的QoE度量的传输和协商。当然，所述QoE度量的传输和协商可使用对于RTSP和SDP是替代的或是额外的其它机制。图1中描述了一QoE协议116的协商和传输过程的一实例实施例。

如果度量信息嵌入在SDP数据中，那么QoE度量协商以对从客户端102发送的DESCRIBE请求响应开始。对于本机存储的含有QoE度量属性的SDP的情况，所述协商以客户端102的SETUP请求开始。如果PSS客户端102支持QoE度量，那么所述客户端102为正在建立的会话阶层或媒体阶层发送一含有选定(即被所述客户端102接受的)/修改(用于再协商)的QoE度量的SETUP请求。

在接收此SETUP请求后，服务器100返回具有“接受的”QoE度量(即等同于客户端102的请求中的度量和度量值且被服务器100接受的度量和度量值)和“再协商”QoE度量(即不等同于客户端102的请求中的度量和度量值且由服务器100修改用于再协商的度量和度量值)的RTSP响应。所述“接受的”QoE度量的回复是为再次确认所述客户端102。服务器100还可拒绝由客户端102作出的改变(即拒绝“再协商”QoE度量)。如果服务器100拒绝所述改变，那么服务器100设定新值并将修改的度量再发送回客户端102，或服务器100忽略所述“再协商”度量且不对其再次确认。任何被服务器100确认为“接受的”QoE度量不再协商(即，其无需在下一RTSP请求中的“3GPP-QoE-Metrics”标头中被再次发送，且无需在下一RTSP响应中被再次确认)。

如果服务器100不认可由客户端102完成的修改，那么服务器100和客户端102继续再协商直到RTSP PLAY请求和服务器100回复RTSP PLAY响应中的“接受的”QoE度量。客户端102可通过提出一RTSP PLAY请求而终止协商过程。应注意，每次在一RTSP请求中发送“QoE度量”标头字段，其还存在于对应于那个特定请求的响应中。另外，响应的接收者假定其它终端不支持QoE度量。

如果在RTSP信令传输开始时没有发送DESCRIBE-RTSP响应对(例如，请参阅图2)，那么表示通过其它构件接收SDP描述。如果所述SDP含有“3GPP-QoE-Metrics”属性，那么以与上文所述的方式相同的方式发生协商(即，以含有“3GPP-QoE-Metrics”标头的SETUP请求开始)。如果所述SDP不含有所述“3GPP-QoE-Metrics”属性且服务器100仍要检查客户端102是否支持QoE协议，那么所述服务器100包括在SETUP响应中含有起始QoE度量的“3GPP-QoE-Metrics”标头。如果PSS客户端102在下一请求中发送QoE度量信息(指示其支持QoE协议)，那么协商继续直到达成相互认同或提出RTSPPLAY请求和响应消息对。如果客户端102不在下一请求中向SETUP响应发送QoE度量信息，那么服务器100假定客户端102不支持QoE度量。

因为性能和复杂性的原因，流期间的QoE度量协商不需在一实施例中完成。然而有可能在流会话期间关闭所述度量。举例而言，所述度量可在会话阶层或媒体阶层被设定为“Off”。请求统一资源***(URL)指示使用哪个阶层。如果不使用URL，那么“Off”应用于会话阶层。服务器100可使用OPTIONS(具有会话ID)或SET_PARAMETER RTSP方法来关闭QoE反馈。

客户端102在RTSP准备状态期间不发送QoE反馈。在准备状态结束后(即，RTSP状态＝播放)，周期性反馈和正常操作会继续。此减少在上行链路和下行链路方向上的网络负载，和用于PSS客户端102的处理开支。当由PSS客户端102在一PAUSE后发送一RTSPPLAY请求时，重设用于(基于定义的“发送率”)测量报告周期的时钟。

如果存在多个非集中会话(即，由一不同的PLAY请求起始每个媒体传递)，那么对于每个会话而言，单独协商并报告QoE度量。

再者，应强调上述(且还大体上在下文部分I.A-I.F中接着描述)特定和主要实施的QoE协议的部分的实施例仅出于说明目的且不期望限制本发明。可如下总结协议的更一般描述：在服务器100与客户端102之间起始一会话；服务器100和客户端102中的一者或两者可或不可支持某些度量；同样，客户端102可选择包括其支持一特定会话的度量的一子组；客户端102和服务器100因此参与一协商过程，其可包含若干来回交换，以确定由客户端102支持和应发送的度量，应发送支持/接受的度量的频率，如何启用和/或停用度量，接受的度量要包含的内容或值，和其它与度量相关的因素；由客户端102进行的对度量值的测量和收集；将度量值从客户端102传输到服务器100；和会话的终止。可评估传输的度量值以确定在流会话期间和/或随后的会话是否能或应改进QoE。随后描述在所定义的标准的情况下的QoE协议的起始/终止、协商和传输(反馈)特点的实施例的更详细且非限制性描述。

A.起始/终止：RTSP

在一说明性且非限制性实施例中，定义一新的RTSP标头以使PSS客户端102和服务器100能够协商PSS客户端102应发送哪个质量体验(QoE)度量、应发送所述度量的频率和如何关闭度量传输。例如在一RTSP实施中，此标头可存在于RTSP方法SETUP、SET_PARAMETER、OPTIONS(具有会话ID)和PLAY的请求和响应中。在非RTSP实施中，可使用其它构件传输标头或标头中的数据。在ABNF[3]中定义实例标头如下：

QoE-Header＝″3GPP-QoE-Metrics″″：″(″Off″/Measure-Spec*(″，″Measure-Spec))CRLF

Measure-Spec＝Stream-URL″；″((Metrics″；″Sending-rate[″；″Measure-Range]*([″；″Parameter_Ext]))/ ″Off″)

Stream-URL＝″ur1″″＝″<″>Rtsp_URL<″>

Metrics＝″metrics″″＝″″{″Metrics-Name*(″，″Metrics-Name)″}″

Metrics-Name＝1*((0x21..0x2b)/(0x2d..0x3a)/(0x3c..0x7a)/0x7c/0x7e)；VCHARexcept″；″，″，″，″{″or″}″

Sending-Rate＝″rate″″＝″1*DIGIT/″End″

Measure-Range＝″range″″＝″Ranges-Specifier

Parameter_Ext＝″On″/″Off″/(1*DIGIT[″.″1*DIGIT])/(1*((0x21..0x2b)/(0x2d..0x3a)/(0x3c..0x7a)/0x7c/0x7e))

Ranges-Specifier＝如RFC 2326中所定义

Rtsp_URL＝如RFC 2326中所定义

有两种方式使用此标头用于此特定非限制性实施例——所述标头可以其它方式用于其它实施例：

-仅使用“Off”参数是服务器100或客户端102希望取消度量报告的指示。

-使用其它参数指示开始度量传输的请求。

如果“Stream-URL”是一RTSP会话控制URL，那么“Metrics”应用于RTSP会话。如果“Stream-URL”是一RTSP媒体控制URL，那么“Metrics”仅应用于会话的所指示的媒体组件。

具有相同“Stream-URL”、“Sending-rate”和“Measure-Range”的QoE度量集中在单个“Measure-Spec”声明中。另外，使用多个“Stream-URL”声明。

“Metrics”字段含有描述将在PSS会话中报告的度量/测量的名称清单。所述“Metrics”字段中未包括的名称不在所述会话期间报告。

“Sending-Rate”被设定，且以秒表示两个连续QoE报告之间的最大周期。如果所述“Sending-Rate”值为0，那么客户端102依据客户端102中出现的事件而决定报告的发送时间。值≥1指示精确的报告间隔。最小间隔为一秒且最长间隔未被定义。所述报告间隔对于不同媒体可不同，但可维持一同步程度以避免在上行链路方向上的额外流量。值“End”指示在会话结束时仅发送一个报告。

可选的“Measure-Range”字段(如果使用)定义流中的时间范围，其中向所述流报告QoE度量。在一实例实施例中，每个测量规格仅有一范围。范围格式可为媒体允许的任何格式。如果所述“Measure-Range”字段不存在，那么使用SDP中的对应的(媒体或会话阶层)范围属性。如果SDP信息不存在，那么度量范围为整个会话持续时间。在一实施例中，在RTSP请求或响应中仅有一个“3GPP-QoE-Metrics”标头。

B.传输/反馈：RTSP

在一实施例中，可由“3GPP-QoE-Feedback”标头使用SET_PARAMETER、PAUSE或TEARDOWN方法输送QoE度量反馈以响应PSS服务器100的请求。在ABNF[3]中定义标头的一可能实例如下：

Feedbackheader＝″3GPP-QoE-Feedback″″：″Feedback-Spec*(″，″Feedback-Spec)CRLF

Feedback-Spec＝Stream-URL 1*(″；″Parameters)[″；″Measure-Range]

Stream-URL＝如[1]中所指定

Parameters＝Metrics-Name″＝″″{″SP/(Measure*(″，″Measure))″)″

Metrics-Name＝如[1]中所指定

Measure＝值[SP Timestamp]

Measure-Range＝如[1]中所定义

Value＝(1*DIGIT[″.″*DIGIT])/1*((0x21..0x2b)/(0x2d..0x3a)/(0x3c..0x7a)/0x7c/0x7e)；VCHAR except″；″，″，″，″(″or″}″

Timestamp＝NPT-Time

NPT-Time＝如RFC 2326中所定义

“Stream-URL”为RTSP会话或识别应用反馈参数的媒体的媒体控制URL。

“Parameters”定义中的“Metrics-Name”字段含有度量/测量的名称，且将相同的标识符用作“3GPP-QoE-Metrics”标头。

“Value”字段指示结果。有可能在一监控周期期间相同事件出现了多次。在那种情况下，度量值可出现多次以向服务器100指示事件数。

可选的“Timestamp”(在NPT时间中定义)指示当事件出现或当计算度量时的时间。如果无事件出现，那么报告一空组(仅含有一空格)。

可选的“Measure-Range”指示此报告有效的实际的报告周期。

由PSS客户端102通过使用(例如)SET_PARAMETER方法而完成QoE度量报告。然而，为了更有效率，在特定情况下还可使用RTSP PAUSE和TEARDOWN方法，诸如：

情况1：当发送最后的QoE报告时，客户端102将QoE信息嵌入一TEARDOWN消息中。

情况2：当客户端102希望暂停流流动时，QoE信息应嵌入一PAUSE方法中。当***暂停时，由于没有媒体流，所以PSS客户端102不应向PSS服务器100发送任何QoE报告。

C.起始/终止：SDP

在一实施例中，SDP可用于起始QoE协商。使用SDP的原因是为了支持通过除RTSPDESCRIBE以外的其它方法(例如WAP、HTTP或email)分配SDP的使用情况。下文基于RFC 2327在ABNF中定义了可在会话或媒体阶层使用的新实例SDP属性：

QoE-Metrics-line＝″a″ ″＝″ ″3GPP-QoE-Metrics：″ att_measure_spec *(″，″att-measure-spec))CRLF

att-measure-spec＝Metrics ″；″ Sending-rate [″；″ Measure-Range] *([″；″Parameter_Ext])

Metrics＝如[1]中所定义

Sending-Rate＝如[1]中所定义

Measure-Range＝如[1]中所定义

Parameter_Ext＝如[1]中所定义

服务器100使用此属性以指示QoE度量被支持且如果还由客户端102支持就被使用。

当在会话阶层存在时，其仅含有应用到完整会话的度量。当在媒体阶层存在时，其仅含有可应用到个别媒体的度量。RTSP控制URI(a＝控制)暗含RTSP标头“3GPP-QoE-Metrics：”规格中使用的URI。

D.起始/终止：SDP(实例)

以下非限制性实例展示了QoE度量的SDP属性的语法。监控会话阶层QoE度量描述(起始缓冲持续时间和再缓冲)，且在会话结束时报告一次。而且，监控度量的视频特定描述(损坏和解码字节)，且从流开始直到(例如)40s的时间每15秒报告一次，但此定时在不同实施例中可适当变化。监控度量的音频特定描述(损坏)，且例如自开始直至流结束每20秒报告一次。

实例1：

Server->Client RTSP/1.0 200 OK

Cseq：1

Content-Type：application/sdp

Content-Base：rtsp://example.com/foo/bar/baz.3gp/

Content-Length：800

Server：PSSR6 Server

v＝0

o＝-3268077682 433392265 IN IP4 63.108.142.6

s＝QoE Enables Session Description Example

e＝[email protected]

c＝IN IP4 0.0.0.0

t＝0 0

a＝range：npt＝0-83.660000

a＝3GPP-QoE-Metrics：{Initial_Buffering_Duration，Rebuffering_Duration}；rate＝End

a＝control：^*

m＝video 0 RTP/AVP 96

b＝AS：28

a＝3GPP-QoE-Metrics：{Corruption_Duration，Decoded_Bytes}；rate＝15；range：npt＝0-40

a＝control：trackID＝3

a＝rtpmap：96 MP4V-ES/1000

a＝range：npt＝0-83.666000

a＝fmtp：96profile-level-id＝8；config＝000001b008000001b50900012000

m＝audio 0 RTP/AVP 98

b＝AS：13

a＝3GPP-QoE-Metrics：{Corruption_Duration}；rate＝20

a＝control：trackID＝5

a＝rtpmap：98 AMR/8000

a＝range：npt＝0-83.660000

a＝fmtp：98 octet-align＝1

a＝maxptime：200

E.起始/终止：RTSP(实例)

在图2的实例中，展示了如何在RTSP会话建立期间协商QoE度量。在协商后，客户端102可向服务器100提供测量/收集的接收的度量值作为反馈。

Client->Server SETUP rtsp://example.com/foo/bar/baz.3gp/trackID＝3RTSP/1.0

Cseq：2

3GPP-QoE-Metrics：url＝″rtsp://example.com/foo/bar/baz.3gp/trackID＝3″：

metrics＝{Corruption_Duration，Decoded_Bytes}；rate＝10；Range：npt＝0-40，

url＝″rtsp://example.com/foo/bar/baz.3gp″；

metrics＝{Initial_Buffering_Duration，Rebuffering_Duration}；rate＝End

在上文实例SETUP请求中，客户端102将控制URL″rtsp://example.com/foo/bar/baz.3gp/tracklD＝3″的QoE度量的发送率从15修改成10(与起始的SDP描述相比)。假定服务器100确认所述改变，服务器100将如下发送回一SETUP响应：

Server->Client RTSP/1.0 200 OK

Cseq：2

Session：17903320

Transport：RTP/AVP；unicast；client_port＝7000-7001；server_port＝6970-6971

3GPP-QoE-Metrics：url＝″rtsp://example.com/foo/bar/baz.3gp/trackID

＝3″：

url＝″rtsp://example.com/foo/bar/baz.3gp″；

metrics＝{Initial_Buffering_Duration，Rebuffering_Duration}；rate＝End

图3展示了当不存在DESCRIBE-200/OK时的实例QoE度量协商。

在下文实例中，(对于所有媒体)在会话阶层关闭度量：

Client->Server，Server->Client SET_PARAMETERrtsp://example.com/foo/

bar/baz.3gpRTSP/1.0

Cseq：302

Session：17903320

3GPP-QoE-Metrics：Off

Content-length：0

设定所述度量的实例响应为：

Server->Client.Client->Server RTSP/1.0 200 OK

Cseq：302

Session：17903320

3GPP-QoE-Metrics：Off

F.传输/反馈：RTSP(实例)

度量反馈(包含度量值/数据)可使用任何合适的通信技术从客户端102传输或另外输送到服务器100。一可能的且非限制性技术是使用SET_PARAMETER方法向服务器100输送反馈。以下实例展示了在监控时间期间出现两个(2)损坏周期。每个值指示每个损坏周期的持续时间(以毫秒计)。

实例5(反馈)：

Client->Server SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

Cseq：302

Session：17903320

3GPP-QoE-Feedback：

url＝″rtsp://example.com/foo/bar/baz.3gp/trackID＝3″；Corruption_Duration＝

{200 1300}

Content-length：0

以下实例展示了在监控时间期间出现两个(2)损坏周期。每个值对指示每个损坏周期的持续时间(以毫秒计)和损坏的时间标记(例如，第一损坏出现在12秒时且持续200毫秒)。

实例6(具有时间标记和范围的反馈)：

Client->Server SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

Cseq：302

Session：17903320

3GPP-QoE-Feedback：url＝″rtsp://example.com/foo/bar/baz.3gp/trackID＝3″；

Corruption_Duration＝{200 12，1300 16}；Range：npt＝10-20

Content-length：0

在以下实例中没有报告事件。

实例7(无事件的反馈)：

Client->Server SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

Cseq：302

Session：17903320

3GPP-QoE-Feedback：

url＝″rtsp://example.com/foo/bar/baz.3gp/trackID＝3″；Corruption_Duration＝{

}

Content-length：0

II.QoE度量

在一实施例中，PSS客户端102在传输层测量度量，但为了更好的精确度还可在应用程序层测量。度量的报告周期是计算一组度量的周期。报告周期的最大值经由QoE协议而协商。报告周期不包括影响实际播放的任何有意事件，诸如暂停或倒转，或由其引起的任何缓冲或停滞/间隙。在其它实施例中，可通过对于客户端102是替代或额外的组件测量一个或多个度量，且接着输送到服务器100和/或客户端102。

在一实施例中，至少某些度量指示影响通信环境质量的特征，或是通信信道的某些其它指示或结果。可在客户端102的协议堆栈、客户端102的应用程序、客户端102的缓冲器、客户端102的编码解码器或与QoE或任何上述组合相关的其它客户端特征中测量所述QoE度量。所述度量可用于调整服务器100和/或客户端102处的这些层中任何层的行为。

可通过PSS客户端102实施QoE而得到以下实例度量。应理解，这些度量不仅仅是可用于QoE目的的度量。可用其它度量补充这些度量，由其它度量替代、修改、组合等。本文描述以下度量以提供对本发明的实施例的操作和特点的更好的了解。

下文定义的所有度量可应用于音频、视频、语音和定时的文字媒体类型中的至少一者，且不需应用于其它媒体类型，诸如合成音频、静止影像、位图图形、向量图形和文字。然而应了解，对于这些其它媒体类型可提供其它度量。在一实施例中，客户端102可忽略任何未知的度量且其不包括在任何QoE报告中。

A.损坏持续时间度量

损坏持续时间M是从损坏前最后良好帧的NPT时间到第一个后续的良好帧的NPT时间或报告周期结束(无论哪个在前)之间的周期。一损坏的帧可为一完全丢失的帧或一质量降级的媒体帧，且解码的帧和无错误的解码不同。一良好的帧为一“完全接收的”帧X：

-其是一更新的帧(不参考任何先前解码的帧且随后接收的帧不参考先于X解码的任何帧)；

-或不参考任何先前解码的帧；

-或参考先前解码的“良好帧”。

“完全接收”指接收所有位且未出现位错误。

在一实施例中，可如下计算以毫秒计的损坏持续时间M：

a)可由客户端102使用编码解码层获得M，在这种情况下编码解码层向客户端102发送一良好帧的解码。还可通过错误跟踪方法获得一良好帧，但解码质量评估方法不用于一个实施例中而可用于另一实施例中。

b)在不存在来自编码解码层的信息的情况下，从损坏前的最后的帧的NPT时间和N获得M，其中N视情况从服务器100向客户端102发送信号，且以毫秒计表示两个后续更新帧之间的最大持续时间。

c)当不存在来自编码解码层的信息且如果未发送N的情况下，那么M默认为∞(对于视频)或为一帧持续时间(对于音频)，或报告周期的结束(无论哪个在前)。

如在点b中定义的可选参数N与“Corruption_Duration”参数一起用于“3GPP-QoE-Metrics”标头中。定义另一可选参数T以指示客户端102是否使用错误跟踪。T的值是由客户端设定的。用于N和T的可包括于“Measure-Spec”([1]的子句5.3.2.3.1)的实例和非限制性语法如下：

N＝″N″″＝″1*DIGIT

T＝″T″″＝″″On″/″Off″

用于QoE反馈标头的“Metrics-Name Corruption_Duration”的一实例和非限制性语法如[1]的子句5.3.2.3.2中所定义。

可使用空格(SP)报告一事件不存在。

对于“Metrics-Name Corruption_Duration”，子句5.3.2.3.2中的“Value”字段指示损坏持续时间。此度量的单位以毫秒表达。有可能损坏在一报告周期期间出现多次。在那种情况下，值可出现多次以指示损坏事件数。

相对于报告周期的开始时间，在报告周期内，以回放次序，在损坏出现前，″Timestamp″值等于最后良好帧的NPT时间。如果在报告周期内且在损坏前没有良好帧，那么所述时间标记被设定成报告周期的开始时间。

B.再缓冲持续时间度量

再缓冲被定义为归因于客户端一侧的任何无意事件的回放时间中的任何停止。

用于QoE反馈标头的“Metrics-Name Rebuffering_Duration”的一实例和非限制性语法如[1]的子句5.3.2.3.2中所定义。

可使用空格(SP)报告一事件不存在。

对于“Metrics-Name Rebuffering_Duration“，子句5.3.2.3.2中的“Value”字段指示再缓冲持续时间。此度量的单位以秒表达，且可为一分数值。有可能再缓冲在一监控周期期间出现多次。在那种情况下，度量值可出现多次以指示再缓冲事件的数目。

可选的“Timestamp”指示当再缓冲从报告周期开始出现时的时间。相对于报告周期的开始时间，在报告周期内且在再缓冲出现前，“Timestamp”值等于最后播放的帧的NPT时间。如果在报告周期内没有播放的帧，那么所述时间标记设定成报告周期的开始时间。

C.起始的缓冲持续时间度量

起始的缓冲持续时间是从接收第一RTP数据包直到播放开始的时间。

除用于此度量“Measure”中的“Timestamp”未定义外，用于QoE反馈标头的“Metrics-Name lnitial_Buffering_Duration”的一实例和非限制性语法如子句5.3.2.3.2中所定义。如果报告周期比“lnitial_Buffering_Duration”短，那么客户端只要观察到，应在每个报告周期发送此参数。“Value”字段指示起始的缓冲持续时间，其中此度量的单位以秒表达，且可为一分数值。仅可有一个“Measure”且其仅可具有一个“Value”。可使用空格(SP)报告一事件不存在。“lnitial_Buffering_Duration”是一个会话阶层参数。

D.RTP数据包的连续丢失

此参数指示每个媒体信道的RTP数据包连续丢失的数目。

用于QoE反馈标头的“Metrics-Name Successive_Loss″”的一实例和非限制性语法如子句5.3.2.3.2中所定义。

可使用空格(SP)报告一事件不存在。

对于“Metrics-Name Successive_Loss”，“Value”字段指示RTP数据包连续丢失的数目。此度量的单位表达为一等于或大于1的整数。有可能在一报告周期期间出现连续丢失多次。在那种情况下，度量值可出现多次以指示连续丢失的数目。

可选的“Timestamp”指示当连续丢失数据包出现时的时间。相对于报告周期的开始时间，在报告周期内，以回放次序，在连续丢失数据包出现前，“Timestamp”值等于最后接收的RTP数据包的NPT时间。如果在报告周期内且在连续丢失前没有接收的RTP数据包，那么时间标记被设定成报告周期的开始时间。

如果需要一具有序列数目信息的RTP丢失的全程程度编码，那么应使用RTCP XR[5]丢失RLE报告区块以替代连续丢失的度量。

E.帧速率偏差

帧速率偏差指示回放帧速率信息。当在一报告周期期间实际的回放帧速率偏离一预定值时发生帧速率偏差。

实际的回放帧速率等于在报告周期期间所播放的帧的数目除以以秒计的报告周期的持续时间。

表示预定帧速率值的参数FR与“Framerate_Deviation”参数一起用在“3GPP-QoE-Metrics”标头中。可由服务器100设定FR的值。用于FR的可包括于“Measure-Spec”([1]的子句5.3.2.3.1)中的一实例和非限制性语法如下：

FR＝″FR″″＝ ″1*DIGIT″.″1*DIGIT

除用于此度量“Measure”中的“Timestamp”未定义外，用于QoE反馈标头的Metrics-Name“Framerate_Deviation”的一实例和非限制性语法如子句5.3.2.3.2中所定义。可使用空格(SP)报告一事件不存在。

对于Metrics-Name“Framerate_Deviation”，“Value”字段指示帧速率偏差值，其等于预定的帧速率减去实际的回放帧速率。此度量可以每秒多少帧表达，且可为一分数值，且可为负值。在一实例和非限制性实施例中，对于此度量，度量值仅可出现一次。

F.抖动持续时间

当实际的回放时间与期望的回放时间之间的绝对差大于100毫秒的预定值时，发生抖动。在一个实例实施例中，一帧的期望时间等于最后播放的帧的实际的回放时间加上所述帧的NPT时间与最后播放的帧的NPT时间之间的差。

用于QoE反馈标头的Metrics-Name“Jitter_Duration”的一实例和非限制性语法如[1]的子句5.3.2.3.2中所定义。

可使用空格(SP)报告一事件不存在。

对于Metrics-Name“Jitter_Duration”，5.3.2.3.2中“Value”字段指示回放抖动的持续时间。此度量的单位以秒表示，且可为一分数值。有可能抖动在一监控周期期间出现多次。在那种情况下，度量值可出现多次以指示抖动事件的数目。

可选的“Timestamp”字段指示从报告周期开始抖动出现时的时间。相对于报告周期的开始时间，“Timestamp”值等于回放抖动中的第一个播放的帧的NPT时间。

III.QoE服务器模块

图4展示了根据一实施例的服务器100中的QoE服务器模块108。所述QoE服务器模块108负责在媒体通信时量化若干因素的影响，包括网络条件、客户端特征等。QoE服务器模块108通过从客户端102收集反馈而实现。

所述QoE服务器模块108的各种实施例的特征和特点可描述如下：

1.所述QoE服务器模块108可驻存于一流服务器中(例如服务器100)。

2.所述QoE服务器模块108可驻存于一rtsp代理或任何其它合适的网络设备中。

3.所述QoE服务器模块108可接受来自各种协议412的输入，所述协议412诸如：

○ 通过QoE协议的QoE度量(如上文和[1]中所解释)

○ RTCP度量[4]

○ 3GPP链路特征[1]

○ RTCP XR[5]

4.所述QoE服务器模块108的配置可存储于一SDP文件或由服务器/代理产生。图4中的410展示了实例配置参数。

5.所述QoE服务器模块108与DBA模块104交互：

○ 影响决定以基于统计的QoE结果而增加位率

○ 影响决定以基于主观的QoE结果而增加位率

○ 影响决定以基于统计的QoE结果而减少位率

○ 影响决定以基于主观的QoE结果而减少位率

○ 以下特征还可基于主观和/或统计的QoE结果而增加/减少或另外影响/改变：帧速率、更新间隔和行为、错误弹性、缓冲行为、最大帧大小、峰值位率、片断、重传输和/或其它特征。

○ 如果开启DBA模块104：

■ QoE可影响速率调节(可配置).

■ 在一实施例中，通过DBA模块104控制报告。

○ 如果关闭DBA模块104：

■ 在一实施例中，QoE服务器108不影响速率调节，但可在另一实施例中影响速率调节。

■ 在一实施例中，由QoE服务器108控制报告，而在另一实施例中由其它模块或组件控制。

○ 在一实施例中，如果关闭DBA和QoE模块104和108，那么由QoS模块106控制报告。

6.所述QoE服务器模块108可以下列模式中的一者或两者而操作：

○ 统计模式

○ 主观模式

○ 详细内容：可以许多方式在所述QoE服务器模块108中组织使用从客户端102传回到服务器100的度量。一种方式是“统计模式”。此处，所述QoE服务器模块108以最小值、最大值等的形式组织度量的统计。第二方式是“主观模式”。此处，QoE服务器模块108通过将度量映射到一质量服务类别以组织其接收的度量。因此，(例如)，在观察度量后，QoE服务器模块108可确定一特定度量属于MEDIUM质量类别。同样，此信息可用于确认的目的。举例而言，如果客户端102属于一HIGH质量类别，但对于基于服务器100接收的度量的此特定会话，其确定此会话仅属于MEDIUM质量类别，那么所述信息可用于许多目的。可能潜在存在许多对QoE服务器模块108接收的度量的其它分析。

7.QoE统计模式：

○ 在媒体或会话阶层计算

○ 在单个周期或整个会话测量

○ 计算最小值、最大值、平均值和至少以下标准偏差：：

■ 损坏持续时间(如上文和[1]中所解释)

■ 再缓冲持续时间(如上文和[1]中所解释)

■ 起始缓冲持续时间(如上文和[1]中所解释)

■ 连续丢失(如上文和[1]中所解释)

8.QoE主观模式：

○ 在媒体或会话阶层计算

○ 在整个会话测量(无单个周期的报告)

○ 提供对预定的QoS类别的映射

■ 尽力服务(Best-effort)或流类别，

■ 低、中或高QoE类别。

○ 提供对可能的问题位置的隔离：

■ 链路层

■ 网络协议堆栈

■ 编码解码器堆栈问题

■ 客户端应用程序问题

■ 夹片问题

■ 其它

9.QoE报告可整合到

○ 监控***

○ 帐务***(如果手持机已被验证)

在一实施例中，DBA模块104、QoS模块106和QoE服务器模块108可共同包含报告模块400的部分。可有额外的模块位于服务器100中，诸如一速率交换模块402。为了简洁目的，本文将不提供所述额外模块的详细描述。

至少某些与QoE相关和上述其它操作可包含在软件或存储于一个或多个机器可读媒体406上的其它机器可读指令404。所述机器可读机器媒体406可位于服务器100中、位于客户端102中和/或位于其它合适的网络位置中。一个或多个处理器408耦接到存储媒体406，以允许处理器408执行存储于其上的软件404。

IV.QoE客户端模块

一个实施例的QoE客户端模块118是基于客户端102的。

所述QoE客户端模块118可基于许多考虑而决定在一会话期间开启/关闭QoE度量。一个所述考虑为(例如)可阻碍其正常操作的低电池功率。

所述QoE客户端模块118在其决定在会话开始时开启度量后，可在会话中间关闭度量。此决定可受许多原因影响，包括其收集的度量无效性或其它原因。

所述QoE客户端模块118可从其支持的度量组中仔细挑选，对于一特定会话支持何种度量。此决定可受计算度量的复杂性、过去的体验或其它考虑影响。所述度量选择可用于与服务器100协商。

所述QoE客户端模块118在其同意在会话开始时测量度量后，可在会话中间选择选择性关闭某度量。QoE客户端模块118还可选择报告所述度量的频率。频率选择可用于与服务器100协商。所述QoE客户端模块118可选择应测量度量的会话范围。范围选择可用于与服务器100协商。一实施例的QoE服务器模块108和/或QoE客户端模块118可在会话期间改变度量清单、度量阶层(媒体/会话)、度量频率和度量范围。

QoE客户端模块118可动态测量或当解码或处理从服务器100接收的媒体时另外获得度量值“on-the-fly”。来自解码和/或处理循环的结果可用在度量收集期间。

所述QoE客户端模块118可在各阶层(例如应用程序、网络、编码解码器或其它)收集数据。所述QoE客户端模块118可接着共同使用所述数据以确定某些度量。

所述QoE客户端模块118可区分与质量体验有关的客户端102的有意和无意动作。所述QoE客户端模块118可维持其测量的度量的完整性。如果所述选择有效，那么所述QoE客户端模块118可选择传输这些度量的方法。

在一实施例中，所述QoE客户端模块118可在仍收集度量的同时改变度量的配置(例如度量的频率和范围)。度量还可应用于会话阶层、流阶层媒体(例如音频、视频，独立地或共同地)。

至少某些与QoE相关和上述其它操作可包含在软件或其它存储于一个或多个机器可读媒体406上的机器可读指令404中。所述机器可读媒体406可位于服务器100、位于客户端102和/或位于其它合适的网络位置处。一个或多个处理器408耦接到存储媒体406，以允许处理器408执行存储于其上的软件404。各种组件，诸如位于服务器100和/或客户端102处的模块，可包含在软件(或其它机器可读指令)、硬件和/或两者的组合中。

本说明书和/或申请数据表中涉及的所有上述美国专利、美国专利申请公告案、美国专利申请案、外国专利、外国专利申请案和非专利申请案，其全文以引用的方式并入本文。

所说明的实施例的以上描述，包括摘要中所述，并非希望详尽化或将本发明限于所揭示的精确形式。当本文出于说明目的而描述特定实施例和实例时，在本发明的范畴内可具有各种等同的修改，且可在不偏离本发明的精神和范畴的情况下而制作。

举例而言，当本文在某些特定通信协议、标准、格式、语法等的情况下描述各种实施例时，对于其它类型的通信协议、标准、格式、语法等可提供其它实施例。本发明不限制于本文描述的特定通信协议、标准、格式、语法等。实施例不仅应用于音频和视频媒体流，且可应用于其它形式的媒体的传递和消费。

根据上述详细描述可对本发明作这些和其它修改。以上申请专利范围中使用的术语不应理解为将本发明限制于说明书和申请专利范围中所揭示的特定实施例。相反，本发明的范畴完全由以下申请专利范围确定，其将根据申请专利范围解释的制定原则而理解。

Claims

1.一种可用于一通信环境中的方法，所述方法包含：

定义复数个质量体验QoE度量，其指示一影响所述通信环境中的质量的特征；

在一客户端与一服务器之间执行一协商以确定在所述客户端与所述服务器之间的一会话期间将被使用的所述QoE度量中的至少一个，其中所述协商在开始所述会话的媒体播放前被执行；

将所述经确定的至少一个QoE度量指定为一接受的QoE度量，所述执行在开始所述会话的媒体播放前的所述协商包括：

确定所述复数个QoE度量中的哪个是由服务器支持，还是由客户端支持，或者同时由两者支持；

确定在所述会话期间停用所述至少一个QoE度量的一方式；

修改一特定的QoE度量，并重新协商所述修改的QoE度量，以确定这一修改的QoE度量能否为所述会话而被支持；和

拒绝一建议的QoE度量，如果所述建议的QoE度量不被所述客户端和服务器中的一者或两者支持，也拒绝所述修改的QoE度量；

在所述会话期间收集一个或多个QoE接受的度量的数据；和

在所述客户端与所述服务器之间传送所述度量数据。

2.根据权利要求1所述的方法，其中所述通信环境包括一无线通信环境。

3.根据权利要求1所述的方法，其中定义所述复数个QoE度量包括定义一影响一固线通信环境中的质量的QoE度量。

4.根据权利要求1所述的方法，其中在所述会话期间收集一个或多个接受的QoE度量的数据包括当所述客户端设备解码或处理从所述服务器接收的所述媒体时，在所述会话期间在所述客户端设备处动态地收集所述数据。

5.根据权利要求1所述的方法，其中定义复数个QoE度量包括定义如下QoE度量：损坏持续时间、再缓冲持续时间、起始缓冲持续时间、连续数据包丢失、帧速率偏差和抖动持续时间。

6.根据权利要求1所述的方法，其中在所述客户端与所述服务器之间传送所述度量数据包括接收在一个或多个数据包中由所述客户端传输到所述服务器的所述度量数据。

7.根据权利要求1所述的方法，其中在开始所述会话的媒体播放前在所述客户端与所述服务器之间执行所述协商且进一步包括：

在所述协商期间确认所述建议的QoE度量的接收；

确定在所述会话期间传送所述至少一个QoE度量的方式；

确定在所述会话期间传送所述至少一个QoE度量的频率；

确定所述至少一个QoE度量的一配置；和

确定度量值的参数。

8.根据权利要求1所述的方法，其进一步包含评估所述度量数据并应用所述度量数据。

9.根据权利要求8所述的方法，其中评估所述度量数据包括根据统计和主观模式而组织所述度量数据。

10.根据权利要求1所述的方法，其中定义复数个QoE度量包括定义与所述客户端的一特征相关联的一QoE度量。

11.一种可用于一通信环境中的***，所述***包含：

用于定义复数个质量体验QoE度量的构件，所述复数个质量体验度量指示一影响所述通信环境中的质量的特征，所述特征包括一客户端特征；

用于在一客户端与一网络设备之间执行一协商，以确定在所述客户端与所述网络设备之间的一会话期间将被使用的所述QoE度量中的至少一个的构件，且将所述经确定的至少一个QoE度量指定为一接受的QoE度量，其中在开始所述会话的媒体播放前执行的所述协商包括；

确定所述复数个QoE度量中的哪个是由所述网络设备支持，还是由客户端支持，或者同时由两者支持；

确定在所述会话期间停用所述至少一个QoE度量的一方式；

修改一特定的QoE度量，并重新协商所述修改的QoE度量，以确定这一修改的QoE度量能否为所述会话所支持；

拒绝一建议的QoE度量，如果所述建议的QoE度量不被所述客户端和网络设备中的一者或两者支持，也拒绝所述修改的QoE度量；和

用于在所述客户端与所述网络设备之间传送所述接受的QoE度量数据的构件。

12.根据权利要求11所述的***，其中所述通信环境包括一无线通信环境。

13.根据权利要求11所述的***，其中所述网络设备包括一服务器。

14.根据权利要求11所述的***，其中用于定义复数个QoE度量的所述构件定义如下QoE度量：损坏持续时间、再缓冲持续时间、起始缓冲持续时间、连续数据包丢失、帧速率偏差和抖动持续时间。

15.根据权利要求11所述的***，其中用于执行所述协商的所述构件包括一用于分析所述度量数据的QoE模块构件，其形成一报告模块构件的部分，所述***进一步包含：

一动态带宽调节(DBA)模块构件，其形成所述报告模块构件的部分以用于与所述QoE模块构件交互，以基于所述度量数据而作出与质量相关的决定；

一质量服务(QoS)模块构件，其形成所述报告模块构件的部分，其用于执行对所述QoE模块构件的报告；和

监控和帐务模块构件，其用于与所述报告模块构件交互以评估所述度量数据。

16.根据权利要求11所述的***，且进一步包含客户端侧QoE模块构件以用于：

基于至少一个考虑而确定在所述会话期间是否开启/关闭所述接受的QoE度量；

在所述会话的一开始时已打开一QoE之后，在所述会话期间关闭所述接受的QoE度量；

选择报告度量数据的一频率；

选择待测量所述QoE度量的所述会话的一范围；

选择所述接受的QoE度量的一阶层，包括媒体和会话阶层；

当解码或处理从所述网络设备接收的所述媒体时，动态获得度量数据；

获得处于各阶层的所述度量数据，包括应用、网络和编码解码阶层；

区分对QoE有一影响的所述客户端的有意和无意的动作；

维持已获得的所述QoE度量的一完整性；

选择一用于传输度量数据的构件；和

改变所述QoE度量的一配置，同时仍收集其数据。

17.一种可用于一通信环境中的装置，所述装置包含：

一质量体验QoE模块，其用于在一客户端与一服务器之间执行一协商，以确定在所述客户端与所述服务器之间的一会话期间将使用的复数个QoE度量中的至少一个QoE度量，其中所述协商是在开始所述会话的媒体播放前开始执行的，指定经确定的所述至少一个QoE度量为一接受的QoE度量，所述QoE模块适于进一步在所述会话期间在所述客户端与所述服务器之间传送对应于所述接受的QoE度量的经收集的度量数据，其中在开始所述会话的媒体播放之前由所述质量体验QoE模块执行的所述协商包括：

确定所述复数个QoE度量中的哪个是由所述服务器支持，还是由客户端支持，或者同时由两者支持；

确定在所述会话期间停用所述至少一个QoE度量的一方式；

修改一特定的QoE度量，并重新协商所述修改的QoE度量，以确定这经修改的QoE度量能为所述会话而被支持；和

拒绝一建议的QoE度量，如果所述建议的QoE度量不被所述客户端和服务器中的一者或两者支持，也拒绝所述修改的QoE度量。

18.根据权利要求17所述的装置，其中所述QoE模块位于所述客户端处，且能进一步在解码或处理从所述服务器接收的媒体时收集所述度量数据。

19.根据权利要求17所述的装置，其中所述QoE模块位于所述服务器处，所述装置进一步包含至少另一模块以与所述QoE模块合作，以出于至少一个目的而应用所述度量数据。

20.根据权利要求17所述的装置，其中在开始所述会话的媒体播放之前由所述QoE模块执行的协商包括：

在所述协商期间确认接收所述建议的QoE度量；

确定在所述会话期间传送所述至少一个QoE度量的一方式；

确定在所述会话期间传送所述至少一个QoE度量的频率；

确定所述至少一个QoE度量的一配置；和

确定度量值的参数。