Ims业务实时媒体流的协商式调节方法
【专利摘要】本发明涉及一种IMS业务实时媒体流的协商式调节方法，包括以下步骤：在媒体流的发送方与接收方之间通过SIP/SDP建立初始业务连接；从接收方通过RR消息向发送方反馈当前的丢包率；在发送方监控当前的丢包率，当监测到丢包率跨越业务信道环境的阀值，并向同一方向减少或增加一个协商启动余量后，从发送方向接收方发送扩展的SR消息，以启动媒体流传输特征改变的带内协商过程。当发送方与接收方协商一致后，在发送方决定根据达成的参数调节当前实时媒体流的发送；在媒体流调节过程中，在发送方持续监测丢包率，当丢包率达到以业务信道环境上或下阀值标记的临界点时，停止媒体流调节。
【专利说明】IMS业务实时媒体流的协商式调节方法
【技术领域】
[0001]本发明涉及MS业务的媒体流传输，尤其是涉及一种MS业务实时媒体流的协商式调节方法。
【背景技术】
[0002]基于頂S(IP Multimedia Subsystem，IP 多媒体子系统，3gpp TS 23.228)架构的移动互联网应用中，具有实时媒体流业务特征的应用较为广泛，如视频共享(Videoshare)应用(GSMA IR.84)、视频(video)应用(GSMA IR.94)等。这些基于MS业务应用的一个主要特征是:信令流与业务流分开。具体地说，通过SIP/SDP (Session initiationProtocol, Session Description Protocol,会话发起协议，会话描述协议，3gpp Ts24.229)消息在单独的信令承载进行业务信令交互，而在另外独立的承载进行实时业务媒体流数据传输。业务数据流由信令控制，如一个应用业务中数据媒体流的增加、减少或编解码器等改变前，均需要通过独立于业务流承载的SIP/SIP信令进行协商，协商一致后才启动业务媒体流的上述变化。然而对于基于实时媒体流的业务，如果每次实时数据流变化前均需要建立独立信令承载以完成相应的SIP/SDP信令交互，会导致业务体验降低，这限制了上述协商方式在实时媒体流中的使用。
[0003]由于实时媒体流的传输一般都采用RTP/RTCP协议(Real time TransferProtocol/Real time Transfer Control Protocol,实时传输协议 / 实时传输控制协议，RFC 3550)。通过RTCP协议中的SR消息(Sender Report Control Packet,发送方报告控制包)及RR消息(Receiver Report Control Packet,接收方报告控制包),可以监测实时媒体流的丢包率情况以反映业务传输信道环境状况。基于这种监测，一些实时媒体流应用业务发送端会单方地进行符合信道环境变化的实时媒体流传送策略调节。与协商方式相比，这种调整是一种单向意愿的调节方式，可能不会得到对端的支持。如丢包率很低时，发送端采用更高视频编码格式的方式发送，但这种格式对端并不支持；又如进行具有实时音频流和实时视频流的应用业务时，由于信号覆盖或小区边界干扰等原因，丢包率过高，发送方拆除视频流而保留音频流，可对端用户却更愿意接收码率降低的视频流。
【发明内容】
[0004]本发明所要解决的技术问题是提供一种MS业务实时媒体流的协商式调节方法，它可以使用实时媒体流内部的控制消息来进行协商交互。
[0005]本发明为解决上述技术问题而采用的技术方案是提出一种MS业务实时媒体流的协商式调节方法，包括以下步骤:
[0006]a.在媒体流的发送方与接收方之间通过SIP/SDP建立初始业务连接；
[0007]b.从接收方通过RR消息向发送方反馈当前的丢包率；
[0008]c.在发送方监控当前的丢包率，当监测到丢包率跨越业务信道环境的阀值，并向同一方向减少或增加一个协商启动余量后，进入步骤d ;[0009]d.从发送方向接收方发送扩展的SR消息，以启动媒体流传输特征改变的带内协商过程；
[0010]e.从接收方返回扩展的RR消息对接收到的扩展的SR消息进行响应；
[0011]f.当发送方与接收方协商一致后，在发送方决定根据达成的参数调节当前实时媒体流的发送；
[0012]g.开始进行媒体流调节过程；以及
[0013]h.在媒体流调节过程中，在发送方持续监测丢包率，当丢包率达到以业务信道环境上或下阀值标记的临界点时，停止媒体流调节。
[0014]在本发明的一实施例中，在步骤f和g之间还包括:进行带内协商锁定，在该锁定期间，发送方不能发起扩展的SR或RR协商过程。
[0015]在本发明的一实施例中，在步骤h之后还包括:解锁带内协商，使发送方可发起扩展的SR或RR协商过程。
[0016]在本发明的一实施例中，在该步骤a中，SDP中包含对应该业务的业务信道环境的阀值和协商启动余量。
[0017]在本发明的一实施例中，在该步骤a中，SDP中包含用于对该业务媒体流发送速率进行调节的步长设定信息。
[0018]在本发明的一实施例中，上述方法还包括重复该步骤d及该步骤e，使该发送方与该接收方协商一致。
[0019]在本发明的一实施例中，该业务信道环境的阀值包括业务信道上阀值和业务信道下阀值，而将该业务信道环境区分为丢包率低于业务信道下阀值的理想信道环境区间、丢包率高于业务信道上阀值的恶化业务信道环境区间、以及正常业务信道环境区间。
[0020]在本发明的一实施例中，该扩展的SR消息和该扩展的RR消息分别包括配置文件特定扩展部分，以包含该媒体流传输特征的描述信息。
[0021]在本发明的一实施例中，该媒体流传输特征的描述信息包括以下的至少一部分:溢出标志部分、模式标志部分、调节方式标志部分、发送码率调节方式标志部分、媒体流标志部分、以及编码方式标志部分。
[0022]在本发明的一实施例中，该实时媒体流的传输是基于RTP/RTCP协议。
[0023]基于上述，本发明由于利用RTCP控制消息交互特点实现了带内协商控制，相比于需要多次重新独立建立承载的带外SIP/SDP信令控制方式，提高了用户体验。
【专利附图】
【附图说明】
[0024]为让本发明的上述目的、特征和优点能更明显易懂，以下结合附图对本发明的【具体实施方式】作详细说明，其中:
[0025]图1示出MS的业务信道环境区间。
[0026]图2示出根据本发明一实施例的扩展的SR\RR消息。
[0027]图3示出根据本发明一实施例的媒体流传输特征描述信息在SR/RR消息扩展部分的实现实例。
[0028]图4示出根据本发明一实施例的“带内”媒体流传输特征的基本协商流程的一个实例。【具体实施方式】
[0029]通常的MS应用中，要对正在进行的媒体流特征进行改变，需要多次重新建立独立于媒体流信道的信令承载，在媒体流发送方和接收方间进行媒体流特征变更协商，即在媒体流信道外进行多次“带外”信令信道的建立、拆除和基于此的SIP/SDP (Sessioninitiation Protocol/Session Description Protocol,会话发起协议 / 会话描述协议)双向协商。
[0030]为了避免多次重新建立独立于媒体流信道的信令承载，本发明的实施例提出一种基于实时媒体流的“带内”信道进行协商的机制。
[0031]通过对实时媒体流传输信道进行分析发现，对实时媒体流传输进行控制的各种RTCP (Real time Transfer Control Protocol,实时传输控制协议)协议消息,本身会周期性地交织在承载媒体流数据的RTP (Real time Transfer Protocol,实时传输协议)数据包中进行传输，是一种天然的“带内”消息传输机制。本发明的实施例通过挖掘RTCP消息传输的这种特性,在MS实时媒体流业务进行过程中，将对应于外部环境变化的实时媒体流特征的动态改变协商融入“带内”实现，以实现更好业务体验的实时媒体流传输自适应调节。
[0032]本发明下面的实施例将描述一种实时媒体流信道环境变化时，利用RTCP控制消息交互特点实现“带内”协商控制以对实时媒体流进行自适应调节的方法。在此，“带内”协商是指利用实时媒体流内部的交互机制进行的协商。与需要多次重新独立建立承载的“带外” SIP/SDP信令控制方式相比，本发明的实施例将SIP/SDP的双向协商模式引入RTCP协议，并基于此实现了基于丢包率监测的协商式自适应调节机制。
[0033]RR 消息(Receiv er Report RTCP Packet)和 SR 消息(Sender Report RTCPPacket)是RTCP协议中媒体流接收方向发送方汇报所监测丢包率及媒体流发送方向接受方发送重要参考信息(如NTP时钟等，Network Time Protocol)的两个消息。利用这两种消息的双向传输特性，可在“带内”建立起实时媒体流特征动态改变协商机制。
[0034]媒体流接收方本身可通过RR消息向发送方反馈所接收数据的当前丢包率。本发明的实施例中，需要设置保证頂S业务应用正常体验可接受的最大丢包率及可使业务体验加强的最小丢包率，将前者称为业务信道环境上阀值，将后者称为业务信道环境下阀值。图1示出MS的业务信道环境区间。参照图1所示，信道环境上阀值Qmax及信道环境下阀值Qmin将业务信道环境分为三个区间:丢包率低于业务信道环境下阀值的理想信道环境区间Zideal、丢包率大于业务信道上阀值的恶化业务信道环境区间Zbad、正常业务信道环境区间
7
^normal °
[0035]其中，业务信道环境上、下阀值0_、Qfflin的选取取决于特定MS业务的具体特征，正常情况下，业务信道初始建立时的丢包率处于正常业务信道环境区间znOTmal。本发明的实施例中，頂S业务的实时媒体流业务信道的初次建立是基于已有的“带外”SIP/SDP(3gpp Ts24.229)机制，但与已有机制区别的是需要在SDP描述中设定该业务的业务信道环境上、下阀值，即通过初始的“带外”信令协商过程，业务发送方、接收方获取反映该业务特征的两个业务信道环境阀值。
[0036]实时媒体流业务开始后，可能由于业务信道环境的变化，导致媒体流接收方向发送方通过RR消息反馈的当前丢包率发生波动。当丢包率波动至跨越业务信道环境上、下阀值标记的临界点并达到一定协商启动余量时，将触发“带内”媒体流传输特征的协商过程，通过协商结果改变媒体流传输特征，以更合理地适应业务信道环境变化，获取更合理的业务体验。协商启动余量是丢包率到达两个阀值临界点后在图1的丢包率时间轴上向同一个方向持续变化的余量，其设置用于防止丢包率在临界点周围波动时，频繁启动协商过程。该协商启动余量可根据具体运营业务特定选取，也需要在业务信道初次建立的“带外” SIP/SDP信令中设置。
[0037]“带内”媒体流传输特征的协商过程是通过对SR、RR消息进行扩展，在其消息体的扩展部分定义反映媒体流传输特征的描述信息，进而通过RTCP本身的SR、RR消息“带内”周期性双向交互机制实现协商。遵循RTCP消息扩展规则(RFC3550)，扩展部分可位于SR、RR消息体的配置文件特定扩展(Profile-Specific Extensions)中。图2示出根据本发明一实施例的扩展的SR\RR消息，图2中201为原有SR/RR消息固定部分，202为扩展的SR/RR消息。
[0038]在一实施例中，反映媒体流传输特征的描述信息至少包括下述方面:
[0039]I)溢出标志部分:
[0040]指示上溢出及下溢出两种协商触发情形，并能用不同标记对这两种触发情形进行区分。图1的丢包率轴线上，当前丢包率向右移动跨过业务信道环境上阀值或下阀值临界点，并继续向右增大达到了协商启动余量，称为上溢出；当前丢包率向左移动跨过业务信道环境上阀值或下阀值临界点，并继续向左降低达到了协商启动余量，称为下溢出。
[0041]2)模式标志部分:
[0042]指示进行的MS业务包括单个实时媒体流，还是包括多个实时媒体流。并用不同的标志区别指示这两种情况。
[0043]3)调节方式标志部分:
[0044]指示带当前媒体流的调节方式，包括改变媒体流发送码率进行调节、增\减业务媒体流进行调节，及包括这两种方式的混合调节方式，并能用不同的标志区别指示这几种方式。其中，增\减业务媒体流的调节方式只在模式标志部分指示为多个实时媒体流时有效。
[0045]4)发送码率调节方式标志部分:
[0046]指示媒体流发送码率的调节方式，包括通过发送速率调节码流及通过改变媒体流编码方式调节这两种方式，并能用不同的标志区别指示这几种方式。该部分只是在调节方式标志部分指示以改变媒体流发送码率进行调节时有效。其中，通过发送速率方式进行调节所依据的调节步长，即每次在当前发送速率上增加或减少的发送速率长度，可在MS业务初始建立时由“带外” SIP/SDP信令设定。
[0047]5)媒体流标志部分:
[0048]指示要增/减的业务媒体流标记。该部分只是在模式标志部分指示为多个实时媒体流时有效。
[0049]6)编码方式标志部分:
[0050]指示要希望采用的编码方式。该部分只是在发送码率调节标志部分指示采用改变媒体流编码方式或混合方式时有效。[0051]图3为上述媒体流传输特征描述信息在SR/RR消息扩展部分的实现实例。在图3中的各部分解释如下:
[0052]OV:溢出标志部分，不同标志区分上溢出及下溢出两种情况
[0053]M:模式标志部分，不同标志区分当前业务为单实时媒体流还是多实时媒体流
[0054]A:调节方式标志部分，不同标志区分增/减部分媒体流方式、码率调节方式、混合调节方式
[0055]S:发送码率调节方式标志部分，不同标志区分自适应编码方式调节及步进(基于步长增或减)调节发送速率方式
[0056]Media Number:媒体流标志部分,通过独立标记指示要选择IMS业务中增加或拆除的媒体流
[0057]Codec:编码方式标注部分，指示希望采用的实时媒体流编码方式
[0058]图4为“带内”媒体流传输特征的基本协商流程的一个实例。参照图4所示，实时媒体流发送方410和实时媒体流430之间通过MS网络420实现通信，基础RTCP扩展SR、RR消息的“带内”媒体流传输特征的基本协商机制如下:
[0059]在步骤401，实时MS业务媒体流发送方410与接收方430通过“带外”SIP/SDP建立初始业务连接。在SDP中包含对应该业务的业务信道环境上、下阀值设定信息、协商启动余量信息。同时SDP中还包含用于对该业务媒体流发送速率进行调节的步长设定信息。这样，开始了实时媒体流的发送和接收，此时丢包率处于图1正常业务信道环境区间。
[0060]在步骤402,接收方430通过RR消息向发送方410反馈当前的丢包率。接收方反馈当前丢包率的RR消息过程遵从已有协议RFC3550的反馈机制。
[0061]在步骤403，发送方410通过接收方反馈的RR消息监控当前的丢包率。由于业务进行中可能的业务信道环境变化，导致丢包率波动。当发送方410监测到丢包率跨越业务信道环境上、下阀值标记的两个临界点，并向同一方向增加或减少一个协商启动余量后，进入步骤404。协商启动余量是丢包率到达两个阀值临界点后在图1的丢包率时间轴上向同一个方向持续变化的余量，其设置用于防止丢包率在临界点周围波动时，频繁启动协商过程。协商启动余量参数根据具体业务特征可以在MS业务的初始“带外”SIP/SDP信令中设定。
[0062]在步骤404，发送方410向接收方430发送扩展SR消息(例如图3所示的格式)，启动媒体流传输特征改变的协商过程。
[0063]在一个不例中，发送方410所建议的媒体流传输特征描述信息为:上溢出，多实时媒体流模式，码率调节方式，自适应编码方式调节码率，低码率视频编码。
[0064]在步骤405，接收方430返回扩展的RR消息对接收到的扩展SR消息进行响应。具体地说，若接收方430同意扩展SR消息中建议变更的媒体流传输特征信息参数，则回复的扩展RR消息中的溢出标志部分同接收到的扩展SR消息，其余扩展标志部分为空；若接收方430不同意扩展SR消息建议的媒体流传输特征信息参数，则向发送方回复完整的扩展RR消息(如图3所示的格式)，其中填写接收方430希望采用的媒体流传输特征描述信息参数。在此，可以约定，即使接收方同意扩展SR消息建议的媒体流传输特征信息参数中的一部分，也回复完整的扩展RR消息。然而可以理解，其它的约定方式，例如接收方只回复在扩展RR消息中包含不同意而建议修改的那部分媒体流传输特征信息参数。[0065]在一个示例中，接收方430不同意扩展SR消息建议的媒体流传输特征信息参数，并且建议的媒体流传输特征描述信息为:上溢出，多实时媒体流模式，调节方式为混合调节方式,标记删除的媒体流为音频媒体流,步进方式调节视频流发送速率。
[0066]在发送方410，则对返回的扩展RR消息进行分析。若收到扩展RR消息除溢出标志部分以外部分为空，表不接收方430同意,发送方410根据上一次发出的扩展SR消息中的媒体流传输特征信息参数对当前实时媒体流的发送进行变更。若扩展RR消息溢出标志部分以外部分不为空，发送方410也同意接收方430的扩展RR消息中的参数建议，则发送方410根据所收到的扩展RR消息中的参数对当前实时媒体流的发送进行变更。
[0067]如果发送方410不同意接收方的扩展RR消息中的参数建议，可重复步骤404发起扩展SR消息继续进行协商。也就是说，这种协商可进行多次，直至协商一致。
[0068]当协商一致后，在步骤406，由发送方410决定根据达成的参数调节当前实时媒体流的发送。在此，假设协商一致的结果是，接收方430返回的扩展RR消息溢出标志部分以外部分不为空，发送方410也同意接收方430的扩展RR消息中的参数建议。
[0069]如步骤407，发送方根据上“带内”协商的结果参数开始进行当前发送实时媒体流的发送调节后，需进行“带内”协商锁定。锁定期间，发送方不能发起扩展SR/RR协商过程。
[0070]在步骤408，根据步骤406所达成的协商一致的结果，进行媒体流调节过程。在一个示例中，当在步骤402监测到丢包率达到业务信道环境上阀值，并继续变大达到协商启动余量后，媒体流调节过程为删除实时音频流，步进方式逐步减少实时视频流的发送速率。
[0071]在步骤409，在媒体流调节过程中，发送方持续监测丢包率，当丢包率达到以业务信道环境上或下阀值标记的临界点时，停止调节。
[0072]在步骤411，发送方410解锁“带内”协商，即发送方可发起扩展SR/RR协商过程。
[0073]本发明上述实施例所描述的一种基于RTCP协议RR、SR消息扩展的“带内” MS业务实时媒体流协商式自适应调节方式，利用RTCP控制消息交互特点实现了 “带内”协商控制，相比于需要多次重新独立建立承载的“带外” SIP/SDP信令控制方式，提高了用户体验。
[0074]虽然本发明已参照当前的具体实施例来描述，但是本【技术领域】中的普通技术人员应当认识到，以上的实施例仅是用来说明本发明，在没有脱离本发明精神的情况下还可作出各种等效的变化或替换，因此，只要在本发明的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。
【权利要求】
1.一种MS业务实时媒体流的协商式调节方法，包括以下步骤: a.在媒体流的发送方与接收方之间通过SIP/SDP建立初始业务连接； b.从接收方通过RR消息向发送方反馈当前的丢包率； c.在发送方监控当前的丢包率，当监测到丢包率跨越业务信道环境的阀值，并向同一方向减少或增加一个协商启动余量后，进入步骤d ； d.从发送方向接收方发送扩展的SR消息，以启动媒体流传输特征改变的带内协商过程; e.从接收方返回扩展的RR消息对接收到的扩展的SR消息进行响应； f.当发送方与接收方协商一致后，在发送方决定根据达成的参数调节当前实时媒体流的发送； g.开始进行媒体流调节过程；以及 h.在媒体流调节过程中，在发送方持续监测丢包率，当丢包率达到以业务信道环境上或下阀值标记的临界点时，停止媒体流调节。
2.如权利要求1所述的方法，其特征在于，在步骤f和g之间还包括:进行带内协商锁定，在该锁定期间，发送方不能发起扩展的SR或RR协商过程。
3.如权利要求1所述的方法，其特征在于，在步骤h之后还包括:解锁带内协商，使发送方可发起扩展的SR或RR协商过程。
4.如权利要求1所述的方法，其特征在于，在该步骤a中，SDP中包含对应该业务的业务信道环境的阀值和协商启动余量。
5.如权利要求1所述的方法，其特征在于，在该步骤a中，SDP中包含用于对该业务媒体流发送速率进行调节的步长设定信息。
6.如权利要求1所述的方法，其特征在于，还包括，重复该步骤d及该步骤e，使该发送方与该接收方协商一致。
7.如权利要求1或4所述的方法，其特征在于，该业务信道环境的阀值包括业务信道上阀值和业务信道下阀值，而将该业务信道环境区分为丢包率低于业务信道下阀值的理想信道环境区间、丢包率高于业务信道上阀值的恶化业务信道环境区间、以及正常业务信道环境区间。
8.如权利要求1所述的方法，其特征在于，该扩展的SR消息和该扩展的RR消息分别包括配置文件特定扩展部分，以包含该媒体流传输特征的描述信息。
9.如权利要求8所述的方法，其特征在于，该媒体流传输特征的描述信息包括以下的至少一部分:溢出标志部分、模式标志部分、调节方式标志部分、发送码率调节方式标志部分、媒体流标志部分、以及编码方式标志部分。
10.如权利要求1所述的方法，其特征在于，该实时媒体流的传输是基于RTP/RTCP协议。
【文档编号】H04L1/00GK103856461SQ201210514564
【公开日】2014年6月11日 申请日期:2012年12月4日 优先权日:2012年12月4日
【发明者】莫建林 申请人:联芯科技有限公司