Abnormal call record processing method, abnormal call record processing device, electronic equipment and storage medium

Abstract

The application provides an abnormal call record processing method, an electronic device and a storage medium. The abnormal call record processing method comprises the following steps: acquiring a tariff of a valid subscription instance in a current prevention and control period; based on a subscription relationship code, aggregating a call usage corresponding to the tariff; if the call usage is not in a preset fluctuation interval, determining that the tariff is a fluctuation abnormal tariff, and analyzing the fluctuation abnormal tariff to determine a fluctuation abnormal reason.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to an abnormal call detail record (CDR) processing method, an abnormal CDR processing device, an electronic device, and a storage medium. Background Technology

[0002] With the continuous development of communication networks and the increasing diversification of communication services, operators face technical challenges in handling abnormal call detail records (CDRs) in their billing systems while providing high-quality services. Abnormal CDRs can affect billing accuracy, accounting integrity, and service response efficiency, thereby impacting operational efficiency and user experience. As communication technology advances and services in the communication industry diversify, the accuracy and efficiency of CDR billing are also facing challenges. Summary of the Invention

[0003] This application provides an abnormal call detail record (CDR) processing method, an electronic device, and a storage medium.

[0004] The abnormal call detail record (CDR) processing method provided in this application includes: Get the pricing for valid subscription instances within the current prevention and control period; Based on the subscription relationship code, summarize the call detail record usage corresponding to the aforementioned tariff; If the call detail record (CDR) usage is not within the preset fluctuation range, the tariff is determined to be an abnormal fluctuation tariff, and the abnormal fluctuation tariff is analyzed to determine the cause of the abnormal fluctuation.

[0005] The abnormal call detail record (CDR) processing device provided in this application includes: The call detail record (CDR) generation and control processing module is used to obtain the tariffs of valid subscription instances within the current control period. The call detail record generation and control processing module is used to summarize the call detail record usage corresponding to the tariff based on the subscription relationship code. The call detail record (CDR) generation flow control processing module is used to determine that the tariff is an abnormal fluctuation tariff if the CDR usage is not within a preset fluctuation range, and to analyze the abnormal fluctuation tariff to determine the cause of the fluctuation.

[0006] The electronic device provided in this application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute the abnormal call detail record (CDR) processing method provided in any embodiment of this application.

[0007] The storage medium provided in this application embodiment is used to store a computer program, which causes a computer to execute the abnormal call detail record (CDR) processing method provided in any embodiment of this application.

[0008] The abnormal call detail record (CDR) processing method, device, electronic equipment, and storage medium provided in this application first obtain the tariffs of valid subscription instances within the current prevention and control period, and summarize the CDR usage corresponding to the tariffs based on the subscription relationship code; then, it determines whether the CDR usage is within a preset fluctuation range. If not, it is determined to be an abnormal fluctuating tariff, and the tariff is analyzed to determine the cause of the anomaly. This design can quickly identify abnormal fluctuations by setting a reasonable fluctuation range, thereby improving the efficiency and accuracy of anomaly detection. At the same time, in-depth analysis of abnormal tariffs helps to locate specific causes, improves problem-solving efficiency, and reduces manual intervention. Attached Figure Description

[0009] Figure 1 A schematic diagram illustrating the implementation flow of the abnormal call detail record (CDR) processing method provided in this application embodiment; Figure 2 A flowchart illustrating the call detail record (CDR) prevention method provided in this application embodiment; Figure 3 This is a schematic diagram of the abnormal call detail record processing device provided in the embodiments of this application; Figure 4 A schematic structural diagram of an electronic device provided in the embodiments of this application; Figure 5 This is a schematic structural diagram of the chip provided in an embodiment of this application. Detailed Implementation

[0010] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0011] It should be noted that, in the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, in the embodiments of this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0012] In the description of the embodiments of this application, the term "correspondence" may indicate that there is a direct or indirect correspondence between two things, or that there is an association between two things, or that there is a relationship of instruction and being instructed, configuration and being configured, etc.

[0013] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0014] With the rapid advancement of communication technology and the diversification of services in the telecommunications industry, call detail records (CDRs) billing face challenges in terms of accuracy, completeness, and timeliness, impacting operator rights, user satisfaction, and technological innovation. Currently, frequent data errors and transmission delays result in losses due to data leakage and inefficiency.

[0015] In the current telecommunications billing environment, traditional auditing methods have significant limitations in processing call detail records (CDRs) and ensuring revenue. First, the monitoring scope is incomplete, failing to effectively cover all key aspects of CDR processing, making it difficult to detect and address potential problems in a timely manner. Second, the auditing process relies on manual processes, which is not only inefficient but also prone to errors and disputes due to human factors (such as fatigue, negligence, or misunderstandings), affecting the accuracy and fairness of billing. Third, real-time response capabilities are insufficient; in the face of a rapidly changing communication environment, manual audits struggle to respond quickly, leading to increased losses. With the surge in data volume, data processing capacity becomes a bottleneck; existing systems often struggle to process massive amounts of CDR data quickly and accurately, impacting billing efficiency and accuracy. Furthermore, high labor costs and inefficient cross-departmental collaboration increase operating costs, prolong problem-solving time, and affect overall operational efficiency.

[0016] refer to Figure 1 , Figure 1 A schematic diagram of the implementation flow of the abnormal call detail record (CDR) processing method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, the abnormal call detail record (CDR) processing method provided in this embodiment includes the following steps: Step 101: Obtain the pricing information for valid subscription instances within the current prevention and control period.

[0017] In this embodiment, the prevention and control period can be set at granularity such as hourly or daily, depending on the business scenario and the configuration requirements of the billing system. A valid subscription instance within the prevention and control period refers to a subscription instance that is active and has not been canceled or suspended during the current prevention and control period. For example, in cloud hosting services, if a user subscribes to a certain tariff product at 9:00 AM on day T-1 and is still using it at 8:00 AM on day T, then the subscription instance of the tariff product subscribed by the user is valid within the prevention and control period of day T. Each subscription instance corresponds to a unique subscription relationship code, used for subsequent call detail record (CDR) usage aggregation and analysis.

[0018] In this embodiment, a subscription instance refers to a user's specific subscription behavior under a certain tariff product. Each subscription instance has unique identification information (such as a subscription relationship code) and includes key attributes such as subscription time, effective time, expiration time, and tariff type. In the billing system, each subscription instance generates corresponding call detail record (CDR) usage data for subsequent billing processing.

[0019] In this embodiment, the control period refers to the time period during which the system monitors and analyzes abnormal call detail records (CDRs). Depending on business needs, the control period can be set to different granularities such as hourly, daily, or weekly. For example, in high-concurrency scenarios, the control period might be set to once per hour to promptly detect abnormal fluctuations; while in low-frequency business scenarios, the control period might be set to once per day. The selection of the control period must balance real-time performance with resource consumption.

