Early warning method and device based on charging ticket file, equipment and medium

Abstract

The embodiment of the invention provides an early warning method and device based on a charging ticket file, equipment and a medium, and the method comprises the steps: obtaining a charging ticket file generated by a service type, and obtaining a first weight attribute of a processing module; for the service type, the first weight attribute is adjusted according to processing data generated in the processing process of a charging ticket file associated with the service type through a processing module, and a second weight attribute is obtained; and according to the first weight attribute and the second weight attribute, determining a weight attribute fluctuation ratio, and when the weight attribute fluctuation ratio exceeds a first preset threshold, triggering an early warning mechanism corresponding to the service type. According to the technical scheme provided by the embodiment of the invention, whether the early warning mechanism corresponding to the service type is triggered or not is determined based on the processing data generated in the processing process of the charging ticket file associated with the service type through the processing module, so that the problem of the charging ticket file in the module can be quickly positioned, the risk of missing receiving is effectively found and reduced, and the efficiency of increasing the receiving is improved.

Description

Technical Field

[0001] This disclosure relates to the field of telecommunications technology, and in particular to an early warning method, apparatus, device, and medium based on billing call detail records (CDRs). Background Technology

[0002] Billing call detail records (CDRs) are collected from various network elements and sent to the billing host. These CDRs undergo processing by multiple modules. Due to the massive volume of CDRs collected daily, some may be lost during processing and analysis. Therefore, it is necessary to audit and correct missing CDRs from the data collected from network elements and stored in the database to reduce missed CDR transmissions within modules and achieve the goal of value-added revenue collection.

[0003] The existing methods for auditing billing call detail records (CDRs) mainly involve manual analysis triggered when external feedback indicates a decrease in revenue or other anomalies. This approach suffers from issues such as delayed response, high labor costs, and low accuracy. Summary of the Invention

[0004] This disclosure provides an early warning method, apparatus, device, and medium based on billing call detail records (CDRs) files, which can quickly locate problems in the CDR files within modules, thereby effectively identifying and reducing the risk of missed collections and improving revenue generation efficiency.

[0005] In a first aspect, embodiments of this disclosure provide an early warning method based on billing call detail records (CDRs), the method comprising:

[0006] Obtain billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtain the first weight attribute of at least two processing modules that process the service type; wherein, the first weight attribute is a weight attribute determined based on the previous processing of billing CDRs generated within a historical time period.

[0007] For the at least one service type, based on the processing data generated during the processing of the billing call detail record file associated with the service type by the at least two processing modules, the first weight attribute of the at least two processing modules is adjusted to obtain the second weight attribute of the at least two processing modules;

[0008] Based on the first weight attribute and the second weight attribute, the weight attribute fluctuation ratio is determined, and when the weight attribute fluctuation ratio exceeds a first preset threshold, an early warning mechanism corresponding to the business type is triggered.

[0009] Secondly, embodiments of the present invention also provide an early warning device based on billing call detail records (CDRs), the device comprising:

[0010] The billing call detail record (CDR) file acquisition module is used to acquire CDR files generated by at least one service type within a preset time period, and to acquire first weight attributes of at least two processing modules that process the service type; wherein, the first weight attribute is a weight attribute determined based on the previous processing of CDR files generated within a historical time period.

[0011] The second weight attribute determination module is used to adjust the first weight attribute of the at least two processing modules based on the processing data generated during the processing of the billing call detail record file associated with the service type by the at least two processing modules, for the at least one service type, so as to obtain the second weight attribute of the at least two processing modules.

[0012] The early warning mechanism triggering module is used to determine the weight attribute fluctuation ratio based on the first weight attribute and the second weight attribute, and to trigger the early warning mechanism corresponding to the business type when the weight attribute fluctuation ratio exceeds a first preset threshold.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0014] One or more processors;

[0015] Storage device for storing one or more programs.

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the early warning method based on billing call detail records as described in any embodiment of the present invention.

[0017] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform an early warning method based on billing call detail records as described in any of the embodiments of the present invention.

[0018] Fifthly, embodiments of the present invention also provide a computer program product, including a computer program, characterized in that, when executed by a processor, the computer program implements the early warning method based on billing call detail records as described in any embodiment of the present invention.

