A method, system, device and storage medium for cellular protocol test decision

Abstract

The application provides a cellular protocol test judgment method, device, equipment and storage medium, comprising: first acquiring a structured test case of a measured cellular network terminal and corresponding traffic evidence, wherein the case at least defines an uplink reference message, an injected downlink message, a candidate response set and an expected response type; locating the uplink reference message in the traffic evidence to determine a trigger event; locating a downlink abnormal message corresponding to the injected downlink message in the traffic evidence, and determining the position of the downlink abnormal message in the traffic evidence as an injection event; determining a response observation window with the injection event as a time sequence anchor point starting point; searching for the messages defined by the candidate response set in the observation window to obtain an actual terminal response set; and finally outputting a test conclusion representing compliance of terminal protocol behavior according to the expected response type and the actual terminal response set. By using the above scheme, the consistency, accuracy and reliability of the cellular protocol test conclusion can be improved.

Description

Technical Field

[0001] This application relates to the field of communication security, and more specifically, to a cellular protocol testing and determination method, system, device, and storage medium. Background Technology

[0002] Cellular mobile communication networks are the core infrastructure for public and critical industry communications. 4G and 5G terminals must strictly follow 3GPP protocol standards in their interaction processes, such as access, authentication, mobility management, and radio resource control. Cellular protocol negative testing is a key technical means to verify terminal protocol compliance and identify potential communication security risks.

[0003] Existing negative testing of cellular protocols mainly adopts the implementation method of combining standardized test suites with manual reading of protocol standards to write test cases. Testers manually design abnormal test scenarios and write test execution steps according to 3GPP standard clauses, and complete test judgment by manually observing terminal behavior.

[0004] The test method, which involves manual coding and judgment, does not set up a unified timing anchor point and response observation window. The scope of terminal response retrieval depends entirely on human subjective determination, which makes negative test conclusions susceptible to human factors. Different people may produce different results when executing the same test case, resulting in extremely poor consistency and verifiability of test conclusions. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a cellular protocol testing and determination method, apparatus, device and storage medium that can improve the consistency, accuracy and reliability of test conclusions.

[0006] In a first aspect, embodiments of this application provide a cellular protocol testing and determination method, the method comprising: Obtain structured test cases for the cellular network terminal under test, and traffic evidence corresponding to the structured test cases, wherein the structured test cases define at least an uplink reference message, an injected downlink message, a candidate response set, and an expected response type; Locate the uplink reference message within the traffic evidence to determine the triggering event; In the traffic evidence, a downlink abnormal message corresponding to the injected downlink message is located after the triggering event, and the position of the located downlink abnormal message in the traffic evidence is determined as the injection event, wherein the injection event is located after the triggering event; The response observation window is determined using the injection event as the starting point of the timing anchor. Retrieve messages defined by the candidate response set within the response observation window to obtain the actual response set of the terminal; Based on the expected response type and the actual response set of the terminal, output test conclusions characterizing the compliance of the terminal protocol behavior.

[0007] Optionally, locating the uplink reference message in the traffic evidence to determine the triggering event includes: Obtain the protocol type, message name, and message direction defined in the uplink reference message from the structured test cases; Based on the protocol type and the message direction, uplink messages matching the message name are filtered from the control plane messages of the traffic evidence; The selected uplink message is identified as the triggering event by its packet sequence number or time position in the traffic evidence.

[0008] Optionally, determining the response observation window using the injection event as the starting point of the time sequence anchor includes: Obtain the injection packet sequence number corresponding to the injection event in the traffic evidence; The injection package number is used as the starting point of the response observation window; The endpoint of the response observation window is determined based on a preset end boundary or timeout boundary; The packet sequence number range from the starting point to the ending point in the traffic evidence is determined as the response observation window.

[0009] Optionally, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual response set of the terminal includes: When the expected response type is a specific response message, and the actual response set of the terminal contains only one message, and that message matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message, and the actual response set of the terminal contains only one message, and that message does not match the specific response message, a test conclusion characterizing non-compliant terminal protocol behavior is output.

[0010] Optionally, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual response set of the terminal includes: When the expected response type is a specific response message and the actual response set of the terminal contains a message that matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message and the actual response set of the terminal does not contain a message that matches the specific response message, a test conclusion characterizing the non-compliance of the terminal protocol behavior is output.

[0011] Optionally, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual response set of the terminal includes: The test conclusion indicating that the compliance of the terminal protocol behavior is undeterminable is output when at least one of the following conditions is met: The triggering event could not be located in the traffic evidence; The injection event could not be located in the traffic evidence; The key packet used to locate the triggering event or the injection event in the traffic evidence is missing; The messages in the candidate response set appear to be hit multiple times within the response observation window and it is impossible to determine a unique actual response. The test execution process was interrupted; Or the traffic evidence is incomplete.

[0012] Optionally, the structured test cases define a standard chain of evidence, which includes at least a standard number, a standard clause number, a clause title, and a fragment of the original clause text. The method further includes: Obtain the sequence number of the first packet associated with the triggering event from the traffic evidence, and / or the sequence number of the second packet associated with the injection event; Based on the first package number and / or the second package number, and the standard clause number, generate an evidence pointer corresponding to the test conclusion; Output the evidence pointer, which is used to point to the packet in the traffic evidence that is related to the test conclusion and the protocol terms indicated by the standard evidence chain.

[0013] Secondly, embodiments of this application provide a cellular protocol testing and determination device, the device comprising: The structured test case acquisition module is used to acquire structured test cases for the cellular network terminal under test, as well as traffic evidence corresponding to the structured test cases. The structured test cases at least define an uplink reference message, an injected downlink message, a candidate response set, and an expected response type. The trigger event determination module is used to locate the uplink reference message in the traffic evidence in order to determine the trigger event; An injection event determination module is used to locate a downlink abnormal message corresponding to the injected downlink message in the traffic evidence after the triggering event, and determine the position of the located downlink abnormal message in the traffic evidence as an injection event, wherein the injection event is located after the triggering event; The response observation window determination module is used to determine the response observation window with the injection event as the starting point of the timing anchor point; The actual response set determination module is used to retrieve messages defined by the candidate response set within the response observation window to obtain the actual response set of the terminal. The test conclusion determination module is used to output a test conclusion characterizing the compliance of the terminal protocol behavior based on the expected response type and the actual response set of the terminal.

