Internet of Things interactive system and method based on distributed network collaborative computing

Abstract

The present invention discloses an Internet of Things (IoT) interaction system and method based on distributed in-network collaborative computing. The system includes an IoT cloud platform, sensor nodes, a programmable P4 switch network topology, and a response terminal. The method involves the IoT cloud platform mapping received task requests to the programmable P4 switch network topology using a task mapping strategy. A scheduling algorithm is then used to perform collaborative computing on the switches along the path, providing computational processing and transmission for each switch. This method addresses the issue of high latency, network congestion, and significant transmission overhead associated with sensor data generated by sensor nodes in IoT interactions, leading to erroneous information being sent from the response terminal.

Description

Technical Field

[0001] This invention relates to the field of communications technology, and more specifically, to an IoT interaction system and method based on distributed in-network collaborative computing in the field of data exchange within IoT communications. This invention can be used for communication between IoT response terminals, IoT cloud platforms, programmable P4 switches, and sensor nodes within the IoT. Background Art

[0002] In recent years, the rapid development of wireless sensor networks has driven the application of the Internet of Things (IoT) in fields such as healthcare, transportation, power grids, and smart security. The distributed nature of massive numbers of lightweight devices has greatly facilitated remote on-site monitoring and control of heterogeneous tasks. However, these devices place higher demands on network processing power and stability. Traditionally, this massive amount of data is typically delivered to the application layer of local or cloud servers for centralized processing. Despite the superior computing performance of a single server cluster, the long communication distances between wireless sensor networks, responders, and servers pose significant challenges for latency-sensitive tasks, making traditional centralized computing paradigms difficult to address. On the one hand, sensor devices frequently collect data for parameter updates, while servers receive sequential data packets intermittently. In the event of network congestion or significant transmission overhead, the server cannot guarantee the validity of the currently acquired data, resulting in error messages in the response segment. On the other hand, in harsh environments, if the processing time is long, the limitations of the sensor device's battery power can seriously affect the normal transmission of data packets. Therefore, in order to meet the business requirements of ultra-low latency for the communication of massive sensor data in the Internet of Things when it travels to and from the server application layer, collaborative computing is required during the transmission process to share the server computing pressure and thus provide users with low-latency services.

[0003] Chongqing University of Posts and Telecommunications, in its patent application, "A Cloud-Edge Collaborative Computing Task Offloading Method in an IoT Environment" (application number 202111480882.2, application publication number CN 114301910 A), provides a cloud-edge collaborative computing task offloading method in an IoT environment. This method constructs a collaborative computing system model for the IoT, which includes a device layer, an edge node layer, and a cloud node layer. The method comprises the following steps: First, construct a collaborative computing system model for the IoT, which includes a device layer, an edge node layer, and a cloud node layer; select queuing system models for the device layer, edge node layer, and cloud node layer of the model; Second, construct a total completion delay expectation function for all tasks based on the collaborative computing system model; Third, using the minimum total completion delay expectation as the objective function, the position parameter optimization honey badger algorithm is used to solve the objective function to obtain the required capacity of each queuing system. Each queuing system then adjusts its capacity based on the required capacity adjustment; Fourth, an optimal offloading strategy is obtained based on the adjusted capacity of each queuing system, and tasks are offloaded according to the optimal offloading strategy. The shortcoming of this method is that when it is applied to the Internet of Things for collaborative computing in a distributed network, the massive data brought by a large number of lightweight devices still needs to be delivered to the application layer of the cloud server for processing. However, when the sensor devices frequently collect data for parameter updates and the server intermittently receives serial data packets, once network congestion or huge transmission consumption occurs, the server cannot guarantee the validity of the currently acquired data, causing the responding end to send an error message.

[0004] Chengdu Qinchuan Internet of Things Technology Co., Ltd. provides a method and system for cross-network data interaction in its patent application, "Internet of Things Cross-Network Data Interaction Method and System" (application number 202110682957.9, application publication number CN 113141381 A). The method disclosed in this patent application includes the following steps: first, establishing an Internet of Things; second, establishing any one or more of the service platform, management platform, and sensor network platform on a cloud platform to form an in-network cloud platform; third, when multiple Internet of Things interact with at least one off-network cloud platform through the in-network cloud platform, the off-network cloud platform obtains data from multiple Internet of Things to generate a first database; fourth, when the Internet of Things requests data from the off-network cloud platform, the off-network cloud platform extracts data from the first database based on the request information sent by the Internet of Things and sends it as first data to the Internet of Things. This method enables the formation of big data across industries and fields, while also providing a reliable reference for the application of big data, connecting the information islands formed by different Internet of Things into a whole. However, this method still has the disadvantage that it only considers the problem of data interaction between multiple platforms. In the case of massive lightweight sensor devices, due to the large number of sensor network platforms, although a single server cluster has superior computing performance, when the wireless sensor network, the responder and the server communicate over long distances in harsh environments, if the communication time is long, the battery power limitations of the sensor devices will seriously affect the normal transmission of data packets. The modules of the system disclosed in this patent application include user modules, service modules, management modules, sensor network modules and object modules. The disadvantage of this system is that all data is aggregated on an off-network cloud platform. Any module requesting data needs to obtain data from the off-network cloud platform, which brings huge delays to the interaction between data. Summary of the Invention

