A cloud edge collaboration-oriented internet of things device access management system

Abstract

The application relates to the field of Internet of Things access management and discloses an Internet of Things device access management system oriented to cloud-edge cooperation, which comprises an access pre-checking module, a cloud-end construction module, a sandbox authentication module and a migration rollback module, the access pre-checking module generates a device access feature vector and a device session identifier, the cloud-end construction module constructs a deterministic finite state automaton, generates Wasm bytecode and issues the Wasm bytecode, the sandbox authentication module creates a Wasm execution context and performs identity authentication, protocol analysis and entropy gradient monitoring, and the migration rollback module generates a lightweight rule set and compiles the lightweight rule set into an eBPF program, detects an abnormal event and restores the Wasm execution context. The application unifies identity authentication, protocol analysis and state flow processes through the deterministic finite state automaton and the Wasm bytecode, and forms a steady-state processing and abnormal rollback link through a lightweight rule set, an eBPF program and an abnormal event recovery mechanism.

Description

Technical Field

[0001] This invention relates to the field of IoT access management, specifically to an IoT device access management system for cloud-edge collaboration. Background Technology

[0002] As IoT devices are increasingly used in field environments such as warehousing, energy metering, environmental monitoring, and industrial control, heterogeneous IoT devices differ in communication protocols, message structures, access frequencies, and authentication methods. The cloud-edge collaborative architecture is used to undertake the tasks of device access, protocol adaptation, and authentication.

[0003] The prior art document CN121418138A discloses a method and system for industrial equipment identity authentication and access control management based on cloud-edge collaboration. It focuses on equipment identity authentication and access control policy management. However, this patent document does not unify protocol parsing, identity authentication and state transition into deterministic finite state automata and Wasm (WebAssembly) bytecode execution logic.

[0004] Existing multi-source heterogeneous device access solutions typically rely on edge nodes for protocol conversion, data preprocessing, and tag mapping. Prior art document CN119155354B discloses a cloud-edge-device collaborative IoT management and scheduling system and data interaction method, while prior art document CN121239749A discloses a unified data access method for multi-source heterogeneous devices based on cloud-edge collaboration. In implementing this invention, the inventors discovered that both methods focus more on data interaction, protocol conversion, or data standardization, lacking steady-state transition triggering judgments based on automata states and entropy gradients. After authentication, steady-state service packets still rely on conventional protocol parsing paths for processing.

[0005] In addition, the inventors also found in their research that existing cloud-edge collaborative access systems often fail to fold the steady-state packet processing logic into a lightweight rule set and compile it into an eBPF (extended Berkeley Packet Filter) program, nor do they process steady-state service packets through the XDP (eXpress Data Path) hook. Furthermore, they lack an exception rollback mechanism that is linked to Wasm execution context recovery when an anomaly occurs.

[0006] Therefore, how to complete identity authentication, protocol parsing, steady-state migration, and abnormal rollback within the same device session lifecycle is a problem that needs to be solved in this field. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides an IoT device access management system for cloud-edge collaboration, which solves at least one technical problem in the process of heterogeneous IoT device access: the lack of a unified collaborative processing mechanism for identity authentication, protocol parsing, steady-state service message processing, and abnormal rollback.

[0008] To address the above problems, this invention provides an IoT device access management system for cloud-edge collaboration, comprising: The access pre-inspection module is used to collect data packets during the initial access phase of heterogeneous IoT devices and generate device access feature vectors and device session identifiers. The cloud-based construction module is used to construct a deterministic finite state automaton based on the device access feature vector, generate Wasm bytecode, and issue the Wasm bytecode when the edge execution conditions are met. The sandbox authentication module is used to load the Wasm bytecode, create a Wasm execution context bound to the device session identifier, perform identity authentication, protocol parsing and entropy gradient monitoring, and output steady-state transition trigger information. The migration rollback module is used to generate a lightweight rule set based on the steady-state migration trigger information and compile it into an eBPF program, process steady-state service messages, detect abnormal events, and restore the Wasm execution context based on the abnormal events.

[0009] By adopting the above technical solution, the deterministic finite state automaton is constructed in the cloud and compiled into Wasm bytecode for execution. Combined with entropy gradient monitoring to output steady-state transition trigger information, the steady-state message processing logic is converted into the eBPF program for processing steady-state service messages. Furthermore, the Wasm execution context is restored upon detecting abnormal events. The authentication logic is handled using the Wasm execution context, ensuring the isolation of the runtime environment for heterogeneous protocol parsing. The steady-state message processing logic after authentication is converted into the eBPF program in the operating system kernel, which reduces the frequent copying of steady-state messages between the kernel layer and the user layer, and reduces the processing latency and resource overhead of the device system. Based on abnormal event detection and context recovery operations, while taking into account message processing efficiency, it maintains the ability to block abnormal communication traffic and restore session state.

[0010] Furthermore, the access pre-detection module generates the device access feature vector by including: Extract the payload, message length, message direction, and arrival time of the data packet; Generate the sampling payload sequence, message length sequence, message direction sequence, and arrival time interval sequence; Calculate the initial information entropy based on the sampled payload sequence and generate a payload summary; The sampling payload sequence, the message length sequence, the message direction sequence, the arrival time interval sequence, the initial information entropy, and the payload summary are combined to form the device access feature vector.

[0011] By employing the above technical solution, message length, message direction, arrival time interval, and byte statistics information in the initial access phase are extracted from multiple dimensions. This processing method completes the extraction of device communication behavior characteristics without relying on deep packet inspection, thereby reducing the computational resource consumption of the pre-feature collection stage.

[0012] Furthermore, the cloud-based construction module constructs the deterministic finite state automaton by: Based on the device access feature vector, candidate protocols are matched in a preset global protocol feature library; Read the identity authentication process corresponding to the candidate protocol; The deterministic finite state automaton is constructed based on the candidate protocol and the identity authentication process.

[0013] By adopting the above technical solution, the verification process of heterogeneous protocols is uniformly abstracted into a deterministic finite state automaton with a fixed structure, eliminating the differences in the underlying network protocol architecture and providing a standard logical benchmark for the unified compilation and state transition of subsequent modules.

[0014] Furthermore, the cloud-based building module generates the Wasm bytecode by including: The deterministic finite state automaton is pruned, retaining the protocol parsing state, authentication state, and steady-state message processing state; The protocol parsing logic, authentication logic, and steady-state message processing logic corresponding to the trimmed deterministic finite state automaton are compiled into the Wasm bytecode.

[0015] By adopting the above technical solution, irrelevant and redundant state nodes are eliminated by pruning the state machine branches, the size of the output Wasm bytecode is reduced, the memory usage of the Wasm execution context is reduced, and the runtime loading time is shortened.

[0016] Furthermore, the cloud-based construction module determines that the edge execution conditions are met by including: The edge execution cost is calculated based on the bytecode size of the Wasm bytecode, the memory usage of the Wasm execution context, the initialization time, and the edge-side resource occupancy rate. The cost of remote parsing is calculated based on the amount of data forwarded remotely in the original message, the round-trip latency of the cloud-edge link, the cloud parsing load, and the quality loss value of the cloud-edge link. When the edge execution cost plus the preset migration decision margin is less than the remote resolution cost, the edge execution condition is determined to be satisfied.

[0017] By adopting the above technical solution, the system's computing resource margin and channel transmission quality are comprehensively considered, and the local operating cost and the remote message return cost are dynamically quantified. This avoids forcibly loading the access logic corresponding to complex deterministic finite state automata when resources are scarce, thus balancing the overall system's computing power allocation.

[0018] Furthermore, the sandbox authentication module performs identity authentication and protocol parsing including: The deterministic finite state automaton is loaded according to the automaton description file associated with the Wasm bytecode; In the Wasm execution context, authentication messages and service messages are processed according to state transition rules. Write the automaton state and entropy gradient into the session state record bound to the device session identifier.

[0019] By adopting the above technical solution, the message flow is processed according to the state transition rules in a secure execution environment, thus achieving isolation between the protocol parsing process and the external system environment. At the same time, the state of the automaton and the entropy gradient are recorded, providing accurate data reference for subsequent steady-state evaluation and logical level migration.

[0020] Furthermore, the sandbox authentication module outputs the steady-state migration trigger information including: The state of the deterministic finite state automaton is read at the end of the sliding window; The entropy gradient is calculated based on the information entropy change of adjacent sliding windows; When the automaton is in a preset steady-state transmit / receive state, and the entropy gradient corresponding to multiple consecutive sliding windows is lower than a preset entropy gradient threshold, the steady-state transition trigger information is output.

[0021] By adopting the above technical solution, the data stream is statistically analyzed using the entropy gradient through a sliding window, which objectively reflects the stability of the message payload structure fluctuating over time. The automaton state is switched to the steady-state transmission and reception state as a constraint condition, and the characteristic change index of stable information entropy is superimposed, providing a numerical judgment condition for the transition of the device communication stage, and ensuring the accuracy of the timing of migration to the kernel layer.

