DPI call ticket detection method, device, equipment, medium and product

Abstract

The invention provides a DPI call ticket detection method and device, equipment, a medium and a product. The method comprises the following steps: sending a dial testing task to a target terminal, wherein the dial testing task comprises at least one dial testing script; obtaining target DPI call ticket data returned by the target terminal, wherein the target DPI call ticket data is DPI call ticket data generated when the target terminal executes the dial test task; generating target XDR call ticket data corresponding to the target DPI call ticket data according to a DPI base generation call ticket generation strategy and the target DPI call ticket data; according to the parameter information of the target XDR call ticket data, XDR call ticket data to be tested are determined from the DPI call ticket data to be tested, and the parameter information of the XDR call ticket data to be tested is the same as the parameter information of the target XDR call ticket data; and detecting the XDR call ticket data to be detected according to the target XDR call ticket data to generate a detection result. According to the technical scheme, the quality of the XDR call ticket is detected and evaluated, and the accuracy and reliability of DPI call ticket detection are improved.

Description

Technical Field

[0001] The present application relates to the field of DPI call record technology, and in particular to a DPI call record detection method, device, equipment, medium and product. Background Art

[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) contains these analysis results and other related information for network management and optimization, billing, security monitoring and other aspects.

[0003] Existing XDR call record detection technology mainly uses terminals to check network uplink and downlink delays, software loading speed, and voice call quality, and establishes the relationship between delay, rate-related parameters and user experience to evaluate XDR call records.

[0004] However, existing detection technologies cannot accurately evaluate the quality and correctness of XDR call records themselves. Summary of the invention

[0005] The present application provides a DPI call record detection method, device, equipment, medium and product to solve the technical problem in the prior art that the quality and correctness of the XDR call record itself cannot be accurately evaluated.

[0006] In a first aspect, the present application provides a method for DPI call record detection, comprising:

[0007] Sending a dial test task to a target terminal, the dial test task includes at least one dial test script, and the dial test script is pre-edited according to the business process;

[0008] Obtain the target deep packet inspection DPI call bill data returned by the target terminal. The target DPI call bill data is the DPI call bill data generated by the target terminal when executing the dial test task.

[0009] Generate target extended detection and response XDR call bill data corresponding to the DPI call bill data according to the call bill generation strategy generated by the DPI base and the target DPI call bill data;

[0010] According to the parameter information of the target XDR call bill data, the XDR call bill data to be tested is determined from the DPI call bill data to be tested, the XDR call bill data to be tested is generated based on the call bill generation strategy of the DPI base, and the parameter information of the XDR call bill data to be tested is the same as the parameter information of the target XDR call bill data;

[0011] The XDR call record data to be tested is tested according to the target XDR call record data to generate a test result, which is used to indicate whether the XDR call record data to be tested has an abnormality.

[0012] Optionally, the XDR call record data to be tested is tested according to the target XDR call record data to generate a test result, including:

[0013] According to the ratio between the operation and the XDR call record data, the predefined minimum comparison unit and the preset field, the target XDR call record data and the XDR call record data to be tested are tested to generate a test result.

[0014] Among them, the minimum comparison unit includes interface, business identifier, business process and DNN.

[0015] Optionally, the parameter information includes the area code, interface, service type, international mobile user identity code IMSI, mobile station international user directory number MSISDN, start time and end time of the target terminal.

[0016] Optionally, the target DPI call record data returned by the target terminal is obtained, including:

[0017] Get the target DPI call list data and target traffic data returned by the target terminal. The traffic data is the traffic data generated by the target terminal when executing the dial test task.

[0018] Optionally, sending a dial test task to a target terminal includes:

[0019] Send the dial test task to the Kafka queue to forward the dial test task to the target terminal through the Kafka queue.

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

[0021] Generate a dial test script for each service based on the service flow of each service defined by the 3rd Generation Partnership Project 3GPP protocol;

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

[0023] Optionally, the method further comprises:

[0024] When the detection result indicates that the XDR call record data to be tested is abnormal, an alarm message is output, and the alarm message is used to indicate the type of abnormality.

[0025] In a second aspect, the present application proposes a DPI call record detection device, comprising:

[0026] A dial test task sending module is used to send a dial test task to a target terminal. The dial test task includes at least one dial test script. The dial test script is edited in advance according to the business process.

[0027] The DPI call bill data acquisition module is used to obtain the target deep packet inspection DPI call bill data returned by the target terminal. The target DPI call bill data is the DPI call bill data generated by the target terminal when executing the dialing test task;

[0028] An XDR call sheet data generation module is used to generate a call sheet generation strategy and target DPI call sheet data according to the DPI base, and generate target extended detection and response XDR call sheet data corresponding to the target DPI call sheet data;