[0020] In this embodiment, the tariff includes one or more of the following information: tariff name, tariff unit price, billing method (such as pay-as-you-go, annual / monthly subscription, etc.), and whether stacked billing is supported. Obtaining the above tariff information provides basic data support for subsequent call detail record (CDR) usage calculations and anomaly detection.

[0021] Step 102: Based on the subscription relationship code, summarize the call detail record (CDR) usage corresponding to the tariff.

[0022] In this embodiment, the subscription relationship code ensures that each call detail record (CDR) can be accurately assigned to the corresponding subscription instance. For example, after a user subscribes to a cloud server service, a unique subscription relationship code can be assigned to that user. Subsequently, each CDR generated by a user using cloud server resources will carry the unique subscription relationship code, so that the system can correctly count the user's CDR usage.

[0023] In this embodiment, call detail record (CDR) usage refers to the actual usage data generated by a specific subscription instance within a specific prevention and control period. CDR usage is typically associated with the product tariff bound to the subscription instance and serves as one of the billing bases. For example, in cloud service scenarios, CDR usage includes CPU time, storage space usage, network traffic, etc. The data included in the aforementioned CDR usage originates from metering files or data collected by other business systems, and is formed into CDR records after standardization processing.

[0024] In this embodiment of the application, during the process of summarizing call detail record (CDR) usage, all relevant CDRs are categorized according to the order relationship code, and the total CDR usage for each tariff within the current prevention and control period is calculated.

[0025] Step 103: If the call detail record (CDR) usage is not within the preset fluctuation range, the tariff is determined to be an abnormal fluctuation tariff, and the abnormal fluctuation tariff is analyzed to determine the cause of the abnormal fluctuation.

[0026] In this embodiment, the preset fluctuation range is a statistical range derived from historical data analysis, used to determine whether the current call detail record (CDR) usage exhibits abnormal fluctuations. The preset fluctuation range can be calculated based on the mean and standard deviation of CDR usage over a certain historical period (e.g., 30 days), and upper and lower thresholds are determined by combining this with a confidence level coefficient. For example, the calculation formula for the preset fluctuation range is as follows: ,in, Average call volume during a single prevention and control period The confidence level coefficient is... This represents the number of call detail record (CDR) output cycles within 31 days. This represents the call detail record (CDR) usage in the nth CDR output cycle. When the sample size is less than 100, and the threshold is 10%, a 90% confidence level is used. It should be 1.645; when the sample size is greater than or equal to 100 but less than 500, and the threshold is 5%, the 95% confidence level should be used. It should be 1.96; when the sample size is greater than or equal to 500 and the threshold is 1%, the 99% confidence level should be used. It should be 2.58.

[0027] Once the pricing is determined to be abnormally fluctuating, the system initiates a root cause drill-down mechanism. This involves in-depth analysis of multiple data sources (such as product-side data, data from the ECloud Marketing & Management Operation Platform-Combined development (MOP), metering data, and call detail record (CDR) data) to identify the specific cause of the anomaly. Common causes include new subscriptions, user cancellations, abnormal metering files, incorrect orders, and errors in the Business Operation Support System for Enterprise Customer (EBOSS). These are factors that can lead to pricing fluctuations. Through precise identification of the cause of the fluctuation, the system can generate corresponding work orders and automatically assign them to the relevant departments for processing.

[0028] In this embodiment of the application, the step of analyzing the fluctuating tariff to determine the cause of the fluctuation includes: If the call detail record (CDR) usage is higher than the maximum value of the preset fluctuation range, it is determined that the CDR usage has increased abnormally. The reasons for the abnormal increase in CDR usage are analyzed to determine the cause of the abnormal fluctuation. If the call detail record (CDR) usage is lower than the minimum value of the preset fluctuation range, it is determined that the CDR usage has decreased abnormally. The reasons for the abnormal decrease in CDR usage are then analyzed to determine the cause of the abnormal fluctuation.

[0029] In this embodiment of the application, when the call detail record (CDR) usage exceeds the upper limit of a set range, the system determines that there is an abnormal increase in CDR usage and enters a further analysis process to locate the specific cause of the anomaly. For example, it may be due to a sudden increase in the number of subscribed instances, a sudden change in user behavior, or a system failure.

[0030] When call detail record (CDR) usage falls below the lower limit of a preset fluctuation range, the system considers this an abnormal decrease and triggers the corresponding analysis process. An abnormal decrease in CDR usage can be caused by various factors, such as user unsubscriptions, service suspensions, product configuration errors, or missing data collection. The system will analyze data from multiple dimensions, including subscription relationships, operation records, and metering documents, to determine whether this change is a normal business fluctuation or an issue requiring further investigation.

[0031] In this embodiment of the application, by setting a reasonable preset fluctuation range, the system can identify abnormal increases and decreases in call detail record (CDR) usage and initiate corresponding analysis processes based on the identification results, thereby enabling real-time monitoring and precise location of billing anomalies.

[0032] In the embodiments of this application, The analysis of the reasons for the abnormal increase in call detail record (CDR) usage includes: Calculate the month-on-month change in call detail record (CDR) usage for the first subscription instance; the first subscription instance is a subscription instance that is valid in both the previous prevention and control period and the current prevention and control period; calculate the month-on-month change in CDR usage for the abnormally fluctuating tariff; based on the month-on-month change in CDR usage for the first subscription instance and the month-on-month change in CDR usage for the abnormally fluctuating tariff, determine whether the abnormal increase in CDR usage is caused by a new subscription; If it is determined that the abnormal increase in call usage is caused by new orders, then the cause of the abnormal fluctuation is determined to be new orders. If it is determined that the abnormal increase in call order usage is not due to new orders, then calculate the month-on-month change in call order volume for each first order instance; based on the month-on-month change in call order volume for each first order instance, identify the abnormal first order instance; determine whether the metering file of the abnormal first order instance is abnormal; if the metering file of the abnormal first order instance is abnormal, then determine that the cause of the fluctuation abnormality is the abnormal metering file of the abnormal first order instance; and / or, The analysis of the reasons for the abnormal decrease in call detail record (CDR) usage includes: Calculate the month-on-month change in call detail record (CDR) usage for the second subscription instance; the second subscription instance is a subscription instance that is valid in both the previous prevention and control period and the current prevention and control period; calculate the month-on-month change in CDR usage for the abnormally fluctuating tariff; based on the month-on-month change in CDR usage for the second subscription instance and the month-on-month change in CDR usage for the abnormally fluctuating tariff, determine whether the abnormal decrease in CDR usage is caused by user unsubscription; If it is determined that the abnormal decrease in call usage is caused by user unsubscription, then the abnormal fluctuation is determined to be caused by user unsubscription. If it is determined that the abnormal decrease in call order usage is not caused by user unsubscription, then calculate the month-on-month change in call order volume for each second order instance; based on the month-on-month change in call order volume for each second order instance, identify the abnormal second order instance; determine whether the metering file of the abnormal second order instance is abnormal; if the metering file of the abnormal second order instance is abnormal, then determine that the cause of the fluctuation abnormality is the abnormal metering file of the abnormal second order instance.

