GPS World

Tag: interoperability

  • Interoperability Working Group Issues November Meeting Report

    The report of Working Group A on Compatibility and Interoperability, held November 11-13, 2013, in Dubai, United Arab Emirates, is now available as a downloadable PDF. It is also available on the ICG Information Portal.

  • Quad-Constellation Receiver: GPS, GLONASS, Galileo, BeiDou

    The implementation changes and first live tests of BeiDou and Galileo on Teseo-3 GNSS chips developed in 2013 are covered, bringing it to a four-constellation machine. By 2020, we expect to have four global constellations all on the same band, giving us more than 100 satellites — under clear sky, as many as 30 or 40 simultaneously.

    By Philip G. Mattos and Fabio Pisoni

    Multi-constellation GNSS first became widely available in 2010/2011, but only as two constellations, GPS+GLONASS. Although receivers at that time may have supported Galileo, there were no usable satellites. BeiDou was a name only, as without a spec (an interface control document, or ICD), no receivers could be built. However, the hardware development time of receivers had been effectively shortened: the Galileo ICD had been available for years, BeiDou codes had been reverse-engineered by Grace Gao and colleagues at Stanford, and at the end of 2011 they were confirmed by the so-called test ICD, which allowed signal testing without yet releasing message characteristics or content.

    The last weeks of 2012 saw two great leaps forward for GNSS. Galileo IOV3 and 4 started transmitting at the beginning of December, bringing the constellation to four and making positioning possible for about two hours a day. At the end of December, the Chinese issued the BeiDou ICD, allowing the final steps of message decode and ephemeris calculation to be added to systems that had been tracking BeiDou for many months, and thus supporting positioning. The Teseo-2 receiver from STMicroelectronics has been available for some years, so apart from software development, it was just waiting for Galileo satellites; however, for BeiDou it needed hardware support in the form of an additional RF front end. Additionally, while it could support all four constellations, it could not support BeiDou and GPS/Galileo at the same time, as without the BeiDou ICD the spreading codes had to be software-generated and used from a memory-based code generator, thus blocking the GPS/Galileo part of the machine.

    The Teseo-3 receiver appeared late in 2013, returning to the optimum single-chip form factor: RF integrated with digital silicon and flash memory in the same package, enabling simultaneous use of BeiDou and GPS/Galileo signals. Multi-constellation in 2012 was GPS+GLONASS, which brought huge benefits in urban canyons with up to 20 visible satellites in an open sky. Now, for two hours a day in Europe while the Galileo IOVs are visible, we can run three constellations, and in the China region, GPS/BeiDou/Galileo is the preferred choice.

    This article covers the first tracking of four Galileo satellites on December 4, 2012, first positioning with Galileo, and first positioning with BeiDou in January 2013. It will cover static and road tests of each constellation individually and together as a single positioning solution. Road tests in the United States/Europe will combine GPS/GLONASS/Galileo, while tests in the China region will combine GPS/Galileo/BeiDou. Results will be discussed from a technical point of view, while the market future of multi-constellation hardware will also be considered.

    In the 2010–2020 timeframe, GLONASS and BeiDou (1602 MHz FDMA and 1561 MHz respectively) cost extra silicon in both RF and digital hardware, and cause marginal extra jamming vulnerability due to the 50 MHz bandwidth of the front end. The extra silicon also causes extra power consumption.

    After 2020, GLONASS is expected to have the L1OC signal operational, CDMA on the GPS/Galileo frequency, and BeiDou is expected both to have expanded worldwide, and also to have the B3 signal fully operational, again on 1575 MHz. At that point we will have four global constellations all on the same band, giving us more than 100 satellites. With a clear sky, the user might expect to see more than 30, sometimes 40, satellites simultaneously.

    Besides the performance benefits in terms of urban canyon availability and accuracy, this allows the receiver to be greatly simplified. While code generators will require great flexibility to generate any of the code families at will, the actual signal path will be greatly simplified: just one path in both RF (analog) and baseband (digital) processing, including all the notch filters, derotation, and so on. And this will greatly reduce the power consumption.

    Will the market want to take the benefit in power consumption and silicon area, or will it prefer to reuse those resources by becoming dual-frequency, adding also the lower-L-band signals, initially L5/E5, but possibly also L2/L3/L6 ? The current view is that the consumer receiver will go no further than L5/E5, but that the hooks will be built-in to allow the same silicon to be used in professional receivers also, or in L2C implementations to take advantage of the earlier availability of a full constellation of GPS-L2C rather than GPS-L5.

    This article presents both technical results of field trials of the quad-constellation receiver, and also the forward looking view of how receivers will grow through multi-frequency and shrink through the growing signal commonalities over this decade.

    History

    Galileo was put into the ST GPS/GNSS receiver hardware from 2006 to 2008, with a new RF and an FPGA-based baseband under the EU-funded GR-PosTer project. While a production baseband (Cartesio-plus) followed in high volume from 2009, in real life it was still plain GPS due to the absence of Galileo satellites.

    The changed characteristics in Galileo that drove hardware upgrades are shown in Figure 1. The binary offset carrier BOC(1,1) modulation stretches the bandwidth, affecting the RF, while both the BOC and the memory codes affect the baseband silicon in the code-generator area.

    Figure 1. Changes for Galileo.
    Figure 1. Changes for Galileo.

    Next was the return to strength of the GLONASS constellation, meaning receivers were actually needed before Galileo. However the different center frequency (1602 MHz), and the multi-channel nature of the FDMA meant more major changes to the hardware. As shown in Figure 2 in orange, a second mixer was added, with second IF path and A/D converter.

    Figure 2. Teseo-2 RF hardware changes for GLONASS.
    Figure 2. Teseo-2 RF hardware changes for GLONASS.
    Figure 3. Teseo-2 and Teseo-3 baseband changes for GLONASS.
    Figure 3. Teseo-2 and Teseo-3 baseband changes for GLONASS.

    The baseband changes added a second pre-processing chain and configured all the acquisition channels and tracking channels to flexibly select either input chain. Less visible, the code-generators were modified to support 511 chip codes and 511kchips/sec rates.

    Teseo-2 appeared with GPS/GLONASS support in 2010, and demonstrated the benefit of GNSS in urban canyons, as shown by the dilution of precision (DOP) plot for central London in Figure 4. The GPS-only receiver (in red) has frequent DOP excursions beyond limits, resulting either in bad accuracy or even interrupted fix availability. In contrast, the GNSS version (in blue) has a DOP generally below 1, with a single maximum of 1.4, and thus 100 percent availability. Tracking 16 satellites, even if many are via non-line-of-sight (NLOS) reflected paths, allows sophisticated elimination of distorted measurements but still continuous, and hence accurate, positioning.

    Figure 4. DOP/accuracy benefits of GNSS.
    Figure 4. DOP/accuracy benefits of GNSS.

    BeiDou

    Like Galileo, BeiDou is a story of chapters. Chapter 1 was no ICD, and running on a demo dual-RF architecture as per the schematic shown in Figure 5. Chapter 2 was the same hardware with the test ICD, so all satellites, but still no positioning. Chapter 3 was the full ICD giving positioning in January 2013 (Figure 6), then running on the real Teseo-3 silicon in September 2013, shown in Figure 7.

    Figure 5. Demo Teseo-2 dual RF implementation of BeiDou.
    Figure 5. Demo Teseo-2 dual RF implementation of BeiDou.
    Figure 6. Beidou positioning results.
    Figure 6. Beidou positioning results.
    Figure 7. Teseo 3 development board.
    Figure 7. Teseo 3 development board.

    The Teseo-3 has an on-chip RF section capable of GPS, Galileo, GLONASS and BeiDou, so no external RF is needed.

    The clear green space around the Teseo-3 chip in the photo and the four mounting holes are for the bolt-down socket used to hold chips during testing, while the chip shown is soldered directly to the board. Figure 8A shows the development board tracking eight BeiDou satellites visible from Taiwan.

    However, the silicon is not designed to be single-constellation; it is designed to use all the satellites in the sky. Figure 8b shows another test using GPS and BeiDou satellites simultaneously.

    Figure 8A. Beidou.
    Figure 8A. Beidou.
    Figure 8b. GPS+Beidou.
    Figure 8b. GPS+Beidou.

    A mobile demo on the Teseo-3 model is shown running GPS plus BeiDou in Figure 9, a road test in Taipei. Satellites (SV) up to 32 are GPS, those over 140 are BeiDou, in the status window shown: total 13 satellites in a high-rise city area, though many are non-LOS.

    Figure 9. GPS + Beidou roadtrack in Taipei.
    Figure 9. GPS + Beidou roadtrack in Taipei.

    Extending the hardware to add BeiDou, which is on 1561 MHz and thus a third center frequency, meant adding another path through the IF stages of the on-chip radio. After the first mixer, GPS is at 4 MHz, and GLONASS at about 30 MHz, but BeiDou is at minus 10 MHz. While the IF strip in general is real, rather than complex (IQ), the output of the mixer and input to the first filter stage is complex, and thus can discriminate between positive frequencies (from the upper sideband) and negative ones (from the lower sideband), and this is normally used to give good image rejection. In the case of BeiDou, the filter input is modified to take the lower sideband, that is, negative frequencies, and a second mixer is not required; the IF filter is tuned to 10 MHz. The new blocks for BeiDou are shown in green in Figure 10. The baseband has no new blocks, but the code generator has been modified to generate the BeiDou codes (and, in fact, made flexible to generate many other code types and lengths). Two forms of Teseo-3 baseband are envisaged, the first being for low-cost, low-current continues to have two input paths, so must choose between GLONASS and BeiDou as required. A future high-end model may have an extra input processing path to allow use of BeiDou and GLONASS simultaneously.

    Figure 10. Teseo-3 RF changes for Beidou shown in green.
    Figure 10. Teseo-3 RF changes for Beidou shown in green.

    Galileo Again

    Maintaining the chronological sequence, Galileo gets a second chapter in three steps. In December 2012, it was possible for the first time to track four IOV satellites simultaneously, though not to position due to the absence of valid orbit data. In March 2012, it was possible for the first time to demonstrate live positioning, and this was done using Teseo-2 simultaneously by ESA at ESTEC and STMicro in Naples and Milan, our software development centres.

    The demos were repeated in public for the press on July 24, 2013, at Fucino, Italy’s satellite earth station, with ESA/EC using the test user receiver (TUR) from Septentrio, and ST running simultaneous tests at its Italian labs. Figure 11 and Figure 12 show the position results for the data and pilot channels respectively, with independent LMS fixes. In real life, the fixes would be from a Kalman filter, and would be from a combined E1-B/E1-C channel, to take advantage of the better tracking on the pilot.

    Figure 11. Galileo positioning, E1-B.
    Figure 11. Galileo positioning, E1-B.
    Figure 12. Galileo positioning, E1-C.
    Figure 12. Galileo positioning, E1-C.

    Good accuracy is not expected from Galileo at this stage. The four satellites, while orbited to give good common visibility, do not also give a good DOP; the full set of ground monitoring stations is not yet implemented and cannot be well calibrated with such a small constellation. Finally, the ionospheric correction data is not yet available. Despite these problems, the residuals on the solutions, against a known fixed position for the rooftop antenna, are very respectable, shown in Figure 13.

    Figure 13. Galileo residuals, L1-B.
    Figure 13. Galileo residuals, L1-B.

    The common mode value is unimportant, representing only an offset in the receiver clock, and 10 meters is about 30 nanoseconds. The accuracy indicator is the spread between satellites, which is very respectable for a code-only receiver without full iono correction, especially around 640 on the TOW scale, where it is less than 2 meters. The rapid and major variation on the green data around t=400 is considered to be multipath, as the roof antenna is not ideally positioned with respect to other machinery and equipment also installed on the roof.

    QZSS and GPS-III/L1C

    Teseo-2 has supported the legacy (C/A code) signal on QZSS for some time, but Teseo-3 has been upgraded to handle the GPS-III/L1-C signal, waiting for modernized GPS. This signal is already available on the QZSS satellite, allowing tests with real signals. Significant changes were required in the baseband hardware, as the spreading code is a Weill code, whose generation complexity is such that it is generated once when the satellite is selected, then replayed real time from memory. Additionally it is long, in two domains. It is 10230 chips — that is, long to store but also long in time, with a 10-millisecond epoch. On Teseo-3, the legacy C/A code is used to determine code-phase and frequency before handing over to the Weill code for tracking.

    Using a long-range crystal ball and looking far into the future, a model of the future Teseo-4 DSP hardware is available, with 64 correlation taps per satellite. Running this on the captured QZSS L1-C signal gives the correlation response shown in Figure 14. Having multiple taps removes all ambiguity from the BOC signal, simultaneously removing data transitions, which can alternatively be pre-stripped using the known pilot secondary code (which on GPS III is 5 dB stronger than the data signal). The resultant plot represents 2,000 epochs, each of 10 milliseconds, plotted in blue, with integrated result for the full 20 seconds shown in the black dashed line. Assuming vehicle dynamics is taken out using carrier Doppler, this allows extremely precise measurement of the code phase, or analysis of any multipath in order to remove it. This RF data was captured on a benign site with a static antenna, so it shows little distortion.

    Figure 14. L1-C tracking on QZSS satellite.
    Figure 14. L1-C tracking on QZSS satellite.
    Figure 15. Dual RF implementation of dual-band front end.
    Figure 15. Dual RF implementation of dual-band front end.

    The Future

    Having already built in extreme flexibility to the code generators to support all known signals and generalized likely future ones, the main step for the future is to support multiple frequencies, starting with adding L5 and/or L2, but as before, ensuring that enough flexibility is built in to allow any rational user/customer choice. It is not viable for us to make silicon for low-volume combinations, nor to divide the overall market over different chips. Thus our mainstream chip must also support the lower volume options.

    We cannot, however, impose silicon area or power consumption penalties on the high-volume customer, or he will not buy our product.

    Thus, our solution to multi-frequency is to make an RF that can support either band switchably, with the high band integrated on the volume single-chip GNSS. Customers who also need the low band can then add a second RF of identical design externally, connected to the expansion port on the baseband, which has always existed for diagnostic purposes, and was how BeiDou was demonstrated on T2. By being an RF of identical design to the internal one, it incurs no extra design effort, and would probably be produced anyway as a test chip during the development of the integrated single-chip version. Without this approach, the low volume of sales of a dual-band radio, or a low-band radio, would never repay its development costs.

    Conclusions

    All four constellations have been demonstrated with live satellite signals on Teseo-2, a high-volume production chip for several years, and on Teseo-3 including use in combinations as a single multi-constellation positioning solution. With the advent of Teseo-3, with optimized BeiDou processing and hardware support for GPS-3/L1C, a long-term single-chip solution is offered.

    For the future, dual-frequency solutions are in the pipeline, allowing full advantage of carrier phase, and research into moving precise point positioning and real-time kinematic into the automotive market for fields such as advanced driver-assistance systems.

    Acknowledgments

    Teseo III design and development is supported by the  European Commission HIMALAYA FP-7 project.

    This article is based on a technical paper first presented at ION-GNSS+ 2013 in Nashville, Tennessee.

    ST GPS products, chipsets and software, baseband and RF are developed by a distributed team in: Bristol, UK (system R&D, software R&D; Milan, Italy (Silicon implementation, algorithm modelling and verification); Naples, Italy (software implementation and validation); Catania, Sicily, Italy (Galileo software, RF design and production); Noida, India (verification and FPGA). The contribution of all these teams is gratefully acknowledged.

    Philip G. Mattos received an external Ph.D. on his GPS work from Bristol University. Since 1989 he has worked exclusively on GNSS implementations, RF, baseband and applications. He is consulting on the next-generation GNSS chips, including one-chip GPS (RF+digital), and high-sensitivity GPS and Galileo for indoor applications, and combined GPS/Galileo/GLONASS chipsets. In 2008-2009, he re-implemented LORAN on the GPS CPU, and in 2009-2010 led the GLONASS implementation team. He is leading the team on L1C and BeiDou implementation, and the creation of totally generic hardware that can handle even future unknown systems.

    Fabio Pisoni has been with the GNSS System Team at STMicroelectronics since 2009. He received a master’s degree in electronics from Politecnico di Milano, Italy, in 1994. He was previously with the GNSS DSP and System Team in Nemerix SA and has earlier working experience in communications (multi-carrier receivers).

  • Innovation: Interfacing Clearly

    Innovation: Interfacing Clearly

    A New Approach to the Design and Development of Global Navigation Satellite Systems

    By Daniele Gianni, Marco Lisi, Pierluigi De Simone, Andrea D’Ambrogio, and Michele Luglio

    GPS World photo
    INNOVATION INSIGHTS by Richard Langley

    MY FIRST DEGREE is in applied physics from the University of Waterloo. Founded in 1957, Waterloo was one of the first universities to introduce co-operative education. Co-operative education (or “co-op” as it is commonly known) is a program that uses both classroom study and temporary jobs to provide students with practical experience. Applied Physics was a co-op program and I worked in both industry and research environments including stints at Philips Electronics and the Atomic Energy of Canada Limited’s Chalk River Laboratories.

    Both on campus and on the job, I met fellow co-op students from a variety of disciplines including mathematics (computer science) and various branches of engineering. One of those was systems design engineering or systems engineering for short. At that time, I really didn’t know much about systems engineering except that it was an all-encompassing branch of engineering and the most challenging of all of the engineering programs at Waterloo — at least according to the students in the program.

    Systems engineering is an interdisciplinary field of engineering focusing on the design and management of complex engineering projects. According to the International Council on Systems Engineering, systems engineers establish processes “to ensure that the customer and stakeholder’s needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system’s entire life cycle. This process is usually comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate [or, SIMILAR, for short].”

    Central to the systems engineering process and the end-product design is the generation of models. Many types of system models are used, including physical analogs, analytical equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations, and even mental models. (If you want to learn a bit about mental and other kinds of models, including how to fix radios by thinking, you could do no better than to look at some of Richard Feynman’s writings including the eminently readable “Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character.)

    As aids to the modeling process, systems engineers have developed specialized modeling languages including the Unified Modeling Language (UML) and the Systems Modeling Language (SysML). These are graphical-based languages that can be used to express information or knowledge about systems in a structure that is defined by a consistent set of rules. Both UML and SysML are widely used in systems engineering. However, both are limited when it comes to representing the signal-in-space (SIS) interfaces for global navigation satellite systems.

    In this month’s column, a team of authors affiliated with the Galileo project discusses the Interface Communication Modeling Language, an extension of UML that allows engineers to clearly represent SIS interfaces, critical for the design of GNSS receivers.

    “Innovation” is a regular feature that discusses advances in GPS technology andits applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas. To contact him, see the “Contributing Editors” section on page 4.

    In this article, we present the results of ongoing research on the use of a modeling language, namely Interface Communication Modeling Language (ICML), for signal-in-space (SIS) interface specification of global navigation satellite systems (GNSS). Specifications based on modeling languages (also known as model-based specifications) have proven to offer a wide range of benefits to systems engineering activities, for supporting system interoperability, reducing design risk, automating software development, and so on. We argue that similar benefits can be obtained for satellite navigation systems and receivers, if a model-based approach is used for defining and expressing the SIS interface specification. In particular, we outline how a model-based SIS interface specification can support the identification of solutions to two key issues: GNSS interoperability and the design of GNSS receivers, particularly Galileo receivers. Both issues are becoming increasingly central to the Galileo program since it entered the In-Orbit-Validation (IOV) phase and is steadily approaching the 2014 milestone, when the first early services — the Open Service (OS) and the Search and Rescue Service — will be provided to users.

    GNSS interoperability concerns the integration of different GNSS with the purpose of being used together, along with regional positioning systems, to provide a seamless navigation capability and improved services in terms of availability, continuity, accuracy, and integrity, for example. GNSS interoperability should be addressed in terms of intra-GNSS interoperability and GNSS-receiver interoperability. The intra-GNSS interoperability concerns the data exchanged among the GNSS, including coordination to guarantee data coherence and consistency over time. For example, GNSS may need to share terrestrial reference frames and constantly synchronize their global time references. On the other hand, GNSS-receiver interoperability concerns the capability of the receiver to use independent GNSS signals for the computation of positions globally. This capability implicitly requires that the receiver computations are decoupled from the SIS interface of any particular GNSS. A key condition to achieve this decoupling is that the SIS interface specification is available in a consistent, unambiguous, and possibly standard format, which can support engineers to more effectively design interoperable receivers. A model-based SIS interface specification would considerably facilitate this as it enables designers to use the processing capabilities of a computer system for the verification of the specification consistency and completeness, for example. Moreover, a model-based SIS interface specification would ease the visual and electronic inspection of the data messages, therefore facilitating the automatic identification of different data representations for the same orbital and temporal parameters.

    The design of GNSS receivers, and particularly those for Galileo, is increasingly of interest, and a model-based SIS interface specification can similarly support the definition of future solutions. For Galileo, specifically, the receiver design is critical to support the marketing strategies that are promoting the use of Galileo services. Key issues underlying any marketing strategy concern the Galileo receiver market appealing from a cost-to-performance ratio point of view. As Galileo receivers may require new design and adaptation of existing software (SW) or hardware (HW), as well as new production chains, higher costs — in particular non-recurring ones — are likely to occur for the production of the Galileo receivers with respect to the well-established GPS receivers. As a consequence, limitations may be experienced in market penetration and in the growth velocity of Galileo receivers’ share of the receiver market. In turn, this may hinder the estimated economic return for the Galileo project.

    Preventing and counteracting this possibility is therefore a critical issue if we aim to achieve the widest possible success of the Galileo project. Market barriers inherently originate from the following needs:

    • Designing new SW and HW solutions for Galileo receivers;
    • Reusing existing SW and HW for GPS receivers;
    • Converting existing production chains to the new Galileo-specific SW and HW solutions.

    GNSS receivers often use established mathematical models that can determine the receiver position from a fundamental set of parameters, such as satellite orbit and system time. As a consequence, the intrinsic representation of the parameter set is a major factor in the adaptation of the existing design and implementation of SW and HW solutions.

    To reduce the impact of the above needs, a model-based SIS interface specification may play a pivotal role in several ways, such as:

    • reducing ambiguities in the Galileo SIS interface specification;
    • enhancing the communication with the involved stakeholders;
    • linking the SIS interface specification to the design schemas of GNSS receivers — particularly Galileo ones — for tracing the interface elements onto the receiver functional and physical schema, thereby supporting the reuse and adaptation of existing HW and SW solutions;
    • supporting the model-based design of security solutions for blocking, jamming, and spoofing.

    Galileo Project

    In October 2012, the final two IOV satellites were launched into orbit, completing the designed configuration for the Galileo IOV phase — the initial stage of the Galileo constellation development. In this phase, preliminary validation tests will be performed and the initial navigation message will be broadcast to the Galileo ground segment for further validation. Shortly after the conclusion of this phase, a series of launches will take place to gradually deploy the remaining 26 satellites that will form the Galileo Full Operational Capability (FOC) configuration. Currently, the Galileo Early Open Service (EOS) is expected to be available by the end of 2014. The EOS will provide ranging capabilities and will enable receiver manufacturers to begin to design and test their technological solutions for Galileo receivers and Galileo overlay services, such as search and rescue.

    In the meantime, the European GNSS Agency has been established and assigned the governance of the Galileo sub-systems, including activities such as:

    • initiating and monitoring the implementation of security procedures and performing system security audits;
    • system infrastructure management, maintenance, improvement, certification, and standardization, and service provision;
    • development and deployment of activities for the evolution and future generations of the systems, including procurement activities;
    • contributing to the exploitation of the systems, including the marketing and promotion of applications and services, including market analysis.

    With the now-rapid development of the Galileo project, it becomes increasingly important to support the receiver manufacturers in the design and implementation of global navigation solutions based on the Galileo services. This is necessary to guarantee the widespread use of the Galileo services, particularly in an increasingly crowded GNSS panorama.

    Model-Based Systems Engineering

    Model-based systems engineering (MBSE) is predicated on the notion that a system is developed by use of a set of system models that evolve throughout the development lifecycle, from abstract models at the early stages down to the operational system. A visual presentation is provided by FIGURE 1, which shows the roles of MBSE approaches within the systems engineering V-shaped process. Specifically, the MBSE approaches enable the designer to effectively trace the requirements and design alternatives on the descending branch of the “V.” For the same characteristics, MBSE facilitates the verification through a model repository that interconnects not only the design products, but also the stakeholders involved in the entire process. In addition, MBSE approaches support the automatic generation of the documentation and of other artifacts, particularly software. All of these capabilities eventually enable the validation of the implementation activities on the ascending branch of the V-process. Also, in this case, MBSE and the model repository play a major role in connecting design to implementation, and users and designers to developers.

    FIGURE 1. Systems engineering V-process supported by an model-based systems engineering with model repository (courtesy of the INCOSE Survey).
    FIGURE 1. Systems engineering V-process supported by an model-based systems engineering with model repository (courtesy of the INCOSE Survey).

    Main Concepts. MBSE approaches are gaining increasing popularity with the widespread adoption of standard modeling languages, such as Unified Modeling Language (UML) and Systems Modeling Language (SysML).

    UML is a formally defined general-purpose graphical language and is mainly used in the context of software systems development. It has been developed and is being managed by the Object Management Group and is the core standard of the Model Driven Architecture (MDA) effort, which provides a set of standards to shift from code-centric to model-driven software development. By use of an MDA-based approach, a software system is built by specifying and executing a set of automated model transformations.

    SysML is defined as an extension of UML and provides a general-purpose modeling language for systems engineering applications (See FIGURE 2). SysML supports MBSE approaches in the development of complex systems that include hardware, software, information, processes, personnel, and facilities.

    FIGURE 2. UML-SysML relationships. (UML 2 is the second generation version of UML introduced in 2005.)
    FIGURE 2. UML-SysML relationships. (UML 2 is the second generation version of UML introduced in 2005.)

    Advantages. With respect to the conventional document-based approaches, MBSE approaches present the following advantages:

    • Conformance to standard specifications and availability of development tools;
    • Increased level of automation due to the formal specification and execution of model transformations that take as input a model at a given level of abstraction and yield as output a refined model at a lower level of abstraction;
    • Better understanding of the system in its operational context;
    • Support for simulation activities at different levels of detail and at different development stages, from concept exploration to dynamic system optimization;
    • Support for the coherent extension of standard modeling languages to adapt them to a specific target or domain.

    These capabilities have motivated and have been sustaining an increasing trend of moving from document-centric to model-centric systems engineering.

    ICML Language

    UML and SysML are widely used languages for MBSE. A plethora of tools and technologies are available to compose models, transform models into documents, derive software products from models, and share and reuse models by means of repositories. However, neither of these languages offers capabilities for the representation of SIS interfaces, which are the critical interfaces for the design of Galileo receivers. For this reason, we have introduced ICML: a modeling language that can enable a full MBSE approach for the design of Galileo receivers. Moreover, ICML extends UML, and therefore it can integrate with system specifications based on compliant technologies as well as be used within standard tools.

    Layout of Interface Specification. The typical layout of ICML-based interface specification is shown in FIGURE 3. The specification covers the definition of both the message structure and conversion processes. The message structure consists of five abstraction levels, and describes how the data is structured within the message. The conversion processes describe how the data values are transformed between adjacent levels of the message specification.

    FIGURE 3. Layout of ICML-based interface specifications.
    FIGURE 3. Layout of ICML-based interface specifications.

    The message structure is defined at five levels: Data Definition, (Logical) Binary Coding, Logical Binary Structure, Physical Binary Coding, and Physical Signal, each covering specific aspects of the SIS interface specification.

    For example, the Data Definition level covers the specification of the logical data structure, which includes the data items composing the message information. A data item is either of application or control type. An application data item represents a domain-specific concept that conveys the information expected by the message recipient. On the other hand, a control data item represents a domain-independent concept that can support the correctness and integrity verification of the associated application data items. A data item can also be associated with semantic and pragmatic definitions. The former specifies the meaning of the data item and the latter specifies the contextual interpretation for the semantic definition.

    Analogously, the Binary Coding level covers the specification of the binary coding for each of the data items defined at the above level. For a data item, the binary coding is represented as a binary sequence and it includes at least a sequence identifier, the semantic definition, and the pragmatic definitions. Similarly to the above level, the semantic and pragmatic definitions enrich the interface specification, conveying an accurate representation of the binary coding.

    The conversion processes describe the activities to be performed for deriving message values between adjacent levels of the above structural specification. As shown in Figure 3, eight processes should be defined to specify all the conversions between adjacent levels. For example, the DataDefinition2BinaryCoding process defines the activities to be performed for the derivation of the logical binary sequences representing data values. Similarly, the LogicalBinary2PhysicalBinary process defines the activities for the implementation of convolution or encryption algorithms on the logical binary sequence. However, these processes do not always need to be explicitly defined. In particular, if the implementation of a process is trivial or standard, a textual note referring to an external document may suffice for the specification purposes.

    The first prototypal version of ICML has been implemented and can be used within the open source TopCased tool. The prototypal version is available under the GNU General Public License (GPL) v3.0 from the ICML project website. We applied the profile and developed the example ICML-based specification given below.

    Galileo-Like Specification. An ICML-based specification of a Galileo-like OS interface, concerning only the above-defined level 3, would display as shown in FIGURE 4. This figure specifically details a part of a reduced F/NAV (the freely accessible navigation message provided by the E5a signal for the Galileo OS) structure consisting of one data frame made up of two F/NAV subframes.

    FIGURE 4. Example of ICML-based specification of an F/NAV-like message structure at the Logical Binary Coding level.
    FIGURE 4. Example of ICML-based specification of an F/NAV-like message structure at the Logical Binary Coding level.

    Benefits. ICML can bring the above-mentioned MBSE benefits to support GNSS interoperability and to GNSS and Galileo receiver design. For example, ICML can:

    • provide a reference guideline for structuring the specification data and thus facilitating the communication between the Galileo SIS designers and the receiver producers;
    • ease visual inspection of the specification for verification purposes and for the identification of data incompatibilities of two GNSS systems;
    • convey the data semantics as well as the measurement units, to guarantee that the binary data from different GNSS are correctly decoded and interpreted;
    • support syntactical model validation using existing tools;
    • provide support for future advance exploitation by means of a machine-readable data format.

    In particular, the availability of a machine-readable format is also the basis for advanced use cases that can exploit the capabilities of modern computer technologies.

    Advanced Future Use Cases. In line with the above-mentioned MBSE model exploitations, we foresee a number of possible exploitation cases:

    • Automatic generation of the interface specification documents;
    • Collaborative development of the interface specification;
    • Automatic completeness and consistency checking of the interface specification;
    • Integration of SIS specifications with model-driven simulation engineering approaches for the simulation of single- and multi-GNSS receivers;
    • Integration of SIS specifications with receiver design models in SysML, for requirements traceability and reuse of existing GNSS solutions.

    The automatic generation of interface specification documents can be an important capability during the lifecycle of a specification. For example, the specification may be updated several times during the interface design, and the textual documentation may need to be produced several times. Using a model-based approach, it is possible to automate the error-prone activities related to the document writing as well as other important functions such as specification versioning.

    Complex system specifications are often the product of collaborating teams, which may occasionally be geographically dispersed. Using a model-based approach, the interface specification can be stored within a version control system that can be concurrently accessed by team members.

    Completeness and consistency checking is also a manual activity, which demands a high degree of mental attention, and it is consequently highly error prone. Once the specification is available in a machine-readable format, the checking can be easily automated by specifying the verification rules that the interface model must satisfy.

    Existing technologies support the simulation of single- and multi-GNSS receivers. As the SIS specification has a major impact on the internal structure of the receiver, the interface specification is a key input for developing GNSS simulators as well as for determining the boundary properties of the input signal into the receiver, including the admitted analog signal and the format of the digital data.

    Moreover, the model-based interface specification can be integrated with a receiver design schema in SysML. This would be important to provide traceability between the interface requirements and the receiver’s functional and physical components. In the following section, we provide an outline for a preliminary integration between the interface specification and the receiver design.

    Designing Galileo Receivers

    Model-based interface specifications can support the design of Galileo receivers in several ways. For example, a specification can provide a link between Galileo requirements down to the Galileo receiver specifications, as shown in FIGURE 5.

    FIGURE 5. Links between ICML and SysML specifications.
    FIGURE 5. Links between ICML and SysML specifications.

    This capability may be useful in several scenarios. In particular, we have identified three scenarios. Scenario 1 consists of the identification of the receiver requirements that are introduced or modified by the Galileo OS SIS, with respect to existing GPS receivers. Scenario 2 concerns the linking between the ICML specification and the receiver functional schema to identify how a Galileo receiver will differ from existing GPS solutions. Scenario 3 is a development of Scenario 1 and Scenario 2, in which the physical schema definition and the physical components identification (HW and SW) may further exploit the ICML-based approach for supporting the reuse of existing GPS components.

    Below, we detail Scenario 2, introducing a simplified receiver functional schema in SysML and linking the above ICML example to the schema.

    Example Functional Schema. In this section, we illustrate a preliminary SysML representation for a simplified GNSS receiver. However, the figures are meant for exemplification purposes only and are not to be considered fully realistic and detailed for real GNSS receivers. Nevertheless, the SysML hierarchical modeling capabilities can be used to further refine the model, up to a potentially infinitesimal level of detail.

    A GNSS receiver functional schema has been derived from A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach (see Further Reading) and its equivalent SysML internal block diagram (IBD) is shown in FIGURE 6.

    FIGURE 6. High-level receiver internal block diagram (functional schema).
    FIGURE 6. High-level receiver internal block diagram (functional schema).

    In particular, the IBD illustrates the functional blocks (instances and types) and connections among these blocks that define the GNSS receiver. In particular, each of these block types is also described in other diagrams, in which the designers can specify the operations performed by the block, the attributes of the block, the referred properties, and the defined values, for example.

    In this short article, we have particularly focused on the navigation data decoder. The data decoder is defined by a Block Definition Diagram (BDD) and an IBD, which are shown in FIGURES 7 and 8, respectively.

    FIGURE 7. Navigation data decoder block definition diagram.
    FIGURE 7. Navigation data decoder block definition diagram.
    FIGURE 8. Navigation data decoder internal block diagram.
    FIGURE 8. Navigation data decoder internal block diagram.

    In particular, the BDD indicates that the navigation data decoder is composed of four types of blocks: shift buffer, parity checker, binary adder, and data item retriever. The shift buffer receives the incoming physical sequence of bits, which is subsequently verified by the parity checker. The verified sequence is then processed to retrieve the standard binary format from the SIS-specific logical coding for the data item. This function is guided by the data item retriever, which stores the defined properties of each incoming data item, in the form of a physical sequence of bits (level 1). As a consequence, the navigation data decoder is involved with data defined at several of the above-defined ICML levels. From this description, it is also possible to sketch the preliminary IBD diagram of Figure 8.

    Using a model-based approach, it becomes easier to establish links between interface elements and the functional blocks in the receiver schema.

    Moreover, these links can also be decorated with a number of properties that can be used to further describe the type of the relationship between the interface element and the functional block. The link identification is important to the receiver design in several ways. For example, linking the interface elements to the receiver functional blocks, it becomes easier to identify which functional blocks are affected by each element of the SIS interface. Moreover, the tracing can be transitively extended to the physical schema, enabling the receiver designers to more immediately identify which physical components can be reused and which ones must be replaced in existing GNSS solutions.

    We exemplify the tracing of interface elements on the above data decoding functional schema in FIGURE 9. This figure shows the navigation data decoder’s BDD in conjunction with ICML level 3 elements (with a white background). As in Figure 7, the relationships are drawn in red, including a richer set of relationship qualifiers. For example, the <<use>> qualifier indicates that the originating block uses the data specified in the connected ICML element. Similarly, the <<consumes>> qualifier indicates that the originating block takes in input instances of the ICML element. ICML level 4 elements are also relevant to this BDD; however, they are not shown for the sake of conciseness.

    FIGURE 9. Linking level 3 elements to the navigation data decoder block definition.
    FIGURE 9. Linking level 3 elements to the navigation data decoder block definition.

    Conclusions

    Galileo receivers may face market barriers that are inherently raised by the costs linked with the introduction of new technologies with respect to the existing GPS ones. In this article, we have advocated that a model-based SIS interface specification can help mitigate possible extra costs in several ways. For example, the model-based interface specification can ease the communication among stakeholders, promote the reuse and adaptation of existing GPS software and chipsets, and support the implementation of receiver-side multi-GNSS interoperability. With the objective of supporting model-based interface specifications, we have designed ICML, which has been provided with a UML profile implementation in an open-source modeling tool. We have also shown an excerpt of a possible model-based specification for a simplified Galileo OS interface. Moreover, we have outlined how the model-based specification can integrate with SysML models of GNSS receivers and support the reuse and adaptation of existing solutions. A preliminary identification of potential exploitations and further benefits is also included. Further research is ongoing to generalize the existing ICML language to more complex types of SIS interfaces.

    Acknowledgments

    The authors would like to thank the students Serena Annarilli and Carlo Di Bartolomei (University of Rome Tor Vergata) for implementing the first prototype version of the ICML profile. The authors would also like to thank Marco Porretta, European Space Agency (ESA) / European Space Research and Technology Centre (ESTEC), for the suggestions of the GNSS example. The ICML project has been partially sponsored by the ESA Summer of Code in Space Initiative, edition 2012. No endorsement is made for the use of ICML for the official Galileo SIS interface specification.

    DANIELE GIANNI is currently a requirement engineering consultant at EUMETSAT in Germany. EUMETSAT is the European operational satellite agency for monitoring weather, climate and the environment. Gianni received a Ph.D. in computer and control engineering from University of Rome Tor Vergata (Italy), in the field of modeling and simulation, in 2007. He has previously held research appointments at ESA, Imperial College, and Oxford University.

    MARCO LISI is currently GNSS services engineering manager at ESA’s Directorate of Galileo Programme and Navigation- Related Activities at ESTEC in Noordwijk, The Netherlands. He was previously responsible for system engineering, operations, and security activities in the Galileo project. He is also a special advisor to the European Commission on European space policies. Lisi has over thirty years of working experience in the aerospace and telecommunication sectors, holding management positions in R&D, and being directly involved in a number of major satellite programs, including Artemis, Meteosat Operational, Meteosat Second Generation, Globalstar, Cosmo-Skymed, and more recently Galileo.

    PIERLUIGI DE SIMONE is currently working on system assembly, integration, and verification for the Galileo mission in ESA. He has worked on many software developments in the fields of graphics, safe mode software, and visual programming. He has worked on many space missions including Helios, Meteosat, Metop, Cosmo-Skymed, and Galileo. His main interests are in modeling paradigms and cryptography and he holds a master’s degree in physics from University of Rome Tor Vergata.

    ANDREA D’AMBROGIO is associate professor of computer science at the University of Rome Tor Vergata. He has formerly been a research associate at the Concurrent Engineering Research Center of West Virginia University in Morgantown, West Virginia. His research interests are in the areas of engineering and validation of system performance and dependability, model-driven systems and software engineering, and distributed simulation.

    MICHELE LUGLIO is associate professor of telecommunication at University of Rome  Tor Vergata. He works on designing satellite systems for multimedia services both mobile and fixed.  He received the Ph.D. degree in telecommunications in 1994.

    FURTHER READING

    • Interface Communication Modeling Language (ICML)

    ICML project website.

    “A Modeling Language to Support the Interoperability of Global Navigation Satellite Systems” by D. Gianni, J. Fuchs, P. De Simone, and M. Lisi in GPS Solutions, Vol. 17, No. 2, 2013, pp. 175–198, doi: 10.1007/s10291-012-0270-z.

    •  Use of ICML for GNSS Signal-in-Space Interface Specification

    “A Model-based Signal-In-Space Interface Specification to Support the Design of Galileo Receivers” by D. Gianni, M. Lisi, P. De Simone, A. D’Ambrogio, and M. Luglio in Proceedings of the 6th ESA Workshop on Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing (NAVITEC), Noordwijk, The Netherlands, December 5–7, 2012, 8 pp., doi: 10.1109/NAVITEC.2012.6423066.

    “A Model-Based Approach to Signal-in-Space Specifications for Designing GNSS Receivers” by D. Gianni, J. Fuchs, P. De Simone, and M. Lisi in Inside GNSS, Vol. 6, No. 1, January/February 2011, pp. 32–39.

    • Related Modeling Languages

    The Unified Modeling Language Reference Manual, 2nd edition, by G. Booch, J. Rumbaugh, and I. Jacobson, published by Addison-Wesley Professional, an imprint of Pearson Education, Inc., Upper Saddle River, New Jersey, 2005.

    A Practical Guide to SysML: The Systems Modeling Language, 2nd edition, by S. Friedenthal, A. Moore, and R. Steiner, published by Morgan Kaufman and the Object Management Group Press, an imprint of Elsevier Inc., Waltham, Massachusetts, 2012.

    • Systems Engineering

    Systems Engineering: Principles and Practice, 2nd edition, by A. Kossiakoff, W.N. Sweet, S.J. Seymour, and S.M. Biemer, published by John Wiley & Sons, Inc., Hoboken, New Jersey, 2011.

    Survey of Model-Based Systems Engineering (MBSE) Methodologies, INCOSE-TD-2007-003-02, published by Model Based Systems Engineering Initiative, International Council on Systems Engineering, Seattle, Washington, 2008.

    • GNSS Receiver Operation

    A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, and S.H. Jensen, published by Birkhäuser Boston, Cambridge, Massachusetts, 2007.

    • Galileo Status and Plans

    “Status of Galileo” (Galileo System Workshop) by H. Tork in the Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 2474–2502.

    “Galileo Integrated Approach to Services Provision” (Galileo System Workshop) by M. Lisi in the Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 2572–2596.

    European GNSS (Galileo) Open Service Signal in Space Interface Control Document, Issue 1.1, European Union and European Space Agency, September 2012.

     

  • GNSS RF Compatibility Assessment: Interference among GPS, Galileo, and Compass

    By Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    A comprehensive methodology combines spectral-separation and code-tracking spectral-sensitivity coefficients to analyze interference among GPS, Galileo, and Compass. The authors propose determining the minimum acceptable degradation of effective carrier-to-noise-density ratio, considering all receiver processing phases, and conclude that each GNSS can provide a sound basis for compatibility with other GNSSs with respect to the special receiver configuration.
    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu
    Power spectral densities of GPS, Galileo, and Compass signals in the L1 band.

    As GNSSs and user communities rapidly expand, there is increasing interest in new signals for military and civilian uses. Meanwhile, multiple constellations broadcasting more signals in the same frequency bands will cause interference effects among the GNSSs. Since the moment Galileo was planned, interoperability and compatibility have been hot topics. More recently, China has launched six satellites for Compass, which the nation plans to turn into a full-fledged GNSS within a few years. Since Compass uses similar signal structures and shares frequencies close to other GNSSs, the radio frequency (RF) compatibility among GPS, Galileo, and Compass has become a matter of great concern for both system providers and user communities.

    Some methodologies for GNSS RF compatibility analyses have been developed to assess intrasystem (from the same system) and intersystem (from other systems) interference. These methodologies present an extension of the effective carrier power to noise density theory introduced by John Betz to assess the effects of interfering signals in a GNSS receiver. These methodologies are appropriate for assessing the impact of interfering signals on the processing phases of the receiver prompt correlator channel (signal acquisition, carrier-tracking loop, and data demodulation), but they are not appropriate for the effects on code-tracking loop (DLL) phase. They do not take into account signal processing losses in the digital receiver due to bandlimiting, sampling, and quantizing. Therefore, the interference calculations would be underestimated compared to the real scenarios if these factors are not taken into account properly. Based on the traditional methodologies of RF compatibility assessment, we present here a comprehensive methodology combining the spectral separation coefficient (SSC) and code tracking spectral sensitivity coefficient (CT_SSC), including detailed derivations and equations.

    RF compatibility is defined to mean the “assurance that one system will not cause interference that unacceptably degrades the stand-alone service that the other system provides.” The thresholds of acceptability must be set up during the RF compatibility assessment. There is no common standard for the required acceptability threshold in RF compatibility assessment. For determination of the required acceptability thresholds for RF compatibility assessment, the important characteristics of various GNSS signals are first analyzed, including the navigation-frame error rate, probability of bit error, and the mean time to cycle slip. Performance requirements of these characteristics are related to the minimum acceptable carrier power to effective noise power spectral density at the GNSS receiver input. Based on the performance requirements of these characteristics, the methods for assessing the required acceptability thresholds that a GNSS receiver needs to correctly process a given GNSS signal are presented.

    Finally, as signal spectrum overlaps at L1 band among the GPS, Galileo, and Compass systems have received a lot of attention, interference will be computed mainly on the L1 band where GPS, Galileo, and Compass signals share the same band. All satellite signals, including GPS C/A, L1C, P(Y), and M-code; Galileo E1, PRS, and E1OS; and Compass B1C and B1A, will be taken into account in the simulation and analysis.

    Methodology

    To provide a general quantity to reflect the effect of interference on characteristics at the input of a generic receiver, a traditional quantity called effective carrier-power-to-noise-density (C/N0), is noted as (C/N0)eff_SSC. This can be interpreted as the carrier-power-to-noise-density ratio caused by an equivalent white noise that would yield the same correlation output variance obtained in presence of an interference signal. When intrasystem and intersystem interference coexist, (C/N0)eff_SSC can be expressed as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Ĝs(f) is the normalized power spectral density of the desired signal defined over a two-sided transmit bandwith ßT, C is the received power of the useful signal. N0 is the power spectral density of the thermal noise. In this article, we assume N0 to be –204 dBW/Hz for a high-end user receiver. Ĝi,j(f) is the normalized spectral density of the j-th interfering signal on the i-th satellite defined over a two-sided transmit bandwith ßT, Ci,j the received power of the j-th interfering signal on the i-th satellite, ßr the receiver front-end bandwidth, M the visible number of satellites, and Ki the number of signals transmitted by satellite i. Iext is the sum of the maximum effective white noise power spectral density of the pulsed and continuous external interference.

    It is clear that the impact of the interference on (C/N0)eff_SSC is directly related to the SSC of an interfering signal from the j-th interfering signal on the i-th satellite to a desired signal s, the SSC is defined as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    From the above equations it is clear that the SSC parameter is appropriate for assessing the impact of interfering signals on the receiver prompt correlator channel processing phases (acquisition, carrier phase tracking, and data demodulation), but not appropriate to evaluate the effects on the DLL phase. Therefore, a similar parameter to assess the impact of interfering signals on the code tracking loop phase, called code tracking spectral sensitivity coefficient (CT_SSC) can be obtained. The CT_SSC is defined as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    where Δ is the two-sided early-to-late spacing of the receiver correlator.

    To provide a metric of similarity to reflect the effect of interfering signals on the code tracking loop phase, a quantity called CT_SSC effective carrier power to noise density (C/N0), denoted (C/N0)eff_CT_SSC, can be derived. When intrasystem and intersystem interference coexist, this quantity can be expressed as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    where IGNSS_CT_SSC is the aggregate equivalent noise power density of the combination of intrasystem and intersystem interference.

    Equivalent Noise Power Density. When more than two systems operate together, the aggregate equivalent noise power density IGNSS ( IGNSS_SSC or IGNSS_CT_SSC ) is the sum of two components

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    IIntra is the equivalent noise power density of interfering signals from satellites belonging to the same system as the desired signal, and IInter is the aggregate equivalent noise power density of interfering signals from satellites belonging to the other systems.

    In fact, recalling the SSC and CT_SSC definitions, hereafter, denoted Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niuor Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu as Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu, the equivalent noise power density (IIntra or IInter) can be simplified as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    where Ci,j is the user received power of the j-th signal belonging to the i-th satellite, as determined by the link budget.

    For the aggregate equivalent noise power density calculation, the constellation configuration, satellite and user receiver antenna gain patterns, and the space loss are included in the link budget. User receiver location must be taken into account when measuring the interference effects.

    Degradation of Effective C/N0. A general way to calculate (C/N0)eff, (C/N0)eff_SSC , or (C/N0)eff_CT_SSC introduced by interfering signals from satellites belonging to the same system or other systems is based on equation (1) or (4). In addition to the calculation of (C/N0)eff , calculating degradation of effective C/N0 is more interesting when more than two systems are operating together. The degradation of effective C/N0 in the case of the intrasystem interference in dB can be derived as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Similarly, the degradation of effective C/N0 in the case of the intersystem interference is

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Bandlimiting, Sampling, and Quantization. Traditionally, the effect of sampling and quantization on the assessment of GNSS RF compatibility has been ignored. Previous research shows that GNSS digital receivers suffer signal-to-noise-plus interference ration (SNIR) losses due to bandlimiting, sampling, and quantization (BSQ). Earlier studies also indicate a 1.96 dB receiver SNR loss for a 1-bit uniform quantizer. Therefore, the specific model for assessing the combination of intrasystem and intersystem interference and BSQ on correlator output SNIR needs to be employed in GNSS RF compatibility assessment.

    Influences of Spreading Code and Navigation Data. In many cases, the line spectrum of a short-code signal is often approximated by a continuous power spectral density (PSD) without fine structure. This approximation is valid for signals corresponding to long spreading codes, but is not appropriate for short-code signals, for example, C/A-code interfering with other C/A-code signals. As one can imagine, when we compute the SSC, the real PSDs for all satellite signals must be generated. It will take a significant amount of computer time and disk storage. This fact may constitute a real obstacle in the frame of RF compatibility studies. Here, the criterion for the influences of spreading code and navigation data is presented and an application example is demonstrated. For the GPS C/A code signal, a binary phase shift keying (BPSK) pulse shape is used with a chip rate fc = 1.023 megachips per seconds (Mcps). The spreading codes are Gold codes with code length N = 1023. A data rate fd = 50 Hz is applied. As shown in Figure 1, the PSD of the navigation data (Gd(f) = 1/fd sin c2 (f/fd) ) replace each of the periodic code spectral lines. The period of code spectral lines is T = 1/LTC. The mainlobe width of the navigation data is Bd =2fd.

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu
    Figure 1. Fine structure of the PSD of GPS C/A code signal (fd = 50 Hz ,without
    logarithm operation).

    For enough larger data rates or long spreading codes, the different navigation data PSDs will overlap with each other. The criterion can be written as:

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Finally,

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    When criterion L ≥ fc/fd is satisfied, navigation signals within the bandwidth are close to each other and overlap in frequency domain. The spreading code can be treated as a long spreading code, or the line spectrum can be approximated by a continuous PSD.

    C/N0 Acceptability Thresholds

    Receiver Processing Phase. The determination of the required acceptability thresholds consider all the receiver processing phases, including the acquisition, carrier tracking and data demodulation phases.The signal detection problem is set up as a hypothesis test, testing the hypothesis H1 that the signal is present verus the hypothesis H0 that the signal is not present. In our calculation, the detection probability pd and the false alarm probability pf are chosen to be 0.95 and 10–4, respectively. The total dwell time of 100 ms is selected in the calculation.

    A cycle slip is a sudden jump in the carrier phase observable by an integer number of cycles. It results in data-bit inversions and degrades performance of carrier-aided navigation solutions and carrier-aided code tracking loops. To calculate the minimum acceptable signal C/N0 for a cycle-slip-free tracking, the PLL and Costas loop for different signals will be considered. A PLL of third order with a loop filter bandwidth of 10 Hz and the probability of a cycle slip of 10–5 are considered. We can find the minimum acceptable signal C/N0 related to the carrier tracking process. For the scope of this article, the vibration induced oscillator phase noise, the Allan deviation oscillator phase noise, and the dynamic stress error are neglected.

    In terms of the decoding of the navigation message, the most important user parameters are the probability of bit error and the probability of the frame error. The probability of frame error depends upon the organization of the message frame and various additional codes. The probability of the frame error is chosen to be 10–3. For the GPS L1C signal using low-density parity check codes, there is no analytical method for the bit error rate or its upper bound. Due to Subframe 3 data is worst case, the results are obtained via simulation. In this article, the energy per bit to noise power density ratio of 2.2 dB and 6 dB reduction due to the pilot signal are taken into account, and the loss factor of the reference carrier phase error is also neglected.

    Minimum Acceptable Degradation C/N0. The methods for accessing the minimum acceptable required signal C/N0 that a GNSS receiver needs to correct
    ly process a desired signal are provided above. Therefore, the global minimum acceptable required signal carrier to noise density ratio (C/N0)global_min for each signal and receiver configuration can be obtained by taking the maximum of minima. In addition to the minimum acceptable required signal C/N0, obtaining the minimum acceptable degradation of effective C/N0 is more interesting in the GNSS RF compatibility coordination. For intrasystem interference, when only noise exists, the minimum acceptable degradation of effective C/N0 in the case of the intrasystem interference can be defined as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Similarly, the minimum acceptable degradation of effective C/N0 in the case of the intersystem interference can be expressed as

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Table 1 summarizes the calculation methods for the minimum acceptable required of degradation of effective C/N0.

    Simulation and Analysis

    Table 2 summarizes the space constellation parameters of GPS, Galileo, and Compass.

    For GPS, a 27-satellite constellation is taken in the interference simulation. Galileo will consist of 30 satellites in three orbit planes, with 27 operational spacecraft and three in-orbit spares (1 per plane). Here we take the 27 satellites for the Galileo constellation. Compass will consist of 27 MEO satellites, 5 GEO, and 3 IGSO satellites. As Galileo and Compass are under construction, ideal constellation parameters are taken from Table 2.

    Signals Parameters. The PSDs of the GPS, Galileo and Compass signals in the L1 band are shown in the opening graphic. As can be seen, a lot of attention must be paid to signal spectrum overlaps among these systems. Thus, we will concentrate only on the interference in the L1 band in this article. All the L1 signals including GPS C/A, L1C, P(Y), and M-code; Galileo E1 PRS and E1OS; and Compass B1C and B1A will be taken into account in the simulation and analysis.

    Table 3 summarizes GPS, Galileo and Compass signal characteristics to be transmitted in the L1 band.

    Simulation Parameters. In this article, all interference simulation results refer to the worst scenarios. The worst scenarios are assumed to be those with minimum emission power for desired signal, maximum emission power for all interfering signals, and maximum (C/N0)eff degradation of interference over all time steps. Table 4 summarizes the simulation parameters considered here.

    SSC and CT_SSC. As shown in expression (1) or (4), (C/N0)eff is directly related to SSC or CT_SSC of the desired and interfering signals. Figure 2 and Figure 3 show both SSC and CT_SSC for the different interfering signals and for a GPS L1 C/A-code and GPS L1C signal as the desired signal, respectively. The figures obviously show that CT_SSC is significantly different from the SSC. The results also show that CT_SSC depends on the early-late spacing and its maximal values appear at different early-late spacing.

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu
    FIGURE 2. SSC and CT_SSC for GPS C/A-code as desired signal.
    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu
    FIGURE 3. SSC and CT_SSC for GPS L1C as desired signal.

    The CT_SSC for different civil signals in the L1 band is calculated using expression (3). The power spectral densities are normalized to the transmitter filter bandwidth and integrated in the bandwidth of the user receiver. As we saw in expression (3), when calculating the CT_SSC, it is necessary to consider all possible values of early-late spacing. In order to determine the maximum equivalent noise power density (IIntra or IInter), the maximum CT_SSC will be calculated within the typical early-late spacing ranges (0.1–1 chip space).

    Results and Analysis

    In this article we only show the results of the worse scenarios where GPS, Galileo, and Compass share the same band. The four worst scenarios include:

    ◾ Scenario 1: GPS L1 C/A-code ← Galileo and Compass (GPS C/A-code signal is interfered with by Galileo and Compass)

    ◾ Scenario 2: GPS L1C ← Galileo and Compass (GPS L1C signal is interfered with by Galileo and Compass)

    ◾ Scenario 3: Galileo E1 OS ← GPS and Compass (Galileo E1 OS signal is interfered with by GPS and Compass)

    ◾ Scenario 4: Compass B1C ← GPS and Galileo (Compass B1C signal is interfered with by GPS and Galileo)

    Scenario 1. The maximum C/N0 degradation of GPS C/A-code signal due to Galileo and Compass intersystem interference is depicted in Figure 4 and Figure 5.

    Scenario 2. Figure 6 and Figure 7 also show the maximum C/N0 degradation of GPS L1C signal due to Galileo and Compass intersystem interference.

    Scenario 3. The maximum C/N0 degradation of Galileo E1OS signal due to GPS and Compass intersystem interference is depicted in Figure 8 and Figure 9.

    Scenario 4. For scenario 4, Figure 10 and Figure 11 show the maximum C/N0 degradation of Compass B1C signal due to GPS and Galileo intersystem interference.

    From the results from these simulations, it is clear that the effects of interfering signals on code tracking performance may be underestimated in previous RF compatibility methodologies. The effective carrier power to noise density degradations based on SSC and CT_SSC are summarized in Table 5. All the results are expressed in dB-Hz.

    C/N0 Acceptability Thresholds. All the minimum acceptable signal C/N0 for each GPS, Galileo, and Compass civil signal are simulated and the results are listed in Table 6. The global minimum acceptable signal C/N0 is summarized in Table 7. All the results are expressed in dB-Hz.

    Effective C/N0 Degradation Thresholds. All the minimum effective C/N0 for each GPS, Galileo and Compass civil signal due to intrasystem interference are simulated, and the results are listed in Table 8. Note that the high-end receiver configuration and external interference are considered in the simulations. According to the method summarized in Table 1, the effective C/N0 degradation acceptability thresholds can be obtained. The results are listed in Table 9.

    As can be seen from these results, each individual system can provide a sound basis for compatibility with other GNSSs with respect to the special receiver configuration used in the simulations. However, a common standard for a given pair of signal and receiver must be selected for all GNSS providers and com
    munities.

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Source: Wei Liu, Xingqun Zhan, Li Liu, and Mancang Niu

    Conclusions

    At a minimum, all GNSS signals and services must be compatible. The increasing number of new GNSS signals produces the need to assess RF compatibility carefully. In this article, a comprehensive methodology combing the spectral separation coefficient (SSC) and code tracking spectral sensitivity coefficient (CT_SSC) for GNSS RF compatibility assessment were presented. This methodology can provide more realistic and exact interference calculation than the calculation using the traditional methodologies. The method for the determination of the required acceptability thresholds considering all receiver processing phases was proposed. Moreover, the criterion for the influences of spreading code and navigation data was also introduced.

    Real simulations accounting for the interference effects were carried out at every time and place on the earth for L1 band where GPS, Galileo, and Compass share the same band. It was shown that the introduction of the new systems leads to intersystem interference on the already existing systems. Simulation results also show that the effects of intersystem interference are significantly different by using the different methodologies. Each system can provide a sound basis for compatibility with other GNSSs with respect to the special receiver configuration in the simulations.

    At the end, we must point out that the intersystem interference results shown in this article mainly refer to worst scenario simulations. Though the values are higher than so-called normal values, it is feasible for GNSS interference assessment. Moreover, the common standard for a given signal and receiver pair must be selected for and coordinated among all GNSS providers and communities.

    This article is based on the ION-GNSS 2010 paper, “Comprehensive Methodology for GNSS Radio Frequency Compatibility Assessment.”

    WEI LIU is a Ph.D. candidate in navigation guidance and control at Shanghai Jiao Tong University, Shanghai, China. XINGQUN ZHAN is a professor of navigation guidance and control at the same university. LI LIU and MANCANG NIU are Ph.D. candidates in navigation guidance and control at the university.