A multi-terminal cooperative emergency broadcast transmission control method, system and device

Abstract

The application provides a multi-terminal cooperative emergency broadcast transmission control method, system and device, and the method comprises the following steps: acquiring installation position information of all emergency broadcast transmission terminals and state data of each emergency broadcast transmission terminal; grouping the emergency broadcast transmission terminals according to the installation position information of all the emergency broadcast transmission terminals, and determining a plurality of basic terminal groups; performing master-slave terminal election processing on each basic terminal group according to the state data of each emergency broadcast transmission terminal, and determining the master terminal and the slave terminal in each basic terminal group; receiving emergency broadcast information issued by an emergency broadcast platform through the master terminal in each basic terminal group; and sending the emergency broadcast information to the slave terminal in the respective basic terminal group through the master terminal, and simultaneously sending the emergency broadcast information to the respective corresponding client terminal through the master terminal. The scheme of the application realizes efficient, reliable, accurate and persistent emergency information publishing.

Description

Technical Field

[0001] This invention relates to the field of emergency broadcast transmission technology, and in particular to a multi-terminal collaborative emergency broadcast transmission control method, system and equipment. Background Technology

[0002] In emergency communication scenarios, the timely and effective dissemination of emergency broadcasts relies on the collaborative work and information synchronization of multiple terminals. However, existing technologies have many limitations, highlighting core technical issues. Traditional emergency broadcast systems often use a method where the emergency broadcast platform establishes a separate connection with each terminal. This not only consumes a large amount of network bandwidth but also causes inconsistent latency among terminals due to differences in network transmission paths, resulting in asynchronous audio playback across multiple terminals and affecting the user's reception experience. Furthermore, it can only cover networked broadcast terminals, making it difficult to adapt to various civilian terminals such as mobile phones, computers, and displays. It also lacks precise positioning capabilities, requiring the use of third-party platforms for cross-terminal push notifications, leading to poor notification effectiveness. Additionally, emergency communication private networks are often distributed networks without a central device, making their information infrastructure vulnerable. Channel status is greatly affected by spatiotemporal differences among nodes. Traditional channel management methods lack effective multi-terminal collaborative evaluation mechanisms and cannot accurately match channel resources according to different data volumes and task types such as voice, text, and high-definition video, resulting in low channel utilization, severe congestion, and unstable transmission quality. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a multi-terminal collaborative emergency broadcast transmission control method, system and equipment, which solves the problems of existing emergency broadcast technology in the process of transmission, such as occupying a large amount of network bandwidth, inconsistent terminal latency, low channel utilization, serious congestion and unstable transmission quality.

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0005] This invention provides a multi-terminal collaborative emergency broadcast transmission control method, applied to an emergency broadcast terminal transmission control system, the method comprising:

[0006] Obtain the installation location information of all emergency broadcast transmission terminals and the status data of each emergency broadcast transmission terminal;

[0007] Based on the installation location information of all emergency broadcast transmission terminals, the emergency broadcast transmission terminals are grouped to determine multiple basic terminal groups;

[0008] Based on the status data of each emergency broadcast transmission terminal, a master-slave terminal election process is performed for each basic terminal group to determine the master terminal and slave terminal in each basic terminal group.

[0009] Each basic terminal group receives emergency broadcast information from the emergency broadcast platform through its main terminal.

[0010] The main terminal sends the emergency broadcast information to the slave terminals in their respective basic terminal groups, and simultaneously sends it to their respective client terminals.

[0011] The present invention also provides an emergency broadcast terminal transmission control system, comprising:

[0012] The acquisition module is used to acquire the installation location information of all emergency broadcast transmission terminals and the status data of each emergency broadcast transmission terminal;

[0013] The data processing module is used to group the emergency broadcast transmission terminals according to their installation location information to determine multiple basic terminal groups; to perform master-slave terminal election processing for each basic terminal group according to the status data of each emergency broadcast transmission terminal to determine the master terminal and slave terminal within each basic terminal group; to receive emergency broadcast information from the emergency broadcast platform through the master terminal within each basic terminal group; and to send the emergency broadcast information to the slave terminals within their respective basic terminal groups through the master terminal, and simultaneously send it to their respective client terminals.

[0014] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above.

[0015] The above-described solution of the present invention has at least the following beneficial effects:

[0016] The multi-terminal collaborative emergency broadcast transmission control method of this invention acquires the installation location information and status data of all emergency broadcast transmission terminals; based on the installation location information, the emergency broadcast transmission terminals are grouped to determine multiple basic terminal groups; based on the status data of each emergency broadcast transmission terminal, a master-slave terminal election process is performed for each basic terminal group to determine the master terminal and slave terminals within each basic terminal group; the master terminal within each basic terminal group receives emergency broadcast information from the emergency broadcast platform; the master terminal sends the emergency broadcast information to the slave terminals within its respective basic terminal group, and simultaneously sends it to their corresponding client terminals. This achieves efficient, reliable, accurate, and persistent emergency information dissemination. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the multi-terminal collaborative emergency broadcast transmission control method of the present invention;

[0018] Figure 2 This is a schematic diagram of the module block structure of the emergency broadcast terminal transmission control system of the present invention. Detailed Implementation

[0019] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0020] like Figure 1 As shown, an embodiment of the present invention proposes a multi-terminal collaborative emergency broadcast transmission control method, applied to an emergency broadcast terminal transmission control system. The method includes:

[0021] Step 11: Obtain the installation location information of all emergency broadcast transmission terminals and the status data of each emergency broadcast transmission terminal; the installation information is the coordinates or latitude and longitude of the installation location of the transmission terminal; the status data of the emergency broadcast transmission terminal includes: the remaining power parameters, communication bandwidth parameters, working status (normal / fault) of the emergency broadcast transmission terminal, and its own device identification ID (which can be represented by the device MAC address);

[0022] Step 12: Based on the installation location information of all emergency broadcast transmission terminals, group the emergency broadcast transmission terminals to determine multiple basic terminal groups;

[0023] Step 13: Based on the status data of each emergency broadcast transmission terminal, perform master-slave terminal election processing for each basic terminal group to determine the master terminal and slave terminal in each basic terminal group;

[0024] Step 14: Receive emergency broadcast information from the emergency broadcast platform through the main terminal in each basic terminal group;

[0025] Step 15: The emergency broadcast information is sent from the main terminal to the slave terminals in their respective basic terminal groups, and simultaneously sent to their respective client terminals by the slave terminals.

[0026] In this embodiment, the multi-terminal collaborative emergency broadcast transmission control method of the present invention, by grouping the transmission terminals and setting master-slave terminal classification elections based on the status data of all emergency broadcast transmission terminals, can realize multi-terminal collaborative control by controlling multiple terminals simultaneously through one emergency broadcast platform. This achieves unified management and synchronous transmission of emergency broadcast information, thereby reducing network bandwidth occupation and terminal latency. At the same time, the unified management settings can also realize unified allocation of transmission channels, thereby improving channel utilization, reducing channel congestion, and achieving efficient, reliable, accurate, and persistent emergency information dissemination.

[0027] In an optional embodiment of the present invention, step 12, grouping the emergency broadcast transmission terminals according to the installation location information of all emergency broadcast transmission terminals to determine multiple basic terminal groups, may include:

[0028] Step 121: Based on the installation location information, identify all emergency broadcast transmission terminals that are within the same preset installation location range as the same basic terminal group, thus obtaining multiple basic terminal groups; and connect the emergency broadcast transmission terminals within the same basic terminal group to the same local area network.