[0014] Optionally, locating the uplink reference message in the traffic evidence to determine the triggering event includes: Obtain the protocol type, message name, and message direction defined in the uplink reference message from the structured test cases; Based on the protocol type and the message direction, uplink messages matching the message name are filtered from the control plane messages of the traffic evidence; The selected uplink message is identified as the triggering event by its packet sequence number or time position in the traffic evidence.

[0015] Optionally, determining the response observation window using the injection event as the starting point of the time sequence anchor includes: Obtain the injection packet sequence number corresponding to the injection event in the traffic evidence; The injection package number is used as the starting point of the response observation window; The endpoint of the response observation window is determined based on a preset end boundary or timeout boundary; The packet sequence number range from the starting point to the ending point in the traffic evidence is determined as the response observation window.

[0016] Optionally, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual response set of the terminal includes: When the expected response type is a specific response message, and the actual response set of the terminal contains only one message, and that message matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message, and the actual response set of the terminal contains only one message, and that message does not match the specific response message, a test conclusion characterizing non-compliant terminal protocol behavior is output.

[0017] Optionally, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual response set of the terminal includes: When the expected response type is a specific response message and the actual response set of the terminal contains a message that matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message and the actual response set of the terminal does not contain a message that matches the specific response message, a test conclusion indicating that the terminal protocol behavior is non-compliant is output.

[0018] Optionally, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual response set of the terminal includes: The test conclusion indicating that the compliance of the terminal protocol behavior is undeterminable is output when at least one of the following conditions is met: The triggering event could not be located in the traffic evidence; The injection event could not be located in the traffic evidence; The key packet used to locate the triggering event or the injection event in the traffic evidence is missing; The messages in the candidate response set appear to be hit multiple times within the response observation window and it is impossible to determine a unique actual response. The test execution process was interrupted; Or the traffic evidence is incomplete.

[0019] Optionally, the structured test cases define a standard chain of evidence, which includes at least a standard number, a standard clause number, a clause title, and a fragment of the original clause text. The device further includes an evidence pointer output module, used for: Obtain the sequence number of the first packet associated with the triggering event from the traffic evidence, and / or the sequence number of the second packet associated with the injection event; Based on the first package number and / or the second package number, and the standard clause number, generate an evidence pointer corresponding to the test conclusion; Output the evidence pointer, which is used to point to the packet in the traffic evidence that is related to the test conclusion and the protocol terms indicated by the standard evidence chain.

[0020] Thirdly, embodiments of this application provide a computer device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the cellular protocol test determination method described in any of the optional embodiments of the first aspect are performed.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the cellular protocol test determination method described in any of the optional embodiments of the first aspect.

[0022] The technical solution provided in this application includes, but is not limited to, the following beneficial effects: Obtain structured test cases for the cellular network terminal under test, along with corresponding traffic evidence. Each structured test case defines at least an uplink reference message, an injected downlink message, a candidate response set, and an expected response type. By acquiring standardized structured test cases and accompanying traffic evidence, a unified and standardized input benchmark can be provided for subsequent test decisions, avoiding logical confusion caused by inconsistent test inputs and ensuring the basic consistency of test decisions.

[0023] The uplink reference message is located within the traffic evidence to determine the triggering event. By locating the uplink reference message within the traffic evidence to determine the triggering event, a precise timing reference can be provided for anomaly injection, ensuring that the triggering timing of subsequent abnormal operations matches the actual interaction state of the terminal, thus improving the accuracy of test triggering.

[0024] In the traffic evidence, a downlink abnormal message corresponding to the injected downlink message is located after the trigger event. The position of the located downlink abnormal message in the traffic evidence is determined as the injection event, wherein the injection event is located after the trigger event. Issuing a downlink abnormal message based on the trigger event and determining it as an injection event allows for precise binding of the abnormal injection action to the trigger timing, ensuring that the abnormal message is executed within the target interaction sequence and avoiding the impact of abnormal injection timing deviations on the authenticity of test results.

[0025] Using the injected event as the starting point of the time sequence anchor, a response observation window is determined. Defining the response observation window using the injected event as the starting point of the time sequence anchor can fix the retrieval range of the terminal response, eliminate the judgment bias caused by arbitrarily setting the retrieval range, and ensure the standardization and uniformity of response retrieval.

[0026] The actual terminal response set is obtained by retrieving messages defined by the candidate response set within the response observation window. Retrieving a preset candidate response set within a standardized observation window allows for accurate extraction of the terminal's actual response behavior, eliminating interference from irrelevant messages and ensuring that the obtained actual terminal response set is authentic and valid.

[0027] Based on the expected response type and the actual response set of the terminal, a test conclusion characterizing the compliance of the terminal's protocol behavior is output. Outputting test conclusions based on the comparison between the expected response type and the actual response set of the terminal allows for objective comparison results to replace subjective judgments, improving the objectivity and accuracy of the test conclusions.

[0028] By implementing the above steps sequentially, this application can achieve precise timing, standardized retrieval, and objective judgment in cellular protocol testing, thereby comprehensively improving the consistency, accuracy, and reliability of test conclusions.

