A method and apparatus for diagnosing IPTV service faults

Abstract

This application provides a method and apparatus for diagnosing IPTV service faults, relating to the field of IPTV technology, and capable of accurately locating faults in the IPTV service process. The method includes: receiving a fault query request for the IPTV service, the fault query request including the service account of the IPTV service; responding to the fault query request, querying the viewing request records associated with the service account based on the service account; if viewing request records are found, obtaining the status of the service account and the authentication records associated with the service account; if the status of the service account is abnormal, or the authentication records are abnormal, determining that the authentication is faulty.

Description

Technical Field

[0001] This application relates to the field of network television technology, and in particular to a method and apparatus for diagnosing faults in interactive network television (IPTV) services. Background Technology

[0002] With the rapid development of technologies such as the Internet and digital television, IPTV has become very popular. IPTV is a service that utilizes broadband cable television infrastructure, uses home television sets as the main terminal appliances, and provides various digital media services, including television programs, through Internet network protocols.

[0003] Although the network quality of IPTV services has been somewhat guaranteed with the deployment of both software and hardware probes, the complexity of IPTV service processes and the intricate nature of intermediate platform systems result in poor performance of IPTV service process interactions and data silos, making it difficult to locate faults throughout the entire IPTV service process. Summary of the Invention

[0004] This application provides a method and apparatus for diagnosing IPTV service faults, which can accurately locate faults throughout the entire IPTV service process.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, this application provides a method for diagnosing IPTV service faults. The method includes: receiving a fault query request for the IPTV service, the fault query request including the service account of the IPTV service; responding to the fault query request, querying the viewing request records associated with the service account based on the service account; if viewing request records are found, obtaining the status of the service account and the authentication records associated with the service account; if the status of the service account is abnormal, or the authentication records are abnormal, determining that the authentication is faulty.

[0007] Based on the method provided in the first aspect above, faults in the IPTV service can be identified in response to IPTV service fault query requests. Identifying IPTV service faults involves querying viewing request records, and if these records are found, obtaining the abnormal status of the service account and authentication records. In other words, fault diagnosis can be performed through the set-top box startup process and authentication process where the IPTV service viewing request records are located, thereby identifying IPTV service faults and enabling IPTV service process monitoring to promptly identify potential problems throughout the entire IPTV service process.

[0008] One possible implementation is to obtain the scheduling log associated with the business account from the business scheduling system if the business account is in a normal state and the authentication record is normal; if the scheduling log is abnormal, it is determined that the business scheduling system is faulty.

[0009] Based on the above method, if the business account is in a normal state and the authentication record is normal, fault diagnosis can be performed through the authentication process and service scheduling process of the IPTV service to determine the fault of the IPTV service.

[0010] One possible implementation is to obtain the request log of the electronic program guide associated with the business account if the scheduling log is normal; obtain the request message of the business account from the request log; and determine that the electronic program guide is faulty if the request message is abnormal.

[0011] Based on the above method, under normal scheduling log conditions, fault diagnosis can be performed through the IPTV service scheduling process and electronic program guide request process to determine the IPTV service fault.

[0012] One possible implementation is to determine whether a video source failure is occurring based on the quality monitoring metrics data of the live streaming channel when the request message is normal and the request log is used to request on-demand resources; or, if the request message is normal and the request log is used to request video-on-demand resources, obtain the RRS scheduling log associated with the business account; if the RRS scheduling log is abnormal, determine that an RRS scheduling failure has occurred.

[0013] Based on the above method, if the request message is normal and the request log is used to request live streaming resources, the fault of the IPTV service can be determined by requesting the Electronic Program Guide (EPB) of the IPTV service, or if the request message is normal and the request log is used to request on-demand resources, the EPB request process and the RRS scheduling process can be used for fault diagnosis.

[0014] One possible implementation is to obtain the HMS logs associated with the business account and the viewing records associated with the business account if the RRS scheduling logs are normal; if the HMS logs are abnormal and the viewing records indicate that multiple videos are playing abnormally, it is determined that the content delivery network server corresponding to the multiple videos is faulty.

[0015] Based on the above method, when the HMS log is abnormal and the viewing records indicate multiple video playback abnormalities, fault diagnosis can be performed through the RRS scheduling process and HMS process of the IPTV service, and the fault of the IPTV service can be determined by combining the viewing records.

