Power distribution internet of things data transmission method and system

Abstract

The application provides a power distribution Internet of Things data transmission method and system, the method comprises the following steps: analyzing the service type, source end identifier and network partition information of the to-be-transmitted service data, combining historical ACK message load residual state adjustment mapping rules, jointly encoding the priority, slice identifier and source end identifier hash value into a composite identifier, and writing the composite identifier into the first area of the TCP header option; normalizing the sending queue trend value and rate deviation, weighting to obtain a forward congestion prediction value, and storing the forward congestion prediction value into the second area to complete message sending; analyzing the congestion prediction value at the receiving end, fusing the processing delay and cache occupancy rate to obtain a comprehensive load feedback value, adjusting the acknowledgment bitmap compression strategy according to the value, storing the comprehensive load feedback value, encoding type identifier and acknowledgment information into the third area of the ACK message TCP option; and analyzing the acknowledgment information according to the encoding type identifier at the sending end, and preferentially retransmitting the data message which is not received and has the smallest sequence number and is indicated by the acknowledgment information.

Description

Technical Field

[0001] This application belongs to the field of power distribution Internet of Things (IoT), and in particular relates to a power distribution IoT data transmission method and system. Background Technology

[0002] With the continuous development of smart grid construction, the distribution Internet of Things (IoT), as a key infrastructure connecting massive amounts of power terminal devices and enabling comprehensive perception and intelligent management of the distribution network, has been widely deployed and applied. The distribution IoT carries a wide variety of business data, including distribution control, smart meter status acquisition, distributed energy monitoring, and video inspection, which vary in terms of real-time performance, reliability, and data throughput. To meet the transmission needs of different services, distribution communication networks typically utilize technologies such as network slicing to achieve resource isolation and on-demand allocation. As a fundamental transport layer protocol of the Internet, TCP, due to its connection-oriented and reliable transmission characteristics, is widely used in data interaction within the distribution IoT. However, facing the concurrent access of massive heterogeneous terminals, variable network partitions, and diverse service types in the distribution IoT, ensuring the stable transmission of critical services with limited network bandwidth resources has become a current challenge in the field of distribution IoT communication.

[0003] In existing power distribution IoT data transmission scenarios, the standard TCP protocol has low depth of awareness regarding application layer service types, source device identities, and underlying network partition information during data transmission. This makes it difficult for network nodes to differentiate scheduling based on service urgency and slice affiliation, and to ensure the transmission quality of high-priority core services. Traditional TCP congestion control and status feedback mechanisms rely on packet loss events or passive acknowledgment delays, exhibiting lag. When sudden traffic surges or increased network node load occur in the power distribution IoT, traditional feedback mechanisms have weak ability to predict congestion trends in advance, and the receiving end struggles to promptly notify the sending end of its actual processing load and buffer status, making it difficult for the sending end to adjust its transmission strategy. Furthermore, traditional message acknowledgment and retransmission mechanisms are relatively rigid, easily triggering numerous redundant retransmissions when facing network jitter and out-of-order packets, exacerbating network congestion and increasing transmission latency. Therefore, there is an urgent need to find a more intelligent optimization mechanism to improve the perception capability, congestion prediction capability, and retransmission efficiency of power distribution IoT data transmission. Summary of the Invention

[0004] According to one aspect of the present invention, a data transmission method for power distribution Internet of Things (IoT) is proposed to improve the sensing capability, congestion prediction capability, and retransmission efficiency of power distribution IoT data transmission, comprising the following steps:

[0005] Parse the service type, source identifier, and network partition information of the service data to be transmitted. Based on the load margin status feedback from historical ACK packets, adjust the mapping rules, map the service type to priority, encode the network partition information into a slice identifier, perform hash calculation on the source identifier, and encode the priority, slice identifier, and source hash value into a composite identifier according to a preset bit width, and write it into the first area of ​​the TCP header options. The forward congestion prediction value is obtained by collecting the trend of the change in the sending queue length and the deviation of the historical sending rate, normalizing them respectively, and then weighted summing them. It is written into the second area of ​​the TCP header options and encapsulated into the sending data packet. The receiving end parses the forward congestion prediction value and measures the processing delay of the packet from the network interface to the kernel protocol stack. The receiving end uses the normalized forward congestion prediction value as a weight, integrates the normalized processing latency and buffer occupancy rate to generate a comprehensive load feedback value, and constructs an acknowledgment bitmap based on the received sequence number. Combining the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third area of ​​the ACK packet TCP options can carry, it selects the original bitmap, compressed bitmap, or missing sequence number encoding as the acknowledgment information, and writes the comprehensive load feedback value, encoding type identifier, and acknowledgment information into the third area of ​​the ACK packet TCP options. The sending end parses the comprehensive load feedback value and acknowledgment information based on the encoding type identifier, determines the data packets marked as not received or missing sequence number encoding in the acknowledgment bitmap, and prioritizes retransmitting the data packets with the smallest sequence number.

[0006] According to another aspect of the present invention, a power distribution Internet of Things (IoT) data transmission system is proposed, comprising the following modules: The adjustment module is used to parse the service type, source identifier, and network partition information of the business data to be transmitted. Based on the load margin status feedback from historical ACK packets, it adjusts the mapping rules, maps the service type to the priority, encodes the network partition information into a slice identifier, performs a hash calculation on the source identifier, and encodes the priority, slice identifier, and source hash value into a composite identifier according to a preset bit width, and writes it into the first area of ​​the TCP header options. The calculation module is used to collect the trend of changes in the sending queue length and the deviation of the historical sending rate. After normalization, the forward congestion prediction value is obtained by weighted summation. The value is written into the second area of ​​the TCP header options and encapsulated into a data packet for transmission. The receiving end parses the forward congestion prediction value and measures the processing latency of the packet from the network interface to the kernel protocol stack. The generation module is used by the receiving end to generate a comprehensive load feedback value by weighting the normalized forward congestion prediction value, integrating the normalized processing latency and buffer occupancy rate, and constructing an acknowledgment bitmap based on the received sequence number. Combining the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third area of ​​the ACK packet TCP options can carry, the module selects the native bitmap, compressed bitmap, or missing sequence number encoding as the acknowledgment information. The comprehensive load feedback value, encoding type identifier, and acknowledgment information are written into the third area of ​​the ACK packet TCP options. The sending end parses the comprehensive load feedback value and acknowledgment information based on the encoding type identifier, determines the data packets marked as not received or missing sequence number encoding in the acknowledgment bitmap, and prioritizes retransmitting the data packets with the smallest sequence number.

