Wireless ad hoc network application information interaction method and device and storage medium

Abstract

The invention discloses a wireless ad hoc network application information interaction method and device and a storage medium, and when a node finds that information such as the state of a local affiliated APP changes, the change can be reliably diffused to the whole network through an infection diffusion mechanism. In the infection diffusion process, in order to reduce the influence of services on air interface bandwidth, nodes can extract locally collected summary information of APP states belonging to all the nodes, and the summary information is periodically diffused between one-hop neighbors; and after receiving the APP state summary information sent by the adjacent node, the node compares the APP state summary information with locally stored information, and if the information in the summary is found to be new, an APP information request can be initiated to the summary information sending node, so that the synchronization of the APP information between the nodes is realized, and the infection diffusion process is completed. According to the invention, the requirement of the synchronization of the APP state information between different nodes on the network flow can be greatly reduced, and the problem that the synchronization of the APP state information under the weak network connection causes the impact of the frequent sending of small packets on the network bearing capacity is solved.

Description

Technical Field

[0001] The present invention relates to the field of mobile communication technology, and in particular to a method, device and storage medium for wireless ad hoc network application information interaction. Background Art

[0002] Self-organizing networks are widely used in private networks and special communications due to their features of being centerless, self-organizing, self-relaying, and infrastructure-free. Each node in a self-organizing network has the same capabilities and equal status. Considering the constraints of equipment power consumption, volume, weight, cost, and available spectrum resources, the air interface traffic of a self-organizing network is usually limited.

[0003] According to the conventional network architecture design, the self-organizing network as a bearer channel should be decoupled from the upper-layer application, that is, the bearer does not need to be aware of the implementation logic of the upper-layer application, and only needs to focus on the transmission channel. However, in actual use, the carrying capacity of wireless networks, especially self-organizing networks, is far from meeting the business requirements of upper-layer applications. Therefore, it is necessary to jointly design the bearer channel and application services to reduce the impact of upper-layer applications on network bandwidth under the principle of logical decoupling. Summary of the invention

[0004] In order to solve the problem that the service data generated by different peripheral applications does not match the channel transmission capacity, the present invention proposes a wireless ad hoc network application information interaction method based on infectious diffusion. The node devices in the network use their own topology discovery mechanism to provide a general strategy to achieve mutual discovery, status detection and change notification functions between peripheral applications deployed in different nodes, thereby reducing the impact on the network carrying capacity.

[0005] The present invention proposes a wireless ad hoc network application information interaction method based on infectious diffusion, which is applied to network nodes or peripherals, including:

[0006] 1) When a node finds that the status information of the local APP, that is, the original APP, changes, it triggers the sending of an "APP information broadcast" message;

[0007] 2) The node that receives the "APP information broadcast" message updates the corresponding table entry in its own local node APP status table to make the locally stored APP status and APP release information consistent with the original APP status and original APP release information;

[0008] 3) Each node in the network periodically constructs an "APP summary notification" and broadcasts it in the 1-hop neighbor to inform the 1-hop neighbor node that it has currently collected summary information of all APP states belonging to each node in the network;

[0009] 4) After receiving the "APP Summary Announcement" message, the neighboring node compares the message entry with the entry in its own local APP status table. If the APP status and APP release information indicated by the "APP Summary Announcement" are new, the neighboring node sends an "APP Information Request" to the source node of the "APP Summary Announcement" message to obtain the new APP status and APP release information;

[0010] 5) After receiving the "APP Information Request" message, the node will extract the APP status and APP release information content required for the "APP Information Request" from its own local APP status table, and send it to the source node of the "APP Information Request" message through the "APP Information Response" message;

[0011] 6) After receiving the "APP Information Response" message, the node updates the corresponding entry in its own local node APP status table, so that the local node continuously maintains the latest APP status and APP release information.

[0012] Furthermore, when the node finds that the local APP status information changes, triggering an "APP information broadcast" message to be sent specifically includes:

[0013] When a node finds in the local APP status table that the belonging node ID is equal to its own ID and the "APP change identifier" of the table item is inconsistent with the previous "APP information broadcast" sent in the air interface, it triggers the sending of an "APP information broadcast" message to the entire network. The message carries at least the "belonging node ID", "APP change identifier under the belonging node" and "APP information under the belonging node". The "APP information under the belonging node" consists of one or more message items, and each message item contains at least one group of "APP index", "APP identifier", "APP release information", "APP survival time", "APP change identifier" and "APP status" information.

[0014] Further, the node receiving the "APP information broadcast" message performs the following processing according to the "belonging node ID", "belonging node APP change identifier" and "belonging node APP information" in the "APP information broadcast" message:

[0015] a) If the "APP information broadcast" message is sent by its own node, the receiving node discards the "APP information broadcast" message and the processing ends;

[0016] b) If the receiving node determines that the APP status information in the local node APP status table is newer than the corresponding entry in the "APP information broadcast" message, the receiving node discards the "APP information broadcast" message and the processing ends;

[0017] c) The receiving node processes each "APP information under the home node" entry in the "APP information broadcast" message:

[0018] i) If the entry of "APP information under the home node" is not found in the local node APP status table of the receiving node itself, the entry in the "APP information broadcast" message is directly inserted into the local node APP status table for storage;

[0019] ii) Otherwise, the receiving node performs the following processing on the entry found in its own local node APP status table:

[0020] If the "APP change identifier" of the table entry is greater than or equal to the value in the "APP information broadcast" message entry, skip the processing of the "APP information broadcast" message entry; otherwise, replace the corresponding content of the APP status table entry with the "APP information broadcast" message entry.

[0021] Furthermore, the "APP summary notification" includes at least one or more "belonging node change identification entries", and each entry includes at least "belonging node ID" and "belonging node subordinate APP change identification".

