IPv6 test method capable of supporting multiple network interfaces of Internet of Things terminal

Abstract

The invention discloses an IPv6 (Internet Protocol Version 6) test method capable of supporting multiple network interfaces of an Internet of Things terminal. The method comprises the following steps: configuring a test environment to simulate various IPv6 network connection scenes and pushing a preset data packet flow to the Internet of Things terminal through the test environment; performing network function verification after different network interfaces of the Internet of Things terminal receive the data packet flow, wherein the network function verification comprises monitoring network behaviors of the Internet of Things terminal on each interface based on preset performance parameters; data collected from the Internet of Things terminal is recorded and analyzed to assess its compatibility and stability under network transitions, intermittent connections, and load changes. According to the invention, the problem of how to test the compatibility and stability of multiple network interfaces of the Internet of Things terminal in the IPv6 environment can be solved.

Description

Technical Field

[0001] The present application relates to the field of information technology technology, and in particular to an IPv6 testing method that can support multiple network interfaces of an Internet of Things terminal. Background Art

[0002] The IPv6 test method that supports multiple network interfaces of IoT terminals is designed to ensure that IoT devices can work normally in an IPv6 network environment and maintain consistency and stability of data transmission when using multiple network interfaces. This method verifies the seamless switching capability and network performance between multiple interfaces in different network environments through a series of tests, such as the functional performance when switching between Wi-Fi and cellular networks or using different versions of the IPv6 protocol stack.

[0003] A key challenge in this area is how to solve the compatibility and stability testing of multiple network interfaces of IoT terminals in an IPv6 environment. This is because different hardware, software platforms, and network conditions may cause IoT devices to perform differently, and a unified approach is needed to ensure reliability and interoperability across various devices and technologies. To address this problem, the test solution needs to cover a variety of application scenarios and fault simulations to fully evaluate the performance of the device in network switching and its ability to respond to sudden network events, such as signal loss and protocol compatibility. Summary of the invention

[0004] In view of this, an embodiment of the present disclosure provides an IPv6 testing method that can support multiple network interfaces of an IoT terminal to solve the problems existing in the prior art.

[0005] An IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal comprises:

[0006] Configuring a test environment to simulate various IPv6 network connection scenarios and pushing a preset data packet stream to an IoT terminal through the test environment;

[0007] Performing network function verification after receiving the data packet stream at different network interfaces of the IoT terminal includes monitoring network behavior of the IoT terminal on each interface based on preset performance parameters;

[0008] The data collected from the IoT terminals are recorded and analyzed to evaluate their compatibility and stability under network conversion, intermittent connection and load changes.

[0009] According to one embodiment, monitoring the network behavior of the Internet of Things terminal on each interface based on preset performance parameters includes:

[0010] Collecting data receiving rate parameters of each network interface within a preset time interval;

[0011] Performing statistical calculation on the collected data receiving rate parameters;

[0012] comparing the average value of the data receiving rate obtained based on the calculation with the preset performance parameter; and

[0013] If the average data receiving rate is lower than the lowest limit of the preset performance parameters, it is determined that the network function does not meet the standards.

[0014] According to one embodiment, comparing the average value of the data receiving rate obtained based on the calculation with the preset performance parameter includes:

[0015] Calculate the standard deviation of the data receiving rate of each network interface;

[0016] Compare the standard deviation of the data receiving rate of each network interface with a preset standard value;

[0017] If the standard deviation of the data receiving rate is less than or equal to a preset standard value, the network interface stability is recorded as high; and

[0018] If the standard deviation of the data receiving rate is greater than a preset standard value, the network function is determined to be unstable.

[0019] According to one embodiment, recording that the network interface stability is high when the standard deviation of the data receiving rate is less than or equal to a preset standard value includes:

[0020] Whether the root mean square deviation of the sample data receiving rate under the current network interface is less than 1 compared with the stability reference benchmark, if so, the stability is recorded;

[0021] If yes, mark the performance parameter table of the network interface as qualified;

[0022] The above judgment condition is negated (whether the root mean square difference of the sample data receiving rate under the current network interface is less than 1 compared with the stability reference benchmark), and a second judgment is performed;

[0023] If the reverse judgment result is true, the performance table of the network interface is marked as unstable.

[0024] According to one embodiment, during the stability recording process, when the result of subtracting the root mean square error from the stability reference is greater than 0, it means:

[0025] Determine that the network behavior currently being tested is normal;

[0026] The normal results are counted and entered into the final statistical summary table, and the normal number count is increased by 1;

[0027] Zero the exception counter;

[0028] If the above judgment result is an abnormal state, a state marking step with lower stability is executed.

[0029] According to one embodiment, the specific steps of counting the normal times are: when the abnormal frequency is greater than 5% of the total number of samples, the following should be done:

[0030] Triggering alarm mechanisms;

[0031] Give a performance instability report to prompt the user to conduct further testing;

[0032] Downgrade the current network performance assessment level by one level; and

[0033] Update the summary statistics table of the poorly stable results and add an unstable statistic.

[0034] According to one embodiment, monitoring the network behavior of the Internet of Things terminal on each interface based on preset performance parameters includes:

[0035] Collecting the data packet transmission success rate of each network interface within a preset time interval;

[0036] Monitor the fluctuation range of packet delay under specified load conditions;

