Emergency communication method and electronic device

Abstract

Embodiments of the present application provide an emergency communication method and an electronic device. The method comprises: receiving a trigger instruction of a user equipment in a network-free communication mode; in response to the trigger instruction, starting Bluetooth broadcasting to discover a target terminal and establishing a communication connection with the target terminal in a no-confirmation pairing mode; collecting multi-modal emergency data corresponding to the mode type according to the trigger instruction; obtaining the data volume of the multi-modal emergency data and estimating the communication distance between the target terminal; and based on the data volume and the communication distance, adaptively selecting a target transmission channel from multiple transmission channels to send the multi-modal emergency data to the target terminal based on the target transmission channel. The present scheme is simple to operate, does not require the user to configure parameters and perform tedious operations, and has extremely low operation complexity. The workflow can achieve high automation control without manual intervention. The communication channel selection is adaptive and more reasonable, achieving an optimal balance between transmission efficiency and reliability.

Description

Technical Field

[0001] This application relates to the field of wireless communication and emergency support technology, and in particular to an emergency communication method and electronic device. Background Technology

[0002] With the rise of outdoor sports and adventure tourism, and the frequent occurrence of sudden natural disasters (such as earthquakes and floods), the emergency communication capabilities of mobile terminals in extreme environments without cellular network signals or fixed WiFi (Wireless Fidelity) coverage have become a crucial cornerstone for ensuring public safety and improving rescue efficiency. In scenarios such as forests, mountains, or disaster ruins, the ability to establish a timely and effective information link between trapped individuals and rescuers directly determines the golden window of rescue operations, possessing extremely high social safety value.

[0003] Currently, existing technologies primarily attempt to address the problem of communication without a network by manually configuring Wi-Fi hotspots, enabling low-speed Bluetooth broadcasting, or using dedicated data transmission equipment. However, in practical applications, these methods face a core bottleneck: due to the specific nature of emergency scenarios, existing technologies often require users to perform cumbersome network configurations and parameter selections, and the transmitted information is relatively limited in format (usually only text or simple coordinates). For emergency search and rescue operations that urgently require "multimodal data" such as location information, real-time on-site voice, or environmental images, existing technologies struggle to balance the immediacy of operation with the effectiveness of data transmission. Users under high anxiety or with limited operational capacity find it difficult to quickly and automatically transmit multi-dimensional distress signals using existing technologies.

[0004] In summary, in order to overcome the shortcomings of existing technologies, such as high operational threshold in offline environments and difficulty in automating multi-dimensional data transmission, a better multimodal emergency communication method is urgently needed. Summary of the Invention

[0005] In view of this, embodiments of this application provide an emergency communication method and electronic device to at least partially solve the above-mentioned problems.

[0006] In a first aspect, embodiments of this application provide an emergency communication method applied to a user equipment, the method comprising: Receive trigger commands for offline communication mode; In response to the trigger command, Bluetooth broadcasting is initiated to discover the target terminal and establish a communication connection with the target terminal without confirmation pairing. Based on the mode type corresponding to the trigger command, collect the corresponding multimodal emergency data; The data volume of the multimodal emergency data is obtained, and the communication distance with the target terminal is estimated. Based on the data volume and the communication distance, a target transmission channel is adaptively selected from multiple transmission channels to send the multimodal emergency data to the target terminal via the target transmission channel.

[0007] Secondly, based on the emergency communication method described in the first aspect of this application, embodiments of this application also provide an emergency communication device, including: The trigger module is used to receive trigger commands in offline communication mode; The pairing module is used to respond to the trigger command, start Bluetooth broadcast to discover the target terminal, and establish a communication connection with the target terminal without confirmation of pairing. The data acquisition module is used to acquire corresponding multimodal emergency data according to the mode type corresponding to the trigger command; The calculation module is used to acquire the data volume of the multimodal emergency data and estimate the communication distance with the target terminal; The transmission module is used to adaptively select a target transmission channel from multiple transmission channels based on the data volume and the communication distance, so as to send the multimodal emergency data to the target terminal based on the target transmission channel.

[0008] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, perform any of the emergency communication methods described in the first aspect of embodiments of this application.

[0009] Fourthly, embodiments of this application also provide an electronic device, including: One or more processors, communication interfaces, memory, and communication buses; the processors, memory, and communication interfaces communicate with each other via the communication bus; the memory is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement any of the emergency communication methods described in the first aspect of this application.

[0010] This application provides an emergency communication method and electronic device. It receives a trigger command from a user device in a network-free communication mode; in response to the trigger command, it initiates Bluetooth broadcasting to discover a target terminal and establishes a communication connection with the target terminal without confirmation pairing; based on the mode type corresponding to the trigger command, it collects corresponding multimodal emergency data; it obtains the data volume of the multimodal emergency data and estimates the communication distance with the target terminal; based on the data volume and communication distance, it adaptively selects a target transmission channel from multiple transmission channels to send the multimodal emergency data to the target terminal. This emergency communication method for emergency rescue in a network-free environment is simple to operate, requires no parameter configuration or cumbersome operations from the user, and has extremely low operational complexity. Furthermore, the entire workflow can achieve a high degree of automated control, completing core operations without manual intervention. The adaptive and more reasonable selection of the communication channel achieves an optimal balance between transmission efficiency and reliability. It offers excellent communication reliability and resource utilization, resulting in a good user experience. Attached Figure Description

[0011] 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 only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0012] Figure 1 A schematic diagram illustrating the workflow of an emergency communication method provided in this application embodiment; Figure 2 A schematic diagram illustrating the workflow of another emergency communication method provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an emergency communication device provided in an embodiment of this application; Figure 4 This is a schematic diagram of another emergency communication device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0014] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0015] Example 1 This application provides an emergency communication method applied to user equipment, the method as follows: Figure 1 As shown, Figure 1 This application provides a schematic diagram illustrating the workflow of an emergency communication method according to an embodiment, including: Step S101: Receive the trigger command for offline communication mode.

