Unified access system for internet of things devices based on multi-protocol adaptation

Abstract

The application discloses a multi-protocol adaptation based Internet of Things device unified access system and belongs to the technical field of Internet of Things communication. The system comprises a protocol listening module, which listens to connection requests on multiple network ports in parallel and assigns protocol analyzers based on protocol characteristic fields; a device mapping module, which maps device identifiers to a device fingerprint library to match device types; a session management module, which establishes a session channel according to a device type by calling a session management template; a message boundary module, which intercepts the first data message and determines the start position of the payload by a boundary marker; a timing unification module, which segments according to the start position of the payload and converts the timing label format; and a window coordination module, which dynamically adjusts the receiving window according to the fragmentation indicator and the rate in the header. Through boundary self-marking and window dynamic coordination, adaptive analysis of heterogeneous protocol messages and optimization of transmission efficiency are realized.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, specifically to a unified access system for IoT devices based on multi-protocol adaptation. Background Technology

[0002] IoT systems need to connect to devices using different communication protocols, and how to automatically identify multiple protocols and process data streams in a unified manner is a fundamental challenge. To achieve this, existing technologies generally utilize pre-deployed protocol parsing and adaptation layers, starting listening on a fixed port for each protocol, or directly assigning a parser through simple characteristic bytes. This approach can maintain operation when the number of protocols is small, but its limitations become apparent when the number of device types surges and the protocol message formats differ significantly.

[0003] In existing technologies, boundary identification of device-reported data often relies on preset fixed offsets or explicitly defined start delimiters in protocol standards. Different manufacturers implement protocol headers with variable lengths and varying field layouts, making preset fixed offsets unsuitable for all situations. Once the protocol version changes or non-standard extended fields are introduced, boundary identification becomes inaccurate, leading to payload extraction errors and affecting the reliable parsing of the entire data chain. Some solutions attempt to use deep packet inspection to traverse and match strings, but this method is computationally expensive and carries the risk of misjudgment in binary protocols.

[0004] In terms of receiving window management, existing systems mostly directly use the sliding window mechanism of the transport layer congestion control algorithm. This mechanism only adjusts the window based on the underlying acknowledgment and latency information, and does not utilize the fragmentation indication information carried by the application layer message itself. When IoT devices continuously report multiple data fragments, they cannot perceive the total size of the fragments, which can easily lead to insufficient window opening on the receiver, forcing the sender to wait frequently, or excessive window opening, causing buffer pressure. Both situations hinder data throughput efficiency.

[0005] Therefore, in a multi-protocol access environment, it is necessary to solve how to accurately and cost-effectively mark the start position of the payload of different protocol messages, and at the same time, it is necessary to solve how to actively predict and coordinate the receiving window based on application layer fragmentation information to adapt to the frequently changing uplink message traffic. Summary of the Invention

[0006] This invention provides a unified access system for IoT devices based on multi-protocol adaptation, aiming to achieve self-identification of message boundaries and adaptive coordination of the receiving window when heterogeneous IoT devices access concurrently. The system determines the payload start point by scanning the continuous flag bit combinations in the binary bit stream of the data packet, replacing the fixed offset method, enabling the system to adapt to the differences in message structures across various protocols. Simultaneously, it uses the fragment count indicator carried in the header, combined with the transmission rate and signal-to-noise ratio, to generate adjustment coefficients to predict the number of consecutive packets, driving dynamic scaling of the receiving window to balance data throughput and queue backlog.

[0007] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a unified access system for IoT devices based on multi-protocol adaptation. This system achieves low-latency, high-reliability access for heterogeneous IoT devices on a unified platform through parallel listening, adaptive protocol identification, device fingerprint matching, dynamic session maintenance, and coordinated adjustment of message timing and window parameters. The system includes a protocol listening module, a device mapping module, a session management module, a message boundary module, a timing unification module, and a window coordination module.

[0008] The protocol listening module listens in parallel on multiple network ports for connection requests from IoT devices and assigns a corresponding protocol parser to each connection request based on the protocol characteristic fields carried in each request. This approach avoids serial probing of a single protocol and can quickly determine the communication protocol used by the device at the initial stage of connection establishment, thus shortening the time required for the device to come online.

[0009] The device mapping module extracts the device identifier from the connection request using the protocol parser and maps the device identifier to a pre-built device fingerprint database to match and determine the device type of the IoT device. Through rapid retrieval from the fingerprint database, the system can accurately identify the device model and its capability attributes, providing a basis for subsequent session management and data processing.

[0010] Based on the device type, the session management module invokes the corresponding session management template to establish a session channel with the IoT device. By employing a session strategy adapted to the device type, devices with different protocols and power consumption characteristics can obtain a matching session maintenance mechanism, ensuring long-term stability of the communication link.

[0011] The message boundary module intercepts the first data packet uploaded by the IoT device in the session channel and marks the boundary of the first data packet to determine the start position of the payload of the first data packet. Through automatic boundary positioning, the header and payload can be accurately separated without relying on a fixed offset message format preset, improving the system's compatibility with unknown or variable-length header formats.

[0012] The timing unification module segments the first data packet into header and payload segments according to the payload's starting position, and converts the timing tags in the header segments into a unified timestamp format. This consolidates the time information reported by devices using different protocols into a consistent time base, enabling cross-protocol data fusion and analysis.