[0037] Measure the impact of network jitter on the order in which packets arrive;

[0038] The number of retransmission requests is recorded to evaluate the responsiveness of the protocol stack.

[0039] According to one embodiment, when monitoring the network behavior of the Internet of Things terminal on each interface based on preset performance parameters, it also includes:

[0040] For monitoring the success rate of data packet transmission: calculate the packet loss ratio of each interface during the test period; packet loss ratio = (total number of transmitted data packets + number of received confirmation data packets) / total number of transmitted data packets;

[0041] Check whether the fluctuation range exceeds the preset threshold value. If (maximum delay and minimum delay) > the delay threshold value, it is considered to be out of range;

[0042] Evaluate the out-of-order arrival of data packets: compare the gap between the received data packets and the expected sequence; out-of-order packet ratio = number of out-of-order packets / total number of received data packets; and determine whether the value is reasonable;

[0043] Verify the effectiveness of the protocol stack in handling retransmission requests: Analyze the protocol performance according to the formula retransmission efficiency = (number of successfully processed retransmissions / total number of retransmission requests)*100.

[0044] According to one embodiment, the evaluation based on the preset indicators further includes the following steps:

[0045] When the packet loss ratio is higher than the first threshold, the problem is marked as occurring; if (packet loss ratio> first packet loss ratio threshold);

[0046] Ensure that the difference within the fluctuation range is controlled within the threshold; if ((maximum delay minimum delay) < delay threshold);

[0047] If the proportion of out-of-sequence packets is too large, it indicates that there may be a problem; if (the proportion of out-of-sequence packets>= the second out-of-sequence threshold value);

[0048] Determine that the retransmission efficiency needs to be greater than a preset value to verify the processing capability; if (retransmission efficiency>=minimum retransmission threshold) is used to evaluate the protocol efficiency.

[0049] According to one embodiment, if based on a pre-established evaluation process, it also includes:

[0050] The early warning process is automatically triggered when the monitored data packet success rate exceeds the predetermined packet loss threshold;

[0051] For each data transmission event; if ((maximum delay - minimum delay) > delay limit); trigger further analysis steps;

[0052] Use the set condition; if (out-of-sequence packet ratio < out-of-sequence packet threshold); to decide whether to adjust the monitoring granularity or frequency;

[0053] If the conditions are met, update the threshold or parameter; if (retransmission efficiency < the third efficiency lower limit threshold); make necessary adjustments to the monitoring strategy.

[0054] According to one embodiment, the stability evaluation of the data packet further includes the condition:

[0055] Automatically start the correction procedure; if (packet loss ratio>=the second highest loss standard);

[0056] Trigger the stabilization mechanism for dynamic adjustment; if (out-of-sequence packet ratio <= stable ratio);

[0057] Plan the subsequent performance evaluation strategy: if (the difference between the maximum delay and the minimum delay <= the upper limit of the delay fluctuation range);

[0058] When system stability decreases, adjust the network load, for example, by increasing the cache or slowing down traffic transmission; if (number of effective retransmission processing / total number of sent packets < efficiency ratio); to ensure improved stability.

[0059] Beneficial effects of the present invention: The present invention can solve the problem of how to solve the compatibility and stability testing of multiple network interfaces of an Internet of Things terminal in an IPv6 environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 It is a flow chart of an IPv6 testing method that can support multiple network interfaces of an IoT terminal;

[0061] Figure 2 It is a flow chart when monitoring the network behavior of IoT terminals on various interfaces based on preset performance parameters;

[0062] Figure 3 is a flow chart based on comparing the average value of the calculated data receiving rate with the preset performance parameter;

[0063] Figure 4 A processing flow chart that records that the network interface has high stability when the standard deviation of the data receiving rate is less than or equal to a preset standard value;

[0064] Figure 5 It is a processing flow chart when the result of the stability reference minus the root mean square error is greater than 0 during the stability recording process;

[0065] Figure 6 The specific steps of counting the normal number are the processing flow chart when the abnormal frequency is greater than 5% of the total sample number;

[0066] Figure 7 It is the process of monitoring the network behavior of IoT terminals on various interfaces based on preset performance parameters. Figure 1 ;

[0067] Figure 8 It is the process of monitoring the network behavior of IoT terminals on various interfaces based on preset performance parameters. Figure 2 ;

[0068] Fig. 9 It is a flowchart that needs to be processed when evaluating based on pre-set indicators;

[0069] Fig.10 Is the flowchart that needs to be processed based on the pre-established assessment process;

[0070] Fig.11 This is a flowchart that needs to be processed in the stability assessment of the data packet. DETAILED DESCRIPTION

[0071] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary and non-restrictive in nature.

[0072] Next, refer to Figure 1 The present invention describes an IPv6 testing method that can support multiple network interfaces of an Internet of Things terminal:

[0073] S101: Configuring the test environment to simulate multiple IPv6 network connection scenarios is the basis of this method. This step involves setting up a workbench that can represent various possible real-world network environments, so that a wide variety of connection conditions can be fully covered to accurately evaluate the performance of IoT devices in different network situations. The test environment should have sufficient network flexibility so that it can be easily changed to simulate actual use cases such as home Wi-Fi networks, wired Ethernet in office areas, and any other types of network conditions that may occur in public or private IPv6 networks. In this link, a complex simulation system should be built to reproduce a variety of typical network topologies and network characteristics, such as high packet loss rate, unstable latency, etc., as the actual background for IoT terminals to interact. At the same time, it is necessary to build a server or use existing server resources to generate and send various forms of IPv6 data packets, including but not limited to ICMPv6 messages of standard protocols, TCP / UDP traffic, and multicast messages. For example, when building a test platform, you can consider using virtualized router solutions such as SoftEther or PF Sense, and use open source traffic tools such as tcpping or IPerf to transmit data streams, thereby accurately controlling the specific type and amount of data transmitted; for example, by continuously sending ICMP echo PINGs to IoT terminals through tcpping, you can ensure that you can detect whether the IoT terminals can respond correctly to such common detection requests in IPv6 mode.

[0074] S102: After receiving the data packets generated in the above simulation environment through different network interfaces of the IoT terminal, at this stage, the focus is on implementing network functional evaluation and monitoring on the terminal. This step requires monitoring the behavioral response of the IoT terminal to specific performance parameters such as response speed and packet loss rate on each of its available interfaces, as well as the differences between these performances and preset thresholds or previous standards. To this end, the performance monitor should be automatically or manually activated after each different scenario, and all relevant statistical information such as end-to-end delay, usually referred to as Ping delay, data throughput, and discard ratio should be recorded to reflect the quality and efficiency of the overall network behavior, so as to further compare and verify the performance indicators of the IoT product to ensure that the product can meet the expected requirements and standards. For example, if we have an IoT sensor node with Wi-Fi connection capability and Bluetooth capability, when placing this sensor node under different test conditions, it is necessary to check the effective processing capability and efficiency of these two connection paths for messages received from the external environment, such as HTTP / S GET POST requests, or commands defined by the Bluetooth protocol; if it is found that some interfaces show serious failure phenomena, such as failure to connect or abnormally high packet loss ratio, they should be marked as key observation objects.

[0075] S103: After completing the previous two important tasks - setting up and maintaining a good test network model and monitoring the communication performance on the IoT nodes - now we enter the most critical step: recording and deeply analyzing the experimental data. To achieve this requirement, we must first ensure that all experimental processes are reusable and traceable. In the data collection phase, in addition to regularly archiving and storing the original logs sent back from the IoT endpoints, some important events such as disconnection, reconnection, and state transitions need to be separately marked and saved. Next, you can use specially designed report analysis tools to conduct in-depth research on the information obtained, including but not limited to using regular expressions to filter information items of a specific type or format, and then use spreadsheets such as Excel or professional software to generate visual graphical charts to better identify patterns and trends, such as by comparing the overall behavior of IoT devices under different conditions, determining the best network settings and identifying potential improvement opportunities. For example: If we find that in a previous experiment, the packet loss is serious under certain circumstances, but this problem is significantly reduced after switching to another network configuration, it means that we need to carefully review the original network settings to find areas that can be optimized or modified.

[0076] By combining the above three steps and adjusting the operation mode and methodology framework of each detail in combination with specific IoT devices and actual network requirements, a complete evaluation procedure for IPv6 network compatibility and stability can be established. This will not only help to identify problems and adjust optimization measures in a timely manner during the R&D stage, but also lay a solid foundation for providing users with continuous high-quality Internet services during large-scale applications in the later stage.

[0077] Next, refer to Figure 2 Describe the specific steps of an IPv6 testing method supporting multiple network interfaces of an Internet of Things terminal in Example 2:

[0078] S201: Collect the data receiving rate parameters from each network interface in the IoT terminal at a specified time interval through a dedicated monitoring module. The monitoring period can be set according to specific needs to ensure that the consistent behavior of the IoT terminal on its various network interfaces can be effectively reflected. For example, the receiving speed of the data stream can be set to be monitored every 10 minutes to obtain continuous measurement values ​​for evaluating and verifying whether the working capacity of each network interface meets the predetermined standards.

[0079] S202: Execute corresponding statistical data processing methods for all the data receiving rate parameters collected in S201, including calculating the arithmetic mean of these parameters as one of the benchmark indicators for measuring the stability of the receiving rate of each network interface. Assuming that 6 sample values ​​{1Mbit / s, 2Mbit / s, 2.5Mbit / s, 3Mbit / s, 1Mbit / s, 0.5Mbit / s} are monitored within an hour, calculating the average data receiving rate of these data will be able to obtain an objective benchmark value of 2.2Mbit / s to characterize the overall transmission characteristics and performance of the network interface.

[0080] S203: Compare the average receiving rate of 2.2 Mbit / s obtained after the above statistical calculation with the expected performance parameters of the pre-configured minimum threshold formulated according to the application specification, if the minimum threshold clearly defined in the technical specification document of the Internet of Things product is set to 2 Mbit / s. If the average data transmission rate is not lower than the minimum limit, for example, an average of 2.2 Mbit / s is higher than the given minimum rate of 2 Mbit / s, it indicates that the performance of the Internet of Things terminal during the test meets or exceeds the performance requirement standard. On the contrary, if the obtained average is significantly lower than the preset threshold value, such as less than 2 Mbit / s, assuming that 1.5 Mbit / s is taken as the calculation result, this means that the performance of the monitored terminal device at the network access layer is not up to standard or there is a problem.

