一种对多媒体广播组播服务用户进行频率层汇聚的方法

文档序号:7958123阅读:170来源:国知局
专利名称:一种对多媒体广播组播服务用户进行频率层汇聚的方法
技术领域
本发明涉及一种为用户提供多媒体广播组播服务的处理方法,尤指一种对多媒体广播组播服务用户进行频率层汇聚(Frequency Layer Convergence,以下简称FLC)的方法。
背景技术
组播和广播是从一个数据源向多个目标传送数据的方式。在传统的移动网络中,小区广播业务(Cell Broadcast Service,以下简称CBS)允许低比特率数据通过小区共享广播信道向所有用户发送,这是一个基于消息的业务。
多媒体广播组播服务(Multimedia Broadcast Multicast Service,以下简称MBMS)是3GPP R6协议开始引入的一种多媒体广播组播业务,它与传统的CBS的区别就在于它不仅能实现纯文本低速率的消息类组播和广播,而且能支持多媒体业务、实现高速率的多媒体业务组播和广播,具备更大的带宽和更好的扩展性。这无疑顺应了未来移动数据发展的趋势。
然而,由于MBMS业务速率很高,在点到多点传输(Point to Multi-point,以下简称PTM)模式下消耗的功率比同等速率的专用信道(Dedicated Channel,以下简称DCH)用户要大,因此当MBMS业务有数据传输,甚至同时有多个MBMS频道在传输的数据时,容易造成整个小区负载的抬高导致拥塞。这对于小区中的普通业务用户产生了极大的影响,因为MBMS业务占据了普通业务可用的资源。基于此原因,一般运营商对于MBMS业务会使用一个专门的载频来承载。
但是由于MBMS业务无论空闲态、寻呼信道(Paging Channel,以下简称PCH)或者前向接入信道(Forward Access Channel,以下简称FACH)态用户均可接收,而这些用户在选择小区时是由UE自主进行选择的,因此,如何控制MBMS用户在MBMS业务开始实际传输前及时汇聚到承载MBMS业务的专门载频上来就成了一个值得关注的问题。
一种为用户提供MBMS业务的处理方法是不对用户进行额外控制,在不支持MBMS业务的小区中不广播MBMS业务的相关信息。然而,这种方法不利于用户接收MBMS业务如果用户不幸选择了不支持MBMS业务的小区进行驻留,则该用户永远无法接收MBMS业务。
另一种提供MBMS业务的处理方法是在不支持MBMS业务的小区也广播MBMS业务的相关信息,但要求需要接收MBMS业务的用户驻留到MBMS小区中。这种方法的缺陷在于其在MBMS业务尚未开始实际数据传输的时候就汇聚了大量用户到MBMS小区中,造成潜在用户大量增加,如果这些用户同时发起呼叫请求,或者MBMS小区本身负载就比较高的话,将会造成这些用户的接入失败,影响用户感受和网络性能指标。
鉴于上述原因,本发明提出了一种对MBMS用户进行频率层汇聚的方法。

发明内容
本发明的目的在于提供一种在多载频网络中实现FLC的方法,该方法通过对MBMS用户的控制,提高用户感受,实现网络资源的合理利用。
本发明目的通过以下技术方案实现一种对多媒体广播组播服务用户进行频率层汇聚的方法,包括指定频点用于承载多媒体广播组播服务,其中,该方法在非指定频点小区建立多媒体广播组播服务控制信道用于广播多媒体广播组播服务相关信息,处于非指定频点小区的用户在业务开始后进行频率层汇聚至指定频点小区。
汇聚至指定频点小区的用户在业务传输结束后进行频率层驱散。
与现有技术相比,本发明既能保证在MBMS业务实际传输数据前及时将MBMS用户汇聚到MBMS专用载频上来,又可以保证在暂时没有MBMS业务数据传输的时候,MBMS用户可以分散到其他小区中去,降低MBMS小区突发浪涌呼叫的潜在风险。