[0022] Furthermore, the migration rollback module generates the lightweight rule set by including: Based on the steady-state transition triggering information, extract the steady-state analytic subgraph corresponding to the steady-state transition triggering information from the deterministic finite state automaton; The message length verification logic, fixed field matching logic, and business field extraction logic in the steady-state parsing subgraph are converted into the lightweight rule set. The lightweight rule set includes message length verification rules, fixed field matching rules, field offset extraction rules, session identifier matching rules, and processing action rules.

[0023] By adopting the above technical solution, a fixed-structure message parsing branch is extracted from the complete deterministic finite state automaton and converted into basic verification and extraction logic, providing a rule basis that conforms to security verification specifications for the subsequent generation of programs suitable for kernel execution.

[0024] Furthermore, the migration rollback module compiles the lightweight rule set into the eBPF program by: The rules in the lightweight rule set are restricted to fixed offset access, fixed-length field extraction, finite branch judgment, and bounded loop processing. The restricted lightweight rule set is compiled into the eBPF program, and the eBPF program is attached to the XDP hook; The eBPF program performs message length verification, fixed field matching, service field extraction, and processing action selection on steady-state service messages.

[0025] By adopting the above technical solution, the syntax and logical structure of the rule content are restricted to ensure that the generated eBPF program passes the security review of the operating system kernel. The eBPF program is then mounted to the XDP hook, so that the steady-state service packets perform verification and processing actions at the network protocol stack entry point, which significantly compresses the flow and processing path of service data packets.

[0026] Furthermore, the migration rollback module restores the Wasm execution context by including: The eBPF program detects entropy feature jumps, steady-state rule mismatches, or session state anomalies, generating the abnormal events. The abnormal events are reported to the user-mode daemon process via a circular buffer. The user-mode daemon restores the Wasm execution context based on the device session identifier contained in the abnormal event.

[0027] By adopting the above technical solution, lightweight statistical monitoring and processing is maintained at the kernel layer. When the business message structure changes abruptly or causes significant fluctuations in information entropy, the abnormal event is constructed and reported through the circular buffer. This enables the user-mode daemon process to reactivate the Wasm execution context based on the device session identifier, thus maintaining the system's fault tolerance capability and business processing continuity in the face of abnormal data.

[0028] Furthermore, the device session identifier is generated based on the address information, access port, transport layer protocol type, and arrival time of the first sampled data packet of the heterogeneous IoT device; The access pre-detection module establishes a session state record; The session state record includes the device session identifier, the device access feature vector, the address information, the access port, the transport layer protocol type, and the current access stage.

[0029] By adopting the above technical solution, a unified device session identifier is generated by combining network protocol layer parameters and time parameters, and multi-dimensional device access information is centrally maintained in the session state record, ensuring the consistency of state in subsequent data interaction and message flow, and facilitating rapid data query and state tracing by each processing module.

[0030] Furthermore, the steady-state migration triggering information includes the device session identifier, the current automaton state, the steady-state message template, the steady-state parsing subgraph index, and the entropy gradient monitoring result; The sandbox authentication module writes the steady-state migration trigger information into the session state record; The migration rollback module reads the corresponding Wasm execution context, automaton description file, and steady-state message template based on the device session identifier.

[0031] By adopting the above technical solution, complete and specific contextual data is provided when a steady-state migration is triggered, and the associated data is written into the session state record. This enables the migration rollback module to obtain the Wasm execution context, automaton description file and steady-state message template required for the logical transformation, thus ensuring the data continuity of the steady-state logical migration process.

[0032] Furthermore, before mounting the eBPF program, the migration rollback module writes the device session identifier, the lightweight rule set, the entropy gradient monitoring result, the bytecode version information, and the current automaton state into the kernel state mapping table; The kernel-mode mapping table is used by the eBPF program to query the rules and status corresponding to the device session when processing steady-state service messages.

[0033] By adopting the above technical solution, key identifiers, rules and status data required for processing are stored in the kernel space in advance, and an independent data storage area is constructed. This enables the eBPF program to perform local queries in the kernel space when processing the steady-state service message, avoiding cross-level data request waiting.

[0034] Furthermore, the abnormal event includes the device session identifier, the time of the abnormality, the type of abnormality, the trigger rule number, the steady-state rule version, and the abnormal load summary; The user-mode daemon process switches the deterministic finite state automaton to either an abnormal re-authentication state or an identity authentication initialization state based on the type of exception.

[0035] By adopting the above technical solution, detailed anomaly tracing data is encapsulated when an anomaly occurs, and the automaton state is reset in a targeted manner according to the specific anomaly type. This enables the system to distinguish communication anomalies in different situations and adopt an appropriate recovery process, thereby improving the system's flexibility in handling complex anomalies.

[0036] This invention provides an IoT device access management system for cloud-edge collaboration, which has the following advantages: This invention generates device access feature vectors and device session identifiers through an access pre-inspection module, and the cloud construction module constructs a deterministic finite state automaton and generates Wasm bytecode based on the device access feature vectors, enabling the identity authentication, protocol parsing and state transition processes of heterogeneous IoT devices to be executed based on unified automaton logic.

[0037] This invention loads Wasm bytecode through a sandbox authentication module, creates a Wasm execution context bound to a device session identifier, performs identity authentication, protocol parsing, and entropy gradient monitoring, and outputs steady-state transition trigger information when the steady-state transmit / receive state and entropy gradient threshold conditions are met, so that steady-state transition has a basis for state and data flow changes.

[0038] This invention generates a lightweight rule set based on steady-state migration trigger information through a migration rollback module and compiles it into an eBPF program. Steady-state service packets are processed at the XDP hook, and the Wasm execution context is restored through a user-space daemon when an abnormal event is detected, so that steady-state processing and abnormal recovery form a continuous processing link. Attached Figure Description

[0039] Figure 1 This is an architecture diagram of an IoT device access management system for cloud-edge collaboration according to an embodiment of the present invention; Figure 2 This is a flowchart of an IoT device access management method for cloud-edge collaboration according to an embodiment of the present invention; Figure 3 This is a flowchart of the device access feature sampling process according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating the automatic mechanism construction and bytecode generation process according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the edge execution determination and sandbox authentication process according to an embodiment of the present invention. Figure 6 This is a flowchart illustrating the steady-state transition and kernel-state takeover process according to an embodiment of the present invention. Figure 7 This is a flowchart illustrating the anomaly detection and rollback wake-up process according to an embodiment of the present invention; Figure 8 This is a logarithmic amplitude spectrum of the payload of steady-state service packets and abnormal service packets according to an embodiment of the present invention; Figure 9 This is a graph showing the changes in information entropy and entropy gradient of the sliding window in an embodiment of the present invention. Detailed Implementation

[0040] The technical solutions in 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.

[0041] This invention provides an IoT device access management system for cloud-edge collaboration, which operates based on a cloud-edge collaborative IoT access environment. The cloud-edge collaborative IoT access environment includes heterogeneous IoT devices on the field side, edge computing gateways deployed on the field side, and a centralized cloud management platform deployed remotely.

[0042] Heterogeneous IoT devices are used to generate device access requests and business data streams. These devices include field equipment such as sensors, industrial control equipment, logistics data collection terminals, energy metering equipment, environmental monitoring equipment, and warehouse automation equipment. Different heterogeneous IoT devices differ in communication protocols, message structures, access frequencies, and authentication methods.

[0043] An edge computing gateway has a network interface, processor, memory, storage media, and operating system runtime environment. It receives access data packets generated by heterogeneous IoT devices on the field side and provides the runtime foundation for both user-mode execution environment and kernel-mode data packet processing environment.

[0044] The cloud-based centralized management and control platform is deployed on cloud servers or cloud computing clusters to provide a protocol feature library, device authentication process library, automaton generation environment, and bytecode compilation environment. The cloud-based centralized management and control platform communicates with the edge computing gateway to receive access features reported by the edge side and to distribute protocol processing logic, authentication parameters, and steady-state message processing rules to the edge side.

[0045] The hardware deployment environment provides the computing, communication, and storage infrastructure required for operation. The hardware devices themselves are implemented using general-purpose computing or network devices. The processing content of this invention focuses on the access management logic, status judgment logic, execution space migration logic, and exception rollback logic running in the cloud-based centralized management platform and edge computing gateway.

[0046] like Figure 1 As shown, the IoT device access management system for cloud-edge collaboration provided by the present invention may include an access pre-inspection module, a cloud construction module, a sandbox authentication module, and a migration rollback module.

[0047] The access pre-inspection module is deployed in the edge-side access processing environment of the edge computing gateway. It is used to establish device sessions when heterogeneous IoT devices initiate connection requests and to perform lightweight pre-inspection on data packets in the early stages of device access. The access pre-inspection module collects several data packets in the early stages of device access, extracts the packet payload, message length sequence, message direction sequence, arrival time interval, source address information, and payload digest information, and generates a device access feature vector based on the collected data.

