Disaster emergency communication method based on decentralized ad hoc network and wireless communication device

Abstract

The embodiment of the application discloses a disaster emergency communication method based on a decentralized ad hoc network and a wireless communication device, and the method comprises the following steps: in response to monitoring that a core network is paralyzed, switching to an emergency networking mode; in the emergency networking mode, enabling a decentralized multi-hop relay protocol, generating and broadcasting a self-defined Beacon frame carrying node roles and dynamic relay weights, and cooperating with surrounding wireless communication nodes to form a decentralized multi-hop relay network; and in the multi-hop relay network, transmitting emergency information according to the node role information and the dynamic relay weight of each wireless communication node. The application can automatically form a local self-help platform for surrounding routers, gateways, mobile phones and other devices when the core network is unavailable, realize the rapid circulation of emergency information, and significantly improve the self-help and mutual-help ability in a disaster area.

Description

Technical Field

[0001] This application relates to wireless communication technology, and more particularly to a disaster emergency communication method and wireless communication device based on a decentralized self-organizing network. Background Technology

[0002] Current home broadband and metropolitan area networks heavily rely on core routers, domain name servers, and internet backbone links. Once the core network is damaged, the entire system will be completely paralyzed, and information exchange between local devices will be impossible.

[0003] In the process of implementing this application, the inventors discovered the following defects in the prior art: Reliance on centralized networking leads to the collapse of the core network and the interruption of global communication, which in turn prevents the flow of rescue information, ultimately resulting in low self-rescue efficiency and increased loss of life and property.

[0004] The need for manual activation and static networking can lead to response delays during sudden disasters, thus missing the golden window for rescue.

[0005] The lack of optimization in general-purpose Mesh protocols leads to rapid power consumption, broadcast storms, inefficient routing, and security vulnerabilities, making them unable to support long-term, multi-type emergency communication needs. Summary of the Invention

[0006] This application provides a disaster emergency communication method and device based on a decentralized self-organizing network. When the core network is unavailable, it automatically builds a local self-rescue platform for surrounding routers, gateways, mobile phones and other devices, enabling the rapid flow of emergency information and significantly improving the self-rescue and mutual rescue capabilities in disaster areas.

[0007] In a first aspect, embodiments of this application provide a disaster emergency communication method based on a decentralized self-organizing network, applied to multiple wireless communication nodes, the method comprising: In response to the detection of a core network failure, the system switches to emergency networking mode. In the emergency networking mode, a decentralized multi-hop relay protocol is enabled to generate and broadcast custom Beacon frames carrying node roles and dynamic relay weights, which work in conjunction with surrounding wireless communication nodes to form a decentralized multi-hop relay network. On the multi-hop relay network, emergency information is transmitted based on the node role information and dynamic relay weight of each wireless communication node.

[0008] In at least one possible implementation, the method further includes: Monitor the dynamic relay weight of the current root node; In response to the current root node's dynamic relay weight dropping below that of any relay node, the node role of that root node is cleared, and a new root node is elected from the backup root nodes.

[0009] In at least one possible implementation, the root node is elected through the following steps: Each wireless communication node detects whether it maintains a wired backhaul connection with the outside world and obtains its remaining energy value and geographical location information. The remaining energy value and the number of neighboring nodes are weighted and calculated to generate a dynamic relay weight; Among the wireless communication nodes that maintain wired backhaul connections, the wireless communication node with the highest dynamic relay weight is elected as the root node.

[0010] In at least one possible implementation, the method further includes: In response to the loss of wired backhaul connection with the outside world by the current root node, the root node role of that root node is cleared, and a new root node is elected from the backup root nodes; and / or Set the wireless communication node that maintains a wired backhaul connection but has not been elected as the root node as the backup root node; and / or In response to the absence of a wireless communication node with a wired backhaul connection to the outside world, the wireless communication node with the highest dynamic relay weight is elected as the root node among all wireless communication nodes.

[0011] In at least one possible implementation, the method further includes: Among the wireless communication nodes not elected as root nodes, those with remaining energy values ​​higher than a preset threshold and capable of stable communication with at least two other wireless communication nodes simultaneously are elected as relay nodes; and / or All wireless communication nodes that were not elected as root nodes, backup root nodes, or relay nodes are set as end nodes.

[0012] In at least one possible implementation, the method further includes: The wireless communication node estimates its relative distance to each of the surrounding wireless communication nodes based on the signal strength of the received Beacon frames from the surrounding wireless communication nodes. When forwarding emergency information, the wireless communication node prioritizes selecting a node with a high dynamic relay weight and a relative distance within a preset directional range pointing towards the target area from the surrounding wireless communication nodes as the next-hop relay node.

