Emergency communication method based on Beidou No.3

Abstract

The invention relates to an emergency communication method based on Beidou No.3, which can be used for transmitting voice, images and videos (RDSS, Radio Determination Service, Satellite Radio Determination Service) by using a Beidou RDSS (Radio Determination Service). The common characteristic of the voice, the image and the video is that the data volume is relatively large, and the byte number of single RDSS communication is limited. In order to realize rapid transmission, the method disclosed by the invention makes efforts from three aspects of compressing the transmitted content, improving the single-time transmission capability and adopting a subpackage transmission mechanism. In addition, in order to ensure the reliability of communication, a re-sending mechanism and a strong splicing mechanism are added in the sub-packet sending process. According to the invention, the communication reliability can be effectively improved, the communication means are enriched, and the user experience is enhanced.

Description

Technical Field

[0001] The present invention relates to the field of Beidou communication technology, and in particular to an emergency communication method based on Beidou-3. Background Art

[0002] In the field of Beidou communications, satellite communications are mainly used in situations where 4G / 5G signals are relatively weak, such as when natural disasters such as floods and earthquakes damage basic communication facilities. At least in this special case, it is particularly necessary to achieve emergency communications through Beidou RDSS communication technology (RDSS, Radio Determination Satellite Service). However, the existing equipment based on Beidou RDSS communication mainly transmits text, and the communication success rate cannot be effectively guaranteed due to the Beidou RDSS communication success rate. In addition, due to the limitation of the single communication length in the existing Beidou RDSS communication, it is impossible to send content with relatively large amounts of data such as voice, images, and videos, which may make it impossible to fully describe the crisis environment in which users are in an emergency state. Summary of the invention

[0003] In view of the defects or shortcomings in the prior art, the present invention provides an emergency communication method based on BeiDou-3, so as to effectively improve the reliability of communication, enrich the means of communication, and enhance the user experience.

[0004] The technical solution of the present invention is as follows:

[0005] An emergency communication method based on BeiDou-3, characterized in that it comprises the following steps:

[0006] Step 1: The emergency communication user enters the information to be sent in the sending interface of the emergency communication APP software on the communication terminal, and the emergency communication APP software establishes a Bluetooth connection with the Beidou-3 emergency terminal device;

[0007] Step 2, performing data compression processing on the information to be sent, and performing packet processing on the compressed data to obtain a series of data packets with packet numbers;

[0008] Step 3, each data packet enters the first interface queue in turn;

[0009] Step 4, send the current data sub-packet, display the send dialog box, and update the progress bar;

[0010] Step 5, determine whether all data subpackets have been sent. If not, return to step 4 to send the next data subpacket. If yes, proceed to step 6;

[0011] Step 6, display the send dialog box and wait for receipt;

[0012] Step 7, determine whether a receipt is received, if not, proceed to step 11, if yes, proceed to step 8;

[0013] Step 8, determine whether the data sub-packet needs to be resent, if not, close the send / re-send dialog box, prompt that the communication is successful and end the communication, if yes, go to step 9;

[0014] Step 9, start the resend mechanism, display the resend dialog box, resend the data packet, and update the progress bar;

[0015] Step 10, determine whether the resending is completed, if not, return to step 9 to resend the next data sub-packet, if yes, display the resending dialog box, wait for the receipt, and return to step 7;

[0016] Step 11, determine whether the waiting timeout has occurred, if not, continue waiting, if yes, proceed to step 12;

[0017] Step 12, close the send / re-send dialog box, prompt the communication failure and end the communication.

[0018] The data compression process in step 2 includes one or a combination of the following: voice compression, image compression, and video compression. The voice compression adopts the speex audio compression method, the image compression adopts the jp2000 compression method, and the video compression adopts the format conversion method.

[0019] The packet processing in step 2 is to packetize the transmission content according to the data length based on the single communication capacity.

[0020] Each data packet in step 2 contains key user information.

[0021] Step 4 includes identifying the following parameters in the data packet transmission: the total number of packets, the current number of packets, the information type, and the estimated transmission time.

[0022] The message receiving process in the BeiDou-3 command and management software is as follows:

[0023] Step A1, the command management software that has been in the message receiving state, after receiving the message subpacket, determines whether the subpacket number is 1. If the subpacket number is 1, it calculates the total message transmission time of this communication according to the total number of subpackets in the message and the sending time of a single subpacket given in the message, and caches the received message subpacket in the receiving queue and receives the next message subpacket. If the subpacket number is not 1, it directly caches the received message subpacket in the receiving queue;

[0024] Step A2, determining whether all message subpackets are received, if yes, then splicing all message subpackets into a complete message and displaying it, clearing the receiving queue, and entering step A3, if no, then entering step A4;

[0025] Step A3, after storing the complete message in the database, the message receiving process ends;

[0026] Step A4: If the next message sub-packet is received within the waiting time that does not exceed the transmission time, then return to step A1; if the waiting time exceeds the transmission time, it means that the sub-packet has not been completely received, then the resending and forced concatenation process is entered.

[0027] The reissue and forced order process includes the following steps:

[0028] Step B1, determine whether the current communication is ended. If the current communication is not ended, continue the information communication. If the current communication is ended, proceed to step B2;

[0029] Step B2, judge the content of the received information, and judge whether the number of sub-packet losses exceeds the set threshold. If yes, directly force the package to be spliced ​​and displayed, and then enter step B7. Forced package splicing is to splice the sub-packet message content in order according to the sub-packet number in the sub-packet. For the sub-packet that has not been received, it is supplemented with default data, and the information after forced splicing of the sub-packet is displayed according to the information type. Since each sub-packet contains the user's key information, not only the forced package information is displayed, but also the user's key information is displayed, thereby improving the effectiveness of communication. If no, enter step B3;

[0030] Step B3, sending a reissue command, and calculating the reissue countdown time according to the number of reissued subpackets;

[0031] Step B4, receiving the resent sub-packet message;

[0032] Step B5, determine whether the reissue countdown time is zero, if not, return to step B4, if yes, go to step B6;

[0033] Step B6, judging whether all sub-packages are collected, if yes, displaying the sub-package information together, if not, displaying the sub-packages together;

[0034] Step B7, clearing the receiving queue, writing the complete message composed of all displayed sub-packet information or the forced message formed by forced packet assembly into the database, and then ending the resending and forced assembly process.

[0035] Use BeiDou RDSS to transmit voice, images and videos.

[0036] The technical effects of the present invention are as follows: The present invention is an emergency communication method based on BeiDou-3, which can use BeiDou RDSS to transmit voice, images and videos (RDSS, Radio Determination Satellite Service). The common feature of voice, image and video is that the data volume is relatively large, while the number of bytes of a single RDSS communication is limited. In order to achieve fast transmission, the present invention makes efforts in three aspects: one is to compress the transmission content, the second is to improve the single transmission capacity, and the third is to adopt a packet transmission mechanism. In addition, in order to ensure the reliability of communication, the present invention adds a retransmission and forced concatenation mechanism in the packet sending process. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a schematic diagram of the information packet sending process in the emergency communication APP software involved in the implementation of the emergency communication method based on Beidou-3 of the present invention. Figure 1The method comprises step 1, wherein an emergency communication user inputs information to be sent in a sending interface of the emergency communication APP software on the communication terminal, and the emergency communication APP software establishes a Bluetooth connection with the BeiDou-3 emergency terminal device; step 2, performing data compression processing on the information to be sent, and performing packet processing on the compressed data to obtain a series of data packets with packet numbers; step 3, each data packet enters the first interface queue in turn; step 4, sending the current data packet, displaying a sending dialog box, and updating a progress bar; step 5, determining whether all data packets have been sent, if not, returning to step 4 to send the next data packet, if yes, entering step 6; step 6, displaying a sending dialog box, and waiting for a receipt; step Step 7, determine whether a receipt is received, if not, go to step 11, if yes, go to step 8; Step 8, determine whether the data subpacket needs to be resent, if not, close the send / re-send dialog box, prompt the communication is successful and end the communication, if yes, go to step 9; Step 9, start the re-send mechanism, display the re-send dialog box, and update the progress bar; Step 10, determine whether the re-send is completed, if not, return to step 9 to re-send the next data subpacket, if yes, display the re-send dialog box, wait for the receipt, and return to step 7; Step 11, determine whether the waiting timeout, if not, continue to wait, if yes, go to step 12; Step 12, close the send / re-send dialog box, prompt the communication failure and end the communication. The data compression processing in step 2 includes one or a combination of the following: voice compression, image compression, and video compression. The voice compression adopts the speex audio compression method, the image compression adopts the jp2000 compression method, and the video compression adopts the format conversion method. The packet processing in step 2 is to packetize the transmission content according to the data length based on the single communication capacity. Each data packet in step 2 contains user key information. Step 4 includes identifying the following parameters in the data packet transmission: total number of packets, current number of packets, information type, and expected transmission time.

