A test method and system for a mandatory parent node based on a mesh network

Abstract

The embodiment of the application provides a test method and system of a compulsory parent node based on a Mesh network, the method comprises the following steps: defining a topology structure of the Mesh network based on a test requirement, the topology structure containing an association list of a child node and a target parent node; extracting configuration information of each child node, generating a configuration instruction based on the configuration information, and enabling the child node side to establish a connection relationship with the target parent node based on the configuration instruction; checking based on a connection result periodically fed back by the child node, generating a health state level corresponding to each link, and generating a corresponding response strategy according to different health state levels; executing a corresponding test case based on the test requirement, and recording test data; after receiving a test requirement update instruction, determining a change mode based on the update instruction, modifying a parent node configuration of the child node based on the change mode, recording a change time stamp, and determining a dynamic response capability of the child node.

Description

Technical Field

[0001] This invention relates to the field of wireless communication network testing technology, and in particular to a testing method and system for a mandatory parent node based on a Mesh network. Background Technology

[0002] In laboratory testing scenarios for mesh networks, automatic routing mechanisms are typically relied upon, where nodes autonomously select the optimal parent node based on factors such as signal strength and load. This self-organizing characteristic enhances network adaptability in real-world deployments.

[0003] However, the above situation has significant drawbacks in the testing environment. These drawbacks include: uncontrollable paths: nodes may switch parent nodes due to random factors such as environmental interference and signal fluctuations, causing data transmission paths to deviate from the preset topology, making it impossible to stably reproduce multi-hop routing scenarios; non-reproducible test results: the same test cases may yield significantly different results at different times or in different environments, affecting the accurate verification of functions such as routing protocols, roaming performance, and fault recovery; and difficulty in simulating abnormal scenarios: it is difficult to construct boundary test conditions such as forced connection with weak signals and switching of faulty nodes, making it impossible to fully verify network robustness.

[0004] To address the aforementioned shortcomings, existing technologies for Mesh networks primarily focus on network optimization and automatic routing algorithms, such as RSSI-based parent node selection mechanisms and load balancing routing protocols. There is an urgent need for a technical solution specifically designed for testing scenarios that enables path controllability. Summary of the Invention

[0005] To address the problems existing in the prior art, embodiments of the present invention provide a testing method and system for a mandatory parent node based on a Mesh network.

[0006] Firstly, embodiments of this specification provide a testing method for a mandatory parent node based on a Mesh network, the method comprising:

[0007] Obtain test requirements, and define the topology of the Mesh network based on the test requirements. The topology includes a list of associations between child nodes and target parent nodes.

[0008] Extract the configuration information of each child node, and generate configuration instructions based on the configuration information, so that the child node can establish a connection with the target parent node based on the configuration instructions;

[0009] The connection results are verified based on the periodic feedback from the child nodes. Based on the verification results, a health status level is generated for each link, and a corresponding response strategy is generated according to different health status levels.

[0010] Execute the corresponding test cases based on the aforementioned test requirements and record the test data;

[0011] Upon receiving a test request update instruction, the change mode is determined based on the update instruction, and the parent node configuration of the child node is modified based on the change mode. The change timestamp is recorded, and the dynamic response capability of the child node is determined.

[0012] Secondly, embodiments of this specification provide a test system for a mandatory parent node based on a Mesh network, the system comprising:

[0013] The acquisition module is used to acquire test requirements and define the topology of the Mesh network based on the test requirements. The topology includes a list of associations between child nodes and target parent nodes.

[0014] The connection module is used to extract the configuration information of each child node and generate configuration instructions based on the configuration information, so that the child node can establish a connection relationship with the target parent node based on the configuration instructions;

[0015] The verification module is used to verify the connection results periodically fed back by the child nodes, generate a health status level for each link based on the verification results, and generate a corresponding response strategy according to different health status levels.

[0016] The testing module is used to execute corresponding test cases based on the test requirements and record test data;

[0017] The update module is used to receive a test requirement update instruction, determine the change mode based on the update instruction, modify the parent node configuration of the child node based on the change mode, record the change timestamp, and determine the dynamic response capability of the child node.

[0018] Thirdly, embodiments of this specification provide an electronic device, including a processor and a memory;

[0019] The processor is connected to the memory;

[0020] The memory is used to store executable program code;

[0021] The processor runs a program corresponding to the executable program code stored in the memory to perform the methods described in one or more embodiments.