[0029] In this embodiment, all emergency broadcast transmission terminals are equipped with locators, which combine GPS / BeiDou positioning with local area network location calibration to obtain accurate coordinates with an error of ≤10 meters; the installation location information being within the same preset installation location range refers to the preset range covered by the same building, utility pole, or other installation point; by connecting the transmission terminals in the same basic terminal group to the same local area network, the cross-network transmission latency can be effectively reduced.

[0030] In an optional embodiment of the present invention, step 13, which involves performing master-slave terminal election processing on each basic terminal group based on the status data of each emergency broadcast transmission terminal to determine the master terminal and slave terminal within each basic terminal group, may include:

[0031] Step 131: Based on the status data of each emergency broadcast transmission terminal and the first preset condition, the emergency broadcast transmission terminals in each basic terminal group are grouped to obtain the election terminal group and the auxiliary terminal group.

[0032] Step 132: Based on preset rules and the status data of each emergency broadcast transmission terminal in the election terminal group, perform terminal election processing on the emergency broadcast transmission terminals in the election terminal group to determine the main terminal of the current basic terminal group;

[0033] Step 133: Determine the remaining emergency broadcast transmission terminals in the election terminal group and the emergency broadcast transmission terminals in the auxiliary terminal group as slave terminals.

[0034] In this embodiment, all terminals automatically identify their own fixed device ID, supported protocols (RTSP, multicast IP, etc.), reception type (audio), and other information to generate a device capability list, providing data support for subsequent grouping, election, and push adaptation. Then, combined with the remaining power (≥30% is the core node threshold) and communication bandwidth (≥10Mbps is the preferred threshold) of the dedicated terminals, the grouping structure is optimized, and high-performance terminals are included in the core group, i.e., the election terminal group, while low-power terminals are assigned to the auxiliary group.

[0035] In an optional embodiment of the present invention, step 131, which involves grouping the emergency broadcast transmission terminals within each basic terminal group according to the status data of each emergency broadcast transmission terminal and a first preset condition to obtain an election terminal group and an auxiliary terminal group, may include:

[0036] Step 1311: The emergency broadcast transmission terminals in the current basic terminal group whose remaining power is greater than or equal to a first preset value and whose communication bandwidth is greater than or equal to a second preset value are divided into election terminal groups; wherein, the first preset value is 30%; and the second preset value is 10Mbps.

[0037] Step 1312: Divide the emergency broadcast transmission terminals in the current basic terminal group whose remaining power is less than a first preset value or whose communication bandwidth is less than a second preset value into auxiliary terminal groups.

[0038] In this embodiment, by performing secondary grouping of terminals within the basic terminal group, terminals that can meet the requirements for subsequent master-slave grouping can be quickly identified, thereby reducing the total number of terminals during master-slave confirmation, reducing subsequent score calculations, and achieving rapid confirmation of master-slave terminals.

[0039] In an optional embodiment of the present invention, step 132, which involves performing terminal election processing on the emergency broadcast transmission terminals within the election terminal group according to preset rules and the status data of each emergency broadcast transmission terminal in the election terminal group, and determining the master terminal of the current basic terminal group, may include:

[0040] Step 1321: Calculate the status data of each emergency broadcast transmission terminal in the election terminal group according to the preset rules, the first preset weight, the second preset weight, and the third preset weight, and determine the status score of each emergency broadcast transmission terminal in the election terminal group.

[0041] Step 1322: Compare the status score received by each emergency broadcast transmission terminal with its current status score to obtain the comparison result;

[0042] Step 1323: Based on the comparison results, the emergency broadcast transmission terminal with the highest status score is selected as the main terminal of the current basic terminal group. Each of the elected terminal groups retains one main terminal. When there are multiple emergency broadcast transmission terminals with the same status score in the comparison results, the one with the largest device mark is selected as the main terminal.

[0043] In this embodiment, the device tag refers to the device's own ID value; the preset rule is that when all emergency broadcast transmission terminals in the election terminal group are initially powered on, or when the current main terminal's battery level is lower than a first preset battery level, or when the main terminal is offline, malfunctioning, or experiencing a signal interruption, the first preset battery level can be set to 10%, and the terminal election function is automatically triggered; during the election, each terminal calculates its own total score using a formula (for terminals with a battery level below 10%, the value is directly assigned to 0), and the terminal broadcasts its own ID and total score information to the group; all terminals in the group compare their total scores, and the one with the highest total score is elected as the main terminal; if the total scores are the same, the one with the larger device ID is given priority; the remaining terminals are automatically slave terminals, and the election is completed; specifically, for example, in a no-support / urban conventional scenario, terminal A: ID=150, battery level=85%; terminal B Terminal A: ID=140, battery level=90%; Terminal B: ID=130, battery level=8%; Calculation: A=150×0.7+85×0.3=130.5; B=140×0.7+90×0.3=125.0; C=0; The result is that Terminal A is selected as the main terminal; In a high-density crowd scenario, when Terminal A: ID=150, battery level=85%, bandwidth=20Mbps; Terminal B: ID=140, battery level=90%, bandwidth=30Mbps; Terminal C: ID=130, battery level=8%, bandwidth=50Mbps; Calculation: A=150×0.6+85×0.3+20×0.1=117.5; B=140×0.6+90×0.3+30×0.1=114.0; C=0, the result is that Terminal A is selected as the main terminal.

[0044] In this embodiment, the master terminal is mainly responsible for establishing a connection with the emergency broadcasting platform, receiving broadcast data, managing channel resources, coordinating the work of slave terminals, and pushing data to civilian terminals; the slave terminals are responsible for receiving broadcast data forwarded by the master terminal, providing feedback on their own status information, and forwarding the received broadcast data to civilian terminals such as mobile phones and computers; the multi-terminal collaborative emergency broadcasting transmission control method of the present invention ensures that the elected master terminal has good communication functions at all times through the automatic election setting of master and slave terminals, and ensures that stable signal reception and transmission can always be achieved in harsh environments. In an optional embodiment of the present invention, step 1321, according to preset rules, a first preset weight, a second preset weight, and a third preset weight, calculates the status data of each emergency broadcasting transmission terminal in the election terminal group to determine the status score of each emergency broadcasting transmission terminal in the election terminal group, which may include:

[0045] Step 13211: When all emergency broadcast transmission terminals in the election terminal group are initially powered on or when the current main terminal's battery level is lower than the first preset battery level, based on the status data of each emergency broadcast transmission terminal, the status score A corresponding to the status data of each emergency broadcast transmission terminal is determined by the formula A=b1×c1+b2×c2+b3×c3; where c1 is the first preset weight; c2 is the second preset weight; c3 is the third preset weight; b1 is the device ID of the emergency broadcast transmission terminal in the status data of the current emergency broadcast transmission terminal; b2 is the remaining battery level parameter of the emergency broadcast transmission terminal in the status data of the current emergency broadcast transmission terminal; b3 is the communication bandwidth parameter of the emergency broadcast transmission terminal in the status data of the current emergency broadcast transmission terminal.

[0046] In this embodiment, the first preset weight, the second preset weight, and the third preset weight can be set according to environmental requirements. For unsupported or typical urban scenarios, c1 can be set to 0.7, c2 to 0.3, and c3 to 0. For high-density crowd scenarios, c1 can be set to 0.6, c2 to 0.3, and c3 to 0.1. For example, in a high-density crowd scenario, when the terminal's own device ID = 150, the remaining power parameter = 85%, and the communication bandwidth parameter = 20Mbps, the current emergency broadcast transmission terminal's status score A = 150 × 0.6 + 85 × 0.3 + 20 × 0.1 = 117.5.

