嵌入的服务质量相关信息的传送

摘要

本发明涉及传送服务质量相关信息的方法，所述信息将以第一装置(30)与第二装置(20)之间的至少一个方向传送。第一方法包括至少在装置(20，30)之一组装包含与服务质量相关信息不同的信息的协议消息以及把服务质量相关信息附加到协议消息中。第二方法包括在协议消息的首标字段和属性其中至少一个内形成服务质量相关信息。本发明同样涉及相应的软件代码、装置(20，30)、网络单元以及系统。

权利要求

1.一种传送服务质量相关信息的方法，所述信息将以第一装置与第二装置之间的至少一个方向传送，所述方法包括至少在所述装置之一：组装包含与所述服务质量相关信息不同的信息的协议消息；

把所述服务质量相关信息附加到所述协议消息，其中所述服务质量相关信息包括表明所述第一装置为了向所述第二装置报告所取得服务质量所采用的频度的信息；以及把所述协议消息传送给所述第一装置和所述第二装置中相应的另一个。

2.如权利要求1所述的方法，其特征在于，所述协议消息是实时流式协议消息、实时传输控制协议和会话发起协议消息其中之一。

3.如权利要求1所述的方法，其特征在于，对于特定服务在所述第一装置与所述第二装置之间形成会话时执行所述传送。

4.如权利要求1所述的方法，其特征在于，对于特定服务在所述第一装置与所述第二装置之间会话期间执行所述传送。

5.如权利要求1所述的方法，其特征在于，所述服务质量相关信息包括由所述第一装置向所述第二装置报告的关于所取得服务质量的信息。

6.如权利要求5所述的方法，其特征在于，所述关于所取得服务质量的信息包括关于与所取得服务质量关联的事件、测量和量度中至少一个的信息。

7.如权利要求5所述的方法，其特征在于，所述关于所取得服务质量的信息在所述服务的暂停状态期间未被传送。

8.如权利要求1所述的方法，其特征在于，所述服务质量相关信息包括用于在所述第一装置与所述第二装置之间协商所述第一装置向所述第二装置关于所取得服务质量报告的程度的信息。

9.如权利要求1所述的方法，其特征在于，所述服务质量相关信息被附加到所述协议消息的首标和所述协议消息的属性其中至少一个。

10.一种用于传送服务质量相关信息的装置，所述信息将以第一装置与第二装置之间的至少一个方向传送，所述装置包括：用于组装包含与所述服务质量相关信息不同的信息的协议消息的装置；

用于把所述服务质量相关信息附加到所述协议消息中的装置，其中所述服务质量相关信息包括表明所述第一装置为了向所述第二装置报告所取得服务质量所采用的频度的信息；以及用于把所述协议消息传送给所述第一装置和所述第二装置中相应的另一个的装置。

11.一种装置，包括：

组装组件，用于组装包含与服务质量相关信息不同的信息的协议消息，以及用于把服务质量相关信息附加到所述消息中，所述服务质量信息将被传送给第二装置，其中所述服务质量相关信息包括表明所述装置和所述第二装置中的一个为了向所述装置和所述第二装置中相应的另一个报告所取得服务质量所采用的频度的信息；以及传送组件，用于把所述组装组件所组装的协议消息传送给所述另一个装置。

12.如权利要求11所述的装置，其中所述协议消息是实时流式协议消息、实时传输控制协议和会话发起协议消息其中之一。

13.如权利要求11所述的装置，其中所述传送组件被配置用于：对于特定服务在所述第一装置与所述第二装置之间形成会话时，将所述组装组件所组装的协议消息传送给所述另一个装置。

14.如权利要求11所述的装置，其中所述传送组件被配置用于：对于特定服务在所述第一装置与所述第二装置之间的会话期间，将所述组装组件所组装的协议消息传送给所述另一个装置。

15.如权利要求11所述的装置，其中所述组装组件被配置用于：将关于所取得服务质量的信息附加至所述组装的协议消息以作为所述服务质量相关信息，其中所述关于所取得服务质量的信息由所述第一装置报告给所述第二装置。

16.如权利要求15所述的装置，其中所述关于所取得服务质量的信息包括关于与所取得服务质量关联的事件、测量和量度中至少一个的信息。

17.如权利要求15所述的装置，进一步包括传送组件，用于将所述组装组件所组装的协议消息传送至所述另一个装置，其中所述传送组件被配置用于在所述服务的暂停状态期间之外，传送所述关于所取得服务质量的信息。

18.如权利要求11所述的装置，其中所述组装组件被配置用于：将用于在所述第一装置与所述第二装置之间协商所述第一装置向所述第二装置关于所取得服务质量报告的程度的信息附加至所述组装的协议消息，以作为所述服务质量相关信息。

19.如权利要求11所述的装置，其中所述组装组件被配置用于：将所述服务质量相关信息附加到所述协议消息的首标和所述协议消息的属性其中至少一个。

20.如权利要求11所述的装置，其中所述装置是移动电话。

21.一种网络的网络单元，包括：

组装组件，用于组装包含与服务质量相关信息不同的信息的协议消息，以及用于把服务质量相关信息附加到所述消息中，所述服务质量信息将被传送给访问所述网络的装置，其中所述服务质量相关信息包括表明所述装置为了向所述网络单元报告所取得服务质量所采用的频度的信息；以及传送组件，用于把所述组装组件所组装的协议消息传送给所述装置。

22.一种包括至少第一装置和第二装置的系统，

所述第一装置包括组装组件，用于组装包含与服务质量相关信息不同的信息的协议消息，以及用于把服务质量相关信息附加到所述消息中，所述服务质量信息将被传送给所述第二装置；

所述第一装置包括传送组件，用于把所述组装组件所组装的协议消息传送给所述第二装置；

所述第二装置包括接收单元，用于接收所述第一装置所传送的协议消息，其中所述服务质量相关信息包括表明所述第一装置和所述第二装置中的一个为了向所述第一装置和所述第二装置中相应的另一个报告所取得服务质量所采用的频度的信息；以及所述第二装置包括分离组件，用于从所接收的协议消息中分离服务质量相关信息。