[0007] This invention analyzes the multidimensional attributes of service data and combines them with historical load margin status to adjust mapping rules. Priority, slice identifier, and source hash value are jointly encoded and stored in the TCP header options. This enables local queue scheduling modules, edge gateways, or network slice scheduling agents supporting this extended protocol to perform classification, queue mapping, and differentiated scheduling based on the composite identifier within a smaller field space. Compared to carrying complete service identifiers, complete source addresses, and complete partition information separately, this reduces the overhead of the extended identifier field, thereby improving the classification and scheduling efficiency of massive services in the power distribution IoT. Furthermore, by fusing the sending queue length trend and historical rate deviation to calculate the forward congestion prediction value, the receiving... The endpoint can detect network congestion risks in advance, reducing the lag of traditional TCP mechanisms that rely on packet loss to determine congestion and enhancing the timeliness of congestion control. At the same time, it generates a comprehensive load feedback value by combining congestion prediction value, processing latency and cache occupancy rate, and adjusts the compression strategy of the acknowledgment bitmap accordingly. In high load or ACK option space-constrained scenarios, it reduces the bandwidth consumption of extended acknowledgment information, and retains the original bitmap in low load scenarios to reduce compression and decompression computation overhead. It also reduces the comprehensive transmission overhead caused by redundant retransmission and head-of-line blocking by prioritizing retransmission of earlier lost packets in subsequent continuous delivery, thereby reducing end-to-end transmission latency and improving the data transmission reliability and network throughput of the power distribution IoT in variable environments. Attached Figure Description

[0008] Figure 1 A flowchart of the first embodiment; Figure 2 This is a schematic diagram of the priority adjustment curve; Figure 3 This is a diagram illustrating the statistical results of message processing delay. Detailed Implementation

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

[0010] In the first embodiment, the present invention proposes a data transmission method for a power distribution Internet of Things (IoT), such as... Figure 1 It includes the following steps: S1: Parse the service type, source identifier, and network partition information of the service data to be transmitted. Based on the load margin status feedback from historical ACK packets, adjust the mapping rules, map the service type to priority, encode the network partition information into a slice identifier, perform hash calculation on the source identifier, and encode the priority, slice identifier, and source hash value into a composite identifier according to the preset bit width, and write it into the first area of ​​the TCP header options.

[0011] The sending end intercepts the data stream by calling the Socket interface at the application layer. It parses the business header in the data stream at the application layer to extract the service type and business protocol label. At the same time, it obtains the source identifier and network partition information through the Socket connection metadata and the local address returned by the system call. The source network address, routing prefix and mask prefix are not directly parsed from the application layer payload, but are provided by the operating system network layer metadata or a dedicated gateway encapsulation module.

[0012] The sending end maintains historical load margin status records updated based on an exponentially weighted moving average algorithm. These historical load margin status records are used to store the receiving end load margin status value, which is obtained by reverse conversion of the comprehensive load feedback value in historical ACK packets, and is calculated according to the formula... Update historical load balance status records, where This represents the current smoothed load margin status value. This is the load margin status value after smoothing from the previous cycle. The load margin status value corresponding to the current ACK packet is α, which is a preset smoothing coefficient. When the comprehensive load feedback value ranges from 0 to 100, the load margin status value of the receiving end is 100 minus the comprehensive load feedback value. Based on the comparison result between the load margin value and the preset threshold, the initial basic weight corresponding to the service type is corrected. The sending end looks up the priority mapping table to convert different service types such as remote signaling and telemetry into fixed-length binary priority codes, and performs feature extraction on the network partition information according to the preset slice identifier generation rules and maps it to a specific fixed-width slice identifier.

[0013] The SHA256 secure hash algorithm is used to perform a one-way hash calculation on the combination of the Media Access Control address and Internet Protocol address of the source identifier, and the lower 16 bits of the result are extracted as the hash value of the source identifier. The sending end concatenates the hash values ​​of the priority, slice identifier, and source identifier into a 32-bit composite identifier by bitwise left shift and bitwise OR operation.

[0014] By using kernel protocol stack interfaces, protocol stack hooks, or dedicated gateway encapsulation modules that support writing TCP extended options, the option type is set to 253, and the composite identifier is written into the first memory area after the option length field. Within the power distribution IoT communication domain that supports this extended protocol, when forwarding or queuing packets, the sending end local queue scheduling module, edge gateway, or network slice scheduling agent locates the first area of ​​the TCP header options according to option type 253, parses the priority field, slice identifier field, and source identifier hash field in the composite identifier, maps the priority field to the corresponding high-priority queue, ordinary queue, or low-priority queue, maps the slice identifier field to the corresponding network slice or security partition queue, and uses the source identifier hash field for merging and statistics of the same source service flow. When multiple packets compete for the same sending resource, the scheduling module prioritizes scheduling the packet with the highest priority field value and belongs to the core slice, and implements differentiated bandwidth allocation through a strict priority queue method. This makes the composite identifier written into the first area of ​​the TCP options form closed-loop control information that can be parsed and executed by the scheduling link.

[0015] In an optional embodiment, the step of parsing the service type, source identifier, and network partition information of the service data to be transmitted, and adjusting the mapping rules based on the load margin status feedback from historical ACK packets to map the service type to priority, includes: Read the receiver's load margin status value from the sender's local historical ACK feedback record at fixed time intervals; Calculate the mean coefficient of the historical load margin status values ​​for a preset quantity; Extract the service type identifier of the service data to be transmitted. The service type identifier includes the service protocol label and the service function identifier. When the same service protocol label corresponds to multiple service functions, further read the function code, subject field or message category field in the service header to distinguish between control, status acquisition, alarm or video service types. Based on the service type identifier, match the system's built-in priority mapping table to query the corresponding initial basic weight. The initial base weight is divided by the mean coefficient and rounded down, and then truncated according to the available bit width of the priority field to obtain the target business priority.