[0005] The purpose of the present invention is to address the deficiencies of the above-mentioned existing technologies and propose a system and method for Internet of Things interaction based on distributed network collaborative computing, which is used to solve the problem of high latency consumption, network congestion, and huge transmission consumption of sensor data when communicating to and from the response terminal in Internet of Things interaction, resulting in the response end sending erroneous information.

[0006] To achieve the above objectives, the IoT interactive system of the present invention includes an IoT cloud platform, sensor nodes, a programmable P4 switch network topology, and a response terminal.

[0007] An IoT interactive system includes an IoT cloud platform, sensor nodes, and response terminals; and further includes a programmable P4 switch network topology, wherein:

[0008] The IoT cloud platform is configured to receive task requests from users that meet their needs, map the received task requests to the programmable P4 switch network topology, obtain network topology information and the node status of each switch in real time, and upon receiving task information from users that meet their needs, deploy a task mapping strategy to all P4 programmable switches and distribute the user tasks to the network topology composed of all P4 programmable switches.

[0009] The sensor nodes are used to upload the signals collected by each sensor node that meet the task request to the network topology in the form of data packets;

[0010] The programmable P4 switch network topology consists of N P4 switches distributed near users (N ≥ 3). Using the heterogeneous earliest completion time (HEFT) algorithm, the capabilities of all devices to process data packets and communications are pre-evaluated. While satisfying task requests, each subtask is mapped to a path device with concentrated computing and communication resources. Each data packet uploaded by the sensor is parsed, action matching is performed after parsing, and the updated data packet is sent to the response terminal or the next-hop switch.

[0011] The response terminal is used to control the response object to perform corresponding actions when receiving the data packet instruction transmitted by the P4 switch.

[0012] The method for Internet of Things interaction of the present invention includes the following steps:

[0013] Step 1: The IoT cloud platform receives a user task request to obtain network topology information and the node status of each switch:

[0014] The IoT cloud platform receives task requests from users to meet their needs and maps them to the programmable P4 switch network topology. The IoT cloud platform obtains network topology information and the node status of each switch in real time. The network topology consists of N P4 programmable switches, where N ≥ 3. When receiving task information from users to meet their needs, the cloud platform deploys a task mapping policy to all P4 programmable switches and distributes the user task to the network topology consisting of all P4 programmable switches.

[0015] Step 2: upload the signals collected by each sensor node that meet the task request to the network topology in the form of data packets;

[0016] Step 3: Perform collaborative calculations on the switches on the path using a scheduling algorithm:

[0017] The Heterogeneous Earliest Finish Time (HEFT) algorithm pre-evaluates the capabilities of all devices in processing data packets and communications, and maps each subtask to a path device with concentrated computing and communication resources while satisfying the task request.

[0018] Step 4: Provide computing processing and transmission for each switch:

[0019] Parse each data packet uploaded by the sensor, perform action matching after parsing, and send the updated data packet to the response terminal or the next-hop switch;

[0020] Step 5: When the response terminal receives the data packet instruction transmitted by the P4 switch, it controls the response object to take corresponding actions.

[0021] Compared with the prior art, the present invention has the following advantages:

[0022] First, the system of the present invention adopts a network topology of programmable P4 switches, which consists of N P4 switch devices distributed near the user. Through a scheduling algorithm, each subtask in the task request is mapped to a path device where computing and communication resources are concentrated, and each data packet uploaded by the sensor is collaboratively calculated, processed and transmitted. This overcomes the shortcomings of the prior art in which massive data brought by massive lightweight devices still needs to be delivered to the application layer of the cloud server for processing, resulting in high latency and high transmission consumption. The present invention enables low-latency, low-power and high-throughput data collection, processing and transmission from massive devices.

[0023] Second, the method of the present invention uses a scheduling algorithm to perform collaborative calculations on switches on the path. Through the scheduling algorithm, the ability of all devices to process data packets and communications is pre-evaluated. While satisfying task requests, each subtask is mapped to a path device with concentrated computing and communication resources. This overcomes the network congestion caused by massive communication processing data, enabling the method of the present invention to improve the quality of interaction.