[0038] Figure 2 The present invention is a schematic diagram of a message receiving process in a BeiDou-3 command machine command management software involved in an emergency communication method based on BeiDou-3 according to the present invention. Figure 2The command management software which has been in the message receiving state, after receiving the message sub-packet, determines whether the sub-packet number is 1, if the sub-packet number is 1, then calculates the transmission time of all messages in this communication according to the total number of sub-packets in the message and the sending time of a single sub-packet given in the message, and caches the received message sub-packet in the receiving queue and then receives the next message sub-packet, if the sub-packet number is not 1, then directly caches the received message sub-packet in the receiving queue; step A2, determines whether all message sub-packets are received, if yes, then splices all message sub-packets into a complete message and displays it, then clears the receiving queue and enters step A3, if not, then enters step A4; step A3, stores the complete message in the database and ends the message receiving process; step A4, if the next message sub-packet is received in the waiting time that does not exceed the transmission time, then returns to step A1, if the waiting time exceeds the transmission time, it means that the sub-packet is not completely received, then enters the resending and forced splicing process.

[0039] Figure 3 It is a schematic diagram of the re-issuance and forced concatenation process involved in implementing an emergency communication method based on Beidou-3 of the present invention. Figure 3 The process includes step B1, judging whether the current communication is over. If the current communication is not over, the information communication is continued. If the current communication is over, the process proceeds to step B2. Step B2, judging the content of the received information, judging whether the number of sub-packet losses exceeds the set threshold. If so, the process proceeds to step B7 after the forced package splicing is performed. The forced package splicing is to splice the sub-packet message content in sequence according to the sub-packet number in the sub-packet. For the sub-packets that are not received, the default data is supplemented. The information after the forced splicing of the sub-packets is displayed according to the information type. Since each sub-packet contains the user's key information, not only the information of the forced package splicing is displayed, but also the user's key information is displayed. key information is displayed, thereby improving the effectiveness of communication. If not, proceed to step B3; step B3, send a reissue command, and calculate the reissue countdown time according to the number of reissued subpackets; step B4, receive the reissued subpacket message; step B5, determine whether the reissue countdown time is zero, if not, return to step B4, if yes, proceed to step B6; step B6, determine whether all subpackets are received, if yes, display the subpacket information in splicing, if not, force the splicing to display; step B7, clear the receiving queue, write the complete message of all the displayed subpacket information splicing or the forced message formed by forced splicing into the database, and then end the reissue and forced splicing process. DETAILED DESCRIPTION

[0040] Below is the attached figure ( Figure 1-Figure 3 ) and Examples illustrate the present invention.

[0041] Figure 1It is a schematic diagram of the information packet sending process in the emergency communication APP software involved in the implementation of the emergency communication method based on Beidou-3 of the present invention. Figure 2 The present invention is a schematic diagram of a message receiving process in a BeiDou-3 command machine command management software involved in an emergency communication method based on BeiDou-3 according to the present invention. Figure 3 This is a schematic diagram of the re-issuance and forced concatenation process involved in implementing an emergency communication method based on Beidou-3 of the present invention. Figures 1 to 3 As shown, the present invention aims at the situation that the existing equipment based on Beidou RDSS communication mainly transmits text and the success rate of Beidou RDSS communication cannot be effectively guaranteed. A method for ensuring communication reliability is proposed to solve the problem of communication reliability and realize the function of transmitting voice, image and video using this system.

