A broadcasting gigabit IPTV groupcast disaster recovery method based on data network redundancy

Abstract

This invention relates to a disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy. The invention determines whether a multicast receiving OLT has failed; calculates the available bandwidth of the data network for the multicast receiving OLT; selects at least one candidate OLT as a set of multicast providing OLTs based on a comprehensive selection priority from high to low; allocates the selected program channels to the multicast providing OLTs in the multicast providing OLT set; issues multicast stream forwarding instructions to the multicast providing OLTs and multicast stream receiving instructions to the multicast receiving OLTs; supplements or cancels program channels according to scheduling priority weights; and when normal operation is confirmed for several consecutive cycles, the multicast input source of the multicast receiving OLT is switched back from the data network channel to the unidirectional IP multicast network program by program. This invention utilizes existing data network channels and, without adding any hardware, upgrades multicast disaster recovery capabilities from primary and backup dual redundancy to triple redundancy including the data network channel, thereby reducing the risk of outages.

Description

Technical Field

[0001] This invention relates to the field of computer network communication and IPTV (Internet Protocol Television) service protection technology, and in particular to a disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy. Background Technology

[0002] The cable television network is currently undergoing fiber optic and IP-based transformation. Under unicast mode, metropolitan area networks are prone to significant service pressure in high-concurrency live broadcast scenarios, making it difficult to support the large-scale deployment of terminals such as IP set-top boxes and TV software terminals.

[0003] To meet the transmission requirements of high-bitrate live streaming services such as 4K and 8K, typical broadcast data networks usually adopt a three-layer architecture consisting of a core layer, an aggregation layer, and an access layer. The IP multicast transmission network operates at the aggregation layer, connecting to the access layer OLT (Optical Line Terminal) equipment, pushing the multicast stream to the OLT uplink port, and the user end pulls the multicast stream from the OLT through the ONU (Optical Network Unit) to watch the program.

[0004] However, existing redundancy mechanisms in unidirectional multicast networks typically rely on primary and backup physical links, which can only cope with single-point link failures. In extreme cases where both the primary and backup links are interrupted simultaneously, the existing primary-backup redundancy mechanism cannot continue to provide live multicast streams to users under the failed OLT, easily causing widespread outages.

[0005] Meanwhile, during disaster recovery switching, different program channels vary in importance, pricing, number of viewers, and video quality. Simply forwarding all program channels in a bandwidth-constrained data network channel may crowd out normal data service bandwidth; conversely, simply cutting channels without distinguishing their importance makes it difficult to guarantee user experience and operational revenue. Summary of the Invention

[0006] Therefore, the technical problem to be solved by the present invention is to overcome the problems in the prior art where the redundancy capability of unidirectional IP multicast networks depends on the primary physical link and the backup physical link, it is difficult to cope with extreme failures where the primary and backup links are interrupted at the same time, and it is impossible to provide fine-grained protection for multicast programs within the limited data network bandwidth after a failure.

[0007] To address the aforementioned technical problems, this invention provides a disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy, comprising: The unidirectional multicast input status of each OLT is periodically detected to obtain the multicast list, real-time traffic of the unidirectional multicast input port, and physical layer status of the multicast input port of each OLT. The multicast list comparison difference rate is determined based on the multicast list, the input traffic deviation is determined based on the real-time traffic, and the multicast receiving OLT is jointly determined to determine whether a fault has occurred based on the physical layer status, the multicast list comparison difference rate, and the input traffic deviation. In response to a failure of the multicast receiving OLT, the available bandwidth of the data network for the multicast receiving OLT is calculated; wherein, the available bandwidth of the data network is the bandwidth that can be used for multicast stream disaster recovery transmission; Candidate OLTs are determined from OLTs with normal multicast input status. Based on the topological distance between the candidate OLT and the multicast receiving OLT, the available bandwidth of the candidate OLT's data network, and the available bandwidth of the multicast receiving OLT's data network, the overall selection priority of the candidate OLT is calculated. At least one candidate OLT is selected as the multicast providing OLT set based on the overall selection priority from high to low. Calculate scheduling priority weights for all program channels being watched by online users under the multicast receiving OLT, sort the program channels in descending order according to the scheduling priority weights, filter program channels based on the available bandwidth of the data network of the multicast receiving OLT, and allocate the filtered program channels to the multicast providing OLTs in the set of multicast providing OLTs. The multicast providing OLT sends a multicast stream forwarding instruction and a multicast stream receiving instruction to the multicast receiving OLT, so that the multicast providing OLT forwards the multicast stream corresponding to the filtered program channel to the multicast receiving OLT through the data network channel. The multicast receiving OLT injects the received multicast stream into the local multicast distribution module and pushes it to the user side. During disaster recovery operation, monitor the changes in available bandwidth of the data network of the multicast providing OLT and the multicast receiving OLT. When the change in available bandwidth of the data network exceeds the adjustment threshold, trigger dynamic rescheduling and supplement or cancel program channels according to the scheduling priority weight. When the unidirectional multicast input status of the multicast receiving OLT is confirmed to have returned to normal for several consecutive cycles, the multicast input source of the multicast receiving OLT is switched back from the data network channel to the unidirectional IP multicast network program by program.

[0008] In one embodiment of the present invention, the multicast list comparison difference rate is determined according to the following formula: ; in, For the first Multicast list comparison difference rate of each OLT The union of the multicast lists across the entire network. For the first Multicast list of each OLT; The input flow deviation is determined according to the following formula: ; in, For the first Input flow deviation of each OLT For the first Real-time traffic of the unidirectional multicast input port of an OLT. The median value of the input traffic for an OLT with normal multicast input status.

[0009] In one embodiment of the present invention, determining whether a multicast receiving OLT has malfunctioned based on the physical layer state, the multicast list comparison difference rate, and the input traffic deviation includes: When the physical layer status of the unidirectional multicast input port is "link disconnected", it is directly determined that the corresponding OLT has experienced a multicast input failure. When the physical layer status of the unidirectional multicast input port is normal, and the multicast list comparison difference rate of the corresponding OLT exceeds the difference rate threshold and the input traffic deviation exceeds the traffic deviation threshold, it is determined that the corresponding OLT has a multicast input failure. If only one of the multicast list comparison difference rate and the input traffic deviation is abnormal, the detection frequency is increased, and after a preset number of consecutive abnormalities, it is determined that the corresponding OLT has a multicast input failure.