[0024] Third, the method of the present invention adopts an Internet of Things cloud platform to map the received task requests to the programmable P4 switch network topology through a task mapping strategy, and maps the task requests to the specific switch nodes under the shortest path through node mapping and edge mapping, overcoming the high latency disadvantage caused by the long communication distance of the existing technology, so that the method of the present invention can optimally allocate communication data. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 Schematic diagram of the structure of the system of the present invention;

[0026] Figure 2 is a flow chart of the method of the present invention;

[0027] Figure 3 Schematic diagram of the task model of the simulation experiment of the present invention;

[0028] Figure 4 The P4 network topology diagram of the simulation experiment of the present invention;

[0029] Figure 5 This is a delay comparison diagram of three computing paradigms in the simulation experiment of the present invention;

[0030] Figure 6 This is a delay comparison chart of different algorithms in the simulation experiment of the present invention; Figure 6 (a) is a delay comparison diagram based on different data packet sizes in the simulation experiment of the present invention, Figure 6 (b) is a delay comparison diagram based on different tasks in the simulation experiment of the present invention. DETAILED DESCRIPTION

[0031] The present invention is further described in detail below with reference to the accompanying drawings and embodiments.

[0032] Reference Figure 1 The system of the present invention is described in further detail.

[0033] The IoT interactive system of the present invention includes an IoT cloud platform, sensor nodes, a programmable P4 switch network topology, and a response terminal.

[0034] The IoT cloud platform is configured to receive task requests from users to meet their needs, map the received task requests to the programmable P4 switch network topology, and obtain network topology information and the node status of each switch in real time. Upon receiving task information from a user to meet their needs, the cloud platform deploys a task mapping policy to all P4 programmable switches, distributing the user's task to the network topology composed of all P4 programmable switches.

[0035] The sensor nodes are used to upload the signals collected by each sensor node and meeting the task request to the network topology in the form of data packets.

[0036] The programmable P4 switch network topology consists of N P4 switch devices distributed near users, where N is greater than or equal to 3. As a more convenient network computing element, the P4 switch mainly exhibits low latency, low power consumption, and high throughput, and has the characteristics of wide distribution range and low deployment cost. This means that tasks can be offloaded to the switch anytime and anywhere, and the device can receive decentralized intelligence data. Based on the programmable P4 data plane programming strategy, packet computing and packet forwarding tasks are preferentially completed at the network layer close to the data source in a manner of data packet unpacking, processing, encapsulation, and transmission. Compared with uploading to the server, the reception and feedback time of the task packet is shortened.

[0037] The operating principle of a P4 switch can be described using its abstract forwarding model, which primarily consists of a parser, a deparser, and a matching action table connected by a metadata bus. When a packet enters a switch port, it is first intercepted by the parser. The parser then relies on parsing techniques within the parsing graph to separate the packet header from the payload. Unlike the payload, the header also defines many different types of data, which are extracted and used for subsequent matching. Furthermore, the header structure and parsing process can be flexibly defined based on the task data required by the task request. After parsing, the resulting data is processed through a multi-stage pipeline. This multi-stage pipeline is a logical connection between multiple matching action tables based on control flow (queuing, replication, and scheduling). It records data state changes between tables and is driven by the control plane. The matching action table contains keywords, actions, and operation data. A match between a keyword and an extracted header field triggers the corresponding action, resulting in the modification, addition, or deletion of header data. The modified fields are stored as temporary variables in the metadata. After this stage is completed, the deparser reassembles the packet for transmission during the deparse phase.

[0038] The development process steps for P4 switches are as follows:

[0039] The first step is to customize the relevant task programs according to the P4 standard, including data frame parsing, matching action table definition and packet flow control process. In particular, the task processing behavior is defined in the matching action table.

[0040] The second step is to compile the P4 program to obtain the switch's binary configuration file and runtime API (switch function driver).

[0041] The third step is to load the configuration file into the corresponding switch chip Tofino and update the data frame parsing status and the content of the matching action table.

[0042] In the fourth step, the switch receives the external data packet, traverses the updated matching action table, and executes the command action. At the same time, it adds, deletes, modifies, and queries table entries under flow control.