[0029] The module for determining XDR call bill data to be tested is used to determine the XDR call bill data to be tested from the DPI call bill data to be tested according to the parameter information of the target XDR call bill data, the XDR call bill data to be tested is generated based on the call bill generation strategy generated by the DPI base, and the parameter information of the XDR call bill data to be tested is the same as the parameter information of the target XDR call bill data;

[0030] The detection result generating module is used to detect the XDR call record data to be tested according to the target XDR call record data and generate a detection result, wherein the detection result is used to indicate whether there is an abnormality in the XDR call record data to be tested.

[0031] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0032] Memory stores computer-executable instructions;

[0033] The processor executes the computer-executable instructions stored in the memory to implement the method of the embodiment of the present application.

[0034] In a fourth aspect, the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method of the embodiment of the present application.

[0035] In a fifth aspect, the present application provides a computer program product, including a computer program, which implements the method of any one of the first aspects when executed by a processor.

[0036] The DPI call bill detection method, device, equipment, medium and product provided in the present application determine the dialing task according to the business process, and send the dialing task to the target terminal to obtain the target deep packet detection DPI call bill data returned by the target terminal; then generate the call bill generation strategy and the target DPI call bill data according to the DPI base, and generate the target XDR call bill data corresponding to the DPI call bill data; then determine the XDR call bill data to be tested from the DPI call bill data to be tested according to the parameter information of the target XDR call bill data; detect the XDR call bill data to be tested according to the target XDR call bill data, and generate a detection result, thereby realizing the detection and evaluation of the quality of the XDR call bill itself, and improving the accuracy and reliability of DPI call bill detection. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 1a This is a system architecture diagram of the DPI call record detection method proposed in this application;

[0039] Figure 1b A schematic diagram of the structure of the terminal management platform and the customized dial test terminal in the system architecture diagram of the DPI call record detection method provided in this application;

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

[0041] Figure 3 This is a flow chart of the first embodiment of the DPI call record detection method proposed in this application;

[0042] Figure 4a A flow chart of the second embodiment of the DPI call record detection method provided by the present application;

[0043] Figure 4b A schematic diagram of the edit distance backtracking path of the DPI call record detection method provided in this application;

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

[0045] Figure 5a A flowchart of the third embodiment of the DPI call record detection method provided by the present application;

[0046] Figure 5b Asynchronous task flow chart of the dialing task of the DPI call record detection method provided in this application;

[0047] Figure 6A schematic diagram of the structure of the DPI call record detection device provided in this application;

[0048] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0049] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0050] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0051] In the existing technology, XDR call record detection mainly focuses on the performance detection of a certain end device, such as detecting uplink and downlink delays, software loading speed, and voice call quality through the terminal, and evaluating network instructions through the correlation between these parameters and user experience. However, these detection schemes do not directly monitor the generation process and accuracy of the XDR call record itself, resulting in the inability to accurately evaluate the data transmission, service processing, and network health status in the 5G core network, and it is difficult to timely identify potential network anomalies and errors in call record generation.

[0052] In response to the above technical problems, the inventors realized that it is necessary to propose a call record detection technology to determine the accuracy of the XDR call record generation process. Based on this, the inventors thought of comparing the differences between the XDR call record generated on the DPI side and the benchmark XDR call record on the terminal side, where the benchmark XDR call record on the terminal side is an XDR call record generated after executing a standard test script, which complies with network standards. Through the above comparison, the deviation and matching degree of the XDR call record can be quantified, and then a detailed comparison of the XDR call record data can be achieved under multiple key dimensions (such as business type, interface, business process and DNN, etc.), thereby ensuring the correctness and reliability of the XDR call record generation.

[0053] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0054] Figure 1a This is the system architecture diagram of the DPI call record detection method proposed in this application. As shown in Figure 1, in order to implement the current network dial test, the system includes the following modules:

[0055] The customized dial test terminal 101 is used to execute the dial test script, generate signaling plane and user plane data, and return dial test related information and benchmark call records.

[0056] The terminal management platform 102 is used to manage customized terminals, complete device registration, status acquisition and task issuance, and collect dialing test related result files.

[0057] The task management module 103 is used to manage and arrange dialing test tasks and manage the dialing test execution history.

[0058] The data analysis module 104 is used to complete the extraction of the core network's deep packet inspection (DPI) data and compare it with the benchmark call record, and evaluate the quality of the extended detection and response (XDR) call record based on the comparison results.

[0059] The data operation module 105 is used to monitor the Third Generation Partnership Project (3GPP) protocol interface, business, and process according to the dial test, customize the operation monitoring indicators, and summarize and display the execution results of the dial test task; at the same time, provide the change trend of the XDR call record quality according to the change of the indicators.

[0060] The monitoring and alarm module 106 is used to monitor the operation indicators and generate and send relevant indicator alarms according to the changes in thresholds.

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

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

[0063] Object storage 109 is used to store original benchmark call record files and original traffic packet capture files.

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