[0033] In this embodiment, the first subscription instance refers to a subscription instance that is valid in both the previous and current prevention and control periods. The first subscription instance has not experienced any cancellations, suspensions, or invalidations, and possesses continuity, making it suitable for comparative analysis of call detail record (CDR) usage trends. By selecting the first subscription instance, abnormal fluctuations caused by subscription interruptions can be eliminated, thereby more accurately identifying anomalies caused by new subscriptions.

[0034] Call detail record (CDR) usage month-over-month (B / L) refers to the rate of change in CDR usage over a specific period relative to the previous period, expressed as a percentage. This indicator reflects changes in the usage behavior of subscription instances at different points in time, helping to identify abnormal growth or decline trends. For example, if a subscription instance experiences a significant B / L increase in CDR usage during the current prevention and control period, it may be due to new subscriptions.

[0035] By comparing the month-on-month change in call detail record (CDR) usage for the first subscription instance with the month-on-month change in CDR usage for the product with abnormally fluctuating pricing, it can be determined whether the abnormal increase is caused by new subscriptions. If the month-on-month change in CDR usage for the first subscription instance is less than the month-on-month change in CDR usage for the product with abnormally fluctuating pricing, it indicates that new subscriptions are the main reason; otherwise, the system needs to further analyze the usage of specific subscription instances.

[0036] In this embodiment, the abnormal first order instance refers to those order instances whose call detail record (CDR) usage is higher than the historical average during the current prevention and control period. The CDR usage of each first order instance is calculated month-on-month, using the formula: (Current CDR - Previous Day's CDR) / Previous Day's CDR. Here, the current CDR is the CDR for a specific time period on the current day (day T); the previous day's CDR is the CDR for the same specific time period on the previous day (day T-1). If the CDR for the same specific time period on day T-1 is 0, the search continues backward to find the CDR for the same specific time period on day T-2, until a non-zero historical CDR for the same specific time period is found. This identifies instances exhibiting abnormal usage behavior. Once an abnormal first order instance is discovered, it is also necessary to check whether the corresponding metering file for that order instance is abnormal. If the metering file shows abnormal data, such as an abnormal increase in the metering file or the generation of multiple CDRs, the cause of the fluctuation is determined to be an abnormality in the metering file, a preliminary judgment is generated, and the abnormality is recorded.

[0037] In this embodiment, the second subscription instance refers to a subscription instance that is valid in both the previous and current prevention and control periods, while there may be multiple first subscription instances. The second subscription instance has not experienced any cancellations, suspensions, or failures, and possesses continuity, making it suitable for comparative analysis of call detail record (CDR) usage trends. By selecting the second subscription instance, abnormal fluctuations caused by subscription interruptions can be eliminated, thereby more accurately identifying anomalies caused by new subscriptions.

[0038] By comparing the month-on-month change in call detail record (CDR) usage for the second subscription instance with that for the product with abnormally fluctuating call detail record (CDR), it can be determined whether the abnormal decrease was caused by cancellations / suspensions. If the month-on-month change in CDR usage for the second subscription instance is greater than that for the product with abnormally fluctuating call detail record (CDR), it indicates that cancellations / suspensions are the primary cause. Otherwise, the system needs to further analyze the usage of specific subscription instances.

[0039] In this embodiment, the abnormal second ordering instance refers to those ordering instances whose call detail record (CDR) usage is lower than the historical average during the current prevention and control period. The CDR usage of each second ordering instance is calculated month-on-month, using the formula: (Current CDR - Previous Day's CDR) / Previous Day's CDR. Here, the current CDR is the CDR for a specific time period on the current day (day T); the previous day's CDR is the CDR for the same specific time period on the previous day (day T-1). If the CDR for the same specific time period on day T-1 is 0, the search continues backward to find the CDR for the same specific time period on day T-2, until a non-zero historical CDR for the same specific time period is found. This identifies instances exhibiting abnormal usage behavior. Once an abnormal second ordering instance is discovered, it is also necessary to check whether the corresponding metering file for that ordering instance is abnormal. If the metering file shows abnormal data, such as an abnormal decrease in metering or fewer CDRs generated, the cause of the fluctuation is determined to be an abnormality in the metering file, a preliminary judgment is generated, and the abnormality is recorded.

[0040] In this embodiment of the application, the method further includes: If there are interruption anomalies among multiple call detail records (CDRs) of the subscription instance, it is determined whether the subscription instance has been unsubscribed and / or suspended; if there are unsubscribed and / or suspended, the interruption is determined to be a normal interruption; if there are no unsubscribed and / or suspended, the cause of the interruption anomaly is analyzed based on the first information; the first information includes one or more of the following: data collected by the product side, data collected by MOP, metering data, call detail record data; and / or, If there are cross-abnormalities among multiple call detail records (CDRs) of the order instance, the cause of the cross-abnormality is analyzed based on the second information; the second information includes one or more of the following: third information, metering data, and CDR data; the third information indicates whether there are duplicate orders.

[0041] In this embodiment, when there is a time discontinuity between multiple call detail records (CDRs) of a subscription instance, it is determined that an interruption anomaly exists. Interruption anomalies may be caused by system failures, data loss, errors in business rules, etc. Determining whether there are unsubscriptions and / or suspensions is to distinguish between normal business behavior and abnormal situations. For example, if a subscription instance stops billing due to a user's voluntary suspension, the CDR interruption in this case is reasonable and should not be considered abnormal. If no suspension record is found, further analysis is needed to determine if the interruption was caused by other problems.

[0042] For each order instance, the call details records (CDRs) of that order instance are sorted in chronological order. If a preset condition is met, the CDRs are considered to be consecutive. If the preset condition is not met, further drill-down analysis is required. The preset condition is that the time interval between the start time of the next CDR and the end time of the previous CDR, or the time interval between the end time of the previous CDR, is less than a preset value. The preset value can be 0 seconds, 1 second, or other times. This application embodiment does not limit this.

[0043] In this embodiment of the application, the data collected by the product side refers to the information related to the subscription instance collected within the product system, such as usage and tariff configuration; the data collected by the MOP refers to the operation records, status changes, and other content related to the subscription instance collected by the MOP; the metering data reflects the actual resource usage data, such as CPU usage, storage capacity, and network traffic; and the call detail record data is the standard billing record generated by the billing system, which includes fields such as usage start and end time, usage, and cost.

[0044] In this embodiment, the various data sources contained in the first information complement each other, and the system can achieve a comprehensive location of the root cause of the interruption based on these data sources, thereby improving the accuracy of problem diagnosis.

[0045] For example, when comparing data collected by the product side and the MOP (Metrology, Opportunity, and Platform): if they are inconsistent, an anomaly is recorded and the estimated impact amount is calculated. For products with metering files: when comparing metering data with call detail record (CDR) data, if the metering data is normal but there is no corresponding CDR data, an anomaly is recorded and the estimated impact amount is calculated. Anomaly scenarios and causes may be as follows: a) Metering data is normal, but there is no corresponding CDR data. If the product side and MOP data are consistent, there is a possibility that fewer CDRs were generated, affecting the product's CDRs; b) Metering data is normal, but there is no corresponding CDR data. If the product side and MOP data are inconsistent, and the MOP missed collecting the data, there is a possibility that fewer metering data were generated or the MOP missed collecting CDRs, affecting the product's CDRs; c) Metering data and CDR data are consistent. If the product side and MOP data are consistent, there is a possibility that metering data is missing, affecting the product's metering files. For products without metering files, if the product side and MOP data are consistent, there may be a problem of fewer CDRs generated by the product side; if they are inconsistent, the MOP missed collecting CDRs, requiring further investigation and analysis by the MOP.

