DPI call detail record (CDR) detection methods, devices, equipment, media, and products

Abstract

This application provides a DPI call detail record (CDR) detection method, apparatus, device, medium, and product. The method includes: sending a test task to a target terminal, the test task including at least one test script; obtaining target DPI CDR data returned by the target terminal, the target DPI CDR data being DPI CDR data generated by the target terminal executing the test task; generating target XDR CDR data corresponding to the target DPI CDR data based on the DPI base CDR generation strategy and the target DPI CDR data; determining the XDR CDR data to be tested from the DPI CDR data to be tested based on the parameter information of the target XDR CDR data, wherein the parameter information of the XDR CDR data to be tested is the same as that of the target XDR CDR data; and detecting the XDR CDR data to be tested based on the target XDR CDR data, generating a detection result. This technical solution realizes the detection and evaluation of the quality of XDR CDRs themselves, improving the accuracy and reliability of DPI CDR detection.

Description

Technical Field

[0001] This application relates to the field of DPI call detail record (CDR) technology, and in particular to a DPI CDR detection method, apparatus, equipment, medium, and product. Background Technology

[0002] In 5G networks, DPI (Deep Packet Inspection) technology is used to deeply analyze data packets in the network to identify and classify various types of application traffic. XDR (Extended Detection and Response), or call detail records (CDRs), contains these analytical results and other relevant information, used for network management and optimization, billing, security monitoring, and other aspects.

[0003] Existing XDR call detail record (CDR) detection technologies mainly evaluate XDR CDRs by examining network uplink and downlink latency, software loading speed, and voice call quality at the terminal, and by establishing the relationship between latency, rate-related parameters, and user experience.

[0004] However, existing detection technologies cannot accurately assess the quality and accuracy of XDR call detail records themselves. Summary of the Invention

[0005] This application provides a DPI call detail record (CDR) detection method, apparatus, equipment, medium, and product to solve the technical problem that existing technologies cannot accurately assess the quality and correctness of XDR CDRs themselves.

[0006] Firstly, this application provides a method for DPI call detail record (CDR) detection, including:

[0007] Send a test task to the target terminal. The test task includes at least one test script, which is pre-edited according to the business process.

[0008] Obtain the target depth packet detection DPI call detail data returned by the target terminal. The target DPI call detail data is the DPI call detail data generated by the target terminal when performing the dial test task.

[0009] Based on the DPI base call detail record generation strategy and the target DPI call detail record data, generate the target extended detection and response XDR call detail record data corresponding to the DPI call detail record data.

[0010] Based on the parameter information of the target XDR call detail record (CDR) data, the XDR CDR data to be tested is determined from the DPI CDR data to be tested. The XDR CDR data to be tested is generated based on the DPI base CDR generation strategy, and the parameter information of the XDR CDR data to be tested is the same as that of the target XDR CDR data.

[0011] Based on the ratio between the operation and the XDR call detail record data, the predefined minimum comparison unit, and preset fields, the target XDR call detail record data and the XDR call detail record data to be tested are detected, and the detection results are generated.

[0012] The smallest comparison unit includes the interface, service identifier, service process, and DNN. The detection result is used to indicate whether there are any abnormalities in the XDR call detail record data under test.

[0013] Optionally, the parameter information includes the target terminal's region code, interface, service type, International Mobile Subscriber Identity (IMSI), International Mobile Subscriber Directory Number (MSIDN), start time, and end time.

[0014] Optionally, the target DPI call detail record (CDR) data returned by the target terminal is obtained, including:

[0015] Obtain the target DPI call detail record data and target traffic data returned by the target terminal. The traffic data is the traffic data generated by the target terminal when performing the dial-up test task.

[0016] Optionally, a test call task is sent to the target terminal, including:

[0017] Send a test task to the Kafka queue so that the test task can be forwarded to the target terminal through the Kafka queue.

[0018] Optionally, before sending the test task to the target terminal, the method further includes:

[0019] Based on the business process defined by the 3GPP (3rd Generation Partnership Project) protocol, generate a test script for each service.

[0020] Configure at least one test script to generate a test task. The configuration operation includes sub-configuration operations for at least one of the following: execution order, number of executions, execution interval, server address to be accessed, and traffic protocol information of transport layer L4 / application layer L7 for different test scripts.

[0021] Optionally, the method further includes:

[0022] When the test results indicate that there is an anomaly in the XDR call detail record data under test, an alarm message is output, which is used to indicate the type of anomaly.

[0023] Secondly, this application proposes a DPI call detail record detection device, comprising:

[0024] The test task sending module is used to send test tasks to the target terminal. The test task includes at least one test script, which is pre-edited according to the business process.

[0025] The DPI call detail data acquisition module is used to acquire the target depth packet detection DPI call detail data returned by the target terminal. The target DPI call detail data is the DPI call detail data generated by the target terminal when performing the dialing test task.

[0026] The XDR call detail record (CDR) data generation module is used to generate CDR generation strategies and target DPI CDR data based on the DPI base, and to generate target extended detection and response XDR CDR data corresponding to the target DPI CDR data.

[0027] The XDR call detail record (CDR) data determination module is used to determine the XDR CDR data to be tested from the DPI CDR data to be tested based on the parameter information of the target XDR CDR data. The XDR CDR data to be tested is generated based on the DPI base CDR generation strategy, and the parameter information of the XDR CDR data to be tested is the same as that of the target XDR CDR data.