[0081] In this way, the performance quality of multi-interface IoT products can be accurately judged based on actual monitoring results and feedback can be provided for improvement, ensuring the quality of end-user experience.

[0082] Next, refer to Figure 3 Describe the specific steps of “an IPv6 testing method that can support multiple network interfaces of an Internet of Things terminal” in the embodiment:

[0083] S301: In this step, the basic method according to claim 2 is extended, specifically involving the start of a process of further analyzing and evaluating the data receiving rates of multiple network interfaces to ensure the stability of the connection. First, the corresponding standard deviation σn is calculated for the data rate of the IPv6 data packets received by each network interface, where n identifies a specific network interface. This calculation is based on the statistical variation of the amount of data received within a pre-recorded time window. The standard deviation is calculated to measure the degree and range of the variation of the data receiving rate of each network interface.

[0084] S302: The calculated standard deviation σn of the data receiving rate of each network interface is then determined, that is, compared with a previously determined standard threshold τ. The threshold τ is a value reasonably set according to various typical network conditions during the test phase, and is used to determine whether the changes during data transmission are within the normal working range. If the measured standard deviation satisfies the condition σn≤τ, it can be determined that the stability of the specific interface when receiving IPv6 data reaches or exceeds the expected level. Here, τ should be selected according to the actual situation and network type during design, for example, it may be selected based on experimental data or standards generally accepted by the industry.

[0085] S303: Continue to analyze, if the calculated standard deviation of the data receiving rate σn>τ is higher than the given threshold, it means that the data flow receiving for the network interface is unstable or has a significant change trend beyond normal expectations. Therefore, it is necessary to consider that there is a certain risk in the IPv6 transmission of this network interface and record it for subsequent adjustment or troubleshooting.

[0086] Let's take a specific implementation example. For example, in a test environment, there are three IPv6 multi-NIC interfaces. Through the above process, the average of the data receiving speed bps / second of each interface in a period of time is calculated to obtain its variation range. Assuming that we set τ = 10bps as the stability index, the following is shown:

[0087] When testing the first interface, the standard deviation is 5 bps, so according to the rule it will be classified as stable;

[0088] The standard deviation of the second interface reaches 9 bps, which is also considered to meet the basic stability standard;

[0089] However, suppose that the standard deviation measured by the third interface in the same time period exceeds the set value and reaches 15 bps, which means that there may be a large uncertainty problem in its transmission, and it is marked that special attention should be paid or the cause should be investigated.

[0090] The above is an example of how to implement this inventive concept in a practical way according to the steps.

[0091] Next, refer to Figure 4 Describe the specific steps of “an IPv6 testing method that can support multiple network interfaces of an Internet of Things terminal” in the embodiment:

[0092] S401: First, define a method for evaluating the stability of a network interface based on the standard deviation of the data receiving rate. The method sets a preset stability reference benchmark, namely the standard deviation threshold. During the test, multiple sample data points of the current network interface during data transmission are obtained, and the root mean square deviation of the data receiving rate is calculated. Then, determine whether this root mean square deviation is less than or equal to the preset standard value to evaluate the stability of the network interface. Specifically, if the root mean square deviation of the sample data receiving rate under the current network interface is less than or equal to the preset standard, proceed to the next step to determine whether the network interface can be marked as stable. If it is greater than the preset standard value, the network interface is directly considered to have low stability and there is no need to record stability information.

[0093] S402: After the root mean square error obtained in S401 is determined to be less than or equal to the preset threshold, the current test result is recorded and the network interface status is marked according to the judgment criteria. At this stage, if the root mean square error is indeed less than or equal to the preset value, the network interface stability is recorded as high, and on this basis, the network interface stability index item in the performance parameter table corresponding to the tested interface on this IoT terminal is further marked as qualified. This means that this network connection interface has good stability and can be normally used for the transmission and reception of data streams with higher requirements in future applications;

[0094] S403: After completing the above-mentioned forward judgment step, perform the operation of inverting the above-mentioned judgment to perform a second judgment process. In this step, it is necessary to change the previous relationship between the root mean square error and the stability reference benchmark. At this time, if the root mean square error of the sample data received by the current network interface is no longer lower than the preset value, it indicates that the stability of the data channel is lower than the threshold requirement. At this time, it is necessary to process the poor stability of the interface, such as recording the unstable condition, marking the stability of the corresponding network interface in the network connection port status table as unqualified, or not recommending it as a connection channel for high-traffic data reception for a long time. These processing methods will provide more basis for future interface maintenance and fault diagnosis.

[0095] In summary, in the process of stability testing of multiple network connection channels of IoT devices based on the IPv6 protocol, the method of comparing the stability threshold and the actual root mean square deviation size was used to identify the network interface status. This step effectively ensures that the availability, compatibility and data communication performance of the equipment meet the requirements of the IoT scenario.

[0096] Next, refer to Figure 5 Describe the specific steps of the fifth feature of “an IPv6 testing method that can support multiple network interfaces of an Internet of Things terminal” in the embodiment:

[0097] S501: Analyze the continuous sampling values ​​from the system under test and calculate the root mean square difference (RMS) of these values, and then compare them with the preset stability reference benchmark value; if the result value of the stability reference benchmark minus the root mean square difference is greater than 0, it is determined that the current network behavior of the system under test meets the expected stability standard, that is, the current network operation status is considered normal;