23.一种传送服务质量相关信息的方法，所述信息将以第一装置与第二装置之间的至少一个方向传送，所述方法包括至少在所述装置之一：在协议消息的首标字段和属性其中至少一个内形成所述服务质量相关信息，其中所述服务质量相关信息包括表明所述第一装置为了向所述第二装置报告所取得服务质量所采用的频度的信息；以及把所述协议消息传送给所述第一装置和所述第二装置中相应的另一个。

24.如权利要23所述的方法，其特征在于，所述协议消息是实时流式协议消息、实时传输控制协议、会话发起协议消息和会话描述协议描述其中之一。

25.如权利要求23所述的方法，其特征在于，所述服务质量相关信息包括关于与所取得服务质量关联的事件、测量和量度其中至少一个的信息。

26.如权利要求23所述的方法，其特征在于，所述服务质量相关信息包括用于在所述第一装置与所述第二装置之间协商所述第一装置向所述第二装置关于所取得服务质量报告的程度的信息。

27.一种用于传送服务质量相关信息的装置，所述信息将以第一装置与第二装置之间的至少一个方向传送，所述装置包括：用于在协议消息的首标字段和属性其中至少一个内形成所述服务质量相关信息的装置，其中所述服务质量相关信息包括表明所述第一装置为了向所述第二装置报告所取得服务质量所采用的频度的信息；以及用于把所述协议消息传送给所述第一装置和所述第二装置中相应的另一个的装置。

28.一种装置，包括：

组装组件，用于在协议消息的首标字段和属性其中至少一个内形成服务质量相关信息，所述服务质量信息将被传送给第二装置，其中所述服务质量相关信息包括表明所述装置和所述第二装置中的一个为了向所述装置和所述第二装置中相应的另一个报告所取得服务质量所采用的频度的信息；以及传送组件，用于把所述组装组件所提供的协议消息传送给所述另一个装置。

29.一种网络的网络单元，包括：

组装组件，用于在协议消息的首标字段和属性其中至少一个内形成服务质量相关信息，所述服务质量信息将被传送给访问所述网络的装置，其中所述服务质量相关信息包括表明所述装置为了向所述网络单元报告所取得服务质量所采用的频度的信息；以及传送组件，用于把所述组装组件所提供的协议消息传送给所述装置。

30.一种包括至少第一装置和第二装置的系统，

所述第一装置包括组装组件，用于在协议消息的首标字段和属性其中至少一个内形成服务质量相关信息，所述服务质量信息将被传送给所述第二装置，其中所述服务质量相关信息包括表明所述第一装置和所述第二装置中的一个为了向所述第一装置和所述第二装置中相应的另一个报告所取得服务质量所采用的频度的信息；以及所述第一装置包括传送组件，用于把所述组装组件所提供的协议消息传送给所述第二装置；

所述第二装置包括接收单元，用于接收所述第一装置所传送的协议消息；以及所述第二装置包括分离组件，用于从所接收的协议消息中提取服务质量相关信息。

说明书

嵌入的服务质量相关信息的传送

发明领域

[0001] 本发明涉及传送与服务质量相关的信息的方法，该信息要沿第一装置与第二装置之间的至少一个方向传送。本发明同样涉及相应的装置、相应的网络单元以及相应的系统。

[0002] 发明背景

[0003] 各种服务中，可能必须为之传送与其服务质量相关的信息的一种服务是流式类服务。

[0004] 对于流式类服务，流式服务器经由网络向流式客户机发送媒体数据，使得媒体数据可在客户机侧作为稳定连续流被处理。流式应用的一个实例是因特网视频产品。流式服务器也可驻留在网络中。

[0005] 网络的运营商或服务提供商对于能够评估流式客户机的用户感觉的服务质量(QoS)感兴趣。目前，采用3GPP TS26.234中标准化的协议来定义的流式会话提供了解关于所感觉的终端用户质量的有限数量的信息的可能性。实时传输控制协议(RTCP)接收方报告由客户机传送给服务器，用于报告关于网络性能的信息，例如与丢包、延迟抖动、所接收的累积最高序号有关的信息以及关于实时传输协议(RTP)包的其它信息。另外，RTCP发送方报告由服务器传送给客户机，其中包含关于发送方的信息。

[0006] 但是，这些报告无法使流式服务器或运营商通过流式服务器从流式客户机获得关于所感觉的QoS的任何附加信息，例如关于受损视频帧的数量、重新缓冲的持续时间、音频间隙的持续时间等的信息。这种信息可能仅通过扩展实时传输控制协议(RTCP)报告、RTCP扩展报告或RTCP XR包所携带的当前信息从流式客户机传递给流式服务器。这种扩展包括一组QoS量度，其中包含与会话建立和断开、语音和音频间隙、受损视频帧、重新缓冲及初始缓冲、连续丢包有关的信息以及与会话和媒体传输有关的可能其它信息。

[0007] 例如，IETF RFC2328(RTSP规范，1998年4月)、IETF RFC3550(RTP规范，2003年7月)和草案RTP控制协议扩展报告(RTCPXR，2003年5月)使流式客户机能够报告关于所接收RTP包的信息，其中包括丢包部分、延迟抖动、所接收的最高序号以及丢包序列。

