A method for managing and controlling wireless communication of an internet of things device

Abstract

The application relates to the technical field of Internet of Things device control, and discloses a wireless communication management and control method for Internet of Things devices. The application obtains control propagation link data corresponding to a target Internet of Things device, constructs a current control semantic anchor point, further reconstructs an event validity time interval of a control related event based on multi-time record and propagation constraint data, determines the validity of the control semantic based on the current control semantic effective window and device execution read-back data, outputs a state write-back permission result, finally executes global control state write-back control and device state review of the target Internet of Things device on the platform side according to the state write-back permission result, so that the normal late but still valid control related events and the late-arriving and invalid historical control related events can be effectively distinguished in the scenario where multi-gateway roaming, edge cache backlog, message resending and retransmission coexist.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) device control technology, and in particular to a method for wireless communication management and control of IoT devices. Background Technology

[0002] With the increasing prevalence of mobile IoT devices in scenarios such as warehousing and logistics, smart manufacturing, smart healthcare, park inspection, and asset transfer, remote access, status monitoring, and control command issuance via wireless networks have become crucial technologies for ensuring efficient on-site collaborative operations. Taking automated guided vehicles (AGVs), delivery carts, inspection robots, mobile medical terminals, pallet tags, and high-value asset identification devices as examples, these devices typically move continuously in multi-workshop, multi-floor, multi-zone, or multi-channel environments. During operation, they often need to frequently switch between multiple gateway coverage areas and communicate with the central platform through edge nodes. In practical applications, the on-site environment commonly presents complex factors such as metal shelving obstructions, enhanced aisle reflections, localized network congestion, edge link load fluctuations, changes in equipment speed, temporary stops, and sudden turns. Differences also exist between different gateways and edge nodes in maintaining access to the same device, data caching, retransmission processing, and backhaul latency. This results in significant asynchrony and dispersion in the propagation of control commands, execution readbacks, confirmation messages, and retransmission data across nodes. Therefore, the device communication records received by the platform are often not strictly corresponding to the actual sequence of field control actions, but rather the result of arrival after being affected by multiple path forwarding, queue backlog, and backhaul jitter.

[0003] For the aforementioned application scenarios, existing technologies typically employ methods such as message deduplication, timestamp comparison, session number matching, last-write priority, and idempotency verification to maintain and update the device control state. Some solutions also incorporate gateway switching flags, device online status, and message retry counts to assist in identifying abnormal communication processes. While these solutions can meet basic usage requirements in stable environments with a single gateway, low latency, and low cache backlog, they still struggle to accurately identify the true effective chain of a control event in scenarios involving multi-gateway roaming, edge collaborative forwarding, and high device mobility. On one hand, acknowledgment information cached by the old gateway, delayed execution results, and historical messages resent locally by the device may arrive at the platform only after the device has connected to the new gateway, causing the platform to mistakenly classify semantically invalid historical records as currently valid. On the other hand, relying solely on message arrival order, local time records, or static session identifiers makes it difficult to recover the causal relationship of control propagation between the device, gateway, edge node, and platform, leading to problems such as old policies overriding new policies, historical states contaminating the current state, repeated execution of control actions, and inconsistencies between platform perception and the actual situation. Especially in scenarios such as logistics scheduling, medical transportation, and production line collaboration, the above problems may further lead to task mismatch, path conflict, misconfiguration of control thresholds, and accidental shutdown and start-up of equipment. Therefore, there is an urgent need for a wireless communication management and control method for IoT devices that can reconstruct the effective chain of control events for cross-gateway propagation processes. Summary of the Invention

[0004] This application proposes a method for wireless communication control of Internet of Things (IoT) devices to address the problems mentioned in the background art.

[0005] To achieve the above objectives, this application adopts the following technical solution: a wireless communication control method for Internet of Things (IoT) devices, comprising the following steps:

[0006] S1. Obtain the control propagation link data corresponding to the target IoT device. The control propagation link data includes at least multiple time records, propagation constraint data, and device execution readback data. The multiple time records include control issuance records and gateway access switching records. Construct the current control semantic anchor point based on the control issuance records and gateway access switching records. The current control semantic anchor point includes at least the current access gateway identifier, the current control sequence number, the control effective start time, and the control target digest code.

[0007] S2. For subsequent control-related events arriving at the platform, based on multi-time recording and propagation constraint data, the gateway-side event recording time carried in the control-related events is mapped to the platform's unified time base and combined with the platform-side reception time of the control-related events to form a backward time interval, thereby reconstructing the time interval for the corresponding control-related events to be valid.

[0008] S3. Construct the current control semantic effective window based on the current control semantic anchor point and propagation constraint data, cross-determine the time interval of the event that can be established with the current control semantic effective window, and check the control semantic consistency between the control-related events and the current control semantic anchor point in combination with the device execution readback data, and output the status write-back permission result.

[0009] S4. Based on the state write-back permission result, execute the global control state write-back control of the target IoT device on the platform side. When the state write-back permission result indicates that write-back is allowed, update the global control state. When the state write-back permission result indicates that write-back is prohibited, block the write-back of the corresponding control-related events and trigger the device state review. When the device state review result is inconsistent with the current control semantic anchor point, generate a correction control event and enter the current control semantic anchor point construction process of the next control cycle.

[0010] Furthermore, in S1, the current control semantic anchor point is constructed based on the control issuance record and the gateway access switching record. This includes: extracting the current control sequence number and the control effective start time from the control issuance record, extracting the current access gateway identifier from the gateway access switching record, performing digest processing on the control target parameters in the control issuance record to obtain the control target digest code, and then generating the current control semantic anchor point corresponding to the target IoT device based on the current access gateway identifier, the current control sequence number, the control effective start time, and the control target digest code.

[0011] Furthermore, in S1, the device executes readback data including at least the executed control sequence number, the executed control target digest code, and the execution status identifier. The execution status identifier is used to characterize the execution status of the target IoT device on the control content corresponding to the control issuance record.

[0012] Furthermore, in S2, the time interval for the corresponding control-related events to be valid is reconstructed, including: mapping the gateway-side event record time carried in the control-related events to the unified time base of the platform to form a gateway mapping time interval, then forming a backtracking time interval based on the platform-side receiving time of the control-related events, and finding the intersection of the gateway mapping time interval and the backtracking time interval to obtain the time interval for the corresponding control-related events to be valid.

[0013] Furthermore, in S2, the propagation constraint data includes at least the time offset, time offset uncertainty, historical baseline propagation delay, propagation delay discrete representation, queue occupancy representation, and retransmission representation.

[0014] The gateway mapping time interval is formed based on the time offset and time offset uncertainty, while the backtracking time interval is formed based on the platform side reception time and combined with the historical baseline propagation delay, propagation delay discrete representation, queue occupancy representation, and retransmission representation. When the gateway mapping time interval and the backtracking time interval do not overlap, the corresponding control-related events are marked as invalid events.

[0015] Furthermore, in S3, the effective window of the current control semantics is constructed based on the current control semantic anchor point and propagation constraint data, including: taking the control effective start time in the current control semantic anchor point as the starting boundary of the effective window of the current control semantics, and combining the propagation constraint data to determine the duration of the effective window of the current control semantics;

[0016] When the current control semantic anchor point of the next control cycle is formed, the termination boundary of the current control semantic effective window of the previous control cycle is converged based on the start time of control effectiveness of the next control cycle.

[0017] Furthermore, in S3, the event's valid time interval is cross-determined with the current control semantic effective window, including: determining whether the event's valid time interval and the current control semantic effective window overlap; if there is an overlap, the corresponding control-related event is identified as a candidate event that meets the time validity condition; if there is no overlap, the write-back permission result of the corresponding control-related event is determined as write-back prohibited.

[0018] Furthermore, in S3, the consistency of control semantics between control-related events and the current control semantic anchor is checked by combining the device execution readback data, including: extracting the control sequence number corresponding to the control-related event and comparing it with the current control sequence number in the current control semantic anchor, and / or extracting the control target digest code corresponding to the control-related event and comparing it with the control target digest code in the current control semantic anchor;

[0019] Extract the executed control sequence number from the device execution readback data and verify its consistency with the current control sequence number in the current control semantic anchor point; and / or extract the executed control target digest code from the device execution readback data and verify its consistency with the control target digest code in the current control semantic anchor point, and verify it in conjunction with the execution status identifier.