[0019] The technical solution of this disclosure first obtains billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtains the first weight attributes of at least two processing modules that process the service type. Then, for at least one service type, based on the processing data generated during the processing of the billing CDRs associated with the service type by the at least two processing modules, the first weight attributes of the at least two processing modules are adjusted to obtain second weight attributes of the at least two processing modules. Finally, based on the first and second weight attributes, the weight attribute fluctuation ratio is determined, and when the weight attribute fluctuation ratio exceeds a first preset threshold, an early warning mechanism corresponding to the service type is triggered. This solves the problems of delayed response, high labor costs, and low accuracy in the prior art where manual analysis is triggered when external feedback indicates a decrease in revenue or other anomalies. This disclosure realizes the determination of whether to trigger an early warning mechanism corresponding to the service type based on the processing data generated during the processing of the billing CDRs associated with the service type by the processing modules. This can quickly locate problems in the billing CDRs within the modules, effectively discovering and reducing the risk of missed revenue collection and improving revenue growth efficiency. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of exemplary embodiments of the present invention, the accompanying drawings used in describing the embodiments are briefly introduced below. Obviously, the accompanying drawings described are only a portion of the drawings of the embodiments to be described in this invention, and not all of the drawings. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0021] Figure 1 This is a flowchart illustrating an early warning method based on billing call detail records provided in this embodiment of the present disclosure;

[0022] Figure 2 This is a flowchart illustrating an early warning method based on billing call detail records provided in this embodiment of the present disclosure;

[0023] Figure 3 This is a schematic diagram of the structure of an early warning device based on billing call detail records provided in an embodiment of this disclosure;

[0024] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0026] Before introducing the technical solutions provided by the embodiments of this disclosure, the application scenarios can be illustrated by example. The technical solutions provided by the embodiments of this disclosure can be applied to scenarios involving the auditing of billing call detail records (CDRs). Based on the technical solutions of the embodiments of this disclosure, the processing data generated during the processing of billing CDRs associated with service types by the processing module is used to determine whether an early warning mechanism corresponding to the service type is triggered. This can quickly locate problems in the billing CDRs within the module, effectively identifying and reducing the risk of missed collections and improving revenue generation efficiency.

[0027] Example 1

[0028] Figure 1 This is a flowchart illustrating an early warning method based on billing call detail records (CDRs) provided in this disclosure. This disclosure is applicable to situations where billing CDRs are audited. The method can be executed by an early warning device based on billing CDRs. This device can be implemented in the form of software and / or hardware. The hardware can be a mobile electronic device. This electronic device can execute the early warning method based on billing CDRs provided in this technical solution.

[0029] like Figure 1 As shown, the method includes:

[0030] S110. Obtain the billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtain the first weight attribute of at least two processing modules that process the service type.

[0031] The first weight attribute is determined based on the previous processing of billing call detail records generated within the historical time period.

[0032] The preset duration refers to the time period set for data statistics and analysis when processing billing call detail records (CDRs). In some cases, the business system can analyze generated CDRs by the hour. For example, it can retrieve CDRs generated by at least one service type between 9:00 AM and 10:00 AM. Service type refers to different categories of services or products in the telecommunications industry. Common service types include voice calls, SMS services, data services, and value-added services. A billing call detail record (CDR) is a file that records detailed information about a user's use of a particular service.

[0033] It should be noted that billing record files are typically obtained from network elements. Network elements refer to equipment in a telecommunications network, such as base stations, switches, or routers. Network elements are responsible for processing user communication requests and generating corresponding billing record files. The billing record files generated by network elements are the direct result of recording the services used by a user within a specific time period. Each network element records relevant information when processing user communications and periodically generates billing record files for subsequent analysis and billing. Furthermore, billing record files for different service types can be generated by different network elements.

[0034] It should be noted that the processing module refers to the various independent functional modules designed to achieve specific functions during the processing of billing call detail records (CDRs). The processing module is responsible for processing and analyzing CDRs of different service types. The processing module may include modules for data acquisition and transmission, CDR decoding, CDR pricing, CDR aggregation, and CDR storage. Data acquisition and transmission refers to collecting and transmitting real-time billing CDRs generated by network elements to the processing system; CDR decoding refers to parsing the data in the billing CDRs for subsequent processing; CDR pricing refers to calculating the billing results based on preset billing rules; CDR aggregation refers to summarizing the processed billing results for statistical analysis; and CDR storage refers to storing the summarized billing results in a database for later querying and analysis.

