A cluster coordination propagation method, device and system for emergency help-seeking information

Abstract

The application discloses a cluster cooperative propagation method, device and system of emergency help-seeking information. A plurality of emergency help-seeking communication devices with hot spot names presenting help-seeking information and providing offline message pages form a cluster; a source device detecting help-seeking generates a help-seeking event announcement carrying a release commitment value and an event fingerprint, and wireless message broadcasting between devices authenticated by a group key; a receiving device item by item checks, limit jump sends after deduplication with the event fingerprint, and switches its own hot spot name to a third hot spot name containing source location information, so that the help-seeking information is presented on surrounding ordinary mobile phones along the cluster; when the help-seeking is released, the source device publishes a release secret value, and each device is linked to release after one-way function verification. Random backoff listening suppression, per-source speed limiting black list and event age expiration mechanism of hop-by-hop accumulation suppress broadcast storm and garbage information, authentication encryption, counter anti-replay and event fingerprint prevent message hijacking and tampering, and the operation of a help seeker is completely consistent with a single field.

Description

Technical Field

[0001] This invention relates to the field of emergency communication technology, and in particular to a clustered collaborative propagation method, emergency rescue communication device, and emergency rescue communication system for emergency distress information. Background Technology

[0002] Following natural disasters such as earthquakes, floods, and typhoons, or in situations involving people trapped in elevators, underground parking garages, tunnels, or mountainous areas, public mobile communication networks are often disrupted or have no coverage, sometimes accompanied by power outages. In these situations, trapped individuals are unable to make calls or send location information, and rescuers struggle to ascertain the location, number, and extent of injuries of those trapped.

[0003] To address the aforementioned problems, existing technologies have developed a type of single-point wireless distress signaling device. For example, some beacon devices based on embedded wireless chips broadcast the name of a wireless LAN hotspot containing the word "DDoS," allowing nearby personnel to find it through their mobile phone's wireless network list; some offline message board devices based on single-board computers allow mobile terminals connected to their hotspots to browse and submit messages, enabling small-scale offline information exchange. The common limitations of these single-point devices are: first, their coverage is limited by the transmission power of a single device and building obstructions, typically only tens to a hundred meters; the distress signal can only reach a small area around the device, and if no one happens to be passing through that area, the information stops there and cannot spread to a wider area; second, the devices are isolated from each other, and the message information stored on each device is not shared, requiring rescuers to approach each device individually; third, there is a single point of failure problem—the distress signal carried by the device disappears when it is damaged or its power is depleted.

[0004] There is another type of wireless interconnected alarm in the existing technology, with wireless interconnected smoke alarm as a typical example: multiple alarms are interconnected via wireless radio frequency, and when one alarm detects smoke, all alarms will sound, and it is also possible to silence any one of them. While such solutions achieve multi-device linkage in alarm states, they suffer from the following shortcomings: First, interconnection typically relies on closed pairing of devices from the same brand and batch, limiting network scale and hindering open expansion at the community level. Second, they transmit a single alarm switch signal, unable to carry structured distress information such as the number of trapped individuals, injuries, location descriptions, and messages, and lack two-way communication capabilities. Third, the linkage status is invisible to nearby smartphones, relying entirely on the device's own audio and visual output; once the audio and visual signals attenuate, the information becomes unreachable. Fourth, deactivation signals such as silencing and resetting are usually simply coded or labeled, lacking authenticity verification linked to the original alarm event, posing a risk of being forged, replayed, or falsely triggered, thus silencing the real alarm. Fifth, the message duplication problem, not prominent in small-scale home interconnection, will evolve into a mutually reinforcing broadcast storm once expanded to high-density deployment scenarios, crowding out wireless channels and accelerating the depletion of emergency power supplies for each device.

[0005] Another type of ad hoc network emergency communication solution exists in existing technologies, including ad hoc network communication terminals based on long-range radio and mesh network chat applications based on near-field wireless technology. These solutions typically employ controlled flooding mechanisms to transmit messages in environments without infrastructure, limiting the propagation range with a hop count limit, avoiding duplicate processing by deduplication using message identifiers, and reducing redundant retransmissions by monitoring suppression. However: First, these solutions require all parties involved to possess dedicated terminals or pre-installed applications, contradicting the reality that "rescue participants are unspecified ordinary people in the surrounding area" in disaster scenarios; second, message revocation or status removal lacks a cryptographically binding verification mechanism to the original message, meaning any node in the network can, in principle, publish revocation messages; third, message timeliness management generally relies on the timestamps of each node, while emergency devices struggle to maintain reliable clocks under conditions of prolonged power outages and post-disaster restarts; fourth, these solutions do not address the issue of "how information can be directly seen by ordinary mobile phones in the surrounding area without dedicated equipment."

[0006] In summary, existing technologies lack a solution that simultaneously meets the following conditions: multiple low-cost distress devices can automatically form a cluster, with distress information and its termination status being propagated in a coordinated manner within the cluster, and presented to each device in a way that can be viewed directly by ordinary mobile phones without access or application, thereby expanding the coverage of distress information from a single point to a contiguous area; the propagation process can simultaneously resist broadcast storms, spam injection, message hijacking and tampering, and forged termination; message timeliness management does not rely on clock synchronization; and all of the above capabilities do not add any operational burden to the genuine distress caller. Summary of the Invention

[0007] The technical problem to be solved by this invention is: in an environment where public communication networks and mains power are unavailable, how to ensure that a distress call in one place can be safely and controllably spread to a wider surrounding area and be directly detected by ordinary mobile phones, how to ensure that the distress call cancellation status is also reliably spread to release rescue attention in a timely manner, while resisting broadcast storms, spam, message hijacking and fake cancellation, and keeping the operation of the person seeking help completely consistent with the single-player scenario.

[0008] To address the aforementioned technical problems, in a first aspect, the present invention provides a cluster-based collaborative propagation method for emergency distress information, applied to a cluster consisting of at least two emergency distress communication devices, each of which has wireless local area network (WLAN) communication capabilities, creates an open WLAN hotspot in access point mode and provides an offline message page to mobile terminals accessing via the hotspot, and, upon detecting a local distress trigger event, switches the broadcast hotspot name from a first hotspot name to a second hotspot name containing the distress information. The method includes: a device that detects a local distress trigger event, acting as the source device, generates a distress event notification. The distress event notification includes at least a source device identifier, an event sequence number maintained by the source device, distress summary information, remaining propagation hops, and a release commitment value. The release commitment value is the output value obtained by applying a one-way function to a release secret value randomly generated and confidentially stored by the source device. The source device also applies a one-way function to all fields, including at least the source device identifier, event sequence number, distress summary information, and release commitment value, to obtain an event fingerprint, and places the event fingerprint into the distress event notification. While maintaining its own hotspot access point service, the source device broadcasts the distress event notification to surrounding devices via inter-device wireless messages. These inter-device wireless messages carry a message authentication code calculated based on a cluster-shared group authentication key. Devices in the cluster that receive the distress event notification verify the message. The system generates an authentication code and recalculates the event fingerprint, comparing it with the event fingerprint carried in the notification. If either verification fails, the event is discarded. If the verification passes, the event fingerprint is used to retrieve the local event table. Existing events are not processed again, while new events are recorded in the event table. The remaining propagation hop count is decremented by one and forwarded if it is greater than zero. Simultaneously, if the local device is not in a distress state, the local hotspot name is switched to a third hotspot name containing nearby distress semantics and source location information, and the distress event is presented on the local device's offline message page. When the source device detects a release trigger event, it generates a release notification carrying the release secret value and broadcasts it. Devices receiving the release notification apply the one-way function to the release secret value. The event is set as released only if the output value matches the release commitment value recorded in the event table, and the release notification continues to propagate. If there are no other active distress events and the local device is not in distress, the hotspot name is restored to the first hotspot name.

