Method and system for determining causes of poor internet television over-the-top (OTT) service
By analyzing data correlation between terminals and node devices and combining it with deep learning models to optimize the identification of causes of poor quality, the problem of incomplete client data analysis was solved, enabling accurate analysis and rapid resolution of causes of poor quality, thereby improving user experience and operational efficiency.
Patent Information
- Application Number
- CN202510012616.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-02
- Publication Date
- 2026-07-03
AI Technical Summary
Current technologies rely solely on data collected from the client side to analyze the reasons for poor quality of Internet TV OTT services, which is incomplete, leading to long fault location and resolution cycles and causing user complaints.
By acquiring first and second data from OTT services on terminal and node devices, responding to quality-poor records, determining the causes of quality-poor performance through data correlation, and optimizing the rules for analyzing the causes of quality-poor performance by combining deep learning models and feedback information.
It improves the accuracy of analyzing the causes of poor quality, shortens the fault location and resolution cycle, enhances the user experience, and enables accurate early warning of poor quality situations and emergency response by maintenance personnel.
Smart Images

Figure CN122340294A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communications, and more specifically, to a method and system for determining the causes of poor quality Internet TV (OTT) services. Background Technology
[0002] Over-the-Top (OTT) TV set-top boxes (hereinafter referred to as terminal devices) inevitably experience various quality issues during use, such as latency, underload, stuttering, screen flickering, and even device malfunctions, severely impacting the user's viewing experience. While related technologies analyze the causes of these quality issues based on data collected from the client side, OTT technology encompasses a complete system, including at least the client, server, and the link connecting them. Analyzing the causes of OTT service quality issues solely based on client-side data leads to incomplete analysis, prolonged fault location and resolution times, and ultimately, user complaints. Summary of the Invention
[0003] This invention provides a method and system for determining the causes of poor OTT service quality, which at least solves the problem in related technologies where the analysis of the causes of poor OTT service quality is based solely on data collected from the client side, resulting in incomplete analysis of the causes of poor quality, long fault location and resolution cycles when poor quality occurs, and user complaints.
[0004] According to an embodiment of the present invention, a method for determining the cause of poor quality of Internet TV OTT service is provided, comprising: acquiring first OTT service data sent by a terminal device and second OTT service data sent by a node device; in response to the occurrence of a poor quality record in the first data, determining the cause of poor OTT service quality based on the correlation between the first data and the second data.
[0005] According to another embodiment of the present invention, a system for determining the cause of poor quality of Internet TV OTT service is provided, including a terminal device, a node device, and a server. The terminal device is used to collect and send first OTT service data to the server. The node device is used to collect and send second OTT service data to the server. The server is used to determine the cause of poor OTT service quality based on the correlation between the first data and the second data in response to the occurrence of a poor quality record in the first data.
[0006] According to yet another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.
[0007] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.
[0008] According to yet another embodiment of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.
[0009] Through the above embodiments of the present invention, since first OTT service data and second OTT service data collected from the terminal device side and the node device side are obtained, in response to the occurrence of poor quality first data, the cause of poor OTT service quality is determined based on the correlation between the first data and the second data. Therefore, it can solve the problem that related technologies rely solely on data collected from the client side to analyze the cause of poor OTT service quality, resulting in incomplete analysis of the cause of quality quality, long fault location and resolution cycles when quality quality is poor, and user complaints. This achieves the effect of improving the accuracy of determining the cause of quality quality, shortening the fault location and resolution cycle, and improving the user experience. Attached Figure Description
[0010] Figure 1 This is a schematic diagram of the OTT system architecture;
[0011] Figure 2 This is a flowchart (I) of a method for determining the causes of poor quality of Internet TV OTT service according to an embodiment of the present invention;
[0012] Figure 3 This is a flowchart (II) of a method for determining the causes of poor quality of Internet TV OTT services according to an embodiment of the present invention;
[0013] Figure 4 This is a structural block diagram of a system for determining the causes of poor quality Internet TV OTT services according to an embodiment of the present invention;
[0014] Figure 5 This is a schematic diagram of a system for determining the causes of poor quality Internet TV OTT service according to an embodiment of the present invention;
[0015] Figure 6 This is a schematic diagram illustrating the working principle of the intelligent module according to an embodiment of the present invention. Detailed Implementation
[0016] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples.
[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0018] OTT systems are streaming media service systems that provide users with television programs, movies, videos, and other media content via the Internet, without relying on traditional cable or satellite television networks. Figure 1 This is a schematic diagram of the OTT system architecture, such as... Figure 1 As shown, an OTT system may include: terminal devices, node devices, and users.
[0019] Terminal devices are the front-end consumer devices for OTT services, commonly including smart TVs and OTT boxes. The box terminal is responsible for receiving user requests (such as video-on-demand, live streaming switching, etc.), interacting with node devices, and ultimately presenting video content to the user.
[0020] Node devices are servers that cache media content.
[0021] This application embodiment can run on the aforementioned OTT architecture. This embodiment provides a method for determining the causes of poor quality Internet TV OTT services running on the aforementioned OTT architecture server. Figure 2 This is a flowchart (I) of a method for determining the causes of poor quality Internet TV OTT service according to an embodiment of the present invention, as shown below. Figure 2 As shown, the process includes the following steps:
[0022] Step S202: Obtain the first OTT service data sent by the terminal device and the second OTT service data sent by the node device.
[0023] For example, the first data for the OTT service is collected by the terminal device through one of the methods of file and streaming, and the second data for the OTT service is collected by the node device through one of the methods of file and streaming.
[0024] In one exemplary embodiment, the first data includes soft probe data; the soft probe data includes at least one of the following: resource operation data, user viewing data; the user viewing data includes at least one of the following: reporting time, terminal device identifier, request content, and quality information.
[0025] For example, the soft probe data may also include at least one of the following: resource operation data, user viewing data, and operation logs. Resource operation data may include at least one of the following: terminal manufacturer, model, network quality, network packet loss rate, CPU and memory information, etc. User viewing data may also include at least one of the following: reporting time, terminal device identifier, requested content, quality information, resource request information, and resource URLs of viewed videos and programs, etc. Operation logs may include some user operations, such as switching from channel A to channel B, or increasing the volume of channel C, etc.
[0026] For example, the reporting time is used to record the time of each viewing data item. The terminal device identifier is a unique identifier for the terminal device. Resource request information can include information such as the download time of the m3u8 index file and TS segments, and the response time. Poor quality information can include information such as the duration and frequency of stuttering, screen tearing, and underloading.
[0027] In one exemplary embodiment, the second data includes at least one of the following: user request logs and hardware resource data; the user request logs include at least one of the following: request time, terminal device identifier, request content, session identifier, request status code, origin status code, and resource download information; the hardware resource data includes at least one of the following: hardware configuration information, CPU usage, memory usage, and network usage.
[0028] For example, user request logs may also include at least one of the following: request time, terminal device identifier, request content, session identifier, request status code, origin server status code, resource download information, node device identifier, user request information field, hardware region information, etc. Hardware resource data may also include at least one of the following: hardware configuration information, CPU usage, memory usage, network usage, disk usage, etc.
[0029] For example, hardware region information may include region address information, node address information, node device address information, and terminal device address information. Network usage information may include network packet loss rate, retransmission, latency, and other information.
[0030] Step S204: In response to the occurrence of a poor quality record in the first data, the cause of the poor OTT service quality is determined based on the correlation between the first data and the second data.
[0031] For example, when there are quality-poor records in the first data such as stuttering or screen tearing with a frequency greater than 0, the reason for the poor quality of OTT service can be determined based on the correlation between the first data and the second data.
[0032] In one exemplary embodiment, step S204 includes: acquiring soft probe data containing poor quality records in the first data, and acquiring user request logs and / or hardware resource data associated with the soft probe data containing poor quality records in the second data.
[0033] For example, the soft probe data that shows poor quality records in the first data can be obtained by filtering out the soft probe data that shows poor quality records on the terminal device based on the poor quality information (e.g., the number of times there is a stutter or screen flickering is greater than 0).
[0034] For example, the soft probe data in the first data includes resource operation data and / or user viewing data. For instance, resource operation data includes network packet loss rate, and user viewing data includes reporting time, terminal device identifier, request content, and poor quality information.
[0035] The second data includes user request logs and / or hardware resource data. For example, user request logs include request time, terminal device identifier, request content, session identifier, etc., while hardware resource data includes hardware configuration information, etc.
[0036] The first and second data are related, including time information (reporting time and request time), terminal device identifier, and request content. The reporting time is the time when the terminal device reports a quality issue, and the request time is the time when the terminal device requests resources from the node device. For example, if the terminal device starts requesting resources from the node device at 10:00:00, and the quality issue occurs at 10:10:01, the terminal device will record the reporting time as 10:10:01, and the node device will record the corresponding request time range as 10:00:00-10:10:01. It should be noted that in some cases, the reporting time can be the same as or approximately the request time.
[0037] For example, by associating the first data with the second data, such as filtering out the first data containing poor quality records from the first data, and searching for the second data containing the corresponding request time, terminal device identifier, and request content information in the second data based on the reporting time, terminal device identifier, and request content information in the filtered first data, and then filtering out these second data, the association of the first data with the second data is achieved.
[0038] In one exemplary embodiment, step S204 further includes: determining the cause of poor OTT service quality based on at least one of the following: soft probe data, user request logs, and hardware resource data.
[0039] For example, the cause of poor OTT service quality can be determined based on soft probe data (such as resource operation data, which may include information like network packet loss rate). The cause of poor OTT service quality can also be determined based on user request logs (such as request status codes). Finally, the cause of poor OTT service quality can be determined based on hardware resource data (such as memory usage).
[0040] The reasons for poor OTT service quality can also be determined based on soft probe data (such as resource operation data, which may include network packet loss rate, etc.) and user request logs (such as request status codes, etc.). Similarly, the reasons for poor OTT service quality can be determined based on user request logs (such as request status codes, etc.) and hardware resource data (such as memory usage, etc.).
[0041] The reasons for poor OTT service quality can also be determined based on soft probe data (such as resource operation data in soft probe data, which may include information such as network packet loss rate), user request logs (such as request status codes in user request logs), and hardware resource data (such as memory usage information in hardware resource data).
[0042] In one exemplary embodiment, obtaining soft probe data showing a poor quality record includes: obtaining user viewing data and / or resource operation data associated with the poor quality information based on the poor quality information in the soft probe data.
[0043] For example, the soft probe data in the first data includes resource operation data and / or user viewing data. For instance, the resource operation data is the network packet loss rate, and the user viewing data is the reporting time, terminal device identifier, request content, and quality information. Then, based on the quality information (for example, quality information includes quality records such as the number of times the screen flickering or screen distortion occurred is greater than 0), the data with the number of times the screen flickering occurred is filtered out from the first data. For example, the filtered data is the reporting time 08:00, terminal device identifier A2, request content xxxx, quality information screen flickering once, and the network packet loss rate of 5% at the corresponding time.
[0044] In one exemplary embodiment, obtaining user request logs and / or hardware resource data associated with the soft probe data in which a poor quality record occurs includes: obtaining user request logs and / or hardware resource data associated with the user viewing data based on the user viewing data in the soft probe data in which the poor quality record occurs.
[0045] For example, the user viewing data in the soft probe data that shows poor quality records can include the reporting time, terminal device identifier, request content, and poor quality information. This user viewing data can then be correlated with user request logs and / or hardware resource data, such as the associated user request log containing information like session identifiers. Based on the associated session identifier, other user request logs and / or hardware resource data corresponding to that session identifier can be further obtained.
[0046] In one exemplary embodiment, the request time of the user request log and / or hardware resource data associated with the user viewing data is earlier than the reporting time in the user viewing data.
[0047] For example, if the reporting time in the user viewing data is 08:00, then the request time of the associated user request log and / or hardware resource data is earlier than the reporting time of 08:00. For example, the user request log in the second data includes session identifier, request time, terminal device identifier, request content, etc.
[0048] For example, the second data includes: (1) Session ID 0x00, request time 07:59. (2) Session ID 0x07, request time 07:49. (3) Session ID 0x19, request time 08:01. It should be noted that (1)-(3) all include terminal device ID A2 and request content xxXX.
[0049] Since the request time 07:59 is earlier than the reporting time 08:00, and the time interval between the request time 07:59 and 08:00 is the shortest, therefore (1) the session identifier 0x00 and the request time 07:59 are the associated session identifiers, that is, the session identifiers corresponding to when the quality difference occurs.
[0050] Based on the session identifier 0x00, all user request logs and / or hardware resource data with session identifier 0x00 and request time range of 07:50-07:59 can be further obtained. For example, user request logs include request status code 404, and hardware resource data includes memory usage of 70%.
[0051] In an exemplary embodiment, determining the cause of poor OTT service quality based on soft probe data includes: in response to the failure to obtain user request logs associated with the soft probe data in which the poor quality record occurred, determining the cause of poor OTT service quality as a first poor quality cause based on a first comparison result of a first statistical value and a first comparison value of resource operation data in the soft probe data.
[0052] In one exemplary embodiment, determining the reasons for poor OTT service quality based on user request logs includes:
[0053] In response to the acquisition of user request logs associated with soft probe data showing poor quality records, the cause of the poor OTT service quality is determined as the second cause of poor quality based on the second comparison result of the second statistical value and the second comparison value of the user request logs.
[0054] In one exemplary embodiment, determining the reasons for poor OTT service quality based on hardware resource data includes:
[0055] In response to the user request log associated with the soft probe data that shows a poor quality record, the cause of the poor OTT service quality is determined as the third cause of the poor quality based on the third comparison result of the third statistical value and the third comparison value of the hardware resource data.
[0056] For example, determining the cause of poor OTT service quality can be achieved by establishing rules for determining the cause of poor OTT service quality. These rules can include four parts: statistical objects, statistical values, conditional values (also known as comparison values), and the cause of the poor quality. The statistical objects can be collected first data and second data. For example, the first data includes network packet loss rate, CPU and memory usage of terminal devices, while the second data includes request status codes, first packet response time, number of repeated downloads, average download speed, request traffic, network download speed, and CPU and memory usage of node devices. The statistical values can be specific values of the first and second data. For example, the resource operation data in the first data could be a network packet loss rate of 10%, the user request log in the second data could be a request status code of 404, and the hardware resource data in the second data could be a CPU usage rate of 80%. The comparison value can be a predetermined threshold. For example, if the comparison value for the network packet loss rate is 5%, then when the statistical value of the network packet loss rate is greater than the comparison value of 5%, the cause of the poor quality can be determined to be a specific reason.
[0057] In an exemplary embodiment, in response to the failure to obtain a session identifier associated with the soft probe data that recorded poor quality in the second data, the first comparison result can be determined based on the first statistical value of network packet loss rate (10%) and the first comparison value of network packet loss rate (5%). If the first comparison result is greater than the first comparison value, the first reason for poor quality is determined to be: the node device did not receive the request, and it is recommended to check whether the terminal-side network is abnormal.
[0058] In an exemplary embodiment, in response to obtaining a session identifier associated with the soft probe data in the second data that shows a poor quality record, the second comparison result is determined to be that the second statistical value is greater than the second comparison value, based on the second statistical value of 3 times the number of requests with status codes 404 corresponding to the session identifier and the second comparison value of 0 times the number of requests with status codes 404. The second reason for poor quality is determined to be: the fragmented resource does not exist.
[0059] In an exemplary embodiment, the second statistical value of the number of requests with status codes 4xx (not 404) and 5xx corresponding to the session identifier is 2, and the second comparison value of the number of requests with status codes 4xx (not 404) and 5xx is 0. If the second comparison result is that the second statistical value is greater than the second comparison value, then the second poor quality reason is determined to be: a download error has occurred.
[0060] In an exemplary embodiment, the second statistical value of the average download rate of the requested fragment corresponding to the session identifier is 100KB / s, and the second comparison value of the average download rate is 1MB / s. If the second comparison result is determined to be that the second statistical value is less than the second comparison value, then it is determined to be the second reason for poor quality: fragment download timeout.
[0061] In an exemplary embodiment, in response to obtaining a session identifier associated with the soft probe data in the second data that shows a poor quality record, the third comparison result is determined to be greater than the third comparison value based on the third statistical value of the hardware resource data (CPU utilization rate of 80%) and the third comparison value of the CPU (70%). If the result is determined to be the third poor quality reason: the node hardware resource utilization rate is too high.
[0062] It should be noted that other reasons for poor quality include corrupted system files, untimely node index updates, uncached shards, failed node origin pulls, and repeated shard requests, which will not be elaborated upon here. Other reasons for poor quality can also be determined according to different OTT service quality determination rules, and this application does not impose any restrictions on this.
[0063] In one exemplary embodiment, the method further includes: displaying, through a display interface, the situation and reasons for poor OTT service quality at the regional, node, and device levels, based on the first data and / or the second data.
[0064] For example, based on first data and / or second data, the service status of OTT services in multiple regions can be displayed through a first display interface, wherein the service status of different OTT services is indicated by different colors; a region click instruction is received, and the user jumps to a second display interface according to the region click instruction, and the quality of OTT services of terminal devices or node devices in the corresponding region is displayed through the second display interface; a terminal device or node device click instruction is received, and the user jumps to a third display interface according to the terminal device or node device click instruction, and the reason for the quality of OTT services of the corresponding terminal device or node device is displayed through the third display interface.
[0065] For example, different colors can be used to identify the quality of OTT services at different provincial, municipal, regional, and node levels. Green represents good service, yellow represents average service, and red represents poor service. At the same time, the topology rendering map can automatically jump to specific terminal and node devices, channels, content, etc. after receiving a click command, providing drill-down capabilities.
[0066] In one exemplary embodiment, the method further includes: predicting the trend of the second data and obtaining the predicted value of the second data; and triggering a quality-poor warning based on the reason for the poor quality of the OTT service in response to the predicted value meeting a preset alarm threshold.
[0067] For example, predictions can be made based on various business and operational metrics data, such as trends in average download speed, request latency, 4xx and 5xx response times, and device load changes. When the predicted trend value meets a preset alarm threshold, a quality improvement warning is triggered based on the cause of the poor OTT service quality. This can buy more emergency response time for operations and maintenance personnel and reduce the occurrence of actual quality improvement situations.
[0068] For example, if the predicted average download speed is less than or equal to a preset alarm threshold, a second quality-poor warning can be triggered for chunk download timeout; if the number of 4xx and 5xx responses is greater than or equal to a preset alarm threshold, a second quality-poor warning can be triggered for download errors.
[0069] In one exemplary embodiment, it further includes: adjusting the reasons for poor OTT service quality based on a deep learning model or received feedback information.
[0070] For example, a deep learning model can learn autonomously from a large number of poor quality cases to extract corresponding representational data (statistical objects and statistical values) and reasons for poor quality. For instance, the deep learning model can query the corresponding rules for determining the reasons for poor quality based on the reasons for poor quality. If no corresponding rules are found, they are supplemented; if they are found, a similarity comparison analysis is performed on the rules for determining the reasons for poor quality. If the similarity is high, no adjustments are made to the rules for determining the reasons for poor quality; if the similarity is low, at least one of the statistical objects, comparison values, and reasons for poor quality in the rules for determining the reasons for poor quality is adjusted.
[0071] For example, based on the received feedback information, at least one of the statistical objects, comparison values, and causes of poor quality in the rules for determining the cause of poor quality can also be adjusted. For example, if the received feedback information includes adjusting the comparison value of the network packet loss rate from 5% to 3%, then the comparison value of the network packet loss rate can be adjusted accordingly based on the feedback information.
[0072] In one exemplary embodiment, the reasons for adjusting poor OTT service quality based on a deep learning model include one of the following:
[0073] The causes of poor OTT service quality are determined based on a deep learning model; the causes of poor OTT service quality determined by the deep learning model are designated as the first cause of poor quality; the similarity between the statistical objects, statistical values, and comparison values used by the deep learning model and the soft probe data, the first statistical value, and the first comparison value are compared; at least one of the soft probe data, the first comparison value, and the first cause of poor quality is adjusted based on the similarity.
[0074] The causes of poor OTT service quality are determined based on a deep learning model; the causes of poor OTT service quality determined by the deep learning model are designated as the second cause of poor quality; the similarity between the statistical objects, statistical values, and comparison values used by the deep learning model and the user request logs, the second statistical value, and the second comparison value are compared; at least one of the user request logs, the second comparison value, and the second cause of poor quality is adjusted based on the similarity.
[0075] The causes of poor OTT service quality are determined based on a deep learning model; the causes of poor OTT service quality determined by the deep learning model are designated as the third cause of poor quality; the similarity between the statistical objects, statistical values, and comparison values used by the deep learning model and the hardware resource data, the third statistical value, and the third comparison value are compared; at least one of the hardware resource data, the third comparison value, and the third cause of poor quality is adjusted based on the similarity.
[0076] For example, if a deep learning model determines that the reason for poor OTT service quality is the second reason for poor quality, namely, the timeout of segment download, and extracts relevant representation data such as the second comparison value of 2MB / s, which has a low similarity to the second comparison value of 1MB / s of the average download rate of requested segments in the rule for determining the reason for poor quality, then the second comparison value of the average download rate in the rule for determining the reason for poor quality can be adjusted from 1MB / s to 2MB / s.
[0077] In one exemplary embodiment, the reasons for adjusting poor OTT service quality based on received feedback information include one of the following:
[0078] Based on the received feedback information, adjust at least one of the soft probe data, the first comparison value, and the first quality defect cause; based on the received feedback information, adjust at least one of the user request log, the second comparison value, and the second quality defect cause; based on the received feedback information, adjust at least one of the hardware resource data, the third comparison value, and the third quality defect cause.
[0079] For example, if the received feedback information includes adjusting the second comparison value of the average download rate of the requested segment from 1MB / s to 2MB / s, then the second comparison value of the average download rate of the requested segment can be adjusted according to the feedback information.
[0080] Through the above steps S202-S204, the problem of incomplete analysis of the causes of poor OTT service quality due to relying solely on data collected from the client side in related technologies can be solved. This leads to long fault location and resolution cycles when poor quality occurs, resulting in user complaints. The solution achieves accurate analysis of the causes of poor quality, shortens the fault location and resolution cycle, and continuously improves the accuracy of poor quality analysis by adjusting and optimizing the rules for analyzing the causes of poor quality through deep learning models. It can also achieve accurate early warning of poor quality situations and increase the emergency response time of operation and maintenance personnel.
[0081] Figure 3 This is a flowchart (II) of a method for determining the causes of poor quality Internet TV OTT service according to an embodiment of the present invention, as shown below. Figure 3 As shown, the process includes the following steps:
[0082] Step S301: Obtain the first OTT service data sent by the terminal device and the second OTT service data sent by the node device.
[0083] The first data includes soft probe data; the soft probe data includes at least one of the following: resource operation data, user viewing data; the user viewing data includes at least one of the following: reporting time, terminal device identifier, request content, and quality information; the resource operation data may include at least one of the following: terminal manufacturer, model, network quality, network packet loss rate, CPU and memory information, etc.
[0084] The second data includes at least one of the following: user request logs, hardware resource data;
[0085] User request logs include at least one of the following: request time, terminal device identifier, request content, session identifier, request status code, origin status code, and resource download information;
[0086] Hardware resource data includes at least one of the following: hardware configuration information, CPU usage, memory usage, and network usage.
[0087] Step S302: Obtain the soft probe data containing poor quality records from the first data.
[0088] For example, soft probe data that shows poor quality records on terminal devices can be filtered out based on poor quality information (such as the number of times stuttering or screen flickering occurs being greater than 0).
[0089] Step S303: Obtain user request logs and / or hardware resource data associated with the soft probe data that contains the poor quality record from the second data.
[0090] For example, in step S302, the data filtered out by the first data is the reporting time 08:00, the terminal device identifier A2, the request content xxxx, the poor quality information is 1 instance of screen flickering, and the network packet loss rate of 5% at the corresponding time. Since the second data includes the request time, the terminal device identifier, and the request content, the second data can be derived based on the first data.
[0091] For example, based on the reporting time 08:00, terminal device identifier A2, and request content xxxx, session identifier 0x00 can be associated with the second data. The request time corresponding to this session identifier is 07:59, which is earlier than the reporting time 08:00. Based on this session identifier 0x00, all user request logs and / or hardware resource data with session identifier 0x00 and request times ranging from 07:50 to 07:59 can be further obtained. For example, user request logs may include request status code 404, and hardware resource data may include memory usage of 70%.
[0092] Step S304: In response to the occurrence of a poor quality record in the first data, the cause of the poor quality of the OTT service is determined based on the correlation between the first data and the second data.
[0093] For example, the data associated with the second data also includes a second statistical value of 100KB / s for the average download speed of the requested chunks. Since this statistical value is less than the second comparison value of 1MB / s for the average download speed, the reason for the poor quality of OTT service can be determined to be the second reason for poor quality, namely, chunk download timeout.
[0094] Step S305: Adjust the reasons for poor OTT service quality, display the situation and reasons for poor OTT service quality, and trigger a quality poor warning.
[0095] For example, the reasons for poor OTT service quality can be adjusted based on deep learning models or received feedback. If the deep learning model determines that the reason for poor OTT service quality is the second reason, namely, chunk download timeout, and extracts relevant representational data, such as the second comparison value of 2MB / s, which has a low similarity to the second comparison value of 1MB / s for the average download rate in the rule for determining the reason for poor quality, then the second comparison value for the request chunk download duration in the rule for determining the reason for poor quality can be adjusted from 1MB / s to 2MB / s.
[0096] For example, based on the second data, the interface displays the status and reasons for poor OTT service quality at the regional, node, and device levels. If a click command is received from a terminal device, the device-level reasons for poor OTT service quality can be displayed. For instance, the reason for poor OTT service quality for terminal device A2 is the second reason for poor quality, namely, fragment download timeout.
[0097] For example, predict the trend of the second data and obtain the predicted value of the second data. In response to the predicted value meeting the preset alarm threshold, trigger a quality deterioration warning based on the cause of poor OTT service quality. If the predicted average download rate of the requested chunk is 0.5MB / s, which is less than the preset alarm threshold of 0.8MB / s, a quality deterioration warning can be triggered if the cause of poor OTT service quality is the second quality deterioration cause, i.e., a chunk download timeout quality deterioration warning.
[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.
[0099] This embodiment also provides a system for determining the causes of poor quality OTT (Over-the-Top) Internet TV services. This system is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0100] Figure 4 This is a structural block diagram of a system for determining the causes of poor quality Internet TV OTT services according to an embodiment of the present invention, such as... Figure 4 As shown, the system 40 includes terminal devices, node devices, and servers.
[0101] Terminal device 42 is used to collect and send the first data of OTT service to the server;
[0102] Node device 44 is used to collect and send OTT service second data to the server;
[0103] Server 46 is used to respond to the presence of a poor quality record in the first data and determine the reason for the poor quality of the OTT service based on the correlation between the first data and the second data.
[0104] Figure 5 This is a schematic diagram of a system for determining the causes of poor quality Internet TV OTT services according to an embodiment of the present invention, such as... Figure 5 As shown, it includes terminal devices, node devices, and servers. The server includes a storage module, a statistics module, a monitoring module, a determination module, and an intelligence module. It should be noted that the module division in this embodiment is different from that in the previous embodiments. The functions of some modules in this embodiment may correspond to the functions of modules in the previous embodiments, or be part of the functions of modules in the previous embodiments, or be a combination of the functions of multiple modules in the previous embodiments.
[0105] The terminal device can be connected to the large screen where the user watches the video, and can realize various functions such as video-on-demand and live streaming through Internet transmission.
[0106] The node devices are distributed across various provinces and cities, and can cache audio and video resources and receive and respond to requests from terminal devices.
[0107] Both terminal devices and node devices include a data acquisition unit, which can send the acquired data to the server. The acquisition unit of the terminal device is responsible for acquiring the first data, which includes soft probe data; the soft probe data includes at least one of the following: resource operation data and user viewing data; the user viewing data includes at least one of the following: reporting time, terminal device identifier, request content, and quality information.
[0108] The acquisition unit of the node device is responsible for collecting the second data, which includes at least one of the following: user request logs and hardware resource data; the user request logs include at least one of the following: request time, terminal device identifier, request content, session identifier, request status code, origin status code, and resource download information; the hardware resource data includes at least one of the following: hardware configuration information, CPU usage, memory usage, and network usage.
[0109] The server can process, analyze, query, and display the first and second data, and its deployment method is not limited to physical or cloud-based methods. After receiving data collected by terminal and node devices, the server performs data entry and storage processing. The technologies used are not limited to one or more of the following: ETL processing (extraction, transformation, and loading), Kafka publish / subscribe message queue technology, API interfaces, and distributed storage technology.
[0110] The storage module stores the collected data and interacts with other modules in the system, such as statistics, monitoring, decision-making, and intelligent modules. The storage module can use one or more database technologies, including HBase, Cassandra, DorisDB, and Elasticsearch.
[0111] The statistics module can generate statistical values for the first and second data points.
[0112] The monitoring module can find the second data related to the first data based on the relationship between the first data and the second data. It can also display the situation and reasons for poor OTT service quality in a multi-dimensional way through the display interface.
[0113] The determination module can identify the cause of poor OTT service quality based on the correlation between the first and second data records that show poor quality.
[0114] For example, after the storage module processes and stores the data collected by the acquisition unit, the statistics module needs to perform statistics on the stored first and second data. The statistical dimensions can include time, province / city / region, node, node device, terminal device, channel, and content. Statistical fields can include total service requests, percentage of successful requests, 4xx percentage (indicating client-side errors such as incorrect or incomplete requests), 5xx percentage (indicating server-side errors, i.e., the server failed to process the request), first packet latency, timeout percentage, and average download speed. The monitoring module's display interface can find the second data associated with the first data within the second data, and perform topological rendering of the OTT service quality issues and their causes for each province / city / region / node. It can also generate a top-N overview of quality issues at the region, node, device, channel, and content levels, providing a multi-dimensional and intuitive display of the OTT service quality issues and their causes.
[0115] Intelligent module, Figure 6 This is a schematic diagram illustrating the working principle of the intelligent module according to an embodiment of the present invention, such as... Figure 6 As shown, the intelligent module can adjust the reasons for poor OTT service quality based on deep learning models or received feedback information. It possesses deep learning, iterative training, and big data analysis capabilities, allowing for continuous adjustment and optimization of the rules for determining the causes of poor OTT service quality, thus improving the accuracy of quality analysis. It can also predict the trend of secondary data and obtain predicted values. In response to the predicted values meeting preset alarm thresholds, it triggers a quality issue warning based on the cause of the poor OTT service quality, thereby identifying problems early and reducing the occurrence of actual quality issues.
[0116] The aforementioned system for determining the causes of poor OTT (Over-the-Top) service quality collects, stores, statistically analyzes, and processes massive amounts of data, including soft probe data from terminal devices, user request logs from node devices, and / or hardware resource data. This enables comprehensive analysis and determination of the causes of quality issues, shortening the fault location and resolution cycle. Furthermore, the system integrates intelligent technology, using deep learning models or received feedback information for autonomous learning and real-time monitoring. This allows for adjustments and optimization of the rules for determining the causes of quality issues, continuously improving the accuracy of analysis and determination, increasing the efficiency of OTT service providers in operation and maintenance, and enhancing user service experience and satisfaction. The system can also trigger quality issue warnings, increasing the emergency response time for maintenance personnel, thereby reducing the frequency and occurrence of quality issues.
[0117] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.
[0118] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.
[0119] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0120] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.
[0121] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.
[0122] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.
[0123] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.
[0124] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for determining the causes of poor quality Internet TV OTT service, characterized in that, include: Obtain the first OTT service data sent by the terminal device and the second OTT service data sent by the node device; In response to the presence of a poor quality record in the first data, the reason for the poor quality of the OTT service is determined based on the correlation between the first data and the second data.
2. The method according to claim 1, characterized in that, The reasons for the poor quality of the OTT service are determined based on the correlation between the first data and the second data, including: From the first data, obtain the soft probe data that shows poor quality records; In the second data, user request logs and / or hardware resource data associated with the soft probe data that showed poor quality records are obtained.
3. The method according to claim 2, characterized in that, Determining the cause of the poor OTT service quality based on the correlation between the first data and the second data also includes: The cause of the poor quality of the OTT service is determined based on at least one of the following: The soft probe data; The user request log; The hardware resource data.
4. The method according to claim 2, characterized in that, Soft probe data that yields poor-quality records includes: Based on the quality difference information in the soft probe data, obtain the user viewing data and / or resource operation data associated with the quality difference information.
5. The method according to claim 2, characterized in that, Acquiring user request logs and / or hardware resource data associated with the soft probe data that shows poor quality records includes: Based on the user viewing data in the soft probe data where the quality is poor, obtain the user request log and / or the hardware resource data associated with the user viewing data.
6. The method according to claim 5, characterized in that, The request time of the user request log and / or the hardware resource data associated with the user viewing data is earlier than the reporting time in the user viewing data.
7. The method according to claim 3, characterized in that, The reasons for the poor quality of the OTT service, as determined by the soft probe data, include: In response to the failure to obtain the user request log associated with the soft probe data that shows a poor quality record, the first reason for the poor quality of the OTT service is determined based on the first comparison result of the first statistical value and the first comparison value of the resource operation data in the soft probe data.
8. The method according to claim 3, characterized in that, The reasons for the poor quality of the OTT service, as determined from the user request logs, include: In response to obtaining the user request log associated with the soft probe data that shows a poor quality record, the cause of the poor OTT service quality is determined as the second cause of the poor quality based on the second comparison result of the second statistical value and the second comparison value of the user request log.
9. The method according to claim 3, characterized in that, The reasons for the poor quality of the OTT service, as determined by the hardware resource data, include: In response to the acquisition of user request logs associated with the soft probe data that showed a poor quality record, the cause of the poor OTT service quality is determined as the third cause of the poor quality based on the third comparison result of the third statistical value and the third comparison value of the hardware resource data.
10. The method according to claim 1, characterized in that, The first data includes soft probe data; The soft probe data includes at least one of the following: resource operation data, user viewing data; The user viewing data includes at least one of the following: reporting time, terminal device identifier, request content, and poor quality information.
11. The method according to claim 1, characterized in that, The second data includes at least one of the following: user request logs, hardware resource data; The user request log includes at least one of the following: request time, terminal device identifier, request content, session identifier, request status code, origin status code, and resource download information; The hardware resource data includes at least one of the following: hardware configuration information, CPU usage, memory usage, and network usage.
12. The method according to claim 1, characterized in that, Also includes: Predict the trend of the second data and obtain the predicted value of the second data; In response to the predicted value meeting the preset alarm threshold, a quality improvement warning is triggered based on the reason for the poor quality of the OTT service.
13. The method according to claim 7, 8, or 9, characterized in that, Also includes: The reasons for poor OTT service quality are adjusted based on deep learning models or received feedback information.
14. The method according to claim 13, characterized in that, The reasons for adjusting the poor quality of the OTT service based on the deep learning model include one of the following: The deep learning model determines the reasons for poor OTT service quality; in response to the reasons for poor OTT service quality determined by the deep learning model as the first reason for poor quality; the similarity between the statistical object, statistical value, and comparison value used by the deep learning model and the soft probe data, the first statistical value, and the first comparison value are compared; at least one of the soft probe data, the first comparison value, and the first reason for poor quality is adjusted according to the similarity. The deep learning model determines the cause of poor OTT service quality; in response to the cause of poor OTT service quality determined by the deep learning model, a second cause of poor quality is identified; the similarity between the statistical object, statistical value, and comparison value used by the deep learning model and the user request log, the second statistical value, and the second comparison value is compared; at least one of the user request log, the second comparison value, and the second cause of poor quality is adjusted based on the similarity. The deep learning model determines the reasons for poor OTT service quality; in response to the reasons for poor OTT service quality determined by the deep learning model, a third reason for poor quality is identified; the similarity between the statistical object, statistical value, and comparison value used by the deep learning model and the hardware resource data, the third statistical value, and the third comparison value is compared; at least one of the hardware resource data, the third comparison value, and the third reason for poor quality is adjusted based on the similarity.
15. A system for determining the causes of poor quality Internet TV (OTT) services, comprising terminal equipment, node equipment, and a server, characterized in that, The terminal device is used to collect and send the first data of OTT service to the server; The node device is used to collect and send the second data of the OTT service to the server; The server is configured to, in response to the presence of a poor-quality record in the first data, determine the reason for the poor quality of the OTT service based on the correlation between the first data and the second data.
16. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1 to 14.
17. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 14.