[0013] The window coordination module predicts the number of consecutive data packets to be received by the session channel based on the message length field in the header segment, and dynamically adjusts the receive window size of the session channel. By predicting and matching the amount of data to be received, the module effectively reduces buffer overflows or low link utilization caused by improper window settings, thus maintaining data reception throughput at a reasonable level.

[0014] As a preferred embodiment of the present invention, the step of assigning a corresponding protocol parser to each connection request specifically includes: extracting the preamble byte sequence of the connection request; performing a bit-by-bit XOR comparison of the preamble byte sequence with multiple protocol feature templates to obtain a matching score for each protocol feature template; selecting the parser instance corresponding to the protocol feature template with the largest matching score as the protocol parser corresponding to the connection request; after allocation, the protocol parser actively sends a handshake confirmation frame to the IoT device and waits for the IoT device to return the device identifier. Through bit-by-bit comparison and maximum score selection, even in the case of partial bit errors or differences in protocol stack implementation, the most matching parser can still be accurately assigned, reducing handshake failures caused by misjudgment.

[0015] Preferably, during the bitwise XOR comparison, each protocol feature template is also multiplied by its corresponding weight coefficient, which is dynamically updated based on historical matching accuracy. This approach allows protocol templates that have been consistently and correctly parsed over a long period to gain a greater advantage in the comparison, further improving the accuracy and adaptability of protocol identification.

[0016] As another preferred technical solution of the present invention, mapping the device identifier to a pre-built device fingerprint database specifically includes: extracting the manufacturer code segment and model code segment from the device identifier, and combining the manufacturer code segment and model code segment into a search key value; searching for a fingerprint entry in the device fingerprint database that exactly matches the search key value; if the fingerprint entry is found, directly reading the device type pre-stored in the fingerprint entry; if no exactly matching fingerprint entry is found, extracting the firmware version number from the device identifier, and performing a range search in the fuzzy matching area of ​​the device fingerprint database based on the firmware version number to obtain the device type. By combining precise matching with fuzzy matching based on firmware version, high-speed identification of mainstream devices is ensured, while also covering new models or variant devices that have not yet been recorded with precise fingerprints, thus expanding the device compatibility range of the system.

[0017] Preferably, establishing a session channel with the IoT device specifically includes: reading the session keep-alive interval, maximum idle time, and retransmission timeout step from the session management template, and sending a probe frame to the IoT device according to the session keep-alive interval; if no response to the probe frame is received from the IoT device within the maximum idle time, the current session channel is closed; if a retransmission request is received from the IoT device, the waiting time for the next retransmission is increased incrementally according to the retransmission timeout step until the maximum idle time is reached. This mechanism avoids frequent session reconstruction by increasing the waiting time when the device is briefly offline, while releasing resources in a timely manner when the device is truly offline, thus balancing communication recovery efficiency and system resource consumption.

[0018] Preferably, the boundary marking of the first data packet specifically includes: scanning the binary bit stream of the first data packet, detecting consecutively occurring flag bit combinations in the binary bit stream, and when the number of occurrences of the flag bit combination reaches a preset threshold, recording the byte index of the last bit of the flag bit combination as the payload start position; after recording the payload start position, marking all bytes before the payload start position as the header segment, and marking all bytes from the payload start position to the payload segment. Utilizing the repetitive nature of flag bit combinations for boundary determination avoids a hard dependency on specific protocol header length fields, and can accurately segment the payload even if rare optional extension fields appear in the header.

[0019] Preferably, converting the time stamp in the header segment into a unified timestamp format specifically includes: extracting the original timestamp from the header segment and identifying the length identifier bit of the original timestamp; determining the encoding length of the original timestamp based on the length identifier bit; separating the second-level count portion and the millisecond-level offset portion from the original timestamp according to the encoding length; merging the second-level count portion and the millisecond-level offset portion into the unified timestamp format; writing the converted unified timestamp format back to the storage location of the original timestamp in the header segment; and updating the verification field in the header segment. By adaptively identifying the length identifier bit and separating and recombining time information, the system can losslessly convert timestamps with different precisions and encoding methods into a unified format, and the write-back and verification update operations ensure the integrity and consistency of the message in subsequent transmission.

[0020] Preferably, predicting the number of consecutive data packets to be received in the session channel specifically includes: counting the total number of fragments carried in the header segment and using the total number of fragments indicator as a first prediction base; monitoring the data transmission rate of the IoT device in the session channel and generating a rate adjustment coefficient based on the ratio of the data transmission rate to the current size of the receiving window; multiplying the first prediction base by the rate adjustment coefficient to obtain a predicted value of the number of consecutive data packets. This prediction method simultaneously considers the number of fragments declared by the sender and the actual transmission rate, ensuring that the predicted value both matches the sender's intention and reflects the current link status, thereby improving the rationality of window adjustment.

[0021] Further preferably, the rate adjustment coefficient is also corrected based on the current signal-to-noise ratio (SNR) of the session channel. When the SNR is lower than a preset threshold, an attenuation factor is applied to the rate adjustment coefficient. When channel quality deteriorates, actively suppressing the window expansion amplitude through the attenuation factor can effectively avoid a large number of retransmissions and congestion deterioration caused by increased bit error rate, ensuring the stable operation of the system in complex wireless environments.

