A cluster processing method and system of intelligent internet-of-things equipment

Abstract

The application belongs to the technical field of Internet of Things, and discloses a cluster processing method and system of intelligent Internet of Things equipment, which is based on a heterogeneous device network running a PIM-SM multicast protocol, and first realizes high-computing-power equipment state synchronization through an improved IGMP message, and actively notifies a "assistable" state to a convergence point (RP) by an access router thereof, and pre-establishes a multicast path. When a low-computing-power equipment initiates a "help-seeking" request, an access router thereof quickly discovers available assist resources through the RP, and triggers a shortest path tree (SPT) switching, and establishes a directional "help-seeking-assist" logical path. The system accurately selects a target assist node according to real-time load, device computing power and other strategies, and completes point-to-point scheduling of a task through a "directional assist request" message. The application realizes efficient, low-delay and low-signaling-overhead computing power collaboration between heterogeneous devices, and is particularly suitable for intelligent agricultural and other clearly-defined Internet of Things scenes.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, and particularly relates to a cluster processing method and system for intelligent IoT equipment. Background Technology

[0002] In large-scale farmland and smart agricultural parks, intelligent IoT equipment with data acquisition capabilities (such as smart wells) are widely deployed. These devices exhibit performance heterogeneity due to differences in cost and computing power: some high-computing-power devices can independently complete complex analysis tasks (such as soil moisture analysis and pest and disease identification), while many low-computing-power devices only have basic data acquisition functions and cannot independently handle advanced tasks. Existing systems lack an efficient cross-device computing power collaborative scheduling mechanism. When low-computing-power devices require complex analysis, they often search for idle high-computing-power devices through global broadcasting or central server queries. This approach has the following drawbacks: 1) High response latency, making it difficult to meet the real-time requirements of agricultural analysis; 2) Generating a large amount of network signaling, excessively consuming network and device resources; 3) Request flooding leads to inefficiency, making it impossible to accurately and quickly schedule tasks to the most suitable idle resources.

[0003] Therefore, there is an urgent need for a technical solution that can efficiently, accurately, and with low disturbance achieve collaborative scheduling of computing power among heterogeneous IoT devices. Summary of the Invention

[0004] The purpose of this invention is to provide a cluster processing method and system for intelligent IoT equipment to solve the above-mentioned technical problems.

[0005] To address the aforementioned technical problems, the specific technical solution of the cluster processing method and system for intelligent IoT equipment of the present invention is as follows:

[0006] A cluster processing method for intelligent IoT equipment, applied to a heterogeneous device network based on the PIM-SM multicast protocol and equipped with a rendezvous point RP, includes the following steps:

[0007] Step 1: The high-computing-power equipment periodically sends IGMP join messages carrying its own status to the directly connected router. When the router has an idle high-computing-power equipment connected, it sends a "help announcement" multicast message to the RP and pre-builds a multicast path to the RP.

[0008] Step 2: When low-computing-power equipment needs assistance, it sends an IGMP join message with a "help" status to the directly connected router, which then sends a "help" PIM join message to the RP.

[0009] Step 3: The RP forwards the received "Assistance Announcement" message to the helper router, triggering it to perform SPT handover to each helper router and establish (s,g) multicast paths from the helper router to each helper router.

[0010] Step 4: The requesting router selects the target assisting router according to the preset policy and sends a "directed assistance request" message to the target assisting router along the corresponding (s, g) path, so that the router can select an idle high-computing-power equipment to perform the task.

[0011] Step 5: When there are no available high-performance computing devices under the assisting router, send a "Cancel Assistance" message to update the path; if the path is invalid, request the assisting router to redirect based on other paths.

[0012] Furthermore, the "Assistance Announcement" multicast message, the "Request for Help" PIM join message, and the "Withdraw Assistance" message all use the same preset multicast address.

[0013] Furthermore, the "Assistance Announcement" multicast message carries the identifier of the sending router and the number of idle high-performance computing devices connected to it.