[0020] If the control sequence number corresponding to the control-related event matches the current control sequence number in the current control semantic anchor, or the control target digest code corresponding to the control-related event matches the control target digest code in the current control semantic anchor, and the executed control sequence number in the device's readback data matches the current control sequence number in the current control semantic anchor, or the executed control target digest code in the device's readback data matches the control target digest code in the current control semantic anchor, and the execution status identifier indicates that the corresponding control content has been executed, then the write-back permission result of the corresponding control-related event will be determined as write-back allowed; otherwise, it will be determined as write-back prohibited.

[0021] Furthermore, in S4, when the state write-back permission result indicates that write-back is allowed, the global control state is updated, including: writing the current access gateway identifier, current control sequence number, control effective start time and control target digest code from the current control semantic anchor into the global control state of the target IoT device on the platform side, and generating a write-back confirmation flag associated with the corresponding control-related event.

[0022] Furthermore, in S4, when the write-back permission result indicates that write-back is prohibited, the write-back of the corresponding control-related event is blocked and the device status review is triggered. This includes: initiating a status query to the target IoT device through the current access gateway, obtaining the execution control sequence number, execution control target digest code, and execution status identifier obtained from the device status review, comparing the execution control sequence number with the current control sequence number in the current control semantic anchor, comparing the execution control target digest code with the control target digest code in the current control semantic anchor, and determining the device status review result based on the execution status identifier.

[0023] When the execution control sequence number is inconsistent with the current control sequence number, or the execution control target digest code is inconsistent with the control target digest code, or the execution status identifier indicates that the corresponding control content is not executed according to the current control semantic anchor point, it is determined that the equipment status verification result is inconsistent with the current control semantic anchor point, and a correction control event is generated. Based on the correction control event, the current control semantic anchor point construction process of the next control cycle is initiated.

[0024] The beneficial effects of this invention are as follows:

[0025] This invention acquires control propagation link data corresponding to the target IoT device, constructs the current control semantic anchor point, and further reconstructs the valid time interval of control-related events based on multi-time records and propagation constraint data. Based on this, it combines the current control semantic validity window and device execution readback data to determine the validity of the control semantic, outputs the state write-back permission result, and finally executes global control state write-back control and device state verification for the target IoT device on the platform side according to the state write-back permission result. This effectively distinguishes between normal, delayed but still valid control-related events and delayed and invalid historical control-related events in scenarios involving multi-gateway roaming, edge cache backlog, and coexistence of message retransmission and retransmission, preventing historical control semantics from contaminating the global control state of the current control cycle. Simultaneously, when write-back is prohibited, the consistency between the global control state of the target IoT device on the platform side and the actual execution state of the device is maintained through device state verification and control event generation correction mechanisms. Therefore, it improves the accuracy and stability of control state confirmation in wireless communication scenarios, and enhances the platform's state correction capability and control semantic continuity in abnormal propagation scenarios. Attached Figure Description

[0026] 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 only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort:

[0027] Figure 1 This is a flowchart of the method of the present invention;

[0028] Figure 2 This is a schematic diagram of the S3 process of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] like Figure 1 and Figure 2 As shown, this invention discloses a method for controlling wireless communication in Internet of Things (IoT) devices, comprising the following specific steps:

[0031] In one implementation, S1 is used to obtain the control propagation link data corresponding to the target IoT device, and to construct the current control semantic anchor point based on this data. This step does not directly use the platform's received results as the semantic basis for the current control cycle, but constructs the current control semantic anchor point based on the control issuance record and gateway access switching record, so that the control semantics within the current control cycle are jointly determined by the access location, control sequence number, effective start point, and control content, thereby providing a unified reference for late event identification and status write-back control in subsequent steps.

[0032] Specifically, firstly, the control propagation link data corresponding to the target IoT device within the current control cycle is acquired. This control propagation link data includes at least multiple time records, propagation constraint data, and device execution readback data. The multiple time records include at least control issuance records and gateway access switching records, as well as time records corresponding to control-related events. The control issuance records include at least the current control sequence number, control issuance time, control activation start time, and control target parameters. The gateway access switching records include at least the gateway identifier before switching, the current access gateway identifier, and the gateway switching activation time. The time records corresponding to control-related events include at least the gateway-side event recording time and the platform-side reception time. The device execution readback data includes at least the executed control sequence number. The system includes an executed control target digest code and an execution status identifier. The execution status identifier characterizes the execution status of the target IoT device in response to the control content corresponding to the control issuance record. Preferably, the execution status identifier is represented by discrete status values, specifically one of not executed, executing, completed, and failed. When the target IoT device only supports simplified receipts, it can also be represented by two status values: completed and not completed. The above data acquisition methods can be implemented using existing methods such as platform-side log collection, gateway-side event log collection, and device-side execution receipt collection. This part is a data collection support means used to improve the solution, and its role is to provide input for subsequent innovative processing. It is not the focus of this implementation method.

[0033] After acquiring the control propagation link data, the core processing in this step is to construct the current control semantic anchor point. To avoid misidentification of control semantics in scenarios such as control retransmission, control correction, parameter format differences, or gateway switching, this implementation does not directly use the original control target parameters to participate in subsequent control semantic consistency verification. Instead, it first unifies the control target parameters in the control transmission record and then generates the control target digest code. The reason for this is that the original control target parameters are usually composed of multiple fields, and the order of different fields, units of measurement, encoding methods of enumerated values, and precision expressions of continuous quantities may differ. If unification is not performed first, even if the control content is substantially the same, different digest results may be obtained due to different parameter representations, thus affecting the stability of the current control semantic anchor point. Conversely, by first converting the control target parameters into a unified expression form and then generating the control target digest code, the control content can maintain consistent semantic identification under different transmission links and different message encapsulation methods, thereby improving the accuracy of subsequent control semantic consistency verification.

[0034] In practical implementation, it is preferable to first perform normalization processing on the control target parameters. Normalization processing should include at least the following: rearranging the parameter fields in the control target parameters according to a preset field order; converting dimensional control parameters to a unified unit of measurement; converting enumerated control parameters to unified code values; and quantifying continuous control parameters according to the minimum execution resolution of the target IoT device. For example, taking target power, target opening degree, and duration as examples, the target power can be uniformly converted to watts, the target opening degree to a percentage, and the duration to seconds. Then, these can be organized into a summary input content according to a fixed field order. For dimensional control parameters... Control parameters are only allowed to participate in subsequent quantization processing after unit conversion is completed; and only control parameters that have undergone quantization are allowed to participate in the generation of control target digest codes. The reason for this setting is that parameter values ​​before unit conversion still retain the original units of measurement and cannot be directly used for stable comparisons; only parameter values ​​after quantization are consistent with the execution precision of the target IoT device and can truly reflect the control content that the device can execute. If unit conversion is skipped and quantization is carried out directly, or if digest codes are generated directly without quantization, the control target digest code will be overly sensitive to the parameter representation, thereby reducing the uniqueness and stability of the current control semantic anchor point.

[0035] The quantization accuracy of continuous control parameters is preferably consistent with the minimum execution resolution of the target IoT device. The minimum execution resolution of the target IoT device can be determined by the device control interface specification, device parameter table, or historical control feedback accuracy. When the device control quantity only supports integer-level adjustment, it is preferable not to retain decimal places; when the device control quantity supports 0.1-level adjustment, it is preferable to retain one decimal place; when the device control quantity supports 0.01-level adjustment, it is preferable to retain two decimal places; and when the device control quantity supports 0.001-level adjustment, it is preferable to retain three decimal places. The above values ​​are based on the following: if the quantization accuracy is lower than the minimum execution resolution of the target IoT device, fundamentally different control content will be compressed into the same control target digest code; if the quantization accuracy is significantly higher than the minimum execution resolution of the target IoT device, the device will mistakenly identify minute numerical differences in execution as different control content, which is also detrimental to the current... After the stable construction and normalization of the pre-control semantic anchor points, the digest input content is processed to obtain the control target digest code. It is preferred to use existing digest algorithms to generate the control target digest code, such as using hash digest to obtain a fixed-length encoding result. The digest code length is preferably 64 to 128 bits, more preferably 64 bits. When the number of target IoT devices connected to a single platform exceeds 1,000,000 and the number of control target parameter fields is large, it is preferred to use a 96-bit or 128-bit control target digest code. The basis for this length range is that a 64-bit control target digest code can already balance the probability of digest collision and storage cost in most industrial IoT, warehousing and logistics IoT and park equipment control scenarios. As the scale of devices and the number of control content combinations further increase, increasing the length of the control target digest code helps to reduce the risk of different control contents being mistakenly merged.