[0029] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 A flowchart of a cellular protocol testing and determination method provided in Embodiment 1 of this application is shown; Figure 2 This paper presents an overall flowchart of the cellular protocol test determination method in an embodiment of this application. Figure 3 A flowchart of a trigger event determination method provided in Embodiment 1 of this application is shown; Figure 4 The offline determination process based on traffic evidence in the embodiments of this application is shown; Figure 5 A flowchart of a response observation window determination method provided in Embodiment 1 of this application is shown; Figure 6 A flowchart of an evidence pointer generation method provided in Embodiment 1 of this application is shown; Figure 7 This paper shows a schematic diagram of the structure of a cellular protocol testing and determination device provided in Embodiment 2 of this application; Figure 8 A schematic diagram of the structure of a computer device provided in Embodiment 3 of this application is shown. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0033] Example 1 To facilitate understanding of this application, the following is combined with... Figure 1 The flowchart illustrating a cellular protocol testing and determination method provided in Embodiment 1 of this application will be used to provide a detailed description of Embodiment 1 of this application.

[0034] Referring to Figure 1, which shows a flowchart of a cellular protocol testing and determination method provided in Embodiment 1 of this application, the method includes steps S101 to S106: S101: Obtain structured test cases for the cellular network terminal under test, and traffic evidence corresponding to the structured test cases, wherein the structured test cases define at least an uplink reference message, an injected downlink message, a candidate response set, and an expected response type.

[0035] Specifically, this application is applied to the fields of cellular mobile communication protocol testing and communication security technology, and is specifically aimed at negative testing scenarios for 4G and 5G cellular network terminals. It is used to solve the core problems of unclear timing, inconsistent observation scope, difficulty in determining no-response scenarios, and unverifiable conclusions in existing negative testing.

[0036] Traffic evidence consists of pcap (Packet Capture) format control plane traffic files collected during the test execution process. These files are exported by the built-in packet capture capability of the access network side protocol stack and can simultaneously cover the entire process of interaction data of NAS (Non-Access Stratum) and RRC (Radio Resource Control) protocols. They are the main objective basis for determining the terminal protocol behavior.

[0037] Structured test cases are the unified expression of negative test constraints in this application. The standard structured expression for a single structured test case is: TC(TestCase) = network,protocol,test,check,impacts,specs,explanation .

[0038] Among them, TC: a single structured test case, is the core carrier that carries all the rules, parameters and basis of negative testing; network: The network type field, used to uniquely identify whether the network used for the test is 4G or 5G; protocol: Protocol type field, used to uniquely identify whether the protocol used for testing is NAS or RRC; test: The test action field is used to define the execution rules such as triggering events, injecting messages, and injecting parameters; check: The decision rule field, used to define the decision logic such as expected response, candidate response set, and retrieval rules; Impacts: The potential security impact information field describes the type and severity of risks corresponding to unexpected terminal behavior and is the core basis for terminal security assessment. Specs (specifications): Standard evidence chain field, used to store the basis of 3GPP standards and support the conclusion of compliance determination; Explanation: This field describes the purpose of the test, the type of exception, the expected behavior, the logic for inferring the security impact, and clarifies the original intention of the test case design and the judgment logic.

[0039] This application relies on six core system modules to achieve full-process automation, namely, standard parsing and knowledge base construction module, test case generation module, centralized configuration management module, test orchestration and execution module, trigger event and observation window judgment module, consistency judgment and result presentation module.

[0040] The standard parsing and knowledge base construction module uses docx (Word document format based on Office Open XML) format as the main input. Early doc (Word binary document format) documents are first converted to docx. Based on the document object model, paragraphs and tables are traversed block by block to identify heading levels and item numbers. After the tables are converted into plain text, they are serialized into a JSON (JavaScript Object Notation, a lightweight data interchange format) structured knowledge base.

[0041] The test case generation module adopts a two-phase process of Plan + Generate. The Plan phase completes the security relevance judgment and test target planning. The Generate phase generates test cases under constraints and prevents illusions by verifying the schema (data structure constraint specification), dynamically enumerating constraints, and semantic consistency verification, thus avoiding the generation of messages or parameters outside the standard.

[0042] The centralized configuration management module selects the operating baseline according to network, protocol, and PLMN (Public Land Mobile Network) and completes the initialization and availability verification of the core network, access network, terminal control link, and decoding environment.

[0043] S102: Locate the uplink reference message in the traffic evidence to determine the triggering event.

[0044] Specifically, the uplink reference message is the message specified by the ul_msg_hooked (uplink message hooked) subfield under the test field in the structured test case. It is the core reference condition in the timing anchor system of this application, used to accurately lock the timing of exception injection.

[0045] Triggering events are a core component of timing anchors. Their function is to unify the injection timing criteria for negative tests, avoid test results that fail to reflect the actual protocol behavior of the terminal due to injection timing deviations, and fundamentally solve the problems of strong timing dependence and distorted judgment in existing technologies.

[0046] The location of the triggering event is based on the control plane messages in the traffic evidence, matching only uplink messages with a specified protocol, direction, and name, excluding interference from data plane messages and messages of non-target protocols.

[0047] The test orchestration and execution module drives the execution process with a test case-level state machine, and incorporates the detection of trigger events into a unified asynchronous supervision framework for environment preparation, terminal network access, exception injection, response observation, and resource cleanup.

[0048] S103: In the traffic evidence, locate the downlink abnormal message corresponding to the injected downlink message after the triggering event, and determine the position of the located downlink abnormal message in the traffic evidence as the injection event, wherein the injection event is located after the triggering event.

[0049] Specifically, the injected downlink message corresponds to the dl_msg_to_send (downlink message to send) subfield under the test field of the structured test case, and the injected parameters correspond to the dl_msg_to_send_params (downlink message to send parameters) subfield under the test field. The combination of the two can construct downlink abnormal messages with malformed fields, incorrect algorithms, illegal timing, and abnormal states.

[0050] Injection events are key identifiers used to determine the starting point of the response observation window in timing anchors. Together with triggering events, they constitute a complete timing anchor system, achieving timing unification of anomaly injection and response retrieval.