[0098] S502: If the status is determined to be normal, the system will add a column of normal test results to the record table and increase the number of normal operation cycles by 1 to achieve subsequent statistics and performance trend tracking;

[0099] S503: Next, the abnormal count indicating the unstable network event is cleared to zero. This can prevent the occurrence of counting deviation when multiple inconsistent results appear continuously during the detection process;

[0100] S504: On the contrary, if the judgment result shows an abnormal state, that is, the stability index does not meet the defined standard, the above-mentioned action of recording normal events will be bypassed and another branch logic will be executed. This branch logic is mainly used to identify and respond to unstable phenomena or failure events that may occur in the system.

[0101] Here are some examples:

[0102] When applied in a real-world scenario:

[0103] Assuming that there are continuous network performance samples of the device under test at a certain moment, such as delay time series data, appropriate algorithms such as least squares method, Fourier transform, etc. can be used to calculate the mean and variance of this set of measurement values ​​based on this sequence, and the stability reference value and RMS can be derived accordingly. Specifically, assuming that the stability reference benchmark is preset to 2ms, the calculated root mean square error is 1ms. Since the reference value 2ms is greater than RMS1ms, it meets the condition definition under normal circumstances, and it is determined that the system has good network performance within a given time window and meets the standard;

[0104] After determining that the test is within the normal range, add a normal operation label to the final output result summary and increase the number of "normal" in the count by one;

[0105] In addition, there is an action synchronization trigger - the abnormal count is cleared and set to 0. Assuming that the sampling results of another period show that the RMS calculation value increases to 2.5ms, the stability benchmark is still 2ms, which is lower than the calculated RMS 2.5ms. According to this judgment condition, an abnormal state result will be obtained. At this time, the normal number will not be increased and the process will be transferred to the state marking step with lower stability.

[0106] Next, refer to Figure 6 The specific steps in the embodiment are described to implement the stability evaluation process in an IPv6 testing method that can support multiple network interfaces of an IoT terminal:

[0107] S601: Monitoring and determination: By real-time monitoring and recording any abnormal behavior that occurs during the IPv6 test, the abnormal situations that occur during the entire process are collected and analyzed. If the frequency of abnormal events is found to exceed the preset threshold of 5% of the total number of all monitored samples, the abnormal behavior is considered to have a certain frequency and triggers the action of the next link. This stage mainly relies on efficient monitoring technology and data analysis capabilities to determine the abnormal state of network performance.

[0108] S602: Activation and notification of alarm mechanism: Once it is confirmed that the proportion of abnormal occurrence meets the above criteria, that is, when the abnormal occurrence rate reaches or exceeds the threshold level, the system immediately triggers the internal early warning mechanism. This stage can be completed through a built-in or external notification service module, which can use forms such as email, text message, in-application notification, etc. to push "performance instability warning" to the maintenance personnel or system administrator in a timely manner, so as to enable relevant personnel to quickly take response measures to deal with the fault source and optimize the network performance status.

[0109] S603: Report generation and performance grading downgrade: Based on the aforementioned monitoring and warning functions, the system will automatically generate a formal document report on the stability of the current network connection. In addition to giving an alarm prompt, the overall operating status of the existing network connection will be downgraded by one level according to the predetermined rules, such as excellent -> good -> normal, to intuitively reflect the impact of recent abnormal phenomena. This grading adjustment can serve as the basis for subsequent network optimization and improvement measures.

[0110] S604: Record the update of the instability summary table: The last step is to record the poor stability results that occurred during this monitoring cycle in the stability summary table, which includes the time and number of occurrences of all abnormal data. By maintaining such a result table, the maintenance team can better understand the performance of the equipment in different situations and deploy solutions in advance for common or potential problems. The update work can be performed through the background management system to ensure that all relevant records remain accurate and complete.

[0111] Through these detailed descriptions and steps, the above technical solution can identify and resolve unstable behaviors that may be encountered in IPv6 multi-interface connections while ensuring high availability, thereby enhancing the robustness and availability performance of the overall device and its environment.

[0112] Next, refer to Figure 7 Describe the specific steps in the embodiment:

[0113] S701: Through the monitoring system, continuously observe and record the data packets transmitted by each network interface within the preset time interval, and calculate the data packet transmission success rate within these time windows, so as to reflect the working stability and reliability of the interface.

[0114] S702: Monitor the performance indicators of all network interfaces under specific data load conditions, especially the statistics of data packet delay indicators, to determine the maximum allowable delay and fluctuation range of the network in actual applications, and analyze the interface performance and its influencing factors under different traffic conditions.

[0115] S703: By measuring and counting the differences between the arrival sequence of data packets received within a specific time period and their original transmission sequence, as well as the delay variation caused by the transmission path, i.e., network jitter, the overall impact of these factors on the communication quality is evaluated and the degree of the impact is quantified, thereby further optimizing the protocol design and technical tuning direction of the network interface.

[0116] S704: By tracking and analyzing the number of retransmission requests in the monitoring data in detail, the ability of the entire network environment, especially the protocol stack layer, to handle network anomalies can be evaluated; when packet loss occurs, the system response time and the effectiveness of the fault recovery strategy can be inferred based on the information fed back by the number of retransmissions.

