Communication function test method, device, equipment, chip and chip module

Abstract

The invention relates to a communication function test method and device, equipment, a chip and a chip module, and the method comprises the steps: determining a request type corresponding to a test request according to the source of the test request under the condition that the test request is received, and carrying out the test of the communication function under the condition that the request type is an active triggering type; and under the condition that the request type is a configuration triggering type, testing a first communication function of the terminal equipment according to the test request, and under the condition that the request type is a configuration triggering type, testing a second communication function of the terminal equipment according to the test request and a preset configuration library. According to the method, when the communication function of the terminal equipment is tested, system codes do not need to be modified, and the equipment does not need to be recompiled or restarted, so that the dynamic, efficient and reusable test on the communication service link is realized, and the test efficiency is remarkably improved. Meanwhile, by automatically judging and routing to different processing paths according to the source of the request, the most adaptive execution logic can be called, and the test accuracy is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication function testing, and in particular to a communication function testing method, device, equipment, chip and chip module. BACKGROUND

[0002] With the deep integration of the fifth generation mobile communication technology (5G) and the Internet of Things technology, mobile terminals equipped with Android operating systems have become the core carriers of personal communication, industry applications and Internet of Things. To ensure the stable communication reliability of mobile terminals in complex and variable network environments, comprehensive testing and verification of their communication functions have become an indispensable key link in the terminal product development process.

[0003] However, the communication function testing method described in the related art has the problem of low testing efficiency. SUMMARY

[0004] Therefore, it is necessary to provide a communication function testing method, device, equipment, chip and chip module capable of improving testing efficiency to solve the above technical problems.

[0005] In a first aspect, the present application provides a communication function testing method applied to a terminal device, the method comprising:

[0006] In the case of receiving a test request, determining the request type corresponding to the test request according to the source of the test request;

[0007] In the case of the request type being an active trigger type, testing the first communication function of the terminal device according to the test request;

[0008] In the case of the request type being a configuration trigger type, testing the second communication function of the terminal device according to the test request and a preset configuration library.

[0009] In some embodiments, testing the first communication function of the terminal device according to the test request comprises:

[0010] Analyzing the test request to determine the first target communication type and the simulation parameters;

[0011] Performing business simulation processing according to the target communication type and the simulation parameters to generate first simulation response data; the data format of the first simulation response data is consistent with the data format reported by a real baseband chip;

[0012] Reporting the first simulation response data to the communication business layer of the terminal device for instructing the test device to obtain the first reporting result from the communication business layer and testing the first communication function according to the first reporting result to obtain the first test result.

[0013] In some embodiments, the second communication function of the terminal device is tested according to the test request and the preset configuration library, including:

[0014] The test request is analyzed to determine a second target communication type;

[0015] Target configuration information of a target test scene corresponding to the second target communication type is queried in the preset configuration library; the preset configuration library includes a correspondence between communication types and configuration information of test scenes;

[0016] The second communication function is tested according to the target configuration information.

[0017] In some embodiments, the second communication function is tested according to the target configuration information, including:

[0018] The target configuration information is simulated to generate second simulation response data; the data format of the second simulation response data is consistent with the data format reported by a real baseband chip;

[0019] The second simulation response data is reported to a communication service layer of the terminal device, used to instruct the test device to obtain a second reporting result from the communication service layer, and test the second communication function according to the second reporting result to obtain a second test result.

[0020] In some embodiments, the request type corresponding to the test request is determined according to the source of the test request, including:

[0021] In the case where the source of the test request is the terminal device, the request type is determined to be a proactive triggering type;

[0022] In the case where the source of the test request is the test device, the request type is determined to be a configuration triggering type.

[0023] In some embodiments, the method further includes:

[0024] In the case where the configuration write request sent by the test device is received, the configuration write request is analyzed to obtain configuration information of a test scene and a communication service type;

[0025] The configuration information of the test scene and the communication service type are associated and written into the preset configuration library.

[0026] In a second aspect, the application further provides a communication function testing device, which includes:

[0027] A determination module is configured to determine a request type corresponding to a test request according to a source of the test request in the case where the test request is received;

[0028] The first test module is configured to test a first communication function of the terminal device according to the test request when the request type is the active trigger type.

[0029] The second test module is configured to test a second communication function according to the test request and a preset configuration library when the request type is the configuration trigger type.

[0030] In a third aspect, the present application further provides a terminal device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0031] determining a request type corresponding to the test request according to a source of the test request when the test request is received;

[0032] testing a first communication function of the terminal device according to the test request when the request type is the active trigger type;

[0033] testing a second communication function of the terminal device according to the test request and a preset configuration library when the request type is the configuration trigger type.

[0034] In a fourth aspect, the present application further provides a chip, comprising a processor and a communication interface, wherein the processor is configured to enable the chip to perform the following steps:

[0035] determining a request type corresponding to the test request according to a source of the test request when the test request is received;

[0036] testing a first communication function of the terminal device according to the test request when the request type is the active trigger type;

[0037] testing a second communication function of the terminal device according to the test request and a preset configuration library when the request type is the configuration trigger type.

[0038] In a fifth aspect, the present application further provides a chip module, comprising a communication module, a power supply module, a storage module and a chip, wherein:

[0039] The power supply module is configured to provide electric energy for the chip module;

[0040] The storage module is configured to store data and instructions;

[0041] The communication module is configured to perform internal communication of the chip module, or to perform communication between the chip module and an external device;

[0042] The chip is configured to perform the steps of the method provided in the first aspect.

[0043] In a sixth aspect, the present application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the following steps:

[0044] In the case of receiving a test request, determining a request type corresponding to the test request according to a source of the test request;