[0046] In this embodiment of the application, by combining the multi-dimensional information contained in the first information for analysis, the system can effectively identify the cause of abnormal interruption, avoid misjudging reasonable behavior as abnormal, and at the same time, the system can promptly discover potential problems and implement corresponding corrective measures.

[0047] In this embodiment, cross-tabulation refers to the overlap of time ranges between multiple call detail records (CDRs) under the same subscription instance; that is, the usage period of one CDR partially or completely overlaps with the time period of another CDR. The presence of cross-tabulation usually indicates potential issues such as duplicate billing, data errors, or system logic defects. Handling cross-tabulation helps prevent revenue loss and reduce customer complaints.

[0048] The presence of duplicate call records (CDRs) is a particularly important indicator, used to determine whether duplicate CDRs have occurred. Duplicate CDRs can lead to duplicate billing, which in turn can cause customer disputes or financial losses. By checking for duplicate CDRs, it's possible to preliminarily determine whether cross-cutting anomalies are caused by duplicate billing.

[0049] In this embodiment, for products with metering documents, the system automatically detects whether the time periods of all call detail records (CDRs) under the same subscription instance overlap, and compares and analyzes the metering data and CDR data. For example, a) if CDRs are duplicated and the metering data is less than the CDR data, there is an issue of excessive CDR generation due to excessive metering data, affecting the product's CDR business; b) if CDRs are not duplicated but the metering data is less than the CDR data, there is an issue of excessive CDR generation due to excessive metering data, affecting the product's CDR business; c) if CDRs are not duplicated and the metering data is consistent with the CDR data, there is an issue of excessive metering data collection, affecting the product's metering document business. For products without metering documents, if CDRs are duplicated, an anomaly is recorded and the business object is analyzed. If CDRs are not duplicated, there may be an issue of multiple CDRs being generated at the same time under the same subscription instance and billing scenario.

[0050] By performing cross-anomaly analysis based on secondary information, abnormal call detail records (CDRs) can be quickly identified and their causes accurately determined, thereby enabling effective control of billing risks.

[0051] In this embodiment, by introducing interruption and cross-exception handling mechanisms, the accuracy and stability of call detail record (CDR) processing can be further improved. These mechanisms enable the timely detection and categorization of various anomalies, thereby reducing revenue loss due to abnormal CDRs, optimizing the overall operational efficiency of the billing system, and enhancing user experience and operator management.

[0052] In this embodiment of the application, the method further includes: Monitor the billing amount of the third subscription instance; the third subscription instance is a pay-as-you-go subscription instance with a non-zero fee. If the bill amount remains unchanged for N consecutive days, then the third order instance is determined to have an abnormal pricing; where N is a positive integer. Based on the fourth information, the reason for the abnormal pricing of the third order instance is determined; the fourth information includes one or more of the following: data collected from the product side, data collected from the MOP, metering data, and call detail record data.

[0053] In this embodiment of the application, pay-as-you-go billing for non-zero-cost services refers to a billing model where users pay based on actual usage (such as resource consumption and service call volume). Cloud servers, bandwidth, databases, and other resources typically use this pay-as-you-go billing method.

[0054] In this embodiment, the third subscription instance specifically refers to a resource instance that is in a valid state and billed according to the above billing method. By continuously monitoring the billing amount of the third subscription instance, the system can promptly detect abnormal fluctuations or stagnations in the billing process, and can provide early warnings of potential revenue loss risks.

[0055] Billing anomalies refer to situations where, during the normal billing process, a subscription instance fails to incur charges as they should, or the charges remain unchanged for an extended period. Billing anomalies indicate that the billing system has failed to correctly execute billing rules, or that metering data has not been collected correctly. A threshold setting for identifying anomalies is N consecutive days without change; the specific number of days can be set based on historical data and business scenarios. For example, for certain high-value resource instances, N can be set to 7 days; for low-frequency resource instances, N can be set to 15 days. This application embodiment does not impose such limitations. By setting a reasonable time window, the system can identify subscription instances that appear normal but may actually have billing issues, thereby triggering further root cause analysis.

[0056] If the MOP fails to collect call detail records (CDRs) for the ordered instance, the system will coordinate with the product side and the MOP to ensure CDR balance. It will check if the CDRs uploaded by the product side are consistent with those collected by the MOP. If they are inconsistent (i.e., the product side uploads CDRs from the most recent N days, but the MOP does not collect them), an anomaly will be recorded, and the estimated impact amount will be calculated. Similarly, the system will coordinate with the consistency control of metering data and CDR data. It will check if the metering data and CDR data are consistent. If they are inconsistent (i.e., metering data exists, but there is no corresponding CDR data), an anomaly will be recorded, and the estimated impact amount will be calculated. The corresponding scenarios are as follows: Scenario 1: Metering data exists but there is no corresponding call detail record (CDR) data. The product side uploads CDRs but the MOP does not collect them. There are no pricing results for the ordered instance for N consecutive days. This may be due to insufficient metering data generation or the MOP not collecting CDRs. The business object involved is product CDRs. Work order generated: Estimated underpayment amount is XX yuan. Affected product: Cloud server. Affected customer: Customer A. Please have the xx product department investigate and analyze.

[0057] Scenario 2: Metering data is missing, and the product side has not uploaded call detail records. The ordered instance has had no pricing results for N consecutive days, indicating missing metering data. This may involve the product metering file. Work order generated: Estimated underpayment amount is XX yuan, affecting product: cloud server, affecting customer: customer A. Please have the xx product department investigate and analyze.

[0058] Scenario 3: Metering data exists but there is no corresponding call detail record (CDR) data, and the product side has not uploaded the CDRs. The ordered instance has not received any pricing results for N consecutive days. There may be an issue of insufficient CDR generation due to insufficient metering data. This involves the business object product CDRs. Work order generated: Estimated shortfall amount is XX yuan. Affected product: Cloud server. Affected customer: Customer A. Please have the xx product department investigate and analyze.