[0047] In an optional embodiment of the present invention, step 1322, comparing the status score received by each emergency broadcast transmission terminal with its current status score to obtain a comparison result, may include:

[0048] Step 13221: Each emergency broadcast transmission terminal sends an election negotiation broadcast message to other transmission terminals in the election terminal group, using its own status score and its own device ID as comparison information.

[0049] Step 13222: After receiving the election negotiation broadcast message, all emergency broadcast transmission terminals in the election terminal group compare the received status score information with their own status score. If the received status score is greater than their own status score, the current emergency broadcast transmission terminal fails to elect and enters silent mode. After a preset time, the terminals that have not entered silent mode are output as the comparison results.

[0050] In an optional embodiment of the present invention, step 1323, based on the comparison result, designating the emergency broadcast transmission terminal with the highest status score as the main terminal of the current basic terminal group, may include:

[0051] Step 13231: Determine whether the output comparison result is a single emergency broadcast transmission terminal. If it is a single terminal, directly use the current emergency broadcast transmission terminal as the main terminal of the current basic terminal group. If it is multiple terminals, compare the device IDs of each emergency broadcast transmission terminal in each comparison result and output the terminal with the largest device ID as the main terminal.

[0052] In an optional embodiment of the present invention, step 14 may specifically establish a connection between the main terminal and the emergency broadcasting platform. Specifically, the main terminal initiates a connection request to the emergency broadcasting platform, and the platform responds upon receiving the request, establishing a connection through a handshake. The platform sends a message to the main terminal, specifying the multicast IP address for forwarding audio broadcast data (or allowing the main terminal to determine it independently). After receiving the message, the main terminal completes the connection path establishment and obtains the corresponding emergency broadcast information through the established path. The main terminal uses the RTSP protocol to call the FFMPEG API interface through the URL sent by the platform to receive the audio broadcast data sent by the platform and stores the data in the relay service station to prevent data loss.

[0053] In an optional embodiment of the present invention, step 15, which involves sending the emergency broadcast information from the main terminal to the slave terminals within their respective basic terminal groups, and simultaneously sending it to their respective corresponding client terminals, may include:

[0054] Step 151: Perform task analysis on the received emergency broadcast information through the main terminal to obtain the analysis results corresponding to the emergency broadcast information;

[0055] Step 152: Based on the analysis results and the cooperative channel evaluation list, perform channel allocation processing on the emergency broadcast information to determine the transmission channel corresponding to the emergency broadcast information;

[0056] Step 153: Based on the transmission channel, the master terminal sends the emergency broadcast information to the slave terminals in its respective basic terminal group in advance according to the preset transmission delay, and simultaneously sends it to their respective client terminals; wherein, the cooperative channel evaluation list is determined by performing channel evaluation on all terminals in the basic terminal group; the preset transmission delay is determined by performing response tests on all slave terminals in the basic terminal group and the client terminals covered by the current master terminal.

[0057] In this embodiment, the multi-terminal collaborative emergency broadcast transmission control method improves channel utilization, reduces channel congestion, and achieves efficient, reliable, accurate, and sustained emergency information dissemination by accurately matching channel resources and uniformly allocating transmission channels according to different broadcast task types such as voice and video.

[0058] In an optional embodiment of the present invention, step 151, which involves performing task analysis on the received emergency broadcast information through the main terminal to obtain the analysis results corresponding to the emergency broadcast information, may include:

[0059] Step 1511: Based on the specific parameters of the received emergency broadcast information, perform task analysis on the received emergency broadcast information to determine the task type corresponding to the current emergency broadcast information, and output the task type as the analysis result; wherein, the specific parameters include the data volume and priority of the received emergency broadcast information; the task type is a high-priority small data task and a high-priority big data task.

[0060] In this embodiment, the amount of data received in the emergency broadcast information can be determined based on the data size. Small data includes broadcasts of small amounts of data such as voice and text, which can be propagated using the 2.4GHz frequency band, which has low frequency, low attenuation, and long propagation distance. Large data includes broadcasts of large amounts of data such as high-definition video, which can be propagated using the 5GHz frequency band, which has large single-channel bandwidth, high transmission rate, and less interference. The priority of the received emergency broadcast information can be set according to requirements.

[0061] In this embodiment, the multi-terminal collaborative emergency broadcast transmission control method determines the task type corresponding to different data volumes of broadcast information to accurately match the corresponding channel resources, thereby improving channel utilization, reducing channel congestion, and thus improving the stability of transmission quality.

[0062] In an optional embodiment of the present invention, step 152, which involves performing channel allocation processing on the emergency broadcast information based on the analysis results and the cooperative channel evaluation list to determine the transmission channel corresponding to the emergency broadcast information, may include:

[0063] Step 1521: Based on the analysis results and the cooperative channel evaluation list, assign high-priority small data tasks to channels in the 2.4 GHz band of the cooperative channel evaluation list with a cooperative channel state factor greater than or equal to 0.7.

[0064] Step 1522: Assign high-priority big data tasks to continuous or discontinuous channels in the 5GHz band of the cooperative channel evaluation list where the cooperative channel state factor is greater than or equal to 0.6.

[0065] In this embodiment, when allocating channels, if a completely matching channel cannot be found, a channel that is close to the cooperative channel state factor can be selected first. For example, if a high-priority big data task cannot find a channel with a cooperative channel state factor greater than or equal to 0.6 in the cooperative channel evaluation list, a channel with a cooperative channel state factor closest to 0.6 can be found, such as a channel with a cooperative channel state factor of 0.5.

[0066] In an optional embodiment of the present invention, step 152, which involves performing channel allocation processing on the emergency broadcast information based on the analysis results and the cooperative channel evaluation list to determine the transmission channel corresponding to the emergency broadcast information, further includes:

[0067] Step 1523: Obtain the load rate and status factor of the allocated transmission channel in real time. When the load rate is greater than 80% or the status factor is lower than the threshold, perform channel switching on the transmission channel.

[0068] In this embodiment, a channel switching notification is sent to all terminals in the group before the channel switching to ensure uninterrupted transmission; wherein, the load rate of the transmission channel is determined by... in, Let g be the real-time load rate of transmission channel g at time t. Let g be the amount of data actually transmitted through the transmission channel g in the period preceding time t. The rated transmission capacity of transmission channel g;

[0069] The state factor of the transmission channel is expressed by the formula It is confirmed that, among them, Let g be the real-time state factor of the transmission channel g at time t. The real-time link quality factor of transmission channel g. The real-time packet loss rate of transmission channel g. , These are the weighting coefficients.

[0070] In this embodiment, the load rate is used to measure the current channel's busyness and congestion level. The more transmission services, the longer the data packets, and the longer the time spent in the actual transmission process, the higher the calculated load rate. By averaging the ratio values ​​sampled multiple times within a period, a stable channel load rate can be obtained. The closer the value is to 1, the more congested the channel, and the more likely transmission stuttering and packet loss will occur. The channel state factor reflects the current usability and stability of the channel. The closer the value is to 1, the better the channel quality and the more suitable it is for carrying emergency broadcast data. By real-time detection of the channel load rate and state factor, the current channel transmission status can be determined, thereby enabling channel switching and further ensuring the stability of the transmission channel during transmission.