[0010] In one embodiment of the present invention, the available bandwidth of the data network of the multicast receiving OLT is determined according to the following formula: ; ; in, The available bandwidth of the data network for the multicast receiving OLT, The total bandwidth of the data network port of the multicast receiving OLT. The bandwidth used for the data network port of the multicast receiving OLT is [not specified]. To reserve bandwidth, This represents the current peak traffic for data services. This is a reserved coefficient.

[0011] In one embodiment of the present invention, the comprehensive selection priority of the candidate OLT is determined according to the following formula: ; in, For the first The overall selection priority of each candidate OLT For the first Topological distance parameters between each candidate OLT and the multicast receiving OLT. For the first Available bandwidth for the data network of each candidate OLT The available bandwidth of the data network for the multicast receiving OLT is specified. The topology distance parameter is 0 when the candidate OLT and the multicast receiving OLT are at the same level, and 1 when the candidate OLT and the multicast receiving OLT are at the next or previous level, and increases progressively according to the topology level.

[0012] In one embodiment of the present invention, selecting at least one candidate OLT as a multicast-providing OLT set based on the comprehensive selection priority from high to low includes: The candidate OLTs are sorted in descending order according to the comprehensive selection priority, and the candidate OLT with the highest comprehensive selection priority is selected first. When the available bandwidth of a single candidate OLT's data network does not meet the available bandwidth requirement of the multicast receiving OLT, candidate OLTs are added sequentially from high to low according to the comprehensive selection priority until the cumulative available bandwidth of the selected candidate OLTs meets the available bandwidth requirement of the multicast receiving OLT.

[0013] In one embodiment of the present invention, the scheduling priority weight is determined according to the following formula: ; in, For the first The scheduling priority weight of each program channel Assigning weight to the program's importance For the weight of paid attributes, Weighting based on user preference For clarity weight, For the first The importance value of each program channel. For the first The value of the charging attribute for each program channel. For the first User preference values ​​for each program channel. For the first The resolution value for each program channel.

[0014] In one embodiment of the present invention, assigning the selected program channels to the multicast providing OLTs in the multicast providing OLT set includes: When the set of multicast providing OLTs includes multiple multicast providing OLTs, the transmission quota is determined according to the proportion of available bandwidth of the data network of each multicast providing OLT. The program channels arranged in descending order according to the scheduling priority weight are allocated to each multicast providing OLT according to the transmission quota, and the allocation bitrate of each multicast providing OLT does not exceed the corresponding transmission quota. The transmission quota is determined according to the following formula: ; in, For the first Each multicast provides the OLT with a transmission quota. For the first Multicast provides the available bandwidth for the OLT's data network. Provides an OLT collection for multicast. The sum of the available bandwidth of the data networks of each multicast-providing OLT in the multicast-providing OLT set.

[0015] In one embodiment of the present invention, when the change in available bandwidth of the data network exceeds an adjustment threshold, dynamic rescheduling is triggered, and program channels are supplemented or canceled according to the scheduling priority weight, including: When available bandwidth increases, program channels are added from the unscheduled program channels in descending order of scheduling priority weight, and the cumulative bitrate of the newly added program channels does not exceed a preset proportion of the bandwidth increase. When available bandwidth decreases, program channels are removed from the end of the currently scheduled program channel sequence according to the scheduling priority weight from low to high, until the released bitrate is not less than the amount of bandwidth reduction.

[0016] In one embodiment of the present invention, switching the multicast input source of the multicast receiving OLT back from the data network channel program-by-program to the unidirectional IP multicast network includes: After the multicast receiving OLT meets the conditions of normal physical layer status of multicast input port, multicast list comparison difference rate lower than difference rate threshold and input traffic deviation lower than traffic deviation threshold for multiple consecutive detection cycles, the multicast input source of program channel is switched one by one at preset time intervals. After all program channels have switched back, a stop forwarding instruction is sent to each multicast providing OLT in the multicast providing OLT set, and the scheduling status of the multicast receiving OLT is reset to normal mode.

[0017] The technical solution of the present invention has the following advantages compared with the prior art: The present invention describes a disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy. By utilizing existing data network channels and OLT management servers (IPTV monitoring and scheduling servers), without adding any hardware equipment, the multicast disaster recovery capability is upgraded from primary and backup dual redundancy to triple redundancy (two primary and backup paths of the 10 Gigabit multicast network and one path of the broadcast data network), which can reduce the risk of outages.

[0018] This invention detects multicast list discrepancies, input traffic deviations, and the physical layer status of multicast input ports. It also combines increased detection frequency and continuous confirmation mechanisms for single-item anomalies, balancing detection speed and accuracy, and reducing unnecessary switching caused by momentary jitter.

[0019] The multicast OLT selection process of this invention considers both available bandwidth and topological distance. By comprehensively prioritizing the selection of OLTs with sufficient bandwidth and closer distance, it can reduce cross-node transmission latency and improve network load balancing.

[0020] This invention performs multi-factor weighted scheduling of program channels, taking into account program importance, charging attributes, user preference, and clarity, and prioritizes high-value and high-demand programs within the limited data network bandwidth, thereby balancing user viewing experience and operational revenue.

[0021] When the bandwidth of a single OLT is insufficient, this invention can automatically enable multiple OLTs to cooperate in transmission and allocate program channels according to the proportion of available bandwidth of the data network of each multicast OLT, thus breaking through the bandwidth bottleneck of a single node.

[0022] This invention can sense bandwidth changes in real time during disaster recovery operation and dynamically increase or decrease the number of transmitted programs without interrupting existing streams that have not been cut, thus balancing the stability of normal data services and the effectiveness of multicast disaster recovery; after the fault is recovered, the program is smoothly switched back one by one to avoid instantaneous traffic surges. Attached Figure Description

