一种多媒体广播/多播业务的业务释放方法

文档序号:7958920阅读:107来源:国知局
专利名称:一种多媒体广播/多播业务的业务释放方法
技术领域
本发明涉及多媒体广播/多播技术,特别是指一种多媒体广播/多播业务的业务释放方法。
背景技术
目前,实现广播/多播业务的一种组网结构如图1所示,包括用户设备(UE)、基站(NodeB)和无线网络控制器(RNC)、服务通用分组无线业务支持节点(SGSN)、网关通用分组无线业务支持节点(GGSN)、门户(Portal)、流媒体服务器。其中流媒体服务器可以为分组交换流媒体服务器(PSS Server)。
基于图1所示的实现广播/多播业务的组网结构中,图2所示为广播/多播业务的业务建立和业务释放流程图,包括以下几个步骤步骤201UE浏览Portal,选择自己感兴趣的广播/多播业务,向Portal发送请求所选择的特定业务的统一资源位置(URL)的消息,所述请求消息可以为超文本传送协议(HTTP)的获取(GET)消息。
步骤202Portal向UE返回携带有UE所请求特定业务URL的响应,所述响应为HTTP的200OK消息,该HTTP 200OK消息中携带UE所请求特定业务的URL。
步骤203UE根据所获取的特定业务的URL,向流媒体服务器发送请求建立实时流协议(RTSP)连接的消息,所述请求消息可以为RTSP的建立(Setup)消息。
步骤204流媒体服务器向UE返回响应,所述响应可以为RTSP的200OK消息,该响应表示UE与流媒体服务器之间已成功建立RTSP连接。
步骤205UE向流媒体服务器请求播放在步骤201中所选择的特定业务的消息,所述请求消息可以为RTSP的播放(PLAY)消息,所述RTSP PLAY消息中携带步骤202中所得到的特定业务的URL。
步骤206流媒体服务器向UE返回响应,所述响应可以为RTSP的200OK消息,该响应表示已经成功处理UE的请求。
步骤207流媒体服务器根据UE请求消息中源IP地址找到对应的GGSN,并向该GGSN发送多播通知(Multieast Notification)消息,该消息中携带UE标识和业务标识。其中,UE标识为UE的相关信息,例如UE的IP地址,或IMSI,或TMSI;业务标识为表示特定业务的标识,流媒体服务器和RNC中相同业务标识表示同一个业务。
通常,流媒体服务器中建立有IP地址与该IP地址所路由的GGSN的对应关系,因此,根据UE发送消息时所携带的源IP地址就能够找到对应的GGSN。
步骤208GGSN收到多播通知消息后,向流媒体服务器返回多播通知确认响应(Multicast Notification ACK)。
步骤209GGSN根据多播通知消息中的UE标识查找服务该UE的SGSN,并向该SGSN转发所述多播通知消息,该消息携带UE标识和业务标识。
步骤210SGSN收到多播通知消息后,向GGSN返回多播通知确认响应。
步骤211SGSN根据多播通知消息中的UE标识查找服务该UE的RNC,并向该RNC转发所述多播通知消息,该消息携带UE标识和业务标识。
步骤212RNC收到多播通知消息后,向SGSN返回多播通知确认响应。
步骤213RNC根据所收到的多播通知消息中UE标识和业务标识,获取对应该UE标识的UE请求接收的特定的多播业务,并向UE发送指示UE切换到传送该多播业务数据的多播信道上的切换信道(Change Channel)消息。如果该UE是当前小区第一个接收该业务的UE,则RNC还应该分配相应的多播信道并在所分配的信道上传送业务数据。所述多播信道可以为前向接入信道(FACH)。
步骤214UE向RNC返回切换信道响应(Change Channel ACK),并根据RNC的指示切换到传送业务数据的多播信道上,从而可以以多播的方式接收业务数据。
步骤215当UE不想继续接收业务数据时,UE向流媒体服务器发送请求业务释放的消息,所述请求消息可以为RTSP的释放(Teardown)消息,RTSP Teardown消息表示该UE不再继续接收该业务数据,即释放该业务。
步骤216流媒体服务器向UE返回响应,所述响应为RTSP的200OK消息,所述响应表示成功处理UE的业务释放的请求。
在以上所述的广播/多播业务的业务建立和释放的流程中,UE在接收业务数据时发送业务释放请求消息给流媒体服务器时,流媒体服务器直接向UE发送响应消息,现有技术中的业务释放过程存在以下缺点1)UE在接收业务数据的时候,处于下行组播数据的接收状态,当在该状态下传送流媒体服务器给UE的响应消息时,如果还有其它UE继续接收所述业务数据,则会对向其它UE传输的业务数据造成冲击,可能引起业务数据丢包。
2)由于响应消息通过广播/多播信道传送,因此不能保证将响应消息可靠地传送到UE,如果UE不能正常地接收流媒体服务器的响应消息,则业务释放流程不能正常完成,有可能导致反复请求释放业务的死循环。尤其是当传输业务数据所使用的传输信道是FACH信道时,由于FACH信道无功率控制,更不能保证将来自流媒体服务器的响应消息可靠地发送给UE。
3)同时,当UE结束接收某个业务时RNC未收到任何通知,因此在某个小区开始多播传送特定业务数据以后,当该小区内所有UE都不再接收所述业务时,RNC也不会释放该小区内传送该业务数据的多播信道,这将极大地浪费该小区的空口资源。