[0016] One possible implementation involves receiving information indicating the start of the IPTV service before receiving a fault query request for the IPTV service. This information includes the current address information associated with the service account. The original address information associated with the service account is then obtained based on the service account. If the current address information differs from the original address information, the current location information of the service account is obtained. This current location information is used to indicate the current address information, the current service router, the current optical line terminal, and the current passive optical network interface.

[0017] Based on the above method, for situations where IPTV service accounts change due to IPTV service modifications, relocation, or account changes, the current location information of the IPTV service account can be determined, ensuring that the current location information matches the actual location information. This allows for the calibration of service account information and IPTV line information, enabling accurate IPTV service location and timely maintenance in case of malfunctions.

[0018] Secondly, this application provides an apparatus for diagnosing IPTV service faults, used to implement the above-described method. The apparatus includes modules, units, or means corresponding to the above-described method. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described functions.

[0019] Thirdly, this application provides an apparatus for diagnosing IPTV service faults, the apparatus comprising: a processor; the processor being coupled to a memory, and after reading instructions from the memory, executing the method described in the first aspect above according to the instructions.

[0020] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0021] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0022] In a sixth aspect, embodiments of this application provide a chip including a processor for running computer programs or instructions to implement the methods described in the first aspect or any possible implementation thereof.

[0023] In one possible implementation, the chip provided in this application embodiment further includes a memory for storing computer programs or instructions.

[0024] The technical effects of any possible implementation of aspects two through six can be found in the first aspect or the technical effects of different possible implementations of aspect one, and will not be repeated here. Attached Figure Description

[0025] Figure 1A This application provides a schematic diagram of an IPTV service process.

[0026] Figure 1B A schematic diagram illustrating an IPTV service process analysis approach provided in this application embodiment;

[0027] Figure 1C This application provides a schematic diagram of the architecture of an IPTV service system.

[0028] Figure 2A A flowchart illustrating a method for diagnosing IPTV service faults provided in this application embodiment;

[0029] Figure 2B A schematic diagram of the human-computer interaction interface of an IPTV service fault diagnosis device provided in an embodiment of this application;

[0030] Figure 3 A schematic diagram of the structure of an IPTV service fault diagnosis device provided in an embodiment of this application;

[0031] Figure 4 A schematic diagram of the hardware structure of an IPTV service fault diagnosis device provided in an embodiment of this application;

[0032] Figure 5 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0033] The methods and apparatus provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0034] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0035] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0036] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0037] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0038] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0039] The method provided in this application can be used in IPTV service processes, which can be as follows: Figure 1A As shown. In Figure 1A In this process, after a user initiates the IPTV service, the IPTV service fault diagnosis device performs a service authentication process, followed by a video network process, and finally a home network process via the IP metropolitan area network to complete the IPTV service activation. The service authentication process includes user authentication and broadcast control authentication. The video network process includes video source-related processes and playback scheduling processes.

[0040] The complex processes and intricate intermediate platform systems of the aforementioned IPTV services result in poor performance and data silos in the IPTV service process interactions, making it difficult to monitor the entire IPTV service process, locate faults, and identify potential problems. Faults in the IPTV service process can include various issues, such as: licensing issues, platform-side issues, network issues, and terminal issues. Licensing issues include monitoring and streamlining processes related to service platform server performance, service scheduling, and authentication. Platform-side issues include CDN scheduling performance, CDN server performance, and user authentication issues. Network issues include excessive network latency, network connection interruptions, severe packet loss, bandwidth limitations, and access network latency / packet loss problems. Terminal issues include poor terminal performance and terminal software problems.

[0041] To address the aforementioned technical issues, this application provides a method for diagnosing IPTV service faults. This method is based on a single-user service authentication process, sorts out and outputs the signaling interaction process in the IPTV service process, and, in conjunction with the current status of the service support platform construction, constructs an IPTV service process QOE perception and assurance system through "log collection + proactive monitoring".