[0016] At fixed time intervals, preferably between 50ms and 200ms (e.g., 100ms), the receiver load margin status value stored in the sender's local historical ACK feedback record is read. This receiver load margin status value is calculated by the sender based on the comprehensive load feedback value carried in the historical ACK packets. The load margin status value is an integer between 0 and 100. The smaller the receiver load margin status value, the lower the available processing capacity and the higher the actual load. A recent preset number of historical load margin status values, preferably 5 to 10 (e.g., 10), are extracted. The arithmetic mean of these historical load margin status values ​​is calculated using a sliding window algorithm and normalized by dividing by 100, resulting in a mean coefficient ranging from 0.01 to 1.0. If the calculated value is lower than 0.01, it is defaulted to 0.01 to avoid division by zero. For example, if the average of 10 load margin status values ​​is 45, the mean coefficient is 0.45. Parse the application layer service header, socket connection metadata, or network layer metadata provided by the protocol stack hook of the data packet to be transmitted, and extract the service type identifier. The service type identifier is determined by the service protocol tag and the service function identifier, such as IEC 61850 GOOSE message, MQTT control message and its corresponding function code, subject field or message category field, and query the priority mapping table in the form of a static hash table built into the system. The priority mapping table is a static configuration table that is preset by the system or issued by the power distribution IoT operation and maintenance platform. The table entries include at least the service type identifier, the service protocol tag, the service function identifier and the corresponding initial basic weight.

[0017] The priority mapping table is a static configuration table pre-set by the system or issued by the power distribution IoT operation and maintenance platform. The table entries include at least a service type identifier, a business protocol label, a business function identifier, and a corresponding initial basic weight. The service type identifier is determined by the business protocol label and the business function identifier. When the same business protocol label corresponds to multiple business functions, the specific service type in the mapping table is determined according to the function code, subject field, or message category field in the business header. For example, the initial basic weight corresponding to key control services such as relay protection trip instructions is set to the highest level, such as 100, while the initial basic weight of routine status monitoring data is set to a lower level, such as 30.

[0018] The initial base weight obtained from the query is used as the dividend, and the calculated mean coefficient is used as the divisor for division. The result is then processed using a floor function, and truncated according to the available bit width of the priority field to prevent the target service priority from exceeding the representable range of the priority field in the composite identifier. For example, when the initial base weight of a GOOSE message is 100 and the load margin mean coefficient is 0.55, 100 ÷ 0.55 ≈ 181.82 is calculated, and after rounding, the target service priority is 181. When the receiver load further increases and the load margin mean coefficient decreases to 0.10, 100 ÷ 0.10 = 1000 is calculated, and after rounding, a higher target service priority is obtained. In this way, when the receiver load is high (i.e., the mean coefficient is low), high-weight services can obtain amplified priority values, occupying higher priority in subsequent transmission queue scheduling, ensuring low latency and high reliability transmission of core power distribution IoT services under network fluctuation conditions.

[0019] In an optional embodiment, encoding the network partition information into slice identifiers includes: Parse the IP address information of the source access node and extract the network address prefix and mask prefix from the routing table corresponding to the source access node; The network address prefix and mask prefix are combined and converted into a binary partition feature sequence; Obtain the system's preset security partition identifier; After aligning the binary partition feature sequence with the security partition identifier code by length, perform a bitwise XOR operation. Extract the first N bits of the operation result to generate a data slice identifier, where N is the available bit length allocated to the slice identifier field in the first region.

[0020] By reading the network interface configuration of the source access node, such as the netlink interface of a Linux system, the IPv4 or IPv6 address information is parsed, and the CIDR-formatted network address prefix and mask prefix are extracted from the routing table. For example, for the IP address 192.168.10.5 / 24, the network address prefix 192.168.10.0 and the mask prefix length 24 are extracted. The network address prefix and mask prefix are then converted into a fixed-length binary partition feature sequence. For example, the network address prefix 192.168.10.0 is converted into a 32-bit address binary sequence, and the / 24 mask prefix is ​​converted into a 32-bit mask binary sequence consisting of 24 consecutive 1s followed by 8 0s. These two are then concatenated into a 64-bit binary partition feature sequence. Simultaneously, the system-preset security partition identifier code is read from the security encryption chip or read-only configuration file. This identifier code is usually a pre-allocated hexadecimal string, such as the identifier code "0xABCD1234" representing the distribution network production control area, and this identifier code is also converted into a corresponding binary sequence.

[0021] After obtaining the two sequences mentioned above, the lengths of the binary partition feature sequence and the security partition identifier code are aligned by padding the shortest sequence with zeros. A bitwise XOR operation is then performed on the two aligned binary sequences, fusing network address attributes, mask attributes, and security attributes. After the operation, based on the pre-allocated available bit length N in the first region of the TCP header options field (preferably 4 to 8 bits, for example, 6 bits), the first N bits of the XOR result are extracted from the high-order bits to the low-order bits as the final data slice identifier; for example, extracting the first 6 bits yields the binary string "101101". This generated N-bit data slice identifier is then filled into the corresponding offset position in the TCP options field, achieving lightweight isolation and identification of different security zones and network slices in the power distribution IoT, such as... Figure 2 As shown.

[0022] S2 collects the trend of changes in the sending queue length and the deviation of the historical sending rate, normalizes them respectively, and then sums them by weight to obtain the forward congestion prediction value. It is written into the second area of ​​the TCP header options and encapsulated into the sent data packet. The receiving end parses the forward congestion prediction value and measures the processing delay of the packet from the network interface to the kernel protocol stack.