[0065] like Figure 1b As shown in the figure, the terminal management platform includes:

[0066] Device management module: responsible for device registration and device status maintenance.

[0067] Script management module: responsible for customizing and saving standard test instruction scripts.

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

[0069] Call record generation module: responsible for capturing file data and generating benchmark call records based on the execution of standard test instructions.

[0070] Customized dial test terminal includes:

[0071] 5G module: responsible for 5G communication and completing 4 / 5G signaling plane and user plane dialing tests.

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

[0073] Terminal management module: responsible for local device management, scheduling the actual test script execution of local devices, and upgrading local apps and dial-up test software.

[0074] Local task cache module: caches the test execution tasks issued by the terminal management module to ensure that certain test tasks can be correctly executed even in offline conditions.

[0075] Original information capture module: responsible for capturing the original data of user-side test instructions. It can capture specific App traffic by AppID or process number to reduce the impact of interference data on DPI call bill monitoring results.

[0076] App use case execution module: used to execute App dialing scripts, start and control specific Apps to complete specific dialing actions, and generate user plane data.

[0077] Browser use case execution module: simulates the browser accessing a specific website and simulates the user's actual web browsing behavior.

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

[0079] 5G signaling execution module: responsible for the execution of 5G signaling plane command tests.

[0080] Specifically, the customized dial test terminal receives the test instructions sent by the terminal management platform through the management module. After the customized dial test terminal caches the test instructions through the local cache module, it schedules different execution modules to execute the test actions according to the test instruction classification. Before executing the action, the original data capture module is started to capture the traffic of the entire test process. The traffic capture process filters the original traffic according to the AppID or process ID, and filters the interference traffic generated by other background apps due to communication. After the dial test instruction is completed, the customized dial test terminal uploads the execution record and the original data capture package to the terminal management platform. The terminal management platform is responsible for temporarily storing the execution results. The call record generation module parses the newly uploaded execution results and generates an XDR call record. The call record generation module generates the same rules as the DPI base generates the call record. At the same time, the dial test instruction execution process, signaling plane and user plane actions are all controlled by the terminal management platform and the customized terminal execution script. Therefore, the call record generated by the call record generation module can fully reflect the instruction action and execution process, so it can be used as a benchmark call record and compared with the DPI call record to verify the quality of the DPI call record.

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

[0082] S201. Define standard test instruction actions.

[0083] S202. According to the 3GPP protocol specification, define the interfaces, services, processes, i.e., the minimum comparison units, the ratio of operations to call records, and the fields in the call records that need to be compared, included in the standard test instructions.

[0084] S203: Set standard test instruction execution parameters, arrange test tasks, select the terminal to be tested and issue execution tasks.

[0085] S204: The tested terminal receives and executes the tested instruction, and reports a reference call list and an original traffic packet capture file after execution.

[0086] S205. According to the benchmark call bill information, query the XDR call bill data of the production DPI in the big data base.

[0087] S206: Complete the XDR call record comparison and field audit of DPI according to the minimum comparison granularity, ratio, and key field information.

[0088] S207. Update the operation indicator data and the alarm data according to the comparison result.

[0089] Figure 3 This is a flow chart of the first embodiment of the DPI call record detection method proposed in this application. Figure 3As shown, the method includes:

[0090] S301. Send a dialing task to a target terminal.

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

[0092] Furthermore, before sending the dialing test task to the target terminal, the method further includes:

[0093] Generate a dial test script for each service based on the service flow of each service defined by the 3rd Generation Partnership Project 3GPP protocol;

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

[0095] Before sending a dial test task to the target terminal, you need to pre-configure the service dial test script to achieve accurate monitoring and quality assessment of XDR call records.

[0096] Specifically, firstly, according to the business processes defined in the 3GPP protocol, the corresponding dialing test scripts are generated. Each dialing test script contains the operation steps for a specific 5G business, that is, it is edited according to the different needs of the business, including network uplink and downlink data transmission, latency evaluation, call quality detection, application performance testing, etc. Through these dialing test scripts, the real business operation of the dialing test terminal can be simulated to achieve comprehensive monitoring and diagnosis of the network.

[0097] After the dial test script is generated, the configuration operation of the dial test task needs to be completed in the task management module 103 to allow the user to fine-tune and control the dial test script to meet the test requirements of different scenarios. The configuration operation includes the following sub-operations:

[0098] (1) Configuration of execution order: For different dial test scripts, you can set the execution order. Different business processes may need to be executed in a certain order to ensure the accuracy of the test under different network conditions. For example, you can set it to execute the voice call test first, and then the data transmission test.

[0099] (2) Execution times and frequency: The execution times and frequency of the dial test script can be configured according to business needs. For example, for voice call quality monitoring, the call dial test script can be set to execute once every hour, or the execution frequency can be adjusted according to the network operation status.

