用于多播或广播服务的反馈控制的制作方法

文档序号:7634687阅读:232来源:国知局
专利名称:用于多播或广播服务的反馈控制的制作方法
技术领域
本发明涉及用于控制移动终端的反馈的传送的方法,其中该移动终端通过移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务,并且本发明还涉及使用该方法的移动终端和反馈控制实体。此外,提供了一种通信系统,其包括反馈控制实体、以及接收多播或广播的移动终端。
背景技术
实时传输协议(RTP)(见Schulzrinne等人,″RTPA Transport Protocolfor Real-Time Applications″,RFC 3550,可从http//www.ietf.org获得)提供了端对端网络传输功能,其适于通过多播或单播网络服务来传送诸如音频、视频或模拟数据之类的实时数据的应用。RTP不为实时服务进行资源预留,并且不保证服务质量。
由控制协议(RTCP)增强该数据传输,以允许对以可缩放到大的多播网络的方式进行的数据传送进行监控,并且提供最少的控制和标识功能。将RTP和RTCP设计为独立于基础传输和网络层。
对于3G网络中的流服务的多播或广播数据传输,可使用RTP。如上所述,实时控制协议(RTCP)提供了用于监控和传输关于所传送的RTP流的控制信息的手段。
标准RTP/RTCPRTP(及其相伴协议RTCP)一开始就被设计为用于单播和多播数据传输二者(RTP报告)。因此,已提出了用于防止反馈爆聚(implosion)的可缩放算法和相应机制。在本文档的其余部分中,将后者分别称为“标准RTCP算法和机制”。
已经利用以任意源多播(ASM)模型为基础的假定而设计了RTCP标准算法和机制,其中允许每个端系统在双向传输信道上发送和接收数据。因此,每个参与的端系统接收RTP数据、以及所有参与者的RTCP发送者报告(SR)和接收者报告(RR)。对所有RR的接收允许每个端系统独立地估计会话参与者的数量,并根据RTCP标准算法、利用这个值来计算报告时间间隔。此外,其向端主机提供一种收集关于所有参与者信息的手段,这对于某些应用、像小组会议可能是有用的。
用于单向多播信道的RTCP RR如S.Bhattacharyya,Ed.″An Overview of Source-Specific Multicast(SSM)″(参见RFC 3539,可从http//www.ietf.org获得)所述的源特定多播(Source-Specific Multicast,SSM)模型尤其适合于结合3GPP MBMS架构使用,其中该MBMS架构在可从http//www.3gpp.org获得的、2003年12月的3GPP TR 23.846″Multimedia Broadcast/Multicast(MBMS);Architecture and functional description(Release 6)″,V6.1.0中规定。
与ASM相比,SSM多播模型引入更低的复杂度,并且允许基于预定的访问控制。在SSM中,允许每个单端系统使用单向多播传输信道来传输数据。只有那些预定了这个信道的参与者才会接收这些消息。
不同于ASM,RTCP接收者报告不能在该多播信道传输。然而,根据指定的接收者和发送者报告带宽值,通过让每个接收者在单个单播传输信道上向发送者发送反馈、以及发送者在多播信道上反映这些消息,可以克服对SSM的这个限制。
用于RTCP的SDP带宽修改器(modifier)标准RTCP机制将全部控制流量带宽缩放到RTP会话带宽的5%。对于具有单个发送者的目标应用情况,为发送者报告(SR)分配的RTP带宽的分数S为1.25%,而向由端系统平等共享的、接收者报告(RR)的分数R分配了值3.75%。为支持差别化配给的分配,已由Casner在″Session DescriptionProtocol(SDP)Bandwidth Modifiers for RTP Control Protocol(RTCP)Bandwidth″(参见RFC 3556,可从http//www.ietf.org获得)提出了会话描述协议(SDP)内的RTCP带宽修改器的信令。用于特定会话的SDP实例可用两个额外参数进行扩展,其中,b=RS<带宽值>和b=RR<带宽值>分别指定了全部发送者和接收者报告速率。根据标准RTCP算法来确定每个主机分配和报告时间间隔。
多播反馈调节在IETE RMT工作组中考虑的大量现有工作解决抑制冗余反馈的问题,例如,对用于可靠多播传播的丢失数据包的否定确认。其他多播应用需要具有根据特定度量(metric)的极端值的端系统的反馈。这些方案的目的在于,在多播会话中寻找具有受限性能(带宽)的接收者,以便发送者相对于这个接收者的反馈来调整传输速率。对这两个问题的端对端解决方法通常使用反馈计时器或轮询机制的不同变体。
几乎没有处理用于收集多播中的参与接收者的状态信息的反馈调节的现有工作。在Bolet等人,″Scalable Feedback Control for Multicast VideoDistribution in the Internet″(Proceeding of ACM/SIGCOMM 1994,第24卷,第4期,1994年10月)中提供了基于收集接收者状态信息的、用于视频流应用的一种优秀机制。所提出的机制的主要目的是根据报告的状态信息调整包的发送速率。
因此,允许接收者报告的状态集被限制为仅仅三种不同的状态。因此,由于以下问题,该方法对调节3GPP MBMS会话中统计信息的反馈是不可用的必须由每个接收者借助于RTCP RR来发现参与端系统的数量。这要求每个参与移动终端(MT,UE)建立到发送者的点对点反馈信道。
然后,该发送者必须反映所有的RR、或对它们总计,并且通过单向多播信道转发此信息。该解决方法的缺点在蜂窝式和移动环境的上下文中是显而易见的●用于建立和维护反馈信道的开销(每个MT/UE一个),●在由所反映的报告生成的多播信道上的开销,以及●在必须动态地保持和更新状态信息的端设备上的功耗开销。
单播反馈信道可能需要小区内大量资源,例如,如果每个用户要具有带有例如单独扩展码的专用上行链路信道。在相应小区中,这个情形可导致增加的呼叫阻塞和移交掉线可能性。
利用如下所示的标准算法,用最小时间间隔Tmin(例如5秒)、RTCP包大小PRTCP、全部接收者报告带宽BRR(RTP带宽的3.75%)、以及接收者的数量n,来计算出每个接收者带宽bRR
bRR=min[avg(PRTCP)Tmin,BRRn],]]>在图1中描述了作为组大小的函数的所产生的每一接收者带宽。
利用标准RTCP算法计算的每个接收者带宽由于组的动态-在正进行的会话期间接收者可加入和离开-有效的每个接收者带宽事先是不知道的并且可显著地变化。为了避免为适应当前组大小而频繁地重新建立反馈信道,必须用预留到上限的资源,即在最坏情况下的最大RR带宽,来建立接收者反馈信道。结果,可能非常低效率地使用用于反馈信道的预留资源。
通过下述标准RTP算法,用最小时间间隔Tmin、接收者的数量n、RTCP包大小PRTCP、以及全部接收者报告带宽BRR来计算RTCP RR时间间隔TT=max(Tmin,Tcalc),其中,Tcalc=n×avg(PRTCP)BRR.]]>图2示出RR时间间隔T(根据上述方程计算得到)与参与该RTP会话的接收者数量n的关系。时间间隔随着参与接收者的数量而线性增加。
为说明定量影响,可考虑下面具有64kbps数据速率的流化音频视频内容的示例。即,对于120字节的平均RTCP PP包大小、以及n=100,可算出报告时间间隔为T100=40秒;对于n=9000,它将达到T9000=1小时。
根据标准算法,接收者在间隔
内根据均匀分布概率性地调度它们的报告包。也就是说,在上述示例中,预期分别在20秒和0.5小时后发送第一报告包。显然这个RR时间间隔T的结果对于实践目的是不可接受的。如上所述,标准RTCP方法解决(address)ASM模型中的该特性,其中每个端系统可在单个双向信道上发送和接收数据,并且进一步提供了损失报告的可能性。然而,对3GPP MBMS服务,该间隔将会容易地超过会话的持续时间,而使得报告无用。
还将注意到,对于广播数据传送,也可考虑提供来自广播服务接收者的反馈,特别是在还可以使用用于广播数据传送的、基于内容的收费时,其中所接收内容的质量对于收费可能是至关重要的。这与基于预定的收费相反,在其于预定的收费中,只有某一服务被接收了这个事实是重要的。
可将上述RTP和MBMS特定的问题概括到经由空中接口在移动终端处接收的多播或广播服务,这些服务使用能够从接收终端向发送源如多播或广播服务器提供反馈的协议。
在WO 2004/040928A1中,已知有用于报告无线网络中的多用户服务的方法。这个文档的概念在于基于中间网络部分中的空中接口资源的RNC信息、生成总计反馈报告。可为多用户服务,即为该多用户服务的所有接收者禁用来自终端的RTCP反馈。在一种变体中,可由RNC配置多用户服务的所有接收者,以提供事件驱动反馈。也可在RNC中使用来自接收者的这个信息以形成总计反馈。
WO 2004/040928A1中提出的方法和系统使用有关移动通信系统中的无线电资源的RNC信息,以生成传输到多用户服务源即服务器的总计反馈报告。因此,将端对端概念的多用户服务供应转换为这个文档中所提出的方法,需要在不同层中的相互作用和数据交换,以例如作为会话层和无线电资源控制以及在RNC中的无线电资源管理和中间网络部分之间的专属扩展,以便传递数据。如果用于提供多播或广播服务的体系应该被广泛地安置,则这些扩展是不可行的。