[0028] The detection result generation module is used to detect the target XDR call detail record (CDR) data and the XDR CDR data to be tested based on the ratio between the operation and the XDR CDR data, the predefined minimum comparison unit, and preset fields, and generate detection results.

[0029] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0030] The memory stores the instructions that the computer executes;

[0031] The processor executes computer execution instructions stored in memory to implement the methods of the embodiments of this application.

[0032] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods of the embodiments of this application.

[0033] Fifthly, this application provides a computer program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects.

[0034] The DPI call detail record (CDR) detection method, apparatus, equipment, medium, and product provided in this application determine the test task according to the business process and send the test task to the target terminal to obtain the target depth packet detection DPI CDR data returned by the target terminal; then, based on the DPI base CDR generation strategy and the target DPI CDR data, target XDR CDR data corresponding to the DPI CDR data is generated; then, based on the parameter information of the target XDR CDR data, the XDR CDR data to be tested is determined from the DPI CDR data to be tested; and the XDR CDR data to be tested is tested based on the target XDR CDR data to generate the test results, thereby realizing the detection and evaluation of the quality of the XDR CDR itself and improving the accuracy and reliability of DPI CDR detection. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0036] Figure 1a This is a system architecture diagram of the DPI call detail record (CDR) detection method proposed in this application;

[0037] Figure 1b The system architecture diagram of the DPI call detail record detection method provided in this application is a structural schematic diagram of the terminal management platform and the customized dialing test terminal.

[0038] Figure 2 This is a schematic diagram of the overall process of the DPI call detail record detection method proposed in this application;

[0039] Figure 3 This is a flowchart illustrating an embodiment of the DPI call detail record (CDR) detection method proposed in this application.

[0040] Figure 4a A flowchart illustrating Embodiment 2 of the DPI call detail record detection method provided in this application;

[0041] Figure 4b A schematic diagram of the editing distance backtracking path for the DPI call detail record detection method provided in this application;

[0042] Figure 4c A schematic diagram of the matching results of the DPI call detail record detection method provided in this application based on the edit distance algorithm;

[0043] Figure 5a A flowchart illustrating Embodiment 3 of the DPI call detail record detection method provided in this application;

[0044] Figure 5b A flowchart of the asynchronous task for the DPI call detail record detection method provided in this application;

[0045] Figure 6This is a schematic diagram of the DPI call detail record (CDR) detection device provided in this application.

[0046] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0047] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0049] Existing technologies for XDR call detail record (CDR) detection primarily focus on performance testing of a single device, such as measuring uplink and downlink latency, software loading speed, and voice call quality at the terminal, and evaluating network commands by correlating these parameters with user experience. However, these detection schemes do not effectively monitor the generation process and accuracy of the XDR CDR itself, resulting in an inability to accurately assess data transmission, service processing, and network health in the 5G core network, and making it difficult to identify potential network anomalies and errors in CDR generation in a timely manner.

[0050] To address the aforementioned technical problems, the inventors recognized the need for a call detail record (CDR) detection technology to determine the accuracy of the XDR CDR generation process. Based on this, the inventors conceived of comparing the differences between the XDR CDR generated on the DPI side and the terminal-side benchmark XDR CDR. The terminal-side benchmark XDR CDR is generated after executing a standard test script and conforms to network standards. Through this comparison, the deviation and matching degree of the XDR CDR can be quantified, enabling detailed comparison of XDR CDR data across multiple key dimensions (such as service type, interface, service process, and DNN), thereby ensuring the correctness and reliability of XDR CDR generation.

[0051] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0052] Figure 1a Figure 1 shows the system architecture diagram of the DPI call detail record (CDR) detection method proposed in this application. As shown in Figure 1, to implement live network testing, the system includes the following modules:

[0053] The customized dial test terminal 101 is used to execute dial test scripts, generate signaling plane and user plane data, and send back dial test related information and baseline call detail records.

[0054] Terminal management platform 102 is used to manage customized terminals, complete device registration, status acquisition and task assignment, and collect test result files.

[0055] The task management module 103 is used to manage and orchestrate test tasks and manage the test execution history.

[0056] The data analysis module 104 is used to extract the Deep Packet Inspection (DPI) data of the core network and compare it with the baseline call detail record (CDR). Based on the comparison results, the quality of the Extended Detection and Response (XDR) CDR is evaluated.

[0057] The data operation module 105 is used to customize operation monitoring indicators based on the 3GPP protocol interface, services, and processes of the dial-up testing and monitoring, and to summarize and display the execution results of dial-up testing tasks; at the same time, it provides the trend of XDR call detail record quality changes based on the changes in indicators.

[0058] The monitoring and alarm module 106 is used to monitor operational indicators and generate and send relevant indicator alarms based on changes in thresholds.

[0059] Kafka message queue 107 is used to transmit task execution, termination, and asynchronous parsing and execution message commands.

[0060] The MySQL business database 108 is used to store the dial-up test service definition and historical execution data.

[0061] Object storage 109 is used to maintain the original baseline call detail records (CDRs) and the original traffic packet capture files.

[0062] Figure 1b The system architecture diagram of the DPI call detail record detection method provided in this application is a schematic diagram of the terminal management platform and the customized dialing test terminal.