[0008] 两个文档草案Rel-6“PSS质量量度永久文档”(3GPP TSG-S4Meeting#27，2003年7月7-11日，Tdoc S4-030562)以及在“流质量量度-客户机量度”(3GPP TSG-S4 Meeting #26，2003年5月5-9日，Tdoc S4-030353)中描述了3GPP(第三代合作项目)中的QoS量度的附加一般问题。第一个文档描述什么信息应当采用语音、音频、视频、播放器和网络量度的25个不同参数来发送以及应当采用什么种类的协议。另外，第二个文档定义高级要求和技术考虑因素。这些文档定义一种方法，在其中，客户机计算信息并在被请求时将其发送给服务器。为了传输的目的，建议采用从服务器发送到客户机的实时流式协议(RTSP)GET_PARAMETER消息以及从客户机发送到服务器的RTSP SET_PARAMETER消息。

[0009] 在文档“流式质量量度-传输”(3GPP TSG-S4Meeting#28，2003年9月1-5日，Tdoc S4-030629)中更详细地定义了这些消息。建议RTSP SET_PARAMETER消息从服务器传送到客户机，用于触发QoS量度。客户机在同意发送QoS量度时可采用RTSP200OK消息进行响应。服务器则可采用另一个SET_PARAMETER消息来发送QoS量度会话的描述，包括量度会话描述METRICS-SETUP，其中包含范围、周期和发送方参数。另外，这个消息还必须由客户机以RTSP200OK消息来接受。或者，服务器可要求客户机以GET_RAPAMETER消息来提供QoS量度会话的描述。一旦QoS量度会话被描述和商定，客户机可采用SET_PARAMETER消息来发送QoS量度，或者服务器可采用GET_PARAMETER消息来检索QoS量度。

[0010] 这种方法的一个缺点是，三对所需消息导致延迟，它可能减缓会话建立。所提出的方法甚至可能混淆建立，因为客户机可能在接收第二SET_PARAMETER消息之前已经在发送第一消息以便从服务器获取数据。

发明内容

[0011] 本发明的一个目的是改进为装置提供服务质量相关信息，例如为流式服务器提供与所感觉的最终用户流式类服务质量有关的信息。

[0012] 本发明的另一个目的是加速两个装置之间的会话的建立以及避免建立的混淆。

[0013] 根据本发明的第一方面，提出传送与服务质量相关的信息的方法，该信息将以第一装置与第二装置之间的至少一个方向传送。所提出的方法包括至少在装置之一中组装包含与有关服务质量的信息不同的信息的协议消息以及把服务质量相关信息附加到协议消息。所提出的方法还包括把协议消息传送给第一装置和第二装置中相应的另一个。

[0014] 根据本发明的第一方面，此外还提出用于传送与服务质量相关的信息的软件代码。信息将以第一装置与第二装置之间的至少一个方向传送。至少在装置之一的处理组件中运行时，软件代码组装包含与有关服务质量的信息不同的信息的协议消息，以及把有关服务质量的信息附加到协议消息。

[0015] 根据本发明的第一方面，另外还提出一种装置，它包括组装组件，用于组装包含与有关服务质量的信息不同的信息的协议消息，以及用于把有关服务质量的信息附加到消息中，该服务质量信息将被传送给另一个装置。所提出的装置还包括传送组件，用于把组装组件所组装的协议消息传送给另一个装置。同样，提出网络的网络单元，它包括用于把服务质量信息传送给访问这个网络的装置的相应特征。

[0016] 此外，根据本发明的第一方面，提出一种系统，它包括至少两个装置。第一装置对应于以上提出的装置。第二装置包括：接收单元，用于接收第一装置所传送的协议消息；以及分离组件，用于从所接收的协议消息中分离服务质量相关信息。

[0017] 本发明的第一方面基于以下考虑：与QoS相关的信息的至少一部分可附加到反正在两个装置之间传送的协议消息中。

[0018] 因此，消息的数量被减少，因为避免了QoS相关信息的专用消息对。

[0019] 因此，与采用专用消息来传送QoS相关信息的已知方法相比，本发明的一个优点是，它要求较少的信令开销，数据交换被加速，它实现更快的会话建立，以及它使得能够容易地交换更大量QoS相关信息。这种更大量QoS相关信息可用于例如协商要考虑的QoS数据、用于把所考虑的QoS数据传送一次以上、用于在正进行的会话期间改变要考虑的QoS数据或者用于在会话期间停止QoS数据的传送。如果QoS相关信息包含在建立消息中，则还可避免建立过程中的混淆。大家理解，组装协议消息以及把QoS相关信息附加到这个消息可能但不一定在分开的相继步骤中实现。附加也可构成协议消息的组装的一部分。QoS相关信息还可附加在协议消息的任何位置、例如在协议消息的首标字段中，或者作为属性附加到协议消息的主体。

[0020] 根据本发明的第二方面，提出传送与服务质量相关的信息的另一种方法，该信息将以第一装置与第二装置之间的至少一个方向传送。所提出的另一种方法包括至少在装置之一中在协议消息的首标字段或者属性内形成与服务质量相关的信息以及把协议消息传送给第一装置和第二装置中相应的另一个。

[0021] 根据本发明的第二方面，此外还提出用于传送与服务质量相关的信息的软件代码。信息将以第一装置与第二装置之间的至少一个方向传送。至少在装置之一的处理组件中运行时，软件代码在协议消息的首标字段和属性其中至少一个内形成与服务质量相关的信息。

[0022] 根据本发明的第二方面，另外还提出一种装置，它包括：组装组件，用于在协议消息的首标字段和属性其中至少一个内形成与服务质量相关的信息，该服务质量信息将被传送给另一个装置；以及传送组件，用于把组装组件提供的协议消息传送给这另一个装置。同样，提出网络的网络单元，它包括用于把服务质量信息传送给访问这个网络的装置的相应特征。

[0023] 此外，根据本发明的第二方面，提出一种系统，它包括至少两个装置。第一装置对应于为本发明的第二方面提出的装置。第二装置包括：接收单元，用于接收第一装置所传送的协议消息；以及分离组件，用于从所接收的协议消息中提取服务质量相关信息。

[0024] 本发明的第二方面基于以下认识：采用协议消息的首标或属性来传送QoS相关信息是特别有利的，因为在这种情况中，单个控制模块可用来分析协议消息以及提取信息、包括QoS相关信息，然后向系统中的必要模块提供所提取的信息。

[0025] 因此，本发明的第二方面例如可基于新定义的RTSP首标字段，它将用于在流式类会话建立期间或者在流式类数据传送期间传送QoS相关信息。

[0026] 对于采用新RTSP首标或属性的替代方案是采用新RTSP消息定义用于信令QoS量度，采用内容-长度字段以及在RTSP消息的末尾插入消息主体，或者定义与SET_PARAMETER和GET_PARAMETERRTSP消息配合使用的有关QoS量度的参数集。实现者可能选择不把RTSP首标字段用于QoS量度，以便将QoS量度信令与会话层信令完全分离。

[0027] 大家要理解，本发明的两个方面也可结合在单一实现中。

[0028] 在本发明的两个方面，协议消息具体但不排他地可能是RTSP消息、RTCP消息、会话发起协议(SIP)消息或者会话描述协议(SDP)描述。这个协议提供比RTCP传输更可靠的灵活传输，这是在所提出的方法中采用RTSP消息的一个特定优点。

[0029] 在本发明的两个方面，服务质量相关的服务例如但不排他地可能是流式类服务。特别是对于这种流式类服务可采用RTSP和RTCP。因此，所提出的装置可能是例如流式类服务的接收单元或传送单元，即流式客户机或流式服务器。本发明提供特别适合的方式来允许流式服务器找出流式客户机实际上如何接收数据以及具有与用户体验的质量(QoE-体验质量)有关以及与流式会话可能遇到的问题有关的更多信息。

[0030] 其它服务可能是例如基于IP的语音、视频电话或者单向传统视频。会议协议SIP具体可用于其它这类服务。

[0031] 协议消息的传送例如可在形成会话时和/或在相应服务的正进行的会话期间来执行。相应协议消息中的QoS相关信息可包括例如关于当前服务的所取得QoS的报告。这个报告具体可包括一个装置提供给另一个装置的参数和/或原始数据。原始数据可包括例如关于事件或测量数据的通知，而又称作量度的参数是已处理原始数据。此外，QoS相关信息可包括从第一装置到第二装置的请求，以便提供关于当前服务的所取得QoS的这种信息和/或定义关于将被提供的所取得QoS的信息的数据。这种数据也可组成装置之间关于将在相应报告中提供的所取得QoS有关的信息的程度和频度的协商的一部分。

[0032] 在一个有利的实施例中，例如对于流式类服务，QoS相关信息包含在会话描述协议(SDP)消息中或者在RTSP DESCRIPTION应答消息200OK、RTSP SETUP消息、RTSP PLAY消息、RTSP PAUSE消息或者RTSP TEARDOWN消息中的首标字段中。“QoS量度参数建立”消息最好是附加到对于RTSP DESCRIPTION消息的应答中的SDP消息。此外，“QoS量度参数变化”消息最好是附加到由客户机装置或者由客户机装置的用户发起的任何RTSP消息、如PAUSE中。还要注意，SDP无法在会话期间使用。

[0033] 为了定义QoS报告，例如对于流式类服务，应当定义一组最小要求。以下定义QoS报告的属性，它们适合使它们对于流式服务的有效性和能力为最大。应当理解，相应的属性对于其它类型的服务也是有利的。如果QoS报告可在流式传输开始时以及在正进行会话期间协商，则是有利的。如果QoS报告始终由流式服务器来请求，则也是有利的。如果存在把一组量度在单个消息中组合在一起的可能性，则也是有利的。服务器可通过单个消息来请求客户机报告单个原始数据项或单个参数或者多个原始数据项和/或参数。如果还有可能在会话或媒体层作为粒度属性协商报告，例如使通过空中接口发送的信息最小以及有选择地选择从哪个媒体以及报告什么内容，则也是有利的。如果存在打开/关闭报告的可能性，则也是有利的。如果存在定义报告频度的可能性，则也是有利的。

[0034] 报告频度可能是周期性的、事件驱动的或者在会话结束时。在周期性报告的情况中，周期由流式服务器来请求，并由流式客户机来商定。流式客户机采用商定的值来应答，商定的值可能没有服务器所请求的那些值那么理想。在事件驱动报告的情况中，“不良质量”事件由流式客户机报告。这使得从流式客户机传送到流式服务器的信息量最少。如果会话异常结束，则在会话结束时的报告可能产生问题。如果服务处于“暂停”状态，则客户机可能不发送QoS相关反馈数据，以免用空数据来浪费无线电资源。服务器应当能够处理这种中断。

[0035] QoS量度最好是在服务器上计算。也就是说，流式客户机报告一组事件和/或测量，服务器执行计算，例如确定指定时间窗口上的某些值的最小值、平均值和/或最大值。流式服务器可将实际统计计算推迟到会话结束或者推迟到低工作负荷的时刻。或者，量度可在客户机上计算。在这种情况下，客户机上的复杂度应当为最小。

[0036] 此外，还应当注意，不同的服务器以同样方式计算QoS量度，以便确保客观性。

[0037] 由于第3层和第4层(L3-L4)量度通过普通RTCP报告或RTCP XR报告可得到，因此，本发明特别适合于传送第5层(L5)量度和原始数据。客户机应当能够缓冲多个QoS报告，将它们在添加时间范围规定的单个报告中发送，以便使通过空中接口发送的消息数量最少。所发送信息的实例是会话ID、损坏之间的持续时间、时标等。

[0038] 通过以下结合附图的详细说明，本发明的其它目的和特征将变得非常明显。但是，应当理解，附图仅用于图解说明而不是作为对本发明的限制的定义，为此应当参照所附权利要求书。还应当理解，附图没有按比例绘制，它们仅用于从概念上描述本文所述的结构和过程。

[0039] 附图概述

[0040] 图1示意说明在其中可实现本发明的系统；

[0041] 图2是表格，提供可由图1的系统的客户机检测的事件和测量；

[0042] 图3是表格，提供可由图1的系统的客户机计算的量度的一个实例；

[0043] 图4是示意信令图，说明根据本发明的方法的一个实施例。

[0044] 发明详细说明

[0045] 图1示意表示在其中可采用本发明的系统10。

[0046] 系统10包括提供例如流式视频点播的流式服务器20。系统10还包括例如可在移动电话中实现的流式客户机30。流式客户机30经由网络40连接到流式服务器20，并且可要求并接收来自流式服务器20的视频流式应用。网络40可包括例如相互连接的、具有流式客户机30的移动电话可访问的公共陆地移动网(PLMN)以及流式服务器20可连接到其中的因特网。要理解，流式客户机30也可能是网络40的网络单元的组成部分。

[0047] 流式服务器20包括：组装组件21，用于组装RTSP消息，连接到发射机TX22；以及分离组件23，用于分离QoS数据，连接到接收机RX24。流式客户机30同样包括：组装组件31，用于组装RTSP消息，连接到发射机TX32；以及分离组件33，用于分离QoS数据，连接到接收机RX34。组件21、23、31和33具体可由软件、但同样也可由硬件来实现。

[0048] 使流式客户机30能够提供传送给流式服务器的三种类型的QoS相关值，即事件、测量和量度。事件被定义为流式客户机30中的事故或错误，它们引起异常以及与媒介的假定参考无错误实现的差异，并且可能包含例如语音间隙的持续时间。测量被定义为监测正常或异常条件中的流式会话的跟踪系统，并且可包括例如会话建立时间。量度是基于事件和测量的计算，并且可包括例如语音间隙的平均和/或最大持续时间。

[0049] 在图1的系统10中，实现一种方法，它可处理事件、测量和量度从流式客户机30到流式服务器20的传送。更具体来说，在流式客户机30与流式服务器20之间的任一方向上、其中也包括事件、测量和量度作为QoS相关定义和协商数据的所有QoS相关数据被附加到为了其它某种目的以任何方式组装的RTSP消息中，分别供组装组件21、31进行传送。补充RTSP消息则由相应传送单元20、30的发射机22、32经由网络40传送给相应接收单元30、20的接收机34、24。在相应的接收单元30、20中，QoS数据在用于分离QoS数据33、23的相应分离组件中从所接收的RTSP消息中分离供进一步使用。

[0050] 如果事件或测量由流式客户机30传送，则流式客户机仅检测事件和/或测量，并将它们报告给流式服务器20。然后，流式服务器20执行量度的计算。如果量度由流式客户机30来确定及传送，则流式服务器20接收预先计算的量度。如果流式客户机30计算量度，则在移动电话上要求更大的处理能力，以及必需传送的数据更多，因为可能要从一个事件或测量中计算若干量度。

[0051] 可由流式客户机30检测的事件和测量的实例在图2的表中提供，而可由流式客户机30或者由流式服务器20来计算的量度的实例则在图3的表中提供。要理解，系统10中采用的事件、测量和量度的列表可能与所提供的不同。

[0052] 此外，还提供定义包括事件、测量和/或量度的反馈消息从流式客户机30到流式服务器20的传送的频度的四种方式。

[0053] 在第一个周期性备选方案中，反馈消息在会话期间根据某个时间表来发送。这提供了根据需要调整所传送媒体流的QoS的服务器动作的可能性。根据所定义的频度，如果报告的周期过短，这可能在上行链路方向产生某种额外业务量。在第二个基于事件的备选方案中，反馈消息根据客户机30中的事件的出现被发送。这种方法也提供让服务器20根据需要在会话期间采取动作的可能性。如果事件率很高，则在上行链路方向上可能产生过多额外业务量，除非许多事件被附加到同一个消息中。在第三个备选方案中，反馈消息仅在会话结束时发送一次。这种方法非常节省带宽，但是报告的事件可能在会话结束时不再相干。在第四种备选方案中，具有先前会话的事件、测量或量度的反馈消息在下一个会话开始时被发送。这种方法的缺点是，根据用户使用服务的频度，报告的事件可能是几天前的并且不再相干。

[0054] 在图1的系统中，QoS相关数据的传送主要以两个阶段来实现，即流式会话的连接建立期间的协商阶段以及在正进行的流式会话期间的反馈阶段。下面参照图4来描述这两个阶段。图4是示意信令图，表示流式服务器20与流式客户机30之间的信令。另外，在正进行的流式会话期间启用重新协商阶段。

[0055] 在流式会话的RTSP连接建立中，流式客户机30和流式服务器20协商什么量度、测量和事件被发送以及发送的频度。对于协商，以下新的QoS-Metrics首标被定义，它与TSG-SA4 Meeting#28的上述文档中所定义的首标不同：

[0056] QoS-header=″QoS-Metrics″″:″″Off″/1#(stream-url

[0057] ″;″Metrics″;″Sending-rate[″;″Range])CRLF

[0058] stream-url=″url″″=″rtsp_URL

[0059] Metrics=″metrics″″=″″{″1#(1*TEXT)″}″

[0060] Sending-rate=″rate″″=″1*DIGIT/″End″

[0061] Range＝如RFC2327中所定义

[0062] DIGIT＝如RFC2326中所定义

[0063] Rtsp_URL＝如RFC2326中所定义

[0064] 这个首标可能是流式服务器20或者流式客户机30所传送的任何RTSP消息的一部分。

[0065] 有两种方式来使用所定义的QoS-Metrics。如果仅使用Off参数，则这是表示服务器20或者客户机30希望取消事件、测量和量度的传送。相反，如果首标包含其它参数、即stream-url、Metrics、Sending-rate以及可能的Range，则分别请求开始或重新开始量度传送。

[0066] stream-url字段是RTSP会话url或者RTSP媒体控制url标识符。如果首标与RTSP会话控制url信息共同使用，则QoS-Metrics在会话层使用。如果url是RTSP媒体控制url，则QoS-Metrics在媒体层使用，以及各媒体得到其自己的QoS-Metrics行。同一个url被引用一次以上是可能的。如果Sending-Rate和Range信息与先前定义的不同，则新的量度参数被看作不同的参数集，它对于那个特定url、但对于不同的量度是有效的。否则，同一个RTSP控制url不必为相同的Sending-Rate和Range值被引用一次以上。

[0067] Metrics字段用来限制要报告的量度、测量和事件的数量。它包含描述在会话中需要报告的量度、测量和事件的名称的列表。在会话中不使用没有包含在Metrics字段中的名称。

[0068] Sending-rate字段用来设置发送速率。如果Sending-rate值为0，则客户机30可根据客户机30中出现的事件在任何时间发送反馈消息。大于1的值表明单位为秒的精确消息发送间隔。最短的间隔是一秒一次，而最长的间隔未定义。反馈发送间隔对于不同的媒体可能不同，但是，建议保持一种同步以避免额外业务量。值End表明仅在会话结束时发送一个反馈消息。

[0069] Range字段可用来定义反馈发送的时间限制。这与参数Off的发送相似，但它允许事先决定协商阶段中的On状态的时间范围。

[0070] 所定义的QoS-Metrics字段可处理其中量度计算在流式服务器20中执行并且流式客户机30仅向服务器发送事件和/或测量的情况，以及同样可处理其中流式客户机30向流式服务器20发送预先计算的量度的情况。

[0071] 另外，还定义新的Qos-Metrics SDP属性，它可用作会话或者用作媒体层SDP属性。定义语法基于RFC2327，通过引用将其结合于本文中：

[0072] a=QoS-Metrics:Metrics″;″Sending-rate[″;″Range])

[0073] CRLF

[0074] Metrics=″metrics″″=″″{″1#(1*TEXT)″}″

[0075] Sending-rate=″rate″″=″1*DIGIT/″End″

[0076] Range＝如RFC2327中所定义

[0077] DIGIT＝如RFC2327中所定义

[0078] 为了开通流式会话，流式客户机30向流式服务器20传送RTSPDESCRIBE请求作为图4的消息1：

[0079] C->S DESCRIBE rtsp://example.com/foo/bar/baz.3gp RTSP/1.0[0080] Cseq:1

[0081] 表示C->S表明从客户机30到服务器20的传送。

[0082] QoS-Metrics字段的实际协商则可采用第一DESCRIBE响应来开始，如下面所述。

[0083] 已经从客户机30接收到DESCRIBE请求1之后，服务器20采用QoS-Metrics SDP属性在SDP描述中列出预期QoS量度信息。这些量度可在SDP中在会话层或者在媒体层定义。这为QoS过程提供了灵活性，使得重要媒体组件可更详细地被监测。流式服务器20把SDP描述附加到DESCRIBE响应200OK，并把响应作为图4的消息2传送给流式客户机30。服务器采用QoS-Metrics首标而不是采用SDP属性在DESCRIBE响应消息中列出QoS量度也是可能的。流式客机30应当检查响应中的这种首标是否存在。

[0084] 必须注意，在TSG-S4Meeting#28的上述文档中，到这时已经需要四个专用QoS消息。

[0085] 下面提供相应会话层消息的一个实例，在其中，所请求会话参数为RTSPSetupTime和InitialBufferingTime，其中所请求的视频参数为Framegap_max和Framegap_ave，以及所请求的音频参数为AudioGap_ave和AudioGap_max。要注意，参数的名称只是示例，以及相应的名称可表示量度、测量和/或事件。

[0086] S->C RTSP/1.0200OK

[0087] Cseq:1

[0088] Content-Type:application/sdp

[0089] Content-Base:rtsp://example.com/foo/bar/baz.3gp/

[0090] Content-Length:800

[0091] Server:Nokia RTSP Server

[0092] v=0

[0093] o=-3268077682433392265IN IP463.108.142.6

[0094] s=QoS Enables Session Description Example

[0095] e=[e-mail]

[0096] c=IN IP40.0.0.0

[0097] t=00

[0098] a=range:npt=0-83.660000

[0099] a=QoS-Metrics:{RTSPSetupTime，InitialBufferingTime};rate＝End[0100] a=control:＊

[0101] m=video0RTP/AVP96

[0102] b=AS:28

[0103] a=QoS-Metrics:{Framegap_max，

[0104] Framegap_ave};rate=15;range:npt=0-40

[0105] a=control:trackID=3

[0106] a=rtpmap:96MP4V-ES/1000

[0107] a=range:npt=0-83.666000

[0108] a=fmtp:96profile-level-

[0109] id=8;config=000001b008000001b5090000010000000120008440fa28[0110] 302090a28f

[0111] m=audio0RTP/AVP98

[0112] b=AS:13

[0113] a=QoS-Metrics:{AudioGap_ave，AudioGap_max};rate=20[0114] a=control:trackID=5

[0115] a=rtpmap:98AMR/8000

[0116] a=range:npt=0-83.660000

[0117] a=fmtp:98 octet-allgn=1

[0118] a=maxptime:200

[0119] 表示S->C表明从服务器20到客户机30的传送。

[0120] 如果一方想启用QoS量度信令，则QoS协商可在会话期间的任何阶段执行。在这里列出的实例中，采用SDP属性在会话建立阶段进行。根据本发明，还能够采用QoS-Metrics SDP属性或者QoS-Metrics首标字段在其它任何RTSP消息中发送QoS量度。

[0121] 流式客户机30选择所接收的200OK消息的SDP属性中列出的可接受的QoS量度，或者在第一SETUP请求中建议新的值。如果客户机30支持QoS量度，则它必须发送SETUP请求或者包含被建立的会话层或媒体层的所选/修改QoS Metrics的其它某个RTSP消息。这种SETUP请求消息在图4中表示为消息3。备选RTSP消息例如是PLAY请求，在图4中表示为消息5。相应的示范SETUP消息表示如下：

[0122] C->S SETUP rtsp://example.com/foo/bar/baz.3gp/trackID=3RTSP/1.0[0123] Cseq:2

[0124] QoS-Metrics:url=”rtsp://example.com/foo/bar/baz.3gp/track ID=3”；

[0125] metrics={Framegap_max，Framegap_ave};rate=10;range:npt=0-40，[0126] url=”rtsp://example.com/foo/bar/baz.3gp”;

[0127] metrics={RTSPSetupTime，InitialBufferingTime};rate=End[0128] 在上面的SETUP请求实例中，流式客户机30修改控制URL的QoS量度的发送速率[0129] ″rtsp://example.com/foo/bar/baz.3gp/trackID＝3″从15到10。

[0130] 为了表明支持会话层以及媒体层QoS Metrics，流式客户机30必须发送与媒体层相关的所有支持和/或修改的QoS Metrics。它还必须在SETUP请求的至少一个中发送所选的会话层Qos Metrics。

[0131] 流式服务器20接收这个SETUP请求，并返回附加了由客户机30传送的已接受QoS Metrics的200OK消息，来重新确认这些变化。这种200OK消息在图4中表示为消息4。流式服务器20也可在200OK消息中拒绝流式客户机30进行的变更。为了拒绝这些变更，流式服务器20可设置新的值并且把附加到200 OK消息的已修改量度重新送回流式客户机30，或者它可能只是忽略那个量度并且不对它们进行重新确认。

[0132] 假定流式服务器20确认了这些变更，则它可发回以下示范SETUP响应：

[0133] S->C RTSP/1.0200OK

[0134] Cseq:2

[0135] Session:17903320

[0136] Transport:RTP/AVP;unicast;client_port=7000-

[0137] 7001;server_port=6970-6971

[0138] QoS-Metrics:url=”rtsp://example.com/foo/bar/baz.3gp/trackID=3”;

[0139] metrics={Framegap_max，Framegap_ave};rate=10;range:npt=0-40，[0140] url=”rtsp://example.com/foo/bar/baz.3gp”；

[0141] metrics={RTSPSetupTime，InitialBufferingTime};rate=End[0142] 当流式客户机30接收响应其SETUP请求3的这个200OK消息4时，它了解流式服务器20支持QoS Metrics。此外，客户机30了解服务器20接受而支持QoS-Metrics RTSP首标中列出的量度。

[0143] 对于会话中的其它媒体组件执行同样的信令。在这种情况下，可能不重复会话层QoS Metrics协商。

[0144] 如果流式服务器20不同意流式客户机30进行的修改，则服务器20和客户机30可继续重新协商，直到由客户机30进行RTSP PLAY请求为止，在图4中表示为消息5。在图4中表示为消息6的服务器20的后续RTSP PLAY响应则返回包含所有会话和媒体层QoS_Metrics值的最终协商的QoS-Metrics。

[0145] 必须注意，每次QoS-Metrics首标字段在RTSP请求中被发送时，它还必须在对应于那个特定请求的响应中提供。否则，响应的接收机20、30假定相应的另一端30、20不支持QoS Metrics。

[0146] 还必须注意，流式客户机30在开始会话之前可能已经拥有SDP描述，例如以文件的形式。如果通过不同于来自特定服务器20的DESCRIBE响应的方式来检索SDP描述，则流式服务器所接收的第一消息为图4的SETUP消息3。因此，图4中与DESCRIBE请求消息1和DESCRIBE响应消息2关联的箭头仅以虚线表示。流式客户机30在这种情况中可传送初始QoS Metrics信息，用于SETUP消息3中的协商。如果SETUP消息3包含QoS Metrics信息，则流式服务器20可接受量度或者在SETUP响应4中建议新的量度，以及QoSMetrics协商可在下一个RTSP消息中继续进行，如上所述。如果第一SETUP消息3不包含QoS Metrics信息，并且流式服务器20希望与流式客户机30协商QoS量度，则流式服务器20可通过使用SETUP响应4来请求从流式客户机30报告QoS量度信息。如果流式客户机30接受所请求的QoS Metrics或者希望对它们进行变更，则流式客户机30必须在下一个RTSP消息中包含量度信息。如果在下一个RTSP消息中没有QoS Metrics信息，则这表明流式客户机30不支持QoSMetrics。

[0147] 在协商已经完成之后，流式客户机30可开始发送反馈消息。

[0148] 反馈消息也应当采用可靠的传输机制来发送。为此，能够采用流式会话过程中使用的任何RTSP请求-响应对。例如，如果RTSPPAUSE消息在会话期间无论如何都发送，则反馈消息可包含在这个PAUSE消息中。如果反馈消息只在会话结束时发送，则可能采用RTSP TEARDOWN消息来避免不必要的业务量。这种TEARDOWN消息无论如何用来发送真正的最后一个反馈消息，同样在周期性反馈报告的情况中。

[0149] 对于反馈，还定义新的首标。下列首标可处理与事件、测量或量度相关的发送方法。定义语法基于RFC2326，同样通过引用将其结合于本文中：

[0150] Feedbackheader=″QoS-Feedback″″:″1#(stream-url

[0151] 1*(parameters) CRLF)

[0152] stream-url=″url″″=″rtsp_URL

[0153] parameters=″；″Metrics″=″″{″SP/1#(Value[SP

[0154] Timestamp])″}″