[0013] In at least one possible implementation, the emergency information carries a severity weight, which is generated through the following steps: The source wireless communication node determines the basic urgency level based on the notification type of the emergency information. The notification types include dangerous situation notification, emergency medical request notification, missing person notification, and emergency material shortage notification. Different notification types correspond to different basic urgency levels. The source wireless communication node obtains its current remaining energy value and determines the energy correction coefficient based on the remaining energy value; The source wireless communication node performs a weighted calculation on the basic urgency level and the energy correction coefficient to generate the urgency weight of the emergency information; The source wireless communication node carries the severity weight along with the emergency information and sends it together.

[0014] In at least one possible implementation, after each relay node in the multi-hop relay network receives emergency information carrying a severity weight, it performs the following steps: Extract the severity weights carried in the emergency information; Obtain the current dynamic relay weight of this node, and perform a weighted summation of the urgency weight and the dynamic relay weight to generate a comprehensive transmission priority value; Based on the comprehensive transmission priority value, multiple urgent messages to be forwarded locally are sorted, with those having the higher comprehensive transmission priority value being forwarded first. The severity weight decreases by a preset attenuation coefficient after each relay node to limit the unlimited priority spread of emergency information in the network.

[0015] In at least one possible implementation, the dynamic relay weight is updated and propagated through the following steps: Each wireless communication node reduces its dynamic relay weight by a preset step size after successfully forwarding an emergency information notice. Each wireless communication node, when forwarding an emergency information notice to other nodes, includes its current dynamic relay weight in the notice and sends it along with the notice. The node that receives the notification extracts the sender's dynamic relay weight carried therein and uses this weight to update the weight record of the corresponding neighbor node stored locally.

[0016] In at least one possible implementation, the method further includes: In emergency networking mode, the wireless communication node monitors the changes in its node role and dynamic relay weight in real time. The node role information and dynamic relay weight are set in the VendorSpecific information element of the custom Beacon frame. When the node role changes, or when the change in the dynamic relay weight exceeds a preset change threshold, the wireless communication node regenerates the content of the Vendor Specific information element. The wireless communication node writes the regenerated Vendor Specific information element into the Beacon frame through the hostapd control interface and triggers the immediate retransmission of the Beacon frame. The wireless hotspot is not restarted during the update process.

[0017] Secondly, embodiments of this application provide a wireless communication device, including a processor and a memory, the memory being coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, causing the processor to execute the steps in the disaster emergency communication method based on a decentralized self-organizing network as described in the first aspect.

[0018] The beneficial effects of this application are: This application's embodiments automatically switch to emergency networking mode without user intervention after detecting core network failure. Custom Beacon frames carrying node roles and dynamic relay weights are generated and broadcast to form a decentralized multi-hop relay network in collaboration with surrounding wireless communication nodes. Emergency information is transmitted via multiple hops based on each node's role and weight. This achieves a second-level automatic response after core network failure, seizing the golden window for rescue. Simultaneously, dynamic routing information is carried using the Vendor Specific information element reserved in the standard Beacon frame. Since Beacon frames are required to be sent periodically by the 802.11 protocol, piggybacking routing information does not increase any additional channel occupation or power consumption, achieving zero overhead for routing signaling. Furthermore, the fully decentralized architecture eliminates the single point of failure risk caused by centralized managers or reliance on external infrastructure in traditional solutions. Each node independently completes routing decisions based on local Beacon information, ensuring that a local self-rescue network can be quickly established to achieve reliable transmission of emergency information even after core network failure. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a disaster emergency communication method based on a decentralized self-organizing network, according to an embodiment of this application.

[0021] Figure 2 This is a schematic diagram of the root node actively yielding process in the disaster emergency communication method based on decentralized self-organizing network in an embodiment of this application.

[0022] Figure 3 This is a schematic diagram of the node role election process in the disaster emergency communication method based on a decentralized self-organizing network according to an embodiment of this application.

[0023] Figure 4 This is a schematic diagram of the structure of a wireless communication device according to an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0025] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0026] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0027] Please refer to Figure 1 This application provides a disaster emergency communication method based on a decentralized self-organizing network, applied to multiple wireless communication nodes. The method includes: In step S100, in response to the detection of a core network failure, the system switches to emergency networking mode; In step S200, under the emergency networking mode, a decentralized multi-hop relay protocol is enabled to generate and broadcast a custom Beacon frame carrying node roles and dynamic relay weights, which works in conjunction with surrounding wireless communication nodes to form a decentralized multi-hop relay network. In step S300, emergency information is transmitted on the multi-hop relay network according to the node role information and dynamic relay weight of each wireless communication node.