[0100] (3) Setting the execution interval: Users can also set the time interval between dial-up test scripts. For example, after completing a dial-up test task, you can set it to wait for a few minutes before executing the next dial-up test task to avoid excessive load on the network.

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

[0102] (5) Configuration of L4 / L7 traffic protocols: For the configuration of transport layer (L4) and application layer (L7) protocol information, you can customize the traffic protocol information used in the dial-up 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.

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

[0104] Furthermore, sending a dial test task to the target terminal includes:

[0105] Send the dial test task to the Kafka queue to forward the dial test task to the target terminal through the Kafka queue.

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

[0107] S302: Obtain target deep packet inspection (DPI) call record data returned by the target terminal.

[0108] In this step, the target deep packet inspection DPI call bill data is generated by the target terminal after completing the dialing test task. The target terminal executes the dialing test task and captures the original data through a series of modules, and then obtains the target deep packet inspection DPI call bill data. The target deep packet inspection DPI call bill data is mainly used to evaluate the network quality of the 5G core network and the accuracy of call bill generation.

[0109] Further, the target DPI call record data returned by the target terminal is obtained, including:

[0110] Get the target DPI call record data and target traffic data returned by the target terminal.

[0111] The traffic data is the traffic data generated by the target terminal based on the actual network interaction when executing the dial test task. In this step, after receiving the dial test task, the target terminal first caches the test instructions in the dial test task through the local cache module to ensure that no data is lost during the execution of the task. Then, the local cache module will classify the test instructions according to their specific content, and distribute the dial test tasks to different execution modules according to the type of instructions or execution requirements. For example, according to the protocol type, data transmission method or test requirements of the instructions, the instructions are assigned to different execution logics for subsequent execution.

[0112] Before executing the test action, the target terminal will start the raw data capture module to capture the network traffic of the entire test process, and then capture all data packets during the test execution, including detailed information of upstream and downstream traffic, such as data transmission rate, protocol type, latency, etc. During the capture process, the traffic filtering module filters the raw traffic according to AppID or process ID to ensure that the captured data is purely from the current test task.

[0113] After distributing the dialing test tasks to different execution modules, the scheduling module will be responsible for scheduling different execution modules to perform corresponding test actions. For example, the instructions for network performance testing will schedule the corresponding modules to perform data transmission, delay testing and other operations, while the voice call test instructions will schedule the voice module to perform dialing testing.

[0114] After completing the dialing task, the target terminal will upload the DPI call list data and captured traffic data to the terminal management platform 102 at the same time. The terminal management platform 102 will temporarily store these execution records and data packets for subsequent diagnosis of network anomalies, traffic anomalies, etc. in specific tasks.

[0115] S303: Generate target XDR call record data corresponding to the DPI call record data according to the call record generation strategy generated by the DPI base and the target DPI call record data.

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

[0117] This step mainly analyzes the target DPI call bill data through the call bill generation module to generate the target XDR call bill. Specifically, the call bill generation module receives the latest uploaded target DPI call bill data from the terminal management platform 102, and then generates a call bill strategy based on the DPI base, processes the target DPI call bill data one by one, and then generates a target XDR call bill to determine whether the content and structure of the target XDR call bill meet the 5G network operation standards. Among them, the target XDR call bill contains various key indicators of network service quality, and the operation and maintenance personnel can evaluate the operation of the network based on these indicators and discover potential problems in a timely manner.

[0118] S304: Determine the XDR call bill data to be tested from the DPI call bill data to be tested according to the parameter information of the target XDR call bill data.

[0119] The XDR call bill data to be tested is generated based on the call bill generation strategy of the DPI base, and the parameter information of the XDR call bill data to be tested is the same as the parameter information of the target XDR call bill data.

[0120] The target XDR call record data generated by the target terminal performing the dial test task mainly includes the following key parameter information: the target terminal area code, interface, service type, international mobile user identity code imsi, mobile station international user directory number msisdn, start time and end time. Among them, the test terminal area code is used to identify the geographical area where the test terminal is located; interface: identifies the access interface type of the network; service type describes the specific network service of the task, such as data transmission, voice call, etc.; IMSI represents the international mobile user identity code, which is used to uniquely identify the user; MSISDN represents the mobile station international user directory number, which is used to associate with the user's phone number; start time and end time are used to record the start and end time of the test task to ensure that all network interaction behaviors can be captured and recorded within this time period.

[0121] After the target terminal completes the dialing task, the generated target XDR call record data will be uploaded to the data analysis module 104 (as shown in FIG. 1 ), and the data analysis module 104 will query the generated DPI call record data from the big data base based on the above parameter information in the target XDR call record data. Specifically, the data analysis module 104 will use the parameter information of the target XDR call record data as a filtering condition to retrieve matching DPI call record data from the big data platform.