[0035] It should also be noted that "historical duration" refers to the time window used for backtracking statistics to calculate the first weighted attribute. The historical duration can be a continuous period of time traced back from a preset starting point. For example, the historical duration can be a 24-hour period traced back from the preset starting point. The weighted attribute determined after processing billing record files generated within the historical duration can be designated as the first weighted attribute. When processing billing record files, if a weighted attribute determined from a previous processing of billing record files generated within the historical duration exists, it can be inherited and used in the current processing. If no weighted attribute was determined from a previous processing of billing record files generated within the historical duration, the value of the first weighted attribute can be 0. This mechanism helps ensure the system can operate normally and process data even in the absence of historical data.

[0036] Specifically, billing record files can be categorized into several service types, including voice calls, SMS services, data services, and value-added services. For voice calls, the billing record file records detailed voice call information and can be further subdivided based on operator or device type. For SMS services, the billing record file records detailed SMS sending and receiving information and can be further subdivided based on SMS type or the network type of the sender and receiver. For data services, the billing record file records data traffic usage and can be further subdivided based on data service type or connection method. For value-added services, the billing record file records usage of value-added services, such as ringback tones or mobile games, and can be further subdivided based on different value-added service types. The system retrieves the billing record files generated after further subdivision of each service type within a preset duration. For each sub-category of a service type, the system retrieves the first weight attribute of at least two processing modules that processed each sub-category.

[0037] S120. For at least one service type, based on the processing data generated during the processing of the billing call detail record file associated with the service type by at least two processing modules, adjust the first weight attribute of at least two processing modules to obtain the second weight attribute of at least two processing modules.

[0038] Here, "processing data" refers to the set of statistical data generated by the processing module during the processing of billing call detail records (CDRs) and used for adjusting weight attributes. For at least one service type, the second weight attribute refers to the weight attribute obtained by adjusting the first weight attributes of at least two processing modules based on the processing data of one service type.

[0039] Optionally, for each processing module, the first number of input billing call detail records (CDRs), the second number of output billing CDRs, the third number of CDRs that meet the preset processing results, and the fourth number of CDRs that do not meet the preset processing results are counted; the first number, the second number, the third number, and the fourth number are determined as the processing data generated during the processing of at least two processing modules.

[0040] It should be noted that meeting the preset processing results means that after the billing call detail records (CDRs) are processed by the corresponding processing module, the output results meet the system's preset qualification standards, i.e., the processing is correct and meets the standards. Each processing module outputs CDRs that meet the preset processing results. For each processing module—collection and transmission, CDR decoding, CDR pricing, CDR aggregation, and CDR storage—at least the first, second, third, and fourth quantities must be counted. For each processing module, the first quantity refers to the number of CDRs input to each processing module; the second quantity refers to the number of CDRs output from each processing module; the third quantity refers to the number of CDRs that are correctly processed and meet the standards in each processing module; and the fourth quantity refers to the number of CDRs that are abnormally processed in each processing module. For the collection and transmission module, the number of CDRs generated by network elements also needs to be counted.

[0041] In this embodiment, for each processing module, the first weight attribute of the processing module is adjusted according to the first quantity, the third quantity, and the fourth quantity corresponding to the processing module; and, for any two adjacent processing modules, the first weight attribute of the processing module is adjusted according to the second quantity corresponding to the previous processing module and the first quantity corresponding to the next processing module; and the adjusted first weight attribute is used as the second weight attribute of the processing module.

[0042] It should be noted that, for each processing module, when the first quantity corresponding to the processing module is not equal to the sum of the third quantity and the fourth quantity corresponding to the processing module, the first weight attribute of the processing module is incremented by one; for each processing module, when the first quantity corresponding to the processing module is equal to the sum of the third quantity and the fourth quantity corresponding to the processing module, the first weight attribute of the processing module remains unchanged.

[0043] It should also be noted that, for any two adjacent processing modules, if the second quantity corresponding to the first processing module is not equal to the first quantity corresponding to the second processing module, the first weight attribute of the two adjacent processing modules is incremented by one; if, for any two adjacent processing modules, the second quantity corresponding to the first processing module is equal to the first quantity corresponding to the second processing module, the first weight attribute of the two adjacent processing modules remains unchanged.

[0044] For example, for each processing module, the formula for adjusting the first weight attribute within the processing module based on the first, third, and fourth quantities corresponding to the processing module can be:

[0045] ;

[0046] in, This refers to the result determined by adjusting the first weight attribute within each processing module based on the first, third, and fourth quantities corresponding to that processing module. This refers to the result determined after adjusting the first weight attribute of the acquisition and transmission module; This refers to the result determined after adjusting the first weight attribute of the call detail record (CDR) decoding module; This refers to the result determined after adjusting the first weight attribute of the call detail record (CDR) pricing module; This refers to the result determined after adjusting the first weight attribute of the call detail record (CDR) summary module; This refers to the result determined after adjusting the first weight attribute of the call detail record (CDR) entry module.

[0047] It should be noted that when the number of billing record files generated by the network element is not equal to the number of billing record files input to the acquisition and transmission module, The value is incremented by one; when the number of billing call detail records (CDRs) input to the CDR decoding module is not equal to the number of correctly processed and compliant CDRs processed by the CDR decoding module and the number of abnormal CDRs processed by the CDR decoding module, The value is incremented by one; when the number of billing call detail records (CDRs) input to the CDR pricing module is not equal to the number of correctly processed and compliant CDRs processed by the CDR pricing module and the number of abnormally processed CDRs, the value is incremented by one; The value is incremented by one; when the number of billing call detail records (CDRs) input to the CDR aggregation module is not equal to the number of correctly processed and compliant CDRs processed by the CDR aggregation module and the number of abnormal CDRs processed by the CDR aggregation module, the value is incremented by one; The value is incremented by one; when the number of billing call detail records (CDRs) entered into the CDR database module is not equal to the number of CDRs output after entry into the database, the value is incremented by one; The value is incremented by one.

[0048] For any two adjacent processing modules, the formula for adjusting the first weight attribute between the processing modules based on the second quantity corresponding to the preceding processing module and the first quantity corresponding to the following processing module can be:

[0049] ;

[0050] in, This refers to the result determined by adjusting the first weight attribute of any two adjacent processing modules based on the second quantity corresponding to the preceding processing module and the first quantity corresponding to the following processing module. This refers to the result determined after adjusting the first weight attribute between the acquisition and transmission module and the call detail record (CDR) decoding module; This refers to the result determined after adjusting the first weight attribute between the call detail record (CDR) decoding module and the CDR pricing module; This refers to the result determined after adjusting the first weight attribute between the call detail record (CDR) pricing module and the CDR summary module; This refers to the result determined after adjusting the first weight attribute between the call detail record (CDR) aggregation module and the CDR entry module.

[0051] It should be noted that when the number of billing call detail records (CDRs) input to the acquisition and transmission module is not equal to the number of CDRs input to the CDR decoding module, [the following will occur]. The value is incremented by one; when the number of billing call detail records (CDRs) output by the call detail record decoding module is not equal to the number of CDRs input to the call detail record pricing module, The value is incremented by one; when the number of billing call detail records (CDRs) output by the CDR pricing module is not equal to the number of CDRs input to the CDR aggregation module, the value is incremented by one. The value is incremented by one; when the number of billing call detail records (CDRs) output by the CDR summary module is not equal to the number of CDRs input to the CDR database module, the value is incremented by one. The value is incremented by one.

[0052] The formula for using the adjusted first weight attribute as the second weight attribute of the processing module can be:

[0053] ;

[0054] It should be noted that, This refers to the second weight attribute. For each business type, after adjusting the first weight attribute within the processing module and the first weight attribute between processing modules, the second weight attribute corresponding to each business type can be obtained.

[0055] Specifically, for each sub-category of business type, the first weight attribute is obtained from at least two processing modules that process each sub-category. For each sub-category, the first weight attribute is adjusted based on the processing data generated by all processing modules during the processing of the billing call detail records (CDRs) under each sub-category, to obtain the second weight attribute.

[0056] S130. Based on the first weight attribute and the second weight attribute, determine the weight attribute fluctuation ratio, and when the weight attribute fluctuation ratio exceeds the first preset threshold, trigger the early warning mechanism corresponding to the business type.

[0057] Within the same business type, the weighted attribute volatility ratio refers to the volatility measure obtained by comparing the difference between the first weighted attribute and the second weighted attribute. The first preset threshold refers to the trigger threshold used to determine whether the weighted attribute volatility ratio is abnormal.