[0023] The sending end's operating system kernel periodically reads the difference between the current length and the previous period's length of the network interface card's (NIC) transmission queue as a trend value, and calculates the decaying difference between the historical sliding window average rate and the current transmission rate as the historical transmission rate deviation. A minimum-maximum normalization algorithm is used to map the trend value and the historical transmission rate deviation to a continuous interval of 0 to 1. The normalized values ​​are then weighted and summed using preset linear regression weighting coefficients to obtain the forward congestion prediction value. The sending end converts the calculated forward congestion prediction value into a 16-bit unsigned integer and fills it into the second area immediately adjacent to the first area of ​​the TCP header options field. The network layer IPv4 encapsulation interface is then called to perform header checksum calculation and packet encapsulation, and the data packet is sent via the network device interface. After the receiving network card receives a data packet, it triggers a hardware interrupt. The receiving process strips the IP header, locates the TCP options field, and extracts the forward congestion prediction value by byte offset. At the network card driver level, the receiving end uses a high-precision event timer to record the first timestamp of the packet arrival. The sequence number verification and validation are completed at the TCP layer. After the packet payload is attached to the Socket receive buffer, the second timestamp is obtained. The time difference algorithm is called to calculate the difference between the two timestamps to obtain the protocol stack processing delay.

[0024] In an optional embodiment, the forward congestion prediction value is obtained by normalizing and weighting the trend of change in the collection and transmission queue length and the deviation of the historical transmission rate, including: The number of data packets to be processed at the sending end is collected periodically, and the difference in queue length between two adjacent collection cycles is calculated to obtain the trend value. Record the current transmission rate and calculate the attenuation statistical deviation of the historical average transmission rate relative to the current transmission rate; After normalizing the trend value and the statistical deviation, a weighted sum is performed to obtain the forward congestion prediction value.

[0025] The flow control module in the sending end's operating system kernel uses a fixed timer, preferably with a period of 10ms to 50ms, for example, set to 20ms, to periodically collect the number of pending data packets in the network card's transmission queue. The module calculates the queue length difference by subtracting the number of packets from the previous period from the current period's packet count, using this difference as a trend value. For example, if there are 150 packets in the queue in the current period and 120 packets in the previous period, the trend value is +30, indicating rapid queue backlog. Simultaneously, the module calculates the current transmission rate (in Mbps) by statistically analyzing the current sliding time window, such as the number of bytes sent in the last second. It also retrieves the historical sliding window average rate maintained in system memory over the past 10 seconds and calculates the dimensionless historical transmission rate deviation using the formula (historical sliding window average rate - current transmission rate) / historical sliding window average rate. This deviation represents the degree of attenuation of the current transmission rate relative to the historical average level. For example, if the current rate is 8 Mbps and the historical sliding window average rate is 10 Mbps, then the historical transmission rate deviation is (10-8) / 10=0.2, indicating that the current transmission rate has decreased and there is a potential risk of congestion.

[0026] A Min-Max normalization algorithm is used to map the trend value to the [0,1] interval, where the minimum value is set to -100, representing an empty queue, and the maximum value is set to +100, representing a large backlog in the queue. Similarly, the historical transmission rate deviation is limited to the [-1,1] range and linearly mapped to the [0,1] interval. A positive historical transmission rate deviation indicates rate attenuation, corresponding to a higher congestion risk contribution after normalization; a negative historical transmission rate deviation indicates that the current rate is higher than the historical average rate, corresponding to a lower congestion risk contribution after normalization. Empirical weight coefficients are assigned to the normalized trend value and the historical transmission rate deviation, with the preferred weight configuration being: a weight of 0.7 for the trend value and a weight of 0.3 for the historical transmission rate deviation. The two are then multiplied and summed. For example, if the normalized trend value is 0.65, and the historical transmission rate deviation is 0.2, after a linear mapping from [-1,1] to [0,1], we get 0.6. The weighted sum is then 0.65 × 0.7 + 0.6 × 0.3 = 0.635. This value, after being amplified and rounded, can be multiplied by 100 to get 64, which is the final forward congestion prediction value. This mechanism assesses potential congestion risk before actual packet loss by fusing transient queue backlog and rate decay dimensions.

[0027] In an optional embodiment, the receiving end parses the forward congestion prediction value and measures the processing latency of the packet from the network interface to the kernel protocol stack, including: Obtain the first timestamp that triggers a hardware interrupt when a data packet arrives at the network interface; The kernel protocol stack was successfully obtained, and the second timestamp of the message was stored in the receive buffer. Subtract the first timestamp from the second timestamp to calculate the time difference as the processing delay.

[0028] During the underlying network hardware interaction at the receiving end, when the network interface card (NIC) layer successfully receives a complete data packet and copies it to the circular buffer via DMA, the NIC controller sends a hardware interrupt to the CPU. At this time, the interrupt handler function of the NIC driver is immediately triggered, obtaining the current system time (at the nanosecond level) by calling a high-precision clock interface and recording this current system time as the first timestamp, for example... =1629876543210987ns. The operating system wakes up a soft interrupt to perform bottom-up processing of the network protocol stack, sequentially going through the unpacking and verification processes of the link layer, network layer, and transport layer.

[0029] When the kernel TCP protocol stack completes the sequence number verification, checksum verification, and pairing of the packet, and successfully adds the packet payload to the corresponding socket's receive buffer list for user-space applications to read, the protocol stack processing logic again calls the clock interface to obtain the current time in nanoseconds, which is recorded as the second timestamp. For example... =1629876543261987ns. Perform a subtraction operation, subtracting the first timestamp from the second timestamp to obtain the time difference, for example... =51000ns, or 51 microseconds. This time difference represents the processing latency of the message within the node, indicating the CPU load pressure, interrupt response latency, and memory copy efficiency of the current receiving end's operating system. Figure 3 As shown.

[0030] S3, the receiving end uses the normalized forward congestion prediction value as weight, integrates the normalized processing delay and buffer occupancy rate to generate a comprehensive load feedback value, and constructs an acknowledgment bitmap based on the received sequence number. Combining the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third area of ​​the ACK packet TCP options can carry, it selects the original bitmap, compressed bitmap, or missing sequence number encoding as the acknowledgment information, and writes the comprehensive load feedback value, encoding type identifier, and acknowledgment information into the third area of ​​the ACK packet TCP options. The sending end parses the comprehensive load feedback value and acknowledgment information based on the encoding type identifier, determines the data packets marked as not received or missing sequence number encoding in the acknowledgment bitmap, and prioritizes retransmitting the data packets with the smallest sequence number.