[0014] Furthermore, the SPT handover in step three specifically includes: the helper router copies the helper device information from the (*, G) entry to the newly created (s, g) entry, and sends a "help" PIM join message carrying the information to the assisting router.

[0015] Furthermore, the preset strategy described in step four includes: selecting a target assisting router based on the IP address order of the assisting router, the number of idle high-computing-power devices, or load balancing principles.

[0016] Furthermore, in step four, the “targeted assistance request” message carries the identifier of the target assisting router, and the routers along the way query the corresponding (s, g) forwarding table according to the identifier for matching and forwarding.

[0017] Furthermore, step five also includes: when the high-computing-power equipment returns to an idle state and its router meets the assistance conditions, resending the "Assistance Announcement".

[0018] Furthermore, the high-computing-power equipment and the low-computing-power equipment are intelligent wells deployed in agricultural areas, wherein the high-computing-power wells are equipped with analysis models, while the low-computing-power wells only have basic data collection functions.

[0019] This invention also discloses a cluster processing system for intelligent IoT equipment, used to implement the method, comprising:

[0020] Multiple intelligent IoT devices are categorized into high-computing-power devices and low-computing-power devices.

[0021] Multiple routers form a network that runs the PIM-SM protocol and has a convergence point (RP).

[0022] The high-performance computing equipment is configured to periodically send IGMP join messages carrying its own state to the directly connected router.

[0023] The router is configured to perform the operations in steps 1 to 5.

[0024] The present invention provides a cluster processing method and system for intelligent IoT equipment, which has the following advantages: The present invention treats all intelligent wells and routers deployed in a target area (such as a large farmland) as a unified processing cluster. Through "assistance announcement" multicast messages, the system pre-establishes a multicast forwarding path between the router connecting idle high-computing-power wells and the aggregation point (RP). When a low-computing-power well initiates an "assistance" request, its access router can quickly discover available assistance resources through the RP and switch to establish an "assistance-assistance" logical path based on the shortest path tree (SPT), achieving rapid targeted forwarding of the task request and greatly reducing the delay in assistance response. The system uses the entire cluster resource pool as the scheduling object and can intelligently select the most suitable assisting well based on factors such as real-time load, interface overhead, and device computing power. It ensures efficient intra-cluster communication and has excellent predictability and controllability, making it highly suitable for scenarios with clearly defined boundaries, such as smart agricultural parks and large industrial plants. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating the synchronization of high-computing-power well status and the pre-construction of the "assistance notification" path in an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram illustrating the low-computing-power well initiating a request for help and the RP responding with an "assistance notification" in an embodiment of the present invention.

[0027] Figure 3 This is a schematic diagram illustrating how the request router performs SPT switching and establishes a "request-assistance" logical path in an embodiment of the present invention.

[0028] Figure 4 This is a schematic diagram of the forwarding path for a targeted assistance request message in an embodiment of the present invention.

[0029] Figure 5 This is a schematic diagram of the request redirection path when the path fails in an embodiment of the present invention. Detailed Implementation

[0030] To better understand the purpose, structure, and function of this invention, the following detailed description of a cluster processing method and system for intelligent IoT equipment, in conjunction with the accompanying drawings, is provided.

[0031] The present invention discloses a cluster processing method for intelligent IoT devices, applied to a cluster network comprising multiple routers and intelligent IoT devices with high and low computing power, wherein the network runs the PIM-SM protocol and has a preset aggregation point (RP). The method includes the following steps:

[0032] Step 1: Build a network of smart IoT devices