[0058] Optionally, an intermediate value is determined based on the first weighted attribute and the second weighted attribute; the fluctuation ratio of the weighted attribute is determined based on the intermediate value and the first weighted attribute.

[0059] It should be noted that this can be based on the first weighted attribute. Second weight attribute The difference is used to determine the median value. The median value can be... It can be based on the median value. and the first weighted attribute Determine the fluctuation ratio of the weighted attributes. The fluctuation ratio of the weighted attributes can be... .

[0060] It should also be noted that the first preset threshold can be 10%. When the fluctuation ratio of the weight attribute exceeds the first preset threshold, the early warning mechanism corresponding to the business type is triggered.

[0061] In this embodiment, when the weight attribute fluctuation ratio exceeds the first preset threshold, an abnormal billing call detail record (CDR) file is determined based on the first weight attribute, the second weight attribute, and the billing CDR file processed by each processing module; the abnormal CDR file and the warning information corresponding to the abnormal CDR file are fed back.

[0062] The warning information includes at least the service type corresponding to the billing call detail record (CDR) file, the name of the CDR file, and the timestamp corresponding to the CDR file.

[0063] It should be noted that when the fluctuation ratio of the weighted attribute exceeds the first preset threshold, according to , , , , , , , , The value of and the billing call detail records (CDRs) processed by each processing module are used to identify abnormal CDRs. When , , , or An increase in this value indicates the presence of an abnormal billing record file within the processing module. When... , , or When the value increases, it indicates that there is an abnormal billing call detail record (CDR) file when the CDR file is transferred between the two processing modules.

[0064] It should also be noted that the service type corresponding to the billing call detail record (CDR) file can refer to voice calls, SMS services, data services, or value-added services, or it can refer to a subcategory of each service type. The name of the billing CDR file refers to its external identifier within the system, typically the filename when it is entered into the database. The timestamp corresponding to the billing CDR file can refer to the timestamp when the billing CDR file was generated.

[0065] Specifically, for each sub-category of business type, the fluctuation ratio of the weight attribute is determined based on the corresponding first weight attribute and the corresponding second weight attribute, and when the fluctuation ratio of the weight attribute exceeds the first preset threshold, an SMS alert corresponding to the business type is triggered.

[0066] The technical solution of this disclosure first obtains billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtains the first weight attributes of at least two processing modules that process the service type. Then, for at least one service type, based on the processing data generated during the processing of the billing CDRs associated with the service type by the at least two processing modules, the first weight attributes of the at least two processing modules are adjusted to obtain second weight attributes of the at least two processing modules. Finally, based on the first and second weight attributes, the weight attribute fluctuation ratio is determined, and when the weight attribute fluctuation ratio exceeds a first preset threshold, an early warning mechanism corresponding to the service type is triggered. This solves the problems of delayed response, high labor costs, and low accuracy in the prior art where manual analysis is triggered when external feedback indicates a decrease in revenue or other anomalies. This disclosure realizes the determination of whether to trigger an early warning mechanism corresponding to the service type based on the processing data generated during the processing of the billing CDRs associated with the service type by the processing modules. This can quickly locate problems in the billing CDRs within the modules, effectively discovering and reducing the risk of missed revenue collection and improving revenue growth efficiency.

[0067] Example 2

[0068] Figure 2 This is a flowchart illustrating the early warning method based on billing call detail records provided in this embodiment of the invention. Based on the aforementioned embodiments, the processing method for target service types whose weight attribute fluctuation ratio meets preset conditions is explained in detail. For specific implementation details, please refer to the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0069] like Figure 2 As shown, the method specifically includes the following steps:

[0070] S210. For target business types whose weight attribute fluctuation ratio meets the preset conditions, obtain the historical weight attribute corresponding to the target business type.

[0071] Among them, the historical weight attribute is the weight attribute determined within a continuous historical period.

[0072] It should be noted that the weighted attribute fluctuation ratio that meets the preset conditions refers to: the weighted attribute fluctuation ratio that exceeds the first preset threshold, or the weighted attribute fluctuation ratio that ranks first when sorted in descending order. The weighted attribute fluctuation ratio. Business types whose weighted attribute fluctuation ratios meet preset conditions are selected as target business types.

[0073] Specifically, based on the fluctuation ratio of the weighted attributes corresponding to all business types, the business types that meet the preset conditions are determined. For the target business type that meets the preset conditions, the second weighted attribute determined within the continuous historical time period corresponding to the target business type is obtained.