[0023] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0024] Figure 1 This is a flowchart of the disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy in this invention.

[0025] Figure 2 This is a network architecture diagram of the cable TV 10 Gigabit IPTV multicast disaster recovery method based on data network redundancy in Embodiment 2 of the present invention. Detailed Implementation

[0026] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0027] Example 1 Reference Figure 1 As shown, this embodiment provides a disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy, including: S1. Periodically detect the unidirectional multicast input status of each OLT to obtain the multicast list, real-time traffic of the unidirectional multicast input port, and physical layer status of the multicast input port of each OLT. Determine the multicast list comparison difference rate based on the multicast list, determine the input traffic deviation based on the real-time traffic, and jointly determine whether the multicast receiving OLT has failed based on the physical layer status, the multicast list comparison difference rate, and the input traffic deviation.

[0028] Specifically, the multicast list comparison difference rate is determined according to the following formula: ; in, For the first Multicast list comparison difference rate of each OLT The union of the multicast lists across the entire network. For the first Multicast list of each OLT; The input flow deviation is determined according to the following formula: ; in, For the first Input flow deviation of each OLT For the first Real-time traffic of the unidirectional multicast input port of an OLT. The median value of the input traffic for an OLT with normal multicast input status.

[0029] Specifically, the determination of whether a multicast receiving OLT has failed is based on the physical layer state, the multicast list comparison difference rate, and the input traffic deviation, including: When the physical layer status of the unidirectional multicast input port is "link disconnected", it is directly determined that the corresponding OLT has experienced a multicast input failure. When the physical layer status of the unidirectional multicast input port is normal, and the multicast list comparison difference rate of the corresponding OLT exceeds the difference rate threshold (0.1 in this embodiment) and the input traffic deviation exceeds the traffic deviation threshold (0.3 in this embodiment), it is determined that the corresponding OLT has a multicast input failure. If only one of the multicast list comparison difference rate and the input traffic deviation is abnormal, the detection frequency is increased, and after a preset number of consecutive abnormalities, the corresponding OLT is determined to have a multicast input fault. In this embodiment, the detection frequency is increased to 1 / 2 of the period T, and a fault is determined after 3 consecutive abnormalities.

[0030] S2. In response to a failure of the multicast receiving OLT, calculate the available bandwidth of the data network of the multicast receiving OLT; wherein, the available bandwidth of the data network is the bandwidth that can be used for multicast stream disaster recovery transmission.

[0031] Specifically, the available bandwidth of the data network of the multicast receiving OLT is determined according to the following formula: ; ; in, The available bandwidth of the data network for the multicast receiving OLT, The total bandwidth of the data network port of the multicast receiving OLT. The bandwidth used for the data network port of the multicast receiving OLT is [not specified]. To reserve bandwidth, This represents the current peak traffic for data services. To reserve a coefficient, this embodiment uses 1.2.

[0032] S3. Determine candidate OLTs from the OLTs with normal multicast input status, and calculate the comprehensive selection priority of the candidate OLTs based on the topological distance between the candidate OLT and the multicast receiving OLT, the available bandwidth of the candidate OLT's data network and the available bandwidth of the multicast receiving OLT's data network. Select at least one candidate OLT as the multicast providing OLT set based on the comprehensive selection priority from high to low.

[0033] Specifically, the overall selection priority of the candidate OLTs is determined according to the following formula: ; in, For the first The overall selection priority of each candidate OLT For the first Topological distance parameters between each candidate OLT and the multicast receiving OLT. For the first Available bandwidth for the data network of each candidate OLT The available bandwidth of the data network for the multicast receiving OLT is specified. The topology distance parameter is 0 when the candidate OLT and the multicast receiving OLT are at the same level, and 1 when the candidate OLT and the multicast receiving OLT are at the next or previous level, and increases progressively according to the topology level.

[0034] This scoring formula allows for the selection of OLTs with ample bandwidth and the shortest topological distance, balancing transmission efficiency and network load balancing.

[0035] Specifically, at least one candidate OLT is selected as the multicast-providing OLT set based on the comprehensive selection priority from high to low, including: The candidate OLTs are sorted in descending order according to the comprehensive selection priority, and the candidate OLT with the highest comprehensive selection priority is selected first. When the available bandwidth of a single candidate OLT's data network does not meet the available bandwidth requirement of the multicast receiving OLT, candidate OLTs are added sequentially from high to low according to the comprehensive selection priority until the cumulative available bandwidth of the selected candidate OLTs meets the available bandwidth requirement of the multicast receiving OLT.

[0036] S4. Calculate the scheduling priority weight for all online users watching program channels under the multicast receiving OLT, sort the program channels in descending order according to the scheduling priority weight, filter the program channels based on the available bandwidth of the data network of the multicast receiving OLT, and allocate the filtered program channels to the multicast providing OLT in the multicast providing OLT set.

[0037] Specifically, the scheduling priority weights are determined according to the following formula: ; in, For the first The scheduling priority weight of each program channel Assigning weight to the program's importance For the weight of paid attributes, Weighting based on user preference For clarity weight, For the first The importance value of each program channel. For the first The value of the charging attribute for each program channel. For the first User preference values ​​for each program channel. For the first The resolution value for each program channel.

[0038] In this embodiment, the program importance value is 1.0 when the program channel is a key program (such as news and variety shows), and 0.3 when the program channel is a regular program; the charging attribute value is 1.0 when the program channel is a paid program, and 0.2 when the program channel is a free program; the user preference value is normalized to [0,1] based on the ratio of the number of users currently watching the corresponding program channel under the multicast receiving OLT to the total number of online users; the resolution value is 1.0 when the program channel is an ultra-high definition (4K / 8K) program, 0.6 when the program channel is a high definition program, and 0.3 when the program channel is a standard definition program.