[0048] The access pre-inspection module is also used to generate device session identifiers and maintain device session state records. These records include the session identifier, device address, access time, current access stage, sampled data summary, cloud-based delivery logic version, user-mode execution context index, and kernel-mode rule version. Through these device session state records, the access pre-inspection module associates the data processing procedures of the same heterogeneous IoT device across the unknown access, authentication, steady-state transmission and reception, and anomaly fallback stages into the same access lifecycle.

[0049] After generating the device access feature vector, the access pre-inspection module sends the device access feature vector, device session identifier, and sampled data digest to the cloud construction module. In the initial stage of access, the access pre-inspection module does not perform complete protocol parsing and complete identity authentication; instead, it completes access feature sampling and session archiving, enabling the cloud construction module to determine subsequent access processing logic based on global protocol information.

[0050] The cloud-based construction module is deployed on a centralized cloud management platform. It is used to determine candidate protocol types, authentication processes, and message parsing rules based on the device access feature vectors reported by the access pre-inspection module. The cloud-based construction module maintains a global protocol feature library and a device authentication process library. The protocol feature library includes protocol payload statistical features, message length patterns, message direction patterns, fixed field templates, port association information, and steady-state message structures. The device authentication process library includes identity identification reading processes, key exchange processes, credential verification processes, authorization confirmation processes, and abnormal re-authentication processes.

[0051] The cloud-based construction module matches device access feature vectors against a global protocol feature library to determine candidate protocols corresponding to the current heterogeneous IoT devices. After determining the candidate protocols, the cloud-based construction module constructs a deterministic finite state automaton for the device, based on a device authentication process library. This deterministic finite state automaton describes the state transitions of heterogeneous IoT devices from unknown access, protocol detection, identity authentication, authorization confirmation, steady-state transmission and reception, abnormal re-authentication, to session termination.

[0052] The cloud-based construction module is also used to prune the deterministic finite state automaton, retaining only the protocol parsing, authentication, and steady-state message processing states required during the access process of heterogeneous IoT devices. The cloud-based construction module compiles the protocol parsing, authentication, and steady-state message processing logic corresponding to the pruned deterministic finite state automaton into Wasm bytecode, and generates an automaton description file, authentication parameters, and steady-state rule templates that accompany the Wasm bytecode.

[0053] The cloud-based construction module is further used to determine the execution of access logic scheduling. Based on the Wasm bytecode size, edge computing gateway resource consumption, user-space sandbox initialization overhead, amount of remote forwarding data for raw packets, cloud-edge link latency, and cloud parsing load, the cloud-based construction module determines whether the protocol processing logic should be executed in the cloud or at the edge. When determining that the protocol processing logic should be migrated to the edge, the cloud-based construction module distributes the Wasm bytecode, automaton description file, authentication parameters, and steady-state rule templates to the sandbox authentication module.

[0054] The sandbox authentication module is deployed in the user-space runtime environment of the edge computing gateway to load and execute the Wasm bytecode issued by the cloud-based build module. The sandbox authentication module creates a Wasm execution context for the current device session and binds the Wasm execution context to the device session identifier generated by the access pre-inspection module.

[0055] The sandbox authentication module loads the deterministic finite state automaton corresponding to the device based on the automaton description file, and performs protocol parsing, key exchange, credential verification, and authorization confirmation according to the automaton state transition rules. During the identity authentication phase, the sandbox authentication module processes messages containing random numbers, key materials, certificate data, signature data, and authentication response data, and updates the device session state record based on the authentication result.

[0056] The sandbox authentication module is also used to perform sliding window statistics on device data streams during device authentication and business data transmission and reception. The sandbox authentication module calculates the information entropy based on the data stream load within each sliding window and calculates the entropy gradient based on the information entropy changes in adjacent sliding windows. The sandbox authentication module combines the entropy gradient change results with the current state of the deterministic finite state automaton to determine whether the device session has transitioned from the authentication phase to the steady-state transmission and reception phase.

[0057] When the deterministic finite state automaton enters a steady-state transmit / receive state, and the entropy gradient within multiple consecutive sliding windows satisfies the steady-state convergence condition, the sandbox authentication module outputs steady-state migration trigger information to the migration rollback module. The steady-state migration trigger information includes the device session identifier, current automaton state, steady-state message processing status, steady-state message template, steady-state parse subgraph index, and entropy gradient monitoring results.

[0058] The migration rollback module is deployed in the user-space daemon and kernel-space execution environment of the edge computing gateway. Based on the steady-state migration trigger information output by the sandbox authentication module, it migrates the steady-state packet processing logic from the user-space Wasm execution environment to the kernel-space execution environment of the edge computing gateway. The migration rollback module extracts the steady-state parse subgraph from the Wasm execution context and automata description file, and collapses the steady-state parse subgraph into a lightweight rule set.

[0059] The lightweight rule set includes message length verification rules, fixed field matching rules, field offset extraction rules, session identifier matching rules, field mask rules, and processing action rules. When generating the lightweight rule set, the migration rollback module restricts the rule content to fixed offset access, fixed-length field extraction, finite branch judgment, and bounded loop processing to adapt to the security verification requirements of eBPF programs running in kernel mode.

[0060] The migration rollback module compiles the lightweight rule set into an eBPF program and loads the eBPF program into the edge computing gateway's operating system kernel. After the eBPF program passes kernel verification, the migration rollback module attaches the eBPF program to the XDP hook, enabling authenticated steady-state service packets to be processed at the network protocol stack entry point. At the XDP hook, the eBPF program performs packet length verification, field matching, field extraction, counting, allowing, dropping, redirecting, and initial anomaly screening.

[0061] After the eBPF application is successfully mounted, the migration rollback module controls the sandbox authentication module to place the Wasm execution context corresponding to the current device session into a suspended state. The suspended Wasm execution context retains the device session identifier, authentication result summary, current state of the deterministic finite state automaton, steady-state rule version, and context recovery index to restore full protocol parsing and authentication capabilities in the event of an anomaly.

[0062] The migration rollback module is also used to perform exception rollback handling during the execution of kernel-mode eBPF programs. When processing steady-state service packets, the eBPF program performs lightweight entropy feature detection, steady-state rule matching, and session state verification on the packets. When the eBPF program detects entropy feature jumps, steady-state rule mismatches, or session state anomalies, the migration rollback module reports the exception event to the user-mode daemon through a ring buffer.

[0063] An abnormal event includes the device session identifier, the time of occurrence of the abnormality, the type of abnormality, the triggering rule number, the steady-state rule version, and the abnormal payload summary. Upon receiving an abnormal event, the user-space daemon locates the suspended Wasm execution context based on the device session identifier and restores the running state of that Wasm execution context. The restored Wasm execution context takes over the current device session again and puts the deterministic finite state automaton into either an abnormal re-authentication state or an authentication initialization state.

[0064] A continuous access management link is formed between the access pre-inspection module, cloud construction module, sandbox authentication module, and migration rollback module. The access pre-inspection module completes the initial sampling and session documentation of unknown devices at the edge; the cloud construction module generates device-specific access logic and determines the scheduling strategy in the cloud; the sandbox authentication module performs full authentication and steady-state determination in the edge user space; and the migration rollback module migrates the packet processing logic to the kernel space for execution during the steady-state phase and restores the user-space authentication process in case of anomalies.

[0065] Through the collaboration of the access pre-inspection module, cloud construction module, sandbox authentication module, and migration rollback module, heterogeneous IoT devices undergo lightweight pre-inspection at the edge during the initial access phase. During the authentication phase, the user-space Wasm execution context completes protocol parsing and identity authentication. In the steady-state transmission and reception phase, the kernel-space eBPF program processes fixed-structure service messages. In the abnormal phase, the Ring Buffer triggers the user-space Wasm execution context to recover. Thus, the protocol processing logic can be scheduled among the cloud, edge user space, and edge kernel space according to the device access status.

[0066] See Figure 2 This invention provides a method for managing IoT device access in a cloud-edge collaborative manner, comprising the following steps: S100: When a heterogeneous IoT device initiates a connection request, the access pre-inspection module collects the data packets in the early stage of device access, extracts device access characteristics, generates a device access feature vector, and establishes a device session identifier. The S200 and cloud-based construction modules match candidate protocols based on device access feature vectors, determine the identity authentication process and message parsing rules, construct the deterministic finite state automaton corresponding to the device, and generate the corresponding Wasm bytecode. S300 and cloud construction modules determine migration costs and, when edge execution conditions are met, send Wasm bytecode and related access parameters to the sandbox authentication module. The sandbox authentication module then performs device authentication, protocol parsing, and entropy gradient monitoring in the user-mode Wasm execution context. When the S400 and sandbox authentication modules determine that the device session has entered the steady-state transmission and reception stage, they output steady-state migration trigger information to the migration rollback module. The migration rollback module folds the steady-state packet processing logic into a lightweight rule set, compiles it into an eBPF program, and then attaches it to the XDP hook, so that the steady-state service packets are transferred to kernel mode processing. The S500 migration rollback module performs anomaly detection during the eBPF program's processing of steady-state service messages. When an anomaly is detected, it reports the anomaly event through a ring buffer. The user-space daemon wakes up the suspended Wasm execution context, causing the current device session to re-enter the authentication process.