[0042] The purpose of the present invention is to solve the reliability problem existing in the Beidou RDSS communication process, as well as the problem that the content with large data volume such as voice, image, video, etc. cannot be sent due to the limitation of the length of a single communication.

[0043] 1. As the content previously transmitted by Beidou RDSS was mainly text messages, the data content displayed by text messages was limited. In order to make the transmitted content richer and more clearly reflect the current crisis environment, it is proposed to use Beidou RDSS to transmit voice, images and videos. The common feature of voice, images and videos is that the data volume is relatively large, while the number of bytes of a single RDSS communication is limited. In order to achieve fast transmission, efforts need to be made in three aspects: first, compress the transmitted content, second, improve the single transmission capacity, and third, adopt a packet transmission mechanism.

[0044] In terms of compressed transmission content, the present invention adopts different compression methods for different transmission modes, adopts Speex audio compression method for voice transmission, adopts jp2000 compression method for image compression, and adopts format conversion method for video compression. The compression method is used to reduce the size of voice, image, and video files for easy transmission.

[0045] In terms of improving the single transmission capability, the BeiDou-3 RDSS communication chip is used to capture the BeiDou-3 RDSS signal frequency for communication, thereby improving the single communication capability.

[0046] Even after the above compression, when the transmission content exceeds the single transmission capacity, a packetization mechanism is required during the transmission process. The transmission content is packetized according to the data length and the single communication capacity. The total number of packets, the current number of packets, the type of information to be sent, the estimated transmission time, etc. are identified in the packet sending.

[0047] 2. In order to ensure the reliability of communication, a retransmission and forced consolidation mechanism is added during the subpacket sending process.

[0048] The retransmission mechanism is that after the receiving end receives the information, it determines whether the communication is over based on the total number of packets and the expected sending time. If the communication is over, it determines the packet number lost in the communication, packages the lost packet number and sends it to the sending end. The receiving end waits to receive the lost information according to the required sending time; after the sending end receives the lost packet number, it sends the lost information to the receiving end. After the receiving end receives the retransmitted information packet, it splices the information, parses and displays it.

[0049] The forced concatenation mechanism is to prevent the entire system receiving end or sending end from being in a dead waiting state. When a communication failure occurs, the sending end cannot communicate after sending. The receiving end waits according to the estimated communication time and number of packets sent by the sending end. When the waiting time is up, whether it is received completely or not, forced concatenation is performed, the information after forced concatenation is displayed, and the end of this communication is marked. For the sending end, it is also stipulated that if the receipt information is not received within the agreed time, the communication will be exited and considered to have failed. A second communication can be initiated.

[0050] 3. The emergency communication system consists of four parts: Beidou-3 command machine equipment, Beidou-3 emergency terminal equipment, emergency communication APP software, and command management software. Beidou-3 emergency terminal equipment is used in conjunction with the emergency communication APP software. The emergency communication APP software and Beidou-3 emergency communication terminal are connected using Bluetooth. The emergency communication APP software can send and receive text, voice, images, and videos; the command management software is used in conjunction with Beidou-3 command machine equipment to realize the reception, display, storage, and terminal management of text, voice, image, and video information. The emergency communication APP software realizes the function of sending information in packets. The information packet sending process is as follows Figure 1 shown.

[0051] Figure 1 The emergency communication APP software information sending process is shown, and the steps are as follows:

[0052] Step 1: The user uses the emergency communication APP software to input the information to be sent in the software sending interface to determine whether the Bluetooth connection between the emergency communication APP software and the Beidou-3 emergency terminal device is successful. If the Bluetooth connection is successful, enter step 2 of the sub-packaging processing flow.

[0053] Step 2: First, compress the data. For voice transmission, the speex audio compression method is used. For image compression, the jp2000 compression method is used. For video compression, the format conversion method is used. Then, the compressed data is packetized according to the total length of the content to be sent and the maximum byte length that can be sent in a single packet. Since the use environment is an emergency communication environment, it is required that key information be included in the transmitted information as much as possible. When inputting information, users are required to enter key information. When packetizing, key information is included in each packet. After the packetization is completed, the packetization and sending process of step 3 is entered.