[0022] Fourthly, embodiments of this specification provide a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described test method for the required parent node based on a Mesh network.

[0023] In view of the above, the beneficial effects of the technical solutions provided by some embodiments of this specification include at least the following:

[0024] In one or more embodiments of this specification, test requirements are obtained, and the topology of the Mesh network is defined based on these requirements. The topology includes a list of associations between child nodes and target parent nodes. Configuration information for each child node is extracted, and configuration instructions are generated based on this information. These instructions are then used by the child nodes to establish connections with the target parent node. Connection results are periodically fed back by the child nodes for verification. Based on the verification results, a health status level is generated for each link, and a corresponding response strategy is generated according to each health status level. Corresponding test cases are executed based on the test requirements, and test data is recorded. Upon receiving a test requirement update instruction, a change mode is determined based on the update instruction, and the parent node configuration of the child node is modified based on the change mode. The change timestamp is recorded, and the dynamic response capability of the child node is determined. By forcing nodes to connect to specified parent nodes, a fixed topology is constructed, ensuring that the test path is consistent with the preset path. When the same test cases are executed at different times, the topology remains stable, and the test data is comparable. Furthermore, extreme conditions such as forced connection with weak signals and switching of faulty nodes can be simulated, comprehensively verifying network performance and reducing test repetition caused by path fluctuations, thus shortening the functional verification cycle. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart illustrating a test method for a mandatory parent node based on a Mesh network, provided in one embodiment of this specification.

[0027] Figure 2 This is a test framework diagram of a mandatory parent node in a Mesh network provided in one embodiment of this specification.

[0028] Figure 3 This is a schematic diagram of the structure of a test system based on a Mesh network with a required parent node, provided in one embodiment of this specification.

[0029] Figure 4 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this specification. Detailed Implementation

[0030] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed merely to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. The function and arrangement of the elements discussed may be changed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the various examples. For example, the described methods may be performed in a different order than described, and steps may be added, omitted, or combined. Furthermore, features described in some examples may be combined in other examples.

[0031] As used herein, the term "comprising" and its variations are open terms meaning "including but not limited to". The term "based on" means "at least partially based on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. Unless explicitly indicated by the context, the definition of a term shall remain consistent throughout the specification.

[0032] Please see Figure 1 , Figure 1 This document presents an overall flowchart of a testing method for a mandatory parent node based on a Mesh network, as provided in an embodiment of this specification. The device driver model includes an application service layer, a driver interface layer, and a peripheral layer.

[0033] like Figure 1 As shown, this test method for the required parent node in a Mesh network includes at least the following steps:

[0034] Step S102: According to the test requirements, define the topology of the Mesh network in the test controller, including the number of nodes, hierarchical relationship, and the required parent node identifier (MAC address or Node ID) for each child node.

[0035] Specifically, the topology of the Mesh network is defined based on testing requirements. This topology includes a node list and hierarchical relationships. Further, the node list can include each node's unique identifier (MAC address or serial number), device model, firmware version, and current online status. The hierarchical relationships can include one or more root nodes, as well as a list of associations linking child nodes to specific parent nodes. Furthermore, a binding mode between each child node and its parent node is defined, which can include a strict mode (where the target parent node is the only legitimate connection object for the child node, and the child node must remain isolated even if the parent node is offline) and a preferred mode (which prioritizes connecting to the target parent node; if a connection fails under specified conditions, it allows fallback to automatic routing).

[0036] In addition, for the binding mode between child and parent nodes, connection parameters for the binding mode can be defined, that is, expected parameters can be set for each forced parent-child link, including the minimum signal strength threshold (e.g., RSSI not lower than -70dBm), the maximum allowable packet loss rate, and the connection timeout determination duration, etc. Then, the node mapping, binding mode, and link constraint threshold are saved as a structured configuration file.

[0037] Step S104: Through the master station remote control page or local monitoring window, send configuration instructions to the child node to force it to connect only to the preset parent node and disable the automatic discovery and routing logic.

[0038] Specifically, the system checks whether the links between nodes can be connected via a management channel independent of the Mesh network, such as wired Ethernet, independent near-field communication, or dedicated management Wi-Fi. When the out-of-band channel is unavailable, the in-band channel, i.e., the Mesh network, is used. The controller extracts the configuration information of each child node from the above steps and generates configuration instructions. These instructions include the parent node identifier, binding mode (strict mode or preferred mode), link constraint thresholds, etc. These instructions are then sent to the target child nodes through the established control channel.