[0043] Taking a single sensor, a single switch, and a single responder as an example, when a task request is issued, the logical processing flow of the P4 switch for the task can be described as follows: When the sensor sends an original data packet containing task data1, the switch processes data1 to generate a current data packet containing the trigger command data2, which is then forwarded to the responder before the task completes. Note that the command takes effect only if the format of data2 in the current data packet matches the pre-command format of the responder; otherwise, it fails. Therefore, as the executor of task packet processing, the switch must also perform format determination and reshaping of the packet data. The switch's lookup table defines the format and task data fields; the action set defines format determination (If), generate (Generate), and specific task execution (IoT Action), each stored in a separate table. The If operation determines whether the packet format meets the consistency requirements; the Generate operation reshapes packets that do not meet the requirements into the new format; and the IoT Action contains the specific task processing operations. When the switch receives the original data packet, it parses the header and payload, first matching the format field in the header with the fields in the lookup table and executing the corresponding if action. If the if judgment condition is not met, the generate field in the table is matched and the Generate action is executed. If the if judgment condition is met, the other fields in the packet header are matched with the corresponding task data fields in the table, and then the IoT Action operation is performed. Finally, the de-parsed current data packet is sent to the responding end or the next-hop switch.

[0044] The Heterogeneous Earliest Finish Time (HEFT) algorithm pre-evaluates the packet processing and communication capabilities of all devices. While satisfying task requests, each subtask is mapped to a path device with concentrated computing and communication resources. Each data packet uploaded by the sensor is parsed, action matching is performed, and the updated data packet is sent to the response terminal or next-hop switch.

[0045] The response terminal is used to control the response object to perform corresponding actions when receiving the data packet instruction transmitted by the P4 switch.

[0046] Reference Figure 2 The method of the present invention is described in further detail.

[0047] Step 1: The IoT cloud platform receives the user's task request to obtain the network topology information and the node status of each switch.

[0048] The IoT cloud platform receives task requests from users to meet their needs and maps them to the programmable P4 switch network topology. The IoT cloud platform obtains real-time network topology information and the node status of each switch. The network topology consists of N P4 programmable switches (N ≥ 3). Upon receiving task information from users, including the measurement data and calculation methods required to meet their needs, the cloud platform issues the computational tasks to all P4 programmable switches.

[0049] Generally speaking, a complete computing task has multiple independent functional modules, each of which is equivalent to a logically complete subtask. In particular, the task dependency constraints between subtasks, that is, the temporal execution priority relationship between predecessor and successor tasks, can be clearly expressed using a DAG. The DAG-driven IoT monitoring task is abstractly described as G = (M, E), where M and E are defined as the set of IoT subtasks and the set of directed edges associated with IoT subtasks, respectively. s ,w s+1 ,…,w l-1 ,w l |s≥1,l>s+1},w1,w2,…,w s Characterize the entry task; w s+1 ,…,w l-1 Characterize the relay task, w l Represent the export task. The entry, relay, and export tasks are independent of each other, and the processing logic of each subtask is different from other tasks. In addition, the forward subtask set of the relay or target task is represented by Φ ↑ (w i )={w j |(w j ,w i )∈E}. The edge weight in E represents the task processing delay, and the edge direction represents the forwarding direction of the data packet.

[0050] The network topology generated by a group of P4 switches can be represented by UG, that is, N = (V, K). Where V = {v1, v2, ..., v s ,v s+1 ,…,v t-1 ,v t |s≥1,t>s+1} is the set of all P4 processing nodes, K is the set of edges of N. To facilitate DAG task mapping, v1,v2,…,v s As the starting processing node, v s+1 ,…,v t-1 As a relay processing node, v tAs the target processing node. The edges between nodes are undirected edges, allowing bidirectional forwarding of data packets. If the graph N is a connected graph, its point cut set is Represented by its edge cut set Represented by ω(N), the number of connected branches is represented by ω(N). When the minimum vertex cut set or the minimum edge cut set in the graph N is removed to make it disconnected, the number of removed vertices or edges is called vertex connectivity or edge connectivity, respectively. Vertex connectivity or edge connectivity is usually used to measure the anti-destruction performance of the network topology. Among them, vertex connectivity is represented by The edge connectivity is expressed as In addition, given from v i to v j The minimum delay in transmitting a unit of data, that is, and will Based on The shortest path obtained. Therefore, the shortest path set is obtained accordingly, that is Considering the direct or indirect connectivity between nodes, using their edge weights and node dependencies, and relying on the single-source shortest path Dijkstra algorithm, we can get and Secondly, the longest path from the starting node to the target node is called the critical path.

[0051] Based on the above definition, a task mapping strategy with the processing layer switch as the target device is deployed on the cloud platform, including node mapping and edge mapping rules.

[0052] The node mapping is the deployment strategy of the IoT task in the P4 cluster. Define ζ:M→V, where ζ represents the set of nodes deployed for the IoT task. The mapping result is expressed as:

[0053]

[0054] The mapping result is to transform the entry tasks w1,w2,…,w s Mapped to the starting processing nodes v1, v2, ..., v of P4 s ; Relay task w s+1 ,…,w l-1 Mapped to relay processing node v s+1 ,…,v t-1 ; Export task w l Mapped to target processing node v t .