[0016] In the practical application scenarios of this embodiment, users can trigger a preset offline communication mode with a single click using the physical shortcut key or on-screen shortcut on their terminal device. For example, when lost outdoors, if a user finds the current communication signal weak or there is no network support for communication, the user can trigger the device to start emergency rescue operations by pressing and holding the volume up / down button on the device for 3 seconds. This one-click activation method simplifies the user operation process, improves the activation efficiency of the emergency communication method in this embodiment, and enhances the user experience.

[0017] Specifically, in some optional implementations of this embodiment, the offline communication mode includes at least a personal distress mode, a companion interconnection mode, and an emergency broadcast mode. Correspondingly, the aforementioned receiving of the trigger command for the offline communication mode specifically includes: monitoring interrupt requests from the underlying hardware of the user device or touch commands from the application layer; and generating a trigger command of the corresponding mode type when a continuous change in the state of the user device's physical shortcut key is detected or a specific touch command is received on the screen. Specifically, a continuous change in the state of the physical shortcut key can mean that the physical shortcut key is pressed and held for more than a preset duration. This embodiment of the application, by presetting the above three distress modes, can cover most practical application scenarios that require the activation of the emergency distress method of this embodiment. For example, when a user encounters danger outdoors, the user can trigger the device to activate the personal emergency rescue mode by pressing and holding the volume up / down button on the device for 3 seconds. During group travel, the user can trigger the companion interconnection mode by clicking the offline interconnection icon on the screen; in the event of a sudden disaster, the user can trigger the emergency broadcast mode for rescue by pressing the power button 5 times consecutively. With these three pre-configured modes, users no longer need to manually configure parameters, further simplifying the operation process. This allows even the elderly and children to trigger the system blindly in a state of sudden panic, solving the problem of cumbersome and overly complex procedures in traditional emergency functions. Furthermore, users can quickly and efficiently activate the corresponding emergency distress mode based on their environment's emergency communication needs, improving user experience and safety.

[0018] Step S102: In response to the trigger command, start Bluetooth broadcasting to discover the target terminal and establish a communication connection with the target terminal without confirmation pairing.

[0019] In the practical application scenario of this embodiment, traditional Bluetooth broadcasting requires multiple steps of interaction, such as searching, selecting, pairing, and confirming. This solution, however, is limited to responding to a trigger command, automatically discovering and connecting, eliminating the cumbersome operations of traditional Bluetooth pairing, passwords, and connection confirmation. This enables rapid connection and communication in emergency scenarios, significantly reducing connection latency. It ensures that even in tense, panicked, or injured states, users can discover and establish communication with nearby available target terminals with just a single trigger, guaranteeing that rescue information is automatically sent without user intervention, thus improving the success rate and timeliness of distress calls.

[0020] Optionally, in the actual application scenario of this embodiment, the Bluetooth module supporting the Bluetooth broadcast is a low-power Bluetooth module. Its standby power consumption and broadcast power consumption are much lower than those of traditional Bluetooth and Wi-Fi. It can still broadcast distress signals for a long time when the mobile phone has low battery or insufficient emergency battery life, avoiding the interruption of distress due to power depletion. Moreover, almost all smartphones and wearable devices have built-in low-power Bluetooth modules, such as BLE (Bluetooth Low Energy module) modules, without the need for additional dedicated hardware, which is conducive to widespread adoption and emergency mutual assistance, thereby increasing the probability of discovering available target terminals.

[0021] Optionally, in some practical application scenarios of this embodiment, in response to a trigger command, Bluetooth broadcasting is initiated to discover nearby communicable target terminals and establish an unconfirmed pairing communication connection with the target terminals. This includes: writing the user equipment's device identifier and compatible protocol version field information into the broadcast payload of the Bluetooth broadcast signal and broadcasting it to identify nearby communicable target terminals; receiving Bluetooth response signals from nearby target terminals, extracting the peer's compatible protocol version field carried in the Bluetooth response signal, inputting the peer's compatible protocol version field into the protocol conversion middleware built into the user equipment, and having the protocol conversion middleware match the corresponding heterogeneous operating system instruction mapping rules according to the peer's compatible protocol version field; converting the user equipment's communication handshake commands into a universal format handshake command recognizable by the target terminal based on the heterogeneous operating system instruction mapping rules; and completing pairing with the target terminal at the link layer based on the universal format handshake command to skip system-level pairing confirmation authorization and establish an unconfirmed two-way communication connection.