[0074] For example, for the weighted attribute fluctuation ratios corresponding to all business types, the values ​​of the weighted attribute fluctuation ratios are sorted in descending order to determine the top five weighted attribute fluctuation ratios. For the target business type corresponding to the top five weighted attribute fluctuation ratios, the second weighted attribute corresponding to the target business type for the previous three days is obtained.

[0075] S220. For historical weight attributes corresponding to adjacent historical time periods, determine the historical weight attribute fluctuation ratio.

[0076] Specifically, for historical weight attributes within a continuous historical period, the difference between the historical weight attributes corresponding to any two adjacent historical periods is determined, that is, the fluctuation ratio of the historical weight attributes corresponding to any two adjacent historical periods is determined.

[0077] For example, for the second weighted attribute corresponding to the target business type obtained three days ago, the historical weighted attribute fluctuation ratio between three days ago and two days ago is determined as follows: The historical weighted attribute fluctuation ratios from two days ago and one day ago were determined as follows: Determine the historical weighted attribute fluctuation ratio between the current day and the day before as follows: .

[0078] S230. When the fluctuation ratio of all historical weight attributes exceeds the second preset threshold, the upgrade warning mechanism corresponding to the target business type is triggered.

[0079] The second preset threshold can be 0.

[0080] Specifically, when the fluctuation ratio of all historical weighted attributes exceeds the second preset threshold, i.e. If the issue proves that no effective manual intervention has been received for three consecutive days, an escalation alert is required. In addition to SMS alerts, alerts can also be issued by calling IVR outbound maintenance personnel and maintenance managers.

[0081] S240. When the historical weight attribute fluctuation ratio does not exceed the second preset threshold, the second weight attribute corresponding to the target business type will be reset.

[0082] Specifically, when the historical weight attribute fluctuation ratio does not exceed the second preset threshold, i.e. When this is the case, it means the problem has been resolved, and the second weight attribute is reset to 0.

[0083] The technical solution of this disclosure determines a second weight attribute based on the smoothness of each module in the billing call detail record (CDR) file processing flow. It compares and audits the CDRs with the previous three days, with the number of audits per day being configurable. It provides effective early warning for imbalances within and between modules that lead to changes in the weight attribute. Furthermore, if the weight attribute of the same service type increases for three consecutive days, it will alert higher-level users, reminding them that the system may be experiencing a loss of billing CDR files.

[0084] Example 3

[0085] Figure 3 This is a schematic diagram of the early warning device based on billing call detail records provided in the embodiments of this disclosure, as shown below. Figure 3 As shown, the device includes: a billing call detail record file acquisition module 310, a second weight attribute determination module 320, and an early warning mechanism triggering module 330.

[0086] A billing call detail record (CDR) file acquisition module is used to acquire CDR files generated by at least one service type within a preset time period, and acquire a first weight attribute of at least two processing modules that process the service type; wherein, the first weight attribute is a weight attribute determined based on the previous processing of CDR files generated within a historical time period; a second weight attribute determination module is used to adjust the first weight attribute of the at least two processing modules for the at least one service type based on the processing data generated during the processing of the CDR files associated with the service type by the at least two processing modules, to obtain a second weight attribute of the at least two processing modules; an early warning mechanism triggering module is used to determine a weight attribute fluctuation ratio based on the first weight attribute and the second weight attribute, and trigger an early warning mechanism corresponding to the service type when the weight attribute fluctuation ratio exceeds a first preset threshold.

[0087] The technical solution of this disclosure first obtains billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtains the first weight attributes of at least two processing modules that process the service type. Then, for at least one service type, based on the processing data generated during the processing of the billing CDRs associated with the service type by the at least two processing modules, the first weight attributes of the at least two processing modules are adjusted to obtain second weight attributes of the at least two processing modules. Finally, based on the first and second weight attributes, the weight attribute fluctuation ratio is determined, and when the weight attribute fluctuation ratio exceeds a first preset threshold, an early warning mechanism corresponding to the service type is triggered. This solves the problems of delayed response, high labor costs, and low accuracy in the prior art where manual analysis is triggered when external feedback indicates a decrease in revenue or other anomalies. This disclosure realizes the determination of whether to trigger an early warning mechanism corresponding to the service type based on the processing data generated during the processing of the billing CDRs associated with the service type by the processing modules. This can quickly locate problems in the billing CDRs within the modules, effectively discovering and reducing the risk of missed revenue collection and improving revenue growth efficiency.