[0042] The above analysis approach for IPTV service processes is based on a review of the IPTV service process and log data from related services. Fault phenomena are used to map corresponding key service indicators, and the judgment logic is continuously verified and improved to achieve full-process analysis and accurate fault location. For example... Figure 1B As shown, the analysis approach for the IPTV service process is based on the analysis of power-on services, authentication services, EPG loading services, and playback services. Because these services generate a large volume of logs and involve complex instructions, data slicing technology is needed to perform statistical operations such as accumulation and counting on the data during data entry, distributing the concentrated statistical computation load later across various time periods. Specifically, the database slices logs at a 1-minute granularity based on the log account ID and timestamp, backfilling account-related log information to ensure high availability of logs even without keywords. This achieves rapid log processing and ultimately outputs various data visualization reports. This processing method is used to process viewing request records, authentication records, EDS scheduling logs, electronic program guide request logs, RRS scheduling logs, and HMS logs in this embodiment of the application.

[0043] Based on the above-mentioned methods for diagnosing IPTV service faults, the quality of multiple stages of the IPTV service process can be improved. Problems in the IPTV service authentication process for individual users can be effectively solved from the source, thereby realizing process monitoring of IPTV services.

[0044] The IPTV service fault diagnosis method provided in this application embodiment can be applied to various IPTV service systems, for example, it can be applied to Figure 1C The IPTV service system 10 shown is shown.

[0045] like Figure 1C The diagram shown is an architectural schematic of the IPTV service system 10 provided in this embodiment of the application. Figure 1C In this system, the IPTV service system 10 may include an IPTV service fault diagnosis device 101, a set-top box 102, and a service management system 103. Optionally, the IPTV service system 10 may also include a service scheduling system 104, an Electronic Program Guide (EPG) request system 105, an RRS scheduling system 106, and an HMS system 107.

[0046] The set-top box in this application embodiment, such as set-top box 102, can be a device that connects a television set to an external signal source.

[0047] The IPTV service fault diagnosis device in this application embodiment, such as the IPTV service fault diagnosis device 101, can be any device with computing and communication capabilities. For example,

[0048] Servers, cloud services, computers, or computing devices, etc.

[0049] The business management system in this application embodiment, such as business management system 103, can be used to obtain the status and authentication records of business accounts.

[0050] The business scheduling system in this application embodiment, for example, business scheduling system 104, can be used to obtain the scheduling log associated with the business account.

[0051] The EPG request system in this application embodiment, such as EPG request system 105, can be used to obtain request logs of electronic program guides associated with business accounts.

[0052] The RRS scheduling system in this application embodiment, such as RRS scheduling system 106, can be used to obtain RRS scheduling logs associated with business accounts.

[0053] The HMS system in the five embodiments of this application, such as HMS system 107, can be used to obtain HMS logs associated with business accounts.

[0054] Figure 1C The IPTV service system 10 shown is for illustrative purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art should understand that, in specific implementations, the IPTV service system 10 may also include... Figure 1C More or fewer devices are not limited.

[0055] The methods provided in the embodiments of this application will be described in detail below.

[0056] like Figure 2A The image shows a method for diagnosing IPTV service faults provided in an embodiment of this application. The method includes the following steps:

[0057] S201: The device for diagnosing IPTV service faults receives a fault query request for IPTV services.

[0058] In this embodiment of the application, the device for IPTV service fault diagnosis can be... Figure 1C The device 101 for diagnosing IPTV service faults in the IPTV5 service system 10 shown.

[0059] by Figure 1C Taking the IPTV service system shown as an example, the set-top box 102 sends an IPTV service fault query request to the IPTV service fault diagnosis device 101, and correspondingly, the IPTV service fault diagnosis device 101 receives the IPTV service fault query request sent by the set-top box 102. The fault query request includes the IPTV service account.

[0060] 0. One possible design involves the IPTV service fault diagnosis device receiving information indicating the initiation of the IPTV service before receiving a fault query request. This information includes the current address information associated with the service account. The device then retrieves the original address information associated with the service account. If the current address information differs from the original address information, it retrieves the current location information of the service account. This current location information indicates the current address information (Internet Protocol, IP), the current service router (SR), the current optical line terminal (OLT), and the current passive optical network (PON) interface.

[0061] For example, the IPTV service fault diagnosis device receives information indicating the start of the IPTV service and obtains the current address information and original address information associated with the service account of the IPTV service. If the current address information differs from the original address information, the IPTV service fault diagnosis device obtains the OLT information of the service account on the SR through the link layer discovery protocol, and obtains the PON interface information through the two-layer virtual LAN based on the OLT information, thereby obtaining the current location information of the service account.