[0122] After determining the DPI call record data that matches the parameter information of the target XDR call record data, the key parameter information in the DPI call record data is extracted according to the call record generation strategy of the DPI base to ensure that this information is consistent with the parameters in the target XDR call record data, and further generate the corresponding XDR call record data to be tested to ensure the consistency of the structure and content of the XDR call record data to be tested and the target XDR call record data.

[0123] S305: Detect the XDR call record data to be tested according to the target XDR call record data, and generate a detection result.

[0124] The detection result is used to indicate whether there is any abnormality in the XDR call record data to be tested, so as to ensure the accuracy of the XDR call record data to be tested.

[0125] Further, the XDR call record data to be tested is tested according to the target XDR call record data to generate a test result, including:

[0126] According to the ratio between the operation and the XDR call record data, the predefined minimum comparison unit and the preset field, the target XDR call record data and the XDR call record data to be tested are tested to generate a test result.

[0127] In this step, the minimum comparison unit for detection is first defined, which is used to ensure the consistency between the target XDR call record data and the XDR call record data to be tested. The minimum comparison unit includes an interface, a service identifier, a service process, and a DNN.

[0128] For example, the interface is used to identify different network interface types (such as S1, S5, S11, etc.), and during detection, ensure that the interfaces used in the target XDR call record and the XDR call record to be tested are consistent; the service identifier is used to indicate the specific service type, such as voice calls, data transmission, video streaming, etc.; the service process refers to the specific execution steps or sequence of network services, such as call establishment for making a phone call, establishment of data transmission, etc.; DNN (data network name) is used to identify different data networks, such as distinguishing data flows for accessing the Internet, private networks or specific application services. By comparing the DNN, ensure that the data network names of the two XDR call record records are consistent.

[0129] When testing the XDR call sheet data to be tested, the test will be performed based on the ratio between the dial test task execution operation and the XDR call sheet data. This ratio reflects the relationship between the number of XDR call sheets generated during the dial test task execution and the actual task execution, which can ensure that the number and frequency of XDR call sheet generation are consistent with the number of operation executions. If there is an abnormality in the ratio, it indicates that there may be omissions or redundancies in the XDR call sheet. Specifically, based on the number of executions, time, and operation flow of the dial test task, the number of target XDR call sheets to be generated is calculated and compared with the number of XDR call sheet data to be tested.

[0130] During the detection process, comparisons are also performed based on pre-defined key fields. For example, the field information in the target XDR call record data is compared with the field information in the XDR call record to be tested one by one to ensure that all fields are consistent.

[0131] After the minimum comparison unit, the preset field and the ratio are detected, a detection result is generated, which indicates whether the XDR call record data to be tested is consistent with the target XDR call record data.

[0132] Furthermore, when the detection result indicates that the XDR call record data to be tested is abnormal, an alarm message is output.

[0133] In this step, if the target XDR bill data is consistent with the XDR bill data to be tested, a "passed" test result will be output, indicating that the bill generation is in line with expectations and there is no abnormality in the data. If inconsistencies are found during the comparison process (such as inconsistent interfaces, incorrect service identifiers, missing service processes, etc.), an "abnormal" test result will be generated and an alarm message will be output.

[0134] Among them, the alarm information is used to indicate the abnormal type, that is, to indicate the field or process with problems for subsequent investigation and correction. The alarm information can be divided into the following types: success rate / failure rate alarm, number of lost / duplicate call records per unit time alarm, cumulative number of lost / duplicate call records on the interface alarm, and abnormal field alarm.

[0135] The above-mentioned embodiment sends the dialing test task to the target terminal so that the target terminal generates a DPI call record and traffic data when executing the task, and then generates target XDR call record data and the XDR call record data to be tested according to the DPI base generation strategy, and performs a detailed comparison of the call record data according to the minimum comparison unit (such as interface, service identifier, business process, DNN, etc.), and then determines whether the XDR call record book to be tested meets the expected standards, and can accurately detect the accuracy of the XDR call record data to be tested.

[0136] Figure 4a This is a flow chart of the second embodiment of the DPI call record detection method provided by this application. Figure 4aAs shown, based on the first embodiment, the XDR call record data to be tested is tested according to the target XDR call record data to generate a test result. This step can also be implemented by the "edit distance algorithm", which compares the two sets of call records and gives the two sets of call record matching quantitative indicators. Including:

[0137] S401: Initialization and preparation.

[0138] In this step, firstly, according to the edit distance algorithm, the following definition is 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 exactly the same. Among them, A = a1a2a3 ... aN, which means that the string A is composed of N strings a1 ... aN; B = b1b2b3 ... bM, which means that the string B is composed of M strings b1 ... bM.

[0139] The target XDR call record is represented by string A, and the DPI call record to be tested is represented by string B. The target DPI call record and the DPI call record to be tested each contain multiple call record records, each record contains key information such as business type, business process, DNN, start time and end time. Then, based on this information, the two sets of call records are initialized into two string sequences for the next step of processing.