[0051] During the test execution phase, the system immediately sends the aforementioned downlink anomaly message upon detecting the trigger event. By setting message hooks and injection handlers in the corresponding message processing chain, the injection operation is ensured to be executed with priority, preventing injection messages from being overwritten or missing the correct timing window, thus achieving low-latency injection assurance.

[0052] Anomaly injection enables adaptation to different protocol scenarios: The NAS protocol is based on Open5GS (open source 4G / 5G core network protocol stack) and sets up uplink message hooks and injection processors on the core network side; the RRC protocol is based on srsRAN 4G (open source 4G radio access network protocol stack) and OCUDU (Open Centralized Unit Distributed Unit, open source 5G radio access network protocol stack) and sets up message hooks and injection processors on the access network side.

[0053] Message hooks are used to trigger custom injection logic. The system supports specified PLMN configurations, including the laboratory test network 00101, and operator scenarios 46002, 46009, and 46011, achieving multi-scenario environment adaptation. Terminal state control adopts a two-level structure: Android terminals control airplane mode through a debug interface; iOS terminals complete state switching and recovery through a UI (User Interface) automated control link. An environment reset is performed after each test case execution to ensure initial state consistency. After execution, traffic evidence (pcap file) containing the entire interaction process is saved.

[0054] During the offline determination phase (i.e., the method described in this step), the saved traffic evidence is obtained, and the downlink anomaly message matching the injected downlink message is located from it. The location method is based on matching protocol type, message name, and message direction, and the packet sequence number or time position of the downlink anomaly message in the traffic evidence is determined as the injection event.

[0055] S104: Determine the response observation window using the injected event as the starting point of the timing anchor.

[0056] Specifically, the function of the response observation window is to fix the retrieval range of terminal responses, eliminate the inconsistency in judgment results caused by differences in the range of manual analysis by different testers and in different test environments, and achieve standardization of negative test judgment.

[0057] The response observation window expression in this application is: ; in, The response observation window is the only retrieval area for terminal response messages; The packet sequence number of the injected downlink message in the pcap traffic file is the absolute starting point of the observation window; The end number of the observation window or the timeout boundary is the endpoint of the observation window; Interval rule: Left-open, right-closed intervals are used. The corresponding injection message packet is not included in the search scope. The corresponding package is the search cutoff position.

[0058] The timing anchor point includes three core elements: triggering event, injection event, and observation window. This step takes the injection event as the starting point and combines the end boundary and timeout boundary to complete the precise delineation of the observation window.

[0059] The test orchestration and execution module uses log keywords, process liveness status, service readiness flags, and traffic evidence as conditions for phase advancement, and achieves rapid failure through timeout competition and abnormal exit monitoring.

[0060] S105: Retrieve the messages defined by the candidate response set within the response observation window to obtain the actual response set of the terminal.

[0061] Specifically, the candidate response set corresponds to the ue_resps_possible (user equipment possible responses) subfield under the check field of the structured test case. It is the range of all response messages that the terminal can make in this negative scenario as specified by the 3GPP standard, and can simultaneously cover two core test scenarios: expected no response and expected specific response.

[0062] The actual terminal response set is the set of response messages actually sent by the terminal within the observation window, expressed as: ; in, Observation window The actual set of terminal responses within the system is the core data for the determination; A single response message in the candidate response set; The candidate response set, which is all the responsive messages defined by ue_resps_possible; Response message The packet sequence number in the pcap traffic file is used to determine whether the message is within the observation window.

[0063] The trigger event and observation window determination module is responsible for accurately retrieving the candidate response set within the window and outputting the actual response result from the terminal.

[0064] S106: Based on the expected response type and the actual response set of the terminal, output a test conclusion characterizing the compliance of the terminal protocol behavior.

[0065] Specifically, the expected response type corresponds to the ue_resp_expected (user equipment expected response, terminal expected response) subfield under the check field of the structured test case, which is divided into two core types: expected no response and expected specific response, which fully matches the 3GPP standard's requirements for terminal behavior in negative scenarios.

[0066] The pass / fail determination expression for this application is as follows: ; in, : Test pass / fail result, with a value of 1 indicating that the test passed (terminal behavior is compliant) and a value of 0 indicating that the test failed (terminal behavior is non-compliant). Empty set: This means that the terminal did not send any candidate response messages in the observation window, i.e., it was silently discarded. : The unique expected response message type specified in the structured test case.

[0067] The test conclusions are based entirely on 3GPP standard terms and pcap traffic evidence, and can be directly traced back to the key packet sequence number and the original standard text, completely eliminating the shortcomings of existing technologies that rely on subjective human interpretation and whose conclusions cannot be verified.

[0068] The consistency determination and result presentation module outputs a pass, fail, or indeterminate conclusion based on the actual response and the expected response, and derives an evidence pointer.

[0069] The key innovation of this application is to propose a deterministic determination method for negative testing of cellular protocols based on time-series anchors. The time-series anchors include uplink reference trigger events, injection events, and observation windows, enabling stable and verifiable determination in two types of scenarios.

[0070] See Figure 2 As shown, Figure 2 The diagram illustrates the overall workflow of the cellular protocol testing and determination method in this embodiment, which is divided into two phases: test case preparation and execution determination. The test case preparation phase takes 3GPP standard documents as input and sequentially performs standard parsing and knowledge base construction, as well as structured test case generation, to complete the standardized definition and output of test cases. The execution determination phase, based on the structured test cases output by the test case preparation phase, sequentially performs trigger event detection, exception message injection, observation window determination, and candidate response retrieval, ultimately outputting a pass / fail / undeterminable test conclusion. This process, through the collaboration of the test case preparation phase and the execution determination phase, achieves a closed-loop process from standard documents to deterministic test conclusions.