[0009] The core concept of the above method can be understood from three levels.

[0010] The first layer is the "relay of the distress banner." In a single-device solution, the hotspot name is a "distress banner" hanging above the device, visible to any nearby mobile phone opening its wireless network list. However, this banner only covers the signal radius of a single device. This invention enables the source device that detects the distress call to announce the event via inter-device wireless messages to nearby similar devices. These nearby devices then forward the message hop-by-hop, with each receiving device switching its hotspot name to a third hotspot name carrying the source location information—essentially lighting up the distress banner along the device link. Thus, the visible range of the distress information expands from a hundred-meter radius of a single device to a contiguous area covered by the entire cluster. Ordinary mobile phones on different floors of buildings, different buildings in communities, and different nodes on mountain roads can directly see the distress call and its location in their wireless network list, without needing to connect to any network or install any applications. The third hotspot name differs from the source device's second hotspot name and carries the source location information, ensuring that nearby personnel know "someone is calling for help nearby" without mistaking the relay device's location for the actual incident.

[0011] The second aspect is the "self-verification of the right to terminate." For a distress call to propagate, the termination status must also propagate; otherwise, the cluster will remain in a distress state for an extended period, consuming rescue efforts. However, once a termination message can be arbitrarily constructed, a malicious actor can publish a forged termination message, effectively "silencing" a genuine distress call—a fatal flaw in emergency systems, and existing interconnected alarm systems suffer from this vulnerability. To address this, this invention designs a commitment-disclosure-based termination verification mechanism: When the source device issues a distress call notification, it randomly generates and secretly stores a termination secret value, only publishing the termination commitment value obtained through a one-way function operation. Upon termination, the source device publishes the termination secret value itself. Any device in the cluster can verify that "the device that issued the termination is indeed the one that initially issued the distress call" by applying the same one-way function to it and comparing it with the previously recorded commitment value. Due to the image-representational nature of the one-way function, any third party without the termination secret value—including cluster internal devices holding the group authentication key—cannot construct a termination notification that passes verification. This mechanism requires no key distribution infrastructure, no pre-pairing between devices, and verification can be completed with a single hash operation, making it perfectly compatible with the computing power of low-cost embedded devices.

[0012] The third layer is "self-discipline in propagation." The event fingerprint serves as both an integrity credential and a deduplication key: any interception and alteration of the announcement content (such as changing location or number of participants) will result in the receiver recalculating a fingerprint that does not match the fingerprint carried in the announcement, leading to the event being discarded. Regardless of the number of paths the same event takes, if the fingerprint is identical, it is only processed once. The remaining propagation hop count limits the diffusion radius. The group authentication key prevents devices outside the cluster from injecting forged messages or deciphering their content. Building upon this, further rate limiting, backoff suppression, and age expiration mechanisms (described later) collectively ensure that the cluster does not experience self-inflamed broadcast storms under high-density deployment.

[0013] Furthermore, before forwarding a distress call or cancellation notification, the device waits for a random backoff period and counts the number of notifications carrying the same event fingerprint received during the backoff period. If the number reaches a preset suppression threshold, the forwarding is canceled. Simultaneously, for distress calls that are active in the event table, a rebroadcast strategy is used to periodically rebroadcast the event with increasing time intervals up to the upper limit. The former utilizes the shared medium characteristic of wireless broadcasting—if a device has heard enough neighbors forwarding the same event during the backoff period, it means that the event has been sufficiently spread locally, and forwarding it again would only increase redundancy—thus reducing the total number of messages caused by a single event from being proportional to the square of the number of devices to approximately linear with the number of devices; random backoff also naturally staggers the forwarding of each device in time, avoiding simultaneous contention for the channel. The latter uses progressively longer intervals to achieve two goals: dense rebroadcasting in the early stage of the event, so that devices that are powered on or newly enter the coverage area can be informed as soon as possible; and sparse rebroadcasting in the later stage of the event, so as to minimize the channel resources occupied for a long time.

[0014] Furthermore, the device limits the rate of distress notifications issued by devices with the same source identifier to a preset rate cap. Notifications exceeding the cap are discarded, and the corresponding source device identifier is added to a gray list for a preset duration. During the gray list period, new distress notifications from that identifier are neither recorded in the event table nor forwarded. The device also imposes a unit-time cap on the total number of inter-device wireless messages sent by itself. When the cap is reached, messages are sent in the priority order of cancel notification, new distress notification, and periodic replay. This mechanism addresses the issue of spam: whether it's a maliciously controlled device frequently issuing spam distress notifications or a faulty device repeatedly triggering them, the impact is limited to a very low rate, and the source exceeding the cap is independently isolated by each device in the cluster—because each device independently performs rate limiting and gray list determination, there is no central node that can be compromised; and the total limit and priority ordering on the sending side ensure that even under the worst channel congestion, messages carrying "cancel" semantics (releasing rescue resources) and newly occurring distress notifications (additional rescue requests) always take precedence over routine replays and background synchronization.

[0015] Furthermore, the distress call notification includes an event age field: the source device sets this to its initial value when generating the notification; when each device forwards or replays it, the duration accumulated by the local timer during the event's local retention period is added to this field; the receiver updates the event table with the larger of the received age and the recorded age; events whose age reaches the preset lifespan limit are deemed expired, marked as invalid, no longer forwarded, and removed from the event table. Emergency devices are often shut down for extended periods and may restart at any time after a disaster, making it difficult to maintain a reliable absolute clock and impossible to synchronize network time. This invention replaces absolute timestamps with "hop-by-hop accumulated relative age," allowing each device to participate in consistent event time management across the network by relying solely on its own local timer (tick count from power-on), completely eliminating reliance on clock synchronization, real-time clock hardware, or satellite time synchronization. The age expiration mechanism also serves as a fallback for the deactivation mechanism: if the source device is damaged or runs out of power before deactivation, its distress call will be automatically deleted from the network after the lifespan limit is reached, preventing it from becoming a permanently lingering "ghost distress call."