[0045] In the case of the request type being the active trigger type, testing a first communication function of the terminal device according to the test request;

[0046] In the case of the request type being the configuration trigger type, testing a second communication function of the terminal device according to the test request and a preset configuration library.

[0047] In a seventh aspect, the present application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the following steps:

[0048] In the case of receiving a test request, determining a request type corresponding to the test request according to a source of the test request;

[0049] In the case of the request type being the active trigger type, testing a first communication function of the terminal device according to the test request;

[0050] In the case of the request type being the configuration trigger type, testing a second communication function of the terminal device according to the test request and a preset configuration library.

[0051] The above communication function testing method, device, equipment, chip and chip module, which, in the case of receiving a test request, determines a request type corresponding to the test request according to a source of the test request, and in the case of the request type being the active trigger type, tests a first communication function of the terminal device according to the test request, and in the case of the request type being the configuration trigger type, tests a second communication function of the terminal device according to the test request and a preset configuration library. In the above method, when testing the communication function of the terminal device, the system code does not need to be modified, the device does not need to be recompiled or restarted, the dynamic, efficient and reusable testing of the communication service link is realized, and thus the testing efficiency is significantly improved. Meanwhile, by automatically distinguishing and routing to different processing paths according to the request source, the most suitable execution logic can be called, and the accuracy of the testing is improved. In addition, the method can support the rapid verification of a single communication function, and can also perform deep testing by means of the complex scenes pre-stored in the preset configuration library, and thus the flexibility of the testing is enhanced. BRIEF DESCRIPTION OF DRAWINGS

[0052] Figure 1 An application environment diagram of the communication function testing method in some embodiments.

[0053] Figure 2 This is one of the flowcharts illustrating the communication function testing method in some embodiments;

[0054] Figure 3 This is a second flowchart illustrating the communication function testing method in some embodiments;

[0055] Figure 4 This is the third flowchart illustrating the communication function testing method in some embodiments;

[0056] Figure 5 This is the fourth flowchart illustrating the communication function testing method in some embodiments;

[0057] Figure 6 This is the fifth flowchart illustrating the communication function testing method in some embodiments;

[0058] Figure 7 This is the sixth flowchart illustrating the communication function testing method in some embodiments;

[0059] Figure 8 This is a structural block diagram of the communication function testing device in some embodiments;

[0060] Figure 9 This is an internal structure diagram of the terminal device in some embodiments;

[0061] Figure 10 This is a structural block diagram of the chip module in some embodiments. Detailed Implementation

[0062] In the embodiments of this application, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0063] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0064] In the embodiments of this application, the term "at least one" means one or more. For example, at least one of A, B and C can represent six situations: A exists alone, B exists alone, C exists alone, A and B exist simultaneously, A and C exist simultaneously, B and C exist simultaneously, and A, B and C exist simultaneously.

[0065] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without creative work are within the protection scope of the present application.

[0066] With the deep integration of the fifth generation mobile communication technology (5G) and the Internet of Things technology, mobile terminals carrying the Android operating system have become the core carriers of personal communication, industry application and Internet of Things. In order to ensure the stable communication reliability of mobile terminals in complex and changeable network environment, it is necessary to comprehensively test and verify the communication function of the mobile terminal, which has become an indispensable key link in the process of terminal product research and development. However, the communication function test method recorded in the related art has the problem of low test efficiency.

[0067] In view of this, the embodiments of the present application propose a communication function test method, device, equipment, chip and chip module. When testing the communication function of the terminal device, the system code does not need to be modified, the device does not need to be recompiled or restarted, the dynamic, efficient and reusable test of the communication service link is realized, and the test efficiency is significantly improved.

[0068] It should be noted that the beneficial effects or technical problems solved by the embodiments of the present application are not limited to this, but also other implicit or related problems. For specific details, please refer to the description of the following embodiments.

[0069] The technical solutions of the present application and how the technical solutions of the present application solve the above technical problems will be 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 described again in some embodiments. The embodiments of the present application will be described below with reference to the drawings.

[0070] In some embodiments, the communication function test method provided by the embodiments of the present application can be applied to, for example, Figure 1The application environment shown. Among them, the test device 101 is connected with the terminal device 102. The test device 101 is used for testing the terminal device 102 in different communication functions. Among them, the terminal device 102 can be but not limited to various personal computers, notebook computers, smart phones, tablet computers, Internet of Things devices and portable wearable devices, and the Internet of Things devices can be smart speakers, smart televisions, smart air conditioners, smart vehicle devices, etc. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, etc. The test device 101 can be but not limited to various personal computers, notebook computers, servers and other computer devices. In practical application, the terminal device 102 can be an Android device, the test device 101 can be a computer device (i.e. PC device), and the communication function test process can be a dynamic simulation test of the communication function communication service (i.e. Telephony service such as telephone, network staying, short message, etc.) and its complex scene of PC device to Android device.

[0071] Those skilled in the art can understand that, Figure 1 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the application environment to which the scheme of the present application is applied. The specific application environment can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0072] In some embodiments, as Figure 2 The communication function test method is provided, and the method is applied to the terminal device in Figure 1 For example, the following steps are included:

[0073] S201, in the case of receiving a test request, determining the request type corresponding to the test request according to the source of the test request.

[0074] Among them, the test request is an instruction or data for simulating the test of the communication function of the terminal device. The source of the test request refers to the entity or interface that initiates the test request, such as the command line of the PC terminal or the application (APP) layer on the terminal device. The request type is used to distinguish the triggering mode and execution logic of the test request, including the active triggering type and the configuration triggering type.