[0022] This embodiment illustrates the process of establishing a communication connection as described above: After receiving the user's trigger command to initiate the emergency communication method, the device starts Bluetooth broadcasting. Two types of key information can be written into the preset fields of the broadcast payload (these preset fields are dedicated to emergency communication, distinct from the general fields of regular Bluetooth broadcasting, to avoid mismatch with non-emergency terminals). First, the user device's device identifier, a unique and identifiable identifier, can be encrypted using a simplified form of the device's MAC (Medium Access Control) address, ensuring device uniqueness while preventing user privacy leaks. Second, the user device's compatible protocol version field, which identifies the emergency communication protocol version supported by the user device, such as version V1.0, and includes core parameters such as broadcast format, handshake command specifications, and data transmission protocol, ensuring protocol compatibility with surrounding target terminals. After these configurations are completed, the user device controls the Bluetooth module to broadcast the Bluetooth signal at a preset period (e.g., 500ms, balancing broadcast coverage and power consumption control to adapt to the low-power characteristics of Bluetooth Low Energy), continuously scanning for surrounding target terminals that can receive the broadcast signal and support emergency communication. The target terminals include smartphones, emergency rescue terminals, wearable emergency devices, and other user devices with built-in low-power Bluetooth modules that support the corresponding emergency protocols. After capturing the broadcast signal, the target terminal parses the device identifier and compatible protocol version fields in the broadcast payload. It then verifies the broadcast signal as an emergency distress broadcast using a preset emergency protocol identifier field. Once it confirms that it supports the corresponding type of emergency communication, it sends a Bluetooth response signal back to the user device without requiring manual intervention from the user. This Bluetooth response signal carries core information about the target terminal, most notably the peer-to-peer compatible protocol version field (i.e., the emergency communication protocol version supported by the target terminal, such as V1.0 or V1.1), and a simplified device identifier for the user device to distinguish between multiple target terminals. Furthermore, during the broadcast, the user device's Bluetooth module simultaneously activates its response signal receiving channel to receive Bluetooth response signals from nearby target terminals in real time. After receiving the feedback signal from the target terminal, the user device parses the feedback response signal, extracts the peer-to-peer compatible protocol version field, and automatically inputs this field into the user device's built-in protocol conversion middleware layer. The protocol converts the middleware layer into a dedicated middleware for emergency communication. It pre-stores instruction mapping rules corresponding to various heterogeneous operating systems (such as Android, iOS, HarmonyOS, and customized operating systems for emergency terminals). These mapping rules are preset based on the parsing specifications and format requirements of different operating systems for Bluetooth link layer handshake instructions. Its function is to achieve handshake instruction compatibility between terminals with different operating systems, solve the communication adaptation problem of heterogeneous terminals, and avoid pairing failures or connection delays caused by differences in operating systems.After receiving the peer's compatible protocol version field, the protocol conversion middleware first verifies this field to determine whether the target terminal's protocol version is compatible with the user device's protocol version. For target terminals determined to be compatible, the protocol conversion middleware matches the extracted peer's compatible protocol version field with the corresponding heterogeneous operating system instruction mapping rules (for example, if the target terminal is an Android system with protocol version V1.0, it matches the handshake instruction mapping rules corresponding to Android system V1.0; if the target terminal is an iOS system with protocol version V1.1, it matches the handshake instruction mapping rules corresponding to iOS system V1.1). Based on the matched heterogeneous operating system instruction mapping rules, the protocol conversion middleware performs format conversion on the original communication handshake instructions generated by the user device. The original handshake command is a link-layer pairing command generated by the user device based on its own operating system (such as Android). It contains core elements such as connection request, identity verification, and communication parameter configuration. However, this original command can only be recognized by terminals with the same operating system and protocol version. Through command mapping rules, this original handshake command is converted into a universal format handshake command that the target terminal can recognize. This universal format handshake command conforms to the general communication specifications of the Bluetooth Low Energy link layer and adapts to the target terminal's operating system parsing requirements, ensuring that the target terminal can quickly recognize the content of the handshake command without additional command conversion. After the handshake command format conversion is completed, the user device controls the Bluetooth Low Energy module to quickly switch to connection mode and sends the converted universal format handshake command to the target terminal. After receiving the universal format handshake command, the target terminal does not need to go through system-level pairing confirmation authorization (i.e., no pairing confirmation pop-up, no need for the user to manually enter the pairing code, no need for the user to click the "confirm pairing" button), and directly completes the pairing verification at the Bluetooth link layer. The link layer verification only verifies the legality of the handshake command, protocol compatibility, and device identifier validity. After the verification is passed, an unacknowledged two-way communication connection is immediately established between the user device and the target terminal. In this embodiment, by taking the above steps and combining the low power consumption and fast mode switching characteristics of the Bluetooth module, the problem of no public network communication in emergency scenarios is solved. Furthermore, through the adaptation role of the protocol conversion intermediate layer, a pairing connection between heterogeneous terminals without confirmation is achieved. This skips the pairing confirmation step at the system level, significantly shortens the connection latency, and ensures the compatibility and reliability of the connection. It fully meets the core requirements of rapid connection and continuous transmission in emergency rescue scenarios, avoids distress interruptions caused by cumbersome pairing, protocol incompatibility, and excessive power consumption, and improves the efficiency and success rate of emergency rescue.

[0023] Furthermore, in the actual application scenario of this embodiment, there can be multiple target terminals. That is, if there are multiple communicable target terminals around the user device, the above process can be executed in parallel, that is, communication connections without confirmation pairing are established with multiple target terminals at the same time, so as to expand the coverage of rescue information and increase the probability of the user being rescued through the method of this embodiment.

[0024] Step S103: Collect the corresponding multimodal emergency data according to the mode type corresponding to the trigger command.

[0025] In this embodiment, this stage collects corresponding multimodal data for different mode types to ensure accurate matching of emergency information collection with the current distress scenario, avoiding irrelevant data collection and transmission, and improving emergency response efficiency. For example, by configuring appropriate location, physiological, environmental, and status data for modes such as personal distress calls, companion communication, and emergency broadcasting, data transmission can be completed quickly under Bluetooth transmission conditions. Through the technical limitations of this step, data redundancy that needs to be transmitted is reduced, communication power consumption is lowered, and transmission stability and real-time performance are improved. The collected multimodal data can also provide rescuers with targeted, multi-dimensional on-site information, facilitating rapid assessment of the danger and formulation of rescue strategies, significantly improving the success rate of distress calls and the reliability of emergency rescue in offline environments.

[0026] Optionally, in some embodiments of this application, according to the mode type corresponding to the trigger command, corresponding multimodal emergency data is collected, including: if the mode type is a personal distress mode, the user device is silently invoked to collect target data, wherein the target data includes: real-time location information, voice information of a preset duration, and environmental image information, and the target data is associated and encapsulated into a distress data packet. This embodiment limits this optional implementation method, that is, when the emergency mode triggered by the user is a personal distress mode, the user device responds to the command and silently invokes the device sensors and other collection modules without pop-ups, prompts, or interference with the user to obtain the user's real-time location information, voice information of a preset duration, and environmental image information, and uniformly associates and encapsulates the above data into a structured distress data packet. This is to avoid the user being in a tense, injured, or unable to perform complex operations in emergency scenarios, by automatically obtaining key on-site information in the emergency distress situation without manual input or selection, providing a complete basis for rescue. At the same time, the silent collection method avoids the prompt interface from distracting the user's attention or revealing the distress behavior. This technical implementation step of quickly completing the collection of multi-dimensional information of location, voice, and image significantly shortens the emergency response time. Furthermore, the collected multimodal data can corroborate each other, accurately reflecting the user's location, the on-site environment, and the state of distress, significantly improving rescue efficiency. The unified data encapsulation facilitates rapid transmission via Bluetooth Low Energy, adapting to emergency communication scenarios without a network, thereby further enhancing the success rate and reliability of distress calls.

[0027] Step S104: Obtain the data volume of multimodal emergency data and estimate the communication distance with the target terminal.