[0063] like Figure 1b As shown, the terminal management platform includes:

[0064] Equipment Management Module: Responsible for equipment registration and equipment status maintenance.

[0065] Script Management Module: Responsible for customizing and saving standard test instruction scripts.

[0066] File management module: responsible for saving script files and execution result packet capture files.

[0067] Call detail record (CDR) generation module: Responsible for capturing packet data and generating baseline CDRs based on the execution of standard test commands.

[0068] Customized testing terminals include:

[0069] 5G module: Responsible for 5G communication and completing 4G / 5G signaling plane and user plane dial tests.

[0070] RJ45 network ports: Dual RJ45 network ports are used, one for fixed network command testing and the other for out-of-band management of the device.

[0071] Terminal Management Module: Responsible for managing local devices, scheduling the execution of actual test scripts on local devices, and upgrading local apps and testing software.

[0072] Local task caching module: Caches test execution tasks issued by the terminal management module to ensure that some test tasks can be executed correctly even when offline.

[0073] Raw Information Capture Module: Responsible for capturing raw data of user plane test commands. It can capture traffic of specific apps by AppID or process ID, reducing the impact of interference data on DPI call detail record monitoring results.

[0074] App test case execution module: Used to execute App probing scripts, start and control specific Apps to complete specific probing actions, and generate user plane data.

[0075] Browser test case execution module: Simulates a browser accessing a specific website, simulating the actual webpage browsing behavior of a user.

[0076] L4 / L7 layer protocol simulation module: Generates L4 / L7 layer protocols and generates specific data traffic through program scripts.

[0077] 5G Signaling Execution Module: Responsible for testing and executing 5G signaling plane commands.

[0078] Specifically, the customized test terminal receives test commands from the terminal management platform through the management module. After caching the test commands locally, the customized test terminal categorizes them and schedules different execution modules to perform test actions. Before execution, the raw data capture module is activated to capture traffic throughout the entire test process. During traffic capture, the raw traffic is filtered based on the AppID or process ID, filtering out interference traffic generated by other background apps due to communication. After the test command is completed, the customized test terminal uploads the execution record and raw data packet capture to the terminal management platform. The terminal management platform is responsible for temporarily storing the execution results. The call detail record (CDR) generation module parses the newly uploaded execution results and generates XDR CDRs. The CDR generation rules are consistent with those of the DPI base station. Furthermore, the execution process of the test commands, signaling plane, and user plane actions are all controlled by the terminal management platform and the customized terminal's execution scripts. Therefore, the CDRs generated by the CDR generation module fully reflect the command actions and execution process, and can be used as a benchmark CDR for comparison with DPI CDRs to verify DPI CDR quality.

[0079] Figure 2 This is a schematic diagram of the overall process of the DPI call detail record (CDR) detection method proposed in this application. Figure 2 As shown, the method includes:

[0080] S201, Define standard test command actions.

[0081] S202. According to the 3GPP protocol specifications, define the standard test instructions including the interface, service, process, minimum comparison unit, operation to call detail record (CDR) quantity ratio, and fields in the CDR that need to be compared.

[0082] S203. Set the standard test command execution parameters, arrange test tasks, select the terminal under test, and issue the execution task.

[0083] S204. The terminal under test receives and executes the test command, and after execution, reports the baseline call detail record and the raw traffic packet capture file.

[0084] S205. Based on the baseline call detail record (CDR) information, query the XDR CDR data of the production DPI in the big data platform.

[0085] S206. Based on the minimum comparison granularity, ratio, and key field information, complete the XDR call detail record comparison and field audit of DPI.

[0086] S207. Based on the comparison results, update the operational indicator data and alarm data.

[0087] Figure 3 This is a flowchart illustrating an embodiment of the DPI call detail record (CDR) detection method proposed in this application. Figure 3As shown, the method includes:

[0088] S301. Send a test call to the target terminal.

[0089] The test task includes at least one test script, which is pre-edited according to the business process. In this step, the test task is obtained by configuring the test task in the task management module 103 in Figure 1. The test task configuration process includes selecting and specifying the execution order of one or more test instructions.

[0090] Furthermore, before sending the test task to the target terminal, the method also includes:

[0091] Based on the business process defined by the 3GPP (3rd Generation Partnership Project) protocol, generate a test script for each service.

[0092] Configure at least one test script to generate a test task. The configuration operation includes sub-configuration operations for at least one of the following: execution order, number of executions, execution interval, server address to be accessed, and traffic protocol information of transport layer L4 / application layer L7 for different test scripts.

[0093] Before sending the call test task to the target terminal, the service call test script needs to be configured in advance to enable accurate monitoring and quality assessment of XDR call details.

[0094] Specifically, firstly, based on the various service processes defined in the 3GPP protocol, corresponding test scripts are generated. Each test script contains operational steps for a specific 5G service, edited according to different service requirements, including network uplink and downlink data transmission, latency assessment, call quality detection, and application performance testing. These test scripts can simulate the real-world service operations of the test terminal, enabling comprehensive network monitoring and diagnosis.

[0095] After generating the probing script, the probing task needs to be configured in the task management module 103 to allow users to fine-tune and control the probing script to adapt to testing needs in different scenarios. The configuration operation includes the following sub-operations:

[0096] (1) Execution order configuration: The execution order can be set for different test scripts. Different business processes may need to be executed in a certain order to ensure the accuracy of testing under different network conditions. For example, you can set the voice call test to be executed first, and then the data transmission test.

[0097] (2) Number of executions and frequency: The number of executions and frequency of the call test script can be configured according to business needs. For example, for monitoring the quality of voice calls, the call test script can be set to be executed once per hour, or the execution frequency can be adjusted according to the network operation status.

[0098] (3) Setting the execution interval: Users can also set the time interval between test scripts. For example, after completing a test task, users can set to wait a few minutes before executing the next test task to avoid overloading the network.

[0099] (4) Server address configuration: The server address that needs to be accessed in the test script can also be customized according to different business testing needs. For example, different URLs or API interfaces can be specified to test the performance of different applications or services in the 5G network.

[0100] (5) L4 / L7 traffic protocol configuration: For the configuration of transport layer (L4) and application layer (L7) protocol information, you can customize the traffic protocol information used in the test task. For example, you can test different protocols such as HTTP, HTTPS, and UDP to detect the transmission efficiency and stability of these protocols under different 5G network conditions.

[0101] After configuring the above parameters, multiple test scripts will be combined according to the configured execution order to generate the final test task. Finally, the test task is sent to the Kafka message queue 107 through the task management module 103, so that the Kafka message queue 107 can send the test task to the customized test terminal 101 through the terminal management platform 102, so that the target terminal can execute the test task.

[0102] Furthermore, a test call task is sent to the target terminal, including:

[0103] Send a test task to the Kafka queue so that the test task can be forwarded to the target terminal through the Kafka queue.

[0104] In this step, the entire test task execution process is completed through the asynchronous message module in the Kafka message queue 107 in Figure 1. The test task is sent from the task management module 102 to the target terminal through the Kafka message queue 107, ensuring that the test task can run stably in the complex 5G network environment, and making large-scale task distribution and real-time task tracking easier and more flexible.

[0105] S302. Obtain the target depth packet detection DPI call detail record data returned by the target terminal.

[0106] In this step, the target deep packet inspection (DPI) call detail record (CDR) data is generated by the target terminal after completing the call test task. The target terminal executes the call test task and captures raw data through a series of modules, thereby obtaining the target deep packet inspection (DPI) CDR data. This target deep packet inspection (DPI) CDR data is mainly used to evaluate the network quality of the 5G core network and the accuracy of CDR generation.

[0107] Furthermore, the target DPI call detail record (CDR) data returned by the target terminal is obtained, including:

[0108] Obtain the target DPI call detail record (CDR) data and target traffic data returned by the target terminal.

[0109] In this step, traffic data refers to the traffic data generated by the target terminal based on actual network interactions when executing the test task. After receiving the test task, the target terminal first caches the test instructions in the test task through a local caching module to ensure that no data is lost during task execution. Then, the local caching module classifies the test instructions according to their specific content and distributes the test task to different execution modules according to the type of instruction or execution requirements. For example, it assigns instructions to different execution logics based on the protocol type, data transmission method, or test requirements for subsequent execution.

[0110] Before executing the test, the target terminal will start the raw data capture module to capture network traffic throughout the entire test process, thereby capturing all data packets during the test execution, including detailed information on uplink and downlink traffic, such as data transmission rate, protocol type, and latency. During the capture process, the traffic filtering module filters the raw traffic based on AppID or process ID to ensure that the captured data comes purely from the current test task.

[0111] After the call test task is distributed to different execution modules, the scheduling module will be responsible for scheduling different execution modules to perform the corresponding test actions. For example, the command for network performance testing will schedule the corresponding module to perform data transmission, latency testing and other operations, while the command for voice call testing will schedule the voice module to perform the call test.

[0112] After completing the dial-up test, the target terminal will upload the DPI call detail record data and the captured traffic data to the terminal management platform 102. The terminal management platform 102 will temporarily store these execution records and data packets for subsequent diagnosis of network anomalies, traffic anomalies and other situations in specific tasks.

[0113] S303. Based on the DPI base call detail record generation strategy and the target DPI call detail record data, generate the target XDR call detail record data corresponding to the DPI call detail record data.

[0114] Among them, the DPI base generation call detail record strategy defines how to extract key information from the target DPI call detail record data and generate extended detection and response (XDR) call detail record data according to preset rules. The target XDR call detail record data is a standardized call detail record widely used in 5G networks to help operation and maintenance personnel fully understand the network's service quality, user experience, and traffic information.

[0115] This step primarily involves analyzing the target DPI call detail record (CDR) data through the CDR generation module to generate the target XDR CDR. Specifically, the CDR generation module receives the latest uploaded target DPI CDR data from the terminal management platform 102, then processes each CDR data entry according to the DPI base generation strategy to generate the target XDR CDR. This ensures that the content and structure of the target XDR CDR conform to 5G network operation standards. The target XDR CDR contains various key indicators of network service quality, allowing operations and maintenance personnel to assess network performance and promptly identify potential problems.

[0116] S304. Based on the parameter information of the target XDR call detail record data, determine the XDR call detail record data to be tested from the DPI call detail record data to be tested.

[0117] The XDR call detail record (CDR) data to be tested is generated based on the DPI base station CDR generation strategy, and the parameter information of the XDR CDR data to be tested is the same as that of the target XDR CDR data.