[0039] Specifically, assigning the selected program channels to the multicast providing OLTs in the multicast providing OLT set includes: When the set of multicast providing OLTs includes multiple multicast providing OLTs, the transmission quota is determined according to the proportion of available bandwidth of the data network of each multicast providing OLT. The program channels arranged in descending order according to the scheduling priority weight are allocated to each multicast providing OLT according to the transmission quota, and the allocation bitrate of each multicast providing OLT does not exceed the corresponding transmission quota. The transmission quota is determined according to the following formula: ; in, For the first Each multicast provides the OLT with a transmission quota. For the first Multicast provides the available bandwidth for the OLT's data network. Provides an OLT collection for multicast. The sum of the available bandwidth of the data networks of each multicast-providing OLT in the multicast-providing OLT set.

[0040] S5. Send a multicast stream forwarding instruction to the multicast providing OLT and a multicast stream receiving instruction to the multicast receiving OLT, so that the multicast providing OLT forwards the multicast stream corresponding to the filtered program channel to the multicast receiving OLT through the data network channel. The multicast receiving OLT injects the received multicast stream into the local multicast distribution module and pushes it to the user side.

[0041] Specifically, the multicast stream forwarding instruction includes a list of multicast streams to be forwarded, the data network address of the multicast receiving OLT, and the upper limit of transmission bandwidth; the multicast stream list includes the multicast address and port number of the program channel; the multicast stream receiving instruction includes the source address, the receiving port, and the local processing method, wherein the local processing method is to inject the multicast stream received by the data network channel into the IGMP (Internet Group Management Protocol) multicast distribution module and bridge it to the user-side port.

[0042] S6. During disaster recovery operation, monitor the changes in available bandwidth of the data network of the multicast providing OLT and the multicast receiving OLT at a period of T (10 seconds in this embodiment). When the change in available bandwidth of the data network exceeds the adjustment threshold (15% by default in this embodiment), trigger dynamic rescheduling and supplement or cancel program channels according to the scheduling priority weight.

[0043] Specifically, when the change in available bandwidth of the data network exceeds the adjustment threshold, dynamic rescheduling is triggered, and program channels are added or removed according to the scheduling priority weight, including: When available bandwidth increases, program channels are added from the unscheduled program channels in descending order of scheduling priority weight, and the cumulative bitrate of the newly added program channels does not exceed a preset proportion of the bandwidth increase. When available bandwidth decreases, program channels are removed from the end of the currently scheduled program channel sequence according to the scheduling priority weight from low to high, until the released bitrate is not less than the amount of bandwidth reduction.

[0044] The above adjustment process can switch programs without interruption, only increasing or decreasing the number of programs, so that the programs that users are watching and have not been cut can always remain smooth.

[0045] S7. When the unidirectional multicast input state of the multicast receiving OLT is confirmed to have returned to normal for several consecutive cycles (3 cycles by default in this embodiment), the multicast input source of the multicast receiving OLT is switched back from the data network channel to the unidirectional IP multicast network program by program.

[0046] Specifically, switching the multicast input source of the multicast receiving OLT back from the data network channel program-by-program to the unidirectional IP multicast network includes: After the multicast receiving OLT meets the conditions of normal physical layer status of multicast input port, multicast list comparison difference rate lower than difference rate threshold and input traffic deviation lower than traffic deviation threshold for multiple consecutive detection cycles, the multicast input source of program channel is switched one by one at preset time intervals. After all program channels have switched back, a stop forwarding instruction is sent to each multicast providing OLT in the multicast providing OLT set, and the scheduling status of the multicast receiving OLT is reset to normal mode.

[0047] Example 2 This embodiment provides a disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy. A metropolitan area network has six 10 Gigabit OLT devices connected to its aggregation layer, numbered sequentially as follows: to Each OLT communicates with each other via a 10 Gigabit data network, while each OLT also receives live multicast streams via an independent unidirectional IP multicast network. The IPTV monitoring and scheduling server 440 connects to the management interfaces of all OLTs via an out-of-band management network for status acquisition, fault diagnosis, and scheduling control.

[0048] Reference Figure 2 As shown, in this embodiment, the main 10 Gigabit multicast signal and the backup 10 Gigabit multicast signal are transmitted to the regional distribution room and the township distribution room via optical splitters and optical repeaters in the city / county central equipment room, respectively. Multiple OLTs are installed in the regional distribution room, and a sixth OLT6 is installed in the township distribution room. Each OLT is connected to form a data network channel via a 10 Gigabit aggregation switch and an OLT control switch. The IPTV monitoring and dispatch server obtains the status of each OLT and issues control commands through the OLT control switch.

[0049] This disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy includes the following processes: IPTV monitoring and scheduling server periodically Every second, poll all 6 OLTs to perform multicast list comparison, input traffic analysis, and port status monitoring.

[0050] Multicast list comparison. Read the current IGMP multicast group member list for each OLT. , , Each multicast list contains approximately 150 multicast group addresses. The list contains only 18 multicast groups. Construct the union of the entire network's multicast list. It contains 155 multicast groups, calculated Multicast list comparison difference rate: ; This value far exceeds the multicast list comparison difference rate threshold. Therefore, this item is marked as abnormal.

[0051] Input traffic calculation. Real-time traffic rates are collected from the unidirectional multicast input ports of each OLT. Normal OLT traffic is between 4.2Gbps and 4.8Gbps; the median value is calculated. . Given an input port flow of 0 Gbps, calculate its input flow deviation: ; This value far exceeds the flow deviation threshold. Therefore, this item is marked as abnormal.

[0052] Port status monitoring involves reading the operating status of each OLT multicast input port via SNMP. The port status returned a link disconnection, therefore a fault was directly marked. After comprehensive judgment, it was determined that... Input a faulty OLT for multicast and record it as .

[0053] The scheduling decision-making process is as follows: Step 1: Calculate the available bandwidth at the receiving end.

[0054] Read Data network port statistics: Total port bandwidth Current data services have already used bandwidth. Recent peak traffic of data services Reserve coefficient The reserved bandwidth is: ; The bandwidth available for multicast transmission is: ; Since the calculated result of 40Mbps is too low and does not meet the basic multicast transmission requirements, the minimum guarantee mechanism is activated. The system's default minimum guarantee bandwidth is 1.5Gbps. The value is 1.5Gbps.