[0067] The following, in conjunction with the accompanying drawings and specific data processing procedures, further explains the device access feature sampling, automatic mechanism construction, edge authentication execution, steady-state migration, and abnormal rollback processes involved in steps S100 to S500.

[0068] See Figure 3 When a heterogeneous IoT device initiates access, the access pre-inspection module performs lightweight sampling of the initial data packets to generate a device access feature vector and establishes a device session identifier that runs through the subsequent processing.

[0069] S101. The access pre-inspection module listens for new connection requests at the edge-side network interface and, when it captures data packets from heterogeneous IoT devices, reads the source address information, destination address information, transport layer protocol type, and access port information from the data packets.

[0070] For TCP-based data streams, the access pre-inspection module uses the connection establishment message or the first data packet carrying a payload as the sampling starting point. For UDP-based data streams, the access pre-inspection module uses combinations of data packets from the same source address, destination address, and access port as the sampling objects.

[0071] The access pre-inspection module determines whether the current data packet belongs to a registered device session based on the source address, destination address, transport layer protocol type, and access port information. If the current data packet does not match a registered device session, the access pre-inspection module establishes a temporary session record for the current access and marks the current access stage as an unknown access stage. The temporary session record is used to store sampled data, access characteristics, and the access processing logic version returned by the cloud later.

[0072] S102. The access pre-detection module samples the data packets during the initial access phase of the current device. The sampling object is a number of data packets that arrive continuously after the device access begins. Let... For the current device, The number of sampled data packets, For the first One sampled data packet, For the first The payload of each sampled data packet, of which .

[0073] The access pre-inspection module extracts the payload, message length, message direction, and arrival time from each sampled data packet. The message direction indicates whether the current sampled data packet was sent from the current device to the edge side or from the edge side to the current device. The arrival time is provided by the edge computing gateway's system clock or network interface timestamp.

[0074] The access pre-detection module concatenates the payloads of each sampled data packet into a sampled payload sequence according to their arrival order. The sampled payload sequence is represented as follows: ; in, The sampled payload sequence; They are respectively the 1st to the 1st The payload of each sampled data packet; This is the payload concatenation operator, which indicates that multiple payloads are joined into a single byte sequence according to the order in which the data packets arrive.

[0075] When the payload of a sampled data packet is empty, the access pre-inspection module retains the packet length, direction, and arrival time of the sampled data packet, and does not add empty payload bytes to the sampled payload sequence. This processing method is used to accommodate access scenarios where control messages exist during the connection establishment phase but the payload is insufficient.

[0076] S103. The access pre-inspection module extracts device access characteristics based on the sampled data. Device access characteristics include initial information entropy, message length sequence, message direction sequence, arrival time interval sequence, and payload summary.

[0077] set up It is a byte value; Byte value In the sampled load sequence The number of times it appears in; For sampling payload sequence byte length; The initial information entropy. When the sampled payload sequence When the byte length is greater than 0, the initial information entropy is: ; in, The initial information entropy; It is a byte value; Byte value In the sampled load sequence The number of times it appears in; For sampling payload sequence byte length; This is a base-2 logarithmic operation. When When the summation term is zero, the corresponding term is recorded as 0.

[0078] When sampling load sequence When the byte length is equal to 0, the access pre-inspection module records the initial information entropy as a null value and retains the message length sequence, message direction sequence and arrival time interval sequence as part of the device access characteristics.

[0079] set up For the first The message length of each sampled data packet, For the first The message direction of each sampled data packet. For the first The arrival times of the sampled data packets, among which ;set up For the first Arrival time interval, ,in ;set up For the current device The payload summary is obtained by the access pre-detection module, which extracts a predetermined length of byte segments from the sampled payload sequence or performs a summary operation on the sampled payload sequence to obtain the current device's payload summary. Load summary .

[0080] S104. The access pre-detection module generates a device access feature vector based on the extracted device access features. Let... For the current device The device access feature vector, the current device The device access feature vector is represented as: ; in, For the current device The device access feature vector; The initial information entropy; They are respectively the 1st to the 1st The message length of each sampled data packet; They are respectively the 1st to the 1st The message direction of each sampled data packet; They are respectively the 1st to the 1st Arrival time interval; For the current device Load summary.

[0081] Device access feature vectors are used to provide the cloud-based building modules with the input information required for protocol matching and access logic generation. Initial information entropy is used to characterize the byte distribution characteristics of the sampled payload sequence; message length sequence is used to characterize the length variation pattern of messages in the early stages of access; message direction sequence is used to characterize the interaction direction between the device and the edge side; arrival time interval sequence is used to characterize the arrival rhythm of messages in the early stages of access; and payload summary is used to provide a compressed representation of the sampled payload.

[0082] The access pre-inspection module does not use the initial information entropy as the sole basis for protocol identification. Instead, it combines the initial information entropy with the message length sequence, message direction sequence, arrival time interval sequence, and payload digest to form a device access feature vector, which is then used by the cloud-based construction module for comprehensive matching.

[0083] S105. The access pre-inspection module establishes a device session identifier for the current device and associates the device session identifier with the device access feature vector. The device session identifier is generated based on the current device's address information, access port, transport layer protocol type, and the arrival time of the first sampled data packet. The generation of the device session identifier can be implemented using a hash digest method.

[0084] The access pre-detection module establishes a session state record, which includes the device session identifier, device access feature vector, address information, access port, transport layer protocol type, and current access stage. The current access stage remains unknown after sampling is completed until the cloud-based construction module returns the corresponding protocol processing logic and authentication parameters.

[0085] The access pre-inspection module encapsulates the current device's device session identifier, device access feature vector, and payload digest into a feature request and sends the feature request to the cloud construction module. Upon receiving the feature request, the cloud construction module performs candidate protocol matching, deterministic finite state automaton construction, and Wasm bytecode generation based on the device access feature vector. TCP connection establishment, UDP packet reception, packet capture at the network interface, and hash digest generation are well-known technologies in the field and will not be elaborated upon here.

[0086] Reference Figure 4 After receiving the feature request, the cloud-based construction module determines the device protocol range based on the device access feature vector and generates protocol parsing and authentication logic that can be executed on the edge side. This process maps access features, protocol features, authentication procedures, and automaton states, providing clear state transition criteria for subsequent edge-side execution.

[0087] S201, Cloud construction module reads the current device Device access feature vector The system then performs protocol feature matching within the global protocol feature library. This library stores multiple protocol templates, each including an initial entropy range, message length pattern, message direction pattern, arrival time interval pattern, fixed field summary, and steady-state message structure.

[0088] set up For the protocol template number, For the first Protocol matching score for each protocol template. For the first The initial information entropy matching score of each protocol template. For the first The message length sequence matching score of each protocol template. For the first The message direction sequence matching score of each protocol template. For the first The arrival time interval sequence matching score of each protocol template. For the first The payload summary matching score of each protocol template. The protocol matching score for each protocol template is represented as follows: ; in, For the first Protocol matching score for each protocol template; For the first The initial information entropy matching score of each protocol template; For the first The message length sequence matching score of each protocol template; For the first The message direction sequence matching score of each protocol template; For the first The arrival time interval sequence matching score of each protocol template; For the first Payload summary matching score for each protocol template; Match weights to the initial information entropy; Weights are matched to the message length sequence; Weights are matched to the message direction sequence; Weights are matched to the arrival time interval sequence; Weights are matched to the payload summary.

[0089] Initial information entropy matching score From the current device The initial information entropy and the first The initial information entropy range recorded in each protocol template is compared to obtain the message length sequence matching score. From the current device The message length sequence and the first The length pattern is compared among the protocol templates to obtain the message direction sequence matching score. From the current device The message direction sequence and the first The arrival time interval sequence matching score is obtained by comparing the directional patterns in each protocol template. From the current device The arrival time interval sequence and the first The payload summary matching score is obtained by comparing time interval patterns in each protocol template. From the current device The load summary and the first The results are obtained by comparing the summaries of fixed fields in each protocol template.

[0090] The cloud-based construction module uses protocol templates that achieve a protocol matching score that reaches the protocol matching threshold as candidate protocols, and uses these candidate protocols as input for subsequent identity authentication processes and automatic mechanism construction. When no protocol template meets the protocol matching threshold, the cloud-based construction module returns a supplementary sampling instruction to the access pre-inspection module. The access pre-inspection module then increases the number of sampled data packets and regenerates the device access feature vector.

[0091] S202, The cloud-based construction module reads the device authentication process library according to the candidate protocol and determines the current device. The corresponding identity authentication process. The device authentication process library stores the identity identification reading rules, authentication initiation messages, key exchange methods, credential verification methods, authorization confirmation methods, and authentication failure handling methods for different protocols.