[0118] The target XDR call detail record (CDR) data generated during the test on the target terminal mainly includes the following key parameters: the target terminal's region code, interface, service type, International Mobile Subscriber Identity (IMSI), Mobile Station International Subscriber Directory Number (MSID), start time, and end time. Specifically, the region code identifies the geographical area where the test terminal is located; the interface identifies the network access interface type; the service type describes the specific network service being performed, such as data transmission or voice calls; the IMSI uniquely identifies the user; the MSISDN associates the user's phone number; and the start and end times record the start and end times of the test task, ensuring that all network interactions are captured and recorded within this timeframe.

[0119] After the target terminal completes the dialing test, the generated target XDR call detail record (CDR) data is uploaded to the data analysis module 104 (as shown in Figure 1). The data analysis module 104 then queries the generated DPI CDR data from the big data platform based on the aforementioned parameter information in the target XDR CDR data. Specifically, the data analysis module 104 uses the parameter information of the target XDR CDR data as a filtering condition to retrieve matching DPI CDR data from the big data platform.

[0120] After determining the DPI call detail record (CDR) data that matches the parameter information of the target XDR CDR data, the key parameter information in the DPI CDR data is extracted according to the strategy of generating CDRs based on the DPI base. This ensures that the information is consistent with the parameters in the target XDR CDR data. Then, the corresponding XDR CDR data to be tested is generated to ensure the consistency of the XDR CDR data to be tested with the target XDR CDR data in terms of structure and content.

[0121] S305. Based on the ratio between the operation and the XDR call detail record data, the predefined minimum comparison unit, and the preset fields, the target XDR call detail record data and the XDR call detail record data to be tested are detected, and the detection results are generated.

[0122] The test results are used to indicate whether there are any anomalies in the XDR call detail record data under test, so as to ensure the accuracy of the XDR call detail record data under test.

[0123] In this step, the first step is to define the minimum comparison units used for detection. These units ensure consistency between the target XDR call detail record (CDR) data and the CDR CDR data under test. The minimum comparison units include the interface, service identifier, service process, and DNN.

[0124] For example, the interface is used to identify different network interface types (such as S1, S5, S11, etc.), and during testing, it is ensured that the interfaces used in the target XDR call detail record and the XDR call detail record under test are consistent; the service identifier is used to indicate the specific service type, such as voice call, data transmission, video stream, etc.; the service process refers to the specific execution steps or sequence of network services, such as call setup for making a phone call, data transmission setup, etc.; the DNN (Data Network Name) is used to identify different data networks, such as distinguishing data streams accessing the Internet, private networks, or specific application services. By comparing the DNN, it is ensured that the data network names recorded in the two XDR call detail records are consistent.

[0125] When testing XDR call detail records (CDRs), the ratio between the number of operations performed in the test task and the actual number of XDRs is used for evaluation. This ratio reflects the relationship between the number of XDRs generated during the test task and the actual number of task executions. It ensures that the quantity and frequency of generated XDRs match the number of operations performed. An abnormal ratio indicates potential omissions or redundancy in XDRs. Specifically, based on the number of test task executions, time, and operational procedures, the target number of XDRs to be generated is calculated and compared with the number of XDRs under test.

[0126] During the testing process, comparisons are also made based on predefined key fields. For example, the field information in the target XDR call detail record (CDR) data is compared one by one with the field information in the XDR CDR under test to ensure that all fields are consistent.

[0127] After completing the detection of the smallest comparison unit, preset fields, and ratio, a detection result will be generated, which indicates whether the XDR call detail record data under test matches the target XDR call detail record data.

[0128] Furthermore, when the test results indicate that there is an anomaly in the XDR call detail record data under test, an alarm message is output.

[0129] In this step, if the target XDR call detail record (CDR) data matches the CDR data under test, a "pass" result will be output, indicating that the CDR generation meets expectations and the data is normal. If inconsistencies are found during the comparison process (e.g., interface mismatch, incorrect service identifier, missing service process, etc.), an "abnormal" result will be generated, and an alarm message will be output.

[0130] Alarm information is used to indicate the type of anomaly, that is, to indicate the problematic field or process, for subsequent investigation and correction. Alarm information can be divided into the following types: success rate / failure rate alarms, number of lost / duplicate call detail records (CDRs) per unit time alarms, cumulative number of lost / duplicate CDRs per interface alarms, and abnormal field alarms.

[0131] The above embodiment sends the test task to the target terminal, so that the target terminal generates DPI call detail records and traffic data when executing the task. Then, according to the DPI base generation strategy, target XDR call detail record data and XDR call detail record data to be tested are generated. The call detail record data is compared in detail according to the smallest comparison unit (such as interface, service identifier, service process, DNN, etc.) to determine whether the XDR call detail record to be tested meets the expected standard, and can accurately detect the accuracy of the XDR call detail record data to be tested.

[0132] Figure 4a This is a flowchart illustrating Embodiment Two of the DPI call detail record (CDR) detection method provided in this application. Figure 4aAs shown in Example 1, based on the target XDR call detail record (CDR) data, the test XDR CDR data is detected, and a detection result is generated. This step can also be implemented using the "edit distance algorithm," which compares the two sets of CDRs and provides a quantified matching index between them. This includes:

[0133] S401. Initialization and preparation.