发明内容
本发明的目的在于为经由保持端对端会话概念的空中接口提供的多播和广播服务启用可配置和自适应的反馈。另一个目的可以是为使用RTP协议提供的MBMS服务提供可配置和自适应的反馈。
由独立权利要求的主题来实现了该目的。本发明的有益实施例是附属权利要求的主题。
本发明的主要思想之一是仅允许移动通信网络内、从反馈控制实体接收多播或广播服务的终端的子集将反馈提供给发送源,即该反馈控制实体。因此有可能保持端对端概念,且不破坏所利用协议的分层体系。本发明的另一思想是统计性用户采样的使用,基于该采样确定提供反馈的终端子集。
根据本发明的实施例,提供了一种用于控制移动终端的反馈的传送的方法,其中该移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务。根据这种方法,移动终端可经由单向下行链路信道、并使用不可靠的传输协议和会话协议,来接收多播或广播服务,其中该会话协议对接收多播或广播服务的终端的反馈供应进行配置。另外,移动终端可接收参数,该移动终端可基于该参数决定是否向反馈控制实体提供反馈。
在决定步骤中,移动终端可基于所接收的参数,决定是否向反馈控制实体提供用于多播服务或广播的、会话协议配置的反馈,并且在决定提供会话协议配置的反馈的情况下,可以建立用于将反馈提供给会话协议配置的反馈控制实体的载体。
一旦已经建立了该载体,则移动终端可经由所建立的载体,向反馈控制实体传输会话协议配置的反馈,其中该反馈指示所述多播或广播服务的接收统计信息。
这个实施例具有如下优点移动终端可基于信令化的参数集(或单个参数)来决定是否提供会话协议配置的反馈。如上所述,在移动终端决定提供会话协议配置的反馈的情况下,建立用于提供会话协议配置的反馈的载体,以便在这种情况下,仅向该移动终端分配例如在移动通信系统的无线电接入网络中的资源。
在本发明的进一步实施例中,在移动终端处接收的参数指示用于概率试验的概率值,移动终端基于该值决定是否提供会话协议配置的反馈。因此,是否提供会话协议配置的反馈的决定可基于由移动终端执行的概率试验的结果,其中所接收的概率值用于执行这个试验。
通过使用发信号通知给接收多播或广播服务的移动终端的概率度量,可减小从移动通信系统的反馈控制实体接收的数据(参数)的大小,但允许每个接收该概率度量的移动终端自发确定是否提供会话协议配置的反馈。下面将提供有关用于决定是否提供反馈的概率试验的使用细节。
根据本发明的另一个实施例,概率试验是伯努利(Bernoulli)试验。这可以具有优点可使用在执行试验时简化计算的近似,以降低在移动终端处的计算复杂度。
在本发明的进一步实施例中,经由提供多播或广播服务的多播或广播数据信道来接收这些参数。如上所概述,在这种情况下可使用不可靠的传输协议例如UDP来将数据传送到终端。
根据本发明的另一实施例的方法预见经由通告信道接收这些参数,其中在该通告信道上将多播或广播服务通告给潜在接收者。在这个实施例的变体中,使用可靠通信协议用于在该通告信道上的数据传输。
这个实施例考虑到,每个终端以可靠的方式来接收信号参数至少一次可能是所期望的。在借助于不可靠通信协议提供这些参数的情况下,不能确保每个接收终端都可以具有必要的参数存在以便决定是否提供会话协议配置的反馈。
本发明的另一实施例预见在移动终端处接收的参数还指示在其之前该参数(多个)为有效的时间点。在该实施例的变体中,在达到由该参数所指示的时间点的情况下,移动终端可释放已建立的、用于提供会话协议配置的反馈的载体。
因此,可确保移动终端使用过期参数集来确定是否应该从相应终端提供会话协议配置的反馈。例如,这可应用于其中使用不可靠传输机制(例如周期性地)更新和提供从反馈控制实体接收的参数的情况。在这个情况下,不能确保每个终端成功地接收参数集的更新,以致预见上述指示参数有效期的机制是可行的。
如上面已指出的那样,本发明的另一实施例便于参数的重新配置或更新。移动终端可接收重新配置参数,其中该重新配置参数更新先前从反馈控制实体接收的参数。
在该实施例的变体中,重新配置参数可包括标记,该标记指示是否更新先前接收的参数的有效期,即指示该参数是否在所谓的“额外”时段中有效。在这个情况下,移动终端可基于该标记更新用于先前所接收参数的有效期。
在另一实施例中,仅那些已建立了用于提供会话协议配置的反馈的载体的移动终端才可进行有效期的更新。
此外,根据本发明的另一实施例,所接收的重新配置参数可包括(额外的)标记,该标记指示是否要由移动终端执行有关提供会话协议配置的反馈的新决定。因此,可根据该标记来控制移动终端,以确定是否要做出有关提供会话协议配置的反馈的新决定。如果该标记指示这样做,则移动终端可基于所接收的重新配置参数,决定是否向反馈控制实体提供用于多播或广播服务的会话协议配置的反馈。如上所述,在决定提供会话协议配置的反馈的情况下,则建立用于向反馈控制实体提供会话协议配置的反馈的载体,并且移动终端可经由所建立的载体,向反馈控制实体传输指示所述多播或广播服务的接收统计信息的、会话协议配置的反馈。
接着,在下面将概述涉及反馈控制实体的操作的其他实施例。应注意到,反馈控制实体可包含在单独的网络单元中,或可与服务源即多播或广播服务提供者一起包含在移动通信网络的网络单元中。本发明的各种实施例之一提供了一种用于由反馈控制实体控制多个移动终端的反馈的传送的方法,该多个移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务。根据这种方法,反馈控制实体可经由单向下行链路信道、并使用不可靠的传输协议和会话协议来传送或转发多播或广播服务,其中,该会话协议对接收多播或广播服务的终端反馈供应进行配置。
另外,反馈控制实体可确定允许移动终端决定是否向反馈控制实体提供会话协议配置的反馈的参数,并且可将那些参数传送给接收多播或广播服务的多个移动终端的至少一个子集。因此,反馈控制实体可从已接收了这些参数的多个移动终端的子集接收反馈。
在本发明的另一实施例中,反馈控制实体基于由反馈控制实体维持的、或从移动通信系统的网络实体接收的多播和广播服务的状态信息,来确定这些参数。
在本发明的进一步实施例中,由反馈控制实体确定的参数指示用于概率试验的概率值,移动终端基于该概率值决定是否提供会话协议配置的反馈。因此,根据这个实施例,反馈控制实体可确定要由移动终端使用、用于概率试验的概率度量,并可将此度量发信号通知给该多个移动终端的至少一个子集。
如上所述,本发明的一个实施例预见经由通告信道传送参数(多个),其中在该通告信道上将多播或广播服务通告给潜在接收者。另外,可以使用可靠通信协议用于通告信道上的数据传输。
根据进一步实施例,反馈控制实体可基于多播或广播服务的参与者数量来确定概率值。例如,可从多播或广播服务相关状态信息中获得多播或广播服务的参与者数量。
在本发明的另一实施例中,多播或广播服务相关的状态信息包含在反馈控制实体处维持的MBMS UE上下文或MBMS载体上下文中。作为选择,可由反馈控制实体从维持MBMS UE上下文或MBMS载体上下文的移动通信网络的网络实体接收该状态信息。
在本发明的进一步实施例中,反馈控制实体可从多播或广播服务提供者接收多播或广播服务的数据。
在这个实施例的变体中,反馈控制实体可向多播或广播服务提供者转发从移动终端接收的会话协议配置的反馈。
在进一步变体中,可使用传输协议和会话协议向反馈控制实体传输多播服务的数据。反馈控制实体可在向移动终端传输或转发多播或广播服务的数据之前,分别将传输协议和会话协议中的至少一个转换成另一个传输协议或会话协议。
另外,有可能使用传输协议和会话协议向反馈控制实体传输用于多播服务的反馈。在这个情况下,反馈控制实体还可在向多播或广播服务提供者转发该反馈之前,分别将传输协议和会话协议中的至少一个转换成另一个传输协议或会话协议。
在这个实施例的另一变体中,反馈控制实体形成从移动终端接收的会话协议配置的反馈的总计,并可将所接收反馈的总计作为反馈信息传输给多播或广播服务提供者。
本发明的进一步实施例考虑使用RTP的服务供应。在这个实施例中,使用RTP协议提供多播或广播服务,并使用RTCP协议提供反馈,其中向RTCP协议消息分配用于提供多播或广播服务的会话的、可用带宽的一部分。
此外,作为选择,可以RTCP协议中的接收者报告的形式来提供会话协议配置的反馈。应注意到,根据本发明的实施例,上述接收统计信息可对应于根据RTCP协议、在接收者报告中信号通知的信息。
根据本发明的另一实施例,由反馈控制实体传送并由移动终端接收的参数还可指示报告时间间隔和可用带宽,以便使用RTCP协议提供反馈。
从反馈控制实体发信号通知的参数可以包括在由反馈控制实体传送的RTCP协议的发送者报告消息内。
另一实施例涉及一种经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务的移动终端。该移动终端可包括接收器,用于经由单向下行链路信道、并使用不可靠传输协议来接收多播或广播服务。另外,该终端可接收参数,该移动终端基于该参数决定是否向反馈控制实体提供会话协议配置的反馈。处理器,用于基于所接收的参数、决定是否向反馈控制实体提供用于多播服务或广播服务的会话协议配置的反馈,并用于在决定提供会话协议配置的反馈的情况下,建立用于将会话协议配置的反馈提供给反馈控制实体的载体;以及传送器,用于经由所建立的载体、向反馈控制实体传送会话协议配置的反馈,其中该反馈指示多播或广播服务的接收统计信息。
在本发明的另一实施例中,移动终端还可包括装置,其适于执行由上述反馈控制方法的各种实施例之一中的移动终端所执行的步骤。
本发明的另一实施例提供了一种反馈控制实体,用于控制多个移动终端的反馈的传送,其中该多个移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务。根据这个实施例,该反馈控制实体可包括传送器,用于经由单向下行链路信道、并使用不可靠的传输协议和会话协议来传送或转发多播或广播服务,其中该会话协议对接收多播或广播服务的终端的反馈供应进行配置。另外,反馈控制实体可还包括处理器,用于确定允许移动终端决定是否向反馈控制实体提供会话协议配置的反馈的参数,其中该传送器适于向接收该多播或广播服务的多个移动终端中的至少一个子集传送所述参数;以及接收器,用于从已接收了该参数的多个移动终端的子集接收会话协议配置的反馈。
在本发明的另一实施例中,反馈控制实体可还包括装置,其适于执行由上述反馈控制方法的各种实施例之一中的反馈控制实体所执行的步骤。
另外,本发明的一个实施例涉及一种移动通信系统,其包括如上所定义的反馈控制实体、以及如上所定义的、用于经由空中接口从反馈控制实体接收多播或广播服务的至少一个移动终端。
本发明的另一实施例涉及用于存储指令的计算机可读介质,当该指令由移动终端的处理器执行时,导致该处理器控制移动终端的反馈的传送,其中该移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务,这通过以下步骤完成通过经由单向下行链路信道、并使用不可靠的传输协议和会话协议在移动终端处接收多播或广播服务,其中该会话协议对接收多播或广播服务的终端的反馈供应进行配置;在移动终端处接收参数,基于该参数,移动终端决定是否向反馈控制实体提供会话协议配置的反馈;由移动终端基于所接收的参数,决定是否向反馈控制实体提供用于多播服务或广播的、会话协议配置的反馈;在决定提供会话协议配置的反馈的情况下,由移动终端建立用于将会话协议配置的反馈提供给反馈控制实体的载体;以及经由所建立的载体,从移动终端向反馈控制实体传送指示多播或广播服务的接收统计信息的反馈。
在另一实施例中,计算机可读介质可还存储这样的指令,当这些指令由移动终端的处理器执行时,导致该处理器执行由上述反馈控制方法的各种实施例之一中的移动终端所执行的步骤。
此外,本发明的另一实施例提供了一种计算机可读介质用于存储指令,当该指令由反馈控制实体的处理器执行时,导致该处理器控制移动终端的反馈的传送,其中该移动终端经由移动通信系统的空中接口接收从反馈控制实体传送或转发的多播或广播服务,这通过以下步骤完成经由单向下行链路信道、并使用到至少一个移动终端的不可靠传输协议和会话协议,从反馈控制实体转发多播或广播服务,其中,该会话协议对接收多播或广播服务的终端的反馈供应进行配置;在反馈控制实体处确定允许移动终端决定是否向反馈控制实体提供会话协议配置的反馈的参数;将这些参数从反馈控制实体传送到接收多播或广播服务的多个移动终端的至少一个子集;以及在反馈控制实体处,从已接收了这些参数的所述多个移动终端的子集接收会话协议配置的反馈。
在进一步实施例中,计算机可读介质还存储这样的指令,当这些指令由反馈控制实体的处理器执行时,导致该处理器执行由上述反馈控制方法的各种实施例之一中的反馈控制实体执行的步骤。