[0028] Please refer to Figure 2 In at least one possible implementation, the method further includes: In step S201, the dynamic relay weight of the current root node is monitored; In step S202, in response to the dynamic relay weight of the current root node falling below that of any relay node, the node role of the root node is cleared, and a new root node is elected from the backup root nodes.

[0029] Please refer to Figure 3 In at least one possible implementation, the root node is elected through the following steps: In step S203, each wireless communication node detects whether it maintains a wired backhaul connection with the outside world and obtains its remaining energy value and geographical location information. In step S204, the remaining energy value and the number of neighboring nodes are weighted and calculated to generate dynamic relay weights; In step S205, among the wireless communication nodes that maintain wired backhaul connections, the wireless communication node with the highest dynamic relay weight is elected as the root node.

[0030] In at least one possible implementation, the method further includes: In response to the loss of wired backhaul connection with the outside world by the current root node, the root node role of that root node is cleared, and a new root node is elected from the backup root nodes; and / or Set the wireless communication node that has a wired backhaul connection but has not been elected as the root node as the backup root node.

[0031] In response to the absence of a wireless communication node with a wired backhaul connection to the outside world, the wireless communication node with the highest dynamic relay weight is elected as the root node among all wireless communication nodes.

[0032] In at least one possible implementation, the method further includes: Among the wireless communication nodes that are not elected as root nodes, the wireless communication nodes with remaining energy values ​​higher than a preset threshold and capable of stable communication with at least two other wireless communication nodes at the same time are elected as relay nodes. All wireless communication nodes that were not elected as root nodes, backup root nodes, or relay nodes are set as end nodes.

[0033] In at least one possible implementation, the method further includes: The wireless communication node estimates its relative distance to each of the surrounding wireless communication nodes based on the signal strength (RSSI) of the Beacon frames received from the surrounding wireless communication nodes. When forwarding emergency information, the wireless communication node prioritizes selecting a node with a high dynamic relay weight and a relative distance within a preset directional range pointing towards the target area from the surrounding wireless communication nodes as the next-hop relay node.

[0034] In at least one possible implementation, the emergency information carries a severity weight, which is generated through the following steps: The source wireless communication node determines the basic urgency level based on the notification type of the emergency information. The notification types include dangerous situation notification, emergency medical request notification, missing person notification, and emergency material shortage notification. Different notification types correspond to different basic urgency levels. The source wireless communication node obtains its current remaining energy value and determines the energy correction coefficient based on the remaining energy value; The source wireless communication node performs a weighted calculation on the basic urgency level and the energy correction coefficient to generate the urgency weight of the emergency information; The source wireless communication node carries the severity weight along with the emergency information and sends it together.

[0035] In at least one possible implementation, after each relay node in the multi-hop relay network receives emergency information carrying a severity weight, it performs the following steps: Extract the severity weights carried in the emergency information; Obtain the current dynamic relay weight of this node, and perform a weighted summation of the urgency weight and the dynamic relay weight to generate a comprehensive transmission priority value; Based on the comprehensive transmission priority value, multiple urgent messages to be forwarded locally are sorted, with those having the higher comprehensive transmission priority value being forwarded first. The severity weight decreases by a preset attenuation coefficient after each relay node to limit the unlimited priority spread of emergency information in the network.

[0036] In at least one possible implementation, the dynamic relay weight is updated and propagated through the following steps: Each wireless communication node reduces its dynamic relay weight by a preset step size after successfully forwarding an emergency information notice. Each wireless communication node, when forwarding an emergency information notice to other nodes, includes its current dynamic relay weight in the notice and sends it along with the notice. The node that receives the notification extracts the sender's dynamic relay weight carried therein and uses this weight to update the weight record of the corresponding neighbor node stored locally.

[0037] In one specific implementation, emergency information includes the following standardized notification types: (1) Hazardous situation notifications (such as fire, gas leak, building collapse): These are given the highest priority. At the network layer, this type of notification uses preemptive queue insertion; even if there are already ordinary notifications waiting to be sent in the queue, the hazard notification is inserted directly at the head of the queue and sent immediately upon arrival. At the MAC layer, this type of notification uses the shortest retransmission backoff window (CW_min=3, CW_max=7) to obtain the highest access probability in channel contention.

