An increasing issue for the NAT Oceanic FIR’s is how to handle aircraft with an in-flight degradation of GPS. This normally follows a GPS Spoofing encounter somewhere prior to Oceanic Entry, leading to a degraded RNP capability.
If you run into GPS issues before entering the Ocean, you will likely end up with RNP10 as the best you can manage for navigational accuracy. This presents some issues for the Oceanic controllers, as RNP4 is commonly used to ensure separation. We’ll take a look at some scenarios and how to best handle these.
Normal RNP requirements on the NAT
NAT Doc 007 specificies two RNP options for entry into the NAT HLA.
The first is RNP10 (accuracy of 10 nm, 95% of the time). An important consideration here is that RNP10 is really RNAV10, but they call it RNP10 to keep things simple [See NAT Doc 007, 1.3.4]. The critical difference is that for RNAV10, on-board monitoring is not required. Since this can only be done by GPS, that’s an important relief when it comes to spoofed flights.
The other is RNP4 (accuracy of 4nm, 95% of the time). RNP4 is only an absolute requirement for PBCS Tracks (“Half-Tracks”). In practice, ATC commonly uses RNP4 for separation purposes on the NAT (Since the introduction of ASEPS). GPS is required for the monitoring part of RNP4; without GPS, RNP4 is not possible.
Loss of GPS Prior to the NAT
Since GPS Spoofing became prevalent in September of 2023, increasing numbers of aircraft are arriving at the Oceanic Boundary with one or both GPS sensors inoperative. A textbook GPS Spoofing encounter will initially see the GPS sensors rapidly change from the real coordinates to fake coordinates. If all GPS sensors agree on the fake coordinates, the FMS becomes confused. IRU values will increase, and in some cases, the IRS may also become “infected”.
The primary spoofing locations have not changed much since the onset of the issue: you will encounter spoofing at the Iraq/Iran border, the Sinai peninsula area (showing Tel Aviv as the spoofed location), Israel and Cyprus (showing Beirut as the spoofed location), and the Black Sea (showing Sevastopol as the spoofed location).
We have no reports in OPSGROUP that the other type of GPS interference – GPS Jamming – leads to lasting effects. Once the jamming has stopped, aircraft systems are normal.
However, we do have reports that if GPS inputs are turned off before departure, and later turned back on in flight, that issues may occur. This is mostly reported for departures from Tel Aviv (LLBG).
GPS failure, Ocean approaching
Since RNP4 requires a functioning GPS, if you encounter spoofing and lose your GPS, you can’t fly RNP4. Assuming that you have an RNP10 approval (one of the only two options for the NAT HLA), you will become RNP10.
The problem occurs when Shanwick, or the OACC at the entry point, get late notice of this fact, and you are close to other aircraft. That leaves the Planning Controller with little time to figure out how to separate you (an RNP10 aircraft) from the others (RNP4 aircraft).
In some cases, “spoofed” aircraft have had to descend to FL280 to exit the NAT HLA, and this has caused diversions.
How to best handle a NAT crossing with a failed GPS
The key is to advise Shanwick, or the first OACC, early. Shanwick’s preference is that you use the RCL request to do this, and add a note to the end of the RCL along the lines of ATC REMARK/GPS DEGRADED RNP10 ONLY. If using voice to get your clearance, that’s what to say as well. Shanwick NOTAM EGGX G0106/24, and a note on the OTS Track message, has this information.
The RCL for Shanwick should ideally be sent 90 minutes before the Oceanic Entry in this case. Normal RCL timeframes are -30 to -90. An RCL sent any earlier will be rejected, but if you have something more unusual to discuss, you could use SATCOM to contact the supervisor and ensure a smooth crossing.
RNP10 time limit
With the change to RNP10 for your crossing, double check the time limit for RNP10. ICAO Doc 9613 (Volume II, Part B, Chapter 1) specifies that RNP is limited to 6.2 hours of flying. The timing starts from when “the systems are placed in navigation mode” or at the last point at which the “systems are updated”. The logic here is that the IRS will drift without updates enroute, and after 6.2 hours of flying, will no longer be capable of maintaining the RNP10 accuracy.
For an aircraft spoofed in the Mediterranean, or Black Sea area, it will take 4 hours before Oceanic entry, so this time limit becomes relevant. If the impact of the spoofing is severe enough, there is potential for inputs – including DME/DME or VOR/DME – to the IRS to stop working. This is one of the potential unknowns at present.
Shanwick comments
Shanwick are encountering several GPS jammed aircraft per day, and it is sometimes difficult (or impossible) to find optimum profiles for aircraft without moving several other aircraft to accommodate. The only instance where they have to insist on FL280 and below, is when an aircraft does not meet the requirements for MNPS (such as single LRNS), and needs to be cleared outside HLA.
If a pilot advises that they have lost RNP4, but are still capable of RNP10, Shanwick controllers will look to find a solution where the aircraft can be cleared with at least 10 minutes longitudinal and 60nm lateral separation. These aircraft also need coordinating with the next Oceanic Center before clearance, and sometimes there are limited options available.
In general, the earlier they informed about the degradation, the easier it is for the Shanwick controllers to find satisfactory solutions.
Member input
This is a developing issue and we gratefully welcome any input from members on this. Email us at team@ops.group.
More on the topic:
- More: 2025 North Atlantic Plotting & Planning Chart
- More: Greenland NAT Alternates – Major Changes Coming
- More: NAT Ops: Flying the Blue Spruce Routes
- More: NAT Guide 2025 – My First NAT Flight is Tomorrow
- More: NAT Circle of Entry (2025)
More reading:
- Latest: Dodging Danger: The Three Routes Through the Middle East
- Latest: US Pre-Clearance: How does it work?
- Latest: 2025 North Atlantic Plotting & Planning Chart
- Safe Airspace: Risk Database
- Weekly Ops Bulletin: Subscribe
- Membership plans: Why join OPSGROUP?
Get the famous weekly 
Calling RNAV10 RNP10 doesn’t simplify things. Quite the opposite as it implies you are non-compliant if your ANP exceeds 10. This was the case for us recently on PACOTS. Momentary GPS interference on departure disabled GPS R and left the GPS L with an ANP stuck on 16 thus defaulting position updating of the inertial to DME/DME even though the GPS L position was perfectly accurate. We lost the DME updating in oceanic airspace but the inertial position hardly drifted during the rest of the flight although the ANP progressively ticked up to about 14. Ironically we could use the GPS L position (verified by other GPS sources) to update the inertial manually to satisfy the 6.2 hour rule even though it worsened the ANP to 16.
We reported unable RNP10 and were cleared to continue on the UPR but in hindsight I believe we were compliant with RNAV10 anyway as it’s not based on internal monitoring.
Flying is getting far too complicated 🤣
The guidance for RNP 10 time limits is found in AC 20-138D:
Inertial systems approved in accordance with part 121 appendix G meet RNP 10 performance criteria for up to 6.2 hours of flight time. This time starts when the flight crew places the INS/IRU system in the inertial navigation mode.
(a) If the flight crew updates the INS/IRU systems en route (through manual or automatic means), the flight crew must adjust the 6.2 hour RNP 10 time limit to account for the update’s accuracy. The flight crew must base any adjustments to the time limit on the demonstrated capability of the updates stated in the aircraft’s airworthiness approval documentation (i.e. the AFMS(S)).
Boeing airplanes have a statement in their respective RNP Capability document similar to this:
…without GPS, time-limited IRS operations without position update (6.2 hours since IRUs enter the nav mode and 5.9 hours after a DME/DME update).
My interpretation is this allows for a maximum of 12.1 hours if the last DME/DME update occurs at the end of the 6.2 hours.
Great article. RFI might also impact your datalink. We’ve had instances where aircraft were subjected to suspected barrage RFI while flying from TLV. The crew noticed a GPS loss followed by a SATCOM loss, which eventually led to a datalink loss once the aircraft moved beyond the VHF/VDL range. This meant the crew could still send RCL, establish ADS-C, and log into CPDLC using datalink through VDL, but they were unable to maintain the connection further into DLM once outside the VHF range. Our aircraft’s SATCOM uses the Iridium frequency range of 1,616 – 1,626 MHz, slightly outside the L1 band. Surprisingly, not much is being said about SATCOM jamming. Even though communications satellites require more power to jam due to their higher transmission power compared to navigational satellites, they are still susceptible to interference from modern military jamming systems.
On the 6.2 hour limit, that is from the time when the FMS is last updated with a good position. Depending on the hardware and programming, the IRS may be several miles off after takeoff, but the FMS is updating with DME/DME while over land because that is a more accurate sensor in it’s mix. Upon reaching the ocean, it will have established a delta from FMS to IRS and hold that at the oceanic entry. Thus the 6.2 hours starts at gate out, not from takeoff. Check your avionics for the exact mix, but that is often the implementation I have found.
Thanks Tim! Exactly what I was hoping to get clarified. You’re right of course, and I’ve updated the article – it’s not just about GPS updates to the IRS. We have had reports of spoofing events where the IRS updating stopped happening on all counts (including D/D and V/D), so that’s the worst case scenario. Hope to have you take part in the GPS Spoofing Workshop Project in the group next week! Cheers – Mark.
Great info Tim. I have, for the most part, had good alignment on the laser IRS’s before departure. Never experienced any early “drift” on Nav accuracy after departure. But good to note that it could happen to a significant degree as you have said. Thanks for the heads up. 👍