[0075] In the embodiments of the present application, the terminal device can receive the test request through various ways. One way is to receive the test request issued by the test device through the command line interface (CLI) module on the terminal device, for example, the user inputs a request in the form of a specific AT instruction through the command line tool (such as adb shell) of the test device. Another way is to receive the test request issued by the local upper-layer application (APP) through the telephony framework on the terminal device, for example, initiated by an automated test application or a debugging tool.

[0076] After receiving the test request, the terminal device can analyze the source of the test request. For example, by analyzing the transmission channel of the request or the identification field in the request data packet, it is determined whether the source of the test request is the test device or the terminal device itself. If the test request comes from the communication link between the CLI module of the test device and the terminal device, it indicates that the source of the test request is the test device, and then it can be determined that the request type of the test request is the configuration trigger type. If the request comes from the calling interface between the upper-layer application and the telephony framework in the terminal device, it indicates that the source of the test request is the terminal device, and then it can be determined that the request type of the test request is the active trigger type.

[0077] S202, in the case where the request type is the active trigger type, testing the first communication function of the terminal device according to the test request.

[0078] The active trigger type indicates that the test request is a single test instruction initiated by the user or test program in real time, which is usually used for immediate verification of a specific communication function. The first communication function refers to a basic or single communication function test that does not require complex preset scene configuration, for example, initiating a simulated call, sending a simulated SMS or querying network status once.

[0079] In the embodiments of the present application, when the terminal device determines that the request type of the test request is the active trigger type, it indicates that it is a test instruction that needs to be executed immediately. The terminal device can analyze the specific operation instruction (for example, a simulated dialing instruction in the form of “ATD1xxx6;”) contained in the test request, and then does not issue the operation instruction to the real baseband chip, but directly simulates the processing flow of the operation instruction in the radio interface layer (RIL), and finally the terminal device collects the simulated response data and encapsulates it as a test result report and transmits it to the test device. After receiving the test result report, the test device determines whether the first communication function passes the test according to the test result report, and obtains the test result.

[0080] S203, in the case of the request type being a configuration trigger type, testing the second communication function of the terminal device according to the test request and a preset configuration library.

[0081] The configuration trigger type indicates that the test request is an operation instruction for setting, querying, modifying, or triggering execution of a test configuration stored in the terminal device. The preset configuration library can be preconfigured or configured in real time during testing, i.e., testing while configuring. The preset configuration library (such as the lib-atStorage.so library) is a database or configuration file stored in the terminal device, used to save a user-defined, complex communication function simulation configuration. The second communication function refers to a complex scenario communication test based on one or more configuration item combinations in the preset configuration library, which can be repeated or triggered according to conditions, such as simulating multiple network registration failures at a specific time point or simulating continuous reception of a specific content message.

[0082] In the embodiments of the present application, when the terminal device determines that the type of the test request is a configuration trigger type, it indicates that the request can be related to a preset test configuration, meaning that the request can only contain an identifier (such as a configuration ID) pointing to a specific scenario in the preset configuration library. The terminal device can then parse the identifier and query and load the corresponding test scenario from the preset configuration library according to the identifier, and then test the second communication function of the terminal device according to the test scenario. The test scenario can define complex logic including instruction sequences, execution intervals, cycle times, and conditional branches. For example, a "registration failure retry" scenario can include a series of operation instructions and their logical relationships, such as "set network status to unavailable", "trigger network registration", "wait for a specific time period", "check registration result", and "repeat triggering if failed". Subsequently, the terminal device can generate and execute a series of sub-test instructions in sequence according to the loaded test scenario. The terminal device does not issue test instructions to the real baseband chip, but directly simulates the processing flow of the test instructions at the wireless interface layer. Finally, the terminal device collects the simulated response data and encapsulates it as a test result report to be transmitted to the test device. After receiving the test result report, the test device determines whether the second communication function passes the test according to the test result report, obtaining the test result.

[0083] The communication function test method provided in the embodiments of the present application comprises the following steps: when a test request is received, the request type corresponding to the test request is determined according to the source of the test request; when the request type is a proactive triggering type, the first communication function of a terminal device is tested according to the test request; and when the request type is a configuration triggering type, the second communication function of the terminal device is tested according to the test request and a preset configuration library. In the above method, when the communication function of the terminal device is tested, the system code does not need to be modified, the device does not need to be recompiled or restarted, and dynamic, efficient and reusable testing of the communication service link is achieved, thereby significantly improving the test efficiency. Meanwhile, by automatically distinguishing and routing to different processing paths according to the request source, the most suitable execution logic can be called, and the accuracy of the test is improved. In addition, the method can support rapid verification of a single communication function and can also perform deep testing by means of the complex scenarios pre-stored in the preset configuration library, thereby enhancing the flexibility of the test.

[0084] In some embodiments, a specific implementation of testing the first communication function of the terminal device according to the test request is also provided, as shown in Figure 3 The "testing the first communication function of the terminal device according to the test request" in S202 comprises the following steps:

[0085] S301, the test request is parsed to determine the first target communication type and the simulation parameter.

[0086] The first target communication type refers to the specific communication service category to be simulated by the test request, such as voice call, SMS sending and receiving, network registration, SIM card state query, etc. The simulation parameter refers to data used to define the details of the simulation behavior, such as the caller number and call time for incoming call simulation, and the sender number, SMS content and receiving time for SMS simulation.

[0087] In the embodiments of the present application, after the terminal device receives the test request (such as an AT instruction format request from the CLI), the test request is first parsed. The parsing process comprises the following steps: identifying the instruction identifier (such as instruction A) of the request, determining the first target communication type corresponding to the instruction identifier according to the predefined instruction mapping table (for example, instruction A is mapped to "voice call initiation", and instruction B is mapped to "SMS sending"). Then, the simulation parameter is extracted from the parameter field of the instruction, wherein the simulation parameter can include the caller number, signal strength value, etc. For example, the target communication type is parsed as "incoming call" and the simulation parameter is the called number "138xxxxxx00" from "ATD138xxxxxx00;".