[0022] Preferably, the dynamic adjustment of the receive window size of the session channel specifically includes: reading the number of packets currently received but not processed by the session channel as a queue backlog value; if the queue backlog value is greater than the lower threshold of the receive window size, then reducing the receive window size to half of the current value; if the queue backlog value is less than the upper threshold of the receive window size, and the predicted value is greater than the current value of the receive window size, then expanding the receive window size to the predicted value. This backlog-aware window adjustment strategy rapidly shrinks the window to prevent buffer overflow when the system processing capacity is bottlenecked, and increases the window based on the predicted value to fully utilize the link bandwidth when the processing capacity is sufficient, thus achieving closed-loop adaptive control of received traffic.

[0023] The technical effects and advantages provided by the present invention in the above technical solution are as follows: For message boundary determination, the binary bit stream of the first data message is scanned to detect consecutively occurring flag bit combinations. When the number of occurrences of such a combination reaches a set threshold, the byte index containing the last bit of the flag bit combination is recorded as the start position of the payload. The bytes preceding this point are classified as header fragments, and the bytes following are classified as payload fragments. This method does not rely on any fixed offset or specific separator bytes of any protocol, and does not require prior knowledge of the header format of each protocol. It can adaptively locate the payload start point based solely on the recurrence of flag bit combinations in the bit stream, eliminating boundary misjudgments caused by protocol field extensions or non-standard implementations. In the case of concurrent access from multiple protocols, it can accurately separate the header from the valid data, avoiding payload truncation or misalignment, thereby improving the robustness and versatility of data extraction.

[0024] For receive window coordination, after obtaining the fragment total number indicator in the header segment as the first prediction base, a rate adjustment coefficient is generated by combining the monitored ratio of the data transmission rate within the session channel to the current size of the receive window. This coefficient is then corrected in real time based on the current signal-to-noise ratio. The prediction base is multiplied by the coefficient to obtain the predicted number of subsequent consecutive data packets. Furthermore, considering the channel queue backlog value, the receive window is halved when the backlog exceeds the lower threshold, and expanded when the backlog is below the upper threshold and the predicted value is greater than the current window size. This window coordination method directly mines fragment size information within the application layer packet for proactive prediction. Compared to the general sliding window mechanism that relies solely on underlying acknowledgment feedback, it can detect the arrival scale of batch data payloads in advance, shorten the window convergence time lag, reduce sender pauses due to insufficient windows, and avoid the risk of buffer overflow caused by excessive window enlargement, maintaining high channel utilization while ensuring orderly reception. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of a unified access system architecture for IoT devices based on multi-protocol adaptation; Figure 2 This is a flowchart illustrating the process of predicting the number of continuous data packets using the window coordination module. Figure 3 This is a flowchart of the dynamic adjustment process for the receiving window size; Figure 4 This is a diagram illustrating the continuous occurrence of the message boundary module flag bit. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0028] See Figure 1This invention provides a unified access system for IoT devices based on multi-protocol adaptation, including a protocol listening module, a device mapping module, a session management module, a message boundary module, a timing unification module, and a window coordination module. The protocol listening module listens in parallel on multiple network ports for connection requests from IoT devices and assigns a corresponding protocol parser to each connection request based on the protocol feature fields carried in each request. The device mapping module extracts the device identifier from the connection request using the protocol parser and maps the device identifier to a pre-built device fingerprint database to match the device type of the IoT device. The session management module calls the corresponding session management template based on the device type to establish a session channel with the IoT device. The message boundary module intercepts the first data packet uploaded by the IoT device in the session channel and marks the boundary of the first data packet to determine the start position of the payload of the first data packet. The timing unification module segments the first data packet into a header segment and a payload segment according to the start position of the payload, and converts the timing tag in the header segment into a unified timestamp format. The window coordination module predicts the number of consecutive data packets to be received by the session channel based on the message length field in the header segment, and dynamically adjusts the receive window size of the session channel.

[0029] Example 1: In practice, the protocol listening module listens for connection requests in parallel on multiple network ports. Each network port is bound to a socket descriptor, and the protocol listening module obtains readable events on the socket descriptor through an asynchronous event notification mechanism. When a readable event is obtained, the protocol listening module receives the raw byte stream of the connection request from the corresponding network port.

[0030] The protocol listening module extracts a preamble byte sequence from the raw byte stream of the connection request. The length of the preamble byte sequence is the same as the length of each protocol feature template. The module then performs a bit-by-bit XOR comparison between the preamble byte sequence and the multiple protocol feature templates. The bit-by-bit XOR comparison process involves XORing each bit in the preamble byte sequence with the corresponding bit in the protocol feature template, counting the total number of zero bits in the XOR result, and dividing this total by the total number of bits in the protocol feature template to obtain an initial matching score. The module then multiplies this initial matching score by the weight coefficient corresponding to the protocol feature template to obtain the matching score for that template. The weight coefficient is a real number greater than zero and less than or equal to one.