[0055] Step 2: Multicast provides OLT with multi-factor selection.

[0056] , , , , All multicast functions are normal; therefore, they are listed as candidate OLTs. Based on... The overall selection priority of each candidate OLT was calculated, and the results are shown below.

[0057] The overall selection priority calculation results for candidate OLTs are as follows: Distance parameters The available bandwidth is 0. With a bandwidth of 4.5Gbps, a distance factor of 1.00, and a bandwidth ratio of 3.00, priority is selected based on these factors. It is 3.00; Distance parameters The available bandwidth is 0. With a bandwidth of 3.2Gbps, a distance factor of 1.00, and a bandwidth ratio of 2.13, priority is selected based on these factors. It is 2.13; Distance parameters The available bandwidth is 0. With a bandwidth of 5.8Gbps, a distance factor of 1.00, and a bandwidth ratio of 3.87, priority is selected based on these factors. It is 3.87; Distance parameters The available bandwidth is 0. With a bandwidth of 2.8Gbps, a distance factor of 1.00, and a bandwidth ratio of 1.87, priority is selected based on these factors. It is 1.87; Distance parameters The available bandwidth is 1. With a bandwidth of 7.0Gbps, a distance factor of 0.50, and a bandwidth ratio of 4.67, priority is selected based on these factors. It is 2.33.

[0058] As can be seen from the above table, It scored the highest, and its available bandwidth of 5.8Gbps was greater than... The 1.5Gbps speed alone is sufficient to meet the requirements. Therefore, it is determined that... .

[0059] Step 3: Calculate program scheduling priority.

[0060] There are currently 500 online users watching 150 different channels. Calculate the scheduling priority weight for each channel individually: ; The rules for assigning values ​​to each factor are as follows: Program Importance Corresponding weights The rate is 0.35, with 1.0 for priority programs and 0.3 for regular programs; (This is a pricing attribute.) Corresponding weights The value is 0.25, with paid programs receiving 1.0 and free programs receiving 0.2; User Preference Corresponding weights It is 0.25, with (Multicast receiver OLT) The ratio of the number of users currently watching the program to the total number of online users is normalized to 0 to 1; resolution Corresponding weights The value is 0.15, 1.0 for ultra-high definition programs, 0.6 for high definition programs, and 0.3 for standard definition programs.

[0061] Let's take a typical channel as an example for explanation.

[0062] Channel A is CCTV's main channel, offering premium ultra-high-definition programming. If 300 households watch, then... , , , The scheduling priority weight for channel A is: ; Channel A bitrate .

[0063] Channel B is a satellite TV channel, offering free, high-definition programming. It is available to 400 households. , , , The scheduling priority weight for channel B is: ; Channel B bitrate .

[0064] Channel C is a local channel, offering standard definition, free-to-air programming. If 50 households are watching, then... , , , The scheduling priority weight for channel C is: ; Channel C bitrate .

[0065] Channel D is a shopping channel, a standard definition, free-to-air program. If 5 households watch it, then... , , , The scheduling priority weight for channel D is: ; Channel D bitrate .

[0066] And so on, calculating the weights of all 150 channels. and corresponding bitrate .

[0067] Step 4: Program selection and allocation under bandwidth constraints.

[0068] The 150 channels are scheduled according to their program channel priority weights. Arranged in descending order, the sorting and bitrate distribution are assumed to be as follows.

[0069] The sorting and bitrate distribution are as follows: the eight channels ranked 1 to 8 are key ultra-high-definition pay channels, with a weight range of 0.80 to 0.95, a single channel bitrate of 40Mbps, a cumulative bitrate of 320Mbps, and a total cumulative bitrate of 320Mbps. The 17 channels ranked 9th to 25th are either ultra-high-definition pay channels or high-definition key channels, with a weight range of 0.55 to 0.79, a single channel bitrate of 35Mbps, a cumulative bitrate of 595Mbps, and a total cumulative bitrate of 915Mbps. The 20 channels ranked 26 to 45 are either premium HD channels or popular channels, with a weighting range of 0.35 to 0.54. The single channel bitrate is 20Mbps, the cumulative bitrate of the interval is 400Mbps, and the total cumulative bitrate is 1315Mbps. The 25 channels ranked 46 to 70 are either high-definition standard channels or popular standard-definition channels, with a weight range of 0.22 to 0.34, a single channel bitrate of 14Mbps, a cumulative bitrate of 350Mbps, and a total cumulative bitrate of 1665Mbps. The 30 channels ranked 71 to 100 are standard definition (SD) channels, with a weight range of 0.15 to 0.21, a single channel bitrate of 8 Mbps, a cumulative bitrate of 240 Mbps, and a total cumulative bitrate of 1905 Mbps. The 30 channels ranked 101 to 130 are standard definition low-popularity channels with a weight range of 0.08 to 0.14, a single channel bitrate of 8Mbps, a cumulative bitrate of 240Mbps, and a total cumulative bitrate of 2145Mbps. The 20 channels ranked 131 to 150 are standard definition channels with very low popularity, with a weight range of 0.02 to 0.07, a single channel bitrate of 8Mbps, a cumulative bitrate of 160Mbps, and a total cumulative bitrate of 2305Mbps.

[0070] The total bandwidth requirement for all 150 channels is 2305Mbps, exceeding the available bandwidth of the data network for the multicast receiving OLT. Therefore, some low-weight channels need to be discarded.

[0071] The screening process is as follows: Starting with the channel with the highest weight, channels are sequentially added to the scheduling list and their bitrates are accumulated in real time. Channels 1 through 8 accumulate a total of 320Mbps, not exceeding 1500Mbps. The total speed of channels 9 through 25, after being included, is 915 Mbps, not exceeding 1500 Mbps; After including channels 26 to 45, the total speed is 1315Mbps, which does not exceed 1500Mbps; if all channels 46 to 70 are included, the total speed is 1665Mbps, which exceeds 1500Mbps. Therefore, it is necessary to judge each channel from 46 to 70 individually.