[0092] The cloud-based construction module reads the corresponding authentication process records for each candidate protocol. These records include the authentication entry status, authentication interaction message type, authentication input fields, authentication output fields, credential verification rules, and authentication result branches. The authentication entry status indicates the initial state of the device session entering the identity authentication process; the authentication interaction message type indicates the message categories that need to be identified during authentication; the authentication input fields represent the identity identifier, random number, certificate data, and signature data read from the device messages; and the authentication output fields represent the authentication challenge, key exchange data, and authorization confirmation data returned to the device from the edge or cloud.

[0093] When multiple candidate protocols exist, the cloud-based construction module determines the priority protocol template based on the protocol matching score and retains the protocol probing branches corresponding to the remaining candidate protocols. These protocol probing branches are used to confirm the protocol based on the message type field or fixed field match results when subsequent messages are received at the edge. The protocol probing branches are generated by mapping the message entry rules of multiple candidate protocols to different input events, enabling the edge to enter the corresponding authentication process based on the actual message content.

[0094] S203, the cloud-based construction module constructs the device according to protocol parsing rules and identity authentication processes. The corresponding deterministic finite state automaton. Let... For the current device The corresponding deterministic finite state automaton, For a set of states, For the set of input events, This is the state transition function. This is the initial state. Let be the set of terminating states. A deterministic finite automaton is represented as: ; in, For the current device The corresponding deterministic finite state automaton; A set of states; For the set of input events; This is the state transition function; This is the initial state; This is the set of terminating states.

[0095] State set This includes unknown access status, protocol probe status, identity authentication initialization status, key exchange status, credential verification status, authorization confirmation status, steady-state transmission and reception status, abnormal re-authentication status, and session termination status. Input event set. These include sampling completion events, protocol hit events, authentication initiation events, key exchange successful events, credential verification successful events, authorization confirmation successful events, authentication failure events, steady-state message hit events, and exception triggering events.

[0096] State transition function Used to describe the correspondence between the current state and input events. The current state is... And the input event is At that time, the next state Represented as: ; in, The next state; This is the state transition function; This is the current state; This is an input event.

[0097] The cloud-based construction module maps protocol parsing rules to input event generation rules, authentication processes to state transition relationships, and steady-state message structures to message processing rules under steady-state transmission and reception. Therefore, the deterministic finite state automaton can represent the current device... The processing path from unknown access, protocol confirmation, identity authentication, authorization confirmation to steady-state transmission and reception can also express the processing paths corresponding to authentication failure, message abnormality and session termination.

[0098] S204, Cloud-based construction module for deterministic finite state automata Perform trimming and generate Wasm bytecode based on the trimming results. The trimming process retains the states required for protocol probing, authentication, authorization confirmation, steady-state transmission and reception, abnormal re-authentication, and session termination; it deletes protocol parsing, authentication, and message processing states that are irrelevant to the current candidate protocol.

[0099] The cloud-based building blocks retain their initial state during the trimming process. Retain reachable paths to steady-state transmit / receive states, abnormal paths from authentication-related states to abnormal re-authentication states, and failed paths from abnormal re-authentication states to session termination states. States and state transition relationships not on reachable, abnormal, or failed paths are not written into the pruned deterministic finite automaton.

[0100] set up For the trimmed deterministic finite state automaton, For the current device The set of protocol parsing rules, For the current device A set of identity authentication rules For the current device A set of steady-state message templates, For the current device The corresponding Wasm bytecode. The cloud build module will... , , and Compiled to Wasm bytecode, it is represented as: ; in, For the current device The corresponding Wasm bytecode; For bytecode compilation operations; For the trimmed deterministic finite state automaton; For the current device A set of protocol parsing rules; For the current device A set of identity authentication rules; For the current device A collection of steady-state message templates.

[0101] The bytecode compilation operation converts state transition functions into executable state branch logic, protocol parsing rules into message field reading and verification logic, authentication rules into authentication interaction and credential verification logic, and steady-state message templates into steady-state stage field extraction and structure verification logic.

[0102] S205, Cloud Builder Generation and Wasm Bytecode The corresponding access parameters are used as input data for subsequent migration cost determination and edge-side execution. These access parameters include the automaton description file, authentication parameters, steady-state rule templates, protocol matching results, and bytecode version information.

[0103] The automaton description file includes a pruned set of states, a pruned set of input events, a pruned set of state transition functions, an initial state, and a pruned set of final states. Authentication parameters include the position of the identity field, key exchange parameters, credential verification rules, authorization confirmation rules, and authentication failure handling rules. The steady-state rule template includes the steady-state message length range, fixed field positions, business field offsets, business field lengths, field verification rules, and exception triggering conditions.

[0104] The cloud-based build module will connect the current device Device session identifier, Wasm bytecode The system associates the automaton description file, authentication parameters, steady-state rule templates, protocol matching results, and bytecode version information to form the current device configuration. The access logic package is used to participate in migration cost determination in subsequent steps and is issued to the sandbox authentication module when the edge execution conditions are met. Sequence similarity comparison, field digest comparison, threshold matching, Wasm bytecode generation, and runtime interface adaptation are well-known technologies in this field and will not be elaborated here.

[0105] See Figure 5 After the cloud-based construction module generates the access logic package for the current device, it determines whether the access logic is suitable for execution in the cloud or migrated to the edge. After the migration determination is completed, the edge uses the user-space Wasm execution context to handle protocol parsing and authentication, and simultaneously monitors changes in the data stream.

[0106] S301, the cloud construction module calculates the edge execution cost based on the access logic package and the current running state. The edge execution cost is used to characterize the resource overhead incurred when Wasm bytecode is sent to the edge and run in the user-space sandbox.

[0107] set up For edge execution cost, Wasm bytecode bytecode size, Memory footprint for the Wasm execution context The time required to initialize the context for Wasm This represents the resource utilization rate on the edge side. The edge execution cost is expressed as: ; in, Cost of edge execution; Wasm bytecode bytecode size; Memory footprint for the Wasm execution context; The time taken to initialize the Wasm context; This refers to the resource utilization rate on the edge side. Bytecode volume weight; Memory usage weight; Initialize the time consumption weights; This represents the weight of resource occupancy on the edge side.

[0108] Edge-side resource utilization The utilization rates are determined based on edge-side processor utilization, memory utilization, and network queue utilization. These rates are provided by the edge computing gateway's operating system monitoring interface.

[0109] S302, the cloud-based construction module calculates the remote resolution cost and makes a migration decision based on the edge execution cost and the remote resolution cost. The remote resolution cost is used to characterize the processing overhead incurred when the original message from the device continues to be sent to the cloud and the cloud performs protocol parsing and authentication.

[0110] set up For the cost of remote resolution, This refers to the amount of data remotely forwarded from the original message. For cloud-edge link round-trip latency, For cloud-based load balancing, This represents the quality loss value of the cloud-edge link. The remote resolution cost is expressed as: ; in, Cost of remote resolution; This refers to the amount of data remotely forwarded from the original message. For cloud-edge link round-trip latency; Analyze the load in the cloud; This represents the quality loss value of the cloud-edge link. Weighting of the amount of data remotely forwarded from the original message; Weights for round-trip latency of cloud-edge links; Analyze load weights in the cloud; This represents the weight of the cloud-edge link quality loss value.

[0111] Raw message remote forwarding data volume Determined based on the cumulative message length generated by the current device session within a unit of time; cloud-edge link round-trip latency. Determined based on the round-trip time of probe messages between the cloud-based construction module and the edge; cloud-based parsing load. Determined based on task queue and processor usage status parsed from cloud protocols; cloud-edge link quality loss value. Determined based on packet loss rate, retransmission rate, or link jitter value.

[0112] set up Migration margin is determined. The cloud-based construction module determines the current device when the following formula is satisfied. The access logic is migrated to the edge for execution: ; in, Cost of edge execution; For migration decision margin; This represents the cost of remote resolution. The migration decision margin is used to avoid frequent switching when the edge execution cost and the remote resolution cost are close.

[0113] If this condition is not met, the cloud-based construction module will maintain the current device. The remote parsing and processing method is used, and a command to continue sampling or remotely forward is returned to the access pre-detection module.

[0114] S303, Cloud Construction Module determines the current device After the access logic is migrated to the edge for execution, the access logic package is distributed to the sandbox authentication module. The access logic package includes the current device... Device session identifier, Wasm bytecode The automaton description file, authentication parameters, steady-state rule templates, protocol matching results, and bytecode version information are included.

[0115] When the cloud-based construction module distributes the access logic package, it uses the device session identifier as a session association field on the edge side, enabling the sandbox authentication module to correlate the access logic package with the session state record established by the access pre-inspection module. Bytecode version information is used to identify the current Wasm bytecode. The corresponding protocol rule version and authentication process version facilitate consistency verification during subsequent steady-state migration and abnormal rollback.