[0031] The receiving end uses an exponentially weighted moving average algorithm to smooth the processing latency and maps it to a standard interval using a minimum-maximum normalization algorithm. It calculates the buffer occupancy rate by reading the ratio of the used space to the total capacity of the system socket receive buffer. After parsing the forward congestion prediction value, the receiving end denormalizes it to a weight factor between 0 and 1 according to a preset range. A weighted arithmetic average algorithm is then used to fuse the normalized processing latency and buffer occupancy rate to generate a comprehensive load feedback value. Specifically, let the normalized forward congestion prediction value be... The normalized processing latency is Cache usage rate First Limited to a preset weight range Inside, obtained ,in The preferred value is 0.3. The preferred value is 0.7; then according to Calculate the normalized composite load value, where, The normalized forward congestion prediction value is γ, which is the forward congestion contribution coefficient, preferably ranging from 0.2 to 0.4. Multiply by 100 and round down to get the comprehensive load feedback value, which ranges from 0 to 100.

[0032] Therefore, the forward congestion prediction value is used to dynamically adjust the proportion of processing latency and buffer occupancy in the overall load calculation, while ensuring that both processing latency and buffer occupancy participate in the calculation, avoiding the complete neglect of a single factor. The receiving end traverses the out-of-order sequence number in the TCP receive window, using the minimum sequence number expected to be received as the starting point, and constructs an acknowledgment bitmap according to the preset acknowledgment unit. The acknowledgment unit corresponds to a TCP segment or a fixed-length data block, rather than directly equating the bit offset to the TCP byte sequence number offset; when using a fixed-length acknowledgment unit, the length of the acknowledgment unit is preferably set to the MSS obtained in the current connection negotiation or the data block length agreed upon by the sender in the options field; when the actual TCP segment length is not fixed, the receiving end maintains an acknowledgment unit length table in the acknowledgment window, so that the starting TCP sequence number corresponding to the i-th acknowledgment unit is BaseSeq plus the sum of the lengths of the previous i acknowledgment units.

[0033] The receiver constructs an acknowledgment bitmap representing the packet reception status by setting the relative offset of successfully received packets to binary 1 and the offset of missing packets to binary 0. The receiver uses threshold-based logic to evaluate the overall load feedback value. When adjusting the compression strategy of the acknowledgment bitmap, the receiver estimates the encoding length of the original acknowledgment bitmap, the run-length encoding result, and the encoding length of the missing sequence number information. This is combined with the remaining bearable bit length after deducting the overall load feedback value field and the encoding type identifier field from the third region of the TCP options in the ACK packet to determine the candidate acknowledgment information format.

[0034] When the overall load feedback value is greater than the set high load threshold and the run-length encoding format belongs to the candidate confirmation information format, the run-length encoding algorithm is selected to compress the confirmation bitmap; when the overall load feedback value is less than or equal to the high load threshold and the native bitmap format belongs to the candidate confirmation information format, the native bitmap mapping strategy is selected; when the run-length encoding format or native bitmap format to be used according to the overall load feedback value does not belong to the candidate confirmation information format, the receiving end extracts the offset positions with a value of 0 in the confirmation bitmap, encodes the offset positions in ascending order or differential mode as missing confirmation unit offset encoding information, associates the current confirmation window's base sequence number and confirmation unit length identifier in the confirmation information, and marks it as missing sequence number encoding format in the encoding type identifier. The missing sequence number encoding format also needs to meet the remaining carryable bit length. If the missing sequence number encoding length in the current confirmation window still exceeds the remaining carryable bit length, the receiving end will reduce the confirmation window length in descending order, regenerate the confirmation bitmap and re-estimate the length of the three types of encoding until at least one confirmation information format meets the remaining carryable bit length. The subsequent reception status not included in the current reduced confirmation window will continue to be fed back in the subsequent ACK message.

[0035] This avoids out-of-bounds errors in the TCP option field of the ACK packet when there are a large number of missing packets. The receiving end calculates the comprehensive load feedback value as an eight-bit integer and concatenates it bit by bit with the encoding type identifier and the acknowledgment information processed by the compression strategy. It then calls the option constructor to store the concatenation result in a data segment with option type 254 in the third area of ​​the ACK packet TCP header and sends it to the sending end. After receiving the ACK packet and parsing the comprehensive load feedback value, the sending end calculates the receiving end load margin status value based on the comprehensive load feedback value. The receiving end load margin status value and the comprehensive load feedback value have an inverse mapping relationship. When the comprehensive load feedback value ranges from 0 to 100, the receiving end load margin status value is 100 minus the comprehensive load feedback value, and this receiving end load margin status value is written into the sending end's local historical ACK feedback record for subsequent priority adjustment. The sending end simultaneously parses the comprehensive load feedback value of the third region to update the local congestion control status, and determines whether the confirmation information is a run-length encoding result, a native confirmation bitmap, or missing sequence number encoding information based on the encoding type identifier in the third region. If it is a run-length encoding result, the run-length decoding algorithm is called to restore the original confirmation bitmap. If it is a native confirmation bitmap, the bitmap scanning process is directly entered. If it is missing confirmation unit offset encoding information, the offset index of the missing confirmation unit is restored according to the ascending order or differential decoding rules, and the offset index is converted into the corresponding original TCP start sequence number according to the base sequence number of the current confirmation window, the fixed confirmation unit length, or the confirmation unit length table.

[0036] When the acknowledgment information is restored to the acknowledgment bitmap, the sending end traverses the acknowledgment bitmap, retrieves the index position with the first bit value of 0, and converts the index position into the corresponding TCP byte sequence number according to the acknowledgment unit length. In the fixed-length acknowledgment unit scenario, the minimum missing sequence number is BaseSeq + i × MSS, where i is the index of the first acknowledgment unit with a bit value of 0, and MSS is the maximum segment length of the current connection or the agreed data block length. In the variable-length acknowledgment unit scenario, the minimum missing sequence number is BaseSeq plus the sum of the lengths of all acknowledgment units before the index. When the acknowledgment information is restored to the missing sequence number, the sending end directly selects the data packet with the smallest sequence number from the restored result, triggers the fast retransmission mechanism before the retransmission timer expires, calls the retransmission function to preferentially inject the buffered data packet corresponding to the sequence number into the sending queue and transmit it outward.