[0054] Step 3: According to the total number of sub-packets, send them one by one according to the sub-packet number. After the sub-packet is sent, send the next sub-packet until all sub-packets are sent. After the sub-packet is sent, enter the receipt waiting process and determine whether the waiting time has timed out. If not, enter step 4 to wait for feedback. If it has timed out, enter step 6 to prompt the communication result.

[0055] Step 4: When receiving the feedback receipt, determine whether the feedback receipt content needs to be re-sent. If it is necessary to re-send the sub-package, proceed to step 5 to re-send the sub-package. Otherwise, proceed to step 6 to prompt the communication result.

[0056] Step 5: Determine whether the sub-package to be re-sent has been sent. If not, send the next sub-package. After all the re-sent sub-packages have been sent, return to step 4 and wait for the receipt process.

[0057] Step 6: If the waiting time does not expire and a receipt is received that does not need to be resent, it indicates that all information has been sent, and the communication is successful. If the waiting time expires and no feedback receipt is received, the communication fails.

[0058] Figure 2 The command management software receives the message process, and the steps are as follows:

[0059] Step 1: The command management software is always in the message receiving state. After receiving the message sub-packet, it determines whether the sub-packet number is 1. If the sub-packet number is 1, the total message transmission time of this communication is calculated according to the total number of sub-packets in the message and the single sub-packet sending time given in the message. At the same time, the received message is cached in the receiving queue. If the sub-packet number is not 1, the received message is directly cached in the receiving queue. Then enter step 2 to wait for the timeout judgment.

[0060] Step 2: Determine whether the waiting time exceeds the transmission time. If it does not exceed the transmission time, proceed to step 3 to determine whether the sub-packet is fully received. If it exceeds the transmission time, it means that the sub-packet is not fully received, and then enter the resend and forced consolidation process.

[0061] Step 3: Determine whether the sub-packet is completely received. If it is completely received, the message is spliced ​​and displayed and stored in the database. If it is not completely received, wait for reception.

[0062] Figure 3 The process of reissue and forced reissue is shown, and the steps are as follows.

[0063] Step 1: Determine whether the current communication has ended. If the current communication has ended, determine the content of the received message and proceed to step 2 for resending and forcing. If the current communication has not ended, continue the message communication.

[0064] Step 2: Determine whether the number of lost subpackets is large and exceeds the set threshold. If the number of lost subpackets is large, directly force the subpackets to be spliced. Forced splicing is to splice the subpacket message content in order according to the subpacket sequence number in the subpacket. For the subpackets that have not been received, they are supplemented with default data, and the information after forced splicing is displayed according to the information type. Since each subpacket contains user key information, in addition to displaying the forced splicing information, the user key information is also displayed, thereby improving the effectiveness of communication; if the number of lost subpackets does not exceed the set threshold, enter step 3 to resend the information process.

[0065] Step 3: First send a resend command, and calculate the resend countdown time according to the number of resend sub-packages. Determine whether the resend countdown time has expired. If not, continue to wait for receiving resend sub-package information. If the time has expired, determine whether the sub-packages have been received. If they have been received, perform splicing and display of the sub-packages; if not, perform forced splicing.

[0066] Since a single message transmission takes a long time, the retransmission mechanism makes up for the defect that all messages need to be sent again when the information is not fully received. Only the missing messages are sent, which shortens the communication time and improves the communication reliability. In the case of a large number of packet losses or unsuccessful retransmission (this situation indicates that the signal quality is poor and the communication may not be good again), the message is forced to be spliced. Since the key information that the user needs to send is added to each sub-packet information during the sub-packetization, the key information of the user can be obtained even if some information is lost during forced splicing. This effectively ensures the accurate transmission of emergency key information in emergency communications.

[0067] The present invention can effectively improve the reliability of communication, enrich the means of communication, and enhance the user experience.

[0068] The contents not described in detail in the specification belong to the prior art known to the professional and technical personnel in the field. It is pointed out here that the above description helps those skilled in the art to understand the invention, but does not limit the protection scope of the invention. Any equivalent replacement, modification and / or simplification of the above description that does not deviate from the essence of the invention falls within the protection scope of the invention.

Claims