[0062] Based on the above method, for situations where IPTV service accounts change due to IPTV service modifications, relocation, or account changes, the current location information of the IPTV service account can be determined, ensuring that the current location information matches the actual location information. This allows for the calibration of service account information and IPTV line information, enabling accurate IPTV service location and timely maintenance in case of malfunctions.

[0063] S202: The IPTV service fault diagnosis device responds to the fault query request and queries the viewing request records associated with the service account based on the service account.

[0064] S203: If a movie viewing request record is found, the IPTV service fault diagnosis device obtains the status of the service account and the authentication record associated with the service account.

[0065] The viewing request records associated with a service account are those stored in the set-top box associated with that service account. The status of a service account includes a normal status and an abnormal status. A normal status indicates that the service account has the necessary permissions or is not in arrears, while an abnormal status indicates that the service account is in arrears or lacks the required permissions.

[0066] by Figure 1C Taking the IPTV service system shown as an example, after receiving a fault query request for the IPTV service, the IPTV service fault diagnosis device 101 queries the viewing request records associated with the service account of the IPTV service. If the set-top box 102 information with stored viewing request records is not found or the viewing records are empty, the IPTV service fault diagnosis device 101 determines that the set-top box 102 is faulty or the network where the set-top box 102 is located is faulty. If a viewing request record is found, the IPTV service fault diagnosis device obtains the status of the service account and the authentication records associated with the service account.

[0067] S204: The device for diagnosing IPTV service faults determines whether it is an authentication fault based on the status of the service account and the authentication records.

[0068] One possible implementation is that if the status of the service account is abnormal, or the authentication record is abnormal, the IPTV service fault diagnosis device determines that the authentication is faulty.

[0069] Understandably, if the IPTV service fault diagnosis device is located in the service management system (e.g., for...), Figure 1C The business management system 103) obtains the status of the business account as either "the business account is in arrears" or "the business account has no permissions," indicating an abnormal status of the business account. Alternatively, it obtains the authentication record of the business account as either "empty" or "authentication failed," indicating an abnormal authentication record. The IPTV service fault diagnosis device then determines that the authentication is faulty.

[0070] Optionally, if the business account is in a normal status (e.g., the business account has the necessary permissions or the business account is not in arrears) and the authentication record is normal (e.g., the authentication record shows successful authentication), Figure 2A The method shown may also include the following steps:

[0071] S205: The device for diagnosing IPTV service faults obtains the scheduling log associated with the service account from the service scheduling system.

[0072] S206: If the scheduling log is abnormal, the IPTV service fault diagnosis device determines that the service scheduling system is faulty.

[0073] Understandably, if the IPTV service fault diagnosis device is from the service scheduling system (e.g., for...) Figure 1C If the service scheduling system 104 in the IPTV service obtains an empty scheduling log associated with the service account or a scheduling failure, i.e., the scheduling log is abnormal, the IPTV service fault diagnosis device determines that the EDS is in a scheduling fault.

[0074] Optionally, if the scheduling log is normal (e.g., the scheduling log indicates successful scheduling or the scheduling log is not empty), Figure 2A The method shown also includes the following steps:

[0075] S207: The device for diagnosing IPTV service faults obtains the request log of the Electronic Program Guide (EPG) associated with the service account and retrieves the request message of the service account from the request log.

[0076] S208: If the request message is abnormal, the IPTV service fault diagnosis device determines that the Electronic Program Guide is faulty.

[0077] Among them, abnormal request messages include requests for the business account having no record, or requests for the business account having failed to respond or timed out.

[0078] Understandably, the device for IPTV service fault diagnosis requests the system (e.g., for...) from the EPG. Figure 1C If the EPG request system 104 in the IPTV service malfunction diagnoses the electronic program guide as faulty if it finds no record for the request message for the service account, or if the request message for the service account fails to respond or times out.

[0079] Optionally, if the request message is normal (e.g., the request message is logged or the request message response is successful), Figure 2A The method shown also includes the following steps:

[0080] S209: The device for diagnosing IPTV service faults determines the faults based on the contents of the EPG request log.