[0037] In an optional embodiment, the step of constructing an acknowledgment bitmap based on the received sequence number, combined with the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third region of the ACK packet TCP options can carry, includes: The preset acknowledgment window is determined based on the remaining bearable bit length after deducting the comprehensive load feedback value field and the encoding type identifier field from the third area of ​​the TCP options in the ACK message, and an acknowledgment bitmap is generated based on the received sequence number within the preset acknowledgment window. Based on the native encoding length, run-length encoding length, and missing sequence number encoding length of the confirmed bitmap, determine the candidate confirmation information format that satisfies the remaining carryable bit length; Determine whether the overall load feedback value is greater than a preset congestion threshold; If it is greater than, and the run-length encoding format belongs to the candidate confirmation information format, then the run-length encoding algorithm is used to compress the confirmation bitmap data; If the value is not greater than the candidate confirmation information format, the native bitmap format is adopted. If the run-length encoding format or native bitmap format to be adopted according to the comprehensive load feedback value is not adopted, the missing sequence number encoding format is used to generate the confirmation information.

[0038] After generating a comprehensive load feedback value, the receiving end normalizes the value range to an integer from 0 to 100. Then, it compares the comprehensive load feedback value with the high load threshold set in the system kernel. The preferred range of the high load threshold is usually set between 70 and 85, for example, 80. When the comprehensive load feedback value is greater than 80 and the run-length encoding format belongs to the candidate acknowledgment information format, it indicates that the current network link or receiving node is in a high-load congestion state. In order to reduce the bandwidth overhead of the reverse link control message, the data compression process is started. The run-length encoding algorithm is used to scan the original acknowledgment bitmap composed of 0 and 1, where 1 indicates that the message has been received and 0 indicates that it has been lost. For consecutive identical bits, the bit is converted into a code pair of "bit value + consecutive number". For example, for the original bitmap "1111100011", which has 10 bits, the run-length encoding will compress the original bitmap into the format of "1(5)-0(3)-1(2)" and then convert it into a specific compact binary byte sequence and store it in the third area of ​​the TCP options to reduce the space occupied by the TCP header option field.

[0039] Conversely, when the overall load feedback value is less than or equal to 80, and the native bitmap format belongs to the candidate acknowledgment information format, it indicates that the network bandwidth is sufficient and the node processing capacity is abundant. In this case, in order to reduce CPU computational overhead and improve the parsing efficiency of the protocol stack, a bitmap mapping strategy is adopted. Starting from the base sequence number of the message, and using the MSS length or the preset data block length as the acknowledgment unit length, the reception status of subsequent non-contiguous data blocks is mapped and assembled into a standard binary string from low to high bits, with each message occupying 1 bit. For example, an 8-bit uncompressed acknowledgment bitmap occupies 1 byte and is stored in the TCP options without any encoding or compression processing. When the original bitmap, run-length encoding, and missing sequence number encoding all exceed the remaining carry-along length of the third area of ​​the TCP options in the current acknowledgment window, the receiver reduces the number of acknowledgment units in the acknowledgment window, for example, from 32 acknowledgment units to 16 or 8 acknowledgment units, and then recalculates the length of each encoding and selects a format that meets the remaining carry-along length. For acknowledgment units not covered by the current ACK, the receiver continues to provide feedback in the next ACK packet. By utilizing this threshold-based compression mechanism, control bandwidth can be saved in congested scenarios, while avoiding additional computational delays under normal network conditions.

[0040] In an optional embodiment, the sending end parses the comprehensive load feedback value and acknowledgment information, and prioritizes retransmitting the data packet with the smallest sequence number indicated by the acknowledgment bitmap as not received or missing sequence number encoding information, including: Parse the confirmation information, restore the confirmation bitmap based on the encoding type identifier or directly locate the missing sequence number, and locate the original sequence number corresponding to all continuous or discrete data blocks marked as not received; Based on the original sequence number, the unreceived data blocks are sorted in ascending order; According to the sorting results, the data blocks with the smallest sequence numbers are added to the head of the retransmission queue for priority retransmission.

[0041] When the sending end's kernel TCP protocol stack receives an ACK packet carrying feedback information, it reads the third area of ​​the TCP options. If the encoding type identifier indicates that the acknowledgment information is a run-length encoded result, it first performs decoding and restores the acknowledgment bitmap bit by bit. If the encoding type identifier indicates that the acknowledgment information is a raw acknowledgment bitmap, it directly parses the raw acknowledgment bitmap bit by bit. If the encoding type identifier indicates that the acknowledgment information is missing sequence number encoded information, it directly decodes to obtain the missing sequence number and skips the acknowledgment bitmap scanning process. For the acknowledgment bitmap format, the expected sequence number indicated in the ACK packet is used as the reference point for the bitmap offset. All marker bits with a value of "0" in the bitmap are scanned, and then the marker bit index is converted into the original TCP byte sequence number according to the acknowledgment unit length. If the acknowledgment unit (ACK) length is fixed (MSS), and the base sequence number is 1000, the MSS is 100 bytes, and the 2nd and 5th bits in the bitmap are 0, then the original TCP start sequence numbers corresponding to the missing ACKs are 1000 + 2 × 100 = 1200 and 1000 + 5 × 100 = 1500, respectively. If the ACK length is not fixed, the sender reads or multiplexes the ACK length table in the ACK window and calculates the corresponding original TCP start sequence number by accumulating the lengths of the preceding ACKs. This allows the location of the original TCP sequence numbers for all consecutive or discrete data blocks that were not successfully identified by the receiver due to network jitter. For example, if the base sequence number is 1000, and the 2nd and 5th bits in the bitmap are 0, then the missing original sequence number blocks are calculated to be 1000 + 2 × 100 = 1200 and 1000 + 5 × 100 = 1500, respectively.

[0042] For missing sequence number encoding formats, the sender directly decodes the missing sequence numbers as the set of original sequence numbers for unreceived data blocks. Using data structures and algorithms such as quicksort or red-black trees, the original sequence numbers of all extracted unreceived data blocks are sorted in ascending order. After sorting, the scheduling module extracts the data block that is first in the sorted result (i.e., the one with the smallest sequence number), clones the corresponding packet data in the sending window buffer, and inserts it into the head of the retransmission queue of the current network interface card driver layer using a header insertion method, without being restricted by the conventional FIFO queue rules.