[0059] If the MOP collects a subscription instance's call detail record (CDR), it coordinates with EBOSS and EOSS to preprocess the CDRs and ensure CDR volume balance control. It checks if EBOSS has processed the CDR for that subscription instance based on the CDR filename. If EBOSS hasn't processed it, it records an anomaly. If EBOSS has processed it, it performs analysis. If the CDR is judged as an erroneous by EBOSS, it triggers root cause analysis to check if the CDR is normal and if EBOSS's judgment is correct. If EBOSS's judgment is correct, it records an anomaly of "long-term lack of pricing approval" and extracts the initial judgment conclusion. If EBOSS's judgment is incorrect, it extracts the initial judgment conclusion and records an anomaly of "long-term lack of pricing approval." If the CDR is not judged as an erroneous by EBOSS, it is recorded as an anomaly. The corresponding scenarios are as follows: Scenario 1: Call detail records (CDRs) are collected by MOP but not processed by EBOSS. The order instance has no pricing results for N consecutive days, which may involve product CDRs. Work order generated: Estimated shortfall of XX yuan, affected customer: Customer A, affected product: Product A. Please investigate and analyze with EBOSS.

[0060] Scenario 2: EBOSS has processed the call detail record (CDR) and determined it to be an incorrect order, and the logic is correct. The order instance has not received a pricing result for N consecutive days, which may involve business objects (business objects extracted from the root cause analysis of the linked problematic CDRs); a work order is generated: estimated shortfall of XX yuan, affecting customer: customer A, affecting product: product A, please have the XX product department investigate and analyze.

[0061] Scenario 3: EBOSS has processed the call detail record (CDR) and judged it as an incorrect order, but there is a logical error. The order instance has not received a pricing result for N consecutive days, which may involve business objects (business objects extracted from the root cause analysis of the linked problematic CDRs); a work order is generated: the estimated amount shortfall is XX yuan, affecting customer: customer A, affecting product: product A. Please check and analyze with EBOSS.

[0062] Scenario 4: EBOSS has processed the call detail record (CDR) and not marked it as an error. The order instance has not received a pricing result for N consecutive days, which may involve business objects (to be further analyzed by the EBOSS department); a work order has been generated: the estimated amount shortfall is XX yuan, affecting customer A and product A. Please investigate and analyze with EBOSS.

[0063] This embodiment introduces a billing amount monitoring mechanism for pay-as-you-go subscriptions that are not zero-cost, and combines this with multi-dimensional data analysis to achieve early identification and rapid response to billing anomalies. Through this method, this embodiment can effectively avoid the risk of revenue loss, thereby improving the stability and reliability of the billing system, and ultimately providing enterprises with more accurate and efficient service guarantees.

[0064] In this embodiment of the application, the method further includes: If an abnormal call detail record (CDR) is found, the cause of the abnormality shall be determined; the cause of the abnormality includes: file abnormality and / or incorrect call detail record. If the cause of the abnormality is a file abnormality, determine the cause of the file abnormality; the cause of the file abnormality includes one or more of the following: garbled file content, missing file content, file content not conforming to call detail record specifications; If the cause of the error is a wrong order, then the cause of the wrong order error is determined based on the type of wrong order.

[0065] In this embodiment of the application, abnormal call detail records (CDRs) refer to CDR data that is identified in the billing system as non-compliant, formatted incorrectly, duplicated, missing, or otherwise abnormal. Abnormal CDRs may affect the accuracy of billing, thereby causing the risk of revenue loss.

[0066] When the system detects abnormal call detail records (CDRs), it triggers a root cause analysis process to determine the underlying cause of the anomaly and takes appropriate corrective or remedial measures based on the analysis results. For example, in communication services, if a CDR record shows that a user has used services outside the subscription scope, and the timestamp of the CDR is outside the subscription validity period, the system will classify this CDR as abnormal. By promptly identifying and locating the cause of abnormal CDRs, the system can reduce the false positive rate, improve problem-solving efficiency, and reduce manual intervention costs.

[0067] File anomalies refer to abnormal situations caused by problems with the content, structure, or integrity of the call detail record (CDR) file itself, such as garbled characters, missing fields, inconsistent formats, etc.; while incorrect CDRs refer to logical errors in the CDR content, such as the CDR start time being earlier than the subscription effective time, the end time being later than the subscription expiration time, incorrect tariff parameters, etc.

[0068] These two types of anomalies have different manifestations and impacts, and therefore need to be handled separately. For example, file anomalies typically affect the overall parsing and reading of multiple call detail records (CDRs), while incorrect CDRs may only affect the billing results of individual CDRs.

[0069] Classifying the causes of anomalies helps the system execute subsequent processing logic more accurately, avoiding resource waste and invalid operations.

[0070] Garbled text in file content refers to errors in character encoding or format in the file, making it impossible to parse the file content correctly; missing file content refers to some fields being blank or having empty field values, making the call detail record (CDR) unable to meet the minimum necessary information requirements; file content not conforming to CDR specifications refers to inconsistencies in the number, order, length, type, etc. of fields with the specified format, causing the system to be unable to read or process it normally.

[0071] In this embodiment, for file anomalies, the system checks for garbled characters or corrupted files that cannot be opened. If so, a work order is generated: "Abnormal file XXX cannot be opened / garbled characters. The problem may involve the product call detail record (CDR). Please have the XX product department investigate and analyze." If the file can be opened and is not garbled, the system links to the CDR file content compliance control, checking whether the CDR record conforms to the CDR specification. If anomalies are found (the number of fields in the CDR file is not equal to the number of fields specified in the CDR file specification / a field in the CDR exceeds the specification length / a required field in the CDR is empty), the initial judgment is: the abnormal file content does not conform to the CDR specification. The reason for the anomaly is the initial judgment extracted from the linked CDR file content compliance control. It should be noted that if the corresponding original CDR... If the root cause has been maintained, then the root cause information of the problematic call detail record (CDR) generated by this control point will be filled in, and no work order will be generated again. If the corresponding original CDR has not maintained a root cause, then the control point will generate a work order normally. If there are no abnormalities in the compliance control of the linked CDR file content, then the abnormality in the root cause analysis of the problematic CDR will be recorded. The initial judgment is: the abnormal file is judged incorrectly. The file can be opened normally and conforms to the CDR specification. There is a possibility that EBOSS is judging incorrectly. The problem may involve a product CDR business object. Generate a work order: The estimated under-collection amount is XX yuan. Affected customer: Customer A. Affected product: Product A. Please check and analyze with EBOSS. It should be noted that after EBOSS verification, if it considers the abnormal file to be normal, this scenario needs to be added to the control rules.

[0072] In this embodiment of the application, the error order is analyzed in detail according to the error order type. Please refer to Table 1, which is a schematic table of error order types provided in this embodiment of the application.

[0073]

[0074] Table 1 For calls not marked "E2415 Overdue Call Detail Records," the system links call detail record dependency data, call detail record data, and order data consistency control, as well as call detail record file content compliance control. If no control anomalies are found, further analysis is performed: If the error code is E2414 or E2322, it is necessary to further check whether the customer status and account status are suspended / pre-cancelled / cancelled. If the statuses match, EBOSS judges the error as normal, and records the anomaly as a discrepancy between the basic password account status and the order instance status. If the statuses do not match, the call detail record is normal, EBOSS judges the error, and the estimated undercharged amount is calculated. If the error code is not E2414 or E2322, the call detail record is normal, EBOSS judges the error, and the estimated undercharged amount is calculated. The calculation method is shown in the calculation rules in Table 1.