[0071] This application has five core technical advantages: First, it unifies the timing criteria for negative testing; second, it stably determines unresponsive scenarios and avoids misjudgments due to silent discarding; third, it improves the verifiability of conclusions and allows for backtracking of packet sequence numbers and standard clauses; fourth, it is compatible with 4G / 5G and NAS / RRC, ensuring consistent conclusions across environments; and fifth, it unifies the data baseline and supports batch operation and regression testing.

[0072] In an optional implementation, see Figure 3 As shown, Figure 3 The flowchart of a trigger event determination method provided in Embodiment 1 of this application is shown, wherein locating the uplink reference message in the traffic evidence to determine the trigger event includes steps S301-S303: S301: Obtain the protocol type, message name, and message direction defined by the uplink reference message from the structured test case.

[0073] Specifically, the protocol type is the value of the protocol field in the structured test case. This application supports two cellular control plane protocols: NAS and RRC.

[0074] The message direction is fixed to uplink (sent from the terminal to the network side), and the message name is the standard protocol message name defined by the 3GPP standard. There are no custom or non-standard messages, ensuring the compliance and universality of the test.

[0075] These three types of parameters are the only matching conditions for triggering event location; none of them can be omitted to ensure that the location results are accurate.

[0076] The data source for dynamic enumeration constraints is based on network and protocol, and the messages and parameters must conform to standard specifications.

[0077] S302: Based on the protocol type and the message direction, filter out uplink messages that match the message name from the control plane messages of the traffic evidence.

[0078] Specifically, the filtering process is performed only on control plane messages, completely eliminating interference from user plane data messages and non-target protocol messages, ensuring the accuracy and uniqueness of trigger event location.

[0079] The filtering logic relies on protocol decoding capabilities to automatically identify the format and fields of NAS and RRC messages, and complete accurate matching.

[0080] S303: The packet sequence number or time position of the selected uplink message in the traffic evidence is determined as the triggering event.

[0081] Specifically, the packet sequence number is a unique numerical identifier for each message in the pcap traffic file, possessing absolute uniqueness; the time position is the timestamp of message collection, which can assist in time sequence verification.

[0082] Both can be used as the basis for locating the triggering event. The packet number should be used first to ensure that the location results of the triggering event are consistent in different environments.

[0083] See Figure 4 As shown, Figure 4 This application illustrates an offline determination process based on traffic evidence, using structured test cases and pcap evidence as initial inputs. The specific process is as follows: First, the process executes steps to locate the uplink reference message and inject the downlink message. Then, it proceeds to a branch determining whether a critical packet is missing or has multiple hits. If a critical packet is missing or has multiple hits, an "undetermined" conclusion is output directly. If the critical packet is normal, the process continues to determine the observation window and retrieve the candidate response set. After response retrieval, it proceeds to a branch determining whether no response is expected: if no response is expected, it further checks if the observation window is empty; if empty, a "pass" conclusion is output; otherwise, a "fail" conclusion is output. If no response is expected, it checks whether the expected response has occurred; if the expected response has occurred, a "pass" conclusion is output; otherwise, a "fail" conclusion is output. This process, through multi-node verification and branch determination, achieves deterministic determination of the compliance of terminal protocol behavior while covering boundary handling for undetermined scenarios.

[0084] This implementation scheme locates trigger events through triple matching of protocol type, message direction, and message name. It can accurately pinpoint the timing benchmark for abnormal injection, unify the injection timing criteria in different test scenarios, reduce the interference of environmental and human factors on timing location, and improve the stability and accuracy of trigger event identification.

[0085] In an optional implementation, see Figure 5 As shown, Figure 5 The flowchart illustrates a response observation window determination method provided in Embodiment 1 of this application, wherein determining the response observation window using the injected event as the starting point of the timing anchor includes steps S501 to S504: S501: Obtain the injection packet sequence number corresponding to the injection event in the traffic evidence.

[0086] Specifically, the injection package number is the one in the observation window formula. It is a unique number for downlink abnormal messages in the pcap traffic file, providing an absolute timing starting point for the observation window and eliminating the impact of link jitter and environmental delay on timing.

[0087] The injection packet sequence number is automatically obtained through traffic decoding and message matching, requiring no manual intervention and ensuring positioning accuracy.

[0088] S502: The injection package number is determined as the starting point of the response observation window.

[0089] Specifically, the starting point of the observation window is strictly locked. Instead of the fixed-delay injection method of existing technologies, state-driven injection is adopted to minimize the interference of environmental differences and link fluctuations on test timing.

[0090] Once the starting point is unified, the test judgment baselines for different test cases, different terminals, and different network environments are completely consistent.

[0091] S503: Determine the endpoint of the response observation window based on a preset end boundary or timeout boundary.

[0092] Specifically, the end boundary is the upper limit of the fixed number of packets preset in the structured test cases, and the timeout boundary is the time threshold preset in the structured test cases. Both are standardized parameters with no room for manual customization.

[0093] The termination boundary is suitable for scenarios where message interaction converges quickly, while the timeout boundary is suitable for scenarios with high response latency, covering all types of negative test scenarios.

[0094] S504: The packet sequence number range from the starting point to the ending point in the traffic evidence is determined as the response observation window.

[0095] Specifically, the observation window strictly follows The left-open, right-closed interval rule retrieves response messages only within the standardized interval, avoiding judgment bias caused by invalid or excessive searches.

[0096] This range can accurately cover all response behaviors of the terminal after abnormal injection, without omission or redundancy.

[0097] This implementation plan defines a standardized observation window by using the injected event as an anchor point. This can fix the retrieval range of terminal responses, eliminate judgment bias caused by differences in human analysis habits and environments, ensure that the response retrieval of negative tests has a unified standard, and improve the consistency of test conclusions under different personnel and environments.

[0098] In an optional implementation, the step of outputting test conclusions characterizing the compliance of the terminal protocol behavior based on the expected response type and the actual set of terminal responses includes: When the expected response type is no response and the actual response set of the terminal is empty, output a test conclusion indicating that the terminal protocol behavior is compliant.