[0134] In this step, based on the edit distance algorithm, the following definitions are made: LD(A, B) represents the edit distance between two strings A and B. If LD(A, B) = 0, it means that A and B are completely identical. Here, A = a1a2a3…aN, indicating that string A consists of N strings from a1 to aN; B = b1b2b3…bM, indicating that string B consists of M strings from b1 to bM.

[0135] The target XDR call detail record (CDR) is represented by string A, and the DPI CDR to be tested is represented by string B. Each set of CDRs contains multiple CDR records, and each record includes key information such as service type, service process, DNN, start time, and end time. Based on this information, the two sets of CDRs are initialized into two string sequences for further processing.

[0136] Specifically, two call detail records (CDRs) ai and bj are considered to match if they simultaneously meet the following conditions:

[0137] ai[business] = bj[business]; ai[process] = bj[process]; ai[DNN] = bj[DNN]; ai[start time] <= bj[start time]; ai[end time] or ai+1[start time] >= bj[end time].

[0138] S402, Filter DPI call detail records.

[0139] Before making the comparison, the DPI call detail record queue is first filtered according to the following rules:

[0140] b1[start time]>=a1[start time]; bN[end time]<=aN[end time].

[0141] This step ensures that the data in the DPI call detail record queue is consistent with the baseline call detail record queue in terms of time, reducing irrelevant data in the comparison.

[0142] S403, Matrix initialization for the edit distance algorithm.

[0143] In this step, a matrix of size (m+1)x(n+1) is initialized according to the edit distance algorithm, where m is the length of the target XDR call detail record data A and n is the length of the DPI call detail record data B to be tested. A=[a,b,c,d,e,f,g,h] and B=[1,b,b,4,f,g,h,h,9,z,x]. The first row and the first column of the matrix are initialized to a sequence of numbers from 0 to m / n.

[0144] S404, Filling matrix.

[0145] In this step, each cell in the matrix will be filled according to the following rules:

[0146] If A[i-1]==B[j-1] (i.e. the call detail records are the same), then D[i][j]=D[i-1][j-1].

[0147] Otherwise, D[i][j] = min(D[i-1][j], D[i][j-1], D[i-1][j-1]) + 1, where:

[0148] D[i-1][j] represents a deletion operation, indicating that a DPI call detail record (CDR) has been lost. D[i][j-1] represents an insertion operation, indicating that there are duplicate or redundant CDRs in the DPI CDR. D[i-1][j-1] represents a replacement operation, indicating that the DPI CDR does not match the baseline CDR.

[0149] This step allows you to calculate the edit distance between the two sets of call detail records (CDRs), i.e., how many operations are needed to convert a DPI CDR into a base CDR.

[0150] S405. Calculate edit distance and matching degree.

[0151] After the matrix is ​​filled, the value D[m][n] in the lower right corner of the matrix represents the edit distance between the two sets of call detail records (CDRs). An edit distance of 0 indicates that the two sets of CDRs are a perfect match; the larger the edit distance, the greater the difference between the CDRs. For example, if the edit distance is 8, it means that there are 8 CDRs that do not match or have differences.

[0152] S406. Backtrack to obtain matching results and generate matching results.

[0153] In this step, backtracking is performed based on the edit distance matrix to determine the specific matching details of the call detail records (CDRs). The backtracking rules are as follows:

[0154] If ai==bj, then backtrack to the top left corner, indicating call detail record matching.

[0155] If ai≠bj, then backtrack to the cell with the smallest value among the top-left, top-left, and left-right cells, with the priority being: top-left > top-left > left-right. Based on the backtracking result, it can be determined whether the call detail record is lost, duplicated, or mismatched.

[0156] Finally, by backtracking, the matching results of the two sets of call detail records (CDRs) can be obtained. For example, there are 4 matched CDRs, 1 lost CDR, and 6 erroneous or duplicate CDRs.

[0157] In practical applications, to improve algorithm efficiency and reduce memory consumption, call detail records (CDRs) can be grouped for comparison. The grouping rule is as follows: CDRs are divided into multiple independent sequences to be compared based on the smallest comparison unit (interface, service type, service process, DNN), prioritizing the grouping by interface-service-process-DNN. Each independent sequence is then compared with a baseline CDR. This grouped comparison effectively reduces time and space complexity, avoiding performance issues during large-scale CDR comparisons.

[0158] S408, Output the detection results.

[0159] In this step, a quantified detection report is generated based on the edit distance and backtracking path. The report includes: the matching degree of the two sets of call detail records (CDRs); the specific CDRs with discrepancies and their reasons (loss, duplication, or mismatch). Additionally, this embodiment provides an automatic repair or retry mechanism; for problematic CDRs, the system can trigger a re-capture and regeneration process.

[0160] The above embodiments accurately calculate the deviation between the XDR call detail records generated by the DPI side and the reference XDR call detail records on the terminal side through the edit distance algorithm, and quantitatively evaluate the quality of the XDR call detail records. It can efficiently and accurately determine the deviation field between the XDR call detail records generated by the DPI side and the reference call detail records.

[0161] Figure 4b This is a schematic diagram of the edit distance backtracking path for the DPI call detail record (CDR) detection method provided in this application. Figure 4b As shown in the figure, based on Example 2, a result diagram of backtracking based on the edit distance matrix is ​​presented, which can intuitively determine the specific matching situation of the call detail record.