[0038] (2) Emergency medical request notices and missing person notices: These are given medium priority. At the network layer, a head-of-queue priority strategy is adopted: if a newly arrived medium-priority notice has a higher priority than an existing notice in the queue, it is inserted at the head of the queue without interrupting ongoing transmission. At the MAC layer, a medium backoff window (CW_min=15, CW_max=31) is adopted.

[0039] (3) Emergency Supplies Shortage Notice: Given ordinary priority. The network layer adopts the first-in-first-out strategy, and the MAC layer adopts the standard backoff window (CW_min=31, CW_max=1023).

[0040] The aforementioned MAC layer backoff parameters are broadcast to neighboring nodes through the extended Vendor Specific information element in the Beacon frame, enabling all nodes to use consistent differentiated parameters for different priority announcements during channel contention, ensuring that high-priority announcements receive priority channel access throughout the network.

[0041] In at least one possible implementation, the method further includes: In emergency networking mode, the wireless communication node monitors the changes in its node role and dynamic relay weight in real time. The node role information and dynamic relay weight are set in the VendorSpecific information element of the custom Beacon frame. When the node role changes, or when the change in the dynamic relay weight exceeds a preset change threshold, the wireless communication node regenerates the content of the Vendor Specific information element. The wireless communication node writes the regenerated Vendor Specific information element into the Beacon frame through the hostapd control interface and triggers the immediate retransmission of the Beacon frame. The wireless hotspot is not restarted during the update process.

[0042] Compared with the prior art, the embodiments of this application achieve the following technical effects: Automatic response in seconds: Automatically detects and switches over after the core network fails, without user intervention, seizing the golden window for rescue.

[0043] Fully decentralized: It does not rely on a centralized manager or external infrastructure, eliminating single points of failure.

[0044] Zero additional signaling overhead: The routing information is carried using the Vendor IE reserved in the standard Beacon frame without adding any additional channel occupation.

[0045] Smooth root node switching: A predictive proactive yielding mechanism enables root node switching without service interruption.

[0046] It can work with zero infrastructure: Root election is based on the node's own capabilities and does not depend on external router signals.

[0047] Energy balancing: Dynamic weights reflect the remaining energy, which decays after forwarding, thus extending the overall lifespan of the network.

[0048] Broadcast storm suppression: Geographically assisted routing transforms the exponential spread of flooding into directional transmission.

[0049] Low cost and easy deployment: Implemented through software / firmware upgrades (in the form of an OpenWRT software package), requiring no additional hardware.

[0050] The embodiments of this application can be deployed on existing home routers and smart terminal devices in the form of OpenWRT software packages and mobile applications without additional hardware investment. They are suitable for various disaster emergency scenarios such as earthquakes, floods, and wars that cause core network paralysis, and have broad industrial practical value and social benefits.

[0051] The method of this application embodiment is described in detail below with reference to an exemplary application scenario.

[0052] Application Scenario: In a residential area of ​​a city, multiple home wireless routers supporting OpenWRT firmware (denoted as nodes A, B, C, D, and E) and several residents' mobile phones (denoted as nodes F, G, and H) were deployed. All devices have the accompanying software of this application embodiment installed. Normally, node A is connected to the Internet via fiber optic cable, while the other nodes access the Internet normally through their respective broadband lines. One day, an earthquake occurs, and the entire core network of the area is paralyzed.

[0053] Phase 1: Automatic Detection of Core Network Failure After the earthquake, the fiber optic cable of node A broke. Node A's network status detection module sent probe requests to multiple public DNS servers (8.8.8.8, 1.1.1.1) every 15 seconds. The first probe received no response, and the local failure counter increased from 0 to 1; the second probe also received no response, and the counter increased to 2; the third probe increased to 3; the fourth probe also failed, and the counter reached the preset threshold of 4.

[0054] Meanwhile, nodes B, C, D, and E are also independently conducting the same probes, each maintaining its own failure counter, and are not synchronized or dependent on each other.

[0055] When the failure counters of each node reach the threshold of 4, each node independently determines that the core network is paralyzed. Node A then automatically triggers the emergency networking mode switch. The entire process requires no user intervention and takes approximately 60 seconds (4 detection cycles) from the occurrence of the earthquake to the completion of the determination by all nodes.

[0056] In this example, each node independently completes the detection and judgment, without relying on any central node, and without requiring any user operation.

[0057] Phase Two: Emergency Networking and Beacon Frame Broadcasting After each node switches to emergency networking mode, the IEEE 802.11s Mesh protocol is automatically enabled.