[0028] This embodiment further defines the scenario in a network-free emergency situation by using the size of the multimodal emergency data and the communication distance between devices as the basis for transmitting emergency communication distress signals. This avoids transmission failures, excessive power consumption, or distress signal interruptions due to excessively large data volumes or long distances, ensuring stable and efficient delivery of emergency data. For example, when a user device triggers a personal distress signal mode and is far from the target terminal, the system assesses the data volume and communication distance, prioritizing the transmission of a simplified location data packet to ensure reachability over long distances. Once the target terminal approaches, larger data packets such as voice and environmental images are then transmitted, ensuring accessibility while fully uploading multimodal emergency information, significantly improving rescue efficiency. Of course, this embodiment only exemplifies the use of data volume and communication distance. This embodiment only introduces data volume and communication distance as the basis for the next step, aiming to ensure the simplest, fastest, and most reliable strategy in emergency scenarios. Introducing more dimensions such as signal strength, battery level, bandwidth, and channel quality as criteria would significantly increase computational complexity and decision-making latency, potentially leading to delays or errors in decision-making during emergencies. This contradicts the fundamental requirement of emergency communication: "one-click triggering and ultra-fast transmission." Using only data volume and distance as dimensions results in low computational cost, fast decision-making speed, easy hardware implementation, and strong robustness. It can quickly determine the optimal transmission strategy in network-free and low-power Bluetooth scenarios, simplifying system logic while ensuring stable, efficient, and reliable delivery of emergency data.

[0029] Step S105: Based on data volume and communication distance, adaptively select the target transmission channel from multiple transmission channels to send multimodal emergency data to the target terminal based on the target transmission channel.

[0030] This approach aims to achieve an optimal balance between transmission efficiency, communication reliability, and device power consumption in network-free emergency scenarios. In the practical application scenario of this embodiment, data volume determines the bandwidth and duration required for transmission, while communication distance determines signal coverage and link stability. Both factors jointly determine which channel is most suitable for the current emergency communication. To ensure priority delivery, broadcast channels are selected when the distance is long and the data volume is small, ensuring that distress messages are delivered. When the distance is short and the data volume is large, high-speed connection channels can be used to quickly and completely transmit multimodal data such as location, voice, and images. For example, a BLE high-speed connection channel can be enabled to control the user device to switch from Bluetooth Low Energy to broadcast mode and then to a dedicated connection link, improving communication speed and bandwidth for larger data transmissions such as voice and images. When the distance is relatively short, a BLE private link can be established without confirmation and with rapid pairing to send multimodal emergency data, thereby improving transmission speed.

[0031] See Figure 2 Optionally, in some embodiments of this application, step S105: adaptively selecting a target transmission channel from multiple transmission channels based on data volume and communication distance, so as to send multimodal emergency data to the target terminal based on the target transmission channel, specifically includes: Step S1051: If the data volume is less than the preset volume threshold and the communication distance is less than the preset first distance threshold, select the Bluetooth transmission channel as the target transmission channel, and send the multimodal emergency data to the target terminal based on the target transmission channel. Step S1052: If the data volume is greater than or equal to the preset volume threshold and the communication distance is less than the preset second distance threshold, use the paired Bluetooth link to exchange keys and directly establish a direct wireless LAN transmission channel as the target transmission channel, and send the multimodal emergency data to the target terminal based on the target transmission channel. Among them, the preset second distance threshold is greater than the preset first distance threshold.

[0032] This embodiment exemplarily illustrates the above steps: a preset volume threshold (e.g., 100KB), a preset first distance threshold (15 meters), and a preset second distance threshold (50 meters) are pre-set, with the second distance threshold being greater than the first distance threshold; after the user equipment acquires the amount of multimodal emergency data and the communication distance with the target terminal, it adaptively selects the target transmission channel according to the following rules: If the data volume is less than the preset volume threshold (such as small volume information like text, location, and short voice messages) and the communication distance is less than the preset first distance threshold (≤15 meters), then the Bluetooth transmission channel will be selected first, and low-power Bluetooth transmission will be used to achieve low power consumption and fast connection. If the data volume is greater than or equal to the preset volume threshold (such as large data such as pictures, long voice messages, and files), and the communication distance calculated by the Bluetooth link is less than the preset second distance threshold (between 15 and 50 meters), then the established unconfirmed pairing Bluetooth link will be used to exchange keys and a direct wireless LAN transmission channel (simplified WiFi direct connection) will be established with a speed of ≥10Mbps to meet the needs of large-volume multimodal data transmission.

[0033] The above method achieves adaptive matching of emergency data transmission channels, accurately matching transmission requirements for different data volumes and communication distances. Small data can be transmitted quickly over short distances with low power consumption, while large data can be transmitted completely over medium distances at high speed. This approach provides a rapid response while balancing transmission efficiency, power consumption, and reliability, enhancing the practicality of the method in this embodiment for emergency rescue.

[0034] Optionally, in some embodiments of this application, sending multimodal emergency data to the target terminal includes: dividing the multimodal emergency data into data blocks according to a preset emergency data priority rule, and transmitting data blocks corresponding to location information, data blocks corresponding to distress signals, data blocks corresponding to voice information, and data blocks corresponding to image information in descending order of emergency data priority; if a transmission link interruption occurs, after the transmission link is interrupted and the communication connection is re-established, receiving the sequence number of the received data blocks fed back by the target terminal, and continuing to transmit the uncompleted data blocks through the target transmission channel based on the breakpoint resume mechanism.