[0155] Metrics=*TEXT

[0156] Value=1*DIGIT[″.″*DIGIT]

[0157] Timestamp=1*DIGIT

[0158] DIGIT=如RFC2326中所定义

[0159] Rtsp_URL=如RFC2326中所定义

[0160] SP＝如RFC2326中所定义

[0161] Stream-url是RTSP会话url或者反馈参数的媒体控制url标识符。参数定义中的Metrics字段包含量度、测量或事件的名称，并且它必须与协商字段QoS-Metrics中的Metrics字段相同。建议使量度的顺序保持不变，以便简化剖析。Value字段表示Metrics的结果。可选Timestamp字段表示事件或测量出现的时间或者量度被计算的时间。通过包含空格(SP)，首标还允许报告零事件。

[0162] 如果事件和测量用于量度发送中，则存在在发送周期中同一事件出现不止一次的可能性。在那种情况中，Metrics类型、即事件或测量的名称可能出现不止一次，这向服务器表明事件的数量。

[0163] 如果反馈消息的协议将为RTCP而不是RTSP，则可能采用RTCPAPP包(应用定义RTCP包，包类型204)或者RTCP RR(接收机报告，包类型201)包的扩充。无论所使用的包是什么，都应当包含至少一个Metrics字段、Value字段以及可选的Timestamp字段。Metrics是量度的名称或者空消息的指示(ASCII或数值)。Value是量度的结果(数值)。Timestamp是事件出现的时间或者量度被计算的时间(数值)，并且仅可选地提供。RTCP首标包含关于特定媒体的信息，因此不需要采用额外字段来重复那种信息。