[0043] If multiple missing packets exist, they are inserted sequentially from largest to smallest sequence number when using the header insertion method, ensuring that the data block with the smallest sequence number is ultimately at the head of the retransmission queue. This retransmission scheduling method reduces buffer blocking at the receiving end due to waiting for earlier lost packets, ensuring that business flows such as distribution network monitoring and control commands can resume normal transmission with minimal delay. The priority retransmission rule prioritizes the recovery of the earliest missing data block in the blocked continuous delivery, without re-determining critical packets based on service type. The transmission priority between different service types is implemented by the composite identifier resolution and queue scheduling mechanism in S1. Furthermore, to illustrate the applicable boundary of the control overhead reduction described in this invention, this invention is not limited to lower overhead than the standard TCP header in every individual TCP packet. Instead, within the distribution IoT communication domain supporting this extended protocol, it replaces the complete service identifier, source address, and partition information with a short-field composite identifier, replaces the fixed-length complete acknowledgment bitmap with run-length encoding or missing sequence number encoding in high-load scenarios, and reduces subsequent redundant retransmissions and receiver head-of-queue blocking by prioritizing the retransmission of the earliest missing data block.

[0044] For normal network conditions where the native bitmap can accommodate the data, this invention allows the selection of the native bitmap to reduce encoding and decoding computational overhead. For high-load conditions or situations with limited ACK option space, this invention controls the length of the extended ACK information by compressing the encoding or reducing the acknowledgment window. Therefore, the overhead reduction described in this invention mainly refers to reducing the occupancy of the extended control field, the occupancy of the reverse acknowledgment feedback, and the overall transmission overhead caused by invalid waiting and redundant retransmissions.

[0045] In a second embodiment, the present invention also proposes a power distribution Internet of Things (IoT) data transmission system, comprising the following modules: The adjustment module is used to parse the service type, source identifier, and network partition information of the business data to be transmitted. Based on the load margin status feedback from historical ACK packets, it adjusts the mapping rules, maps the service type to the priority, encodes the network partition information into a slice identifier, performs a hash calculation on the source identifier, and encodes the priority, slice identifier, and source hash value into a composite identifier according to a preset bit width, and writes it into the first area of ​​the TCP header options. The calculation module is used to collect the trend of changes in the sending queue length and the deviation of the historical sending rate. After normalization, the forward congestion prediction value is obtained by weighted summation. The value is written into the second area of ​​the TCP header options and encapsulated into a data packet for transmission. The receiving end parses the forward congestion prediction value and measures the processing latency of the packet from the network interface to the kernel protocol stack. The generation module is used by the receiving end to generate a comprehensive load feedback value by weighting the normalized forward congestion prediction value, integrating the normalized processing latency and buffer occupancy rate, and constructing an acknowledgment bitmap based on the received sequence number. Combining the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third area of ​​the ACK packet TCP options can carry, the module selects the native bitmap, compressed bitmap, or missing sequence number encoding as the acknowledgment information. The comprehensive load feedback value, encoding type identifier, and acknowledgment information are written into the third area of ​​the ACK packet TCP options. The sending end parses the comprehensive load feedback value and acknowledgment information based on the encoding type identifier, determines the data packets marked as not received or missing sequence number encoding in the acknowledgment bitmap, and prioritizes retransmitting the data packets with the smallest sequence number.

[0046] The above description represents the preferred embodiments of the present invention. It should be noted that, for those skilled in the art, various improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A data transmission method for a power distribution Internet of Things (IoT), characterized in that, include: Parse the service type, source identifier, and network partition information of the service data to be transmitted. Based on the load margin status feedback from historical ACK packets, adjust the mapping rules, map the service type to priority, encode the network partition information into a slice identifier, perform hash calculation on the source identifier, and encode the priority, slice identifier, and source hash value into a composite identifier according to a preset bit width, and write it into the first area of ​​the TCP header options. The forward congestion prediction value is obtained by collecting the trend of the change in the sending queue length and the deviation of the historical sending rate, normalizing them respectively, and then weighted summing them. It is written into the second area of ​​the TCP header options and encapsulated into the sending data packet. The receiving end parses the forward congestion prediction value and measures the processing delay of the packet from the network interface to the kernel protocol stack. The receiving end uses the normalized forward congestion prediction value as a weight, integrates the normalized processing latency and buffer occupancy rate to generate a comprehensive load feedback value, and constructs an acknowledgment bitmap based on the received sequence number. Combining the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third area of ​​the ACK packet TCP options can carry, it selects the original bitmap, compressed bitmap, or missing sequence number encoding as the acknowledgment information, and writes the comprehensive load feedback value, encoding type identifier, and acknowledgment information into the third area of ​​the ACK packet TCP options. The sending end parses the comprehensive load feedback value and acknowledgment information based on the encoding type identifier, determines the data packets marked as not received or missing sequence number encoding in the acknowledgment bitmap, and prioritizes retransmitting the data packets with the smallest sequence number.

2. The method according to claim 1, characterized in that, The process of parsing the service type, source identifier, and network partition information of the service data to be transmitted, and adjusting the mapping rules based on the load margin status feedback from historical ACK packets, maps the service type to priority, including: Read the receiver's load margin status value from the sender's local historical ACK feedback record at fixed time intervals; Calculate the mean coefficient of the historical load margin status values ​​for a preset quantity; Extract the service type identifier of the service data to be transmitted. The service type identifier includes the service protocol label and the service function identifier. When the same service protocol label corresponds to multiple service functions, further read the function code, subject field or message category field in the service header to distinguish between control, status acquisition, alarm or video service types. Based on the service type identifier, match the system's built-in priority mapping table to query the corresponding initial basic weight. The initial base weight is divided by the mean coefficient and rounded down, and then truncated according to the available bit width of the priority field to obtain the target business priority.