[0075] If an anomaly exists, and if only the anomaly that does not correspond to the error code exists, then EBOSS will judge it as an error, but the error code is incorrect; and all preliminary judgment conclusions of the call detail record (CDR) anomaly will be extracted; if there are both anomalies that correspond to the error code and anomalies that do not correspond to the error code, then EBOSS will judge it as an error, the error code is correct, and all preliminary judgment conclusions of the CDR anomaly will be extracted.

[0076] For “E2415 Overdue Call Detail Record”, check if the order instance in the erroneous order was effective when the pricing was approved. If it is still effective, compare the EBOSS pricing with the start time of the call detail record usage to see if it exceeds 60 days. If it exceeds 60 days, EBOSS will judge the erroneous order as normal; if it does not exceed 60 days, it will be recorded as abnormal, and the estimated impact amount will be calculated. If it has expired, compare the EBOSS pricing with the start time of the call detail record usage to see if it exceeds 30 days. If it exceeds 30 days, EBOSS will judge the erroneous order as normal; if it does not exceed 30 days, it will be recorded as abnormal, and the estimated impact amount will be calculated. The calculation method is as shown in the calculation rules in Table 1.

[0077] In this embodiment of the application, the method further includes: A work order is generated based on the first abnormal reason; the work order includes one or more of the following information: the amount affected, the affected customer, the affected product, and the first department; the first department is the department related to the first abnormal reason; the first abnormal reason includes one or more of the following abnormal reasons: fluctuation abnormal reason, interruption abnormal reason, cross-exchange abnormal reason, batch pricing abnormal reason, document abnormal reason, and wrong order abnormal reason; The work order is sent to the first department.

[0078] In this application embodiment, the first abnormal cause refers to a specific type of problem that may lead to revenue loss or other business risks in the call detail record (CDR) billing process. The fluctuation abnormal cause refers to a phenomenon where CDR usage deviates significantly from the historical normal range within a certain time period. The interruption abnormal cause refers to a situation where a subscription instance experiences missing CDRs when they should be generated continuously. The overlap abnormal cause refers to a situation where the time periods of multiple CDRs under the same subscription instance overlap. The batch pricing abnormal cause refers to a situation where the billing system fails to correctly execute the billing rules, resulting in billing errors. The file abnormal cause refers to an uploaded CDR file having non-standard formatting, missing fields, etc. The incorrect call detail record (CDR) abnormal cause refers to a situation where the system misjudges the validity of a CDR, marking a normal CDR as invalid or treating an invalid CDR as valid.

[0079] In this embodiment, a work order is a mechanism for recording and tracking abnormal events and assigning them to relevant responsible departments for handling. The work order includes a description of the abnormal event, an impact assessment, and handling suggestions to ensure that abnormal events can be identified and resolved in a timely manner. In this embodiment, the work order includes four key pieces of information: In this embodiment, the selection of the first department is based on the nature of the first anomaly cause. According to the nature of the first anomaly cause, the work order is assigned to the most suitable department. The system can automatically assign work orders to the most appropriate personnel, improving problem response efficiency.

[0080] refer to Figure 2 , Figure 2 This is a flowchart illustrating the call detail record (CDR) control method provided in the embodiments of this application, as shown below. Figure 2 As shown, it includes the following steps: Step 201: Obtain the latest call detail records (CDRs) and error call data through the big data platform's FTP service; and synchronize order data in real time through the database.

[0081] During the data acquisition phase, the system periodically polls the operator's or business system for the latest call detail record (CDR) files and error logs via the big data platform's FTP service, automatically downloading and parsing this raw data to ensure its integrity and timeliness. Simultaneously, the system obtains real-time user subscription information from the core business system through a real-time database synchronization mechanism (such as Change Data Capture, CDC), including key operation records such as package changes and service activation / cancellation. This process ensures the consistency between CDR data and the user's actual business status, providing an accurate data foundation for subsequent risk identification and problematic CDR analysis, effectively supporting the accurate judgment of abnormal usage behavior, billing discrepancies, and other issues.

[0082] Step 202: The system performs prevention and control tasks, identifies problematic call records, packages the problematic call records and generates work orders, and transfers them to relevant departments for processing.

[0083] The abnormal call detail record (CDR) processing method provided in this application involves multi-dimensional analysis of CDR data during the prevention and control task execution phase. This analysis identifies CDRs with potential issues such as billing errors, formatting errors, duplicate reporting, and unauthorized use. The identified problematic CDRs are categorized, tagged, and packaged into structured work orders, including problem descriptions, impact scope, and preliminary root cause predictions. Work orders are automatically dispatched to the appropriate responsible departments (such as billing centers, network operations and maintenance, and customer service) via a workflow engine, triggering processing reminders and tracking mechanisms to ensure timely problem response, forming a closed-loop management system, and improving problem handling efficiency and system autonomy.

[0084] Step 203: The relevant departments receive and process the work orders, close the processed work orders, update the root cause records based on the processing results, and optimize the prevention and control strategies.

[0085] After receiving a work order from the system, relevant departments conduct verification and processing based on its content. This includes contacting the user for confirmation, checking system configurations, correcting billing data, or adjusting business processes. Once processing is complete, staff close the work order in the system and fill in detailed information about the processing procedure and the final confirmed root cause. Based on this feedback, the system continuously builds a root cause knowledge base and uses data analysis to optimize existing prevention and control rules and identification models, such as adjusting thresholds, adding new detection rules, or improving algorithm strategies. This closed-loop mechanism not only improves the transparency and traceability of problem handling but also enables the dynamic evolution and intelligent upgrading of the prevention and control system.

[0086] The abnormal work order handling method provided in this application adopts advanced automated monitoring technology to achieve real-time monitoring of the entire process of call order generation, transmission, pricing, and feedback, ensuring no monitoring blind spots and timely detection and handling of potential problems; it designs and implements an automated review process to reduce manual intervention, standardizes call order data processing through preset rules and processes, and reduces the possibility of human error and disputes; it automatically triggers corresponding processing procedures for monitored abnormal behaviors, shortening the time from problem discovery to resolution and reducing losses; and it establishes a cross-departmental collaboration mechanism based on a cloud platform, simplifying collaboration processes and improving inter-departmental communication and collaboration efficiency by sharing workflows and information, thereby shortening the problem resolution cycle.

[0087] This application also provides an abnormal call detail record (CDR) processing device, see reference. Figure 3 , Figure 3 This is a schematic diagram of the abnormal call detail record (CDR) processing device provided in an embodiment of this application. The abnormal CDR processing device in this embodiment includes: The call detail record (CDR) generation and control processing module is used to obtain the tariffs of valid subscription instances within the current control period. The call detail record generation and control processing module is used to summarize the call detail record usage corresponding to the tariff based on the subscription relationship code. The call detail record (CDR) generation flow control processing module is used to determine that the tariff is an abnormal fluctuation tariff if the CDR usage is not within a preset fluctuation range, and to analyze the abnormal fluctuation tariff to determine the cause of the fluctuation.

