Elements separately listed herein need not be distinct components and alternatively may be the same structure. A statement that an element or feature may exist is intended to include (a) embodiments in which the element or feature exists; (b) embodiments in which the element or feature does not exist; and (c) embodiments in which the element or feature exist selectably e.g., a user may configure or select whether the element or feature does or does not exist.

Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein. Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor/s may be employed to compute or generate or route, or otherwise manipulate or process information as described herein and/or to perform functionalities described herein and/or to implement any engine, interface or other system illustrated or described herein. Any suitable computerized data storage e.g., computer memory, may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computerized components shown and described herein may communicate between themselves via a suitable computer network.

The system shown and described herein may include user interface/s e.g. as described herein, which may, for example, include all or any subset of: an interactive voice response interface, automated response tool, speech-to-text transcription system, automated digital or electronic interface having interactive visual components, web portal, visual interface loaded as web page/s or screen/s from server/s via communication network/s to a web browser or other application downloaded onto a user's device, automated speech-to-text conversion tool, including a front-end interface portion thereof and back-end logic interacting therewith. Thus the term user interface, or “UI” as used herein, includes also the underlying logic which controls the data presented to the user e.g. by the system display, and receives and processes and/or provides to other modules herein, data entered by a user e.g. using her or his workstation/device.

BRIEF DESCRIPTION OF THE DRAWINGS

Certain embodiments of the present invention are illustrated in the following drawings; in the block diagrams, arrows between modules may be implemented as APIs and any suitable technology may be used for interconnecting functional components or modules illustrated herein in a suitable sequence or order e.g., via a suitable API/Interface. For example, state-of-the-art tools may be employed, such as but not limited to Apache Thrift™ remote procedure call (RPC) framework and Apache Avro™ data serialization framework, which provide remote call support. Or, a standard communication protocol may be employed, such as but not limited to HTTP (Hypertext Transfer Protocol) or MQTT (Message Queuing Telemetry Transport), and may be combined with a standard data format, such as but not limited to JSON (JavaScript Object Notation) or XML (Extensible Markup Language). According to one embodiment, one of the modules may share a secure API with another. Communication between modules may comply with any customized protocol or customized query language, or may comply with any conventional query language or protocol.

FIG. 1 illustrates a hardware processor configured to perform any method shown and described herein, and other hardware components providing inputs to the hardware processor.

FIG. 2 illustrates a platform and typically plural such, which may be interconnected by suitable network data communication and may have, onboard, a hardware processor such as that of FIG. 1.

FIGS. 3a-3b, taken together, form a simplified flowchart illustration of a method according to certain embodiments including operations as shown, all or any subset of which may be performed, in any suitable order e.g., as shown, for example by the hardware processor of FIG. 1 which may for example be deployed on board any of the platforms of FIG. 2. According to certain embodiments, the 1PPS signal is generated by the GNSS (Global Navigation Satellite System) and in all other operations 1 second (say) is counted according to an internal clock.

Methods and systems included in the scope of the present invention may include any subset or all of the functional blocks shown in the specifically illustrated implementations by way of example, in any suitable order, e.g., as shown. Flows may include all or any subset of the illustrated operations, suitably ordered e.g., as shown. Tables herein may include all or any subset of the fields and/or records and/or cells and/or rows and/or columns described.

Computational, functional, or logical components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor, or any suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences, such as but not limited to objects, procedures, functions, routines and programs, and may originate from several computer files which typically operate synergistically.

Each functionality or method herein may be implemented in software (e.g. for execution on suitable processing hardware, such as a microprocessor or digital signal processor), firmware, hardware (using any conventional hardware technology such as Integrated Circuit Technology), or any combination thereof.

Functionality or operations stipulated as being software-implemented may, alternatively, be wholly or fully implemented by an equivalent hardware or firmware module, and vice-versa. Firmware implementing functionality described herein, if provided, may be held in any suitable memory device and a suitable processing unit (aka processor) may be configured for executing firmware code. Alternatively, certain embodiments described herein may be implemented partly or exclusively in hardware, in which case all or any subset of the variables, parameters, and computations described herein may be in hardware.