3. The method according to claim 1 or 2, characterized in that, Encoding network partition information into slice identifiers includes: Parse the IP address information of the source access node and extract the network address prefix and mask prefix from the routing table corresponding to the source access node; The network address prefix and mask prefix are combined and converted into a binary partition feature sequence; Obtain the system's preset security partition identifier; After aligning the binary partition feature sequence with the security partition identifier code by length, perform a bitwise XOR operation. Extract the first N bits of the operation result to generate a data slice identifier, where N is the available bit length allocated to the slice identifier field in the first region. The slice identifier field, together with the priority field and the source identifier hash field, constitutes the composite identifier.

4. The method according to claim 1, characterized in that, The trend of changes in the collection and transmission queue length and the deviation of the historical transmission rate are normalized and then weighted to obtain the forward congestion prediction value, including: The number of data packets to be processed at the sending end is collected periodically, and the difference in queue length between two adjacent collection cycles is calculated to obtain the trend value. Record the current transmission rate and calculate the attenuation statistical deviation of the historical average transmission rate relative to the current transmission rate; After normalizing the trend value and the statistical deviation, a weighted sum is performed to obtain the forward congestion prediction value.

5. The method according to claim 1, characterized in that, The receiving end parses the forward congestion prediction value and measures the processing latency of the packet from the network interface to the kernel protocol stack, including: Obtain the first timestamp that triggers a hardware interrupt when a data packet arrives at the network interface; The kernel protocol stack was successfully obtained, and the second timestamp of the message was stored in the receive buffer. Subtract the first timestamp from the second timestamp to calculate the time difference as the processing delay.

6. The method according to claim 1, characterized in that, The step of constructing an acknowledgment bitmap based on the received sequence number, combined with the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third region of the ACK packet TCP options can carry, includes: The preset acknowledgment window is determined based on the remaining bearable bit length after deducting the comprehensive load feedback value field and the encoding type identifier field from the third area of ​​the TCP options in the ACK message, and an acknowledgment bitmap is generated based on the received sequence number within the preset acknowledgment window. Based on the native encoding length, run-length encoding length, and missing sequence number encoding length of the confirmed bitmap, determine the candidate confirmation information format that satisfies the remaining carryable bit length; Determine whether the overall load feedback value is greater than a preset congestion threshold; If it is greater than, and the run-length encoding format belongs to the candidate confirmation information format, then the run-length encoding algorithm is used to compress the confirmation bitmap data; If the value is not greater than the candidate confirmation information format, the native bitmap format is adopted. If the run-length encoding format or native bitmap format to be adopted according to the comprehensive load feedback value is not adopted, the missing sequence number encoding format is used to generate the confirmation information.

7. The method according to claim 1, characterized in that, The sending end parses the comprehensive load feedback value and acknowledgment information, and prioritizes retransmitting the data packet with the smallest sequence number indicated by the acknowledgment bitmap as not received or missing sequence number encoding information, including: Parse the confirmation information, restore the confirmation bitmap based on the encoding type identifier or directly locate the missing sequence number, and locate the original sequence number corresponding to all continuous or discrete data blocks marked as not received; Based on the original sequence number, the unreceived data blocks are sorted in ascending order; According to the sorting results, the data blocks with the smallest sequence numbers are added to the head of the retransmission queue for priority retransmission.

8. A power distribution Internet of Things (IoT) data transmission system, characterized in that, include: The adjustment module is used to parse the service type, source identifier, and network partition information of the business data to be transmitted. Based on the load margin status feedback from historical ACK packets, it adjusts the mapping rules, maps the service type to the priority, encodes the network partition information into a slice identifier, performs a hash calculation on the source identifier, and encodes the priority, slice identifier, and source hash value into a composite identifier according to a preset bit width, and writes it into the first area of ​​the TCP header options. The calculation module is used to collect the trend of changes in the sending queue length and the deviation of the historical sending rate. After normalization, the forward congestion prediction value is obtained by weighted summation. The value is written into the second area of ​​the TCP header options and encapsulated into a data packet for transmission. The receiving end parses the forward congestion prediction value and measures the processing latency of the packet from the network interface to the kernel protocol stack. The generation module is used by the receiving end to generate a comprehensive load feedback value by weighting the normalized forward congestion prediction value, integrating the normalized processing latency and buffer occupancy rate, and constructing an acknowledgment bitmap based on the received sequence number. Combining the comprehensive load feedback value, the acknowledgment bitmap encoding length, and the bit length that the third area of ​​the ACK packet TCP options can carry, the module selects the native bitmap, compressed bitmap, or missing sequence number encoding as the acknowledgment information. The comprehensive load feedback value, encoding type identifier, and acknowledgment information are written into the third area of ​​the ACK packet TCP options. The sending end parses the comprehensive load feedback value and acknowledgment information based on the encoding type identifier, determines the data packets marked as not received or missing sequence number encoding in the acknowledgment bitmap, and prioritizes retransmitting the data packets with the smallest sequence number.

9. The system according to claim 8, characterized in that, The process of parsing the service type, source identifier, and network partition information of the service data to be transmitted, and adjusting the mapping rules based on the load margin status feedback from historical ACK packets, maps the service type to priority, including: Read the receiver's load margin status value from the sender's local historical ACK feedback record at fixed time intervals; Calculate the mean coefficient of the historical load margin status values ​​for a preset quantity; Extract the service type identifier of the service data to be transmitted. The service type identifier includes the service protocol label and the service function identifier. When the same service protocol label corresponds to multiple service functions, further read the function code, subject field or message category field in the service header to distinguish between control, status acquisition, alarm or video service types. Based on the service type identifier, match the system's built-in priority mapping table to query the corresponding initial basic weight. The initial base weight is divided by the mean coefficient and rounded down, and then truncated according to the available bit width of the priority field to obtain the target business priority.

10. The system according to claim 8, characterized in that, Encoding network partition information into slice identifiers includes: Parse the IP address information of the source access node and extract the network address prefix and mask prefix from the routing table corresponding to the source access node; The network address prefix and mask prefix are combined and converted into a binary partition feature sequence; Obtain the system's preset security partition identifier; After aligning the binary partition feature sequence with the security partition identifier code by length, a bitwise XOR operation is performed. The first N bits of the operation result are extracted to generate a data slice identifier, where N is the available bit length allocated to the slice identifier field in the first region. The slice identifier field, together with the priority field and the source identifier hash field, constitutes the composite identifier.

Images