[0071] In an optional embodiment of the present invention, step 153, based on the transmission channel, the master terminal sends the emergency broadcast information in advance to the slave terminals in its respective basic terminal group according to a preset transmission delay, and simultaneously sends it to their respective corresponding client terminals. This may include:

[0072] Step 1531: Before the main terminal prepares to broadcast broadcast data, it retrieves data from the relay service station in advance by a preset transmission delay time and broadcasts the multicast IP address to the slave terminal to ensure that the slave terminal accurately receives the data according to the specified IP address; at the same time, based on the location data of the main terminal, an adjustable push range of 100 meters to 5 kilometers is defined with the location of the main terminal as the axis, and the broadcast content is pushed only to civilian terminals, i.e., client terminals within the range.

[0073] In an optional embodiment of the present invention, determining the cooperative channel evaluation list by performing channel evaluation on all terminals within the basic terminal group may include:

[0074] Step 1541: Perform a synchronous scan of all terminals in the basic terminal group to determine the accessible channel corresponding to each terminal.

[0075] Step 1542: Obtain the channel parameters of the accessible channels for each terminal in the basic terminal group within a preset time period.

[0076] Step 1543: Based on the channel parameters, determine the non-cooperative channel state factor for each terminal in the basic terminal group to the accessible channels;

[0077] Step 1544: Determine the cooperative channel state factor of the link corresponding to each terminal based on the non-cooperative channel state factor of each terminal for the accessible channel.

[0078] Step 1545: Determine the cooperative channel evaluation list based on the cooperative channel state factor.

[0079] In this embodiment, step 1541 specifically includes the main terminal initiating a channel evaluation command, and all terminals in the group synchronously scanning accessible channels (including the 2.4GHz and 5GHz frequency bands) to determine the accessible channel corresponding to each terminal; a full channel evaluation is performed every 10 minutes, and an immediate evaluation is triggered if the channel packet loss rate is >30%; in this embodiment, the preset time is the scanning period, which is 10 minutes, and the channel parameters include: the average number of data packets received by the terminal on the accessible channel, the maximum number of data packets that can be received within a preset time under ideal channel conditions, the active duration of the accessible channel within the preset time, and the packet loss rate of the accessible channel.

[0080] In an optional embodiment of the present invention, step 1543, determining the non-cooperative channel state factor for each terminal in the basic terminal group to the accessible channel based on the channel parameters, may include:

[0081] Based on the channel parameters, through Determine the non-cooperative channel state factor of the accessible channel for each terminal within the basic terminal group. ;in, This represents the non-cooperative channel state factor of terminal n for accessible channel x; This represents the average number of data packets received by terminal n on the accessible channel x within a preset time period. This represents the maximum number of data packets that can be received within a preset time under ideal channel conditions. The active duration of accessible channel x within a preset time period. The preset total duration, The packet loss rate is the data packet loss rate of the accessible channel x. , , These are the preset weighting coefficients.

[0082] In an optional embodiment of the present invention, step 1544, determining the cooperative channel state factor of the link corresponding to each terminal based on the non-cooperative channel state factor of each terminal for the accessible channel, may include:

[0083] Based on the non-cooperative channel state factor of each terminal for the accessible channels, using the formula... Determine the cooperative channel state factor of the link corresponding to each terminal. ;in, This represents the non-cooperative channel state factor of terminal n pairs within the basic terminal group that can access channel x; This represents the non-cooperative channel state factor of the receiving terminal m corresponding to terminal n within the basic terminal group, for the accessible channel x. This represents the cooperative channel state factor value of the link corresponding to terminal n, that is, the cooperative channel state factor value of the link between transmitting terminal n and receiving terminal m.

[0084] In this embodiment, the multi-terminal collaborative emergency broadcast transmission control method can accurately match channel resources according to different broadcast task types such as voice and video by using the collaborative channel state factor to quantify channel quality.

[0085] In an optional embodiment of the present invention, step 1545, determining the cooperative channel evaluation list based on the cooperative channel state factor, may include:

[0086] Step 15451, based on the cooperative channel state factor, using the formula Determine the overall quality score for each accessible channel within the basic terminal group; among which, This represents the overall quality score of the accessible channel x; This represents the total number of links within the group. This represents the cooperative channel state factor value of the link corresponding to terminal n;

[0087] Step 15452: Construct a cooperative channel evaluation list based on the overall quality score of the accessible channels and the frequency band of each accessible channel.

[0088] In this embodiment, the collaborative channel evaluation list is constructed based on the comprehensive quality score of the accessible channels and the frequency band of each accessible channel. Specifically, all channels are sorted from high to low according to their comprehensive quality values, and the channels are divided into three levels: excellent, available, and restricted, according to a preset threshold. At the same time, the channel frequency band, real-time load rate, and adapted task type are labeled. Finally, the sorting results, level, frequency band, load, adapted task, and other information are organized into a structured list to form a collaborative channel evaluation list that can be directly used for channel allocation. The main terminal matches the optimal channel for different broadcast tasks based on this list.

[0089] In an optional embodiment of the present invention, step 15, which determines the preset transmission delay by performing response tests on all slave terminals within the basic terminal group and the client terminals covered by the current master terminal, includes:

[0090] Step 1551: The master terminal sends a delay measurement broadcast request message to all slave terminals and covered client terminals in the current basic terminal group, and receives a response message for each delay measurement broadcast request message.

[0091] Step 1552: The main terminal determines the one-way transmission delay corresponding to each delay measurement broadcast request message based on the time corresponding to sending the delay measurement broadcast request message and the time corresponding to receiving the response message.

[0092] Step 1553: Determine the preset transmission delay based on the unidirectional transmission delay.

[0093] In this embodiment, by designing a preset transmission delay, the time delay between the master terminal and the slave terminal during data forwarding can be further eliminated, thereby further realizing the unified management and synchronous transmission of emergency broadcast information and ensuring the consistency of terminal data transmission delay. In this embodiment, in step 1552, the master terminal determines the one-way transmission delay t corresponding to each delay measurement broadcast request message according to the time corresponding to sending the delay measurement broadcast request message and the time corresponding to receiving the response message, using the formula t=(t2-t1) / 2; where t2 is the time corresponding to receiving the response message; and t1 is the time corresponding to sending the delay measurement broadcast request message.

[0094] In this embodiment, step 1553, determining the preset transmission delay based on the one-way transmission delay, may include:

[0095] Based on the aforementioned one-way transmission delay, using the formula Calculate the average one-way transmission delay of the main terminal, i.e., the preset transmission delay. Where N represents the total number of slave terminals and client terminals associated with the master terminal; Indicates the first The delay measurement is the one-way transmission delay corresponding to the broadcast request message.

[0096] In an optional embodiment of the present invention, step 15, which involves sending the emergency broadcast information from the master terminal to the slave terminals within their respective basic terminal groups, and simultaneously sending it to their respective corresponding client terminals, further includes:

[0097] Step 154: When the master terminal sends the emergency broadcast information to the slave terminals in its respective basic terminal group, it selects slave terminals with remaining power greater than or equal to the second preset power value and communication power consumption lower than the first preset power value as cooperative nodes. The master terminal fragments the broadcast data and forwards it to the slave terminals in its respective basic terminal group through multiple cooperative nodes, and sends it to their respective client terminals at the same time as the slave terminals, thereby balancing the load and reducing the energy consumption of the master terminal; the second preset power value is 40%.

