At present, a multicast service is provided on a networking model generally over a multicast video network including a video headend system (i.e. headend system), an IP Metropolitan Area Network (MAN) (i.e. core device), an access network (edge device), and a home network.
The video headend system implements functions such as video subscriber management, Condition Access (CA)/Digital Rights Management (DRM), video coding, and transmits a video stream to an IP MAN. Signals of a TV and a broadcast channel are encoded into one-path stream by means of the MPEG-2 and the one-path stream is encapsulated in a User Datagram Protocol (UDP)/IP packet. The IP MAN transmits a video stream to a broadband access network by means of an IP multicast function. The access network implements the process of joining and leaving a video group, and sends the video stream required to the user.
The access network may include a Layer 2 switch and a Digital Subscriber Line Access Multiplexer (DSLAM). The Layer 2 switch includes an Asynchronous Transfer Mode (ATM) switch or an Ethernet switch. The access network connects with users via physical lines such as a Fast Ethernet (FE) or an x Digital Subscriber Line (xDSL). The IP MAN sends a video stream to an edge device to which a user connects, such as a multicast router, a Layer 2 switch or a DSLAM, and the video stream is sent to users according to an Internet Group Management Protocol (IGMP) control packet.
At present, a PC or a Set Top Box (STB) joins the multicast programs as a user device through a multicast protocol, IGMP (V1, V2 or V3). The IGMP is a protocol over an IP protocol and in parallel with the IP protocol, and defines two entities, a client and a multicast router. The two entities are a video terminal and an access device with respect to the above network.
Based on an IGMP protocol, a host is able to report that the host wants to join or leave a multicast group to a multicast router. For example, when joining the multicast group, a host sends a “membership report” message to a local multicast router, and makes an appropriate preparation of its own IP module so as to receive data transmitted from the multicast group.
Before developing a multicast service, it is necessary to configure different port-based multicast rights at a DSLAM. A user is able to access multicast contents listed in a multicast right list of the user. When accessing other contents, the user will be rejected without any content to be returned.
In a DSL-based Internet Protocol Television (IPTV), since DSL line bandwidth changes randomly, the bandwidth reduction or off-line will occur when a DSL line is affected by instantaneous external interference. In accordance with the dynamic multicast bandwidth control, a random packet loss will occur in the videos of all programs when the bandwidth requirement for a DSL line has exceeded the downlink bandwidth of the DSL line, thereby influencing the program that a user is watching.
At present, in the procedure of developing a multicast service by a user terminal, there is no IGMP-based feedback channel in a server end since the current IGMP protocol only supports a unidirectional process initiated by a user.
In this way, the network side only simply rejects a request from a user or randomly discards a multicast packet sent to a video terminal of the user under an abnormal condition, and thus there will be a blank screen in the video terminal of the user. That is to say, it is impossible for the network side to notify a user of a reason that the user is unable to watch a video program or the quality of the video program watched by the user is impaired, thereby influencing the user's satisfaction of a multicast video service.