[0033] Within a target management area (such as an entire smart agriculture park), all smart well equipment and network routers are deployed, forming a unified IoT processing cluster. The smart well equipment is divided into two categories based on computing power: high-computing-power wells equipped with high-performance processors and agricultural analysis models (capable of complex analyses such as soil moisture assessment, pest and disease identification, crop growth stage determination, and irrigation decisions), and low-computing-power wells with only basic data collection functions. All well equipment within the cluster connects to the routers within the cluster via an agricultural IoT network (such as LoRa, ZigBee, or a wired network). These routers operate on the PIM-SM multicast protocol (preset multicast address 227.20.20.1), forming an internal multicast distribution network. The well equipment ID uses the format "region-field-equipment number," such as A-03-15, representing well number 15 in field number 3 of region A.

[0034] Step 2: State synchronization and cooperative path pre-construction

[0035] High-performance computing devices periodically send improved IGMP join messages to directly connected routers, carrying their own state ("idle" or "busy") and device identifier. The directly connected router records this state on the corresponding interface in its multicast group forwarding table and sends a PIM message synchronizing this state information to the RP. If a router detects a high-performance computing device with an "idle" state connected to it, in addition to normal multicast routing processing, it proactively sends a specific "helpable advertisement" multicast message to the RP. This message carries a "help" flag, the router's identifier, and the number of connected idle high-performance computing devices. The RP and routers along the path record this information, thereby pre-establishing a multicast forwarding path from the router to the RP.

[0036] Step 2.1: Each high-performance computing rig periodically sends an improved IGMP join message (multicast address 227.20.20.1) to the directly connected router. In addition to the regular fields, the message includes a new "rig ID" and "status" field: the rig fills in "idle" or "busy" according to its own load. If a rig changes from idle to busy during a transmission interval, it immediately sends an IGMP message update with a status of "busy".

[0037] Step 2.2: After receiving the IGMP message, the leaf routers (such as routers B and C) directly connected to the well record the well ID and status ("idle" or "busy") on the corresponding output interface of the forwarding table of multicast group 227.20.20.1: The interface of router B connected to well B-05-11 is in the "idle" state, and the interface connected to well B-05-12 is in the "busy" state; the interfaces of router C connected to wells C-06-01 and C-06-02 are in the "idle" state.

[0038] Step 2.3: Routers B and C have local member interfaces (i.e., interfaces connected to spools, receiving IGMP join messages with an "idle" status) in their multicast forwarding tables at (*, 227.20.20.1). Besides sending PIM messages to the RP normally, routers B and C will also proactively send a specific "Assistance Announcement" multicast message to the RP. This message has a destination address of 227.20.20.1, a source address of the router's loopback interface IP, carries an "Assistance" tag set to 1, and includes the router's ID (e.g., RouterID B, RouterID C) and the number of "idle" spools connected. Figure 1 As shown: After receiving this "Helpable Announcement" multicast message, the routers and RPs along the way will temporarily store the message locally and record the "Help" tag and the router's ID on the interface that received the message in the (*,227.20.20.1) forwarding table.

[0039] Through the above process, a multicast forwarding path from the router connecting the "idle" high-computing-power silo to the RP is pre-established within the cluster.

[0040] Step 3: Assist in request initiation and path construction.

[0041] When a low-performance device needs assistance with analysis, it sends an improved IGMP join message carrying a "help" status and request type to its directly connected router. Upon receiving this message, the router sends a "help" PIM join message to the RP (Resource Provider). After discovering the existence of a "help" path, the RP forwards a temporarily stored "helpable announcement" message to the help router. Upon receiving the announcement, the help router triggers a Shortest Path Tree (SPT) switch to the help routers, establishing (s, g) multicast forwarding paths from the help router to each help router, and recording the "help" status and resource quantity information on each path. Here, s represents the source IP address of the router, and g represents the multicast address.

[0042] Step 3.1: When a low-computing-power well (such as well A-03-15, connected to router A) detects continuous abnormalities in soil data or abnormal crop growth in images based on its temperature and humidity acquisition and image capture capabilities, and needs to perform in-depth analysis (such as disease and pest diagnosis, irrigation strategy formulation), and needs to submit the abnormal data for in-depth analysis, it sends a "Help" IGMP join message with a multicast address of 227.20.20.1 to its directly connected router A. The message carries the ID of well A, the source IP of well A, and sets the status field to "Help". At the same time, the IGMP message carries the specific request type (such as "soil moisture analysis" or "disease and pest identification").