[0016] Furthermore, wireless messages between devices are authenticated and encrypted using a group authentication key before transmission, and the message text does not appear on the wireless channel. Each device maintains a monotonically increasing message counter for its own messages and stores the messages. The receiver maintains a received counter window for each source device identifier, and messages whose counters fall within the received range are considered replays and discarded. Authentication encryption provides both confidentiality and integrity: eavesdroppers cannot intercept distress details from the air (protecting the privacy of trapped individuals and preventing information from being used for targeted attacks), injectors cannot construct legitimate messages, and any alterations by tamperers will result in authentication failure; the counter window blocks the attack path of "recording old messages and replaying them later"—for example, recording an old distress notice and replaying it after it is cleared to create a false alarm, or recording a clearing notice and replaying it during a new distress call.

[0017] Furthermore, each device holds an asymmetric key pair. The source device identifier is the public key fingerprint obtained by applying a one-way function to the source device's public key. The distress notification carries the source device's public key and the digital signature made by the source device using its private key on the event fingerprint. The recipient verifies the correspondence between the public key and the source device identifier, as well as the signature; if it fails, the notification is discarded. This mechanism forms a "self-certifying identifier": the device identifier is not an arbitrarily filled number, but a fingerprint mathematically bound to the public key. To impersonate another device's identifier, the attacker must possess the corresponding private key. Thus, even if the group authentication key is leaked on a certain device, an attacker cannot impersonate other devices in the cluster to issue distress notifications, extending the defense from the "cluster boundary" to "single-machine identity." This mechanism does not require any public key infrastructure such as a certificate authority; the public key is included with the notification, and the fingerprint serves as the identifier, consistent with the infrastructure-free premise of emergency scenarios.

[0018] Furthermore, messages related to the distress call submitted via the offline message page of any device in the cluster are identified by both the receiving device's device identifier and the message sequence number, and are synchronized within the cluster via inter-device wireless messages: each device periodically broadcasts a summary of its existing message set, and neighboring devices, after comparison, unicast requests to complete any missing messages; response messages indicating the ability to participate in the rescue are synchronized to the source device, which then displays the received rescue response on its screen and offline message page. Thus, information left by rescuers on any device in the cluster can be seen by people in other locations, and the source device near the trapped person can tell them "how many people have responded and where they are coming from"—in the dark environment of power and network outages, this feedback is irreplaceable in maintaining the trapped person's will to survive; the summary-comparison-unicast completion synchronization method excludes the large message body from broadcast flooding, coordinating with the storm prevention mechanism.

[0019] Furthermore, the third hotspot name uses distinguishable wording from the second hotspot name, and the third hotspot name also includes at least one of the following: a hop count indicating the propagation distance and an event age indicating the duration. When the device sends a distress signal, the second hotspot name takes precedence. The device drives indicator lights to signal nearby assistance in a third indication mode, distinct from the device's own distress signal mode. These presentation design elements ensure that distress information is not distorted during propagation: those who see the third hotspot name know "help is elsewhere, this is a relay," and the hop count and age indication help them judge the distance and urgency; the device's own distress signal priority ensures that the relay function never masks the device's own distress call.

[0020] Secondly, this invention provides an emergency distress communication device, comprising a housing, a controller disposed within the housing, a wireless local area network (WLAN) communication module integrated or connected to the controller, a local memory, a display screen disposed on the housing, a distress button and indicator lights, and a power module; the WLAN communication module supports a working mode where access point services and wireless message transmission and reception between devices coexist; the controller is configured to execute the steps on both the source device side and the receiving device side of the aforementioned cluster cooperative propagation method, and the event table, message records, message counter, and decryption secret value generated when the device is the source device are stored in the local memory. The decryption secret value is stored on disk to ensure that even if the device experiences a power outage and restart during a distress call, it can still issue a legitimate decryption notice after power is restored.

[0021] Thirdly, the present invention provides an emergency distress communication system, including at least two of the above-mentioned emergency distress communication devices. Each device is pre-set or configured with the same group authentication key and is deployed in a location where the wireless signal coverage areas are connected to form a cluster. When any device detects a distress triggering event, the distress event is propagated within the cluster in the above-mentioned manner, and the distress information is displayed in conjunction with the hotspot names of each device. When the distress is resolved, the resolved status is also propagated in conjunction with the event.

[0022] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) The coverage of distress information has been qualitatively expanded: distress banners are no longer limited to the signal radius of a single device, but are lit up one by one along the cluster. Ordinary mobile phones on each floor of the building and in each building of the community can directly see the distress and its source location in the wireless network list without access or application; the cancellation status is also linked across the entire network, and rescue attention is released in a timely manner.

[0023] (2) Broadcast storms and spam are systematically suppressed: event fingerprint deduplication, hop count limit and age expiration limit the propagation range and life cycle of each event; random backoff plus listening suppression reduces message redundancy from the quadratic level to approximately linear; per-source rate limiting and graylists restrain the influence of malicious or faulty sources at a very low rate and automatically isolate them; the total sending limit and the priority of "release first, help second, replay last" ensure that the most important information always goes first.

[0024] (3) Message hijacking, tampering and forgery are intercepted by multiple layers: group key authentication encryption prevents external devices from eavesdropping or injecting; message counter window disables replay; event fingerprint immediately exposes any mid-process tampering; self-certification identifier and source signature prevent internal devices from impersonating the system. The four layers of defense are independent of each other, and breaching any one layer is not enough to harm the system.

[0025] (4) Self-certification of the right to terminate, and the distress call will not be maliciously silenced: The commitment-disclosure mechanism mathematically guarantees that only the source device that issued the distress call can terminate the distress call, without the need for any key distribution infrastructure; when the source device is disabled, the age expiration mechanism will be used to clear it, and the "ghost distress call" will not remain indefinitely.

[0026] (5) Zero burden for those seeking help: The discovery, propagation, verification, synchronization and delinking of the cluster are all completed automatically. The operation of those seeking help is completely consistent with the single-machine scenario - a short press of the button or selection of "I am trapped" is to call for help, and a long press is to delink. Illiterate elderly people and panicked children do not need to understand or come into contact with any cluster concept.

[0027] (6) Not dependent on clocks and infrastructure: The event age accumulated hop by hop replaces the absolute timestamp, and the device does not require real-time clock hardware or time synchronization; the public key fingerprint is used for identification, and no certificate system is required; the group key is pre-configured at the factory and can be used. The whole mechanism operates self-consistently under the worst-case scenario of "network outage, power outage, and no infrastructure".