[0036] After generating the control target digest code, the current control semantic anchor point is further constructed based on the control issuance record and gateway access switching record. Specifically, the current control sequence number and control effective start time are extracted from the control issuance record, and the current access gateway identifier is extracted from the gateway access switching record. These are then combined with the aforementioned control target digest code to form the current control semantic anchor point corresponding to the target IoT device. The current control semantic anchor point includes at least the current access gateway identifier, the current control sequence number, the control effective start time, and the control target digest code. These four items are used to characterize the access location, control identity, time start point, and control content of the current control cycle, respectively. Only by retaining all four items can the current control be effectively controlled. To fully characterize the semantics, if only the current control sequence number is retained, confusion between different control contents can easily occur in control retransmission or sequence number rollback scenarios. If only the control target digest code is retained, it is difficult to distinguish between previous and subsequent cycles when the same control content is repeatedly sent within a continuous control cycle. If the current access gateway identifier is not retained, it is impossible to distinguish the control propagation link semantics before and after the gateway switch. If the control effective start time is not retained, it is difficult to construct the current control semantic effective window corresponding to the current control cycle in subsequent steps. Therefore, this implementation combines the above four items as the components of the current control semantic anchor point to represent the unique effective control semantics recognized by the platform within the current control cycle.

[0037] It should be noted that the construction of the current control semantic anchor point is based solely on the control issuance record and gateway access switching record, and is not based on device execution readback data. The reason for this design is that device execution readback data is usually generated after control issuance. If device execution readback data is used as the condition for constructing the current control semantic anchor point, the generation time of the current control semantic anchor point will lag behind the start time of control effectiveness, thereby weakening the role of the current control semantic anchor point as a unified reference for subsequent steps. After the device execution readback data is acquired and its fields are organized in S1, it is retained in S3 to participate in the control semantic consistency verification. Thus, the construction of the current control semantic anchor point in S1 and the control semantic consistency verification in S3 maintain a clear division of labor in terms of time sequence, avoiding the logical conflict of post-execution data inversely determining the pre-execution benchmark.

[0038] To support the subsequent mapping of gateway-side event recording times to the platform's unified time base in S2, this step also obtains time synchronization-related content from the propagation constraint data. This content is used to improve the subsequent time interval reconstruction process. Preferably, the existing bidirectional time synchronization method is used to obtain the gateway's time offset and time offset uncertainty relative to the platform's unified time base. Specifically, this can be achieved by periodically exchanging time synchronization messages between the gateway and the platform, calculating the gateway clock's time offset relative to the platform's unified time base based on the request sending time, the platform response time, and the gateway receiving the response time. Then, the time offset uncertainty is determined based on the offset fluctuations over multiple consecutive time synchronization periods. The time period is preferably 0.5s to 30s, more preferably 1s to 5s. The reason for this choice is that an excessively long time period will increase the accumulation of clock drift, which is not conducive to the time mapping of subsequent late events; an excessively short time period will increase the communication and processing burden on the gateway side. The time offset uncertainty is preferably no more than 20% of the duration of a single control cycle, more preferably no more than 50ms, so as to ensure that the reconstruction of the time interval for subsequent events has sufficient time resolution. It should be emphasized that the time offset and time offset uncertainty are only acquired in this step and do not directly participate in the construction of the current control semantic anchor point. Instead, they are used in the subsequent S2 to form the gateway mapping time interval.

[0039] In some implementation scenarios, to avoid the current control semantic anchor point becoming outdated due to its long-term retention, this embodiment preferably sets a refresh rule for the current control semantic anchor point. The refresh conditions for the current control semantic anchor point preferably include at least one of the following: the current control sequence number changes; the current access gateway identifier changes; the control target digest code changes; or the control effective start time enters a new control cycle. The reason for setting the above refresh conditions is that a change in the control sequence number indicates the advancement of the control cycle, a change in the current access gateway identifier indicates a change in the control propagation link position, a change in the control target digest code indicates a change in the control content, and the control effective start time entering a new control cycle indicates a change in the time boundary. If any of the above conditions are met, it may mean that the current control semantics have changed. Therefore, a new current control semantic anchor point should be constructed to ensure that the current control semantic anchor point continuously reflects the effective platform control semantics of the target IoT device within the current control cycle.

[0040] Through the above processing, S1 finally outputs the current control semantic anchor point, propagation constraint data, and device execution readback data with completed field organization. Among them, the current control semantic anchor point is used as a unified reference for the reconstruction of the time interval for event validity in S2 and the control semantic consistency verification in S3. The propagation constraint data is used to support the subsequent time mapping and time interval reconstruction. The device execution readback data is used for the subsequent control semantic consistency verification. Compared with the existing processing method that only maintains the current control state based on the last control-related event received by the platform, a single control sequence number, or a single access state, this step constructs the current control semantic anchor point to jointly solidify the access position, control identity, time start point, and control content in the current control cycle. This ensures that even if subsequent late events arrive legally on the platform side, they must return to the current control semantic anchor point for comparison, thereby effectively reducing the risk of old control semantics mistakenly contaminating the current control cycle.

[0041] In one implementation, S2 is used to reconstruct the event validity time interval for subsequent control-related events arriving at the platform based on multi-time records and propagation constraint data, and output the event validity time interval to S3 for use. The technical problem to be solved by this step is that in an operating environment where multiple gateways roam, gateway cache backlog, message retransmission and retransmission coexist, the time when the platform receives the control-related event is not the same as the actual validity time of the control-related event in the propagation link. If the event validity time is determined solely based on the platform receiving time, the last arrival order of the platform, or the result of back-calculating the fixed propagation delay, it is easy to mistakenly identify late-arriving historical events as current control cycle events, and it is also easy to mistakenly exclude normally late but still valid control-related events. Therefore, S2 combines the gateway record chain and the platform receiving chain to restore the event validity time interval that matches the actual propagation process for each control-related event, which serves as the time basis for subsequent control semantic consistency verification.

[0042] Specifically, S2 processes control-related events that subsequently arrive at the platform. In this embodiment, control-related events include at least one of the following: acknowledgment return events, resend message events, and old control command return events. For each control-related event, it is preferable to extract the corresponding gateway-side event recording time and platform-side receiving time from multiple time records, and then reconstruct the event's valid time interval by combining it with the propagation constraint data already obtained in S1. It should be clarified here that the gateway-side event recording time belongs to the gateway's local time system, while the platform-side receiving time belongs to the platform's unified time base. The two cannot be directly compared, nor can they be directly used to calculate the difference or average. Only after completing the time mapping and propagation delay constraint processing can the gateway-side event recording time and the platform-side receiving time jointly participate in the construction of the event's valid time interval.

[0043] In this embodiment, the propagation constraint data includes at least time offset, time offset uncertainty, historical baseline propagation delay, propagation delay discrete representation, queue occupancy representation, and retransmission representation. The time offset is used to correct the systematic difference between the gateway's local clock and the platform's unified time reference; the time offset uncertainty characterizes the fluctuation range of this correction relationship; the historical baseline propagation delay characterizes the normal propagation level from the gateway to the platform under the same current access gateway and the same control-related event type; the propagation delay discrete representation characterizes the normal fluctuation degree of propagation delay; the queue occupancy representation characterizes the queuing congestion degree when the current control-related event enters the gateway reporting link; and the retransmission representation characterizes the intensity of repeated transmission of the control-related event during propagation. In the above propagation constraint data, the time offset, time offset uncertainty, historical baseline propagation delay, and propagation delay discrete representation are all time-related quantities, preferably uniformly represented in seconds or milliseconds; the queue occupancy representation is a dimensionless representation; and the retransmission representation is a count. Only after the dimensions are unified will the relevant data participate in subsequent time interval reconstruction to avoid directly mixing data with different dimensions.

