Russia’s April 1 GLONASS blackout occurred, ironically, only hours after the U.S. House of Representatives passed legislation to preserve infrastructure that could support a back-up system for GPS that could be used for critical infrastructure and applications in the event of a similar disaster occurring in the United States.
The 2014 Coast Guard Authorization Act requires the Department of Homeland Security (DHS) to halt dismantling and disposal of infrastructure that could be used for a terrestrial system during times and in places where GPS is not available.
DHS had announced in 2008 that it would build such a back-up system, but it never did so, and actually began dismantling, destroying, and divesting itself of Loran equipment and properties. The equipment, facilities, and sites could be used to implement a new-generation eLoran system for GPS back-up, among other applications. Despite strong recommendations to the contrary by its own panel of experts, the Obama administration, DHS, and the Coast Guard moved in 2009 to kill the Loran program.
Ever watchful, Congress has lately become more visibly concerned about the vulnerability of the nation’s space systems. The 2014 National Defense Authorization Act tasked the administration with reporting on how it was going to provide necessary national security capabilities when space systems were disrupted. More recently, Congressmen Duncan Hunter (Republican, California), chair of the House Coast Guard and Marine Transportation Subcommittee, held a hearing at which he expressed his concern that the nation has no back-up for GPS. He also expressed his frustration with the Department of Homeland Security, reporting that “They said they need to do a study about their study.”
Congressman John Garamendi (Democrat, California), commented “GPS will go down one day. The question is, is there a backup?”
The legislation passed by the House authorizes DHS to partner with public or private entities to build a system that would not only backup GPS, but also work indoors, underground and underwater — all characteristics of long-wave Loran technology.
Dana Goward, president of the Resilient Navigation and Timing Foundation, said such a project would be relatively inexpensive. “If the existing equipment and infrastructure are preserved and reused, the system could be restored and put into operation for less than half the cost to dispose of it.”
“It isn’t an issue of money,” Goward continued. “It is a question of the government taking this problem seriously and acting on it.”
The foundation has as offered to partner with the government to build the system.
“Our government has known about this issue for a long time,” Goward said. “At least since 2001. And there has been a standing presidential direction to obtain back-up capability since 2004. But for some reason, it hasn’t yet happened.”
The U.S. government’s official information website about GPS has recently updated its page on eLoran and Loran-C with a tracking log for Coast Guard and Maritime Transportation Act of 2014, which now goes to the Senate.
India’s Indian Space Research Organisation (ISRO) launched its second navigation satellite today, April 4, at 11:44 UTC. A Polar Satellite Launch Vehicle (PSLV) rocket launched the IRNSS-1B spacecraft in a mission originating from the Satish Dhawan Space Centre.
Liftoff was on schedule. IRNSS-1B is the second of seven satellites that comprise the first-generation Indian Regional Navigation Satellite System (IRNSS). IRNSS-1B will join IRNSS-1A already in orbit in forming the first pair of satellites for the IRNSS.
Watch the launch in this video:
The IRNSS system will consist of three geostationary satellites and two pairs of spacecraft in inclined geosynchronous orbits. Each IRNSS satellite uses a rubidium-based atomic clock to keep time, transmitting signals on L and S-band frequencies at 1,176.45 and 2492.028 megahertz respectively. A C-band transponder and an array of retroreflectors will be used to determine ranging data for calibration, according to NASASpaceflight.com.
“From the reports on GLONASS problems, we have an explanation that may be used in our technical support replies:
“Our analysis reveals the GLONASS integration algorithms skipped an interval of around 1.5 minutes at the control centre software.
“At 21:00 UTC April 1, all GLONASS satellites received an orbit state (ephemeris) which was clearly several minutes ahead of the current orbit shape without actually changing the applicable reference time stamp. In other words, future orbit-position, velocity and accelerations were assigned to a current reference timestamp.
“This led to incorrect orbit positions for all GLONASS satellites and subsequent problems with receiver using GLONASS measurements.
“In our receivers, RAIM rejected the solutions because of the large GLONASS errors, and could only work with GPS only and the recently revised RAIM settings for a Base (SRL,ON,-6,-4,-4).
“The issue is now rectified, and the GLONASS constellation is back to normal.”
Yesterday we posted news of an 11-hour downtime for the full GLONASS constellation, due to an upload of bad ephemerides. Coincidentally, during that 11-hour period, the mass-market chip company Broadcom was conducting multi-constellation receiver tests in Asia. Frank van Diggelen, Broadcom’s chief GNSS scientist and vice president says, “We have definitive data to show how a multi-constellation receiver survives such an outage.”
Here are the pictures, and the story they tell.
Test data coincident with the GLONASS ephemeris disruption of April 1 and 2 showing conclusively how a GPS/GLONASS/QZSS/BEIDOU receiver survives the complete disruption of one of the constellations.
On April 2 at 1:00 a.m. Moscow time, bad ephemeris was uploaded to all satellites (see chart at the bottom of this story).
There are two receivers shown here, from two different manufacturers, both in smartphones. The yellow dots are for a GPS/GLONASS receiver; the blue dots are from the Broadcom 47531 receiver which tracks GPS/GLONASS/QZSS/BeiDou signals simultaneously. The 47531 receiver includes logic to use redundant measurements to check the validity of all measurements. It successfully identified and removed the bad GLONASS ephemeris 100 percent of the time, as can be seen by the continuity and accuracy of the positions.
Here is the satellite outage chart from yesterday’s story. All GLONASS satellites were restored to healthy state after the 11-hour interruption.
Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.
By Tim Reynolds, GPS World’s contributing editor for Europe
This spring, two Brussels conferences focused on new possibilities and modes of transport enabled by satellite navigation, showing the added value delivered by current and future European GNSS solutions.
The European GNSS Agency (GSA) hosted the first gathering in February, discussing its GNSS Applications Action Plan in areas relating to road transport including smart tachographs, long-range buses, transport of dangerous goods, multimodal logistics, and road tolling. The 11th Annual Road User Charging Conference (RUC) in March, an industrial gathering, highlighted recent developments in truck tolling and a possible future breakthrough for lighter vehicles.
Huge Market
The GSA identified the road sector as the largest GNSS market segment (with location-based services) in its October 2013 Market Report. Most GNSS devices were already enabled for European GNSS services, either via EGNOS or Galileo. Developments such as lower costs for connectivity, growing numbers of embedded devices, intelligent transport systems (ITS), and vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, together with new European Union policies and regulations, drive new requirements for vehicle positioning, and GNSS technologies are poised to fulfill these.
In two specific policy areas, road tolling and eCall emergency response, GNSS shows particular promise for adding value and providing flexible solutions. The GSA manages a large portfolio of research and innovation projects to develop near-market applications in this area.
e-Freight
E-Freight, a vision of a paperless freight transport system where electronic data flow is linked to the physical flow of goods, can lead to future intelligent-cargo concepts to further automate and improve logistics. Positioning services naturally form an integral part of this concept. The increased availability, resilience, integrity, and accuracy offered by European GNSS will support the uptake and efficiency of e-Freight systems through georeferenced cargo-status monitoring, among other services, seamlessly delivered across transport modes and national borders.
Road Tolling
The GSA delivered its perspective on road tolling in advance of the later industrial conference. Location-based charging offers flexibility, easy extension of schemes, low transaction costs, and — most promising from an agency point of view — could have a big impact on traffic management and environmental policy. GNSS is becoming the technology of choice for free-flow road tolling with its three main advantages: coverage, availability, and no direct installation costs.
The final GSA presentation focused on authentication services offered by Galileo to benefit the next-generation digital tachograph, a device fitted to a vehicle that automatically records its speed and distance, together with the driver’s activity selected from a choice of modes. New government proposals for the digital tachograph will mandate the inclusion of GNSS technology.
Clearly, a tachograph requires a robust and trusted GNSS service that is also very low-cost and resilient against spoofing and other interference. An authentification signal provided via the Galileo Open Service could provide a suitable solution free of charge, offering global coverage and easily initiated in existing Galileo-enabled receivers and terminals when the service was introduced. There is growing interest in such a service and its market potential from a range of stakeholders.
Road-User Charging
GNSS should be a key enabling technology for a scalable and cost-effective approach to fair and flexible road charging. But despite its great promise, implementation of such schemes have proven difficult on both sides of the Atlantic.
GNSS-enabled road-use charging systems now operate in Switzerland, Germany, Slovakia, and Hungary for heavy-goods vehicles (HGVs). Plans are in hand for a similar scheme in France covering 15,000 kilometers of national roads. Russia aims to introduce a GLONASS-mandated operation, initially for 50,000 kilometers of federal road and perhaps half a million kilometers of regional roads.
Belgium plans a HGV GNSS-enabled system to start in 2016, initially using GPS and GLONASS signals, eventually covering its full 150,000-kilometer road system. On-board units (OBUs) will be mandatory, and the system will have the capacity to define up to 10,000 toll rates dependent on factors such as location, time of day, direction of travel, road, and vehicle category.
Factor of Seven. The flexibility and scalability of a GNSS-based charging system was demonstrated by the SkyToll organization that operates the road-user charging scheme for HGVs in the Slovak Republic. This system’s network coverage has recently been extended seven-fold from main motorways and major roads to encompass 17,762 kilometers, effectively bring all motorways and class 1, 2, and 3 roads under charge.
To achieve this with a terrestrial system would have required the construction 4,000 gantries, but the huge expansion was built using software in three months. “This is only possible via GNSS,” stated spokesperson Miroslav Bobošik.
The two-way communications possible with GNSS-enabled OBUs also meant that tariff and network models could be updated and amended quickly and easily. Charge collection efficiency exceeds 99 percent and is independent of road type. “There is a clear trend to GNSS-enabled systems due to their flexibility, efficiency and fast implementation,” said Bobošik.
Belgium First? On the first day of the RUC conference, a Flemish regional government spokesperson described plans for the Belgian road-user charging system for HGVs heavier than 3.5 tonnes that could be launched across the whole of the country in 2016.
In parallel to these developments for HGVs, a major pilot project for lighter vehicles, that is, passenger automobiles, has just started in Belgium’s GEN-zone. This area is effectively the capital city, Brussels, and its surrounding provinces of Flemish and Wallonian Brabant. The pilot will test the practicalities of a GNSS-enabled mileage-based charging system and involves 1,000 selected participants in a three-month trial. First results will be available in April, and the final report is due in the summer. This report will form the basis of future national policy on road-user charging and will likely be on the desk of the new Minister for Transport when he or she takes office after the upcoming Belgian elections.
If the political will is there — and post-election the necessary political capital may well be in place — could Belgium become the first nation to implement a GNSS-enabled road-user charging scheme for all vehicles as early as 2016? Watch this space!
Tim Reynolds is director of Inta Communication Ltd. and a long-term Brussels observer writing on many aspects of European government policy and implementation for a range of clients and publications. The material presented here was first prepared in a somewhat different form for the GSA.He is the contributing editor for GPS World’s new quarterly e-newsletter, EAGER: the European GNSS and Earth Observation Report. Subscribe free at env-gpsworld-integration.kinsta.cloud/subscribe.
In the mass market, individuals around the world are creating vast quantities of location data and GPS traces using not only GPS, but also Russia’s GLONASS, Europe’s Galileo, China’s Compass, and India’s Regional Navigational Satellite System. The value of this data and the value chains that produce it will increase significantly with an increase in interoperability of these satnav systems. Currently, non-interoperability represents a serious obstacle to the growth of the GPS market.
The overall system-of-system’s diversity of data formats, data models, processing models and associated custom- built one-to-one communication interfaces significantly inhibits introduction of new subsystems and also new GPS-dependent systems that would support development of future classes of stakeholders. “Many-to-many” networks based on open standards can create interoperability as well as opportunities for the introduction of new technologies, value-added data products, and new users.
To address this problem, sponsors of the 2012 Open Geospatial Consortium (OGC) OWS-9 Interoperability Testbed, including the U.S. National Geospatial-Intelligence Agency (NGA), documented a set of use cases and associated interoperability requirements, selected strategically to address problems whose solutions would be applicable in a wide variety of GPS value chains.
Technology providers participating in the testbed then implemented standards-based solutions that addressed the requirements. These were documented in a draft Engineering Report, “Use of SWE Common and SensorML for GPS Messaging.” The document focuses on the use of the OGC Sensor Web Enablement (SWE) Common Data 2.0 encodings to support an interoperable messaging description and encoding for the next-generation GPS message streams into and out of processing services that provide improved GPS navigation accuracy.
Standards. The OGC Sensor Web Enablement (SWE) suite of standards specifies models and XML encodings that provide a framework within which the geometric, dynamic, and observational characteristics of all types of sensors and sensor systems can be defined.
Furthermore, through standard web-service interfaces, one can task sensor and actuator systems and have immediate access to observations and alerts. SWE standards, now widely implemented around the world, enable developers to make all types of networked sensors, transducers, and sensor data repositories discoverable, accessible, and usable via the Web or other networks. OGC standards are downloadable at no charge, for use by anyone.
OGC Testbed
The OGC OWS-9 testbed’s OWS Innovations thread included a hands-on prototyping activity that addressed a particular set of interoperability requirements related to GPS accuracy.
GPS relies on accurate knowledge regarding the position, measured time, and state of the satellites, provided to GPS devices and processing centers in the form of satellite ephemeris data and status reports. The accuracy of the system relies on communication between the satellites themselves, the data collection systems, the data processing centers, and the GPS devices that ultimately determine their own location. This communication is through various data streams that consist of predefined message structures and encodings.
The accuracy of the positions derived from GPS can be negatively affected by several well-known factors. Improvements to the derived positions within the current operational system can occur (1) through occasional (once a day or once every few hours) updates to the satellites’ clock and ephemeris on-board information, or (2) through post- processing for applications such as geodetic surveying or image processing and georectification. Efforts are underway to provide more timely updates to satellites or positioning devices to improve the accuracy of positioning in real-time.
The GPS Correction Process
One view of the current system for correcting GPS positioning is provided in Figure 1. A GPS positioning unit (shown as a device with red thumb tack) receives signals from four or more GPS satellites derives its position. In addition, the information being sent by all satellites in the GPS system is also received at various receiving stations, stored as raw navigation data, and used to correct the clock and position information for all of the satellites. The correction process can utilize one or more operational processing systems for correcting satellite clock and ephemeris information. Each of these systems tends to utilize particular data sources and often output their results in different message structures and encodings.
FIGURE 1. Typical flow of data within the GPS correction system.
One such system for correcting the timing and positioning of GPS satellites is Estimation and Prediction of Orbits and Clocks to High Accuracy (EPOCHA). Currently, navigation and timing improvements are only uploaded to the satellites and GPS devices once a day. To improve the EPOCHA system, the National Geospatial Intelligence Agency (NGA) is researching the logistics and benefits of updating the navigation and timing information at much shorter time frames (for example, every 2–15 minutes).
The corrected satellite clock and state data can then be sent to the satellites, to the processing centers to improve geolocation of real-time or archived positions or remotely sensed observations, and to devices in the field to improve real-time position measurements.
A processing system in widespread use for applying these corrections to positional measurements is the open-source GPS Toolkit (GPSTk). This software was used in OWS-9 to demonstrate the processing of SWE Common encoded GPS data within a Web-enabled environment.
As shown in Figure 1, the data flowing between archiving and processing components exist in a wide variety of formats. Currently, these message streams consist of message structures defined through various documents, some of which have restricted access. Additionally, these streams and the messages they contain are being encoded in various formats, including, for example, a binary exchange format (BINEX), a system-specific XML schema, an HDF5 file format, several text-based formats, and others.
The message components within each of these formats are inconsistent, even though two messages may describe similar information. Often a processing system is required to read data and output results in multiple formats and to understand the inconsistencies between them.
By forcing different software and processing systems to support multiple message structures and data formats, the current system inhibits the effective use of these data by:
requiring several format-specific readers and writers to be developed in the appropriate software language (C, C++, Java, Python) as required by each application system;
providing inconsistent message structures between the data used or produced by different processing systems;
requiring meticulous and thus error-prone human interpretation of the data components based on the limited documentation provided for each;
creating lack of interoperability with regard to using data designed for or produced by a different particular processing system; and
discouraging development of new and innovative software and processing solutions.
The Engineering Report addresses the feasibility of using the OGC SWE Common Data v2.0 standard to support all message and data streams within future generations of the GPS operational network. In particular, the effort focuses on message streams that provide input to and output from the processing systems responsible for providing improved position and time accuracy within the GPS network.
Here are the benefits of the SWE Common Data standard:
The data can be fully described in a machine- and human- readable XML document providing: data type, units, constraints, semantics, quality, labels, and so on; and an unambiguous definition of both the data structure and encoding of messages/records.
The data values themselves can be encoded in highly efficient binary or ASCII text blocks or streams.
A single software application is able to read any data described in SWE Common data.
Any process can be described in SensorML using SWE Common as inputs, outputs, and parameters.
Any SensorML-defined process can participate in easily-defined executable workflows.
The Engineering Report describes the formats and how they were encoded, and the Web services created to move data between various GPS processing systems (FIGURE 2).
FIGURE 2. Collection of SWE services providing on-demand access to all GPS-related data in the project.
Conclusions
A common standards framework for all data files and streams within the GPS system would significantly improve interoperability between data centers, processing centers, and user tools.
In addition to a common encoding, common models for equivalent message or data records would also be important for interoperability among data, processing centers, and the tools. Common models and a common data framework enable rapid reconfiguration of workflows using different GPS processing products. Likewise, the availability of a common Web service interface enables one to rapidly and flexibly request specific data products and feed them into an executable workflow.
Here are further benefits:
SWE Common Data framework is fully self-described and machine readable.
Common models for all data would support “mix-and-match” capabilities within the processing workflows.
SWE Web services enable on-demand access to various GPS data products using a common framework.
SWE Common Data enables use of SensorML for readily defining and executing various workflows on demand.
Future Directions
Further research and development should move closer to a highly interoperable GNSS system that meets the needs of a broader community of users and enables the development of new supporting software by outside communities. Thus the following are recommended:
Design and reach consensus on consistent data models for all message types in navigation, observation, and state data streams.
Incorporate SWE Common Data readers/writers in the GPSTk toolkit.
Create SensorML descriptions for GPSTk apps.
Demonstrate on-demand design and execution of SensorML-defined workflows for GPS correction.
Demonstrate on-demand geolocation of UAV, ground-vehicle, and hand- held sensors using SWE services and encodings.
Some of these needs will be addressed in the OWS-10 Testbed that is currently ramping up in the OGC.
MIKE BOTTS is president and CTO of Botts Innovative Research, Inc, specializing in the design and application of open standards for sensor systems. He is the creator and chief architect of Sensor Model Language (SensorML), an OGC technical standard for describing the measurement and processing of observations from virtually any sensor system.
In an unprecedented total disruption of a fully operational GNSS constellation, all satellites in the Russian GLONASS broadcast corrupt information for 11 hours, from just past midnight until noon Russian time (UTC+4), on April 2 (or 5 p.m. on April 1 to 4 a.m. April 2, U.S. Eastern time). This rendered the system completely unusable to all worldwide GLONASS receivers. Full and correct service has now been restored.
“Bad ephemerides were uploaded to satellites. Those bad ephemerides became active at 1:00 am Moscow time,” reported one knowledgeable source. For every GNSS in orbit, the navigation messages includeephemeris data, used to calculate the position of each satellite in orbit, and information about the time and status of the entire satellite constellation (almanac); this data is processed by user receivers on the ground to compute their precise position.
According to another source, a GLONASS fix could not take effect until each satellite in turn passed back over control stations in the Northern Hemisphere to be reset, thus taking nearly 12 hours.
During the outage, CEO Neil Vancans of Altus Positioning Systems reported “We are currently experiencing calls from customers all over the world who are experiencing GLONASS ‘outages’ and we have advised customers to switch GLONASS tracking off on our receivers. We don’t have any better information on when normal service is likely to resume from GLONASS satellites. If you do, let me know!”
Such a — possibly human, possibly computer-generated — error could conceivably occur with GPS, Galileo, or BeiDou. “Another reason to have backups,” mused Richard Langley of the University of New Brunswick. “And not just other GNSS.”
A recent plot shows all satellites restored to normal service:
Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.
GPS III prime contractor Lockheed Martin has heard from six companies concerning alternate designs for the GPS III satellite payload, according to reports. A company spokesperson said “constantly canvassing the industrial base to see what’s out there” is merely part of Lockheed’s standard business practice.
Lockheed Martin partner Exelis Geospatial Systems currently supplies the payload, as it has for all previous GPS generations. Earlier this year, Gen. William Shelton, Air Force Space Command, said the first GPS III launch date had slipped from late 2015 into 2016, and confessed to “patience wearing thin” at a press breakfast.
Part of the delay may have been due to signal crosstalk in the new, as yet unlaunched, payload. Crosstalk occurs when a signal broadcast on one circuit creates an undesired effect on another circuit.
The Story So Far. In December 2013, Lockheed Martin turned on power to the bus and network communications payload of the second GPS III satellite, SV-02, at its test facility in Denver. This demonstrated the satellite’s mechanical integration, validated its interfaces, and opened the way for electrical and integrated hardware-software testing. The first GPS III satellite (SV-01) was powered on in February 2013.
In October, the Lockheed Martin GPS III Nonflight Satellite Testbed (GNST), a full-sized, functional satellite prototype at Cape Canaveral Air Force Station, successfully communicated via cross-links to Air Force simulators of the current GPS constellation in orbit. Testing also demonstrated the ability of an Air Force receiver to track navigation signals transmitted by the GNST.
Exelis Advances. In mid-March, Exelis announced successful completion and full testing of six transmitter assemblies, which are integral payload components for the GPS III satellites. The test program includes random vibration, pyroshock, and thermal vacuum testing, replicating space-like conditions through deployment and on-orbit environments. In January, Exelis received three rubidium atomic frequency standard clocks from Excelitas Technologies specifically designed for GPS III.
Signs Point Toward Early Services in December, If ESA Delivers
Europe’s Galileo satnav system.
A February conference on the European Union’s space policy in Brussels sought to set a course for 2020 and close official ranks behind the prospect of early Galileo services at the end of this year. Much in the business community’s perception of the new system — critical for device availability and mass- and professional-market adoption of Galileo — will depend on meeting the projected unveiling of early services in December. This is turn depends on an operational 10-satellite constellation; the fleet now stands at four.
Among trends noted at the meeting: the growing importance of the European GNSS Agency (GSA) as Galileo service provider, with perhaps more authority — and budget — than it has had in the past to get the job done. “The GSA will gradually assume responsibility for the operational management of the programmes while ESA will remain responsible for the deployment of Galileo, and the design and development of new generation of systems,” announced the European Commision (EC).
EC Vice President Antonio Tajani reiterated there will be three Galileo launches in 2014 to reach the requisite year-end total. “The first will come in June. Two satellites have passed the necessary tests. We need to keep this up, and continue to raise our game.”
Trouble on the Equator. The next two Galileo satellites may be ready to ship to Europe’s spaceport in South America by early April. But a large European commercial satellite customer is crowding the schedule, pressuring launch operator Arianespace to lift its satellites first. This could delay the Galileo birds, now set for June rise.
ESA’s year-end plan calls for two more dual-satellite launches in October and December on Russian Soyuz rockets — new partners to the Galileo dance, bringing perhaps new technical connectivity issues.
It’s Not Easy. With Galileo and EGNOS financed to the tune of €7 billion for 2014–2020, expectations are high, yet the European Commission brings a decidely conservative approach to expenditure on new ventures.
“To take a chance, to do what no one has ever done — it’s not easy in a culture that doesn’t like risk,” said ESA director Jean-Jacques Dordain.
Other conference speakers pointed to the securely established European Geostationary Navigation Overlay Service (EGNOS), the first generation of Europe’s GNSS, now fully operational.
Carlo des Dorides, executive director of the GSA, responsible for operating EGNOS through the EGNOS Service Provider (ESSP), elaborated on his big job in 2014: maintaining and improving EGNOS performance and maximizing user adoption, particularly in the aviation, maritime transport, and rail transport sectors.
“The experience we gain through our work with EGNOS will be instrumental as we move towards Galileo service delivery.”
As well as organizational experience with EGNOS, user adoption of the GNSS precursor augurs much for Galileo. With one eye on the present and another on the future, the GSA has a big serving coming to its plate by December: management of a long-awaited, heavily invested system that has been in discussion since the 1990s and in various stages of gestation since 2000.
PNT Advisory Board Hears Air Force CNAV Plan
The U.S. National Space-Based Positioning, Navigation, and Timing (PNT) Advisory Board published the minutes of its December 2013, detailing a report from Air Force Space Command on the road ahead for implementation of the GPS Civil Navigation (CNAV) message on L2C and L5. The subject has stirred some controversy of late, particularly between the U.S. Departments of Transportation (DoT) and Defense (DoD), and DoT is currently seeking public comments on the plan.
The minutes relay the gist of General Whelan’s CNAV remarks as follows: “CNAV has been under discussion for a considerable time. Currently, L2C and L5 signals are being transmitted, but without a navigation message. AFSPC is working hard to activate these messages as soon as possible. One of the reasons for the delay is that additional time was needed to complete testing prior to activation. Testing began in late summer 2013 and, based on initial test results, a ‘way ahead’ has been plotted. . . . Current plans are to begin initial broadcasting in the spring of 2014. CNAV uploads will occur twice weekly. The signal will meet GPS Standard Positioning System (SPS) standards, but may not achieve current accuracy levels until full implementation in late 2014.
“CNAV live-sky testing occurred in June [2013] and was conducted in cooperation with civil, industry, and international partners. The two-week test series included independent assessment and verification. The tests identified four errors that required action. The first, which was addressed in real time, related to implementation of the test series. The second required improvement to the tools suite, which should be totally integrated into the ground segment by December 2014. The third and fourth errors required patches to satellite software. All four issues are now regarded as closed.”
DOT Speaks. A subsequent presentation from the Department of Transportation did not directly mention CNAV, according to the meeting minutes, but did include this update on civil signal monitoring, taken from the meeting minutes:
“DOT is responsible for performance monitoring of GPS civil signals. The International Committee on GNSS’s (ICG’s) transparency principle states that ‘Every GNSS provider should publish documentation that describes the signal and system information, the policies of provision, and the minimum levels of performance offered for its open service.’
Currently, this is only done on GPS L1 C/A signals. Performance standards for L2C and L5 have not yet been established. The crucial function of signal/service monitoring is to verify that commitments to GNSS performance are being met. Additionally, monitoring improves the situational awareness for GNSS operators, and provides assurance that any civil service failure is detected and resolved promptly.”
Opposing Activation. At the close of 2013, a departing DOT assistant secretary wrote a letter to the Air Force opposing activation of the CNAV signal in April 2014. In March, DOT opened a 30-day comment period on the proposed CNAV message on L2C and L5. The comment period closed on April 4, after press time for this magazine so no results are yet known.
Bright New IIF Aloft
A United Launch Alliance Delta IV lifts off from Space Launch Complex-37 with the Air Force’s Global Positioning System (GPS) IIF-5 satellite. This launch marked the 25th Delta IV flight since the first flight in 2002.
The latest GPS IIF satellite was successfully launched into orbit on February 21. GPS IIF-5 will replace the vintage 1997 spacecraft known as GPS IIA-28 in Plane A, Slot 3 of the constellation. IIA-28 will go into a reserve role in the network for the remainder of its useful life.
This is the first of three GPS launches planned through July to replace aging craft in the constellation. The IIF generation will form the backbone of the GPS space fleet for the next 15 years, providing greater navigational accuracy through improvements in atomic clock technology, a new, more robust, third civil signal, L5, for commercial aviation and safety-of-life applications, a second civil signal, L2C, for the dual-frequency GPS receivers, and improved anti-jam capabilities for military and civil users around the world.
The GPS Block IIF satellites are built by Boeing. Earlier IIF satellites were launched in 2010, 2011, 2012, and 2013. All 12 satellites in the GPS IIF series have completed production. The Air Force plans to launch the remaining IIF satellites by 2016.
Downstream Dialog, Tests in Europe
With Galileo services set to take effect in December, the two European entities charged with the program are engaging manufacturers — the European Space Agency (ESA) in consumer markets, and the European GNSS Agency (GSA) in the government security sector, respectively.
“We put out an open call to satnav manufacturers offering testing with our laboratory facilities,” said the head of ESA’s Radio Frequency Systems, Payload, and Technology Division. “We have gone on to work with five mass-market chipset makers and a comparable number of professional receiver manufacturers.”
Available ESA facilities include:
a hybrid localization solution rack for receiver plug-in; it generates simulated constellations of multiple satnav systems along with Wi-Fi or mobile networks. It can also simulate inputs from inertial devices.
the octobox, a mini anechoic chamber into which phones or mobile devices can be placed, to feed them simulated satnav and cellular network signals.
a telecommunications and navigation testbed vehicle for field tests, carrying its own extremely accurate receivers to assess the performance of the consumer devices under test.
“Thanks to earlier collaboration with ESA and the EU, the millions of multi-constellation satnav chips we sell annually have been equipped for Galileo signals since 2009,” stated Philip Mattos of ST Microelectronics, whose Teseo II receiver chips are used in satnavs and embedded in cars (see detailed technical article on page 36). “It will take only a software update to enable them to start using Galileo. This cooperation allows us to optimize our software based on access to actual signals and background technical information.”
Regulated Service. The GSA invited European industries and member states’ Public Regulated Service (PRS) authorities to share views and ideas on technologies at the user segment level for the adoption of the PRS. The PRS uses encrypted signals designed to resist jamming, involuntary interference, and spoofing. GSA’s objective is to ensure that PRS service is affordable and secure for all interested users while also ensuring that European industry maintains its competitive edge in the global satellite navigation marketplace.
GSA consultations will focus on:
steps transforming technologies into products competitive enough in terms of cost, power, dimension;
euro-manufacturing capability and capacity, especially nanotechnology;
how to build the manufacturing lines capable of serving PRS user segment needs;
main domains, elements, and interfaces that will benefit from standardization, allowing for a stronger market adoption of PRS.
GPS III Alternative Payloads Canvassed
GPS III prime contractor Lockheed Martin has heard from six companies concerning alternate designs for the GPS III satellite payload, according to reports. A company spokesperson said “constantly canvassing the industrial base to see what’s out there” is merely part of Lockheed’s standard business practice.
Lockheed Martin partner Exelis Geospatial Systems currently supplies the payload, as it has for all previous GPS generations. Earlier this year, Gen. William Shelton, Air Force Space Command, said the first GPS III launch date had slipped from late 2015 into 2016, and confessed to “patience wearing thin” at a press breakfast.
Part of the delay may have been due to signal crosstalk in the new, as yet unlaunched, payload. Crosstalk occurs when a signal broadcast on one circuit creates an undesired effect on another circuit.
The Story So Far. In December 2013, Lockheed Martin turned on power to the bus and network communications payload of the second GPS III satellite, SV-02, at its test facility in Denver. This demonstrated the satellite’s mechanical integration, validated its interfaces, and opened the way for electrical and integrated hardware-software testing. The first GPS III satellite (SV-01) was powered on in February 2013.
In October, the Lockheed Martin GPS III Nonflight Satellite Testbed (GNST), a full-sized, functional satellite prototype at Cape Canaveral Air Force Station, successfully communicated via cross-links to Air Force simulators of the current GPS constellation in orbit. Testing also demonstrated the ability of an Air Force receiver to track navigation signals transmitted by the GNST.
Exelis Advances. In mid-March, Exelis announced successful completion and full testing of six transmitter assemblies, which are integral payload components for the GPS III satellites. The test program includes random vibration, pyroshock, and thermal vacuum testing, replicating space-like conditions through deployment and on-orbit environments. In January, Exelis received three rubidium atomic frequency standard clocks from Excelitas Technologies specifically designed for GPS III.
Next-Gen SBAS Will Be a Multi-Constellation Affair
Plans to harness Galileo and other satnav systems for next-generation satellite augmentation systems for aviation and other high-performance uses took a step forward at the 126th Satellite-Based Augmentation Systems (SBAS) Interoperability Working Group (IWG) in New Delhi, India, in February, with plans to move to a multi-constellation design adding Galileo, BeiDou, and GLONASS systems in the post-2020 era.
International experts began converging on a standard message definition for the L5 channel of the planned second-generation SBAS systems, which will utilize dual-frequency, multi-constellation signals.
“Two solutions had been put forward, one by ESA based on work by European industry and one from the U.S. Federal Aviation Administration and Stanford University,” explained ESA’s Didier Flament, co-chair of the IWG.
“A single definition coordinated between both bodies has been presented, combining the benefits of both solutions. The formal IWG review and approval loop has now been started with the objective of finalizing it for September’s IWG meeting.
“The aim is to have it ready to submit to the official international SBAS standardization bodies — the International Civil Aviation Organization and the Radio Technical Commission for Aeronautics — as soon as October.”
GAGAN to the Mix. The meeting also marked the significant progress made by India’s own SBAS system GAGAN, which underwent its final stability test in summer 2013, followed by its safety certification in December.
At this point GAGAN was declared certified for non-precision approach users , followed by its safety-of-life service being formally offered to civil aviation users on February 14.
SBAS Services Worldwide
GAGAN is the fourth certified SBAS to enter service worldwide. Europe has the European Geostationary Navigation Overlay Service (EGNOS), which was designed and built by ESA then turned over for operation by the European Satellite Service Provider, ESSP, overseen by the European GNSS Agency (GSA) — both of whom also participated in the meeting. ESA retains responsibility for the future evolution of EGNOS.
The U.S. has the Wide Area Augmentation System (WAAS), developed and operated by the Federal Aviation Administration, with an extension over Canada called CWAAS (Canadian WAAS). WAAS celebrated its 10th anniversary of operational life in July 2013.
Japan has the Multi-functional Satellite Augmentation System (MSAS), developed and operated by Japan’s Civil Aviation Bureau. Japan is discussing plans to merge this capability with its new home-grown satnav system, QZSS.
Along with GAGAN, the meeting covered the progress made by the other SBAS systems under definition or development — the Russian SDCM, Chinese SNAS, and Korean K-SBAS.
The next IWG meeting will take place in September in Tampa, Florida.
ESA’s Galileo Ground Segment Procurement Manager Syvain Loddo speaks during the opening ceremony of the new Galileo Sensor Station on Portugal’s Santa Maria island.
The latest addition to Galileo’s worldwide ground infrastructure has been made in the mid-Atlantic, on Portugal’s Santa Maria island in the Azores. This new Galileo Sensor Station joins a far-flung network of stations monitoring signal quality, clock timings and positioning of the Galileo satellites orbiting Earth.
Its formal opening ceremony on March 26 was presided over by the Azores’ Regional Secretary of Tourism and Transport Vitor Fraga and ESA’s Galileo Ground Segment Procurement Manager Syvain Loddo.
The station’s omnidirectional antenna itself is just half a meter in length, but also requires a power plant and guard house as well as a pair of small VSAT satellite antennas to link the station to the worldwide Galileo Ground Segment.
About 1500 km from mainland Portugal, the small, mountainous island of Santa Maria is already home to an ESA Estrack station, used to follow launches from Europe’s Spaceport in Kourou, French Guiana. The new station is adjacent to this existing site, known locally as the Montes das Flores (Hill of Flowers). It is built on land owned by the Region of Azores, which is Portugal’s public regional authority overseeing the archipelago. The site meets Galileo’s characteristic needs, located away from built-up areas on flat land offering a clear view of the sky in all directions.
ESA’s Santa Maria ground station is located on the ‘Montes das Flores’ (Hill of Flowers) on Santa Maria island in Portugal’s mid-Atlantic Azores. It includes a Galileo Sensor Station.
Both stations have been built by Portugal’s Edisoft company, part of the Thales Group, also responsible for maintaining and running the sites.
Later this year, the Azores station will also host a reference beacon used for assessing Galileo’s Search and Rescue system. As part of the international Cospas–Sarsat system, the medium-orbit Galileo constellation is equipped to pick up UHF signals from emergency beacons aboard ships, aircraft or carried by individuals for relay to the nearest emergency services.
The island has a notable footnote in the history of navigation: reputedly, Christopher Columbus’s flagship Niña landed there in February 1493, having just “discovered” the Americas.
Santa Maria’s climate is mild, although identical Galileo stations have been established everywhere from stormy Arctic islands to the icebound Antarctic mainland.
Multiple Galileo Sensor Station sites will work together to perform ranging measurements while holding a Galileo satellite in common view, seeking to identify any orbital drift that might reduce satnav accuracy. This is effectively a reversal of the way satellite navigation normally operates, with multiple satellites’ signals used to pinpoint the user’s receiver location.
Galileo’s ground segment also includes a number of larger Uplink Stations to transmit navigation messages, including any corrections for rebroadcast to users, as well as Telemetry, Tracking and Command Stations to oversee the satellite platform. A pair of control centres in Fucino, Italy, and Oberpfaffenhofen, Germany, oversees the satellites and their navigation services.
The first four Galileo satellites are already in orbit and operational. Over the course of 2014 more satellites will join them, with initial Galileo services scheduled to start by the end of this year.
The authors test three mass-market design drivers on a chip developed expressly for a new role as a combined GPS and Galileo consumer receiver: the time-to-first-fix for different C/N0, for hot, warm, and cold start, and for different constellation combinations; sensitivity in harsh environments, exploiting a simulated land mobile satellite multipath channel and different user dynamics; and power consumption strategies, particularly duty-cycle tracking.
By Nicola Linty, Paolo Crosta, Philip G. Mattos, and Fabio Pisoni
The two main GNSS receiver market segments, professional high-precision receivers and mass-market/consumer receivers, have very different structure, objectives, features, architecture, and cost. Mass-market receivers are produced in very high volume — hundreds of millions for smartphones and tablets — and sold at a limited price, and in-car GNSS systems represent a market of tens of millions of units per year. The reason for these exploding markets can be found not only in the improvements in electronics and integration, but also in the increasing availability of new GNSS signals. In coming years, with Galileo, QZSS, BeiDou, GPS-L1C, and GLONASS-CDMA all on the way, the silicon manufacturer must continue the path towards the fully flexible multi-constellation mass-market receiver.
Mass-market receivers feature particular signal processing techniques, different from the acquisition and tracking techniques of standard GNSS receivers, in order to comply with mobile and consumer devices’ resources and requirements. However, a limited documentation is present in the open literature concerning consumer devices’ algorithms and techniques; besides a few papers, all the know-how is protected by patents, held by the main manufacturers, and mainly focused on the GPS L1 C/A signal. We investigate and prove the feasibility of such techniques by semi-analytical and Monte Carlo simulations, outlining the estimators sensitivity and accuracy, and by tests on real Galileo IOV signals.
To understand, analyze, and test this class of algorithms, we implemented a fully software GNSS receiver, running on a personal computer. It can process hardware- and software-simulated GPS L1 C/A and Galileo E1BC signals, as well as real signals, down-converted at intermediate frequency (IF), digitalized and stored in memory by a front-end/bit grabber; it can also output standard receiver parameters: code delay, Doppler frequency, carrier-to-noise power density ratio (C/N0), phase, and navigation message. The software receiver is fully configurable, extremely flexible, and represents an important tool to assess performance and accuracy of selected techniques in different circumstances.
Code-Delay Estimation
The code-delay estimation is performed in the software receiver by a parallel correlation unit, giving as output a multi-correlation with a certain chip spacing. This approach presents some advantages, mostly the fact that the number of correlation values that can be provided is thousands of times greater, compared to a standard receiver channel. Use of multiple correlators increases multipath-rejection capabilities, essential features in mass-market receivers, especially for positioning in urban scenarios. The multi-correlation output is exploited to compute the received signal code delay with an open-loop strategy and then to compute the pseudorange.
In the simulations performed, the multi-correlation has a resolution of 1/10 of a chip, which is equivalent to 30 meters for the signals in question; to increase the estimate accuracy, Whittaker-Shannon interpolation is performed on the equally spaced points of the correlation function belonging to the correlation peak.
The code-delay estimate accuracy is reported in Figures 1 and 2. The results are obtained with Monte Carlo simulations on simulated GNSS signals, with sampling frequency equal to 16.3676 MHz. In particular, a GPS L1 C/A signal is considered, affected by constant Doppler frequency equal to zero for the observation period, to avoid the effect of dynamics. The figures show the standard deviation of the code estimation error, that is, the difference between the estimated code delay and the true one, expressed in meters (pseudorange error standard deviation) for different values of C/N0. To evaluate the quality of the results, the theoretical delay locked loop (DLL) tracking jitter is plotted for comparison, as
where Bn is the code loop noise bandwidth, Rc is the chipping rate, Bfe is the single sided front-end bandwidth, Tc is the coherent integration time, and c is the speed of light.
In the two figures, the red curve shows the theoretical tracking jitter for a DLL, which can be considered as term of comparison for code-delay estimation. To correlate the results, a E-L spacing equal to D = 0.2 chip is chosen, and the code-delay error values of the software receiver simulation are filtered with a moving average filter. By averaging 0.5 seconds of data (for example, L = 31 values spaced 16 milliseconds), an equivalent closed-loop bandwidth of about 1 Hz can be obtained:
In particular, in Figure 1, a coherent integration time equal to 1 millisecond (ms) and 16 non-coherent sums are considered, while in Figure 2 a coherent integration time equal to 4 ms and 16 non-coherent sums, spanning a total time T=64 ms, are considered. In both cases, the software receiver results are extremely good for high C/N0. The code-delay error estimate is slightly higher than its equivalent in the DLL formulation. The open-loop estimation error notably increases in the first case below 40 dB-Hz due to strong outliers, whose probability of occurrence depends on the C/N0. In fact, this effect is smoothed in the second case, where the coherent integration time is four times larger, thus improving the signal-to-noise ratio.
Nevertheless, the comparison between open loop multi-correlation approach and closed loop DLL is difficult and approximate, because the parameters involved are different and the results are only qualitative.
Doppler Frequency Estimation
In the particular case of the software receiver developed here, the residual Doppler frequency affecting the GNSS signal is estimated by means of a maximum likelihood estimator (MLE) on a snapshot of samples, exploiting open-loop strategy. In fact, despite the higher standard deviation of the frequency error (jitter), open-loop processing offers improved tracking sensitivity, higher tracking robustness against fading and interference, and better stability when increasing the coherent integration time. In addition, the open-loop approach does not require the design of loop filters, avoiding problems with loop stability. A certain number of successive correlator values, computed in the multiple correlations block, are combined in a fast Fourier transform (FFT) and interpolated.
Figure 3 shows the root mean square error (RMSE) of the frequency estimate versus signal
C/N0, obtained collecting 16 coherent accumulations of 4 ms of a Galileo E1B signal, then computing a 16 points FFT spanning a time interval of 64 ms, and finally refining the result with an interpolation technique. Three different curves are shown, corresponding respectively to:
the RMSE derived from simulations, carried out with GNSS data simulated with the N-FUELS signal generator;
a semi-analytical estimation, exploiting the same algorithm;
the Cramer-Rao lower bound (CRLB) for frequency estimation, shown as
where fs is the sampling frequency.
Figure 3. Doppler frequency estimate RMSE versus C/N0 in super-high resolution with T=64 ms, comparison between theoretical and simulated results.
A well-known drawback is the so-called threshold effect. Below a certain C/N0, the frequency estimate computed with MLE suffers from an error, and the RMSE increases with respect to the CRLB.
Mass-Market Design Drivers
Once we have analyzed the features of some mass-market algorithms with a software receiver, we can move toward the performance of a real mass-market device, to compare results and confirm improvements brought by the new Galileo signals, so far mainly known from a theoretical point of view.
A recent survey identified three main drivers in the design of a mass-market receiver, coming directly from user needs, and solvable in different ways.
Time-to-first-fix (TTFF) corresponds to how fast a position, velocity, and time (PVT) solution is available after the receiver is powered on, that is, the time that a receiver takes to acquire and track a minimum of four satellites, and to obtain the necessary information from the demodulated navigation data bits or from other sources.
Capability in hostile environments, for example while crossing an urban canyon or when hiking in a forest, is measured in terms of sensitivity. It can be verified by decreasing the received signal strength and/or adding multipath models.
Power consumption of the device. GNSS chipset is in general very demanding and can produce a not-negligible battery drain.
We analyzed these three drivers with a commercial mass-market receiver and with the software receiver.
Open-Sky TTFF Analysis
TTFF depends on the architecture of the receiver, for example the number of correlators or the acquisition strategy, on the availability of assistance data, such as rough receiver position and time or space vehicles’ (SV) ephemeris data, and on the broadcast navigation message structure. Some receivers, like the one used here for testing, embed an acquisition engine that can be activated on request and assures a low acquisition time; moreover, they implement ephemeris extension. In contrast, other consumer receiver manufacturers exploit a baseband-configurable processing unit, similar to the one implemented in the software receiver, with thousands of parallel correlators generating a multi-correlator output with configurable spacing, depending on the accuracy required. By selecting an appropriate number of correlators, depending on the available assistance data and on the accuracy required, the TTFF consequently varies.
We assessed the performance of the receiver under test for different C/N0, for hot, warm, and cold start, and for different constellation combinations, exploiting hardware-simulated GNSS data. Good results are achieved, especially when introducing Galileo signals.
Figure 4 reports the hot-start TTFF for different C/N0 values in the range 25–53 dB-Hz, computed using the receiver. The receiver, connected to a signal generator, is configured in dual-constellation mode (GPS and Galileo) and carries out 40 TTFF trials, with a random delay between 15 and 45 seconds. In a standard additive white Gaussian noise (AWGN) channel and in hot-start conditions, the results mainly depend on the acquisition strategy and on the receiver availability of correlators and acquisition engines. In an ideal case with open-sky conditions and variable C/N0, the introduction of a second constellation only slightly improves the TTFF performance; this result cannot be generalized since it mainly depends on the acquisition threshold of the receiver, which can change using signals of different constellations. In real-world conditions, the situation can vary.
Figure 4. Hot start TTFF for Galileo+GPS configuration versus C/N0 using the test receiver.
Cold Start. Secondly, we analyze TTFF differences due to the different structure of GPS and Galileo navigation messages. The I/NAV message of the Galileo E1 signal and the data broadcast by GPS L1 C/A signals contain data related to satellite clock, ephemeris, and GNSS time: parameters relevant to the position fix since they describe the position of the satellite in its orbit, its clock error, and the transmission time of the received message.
Table 1 shows some results in the particular case of cold start, with an ideal open-sky AWGN scenario. The TTFF is significantly lower when using Galileo satellites: while the mean TTFF when tracking only GPS satellites is equal to about 31.9 seconds (s), it decreases to 24.7 s when considering only Galileo satellites, and to 22.5 s in the case of dual constellation. Similarly, the minimum and maximum TTFF values are lower when tracking Galileo satellites. The 95 percent probability values confirm the theoretical expectations. Again, in the ideal case with open-sky conditions, the results with two constellations are quite similar to the performance of the signal with faster TTFF. However, in non-ideal conditions, use of multiple constellations represents a big advantage and underlines the importance of developing at least dual-constellation mass-market receivers.
Table 1. Comparison between TTFF (in seconds) in cold start for different constellation combinations.
Furthermore, it is interesting to analyze in more detail the case of a GPS and Galileo joint solution. GPS and Galileo system times are not synchronized, but differ by a small quantity, denoted as the GPS-Galileo Time Offset (GGTO). When computing a PVT solution with mixed signals, three solutions are possible: to estimate it as a fifth unknown, to read it from the navigation message, or to use pre-computed value. In the first case it is not necessary to rely on the information contained in the navigation message, eventually reducing the TTFF. However, five satellites are required to solve the five unknowns, and this is not always the case in urban scenarios or harsh environments, as will be proved below. On the contrary, in the second case, it is necessary to obtain the GGTO information from the navigation message, and since it appears only once every 30 seconds, in the worst case it is necessary to correctly demodulate 30 seconds of data. Both approaches show benefits and disadvantages, depending on the environment. The receiver under test exploits the second solution: in this case, it is possible to see an increase in the average TTFF when using a combination of GPS and Galileo, due to the demodulation of more sub-frames of the broadcast message.
Sensitivity: Performance in Harsh Environments
Harsh environment is the general term used to describe those scenarios in which open sky and ideal propagation conditions are not fulfilled. It can include urban canyons, where the presence of high buildings limits the SV visibility and introduces multipath; denied environments, where unintentional interference may create errors in the processing; or sites where shadowing of line-of-sight (LoS) path is present, for example due to trees, buildings, and tunnels. In these situations it is necessary to pay particular attention to the signal-processing stage; performance is in general reduced up to the case in which the receiver is not able to compute a fix.
A first attempt to model such an environment has been introduced in the 3GPP standard together with the definition of A-GNSS minimum performance requirements for user equipment supporting other A-GNSSs than GPS L1 C/A, or multiple A-GNSSs which may or may not include GPS L1 C/A. The standard test cases support up to three different constellations; in dual-constellation case it foresees three satellites in view for each constellation with a horizontal dilution of precision (HDOP) ranging from 1.4 to 2.1.
To perform TTFF and sensitivity tests applying the 3GPP standard test case, we configured a GNSS simulator scenario with the following characteristics, starting from the nominal constellation:
Six SVs: three GPS (with PRN 6,7, 21) and three Galileo (with code number 4, 11, 23);
HDOP in the range 1.4 – 2.1;
nominal power as per corresponding SIS-ICD;
user motion, with a heading direction towards 90° azimuth, at a constant speed of 5 kilometers/hour (km/h).
In addition to limiting the number of satellites, we introduced a narrowband multipath model. The multi-SV two-states land mobile satellite (LMS) model simulator generated fading time series representative of an urban environment. The model includes two states:
a good state, corresponding to LOS condition or light shadowing;
a bad state, corresponding to heavy shadowing/blockage.
Within each state, a Loo-distributed fading signal is assumed. It includes a slow fading component (lognormal fading) corresponding to varying shadowing conditions of the direct signal, and a fast fading component due to multipath effects. In particular, the last version of the two-state LMS simulator is able to generate different but correlated fading for each single SV, according to its elevation and azimuth angle with respect to the user position: the angular separation within satellites is crucial, since it affects the correlation of the received signals. This approach is based on a master–slave concept, where the state transitions of several slave satellites are modeled according to their correlation with one master satellite, while neglecting the correlation between the slave satellites. The nuisances generated are then imported in the simulator scenario, to timely control phase and amplitude of each simulator channel. Using this LMS scenario, the receiver’s performance in harsh environments has been then verified with acquisition (TTFF) and tracking tests.
The TTFF was estimated with about 50 tests, in hot, warm, and cold start, first using both GPS and Galileo satellites, and then using only one constellation. In the second case only the 2D fix is considered, since, according to the scenario described, at maximum three satellites are in view. Table 2 reports the results for the dual-constellation case: in hot start the average TTFF is about 8 s, and it increases to 36 s and 105 s respectively for the warm and cold cases. Clearly the results are much worse than in the case reported earlier of full open-sky AWGN conditions. In this scenario only six satellites are available at maximum; moreover, the presence of multipath and fading affects the results, and they exhibit a larger variance, because of the varying conditions of the scenario.
Table 2. TTFF (in seconds) exploiting GPS and Galileo constellations in harsh environments.
Table 3 shows similar results, but for the GPS-only case. In this case the receiver was configured to track only GPS satellites. The mean TTFF increases both in the hot and in the warm case, whereas in cold start it is not possible compute a 2D fix with only three satellites; the ambiguity of the solution cannot be solved if an approximate position solution is not available. It may seem unfair to compare a scenario with three satellites and one with six satellites. However, it can be assumed that this is representative of what happens in limited-visibility conditions, where a second constellation theoretically doubles the number of satellites in view.
Table 3. TTFF (in seconds) exploiting only GPS constellations in harsh environments.
The results confirm the benefits of dual-constellation mass-market receivers in harsh environments where the number of satellites in view can be very low. Making use of the full constellation of Galileo satellites will allow mass-market receivers to substantially increase performances in these scenarios.
Tracking.We carried out a 30-minute tracking test with both the receiver and the software receiver model. Both were able to acquire the six satellites and to track them, even with some losses of lock (LoLs) due to fading and multipath reflections. Figure 5 shows the number of satellites in tracking state in the receiver at every second, while Figure 6 shows the HDOP as computed by the receiver. When all six satellites are in tracking state, the HDOP lies in the range 1.4 – 2.1, as defined in the simulation scenario; on the contrary, as expected, in correspondence with a LoL it increases.
Figure 6. HDOP computed by the test receiver in the Multi-SV LMS simulation.
Figure 7 compares the signal power generated by the simulator and the power estimated by the receiver, in the case of GPS PRN 7 and Galileo code number 23. This proves the tracking capability of the receiver also for high sensitivity. To deal with low-power signals, the integration time is extended both for GPS and for Galileo, using the pilot tracking mode in the latter case.
Figure 7. C/N0 estimate computed by the receiver in harsh environments and compared with the signal power.
Figures 8 and 9 show respectively the position and the velocity solution. In the first case latitude, longitude, and altitude are plotted, while in the second case the receiver speed estimate in km/h is reported.
Figure 8. Test receiver position solution in LMS scenario.Figure 9. Test receiver velocity solution in LMS scenario.
In this framework it is possible to evaluate the advantages and disadvantages of using the broadcast GGTO when computing a mixed GPS and Galileo position. When the LMS channel conditions are good, all six SVs in view are in tracking state, as shown in Figure 5. However, when the fading becomes important, the number is reduced to only two satellites. If the receiver is designed to extract the GGTO from the navigation message, then a PVT solution is possible also when only four satellites are in tracking state, that is for 90 percent of the time in this specific case. On the contrary, if the GGTO has to be estimated, one more satellite is required, and this condition is satisfied only 57 percent of the time, strongly reducing the probability of having a fix. Nevertheless, estimating the GGTO requires the correct demodulation of the navigation message, and this is possible only if the signal is good enough for a sufficient time.
Figure 5. Number of satellites tracked by the test receiver in the Multi-SV LMS simulation.
Power-Saving Architectures
The final driver for mass-market receivers design is represented by power consumption. Particularly for chips suited for portable devices running on batteries, power drain represents one of the most important design criteria. To reduce at maximum the power consumption, chip manufacturers have adopted various solutions. Most are based on the concept that, contrarily to a classic GNSS receiver, a mass-market receiver is not required to constantly compute a PVT solution. In fact, most of the time, GNSS chipsets for consumer devices are only required to keep updated information on approximate time and position and to download clock corrections and ephemeris data with a proper time rate, depending on the navigation message type and the adopted extended ephemeris algorithm. Then, when asked, the receiver can quickly provide a position fix. By reducing the computational load of the device during waiting mode, power consumption is reduced proportionally.
To better understand advantages and disadvantages of power saving techniques, some of them have been studied and analyzed in detail. In particular, the algorithm implemented in the software receiver model is based on two different receiver states: an active state, in which all receiver parts are activated, as in a standard receiver, and a sleep state, where the receiver is not operating at all. In the sleep state, the GNSS RF module, GNSS baseband, and digital signal processor core are all switched off. By similarity to a square wave, these types of tracking algorithms are also called duty-cycle (DC) algorithms. Exploiting the software approach’s flexibility, we can test the effect of two important design parameters:
sleep period length;
minimum active period length.
Their setting is not trivial and depends on the channel conditions, on the signal strength, on the number of satellites in view, on the user dynamics, and finally on the required accuracy.
In the software receiver simulations performed, the active mode length is fixed to 64 ms: the receiver collects 16 correlation values with coherent integration time equal to 4 ms, to perform frequency estimation as described above. Then it switches to sleep state for 936 ms, until a real-time clock (RTC) wake-up initiates the next full-power state. In this way a fix is available at the rate of 1 s, as summarized in Figure 10. However, there are some situations where the receiver may stay in full-power mode, for example during the initialization phase, to collect important data from the navigation message, such as the ephemeris, and to perform RTC calibration.
Figure 10. Duty cycle tracking pattern in the software receiver simulations.
There are benefits of using this approach coupled to Galileo signals: the main impact is the usage of the pilot codes. Indeed, a longer integration time allows reducing the active period length, which most impacts the total power consumption, being usually performed at higher repetition rate.
Some simulations were carried out to assess the performance of DC algorithms in the software receiver. While in hardware implementations the direct benefit is the power computation, in a software implementation it is not possible to see such an improvement. The reduced power demand is translated into a shorter processing time for each single-processing channel. The DC approach can facilitate the implementation of a real-time or quasi-real-time software receiver.
The main drawback of using techniques based on DC tracking is the decrease of the rate of observables and PVT solution. However, this depends on the application; for some, a solution every second is more than enough.
Real-Signal Results
On March 12, 2013, for the first time the four Galileo IOV satellites were broadcasting a valid navigation message at the same time. From 9:02 CET, all the satellites were visible at ESTEC premises, and the first position fix of latitude, longitude, and altitude took place at the TEC Navigation Laboratory at ESTEC (ESA) in Noordwijk, the Netherlands. At the same time, we were able to acquire, track, and compute one of the first Galileo-only mobile navigation solutions, using the receiver under test. Thanks to its small size and portability, it was installed on a mobile test platform, embedded in ESA’s Telecommunications and Navigation Testbed vehicle. Using a network connection, we could follow, from the Navigation Lab, the real-time position of the van moving around ESTEC.
Figure 11 shows the van’s track, obtained by post processing NMEA data stored by the receiver evaluation board. The accuracy achieved in these tests met all the theoretical expectations, taking into account the limited infrastructure deployed so far. In addition, the results obtained with the receiver have to be considered preliminary, since its firmware supporting Galileo was in an initial test phase (for example, absence of a proper ionospheric model, E1B-only tracking).
Figure 11. Galileo-only mobile fix, computed on March 12, 2013.
Conclusions
Analysis of a receiver’s test results confirms the theoretical benefits of Galileo OS signals concerning TTFF and sensitivity. Future work will include the evolution of the software receiver model and a detailed analysis of power-saving tracking capabilities, with a comparison of duty-cycle tracking techniques in open loop and in closed loop.
Acknowledgments
This article reflects solely the authors’ views and by no means represents official European Space Agency or Galileo views. The article is based on a paper first presented at ION GNSS+ 2013. Research and test campaigns related to this work took place in the framework of the ESA Education PRESTIGE programme, thanks to the facilities provided by the ESA TEC-ETN section. The LMS multipath channel model was developed in the frame of the MiLADY project, funded by the ARTES5.1 Programme of the ESA Telecommunications and Integrated Applications Directorate.
Manufacturers
The tests described here used the STMicroelectronics Teseo II receiver chipset and a Spirent signal simulator.
Nicola Linty is a Ph.D. student in electronics and telecommunications at Politecnico di Torino. In 2013 he held an internship at the European Space Research and Technology Centre of ESA.
Paolo Crosta is a radio navigation system engineer at the ESA TEC Directorate where he provides support to the EGNOS and Galileo programs. He received a MSc degree in telecommunications engineering from the University of Pisa.
Philip G. Mattos received an external Ph.D. on his GPS work from Bristol University. He leads the STMicroelectronics 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.
The R&S SMBV100A vector signal generator can generate Galileo, GPS, and GLONASS signals for up to 24 satellites in real time. With the SMBV-K107 option, the simulator covers the BeiDou standard as well.
The R&S SMBV-K101 option allows developers in the automotive and wireless communications industries to test GNSS receivers for specific effects such as obscuration and multipath propagation. If the GNSS receiver of a navigation instrument or smartphone is located inside a vehicle, testing must also take into account the obscuring effect of the vehicle’s metal body. The R&S SMBV-K102 option can simulate this obscuration and, if required, the additional antenna pattern.
In addition to test scenarios for A-GPS, smartphone developers have the Assisted Galileo (R&S SMBV-K67) and Assisted GLONASS (R&S SMBV-K95) options at their disposal.