[0081] One possible implementation is that, if the request message is normal and the request log is used to request live streaming resources, the IPTV service fault diagnosis device determines whether the video source is faulty based on the content source live streaming channel quality monitoring index data.

[0082] Understandably, if the EPG request log is used to request live streaming resources, and the quality monitoring data of the live streaming channel of the content source is poor, resulting in buffering during the live stream, then the IPTV service fault diagnosis device will determine that the video source is faulty.

[0083] One possible implementation involves the following steps: If the request message is normal and the request log is used to request on-demand resources, the IPTV service fault diagnosis device obtains the RRS scheduling log associated with the service account. If the RRS scheduling log is abnormal, the IPTV service fault diagnosis device determines it to be an RRS scheduling failure. Abnormal RRS scheduling logs include no record in the RRS scheduling log for the service account, or the RRS scheduling log for the service account recording a no-response request or scheduling failure.

[0084] Understandably, IPTV service fault diagnosis devices are derived from the RRS dispatch system (e.g., for...). Figure 1C If the RRS scheduling system 106 in the IPTV service fails to obtain a record in the RRS scheduling log of the service account, or if the record in the RRS scheduling log of the service account is "no response to request" or "scheduling failure", the IPTV service fault diagnosis device determines that it is an RRS scheduling fault.

[0085] Optionally, if the RRS scheduling log is normal (e.g., RRS scheduling log response is successful or RRS scheduling is successful), the IPTV service fault diagnosis device obtains the HMS log associated with the service account and the viewing records associated with the service account. If the HMS log is abnormal and the viewing records indicate that multiple videos are playing abnormally, the IPTV service fault diagnosis device determines that the content delivery network server corresponding to the multiple videos is faulty.

[0086] Understandably, IPTV service fault diagnosis devices are derived from the HMS system (e.g., for...). Figure 1C The HMS system 107 retrieves the HMS logs associated with the business account and, in conjunction with the viewing records associated with the business account, determines whether the content delivery network server corresponding to multiple videos is faulty. If the HMS logs indicate that multiple videos are clustered on the same CDN server and experience playback failures or poor quality, or if the HMS logs indicate that the aggregation reveals a CDN server network port failure or high network latency, the IPTV service fault diagnosis device determines that the content delivery network server corresponding to multiple videos is faulty. Otherwise, if everything is normal, the IPTV service fault diagnosis device terminates the fault diagnosis.

[0087] based on Figure 2AThe method shown allows the IPTV service fault diagnosis device to respond to IPTV service fault query requests and determine IPTV service faults. To determine an IPTV service fault, the device needs to query viewing request records. Only after finding these records can it obtain the service account's status anomaly and authentication records. In other words, fault diagnosis can be performed through the set-top box's boot-up and authentication processes associated with the IPTV service's viewing request records. Furthermore, the device also performs fault diagnosis using EDS scheduling logs, Electronic Program Guide request logs, RRS scheduling logs, and HMS logs, thereby achieving full-process monitoring of a single IPTV service and promptly identifying potential problems throughout the entire process.

[0088] Understandably, the above-described device for IPTV service fault diagnosis diagnoses single-user IPTV services based on the IPTV service process, thereby identifying faults in the single-user IPTV service process and completing the fault diagnosis method for the single-user IPTV service authentication process. For fault diagnosis of IPTV services for group users, the five types of authentication requests in the existing group user IPTV service process within a selected time period can be analyzed step-by-step. By analyzing the success rate of each of the five authentication requests before transitioning to the next authentication step, supplemented by set-top box type, version, and server request address, fault diagnosis can be performed on the faulty IPTV service, thus achieving fault diagnosis of the IPTV service process for group users. The five types of authentication requests include: EDS authentication request, challenge key acquisition authentication request, access token acquisition authentication request, ACS authentication request, and Lancher authentication request.

[0089] For example, within a selected time period, by statistically analyzing data on IPTV service requests initiated by set-top boxes across the province, it was determined that a total of 327,500 users initiated IPTV service requests from EDS authentication to Launcher authentication. During this period, the success rate of IPTV service requests was 90%, totaling 297,400 users. Specifically, 327,527 users successfully completed EDS authentication requests, 321,430 successfully completed challenge-based authentication requests, 319,459 successfully completed access token authentication requests, 318,959 successfully completed ACS authentication requests, and 297,469 successfully completed Launcher authentication requests. Therefore, it can be concluded that Launcher authentication requests had the fewest successful users among the five types of authentication requests, i.e., the lowest success rate, thus indicating that the possibility of Launcher authentication request failure is the highest.