发明内容
有鉴于此,本发明的主要目的在于提供一种多媒体广播/多播业务的业务释放方法,当UE请求业务释放时,能够可靠地接收来自流媒体服务器的释放响应消息。
为了达到上述目的,本发明提供一种多媒体广播/多播业务的业务释放方法,该方法包括a.用户设备UE向流媒体服务器请求释放当前已建立的业务;b.流媒体服务器向所述UE所在的无线网络控制器RNC发送所述UE请求释放广播/多播业务的通知;c.RNC将所述请求释放业务的UE配置为专用信道状态后,向流媒体服务器返回广播/多播业务释放响应;d.流媒体服务器收到来自RNC的广播/多播业务释放响应后,通过所配置的专用信道向所述UE返回业务释放响应。
步骤b所述流媒体服务器向RNC发送请求释放广播/多播业务的通知为流媒体服务器通过网关通用分组无线业务支持节点GGSN、服务通用分组无线业务支持节点SGSN向RNC发送广播/多播业务释放通知消息,广播/多播业务释放通知消息中携带请求释放业务UE的UE标识和业务标识;步骤c所述RNC向流媒体服务器返回广播/多播业务释放响应为RNC通过SGSN、GGSN向流媒体服务器返回广播/多播业务释放响应。
步骤b所述流媒体服务器向RNC发送广播/多播业务释放通知消息的步骤包括b1.流媒体服务器根据UE的IP地址查找对应的GGSN,向所述GGSN发送广播/多播业务释放通知消息;b2.GGSN根据所接收到的广播/多播业务释放通知消息中UE标识查找对应的SGSN,将所述广播/多播业务释放通知消息转发给所述SGSN;b3.SGSN根据所接收到的广播/多播业务释放通知消息中UE标识查找对应的RNC,将所述广播/多播业务释放通知消息转发给所述RNC;步骤c所述RNC向流媒体服务器返回广播/多播业务释放响应的步骤包括c1.RNC向SGSN返回广播/多播业务释放响应;c2.SGSN向GGSN返回广播/多播业务释放响应。
c3.GGSN向流媒体服务器返回广播/多播业务释放响应。
所述GGSN预先设置接收流媒体服务器的广播/多播业务释放通知消息的用户数据报协议UDP或传输控制协议TCP端口;步骤b1所述流媒体服务器向GGSN发送广播/多播业务释放通知消息为使用用户数据报协议UDP或传输控制协议TCP将所述广播/多播业务释放通知消息发送给GGSN,其中UDP或TCP报文的目标端口为所述GGSN所预先设置的接收流媒体服务器的广播/多播业务释放通知消息的UDP或TCP端口。
步骤b2所述GGSN将广播/多播业务释放通知消息转发给SGSN为使用通用分组无线业务隧道协议控制面GTP-C协议传送所述广播/多播业务释放通知消息。
步骤b3所述SGSN将广播/多播业务释放通知消息转发给RNC为使用无线接入网络应用部分RANAP协议传送所述广播/多播业务释放通知消息。
RNC预先设置接收流媒体服务器的广播/多播业务释放通知消息的UDP或TCP端口;步骤b所述流媒体服务器向RNC发送请求释放广播/多播业务的通知为流媒体服务器向RNC使用UDP或TCP传送广播/多播业务释放通知消息,其中UDP或TCP报文中目标端口为所述RNC所预先设置的接收流媒体服务器的广播/多播业务释放通知消息的UDP或TCP端口,所述广播/多播业务释放通知消息携带请求释放业务的UE标识和业务标识。
步骤c所述RNC将所述请求释放业务的UE配置为专用信道状态的步骤包括RNC指示广播/多播业务释放通知消息中UE标识对应的UE切换到专用信道状态;UE根据所述指示切换到专用信道状态。
当建立多播业务时,RNC收到来自流媒体服务器的包含UE标识和业务标识的多播通知消息后,进一步包括RNC根据UE标识确定该UE所在的小区,并根据业务标识更新所述小区内当前接收对应业务的UE的数目;当释放多播业务时,步骤c所述RNC将请求释放业务的UE配置为专用信道状态之后进一步包括RNC根据广播/多播业务释放通知消息中UE标识确定该UE所在的小区,并根据业务标识更新所述小区内当前接收对应业务的UE的数目;RNC判断所述小区内更新后的接收对应业务的UE的数目是否为0,如果是,则释放该小区内传送该业务的空口资源。
所述RNC释放小区内传送该业务的空口资源为RNC释放该小区内传送该业务的空中信道,或者停止下发所述业务的数据。
建立多播业务时,所述更新所述小区内当前接收对应业务的UE的数目为将UE的数目加1;释放多播业务时,所述更新所述小区内当前接收对应业务的UE的数目为将UE的数目减1。
根据本发明提供的方法,当UE发起广播/多播业务的业务释放请求时,流媒体服务器向该UE所在RNC发送UE请求释放业务的业务释放通知,然后由RNC为该请求业务释放的UE配置专用信道,这样,流媒体服务器向UE返回业务释放响应时通过专用信道可以正确可靠地传送响应,而且对广播/多播业务数据无冲击。由于UE发起业务释放请求时,RNC收到来自流媒体服务器的业务释放通知,因此,RNC能够获取特定小区内接收特定业务的UE数目,这样,当RNC判断出特定小区内当前正在接收特定业务的UE数目为0时,即可释放该小区内传送该业务数据的空中信道或停止下发数据,从而节省空口资源。