[0035] In this embodiment, at this stage, once the target transmission channel is determined, the collected multimodal emergency data is first processed. Based on a preset emergency data priority rule, the multimodal emergency data is divided into different data blocks. The preset emergency data priorities, from highest to lowest, are: location information data block, distress signal data block, voice information data block, and image information data block. Specifically, the location information data block contains the user's real-time offline location coordinates; the distress signal data block contains the user device's unique identifier and an emergency status marker; the voice information data block contains a distress voice clip of preset duration; and the image information data block contains images of the scene environment. Each data block is marked with a unique sequence number for subsequent verification and retransmission. After the data blocks are divided, they are transmitted sequentially according to their emergency data priority, prioritizing the transmission of the two core emergency data types: location information and distress signals, to ensure the rescuer (target terminal) quickly obtains crucial distress information. Voice and image information are then transmitted sequentially to supplement scene details. During transmission, the target terminal receives data blocks in real time and records the sequence number of successfully received data blocks. After receiving each data block, it sends a reception confirmation signal for the corresponding sequence number back to the user device. If the transmission link is interrupted during transmission due to environmental obstructions, device movement, or other factors (such as Bluetooth signal loss or disconnection of the direct Wi-Fi connection), data transmission is paused, and the communication signal of the target terminal is continuously monitored. Once the target terminal re-enters the communication range and the transmission link is re-established, the user device immediately receives the sequence number of the received data blocks from the target terminal. Based on the breakpoint resumption mechanism, it compares its own untransmitted data block sequence number with the target terminal's received sequence number, filters out the untransmitted data blocks, and continues transmitting the uncompleted data blocks through the established target transmission channel, without retransmitting the received data blocks. This emergency data priority transmission, prioritizing location information > distress signals > voice information > image information, ensures that the target terminal quickly obtains key data such as location and identity, prioritizing core distress needs and buying time for rapid rescue, thus meeting the core requirement of "ensuring critical data first, then supplementing details" in emergency scenarios. The breakpoint resumption mechanism avoids retransmitting received data after link interruption, reducing transmission redundancy, lowering device power consumption and transmission latency, while ensuring that multimodal emergency data (voice, images, etc.) is ultimately delivered completely, avoiding information loss due to interruption. This achieves an optimal balance between transmission efficiency, power consumption, and data integrity, extending the device's emergency battery life and making it highly suitable for data transmission characteristics in scenarios involving low-power Bluetooth and direct-connect wireless LAN.

[0036] Furthermore, in some embodiments of this application, the method further includes: when a direct wireless LAN transmission channel is selected as the target transmission channel, but the number of consecutive connection failures exceeds a preset number, a data degradation mechanism is triggered to call the image processing engine to compress the environmental image information in the multimodal emergency data, so that the data volume of the processed data is reduced to below a preset volume threshold, thereby generating degraded data; the degraded data is divided into multiple data fragments, and the data fragments are sent to the target terminal based on the extended broadcast channel of the Bluetooth transmission channel carrying an auto-incrementing sequence number.