[0022] Furthermore, after receiving the "APP summary notification", the neighboring node performs the following processing on each "home node change identification entry" therein:

[0023] a) If the "home node ID" of the "home node change identification entry" is the same as the own node ID, skip this entry and directly proceed to the next entry;

[0024] b) If an entry is found in the local node APP status table, whose "belonging node ID" is equal to the "belonging node ID" of the "belonging node change identification entry" currently being processed, but the "belonging node subordinate APP change identification" in the entry is greater than or equal to the "belonging node subordinate APP change identification" of the "belonging node change identification entry" currently being processed, then skip this entry and directly proceed to the next entry;

[0025] c) Otherwise, the adjacent node constructs an "APP Information Request" message and sends it to the node that issues the "APP Summary Notification". The "APP Information Request" message carries at least: the requesting node ID, the target node ID, the belonging node ID, the APP change identifier of the belonging node stored in the local node APP status table, and the APP summary list of the belonging node.

[0026] Furthermore, the node receiving the "APP information request" performs the following processing:

[0027] a) If the "target node ID" of the "APP information request" message is not equal to the node ID of the node itself, the "APP information request" message is discarded and the processing ends;

[0028] b) Otherwise, initialize an "APP information response" message, which at least includes: a responding node ID, a requesting node ID, and a response message item, wherein the responding node ID is the current node ID, the requesting node ID is the sending node ID of the "APP information request", and the response message item is 0;

[0029] c) For each "home node ID" in the "APP information request", search the local node APP status table:

[0030] i) If no corresponding entry with the same “home node ID” is found, skip all APP summary lists under the “home node ID” in the “APP information request” and directly proceed to the next “home node ID” corresponding entry;

[0031] ii) Otherwise, if a corresponding entry with the same “home node ID” is found, the following processing is performed:

[0032] If the "APP change identifier under the home node" corresponding to the "home node ID" in the "APP information request" is greater than or equal to the corresponding value in the local node APP status table item, then skip the summary list of all APPs under the "home node ID" in the "APP information request" and directly proceed to the next "home node ID" corresponding table item;

[0033] Otherwise, the node compares the found "APP information request" with the "APP information under the home node" entry with the same "home node ID" in the local APP status table.

[0034] If the entry only exists in the "APP Information Request", insert the "APP Delete Entry" in the "APP Information Response" message;

[0035] If the entry only exists in the local APP status table, insert the "APP New Entry" into the "APP Information Response" message;

[0036] If the entry exists both in the "APP Information Request" and in the local APP status table, insert the "APP Update Entry" into the "APP Information Response" message;

[0037] Each time an entry is inserted into the "APP response message", the number of response entries increases by 1;

[0038] d) If the number of "Response Message Items" of the "APP Information Response" message is 0 after the "APP Information Request" message is processed, the "APP Information Response" message is deleted and the processing is completed; otherwise, the "APP Information Response" message is sent on the air interface.

[0039] Furthermore, after receiving the "APP Information Response" message, if the "Requesting Node ID" is not equal to its own node ID, the node will discard it; otherwise, each response message item will be processed as follows:

[0040] For "APP deletion entries", delete all matching corresponding entries in the local node APP status table;

[0041] For the "new APP entry", insert a new "APP information under the jurisdiction of the belonging node" entry into the local node APP status table;

[0042] For the "APP update entry", the corresponding "APP information under the jurisdiction of the belonging node" entry in the local node APP status table is updated.

[0043] Furthermore, it also includes:

[0044] 1) After the APP works normally, it initiates the registration and subscription process. The APP obtains the address information required for registration and subscription of the corresponding node through preset or node active publishing;

[0045] 2) The APP sends a "registration subscription request" message to the obtained registration subscription address information, which carries at least: APP identification, APP release information, and subscription content;

[0046] 3) After receiving the "registration subscription request" of the APP, the node will send a "registration subscription response" message to the APP, which at least carries: the home node ID, APP identifier, and registration subscription result;

[0047] 4) If the registration and subscription is successful, the node updates the local APP status table and inserts a new table entry. The table is a two-dimensional table. The first dimension contains at least: the home node ID and the APP change identifier under the home node; the second dimension is the APP information entry under the home node, and each entry contains at least: APP index, identifier, release information, survival time, change identifier, and status;

[0048] The "belonging node ID" of the inserted entry is set to the ID of the current node itself, the "belonging node's APP change ID" and "APP change ID" are both increased by 1, the "APP index" is assigned by the node, the "APP ID" and "APP release information" come from the registration subscription request message, the "APP survival time" is set to the maximum value allowed, and the "APP status" is set to "online";

[0049] 5) If the registration and subscription process fails, the node takes no action.

[0050] Furthermore, it also includes:

[0051] 1) The node periodically sends a "keep alive request" message to each APP whose home node ID is equal to its own ID in its local APP status table. The message carries at least: home node ID, APP identifier, and sequence number; after receiving the message, each APP sends a "keep alive response" message to the node. The message carries at least: home node ID, APP identifier, and sequence number in the keep alive request;

[0052] 2) After receiving the "keep alive response" message sent by each APP, if the node fails the validity check, no action will be taken. The validity check is to determine whether the home node ID, APP identifier and sequence number match the corresponding items in the "keep alive request" message;

[0053] 3) If the validity check passes, the "survival time" of the corresponding APP entry in the local APP status table is extended to the maximum allowed value T1, the "APP status" is updated to "online", and the "APP change identifier" and "APP change identifier under the belonging node" are updated at the same time;