1. An emergency communication method based on BeiDou-3, characterized in that: The following steps are involved: Step 1: The emergency communication user enters the information to be sent in the sending interface of the emergency communication APP software on the communication terminal, and the emergency communication APP software establishes a Bluetooth connection with the Beidou-3 emergency terminal device; Step 2, performing data compression processing on the information to be sent, and performing packet processing on the compressed data to obtain a series of data packets with packet numbers; Step 3, each data packet enters the first interface queue in turn; Step 4, send the current data sub-packet, display the send dialog box, and update the progress bar; Step 5, determine whether all data subpackets have been sent. If not, return to step 4 to send the next data subpacket. If yes, proceed to step 6; Step 6, display the send dialog box and wait for receipt; Step 7, determine whether a receipt is received, if not, proceed to step 11, if yes, proceed to step 8; Step 8, determine whether the data sub-packet needs to be resent, if not, close the send / re-send dialog box, prompt that the communication is successful and end the communication, if yes, go to step 9; Step 9, start the resend mechanism, display the resend dialog box, resend the data packet, and update the progress bar; Step 10, determine whether the resending is completed, if not, return to step 9 to resend the next data sub-packet, if yes, display the resending dialog box, wait for the receipt, and return to step 7; Step 11, determine whether the waiting timeout has occurred, if not, continue waiting, if yes, proceed to step 12; Step 12, close the send / re-send dialog box, prompt the communication failure and end the communication.

2. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: The data compression process in step 2 includes one or a combination of the following: voice compression, image compression, and video compression. The voice compression adopts the speex audio compression method, the image compression adopts the jp2000 compression method, and the video compression adopts the format conversion method.

3. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: The packet processing in step 2 is to packetize the transmission content according to the data length based on the single communication capacity.

4. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: Each data packet in step 2 contains key user information.

5. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: Step 4 includes identifying the following parameters in the data packet transmission: the total number of packets, the current number of packets, the information type, and the estimated transmission time.

6. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: The message receiving process in the BeiDou-3 command and management software is as follows: Step A1, the command management software that has been in the message receiving state, after receiving the message subpacket, determines whether the subpacket number is 1. If the subpacket number is 1, it calculates the total message transmission time of this communication according to the total number of subpackets in the message and the sending time of a single subpacket given in the message, and caches the received message subpacket in the receiving queue and receives the next message subpacket. If the subpacket number is not 1, it directly caches the received message subpacket in the receiving queue; Step A2, determining whether all message subpackets are received, if yes, then splicing all message subpackets into a complete message and displaying it, clearing the receiving queue, and entering step A3, if no, then entering step A4; Step A3, after storing the complete message in the database, the message receiving process ends; Step A4: If the next message sub-packet is received within the waiting time that does not exceed the transmission time, then return to step A1; if the waiting time exceeds the transmission time, it means that the sub-packet has not been completely received, then the resending and forced concatenation process is entered.

7. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: The reissue and forced order process includes the following steps: Step B1, determine whether the current communication is ended. If the current communication is not ended, continue the information communication. If the current communication is ended, proceed to step B2; Step B2, judge the content of the received information, and judge whether the number of sub-packet losses exceeds the set threshold. If yes, directly force the package to be spliced ​​and displayed, and then enter step B7. Forced package splicing is to splice the sub-packet message content in order according to the sub-packet number in the sub-packet. For the sub-packet that has not been received, it is supplemented with default data, and the information after forced splicing of the sub-packet is displayed according to the information type. Since each sub-packet contains the user's key information, not only the forced package information is displayed, but also the user's key information is displayed, thereby improving the effectiveness of communication. If no, enter step B3; Step B3, sending a reissue command, and calculating the reissue countdown time according to the number of reissued subpackets; Step B4, receiving the resent sub-packet message; Step B5, determine whether the reissue countdown time is zero, if not, return to step B4, if yes, go to step B6; Step B6, judging whether all sub-packages are collected, if yes, displaying the sub-package information together, if not, displaying the sub-packages together; Step B7, clearing the receiving queue, writing the complete message composed of all displayed sub-packet information or the forced message formed by forced packet assembly into the database, and then ending the resending and forced assembly process.

8. The BeiDou-3-based emergency communication method according to claim 1, characterized in that: Use BeiDou RDSS to transmit voice, images and videos.

Images