[0055] The edge mapping, that is, the mapping of the directed edges of the DAG tasks to the undirected edges of the UG, defines ψ:E→K, where ψ represents the edge mapping set that satisfies the following relationship:

[0056]

[0057] where ψ maps all directed edges in E to the shortest paths between nodes.

[0058] Through the above task mapping strategy, the cloud platform sends user tasks to the network topology composed of all P4 programmable switches.

[0059] Step 2: Upload the signals collected by each sensor node that meet the task requirements to the network topology in the form of data packets.

[0060] Step 3: Perform collaborative calculations on the switches on the path through a scheduling algorithm.

[0061] The fluctuating delay caused by the diversity of task mapping needs to be optimized, and a mathematical model with delay as the optimization target is constructed. During task processing, the total delay T of a P4 switch to the next hop switch or the target switch is sum is the maximum time span on its shortest path, which includes processing delay and cumulative delay. Its delay model is expressed as:

[0062] T sum (w i )=T proc (w i )+T accu (w i )

[0063] Where: Processing delay T proc (w i ) is the device processing task w i The time consumed is expressed as:

[0064]

[0065] in: is the size of the processed data packet, α is the logical complexity of the task, is the processing capability of the device, the cumulative delay T accu (w i ) represents the time consumed by the subtask before the current switch node starts processing, specifically the sum of the total delay, transmission delay, and queue delay of the forward subtask, expressed as:

[0066]

[0067] Where: T trans represents the transmission delay, which can be expressed as:

[0068]

[0069] in: Indicates the minimum delay for transmitting unit data between two mapping nodes. Indicates the size of the data packet currently being transmitted, queue delay T que Refers to the time a packet waits in the queue before being transmitted, which can be expressed as:

[0070]

[0071] Where: L is the packet length, I que is the average queue length, and B is the transmission rate. Since the communication distance when multiple switches collaborate on computing is short, the impact of propagation delay can be ignored.

[0072] From the above delay model, we can know that the output delay of the target node is the total delay consumed by the task graph G, which can be expressed as:

[0073] T sum (G)=T sum (w l )

[0074] Considering the random factors of the DAG to UG mapping results, a mapping matrix is ​​defined to uniformly represent all mapping relationships. The mapping matrix is ​​expressed as:

[0075]

[0076] in: Represents the mapping results of all subtasks and P4 switches. If its value is 1, then the subtask w p Deployed to the network topology q Node; if its value is 0, then the subtask w p Not deployed to v q Node, that is

[0077] Combined with the mapping principle, the representation of the delay model is updated as follows:

[0078]

[0079]

[0080] Therefore, T sum (G) can be expressed as a function of X, that is, T sum (G) = F(X);

[0081] In summary, in order to find the best mapping result from the mapping matrix, the following latency optimization model is established:

[0082]

[0083] To further achieve the optimization goal based on mapping optimization, a table scheduling algorithm based on the Heterogeneous Earliest Finish Time (HEFT) algorithm is employed. This algorithm is suitable for solving low-complexity multi-task scheduling problems with task dependencies in multi-device collaborative scenarios. It pre-evaluates the packet processing and communication capabilities of all devices. While satisfying the overall task dependencies, it maps each task to a path switch with concentrated computing and communication resources, thereby reducing the total completion time of consecutive tasks. Its design concept consists of two phases: prioritizing tasks of the same level and scheduling them.

[0084] In the task sorting stage, the average processing time that needs to be referred to is expressed as:

[0085]

[0086] in: Represents task w i The average processing time, m is the total number of switches, e i,j For switch v j Run the task w i The average communication cost for reference is expressed as: in: Represents subtask w i Execute to w j The average communication cost of data packet transmission. is the average startup time of the device, is the data size of the data packet, is the average transmission rate between devices.

[0087] The ranking value of a task is expressed as:

[0088]

[0089] Where: r(w i ) represents subtask w i The critical path length between the task and the exit task, where the task with the higher ranking value is scheduled first. s(w i ) represents subtask w i A set of direct successor subtasks; for the export task, its ranking value can be expressed as:

[0090]

[0091] In the task scheduling stage, the task w is obtained by mapping the optimization model and the delay model representation. i The earliest completion time e when executing on each device ft , and select the smallest e ft The corresponding device performs task scheduling.

[0092] The steps of the scheduling algorithm are as follows:

[0093] The first step is to obtain the average processing time and average communication cost of all subtasks under the current task request;

[0094] The second step is to traverse the sorting values ​​of all subtasks. The ones with higher sorting values ​​are scheduled first. They are sorted in a non-increasing manner and stored in the task sorting list.

[0095] The third step is to select the first unscheduled subtask in the task sorting list, find the switch that can complete the subtask in the shortest time, and schedule the subtask on that switch.

