专利名称：用于传输会话的增强的质量报告的制作方法
技术领域：
本发明涉及在根据 一 个或多个度量来报告传输会话的质量的环 境中的方法、计算机程序产品、客户端、服务器、系统和协议。
背景技术：
第三代合作伙伴计划(3GPP)分组交换流传输服务(PSS)在 3G网络中为基于因特网协议(IP)的流应用提供框架。通过参考引 入在此的文档3GPP TS 26.234 V.6,a.0 "Transparent end-to-end Packet-Switch Streaming Service (PSS) Protocols and codes (Release 6)"规定了用于3GPPPSS的协议和编解码器。规定了用于控制信 令、能力交换、媒体传输、速率适配和流保护的协议。
此外，PSS定义了可选的体验质量(QoE)度量框架。QoE度量 框架是一种用于评价媒体流应用的端用户体验的技术。其支持在提 取结果(QoE度量)的过程中组合跨层测量。提取的结果可以用于 监视和改进基于可变网络条件上的端用户体验。
支持QoE度量特征的3GPP PSS客户端应该根据测量定义来执 行质量测量，并且当被请求如此时，使用QoE传输协议将它们汇聚 到客户端QoE度量并且将度量报告给PSS服务器。
QoE度量框架其中涉及
QoE度量定义定义了一组QoE度量以用于评价会话层和媒体 层体验质量。3GPP TS 26.234 V.6.a.0提供了关于如何计算这些度量 和传输它们的频度的定义和建议。
QoE度量协商定义了实时流传输协议(RTSP )报头"3GPP-QoE-度量"以支持PSS客户端和服务器来协商PSS客户端应该发送哪些 QoE度量，发送它们的频度以及如何关闭度量传输。该报头可以在
8RTSP方法SETUP 、 SET—PARAMETER、 OPTIONS (具有会话ID ) 和PLAY的请求和响应中发送。根据3GPPTS 26.234 V.6.a.0,该协 商以由PSS服务器提供的会话描述协议(SDP )文件或来自PSS客 户端的RTSP SETUP请求开始，并且最晚当由PSS月良务器发布RTSP PLAY响应消息时结束。客户端可以简单地通过发布RTSP PLAY请 求来终结该协商过程。 一旦媒体传输开始，将不再允许有QoE度量 协商，除非关闭QoE度量反馈。
QoE度量传输为了将协商的QoE度量从PSS客户端传输到PSS 服务器，定义了 RTSP报头 "3GPP-QoE-feedback"并且该报头与某 些RTSP方法有关(SET—PARAMETER、 PAUSE或TEARDOWN )。
3GPPPSS版本7规范(也称为PSSe)当前正在3GPP SA4中发 展。该工作项目的目标是以媒体编解码配置的新功能性和现有技术 配置来改进现有分组交换流传输(PSS)规范。该工作的主要目标之 一是改进PSS信道/内容-交换时间并且也支持PSS会话的更快启动。
如在涉及3GPP版本7规范的改变请求S4-070151 "快速内容交 换和启动"中，对于快速内容启动，引入RTSP消息的管道传输。 特别地，已经同意对针对各种i某体流的RTSP SETUP请求以及会聚 控制PLAY请求进行管道传输以加速PSS会话启动。这在附图1的 图100中示出，其中示出了服务器和客户端之间的RTSP请求和响 应的交换，并且其中RTSP SETUP请求视频101和音频102,并且 对RTSP PLAY请求103进行管道传输。
类似地，为了加速PSS信道/内容交换，定义新的RTSP报头， 其支持新的PSS会话的建立而不需要拆除旧的RTSP会话和建立新 的RTSP会话。特别地，对于快速内容交换，具有"切换-流"报头 的过载PLAY请求用于指示将被流传输到接收机的新内容。这在附 图2的图200中示出，其中示出服务器和客户端之间的RTSP请求/ 响应的交换。客户端使用具有"切换-流"报头的RTSP PLAY请求 来向服务器指示应该执行从两个先前的流到两个新流的切换，并且 服务器以RTSP "200 OK"响应对该切换做出确认。标准化组织同意的当前解决方案(用于快速信道/内容交换和快 速会话启动)涉及对于RTSP会话建立前的协商协议的主要改变。 这些解决方案背后的主导原理是通过对两个内容之间就它们的媒体 层以及会话层传输参数方面之间的相似性做出合理的假设来尽可能 地减小更多的往返延迟。
在PSS规范的版本6中，QoE协商可能不增加总体会话建立延 迟。由于对于每个媒体具有分开的SETUP请求/响应对，也就存在多 个往返。在该情况下，QoE度量协商可能不会对总体会话建立延迟 做出显著贡献，因为QoE度量协商报头被搭载(piggy-backed)到 RTSP SETUP请求/响应对。
相比较而言，在PSS的版本7 (PSSe)中，会话建立(仅)请 求一或两个往返。在该情况下，QoE度量协商可能对总体会话建立 延迟做出显著贡献，因为在单个往返时间内完成协商可能是不太可 行的。
在PSSe中使用现有的QoE协商因此导致增加的会话建立时间和 内容切换时间。因此需要修改QoE度量协商过程以反映新的会话启 动和切一炎优4匕。
进一步，尽管版本7PSS (PSSe)对解决方案进行标准化以显著 地改进启动和切换时间，但是由于变化的信道条件和内容组成(例 如，内容供应中的媒体流的数目和它们的比特速率)，服务的实际 部署期间的端用户体验可能不同。然而，用于评价PSSe增强的有效 性的QoE度量，特别是信道/内容切换期间的用户体验的QoE度量， 到目前为止还不存在。
发明内容
第一方面
才艮据本发明的第一方面，公开一种客户端侧方法，所述方法包 括根据将要报告给服务器的 一 个或多个度量来测量传输会话的质
量，其中一个或多个度量包括内容切换时间度量，该内容切换时间
10度量涉及在传输会话中内容间切换所占用的时间。
根据本发明的第 一 方面，进一 步公开了其中存储有计算机程序 的计算机可读介质，计算机程序包括可操作以使得处理器来执行客 户端侧方法的指令。将理解到计算机程序本身也被公开，即在没有 存储在计算机可读介质上的情况下。
根据本发明的第一方面，还公开一种客户端侧设备，所述设备 包括处理单元，其配置成根据将要报告给服务器的一个或多个度量 来测量传输会话的质量，其中一个或多个度量包括内容切换时间度 量，该内容切换时间度量涉及在传输会话中内容间切换所占用的时 间。该设备例如可以是客户端或其一部分。
根据本发明的第一方面，还公开一种客户端侧设备，所述设备 包括用于根据将要报告给服务器的一个或多个度量来测量传输会话 的质量的装置，其中一个或多个度量包括内容切换时间度量，该内 容切换时间度量涉及在传输会话中内容间切换所占用的时间。该设 备例如可以是客户端或其一部分。
根据本发明的第一方面，还公开了一种服务器侧方法，所述方 法包括处理一个或多个度量，将根据该一个或多个度量来报告传输 会话的质量，其中一个或多个度量包括内容切换时间度量，该内容 切换时间度量涉及在传输会话中内容间切换所占用的时间。
根据本发明的第 一方面，进一步公开了其中存储有计算机程序 的计算机可读介质，计算机程序包括可操作以使得处理器来执行服 务器侧方法的指令。将理解到计算机程序本身也被公开。即在没有 存储在计算机可读介质上的情况下。
根据本发明的第一方面，还公开了一种服务器侧设备，所述设 备包括处理单元，其配置成处理一个或多个度量，将根据该一个或 多个度量来报告传输会话的质量，其中一个或多个度量包括内容切 换时间度量，该内容切换时间度量涉及在传输会话中内容间切换所 占用的时间。该设备例如可以是服务器或其 一部分。
根据本发明的第一方面，还公开了一种服务器侧设备，所述设
11备包括用于处理一个或多个度量的装置，将根据该一个或多个度量 来报告传输会话的质量，其中 一个或多个度量包括内容切换时间度 量，该内容切换时间度量涉及在传输会话中内容间切换所占用的时 间。该设备例如可以是服务器或其一部分。
根据本发明的第一方面，还公开了一种系统，包括根据本发明 第一方面的客户端侧设备和服务器侧设备。
根据本发明的第一方面，在传输会话中，内容被传送到客户端。 所述传输会话例如可以是流传输会话，其中例如在线路绑定或无线 网络或其组合的网络中，内容经由 一 个或多个媒体流流传输到客户
端。所述媒体流例如可以是实时传输协议(RTP)媒体流。所述内容 源自于内容源。传输会话可以通过协议来建立和控制，例如在流传 输会话的情况下通过实时流传输协议(RTSP)来建立和控制。
在传l命会话中，例如响应于用户请求，可以在内容之间进行切 换。在流传输会话的情形下，媒体传输例如可以是媒体流。例如， 通过替换媒体流(相同或不同媒体类型)的内容(例如同时维持媒 体流的相同传输和/或编解码器参数)，和/或通过替换媒体流和/或 通过增加和/或移除媒体流，内容可以被切换。在会话通过RTSP来 控制的情形下，切换例如可以通过在RTSP PLAY请求中使用 "Switch-Stream"("切换-流")报头来完成。
在客户端处，根据一个或多个度量来测量传输会话的质量并且 报告给服务器以便处理，例如用于传输会话质量的评估。其中，向 其报告度量的服务器可以不必是内容源。
一个或多个度量包括内容切换时间度量，该内容切换时间度量 涉及在传输会话中内容间切换所占用的时间，并且因此可以允许运 营商或服务提供商在内容的切换期间来评价用户体验。
根据本发明的第 一方面的示例性实施方式，内容切换时间度量 被定义为这样的时间之一，从在客户端上新内容被选择的时刻到新 内容的第 一媒体帧被回放的时刻的时间，以及从切换请求从客户端 发送到服务器的时刻到在客户端处接收新内容的第 一媒体分组的时刻的时间。同样地，可以基于这两个定义或其元素的组合来定义内 容切换时间度量。
根据本发明的第 一 方面的另外示例性实施方式，可以协商内容 切换时间度量以便立即进行报告。为此，可以针对内容切换时间度
量来定义新的报告速率值"Start"("开始，，)。
根据本发明的第 一方面的另外示例性实施方式，根据第三代合 作伙伴计划分组交换流传输服务，内容切换时间度量是体验质量度量。
第二方面
根据本发明的第二方面，公开了一种方法，该方法包括如果在 传输会话中发生从先前内容到具有先前内容和新内容之间共同媒体 类型的新内容的切换时，为了报告新内容的传输质量，在客户端处 接受所有已经在客户端和服务器之间协商的、用于报告先前内容的 共同媒体类型的传输质量的一个或多个度量。
根据本发明的第二方面，进一步公开了其中存储有计算机程序 的计算机可读介质，计算机程序包括可操作以使得处理器来执行根 据本发明的第二方面的方法的指令。将理解到计算机程序本身也被 公开，即在没有存储在计算机可读介质上的情况下。
根据本发明的第二方面，还公开了一种设备，该设备包括处理 单元，其配置成如果在传输会话中发生从先前内容到具有先前内容 和新内容之间共同媒体类型的新内容的切换时，为了报告新内容的 传输质量，接受所有已经在客户端和服务器之间协商的、用于报告 先前内容的共同媒体类型的传输质量的一个或多个度量。所述设备 例如可以是客户端或其一部分。
根据本发明的第二方面，还公开了一种设备，该设备包括用于 如果在传输会话中发生从先前内容到具有先前内容和新内容之间共 同媒体类型的新内容的切换时，为了报告新内容的传输质量，接受 所有已经在客户端和服务器之间协商的、用于报告先前内容的共同 媒体类型的传输质量的 一 个或多个度量的装置。所述设备例如可以是客户端或其一部分。
根据本发明的第二方面，还公开了一种系统，所述系统包括服 务器和客户端，其中所述客户端包括根据本发明第二方面的设备。
根据本发明的第二方面，还公开了一种协议，所述协议包括一 种规则，该规则允许或规定如果在传输会话中发生从先前内容到具
接受所有已经在客户端和服务器之间协商的、用于报告先前内容的 传输质量的 一 个或多个度量，以便报告新内容的共同媒体类型的传
输质量。协议例如可以是才艮据3GPP PSS的QoE协商协议。
根据本发明的第二方面，在传输会话中，内容被发送到客户端。 所述传输会话例如可以是流传输会话，其中例如在线路绑定或无线 网络或其组合的网络中，内容经由一个或多个々某体流从内容源流传 输到客户端。所述媒体流例如可以是实时传输协议(RTP)媒体流。 传输会话可以通过协议来建立和控制，例如在流传输会话情况下通 过实时流传输协议(RTSP)来建立和控制。
在传输会话中，例如响应于用户请求，可以在内容之间切换。 在流传输会话的情况下，所述媒体传输例如可以是媒体流。例如， 通过替换媒体流(相同或不同媒体类型)的内容(例如同时维持媒 体流的相同传输和/或编解码器参数)，和/或通过替换媒体流和/或 通过增加和/或移除媒体流，内容可以被切换。在会话通过RTSP来 控制的情形下，切换例如可以通过在RTSP PLAY请求中使用 "Switch-Stream"("切换-流")报头来完成。
在客户端处，根据一个或多个度量来测量传输会话的质量并且 报告给服务器以便处理，例如用于传输会话质量的评估。其中，向 其报告度量的服务器可以不必是内容源。
用于报告先前内容的传输质量的度量已经在服务器和客户端之 间进行了协商。其中，所述度量的协商可以理解为包括找到关于度 量本身和/或与度量关联的度量值的协定，例如指示应该以何频度报 告度量的报告率，或范围。为了减小往返时间，在共同媒体类型的情况下(例如，视频、 音频、语音、字幕等)，客户端接受针对先前内容的媒体类型(这 些媒体类型对应于新内容的一些或所有的媒体类型)所有已经协商 的度量，以便报告新内容的传输质量，从而不需要对于这些度量的 更多协商。换句话说，如果先前媒体传输(例如，媒体流)和新的 媒体传输(例如，媒体流)具有相同的媒体类型，则客户端针对新 的媒体流接受相同QoE度量。所述接受可以涉及度量和与度量关联 的度量值二者。如果需要的话，客户端或服务器可以在会话期间关 闭所述度量。
根据本发明的第二方面的示例性实施方式，客户端在针对新内 容的回放的请求中接受所述度量。
根据本发明的第二方面的另外示例性实施方式，度量是根据第 三代合作伙伴计划分组交换流传输服务的体验质量度量。于是，例
如可以在RTSP PLAY请求中接受所述度量。 第三方面
根据本发明的第三方面，公开了一种方法，该方法包括协商至 少 一 个度量以便报告传输会话的质量，其中在发起多个管道传送的 请求之前，不开始客户端侧协商，所述多个管道传送的请求包括至 少一个针对在传输会话中建立媒体传输的请求和针对在传输会话中 回放内容的请求。
根据本发明的第三方面，进一步公开了其中存储有计算机程序 的计算机可读介质，计算机程序包括可操作以使得处理器来执行根 据本发明的第三方面的方法的指令。将理解到计算机程序本身也被 公开，即在没有存储在计算机可读介质上的情况下。
根据本发明的第三方面，还公开了一种客户端侧设备，其包括 处理单元，所述处理单元配置成协商至少一个度量以便报告传输会 话的质量，其中在发起多个管道传送的请求之前，不开始客户端侧 协商，所述多个管道传送的请求包括至少一个针对在传输会话中建 立媒体传输的请求和针对在传输会话中回放内容的请求。根据本发明的第三方面，还公开了一种客户端侧设备，其包括 用于协商至少 一 个度量以便报告传输会话的质量的装置，其中在发 起多个管道传送的请求之前，不开始客户端侧协商，所述多个管道 传送的请求包括至少一个针对在传输会话中建立媒体传输的请求和 针对在传输会话中回放内容的请求。
根据本发明的第三方面，还公开了一种系统，包括服务器和客 户端，所述客户端包括根据本发明第三方面的设备。
根据本发明的第三方面，还公开了一种协议，所述协议包括一 种规则，该规则规定在发起多个管道传送的请求之前，不应该开始 针对至少 一个度量的客户端侧协商以便传输会话质量的报告，所述 多个管道传送的请求包括至少一个针对在传输会话中建立媒体传输 的请求和针对在传输会话中回放内容的请求。协议例如可以是根据
3GPP PSS的QoE协商协议。
根据本发明的第三方面，在传输会话中，内容被传送到客户端。 所述传输会话例如可以是流传输会话，其中例如在线路绑定或无线 网络或其组合的网络中，内容经由一个或多个媒体流从内容源流传 输到客户端。所述媒体流例如可以是实时传输协议(RTP )媒体流。 传输会话可以通过协议来建立和控制，例如在流传输会话情况下通 过实时流传输协议(RTSP)来建立和控制。
在客户端处，根据一个或多个度量来测量传输会话的质量并且 将其报告给服务器以便处理，例如用于传输会话质量的评估。其中， 向其报告度量的服务器可以不必是内容源。
为了确保快速的会话启动，在多个管道传送的请求发起之前， 不开始针对至少一个度量的客户端侧协商，所述多个管道传送的请
求包括至少 一 个针对在传输会话中建立媒体传输的请求和针对在传 输会话中回放内容的请求。其中,针对回放的请求可以是针对传输 会话(例如可以是RTSP会话)中内容的回放的第一请求。多个管 道传送的请求可以理解为按顺序发起的多个请求，其中在发起下一 个请求前，不等待对发起的请求的响应。通过这种方式，可以实现在开始内容的回放前，度量协商将不会造成任何的额外往返时间。 客户端侧协商例如可以以多个管道传送的"i青求中的 一 个请求来开 始，即建立请求或回放请求。客户端例如可以提供有文件(例如， 会话描述协议(SDP)文件)，其描述服务器接受了哪些度量以便报
告传输会话的质量。该SDP文件例如可以已经由服务器响应于客户 端的RTSP DESCRIBE请求而发送给客户端。同样地，SDP文件可 以预先存储在客户端处或经由其它装置发送到客户端。通过在管道 传送的建立/回放请求之一中传达其对支持的度量(包括与度量关联 的度量值，例如报告率或范围)的选择，客户端继而可以开始客户 端侧协商。
根据本发明的第三方面的示例性实施方式，协商至少部分地发 生在针对内容的回放的请求之后。发生在客户端已经请求了内容的
已经请求了内容的回》文之后的协商或协商的 一 部分可以至少包括建 议改变的度量和/或度量值，其中改变参考协商伙伴的建议。
根据本发明的第三方面的示例性实施方式，度量是根据第三代 合作伙伴分组交换流传输服务的体验质量度量。接着，至少一个度 量的客户端侧协商可以例如以包含"3GPP-QoE-Metrics" ( "3GPP -QoE-度量，，)报头的管道传送的RTSP SETUP/PLAY请求开始。
第四方面
根据本发明的第四方面，公开了一种方法，该方法包括协商至 少 一 个度量以便报告传输会话的质量，其中所述协商至少部分地发 生在客户端已经请求了对传输会话内的内容的回放之后。
根据本发明的第四方面，进一步公开了其中存储有计算机程序 的计算机可读介质，计算机程序包括可操作以使得处理器来执行根 据本发明的第四方面的方法的指令。将理解到计算机程序本身也被 公开，即在没有存储在计算机可读介质上的情况下。
根据本发明的第四方面，还公开了一种客户端侧设备，该设备 包括处理单元，其配置成协商至少 一个度量以便报告传输会话的质
17量，其中所述协商至少部分地发生在客户端已经请求了对传输会话 内的内容的回放之后。设备例如可以是客户端或其 一部分。
根据本发明的第四方面，还公开了一种客户端侧设备，该设备 包括用于协商至少一个度量以便报告传输会话的质量的装置，其中 所述协商至少部分地发生在客户端已经请求了对传输会话内的内容 的回力文之后。设备例如可以是客户端或其一部分。
根据本发明的第四方面，还公开了一种服务器侧设备，所述设 备包括处理单元，其配置成协商由客户端使用的至少一个度量以便 报告传输会话的质量，其中协商至少部分地发生在客户端已经请求 了对传输会话内的内容的回放之后。该设备例如可以是客户端或其 一部分。
根据本发明的第四方面，还公开了一种服务器侧设备，所述设 备包括用于协商由客户端使用的至少 一 个度量以便报告传输会话的 质量的装置，其中协商至少部分地发生在客户端已经请求了对传输 会话内的内容的回放之后。该设备例如可以是客户端或其 一部分。
根据本发明的第四方面，还公开了一种系统，该系统包括包 括根据本发明第四方面的客户端侧设备的客户端以及包括根据本发 明的第四方面的服务器侧设备的服务器。
根据本发明的第四方面，还公开了一种协议，所述协议包括一 种规则，该规则允许用于报告传输会话的质量的至少一个度量在客 户端已经请求了对传输会话内的内容的回放之后至少部分地进行协商。
根据本发明的第四方面，在传输会话中，内容被传送到客户端。 所述传输会话例如可以是流传输会话，其中例如在线路绑定或无线 网络或其组合的网络中，内容经由 一个或多个媒体流从内容源流传 输到客户端。所述媒体流例如可以是实时传输协议(RTP)媒体流。 传输会话可以通过协议来建立和控制，例如在流传输会话情况下通 过实时流传输协议(RTSP)来建立和控制。
在客户端处，根据一个或多个度量来测量传输会话的质量并且将其报告给服务器以便处理，例如用于传输会话质量的评估。其中， 向其报告度量的服务器可以不必是内容源。
回放请求例如可以是传输会话中的第 一 回放请求。在该情况下， 所述协商也可以完全发生在客户端已经请求了内容的回放之后。同 样地，回放请求可以是传输会话中稍后的回放请求。
所述回》文所_清求的所述内容例如可以至少部分;也不同于4十对其 协商至少一个度量的内容。例如，可能已经针对所述传输会话的第 一内容而请求了回放，并且在从第一内容到第二内容的内容切换期 间或之后，开始针对第二内容的至少一个度量的协商。所述协商也 可以完全发生在客户端已经请求了内容的回放之后。
至少一个度量在客户端和服务器之间进行协商。发生在客户端
告。发生在客户端已经请求了内容的回》文之后的协商或协商的一部 分可以至少包括建议改变的度量和/或度量值，其中改变参考协商伙 伴的建议。
根据本发明的第四方面的示例性实施方式，如果发生了从先前 内容到相比较于先前内容中的媒体流包括至少一个额外的或不同的 媒体流的新内容的切换，则客户端通过将涉及至少一个度量的信息 插入到针对在传输会话中建立至少一个媒体流的请求以及针对在传 输会话中回放新内容的请求中的一个请求，来开始协商针对至少一 个媒体流的至少 一个度量，其中这两个请求都被管道传送且从客户 端发送到服务器。
媒体流例如可以是RTP媒体流。例如，通过替换所述媒体流的 (相同或不同媒体类型)内容(例如同时维持媒体流的相同传输和/ 或编解码器参数)，和/或通过替换媒体流和/或通过增加和/或移除 々某体流，内容可以净皮切换。
其中，涉及至少 一个度量的信息例如可以是指示客户端是否期 望使用度量和/或针对与度量关联的度量值的建议。
其中，管道传送形式的发送可以被理解为请求的顺序发送，其中在不等待针对请求中的第 一请求的响应的情况下，发送请求中的
第二请求。在3GPPPSS系统中，涉及至少一个度量的信息例如可以被插入到新媒体的管道传送的RTSP SETUP请求中或内容的管道传送的会聚RTSP PLAY请求中。
根据本发明的第四方面的另外示例性实施方式，度量是根据第三代合作伙伴计划分组交换流传输服务的体验质量度量。第五方面
根据本发明的第五方面，公开了一种方法，包括如果在传输会话中发生从先前内容到新内容的切换，则继承客户端和服务器之间协商的、用于报告先前内容的传输质量的至少 一 个度量。
根据本发明的第五方面，进一步公开了其中存储有计算机程序的计算机可读介质，计算机程序包括可操作以使得处理器来执行根据本发明的第五方面的方法的指令。将理解到计算机程序本身也被
公开，即在没有存储在计算机可读介质上的情况下。
根据本发明的第五方面，还公开了一种设备，该设备包括处理
单元，该处理单元配置成如果在传输会话中发生从先前内容到新内
容的切换，则继承客户端和服务器之间协商的、用于报告先前内容
的传输质量的至少一个度量。
根据本发明的第五方面，还公开了一种设备，该设备包括用于
如果在传输会话中发生从先前内容到新内容的切换，则继承客户端
和服务器之间协商的、用于报告先前内容的传输质量的至少一个度
量的装置。
根据本发明的第五方面，还公开了一种系统，所述系统包括服务器和客户端，并且所述客户端包括根据本发明的第五方面的设备。
根据本发明的第五方面，还公开了一种协议，该协议包括一种规则，该规则允许或规定如果在传输会话中发生从先前内容到新内容的切换，则继承客户端和服务器之间协商的、用于报告先前内容的传输质量的至少 一个度量。
根据本发明的第五方面，在传输会话中，内容被传送到客户端。所述传输会话例如可以是流传输会话，其中例如在线路绑定或无线网络或其组合的网络中，内容经由 一个或多个媒体流从内容源流传
输到客户端。所述媒体流例如可以是实时传输协议(RTP)媒体流。传输会话可以通过协议来建立和控制，例如在流传输会话情况下通过实时流传输协议(RTSP)来建立和控制。
在客户端处，根据一个或多个度量来测量传输会话的质量并且将其报告给服务器以便处理，例如用于传输会话质量的评估。其中，向其报告度量的服务器可以不必是内容源。
在传输会话中，例如响应于用户请求，可以在内容之间进行切换。在流传输会话的情形下，例如，通过替换媒体流的(相同或不同媒体类型)内容(例如同时维持媒体流的相同传输和/或编解码器参数)，和/或通过替换媒体流和/或通过增加和/或移除媒体流，内容可以被切换。在会话通过RTSP来控制的情形下，切换例如可以通过在RTSPPLAY请求中使用"Switch-Steam"("切换-流")报头来完成。
如果这样的内容切换发生，则继承在客户端和服务器之间协商的、用于报告先前内容的流传输的质量的至少一个度量。同样地，新内容可以继承在客户端和服务器之间协商的、以便报告先前内容
的传输质量的所有度量。继承可以意味着已经针对先前内容协商的度量不需要被再次协商以便在切换发生后应用于新内容，而是可以将它们在切换后立即应用于稍后的内容。例如可以针对客户端来规定(例如在SDP文件中或在内容切换之前/内容切换期间的任何RTSP请求中)度量被继承，并且针对服务器规定应该假设度章被继承。
除非明确地修改或停止，新内容的质量的报告可以以与针对先前内容的相同速率来继续。因此可以不需要针对新内容的度量的协商。然而，当报告发生在内容切换完成后的事件时，可以使用涉及新内容的唯一资源定位符而不是涉及先前内容的唯一 资源定位符。
除了继承已经协商的度量以外，可以协商另外的度量(例如，对于不同于先前内容的媒体流的新内容的媒体流)。可以允许该协商至少部分地发生在客户端已经发布了播;改请求之后。
根据本发明的第五方面的示例性实施方式，针对先前内容的报告速率与针对新内容的报告速率相同。除非明确修改或停止，质量的报告可以以与针对先前媒体流或内容的相同速率来继续。
根据本发明的第五方面的示例性实施方式，针对客户端在SDP
文件和在内容的所述切换前或期间的请求之一中规定至少一个度量
应该#皮继承。所述请求例如可以是RTSP请求。
根据本发明的第五方面的示例性实施方式，度量可以是根据第三代合作伙伴分组交换流传输服务的体验质量度量。
通过参考下面的详细描述，本发明的这些和其它方面将变得明显并且被阐明。
本发明的不同方面的特征和如上面所提供的它们的示例性实施方式可以理解为也在彼此的所有可能组合中公开。
在附图中
图1:根据分组交换流传输服务的快速会话启动的示例性图示；图2:根据分组交换流传输服务的快速内容切换的示例性图示；图3:根据本发明的系统的示例性实施方式的示意框图；图4:根据本发明的第一方面的方法的示例性实施方式的流程
图5:根据本发明的第 一 方面的Content_Switch—Time (内容_切换—时间)度量的计算的示意框图6:根据本发明的第二方面的方法的示例性实施方式的流程
图7:根据本发明的第三方面的方法的示例性实施方式的流程
图8:根据本发明的第四方面的方法的示例性实施方式的流程
22图9:根据本发明的第五方面的方法的示例性实施方式的流程图。
具体实施例方式
在本发明的下面详细描述中，将在第三代合作伙伴计划(3GPP)分组交换流传输服务(PSS )系统的环境中描述本发明的示例性实施方式。
图3是根据本发明的系统1的示例性实施方式的示意框图。系统1包括PSS服务器2和PSS客户端3。
服务器2包括控制服务器2的整体操作的处理器20。处理器20执行存储在处理器存储器21中的程序代码，该处理器存储器21例如可以具体实现为固定内置的存储器，例如随机存取存储器(RAM)或只读存储器(ROM),或者具体实现为可移动存储器，例如存储卡或光存储介质。处理器20可以访问到内容存储器，该内容存储器存储将流传输到客户端3的内容。其中，内容例如可以被理解为包括一个或多个媒体流，例如音频和视频流或语音。经由接口22(其例如可以是分组交换接口 )，处理器20能够与客户端3进行通信。
应该注意到，可选地，内容存储于一个或多个专用内容服务器中，并且在该情况下则图1的服务器2仅用作建立和控制客户端3和这样的内容服务器之间的流传输会话的RTSP服务器。然而，为了简洁，在图1中示例性地假设RTSP服务器和内容服务器共处相同的位置。
处理器20对流传输会话中的从服务器2到客户端3的流内容实现所有的功能性，并且监视流传输的质量。为此，处理器20实现用于内容的流传输的协议栈，其包括适配层，其用于将内容的净荷转换成实时传输协议(RTP) 、 RTP、用户数据报协议(UDP)和因特网协议(IP)的格式。而且，处理器20实现用于该流传输的建立和控制的协议栈，包括实时流传输协议(RTSP),其基于传输控制协议(TCP)或基于UDP， 二者都基于IP。 RTSP至少可能需要表示描
23述，例如根据会话描述协议(SDP)，以建立流传输会话。RTSP进一步用于协商服务器2和客户端3之间的体验质量(QoE)度量，并且将这些QoE度量从客户端3传输到服务器2。
客户端3包括用于控制其整体操作的处理器30。处理器30执行存储在处理器存储器31中的程序代码，该处理器存储器31例如可以具体实现为固定内置的存储器，例如随机存取存储器(RAM)或
只读存储器(ROM)，或者具体实现为可移动存储器，例如存储卡或光存储介质。处理器30控制用户接口 32来接收用户输入，并且显示器33和扬声器34用于将流传输会话内的从服务器2流传输到客户端3的内容进行呈现。客户端3进一步包括与服务器2通信的接口 35。所述接口例如可以是基于分组的接口 。
为了提供功能性以便加入到流传输会话中，并且能够将涉及该流传输会话的QoE度量报告给服务器2,客户端3的处理器30实现与由服务器2的处理器20所实现的协议栈对应的协议栈，即，协议栈包括适配层、RTP、 UDP、 IP、 RTSP和可选的TCP。
为了向PSS系统中的服务提供商提供评估端用户流传输体验的手段，已经在PSS系统中引入流传输服务QoE度量。客户端3测量实际流传输应用的质量的信息并且将关于该质量的信息反馈给服务器3,其中根据QoE度量来定义质量。质量度量例如可以通过使用RTSP和SDP来传输。同样地，其它协议也可以用于携带QoE度量，例如会话发起协议(SIP)、扩展标记语言(XML)、超文本传输协议(HTTP)或短消息服务(SMS),还有很多但这里不^"~一列举。
具有质量反馈的PSS系统中的客户端3负责根据测量定义来执行质量测量，将它们会聚成流传输客户端质量度量并且将这些度量报告给服务器2。
服务器2负责用信号通知客户端的QoE度量报告的激活并且收集客户端的QoE度量。服务器2可以处理接收到的客户端QoE度量以构建会聚的质量度量。例如，其可以接收原始丢失的分组报告并且针对特定的客户端来构建Min (最小)、Max(最大)、Avg (平200880008515.9
说明书第18/33页
均)和Std (标准)分组丢失率。
下面将参考图4、 6、 7、 8和9的流程图来详细描述参考本发明
的不同方面的系统1的具体#:作。
根据本发明的第一方面，建议一种新的QoE度量 "Content—Switch_Time，，以允许客户端来向服务器报告内容切换时 间。由于该Content—Switch—Time QoE度量允许运营商或服务提供商 来评价在信道/内容切换期间的用户体验并且因此评价PSSe增强的 有效性，因此其是相当有用的。
该Content—Switch—Time QoE度量报告的格式以如下的扩展巴克 斯-诺尔范式(ABNF)来规定
Parameters-〃Co/itent—Switoh一rirae〃 "=〃 'V" switch-time-
该定义相当适合于3GPPPSS的QoE反馈才艮告语法。
用于该度量的时间戳参数用于指示时间(例如，以常规播放时 间(NPT)表示的)，在该时间处切换操作已经发起。该时间根据 先前内容的时间线。
Content—Switch—Time QoE度量例如可以定义为这样的时间(例 如，以毫秒表示)，即从用户在客户端上选择新内容时刻到第一媒 体帧被回放的时刻。可选地，Content—Switch—Time QoE度量可以萍皮 定义为这样的时间(例如，以毫秒计)，即从切换请求从客户端向 服务器发送的时刻到在客户端处接收新的媒体流的第 一媒体分组的 时刻。Content_Switch_Time QoE度量也可以是上述定义的任意组合。
有利的是，可以要求立即报告Content—Switch—Time QoE度量值。 为此，可以针对Content—Switch—Time QoE度量定义新的报告速率值 "Start"("开始，，)。
有利地，本发明的第一方面通过后向兼容的方式实现到3GPP PSS的QoE框架。例如，可以在SDP文件或在任何的RTSP请求/ 响应消息中执行新的QoE度量的信号发送。如果所协商的速率被设 置为"Start",则可以在内容切换结束后立即报告Content—SwitchJTimeQoE度量。可选地，如果速率被设置成"End" ("结束，，)，则可以在当前内容会话的结尾对Content—Switch_Time QoE度量进行报告。
可以总是基于先前内容的NPT来计算内容切换时间。如果在开 始后立即报告内容切换时间，则可以包括先前内容的NPT时间戳。 否则，时间戳可能对于报告是没有用的。
内容切换时间以毫秒计算并且未经NPT时间缩放。 图5描绘出内容切换时间计算。其示出旧内容的NPT501，墙上 时钟时间502和新内容的NPT 503。接着获得内容切换时间506,作 为内容之间切换完成的时刻505 (例如，第一士某体帧回放的时刻或在 客户端处接收新的媒体流的第一媒体分组的时刻)和由用户触发的 切换时刻504 (例如，用户选4奪新内容的时刻或切换请求从客户端向 服务器发送的时刻)之间的差值，其中根据墙上时钟时间尺度502 来测量该差值。
如果针对Content—Switch—Time QoE度量规定了范围值，该范围 值可以指示这样的时间段在该时间段中如果内容切换发生在该间 隔期间，则报告内容切换时间。该范围应用于先前内容。
图4示出根据本发明的第一方面的示例性实施方式的流程图 400。流程图400的步骤可以例如由客户端3的处理器30(参见图3 ) 来执行以向服务器2报告Content—Switch—Time QoE度量。其中，该 流程图中的步骤顺序以及在该说明书中所示出的所有其它流程图中 的步骤不应该被理解为是绑定的，而且偏离于这些步骤的顺序也是 可以4吏用的。
在第一步骤401中，例如响应于RTSP DESCRIBE请求，获得 SDP文件。同样地，SDP文件可以经由HTTP来接收，或可以用于 客户端3，例如可以存储在客户端3可对其进行访问的位置。SDP 文件例如可以预先存储在客户端中。SDP文件包含QoE度量以及服 务器2所支持的相关QoE度量值(例如报告速率)。为了简化表示， 假设服务器仅支持具有速率="Start"的Content—Switch—Time QoE
26度量。
在步骤402中，客户端3请求建立具有特定内容的媒体流(经 由RTSP SETUP请求)。在这些RTSP SETUP请求中，包括 "3GPP-QoE-度量"报头并且配置成向服务器2报告客户端3接受了 SDP文件的所有QoE度量和相关的QoE度量值(即，具有速率=
"Start"的ContenLSwitch_Time QoE度量)。事实上，QoE度量协 商于是可以被认为终结。然而，响应于RTSP建立请求，服务器2 可以回应接受的参数，以便对客户端3重确认。
在步骤403中，客户端3经由RTSPPLAY请求来请求内容的回 放。为了减小会话建立时间，该请求也可以以管道传送的形式与 RTSP SETUP请求一起发送，即，在发送RTSP PLAY请求前无需等 待针对RTSP SETUP请求的响应。在该情况下，事实上本发明的第 三方面将被实现，如下面将参考图7进行讨论的那样。
返回到图4，在步骤404中，客户端3接着接收来自于服务器2 的内容。
在步骤405中，客户端3已经决定切换内容，并且例如可以向 服务器2发布具有包括的RTSP "Switch-Stream"("切换-流，，) 报头的过载RTSPPLAY请求。这使得内容切换的发生。
在步骤406中，与Content_Switch—Time QoE度量关联的报告速 率被协商至值"Start"(意味着在内容切换已经发生后，同时报告 内容切换时间)，客户端3测量与内容的切换关联的内容切换时间， 将测量结果会聚成Content—Switch—Time QoE度量并且将该QoE度 量发送到服务器2，例如经由"3GPP-QoE-feedback，， ( "3GPP-QoE-反馈，，)报头包括在RTSP SET—PARAMETER请求中。
最终，在步骤407中，客户端3接收新内容。
在下文中，将提供根据本发明的第一方面的 Content一Switch_Time QoE度量的协商的可选的、而更为详细的例子。 其中，符号"S->C，，指示内容从服务器(S)发送到客户端(C), 而符号"C-〉S，，指示信息从客户端发送到服务器。涉及Content—Switch—Time QoE度量的信息以黑体给出。进一步，协商的 相关度量值被加注下划线。
初始地，响应于客户端3的RTSP DESCRIBE请求，服务器2 在响应消息中提供下面的SDP文件(该响应消息例如在图4的流程 图400的步骤401中接收)
S->C RTSP/1.0 200 OK
Cseq;: 1
Content-Type: application/sdp
Content-Base: rtsp: //example.com/foo/bar/ba2;.3gp/ Content-Length: 800 Server: Server
v=(3
o=- 3268077682 433392265 IN工P4 63.108.142.5 s=QoE Enables Session Description Example e=support@foo.com c=IN工P4 0.0.0.0 t = 0 0
a=range:npt=0-83.660000
a=3GPP—QoE-Meti:ics: {Cont;ftnt_Switch_Time} '.rate=Start
a-control:*
m=video 0 RTP/AVP 96
b=AS:28
扭3GPP-QoE-他ti:ics: {Content_Switcli_Time}; rate=Staxt
a=control:trackID=3 a-rtpniap: 9 6 MP4V-ES/1000 a=range:npt=0-83.666000 a=fmtp:96profile-level-
id=8,-config=0000Dlb0080D0001i>503 00012000 m-auciio 0 RTP/AVP 98
b-AS:13
a=3GPP-QoE-Metrics:{Content— Switch— Time};rste=Start
a-control:trackID=5 a=rtpinap:98 AMR/8000 a=:cange:npt=0-83 . 660000 a=fmtp:98 octet-align-l a=maxptime:200
下面的请求在由客户端3所发起的RTSP SETUP和PLAY请求 以及由服务器2发起针对其的响应中示出Content—Switch_Time QoE 度量的协商。该例子示出了报告速率的协商，该报告速率由客户端3 从"Start"改变到"End"的并且接着由服务器2从"End"改变到 "Start"(该协商因此偏离于图4中的流程400的步骤402中的协 商，其中客户端3直接接受SDP文件中的QoE度量和相关速率)。客户端3最终在RTSP PLAY请求中接受速率"Start"。
C->S SETUP rtsp://example.com/foo/bar/baz.3gp/trackID=l RTSP/1.0 Cseq: 2 3GPP-QoE-
Metrics: url-〃rtsp: / /exanqple. com/f oo/b r/ba2;. 3gp/trajek工
边etries-《Contsiit一Switc:h一Time} ;rate，End
C->S SETUP rtsp://example.com/foo/bar/baz.3gp/track工D-2 RTSP/1,0 Cseq: 3 3GPP-QoE-
Metrics :url-":ctsp: / /example, com/f00/bar/ba2 .,3gp/t:cackl
metri es=《Content—Switch—Tiro}/rata=End
S->C RTSP/1.0 200 OK Csecj: 2
Session: 17903320
Transport: RTP/AVP;unicast;client_port=7 000-7 001;server_port= 6970-6971
3GPP-QoE-
Metrics: u:rl="rtsp: //exaa^)le ， com/f oo/bar/baz. 3gp/ti:eLckl metrics—Content一Switch一Timel ;rat炉Start
S->C RTSP/1.0 200 OK Cseq: 3
Session: 17903320
Transport: RTP/AVP;unicast;clierit_port==7 004-7005;server port= 6900-6901
Metrics: url-"rtsp: / /example. eom/f oo/b*r/baz. 3gp/trackl
D-5"7
边etxics-{C。rruption一Duration | Doeoded一Bytas}; rate=Stai:t
C->S PLAY rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 4 3GFP-QoE-
Metrics: url 〃r:tsp: / /example. com/f oo/bar/baz. 3gp/trac]cl
加trica:(Content—Switch—Time} ;rate=Start,
Metrics:url豕"rtsp://axaa^le.com/foo/bar/baz.3gp/trackl D=5〃,，
metricB={Content—Switch—Time} ,' rate=Sbart
下面的请求是Content—Switch—Time QoE度量的反馈的例子。这里，内容切换时间是200ms,并且该内容切换在先前内容的NPT时 间戳2105.2处发起(该反馈例如可以在图4的流程图400的步骤406
中执行)。
C->S SET—paramETER rtsp://example.com/foo/bar.3gp RTSP/1.0 Cseg: 201 Session: 235，2 3GPP-QoE-Feedback:
url=、、3rtsj>: //axample com/f oo/bar. 3gp/trackID=l",' Cont抑t一Switch一Time-{200 2105.1} Content—length: 0
本发明的第二方面涉及将QoE度量协商协议应用于切换内容， 并且建议，如果先前媒体流的内容和新的J 某体流的内容具有相同的 媒体类型，则客户端应该接受PLAY请求的"Switch-Stream"报头 中的相同QoE度量。不再需要对这些参数进行协商。如果需要，客 户端或服务器可以在会话期间关闭这些度量。
另外，本发明的第四方面也涉及将QoE度量协商协议应用于切 换内容，并且建议允许在PLAY请求之后进行QoE度量协商(例如， 会话的初始PLAY请求)。例如，对于具有比旧内容更多i某体流的 新内容，可以在会话期间协商针对新媒体流的QoE度量(在版本6 中当前并不允许)。客户端应该将其对支持的QoE的度量的选择包 括在新媒体的管道传送的SETUP请求中或内容的管道传送的会聚 PLAY请求中(对于具有比旧内容更少的媒体流的新内容，可以不需 要更多的QoE度量协商)。
图6示出根据本发明第二方面和第四方面的方法的示例性实施 方式的流程图600。该流程图的步骤例如可以由图3中系统1的客户 端3的处理器30来执行。在该流程图中，示例性地假设在内容的 切换中，媒体流的数目保持不变。切换后的额外媒体流的情况由图8 的流程图800来覆盖。
在第一步骤601中，例如响应于RTSP DESCRIBE请求，客户端 3获得SDP文件。SDP文件也可以预先存储在客户端中。
在步骤602中，客户端3请求媒体流的建立(经由RTSP SETUP请求)，并且接受如由服务器2在SDP文件中所建议的所有QoE度
量和相关的度量值。
在步骤603中，客户端3接着经由RTSPPLAY请求来请求内容 的回放，并且在步骤604中，接收内容。
在步骤605中，确定是否期望内容的切换。如果不期望切换内 容，则流程返回到步骤604。否则，检查在先前内容和新内容中是否 有共同的媒体类型(例如，视频/音频/语音等媒体类型)。
如果期望内容的切换，则在步骤607中可以应用本发明的第二 方面，即例如在RTSPPLAY请求中，接受针对与新内容的媒体类型 共同的先前内容的媒体类型(例如，视频/音频/语音等媒体类型)所 协商的所有QoE度量(以及相关的度量值，即，报告速率)。
如果新内容还包括不同于先前内容的媒体类型的媒体类型，本 发明的第四方面可以应用于步骤607中，即允许针对这些々某体类型 的QoE度量进行协商，尽管该协商至少部分地发生在已经发起了 RTSPPLAY请求之后。例如，客户端3通过在针对新的媒体的管道 传送的RTSP SETUP请求或针对新内容的管道传送的会聚RTSP PLAY请求中传达其对QoE度量(包括相关的QoE度量值)的选择 来开始协商。如果服务器2并不同意客户端对QoE度量的选择，则 将仍允许继续该协商，例如通过建议偏离参数以响应于RTSP SETUP 或PLAY请求。其中，包含针对新内容的QoE度量的描述的SDP文 件可以响应于DESCRIBE请求已被发送到客户端3，或者可以预先 存储在客户端中，或者可以在切换期间对其进行请求(未在图6中 示出)并且经由RTSP或其它手段发送到客户端。
类似地，如果在步骤606中确定在先前内容和新内容之间没有 共同的媒体类型，则在步骤608中可以应用本发明的第四方面，即 开始针对新媒体类型的QoE度量的协商，尽管该协商至少部分地发 生在已经发起了 RTSPPLAY请求之后。客户端3通过在针对新的媒 体的管道传送的RTSP SETUP请求或针对内容的管道传送的会聚 RTSP PLAY请求中传达其对QoE度量(包括相关的QoE度量值)的选择来开始协商。正如上文所描述的，在该情况下，包含针对新
内容的QoE度量的描述的SDP文件可以响应于DESCRIBE请求已 被发送到客户端3，或者可以预先存储在客户端中，或者可以在切换 期间对其进行请求(未在图6中示出)并且经由RTSP或其它手段 发送到客户端。
在步骤609中，接着接收新内容，并且测量和报告协商的QoE度量。
本发明的第三方面涉及将QoE度量协商协议应用于快速会话建 立，并且建议对于快速会话启动，在PLAY请求前，不应增加QoE 度量协商。在管道传送的SETUP/PLAY请求之一中，客户端应该传 达其对所支持的QoE度量的选择，该支持的QoE度量是由其在SDP 文件中接收到的。
图7绘出根据本发明的第三方面的方法的示例性实施方式的流 程图700。该流程图的步骤例如可以通过图3中系统1的客户端3 的处理器30来执行。
在第一步骤701中，例如响应于RTSP DESCRIBE请求，客户端 3获得SDP文件。SDP文件例如可以预先存4诸在客户端中或经由其 它手段发送到客户端。
在步骤702中，客户端3发起多个管道传送的请求，即顺序发 起多个请求，其中第二请求在不等待针对已经发送的第 一请求的响 应的情况下发送，第三请求在不等待针对发送的第二请求的响应的 情况下发送，并且以此类推。
这些管道传送的请求包括针对将在流传输会话中流传输的内容 的媒体流的建立的RTSP SETUP请求以及针对触发在内容中会聚的 所有媒体流的回放的会聚RTSP PLAY请求。客户端对于支持的QoE 度量的选择通过"3GPP-QoE-metrics"报头包括在RTSP SETUP请 求中或在RTSP PLAY请求中。
月良务器可以在响应消息中接受客户端的选择，服务器终结协商， 或可以做出偏离于客户端的选择的建议。在后一种情况中(在图7的流程图中未示出)根据本发明的第四方面应用建议是有利的，因 为协商可以未被完成，而根据本发明的第四方面，允许协商至少部 分地发生在已经请求了回放以后。
因此，根据本发明的第三方面，将不再RTSP播放请求前开始协
商，这避免了由QoE度量协商所造成的额外往返时间，并且确保了
快速的会话建立。
在流程图700的最后步骤703中，接着接收内容，并且如协商 的那样测量和报告QoE度量。
正如上面所描述的，本发明的第四方面也涉及将QoE度量协商 协议应用于内容的切换并且建议在PLAY请求(即，会话的初始 PLAY请求)后允许QoE度量协商。例如，对于比旧内容具有更多 的媒体流的新内容，可以在会话期间协商针对新的媒体流的QoE度 量(版本6中当前并不允许)。客户端应该将其对所支持的QoE的 度量的选择包括在新^ 某体的管道传送的SETUP请求中或内容的管道 传送的会聚PLAY请求中(对于具有比旧内容更少的媒体流的新内 容，不需要更多的QoE度量协商)。
图8示出根据本发明的第四方面的方法的示例性实施方式的流 程图800。该流程图的步骤例如可以由图3中系统1的客户端3的处 理器30来执行。
在第一步骤801中，例如响应于RTSP DESCRIBE请求，客户端 3获得SDP文件。SDP文件例如可以预先存储在客户端中或经由其 它手段发送到客户端。
在步骤802中，客户端3请求媒体流的建立(经由RTSP SETUP 请求)，并且接受如服务器2在SDP文件中所建议的所有QoE度量
和相关的度量值。
在步骤803中，客户端3接着经由RTSPPLAY请求来请求内容 的回放，并且在步骤804中，接收内容。步骤802中的RTSP PLAY 请求因此是流传输会话中的第一 RTSP PLAY请求。
在步骤805中，客户端3请求内容的切换。其中，示例性地4支设新内容包括比旧内容更多的媒体流，即当切换内容时，增加一个 或多个媒体流。而根据本发明的第二方面，如果这些媒体流的媒体 类型保持不变，可以接受针对维持的媒体流的已协商QoE度量，而 用于额外媒体流的QoE度量可能需要协商。因此有利的是允许协商 发生在初始RTSP PLAY请求803之后。
例如，客户端3可以将其对所支持的QoE度量的选择包括在新 媒体流的管道传送的RTSP SETUP请求中或新内容的管道传送的会 聚RTSPPLAY请求中，以便开始协商。响应于该请求，服务器2可 接着接受所建议的QoE度量以及QoE度量值或做出不同的建议。客 户端3接着可以接受或做出另外不同的建议。
包含针对新内容的QoE度量的描述的SDP文件可以响应于 DESCRIBE请求已被发送到客户端3，或者可以预先存储在客户端 中，或者可以在切换期间对其进行请求(未在图8中示出)并且经 由RTSP或其它手段发送到客户端。
在步骤806中，接着接收新内容，并且在步骤807中，测量和 报告QoE度量。
本发明的第五方面涉及将QoE度量协商协议应用于内容的切换 并且建议由新内容来继承已协商的QoE度量。除非明确修改或停止， 报告以针对先前的媒体流或内容的相同速率来继续。然而，当报告 发生在切换完成之后的事件时，应该使用新的URL而不是旧的URL。
图9图示出根据本发明的第五方面的方法的示例性实施方式的 流程图900。该流程图的步骤例如可以由图3中系统1的客户端3 的处理器30来执行。
在第一步骤901中，例如响应于RTSP DESCRIBE请求，客户端 3获得SDP文件。SDP文件例如可以预先存储在客户端中或经由其 它手段发送到客户端。
在步骤902中，客户端3请求媒体流的建立(经由RTSP SETUP 请求)，并且接受如服务器2在SDP文件中所建议的所有QoE度量 和相关的度量值。在步骤903中，客户端3接着经由RTSPPLAY请求来请求内容 的回放，并且在步骤卯4中，接收内容。
在步骤905中，客户端3请求内容的切换，并且从先前内容继 承已协商的QoE度量。继承意味着针对先前内容已协商的QoE度量 不需要被再次协商以便可以在切换发生之后应用于新内容，而是将 它们在切换后立即应用于稍后的内容。
除了继承已经协商的度量以外，可以协商另外的度量(例如， 对于不同于先前内容的媒体流的新内容的媒体流)。可以允许该协 商过程发生在由客户端已发布了播放请求之后(即，根据本发明的 第四方面)，并且可以例如以在管道传送的RTSP SETPU请求或管 道传送的会聚RTSPPLAY请求中的QoE度量(以及相关的QoE度 量值)的建议来开始协商过程。
包含针对新内容的QoE度量的描述的SDP文件可以响应于 DESCRIBE请求已被发送到客户端3,或者可以预先存储在客户端 中，或者可以在切换期间对其进行请求(未在图8中示出)并且经 由RTSP或其它手段发送到客户端。
在步骤906中，接着接收新内容，并且在步骤907中，测量和 报告继承的QoE度量。其中，报告以针对先前的媒体流或内容的相 同速率来继续。当报告在切换完成之后发生的事件时，应该使用新 的URL而不是旧的URL。
在下文中，将提供根据本发明的QoE度量协商的另外例子，特 别是参考本发明的第一、第三和第四方面。为了简化控制tmckID的 跟踪以及它们的QoE度量的相关"rate"("速率")，这些参数被 加下划线。另外，所有的"3GPP-QoE-Metrics"报头以黑体给出。
在下面的例子中，客户端同意报告由服务器在SDP文件中所支 持的所有QoE参数，其中有根据本发明的第一方面的 Content—Switch—Time QoE度量。
然而，它不能以服务器在SDP文件中所请求的"rate"来报告它 们。因此，它建议对与一些QoE参数关联的"rate"特征进行一些改变(将trackID=3中的速率从10改变到15并且将trackID=5中的速 率从20改变到40)。根据本发明的第三方面，客户端在管道传送的 RTSP PLAY请求中指示这些改变。另外，根据本发明的第四方面， 这造成QoE度量协商至少部分地发生在已经发起了 RTSP PLAY i青 求之后，因为服务器被要求(甚至当接受了客户端的建议)响应于 RTSP PLAY请求而对客户端的建议做出回应，从而对客户端进4亍确 认。
S->C RTSP/1.0 200 OK Cseg: 1
Content-Type: application/sdp
Content-Base: rtsp://example.com/foo/bar7baz.3gp/ Content-Length: 謂 Server: PSSR6 Server
v=0
o=- 3268077682 433392265 IN IP4 63.108.142.6 s=QoE Enables Session Description Example e=support@foo.com c=IN工P4 0.0.0.0
arrange:npt=0-83.660000 a=3GPP-QoE-
Metrics : {InitialJBufferingJDurationl Rebuffe;ring一Dura tion} zrate-End
a-3GPP-QoE-Metrics: {Content—Switch—Time} rate^Start a=control:*
m=video 0 RTP/AVP 96 b=AS:2 8
Metrics: {Cosriruption—Duration|Deood d—Bytes} ,*rat =10; range:npt=0—40a豕control:trackID=3
a=rtpmap:96 MP4V-ES/1000 a=range:npt=0-83.666000 a-fmtp:96profile-level-id-S'-Config-OOOOOlbOOSOOOOOlbSOSOOOlSOOO m=au<3io 0 RTP/AVP 98 b-AS:13
a=rtpmap:98 AMR/,0 a=rangempt-0-83 . 660画 a=fmtp:98 octet-align-l a-maxptime:200
C->S SETUP rtsp;//example.cora/foo/bar/baz.3gp/trackID= RTSP/l.D Cseg: 2
C->S SETUP rtsp://example.com/foo/bar/baz.3gp/tracklD=2 RTSP/1.0 Cseg: 3
C->S PLAY rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 4
3GPP-QoE-
Metrics ; url-〃rtsp: //狄an^le. com/f oo/baur/baz. 3gp/tr&c
3cID=3";
鹏tricsss ■(Corruption—Duration' Decsoded一Bytes},' rate sl5; Range:npt=0 - 4 0,
u:cl-〃rtsp: //exan^le. c加/f oo/bar/baz. 3gp/ trackID=5 ",'
metirics="{Coj:ruptioii—Dui:atioii}raten^O; Range :npt*sO-40, —
u:cl-"rtsp: / /example. c加/f oo/bax/baz . 3gp〃 ,'
metrics-{Initial_Buffering—Duration | Rebuf f eriixg一Duca
tion h rate End
metrics= {Content Switch Time} ,':cat =Stai:t7
服务器接受报告的"rate"中的这些改变。因此，通过回应 "3GPP-QoE-Metrics"报头的内容，服务器对RTSP PLAY请求做出 响应而确认其的接受。如上文中所述，因此本发明的第四方面应用 在此，因为QoE度量协商至少部分地(即，对于参数的服务器侧的 接受)发生在RTSP PLAY请求之后。S->C RTSP/1.0 200 OK Csecj: 2
S->C RTSP/1.0 200 OK Cseq,' 3
S->C RTSP/1,0 200 OK Cseg: 4
3GPP-QoE-
Metrics: url-〃rts;p: //战an^le. com/f oo/bar/baz. 3gp/trac kID=3";
鹏trics叫Corruption—Duration | Decoded—Bytes} rats=15卩 Range:npt-0-40,
url-〃:ctsp: //example. eom/f oo/bar/baz. 3qp/,r ; met::icsaMCoj:ruptioii一Diirationl,. ratew40; Range :apt-O-40,' —
url-"rtsp: //exan^>le. co迈/foo/bar/baz. 3gp";
nratrics={ Initial一Buf f枕ing一;Dui:at:ion | Robuf f虹iag一Dua:a
tion}'- ~be=End ,*
迈atrics- {Cont抑t一Switch一Time},- j: te=Star"t r-
可替换地，如果服务器不同意客户端所建议的改变，则其在 RTSP PLAY响应之外继续协商(也根据本发明的第四方面)。
如果RTSP PLAY响应中的QoE参数与由客户端在RTSP PLAY 请求中所建议的参数相同，则客户端应该停止协商。
否则，它应该使用RTSP OPTIONS或RTSP SET—PARAMETER 请求来继续协商直到客户端和服务器达成一致。
下面的例子是上面的例子的继续(也根据本发明的第四方面)， 其中服务器同意所有度量和相关的值中的客户端建议，除了针对 QoE度量"Decoded—Bytes"("解码的—字节，，)的"rate"。月良务器 建议以"rate" =5来发送"Decoded—Bytes"。 ^f旦客户端不能如此频繁 地发送它们，因此它在下 一 轮的协商中以支持的最大速率来发送 ("rate，，二10)。其从协商中排除已经同意的QoE度量。其使用RTSP OPTIONS请求来再次建议用于剩余QoE度量的新值。服务器最终同 意该值。S->C. RTSP/1. 0 200 OK Cseg: 4
Metrics: url迈〃rtsp: //抑az^le. c咖/foo/bar/baz ， 3gp/ trmc IclDW; metrics {Cor:cuptio:n一Emrati011 } ;rate豕15; Range;npt^0-40,
taetrics={Decoded_Bytes },' wt炉5; Range :npt豕0-40,
url-"rtsp: //example. com/f oo/bar/bax, 3gp/ tr&。)cID-5〃;
Hietrios= {Corruption一DiMration}rate=40,' Range: npt-0-
-
tu:l-〃rtsp: //战ample. com/f oo/bair/baz. 3gp', /
metrics- {Ini tial一Biaf f ajri:ag一Duxation | Rebuff earing Dura
metrics-{Cont抑t一Svritch一Time} j:ate=Start f-
C->S OPTIONS rtsp://example.com/foo/bar/toaz.3gp/trackID=5 RTSP/1.0 Cseq: 5 3GPP-QoE-
Metrics: urls="rtsp: //eacaicple. <2can/f oo/bar/bas . 3gp/trac ma~trics={ Decoded—Bytes },. rate=10; Ran^e: npt=0-40,
S->C RTSP/1.0 200 OK Cseq: 5
Metrics :url-"rtsp: //example. com/foo/bar/baz. 3gp/trac
metxic3 { Decoded一Bytes } rat炉l0/ Range:npt=0-40,
在本发明的上述详细描述中，已经在第三代合作伙伴计划 (3GPP)分组交换流传输服务(PSS)系统中描述了本发明的示例 性实施方式。
将理解到本发明不限于部署在3GPPPSS系统中，而是同样地可 以部署在其中可应用质量报告的所有其它类型的传输系统中，例如 传统系统(例如，视频电话)的环境中，其中经由网络交换两个或 多个客户端之间的信息，并且其中度量例如可以由网元(例如会话 发起协议(SIP )代理)来捕获。
用于本发明的另外示例性部署场景是多媒体广播/多播服务 (MBMS),其中也可以使用切换时间度量并且经由扩展标记语言 (XML)、超文本传输协议(HTTP)或其它手段传送到服务器。内容切换时间度量也可以表示MBMS和单播PSS之间或反之的切换。
如果内容相同，则内容切换时间可以测量从一个网络切换到另 一个 网络所要占用的时间。如果内容不同，则内容切换时间可以测量从 一个网络切换到另 一 个网络所占用的时间加上根据本发明的第 一方 面已定义的内容切换时间。
很容易理解QoE度量不必须由RTSP和SDP来携带。同样地， 其它的协议也可以用于携带QoE度量，例如SIP、 XML、 HTTP或 短消息服务(SMS),还包括其它而不在此——列举。
上面已经通过示例性实施方式描述了本发明。应该注意到对于 本领域技术人员来说明显的是还存在可替换的方式和变形并且可以 在不偏离所附权利要求书的范围和精神的情况下实现。
进一步，对于技术人员来说很清楚的是，示意框图中的逻辑块 以及在上面描述中所示出的流程图和算法步骤可以至少部分地以电 子硬件和/或计算机软件来实现，其中这取决于逻辑块、流程图步骤 和算法步骤的功能性，并且取决于施加到相应的设备的 一 定程度的 设计限制，其中要求逻辑块、流程图步骤或算法步骤以硬件或软件 来实现。所示出的逻辑块、流程图步骤和算法步骤例如可以实现在 一个或多个数字信号处理器中、专用集成电路、现场门阵列或其它 可编程器件中。计算机软件可以存储在电的、磁的、电磁的或光类 型的各种存储介质中，并且可以由处理器(例如微处理器)来读取 和执行。为此，处理器和存储介质可以耦合以互换信息，或可以将 存储介质包括在处理器中。
最后，应该理解本发明的实施方式以彼此的所有可能组合来^^开。
40
权利要求
1.一种客户端侧方法，所述方法包括-根据将要报告给服务器的一个或多个度量来测量传输会话的质量，其中所述一个或多个度量包括内容切换时间度量，该内容切换时间度量涉及在所述传输会话中内容间切换所占用的时间。
2. 根据权利要求1所述的方法，其中所述内容切换时间度量被 定义为这样的时间之一 ，从在客户端上新内容被选择的时刻到所述 新内容的第 一媒体帧被回放的时刻的时间，以及从从客户端向服务器发送切换请求的时刻到在所述客户端处接收所述新内容的第 一 媒 体分组的时刻的时间。
3. 根据权利要求1所述的方法，其中可以协商所述内容切换时 间度量以便立即被报告。
4. 根据权利要求1所述的方法，其中所述内容切换时间度量是 第三代合作伙伴计划分组交换流传输服务的体验质量度量。
5. —种其中存储有计算机程序的计算机可读介质，所述计算机 程序包括可操作以使得处理器来执行根据权利要求1所述的方法。
6. —种客户端侧设备，所述设备包括-处理单元，其配置成根据将要报告给服务器的一个或多个度量 来测量传输会话的质量，其中所述 一 个或多个度量包括内容切换时 间度量，该内容切换时间度量涉及在所述传输会话中内容间切换所 占用的时间。
7. 根据权利要求6所述的设备，其中所述内容切换时间度量是 第三代合作伙伴计划分组交换流传输服务的体验质量度量。
8. —种服务器侧方法，所述方法包括-处理一个或多个度量，客户端将根据该一个或多个度量报告传 输会话的质量，其中所述一个或多个度量包括内容切换时间度量， 该内容切换时间度量涉及在传输会话中内容间切换所占用的时间。
9. 根据权利要求8所述的方法，其中所述内容切换时间度量是 第三代合作伙伴计划分组交换流传输服务的体验质量度量。
10. —种其中存储有计算机程序的计算机可读介质，所述计算机程序包括可操作以使得处理器来执行根据权利要求8所述的方法的指令。
11. 一种服务器侧设备，所述设备包括-处理单元，其配置成处理一个或多个度量，客户端将根据该一 个或多个度量报告传输会话的质量，其中所述一个或多个度量包括 内容切换时间度量，该内容切换时间度量涉及在传输会话中内容间 切换所占用的时间。
12. 根据权利要求11所述的设备，其中所述内容切换时间度量 是第三代合作伙伴计划分组交换流传输服务的体验质量度量。
13. —种系统，包括根据权利要求6所述的客户端侧设备和根据 权利要求11所述的服务器侧设备。
14. 一种方法，该方法包4舌-如果在传输会话中发生从先前内容到具有所述先前内容和新内 容之间共同媒体类型的所述新内容的切换时，为了报告所述新内容的传输质量，在客户端处接受所有已经在客户端和服务器之间协商 的、用于报告所述先前内容的所述共同媒体类型的传输质量的 一 个 或多个度量。
15. 根据权利要求14所述的方法，其中所述客户端在针对所述 新内容的回放的请求中接受所述度量。
16. 根据权利要求14所述的方法，其中所述度量是根据第三代 合作伙伴计划分组交换流传输服务的体验质量度量。
17. —种其中存储有计算机程序的计算机可读介质，所述计算机 程序包括可操作以使得处理器来执行根据权利要求14所述的方法的 指令。
18. —种设备，该设备包括-处理单元，其配置成如果在传输会话中发生从先前内容到具有所述先前内容和新内容之间共同媒体类型的所述新内容的切换时， 为了报告所述新内容的传输质量，接受所有已经在客户端和服务器 之间协商的、用于报告所述先前内容的所述共同媒体类型的传输质 量的一个或多个度量。
19.根据权利要求18所述的设备，其中所述内容切换时间度量是第三代合作伙伴计划分组交换流传输服务的体验质量度量。
20， 一种系统，所述系统包括服务器和客户端，其中所述客户端 包括根据权利要求19所述的设备。
21. —种协议，所述协议包括一种规则，该规则允许或规定如果在传输会话中发生从先前内容 到具有所述先前内容和新内容之间共同媒体类型的所述新内容的切 换时，客户端接受所有已经在所述客户端和服务器之间协商的、用 于报告先前内容的传输质量的一个或多个度量，以便报告所述新内 容的所述共同媒体类型的传输质量。
22. —种方法，该方法包4舌-协商至少一个度量以便报告传输会话的质量，其中在对多个管 道传送的请求的一个发起之前，不开始客户端侧协商，所述多个管 道传送的请求包括至少一个针对在所述传输会话中建立媒体传输的 请求和针对在所述传输会话中回放内容的请求。
23. 根据权利要求22所述的方法，其中所述协商至少部分地发 生在针对所述内容的回放的请求之后。
24. 根据权利要求22所述的方法，其中所述度量是根据第三代 合作伙伴计划分组交换流传输服务的体验质量度量。
25. —种其中存储有计算机程序的计算机可读介质，所述计算机 程序包括可操作以使得处理器来执行根据权利要求22所述的方法的 指令。
26. —种客户端侧设备，其包括-处理单元，所述处理单元配置成协商至少一个度量以便报告传 输会话的质量，其中在多个管道传送的请求的一个发起之前，不开始客户端侧协商，所述多个管道传送的请求包括至少一个针对在所 述传输会话中建立媒体传输的请求和针对在所述传输会话中回放内 容的请求。
27. 根据权利要求26所述的设备，其中所述内容切换时间度量 是第三代合作伙伴计划分组交换流传输服务的体验质量度量。
28. —种系统，包括服务器和客户端，所述客户端包括根据权利 要求26所述的设备。
29. —种协议，所述协议包括-一种规则，该身见则-见定在多个管道传送的请求的一个发起之前， 不应该开始对至少 一个度量的客户端侧协商以便报告传输会话的质 量，所述多个管道传送的请求包括至少一个针对在所述传输会话中 建立媒体传输的请求和针对在所述传输会话中回放内容的请求。
30. —种方法，该方法包4舌协商至少 一 个度量以便报告传输会话的质量，其中所述协商至少 部分地发生在客户端已经请求了对所述传输会话内的内容的回放之后。
31. 根据权利要求30所述的方法，其中如果发生了从先前内容 到相比较于先前内容中的媒体流包括至少一个不同的或额外的媒体 流的新内容的切换，则所述客户端通过将涉及至少 一个度量的信息 插入到针对在所述传输会话中建立至少 一个媒体流的请求以及针对 在所述传输会话中回放所述新内容的请求之一，来开始协商针对所 述至少 一个媒体流的所述至少 一个度量，这两个请求都被管道传送 且从所述客户端发送到所述服务器。
32. 根据权利要求30所述的方法，其中所述度量是第三代合作 伙伴计划分组交换流传输服务的体验质量度量。
33. —种其中存储有计算机程序的计算机可读介质，所述计算机 程序包括可操作以使得处理器来执行根据权利要求30所述的方法的 指令。
34. —种客户端侧设备，该设备包括-处理单元，其配置成协商至少 一 个度量以便报告传输会话的质 量，其中所述协商至少部分地发生在客户端已经请求了对所述传输 会话内的内容的回方文之后。
35. 根据权利要求34所迷的设备，其中所述内容切换时间度量 是第三代合作伙伴计划分组交换流传输服务的体验质量度量。
36. —种服务器侧设备，所述设备包括-处理单元，其配置成协商由客户端使用的、以便报告传输会话 的质量的至少一个度量，其中所述协商至少部分地发生在客户端已 经请求了对所述传输会话内的内容的回放之后。
37. 根据权利要求36所述的设备，其中所述内容切换时间度量 是第三代合作伙伴计划分组交换流传输服务的体验质量度量。
38. —种系统，该系统包括根据权利要求34所述的客户端侧设 备的客户端和根据权利要求36所述的服务器侧设备的服务器。
39. —种协议，所述协议包括-一种规则，该规则允许在客户端已经请求了对所述传输会话内一个度量。
40. —种方法，包括-如果在传输会话中发生从先前内容到新内容的切换，则继承客 户端和服务器之间协商的、用于报告所述先前内容的传输质量的至 少一个度量。
41. 根据权利要求40所述的方法，其中针对先前内容的报告速 率与针对所述新内容的报告速率相同。
42. 根据权利要求40所述的方法，其中在SDP文件和在内容的 所述切换前或期间的请求之 一 中，针对客户端规定应该继承至少一个度量。
43. 根据权利要求40所述的方法，其中所述度量是根据第三代 合作伙伴计划分组交换流传输服务的体验质量度量。
44. 一种其中存储有的计算机程序的计算机可读介质，所述计算机程序包括可操作以使得处理器来执行根据权利要求40的方法的指令。
45. —种设备，该设备包括-处理单元，该处理单元配置成如果在传输会话中发生从先前内 容到新内容的切换，则继承客户端和服务器之间协商的、用于报告 所述先前内容的传输质量的至少一个度量。
46. 根据权利要求45所述的设备，其中所述内容切换时间度量 是第三代合作伙伴计划分组交换流传输服务的体验质量度量。
47. —种系统，所述系统包括服务器和客户端，并且所述客户端 包括根据权利要求45所述的设备。
48. —种协议，该协议包4舌-一种规则，该规则允许或规定如果在传输会话中发生从先前内 容到新内容的切换，则继承客户端和服务器之间协商的、用于所述 报告先前内容的传输质量的至少一个度量。
全文摘要
本发明涉及在根据一个或多个度量来报告传输会话的质量的环境中的方法、计算机程序产品、客户端、服务器、系统和协议，特别涉及将质量报告应用于传输会话内的内容切换并且允许更快的会话启动。
文档编号H04L29/06GK101632286SQ200880008515
公开日2010年1月20日 申请日期2008年3月6日 优先权日2007年3月16日
发明者I·柯西奥, I·鲍阿齐齐, R·维丹萨姆 申请人:诺基亚公司