[0044] In this embodiment, the queue occupancy characteristic is preferably obtained using a ratio conversion method. Specifically, the queue length when control-related events enter the gateway reporting queue and the corresponding gateway queue capacity are extracted. Then, the queue occupancy characteristic is obtained by dividing the queue length by the queue capacity. The reason for this processing is that queue length and queue capacity are both count quantities and cannot be directly used for propagation delay correction. Only through ratio conversion can a dimensionless characteristic result independent of the gateway size be obtained and used for subsequent propagation delay upper bound correction. Preferably, when the gateway uses a fixed-capacity queue, the queue occupancy characteristic is... The value of the representation quantity is between 0 and 1. When the gateway adopts elastic queue management and allows short-term overload, the ratio conversion result can exceed 1. In this case, it is preferable to truncate the ratio conversion result exceeding 1 to the range of 1 to 1.5 and use it as the queue occupancy representation quantity. The basis for its value is: if the ratio conversion result under extreme congestion scenario is not restricted at all, a small number of abnormal peaks will cause the subsequent backtracking time interval to be excessively amplified, reducing the ability to distinguish the time interval where the event can be established; while using limited truncation, it can reflect the amplification effect of gateway backlog on propagation delay, and avoid extreme samples from destroying the overall stability.

[0045] After obtaining the queue occupancy representation, this implementation further determines the retransmission representation. The retransmission representation is preferably represented by the number of retransmissions of the current control-related event. Preferably, the value of the number of retransmissions is in the range of 0 to 5. In environments with significant link fluctuations and frequent retransmissions and retransmissions, it can be extended to 0 to 10. The basis for this value range is that for most IoT control links, a retransmission count exceeding 5 indicates that the propagation stability of the current control-related event is poor, and the safety margin needs to be significantly increased when constructing the upper bound of the propagation delay. If the retransmission count exceeds 10, it usually corresponds to an abnormal communication scenario, and the subsequent backtracking time interval will be significantly widened. At this time, it is more suitable to further strictly filter out retransmissions in S3 in combination with the effective window of the current control semantics.

[0046] To construct the lower and upper bounds of propagation delay, this implementation preferably first determines the historical baseline propagation delay and the discrete representation of propagation delay. The historical baseline propagation delay is preferably obtained from the statistics of the most recent 100 to 1000 historical samples under the same current access gateway and the same control-related event type; more preferably, it is obtained from the statistics of the most recent 200 to 500 historical samples. If the average value is used as the historical baseline propagation delay, the discrete representation of propagation delay is preferably the standard deviation; if the median value is used as the historical baseline propagation delay, the discrete representation of propagation delay is preferably the mean of absolute deviations or the interquartile range. This is because the central statistic and the discrete statistic... To accurately reflect the fluctuation level of propagation delay, matching statistical standards should be adopted. If the number of historical samples is less than 50, the historical baseline propagation delay should preferably be the benchmark propagation delay recorded during the system online calibration phase, and the propagation delay discrete characterization should preferably be the maximum propagation deviation recorded during the online calibration phase or a preset safety margin. When the number of historical samples is between 50 and 100, it is preferable to determine the historical baseline propagation delay and the propagation delay discrete characterization by weighted fusion of the historical sample statistical results and the online calibration results. The weight of the historical sample statistical results is preferably between 0.4 and 0.7, which can avoid the propagation delay estimation instability caused by insufficient samples during the cold start phase.

[0047] Based on this, this implementation constructs a lower bound and an upper bound for propagation delay. The lower bound is preferably obtained by subtracting one time the discrete representation of propagation delay from the historical baseline propagation delay. When the calculated result is less than 0, the lower bound is corrected to 0. This is because the lower bound represents the shortest reasonable time required for control-related events to propagate from the gateway to the platform, and a negative value is impossible. Simultaneously, subtracting one time the discrete representation from the historical baseline propagation delay allows for necessary downlink space to accommodate normal propagation fluctuations without excessively lowering the lower bound. The upper bound is preferably obtained by adding the corrected result of the discrete representation of propagation delay to the historical baseline propagation delay. The discrete representation of propagation delay is amplified and corrected according to queue occupancy and retransmission representations. Specifically, a queue occupancy correction system is preferably introduced. The queue occupancy correction coefficient and retransmission correction coefficient are used to jointly correct the discrete representation of propagation delay. The queue occupancy correction coefficient is preferably 0.5 to 1.5, more preferably 1.0; the retransmission correction coefficient is preferably 0.5 to 3.0, more preferably 1.5. The values ​​are based on the following: the impact of gateway queuing on propagation delay is usually a gradual increase, so the queue occupancy correction strength should be controlled within a medium range; the impact of retransmission behavior on propagation delay is more direct, especially in retransmission events and old control command return events. For each additional retransmission, the uncertainty of the event arrival time at the platform will increase significantly. Therefore, the retransmission correction coefficient should be higher than the queue occupancy correction coefficient. The lower bound and upper bound of propagation delay constructed in the above manner are both time quantities, preferably uniformly expressed in seconds or milliseconds, and the units should be unified before being combined with the platform-side reception time.

[0048] After obtaining the lower and upper bounds of the propagation delay, this embodiment constructs a gateway mapping time interval. Specifically, the gateway-side event recording time carried in the control-related events is mapped to the platform's unified time reference according to the time offset, and the mapping result is used as the center time. Then, the gateway mapping time interval is formed by extending it by one time offset uncertainty before and after. The reason for this processing is that the time offset is used to correct the systematic difference between the gateway clock and the platform clock, and the time offset uncertainty is used to characterize the fluctuation range of this mapping relationship. Only when the two work together can the gateway-side event recording time be converted into a time interval that can be compared under the platform's unified time reference, rather than a single point result lacking tolerance. Preferably, the time offset uncertainty is controlled within 5% to 20% of the duration of a single control cycle, and more preferably not higher than 50 milliseconds. If the time offset uncertainty exceeds this range, it indicates that the current time synchronization quality is poor, and the obtained gateway mapping time interval will be significantly wider. At this time, a more rigorous screening should be performed in S3 in combination with the current control semantic effective window.

[0049] While constructing the gateway mapping time interval, this implementation also constructs a backtracking time interval. Specifically, using the platform-side reception time as the backtracking reference point, the upper bound of the propagation delay is pushed back to obtain the starting boundary of the backtracking time interval, and the lower bound of the propagation delay is pushed back to obtain the ending boundary of the backtracking time interval. The backtracking time interval formed in this way means that if the control-related event is indeed uploaded to the platform by the gateway, then the actual time of its occurrence on the gateway side should fall between the above-mentioned starting boundary and ending boundary. It should be emphasized here that the platform-side reception time can only form a physically meaningful backtracking time interval after combining the lower bound and the upper bound of the propagation delay. If a single backtracking result is obtained by directly subtracting a fixed constant from the platform-side reception time, it will not be able to reflect the propagation differences of different control-related events under different queue loads and different retransmission intensities.

[0050] After obtaining the gateway mapping time interval and the backtracking time interval, this implementation performs an intersection process on the two to obtain the event-possible time interval for the corresponding control-related event. The meaning of the intersection process is to retain the time range jointly covered by the gateway mapping time interval and the backtracking time interval. The technical significance of this process is that the gateway mapping time interval constrains the possible time of the control-related event from the gateway record chain, and the backtracking time interval constrains the possible time of the control-related event from the platform receiving chain. Only the time range that simultaneously satisfies both types of constraints can be identified as the time interval in which the control-related event is truly likely to be established. Therefore, the event-possible time interval is not an approximate time point obtained by backtracking from a single timestamp, but a unified time interval that simultaneously satisfies the gateway-side recording time, the platform-side receiving time, and the propagation constraints. If the gateway mapping time interval and the backtracking time interval overlap, the overlapping part is output as the event-possible time interval for S3 to call; if the two do not overlap, it means that the gateway-side event recording time, the platform-side receiving time, and the propagation constraints of the control-related event cannot be simultaneously established, and the control-related event is marked as an invalid event and will not enter the subsequent state write-back permission result generation process.

[0051] To improve the stability of this step in actual engineering scenarios, this implementation method preferably performs further constraint processing on invalid events. Preferably, when the proportion of invalid events in the same current access gateway exceeds 20% within three consecutive control cycles, the time offset and time offset uncertainty of the corresponding gateway are preferably re-executed for time synchronization update. When the proportion of invalid events in the same control-related event type exceeds 30% in 50 consecutive events, the historical baseline propagation delay and propagation delay discrete representation quantity corresponding to this type are preferably re-statistically calculated. The reason for setting the above constraints is that a continuous increase in the proportion of invalid events usually means that the time mapping relationship or propagation delay statistical model has deviated from the current actual operating state. If it is not corrected in time, the control semantic consistency verification of subsequent S3 will be affected. This part of the processing is an engineering enhancement measure for the aforementioned innovative reconstruction chain, and its purpose is to maintain the long-term stability of the reconstruction process of the event valid time interval.