[0096] Step 4: Determine whether there are any unscheduled subtasks in the task sorting list. If so, execute step 3; otherwise, execute step 5.

[0097] In the fifth step, all subtasks have been scheduled on a specific switch to complete the scheduling of all subtasks under the current task request in the shortest time.

[0098] Step 4: Provide computing processing and transmission for each switch:

[0099] Each data packet uploaded by the sensor is parsed, action matching is performed after parsing, and the updated data packet after processing is sent to the response terminal or the next hop switch.

[0100] The steps of parsing each data packet are as follows: extracting relevant fields after identifying the packet header, and splitting the data packet into the packet header and the payload outside the packet header.

[0101] The steps of the action matching process are:

[0102] In the first step, the packet header keyword is input into the matching action table composed of the keyword and action, and the data packets that fail to match are discarded;

[0103] The second step is to calculate and process the payload of the successfully matched data packet according to the action corresponding to the matching action table;

[0104] The third step is to assemble the separately processed header and payload into an updated data packet.

[0105] The step of sending the processed updated data packet to the responding end or the next-hop switch is as follows: when a data packet is loaded into the switch port, the packet header and the payload outside the packet header are separated, the destination address of the packet header is matched with the routing table of the destination address and the switch combination, and the updated data packet with successful matching is sent to the responding end or the next-hop switch.

[0106] Step 5: When the response terminal receives the data packet instruction transmitted by the P4 switch, it controls the response object to take corresponding actions.

[0107] The corresponding actions include any one of display, protection, alarm, start and stop.

[0108] The effect of the present invention can be further demonstrated through the following simulation.

[0109] 1. Simulation experimental conditions.

[0110] This simulation was conducted using the Python software platform to verify the feasibility of the collaborative computing method within the network. The computer used for the test had an i5-7200U CPU and 8.00GB of memory.

[0111] In the application scenario of the simulation experiment of the present invention, the logical processing methods within different tasks are diverse. In order to maintain generality, three DAG task models with different dependencies are designed in comparison with real task examples, such as Figure 3 As shown in the figure, different numbers represent different nodes.

[0112] In order to meet the characteristics of random distribution of switches in actual scenarios, the Python platform is used to generate four irregular network topologies divided by edge connectivity. The network topology is composed of 10 switches, such as Figure 4 As shown in the figure. The number on each switch in the figure indicates the number of edges associated with it. According to the definition of edge connectivity, the edge connectivity of network topologies I, II, III, and IV is 4, 3, 2, and 1, respectively.

[0113] The parameters used in the simulation experiment of the present invention, such as link transmission rate and device processing capacity parameters, are basically set with reference to the actual requirements of the switch working in a 4G (10-100Mbps) network, but do not take into account the delay consumption of retransmission after packet loss during transmission.

[0114] The specific settings of the simulation experiment parameters of the present invention are shown in Table 1.

[0115] Tab.1Simulation parameters table

[0116]

[0117]

[0118] 2. Simulation content and result analysis.

[0119] The simulation experiment 1 of the present invention adopts the collaborative computing based on HEFT algorithm of the present invention and two existing technologies (local computing and cloud computing), using Figure 3 The Task 2 model shown and Figure 4 The network topology II shown in the figure evaluates the delay of the three calculation methods. Each P4 node is set to receive the same data packet size, and the delay is tested and evaluated. As the data packet size increases from small to large, the delay results of the three methods and their links are shown in the figure below. Figure 5 As shown, Figure 5 The horizontal axis is the size of the data packet, and the vertical axis is the delay. The solid line marked with a circle represents the simulation result of the delay obtained using the collaborative computing method, the dotted line marked with a circle represents the in-network computing transmission link, the solid line marked with a triangle represents local computing, the dotted line with a triangle represents the local computing transmission link, the vertical solid line represents cloud computing, and the vertical dotted line represents the cloud computing transmission link.

[0120] Figure 5 The results show that under the same load, compared with the other two computing modes, the delay of in-network collaborative computing is the smallest and the reduction in link delay is the largest. For example, when the packet load is 1000Byte, its link delay is reduced by about 28.27ms and 69.91ms compared with local computing and cloud computing, respectively. When the load is small, since the computing power of local and cloud exceeds that of in-network collaborative computing, it can make up for the shortcomings caused by the long transmission distance to a certain extent. However, as the packet load increases, its computing advantage is significantly reduced and the transmission consumption gradually increases. The delay of in-network collaborative computing is the opposite. When the packet load increases from 200Byte to 1000Byte, the delay only increases by 3.27ms. Therefore, the method proposed in the present invention solves the transmission loss problem of packet forwarding and can better meet the low-latency requirements of packet computing tasks.

