Analysis of the Galileo SAR Return Link Service Using the GalileoSARlib Open-Source Library ^†

Abstract

The Galileo Search and Rescue (SAR) service is the contribution from the European constellation to the international Cospas–Sarsat system. This system uses a variety of space and ground infrastructure to detect and localize distress signals from beacons on the 406 MHz frequency. Satellites in different orbits detect the signals coming from the Earth and transmit them back to Earth stations that route them to the appropriate government authorities. On top of the standard detection and relay service, the Galileo constellation is the first to offer a Return Link Service (RLS) that acknowledges the processing of the distress signal with a Return Link Message (RLM) back to the originating beacon. This RLM is transmitted in the SAR field of the E1 signal I/NAV message, which allocates 20 bits every 2 s page. Therefore, transmitting a short RLM (80 bits) takes four consecutive pages or eight seconds. Moreover, each RLM is transmitted in parallel from two Galileo satellites. The RLS has been active since 2020, avoiding the spotlight of the GNSS community. This paper presents an analysis of the SAR Return Link Messages extracted from more than 3 months of signal-in-space data to investigate the current bandwidth use, monitor the type of SAR usage, and detect anomalies in the service. To extract and parse the Return Link Messages, we have developed and published an open-source Python library called GalileoSARlib on GitHub, which is also detailed in the paper.

1. Introduction

The international Cospas–Sarsat (C/S) system is a free-of-charge satellite Search and Rescue (SAR) system for distress signals from emergency beacons in the 406 MHz frequency. The C/S system employs a network of satellites and ground infrastructure to locate the alert signal and communicate with the relevant authorities. This international effort dramatically improves response times and coordination efficiency during emergencies, especially in situations where traditional communication systems are not available.

The C/S program started in 1979, and was originally composed by low Earth orbit (LEO) satellites and four participating countries: Canada, France, the USA, and the former USSR. The system has evolved over the years, moving from analog to digital emergency signals and from a few LEO satellites to constellations of LEO, MEO, and GEO satellites. The use of digital alert signals permitted to encode GNSS coordinates in the distress message, which allowed to not rely only on the Doppler-based location used in the early days of C/S. However, the increase in the number of satellites substantially improved the accuracy and detection time for the Doppler-based method. Currently, more than 40 countries and organizations are members of the C/S initiative.

The Galileo SAR service, which is part of our analysis, is part of the medium Earth orbit SAR (MEOSAR) constellations. The interaction between the MEOSAR components is illustrated in Figure 1. The emergency beacons may be Emergency Locator Transmitters (ELTs) for aviation applications, Emergency Position Indication Radio Beacons (EPIRBs) for maritime applications, and Personal Location Beacons (PLBs) for personal purposes. All beacons transmit a signal at 406 MHz that is received by antennas in the MEOSAR satellites. Then, the MEOSAR satellites relay this information to the Local User Terminals (MEOLUTs) which aggregate the information in the mission control center. This capability of picking up ground distress signals and transmitting them to ground stations is called forward link service. The mission control center decides the next steps to follow after the reception of the distress signal, which may be to contact the appropriate rescue authorities and alert the distress beacon of the correct reception of the signal.

Figure 1. Description of the elements conforming the MEOSAR system and the sequence of actions followed during a distress signals reception. Illustration extracted from [1].

The communication back to the originating beacon is part of the new SAR capabilities of C/S, and it has become firstly available in Galileo. The Galileo Return Link Service (RLS) automatically communicates to the user of a distress beacon the detection of the alert signal and the correct determination of their location. This service is identified as Acknowledgment Type-1 Return Link Message (RLM) in [2]. The RLS is broadcast in several pages of the Galileo open E1-B signal I/NAV message, and therefore it can be decoded and received by any GNSS user with access to the navigation data bits information.

The objective of this manuscript is to bring light to the current usage of the Galileo SAR RLS by analyzing 3 months of data from a receiver in Belgium. For that purpose, we have developed an open-source Python library to process the RLS, which we also present in this article.

2. Galileo SAR and Return Link Service

2.1. Galileo SAR Contribution

