GPS World

Blog

  • The System: Test Data Predicts Disastrous GPS Jamming by FCC-Authorized Broadcaster

    Representatives of the GPS industry presented to members of the Federal Communications Commission (FCC) laboratory evidence of interference with the GPS signal by a proposed new broadcaster on January 19 of this year. The meeting and subsequent filing did not dissuade FCC International Bureau Chief Mindel De La Torre from authorizing Lightquared to proceed with ancillary terrestrial component operations, installing up to 40,000 high-power transmitters close to the GPS frequency, across the United States.

    The document describing the testing states that the Lightsquared initiative “will have a severe impact on the GPS band” and “will create a disastrous interference problem for GPS receiver operation to the point where GPS receivers will cease to operate (complete loss of fix) when in the vicinity of these transmitters.”

    On January 26, the FCC waived its own rules and granted permission for the potential interferer to broadcast in the L Band 1 (1525 MHz–1559 MHz) from powerful land-based transmitters. This band lies adjacent to the band (1559–1610 MHz) where GPS and other GNSSs operate.

    The FCC called for further testing to be led by LightSquared and completed by June 15.

    Prior to the decision, representatives of the U.S. GPS Industry Council and GPS manufacturers Garmin and Trimble presented “Experimental Evidence of Wide Area GPS Jamming That Will Result from LightSquared’s Proposal to Convert Portions of L Band 1 to High Power Terrestrial Broadband,” to five members of the FCC’s Office of Engineering and Technology, including its chief, two members of the FCC International Bureau, one from the Public Safety and Homeland Security Bureau, and two from the Wireless Telecommunications Bureau.

    A full PDF of “Experimental Evidence of Wide Area GPS Jamming” is available.

    The document conveys results of testing on a common portable consumer automotive navigation device and on a common general aviation receiver. The consumer GPS device began to be jammed at a power level representing a distance of 3.6 miles (5.8 kilometers) from the simulated LightSquared transmitter. The consumer device lost a fix at 0.66 miles (1.1 kilometers) from the transmitter.

    The Federal Aviation Administration (FAA)-certified aviation receiver began to be jammed at a distance of 13.8 miles (22.1 kilometers) and experienced total loss of fix at 5.6 miles (9.0 kilometers) from the transmitter.

    During the laboratory testing, GPS signals were simulated by a Spirent GSS6560 GPS simulator, representing a constellation of 31 GPS satellites, the current configuration. LightSquared’s signal was simulated using a Rhode and Schwartz SMIQ-03S signal generator with digital modulation, amplified to achieve the relevant signal strengths. Full technical specifications and parameters are described in the Experimental Evidence document linked above.

    The industry report concludes: “The proposed LightSquared plan . . .  will deny GPS service over vast areas of the United States.”
    In its decision document on January 26, the FCC not only authorized LightSquared to proceed, it turned up its nose at assertions that the entire process had been conducted in near-stealth mode as well as on an accelerated track.

    LightSquared was established in mid-2010 by “an experienced team of global telecommunications executives and investors.” From 2001 to 2005, Lightsquared executive vice president Jeff Carlisle served as deputy chief and then chief of the FCC’s Wireline Competition Bureau.

    See also “Act Now to Protect GPS Signal.”

    and

    “The FCC’s Decision on LightSquared: High-Precision Users Would Be Affected Most.”

    Galileo’s GATE Opened

    The Galileo Test and Development Environment (GATE) in Berchtesgaden, Germany, officially opened on February 4. The system operator, IFEN GmbH of Poing, Germany, jointly with the German Federal Minister of Transport, Building and Urban Development, announced the opening for use by commercial and organizational entities seeking to test equipment with the coming Galileo signals. GATE was developed on behalf of the German Aerospace Center (DLR) with funding by the German Federal Ministry of Economics and Technology.

    The test area extends across a valley of approximately 65 square kilometers, southeast of Munich, where antennae atop surrounding peaks broadcast the various Galileo signals. Technical details and specifications of the test environment are at www.gate-testbed.com.

    The GATE infrastructure is capable of transmitting the Galileo Open Service, the Safety-of-Life Service (functional, with certification as a next step), the Commercial Service, and a Public Regulated Service  dummy signal.

    The GATE system upgrade has been further extended to also support user integrity testing, simulating simple alarm-triggering events on the system/satellite level, supporting GPS and GATE/Galileo dual-constellation receiver-autonomous integrity monitoring (RAIM), individual user integrity test scenarios, and tests of receivers with different RAIM functionalities.

    Next-Generation GLONASS

    As this magazine goes to press, a Soyuz rocket carring a new GLONASS-K1 satellite has moved to the Plesetsk Cosmodrome launch pad for a scheduled blast-off on February 24. Assuming all goes well, the satellite’s eventual transmissions will include Russia’s new CDMA signal on a GLONASS L3 frequency. Further information and photos will be posted to env-gpsworld-integration.kinsta.cloud/glonassk.

    In Other Developments. Roscosmos, the Russian space agency, said it lost contact with a military satellite launched on February 1, a painful incident following the failed launch of three GLONASS-M satellites in December.

    The Geo-IK-2 satellite, designed for geodetic studies, remains in its transfer orbit because the upper stage failed to restart for its second circularizing burn. Based on the GLONASS-M bus, Geo-IK-2 carries laser reflectors, GPS/GLONASS receiving equipment, and an altimeter. Communications with the satellite have been re-established but it is not clear how useful it will be in its current orbit.

    Galileo IOV August Launch

    The European Space Agency announced that the first two Galileo in-orbit validation (IOV) satellites will rise on August 31. They will ride aboard a Soyuz-ST-B rocket from the Kouros, French Guiana, Space Center. There was no word about the third and fourth IOV satellites, which had at one point been scheduled for an October launch, at a time when the first two were penciled for a June launch.

    JAVAD Receivers Track Compass B1 Signal

    JAVAD GNSS has announced that, with modified firmware, all of the company’s receivers can now track the Chinese Compass B1 signal. The company states that Compass is the sixth GNSS system that its receivers can track, joining GPS, GLONASS, Galileo (the two GIOVE in-orbit validation experimental satellites), SBAS (the European Geostationary Navigation Overlay Service or EGNOS), and Japan’s Quasi-Zenith Satellite System (QZSS).

    JAVAD GNSS made available several plots, shown here. One is a log file, collected on JAVAD’s TR_G3TH board in Moscow during the last weekend in January, reporting up to 26 satellites from the various systems, locked simultaneously. Also provided below are several other plots showing the new capability.

    The company further stated that it will add Compass tracking to almost all receivers in near future, as a firmware upgrade.

  • Out in Front: Act Now to Protect GPS Signal

    This guest editorial addresses a subject of paramount importance to the GNSS industry, to the U.S. national infrastructure, and to the global GNSS community. I urge you to take immediate action by contacting U.S. government representatives, indicated at the end of this article.

    — Alan Cameron, editor-in-chief

     

    Guest Editorial by Joe Paiva

    GPS has become a key component of the U.S. national infrastructure, the driver of a significant part of the civilian economies of the world, and the enabler of millions of professional precision uses and consumer benefits.The viability of the GPS signal is now threatened — ironically by what appears to be a misguided attempt to increase accessibility to broadband by creating a needless zero-sum result for customers who want both services.

    The threat is real and immediate. The U.S. Federal Communications Commission (FCC) has issued a conditional waiver to LightSquared, a company engaged in developing 4G-LTE (long-term evolution) cellular networks for wholesale-only basis commerce with its business partners.

    LightSquared Scheme. LightSquared acquired a company providing a combined space-based and ancillary land-based service using the L-band radiofrequency. The FCC conditional waiver, granted to LightSquared on January 26 of this year, allows it to broadcast a new terrestrial broadband service from 1,500-watt terrestrial transmitters — 40,000 of which will eventually be installed by LightSquared — in the portion of L Band (1525 MHz–1559 MHz) immediately adjacent to the 1559–1610 MHz band used by GPS.

    Instead of offering dual-mode handsets exclusively as required by their FCC license, retailers purchasing this combined service can choose to offer terrestrial mobile phones only, which was the change in license terms that LightSquared was seeking via waiver. This change amounts to a de facto reallocation of Lightsquared’s spectrum use from space to terrestrial wireless. In fact, the new broadband service is planned to operate in urban areas, and the space service will operate outside these areas.

    The LightSquared terrestrial broadband signal is about 1 billion times the received power of the GPS signal on Earth. Members of the GPS industry have been conducting experiments and analyses, and these figures come from those very early studies. Soon, we may experience GPS interference — jamming — on an almost unimaginable scale and to a geographical extent that could create widespread havoc.

    Threats. The GPS system works so well that we often forget the complexity behind it and take for granted the service we use daily. One reason GPS works so well and is seldom defeated is that the signals broadcast by the satellites can be received under a wide variety of conditions on Earth. Historically, the FCC and the International Telecommunications Union, understanding potential interference issues, intentionally planned uses of adjacent swaths of the L-band so that satellite-based transmissions, relatively low-power, would be natural neighbors, so as to cause as little disturbance as possible to radio-navigation uses. This dedicated purposing of the bands and the resulting environment of negligible interference is one reason that GPS has become reliable and its use ubiquitous.

    Long-time observers of the GPS scene will remember how civilians, and especially potential international users, initially had uncertainty about the U.S. Department of Defense’s statements that the service would be free and not subject to any restrictions in one’s ability to receive and use the broadcast signals. This uncertainty was due primarily to the implementation of Selective Availability (SA), which intentionally degraded the available accuracy of the GPS signal. SA was permanently removed in 2000 by President Clinton’s 1996 Presidential Decision Directive.

    Many factors have enabled users and potential users to see GPS as a reliable, consistent technology that provides significant increases in productivity, efficiency, precision, continuing innovation, and many other benefits. These factors include the reliability of the overall GPS technology, improvements in receivers and in successive next-generation satellites, advances in differential and relative positioning, dynamic applications, and real-time kinematic solutions. And, just as importantly: stable, predictable U.S. policy.

    Investments. Now, by virtue of this unusual FCC action, uncertainty has been thrown into the viability of the hundreds of millions of GPS receivers in use today. Much research and development work is being done on improving receiver performance and taking advantage of improvements planned for the satellites. The most dollars go towards devising new applications, products, and services that improve the quality life of millions of Americans, create new companies, markets, and jobs. These dollars are also being spent by government agencies, not just the Department of Defense, but very visibly by Agriculture, Commerce, Interior, Energy, Homeland Security and Transportation. More than likely, the remaining departments either have active programs that are using or considering using GPS or are positively affected by others’ use of GPS.

    That’s just the executive branch. Other parts of the federal government, as well as state and local governments, do research on GPS technology and applications and actively use GPS to improve the lives of citizens, increasing work and recreation, efficiency, and safety. In many local government settings, there is active cooperation to improve delivery of services by having governmental and non-governmental organizations collaborate around the simple fact of accurate position being available through GPS, with significant cost savings in current lean budgets.

    It is inexplicable that another part of the government would be so cavalier in rapidly and uncharacteristically granting a waiver that clearly endangers the whole system. And only after granting the waiver, which must act at least as a yellow light for LightSquared’s mobilization plans, comes the requirement for a study — to be headed by LightSquared — to determine impacts and mitigation of interference with the GPS signals.

    Why Fast Track? The FCC grant of a reallocation of spectrum use from space to terrestrial on a fast-track waiver did not follow the standard FCC rule-making process for reallocation of spectrum use. The standard regulatory approach allows sufficient time for robust public comment by all potentially affected parties, including the conduct of interference studies and the introduction of comments on interference results in the public record. Instead, the FCC order granting the waiver to LightSquared has mandated what appears to be fast-track GPS interference research.

    Currently, the proposed LightSquared terrestrial broadband service does not have an installed user base. In contrast, the installed GPS user base represents a broad and diverse range of use representing hundreds of millions of users established over 30 years.

    The final Working Group report is due to the FCC on June 15, 2011. The FCC order requires the GPS community to participate “in good faith” in this study effort. In response, the U.S. GPS Industry Council and others are working on this interference study to protect GPS operations under these extraordinary regulatory conditions.

    A further problem created by the FCC conditional waiver is that LightSquared is able to move ahead with its infrastructure development, assuming that viable solutions to the jamming issue will be found. For many GPS users, theoretical fixes are not likely to prove viable.

    Negative Impacts. Preliminary research done by member companies of the USGIC already has been reported in GPS World. The research indicates that LightSquared’s 1,500-watt terrest
    rial transmitters will result in a signal 90 dB stronger than GPS over the coverage area; this amounts to signal strength 1 billion times stronger than GPS. There is more to the research, all done with GPS simulators and signal generators (see env-gpsworld-integration.kinsta.cloud/data for test results).

    Clearly the jamming level will vary with geography. We don’t yet know LightSquared’s broadcast-tower siting plan. But it is clear that if LightSquared is allowed to broadcast terrestrially on the mobile satellite system (MSS) band, dedicated until now to signals compatible with satellite transmissions, there is a substantial danger that millions of GPS receivers will be adversely affected.

    Some obvious impacts are loss of operational viability of businesses involved in aviation, surveying, agriculture, engineering and construction, vehicle navigation, mariners, transportation, public safety and homeland security, disaster management, utilities, mapping, and scientific research. Several of these involve safety-of-life issues, which are at risk of being jammed.

    Keep in mind that GPS was envisioned as a system for space and time. Its longest life as a useful contributor to society has been as a time standard. Countless networks, whether for computing, broadcasting, power generation — even, ironically, cell phones — are synchronized using the most precise signal practically available. Fixed GPS receiving stations for time reference may be able to be designed to withstand some interference from high-power broadcasting on adjacent frequencies, but nobody has tried so far.

    Any hypothetical fixes for GPS beg a more fundamental question: Why should Lightsquared, a new entrant with no existing business, be allowed to shift the burden of mitigating interference created by its operations to millions of consumers, government agencies, and businesses who have invested in GPS over the last 30 years?

    Keep in mind that other users of the MSS band will also be affected. Many commercial and governmental uses of the very band that LightSquared will occupy with its terrestrial transmitters may also be jeopardized.

    We must also remember that the FCC has its own agenda, to implement its National Broadband Plan. What is truly difficult to comprehend is that broadband and GPS will serve the same mobile user.

    Action Needed. Please act now.

    • Write to your representatives in Congress, and to your professional and trade associations.
    • If you are an expert on radio or spectrum or GPS or whatever else is pertinent, make your comments, do your research if possible, and publish your results with all due speed.
    • Petition the FCC to turn the yellow light to red, while other paths to achieving LightSquared’s and the FCC’s goals are investigated.
    • Do not forget the Administration: the National Telecommunications Information Administration (NTIA) represents the president and the Administration as official co-regulator with the FCC of the spectrum where GPS operates. In the recent FCC Order, NTIA must review the report on results of the FCC-mandated interference study.
    • Specifically, ask Congress to demand that the FCC include specific language to protect GPS use in the final FCC Order to LightSquared after the interference study is completed.
    • Ask the Secretary of Commerce and the White House Office of Science and Technology Policy (OSTP) to inform the NTIA Administrator to urge the FCC chairman to take this same action to protect GPS in the final FCC Order.
    • Contact the FCC chairman directly and urge this same action.
    • Finally, help develop user and beneficiary awareness of the grave danger being posed to GPS and make your elected and congressional representatives aware of the impact that interference with GPS would have on your work.

    The large-scale disruption of the GPS service mustn’t be on our hands due to inaction.

    Points of Contact

    Send messages to FCC chairman, commissioners, and NTIA:

    • Edward.Lazarus at fcc.gov (Chairman Genachowski’s office
    • John.Giusti at fcc.gov (Comm. Copps’ office)
    • Angela.Giancarlo at fcc.gov (Comm. McDowell’s office)
    • Louis.Peraertz at fcc.gov (Comm. Clyburn’s office)
    • Charles.Mathias at fcc.gov (Comm. Baker’s office)
    • lstrickling at ntia.doc.gov (asst. secretary for communications and information, NTIA)

    International readers may contact the U.S. State Department, clorere at state.gov. For further contacts, see env-gpsworld-integration.kinsta.cloud/actnow.

    Joseph Paiva is a consultant to the geomatics industry, with background in private engineering, surveying and mapping consulting, and as developer and general manager for two geomatics products corporations.

     

    High-Precision Users

    High-performance L1 receivers (sub-meter) have a wide-bandwidth RF front-end to improve performance, about 20 MHz, compared to a consumer receiver that typically has a front-end bandwidth of 2 MHz. GPS World contributing editor for survey and GIS Eric Gakstatter discusses this aspect of the issue in his recent e-mail newsletter column at env-gpsworld-integration.kinsta.cloud/l2high.

  • Expert Advice: Positioning Protocol for Next-Gen Cell Phones

    Expert Advice: Positioning Protocol for Next-Gen Cell Phones

    Lauri_Wirola
    Lauri Wirola, Nokia Services Location

    by Lauri Wirola, Nokia Services Location

    As cell phones move into the next generation called Long-Term Evolution (LTE), also sometimes called 4G, and the methods of wireless transmission change, so too must the methods of providing location information over those new wireless interfaces. LTE Positioning Protocol (LPP) and Secure User Plane Location (SUPL) 2.0 and 3.0 are the key players in this new picture.

    Cellular industry location standards first appeared in the late 1990s, with the 3rd Generation Partnership (3GPP) Radio Resource Location Services Protocol (RRLP) Technical Specification (TS) 44.031 positioning protocol for GSM networks. Today RRLP is the de facto standardized protocol to carry, for instance, GNSS assistance data to GNSS-enabled mobile devices.

    A major update of RRLP began in 2007, when RRLP Release 7 added support for assisted-Galileo, and Release 8 for the rest of the GNSS including GLONASS, modernized GPS, QZSS, and the various SBASs.

    RRLP Releases 7/8 set high expectations in terms of performance improvements. The initial idea was to go beyond the native capabilities of GNSSs to achieve tangible accuracy, time-to-first-fix (TTFF), and availability improvements. Contributors proposed introducing local ionosphere and troposphere models as well as carrier-phase-based relative positioning — in cell phones!

    However, legacy implementations, architecture limitations, and the lack of a business case hindered this development. In the end, RRLP support was limited more or less to the native assistance data types such as global Klobuchar and NeQuick models for the ionosphere. The same approach was also mapped to 3GPP TS 25.331 Radio Resource Control (RRC) protocol, which defines the positioning procedures and assistance data delivery for Universal Mobile Telecommunications System Terrestrial Radio Access (UTRA) — that is, wideband code-division multiple-access (WCDMA) and time-division synchronous CDMA networks.

    Long-Term Evolution Networks

    A fresh push for location services in 3GPP started in 2009 for LTE Release 9 technologies. LTE is sometimes called 4G, but to be precise only a further evolution of LTE, called LTE Advanced (LTE-A), will be 4G, together with WiMAX evolution 802.16m.

    The starting point for LTE location services work was to enable similar positioning capabilities in the LTE networks as are present in GSM, UTRA, and CDMA networks. This meant that there was a need to define assisted-GNSS positioning as well as introduce positioning methods, such as enhanced cell ID (ECID) and hyperbolic time-difference-of-arrival (TDOA) methods for non-GNSS devices, hybrid use, and for GNSS-denied environments. The underlying driver of all this work was the U.S. Federal Communications Commision (FCC) Wireless E911 mandate.

    LTE Location Architecture

    LTE location architecture is shown in Figure 1. The evolved serving mobile location center (E-SMLC) is the server component in charge of positioning activities. The mobility management entity (MME) gives the positioning request to E-SMLC, which then controls the user equipment (UE, the LTE device to be positioned) and, possibly, LTE base stations (eNodeBs), to perform positioning.

    Figure1-W
    Figure 1. Long-Term Evolution (LTE) location architecture.

    LTE Positioning Protocol. The actual positioning and assistance protocol between E-SMLC and UE is called LTE Positioning Protocol (LPP). In overview, LPP consists of three independent elementary procedures: capability exchange, assistance data exchange, and location information exchange, which refers to both measurement and position. The associated messaging is shown in Figure 2. In addition to the six message types shown, there are LPP Error and LPP Abort messages to handle abnormal situations.

    Figure 2. LPP elementary procedures and messages. In LPP terminology, “target” is the end user device to be positioned.
    Figure 2. LPP elementary procedures and messages. In LPP terminology, “target” is the end user device to be positioned.

    Figure 3 shows a sample positioning session using all the procedures. Assume that the server has received a location request for a given target (UE) and that the server can exchange messages with the UE — that is, lower protocol layers can provide the transport for the LPP-level messages. The first transaction of the location session is the capability exchange (LPP Request/Provide Capabilities). This information exchange makes the server aware of the UE positioning capabilities (GNSS support, supported cellular network measurements). Based on this information, the server can make a decision on the positioning method to be used, based on both UE capabilities and the requested quality-of-position (response time, accuracy).

    Figure 3. Example of a typical LPP positioning session.
    Figure 3. Example of a typical LPP positioning session.

    The actual location information request is carried in LPP Request Location Information message: whether position or measurements are requested and/or allowed and, for instance, which GNSSs are allowed to be used. It also carries other reporting instructions such as periodicity and required response time.

    Having received this message, the target begins its positioning activities. In a typical scenario, this activity triggers a request for the assistance data. For instance, if the server requests the GNSS-based position, and the target does not have the latest ephemerides, the target will request those with the LPP Request/Provide Assistance Data mechanism (transaction 3). Having received the ephemerides, the target can position itself quickly, without needing the data broadcasts from the satellites, and report the location information back to the server in LPP Provide Location Information message. Other supporting information, such as reference location, reference time and ionosphere model, may also be provided to the target.

    Figures 4 and 6 summarize the contents of LPP Provide Location Information and LPP Provide Assistance Data messages, respectively, in the gray boxes. The LPP Provide Location Information contents can be roughly divided into four categories: one category for each positioning method (assisted GNSS, observed TDOA, and ECID) and one category for providing the location estimate. In the A-GNSS category, the UE, based on the server commands, either reports the raw code and carrier-phase measurements (UE-assisted mode) or information regarding the provided PVT estimate (OTDOA and ECID function only in UE-assisted mode in LPP).

    Figure 4. LPP/LPPe Provide Location Information content. 3GPP LPP shown in gray; OMA LPP Extensions shown in green. (Click too enlarge.)
    Figure 4. LPP/LPPe Provide Location Information content. 3GPP LPP shown in gray; OMA LPP Extensions shown in green. (Click too enlarge.)

    The LPP Provide Assistance Data reflects the same structure and categorization. Similarly, to Provide Location Information message, one can see in the assistance data message GNSS-specific assistance as well as OTDOA-specific assistance. However, there is no ECID-specific assistance due to it being available only in UE-assisted fashion. For OTDOA there is assistance, but only to assist the UE in the measurement process, not for positioning purposes — for instance, eNodeB positions cannot be transferred in the assistance data.

    User Plane and Applications. RRLP, RRC, and LPP are natively control-plane positioning protocols. This means that they are transported in the inner workings of cellular networks and are practically invisible to end users. In the control pla
    ne, their main purpose is to reliably provide the emergency-call positioning capability. However, there is obviously demand for positioning services for location-based end-user applications. To address this, in 2003 the Open Mobile Alliance started to work with Secure User Plane Location (SUPL) 1.0 protocol that brings the same location capabilities to user plane (application domain) over IP-networks as RRLP/RRC/LPP bring to control plane. One design principle of SUPL was not to re-invent the wheel; thus RRLP/RRC/LPP are being re-used in the user plane domain for positioning. OMA SUPL specifies a bearer protocol that carries a 3GPP-defined positioning protocol and provides security, authentication, privacy, and charging mechanisms. SUPL 1.0 is already commercially deployed, and SUPL 2.0 is now being deployed globally.

    Figure 5 shows the OMA SUPL 2.0 protocol stack, which illustrates the re-use of 3GPP positioning protocols over IP networks. The security is provided by the standard transport layer security (TLS), and the user plane location protocol (ULP) is the wrapper for the 3GPP positioning protocols. The vast majority of SUPL 2.0 deployments will use RRLP as the positioning protocol. SUPL 3.0, currently being defined, will no longer support RRLP/RRC; LPP will gradually replace RRLP as the dominant standardized positioning protocol.

    Figure 5. OMA SUPL 2.0 and 3.0 protocol stacks. TIA-801 is the 3GPP2-defined positioning protocol for the CDMA networks. Note that ULP 1.0 (not shown) supports RRLP, RRC, and TIA-801.
    Figure 5. OMA SUPL 2.0 and 3.0 protocol stacks. TIA-801 is the 3GPP2-defined positioning protocol for the CDMA networks. Note that ULP 1.0 (not shown) supports RRLP, RRC, and TIA-801.
    Figure 6. Assistance data content of LPP and LPP Extension. 3GPP LPP shown in gray; OMA LPP Extensions shown in green. (Click too enlarge.)
    Figure 6. Assistance data content of LPP and LPP Extension. 3GPP LPP shown in gray; OMA LPP Extensions shown in green. (Click too enlarge.)

    LPP Extensions

    From the beginning, it was clear that the contents of the LPP would largely reflect that of the RRLP and would be limited to the native capabilities in the GNSS domain, and in other positioning methods to the methods strictly needed to fulfill the emergency-call positioning requirements. For example, in the GNSS domain the ionosphere models are limited to the (global) broadcast models as obtained from GPS, QZSS, and Galileo; there is no support for local ionosphere models. Other potential performance improvements including troposphere models and pressure-based altitude assistance are not in the scope of the 3GPP LPP work. Furthermore, a plethora of other positioning methods ranging from GSM- and WCDMA-based positioning (ECID, hyperbolic TDOA methods) to utilizing WLAN and short-range nodes such as Bluetooth are beyond the scope of current LPP development.

    During the LPP Release 9 work, the industry was at a crossroads. On one hand, it was known that the 3GPP-defined LPP would become the de facto standardized protocol to do basic positioning not only in the LTE control plane, but also in IP networks over SUPL 2.0 and 3.0. On the other hand, it was also known that it would lack some key features including WLAN-based positioning, which would essentially force vendors to introduce proprietary protocols to augment LPP. Further, a serious drawback for use of LPP in the IP-network domain is that it does not support GSM- and UTRA-specific positioning methods (ECID, OTDOA). Thus, LPP could not completely replace legacy positioning protocols, including RRLP.

    These considerations led to discussion of introducing extension hooks in LPP messages, so that the bodies external to 3GPP could extend the LPP feature set. In 2009, Qualcomm contributed extension containers to the LPP messages, and the way was open to start work on OMA LPP Extensions Release 1.0 in 2010.

    The mandate of the OMA LPP Extensions (LPPe) is to build on top of the 3GPP LPP, re-using its procedures and data types as far as possible. This means that the message types are fixed; new messages cannot be defined, only extensions to existing ones can be formulated. Whenever possible, OMA should re-use information elements from 3GPP LPP to avoid duplicate definitions, compatibility, and maintenance issues. LPPe is supported in SUPL 3.0, which will be the primary transport protocol of LPPe.

    Procedure Extensions. OMA LPP Extensions Release 1.0 not only defines new positioning methods and assistance data types, but also defines new procedures for improved performance. These include the following:

    ◾ Capability exchange and location-information exchange reversed mode, illustrated in Figure 7, with the LPPe Request/Provide Capabilities/Location Information messages flowing in the opposite directions as compared to Figure 2. This reversed mode is only allowed in the context of LPPe. In the context of assistance data support, capabilities in the reversed case refer to the assistance data that the server can provide, as opposed to the assistance data the target can utilize in normal mode-capability exchange.

    Figure 7. LPPe reversed mode for capability and location information exchange.
    Figure 7. LPPe reversed mode for capability and location information exchange.

    The interpretation of reversed mode for location information exchange is somewhat more delicate. When the UE sends LPPe Request Location Information to the server, the UE does not request the server position, but the UE position. In the request the UE may define the quality-of-position, which then guides the positioning method selection by the server.

    • Periodic assistance data is a completely new feature to the assistance-data protocols. Periodic assistance can be used with selected assistance-data types that require updates at short intervals. Such data types include short-term real-time ionosphere correction from GNSS networks and carrier phase — assistance for high-accuracy relative positioning. The periodic assistance procedure also includes the possibility for the target and server to update the periodic session-control parameters (duration, rate of delivery) intra-session. This control is carried in the common part of the LPPe Request/Provide Assistance Data message (Figure 6).
    • Periodic location information reporting is included in 3GPP LPP, but the similar capability in the OMA LPPe is specifically designed for continuous measurements including continuous carrier-phase measurements for high-accuracy purposes. The 3GPP LPP does specify periodic measurements, but in such a way that, say, the GNSS measurement engine can be powered off between measurement deliveries, which is obviously unacceptable in the view of carrier-phase-based relative high-accuracy GNSS. The periodic location information procedure also includes the possibility for the target and server to update the periodic session-control parameters (duration, rate of delivery) intra-session. This control is carried in the common part of the LPPe Request/Provide Location Information message as shown in Figure 4.
    • Segmented assistance-data transfer procedure allows for partitioning a large assistance-data delivery into smaller segments as well as resuming such a segmented session after an active-inactive-active cycle in the LPPe session. This control is carried in the common part of the LPPe Request/Provide Assistance Data message as shown in Figure 6.
    • Measurement scheduling/windowing allows the server to request measurements (GNSS, ECID, TDOA) to be made within a certain time window that can be expressed in terms of GNSS time or cellular network time. This control is carried in the common part of the LPPe Request/Provide Location Information message as shown in Figure 4.

    Extensions. OMA LPPe introduces several enhancements for various positioning methods as well as completely new methods:

    • Additions in the A-GNSS domain include local atmosphere models. In 3GPP LPP, the models are limited to ionosphere ones and therein to the broadcast types as in GPS, Galileo, and QZSS broadcasts. The OMA LPPe introduces a localized Klobuchar model, which allows for presenting the delay corrections in the well-known Klobuchar model, but for a limited-validity area and time for more accurate delay compensation. In addition, ionosphere storm warnings can be carried to the UE at the chosen resolution. This information allows UE to deduce the reason for high measurement residuals.

    Troposphere models have not previously been in the scope of the standardized assistance protocols. The troposphere model in LPPe carries the hydrostatic and wet zenith delays, their change rates in the height dimension for approximating the zenith delays at the UE altitude, Niel mapping functions for hydrostatic and wet components, and composite spatial gradients. Alternatively, the surface meteorological parameters (pressure, temperature) can be carried to the UE, and the calculation of the troposphere delay is left for the UE.

    Another troposphere model is the altitude-pressure relationship for the UEs with a barometer. This altitude assistance increases availability by introducing an independent source of altitude information.

    Whereas the 3GPP LPP carries the ephemerides, almanacs, signals supported by the satellites, and the GLONASS frequency mappings, OMA LPPe introduces satellite mechanical informational, differential code biases, and new navigation models. The mechanical information consists of mass, effective reflectivity-area, and phase-center offsets for the in-UE orbit prediction purposes. In the navigation model domain, the additions include SP3-type orbit representation and the orbit/clock model degradation models for improved error modeling. Practically all the new assistance data types support precise-point positioning approaches for future GNSS services.

    Lastly, one of the major LPPe A-GNSS features is the continuous carrier-phase (CCP) assistance for real-time kinematic applications. The CCP data format supports straightforward mapping from RTCM 10403.1 to ensure interoperability. The LPPe CCP mechanism utilizes the LPPe-level periodic assistance data procedure and supports multiple reference stations as well as mobility, that is, changes in the set of active reference stations on-the-fly.

    • To enable the use of LPP/LPPe in all the networks, the legacy hyperbolic methods E-OTD and OTDOA-IPDL for GSM and UTRA networks, respectively, are supported, and the data content are copy/pastes from RRLP and RRC to ensure interoperability. Support for UE-based LTE OTDOA is also included.
    • A major part of LPPe specification is devoted to the various ECID methods. These cover GSM, UTRA, LTE, and WLAN networks both in UE-assisted and UE-based modes.
    • In LPPe terminology, the short-range nodes (SRNs) refer to Bluetooth, Bluetooth Low-Energy, and near-field communication (NFC) tags, which are considered separately from the primary communications networks (cellular networks and WLAN). Similarly to the ECID methods, the SRNs can be used for positioning in either UE-assisted or UE-based modes. In the UE-based mode, in which the SRN locations need to be carried to the UE, the philosophy is that the SRNs are logically arranged into groups – one group of SRNs can be the set of SRNs in one building or in one floor in the building. The assistance data is considered in the units of these groups in conjunction with the group data version that allows for handling situations, in which the arrangement of the SRNs in the building changes, and the data in the UE needs to be refreshed.
    • Finally, no single positioning and assistance protocol can address all needs. Thus, both LPPe assistance data exchange and LPPe location information exchange include black-box containers for vendors and operators to carry their own proprietary assistance data and location information in a standardized framework. The benefit of this approach is that the same standardized protocol framework used in commercial deployments can be used for rapid prototyping and providing differentiating positioning performance, without the need for defining proprietary protocols from scratch.

    Conclusion

    The framework introduced by 3GPP LPP and extended in LPPe brings long-sought convergence in the control- and user-plane positioning protocols. This ensures that in the user-plane domain, the dominant domain for positioning services in consumer LBS, vendors can utilize exactly the same protocol as in the control plane. This reduces implementation, testing, and deployments costs, and will make the LPP/LPPe the de facto standardized positioning protocol in the mobile domain.

    Lauri Wirola has a Ph.D. in electrophysics from Tampere University of Technology in Finland. He manages indoor positioning activities at Nokia Services Location.

  • Iraq on the Map: Installing Reference Stations for Accurate Engineering

    By Anas Malkawi

    Edge-HARNS-installation
    The team installs a HARNS in the southern province of Basra. Since 2005, Iraqi engineers have attempted to recover HARNS, but many were destroyed by locals who thought they indicated buried treasure.

    As a geodetic surveyor, I served in the U.S Army for 10 years. During that time, my team and I developed a nationwide GPS infrastructure system called the Iraqi Geospatial Reference System (IGRS). We installed Continuously Operating Reference Stations (CORS) and High Accuracy Reference Network Stations (HARNS), the first Iraqi owned and maintained system of its type.

    As a native Arabic speaker, my role was to train the Iraqi engineers to install additional CORS, as well as update and maintain the IGRS as a part of the International GNSS Service (IGS) network to sustain the accuracy of engineering and mapping projects. The IGRS was critical to other major infrastructure projects in the effort of rebuilding the battered nation, such as telecommunications, public works, and natural resource management to name a few.

    Some of the CORS we installed have Virtual Reference System (VRS) capability, a technology newly developed to establish real-time corrections in the field by using CORS as a base station for real-time kinematic (RTK) data collection.

    Key coordinators for the installation included Wisam Al-Hassani of the Iraq Ministry of Water Resources, Paul McKenzie of the Canadian Army, Linda Allen of the U.S. State Department, and myself, representing the U.S. Army, in addition to representatives from National Geodetic Survey (NGS), National Geospatial-Intelligence Agency (NGA), and Trimble Navigation.

    In addition to developing the IGRS, we performed several critical projects to assist in the rebuilding efforts as well as providing force protection, navigation, and mapping. My topographic engineering unit was responsible for providing coalition forces with GIS analysis, map production, and geodetic surveys.

    Edge-GPS-in-Haditha-Dam
    GPS equipment collecting data on a reference benchmark used to monitor the deformation of the Haditha Dam.

    For my second tour in Iraq (2007–2008), I was the platoon sergeant, which is equivalent to a project manager in a surveying firm. During the 15-month deployment, my team performed various survey projects including: 10 airport obstruction surveys, a dam deformation survey, more than 30 artillery and target-acquisition radar surveys, base-camp designs, site layouts, and ground-truth data collection for photogrammetry and remote sensing projects. We also established a nationwide database of all survey control stations in Iraq. The CORS was installed using Trimble NetRS receivers and Zephyr geodetic antennas. Trimble GPSNet and GPSBase software were used to process the continuous satellite data, for inclusion in the worldwide CORS network for public use. Field survey operations were conducted using Trimble 5700 GPS equipment.

    Traveling in Iraq was a major obstacle for survey operations. We had a choice: either fly on helicopters or drive military vehicles. Flying in helicopters with survey equipment was a challenge because we could never fit all our personnel and equipment. However, it was much safer than ground transportation through the dangerous roads of Iraq. In one incident, we were building a bridge in Baiji to help Iraqis and coalition forces cross the Tigris River after the original bridge was destroyed during the 2003 invasion. Our vehicle hit an improvised explosive device (IED). Some of the survey equipment was damaged, but we went back the next day and eventually built the bridge.

    Anas Malkawi served 10 years in the Army as a geodetic surveyor and senior technical engineer. He is currently enrolled in Old Dominion University’s Civil Engineering program while working at Transocean International Corporation as the Iraq program manager.

    Edge-IGRS-plan-map
    The initial plan of IGRS and placement of CORS/HARN through the Southern provinces.
    Edge-Airport
    Soldiers establish geodetic control for an airport aeronautical survey.
    Edge-Navaid-Survey
    Soldiers survey airport navigational aids that require high geodetic accuracy.
    Edge-IGRS-new-CORS-plan-meeting
    Malkawi discusses installation of Iraqi operated and maintained CORS with Al-Hassani.
    Edge-crash
    The result of traveling in military vehicles over roads infested with IED.
    CORS-coordination-team
    Key coordinators for the installation of the first Iraqi owned and maintained Continuously Operating Reference Station (CORS.) From left are Hussein, Malkawi, McKenzie, and Allen.
    Edge-Grp
    The 2005 U.S./British IGRS Team. Despite the difficulties, the soldiers I am honored to have served with stayed motivated and performed exceptionally every day by providing accurate data that saved lives.

     

     

  • GLONASS K-1 Launch Delayed Twice, Rescheduled for Tomorrow

     


    GLONASS-K is moved to the launchpad.

    News courtesy of CANSPACE listserv.

    According to a Roscosmos report, the state commission governing rocket launches will launch GLONASS-K1 on February 26 at 03:06 UTC. The launch of GLONASS-K1 has been pushed back for “technical reasons.” The original schedule called for a February 24 launch.

    Quoting the commander of the Russian Space Forces, Lieutenant-General Oleg Ostapenko, an Interfax news item stated that there was insufficient time to ready the rocket for launch february 25, though it was announced as a launch date following the scrub on February 25. “The probability of a launch on the 26th is very high,” Ostapenko said.

    Meanwhile, Komsomolskaya Pravda quoted an unnamed space industry official as saying that if the launch is not held tomorrow, it will be put off for a month. “[The decision will be] once again to be safe, rather than to carry out the launch, which for technical reasons, was postponed for the second day in a row. Without further checks, and to eliminate technical problems, no one [wants to] take responsibility to conduct the launch,” he said.

    Gazeta.ru, an online Russian newspaper, has carried a report in which Nikolai Testoedov, the chief designer and CEO of Information Satellite Systems Reshetnev states that seven GLONASS satellites will be launched this year. In addition to GLONASS-K satellites being launched this month and in December, five GLONASS-M satellites will be launched. Three will be launched on a Proton-M rocket from Baikonur (this launch is expected in June). He said that, in addition, two GLONASS-M satellites will be launched on the Soyuz-2 rocket from Plesetsk. The first of the five GLONASS-M satellites is to be delivered to the customer on February 28.

  • Three Reasons Why Social Media Works: New Zealand Earthquake Is a Perfect Example

    Location-based social media, whether it be Twitter or Ushahidi or Gowalla or Foursquare, works. The earthquake in New Zealand earlier this week is a perfect example of how it works and why location-based social media will become an integral part of our lives.

    There are many variations of location-based services (LBS). The one most folks pay attention to are the social networking type of apps:

    “Send me a text message when Bill is within a half mile of me.”

    “Have Starbucks send me a text message, a coupon, and its location when I’m within 2 km of a store.”

     

    Then there’s the family finder type of LBS apps:

    “Send me a text message when my child arrives at school.”

    “Send me a text message when my child ventures outside of my preset boundary.”

     

    Location-based social media is a bit different than both of the above. You can think of the LBS social media as giving everyone with the proper equipment (a smartphone) the opportunity to be a news correspondent. The “correspondent” can be “reporting” hard news (timely events) or feature stories (human interest). Mostly, the reports are covered in 140 characters or so (thanks Twitter).

    The power of location-based social media is that on-site news can be published in near real-time, much faster than a news bureau sending a news correspondent to the scene.

    Consider the New Zealand earthquake earlier this week.

    Esri has developed an incident response map tool for collecting and displaying social media content for events like the earthquake.

    The New Zealand Incident Map shown below (click on it for an interactive map) was a joint effort of a local government entity (Environment Canterbury) and the local Esri distributor (Eagle Technology Group).

    Earthquake in Canterbury/Christchurch, New Zealand

     

    As you can see on the map, it includes content from Ushahidi, Youtube, Twitter, and Flickr.

    If you haven’t heard about Ushahidi, you should know that it is a non-profit technology company voted by MIT’s Technology Review as one of the 50 Most Innovative Companies for 2011. According to its website, Ushahidi’s “roots are in the collaboration of Kenyan citizen journalists during a time of crisis. The original website was used to map incidents of violence and peace efforts throughout the country based on reports submitted via the web and mobile phones. This website had 45,000 users in Kenya, and was the catalyst for us realizing there was a need for a platform based on it, which could be used by others around the world.”

    Youtube is an efficient way to share video footage over the web.

    Twitter is, according to its website, “a real-time information network that connects you to the latest information about what you find interesting. Simply find the public streams you find most compelling and follow the conversations. At the heart of Twitter are small bursts of information called Tweets. Each Tweet is 140 characters in length.” I call Twitter “the text message to everyone,” at least everyone who has chosen to receive your Tweets.

    Flickr is an efficient way to share photos over the web.

    By compiling data in near real-time from these four technologies, as well as the basemap information (OpenStreetMap or some other source), an amazing amount of useful information can be shared. Think about it — even with a little known technology such as this, click on some of the several hundred content entries and one can instantly see the value. The content search name for each provider has a default name. For example, the search term used to pull content for the New Zealand earthquake from Youtube is “christchurch earthquake”.

    Some example Ushahidi content obtained by clicking on Ushahidi symbols on the map:

    ———————-

    Shops collapsed on corner of Lichfield and High Street, possibly trapped people.

    On the corner of Lichfield & High streets, a block of shops collapsed — rescue svs believe 4-5 people are trapped in the rubble.

    Date Published: 2011-02-21 21:53:00

    Category: Building damage – red

    ———————

    Fitzgerald Bridge by Kilmore Terrace impassable.

    Route around is not usable.

    Date Published: 2011-02-23 13:55:00

    Category: Road damage

    ———————

    BNZ ATM Riccarton Mall

    Working ATM as at 10:49 p.m., 22 Feb – Division St, Riccarton

    Date Published: 2011-02-22 22:47:00

    Category: ATM/Money centre

    ——————–

    Such citizen reporting is enabled by three technologies; smartphones, social media apps, and GIS (including app software and basemaps). The first two are relatively new technologies and are being adopted at a very fast pace, so I would expect that crises like the recent flooding, political unrest, earthquakes, and other large-scale crises will never be reported the same in the future. Smartphones have empowered people with the ability to share an unprecedented amount of information.

    This Just In

    Following is another current event where information is being shared via citizen reporting. Note the date on the posts. This is as near real-time as you’ll get:

    Unrest in the Middle East

     

    Thanks, and see you next week.

    Follow me on Twitter at http://twitter.com/GPSGIS_Eric

  • Raytheon Interview: GPS OCX Program Status

    Don Jewell, our intrepid Defense editor, finally stopped traveling long enough to catch up with Robert “Bob” Canty, the Raytheon vice president and program manager for the GPS OCX program. They managed to find time for a very interesting and uplifting conversation concerning the history, current status, and way ahead for the next-generation GPS operational ground control segment. Uplifting because, incredibly, this critical space program is actually on schedule and on budget. Alert the media and roll the presses!

    DJ (Don Jewell): Bob I really appreciate you taking the time to sit down with GPS World and talk about OCX which is the future GPS Operational Ground Control Segment located at Schriever AFB in Colorado.

    BC (Bob Canty): Don, I am always happy to talk about OCX. The program is doing extremely well and it is a good space story to tell.

    DJ: Great, Bob. Now, historically, exactly how long has the Raytheon OCX team effort been in place? By that I am referring to the fact that Raytheon was required to prepare some amount of operational software for the last demo phase during the OCX competition, before contract award, that would supposedly be used at a later date. Are you making use of that software, and if you count that time during the competition phase, exactly how long have you or your team been working the OCX program?

    BC: Don, what’s interesting is that we (Raytheon) were involved all the way back in the SARD (System Architecture and Requirements Definition) days, the early 2000s. I have personally been involved since the SARD days as well when we were supporting the Spectrum Astro and the Boeing teams. Then, after the SARD phase, the Spectrum Astro team joined the Lockheed Martin team, so then we were supporting Lockheed Martin (LMCO) and Boeing in that phase. When the space and control segment competitions were separated we had a PRDA (Program Research and Development Announcement) team, and consequently our team has been together since 2005. So our team has been around GPS a long time…when we came into the last phase, which was Phase A, of the program our team had a very mature design and a very mature approach. The Raytheon team was integrated and had many of the process steps behind us when we came into Phase A.

    Essentially, we designed in Phase A the ability to be able to reuse that software in Phase B, so 97 percent of the software we developed in Phase A is being reused now in Phase B. Now, because of our reuse heritage, we have reuse from many different programs. We were able to incorporate that experience into Phase A and deliver a significant amount of code. Just from a DSLOC (Delivered Source Lines of Code) standpoint, on the order of 40 percent of the Block 1 code is completed and integrated together. When you look at equivalent source lines of code, or how much effort it took us to put that DSLOC together, it was about 75,000 lines of code. So when I take a look at all the code that AEP/LADO (Architecture Evolution Plan [current GPS ground control system]) has as delivered source lines of code, our final program will have less than half the lines of code than are currently in operations with the AEP/LADO program.

    Now to get back to your original question about Raytheon’s longevity with the OCX program. In November 2007, Raytheon won a $160 million Phase A System Design and Risk Reduction contract. In February 2010, just 12 months ago, Raytheon was awarded a 73-month, $886 million contract for Blocks 1 and 2 of the GPS Advanced Control Segment (OCX). Raytheon has been working the next-generation GPS control system for more than 10 years. Now the Raytheon team, as such, has been in place since the PDRA phase so we have worked together for over five years. By establishing our technical approach and processes prior to Phase A, we were able to move very quickly into maturing our system design. This allowed us to develop software that is reusable in Phase B.

    DJ: That’s great Bob, but why the smaller overall amount of code? Are you just utilizing a more modern and efficient software development language?

    BC: Right, Don, it has to do with the overall efficiency of the code and the way it is architected and designed. There are many things we are doing with this particular code. Specifically we build functionality once and use it in many places in the architecture. By understanding the complete construct of what we have to deliver, we can get a tremendous amount of efficiency by the way we architect the overall SW and reuse pieces. We build once and deploy in several different places.

    DJ: That sounds like very efficient code, Bob. What exactly is the primary software development language the Raytheon team is using?

    BC: It is primarily C++ and Java.

    DJ: So that must make it easier to follow sequences and find errors and problems in the code.

    BC: It does, and from an integration standpoint, the overall modularity approach of a Service Oriented Architecture (SOA), facilitates integration. An SOA done right, and they aren’t all designed correctly, partitions code into much smaller modules with standard interfaces that makes it easier to integrate and test. Plus, in older architectures, you had to integrate all the code together before you could find problems among modules. In today’s OCX architecture you can really isolate problems down to different layers in the architecture, which also makes it much simpler to integrate and test.

    DJ: It certainly sounds like OCX software will be easier to maintain. And I think you mentioned to me before that there will be no reuse of the AEP software in the OCX code.

    BC: Right. We have no AEP code in our architecture at all. We are, however, reusing some parts of the LADO (Launch and Early Orbit, Anomaly Resolution, and Disposal Operations) software. Some of the software code that Braxton has, especially for modeling and simulation — and I will talk more about that in a minute — is being validated in our modeling and simulation framework. We are bringing all that reuse of Braxton software into our overall offering.

    Essentially, Don, the entire OCX architecture was designed to easily evolve to accommodate new functionally, automation and changes in the mission CONOPS (Concept of Operations). It is also a very efficient design. Our design will use less than half the lines of code as AEP/LADO with twice the capability. As I said, we purposely did not reuse any AEP software. We have taken advantage of Braxton’s validated LADO IIR, IIR-M, and IIF models. Raytheon is also taking advantage of our Eclipse Command and Control and Equinox Mission Management product suites. ITT reuses designs from its GPS IIR, GPS IIR-M, and GPS IIIA , and Raytheon’s NCS (Network Centric Systems) brings reuse from the FAA’s (Federal Aviation Administration) Wide-Area Augmentation System better known as WAAS.

    DJ: I guess that makes sense, and it’s obviously more economical for cost and schedule to automate and reuse software where you can. And since you mentioned LADO, many of the 2SOPS (2nd Space Operations Squadron) operators tell me that they prefer to use the Braxton LADO system and software because so much of it is automated. It does away with human interpretation and is less prone to fat fingering errors, especially during times of high-operations tempo on the operations floor at Schriever AFB.

    BC: Absolutely. In our system going forward, we are bringing more automation into play. As you start bringing in NAVWAR (Navigation Warfare) in Block II, the overall goal is to have the same or a fewer number of operators than are on the GPS operatio
    ns floor today. We are essentially doubling the operational capacity with the same or a fewer number of people. We are introducing much more automation into OCX program, more even than the Braxton LADO program has today.

    DJ: We’ve talked a lot about software and procedures, but is the OCX program also about hardware?

     

    BC: You’re right, Don. Although the GPS OCX contract is primarily a software development effort, there is a significant amount of hardware. Approximately 20 percent of the effort is hardware. In addition to the computer equipment that will support operations at the primary and alternate Master Control Stations (AMCS), we will be installing new GPS receivers in 17 globally distributed monitoring stations to monitor all GPS signals, and upgrading the ground antennas at all four legacy ground antenna (GA) locations. Most of it is COTS (commercial off the shelf) hardware, the only exception being the receivers that we put in the monitoring stations. They are custom built receivers in order to get the performance we are looking for. Since we are incorporating the M-Code (military-only code) capability into the receivers, we are required to go through an intensive information assurance (IA) accreditation process. So that is really the only custom piece of hardware out there as far as OCX is concerned.

    DJ: Does that mean that you are going to have to certify all new hardware to prove that it will operate with OCX?

    BC: Actually, no, there are only two segments of the hardware program that are going to have to be certified, and that is the GPS monitors/receivers and the key management system.

    DJ: Key management… Does that mean that you are currently working the SAASM (Selective Availability Anti-Spoofing Module) OTAR (over the air re-keying) and OTAD (over-the-air delivery) piece of the GPS control system as well within the OCX program?

    BC: Correct.

    DJ: And now the question that everyone wants answered; is the OCX program still on schedule? Will it be delivered on time?

    BC: We are on schedule and on cost. Since contract award in February 2010, we have successfully completed our Technical Baseline Review, Integrated Baseline Review, Software Specification Review, and Hardware Preliminary Design Review. We are on track for a successful system PDR in the second quarter of calendar year 2011 (2Q11). We just completed software iteration version 1.2 integration and test. We have started software iteration version 1.3 design activities so we are right on schedule. As I mentioned before, since we had a lot of code reuse coming out of Phase A, we were able to incorporate 97% of it into our iteration version 1.2 of the software baseline. We will progress all the way to version 1.7 in our software iterations for Block 1, so essentially we are currently a little less than a third of the way through our software development activity. We completed iteration 1.2 right on the day it was scheduled in our original operational baseline schedule. Starting this week we are beginning our iterative software design for iteration version 1.3 and that is scheduled to complete in the fall of 2011. So, yes, right now on the software development side we are right on schedule.

    DJ: Bob, anyone familiar with the OCX and GPS IIIA programs has heard about a supposed gap or lack of synchronization between the two programs. Is there still a gap between the OCX FOC (full operational capability) date and the proposed launch date for the first GPS IIIA satellite? If so, how large is that gap and is it getting bigger or smaller?

    BC: Don, the first GPS IIIA satellite is currently scheduled to launch in May 2014, and the OCX Block 1.0 Ready To Operate (RTO) date is August 2015. Over the past six months, we have worked closely with the GPS Directorate and GPS IIIA contractor Lockheed Martin (LMCO) to align our schedules and ensure OCX is ready to support the first IIIA launch. This has required the introduction of a streamlined Launch and Checkout System (LCS) designed to:

    • Reduce schedule risk for OCX Block 1.0 RTO through early completion of GPS IIIA integration, test, exercises, and rehearsals.
    • Provide earliest GPS IIIA-1 operational availability.
    • Provide opportunity for discovery of potential IIIA-1 design issues.

    LCS will provide Block 1.0 Initial Checkout Capability in April 2013, On-Orbit Checkout Capability (spacecraft only) in March 2014, and Full Checkout Capability (spacecraft and navigation payload) in March 2015 (in time for the scheduled IIIA-2 launch). With LCS we have essentially closed the gap between GPS IIIA launch and OCX Block 1.0 delivery.

    DJ: Great. You have theoretically closed the gap as long as LCS comes to fruition. Barring that, if required, could LADO launch the first GPS IIIA satellite?

    BC: The LADO system does not currently support the IIIA vehicle and, ultimately, it is not about launching GPS IIIA as much as it is about bringing it into operations. OCX is the only system that can bring GPS IIIA into operations. Raytheon feels the current LCS approach significantly reduces the operational risk to GPS IIIA.

    DJ: Now, Bob, as we mentioned earlier Raytheon has put together a team. You are not doing this alone, so please remind us of who your initial teammates were and are they all still on board? Have any new teammates been added and what does each teammate specialize in as far as OCX support is concerned?

    BC: Actually, we maintain the same team today with which we started the OCX contract. Raytheon‘s teammates include Boeing, ITT Corporation, Braxton Technologies, Infinity Systems Engineering, and the Jet Propulsion Laboratory. Details on each partner and its role in the GPS OCX program are as follows:

    DJ: Is the Raytheon team going to design a new Kalman filter for OCX? [Editor: for those who aren’t aware, a Kalman filter is not a hardware device but rather a set of sophisticated processing algorithms.] And if so, how do you envision the transition process progressing? Is this an area of special concern? And would Raytheon build the Kalman filter or would it be one of your teammates? If so, which one and why?

     

    BC:I think you just asked me six rapid-fire questions about the Kalman filter.Yes, we are designing new Kalman filter algorithms for OCX. Our Jet Propulsion Laboratory (JPL) teammate, with extensive experience in this area, is responsible for developing the Kalman filter algorithms and ITT Space Systems is integrating the algorithms into the OCX navigation solution. Based on past experience, we are developing a very robust and flexible transition plan in which the Kalman filter can be operated in parallel and switched in and out even after long periods of operations. We believe this will facilitate a smooth transition from the current GPS AEP OCS to OCX.


    DJ    : Bob, if you don’t mind, I would like to go back to the gap issue for just a moment, just to make sure there are no misunderstandings. According to LMCO, the GPS IIIA program is continuing to move to the left, so much so that the first IIIA launch might take place before the last IIF launch. Will this cause OCX any special problems?

    BC: Don, as stated before, the first GPS IIIA launch is scheduled for May 2
    014 and we do not anticipate any schedule problems.

    DJ: That’s great. Not to beat a dead horse, but that is a question we get a lot at GPS World, and I just wanted to make sure we had it covered. Now to move on, have there been any major surprises in the program so far, good or bad?

    BC: I have been very pleased with the collaboration efforts among the GP (GPS Directorate), SE&I (Systems Engineering and Integration), GPS IIIA, and OCX contractors. The cooperation, data sharing, and teaming are outstanding. Bringing in a diversity of views and solutions is really enhancing the program.

    DJ: Bob, is there a particular aspect of the OCX program of which you as the PM (program manager) are particularly proud?

    BC: There is. As identified earlier, we are proud to be on schedule and on cost. We have an outstanding team that is executing to meet the customer’s needs. The strong relationship we have built with our teammates, with Lockheed Martin, the GPS IIIA contractor, and our SMC customer has been vital to the success of the program to date. In addition, we believe the ability to design a solution that leverages significant software reuse has proven invaluable to reducing cost, schedule, and technical risk on the program.

    DJ: Sounds like the A-Team motto, “I love it when a plan comes together.” But what about the future, the way ahead for OCX? Is the government continuing to add requirements as you go along?

    As you know many PMs have seen their well-planned programs fail because of continuous government change requests.

    BC: Actually, Don, the requirements have been very stable on Block 1 and 2 for OCX. As for the future of OCX, the net-centric features that will be enabled by OCX will revolutionize future GPS services. We anticipate new capabilities such as:

    • Net-centric GPS user equipment will enable delivery of future GPS OCX net-centric services (e.g., situational awareness, augmentation, differential GPS) directly to end-users.
    • Net-centric user equipment and the future ISR (intelligence, surveillance, reconnaissance) sensor “cloud” will close the loop for GPS forward monitoring for assured delivery of PNT services and for identifying, locating and reporting sources of interference.
    • Collaborative, effects-based decision support tools and ad hoc planning coupled with an integrated space/ground network will tighten the NAVWAR and integrity timeline.
    • Combined planning of space, air, and ground-based L-band augmentation assets for assured PNT (position, navigation and timing).
    • Secure, cross-domain collaboration and GPS mission situational awareness will provide efficient user help-desk services and automation for constellation management.
    • Standards-based developer’s toolkits will speed delivery of new capabilities to users and ensure future interoperability.

    DJ: OK, Bob, OCX may be flashy, new, on schedule and on budget as well as being projected to be more efficient. But as the PM what do you consider to be the most impressive or critical new capabilities that OCX brings to the GPS control system and to the warfighters?

    BC: GPS OCX consolidates all ground system operations into a single, flexible, service-oriented architecture (SOA) solution that meets the needs of both legacy and future satellites. GPS OCX offers the capability to optimize across all elements of the space segment and provides net-centric interfaces and services to improve civil and commercial capabilities and enhance warfighter effectiveness well into the future.

    GPS OCX will act as a service bridge between space and user segments, enabling a more innovative, user-centric system including:
    Improved availability of signals from space

    • Increased accuracy of data
    • Flexible modern software that is easier to maintain and modernize
    • Timely clock and calendar updates
    • Enhanced anti-jam and interference performance
    • Increased capacity for satellite support
    • Increased Situational Awareness for GPS operators
    • Syncs with current satellites and future satellites
    • Performance continuity with existing GPS devices.

    GPS OCX will revolutionize command and control (C2) and mission capabilities for U.S. armed forces and our allies, transforming the focus of GPS operations from satellite C2, to user-oriented, effects-based operations. The program will increase operational efficiency by supporting network-centric capabilities, navigation warfare, and effects-based operations (EBO), while providing the war fighter secure, actionable and predictive information to enhance situational awareness, real-time decision-making, and responsiveness.

    DJ: Bob, what can you tell us about the new Raytheon GPS collaboration facility that is scheduled to open sometime this month in El Segundo, California? What part will that facility and its capabilities play, if any, in the OCX process going forward?

    BC: Don, bringing new GPS capability on-line is directly related to when the control segment (OCX) can transition the capability to everyday operations. We recognize that close collaboration is necessary for enterprise success. The GPS Collaboration Center will be used for OCX development and deployment in addition to demonstrating future GPS capabilities from across the Raytheon Corporation and the OCX team.

    DJ: Well Bob I’m certainly impressed and I want to thank you once again for your time today. This is an impressive story. There aren’t many space programs today that are on their cost and schedule budget or anywhere near it for that matter. That in itself is an amazing achievement. Any closing comments or important questions we forgot?

    BC: Don, I appreciate the opportunity to talk about the OCX program and in closing I want to say that GPS OCX, the next-generation operational gateway service, is designed to provide secure, accurate, and reliable navigation and timing information to effectively support military, commercial, and civil users. GPS OCX will act as the service integrator for ground, space, and user segments to enhance mission command and control, and situational awareness capabilities, while seamlessly supporting millions of users around the world.

    Raytheon IIS brings more than four decades of high-availability, precision-based, and command and control systems experience to GPS OCX. In addition, Raytheon IIS understands the need to move from a platform-centric to a user-centric system, and is able to deliver capability upgrades in an asynchronous environment and support the government’s desire to operate as a systems integrator. As the prime contractor for the GPS OCX program, Raytheon will continue to ensure that the solution is delivered on time, and on budget.

  • Smartphones Take on PCs: Significant Historical Moment

    It is a significant first, an iconic moment, a big deal. You will want to remember where you were when you heard that smartphones started to outsell personal computers. According to a report by market research company IDC, consumer electronics makers shipped 100.9 million smartphones worldwide in the last three months of 2010, an 87 percent jump from a year earlier. PC shipments didn’t do as well, edging up just three percent to 92.1 million. The falling prices of smartphones have contributed to this trend. The numbers are skewed by the longer life of a computer compared to a smartphone, which frequently is replaced within two years. For many of us, one doesn’t supplant the need for the other.

    Are car companies and content providers allowed to wed? At the Navigation Strategies, USA, conference, it was a striking new world with the automotive industry anxious to engage with application providers. Some of the interesting tweetable snippets from leading automotive and content providers:

    • “There is a three year development cycle with automotive. But now you can integrate an app into a vehicle in four weeks.”
    • “Maps used to an end onto itself, but now it is a way to organize information.”
    • “People will pay for connectivity in the vehicle, but may only be willing to pay during the time when it is needed.”
    • “People will pay for traffic, but you need to educate them on what it has done for them. This month you saved x money in gas, this amount of time navigating around traffic.”
    • “No one needs a map for their commute. They need their alarm clock to wake them early when their commute route is congested.”
    • “Content providers can only avoid the ‘free monster’ with value added services.”
    • “Navigation is now about smartphones and how to integrate with the car.”

    Augment my reality. I’m not the only one charmed by Wikitude (no, not WikiLeaks) from Austrian-based Mobilizy. I took a walk around a hotel parking lot with Wikitude’s Philipp Breuss-Schneeweis imagining the possibilities of Wikitude Drive, augmented-reality navigation for vehicles or pedestrians. Intended as a heads-up display, it is currently shown as a smartphone mounted on a dashboard that displays the scene ahead of you, exactly as you see it with your eyes. However, the navigation route is drawn on top of the real scene. There is an option, particularly important at night, to switch out of augmented reality to see the route as a street map. Wikitude Drive was the grand prize winner of the 2010 NAVTEQ Global LBS Challenge. World Browser, another product by Wikitude, identifies objects around you. Point your phone and it will (try to) identify your surroundings, such as landmarks, mountains, or buildings.

    Location-based social networks. I recently hosted a webinar on location-based social networks (LBSN). It is a hot topic: I had registrants from 42 countries. LBSNs are mobile apps based on developing a social community that broadcasts a user’s location and other content. LBSNs have an element of gaming that fuels and rewards usage, helps people find their friends or make new friends that share the same interest and proximity, and often provide offers and coupons from brands. A hallmark of many of these applications are check-ins, which is a manual or automated process of letting one’s community know one’s location: “I’m at Frankie’s Pizza.” There are too many LBSNs to list, but they include Booyah!, Whrrl, foursquare, Gowalla, SCVNGR. If you are interested, the webinar is available for download.

    My webinar guests were Brian Cho of Booyah!, maker of MyTown, and Chad Reed of Pelago, maker of Whrrl. MyTown is an LBSN game that proves the concept with 3.7 million users. Sessions average 55 minutes a day and at its peak had 1.1 million daily sessions. Advertisers drop items into the game that may depend on the player’s location and sometimes a clue cannot be unlocked without a visit to a retail location. MyTown drove more than 800,000 visits to H&M, a clothing retailer.

    Wirrl focuses on building affinity societies, and currently has 5,000 special interest societies, such as mountain biking, the Red Bull Society, and Mexican food lovers. Society members make recommendations to other members of their affinity group and a sophisticated algorithm builds up individual preferences. Whrrl’s revenue comes from brands that offer contests and prizes that match society members’ interests and locations. Reed says they use contests, instead of coupons or offers, to allow brands to control costs and add excitement.

    Making money. I’m often asked for advice from content providers on making money when consumers are increasingly expecting applications to be free, and some applications, such as navigation or mapping, are getting dangerously close to becoming a utility. One strategy is to add value in a way that is challenging for other companies to cookie cut. An example is Navx, a company based in Paris that provides fuel prices for up to 100,000 gas stations with hourly updates. Consolidating the data isn’t a fully automated process so it is unlikely that companies like Google, or the like, will want to get their hands dirty. Navx also identifies parking spaces, speed traps, and charging stations for electric vehicles.

    Probe sharing. Adding live connectivity to enable traffic and other services is critical for personal navigation device (PND) providers that are competing for market with smartphones. The recently announced TomTom GO 2505 is stepping up with improved traffic (updated every two minutes) from probe and traditional sources, as well as local search, fuel prices, and weather. TomTom is anxious to get its users hooked and is providing a 12-month trial subscription out of the box. Part of the traffic data set is provided by its own users, and Tom Murray of TomTom reports that more than 90 percent of its customers opt-in to contribute the data.

    The World Mobile Conference is under way. It’s looking like it is all about smartphones and tablets. More later.

  • Galileo Test Environment Open for Business

     

    The Galileo Test and Development Environment (GATE) in Berchtesgaden, Germany, officially opened on February 4. The system operator, IFEN GmbH of Poing, Germany, jointly with the German Federal Minister of Transport, Building and Urban Development, announced the opening for use by commercial and organizational entities seeking to test equipment with the coming Galileo signals. GATE was developed on behalf of the German Aerospace Center (DLR) with funding by the German Federal Ministry of Economics and Technology.

    The test area extends across a valley of approximately 65 square kilometers, south-east of Munich, where antennae atop surrounding peaks broadcast the various Galileo signals. Technical details and specifications of the test environment are at www.gate-testbed.com.

    GATE has completed its signal upgrade phase according to the latest version of the European Space Agency’s Galileo Signal-In-Space (SIS) Interface Control Document (ICD) and the European GNSS Agency’s Public Galileo Open Service (OS) ICD. The GATE infrastructure is capable of transmitting the Galileo OS, the Galileo Safety-of-Life (SoL) Service (functional), the Galileo Commercial Service (CS), and a Galileo Public Regulated Service (PRS) dummy signal.

    The GATE system upgrade has been further extended to also support user integrity testing. GATE can simulating simple alarm-triggering events on the system/satellite level, supporting GPS and GATE/Galileo dual-constellation receiver-autonomous integrity monitoring (RAIM), individual user integrity test scenarios, and tests of receivers with different RAIM functionalities.

    The next step will be certification of the GATE test infrastructure as an officially accredited open-air test infrastructure to perform the necessary tests needed for the process to certify Galileo SoL equipment.

    Günter Heinrichs, head of customer applications and business development for IfEN GmbH, described the goals and capabilities of GATE in a 2007 GPS World article. He gave an update on developments in a 2009 video interview. A recent simulation of emergency response scenarios using the Galileo signal is described at Galileo to the Rescue.

  • u-blox, Rohde & Schwarz Successfully Simulate Galileo with u-blox Platform

    u-blox and Rohde & Schwarz (R&S), a supplier of test and measurement equipment, have successfully concluded a simulation of the European Galileo satellite positioning system. The test, carried out with the R&S SMBV100A vector signal generator and its GNSS simulation options, verified the u-blox proof-of-concept and the compatibility of u-blox receiver technology with the Galileo transmission protocol.

    The cooperation with R&S is also being extended to the Russian GLONASS satellite system, which is targeted to be fully operational with 24 satellites in 2012.

    “Our close cooperation with R&S has proven to be a valuable and strategic asset, allowing us to develop advanced satellite receiver technology well before the actual satellites are available” said Clemens Bürgi, vice president of software development at u-blox.

    “u-blox, with its depth of expertise in GNSS technologies, has helped us to validate our satellite simulator technology,” said Andreas Pauly, head of R&D Signal Generators Baseband at Rohde & Schwarz. “Now we have developed cutting-edge test equipment that simulates the protocol and physical layer.”

  • Confessions of a Public GIS Manager: Does IT Outsourcing Really Save Money?

    In following up on my example of a simple GIS app for entering and displaying lat/lon coordinates from a spreadsheet (or text file), the discussion went from cloud to client and then back to cloud. The reason may surprise you. Recall that I was looking for the best solution for a reader who was looking for a simple GIS app to display gobs lat/lon coordinates.

    My first inclination was to use an online app (cloud) such as arcgis.com or Google Earth in order to stay away from the users needing to install and maintain software on their local desktop computers. No go. The functionality just wasn’t there. All along, my backup plan was to use a client app like ArcGIS Explorer. Well, after messing around a little and consulting with an online discussion group, that’s the route I went. I wrote about it last week.

    Subsequently, a GIS manager from a public department (state level), wrote about his experience with client-based apps and his challenges with IT outsourcing. It really make one reconsider the cost effectiveness and efficiency of IT outsourcing. His perspective makes interesting reading:

     

    We didn’t go the ArcGIS Explorer route primarily because of the current war (GIS vs. IT) which scientific computing is losing badly at this point in time. Our State and many others are neck deep in smelly muck created by business computing’s IT consolidation and outsourcing.  I just got back from a meeting where I heard another round of horror stories from VA.

    For more than five years, our WAN-based users at regional offices throughout the state have ran GIS via Citrix with customized ArcGIS desktop apps written entirely in-house by our staff in VB and .Net.  We elected that strategy because at that time it was really the only serious option to allow access to the large amounts of data we had in our geospatial archive here at our headquarters. It was also attractive because back then we controlled our infrastructure and our LAN and were highly influential in WAN decisions because we had a very advanced computing environment here.

    Then came IT consolidation and the predictable downgrading of advanced Agency’s capacity so we’d be able to open really big word processing documents on our desktops. By that, I mean scientific computing like GIS, Remote Sensing, etc. apps were not considered seriously in that process even though we need to operate much closer to DoD or NGA-like computing capacity compared to the average accountant. After multiple attempts to modernize our Citrix and SAN, resources were turned down and we decided we’d better switch to a new approach.

    Because we’re charged serious bucks every time we put in a service call to have ArcGIS Explorer installed on an existing or new PC, we elected to go as thin client as possible. Everyone has a browser and we don’t have to pay to have that installed.  We initially developed some betas using ESRI’s JavaScript solution but browser differences (both different versions of the same browser and Microsoft vs. Firefox on individual PCs just inside our unit) caused many applications development problems so we abandoned development with that API.

    That’s when we elected to do a very serious Flex vs. SilverLight comparison and the rest is history. The new beta has a rainfall widget we’re particularly proud of. It grew out of our active mining program staff having to respond to horrific flash flooding typical in spring and summer in our state. This new app will allow staff to go to the permitted sites to check stability of sediment control structures where the most rainfall (… based on Nexrad) was projected to have fallen for the first time this spring.

    In April this year we’ll find out if our jobs are going to be outsourced or whether our state will modernize internally. The refusal to allow Citrix and SAN improvements is a harbinger of the way that will go I believe. We have been presented with 4 SAGs in the last decade. I wonder what the total count will after the first decade of outsourcing?

    Many potential problems exist for geospatial programs because of IT consolidation and the more recent potential of outsourcing GIS. IT consol first. My unit does a great many very large (… and long) computing jobs. We routiinely move data from one projection or datum to another. When you deal with thousands of raster tiles, a reprojection project can take weeks to accomplish successfully. We also do spatial analysis projects that take even longer. We recently used Landsat scenes and higher resolution commercial satellite data plus aerials from multiple dates to do change analysis. That job took more than a month on beastly PCs we’ve built up specifically for these very tough jobs.

    [[Our]] ICI is an old DoD concept I pulled back into use. We built these platforms after about a year of total frustration having our big jobs crashed from IT pushes of OS upgrades happening in the middle of producing badly needed new deliverables, network disconnects dropping out our license checkout connectivity to a remote license manager on the WAN, etc. I’ve already mentioned the failure to consider geospatial in upgrading infrastructure and improving bandwidth.

    Even keeping your servers local can be a big battle in the war.  We have an older county size LiDAR dataset (pre-.las) processed and delivered as a point cloud. We have new LiDAR from the same county and we’re trying to do a comparison of the two datasets. Depending on what USGS quadrangles are selected it typically takes 30 to 40 minutes to load up four 1:24K quad size tiles of the older point cloud data via our LAN at fast Ethernet speed. Move that to a WAN situation and we need to start it loading in the evening so it’s ready by the following morning (but that won’t work because of the auto-shutdown software on all the desktops that executes every evening a 7PM). And then there’s the joke about the virus checking software pushed out to every desktop, configured all the same for everybody and auto executed and the twenty-one staff that mapped over five terrabytes of GIS datasets on the SAN and their very fast new computers (sarcasm) being brought to the approximate speed of molasses running up hill because the virus checking code never stopped trying to check all five TBs on each of the twenty-one PCs.  It wasn’t much of a joke when the whole Agency’s networking speed dropped to a crawl! Need I say more about one-size-fits-all IT mentality shooting off their own feet!

    Negative aspects of outsourcing geospatial jobs are obvious. No contractor is going to know the individual program requirements like in-house staff and that’s a challenge even for us. Good example … the rainfall widget on the new beta app I pointed you to wasn’t requested by our mining folks until we approached them with the idea that we might be able to do something like that. Would there have been that kind of insights by a big corporate consulting firm like IBM or HP? I think not.

    On the good side of IT consolidation, if geospatial folks are pulled together into a core group I think that gives folks the chance to work on a broader spectrum of tasks not limited by the bounds of what one state government Agency desires, but rather the state as a whole. That could be a good thing. Also, it gives Agencies with a GIS effort, consisting of one or two folks, access to experts they’d not be able to otherwise tap into (GIS DBAs, geospatial applications development gurus, etc.) and that definitely would be a very good thing. Of course that hasn’t happened here. On the good side, with outsourcing GIS jobs, I’m clueless as to how that could ever benefit anyone except the recipient of the contract. The horrible stories from colleagues give me night terrors.  PC refresh cycles of 5 years, horrendously expensive SAN storage rates, etc. You name it, &
    nbsp;the customer is hosed by it.

    There really is a business vs. scientific computing all-out war going on all around us and as I said initially, too many scientific computing types have their heads down doing the exciting stuff while the fight rages on, without them even knowing about it. If you can wake them up to the reality that business computing “experts” may very well be building a scientific computingless future in which they’ll have no place (or job), it would be greatly appreciated.

     

    I’ll be writing more about this. It’s a serious issue and it’s not going away, especially with the geospatial industry continuing to put up strong growth numbers.

     

    Thanks, and see you next week.

    Follow me on Twitter at http://twitter.com/GPSGIS_Eric