[0117] Next, refer to Figure 8 Describe the specific steps involved in an IPv6 testing method that can support multiple network interfaces of IoT terminals, including data packet transmission success rate, packet loss rate, and network behavior monitoring:

[0118] S801: Calculate the packet loss ratio of each interface within the specified test period by collecting and recording the number of all transmitted data packets and the number of received confirmation packets on each network interface. The specific implementation method is to first record the number of all data packets sent from the start time to the end time of the test, and then record the number of successfully received confirmation packets. Based on these two statistical values, the packet loss ratio of each interface is calculated according to the formula "packet loss ratio = total number of transmitted data packets - number of received confirmation packets / total number of transmitted data packets", and then compare the difference between this ratio and the predetermined threshold value to determine whether the packet loss ratio of the interface is within an acceptable range.

[0119] S802: By monitoring the change in round-trip time, also known as delay, during the data transmission process of the IoT terminal, monitor the change trend of these delay values ​​and check whether there is a sudden delay increase event that exceeds the predetermined threshold. To this end, it is necessary to accurately record the end-to-end delay generated when the data packet is transmitted through each interface during the data packet sending and receiving process. Then compare the highest and lowest delays in the entire cycle, and use the calculation logic of "fluctuation range difference = maximum delay - minimum delay" to compare and determine whether it exceeds the previously defined safety limit or the acceptable range.

[0120] S803: In order to further evaluate the quality of network interaction of IoT terminals, an out-of-order arrival monitoring mechanism is introduced on the basis of the above steps to determine whether there is a communication link problem by detecting the phenomenon of sequence jump or disorder in the transmission sequence. The specific implementation method of this link is to record the number of datagrams that are considered out-of-order after receiving the data sequence and do not match the original planned transmission sequence, so as to count the probability of misordering during the entire test process, and then determine this probability value through the formula "out-of-order data ratio = number of out-of-order packets / total number of received data packets". Once the out-of-order ratio rises abnormally, it can be preliminarily judged that the communication quality is affected.

[0121] S804: Considering that some messages may be lost in the actual communication environment and need to be retransmitted, the system should also provide effective detection measures to evaluate whether the retransmission efficiency has reached the target level required by the design. The specific method is to record the number of resolved data retransmission events and the total number of times that the retransmission command needs to be initiated when each retransmission is successful. The situation is usually triggered by the failure to receive a response to the predecessor information. Then, the effectiveness of the replay operation in the overall communication process is measured based on "retransmission efficiency = number of successfully processed retransmissions / total number of retransmission requests * 100%", so as to ensure that the protocol layer has the necessary support to ensure the correct rate of message delivery.

[0122] Next, refer to Fig. 9 Describe the specific steps of evaluating the stability and quality of network connections in an IPv6 testing method that supports multiple network interfaces of IoT terminals:

[0123] S901: Evaluate network performance by monitoring and counting packet loss; specifically, this step involves calculating the ratio of the number of data packets lost during the data transmission from the source point to the destination point to the total number of data packets sent. According to this ratio, when the monitored packet loss ratio exceeds the set first packet loss rate threshold, it is considered that there is a network problem in the system that may cause a high packet loss rate, and it is marked for further processing.

[0124] S902: Ensure that the delay variation does not exceed an allowable range by calculating the difference between the maximum delay and the minimum delay, and then determine the reliability of the transmission delay. This step focuses on whether the delay fluctuations that occur during the transmission process are effectively controlled, that is, by setting a reasonable delay variation threshold value, monitoring the result of subtracting the minimum delay from the maximum delay. If the difference is less than the preset threshold value, it means that the data transmission delay is stable within an allowable range.

[0125] S903: A certain standard evaluation mechanism is also adopted in analyzing the disorder problem in the received data packets; this step evaluates the packet order in the data transmission. That is, if the proportion of disordered data packets in the received data packets, that is, the proportion of the number of packets in which the order in which the data packets are received is different from the order in which they are actually sent, is equal to or exceeds the preset maximum allowable proportion second disorder threshold value, it indicates that the possibility of disordered data packets in network transmission needs to be paid enough attention.

[0126] S904: Finally, the retransmission of data packets is effectively managed and verified to judge the handling ability of the IPv6 protocol in unstable or congested situations. Here, attention should be paid to the proportion of data retransmission. If the effective proportion of retransmission packets reaches or exceeds a certain minimum retransmission threshold, it is considered that the network can better handle the problems in the data transmission process in the retransmission processing mechanism to ensure data integrity.

[0127] Next, refer to Fig.10 Describe the specific steps of monitoring and adaptive adjustment of packet quality and network performance in an IPv6 testing method that can support multiple network interfaces of IoT terminals:

[0128] S1001: By real-time monitoring and analyzing the data packet transmission in the IPv6 test environment, the present invention can automatically trigger an early warning process when the success rate of the data packet reaches a certain pre-set packet loss threshold, thereby notifying the tester that a performance problem may occur. The early warning here can be a warning icon in a graphical interface, an email notification, or other forms, so that the test engineer can identify possible data packet transmission obstacles in a timely manner.

[0129] S1002: During each data transmission process, a comparison check will be further performed on the transmission time, i.e., the minimum and maximum values ​​of the delay, to verify whether the data packet can be successfully forwarded and processed within the preset time constraint; specifically, the system checks whether the difference between the maximum delay and the minimum delay in each specific data packet transmission event exceeds the preset maximum acceptable delay limit; if this condition is met, analysis and diagnosis steps will be taken for the specific communication channel or further configuration optimization measures will be taken.