[0098] In this embodiment, the main terminal can construct a four-dimensional dynamic evaluation model of "power consumption - energy recovery capability - channel quality - power supply type", with the weights adjusted to 70% remaining power consumption, 20% energy recovery capability, and 10% channel status. Terminals with continuous external power supply (solar energy, hand-cranked generator) and ≥60% remaining power consumption are prioritized as cooperative nodes. Cooperative nodes can also be classified into core relay nodes, which must meet the following requirements: ≥60% remaining power consumption, ≤40mW communication power consumption, ≥-65dBm signal strength, ≥0.7 channel status factor, and stable energy recovery capability; and ordinary relay nodes, which must meet the following requirements: 40%-60% remaining power consumption, ≤50mW communication power consumption, ≥-70dBm signal strength, and 0.6-0.7 channel status factor. Terminals with three consecutive transmission delay fluctuations exceeding 50ms and a channel status factor below 0.5 are directly removed from the cooperative node pool to avoid energy waste.

[0099] In this embodiment, the main terminal can strictly adapt to weak network and low-power scenarios through data fragmentation algorithms. The fragment size is uniformly set to 256KB-512KB, each fragment has an independent checksum, supports breakpoint resumption, and only retransmits lost fragments without retransmitting the entire fragment, thus reducing retransmission energy consumption. The channel selection implements a 2.4GHz low-frequency band priority strategy, and only enables the 5GHz band in close-range scenarios with sufficient power, avoiding the problems of high power consumption and weak wall penetration of high-frequency bands. A minimum energy consumption path algorithm is added, which prioritizes the multi-hop path with the lowest total transmission energy consumption during forwarding, rather than the shortest distance path. For example, if the total energy consumption of a two-hop path is 30% lower than that of a one-hop path, the two-hop path is automatically selected, maximizing terminal power saving even if the transmission distance is longer. After each round of fragment transmission, the main terminal re-evaluates the total energy consumption of each path and dynamically adjusts the forwarding path to ensure the lowest energy consumption for the entire group.

[0100] In an optional embodiment of the present invention, step 155, which involves sending the emergency broadcast information from the master terminal to the slave terminals within their respective basic terminal groups, and simultaneously sending it to their respective corresponding client terminals, further includes:

[0101] The collaboration weight is dynamically adjusted based on the remaining battery power of the slave terminals. Slave terminals with high battery power undertake more forwarding tasks, while slave terminals with low battery power only receive data. For slave terminals that do not currently have receiving tasks, they are controlled to enter a low-power sleep mode, retaining only the status monitoring and wake-up receiving modules. When there is a new task, they are quickly activated by a wake-up signal.

[0102] In this embodiment, the collaboration weight is dynamically adjusted based on the remaining battery power of the terminals. This is a dynamic scheduling mechanism where the master terminal assigns a corresponding collaboration weight to each terminal based on the remaining battery power reported by each slave terminal in real time. The master terminal continuously collects and judges the battery level of the terminals, increasing the collaboration weight for terminals with sufficient battery power, decreasing the weight for terminals with low battery power, and canceling the weight for terminals with insufficient battery power. This ensures that the weight is positively correlated with the remaining battery power, achieving a balanced distribution of load and energy consumption within the group. During task execution, terminals with high battery power have higher weights and are assigned more tasks such as data fragmentation forwarding and channel collaborative monitoring, making full use of their battery life to support group transmission. Terminals with low battery power automatically reduce or cancel forwarding tasks, retaining only core functions such as emergency broadcast data reception, reducing unnecessary energy consumption, avoiding failures due to overload power consumption, and ensuring the stable operation of the entire system for a long time in emergency scenarios. This solves the problems of existing systems not considering the balance of energy consumption of emergency terminals, the susceptibility of single terminals to failure due to excessive load, and the lack of low-power management strategies for idle terminals, resulting in insufficient overall battery life and difficulty in meeting the long-term reliable operation requirements of emergency scenarios such as earthquake relief and flood control.

[0103] The following is a specific embodiment illustrating the detailed implementation process of step 15 in this invention, in which the main terminal sends the emergency broadcast information to the slave terminals within their respective basic terminal groups, and simultaneously the slave terminals send the information to their respective corresponding client terminals:

[0104] First, the average delay of the main terminal completing one-way transmission. After calculation, the forwarding timing planning process is initiated; during the countdown phase for broadcasting its own data, it is done in advance. The system triggers data extraction commands from relay service stations based on time, ensuring precise timing matching between data forwarding and its own broadcast. The data extraction process employs a priority scheduling mechanism, prioritizing the extraction of high-emergency-level audio and text core data, followed by auxiliary data such as video, thus avoiding delays in core information transmission. Before forwarding, the system can dynamically adjust the forwarding timing strategy based on the scenario: for general scenarios, a unified timing forwarding strategy is used; for high-density concurrent scenarios (e.g., ≥500 terminals in a single group), concurrent timing segmentation scheduling is enabled, dividing terminals into multiple parallel sub-queues based on type, access network, and receiving capability, with each sub-queue having a 5ms fixed interval. Timing offsets are used to form a tiered forwarding sequence; for example, 1000 terminals are divided into 10 queues, with adjacent queues offset by 5ms, resulting in a total synchronization error of ≤50ms and reducing the instantaneous signaling pressure on the main terminal by 90%; for extreme unreliable scenarios (such as no network or fixed facilities): a delay-tolerant and interrupt-tolerant store-carry-forward (DTN) mechanism is enabled; the main terminal fragments and encrypts the data to multiple relay nodes, and the nodes automatically synchronize when they meet through the wireless ad hoc network; the synchronization fault tolerance window is widened to 200ms, prioritizing 100% information reachability; even if a node is offline for more than 24 hours and then comes back online, it can still automatically synchronize the untransmitted data;

[0105] During forwarding, the system implements differentiated forwarding based on terminal type and scenario. For general or high-concurrency scenarios, the main terminal uses multicast technology to bind multicast IP addresses with broadcast data before forwarding. The RTSP protocol is used to ensure audio continuity, and timestamps are embedded to ensure that the audio synchronization error of all dedicated terminals is ≤30ms. For high-concurrency scenarios, a distributed synchronization check can be added. The main terminal sends a baseline synchronization packet, and only terminals with abnormal synchronization status report to the main terminal; normal terminals do not need to provide feedback, reducing the main terminal's verification burden by 85%. For extreme unreliable scenarios, it is reconstructed as an AdHoc wireless self-organizing network multi-hop forwarding system, supporting up to 8 hops of relays, with the path automatically bypassing faulty nodes. A lightweight design is employed. The RTSP protocol reduces header overhead by 40% and achieves a synchronization error of ≤200ms. During forwarding, it can also perform dual-link transmission for civilian terminals (mobile phones, computers, etc.). The main terminal uses network status parameters in the terminal registration information to determine the local area network (LAN) access status of civilian terminals in real time. If the terminal is already connected to the same group of LANs, it is marked as "LAN priority" and data is pushed directly through the LAN multicast channel with latency controlled within 50ms. If no LAN connection is detected, it automatically switches to "mobile network fallback" mode, accessing the 4G / 5G network via a transceiver for data push. When the LAN reconnects from a disconnection, link switching is immediately triggered. Specifically, link status monitoring is configured. A timer (100ms cycle) monitors the stability of the current transmission link in real time. When the local area network recovers from a disconnection, it immediately triggers a link switch. During the switch, a caching mechanism retains untransmitted data fragments to prevent content interruption or duplication. After the switch is completed, a synchronization calibration command is sent, and civilian terminals adjust their playback progress according to the command to ensure a playback time difference of ≤50ms with dedicated terminals. When forwarding, the main terminal uses its own precise coordinates obtained from the locator, combined with the push range parameters (adjustable from 100 meters to 5 kilometers) issued by the emergency broadcasting platform, to generate a dynamic push area using a geofencing algorithm. It supports setting various area shapes such as circles and rectangles to adapt to different emergency scenarios (such as disaster relief). (Scope, large-scale event venues, etc.); Simultaneously, the main terminal sends location verification requests to all terminals within the coverage area, and the terminals return their own real-time location data after receiving the requests; the main terminal verifies whether the terminal is within the designated range using a distance calculation algorithm (based on the Haversine formula of latitude and longitude coordinates), and only sends broadcast data to terminals with valid locations, reducing the bandwidth and energy consumed by invalid transmissions; when pushing data, a three-level priority identifier is attached (level 1 is for life safety, level 2 is for emergency notification, and level 3 is for general prompts). After receiving the data, the LED display screen automatically adjusts the display strategy according to the priority. Level 1 priority content is directly covered in full screen, while level 2 and level 3 priority content is displayed superimposed according to preset rules;