[0088] S302, the service simulation processing is performed according to the target communication type and the simulation parameter, and the first simulation response data is generated.

[0089] The service simulation processing refers to the behavior of a real baseband chip (Modem) simulated by a wireless interface layer according to the target communication type and the simulation parameter, to construct response data conforming to the communication protocol specification and available for the upper layer service processing. The first simulation response data refers to the data packet or data structure simulated by the simulation processing to simulate the real network or baseband response, for example, a response event of a "network registration success" or a response message containing specific short message content. The data format of the first simulation response data is consistent with the data format reported by the real baseband chip.

[0090] In the embodiment of the present application, the terminal device can start the simulation processing logic after determining the target communication type and the simulation parameter. The processing process does not actually send the request to the physical baseband chip, but is completed in the wireless interface layer. For example, if the target communication type is "querying the current network signal strength", the terminal device can directly construct a structure data containing a specified signal strength value as the first simulation response data according to the simulation parameter (such as a specified strength value -85dBm). If the target communication type is "simulating receiving a short message", the terminal device can assemble a complete short message simulation data according to the sender number and the short message content in the simulation parameter according to the protocol format.

[0091] S303, reporting the first simulation response data to the communication service layer of the terminal device, for instructing the test device to obtain the first reporting result from the communication service layer, and testing the first communication function according to the first reporting result to obtain the first test result.

[0092] The reporting refers to the wireless interface layer in the terminal device, which transmits the generated simulation response data to the communication service layer (Telephony Framework) of the terminal device through a predefined internal interface. The communication service layer is the core framework of the terminal device for managing all telephone services. The test device refers to the PC terminal initiating the test request, which obtains the first reporting result by listening to or querying the state change or callback data of the communication service layer. The first test result is the test conclusion obtained by the test device based on the obtained reporting result and the comparison analysis with the expected result.

[0093] In the embodiments of the present application, after the terminal device generates the first simulation response data, the terminal device can report the first simulation response data to the communication service layer through an inter-process communication mechanism (such as Binder) or a system callback interface. After receiving the data, the communication service layer will analyze and update the internal state as if it were processing the data reported by the real baseband, and can further notify the upper layer application (APP). The test device can obtain the first reporting result from the communication service layer in various ways: one way is that the test tool of the test device captures system logs in real time through a debugging interface such as adb, filters specific logs printed by the communication service layer to confirm whether the simulation event is correctly processed; another way is that the test tool can trigger a query request (such as sending a state query AT command through CLI), and the communication service layer will return the query result based on the latest simulation state, which is the first reporting result. The test device compares the obtained reporting result with the expected result of the test request, and determines whether the simulation test passes, thereby obtaining the first test result. If the first reporting result and the expected result are consistent, it is determined that the simulation test passes, and it is determined that the first test result is that the communication function passes; if the first reporting result and the expected result are inconsistent, it is determined that the simulation test does not pass, and it is determined that the first test result is that the communication function does not pass.

[0094] The method described in the embodiments of the present application can achieve the purpose of dynamically, flexibly and repeatedly testing various communication functions of a terminal device in a closed loop without the participation of real network and baseband hardware, thereby greatly improving the test efficiency and scene coverage.

[0095] In some embodiments, a specific implementation of testing a second communication function of a terminal device according to a test request and a preset configuration library is also provided, as shown in Figure 4 As shown in S203, the "testing a second communication function of a terminal device according to a test request and a preset configuration library" includes:

[0096] S401, analyzing the test request to determine a second target communication type.

[0097] The second target communication type refers to a complex communication service category associated with or operated by the test request and dependent on the preset configuration library. This type usually corresponds to a set of configurable and repeatable test scenarios, such as "timed call test scenario" or "multi-round network switching stress test scenario".

[0098] In the embodiments of the present application, after receiving the test request, the terminal device first analyzes the request to identify the intention, and then determines the second target communication type according to the intention. The analysis process includes identifying the operation instruction in the request, for example, if the request includes "QUERY, CALL", it is analyzed that the intention is "querying the test scenario related to call", and it is determined that the second target communication type is "call type scenario".

[0099] S402, querying the target configuration information of the target test scenario corresponding to the second target communication type in the preset configuration library.

[0100] The preset configuration library includes the correspondence between the communication type and the configuration information of the test scenario. The preset configuration library (such as lib-atStorage.so) is a structured database or a set of configuration files stored in the non-volatile memory of the terminal device. The configuration information of the test scenario is a detailed test behavior definition for a certain communication type, and its content can include scene identification (ID), specific simulation parameters (such as number, content, time), trigger condition (such as system event, timing), execution strategy (such as repetition number, failure handling) and the like. The target test scenario refers to the test scenario stored in the preset configuration library and associated with the second target communication type. The target configuration information refers to the detailed configuration data corresponding to the target test scenario, including but not limited to scene identification, trigger condition, simulation parameter sequence, execution strategy and the like.

[0101] In the embodiments of the present application, after determining the second target communication type, the terminal device can initiate a query to the preset configuration library to obtain the detailed configuration of the specific scene. The specific query method can be flexibly performed according to the request content: if the request is to query all scenes of a certain type, the terminal device takes the second target communication type as the key, retrieves the list of all scene configuration information belonging to the type in the library, and returns. If the request is for a specific scene (such as specified by scene ID), the terminal device first locates the scene configuration information, and verifies whether the communication type to which it belongs matches or is implicitly consistent with the second target communication type. The query process is completed by calling the special API (application program interface) provided by the preset configuration library, for example, calling the query function.