图1为第一种现有的多媒体广播组播服务载频规划图示。
图2为第二种现有的多媒体广播组播服务载频规划图示。
图3为本发明具体实施方式
中FLC流程示意图。
具体实施例方式
本发明一种对多媒体广播组播服务用户进行频率层汇聚的方法,包括指定频点用于承载多媒体广播组播服务,在非指定频点小区建立多媒体广播组播服务控制信道用于广播多媒体广播组播服务相关信息,对处于非指定频点小区的用户在业务开始后进行频率层汇聚至指定频点小区进行数据传输。
由于MBMS广播业务资源消耗大,因此在实际的网络规划中,运营商可能采用单独的频点来承载MBMS业务,一种现有的载频规划方式如图1所示。这种规划方式主要考虑了MBMS业务的连续覆盖,因此MBMS业务部署在已经实现全网覆盖的F1频点上,保证了MBMS业务接收时的业务质量。
但是,这种组网场景对于传统的R99用户不利,因为MBMS业务消耗资源较大,因此在多载频重叠覆盖的热点地区,传统R99用户往往会因为小区负载过高而不得不进行异频重选、异频切换,这将造成不可忽略的业务中断影响,使传统R99用户感受降低。
而如图2所示的另一种载频规划主要考虑了传统R99用户的连续覆盖,在热点地区不让MBMS占用F1频点的小区资源,以保证传统R99用户的感受。但是这不利于MBMS业务用户。因为他们在进入多载频重叠覆盖的热点地区时不得不进行一次异频重选或者异频切换才能继续接收MBMS业务,这将会导致较长的业务中断,影响用户感受。当然,这种场景也包括MBMS只部署在F2频点上的情况,这种情况下MBMS仅仅实现了热点地区的局部覆盖。
因此无论上面那一种频点规划场景,都将造成一部分用户感受的降低。而这种现象的根本原因在于,驻留在一个只有R99业务的小区的MBMS用户无法来接收MBMS业务,驻留在一个有过多MBMS用户的小区的R99用户会因为小区负载过高而需要异频切换、重选,因此需要对该类用户进行FLC/FLD处理。
所谓FLC就是指当网络规划用一个指定频点承载某个MBMS业务的时候,就需要指明这个频点并让所有需要接收这个MBMS业务的用户能够自动重选到该频点中去,尤其是在数据传输开始以后。
另外,当MBMS业务传输完毕,需要UE自动回到原来驻留的小区或者在网络层的管理算法控制下选择不在指定频点的其它小区驻留,以分散用户的分布,降低用户集中呼叫造成小区拥塞的风险。这就是频率层驱散(FrequencyLayer Dispersion,以下简称FLD),其为FLC的反向过程,。
为了保证驻留在R99小区中的用户能够按照FLC的要求重选到指定频点中去接收MBMS业务,我们必须保证在R99小区中也要广播MBMS业务相关信息。
因此要求在R99小区中也必须分配一条辅公共控制物理信道(SecondaryCommon Control Physical Channel,以下简称SCCPCH)来专门承载MBMS控制信道(MBMS Control Channel,以下简称MCCH),同时也必须有对应的MBMS指示信道(MBMS Indication Channel,以下简称MICH)存在。
R99小区的MCCH信令发送与其重叠覆盖的R99+MBMS小区的MCCH信令基本相同,其区别在于R99小区不会建立专门承载MBMS业务信道(MBMSTraffic Channel,以下简称MTCH)的SCCPCH。
此外,对于R99小区,需要执行FLC请求,让用户重选到能够承载的MTCH的频点中去。该方法的过程请参阅图3所示,具体如下
1.核心网下发MBMS会话开始信令,RNC获知相关的MBMS业务属性。由于在核心网下发开始信令之前以及收到MBMS会话结束的通知之后,在小区的MCCH上都没有MBMS业务的相关信息出现,因此FLC需要在RNC收到核心网的MBMS会话开始通知之后进行操作。通常,RNC收到核心网的MBMS会话开始通知即为业务开始,收到该会话开始通知之后的操作为业务开始后的操作。
2.RNC收到核心网的会话开始信令后,查看信令中所带的“MBMS服务区域”信元,确定将要进行的MBMS业务传输所在的小区。其中,“MBMS服务区域”信元其实是一个最大长度256(参见协议TS25.413)的列表,表明了该MBMS业务所广播的服务区域,而服务区域与具体小区的映射关系是在RNC中通过O&M进行参数配置的。RNC获得了服务区域列表也就知道了MBMS业务将会在哪些小区进行广播,这些小区所在的频点就是该MBMS业务在该地理位置的指定频点。
3.RNC在服务区域所对应的小区中通过准入建立MBMS承载。一旦MBMS承载建立成功就在这些小区的MCCH上修改对应的MBMS业务信息并通过MICH指示小区中的用户开始接收。
对于异频邻区的用户来说,只要MBMS会话开始信令中的“FLC标识”信元没有被设置成“no FLC”,就有必要对异频邻区做FLC。
FLC过程举例如下a)F1载频上的小区A为服务区域中的小区,小区A有一个异频邻区为F2载频上的小区B,首先检查小区B是否在服务区域中,如果在就不需要额外操作,过程结束。如果小区B不在服务区域中,那么对于小区B来说,该MBMS业务的指定频点即为载频F1。因此需要在小区B的MCCH上广播该MBMS业务的相关信息。
b)在小区B的MBMS基本信息信令中填写MBMS指定频点信息信元。需要注意的是该信元中指明频点的MBMS指定频点信元其实是一个索引,如果其值为n,那么指的是SIB11广播消息中New inter-frequency cells系列中出现的第n+1个频点,因此需要找到F1是第几个频点,然后正确填写。
c)在小区B的MBMS Modified/Unmodified Services Information信令中填写相应MBMS业务的MBMS指定频点信元指向F1。需要注意的是该信元使用的频率索引指向MBMS基本信息信令中的频率列表,是一个间接索引。因为小区B不承载MTCH,因此只填写业务ID等信息,不填写RB信息,并将MBMS要求UE动作的信元配成none,还要根据小区的配置设置MBMS驱散指示(一般默认为TRUE)。
d)小区B中需要接收MBMS业务的用户发起重选到载频F1,建立MBMS承载。
这里可能存在一种特殊情况,那就是小区B还有一个异频邻区是位于F3载频的小区C,小区C也在同一个MBMS业务的服务区域中,那么小区B该如何设置同一个MBMS业务的指定频点。本发明不作规定,实现中也可以不另外考虑,因为任何一种设置都是合理的。
需要说明的是,上文提及的Modified和Unmodified是针对不同的Modification Period而言的,同样的内容在前一个Modification Period是属于Modified,在后一个Modification Period就成了Unmodified了,因此上面的描述中把Modified和Unmodifed放在一起描述,特此说明。
4.MBMS用户结束会话后,RNC通过与FLC相反的FLD过程,使用户自动回到原来留驻的小区。
本发明提出了一种多载频网络中实现FLC的方法,通过在不支持MBMS的R99小区中增加MCCH,但是不建立MTCH的方式,使得在传统R99小区中可以广播MBMS业务相关信息,同时又不会占用过多小区资源。当MBMS业务开始实际的数据传输时,R99小区中的MBMS信息及时要求MBMS用户发起小区重选,汇聚到MBMS业务专用载频中。当MBMS业务结束会话后,MBMS用户又可以重新回到原来留驻的小区,降低MBMS小区突发浪涌呼叫的潜在危险。
另外,本发明能够根据核心网下发的服务列表,对于异频邻区做必要的FLC。RNC只需要维护服务区域和小区的映射关系,避免了针对每个业务配置指定频点的繁琐和不便。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
权利要求
1.一种对多媒体广播组播服务用户进行频率层汇聚的方法,包括指定频点用于承载多媒体广播组播服务,其特征在于该方法在非指定频点小区建立多媒体广播组播服务控制信道用于广播多媒体广播组播服务相关信息,处于非指定频点小区的用户在业务开始后进行频率层汇聚至指定频点小区。
2.如权利要求1所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于汇聚至指定频点小区的用户在业务传输结束后进行频率层驱散。
3.如权利要求2所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于汇聚至指定频点小区的用户在业务传输结束后自动回到原来驻留的小区。
4.如权利要求2所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于汇聚至指定频点小区的用户在业务传输结束后在网络层的管理算法控制下选择不在指定频点的其它小区驻留。
5.如权利要求1所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于核心网向网络服务器下发所述广播多媒体广播组播会话开始信令。
6.如权利要求5所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于网络服务器收到多媒体广播组播业务开始信令,获知广播多媒体广播组播业务属性,对用户进行频率层汇聚。
7.如权利要求6所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于网络服务器通过所述多媒体广播组播业务开始信令确定将要进行的多媒体广播组播业务传输所在的小区。
8.如权利要求7所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于网络服务器在小区建立多媒体广播组播承载,在控制信道上修改多媒体广播组播业务信息,并通过指示信道指示小区中的用户开始接收。
9.如权利要求1所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于只要多媒体广播组播会话开始信令没有限制不能使用频率层汇聚,就有必要对异频邻区做频率层汇聚。
10.如权利要求9所述的对多媒体广播组播服务用户进行频率层汇聚的方法,其特征在于该方法包括在所述异频邻区的多媒体广播组播基本信息信令中填写指定频点信息信元,该指定频点信息信元指向所述指定频点。
全文摘要
本发明提出了一种对多媒体广播组播服务用户进行频率层汇聚的方法,指定频点用于承载多媒体广播组播服务,该方法在非指定频点小区建立多媒体广播组播服务控制信道、用于广播多媒体广播组播服务相关信息,处于非指定频点小区的用户在业务开始后进行频率层汇聚至指定频点小区。本发明既能保证在多媒体广播组播业务实际传输数据前及时将用户汇聚到专用载频上来,又可以保证在暂时没有业务数据传输的时候,用户可以分散到其他小区中去,降低多媒体广播组播小区突发浪涌呼叫的潜在风险。
文档编号H04W4/06GK1997169SQ20061006374
公开日2007年7月11日 申请日期2006年12月31日 优先权日2006年12月31日
发明者王宏伟 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1