[0121] The simulation experiment 2 of the present invention uses the scheduling algorithm based on the HEFT algorithm of the present invention and three existing scheduling algorithms (weighted round-robin WRR algorithm, greedy load balancing Greedy-LB algorithm and random dynamic Pick-KX algorithm), and evaluates the delay of the four algorithms from two aspects: one is the size of the processed data packet, and the other is different task types. Figure 4 The topology III structure is simulated, and the results are as follows Figure 6 As shown, Figure 6 The purple column represents the Greedy-LB algorithm, the blue column represents the Weighted Round Robin (WRR) algorithm, the green column represents the Pick-KX algorithm, and the red column represents the HEFT task scheduling algorithm. Figure 6 (a) is the result obtained using the Task 2 model.

[0122] In simulation experiment 2, the three existing technologies used are:

[0123] Existing technology 1 refers to an improved WRR independent task scheduling algorithm proposed by Liu Lindong in his published paper "Research on an Improved WRR Independent Task Scheduling Algorithm" (Journal of Guangdong Second Normal University, 2020, 40(03):89-93), referred to as the weighted round-robin (WRR) algorithm.

[0124] Existing technology 2 refers to a greedy load balancing algorithm mentioned by Zheng Zhongbin et al. in their paper "Research on Computation Offloading Strategy of 5G Cloud Network Architecture Based on Edge Computing" (Adhesion, 2021, 47(08): 97-101), which is a greedy load balancing (Greedy-LB) algorithm.