[0106] During forwarding, both the master and slave terminals send a forced push command to the mobile terminal through a collaborative transmission channel between the mobile network and the local area network. The command triggers a system-level pop-up window on the mobile phone (covering all application interfaces) and simultaneously starts audio playback (the volume is set to the upper-middle level of the system by default, and users can manually fine-tune it). The pop-up window only has a "read" confirmation button and no close option. The pop-up window disappears after the user confirms, and continues to be displayed and repeats the playback every 30 seconds if the user does not confirm, to ensure that the information is delivered.

[0107] To address the differences between Android (Android 8.0 and above) and iOS (iOS 12.0 and above) systems, differentiated push interfaces are pre-defined: Android terminals: By combining system notification permissions with background services, pop-up windows can be kept running and audio broadcasts can be played, supporting direct triggering of display in the lock screen state; iOS terminals: Utilizing APNs push services, combined with local application plugins, pop-up windows can be forcibly displayed and audio wake-up can be achieved, adapting to the iOS system's permission management mechanism; If the mobile terminal does not receive the push data within 30 seconds, the main terminal will automatically resend, with a maximum of 3 resends; If it is still not received, the terminal ID will be recorded and reported to the emergency broadcasting platform, which can supplement the push with core emergency information via SMS.

[0108] For computer terminals, a lightweight network push plugin needs to be pre-installed, supporting mainstream systems such as Windows and macOS. The plugin runs continuously in the background. Upon receiving a push command from the main terminal, it immediately triggers a desktop pop-up (centered and non-minimizable) and simultaneously connects to the system volume control module, automatically adjusting to a preset appropriate volume (default 50%, with manual adjustment supported by the user) to play the audio. The pop-up includes elements such as the emergency information title, content, release time, and confirmation button. After the user clicks "Confirm Receipt," the pop-up closes and the audio stops. If the user does not interact, the pop-up continues to display for 10 minutes before automatically shrinking to the system tray, while retaining the audio playback until the user confirms. The plugin supports logging, automatically saving reception records (including reception time, information content, and confirmation status) for easy traceability. The plugin's operating mechanism is optimized for different browsers, office software, and other commonly used applications to avoid conflicts with other applications during the push process. Remote plugin upgrades are supported; the main terminal can send upgrade commands to enable plugin function iteration and vulnerability patching.

[0109] After forwarding, the terminal's current playback sequence can be synchronized and calibrated according to the synchronization calibration mechanism. Specifically, the calibration command includes information such as the terminal's current playback progress and timestamp offset. After receiving the command, the civilian terminal quickly adjusts its playback sequence using a local clock calibration algorithm. For audio data, frame alignment technology is used to ensure audio-visual synchronization. For text and video data, timestamp matching is used to achieve synchronized content display. Specifically, the dedicated slave terminal continuously listens to the master terminal's push data through a preset multicast IP address. After receiving the data, the hardware decoding module quickly parses the audio and video data streams, with decoding latency controlled within 20ms. It supports multiple mainstream encoding formats (such as MP3, H.264, etc.) to ensure data compatibility.

[0110] The main terminal sets a synchronization verification timer (period of 2 seconds) to periodically send synchronization verification packets containing information such as the current playback frame number, timestamp, and link delay offset. After receiving the verification packet from the terminal, it compares it with its current playback status. If a frame offset or timestamp difference is detected (threshold 5ms), the calibration process is immediately started to adjust the playback progress and avoid cumulative delay deviation after long-term playback.

[0111] The terminal provides real-time feedback to the main terminal on playback status (such as playing, paused, abnormal, etc.), signal strength, decoding success rate, and other data. The main terminal judges the terminal's working status based on the feedback data. If an abnormality is detected (such as no feedback for 3 consecutive times or decoding success rate below 90%), it is marked as a faulty terminal and a backup terminal is activated to take over the work.

[0112] During the process of sending the emergency broadcast information from the main terminal to the slave terminals within their respective basic terminal groups, and simultaneously sending it to their corresponding client terminals, the main terminal can also optimize its energy consumption based on needs and the current environment. Specifically, the main terminal collects parameters such as the remaining battery power, communication energy consumption, and signal strength of the slave terminals in real time to establish a multi-dimensional evaluation model; it sets collaboration thresholds: remaining battery power ≥ 40%, communication energy consumption ≤ 50mW, and signal strength ≥ -70dBm, and only selects terminals that meet all thresholds as candidate collaboration nodes; it calculates the comprehensive score of the candidate nodes based on the evaluation model (battery power weight 60%, energy consumption weight 30%, signal strength weight 10%), sorts them in descending order of score, and selects the top 30%. The system uses at least two nodes as official collaborating nodes to ensure redundancy. An adaptive fragmentation algorithm is employed to dynamically divide the broadcast data into fragments based on its size and type. Small data volumes (text and audio, ≤10MB) are divided into 2-4 fragments, while large data volumes (video, >10MB) are divided into 8-16 fragments. Each fragment is controlled to be 1-2MB in size for easy transmission and retransmission. Fragmentation tasks are allocated based on the collaborative nodes' overall scores, with higher-scoring nodes receiving more fragments. For example, the highest-scoring node receives 30% of the total fragments, the second-highest receives 25%, and so on, to avoid overloading any single node. After each round of fragment transmission, node status parameters are re-collected, the overall score is updated, and the fragmentation allocation ratio for the next round is dynamically adjusted. A collaborative node status monitoring cycle (500ms) is set to monitor the node's transmission status in real time. If a node experiences a transmission timeout (failure to report fragmentation completion within 500ms) or its battery level drops below 30%, it will be immediately marked as "temporarily unavailable," and a backup collaborating node will be activated to take over its unfinished fragmentation tasks. Once the node recovers (transmission resumes or battery level is replenished to ≥40%), it will be reinstated into the collaborating node pool.

[0113] For the remaining slave terminals, the hibernation level can be determined by a decision tree algorithm based on the terminal's task status (idle / working) and remaining battery power: when the terminal currently has no receiving / forwarding tasks and the remaining battery power is ≥20%, it is determined to be in a light hibernation state; non-core modules such as data decoding and audio playback are turned off, and only the core receiving modules (such as multicast monitoring and signal detection) and positioning modules are kept working, with a response time ≤100ms and static power consumption reduced to 30% of the normal working state;