The Galileo SAR infrastructure includes the MEO satellite constellation and several MEOLUTs that receive the distress signals picked up by the satellites and relay them to the mission control centers. The Galileo MEOLUT facilities guarantee the forward link service in the SAR areas under responsibility of the European territories. The covered areas expand 40 million square kilometers over Europe, the north of Africa, and parts of the Atlantic ocean in a rectangular-like area, and 19.6 million square kilometers in a circular area centered in La Reunion island, in the Indian ocean.

There are four MEOLUT facilities: in Spitsbergen (Norway), in Maspalomas (Spain), in Lanarca (Cyprus), and in La Reunion (France). There is also one central MEOLUT tracking coordination facility located in Toulouse (France). Aside from the MEOLUTs, the Galileo ground infrastructure has deployed eight reference beacons that are continuously monitoring the performance of the Galileo SAR services. This reference beacons are the following:

• TLS-EU1: in Tolouse (France);
• SBG-EU2: in Spitsbergen (Norway);
• SMR-EU3: in Santa Maria (Portugal);
• MSP-EU4: in Maspalomas (Spain);
• LNC-EU5: in Lanarca (Cyprus);
• SON-EU6: in Sondrestromfjord (Denmark);
• REU-EU7: in La Reunion (France);
• KLN-EU8: in Kerguelen (France).

More information on the Galileo SAR contribution can be found in [1,3].

2.2. Galileo Return Link Service Format

The Galileo Return Link Service (RLS) enables to communicate back to the distress beacon if it has indicated so in the signal. The transmitted information is a Return Link Messages (RLM), which is only transmitted in the E1-B component of Galileo, in the SAR field of the odd pages of the I/NAV message (transmitted every other second). The SAR field is 22 bits long, and contains one bit to signal the start of a new RLM, one bit to distinguish between short and long RLM, and 20 bits of RLM data. The short messages are 80 bits long (it takes 4 pages or 8 s to receive), and the long messages are 160 bits long (it takes 8 pages or 16 s to receive). If no RLM is being transmitted, the start bit is set held to one and the other bits are spare [4].

The RLM is composed of:

• 60 bits with the Beacon ID, the unique identifier of the distress beacon;
• 4 bits with the message code, that indicates the Return Link Service in use;
• 16 or 96 bits (for short and long RLM respectively) with additional parameters for the Return Link Service.

Currently, only two message codes for short RLM are in use: ‘0001’ for the automatic Acknowledgment Service, and ‘1111’ for the Test Service. For the long RLM, all the codes are spare.

The RLM parameters field is only defined for short RLM, and contains ‘10’ in the first two bits for the Acknowledgment Service, with the rest of the bits except the last one set to spare. All parameter bits except the last one are reserved in the Test Service. In both cases, the last bit is a parity bit.

The 60 bits of Beacon ID (or beacon 15 Hex ID) are defined in the C/S documents and contain several fields of information to identify the beacon. The information varies depending on the beacon protocol and message but in general contains the country code, the protocol code, the beacon type, the manufacturer, and the coordinates.

3. GalileoSARlib Library

In order to process the Galileo SAR RLM data, we developed GalileoSARlib [5], an open-source library in Python. The library is able to process information from log files in Septentrio Binary Format (SBF) as long as they contain the block with the I/NAV navigation data bits. More data input formats are foreseen to be added in the future.

The library parses the 22-bit long SAR field from I/NAV message and reconstructs the RLMs present in the file. The three different parts of the RLM (Beacon ID, message code, and additional parameters) are decoded based on the official documentation. Finally, the 60 bits of the Beacon ID are also parsed and interpreted.

The Beacon ID is the most challenging part to decode since the C/S documentation defines numerous protocols and formats. However, those currently present in Galileo constitute only a subset, and the library will be extended as additional protocols are added to the RLS.

All the decoded information is printed in the console in plain text and saved in JSON format to file for further processing. Each object in the JSON format corresponds to one RLM and contains nested objects for each one of the message’s field. These objects contain attributes including the field name, the raw value (i.e., the binary value), and the interpreted value. Finally, each RLM JSON object includes a metadata attribute containing the transmitting satellite and the reception time.

Aside from the parsing library, the GalileoSARlib repository also provides the plotting scripts used to generate the figures used later in this manuscript. These scripts can be used without modification, or as a template to generate custom plots. The folder will continue to be updated as future research is performed on the topic.

4. Galileo SAR Return Link Service Analysis