[0140] Specifically, when the two CDRs ai and bj meet the following conditions at the same time, the two CDRs are considered to match:

[0141] 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].

[0142] S402: Filter the DPI call record.

[0143] Before making a comparison, filter the DPI call record queue first. The filtering rules are as follows:

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

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

[0146] S403: Initialize the matrix of the edit distance algorithm.

[0147] 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 record data A, n is the length of the DPI call record data B to be tested, A=[a,b,c,d,e,f,g,h], B=[1,b,b,4,f,g,h,h,9,z,x], and the first row and first column of the matrix are initialized to digital sequences from 0 to m / n, respectively.

[0148] S404, fill the matrix.

[0149] In this step, each cell in the matrix is ​​filled according to the following rules:

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

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

[0152] D[i-1][j] indicates a delete operation, and a DPI call record is missing. D[i][j-1] indicates an insert operation, and there are duplicate or redundant call records in the DPI call record. D[i-1][j-1] indicates a replace operation, and the DPI call record does not match the reference call record.

[0153] Through this step, the edit distance between the two sets of call records can be calculated, that is, how many operations are required to convert the DPI call record into the form of the benchmark call record.

[0154] S405: Calculate the edit distance and the matching degree.

[0155] 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 records. An edit distance of 0 indicates that the two sets of call records are completely matched; the larger the edit distance, the greater the difference in the call records. For example, if the edit distance is 8, it means that there are 8 call records that are mismatched or different.

[0156] S406: Backtrack to obtain matching results and generate matching results.

[0157] In this step, backtracking is performed based on the edit distance matrix to determine the specific matching situation of the call record.

[0158] The backtracking rules are as follows:

[0159] If ai==bj, then trace back to the upper left corner, indicating that the call record matches.

[0160] If ai≠bj, then trace back to the cell with the smallest value among the top left, top side, and left side, with the priority being: top left > top side > left side. Based on the traceback results, it can be determined whether the call record is lost, duplicated, or mismatched.

[0161] Finally, by backtracking, we can get the matching status of the two sets of call records. For example, there are 4 matching call records, 1 lost call record, and 6 wrong or duplicate call records.

[0162] In practical applications, in order to improve the efficiency of the algorithm and reduce memory loss, the call records can be grouped and compared. The grouping rule is: divide the call records into multiple independent sequences to be compared according to the minimum comparison unit (interface, service type, business process, DNN), and preferentially divide the data into multiple sequences to be compared according to interface-service-process-DNN. Each independent sequence is compared with the benchmark call record. This grouping comparison can effectively reduce the time complexity and space complexity, and avoid performance problems when comparing large-scale call records.

[0163] S408: Output the detection result.

[0164] In this step, a quantitative detection report is generated based on the edit distance and the backtracking path. The report includes: the matching degree of the two sets of call records. The specific call records with differences and their reasons (loss, duplication or mismatch). In addition, this embodiment also provides an automatic repair or retry mechanism. For the problem call records found, the system can trigger the re-capture and generation process.

[0165] The above embodiment accurately calculates the deviation between the XDR call record generated on the DPI side and the benchmark XDR call record on the terminal side through the edit distance algorithm, performs a quantitative evaluation on the quality of the XDR call record, and can efficiently and accurately determine the deviation field between the XDR call record generated on the DPI side and the benchmark call record.

[0166] Figure 4b This is a schematic diagram of the edit distance backtracking path of the DPI call record detection method provided in this application. Figure 4b As shown, based on the second embodiment, a result diagram of backtracking based on the edit distance matrix is ​​shown, so that the specific matching situation of the call record can be intuitively determined.

[0167] Figure 4c This is a schematic diagram of the matching results based on the edit distance algorithm of the DPI call record detection method provided by this application. Figure 4c As shown, based on the second embodiment, a matching result diagram is shown in which there are 4 matching bills, 1 lost bill, and 6 wrong or duplicate bills.

[0168] Figure 5a This is a flow chart of the third embodiment of the DPI call record detection method provided by this application. Figure 5a As shown, based on the first embodiment, a dialing task is sent to the target terminal, and the method further includes:

[0169] S501, dial test task encapsulation.

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

[0171] S502: Send the dialing task to the Kafka queue.

[0172] After the dial test task is encapsulated, each Kafka message corresponding to the dial test task is sent to the Kafka queue. Among them, the Kafka message queue 107 contains an asynchronous message execution module, which is the core component of the entire dial test task execution process, including the producer end, consumer end and business logic module of Kafka. Among them, the role of the producer end is that when the task management module 102 generates a dial test task, the dial test task will be sent to the specified Kafka queue through the Kafka producer end. The role of the consumer end is that the target terminal, as a consumer of Kafka, listens to and consumes the dial test tasks in the Kafka queue.