[0114] When the terminal has no current task and the remaining battery level is between 10% and 20%, it is determined to be in a moderate sleep state. All functional modules except the positioning module and the wake-up receiver module are turned off. The positioning module adopts a low-power mode (the positioning cycle is extended to 10 seconds), and the wake-up receiver module only listens to specific wake-up frequency signals, with a response time ≤500ms. Static power consumption is reduced to 15% of the normal operating state.

[0115] When the terminal has no current task and the remaining battery power is less than 10%, it is determined to be in deep sleep mode. Only the emergency wake-up channel is retained (controlled by a dedicated low-power chip), and all non-essential functions such as positioning and communication are suspended, reducing static power consumption to 5% of the normal operating state. The terminal briefly wakes up once every 60 seconds to check for an emergency wake-up signal. If there is no signal, it continues to sleep. Upon receiving a wake-up signal, it completes full-function startup within 1 second and resumes normal operating state.

[0116] After the terminal enters sleep mode, it sends a 1-byte simplified status message to the main terminal every 30 seconds through the simplified communication module. The message contains core information such as battery level and sleep level. After receiving the message, the main terminal establishes a "terminal-channel-energy consumption" association ledger to track the energy consumption changes of each terminal and the channel load status in real time.

[0117] When a new broadcast task arrives, a wake-up command (including task priority, transmission channel, etc.) is sent through the main terminal. Upon receiving the command, the terminal corresponding to the hibernation level initiates the wake-up process, restoring functional modules in priority order to ensure timely data reception. For example, for Level 1 emergency tasks (life safety-related, such as evacuation orders and disaster warnings), a high-frequency wake-up signal is sent. Terminals in deep hibernation complete full-function startup within 100ms, prioritizing the use of 2.4GHz high channel state factor (η≥0.7) channel resources. This frequency band has low channel attenuation and long propagation distance, ensuring data achieves maximum coverage with minimal power consumption, buying time for life safety. For Level 2 (emergency notification, such as material allocation and road condition information) / Level 3 (general notification, such as post-disaster reconstruction notifications) emergency tasks, a general wake-up signal is used. Terminals in medium hibernation start within 500ms, and terminals in deep / ultra-deep hibernation start within 2s. Only the 2.4GHz general channel is adapted to avoid high-priority channels being occupied by non-critical wake-ups, reducing unnecessary power consumption.

[0118] like Figure 2 As shown, embodiments of the present invention also provide an emergency broadcast terminal transmission control system 20, comprising:

[0119] The acquisition module 201 is used to acquire the installation location information of all emergency broadcast transmission terminals and the status data of each emergency broadcast transmission terminal;

[0120] The data processing module 202 is used to group the emergency broadcast transmission terminals according to the installation location information of all emergency broadcast transmission terminals to determine multiple basic terminal groups; to perform master-slave terminal election processing for each basic terminal group according to the status data of each emergency broadcast transmission terminal to determine the master terminal and slave terminal in each basic terminal group; to receive emergency broadcast information issued by the emergency broadcast platform through the master terminal in each basic terminal group; and to send the emergency broadcast information to the slave terminals in their respective basic terminal groups through the master terminal, and simultaneously send it to their respective corresponding client terminals.

[0121] Optionally, based on the installation location information of all emergency broadcast transmission terminals, the emergency broadcast transmission terminals are grouped to determine multiple basic terminal groups, including:

[0122] All emergency broadcast transmission terminals are grouped together according to their installation location information. Multiple emergency broadcast transmission terminals installed within the same preset installation location range are grouped together to obtain multiple basic terminal groups.

[0123] Optionally, based on the status data of each emergency broadcast transmission terminal, a master-slave terminal election process is performed for each basic terminal group to determine the master and slave terminals within each basic terminal group, including:

[0124] Based on the status data of each emergency broadcast transmission terminal and the first preset condition, the emergency broadcast transmission terminals in each basic terminal group are grouped to obtain the election terminal group and the auxiliary terminal group.

[0125] Based on preset rules and the status data of each emergency broadcast transmission terminal in the election terminal group, terminal election processing is performed on the emergency broadcast transmission terminals in the election terminal group to determine the master terminal of the current basic terminal group.

[0126] The remaining emergency broadcast transmission terminals in the election terminal group and the emergency broadcast transmission terminals in the auxiliary terminal group are all designated as slave terminals.

[0127] Optionally, based on preset rules and the status data of each emergency broadcast transmission terminal within the election terminal group, a terminal election process is performed on the emergency broadcast transmission terminals within the election terminal group to determine the current master terminal of the basic terminal group, including:

[0128] Based on the first preset weight, the second preset weight, and the third preset weight, the status data of each emergency broadcast transmission terminal in the election terminal group is scored to determine the status score of each emergency broadcast transmission terminal in the election terminal group.

[0129] The status score received by each emergency broadcast transmission terminal is compared with its current status score to obtain the comparison result;

[0130] Based on the comparison results, the emergency broadcast transmission terminal with the highest status score is selected as the master terminal of the current basic terminal group. Each of the elected terminal groups retains one master terminal. When there are multiple emergency broadcast transmission terminals with the same status score in the comparison results, the one with the largest device mark is selected as the master terminal.

[0131] Optionally, the emergency broadcast information is sent from the main terminal to the slave terminals within their respective basic terminal groups, and simultaneously sent to their respective corresponding client terminals, including:

[0132] The main terminal performs task analysis on the received emergency broadcast information to obtain the analysis results corresponding to the emergency broadcast information.

[0133] Based on the analysis results and the cooperative channel evaluation list, channel allocation processing is performed on the emergency broadcast information to determine the transmission channel corresponding to the emergency broadcast information;

[0134] Based on the transmission channel, the master terminal sends the emergency broadcast information to the slave terminals in its respective basic terminal group in advance according to the preset transmission delay, and simultaneously sends it to its corresponding client terminal along with the slave terminals.

[0135] The cooperative channel evaluation list is determined by performing channel evaluation on all terminals within the basic terminal group.

[0136] The preset transmission delay is determined by performing response tests on all slave terminals within the basic terminal group and the client terminals covered by the current master terminal.

[0137] Optionally, a collaborative channel evaluation list is determined by performing channel evaluation on all terminals within the basic terminal group, including:

[0138] Perform a synchronous scan of all terminals within the basic terminal group to determine the accessible channel for each terminal;

[0139] Obtain the channel parameters of the accessible channels for each terminal in the basic terminal group within a preset time period;

[0140] Based on the channel parameters, determine the non-cooperative channel state factor for each terminal in the basic terminal group to the accessible channels;

[0141] Based on the non-cooperative channel state factor of each terminal for the accessible channel, determine the cooperative channel state factor of the link corresponding to each terminal.

[0142] Based on the cooperative channel state factor, a cooperative channel evaluation list is determined.

[0143] Based on the channel parameters, determine the non-cooperative channel state factor for each terminal in the basic terminal group to the accessible channels, including:

[0144] pass Determine the non-cooperative channel state factor of the accessible channel for each terminal within the basic terminal group. ;

[0145] in, This represents the non-cooperative channel state factor of terminal n for accessable channel x; This represents the average number of data packets received by terminal n on the accessible channel x within a preset time period. This represents the maximum number of data packets that can be received within a preset time under ideal channel conditions. The active duration of accessible channel x within a preset time period. The preset total duration, The packet loss rate is the data packet loss rate of the accessible channel x. , , These are the preset weighting coefficients.

[0146] Optionally, the preset transmission delay is determined by performing response tests on all slave terminals within the basic terminal group and the client terminals covered by the current master terminal, including:

[0147] The master terminal sends latency measurement broadcast request messages to all slave terminals and covered client terminals within the current basic terminal group, and receives response messages from each latency measurement broadcast request message.

[0148] The main terminal determines the one-way transmission delay corresponding to each delay measurement broadcast request message based on the time corresponding to sending the delay measurement broadcast request message and the time corresponding to receiving the response message;

[0149] The preset transmission delay is determined based on the unidirectional transmission delay.

[0150] It should be noted that this system corresponds to the method described above, and all implementations in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effect. Further details are omitted in this embodiment.

[0151] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0152] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0153] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0154] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0155] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0156] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0157] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0158] Furthermore, it should be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of the present invention.

[0159] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

[0160] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A multi-terminal collaborative emergency broadcast transmission control method, characterized in that, The method, applied to an emergency broadcast terminal transmission control system, includes: Obtain the installation location information of all emergency broadcast transmission terminals and the status data of each emergency broadcast transmission terminal; Based on the installation location information of all emergency broadcast transmission terminals, the emergency broadcast transmission terminals are grouped to determine multiple basic terminal groups; Based on the status data of each emergency broadcast transmission terminal, a master-slave terminal election process is performed for each basic terminal group to determine the master terminal and slave terminal in each basic terminal group. Each basic terminal group receives emergency broadcast information from the emergency broadcast platform through its main terminal. The main terminal sends the emergency broadcast information to the slave terminals in their respective basic terminal groups, and simultaneously sends it to their respective client terminals.

2. The multi-terminal collaborative emergency broadcast transmission control method according to claim 1, characterized in that, Based on the installation location information of all emergency broadcast transmission terminals, the emergency broadcast transmission terminals are grouped to determine multiple basic terminal groups, including: All emergency broadcast transmission terminals are grouped together according to their installation location information. Multiple emergency broadcast transmission terminals installed within the same preset installation location range are grouped together to obtain multiple basic terminal groups.

3. The multi-terminal collaborative emergency broadcast transmission control method according to claim 1, characterized in that, Based on the status data of each emergency broadcast transmission terminal, a master-slave terminal election process is performed for each basic terminal group to determine the master and slave terminals within each basic terminal group, including: Based on the status data of each emergency broadcast transmission terminal and the first preset condition, the emergency broadcast transmission terminals in each basic terminal group are grouped to obtain the election terminal group and the auxiliary terminal group. Based on preset rules and the status data of each emergency broadcast transmission terminal in the election terminal group, terminal election processing is performed on the emergency broadcast transmission terminals in the election terminal group to determine the master terminal of the current basic terminal group. The remaining emergency broadcast transmission terminals in the election terminal group and the emergency broadcast transmission terminals in the auxiliary terminal group are all designated as slave terminals.

4. The multi-terminal collaborative emergency broadcast transmission control method according to claim 3, characterized in that, Based on preset rules and the status data of each emergency broadcast transmission terminal within the election terminal group, terminal election processing is performed on the emergency broadcast transmission terminals within the election terminal group to determine the current master terminal of the basic terminal group, including: Based on the first preset weight, the second preset weight, and the third preset weight, the status data of each emergency broadcast transmission terminal in the election terminal group is scored to determine the status score of each emergency broadcast transmission terminal in the election terminal group. The status score received by each emergency broadcast transmission terminal is compared with its current status score to obtain the comparison result; Based on the comparison results, the emergency broadcast transmission terminal with the highest status score is selected as the master terminal of the current basic terminal group. Each of the elected terminal groups retains one master terminal. When there are multiple emergency broadcast transmission terminals with the same status score in the comparison results, the one with the largest device mark is selected as the master terminal.

5. The multi-terminal collaborative emergency broadcast transmission control method according to claim 1, characterized in that, The emergency broadcast information is sent from the main terminal to the slave terminals within their respective basic terminal groups, and simultaneously sent to their respective client terminals by the slave terminals, including: The main terminal performs task analysis on the received emergency broadcast information to obtain the analysis results corresponding to the emergency broadcast information. Based on the analysis results and the cooperative channel evaluation list, channel allocation processing is performed on the emergency broadcast information to determine the transmission channel corresponding to the emergency broadcast information; Based on the transmission channel, the master terminal sends the emergency broadcast information to the slave terminals in its respective basic terminal group in advance according to the preset transmission delay, and simultaneously sends it to its corresponding client terminal along with the slave terminals. The cooperative channel evaluation list is determined by performing channel evaluation on all terminals within the basic terminal group. The preset transmission delay is determined by performing response tests on all slave terminals within the basic terminal group and the client terminals covered by the current master terminal.

6. The multi-terminal collaborative emergency broadcast transmission control method according to claim 5, characterized in that, A collaborative channel evaluation list is determined by performing channel evaluation on all terminals within the basic terminal group, including: Perform a synchronous scan of all terminals within the basic terminal group to determine the accessible channel for each terminal; Obtain the channel parameters of the accessible channels for each terminal in the basic terminal group within a preset time period; Based on the channel parameters, determine the non-cooperative channel state factor for each terminal in the basic terminal group to the accessible channels; Based on the non-cooperative channel state factor of each terminal for the accessible channel, determine the cooperative channel state factor of the link corresponding to each terminal. Based on the cooperative channel state factor, a cooperative channel evaluation list is determined.

7. The multi-terminal collaborative emergency broadcast transmission control method according to claim 6, characterized in that, Based on the channel parameters, determine the non-cooperative channel state factor for each terminal in the basic terminal group to the accessible channels, including: pass Determine the non-cooperative channel state factor of the accessible channel for each terminal within the basic terminal group. ; in, This represents the non-cooperative channel state factor of terminal n for accessible channel x; This represents the average number of data packets received by terminal n on the accessible channel x within a preset time period. This represents the maximum number of data packets that can be received within a preset time under ideal channel conditions. The active duration of accessible channel x within a preset time period. The preset total duration, The packet loss rate is the data packet loss rate of the accessible channel x. , , These are the preset weighting coefficients.

8. The multi-terminal collaborative emergency broadcast transmission control method according to claim 5, characterized in that, The preset transmission delay is determined by conducting response tests on all slave terminals within the basic terminal group and the client terminals covered by the current master terminal, including: The master terminal sends latency measurement broadcast request messages to all slave terminals and covered client terminals within the current basic terminal group, and receives response messages from each latency measurement broadcast request message. The main terminal determines the one-way transmission delay corresponding to each delay measurement broadcast request message based on the time corresponding to sending the delay measurement broadcast request message and the time corresponding to receiving the response message; The preset transmission delay is determined based on the unidirectional transmission delay.

9. An emergency broadcast terminal transmission control system, characterized in that, include: The acquisition module is used to acquire the installation location information of all emergency broadcast transmission terminals and the status data of each emergency broadcast transmission terminal; The data processing module is used to group the emergency broadcast transmission terminals according to the installation location information of all emergency broadcast transmission terminals to determine multiple basic terminal groups; Based on the status data of each emergency broadcast transmission terminal, a master-slave terminal election process is performed for each basic terminal group to determine the master terminal and slave terminal in each basic terminal group. Each basic terminal group receives emergency broadcast information from the emergency broadcast platform through its main terminal. The main terminal sends the emergency broadcast information to the slave terminals in their respective basic terminal groups, and simultaneously sends it to their respective client terminals.

10. A computing device, characterized in that, include: A processor and a memory, wherein the memory stores a computer program that, when run on the processor, performs the method as described in any one of claims 1 to 8.

Images