[0052] It should be noted that the gateway-side event recording time collection, platform-side receiving time collection, bidirectional time synchronization, queue length monitoring, retransmission count, and historical sample statistics are all existing data acquisition or basic statistical methods in this field. In this step, they are mainly used to provide input or complete basic conversions, so they are only briefly introduced as supporting content and are not the focus of this step.

[0053] In one implementation, S3 is used to determine whether the control-related events are consistent with the control semantics corresponding to the current control cycle based on the current control semantic anchor point obtained in S1, the event validity time interval obtained in S2, the device execution readback data and propagation constraint data obtained in S1, and output the state write-back permission result. This step also introduces the current control semantic validity window, interval overlap rate, execution readback consistency value, control semantic validity score and state write-back permission result to jointly determine whether the control-related events belong to the current control cycle in terms of time, whether they point to the current control semantic anchor point in terms of content, and whether they have been executed in terms of execution status.

[0054] Specifically, firstly, a valid window for the current control semantics is constructed based on the current control semantic anchor point and propagation constraint data. The valid window for the current control semantics is used to characterize the time range within which the platform allows control-related events to be recognized as valid control semantics for the current control cycle. When constructing this window, the control effective start time in the current control semantic anchor point is used as the starting boundary of the valid window for the current control semantics. This is because the control effective start time characterizes the starting point of the time when the current control content officially enters the effective state on the platform side. Control-related events arriving on the platform before this time point should not be considered as valid confirmation criteria for the current control cycle. The termination boundary of the valid window for the current control semantics is not directly given with a fixed duration, but is adaptively constructed in combination with propagation constraint data to ensure that the window is closed in a timely manner in scenarios with small link fluctuations, and to retain a reasonable tolerance range for normal late events in scenarios with large link fluctuations.

[0055] In this embodiment, three parameters are preferably preset: basic hold duration, maximum hold duration, and protection interval. A propagation jitter correction is constructed based on the width of the time interval within which recently confirmed control-related events can be established. The basic hold duration characterizes the minimum duration that the current control semantic effective window needs to be maintained under normal propagation conditions. The basic hold duration is preferably between 1 and 60 seconds, more preferably between 3 and 20 seconds. If the basic hold duration is less than 1 second, it is difficult to cover normal link fluctuations and platform processing latency, and control-related events that are normally delayed but still valid may be prematurely excluded. If the basic hold duration exceeds 60 seconds, the old control semantics will be maintained for too long, which is not conducive to timely blocking of historical events in scenarios where the control cycle progresses rapidly. The maximum hold duration... The protection interval is used to limit the maximum extension range of the current control semantic effective window under extreme link fluctuation scenarios. It is preferably 5 to 180 seconds, more preferably 10 to 60 seconds. The maximum holding time should be greater than the basic holding time to retain the fault tolerance capability when the link fluctuates abnormally, but it cannot be expanded indefinitely, otherwise it will weaken the constraint effect of the current control semantic effective window on the time boundary. The protection interval is used to avoid the current control semantic effective window of the previous control cycle and the next control cycle from overlapping in reverse at the boundary. It is preferably 10 milliseconds to 500 milliseconds, more preferably 50 milliseconds to 200 milliseconds. If the protection interval is too small, the windows will squeeze each other or even cross under time jitter scenarios. If the protection interval is too large, it will unnecessarily shorten the confirmation time of the previous control cycle for normal late events.

[0056] The propagation jitter correction is used to describe the time uncertainty level of the current link in its recent operating state. To ensure its feasibility and engineering stability, this implementation method preferably uses existing smoothing statistical methods to obtain the propagation jitter correction. Specifically, firstly, the width of the event validity time interval for recently confirmed control-related events is calculated. The event validity time interval width is obtained by subtracting the starting boundary from the ending boundary of the event validity time interval. The result is a time quantity, preferably uniformly expressed in seconds or milliseconds. Then, the event validity time interval widths of the most recent 20 to 100 confirmed control-related events are calculated using an exponentially weighted moving average method. The propagation jitter correction is obtained by smoothing the data. When the number of samples is less than 20, the propagation jitter correction is easily affected by occasional anomalies. When the number of samples exceeds 100, the propagation jitter correction responds too slowly to changes in the current link status. The smoothing factor in the exponentially weighted moving average is preferably 0.1 to 0.5, more preferably 0.2 to 0.3. If the smoothing factor is too small, the propagation jitter correction will not respond sufficiently. If the smoothing factor is too large, the single abnormal sample will have too strong an impact on the window boundary. If the system is in the cold start phase, or the number of recently confirmed control-related events is less than 20, the propagation jitter correction is preferably based on the propagation uncertainty benchmark value recorded during the online calibration phase.

[0057] After obtaining the base hold duration, maximum hold duration, guard interval, and propagation jitter correction amount, the effective window of the current control semantics is constructed. If the anchor point of the current control semantics for the next control cycle has already been formed, the termination boundary of the effective window of the current control semantics is preferably determined according to the following rules: On the one hand, the time convergence boundary is obtained by subtracting the guard interval from the control activation start time of the next control cycle; on the other hand, the propagation tolerance boundary is obtained by adding the base hold duration to the control activation start time of the current control cycle, and then adding the amplified correction duration of the propagation jitter correction amount. The amplification of the propagation jitter correction amount is preferably achieved by multiplying by an amplification factor, which is preferably between 0.5 and 3.0, more preferably between 1.0 and 2.0. Then, the earlier arrival time between the time convergence boundary and the propagation tolerance boundary is taken as the effective window of the current control semantics. The reason for handling the termination boundary of the effective window in this way is that when the next control cycle has been formed, the window of the current control cycle must end in a timely manner to avoid the old control semantics from intruding into the new control semantics. However, if there are still normal late arrival phenomena in the link, a certain propagation tolerance range needs to be reserved. Therefore, the time convergence boundary and the propagation tolerance boundary should be considered at the same time. When the current control semantic anchor point of the next control cycle has not yet been formed, it is preferable to add the base hold duration to the start time of the control effect of the current control cycle, and then add the propagation jitter correction amount after amplification to this basis. Then compare it with the termination time under the control of the maximum hold duration, and take the earlier one as the termination boundary of the effective window of the current control semantics. In this way, the confirmation space for normal late arrival events can be reserved before entering the next control cycle, while preventing the window from being amplified indefinitely due to abnormal propagation fluctuations.

[0058] It should be further explained that whether the current control semantic anchor point is formed in the next control cycle is preferably determined according to the rule in S1. That is, when the control sequence number changes, the current access gateway identifier changes, the control target digest code changes, or a new control cycle begins at the start of control, it is considered that the current control semantic anchor point of the next control cycle has been formed. By pointing this rule back to S1, it can be ensured that the construction of the current control semantic effective window in S3 is consistent with the update of the current control semantic anchor point in S1, and there will be no problem of inconsistent judgment basis between the previous and next cycles.

[0059] After constructing the current control semantic validity window, this implementation method cross-determines the event validity time interval output by S2 with the current control semantic validity window. Specifically, it first determines whether there is an overlapping interval. If there is no overlapping interval, it means that although the control-related event may be valid in the sense of propagation link, its possible validity time range has fallen outside the time range allowed for confirmation in the current control cycle. Therefore, the write-back permission result corresponding to the control-related event should be directly determined as write-back prohibited, and it will not enter the subsequent control semantic consistency verification process. The reason for this is that the time condition is the first threshold of the control semantic validity. Any control-related event that does not meet the time condition should not be allowed to be written back, even if its control sequence number or control target digest code is superficially consistent with the current control semantic anchor point. If the event validity time interval overlaps with the current control semantic validity window, the control-related event is determined as a candidate event that meets the time validity condition, and the interval overlap rate is calculated.

[0060] The interval overlap rate is used to characterize the temporal closeness of the event's valid time interval and the current control semantic effective window. In practice, it is preferable to calculate the interval overlap rate by dividing the overlapping interval duration by the event's valid time interval duration. Both the overlapping interval duration and the event's valid time interval duration are time quantities, preferably expressed in seconds or milliseconds. The interval overlap rate obtained after the ratio conversion is a dimensionless quantity, ranging from 0 to 1. To avoid unstable results due to an excessively small denominator when the event's valid time interval is extremely narrow, it is preferable to use a value within the event's valid time interval duration... The larger of the two values, the minimum positive time constant and the minimum positive time constant, is used as the denominator for the ratio conversion. The minimum positive time constant is preferably between 1 and 10 milliseconds, and more preferably 5 milliseconds. The reason for this value is that if the minimum positive time constant is too small, it will not be able to effectively suppress the proportional amplification caused when the denominator is close to 0; if the minimum positive time constant is too large, it will reduce the interval overlap rate of candidate events that should have a high degree of time matching. The closer the interval overlap rate is to 1, the more concentrated the control-related event is in the current control semantic effective window in time; the closer the interval overlap rate is to 0, the weaker its correlation with the current control cycle in time.