图1所示为现有技术中实现广播/多播业务的结构;图2所示为现有技术中实现广播/多播业务的业务建立和业务释放的流程图;图3所示为本发明实施例中实现广播/多播业务的业务释放的流程图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚明白,下面举具体实施例,对本发明作进一步详细的说明。
本发明提供广播/多播业务的业务释放方法,其主要思想是流媒体服务器接收到UE的业务释放请求后,向该UE所在的RNC发送所述UE请求业务释放的通知,收到所述业务释放通知的RNC将所述发起业务释放的UE切换到专用信道(DCH),并向流媒体服务器返回业务释放响应;收到来自RNC业务释放响应的流媒体服务器向请求业务释放的UE返回业务释放响应,所述业务释放响应通过DCH可靠的传送到UE。针对多播业务的释放,收到所述业务释放通知的RNC进一步判断是否已没有UE接收当前请求释放的业务,如果是,则释放传输该业务的空口资源。
本发明中,在采用图2所示的步骤201~步骤214建立广播/多播业务后,当UE在接收广播/多播业务过程中发起业务释放请求时,实现广播/多播业务的业务释放的流程如图3所示,包括以下几个步骤步骤301当正在接收广播/多播业务业务数据的UE希望不再接收该业务时,UE向流媒体服务器请求释放业务,即向流媒体服务器发送RTSP释放请求,所述请求可以是RTSP Teardown消息。
步骤302流媒体服务器根据UE的IP地址查找对应的GGSN,并向该GGSN发送广播/多播业务释放通知消息,该消息中携带请求释放业务的UE的UE标识和该UE所要释放的业务标识。
流媒体服务器向GGSN发送的广播/多播业务释放通知消息可通过用户数据报协议(UDP)或传输控制协议(TCP)传送,这时,GGSN需要预先设置接收流媒体服务器的业务释放通知消息的UDP或TCP端口,而流媒体服务器向GGSN发送的UDP或TCP报文中目的端口为所述GGSN预先设置的接收流媒体服务器的业务释放通知消息的UDP或TCP端口。
在广播/多播业务释放通知消息中携带的UE标识可以是该UE的IP地址,或者是该UE的国际移动用户识别码(IMSI),或者是该UE的临时移动台识别码(TMSI)等UE相关信息。所述UE标识可以在建立业务过程中得到,或者通过其它信令过程得到,或者通过查找所述UE的分组数据协议(PDP)上下文得到,获取UE标识的过程属于现有技术,在此不作详细描述。
步骤303GGSN根据广播/多播业务释放通知消息携带的UE标识查找服务该UE的SGSN,并向该SGSN转发该广播/多播业务释放通知消息,该消息携带UE标识和业务标识。
GGSN向SGSN发送的广播/多播业务释放通知消息可通过GPRS隧道协议控制面(GTP-C)协议传送。
步骤304SGSN根据广播/多播业务释放通知消息携带的UE标识查找该UE所在的RNC,并向该RNC转发该广播/多播业务释放通知消息,该消息携带UE标识和业务标识。
SGSN向RNC发送的广播/多播业务释放通知消息可通过无线接入网络应用部分(RANAP)协议传送。
步骤305RNC根据广播/多播业务释放通知消息中携带的UE标识,配置UE到专用信道状态(CELL_DCH),其步骤是RNC指示UE切换到CELL_DCH状态,UE根据所述指示切换到CELL_DCH状态。UE处于CELL_DCH状态时,可以通过专用信道(DCH)接收数据。
步骤306RNC根据广播/多播业务释放通知消息中携带的UE标识确定该UE所在的小区,并根据广播/多播业务释放通知消息中携带的业务标识更新该小区内当前接收特定业务的UE数目,即将所述接收特定业务的UE的数目减1。
步骤307更新UE数目后,RNC判断该小区内当前接收特定业务的UE数目是否为0,如果是,则说明该小区内已没有UE接收特定业务,释放该小区内传输该业务数据的空口资源。
所述释放空口资源的方法可以为释放该小区内传输该业务数据的空中信道;或者,通过停止下发业务数据释放空口资源,因为只要停止下发数据,就不再占用空口资源。
广播/多播都是指发送者以一对多的方式在相同的传输通道上传送一份同样的数据给多个接收者。在实际应用中,广播/多播通常会有一个树状的多级广播/多播传输结构,每个上游节点将数据广播/多播给相连的多个下游节点。广播和多播存在一个重要区别在广播模式下,这种树状传输结构的每个分支上都有广播数据传送,每个上游节点总是将数据传送给所有相连的下游节点;而在多播模式下,每个上游节点当且仅当它有至少一个相连的下游节点期望接收多播数据时,才会将多播数据传送给所有期望接收多播数据的下游节点,否则该节点即使收到多播数据,也不会传送给下游节点。
针对以上释放空口资源的步骤306、307,RNC可以根据以下几种情况执行或不执行释放空口资源的步骤如果当前释放的业务为广播业务,则RNC不释放空口资源,如果当前释放的业务为多播业务,则RNC释放空口资源;或者RNC根据自身处理当前释放的业务的模式,如果以广播方式处理该业务,则不释放空口资源,如果以多播方式处理该业务,则释放空口资源。
当需要执行以上步骤306、307所述释放空口资源时,在业务建立过程中,同样的需要更新每个小区内接收特定业务数据的UE数目,其步骤为在图2所示步骤211中,RNC接收到包含业务标识和UE标识的多播通知消息后,根据UE标识确定该UE所在的小区,并根据业务标识更新对应小区内接收当前特定业务的UE的数目,即将所述接收当前特定业务的UE的数目加1。
步骤308RNC响应从SGSN收到的广播/多播业务释放通知,向SGSN发送广播/多播业务释放响应。该步骤也可以在步骤306或步骤307之前执行。
步骤309SGSN收到RNC的广播/多播业务释放响应后,向GGSN转发RNC发送的广播/多播业务释放响应。
步骤310GGSN收到SGSN的广播/多播业务释放响应后,向流媒体服务器转发SGSN发送的广播/多播业务释放响应。
步骤311流媒体服务器收到广播/多播业务释放响应后,向UE发送RTSP释放响应消息,由于UE已处于CELL_DCH状态,因此RTSP释放响应消息通过UE当前处于的DCH传送,这样,UE能够正确地接收到该响应消息。
该UE发起的业务释放流程至此结束。
按照以上步骤所述,流媒体服务器向RNC发送广播/多播业务释放通知消息时,通过GGSN、SGSN发送至RNC,其具体实现除了图3所述步骤302、303、304的方法之外,还可以通过以下方法实现第一种流媒体服务器根据UE的IP地址向对应的GGSN发送广播/多播业务释放通知消息,然后由GGSN通过SGSN向RNC转发所述广播/多播业务释放通知消息。例如,GGSN使用该UE的专用信令连接向RNC转发所述广播/多播业务释放通知消息,在使用UE专用信令连接传送所述广播/多播业务释放通知消息时,该消息中可以不携带UE标识,因为该信令连接为特定UE专用,可以视为该消息中已经隐含了UE标识。
第二种流媒体服务器使用UDP或TCP协议,直接将所述广播/多播业务释放通知消息发送给RNC,这时,RNC需要预先设置接收流媒体服务器的业务释放通知消息的UDP或TCP端口,而流媒体服务器向RNC发送的UDP或TCP报文中目的端口为所述RNC预先设置的接收流媒体服务器的业务释放通知消息的UDP或TCP端口。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
权利要求
1.一种多媒体广播/多播业务的业务释放方法,其特征在于,该方法包括a.用户设备UE向流媒体服务器请求释放当前已建立的业务;b.流媒体服务器向所述UE所在的无线网络控制器RNC发送所述UE请求释放广播/多播业务的通知;c.RNC将所述请求释放业务的UE配置为专用信道状态后,向流媒体服务器返回广播/多播业务释放响应;d.流媒体服务器收到来自RNC的广播/多播业务释放响应后,通过所配置的专用信道向所述UE返回业务释放响应。
2.根据权利要求1所述的方法,其特征在于,步骤b所述流媒体服务器向RNC发送请求释放广播/多播业务的通知为流媒体服务器通过网关通用分组无线业务支持节点GGSN、服务通用分组无线业务支持节点SGSN向RNC发送广播/多播业务释放通知消息,广播/多播业务释放通知消息中携带请求释放业务UE的UE标识和业务标识;步骤c所述RNC向流媒体服务器返回广播/多播业务释放响应为RNC通过SGSN、GGSN向流媒体服务器返回广播/多播业务释放响应。
3.根据权利要求2所述的方法,其特征在于,步骤b所述流媒体服务器向RNC发送广播/多播业务释放通知消息的步骤包括b1.流媒体服务器根据UE的IP地址查找对应的GGSN,向所述GGSN发送广播/多播业务释放通知消息;b2.GGSN根据所接收到的广播/多播业务释放通知消息中UE标识查找对应的SGSN,将所述广播/多播业务释放通知消息转发给所述SGSN;b3.SGSN根据所接收到的广播/多播业务释放通知消息中UE标识查找对应的RNC,将所述广播/多播业务释放通知消息转发给所述RNC;步骤c所述RNC向流媒体服务器返回广播/多播业务释放响应的步骤包括c1.RNC向SGSN返回广播/多播业务释放响应;c2.SGSN向GGSN返回广播/多播业务释放响应;c3.GGSN向流媒体服务器返回广播/多播业务释放响应。
4.根据权利要求3所述的方法,其特征在于,所述GGSN预先设置接收流媒体服务器的广播/多播业务释放通知消息的用户数据报协议UDP或传输控制协议TCP端口;步骤b1所述流媒体服务器向GGSN发送广播/多播业务释放通知消息为使用用户数据报协议UDP或传输控制协议TCP将所述广播/多播业务释放通知消息发送给GGSN,其中UDP或TCP报文的目标端口为所述GGSN所预先设置的接收流媒体服务器的广播/多播业务释放通知消息的UDP或TCP端口。
5.根据权利要求3所述的方法,其特征在于,步骤b2所述GGSN将广播/多播业务释放通知消息转发给SGSN为使用通用分组无线业务隧道协议控制面GTP-C协议传送所述广播/多播业务释放通知消息。
6.根据权利要求3所述的方法,其特征在于,步骤b3所述SGSN将广播/多播业务释放通知消息转发给RNC为使用无线接入网络应用部分RANAP协议传送所述广播/多播业务释放通知消息。
7.根据权利要求1所述的方法,其特征在于,RNC预先设置接收流媒体服务器的广播/多播业务释放通知消息的UDP或TCP端口;步骤b所述流媒体服务器向RNC发送请求释放广播/多播业务的通知为流媒体服务器向RNC使用UDP或TCP传送广播/多播业务释放通知消息,其中UDP或TCP报文中目标端口为所述RNC所预先设置的接收流媒体服务器的广播/多播业务释放通知消息的UDP或TCP端口,所述广播/多播业务释放通知消息携带请求释放业务的UE标识和业务标识。
8.根据权利要求2至7任一项所述的方法,其特征在于,步骤c所述RNC将所述请求释放业务的UE配置为专用信道状态的步骤包括RNC指示广播/多播业务释放通知消息中UE标识对应的UE切换到专用信道状态;UE根据所述指示切换到专用信道状态。
9.根据权利要求2至7任一项所述的方法,其特征在于,当建立多播业务时,RNC收到来自流媒体服务器的包含UE标识和业务标识的多播通知消息后,进一步包括RNC根据UE标识确定该UE所在的小区,并根据业务标识更新所述小区内当前接收对应业务的UE的数目;当释放多播业务时,步骤c所述RNC将请求释放业务的UE配置为专用信道状态之后进一步包括RNC根据广播/多播业务释放通知消息中UE标识确定该UE所在的小区,并根据业务标识更新所述小区内当前接收对应业务的UE的数目;RNC判断所述小区内更新后的接收对应业务的UE的数目是否为0,如果是,则释放该小区内传送该业务的空口资源。
10.根据权利要求9所述的方法,其特征在于,所述RNC释放小区内传送该业务的空口资源为RNC释放该小区内传送该业务的空中信道,或者停止下发所述业务的数据。
11.根据权利要求9所述的方法,其特征在于,建立多播业务时,所述更新所述小区内当前接收对应业务的UE的数目为将UE的数目加1;释放多播业务时,所述更新所述小区内当前接收对应业务的UE的数目为将UE的数目减1。
全文摘要
本发明公开了一种多媒体广播/多播业务的业务释放方法,该方法包括用户设备UE向流媒体服务器请求释放当前已建立的业务;流媒体服务器向所述UE所在的无线网络控制器RNC发送所述UE请求释放广播/多播业务的通知;RNC将所述请求释放业务的UE配置为专用信道状态后,向流媒体服务器返回广播/多播业务释放响应;流媒体服务器收到来自RNC的广播/多播业务释放响应后,通过所配置的专用信道向所述UE返回业务释放响应。根据本发明公开的方法,当UE请求业务释放时,能够可靠地接收来自流媒体服务器的释放响应,且RNC能够释放传输该业务数据的空口资源。
文档编号H04W76/06GK101047962SQ20061006707
公开日2007年10月3日 申请日期2006年3月31日 优先权日2006年3月31日
发明者胡军, 司宏杰 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1