[0164] 在反馈消息中，QoS-Feedback首标仅包含已更新的QoS-Metrics量度。如果没有列出量度参数，但在建立阶段进行协商，则那个量度参数被假定为未改变/未更新。流式客户机30在PLAY请求之后可在任何RTSP消息中采用以下消息。这种消息在图4中表示为消息7。要注意，参数的名称只是实例。

[0165] OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

[0166] Cseq:302

[0167] Session:17903320

[0168] QoS-Feedback:

[0169] url=“rtsp://example.com/foo/bar/baz.3gp/trackID=3”;Framega

[0170] p_max=1006000;Framegap_ave=506000

[0171] url=“rtsp://example.com/foo/bar/baz.3gp/trackID=5”;

[0172] AudioGap_ave=340.552;AudioGap_max=0500

[0173] 还可能连接RTSP反馈消息，以便避免例如因基于事件的发送产生的过高消息发送速率。

[0174] 作为RTSP反馈消息的替代，流式客户机30可采用例如以下RTCP RR消息用于报告QoS数据：

[0175] RTCP首标

[0176] 报告块

[0177] 简档特定扩充

[0178] AudioGap_ave 105.56000

[0179] AudioGap_max 123 500

[0180] 另外的备选方案是，客户机可采用例如以下RTCP APP消息：