[0061] After completing the time matching determination, this embodiment combines the device execution readback data to verify the control semantic consistency between the control-related events and the current control semantic anchor. The device execution readback data includes at least the executed control sequence number, the executed control target digest code, and the execution status identifier. The purpose of the control semantic consistency verification is to determine whether the control content pointed to by the candidate event that meets the time condition truly belongs to the control semantics corresponding to the current control cycle. Specifically, it is preferable to first compare the execution content of the control-related event itself, that is, extract the control sequence number corresponding to the control-related event and compare it with the current control sequence number in the current control semantic anchor, and / or extract the control target digest code corresponding to the control-related event and compare it with the control target digest code in the current control semantic anchor. For line comparison, if the control-related event carries both a control sequence number and a control target digest code, it is preferable to perform both comparisons simultaneously; if it carries only one of them, it is preferable to perform a comparison on the available fields, and then perform an execution result comparison on the device's readback data, that is, extract the executed control sequence number and verify its consistency with the current control sequence number in the current control semantic anchor, and or extract the executed control target digest code and verify its consistency with the control target digest code in the current control semantic anchor. It must be clear here that similar quantities should be compared accordingly, that is, the control sequence number is only compared with the current control sequence number, and the control target digest code is only compared with the control target digest code. Cross-comparison is not allowed. The execution status identifier is used alone to determine whether the device has completed the execution of the current control content.

[0062] To unify the matching of time matching results and execution results within the same judgment framework, this implementation further constructs an execution readback consistency value. The execution readback consistency value is obtained using a discrete mapping method and is a dimensionless quantity. Specifically, when the device's execution readback data explicitly indicates that the executed control sequence number matches the current control sequence number, or that the executed control target digest code matches the control target digest code in the current control semantic anchor point, and the execution status identifier indicates that the corresponding control content has been executed, the execution readback consistency value is preferably set to 1; when the device's execution readback data explicitly indicates that the executed control sequence number matches the current control sequence number, or that the executed control target digest code matches the control target digest code in the current control semantic anchor point, and the execution status identifier indicates that the corresponding control content has been executed, the execution readback consistency value is preferably set to 1. When the current control sequence number is inconsistent, or the executed control target digest code is inconsistent with the control target digest code, the execution readback consistency value is preferably set to 0. When the device has not yet returned the executed readback data, but the current control-related event has passed the time condition determination, and the current access gateway remains continuous, the execution readback consistency value is preferably set to 0.5. It should be clearly stated here that the execution readback consistency value of 0.5 only indicates that the current control-related event is in an intermediate determination state. This value is only used for the comprehensive judgment of the subsequent control semantic validity score, and does not directly represent that write-back is allowed, nor does it mean that the device has completed execution.

[0063] After obtaining the interval overlap rate and the execution readback consistency value, this embodiment preferably uses a weighted summation method to form the control semantic effectiveness score. The interval overlap rate is a dimensionless quantity obtained by ratio conversion, and the execution readback consistency value is a dimensionless quantity obtained by discrete mapping. Therefore, the two can be weighted and summed after weight normalization. Specifically, it is preferable to assign a time matching weight to the interval overlap rate and an execution consistency weight to the execution readback consistency value. The sum of the two is 1, so the control semantic effectiveness score is also a dimensionless quantity. The time matching weight is preferably 0.3 to 0.5, more preferably 0.4; the execution consistency weight is preferably 0.5 to 0.7, more preferably 0.6. The basis for this setting is that time matching is used to limit whether control-related events are... While it falls within the current control cycle, the final decision on whether to allow a write-back should be primarily based on whether the device has actually executed the current control content. Therefore, the execution consistency weight is preferably higher than the time matching weight, and the state write-back permission threshold is preferably between 0.8 and 0.95, more preferably 0.85. If the threshold is too low, control-related events with high time matching but insufficient execution confirmation may be mistakenly allowed to write back. If the threshold is too high, some truly valid late events may be difficult to pass the judgment. According to the above weight and threshold settings, even if the interval overlap rate reaches 1, if the execution readback consistency value is only 0.5, the control semantic validity score is usually insufficient to reach the state write-back permission threshold. This ensures that candidate events of "execution readback not yet returned" will not be mistakenly judged as allowed to write back simply because of good time matching.

[0064] In this embodiment, the generation of the state write-back permission result preferably satisfies the following three conditions simultaneously: First, the time interval for the event to be valid overlaps with the current control semantic validity window; second, the control semantic validity score is not lower than the state write-back permission threshold; third, the execution status identifier in the device execution readback data indicates that the corresponding control content has been executed. Only when the above three conditions are met simultaneously is the state write-back permission result of the corresponding control-related event determined as allowed to write back; otherwise, it is determined as prohibited to write back. The reason for this processing is that the interval overlap rate solves the problem of "whether the event belongs to the current control cycle in terms of time", the execution readback consistency value solves the problem of "whether the event points to the current control semantic anchor point in terms of content", and the execution status identifier further solves the problem of "whether the device has completed execution". All three are indispensable. Compared with the existing method of confirming the control semantic validity based only on the platform arrival order, local timestamp or single control sequence number, this embodiment can significantly reduce the risk of erroneous write-back of historical events and misconfirmation of incomplete execution status by dual constraints of "current control semantic validity window" and "device execution readback data".

[0065] In terms of engineering implementation, it has recently been confirmed that control-related event width statistics, exponential weighted moving average smoothing, time interval length calculation, overlapping interval extraction, ratio conversion, and weighted summation are all commonly used data processing methods in this field. They mainly play a basic calculation support role in this step, so they are only briefly described as supporting existing technologies and are not the focus of this step.

[0066] In one implementation, S4 is used to call the state write-back permission result output by S3 to execute the global control state write-back control of the target IoT device on the platform side; when the state write-back permission result indicates that write-back is prohibited, the device state verification is further triggered, and when the device state verification result is inconsistent with the current control semantic anchor point, a correction control event is generated, and the current control semantic anchor point construction process of the next control cycle is entered. Therefore, this step establishes a stable and traceable global control state when write-back is allowed, identifies the real deviation through device state verification when write-back is prohibited, and generates a correction control event when necessary to restore the consistency between the global control state of the target IoT device on the platform side and the actual execution state of the device.

[0067] Specifically, the write-back permission result output by S3 is called first. The write-back permission result includes at least two states: write-back allowed and write-back prohibited. Write-back allowed means that the corresponding control-related event has simultaneously met the current control semantic effective window constraint, control semantic consistency verification requirement, and execution completion requirement. Therefore, it can be used as a valid confirmation basis for the current control cycle to participate in the global control state update of the target IoT device on the platform side. Write-back prohibited means that the corresponding control-related event does not meet at least one of the aforementioned conditions. Therefore, it cannot directly enter the global control state of the target IoT device on the platform side. The write-back permission result itself belongs to the output result of S3 and is not recalculated in S4. Instead, it is directly called as the basis for branch control.

[0068] When the write-back permission result indicates that write-back is allowed, this implementation performs a global control state update. Here, global control state refers to the set of currently valid control states maintained by the platform for the target IoT device, used to record the current control cycle control semantics confirmed by the platform. During the global control state update, at least the current access gateway identifier, current control sequence number, control effective start time, and control target digest code from the current control semantic anchor point are written into the global control state of the target IoT device on the platform side, and a write-back confirmation flag associated with the corresponding control-related event is generated. This is because the current access gateway identifier is used to characterize the current control... The access location to which the semantics depend, the current control sequence number used to represent the identity identifier of the current control cycle, the control effective start time used to represent the starting time of the current control content taking effect on the platform side, the control target digest code used to represent the semantic identifier of the current control content, and the write-back confirmation flag used to represent that the global control state has passed the validity judgment of S3 and been recognized by the platform. Only by writing the above content together can the global control state of the target IoT device on the platform side fully represent the control semantics that have been confirmed to be valid within the current control cycle. If only some of these fields are written, the subsequent device status verification and correction control event generation will lose a complete comparison basis.