[0102] S403, testing the second communication function according to the target configuration information.

[0103] In the embodiments of the present application, after obtaining the target configuration information, the terminal device can test the second communication function according to the target configuration information. The specific process includes: 1) configuration application: the RILD module in the terminal device reads each parameter in the configuration information and loads it into a specific structure body or context in the memory as the basis for this simulation run. For example, load the configuration "simulate a short message from a specified number every 30 seconds". 2) Condition monitoring and triggering: the RILD module continuously monitors according to the trigger conditions (such as timers, system events) in the configuration. When the trigger condition is met (such as the time reaches the predetermined time), the simulation process is automatically started. 3) Scene simulation execution: the RILD module executes a series of simulation operations according to the process and parameters defined in the configuration information. This process may involve generating multiple simulation response data, simulating state sequence changes and other complex behaviors. For example, execute a scenario of "automatically attempting network registration after booting and simulating three failures before success". The entire test process is completely driven by configuration information and does not need to issue detailed step-by-step instructions again during testing.

[0104] The method described in the embodiments of the present application determines the communication type to be tested by analyzing the test request, queries the corresponding preset scene configuration from the preset configuration library accordingly, and finally automatically executes the test according to the configuration. This process realizes unified management, on-demand calling and automatic execution of complex communication function test scenes, so that users can trigger reusable complex test processes through simple instructions, significantly improving the convenience, execution efficiency and scene coverage of the test.

[0105] In some embodiments, a specific implementation of testing the second communication function according to the target configuration information is also provided, as shown in Figure 5 The "testing the second communication function according to the target configuration information" in S403 above includes:

[0106] S501, simulating the target configuration information to generate second simulation response data; the data format of the second simulation response data is consistent with the data format reported by the real baseband chip.

[0107] Among them, the simulation processing refers to imitating the behavior of the real baseband chip (Modem) at the software level (such as the RIL layer) according to the test scene, parameters and logic defined in the target configuration information, to generate corresponding response data. The consistent data format means that the generated second simulation response data is exactly the same as the data format reported by the real baseband chip to the wireless interface layer (RIL) through the hardware interface, including the data structure, field definition, encoding method, message type identification, etc., so that the upper software cannot distinguish whether the data comes from the real hardware or the software simulation from the data format itself.

[0108] In the embodiments of the present application, after the RILD module of the terminal device acquires the target configuration information, the simulation processing engine can be started. The engine parses the configuration information. For example, if the configuration is "simulate receiving a call from number A when the signal strength is -95dBm, and automatically hang up after 10 seconds", the RILD module will first simulate the baseband chip to report a signal strength measurement report (its data format complies with the signal strength measurement message structure in the 3GPP protocol), and then simulate the reporting of an incoming call notification containing the caller number A at the specified time point (the format complies with the incoming call message structure), and simulate the reporting of a call release notification after 10 seconds. When generating these data, the RILD module strictly assembles them according to the agreed underlying protocol data unit (PDU) format when communicating with the real baseband chip, including the message header, message body, checksum, etc., to ensure that the binary format or high-level abstract interface (such as the Parcel data packet defined by the Android RIL-Java layer) is completely compatible with the hardware reported data.

[0109] S502, report the second simulation response data to the communication service layer of the terminal device, for instructing the test device to acquire a second reporting result from the communication service layer, and test the second communication function according to the second reporting result to obtain a second test result.

[0110] Wherein, the reporting refers to that the terminal device submits the generated second simulation response data to the communication service layer through the system-defined internal communication channel (such as HIDL, AIDL or Binder). The second reporting result refers to the state update, event notification or API return information generated by the communication service layer after receiving and processing the second simulation response data. The second test result refers to the test evaluation conclusion made by the test device on the second communication function (i.e. the complex scene function) based on the comparison and analysis of the expected scene sequence in the target configuration information and the acquired second reporting result.

[0111] In the embodiments of the present application, the terminal device generates the second simulation response data immediately or according to the configured timing, and reports it to the communication service layer through an inter-process communication (IPC) interface. Since the data format is completely consistent, the communication service layer will analyze the data, update the internal state machine (such as the call state and the network registration state), and possibly trigger corresponding broadcast events or callback notifications to the upper layer application, just like processing real hardware events. The test device obtains the second reporting result by listening to the specific event identifier printed by the communication service layer in the system log, actively calling the interface to query the current state, or monitoring the callback information received by the test application (APP). Subsequently, the test tool compares the actual observed result sequence (such as "receiving incoming call notification, call establishment, call release after 10 seconds") with the expected scenario sequence defined in the target configuration information, judges whether the scenario is completely and correctly simulated, and generates the second test result (such as "pass", "fail" and failure reason). If the second reporting result and the expected scenario sequence are consistent, it is determined that the simulation test passes, and the second test result is determined as the communication function passing. If the second reporting result and the expected scenario sequence are inconsistent, it is determined that the simulation test does not pass, and the second test result is determined as the communication function not passing.

[0112] The method described in the embodiments of the present application generates simulation response data completely consistent with the real hardware data format according to the target configuration information, and drives the communication service layer to produce real service state changes, so that the second communication function test for complex scenarios can be performed in a completely simulated and highly controllable environment. This method ensures that the simulation test can seamlessly integrate into the existing communication processing flow of the terminal device, thereby truly and effectively verifying the correctness of the function and the stability of the system under complex service scenarios, and significantly improving the reliability and efficiency of complex scenario testing.

[0113] In some embodiments, as shown in Figure 6 The communication function test method described above further includes:

[0114] S601, in the case of receiving the configuration write request sent by the test device, the configuration write request is parsed to obtain the configuration information of the test scenario and the communication service type.