[0037] This embodiment further defines a common application scenario for emergency communication during distress calls. Specifically, when a user device, based on data volume and communication distance, selects a direct-connect Wi-Fi channel as the target transmission channel and attempts to establish a communication connection with the target terminal, but fails to establish a successful connection after multiple attempts, the direct-connect Wi-Fi channel is deemed unusable, and a data degradation mechanism is immediately triggered. After the data degradation mechanism is triggered, the user device invokes its built-in image processing engine to process the environmental image information in the multimodal emergency data. Specific processing methods include feature extraction and compression. During feature extraction, only core features relevant to emergency rescue (such as the outline of the distressed environment and the user's silhouette) are retained, while redundant pixel information is removed. For compression, an efficient compression algorithm is used to reduce image resolution and bit rate while ensuring the core rescue information remains identifiable. Through these processes, the overall multimodal emergency data volume is reduced to below a preset volume threshold, generating degraded data that is compatible with the transmission capabilities of the Bluetooth transmission channel. After the downgraded data is generated, it is further divided into multiple equally sized data fragments. Each data fragment is marked with a unique auto-incrementing sequence number, which is used by the target terminal to verify the integrity and order upon receipt. Then, the two-way communication is switched to the Bluetooth transmission channel. Using the extended broadcast channel of the Bluetooth transmission channel, the data fragments carrying the auto-incrementing sequence numbers are sent sequentially to the target terminal. After receiving the data fragments, the target terminal sorts and concatenates them according to the auto-incrementing sequence numbers to restore the complete downgraded data, completing the emergency data transmission. This step switches to the Bluetooth transmission channel through the data downgrade mechanism when the direct Wi-Fi connection fails, avoiding the inability to send emergency data due to a single channel failure, ensuring uninterrupted distress messages, and improving the success rate of emergency distress calls. Image compression or feature extraction is used to reduce the data size, adapting it to the bandwidth and power consumption limitations of the Bluetooth transmission channel. Simultaneously, the extended broadcast channel and auto-incrementing sequence numbers ensure orderly and complete transmission of data fragments, reducing packet loss. Downgrade processing only compresses or extracts redundant image information, retaining key emergency data such as location, distress signals, voice, and core image features. This ensures rescuers receive effective information while improving Bluetooth transmission efficiency and avoiding transmission delays caused by excessive data size. The entire process requires no manual user operation, adapting to emergency scenarios where users are stressed or injured and unable to perform complex operations, further lowering the operational threshold and ensuring timely transmission.

[0038] Optionally, in some embodiments of this application, the method further includes: step S106: when the user equipment receives multimodal emergency data sent by other transmitting devices as a receiving end, it obtains the current remaining power of the user equipment and the communication strength between the user equipment and other transmitting devices; calculates the relay weight value based on the current remaining power and communication strength, and allocates the backoff time according to the preset correspondence between the relay weight value and the backoff time, wherein the higher the relay weight value, the shorter the allocated backoff time; during the countdown of the backoff time, it monitors whether there are other terminals in the vicinity forwarding multimodal emergency data with the same device identifier; if no other terminals are detected, it forwards the multimodal emergency data to the outside through its own broadcast channel after the backoff time ends.

[0039] In one practical application scenario of this embodiment, when a user device (UGC) receives multimodal emergency data (including raw or degraded data) from another transmitting device via a Bluetooth transmission channel or a direct wireless LAN transmission channel, it first obtains its current remaining battery power. Simultaneously, through its built-in communication module, it detects and obtains the communication strength (expressed as a signal strength value in dBm) with the transmitting device. Subsequently, the UAC calculates a relay weight value based on preset calculation rules, considering both the remaining battery power and communication strength: the higher the remaining battery power and the stronger the communication strength, the higher the relay weight value. Based on the calculated relay weight value, a corresponding backoff time is allocated to itself. A higher relay weight value results in a shorter backoff time, ensuring that devices with strong relay capabilities are prioritized for forwarding, thus improving forwarding efficiency. During the backoff time countdown, the UAC continuously activates its broadcast monitoring function to listen for other terminals forwarding multimodal emergency data with the same device identifier (i.e., the unique identifier of the transmitting device), avoiding signal conflicts and power waste caused by multiple terminals forwarding simultaneously. If no other terminal in the vicinity is detected forwarding emergency data with the same device identifier during the backoff time countdown, the user device will automatically activate its own broadcast channel (Bluetooth Extended Broadcast Channel) after the backoff time ends to forward the multimodal emergency data, achieving relay transmission of emergency information. If other terminals have already forwarded the data, the device will terminate its own forwarding operation and only maintain a listening state to avoid redundant transmission. This step limits the relay transmission of emergency data to relay forwarding through the receiving end, solving the problem of limited communication distance of a single sending end, allowing distress information to cover a wider range, increasing the probability of being discovered by the rescued party, and adapting to large-scale no-network scenarios such as the wilderness and disaster sites. Weights are calculated and backoff time is allocated based on remaining battery power and communication strength, ensuring that devices with sufficient power and stable communication are given priority for forwarding, preventing devices with insufficient power from consuming too much power during forwarding and thus being unable to send out distress signals, while also reducing signal collisions and improving forwarding reliability. By monitoring the forwarding situation in the vicinity, multiple terminals are prevented from repeatedly forwarding the same data, reducing communication channel occupation and device power consumption, balancing relay efficiency and device emergency battery life, and adapting to the transmission characteristics of Bluetooth Low Energy. Furthermore, the process requires no manual intervention from the user and is automatically triggered after receiving data, adapting to scenarios where users are in an emergency and unable to operate the device, further improving the timeliness and practicality of emergency response.

[0040] Optionally, in some embodiments of this application, after establishing an unconfirmed pairing communication connection with the target terminal and before sending multimodal emergency data, the method further includes: obtaining the information format types supported by the target terminal and the current signal reception capability of the target terminal through the communication connection; based on the information format type and the current signal reception capability, providing compatibility status prompts and transmission success rate warnings on the user device's interactive interface. The purpose of this step in this embodiment is to predict transmission compatibility and reliability in advance, avoiding data loss or transmission failure caused by blind transmission, while allowing users to intuitively understand the transmission status. By implementing this step, transmission problems caused by format incompatibility and weak signal reception can be avoided in advance, improving the success rate of emergency data transmission; users can quickly grasp transmission risks and adjust data in advance if necessary to adapt to the timeliness requirements of emergency scenarios; user operation is simplified, eliminating the need for manual compatibility testing, balancing practicality and ease of use, and further ensuring the reliability of emergency rescue.

[0041] Optionally, in some embodiments of this application, after sending multimodal emergency data to the target terminal, the method further includes: listening to the reception confirmation signal returned by the target terminal; and in response to the reception confirmation signal, controlling the user device to execute a preset physical perception reminder, which includes at least one of vibration reminder, screen flashing reminder, or audio reminder at a specific frequency. This embodiment limits the user device to continuously listening to the reception confirmation signal returned by the target terminal, which can be automatically returned by the target terminal after successful reception and restoration of complete data. When the user device receives the reception confirmation signal, it immediately responds and controls itself to execute a preset physical perception reminder, such as vibration, screen flashing, or audio at a specific frequency, without requiring manual triggering by the user. The purpose is to allow the user to intuitively confirm that the emergency data has been successfully delivered, avoiding repeated transmissions due to uncertain transmission results and saving device power consumption. This alleviates user anxiety in emergency situations; avoids resource waste and delays caused by repeated transmissions, ensuring device emergency battery life; and makes physical perception reminders more easily noticed by users in tense or noisy environments, improving the user experience in emergency scenarios, further ensuring a closed-loop rescue process, and improving rescue reliability.

[0042] Optionally, in some embodiments of this application, after receiving the confirmation signal, the method further includes: cutting off the power supply to the target transmission channel, or controlling the corresponding communication module to enter a sleep state; and switching the Bluetooth module of the user device to a low-frequency listening mode that only retains the specific broadcast payload. This embodiment limits the following: if a direct wireless LAN channel or high-speed transmission channel was previously used, the power supply to that channel is immediately stopped or it is put into a low-power sleep mode after data transmission is completed and a confirmation signal is received, to avoid unnecessary power consumption; if a Bluetooth channel was previously used, only the core listening function is retained, and the power supply to redundant transmission modules is turned off. The low-frequency listening mode retains only the listening function for specific broadcast payloads (i.e., simplified broadcast packets containing emergency identifiers and unique device identifiers), reducing the operating frequency and power consumption of the Bluetooth module, no longer performing large amounts of data transmission, and focusing only on capturing possible rescue terminal signals or subsequent supplementary transmission needs. Furthermore, the Bluetooth module only wakes up within a preset low-frequency interval to detect whether a new target terminal is connected or needs supplementary transmission, and remains in low-power sleep mode the rest of the time, ensuring the timeliness of subsequent emergency response while minimizing device power consumption and extending emergency battery life.

[0043] The emergency communication method provided in this application receives a trigger command from a user device in a network-free communication mode; in response to the trigger command, it initiates Bluetooth broadcasting to discover the target terminal and establishes a communication connection with the target terminal without confirmation pairing; according to the mode type corresponding to the trigger command, it collects corresponding multimodal emergency data; it obtains the data volume of the multimodal emergency data and estimates the communication distance with the target terminal. This emergency communication method for emergency rescue in a network-free environment is simple to operate, requires no parameter configuration or cumbersome operations from the user, and has extremely low operational complexity. Furthermore, the entire workflow can achieve a high degree of automated control, completing core operations without manual intervention. The communication channel selection is adaptive and more reasonable, achieving an optimal balance between transmission efficiency and reliability. It offers excellent communication reliability and resource utilization, resulting in a good user experience.

[0044] Example 2 Based on the emergency communication method provided in Embodiment 1 of this application, this embodiment also provides a corresponding emergency communication device, such as... Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of an emergency communication device 20 provided in an embodiment of this application. The emergency communication device 20 includes: Trigger module 201 is used to receive trigger commands in offline communication mode; The pairing module 202 is used to respond to a trigger command, start Bluetooth broadcast to discover the target terminal, and establish a communication connection with the target terminal without confirmation pairing. The acquisition module 203 is used to acquire corresponding multimodal emergency data according to the mode type corresponding to the trigger command; The calculation module 204 is used to acquire the data volume of multimodal emergency data and estimate the communication distance with the target terminal; The transmission module 205 is used to adaptively select a target transmission channel from multiple transmission channels based on data volume and communication distance, so as to send multimodal emergency data to the target terminal based on the target transmission channel.

[0045] Optionally, in some embodiments of this application, the offline communication mode includes at least a personal distress signal mode, a companion interconnection mode, and an emergency broadcast mode. Correspondingly, the trigger module 201 is also used for: Monitor interrupt requests from the underlying hardware of the user equipment or touch commands from the application layer; When a continuous change in the state of a user's physical shortcut key is detected or a specific touch command is received on the screen, a trigger command of the corresponding mode type is generated.

[0046] Optionally, in some embodiments of this application, the acquisition module 203 is further configured to: if the mode type is a personal distress mode, silently invoke the user device to acquire target data, the target data including: real-time location information, voice information of a preset duration and environmental image information, and associate and encapsulate the target data into a distress data packet.

[0047] Optionally, in some embodiments of this application, the pairing module 202 is further configured to: write the device identifier and compatible protocol version field information of the user equipment into the broadcast payload of the Bluetooth broadcast signal, and broadcast it to identify nearby communicable target terminals; Receive the Bluetooth response signal from the target terminal, extract the peer-to-peer compatible protocol version field carried in the Bluetooth response signal; input the peer-to-peer compatible protocol version field into the protocol conversion middleware built into the user device, and the protocol conversion middleware matches the corresponding heterogeneous operating system instruction mapping rules according to the peer-to-peer compatible protocol version field; Based on the heterogeneous operating system instruction mapping rules, the communication handshake instructions of the user equipment are converted into a universal format handshake instructions that can be recognized by the target terminal. Pairing with the target terminal is completed at the link layer based on a universal handshake command format.

[0048] Optionally, in some embodiments of this application, the transmission module 205 is further configured to: If the data volume is less than the preset volume threshold and the communication distance is less than the preset first distance threshold, select the Bluetooth transmission channel as the target transmission channel. If the data volume is greater than or equal to the preset volume threshold and the communication distance is less than the preset second distance threshold, the paired Bluetooth link is used to exchange keys and a direct wireless LAN transmission channel is established as the target transmission channel. Among them, the preset second distance threshold is greater than the preset first distance threshold.

[0049] Optionally, in some embodiments of this application, the device 20 further includes a degradation module (not shown in the drawings): the degradation module is used for: When the direct wireless LAN transmission channel is selected as the target transmission channel, but the number of consecutive connection failures exceeds the preset number, the data degradation mechanism is triggered to call the image processing engine to compress the environmental image information in the multimodal emergency data so that the data volume of the processed data is reduced to below the preset volume threshold, and degraded data is generated. The degraded data is divided into multiple data fragments, and an auto-incrementing sequence number is carried on the extended broadcast channel of the Bluetooth transmission channel to send the data fragments to the target terminal.

[0050] Optionally, in some embodiments of this application, the transmission module 205 is further configured to: divide the multimodal emergency data into data blocks according to a preset emergency data priority rule, and transmit the data blocks corresponding to the location information, the data blocks corresponding to the distress sign, the data blocks corresponding to the voice information, and the data blocks corresponding to the image information in order of emergency data priority from high to low. If a transmission link interruption occurs, after the transmission link is interrupted and the communication connection is re-established, the sequence number of the received data block is received from the target terminal, and the data block that has not been transmitted is continued to be transmitted through the target transmission channel based on the breakpoint resume mechanism.

[0051] Optionally, in some embodiments of this application, such as Figure 4 As shown, Figure 4 This is a schematic diagram of another emergency communication device 21 provided in an embodiment of this application. The device 21 further includes a relay module 206, which is used for: When a user equipment receives multimodal emergency data sent by other sending devices as a receiver, it obtains the user equipment's current remaining power and the communication strength between the user equipment and other sending devices. The relay weight value is calculated based on the current remaining power and communication strength, and the backoff time is allocated according to the preset correspondence between the relay weight value and the backoff time. The higher the relay weight value, the shorter the allocated backoff time. During the countdown to the retreat period, monitor whether other terminals in the vicinity are forwarding multimodal emergency data with the same device identifier; If no response is received, the system will forward multimodal emergency data to other systems via its own broadcast channel after the backoff period ends.

[0052] Optionally, in some embodiments of this application, the device 21 further includes: a reminder module 207, which is used to obtain the information format type supported by the target terminal and the current signal receiving capability of the target terminal through the communication connection after establishing an unconfirmed pairing communication connection with the target terminal and before sending multimodal emergency data; and to provide compatibility status prompts and transmission success rate warnings on the user equipment's interactive interface based on the information format type and the current signal receiving capability.

[0053] Optionally, in some embodiments of this application, the reminder module 207 is further configured to listen to the receipt confirmation signal returned by the target terminal after sending the multimodal emergency data to the target terminal; in response to the receipt confirmation signal, control the user equipment to execute a preset physical perception reminder, the physical perception reminder including at least one of vibration reminder, screen flashing reminder or audio reminder of a specific frequency.

[0054] Optionally, in some embodiments of this application, the device 21 further includes a muting module 208, which is used to: cut off the power supply to the target transmission channel or control the corresponding communication module to enter a sleep state after receiving a confirmation signal; and switch the Bluetooth module of the user equipment to a low-frequency listening mode that only retains the specific broadcast payload.

[0055] Example 3 This application also provides a storage medium storing a computer program that, when executed by a processor, implements any of the emergency communication methods described in the foregoing embodiment one of this application.

[0056] Example 4 This application also provides an electronic device, such as... Figure 5 As shown, Figure 5 This application provides a schematic diagram of the structure of an electronic device 30, which includes: One or more processors 301, communication interface 302, memory 303 and communication bus 304, the processors 301, memory 303 and communication interface 302 communicate with each other through communication bus 304; Memory 303 is used to store one or more programs; When one or more programs are executed by one or more processors 301, the one or more processors 301 implement any of the emergency communication methods as described in Embodiment 1 of this application.

[0057] This application has now described specific embodiments of the subject matter. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing can be advantageous.

[0058] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system layer onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confirm, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0059] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0060] The system layers, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0061] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0062] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0063] Those skilled in the art will understand that embodiments of this application can be provided as methods, system-level, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0064] This application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific transactions or implement specific abstract data types. This application can also be practiced in distributed computing environments where transactions are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0065] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system-level embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0066] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An emergency communication method, characterized in that, Applied to user equipment, the method includes: Receive trigger commands for offline communication mode; In response to the trigger command, Bluetooth broadcasting is initiated to discover the target terminal and establish a communication connection with the target terminal without confirmation pairing. Based on the mode type corresponding to the trigger command, collect the corresponding multimodal emergency data; The data volume of the multimodal emergency data is obtained, and the communication distance with the target terminal is estimated. Based on the data volume and the communication distance, a target transmission channel is adaptively selected from multiple transmission channels to send the multimodal emergency data to the target terminal via the target transmission channel.