[0069] In this embodiment, the write-back confirmation flag preferably includes at least one of the following: confirmation event identifier, confirmation write-back time, and confirmation source type. The confirmation event identifier is used to trace the specific control-related event that triggered the current global control state update. The confirmation write-back time is used to record the time point when the global control state of the target IoT device on the platform side is confirmed and written back. The confirmation source type is used to distinguish whether the global control state update is triggered by a confirmation transmission event, a resend message event, or an old control command transmission event. The retention time of the write-back confirmation flag is preferably 1 to 10 control cycles, more preferably 2 to 5 control cycles. The value is determined by the fact that: if the retention time is too short, there will be a lack of effective traceability basis when the device status is reviewed later; if the retention time is too long, it will increase the storage burden of the platform status table. The generation, writing, and storage of the write-back confirmation flag can be implemented by existing status table updates, status database writing, or memory cache refresh methods. These methods are supporting existing technologies, and this step does not focus on the flag storage method itself.

[0070] When the write-back permission result indicates that write-back is prohibited, this implementation method first blocks the write-back of the corresponding control-related event, and then triggers the device status review. The meaning of blocking write-back is: the corresponding control-related event must not directly modify the global control status of the target IoT device on the platform side, must not cover the current access gateway identifier, current control sequence number, control effective start time and control target digest code in the current control semantic anchor point, and must not generate a new write-back confirmation flag. The reason for this is that prohibiting write-back essentially indicates that the control-related event does not yet meet the conditions for entering the effective state of the platform. If it is allowed to directly rewrite the global control status under the condition of prohibiting write-back, the control semantic validity judgment of S3 will lose its constraint effect, causing late historical events or incomplete execution events to pollute the current control cycle status.

[0071] After blocking the write-back, this implementation triggers a device status review. The purpose of the device status review is to confirm whether the global control status of the target IoT device on the platform side is still consistent with the actual execution status of the device, based on the current actual execution result of the target IoT device, rather than repeating the time condition determination already completed in S3. Specifically, it is preferable to initiate a status query to the target IoT device through the current access gateway to obtain the execution control sequence number, execution control target digest code, and execution status identifier required for device status review. The reason for prioritizing the initiation of the status query through the current access gateway is that the current access gateway has been determined as the access location corresponding to the current control cycle in the current control semantic anchor point. Executing the status query through this gateway can reduce routing deviations, duplicate mappings, and status delays caused by cross-gateway queries.

[0072] Status queries are preferably implemented using existing device status query commands, status reporting requests, or heartbeat enhancement query methods. The preferred status query timeout is 50 milliseconds to 3000 milliseconds, more preferably 100 milliseconds to 1000 milliseconds. Since the status query timeout is a time-based parameter, it is preferred to uniformly express it in milliseconds, and the units should be unified before comparison with other time parameters. The rationale for its selection is as follows: if the status query timeout is too short, normal fluctuations in the link will cause a large number of valid queries to be falsely judged as failures; if the status query timeout is too long, the platform's status correction response speed will significantly decrease, and the number of status query retries will increase. The preferred retry count is 1 to 3 times, with 2 times being more preferred. When the retry count is 0, a single occasional query failure will directly lead to the loss of device status verification information. If the retry count exceeds 3 times, it will increase the communication burden on the gateway side and may delay the generation of correction control events. If all status query attempts fail to obtain the data required for device status verification, it is preferable to determine the device status verification result as unconfirmed and keep the current global control status unchanged. At the same time, a verification failure mark is recorded for subsequent operation and maintenance analysis. The verification failure mark here is a supporting engineering recording method used to enhance system traceability and is not the focus of this step.

[0073] After obtaining the execution control sequence number, execution control target digest code, and execution status identifier, this embodiment further determines the device status verification result. To ensure clear judgment relationships and avoid cross-comparison of different types of fields, the following three judgments are preferably performed: The first judgment is to compare the execution control sequence number with the current control sequence number in the current control semantic anchor. It should be clarified here that both the execution control sequence number and the current control sequence number are sequence number identifiers, used only for identity consistency comparison, and not for numerical calculation. The second judgment is to compare the execution control target digest code with the control target digest code in the current control semantic anchor. Both the execution control target digest code and the control target digest code are dimensionless semantic identifiers, used only for semantic consistency comparison, and not involved in numerical addition and subtraction. The third judgment is to determine the device's execution status for the current control content based on the execution status identifier. The execution status identifier is a discrete state quantity, used to characterize the device's execution completion status, execution status, or execution failure status for the control content. Its role is to participate in the determination of the device status verification result, rather than to perform a direct field correspondence comparison with the fields in the current control semantic anchor.

[0074] In this embodiment, the device status verification result includes at least three states: consistent, inconsistent, and unconfirmed. A consistent state indicates that the global control state of the target IoT device on the platform side is consistent with the device's current actual execution state. An inconsistent state indicates that the global control state of the target IoT device on the platform side is inconsistent with the device's current actual execution state. An unconfirmed state indicates that valid device status verification data could not be obtained within the specified status query timeout period and retry count. The device status verification result is preferably determined according to the following rules: if the execution control sequence number is consistent with the current control sequence number, the execution control target digest code is consistent with the control target digest code, and the execution status identifier indicates that the corresponding control content has been executed, then the device status verification result is determined to be consistent. If the execution control sequence number is inconsistent with the current control sequence number, or the execution control target digest code is inconsistent with the control target digest code, or the execution status identifier indicates that the corresponding control content was not executed according to the current control semantic anchor point, then the device status verification result is determined to be inconsistent. If the status query does not return a usable execution control sequence number, execution control target digest code, and execution status identifier, then the device status verification result is determined to be unconfirmed.

[0075] Here, it is necessary to further clarify the meaning of "the execution status indicator indicates that the corresponding control content is not executed according to the current control semantic anchor point". Preferably, this situation includes at least the following two types of reasons. The first type of reason is an abnormal execution status, that is, the execution status indicator indicates that the device is still in the execution state and has exceeded the preset execution waiting time, or the execution status indicator indicates that the execution has failed. The preset execution waiting time is preferably 1 to 3 basic holding times, more preferably 1.5 to 2 basic holding times. The preset execution waiting time is a time quantity, preferably uniformly expressed in seconds or milliseconds, and the unit is unified before comparison. Its value is based on the fact that if the preset execution waiting time is too short, some parts that could have been executed will be executed. Regularly completed equipment actions may be misjudged as execution anomalies. If the preset execution wait time is too long, it will delay the generation of correction control events and reduce the timeliness of platform status correction. The second type of reason is control semantic deviation, that is, the execution control sequence number is inconsistent with the current control sequence number, or the execution control target digest code is inconsistent with the control target digest code. It should be noted here that the control semantic deviation is determined by the comparison result of the execution control sequence number and the execution control target digest code, rather than by the execution status identifier. By separating "execution status anomaly" and "control semantic deviation" into two types of reasons, we can avoid making the execution status identifier bear the judgment task beyond the scope of its field meaning, and make the determination process of equipment status review results clearer.

[0076] When the device status verification result is determined to be consistent, this implementation method keeps the global control status of the target IoT device on the platform unchanged. The reason for this is that although the corresponding control-related event is determined by S3 to be prohibited from being written back, the current actual execution status of the device is still consistent with the current control semantic anchor point, indicating that the global control status maintained by the platform is correct, and there is no need to perform additional status correction at this time.

[0077] When the device status verification result is determined to be unconfirmed, this embodiment preferably keeps the current global control status unchanged and records the verification failure mark, waiting for the next control-related event to arrive or the next status query to re-determine. The reason for this is that if the platform status is rashly adjusted in the unconfirmed state, it is easy to introduce new errors.

[0078] When the device status verification result determines that the status is inconsistent, this implementation generates a correction control event and enters the current control semantic anchor point construction process of the next control cycle based on the correction control event. The technical significance of this approach is that the platform does not rely on the delayed control-related events themselves to directly overwrite the current global control status. Instead, it generates a new correction control event after confirming the deviation through the actual execution status of the device, bringing the system into a new control cycle and re-establishing the consistency between the platform status and the device status with the new current control semantic anchor point. This approach differs from the existing methods of "directly overwriting the current status with abnormal events after discovering an anomaly" or "simply discarding abnormal events without processing," and can simultaneously take into account the continuity of control semantics and the stability of the global control status of the target IoT device on the platform side.