[0116] S304. After receiving the access logic packet, the sandbox authentication module creates a Wasm execution context in the user-space environment on the edge side and binds the Wasm execution context to the device session identifier.

[0117] Sandbox authentication module loads Wasm bytecode It allocates linear memory, a runtime stack, imported function interfaces, and a session buffer for the Wasm execution context. The imported function interfaces provide the Wasm execution context with functions for reading packets, sending packets, reading time, reading session state, writing session state, and writing entropy statistics results.

[0118] The sandbox authentication module recovers the trimmed deterministic finite-state automaton based on the automaton description file. The sandbox authentication module sets the current device session state to the initial state. It writes the device session identifier, Wasm execution context index, bytecode version information, and current state into the session state record, enabling the access pre-inspection module, sandbox authentication module, and migration rollback module to associate states based on the same device session identifier.

[0119] S305, the sandbox authentication module performs protocol parsing and identity authentication in the Wasm execution context, and continuously calculates the data stream entropy gradient during device authentication and service transmission and reception.

[0120] set up For state processing rounds, For the first Each state processing round corresponds to the current state. For the first Each state handles the input event corresponding to a given round. For the first The next state corresponds to each state processing round. The sandbox authentication module executes state transitions according to the trimmed state transition function, represented as: ; in, For the first The next state corresponding to each state processing round; This is the state transition function; For the first Each state processing round corresponds to the current state; For the first Each state handles the input event corresponding to a given round.

[0121] Input Events It is generated based on the message type of the currently received message, field verification results, key exchange results, credential verification results, authorization confirmation results, or anomaly detection results. The sandbox authentication module is based on input events. Call Wasm bytecode The protocol parsing logic, identity authentication logic, and message processing logic are included.

[0122] During the authentication phase, the sandbox authentication module reads the device identity identifier through the Wasm execution context and performs authentication initiation message parsing, key exchange data processing, credential verification, and authorization confirmation. During protocol parsing and authentication, the sandbox authentication module uses a sliding window to analyze the current device. The data stream load is statistically analyzed.

[0123] set up Number the sliding window. For the first Information entropy within a sliding window For the first The entropy gradient corresponding to each sliding window The length of the sliding window. The entropy gradient corresponding to each sliding window is expressed as: ; in, For the first The entropy gradient corresponding to each sliding window; For the first Information entropy within a sliding window; For the first Information entropy within a sliding window; This represents the length of the sliding window.

[0124] The sandbox authentication module will assign the entropy gradient to each sliding window. Write the session state record and the entropy gradient Compared with the current state Association. The association result is used to subsequently determine whether the current device session has completed authentication and entered the steady-state transmission and reception stage, and is also used to determine the steady-state baseline when the migration and rollback module generates kernel-state steady-state processing rules. Resource monitoring, link detection, secure transmission, Wasm module instantiation, key exchange, digital signature verification, and certificate chain verification are well-known technologies in this field and will not be elaborated here.

[0125] Reference Figure 6 After device authentication is completed, the sandbox authentication module determines whether the device session has entered the fixed structure business message sending and receiving stage based on the automaton state and data flow entropy gradient. When the migration conditions are met, the steady-state message processing logic is handed over to the migration rollback module to be converted into a kernel-mode executable program.

[0126] S401 The sandbox authentication module determines whether the current device session has entered the steady-state transmission and reception phase based on the current state of the deterministic finite state automaton and the entropy gradient change within the continuous sliding window.

[0127] The sandbox authentication module reads the automaton state of the current device session at the end of each sliding window and determines whether the current automaton state is in a steady-state transmit / receive state. If the current automaton state has not entered a steady-state transmit / receive state, the sandbox authentication module continues to perform protocol parsing and authentication in the user-space Wasm execution context.

[0128] When the current automaton is in a steady-state transmit / receive state, the sandbox authentication module reads the entropy gradients corresponding to the most recent consecutive sliding windows and compares the entropy gradient of each sliding window with the entropy gradient threshold. If the entropy gradients corresponding to the most recent consecutive sliding windows are all lower than the entropy gradient threshold, the sandbox authentication module determines that the current device session has entered the steady-state transmit / receive stage and generates steady-state transition trigger information.

[0129] If the current automaton is in a steady-state transmit / receive state, but there is at least one entropy gradient that is not lower than the entropy gradient threshold in the most recent consecutive sliding windows, the sandbox authentication module continues to process the current device session by the user-state Wasm execution context and continues to update the automaton state and entropy gradient monitoring results.

[0130] By using both the automaton state and the entropy gradient of the continuous sliding window as steady-state judgment conditions, the sandbox authentication module can distinguish between data flow changes during the identity authentication phase and data flow changes during the steady-state business phase, avoiding triggering execution space migration based solely on a single message or a single entropy value change.

[0131] S402. When the sandbox authentication module determines that the current device session has entered the steady-state transmission and reception phase, it outputs steady-state migration trigger information to the migration rollback module. The steady-state migration trigger information is used by the migration rollback module to determine the device session to be migrated, the current automaton state, and the steady-state message processing content that can be migrated.

[0132] The steady-state migration trigger information includes the device session identifier, current automaton state, steady-state message template, steady-state parsing subgraph index, and entropy gradient monitoring results. The sandbox authentication module writes the steady-state migration trigger information into the session state record and sends it to the migration rollback module. The migration rollback module reads the corresponding Wasm execution context, automaton description file, and steady-state message template based on the device session identifier and prepares to extract the steady-state message processing logic.

[0133] S403, The migration rollback module, based on the steady-state migration trigger information, starts from the trimmed deterministic finite state automaton. Extract the steady-state parse subgraph corresponding to the steady-state transmit and receive states. The steady-state parse subgraph is used to represent the processing logic of fixed-structure business messages after authentication.

[0134] The steady-state parse subgraph includes steady-state transmit / receive states and states related to fixed-structure service message processing. Input events in the steady-state parse subgraph include steady-state message hit events, message length validation pass events, fixed field matching pass events, service field extraction events, and steady-state rule mismatch events. State transition relationships in the steady-state parse subgraph include those triggered by steady-state input events.

[0135] When extracting the steady-state parsing subgraph, the migration rollback module only retains the fixed-structure business message processing logic after authentication. This fixed-structure business message processing logic includes message length verification, fixed field matching, business field offset reading, business field length reading, session identifier matching, and basic processing actions. Complex identity authentication, key exchange, certificate chain verification, and non-fixed-length message reassembly are not included in the steady-state parsing subgraph.

[0136] S404, the migration rollback module folds the steady-state parsing subgraph into a lightweight rule set and compiles the lightweight rule set into an eBPF program. The lightweight rule set is used to perform fast matching and field extraction of fixed-structure messages in kernel mode.

[0137] set up For the current device A lightweight rule set, For the first Lightweight rules, For the current device The number of lightweight rules. Lightweight rule set. Represented as: ; in, For the current device A lightweight rule set; For the first Lightweighting rules; Number the lightweight rule; For the current device The number of lightweight rules; This indicates a set construction relation that satisfies the subsequent condition.

[0138] No. Lightweighting rules Represented as: ; in, For the first Lightweighting rules; For the first The starting offset of the field in the lightweight rule; For the first The field length of each lightweight rule; For the first The field mask for each lightweight rule; For the first The expected field values ​​for each lightweight rule; For the first The processing actions of the lightweight rule.

[0139] The migration rollback module transforms the packet length verification logic in the steady-state parsing subgraph into field length constraints, the fixed field matching logic into field masks and expected field values, the business field extraction logic into field start offsets and field lengths, and the allow, drop, redirect, count statistics, and exception reporting into processing actions. Through this transformation, the steady-state packet processing logic in the user-space Wasm execution context is represented as a lightweight rule set executable in kernel space. .

[0140] For the current data packet to be processed, the eBPF program reads the corresponding fields from the data packet according to the field start offset and field length in each lightweight rule; then it performs bitwise AND processing on the read fields according to the field mask, and compares the processing result with the expected field value. If the comparison results for all required rules are consistent, the current data packet to be processed satisfies the steady-state rule; if the comparison results for any required rule are inconsistent, the current data packet to be processed does not satisfy the steady-state rule.

[0141] The migration rollback module generates a lightweight rule set. When doing so, the rules are restricted to fixed offset access, fixed-length field extraction, finite branch judgment, and bounded loop processing.

[0142] S405, the migration rollback module will be based on a lightweight rule set. The generated eBPF program is attached to the XDP hook, and after successful attachment, the corresponding Wasm execution context is put into a suspended state.

[0143] Before mounting the eBPF application, the migration rollback module will set the device session identifier and lightweight rule set. The entropy gradient monitoring results, bytecode version information, and the current state of the automaton are written to the kernel-mode mapping table. The kernel-mode mapping table is used by eBPF programs to query the rules and states corresponding to the current device session when processing steady-state service messages.

[0144] After the eBPF program passes kernel verification, the migration and rollback module mounts the eBPF program to the XDP hook, so that the eBPF program performs length verification, field matching, field extraction and processing actions on the steady-state service packets entering the network protocol stack.