[0058] Node A detects its own status: the wired backhaul connection is broken (fiber optic cable is broken), the UPS has 85% remaining power, and it counts 4 neighboring nodes (B, C, D, E) based on the received Beacon frames.

[0059] Node A calculates the dynamic relay weight: WA = α × 85% + β × 4. Assuming α = 0.6 and β = 0.4, then WA = 0.6 × 85 + 0.4 × 4 = 51 + 1.6 = 52.6.

[0060] Node B status: no wired connection, UPS power 92%, number of neighbors 3 (A, C, E), WB=0.6×92+0.4×3=55.2+1.2=56.4.

[0061] Node C status: No wired connection, mains power is normal (powered by the community's backup generator), power is 100%, number of neighbors is 5 (A, B, D, E, F), WC=0.6×100+0.4×5=60+2=62.

[0062] Node D status: no wired connection, 45% battery (UPS about to run out), number of neighbors 2 (A, C), WD=0.6×45+0.4×2=27+0.8=27.8.

[0063] Node E status: no wired connection, battery level 78%, number of neighbors 3 (A, B, C), WE = 0.6 × 78 + 0.4 × 3 = 46.8 + 1.2 = 48.

[0064] Each node generates a custom Beacon frame, filling its Vendor Specific information element (Element ID 0xDD) with: OUI (0x00 0x11 0x22), emergency mode flag (0x01), node role (initially all are Leaf, 0x03), node ID (generated from MAC address mapping), and dynamic relay weight (W value of each node). Then, each node begins periodically broadcasting this custom Beacon frame.

[0065] This example utilizes the Vendor Specific IE reserved in the standard Beacon frame to carry multi-dimensional dynamic information node roles and dynamic relay weights without adding any additional signaling overhead.

[0066] Phase 3: Autonomous Election of Node Roles Each node receives Beacon frames from each other to obtain information about the roles and weights of its neighbors, and then initiates an autonomous election process.

[0067] Root node election: Each node checks whether it maintains a wired backhaul connection. In this round, all nodes have no wired connection (all fiber optic cables are broken). Therefore, the node with the highest dynamic relay weight among all nodes is elected as the root node.

[0068] Compare the weights of each node: C (62) > B (56.4) > A (52.6) > E (48) > D (27.8). Node C is selected as the root node, and the Role field in the Vendor Specific information element of its Beacon frame is changed from 0x03 (Leaf) to 0x01 (Root).

[0069] Since no node maintains a wired backhaul connection, no backup root node is generated in this round.

[0070] Relay node election: Among the remaining nodes, each node is checked to see if it meets the Relay condition: the remaining energy is higher than the preset threshold (e.g., 20%) and it can establish a stable link with at least two other nodes at the same time (RSSI is higher than -70dBm in 3 consecutive Beacon cycles).

[0071] Node B: Battery level 92% > 20%, stable neighbors A (RSSI -55dBm), C (-50dBm), E (-60dBm) total 3 ≥ 2 → Selected as relay node, Role set to 0x02.

[0072] Node A: Battery level 85% > 20%, stable neighbors B (-55dBm), C (-52dBm), D (-65dBm), E (-58dBm) total 4 ≥ 2 → Selected as relay node, Role set to 0x02.

[0073] Node E: Battery level 78% > 20%, stable neighbors A (-58dBm), B (-60dBm), C (-62dBm) total 3 ≥ 2 → Selected as relay node, Role set to 0x02.

[0074] Node D: Battery level 45% > 20%, stable neighbors are only A (-65dBm) and C (-70dBm critical), C's RSSI occasionally falls below the threshold during continuous monitoring, so it is judged as unstable, and there is only 1 stable neighbor < 2 → it failed to be selected as a relay.

[0075] End node settings: If node D (45% battery, only 1 stable neighbor) and mobile nodes F, G, and H (low-battery terminal devices) are neither Root nor Relay, they will be automatically set as leaf nodes, and the Role field will remain at 0x03.

[0076] At this point, the network has formed a complete three-level topology: root node C (responsible for coordinating the entire network) → relay nodes A, B, and E (responsible for backbone forwarding) → end nodes D, F, G, and H (only send and receive their own information and do not undertake forwarding obligations).

[0077] This example achieves optimized distribution of functional division and energy consumption through a three-tiered role hierarchy: low-power nodes automatically step down to Leaf and do not undertake forwarding, thus extending the overall network lifespan.

[0078] Phase Four: Emergency Information Transmission Based on Role and Weight Routing Decisions A user discovers a gas leak in the neighboring building via mobile node F. Using the app, they select the "Hazard Notice" template and fill in "Gas leak in Unit XXX, Building XX. Please stay away." Node F, as a Leaf node, needs to send this emergency message out.

[0079] Next jump selection: Node F (Leaf) receives Beacon frames from surrounding nodes and extracts the roles and weights of each neighbor: Node C (Root): Weight 62, Direction: Northeast; Node B (Relay): Weight 56.4, Direction East; Node A (Relay): Weight 52.6, direction North.

[0080] Node F's relative distance and direction are estimated based on RSSI: Node C is approximately 15 meters northeast (RSSI -45dBm), Node B is approximately 20 meters east (RSSI -50dBm), and Node A is approximately 25 meters north (RSSI -55dBm). The target area (the building with the gas leak) is located in the southeast direction, and Node B is closest to the target.

[0081] Node F applies the fusion decision rule: prioritize nodes with high dynamic relay weights and directions pointing towards the target area. Node B has a weight of 56.4 and its direction is correct, while node C has a high weight (62) but its direction deviates from the target. Ultimately, node F selects node B as its next hop.

[0082] Multi-hop transmission: Node F sends a "danger situation notice" to Node B. Upon receiving the notice, Node B extracts its content and identifies it as a "danger situation notice": highest priority. Node B selects Root C (with a weight of 62, Relay A of 52.6, and Relay E of 48) as its next hop, as it has the highest weight (the danger notice needs to spread throughout the network as quickly as possible, making Root C the optimal choice). Node B then forwards the notice to Node C.

[0083] Once node C (Root) receives the notification, it broadcasts it to all its neighbors (A, B, E, D). Each node then forwards the notification to its child nodes, until eventually all nodes in the network receive the warning.

[0084] Cross-layer priority transmission: Because this notification type is "dangerous situation notification," the shortest retransmission backoff window (CW_min=3, CW_max=7) is used at the MAC layer, and preemptive queue insertion is used at the network layer, which can interrupt the ongoing transmission of ordinary notifications. This means that even if the channel is congested, danger notifications can be sent with the highest probability of preempting the channel.

[0085] This example maps application layer message types to MAC layer contention parameters, enabling high-priority announcements to achieve an exponentially higher access success rate when the channel is congested.

[0086] Phase 5: Root Node Proactively Yields and Smoothly Switches Over After several hours of emergency communication, the mains power to root node C was interrupted due to the exhaustion of fuel in the community's backup generator, and the system switched to UPS power.

[0087] The battery level of node C gradually decreases from 100%: 90%→80%→70%→60%→55%, and the dynamic relay weight of node C decreases accordingly (assuming α=0.6, β=0.4, and the number of neighbors remains 5): When the battery is 100% charged: WC = 0.6 × 100 + 0.4 × 5 = 62; When the battery is at 60% charge: WC = 0.6 × 60 + 0.4 × 5 = 36 + 2 = 38; When the battery is at 55% charge: WC = 0.6 × 55 + 0.4 × 5 = 33 + 2 = 35.

[0088] Meanwhile, relay node B's battery level remained at 92% (connected to a backup power source), with a weight of 56.4; relay node A's battery level was 85%, with a weight of 52.6.

[0089] When the weight of node C (35) drops below the weight of relay node B (56.4): Active Removal of Root Identifier: When node C detects that its weight has fallen below that of relay node B, it proactively removes the Root identifier (the Role field changes from 0x01 to 0x02) from the Vendor Specific information element of its Beacon frame, switching to a regular relay node. This behavior is a self-determined and proactive action by node C, requiring no external triggering or API calls.

[0090] Backup Root Node Competition: Since no node maintains a wired connection in this round, there is no backup root node. After each Relay node (A, B, E) detects that the Root identifier of the original Root node C has disappeared (no Beacon frame containing the Root identifier has been received for 3 consecutive Beacon cycles), they compete again according to their respective dynamic relay weights: B (56.4) > A (52.6) > E (48). Node B is elected as the new Root, and sets the Root identifier (Role is set to 0x01) in the Vendor Specific information element of its Beacon frame.

[0091] Seamless handover: Throughout the handover process, network communication remains uninterrupted: While the old Root C voluntarily yields, the new Root B is already preparing to take over. Regular announcements already in progress continue to be transmitted, and newly arriving announcements are processed by the new Root B.

[0092] In this example, the Root node proactively yields its position when its weight decreases, without waiting for a complete disconnection. This achieves predictive proactive yielding, and the switching process is imperceptible to upper-layer services.

[0093] Phase Six: Beacon Vendor IE Dynamic Updates: During the root node switching process described above, node C's role changes from Root to Relay, and node B's role changes from Relay to Root.

[0094] Each node's emergency-mesh-daemon process monitors the node's role and dynamic relay weight changes in real time. When node B detects that its role has changed from Relay to Root, it immediately regenerates the Vendor Specific information element (changing the Role field from 0x02 to 0x01 and updating the Weight field to the current value 56.4).

[0095] Node B performs the update through the control interface.

[0096] The entire update process does not restart the Wi-Fi hotspot (no Wi-Fi reload is required), and all established connections remain unaffected. The new Beacon frame is broadcast in the next Beacon cycle (approximately 100ms later), and surrounding nodes immediately detect the presence of the new Root node B.

[0097] Phase 7, Core Network Recovery and Decommissioning: Hours later, rescue personnel arrived and restored fiber optic connectivity to the area. Node B (the current root)'s network status detection module received its first DNS response during periodic probes, resetting the failure counter to zero.

[0098] Node B continued to monitor and detected three consecutive successful probes, indicating that the core network had been stably restored. Node B cleared the Emergency Mode Flag (changing the Emergency Flag from 0x01 to 0x00) in the Vendor Specific information element of its Beacon frame and broadcast a "Core Network Has Restored" notification message to the entire network through the multi-hop relay network.

[0099] After receiving the notification, if no core network interruption is detected again within the preset waiting time (e.g., 30 seconds), each Leaf and Relay node will exit the emergency networking mode and return to the normal working mode: reconnect to the Internet and restore normal Internet access.

[0100] Based on the same concept as the above embodiments, this application also provides a disaster emergency communication system based on a decentralized self-organizing network, including multiple wireless communication nodes, each wireless communication node including: The network status detection module is used to continuously monitor the connectivity status of the core network during normal operation and maintain a failure counter locally; when a core network failure is detected, a trigger signal is generated. An emergency networking module, connected to the network status detection module, is configured to switch to emergency networking mode without user intervention upon receiving the trigger signal. In emergency networking mode, a custom Beacon frame is generated and broadcast. The Vendor Specific information element of the custom Beacon frame contains node role information and dynamic relay weight, and the content of the Vendor Specific information element is dynamically updated when the node role or dynamic relay weight changes. The routing module is configured to include the current dynamic relay weight of this node in the announcement each time an emergency information announcement is forwarded, and to update the weight records of the corresponding neighbor nodes stored locally based on the sender's dynamic relay weight carried in the received announcement. The emergency information processing module is configured to generate emergency information announcements containing globally unique serial numbers, and to perform deduplication based on the serial number when an announcement is received. Emergency information includes at least one of the following: danger situation announcement, emergency medical request announcement, missing person announcement, and emergency material shortage announcement. Different types of announcements correspond to different MAC layer contention parameters.

[0101] The multiple wireless communication nodes include home wireless routers running OpenWRT firmware and smart terminal devices with accompanying applications installed. The network status detection module and emergency networking module in the home wireless router are integrated into the router firmware in the form of an OpenWRT software package; The network status detection module and emergency networking module in the intelligent terminal device are integrated into the operating system of the intelligent terminal as a system background service.

[0102] Please refer to Figure 4 This application also provides a wireless communication device, including a processor 100 and a memory 200. The memory 200 is coupled to the processor 100 and is used to store computer program code, which includes computer instructions. When the processor 100 reads the computer instructions from the memory 200, the processor 100 executes the steps of the method in any possible implementation of any of the foregoing embodiments.

[0103] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the steps of the method in any of the possible implementations of the foregoing embodiments.

[0104] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0105] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A disaster emergency communication method based on a decentralized self-organizing network, applied to multiple wireless communication nodes, characterized in that, The method includes: In response to the detection of a core network failure, the system switches to emergency networking mode. In the emergency networking mode, a decentralized multi-hop relay protocol is enabled to generate and broadcast custom Beacon frames carrying node role information and dynamic relay weights, and to form a decentralized multi-hop relay network in cooperation with surrounding wireless communication nodes, wherein the node roles include at least root nodes and relay nodes. In the multi-hop relay network, emergency information is transmitted according to the node role information and dynamic relay weight of each wireless communication node; During transmission, monitor the dynamic relay weight of the current root node; In response to the current root node's dynamic relay weight dropping below any relay node, the node role of that root node is cleared, and a new root node is elected from the backup root nodes. The root node is elected through the following steps: Each wireless communication node detects whether it maintains a wired backhaul connection with the outside world and obtains its remaining energy value and geographical location information. The remaining energy value and the number of neighboring nodes are weighted and calculated to generate a dynamic relay weight; Among the wireless communication nodes that maintain wired backhaul connections, the wireless communication node with the highest dynamic relay weight is elected as the root node.