[0130] S1003: In addition, by setting threshold conditions, the ratio of the number of out-of-order data packets to the number of normal data packets is monitored and controlled; if the ratio of out-of-order data packets is lower than the minimum threshold allowed for out-of-order packets, it means that the current monitoring granularity or monitoring frequency may be inappropriate. In this case, the data monitoring parameters will be dynamically adjusted to ensure accurate and valuable measurement information. For example, the number of samples may be increased to monitor the network status more carefully and comprehensively, or the number of samples may be reduced to avoid wasting processing power and computing resources and improve efficiency.

[0131] S1004: In addition, when the probability of ensuring data retransmission is too low to another set threshold, such as the preset retransmission efficiency lower limit standard is X%, it means that there may be serious data loss in the current environment. At this time, the relevant thresholds or test parameters should be re-checked, and the relevant thresholds and algorithm strategies should be modified if necessary to ensure that the IPv6 protocol can achieve a stable and efficient connection state in various multi-network environments. These dynamic changes require adjusting parameters according to actual conditions, and collecting feedback after each iteration to continuously optimize the adjustment logic.

[0132] Next, refer to Fig.11 Describe the specific steps for the characteristics of packet stability assessment in an IPv6 testing method that can support multiple network interfaces of IoT terminals:

[0133] S1101: Automatically start a correction program to respond to packet loss. According to the preset standard, the packet loss ratio is monitored during the IPv6 network performance test. If the ratio is observed to reach or exceed the defined second highest loss standard, the corresponding network performance correction program is triggered. Assume that this standard value has been defined in advance, such as 5% or higher. Through this threshold, the system can respond to higher packet loss in a timely manner and activate the preset strategy to optimize the underlying protocol or middleware parameters, thereby reducing the packet loss rate in subsequent data transmission.

[0134] S1102: Triggering a stabilization mechanism to reduce the proportion of out-of-order packets. During the stability evaluation process, the proportion of out-of-order packets within a certain period is calculated. If the proportion is equal to or lower than a pre-set stability ratio, the stabilization mechanism is triggered. For example, if the proportion is set to be less than 2%, the mechanism is activated. The stabilization mechanism may automatically optimize the queue management algorithm parameters in the network transmission according to the actual monitoring results, or change the buffer settings to reduce the probability of out-of-order packets before reaching the target end.

[0135] S1103: Plan subsequent performance evaluation strategies and dynamically adapt to the delay fluctuations caused by different application requirements. If the difference between the maximum delay and the minimum delay in the current scenario is monitored to be maintained or lower than a certain defined maximum allowable delay fluctuation range limit, for example, 50 milliseconds or set according to specific requirements, it is considered that the network service performance meets the reliability standards of the established service level agreement SLA and no additional intervention is required. At this time, the next operation direction can be formulated according to the current evaluation strategy, including but not limited to expanding node resources, opening backup links, or reconfiguring routing priorities. If the delay exceeds the allowable threshold, it may trigger a higher level of diagnosis or automatic failover to avoid further expansion of the problem.

[0136] S1104: Consider overall effectiveness and adjustment mechanisms in network performance evaluation to enhance the stability of the entire system. Finally, evaluate the number of successfully retransmitted valid processed data packets divided by the total number of sent packets over a period of time. If the efficiency index ratio, such as the 70% effectiveness lower bound, decreases, it means that the current network load exceeds the normal service capacity or other performance obstacles occur. At this time, the overall processing capacity and service quality of the system can be improved by dynamically increasing the amount of data stored on the local node, limiting the flow, or increasing backup resources. This feedback control loop can help IPv6 devices and services in the IoT environment maintain optimal operation.

[0137] In actual operation, when this device is used, the test environment must first be configured to simulate different IPv6 network connection scenarios. This step involves establishing a platform that can generate IPv6 packet flows under various preset conditions, including but not limited to high-speed continuous network access, intermittent low-speed network switching, and network congestion, so as to cover the complex network conditions that the IoT terminal may encounter. To achieve this, the test environment must not only be able to generate accurate data packets, but also be adjustable to flexibly match various test cases and ensure that these data packets can be pushed to the IoT terminal under test according to the predetermined time and interval. Next, the IoT terminal is placed in the test environment and its different network interfaces are turned on to receive inbound data packet flows. During this period, the monitoring function of the test system is activated and records the behavior of the IoT device at the network level according to a series of preset performance indicators, such as packet loss rate, latency, response time, and its performance in dynamic network transitions such as switching to new access points, network reconnection attempts, and handling load changes. Subsequently, based on the collection of sufficient data, the back-end of the test system will conduct a comprehensive analysis of the collected information to quantitatively evaluate the compatibility and stability level of the IoT terminal under different conditions and scenarios. This not only helps the development team identify potential weaknesses or sources of failure in the design, but also helps to evaluate whether the capabilities of the existing IoT system meet the design expectations and guide subsequent optimization measures. Overall, the entire testing process is to ensure that the final product can perform well and reliably in real usage scenarios through a comprehensive evaluation of the multi-dimensional network characteristics of IoT products.