[0181] RTCP APP首标

[0182] 名称

[0183] QoS_Metrics

[0184] 应用相关数据

[0185] Audiogap_ave 105.5 6000

[0186] Audiogap_max 123 500

[0187] 如果测量或事件而不是所计算的量度被报告，则事件描述可包括不止一个值。例如，如果在报告周期中存在丢失RTP包的两个独立事件，则这可能是受关注的。

[0188] 用于RTSP消息中的以下实例另外还包括可选Timestamp信息：OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

[0189] Cseq:302

[0190] Session:17903320

[0191] QoS-Feedback:

[0192] url=“rtsp://example.com/foo/bar/baz.3gp/trackID=3”;Vcorruption_dur

[0193] ={1006000，215.411000};Lost_RTP={36000，511000}

[0194] url=“rtsp://example.com/foo/bar/baz.3gp/trackID=5”；

[0195] Acorruption_dur={976000，22111000}

[0196] 用于RTCP RR消息中的以下实例也包括可选Timestamp信息：

[0197] RTCP首标

[0198] 报告块

[0199] 简档特定扩充

[0200] Acorruption_dur 97 6000

[0201] Acorruption_dur 221 11000

[0202] 用于RTCP APP消息中的以下实例也包括可选Timestamp信息：

[0203] RTCP APP首标