[0145] After the eBPF application is successfully mounted, the migration rollback module sends a suspend command to the sandbox authentication module. The sandbox authentication module will then suspend the current device... The corresponding Wasm execution context is placed in a suspended state, retaining the device session identifier, authentication result digest, current state, steady-state parsing subgraph index, bytecode version information, and context recovery index. When the Wasm execution context is in a suspended state, it no longer processes the current device. The system handles steady-state service messages, but retains the context data required to restore the complete protocol parsing and authentication process. eBPF program loading, kernel verification, kernel-mode mapping table creation, XDP hook mounting, and eBPF program unloading are well-known technologies in the field and will not be elaborated upon here.

[0146] Reference Figure 7 After steady-state service packets are transferred to kernel mode for processing, the migration and rollback module retains its anomaly detection and rollback capabilities. The kernel-mode eBPF program processes packets conforming to steady-state rules, while the user-mode daemon receives exception events and resumes suspended Wasm execution contexts.

[0147] S501, the migration rollback module processes the current device through the eBPF program attached to the XDP hook. The eBPF program receives the current pending data packet and reads the lightweight rule set associated with the device session identifier from the kernel-mode mapping table. eBPF programs are based on a lightweight rule set. Perform message length verification, fixed field matching, business field extraction, session identifier matching, and processing action selection on the current data packet to be processed.

[0148] The current data packet to be processed satisfies the steady-state rule, meaning that the data packet passes through the current device. The corresponding message length verification, session identifier matching, and field matching of all required lightweight rules are performed. A packet to be processed that does not meet the steady-state rules means that the packet failed message length verification, session identifier matching, or field matching of any required lightweight rule.

[0149] When the current data packet to be processed meets the steady-state rules, the eBPF program performs actions such as allowing, dropping, redirecting, counting, or outputting fields according to the processing actions configured in the lightweight rule set.

[0150] S502. The migration rollback module detects entropy feature jumps, steady-state rule mismatches, and session state anomalies during eBPF program execution. When any of the abnormal conditions is met, the migration rollback module marks the current device session as pending rollback.

[0151] For entropy feature jump detection, the eBPF program performs lightweight statistics on the packet payload within the current detection window. Let... For the first Approximate information entropy within a sliding window, For steady-state baseline information entropy, This is the entropy jump threshold. The eBPF program in... When the current data packet to be processed is detected, it is determined that there is an entropy feature jump in the detection window.

[0152] Approximate information entropy The values ​​are obtained by the eBPF program based on byte frequency statistics, fixed-point arithmetic, or table lookup. Because the eBPF program runs in kernel mode and is subject to kernel verification constraints, floating-point operations and unbounded loops are not written into the eBPF program.

[0153] For steady-state rule mismatch detection, the eBPF program determines that there is a steady-state rule mismatch in the current data packet to be processed if the packet length check, session identifier matching, or field matching of any required lightweight rule is not passed.

[0154] For session state anomaly detection, if the eBPF program cannot find the current device session identifier in the kernel-mode mapping table, or if the rule version corresponding to the current device session identifier is inconsistent with the packet processing path, it determines that the current packet to be processed has a session state anomaly.

[0155] When any of the following anomalies is triggered: entropy feature jump, steady-state rule mismatch, or session state anomaly, the eBPF program generates a comprehensive anomaly flag and marks the current device session as pending rollback.

[0156] S503, the migration rollback module reports abnormal events to the user-space daemon via a Ring Buffer when entropy characteristic jumps, steady-state rule mismatches, or session state anomalies are triggered. The Ring Buffer is used to transfer event data generated by kernel-space eBPF programs to the user-space daemon.

[0157] An abnormal event includes a device session identifier, the time of occurrence, the type of abnormality, the triggering rule number, the steady-state rule version, and the abnormal payload summary. The abnormal type is determined based on the triggering source among entropy feature jumps, steady-state rule mismatches, and session state anomalies. The triggering rule number records the rule number that failed to match during a steady-state rule mismatch; when triggered by an entropy feature jump or a session state anomaly, the triggering rule number is recorded as a preset abnormal number. The abnormal payload summary is derived from the currently pending data packet. The kernel-mode data packet pointer is not passed to user space and is generated from the predetermined byte fragment or digest operation result.

[0158] S504. After receiving an abnormal event, the user-mode daemon queries the session state record based on the device session identifier in the abnormal event and determines the Wasm execution context associated with the device session identifier.

[0159] When the Wasm execution context corresponding to the current device exists in the suspended context set, the user-space daemon reads the device session identifier, authentication result digest, current state, steady-state parsing subgraph index, bytecode version information and context recovery index stored in the Wasm execution context, and restores the Wasm execution context to the running state.

[0160] When the Wasm execution context corresponding to the current device does not exist in the suspended context set, the user-space daemon sends a re-archiving instruction to the access pre-inspection module and writes the exception event into the exception log. The re-archiving instruction is used to make the access pre-inspection module re-collect the access data packets of the current device and re-trigger the cloud construction module to generate access logic packets.

[0161] After the S505 and Wasm execution contexts are restored to running state, the sandbox authentication module causes the current device session to re-enter the authentication process. The sandbox authentication module, based on the exception type in the abnormal event, modifies the tailored deterministic finite state automaton. Switch to abnormal re-authentication state or identity authentication initialization state.

[0162] When the entropy feature corresponding to the anomaly type changes abruptly or the steady-state rule mismatch occurs, the sandbox authentication module will switch the current state to the anomaly re-authentication state, retain the device session identifier, bytecode version information and authentication result summary of the current device, and re-execute the credential verification, authorization confirmation and steady-state judgment process.

[0163] When the exception type corresponds to an abnormal session state, device reconnection, or missing authentication context, the sandbox authentication module will switch the current state to the identity authentication initialization state, clear the current device's authentication result summary and steady-state rule version, and re-execute the identity identifier reading, key exchange, credential verification, and authorization confirmation process.

[0164] After the restored Wasm execution context takes over the current device session again, the migration rollback module stops the eBPF steady-state processing path corresponding to the current device, or marks the lightweight rule set corresponding to the current device as paused from the kernel-state mapping table. When re-authentication is successful, the sandbox authentication module continues to determine whether the current device session should re-enter the steady-state transmit / receive phase based on the automaton state and entropy gradient changes; when re-authentication fails, the sandbox authentication module switches the current device session to the session termination state and reports the authentication failure result to the cloud construction module. Ring buffer event propagation, user-state event reading, eBPF mapping table access, fixed-point arithmetic, table lookup operations, allowing, discarding, redirecting, and counting statistics are well-known technologies in this field and will not be elaborated upon here.

[0165] To better understand the technical solution of this invention, the invention will be further described in detail below with reference to specific application scenarios and accompanying drawings. This specific application embodiment is built on a cloud-edge collaborative IoT access management system for warehouse environment monitoring equipment. The system runs on the edge computing gateway at the warehouse site and the centralized cloud management platform, and is responsible for acquiring temperature, humidity and equipment status messages, and performing access pre-inspection, protocol matching, identity authentication, steady-state migration and anomaly fallback closed loop.

[0166] During the access pre-detection phase, the access pre-detection module extracts 16 consecutive data packets arriving from heterogeneous IoT devices in the initial access phase, generating a sampling payload sequence, message length sequence, message direction sequence, and arrival time interval sequence, and calculates the initial information entropy to be 6.92. The cloud-based construction module matches candidate protocols in the global protocol feature library based on the device access feature vectors and constructs a deterministic finite state automaton. This deterministic finite state automaton includes unknown access state, protocol probing state, authentication initialization state, key exchange state, credential verification state, authorization confirmation state, steady-state transmission and reception state, abnormal re-authentication state, and session termination state.

[0167] During the migration cost determination phase, the cloud-based construction module calculates the edge execution cost. The parameters are set as follows: Wasm bytecode size is 480KB, Wasm execution context memory usage is 24MB, Wasm execution context initialization time is 18ms, and edge-side resource utilization is 0.42; bytecode size weight is 0.002, memory usage weight is 0.15, initialization time weight is 0.08, and edge-side resource utilization weight is 3.00. The cloud-based construction module substitutes these values ​​into the formula to calculate the edge execution cost: ; Substitute the values ​​into the calculation: ; The results show that the edge execution cost obtained by the system is 7.26.

[0168] The cloud-based construction module further calculates the remote resolution cost. The parameters are set as follows: the original packet remote forwarding data volume is 1800KB, the cloud-edge link round-trip latency is 38ms, the cloud resolution load is 0.61, and the cloud-edge link quality loss value is 0.18; the weights for the original packet remote forwarding data volume are 0.004, the cloud-edge link round-trip latency weight is 0.10, the cloud resolution load weight is 4.00, and the cloud-edge link quality loss value weight is 5.00. The cloud-based construction module substitutes these values ​​into the formula to calculate the remote resolution cost: ; Substitute the values ​​into the calculation: ; The results show that the remote resolution cost obtained by the system is 14.34. The migration decision margin is set to 0.80, and the cloud-based construction module uses the formula to determine edge execution: ; Substitute the values ​​into the calculation: ; Since the calculation results meet the judgment conditions, the cloud construction module determines that the current device access logic will be migrated to the edge side for execution, and sends the Wasm bytecode, automaton description file, authentication parameters and steady-state rule template to the sandbox authentication module.