[0099] Specifically, this scenario corresponds to the compliant behavior of the terminal silently discarding abnormal messages as required by the 3GPP standard. It is a core compliance scenario in negative testing and fully complies with the judgment rule of Pass=1.

[0100] Before outputting conclusions, the validity of the structured test cases must be verified. The formula for determining validity is as follows:

[0101] in, The overall result of the structured test case validity assessment is that if all sub-conditions are met, the test case is valid. The field types and hierarchical structure of the test cases conform to the established schema constraints; The message name and parameter values ​​must fall within the standard enumeration range supported by the current network and protocol. The expected response and the candidate response set are semantically consistent and have no logical conflicts. The standard chain of evidence is not empty and contains complete clause numbers, titles, and excerpts from the original text.

[0102] When the expected response type is no response and the actual response set of the terminal is not empty, the test conclusion indicating that the terminal protocol behavior is non-compliant is output.

[0103] Specifically, when a terminal issues a response in a scenario where it should silently discard abnormal messages, it violates the timing constraints and state machine logic specified in the 3GPP standard, which constitutes a protocol behavior violation and fully complies with the Pass=0 judgment rule.

[0104] Such violations can be linked to potential risks defined in the impacts field, providing a basis for endpoint security assessments.

[0105] This implementation plan establishes clear judgment rules for expected unresponsive scenarios, which can accurately identify compliant behaviors of silent terminal abandonment, avoid misjudging standard unresponsive behaviors as abnormal, and improve the stability and accuracy of unresponsive scenarios in negative testing.

[0106] In an optional implementation, the step of outputting test conclusions characterizing the compliance of the terminal protocol behavior based on the expected response type and the actual set of terminal responses includes: When the expected response type is a specific response message, and the actual response set of the terminal contains only one message, and that message matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. Specifically, the specific response message is the variable in the formula; it is the only standard response that the terminal should return in this negative scenario, as specified by the 3GPP standard. Response matching requires simultaneous verification of the message type and key parameters within the message, where the key parameters are defined by the `ue_resp_expected_params` field in the structured test cases. When the message type returned by the terminal is consistent with the specific response message and the key parameters meet expectations, it fully complies with the protocol specification and the judgment rules.

[0107] When the expected response type is the specific response message, and the actual response set of the terminal contains only one message, and that message does not match the specific response message, a test conclusion characterizing non-compliant terminal protocol behavior is output.

[0108] Specifically, if the terminal fails to return a specified standard response, returns an error response, or does not respond, it does not follow the exception handling logic of the 3GPP standard, which constitutes a violation of protocol behavior and is in compliance with regulations. The rule for determining =0.

[0109] Such violations can be directly linked to a standard chain of evidence, clearly identifying the corresponding standard clauses.

[0110] This implementation plan achieves accurate matching and judgment for specific expected response scenarios. It can strictly verify the terminal response behavior according to 3GPP standards, ensuring that the test conclusions are highly consistent with the protocol specifications, and improving the objectivity and authority of the judgment results in specific response scenarios.

[0111] In an optional implementation, the step of outputting test conclusions characterizing the compliance of the terminal protocol behavior based on the expected response type and the actual set of terminal responses includes: The test conclusion indicating that the compliance of the terminal protocol behavior is undeterminable is output when at least one of the following conditions is met: The triggering event could not be located in the traffic evidence.

[0112] Specifically, the uplink reference message specified by the ul_msg_hooked subfield was not found in the traffic evidence, the triggering event is missing, the timing benchmark for the exception injection does not exist, the test premise is not valid, therefore the conclusion cannot be determined.

[0113] The injection event could not be located in the traffic evidence.

[0114] Specifically, no downlink abnormal message specified by the dl_msg_to_send subfield was found in the traffic evidence, the injection event was missing, the observation window had no valid starting point, and response retrieval could not be carried out. Therefore, the conclusion cannot be determined.

[0115] The key packets used to locate triggering or injecting events in the traffic evidence are missing.

[0116] Specifically, the core message packets in the pcap traffic file are missing or corrupted, and the evidence chain for locating the triggering and injection events is broken, making it impossible to support a definitive judgment. Therefore, the conclusion is indeterminate.

[0117] The messages in the candidate response set show multiple hits within the response observation window, and it is impossible to determine a unique actual response.

[0118] Specifically, the observation window shows multiple candidate response messages, making it impossible to distinguish the actual behavior of the terminal. The judgment criteria are vague and not unique, so the conclusion cannot be determined.

[0119] The test execution process was interrupted.

[0120] Specifically, the test case-level state machine operation was interrupted due to reasons such as environment reset failure, terminal abnormality, protocol stack crash, or link disconnection. The test process was not fully executed, and the results were of no reference value. Therefore, the conclusion cannot be determined.

[0121] Or the traffic evidence is incomplete.

[0122] Specifically, the pcap traffic file collection was incomplete, with severe packet loss, and the entire trigger-injection-response process was not covered. The evidence was insufficient to support a valid judgment, therefore the conclusion could not be determined.

[0123] This implementation plan clearly defines various boundary scenarios where judgment is impossible, which can avoid issuing unreliable conclusions when there is insufficient evidence, abnormal processes, or ambiguous basis, ensuring the rigor and verifiability of test results. At the same time, it clearly defines the functional boundaries of the system and avoids the judgment risks caused by testing beyond the scope.

[0124] In an optional implementation, the structured test cases define a standard chain of evidence, which includes at least a standard number, a standard clause number, a clause title, and a fragment of the clause text.

[0125] Specifically, the specs field of the structured test case corresponding to the standard evidence chain includes, in addition to the clause number, the 3GPP standard number, Release version, clause title, and a fragment of the original clause text, satisfying the Valid_specs(TC) legality verification requirements.

