{'fraction_non_alphanumeric': 0.025627669548911346, 'fraction_numerical': 0.007709136368371706, 'mean_word_length': 4.914972273567468, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 1, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Design of COSPAS-SARSAT Beacon with BDS Return Link Service

This article describes a proto-type beacon, which supports search and rescue (SAR) return link service (RLS) provided by BeiDou Satellite Navigation System (BDS). According to the design of signal-in-space format of BDS RLS, with related technologies from COSPAS-SARSAT, comparing with Galileo RLS system, this article describes a design of BDS RLS beacon proto-type, and how it receives and processes return link message (RLM). Then three interfaces are analysed, which are the GNSS signal interface from the BDS satellite to the GNSS receiver, the GNSS receiver sentence interface from the GNSS receiver to the beacon processing unit and the human-machine interaction interface for the beacon to the user. Finally, its test result and cost-performance trade-off are discussed.


Introduction
COSPAS-SARSAT is a successful global satellite search and rescue (SAR) system. To contribute to COSPAS-SARSAT, BDS also provide SAR service [1]. The working principle of the traditional 406MHz satellite SAR service is simple. A beacon transmits at 406MHz the alert signal, which is forwarded to the ground segment by SAR payload carried by satellites to complete the transmission of the alert. It is a one-way communication from the user in distress to SAR authorities. As one component of the BDS SAR service, BDS return link service (RLS) is being tested. By sending a return link message (RLM) to the beacon via BDS navigation message, the BDS RLS provides the possibility of two-way interaction for search and rescue. Through RLS, SAR authorities can send some useful information to the user in distress, such as acknowledgements, or information related to search and rescue progress. Our previous work includes the design of BDS RLS system [2] [3], releasing its signal interface from satellite [4]. Since the BDS RLM is broadcasted through navigation message, a special beacon is designed to test BDS RLS system and its service. This article mainly describes the design of such beacon prototype that supports BDS RLS.

Design Concept
COSPAS-SARSAT has put forward the most basic requirements for the existing beacons, including basic alert signal format, coding method, modulation method and transmission frequency, transmission time, internal GNSS receiver, etc.  Figure 1. Design block of the beacon. The beacon needs to have an internal GNSS receiver to calculate its position. As BDS RLM is also broadcasted via satellite navigation message, the GNSS receiver should receive and process the RLM. The microcontroller controls the transmitter module to transmit alert signal and processes the data from GNSS receiver, including the positioning of the beacon which will be contained in the alert signal, and relevant RLM. Display circuit includes an display and a buzzer, which are used for audible and visual alarms to inform the user of the current beacon status and displaying some useful RLM.
The key point of BDS RLS beacon is receiving and processing BDS RLM. Since Galileo already launched its RLS with its related beacon [5] [6], the study on Galileo RLS system with its beacon is conducted first.

Study on Galileo RLS System and Its BEACON
From the information provided by Galileo, combined with BDS RLS scheme, the following table shows the mechanism differences between BDS and Galileo RLS. Human-machine Interaction Figure 2. Structure of signal flow and interface. According to the working flow of BDS RLS, the beacon contains three interactive interfaces to receive and process RLM from BDS satellite. These interfaces are: navigation signal interface from the BDS satellite to GNSS receiver; GNSS receiver output sentence interface from GNSS receiver to the beacon processing unit (MCU); and human-machine interface for beacon to user for interaction.

BDS B2b Navigation Signal Interface
The first layer is the navigation signal interface, which mainly uses GNSS receivers to receive navigation messages broadcasted by major GNSS systems, including ephemeris and other information used to determine the current position of the receiver. In particular, because the RLM frame is broadcasted in B2b signal, the GNSS receiver needs to have the ability to receive and decode the RLM within the B2b signal broadcasted by the BDS MEO satellite and IGSO satellite. The RLM is packaged in a return link dedicated frame with independent message type (MesType). The data packaging method of RLM is shown in the figure below.  The specific frame structure is described in that interface control document. The internal processing module of the GNSS receiver needs to be able to process and output the return link message according to the requirements of the interface control document. Since there is no shelf product that supports BDS RLS in the market, in this article, a FPGA is temporarily used to process and output navigation messages.

GNSS Receiver Output Sentence Interface
The second is GNSS receiver output sentence interface. Most GNSS receivers use NMEA-0183 (National Marine Electronics Association-0183) format to output GNSS related information to microcontroller through electrical interfaces such as Universal asynchronous receiver-transmitter (UART); or receive some instructions from the microcontroller. According to our participation and tracking of the discussion of the relevant International Electrotechnical Committee (IEC) working groups, the IEC has already published the second part of the IEC61097-2 Global maritime distress In the above statement, hhhhhhhhhhhhhhh is the beacon ID, which is a 15-characters hexadecimal code; hhmmss.ss is the time when GNSS receiver receives a RLM from satellite; next h is the message type, with 1 as the acknowledgement service RLM, 2 as the command service RLM, and 3 as message service RLM; h--h is the actual message content transmitted from RLM, expressed in hexadecimal code, and the actual content of this part needs to be processed by the beacon microcontroller; *hh is the check bit. The RLM sentence in the NMEA-0183 format abstracts the RLM from BDS or Galileo systems, and the interoperability sentence is completed at this level. Beacon micro-controller only needs to process the standard sentences, without paying attention to the RLM source satellite navigation system. In the beacon described in this article, the FPGA compiles the RLM from received B2b signal, and sends it to the beacon's microcontroller in NMEA-0183 format. The micro-controller will process the RLM statement. Since RLM is not encrypted, FPGA will output all RLMs it received, including some RLMs to be sent to other beacons. The micro-controller should determine whether the return link message is sent to itself or other beacons, based on the beacon ID, which is loaded in the beacon manufacturer. With its standard interface, a NMEA-0183 format sentence can also be sent to other devices for processing.

Human-Machine Interface
The third layer is human-machine interface, which is an interactive interface between beacon and user. According to the COSPAS-SARSAT requirements, all beacons must be equipped with a trigger for initiating or cancelling the alert. In order to support the most basic return link confirmation service (message type 1), the BDS return link beacon should be equipped with a LED or buzzer to indicate if the beacon has received the confirmation from SAR authorities, and give light or sound prompts to users. In particular, due to the special design of BDS type-3 RLM [4], BDS return link can transmit plain text information. The beacon described in this article is also equipped with an OLED screen and can display relevant characters. The plain text information is encoded in UTF-8, hence the message is also compatible with multiple languages.

Discussion
A simple reception test shows that the beacon is able to receive BDS RLM with 100% success rate. The LED can be trigged after the reception of RLM from satellites, demonstrating that the beacon is ready for use in future system performance testing. Mass production of beacons needs to be considered. BDS RLM is broadcasted via B2b signal, which means the internal GNSS receiver must support receiving BDS B2b signal, literally a dual-bands receiver. Galileo system uses common single band E1-B signal to broadcast RLM. There are some GNSS receiver on the market that support Galileo RLS as shelf products. The price of dual-band GNSS receivers currently on the market is higher than single-frequency GNSS receivers. However, bitrate of B2b navigation message is higher than that of B1C navigation message, which improves the cold start positioning speed of the GNSS receiver. BDS RLM-supported beacons are used to conduct a B2b positioning test, and the result shows that the first positioning time of the GNSS receiver using B2b signal cold start is about 6 seconds, the horizontal error is 2.7 meters, and the vertical error is 4.9 meters (95% confidence, number of satellites=9, PDOP=1.1) [3]. A shorter GNSS first-lock time will improve the efficiency of beacon to obtain its position, thereby improves the efficiency of search and rescue operations, hence the trade-off between higher price and enhanced positioning can be accepted.

Conclusion
From three interfaces, this article basically describes a design of BDS RLS-supported beacon, and how the beacon receives and processes RLM from BDS satellites. In future work, this beacon will be used to conduct delay and capability tests of BDS RLS. We are looking forward to gathering more data from the tests on BDS RLM-supported beacons.