[0054] 4) When the node fails to receive a keep-alive response message from the APP for K consecutive times and the "APP status" of the corresponding entry in the local APP status table is "online", it indicates that the APP is invalid. The "APP status" of the corresponding entry is set to "offline", the "APP survival time" is changed to T2, and the "APP change flag" and "APP change flag under the belonging node" are both increased by 1;

[0055] 5) When the "APP status" of an entry in the local APP status table is equal to "offline" and the "APP survival time" is reduced to 0, the APP entry is directly deleted; when all APP entries under the home node are deleted, the table entry corresponding to the home node is directly deleted.

[0056] Furthermore, it also includes:

[0057] 1) When the "published information" of the APP needs to be changed, the APP sends an "information change request" to the node to notify the node to update the "published information" of the APP. The "information change request" message carries at least: the home node ID, the APP identifier, and the published information;

[0058] 2) After receiving the "information change request" message, the node responds to the APP, and then updates the "APP release information" of the corresponding APP entry in the local node APP status table, and at the same time, the corresponding "APP change identifier" and "APP change identifier under the belonging node" are both increased by 1.

[0059] Furthermore, it also includes:

[0060] 1) The APP actively initiates the deregistration process through a "deregistration request" message, which contains at least: the home node ID and the APP identifier;

[0061] 2) After receiving the deregistration request, the node sends a "deregistration response" to the APP. If the "APP status" of the corresponding APP entry in the local APP status table is "online", it indicates that the APP is invalid, and the "APP status" corresponding to the entry is set to "offline", the "APP survival time" is changed to T2, and the "APP change identifier" and "APP change identifier under the belonging node" are both increased by 1; if the "APP status" of the corresponding APP entry in the local APP status table is not "online" or the APP corresponding to the "deregistration request" is not found, no action is taken;

[0062] 3) When the "APP status" of an entry in the local APP status table is equal to "offline" and the "APP survival time" is reduced to 0, the APP entry is directly deleted; when all APP entries under the belonging node are deleted, the table entry corresponding to the belonging node is directly deleted.

[0063] Furthermore, if the node finds that the network topology has changed, it will proceed as follows:

[0064] If a node is found to be unreachable, all entries in the local node APP status table whose belonging node ID is equal to the unreachable node ID are directly deleted;

[0065] If a new node is found online or the node becomes reachable, wait for the APP information to spread to the local area according to the transmission and diffusion process.

[0066] Furthermore, if the node finds that there is an update to the entry in the local node APP status table whose belonging node ID is not equal to its own node ID, the node publishes the updated APP status and APP release information to the APP that belongs to its own node and has subscribed to the APP status and APP release information changes through a "status change release" message; the "status change release" message carries at least: belonging node ID, APP identifier, APP release information, and APP status.

[0067] The present invention also proposes a wireless ad hoc network application information interaction device based on infectious diffusion, which is applied to a network node or peripheral device, and includes a memory and a processor connected to the memory, and the processor is configured to implement the information interaction method as described above.

[0068] The present invention also proposes a computer storage medium on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor, the information interaction method described above is implemented.

[0069] The present invention can greatly reduce the air interface overhead of APPs probing each other by sending 1-hop summary information through APPs deployed in different areas of the network, that is, the APP status obtained by different nodes is checked through the summary, and only when the status is inconsistent, the air interface "large" data volume is transmitted, thereby achieving reliable information synchronization. This method can greatly reduce the requirements for network traffic and solve the problem of the impact of different business applications under weak network connections on network carrying capacity due to frequent small packets. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] Figure 1 Network architecture diagram for infectious diffusion fusion application;

[0071] Figure 2 It is a schematic diagram of the application information interaction process of the present invention;

[0072] Figure 3 This is an example diagram of an infectious diffusion fusion application network in a specific embodiment of the present invention. DETAILED DESCRIPTION

[0073] The technical solution of the present invention is further described below through the accompanying drawings and embodiments.

[0074] like Figure 1 In the network shown in the figure, the nodes in the self-organizing network build a multi-hop self-organizing network through air interface self-relay to achieve air interface interconnection; the nodes are interconnected with peripherals or peripheral networks through "service ports" to provide two-way bearer paths for applications deployed on different peripherals. The "service port" can be a wired or wireless interface such as an Ethernet port, serial port, WiFi, or Bluetooth.

[0075] Applications (hereinafter referred to as APP, which can be application software or functional modules under application software) can be deployed on peripherals or nodes. If the APP is deployed on a peripheral, the APP communicates with the node through the "business port" provided by the node; if the APP is deployed on a node, it communicates with the node through the internal interface.

[0076] In a specific embodiment of the present invention, it is assumed that the APP is deployed on a peripheral device. When the APP is deployed on a node, the present invention is also applicable, and the only difference in the scheme is that the physical interface is replaced by an "internal interface" instead of a "service port".

[0077] The nodes in the self-organizing network provide a registration and subscription interface through the "business port" for the APP deployed on the node's peripherals to initiate registration and subscription to the self-organizing network node (belonging node) on demand. The purpose of registration is to inform the node that a new APP is online and the node needs to maintain the status of the APP; the purpose of subscription is to inform the node that when the status of an APP belonging to another node changes, the subscribed APP needs to be notified. The APP can achieve active offline notification through the logout process.

[0078] After the registration and subscription process is completed, the node will continue to keep the APP belonging to it alive to detect the status changes of the APP.

[0079] For the APP to which the node belongs, the node provides an information update interface for the APP to actively notify that its own information (status) has changed, and the node needs to help spread the change.

