CN102264001A - Iptv增强组播可靠性的方法、服务器及系统 - Google Patents
Iptv增强组播可靠性的方法、服务器及系统 Download PDFInfo
- Publication number
- CN102264001A CN102264001A CN2010101876306A CN201010187630A CN102264001A CN 102264001 A CN102264001 A CN 102264001A CN 2010101876306 A CN2010101876306 A CN 2010101876306A CN 201010187630 A CN201010187630 A CN 201010187630A CN 102264001 A CN102264001 A CN 102264001A
- Authority
- CN
- China
- Prior art keywords
- server
- multicast source
- multicast
- source server
- link failure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供一种IPTV增强组播可靠性的方法、服务器及系统。该方法包括检测组播数据流传输是否出现流类型故障或者链路故障;当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后,将关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。本发明实施例可以提高可服务性及中断的切换和自动恢复。
Description
技术领域
本发明涉及网络通信技术,尤其涉及一种IPTV增强组播可靠性的方法、服务器及系统。
背景技术
网络电视(Internet Protocol Television,IPTV)是多用户访问相同节目内容的业务,而组播正是提供一对多业务模式的有效手段,允许一台或多台主机作为组播源一次性地发送单一数据包到多台主机接受者,与传统的单播技术相比,组播能有效的节省网络带宽,减轻IP承载网络的负载和服务器负载,因此,在IPTV的业务承载上部署组播无疑是最佳选择。IPTV业务的典型应用是广播电视业务(Broadcast Television,BTV),具体实现为:BTV前端(组播源)将媒体数据流发送到IP城域网中,当用户需要服务时,由接收终端(Customer Provider Edge,CPE),例如机顶盒(Set Top Box,STB),向宽带接入服务器(Broadband Access Server,BRAS)进行用户接入认证,认证通过后获得电子节目菜单(ElectronicProgram Guide,EPG),用户根据开户时定制的服务产品选择自己需要的频道向BRAS发送加入频道请求,BRAS收到请求后将IP城域网中基于IP组播报文承载的视频数据流通过数字用户线接入复用器(DigitalSubscriber Line Access Multiplexer,DSLAM)转发到CPE进行节目播放。
IPTV业务采用IP组播技术将频道节目流推送到用户,这种基于IP组播报文承载IPTV视频数据流的方法,对组播源的可靠性要求较高,当组播源服务器设备发生故障或链路发生故障时都会影响IPTV业务的正常开展。
为了保证组播源的可靠性,现有技术中存在两种实现方式,现有技术一是建立组播源集群服务器,当一台组播源服务器发生故障时,备份的服务器会立即接管故障服务器的角色,保证组播业务不中断。现有技术二是对于同一视频流,通过两个组播源服务器配置不同的源地址进行转发。两个数据流都被路由器转发,由接收终端负责丢弃冗余数据。可以是CPE通过因特网组管理协议(Internet Group Management Protocol,IGMPV3)加入特定源组,组播源服务器失效后,CPE向备份组播源服务器发IGMPV3加入。当CPE不支持IGMPV3时,需要在BRAS中配置映射表(mapping)选择具体源IP。
在实现本发明过程中,发明人发现现有技术中至少存在如下问题:现有技术一要求组播源服务器部署集中,当整个集群服务器网络故障时会导致组播业务立即中断;现有技术二需要CPE支持IGMPV3,或者当不支持IGMPV3时,需要在BRAS中配置mapping,当发生故障后需要手工调整mapping,造成可服务性差;并且对于组播源流类型故障或者组播源服务器链路故障,无法依靠路由收敛,造成业务中断而无法切换和自动恢复。
发明内容
本发明实施例提供了一种IPTV增强组播可靠性的方法、服务器及系统,用以解决现有技术中存在的可服务性差及中断无法切换和自动恢复的问题。
一方面,本发明实施例是提供一种IPTV增强组播可靠性的方法,包括:
检测组播数据流传输是否出现流类型故障或者链路故障;
当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后,将关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
另一方面,本发明实施例提供了一种IPTV增强组播可靠性的方法,包括:
接收主用组播源服务器发送的告警信息,所述告警信息为所述主用组播源服务器检测到组播数据流传输出现流类型故障或者链路故障后发送的;
将与所述主用组播源服务器关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
一方面,本发明实施例提供了一种组播源服务器,包括:
检测模块,用于检测组播数据流传输是否出现流类型故障或者链路故障;
告警模块,用于当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后将关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
另一方面,本发明实施例提供了一种网管服务器,包括:
接收模块,用于接收主用组播源服务器发送的告警信息,所述告警信息为所述主用组播源服务器检测到组播数据流传输出现流类型故障或者链路故障后发送的;
更新模块,用于将与所述主用组播源服务器关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
本发明实施例提供了一种IPTV增强组播可靠性的系统,包括:
组播源服务器,用于当检测到出现流类型故障或者链路故障时,断掉路由器的通信连接,并上报告警信息;
网管服务器,用于在接收到所述告警信息后,将与所述组播源服务器关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
由上述技术方案可知,本发明实施例通过检测流类型故障和链路故障,并在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本发明第一实施例的方法流程示意图;
图2为本发明第二实施例的方法流程示意图;
图3为本发明第三实施例的方法流程示意图;
图4为本发明第四实施例的组播源服务器结构示意图;
图5为本发明第五实施例的网管服务器结构示意图;
图6为本发明第六施例的系统结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1为本发明第一实施例的方法流程示意图,包括:
步骤11:主用组播源服务器检测组播数据流传输是否出现流类型故障或者链路故障;
其中,当主用组播源服务器正常时,该组播数据流是由该主用组播源服务器转发,在发生故障后由备用组播源服务器转发组播数据流。
步骤12:当检测到出现流类型故障或者链路故障时,主用组播源服务器断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后将关联的BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
本实施例通过检测流类型故障和链路故障,并在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。
图2为本发明第二实施例的方法流程示意图,本实施例以组播源服务器为媒体资源功能实体(Media Resource Function,MRF)为例。参见图2,包括:
步骤201:BRAS配置初始映射表,其中包括主用MRF的IP地址和备用MRF的IP地址,并指定由主用MRF进行组播数据流转发。
可选的,备用MRF可以为多个,每一备用MRF对应相应的IP地址。
步骤202:CPE向主用MRF发送加入请求,建立与主用MRF的通信连接,从主用MRF获取组播数据流。
步骤203:主用MRF和备用MRF分别建立与网管服务器的通信连接。
可以理解是,步骤201-203为系统预先的配置信息,当数据流从主用MRF转发后,可以从以下的步骤204开始执行,而不需要每次都从步骤201开始执行。
步骤204:主用MRF检测是否出现流类型故障或者链路故障,若是,执行步骤205,否则,执行步骤212。
其中,流类型故障可以通过如下方式检测:在主用MRF中设置采样周期和阈值,当采样周期内得到的数据流的变化率超出该阈值时,则表明出现流类型故障。
链路故障可以通过如下方式检测:主用MRF定时向与主用MRF通信连接的路由器发送ping包,当未成功接收到对应的响应包时,则表明链路故障。
步骤205:主用MRF断掉(down)与路由器的连接,并通过与网管服务器建立的通信连接向网管服务器上报告警信息。
其中,由于链路断掉,路由会重新进行收敛;由于组播源服务器包含主用MRF和备用MRF,则最优的主用MRF断掉后,路由会重新收敛到备用MRF对应的路径上。
步骤206:网管服务器在接收到告警信息后,向与主用MRF关联的BRAS发送映射表刷新指令。
其中,告警信息包括告警源地址、告警时间、告警类型、告警原因和网络设备关联关系。告警源地址是指MRF服务器的IP地址,作用是通知网管比对映射表(Mapping)中的IP地址,从而将Mapping表中为CPE提供服务的MRF的IP地址更改为与告警源地址不同的预先配置的另一IP地址。告警时间是指发生故障的时间点,作用是便于故障回溯。告警类型是指是流类型故障还是链路故障,作用也是便于故障恢复。告警原因是对告警类型的进一步细化,例如链路故障包括单纤故障、链路挂死等;流类型故障也包括流服务停止或者流内容本身异常。网络设备关联关系是指网络中需要配置Mapping的BRAS的地址信息,作用是网管服务器根据该网络设备关联关系获取需要更改映射表项的BRAS的地址,该需要更改映射表项的BRAS为与主用MRF关联的BRAS。
步骤207:BRAS接收到刷新指令后更新映射表中的组播源服务器的地址,将组播源服务器的地址从主用MRF的地址更新为备用MRF的地址。
为了加快新的映射表项的生效,网管服务器在下发刷新指令时还可以下发删除指令,以删除老的映射表项。
步骤208:CPE向备用MRF发送加入请求,建立与备用MRF的通信连接,从备用MRF获取组播数据流。
步骤209:主用MRF定时检测故障是否恢复,若是,执行步骤210,否则,执行步骤213。
步骤210:主用MRF向网管服务器发送恢复正常消息。
步骤211:当备用MRF发生故障后,备用MRF通过与网管服务器的通信连接向网管发送故障消息,之后,网管服务器通过刷新BRAS中的映射表项,将链路切换回主用MRF。
步骤212:主用MRF继续为CPE提供组播数据流。之后,可以重复执行步骤204。
步骤213:备用MRF继续为CPE提供组播数据流。之后,可以重复执行步骤209。
本实施例通过检测流类型故障和链路故障,在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。本实施例通过在备用MRF发生故障后再切换回主用MRF而不是主用MRF恢复正常即切换,可以提高系统的稳定性。
图3为本发明第三实施例的方法流程示意图,包括:
步骤31:网管服务器接收主用组播源服务器发送的告警信息,所述告警信息为所述主用组播源服务器检测到组播数据流传输出现流类型故障或者链路故障后发送的;
其中,主用组播源服务器在检测到组播数据流传输出现流类型故障或者链路故障后,还会断掉与路由器的通信连接,以便进行新的路由收敛,由备用组播源服务器提供转发组播数据流的业务。
步骤32:网管服务器将与所述主用组播源服务器关联的BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
本实施例通过由主用组播源服务器检测流类型故障和链路故障,并在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。
图4为本发明第四实施例的组播源服务器结构示意图,包括检测模块41和告警模块42;检测模块41用于检测组播数据流是否出现流类型故障或者链路故障;告警模块42用于当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后将关联的BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
其中,检测模块41可以包括第一单元411和/或第二单元412,第一单元411用于当在预先设定的采样周期内,检测到数据流量的变化率超出预先设定的阈值时,检测出流类型故障;第二单元412用于定时向连接的路由器发送ping包,当未接收到所述路由器反馈的与所述ping包对应的响应时,检测出链路故障。
进一步地,还可以包括建立模块43,建立模块43用于建立与网管服务器之间的通信链路,通过所述通信链路上报所述告警信息,所述告警信息包括:告警源地址、告警时间、告警类型、告警原因、网络设备关联关系。
进一步地,还可以包括恢复模块44,恢复模块44用于当流类型故障或者链路故障消除后,向所述网管服务器发送恢复正常消息,以便在备用组播源服务器发生故障后,恢复对组播数据流的转发。
上述模块的具体功能可以参见上述方法实施例,不再赘述。
本实施例通过检测流类型故障和链路故障,并在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。
图5为本发明第五实施例的网管服务器结构示意图,包括接收模块51和更新模块52;接收模块51用于接收主用组播源服务器发送的告警信息,所述告警信息为所述主用组播源服务器检测到组播数据流传输出现流类型故障或者链路故障后发送的;更新模块52用于将与所述主用组播源服务器关联的BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
本实施例还可以包括恢复模块53,恢复模块53用于当流类型故障或者链路故障消除后,接收所述主用组播源服务器发送的恢复正常消息,以便在备用组播源服务器发生故障后,恢复主用组播源服务器对组播数据流的转发。
本实施例通过由主用组播源服务器检测流类型故障和链路故障,并在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。
图6为本发明第六实施例的系统结构示意图,包括组播源服务器61和网管服务器62;组播源服务器61用于当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并上报告警信息;网管服务器62用于在接收到所述告警信息后,将与所述组播源服务器关联的BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
其中,组播源服务器61可以如图4所示,网管服务器62可以如图5所示。
本实施例通过检测流类型故障和链路故障,并在上述故障后断开链路连接,并刷新映射表项,可以实现路由表的重新收敛及映射表的自动刷新,提高可服务性及中断的切换和自动恢复。
综上所述,本发明实施例采用主动检测组播数据流异常及链路异常,可以在上述异常时撤销近端组播路由,避免流类型故障或链路故障无法感知的问题,降低了网络中应用层故障对组播业务的影响。增加了组播源服务器与网管及相关联的网络设备BRAS之间的联动,可以在检测到故障时触发网管实时刷新映射表项,避免手工切换映射表引起的问题,提高了网络故障恢复的可服务性。本发明实施例对CPE没有特别的要求。可以降低网络配置的复杂度,提升IPTV业务的可靠性以及用户的满意度,降低运营商成本,为运营商带来了相应的经济价值。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (14)
1.一种网络电视IPTV增强组播可靠性的方法,其特征在于,包括:
检测组播数据流传输是否出现流类型故障或者链路故障;
当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后,将关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
2.根据权利要求1所述的方法,其特征在于,所述是否出现流类型故障或者链路故障,包括:
当在预先设定的采样周期内,检测到数据流量的变化率超出预先设定的阈值时,检测出流类型故障;
和/或,
定时向连接的路由器发送ping包,当未接收到所述路由器反馈的与所述ping包对应的响应时,检测出链路故障。
3.根据权利要求1所述的方法,其特征在于,还包括:建立与所述网管服务器之间的通信链路,以便通过所述通信链路上报所述告警信息,所述告警信息包括:告警源地址、告警时间、告警类型、告警原因、网络设备关联关系。
4.根据权利要求1-3任一项所述的方法,其特征在于,还包括:当流类型故障或者链路故障消除后,向所述网管服务器发送恢复正常消息,以便在备用组播源服务器发生故障后,恢复对组播数据流的转发。
5.一种网络电视IPTV增强组播可靠性的方法,其特征在于,包括:
接收主用组播源服务器发送的告警信息,所述告警信息为所述主用组播源服务器检测到组播数据流传输出现流类型故障或者链路故障后发送的;
将与所述主用组播源服务器关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
6.根据权利要求5所述的方法,其特征在于,还包括:当流类型故障或者链路故障消除后,接收所述主用组播源服务器发送的恢复正常消息,以便在备用组播源服务器发生故障后,恢复主用组播源服务器对组播数据流的转发。
7.一种组播源服务器,其特征在于,包括:
检测模块,用于检测组播数据流传输是否出现流类型故障或者链路故障;
告警模块,用于当检测到出现流类型故障或者链路故障时,断掉与路由器的通信连接,并向网管服务器上报告警信息,以使所述网管服务器在接收到所述告警信息后将关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
8.根据权利要求7所述的服务器,其特征在于,所述检测模块包括:
第一单元,用于当在预先设定的采样周期内,检测到数据流量的变化率超出预先设定的阈值时,检测出流类型故障;
和/或,
第二单元,用于定时向连接的路由器发送ping包,当未接收到所述路由器反馈的与所述ping包对应的响应时,检测出链路故障。
9.根据权利要求7所述的服务器,其特征在于,还包括:
建立模块,用于建立与所述网管服务器之间的通信链路,通过所述通信链路上报所述告警信息,所述告警信息包括:告警源地址、告警时间、告警类型、告警原因、网络设备关联关系。
10.根据权利要求7-9任一项所述的服务器,其特征在于,还包括:
恢复模块,用于当流类型故障或者链路故障消除后,向所述网管服务器发送恢复正常消息,以便在备用组播源服务器发生故障后,恢复对组播数据流的转发。
11.一种网管服务器,其特征在于,包括:
接收模块,用于接收主用组播源服务器发送的告警信息,所述告警信息为所述主用组播源服务器检测到组播数据流传输出现流类型故障或者链路故障后发送的;
更新模块,用于将与所述主用组播源服务器关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
12.根据权利要求11所述的服务器,其特征在于,还包括:
恢复模块,用于当流类型故障或者链路故障消除后,接收所述主用组播源服务器发送的恢复正常消息,以便在备用组播源服务器发生故障后,恢复主用组播源服务器对组播数据流的转发。
13.一种网络电视IPTV增强组播可靠性的系统,其特征在于,包括:
组播源服务器,用于当检测到出现流类型故障或者链路故障时,断掉路由器的通信连接,并上报告警信息;
网管服务器,用于在接收到所述告警信息后,将与所述组播源服务器关联的宽带接入服务器BRAS中的映射表中的组播源地址更新为备用组播源服务器的地址。
14.根据权利要求13所述的系统,其特征在于,
所述组播源服务器为权利要求7-10任一项所述的服务器;
和/或,
所述网管服务器为权利要求11或12所述的服务器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010101876306A CN102264001A (zh) | 2010-05-25 | 2010-05-25 | Iptv增强组播可靠性的方法、服务器及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010101876306A CN102264001A (zh) | 2010-05-25 | 2010-05-25 | Iptv增强组播可靠性的方法、服务器及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102264001A true CN102264001A (zh) | 2011-11-30 |
Family
ID=45010427
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2010101876306A Pending CN102264001A (zh) | 2010-05-25 | 2010-05-25 | Iptv增强组播可靠性的方法、服务器及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102264001A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103491555A (zh) * | 2012-06-13 | 2014-01-01 | 中国移动通信集团湖南有限公司 | 一种基于业务信息定位ip链路故障的方法、设备和系统 |
CN106100988A (zh) * | 2016-07-26 | 2016-11-09 | 安徽皖通邮电股份有限公司 | 一种实现链路聚合快速切换的方法 |
CN106559253A (zh) * | 2015-09-30 | 2017-04-05 | 中兴通讯股份有限公司 | 一种组播诊断方法及装置 |
CN107105337A (zh) * | 2017-02-27 | 2017-08-29 | 深圳市卓翼科技股份有限公司 | 无线多媒体播放方法和装置 |
CN107257496A (zh) * | 2017-06-14 | 2017-10-17 | 广州市千钧网络科技有限公司 | 一种直播的控制方法、装置及移动终端 |
TWI740547B (zh) * | 2020-05-13 | 2021-09-21 | 威盛電子股份有限公司 | 串流媒體同步播放方法及串流媒體同步播放系統 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101145924A (zh) * | 2006-09-13 | 2008-03-19 | 华为技术有限公司 | 实现ssm模式组播的方法、设备及系统 |
CN101163047A (zh) * | 2007-11-23 | 2008-04-16 | 上海华为技术有限公司 | 一种实现主设备和备用设备倒换的方法和装置 |
CN101192964A (zh) * | 2006-11-24 | 2008-06-04 | 中兴通讯股份有限公司 | 组播源主备倒换系统和方法 |
CN101202705A (zh) * | 2007-08-14 | 2008-06-18 | 华为技术有限公司 | 增强组播可靠性的方法和路由器 |
US20090010257A1 (en) * | 2007-07-06 | 2009-01-08 | Chaudhry Ather J | Method and apparatus for simultaneous support of fast restoration and native multicast in ip networks |
CN101651553A (zh) * | 2009-09-03 | 2010-02-17 | 华为技术有限公司 | 用户侧组播业务主备保护系统、方法及路由设备 |
-
2010
- 2010-05-25 CN CN2010101876306A patent/CN102264001A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101145924A (zh) * | 2006-09-13 | 2008-03-19 | 华为技术有限公司 | 实现ssm模式组播的方法、设备及系统 |
CN101192964A (zh) * | 2006-11-24 | 2008-06-04 | 中兴通讯股份有限公司 | 组播源主备倒换系统和方法 |
US20090010257A1 (en) * | 2007-07-06 | 2009-01-08 | Chaudhry Ather J | Method and apparatus for simultaneous support of fast restoration and native multicast in ip networks |
CN101202705A (zh) * | 2007-08-14 | 2008-06-18 | 华为技术有限公司 | 增强组播可靠性的方法和路由器 |
CN101163047A (zh) * | 2007-11-23 | 2008-04-16 | 上海华为技术有限公司 | 一种实现主设备和备用设备倒换的方法和装置 |
CN101651553A (zh) * | 2009-09-03 | 2010-02-17 | 华为技术有限公司 | 用户侧组播业务主备保护系统、方法及路由设备 |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103491555A (zh) * | 2012-06-13 | 2014-01-01 | 中国移动通信集团湖南有限公司 | 一种基于业务信息定位ip链路故障的方法、设备和系统 |
CN103491555B (zh) * | 2012-06-13 | 2016-08-10 | 中国移动通信集团湖南有限公司 | 一种基于业务信息定位ip链路故障的方法、设备和系统 |
CN106559253A (zh) * | 2015-09-30 | 2017-04-05 | 中兴通讯股份有限公司 | 一种组播诊断方法及装置 |
WO2017054558A1 (zh) * | 2015-09-30 | 2017-04-06 | 中兴通讯股份有限公司 | 一种组播诊断的方法及装置 |
CN106100988A (zh) * | 2016-07-26 | 2016-11-09 | 安徽皖通邮电股份有限公司 | 一种实现链路聚合快速切换的方法 |
CN107105337A (zh) * | 2017-02-27 | 2017-08-29 | 深圳市卓翼科技股份有限公司 | 无线多媒体播放方法和装置 |
CN107105337B (zh) * | 2017-02-27 | 2020-07-24 | 深圳市卓翼科技股份有限公司 | 无线多媒体播放方法和装置 |
CN107257496A (zh) * | 2017-06-14 | 2017-10-17 | 广州市千钧网络科技有限公司 | 一种直播的控制方法、装置及移动终端 |
TWI740547B (zh) * | 2020-05-13 | 2021-09-21 | 威盛電子股份有限公司 | 串流媒體同步播放方法及串流媒體同步播放系統 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1821491B1 (en) | A multicast realizing method in access device based on main and backup board switching | |
CN101651553B (zh) | 用户侧组播业务主备保护系统、方法及路由设备 | |
US8270294B2 (en) | Method and apparatus for implementing multicast service | |
CN102264001A (zh) | Iptv增强组播可靠性的方法、服务器及系统 | |
US8761002B2 (en) | Controlling multicast source selection in an anycast source audio/video network | |
CN101072154B (zh) | 以太环网切换方法 | |
EP1965545B9 (en) | Method for preventing the dispatch of dual multicast streams | |
US20080112324A1 (en) | Method, system and network device for exception handling of multicast service | |
CN101145930A (zh) | 保证组播业务可靠传输的方法、系统和设备 | |
CN103023665B (zh) | 一种组播业务保护的方法、网络设备和系统 | |
CN101202705A (zh) | 增强组播可靠性的方法和路由器 | |
CN101610210A (zh) | 具有冗余结构的组播传输系统及方法 | |
CN109862437B (zh) | 一种转发表项创建方法及bras | |
CN101674199A (zh) | 用于实现网络故障时切换的方法及查询器 | |
CN101909006A (zh) | 双向转发检测报文发送、接收方法及其装置与通信系统 | |
US8429465B2 (en) | Method, device and system for managing resources in networks | |
CN102130778A (zh) | 一种iptv组播业务保护方法及系统 | |
CN101902403A (zh) | 一种增强组播源可靠性的方法及其装置 | |
WO2014023192A1 (zh) | 交互式网络电视系统中点播服务不中断的方法及装置 | |
EP1863219B1 (en) | Method and system for processing abnormally becoming power off of a terminal of multicast user | |
CN101399681A (zh) | 组播节目的管理方法、装置及系统 | |
CN101483560A (zh) | 一种实现隧道检测的方法、装置和系统 | |
CN103402144A (zh) | 自动测量组播业务性能的方法、装置及系统 | |
CN102480479A (zh) | 一种业务处理方法和系统 | |
KR101144408B1 (ko) | 이중화 구조를 갖는 네트워크 접속 시스템 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20111130 |