Error Detection Methods and Systems

Abstract

This invention relates to the field of blockchain technology, and in particular to a method and system for detecting call detail records (CDRs). The invention trains a model based on a CDR training dataset and corresponding CDR type labels stored in a blockchain network, thereby obtaining a trained CDR detection model on the blockchain network. Then, it acquires the CDR data to be processed from the clearing and settlement system, and finally uses the trained CDR detection model on the blockchain network to detect errors in the CDR data to be processed. This improves the efficiency of CDR detection, avoids the cumbersome and inefficient CDR detection process in existing technologies, and reduces the data load on local devices.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and system for detecting erroneous orders. Background Technology

[0002] In traditional technology, when performing error verification for mobile operators' clearing and settlement services, it is generally done by reading each call detail record (CDR) one by one and checking each field in the CDR. This process is quite cumbersome, and when the amount of CDR data to be checked is large, it will consume a lot of local processor and memory resources, making the local data for auxiliary verification change more frequently and resulting in low efficiency.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this invention is to provide a method and system for detecting incorrect orders, aiming to solve the technical problems of cumbersome incorrect order detection process and low efficiency in the prior art.

[0005] To achieve the above objectives, the present invention provides an error order detection method, which is applied to a blockchain network, and the method includes the following steps:

[0006] Obtain the call detail record (CDR) training dataset and the corresponding CDR type labels;

[0007] Based on the call detail record training dataset and the call detail record type label, an on-chain model is trained to obtain a trained error call detection model.

[0008] Retrieve pending call detail records (CDRs) from the clearing and settlement system;

[0009] The error detection model is used to perform error detection on the call detail records (CDRs) data to be processed, and the error detection results are obtained.

[0010] Optionally, the step of training an on-chain model based on the call detail record (CDR) training dataset and the CDR type labels to obtain a trained error call detection model includes:

[0011] Obtain initial model byte data through the preset interface model;

[0012] The initial model byte data is deserialized to obtain the initial machine learning model;

[0013] Based on the call detail record (CDR) training dataset and the CDR type labels, the initial machine learning model is used to predict the model accuracy.

[0014] Based on the accuracy of the model, the model parameters of the initial machine learning model are iterated to obtain a trained error detection model.

[0015] Optionally, the error detection method further includes:

[0016] The trained error detection model is serialized to obtain the model byte data;

[0017] The model byte data is stored in the target block using a preset interface function.

[0018] Optionally, obtaining the call detail record (CDR) training dataset and the corresponding CDR type labels includes:

[0019] The recoded call detail record data stored in the target block is obtained through a preset interface function;

[0020] A decision tree model is generated based on the recoded call detail record data and the preset data structure;

[0021] Detect the category identifier of the decision tree model;

[0022] Based on the category identifier, extract the call detail record (CDR) training set and corresponding CDR type labels from the dataset data structure.

[0023] Optionally, the call detail record (CDR) data to be processed includes coded CDR data and model identifier;

[0024] The step of performing error detection on the call detail record (CDR) data to be processed based on the trained error detection model to obtain error detection results includes:

[0025] The model byte data corresponding to the model identifier is extracted from the target block using a preset interface model;

[0026] The model byte data is deserialized to obtain the target error detection model;

[0027] The encoded call detail record (CDR) data is deserialized to obtain the target encoded CDR data;

[0028] The target coded call detail record (CDR) data is subjected to error detection based on the target error detection model to obtain the error detection result corresponding to the CDR data to be processed.

[0029] This invention provides a method for detecting incorrect orders, which is applied to a client-side application. The method includes the following steps:

[0030] Obtain local call detail records (CDRs) from each child node;

[0031] The local call detail records (CDRs) are preprocessed.

[0032] The preprocessed local call detail records are re-encoded to obtain the target call detail records.

[0033] The target call detail record (CDR) data is sent to a blockchain network for storage. The target CDR data includes a CDR training dataset and corresponding CDR type tags.

[0034] Optionally, the method of preprocessing the local call detail record data includes at least one of the following: data cleaning, data transformation, data labeling, feature selection, and dataset partitioning.

[0035] Optionally, the step of re-encoding the preprocessed local call detail records (CDRs) to obtain the target CDRs includes:

[0036] The preprocessed local call detail records (CDRs) are converted to obtain the CDRs to be encoded.