2. The method according to claim 1, characterized in that, The offline communication modes include at least a personal distress mode, a companion interconnection mode, and an emergency broadcast mode; Correspondingly, the trigger command for receiving the offline communication mode includes: Monitor interrupt requests from the underlying hardware of the user equipment or touch commands from the application layer; When a continuous change in the state of the physical shortcut key of the user device is detected or a specific touch command is received on the screen, a trigger command of the corresponding mode type is generated.

3. The method according to claim 2, characterized in that, The step of collecting corresponding multimodal emergency data based on the mode type corresponding to the trigger command includes: If the mode type is a personal distress mode, the user device is silently invoked to collect target data, which includes: real-time location information, voice information of a preset duration, and environmental image information, and the target data is associated and encapsulated into a distress data packet.

4. The method according to any one of claims 1-3, characterized in that, The step of responding to the trigger command by initiating Bluetooth broadcasting to discover the target terminal and establishing an unconfirmed pairing communication connection with the target terminal includes: The user device's device identifier and compatible protocol version information are written into the broadcast payload of the Bluetooth broadcast signal and broadcast to identify nearby communicable target terminals. Receive the Bluetooth response signal fed back by the target terminal, and extract the peer-to-peer compatible protocol version field carried in the Bluetooth response signal; The peer-to-peer compatible protocol version field is input into the protocol conversion middleware built into the user equipment. The protocol conversion middleware then matches the corresponding heterogeneous operating system instruction mapping rules based on the peer-to-peer compatible protocol version field. Based on the heterogeneous operating system instruction mapping rules, the communication handshake instructions of the user equipment are converted into a universal format handshake instructions that the target terminal can recognize; Based on the general format handshake command, pairing is completed with the target terminal at the link layer.