[0088] Based on the above technical solutions, the device further includes: a processing data determination module, used to, for each processing module, count the first number corresponding to the input billing call detail records (CDRs), the second number corresponding to the output CDRs, the third number corresponding to the CDRs that meet the preset processing results, and the fourth number corresponding to the CDRs that do not meet the preset processing results; and determine the first number, the second number, the third number, and the fourth number as the processing data generated during the processing of the at least two processing modules.

[0089] Based on the above technical solutions, the second weight attribute determination module 320 includes: a weight attribute adjustment submodule and a second weight attribute acquisition submodule.

[0090] The weight attribute adjustment submodule is used to adjust the first weight attribute of each processing module according to the first quantity, third quantity, and fourth quantity corresponding to the processing module; and, for any two adjacent processing modules, to adjust the first weight attribute of the processing module according to the second quantity corresponding to the preceding processing module and the first quantity corresponding to the following processing module; and the second weight attribute obtaining submodule is used to use the adjusted first weight attribute as the second weight attribute of the processing module.

[0091] Based on the above technical solutions, the early warning mechanism triggering module 330 includes: an intermediate value determination submodule and a weight attribute fluctuation ratio determination submodule.

[0092] The intermediate value determination submodule is used to determine the intermediate value based on the first weight attribute and the second weight attribute; the weight attribute fluctuation ratio determination submodule is used to determine the weight attribute fluctuation ratio based on the intermediate value and the first weight attribute.

[0093] Based on the above technical solutions, the device further includes: an early warning information feedback module, used to determine abnormal billing call detail records (CDRs) based on the first weight attribute, the second weight attribute, and the billing CDRs processed by each processing module; and to feed back the abnormal CDR and the early warning information corresponding to the abnormal CDR; wherein the early warning information includes at least the service type corresponding to the billing CDR, the name of the billing CDR, and the timestamp corresponding to the billing CDR.

[0094] Based on the above technical solutions, the device further includes: a second weight attribute reset module, used to obtain the historical weight attribute corresponding to the target business type for a target business type whose weight attribute fluctuation ratio meets a preset condition; wherein the historical weight attribute is a weight attribute determined within a continuous historical period; for historical weight attributes corresponding to adjacent historical periods, the historical weight attribute fluctuation ratio is determined; when all historical weight attribute fluctuation ratios exceed a second preset threshold, an upgrade warning mechanism corresponding to the target business type is triggered; when there is a historical weight attribute fluctuation ratio that does not exceed the second preset threshold, the second weight attribute corresponding to the target business type is reset.

[0095] The early warning device based on billing call detail records provided in this disclosure can execute the early warning method based on billing call detail records provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the execution method.

[0096] It is worth noting that the various units and modules included in the above-mentioned device are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of this disclosure.

[0097] Example 4

[0098] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Refer to the following... Figure 4 It illustrates an electronic device suitable for implementing embodiments of the present disclosure (e.g., Figure 4The diagram below shows the structure of the terminal device or server 500. The terminal device in this embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and vehicle terminals (e.g., vehicle navigation terminals). Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0099] like Figure 4 As shown, electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. An edit / output (I / O) interface 505 is also connected to bus 504.

[0100] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0101] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0102] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0103] The electronic device provided in this embodiment and the early warning method based on billing call detail records provided in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0104] Example 5

[0105] This disclosure provides a computer storage medium storing a computer program that, when executed by a processor, implements the early warning method based on billing call detail records provided in the above embodiments.

[0106] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can 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 of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0107] In some implementations, the server may communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and may interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0108] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0109] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to:

[0110] Obtain billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtain the first weight attribute of at least two processing modules that process the service type; wherein, the first weight attribute is a weight attribute determined based on the previous processing of billing CDRs generated within a historical time period.

[0111] For the at least one service type, based on the processing data generated during the processing of the billing call detail record file associated with the service type by the at least two processing modules, the first weight attribute of the at least two processing modules is adjusted to obtain the second weight attribute of the at least two processing modules;

[0112] Based on the first weight attribute and the second weight attribute, the weight attribute fluctuation ratio is determined, and when the weight attribute fluctuation ratio exceeds a first preset threshold, an early warning mechanism corresponding to the business type is triggered.