[0031] In some embodiments, the weight coefficient corresponding to the protocol feature template is dynamically updated based on the historical matching accuracy. The historical matching accuracy refers to the proportion of times, within a preset time period, the device corresponding to the connection request successfully returned a handshake confirmation frame after the protocol feature template was selected as the one with the highest matching score. The dynamic update method is as follows: whenever the protocol parser sends a handshake confirmation frame, if a complete device identifier returned by the IoT device is received within a preset waiting time, the match is considered successful; if a complete device identifier is not received within the timeout, the match is considered unsuccessful. The protocol listening module records the number of successful matches for each protocol feature template in the most recent N matches, divides the number of successful matches by N to obtain the historical matching accuracy, and assigns the historical matching accuracy to the weight coefficient corresponding to the protocol feature template. N is a preset statistical window size, and the value of N is 100.

[0032] The protocol listening module selects the highest matching score from all protocol feature templates and uses the parser instance corresponding to that matching score as the protocol parser for the connection request. The parser instance is a pre-instantiated object, and each parser instance contains a protocol state machine, frame format definition, and field extraction rules.

[0033] After the protocol parser assigns the data, it proactively sends a handshake confirmation frame to the IoT device. The format of the handshake confirmation frame is determined by the frame format definition within the protocol parser. After sending the handshake confirmation frame, the protocol parser starts a receive timer, waiting for the IoT device to return its device identifier. Before the receive timer expires, the protocol parser receives data from the network port corresponding to the connection request and parses the data frame according to the protocol state machine. Once a complete device identifier is parsed, the protocol parser passes the device identifier to the device mapping module. If the receive timer expires without receiving a complete device identifier, the protocol parser retransmits the handshake confirmation frame, with a maximum retransmission count of three.

[0034] Example 2: In practice, after the protocol parser extracts the device identifier from the connection request, it passes the device identifier to the device mapping module. The device mapping module internally maintains an identifier structure configuration table, which records the field layout of the device identifier corresponding to each protocol type. The field layout includes the start offset of the vendor code segment, the length of the vendor code segment, the start offset of the model code segment, the length of the model code segment, the start offset of the firmware version number segment, and the length of the firmware version number segment. Based on the protocol type used in the current connection request, the device mapping module reads the corresponding start offset of the vendor code segment, the length of the vendor code segment, the start offset of the model code segment, and the length of the model code segment from the identifier structure configuration table. The device mapping module extracts the vendor code segment from the byte sequence of the device identifier according to the read start offset and length of the vendor code segment, and extracts the model code segment from the byte sequence of the device identifier according to the start offset and length of the model code segment. The device mapping module then concatenates the extracted vendor code segment byte sequences and model code segment byte sequences sequentially to generate a retrieval key.

[0035] The device mapping module searches a pre-built device fingerprint database for fingerprint entries that exactly match the search key. The device fingerprint database uses a hash table structure for storage, where the key is the search key, the value is the fingerprint entry, and the fingerprint entry contains a device type field. The device mapping module takes the search key as input and performs a key lookup operation in the hash table of the device fingerprint database. If a key in the hash table matches the search key, the device mapping module determines that a perfectly matching fingerprint entry has been found. It then directly reads the value of the device type field from this fingerprint entry and uses this value as the device type of the IoT device.

[0036] If no key in the hash table matches the search key, the device mapping module determines that no completely matching fingerprint entry was found. The device mapping module reads the firmware version number segment start offset and firmware version number segment length from the identifier structure configuration table based on the current protocol type, extracts the firmware version number byte sequence from the device identifier, and converts the firmware version number byte sequence into an integer firmware version number value. The device mapping module performs a range search in the fuzzy matching area of ​​the device fingerprint database. The fuzzy matching area is stored using an interval tree structure. Each node in the interval tree contains a lower bound field for the firmware version number, an upper bound field for the firmware version number, and a device type field. Starting from the root node of the interval tree, the device mapping module compares the integer value of the firmware version number with the lower bound field and the upper bound field of the firmware version number of the current node. If the integer value of the firmware version number is greater than or equal to the lower bound field and less than or equal to the upper bound field, the device mapping module stops searching, reads the value of the device type field in the current node, and uses the read value as the device type of the IoT device. If the firmware version number is less than the lower bound field of the firmware version number, the device mapping module enters the left child node of the current node to continue the comparison; if the firmware version number is greater than the upper bound field of the firmware version number, the device mapping module enters the right child node of the current node to continue the comparison, until a node containing the integer value of the firmware version number is found.

[0037] After obtaining the device type output by the device mapping module, the session management module calls the corresponding session management template based on the device type. The session management template is pre-configured structured data according to the device type, and each template includes a session keep-alive interval field, a maximum idle duration field, and a retransmission timeout step field. The session management module reads the values ​​of the session keep-alive interval, maximum idle duration, and retransmission timeout step from the session management template corresponding to the device type. The session management module uses the read parameters to establish a session channel with the IoT device. The session channel consists of a network connection handle, a session status flag, and two timer instances: a probe frame timer and an idle timer.

[0038] The session management module starts a probe frame timer, setting its timeout to the session keep-alive interval. The probe frame timer uses a periodic timing mode, triggering a timeout event every specified session keep-alive interval. Each time the probe frame timer times out, the session management module calls the probe frame constructor bound to the session management template to generate probe frame data and sends it to the IoT device via the network connection handle of the session channel. After the probe frame is sent, the session management module starts an idle timer, setting its timeout to the maximum idle duration. The idle timer is a single-trigger timer.

[0039] If the session management module receives a response message for the probe frame from the IoT device through the network connection handle before the idle timer expires, the session management module stops and resets the idle timer, and continues the probe frame timer for the next probe cycle.