[0169] During the steady-state determination phase, the sandbox authentication module performs identity authentication and protocol parsing within the Wasm execution context, and calculates the entropy gradient by combining the information entropy of the sliding window. The parameters are set as follows: the sliding window length is 2, the information entropy in the 24th sliding window is 4.86, the information entropy in the 25th sliding window is 5.28, and the information entropy in the 26th sliding window is 5.86. The sandbox authentication module substitutes these parameters into the formula to calculate the entropy gradient: ; Substitute the values ​​into the calculation: ; ; The results show that the entropy gradient corresponding to the 25th sliding window is 0.21, and the entropy gradient corresponding to the 26th sliding window is 0.29. The preset entropy gradient threshold is 0.08. Since the calculated entropy gradient is greater than the entropy gradient threshold, the migration rollback module determines that there is an entropy feature jump in the current device session and reports the abnormal event through the circular buffer. The user-space daemon process restores the suspended Wasm execution context according to the device session identifier.

[0170] During the steady-state service message processing phase, the migration rollback module extracts a steady-state parsing subgraph based on the steady-state migration trigger information. It then folds the message length verification logic, fixed field matching logic, and service field extraction logic within the steady-state parsing subgraph into a lightweight rule set, which is compiled into an eBPF program. After the eBPF program is attached to the XDP hook, it performs message length verification, fixed field matching, service field extraction, and processing action selection on the steady-state service messages.

[0171] To verify the accuracy and stability of the response strategy, which includes steady-state transition and abnormal rollback mechanisms, during system operation, the system compared and output the logarithmic amplitude spectrum data of the loads of steady-state service messages and abnormal service messages under the same experimental environment.

[0172] like Figure 8 As shown, Figure 8 The horizontal axis represents frequency, and the vertical axis represents log-normalized amplitude. In the figure, steady-state service packets form a main peak around 43Hz, with secondary peaks around 92Hz and 140Hz, indicating that authenticated service packets have concentrated frequency components. Abnormal service packets form a main peak around 47Hz, with additional peaks around 170Hz, 260Hz, and 330Hz. This result shows that abnormal service packets, compared to steady-state service packets, add new frequency components, which can correspond to the triggering sources of lightweight rule mismatch and entropy feature jumps.

[0173] Based on the completion of the load frequency component verification, in order to further verify the effectiveness of the present invention in steady-state determination and abnormal backoff under sliding window monitoring, the system compared the changes in information entropy and entropy gradient under different sliding window numbers.

[0174] See Figure 9 , Figure 9The horizontal axis represents the sliding window number, the left vertical axis represents the information entropy, and the right vertical axis represents the entropy gradient. The information entropy of the 1st to 9th sliding windows decreases from 7.05 to 4.82, indicating that the payload structure gradually shifts to the service transmission and reception structure during the authentication phase. After the 10th sliding window marks the end of authentication, the information entropy stabilizes between 4.75 and 4.86, and the entropy gradient is close to 0 and between the positive and negative thresholds. After the 24th sliding window marks the anomaly injection, the information entropy increases from 4.86 to 5.28 and continues to increase to 6.45, with the entropy gradient exceeding the positive threshold. After the anomaly fluctuation ends, the information entropy falls back to 5.05 and 4.88, and the entropy gradient exceeds the negative threshold and gradually decreases. This result shows that the present invention can maintain kernel-level steady-state service packet processing during the steady-state transmission and reception phase and triggers anomaly event reporting and Wasm execution context recovery when the entropy gradient exceeds the threshold.

Claims

1. A cloud-edge collaborative IoT device access management system, characterized in that, include: The access pre-inspection module is used to collect data packets during the initial access phase of heterogeneous IoT devices and generate device access feature vectors and device session identifiers. The cloud-based construction module is used to construct a deterministic finite state automaton based on the device access feature vector, generate Wasm bytecode, and issue the Wasm bytecode when the edge execution conditions are met. The sandbox authentication module is used to load the Wasm bytecode, create a Wasm execution context bound to the device session identifier, perform identity authentication, protocol parsing and entropy gradient monitoring, and output steady-state transition trigger information. The migration rollback module is used to generate a lightweight rule set based on the steady-state migration trigger information and compile it into an eBPF program, process steady-state service messages, detect abnormal events, and restore the Wasm execution context based on the abnormal events.

2. The IoT device access management system for cloud-edge collaboration according to claim 1, characterized in that, The access pre-detection module generates the device access feature vector including: Extract the payload, message length, message direction, and arrival time of the data packet; Generate the sampling payload sequence, message length sequence, message direction sequence, and arrival time interval sequence; Calculate the initial information entropy based on the sampled payload sequence and generate a payload summary; The sampling payload sequence, the message length sequence, the message direction sequence, the arrival time interval sequence, the initial information entropy, and the payload summary are combined to form the device access feature vector.

3. The IoT device access management system for cloud-edge collaboration according to claim 1, characterized in that, The cloud-based construction module constructs the deterministic finite state automaton in the following ways: Based on the device access feature vector, candidate protocols are matched in a preset global protocol feature library; Read the identity authentication process corresponding to the candidate protocol; The deterministic finite state automaton is constructed based on the candidate protocol and the identity authentication process.

4. The IoT device access management system for cloud-edge collaboration according to claim 3, characterized in that, The cloud-based build module generates the Wasm bytecode including: The deterministic finite state automaton is pruned, retaining the protocol parsing state, authentication state, and steady-state message processing state; The protocol parsing logic, authentication logic, and steady-state message processing logic corresponding to the trimmed deterministic finite state automaton are compiled into the Wasm bytecode.

5. The IoT device access management system for cloud-edge collaboration according to claim 1, characterized in that, The cloud-based construction module determines that the edge execution conditions are met, including: The edge execution cost is calculated based on the bytecode size of the Wasm bytecode, the memory usage of the Wasm execution context, the initialization time, and the edge-side resource occupancy rate. The cost of remote parsing is calculated based on the amount of data forwarded remotely in the original message, the round-trip latency of the cloud-edge link, the cloud parsing load, and the quality loss value of the cloud-edge link. When the edge execution cost plus the preset migration decision margin is less than the remote resolution cost, the edge execution condition is determined to be satisfied.

6. The IoT device access management system for cloud-edge collaboration according to claim 1, characterized in that, The sandbox authentication module performs identity authentication and protocol parsing, including: The deterministic finite state automaton is loaded according to the automaton description file associated with the Wasm bytecode; In the Wasm execution context, authentication messages and service messages are processed according to state transition rules. Write the automaton state and entropy gradient into the session state record bound to the device session identifier.

7. The IoT device access management system for cloud-edge collaboration according to claim 6, characterized in that, The sandbox authentication module outputs the steady-state migration trigger information, including: The state of the deterministic finite state automaton is read at the end of the sliding window; The entropy gradient is calculated based on the information entropy change of adjacent sliding windows; When the automaton is in a preset steady-state transmit / receive state, and the entropy gradient corresponding to multiple consecutive sliding windows is lower than a preset entropy gradient threshold, the steady-state transition trigger information is output.

8. The IoT device access management system for cloud-edge collaboration according to claim 1, characterized in that, The migration rollback module generates the lightweight rule set including: Based on the steady-state transition triggering information, extract the steady-state analytic subgraph corresponding to the steady-state transition triggering information from the deterministic finite state automaton; The message length verification logic, fixed field matching logic, and business field extraction logic in the steady-state parsing subgraph are converted into the lightweight rule set. The lightweight rule set includes message length verification rules, fixed field matching rules, field offset extraction rules, session identifier matching rules, and processing action rules.

9. The IoT device access management system for cloud-edge collaboration according to claim 8, characterized in that, The migration rollback module compiles the lightweight rule set into the eBPF program, including: The rules in the lightweight rule set are restricted to fixed offset access, fixed-length field extraction, finite branch judgment, and bounded loop processing. The restricted lightweight rule set is compiled into the eBPF program, and the eBPF program is attached to the XDP hook; The eBPF program performs message length verification, fixed field matching, service field extraction, and processing action selection on steady-state service messages.

10. The IoT device access management system for cloud-edge collaboration according to claim 9, characterized in that, The migration rollback module restores the Wasm execution context by including: The eBPF program detects entropy feature jumps, steady-state rule mismatches, or session state anomalies, generating the abnormal events. The abnormal events are reported to the user-mode daemon process via a circular buffer. The user-mode daemon restores the Wasm execution context based on the device session identifier contained in the abnormal event.

Images