Fault detection method, monitoring device and network device
By obtaining the video quality parameters of the video stream in IPTV video service, especially the effective packet loss factor, accurately detecting video service failures, the problem of inaccurate detection in the prior art is solved and the accuracy of fault detection is improved.
Patent Information
- Application Number
- CN202110080867.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2017-05-27
- Publication Date
- 2025-03-25
- Estimated Expiration
- 2037-05-27
AI Technical Summary
In the prior art, when detecting faults in IPTV video services, it is difficult to accurately distinguish between network transmission failures and other equipment failures, especially in the scenario where packet loss recovery method is adopted, the packet loss rate detection result is inaccurate.
By obtaining the video quality parameters of the monitored video stream, including the effective packet loss factor, the parameters that need to be monitored are determined according to the packet loss recovery method, and accurate fault detection of video services is achieved.
It improves the accuracy of video service fault detection, and can accurately determine the cause of the fault in the case of poor network conditions but effective packet loss recovery, and avoid misjudgment.
Smart Images

Figure CN112702630B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the field of multimedia technology, and in particular to a fault detection method, a monitoring device and a network device. Background Art
[0002] In Internet Protocol television (IPTV) video services, the video headend sends the video stream, which is transmitted via the network device to the set top box (STB) deployed on the user side. The STB transmits the video stream to the display device for display. The packet loss and delay that occur during the network transmission process will have different degrees of impact on the video service. Usually, the packet loss rate can be used to characterize the impact of network transmission quality on video quality. In addition, the prior art monitors the network transmission quality through the packet loss rate. When a video service fails (such as: a distorted screen appears during playback), once it is determined that the packet loss rate is higher than the threshold, it indicates that the network transmission is not good and the video service failure is caused by network transmission.
[0003] In order to improve the service quality of IPTV systems, network operators often use various packet loss recovery methods to enhance the fault tolerance of IPTV systems to network packet loss, such as forward error correction (FEC), retransmission (RET) and other technologies. The use of packet loss recovery methods may affect the user side's sensitivity to packet loss rate. If fault detection is still performed based on packet loss rate when packet loss recovery methods are used, inaccurate detection results will result. Summary of the invention
[0004] The present application provides a video quality monitoring method, monitoring equipment and network equipment, which can accurately detect faults in video services.
[0005] In order to achieve the above objectives, this application adopts the following technical solutions:
[0006] In a first aspect, a fault detection method is provided, comprising: obtaining a video quality parameter of a monitored video stream, wherein in a specific implementation, the video quality parameter is determined according to a packet loss recovery method of the monitored video stream. The video quality parameter may include an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss. Finally, fault detection may also be performed based on the video quality parameter of the monitored video stream.
[0007] It can be seen that in the fault detection method provided by the embodiment of the present invention, the video quality parameters that need to be monitored are determined according to the packet loss recovery method of the monitored video stream. These parameters may include an effective packet loss factor, which can indicate the effectiveness of the packet loss recovery method used to recover network packet loss, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and thus, the fault detection of the video service can be accurately performed according to the video quality parameters of the monitored video stream. For example: although the network condition is not good and the packet loss rate is high, the effective packet loss factor is low, that is, the packet loss recovery method is used to effectively recover the lost source data packets. Therefore, the video service failure that occurs at this time is not caused by the network, but may be caused by the failure of the head-end device or the failure of the user terminal. It can be seen that the method provided by the embodiment of the present invention improves the accuracy of video service fault detection.
[0008] In combination with the first aspect, in a first possible implementation of the first aspect, before obtaining the video quality parameters of the monitored video stream, the method further includes: sending a video quality parameter request message to at least one network device through which the monitored video stream flows, the video quality parameter request message being used to indicate an identifier of the monitored video stream and a packet loss recovery method for the monitored video stream. For example, if the monitored video stream is a live video stream, the identifier of the monitored video stream may be a channel number or a multicast address and port; if the monitored video stream is a video-on-demand stream, the identifier of the monitored video stream may be a five-tuple.
[0009] Then, obtaining the video quality parameter of the monitored video stream specifically includes: obtaining the video quality parameter of the monitored video stream from the at least one network device.
[0010] In this way, the monitoring device can obtain the video quality parameter of at least one reported monitored video stream through which the monitored video stream flows.
[0011] In combination with the first aspect and any possible implementation of the first aspect above, in a second possible implementation of the first aspect, the effective packet loss factor may indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover from network packet loss, such as: the effectiveness of using the packet loss recovery method of the monitored video stream to recover from network packet loss, or the probability of effectively recovering from network packet loss using the packet loss recovery method of the monitored video stream.
[0012] Specifically, if no packet loss recovery method is set for the unmonitored video stream, the video quality parameters include the following parameters: packet loss rate; if the packet loss recovery method of the monitored video stream is FEC, the video quality parameters include the following parameters: packet loss rate, a first effective packet loss factor (i.e., the effective packet loss factor of the first aspect above), the first effective packet loss factor is used to indicate the effectiveness of using FEC to recover from network packet loss; if RET and FEC are set for the monitored video stream at the same time, the video quality parameters include the following parameters: packet loss rate, maximum number of consecutive packet losses, a second effective packet loss factor (i.e., the effective packet loss factor of the first aspect above), the second effective packet loss factor is used to indicate the effectiveness of using FEC and RET to recover from network packet loss. If the packet loss recovery method of the monitored video stream is retransmission RET, the video quality parameters include the following parameters: packet loss rate, maximum number of consecutive packet losses, and a third effective packet loss factor, the third effective packet loss factor is used to indicate the effectiveness of using RET to recover from network packet loss.
[0013] It can be seen that for the packet loss recovery methods such as FEC and RET set for the monitored video stream, different video quality parameters are counted. When using different packet loss recovery methods, the compensation of network packet loss by the packet loss recovery method can be considered while considering the packet loss rate, such as: a first effective packet loss factor indicating the effectiveness of using FEC to recover network packet loss. Specifically, if the video quality parameters include the packet loss rate and the first effective packet loss factor, when the first effective packet loss factor is greater than the corresponding threshold value, it is determined that the compensation for network packet loss using FEC is not effective. At this time, it can be determined that the video service failure is caused by a network transmission failure.
[0014] In combination with the first aspect and any possible implementation manner of the first aspect above, in a third possible implementation manner of the first aspect, the first effective packet loss factor ELF_F satisfies:
[0015] in,
[0016] L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, For x l (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. windows, where the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; Num l(k) is the number of packet losses in the kth window among K monitoring windows, and R is the maximum number of packet losses that can be recovered using FEC for L source data packets.
[0017] In combination with the first aspect and any possible implementation manner of the first aspect above, in a fourth possible implementation manner of the first aspect, the second effective packet loss factor ELF_FR satisfies:
[0018] in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, K is the number of corresponding monitoring windows, and the monitoring window includes the first source data packet in the monitoring period, which is obtained by dividing N source data packets according to the length of the source block. windows, the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; lost(k) is the number of source data packets that cannot be recovered by FEC in the kth window of the K monitoring windows, δ is the maximum number of lost packets that can be recovered by RET for E source data packets, and E is the number of source data packets in one monitoring period;
[0019] or,
[0020] The effective factor ELF_FR satisfies: in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, for y l (1) to y l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. A window, wherein the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; x l (k) is the number of packet losses in the kth window among K monitoring windows, E' is the number of source data packets recoverable using FEC in the kth window, and R is the maximum number of packet losses recoverable using RET for L source data packets.
[0021] In combination with the first aspect and any possible implementation manner of the first aspect above, in a fifth possible implementation manner of the first aspect, the third effective packet loss factor ELF_R satisfies:
[0022] in,
[0023] L is the preset window length; for any l greater than 0 and less than or equal to L, For x l (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the preset window length with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among K monitoring windows; R is the maximum number of packet losses that can be recovered using RET for L source data packets.
[0024] In combination with the first aspect and any possible implementation of the first aspect above, in a sixth possible implementation of the first aspect, the at least one network device includes a first device, and fault detection is performed according to the video quality parameters of the monitored video stream, specifically including: if a first video quality parameter reported by the first device is received within a monitoring cycle, it is determined that a fault occurs between the first device and the head-end device; the head-end device is a device that provides the monitored video stream; the first video quality parameter is reported to the monitoring device by the first device after determining that at least one parameter of the first video quality parameters exceeds the corresponding threshold value.
[0025] Here, each device first counts the corresponding video quality parameters according to the packet loss recovery method of the monitored video stream. Once it is determined that the video quality parameters exceed the corresponding threshold, the video quality parameters are reported to the monitoring device. It can be seen that within a monitoring cycle, if the monitoring device receives the video quality parameters reported by a network device, it means that the video quality parameters reported by the network device are
[0026] If the number exceeds the threshold, it means that the upstream of the network device has a fault, and it can be considered that there is a fault between the network device and the head-end device. On the contrary, if the video quality parameter reported by the network device is not received, it means that the video quality parameter counted by the network device does not exceed the threshold. In this way, the number of signaling received by the monitoring device can be reduced, which reduces the processing load of the monitoring device.
[0027] In combination with the first aspect and any possible implementation of the first aspect above, in a seventh possible implementation of the first aspect, the at least one network device further includes a second device downstream of the first device. The method further includes: if the monitoring device receives the second video quality parameter reported by the second device within a monitoring cycle and does not receive the first video quality parameter, it is determined that a fault occurs between the first device and the first device; the second video quality parameter is reported to the monitoring device by the second device after determining that at least one parameter of the second video quality parameter exceeds the corresponding threshold value; if the monitoring device does not receive the second video quality parameter and the first video quality parameter within a monitoring cycle, it is determined that a fault occurs between the second device and the user terminal; the user terminal is a device that receives the monitored video stream.
[0028] If the video quality parameters reported by the first device are not received within a monitoring cycle, it indicates that the video quality parameters monitored by the first device do not exceed the corresponding threshold value, that is, there is no fault in the upstream of the first device. If the video quality parameters reported by the second device are received, it indicates that there is a fault in the upstream of the second device. In summary, there is a fault between the first device and the second device. Similarly, if the video quality parameters reported by the first device and the second device are not received within a monitoring cycle, it indicates that there is no fault in the upstream of the second device, and the fault of the video service is caused by the fault between the user terminal and the second device.
[0029] In combination with the first aspect and any possible implementation of the first aspect above, in an eighth possible implementation of the first aspect, the at least one network device includes N network devices through which the monitored video stream flows, and N is an integer greater than or equal to 2; then, the monitoring device obtains the video quality parameters of the monitored video stream monitored by at least one network device specifically including: receiving the video quality parameters of the monitored video stream sent by each of the N network devices.
[0030] In this scenario, each of the N network devices through which the monitored video stream flows will count the corresponding video quality parameters according to its own packet loss recovery method, and after counting the video quality parameters, it will report the counted video quality parameters to the monitoring device.
[0031] In combination with the first aspect and any possible implementation of the first aspect above, in the ninth possible implementation of the first aspect, if it is determined that at least one parameter of the first video quality parameters reported by the first device among the N network devices is greater than or equal to the corresponding threshold value, it is determined that a fault occurs between the first device and the second device; the head-end device is a device that provides a monitored video stream; if it is determined that the first video quality parameters reported by the first device are all less than the corresponding threshold value, and at least one parameter of the second video quality parameters reported by the second device downstream of the first device among the N network devices is greater than or equal to the corresponding threshold value, it is determined that a network fault occurs between the first device and the second device.
[0032] That is to say, when at least one of the video quality parameters reported by a certain device exceeds the corresponding threshold, it can be indicated that the upstream of the network device has a fault. For example, if the video quality parameter reported by the most downstream device among the N network devices mentioned above exceeds the threshold, it can be considered that the network transmission failure caused the video service failure; if the video quality parameter reported by the most upstream device through which the monitored video stream flows exceeds the corresponding threshold, it can be considered that the failure of the head-end device caused the video service failure.
[0033] In combination with the first aspect and any possible implementation of the first aspect above, in the tenth possible implementation of the first aspect, if the monitoring device determines that a fault occurs in the network between the first device and the second device, the method also includes: determining the failure probability of each of the M+1 network segments; the network segment is the first device, M third devices, and the network between any two adjacent devices of the second device, and the third device is a device between the first device and the second device; determining the network segment with the highest failure probability among the M+1 network segments as the network segment with the fault; wherein M is an integer less than N.
[0034] It can be seen that the method provided by the embodiment of the present invention can also improve the accuracy of video service fault detection by detecting the fault on a specific network segment.
[0035] In combination with the first aspect and any possible implementation manner of the first aspect above, in an eleventh possible implementation manner of the first aspect, determining the failure probability of each of the M+1 network segments specifically includes:
[0036] Calculate the probability that the Qth parameter in the video quality parameter causes the i-th network segment to fail i is an integer greater than or equal to 1 and less than or equal to M+1, satisfy:
[0037] in, is the Qth parameter reported by the i+1th device. is the Qth parameter reported by the i-th device, λ Q is the threshold value corresponding to the Qth parameter, and the i+1th device is the upstream device adjacent to the i-th device;
[0038] The failure probability of the parameter with the highest failure probability among all the parameters included in the video quality parameters is determined as the failure probability p of the i-th network segment i .
[0039] In a specific implementation, the failure probability of each network segment can be calculated based on the video quality parameters reported by each network device through which the monitored video stream flows, and then the fault can be detected on the network segment with the highest failure probability, thereby improving the accuracy of video service fault detection.
[0040] In combination with the first aspect and any possible implementation of the first aspect above, in a twelfth possible implementation of the first aspect, the method further includes: calculating the failure probability p of the i-th network segment within T consecutive monitoring cycles. i ', T is an integer greater than or equal to 2; p i 'satisfy:
[0041] Among them, β t =2 -t , t∈[1,.....T]; update the failure probability of the i-th network segment to S,
[0042] Updating the failure probability of a network segment to the average failure probability of the network segment in multiple continuous monitoring cycles can improve the accuracy of fault location. If the average failure probability of a network segment in multiple continuous monitoring cycles is higher than the threshold, it indicates that the probability of failure of the network segment is very high, and the video service failure is likely caused by the failure of the network segment.
[0043] In combination with the first aspect and any possible implementation of the first aspect above, in a thirteenth possible implementation of the first aspect, when l is greater than 1, the monitoring window further includes a first window, and the first window is a window formed by a source data packet before the lth source data packet;
[0044] And / or, when N / L is not an integer, the monitoring window further includes a second window, and the second window is the last window in the windows obtained by dividing the windows with the lth source data packet as the starting point within the monitoring period.
[0045] In combination with the first aspect and any possible implementation of the first aspect above, in a fourteenth possible implementation of the first aspect, when the number of source data packets in the first window is greater than a first threshold, the monitoring window also includes the first window.
[0046] That is, only when l is greater than 1 and the number of source data packets in the first window is greater than the first threshold, and the monitoring window also includes the first window, the first window is used as a monitoring window.
[0047] In combination with the first aspect and any possible implementation of the first aspect above, in a fifteenth possible implementation of the first aspect, when the number of source data packets in the second window is greater than a second threshold, the monitoring window also includes a second window.
[0048] That is, only when N / L is not an integer and the number of source data packets in the second window is greater than the second threshold, and the monitoring window also includes the second window, the second window is used as a monitoring window.
[0049] In a second aspect, a fault detection method is disclosed, comprising: determining video quality parameters of a monitored video stream according to a packet loss recovery method of the monitored video stream; wherein the video quality parameters include an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss; and sending the video quality parameters of the monitored video stream to a monitoring device.
[0050] The execution subject of the method provided in the second aspect above can be the network device through which the monitored video stream flows. It can be seen that in the fault detection method provided in the embodiment of the present invention, the network device can determine the video quality parameters that need to be monitored according to the packet loss recovery method set for the monitored video stream. These parameters may include an effective packet loss factor, which can indicate the effectiveness of the packet loss recovery method used to recover network packet loss, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and then, the video service fault detection can be accurately performed according to the video quality parameters of the monitored video stream. For example: although the network condition is not good and the packet loss rate is high, the effective packet loss factor is low, that is, the packet loss recovery method is used to effectively recover the lost source data packets. Therefore, the video service failure that occurs at this time is not caused by the network, but may be caused by the failure of the head-end device or the failure of the user terminal. In summary, the method provided in the embodiment of the present invention improves the accuracy of video service fault detection.
[0051] In combination with the second aspect, in a first possible implementation of the second aspect, before determining the video quality parameters of the monitored video stream according to the packet loss recovery method of the monitored video stream, the method also includes: receiving a video quality parameter request message sent by the monitoring device; the video quality parameter request message is used to indicate the identifier of the monitored video stream and the packet loss recovery method of the monitored video stream.
[0052] In combination with the second aspect, in a second possible implementation method of the second aspect, determining the video quality parameter of the monitored video stream according to the packet loss recovery method of the monitored video stream specifically includes:
[0053] If the monitored video stream does not have a packet loss recovery method set, the video quality parameter includes a packet loss rate, and the packet loss rate is determined; wherein the packet loss rate is a ratio of the number of lost packets to the number of source data packets expected to be received;
[0054] If the packet loss recovery method of the monitored video stream is forward error correction FEC, the video quality parameters include a packet loss rate and a first effective packet loss factor, and the packet loss rate and the first effective packet loss factor (i.e., the effective packet loss factor in the second aspect above) are determined;
[0055] If the monitored video stream is set with both RET and FEC, the video quality parameters include packet loss rate, maximum number of consecutive packet losses, and a second effective packet loss factor (i.e., the effective packet loss factor of the second aspect above), and the packet loss rate, maximum number of consecutive packet losses, and the second effective packet loss factor are determined;
[0056] If the packet loss recovery method of the monitored video stream is RET, the video quality parameters include a packet loss rate, a maximum number of consecutive packet losses, and a third effective packet loss factor, and the packet loss rate, the maximum number of consecutive packet losses, and the third effective packet loss factor are determined.
[0057] It can be seen that for the packet loss recovery methods such as FEC and RET set for the monitored video stream, different video quality parameters are counted. In the scenarios where different packet loss recovery methods are used, the compensation for network packet loss by the packet loss recovery method can be considered while considering the packet loss rate. For example, the first effective packet loss factor indicates the effectiveness of using FEC to recover network packet loss. Specifically, if the video quality parameters include the packet loss rate and the first effective packet loss factor, when the packet loss rate is greater than the corresponding threshold and the first effective packet loss factor is greater than the corresponding threshold, it is determined that the compensation for network packet loss using FEC is not effective. At this time, when the packet loss rate is greater than the corresponding threshold, it can be determined that the video service failure is caused by a network transmission failure.
[0058] In combination with the second aspect and any possible implementation of the second aspect above, in a third possible implementation of the second aspect, the first effective packet loss factor RTP_F satisfies:
[0059] in,
[0060] L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, For x l (1) to x l(K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among the K monitoring windows, and R is the number of redundant data packets of a single source block set by using FEC to recover packet losses.
[0061] In combination with the second aspect and any possible implementation of the second aspect above, in a fourth possible implementation of the second aspect, the second effective packet loss factor ELF_FR satisfies:
[0062] in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, K is the number of corresponding monitoring windows, and the monitoring window includes the first source data packet in the monitoring period, which is obtained by dividing N source data packets according to the length of the source block. windows, the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; lost(k) is the number of source data packets that cannot be recovered by FEC in the kth window of the K monitoring windows, δ is the maximum number of lost packets that can be recovered by RET for E source data packets, and E is the number of source data packets in one monitoring period;
[0063] Or, the second effective factor ELF_FR satisfies:
[0064] in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, for y l (1) to y l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. A window, wherein the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; x l (k) is the number of packet losses in the kth window among K monitoring windows, E' is the number of source data packets recoverable using FEC in the kth window, and R is the maximum number of packet losses recoverable using RET for L source data packets.
[0065] In combination with the second aspect and any possible implementation manner of the second aspect above, in a fifth possible implementation manner of the second aspect, the third effective packet loss factor ELF_R satisfies:
[0066] in,
[0067] Where L is the preset window length; for any l greater than 0 and less than or equal to L, For x l (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the preset window length with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among K monitoring windows; R is the maximum number of packet losses that can be recovered using RET for L source data packets.
[0068] In combination with the second aspect and any possible implementation of the second aspect above, in a sixth possible implementation of the second aspect, sending the video quality parameters of the monitored video stream specifically includes: sending the video quality parameters of the monitored video stream to the monitoring device when it is determined that at least one parameter among the video quality parameters of the monitored video stream is greater than or equal to the corresponding threshold value.
[0069] Here, each device first counts the corresponding video quality parameters according to the set packet loss recovery method, and once it is determined that the video quality parameters exceed the corresponding threshold, the video quality parameters are reported to the monitoring device. In this way, the number of signaling received by the monitoring device can be reduced, and the processing load of the monitoring device can be reduced.
[0070] In combination with the second aspect and any possible implementation of the second aspect above, in a seventh possible implementation of the second aspect, when l is greater than 1, the monitoring window further includes a first window, and the first window is a window formed by a source data packet before the lth source data packet;
[0071] And / or, when N / L is not an integer, the monitoring window further includes a second window, and the second window is the last window in the windows obtained by dividing the windows with the lth source data packet as the starting point within the monitoring period.
[0072] In combination with the second aspect and any possible implementation of the second aspect above, in an eighth possible implementation of the second aspect, when the number of source data packets in the first window is greater than a first threshold, the monitoring window also includes the first window.
[0073] That is, only when l is greater than 1 and the number of source data packets in the first window is greater than the first threshold, and the monitoring window also includes the first window, the first window is used as a monitoring window.
[0074] In combination with the first aspect and any possible implementation of the first aspect above, in a ninth possible implementation of the first aspect, when the number of source data packets in the second window is greater than a second threshold, the monitoring window also includes a second window.
[0075] That is, only when N / L is not an integer and the number of source data packets in the second window is greater than the second threshold, and the monitoring window also includes the second window, the second window is used as a monitoring window.
[0076] In a third aspect, a monitoring device is disclosed, comprising:
[0077] The acquisition unit is used to acquire the video quality parameters of the monitored video stream; the video quality parameters are determined according to the packet loss recovery method of the monitored video stream, and the video quality parameters include an effective packet loss factor, which is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss. The detection unit is used to perform fault detection according to the video quality parameters of the monitored video stream.
[0078] It can be seen that the monitoring device provided by the embodiment of the present invention determines the video quality parameters that need to be monitored according to the packet loss recovery method of the monitored video stream. These parameters may include an effective packet loss factor, which can indicate the effectiveness of the packet loss recovery method used to recover network packet loss, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and thus, can accurately perform video service fault detection according to the video quality parameters of the monitored video stream. For example: although the network condition is not good and the packet loss rate is high, the effective packet loss factor is low, that is, the packet loss recovery method is used to effectively recover the lost source data packets. Therefore, the video service failure that occurs at this time is not caused by the network, but may be caused by a failure of the head-end device or a failure of the user terminal. It can be seen that the method provided by the embodiment of the present invention improves the accuracy of video service fault detection.
[0079] In combination with the third aspect, in a first possible implementation of the third aspect, the above-mentioned device also includes a sending unit. The sending unit is used to send a video quality parameter request message to at least one network device, and the video quality parameter request message is used to indicate the identifier of the monitored video stream and the packet loss recovery method of the monitored video stream. For example, if the monitored video stream is a live video stream, the identifier of the monitored video stream can be a channel number or a multicast address and port; if the monitored video stream is a video-on-demand stream, the identifier of the monitored video stream can be a quintuple. The acquisition unit is specifically used to obtain the video quality parameters of the monitored video stream from the above-mentioned at least one network device.
[0080] In combination with the third aspect and any possible implementation of the third aspect above, in the first possible implementation of the third aspect, if the packet loss recovery method of the monitored video stream is forward error correction FEC, the video quality parameters include the following parameters: a first effective packet loss factor; the first effective packet loss factor is used to indicate the effectiveness of using FEC to recover from network packet loss; if RET and FEC are set for the monitored video stream at the same time, the video quality parameters include the following parameters: the maximum number of consecutive packet losses, the second effective packet loss factor; the second effective packet loss factor is used to indicate the effectiveness of using FEC and RET to recover from network packet loss. If the packet loss recovery method of the monitored video stream is retransmission RET, the video quality parameters include the following parameters: packet loss rate, the maximum number of consecutive packet losses, and the third effective packet loss factor, and the second effective packet loss factor is used to indicate the effectiveness of using RET to recover from network packet loss.
[0081] It can be seen that for the packet loss recovery methods such as FEC and RET set for the monitored video stream, different video quality parameters are counted. In the scenarios where different packet loss recovery methods are used, the compensation for network packet loss by the packet loss recovery method can be considered while considering the packet loss rate, such as: a first effective packet loss factor indicating the effectiveness of using FEC to recover network packet loss. Specifically, if the video quality parameters include the packet loss rate and the first effective packet loss factor, when the first effective packet loss factor is greater than the corresponding threshold value, it is determined that the compensation for network packet loss using FEC is not effective. At this time, it can be determined that the video service failure is caused by a network transmission failure.
[0082] In combination with the third aspect and any possible implementation of the third aspect, in a third possible implementation of the third aspect, the first effective packet loss factor ELF_F satisfies:
[0083] in,
[0084] L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, For xl (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among K monitoring windows, and R is the maximum number of packet losses that can be recovered using FEC for L source data packets.
[0085] In combination with the third aspect and any possible implementation of the third aspect, in a fourth possible implementation of the third aspect,
[0086] The second effective packet loss factor ELF_FR satisfies:
[0087] in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, K is the number of corresponding monitoring windows, and the monitoring window includes the first source data packet in the monitoring period, which is obtained by dividing N source data packets according to the length of the source block. windows, the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; lost(k) is the number of source data packets that cannot be recovered by FEC in the kth window of the K monitoring windows, δ is the maximum number of lost packets that can be recovered by RET for E source data packets, and E is the number of source data packets in one monitoring period;
[0088] or,
[0089] The second effective factor ELF_FR satisfies: in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, for y l (1) to y l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. A window, wherein the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; x l(k) is the number of packet losses in the kth window among K monitoring windows, E' is the number of source data packets recoverable using FEC in the kth window, and R is the maximum number of packet losses recoverable using RET for L source data packets.
[0090] In combination with the third aspect and any possible implementation manner of the third aspect, in a fifth possible implementation manner of the third aspect, the third effective packet loss factor ELF_R satisfies:
[0091] in,
[0092] Where L is the preset window length; for any l greater than 0 and less than or equal to L, For x l (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the preset window length with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among K monitoring windows; R is the maximum number of packet losses that can be recovered using RET for L source data packets.
[0093] In combination with the third aspect and any possible implementation of the third aspect above, in a sixth possible implementation of the third aspect, the at least one network device includes a first device. The detection unit is specifically configured to determine that a fault occurs between the first device and the head-end device if the monitoring device receives the first video quality parameter reported by the first device within a monitoring cycle; the head-end device is a device that provides a monitored video stream; the first video quality parameter is reported to the monitoring device by the first device after determining that at least one parameter in the first video quality parameter exceeds a corresponding threshold.
[0094] In combination with the third aspect and any possible implementation manner of the third aspect above, in a seventh possible implementation manner of the third aspect, at least one network device further includes a second device, and the second device is a downstream device of the first device.
[0095] The detection unit is specifically used to determine that a fault occurs between the first device and the first device if the monitoring device receives a second video quality parameter reported by the second device within a monitoring cycle and does not receive the first video quality parameter; the second video quality parameter is reported to the monitoring device by the second device after the second device determines that at least one parameter of the second video quality parameter exceeds the corresponding threshold value; if the monitoring device does not receive the second video quality parameter and the first video quality parameter within a monitoring cycle, it is determined that a fault occurs between the second device and the user terminal; the user terminal is a device that receives the monitored video stream.
[0096] In combination with the third aspect and any possible implementation of the third aspect above, in an eighth possible implementation of the third aspect, at least one network device includes N network devices through which the monitored video stream flows, where N is an integer greater than or equal to 2; the acquisition unit is specifically used to receive video quality parameters of the monitored video stream sent by each of the N network devices.
[0097] In combination with the third aspect and any possible implementation of the third aspect above, in a ninth possible implementation of the third aspect, the detection unit is specifically used to, if it is determined that at least one parameter of the first video quality parameters reported by the first device among N network devices is greater than or equal to the corresponding threshold value, determine that a fault occurs between the first device and the second device; the head-end device is a device that provides the monitored video stream; if it is determined that the first video quality parameters reported by the first device are all less than the corresponding threshold value, and at least one parameter of the second video quality parameters reported by the second device downstream of the first device among the N network devices is greater than or equal to the corresponding threshold value, then determine that a network fault occurs between the first device and the second device.
[0098] In combination with the third aspect and any possible implementation of the third aspect above, in the tenth possible implementation of the third aspect, the detection unit is also used to determine the failure probability of each network segment in the M+1 network segments; the network segment is a first device, M third devices, and a network between any two adjacent devices in the second device, and the third device is a device between the first device and the second device; the network segment with the highest failure probability in the M+1 network segments is determined as the network segment where the fault occurs; wherein M is an integer less than N.
[0099] In combination with the third aspect and any possible implementation of the third aspect above, in an eleventh possible implementation of the third aspect, the detection unit is specifically used to calculate the failure probability that the Qth parameter in the video quality parameter causes the i-th network segment to fail. i is an integer greater than or equal to 1 and less than or equal to M+1, satisfy:
[0100] in, is the Qth parameter reported by the i+1th device. is the Qth parameter reported by the i-th device, λ Q is the threshold value corresponding to the Qth parameter, and the i+1th device is the upstream device adjacent to the i-th device;
[0101] The failure probability of the parameter with the highest failure probability among all the parameters included in the video quality parameters is determined as the failure probability p of the i-th network segment i .
[0102] In combination with the third aspect and any possible implementation of the third aspect above, in a twelfth possible implementation of the third aspect, the detection unit is further used to calculate the failure probability p of the i-th network segment within T consecutive monitoring cycles. i ', T is an integer greater than or equal to 2; p i 'satisfy:
[0103] Among them, β t =2 -t , t∈[1,.....T];
[0104] Update the failure probability of the i-th network segment to S,
[0105] In combination with the third aspect and any possible implementation of the third aspect above, in a thirteenth possible implementation of the third aspect, when l is greater than 1, the monitoring window further includes a first window, and the first window is a window formed by a source data packet before the lth source data packet;
[0106] And / or, when N / L is not an integer, the monitoring window further includes a second window, and the second window is the last window in the windows obtained by dividing the windows with the lth source data packet as the starting point within the monitoring period.
[0107] In combination with the third aspect and any possible implementation of the third aspect above, in a fourteenth possible implementation of the third aspect, when the number of source data packets in the first window is greater than a first threshold, the monitoring window also includes the first window.
[0108] That is, only when l is greater than 1 and the number of source data packets in the first window is greater than the first threshold, and the monitoring window also includes the first window, the first window is used as a monitoring window.
[0109] In combination with the third aspect and any possible implementation of the third aspect above, in a fifteenth possible implementation of the third aspect, when the number of source data packets in the second window is greater than a second threshold, the monitoring window also includes a second window.
[0110] That is, only when N / L is not an integer and the number of source data packets in the second window is greater than the second threshold, and the monitoring window also includes the second window, the second window is used as a monitoring window.
[0111] In a fourth aspect, a network device is disclosed, comprising:
[0112] A determination unit is used to determine the video quality parameters of the monitored video stream according to the packet loss recovery method of the monitored video stream; wherein the video quality parameters include an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss; a sending unit is used to send the video quality parameters of the monitored video stream to the monitoring device.
[0113] The network device provided by the embodiment of the present invention can determine the video quality parameters that need to be monitored based on the packet loss recovery method of the monitored video stream. These parameters may include an effective packet loss factor, which can indicate the effectiveness of the packet loss recovery method used to recover network packet loss, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and thus, can accurately perform video service fault detection based on the video quality parameters of the monitored video stream. For example: although the network condition is not good and the packet loss rate is high, the effective packet loss factor is low, that is, the packet loss recovery method is used to effectively recover the lost source data packets. Therefore, the video service failure that occurs at this time is not caused by the network, but may be caused by a failure of the head-end device or a failure of the user terminal. In summary, the method provided by the embodiment of the present invention improves the accuracy of video service fault detection.
[0114] In combination with the fourth aspect, in a first possible implementation method of the fourth aspect, it also includes a receiving unit for receiving a video quality parameter request message sent by a monitoring device; the video quality parameter request message is used to indicate the identifier of the monitored video stream and the packet loss recovery method of the monitored video stream.
[0115] In this way, the network device can monitor the corresponding video quality parameters according to the packet loss recovery method of the monitored video stream, so that the monitoring device can accurately detect faults of the video service according to these video quality parameters.
[0116] In combination with the fourth aspect, in a second possible implementation of the fourth aspect, the determination unit is specifically used to: if the packet loss recovery method of the monitored video stream is forward error correction FEC, the video quality parameters include a first effective packet loss factor, and the first effective packet loss factor is determined; if the monitored video stream is set with both RET and FEC, the video quality parameters are determined to include a maximum number of consecutive packet losses and a second effective packet loss factor, and the maximum number of consecutive packet losses and the second effective packet loss factor are determined. If the packet loss recovery method of the monitored video stream is retransmission RET, the video quality parameters include: packet loss rate, maximum number of consecutive packet losses, and a third effective packet loss factor, and the determination unit is used to determine the maximum number of consecutive packet losses, the packet loss rate, and the third effective packet loss factor.
[0117] It can be seen that for the packet loss recovery methods such as FEC and RET set for the monitored video stream, different video quality parameters are counted. In the scenarios where different packet loss recovery methods are used, the compensation for network packet loss by the packet loss recovery method can be considered while considering the packet loss rate, such as: a first effective packet loss factor indicating the effectiveness of using FEC to recover network packet loss. Specifically, if the video quality parameters include the packet loss rate and the first effective packet loss factor, when the first effective packet loss factor is greater than the corresponding threshold value, it is determined that the compensation for network packet loss using FEC is not effective. At this time, it can be determined that the video service failure is caused by a network transmission failure.
[0118] In combination with the fourth aspect and any possible implementation of the fourth aspect above, in a third possible implementation of the fourth aspect, the first effective packet loss factor RTP_F satisfies:
[0119] in,
[0120] L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, For x l (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among the K monitoring windows, and R is the number of redundant data packets of a single source block set by using FEC to recover packet losses.
[0121] In combination with the fourth aspect and any possible implementation of the fourth aspect, in a fourth possible implementation of the fourth aspect, the second effective packet loss factor ELF_FR satisfies:
[0122] in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, K is the number of corresponding monitoring windows, and the monitoring window includes the first source data packet in the monitoring period, which is obtained by dividing N source data packets according to the length of the source block. windows, the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; lost(k) is the number of source data packets that cannot be recovered by FEC in the kth window of the K monitoring windows, δ is the maximum number of lost packets that can be recovered by RET for E source data packets, and E is the number of source data packets in one monitoring period;
[0123] Or, the second effective factor ELF_FR satisfies: in, L is the length of the source block set by FEC to recover packet loss; for any l greater than 0 and less than or equal to L, for y l (1) to y l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the length of the source block with the lth source data packet as the starting point in the monitoring period. A window, wherein the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; x l (k) is the number of packet losses in the kth window among K monitoring windows, E' is the number of source data packets recoverable using FEC in the kth window, and R is the maximum number of packet losses recoverable using RET for L source data packets.
[0124] In combination with the fourth aspect and any possible implementation of the fourth aspect, in a fifth possible implementation of the fourth aspect, the third effective packet loss factor ELF_R satisfies:
[0125] in,
[0126] Where L is the preset window length; for any l greater than 0 and less than or equal to L, For x l (1) to x l(K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the preset window length with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l (k) is the number of packet losses in the kth window among K monitoring windows; R is the maximum number of packet losses that can be recovered using RET for L source data packets.
[0127] In combination with the fourth aspect and any possible implementation of the fourth aspect above, in a sixth possible implementation of the fourth aspect,
[0128] The sending unit is specifically configured to send the video quality parameters of the monitored video stream to the monitoring device when it is determined that at least one parameter of the video quality parameters of the monitored video stream is greater than or equal to a corresponding threshold value.
[0129] In combination with the fourth aspect and any possible implementation of the fourth aspect above, in a seventh possible implementation of the fourth aspect, when l is greater than 1, the monitoring window further includes a first window, and the first window is a window formed by a source data packet before the lth source data packet;
[0130] And / or, when N / L is not an integer, the monitoring window further includes a second window, and the second window is the last window in the windows obtained by dividing the windows with the lth source data packet as the starting point within the monitoring period.
[0131] In combination with the fourth aspect and any possible implementation of the fourth aspect above, in an eighth possible implementation of the fourth aspect, when the number of source data packets in the first window is greater than a first threshold, the monitoring window also includes the first window, and the monitoring window also includes the first window.
[0132] That is, only when l is greater than 1 and the number of source data packets in the first window is greater than the first threshold, and the monitoring window also includes the first window, the first window is used as a monitoring window.
[0133] In combination with the fourth aspect and any possible implementation of the fourth aspect above, in a ninth possible implementation of the fourth aspect, when the number of source data packets in the second window is greater than a second threshold, the monitoring window also includes the second window, and the monitoring window also includes the second window.
[0134] That is, only when N / L is not an integer and the number of source data packets in the second window is greater than the second threshold, and the monitoring window also includes the second window, the second window is used as a monitoring window.
[0135] According to a fifth aspect of an embodiment of the present invention, a monitoring device is provided, which may include: at least one processor, a memory, a communication interface, and a communication bus; at least one processor is connected to the memory and the communication interface through a communication bus, and the memory is used to store computer execution instructions. When the server is running, the processor executes the computer execution instructions stored in the memory, so that the monitoring device executes the fault detection method of the first aspect or any possible implementation method of the first aspect.
[0136] According to a sixth aspect of an embodiment of the present invention, a network device is provided, which may include: at least one processor, a memory, a communication interface, and a communication bus; at least one processor is connected to the memory and the communication interface through a communication bus, and the memory is used to store computer execution instructions. When the server is running, the processor executes the computer execution instructions stored in the memory so that the device executes the fault detection method of the first aspect or any possible implementation method of the first aspect.
[0137] According to a seventh aspect of an embodiment of the present invention, a computer storage medium is provided for storing computer software instructions used by the above-mentioned monitoring device, wherein the computer software instructions include a program for executing the above-mentioned fault detection method.
[0138] According to an eighth aspect of an embodiment of the present invention, a computer storage medium is provided for storing computer software instructions used by the above-mentioned device, wherein the computer software instructions include a program for executing the above-mentioned fault detection method. BRIEF DESCRIPTION OF THE DRAWINGS
[0139] Figure 1 A schematic diagram of an existing IPTV video service;
[0140] Figure 2 It is a schematic diagram of the principle of the existing FEC technology;
[0141] Figure 3 A schematic diagram of different packet loss distributions provided by an embodiment of the present invention;
[0142] Figure 4 A schematic diagram of a video quality monitoring system provided by an embodiment of the present invention;
[0143] Figure 5 A schematic diagram of a fault detection deployment provided by an embodiment of the present invention;
[0144] Figure 6 Another schematic diagram of fault detection deployment provided by an embodiment of the present invention;
[0145] Figure 7 A schematic diagram of the composition of a network device provided in an embodiment of the present invention;
[0146] Figure 8 A schematic diagram of the composition of a monitoring device provided in an embodiment of the present invention;
[0147] Fig. 9 A flowchart of a fault detection method provided by an embodiment of the present invention;
[0148] Fig.10 Another flow chart of the fault detection method provided by an embodiment of the present invention;
[0149] Fig.11 Another flow chart of the fault detection method provided by an embodiment of the present invention;
[0150] Fig.12 Another schematic diagram of the components of the monitoring device provided by an embodiment of the present invention;
[0151] Fig.13 Another schematic diagram of the components of the monitoring device provided by an embodiment of the present invention;
[0152] Fig.14 Another schematic diagram of the composition of a network device provided by an embodiment of the present invention;
[0153] Fig.15 Another schematic diagram of the composition of the network device provided by the embodiment of the present invention. DETAILED DESCRIPTION
[0154] The technical solutions in the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.
[0155] like Figure 1 As shown, the IPTV video service is provided by the operator with head end equipment (HE) and user terminals, wherein HE provides IPTV video source, encodes the video source into a video stream, and then divides the video stream into multiple source data packets, which are transmitted to the user terminal, such as a set top box (STB), via network devices such as a content delivery network (CDN) and a broadband remote access server (BARS), and then transmitted to a display device (such as a TV) by the set top box for display. During the transmission of the video stream from the head end device to the first network device, the video stream can also be transmitted to the service inspection gateway (SIG) by mirroring. Usually, during the transmission process, packet loss or delay may occur due to the influence of network conditions, which will affect the video service, for example, a distorted screen appears when the display device is playing.
[0156] The existing technology can characterize the impact of network conditions on video service quality through the Media Loss Rate (MLR) and Delay Factor (DF) during the transmission of source data packets. The packet loss rate is the ratio of the number of source data packets lost to the number of source data packets to be transmitted during the transmission of the monitored video stream from the head-end device to the user terminal.
[0157] For example: before transmission, the head-end device encodes the video source into 10 source data packets, that is, there are 10 source data packets to be transmitted. After transmission by the core router (CR) and other devices, the user terminal receives 8 source data packets, indicating that 2 source data packets are lost during network transmission. Therefore, the packet loss rate is 2 / 10, that is, 20%. In addition, DF is used to characterize the rate of change of the cache occupied by the video stream within a monitoring cycle. Specifically, when the DF value is large, it indicates that the video stream occupies a very fast change in the cache during the monitoring period, indicating that the source data packet suddenly arrives very quickly or suddenly arrives very slowly, which indicates that the network is unstable; when the DF value is very small, it indicates that the video stream occupies a small change in the cache during the monitoring period, indicating that the network is relatively stable.
[0158] When monitoring the network operation status in real time, the respective threshold values of DF and MLR can be preset. Once it is found that the value is lower than or higher than the threshold value, an alarm can be issued in time.
[0159] Currently, operators have adopted a variety of packet loss recovery methods to reduce the adverse effects of network quality on media transmission, such as forward error correction (FEC) and retransmission (RET) technology. Among them, FEC inserts redundant data packets into the original video stream to improve the resistance of media services to network packet loss. Specifically, refer to Figure 2 , the head-end device divides the video source into several source data packets of equal size, divides each k source data packets into a source block, and encodes each source block to generate n redundant data packets. Then, the source block and redundant data packets are sent to the user terminal. After network transmission, m data packets are received at the receiving end. For a source block, as long as the number of data packets received by the user terminal is greater than the number of source data packets, that is, m ≥ k, the received data packets can be used to restore k source data packets.
[0160] In addition, after the RET algorithm is deployed, when the user terminal detects packet loss, it can initiate a retransmission request to the RET server, requesting the RET server to transmit the lost source data packet, thereby ensuring the quality of media services.
[0161] When using packet loss recovery methods, the sensitivity of media services to packet loss rate will also change. Taking FEC as an example, refer to Figure 3 If the packet loss rate is lower than the threshold and the packet loss distribution is relatively concentrated, the STB cannot use the FEC algorithm to recover the source data packets transmitted by the video head end, and the display device will have a distorted screen when playing. The user's video experience is affected by network packet loss. However, since the packet loss rate is less than the threshold, after the video service fails, the technicians believe that the video service failure is not caused by network transmission. Alternatively, if the packet loss rate is higher than the threshold but the packet loss distribution is relatively dispersed, the STB can use the FEC algorithm to recover the source data blocks transmitted by the video head end, which will not affect the user's video experience. However, if the packet loss rate is greater than the threshold, after the video service fails, the technicians will believe that the video service failure is caused by network transmission.
[0162] It can be seen that the existing technology does not take into account the packet loss recovery methods such as FEC and RET used by operators when detecting video service faults, and cannot accurately reflect the impact of network transmission on the quality of video services, and thus cannot accurately detect faults. For example, if the video head end and STB deploy the FEC algorithm, but the packet loss rate is lower than the threshold and the packet loss distribution is relatively concentrated, the STB cannot use the FEC algorithm to recover the source data blocks transmitted by the video head end, and the display device will have a distorted screen when playing, and the user's video experience will be affected by network packet loss. However, because the packet loss rate is less than the threshold, the technicians believe that the video service failure is not caused by network transmission.
[0163] The embodiment of the present invention provides a fault detection method, the basic principle of which is that the network device through which the monitored video stream flows monitors different delimiting indicators (i.e., the video quality parameters described in the embodiment of the present invention) for different packet loss recovery methods (FEC, RET) used by the operator. These indicators are determined according to the packet loss recovery method used, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and accurately reflecting the impact of network transmission quality on video service quality. Furthermore, when performing fault detection, the monitoring device can accurately determine the impact of network transmission quality on video service quality based on the video quality parameters reported by the device, thereby improving the accuracy of video service fault detection. For example, although the network condition is not good and the packet loss rate is high, the lost source data packets are recovered by the packet loss recovery method. Therefore, the video service failure that occurs at this time is not caused by the network, but may be caused by a failure of the head-end device or a failure of the user terminal.
[0164] It should be noted that the "fault detection" involved in the embodiments of the present invention may include detecting whether a fault exists and performing fault demarcation. The so-called fault demarcation means determining the device or network segment where the fault occurs when a video service fails, such as a distorted screen or freezes when a display device plays.
[0165] The following will describe in detail the implementation of the embodiment of the present invention in conjunction with the accompanying drawings:
[0166] The embodiment of the present invention provides a video quality monitoring system, such as Figure 4 As shown, the video quality monitoring system includes a head-end device, a network device through which the monitored video stream flows, a user terminal, and a monitoring device.
[0167] The head-end device is used to provide a video source and transcode the video source into a video stream (including multiple source data packets) with a constant bit rate and send it to the device closest to the head-end device in a live broadcast mode. The head-end device can be a HE server. In addition, the head-end device mirrors the video stream to the SIG. In the embodiment of the present invention, the network device through which the monitored video stream flows can be BARS, optical network terminal (Optical network terminal, ONT), optical line terminal (Optical Line Terminal, OLT), CR and other devices in addition to SIG.
[0168] The user terminal is used to receive the video stream, and may be a STB.
[0169] It should be noted that, in the embodiment of the present invention, the transmission direction of the video stream can be considered to be from upstream (i.e., the direction pointing to the head-end device) to downstream (i.e., the direction pointing to the user terminal). At the same time, the device closest to the head-end device among the network devices through which the monitored video stream flows can be called the most upstream device; the device closest to the user terminal among the network devices through which the monitored video stream flows can be called the most downstream device. In the embodiment of the present invention, the most upstream device can be considered to be the SIG, and the most downstream device can be considered to be the ONT.
[0170] Generally, when a video quality parameter monitored by a device exceeds a corresponding threshold, it can be considered that a fault has occurred upstream of the network device. For example, a probe can be deployed on the SIG. When the video quality parameter monitored by the probe deployed on the SIG exceeds the corresponding threshold, it can be considered that a fault has occurred upstream of the SIG. Since there is only a head-end device upstream of the SIG, it can be considered that a fault has occurred at the head-end. It should be noted that if the probe is deployed at the input port of a device, the upstream device of the network device does not include the network device. If the probe is deployed at the output port of the network device, the upstream device of the network device includes the network device.
[0171] refer to Figure 4 In the video quality monitoring system shown, the ONT is the network device closest to the user terminal, that is, the most downstream device, and the SIG is the network device closest to the head-end device, that is, the most upstream device.
[0172] Among them, CR is composed of central processing unit (CPU), random access memory / dynamic random access memory (RAM / DRAM), Flash, non-volatile random access memory (NVRAM), read only memory (ROM) and various interfaces. BRAS is mainly composed of service management module and service forwarding module. OLT includes main control board, service board, interface board, power board, etc.
[0173] When the video stream is transmitted from the head-end device to the user terminal (set-top box), due to the change of the network status, the source data packets of the video stream will be lost, delayed, jittered, disordered and other abnormal phenomena. These abnormal phenomena will cause defects such as screen distortion on the video screen played on the terminal, resulting in failure of the video service quality. Therefore, the acquisition module can be deployed on each device in the video quality monitoring system to monitor video quality parameters, such as packet loss rate, delay jitter and other parameters, so as to detect video service faults based on these parameters.
[0174] Depending on the deployment mode of the acquisition module, there are two typical deployment scenarios:
[0175] First, reference Figure 5 , the acquisition module is deployed on ONT and SIG. By monitoring the video quality parameters collected on ONT and SIG, the fault detection of video service can be realized. Specifically, it can be determined whether the video service fault is caused by the fault of the user terminal, the network, or the head-end device.
[0176] For example, after a video service fails, fault detection is performed based on the video quality parameters collected on the ONT and SIG. If the video quality parameters collected on the ONT exceed the threshold, the video service failure is considered to be caused by a network failure; if the video quality parameters collected on the SIG exceed the threshold, the video service failure is considered to be caused by a head-end device failure; if the video quality parameters collected on the ONT and SIG do not exceed the threshold, the video service failure is considered to be caused by a user terminal failure.
[0177] Second, reference Figure 6 The acquisition module can be deployed on network devices such as ONT, OLT, BARS, CR, SIG, etc. to collect video quality parameters. For example, it can be deployed on the CPU of CR; it can be deployed on the main control CPU of the service management module of BARS; it can be deployed on the main control board CPU of OLT.
[0178] Deploy the collection module to Figure 6 On the multiple devices shown, the failure of the video service can be localized to a specific network segment or device. In an embodiment of the present invention, if the video quality parameter collected on the ONT exceeds a threshold, it is considered that the video service failure is caused by a network failure. Further, it is also possible to determine which network segment has a failure based on the video quality parameters reported by two adjacent devices. Specifically, among all devices that transmit video streams, the network between any two adjacent devices is called a network segment. The probability of failure of each network segment is determined, and the network segment with the highest probability of failure is determined. It can be considered that the video service failure is caused by the failure of the network segment.
[0179] Figure 7 A schematic diagram of the composition of a network device provided in an embodiment of the present invention, the network device may be a network device through which a monitored video stream flows in an embodiment of the present invention, such as: Figure 4 The network devices in the video quality monitoring system shown in FIG. include BARS, ONT, OLT, CR, SIG, etc. Figure 7 As shown, the network device may include at least one processor 11 , a memory 12 and a communication interface 13 .
[0180] Combine the following Figure 7 A detailed introduction to each component of the network equipment:
[0181] The processor 11 is the control center of the network device, and may be a processor or a general term for multiple processing elements. For example, the processor 11 is a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention, such as one or more microprocessors (digital signal processors, DSPs), or one or more field programmable gate arrays (Field Programmable Gate Arrays, FPGAs).
[0182] The processor 11 can execute various functions of the network device by running or executing software programs stored in the memory 12 and calling data stored in the memory 12.
[0183] In a specific implementation, as an embodiment, the processor 11 may include one or more CPUs, such as Figure 7 CPU0 and CPU1 are shown in the figure.
[0184] In a specific implementation, as an embodiment, the network device may include multiple processors, such as Figure 7 1 and 15 are shown in FIG. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor here may refer to one or more network devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).
[0185] The memory 12 may be a read-only memory (ROM) or other types of static storage network devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage network devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage network devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 12 may exist independently and be connected to the processor 11 via the communication bus 14. The memory 12 may also be integrated with the processor 11.
[0186] The memory 12 is used to store the software program for executing the solution of the present invention, and the execution is controlled by the processor 11.
[0187] The communication interface 13 may include two communication interfaces, one for communicating with an external network device (such as: Figure 4 an upstream network device or a downstream network device adjacent to the network device, or, Figure 4 The communication interface 13 includes a transmission interface for transmitting data to the monitoring device shown in the figure and a receiving interface for receiving data from an external network device, that is, the network device can respectively realize data reception and data transmission through two different communication interfaces. Of course, the communication interface 13 can integrate the data receiving function and the data transmitting function into one communication interface, and the communication interface has the data receiving function and the data transmitting function.
[0188] Figure 7 The network device structure shown in the figure does not constitute a limitation on the network device, and may include more or less components than those shown in the figure, or combine certain components, or arrange the components differently.
[0189] In an embodiment of the present invention, different video quality parameters are used to characterize the adverse effects of network transmission on media quality and user experience quality for different packet loss recovery methods set for monitored video streams. The monitored video stream may be a video stream of a specific channel or a video stream of a user terminal. The embodiment of the present invention will introduce the video quality parameters determined by each device in the video quality monitoring system for the following four scenarios: a scenario where no packet loss recovery method is set, a scenario where only FEC is set, a scenario where only RET is set, and a scenario where both FEC and RET are set.
[0190] First, in the scenario where the packet loss recovery method is not used, the video quality parameter determined by the device is the packet loss rate RTP_LR, that is, the ratio of the number of source data packets lost during the video stream transmission to the number of source data packets to be transmitted (that is, multiple source data packets divided by the head-end device according to the video stream of the target monitoring device).
[0191] When calculating RTP_LR, the device first creates a cache queue, sorts the received real-time transport protocol (RTP) messages (ie, the source data packets), and then detects packet loss using the sequence number of the sorted RTP message header to calculate RTP_LR.
[0192] In addition, the delay and jitter of the RTP message during transmission to the network device will cause underflow at the decoding end. The device can also convert the underflow at the decoding end into packet loss processing. The so-called underflow at the decoding end means that the user terminal has a cache. If the RTP message delay is large, the cache will become empty. At this time, the decoder of the user terminal will decode incorrectly. The RTP message that arrives in the receiving end cache cannot be decoded and will be directly discarded. In the specific implementation, the device can set the size of the cache queue to be close to the decoding cache size of the head-end device.
[0193] Specifically, RTP_LR satisfies the following formula (1):
[0194]
[0195] Wherein, losspktNum represents the number of lost RTP packets, and expectedpktNum represents the number of RTP packets expected to be received (ie, the source data packets described in the embodiment of the present invention). Figure 4 , assuming that the head-end device divides the video source of the monitored video stream into t source data packets, for the subsequent devices, the number of source data packets expected to be received will also be t.
[0196] Second, in the scenario where only FEC is set, the video quality parameters determined by the device include RTP_LR and the effective packet loss factor of the FEC scenario. The effective packet loss factor of the FEC scenario is the first effective packet loss factor described in the embodiment of the present invention, which can be an effective packet loss factor a used to indicate the probability of failure to recover from network packet loss using FEC. Of course, it can also be an effective packet loss factor b used to indicate the probability of effective recovery from network packet loss using FEC, where b=1-a. Both a and b can indicate the effectiveness of using FEC to recover from network packet loss. The following will only take the first effective packet loss factor as an example to indicate the probability of failure to recover from network packet loss using FEC (Effective Loss Factor for FEC) to describe the calculation method of the first effective packet loss factor.
[0197] In a specific implementation, ELF_F (i.e., the above-mentioned effective packet loss factor a) satisfies the following formula (2):
[0198]
[0199] in,
[0200] In addition, 0<l≤L, 0<k≤K.
[0201] In addition, it can be seen from the above that the value range of ELF_F is 0≤ELF_F≤1.
[0202] It should be noted that when using FEC, multiple source data packets corresponding to the video source need to be divided into multiple source blocks of the same size, and each source block includes the same number of source data packets, such as: every 100 source data packets are divided into one source block. Further, multiple redundant data packets are generated for each source block encoding, and the number of redundant data packets corresponding to each source block is the same. Here, L is the length of the source block set by using FEC to recover packet loss, that is, the number of source data packets included in a single source block, such as 100;
[0203] For any l greater than 0 and less than or equal to L, the above formula (2) For x l (1) to x l (K) is the average value after summing, where K in the above formula (2) is the number of monitoring windows, and the monitoring window includes the first source data packet as the starting point in the monitoring period, which is obtained by dividing N source data packets according to the length of the source block. The so-called N source data packets here are the source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period. It should be noted that the above N source data packets include the lth source data packet and the last source data packet in the monitoring period. represents the rounding down of *. For example, N / L = 5.2, 5.2 is rounded down to 5. For example, for a certain l, if the monitoring window includes and only includes the previous windows, and Then the K corresponding to this l is 5.
[0204] R is the maximum number of packet losses that can be recovered using FEC for L source data packets. It is usually the number of redundant data packets of a single source block set by FEC to recover packet losses. For example, if 5 redundant data packets are generated for each source block encoding, then R is 5.
[0205] Num l (k) represents the number of packet losses in the kth window under the lth slide, that is, the number of packet losses in the kth window among the K monitoring windows, and R is the number of redundant data packets of a single source block set by using FEC to recover packet losses. It should be noted that the so-called slide means that the window is divided according to the length of the source block, starting from one source data packet in turn according to the order of transmission of the source data packets. For example, assuming that there are 100 source data packets to be transmitted within the monitoring period, the length of the source block is 5, the lth slide divides the window, that is, starting from the lth source data packet among the above 100 source data packets, and every 5 source data packets are divided into a window; the 8th slide divides the source block, that is, starting from the 8th source data packet among the above 100 source data packets, and every 5 source data packets are divided into a window.
[0206] In addition, the monitoring period may be an artificially set observation period, such as 10 seconds.
[0207] Third, when both FEC and RET are set, the video quality parameters determined by the device include: packet loss rate RTP_LR, maximum continuous packet loss length RTP_LP, and effective packet loss factor for RET and FEC scenarios, i.e., the second effective packet loss factor described in the embodiment of the present invention. The second effective packet loss factor can be an effective packet loss factor m for indicating the probability of failure to recover from packet loss using RET and FEC, or an effective packet loss factor n for indicating the probability of effective recovery from packet loss using RET and FEC, where m=1-n. Both n and m can represent the effectiveness of using RET and FEC to recover from network packet loss. The calculation method of the second effective packet loss factor will be introduced later using the effective packet loss factor ELF_FR (effective loss factor for FEC and RET) for indicating the probability of failure to recover from packet loss using RET and FEC as an example.
[0208] ELF_FR (i.e., the above-mentioned effective packet loss factor m) satisfies the following formula (3):
[0209]
[0210] in,
[0211] Here, L is the length of the source block set by using FEC to recover packet loss; for any l greater than 0 and less than or equal to L, K is the number of corresponding monitoring windows, and the monitoring window includes the first source data packet obtained by dividing the N source data packets according to the preset window length within the monitoring period with the lth source data packet as the starting point windows, the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; lost(k) is the number of source data packets that cannot be recovered by FEC in the kth window of the K monitoring windows, δ is the maximum number of lost packets that can be recovered by RET for E source data packets, and E is the number of source data packets in a monitoring period, that is, the number of source data packets expected to be received in a monitoring period. Usually, if the packet loss in the kth window cannot be recovered, lost(k) is actually the number of all packet losses in the kth window. As long as one packet loss in the kth window can be recovered, all packet losses in the window can be recovered, and then lost(k) is 0.
[0212] It should be noted that, in some embodiments, x(l) may also be At this time, δ is the ratio of the maximum number of lost packets that can be recovered using RET for the E source data packets to the number E of source data packets expected to be received.
[0213] Alternatively, ELF_FR satisfies the following formula (4):
[0214] The effective packet loss factor ELF_FR satisfies:
[0215] in,
[0216] It should be noted that L in formula (4) is the length of the source block set by using FEC to recover packet loss; for any l greater than 0 and less than or equal to L, for y l (1) to y l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the first source data packet as the starting point in the monitoring period, and the N source data packets are divided according to the preset window length to obtain the previous A window, wherein the N source data packets are source data packets from the lth source data packet in the monitoring period to the last source data packet in the monitoring period; x l(k) is the number of packet losses in the kth window among the K monitoring windows, E' is the number of source data packets that can be recovered using FEC in the kth window, and R is the maximum number of packet losses that can be recovered using RET for L source data packets. For example: L is 100, assuming that at most 5 packets are retransmitted for every 100 packets, then R is 5.
[0217] Fourth, in the scenario where only the RET scenario is set, the video quality parameters determined by the device include the packet loss rate RTP_LR, the maximum consecutive loss period (RTP_LP) and the third effective packet loss factor. The third effective packet loss factor can be an effective packet loss factor x for indicating the probability of failure to recover from packet loss using RET, or it can be an effective packet loss factor y for indicating the probability of effective recovery from packet loss using RET. Wherein, x=1-y. Both y and x can represent the effectiveness of using RET to recover from network packet loss. Subsequently, the calculation method of the third effective packet loss factor will be introduced using the effective loss factor ELF_R (effective loss factor for RET) for indicating the probability of failure to recover from packet loss using RET as an example.
[0218] RTP_LP is the maximum value of the number of consecutive packet losses. For example, the number of consecutive packet losses is: the first consecutive packet loss number is 2, the second consecutive packet loss number is 2, and the third consecutive packet loss number is 4, so RTP_LP is 4.
[0219] The third effective packet loss factor ELF_R (i.e. the above effective packet loss factor x) satisfies:
[0220]
[0221] in,
[0222] It should be noted that L is the preset window length, which can be considered as the number of source data packets included in a window. For example, if 100 source data packets are preset as a window, L is set to 100. For any l greater than 0 and less than or equal to L, For x l (1) to x l (K) is the average value after summing, K is the number of monitoring windows, and the monitoring window includes the previous source data packets obtained by dividing N source data packets according to the preset window length with the lth source data packet as the starting point in the monitoring period. windows, the N source data packets are source data packets from the first source data packet in the monitoring period to the last source data packet in the monitoring period; Num l(k) is the number of packet loss in the kth window among K monitoring windows. For example, assume that N is 100, L is 10, and Num 2 (5) represents the number of packet losses in the fifth window obtained when every 10 source data packets are divided into one window, starting from the second source data packet among 100 source data packets;
[0223] R is the maximum number of lost packets that can be recovered using FEC for L source data packets. For example, L is 100. Assuming that at most 5 packets are retransmitted for every 100 packets, R is 5.
[0224] In some embodiments, when l is greater than 1, the monitoring windows in the above four scenarios may also include a first window, where the so-called first window is a window formed by source data packets before the lth source data packet, that is, the source data packets in the first window are all source data packets before the lth source data packet in the monitoring period. Optionally, the first window is used as a monitoring window only when the number of source data packets in the first window is greater than a first threshold. The first threshold may be set to
[0225] In some embodiments, when N / L is not an integer, the monitoring window further includes a second window, which is the last window in the window obtained by dividing the window with the lth source data packet as the starting point within the monitoring period. Optionally, the second window is used as a monitoring window only when the number of source data packets in the second window is greater than a second threshold. The second threshold and the first threshold can be the same value, such as being set to
[0226] For example, source data packets with sequence numbers 1 to 8 are one monitoring period, the window length (which can be the length of the source block or the preset window length) is 3, and the window is divided from the second source data packet as the starting point, that is, from the source data packet with sequence number 2 as the starting point, and the divided windows are [source data packet with sequence number 2, source data packet with sequence number 3, source data packet with sequence number 4], [source data packet with sequence number 5, source data packet with sequence number 6, source data packet with sequence number 7], [source data packet with sequence number 8]. There are a total of 7 source data packets from the second source data packet to the last source data packet in the monitoring period, so the above N is 7. If the monitoring window is the previous windows, then the monitoring windows are [source data packet numbered 2, source data packet numbered 3, source data packet numbered 4], [source data packet numbered 5, source data packet numbered 6, source data packet numbered 7].
[0227] Further, the first window is a window formed by the source data packet before the second source data packet, and the source data packet in the first window is the source data packet with sequence number 1, so the first window can also be used as a monitoring window. Of course, if it is determined based on the first threshold whether to use the first window as a monitoring window, and the first threshold is 2, and the number of source data packets in the first window is 1, then the first window cannot be used as a monitoring window.
[0228] In addition, the second window is the last window in the window obtained by dividing the window with the second source data packet as the starting point within the monitoring period, and the source data packet in the second window is the source data packet with sequence number 8, so the second window can be used as a monitoring window. Of course, if it is determined based on the second threshold whether to use the second window as a monitoring window, and the second threshold is 2, and the number of source data packets in the second window is 1, then the second window cannot be used as a monitoring window.
[0229] It should be noted that when l is different, the corresponding K may be different. Take a window as an example, assuming that the source data packets with sequence numbers 1 to 7 are one monitoring cycle, and the window length is 3. When l is 1, the monitoring window includes [source data packet with sequence number 1, source data packet with sequence number 2, source data packet with sequence number 3], [source data packet with sequence number 4, source data packet with sequence number 5, source data packet with sequence number 6], and K is 2; when l is 3, the monitoring window includes [source data packet with sequence number 3, source data packet with sequence number 4, source data packet with sequence number 5], and K is 1.
[0230] It should also be noted that in the specific implementation, the monitoring period or window is divided according to the sequence number of the source data packet, that is, the network packet loss is also divided into the monitoring period or a certain window. For example, the source data packets in the monitoring period are the 10 source data packets with sequence numbers 11 to 20, the source block length is 3, and the source data packet with sequence number 18 is lost during the transmission process. Assuming that the window is divided with the second source data packet of the above 10 source data packets as the starting point, the obtained windows are [source data packet with sequence number 12, source data packet with sequence number 13, source data packet with sequence number 14], [source data packet with sequence number 15, source data packet with sequence number 16, source data packet with sequence number 17], [source data packet with sequence number 18, source data packet with sequence number 19, source data packet with sequence number 20].
[0231] Figure 8 A schematic diagram of a monitoring device provided in an embodiment of the present invention. The monitoring device can Figure 4 The monitoring equipment in the video quality monitoring system shown in FIG. Figure 8 As shown, the monitoring device may include at least one processor 21 , a memory 22 and a communication interface 23 .
[0232] Combine the following Figure 8 A detailed introduction to the various components of the monitoring equipment:
[0233] The processor 21 is the control center of the monitoring device, and can be a processor or a general term for multiple processing elements. For example, the processor 21 is a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention, such as one or more microprocessors (digital signal processors, DSPs), or one or more field programmable gate arrays (Field Programmable Gate Arrays, FPGAs).
[0234] The processor 21 can perform various functions of the monitoring device by running or executing software programs stored in the memory 22 and calling data stored in the memory 22.
[0235] In a specific implementation, as an embodiment, the processor 21 may include one or more CPUs, such as Figure 8 CPU0 and CPU1 are shown in the figure.
[0236] In a specific implementation, as an embodiment, the monitoring device may include multiple processors, such as Figure 4 21 and processor 25 shown in FIG. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).
[0237] The memory 22 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 22 may exist independently and be connected to the processor 21 via a communication bus 24. The memory 22 may also be integrated with the processor 21.
[0238] The memory 22 is used to store the software program for executing the solution of the present invention, and the execution is controlled by the processor 21.
[0239] The communication interface 23 may include two communication interfaces, one for communicating with an external device (such as: Figure 4 The communication interface 23 includes a transmitting interface for transmitting data to a network device (such as a BARS, ONT, etc.) through which the monitored video stream flows, and a receiving interface for receiving data from an external device, that is, the monitoring device can respectively realize data reception and data transmission through two different communication interfaces. Of course, the communication interface 23 can also integrate the data receiving function and the data sending function into one communication interface, and the communication interface has the data receiving function and the data sending function.
[0240] Figure 8 The structure shown in the figure does not constitute a limitation on the monitoring device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.
[0241] In some embodiments, the processor 21 calls the code in the memory 22 to monitor the video quality of the monitored video stream, and then perform fault detection. Specifically, the communication interface 23 sends a video quality parameter request message to at least one network device through which the monitored video stream flows, and the request includes information about the monitored video stream. In a specific implementation, it can be Figure 5In the scenario shown, the collection module is deployed on ONT and SIG. The at least one network device mentioned above can be ONT and SIG. ONT can be considered as the network device closest to the user terminal, and SIG is the network device closest to the head-end device. Of course, it can also be Figure 6 In the scenario shown, the at least one network device includes BARS, ONT, OLT, CR, and SIG.
[0242] The processor 21 obtains the video quality parameter of the monitored video stream monitored by at least one network device through which the monitored video stream flows through through the communication interface 23. The video quality parameter is determined by the network device through which the monitored video stream flows according to the packet loss recovery method of the monitored video stream, and specifically refers to the video quality parameters in the above four scenarios: the scenario in which the packet loss recovery method is not set, the scenario in which only FEC is set, the scenario in which only RET is set, and the scenario in which both FEC and RET are set.
[0243] If the processor 201 of the monitoring device obtains the video quality parameters of the monitored video streams monitored by the first device and the second device, taking the first device as SIG and the second device as ONT as an example, that is, Figure 5 In the deployment scenario shown, after the communication interface 23 sends a video quality parameter request message to the ONT and the SIG, the ONT determines that at least one of the video quality parameters monitored by itself exceeds the corresponding threshold value and then reports the video quality parameter to the monitoring device. Specifically, if one of the multiple video quality parameters exceeds the corresponding threshold value, the video quality parameter is reported, or multiple video quality parameters can be reported together.
[0244] For example, if the packet loss recovery method set for the monitored video stream is FEC, the video quality parameters determined by the ONT include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F. If the packet loss rate RTP_LR exceeds its corresponding threshold, the ONT reports RTP_LR to the monitoring device and may also report ELF_F. It should be noted that the threshold corresponding to the packet loss rate is different in the scenario where the packet loss recovery method is not set and the scenario where the packet loss recovery method is set. For example, the threshold corresponding to the packet loss rate in the scenario where the packet loss recovery method is not set is less than the threshold corresponding to the packet loss rate in the scenario where the packet loss recovery method is set.
[0245] Similarly, the video quality parameters determined by SIG include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F. If the packet loss rate RTP_LR exceeds its corresponding threshold, the ONT reports RTP_LR to the monitoring device and may also report ELF_F.
[0246] If the processor 201 of the monitoring device obtains the video quality parameters reported by all devices through which the monitored video stream flows, that is, Figure 6 In the deployment scenario shown, after the communication interface 23 sends a video quality parameter request message to each of the devices such as ONT and OLT, each device determines the video quality parameters monitored by itself, and then reports all the monitored video quality parameters to the monitoring device. For example, if the packet loss recovery method set by the monitored video stream device is FEC, the video quality parameters determined by the ONT include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F, and the BARS, ONT, OLT, CR, SIG, etc. will report the RTP_LR and ELF_F monitored by each device to the monitoring device.
[0247] Furthermore, when a video service failure occurs in a user terminal, for example, a distorted screen occurs when a display device plays, the processor 21 performs fault detection based on the video quality parameters of the monitored video stream sent by at least one network device through which the monitored video stream flows. Figure 5 In the scenario shown, if the monitoring device receives the video quality parameters reported by the first device within a monitoring period, it indicates that a fault occurs between the first device and the head-end device. In some embodiments, the first device is SIG, and when the monitoring device receives the video quality parameters reported by SIG, it is determined that the head-end device has a fault.
[0248] Or, the processor 21 receives the video quality parameter reported by the second device through the communication interface 23 within the monitoring period and does not receive the video quality parameter reported by the first device, indicating that a network failure occurs between the first device and the second device. In some embodiments, the first device is a SIG and the second device is an ONT. When the monitoring device does not receive the video quality parameter reported by the SIG within a monitoring period and receives the video quality parameter reported by the ONT, it is determined that a network failure occurs between the SIG and the ONT.
[0249] Or, if the processor 21 does not receive the video quality parameters reported by the first device and the video quality parameters reported by the second device through the communication interface 23 during the monitoring period, it means that there is no fault upstream of the second device (including the second device), and the fault of the video service is caused by a fault between the second device and the user terminal. In some embodiments, the first device is a SIG, the second device is an ONT, and the ONT is directly connected to the user terminal (such as: STB), and no other devices are connected. Therefore, it can be determined that the fault of the video service is caused by a fault of the user terminal.
[0250] In some embodiments, if the probability that the processor 21 receives the first video quality parameter reported by the first device in at least two consecutive monitoring cycles is greater than or equal to the third threshold value, it is determined that a fault occurs between the first device and the head-end device. Example: The third threshold value is 70%. Assuming that the processor 21 receives the first video quality parameter reported by the first device in 3 monitoring cycles within 4 consecutive monitoring cycles, that is, the probability of receiving the first video quality parameter is 75%, which is greater than 70%, and the processor 21 determines that a fault occurs between the first device and the head-end device.
[0251] Similarly, if the probability that the processor 21 receives the second video quality parameter reported by the second device within the at least two consecutive monitoring cycles is greater than or equal to the fourth threshold value, and the probability that the processor 21 receives the first video quality parameter within the at least two consecutive monitoring cycles is less than the above-mentioned third threshold value, it is determined that a network failure has occurred between the first device and the second device.
[0252] Alternatively, if the probability that the processor 21 receives the second video quality parameter within the at least two consecutive monitoring periods is less than the fourth threshold, it is determined that a network failure occurs between the second device and the user terminal.
[0253] exist Figure 6 In the scenario shown, the processor 21 receives the video quality parameters reported by each device through which the monitored video stream flows, and performs fault detection according to the video quality parameters reported by each device. Specifically, it is determined whether the fault occurs in the user terminal, the head-end device, or the network transmitting the video stream based on the video quality parameters reported by the ONT and SIG. Once it is determined that the fault occurs in the network, the fault can be detected in a specific network segment based on the video quality parameters reported by each two adjacent devices. For example, the processor 21 determines the probability of failure of each network segment, and determines the network segment with the highest probability of failure as the network segment causing the video service failure.
[0254] It should be noted that the so-called network segment is the network segment between the two devices through which the monitored video stream flows. In specific implementation, it is determined according to the ports where the probes of the two devices are deployed. For example, if the probes of the two devices are deployed on the outbound interface, then the network segment between the two devices is the network segment between the outbound interfaces of the two devices.
[0255] Fig. 9 A flowchart of a fault detection method provided by an embodiment of the present invention is shown in FIG. Fig. 9 As shown, the method may include the following steps:
[0256] 101. A monitoring device sends a video quality parameter request message to at least one network device through which a monitored video stream flows. The video quality parameter request message is used to indicate an identifier of the monitored video stream and a packet loss recovery method of the monitored video stream.
[0257] The at least one network device may include an ONT (i.e., the second device described in the embodiment of the present invention) that is closest to the user terminal and a SIG (i.e., the first device described in the embodiment of the present invention) that is closest to the headend device; it may also include BARS, ONT, OLT, CR, SIG, and other devices through which the monitored video stream flows. The packet loss recovery method of the monitored video stream can be considered as a packet loss recovery method set for the monitored video stream. When network packet loss occurs during the transmission of the monitored video stream, the packet loss recovery method of the monitoring video stream can be used to recover the network packet loss.
[0258] In some embodiments, if the monitored video stream is a live video stream, the identifier of the monitored video stream can be a channel number or a multicast address and port; if the monitored video stream is a video on demand stream, the identifier of the monitored video stream can be a quintuple, such as: source Internet Protocol (IP) address, source port, destination IP address, destination port and transport layer protocol.
[0259] In a specific implementation, the monitored video stream may be a video stream corresponding to a specific channel, or a video stream corresponding to a user terminal. If the monitored video stream may be a video stream corresponding to a specific channel, the information of the monitored video stream includes channel information, whether the channel has the FEC function turned on, the size of the FEC encoding matrix, the number of redundant data packets of a single source block, and whether the user terminal (such as STB) supports the FEC function; if the monitored video stream is a user terminal, the information of the monitored video stream includes whether the terminal has the RET function, the retransmission limit of RET (i.e., the above-mentioned δ), and other information as well as terminal-related decoding parameters (buffer capacity), etc.
[0260] 102. Each of the at least one network device determines a video quality parameter according to the packet loss recovery method of the monitored video stream. The video quality parameter includes an effective packet loss factor, which is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss.
[0261] First, each network device determines the identifier of the monitored video stream and the packet loss recovery method of the monitored video stream according to the received video quality parameter request message, and then determines the video quality parameters to be collected according to the packet loss recovery method of the monitored video stream. Specifically, if the packet loss recovery method of the monitored video stream is FEC, the video quality parameter is at least one of the packet loss rate determined by the network device through which the monitored video stream flows and the first effective packet loss factor (i.e., the effective packet loss factor described in step 102);
[0262] If the packet loss recovery method of the monitored video stream is RET, the video quality parameter is at least one of the packet loss rate and the maximum number of consecutive packet losses determined by the network device through which the monitored video stream flows;
[0263] If the monitored video stream is set with both RET and FEC, the video quality parameter is at least one of the packet loss rate, the maximum number of consecutive packet losses and the second effective packet loss factor (i.e., the effective packet loss factor described in step 102) determined by the network device through which the monitored video stream flows.
[0264] It should be noted that the packet loss rate satisfies the above formula (1), the first effective packet loss factor ELF_F satisfies the above formula (2), the second effective packet loss factor RTP_FR satisfies the above formula (3) or (4), and the third effective packet loss factor ELF_R satisfies the above formula (5). The specific calculation method is not described here.
[0265] 103. The monitoring device obtains a video quality parameter of the monitored video stream monitored by at least one network device through which the monitored video stream flows.
[0266] In some embodiments, the at least one network device may be a second device among the network devices through which the monitored video stream flows and which is closest to the user device, and a first device among the network devices through which the monitored video stream flows and which is closest to the head-end device, that is, Figure 5 In the deployment scenario shown, within a monitoring cycle, after the first device determines that the first video quality parameter monitored by itself exceeds the first threshold, the first video quality parameter is reported to the monitoring device. Specifically, if one of the multiple video quality parameters included in the first video quality parameter exceeds the corresponding threshold, the video quality parameter is reported, or the multiple video quality parameters included in the first video quality parameter are reported together.
[0267] For example, if the packet loss recovery method set for the monitored video stream device is FEC, the video quality parameters determined by the first device include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F, and if the packet loss rate RTP_LR exceeds its corresponding threshold, the ONT reports RTP_LR to the monitoring device, and may also report ELF_F. It should be noted that the threshold corresponding to the packet loss rate is different in the scenario where the packet loss recovery method is not set and the scenario where the packet loss recovery method is set. In some embodiments, the threshold corresponding to the packet loss rate in the scenario where the packet loss recovery method is not set is less than the threshold corresponding to the packet loss rate in the scenario where the packet loss recovery method is set.
[0268] Similarly, the video quality parameters determined by the second device include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F. If the packet loss rate RTP_LR exceeds its corresponding threshold, the ONT reports RTP_LR to the monitoring device and may also report ELF_F.
[0269] In some embodiments, the at least one network device may be N (N is an integer greater than or equal to 2) devices through which the monitored video stream flows. Figure 6 In the deployment scenario shown, N network devices determine the video quality parameters monitored by themselves, and report all the monitored video quality parameters to the monitoring device within a monitoring cycle. For example, if the packet loss recovery method set by the monitored video stream device is FEC, the video quality parameters determined by the N network devices include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F, and the N network devices will report the RTP_LR and ELF_F monitored by each of them to the monitoring device.
[0270] 104. The monitoring device performs fault detection according to the video quality parameter of the monitored video stream monitored by the at least one network device.
[0271] In the specific implementation, if Figure 5 In the deployment scenario shown, if the monitoring device receives the video quality parameters reported by the first device within a monitoring period, that is, at least one of the video quality parameters monitored by the first device exceeds the corresponding threshold value, it is determined that the head-end device fails;
[0272] Or, if the monitoring device receives the video quality parameter reported by the second device within the monitoring period, but does not receive the video quality parameter reported by the first device, it can be determined that a network failure occurs between the second device and the first device;
[0273] Or, if the monitoring device does not receive the video quality parameter reported by the first device and the video quality parameter reported by the second device within a monitoring period, it is determined that a fault occurs in the user terminal.
[0274] in the case of Figure 6 In the deployment scenario shown, the monitoring device receives the video quality parameters of the monitored video stream sent by each of the N network devices.
[0275] Similarly, the monitoring device can perform fault detection based on the parameters reported by each device. Specifically, if at least one of the video quality parameters reported by the first device exceeds the corresponding threshold, it is determined that the head-end device has a fault;
[0276] Or, if none of the video quality parameters reported by the first device exceeds the corresponding threshold, but at least one of the video quality parameters reported by the second device exceeds the corresponding threshold, it can be determined that a network failure occurs between the second device and the first device;
[0277] Or, if the monitoring device determines that the video quality parameter reported by the first device and the video quality parameter reported by the second device do not exceed corresponding threshold values, it is determined that a fault occurs in the user terminal.
[0278] exist Figure 6 In the scenario shown, further, if the monitoring device determines that a network failure occurs between the first device and the second device, the failure can be located in a certain network segment based on the video quality reported by each device.
[0279] Specifically, in an embodiment of the present invention, in the direction of the monitored video stream, there are M third devices between the first device and the second device, and the network between any two adjacent devices among the first device, the M third devices, and the second device is called a network segment. The first device, the M third devices, and the second device are the first device, the second device, ... the i-th device, the i+1-th device, ... the M+2-th device in the order from upstream to downstream. A network segment formed between any two adjacent devices among the M+2 devices, the first device, the M third devices, and the second device can determine M+1 network segments, and the M+1 network segments are the first network segment, the second network segment, ... the i-th network segment, the i+1-th network segment, ... the M+1-th network segment in the order from upstream to downstream, and the network segment between the i-th device and the i+1-th device is the i-th network segment. Wherein, i is an integer greater than or equal to 1 and less than or equal to M+1. First, the failure probability of each network segment is determined, and then the network segment with the largest failure probability among the M+1 network segments can be determined as the network segment where the failure occurs.
[0280] In some embodiments, the monitoring device may determine the failure probability of each network segment according to the following steps:
[0281] For the i-th network segment, the probability of the i-th network segment failing due to the Q-th parameter in the video quality parameter is calculated according to formula (6):
[0282]
[0283] in, is the Qth parameter reported by the i+1th device. is the Qth parameter reported by the i-th device, the λ Q is the threshold value corresponding to the Qth parameter, and the (i+1)th device is an upstream device adjacent to the i-th device.
[0284] Substitute all the parameters included in the video quality parameters into the above formula (6), calculate the failure probability of each parameter causing the i-th network failure, and determine the maximum failure probability as the failure probability p of the i-th network segment i .
[0285] By traversing each of the N-1 network segments, the failure probability of each network segment can be determined, and then the network segment with the highest probability of occurrence can be determined as the failure point. It can be considered that the failure of the video service is caused by the failure of the network segment.
[0286] In some embodiments, the monitoring device may also calculate the average probability of a certain network segment failing over several consecutive cycles. Specifically, taking the ith network segment as an example, the failure probability p of the ith network segment over T consecutive monitoring cycles is calculated. i ', T is an integer greater than or equal to 2; p i ' satisfies the following formula (7):
[0287]
[0288] Among them, β t is the time weight coefficient, satisfying β t =2 -t , t∈[1,.....T].
[0289] Furthermore, the monitoring device may update the failure probability of the i-th network segment to S,
[0290] The present invention also provides a fault detection method. Figure 5 In the deployment scenario shown in the figure, video fault detection modules and acquisition modules are deployed in SIG and ONT. Fig.10 As shown, the method may include the following steps:
[0291] 201. The monitoring device is responsible for sending a video quality parameter request message to a video fault detection module deployed on a SIG or an ONT.
[0292] It should be noted that the request is used to instruct the acquisition module deployed on the SIG or ONT to collect the video quality parameters of the monitored video stream (such as a specific channel or user terminal) to monitor the video quality of a specific channel or user terminal. The instruction is used to indicate the identifier of the monitored video stream and the packet loss recovery method of the monitored video stream.
[0293] 202. The video fault detection module receives a video quality parameter request message, and determines whether the monitored video stream has FEC or RET function enabled according to the message, and selects corresponding video quality parameters according to whether the FEC or RET function is enabled.
[0294] Specifically, referring to the video quality parameters in the above four scenarios, namely, the scenario where the packet loss recovery method is not set, the scenario where only FEC is set, the scenario where only RET is set, and the scenario where both FEC and RET are set, the specific calculation methods of each parameter are not repeated here.
[0295] 203. The acquisition module collects statistics of the selected video quality parameters according to the specified monitoring period.
[0296] 204. The acquisition module periodically reports the statistical video quality parameters to the video fault detection module. The video fault detection module compares the acquired video quality parameters with corresponding thresholds. If one of the multiple parameters exceeds the threshold, the fault is reported to the monitoring device.
[0297] Specifically, the parameters exceeding the threshold may be reported, or all monitored parameters may be reported together to the monitoring device.
[0298] 205. After a user video experience failure occurs, the monitoring device counts the failure probability within multiple continuous monitoring cycles and compares it with the corresponding threshold.
[0299] Specifically, the failure probability within multiple consecutive monitoring cycles is counted, that is, the probability of the computing device reporting a failure within multiple consecutive cycles. For example, if the SIG reports a failure in 3 cycles within 4 consecutive cycles, the failure probability of the SIG within the 4 consecutive cycles is 3 / 4, that is, 75%.
[0300] 206. If the SIG failure probability exceeds the threshold, it is considered that the video head-end content is incorrect and causes the video service failure; if the ONT failure probability exceeds the threshold, it is considered that the network transmission causes the video service failure; otherwise, it is considered that the video service failure is caused by a user terminal failure.
[0301] In the method provided by the embodiment of the present invention, the acquisition modules are respectively deployed in the most upstream device and the most downstream device through which the monitored video stream flows, and the two devices monitor different video quality parameters for different packet loss recovery methods (FEC, RET) used by the operator. These parameters are determined according to the packet loss recovery method used, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and accurately reflecting the impact of network transmission quality on video service quality. Furthermore, the monitoring device can accurately determine the impact of network transmission quality on video service quality according to the video quality parameters reported by the device, thereby improving the accuracy of video service fault detection. For example, in the scenario where the target monitoring device is only set with FEC, although the network condition is not good and the packet loss rate is high, the lost source data packet is recovered by using the packet loss recovery method. At this time, although the monitoring device reports the video quality parameters, that is, at least one parameter in the video quality parameters reported by the ONT exceeds the corresponding threshold value, such as: the packet loss rate is higher than the corresponding threshold value, but the first packet loss factor reported by the ONT is less than the corresponding threshold value, that is, the FEC is used to compensate for the adverse effects of network packet loss on the video service, so the monitoring device can believe that the video service failure is not caused by network transmission.
[0302] The present invention also provides a fault detection method. Figure 6 In the deployment scenario shown in the figure, the acquisition module is deployed on the ONT, OLT, BARS, CR, and SIG, and the video fault detection module is deployed on the monitoring device. Fig.11 As shown, the method may include the following steps:
[0303] 301. The monitoring device is responsible for sending a video quality parameter request message to the video fault detection module deployed on each network device where the acquisition module has been deployed.
[0304] It should be noted that the monitoring device sends the video quality parameter request message to ONT, OLT, BARS, CR, and SIG. The request is used to instruct the acquisition module deployed on the SIG or ONT to collect the video quality parameters of the monitored video stream (such as a specific channel or user terminal) to monitor the video quality of a specific channel or user terminal. The instruction is used for the identification of the monitored video stream and the packet loss recovery method of the monitored video stream.
[0305] 302. The video fault detection module receives a video quality parameter request message, and determines whether the monitored video stream has FEC or RET function enabled according to the message, and selects corresponding video quality parameters according to whether the FEC or RET function is enabled.
[0306] Specifically, referring to the video quality parameters in the above four scenarios, namely, the scenario where the packet loss recovery method is not set, the scenario where only FEC is set, the scenario where only RET is set, and the scenario where both FEC and RET are set, the specific calculation methods of each parameter are not repeated here.
[0307] 303. The acquisition module counts video quality parameters according to a specified monitoring period, and reports all the counted parameters to the monitoring device.
[0308] 304. After a user video experience failure occurs, the monitoring device arranges the devices in order from upstream to downstream, and compares the video quality parameters collected by the most downstream device with the corresponding threshold value.
[0309] In a specific implementation, the monitoring device uses a service path restoration method to sort the devices from upstream to downstream.
[0310] If the monitoring device determines that the video quality parameter reported by the most downstream device exceeds the threshold value (it may be that a certain parameter exceeds the threshold value, or it may be that multiple parameters exceed the threshold value), it is determined that the video service failure is caused by network transmission, and the subsequent delimitation step is performed, that is, step 306; otherwise, it is determined that the video service failure is not caused by network transmission, and step 305 is performed.
[0311] 305. If the monitoring device determines that the video quality parameter reported by the SIG exceeds the threshold, it is considered that the HE failure causes the video service failure; otherwise, it is considered that the video service failure is caused by the STB failure.
[0312] 306. The monitoring device calculates the failure probability of each network segment, and determines the network segment with the highest failure probability as the network segment causing the video service failure.
[0313] refer to Figure 6 The network devices through which the monitored video stream flows are ONT, OLT, BARS, CR, and SIG, and a total of four network segments are determined. Taking the first network segment (i.e., the network segment between CR and SIG) as an example, the fault probability calculation method provided by the embodiment of the present invention is introduced.
[0314] Assume that the only packet loss recovery method for the monitored video stream is FEC. In this scenario, the video quality parameters determined by CR and SIG include the packet loss rate RTP_LR and the first effective packet loss factor ELF_F.
[0315] For the first video quality parameter - packet loss rate, is the packet loss rate reported by SIG, is the packet loss rate reported by CR, is the packet loss rate reported by BARS, is the packet loss rate reported by the OLT, It is the packet loss rate reported by the ONT. The indicator difference is calculated based on the packet loss rates reported by two adjacent devices to obtain four indicator differences.
[0316] Calculate the sum W of the index differences, Furthermore, we calculate the probability P that the packet loss rate parameter will cause the first segment network failure. 1 Specifically, if W is less than or equal to the threshold λ of the packet loss rate in this scenario (i.e., the only packet loss recovery method is FEC), 1 , then P 1 =0; if W is greater than λ 1 ,but
[0317] For the second video quality parameter, the first effective packet loss factor, is the packet loss rate reported by SIG, is the packet loss rate reported by CR, is the packet loss rate reported by BARS, is the packet loss rate reported by the OLT, It is the packet loss rate reported by the ONT. The indicator difference is calculated based on the packet loss rates reported by two adjacent devices to obtain four indicator differences.
[0318] Calculate the sum of the index differences X, Furthermore, the probability P of the first effective packet loss factor causing the first segment network failure is calculated. 2 Specifically, if X is less than or equal to the threshold value λ of the first effective packet loss factor in this scenario (i.e., the packet loss recovery method is only FEC) 2 , then P 2 =0; if X is greater than λ 2 ,but
[0319] P 1 , P 2 The larger one is used as the probability of the first network segment failing.
[0320] Similarly, the probability of failure of the second network segment, the third network segment, and the fourth network segment is calculated, and the network segment with the highest probability of failure is determined as the network segment causing the video service failure.
[0321] Optionally, the monitoring device may also calculate the probability of each network segment causing a video service failure within a plurality of consecutive monitoring cycles, and update the failure probability of the network segment to the probability of the network segment causing a video service failure within a plurality of consecutive monitoring cycles.
[0322] In a specific implementation, the probability of a certain network segment causing a video service failure within multiple monitoring cycles is calculated according to the following formula.
[0323] Among them, β t is the time weighting coefficient. The farther the monitoring period is from the fault time point, the smaller the corresponding weighting coefficient is. t =2 -t , t∈[1,.....T]. T is T consecutive monitoring cycles.
[0324] Update the failure probability of the i-th network segment to S,
[0325] For example, taking the first network segment as an example, the failure probability of the first monitoring cycle in three consecutive monitoring cycles is P 1 , the failure probability in the second monitoring cycle is P 2 , the failure probability of the third monitoring cycle is P 3 , and the first monitoring cycle is closest to the fault time point, followed by the second monitoring cycle, and the third monitoring cycle is farthest from the fault time point. The sum of the failure probabilities of the first network segment in the three monitoring cycles is calculated as: p i ′=P 1 *1 / 2+P 2 *1 / 4+P 3 *1 / 8. Further, the failure probability of the first network segment calculated in step 306 is updated to:
[0326] (P 1 *1 / 2+P 2 *1 / 4+P 3 *1 / 8) / (p 1 ′+p 2 ′+p 3 ′+p 4 ′). Among them, p 2 ′ is the failure probability of the second network segment, p 3 ′ is the failure probability of the third network segment, p 4 ′ is the failure probability of the second network segment.
[0327] In the method provided by the embodiment of the present invention, a collection module is deployed on each network device that transmits a video stream, and each device monitors different video quality parameters for different packet loss recovery methods (FEC, RET) used by operators. These parameters are determined according to the packet loss recovery method used, taking into account the compensation of the packet loss recovery method for network transmission packet loss, and accurately reflecting the impact of network transmission quality on video service quality. Furthermore, the monitoring device can accurately determine the impact of network transmission quality on video service quality based on the video quality parameters reported by the device, thereby improving the accuracy of video service fault detection. For example, in a scenario where the target monitoring device is only set to FEC, if at least one parameter of the video quality parameters reported by the ONT exceeds the corresponding threshold value, such as: the packet loss rate is higher than the corresponding threshold value, but the first packet loss factor reported by the ONT is less than the corresponding threshold value, that is, the use of FEC compensates for the adverse effects of network packet loss on the video service, so the monitoring device can believe that the video service failure is not caused by network transmission.
[0328] The above mainly introduces the solution provided by the embodiment of the present invention from the perspective of the interaction between various network elements. It can be understood that the monitoring equipment and devices described in the embodiments of the present invention, in order to realize the above functions, include hardware structures and / or software modules corresponding to the execution of various functions. Those skilled in the art should easily realize that, in combination with the algorithm steps of each example described in the embodiments disclosed in this article, the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.
[0329] The embodiment of the present invention can divide the monitoring equipment and devices involved in the embodiment of the present invention into functional modules according to the above method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present invention is schematic and is only a logical function division. There may be other division methods in actual implementation.
[0330] In the case of dividing each functional module into corresponding functional modules, Fig.12 A possible schematic diagram of the composition of the monitoring device involved in the above-mentioned embodiments is shown. Fig.12 As shown, the monitoring device may include: a sending unit 401 , an acquiring unit 402 , and a detecting unit 403 .
[0331] The sending unit 401 is used to support the monitoring device to execute Fig. 9 Step 101 in the fault detection method shown, Fig.10 Step 201 of the fault detection method shown in FIG. Fig.11 Step 301 in the fault detection method shown.
[0332] Acquisition unit 402, used to support monitoring equipment to execute Fig. 9 Step 103 in the fault detection method shown, Fig.10 Step 204 in the fault detection method shown is also used to support the monitoring device to perform Fig.11 Step 303 in the fault detection method shown.
[0333] Detection unit 403, used to support monitoring equipment to perform Fig. 9 Step 104 in the fault detection method shown, Fig.10 Steps 205, 206 and Fig.11 Steps 304 to 306 in the fault detection method shown.
[0334] In the case of an integrated unit, Fig.13 FIG. 2 shows another possible schematic diagram of the composition of the monitoring device involved in the above embodiment. Fig.13 As shown, the monitoring device includes: a processing module 501 and a communication module 502 .
[0335] The processing module 501 is used to control and manage the actions of the monitoring device. For example, the processing module 501 is used to support the monitoring device to execute Fig. 9 Step 104 in the fault detection method shown, Fig.10 Steps 205, 206 and Fig.11 The communication module 502 is used to support the communication between the monitoring device and other network entities, such as Figure 5 The communication between the SIG and the ONT is shown in FIG. The monitoring device may further include a storage module 503 for storing program codes and data of the monitoring device.
[0336] The processing module 501 may be a processor or a controller. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of the present invention. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication module 502 may be a transceiver, a transceiver circuit or a communication interface, etc. The storage module 503 may be a memory.
[0337] When the processing module 501 is a processor, the communication module 502 is a communication interface, and the storage module 503 is a memory, the monitoring device involved in the embodiment of the present invention can be Figure 8 Monitoring equipment shown.
[0338] In the case of dividing each functional module into corresponding functional modules, Fig.14 A possible composition diagram of the network devices involved in the above embodiments is shown. Fig.14 As shown, the network device may include: a receiving unit 601, a determining unit 602, and a sending unit 603.
[0339] Receiving unit 601, used to support the device to execute Fig. 9 Step 101 in the fault detection method shown, Fig.10 Step 201 of the fault detection method shown in FIG. Fig.11 Step 301 in the fault detection method shown.
[0340] Determining unit 602, used to support the device to execute Fig. 9 Step 102 in the fault detection method shown, Fig.10 Steps 202, 203 and Fig.11 Step 302 in the fault detection method shown, and the step of "collecting statistics of video quality parameters according to a specified monitoring period" in step 302.
[0341] The sending unit 603 is used to support the device to execute Fig. 9 Step 103 in the fault detection method shown, Fig.10 Step 204 of the fault detection method shown in FIG. Fig.11 The step of "reporting all the statistical parameters to the monitoring device" in step 303 in the fault detection method shown.
[0342] In the case of an integrated unit, Fig.15 FIG. 2 shows another possible schematic diagram of the composition of the network device involved in the above embodiment. Fig.15 As shown, the network device includes: a processing module 701 and a communication module 702 .
[0343] The processing module 701 is used to control and manage the actions of the device. For example, the processing module 701 is used to support the device to execute Fig. 9 Step 102 in the fault detection method shown, Fig.10 Steps 202, 203 and Fig.11The communication module 702 is used to support the communication between the device and other network entities, such as the communication between the device and the network entity, and the communication between the device and the network entity ... Figure 5 The communication between the SIG and the ONT is shown in FIG. The network device may further include a storage module 703 for storing program codes and data of the device.
[0344] The processing module 701 may be a processor or a controller. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of the present invention. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.
[0345] The communication module 702 may be a transceiver, a transceiver circuit or a communication interface, etc. The storage module 703 may be a memory.
[0346] When the processing module 701 is a processor, the communication module 702 is a communication interface, and the storage module 703 is a memory, the network device involved in the embodiment of the present invention can be Figure 7 The network devices shown.
[0347] Since the terminal provided in the embodiment of the present application can be used to execute the above-mentioned fault detection method, the technical effects that can be obtained can refer to the above-mentioned method embodiment, and the embodiment of the present application will not be repeated here.
[0348] Through the description of the above implementation methods, technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.
[0349] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0350] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0351] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0352] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, or all or part of the technical solution. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: flash memory, mobile hard disk, read-only memory, random access memory, disk or optical disk, and other media that can store program codes.
[0353] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A fault detection method, characterized in that: include: Acquire a video quality parameter of a monitored video stream, wherein the video quality parameter is determined according to a packet loss recovery method of the monitored video stream, and the video quality parameter includes an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss; Fault detection is performed based on the video quality parameters of the monitored video stream.
2. The method according to claim 1, characterized in that The packet loss recovery method of the monitored video stream is forward error correction FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC to recover network packet loss; or, The packet loss recovery method of the monitored video stream is retransmission RET, and the effective packet loss factor is specifically used to indicate the effectiveness of using RET to recover network packet loss; or, The packet loss recovery methods of the monitored video stream are RET and FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC and RET to recover network packet loss.
3. The method according to claim 2, characterized in that The packet loss recovery method of the monitored video stream is FEC, and the effective packet loss factor is determined based on whether the number of packet losses in each monitoring window in multiple monitoring windows within a monitoring period is greater than R, where R is the maximum number of packet losses that can be recovered using FEC for L source data packets.
4. The method according to claim 2, characterized in that: The packet loss recovery method of the monitored video stream is RET, and the effective packet loss factor is determined according to whether the number of packet losses in each monitoring window of multiple monitoring windows within the monitoring period is greater than R, where R is the maximum number of packet losses that can be recovered using RET for L source data packets.
5. The method according to claim 2, characterized in that: The packet loss recovery method of the monitored video stream is FEC, and the video quality parameter also includes a packet loss rate.
6. The method according to claim 2, characterized in that The packet loss recovery method of the monitored video stream is RET, or RET and forward error correction FEC, and the video quality parameters also include: packet loss rate and maximum continuous packet loss number.
7. The method according to any one of claims 1 to 4, characterized in that: The fault detection includes detecting whether a fault exists and / or performing fault demarcation; the fault demarcation includes determining the device or network segment where the fault occurs when a video service fails.
8. The method according to any one of claims 1 to 4, characterized in that: The obtaining of the video quality parameter of the monitored video stream includes obtaining the video quality parameter from at least one network device through which the monitored video stream flows.
9. The method according to claim 8, characterized in that Before obtaining the video quality parameters of the monitored video stream, the method further includes: sending a video quality parameter request message to the at least one network device, wherein the video quality parameter request message is used to indicate the identifier of the monitored video stream and a packet loss recovery method of the monitored video stream.
10. The method according to claim 8, characterized in that The at least one network device comprises a first device, The performing fault detection according to the video quality parameter of the monitored video stream specifically includes: If the first video quality parameter reported by the first device is received within a monitoring cycle, it is determined that a fault occurs between the first device and the head-end device; the head-end device is a device that provides the monitored video stream; the first video quality parameter is reported to the monitoring device by the first device after the first device determines that at least one parameter of the first video quality parameters exceeds the corresponding threshold value.
11. The method according to claim 10, characterized in that The at least one network device further includes a second device, the second device being a downstream device of the first device, The performing fault detection according to the video quality parameter of the monitored video stream specifically includes: If the second video quality parameter reported by the second device is received within a monitoring period and the first video quality parameter is not received, it is determined that a fault occurs between the second device and the first device; the second video quality parameter is reported to the monitoring device by the second device after the second device determines that at least one parameter of the second video quality parameters exceeds a corresponding threshold value; If the second video quality parameter and the first video quality parameter are not received within a monitoring period, it is determined that a fault occurs between the second device and the user terminal; the user terminal is a device that receives the monitored video stream.
12. The method according to claim 8, characterized in that The at least one network device includes n network devices through which the monitored video stream flows, where n is an integer greater than or equal to 2; The acquiring the video quality parameter from the at least one network device specifically includes: Receive the video quality parameter of the monitored video stream sent by each of the n network devices.
13. The method according to claim 12, characterized in that The performing fault detection according to the video quality parameter of the monitored video stream specifically includes: If it is determined that at least one parameter of the first video quality parameters reported by the first device among the n network devices is greater than or equal to the corresponding threshold value, it is determined that a fault occurs upstream of the first device; and / or If it is determined that the first video quality parameters reported by the first device are all less than the corresponding threshold value, and at least one parameter of the second video quality parameters reported by the second device downstream of the first device among the n network devices is greater than or equal to the corresponding threshold value, it is determined that a network failure occurs between the first device and the second device.
14. The method according to claim 13, characterized in that If the monitoring device determines that a network failure occurs between the first device and the second device, the method further includes: Determine a failure probability of each of M+1 network segments; the network segment is the first device, M third devices, and a network between any two adjacent devices of the second device, the third device is a device between the first device and the second device; M is an integer less than n; The network segment with the highest probability of failure among the M+1 network segments is determined as the network segment where the failure occurs.
15. The method according to claim 14, characterized in that Determining the failure probability of each network segment in the M+1 network segments specifically includes: Calculate the probability of failure of the i-th network segment caused by the Q-th parameter in the video quality parameter The i is an integer greater than or equal to 1 and less than or equal to M+1, satisfy: in, is the Qth parameter reported by the i+1th device. is the Qth parameter reported by the i-th device, the λ Q is the threshold value corresponding to the Qth parameter, and the (i+1)th device is an upstream device adjacent to the i-th device; The failure probability of the parameter with the highest failure probability among all the parameters included in the video quality parameters is determined as the failure probability p of the i-th network segment. i .
16. The method according to claim 15, characterized in that The method further comprises: Calculate the failure probability p of the i-th network segment within T consecutive monitoring cycles i ', T is an integer greater than or equal to 2; p i 'satisfy: Among them, β t =2 -t , t∈[1,.....T]; Update the failure probability of the i-th network segment to S, 17. A fault detection method, characterized in that: include: Determining a video quality parameter of the monitored video stream according to the packet loss recovery method of the monitored video stream; the video quality parameter includes an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss; The video quality parameters of the monitored video stream are sent to a monitoring device; the video quality parameters are used for fault detection.
18. The method according to claim 17, characterized in that The packet loss recovery method of the monitored video stream is forward error correction FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC to recover network packet loss; or, The packet loss recovery method of the monitored video stream is retransmission RET, and the effective packet loss factor is specifically used to indicate the effectiveness of using RET to recover network packet loss; or, The packet loss recovery methods of the monitored video stream are RET and FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC and RET to recover network packet loss.
19. The method according to claim 18, characterized in that The packet loss recovery method of the monitored video stream is FEC, and the effective packet loss factor is determined based on whether the number of packet losses in each monitoring window in multiple monitoring windows within a monitoring period is greater than R, where R is the maximum number of packet losses that can be recovered using FEC for L source data packets.
20. The method according to claim 18, characterized in that The packet loss recovery method of the monitored video stream is RET, and the effective packet loss factor is determined according to whether the number of packet losses in each monitoring window of multiple monitoring windows within the monitoring period is greater than R, where R is the maximum number of packet losses that can be recovered using RET for L source data packets.
21. The method according to any one of claims 17 to 20, characterized in that: Before determining the video quality parameter of the monitored video stream according to the packet loss recovery method of the monitored video stream, the method further includes: A video quality parameter request message sent by the monitoring device is received; the video quality parameter request message is used to indicate an identifier of a monitored video stream and a packet loss recovery method of the monitored video stream.
22. The method according to any one of claims 17 to 20, characterized in that: The sending of the video quality parameter of the monitored video stream to the monitoring device specifically includes: When it is determined that at least one parameter of the video quality parameters of the monitored video stream is greater than or equal to the corresponding threshold value, the video quality parameter of the monitored video stream is sent to the monitoring device.
23. A monitoring device, characterized in that: include: An acquisition unit, used for acquiring video quality parameters of a monitored video stream; The video quality parameter is determined according to the packet loss recovery method of the monitored video stream, and the video quality parameter includes an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss; The detection unit is used to perform fault detection according to the video quality parameters of the monitored video stream.
24. The monitoring device according to claim 23, characterized in that The packet loss recovery method of the monitored video stream is forward error correction FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC to recover network packet loss; or, The packet loss recovery method of the monitored video stream is retransmission RET, and the effective packet loss factor is specifically used to indicate the effectiveness of using RET to recover network packet loss; or, The packet loss recovery methods of the monitored video stream are RET and FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC and RET to recover network packet loss.
25. The monitoring device according to claim 24, characterized in that The packet loss recovery method of the monitored video stream is FEC, and the effective packet loss factor is determined according to whether the number of packet losses in each of the multiple monitoring windows in the monitoring period is greater than R, where R is the maximum number of packet losses that can be recovered using FEC for L source data packets, and the length of the monitoring window is L; or The packet loss recovery method of the monitored video stream is RET, and the effective packet loss factor is determined based on whether the number of packet losses in each monitoring window among multiple monitoring windows within a monitoring period is greater than R, where R is the maximum number of packet losses that can be recovered using RET for L source data packets, and the length of the monitoring window is L.
26. The monitoring device according to any one of claims 23 to 25, characterized in that: Also includes a sending unit, The sending unit is used to send a video quality parameter request message to at least one network device through which the monitored video stream flows before the acquiring unit acquires the video quality parameter of the monitored video stream, wherein the video quality parameter request message is used to indicate an identifier of the monitored video stream and a packet loss recovery method of the monitored video stream; The acquisition unit is specifically configured to acquire the video quality parameter from the at least one network device.
27. The monitoring device according to claim 26, characterized in that The at least one network device comprises a first device, The detection unit is specifically used to determine that a fault occurs between the first device and the head-end device if the first video quality parameter reported by the first device is received within a monitoring cycle; the head-end device is a device that provides the monitored video stream; the first video quality parameter is reported to the monitoring device by the first device after the first device determines that at least one parameter of the first video quality parameters exceeds the corresponding threshold value.
28. The monitoring device according to claim 27, characterized in that The at least one network device further includes a second device, the second device being a downstream device of the first device, The detection unit is further configured to determine that a fault occurs between the second device and the first device if the second video quality parameter reported by the second device is received and the first video quality parameter is not received within a monitoring period; the second video quality parameter is reported to the monitoring device by the second device after the second device determines that at least one parameter of the second video quality parameter exceeds a corresponding threshold value; If the second video quality parameter and the first video quality parameter are not received within a monitoring period, it is determined that a fault occurs between the second device and the user terminal; the user terminal is a device that receives the monitored video stream.
29. The monitoring device according to claim 26, characterized in that The at least one network device includes N network devices through which the monitored video stream flows, where N is an integer greater than or equal to 2; Then, the acquisition unit is specifically used to receive the video quality parameter of the monitored video stream sent by each of the N network devices.
30. The monitoring device according to claim 29, characterized in that The detection unit is specifically used for: If it is determined that at least one parameter of the first video quality parameters reported by the first device among the N network devices is greater than or equal to the corresponding threshold value, it is determined that a fault occurs upstream of the first device; and / or If it is determined that the first video quality parameters reported by the first device are all less than the corresponding threshold value, and at least one parameter of the second video quality parameters reported by the second device downstream of the first device among the N network devices is greater than or equal to the corresponding threshold value, it is determined that a network failure occurs between the first device and the second device.
31. The monitoring device according to claim 30, characterized in that The detection unit is further configured to, if the monitoring device determines that a network between the first device and the second device fails, determine a failure probability of each of M+1 network segments; the network segment is the first device, M third devices, and a network between any two adjacent devices of the second device, the third device being a device between the first device and the second device; and M is an integer less than n; The network segment with the highest probability of failure among the M+1 network segments is determined as the network segment where the failure occurs.
32. A network device, characterized in that: include: A determination unit, configured to determine a video quality parameter of the monitored video stream according to the packet loss recovery method of the monitored video stream; the video quality parameter includes an effective packet loss factor, and the effective packet loss factor is used to indicate the effectiveness of using the packet loss recovery method of the monitored video stream to recover network packet loss; The sending unit is used to send the video quality parameters of the monitored video stream to the monitoring device; the video quality parameters are used for fault detection.
33. The network device according to claim 32, characterized in that: The packet loss recovery method of the monitored video stream is forward error correction FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC to recover network packet loss; or, The packet loss recovery method of the monitored video stream is retransmission RET, and the effective packet loss factor is specifically used to indicate the effectiveness of using RET to recover network packet loss; or, The packet loss recovery methods of the monitored video stream are RET and FEC, and the effective packet loss factor is specifically used to indicate the effectiveness of using FEC and RET to recover network packet loss.
34. The network device according to claim 32 or 33, characterized in that: Also includes a receiving unit, The receiving unit is used to receive a video quality parameter request message sent by the monitoring device before the determining unit determines the video quality parameters of the monitored video stream according to the packet loss recovery method of the monitored video stream; the video quality parameter request message is used to indicate the identifier of the monitored video stream and the packet loss recovery method of the monitored video stream.
35. The network device according to claim 32 or 33, characterized in that: The sending unit is specifically configured to send the video quality parameters of the monitored video stream to the monitoring device when it is determined that at least one parameter of the video quality parameters of the monitored video stream is greater than or equal to a corresponding threshold value.
Citation Information
Patent Citations
Fault detection method, monitoring equipment and network equipment
CN112702629A