Any module or functionality described herein may comprise a suitably configured hardware component or circuitry. Alternatively or in addition, modules or functionality described herein may be performed by a general purpose computer or more generally by a suitable microprocessor, configured in accordance with methods shown and described herein, or any suitable subset, in any suitable order, of the operations included in such methods, or in accordance with methods known in the art.

Any logical functionality described herein may be implemented as a real time application, if and as appropriate, and which may employ any suitable architectural option, such as but not limited to FPGA, ASIC or DS,P or any suitable combination thereof.

Any hardware component mentioned herein may in fact include either one or more hardware devices e.g., chips, which may be co-located or remote from one another.

Any method described herein is intended to include within the scope of the embodiments of the present invention also any software or computer program performing all or any subset of the method's operations, including a mobile application, platform or operating system e.g. as stored in a medium, as well as combining the computer program with a hardware device to perform all or any subset of the operations of the method.

Data can be stored on one or more tangible or intangible computer readable media stored at one or more different locations, different network nodes, or different storage devices at a single node or location.

It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data used for computing for an interval of time, and any type of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use, and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper, and others.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Spoofer detection solutions are now described which may generate, in real time, a time-specific indication that a platform is currently being spoofed (indication with value 1 e.g.), and may then estimate the platform's correct, non-spoofed current position using (only) the platform's own built-in system/s, and may continue using only the platform's own built-in system/s until the time-specific indication that platform is currently being spoofed has turned off (has been superseded with a time-specific indication of value 0 e.g.).

The spoofer detection solutions herein may define measures which can test each navigation method's level of reliability over time e.g. which of various indications of drift are more reliable or less reliable, and may give more or less weight to these, when generating a general, time-specific spoof indication by computing a weighted combination of drift-indication specific alerts.

The spoofer detection solutions described herein may connect plural navigation methods (e.g., plural indications of spoofing which are based on plural respective drift indications) to one generalized navigation method e.g., by combining the outputs of the plural navigations methods, and may define a relationship between the navigation methods for detecting deviations.

A system and process of operation, which may measure or estimate the actual current time, position and altitude of a vehicle (or more generally, platform) and compare them to the platform e.g., vehicle GNSS system time, position and altitude, and identifies GNSS spoofing (and publish the spoofed locations), is now described. FIGS. 1-3, whether provided in combination or separately, are example embodiments.

In FIG. 1, all or any subset of the hardware devices providing inputs to the processor (GNSS, INS, anchoring system, . . . . DTM, radar), may be provided. The processor may perform all or any subset of the operations shown and described herein, and may generate all or any subset of the outputs shown.

As shown, the GNSS typically provides time and/or position and/or altitude of the platform which is running the method of FIGS. 3a-3b.

The INS and anchoring system provide position of the platform which is running the method of FIGS. 3a-3b.

ADS provides barometric altitude of the platform which is running the method of FIGS. 3a-3b.

The radar altimeter provides barometric altitude of the platform which is running the method of FIGS. 3a-3b.

The DTM provides altitude of the terrain over which the platform, which is running the method of FIGS. 3a-3b, and is travelling.

The AA radar provides range from the platform which is running the method of FIGS. 3a-3b, to a network member that is being tracked by the radar.

The anchoring system of FIG. 1 is intended to refer to any subsystem, on board the platform, typically installed on the platform's avionics system, which uses suitable localization techniques, to provide georeferenced localization of the platform without GNSS, using instead:

- i. inertial measurements (approximated position+attitude) and/or
- ii. a (video e.g.) camera facing an arbitrary direction; and/or
- iii. an orthophoto image map
  
  e.g., as described online here: 2103.14381.pdf (arxiv.org)

Typically, the processor of FIG. 1 which may run the method of FIGS. 3a-3b including all or any subset of the operations in FIGS. 3a-3b, is configured to compute GNSS drift indications, comprising indications that certain GNSS-computed quantities, such as but not limited to Time, Altitude and Position (Latitude and/or Longitude), are drifting away from estimates of the same quantities provided by other, non-GNSS based sources. For example, a gap or difference between various GNSS-computed quantities, such as but not limited to Time, Altitude and Position (Latitude and/or Longitude) on the one hand, and estimates of the same quantities provided by other, non-GNSS based sources on the other hand, may be computed and compared to a threshold value.