4.1. Data Collection

To analyze the current state of the Galileo SAR return link service, we recorded 90 days of continuous GNSS data, from 16 January to 16 April of 2025. The data was collected using a Septentrio mosaic-X5 receiver [6] located at the top of a tower in the electrical engineering faculty of KU Leuven, Belgium. This open-sky location maximizes the amount of information collected, as it allows to track satellites at low elevations.

Ideally, we would like to track all the constellation satellites to get a global view of the service. However, that would require the deployment of receivers at selected locations around the globe and a monitoring infrastructure. The open-source galmon network, a voluntary supported monitoring GNSS network that aggregates GNSS data from multiple stations, could solve this problem. Unfortunately, the endpoint they have that offers the combined Galileo I/NAV data has a bug and does not provide all pages.

The collected 90 days of data are in SBF files filtered to contain only the I/NAV messages. Then, these SBF files (one per day) are concatenated and parsed using the GalileoSARlib library to extract the JSON file. Both the SBF and JSON files are available in the library repository.

4.2. RLS Usage

In total, we processed 40,665,669 I/NAV pages which contained 260,025 short RLM and 14,683 long RLM. The short RLM is transmitted over 4 pages, and the long RLM over 8 pages. Thus, 1,157,564 pages out of 40,665,669 were used for RLS, which gives a usage of 2.86%.

From all the messages received, 94.7% are short RLM, and 5.3% are long RLM. The result is surprising because all long RLM services are currently undefined. When the messages are classified by the requested RLS, the vast majority correspond to the Test Service, whereas only 2.3% correspond to the operational Acknowledge Service. Finally, 5.3% contain spare values (i.e., undefined in the documentation); these include all long RLM and a small percentage of the short RLM. All the spare short RLM messages have the code “0010”, and the long RLM have codes “0010” and “0101”. The data is presented in Table 1 and Figure 2.

Table 1. Return Link Messages in the 90 days of data divided by the RLM type and Return Link Service requested.

RLM Type	Test Service	Acknowledgment Service	Spare
Short RLM	256,533	6416	68
Long RLM	0	0	14,683

Figure 2. Galileo SAR Return Link Messages received during 90 days, (a) shows them by RLM type and (b) sorts them by their RLS.

The next interesting step is to analyze the C/S beacon protocol encoded in the Beacon ID for all the RLMs that are not spare. Surprisingly, there are only two protocols: Orbitography Protocol and RLS Location Protocol. All the Orbitography messages are transmitted in the Test Service, while the RLS Location Protocol messages are transmitted mostly in the Acknowledgment Service. The data is detailed in Table 2.

Table 2. Return Link Messages in the 90 days of data divided by their C/S protocol and the RLS requested.

C/S Protocol	Test Service	Acknowledgment Service
Orbitography Protocol	255,150	0
RLS Location Protocol	1383	6416

4.3. RLS Location Protocol Analysis

The RLS Location Protocol is the default protocol for the Acknowledgment Service. The 60-bit Beacon ID that is transmitted in the RLM is defined in [2]. The Beacon ID contains information about the beacon such as the registration country, the beacon type (ELT, PLB, EPIRB, or test location), and the beacon manufacturer (model, serial number, revision, and capabilities). Finally, it also includes the coordinates within 30 min resolution, although for privacy in the RLM they have always default values.

Using the 90-day recording, we can monitor which beacon types are used the most, and also break it down by beacon registration country (Figure 3). The majority of the beacons are PLB, which are intended for individual persons. There is also big use of EPIRB beacons, which are intended for maritime use, and it can be further specified if they are the first or second EPIRB of the vessel. The Location Test Protocol beacons are transmitted in Test Service instead of Acknowledgment Service. Interestingly, there are no ELT beacons, which are intended for aviation applications. The beacon’s registration country also provides some notable information such as that the vast majority of the Location Test Protocol beacons activated in the recorded 90 days were registered in Israel.

Figure 3. Beacon types using the RLS Location Protocol, further detailed by beacon registration country.

4.4. Orbitography Protocol Analysis

The Orbitography Protocol is used to monitor the system performance by using beacons with an accurately determined position. Then, the position calculated by the SAR system can be compared with a truth value and the system adjusted and improved. The beacon ID contents are described in [7], and include the beacon’s registration country code, seven text characters in Baudot code, and four zeros at the end.