2. The disaster emergency communication method based on a decentralized self-organizing network according to claim 1, characterized in that, The method further includes: In response to the loss of wired backhaul connection with the outside world by the current root node, the root node role of that root node is cleared, and a new root node is elected from the backup root nodes; and / or Set the wireless communication node that maintains a wired backhaul connection but has not been elected as the root node as the backup root node; and / or In response to the absence of a wireless communication node with a wired backhaul connection to the outside world, the wireless communication node with the highest dynamic relay weight is elected as the root node among all wireless communication nodes.

3. The disaster emergency communication method based on a decentralized self-organizing network according to claim 2, characterized in that, The method further includes: Among the wireless communication nodes not elected as root nodes, those with remaining energy values ​​higher than a preset threshold and capable of stable communication with at least two other wireless communication nodes simultaneously are elected as relay nodes; and / or All wireless communication nodes that were not elected as root nodes, backup root nodes, or relay nodes are set as end nodes.

4. The disaster emergency communication method based on a decentralized self-organizing network according to any one of claims 1-3, characterized in that, The method further includes: The wireless communication node estimates its relative distance to each of the surrounding wireless communication nodes based on the signal strength of the received Beacon frames from the surrounding wireless communication nodes. When forwarding emergency information, the wireless communication node prioritizes selecting a node with a high dynamic relay weight and a relative distance within a preset directional range pointing towards the target area from the surrounding wireless communication nodes as the next-hop relay node.