[0162] Figure 4c This diagram illustrates the matching results of the DPI call detail record (CDR) detection method based on the edit distance algorithm provided in this application. Figure 4c As shown in the figure, based on Example 2, a matching result diagram is shown where there are 4 matched call records, 1 lost call record, and 6 erroneous or duplicate call records.

[0163] Figure 5a This is a flowchart illustrating Embodiment 3 of the DPI call detail record (CDR) detection method provided in this application. Figure 5a As shown, based on Embodiment 1, the method further includes sending a test call task to the target terminal.

[0164] S501, Test Task Encapsulation.

[0165] In this step, the detailed configuration parameters in the probing task (such as the execution order, number of times, frequency, access address, L4 / L7 protocol, etc. of the probing script) are first converted into a data format that can be transmitted via Kafka messages. Then, a unique task ID is assigned to each Kafka message for subsequent task tracking and status monitoring.

[0166] S502, Send the test task to the Kafka queue.

[0167] After the probing task is encapsulated, each Kafka message corresponding to the probing task is sent to a Kafka queue. The Kafka message queue 107 contains an asynchronous message execution module, which is the core component of the entire probing task execution process. This module includes a Kafka producer, a consumer, and a business logic module. The producer's role is to send the probing task to the designated Kafka queue after the task management module 102 generates it. The consumer's role is to allow the target terminal to act as a Kafka consumer, listening to and consuming the probing tasks in the Kafka queue.

[0168] Furthermore, different states correspond to different asynchronous message execution modules, which handle specific tasks based on the task status. Specifically, the message consumer processes task status. For example, when a testing task enters the execution state, the relevant module retrieves the task's status message through Kafka message queue 107, executes the task, and updates the task status to "completed" or "failed" upon completion. After the task is completed, the asynchronous message execution module pushes the updated status message back to Kafka message queue 107 so that the next module can receive and process it. For instance, if a task fails, the system can re-execute the failed steps using the retry mechanism of Kafka message queue 107.

[0169] S503, Re-execution and status update of the test task.

[0170] In this step, if a test task fails during execution, its status will be modified, and the relevant module will be notified to re-execute it via Kafka message queue 107. For example, a re-executed task might re-fetch XDR call detail record data generated by the DPI side and re-analyze it according to the new rules. Furthermore, Kafka message queue 107's asynchronous message processing mechanism ensures automated task management and state transitions. For instance, when a task is re-executed after a failure, the system can automatically update the task status and decide whether to continue to the next step or retry based on the execution result.

[0171] The above embodiment utilizes Kafka message queue 107 to distribute and manage the status of testing tasks. Kafka producers and consumers are responsible for task generation and execution, respectively. The asynchronous message execution module ensures correct processing of tasks under different states through dynamic task status transitions. When a task fails, a retry can be initiated by modifying the task status, allowing for the re-retrieval and analysis of DPI call detail record (CDR) data, thereby ensuring the monitoring and verification of XDR CDR quality and service performance in the 5G core network.

[0172] Figure 5b The flowchart shows the asynchronous task of the dialing test for the DPI call detail record (CDR) detection method provided in this application. Figure 5b As shown, the execution of a test task involves a continuous change in its state from start to finish. Furthermore, in some scenarios where execution fails, this step can be re-executed by repeating the process. By modifying the test task state, the task can be re-executed, DPI call detail record data can be re-captured, and test cases can be re-analyzed or re-analyzed according to new rules.

[0173] The entire execution process is accomplished through Kafka message queues and asynchronous message execution modules. The asynchronous message execution model includes message consumers, producers, and business logic modules. Different states correspond to different asynchronous message execution modules. Each module focuses on a specific state of the task being executed; after receiving a message, it only handles the business logic relevant to its module. Once processing is complete, it advances the message to the next state and sends a state change message. Through the direct cooperation of these various state message processing modules, the entire message execution process is ultimately completed.

[0174] Figure 6 This is a schematic diagram of the DPI call detail record (CDR) detection device provided in this application. Figure 6 As shown, the DPI call detail record (CDR) detection device 60 includes:

[0175] The test task sending module 601 is used to send a test task to the target terminal. The test task includes at least one test script, which is pre-edited according to the business process.

[0176] DPI call detail data acquisition module 602 is used to acquire target depth packet detection DPI call detail data returned by the target terminal. The target DPI call detail data is the DPI call detail data generated by the target terminal when performing the dialing test task.

[0177] XDR call detail record (CDR) data generation module 603 is used to generate target XDR CDR data corresponding to the target DPI CDR data based on the DPI base CDR generation strategy and target DPI CDR data.

[0178] The XDR call detail record (CDR) data determination module 604 is used to determine the XDR CDR data to be tested from the DPI CDR data to be tested based on the parameter information of the target XDR CDR data. The XDR CDR data to be tested is generated based on the DPI base CDR generation strategy, and the parameter information of the XDR CDR data to be tested is the same as the parameter information of the target XDR CDR data.

[0179] The detection result generation module 605 is used to detect the target XDR call detail record data and the XDR call detail record data to be tested based on the ratio between the operation and the XDR call detail record data, the predefined minimum comparison unit, and the preset fields, and generate detection results.

[0180] The smallest comparison unit includes the interface, service identifier, service process, and DNN. The detection result is used to indicate whether there are any anomalies in the XDR call detail record data under test.