[0090] In addition to troubleshooting IPTV services for single users and groups of users, there will also be troubleshooting for IPTV services from users exhibiting abnormal behavior. Abnormal users include those with long activation request times and those with a high number of activation requests. For example, users with long activation request times are those whose activation time from initiating an EDS request to successful Launcher authentication exceeds 50 seconds. Troubleshooting IPTV services for abnormal users requires extracting and analyzing their data separately.

[0091] Integrating fault diagnosis for single-user IPTV services, group-user IPTV services, and abnormal user IPTV services can create a one-click diagnostic analysis model for the entire IPTV service process, enabling comprehensive fault diagnosis. The specific interface implementation can be as follows: Figure 2B As shown.

[0092] For example, the total number of users of the Magic Box service (an IPTV service) in a certain province is approximately 4.6653 million. Its overall satisfaction score in the third quarter was 68.54, ranking near the bottom nationally, with a particularly low score for terminal quality. Among network quality complaints from January to August, Magic Box complaints accounted for 24%. Analysis of Magic Box complaint types revealed that startup failure complaints accounted for 32.3%, and authentication failure complaints accounted for 21.6%. By monitoring the entire IPTV service process using the method provided in this application embodiment, the startup failure complaint rate decreased to 18.9%, and the authentication failure complaint rate decreased to 10.5%.

[0093] Therefore, the method provided in this application embodiment can realize fault diagnosis of the entire process of user-level IPTV service and achieve end-to-end problem troubleshooting.

[0094] The embodiments of this application can divide the device for IPTV service fault diagnosis into functional modules or functional units according to the above method examples. For example, each function can be divided into a functional module or functional unit, or two or more functions can be integrated into one module.

[0095] The integrated modules described above can be implemented in hardware, software, or as functional modules or units. The division of modules or units in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used.

[0096] like Figure 3The diagram shown is a hardware structure diagram of an IPTV service fault diagnosis device 30 provided in an embodiment of this application. The device includes: a transceiver module 301, a processing module 302, and an acquisition module 303.

[0097] 5. Among them, the transceiver module 301 is used to receive fault query requests for the IPTV service, and the fault query requests include the service account of the IPTV service. For example, the transceiver module 301 is used to perform the above...

[0098] S201.

[0099] Processing module 302 is used to respond to a fault query request by querying the movie viewing request records associated with the business account based on the business account. For example, processing module 302 is used to execute S202 as described above.

[0100] Module 303 is used to obtain the status of the business account and the authentication records associated with the business account if a movie viewing request record is found. For example, module 303 is also used to perform the above...

[0101] S203.

[0102] The processing module 302 is also used to determine an authentication failure if the status of the business account is abnormal or the authentication record is abnormal. For example, the processing module 302 is also used to execute the above-mentioned S204.

[0103] 5. One possible implementation is that the acquisition module 303 is also used to obtain the scheduling log associated with the business account from the business scheduling system if the status of the business account is normal and the authentication record is normal.

[0104] The processing module 302 is also used to determine the scheduling failure of the business scheduling system if the scheduling log is abnormal.

[0105] In one possible implementation, the acquisition module 303 is further configured to acquire the request log of the electronic program guide associated with the business account if the scheduling log is normal; the acquisition module 303 is further configured to acquire the request message of the business account from the request 0 log; and the processing module 302 is further configured to determine that the electronic program guide is faulty if the request message is abnormal.

[0106] In one possible implementation, the processing module 302 is further configured to determine whether the video source is faulty based on the quality monitoring index data of the live streaming channel of the content source if the request message is normal and the request log is used to request live streaming resources; or, the acquisition module 303 is further configured to acquire the RRS scheduling log associated with the business account if the request message is normal and the request log is used to request on-demand resources; the processing module 302 is further configured to determine that the RRS scheduling is faulty if the RRS scheduling log is abnormal.

[0107] In one possible implementation, the acquisition module 303 is further configured to acquire the HMS log associated with the business account and the viewing records associated with the business account if the RRS scheduling log is normal; the processing module 302 is further configured to determine that the content distribution network server corresponding to the multiple videos is faulty if the HMS log is abnormal and the viewing records indicate that multiple videos are playing abnormally.