[0072] Channels 46-70, a total of 25 channels (weights 0.22-0.34, with a mixed bitrate of approximately 14Mbps each), after being included, have a cumulative bitrate of 1665Mbps, exceeding the available bandwidth of the multicast receiving OLT's data network. The 1500Mbps upper limit is 165Mbps, so it cannot be included entirely and needs to be judged channel by channel within this range.

[0073] Filter channels 46-70 one by one in descending order of weight: The 46th one (weight 0.34, bitrate 14Mbps): 1315 + 14 = 1329 ≤ 1500, included; The 47th one (weight 0.33, bitrate 14Mbps): 1329 + 14 = 1343 ≤ 1500, included; The 48th one (weight 0.32, bitrate 14Mbps): 1343 + 14 = 1357 ≤ 1500, included; The 49th one (weight 0.31, bitrate 14Mbps): 1357 + 14 = 1371 ≤ 1500, included; The 50th one (weight 0.30, bitrate 14Mbps): 1371 + 14 = 1385 ≤ 1500, included; The 51st (weight 0.29, bitrate 14Mbps): 1385 + 14 = 1399 ≤ 1500, included; The 52nd one (weight 0.28, bitrate 14Mbps): 1399 + 14 = 1413 ≤ 1500, included; The 53rd one (weight 0.27, bitrate 14Mbps): 1413 + 14 = 1427 ≤ 1500, included; The 54th one (weight 0.26, bitrate 14Mbps): 1427 + 14 = 1441 ≤ 1500, included; The 55th one (weight 0.25, bitrate 14Mbps): 1441 + 14 = 1455 ≤ 1500, included; The 56th one (weight 0.24, bitrate 14Mbps): 1455 + 14 = 1469 ≤ 1500, included; The 57th one (weight 0.23, bitrate 14Mbps): 1469 + 14 = 1483 ≤ 1500, included; The 58th one (weight 0.22, bitrate 14Mbps): 1483 + 14 = 1497 ≤ 1500, included; The 59th number (weight 0.22, bitrate 14Mbps): 1497 + 14 = 1511 > 1500, stop.

[0074] The scheduling result is as follows: the top 58 channels were included, with a cumulative bitrate of 1497Mbps, occupying [a certain amount of bandwidth]. 99.8% of the total. Channels 59 to 150, a total of 92 channels, are temporarily suspended due to insufficient bandwidth and are not included in this transmission list. The 58 channels included are all the highest-weighted programs, covering all key ultra-high-definition channels, high-definition pay channels, and popular programs.

[0075] The channels that have been put on hold include: Channels 59 to 70 comprise 12 channels, with a weight range of 0.17 to 0.22 and a cumulative bitrate of approximately 168 Mbps. Channels 71 to 100 comprise 30 channels, with a weight range of 0.15 to 0.21 and a cumulative bitrate of 240 Mbps. Channels 101 to 130 comprise 30 channels, with a weight range of 0.08 to 0.14 and a cumulative bitrate of 240 Mbps. Channels 131 to 150 comprise 20 channels, with a weight range of 0.02 to 0.07 and a cumulative bitrate of 160 Mbps. The total bandwidth requirement for the 92 shelved channels is approximately 808 Mbps.

[0076] Step S5: Instruction issuance and stream switching process.

[0077] The IPTV monitoring and dispatch server transmits data through the management network to... Issue a multicast stream forwarding control command, the control command including: instruction type is multicast stream forwarding; target address is... The data network interface IP address is 10.10.3.1; the multicast stream list contains the multicast addresses and UDP port numbers of 58 channels; the forwarding port is Eth-Trunk1; and the bandwidth limit is 1497Mbps.

[0078] At the same time, the IPTV monitoring and dispatch server sends... A receive command is issued, comprising: instruction type "multicast stream receive"; source address "10.10.4.1", i.e. The data network interface is Eth-Trunk1; the local processing method is to inject the received multicast stream into the IGMP multicast distribution module and bridge it to each PON port to push it to the user.

[0079] During the reception of new streams, the residual data in the original multicast buffer continues to be output. Once the multicast stream from the data network channel arrives and stabilizes, the buffer content is smoothly replaced so that the user end is not noticeably affected.

[0080] Dynamic bandwidth adaptive adjustment process. During disaster recovery operation, the IPTV monitoring and scheduling server uses... Continuous data collection every second and Available bandwidth for the data network.

[0081] Scenario 1: Increased bandwidth – supplementing transmission.

[0082] After running for about 30 minutes, Data traffic decreased from 4.2Gbps to 2.8Gbps. The available bandwidth of the data network for the multicast receiving OLT was recalculated. This is still less than the minimum guaranteed bandwidth of 1.5Gbps, therefore it remains unchanged. Since it is currently only using 1497Mbps, compared to The situation remains largely unchanged, and no rescheduling is triggered at this time.

[0083] If data speeds are further reduced to 2.0Gbps, then This exceeds the minimum guaranteed bandwidth, so the actual value of 2.24Gbps is used. Compared to the previous 1.5Gbps, the range of available bandwidth variation has been increased. The change was 49.3%, exceeding the adjustment threshold. This triggers a rescheduling.

[0084] From the 92 previously shelved channels, click Supplementary transmissions are selected in descending order, and the cumulative bitrate of newly added program channels does not exceed [a certain value]. .

[0085] Starting from channel 59: Channels 59 to 70, totaling 12 channels, with a weight of 0.17 to 0.22 and a cumulative bitrate of 168 Mbps, are included. Channels 71 to 100, totaling 30 channels, with a weight of 0.15 to 0.21 and a cumulative bitrate of 240 Mbps, totaling 408 Mbps, are included. Channels 101 to 122, totaling 22 channels, with a weight of 0.08 to 0.12 and a cumulative bitrate of 176 Mbps, totaling 584 Mbps, are included. Channel 123 has a bitrate of 8Mbps, totaling 592Mbps, and is included.