[0173] In addition, different states will correspond to different asynchronous message execution modules, which will process specific tasks according to the task status. Specifically, the message consumer processes the task status. For example, when a dialing task enters the execution state, the relevant module will obtain the status message of the task through the Kafka message queue 107, execute the task, and update the task status to "completed" or "failed" after the task is completed. After the task is executed, the asynchronous message execution module will push the updated status message to the Kafka message queue 107 again so that the next module can receive and process it. For example, when a task fails, the system can re-execute the failed steps through the retry mechanism of the Kafka message queue 107.

[0174] S503: Re-execution and status update of the dialing task.

[0175] In this step, if the dial test task fails during execution, the status of the dial test task will be modified, and the corresponding module will be notified to re-execute through the Kafka message queue 107. For example, the re-executed task may re-capture the XDR call data generated by the DPI side and re-analyze it according to the new rules. In addition, the asynchronous message processing mechanism of the Kafka message queue 107 ensures the automated management and status flow of tasks. For example, when a task is re-executed after failure, the system can automatically update the task status and decide whether to continue to the next step or retry again based on the execution result.

[0176] The above embodiment realizes the distribution and status management of dialing tasks through the Kafka message queue 107. The producer and consumer of Kafka are responsible for the generation and execution of tasks respectively. The asynchronous message execution module ensures that the tasks are correctly processed in different states through the dynamic flow of task status. When a task fails, it can initiate a retry by modifying the task status, re-capture the DPI call data and analyze it, thereby ensuring the monitoring and verification of the XDR call quality and service performance of the 5G core network.

[0177] Figure 5b This is an asynchronous task flow chart of the dialing task of the DPI call record detection method provided by this application. Figure 5b As shown in the figure, the dial test task is a process in which the execution status of the task changes continuously from execution to completion. In some scenarios where the execution fails, the step can be re-executed by repeating the execution. By modifying the test task status, the task can be re-executed, DPI call data can be re-captured, and the test case can be re-analyzed or re-analyzed according to new rules.

[0178] The entire execution process is completed through the kafka message queue and the asynchronous message execution module. The asynchronous message execution model includes message consumers, producers, and business logic modules. Different states correspond to different asynchronous message execution modules. Different asynchronous message execution modules focus on the specific state of the execution task. After obtaining the message, it is only responsible for the business processing of the module. After processing, the message is pushed to the next state and the state change message is sent. Through the direct cooperation of various state message processing modules, the entire message execution process is finally completed.

[0179] Figure 6 This is a schematic diagram of the structure of the DPI call record detection device provided by this application. Figure 6 As shown, the DPI call record detection device 60 includes:

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

[0181] The DPI call list data acquisition module 602 is used to acquire the target deep packet inspection DPI call list data returned by the target terminal, and the target DPI call list data is the DPI call list data generated by the target terminal when executing the dialing test task;

[0182] The XDR call record data generation module 603 is used to generate a call record generation strategy and target DPI call record data according to the DPI base, and generate target XDR call record data corresponding to the target DPI call record data;

[0183] The XDR call bill data to be tested determining module 604 is used to determine the XDR call bill data to be tested from the DPI call bill data to be tested according to the parameter information of the target XDR call bill data, the XDR call bill data to be tested is generated based on the call bill generation strategy generated by the DPI base, and the parameter information of the XDR call bill data to be tested is the same as the parameter information of the target XDR call bill data;

[0184] The detection result generating module 605 is used to detect the XDR call bill data to be tested according to the target XDR call bill data and generate a detection result, wherein the detection result is used to indicate whether there is an abnormality in the XDR call bill data to be tested.

[0185] The detection result generating module 605 is further used for:

[0186] According to the ratio between the operation and the XDR call record data, the predefined minimum comparison unit and the preset field, the target XDR call record data and the XDR call record data to be tested are tested to generate a test result.

[0187] Among them, the minimum comparison unit includes interface, business identifier, business process and DNN.

[0188] The parameter information in the XDR call record data determination module 604 includes the area code, interface, service type, international mobile subscriber identity code imsi, mobile station international subscriber directory number msisdn, start time and end time of the target terminal.

[0189] The dialing test task sending module 601 is further used to send the dialing test task to the Kafka queue, so as to forward the dialing test task to the target terminal through the Kafka queue.

[0190] The dial test task sending module 601 is also used to generate a dial test script for each service according to the service flow of each service defined by the 3rd Generation Partnership Project 3GPP protocol;

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

[0192] When the detection result indicates that the XDR call record data to be tested is abnormal, the detection result generating module 605 outputs alarm information, where the alarm information is used to indicate the type of abnormality.

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

[0194] 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 , the memory 702 and the communication component 703 are connected via a bus 704 .