[0037] The call detail record (CDR) data to be encoded is encoded using a preset encoding model to obtain a CDR byte array;

[0038] The target call detail record (CDR) data is generated based on the CDR byte array.

[0039] Optionally, sending the target call detail record (CDR) data to a blockchain network for storage includes:

[0040] The target call detail record (CDR) data is decoded to obtain a decoded byte array;

[0041] The decoded byte array is sent to the blockchain network for storage by calling a preset interface function.

[0042] This invention discloses a method for detecting call detail records (CDRs). The method includes: acquiring a CDR training dataset and corresponding CDR type labels; training an on-chain model based on the CDR training dataset and the CDR type labels to obtain a trained CDR detection model; acquiring CDR data to be processed in a clearing and settlement system; and performing CDR detection on the CDR data to be processed using the trained CDR detection model to obtain a CDR detection result. This invention improves the efficiency of CDR detection by training a model based on a CDR training dataset and corresponding CDR type labels stored in a blockchain network, thereby obtaining a trained CDR detection model on the blockchain network, acquiring CDR data to be processed in the clearing and settlement system, and finally performing CDR detection on the CDR data to be processed using the trained CDR detection model on the blockchain network. This avoids the technical problems of cumbersome CDR detection process and low efficiency in existing technologies, and reduces the data load on local devices. Attached Figure Description

[0043] Figure 1This is a flowchart illustrating an embodiment of the error detection method of the present invention;

[0044] Figure 2 This is a schematic diagram of a decision tree model structure example of an embodiment of the error detection method of the present invention;

[0045] Figure 3 This is a schematic diagram of the model training process in an embodiment of the error detection method of the present invention;

[0046] Figure 4 This is a schematic diagram of the model testing process of an embodiment of the error detection method of the present invention;

[0047] Figure 5 This is a schematic flowchart illustrating the error detection process of an embodiment of the error detection method of the present invention.

[0048] Figure 6 This is a flowchart illustrating Embodiment 2 of the error order detection method of the present invention;

[0049] Figure 7 This is a schematic diagram of the architecture between the client and the blockchain network in one embodiment of the error detection method of the present invention;

[0050] Figure 8 This is a schematic diagram illustrating a data format example of an embodiment of the error detection method of the present invention.

[0051] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0052] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0053] This invention provides a method for detecting incorrect orders, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the error detection method of the present invention applied to a blockchain network.

[0054] In this embodiment, the error detection method includes the following steps:

[0055] Step S10: Obtain the call detail record (CDR) training dataset and the corresponding CDR type labels.

[0056] It should be noted that the execution subject of the method in this embodiment can be a device with functions such as data processing, network communication and program execution, such as a cloud server, smart contract or blockchain network, or other devices that can achieve the same or similar functions. This embodiment does not impose specific limitations on this. In this embodiment and the following embodiments, a blockchain network will be used as an example for explanation.

[0057] It should be noted that the existing error detection technology is performed during the preprocessing of the settlement system on the local device. The preprocessing includes scanning, file decoding and filtering, file merging, call detail record (CDR) preprocessing (verification, pricing, and edge / roaming judgment), CDR deduplication, result publishing, rollback, billing period update, and merged distribution. During CDR preprocessing, verification involves detailed-level verification of the original decoded CDR files. This process checks different types of CDRs, such as calling CDRs, called CDRs, and call forwarding CDRs, field by field according to the verification rules. Furthermore, for complex processing logic involving verification points, a large amount of local data is often required to assist in CDR detection and verification, resulting in strong dependency.

[0058] Because a large amount of local data is needed to assist in call detail record (CDR) detection, a large amount of memory is consumed when performing CDR detection on the local device. Furthermore, different local data needs to be replaced for different CDR types, resulting in extremely low efficiency.

[0059] For example, during the verification of the calling-party identifier field in the call detail record (CDR), based on rules, this field has three verification points: error code F070 checks if the field is an 11-digit number; error code F071 checks if the first 7 digits have a corresponding home exchange number in the "MSISDN Code and Long Distance Area Code Lookup Table"; and error code F072 checks that if the field is not in a preset number segment, the number must exist in the ported-in user table. For error codes F071 and F072, before verification, the full set of MSISDN Code and Long Distance Area Code Lookup Table and number portability number table data must be loaded into the database or memory. Only by using this data can erroneous CDRs be detected, and error codes are attached to each detailed record, marking them as erroneous records for subsequent preprocessing of erroneous record data into the database.