[0086] A total of 53 channels have been added so far, with a bitrate of 592Mbps. Channels 124 to 150, totaling 27 channels and 216Mbps, will not be scheduled for the time being. The number of channels available to users has increased from 58 to 111.

[0087] Scenario 2: Reduced bandwidth - pruning low-weight streams.

[0088] Assuming during operation A sudden data service disruption caused the available bandwidth of the data network to drop from 5.8Gbps to 2.0Gbps. Since this is still greater than the current carrying capacity of 1497Mbps, rescheduling will not be triggered at this time. If the available bandwidth further drops to 1.2Gbps, below the current carrying capacity of 1497Mbps, and the change is greater than 15% (20%), then rescheduling will be triggered.

[0089] The required release bitrate is no less than 1497 - 1200 = 297 Mbps. Stop transmission in reverse order from the end of the currently scheduled program sequence (the channel with the lowest weight): Stop channel 58 (weight 0.22, bitrate 14Mbps), releasing a total of 14Mbps; Stopped the 57th one (weight 0.23, bitrate 14Mbps), 28Mbps released in total... Channels 58 through 38 were stopped sequentially (a total of 21 channels, all of which were popular HD / SD channels, with a total bitrate of approximately 294Mbps), releasing a total bitrate of nearly 297Mbps, at which point the cutoff was stopped; Channels 1-37 (weights 0.35-0.95, totaling approximately 1203 Mbps) continue to play smoothly. The user interface for the 21 channels that were cut displays "Signal switching in progress." Data services are unaffected. At this point, the monitoring program will control other suitable alternative OLTs to send the required multicast streams.

[0090] Fault recovery and switchback process.

[0091] Maintenance personnel repair After the unidirectional multicast input link is established, the IPTV monitoring and scheduling server continuously performs multicast list comparison, input traffic analysis, and port status monitoring. All test results within each cycle were normal: In cycle 1, the port returned to normal link status, the multicast list recovered to 148 multicast groups, the multicast list comparison difference rate was 0.045 and below 0.1, the traffic was 4.3Gbps, and the input traffic deviation was 0.044 and below 0.3; cycles 2 and 3 were both normal. After confirming fault recovery, the switchback process was initiated.

[0092] When cutting back, Currently, 58 channels are being received via the data network channel. The IPTV monitoring and scheduling server switches channels sequentially, switching the multicast input source of one channel from the data network channel back to the unidirectional IP multicast network at 200ms intervals.

[0093] All 58 channels were switched over in a total time of approximately 58 × 200ms = 11.6 seconds.

[0094] Subsequently, the IPTV monitoring and dispatch server sent to Send a stop command, requesting it to stop forwarding multicast streams from all 58 channels and release data network bandwidth; simultaneously... The scheduling status in the system is reset to normal mode and is no longer marked as a faulty OLT. If channels are added during dynamic adjustment, the switchback will be performed according to the current actual transmission list. Throughout the switchback process, the switching interval between each channel is short, and the user end has no obvious interruption due to buffer compensation.

[0095] Multi-OLT collaborative transmission (supplementary scenario).

[0096] In the above embodiments, the highest score The available bandwidth is insufficient to meet the available bandwidth of the data network alone. Demands, for example ,and If the available bandwidth is only 0.8Gbps, a single OLT cannot meet the demand. In this case, priority should be selected based on overall factors. Sort and accumulate candidate OLTs sequentially: First select A total of 0.8Gbps is available; then select Its available bandwidth is 4.5Gbps, with a cumulative available bandwidth of 5.3Gbps, which is greater than 1.5Gbps. Therefore, the multicast-provided OLT set is determined. .

[0097] The first and fourth multicasts provide transmission quotas for the OLT. , for: ; ; The 58 high-weight programs that have already been ranked will be allocated according to the quota ratio, among which... It can handle the top 15% of programming, such as the top 6 channels with the highest weight, including 5 UHD key channels and 1 UHD pay channel, totaling approximately 235Mbps; It will handle the remaining 52 programs, totaling approximately 1262 Mbps. Simultaneously, multicast streams are received from the data network interfaces of the two multicast OLTs, merged locally, and then pushed to users in a unified manner.

[0098] This demonstrates the available bandwidth of the data network for multicast receiving OLTs. In a scenario where the total bandwidth requirement for 150 channels is approximately 2.305Gbps, this embodiment prioritizes 58 high-weight channels through multi-factor weighting, with a cumulative bitrate of 1497Mbps, while temporarily suspending 92 low-weight channels, with a cumulative bitrate of approximately 808Mbps. At the same time, it can automatically replenish suspended programs when bandwidth recovers and cut low-weight programs when bandwidth decreases, fully demonstrating the bandwidth constraint screening and flexible scheduling capabilities of this embodiment.

[0099] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0100] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0101] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0102] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0103] Finally, it should be noted that the above specific embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to examples, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy, characterized in that, include: The unidirectional multicast input status of each OLT is periodically detected to obtain the multicast list, real-time traffic of the unidirectional multicast input port, and physical layer status of the multicast input port of each OLT. The multicast list comparison difference rate is determined based on the multicast list, the input traffic deviation is determined based on the real-time traffic, and the multicast receiving OLT is jointly determined to determine whether a fault has occurred based on the physical layer status, the multicast list comparison difference rate, and the input traffic deviation. In response to a failure of the multicast receiving OLT, the available bandwidth of the data network for the multicast receiving OLT is calculated; wherein, the available bandwidth of the data network is the bandwidth that can be used for multicast stream disaster recovery transmission; Candidate OLTs are determined from OLTs with normal multicast input status. Based on the topological distance between the candidate OLT and the multicast receiving OLT, the available bandwidth of the candidate OLT's data network, and the available bandwidth of the multicast receiving OLT's data network, the overall selection priority of the candidate OLT is calculated. At least one candidate OLT is selected as the multicast providing OLT set based on the overall selection priority from high to low. Calculate scheduling priority weights for all program channels being watched by online users under the multicast receiving OLT, sort the program channels in descending order according to the scheduling priority weights, filter program channels based on the available bandwidth of the data network of the multicast receiving OLT, and allocate the filtered program channels to the multicast providing OLTs in the set of multicast providing OLTs. The multicast providing OLT sends a multicast stream forwarding instruction and a multicast stream receiving instruction to the multicast receiving OLT, so that the multicast providing OLT forwards the multicast stream corresponding to the filtered program channel to the multicast receiving OLT through the data network channel. The multicast receiving OLT injects the received multicast stream into the local multicast distribution module and pushes it to the user side. During disaster recovery operation, monitor the changes in available bandwidth of the data network of the multicast providing OLT and the multicast receiving OLT. When the change in available bandwidth of the data network exceeds the adjustment threshold, trigger dynamic rescheduling and supplement or cancel program channels according to the scheduling priority weight. When the unidirectional multicast input status of the multicast receiving OLT is confirmed to have returned to normal for several consecutive cycles, the multicast input source of the multicast receiving OLT is switched back from the data network channel to the unidirectional IP multicast network program by program.