[0043] Step 3.2: After receiving this "Help" IGMP message, Router A generates a multicast forwarding table (*, 227.20.20.1) and records the ID of Well A, the source IP of Well A, the "Status", and the "Request Type" on the interface GigabitEthernet (abbreviated as G in the attached diagram)0 / 2 that received the message. Simultaneously, Router A sends a "Help" PIM join message towards the aggregation point (RP). This PIM message carries a "Status" field of "Help". Routers along the route and the RP record the status as "Help" on the corresponding upstream ingress interface in the (*, 227.20.20.1) multicast forwarding table. At the same time, the RP discovers that the (*, 227.20.20.1) forwarding table contains an interface record with the "Assist" tag (set to 1), indicating that the RP needs to construct one or more "Help-Assist" logical paths to the assisting routers (Router B, C) connected to the "Help" Well (Router A). Therefore, RP forwards the previously stored "Assistance Available" multicast message from the upstream interface with the "Help Needed" status field in the forwarding table (*, 227.20.20.1), that is, it sends this announcement message to router A connected to the "Help Needed" rig. Routers along the path that receive the "Assistance Available" multicast message all perform the same processing as RP. For example... Figure 2 As shown: Router A receives a "Assistable" multicast message from RP on interface GigabitEthernet0 / 1 (the "Assist tag" is set to 1 in the message). Router A records the "Assist" tag, RouterID B, RouterID C, and the number of "idle" wells connected to each of Router B and Router C on its local forwarding table (*, 227.20.20.1) on interface GigabitEthernet0 / 1.

[0044] Step 3.3: As Figure 3As shown: After receiving the "Assistance Advertisement" multicast message from Router B, Router A performs an SPT switch. First, it copies the ID of Well A, the source IP of Well A, the "Status", and the "Request Type" fields recorded in the (*, 227.20.20.1) entry on interface GigabitEthernet0 / 2 to GigabitEthernet0 / 2. Subsequently, a "Help Request" PIM join message (RouterB IP, 227.20.20.1) is sent from GigabitEthernet0 / 4 to the next-hop IP address of the loopback interface IP connected to Router B. The message carries the ID of Well A and the "Status" field is set to "Help Request". Routers along the path record the ID of Well A and the status "Help Request" on the interface that received the PIM message in their local multicast forwarding table (RouterB IP, 227.20.20.1), and then forward "Help Request" PIM join messages hop-by-hop to Router B. Upon receiving the message, Router B creates its local multicast forwarding table (RouterB IP, 227.20.20.1) and changes its settings to send an "Available for Assistance" multicast message from the interface that received the PIM message with the "Status" field set to "Help Request". Router B subtracts the number of well IDs carried in the "Help" PIM message from the number of "idle" wells connected locally, obtaining a count x. It immediately sends a "Helpable Announcement" multicast message to the RP, updating the number of "idle" wells in the message to x. When x is less than or equal to 0, Router B must immediately send a "Withdraw Helpable" multicast message to the RP. This message has a destination address of 227.20.20.1, carries a "Withdraw Helpable" tag set to 1, and includes Router B's ID (Router-ID-B). Upon receiving this "Withdraw Helpable" multicast message, routers along the path or the RP delete the "Help" tag, Router B's ID, and the number of connected "idle" wells from the interface in the forwarding table at group address 227.20.20.1. After receiving a new "Assistable Announcement" multicast message from Router B from GigabitEthernet0 / 4, Router A records the "Assist" tag, Router ID B, and the number of "idle" wells connected to Router B on its local forwarding table outgoing interface GigabitEthernet0 / 4 (RouterA IP, 227.20.20.1). At the same time, it deletes the "Assist" tag, Router ID B, and the number of "idle" wells connected to Router B from its forwarding table outgoing interface GigabitEthernet0 / 1 (*, 227.20.20.1).Similarly, after router A receives a new "Assistable Announcement" multicast message from router C from GigabitEthernet0 / 5, router A records the "Assist" tag, RouterID C, and the number of "idle" wells connected to router C on its local forwarding table outgoing interface GigabitEthernet0 / 5 (RouterC IP, 227.20.20.1). At the same time, it deletes the "Assist" tag, RouterID C, and the number of "idle" wells connected to router C recorded on its forwarding table outgoing interface GigabitEthernet0 / 1 (*, 227.20.20.1).