[0039] Upon receiving the configuration command, the node verifies the legitimacy of the source and activates the test mode lock, setting a global flag. This global flag is referenced by all layers of the protocol stack (such as the MAC layer, network layer, and application layer), switching the protocol stack from an adaptive state to a deterministic conformity state. Specifically, at the MAC layer, scan suppression is implemented, stopping periodic active or background scans and ceasing to report newly discovered neighbor nodes to upper layers. Furthermore, the routing function is bypassed, and the target parent node becomes the only associatable object. For different modes, in strict mode, connection requests are only allowed to the specified parent node. If the connection is lost, the request will be retried indefinitely without any roaming attempts. In preferred mode, the specified parent node is prioritized for connection, but after N consecutive failed retries or timeouts, if the flag allows, the connection to other nodes is temporarily relaxed.

[0040] After a node completes the forced association, it sends a confirmation message to the controller. This message includes the current parent node, signal strength, negotiation rate, and whether the forced binding was strictly followed (if the process is relaxed in preferred mode, this needs to be explained). Upon receiving information from all nodes, the controller compares the actual topology with the preset topology to check for anomalies. If an anomaly is found, it marks the anomaly point.

[0041] Step S106: Collect parameters such as the connection status, signal strength, and data transmission rate of the node in real time, and verify whether the child node has successfully bound to the specified parent node. If a connection error occurs, reconfigure the node.

[0042] Specifically, the system receives periodic data and event reports from each child node in real time, including link status, current parent node identifier, signal strength, and transmission rate. Then, within each controller cycle, a verification loop is performed. The verification loop includes the following checks: parent node consistency check (checking if the parent node identifier reported by the child node matches the specified parent node identifier); signal strength check (checking if the reported signal strength is below the minimum signal strength threshold); and connection status check (checking if the child node is in an associated state). Based on the verification results, a health status level is generated for each link. The health status levels include, but are not limited to: Healthy (parent node consistent, RSSI meets the standard, associated); Weak Link (parent node consistent, associated, but RSSI below the threshold (applicable to intentionally constructed weak signal tests; no forced repair as long as it's not broken)); Connection Failure (parent node consistent, associated, but RSSI below the threshold (applicable to intentionally constructed weak signal tests; no forced repair as long as it's not broken)); Topology Violation (parent node inconsistent).

[0043] Different response strategies are determined for the different health status levels mentioned above. These response strategies include:

[0044] When the health status level is healthy link, only logs are recorded to form the stable period data in the test report.

[0045] When the health status level is weak link, it is marked as a weak signal condition test when logging.

[0046] When the health status level is "connection failure," if it's in strict mode, since child nodes are prohibited from switching to other parent nodes, a forced re-association command to the target parent node can be sent, and it should be marked. Additionally, if the target parent node experiences a permanent failure, the test case should be terminated and marked as the disconnection limit, serving as a verification scenario in the test environment. If it's in preferred mode, multiple attempts to reconfigure the target parent node should be made. If all attempts fail, a temporary unbinding command should be issued to the child node, allowing it to revert to automatic routing mode to ensure its network connectivity. Furthermore, the original target parent node should be continuously monitored, and once it recovers, the connection should be switched back to the target parent node.

[0047] When the health status level is topology violation, the control sends a command to disconnect the current connection and force a connection to the target parent node. If the child node is in strict mode, it will also check whether its test mode lock has been accidentally released. If it has been released, it will be reactivated.

[0048] Step S108: Based on the fixed topology, execute the preset test cases, record and analyze the test data.

[0049] Specifically, after constructing the test topology, it is controlled to execute test logic according to the test script, and execution data is recorded during the process. Execution data includes service performance data, network status data, and test event logs. This execution data is then overlaid on the same timeline to locate any performance degradation points during the test, and to check whether the link is in a weak signal range, whether there are topology violations, or whether there are retransmission events. Furthermore, for relatively important test cases, multiple executions can be performed under identical topology snapshots to generate baseline performance ranges for multiple executions, and the test results are then output.

[0050] Step S110: Continuously monitor the drone status, and detect task anomalies by combining the drone status, wind shear index distribution, horizontal divergence field and vertical vortex field. When a task anomaly occurs, calculate the task cost function of the substitute drone, and allocate the substitute drone based on the task cost function.