[0040] If the idle timer expires and the session management module still has not received a response message from the IoT device for the probe frame, the session management module will immediately close the current session channel. The operations for closing the current session channel include: canceling the probe frame timer, canceling the idle timer, closing the network connection handle, and setting the session status flag to the off state.

[0041] While the session channel is open, if the session management module receives a retransmission request message from an IoT device via the network connection handle, the session management module adjusts the retransmission waiting time. The session management module reads the currently used retransmission waiting time, the initial value of which is set to the retransmission timeout step size when the session channel is established. The session management module adds the retransmission timeout step size to the current retransmission waiting time to obtain the adjusted retransmission waiting time. The session management module compares the adjusted retransmission waiting time with the maximum idle time. If the adjusted retransmission waiting time is less than the maximum idle time, the session management module uses the adjusted retransmission waiting time as the effective retransmission waiting time and initiates the retransmission operation according to the effective retransmission waiting time. The retransmission operation is as follows: after waiting for the effective retransmission waiting time, a retransmission message is constructed and sent. If the adjusted retransmission waiting time is greater than or equal to the maximum idle time, the session management module uses the maximum idle time as the effective retransmission waiting time and executes the retransmission operation according to the maximum idle time. After each retransmission operation is completed, the session management module starts an idle timer to monitor subsequent responses.

[0042] Example 3: In practice, after the session channel is established, the message boundary module receives the first data packet uploaded by the IoT device through the network connection handle of the session channel. The message boundary module stores the first data packet in a contiguous byte buffer, the size of which is the same as the maximum message length negotiated by the session channel. The message boundary module maintains a current scan byte offset variable and a flag consecutive occurrence counter, initializing both the current scan byte offset variable and the flag consecutive occurrence counter to zero.

[0043] The message boundary module begins scanning the first data packet from the start of the byte buffer, performing a binary bitstream scan. During scanning, the module increments the current scanned byte offset variable by byte, extracting a complete 8-bit binary group from the byte pointed to by the offset variable each time. The module then performs a bitwise AND operation on this 8-bit binary group with a preset flag combination. The flag combination is a fixed-length binary sequence, with each bit's value determined during system initialization based on the message boundary flag field defined in the protocol feature template. If the result of the bitwise AND operation perfectly matches the flag combination, the message boundary module determines that it has detected an occurrence of the flag combination at the current scanned byte offset variable.

[0044] When the message boundary module detects the occurrence of a flag bit combination, it increments the value of the flag bit consecutive occurrence counter. If the value of the flag bit consecutive occurrence counter reaches a preset threshold, the message boundary module stops scanning and calculates the payload start position. The payload start position is calculated by adding the length of the flag bit combination in bytes to the value of the current scanned byte offset variable; the resulting byte index value is the payload start position. In one implementation, the preset threshold is determined by the configuration parameters read during system startup, and the preset threshold value is 2. If the number of occurrences of the flag bit combination does not reach the preset threshold, but a binary bit group inconsistent with the flag bit combination appears during scanning, the message boundary module clears the flag bit consecutive occurrence counter to zero and continues scanning subsequent bytes until the current scanned byte offset variable reaches the end of the byte buffer.

[0045] After recording the payload start position, the message boundary module marks all bytes in the byte buffer from index zero to the payload start position minus one as header segments, and marks all bytes from the payload start position onwards as payload segments. The message boundary module writes the start address and length of the header segment and the start address and length of the payload segment into two buffer descriptor structures respectively, and then passes the two buffer descriptor structures to the timing unification module.

[0046] After obtaining the buffer descriptor structure, the timing unification module accesses the byte data in the header segment based on the start address and length of the header segment. The timing unification module then extracts the raw timestamp from the header segment. The storage location and format of the raw timestamp in the header segment are determined by the timestamp field descriptor defined in the protocol feature template used by the current connection. The timestamp field descriptor includes the starting offset value of the raw timestamp, the bit width of the length flag, and the position offset of the length flag.

[0047] The timing unification module reads the bit value of the length identifier bit from the byte sequence of the original time tag according to the position offset value of the length identifier bit in the time tag field descriptor. The bit value of the length identifier bit consists of several bits. The timing unification module converts the bit value of the length identifier bit into an integer, which is used as the encoding length of the original time tag. The unit of encoding length is bytes. In some implementations, the position offset value of the length identifier bit is zero, the bit width of the length identifier bit is two bits, and the mapping relationship between the encoding length value and the length identifier bit value is as follows: when the length identifier bit value is binary 00, the encoding length is four bytes; when the length identifier bit value is binary 01, the encoding length is six bytes; when the length identifier bit value is binary 10, the encoding length is eight bytes; when the length identifier bit value is binary 11, the encoding length is ten bytes.

[0048] The timing unification module reads the encoded bytes of data from the byte sequence of the original timestamp based on the encoded length of the original timestamp, and parses it according to either big-endian or little-endian byte order. The byte order is determined by the timestamp byte order marker in the protocol feature template. The timing unification module separates the second-level count portion and the millisecond-level offset portion from the parsed data. The separation method is based on the internal structure corresponding to the encoded length: if the encoded length is four bytes, the second-level count portion occupies the first three bytes, and the millisecond-level offset portion occupies the lower six bits of the last byte; if the encoded length is six bytes, the second-level count portion occupies the first four bytes, and the millisecond-level offset portion occupies the lower ten bits of the last two bytes; if the encoded length is eight bytes, the second-level count portion occupies the first six bytes, and the millisecond-level offset portion occupies the lower ten bits of the last two bytes; if the encoded length is ten bytes, the second-level count portion occupies the first six bytes, and the millisecond-level offset portion occupies the lower sixteen bits of the last four bytes.