[0060] It is understood that the call detail record (CDR) training dataset and the corresponding CDR type tags are data stored in a certain partition of the blockchain network after being uploaded by the client. They are mainly used for training and iteration of the error call detail record (CDR) model. In this embodiment, the CDR training dataset may include a training set for model training and a prediction set for model iteration.

[0061] Further, obtaining the call detail record (CDR) training dataset and the corresponding CDR type labels includes:

[0062] The recoded call detail record data stored in the target block is obtained through a preset interface function;

[0063] A decision tree model is generated based on the recoded call detail record data and the preset data structure;

[0064] Detect the category identifier of the decision tree model;

[0065] Based on the category identifier, extract the call detail record (CDR) training set and corresponding CDR type labels from the dataset data structure.

[0066] It should be understood that the preset interface function can be a CreateModel smart contract command or other smart contract command, used to read stored data from the shard, subchain, private partition or public partition of the blockchain corresponding to the preset interface function. For example, by calling the interface function provided by Fabric, all data can be obtained from the Fabric network block ledger.

[0067] The preset data structure in this embodiment can be referenced. Figure 2 The decision tree model structure shown uses ModelId as a unique identifier for the model. This ModelId serves as the on-chain key, allowing subsequent retrieval of the corresponding model data. For example, in a VoLTE roaming settlement system, ModelId is set to VolteModel. The data model, including all the following model parameters, is stored on-chain as the Value. Subsequently, the model data can be obtained by calling and retrieving the Key value of ModelId according to the smart contract, and then used for data prediction.

[0068] In the Model structure, Alpha, Regularization, and MaxIterations are hyperparameters used to control model training and are adjusted according to the specific task and dataset. In the decision tree model, Alpha (learning rate) is mainly used to control the step size of each parameter update; Regularization is a regularization parameter used to prevent overfitting; MaxIterations is the maximum number of iterations used to control the training time and accuracy; Method is the optimization method used to determine how parameters are updated; TrainingSet is the training dataset, containing features and their corresponding outputs; ExpectedResults is the expected output results used to calculate the model's error; and Parameters are the model's parameters, including the weights and biases of each feature, used to calculate the model's output.

[0069] In the specific implementation, by developing and calling the CreateModel smart contract command, all data is obtained from the Fabric network block ledger. Then, a multi-dimensional decision tree random forest call detail record detection model is built based on the obtained data, and training data is selected according to the Type label to train the generated model.

[0070] Step S20: Train the on-chain model based on the call detail record (CDR) training dataset and the CDR type label to obtain the trained error call detection model.

[0071] It is worth noting that when training a model in a blockchain network, an initial machine learning model can be extracted first, and then the initial machine learning model can be trained using the call detail record (CDR) training dataset and CDR type labels to obtain a trained error detection model.

[0072] Further, the step of training an on-chain model based on the call detail record (CDR) training dataset and the CDR type labels to obtain a trained error call detection model includes:

[0073] Obtain initial model byte data through the preset interface model;

[0074] The initial model byte data is deserialized to obtain the initial machine learning model;

[0075] Based on the call detail record (CDR) training dataset and the CDR type labels, the initial machine learning model is used to predict the model accuracy.

[0076] Based on the accuracy of the model, the model parameters of the initial machine learning model are iterated to obtain a trained error detection model.

[0077] In its implementation, the creation of machine learning models and data prediction on the blockchain are carried out by peer nodes organized by the Information Technology Center on the consortium blockchain. The Information Technology Center is mainly responsible for creating the learning models and the data prediction process, and uploading the datasets, data models, and prediction results to the on-chain ledger. Sub-level companies can obtain the corresponding machine learning models, error call prediction results, and datasets from the peer nodes they join through the created channels. They can also use the learning models to predict from the original provincial call detail record (CDR) data and compare the differences in error call data.