[0028] (7) Two-way flow of rescue information: messages are synchronized on demand within the cluster, and rescue responses are transmitted back to the source device for display. The trapped person can know that rescue forces are gathering. This psychological support has long been absent in existing emergency equipment. Attached Figure Description

[0029] Figure 1 This is a schematic diagram illustrating the cluster networking and distress information relay of the emergency rescue communication system provided in this embodiment of the invention. Figure 2 This is an overall flowchart of the cluster collaborative propagation method provided in the embodiments of the present invention; Figure 3 This is a schematic diagram of the structure of a help event notification message in an embodiment of the present invention; Figure 4 This is a signaling flowchart for the commitment release-disclosure verification in an embodiment of the present invention; Figure 5 This is a flowchart of forwarding suppression and rate limiting control in an embodiment of the present invention; Figure 6 This is a flowchart of message synchronization and rescue response feedback in an embodiment of the present invention.

[0030] Explanation of reference numerals in the attached diagram: 100-Emergency distress communication device; 100A-Source device; 100B, 100C-Relay device; 200-Mobile terminal; 300-SOS event notification; 301-Message header; 302-Source device identifier field; 303-Event sequence number field; 304-SOS summary information field; 305-Remaining propagation hop number field; 306-Event age field; 307-Cancellation commitment value field; 308-Event fingerprint field; 309-Message counter field; 310-Message authentication code field; 400-Cancellation notification; 401-Cancellation secret value field; 500-Event table. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0032] I. Structure of the Equipment Foundation and Cluster The emergency rescue communication device 100 in this embodiment includes a housing, a controller, a display screen, a rescue button, indicator lights, and a power module consisting of a battery and a charging management module. The controller is an embedded system-on-a-chip with an integrated wireless LAN communication module. In this embodiment, an ESP32-S3 development board is used. The local memory includes the controller's running memory and a non-volatile storage partition. The stand-alone functions of the device are: to create an open wireless LAN hotspot in access point mode and broadcast the first hotspot name ("Firefly Beacon - Emergency Hotspot" in this embodiment); to run domain name resolution service and web page service, resolve the domain name resolution request of the access terminal to the device's own address and return a redirect response to the network connectivity detection request, so that the access mobile terminal 200 automatically displays the device's local offline message page; to send and receive messages through the offline message page; to detect rescue trigger events (submission of rescue messages on the page or short press of the rescue button), and after triggering, to switch the hotspot name to a second hotspot name containing rescue information ("SOS - Someone is Trapped - Request for Rescue" in this embodiment). Pressing and holding the rescue button resets the device. The above-mentioned single-machine structure and function have been described in detail in the applicant's prior patent application (application number 202610985805.9, application date July 3, 2026, not yet published as of the date of this application). This embodiment follows the same structure. The improvement of this invention lies in the cluster collaboration between multiple devices, which is described in detail below.

[0033] like Figure 1 As shown, multiple emergency communication devices 100 are deployed in locations where their wireless signal coverage areas overlap—for example, elevator lobbies on different floors of the same building, unit doors of different buildings in the same community, or rest stops on the same mountain trail—forming a cluster. Each device is pre-configured or has the same group authentication key (see Section 4 for configuration details). Figure 1 The following is a minimum scenario with three devices: Device 100A is located at the incident site (source device), Device 100B is within the signal range of 100A, and Device 100C is within the signal range of 100B but outside the direct range of 100A; the distress call is initiated by 100A, forwarded by 100B to 100C, and the hotspot names of the three devices switch in tandem. Mobile terminals 200 in their vicinity can all see the distress message in the wireless network list.

[0034] II. Bearer of Wireless Messages Between Devices The prerequisite for cluster collaboration is that devices can maintain their own hotspot access point service while also directly exchanging messages with neighboring devices. This embodiment utilizes the access point mode and peer frame transmission and reception capabilities of the ESP32 series chip, and adopts a connectionless peer-to-peer communication mechanism (Espressif ESP-NOW) based on IEEE 802.11 vendor-defined action frames to carry wireless messages between devices: devices can directly send data frames of up to approximately 250 bytes to the broadcast address or the physical address of the specified peer without needing to access each other or establish a connection; this mechanism operates concurrently with the access point service, and the hotspot is not interrupted during the transmission and reception of peer frames, and the connected mobile terminals are not affected.

[0035] It should be noted that there is a co-channel constraint: peer frames can only be sent and received on the wireless channel currently in operation of the device. Therefore, the hotspots of all devices in the cluster and peer frames are uniformly fixed on the same preset channel (channel 1 in this embodiment). This constraint is implemented in this embodiment through a uniformly preset channel in the factory firmware; since the hotspots of each device are already operating on a fixed channel, this constraint does not incur any additional cost.

[0036] The message sending and receiving address strategy is as follows: Help event announcement 300, cancellation announcement 400 and message summary use broadcast frames, which are directed to all similar devices within the signal range; message requests and message data use unicast frames, which are transmitted point-to-point only between two devices that have been compared and found to be different, and do not participate in flooding.

[0037] III. Message Format like Figure 3As shown, the help request event notification 300 contains the following fields in sequence: Message header 301, containing a 2-byte protocol magic number and version number, and a 1-byte message type (0x01 indicates help request event notification, 0x02 indicates cancellation notification, 0x03 indicates message summary, 0x04 indicates message request, 0x05 indicates message data); Source device identifier field 302, 8 bytes, the value method is described in Section 4; Event sequence number field 303, 4 bytes, monotonically incremented from 0 by the source device and stored on disk; Help request summary information field 304, containing a 1-byte event type (defined in this embodiment as: 0x01 trapped and needing help, 0x02 injury and illness). The data includes: Request for Help (0x03 Fire Alarm, 0xFF Other), 1 byte for the number of people requesting help, and a location alias of up to 24 bytes (UTF-8 encoded, configured via the management page during deployment, e.g., "Elevator in Unit 2 of Building 3"; if not configured, a short hexadecimal code representing the source device identifier is used); 305 bytes for the remaining propagation hop number field (initial value 5 in this embodiment); 306 bytes for the event age field (in minutes, set to 0 for the source device); 307 bytes for the release commitment value field; 308 bytes for the event fingerprint field; 309 bytes for the message counter field; and 310 bytes for the message authentication code field. The total is approximately 105 bytes, providing ample margin within the approximately 250-byte payload limit for peer frames. When the source signature enhancement described in Section 7 is enabled, an additional 32 bytes of public key and 64 bytes of signature are added, totaling approximately 201 bytes, still within the upper limit.

[0038] The fields of the release notification 400 are basically the same as those of the help request event notification, with the following differences: the message type is 0x02; the release commitment value field 307 is not included, but is replaced by a 16-byte release secret value field 401; the event fingerprint field 308 carries the same fingerprint as the original help request event, which is used by the receiver to locate the event table entry.