[0080] When a node finds that the APP information (status) has changed, it can reliably spread the change to the entire network through the infectious diffusion mechanism. To speed up the diffusion process, the node can trigger a network-wide APP information broadcast (it is difficult to ensure the reliability of transmission in a complex electromagnetic environment). During the infectious diffusion process, in order to reduce the impact of the service on the air interface bandwidth, the node can extract the summary information (change identifier) ​​of the APP status of each node collected locally, and periodically diffuse the summary among 1-hop neighbors; after receiving the APP summary sent by the adjacent node, the node compares it with the locally stored information. If the information in the summary is found to be "new", it can initiate an APP information request to the summary sending node to synchronize the APP information between nodes, thereby completing the infectious diffusion process.

[0081] When a node senses that the status of an APP from another node has changed, it will publish the status change to notify all peripheral APPs that belong to the node and subscribe to the change.

[0082] When a node finds that there are unreachable nodes in the network, it will directly notify the local APP to which these unreachable nodes belong to go offline; when the node finds that other nodes are online, no additional behavior is required, and it only needs to follow the infection and diffusion process to achieve reliable synchronization of APP information (status) in the network.

[0083] In a specific embodiment of the present invention, the details are as follows: Figure 2 shown.

[0084] Sign up for the subscription process.

[0085] 1) After the APP works normally, it will initiate the registration and subscription process. The APP can obtain the address information (for example, IP address + port information) required for registration and subscription of the corresponding node (i.e., the home node) through preset or node active release;

[0086] 2) The APP sends a "registration subscription request" to the obtained registration subscription address information. The message carries at least: APP identifier (used to identify different APPs), APP release information (used for information that requires node assistance to spread to other node-related APPs), subscription content (information content subscribed to the node, default subscription to the status change of the same APP identifier); optional including: authentication encryption content (used for authentication encryption between APP and node);

[0087] 3) After receiving the "registration subscription request" from the APP, the node will send a "registration subscription response" to the APP. The message carries at least: home node ID, APP identifier, registration subscription result (success or failure, and if failure, the failure reason can also be carried);

[0088] 4) If the registration and subscription is successful, the node updates the local APP status table and inserts a new table entry. The table is a two-dimensional table. The first dimension contains at least: the home node ID and the APP change identifier under the home node; the second dimension is the APP information entry under the home node. Each entry contains at least: APP index, identifier, release information, survival time, change identifier, status, etc. The member description of each table entry is shown in the following table:

[0089]

[0090] The "belonging node ID" of the inserted table entry is set to the ID of the current node itself, the "belonging node's APP change identifier" and the "APP change identifier" both need to be increased by 1, the "APP index" is assigned by the node, the "APP identifier" and "APP release information" come from the registration subscription request message, the "APP survival time" is set to the maximum value allowed, and the "APP status" is set to "online";

[0091] 5) If the registration and subscription process fails due to reasons such as exceeding the node specifications, the node will not take any action.

[0092] Keep alive process.

[0093] 1) The node periodically sends a "keep alive request" message to each APP whose home node ID is equal to its own ID in its local APP status table. The message carries at least the home node ID, APP identifier, serial number and other information. After receiving the message, each APP will send a "keep alive response" message to the node. The message carries at least the home node ID, APP identifier, and the serial number in the keep alive request.

[0094] 2) After receiving the "keep alive response" message sent by each APP, if the node fails to pass the validity check, no action will be taken. The validity check is to determine whether the home node ID, APP identifier and sequence number match the corresponding items in the "keep alive request" message. If they match, the validity check is passed; if they do not match, the validity check is not passed;

[0095] 3) If the validity check passes, the "survival time" of the corresponding APP entry in the local APP status table is extended to the maximum allowed value T1, the "APP status" is updated to "online", and the "APP change identifier" and "APP change identifier under the belonging node" are updated (plus 1).

[0096] 4) When the node fails to receive a keep-alive response message from the APP for K consecutive times and the "APP status" of the corresponding entry in the local APP status table is "online", it indicates that the APP is invalid. The "APP status" of the corresponding entry is set to "offline", the "APP survival time" is changed to T2, and the "APP change flag" and "APP change flag under the belonging node" are both increased by 1;

[0097] 5) When the "APP status" of an entry in the local APP status table is equal to "offline" and the "APP survival time" is reduced to 0, the APP entry is directly deleted; when all APP entries under the home node are deleted, the table entry corresponding to the home node is directly deleted.

[0098] Information update process.

[0099] 1) When the "published information" of an APP needs to be changed, the APP will send an "information change request" to the node to notify the node to update the "published information" of the APP. The "information change request" carries at least: the home node ID, the APP identifier, and the published information;

[0100] 2) After receiving the "information change request" message, the node responds to the APP, and then updates the "APP release information" of the corresponding APP entry in the local node APP status table, and at the same time, the corresponding "APP change identifier" and "APP change identifier under the belonging node" are both increased by 1.

[0101] Logout process.

[0102] 1) The APP can also actively initiate the deregistration process through a "deregistration request" message, which at least contains: home node ID and APP identifier;

[0103] 2) After receiving the deregistration request, the node will send a "deregistration response" to the APP. If the "APP status" of the corresponding APP entry in the local APP status table is "online", it means that the APP is invalid, and the "APP status" corresponding to the entry is set to "offline", the "APP survival time" is changed to T2, and the "APP change identifier" and "APP change identifier under the belonging node" are both increased by 1; if the "APP status" of the corresponding APP entry in the local APP status table is not "online" or the APP corresponding to the "deregistration request" is not found, no action is taken;

[0104] 3) When the "APP status" of an entry in the local APP status table is equal to "offline" and the "APP survival time" is reduced to 0, the APP entry is directly deleted; when all APP entries under the belonging node are deleted, the table entry corresponding to the belonging node is directly deleted.

[0105] The process of spreading infection.

[0106] 1) When a node finds that the status and other information of the local APP (also called the original APP) have changed, it triggers the sending of an "APP information broadcast" message;