[0078] In the specific implementation process, refer to Figure 3 and Figure 4 , Figure 3 This is a schematic diagram of the model training process in this embodiment. Figure 4This is a schematic diagram of the model testing process in this embodiment. The process involves: setting the created model ID (ModelId), designing the model data structure, and storing the model in the blockchain ledger; calling the interface functions provided by Fabric to read the re-encoded dataset from the block; traversing the dataset data structure, checking the Type identifier, reading the dataset identified as "train," obtaining the Inputs and Targets data, and saving them in a new structure (Datalist); using the Datalist data for model training, saving the parameters from multiple training iterations and parameter tuning, along with the training dataset, into the Model structure (struct); serializing the model structure to obtain the on-chain byte data; calling the interface functions provided by Fabric to store the model in the block; after model creation and training, model testing can begin; developing and calling the TestModel smart contract command to first obtain all datasets and select the test dataset based on the Type identifier; reading the model data from the blockchain ledger according to the set modelid parameter, testing the generated model, and finally returning the prediction accuracy; completing multiple model training and testing iterations to obtain a high-accuracy error detection model.

[0079] Furthermore, to facilitate the use of the trained error detection model in subsequent error detection processes, the error detection method further includes:

[0080] The trained error detection model is serialized to obtain the model byte data;

[0081] The model byte data is stored in the target block using a preset interface function.

[0082] Understandably, due to the data storage characteristics of blockchain and to facilitate subsequent model training, this embodiment can save the serialized model byte data and the call detail record (CDR) training dataset in the same block to simplify the data structure construction steps and improve the efficiency of model training.

[0083] In a specific implementation, serialization refers to converting the trained error detection model into a byte stream or other form of data for storage and transmission between different systems; the preset interface function can be an interface function provided by Fabric, and this embodiment does not impose specific restrictions on it.

[0084] Step S30: Obtain pending call detail records (CDRs) from the clearing and settlement system.

[0085] It should be noted that the clearing and settlement system is mainly used to manage call detail records (CDRs) such as calling party CDRs, called party CDRs, and call forwarding CDRs; pending CDR data refers to CDR data that has not been checked for errors or has been checked for errors.

[0086] Step S40: Perform error detection on the call detail record (CDR) data to be processed according to the trained error detection model to obtain the error detection result.

[0087] It should be noted that after multiple model training and testing sessions, and once a model with high accuracy is achieved, predictions can be made on the input dataset. This is done by developing and calling the Predict smart contract command, inputting a preprocessed and re-encoded string and a modelid, retrieving the prediction model from the blockchain ledger based on the modelid, deserializing the input string, inputting it into the model for prediction, and returning the prediction result.

[0088] Further, the step of performing error detection on the call detail record (CDR) data to be processed based on the trained error detection model to obtain error detection results includes:

[0089] The model byte data corresponding to the model identifier is extracted from the target block using a preset interface model;

[0090] The model byte data is deserialized to obtain the target error detection model;

[0091] The encoded call detail record (CDR) data is deserialized to obtain the target encoded CDR data;

[0092] The target coded call detail record (CDR) data is subjected to error detection based on the target error detection model to obtain the error detection result corresponding to the CDR data to be processed.

[0093] In the specific implementation, refer to Figure 5 , Figure 5 This is a schematic diagram of the actual error detection process in this embodiment. First, the dataset ID to be predicted is input, which is the key value of the uploaded data, or the ID in the data structure. Based on the ID, the Fabric interface function is called to obtain the serialized string code, and then the code is deserialized to obtain the data structure data_struct. Next, by calling the interface function provided by Fabric, the model data is obtained based on the ModelId. At this point, the model is a byte array byte. The model is deserialized to obtain the model structure model_struct. Finally, the model_struct is used to predict the data Inputs in the data_struct, and the prediction result is output.

[0094] This embodiment trains a model based on the call detail record (CDR) training dataset and corresponding CDR type labels stored in the blockchain network, thereby obtaining a trained error detection model on the blockchain network. Then, it acquires the CDR data to be processed from the clearing and settlement system, and finally uses the trained error detection model on the blockchain network to detect errors in the CDR data to be processed. This improves the efficiency of error detection, avoids the technical problems of cumbersome error detection process and low efficiency in the prior art, and reduces the data load on local devices.

[0095] Example 2

[0096] This invention provides a method for detecting incorrect orders, referring to... Figure 6 , Figure 6 This is a flowchart illustrating another embodiment of the error detection method of the present invention applied to a client.

[0097] In this embodiment, the error detection method includes the following steps:

[0098] Step S10: Obtain local call detail records (CDRs) for each sub-node.

[0099] It should be noted that the execution subject of the method in this embodiment can be a client, such as a computer, a control computer or other terminal device, or other devices that can achieve the same or similar functions. This embodiment does not impose specific limitations on this. In this embodiment and the following embodiments, a control computer is used as an example for explanation.