[0039] IV. Cryptographic Mechanisms Group authentication key: 16-byte symmetric key, with a factory-preset unified default key to ensure interoperability between devices upon purchase; the deployer can enter a "group password" through the device management page (the configuration entry in the offline message page requires a management password to access), and the device will derive a new group authentication key from the password using a key derivation function (HKDF) based on SHA-256 and write it to disk. Devices in the same community or unit configured with the same password form an independent cluster that does not interfere with adjacent clusters.

[0040] Message Authentication and Encryption: In this embodiment, all fields except the message header are authenticated and encrypted using a group authentication key, employing the AES-128-CCM algorithm (ESP32 series chips have AES hardware acceleration). The random number is constructed by concatenating the source device identifier and the message counter, ensuring uniqueness for each frame. The authentication tag is truncated to 8 bytes as the message authentication code 310. In a simplified implementation, authentication can also be performed without encryption, i.e., HMAC-SHA256 is used to calculate the entire text and truncated to 8 bytes to be placed in the 310 field. In both methods, external devices cannot inject or tamper with the message. The authentication and encryption method also prevents eavesdroppers from obtaining the message text, protecting the location and injury privacy of the trapped individual.

[0041] Anti-replay: Each device maintains a 4-byte monotonically increasing counter for each message it sends (stored to disk and not rolled back upon restart); the receiving device maintains "highest seen counter value + 64-bit sliding bitmap window" for each source device identifier. Messages whose counter is not higher than the lower edge of the window or are marked in the bitmap are considered replays and discarded. Thus, attack paths such as recording old distress notifications and replaying them after they have been cleared to create false alarms, or recording clear notifications and replaying them during a new round of distress calls, are blocked—the latter is also intercepted by the mismatch between the clearing secret value and the new event commitment value, forming a double layer of protection.

[0042] Deactivation Promise and Deactivation Secret Value: When a device detects a local distress trigger event and needs to issue a new distress event, it generates a 16-byte deactivation secret value R using the chip's built-in true random number generator. This value is immediately written to a non-volatile storage partition for secure storage (ensuring deactivation even after a power outage and restart during the distress call period). The device then calculates the deactivation promise value C = SHA-256(R) and places C into field 307 of the notification. Upon deactivation, R itself is published via field 401 of the deactivation secret value. Any device that calculates SHA-256(R) and compares it with C stored in the event table will be able to verify that the deactivation notification originated from the same device that initially issued the distress call. The image-like property of SHA-256 guarantees that during the confidentiality of R, no third party (including devices within the cluster holding the group authentication key) can deduce R from C, thus preventing the construction of a false deactivation that passes verification.

[0043] Event fingerprint: The SHA-256 hash of the concatenated source device identifier 302, event sequence number 303, request summary information 304, and release commitment value 307 is calculated, and the first 16 bytes are extracted to obtain the event fingerprint 308. The event fingerprint serves a dual function: firstly, it acts as a unique, unified event identifier across the entire network, used for event table retrieval and deduplication; secondly, it serves as a credential for content integrity—if any hop in the forwarding path tampers with the summary information (such as altering location aliases or the number of people), the fingerprint recalculated by the receiver will not match the fingerprint carried in the announcement, the announcement will be discarded, and the tampering cannot be propagated along the link. The remaining propagation hop count 305 and event age 306 are hop-by-hop variable fields and are not included in the fingerprint calculation.

[0044] Source Signature and Self-Certification Identifier (Enhanced Implementation, corresponding to claim 6): Upon initial power-up, each device generates an Ed25519 key pair using a true random number generator and stores it on disk; the source device identifier 302 extracts the first 8 bytes of the SHA-256 hash of the public key, i.e., "public key fingerprint is the identifier." When issuing a help event announcement, the device's public key and a signature made using the private key on the event fingerprint are attached; the recipient first verifies that the hash of the attached public key matches the source device identifier, and then verifies the signature using the public key. The device records the public key of the source device identifier it encounters for the first time, and verifies consistency thereafter. Thus, the device identifier and private key are mathematically bound, and even if the group authentication key is leaked, attackers cannot impersonate the identifiers of other devices to issue events. This enhancement method does not require a certificate authority, the public key is included with the announcement, and it is suitable for applications without infrastructure requirements; the ESP32-S3 takes milliseconds to perform an Ed25519 signature verification, which is not a burden. A simplified implementation that is extremely cost-sensitive can omit this mechanism and rely solely on group keys and event fingerprints, while still providing protection against attacks from outside the cluster and tampering during the process.

[0045] Key and secret storage: The group authentication key, device private key, decryption value and message counter are all stored in the controller's non-volatile storage partition, which uses the chip's storage encryption features to prevent disassembly and reading.

