[go: up one dir, main page]

WO2007071144A1 - Method for preventing the dispatch of the dual multicast stream - Google Patents

Method for preventing the dispatch of the dual multicast stream Download PDF

Info

Publication number
WO2007071144A1
WO2007071144A1 PCT/CN2006/002698 CN2006002698W WO2007071144A1 WO 2007071144 A1 WO2007071144 A1 WO 2007071144A1 CN 2006002698 W CN2006002698 W CN 2006002698W WO 2007071144 A1 WO2007071144 A1 WO 2007071144A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
top box
channel
address
igmp
Prior art date
Application number
PCT/CN2006/002698
Other languages
English (en)
French (fr)
Inventor
Dawei Yu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to CN2006800122962A priority Critical patent/CN101160831B/zh
Priority to ES06804924T priority patent/ES2378468T3/es
Priority to AT06804924T priority patent/ATE542331T1/de
Priority to EP06804924A priority patent/EP1965545B9/en
Publication of WO2007071144A1 publication Critical patent/WO2007071144A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast

Definitions

  • the present invention relates to a network television technology, and in particular, to a method for preventing a dual multicast stream from being delivered. Background of the invention
  • IPTV Internet Protocol Television
  • BTV BroadCast TV
  • the content of the default channel generally set the first channel to the default channel.
  • BTV is a multicast-based service that relies on multicast routing protocols supported by network devices, IGMP protocols (Internet Group Management Protocol), and IGMP PROXY protocols.
  • the IPTV system transmits the multicast program stream to the access network.
  • the router in the network runs a multicast routing protocol
  • the access network device runs the IGMP PROXY protocol.
  • the user terminal device of the IPTV system is an IP set-top box.
  • a channel list file is stored in the memory of the IP set-top box, and the main content of the channel list file is a multicast IP address and a multicast port number of the channel program that the user has permission to watch.
  • the IP set-top box queries the channel list file for the multicast address and the multicast port of the user to watch the channel program according to the instruction from the remote controller, and then according to the multicast address and the multicast port of the user to watch the channel program.
  • the RPC2236 document specifies that the IGMP Report message is applied to join the multicast group. After the IGMP PROXY is executed on all network devices, the multicast stream is obtained from the IPTV service source network.
  • the IP set-top box When the user needs to perform channel switching, the IP set-top box first follows the rules of the RFC2236 document. After the IGMP Leave message is sent to the current multicast group, the multicast stream of the current channel stops being sent. Then, the multicast list address and multicast port of the BTV program are queried in the channel list file, and then the RPC2236 is located. The specified group of IGMP Report messages is applied to join the new multicast group. The multicast stream of the new channel is sent to the set-top box.
  • the IP set-top box When the IP set-top box is switched from the BTV service to the other service, the IP set-top box first sends the IGMP Leave message to the current multicast group according to the requirements of the RFC2236 document. At this time, the multicast stream of the current channel stops being delivered, and then according to the user's The instruction issues a corresponding message to request a new service.
  • the IP set-top box on the market is carrying out the BTV service
  • the IP set-top box needs to be restarted due to abnormal conditions (sudden power failure, human power accidentally pressing the power button, etc.)
  • the existing technical solution is a group regardless of the abnormal situation.
  • the IP set-top box sends an IGMP Report message directly to the default channel of the BTV service.
  • the IP set-top box cannot send the IGMP Leave message to leave the current multicast group.
  • the probability that the current multicast group is the default channel for booting is small, and the probability is 1/the user has the right to watch the total number of BTV programs.
  • the IGMP Report message is sent to the multicast group of the default channel.
  • the multicast stream sent to the IP set-top box will continue to be sent. This is because :
  • the Digital Subscriber Line Access Multiplexer (DSLAM) device that delivers the multicast stream to the IP set-top box cannot know that the IP set-top box has an abnormality.
  • the DSLAM device must send an IGMP Query message and a specific group query message to determine whether the IP set-top box that joins the current multicast group is still active.
  • RFC 2236 specifies that the interval between IGMP Query messages is 125 seconds, and the maximum response time for responding to IGMP Query messages is 10 seconds. RFC2236 does not specify an exception when the general group query is sent after waiting for how long to send a specific group of query messages (each communication vendor The device will be different. After the IGMP Query message is sent, it will wait for about 20 seconds to send a specific group of query messages. As for the number of times and the interval for sending a specific group of query messages, RFC 2236 does not provide any regulations. The device will be different. Generally, the specific group query is sent twice, and the interval is 4 seconds.
  • the DSLAM device will send an IGMP Query message again. Then the DSLAM device sends two specific group query messages. Determines whether the multicast group member has been removed from the multicast group when the abnormality occurs. After that, the multicast stream sent to the IP set-top box when the abnormal situation occurs is stopped. That is, if the abnormal situation occurs after the DSLAM device sends an IGMP Query message and the IP set-top box returns the corresponding response message, the multicast stream sent to the IP set-top box will continue to be sent for about 144 seconds.cca
  • the DSLAM device will send two more IGMP Query messages, and then the DSLAM device sends the second group query message twice. To determine whether a multicast group member has left the multicast group when the abnormality occurs. Then, the multicast stream sent to the IP set-top box when the abnormal situation occurs is stopped. That is to say, if the abnormal situation occurs when the DSLAM device sends an IGMP Query message and the IP set-top box returns the corresponding response message, the multicast stream sent to the IP set-top box will continue to be sent for about 269 seconds.
  • the multicast stream sent to the IP set-top box lasts for about 144 seconds to 269 seconds.
  • the IP set-top box usually takes about 20 seconds to start and assemble the IGMP Report message and apply for the multicast group that is added to the default channel. Then, the multicast stream of the default channel is sent to the multicast stream. DP set top box. Obviously, at this time, the multicast stream when the abnormal situation occurs and the multicast stream of the default channel are simultaneously sent to the IP set-top box. This phenomenon can be called the phenomenon of discovery under dual multicast streams.
  • the discovery of the dual multicast stream typically lasts from 124 seconds to 249 seconds (in extreme cases, 119 seconds to 254 seconds).
  • the discovery of the image in the dual multicast stream will result in the following two adverse consequences: First, the bandwidth of the dual multicast stream will generally exceed the bandwidth of the service provided by the IPTV system to the user, and the multicast stream delivered to the IP set-top box is more serious.
  • the packet loss phenomenon the performance of the packet loss phenomenon is the picture stagnation, mosaic phenomenon;
  • the prior art has a problem that the system continuously delivers dual multicast streams to the IP set-top box for a long period of time, which seriously affects the picture quality, and may even cause the IP set-top box to be abnormally restarted, which greatly impairs the user experience and is obviously Reduce user satisfaction.
  • the technical problem to be solved by the present invention is to provide a dual-multicast stream that can prevent dual-multicast streams from being simultaneously affected by the problem of seriously affecting picture quality caused by the dual-multicast stream in the prior art and even causing an abnormal restart of the IP set-top box.
  • the method of delivery is to provide a dual-multicast stream that can prevent dual-multicast streams from being simultaneously affected by the problem of seriously affecting picture quality caused by the dual-multicast stream in the prior art and even causing an abnormal restart of the IP set-top box.
  • the invention discloses a method for preventing a dual multicast stream from being delivered, the method comprising: stopping sending a multicast stream to the IP set-top box when the IP set-top box is powered on.
  • the method for stopping the delivery of the multicast stream is as follows:
  • the IGMP Leave message is sent and sent according to the information set.
  • the DSLAM stops sending the multicast stream for the IGMP Leave message to the IP set-top box.
  • the information is the multicast IP address and multicast port number of the channel that was last stored before the power failure in the non-volatile memory of the IP set top box, and the verification information.
  • the method for stopping the delivery of the multicast stream is as follows:
  • the DSLAM queries whether it is currently sending a multicast stream to the IP set-top box, and stops transmitting the multicast stream to the IP set-top box when it determines that the multicast stream is being sent to the IP set-top box.
  • the method for stopping the delivery of the multicast stream is as follows:
  • the DSLAM Upon receiving the IGMP Report message from the IP set-top box, the DSLAM queries whether it is currently sending a multicast stream to the IP set-top box. If so, the DSLAM stops sending the multicast stream to the IP set-top box.
  • the method further includes:
  • the IP set-top box sends an IGMP Report message according to the content group of the channel list file stored in the IP set-top box, and joins the power-on default channel multicast group.
  • the method further includes:
  • At least one operation including channel switching, switching to non-BTV service, and shutdown is performed according to the received user instruction.
  • the operation performed is a channel switching, and the channel switching operation includes:
  • the IGMP Leave message to the current multicast group. Find the multicast IP address and multicast port number of the channel selected by the user in the channel list file. According to this, the IGMP Report is sent to join the new multicast group.
  • the operation performed is a channel switching, and the channel switching operation includes:
  • the IGMP Leave message is sent to the current multicast group.
  • the multicast IP address and multicast port number of the channel selected by the user in the channel list file are found.
  • the IGMP Report message is sent to join the new multicast group.
  • the corresponding information stored in the original multicast information is updated by using the multicast IP address, the multicast port number, and the verification information of the new multicast group.
  • the multicast IP address, multicast port number, and verification information of the new multicast group are updated with the corresponding information stored in the original multicast; otherwise, the originally stored information is not updated.
  • the IP address and multicast port number and the verification information are stored in a save information file of the file system of the nonvolatile memory or in a block of the file system of the nonvolatile memory.
  • the information is stored in a channel list file of a memory of the IP set top box, and the information includes: a multicast IP address and a multicast port number of all channels that the user has the right to watch;
  • the IGMP Leave message is sent in the same manner as the multicast IP address and the multicast port number of all the channels in the channel list file.
  • the method of the present invention can avoid the discovery of the dual multicast stream in the prior art, eliminate the damage picture quality caused by the dual multicast stream delivery, and even cause the IP set-top box to restart abnormally, effectively improving.
  • the user experience can significantly improve user satisfaction.
  • FIG. 1 is a flow chart showing the operation of an IP set top box according to a first preferred embodiment of the present invention
  • FIG. 2 is a flow chart showing the operation of an IP set top box according to a second preferred embodiment of the present invention.
  • FIG. 3 is a flow chart showing the operation of an IP set top box according to a third preferred embodiment of the present invention.
  • FIG. 4 is a flow chart showing the operation of an IP set top box according to a fourth preferred embodiment of the present invention.
  • FIG. 5 is a flow chart showing the operation of an IP set top box according to a fifth preferred embodiment of the present invention. Mode for carrying out the invention
  • FIG. 1 is a flowchart of the operation of an IP set top box according to a first preferred embodiment of the present invention. As shown in Figure 1, after the IP set-top box is powered on, it first sends an IGMP Leave message according to the information group saved by itself, so as to leave the multicast group where the abnormal situation occurs.
  • the information stored in the IP set-top box includes the multicast IP address and multicast port number of the multicast group that the user last switched the channel before the IP set-top box was shut down (or abnormal power-down occurred).
  • the DSLAM stops sending the multicast stream for the IGMP Leave message to the IP set-top box.
  • the multicast stream is the multicast stream that is delivered when the IP set-top box is abnormal. .
  • the IP set-top box can smoothly leave the multicast group where the power is lost after the power-on is started. After that, the IP set-top box can further send and send an IGMP Report message according to the content list of the saved channel list file, and add the default channel. Subsequent operations can then be continued according to user instructions, such as: switching channels, switching to non-BTV services, or shutting down.
  • FIG. 2 is a flowchart of the operation of an IP set top box according to a second preferred embodiment of the present invention.
  • a non-volatile memory with a file system is configured on the IP set-top box.
  • the file system usually has a Savelnfo.txt (other name) file for saving information. In practical applications, it can be utilized.
  • the SaveInfo.txt file stores the multicast IP address, multicast port number, and verification information of the multicast group to which the IP set-top box is currently attached.
  • the set-top box when the set-top box is powered on, the set-top box first detects whether the Savelnfo.txt file exists, if it exists, opens the file to read the information, and then closes the Savelnfo.txt file. After the information is verified, the information group is parsed into an IGMP Leave message and sent according to the IGMP Leave message format specified in the RFC2236 document.
  • the Savelnfo.txt file does not exist, you need to create a new Savelnfo.txt file and close the newly created Savelnfo.txt file after the build is complete. After that, the multicast stream that is delivered when the IP set-top box is abnormal will be stopped, which makes the discovery of the dual multicast stream in the prior art avoidable.
  • the IP set-top box can send an IGMP Report message according to the multicast IP address and multicast port information group of the power-on default channel recorded in its own channel list file, and then send it to the default channel. Multicast group.
  • the IP set-top box opens its own saved SaveInfo.txt file, writes the multicast IP address and multicast port number and verification information of the boot default channel to the SaveInfo.txt file, and then closes the file.
  • the multicast stream provided by the IP set-top box to the user is the multicast program of the default channel.
  • the IP set-top box may receive the following three commands:
  • the first instruction channel switching (internal switching of BTV services);
  • the second instruction performing service switching (switching between BTV services and non-BTV services that IP set-top boxes can provide);
  • the third instruction shutdown;
  • the IP set-top box can perform the corresponding processing process separately:
  • the IP set-top box first sends an IGMP Leave message to leave the current multicast group, and then according to the remote control device.
  • the instruction queries the multicast address and the multicast port number of the BTV program corresponding to the command in the channel list file stored in the command, and also sends an IGMP Report message according to the queried multicast address and the multicast port number group; Then, open the SaveInfo.txt file and clear the contents. Save the multicast IP address and multicast port number of the switched channel and the verification information in the SaveInfo.txt file and close the file.
  • the third processing procedure performed by the IP set-top box for the third command The IP set-top box first sends the IGMP Leave message to leave the current multicast group, and then performs the shutdown process.
  • the IP set-top box may receive an instruction to perform service switching (ie, switching from BTV service to non-BTV service) or shutting down. If the service switching instruction is received, the IP set top box performs the second processing procedure described above; if the shutdown command is received, the IP set top box performs the third processing described above.
  • service switching ie, switching from BTV service to non-BTV service
  • the IP set-top box may receive an instruction to switch from the non-BTV service to the BTV service or to shut down. If the command to switch from the non-BTV service to the BTV service is received, the IP set-top box performs the following steps in the first process, but does not need to send the IGMP Leave message in the first process to leave the current multicast group. Operation; If a shutdown command is received, the IP set-top box directly performs the shutdown process.
  • the process shown in Figure 2 is based on the existence of a file system on the non-volatile memory. If the file system does not exist on the non-volatile memory, as another implementation manner, the multicast IP address, the multicast port number, and the verification information of the current multicast group may be saved in a block of the IP set-top box. The information is saved, read or updated by calling the block's operational interface function.
  • the boot default channel and other channels are placed in the same position for processing.
  • the IP set-top box is booting the default frequency when an abnormal situation occurs.
  • the phenomenon that the multicast stream of the two default channels is delivered to the IP set-top box does not occur. Therefore, the multicast IP address and multicast port number of the default channel and the verification information may not be saved during the service development of the IP set-top box.
  • the multicast IP address and multicast port number of the default channel and the verification information can be omitted from writing to Savelnfo.txt (or Block block).
  • the IP set-top box can also determine whether the current multicast channel is the default channel after booting, after saving the multicast IP address and multicast port number and verifying the information to the Savelnfo.txt file. , you can omit the operation of writing the multicast IP address and multicast port number of the default channel and the check information into Savelnfo.txt (or Block); otherwise, you need to switch the multicast IP of the new channel.
  • the address and multicast port number and checksum information are written to Savelnfo.txt (or Block).
  • the channel list file is generally stored in the memory of the IP set top box, and the channel list file stores the multicast IP address, multicast port number, and other related channel information of the channel program that the user is entitled to watch.
  • FIG. 2 proposes a method for saving related information in the file system of the non-volatile memory; and also provides a non-volatile memory.
  • An alternative to the file system a method for saving the multicast IP address and multicast port number of the boot default channel and the checksum information to the Savelnfo.txt file is also provided; plus the checksum information is also considered. Therefore, the IP set-top box working method shown in FIG. 2 has remarkable effectiveness and high stability.
  • the key point of the process shown in Figure 2 is: save the multicast IP address and multicast port number and check information of the channel program when performing BTV service; read the saved related information when the IP set-top box starts up under abnormal conditions. I put out the IGMP Leave message and send it in the same group. The IGMP Leave message is sent before the IGMP Report message, so that the discovery of the dual multicast stream in the prior art can be avoided.
  • FIG. 3 is a flowchart of the operation of an EP set top box according to a third preferred embodiment of the present invention.
  • the IP set-top box when it is necessary to start up due to any situation (including abnormal conditions), the IP set-top box composes the IGMP Leave message corresponding to the channel that the user has the right to watch according to the content in the channel list file stored by the IP set-top box. Issued in order.
  • the above operation mode enables the IP set-top box to actively leave the multicast group where the abnormal situation occurs.
  • the IP set-top box can send an IGMP Report message according to the multicast IP address and the multicast port number of the boot default channel recorded in the channel list file stored in the IP set-top file, and join the multicast group of the default channel.
  • the IP set-top box can continue the subsequent operations according to the received user command, such as: channel switching, switching to non-BTV service or shutdown.
  • the process shown in FIG. 3 adopts the method of traversing the channel list file to ensure that the IGMP Leave message corresponding to all the channels that the user has the right to watch can be sent in succession, so as to terminate the multicast that is still delivered after the abnormality of the IP set-top box is terminated.
  • flow Assume that the number of multicast channels that the user has the right to watch is 100. The time that the set-top box sends a single IGMP Leave message for the 100 multicast channels can be controlled to be less than the order of milliseconds. Considering the processing capability of the DSLAM device and the network congestion, you can set the interval for sending IGMP Leave messages to 1 millisecond. In this way, all the IGMP Leave messages can be sent in 0.1 seconds after the IP set-top box is powered on. The IP set-top box can terminate the multicast stream that is still being delivered after the abnormal situation can be terminated in a short time.
  • the communication entity sent by the network side can also actively stop the multicast stream sent when the IP set-top box is powered on, so as to avoid the discovery of the dual multicast stream. Specific operation The process is shown in Figure 4 and Figure 5.
  • FIG. 4 is a flowchart of the operation of an IP set top box according to a fourth preferred embodiment of the present invention.
  • the IP set-top box negotiates with the broadband access server through the relevant protocol, and the broadband access server allocates the IP set-top box for support after successful negotiation.
  • the IP address of the communication at the same time, the broadband access server can notify the DSLAM IP set-top box that the network set-top box has successfully accessed the network by sending a message or the like.
  • the DSLAM Upon receiving the notification from the broadband access server, the DSLAM queries whether it is currently transmitting a multicast stream to the IP set-top box and stops transmitting the multicast stream to the IP set-top box when it is determined that the multicast stream is being sent to the IP set-top box.
  • the IP set-top box can send the IGMP Report message according to the content of the channel list file stored in the IP set-top box and send it to the default channel multicast group.
  • the DSLAM determines that no multicast stream is currently being sent to the IP set-top box, the DSLAM can perform its own other operations in accordance with the prior art.
  • the IP set-top box can also send IGMP Report messages according to the content group of the channel list file stored in the IP set-top box and send them to the default channel multicast group.
  • FIG. 5 is a flowchart of an operation of an IP set top box according to a fourth preferred embodiment of the present invention.
  • the IP set-top box negotiates with the broadband access server through the relevant protocol, and the broadband access server allocates the IP set-top box for support after successful negotiation.
  • the IP set-top box spells the IGMP Report message according to the content group of the channel list file stored by itself, and requests to join the power-on default channel multicast group.
  • the DSLAM When receiving the IGMP Report message from the IP set-top box, the DSLAM queries whether it is currently sending a multicast stream to the IP set-top box. If so, the DSLAM stops sending the multicast stream to the IP set-top box, and can further reject the IP set-top box to join the boot default channel. Multicast group please Otherwise; the DSLAM allows the IP set-top box to join the requested power-on default channel multicast group. As shown in FIG. 4 and FIG. 5, when the IP set-top box is powered on due to an abnormal situation, the DSLAM on the network side can actively stop the multicast stream sent to the IP set-top box when the abnormal situation is sent, so as to avoid the dual multicast stream being sent. phenomenon.
  • the method for preventing the dual multicast stream from being sent by the present invention can avoid the discovery of the image in the dual multicast stream in the prior art, and eliminate the damaged picture quality caused by the dual multicast stream delivery, and even cause the IP set top box.
  • the abnormal restart phenomenon effectively improves the user experience and can significantly improve user satisfaction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Description

一种防止双组播流下发的方法
技术领域
本发明涉及网络电视技术，具体涉及一种防止双組播流下发的方法。 发明背景
网际协议电视 ( IPTV ) (也称网絡电视）是一种基于 Internet技术的 个性化、 交互式服务的崭新的媒体形态。 BTV(BroadCast TV广播电视） 是 IPTV系統最基本的业务， 也是目前业界运行最成熟的业务。 运营商 基于节目预告、 品牌宣传和商业广告的考虑， 通常设置一个开机默认频 道， 在该开机默认频道节目里放置节目预告、 品牌宣传和商业广告的内 容，使得 IP机顶盒上电开机就能接收开机默认频道的内容， 一般把第一 频道设置为开机默认频道。
BTV是基于组播的业务， 依赖于网络设备所支持的组播路由协议、 IGMP协议 (Internet组管理协议)、 IGMP PROXY协议等。 IPTV系统将 组播节目流传送至接入网络， 一般采取网络中路由器运行组播路由协 议， 接入网络设备运行 IGMP PROXY协议。
IPTV系统的用户终端设备就是 IP机顶盒， 在 IP机顶盒的存储器中 一般都保存有频道列表文件， 该频道列表文件的主要内容是用户有权限 观看的频道节目的组播 IP地址、组播端口号以及频道其它相关信息的列 表。 当用户进行 BTV业务时， IP机顶盒根据来自遥控器的指令在频道 列表文件中查询出用户欲观看频道节目的组播地址和組播端口， 再根据
RPC2236文档的规定組拼 IGMP Report报文申请加入组播组， 经过各级 网络设备执行 IGMP PROXY后， 从 IPTV业务源网络获取组播流。
当用户需要进行频道切换时， IP机顶盒首先根据 RFC2236文档的规 定组拼 IGMP Leave报文离开当前组播组， 此时当前频道的組播流停止 下发； 再在频道列表文件中查询出用户欲观看 BTV节目的組播地址和 组播端口，然后 居 RPC2236文档的规定组拼 IGMP Report报文申请加 入新组播组， 此时新频道的组播流下发到机顶盒。
当 IP机顶盒从 BTV业务切换到其它业务时， IP机顶盒首先才艮据 RFC2236文档的规定组拼 IGMP Leave报文离开当前组播组， 此时当前 频道的组播流停止下发， 然后根据用户的指令发出相应报文来请求新的 业务。
目前市场上的 IP机顶盒在开展 BTV业务时， 当 IP机顶盒因异常情 况（突然掉电、 人力误按电源按钮等） 需要重新开机上电时， 现有的技 术方案是不论异常情况发生时的组播流是否已经停止下发， IP机顶盒启 动后便直接发送 IGMP Report报文加入 BTV业务的开机默认频道。
在上述异常情况发生的瞬间， IP 机顶盒没有办法通过发送 IGMP Leave报文来离开当前组播组。 同时当前组播组是开机默认频道的机率 很小， 该机率是 1/用户有权限观看 BTV节目总数。
当 IP机顶盒开机启动后直接发送 IGMP Report报文加入开机默认频 道的组播组时，所述异常情况发生时正向 IP机顶盒下发的组播流一^:还 会继续下发； 这是因为： 当异常情况发生时， 向 IP机顶盒下发组播流的 数字用户线接入复接器 （DSLAM )设备无法获知 IP机顶盒已经发生异 常。在实际应用中， DSLAM设备必须通过发送通用组查询（ IGMP Query ) 报文和特定组查询报文来确定加入当前组播组的 IP机顶盒是否还处于 活动状态。
RFC2236规定了 IGMP Query报文的时间间隔为 125秒， 对 IGMP Query报文进行响应的最大等待时间为 10秒。 RFC2236没有规定异常时 通用组查询发出之后等待多长时间再发特定组查询报文（各个通信厂商 的设备会有所不同 ,一般 IGMP Query报文发出之后等待 20秒左右再发 特定组查询报文）； 至于特定组查询报文发送的次数和发送间隔， RFC2236也没有做出规定（各个通信厂商的设备会有所不同， 一般特定 组查询 4艮文发送两次， 发送的间隔为 4秒）。
如果异常情况发生在 DSLAM设备发出 IGMP Query报文之后、 IP 机顶盒返回相应的响应报文之前， 则 DSLAM设备还会再发一次 IGMP Query报文， 然后 DSLAM设备再发两次特定組查询报文来确定异常情 况发生时的组播组成员是否已经离开组播组； 之后， 才会停止下发异常 情况发生时向 IP机顶盒下发的组播流。也就是说，如果异常情况发生在 DSLAM设备发出 IGMP Query报文之后、 IP机顶盒返回相应的响应报 文之前， 则异常情况发生时向 IP机顶盒下发的组播流还会持续下发约 144秒„
如果异常情况发生在 DSLAM设备发出 IGMP Query报文、 IP机顶 盒返回相应的响应 ^艮文时，那么 DSLAM设备还会再发两次 IGMP Query 报文， 然后 DSLAM设备再发两次特定组查询报文来确定异常情况发生 时的组播组成员是否已经离开组播组； 之后， 才会停止下发异常情况发 生时向 IP机顶盒下发的组播流。也就是说，如果异常情况发生在 DSLAM 设备发出 IGMP Query报文、 IP机顶盒返回相应的响应报文时， 则异常 情况发生时向 IP机顶盒下发的组播流还会持续下发约 269秒。
由以上所述可见， 当 IP机顶盒发生异常情况时， 向 IP机顶盒下发 的組播流还会持续约 144秒到 269秒。
另外， 在异常情况发生后， IP机顶盒通常需要 20秒左右的时间启 动并组拼 IGMP Report报文以及申请加入开机默认频道的组播组， 这时 便会有开机默认频道的組播流下发到 DP机顶盒。显然，此时就出现了异 常情况发生时的组播流和开机默认频道的组播流同时下发到 IP机顶盒 的现象， 可以将这种现象称为双组播流下发现象。
所述双组播流下发现象通常会持续 124秒到 249秒 (极端情况下为 119秒到 254秒)。 双组播流下发现象会导致以下两个不良后果： 第一， 由于双组播流的带宽一般都会超过 IPTV系统提供给用户的业务运营带 宽，导致下发到 IP机顶盒的组播流存在比较严重的丢包现象，丟包现象 的表现就是画面停滞、 马赛克现象； 第二， 由于双组播流同时下发到 IP 机顶盒， 因此 IP机顶盒的业务处理性能会受到影响， 轻则导致 IP机顶 盒播放不顺畅， 重则导致 IP机顶盒异常重启。
综上所述，现有技术存在着长时间内系统持续下发双组播流到 IP机 顶盒的问题， 严重影响了画面质量， 甚至会导致 IP机顶盒异常重启， 极 大地损害了用户体验， 会明显降低用户满意度。 发明内容
有鉴于此， 本发明要解决的技术问题在于： 针对现有技术中的双组 播流所引起的严重影响画面质量、 甚至导致 IP机顶盒异常重启的问题， 提供一种能防止双组播流同时下发的方法。
为达到上述目的， 本发明的技术方案是这样实现的：
本发明公开了一种防止双组播流下发的方法， 该方法包括： 在 IP机顶盒开机启动时， 停止向该 IP机顶盒下发组播流。
停止下发所述组播流的方法为：
IP 机顶盒在开机启动后， 根据自身保存的信息组拼并发送 IGMP Leave报文； 收到来自 IP机顶盒的 IGMP Leave报文时， DSLAM停止 向 IP机顶盒发送 IGMP Leave报文所针对的组播流。
所述信息是保存在 IP机顶盒的非易失存储器中的掉电前最近一次 所在频道的组播 IP地址和組播端口号以及校验信息。 停止下发所述组播流的方法为：
获知 IP机顶盒已成功接入网络时， DSLAM查询当前是否正在向 IP 机顶盒发送组播流， 并在确定正在向 IP机顶盒发送组播流时停止向 IP 机顶盒发送该组播流。
停止下发所述组播流的方法为：
在收到来自 IP机顶盒的 IGMP Report报文时， DSLAM查询当前是 否正在向 IP机顶盒发送組播流， 如果是， DSLAM就停止向 IP机顶盒 发送组播流。
该方法进一步包括：
IP机顶盒根据自身存储的频道列表文件的内容组拼并发送 IGMP Report报文， 加入开机默认频道组播组。
该方法进一步包括：
根据接收到的用户指令执行包括频道切换、切换到非 BTV业务、关 机中的至少一个操作。
执行的所述操作为频道切换， 该频道切换操作包括：
发送 IGMP Leave报文离开当前组播组； 找出频道列表文件中用户 所选频道的组播 IP地址和组播端口号， 据此组拼并发送 IGMP Report 才艮文加入新组播组。
执行的所述操作为频道切换， 该频道切换操作包括：
发送 IGMP Leave报文离开当前组播组； 找出频道列表文件中用户 所选频道的组播 IP地址和组播端口号， 据此组拼并发送 IGMP Report 报文加入新组播组。
加入所述新组播组时，用该新组播组的组播 IP地址和组播端口号及 校验信息更新原来存储的相应信息；
或者， 判断用户所选频道是否是开机默认频道， 如果不是， 则用该 新组播组的組播 IP地址和组播端口号及校验信息更新原来存储的相应 信息； 否则， 不对原来存储的所述信息进行更新。
所述 IP地址和组播端口号以及校验信息是保存在所述非易失存储 器的文件系统的保存信息文件中， 或是保存在所述非易失存储器的文件 系统的块中。
所述信息保存在 IP机顶盒的存储器的频道列表文件中， 该信息包 括： 用户有权观看的全部频道的组播 IP地址和组播端口号；
所述组拼并发送 IGMP Leave报文是根据频道列表文件中的全部频 道的组播 IP地址和组播端口号依次组拼并发送一遍 IGMP Leave报文。
与现有技术相比， 实施本发明方法可避免现有技术中的双组播流下 发现象， 消除因双组播流下发所造成的损伤画面质量、甚至导致 IP机顶 盒异常重启的现象， 有效改善了用户体验， 并能明显提高用户满意度。 附图简要说明
图 1为本发明第一较佳实施例的 IP机顶盒工作流程图；
图 2为本发明第二较佳实施例的 IP机顶盒工作流程图；
图 3为本发明第三较佳实施例的 IP机顶盒工作流程图；
图 4为本发明第四较佳实施例的 IP机顶盒工作流程图；
图 5为本发明第五较佳实施例的 IP机顶盒工作流程图。 实施本发明的方式
下面结合附图及具体实施例对本发明详细说明。
本发明的总体构思为： 当 IP机顶盒开机启动时先发送 IGMP Leave 报文离开异常情况发生时所在的组播组， 以便从根本上解决双组播流同 时下发的问题。 参见图 1 , 图 1为本发明第一较佳实施例的 IP机顶盒工作流程图。 如图 1所示， 当 IP机顶盒上电开机启动后，首先^ ^据自身保存的信息組 拼并发送 IGMP Leave报文， 以离开发生异常情况时所在的组播组。 保 存在 IP机顶盒中的所述信息包含了 IP机顶盒关机 (或发生异常掉电情况) 前用户最后一次所切换频道的组播組的组播 IP地址和组播端口号等内 容。 在收到来自 IP机顶盒的 IGMP Leave报文时， DSLAM就会停止向 IP机顶盒发送 IGMP Leave报文所针对的組播流，该組播流就是 IP机顶 盒发生异常情况时被下发的组播流。
显然， 基于上述操作， 当 IP机顶盒正在进行 BTV业务时如果发生 异常掉电，那么 IP机顶盒在开机启动后则可以顺利离开掉电时所在的组 播组。 在此之后， IP机顶盒还可以进一步根据自身保存的频道列表文件 内容组拼并发送 IGMP Report报文， 加入开机默认频道。 之后还可以根 据用户指令继续后续操作， 如： 切换频道、 切换到非 BTV 业务或关机 等。
参见图 2, 图 2为本发明第二较佳实施例的 IP机顶盒工作流程图。 通常， IP机顶盒上都会配置一个设置有文件系统的非易失性存储器， 该 文件系统中则通常设置有 Savelnfo.txt (也可以采用其它名称）文件用于 保存信息； 在实际应用中， 可以利用所述 SaveInfo.txt文件保存 IP机顶 盒当前所加入的组播组的组播 IP地址和组播端口号以及校验信息等。
根据图 2所示， 当机顶盒开机启动时， 机顶盒首先检测 Savelnfo.txt 文件是否存在， 如果存在便打开该文件读取信息， 之后再关闭 Savelnfo.txt文件。 在读取的信息通过校验后， 根据 RFC2236文档规定 的 IGMP Leave报文格式将读取的信息组拼成 IGMP Leave报文并发送。 当然， 如果不存在 Savelnfo.txt文件， 则需要新建 Savelnfo.txt文件， 并 在建立完成后关闭新建的 Savelnfo.txt文件。 在此之后， IP机顶盒发生异常情况时被下发的组播流将被停止发送， 这使得现有技术中的双组播流下发现象得以避免。
在发送了 IGMP Leave报文之后， IP机顶盒便可以根据自身的频道 列表文件中记录的开机默认频道的组播 IP 地址和组播端口信息组拼 IGMP Report报文并发送， 从而加入开机默认频道的组播组。 接着， IP 机顶盒打开自身存储的 SaveInfo.txt文件， 将开机默认频道的组播 IP地 址和组播端口号以及校验信息写入到 SaveInfo.txt文件中，随后关闭该文 件。此时， IP机顶盒提供给用户的组播流就是开机默认频道的组播节目。
在开展开机默认频道的组播业务时， IP机顶盒可能会接收到以下三 种指令：
第一种指令： 进行频道切换（BTV业务内部的切换）；
第二种指令：进行业务切换（ BTV业务和 IP机顶盒能提供的非 BTV 业务之间的切换）；
第三种指令： 关机；
对于上述三种指令， IP机顶盒能够分别进行相应的处理过程： IP机顶盒对于第一种指令所进行的第一处理过程： IP机顶盒首先发 送 IGMP Leave报文离开当前组播組， 再根据来自遥控器的指令在自身 存储的频道列表文件中查询出指令所对应的 BTV节目的组播地址和组 播端口号， 还根据查询出的组播地址和组播端口号组拼 IGMP Report报 文并发送； 接着， 打开 SaveInfo.txt文件并清空其中的内容， 将切换后频 道的組播 IP地址和组播端口号以及校验信息保存在 SaveInfo.txt文件中 再关闭该文件。
可见，每次进行频道切换时都需要用新频道的组播 IP地址和組播端 口号以及校验信息对 SaveInfo.txt 文件中的原信息进行更新。 该 SaveInfo.txt文件更新操作通常是必要并且重要的。 当然， 如果 IP机顶 盒新切换到的频道是开机默认频道， 则不一定要更新 SaveInfo.txt文件。 IP机顶盒对于第二种指令所进行的第二处理过程： 当要从 BTV业 务切换到非 BTV业务时， IP机顶盒首先发送 IGMP Leave报文离开当前 组播组， 然后根据收到的指令发出相应报文以请求非 BTV业务。
IP机顶盒对于第三种指令所进行的第三处理过程： IP机顶盒首先发 送 IGMP Leave报文离开当前组播组， 然后执行关机流程。
在上述的第一处理过程完成后， 即当 IP机顶盒完成频道切换操作 后， IP机顶盒可能会接收到进行业务切换（即从 BTV业务切换到非 BTV 业务）或者关机的指令。 如果接收到业务切换指令， IP机顶盒则进行 上述的第二处理过程； 如果接收到关机指令， IP机顶盒则进行上述的第 三处理过程。
在上述的第二处理过程完成后， 即 IP机顶盒从 BTV业务切换到非 BTV业务后， IP机顶盒可能会接收从非 BTV业务切换到 BTV业务或者 关机的指令。如果接收到从非 BTV业务切换到 BTV业务的指令时， IP 机顶盒则基本按照上述的第一处理过程的步骤进行， 只不过不用进行第 一处理过程中的发送 IGMP Leave报文离开当前组播组的操作； 如果接 收到关机指令， IP机顶盒则直接执行关机流程即可。
图 2所示流程是以非易失性存储器上存在文件系统为前提的。 如果 非易失性存储器上不存在文件系统 , 作为另一种实施方式， 可以将当前 組播组的组播 IP地址和组播端口号以及校验信息保存到 IP机顶盒的块 (Block)中， 通过调用 Block的操作接口函数， 对信息进行保存、 读取或 更新。
另外， 在图 2所示流程中， 在保存组播 IP地址和组播端口号以及校 验信息到 Savelnfo.txt文件时，是把开机默认频道和其它频道放在同等的 地位进行处理的。其实，在异常情况发生时 IP机顶盒正进行开机默认频 道的 BTV业务、 并且开机后 IP机顶盒要加入开机默认频道的组播组的 情况下， 根据组播原理， 并不会出现两个开机默认频道的组播流被下发 到 IP机顶盒的现象， 因此开机默认频道的组播 IP地址和組播端口号以 及校验信息在 IP机顶盒的业务开展过程中是可以不保存的。
例如，可以在 IP机顶盒开机启动后第一次加入开机默认频道的组播 组时，省略将开机默认频道的组播 IP地址和组播端口号以及校验信息写 入 Savelnfo.txt (或 Block块)中这一操作。 此外， IP机顶盒还可以在切换 频道之后、 保存组播 IP地址和組播端口号以及校验信息到 Savelnfo.txt 文件之前， 判断当前所在的组播频道是否是开机默认频道， 如果是开机 默认频道，则可以省略将开机默认频道的组播 IP地址和组播端口号以及 校验信息写入 Savelnfo.txt (或 Block块)中这一操作； 否则， 就需要将切 换后新频道的组播 IP 地址和组播端口号以及校验信息写入 Savelnfo.txt (或 Block块)中。
IP机顶盒的存储器中一般都保存有频道列表文件， 该频道列表文件 中保存有用户有权观看的频道节目的组播 IP地址、组播端口号以及其它 相关频道信息。
可见， 为了实现 IP机顶盒在发送 IGMP Report拫文之前发送 IGMP Leave报文， 图 2提出了在非易失性存储器的文件系统中保存相关信息 的方法； 并且还提供了非易失性存储器中不存在文件系统时的替代方 案；另外还提供了不将开机默认频道的组播 IP地址和组播端口号以及校 验信息保存到 Savelnfo.txt文件的方法； 再加上校验信息也得到了考虑， 所以图 2所示的 IP机顶盒工作方法具有显著的有效性和很高的稳定性。
显然， 图 2所示流程的关键点是：保存进行 BTV业务时频道节目的 组播 IP地址和組播端口号以及校验信息； 当 IP机顶盒在异常情况下开 机启动时把保存的相关信息读出并组拼成 IGMP Leave报文， 并在发送 IGMP Report报文之前先发送所述 IGMP Leave报文，从而使现有技术中 的双组播流下发现象得以避免。
参见图 3, 图 3为本发明第三较佳实施例的 EP机顶盒工作流程图。 图 3中， 当由于任何情况（包括异常情况）需要开机启动时， IP机顶盒 根据自身存储的频道列表文件中的内容， 按照先后顺序组拼用户有权观 看的频道所对应的 IGMP Leave报文并按序发出。 上述操作方式可以使 IP机顶盒主动离开异常情况发生时所在的组播组。
接着， IP机顶盒可以根据自身存储的频道列表文件中记录的开机默 认频道的组播 IP地址和组播端口号信息组拼并发送 IGMP Report报文， 加入开机默认频道的组播組。
在此之后 , IP机顶盒还可以根据接收到的用户指令继续后续操作， 如： 频道切换、 切换到非 BTV业务或关机等。
可见， 图 3所示流程采取遍历频道列表文件的方式以确保能够先后 发送用户有权观看的所有频道所对应的 IGMP Leave报文， 以便终止 IP 机顶盒发生异常情况后仍被继续下发的组播流。 假定用户有权观看的组 播频道数目为 100个， Π>机顶盒针对这 100个组播频道发送单个 IGMP Leave报文的时间可被控制在毫秒数量级以下。 考虑到 DSLAM设备的 处理能力以及网络拥塞情况， 可以将发送 IGMP Leave报文的时间间隔 设置为 1毫秒； 这样， IP机顶盒开机后只需 0.1秒的时间就能够完成所 有 IGMP Leave报文的发送， 使得 IP机顶盒可以用很短的时间就能终止 异常情况后仍被继续下发的组播流。
由以上所述可见，图 1至图 3均是以 IP机顶盒主动发送 IGMP Leave 报文的方式， 避免双組播流下发现象。
实际上，也可以由网络侧的通信实体在 IP机顶盒开机启动后主动停 止下发异常情况时所下发的组播流， 以避免双组播流下发现象。 具体操 作过程如图 4、 图 5所示。
参见图 4, 图 4为本发明第四较佳实施例的 IP机顶盒工作流程图。 如图 4所示， 当由于任何情况（包括异常情况）开机启动时， IP机顶盒 都会和宽带接入服务器通过相关协议进行协商， 并由宽带接入服务器在 协商成功后为 IP机顶盒分配用于支持通信的 IP地址； 与此同时， 宽带 接入服务器可以以发送消息等方式通知 DSLAM IP机顶盒已成功接入网 络。
收到来自宽带接入服务器的通知时， DSLAM 查询当前是否正在向 IP机顶盒发送组播流， 并在确定正在向 IP机顶盒发送组播流时停止向 IP机顶盒发送该組播流。 当 IP机顶盒不再收到来自 DSLAM的組播流 时， IP 机顶盒可以根据自身存储的频道列表文件的内容组拼 IGMP Report报文并发送， 加入开机默认频道组播组。
当然，如果 DSLAM确定当前没有向 IP机顶盒发送组播流， DSLAM 则可以按照现有技术执行自身的其它操作。 在这种情况下， IP机顶盒同 样可以根据自身存储的频道列表文件的内容组拼 IGMP Report报文并发 送， 加入开机默认频道组播组。
参见图 5， 图 5为本发明第四较佳实施例的 IP机顶盒工作流程图。 如图 5所示， 当由于任何情况（包括异常情况）开机启动时， IP机顶盒 都会和宽带接入服务器通过相关协议进行协商， 并由宽带接入服务器在 协商成功后为 IP机顶盒分配用于支持通信的 IP地址； 接着， IP机顶盒 根据自身存储的频道列表文件的内容组拼 IGMP Report报文并发送， 请 求加入开机默认频道组播組。
当收到来自 IP机顶盒的 IGMP Report报文时， DSLAM查询当前是 否正在向 IP机顶盒发送组播流， 如果是， DSLAM就停止向 IP机顶盒 发送组播流，还可以进一步拒绝 IP机顶盒加入开机默认频道组播組的请 求；否则， DSLAM就允许 IP机顶盒加入所请求的开机默认频道组播组。 由图 4、 图 5可见， 在 IP机顶盒因发生异常情况而开机启动时， 网 络侧的 DSLAM可以主动停止下发异常情况时向 IP机顶盒所下发的组播 流， 以避免双组播流下发现象。
综上所述， 本发明所提供的防止双組播流下发的方法可避免现有技 术中的双组播流下发现象， 消除因双組播流下发所造成的损伤画面质 量、 甚至导致 IP机顶盒异常重启的现象， 有效改善了用户体验， 并能明 显提高用户满意度。

Claims

权利要求书
1、 一种防止双組播流下发的方法， 其特征在于， 该方法包括： 在网际协议 IP机顶盒开机启动时，停止向该 IP机顶盒下发组播流。
2、根据权利要求 1所述的方法， 其特征在于， 停止下发所述組播流 的方法为：
IP机顶盒在开机启动后， 根据自身保存的信息组拼并发送 IGMP Leave报文； 收到来自 IP机顶盒的 IGMP Leave报文时， DSLAM停止 向 IP机顶盒发送 IGMP Leave报文所针对的组播流。
3、 根据权利要求 2 所述的方法， 其特征在于， 所述信息是保存在 IP机顶盒的非易失存储器中的掉电前最近一次所在频道的組播 IP地址 和组播端口号以及校验信息。
4、根据杈利要求 1所述的方法， 其特征在于， 停止下发所述組播流 的方法为：
获知 IP机顶盒已成功接入网络时， DSLAM查询当前是否正在向 IP 机顶盒发送组播流， 并在确定正在向 IP机顶盒发送组播流时停止向 IP 机顶盒发送该组播流。
5、根据权利要求 1所述的方法， 其特征在于， 停止下发所述組播流 的方法为：
在收到来自 IP机顶盒的 IGMP Report报文时 , DSLAM查询当前是 否正在向 IP机顶盒发送组播流， 如果是， DSLAM就停止向 IP机顶盒 发送組播流。
6、根据权利要求 1至 5任一项所述的方法， 其特征在于， 该方法进 一步包括：
IP机顶盒根据自身存储的频道列表文件的内容组拼并发送 IGMP Report报文 , 加入开机默认频道组播组。
7、根据权利要求 1至 5任一项所述的方法， 其特征在于， 该方法进 一步包括：
根据接收到的用户指令执行包括频道切换、切换到非 BTV业务、关 机中的至少一个操作。
8、根据杈利要求 7所述的方法， 其特征在于， 执行的所述操作为频 道切换， 该频道切换操作包括：
发送 IGMP Leave报文离开当前组播组； 找出频道列表文件中用户 所选频道的组播 IP地址和组播端口号， 据此组拼并发送 IGMP Report 报文加入新組播組。
9、根据杈利要求 7所述的方法， 其特征在于， 执行的所述操作为频 道切换， 该频道切换操作包括：
发送 IGMP Leave报文离开当前组播组； 找出频道列表文件中用户 所选频道的组播 IP地址和组播端口号， 据此組拼并发送 IGMP Report 才艮文加入新组播组。
10、 根据权利要求 8或 9所述的方法， 其特征在于， 加入所述新组 播组时，用该新组播组的组播 IP地址和组播端口号及校验信息更新原来 存储的相应信息；
或者， 判断用户所选频道是否是开机默认频道， 如果不是， 则用该 新组播组的组播 IP地址和组播端口号及校验信息更新原来存储的相应 信息； 否则， 不对原来存储的所述信息进行更新。
11、 根据权利要求 3、 8或 9所述的方法， 其特征在于， 所述 IP地 址和組播端口号以及校验信息是保存在所述非易失存储器的文件系统 的保存信息文件中， 或是保存在所述非易失存储器的文件系统的块中。
12、根据权利要求 2所述的 IP机顶盒的工作方法， 其特征在于， 所 述信息保存在 IP机顶盒的存储器的频道列表文件中，该信息包括： 用户 有权观看的全部频道的组播 IP地址和组播端口号；
所述组拼并发送 IGMP Leave报文是根据频道列表文件中的全部频 道的组播 IP地址和組播端口号依次组拼并发送一遍 IGMP Leave拫文。
PCT/CN2006/002698 2005-12-19 2006-10-13 Method for preventing the dispatch of the dual multicast stream WO2007071144A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN2006800122962A CN101160831B (zh) 2005-12-19 2006-10-13 一种防止双组播流下发的方法
ES06804924T ES2378468T3 (es) 2005-12-19 2006-10-13 Método que permite impedir la distribución de un doble flujo de datos de multidifusión
AT06804924T ATE542331T1 (de) 2005-12-19 2006-10-13 Verfahren zur verhinderung der aussendung doppelte multicast-stroms
EP06804924A EP1965545B9 (en) 2005-12-19 2006-10-13 Method for preventing the dispatch of dual multicast streams

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2005101210046A CN100536467C (zh) 2005-12-19 2005-12-19 Ip机顶盒的工作方法
CN200510121004.6 2005-12-19

Publications (1)

Publication Number Publication Date
WO2007071144A1 true WO2007071144A1 (en) 2007-06-28

Family

ID=37133779

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/002698 WO2007071144A1 (en) 2005-12-19 2006-10-13 Method for preventing the dispatch of the dual multicast stream

Country Status (7)

Country Link
US (1) US7751395B2 (zh)
EP (3) EP2530878B1 (zh)
CN (2) CN100536467C (zh)
AT (1) ATE542331T1 (zh)
ES (1) ES2378468T3 (zh)
FR (1) FR2895192B1 (zh)
WO (1) WO2007071144A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4765952B2 (ja) * 2007-02-15 2011-09-07 ソニー株式会社 マルチキャスト配信システム、クライアント機器、上位ルータ制御装置、コンテンツの表示方法およびプログラム
JP4752786B2 (ja) * 2007-02-15 2011-08-17 ソニー株式会社 マルチキャスト配信システムおよびマルチキャスト配信方法
US20090022064A1 (en) * 2007-07-18 2009-01-22 Moshe Oron Method and apparatus for monitoring multicast bandwidth to a user
KR100884061B1 (ko) 2007-08-30 2009-02-19 한양대학교 산학협력단 멀티캐스트 전송 환경에서의 그룹 탈퇴 방법 및 이를지원하는 장치
KR100895880B1 (ko) 2007-08-30 2009-04-30 한양대학교 산학협력단 멀티캐스트 전송 환경에서의 그룹 탈퇴 방법 및 이를지원하는 호스트 장치
CN100583997C (zh) * 2007-10-19 2010-01-20 深圳华为通信技术有限公司 网络电视的业务启动方法、装置和系统以及网络电视终端
WO2009069737A1 (ja) * 2007-11-30 2009-06-04 Sharp Kabushiki Kaisha 放送受信装置
CN101494548B (zh) * 2009-03-02 2011-07-13 中兴通讯股份有限公司 减少网络电视组播断流时间的方法和装置
US9059919B1 (en) * 2011-03-28 2015-06-16 Symantec Corporation Systems and methods for preserving network settings for use in a pre-boot environment
CN102318272B (zh) * 2011-06-29 2013-12-18 华为技术有限公司 一种进程组中的异常组成员离开的方法
CN103581708A (zh) 2012-07-31 2014-02-12 中兴通讯股份有限公司 机顶盒开机广告播放的方法和系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1119134A2 (en) 1999-12-21 2001-07-25 Alcatel Canada Inc. Method and apparatus for an improved internet group management protocol
EP1427132A2 (en) 2002-12-06 2004-06-09 Alcatel Canada Inc. Method and device for multicast group management
EP1429489A2 (en) 2002-12-12 2004-06-16 Alcatel Canada Inc. Method and device for multicast group management
WO2004086245A1 (en) * 2003-03-20 2004-10-07 Thomson Licensing S.A. System and method for utilizing multicast ip and ehternet to locate and distribute a satellite signal
CN1592487A (zh) * 2003-06-24 2005-03-09 阿尔卡特公司 具有改进的认证、授权、计费和配置控制的dsl接入网络
US20050220132A1 (en) * 2004-03-30 2005-10-06 Packetfront Sweden Ab Multicast

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6983478B1 (en) * 2000-02-01 2006-01-03 Bellsouth Intellectual Property Corporation Method and system for tracking network use
US20050028206A1 (en) * 1998-06-04 2005-02-03 Imagictv, Inc. Digital interactive delivery system for TV/multimedia/internet
US20020150094A1 (en) * 2000-10-27 2002-10-17 Matthew Cheng Hierarchical level-based internet protocol multicasting
US20030145102A1 (en) * 2002-01-29 2003-07-31 Alcatel, Societe Anonyme Facilitating improved reliability of internet group management protocol through the use of acknowledge messages
US7272652B1 (en) * 2002-04-30 2007-09-18 Alcatel Lucent Facilitating accelerated processing of internet group management protocol messages
JP4420399B2 (ja) * 2002-08-16 2010-02-24 トムソン ライセンシング マルチキャスト・データの存在下でのダウンロードの最適化
CN2583891Y (zh) * 2002-09-29 2003-10-29 上海广电信息产业股份有限公司 使机顶盒具有记录第一次使用时间的装置
US7254608B2 (en) * 2002-10-31 2007-08-07 Sun Microsystems, Inc. Managing distribution of content using mobile agents in peer-topeer networks
US20040090970A1 (en) * 2002-11-11 2004-05-13 Sanchez Cheryl A. Distribution of data flows to local loop subscribers by an access multiplexer
US20070044123A1 (en) * 2005-08-16 2007-02-22 Alcatel System and method for smoothing channel changing in internet protocol television systems

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1119134A2 (en) 1999-12-21 2001-07-25 Alcatel Canada Inc. Method and apparatus for an improved internet group management protocol
EP1427132A2 (en) 2002-12-06 2004-06-09 Alcatel Canada Inc. Method and device for multicast group management
EP1429489A2 (en) 2002-12-12 2004-06-16 Alcatel Canada Inc. Method and device for multicast group management
WO2004086245A1 (en) * 2003-03-20 2004-10-07 Thomson Licensing S.A. System and method for utilizing multicast ip and ehternet to locate and distribute a satellite signal
CN1592487A (zh) * 2003-06-24 2005-03-09 阿尔卡特公司 具有改进的认证、授权、计费和配置控制的dsl接入网络
US20050220132A1 (en) * 2004-03-30 2005-10-06 Packetfront Sweden Ab Multicast

Also Published As

Publication number Publication date
CN101160831B (zh) 2010-05-19
EP1965545B1 (en) 2012-01-18
EP1965545A1 (en) 2008-09-03
ES2378468T3 (es) 2012-04-12
CN1852311A (zh) 2006-10-25
CN100536467C (zh) 2009-09-02
EP1965545A4 (en) 2009-06-17
CN101160831A (zh) 2008-04-09
ATE542331T1 (de) 2012-02-15
EP2458791B1 (en) 2015-04-01
EP2530878A1 (en) 2012-12-05
EP1965545B9 (en) 2012-04-18
US20070147373A1 (en) 2007-06-28
EP2458791A3 (en) 2012-08-29
EP2530878B1 (en) 2014-01-08
US7751395B2 (en) 2010-07-06
EP2458791A2 (en) 2012-05-30
FR2895192A1 (fr) 2007-06-22
FR2895192B1 (fr) 2011-05-27

Similar Documents

Publication Publication Date Title
WO2007071144A1 (en) Method for preventing the dispatch of the dual multicast stream
EP1821491B1 (en) A multicast realizing method in access device based on main and backup board switching
AU2010256136B2 (en) Channel switching processing method, system and related devices
WO2007118405A1 (fr) Dispositif, système et procédé d'exécution de la mise à niveau à distance d'un logiciel
KR101477202B1 (ko) 모바일 텔레비전 시스템을 위한 액세스 네트워크 핸드오버
US8270294B2 (en) Method and apparatus for implementing multicast service
WO2011103837A2 (zh) 服务器故障时的报文处理方法及路由器
EP2296314B1 (en) Configuring application method, device and system
TWI444022B (zh) 裝置中已被中斷的下載會期之恢復方法及電腦程式產品
WO2010127599A1 (zh) 组播业务断开后快速恢复的方法、装置及网关设备
WO2010099687A1 (zh) 减少网络电视组播断流时间的方法和装置
WO2012159287A1 (zh) 数据传输方法和设备
US20070274310A1 (en) Method and system for processing abnormally becoming power off of a terminal of multicast user
WO2010025635A1 (zh) 一种播放切换方法、媒体服务器、用户终端和系统
WO2011131098A1 (zh) 一种设备调度方法、装置及系统
KR101235093B1 (ko) 스트리밍 데이터 전달
WO2024212774A1 (zh) 数据传输方法及装置、电子设备、存储介质
WO2004079580A1 (ja) データ配信方法及びデータ配信システム
CN110892686A (zh) 向音频/视频接收器设备提供信息的方法和对应的装置
TW201001971A (en) System and method for multicasting with redundant structure
KR19980075491A (ko) 영상배달 서비스시스템에 있어서 비디오스트림 서버 제어방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200680012296.2

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2006804924

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2006804924

Country of ref document: EP