[0115] The configuration write request is an instruction for adding or updating a test scenario configuration in the preset configuration library in the terminal device. Parsing means identifying the operation type of the request and extracting the effective data encapsulated therein. The configuration information of the test scenario describes the specific content of a complete test scenario, which can include scenario identifier, trigger condition, simulation parameter sequence, execution strategy, etc. The communication service type is the communication function category to which the test scenario is directed, such as voice call, short message, network registration, etc.

[0116] In the embodiment of the present application, the terminal device receives a configuration write request from the test device through its command line interface (CLI) module, which usually follows a private protocol format based on AT commands. The RILD module of the terminal device parses the request. Specifically, the RILD module identifies the operation instruction in the request and confirms that the operation instruction is a configuration write operation. Then, the RILD module extracts the test scenario configuration information encapsulated in a specific format (such as JSON, XML, or custom key-value pair) from the parameter field of the request, and extracts or derives the communication service type (such as "voice call", "short message", or "network attachment") to which the scenario belongs.

[0117] S602, write the configuration information of the test scenario and the communication service type into the preset configuration library in association.

[0118] Among them, the associated write means to establish a logical binding relationship between the parsed test scenario configuration information and the communication service type corresponding to the configuration information, and store it as a complete configuration entry in the preset configuration library, so that the configuration can be retrieved and classified by the communication service type.

[0119] In the embodiment of the present application, the terminal device can call the storage interface provided by the preset configuration library (such as lib-atStorage.so library) to store the communication service type as a classification tag or index key and the configuration information of the test scenario as the main content in the non-volatile memory (such as flash memory) of the terminal device. Through this operation, the user-defined, reusable complex test scenario configuration can be saved locally in the terminal device.

[0120] The method described in the embodiment of the present application receives and parses the configuration write request from the test device, extracts the scenario configuration and service type information in the write request, and stores them in association in the preset configuration library locally in the terminal device, which realizes the dynamic configuration and persistent management of complex communication test scenarios. The user can flexibly create and accumulate diversified test scenario configurations as needed, providing a rich scenario resource library for subsequent execution of complex and repeatable automatic communication function testing, which significantly improves the flexibility and scalability of the test.

[0121] In combination with all the above embodiments, a communication function test method is also provided, which comprises:

[0122] S701, receive a test request, and in the case that the source of the test request is a terminal device, determine that the request type is an active trigger type.

[0123] S702, in the case that the source of the test request is a test device, determine that the request type is a configuration trigger type.

[0124] S703, in the case of the request type being an active trigger type, parsing the test request to determine a first target communication type and simulation parameters.

[0125] S704, according to the target communication type and the simulation parameters, performing service simulation processing to generate first simulation response data. The data format of the first simulation response data is consistent with the data format reported by the real baseband chip.

[0126] S705, reporting the first simulation response data to the communication service layer of the terminal device, for instructing the test device to obtain a first reporting result from the communication service layer and test the first communication function according to the first reporting result, to obtain a first test result.

[0127] S706, in the case of the request type being a configuration trigger type, parsing the test request to determine a second target communication type.

[0128] S707, querying target configuration information of a target test scene corresponding to the second target communication type in a preset configuration library. The preset configuration library includes a correspondence between communication types and configuration information of test scenes.

[0129] S708, simulating the target configuration information to generate second simulation response data. The data format of the second simulation response data is consistent with the data format reported by the real baseband chip.

[0130] S709, reporting the second simulation response data to the communication service layer of the terminal device, for instructing the test device to obtain a second reporting result from the communication service layer and test a second communication function according to the second reporting result, to obtain a second test result.

[0131] S710, in the case of receiving a configuration write request sent by the test device, parsing the configuration write request to obtain configuration information of a test scene and a communication service type.

[0132] S711, associating and writing the configuration information of the test scene and the communication service type into the preset configuration library.

[0133] In the embodiment of the present application, a communication function rapid debugging tool is described, which builds the communication between a test device (PC terminal) and the RILD module in a terminal device (Android device). A user performs communication function simulation configuration through the private communication protocol based on AT commands between the test device and the RILD module in the terminal device to simulate the expected communication process, thereby completing the function test of the RILD module and the communication chain of the upper layer application. In this process, the test scenario configuration in the preset configuration library does not reach the real baseband chip (CP) when reaching the RILD module, but generates and returns simulation response data directly in the RILD module. The user can freely set the combination of multiple communication scenarios to simulate the communication scenarios that are difficult to achieve in the real network environment. After each test is completed, the configuration in the preset configuration library can be emptied, deleted or saved (the configuration still takes effect after the device restarts) through the private protocol, so as to facilitate the next test, which enables multiple tests to be completed without re-burning or restarting the device.

[0134] As shown in Figure 7 , taking the test device (PC terminal) and the terminal device (Android device) as an example, the specific implementation process of the embodiment is exemplarily described, which includes:

[0135] (1) Connection of the test device (PC terminal) and the terminal device (Android device): first, the connection between the test device and the terminal device is established through the Android Debug Bridge (ADB) command, so that the test device can operate the terminal device.

[0136] Command execution: through the adb shell and other command line tools, the terminal device is connected to the test device (development machine) to allow the execution of commands and access to the device.

[0137] Device identification: through adb devices, it is ensured that the terminal device has been connected and correctly identified.

[0138] (2) Manual execution of the command line interface (CLI) executable file: after the connection is successful, the command line interface (CLI) executable file (such as RIL-CLI) is manually executed on the test device. The file is a command line tool for communication with the terminal device.

[0139] Function of CLI: the executable file is a command line interface (CLI) tool, which can accept and process the test request (in the format of AT instruction) input by the user.