[0049] The timing unification module converts the integer values ​​of the second-level count portion and the integer values ​​of the millisecond-level offset portion into a unified timestamp format. The unified timestamp format is a 64-bit unsigned integer, the value of which is calculated using the following formula: in, Represents a 64-bit unsigned integer value in a uniform timestamp format. This represents the integer value corresponding to the second-level count portion separated from the original timestamp. This represents the integer value corresponding to the millisecond-level offset portion separated from the original timestamp. The value of is an integer ranging from zero to nine hundred and ninety-nine.

[0050] The timing unification module converts the calculated 64-bit unsigned integer value of the unified timestamp format into an eight-byte sequence according to little-endian byte order, and writes the converted eight-byte sequence back to the storage location of the original timestamp in the header segment. During write-back, the timing unification module sequentially overwrites the original byte data with eight bytes starting from the starting offset of the original timestamp. If the length of the eight bytes exceeds the encoded length of the original timestamp, the excess bytes are written sequentially to the byte space immediately following the storage location of the original timestamp, and the effective length of the header segment is extended to the corresponding number of bytes; if the length of the eight bytes is less than the encoded length of the original timestamp, the remaining original bytes remain unchanged after writing, and the length of the header segment is not adjusted.

[0051] After the write-back operation is complete, the timing unification module updates the checksum field in the header segment. The location and algorithm of the checksum field are determined by the checksum field descriptor defined in the protocol feature template. The checksum algorithm is Cyclic Redundancy Check (CRC), and the checksum calculation covers all bytes of data in the header segment from the first byte to the byte preceding the checksum field. The timing unification module calls the Cyclic Redundancy Check calculation function, using the updated header segment as input, to calculate the new checksum value and write it to the storage location of the checksum field.

[0052] See Figure 4 In the graph, the horizontal axis represents the current scan byte offset when the message boundary module performs a binary bit stream scan on the first data packet, in bytes, ranging from 0 to 1000 bytes; the vertical axis represents the count value of the flag bit consecutive occurrence counter, which is an integer. The blue solid line curve depicts the changing trend of the flag bit consecutive occurrence counter during the scanning process; the red dashed line represents the preset threshold value, with the counting threshold set to 2; the green dotted line represents the byte offset at the start of the payload, corresponding to a scan byte offset of approximately 200 bytes.

[0053] As shown in the figure, the flag bit consecutive occurrence counter fluctuates multiple times within the range of approximately 200 bytes from the start of the scan, but the count value does not reach the preset threshold of 2. During this period, the counter value is intermittently 1, indicating that the flag bit combination appears sporadically and discontinuously. When the scan byte offset approaches 200 bytes, the counter value suddenly increases to 2, reaching the preset threshold for the first time and triggering the stop scan operation. At this time, the message boundary module uses the scan byte offset of 200 bytes plus the length of the flag bit combination in bytes (the specific length is not shown, but in this embodiment it can be set to a fixed value) as the starting position of the payload, that is, it determines that the starting position of the payload is after this offset.

[0054] Example 4: In specific implementation, please refer to Figure 3The window coordination module reads the message length field from the header segment processed by the message boundary module or the timing unification module. The starting offset and field length of the message length field in the header segment are determined by the message length field descriptor in the protocol feature template used by the current connection. The window coordination module extracts the value of the message length field from the byte sequence of the header segment according to the message length field descriptor, and stores the value of the message length field as the basic parameter for window adjustment in the internal state structure of the window coordination module.

[0055] The window coordination module calculates the total fragmentation indicator from the header segment. The starting offset and field length of the total fragmentation indicator in the header segment are determined by the fragmentation control field descriptor in the protocol feature template. The fragmentation control field descriptor includes the positions of the fragmentation flag and the total fragmentation indicator. The window coordination module first reads the value of the fragmentation flag, which is a one-bit bit. When the value of the fragmentation flag is 1, it indicates that the current data packet belongs to a fragmented transmission sequence, and the header segment contains a valid total fragmentation indicator; when the value of the fragmentation flag is 0, it indicates that the current data packet is a non-fragmented transmission, and the total fragmentation indicator is invalid. When the value of the fragmentation flag is 1, the window coordination module reads the integer value of the total fragmentation indicator from the header segment according to its position and stores the integer value of the total fragmentation indicator as the first prediction cardinality in the internal state structure of the window coordination module. When the value of the fragmentation flag is 0, the window coordination module sets the first prediction cardinality to 1.

[0056] The window coordination module monitors the data transmission rate of IoT devices within the session channel. The monitoring method is as follows: When the session channel is established, the window coordination module creates a rate monitoring window, the duration of which is a preset rate sampling period. The rate sampling period is 500 milliseconds. Within the rate monitoring window, the window coordination module counts the total number of bytes received from all data packets through the network connection handle and divides this total number of bytes by the rate sampling period to obtain the data transmission rate of the IoT device within the rate monitoring window, in bytes per second. At the end of each rate sampling period, the window coordination module updates the data transmission rate value and restarts the next rate sampling period.