[0113] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0115] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0116] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0117] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0118] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0119] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0120] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A warning method based on billing call detail records (CDRs), characterized in that, The method includes: Obtain billing call detail records (CDRs) generated by at least one service type within a preset time period, and obtain the first weight attribute of at least two processing modules that process the service type; wherein, the first weight attribute is a weight attribute determined based on the previous processing of billing CDRs generated within a historical time period. For the at least one service type, based on the processing data generated during the processing of the billing call detail record file associated with the service type by the at least two processing modules, the first weight attribute of the at least two processing modules is adjusted to obtain the second weight attribute of the at least two processing modules; Based on the first weight attribute and the second weight attribute, the weight attribute fluctuation ratio is determined, and when the weight attribute fluctuation ratio exceeds a first preset threshold, an early warning mechanism corresponding to the business type is triggered.

2. The method according to claim 1, characterized in that, Determine the processing data generated during the processing of the at least two processing modules, including: For each of the processing modules, the following are counted: the first number of input billing call detail records (CDRs), the second number of output billing CDRs, the third number of CDRs that meet the preset processing results, and the fourth number of CDRs that do not meet the preset processing results. The first quantity, the second quantity, the third quantity, and the fourth quantity are determined as the processing data generated during the processing of the at least two processing modules.

3. The method according to claim 1, characterized in that, The processing data generated during the processing of the billing record file associated with the service type by the at least two processing modules is used to adjust the first weight attribute of the at least two processing modules to obtain the second weight attribute of the at least two processing modules, including: For each processing module, the first weight attribute of the processing module is adjusted according to the first quantity, third quantity, and fourth quantity corresponding to the processing module; and, For any two adjacent processing modules, the first weight attribute of the processing module is adjusted according to the second quantity corresponding to the previous processing module and the first quantity corresponding to the next processing module. The adjusted first weight attribute is used as the second weight attribute of the processing module.

4. The method according to claim 1, characterized in that, Determining the weight attribute fluctuation ratio based on the first weight attribute and the second weight attribute includes: The intermediate value is determined based on the first weight attribute and the second weight attribute; The weight attribute fluctuation ratio is determined based on the median value and the first weight attribute.

5. The method according to claim 1, characterized in that, When the fluctuation ratio of the weighted attribute exceeds a first preset threshold, the method further includes: Based on the first weight attribute, the second weight attribute, and the billing call detail records processed by each of the processing modules, abnormal billing call detail records are determined. The abnormal billing call detail record (CDR) file and the corresponding warning information are fed back; wherein, the warning information includes at least the service type corresponding to the billing CDR file, the name of the billing CDR file, and the timestamp corresponding to the billing CDR file.

6. The method according to claim 1, characterized in that, The method further includes: For target business types whose weight attribute fluctuation ratio meets preset conditions, obtain the historical weight attribute corresponding to the target business type; wherein, the historical weight attribute is the weight attribute determined within a continuous historical period; For historical weight attributes corresponding to adjacent historical time periods, determine the fluctuation ratio of the historical weight attributes; When the fluctuation ratio of all historical weighted attributes exceeds the second preset threshold, an upgrade warning mechanism corresponding to the target business type is triggered; When the historical weight attribute fluctuation ratio does not exceed the second preset threshold, the second weight attribute corresponding to the target business type will be reset.

7. An early warning device based on billing call detail records, characterized in that, include: The billing call detail record (CDR) file acquisition module is used to acquire CDR files generated by at least one service type within a preset time period, and to acquire first weight attributes of at least two processing modules that process the service type; wherein, the first weight attribute is a weight attribute determined based on the previous processing of CDR files generated within a historical time period. The second weight attribute determination module is used to adjust the first weight attribute of the at least two processing modules based on the processing data generated during the processing of the billing call detail record file associated with the service type by the at least two processing modules, for the at least one service type, so as to obtain the second weight attribute of the at least two processing modules. The early warning mechanism triggering module is used to determine the weight attribute fluctuation ratio based on the first weight attribute and the second weight attribute, and to trigger the early warning mechanism corresponding to the business type when the weight attribute fluctuation ratio exceeds a first preset threshold.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When one or more programs are executed by one or more processors, the one or more processors implement the early warning method based on billing call detail records as described in any one of claims 1-6.

9. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the early warning method based on billing call detail records as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the early warning method based on billing call detail records as described in any one of claims 1-6.

Images