发明内容
因此本发明的目的是为了克服上述问题。
通过独立权利要求的主题来解决该目的。优势实施例是从属处理要求的主题。
本发明的一个关键方面是向接收多播或广播服务的移动终端提供关于个体(分层的/可替换的/补充的)载体的关系的信息以便利于成功的服务接收。可以在对于多播或广播服务的服务描述信息中提供该载体的关系,该服务描述消息指示关联于多播或广播服务的载体和多个载体之间的预定载体组合。
每个预定载体组合可以包括所述多个载体的至少一个,且每个预定载体组合可以以预定的服务质量参数提供多播或广播服务。基于服务描述信息,移动终端可以确定在从网络中所接收的至少一个通知中所指示的至少一个载体是否对应于所述预定载体组合之一,并可以适当地基于该确定结果来动作。
另外,多播或广播服务的每个载波包括服务的一个包流(例如音频或视频)。但是,使用单个载体服务提供多于一个包流(例如音频或视频)也是可能的。
根据上述考虑,本发明的实施例涉及用于经由移动通信***的无线接入网向移动终端的用户提供多播或广播服务的方法。在该实施例中,该多播或广播服务被关联于用于提供多播或广播服务的多个载体。
移动终端可以接收对于多播或广播服务的服务描述信息,其中该服务描述信息指示被关联于多播或广播服务的多个载体。另外,服务描述信息指示在多个载体之间的预定载体组合,每个预定载体组合包括所述多个载体的至少一个,且每个预定载体组合以预定的服务质量参数提供多播或广播服务。
接下来,移动终端可以激活被关联于多播或广播服务的多个载体。应该注意,载体的激活仅指示移动终端对被激活的相应载体的兴趣,即指示移动终端对多播或广播服务的兴趣。响应多个载体的激活,移动终端可以接收指示经由无线接入网的空中接口多播或广播的多个载体的至少一个载体的服务通知信息。
基于先前由终端接收的服务描述信息,移动终端可以确定在所接收的服务通知信息中所指示的至少一个载体是否对应于所述预定载体组合之一。如果是这种情况,则移动终端可以经由在服务通知信息中所指示的所述至少一个载体接收多播或广播服务的内容数据,并向移动终端的用户提供该内容数据。
在本发明的示例实施例中,多播或广播服务是经由UMTS网络所提供的MBMS用户服务。
由于得知提供多播或广播服务的“所允许的”载体组合,移动终端还可以检测由于通知信息没有指示“所允许的”载体组合而检测到差错的状况。关于此,如果在所接收的服务通知信息中所指示的至少一个载体不对应于预定载体组合之一,移动终端可以向移动终端的用户提供差错消息,
可替换地,如果在所接收的服务通知信息中所指示的至少一个载体不对应于所述预定载体组合之一,则移动终端可以在向移动终端的用户提供多播或广播服务的内容数据之前等待接收进一步服务通知信息,且如果在预定时间范围内没有接收到进一步服务通知,则可以向移动终端的用户提供差错消息。
因此,移动终端可以是处理其中在从网络中提供了对于所提供的服务级别质量的不足数量的载体的情况的实现例程。
在本发明的再一实施例中,服务通知信息还指示由移动终端接收至少一个载体所需的参数。因此,除了标识在其上提供了多播或广播服务的内容数据的各个载体以外,终端还可以被通知有关使之调适于各个所指定的载体的相应载体的参数。
本发明的另一实施例预见以诸如XML的标记语言来描述服务描述信息的内容。在本实施例的变体中,服务描述信息包括定义预定载体组合的标签。在另一变体中,服务描述信息(还)可以包括指示预定载体组合之间的关系的标签。
另外,服务描述信息还可以定义每个预定载体组合的优先权。该组合优先权的定义可以关于对于可替换的载体组合的服务质量需求,指示所期望的载体组合的顺序。对于分层的载体组合,优先权可以指示层的顺序。这使得移动终端能够全面地理解用户服务语义。
在再一实施例中,预见了在至少一个通知消息中提供服务通知信息。为了在无线接入网中有效地分发服务通知信息,还可以预见经由广播无线信道提供通知信息。
本发明的另一实施例涉及控制无线接入网的空中接口上的无线资源的无线接入网的网络实体的操作。在UMTS网络中,该网络实体普遍地被称为RNC(无线网络控制器)。但是,要注意,网络元素还可以是控制无线资源的无线接入网的任何其他网络元素。例如,在增强的RAN架构中,该网络实体可以对应于负责无线资源控制(RRC)的节点B。
本实施例涉及经由移动通信***的无线接入网向移动终端提供多播或广播服务的方法。该多播或广播服务还是被关联于用于提供多播或广播服务的多个载体。网络实体可以首先接收来自于移动通信网的核心网的网络实体的多播或广播服务的服务语境信息。该服务语境信息指示被关联于多播或广播服务的多个载体。另外,服务语境信息指示在多个载体之间的预定载体组合,其中每个预定载体组合可以包括所述多个载体的至少一个,且以预定的服务质量参数提供多播或广播服务。
如介绍所概述的,网络实体可以包括服务质量管理功能,且可以从其(从其中)获得指示对于通过其已经接收了移动终端的服务请求的网络实体的接口上的下游传输可用的服务质量的服务质量约束。
通过得知对于(如服务语境信息所提供的)每个预定载体组合的预定的服务质量参数,现在网络实体可以从在从服务质量管理功能所获得的质量约束内可提供的所述预定载体组合中选择载体组合。
接下来,网络实体可以宣布在所选载体上的多播或广播服务的传输。因此,网络实体可以例如向移动终端传输指示所选载体组合的服务通知信息。另外,网络实体可以继续经由所选载体组合的至少一个载体向移动终端传输多播或广播服务的内容数据。
在本发明的再一实施例中,网络元素还可以为经由所选载体组合的载体进行的内容数据的传输分配无线资源。
在上述实施例的变体中,可以在已经例如在会话开始消息中接收了关于开始多播或广播服务的指示之后进行资源保留以及通知信息的传输。
在本发明的另一实施例中,网络实体还可以向移动终端中继对于多播或广播服务的服务描述信息,其中服务描述信息指示被关联于多播或广播服务的多个载体。该服务描述信息还指示在多个载体之间的预定载体组合。每个预定载体组合可以包括所述多个载体的至少一个,且每个预定载体组合可以以预定的服务质量参数提供多播或广播服务。
另外,本发明的实施例预见到网络实体使用网络实体的服务质量管理功能来监控指示对于通过其已经接收了移动终端的服务请求的网络实体的接口的下游传输可用的服务质量的服务质量约束,并确定所监视的服务质量约束是否仍然允许向移动终端提供所选载体组合。
如果不是这种情况,则网络实体可以基于对于被包括在服务语境信息中的每个预定载体组合的预定的服务质量参数,从在从服务质量管理功能所获得的质量约束内可提供的所述预定载体组合中选择另一载体组合。网络实体可以向移动终端传输指示所选其他载体组合的服务通知信息,且还可以经由所述所选其他载体组合的至少一个载体来向移动终端传输多播或广播服务的内容数据。
在本实施例的变体中,网络实体还可以为经由所述所选其他载体组合进行的内容数据的传输分配无线资源,并可以释放先前被分配给所述多播和广播服务的内容数据的传输的无线资源。
在本发明的再一实施例中,服务描述信息被包括在分开地被提供给移动终端的用户服务描述和所述多个载体的每个载体的服务描述中。
在变体中,用户服务描述指示被关联于所述载体的每个服务描述的URI,并基于URI定义预定载体组合,且对于所述多个载体的相应载体的每个服务描述包括相应载体的临时标识符。另外,在另一变体中,服务通知信息包括被包括在所述所选载体组合中的每个载体的临时标识符。
本发明的另一实施例涉及用于向用户提供多播或广播服务的移动终端。经由移动通信***的无线接入网来传输该多播或广播服务,该多播或广播服务被关联于用于提供多播或广播服务的多个载体。
根据本实施例,移动终端可以包括用于接收对于多播或广播服务的服务描述信息的接收器。该服务描述信息指示被关联于多播或广播服务的多个载体。另外,该服务描述信息指示在多个载体之间的预定载体组合。每个预定载体组合可以包括所述多个载体的至少一个。另外每个预定载体组合可以以预定的服务质量参数提供多播或广播服务。
移动终端的接收器还可以适于响应于多个载体的激活而接收服务通知信息。该服务通知信息指示经由无线接入网的空中接口进行多播或广播的所述多个载体的至少一个载体。
另外,移动终端可以包括用于激活被关联于多播或广播服务的多个载体的传输器,和用于确定在所接收的服务通知信息中所指示的至少一个载体是否对应于所述预定的载体组合之一的处理装置。
移动终端的接收器可以被适应于,如果处理装置已经确定在所接收的服务通知信息中所指示的至少一个载体对应于所述预定载体组合之一,则经由在服务通知信息中所指示的所述至少一个载体来接收多播或广播服务的内容数据。
另外,所包括的移动终端适于向移动终端的用户提供该内容数据。
在再一实施例中,移动终端还包括适应于执行根据上述各种实施例及其变体之一的向移动终端的用户提供多播或广播服务的方法的步骤的装置。
本发明的另一实施例涉及用于经由移动通信***的无线接入网向移动终端的用户提供多播或广播服务的网络实体。如上述实施例中的那样,该多播或广播服务被关联于用于提供多播或广播服务的多个载体。该网络实体可以被置于无线接入网中,并可以适于控制无线接入网的空中接口上的无线资源。
网络实体可以包括用于接收来自于移动通信网的核心网的网络实体的多播或广播服务的服务语境信息的接收器。该服务语境信息指示被关联于多播或广播服务的多个载体以及在多个载体之间的预定载体组合。每个预定载体组合包括所述多个载体的至少一个,且可以以预定的服务质量参数提供多播或广播服务。
另外,网络实体可以包括处理装置,其用于从网络实体的服务质量管理功能获得指示对于在通过其已经接收了移动终端的服务请求的网络实体的接口上的下游传输可用的服务质量的服务质量约束。该处理装置可以被适应于基于对于被包括在服务语境信息中的每个预定载体组合的预定的服务质量参数,从在从服务质量管理功能所获得的质量约束内可提供的所述预定载体组合中选择载体组合。
另外,网络实体包括传输器,其用于向移动终端传输指示所选载体组合的服务通知信息,以及用于经由所述所选载体组合的至少一个载体来向移动终端传输多播或广播服务的内容数据。
在再一实施例中,网络实体还包括适应于执行根据上述各种实施例及其变体之一的向移动终端提供多播或广播服务的方法步骤的装置。
本发明的另一实施例涉及一种存储指令的计算机可读介质,所述指令当由移动终端的处理器执行时,使得经由移动通信***的无线接入网向移动终端的用户提供多播或广播服务。该多播或广播服务可以被关联于用于提供多播或广播服务的多个载体。
可以使得移动终端通过接收对于多播或广播服务的服务描述信息来接收多播或广播服务,其中该服务描述信息指示被关联于多播或广播服务的多个载体,其中该服务描述信息还指示在多个载体之间的预定载体组合,每个预定载体组合包括所述多个载体的至少一个,且每个预定载体组合以预定的服务质量参数提供多播或广播服务。
指令还可以使得移动终端通过下述操作来接收多播或广播服务:激活被关联于多播或广播服务的多个载体,响应于多个载体的激活来接收服务通知信息,其中服务通知信息指示经由无线接入网的空中接口进行多播或广播的所述多个载体的至少一个载体,且确定在所接收的服务通知信息中所指示的至少一个载体是否对应于所述预定的载体组合之一。如果是,指令可以使得移动终端经由在服务通知信息中所指示的所述至少一个载体接收多播或广播服务的内容数据,并向移动终端的用户提供该内容数据。
在再一实施例中,计算机可读介质还存储指令,所述指令当由移动终端的处理器执行时,使得移动终端执行根据各种实施例及其变体之一的向移动终端的用户提供多播或广播服务的步骤方法。
本发明的另一实施例提供一种存储指令的计算机可读介质,所述指令当由网络实体的处理器执行时,使得网络实体经由移动通信***的无线接入网向移动终端提供多播或广播服务。该多播或广播服务可以被关联于用于提供多播或广播服务的多个载体。另外,该网络实体可以被置于无线接入网中,并控制无线接入网的空中接口上的无线资源。指令,当由处理器执行时可以使得网络实体接收来自于移动通信网的核心网的网络实体的多播或广播服务的服务语境信息,其中服务语境信息指示被关联于多播或广播服务的多个载体,且其中服务语境信息还指示在多个载体之间的预定载体组合。每个预定载体组合可以包括所述多个载体的至少一个,且每个预定载体组合可以以预定的服务质量参数提供多播或广播服务。
另外,指令可以使得网络实体从网络实体的服务质量管理功能中获得指示对于在通过其已经接收了移动终端的服务请求的网络实体的接口上进行下游传输可用的服务质量的服务质量约束,并基于对于被包括在服务语境信息中的每个预定载体组合的预定的服务质量参数,从在从服务质量管理功能所获得的质量约束内可提供的所述预定载体组合中选择载体组合。
另外,指令可以使得网络实体向移动终端传输指示所选载体组合的服务通知信息,以及经由所述所选载体组合的至少一个载体来向移动终端传输多播或广播服务的内容数据。
在再一实施例中,计算机可读介质还存储指令,当由网络实体的处理器执行时,使得网络实体执行根据上述各种实施例及其变体之一的向移动终端提供多播或广播服务的方法步骤。
具体实施方式
以下几段将描述本发明的各种实施例。仅用于示例目的,多数实施例是关于UMTS通信***来概述的,并且以下所使用的术语主要涉及UMTS术语。但是,关于UMTS架构的所使用的术语和实施例的描述并在旨在将本发明的原理和思想局限于这种***。
同样,以上在技术背景部分中给出的具体说明仅仅是为了更好地理解以下所描述的大部分UMTS具体示例实施例,而不应被理解为将本发明局限于移动通信网络中的处理和功能的所述具体实现。
还要注意,主要关于带宽需求和QoS适应(adaptation)描述本发明。但是,在服务描述信息中的QoS区分(differentiation)和适应还可以被应用于任何其它QoS参数,例如丢失率,或参数的组合。
为了使能利用传输分层的、补充的、可替换的服务流的多个载体的用户服务的供应,MBMS传输服务和MBMS用户服务被增强。增强的多播/广播服务的设计的重要的方面是覆盖对于内容适应的广泛可能性。例如,可以覆盖可用的适应的媒体编解码器,且可以提供对于未来扩展的框架。
克服当前MBMS架构的局限的一种可能的手段可以是适应的媒体编解码器的使用。适应的媒体编解码器的示例有诸如MPEG2或MPEG4的分层编解码器。这些编解码器典型地将媒体信息编码成(至少)两个或更个层,从而最低层是最重要的层。之后的(更高的)层取决于先前的(更低的)层。
内容还可以例如使用允许提供具有不同带宽需求或不同错误恢复(resilience)的可替换流的MPEG-1编码器,被编码成几个独立的表示。
适应的媒体编解码器的另一示例是多描述编解码器(MDC)的家族。在这种编码中,内容被编码成几个补充层,即基本层的概念和对先前层的依赖消失了。特别地,接收到的MDC-编码的包数量越高,则所获得的质量越高。
进一步设计考虑是RAN(Radio Access Network,无线接入网)资源的可用性。不失普遍性地,RAN可以被典型地视为决定性(critical)***,其中由于不足的无线资源,传输载体的建立可能表现出瓶颈。因此,增强的多播/广播服务架构应当考虑对于在RNC(Radio Network Controller,无线网络控制器)中的改变的RAN资源时做出反应的适应性功能。
由于UE的移动性,分布树在正在进行的会话期间可能改变。因此,增强多播/广播服务架构可以允许在会话开始和会话期间、例如切换时都能适应。
对于增强多播/广播服务架构的另一个可能的设计方面是提供对于在网络和无线组件中改变的状况的适应。MBMS数据可以通过可以穿越许多RNC和许多SGSN的MBMS分布树来被分发给多个用户。
从而,从用户视角来说的组成单个MBMS服务的不同媒体组件(component)可以在单独的GTP(GPRS Tunneling Protocol,GPRS隧道协议)隧道(GGSN<->SGSN,SGSN<->RNC-见图1)和无线载体(RNC<->UE)上提供,由此使能每个组件的QoS区分。因此,增强的多播/广播服务架构可以解决在无线接入和核心网两者中的QoS问题。
为了实现某网络QoS,可以从用户服务(例如,多播或广播服务)的源到目的建立具有清楚定义的特征和功能的载体服务(例如UMTS/MBMS载体)。载体服务包括使能协定的QoS的供应的所有方面。这些方面是控制信令、用户层面传输和QoS管理功能及其它。图2示出了UMTS载体服务分层QoS架构。在具体层上的每个载体服务使用下面层所提供的服务来供给其个别服务。
为指定、建立、修改和维持具有具体QoS的UMTS载体服务所需的节点(GGSN、SGSN、RNC等等)之间功能的具体关系可以是特别实现的。这意味着,可以使用诸如DiffServ、IntServ(见Braden等.,“Integrated Services in theInternet Architecture:an Overview”,RFC1633,1994)、RSVP或MPLS的各种技术。
考虑UMTS的示例,对UMTS实体的这些功能的分配意味着,这些实体可以推行(enforce)针对UMTS载体服务协商的QoS委托。这些功能的具体实现可以是取决于实现的,且仅必须维持指定的QoS特征。所有UMTS实体的QoS管理功能一起可以保证在UMTS载体服务的接入点之间所协商的服务的供应。
对于建立新的增强的多播/广播服务架构,如3GPP TS 23.107:“TechnicalSpecification Group Services and System Aspects;Quality of Service(QoS)concept and architecture(Release 6)”(见版本6.1.0,2004年3月)的部分6.2.1.1所述的服务管理器的功能可能引发特定的兴趣。服务管理器协调控制层面(例如MBMS载体语境)的功能,以建立、修改和维持其负责的服务(见图3)。另外,它给所有的用户层面QoS管理功能提供相关属性(例如,受保护的比特率、最大比特率、最大包大小、丢失率等等)。
服务管理器还可以向其它实例供给(offer)服务(例如,MBMS载体语境管理功能),可以利用端服务管理器(peer service manager)发信令,并可以使用由其它实例提供的服务。服务管理器还可以进行属性翻译(例如,应用包丢失率到RLC SDU丢失率、SDU丢失率到层1/层2块差错率)来请求更低层的服务。另外,它可以询问其它控制功能来接收对于服务提供的许可。
因此,可以假设,提供了这种底层基础结构,给出了MBMS载体和QoS管理功能之间的交互。这允许使得由于关于用户如何使用可用资源的不确定性和其他不可预见的事件而固有地变化的网络(CN)和RAN两者的状况对于MBMS用户服务的语境管理功能变为已知。
例如,后者的示例性例子是典型的快速拥挤(flash-crowd)现象,其中特定服务器和相关的网络段被用户请求所超载。另一个例子可以是在服务传递路径中的节点的故障或对于多少用户将加入如3GPP MBMS的多播服务的不确定性。
另外,当设计增强多播/广播服务架构时的另一方面是使能多播/广播服务的网络驱动自适应(network-driven adaptation)。在目前MBMS架构中,MBMS用户将典型地有少量机会或没有机会与服务器(例如BM-SC)协商会话传递的细节。这里是网络驱动适应变得重要之处。
QoS架构被扩展,以便用户服务的流/载体的区分在沿着MBMS用户服务的分布树的网络节点(网络实体)上变得可能。以此方式,对于改变的资源、异构终端和不同的网络组件的网络驱动适应是可能的。
根据这种手段,引入了MBMS用户服务语境形式的附加状态信息。MBMS用户服务语境存储对于在服务中所包括的载体的引用。另外,载体关系信息可以被存储,其定义载体之间关系,以便适应节点可以根据下行链路能力例如下游QoS约束来进行载体的激活/灭活(deactivation)。
出于示例目的的下面所考虑的MBMS用户服务的时间线(timeline)如下:在数据层面,只要任何中间网络实体满足QoS需求(约束),所请求的多媒体广播或多播服务的服务内容数据(典型地以可选/可替换/补充流的形式)在它们的MBMS载体上被向下游转发。如果例如中间节点可能不转发属于用户服务的所有载体,则它通过选择可用载体服务的子集来过滤载体,以便使得全部的会话流适应可用的QoS。中继(relay)的语境信息(例如,在MBMS载体语境和新定义的MBMS用户服务语境内的)使得网络节点能够进行这种过滤。可以依据请求向分布树下游传播为建立MBMS载体语境和新定义的MBMS用户服务语境所必需的信息。
语境信息还可以允许网络反应于突发容量变化(升/降级),因为节点意识到所有选择,即可用于服务传送的可能的载体组合。中继的语境信息描述了对于服务配置的选择,即服务语义,且它可以例如被存储在MBMS用户服务语境中。服务语义及其(分层的、可替换的、补充的)相互关系,在可替换的流的情况下可能的流组合等等。进一步设计可能性可以是向下游转发关于丢弃和未丢弃流的状态的信息。
另外,还应该注意,为了允许对突发容量变化的适应,可以考虑流的QoS轮廓。该信息可以容易地从包括对于每个所建立的载体的QoS轮廓的适应节点中存在的MBMS载体语境中得到。可替换地,还可以考虑在服务语义中以信令通知该信息,并在用户服务语境中存储它们。
不失普遍性,无线接入网可能被视为3GPP架构中的瓶颈,且核心网可能被考虑为过度供应(over-provision)。应该注意,这里描述的概念不局限于仅在该假设下可用。因此,过滤器实体(即“适应节点”)可以被示例在RNC中,因为RNC知道在其自己的无线域中的可用资源。这使得它们适合于该功能。
通常,在RAN或CN中的任何网络实体可以作为过滤器实体。但是,选择下面的实体作为过滤器实体可能是可行的:该网络实体知道在通向接收所请求服务的移动终端的下游链路上的资源。
在适应网络实体处过滤器的初始化可以使用控制消息来触发。因此,可以使用MBMS过程来把服务语义向下游以信令发送到相应的RNC。服务语义可以被理解为指的是关于传递用户服务的流、它们的相互关系和它们的QoS轮廓的信息。
例如,在指定的MBMS信令消息的可选字段中提供反映服务语义的这些信息。另外,诸如GGSN和SGSN的中间节点可以不需要解析和处理消息扩展的值,如果它们不理解它们的话。它们可以仅向下游转发它们。
另外,以上概述的适应的QoS概念使能支持例如分层、可替换的或补充的对给定内容编码的不同范例的服务的供应。这是用于提供MBMS服务的新颖的手段,这样,它还没有被反映在当前架构中。目前,仅定义了用于信令通知和管理必要MBMS语境信息的占位符(placeholder)被定义了,但没有定义如何实现不同的可能性。因此,用于存储服务语义(例如,关于属于服务的载体、它们的相互关系、它们的QoS轮廓等等的信息)的MBMS用户服务语境的使用与当前MBMS架构兼容。
本发明假设诸如MBMS用户服务的多播或广播服务由多个载体组成,该多个载体可以是可替换的、补充的或分层的。相应地,每个载体被关联于需要满足的预定QoS约束,以便向UE传送各个载体。另外,关联于各个载体的QoS参数不仅描述了用于向UE传递载体所需的比特率,还描述了它的内容(例如,由载体承载的一个或多个流的保证的比特率、最大比特率、最大包大小、丢失率等等)。
因此,具体QoS关系存在于MBMS载体(或载体组)之间,例如可替换的、补充的或分层关系。如上述,在3G网络中自治地使MBMS用户服务的QoS适应。在RAN或CN(“适应节点”)中的QoS决定点基于从适应节点中所实现的服务质量管理功能中获得的服务质量约束根据下游可用资源来选择/丢弃部分MBMS载体。
UE不知道在RAN和/或CN中的这种选择/丢弃处理,因此其被假设接收如MBMS用户服务描述中所指示的MBMS用户服务的所有载体。因此,所丢弃的载体将被传统的UE视为差错情况。因此,UE不知道它们实际上在一个可用的QoS级别上接收服务。因此,UE不能正确地接收MBMS用户服务。
为了更好地理解该问题,提供了下列示例。MBMS用户服务被假设包含两个MBMS载体,其呈现服务可替换性,即每个载体将传递相同的但以不同质量级编码的内容(例如在两个不同的比特率上编码的音频-视频流)。另外,可能存在针对每个载体配置的关联的传递后过程(post-delivery procedure)(例如内容接收报告)。因为,MBMS载体呈现服务可替换性,仅一个被意图用于被传递给UE。
UE接收MBMS用户服务描述,其包括了对于两个MBMS载体的描述。根据普通行为,它请求两个MBMS载体。问题在于,UE不知道MBMS载体是可替换的,且它仅需对于它们之一保留资源。因此,它必须为两个载体保留资源(例如流缓冲器),这导致UE中的资源(例如,存储器空间)的浪费。另外,UE可能对于两个载体都开始传送后过程。但是,网络仅对接收对于其被实际地传递给UE的服务(载体)的传递后过程感兴趣。这导致了网络资源的浪费。
本发明的实施例的关键方面是引入了新的成组(grouping)描述作为标准MBMS用户服务描述的扩展。MBMS用户服务描述是基于XML的。新元素描述了在MBMS用户服务中的各个MBMS载体之间的成组关系。
通过这种扩展的描述,UE知道MBMS载体成组,且它们知道可以接收非所有的载体。因此,UE准备仅接收所有MBMS载体的子集。因此,未接收到MBMS载体不会即可被视为差错情况。另一方面,UE能够确定是否接收了完整的组,这使得UE能够认识到MBMS用户服务是否被正确地接收。
下列行示出了传统MBMS用户服务描述的示例XML图解:
<?xml version=″1.0″encoding=″UTF-8″?>
<xs:schema elementFormDefault=″qualified″
targetNamespace=″urn:3gpp:metadata:2004:userservicedescription″
xmlns=″urn:3gpp:metadata:2004:userservicedescription″
xmlns:xs=″http://www.w3.org/2001/XMLSchema″>
<xs:element name=″userServiceDescription″
type=″userServiceDescriptionType″/>
<xs:complexType name=″userServiceDcscriptionType″>
<xs:sequence>
<xs:element name=″name″type=″nameType″
minOccurs=″0″maxOccurs=″unbounded″/>
<xs:element name=″serviceLanguage″type=″xs:language″
minOccurs=″0″maxOccurs=″unbounded″/>
<xs:element name=″deliveryMethod″
type=″deliveryMethodType″
maxOccurs=″unbounded″/>
</xs:sequence>
<xs:attribute name=″serviceId″type=″xs:anyURI″
use=″required″/>
</xs:complexType>
<xs:complexType name=″deliveryMethodType″>
<xs:attribute name=″associatedProcedureDescriptionURI″
type=″xs:anyURI″use=″optional″/>
<xs:attribute name=″protectionDescriptionURI″
type=″xs:anyURI″use=″optlonal″/>
<xs:attribute name=″sessionDescriptionURI″
type=″xs:anyURI″use=″required″/>
</xs:complexType>
<xs:complexType name=″nameType″>
<xs:simpleContent>
<xs:extension base=″xs:string″>
<xs:attribute name=″lang″type=″xs:language″
use=″optional″/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
userServiceDescription是包括所有MBMS用户服务描述信息的顶级元素。最重要的是,deliveryMethod元素集合关于MBMS用户服务的具体MBMS载体的所有信息。描述MBMS载体细节的所有信息被包含在其他专用元数据描述(同样被称为媒体和会话描述)中。那些是被在deliveryMethod元素中的它们唯一的URI所引用的。另外,(按照它们关联的URI/媒体或会话描述)列于deliveryMethod元素中的每个MBMS载体具有关联于相应载体的TMGI(Temporary Multicast Group Identifier,临时多播组标识符)。关于传输和媒体编码参数,这些信息被包含在单独的SDP描述中,其在deliveryMethod元素的sessionDescriptionURI属性中被指定。
下列行图示了在上述XML规范的deliveryMethod元素内遵守的专用元数据描述的示例内容。
v=0
o=user123 2890844526 2890842807 IN IP6
2201:056D::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=mbms-mode:broadcast 1234
a=FEC-declaration:0 encoding-id=128;instance-id=0
a=source-filter:incl IN IP6*
2001:210:1:2:240:96FF:FE25:8EC9
a=flutc-toi:3
m=application 12345 FLUTE/UDP 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1
a=lang:EN
a=FEC:0
对于本发明的一个实施例相关的行是
a=mbms-mode:broadcast 1234
其中,定义了,MBMS用户服务是以广播模式提供的,并且是利用具有TMGI 1234的载体提供的。基于由MBMS用户服务描述所引用的服务描述中的该TMGI,UE可以把MBMS用户服务描述中的每个URI与在所引用的服务描述中所描述的提供内容数据的载体的TMGI相关联。因此,如将在下面描述的,对于其在UE处接收MBMS通知的载体的TMGI允许UE确定由它们的TMGI所标识的载体是否组成“有效”载体组合。应当注意,对于多播模式的MBMS服务来说,所引用的服务描述可以不指示载体的TMGI。
下列行示出根据本发明的示例实施例、允许支持MBMS载体的成组的标准MBMS用户服务描述的XML图解的扩展(粗体行指示所应用的扩展):
<?xml version=″1.0″encoding=″UTF-8″?>
<xs:schema elementFormDefault=″qualified″
targetNamespace=″urn:3gpp:metadata:2004:userservicedescription″
xmlns=″urn:3gpp:metadata:2004:userservicedescription″
xmlns:xs=″http://www.w3.org/2001/XMLSchema″>
<xs:element name=″userServiceDescription″
type=″userServiceDescriptionType″/>
<xs:complexType name=″userServiceDescriptionType″>
<xs:sequence>
<xs:element name=″name″type=″nameType″
minOccurs=″0″maxOccurs=″unbounded″/>
<xs:element name=″serviceLanguage″type=″xs:language″
minOccurs=″0″maxOccurs=″unbounded″/>
<xs:element name=″deliveryMethod″
type=″deliveryMethodType″
maxOccurs=″unbounded″/>
<xs:element name=″qosGroup″type=″qosGroupType″
minOccurs=″0″maxOccurs=″unbounded″/>
</xs:sequence>
<xs:attribute name=″serviceId″type=″xs:anyURI″
use=″required″/>
</xs:complexType>
<xs:complexType name=″deliveryMethodType″>
<xs:attribute name=″associatedProcedureDescriptionURI″
type=″xs:anyURI″use=″optional″/>
<xs:attribute name=″protectionDescriptionURI″
type=″xs:anyURI″use=″optional″/>
<xs:attribute name=″sessionDescriptionURI″
type=″xs:anyURI″use=″required″/>
</xs:complexType>
<xs:complexType name=″nameType″>
<xs:simpleContent>
<xs:extension base=″xs:string″>
<xs:attribute name=″lang″type=″xs:language″
use=″optional″/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name=″qosGroupType″>
<xs:sequence> </--re-uses sessionDescriptionURI
attribute from deliveryMethod element-->
<xs:element name=″qosGroupItem″type=″xs:anyURI″
maxOccurs=″unbounded″/>
</xs:sequence>
<xs:attribute name=″qosItem″type=″xs:anyURI″
use=″optional″/>
</xs:complexType>
</xs:schema>
两个新元素被引入来描述各个MBMS载体之间的成组关系。这些是qosGroup元素,其包含一个或多个qosGroupItem元素。qosGroup元素被定义在与deliveryMethod元素相同的级别上。在qosGroup中的qosGroupItem定义了MBMS载体的组。与在deliveryMethod元素的sessionDescriptionURI属性中所使用的URI相同的URI,唯一地标识个体MBMS载体。
因此,在由UE接收的通知信息内包括的TMGI可以用于确定是否由网络提供了根据MBMS用户服务描述中的定义的载体组。
接下来,下面示出了根据本发明的另一实施例的标准MBMS用户服务描述的XML图解的另一示例扩展(粗体行指示所应用的扩展):
<?xml version=″1.0″encoding=″UTF-8″?>
<xs:schema elementFormDefault=″qualified″
targetNamespace=″urn:3gpp:metadata:2004:userservicedescription″
xmlns=″urn:3gpp:metadata:2004:userservicedescription″
xmlns:xs=″http://www.w3.org/2001/XMLSchema″>
<xs:element name=″userServiceDescription″
type=″userServiceDescriptionType″/>
<xs:complexType name=″userServiceDescriptionType″>
<xs:sequence>
<xs:element name=″name″type=″nameType″
minOccurs=″0″maxOccurs=″unbounded″/>
<xs:element name=″serviceLanguage″type=″xs:language″
minOccurs=″0″maxOccurs=″unbounded″/>
<xs:element name=″deliveryMethod″
type=″deliveryMethodType″
maxOccurs=″unbounded″/>
<xs:element name=″qosRelation″type=″qosRelationType″
minOccurs=″0″maxOccurs=″unbounded″/>
</xs:sequence>
<xs:attribute name=″serviceId″type=″xs:anyURI″
use=″required″/>
</xs:complexType>
<xs:complexType name=″deliveryMethodType″>
<xs:attribute name=″associatedProcedureDescriptionURI″
type=″xs:anyURI″use=″optional″/>
<xs:attribute name=″protectionDescriptionURI″
type=″xs:anyURI″use=″optional″/>
<xs:attribute name=″sessionDescriptionURI″
type=″xs:anyURI″use=″required″/>
</xs:complexType>
<xs:complexType name=″nameType″>
<xs:simpleContent>
<xs:extension base=″xs:string″>
<xs:attribute name=″lang″type=″xs:language″
use=″optional″/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name=″qosRelationType″>
<xs:sequence>
<xs:element name=″qosGroup″type=″qosGroupType″
maxOccurs=″unbounded″/>
</xs:sequence>
<xs:attribute name=″discrete″type=″xs:boolean″
use=″optional″/>
</xs:complexType>
<xs:complexType name=″qosGroupType″>
<xs:sequence> </-- re-uses sessionDescriptionURI
attribute from deliveryMethod element -->
<xs:element name=″qosGroupItem″type=″xs:anyURI″
maxOccurs=″unbounded″/>
</xs:sequence>
<xs:attribute name=″qosPrio″type=″xs:positiveInteger″
use=″optional″/>
<xs:attribute name=″qosItem″type=″xs:anyURI″
use=″optional″/>
</xs:complexType>
</xs:schema>
该扩展可用于指示描述MBMS载体组关系。
有三个新元素来描述MBMS载体组以及它们之间的关系。被定义在与deliveryMethod元素相同的级别上的qosRelation元素描述载体组之间的普遍关系。那些组能够表现离散的可替换性,即它们之一被排他地选择,或依赖于彼此,例如表现相同媒体的层。qosRelation的子元素是qosGroup元素,其指定属于区别的组的MBMS载体,如以上示例的XML定义所述的那样。
本实施例中提出的扩展是qosGroup元素的qosPrio属性,其是为表达所定义的载体组的顺序所需的。该顺序的确切意思依赖于qosRealtion元素。它或者指定替换的顺序,例如从最佳到最差替换,或者它指定依赖组的顺序,例如基础层和增强层。
更普遍地,MBMS用户服务描述可以被定义为描述被传递给UE的服务的元数据的集合。接收该服务的所有必需的参数都被包含在该描述中。由个别DSP描述来描述传输服务内容的MBMS载体。这些经由URI在deliveryMethod元素中的MBMS用户服务描述中被引用。因此,每个deliveryMethod元素代表被包含在MBMS用户服务中的单独的MBMS载体。引用SDP描述的URI唯一地标识该MBMS载体。
被称为qosGroup的MBMS用户服务描述中的新元素将相关的MBMS载体成组在一起。被包含在这种qosGroup元素中的每个MBMS载体属于相同的载体组。那些被指定在新的qosGroupItem元素中,其是qosGroup的子元素。每个MBMS载体的SDP描述的URI被用作载体标识符。
以下XML示例图示了依照上示的本发明的两个实施例的XML图解的定义的增强的MBMS用户服务描述:
<?xml version= ″1.0″encoding=″UTF-8″?>
<userServiceDescription
xmlns=″www.example.com/3gppUserServiceDescription″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″
serviceId=″urn:3gpp:1234567890coolcat″>
<deliveryMethod sessionDescriptionURI=
″http://www.example.com/3gpp/mbms/session1.sdp″/>
<deliveryMethod sessionDescriptionURI=
″http://www.example.com/3gpp/mbms/session2.sdp″/>
<deliveryMethod sessionDescriptionURI=
″http://www.example.com/3gpp/mbms/session3.sdp″/>
<deliveryMethod sessionDescriptionURI=
″http://www.example.com/3gpp/mbms/session4.sdp″/>
<qosGroup>
<qosGroupItem>
http://www.example.com/session1.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session2.sdp
</qosGroupItem>
</qosGroup>
<qosGroup>
<qosGroupItem>
http://www.example.com/session3.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session4.sdp
</qosGroupItem>
</qosGroup>
</userServiceDescription>
在描述中存在四个deliveryMethod元素。这意味着MBMS用户服务由四个MBMS载体组成。另外,由两个qosGroup元素指定了两个组。在该示例中,每个组包含了两个MBMS载体,其由包含了相移载体的SDP描述的URI的两个qosGroupItem元素来表达。
使用如以上示例XML定义中提出的扩展的MBMS用户服务描述,接收传递分层的、补充的或可替换的层的MBMS用户服务的UE知道个体MBMS载体之间的成组关系,并得知可能在网络中进行自主的QoS适应。因此,UE准备好仅接收被包含在MBMS用户服务描述中的所有MBMS载体的子集。它们能够确定是否完整地接收了组,这使得UE能够正确地接收MBMS用户服务。
上述示例XML图解不仅解决标识属于某组的MBMS载体的问题,它们还可以定义这些组是如何相互关联的(例如,代表替补或层)。
有关地,上面提出的第二XML图解(schema)引入了组的相互关系的描述。这是由新的qosRelation元素和qosGroup元素的扩展来实现的。qosRelation元素指定普遍的组关系,即,这些组是代表分离的媒体替换还是属于相同媒体的不同层。且qosGroup元素的qosPrio属性指定组层次。这取决于qosRelation元素而为替换的顺序(例如从最好到最差替换)或层的顺序(例如基础和增强层)。
下列示例图示了扩展:
<qosRelation discrete=″true″>
<qosGroup qosPrie=″1″>
<qosGroupItem>
http://www.example.com/session1.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session2.sdp</qosGroupItem>
</qosGroup>
<qosGroup qosPrio=″2″>
<qosGroupItem>
http://www.example.com/session3.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session4.sdp
</qosGroupItem>
</qosGroup>
</qosRelation>
在上述示例中的qosRelation元素示出了所描述的组被视为离散的(discrete),即,代表服务替换。qosPrio属性示出第一个所述组是优选的组。
在上述示例实施例中,UE将接收对于每个载体的MBMS通知消息,该每个载体是由用于提供如在MBMS用户服务描述中所引用的元数据的描述中所定义的相应载体的内容数据的其RNC选择的。UE得知提供服务的载体的TMGI,如例如,其经由寻呼信道(paging channel)在一个或多个MBMS通知消息中被接收。把所接收的一个或多个通知的TMGI与由MBMS用户服务描述的各个qosGroup元素的qosGroupItem元素中所引用的各个描述所定义的那些TMGI相比较,UE识别是否已经接收了以预定(载体)配置来接收服务所必需的所有载体。
如果MBMS通知宣布(announce)被定义在MBMS用户服务描述中的载体组合,则UE可以接收在一个或多个载体上提供的内容数据,并可以例如通过显示所接收的视频数据、重放所接收的音频信号等等,来向UE的用户提供内容。
如果MBMS通知没有宣布被定义在MBMS用户服务描述中的载体组合,UE可以遵照不同的策略来处理状况。例如,UE可以指示用户该服务可能不被提供,即可以触发差错消息。可替换地,UE可以等待接收其可能使MBMS用户服务的所指示的MBMS载体集“完整”的进一步通知,以便指示的MBMS载体对应于在MBMS用户服务描述中所指示的载体组合。计时器可以例如被用于保证在预定时间段内向UE指示“有效”载体组合。一旦计时器到时,UE可以决定触发差错消息。
在以下段落中,参考图5将概述根据本发明的示例实施例的MBMS多播服务的示例操作。MBMS广播服务的提供是类似的,除了不要求执行下面简短概述的订购、加入和离开过程。
在第一步,建立用户和允许用户接收相关MBMS多播服务的服务提供商之间的关系。所谓服务订购是用户同意接收由服务提供商所供给的服务。服务提供商在网络操作者网络中适当的数据库中记录订购信息。(在UMTS中,服务提供商可以是第三方,但MBMS由网络操作员来控制。)
下一步是MBMS用户服务宣布/发现机制401。该机制允许用户请求或被告知有关可用的MBMS用户服务的范围。可用的服务可以是例如操作者特定MBMS用户服务,以及来自PLMN外部的内容提供商的服务。
服务宣布被用于分发给用户有关服务的信息、服务激活所需的参数(例如IP多播地址)、和可能的其他服务相关参数(例如服务开始时间)。一般地,该信息以根据上述本发明的实施例的扩展的MBMS用户服务描述的形式来提供502。
根据本发明的实施例,可能使用几种服务发现机制,其包括诸如SMS的标准机制,或取决于个体UE的容量,促使用户询问(interrogation)的应用。所选取来通知用户有关可用MBMS用户服务的方法可以考虑用户的位置。例如,CBS(小区广播服务)、公告MBMS多播和广播用户服务的MBMS广播模式、公告MBMS多播用户服务的MBMS多播模式、诸如WAP、SMS-PP或MMS、URL(例如经由HTTP、FTP)的PUSH机制可以被用作MBMS用户服务宣布机制。
接下来,由用户进行MBMS激活503。通过该处理,订购者加入多播组,即用户向网络指示403他/她想要接收特定MBMS载体服务的多播模式数据。
MBMS多播服务激活过程在网络中注册用户以使能接收来自特定多播MBMS载体服务的数据。激活是在UE和网络之间的发信令的过程。该过程可以针对每个所激活的多播MBMS载体服务在UE、SGSN和GGSN和RNC建立中MBMS UE语境(context)。
在服务激活过程中,UE可以例如向BM-SC指示其期望接收的MBMS用户服务的MBMS载体(载体服务)的IP多播地址。在BM-SC和UE之间的随后信令中,UE被提供有所指示的MBMS载体的TMGI。因此,在多播服务的情况下,在(由MBMS用户服务描述所引用的)它们的媒体或会话描述中的载体服务的IP多播地址可以被用于建立载体相互关系和它们的成组到载体的TMGI的映射。
在MBMS激活过程503的信令中,还执行MBMS注册过程。MBMS是下述过程,通过该过程下游节点告知上游节点它愿意接收对于特定MBMS载体服务的会话属性和数据以便将它进一步向下游分发。该过程构建用于从BM-SC传递MBMS会话属性和数据到对服务感兴趣的UE的分布树,并在分布树中的网络节点中建立MBMS载体语境。对于MBMS用户服务的每个载体(MBMS载体服务),在网络节点中建立504 MBMS载体语境。MBMS载体语境包括相应MBMS载体服务所需的QoS、UE必须支持的最小载体容量、及其它。
但是,网络节点不知道属于单个MBMS用户服务的载体,也不知道它们的关系。MBMS注册过程可以适于在沿着分布树的网络节点中建立504MBMS用户服务语境,其为网络节点提供关于MBMS载体服务的相互关系的信息。还在伺服(serve)请求MBMS服务的UE的RNC中建立的MBMS用户服务语境反映会话语义,即其提供关于载体关系的信息,并描述附加的载体性质(property)。下列表图示了根据本发明的示例实施例的该语境的内容。
表1-MBMS用户服务语境
参数 |
描述/值 |
MBMS用户服务ID |
MBMS用户服务的标识符。MBMS用户服务ID标识例如属于服务的流的不同IP多播地址。 |
载体IE |
关于组成MBMS用户服务的每个MBMS载体(见以下)的信息元素。该字段包含至少对于一个载体的描述。 |
每个载体信息元素可以包括依赖于载体相互关系的不同字段。下面将描述对于每个示例类型(分层的、可替换的和补充的)的信息元素。
表2.1-对于分层载体的载体IE
载体的类型 |
在MBMS服务中载体到其他载体之间的关系的类型(例如分层的、可替换的、补充的或空的(void))。如果是“空的(void)”,则服务仅由一个载体组成。 |
载体列表 |
这是包含载体列表元素(LE)的列表,载体列表元素每个都描述上述字段中指定的类型的载体。 |
表2.2-对于分层载体的载体列表元素
MBMS载体ID |
MBMS载体的标识符,例如用于标识MBMS载体语境的IP多播地址。可以使用除了IP多播地址以外的标识符。 |
转发状态 |
包含对于每个下游节点的该MBMS载体中的流的转发状态(例如“转发”或“丢弃”)的列表。网络节点可以具有可以或可以不向其转发流的几个下游节点(例如附于SGSN的几个 |
|
RNC)。对于每个下游节点接口,在该列表中指定该流/载体的转发状态。 |
优先级 |
MBMS载体的优先级。 |
表3.1-对于可替换的载体的载体IE
载体的类型 |
在MBMS服务中载体到其他载体之间的关系的类型(例如分层的、可替换的、补充的或空的(void))。如果是“空的”,则服务仅由一个载体组成。 |
载体列表 |
这是包含载体列表元素(LE)的阵列,每个载体列表元素描述在上述字段中指定的类型的载体。 |
缺省载体组合 |
该字段标识对于MBMS用户服务的缺省的载体或载体的组合。 |
可替换的载体组合 |
该字段标识哪个载体组合(使用载体标识符)是上述缺省选项的合理替换。可替换载体组合可以定义,例如较低带宽载体组合。其他组合可以,例如以不同于缺省选项的语言来定义载体的组合。另外,可以表达基于区域(region-based)的组合来将载体组合适配于在其中供给MBMS服务的区域,例如,基于位置的服务。 |
表3.2-对于可替换的载体的载体列表元素
MBMS载体ID |
MBMS载体的标识符,例如,用于标识MBMS载体语境的IP多播地址。其他标识符是可能的。 |
转发状态 |
包含对于每个下游节点的该MBMS载体的流的转发状态(例如“转发”或“丢弃”)的列表。网络节点可以具有可以或可以不向其转发流的几 |
|
个下游节点(例如附于SGSN的几个RNC)。对于每个下游节点接口,在该列表中指定该流的转发状态。 |
表4.1-对于补充的载体的载体IE
载体的类型 |
载体是分层的、可替换的、补充的或其它类型。在MBMS服务中载体对其他载体之间的关系的类型(例如分层的、可替换的、补充的或空的)。如果是“空的”,则服务仅由一个载体组成。 |
载体列表 |
这是包含载体列表元素(LE)的阵列,每个载体列表元素描述在上述字段中指定的类型的载体。 |
表4.2-对于补充载体的载体列表元素
MBMS载体ID |
MBMS载体的标识符,例如,用于标识MBMS载体语境的IP多播地址。其他标识符是可能的。 |
转发状态 |
包含对于每个下游节点的该MBMS载体的流的转发状态(例如“转发”或“丢弃”)的列表。网络节点可以具有可以或可以不向其转发流的几个下游节点(例如附于SGSN的几个RNC)。对于每个下游节点接口,在该列表中指定该流的转发状态。 |
当维持上述MBMS用户服务语境时,RNC得知可能用于提供MBMS用户服务的载体的不同组合以及它们所需的QoS(MBMS载体语境)。
在接下来的步骤505中,BM-SC准备发送数据-会话开始。会话开始可以独立于由用户对服务的激活而发生。会话开始过程触发了在网络中用于MBMS数据传输的载体资源的保留。随后,BM-SC前进进行向下游发送509服务内容。
通过会话开始过程,把诸如QoS、所评估的会话时间段(如果可得的话)的MBMS会话属性被提供给先前已经对于相应的MBMS载体服务注册的一个或多个GGSN和一个或多个SGSN,以及连接于所注册的SGSN的所有RNC。
根据本发明的一个实施例,伺服请求MBMS用户服务的UE的RNC可以从其服务质量管理功能请求506在其同向UE的接口上的可用资源。该功能向RNC提供在用于服务供应的通向UE的下游上的QoS约束。基于从服务质量管理功能获得的信息和其对于载体关系(MBMA用户服务语境)和它们的相应QoS需求(MBMS载体语境)的知识,RNC可以选择507 MBMS载体组合,其在从服务质量管理功能中所获得的QoS约束下向UE提供所请求的MBMS用户服务。RNC可以获得关于通过其UE先前请求服务的所有接口的QoS约束,且可以针对每个接口(小区)选择满足相应QoS约束的载体组合。
对于每个小区已经选择了适当的载体组合,RNC可以广播508对于所选MBMS载体的MBMS通知,来告知已经请求服务的UE有关即将到来(以及可能在进行中)的相应所选的MBMS载体的传输。如果尚没有被传输,RNC可以在MBMS用户服务的所选MBMS载体上开始内容数据的多播。
已经宣布其对MBMS服务感兴趣的UE将接收对于其小区中所选载体的MBMS通知,并将开始从所选载体接收510内容数据。如上所述,由于被利用MBMS用户服务描述告知载体的相互关系,UE可以识别是否提供了“有效”载体的组合。
为了完成MBMS用户服务提供中进行的过程序列,接下来说明会话停止过程。BM-SC(广播/多播-服务中心)当其考虑要终止该MBMS会话时初始化MBMS会话停止过程。典型地当足够长的时间内不再有期望被传输的MBMS数据以判断网络中载体层面资源的释放时,终止会话。该过程被传播到针对相应的MBMS载体服务注册的所有SGSN和GGSN,以及具有与SGSN所建立的lu载体层面的RNC。
通过离开过程,UE可以终止MBMS多播服务的接收。由用户进行的该MBMS多播灭活是通过其订购者离开多播组(停止成为成员之一),即用户不再想要接收具体MBMS载体服务的多播模式数据的处理。
本发明的另一实施例涉及使用硬件和软件实现上述各种实施例。认识到,可以使用计算器件例如通用处理器、数字信号处理器(DSP)、特定用途集成电路(ASIC)、场可编程门阵列(FPGA)或其他可编程逻辑器件等等来实现或进行上述各种方法以及上述各种逻辑块、模块、电路。
还可以由这些器件的组合来进行或实施本发明的各种实施例。
另外,还可以按照由处理器或直接在硬件中执行的软件模块来实现本发明的各种实施例。
而且,软件模块和硬件实现的组合可以是可能的。可以把软件模块存储在例如RAM、EPROM、EEPROM、闪速存储器、寄存器、硬盘、CD-ROM、DVD等等的任何种类的计算机可读存储介质上。