[0108] In one possible implementation, the transceiver module 301 is further configured to receive information indicating the start of the IPTV service, including the current address information associated with the service account; the acquisition module 303 is further configured to acquire the original address information associated with the service account based on the service account; the acquisition module 303 is further configured to acquire the current location information of the service account if the current address information is different from the original address information, and the current location information is used to indicate the current address information, the current service router, the current optical line terminal, and the current passive optical network interface.

[0109] Understandably, the above-mentioned device can also be implemented in hardware. For example, in hardware implementation, the transceiver module 301 and the acquisition module 303 in this embodiment can be integrated on the communication interface, and the processing module 302 can be integrated on the processor. As another example, in hardware implementation, the transceiver module 301, the processing module 302, and the acquisition module 303 in this embodiment are all integrated on the processor. The hardware structure can be as follows... Figure 4 As shown.

[0110] Figure 4 A schematic diagram of a possible hardware structure of the IPTV service fault diagnosis device involved in the above embodiments is shown. The IPTV service fault diagnosis device includes a processor 402. Optionally, the IPTV service fault diagnosis device further includes a communication interface 403, a memory 401, and a bus 404.

[0111] The processor 402 is used to control and manage the operation of the device for IPTV service fault diagnosis, for example, executing the steps performed by the processing module 302, and / or other processes for performing the techniques described herein. Optionally, the processor 402 may also execute the steps performed by the transceiver module 301 and the acquisition module 303. The processor 402 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0112] The communication interface 403 is used to support communication between the device for IPTV service fault diagnosis and other network entities, for example, to perform the steps performed by the acquisition module 303 described above.

[0113] The memory 401 is used to store program code and data of the device for IPTV service fault diagnosis. For example, the memory 401 may be the memory in the device, and the memory may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk or solid-state drive; the memory may also include a combination of the above types of memory.

[0114] Bus 404 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 404 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0115] Figure 5 This is a schematic diagram of the structure of chip 50 provided in an embodiment of this application. Chip 50 includes one or more (including two) processors 501. Optionally, chip 50 also includes a communication interface 503, a bus 502, and a memory 504.

[0116] The processor 501 described above can implement or execute various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. The processor can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. The processor can 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.

[0117] Memory 504 may include read-only memory and random access memory, and provides operation instructions and data to processor 501. A portion of memory 504 may also include non-volatile random access memory (NVRAM).

[0118] In some implementations, memory 504 stores elements such as execution modules or data structures, or subsets thereof, or extended sets thereof.

[0119] In this embodiment of the application, the corresponding operation is executed by calling the operation instructions stored in the memory 504 (which may be stored in the operating system).

[0120] The memory 504 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk or solid-state drive; the memory may also include combinations of the above types of memory.

[0121] Bus 502 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 502 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0122] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be 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 be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0123] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the IPTV service fault diagnosis method described in the above method embodiments.

[0124] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method for diagnosing IPTV service faults in the method authentication process described in the above-described method embodiments.

[0125] The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires; portable computer disks; hard disks; random access memory (RAM); read-only memory (ROM); erasable programmable read-only memory (EPROM); registers; hard disks; optical fibers; portable compact disc read-only memory (CD-ROM); optical storage devices; magnetic storage devices; or any suitable combination thereof; or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may reside in an application-specific integrated circuit (ASIC). In the embodiments of this application, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0126] Since the apparatus, computer-readable storage medium, and computer program product in the embodiments of this application can be applied to the above methods, the technical effects that can be obtained can also be referred to the above method embodiments. The embodiments of this application will not be repeated here.

[0127] In the several embodiments provided in this 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 merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0130] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for diagnosing a fault of an interactive network television (IPTV) service, the method comprising: receiving a fault report from a user; and diagnosing the fault of the IPTV service based on the fault report. The method comprises: receiving a fault query request of an IPTV service, the fault query request comprising a service account of the IPTV service; in response to the fault query request, querying a viewing request record associated with the service account according to the service account; if the viewing request record is queried, acquiring a state of the service account and an authentication record associated with the service account; if the state of the service account is abnormal or the authentication record is abnormal, determining authentication failure; if the state of the service account is normal and the authentication record is normal, acquiring a scheduling log associated with the service account from a service scheduling system; if the scheduling log is abnormal, determining scheduling failure of the service scheduling system; if the scheduling log is normal, acquiring a request log of an electronic program guide associated with the service account; acquiring a request message of the service account from the request log; if the request message is abnormal, determining electronic program guide failure.