[0045] In the above manner, each router (such as router A) that initiates a "help request" constructs one or more "help-assist" logical paths pointing to assisting routers (such as routers B and C), and records them in the multicast forwarding table of each router on the path (s, 227.20.20.1) (where s represents the source IP of router B or router C).

[0046] Step 4: Task-oriented scheduling

[0047] The requesting router selects a target assisting router from the established "assistance" paths based on preset policies (such as minimum source IP, number of idle devices, and load balancing). It then generates a "directed assistance request" multicast message carrying the target router's identifier and accurately forwards the message to the target assisting router according to its local (s, g) forwarding table. Upon receiving the message, the target assisting router selects one of its connected idle high-performance devices and forwards the assistance request to it, thus establishing a point-to-point connection between the low-performance device and the selected high-performance device to perform the analysis task.

[0048] Step 4.1: After router A completes the SPT tree switch for (s, 227.20.20.1) (s represents the source IP of router B or router C), it selects a target assisting router (such as router B) from the list of outgoing interfaces recorded in the forwarding table of (s, 227.20.20.1) that has a "helping" tag, the responding router ID, and the number of "idle" connection wells, according to a preset strategy (such as minimum s IP, number of "idle" wells, or load balancing).

[0049] Step 4.2: As Figure 4As shown: Router A generates a "Directed Assistance Request" multicast message with a destination address of 227.20.20.1. This message carries the source IP of the requesting router A-03-15, the "Assistance Request" field set to 1, and the ID of the target router B. Router A queries its local forwarding table (RouterB IP, 227.20.20.1) and forwards the message from the outgoing interface GigabitEthernet0 / 4, which records the Router B ID and the "Assistance" flag. Routers along the way, based on the target router B ID in the "Directed Assistance Request" multicast message, query their local multicast forwarding table (RouterB IP, 227.20.20.1) to find the interface recording the same router ID and forward it accordingly, until the message is accurately delivered to Router B.

[0050] Step 4.3: After receiving the "Directed Assistance Request", Router B selects a high-performance rig (such as rig B-05-11) from the "idle" member interfaces (i.e., directly connected rigs) in its local (*, 227.20.20.1) multicast forwarding table according to its local policy (such as the smallest ID) and forwards the "Directed Assistance Request" message to it.

[0051] Step 5: Dynamic Status Maintenance and Path Recovery

[0052] When all high-performance devices under the assisting router become "busy," it triggers a "Cancel Assistance" multicast announcement, updating the network-wide path information so that the path will no longer be selected. If the preferred assistance path fails, the assisting router can automatically redirect the request to other available assisting routers based on other valid "assistance" path information. After the task is completed, the high-performance device's status returns to "idle." If its router meets the assistance conditions again, it re-initiates the "Assistance Available" announcement and returns to the assistance resource pool.

[0053] Step 5.1: Upon receiving the "Directed Assistance Request" message, the high-performance computing well (well B-05-11) extracts the source IP of well A-03-15 from the message and sends a unicast confirmation to the requesting well (well A-03-15). Subsequently, it receives the analysis data (such as images and sensor data) sent by well A-03-15, calls the local model for processing, and returns the result via unicast.