[0107] 2) The node that receives the "APP information broadcast" message updates the corresponding table entry in its own local node APP status table to make the locally stored APP status and APP release information consistent with the original APP status and original APP release information;

[0108] 3) Each node in the network periodically constructs an "APP summary notification" and broadcasts it in the 1-hop neighbor to inform the 1-hop neighbor node that it has currently collected summary information of all APP states belonging to each node in the network;

[0109] 4) After receiving the "APP Summary Announcement" message, the neighboring node compares the message entry with the entry in its own local APP status table. If the APP status and APP release information indicated by the "APP Summary Announcement" are new, the neighboring node sends an "APP Information Request" to the source node of the "APP Summary Announcement" message to obtain the new APP status and APP release information;

[0110] 5) After receiving the "APP Information Request" message, the node will extract the APP status and APP release information content required for the "APP Information Request" from its own local APP status table, and send it to the source node of the "APP Information Request" message through the "APP Information Response" message;

[0111] 6) After receiving the "APP Information Response" message, the node updates the corresponding entry in its own local node APP status table, so that the local node continuously maintains the latest APP status and APP release information.

[0112] The above-mentioned infection spreading process is described in detail below.

[0113] 1) When a node finds in the local APP status table that the belonging node ID is equal to its own ID and the "APP change identifier" of the table item is inconsistent with the previous "APP information broadcast" sent in the air interface, it triggers the sending of an "APP information broadcast" message to the entire network. The message will carry at least "belonging node ID", "APP change identifier under the belonging node" and "APP information under the belonging node". "APP information under the belonging node" consists of one or more message items, and each message item contains at least one group of information: "APP index", "APP identifier", "APP release information", "APP survival time", "APP change identifier", "APP status" and so on.

[0114] 2) The node that receives the "APP Information Broadcast" message updates the corresponding table entry in its local node APP status table to make the locally saved APP status and APP release information consistent with the original APP status and original APP release information, and performs the following processing based on the "belonging node ID", "belonging node subordinate APP change identifier" and "belonging node subordinate APP information" in the "APP Information Broadcast" message:

[0115] a) If the "APP Information Broadcast" message is sent by its own node, that is, the "belonging node ID" in the "APP Information Broadcast" message is the same as the receiving node ID, the receiving node discards the "APP Information Broadcast" message and the processing ends;

[0116] b) If the receiving node determines that the APP status information in the local node APP status table is newer than the corresponding table item in the "APP information broadcast" message, that is, the receiving node finds the table item in its own local node APP status table whose "belonging node ID" is equal to the "belonging node ID" carried by the "APP information broadcast", and the "belonging node subordinate APP change identifier" of the table item is greater than or equal to the "belonging node subordinate APP change identifier" carried by the "APP information broadcast" message, then the receiving node discards the "APP information broadcast" message and the processing ends;

[0117] c) The receiving node processes each "APP information under the home node" entry in the "APP information broadcast" message:

[0118] i) If the entry of the “APP information under the jurisdiction of the belonging node” is not found in the local node APP status table of the receiving node itself (the “belonging node ID” corresponding to the entry is equal to the “belonging node ID” carried in the “APP information broadcast” message, and the “APP index” of the entry is equal to the “APP index” in the “APP information under the jurisdiction of the belonging node” entry carried in the “APP information broadcast” message), that is, the entry whose belonging node ID and APP index are the same as the belonging ID and APP index in the “APP information broadcast” message is not found in the local node APP status table, then the entry in the “APP information broadcast” message is directly inserted into the local node APP status table for storage;

[0119] ii) Otherwise, the receiving node performs the following processing on the entry found in its own local node APP status table:

[0120] If the "APP change identifier" of the table entry is greater than or equal to the value in the "APP information broadcast" message entry, the processing of the "APP information broadcast" message entry is skipped;

[0121] Otherwise, the corresponding content of the APP status table entry is replaced with the "APP information broadcast" message entry.

[0122] Optionally, the node that receives the "APP information broadcast" message may also relay and forward the "APP information broadcast" according to the rules of the multi-hop network.

[0123] 3) The node constructs an "APP summary notification" and periodically publishes the summary information of the APP it has obtained in the 1-hop neighbor. The "APP summary notification" contains at least one or more "belonging node change identification entries", and each entry includes at least: "belonging node ID" and "belonging node subordinate APP change identification".

[0124] 4) After receiving the "APP summary notification", the neighboring node performs the following processing on each "home node change identification entry" therein:

[0125] a) If the "home node ID" of the "home node change identification entry" is the same as the own node ID, skip this entry and directly proceed to the next entry;

[0126] b) If an entry is found in the local node APP status table, whose "belonging node ID" is equal to the "belonging node ID" of the "belonging node change identification entry" currently being processed, but the "belonging node subordinate APP change identification" in the entry is greater than or equal to the "belonging node subordinate APP change identification" of the "belonging node change identification entry" currently being processed, then skip this entry and directly proceed to the next entry;

[0127] c) Otherwise, the adjacent node constructs an "APP information request" message and sends it to the node that issues the "APP summary notification". The message carries at least: the requesting node ID, the target node ID, the belonging node ID, the APP change identifier of the belonging node stored in the local node APP status table, and the APP summary list of the belonging node.

[0128] 5) The node that receives the "APP information request" performs the following processing:

[0129] a) If the "target node ID" of the "APP information request" message is not equal to the node ID of the node itself, the "APP information request" message is discarded and the processing ends;

[0130] b) Otherwise, initialize an "APP Information Response" message, which at least includes: a responding node ID, a requesting node ID, and a response message item, wherein the responding node ID is the current node ID, the requesting node ID is the sending node ID of the "APP Information Request", and the response message item is 0;

[0131] c) For each "home node ID" in the "APP information request", search the local node APP status table:

[0132] i) If no corresponding entry with the same “home node ID” is found, skip all APP summary lists under the “home node ID” in the “APP information request” and directly proceed to the next “home node ID” corresponding entry;

[0133] ii) Otherwise, if a corresponding entry with the same “home node ID” is found, then:

[0134] ① If the "APP change identifier under the home node" corresponding to the "home node ID" in the "APP information request" is greater than or equal to the corresponding value in the local node APP status table, then skip the summary list of all APPs under the "home node ID" in the "APP information request" and directly proceed to the next "home node ID" corresponding table item;

[0135] ② Otherwise, the node compares the found "APP Information Request" with the "APP Information under the Belonging Node" entry with the same "Belonging Node ID" in the local APP status table. If the entry only exists in the "APP Information Request", the "APP Deleted Entry" is inserted in the "APP Information Response" message; if the entry only exists in the local APP status table, the "APP Newly Added Entry" is inserted in the "APP Information Response" message; if the entry exists in both the "APP Information Request" and the local APP status table, the "APP Updated Entry" is inserted in the "APP Information Response" message; each time an entry is inserted in the "APP Response Message", the number of response entries increases by 1;

[0136] d) If the number of "Response Message Items" of the "APP Information Response" message is 0 after the "APP Information Request" message is processed, the "APP Information Response" message is deleted and the processing is completed; otherwise, the "APP Information Response" message is sent on the air interface.

[0137] 6) After receiving the "APP Information Response" message, the node updates the corresponding table entry in its local node APP status table, so that the locally stored APP status and APP release information are consistent with the original APP status and original APP release information stored by the source node of the "APP Information Response" message. If the "Requesting Node ID" is not equal to its own node ID, it is discarded; otherwise, each response message entry is processed as follows:

[0138] a) For "APP deletion entries", delete all matching corresponding entries in the local node APP status table;

[0139] b) For the "new APP entry", insert a new "APP information under the jurisdiction of the belonging node" entry into the local node APP status table;

[0140] c) For the "APP update entry", the corresponding "APP information under the jurisdiction of the belonging node" entry in the local node APP status table is updated.

[0141] Network topology changes

[0142] If a node finds that the network topology has changed, it will proceed as follows:

[0143] 1) If a node is found to be unreachable, all entries in the local node APP status table whose belonging node ID is equal to the unreachable node ID are directly deleted;

[0144] 2) If a new node is found online or the node becomes reachable, wait for the APP information to spread to the local area according to the above-mentioned spreading process.

[0145] Change Notification Process

[0146] If the node finds that the entry in the local node APP status table whose belonging node ID is not equal to its own node ID has been updated ("APP change identifier" changes, new entries appear or entries are deleted in the APP information under the belonging node), the node will publish these updates (referring to the updated APP status and APP release information) to the APPs that belong to its own node and have subscribed to the change (referring to the change of APP status and APP release information) through the "status change release" message; the "status change release" message carries at least: belonging node ID, APP identifier, APP release information, and APP status.

[0147] The present invention also proposes a wireless ad hoc network application information interaction device, which can be deployed on a peripheral device or on a network node. The interaction device includes a memory and a processor connected to the memory. The processor can implement the information interaction method described above, which will not be repeated here.

[0148] The present invention also proposes a computer storage medium on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor, the steps of the information interaction method described above are implemented, which will not be repeated here.

[0149] Example 1

[0150] like Figure 3 The network shown has 4 nodes, of which nodes 1 and 2 are connected to one peripheral each, namely peripheral 1 and peripheral 2; node 3 is connected to two peripherals through a switch, namely peripheral 3 and peripheral 4; node 4 has no peripherals. APP1 is deployed on peripheral 2, peripheral 3 and node 4, and needs to sense, discover and maintain each other's status; APP2 and APP3 are deployed on peripheral 1 and peripheral 4 respectively. The same APPs deployed on different devices need to sense, discover and maintain each other's status. For example, APP2 deployed on peripheral 4 needs to sense the information of APP2 deployed in other locations, but does not need to sense the information of APP3.

[0151] After each APP is started, it will register and subscribe to the node to which it belongs. After each node responds, it will maintain the keep-alive status with the APP. After completing the registration, the initial local node APP status table of each node is shown in the following table:

[0152]

[0153]

[0154] After node 1 sends the APP information broadcast, assuming that the entire network has received it, the local node APP status table of each node is updated as follows:

[0155]

[0156]

[0157] Among them, only the APP on the peripheral 4 of node 3 has subscribed to the information change notifications of APP2 and APP3, so node 3 will send a "status change release" to the APP on the peripheral 4, the content is as follows:

[0158]

[0159] The content of the APP summary notification sent by node 3 is shown in the following table:

[0160] Home Node ID Change ID of APP under the control of the home node 3 1 1 1

[0161] After receiving the "APP summary notification" from node 3, node 2 and node 4 will send "APP information request" to node 3 respectively. The contents of each "APP information request" message are shown in the following table:

[0162]

[0163] After receiving the "APP Information Request" from Node 2 and Node 4, Node 3 will send "APP Information Response" to Node 2 and Node 4 respectively. The contents of the messages are shown in the following table.

[0164]

[0165]

[0166] After receiving the APP information response from node 3, node 2 and node 4 update their own local node APP status tables respectively, and notify their respective APP1s that "peripheral device 3.APP1" is online.

[0167] Through the above methods, the entire network can gradually achieve the effect of consistent APP status.

[0168] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solution of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solution to deviate from the spirit and scope of the technical solution of the present invention.

Claims