Descriptions herein of how estimates of GNSS-computed quantities such as Time, Altitude and Position are obtainable from other, non-GNSS based sources, are intended to be merely exemplary, and not limiting.

Referring now to FIGS. 3a-3b, each platform may include all or any subset of the blocks shown and described herein by way of example.

It is appreciated that the network equipment referred to herein, which supports the network data communication between platforms e.g. as shown in FIG. 2, may include all or any component of conventional network hardware e.g. as described online here: en.wikipedia.org/wiki/Networking_hardware.

Typically, drift-indication specific possible spoof alert computations are all triggered by the same signal which is generated by a single module, e.g., the GNSS.

If the platforms are aircraft, each aircraft may include a suitable avionics system e.g., as described online herein: en.wikipedia.org/wiki/Networking_hardware. This system, or a similar system on non-aircraft platforms, may include a hardware processor (not shown for simplicity) which runs the method of FIGS. 3a-3b and may also include an anchoring system (not shown for simplicity) as described herein.

Inputs to the method herein may include all or any subset of the following inputs; each input below may be provided once, occasionally, periodically, or continuously:

Time Inputs1, . . . 3 (aka inputs T1, . . . . T3):

- Input1. GNSS Time from a GNSS which may be aboard the platform
- Input2. 1PPS (1 Pulse Per Second) from a GNSS which may be aboard the platform including the platform's Tfom from (or relative to) the GNSS
- Input3. Avionic Clock Time, from an avionic clock which may be aboard the platform (works in the same resolution as the GNSS and has a well-defined drift). Each tick in the clock represents the clock's resolution.
- Position inputs 1, . . . 12 aka inputs P1, . . . p12):
- Input1. GNSS Position e.g. Latitude and/or Longitude of platform (e.g., aircraft) which may be spoofed from GNSS
- Input2. GNSS Altitude of platform (e.g., aircraft) which may be spoofed from GNSS
- Input3. Hfom e.g., estimated horizontal error of platform (e.g., aircraft) which may be spoofed from GNSS
- Input4. Vfom e.g., estimated vertical error of platform (e.g., aircraft) which may be spoofed from GNSS
- Input5. INS Position e.g., Latitude and/or Longitude and/or Altitude of platform from an INS
- Input6. Network Member Position e.g., Latitude and/or Longitude and/or Altitude of platform received from a network member e.g., platform networked to the platform running all or any subset of operations 10, 20, . . . 140 described herein.
- Input7. Anchoring Position e.g., Latitude, Longitude of a platform from a video based anchoring system installed on an avionic system on the platform.
- Input8. Barometric Altitude of a platform from Air Data System
- Input9. Altitude of the terrain (in refer to the platform's Latitude, Longitude) on which the platform is travelling e.g., flying from a DTM.
- Input10. Radar Altitude of a platform from Radar altimeter
- Input11. Radar Range and Azimuth position of a network member from A-A Radar
- Input12. 4 Ground stations positions are pre-known ground station positions from a GNSS augmentation system or any other system for improving attributes, e.g., accuracy and/or reliability and/or availability, of any navigation system, such as GNSS or any navigation technology which may be used in GNSS's stead. Such systems for improving navigation attributes include such navigation services as WAAS or EGNOS e.g., as described online here en.wikipedia.org/wiki/Wide_Area_Augmentation_System and en.wikipedia.org/wiki/European_Geostationary_Navigation_Overlay_Service or, respectively or more generally, any satellite-based augmentation system (SBAS).

Such systems may provide data to improve positioning accuracy and/or integrity, and/or availability and/or reliability, e.g., by correcting error sources affecting GNSS signals, and may transmit, in real time, corrections to mitigate ranging error sources, such as but not limited to satellite clocks and/or satellite position and/or ionospheric effects.

Such a system may include, in a ground segment, Ranging Integrity Monitoring Stations (RIMS) and/or Mission Control Centres (MCC), and/or Navigation Land Earth Stations (NLES) e.g. for each Geostationary Earth Orbit (GEO), and/or a network e.g. Wide Area Network providing communication between all of the above components. Synchronization of this data with the GPS signal itself, is typically provided.

In a Space Segment, the system may include geostationary satellites broadcasting corrections and/or integrity information for GPS satellites e.g., in the L1 frequency band (1575.42 MHZ). In a user segment, receivers may enable their users to compute their positions with accuracy and integrity, based on data signals received via a compatible receiver.

Such a system's ground-based reference stations may be configured to measure variations in the GPS satellite signals in the western hemisphere. Measurements from reference stations may be routed to master stations, whose queue received Deviation Corrections, and send correction messages to geostationary WAAS satellites typically repeatedly, e.g., at least every 5 seconds. WAAS-enabled (say) GPS receivers may use the corrections while computing their positions to improve accuracy of these computations.

Augmentation typically improves the navigation system's attributes, via integration of external information into navigation computations. Information may characterize sources of error (e.g., clock drift and/or ephemeris and/or ionospheric delay), may indicate how much the signal was off in the past, and/or may include additional platform/vehicle information.

Additional Information:

- Input1. Net Member Spoofing Indication Spoofing indication from other networked platforms, e.g., as generated in operation 140.

Typically, each input data (e.g., T1-T3, P1-P12, A1) has a (typically unique, relative to other input data of the same type) time tag which may be generated by a main computer on the platform e.g., if the platform is an aircraft, by the avionics main computer. The time tag may be generated upon generation and/or upon receipt and/or upon transmission of the input data, by the entity (e.g. main computer) responsible for tagging all input data. Typically, if the time tag of one input data is generated upon generation thereof, at least one other input data (typically all) are also generated upon generation thereof. Or, if the time tag of one input data is generated upon receipt thereof, at least one other input data (typically all) are also generated upon receipt thereof. Or, if the time tag of one input data is generated upon transmission thereof, at least one other input data (typically all) is also generated upon transmission thereof.

All the time tags in the platform are synchronized in accordance with the 1 PPS synchronization mechanism as described online here: (en.wikipedia.org/wiki/Pulse-per-second_signal) or in accordance with the avionics main computer clock (en.wikipedia.org/wiki/MIL-STD-1553) that synchronize all the platform systems. Time synchronization is important in order to compare between inputs from several sources.

All of any subset of the following operations (or of the operations as shown in FIGS. 3a-3b) may be performed, e.g., by a processor on board the platform and/or on the ground. Typically, all operations 10, 20, . . . 140 are performed sequentially and/or repeatedly e.g., continuously or periodically, e.g., once a second.

Operation 10: sampling all or any subset of the GNSS indications values e.g., T1 and/or T2 and/or P1 and/or P3 and/or P4, periodically at a suitable rate such as once a second (1 HZ rate). The values sampled typically include general data and/or platform e.g., aircraft attitude information and/or platform e.g., aircraft position information.

The general data typically includes all or any subset of the following:

- 10i. Platform e.g. aircraft attitude information which typically includes all or any subset of the following:
- Current pitch, roll, yaw values, designated herein as pr y respectively; and/or maximum proper values for proper GNSS reception (which may be based on expert knowledge) for Pitch, Roll, Yaw, designated herein as P R Y respectively.
- 10ii. The GNSS Position information typically includes or is augmented by all or any subset of the following:
- Current Estimated Horizontal Error and Estimated Vertical Error values, designated herein as Hfom Vfom respectively; and/or maximum allowed values (which may be based on expert knowledge) for Horizontal FOM, Vertical FOM, designated herein as HFOM VFOM respectively.
- 10iii. The GNSS time information typically includes or is augmented by all or any subset of the following:
- Current Estimated Time Error, designated herein as Tfom respectively; and/or maximum allowed values (which may be based on expert knowledge) for Time FOM, designated herein as TFOM respectively.
- Operation 20: If (g<G) and (p<P and r<R and y<Y) and (Hfom<HFOM and Vfom<VFOM) and (Tfom<TFOM) indicating that the current GNSS input is reliable, then go to operation 30, otherwise discard the current GNSS input of the vehicle and go to operation 10. Alternatively, any other suitable logical combination (not just “and” e.g.) of any suitable criteria of reliability (the criteria which may or may not include conditions on all or any subset of g, p, r, y, Hfom, Vfom, Tfom).

A possible Spoof alert is now computed, e.g. by performing all or any subset of operations 30-90, suitably ordered e.g. as shown. There are 3 main data groups-time, altitude and position. The order of the steps is not crucial in order to find the possible sspoof alert.

- Operation 30: Identify a GNSS time drift and compute a possible spoof alert indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g., by performing all or any subset of the following operations, suitably ordered, e.g., as follows:
  - Read the Avionic Clock Time (in ticks) from the avionic computer every time that a 1PPS signal is raised (it is appreciated that “1PPS signal”, here and throughout the document, except if otherwise mentioned, is but an example of a periodic reference signal generated by a component of the system herein, typically by one central component, e.g. by the GNSS (as shown in FIG. 1 e.g.), and which may used as a common temporal reference point to trigger operations 30-90 and/or to ensure synchronization between the various data elements described herein):
    - a. Tprevious_1pps=Tcurrent_1pps
    - b. Tcurrent_1pps=Avionic Clock Time
  - Read the GNSS Time from the GNSS every time that a 1PPS signal is raised:
    - a. Tprevious_gnss=Tcurrent_gnss
    - b. Tcurrent_gnss=GNSS Time
  - Read the Tfom of the GNSS in the clock's resolution value from the GNSS every time that a 1PPS signal is raised and save it to Tfom. Tavionic_clock is the number of ticks which represent 1 second+the clock's drift (pre-known value e.g. constant)

T
⁢
1
⁢
pps

=

Tcurrent_
⁢
1
⁢
pps

-

Tprevious_
⁢
1
⁢
pps

Tgnss
=

Tcurrent_gnss
-
Tprevious_gnss

For each Tavionic_clock (~1 second):

1.
Read the most updated T1pps value

2.
Read the most updated Tgnss value

3.
Tgap1 = | Tavionic_clock − T1pps |

4.
Tgap2 = | Tavionic_clock − Tgnss |

5.
If Tgap1 > 0

a.
If | Tgap1 −Tfom | > 0

i.
Possible Spoof alert = 1

ii.
go to operation 110

b.
Else

i.
Possible Spoof alert = 0

6.
If Tgap2 > 0

a.
If | Tgap2 −Tfom | > 0

i.
Possible Spoof alert = 1

ii.
go to operation 110

b.
Else

i.
Possible Spoof alert = 0

Operation 40: Identify a GNSS barometric altitude drift and compute a Possible Spoof alert indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g. by performing all or any subset of the following operations, suitably ordered, e.g. as follows: Read the following every time that a Tavionic_clock (~1 second) has passed:

- 1. Barometric Altitude (in feet) from the Air Data System
- 2. GNSS Altitude from the GNSS
- 3. Estimated altitude error of the GNSS in the clock's resolution value from the GNSS and save it to Hfom
  
  BA Reference gap-a pre-known value determined by a human expert/system designer, e.g., as a parameter default value, e.g., /system designer, e.g., as a parameter default value, e.g. in accordance with:
- 1. The OEM pre-known altitude drift of the GNSS
- 2. The OEM pre-known drift of the Air Data Computer (according to the Atmosphere conditions)

For each Tavionic_clock (~1 second):

1.
Read the most updated Barometric Altitude value

2.
Read the most updated GNSS Altitude value

3.
Bagap = | Barometric Altitude − GNSS Altitude |

4.
If Bagap > BA Reference gap

a.
If | Bagap −Hfom | > 0

i.
Possible Spoof alert = 1

ii.
go to operation 110

b.
Else

i.
Possible Spoof alert = 0

Operation 50: Identify a GNSS computed altitude drift and compute a Possible Spoof alert indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g. by performing all or any subset of the following operations, suitably ordered, e.g. as follows:

Read the following every time that a Tavionic_clock (~1 second) has passed:

- 1. Radar Altitude (in feet) from the Radar Altimeter
- 2. GNSS Altitude from the GNSS
- 3. Estimated altitude error of the GNSS in the clock's resolution value from the GNSS and save it to Hfom
- 4. Altitude of the terrain from a DTM in the current platform position

DRA Reference gap-a pre-known value determined by a human expert/system designer, e.g., as a parameter default value, e.g. in accordance with:

1.
The OEM pre-known altitude drift of the GNSS

2.
The OEM pre-known drift of the Radar Altimeter

3.
The OEM pre-known drift of the DTM

For each Tavionic_clock (~1 second):

1.
Read the Radar Altitude value

2.
Read the GNSS Altitude value

3.
DRA= Radar Altitude + GNSS Altitude

4.
DRAgap = | DRA − GNSS Altitude |

5.
If DRAgap > DRA Reference gap

a.
If | DRAgap −Hfom | > 0

i.
Possible Spoof alert = 1

ii.
go to operation 110

b.
Else

i.
Possible Spoof alert = 0

Operation 60: Identify a GNSS position drift relative to the INS and compute a Possible Spoof alert Indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g. by performing all or any subset of the following operations, suitably ordered, e.g. as follows: Read the following every time that a Tavionic_clock (~1 second) has passed:

- 1. GNSS Position (e.g. platform latitude and longitude) of the platform from the GNSS
- 2. INS Position (e.g. platform latitude and longitude) of the platform from the INS
- 3. Estimated Position error of the GNSS in the clock's resolution value from the GNSS and save it to Vfom

INS Reference position gap-a pre-known value determined by a human expert/system designer, e.g., as a parameter default value, e.g. in accordance with:

1.
The OEM pre-known position drift of the GNSS

2.
The OEM pre-known position drift of the INS

For each Tavionic_clock (~1 second):

1.
Read the GNSS position values

2.
Read the INS position values

3.
INSgap = | INS position − GNSS position |

4.
If INSgap > INS Reference gap

a.
If | INSgap −Vfom | > 0

i.
Possible Spoof alert = 1

ii.
go to operation 110

b.
Else

i.
Possible Spoof alert = 0

Operation 70: Identify a GNSS position drift relative to an anchoring system (geo-localization system e.g., as described online here: arxiv.org/pdf/2103.14381.pdf) and compute a Possible Spoof alert indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g. by performing all or any subset of the following operations, suitably ordered, e.g. as follows:

Read the following every time that a Tavionic_clock (~1 second) has passed:

- 1. GNSS position (e.g., platform latitude and longitude) of the platform from the GNSS
- 2. Anchoring Position (e.g., platform latitude and longitude) of the platform from the anchoring system
- 3. Estimated Position error of the GNSS in the clock's resolution value from the GNSS and save it to Vfom

ANC Reference position gap-a pre-known value determined by a human expert/system designer, e.g., as a parameter default value, e.g. in accordance with:

1.
The OEM pre-known position drift of the GNSS

2.
The OEM pre-known position drift of the Anchoring system

For each Tavionic_clock (~1 second):

1.
Read the GNSS Position values

2.
Read the Anchoring Position values

3.
ANCgap = | Anchoring Position − GNSS position |

4.
If ANCgap > ANC Reference gap

a.
If | ANCgap −Vfom | > 0

i.
Possible Spoof alert = 1

ii.
go to operation 110

b.
Else

i.
Possible Spoof alert = 0

Operation 80: Identify a GNSS position drift relative to a Network Member Position and compute a Possible Spoof alert indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g., by performing all or any subset of the following operations, suitably ordered, e.g., as follows:

Read the following every time that a Tavionic_clock (~1 second) has passed:

- 1. GNSS Position (e.g., platform latitude and longitude) of the platform from the GNSS
- 2. Network Member Position (e.g., a net member platform latitude and longitude) of a platform from a network
- 3. Net Member Spoofing indication of a platform from a network
- 4. Radar Range of a network member relative to the platform from A-A Radar

NetMember Reference position gap-a pre-known value determined by a human expert/system designer, e.g., as a parameter default value, e.g., in accordance with:

- 1. The OEM pre-known position drift of the GNSS
- 2. The OEM pre-known range drift of the Radar Range
- 3. The OEM pre-known position drift of the aerial network

For each Tavionic_clock (~1 second):

1.
Read the GNSS Position values

2.
Read the Network Member Position values

3.
Read the Radar Range value

4.
Read the Net Member Spoofing indication of the network member

5.
NetMember Gap = | Network Member Position − GNSS position |

6.
If |NetMember Gap − Radar Range | > 0

a.
If NetMember Gap > Net Member Reference gap

i.
If Net Platform Spoofing indication is 0

1.
Possible Spoof alert = 1

2.
go to operation 110

ii.
Else

1.
Possible Spoof alert = 0

b.
Else

1.
Possible Spoof alert = 0

7.
Else

a.
Possible Spoof alert = 0

Operation 90: Identify a GNSS position drift relative to a known ground stations and compute a Possible Spoof alert indicating that the platform may be within the range of a spoofer and/or that GNSS readings provided to the platform may be spoofed) e.g., by performing all or any subset of the following operations, suitably ordered, e.g., as follows: Read the following every time that a Tavionic_clock (~1 second) has passed:

- 1. GNSS Position (e.g., platform latitude and longitude) of the platform from the GNSS
- 2. 4 Ground stations positions (e.g., platform latitude and longitude) of a pre-known ground station position
- 3. Estimated Position error of the GNSS in the clock's resolution value from the GNSS and save it to Vfom

Net Reference position gap-a pre-known value determined by a human expert/system designer, e.g., as a parameter default value, e.g. in accordance with:

- 1. The OEM pre-known position drift of the GNSS
- 2. The OEM pre-known position drift of the anchoring system
- 3. The OEM pre-known position drift of the navigation service

For each Tavionic_clock (~1 second):

1.
Read the GNSS Position values

2.
Read the 4 Ground stations Position values

a. Compute the Computed platform position according to

Ground stations Position (e.g. by using

http://mason.gmu.edu/~treid5/Math447/GPSEquations/)

3.
Netgap = | Computed platform position − GNSS position |

4.
If Netgap > Net Reference gap

a. If | Netgap −Vfom | > 0

i. Possible Spoof alert = 1

ii. go to operation 110

b. Else

i. Possible Spoof alert = 0

Operation 100: Identify Spoof Position by the following

1.
If Possible Spoof alert = 0

a.
Last Reliable Position = GNSS Position

2.
Else go to operation 110

Operation 110: Count the number of consecutive Possible Spoof alert (e.g., the length of a current run of Tavionic_clock, characterized in that all Tavionic_clock signals in the run triggered a Possible Spoof alert of value 1) e.g. in the following way:

1.
If Possible Spoof alert = 1

a.
SpoofIndicationCounter = SpoofIndicationCounter + 1

2.
Else

a.
SpoofIndicationCounter = 0

b.
Go to operation 10

More generally, in Operation 110, drift-indication specific Possible Spoof alerts may be combined to yield a time-specific spoof indication. This is implicit in the specific embodiment described above by way of example, in which a single possible spoof alert value of 1, obtained using any drift indication, suffices to yield a time-specific spoof indication of 1 (which is why, in the illustrated embodiment, a possible spoof alert of 1 is followed by skipping straight to operation 110. However, more generally, e.g., as described elsewhere herein, other logic (logic which does not involve ORing-all possible spoof alert values) may be used to define the time-specific spoof indication as a combination of drift-indication specific Possible Spoof alerts and this logic may be performed in operation 110.

Operation 120: detect that a spoofer is present, if the run of Tavionic_clock all of which triggered a positive spoof indication, has an over-threshold length e.g., identify Spoof indication by the following:

1.
If SpoofIndicationCounter >= 10 (or any other suitable run length)

a.
Spoof indication = 1

2.
Else

a.
Go to operation 10

Operation 130: Compute Last Reliable Position Radius by the following:

- 1. Read the platform Velocity from the INS
- 2. Last Reliable Position Radius=Platform Velocity*SpoofIndicationCounter
  
  It is assumed that the platform velocity remains the same as it was in Last Reliable
  
  Position
  
  Operation 140: Report all or any subset of the following via an aerial network e.g., radio communication such as to other platforms in the area which are in data communication with the platform performing all or any subset of operations 10-140 herein and which may themselves be performing all or any subset of operations 10-140 herein
- 1. Spoof indication
- 2. Last Reliable Position
- 3. Last Reliable Position Radius as computed in operation 130 Go to operation 10
  - It is appreciated that by sending Last Reliable Position and Last Reliable Position Radius other platforms can define spoofed areas (where Last Reliable Position is the center of a circle and Last Reliable Position Radius is the radius of the circle)

It is appreciated that, by way of example, a spoof indication may be provided at a given time, if even a single navigation method indicates that a spoofer may be present, thus the criterion for presence of a spoofer is defined as navigation method 30 or 40 or . . . 90 (using the numbering of the operations to refer to the respective navigation methods employed). However, alternatively, a spoofer may be deemed present/absent based on any other logical or computational combination of the set of navigation methods corresponding to operations 30, 40, . . . 90, such as deeming a spoofer to be present only if navigation method 30 and 40 and . . . 90 all so indicate. Or deeming a spoofer to be present only if M (e.g. 3 or 4) navigation methods all so indicate, or only if at least one of the first 5 navigation methods all so indicate, and/or deeming a spoofer to be absent if at least one of the first 4 navigation methods all so indicate, etc. any set of rules may be defined, rather than only those rules, and that logic specifically described herein, to combine plural navigation methods, such as all or any subset of navigations methods 30-90 herein. Also, the possible spoof indication need not be binary, and may instead be multi-level (e.g., there may be one or more “inconclusive” levels, or 5 levels such as 1, “tend to 1”, inconclusive, “tend to 0” and zero. These states may be combined, again using any suitable logical or computational combination. Or, machine learning may be employed to determine, over time, which navigation methods did best in detecting presence of a spoofer.

According to certain embodiments, training data may be provided by deploying known spoofers at known locations, then operating the system, and then assigning higher and lower weights to navigation methods which detect the known spoofers more and less successfully, respectively.

Training data may include a first set of data points recording gaps or drifts which were found when spoofers are known to have been present, and/or a second set of data points recording gaps or drifts which were found when spoofers are known not to have been present.

Training may encompass plural levels e.g., one level vis a vis a spoofer simulator and the system in general, another level in which the system becomes operational and runs vis a vis real spoofers, and a third level in which recordings made by the platforms are analyzed in the lab to improve functioning of the system.

According to one embodiment, less than all navigation methods are employed in at least one time unit. For example, if a spoofer is deemed to be present in a given time unit, if even one navigation method so indicates, then once a given navigation method so indicates, during a given time-unit, all other navigation methods may be skipped, in that time unit. Similarly, if a spoofer is deemed to be absent in a given time unit, if even one navigation method so indicates, then once a given navigation method so indicates, during a given time-unit, all other navigation methods may be skipped, in that time unit. However, alternatively, all navigation methods may be employed in each time unit. Or, the logic governing which navigation method/s to operate in each time unit may be other than that described above merely by way of non-limiting example.

Also, any suitable criterion of consecutiveness may be employed; the criterion of detecting a spoofer if and only if 10 (or any other threshold number of) spoof indications occur over 10 consecutive time units, is merely an example. The system may, for example, use a criterion of consecutiveness which states that even if time-specific spoof indications occur, say, in 8 consecutive time-units followed by 2 more in which time-specific spoof indications also occur with a 1-unit skip (between the 8 units and the 2 units) in which no time-specific spoof indication occurs, and so forth. The criterion of consecutiveness may be defined over one or more drift-indication specific possible spoof alerts rather than over time-specific spoof indications. If a criterion of consecutiveness is defined over each of plural drift-indication specific possible spoof alerts, then the resulting plural criteria of consecutiveness may be logically combined to yield a single total criterion of consecutiveness.