[0204] 名称

[0205] QoS_Metrics

[0206] 应用相关数据

[0207] Acorruption_dur 97 6000

[0208] Acorruption_dur 221 11000

[0209] 流式服务器20或者客户机30希望在会话期间改变所协商参数是可能的。服务器20例如可能更频繁想要某种信息，而客户机30则可能注意到它无法提供商定数量的参数。
还可能切断整个QoS量度发送。为了以后再次开始，流式客户机30或者流式服务器20可发送新的请求。在正进行的流式会话期间，能够采用任何RTSP消息用于重新协商QoS量度参数。最初协商的报告的任何变更也归入图4的消息7。

[0210] 下面是由客户机30或服务器20在会话期间进行变更请求、或者由客户机30或服务器20在已经把QoS Metrics设置为关断之后在会话期间进行的重新开始请求的一个实例：

[0211] C->S，S->C OPTIONS rtsp://example.com/foo/bar/baz.3gp/trackID=5[0212] RTSP/1.0

[0213] Cseq:302

[0214] Session:17903320

[0215] QoS-Metrics:metrics=AudioGap_ave，AudioGap_num，[0216] AudioGap_max;rate=20

[0217] 表明请求的接受的对变更请求的响应对于两个方向例如定义如下：

[0218] S->C，C->S RTSP/1.0200OK