1. A wireless ad hoc network application information interaction method based on infectious diffusion, applied to network nodes or peripherals, characterized in that: include: 1) When a node finds that the status information of the local APP, that is, the original APP, changes, it triggers the sending of an "APP information broadcast" message; 2) The node that receives the "APP information broadcast" message updates the corresponding table entry in its own local node APP status table to make the locally saved APP status and APP release information consistent with the original APP status and original APP release information; 3) Each node in the network periodically constructs an "APP summary notification" and broadcasts it in the 1-hop neighbor to inform the 1-hop neighbor node that it has currently collected summary information of all APP statuses belonging to each node in the network; 4) After receiving the "APP Summary Announcement" message, the neighboring node compares the message entry with the entry in its own local APP status table. If the APP status and APP release information indicated by the "APP Summary Announcement" are new, the neighboring node sends an "APP Information Request" to the source node of the "APP Summary Announcement" message to obtain the new APP status and APP release information; 5) After receiving the "APP Information Request" message, the node will extract the APP status and APP release information content required for the "APP Information Request" from its own local APP status table, and send it to the source node of the "APP Information Request" message through the "APP Information Response" message; 6) After receiving the "APP Information Response" message, the node updates the corresponding entry in its own local node APP status table, so that the local area continues to maintain the latest APP status and APP release information.

2. According to claim 1, a method for wireless ad hoc network application information interaction based on infectious diffusion is characterized in that: When the node finds that the local APP status information has changed, triggering an "APP information broadcast" message to be sent specifically includes: When a node finds in the local APP status table that the belonging node ID is equal to its own ID and the "APP change identifier" of the table item is inconsistent with the previous "APP information broadcast" sent in the air interface, it triggers the sending of an "APP information broadcast" message to the entire network. The message carries at least "belonging node ID", "APP change identifier under the belonging node" and "APP information under the belonging node". "APP information under the belonging node" consists of one or more message items, and each message item contains at least one set of: "APP index", "APP identifier", "APP release information", "APP survival time", "APP change identifier", and "APP status" information.

3. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 2, characterized in that: The node receiving the "APP information broadcast" message performs the following processing according to the "belonging node ID", "APP change identifier under the belonging node" and "APP information under the belonging node" in the "APP information broadcast" message: a) If the "APP Information Broadcast" message is sent by its own node, the receiving node discards the "APP Information Broadcast" message and the processing ends; b) If the receiving node determines that the APP status information in the local node APP status table is newer than the corresponding entry in the "APP information broadcast" message, the receiving node discards the "APP information broadcast" message and the processing ends; c) The receiving node processes each "APP information under the home node" entry in the "APP information broadcast" message: i) If the "APP information under the home node" entry is not found in the local node APP status table of the receiving node itself, the entry in the "APP information broadcast" message is directly inserted into the local node APP status table for storage; ii) Otherwise, the receiving node performs the following processing on the entry found in its own local node APP status table: If the "APP change identifier" of the table entry is greater than or equal to the value in the "APP information broadcast" message entry, skip the processing of the "APP information broadcast" message entry; otherwise, replace the corresponding content of the APP status table entry with the "APP information broadcast" message entry.

4. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 3 is characterized in that: The "APP summary notification" includes at least one or more "belonging node change identification entries", each of which includes at least "belonging node ID" and "APP change identification under the belonging node".

5. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 4, characterized in that: After receiving the "APP summary notification", the neighboring node performs the following processing on each "home node change identification entry" therein: a) If the "home node ID" of the "home node change identification entry" is the same as the own node ID, skip this entry and directly proceed to the next entry; b) If an entry is found in the local node APP status table, whose "home node ID" is equal to the "home node ID" of the "home node change identification entry" being processed, but the "home node subordinate APP change identification" in the entry is greater than or equal to the "home node subordinate APP change identification" of the "home node change identification entry" being processed, then skip this entry and directly proceed to the next entry; c) Otherwise, the adjacent node constructs an "APP information request" message and sends it to the node that issues the "APP summary notification". The "APP information request" message carries at least: the requesting node ID, the target node ID, the belonging node ID, the APP change identifier of the belonging node stored in the local node APP status table, and the APP summary list of the belonging node.

6. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 5, characterized in that: The node that receives the "APP information request" performs the following processing: a) If the "target node ID" of the "APP information request" message is not equal to the node ID of the node itself, the "APP information request" message is discarded and the processing ends; b) Otherwise, initialize the "APP Information Response" message, which at least includes: responding node ID, requesting node ID, and response message item, where the responding node ID is the current node ID, the requesting node ID is the sending node ID of the "APP Information Request", and the response message item is 0; c) For each "home node ID" in the "APP information request", search the local node APP status table: i) If no corresponding table entry with the same "home node ID" is found, skip all APP summary lists under the "home node ID" in the "APP information request" and directly proceed to the next "home node ID" corresponding table entry; ii) Otherwise, if a corresponding entry with the same “home node ID” is found, the following processing is performed: If the "APP change identifier under the home node" corresponding to the "home node ID" in the "APP information request" is greater than or equal to the corresponding value in the local node APP status table item, then skip the summary list of all APPs under the "home node ID" in the "APP information request" and directly proceed to the next "home node ID" corresponding table item; Otherwise, the node compares the found "APP information request" with the "APP information under the home node" entry with the same "home node ID" in the local APP status table. If the entry only exists in the "APP Information Request", insert the "APP Delete Entry" in the "APP Information Response" message; If the entry only exists in the local APP status table, insert "APP New Entry" into the "APP Information Response" message; If the entry exists in both the "APP Information Request" and the local APP status table, insert the "APP Update Entry" into the "APP Information Response" message; Each time an entry is inserted into the "APP response message", the number of response entries increases by 1; d) If the number of "Response Message Items" of the "APP Information Response" message is 0 after the "APP Information Request" message is processed, the "APP Information Response" message is deleted and the processing is completed; otherwise, the "APP Information Response" message is sent on the air interface.

7. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 6, characterized in that: After receiving the "APP Information Response" message, if the "Requesting Node ID" is not equal to its own node ID, the node will discard it; otherwise, each response message item will be processed as follows: For "APP deletion entries", delete all matching corresponding items in the local node APP status table; For "New APP entry", insert a new "APP information under the jurisdiction of the belonging node" entry into the local node APP status table; For the "APP update entry", update the corresponding "APP information under the jurisdiction of the belonging node" entry in the local node APP status table.

8. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 1, characterized in that: Also includes: 1) After the APP works normally, it initiates the registration and subscription process. The APP obtains the address information required for registration and subscription of the corresponding node through preset or node active publishing; 2) The APP sends a "registration subscription request" message to the obtained registration subscription address information, which carries at least: APP identification, APP release information, and subscription content; 3) After receiving the "registration subscription request" from the APP, the node will send a "registration subscription response" message to the APP, which carries at least: the home node ID, APP identifier, and registration subscription result; 4) If the registration and subscription is successful, the node updates the local APP status table and inserts a new table entry. The table is a two-dimensional table. The first dimension contains at least: the home node ID and the APP change identifier under the home node; the second dimension is the APP information entry under the home node, and each entry contains at least: APP index, identifier, release information, survival time, change identifier, and status; The "belonging node ID" of the inserted entry is set to the ID of the current node itself, the "belonging node's APP change identifier" and "APP change identifier" are both increased by 1, the "APP index" is assigned by the node, the "APP identifier" and "APP release information" come from the registration subscription request message, the "APP survival time" is set to the maximum value allowed, and the "APP status" is set to "online"; 5) If the registration and subscription process fails, the node takes no action.

9. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 1, characterized in that: Also includes: 1) The node periodically sends a "keep alive request" message to each APP whose home node ID is equal to its own ID in its local APP status table. The message carries at least: home node ID, APP identifier, and sequence number; after receiving the message, each APP sends a "keep alive response" message to the node. The message carries at least: home node ID, APP identifier, and sequence number in the keep alive request; 2) After receiving the "keep alive response" message sent by each APP, if the node fails the validity check, no action will be taken. The validity check is to determine whether the home node ID, APP identifier and sequence number match the corresponding items in the "keep alive request" message; 3) If the validity check is passed, the "survival time" of the corresponding APP entry in the local APP status table is extended to the maximum allowed value T1, the "APP status" is updated to "online", and the "APP change identifier" and "APP change identifier under the belonging node" are updated at the same time; 4) When the node fails to receive a keep-alive response message from the APP for K consecutive times and the "APP status" of the corresponding entry in the local APP status table is "online", it indicates that the APP is invalid, and the "APP status" of the corresponding entry is set to "offline", the "APP survival time" is changed to T2, and the "APP change flag" and "APP change flag under the belonging node" are both increased by 1; 5) When the "APP status" of an entry in the local APP status table is equal to "offline" and the "APP survival time" is reduced to 0, the APP entry is directly deleted; when all APP entries under the home node are deleted, the table entry corresponding to the home node is directly deleted.

10. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 1, characterized in that: Also includes: 1) When the "publishing information" of an APP needs to be changed, the APP sends an "information change request" to the node to notify the node to update the "publishing information" of the APP. The "information change request" message carries at least: the home node ID, the APP identifier, and the publishing information; 2) After receiving the "information change request" message, the node responds to the APP, and then updates the "APP release information" of the corresponding APP entry in the local node APP status table, and at the same time, the corresponding "APP change identifier" and "APP change identifier under the belonging node" are both increased by 1.

11. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 1, characterized in that: Also includes: 1) The APP actively initiates the deregistration process through a "deregistration request" message, which contains at least: home node ID and APP identifier; 2) After receiving the deregistration request, the node sends a "deregistration response" to the APP. If the "APP status" of the corresponding APP entry in the local APP status table is "online", it indicates that the APP is invalid, and the "APP status" corresponding to the entry is set to "offline", the "APP survival time" is changed to T2, and the "APP change identifier" and "APP change identifier under the belonging node" are both increased by 1; if the "APP status" of the corresponding APP entry in the local APP status table is not "online" or the APP corresponding to the "deregistration request" is not found, no action is taken; 3) When the "APP status" of an entry in the local APP status table is equal to "offline" and the "APP survival time" is reduced to 0, the APP entry is directly deleted; when all APP entries under the home node are deleted, the table entry corresponding to the home node is directly deleted.

12. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 1, characterized in that: If a node finds that the network topology has changed, it will proceed as follows: If a node is found to be unreachable, all entries in the local node APP status table whose belonging node ID is equal to the unreachable node ID are directly deleted; If a new node is found online or the node becomes reachable, wait for the APP information to spread to the local area according to the transmission and diffusion process.

13. The method for wireless ad hoc network application information interaction based on infectious diffusion according to claim 1, characterized in that: If a node finds that an entry in the local node APP status table whose belonging node ID is not equal to its own node ID is updated, the node publishes the updated APP status and APP release information to the APPs that belong to its own node and have subscribed to the APP status and APP release information changes through a "status change release" message; the "status change release" message carries at least: belonging node ID, APP identifier, APP release information, and APP status.

14. A wireless ad hoc network application information interaction device based on infectious diffusion, applied to network nodes or peripherals, characterized in that: It comprises a memory and a processor connected to the memory, and the processor is configured to implement the information interaction method according to any one of claims 1 to 13.

15. A computer storage medium having computer readable instructions stored thereon, characterized in that: When the computer-readable instructions are executed by a processor, the information interaction method according to any one of claims 1 to 13 is implemented.

Images