2. The disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, The multicast list comparison difference rate is determined according to the following formula: ； in, For the first Multicast list comparison difference rate of each OLT The union of the multicast lists across the entire network. For the first Multicast list of each OLT; The input flow deviation is determined according to the following formula: ； in, For the first Input flow deviation of each OLT For the first Real-time traffic of the unidirectional multicast input port of an OLT. The median value of the input traffic for an OLT with normal multicast input status.

3. The disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, The determination of whether a multicast receiving OLT has malfunctioned is based on the physical layer status, the multicast list comparison difference rate, and the input traffic deviation, including: When the physical layer status of the unidirectional multicast input port is "link disconnected", it is directly determined that the corresponding OLT has experienced a multicast input failure. When the physical layer status of the unidirectional multicast input port is normal, and the multicast list comparison difference rate of the corresponding OLT exceeds the difference rate threshold and the input traffic deviation exceeds the traffic deviation threshold, it is determined that the corresponding OLT has a multicast input failure. If only one of the multicast list comparison difference rate and the input traffic deviation is abnormal, the detection frequency is increased, and after a preset number of consecutive abnormalities, it is determined that the corresponding OLT has a multicast input failure.

4. The disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, The available bandwidth of the data network for the multicast receiving OLT is determined according to the following formula: ； ； in, The available bandwidth of the data network for the multicast receiving OLT, The total bandwidth of the data network port of the multicast receiving OLT. The bandwidth used for the data network port of the multicast receiving OLT is [not specified]. To reserve bandwidth, This represents the current peak traffic for data services. This is a reserved coefficient.

5. A disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, The overall selection priority of the candidate OLTs is determined according to the following formula: ； in, For the first The overall selection priority of each candidate OLT For the first Topological distance parameters between each candidate OLT and the multicast receiving OLT. For the first Available bandwidth for the data network of each candidate OLT The available bandwidth of the data network for the multicast receiving OLT is specified. The topology distance parameter is 0 when the candidate OLT and the multicast receiving OLT are at the same level, and 1 when the candidate OLT and the multicast receiving OLT are at the next or previous level, and increases progressively according to the topology level.

6. The disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy according to claim 1, characterized in that, Based on the comprehensive selection priority, at least one candidate OLT is selected from high to low as the multicast providing OLT set, including: The candidate OLTs are sorted in descending order according to the comprehensive selection priority, and the candidate OLT with the highest comprehensive selection priority is selected first. When the available bandwidth of a single candidate OLT's data network does not meet the available bandwidth requirement of the multicast receiving OLT, candidate OLTs are added sequentially from high to low according to the comprehensive selection priority until the cumulative available bandwidth of the selected candidate OLTs meets the available bandwidth requirement of the multicast receiving OLT.

7. A disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, The scheduling priority weights are determined according to the following formula: ； in, For the first The scheduling priority weight of each program channel Assigning weight to the program's importance For the weight of paid attributes, Weighting based on user preference For clarity weight, For the first The importance value of each program channel. For the first The value of the charging attribute for each program channel. For the first User preference values ​​for each program channel. For the first The resolution value for each program channel.

8. A disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, Assigning the selected program channels to the multicast providing OLTs in the set of multicast providing OLTs, including: When the set of multicast providing OLTs includes multiple multicast providing OLTs, the transmission quota is determined according to the proportion of available bandwidth of the data network of each multicast providing OLT. The program channels arranged in descending order according to the scheduling priority weight are allocated to each multicast providing OLT according to the transmission quota, and the allocation bitrate of each multicast providing OLT does not exceed the corresponding transmission quota. The transmission quota is determined according to the following formula: ； in, For the first Each multicast provides the OLT with a transmission quota. For the first Multicast provides the available bandwidth for the OLT's data network. Provides an OLT collection for multicast. The sum of the available bandwidth of the data networks of each multicast-providing OLT in the multicast-providing OLT set.

9. A disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, When the change in available bandwidth of the data network exceeds the adjustment threshold, dynamic rescheduling is triggered, and program channels are added or removed according to the scheduling priority weight, including: When available bandwidth increases, program channels are added from the unscheduled program channels in descending order of scheduling priority weight, and the cumulative bitrate of the newly added program channels does not exceed a preset proportion of the bandwidth increase. When available bandwidth decreases, program channels are removed from the end of the currently scheduled program channel sequence according to the scheduling priority weight from low to high, until the released bitrate is not less than the amount of bandwidth reduction.

10. A disaster recovery method for 10 Gigabit IPTV multicast based on data network redundancy as described in claim 1, characterized in that, Switching the multicast input source of the multicast receiving OLT back from the data network channel program-by-program to the unidirectional IP multicast network includes: After the multicast receiving OLT meets the conditions of normal physical layer status of multicast input port, multicast list comparison difference rate lower than difference rate threshold and input traffic deviation lower than traffic deviation threshold for multiple consecutive detection cycles, the multicast input source of program channel is switched one by one at preset time intervals. After all program channels have switched back, a stop forwarding instruction is sent to each multicast providing OLT in the multicast providing OLT set, and the scheduling status of the multicast receiving OLT is reset to normal mode.

Images