[0057] The window coordination module reads the current size of the receive window. This current size is stored in the window control structure of the session channel. The window control structure is initialized by the session management module when the session channel is established, with the initial value being the default receive window size defined in the protocol feature template. The window coordination module divides the monitored data transmission rate by the current receive window size to generate a rate adjustment coefficient. This rate adjustment coefficient is a floating-point number.

[0058] In some embodiments, the window modulation module further corrects the rate adjustment coefficient based on the current signal-to-noise ratio (SNR) of the session channel. The current SNR is obtained by the window modulation module from the network interface layer. The network interface layer provides an interface for obtaining wireless signal quality information, returning the SNR value in decibels (dB). The window modulation module compares the obtained SNR value with a preset threshold. The preset threshold is 10 dB, set based on the principle that in wireless environments with an SNR below 10 dB, the bit error rate of data packets increases due to signal interference, and expanding the receive window would actually increase link congestion and retransmission pressure.

[0059] When the signal-to-noise ratio (SNR) is below a preset threshold, the window tuning module applies an attenuation factor to the rate adjustment coefficient. The attenuation factor is calculated by dividing the SNR by the preset threshold and then multiplying the result by the rate adjustment coefficient. The rate adjustment coefficient after applying the attenuation factor is calculated using the following formula: in, This represents the rate adjustment coefficient after applying the attenuation factor. It is a floating-point number greater than zero; This represents the rate adjustment coefficient before the attenuation factor is applied. A floating-point value obtained by dividing the data transmission rate by the current size of the receiving window; This represents the current signal-to-noise ratio value of the session channel. The unit is decibel. The value of is a real number between zero and fifty. This represents the value of the preset threshold. The value is 10 decibels.

[0060] When the signal-to-noise ratio is greater than or equal to the preset threshold, the window tuning module does not apply an attenuation factor to the rate adjustment coefficient, and the rate adjustment coefficient remains the value obtained directly by dividing the data transmission rate by the current size of the receiving window.

[0061] The window coordination module multiplies the first prediction base with the rate adjustment coefficient to obtain a predicted value for the number of consecutive data packets. During multiplication, the window coordination module converts the first prediction base to a floating-point number, multiplies it with the rate adjustment coefficient, and then rounds the product down to obtain an integer value as the predicted number of consecutive data packets. The window coordination module stores this predicted value in its internal state structure for use in subsequent adjustments to the receive window size.

[0062] Example 5: In specific implementation, please refer to Figure 3The window coordination module dynamically adjusts the receive window size. It reads the current receive window size from the session channel's window control structure, in bytes. The module also accesses the session channel's receive queue data structure, maintained by the session management module, which buffers data packets received by the network connection handle. This receive queue data structure contains a count of received but not yet retrieved by the upper-layer application. The window coordination module reads this count and uses it as the queue backlog value. The queue backlog value is measured in packets.

[0063] The window coordination module reads the preset lower and upper threshold values ​​from the window control structure. These thresholds are initialized based on configuration parameters in the protocol feature template when the session channel is established. The lower threshold is set to one-quarter of the initial receive window size. The upper threshold is set to three-quarters of the initial receive window size. The initial receive window size is the default receive window size defined in the protocol feature template.

[0064] The window coordination module compares the queue backlog value with the lower threshold. If the queue backlog value is greater than the lower threshold, the window coordination module performs a reduction operation on the receive window size. The reduction operation is as follows: the window coordination module calculates half of the current receive window size, rounds the result down, and if the rounded result is less than the minimum receive window size defined in the protocol feature template, the receive window size is set to the minimum receive window size; if the rounded result is greater than or equal to the minimum receive window size, the rounded value is used as the new receive window size. The window coordination module calls the socket option setting interface provided by the operating system to apply the new receive window size to the network connection handle of the session channel and synchronously updates the current receive window size field in the window control structure.

[0065] The window coordination module compares the queue backlog value with the upper threshold and reads the predicted number of consecutive data packets from its internal state structure. If the queue backlog value is less than the upper threshold and the predicted number of consecutive data packets is greater than the current receive window size, the window coordination module performs a receive window size expansion operation. The expansion operation is as follows: the window coordination module sets the receive window size to the number of bytes obtained by multiplying the predicted number of consecutive data packets by the maximum length of a single packet. The maximum length of a single packet is provided by the maximum transmission unit field defined in the protocol feature template. The window coordination module compares the calculated expanded byte count with the maximum receive window size defined in the protocol feature template. If the expanded byte count is greater than the maximum receive window size, the receive window size is set to the maximum receive window size; if the expanded byte count is less than or equal to the maximum receive window size, the expanded byte count is used as the receive window size. The window coordination module calls the socket option setting interface provided by the operating system to apply the finally determined receive window size to the network connection handle of the session channel and synchronously updates the current receive window size field in the window control structure.

[0066] When the queue backlog value does not meet the conditions of being greater than the lower threshold, nor does it meet the conditions of being less than the upper threshold and the predicted value of the number of consecutive data packets being greater than the current size of the receiving window, the window coordination module keeps the current size of the receiving window unchanged.

