Your behavior appears to be a little unusual. Please verify that you are not a bot.


GLONASS Gone . . . Then Back

April 2, 2014  - By

In an unprecedented total disruption of a fully operational GNSS constellation, all satellites in the Russian GLONASS broadcast corrupt information for 11 hours, from just past midnight until noon Russian time (UTC+4), on April 2 (or 5 p.m. on April 1 to 4 a.m. April 2, U.S. Eastern time). This rendered the system completely unusable to all worldwide GLONASS receivers. Full and correct service has now been restored.

“Bad ephemerides were uploaded to satellites. Those bad ephemerides became active at 1:00 am Moscow time,” reported one knowledgeable source. For every GNSS in orbit, the navigation messages include ephemeris data, used to calculate the position of each satellite in orbit, and information about the time and status of the entire satellite constellation (almanac); this data is processed by user receivers on the ground to compute their precise position.

According to another source, a GLONASS fix could not take effect until each satellite in turn passed back over  control stations in the Northern Hemisphere to be reset, thus taking nearly 12 hours.

During the outage, CEO Neil Vancans of Altus Positioning Systems reported “We are currently experiencing calls from customers all over the world who are experiencing GLONASS ‘outages’ and we have advised customers to switch GLONASS tracking off on our receivers. We don’t have any better information on when normal service is likely to resume from GLONASS satellites. If you do, let me know!”

Such a — possibly human, possibly computer-generated — error could conceivably occur with GPS, Galileo, or BeiDou. “Another reason to have backups,” mused Richard Langley of the University of New Brunswick. “And not just other GNSS.”

A recent plot shows all satellites restored to normal service:

Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.

Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.

 

 

About the Author: Alan Cameron

Alan Cameron is the former editor-at-large of GPS World magazine.

16 Comments on "GLONASS Gone . . . Then Back"

Trackback | Comments RSS Feed

  1. Mike says:

    Now that we’ve seen the “impossible” happen, maybe the USG will get off its collective bum and get cracking on the derailed eLoran deployment. That project was almost completed before it was undone by one of the most spectacular anal-cranial inversions in the history of modern bureacracy. We must have a backup PNT system for GPS and we need it *now*. eLoran was and still is the obvious answer in finite time and dollars. Until that happens, major projects like FAA’s NextGen ATC system are hanging fire.

    Given that problems un-owned are un-solved, who has the token to make eLoran real?

    • Ross says:

      HR4005 (House passed, needs Senate approval) most recent legislation for US Coast Guard appropriations, will stop further destruction of Loran towers (only 8 are left out of 31) until eLoran is confirmed needed for GPS PNT (position, navigation and timing) backup.

  2. beelza says:

    Looks like NSA sent the Russians a message.

  3. John Schubert says:

    I don’t think this is something we can have happen to the magnitude of GLONASS’ issue here. I was a Satellite Operator (SSO) for GPS and later taught 2 SOPS SSOs at the school house (VAFB, CA). When a navigation upload is sent to a GPS bird, the nav upload becomes active as soon as the 3rd page (page being a physical reference to memory allocation) closes. And hence, the Nav Officer (now called the Payload Officer) would have 12 monitoring stations screaming within a very short period of time. Conceivably, you can have 3 SSOs up on birds at the same time, all sending Navs, albeit it’s unlikely. So worst case scenario, 3 out of 26 could fail, and we wouldn’t have to wait to fix it, as all birds have visibility world-wide. So, much smaller outage, much shorter time to resolution.

  4. KSKN says:

    Was the data been encrypted rather than corrupted during this period?
    If so, was it done deliberately or not?
    Is it a war exercise?

  5. Ben says:

    Agree with conclusion “Another reasons to have backups” but don’t understand why followed by “And just not another GNSS”?

    Indeed, the likelihood to have this kind of event for two simultaneous constellations at the same time seems very close to zero.

    I don’t deny that thinking about alternative PNT than GNSS is worthwhile, but there is no evidence in the paper showing why multiconstellation GNSS would not be enough to cope with this kind of event.

    • Ross says:

      I support the comment “not just another GNSS” on the basis that one fatal failure mode that would take down all GNSS would be jamming, and when we have an economical jam-resistant terrestrial PNT backup that experts around the world have agreed and are proceeding with, namely eLoran, the USA would do well to invest in that.

      • John Schubert says:

        There are anti-jam solutions, such as http://www.novatel.com/gajt/how-it-works/

        Block IIF will have nulling antennas which can allow anti-jam increased capabilities. http://www.spaceflightnow.com/atlas/av039/gps2ffactsheet.pdf

        Unfortunately, it’s always going to be a cat and mouse game between jam and anti-jam. The fact each satellite has to spread it’s RF across the entire width and height of the visible (from the satellite) Earth will have inherent hurdles.

        • Ross Norsworthy says:

          No, it does not have to be cat and mouse with jam and antijam, if we use the terrestrial eLoran solution, because this solution does not impose on any other system and it in itself is jam-resistant due to its extremely low frequency and high power.

  6. John Schubert says:

    KSKN:

    They said it was ephemeris that caused the issue. GPS, and I’m assuming GLONASS as well, is transmitting its current position (estimated) in space. Solving for the distance, based on the time delta (time xmit vs your receivers rcv time), you can triangluate your position to two spots: 1 on Earth, and 1 about 22,000 miles in space. Hence, if you throw off the model, then you “corrupt” the navigation solution.

    They said they needed time to update the 12 satellites. This tells me: they didn’t catch it quickly, as we would have with our monitoring stations. It was a software error, not an issue with encryption (your question), and to me the biggest issue, they had to wait to fix it. GPS has ground antennas around the world (Diego Garcia, Ascension islands, Colorado Springs, Kwaj Islands and 1 more I’m forgetting) so we have practically 24/7 vis on all our birds.

    I am fairly certain their birds are like ours where the transport layer is encrypted, and so if they’re uplinking, the crypto is good. You’d have to have good uplink/crypto just to begin the navigation upload. For that reason, it’s very unlikely this has any thing to do with crypto.

  7. David Storm says:

    All of New Zealand and Australia were affected significantly by this from a surveyors perspective, I am.reliant on the VRS ibase for my setout on site, does anyone know of a website where we could be notified of any problems within say the hour, obviously the rover gives a fair indication but not always

  8. John Ingram says:

    I’m not working now, but still, don’t forget how to read a paper map.

  9. William K. says:

    Computer errors certainly do happen, with or without human involvement. Most code is produced by humans and therefore a bit suspect. And how did they survive without any nav aids?
    Yes, e-loaran or else something better is what is needed for a backup. If our system were jammed, not taken down or spoofed, but simply jammed by a more powerful set of transmitters on the same frequencies, we could be in a big hurt, and only by shooting down the jammer could we fix it. Rotten nasty scenario, but it could happen and would not need that sophisticated hardware to do it. So we certainly need a non-gps alternate.