So rather than buying one jammer, the bad guys will just buy several jammers?
Most tunnels where GPS "works" pass a repeated GPS signal through a leaky feeder, the receiver uses doppler to figure out your speed and guestimate distance. I guess because of the point source on the surface the phone must also think the tunnel is a vertical shaft as well.
The new ones create take ephemeris and almanac data and create simulated time signals for the repeaters exact location. This is the same thing that military jammers do near important locations like embassies and bases to ensure that enemy missiles hit somewhere across the road.
Full coverage either (a) already exists for all of these systems, or (b) is planned for all of these systems.
> suggest there are a reasonable range of frequencies in use.
Not really. The frequencies bands reserved for GNSS are between 1164 and 1300 MHz, and 1559 and 1610 MHz:
* https://www.orolia.com/resources/blog/lisa-perdue/2019/gnss-...
However there are specific frequencies that things are focused on. If you actually look at where each service has each of its frequencies, especially visually, they're all quite close together:
* https://www.tallysman.com/gnss-constellations-radio-frequenc...
* https://gssc.esa.int/navipedia/index.php/GNSS_signal
L1/E1/B1 are all stacked on top of each other, with G1 being 25 MHz of to their side; L2 and G2 are on their own; L5/E5A/B2A are all stacked as are G3/E5b/B2; and so are L7/E6 with B3 overlapping a whole bunch.
Also remember that a lot of the signals are at quite a low power, so localized jamming is not that difficult.
None of your suggestions are robust enough for the stated needs, especially when it comes to timing. A reliable source of UTC is needed in a whole bunch of things (e.g., electrical grids), and "sensor-fusion" will not cut it. It will not even cut if for navigation.
The US DOT released a study that what will probably be needed is multiple systems at various frequencies:
> In a long-anticipated report issued last week, the Department of Transportation (DOT) outlined the results of its GPS Backup Technology Demonstration project.[1] As officials had previously projected, it called for a system-of-systems approach using multiple complementary technologies.
* https://rntfnd.org/2021/01/20/dot-report-l-band-uhf-lf-and-f...
> The demonstration indicates that there are suitable, mature and commercially available technologies to backup or complement the timing services provided by GPS. However, the demonstration also indicates that none of the systems can universally backup the positioning and navigations capabilities provided by GPS and its augmentations. The critical infrastructure positioning and navigation requirements are so varied that function, application, and end-user specific positioning and navigation solutions are needed. This necessitates a diverse universe of positioning and navigation technologies.
* PDF: https://www.transportation.gov/sites/dot.gov/files/2021-01/F...
At the very least they probably have to resurrect (e)Loran, or something less in the low- to medium-frequency (<2MHz) range.
Disagree. Your sole suggestion (resurrect (e)Loran) is expensive and unlikely. IMHO we are more likely to add better geolocation query features to cellular networks than build another network of ground stations.
One I forgot to mention is internet-based wifi SSID geolocation lookups... these are generally super accurate and fast.
I said "very least". It may not be the solution, it is probably part of a solution(s). The various options being looked at are listed, with test results, in the DOT document.
And running the Loran-c was not that expensive:
> DHS also reported that terminating the system would save the government $36 million in fiscal 2010 and $190 million during a five-year period, according to its budget.
* https://www.nextgov.com/cio-briefing/2009/03/obama-proposes-...
For the purchase price of two F-35s the Loran-C infrastructure could (have) be run for five years.
(e)Loran is being (has been?) deployed by South Korea because of all sorts jamming around their peninsula, and it's quite robust. Russia never shut down their (Chayka) network. China is expanding their network:
* https://www.gpsworld.com/china-expanding-loran-as-gnss-backu...
> One I forgot to mention is internet-based wifi SSID geolocation lookups
Would Wifi SSIDs will be available to the aircraft flying at 50,000 feet? Which SSIDs are available to folks in their boats in the Florida Keys? Or boats in the shipping lanes in the middle of the Atlantic? Loran-C skywave propagation (especially at night) can give rough positioning at great distances. You wouldn't want to use it for an ILS approach of course.
While IIRC GLONASS, Beidu and Galileo have less than full-planet coverage, https://novatel.com/support/known-solutions/gnss-frequencies... suggest there are a reasonable range of frequencies in use. As I am not a radio guy, in terms of countermeasures, then, would using multiple GNSS systems in places where their constellations are visible frustrate jamming, since standard ICs now support all systems?
In cars and boats, inertial navigation is also common. This is what provides the "you are x% through the tunnel" movement on car navigation screens. In the event that GNSS is lost, just like driving through a tunnel, one would expect operation to continue at a lower resolution / slowly increasing error on many of these systems.
In addition, there are alternate systems for shipping. I believe AIS publishes last known GPS position/heading, which RADAR and depth-sounding can confirm (along with terrain knowledge). By utilizing the shared state of nearby vessels prior to and during an outage, presumably inertial navigation assumption related error could be greatly reduced (as per the DGPS idea that IIRC was common prior to the unmasking of higher resolution GPS signals earlier in its public-use evolution).
Finally, free data sources for celestial navigation systems, terrain-based navigation systems (including bathymetry) and cell sites are available which can provide pretty reasonable estimates as well.
I think it's a safe bet that, even more so than at present, future systems will typically operate on "sensor-fusion" to de-risk outages in sensitive applications.