[0125] Existing technology 3 refers to a random dynamic load balancing algorithm mentioned in the paper "Cloud-Mist Network for Medical Big Data and Its Distributed Computing Solution" published by He Xiuli et al. (Journal of Xi'an Jiaotong University, 2016, 50(10):71-77), referred to as the random dynamic (Pick-KX) algorithm.

[0126] Figure 6 The results in (a) show that regardless of the packet size, the HEFT algorithm consistently achieves lower latency than the other three scheduling algorithms. For example, when the packet size is 1200 bytes, the HEFT algorithm's latency performance improves by 25.6%, 47.9%, and 54.3% over the Greedy-LB algorithm, the WRR algorithm, and the Pick-KX algorithm, respectively.

[0127] In order to prove that the algorithm of the present invention is applicable to different task models, Figure 6 The corresponding simulation results are given in (b). It can be seen that there is a certain gap in the delay of the four algorithms when applied to the three task models (with the same number of subtasks), among which task 3 has the lowest delay and task 1 has the highest delay. This result is caused by the number of subtasks on the critical path. Compared with tasks 1 and 2, task 3 has the least number of subtasks on this path, so it consumes the shortest time. In addition, no matter which task model is adopted, the HEFT algorithm has lower delay than other algorithms. The main reason is that the Pick-KX algorithm does not consider the packet forwarding capability of the device when scheduling subtasks to nodes. Although the WRR algorithm and the Greedy-LB algorithm have made some improvements on this issue, they ignore the communication overhead of the device network link. In contrast, the HEFT algorithm used in the present invention takes the computing and communication overhead of the device as optimization indicators, comprehensively improves the utilization of resources, and thus makes up for the above-mentioned defects.

Claims

1. An Internet of Things interactive system based on distributed in-network collaborative computing, comprising an Internet of Things cloud platform, sensor nodes, and response terminals; characterized in that: Also included is a programmable P4 switch network topology where: The IoT cloud platform is configured to receive task requests from users that meet their needs, map the received task requests to the programmable P4 switch network topology, obtain network topology information and the node status of each switch in real time, and upon receiving task information from users that meet their needs, deploy a task mapping strategy to all P4 programmable switches and distribute the user tasks to the network topology composed of all P4 programmable switches. The sensor nodes are used to upload the signals collected by each sensor node that meet the task request to the network topology in the form of data packets; The programmable P4 switch network topology consists of N P4 switches distributed near users (N ≥ 3). The heterogeneous earliest completion time (HEFT) algorithm pre-evaluates the packet processing and communication capabilities of all devices. While satisfying task requests, each subtask is mapped to a path device with concentrated computing and communication resources. The implementation steps are as follows: The first step is to obtain the average computational cost and average communication cost of all subtasks under the current task request; The second step is to traverse the sorting values ​​of all subtasks. The ones with higher sorting values ​​are scheduled first. They are sorted in a non-increasing manner and stored in the task sorting list. The third step is to select the first unscheduled subtask in the task sorting list, find the switch that can complete the subtask in the shortest time, and schedule the subtask on that switch. Step 4: Determine whether there are any unscheduled subtasks in the task sorting list. If so, execute step 3; otherwise, execute step 5. In the fifth step, all subtasks have been scheduled on a specific switch to complete the scheduling of all subtasks under the current task request in the shortest time; Each data packet uploaded by the sensor is parsed, and action matching processing is performed after parsing, and the updated data packet is sent to the response terminal or the next-hop switch. The action matching processing steps are as follows: first, inputting the packet header keyword into a matching action table composed of the keyword and action for matching, and discarding the data packet that fails to match; second, calculating the payload in the matching data packet according to the action corresponding to the matching action table; third, assembling the processed packet header and payload into an updated data packet; The response terminal is used to control the response object to perform corresponding actions when receiving the data packet instruction transmitted by the P4 switch.

2. A method for Internet of Things interaction based on distributed in-network collaborative computing according to the interactive system of claim 1, characterized in that: The IoT cloud platform maps received task requests to a programmable P4 switch network topology using a task mapping strategy. It then uses a scheduling algorithm to perform collaborative computations on switches along the path, providing computation processing and transmission for each switch. The method includes the following steps: Step 1: The IoT cloud platform receives a user task request to obtain network topology information and the node status of each switch: The IoT cloud platform receives task requests from users to meet their needs and maps them to the programmable P4 switch network topology. The IoT cloud platform obtains network topology information and the node status of each switch in real time. The network topology consists of N P4 programmable switches, where N ≥ 3. When receiving task information from users to meet their needs, the cloud platform deploys a task mapping policy to all P4 programmable switches and distributes the user task to the network topology consisting of all P4 programmable switches. Step 2: upload the signals collected by each sensor node that meet the task request to the network topology in the form of data packets; Step 3: Perform collaborative calculations on the switches on the path using a scheduling algorithm: The Heterogeneous Earliest Finish Time (HEFT) algorithm pre-evaluates the data packet processing and communication capabilities of all devices. While satisfying task requests, each subtask is mapped to a path device with concentrated computing and communication resources. The implementation steps are as follows: The first step is to obtain the average computational cost and average communication cost of all subtasks under the current task request; The second step is to traverse the sorting values ​​of all subtasks. The ones with higher sorting values ​​are scheduled first. They are sorted in a non-increasing manner and stored in the task sorting list. The third step is to select the first unscheduled subtask in the task sorting list, find the switch that can complete the subtask in the shortest time, and schedule the subtask on that switch. Step 4: Determine whether there are any unscheduled subtasks in the task sorting list. If so, execute step 3; otherwise, execute step 5. In the fifth step, all subtasks have been scheduled on a specific switch to complete the scheduling of all subtasks under the current task request in the shortest time; Step 4: Provide computing processing and transmission for each switch: Parse each data packet uploaded by the sensor, perform action matching after parsing, and send the updated data packet to the response terminal or the next-hop switch; The steps of the action matching process are: In the first step, the packet header keyword is input into the matching action table composed of the keyword and action, and the data packets that fail to match are discarded; The second step is to calculate and process the payload of the successfully matched data packet according to the action corresponding to the matching action table; The third step is to assemble the processed header and payload into an updated data packet; Step 5: When the response terminal receives the data packet instruction transmitted by the P4 switch, it controls the response object to take corresponding actions.

3. The Internet of Things interaction method based on distributed in-network collaborative computing according to claim 2, characterized in that: The task information that satisfies one's own needs described in step 1 refers to the measurement data and the calculation method of the data that the user needs to achieve his or her own needs.

4. The method for Internet of Things interaction based on distributed in-network collaborative computing according to claim 2, characterized in that: The task mapping strategy described in step 1 is a mapping strategy with the P4 switch as the target device. This strategy includes node mapping and edge mapping rules. Task node mapping maps the ingress task to the starting processing node of P4, the relay task to the relay processing node, and the egress task to the target processing node. Edge mapping represents the shortest path from which all directed edges are mapped to nodes.

5. The Internet of Things interaction method based on distributed in-network collaborative computing according to claim 2, characterized in that: The steps for parsing each data packet described in step 4 are as follows: after identifying the packet header, extract the relevant fields and split the data packet into the packet header and the payload outside the packet header.

6. The Internet of Things interaction method based on distributed in-network collaborative computing according to claim 2, characterized in that: The steps of sending the processed updated data packet to the responding end or the next-hop switch described in step 4 are: when a data packet is loaded into the switch port, the packet header and the payload other than the packet header are separated, the destination address of the packet header is matched with the routing table of the destination address and the switch combination, and the updated data packet with successful matching is sent to the responding end or the next-hop switch.

7. The Internet of Things interaction method based on distributed in-network collaborative computing according to claim 2, characterized in that: The corresponding actions described in step 5 include any one of display, protection, alarm, start and stop.

Images