[0219] Cseq:302

[0220] Session:17903320

[0221] QoS-Metrics:metrics=AudioGap_ave，AudioGap_num，[0222] AudioGap_max;rate=20

[0223] 表明请求的拒绝的对变更请求的响应对于两个方向例如定义如下：

[0224] S->C，C->S RTSP/1.0200OK

[0225] Cseq:302

[0226] Session:17903320

[0227] QoS-Metrics:metrics=AudioGap_ave，AudioGap_max;rate=20[0228] 如果新的值未被接受，则先前使用的参数被重复，表明先前协商的情况保持不变。量度的列表始终是绝对的。没有任何方法对当前列表进行添加或减少，而是量度的新列表取代旧列表。

[0229] 下面是由客户机30或服务器20在会话期间用于把量度设置为关断的消息的一个实例：

[0230] C->S，S->C OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0[0231] Cseq:302

[0232] Session:17903320

[0233] QoS-Metrics:Off

[0234] 必须注意，量度可在会话层或在媒体层设置为关断。url表示使用什么层。在上面的实例中，量度在会话层对于所有媒体被关断。

[0235] 如果把量度设置为关断的请求被接受，则响应对于两个方向例如定义如下：

[0236] S->C，C->S RTSP/1.0200OK

[0237] Cseq:302

[0238] Session:17903320

[0239] QoS-Metrics:Off

[0240] 如果把量度设置为关断的请求被拒绝，则响应对于两个方向例如定义如下：

[0241] S->C，C->S RTSP/1.0200OK

[0242] Cseq:302

[0243] Session:17903320

[0244] QoS-Metrics:metrics=AudioGap_ave，AudioGap_max;rate=20[0245] 也就是说，如果设置关断未被接受，则先前使用的参数被重复，表明先前协商的情况保持不变。能够根据需要重新协商发送参数。

[0246] 如果仅需要事件检测，则流式客户机30的实现更容易。

[0247] 所提供方法的一个优点是，可定期发送消息，以及消息被设计成尽可能小。

[0248] 所述方法允许传递比3GPP TSG-S4 Meeting#28的上述文档更多的信息。此外，所提供方法使建立更快，因为需要更少消息。所提出的方法的优点还在于，它允许协商所使用量度的每一个。此外，它提供根据需要在会话中间重新协商量度发送以及根据需要把整个量度发送设置为关断的可能性。

[0249] 所提供方法还提供量度的时标，它比其它解决方案中所使用的范围更准确地描述事件的时间。对于在周期性消息发送中没有事件要描述的情况定义空消息。还能够连接若干消息，以便优化消息发送。

[0250] 虽然将本发明应用于本发明的一个优选实施例来表示、描述并指出其新颖的基本特征，但应当理解，本领域的技术人员可对所述装置和方法的形式及细节进行各种省略、替换和变更，而没有背离本发明的精神。例如，很显然，以实质上相同的方式执行实质上相同的功能以获得同样结果的那些元件和/或方法步骤的所有组合均属于本发明的范围之内。另外，应当理解，结合本发明的任何公开形式或实施例所表示和/或所描述的结构和/或元件和/或方法步骤可作为设计选择的一般问题结合到其它任何公开或描述或建议的形式或实施例中。因此，意图是仅受所附权利要求的范围所指明的限制。