[0126] The standard chain of evidence is automatically generated by the standard parsing and knowledge base building module. This module parses 3GPP standard docx documents, builds a local structured knowledge base, and completes the binding of clauses and use cases.

[0127] The complete and specific implementation method of this application is as follows: standard structured representation - structured test case generation - execution environment initialization and exception injection - determination of triggering events and observation windows - deterministic judgment based on pcap, covering the entire closed loop process.

[0128] See Figure 6 As shown, Figure 6 A flowchart of an evidence pointer generation method provided in Embodiment 1 of this application is shown, wherein the method further includes steps S601-S603: S601: Obtain the sequence number of the first packet associated with the triggering event and / or the sequence number of the second packet associated with the injection event from the traffic evidence.

[0129] Specifically, the first packet sequence number is the packet sequence number of the triggering event (uplink reference message) in pcap, and the second packet sequence number is the packet sequence number of the injection event (downlink abnormal message) in pcap. These are the core location identifiers for traffic evidence.

[0130] The packet sequence number is automatically extracted from the traffic decoding results, eliminating the need for manual input and ensuring accuracy.

[0131] S602: Generate evidence pointers corresponding to the test conclusions based on the first package number and / or the second package number, as well as the standard clause number.

[0132] Specifically, the evidence pointer binds the traffic packet sequence number to the 3GPP standard clause number in both directions, forming a complete and verifiable evidence chain of traffic evidence and standard basis, enabling direct backtracking from the conclusion to the original data and the original standard text.

[0133] S603: Output the evidence pointer, which is used to point to the packet in the traffic evidence that is related to the test conclusion and the protocol clause indicated by the standard clause number.

[0134] Specifically, the evidence pointers can be exported, retained, and audited, completely solving the industry pain points of existing negative test conclusions of cellular protocols relying on manual interpretation, being unverifiable, and untraceable, thus meeting the requirements for test compliance and security.

[0135] Evidence pointers support both online viewing and offline review, adapting to the needs of all scenarios such as laboratory testing, batch regression testing, and third-party auditing.

[0136] This implementation plan generates and outputs evidence pointers, which can accurately bind test conclusions with traffic data packets and 3GPP standard clauses, enabling full-link backtracking and auditing of test results. This significantly improves the verifiability and credibility of negative test conclusions and meets the compliance requirements of standardized testing and security assessment.

[0137] Example 2 See Figure 7 As shown, Figure 7 This illustration shows a schematic diagram of a cellular protocol testing and determination device provided in Embodiment 2 of this application, wherein the device includes: The structured test case acquisition module 701 is used to acquire structured test cases for the cellular network terminal under test, as well as traffic evidence corresponding to the structured test cases. The structured test cases at least define an uplink reference message, an injected downlink message, a candidate response set, and an expected response type. Triggering event determination module 702 is used to locate the uplink reference message in the traffic evidence in order to determine the triggering event; The injection event determination module 703 is used to locate the downlink abnormal message corresponding to the injected downlink message in the traffic evidence after the triggering event, and determine the position of the located downlink abnormal message in the traffic evidence as the injection event, wherein the injection event is located after the triggering event; The response observation window determination module 704 is used to determine the response observation window with the injection event as the starting point of the timing anchor point; The actual response set determination module 705 is used to retrieve messages defined by the candidate response set within the response observation window to obtain the actual response set of the terminal. The test conclusion determination module 706 is used to output a test conclusion characterizing the compliance of the terminal protocol behavior based on the expected response type and the actual response set of the terminal.

[0138] In an optional implementation, locating the uplink reference message in the traffic evidence to determine the triggering event includes: Obtain the protocol type, message name, and message direction defined in the uplink reference message from the structured test cases; Based on the protocol type and the message direction, uplink messages matching the message name are filtered from the control plane messages of the traffic evidence; The selected uplink message is identified as the triggering event by its packet sequence number or time position in the traffic evidence.

[0139] In an optional implementation, determining the response observation window using the injection event as the starting point of the timing anchor includes: Obtain the injection packet sequence number corresponding to the injection event in the traffic evidence; The injection package number is used as the starting point of the response observation window; The endpoint of the response observation window is determined based on a preset end boundary or timeout boundary; The packet sequence number range from the starting point to the ending point in the traffic evidence is determined as the response observation window.

[0140] In an optional implementation, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual set of terminal responses includes: When the expected response type is a specific response message, and the actual response set of the terminal contains only one message, and that message matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message, and the actual response set of the terminal contains only one message, and that message does not match the specific response message, a test conclusion characterizing non-compliant terminal protocol behavior is output.

[0141] In an optional implementation, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual set of terminal responses includes: When the expected response type is a specific response message and the actual response set of the terminal contains a message that matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message and the actual response set of the terminal does not contain a message that matches the specific response message, a test conclusion characterizing the non-compliance of the terminal protocol behavior is output.

[0142] In an optional implementation, the step of outputting test conclusions characterizing the compliance of terminal protocol behavior based on the expected response type and the actual set of terminal responses includes: The test conclusion indicating that the compliance of the terminal protocol behavior is undeterminable is output when at least one of the following conditions is met: The triggering event could not be located in the traffic evidence; The injection event could not be located in the traffic evidence; The key packet used to locate the triggering event or the injection event in the traffic evidence is missing; The messages in the candidate response set appear to be hit multiple times within the response observation window and it is impossible to determine a unique actual response. The test execution process was interrupted; Or the traffic evidence is incomplete.

[0143] In an optional implementation, the structured test case defines a standard chain of evidence, which includes at least a standard number, a standard clause number, a clause title, and a fragment of the clause text. The method further includes: Obtain the sequence number of the first packet associated with the triggering event from the traffic evidence, and / or the sequence number of the second packet associated with the injection event; Based on the first package number and / or the second package number, and the standard clause number, generate an evidence pointer corresponding to the test conclusion; Output the evidence pointer, which is used to point to the packet in the traffic evidence that is related to the test conclusion and the protocol terms indicated by the standard evidence chain.

