The New Year’s festivities had ended and satellite operators at the 2d Space Operations Squadron (2 SOPS) at Schriever Air Force Base, Colorado, were hard at work conducting routine operations on the GPS satellites. At around 11:30 in the morning local time (1830 UTC) on January 1, 2004, range errors for space vehicle number (SVN) 23 began to rapidly drift above the 30-meter threshold.
The New Year’s festivities had ended and satellite operators at the 2d Space Operations Squadron (2 SOPS) at Schriever Air Force Base, Colorado, were hard at work conducting routine operations on the GPS satellites. At around 11:30 in the morning local time (1830 UTC) on January 1, 2004, range errors for space vehicle number (SVN) 23 began to rapidly drift above the 30-meter threshold.
Not until almost three hours later was the satellite set “unhealthy,” thereby protecting users from the wayward signal. In the meantime, the C/A-code signal had reached 280,000 meters of ranging error.
This one event would have been bad enough, but it actually marked the second time a signal had reached such a large error. Just two and half years earlier, in July 2001, SVN 22 had broadcast a signal with 200 kilometers of range error.
Taking Steps to Improve Service
Six years have passed since the 2004 event, and a similar incident has not recurred. What has happened since then, and how can we ensure that such events do not happen in the future?
Many lessons were learned from the SVN22 (PRN22) and SVN23 (PRN23) incidents, and as a result of these lessons GPS users are being better served. For example, operators now immediately remove aberrant satellites from service and then investigate the cause. In addition, in September 2005, the GPS Master Control Station (MCS) began to include data from monitoring stations in the network managed by the National Geospatial-Intelligence Agency (NGA).
With these added stations, satellites can no longer move outside of the coverage area of ground reference stations monitoring GPS satellites, where signal anomalies could go undetected. Due to the increase in the number of monitoring stations, multiple stations continuously monitor each satellite’s signal, ensuring that the sources of anomalies are rapidly and unambiguously determined by satellite operators.
These improvements in control segment operations pointed to a larger issue, however — that of defining what exactly is meant by signal and service monitoring. As a result, in 2003 Tom Nagle, the acquisition liaison for GPS civil applications at the GPS Joint Program Office, took steps to clarify the issue of what is meant by monitoring the civil GPS signal and service.
Nagle commissioned the development of a GPS civil monitoring performance specification, which would clearly and unambiguously describe what the civil community sought and could expect from a monitoring service. The GPS Civil Monitoring Performance Specification, or CMPS, was first published in 2005. It identifies the key elements needed in monitoring services to ensure GPS meets its commitments to the civilian user community.
This article describes the goals, process, and results involved in developing the CMPS, along with steps the U.S. Government could take in implementing the requirements identified in the CMPS.
Motives and Objectives for Monitoring
Several important reasons exist for monitoring the civil service and signals, which support multiple categories of beneficiaries.
- The GPS user community wants assurance that service and signal failures are detected and resolved promptly. For the most part, users do not want details; they just want a working GPS.
- The system designers and developers want baseline information on system performance. This information verifies that operational and contractual objectives and thresholds are being met. It also serves as a means of identifying potential areas of future improvement.
- Policy-makers desire validation that service is meeting expectations. This has been important in the past, but will likely become more important in a multi-GNSS future in which various GNSSs make competing claims regarding the accuracy and reliability of their services.
While general agreement exists that monitoring is beneficial and desired, the exact definition of what it means to monitor a service or a signal is not well defined in government policy documents and specifications. If the definition is open to interpretation by various organizations, miscommunication and disagreements will occur.
Today’s Monitoring Capability
Today’s GPS constellation is controlled through the U.S. Air Force (AF) Operational Control System (OCS). The OCS consists of the MCS, two sets of monitoring stations, and two sets of ground antennas, the four dedicated GPS ground antennas, and those employed in the Air Force Satellite Control Network.
Figure 1 illustrates the flow of information among the components of the Space Segment and OCS. The two networks of monitoring stations shown in the figure are the six-station OCS network and the 11-station network operated by the NGA. This figure illustrates the control loop from the MCS to the space vehicle (SV) to the monitor station and back to the MCS. The figure also illustrates some of the monitoring tools currently available to the 2 SOPS operators.
The current OCS focuses on collecting and analyzing the L1/L2 P(Y)-code signals — centered at 1575.42 and 1227.6 MHz, respectively — broadcast by the GPS SVs. The L-Band monitor located at the MCS performs this function. The AF stations only track the C/A-code during SV acquisition.
The NGA stations track the C/A-code as well as the P(Y)-code signals, but the current MCS only processes the P(Y)-code data with respect to signal quality monitoring and orbit prediction.
The operators have at least two means of access to C/A-code information in near–real-time. The NGA C/A-code information is available through an additional system known as the Tactical Analysis Toolsuite for 2 SOPS (TAT2). In addition, the operators have access to signal information collected by the NASA Global Differential GPS (GDGPS) system developed by the Jet Propulsion Laboratory (JPL).
The limitation of not providing continuous monitoring of the L1 C/A-code signal has in the past, for most cases, been acceptable. Anomalies occurred very rarely that would only affect C/A-code users and not be observable by the operators at the MCS. Several reasons account for this:
- A great deal of commonality exists within the SV signal paths. Most failure modes will affect all signals (e.g.. a frequency standard failure).
- Early control segment receivers used C/A-code during acquisition even though the end state was to track P(Y)-code. As a result, a persistent C/A-code problem would be detected.
- The navigation message on C/A-code and P(Y)-code is essentially identical; so, any errors that affect the C/A-code navigation message would also be detectable when monitoring the P(Y)-code navigation message.
The Future Brings Challenges
The situation will become more challenging as new signals come on line. With the advent of a third frequency (L5, centered on 1176.45 MHz) that will become available beginning with Block IIF launches this year, a future L1 civil signal (L1C), and additional codes, the opportunity for varying performance between and among signals will increase.
The U.S. government’s emphasis on separating the military and civil signals provides an additional reason to expect corresponding separation in causes of anomalies. For example, in today’s SVs (Blocks IIA, IIR, and IIR-M) the L1 and L2 signals that carry the P(Y)-code (military), C/A-code (civil), and L2C (civil) have a common frequency standard that drives these signals, and thus the signal path for each is largely common.
Another example: the L1 C/A-code and L1 P(Y)-code are modulated on a common carrier and amplified by a single transmission amplifier. A similar situation holds for L2C and L2 P(Y)-code.
In the next generation of SVs (Blocks IIF and III), however, the L5 signal has no such military signal in common. A failure on the L5 modulator or transmission amplifier may have no affect on the military signals and, in fact, may not been seen by satellite operators if the OCS were tracking only the military signals.
In addition to the focused concern on the signal-in-space (SIS), a more general concern arises, that of achieving complete closure of the control loop between the Control Segment and the Space Segment. As shown in Figure 1, GPS includes a command and control loop wherein the Control Segment uploads data and commands to the SVs.
Current monitoring efforts are tightly focused on monitoring the accuracy and health of the L1/L2 P(Y)-code SIS. To completely close the loop, monitoring must enable the operators to observe that navigation message data passed to the SVs is forwarded to the users as expected.
In summary, despite the occurrence of a few spectacular cases of large ranging errors of long duration, the monitoring system has been arguably adequate for providing the service needed for civil users. However, these anomalies demonstrate the need for a more comprehensive approach with respect to an accepted definition of monitoring, a commitment to monitor all the signals all the time, and a means of appropriately distributing monitoring results to interested parties.
As with all systems engineering efforts, the first question to address is to define what is needed in monitoring. That is role of the CMPS.
The Civil Monitoring Performance Specification
The CMPS provides a comprehensive compilation of requirements to be implemented to effectively monitor the civil service and signals. The requirements in the CMPS are derived from U.S. government policy documents and GPS signal interface specifications.
As implied by the word “civil,” the CMPS focuses on the service (the Standard Positioning Service or SPS) and the signals (L1 C/A, L1C, L2C, L5) defined for civil use. The intent of the CMPS is to document a consistent, unambiguous and useful interpretation of the meaning of monitoring in the form of a set of requirements that can be allocated to a system or systems, implemented, tested, and verified.
With the CMPS, the term “monitor” is interpreted to mean “to verify intended operation.” To that end, various U.S. government policy documents provide assertions regarding the characteristics of the SPS, and the GPS signal interface specifications provide a comprehensive definition of the characteristics of the signals. The CMPS translates these assertions and definitions into a set of monitoring requirements that state how the assertions and definitions can be verified.
The latest version is the GPS Civil Monitoring Performance Specification, DOT-VNTSC-FAA-09-08, April 30, 2009. The document is available from the website of the National Executive Committee for Space-Based Positioning, Navigation and Timing at http://pnt.gov/public/docs (specifically, http://pnt.gov/public/docs/2009/CMPS2009.pdf).
The CMPS does not impose new requirements on GPS in terms of service or signals, rather it provides clarification of GPS III/OCX requirements to “monitor all signals all the time.” Furthermore, the CMPS is not intended to state how civil monitoring will be implemented nor does it consider the capabilities or limitations of any current GPS tracking networks.
The CMPS has been extensively reviewed by U.S. government departments and agencies representing the civil community and represents a civil U.S. government community consensus regarding monitoring of GPS service and signals.
Description of the CMPS
The CMPS is organized into five major sections: scope, applicable documents, requirements, partitioning of requirements, and notes. The scope section describes the intent of the CMPS, how the CMPS was developed, and the structure of the CMPS.
The list of applicable documents is particularly relevant in the case of the CMPS because they are sources of the monitoring requirements defined later in the performance specification. The document list includes
- 2008 Federal Radionavigation Plan
- GPS Standard Positioning Service Performance Standard (SPS PS)
- Wide Area Augmentation System (WAAS) Performance Standard
- IS-GPS-200 “Navstar GPS Space Segment/Navigation User Interfaces”
- ICD-GPS-240 “Navstar GPS Master Control Station to User Support Community Interface”
- IS-GPS-705 “Navstar GPS Space Segment/User Segment L5 Interfaces”
- IS-GPS-800 “Navstar GPS Space Segment/User Segment L1C Interfaces.”
The CMPS contains 193 requirements grouped into eight sections. One section contains service-monitoring requirements derived from the SPS PS. A second section contains requirements on monitoring the signals themselves, based on the various interface specifications.
Another section concerns verification of the ways in which GPS communicates critical data to users that is outside the scope of the SIS. (Examples of such information include the provision of Notice Advisory to Navstar Users (NANU) and on-line almanac information.) One section is a placeholder for possible future integrity requirements (since such a section was included in the SPS PS).
The final four sections of requirements are different in nature than the first four sections, which are derived directly from the higher-level requirements documents. For example, if the SPS PS asserts that position dilution of precision (PDOP, a factor based on the configuration of satellites used in a specific position solution) coverage will be at-or-above some value for some fraction of time that is translated into a specific monitoring requirement.
However, the last four sections relate to the reliability of monitoring, response times when anomalies are detected, and the time periods for which monitoring results should be maintained. None of these is addressed in the higher-level requirements.
Therefore, the requirements addressed in the final four sections of the CMPS are based on a variety of sources including consistency with other GPS requirements, reasonable systems engineering estimates, or a consensus viewpoint reached after discussion within the GPS community.
As a dual-use system, many of the requirements levied on GPS are relevant both to military and civil users. Accordingly, the CMPS enumerates (or “partitions”) monitoring requirements that apply equally to military and civil monitoring needs. Table 4-1 in the CMPS spells out which requirements are “civil-unique” and which apply equally to civil and military needs.
The CMPS goes beyond a simple mechanical derivation of monitoring requirements from service and signal requirements. The utility of some monitoring requirements is inherently obvious. The utility of others may not be as readily apparent. Likewise, the methods for verifying requirements are not always obvious.
The final section of the CMPS contains notes that endeavor to anticipate and address questions on interpreting and verifying monitoring requirements. In particular, the Notes section includes
- a listing of additional references that may be of use in interpreting the requirements and implementing a monitoring system
- a set of use cases illustrating anticipated monitoring applications
- several requirement-specific notes clarifying the reasoning behind a requirement or providing algorithmic details regarding how verification could be implemented, and
- a listing of definitions and acronyms.
The general goal of the Notes is to eliminate ambiguity in the CMPS and reduce opportunities for misinterpretation.
Development of the CMPS
Figure 2 shows the significant milestones in development of the CMPS. The initial draft was developed primarily to document the monitoring requirements for existing commitments made by the U.S. government. Overlook Systems Technologies, Inc., and Applied Research Laboratories, The University of Texas at Austin (ARL:UT) developed this draft in 2003 (June through September).
Over the next two years the draft was improved and refined through a succession of reviews that also served to build awareness of, and support for, the CMPS throughout the civil community. The CMPS was reviewed by
- the GPS Systems Engineering Forum
- the GPS Independent Review Team
- the U.S. Department of Transportation (DoT) Position/Navigation Executive Committee
- the GPS Wing
- 14 AF/50 Space Wing/2d Space Operations Squadron, and
- the DOT Extended Position/Navigation Working Group.
The GPS Wing and DOT approved the final draft for public release. The first version of the CMPS was released on December 1, 2005.
In January 2008, the GPS Wing established the Signal Monitoring Working Group (SMWG) comprised of representatives from the Wing, the 2 SOPS, NGA, NASA, Federal Aviation Administration (FAA) and other DoT agencies, all DoD services, and contractors.
The purpose of the SMWG is to develop a comprehensive and coherent vision for performing GPS signal monitoring, ranging from the current state-of-the-art capabilities through those anticipated to be available at the time when the GPS III space vehicles are on orbit and operational.
The SMWG’s purpose is to go beyond civil monitoring needs to consider military monitoring needs as well. The SMWG began its task by forming a Requirements Team (RT) to determine an appropriate set of monitoring requirements.
The SMWG/RT met from April to October 2008, adopting at its first meeting the existing CMPS as its baseline set of civil monitoring requirements. The SMWG/RT recommended improvements in the CMPS, including some additional requirements, which were subsequently incorporated into the CMPS.
In addition, an L1C signal specification (IS-GPS-800) and a new version of the SPS PS had been released since the first release of the CMPS, and these also needed to be incorporated into the CMPS. With these additions and changes in hand, ARL:UT and Advanced Research Corporation prepared a new draft of the CMPS.
The draft was reviewed by the SMWG/RT, the GPS Wing staff, and the DOT Extended Position/Navigation Working Group, and a second version of the CMPS was released on April 30, 2009.
Implementing the CMPS
In writing the CMPS we were careful not to drive toward any particular method or design for performance monitoring, but rather to state the requirements for monitoring independent of how they were to be implemented.
That said, we have had many discussions as to which requirements could be easily incorporated into the OCX, which would require special equipment and expertise and fall to organizations outside the OCX, and which could be incorporated into normal operations of either the satellite operators or civilian government agencies.
Part of the issue is the conflict between different sets of needs. On the one hand, monitoring must be integrated into daily satellite operations so that 2 SOPS operators are aware of the issues and can respond to them. On the other hand, monitoring should be separated from normal operations to ensure an independent perspective in assessing performance.
We have taken the position that part of the purpose of monitoring is to detect faults so that they may be corrected as quickly as possible. As a result, we have concluded that monitoring must be part of daily satellite operations, because only the operators can either fix an anomaly or remove an aberrant signal from service.
A next step for implementation is to architect the various elements of the monitoring activity. A team from the DOT Research and Innovative Technology Administration (RITA) and GPS Wing is currently leading this initiative with the goal of ensuring that all requirements are adequately met while avoiding duplication of effort.
The architecture depends largely on the OCX effort and the degree to which the OCX development contractor is able to incorporate signal monitoring into its design and hence into normal satellite operations. The architecture will allocate which pieces belong to the OCX and which should be carried out by other organizations.
Signal monitoring not only includes the real-time operations but also the archiving of the data and results, so that in the future, historical data can be examined to support performance, mission, and legal inquiries, including investigations and trending analysis.
The Benefits of Monitoring
As we move into the future with the addition of L2C, L5, and L1C civil signals, monitoring of GPS signals and service will become more complex. It is essential to have in place the tools and processes to ensure that these signals and services are performing as expected. In doing so, users will benefit both directly and indirectly.
The most immediate direct benefit will be the reduced probability of integrity failures. When integrity failures do occur, the range errors will be small and of short duration.
Satellite operators will have full situational awareness into the operation of the constellation and the service being provided so that they can unambiguously identify anomalies for rapid isolation and resolution. Moreover, having access to a database of failures, the operators will be able to identify potential failures earlier and have an opportunity to head them off before they occur.
A further benefit of archiving data is its subsequent use to assess performance quality over time and assist in performing historical analyses, whether these are battle damage assessments for the military or investigating service performance at the time of a transportation incident involving GPS.
Civil monitoring will also provide the U.S. government with an ability to quantitatively confirm that GPS is meeting its performance objectives.
The CMPS establishes a set of monitoring goals for GPS that will greatly benefit satellite operators, developers, and GPS users alike. Our hope is that this approach will be adopted by other GNSS providers as they develop and modernize their system capabilities.
Furthermore, we feel consideration should be given in the future to monitor all GNSS signals. Although this is not currently in the CMPS, such a step would do much to stabilize, strengthen, and unify the service operated by all GNSS providers.
Acknowledgements
The authors wish to thank those who helped us in getting all our facts right in developing the CMPS, including P. J. Mendicki and Karl Kovach at Aerospace Corporation, Pat Reddan at Zeta Associates, and Todd Kawakami of the National Geospatial-Intelligence Agency.
Additional Resources
[1] GPS Civil Monitoring Performance Specification, DOT-VNTSC-FAA-09-08, April 30, 2009
[2] ICD-GPS-240 “Navstar GPS Master Control Station to User Support Community Interface”
[3] IS-GPS-200 “Navstar GPS Space Segment/Navigation User Interfaces”
[4] IS-GPS-705 “Navstar GPS Space Segment/User Segment L5 Interfaces”
[5] IS-GPS-800 “Navstar GPS Space Segment/User Segment L1C Interfaces”
[6] Standard Positioning Service Performance Standard, U.S. Department of Defense, 4th Edition, September 2008
[7] “Summary of Accuracy Improvements from the GPS Legacy Accuracy Improvement Initiative (L-AII),” Creel, T., and A. J. Dorsey, P. J. Mendicki, J. Little, R. G. Mach, and B. A. Renfro, Proceedings of ION GNSS-2007, Fort Worth, Texas, USA, September 25–28, 2007