[0140] Parameter transmission: when executing the CLI, the test request to be executed is transmitted to the CLI process through the command line parameter (such as char**arg).

[0141] (3) CLI process handles test request and communicates with RILD process: After receiving the test request (AT command), the CLI process needs to communicate with the RILD (Radio Interface Layer Daemon) in the terminal device through the Inter-Process Communication (IPC) mechanism.

[0142] In the entry function of the CLI, the test request is extracted into parameters.

[0143] The CLI uses the Binder mechanism to establish communication with the RILD process.

[0144] (4) RILD process handles Binder request: The RILD process receives and processes the Binder request from the CLI, parses and processes the request.

[0145] After receiving the test request passed from the CLI process, the RILD decides the specific operation to be performed according to the request type of the request (e.g., determines whether it is an active trigger type or a configuration trigger type).

[0146] During execution, the RILD may call the underlying preset configuration library (such as lib-atStorage.so) or simulation logic as needed to complete instruction processing.

[0147] (5) RILD calls preset configuration library to handle instructions: The preset configuration library (lib-atStorage.so) is a shared library specifically designed to handle configuration-related test requests, involving storage, reading, and modification of test scenario configuration information in the library.

[0148] The functions in the library will analyze the passed test request and perform corresponding operations such as querying, adding, modifying, or deleting test scenario configuration information.

[0149] Data saving: The execution results and related configuration data are saved in the preset configuration library for subsequent use.

[0150] (6) Generate simulation response and return results: After instruction execution is complete, the RILD will generate simulation response data and return the results through a callback mechanism.

[0151] Result generation: According to the type and parameters of the test request, the RILD will generate corresponding simulation response data (such as first simulation response data or second simulation response data).

[0152] Return mechanism: The RILD will return the simulation response data to the CLI process through the Binder mechanism. After receiving the results, the CLI process can present them to the user, or the test device can further analyze the results to obtain test results based on the results.

[0153] The method provided by the embodiments of the present application can quickly verify protocol functions through a simulation communication interface, does not need to rely on complete system implementation, and can achieve the effect of quickly plugging in code. Through supporting real-time monitoring and adjustment of communication states, dynamic viewing of data streams and problems, the effect of real-time dynamic debugging can be achieved. The method does not need to be recompiled, can dynamically adjust configurations, can reduce debugging waiting time, and can achieve the effect of compilation-free / dynamic configuration. Through providing an intuitive interface, configuration and debugging operations are simplified, and the effect of easy use can be achieved. The method is seamlessly integrated with existing development environments, is convenient for continuous verification, and can achieve the effect of easy integration. Through supporting compatibility of different versions and protocols, the method does not need to worry about version updates affecting the debugging process, and can achieve the effect of decoupling from versions.

[0154] The PC terminal can dynamically simulate and test the Telephony service of an Android device and complex scenarios of the Telephony service; the PC terminal user can dynamically and real-timely configure desired communication functions, and can set an effective time and a number of times; the user can complete multiple communication tests without re-burning the device or restarting the device; a private protocol for communication between the PC terminal and the Android device based on AT commands is constructed; and a communication function simulation configuration library that can be added, deleted, modified, and inquired on the Android side is constructed.

[0155] The method described in each of the steps is described in the foregoing embodiments, and the details are described in the foregoing description, which will not be described herein.

[0156] It should be understood that, although each step in the flowchart involved in each of the above-described embodiments is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, at least part of the steps in the flowchart involved in each of the above-described embodiments can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or steps or stages in other steps.

[0157] Based on the same inventive concept, the embodiments of the present application also provide a communication function test device for implementing the above-described communication function test method. The device can be applied or integrated in a chip or a chip module, etc. The implementation scheme for solving problems provided by the device is similar to the implementation scheme described in the above method, and therefore the specific limitations in one or more communication function test device embodiments provided below can refer to the limitations of the communication function test method described above, which will not be described herein.

[0158] In some embodiments, as shown in FIG. 1, a communication function test apparatus is provided, comprising: Figure 8

[0159] A determination module 11 is configured to determine a request type corresponding to a test request according to a source of the test request when the test request is received.

[0160] A first test module 12 is configured to test a first communication function of a terminal device according to the test request when the request type is an active trigger type.

[0161] A second test module 13 is configured to test a second communication function according to the test request and a preset configuration library when the request type is a configuration trigger type.

[0162] In some embodiments, the first test module comprises:

[0163] A first analysis unit is configured to analyze the test request to determine a first target communication type and simulation parameters.

[0164] A simulation unit is configured to perform service simulation processing according to the target communication type and the simulation parameters to generate first simulation response data; the data format of the first simulation response data is consistent with a data format reported by a real baseband chip.

[0165] A reporting unit is configured to report the first simulation response data to a communication service layer of the terminal device, to instruct the test device to obtain a first reporting result from the communication service layer, and to test the first communication function according to the first reporting result to obtain a first test result.

[0166] In some embodiments, the second test module comprises:

[0167] A second analysis unit is configured to analyze the test request to determine a second target communication type.

[0168] A query unit is configured to query target configuration information of a target test scene corresponding to the second target communication type in a preset configuration library; the preset configuration library comprises a correspondence between communication types and configuration information of test scenes.

[0169] A test unit is configured to test the second communication function according to the target configuration information.

[0170] In some embodiments, the test unit comprises:

[0171] A simulation subunit is configured to perform simulation processing on the target configuration information to generate second simulation response data; the data format of the second simulation response data is consistent with a data format reported by a real baseband chip. ​

[0172] The reporting subunit is used to report the second simulated response data to the communication service layer of the terminal device, and to instruct the test device to obtain the second reporting result from the communication service layer, and to test the second communication function based on the second reporting result to obtain the second test result.