[0051] Specifically, during testing, if a new topology result test request is received, a mandatory binding relationship update instruction between the child node and the target parent node is generated. This update instruction includes the new parent node identifier, the new binding mode, and the change instruction ID. However, the original parent node is not immediately disconnected; instead, the node switches to a ready state and then determines the switching mode. The switching mode can be adjusted according to different test scenarios. For example, there is a "connect first" mode, where the child node first attempts to initiate a connection request to the new parent node, and only disconnects from the original parent node after the link with the new parent node is successfully established. This mode is suitable for testing seamless roaming with the shortest possible service interruption time. Alternatively, there is a "disconnect first" mode, where the child node first sends a disassociation notification to the original parent node, disconnecting the existing connection, and then immediately switches to the new parent node for scanning and connection. This mode is used to test rerouting and fault recovery, simulating scenarios where the parent node suddenly fails. Furthermore, during execution, the node's automatic routing logic still only allows connections to the specified new parent node.

[0052] For the aforementioned handover process, relevant timestamps are monitored and recorded, such as the time the handover command is issued, the time the original parent node disconnects, the time the new parent node is associated, and the time the service data flow restarts. Performance metrics are then established based on these timestamps. For example, the performance metric for the handover decision can be determined by subtracting the handover command issuance time from the time the original parent node disconnects; network reconnection latency can be determined by subtracting the original parent node disconnection time from the time the new parent node is associated; and service interruption duration can be determined by subtracting the interruption time from the time the service data flow restarts. This establishes a performance baseline. Then, using this performance baseline as a benchmark, multiple test script adjustment commands are concatenated to generate a topology change script. Timestamps are generated from these adjustment commands based on the performance baseline results. Finally, combined with reported data, test results and dynamic response times for the test system are generated.

[0053] This invention provides a testing method for mandatory parent nodes in a mesh network. The method involves obtaining test requirements, defining the mesh network topology based on these requirements (including a list of associations between child nodes and target parent nodes), extracting configuration information for each child node, generating configuration instructions for the child nodes to establish connections with the target parent node, verifying connections based on periodic feedback from the child nodes, generating health status levels for each link based on these verification results, and generating corresponding response strategies for different health status levels. The method executes corresponding test cases based on the test requirements and records test data. Upon receiving a test requirement update instruction, the method determines the change mode based on the update instruction, modifies the parent node configuration of the child nodes based on the change mode, records the change timestamp, and determines the dynamic response capability of the child nodes. By forcing nodes to connect to a specified parent node, a fixed topology is constructed, ensuring that the test path is consistent with the preset path. When the same test cases are executed at different times, the topology remains stable, and the test data is comparable. Furthermore, it can simulate extreme conditions such as forced connection with weak signals and switching of faulty nodes, comprehensively verifying network performance, reducing test repetition caused by path fluctuations, and shortening the functional verification cycle.

[0054] In another embodiment, the test framework diagram for a test method of mandatory parent nodes in a mesh network can be as follows: Figure 2 As shown, in Figure 2 In the topology, a 3-hop Mesh network is defined, with the node gateway as the root node, node B3 bound to node A1, and nodes C1 and C2 bound to node B3. Then, configuration injection is performed: a command is sent to node B3, forcing it to connect only to the MAC address of node A1; a command is sent to node C2, forcing it to connect only to the MAC address of node B3. Finally, status verification is performed: the network topology is checked to confirm that the parent node configurations of nodes B3 and C2 are effective and the signal strength is stable.

[0055] Please refer to the following. Figure 3 , Figure 3 This diagram illustrates the structure of a test system based on a mesh network with a required parent node, as provided in an embodiment of this specification. It should be noted that... Figure 3 The test system shown, based on a mesh network and requiring a parent node, is used to execute this specification. Figure 1 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figure 1 The example shown.

[0056] like Figure 3 As shown, this test system based on a Mesh network with a required parent node can include at least:

[0057] The acquisition module S302 is used to acquire test requirements and define the topology of the Mesh network based on the test requirements. The topology includes a list of associations between child nodes and target parent nodes.

[0058] The connection module S304 is used to extract the configuration information of each child node and generate configuration instructions based on the configuration information, so that the child node can establish a connection relationship with the target parent node based on the configuration instructions;

[0059] The verification module S306 is used to verify the connection results periodically fed back by the child node, generate a health status level for each link based on the verification results, and generate a corresponding response strategy according to different health status levels.

[0060] The testing module S308 is used to execute corresponding test cases based on the test requirements and record test data;

[0061] The update module S310 is used to receive a test requirement update instruction, determine the change mode based on the update instruction, modify the parent node configuration of the child node based on the change mode, record the change timestamp, and determine the dynamic response capability of the child node.