5. The disaster emergency communication method based on a decentralized self-organizing network according to any one of claims 1-3, characterized in that, The emergency information carries a severity level weight, which is generated through the following steps: The source wireless communication node determines the basic urgency level based on the notification type of the emergency information. The notification types include dangerous situation notification, emergency medical request notification, missing person notification, and emergency material shortage notification. Different notification types correspond to different basic urgency levels. The source wireless communication node obtains its current remaining energy value and determines the energy correction coefficient based on the remaining energy value; The source wireless communication node performs a weighted calculation on the basic urgency level and the energy correction coefficient to generate the urgency weight of the emergency information; The source wireless communication node carries the severity weight along with the emergency information and sends it together.

6. The disaster emergency communication method based on a decentralized self-organizing network according to claim 5, characterized in that, After receiving emergency information carrying severity weights, each relay node in the multi-hop relay network performs the following steps: Extract the severity weights carried in the emergency information; Obtain the current dynamic relay weight of this node, and perform a weighted summation of the urgency weight and the dynamic relay weight to generate a comprehensive transmission priority value; Based on the comprehensive transmission priority value, multiple urgent messages to be forwarded locally are sorted, with those having the higher comprehensive transmission priority value being forwarded first. The severity weight decreases by a preset attenuation coefficient after each relay node to limit the unlimited priority spread of emergency information in the network.