在下文中,参考附图更详细地说明本发明。其中用相同的附图标记来标记附图中相似或相应的细节。
图1示出了作为已经预定了RTP会话的接收者的数量n的函数的、每个接收者报告带宽;图2示出了作为已经预定了RTP会话的接收者的数量n的函数的、接收者报告(RR)时间间隔T;图3示出了RTCP应用定义包;图4示出了根据本发明实施例、在RTCP应用定义包中传输的应用定义参数的格式;图5示出了根据本发明实施例、扩展RTCP接收者报告块的格式;图6示出了根据本发明实施例、用于在图3的RTCP应用定义包中、或图5所示的扩展RTCP接收者报告块中传输参数的格式;
图7、图8和图9示出了根据本发明的不同实施例、用于向用户提供多播和广播服务以及控制接收终端的反馈的不同场景;以及图10和图11分别示出了根据本发明的不同实施例的移动终端和反馈控制实体。
具体实施例方式
下面的段落将说明本发明的各种实施例。仅为了示例性目的,大多数实施例参照UMTS通信系统来概述,并且在后续段落中使用的术语主要涉及UTMS术语。然而,这些与UMTS体系相关的使用术语和实施例说明目的不是将本发明的原则和思想限制为这样的系统。
此外,上面在背景技术部分给出的详细阐述仅仅是为了更好地理解下面所描述的大多数UMTS特定的示例实施例,并且不应当被理解为将本发明限制为所描述的、移动通信系统中的处理和功能的特定实现。
将在后续部分中概述的思想和原则可适用于使用单向下行链路和不可靠的传输协议用于数据传送、经由空中接口在移动终端处接收的多播或广播服务。另外,使用了使得能够从接收终端向发送源(例如反馈控制实体)提供反馈的协议。要注意到,在上述场景中,不可能经由通过其接收服务数据的信道提供反馈,这是因为该信道是单向的。
本发明的一个实施例的关键方面在于,如先前所述,在可控制通信网络内的服务和反馈供应的移动通信网络中,仅仅允许从反馈控制实体接收多播或广播服务的终端的子集向反馈控制实体提供反馈。在本发明的实施例中,例如,可通过让接收多播或广播服务的移动终端决定-例如基于概率试验-它们是否提供反馈来实现。通过发信号通知参数如试验中使用的概率值,反馈控制实体可通过改变所信号通知的参数来控制反馈,以便-统计地说-具有所希望数量的、接收服务的移动终端提供反馈。
在这个方面重要的是,要注意到多播或广播服务的基础是端对端概念,这意味着端点之间的交换信息对任选的中间节点是透明的。这也被所用的遵循分层体系的协议所反映,该体系将所输送的信息封装在某一层内。在一个层处的信息最初对于其它层是不可见的。仅仅相邻的层能通过良好定义的服务和服务接入点来交换信息。因为所传送的、多播或广播服务的信息仅对发送源(即,反馈控制实体和接收者)是可见的,所以中间节点仅支持比所用传输协议更低层的协议。
选择接收多播或广播服务的终端的子集来提供反馈的思想保持了这个端对端概念,并且不会打破所用协议的分层体系。
相反,在UTRAN或CN的中间节点中生成反馈将打破这些概念,并将需要以不相容的方式来改变协议、以及扩展中间节点以执行不适当的功能。如果广泛地建立了用于提供多播或广播服务的体系,则这些假设中的任意一个都是不可行的。
本发明的另一实施例基于为MBMS服务提供可配置和自适应的反馈解决方案的思想。在下文中将更详细地解释这个实施例。
MBMS服务一般使用RTP协议用于流化媒体。可使用相伴随的RTCP协议用于收集RTP会话反馈,并提供对会话的松散控制。可使用RTCP反馈来收集关于正在进行的RTP多播会话的统计信息。可假设UDP为基础不可靠的传输协议。
替代标准RTP算法,即使用RTCP RR来估计参与移动终端(MT)的数量,由本发明的这个实施例提出的方案使用MBMS信令和/或MBMS状态信息来确定会话中MT/UE的确切数量。这个方法避免了让每个接收者都具有反馈信道的需要,即每个参与者接收来自其他参与者的所有消息的事实,并消除了多播/广播和计算日常费用。
一般而言,应注意到,在MBMS规范中,存在两类状态信息MBMS载体上下文,其描述一种特定MBMS载体服务;以及MBMS UE上下文,其包括关于特定MBMS载体服务的UE特定信息。这两种上下文均可在RAN、SGSN、GGSN和BM-SC中创建。可为每个接收服务的UE创建UE上下文。目前,GGSN中的载体上下文包含接收服务的UE的数量。
然而,当然也有可能的是,其他RAN或CN节点在上下文中存储服务的状态信息,即允许通过例如对所创建的上下文数量的计数(即,在网络节点中,每个UE具有其自身的UE上下文),也允许由上下文内指示服务参与者总数的字段,来确定服务参与UE的数量。
在采用MBMS体系用于服务供应的情况下,可对BM-SC的UE上下文中的参与者的数量进行计数,或GGSN可以通过将载体上下文中的相应字段值发信号通知给BM-SC来提供参与者的总数。
用于收集会话统计信息的统计用户采样的用法可用于仅允许移动终端(MT)的子集来提供反馈。即,仅仅接收者的一个集合被配置为向反馈控制实体发送报告。这与标准RTP多播相反,在标准RTP多播中,每个参与者都发送RTCP反馈,并且该反馈一般被转发到所有其他方。
根据本发明的这个实施例,以概率性的方式选择发报告接收者的集合。执行统计用户采样所必需的一个参数可以是报告概率。其他可被使用/发信号通知的参数是报告时间间隔和预留的反馈带宽。发送反馈控制实体,例如BM-SC,可根据允许反馈的总量来设置这些参数,这是因为不同的服务可能具有不同的报告需要。
通过采用这个方案,可控制反馈信道的数量,并且更有效地使用每个反馈信道。
上述用于该方案配置的参数可被传输到多播/广播组参与者。例如,可通过使用多播/广播数据信道或通告信道来实现这一点。
这个实施例的一个变体向反馈控制实体(例如BM-SC)提供了这样的可能性即重新配置发报告的接收者集合,以及在正进行的会话期间将报告时间间隔(重新)设置为与组大小无关的常值。这可解决允许将RR的报告时间间隔设置为合理值的问题。
为避免终端在重新配置后以不同的报告间隔和可能性进行操作,可将计时器值包括在这些消息中。因此,可将多播信道上的信令和费用、以及由于在每个端设备上计算参数而引起的计算费用保持为最小。
标准RTP/RTCP算法和机制遵循一般设计,以便支持具有单个和多个数据源以及接收者的应用的广泛类别。在3GPP MBMS环境中的行为目的比RTP/RTCP的供应更加明确,并且集中于从单个服务器向移动终端集合提供单向数据传送服务,即流或下载服务。
因此,如上所示,本发明的一个实施例涉及当采用RTP和RTCP时、对后者环境的优化。具体而言,这个实施例的目的可以是支持与RTP数据传送会话相关的统计信息的反馈,同时解决上面介绍部分所述的问题。3GPP MBMS体系的一个部分是MBMS载体上下文。在这个载体上下文中,聚集了建立穿越3G网络的链路所必需的信息。一般将MBMS载体上下文存储在路径中的每个节点处,其中MBMS服务数据经由该路径而提供给终端,即在BM-SC、RAN、GGSN和SGSN中的终端。
也将所服务UE的数量存储在GGSN的MBMS载体上下文中。因此,GGSN可将所服务UE的数量提供给BM-SC,以便BM-SC可具有有关在MBMS会话中参与UE的确切数量的知识,避免使用RTCP反馈来确定参与RTP会话的用户的数量所固有的延迟和开销。因此,不是通过收集来自每个参与者的反馈报告来确定UE的数量,而是可以使用载体上下文中存储的状态信息来确定UE数量。
因为可基于MBMS状态信息而不使用来自参与用户的反馈来确定会话参与者的数量,所以没有必要为每个参与者保留反馈信道。由此,可实现移动通信系统的RAN和核心网络中可用资源的显著节约。如上概述,本发明的实施例预见与服务相关、并可被存储在RAN和/或CN的一个或更多的网络节点中的状态信息可以用来确定接收特定服务的终端数量。如有必要,可在网络节点之间交换状态信息。
如先前所示,为了减少为反馈目的而分配的必要资源,可以仅仅选择M个接收者(作为接收者的子集)来建立用于向服务器反馈的上行链路信道。MBMS服务器可确定全部反馈带宽BRR的值、以及可用反馈信道的数量M。
因为反馈控制实体可知道报告包PRTCP的结构和平均大小,所以可以根据下列方程计算出用于每个反馈消息的报告间隔TT=M×avg(PRTCP)BRR]]>根据本发明的实施例,可采取概率性方法用于选择发报告的接收者集合M。每个接收者可执行概率试验,例如成功概率为p的伯努利试验。为计算这个值,概率密度函数的特征如下。假设n个用户执行概率为p的伯努利试验,并假设每次试验都相互独立,则可获得二项式分布,并且可将该概率密度函数表达为fx(x)=P(X=x)=nxpx(1-p)n-x]]>此外,由下式给出概率分布函数Fx(x)=P(X≤x)=Σk≤xnkpk(1-p)n-k]]>在特定条件下,二项式分布可用高斯(Gauβ)分布来近似。其要求是np>4n(1-p)=nq>4这个近似还可被用于当考虑MBMS服务时的简化,因为通常可假设将多播服务发送给大量的用户。
给定这个简化,该方程更易于处理。简化二项式分布的概率密度函数将是带有下述均值和方差的高斯分布fx(x)=P(X=x)=12πnpqe12(x-μσ)2]]>其中μ=np且σ2=npq。
如上所述,可根据MBMS载体上下文确定在多播会话中当前参与接收者的总数n。以这种方式,服务器可具有用于计算成功概率p所存储的全部信息。因此,让反馈控制实体执行上述计算、并在多播/广播信道向该组顺序地通告全部的必要参数(时间间隔T、概率p、每个接收者报告带宽BRR/M=bRR)是合理的。
根据上述概率分布函数,我们可获得p的值,从而导出发报告的接收者的总数M,当p的值满足下式时,其应该在区间(MMin,MMax)中P(MMin≤x≤MMax)=Fx(MMax)-Fx(MMin)可使用上面概述的近似或其他方法来求解此方程,在本文中没有更详细地描述该解法(例如,请参见Bronstein等,“Taschenbuch dermathematik”,1999,章16.2.3.1“Binomialverteilung”)。
一旦由UE接收了上述值p,则其可执行伯努利试验。仅仅在试验结果是肯定时,接收者才可建立具有所提供的每个参与接收者报告带宽bRR的反馈信道。要注意到,UE可有机会取决于其中使用了本文中概述的原理的系统而为载体指定所需的带宽。然后UE可在指定的时间间隔T之后发送RTCP RR。
根据本发明的一个实施例,可利用RTCP发送者报告块,将用于接收者配置(即,允许UE确定是否提供反馈)的参数传输到接收者。为此目的,可以存在数种选择。
第一种可能性可以是使用图3所示、符合RTCP规范的应用定义包(APP包)。通常,由于已开发了新的应用和新的特征,所以APP包用于试验用途而无需包类型值登记。
在图3中,在RFC 3500的6.7部分中定义了字段V、P、子类、PT、长度和SSRC。名称字段例如可被设置为“MBMS”,但作为替代可以使用任何其它由不超过4个八位字节组成的名称。此外,可将应用相关数据附于上述字段。
在图4所示的本发明的示例实施例中,APP包中的应用相关部分可至少包括下述字段时间间隔,以毫秒为单位来指示(RTCP)报告时间间隔;概率值,以概率试验的成功概率的定点表示;以及报告带宽,如果概率试验成功,则其指定接收者必须为报告信道分配的带宽(例如,以位每秒为单位)。
根据概率值的定点表示,例如,最大概率p=1可被编码为16位序列(“1111111111111111”)。因此,p的分辨率等于1/(216-1)。
本发明的另一实施例预见借助于如图5所示、新定义的扩展接收者报告块(XR报告块)来传送必要参数。在Friedman等人所著的“RTP ControlProtocol Extended Reports (RTCP XR)”中(参见RFC 3611,可在http//www.ietf.org获得)指定了一种框架,用于定义具有扩展性能的特别(ad-hoc)RTCP报告块。根据这个实施例,可将这样的块定义为输送上面所示的报告信息(例如,报告间隔、报告概率等)。
在图5所示的XR报告块中,在RFC 3611的部分2中定义了字段V、P、保留、PT、长度、SSRC。类似地,在RFC 3611的部分3中定义了字段BT、rsvd(用于类型特定的信息)以及块长度。字段BT(块类型)采用在范围(8,255)中的未用值。已经使用了值0-7。
这个选项具有如下优点其具有这样的可能性,即当使用如上所概述的APP报告块时,直接在RTP协议内而不是在应用层上实现逻辑。由本发明的这个实施例提议的解决方法具有另一个优点接收者可使用或提供根据RFC3611或本文内所定义的可用扩展报告的可能性。
在本发明的另一实施例中,建议使用诸如在RTP报头中的简档特定扩展、用于RTCP的特别报告块或简档特定扩展之类的方法,用于输送允许移动终端确定是否向其提供反馈的参数。
在下文中,在下面的部分中概述了根据本发明的几个实施例、有关如何传输报告信息(使用部分不同的传输协议)的几种变体。
由于其概率性属性、以及在RTP在诸如UDP之类的不可靠传输协议上运行的情况下,上面概述的实施例不可能保证建立确切优选数量的反馈信道。
这个的原因之一可能在于,没有足够数量的参与者从反馈控制实体接收参数,以致不能达到报告的目标最小值。如上所述,下行流中的包可能由于不可靠传输机制的使用而丢失。
另一个原因可能在于,由于试验的概率属性,试验导致实际上发送反馈消息的用户过于少。这应该是罕见的情况,因为可以对方程P(MMin≤x≤MMax)=Fx(MMax)-Fx(MMin)(也见上面)求解以便最小化发送反馈的用户过于少的概率。
同样,诸如报告带宽的增加之类的各种其他原因使得允许接收者重新配置是合理的。
在下文中,本发明的实施例概述了可如何重新配置用于在移动终端处决定是否提供反馈的参数的重新配置。除根据上面的实施例(见图4和图5)发信号通知的信息外,还可将指示重新配置的两个标记和某些计时器信息包括到用于将参数输送到移动终端的包中。例如,计时器可避免不同的参与者使用不同的设置并因此耗尽上行链路带宽。
图6示出了根据这个实施例的包结构。如上面参考图4和图5概述的实施例中所示,该包包含概率字段。假设该字段长14位,并使用伯努利试验的成功概率的定点表示,则p的分辨率等于1/(214-1)。可由预定的14位序列(例如“11111111111111”)来指示概率p=1。
除概率字段、报告带宽字段和时间间隔字段之外,包结构可还包括重新配置标记(R)、delta标记(D)和计时器值字段(如32位),该计时器值字段指示参数有效的时间间隔(如,以毫秒为单位)。
当计时器过期,并且这个接收者还未接收到新的值时,该接收者(移动终端)可能停止使用这些值,并可能卸除已建立的反馈信道。为了避免因为连续的报告设置(参数)未由参与者的同一集合所接收而导致终端以不同的设置操作,这是可行的。具有已建立的反馈信道的接收者,可侦听该报告设置,并可相应地更新它们的计时器值。
重新配置标记(R)可向接收者指示是否存在要执行的重新配置。如果未置位重新配置标记(如R=0),则该消息用于刷新具有已建立的反馈信道的接收者的计时器值。这用于保持现有的发报告的接收者,并且不执行重新配置。在重新配置标记置位(如R=1)时,接收者必须根据delta标记(D)的状态来执行概率试验。
如果置位了重新配置标记(如R=1),则delta标记(D)可定义重新配置的范围。如果未置位delta标记(如D=0),则重新配置应用于所有接收者。在这个情况下,所有接收者可根据指定的概率值来执行概率试验。这可用于初始选择发报告的接收者或用于完全重新配置已建立的报告的场景,如用于停止所有发报告的接收者。
在未置位delta标记的情况下(如D=0),先前已决定执行反馈并因此已建立了反馈信道的移动终端,可保持那个信道,而不是执行卸除或重新建立。仅在已建立的上行链路提供与新消息中通告的带宽相同的带宽的假设下,后者才可保持为真。如果带宽已改变了,则接收者可能需要卸除旧的信道,并重新建立新的反馈信道(载体)。
如果置位了delta标记(如D=1),则重新配置可仅应用于那些确实还未维持反馈信道的接收者。只有那些接收者可根据指定的概率值执行概率试验。在未满足发报告接收者的某一优选阈值Mmin、并且另外的接收者应该建立反馈信道的情况下,这可能是有用的。
下表总结了不同的重新配置选项

根据上面部分可见,在使用不可靠的传输机制来传送报告参数的情况下,该参数可能在传输期间丢失。在通过不可靠的UDP协议来传送RTP包的情形下,这尤其可能是真的。UDP是提供不可靠数据报文服务的传输协议。其通常用于RTP包中的单播/多播流媒体(像MPEG4)。相应的RTCP包也通过UDP传输。
BM-SC(作为这个实施例中的反馈控制实体)也可决定以更可靠的方式来发送此信息。要注意到,在上面的实施例中,已将BM-SC考虑为向移动终端传送的参数的来源。然而,还有可能的是,提供多播或广播服务(会话)的内容的反馈控制实体,可确定并将这些参数传播给接收服务的移动终端。
在MBMS框架中,存在以更可靠的方式来传送信息的方法。终端可使用到例如HTTP服务器的点对点连接来获取MBMS服务的会话描述信息(例如,如SDP描述),或者它们可在加入MBMS会话之前接收包括此信息的SMS。
另一种可能性可以是FLUTE协议(参见Paila等人,“FLUTE-FileDelivery over Unidifectional Transport ”,draft-ietf-rmt-flute-07.txt,2004年6月,可在http//www.ietf.org获得)的使用。FLUTE协议可用于MBMS体系中的可靠数据传输。可使用FLUTE和用于描述所提供服务的会话描述协议如SDP(会话描述协议),来传送服务通告信息,该服务通告信息中尤其包含了用于允许移动终端决定是否提供反馈的参数。
因此,在上述的会话描述的可靠传输可用时,根据本发明的另一实施例,在该描述中可包括报告信息(至少包括报告概率,以及如果需要可能另外包括报告间隔和报告带宽)。
接下来,参考图7、8和9,出于示例性的目的,概述了用于向用户提供多播或广播服务、并能够采用上面在各种实施例中概述的发明的某些可能的场景。
在图7中,内容服务器701例如通过基于IP的网络,经由反馈控制实体如BM-SC 704向用户提供多播或广播会话。某些接收服务数据的用户可位于诸如UMTS网络702之类的移动通信网络中,为了示例性目的而在下面考虑该UMTS网络。
如上概述,根据本发明的一个实施例,位于UMTS网络702内的BM-SC 704可控制服务接收终端712、713的反馈的供应。BM-SC 704从内容服务器701接收服务数据,并可例如经由CN(核心网络)703的GGSN(GPRS网关支持节点)705和SGSN(服务GPRS支持节点)706、至少一个RNC 709以及至少一个节点B 710、711,将该服务数据在MBMS会话中传送给终端712、713。要注意的是,BM-SC 704也可负责用于经由UMTS网络702中的通告信道而通告服务可用性,并在服务管理、即UE参加和离开服务中涉及。如先前参考本发明的一个实施例所述,服务通告可包括用于反馈控制的参数。
现在转到图8,其示出了本发明的示例实施例,其中内容服务器801位于移动通信系统内。本质上,除了采用图7所示、基于IP的网络用于数据供应可能不必要之外,对上面参考图7概述的本发明实施例的相同考虑也在此应用。
图9中示出了本发明的示例性实施例,其中内容服务器901是多播或广播服务的数据源。在本发明的这个实施例中,内容服务器901正将服务相关的数据流(多个)直接提供给GGSN 705。根据这个实施例,GGSN 705可因此成为控制接收服务的下行流终端的反馈供应的网络实体。在此情况下,基于诸如MBMS载体上下文之类的服务相关上下文信息中存储的相应信息,GGSN705可直接确定服务参与者的数量。
如图7和8所示,在本发明的另一实施例中,反馈控制实体如BM-SC可从多播或广播服务提供者(内容提供者701、801)接收多播或广播服务的数据。
可以不透明模式为多播或广播服务提供者操作反馈控制实体。在下文中将参考图7来阐述这个模式。
在这个情况下,从内容提供者701(即图7所示的示例实施例中的多播或广播服务提供者)的观点来看,BM-SC 704(即图7所示的示例实施例中的反馈控制实体)起接收多播或广播服务的客户端的作用。从终端712、713的观点来看,对于多播或广播服务,BM-SC 704起提供服务的多播或广播服务器的作用。
因此,可能不存在从内容服务器701到移动终端712、713的端对端服务会话,但是服务供应被分成两个端对端对话一个在终端712、713和BM-SC704之间、以及一个在BM-SC 704和内容提供者701之间。
对于这两个会话,可以使用例如在传输和会话层上的不同协议。例如,在BM-SC 704和终端712、713之间的会话可使用RTP/UDP/IP(以及RTCP反馈),同时在内容提供者701和BM-SC 704之间的会话可使用相同的或不同的协议。因此,BM-SC 704可以提供协议转换机制的类似网关的方式进行操作。现在考虑在内容服务器701和BM-SC 704之间的会话,后者可因此向内容提供者701提供反馈。为了反映由从终端712、713接收的反馈所反映的接收统计信息,例如为不同的服务接收终端712、713所实现的QoS、到各个终端712、713的包损失速率,BM-SC 704可分析所接收的反馈,并可形成其总计或累计值,该总计或累计值反映了移动通信系统内的服务的接收统计信息。可以任意形式将该总计或累计值作为反馈提供给内容提供者701。例如,BM-SC 704可生成反映该总计或累计值的“标准”RTCP接收者报告、或者可在内容提供者701和BM-SC 704之间定义反馈供应的特定形式。
第二种可能性可在于,BM-SC 704将所接收的各个UE 712、713的反馈转发给内容提供者701。此外,在这个情况下,BM-SC 704可执行反馈数据的某些转换,这是因为在BM-SC 704和内容提供者701之间存在分离的连接/会话,其中甚至可以使用其他的协议。
无论如何,例如在基于所实现的QoS而为所接收的服务向用户收费的情况下,从BM-SC 704到内容提供者701的反馈供应可能是尤其可行的。
本发明的另一实施例涉及使用硬件和软件来实现上述各种实施例。应当认可,可使用计算设备(处理器),如例如通用目的处理器、数字信号处理器(DSP)、特定用途集成电路(ASIC)、现场可编程门阵列(FPGA)或其他可编程逻辑设备等来实现或执行各种上述方法、以及上述各种逻辑块、模块、电路。还可以由这些设备的组合来执行或体现本发明的各种实施例。另外,还可借助于由处理器执行或直接在硬件内的软件模块来实现本发明的各种实施例。此外,软件模块和硬件实现的组合是可能的。可将软件模块存储在任意类型的计算机可读存储介质上,例如RAM、EPROM、EEPROM、闪存、寄存器、硬盘、CD-ROM、DVD等。
就此而言,图10和图11分别示出了根据本发明的示例实施例的移动终端和反馈控制实体。
移动终端可以包括显示器1001,用于显示从反馈控制实体传送的数据;以及至少一个通信接口1004,使得能够接收多播或广播会话和传送反馈。另外,移动终端可包括处理器1002(计算设备),其可用于执行存储在计算机可读存储介质1003上的指令。另外,处理器1002可控制经由通信接口1004(多个)的通信,并执行概率试验以确定在终端处是否提供反馈等。
图11所示的反馈控制实体可包括处理器1101、计算机可读存储介质1102、以及至少一个通信接口1104。反馈控制实体可以是提供或转发多播或广播服务的UMTS网络中的BM-SC。反馈控制实体还可包括服务数据库1103,其存储或缓冲由多播或广播数据向用户提供的服务数据(例如,流)。此外,计算机可读介质1102还存储可由处理器1101执行的指令和其他数据。
例如,在计算机可读介质1102中存储的数据可包括相应服务的上下文信息,反馈控制实体基于该信息确定服务参与者的数量。在计算机可读介质1102上存储的指令还可使得反馈控制实体能够如上面的各个实施例中概述的那样、控制来自服务参与者的反馈供应。
权利要求
1.一种用于控制移动终端的反馈的传送的方法,该移动终端经由移动通信系统的空中接口接收由移动通信系统中的反馈控制实体传送或转发的多播或广播服务,该方法包括以下由移动终端执行的步骤经由单向下行链路信道、并使用不可靠的传输协议和会话协议接收该多播或广播服务,其中,该会话协议对接收多播或广播服务的终端的反馈供应进行配置,接收参数,其中移动终端基于该参数决定是否向所述反馈控制实体提供会话协议配置的反馈,基于所接收的参数,决定是否向反馈控制实体提供用于多播服务或广播的、会话协议配置的反馈,在决定提供会话协议配置的反馈的情况下,建立用于将反馈提供给所述反馈控制实体的载体,以及经由所述建立的载体,将会话协议配置的反馈传送给反馈控制实体,其中该反馈指示所述多播或广播服务的接收统计信息。
2.如权利要求1所述的方法,其中,在所述移动终端处接收的参数指示用于概率试验的概率值,所述移动终端基于该概率值决定是否提供会话协议配置的反馈。
3.如权利要求2所述的方法,其中,所述决定是否提供反馈包括使用所述接收的概率值在移动终端处执行概率试验;以及基于该试验的结果决定是否提供会话协议配置的反馈。
4.如权利要求2或3所述的方法,其中,所述概率试验是伯努利试验。
5.如权利要求1到4之一所述的方法,其中,经由提供所述多播或广播服务的多播或广播数据信道来接收所述参数。
6.如权利要求1到4之一所述的方法,其中,经由通告信道接收所述参数,其中在该通告信道上向潜在接收者通告多播或广播服务。
7.如权利要求6所述的方法,其中,使用可靠通信协议用于在通告信道上的数据传输。
8.如权利要求1到7之一所述的方法,其中,在所述移动终端处接收的参数还指示在其之前该参数有效的时间点。
9.如权利要求8所述的方法,还包括步骤在达到由所述参数所指示的时间点的情况下,所述移动终端释放已建立的、用于提供会话协议配置的反馈的载体。
10.如权利要求1到9之一所述的方法,还包括步骤接收重新配置参数,其中该重新配置参数更新先前从所述反馈控制实体接收的参数。
11.如权利要求10所述的方法,其中,该重新配置参数包括标记,该标记指示是否更新先前接收的参数的有效期,而且该方法还包括步骤基于这个标记更新先前接收的参数的有效期。
12.如权利要求11所述的方法,其中,仅仅在所述移动终端已建立了用于提供会话协议配置的反馈的载体时,才执行有效期的更新。
13.如权利要求10到12之一的方法,其中,所接收的重新配置参数包括标记,该标记指示是否要由所述移动终端执行有关提供会话协议配置的反馈的新决定,并且还包括步骤基于这个标记确定是否要由所述移动终端执行有关提供会话协议配置的反馈的新决定,以及如果要执行的话,则基于所接收的重新配置参数,决定是否将用于多播或广播服务的、会话协议配置的反馈提供给所述反馈控制实体,在决定提供会话协议配置的反馈的情况下,建立用于向反馈控制实体提供会话协议配置的反馈的载体,以及经由所述建立的载体,将指示所述多播或广播服务的接收统计信息的反馈传送给所述反馈控制实体。
14.一种用于由反馈控制实体控制多个移动终端的反馈的传送的方法,所述多个移动终端经由移动通信系统的空中接口接收多播或广播服务,该方法包括下述由该反馈控制实体执行的步骤经由单向下行链路信道、并使用到至少一个移动终端的不可靠传输协议和会话协议来传送或转发多播或广播服务的数据,其中该会话协议对接收多播或广播服务的终端的反馈供应进行配置,确定参数,该参数允许所述移动终端决定是否向所述反馈控制实体提供会话协议配置的反馈,向接收该多播或广播服务的所述多个移动终端中的至少一个子集传送所述参数,以及从已接收了所述参数的所述多个移动终端中的子集接收会话协议配置的反馈。
15.如权利要求14所述的方法,其中,基于由所述反馈控制实体维持的、或从移动通信系统中的网络实体接收的多播和广播服务的状态信息,来确定该参数。
16.如权利要求14或15所述的方法,其中,由所述反馈控制实体确定的参数指示用于概率试验的概率值,所述移动终端基于该概率值决定是否提供反馈。
17.如权利要求15或16所述的方法,其中,经由通告信道传送该参数,其中在该通告信道上向潜在接收者通告所述多播或广播服务。
18.如权利要求17所述的方法,其中使用可靠通信协议用于在该通告信道上的数据传输。
19.如权利要求14到18之一所述的方法,其中,该参数还指示在其之前参数有效的时间点。
20.如权利要求15到19之一所述的方法,还包括步骤基于该多播或广播服务的参与者数量来确定该概率值。
21.如权利要求20所述的方法,还包括步骤从由所述反馈控制实体维持或接收的状态信息中获得该多播或广播服务的参与者数量。
22.如权利要求21所述的方法,其中,该多播或广播服务的状态信息包含在所述反馈控制实体处维持的MBMS UE上下文或MBMS载体上下文内。
23.如权利要求21所述的方法,还包括步骤从维持MBMS UE上下文或MBMS载体上下文的移动通信网络的网络实体接收该多播或广播服务的状态信息。
24.如权利要求14到23之一所述的方法,还包括步骤从多播或广播服务器提供者接收该多播或广播服务的数据。
25.如权利要求24所述的方法,还包括步骤将在所述反馈实体处接收的、会话协议配置的反馈转发给所述多播或广播服务提供者。
26.如权利要求24或25所述的方法,其中,使用传输协议和会话协议向所述反馈控制实体传输该多播服务的数据,而且该方法还包括步骤在向所述移动终端传送或转发该多播或广播服务的数据之前,分别将传输协议和会话协议中的至少一个转换成另一个传输协议或会话协议。
27.如权利要求25或26所述的方法,其中,使用传输协议和会话协议向所述反馈控制实体传输用于多播服务的反馈,而且该方法还包括步骤在向所述多播或广播服务提供者转发反馈之前,分别将传输协议和会话协议中的至少一个转换成另一个传输协议或会话协议。
28.如权利要求24所述的方法,还包括步骤形成在所述反馈控制实体处接收的会话协议配置的反馈的总计,以及将所述会话协议配置的反馈的所述总计传送给所述多播或广播服务提供者。
29.如权利要求1到28之一所述的方法,其中,使用RTP协议提供该多播或广播服务,且使用RTCP协议提供反馈,其中向该RTCP协议消息分配用于提供该多播或广播服务的会话的可用带宽的一部分。
30.如权利要求29所述的方法,其中以该RTCP协议的接收者报告的形式来提供该会话协议配置的反馈。
31.如权利要求29或30所述的方法,其中,该参数还指示报告时间间隔和可用带宽,以便使用该RTCP协议提供会话协议配置的反馈。
32.如权利要求1到31之一所述的方法,其中,该参数包含在由该反馈控制实体传送的RTCP协议的发送者报告消息内。
33.一种经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务的移动终端,该移动终端包括接收器,用于经由单向下行链路信道、并使用不可靠传输协议和会话协议来接收该多播或广播服务,其中该会话协议对接收多播或广播服务的终端的反馈供应进行配置,其中该接收器还适用于接收参数,所述移动终端基于该参数决定是否向反馈控制实体提供会话协议配置的反馈,处理器,用于基于所接收的参数、决定是否向反馈控制实体提供用于该多播或广播服务的、会话协议配置的反馈;以及用于在决定提供会话协议配置的反馈的情况下,建立用于将会话协议配置的反馈提供给所述反馈控制实体的载体,以及传送器,用于经由所建立的载体,将指示所述多播或广播服务的接收统计信息的、会话协议配置的反馈传送给所述反馈控制实体。
34.如权利要求33所述的移动终端,还包括装置,其适于执行根据权利要求1到13或权利要求29到32之一的方法中的步骤。
35.一种反馈控制实体,用于控制多个移动终端的反馈的传送,所述多个移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务,该反馈控制实体包括传送器,用于经由单向下行链路信道、并使用不可靠的传输协议和会话协议,向至少一个移动终端传送或转发该多播或广播服务的数据,其中该会话协议对接收该多播或广播服务的终端的反馈供应进行配置,处理器,用于确定参数,该参数允许移动终端决定是否向所述反馈控制实体提供会话协议配置的反馈,其中,该传送器适于向接收该多播或广播服务的所述多个移动终端中的至少一个子集传送所述参数,以及接收器,用于从已接收了所述参数的所述多个移动终端的子集接收会话协议配置的反馈。
36.根据权利要求35的反馈控制实体,还包括装置,其适于执行根据权利要求14到32之一的方法中的步骤。
37.一种移动通信系统,包括根据权利要求35或36的反馈实体;以及至少一个根据权利要求33或34的移动终端,该移动通信系统用于使用单向下行链路信道和不可靠传输协议、经由空中接口从反馈控制实体接收多播或广播服务。
38.一种计算机可读介质,用于存储指令,当该指令由移动终端的处理器执行时,导致该处理器控制所述移动终端的反馈的传送,所述移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务,这通过以下步骤进行经由单向下行链路信道、并使用不可靠的传输协议和会话协议,在所述移动终端处接收该多播或广播服务,其中该会话协议对接收该多播或广播服务的终端的反馈供应进行配置,在所述移动终端处接收参数,所述移动终端基于该参数决定是否向所述反馈控制实体提供会话协议配置的反馈,由所述移动终端基于所接收的参数,决定是否向所述反馈控制实体提供用于该多播服务或广播的、会话协议配置的反馈,在决定提供会话协议配置的反馈的情况下,由所述移动终端建立用于将反馈提供给所述反馈控制实体的载体,以及经由所述建立的载体,将指示所述多播或广播服务的接收统计信息的反馈从所述移动终端传送到所述反馈控制实体。
39.如权利要求38所述的计算机可读介质,还存储有指令,当该指令由所述移动终端的处理器执行时,导致该处理器执行根据权利要求1到13或权利要求29到32之一的方法中的步骤。
40.一种计算机可读介质,用于存储指令,当该指令由移动终端的处理器执行时,导致该处理器控制移动终端的反馈的传送,所述移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务,这通过以下步骤完成经由单向下行链路信道、并使用不可靠的传输协议和会话协议,来从所述反馈控制实体向至少一个移动终端传送或转发该多播或广播服务的数据,其中该会话协议对接收该多播或广播服务的反馈供应进行配置,在所述反馈控制实体处确定参数,该参数允许移动终端决定是否向所述反馈控制实体提供会话协议配置的反馈,将所述参数从所述反馈控制实体传送到接收所述多播或广播服务的所述多个移动终端中的至少一个子集,以及在反馈控制实体处接收来自已接收了所述参数的所述多个移动终端的子集的、会话协议配置的反馈。
41.如权利要求40所述的计算机可读介质,还存储有指令,当该指令由所述反馈控制实体的处理器执行时,导致该处理器执行根据权利要求14到32之一的方法中的步骤。
全文摘要
本发明涉及用于控制移动终端的反馈的传送的方法,该移动终端经由移动通信系统的空中接口接收由反馈控制实体传送或转发的多播或广播服务,以及涉及使用该方法的移动终端和反馈控制实体。此外,还提供了包括反馈控制实体和接收多播或广播服务的移动终端的通信系统。为了使得经由维持端对端会话概念的空中接口而提供的多播或广播服务能够有可配置和自适应的反馈,本发明建议选择移动通信系统中、接收多播或广播服务的移动终端的子集,用于向反馈控制实体提供反馈。在本发明的一个实施例中,终端可基于概率试验决定是否提供反馈,其中该概念试验基于由反馈控制实体确定和提供的参数来执行。
文档编号H04L29/06GK1961529SQ200580011214
公开日2007年5月9日 申请日期2005年6月21日 优先权日2004年8月6日
发明者乔斯·雷伊, 伊维卡·里马克, 罗尔夫·哈肯伯格, 拉尔夫·贝克尔 申请人:松下电器产业株式会社
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1