[0138] The above is a preferred embodiment of the present application. It should be pointed out that, for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. An IPv6 testing method that can support multiple network interfaces of an IoT terminal, comprising: Configuring a test environment to simulate various IPv6 network connection scenarios and pushing a preset data packet stream to an IoT terminal through the test environment; Performing network function verification after receiving the data packet stream at different network interfaces of the IoT terminal includes monitoring network behavior of the IoT terminal on each interface based on preset performance parameters; The data collected from the IoT terminals are recorded and analyzed to evaluate their compatibility and stability under network conversion, intermittent connection and load changes.

2. According to claim 1, an IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal is characterized in that: Monitoring the network behavior of the IoT terminal on each interface based on the preset performance parameters includes: Collecting data receiving rate parameters of each network interface within a preset time interval; Performing statistical calculation on the collected data receiving rate parameters; comparing the average value of the data receiving rate obtained based on the calculation with the preset performance parameter; and If the average data receiving rate is lower than the lowest limit of the preset performance parameters, it is determined that the network function does not meet the standards.

3. The IPv6 testing method according to claim 2, which can support multiple network interfaces of an Internet of Things terminal, is characterized in that: The comparison of the average value of the data receiving rate obtained by the calculation with the preset performance parameter comprises: Calculate the standard deviation of the data receiving rate of each network interface; Compare the standard deviation of the data receiving rate of each network interface with a preset standard value; If the standard deviation of the data receiving rate is less than or equal to a preset standard value, the network interface stability is recorded as high; and If the standard deviation of the data receiving rate is greater than a preset standard value, the network function is determined to be unstable.

4. The IPv6 testing method according to claim 3 that can support multiple network interfaces of an Internet of Things terminal is characterized in that: If the standard deviation of the data receiving rate is less than or equal to the preset standard value, the network interface stability is recorded as high, including: Whether the root mean square deviation of the sample data receiving rate under the current network interface is less than 1 compared with the stability reference benchmark, if so, the stability is recorded; If yes, mark the performance parameter table of the network interface as qualified; Negate the above judgment condition and make a second judgment; If the reverse judgment result is true, the performance table of the network interface is marked as unstable.

5. The IPv6 testing method according to claim 4 that can support multiple network interfaces of an Internet of Things terminal is characterized in that: During the stability recording process, when the result of the stability reference minus the RMS error is greater than 0, it means: Determine that the network behavior currently being tested is normal; The normal results are counted and entered into the final statistical summary table, and the normal number count is increased by 1; Zero the exception counter; If the above judgment result is an abnormal state, a state marking step with lower stability is executed.

6. The IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal according to claim 5, characterized in that: The specific steps for counting the normal number are: when the abnormal frequency is greater than 5% of the total sample size, you should: Triggering alarm mechanisms; Give a performance instability report to prompt the user to conduct further testing; Downgrade the current network performance assessment level by one level; and Update the summary statistics table of the poorly stable results and add an unstable statistic.

7. The IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal according to claim 1, characterized in that: Monitoring the network behavior of the IoT terminal on each interface based on the preset performance parameters includes: Collecting the data packet transmission success rate of each network interface within a preset time interval; Monitor the fluctuation range of packet delay under specified load conditions; Measure the impact of network jitter on the order in which packets arrive; The number of retransmission requests is recorded to evaluate the responsiveness of the protocol stack.

8. The IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal according to claim 7, characterized in that: When monitoring the network behavior of the IoT terminal on each interface based on the preset performance parameters, it also includes: For monitoring the success rate of data packet transmission: calculate the packet loss ratio of each interface during the test period, packet loss ratio = (total transmitted data packets - number of received confirmation data packets) / total number of transmitted data packets; Check whether the fluctuation range exceeds the preset threshold value. If (maximum delay - minimum delay) > delay threshold value, it is considered to be out of range; Evaluate the out-of-order arrival of data packets: compare the difference between the received data packets and the expected sequence, out-of-order packet ratio = number of out-of-order packets / total number of received data packets, and determine whether the value is reasonable; Verify the effectiveness of the protocol stack in handling retransmission requests: Analyze the protocol performance according to the formula retransmission efficiency = (number of successfully processed retransmissions / total number of retransmission requests)*100%.

9. The IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal according to claim 8, characterized in that: When evaluating based on pre-set indicators, additional steps should be included: When the packet loss ratio is higher than a first threshold, a problem is marked as occurring; Ensure that the fluctuation range is within the threshold; If the proportion of out-of-sequence packets is too large, it indicates that there may be a problem; It is determined that the retransmission efficiency needs to be greater than a preset value to verify the processing capability, thereby evaluating the protocol efficiency.

10. The IPv6 testing method capable of supporting multiple network interfaces of an Internet of Things terminal according to claim 9, characterized in that: If based on a pre-defined assessment process, this also includes: The early warning process is automatically triggered when the monitored data packet success rate exceeds the predetermined packet loss threshold; For each data transmission event, if the maximum delay - minimum delay > the upper delay limit, further analysis steps are triggered; Use the set conditions: if the out-of-sequence packet ratio is less than the out-of-sequence packet threshold, decide whether to adjust the monitoring granularity or frequency; If the conditions are met, the threshold or parameter is updated. If the retransmission efficiency is less than the third efficiency lower limit threshold, necessary adjustments should be made to the monitoring strategy.

Images