5. The method according to any one of claims 1-3, characterized in that, The adaptive selection of a target transmission channel from multiple transmission channels based on the data volume and the communication distance includes: If the data volume is less than a preset volume threshold and the communication distance is less than a preset first distance threshold, the Bluetooth transmission channel is selected as the target transmission channel. If the data volume is greater than or equal to the preset volume threshold and the communication distance is less than the preset second distance threshold, the paired Bluetooth link is used to exchange keys and establish a direct wireless LAN transmission channel as the target transmission channel. Wherein, the preset second distance threshold is greater than the preset first distance threshold.

6. The method according to claim 5, characterized in that, The method further includes: When the direct wireless LAN transmission channel is selected as the target transmission channel, but the number of consecutive connection failures exceeds a preset number, the image processing engine is invoked to compress the environmental image information in the multimodal emergency data, so that the data volume of the processed data is reduced to below the preset volume threshold, and degraded data is generated. The downgraded data is divided into multiple data fragments, and the data fragments are sent to the target terminal based on the extended broadcast channel of the Bluetooth transmission channel, carrying an auto-incrementing sequence number.

7. The method according to any one of claims 1-3, characterized in that, The step of sending the multimodal emergency data to the target terminal includes: The multimodal emergency data is divided into data blocks according to the preset emergency data priority rules, and the corresponding location information data block, the corresponding distress signal data block, the corresponding voice information data block, and the corresponding image information data block are transmitted in order from high to low emergency data priority. If a transmission link interruption occurs, after the transmission link is interrupted and the communication connection is re-established, the sequence number of the received data block fed back by the target terminal is received, and the data block that has not been transmitted is continued to be transmitted through the target transmission channel based on the breakpoint resume mechanism.

8. The method according to claim 1, characterized in that, The method further includes: When the user equipment receives multimodal emergency data sent by other transmitting devices as a receiving end, it obtains the current remaining power of the user equipment and the communication strength between the user equipment and other transmitting devices. The relay weight value is calculated based on the current remaining power and the communication strength, and the backoff time is allocated according to the preset correspondence between the relay weight value and the backoff time. The higher the relay weight value, the shorter the allocated backoff time. During the countdown of the retreat duration, monitor whether other terminals in the vicinity are forwarding multimodal emergency data with the same device identifier; If no response is received, the multimodal emergency data will be forwarded to the outside world through its own broadcast channel after the backoff period ends.

9. The method according to any one of claims 1-3, characterized in that, After establishing an unconfirmed pairing communication connection with the target terminal, and before sending the multimodal emergency data, the method further includes: The information format types supported by the target terminal and the current signal receiving capability of the target terminal are obtained through the communication connection. Based on the information format type and the current signal receiving capability, compatibility status prompts and transmission success rate warnings are displayed on the user equipment's interactive interface.

10. An electronic device, characterized in that, include: One or more processors, communication interfaces, memory, and communication buses, wherein the processors, memory, and communication interfaces communicate with each other through the communication bus; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the emergency communication method as described in any one of claims 1 to 9.

Images