2. The method of claim 1, wherein, The method further comprises: if the request message is normal and the request log is used to request live broadcast resources, determining whether video source failure occurs according to content source live broadcast channel quality monitoring index data; or if the request message is normal and the request log is used to request on-demand resources, acquiring an RRS scheduling log associated with the service account; if the RRS scheduling log is abnormal, determining RRS scheduling failure.

3. The method of claim 2, wherein, The method further comprises: if the RRS scheduling log is normal, acquiring an HMS log associated with the service account and a viewing record associated with the service account; if the HMS log is abnormal and the viewing record indicates that multiple video playback is abnormal, determining that content distribution network servers corresponding to the multiple videos fail.

4. The method according to any one of claims 1 to 3, characterized in that, Before the receiving of the fault query request of the IPTV service, the method further comprises: receiving information indicating that the IPTV service is started, the information comprising current address information associated with the service account; acquiring original address information associated with the service account according to the service account; if the current address information is different from the original address information, acquiring current location information of the service account, the current location information being used to indicate the current address information, a current service router, a current optical line terminal and a current passive optical network interface.

5. An apparatus for diagnosing an IPTV service failure, the apparatus comprising: The apparatus comprises a transceiver module, a processing module and an acquisition module; the transceiver module is configured to receive a fault query request of an IPTV service, the fault query request comprising a service account of the IPTV service; the processing module is configured to, in response to the fault query request, query a viewing request record associated with the service account according to the service account; the acquisition module is configured to, if the viewing request record is queried, acquire a state of the service account and an authentication record associated with the service account; the processing module is further configured to, if the state of the service account is abnormal or the authentication record is abnormal, determine authentication failure; The acquisition module is further configured to acquire, from a service scheduling system, a scheduling log associated with the service account if the state of the service account is normal and the authentication record is normal. The processing module is further configured to determine a scheduling failure of the service scheduling system if the scheduling log is abnormal. The acquisition module is further configured to acquire a request log of an electronic program guide associated with the service account if the scheduling log is normal. The acquisition module is further configured to acquire a request message of the service account from the request log. The processing module is further configured to determine an electronic program guide failure if the request message is abnormal.

6. The apparatus of claim 5, wherein, The processing module is further configured to determine whether a video source is faulty according to content source live channel quality monitoring index data if the request message is normal and the request log is used to request live resources; or The acquisition module is further configured to acquire an RRS scheduling log associated with the service account if the request message is normal and the request log is used to request on-demand resources. The processing module is further configured to determine that the RRS scheduling is faulty if the RRS scheduling log is abnormal.

7. The apparatus of claim 6, wherein, The acquisition module is further configured to acquire an HMS log associated with the service account and a viewing record associated with the service account if the RRS scheduling log is normal. The processing module is further configured to determine that content distribution network servers corresponding to a plurality of videos are faulty if the HMS log is abnormal and the viewing record indicates that the plurality of videos play abnormally.

8. The apparatus of any one of claims 5-7, wherein, The transceiver module is further configured to receive information indicating that the IPTV service is started, the information including current address information associated with the service account. The acquisition module is further configured to acquire original address information associated with the service account according to the service account. The acquisition module is further configured to acquire current location information of the service account if the current address information is different from the original address information, the current location information being used to indicate the current address information, a current service router, a current optical line terminal, and a current passive optical network interface.

9. An apparatus for diagnosing an IPTV service failure, the apparatus comprising: comprising: a processor coupled to a memory, the memory storing programs or instructions that, when executed by the processor, cause the apparatus to perform the method of any one of claims 1-4.

10. A chip, characterized by comprising: a processor coupled to a memory, the memory storing programs or instructions that, when executed by the processor, cause the chip to perform the method of any one of claims 1-4.

11. A computer-readable storage medium having stored therein instructions, the computer-readable storage medium comprising: When a computer executes the instructions, the computer performs the method of any one of claims 1-4.

Images