[0100] In this embodiment, reference Figure 7 , Figure 7 This is a schematic diagram of the architecture of the client and the blockchain network in this embodiment. In order to reduce the memory usage pressure and storage load of the local device client, the client performs preprocessing and encoding operations on the data, and then uploads the processed data to the blockchain network for storage through a smart contract. The model is trained in the blockchain network and error detection is performed.

[0101] To build a consortium blockchain architecture for the client and blockchain network, this embodiment further includes the following steps before step S10: building and deploying a consortium blockchain with multiple member organizations based on Hyperledger Fabric, where each system creates a member and joins the corresponding organization; and creating a preset number of channels based on the consortium blockchain's support for multi-channel message passing in the consensus service, so that member nodes of different channels can maintain the ledgers and states corresponding to each channel, thereby achieving secure isolation of call detail record (CDR) data.

[0102] It should be understood that the error call record (CDR) detection process and its results are primarily geared towards the sub-level companies, serving as the basis for these companies to verify CDRs and rectify original provincial CDRs. The main entity responsible for error call record detection is the Information Technology Center, and the entire process is conducted collaboratively by both parties during the consortium blockchain construction. The Information Technology Center and the sub-level companies build the consortium blockchain through public network access. This consortium blockchain network comprises two organizations: the Information Technology Center and the sub-level companies. Nodes are deployed in the regions of the organizations where the sub-level companies are located, and corresponding member nodes are created.

[0103] Channels are established between member nodes in two organizations. Multiple channels can be created between two member nodes within an organization. Channels are used to isolate data from various sub-level companies. Members within the same channel can share the ledger, while error call record data between members of different channels is not searchable. For error call record detection in different business systems, which involves 31 sub-level companies, 31 channels can be created on member nodes to achieve call detail record data isolation.

[0104] In the actual implementation, the client is responsible for preprocessing the local dataset. The data preprocessing process involves data cleaning, feature encoding, data labeling, dataset partitioning, and other preparations before modeling. Because the preprocessing process involves multiple processing steps and requires repeated trials, and smart contracts also require standard program logic, the data processing is not performed through smart contracts.

[0105] Understandably, after preprocessing, the client re-encodes the dataset into the data type required for on-chain processing, preparing for subsequent modeling of the dataset on the blockchain. Then, through interface functions provided by Hyperledger Fabric, the processed dataset is passed to the technical layer. At the technical layer, a Hyperledger Fabric network is built, and data is pulled from the blockchain via smart contracts for on-chain processing and decoding. Next, on-chain machine learning models are created and data predictions are performed, ultimately inputting the prediction results into the blockchain ledger. The multi-channel isolation mechanism based on Hyperledger Fabric also ensures the reliability of the error detection process for each access system. The ledger is maintained jointly by multiple nodes, guaranteeing data transparency and traceability.

[0106] Step S20: Preprocess the local call detail records (CDRs) of each type.

[0107] It should be noted that the preprocessing of local call detail record (CDR) data includes, but is not limited to, data cleaning, data transformation, data labeling, feature selection, and dataset partitioning. This embodiment does not impose specific limitations on these processes.

[0108] In practical implementation, the data cleaning process can be to supplement the local call detail record (CDR) data by using algorithms such as average and mode to identify outliers and missing values ​​according to the overall distribution of CDR data. Alternatively, when there is insufficient sample CDR data, sample CDR data can be supplemented by CDR detection rules to meet the requirements of model training. For example, data expansion and data fusion can be used to achieve data expansion.

[0109] Data conversion refers to converting Chinese and English data in fields such as subsidiary names and access networks in call detail records (CDRs) into numeric types to match the model's input data requirements, facilitating subsequent on-chain data processing and data conversion.

[0110] Understandably, after data cleaning and transformation, call detail records (CDRs) are analyzed. Since error detection is a supervised learning process, data in the CDRs that do not conform to the CDR detection rules are marked, and each CDR is labeled with an output column, such as "normal" or "abnormal".