[0181] The parameter information in the XDR call detail record (CDR) determination module 604 includes the target terminal's area code, interface, service type, International Mobile Subscriber Identity (IMSI), International Mobile Subscriber Directory Number (MSIDN), start time, and end time.

[0182] The test task sending module 601 is also used to send test tasks to the Kafka queue so that the test tasks can be forwarded to the target terminal through the Kafka queue.

[0183] The test task sending module 601 is also used to generate test scripts for each service according to the business process defined by the 3GPP protocol for each service.

[0184] Configure at least one test script to generate a test task. The configuration operation includes sub-configuration operations for at least one of the following: execution order, number of executions, execution interval, server address to be accessed, and traffic protocol information of transport layer L4 / application layer L7 for different test scripts.

[0185] When the detection result generation module 605 indicates that there is an anomaly in the XDR call detail record data under test, the detection result generation module 605 outputs an alarm message, which is used to indicate the type of anomaly.

[0186] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 70 includes:

[0187] The electronic device 70 may include a processor 701 with one or more processing cores, a memory 702 with one or more computer-readable storage media, a communication component 703, and other components. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0188] In the specific implementation process, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to execute the DPI call detail record detection method as described above.

[0189] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0190] In the above Figure 7 In the illustrated embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0191] The memory may include high-speed memory (Random Access Memory, RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0192] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0193] In some embodiments, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps in any of the DPI call detail record detection methods described above.

[0194] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0195] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0196] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute the steps in any of the DPI call detail record detection methods provided in embodiments of this application.

[0197] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0198] According to one aspect of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium.

[0199] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0200] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0201] It should be further noted that although the steps in the flowchart 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 steps in the flowchart 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. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0202] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0203] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

Claims

1. A DPI call detail record (CDR) detection method, characterized in that, include: Send a test task to the target terminal. The test task includes at least one test script, which is pre-edited according to the business process. Obtain the target depth packet detection DPI call detail data returned by the target terminal, wherein the target DPI call detail data is the DPI call detail data generated by the target terminal when performing the dialing test task; Based on the DPI base call detail record generation strategy and the target DPI call detail record data, generate the target extended detection and response XDR call detail record data corresponding to the DPI call detail record data. Based on the parameter information of the target XDR call detail record (CDR) data, the XDR CDR data to be tested is determined from the DPI CDR data to be tested. The XDR CDR data to be tested is generated based on the CDR generation strategy of the DPI base. The parameter information of the XDR CDR data to be tested is the same as the parameter information of the target XDR CDR data. Based on the ratio between the operation and the XDR call detail record data, the predefined minimum comparison unit, and preset fields, the target XDR call detail record data and the XDR call detail record data to be tested are detected, and a detection result is generated. The minimum comparison unit includes an interface, a service identifier, a service process, and a DNN. The detection result is used to indicate whether there are any anomalies in the XDR call detail record data to be tested.

2. The method according to claim 1, characterized in that, The parameter information includes the target terminal's region code, interface, service type, International Mobile Subscriber Identity (IMSI), International Mobile Subscriber Number (MSID), start time, and end time.

3. The method according to claim 1, characterized in that, The step of obtaining the target DPI call detail record data returned by the target terminal includes: Obtain the target DPI call detail record data and target traffic data returned by the target terminal. The traffic data is the traffic data generated by the target terminal when performing the dialing test task.

4. The method according to claim 1, characterized in that, Sending the test call task to the target terminal includes: The test task is sent to the Kafka queue so that the test task can be forwarded to the target terminal through the Kafka queue.

5. The method according to claim 1, characterized in that, Before sending the test task to the target terminal, the method further includes: Based on the business process defined by the 3GPP (3rd Generation Partnership Project) protocol, generate a test script for each service. Configure at least one test script to generate the test task. The configuration operation includes sub-configuration operations for at least one of the following: execution order, number of executions, execution interval, server address to be accessed, and traffic protocol information of transport layer L4 / application layer L7 for different test scripts.

6. The method according to claim 1, characterized in that, The method further includes: When the detection result indicates that there is an anomaly in the XDR call detail record data under test, an alarm message is output, which is used to indicate the type of anomaly.

7. A DPI call detail record (CDR) detection device, characterized in that, include: The test task sending module is used to send a test task to the target terminal. The test task includes at least one test script, which is pre-edited according to the business process. The DPI call detail data acquisition module is used to acquire the target depth packet detection DPI call detail data returned by the target terminal. The target DPI call detail data is the DPI call detail data generated by the target terminal when performing the dialing test task. The XDR call detail record (CDR) data generation module is used to generate target extended detection and response (XDR) CDR data corresponding to the target DPI CDR data based on the DPI base CDR generation strategy and the target DPI CDR data. The XDR call detail record (CDR) data determination module is used to determine the XDR CDR data to be tested from the DPI CDR data to be tested based on the parameter information of the target XDR CDR data. The XDR CDR data to be tested is generated based on the DPI base CDR generation strategy, and the parameter information of the XDR CDR data to be tested is the same as the parameter information of the target XDR CDR data. The detection result generation module is used to detect the target XDR call detail record data and the XDR call detail record data to be tested based on the ratio between the operation and the XDR call detail record data, the predefined minimum comparison unit, and the preset fields, and generate detection results.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.

Images