[0062] In another embodiment, a test system for mandatory parent nodes based on a mesh network further includes:

[0063] A connection module is used to construct the connection relationship, which includes a strict mode or a preferred mode. In the strict mode, the target parent node is the only connection node of the child node, and in the preferred mode, the target parent node is the preferred connection node of the child node.

[0064] In another embodiment, a test system for mandatory parent nodes based on a mesh network further includes:

[0065] The health status levels include healthy, weak link, connection failure, and topology violation;

[0066] The strict mode module is used to send a forced re-association command to the target parent node when the health status level is connection failure and the connection relationship is in strict mode, and to terminate the corresponding test case and mark the disconnection when a permanent failure is detected in the target parent node.

[0067] The preferred mode module is used to send a forced re-association command to the target parent node when the health status level is connection failure and the connection relationship is preferred mode. After failing to connect within a preset number of times, it sends a child node binding release command to allow the child node to fall back to the automatic routing mode.

[0068] Those skilled in the art will clearly understand that the technical solutions of the embodiments in this specification can be implemented by means of software and / or hardware. In this specification, "unit" and "module" refer to software and / or hardware capable of independently performing or cooperating with other components to perform a specific function. The hardware may be, for example, a Field-Programmable Gate Array (FPGA), an Integrated Circuit (IC), etc.

[0069] Each processing unit and / or module in the embodiments of this specification can be implemented by an analog circuit that implements the functions described in the embodiments of this specification, or by software that executes the functions described in the embodiments of this specification.

[0070] See Figure 4 It shows a schematic diagram of the structure of an electronic device according to an embodiment of this specification, which can be used to implement... Figure 1 The method in the illustrated embodiment. (As shown) Figure 4 As shown, the electronic device 400 may include: at least one central processing unit 401, at least one network interface 404, user interface 403, memory 405, and at least one communication bus 402.

[0071] The communication bus 402 is used to enable communication between these components.

[0072] The user interface 403 may include a display screen and a camera. Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0073] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0074] The processor 401 may include one or more processing cores. The processor 401 connects to various parts within the electronic device 400 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 405, and by calling data stored in the memory 405. Optionally, the processor 401 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 401 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip, without being integrated into the processor 401.

[0075] The memory 405 may include random access memory (RAM) or read-only memory. Optionally, the memory 405 may include a non-transitory computer-readable storage medium. The memory 405 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 405 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 405 may also be at least one storage system located remotely from the aforementioned processor 401. Figure 4 As shown, the memory 405, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and program instructions.

[0076] exist Figure 4In the illustrated electronic device 400, the user interface 403 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 401 can be used to call the image-based interactive application stored in the memory 405 and specifically perform the following operations:

[0077] Obtain test requirements, and define the topology of the Mesh network based on the test requirements. The topology includes a list of associations between child nodes and target parent nodes.

[0078] Extract the configuration information of each child node, and generate configuration instructions based on the configuration information, so that the child node can establish a connection with the target parent node based on the configuration instructions;

[0079] The connection results are verified based on the periodic feedback from the child nodes. Based on the verification results, a health status level is generated for each link, and a corresponding response strategy is generated according to different health status levels.

[0080] Execute the corresponding test cases based on the aforementioned test requirements and record the test data;

[0081] Upon receiving a test request update instruction, the change mode is determined based on the update instruction, and the parent node configuration of the child node is modified based on the change mode. The change timestamp is recorded, and the dynamic response capability of the child node is determined.

[0082] As an optional embodiment of this specification, the connection relationship includes a strict mode or a preferred mode, in which the target parent node is the only connection node of the child node, and in the preferred mode, the target parent node is the preferred connection node of the child node.

[0083] As an optional embodiment of this specification, the health status level includes healthy, weak link, connection failure, and topology violation;

[0084] When the health status level is connection failure and the connection relationship is in strict mode, a forced re-association instruction is sent to the target parent node. When a permanent failure is detected in the target parent node, the corresponding test case is terminated and the connection is marked as disconnected.

[0085] When the health status level is connection failure and the connection relationship is the preferred mode, a forced re-association command is sent to the target parent node. If the connection fails within a preset number of attempts, a child node binding release command is issued, allowing the child node to fall back to the automatic routing mode.

[0086] As an optional embodiment of this specification, the method further includes:

[0087] The change mode is adjusted according to the different test scenarios corresponding to the test requirements. The change mode includes either the first association mode or the first disconnect mode.

[0088] As an optional embodiment of this specification, the dynamic response capability includes:

[0089] Performance metrics for switching decisions, network reconnection latency, and service interruption duration.

[0090] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

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

[0092] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0093] In the embodiments provided in this specification, it should be understood that the disclosed system can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between systems or units may be electrical or other forms.

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

[0095] Furthermore, the functional units in the various embodiments of this specification 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0096] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this specification, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 specification. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0097] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0098] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

Claims

1. A test method for a mandatory parent node based on a Mesh network, characterized in that, The method includes: Obtain test requirements, and define the topology of the Mesh network based on the test requirements. The topology includes a list of associations between child nodes and target parent nodes. Extract the configuration information of each child node, and generate configuration instructions based on the configuration information, so that the child node can establish a connection with the target parent node based on the configuration instructions; The connection results are verified based on the periodic feedback from the child nodes. Based on the verification results, a health status level is generated for each link, and a corresponding response strategy is generated according to different health status levels. Execute the corresponding test cases based on the aforementioned test requirements and record the test data; Upon receiving a test request update instruction, the change mode is determined based on the update instruction, and the parent node configuration of the child node is modified based on the change mode. The change timestamp is recorded, and the dynamic response capability of the child node is determined.

2. The testing method for the required parent node based on a Mesh network according to claim 1, characterized in that, The connection relationship includes a strict mode or a preferred mode. In the strict mode, the target parent node is the only connection node of the child node. In the preferred mode, the target parent node is the preferred connection node of the child node.

3. The testing method for the required parent node based on a Mesh network according to claim 2, characterized in that, The health status levels include healthy, weak link, connection failure, and topology violation; When the health status level is connection failure and the connection relationship is in strict mode, a forced re-association instruction is sent to the target parent node. When a permanent failure is detected in the target parent node, the corresponding test case is terminated and the connection is marked as disconnected. When the health status level is connection failure and the connection relationship is the preferred mode, a forced re-association command is sent to the target parent node. If the connection fails within a preset number of attempts, a child node binding release command is issued, allowing the child node to fall back to the automatic routing mode.

4. The testing method for a mandatory parent node based on a Mesh network according to claim 1, characterized in that, The method further includes: The change mode is adjusted according to the different test scenarios corresponding to the test requirements. The change mode includes either the first association mode or the first disconnect mode.

5. The testing method for a mandatory parent node based on a Mesh network according to claim 1, characterized in that, The dynamic response capability includes: Performance metrics for switching decisions, network reconnection latency, and service interruption duration.

6. A testing system based on a Mesh network with a mandatory parent node, characterized in that, The system includes: The acquisition module is used to acquire test requirements and define the topology of the Mesh network based on the test requirements. The topology includes a list of associations between child nodes and target parent nodes. The connection module is used to extract the configuration information of each child node and generate configuration instructions based on the configuration information, so that the child node can establish a connection relationship with the target parent node based on the configuration instructions; The verification module is used to verify the connection results periodically fed back by the child nodes, generate a health status level for each link based on the verification results, and generate a corresponding response strategy according to different health status levels. The testing module is used to execute corresponding test cases based on the test requirements and record test data; The update module is used to receive a test requirement update instruction, determine the change mode based on the update instruction, modify the parent node configuration of the child node based on the change mode, record the change timestamp, and determine the dynamic response capability of the child node.

7. The test system for mandatory parent nodes based on Mesh networks according to claim 6, characterized in that, The system also includes: A connection module is used to construct the connection relationship, which includes a strict mode or a preferred mode. In the strict mode, the target parent node is the only connection node of the child node, and in the preferred mode, the target parent node is the preferred connection node of the child node.

8. The test system for mandatory parent nodes based on Mesh networks according to claim 7, characterized in that, The health status levels include healthy, weak link, connection failure, and topology violation; The strict mode module is used to send a forced re-association command to the target parent node when the health status level is connection failure and the connection relationship is in strict mode, and to terminate the corresponding test case and mark the disconnection when a permanent failure is detected in the target parent node. The preferred mode module is used to send a forced re-association command to the target parent node when the health status level is connection failure and the connection relationship is preferred mode. After failing to connect within a preset number of times, it sends a child node binding release command to allow the child node to fall back to the automatic routing mode.

9. An electronic device, comprising a processor and a memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, in order to perform the method as described in any one of claims 1-5.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-5.

Images