7. The disaster emergency communication method based on a decentralized self-organizing network according to any one of claims 1-3, characterized in that, The dynamic relay weight is updated and propagated through the following steps: Each wireless communication node reduces its dynamic relay weight by a preset step size after successfully forwarding an emergency information notice. Each wireless communication node, when forwarding an emergency information notice to other nodes, includes its current dynamic relay weight in the notice and sends it along with the notice. The node that receives the notification extracts the sender's dynamic relay weight carried therein and uses this weight to update the weight record of the corresponding neighbor node stored locally.

8. The disaster emergency communication method based on a decentralized self-organizing network according to any one of claims 1-3, characterized in that, The method further includes: In emergency networking mode, the wireless communication node monitors the changes in its node role and dynamic relay weight in real time. The node role information and dynamic relay weight are set in the Vendor Specific information element of the custom Beacon frame. When the node role changes, or when the change in the dynamic relay weight exceeds a preset change threshold, the wireless communication node regenerates the content of the Vendor Specific information element. The wireless communication node writes the regenerated Vendor Specific information element into the Beacon frame through the hostapd control interface and triggers the immediate retransmission of the Beacon frame without restarting the wireless hotspot during the update process.

9. A wireless communication device, characterized in that, It includes a processor and a memory coupled to the processor. The memory is used to store computer program code, which includes computer instructions. When the processor reads the computer instructions from the memory, the processor performs the steps in the disaster emergency communication method based on a decentralized self-organizing network as described in any one of claims 1-8.

Images