[0111] Call detail record (CDR) detection rules refer to the corresponding CDR verification rule standards for each clearing and settlement business processing system. This means that each field in the CDR has a specific verification process and is assigned an error code. For example, for the Role-of-Node field in the CDR type, the valid value must be one of 0, 1, or 4: 0: ORIGINATING_ROLE indicates the calling party's CDR; 1: TERMINATING_ROLE indicates the called party's CDR; 4: CALLFORWARD_ROLE indicates the forwarding CDR. If not, the CDR is detected as an error and marked with error code F040. Another example is the Calling-Party field, which is not an 11-digit number, resulting in error code F070; the first 7 digits do not have a corresponding home exchange number in the "MSISDN Code and Long Distance Area Code Comparison Table," resulting in error code F071; and if the number is a China Mobile number segment, it does not exist in the ported-in user table, resulting in error code F072. In other words, each CDR data is marked according to these CDR detection rules.

[0112] In addition, feature selection uses the Pearson correlation coefficient to calculate the correlation between each feature and the label in the call detail record file, and selects the corresponding feature with the larger coefficient value as the model input value.

[0113] Because the types of incorrect orders are limited and relatively fixed, the dataset is divided into a training set and a test set for model training and a test set for model prediction.

[0114] Step S30: Re-encode each of the preprocessed local call detail records (CDRs) to obtain the target CDRs.

[0115] It should be noted that recoding refers to the process of converting data from a flat file into a byte array in a fixed format, and then encoding the byte array into a unique string.

[0116] Further, the step of re-encoding the preprocessed local call detail records (CDRs) to obtain the target CDRs includes:

[0117] The preprocessed local call detail records (CDRs) are converted to obtain the CDRs to be encoded.

[0118] The call detail record (CDR) data to be encoded is encoded using a preset encoding model to obtain a CDR byte array;

[0119] The target call detail record (CDR) data is generated based on the CDR byte array.

[0120] In the specific implementation, refer to Figure 8 , Figure 8 This is a schematic diagram of a data format example in an encoding model, which re-encodes preprocessed data, reading data from a flat file into a format such as... Figure 8 After defining the data format as shown, use Golang's encoding / json library to encode it into a byte array, and then use the encoding / base64 library to encode the obtained byte data into a string and save it in a txt file for subsequent data uploading to the blockchain.

[0121] exist Figure 7 In the data structure shown, Feature stores the feature names of the data, Inputs stores the independent variables of the data, Targets stores the dependent variables of the data, Id is used as the key for each data upload and can be used to trace the data on the chain later, while Type determines the purpose of the data, using train and test to distinguish between training data and prediction data.

[0122] Step S40: Send the target call detail record (CDR) data to the blockchain network for storage. The target CDR data includes a CDR training dataset and corresponding CDR type tags.

[0123] Furthermore, the step of sending the target call detail record (CDR) data to the blockchain network for storage includes:

[0124] The target call detail record (CDR) data is decoded to obtain a decoded byte array;

[0125] The decoded byte array is sent to the blockchain network for storage by calling a preset interface function.

[0126] The preset interface function can be the Update function in a smart contract, and this embodiment does not impose specific restrictions on it.

[0127] In the specific implementation, the data upload process involves base64 decoding of the preprocessed and re-encoded string to obtain a byte array, and then storing the data into the blockchain ledger by calling the interface function in the Go SDK. The Update function in the smart contract is developed and called to complete the data upload.

[0128] This embodiment preprocesses and re-encodes the local call detail record (CDR) data of each sub-node to obtain target CDR data that conforms to the format required by the smart contract. The target CDR data is then uploaded to the blockchain network for storage, so as to facilitate subsequent model training and error detection in the blockchain network and improve the efficiency of error detection.

[0129] Furthermore, embodiments of the present invention also propose an error order detection system, referring to... Figure 7 The error order detection system includes a client and a blockchain network. The blockchain network is used to implement the error order detection method described in Embodiment 1, and the client is used to implement the error order detection method described in Embodiment 2.

[0130] It should be understood that although the steps in the flowcharts of this application's embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0131] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solutions of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.

[0132] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0133] In addition, for technical details not described in detail in this embodiment, please refer to the error detection method provided in any embodiment of the present invention, which will not be repeated here.

