Status, Key Results, Performance
By Axel van den Berg, Tom Willems, Graham Pye, and Wim de Wilde, Septentrio Satellite Navigation, Richard Morgan-Owen, Juan de Mateo, Simone Scarafia, and Martin Hollreiser, European Space Agency
A fully stand-alone, multi-frequency, multi-constellation receiver unit, the TUR-N can autonomously generate measurements, determine its position, and compute the Galileo safety-of-life integrity.
Development of a reference Galileo Test User Receiver (TUR) for the verification of the Galileo in-orbit validation (IOV) constellation, and as a demonstrator for multi-constellation applications, has culminated in the availability of the first units for experimentation and testing. The TUR-N covers a wide range of receiver configurations to demonstrate the future Galileo-only and GPS/Galileo combined services:
- Galileo single- and dual-frequency Open Services (OS)
- Galileo single- and dual-frequency safety-of-life services (SoL), including the full Galileo navigation warning algorithms
- Galileo Commercial Service (CS), including tracking and decoding of the encrypted E6BC signal
- GPS/SBAS/Galileo single- and dual- frequency multi-constellation positioning
- Galileo single- and dual-frequency differential positioning.
- Galileo triple-frequency RTK.
In parallel, a similar test user receiver is specifically developed to cover the Public Regulated service (TUR-P). Without the PRS components and firmware installed, the TUR-N is completely unclassified.
Main Receiver Unit
The TUR-N receiver is a fully stand-alone, multi-frequency, multi-constellation receiver unit. It can autonomously generate measurements, determine its position, and compute Galileo safety-of-life integrity, which is output in real time and/or stored internally in a compact proprietary binary data format.
The receiver configuration is fully flexible via a command line interface or using the dedicated graphical user interface (GUI) for monitoring and control. With the MCA GUI it is also possible to monitor the receiver operation (see Figure 1), to present various real-time visualizations of tracking, PVT and integrity performances, and off-line analysis and reprocessing functionalities. Figure 2 gives an example of the correlation peak plot for an E5 AltBOC signal.
A predefined set of configurations that map onto the different configurations as prescribed by the Test User Segment Requirements (TUSREQ) document is provided by the receiver.
The unit can be included within a local network to provide remote access for control, monitoring, and/or logging, and supports up to eight parallel TCP/IP connections; or, a direct connection can be made via one of the serial ports.
The main receiver unit consists of three separate boards housed in a standard compact PCI 19-inch rack. See Figure 3 for a high-level architectural overview.
A dedicated analog front-end board has been developed to meet the stringent interference requirements. This board contains five RF chains for the L1, E6, E5a/L5, E5b, and E5 signals. Via a switch the E5 signal is either passed through separate filter paths for E5a and E5b or via one wide-band filter for the full E5 signal. The front-end board supports two internal frequency references (OCXO or TCXO) for digital signal processing (DSP).
The DSP board hosts three tracker boards derived from a commercial dual-frequency product family. These boards contain two tracking cores, each with a dedicated fast-acquisition unit (FAU), 13 generic dual-code channels, and a 13-channel hardware Viterbi decoder. One tracking core interacts with an AES unit to decrypt the E6 Commercial Service carrier; it has a throughput of 149 Mbps.
Each FAU combines a matched filter with a fast Fourier transform (FFT) and can verify up to 8 million code-frequency hypotheses per second. Each of the six tracker cores can be connected with one of the three or four incoming IF streams. To simplify operational use of the receiver, two channel-mapping files have been defined to configure the receiver either for a 5-frequency 13-channel Galileo receiver, or for a dual-frequency 26-channel Galileo/GPS/SBAS receiver. Figure 4 shows all five Galileo signal types being tracked for nine visible satellites at the same time.
The receiver is controlled using a COTS CPU board that also hosts the main positioning and integrity algorithms. The processing power and available memory of this CPU board is significantly higher than what is normally available in commercial receivers. Consequently there is no problem in supporting the large Nequick model used for single-frequency ionosphere correction, and achieving the 10-Hz update rate and low latency requirements when running the computationally intensive Galileo integrity algorithms. For commercial receivers that are normally optimized for size and power consumption, these might prove more challenging.
The TUR project included development of three types of Galileo antennas:
- a triple-band (L1, E6, E5) high-end antenna for fixed base station applications including a choke ring;
- a triple-band (L1, E6, E5) reference antenna for rover applications;
- a dual-band (L1, E5b) aeronautic antenna for SOL applications
Figure 5 shows an overview of the main interfaces and functional blocks of the receiver, together with its antenna and a host computer to run the MCA software either remotely or locally connected.
Currently, the TUR-N is undergoing an extensive testing program. In order to fully qualify the receiver to act as a reference for the validation of the Galileo system, some challenges have to be overcome. The first challenge that is encountered is that the performance verification baseline is mainly defined in terms of global system performance. The translation of these global requirements derived from the Galileo system requirements (such as global availability, accuracy, integrity and continuity, time-to-first/precise-fix) into testable parameters for a receiver (for example, signal acquisition time, C/N0 versus elevation, and so on) is not trivial. System performances must be fulfilled in the worst user location (WUL), defined in terms of dynamics, interference, and multipath environment geometry, and SV-user geometry over the Galileo global service area.
A second challenge is the fact that in the absence of an operational Galileo constellation, all validation tests need to be done in a completely simulated environment. First, it is difficult to assess exactly the level of reality that is necessary for the various models of the navigation data quality, the satellite behaviour, the atmospheric propagation effects, and the local environmental effects. But the main challenge is that not only the receiver that is being verified, also the simulator and its configuration are an integral part of the verification. It is thus an early experience of two independent implementations of the Galileo signal-in-space ICD being tested together. At the beginning of the campaign, there was no previously demonstrated or accepted test reference.
Only the combined efforts of the various receiver developments benchmarked against the same simulators together with pre-launch compatibility tests with the actual satellite payload and finally IOV and FOC field test campaigns will ultimately validate the complete system, including the Galileo ground and space segments together with a limited set of predefined user segment configurations. (Previously some confidence was gained with GIOVE-A/B experimental satellites and a breadboard adapted version of TUR-N). The TUR-N was the first IOV-compatible receiver to be tested successfully for RF compatibility with the Galileo engineering model satellite payload.
Receiver requirements, including performance, are defined in the TUSREQ document.
Antenna and Interference. A key TUSREQ requirement focuses on receiver robustness against interference. It has proven quite a challenge to meet the prescribed interference mask for all user configurations and antenna types while keeping many other design parameters such as gain, noise figure, and physical size in balance. For properly testing against the out-of-band interference requirements, it also proved necessary to carefully filter out increased noise levels created by the interference signal generator.
Table 2 gives an overview of the measured values for the most relevant Antenna Front End (AFE) parameters for the three antenna types. Note: Asymmetry in the AFE is defined as the variation of the gain around the centre frequency in the passband. This specification is necessary to preserve the correlation peak shape, mainly of the PRS signals.
The gain for all antenna front ends and frequencies is around 32 dB. Figures 6 and 7 give an example of the measured E5 RHCP radiating element gain and axial ratio against theta (the angle of incidence with respect to zenith) for the high-end antenna-radiating element. Thus, elevation from horizontal is 90-theta.
UERE Performance. As part of the test campaign, TUR performance has been measured for user equivalent range error (UERE) components due to thermal noise and multipath.
TUSREQ specifies the error budget as a function of elevation, defined in tables at the following elevations: 5, 10, 15, 20, 30, 40, 50, 60, 90 degrees. The elevation dependence of tracking noise is immediately linked to the antenna gain pattern; the antenna-radiating element gain profiles were measured on the actual hardware and loaded to the Radio Frequency Constellation Simulator (RFCS), one file per frequency and per antenna scenario. The RFCS signal was passed through the real antenna RF front end to the TUR. As a result, through the configuration of RFCS, real environmental conditions (in terms of C/N0) were emulated in factory.
The thermal noise component of the UERE budget was measured without multipath being applied, and interference was allowed for by reducing the C/N0 by 3 dB from nominal. Separately, the multipath noise contribution was determined based on TUSREQ environments, using RFCS to simulate the multipath (the multipath model configuration was adapted to RFCS simulator multipath modeling capabilities in compliance with TUSREQ). To account for the fact that multipath is mostly experienced on the lower elevation satellites, results are provided with scaling factors applied for elevation (“weighted”), and without scaling factors (“unweighted”). In addition, following TUSREQ requirements, a carrier smoothing filter was applied with 10 seconds convergence time.
Figure 8 shows the C/N0 profile from the reference antenna with nominal power reduced by 3 dB. Figure 9 shows single-carrier thermal noise performance without multipath, whereas Figure 10 shows thermal noise with multipath. Each of these figures includes performance for five different carriers: L1BC, E6BC, E5a, E5b, and E5 AltBOC, and the whole set is repeated for dual-frequency combinations (Figure 11 and Figure 12).
The plots show that the thermal noise component requirements are easily met, whereas there is some limited non-compliance on noise+multipath (with weighted multipath) at low elevations. The tracking noise UERE requirements on E6BC are lower than for E5a, due to assumption of larger bandwidth at E6BC (40MHz versus 20MHz). Figures 9 and 10 refer to UERE tables 2 and 9 of TUSREQ. The relevant UERE requirement for this article is TUSREQ table 2 (satellite-only configuration). TUSREQ table 9 is for a differential configuration that is not relevant here.
UERRE Performance. The complete single-frequency range-rate error budget as specified in TUSREQ was measured with the RFCS, using a model of the reference antenna. The result in Figure 13 shows compliance.
Position Accuracy. One of the objectives of the TUR-N is to demonstrate position accuracy. In Figure 14 an example horizontal scatter plot of a few minutes of data shows a clear distinction between the performances of two different single-frequency PVT solutions: GPS L1CA in purple and E5AltBOC in blue. The red marker is the true position, and the grid lines are separated at 0.5 meters. The picture clearly shows how the new E5AltBOC signal produces a much smoother position solution than the well-known GPS L1CA code. However, these early results are from constellation simulator tests without the full TUSREQ worst-case conditions applied.
The defined TUSREQ user environments, the basis for all relevant simulations and tests, are detailed in Table 3. In particular, the rural pedestrian multipath environment appears to be very stringent and a performance driver.
This was already identified at an early stage during simulations of the total expected UERE and position accuracy performance compliance with regard to TUSREQ, summarized in Table 4, and is now confirmed with the initial verification tests in Figure 10. UERE (simulated) total includes all other expected errors (ionosphere, troposphere, ODTS/BGD error, and so on) in addition to the thermal noise and multipath, whereas the previous UERE plots were only for selected UERE components. The PVT performance in the table is based on service volume (SV) simulations.
The non-compliances on position accuracy that were predicted by simulations are mainly in the rural pedestrian environment. According to the early simulations:
- E5a and E5b were expected to have 43-meter vertical accuracy (instead of 35-meter required).
- L1/E5a and L1/E5b dual-frequency configurations were expected to have 5-meter horizontal, 12-meter vertical accuracy (4 and 8 required).
These predictions appear pessimistic related to the first position accuracy results shown in Table 5. On single frequency, the error is dominated by ionospheric delay uncertainty. These results are based on measurements using the RFCS and modeling the user environment; however, the simulation of a real receiver cannot be directly compared to service-volume simulation results, as a good balance between realism and worst-case conditions needs to be found. Further optimization is needed on the RFCS scenarios and on position accuracy pass/fail criteria to account for DOP variations and the inability to simulate worst environmental conditions continuously.
Further confirmations on Galileo UERE and position accuracy performances are expected after the site verifications (with RFCS) are completed, and following IOV and FOC field-test campaigns.
Acquisition. Figure 15 gives an example of different signal-acquisition times that can be achieved with the TUR-N after the receiver boot process has been completed. Normally, E5 frequencies lock within 3 seconds, and four satellites are locked within 10 seconds for all frequencies. This is based on an unaided (or free) search using a FAU in single-frequency configurations, in initial development test without full TUSREQ constraints.
When a signal is only temporarily lost due to masking, and the acquisition process is still aided (as opposed to free search), the re-acquisition time is about 1 second, depending on the signal strength and dynamics of the receiver. When the PVT solution is lost, the aiding process will time out and return to free search to be robust also for sudden user dynamics.
More complete and detailed time-to-first-fix (TTFF) and time-to-precise-fix (TTPF), following TUSREQ definitions, have also been measured.
In cold start the receiver has no prior knowledge of its position or the navigation data, whereas in warm start it already has a valid ephemeris in memory (more details on start conditions are available in TUSREQ). Table 6 shows that the acquisition performances measured are all compliant to TUSREQ except for warm start in E5a single frequency and in the integrity configurations. However, when the navigation/integrity message recovery time is taken off the measurement (as now agreed for updated TUSREQ due to message limitations), these performances also become compliant.
Specific examples of statistics gathered are shown in figures 16–21, these examples being for dual-frequency (E5b+L1) with integrity configuration. The outliers, being infrequent results with high acquisition times, are still compliant with the maximum TTFF/TTPF requirements, but are anyway under further investigation.
Integrity Algorithms. The Galileo SoL service is based on a fairly complex processing algorithm that determines not only the probability of hazardous misleading information (PHMI) based on the current set of satellites used in the PVT computation (HPCA), but also takes into consideration the PHMI that is achieved when one of the satellites used in the current epoch of the PVT computation is unexpectedly lost within the following 15 seconds. PHMI is computed according to alarm limits that are configurable for different application/service levels. These integrity algorithms have been closely integrated into the PVT processing routines, due to commonality between most processing steps.
Current test results of the navigation warning algorithm (NWA) indicate that less than 10 milliseconds of processing time is required for a full cycle of the integrity algorithms (HPCA+CSPA) on the TUR-N internal CPU board. Latency of the availability of the integrity alert information in the output of the receiver after it was transmitted by the satellite has been determined to be below 400 milliseconds. At a worst-case data output rate of 10 Hz this can only be measured in multiples of 100 millisecond periods. The total includes 100 milliseconds of travel time of the signal in space and an estimated 250 milliseconds of internal latency for data-handling steps as demodulation, authentication, and internal communication to make the data available to the integrity processing.
The TUR-N is a fully flexible receiver that can verify many aspects of the Galileo system, or as a demonstrator for Galileo/GPS/SBAS combined operation. It has a similar user interface to commercial receivers and the flexibility to accommodate Galileo system requirements evolutions as foreseen in the FOC phase without major design changes.
The receiver performance is in general compliant with the requirements. For the important safety-of-life configuration, major performance requirements are satisfied in terms of acquisition time and position accuracy.
The receiver prototype is currently operational and undergoing its final verification and qualification, following early confirmations of compatibility with the RFCS and with the Galileo satellite payload.