[0088] In this embodiment of the application, the call detail record (CDR) generation flow control processing module is used to determine that the CDR usage is abnormally increased if the CDR usage is higher than the maximum value of the preset fluctuation range, and to analyze the reasons for the abnormal increase in CDR usage to determine the cause of the fluctuation abnormality; if the CDR usage is lower than the minimum value of the preset fluctuation range, it is determined that the CDR usage is abnormally decreased, and to analyze the reasons for the abnormal decrease in CDR usage to determine the cause of the fluctuation abnormality.

[0089] In this embodiment of the application, the call detail record (CDR) generation flow control processing module is used to calculate the month-on-month change in CDR usage for a first subscription instance; the first subscription instance is a subscription instance that is valid in both the previous control period and the current control period; calculate the month-on-month change in CDR usage for the fluctuating abnormal tariff; based on the month-on-month change in CDR usage for the first subscription instance and the month-on-month change in CDR usage for the fluctuating abnormal tariff, determine whether the abnormal increase in CDR usage is caused by a new subscription; if it is determined that the abnormal increase in CDR usage is caused by a new subscription, then the cause of the fluctuation abnormality is determined to be a new subscription; if it is determined that the abnormal increase in CDR usage is not caused by a new subscription, then calculate the month-on-month change in CDR usage for each first subscription instance; based on the month-on-month change in CDR usage for each first subscription instance, determine the abnormal first subscription instance; determine whether the metering file of the abnormal first subscription instance is abnormal; if the metering file of the abnormal first subscription instance is abnormal, then the cause of the fluctuation abnormality is determined to be the abnormal metering file of the abnormal first subscription instance; and / or, In this embodiment, the call detail record (CDR) generation flow control processing module is used to calculate the month-on-month change in CDR usage for the second subscription instance; the second subscription instance is a subscription instance that is valid in both the previous control period and the current control period; calculate the month-on-month change in CDR usage for the abnormally fluctuating tariff; based on the month-on-month change in CDR usage for the second subscription instance and the month-on-month change in CDR usage for the abnormally fluctuating tariff, determine whether the abnormal decrease in CDR usage is caused by user unsubscription; if it is determined that the abnormal decrease in CDR usage is caused by user unsubscription, then the cause of the fluctuation anomaly is determined to be user unsubscription; if it is determined that the abnormal decrease in CDR usage is not caused by user unsubscription, then calculate the month-on-month change in CDR usage for each second subscription instance; based on the month-on-month change in CDR usage for each second subscription instance, determine the abnormal second subscription instance; determine whether the metering file of the abnormal second subscription instance is abnormal; if the metering file of the abnormal second subscription instance is abnormal, then the cause of the fluctuation anomaly is determined to be the abnormal metering file of the abnormal second subscription instance.

[0090] In this embodiment of the application, the call detail record (CDR) generation flow control processing module is used to determine whether the ordering instance has been unsubscribed and / or suspended if there is an interruption anomaly among multiple CDRs of the ordering instance; if there is an unsubscription and / or suspension, the interruption is determined to be a normal interruption; if there is no unsubscription and / or suspension, the cause of the interruption anomaly is analyzed based on first information; the first information includes one or more of the following: data collected by the product side, data collected by the MOP, metering data, and CDR data; and / or, if there is a cross-anomaly among multiple CDRs of the ordering instance, the cause of the cross-anomaly is analyzed based on second information; the second information includes one or more of the following: third information, metering data, and CDR data; the third information indicates whether there are duplicate orders.

[0091] In this embodiment of the application, the abnormal call detail record (CDR) processing device further includes: a batch pricing flow control processing module, used to monitor the bill amount of a third subscription instance; the third subscription instance is a pay-as-you-go subscription instance with a non-zero-cost fee; if the bill amount remains unchanged for N consecutive days, it is determined that the third subscription instance has a batch pricing anomaly; N is a positive integer; based on fourth information, the reason for the batch pricing anomaly of the third subscription instance is determined; the fourth information includes one or more of the following: data collected by the product side, data collected by the MOP, metering data, and call detail record (CDR) data.

[0092] In this embodiment of the application, the abnormal call detail record (CDR) processing device further includes: a fallback flow prevention and control processing module, used to determine the cause of the abnormal CDR if an abnormal CDR is detected; the cause of the abnormality includes: file abnormality and / or erroneous CDR; if the cause of the abnormality is file abnormality, the cause of file abnormality is determined; the cause of file abnormality includes one or more of the following: garbled file content, missing file content, file content not conforming to CDR specifications; if the cause of the abnormality is erroneous CDR, the cause of erroneous CDR is determined based on the erroneous CDR type.

[0093] In this embodiment of the application, the abnormal call detail record (CDR) processing device further includes: a generation module: used to generate a work order based on a first abnormal reason; the work order includes one or more of the following information: affected amount, affected customer, affected product, and a first department; the first department is a department related to the first abnormal reason; the first abnormal reason includes one or more of the following abnormal reasons: fluctuation abnormal reason, interruption abnormal reason, cross-exchange abnormal reason, batch pricing abnormal reason, document abnormal reason, and incorrect order abnormal reason; and the work order is sent to the first department.

[0094] Those skilled in the art should understand that Figure 3 The functions of each module in the abnormal call detail record processing device shown can be understood by referring to the relevant descriptions of the aforementioned methods. Figure 3The functions of each module in the abnormal call detail record processing device shown can be implemented by a program running on the processor or by specific logic circuits.

[0095] Figure 4 This is a schematic structural diagram of an electronic device provided in an embodiment of this application. Figure 4 The electronic device shown includes a processor 410, which can call and run computer programs from memory to implement the abnormal call detail record processing method provided in the embodiments of this application.

[0096] Optionally, such as Figure 4 As shown, the electronic device may also include a memory 420. The processor 410 can retrieve and run computer programs from the memory 420 to implement the abnormal call detail record (CDR) processing method provided in this embodiment.

[0097] The memory 420 can be a separate device independent of the processor 410, or it can be integrated into the processor 410.

[0098] Optionally, such as Figure 4 As shown, the electronic device may also include a transceiver 430, which the processor 410 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0099] The transceiver 430 may include a transmitter and a receiver. The transceiver 430 may further include an antenna, and the number of antennas may be one or more.

[0100] The electronic device can implement the corresponding processes of the abnormal call detail record processing device in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0101] For example, embodiments of this application also provide a computer program product, including a computer program that can be executed by a processor 410 of an electronic device to perform the steps described in any of the foregoing methods.

[0102] Figure 5 This is a schematic structural diagram of the chip according to an embodiment of this application. Figure 5 The chip shown includes a processor 510, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0103] Optionally, such as Figure 5 As shown, the chip may also include a memory 520. The processor 510 can retrieve and run computer programs from the memory 520 to implement the methods described in this embodiment.