[0054] Step 5.2: After router B assigns the task (i.e., forwards the "Directed Assistance Request" message) to well B-05-11, the interface state of well B-05-11 in the multicast forwarding table of group address 227.20.20.1 changes from "Idle" to "Busy," and well B-05-11 subsequently starts sending IGMP messages carrying the "Busy" status field. If the status of all interfaces connected to high-performance wells in router B's (*, 227.20.20.1) multicast forwarding table becomes "Busy" (i.e., the number of interfaces carrying the "Idle" status drops to 0), then the condition for sending an "Assistance Announcement" is no longer met. If a forwarding table of (RouterB IP, 227.20.20.1) exists, router B must immediately send a "Revoke Assistance" multicast message from the interface with the "Assistance" status field in the forwarding table to notify the entire network to update its status; if a forwarding table of (RouterB IP, 227.20.20.1) does not exist, it sends the message to the RP. The message's destination address is 227.20.20.1. It carries a "Cancel Assistance" tag set to 1 and includes the ID of Router B (Router-ID-B). Upon receiving this "Cancel Assistance" multicast message, routers or RPs along the path remove the "Assistance" tag, Router B's ID, and the number of "idle" connection spools from the interface in the forwarding table of group address 227.20.20.1 that received the message. When Router A receives this "Cancel Assistance" message, it removes the "Assistance" tag, Router B's ID, and the number of "idle" connection spools from the interface in the forwarding table of group address 227.20.20.1 that received the message, ensuring that subsequent requests are no longer forwarded to B, which no longer has any idle resources.

[0055] Step 5.3: In this case, the original "Help-Assist" logical path from Router A to Router B is unavailable. When switching to another router path with an idle interface is required, Router A checks within the multicast group with local group address 227.20.20.1 [containing (*, 227.20.20.1) or (s, 227.20.20.1)] for an interface with the "Assist" tag set to 1. If found, it selects one interface to forward the "Directed Assist Request" message according to a preset policy (such as minimum s IP, number of "idle" kiosks, or load balancing). Figure 5As shown, router A discovers that the forwarding table outgoing interface GigabitEthernet0 / 5 (RouterC IP, 227.20.20.1) has a "Assistance" tag set to 1. Therefore, it sends a "Directed Assistance Request" message with a destination address of 227.20.20.1 from this interface. This message contains a "Assistance Request" field set to 1 and explicitly carries the ID of the target router C. Routers along the path, based on the target router C ID in the "Directed Assistance Request" multicast message, query their local multicast forwarding table (RouterC IP, 227.20.20.1) to find the interface recording the same router ID and forward it accordingly, until the message is accurately delivered to router C.

[0056] Step 5.4: As long as router B still has at least one "idle" interface in the multicast forwarding table of group address 227.20.20.1, it still satisfies the condition of "having a directly connected idle member". Therefore, it does not need to immediately send a multicast message to router A or RP to revoke the assistable state. This avoids frequent global signaling caused by changes in the state of a single router.

[0057] Step 5.5: After assisting well B-05-11 in completing the analysis task, its status returns to "idle" and it sends an IGMP message to update the interface status. If this recovery causes router B to meet the "existence of directly connected idle members" condition again, it will re-initiate the "assistance announcement" process to reconnect to the assistance resource pool.

[0058] A cluster processing system for intelligent IoT equipment implementing the above method according to the present invention includes:

[0059] Multiple smart IoT devices are divided into high-computing-power devices and low-computing-power devices.

[0060] Multiple routers form an internal network that runs the PIM-SM multicast protocol, and a pre-defined aggregation point (RP) is used.

[0061] The high-computing-power equipment is configured to periodically send improved IGMP join messages carrying its own status and device identifier to the directly connected router;

[0062] The router is configured as follows:

[0063] Record the status of the connected high-computing-power equipment in its multicast forwarding table;