[0067] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A system for uniform access of Internet of Things devices based on multi-protocol adaptation, characterized in that, include: The protocol listening module is used to listen for connection requests from IoT devices in parallel on multiple network ports, and to assign a corresponding protocol parser to each connection request based on the protocol feature fields carried in each connection request. The device mapping module extracts the device identifier from the connection request by the protocol parser and maps the device identifier to a pre-built device fingerprint database to match and obtain the device type of the IoT device; The session management module, based on the device type, calls the corresponding session management template to establish a session channel with the IoT device; The message boundary module is used to intercept the first data packet uploaded by the IoT device in the session channel and mark the boundary of the first data packet to determine the start position of the payload of the first data packet. The timing unification module segments the first data packet into a header segment and a payload segment according to the start position of the payload, and converts the timing tag in the header segment into a unified timestamp format; The window coordination module predicts the number of consecutive data packets to be received by the session channel based on the message length field in the header segment, and dynamically adjusts the receive window size of the session channel.

2. The unified access system for IoT devices based on multi-protocol adaptation according to claim 1, characterized in that, The process of assigning a corresponding protocol parser to each connection request includes: Extract the leading byte sequence of the connection request, and perform a bitwise XOR comparison between the leading byte sequence and multiple protocol feature templates to obtain the matching score of each protocol feature template; Select the parser instance corresponding to the protocol feature template with the largest value in the matching score as the protocol parser corresponding to the connection request; After allocation, the protocol parser actively sends a handshake confirmation frame to the IoT device and waits for the IoT device to return the device identifier.

3. The unified access system for IoT devices based on multi-protocol adaptation according to claim 2, characterized in that, During the bitwise XOR comparison, each protocol feature template is also multiplied by the weight coefficient corresponding to that template, and the weight coefficient is dynamically updated based on the historical matching accuracy.

4. The unified access system for IoT devices based on multi-protocol adaptation according to claim 2, characterized in that, The step of mapping the device identifier to a pre-built device fingerprint database includes: Extract the manufacturer code segment and model code segment from the device identifier, and combine the manufacturer code segment and model code segment into a search key value; Search the device fingerprint database for a fingerprint entry that perfectly matches the search key value. If the fingerprint entry is found, directly read the device type pre-stored in the fingerprint entry. If no perfectly matching fingerprint entry is found, the firmware version number is extracted from the device identifier, and a range search is performed in the fuzzy matching area of ​​the device fingerprint database based on the firmware version number to obtain the device type.

5. The unified access system for IoT devices based on multi-protocol adaptation according to claim 4, characterized in that, The establishment of a session channel with the IoT device includes: Read the session keep-alive interval, maximum idle time and retransmission timeout step from the session management template, and send probe frames to the IoT device according to the session keep-alive interval; If no response to the probe frame is received from the IoT device within the maximum idle time, the current session channel is closed. If a retransmission request is received from the IoT device, the waiting time for the next retransmission is extended incrementally according to the retransmission timeout step size until the maximum idle time is reached.

6. The unified access system for IoT devices based on multi-protocol adaptation according to claim 5, characterized in that, The step of marking the boundaries of the first data packet includes: Scan the binary bit stream of the first data packet, detect consecutive flag bit combinations in the binary bit stream, and when the number of occurrences of the flag bit combination reaches a preset threshold, record the byte index of the last bit of the flag bit combination as the starting position of the payload. After recording the payload start position, all bytes before the payload start position are marked as the header segment, and all bytes after the payload start position are marked as the payload segment.

7. The unified access system for IoT devices based on multi-protocol adaptation according to claim 6, characterized in that, The step of converting the time stamp in the header segment into a unified timestamp format includes: Extract the original time tag from the header segment, identify the length identifier bit of the original time tag, and determine the encoded length of the original time tag based on the length identifier bit; According to the encoding length, the second-level count part and the millisecond-level offset part are separated from the original timestamp, and the second-level count part and the millisecond-level offset part are merged into the unified timestamp format; The converted unified timestamp format is written back to the storage location of the original timestamp in the header segment, and the verification field in the header segment is updated.

8. The unified access system for IoT devices based on multi-protocol adaptation according to claim 7, characterized in that, The prediction of the number of consecutive data packets to be received in the subsequent session channel includes: The total number of fragment indicators carried in the header segment is counted, and the total number of fragment indicators is used as the first prediction base. The data transmission rate of the IoT device is monitored in the session channel, and a rate adjustment coefficient is generated based on the ratio of the data transmission rate to the current size of the receiving window. Multiply the first prediction base by the rate adjustment coefficient to obtain the predicted value of the number of continuous data packets.

9. The unified access system for IoT devices based on multi-protocol adaptation according to claim 8, characterized in that, The rate adjustment coefficient is also corrected based on the current signal-to-noise ratio of the session channel. When the signal-to-noise ratio is lower than a preset threshold, an attenuation factor is applied to the rate adjustment coefficient.

10. The unified access system for IoT devices based on multi-protocol adaptation according to claim 8, characterized in that, The dynamic adjustment of the receive window size of the session channel includes: Read the number of messages that have been received but not yet processed in the session channel, and use it as the queue backlog value; If the queue backlog value is greater than the lower limit threshold of the receiving window size, then the receiving window size is reduced to half of the current value; If the queue backlog value is less than the upper limit threshold of the receiving window size, and the predicted value is greater than the current value of the receiving window size, then the receiving window size is increased to the predicted value.

Images