The seven characters in Baudot Code decode to the eight reference beacons described in Section 2.1, which is expected, as they are the monitoring beacons from Galileo. However, there is a ninth Baudot Code decoding: V?????E. This name is not in the reference beacons list and does not follow the specifications because a ”?” character means that it is not a valid Baudot Code value. Moreover, the ensured last four zeros are not zero value.

The Orbitography Protocol RLMs are transmitted in batches separated by 30 min. Figure 4 shows the message reception sorted by reference beacon in the Baudot Code text during 10 April 2025. From the antenna located in Belgium, the satellites transmitting the messages directed to the reference beacons in the Indian Ocean (REU-EU7 and KLN-EU8) are less visible and, hence, there are more gaps in the reception sequence.

Figure 4. Orbitography Protocol messages received for each reference beacon encoded in the message text during 10 April 2025. The messages are transmitted in batches with 30 min gaps between the reference beacon being targeted. The beacon V?????E correspond to an erroneous undocumented beacon name.

In Figure 5, it is shown how all satellites transmit messages for all reference beacons equally, without any preference. There are a few gaps on the Satellite Vehicle ID (SVID) axis which correspond to satellites currently not in orbit or not operational. However, the SVIDs 6, 16, 23, and 29 correspond to operational satellites launched in 28 April and 17 September 2024, and they are not transmitting SAR Return Link Messages. This is because, although operational during the recording, the satellites did not join the SAR efforts until 16 April 2025, the same day the 90-day recording of the data processed in this manuscript ends.

Figure 5. Orbitography Protocol messages received from each satellite of the Galileo constellation. In color, the reference beacon name contained in the message text.

4.5. RLM Transmission Time Analysis

It is also interesting to analyze if the satellites have a time preference to transmit the RLM of each protocol. For this purpose, we computed the transmission time of the SAR RLMs and calculated the modulus 60 s for each satellite. Because the Galileo I/NAV pages are transmitted every 2 s, the value calculated is the time at the start of transmission of the page containing the first piece of the RLM. The results are displayed in a heatmap in Figure 6. The heatmap values are normalized for each satellite row and plotted in logarithmic scale to accentuate the less common transmission positions.

Figure 6. Transmission time of short Galileo SAR Return Link Messages received during the 90-day modulus 60 s in logarithmic scale: (a) displays the RLS Location protocol messages, and (b) the Orbitography Protocol messages.

The RLS Location Protocol messages are transmitted usually on the second 7 of the GNSS minute. For the Orbitography Protocol, messages are usually transmitted in the second 23 of the GNSS minute. In the Orbitography Protocol, there are other less preferred positions at second 3, 11 and 19 s, which are separated by 4 pages each because that is how long it takes to transmit a short RLM. In both protocols, the SVID 11 and 12 have an offset of one page; this offset is not explained in the service documentation, although coincidentally they are the two oldest operational satellites of the Galileo constellation.

The same transmission time analysis can be performed for the long RLMs, although there is no service defined. The results in Figure 7 show that there is a preference for transmitting them at the second 7 of the GNSS minute and a lower preference for the second 23. Both preferred positions are separated by eight pages, which is the size of a long RLM.

Figure 7. Transmission time of long Galileo SAR Return Link Messages received during 90-day modulus 60 s in logarithmic scale.

5. Conclusions and Future Work

We presented an analysis of the Galileo SAR Return Link Service using 90 days of GNSS data to detail the current usage of the service and the anomalies detected. The RLS has been used in 2.86% of its capacity as seen from the recording position, mainly with test messages. The actual SAR acknowledgment messages represent only 2.3% of the totality of the messages. Although their content is not defined in the documentation, we detected the transmission of long RLM and undefined service short RLM. Finally, different message protocols prefer to be transmitted at certain epochs, with SVID 11 and 12 having an offset of one page.

The code of the GalileoSARlib library used to parse the SAR data, the 90 days data recording, and the scripts to generate the plots in this document have been made publicly available on GitHub.

The SAR field in the I/NAV message is a candidate to transmit the Galileo Emergency Warning Message in the future. The GalileoSARlib library will be updated to decode the message and monitor its usage in a similar way as the Return Link Service.