[0104] The memory 520 can be a separate device independent of the processor 510, or it can be integrated into the processor 510.

[0105] Optionally, the chip may also include an input interface 530. The processor 510 can control the input interface 530 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0106] Optionally, the chip may also include an output interface 540. The processor 510 can control the output interface 540 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0107] This chip can be applied to the electronic devices in the embodiments of this application, and the chip can implement the corresponding processes implemented by the electronic devices in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0108] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0109] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0110] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0111] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0112] This application also provides a storage medium for storing a computer program. This storage medium can be applied to the electronic device in this application embodiment, and the computer program causes the computer to execute the corresponding processes implemented by the electronic device in the various methods of this application embodiment; for brevity, further details are omitted here.

[0113] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0114] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

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

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

[0118] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or electronic device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0119] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for handling abnormal call detail records, characterized in that, include: Get the pricing for valid subscription instances within the current prevention and control period; Based on the subscription relationship code, summarize the call detail record usage corresponding to the aforementioned tariff; If the call detail record (CDR) usage is not within the preset fluctuation range, the tariff is determined to be an abnormal fluctuation tariff, and the abnormal fluctuation tariff is analyzed to determine the cause of the abnormal fluctuation.

2. The method according to claim 1, characterized in that, The analysis of the abnormal tariff fluctuations to determine the cause of the fluctuations includes: If the call detail record (CDR) usage is higher than the maximum value of the preset fluctuation range, it is determined that the CDR usage has increased abnormally. The reasons for the abnormal increase in CDR usage are analyzed to determine the cause of the abnormal fluctuation. If the call detail record (CDR) usage is lower than the minimum value of the preset fluctuation range, it is determined that the CDR usage has decreased abnormally. The reasons for the abnormal decrease in CDR usage are then analyzed to determine the cause of the abnormal fluctuation.

3. The method according to claim 2, characterized in that, The analysis of the reasons for the abnormal increase in call detail record (CDR) usage includes: Calculate the month-on-month change in call detail record (CDR) usage for the first subscription instance; the first subscription instance is a subscription instance that is valid in both the previous prevention and control period and the current prevention and control period; calculate the month-on-month change in CDR usage for the abnormally fluctuating tariff; based on the month-on-month change in CDR usage for the first subscription instance and the month-on-month change in CDR usage for the abnormally fluctuating tariff, determine whether the abnormal increase in CDR usage is caused by a new subscription; If it is determined that the abnormal increase in call usage is caused by new orders, then the cause of the abnormal fluctuation is determined to be new orders. If it is determined that the abnormal increase in call order usage is not due to new orders, then calculate the month-on-month change in call order volume for each first order instance; based on the month-on-month change in call order volume for each first order instance, identify the abnormal first order instance; determine whether the metering file of the abnormal first order instance is abnormal; if the metering file of the abnormal first order instance is abnormal, then determine that the cause of the fluctuation abnormality is the abnormal metering file of the abnormal first order instance; and / or, The analysis of the reasons for the abnormal decrease in call detail record (CDR) usage includes: Calculate the month-on-month change in call detail record (CDR) usage for the second subscription instance; the second subscription instance is a subscription instance that is valid in both the previous prevention and control period and the current prevention and control period; calculate the month-on-month change in CDR usage for the abnormally fluctuating tariff; based on the month-on-month change in CDR usage for the second subscription instance and the month-on-month change in CDR usage for the abnormally fluctuating tariff, determine whether the abnormal decrease in CDR usage is caused by user unsubscription; If it is determined that the abnormal decrease in call usage is caused by user unsubscription, then the abnormal fluctuation is determined to be caused by user unsubscription. If it is determined that the abnormal decrease in call order usage is not caused by user unsubscription, then calculate the month-on-month change in call order volume for each second order instance; based on the month-on-month change in call order volume for each second order instance, identify the abnormal second order instance; determine whether the metering file of the abnormal second order instance is abnormal; if the metering file of the abnormal second order instance is abnormal, then determine that the cause of the fluctuation abnormality is the abnormal metering file of the abnormal second order instance.

4. The method according to claim 1, characterized in that, The method further includes: If there are interruption anomalies among multiple call detail records (CDRs) of the subscription instance, it is determined whether the subscription instance has been unsubscribed and / or suspended; if there are unsubscribed and / or suspended, the interruption is determined to be a normal interruption; if there are no unsubscribed and / or suspended, the cause of the interruption anomaly is analyzed based on the first information; the first information includes one or more of the following: data collected by the product side, data collected by MOP, metering data, call detail record data; and / or, If there are cross-abnormalities among multiple call detail records (CDRs) of the order instance, the cause of the cross-abnormality is analyzed based on the second information; the second information includes one or more of the following: third information, metering data, and CDR data; the third information indicates whether there are duplicate orders.

5. The method according to claim 1, characterized in that, Also includes: Monitor the billing amount of the third-party order instance; The third order instance is a pay-as-you-go order instance with a non-zero cost. If the bill amount remains unchanged for N consecutive days, then the third order instance is determined to have an abnormal pricing. N is a positive integer; Based on the fourth information, the reason for the abnormal pricing of the third order instance is determined; the fourth information includes one or more of the following: data collected from the product side, data collected from the MOP, metering data, and call detail record data.

6. The method according to claim 1, characterized in that, Also includes: If abnormal call detail records are found, determine the cause of the abnormality. The reasons for the anomalies include: file anomalies and / or order errors; If the cause of the abnormality is a file abnormality, determine the cause of the file abnormality; the cause of the file abnormality includes one or more of the following: garbled file content, missing file content, file content not conforming to call detail record specifications; If the cause of the error is a wrong order, then the cause of the wrong order error is determined based on the type of wrong order.

7. The method according to any one of claims 1 to 7, characterized in that, The method further includes: A work order is generated based on the first abnormal reason; the work order includes one or more of the following information: the amount affected, the affected customer, the affected product, and the first department; the first department is the department related to the first abnormal reason; the first abnormal reason includes one or more of the following abnormal reasons: fluctuation abnormal reason, interruption abnormal reason, cross-exchange abnormal reason, batch pricing abnormal reason, document abnormal reason, and wrong order abnormal reason; The work order is sent to the first department.

8. An abnormal call detail record (CDR) processing device, characterized in that, include: The call detail record (CDR) generation and control processing module is used to obtain the tariffs of valid subscription instances within the current control period. The call detail record generation and control processing module is used to summarize the call detail record usage corresponding to the tariff based on the subscription relationship code. The call detail record (CDR) generation flow control processing module is used to determine that the tariff is an abnormal fluctuation tariff if the CDR usage is not within a preset fluctuation range, and to analyze the abnormal fluctuation tariff to determine the cause of the fluctuation.

9. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to perform the abnormal call detail record processing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, Used to store a computer program that causes a computer to perform the abnormal call detail record (CDR) processing method as described in any one of claims 1 to 7.

Images