[0079] In this embodiment, the correction control event includes at least a correction control sequence number, a correction control effective time, and a correction control target digest code. The correction control sequence number is used to identify the identity of the new control cycle to which the correction control event belongs, and is preferably generated by incrementing the current control sequence number by 1. When the platform adopts a segmented sequence number strategy, the next available control sequence number within the sequence segment of the current control cycle can also be used. The correction control effective time is preferably the current platform time after the device status verification result is determined to be inconsistent, or the current platform time plus a preset correction preparation time. The preset correction preparation time is preferably 10 milliseconds to 500 milliseconds, more preferably 50 milliseconds to 200 milliseconds, and the preset correction preparation time is the same as the previous one. The sample belongs to the time quantity, and it is preferred to uniformly use milliseconds to represent it. Its purpose is to reserve the necessary state switching preparation time for the current access gateway and the target IoT device. The correction control target digest code is preferably obtained by re-executing the digest processing according to the control target digest code generation rules in S1 based on the control target parameters corresponding to the correction control event. This is to ensure that after the correction control event enters the next control cycle, it can be consistent with the current control semantic anchor construction logic in S1. It should be emphasized here that the correction control event is not a simple renaming of the write-back prohibited event, but a new control cycle control event actively generated by the platform to restore state consistency after confirming that the current actual execution state of the device is inconsistent with the current control semantic anchor.

[0080] In terms of engineering implementation, status query message sending, status receipt reception, write-back confirmation flag generation, platform status table update, retry query, and log recording are all common platform status maintenance and device status query methods in this field. In this step, they mainly serve the functions of input acquisition, process support, and result recording. Therefore, they are only briefly described as supporting existing technologies and are not the focus of S4.

[0081] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for wireless communication control of Internet of Things (IoT) devices, characterized in that, Includes the following steps: S1. Obtain the control propagation link data corresponding to the target IoT device. The control propagation link data includes at least multiple time records, propagation constraint data, and device execution readback data. The multiple time records include control issuance records and gateway access switching records. Construct the current control semantic anchor point based on the control issuance records and gateway access switching records. The current control semantic anchor point includes at least the current access gateway identifier, the current control sequence number, the control effective start time, and the control target digest code. S2. For subsequent control-related events arriving at the platform, based on multi-time recording and propagation constraint data, the gateway-side event recording time carried in the control-related events is mapped to the platform's unified time base and combined with the platform-side reception time of the control-related events to form a backward time interval, thereby reconstructing the time interval for the corresponding control-related events to be valid. S3. Construct the current control semantic effective window based on the current control semantic anchor point and propagation constraint data, cross-determine the time interval of the event that can be established with the current control semantic effective window, and check the control semantic consistency between the control-related events and the current control semantic anchor point in combination with the device execution readback data, and output the status write-back permission result. S4. Based on the state write-back permission result, execute the global control state write-back control of the target IoT device on the platform side. When the state write-back permission result indicates that write-back is allowed, update the global control state. When the state write-back permission result indicates that write-back is prohibited, block the write-back of the corresponding control-related events and trigger the device state review. When the device state review result is inconsistent with the current control semantic anchor point, generate a correction control event and enter the current control semantic anchor point construction process of the next control cycle.

2. The wireless communication control method for IoT devices according to claim 1, characterized in that, In S1, the current control semantic anchor point is constructed based on the control issuance record and the gateway access switching record. This includes: extracting the current control sequence number and the control effective start time from the control issuance record, extracting the current access gateway identifier from the gateway access switching record, performing digest processing on the control target parameters in the control issuance record to obtain the control target digest code, and then generating the current control semantic anchor point corresponding to the target IoT device based on the current access gateway identifier, the current control sequence number, the control effective start time, and the control target digest code.

3. The wireless communication control method for IoT devices according to claim 2, characterized in that, In S1, the device executes readback data, which includes at least the executed control sequence number, the executed control target digest code, and the execution status identifier. The execution status identifier is used to characterize the execution status of the target IoT device on the control content corresponding to the control issuance record.

4. The wireless communication control method for IoT devices according to claim 3, characterized in that, In S2, the time interval for the corresponding control-related events to be valid is reconstructed, including: mapping the gateway-side event record time carried in the control-related events to the unified time base of the platform to form a gateway mapping time interval, then forming a backtracking time interval based on the platform-side receiving time of the control-related events, and finding the intersection of the gateway mapping time interval and the backtracking time interval to obtain the time interval for the corresponding control-related events to be valid.

5. The wireless communication control method for IoT devices according to claim 4, characterized in that, In S2, the propagation constraint data includes at least the time offset, time offset uncertainty, historical baseline propagation delay, propagation delay discrete representation, queue occupancy representation, and retransmission representation. The gateway mapping time interval is formed based on the time offset and time offset uncertainty, while the backtracking time interval is formed based on the platform side reception time and combined with the historical baseline propagation delay, propagation delay discrete representation, queue occupancy representation, and retransmission representation. When the gateway mapping time interval and the backtracking time interval do not overlap, the corresponding control-related events are marked as invalid events.

6. The wireless communication control method for IoT devices according to claim 5, characterized in that, In S3, the effective window of the current control semantics is constructed based on the current control semantic anchor point and propagation constraint data, including: taking the start time of control effectiveness in the current control semantic anchor point as the starting boundary of the effective window of the current control semantics, and combining the propagation constraint data to determine the duration of the effective window of the current control semantics; When the current control semantic anchor point of the next control cycle is formed, the termination boundary of the current control semantic effective window of the previous control cycle is converged based on the start time of control effectiveness of the next control cycle.

7. The wireless communication control method for IoT devices according to claim 6, characterized in that, In S3, the event's valid time interval is cross-determined with the current control semantic effective window, including: determining whether the event's valid time interval and the current control semantic effective window overlap; if there is an overlap, the corresponding control-related event is identified as a candidate event that meets the time validity condition; if there is no overlap, the write-back permission result of the corresponding control-related event is determined as write-back prohibited.

8. The wireless communication control method for IoT devices according to claim 7, characterized in that, In S3, the consistency of control semantics between control-related events and the current control semantic anchor is checked by combining the device execution readback data. This includes: extracting the control sequence number corresponding to the control-related event and comparing it with the current control sequence number in the current control semantic anchor, and / or extracting the control target digest code corresponding to the control-related event and comparing it with the control target digest code in the current control semantic anchor; Extract the executed control sequence number from the device execution readback data and verify its consistency with the current control sequence number in the current control semantic anchor point; and / or extract the executed control target digest code from the device execution readback data and verify its consistency with the control target digest code in the current control semantic anchor point, and verify it in conjunction with the execution status identifier. If the control sequence number corresponding to the control-related event matches the current control sequence number in the current control semantic anchor, or the control target digest code corresponding to the control-related event matches the control target digest code in the current control semantic anchor, and the executed control sequence number in the device's readback data matches the current control sequence number in the current control semantic anchor, or the executed control target digest code in the device's readback data matches the control target digest code in the current control semantic anchor, and the execution status identifier indicates that the corresponding control content has been executed, then the write-back permission result of the corresponding control-related event will be determined as write-back allowed; otherwise, it will be determined as write-back prohibited.

9. A wireless communication control method for IoT devices according to claim 8, characterized in that, In S4, when the write-back permission result indicates that write-back is allowed, the global control state is updated, including: writing the current access gateway identifier, current control sequence number, control effective start time and control target digest code from the current control semantic anchor into the global control state of the target IoT device on the platform side, and generating a write-back confirmation flag associated with the corresponding control-related event.

10. A wireless communication control method for IoT devices according to claim 9, characterized in that, In S4, when the write-back permission result indicates that write-back is prohibited, the write-back of the corresponding control-related event is blocked and the device status review is triggered. This includes: initiating a status query to the target IoT device through the current access gateway, obtaining the execution control sequence number, execution control target digest code, and execution status identifier obtained from the device status review, comparing the execution control sequence number with the current control sequence number in the current control semantic anchor, comparing the execution control target digest code with the control target digest code in the current control semantic anchor, and determining the device status review result based on the execution status identifier. When the execution control sequence number is inconsistent with the current control sequence number, or the execution control target digest code is inconsistent with the control target digest code, or the execution status identifier indicates that the corresponding control content is not executed according to the current control semantic anchor point, it is determined that the equipment status verification result is inconsistent with the current control semantic anchor point, and a correction control event is generated. Based on the correction control event, the current control semantic anchor point construction process of the next control cycle is initiated.

Images