[0173] In some embodiments, the determining module includes:

[0174] The first determining unit is used to determine that the request type is an actively triggered type when the source of the test request is a terminal device.

[0175] The second determining unit is used to determine the request type as a configuration trigger type when the source of the test request is a test device.

[0176] In some embodiments, the above-mentioned communication function testing apparatus further includes:

[0177] The receiving unit is used to parse the configuration write request sent by the test device to obtain the configuration information and communication service type of the test scenario.

[0178] The association unit is used to associate the configuration information of the test scenario with the communication service type and write it into the preset configuration library.

[0179] Each module in the aforementioned communication function testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the terminal device in hardware form or independent of it, or stored in the memory of the terminal device in software form, so that the processor can call and execute the operations corresponding to each module.

[0180] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0181] In some embodiments, a terminal device is provided, the internal structure of which can be as shown in the figure below. Figure 9As shown, the terminal device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a communication function testing method. The display unit of the terminal device forms a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the terminal device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the terminal device, or external keyboards, touchpads, or mice, etc.

[0182] In some embodiments, a terminal device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the communication function testing method described in any of the above embodiments.

[0183] The terminal device provided in the above embodiments has a similar implementation principle and technical effect to the above method embodiments, and will not be described again here.

[0184] Based on the same inventive concept, this application also provides a chip, including a processor and a communication interface; the communication interface is used to receive or send data; the processor is configured to cause the chip to perform the steps of implementing the communication function test method described in any of the above embodiments.

[0185] It is understood that the chip involved in the embodiments of this application may be a field-programmable gate array (FPGA), may be an application-specific integrated circuit (ASIC), may be a system on chip (SoC), may be a central processor unit (CPU), may be a network processor (NP), may be a digital signal processor (DSP), may be a microcontroller unit (MCU), may be a programmable logic device (PLD), or other integrated chips, etc.

[0186] Based on the same inventive concept, this application also provides a chip module, such as... Figure 10 As shown, the chip module includes a communication module, a power module, a storage module, and a chip. Among them:

[0187] The power module is used to provide power to the chip module; the storage module is used to store data and instructions; the communication module is used for internal communication within the chip module, or for communication between the chip module and external devices; this chip corresponds to the chip in the above chip embodiment.

[0188] The implementation method of this chip module can be found in the relevant content of the above chip embodiment, and will not be repeated here.

[0189] In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the communication function testing method described in any of the above embodiments.

[0190] The computer-readable storage medium provided in the above embodiments has a similar implementation principle and technical effect to the above method embodiments, and will not be described again here.

[0191] In some embodiments, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the communication function testing method described in any of the above embodiments.

[0192] The computer program product provided in the above embodiments has a similar implementation principle and technical effect to the above method embodiments, and will not be described again here.

[0193] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0194] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are 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.

[0195] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for testing communication functions, characterized in that, Applied to a terminal device, the method includes: Upon receiving a test request, the request type corresponding to the test request is determined based on the source of the test request; When the request type is an active trigger type, the first communication function of the terminal device is tested according to the test request; When the request type is a configuration trigger type, the second communication function of the terminal device is tested according to the test request and the preset configuration library.

2. The method according to claim 1, characterized in that, The step of testing the first communication function of the terminal device according to the test request includes: The test request is parsed to determine the first target communication type and simulation parameters; Based on the target communication type and the simulation parameters, a service simulation process is performed to generate first simulated response data; the data format of the first simulated response data is consistent with the data format reported by the real baseband chip. The first simulated response data is reported to the communication service layer of the terminal device, which instructs the test device to obtain the first reporting result from the communication service layer and test the first communication function based on the first reporting result to obtain the first test result.

3. The method according to claim 1, characterized in that, The step of testing the second communication function of the terminal device according to the test request and the preset configuration library includes: The test request is parsed to determine the second target communication type; The target configuration information of the target test scenario corresponding to the second target communication type is queried from the preset configuration library; the preset configuration library includes the correspondence between communication types and test scenario configuration information. The second communication function is tested based on the target configuration information.

4. The method according to claim 3, characterized in that, The step of testing the second communication function according to the target configuration information includes: The target configuration information is simulated to generate second simulated response data; the data format of the second simulated response data is consistent with the data format reported by the real baseband chip. The second simulated response data is reported to the communication service layer of the terminal device, which instructs the test device to obtain the second reporting result from the communication service layer and to test the second communication function based on the second reporting result to obtain the second test result.

5. The method according to any one of claims 1-4, characterized in that, Determining the request type corresponding to the test request based on its source includes: If the source of the test request is the terminal device, the request type is determined to be the active triggering type; If the source of the test request is a test device, the request type is determined to be the configuration trigger type.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: Upon receiving a configuration write request from the test device, the configuration write request is parsed to obtain the configuration information and communication service type of the test scenario; The configuration information of the test scenario and the communication service type are associated and written into the preset configuration library.

7. A communication function testing device, characterized in that, The device includes: The determination module is used to determine the request type corresponding to the test request based on the source of the test request when a test request is received; The first test module is used to test the first communication function of the terminal device according to the test request when the request type is an active trigger type. The second testing module is used to test the second communication function according to the test request and the preset configuration library when the request type is a configuration trigger type.

8. A terminal device, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A chip, characterized in that, The device includes a processor and a communication interface, wherein the processor is configured to cause the chip to perform the steps of the method described in any one of claims 1 to 6.

10. A chip module, characterized in that, This includes communication modules, power modules, storage modules, and chips, among which: The power module is used to provide power to the chip module; The storage module is used to store data and instructions; The communication module is used for internal communication within the chip module, or for communication between the chip module and external devices. The chip is used to perform the steps of the method according to any one of claims 1 to 6.

Images