[0134] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0135] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0136] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0137] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for detecting incorrect orders, characterized in that, The error detection method is applied to a blockchain network; The error detection method includes: The recoded call detail record data stored in the target block is obtained through a preset interface function; A decision tree model is generated based on the recoded call detail record data and the preset data structure; Detect the category identifier of the decision tree model; The call detail record (CDR) training set and corresponding CDR type labels are extracted from the decision tree model based on the category identifier. The CDR training set and corresponding CDR type labels are data that is stored in a partitioned blockchain network after being uploaded to the blockchain by the client. Based on the call detail record training dataset and the call detail record type label, an on-chain model is trained to obtain a trained error call detection model. Retrieve pending call detail records (CDRs) from the clearing and settlement system; The error detection model is used to detect errors in the call detail records (CDRs) data to be processed, and the error detection results are obtained. Before obtaining local call detail records (CDRs) from each sub-node, the client builds and deploys a consortium blockchain with multiple members based on Hyperledger. Each system creates a member and joins the corresponding organization. Based on the consortium blockchain, it supports multi-channel message passing in the consensus service and creates a preset number of channels so that member nodes of different channels can maintain the ledger and state corresponding to each channel.

2. The error detection method as described in claim 1, characterized in that, The step of training an on-chain model based on the call detail record (CDR) training dataset and the CDR type labels to obtain a trained error call detection model includes: Obtain initial model byte data through the preset interface model; The initial model byte data is deserialized to obtain the initial machine learning model; Based on the call detail record (CDR) training dataset and the CDR type labels, the initial machine learning model is used to predict the model accuracy. Based on the accuracy of the model, the model parameters of the initial machine learning model are iterated to obtain a trained error detection model.

3. The error detection method as described in claim 2, characterized in that, After obtaining the trained error order detection model, the error order detection method further includes: The trained error detection model is serialized to obtain the model byte data; The model byte data is stored in the target block using a preset interface function.

4. The error detection method as described in claim 1, characterized in that, The call detail record (CDR) data to be processed includes coded CDR data and model identifiers; The step of performing error detection on the call detail record (CDR) data to be processed based on the trained error detection model to obtain error detection results includes: The model byte data corresponding to the model identifier is extracted from the target block using a preset interface model; The model byte data is deserialized to obtain the target error detection model; The encoded call detail record (CDR) data is deserialized to obtain the target encoded CDR data; The target coded call detail record (CDR) data is subjected to error detection based on the target error detection model to obtain the error detection result corresponding to the CDR data to be processed.

5. A method for detecting incorrect orders, characterized in that, The error order detection method is applied to the client side; The error detection method includes: Obtain local call detail records (CDRs) from each child node; Before obtaining the local call detail record (CDR) data of each sub-node, the process also includes: building and deploying a consortium blockchain with multiple members based on Hyperledger, with each system creating a member and joining the corresponding organization; and creating a preset number of channels based on the consortium blockchain's support for multi-channel message passing in the consensus service, so that member nodes of different channels can maintain the ledger and state corresponding to each channel. The local call detail records (CDRs) are preprocessed. The preprocessed local call detail records are re-encoded to obtain the target call detail records. The target call detail record (CDR) data is sent to a blockchain network for storage. The target CDR data includes a CDR training dataset and corresponding CDR type tags. The blockchain network obtains the recoded call detail record (CDR) data stored in the target block through a preset interface function; generates a decision tree model based on the recoded CDR data and a preset data structure; detects the category identifier of the decision tree model; and extracts the CDR training set and corresponding CDR type labels from the decision tree model based on the category identifier. The CDR training set and corresponding CDR type labels are data that is stored in the blockchain network partitions after being uploaded by the client.

6. The error detection method as described in claim 5, characterized in that, The method for preprocessing the local call detail record (CDR) data includes at least one of the following: data cleaning, data transformation, data labeling, feature selection, and dataset partitioning.

7. The error detection method as described in claim 5, characterized in that, The step of re-encoding the preprocessed local call detail records (CDRs) to obtain the target CDRs includes: The preprocessed local call detail records (CDRs) are converted to obtain the CDRs to be encoded. The call detail record (CDR) data to be encoded is encoded using a preset encoding model to obtain a CDR byte array; The target call detail record (CDR) data is generated based on the CDR byte array.

8. The error detection method as described in claim 5, characterized in that, The step of sending the target call detail record (CDR) data to the blockchain network for storage includes: The target call detail record (CDR) data is decoded to obtain a decoded byte array; The decoded byte array is sent to the blockchain network for storage by calling a preset interface function.

9. An error order detection system, characterized in that, The error order detection system includes a client and a blockchain network, wherein the blockchain network is used to implement the error order detection method as described in claims 1-4, and the client is used to implement the error order detection method as described in claims 5-8.

Images