[0144] Example 3 Based on the same application concept, see [link / reference] Figure 8 As shown, Figure 8 This illustration shows a structural schematic diagram of a computer device provided in Embodiment 3 of this application, wherein, as shown... Figure 8 As shown, the computer device 800 provided in Embodiment 3 of this application includes: The computer device 800 includes a processor 801, a memory 802, and a bus 803. The memory 802 stores machine-readable instructions that can be executed by the processor 801. When the computer device 800 is running, the processor 801 communicates with the memory 802 through the bus 803. When the machine-readable instructions are executed by the processor 801, the steps of the cellular protocol test determination method shown in Embodiment 1 are performed.

[0145] Example 4 Based on the same concept, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the cellular protocol test determination method described in any of the above embodiments.

[0146] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0147] The computer program product for performing cellular protocol testing and determination provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0148] The cellular protocol testing and determination device provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0149] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0151] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0153] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0154] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for determining cellular protocol testing, characterized in that, The method includes: Obtain structured test cases for the cellular network terminal under test, and traffic evidence corresponding to the structured test cases, wherein the structured test cases define at least an uplink reference message, an injected downlink message, a candidate response set, and an expected response type; Locate the uplink reference message within the traffic evidence to determine the triggering event; In the traffic evidence, a downlink abnormal message corresponding to the injected downlink message is located after the triggering event, and the position of the located downlink abnormal message in the traffic evidence is determined as the injection event, wherein the injection event is located after the triggering event; The response observation window is determined using the injection event as the starting point of the timing anchor. Retrieve messages defined by the candidate response set within the response observation window to obtain the actual response set of the terminal; Based on the expected response type and the actual response set of the terminal, output test conclusions characterizing the compliance of the terminal protocol behavior.

2. The method according to claim 1, characterized in that, Locating the uplink reference message in the traffic evidence to determine the triggering event includes: Obtain the protocol type, message name, and message direction defined in the uplink reference message from the structured test cases; Based on the protocol type and the message direction, uplink messages matching the message name are filtered from the control plane messages of the traffic evidence; The selected uplink message is identified as the triggering event by its packet sequence number or time position in the traffic evidence.

3. The method according to claim 1, characterized in that, The step of determining the response observation window, using the injected event as the starting point of the time sequence anchor, includes: Obtain the injection packet sequence number corresponding to the injection event in the traffic evidence; The injection package number is used as the starting point of the response observation window; The endpoint of the response observation window is determined based on a preset end boundary or timeout boundary; The packet sequence number range from the starting point to the ending point in the traffic evidence is determined as the response observation window.

4. The method according to claim 1, characterized in that, The test conclusion, which characterizes the compliance of the terminal protocol behavior, is output based on the expected response type and the actual response set of the terminal, including: When the expected response type is no response and the actual response set of the terminal is an empty set, output a test conclusion characterizing the compliance of the terminal protocol behavior; When the expected response type is no response and the actual response set of the terminal is not empty, a test conclusion indicating that the terminal protocol behavior is non-compliant is output.

5. The method according to claim 1, characterized in that, The test conclusion, which characterizes the compliance of the terminal protocol behavior, is output based on the expected response type and the actual response set of the terminal, including: When the expected response type is a specific response message, and the actual response set of the terminal contains only one message, and that message matches the specific response message, a test conclusion characterizing the compliance of the terminal protocol behavior is output. When the expected response type is the specific response message, and the actual response set of the terminal contains only one message, and that message does not match the specific response message, a test conclusion characterizing non-compliant terminal protocol behavior is output.

6. The method according to claim 1, characterized in that, The test conclusion, which characterizes the compliance of the terminal protocol behavior, is output based on the expected response type and the actual response set of the terminal, including: The test conclusion indicating that the compliance of the terminal protocol behavior is undeterminable is output when at least one of the following conditions is met: The triggering event could not be located in the traffic evidence; The injection event could not be located in the traffic evidence; The key packet used to locate the triggering event or the injection event in the traffic evidence is missing; The messages in the candidate response set appear to be hit multiple times within the response observation window and it is impossible to determine a unique actual response. The test execution process was interrupted; Or the traffic evidence is incomplete.

7. The method according to any one of claims 1 to 6, characterized in that, The structured test cases define a standard chain of evidence, which includes at least a standard number, a standard clause number, a clause title, and a fragment of the original clause text. The method further includes: Obtain the sequence number of the first packet associated with the triggering event from the traffic evidence, and / or the sequence number of the second packet associated with the injection event; Based on the first package number and / or the second package number, and the standard clause number, generate an evidence pointer corresponding to the test conclusion; Output the evidence pointer, which is used to point to the packet in the traffic evidence that is related to the test conclusion and the protocol terms indicated by the standard evidence chain.

8. A cellular protocol testing and determination device, characterized in that, The device includes: The structured test case acquisition module is used to acquire structured test cases for the cellular network terminal under test, as well as traffic evidence corresponding to the structured test cases. The structured test cases at least define an uplink reference message, an injected downlink message, a candidate response set, and an expected response type. The trigger event determination module is used to locate the uplink reference message in the traffic evidence in order to determine the trigger event; An injection event determination module is used to locate a downlink abnormal message corresponding to the injected downlink message in the traffic evidence after the triggering event, and determine the position of the located downlink abnormal message in the traffic evidence as an injection event, wherein the injection event is located after the triggering event; The response observation window determination module is used to determine the response observation window with the injection event as the starting point of the timing anchor point; The actual response set determination module is used to retrieve messages defined by the candidate response set within the response observation window to obtain the actual response set of the terminal. The test conclusion determination module is used to output a test conclusion characterizing the compliance of the terminal protocol behavior based on the expected response type and the actual response set of the terminal.

9. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the cellular protocol test determination method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the cellular protocol test determination method as described in any one of claims 1 to 7.

Images