[0195] In the specific implementation process, at least one processor 701 executes the computer execution instructions stored in the memory 702, so that at least one processor 701 executes the above DPI call record detection method.

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

[0197] In the above Figure 7 In the illustrated embodiment, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

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

[0199] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.

[0200] In some embodiments, a computer program product is also proposed, including a computer program or instructions, which, when executed by a processor, implement the steps in any of the above-mentioned DPI call record detection methods.

[0201] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0202] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0203] To this end, an embodiment of the present application provides a computer-readable storage medium, in which multiple instructions are stored, and the instructions can be loaded by a processor to execute the steps in any DPI call record detection method provided in the embodiment of the present application.

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

[0205] According to one aspect of the present application, a computer program product or a computer program is provided. The computer program product or the computer program comprises computer instructions stored in a computer-readable storage medium.

[0206] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0207] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0208] It should be further noted that, although the various steps in the flow chart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flow chart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

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

[0210] In the above embodiments, the description of each embodiment has its own emphasis. For the part not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A DPI call record detection method, characterized in that: include: Sending a dialing test task to a target terminal, wherein the dialing test task includes at least one dialing test script, and the dialing test script is pre-edited according to a business process; Acquire target deep packet inspection (DPI) call bill data returned by the target terminal, where the target DPI call bill data is the DPI call bill data generated by the target terminal when executing the dialing test task; Generate target extended detection and response XDR call record data corresponding to the DPI call record data according to the DPI base generation call record generation strategy and the target DPI call record data; Determine the XDR call bill data to be tested from the DPI call bill data to be tested according to the parameter information of the target XDR call bill data, wherein the XDR call bill data to be tested is generated based on the call bill generation strategy of the DPI base, and the parameter information of the XDR call bill data to be tested is the same as the parameter information of the target XDR call bill data; The XDR call bill data to be tested is tested according to the target XDR call bill data to generate a test result, where the test result is used to indicate whether the XDR call bill data to be tested is abnormal.

2. The method according to claim 1, characterized in that The detecting the XDR call record data to be tested according to the target XDR call record data to generate a detection result includes: According to the ratio between the operation and the XDR call record data, the predefined minimum comparison unit and the preset field, the target XDR call record data and the XDR call record data to be tested are tested to generate the test result; The minimum comparison unit includes an interface, a service identifier, a service process and a DNN.

3. The method according to claim 1 or 2, characterized in that: The parameter information includes the area code, interface, service type, international mobile user identity code imsi, mobile station international user directory number msisdn, start time and end time of the target terminal.

4. The method according to claim 1 or 2, characterized in that: The obtaining of target DPI call record data returned by the target terminal includes: The target DPI call list data and target traffic data returned by the target terminal are obtained, where the traffic data is traffic data generated by the target terminal when executing the dialing test task.

5. The method according to claim 1 or 2, characterized in that: The sending of the dialing test task to the target terminal includes: The dialing test task is sent to the kafka queue, so as to forward the dialing test task to the target terminal through the kafka queue.

6. The method according to claim 1 or 2, characterized in that: Before sending the dialing test task to the target terminal, the method further includes: Generate a dial test script for each service based on the service flow of each service defined by the 3rd Generation Partnership Project 3GPP protocol; Perform configuration operations on at least one dialing test script to generate the dialing test task, wherein the configuration operation includes sub-configuration operations for at least one of the following items: the execution order, execution times, execution interval, server address to be accessed, and traffic protocol information of the transport layer L4 / application layer L7 of different dialing test scripts.

7. The method according to claim 1 or 2, characterized in that: The method further comprises: When the detection result indicates that the XDR call record data to be tested is abnormal, an alarm message is output, where the alarm message is used to indicate the type of abnormality.

8. A DPI call record detection device, characterized in that: include: A dial test task sending module, used to send a dial test task to a target terminal, wherein the dial test task includes at least one dial test script, and the dial test script is pre-edited according to a business process; A DPI call list data acquisition module is used to acquire target deep packet inspection DPI call list data returned by the target terminal, wherein the target DPI call list data is the DPI call list data generated by the target terminal when executing the dialing test task; An XDR call sheet data generation module is used to generate a call sheet generation strategy and the target DPI call sheet data according to the DPI base, and generate target extended detection and response XDR call sheet data corresponding to the target DPI call sheet data; The module for determining XDR bill data to be tested is used to determine the XDR bill data to be tested from the DPI bill data to be tested according to the parameter information of the target XDR bill data, wherein the XDR bill data to be tested is generated based on the bill generation strategy generated by the DPI base, and the parameter information of the XDR bill data to be tested is the same as the parameter information of the target XDR bill data; The detection result generating module is used to detect the XDR call bill data to be tested according to the target XDR call bill data and generate a detection result, wherein the detection result is used to indicate whether there is an abnormality in the XDR call bill data to be tested.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

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

11. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 7 when being executed by a processor.

Images