[0046] V. Event List and Hot Topic Name Arbitration Each device maintains a local event table of 500 entries. Each entry includes: event fingerprint, source device identifier, event number, request summary information, event age, event status (active, deactivated, expired), remaining propagation hops, the local tick value of the last time the event was heard on the device, the planned time for the next replay, and the current replay interval. In this embodiment, the event table has a capacity of 32 entries. When full, expired entries are evicted first, followed by the oldest deactivated entry, and then the oldest active entry. The event table is saved to disk and restored after a device restart. Ages that cannot be measured based on downtime are not accumulated (a conservative approach; it's better to retain more events than to have them disappear prematurely).

[0047] The hotspot name arbitration rule follows a three-tier priority: If the local device is in distress, the second hotspot name is broadcast; if there is no distress on the local device but an active nearby distress event exists in the event table, the third hotspot name is broadcast; if multiple active events coexist, the youngest (most recently occurring) event is selected; if neither is present, the first hotspot name, "Watch," is broadcast. Any change in event status (addition, cancellation, expiration) triggers an arbitration recalculation to ensure that the hotspot name always reflects the most critical current status.

[0048] Construction rule for the third hotspot name: fixed prefix "SOS-NEARBY-HELP", followed by source location information and hop count reminder, separated by "-" for each segment. For example, device 100C presents "SOS-NEARBY-HELP-Building 3, Unit 2-2 hops". The byte length of the name complies with the upper limit of 32 bytes for the service set identifier, calculated as 3 bytes per Chinese character (UTF-8). When it is too long, the location alias is truncated successively and the hop count reminder is omitted to ensure that the name is always legal; when the creation of a name containing non-ASCII characters fails, it falls back to the preset ASCII name (such as "SOS-NEARBY-B3U2-2HOP"), and this fallback logic is the same as that of the single-device solution. The third hotspot name is clearly distinguishable from the second hotspot name ("SOS-SOMEONE TRAPPED-REQUEST RESCUE") to prevent surrounding people from mistaking the location of the relay device for the incident location.

[0049] Presentation linkage: For a device that enters the nearby help state, its indicator light is driven in the third indication mode (in this embodiment, it is a double flash with a period of 2 seconds, different from the single flash every 3 seconds in the watch state and the rapid triple flash with a period of 1.2 seconds in the local distress state); the display screen shows the nearby help list, giving the source location alias, event type, number of people in distress, event age, and hop count item by item (such as "Building 3, Unit 2·2 people trapped·about 3 minutes ago·2 hops"); the same content is presented as a system message inserted at the top of the offline message page, and the mobile terminal 200 accessing the hotspot of this device can view all active help events in the cluster.

[0050] VI. Propagation process and anti-storm control Combined with Figure 2 and Figure 5 Describe the receiving, processing, and forwarding control processes of the message.

[0051] After receiving the help event notice 300, the device executes the following steps in sequence: Step R1, perform decryption and authentication verification with the group authentication key, and discard it if it fails; Step R2, perform anti-replay verification (Section IV), and discard it if it fails; Step R3, perform per-source rate limit verification (described later in

[0060] ), discard it if it exceeds the limit and record it in the gray list; Step R4, recalculate the event fingerprint and compare it with the 308 field, and discard it if they do not match; Step R5, verify the public key fingerprint and signature when source signature enhancement is enabled, and discard it if it fails; Step R6, retrieve the event table with the fingerprint: if it is hit and the status is resolved or expired, it is not processed as a new event (and perform the tombstone response described in

[0062] ); if it is hit and the status is active, only update the event age with the larger value and refresh the most recently heard time for statistical suppression; if it is not hit, it is a new event and enters Step R7; Step R7, record it in the event table, perform hotspot name arbitration and local presentation linkage, and enter the forwarding scheduling when the remaining propagation hop count minus one is greater than zero.

[0052] Forwarding scheduling employs random backoff combined with listening suppression: the device randomly selects a backoff duration uniformly within the range of 200 milliseconds to 1500 milliseconds. During the backoff period, the number of received announcements with the same fingerprint continues to be counted. If the number reaches the suppression threshold (2 in this embodiment), the forwarding is canceled; otherwise, a forwarding frame is sent at the end of the backoff. The principle is as follows: wireless broadcasting is a shared medium, and the local device can also hear the forwarding of neighboring devices. Hearing it twice indicates that two devices in the vicinity have already completed the diffusion. The local device's third forwarding has a very small marginal contribution to coverage while the cost of channel occupancy is certain, so it is canceled. Random backoff also naturally staggers the forwarding times of neighbors with the same hop, avoiding collisions.

[0053] Active rebroadcast: For each active event in the event table, the device periodically rebroadcasts its distress event announcement according to the rebroadcast plan (carrying the event age accumulated according to the rules in Section 7 and the remaining hops from the device's perspective). The rebroadcast interval doubles each time starting from 30 seconds, up to a maximum of 600 seconds; rebroadcasting terminates when the event is resolved or expires. Rebroadcasting allows devices that are powered on midway, restarted after a disaster, or newly entered the coverage area to be aware of existing events, and the doubling of the interval ensures that long-term active events occupy only a very low channel share. Rebroadcast frames are also subject to random backoff and listening suppression constraints—if a neighbor's rebroadcast of the same event has been heard before the scheduled rebroadcast time, the device postpones its own plan.

[0054] Per-source rate limiting and graylist: The device maintains a token bucket for each source device identifier. In this embodiment, the bucket capacity is 2, and the token replenishment rate is 1 token every 30 seconds. Accepting a new distress call consumes 1 token. When tokens are insufficient, the new event is discarded, and the source device identifier is added to the graylist for 10 minutes. During the graylist period, new distress calls from this identifier will not be recorded, forwarded, or displayed (existing events already in the table are unaffected, preventing junk traffic from overwriting genuine historical distress calls). Each device independently executes the above judgment, and no central node can be compromised. During normal use, the same device can initiate a new distress call at most once every 30 seconds, which is far below the rate limiting threshold, and real users will not be mistakenly affected.

[0055] Total Sending Control and Priority: The device imposes a time limit on the number of peer frames sent by the device (30 frames per minute in this embodiment). The sending queue is ordered according to four priority levels: release announcements are the highest, followed by new help-seeking event announcements (including the first forward), periodic replays, and message synchronization messages are the lowest. When the limit is reached, high-priority messages crowd out the sending opportunities of low-priority messages, which are then postponed. This design ensures that under the worst congestion conditions, "release" (releasing rescue resources and restoring network quiet) and "new help-seeking" (new rescue requests) are always delivered first.

[0056] Tombstone Response: After an event is resolved, its entry remains in a "Resolved" state until the user's age expires. If the device receives another notification of the event's activity status (a belated copy or a malicious replay) during this period, it does not restore the event's presentation. Instead, it responds with a resolution notification carrying the retained resolution secret value, immediately informing the device that issued the belated notification that the event has been resolved. This mechanism accelerates the network-wide clearing of residual distress states and prevents "resolved distress calls from resurrecting at the network edge."

[0057] VII. Event Age and Expired Clearance The rules for accumulating event age are as follows: the age is set to 0 when the source device issues its first notification; when any device forwards or replays an event, it converts the elapsed local tick duration since the event was recorded in its local event table (or last issued) into minutes, adds it to the age field, and then issues the notification; the receiver updates the table entry with the larger of "received age" and "locally recorded age". Thus, the event age monotonically decreases along the propagation path. Although there is a slight error due to hopping-by-hopping quantization to minutes, it is perfectly adequate for "determining the age of events and performing expiration cleanup". The benefit is that the entire network does not require any form of clock synchronization, devices do not need real-time clock hardware, and there is no need for time synchronization after a restart.

[0058] Expiration Determination: Events that have reached their lifespan limit (12 hours by default in this embodiment, configurable from 1 to 24 hours via the management page) are marked as expired, stop replaying and forwarding, are no longer considered in hotspot name arbitration, and are removed from the table in the next elimination round. The expiration mechanism has two significances: First, it serves as a fallback mechanism – if the source device is damaged, buried, or runs out of power before the expiration, its distress event will be automatically cleared from the entire network after its lifespan limit, and will not permanently occupy the hotspot names and event tables of each device; second, it acts as the last line of defense against storms – any event, regardless of its nature, has only a finite lifespan, and the total number of packets in the network has a definite upper limit.

[0059] VIII. Deactivation Process Combination Figure 4 The complete release sequence is explained below. After the rescue is completed, the trapped person or rescuer presses and holds the distress button on the source device 100A (the same reset operation as the standalone solution, in this embodiment, it is a continuous press for 3000 milliseconds). Device 100A performs the following actions: exits the distress state, restores the hotspot name according to the arbitration rules; reads the release secret value R of the event from non-volatile memory, constructs a release announcement 400 (carrying the event fingerprint, release secret value R, message counter and message authentication code) and broadcasts it; to improve reliability, the release announcement is retransmitted three times at 2 seconds, 8 seconds and 30 seconds, and then stops.

[0060] Upon receiving a release notification, each device in the cluster performs the same authentication and replay protection checks as the distress notification; it locates the event table entry using the event fingerprint, calculates the SHA-256(R) and compares it with the release commitment value C stored in the entry—if they match, the event is marked as released, hotspot name arbitration is performed (if there are no other active events and the device has not requested help, the first hotspot name is restored), the display and indicator lights are updated, a system message "This distress request has been released" is inserted into the message page, and the release notification continues to be forwarded according to the backoff suppression rules in Section 6; if they do not match, the notification is discarded, and the device's state remains unchanged. Forged release notifications cannot provide a correct R and will fail the comparison on every device in the network, ensuring that genuine distress requests are not maliciously silenced.

[0061] If device 100A experiences a power outage and restart during a distress call, the decryption secret value R and the event sequence number have already been written to disk. They can be read back after the restart, and the decryption capability will not be lost. If 100A becomes completely disabled and cannot be decrypted, the event will be automatically cleared from the entire network after the lifespan limit according to the age expiration mechanism in Section 7.

[0062] IX. Message synchronization and rescue response feedback Combination Figure 6 Note: Each message within the cluster is uniquely identified by a tuple of (receiving device identifier, message sequence number). The receiving device is the device that the message was submitted to, and the message sequence number is monotonically incremented by the receiving device. During a help request event, messages submitted via any device's offline message page are associated with the latest event and participate in cluster synchronization by default; messages submitted when there is no event are only stored locally and do not occupy cluster channels.

[0063] Synchronization employs a three-step process: digest-comparison-completion. During active events, each device broadcasts a message digest frame (message type 0x03) every 60 seconds. The content is a version vector of the messages already stored on the device—a mapping table of "device identifier → highest message sequence number stored on this device," with a maximum of 10 entries. After receiving the digest, the neighbor compares it with its local message database. If a missing interval is found, it requests the message from the digest publisher via unicast message request (0x04). The publisher then resends the message data frame (0x05) one message at a time, with each message exceeding 120 bytes in length and truncated. All synchronization messages are sent with the lowest priority as specified in Section 6, and the message body is unicast only between the two devices without flooding, thus aligning with the channel occupancy and storm prevention objectives.

[0064] Rescue response feedback: When the existing "I can help" preset control on the message page is clicked, the generated response messages are marked with high synchronization priority and propagate to the cluster via the synchronization mechanism, reaching the source device 100A. 100A displays "Rescue Responses: N" and the alias of the source location of the most recent response on its screen, and also presents the same information at the top of the message page. The trapped person thus learns that rescue forces are gathering and arriving from where. The number of response messages on the source device is only counted and the latest entry is displayed; they are not displayed one by one to avoid interference.

[0065] 10. User Operation Perspective and Ease of Use From the user's perspective: The operation is completely consistent with the standalone solution—users with mobile phones connect to the hotspot and select "I'm trapped" on the automatically pop-up page; users without mobile phones briefly press the SOS button on their device; to disconnect, long press the same button on the source device. The cluster's event generation, commitment value calculation, announcement broadcasting, hop-by-hop forwarding, verification and deduplication, hotspot name linkage, message synchronization, and disconnection propagation are all completed automatically. Users do not need to know about the cluster's existence or perform any additional operations or selections. The ease of use for panicked individuals, the elderly, children, and the injured is exactly the same as the standalone solution.

[0066] From the deployer's perspective: The device comes pre-installed with a default group key and fixed channel, and multiple devices can automatically communicate with each other upon power-up, making it "networked out of the box"; Deployers with the necessary resources can configure location aliases for each device through the management page (so that the distress banner carries the precise location) and uniformly set group passwords (so that the community cluster is isolated from the outside world), all of which are one-time configurations.

[0067] From the perspective of those in the vicinity: No operation is required - simply open the list of wireless networks on your mobile phone to see "SOS - Someone is trapped - Request for rescue" or "SOS - Nearby assistance - Building 3, Unit 2 - Jump 2"; connecting to any device's hotspot will automatically pop up a message page, showing all active requests for help and messages within the cluster. Clicking "I can rescue" will allow the trapped person to receive a response.

[0068] XI. Other Implementation Methods and Variations The carrier of wireless messages between devices is not limited to vendor-defined action frame mechanisms. In other implementations, distress event announcements can be encoded into vendor-defined information elements of hotspot beacon frames and continuously broadcast with the beacon. Nearby devices receive these messages through periodic channel scanning, requiring no additional protocol support from the receiver. Alternatively, WiFi Aware can be used as the carrier. Furthermore, devices can take turns accessing nearby device hotspots in a station mode, exchanging events and messages via a Hypertext Transfer Protocol interface. This method offers higher throughput but slightly lower real-time performance. These carrier methods can be used in combination.

[0069] The controller is not limited to the ESP32-S3; any embedded system-on-a-chip with integrated wireless LAN capabilities that supports access point services and peer-to-peer frames (or supports access points and sites) can implement this method. The hash function can use SM3 instead of SHA-256, the signature algorithm can use SM2 instead of Ed25519, and the authentication encryption can use ChaCha20-Poly1305 instead of AES-128-CCM to adapt to different algorithm compliance requirements; the lengths of the decryption secret value and the commitment value can be adjusted according to security requirements.

[0070] Simplified relay nodes can be added to the cluster: omitting the display screen and buttons, retaining only the controller, indicator lights and power module, dedicated to forwarding and relaying hotspot names, used in locations such as corridors and streetlight poles where only extended coverage is needed, further reducing deployment costs; these nodes also perform all the steps on the receiving device side of this method.

[0071] In an extended implementation, one or more devices in the cluster can be equipped with a long-range radio module (such as LoRa) as a cross-cluster gateway to bridge distress event notifications from this cluster to another cluster or rescue command node several kilometers away for transmission; the bridging message uses the event fingerprint, release commitment value and age field of this method, and the verification and release mechanism remains consistent across media.

[0072] Each implementation parameter (initial hop count, backoff interval, suppression threshold, replay interval and upper limit, token bucket parameters, gray list duration, total sending limit, event lifespan limit, message summary period, etc.) can be configured within a reasonable range according to deployment density and scenario. The values ​​given in this manual are default values ​​after design trade-offs and do not constitute a limitation on the scope of protection.

[0073] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cluster-based collaborative propagation method for emergency distress information, applied to a cluster consisting of at least two emergency distress communication devices, each device having wireless local area network (WLAN) communication capabilities, creating an open WLAN hotspot in access point mode and providing an offline message page to mobile terminals accessing via the hotspot, and, upon detecting a local distress trigger event, switching the broadcast hotspot name from a first hotspot name to a second hotspot name containing the distress information, characterized in that... The method includes: The device that detects the local distress call trigger event acts as the source device and generates a distress event notification. The distress event notification includes at least a source device identifier, an event sequence number maintained by the source device, distress summary information, remaining propagation hops, and a release commitment value. The release commitment value is the output value obtained by applying a one-way function to a release secret value randomly generated and kept confidential by the source device. The source device also applies a one-way function to all fields including at least the source device identifier, the event sequence number, the distress summary information, and the release commitment value to obtain an event fingerprint, and places the event fingerprint into the distress event notification. While maintaining its own hotspot access point service, the source device broadcasts the distress call notification to the surrounding area via inter-device wireless messages. The inter-device wireless messages carry a message authentication code calculated based on the cluster-shared group authentication key. The device receiving the distress event notification in the cluster verifies the message authentication code and recalculates the event fingerprint in the same way as the source device, comparing it with the event fingerprint carried in the notification. If any verification fails, the notification is discarded. If the verification passes, the event fingerprint is used to retrieve the local event table. If the event already exists, it is not processed again. If the event is a new event, it is recorded in the local event table. The remaining propagation hop count is decremented by one, and the distress event notification is forwarded if the remaining propagation hop count after decrementing is greater than zero. If the local device is not in a distress state, the hotspot name broadcast by the local device is switched to a third hotspot name. The third hotspot name contains the semantics of nearby distress and the source location information taken from the distress summary information. The distress event is then presented on the local device's offline message page. When the source device detects a release trigger event for the distress call event, it generates a release notification carrying the release secret value and broadcasts it to the surrounding area. Devices in the cluster that receive the release notification apply the one-way function to the release secret value carried in the notification. Only when the output value matches the release commitment value of the event recorded in the local event table will the event be set to a released state. The release notification will continue to be propagated according to the same rules as forwarding distress call event notifications. When there are no other active distress call events on the local machine and the local machine is not in a distress call state, the hotspot name broadcast by the local machine will be restored to the first hotspot name.

2. The cluster collaborative propagation method according to claim 1, characterized in that, Before forwarding the help request event notification or the cancellation notification, the device waits for a random backoff period and counts the number of notifications with the same event fingerprint received within the random backoff period. When the number of notifications reaches a preset suppression threshold, the forwarding is canceled. The device also periodically rebroadcasts the help request event notification for active help requests in the local event table using a rebroadcast strategy that increases the time interval sequentially until a preset upper limit is reached, so that devices that subsequently enter the cluster coverage area or are powered on midway are aware of the event.

3. The cluster cooperative propagation method according to claim 1 or 2, characterized in that, The device limits the rate of distress event announcements issued by the same source device identifier to a preset rate limit. Announcements exceeding the rate limit are discarded, and the corresponding source device identifier is added to a gray list for a preset duration. During the gray list period, new distress event announcements from the same source device identifier are not recorded in the event table or forwarded. The device also imposes a unit time limit on the number of inter-device wireless messages sent by the device itself, and when the limit is reached, it sends messages in a priority order of canceling announcements over new distress event announcements, and new distress event announcements over periodic replays.

4. The cluster collaborative propagation method according to claim 1, characterized in that, The distress event notification also includes an event age field. When the source device generates the notification, it sets the event age field to an initial value. When each device forwards or rebroadcasts the notification, it adds the duration accumulated by the local timer during the event's retention period to the event age field. The receiving device updates the event table with the larger of the received event age and the event age already recorded in the local event table, replacing the absolute timestamp that depends on clock synchronization with the event age accumulated hop by hop. Help requests that have reached the preset lifespan limit are deemed expired. Expired help requests are marked as invalid, will no longer be forwarded, and will be removed from the event table.

5. The cluster collaborative propagation method according to claim 1, characterized in that, The wireless messages between devices are transmitted after being authenticated and encrypted using the group authentication key. Each device maintains a monotonically increasing message counter for the wireless messages between devices it sends and places the message counter into the message. The receiving device maintains a received counter window for each source device identifier. Messages whose message counters fall within the received range are identified as replay messages and discarded.

6. The cluster collaborative propagation method according to claim 1, characterized in that, Each device holds an asymmetric key pair, and the source device identifier is a public key fingerprint obtained by applying a one-way function to the public key of the source device. The help event notification also carries the public key of the source device and a digital signature made by the source device with its private key on the event fingerprint. The receiving device verifies the correspondence between the public key carried and the source device identifier, as well as the digital signature. Notifications that fail the verification are discarded, so that the device holding the group authentication key cannot impersonate the identifier of other devices to issue help events.

7. The cluster cooperative propagation method according to claim 1, characterized in that, Messages related to a request for help submitted via the offline message page of any device in the cluster are identified by both the device identifier of the device receiving the message and the message sequence number, and are synchronized within the cluster via inter-device wireless messages. Each device periodically broadcasts a summary of its existing message set. Neighboring devices compare the summary information with their existing messages and then request and retrieve any missing messages via inter-device wireless messages. Response messages indicating the ability to participate in rescue efforts are synchronized to the source device, which displays the received rescue response at least once on its screen and offline message page to provide feedback on the rescue response status to the person requesting help.

8. The cluster collaborative propagation method according to claim 1, characterized in that, The third hotspot name uses distinguishable wording from the second hotspot name, and the third hotspot name also includes at least one of the following: hop count information reflecting the propagation distance of the distress call and event age information reflecting the duration of the distress call, so as to avoid surrounding people mistaking the location of the relay device for the location of the distress call; when a distress call trigger event occurs on the device itself, the second hotspot name takes precedence over the third hotspot name; the device also drives its indicator light in a third indication mode that is different from the local distress call status indication mode to indicate the presence of a nearby distress call event.

9. An emergency distress communication device, comprising a housing, a controller disposed within the housing, a wireless local area network communication module integrated or connected to the controller and a local memory, a display screen disposed on the housing, a distress button and indicator lights, and a power supply module for supplying power to the device, characterized in that, The wireless LAN communication module supports a working mode in which access point services and devices can simultaneously transmit and receive wireless messages; the controller is configured to execute the steps on the source device side and the steps on the receiving device side in the cluster cooperative propagation method according to any one of claims 1 to 8, and the local event table, message records, message counter, and decryption value generated when the local device is the source device are stored in the local memory.

10. An emergency distress communication system, characterized in that, The device includes at least two emergency distress communication devices as described in claim 9, each device having the same group authentication key pre-set or configured, and deployed at locations where the wireless signal coverage areas are interconnected to form a cluster; when any device in the cluster detects a distress trigger event, the corresponding distress event is propagated within the cluster according to the method described in claim 1, causing the hotspot names broadcast by each device in the cluster to display distress information in a linked manner, and when the distress event is canceled, the canceled status is propagated within the cluster in a linked manner according to the method described in claim 1.

Images