[0064] When a high-performance computing device with a "free" status is connected, send a "helpable announcement" multicast message to the RP.

[0065] Receive and record "Assistance Announcement" or "Assistance Withdrawal" messages from other routers;

[0066] When a connected low-computing-power device initiates a request for help, it receives the IGMP message, sends a "Request for Help" PIM join message to the RP, receives the "Available to Assist" notification forwarded by the RP, and triggers an SPT switch to establish a (s, g) path.

[0067] The target assist router is selected according to the policy, and the "directed assistance request" message is accurately forwarded based on the (s,g) forwarding table;

[0068] When all connected high-computing-power equipment is busy, send a "Cancel Assistance" message.

[0069] It is understood that the present invention has been described through some embodiments, and those skilled in the art will recognize that various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of the invention. Furthermore, under the teachings of the present invention, these features and embodiments can be modified to adapt to specific situations and materials without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are within the protection scope of the present invention.

Claims

1. A cluster processing method for intelligent IoT equipment, applied to a heterogeneous device network based on the PIM-SM multicast protocol and equipped with a convergence point RP, characterized in that, Includes the following steps: Step 1: The high-computing-power equipment periodically sends IGMP join messages carrying its own status to the directly connected router. When the router has an idle high-computing-power equipment connected, it sends a "help announcement" multicast message to the RP and pre-builds a multicast path to the RP. Step 2: When low-computing-power equipment needs assistance, it sends an IGMP join message with a "help" status to the directly connected router, which then sends a "help" PIM join message to the RP. Step 3: The RP forwards the received "Assistance Announcement" message to the helper router, triggering it to perform SPT handover to each helper router and establish (s,g) multicast paths from the helper router to each helper router. Step 4: The requesting router selects the target assisting router according to the preset policy and sends a "directed assistance request" message to the target assisting router along the corresponding (s, g) path, so that the router can select an idle high-computing-power equipment to perform the task. Step 5: When there are no available high-computing-power devices under the assisting router, send a "Cancel Assistance" message to update the path; if the path is invalid, request the assisting router to redirect based on other paths.

2. The method according to claim 1, characterized in that, The "Assistance Available" multicast message, the "Help Needed" PIM join message, and the "Cancel Assistance Available" message all use the same preset multicast address.

3. The method according to claim 1, characterized in that, The "Assistance Announcement" multicast message carries the identifier of the sending router and the number of idle high-performance computing devices connected to it.

4. The method according to claim 1, characterized in that, The SPT handover described in step three specifically includes: the helper router copies the helper device information from the (*, G) entry to the newly created (s, g) entry, and sends a "help" PIM join message carrying the information to the assisting router.

5. The method according to claim 1, characterized in that, The preset strategies described in step four include: selecting a target assisting router based on the IP address order of the assisting router, the number of idle high-computing-power devices, or load balancing principles.

6. The method according to claim 1, characterized in that, In step four, the "targeted assistance request" message carries the identifier of the target assisting router, and the routers along the way query the corresponding (s, g) forwarding table according to the identifier to match and forward the message.

7. The method according to claim 1, characterized in that, Step five also includes: when the high-performance computing equipment returns to idle status and its router meets the assistance conditions, resend the "Assistance Announcement".

8. The method according to claim 1, characterized in that, The high-computing-power equipment and low-computing-power equipment are intelligent wells deployed in agricultural areas. The high-computing-power wells are equipped with analysis models, while the low-computing-power wells only have basic data collection functions.

9. A cluster processing system for intelligent IoT equipment, used to implement the method according to any one of claims 1-8, characterized in that, include: Multiple intelligent IoT devices are categorized into high-computing-power devices and low-computing-power devices. Multiple routers form a network that runs the PIM-SM protocol and has a convergence point (RP). The high-computing-power equipment is configured to periodically send IGMP join messages carrying its own state to the directly connected router; The router is configured to perform the operations described in steps 1 to 5 as claimed in claim 1.

Images