Detecting Spoofed Global Navigation Satellite System (GNSS) Signals

Abstract

In one aspect, a user equipment (UE) receives a spoof alert message from either a server or an Internet of Things (IOT) device indicating whether a spoofed Global Navigation Satellite System (GNSS) condition exists. Based on a determination that the spoof alert message indicates that a spoofed GNSS condition exists, the UE determines a location of a spoofer broadcasting a spoofed GNSS signal based on the spoof alert message, determines that the UE is within a reception area of ​​the spoofed GNSS signal based on the location of the spoofer and a current location of the UE, and determines a position of the UE without using the spoofed GNSS signal.

Description

[Technical field]

[0001] Aspects of the present disclosure relate generally to Global Navigation Satellite Systems (GNSS), and in particular to detecting spoofed GNSS signals. [Background technology]

[0002] A satellite navigation system is a system that uses satellites to provide autonomous geospatial positioning. Such systems enable electronic receivers to determine location (longitude, latitude, and altitude) with high accuracy (e.g., typically within a few centimeters to a few meters) using radio frequency (RF) signals transmitted along line of sight from the satellites. A satellite navigation system with worldwide coverage is called a Global Navigation Satellite System (GNSS).

[0003] Reliable navigation is important for public safety. GNSS signals used for navigation can be spoofed, thereby causing navigation problems and potentially disastrous consequences for users. Spoofing refers to broadcasting a false ("spoofed") GNSS signal with the intention that the receiver will mistake the spoofed signal for a genuine signal, thereby causing the receiver to determine a false position fix. Such spoofing can be used, for example, to make a drone plummet, guide a yacht off course, etc. Thus, spoofing a GNSS signal can cause dangerous behavior from a receiver that trusts the spoofed signal. Current techniques for detecting spoofed GNSS signals are unreliable and cannot distinguish between a spoof and a bad (e.g., noisy) environment. Summary of the Invention [Means for solving the problem]

[0004] The following provides a simplified summary of one or more aspects disclosed herein. As such, the following summary is not intended to be an extensive overview of all contemplated aspects, nor is it intended to identify key or critical elements of all contemplated aspects or to define the scope associated with any particular aspect. As such, the following summary has the sole purpose of presenting some concepts of one or more aspects of the mechanisms disclosed herein in a simplified form prior to the detailed description presented below.

[0005] In a first aspect, a method of operating a server includes receiving an alert message from a monitored device in a set of monitored devices. The alert message includes Global Navigation Satellite System (GNSS) measurement data. The method includes determining, based at least in part on an analysis of the GNSS measurement data, whether a spoofed GNSS condition exists. Based on the determination, the method includes sending a spoof alert message to one or more user equipment (UE).

[0006] In a second aspect, a method of operating a device includes measuring one or more Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data, determining that one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied, and sending a warning message associated with the GNSS measurement data to a server to alert the server of potential GNSS spoofing.

[0007] In a third aspect, a method of operating a user equipment includes receiving a spoof alert message including an indication that a spoofed Global Navigation Satellite System (GNSS) condition exists, a location of a spoofer broadcasting the spoofed GNSS signal, and an indication of a spoofed zone. The method includes determining that the spoof alert message indicates that a spoofed GNSS condition exists. The method includes determining a location of the spoofer broadcasting the spoofed GNSS signal based on the spoof alert message. The method includes determining that the user equipment is within a reception area of ​​the spoofed GNSS signal based on the location of the spoofer and a current location of the user equipment. The method includes determining a position of the user equipment without using the spoofed GNSS signal.

[0008] In a fourth aspect, a device includes a memory and one or more processors communicatively coupled to the memory, the one or more processors configured to measure one or more Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data, determine that one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied, and send a warning message associated with the GNSS measurement data to a server to alert the server of potential GNSS spoofing.

[0009] In a fifth aspect, a server includes a memory and one or more processors communicatively coupled to the memory. The one or more processors are configured to receive an alert message from a monitored device in a set of monitored devices. The alert message includes Global Navigation Satellite System (GNSS) measurement data. The one or more processors are configured to determine, based at least in part on an analysis of the GNSS measurement data, whether a spoofed GNSS condition exists, and, based on the determination, send a spoof alert message to one or more user equipments (UEs).

[0010] In a sixth aspect, a user equipment includes a wireless transceiver, a global navigation satellite system (GNSS) receiver, and one or more processors. The one or more processors are communicatively connected to the wireless transceiver and the GNSS receiver. The one or more processors are configured to receive a spoofing alert message including an indication of whether a spoofed global navigation satellite system (GNSS) condition exists, a location of a spoofer broadcasting the spoofed GNSS signal, and an indication of a spoofed zone. The one or more processors are configured to determine that the spoofing alert message indicates that a spoofed GNSS condition exists. The one or more processors are configured to determine a location of a spoofer broadcasting the spoofed GNSS signal based on the spoofing alert message. The one or more processors are configured to determine that the user equipment is within a reception area of ​​the spoofed GNSS signal based on the location of the spoofer and a current location of the user equipment. The one or more processors are configured to determine a position of the user equipment without using the spoofed GNSS signal.

[0011] In a seventh aspect, a non-transitory computer-readable storage medium stores instructions executable by one or more processors to receive an alert message from a monitored device in a set of monitored devices. The alert message includes Global Navigation Satellite System (GNSS) measurement data. The instructions are executable by the one or more processors to determine, based at least in part on an analysis of the GNSS measurement data, whether a spoofed GNSS condition exists. Based on the determination, the instructions are executable to send a spoof alert message to one or more user equipments (UEs).

[0012] In an eighth aspect, a non-transitory computer-readable storage medium stores instructions executable by one or more processors to measure one or more Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data, determine that one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied, and send a warning message associated with the GNSS measurement data to a server to alert the server of potential GNSS spoofing.

[0013] In a ninth aspect, a non-transitory computer-readable storage medium stores instructions executable by one or more processors to receive a spoof alert message including an indication that a spoofed Global Navigation Satellite System (GNSS) condition exists, a location of a spoofer broadcasting the spoofed GNSS signal, and an indication of a spoofed zone. The instructions are further executable by the one or more processors to determine that the spoof alert message indicates that a spoofed GNSS condition exists. The instructions are further executable by the one or more processors to determine a location of the spoofer broadcasting the spoofed GNSS signal based on the spoof alert message. The instructions are further executable by the one or more processors to determine that the user equipment is within a reception area of ​​the spoofed GNSS signal based on the location of the spoofer and a current location of the user equipment. The instructions are further executable by the one or more processors to determine a position of the user equipment without using the spoofed GNSS signal.

[0014] Other objects and advantages associated with the embodiments disclosed herein will become apparent to those of ordinary skill in the art based on the accompanying drawings and detailed description.

[0015] The accompanying drawings are presented to aid in the explanation of various aspects of the present disclosure and are provided only for illustration of the aspects, not for limitation of the aspects. A more complete understanding of the present disclosure may be obtained by reference to the following detailed description in conjunction with the accompanying drawings. In the figures, the left-most digit of a reference number identifies the figure in which that reference number first appears. The same reference numbers in different figures indicate similar or identical items. [Brief description of the drawings]

[0016] [Figure 1]FIG. 1 illustrates an example of a system for detecting spoofed GNSS data in accordance with various aspects of the present disclosure. [Diagram 2] FIG. 1 illustrates an example wireless communication system in accordance with various aspects of the present disclosure. [Diagram 3] FIG. 1 illustrates an example process for determining whether to send a warning message, according to an aspect of the present disclosure. [Figure 4] FIG. 1 illustrates an example process for selecting a subset of devices to monitor, according to an aspect of the disclosure. [Diagram 5] FIG. 2 illustrates an example process for determining whether a spoofed signal is being broadcast, according to an aspect of the disclosure. [Figure 6] FIG. 1 illustrates an example process including sending a warning message to a server, according to an aspect of the disclosure. [Figure 7] FIG. 1 illustrates an example process that includes performing an analysis to determine whether spoofed GNSS data is being received by a device, according to an aspect of the disclosure. [Figure 8] FIG. 1 illustrates an example process including receiving a spoofing alert, according to an aspect of the disclosure. [Figure 9] FIG. 1 illustrates a communication system according to an aspect of the present disclosure. [Figure 10A] 1 is a simplified block diagram of several sample aspects of components that may be employed in a wireless communication node and configured to support communications as described herein; [Figure 10B] 1 is a simplified block diagram of several sample aspects of components that may be employed in a wireless communication node and configured to support communications as described herein; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Systems and techniques are disclosed for detecting GNSS data spoofing using static Internet of Things (IOT) devices. For example, static IOT devices embedded in locations such as traffic lights, street lights, security cameras, etc. are used to determine whether spoofed GNSS data is being transmitted. Each static IOT device in the network performs a comparison of a long-term average of GNSS fixes to a short-term average of GNSS fixes. The short-term average of GNSS fixes is an average of the number of fixes determined in a relatively short time period, such as, for example, between about 10 seconds and about 60 seconds. In some aspects, the short-term average of GNSS fixes may be determined over a time period of about 20 seconds. The long-term average of GNSS fixes is the number of fixes determined in a relatively long time period, such as, for example, between 1 day and 30 days. In some aspects, the long-term average of GNSS fixes may be determined over a time period of about 7 days. The short-term average and the long-term average are used only as examples. It should be understood that other techniques, such as determining a median of fixes over a time period, determining a statistical center, etc., may be used instead of determining an average.

[0018] For example, if the difference between the long-term average of the GNSS fix and the short-term average of the GNSS fix meets a certain threshold, the static IOT device determines that the static IOT device may have received spoofed GNSS data and sends an alert message to the server including the short-term average of the GNSS fix, the long-term average of the GNSS fix, the difference between the long-term average and the short-term average of the GNSS fix, and the HEPE. The server stores the data received from the IOT device (e.g., in a database), thereby enabling the server to use the long-term average of the GNSS fix as a reference for determining whether the GNSS data is spoofed.

[0019] The server serves a particular geographic region (e.g., a portion of a city, one or more cities, one or more counties, one or more states, one or more countries, or another geographic definition). The server collects data from multiple IOT devices located in the particular geographic region ("region") to determine whether the GNSS data is spoofed. The server may perform analysis of the alert messages received from multiple IOT devices, such as, for example, the location of each IOT device, how long each IOT device has been sending alert messages, and the movement patterns of each IOT device. By way of example, the server may determine whether position jumps are similar (e.g., due to spoofed ephemeris) or whether multiple positions jump to the same location (meaconing). In navigation, ephemeris (plural ephemerides) gives the orbit, e.g., position and possibly velocity, of satellites in the sky over time. Meaconing is the interception and rebroadcasting of navigation signals. The navigation signal is rebroadcast on the receiving frequency, typically at a higher power level than the original signal. The server may optionally use machine learning, such as a support vector machine or other classifier, to predict (e.g., based on an alert message) whether spoofed GNSS data (e.g., one or more GNSS signals) are being transmitted in the area.

[0020] If the server determines, for example, based on the analysis of the alert message that GNSS spoofing is occurring (e.g., spoofed data is being broadcast), the server sends information about the spoofing to user equipment (UE) devices (and to IOT devices) in the area. By analyzing alert messages from multiple IOT devices, the server can determine the location of the spoofer. Because the server collects data from multiple IOT devices, the systems and techniques described herein provide much greater reliability compared to other methods of detecting spoofing. Additional advantages include self-learning based on historical data, no external assistance, no prior reconnaissance, use of existing infrastructure, low cost, wide coverage, etc. Furthermore, the systems and techniques described herein may be used using point positioning (SPP) without using precision improvements used to increase the accuracy of GNSS-derived positioning, such as, for example, real-time kinematic (RTK) positioning, precise point positioning (PPP), etc. However, when accuracy improvements such as RTK, PPP, etc. are available, the systems and techniques described herein can take advantage of them to increase the accuracy of spoof analysis.

[0021] Aspects of the present disclosure are provided in the following description and associated drawings, which are directed to various examples provided for illustrative purposes. Alternative aspects may be devised without departing from the scope of the present disclosure. Additionally, well-known elements of the present disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of the present disclosure.

[0022] The words "exemplary" and / or "example" are used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" and / or "example" should not necessarily be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the disclosure" does not require that all aspects of the disclosure include the described feature, advantage or mode of operation.

[0023] Those skilled in the art will appreciate that the information and signals described below may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the following description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, depending in part on the particular application, in part on the desired design, in part on the corresponding technology, etc.

[0024] Further, many aspects are described in terms of sequences of actions to be performed, for example, by elements of a computing device. It will be appreciated that various actions described herein may be performed by specific circuitry (e.g., an application specific integrated circuit (ASIC)), by program instructions being executed by one or more processors, or by a combination of both. In addition, a sequence of actions described herein may be considered to be fully embodied in any form of non-transitory computer-readable storage medium having stored therein a corresponding set of computer instructions that, when executed, will cause or instruct an associated processor of a device to perform the functions described herein. Thus, various aspects of the present disclosure may be embodied in a number of different forms, all of which are contemplated to fall within the scope of the claimed subject matter. In addition, for each of the aspects described herein, the corresponding form of any such aspect may be described herein, for example, as "logic configured to" perform the described actions.

[0025] As used herein, the terms "user equipment" (UE) and "base station" are not intended to be specific or otherwise limited to any particular radio access technology (RAT) unless otherwise stated. In general, a UE may be any wireless communication device (e.g., a mobile phone, a router, a tablet computer, a laptop computer, a consumer asset tracking device, a wearable device (e.g., a smart watch, glasses, an augmented reality (AR) / virtual reality (VR) headset, etc.), a vehicle (e.g., an automobile, a motorcycle, a bicycle, etc.), an Internet of Things (IoT) device, etc.) used by a user to communicate over a wireless communication network. A UE may be mobile or may be stationary (e.g., at some times) and may communicate with a radio access network (RAN). As used herein, the term "UE" may be referred to interchangeably as "access terminal" or "AT", "client device", "wireless device", "subscriber device", "subscriber terminal", "subscriber station", "user terminal" or "UT", "mobile device", "mobile terminal", "mobile station", or variations thereof. In general, a UE may communicate with a core network via a RAN, through which the UE may be connected to external networks, such as the Internet, and to other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for a UE, such as via a wired access network, a wireless local area network (WLAN) network (e.g., based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11, etc.), etc.

[0026] A base station may operate according to one of several RATs in communication with UEs depending on the network in which the base station is deployed and may alternatively be referred to as an access point (AP), network node, Node B, evolved Node B (eNB), next generation eNB (ng-eNB), New Radio (NR) Node B (also referred to as gNB or gNode B), etc. A base station may be used primarily to support wireless access by UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, the base station may provide purely edge node signaling functionality, while in other systems, the base station may provide additional control and / or network management functionality. A communication link through which a UE may send RF signals to a base station is referred to as an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). A communication link through which a base station may send RF signals to a UE is referred to as a downlink (DL) or forward link channel (e.g., paging channel, control channel, broadcast channel, forward traffic channel, etc.). As used herein, the term Traffic Channel (TCH) can refer to either an uplink / reverse traffic channel or a downlink / forward traffic channel.

[0027] The term "base station" may refer to a single physical transmit reception point (TRP) or multiple physical TRPs that may or may not be collocated. For example, when the term "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station corresponding to a cell (or several cell sectors) of the base station. When the term "base station" refers to multiple collocated physical TRPs, the physical TRP may be an array of antennas of the base station (e.g., as in the case of a multiple-input multiple-output (MIMO) system or when the base station employs beamforming). When the term "base station" refers to multiple non-collocated physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transport medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, a non-collocated physical TRP may be a serving base station from which the UE receives measurement reports from neighboring base stations whose UE is measuring its reference RF signal (or simply "reference signal"). A TRP is a point from which a base station transmits and receives wireless signals, so as used herein, references to transmission from or reception at a base station should be understood as referring to the particular TRP of the base station.

[0028] In some implementations that support positioning of UEs, a base station may not support wireless access by the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but instead may transmit reference signals to the UE to be measured by the UE and / or may receive and measure signals transmitted by the UE. Such a base station may be referred to as a positioning beacon (e.g., when it transmits signals to the UE) and / or a location measurement unit (e.g., when it receives and measures signals from the UE).

[0029] An "RF signal" includes electromagnetic waves of a given frequency that transport information through space between a transmitter and a receiver. As used herein, a transmitter may transmit a single "RF signal" or multiple "RF signals" to a receiver. However, the receiver may receive multiple "RF signals" corresponding to each transmitted RF signal due to the propagation characteristics of RF signals through a multipath channel. The same RF signal transmitted on different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, an RF signal may also be referred to as a "wireless signal," "radar signal," "wave," "waveform," etc., or simply a "signal" when it is clear from the context that the term "signal" refers to a wireless signal or an RF signal.

[0030] As a first example, a device (e.g., an Internet of Things (IOT) device) measures Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data, determines that one or more GNSS spoofing criteria associated with the GNSS measurement data are met, and sends a warning message associated with the GNSS measurement data to a server to alert the server of the potential GNSS spoofing. For example, the device may determine that one or more GNSS spoofing criteria associated with the GNSS measurement data are met by determining a current GNSS fix based on the GNSS signal, updating the GNSS fix data to include the current GNSS fix, determining a short-term average of the GNSS fix based on the GNSS fix data, determining a long-term average of the GNSS fix based on the GNSS fix data, determining a difference between the short-term average of the GNSS fix and the long-term average of the GNSS fix, determining that the difference meets a first threshold for at least a particular duration, determining a horizontal estimated position error (HEPE) based on the current GNSS fix, and determining that the HEPE meets a second threshold for at least a particular duration. The short-term average of the GNSS fix is ​​determined for a time period of 10 to 60 seconds, and in some embodiments preferably 20 seconds. The long-term average of the GNSS fix is ​​determined for a time period of 1 to 30 days, and in some embodiments preferably one week. The device may receive a spoof alert message from a server indicating the presence of a spoofed GNSS signal. The spoof alert message includes at least one of (1) one or more frequencies associated with the spoofed signal, or (2) one or more constellations associated with the spoofed signal. The device may ignore the spoofed GNSS signal. The device may determine that one or more user equipment (UE) are receiving the spoofed GNSS signal and send the spoof alert message to at least one UE of the one or more UEs.In some cases (e.g., if the server determines that the device may be defective), the device may receive instructions from the server to do at least one of: take certain sensors associated with the device offline, stop sending warning messages to the server, or put the device into a low power mode (e.g., standby or powered down).

[0031] As a second example, a server receives an alert message from a monitored device in a set of monitored devices (e.g., monitored IOT devices). The alert message includes Global Navigation Satellite System (GNSS) measurement data. The server determines whether a spoofed GNSS condition exists based at least in part on an analysis of the GNSS measurement data, and based on the determination, sends a spoof alert message to one or more user equipment (UE). If the server determines that there is no spoofed GNSS condition, the spoof alert message provides an indication that a spoofed GNSS condition does not exist. If the server determines that a spoofed GNSS condition exists, the spoof alert message provides an indication that a spoofed GNSS condition exists. Determining that a spoofed GNSS condition exists includes determining that a number of monitored devices sending alert messages is greater than a number threshold, determining that a percentage of a number of monitored devices sending alert messages to a total number of monitored devices is greater than a percentage threshold, determining that a size of a sub-area in which the monitored devices are sending alert messages is greater than a size threshold, and determining that a length of time in which the monitored devices are sending alert messages is greater than a time threshold. The spoofed alert message includes a spoofed constellation used by the spoofed GNSS signal, a frequency used by the spoofed GNSS signal, or both. Determining that a spoofed GNSS condition does not exist includes determining that for at least a percentage of the monitored devices, a difference between a short-term average of GNSS fixes and a long-term average of GNSS fixes is less than a difference threshold.The server creates a set of monitored devices by determining that there are no spoofed GNSS conditions, and if for a particular device of the plurality of devices, a difference between a short-term average of the first plurality of global navigation satellite system fixes and a long-term average of the second plurality of global navigation satellite system fixes is less than or equal to a difference threshold, and the horizontal estimated position error is less than or equal to an error threshold, the server includes the particular device in the set of monitored devices. The alert message received from the monitored device includes the short-term average of the first plurality of GNSS fixes determined by the monitored device, the long-term average of the second plurality of GNSS fixes determined by the monitored device, the difference between the short-term average and the long-term average, and the horizontal estimated position error (HEPE) determined by the monitored device. The server may receive a second alert message from a second monitored device in the set of monitored devices. The second alert message includes second GNSS measurement data. If the server determines, based at least in part on the second GNSS measurement data, that the second monitored device is defective, the server removes the second monitored device from the set of monitored devices. The server sends instructions to the second monitored device. For example, the instructions may include a first instruction to disable a navigation sensor of the second monitored device, a second instruction to transition the second monitored device to a low power mode, or both. 10. The method of claim 1, further comprising: determining a weighted average of long-term averages of GNSS fixes determined by the monitored devices sending the warning messages, the weight for each device being based on a difference between a short-term average of GNSS fixes determined by the monitored devices sending the warning messages and a long-term average of GNSS fixes determined by the monitored devices sending the warning messages; and determining a rough location of the spoofer transmitting the spoofed GNSS signal based on the weighted average.

[0032] As a third example, a user equipment (UE) receives a spoof alert message indicating whether a spoofed global navigation satellite system (GNSS) condition exists. If the UE determines that the spoof alert message indicates that a spoofed GNSS condition exists, the UE determines a location of a spoofer broadcasting the spoofed GNSS signal based on the spoof alert message, determines that the user equipment is within a reception area (e.g., a spoofed zone) of the spoofed GNSS signal based on the location of the spoofer and a current location of the user equipment, and determines a position of the user equipment without using the spoofed GNSS signal. For example, the spoof alert message includes one or more constellations associated with the spoofed GNSS signal, one or more frequencies associated with the spoofed GNSS signal, or both. The user equipment may determine a location of the user equipment without using spoofed GNSS signals by retrieving a previously determined location (e.g., determined prior to receiving the spoof alert message), determining sensor data from one or more sensors (e.g., magnetometer, gyroscope, accelerometer, etc.) of the user equipment, and determining a current location of the user equipment based at least in part on the previously determined location and sensor data. Based on a determination that the spoof alert message indicates an absence of spoofed GNSS conditions, the user equipment determines a location of the user equipment using the GNSS signals.

[0033] FIG. 1 illustrates an example of a system 100 for detecting spoofed GNSS data according to various aspects of the present disclosure. The system 100 may include a plurality of Internet of Things (IOT) devices 102(1)-102(N) (N>0) connected to one or more servers 104 via one or more networks 106. A plurality of user equipments (UEs) 108(1)-108(M) (M>0) may be connected to the network 106 and may include user devices such as, for example, smartphones, smart watches, vehicles, and other devices capable of receiving Global Navigation Satellite System (GNSS) data 168 (e.g., transmitted by a GNSS signal source 170) and determining a position fix (e.g., latitude, longitude, altitude) based on the GNSS data 168. Each UE 108 may include a plurality of sensors 116 including navigation sensors 114 (e.g., a GNSS receiver, etc.) and a wireless transceiver 115.

[0034] The spoofer 110 may transmit spoofed data 112 to fool navigation sensors 114 (e.g., GNSS receivers) that are part of a plurality of sensors 116 included in each of the UEs 108. The spoofed data 112 can cause receivers, such as the IOT devices 102 and the UEs 108, to determine a false fix.

[0035] Each of the IOT devices 102 may have an associated location. For example, in FIG. 1, the IOT device 102(1) has an associated location 118(1), and the IOT device 102(N) has an associated location 118(N). Each of the locations 118 may be different from one another. At least a portion of the IOT devices 102 may be at fixed (e.g., stationary) locations 118. For example, at least some of the IOT devices 102 may be co-located with street lights, traffic lights, security cameras, or another type of stationary object. The user equipment 108 may include user devices, such as, for example, smartphones, smart watches, vehicles, and other devices that are not typically stationary and may be moving from one location to another.

[0036] Each of the IOT devices 102 includes a number of sensors 120, including navigation sensors for receiving GNSS data 168 and determining a current fix. In some cases, an inertial measurement unit (IMU) and a camera may be included in the number of sensors 120 to enable the individual IOT devices 102 and the server 104 to determine that the individual IOT devices are static. Each of the IOT devices 102 may store fixes 121, including a current fix and previously determined fixes. Each of the IOT devices 102 includes a spoof checker 122 that performs various calculations (e.g., as described herein) based on the fixes 121. For example, the spoof checker 122 determines (e.g., using the fixes 121) a short-term average ("ST AVG") 124 of the GNSS fixes, a long-term average ("LT AVG") 126 of the GNSS fixes, and determines the difference in distance between the short-term average 124 and the long-term average 126, for a particular time interval. Each of the IOT devices 102 may determine a horizontal estimated position error (HEPE) 123. The short-term average 124 of the GNSS fixes is an average of the number of fixes determined over a relatively short time period, such as, for example, between about 10 seconds and about 60 seconds. In some aspects, the short-term average of the GNSS fixes may be determined over a time period of about 20 seconds. The long-term average 126 of the GNSS fixes is a number of fixes determined over a relatively long time period, such as, for example, between 1 day and 30 days. In some aspects, the long-term average of the GNSS fixes may be determined over a time period of about 7 days. The short-term average 124 and the long-term average 126 are used by way of example only. It should be understood that other techniques, such as determining a median of fixes over a time period, determining a statistical center, etc., may be used instead of determining an average.

[0037] Each of the IOT devices 102 determines whether criteria 128 is met, including the difference in distance between the short-term average 124 and the long-term average 126. For example, if the IOT device 102(1) determines that the criteria 128 is met, the IOT device 102(1) may send a message 130 (e.g., a warning message) to the server 104 indicating that the IOT device 102(1) suspects that spoofing is occurring. For example, the criteria 128 may specify that spoofing is likely occurring if the IOT device 102(1) determines that (1) the difference in distance between the short-term average 124 and the long-term average 126 meets a first threshold, (2) the difference in distance divided by the HEPE 123 meets a second threshold, and (3) both conditions (1) and (2) are met for at least a certain duration (e.g., a third threshold). In response to determining that the criteria 128 are met, the IOT device 102(1) sends a message 130 to the server 104 alerting the server 104 that spoofing may be occurring.

[0038] If one or more of the IOT devices 102 use real-time kinematic (RTK) positioning, precise point positioning (PPP), or another technique for improving positioning accuracy, the improved accuracy provided by these may be used to improve the accuracy of spoofing detection. In some cases, the GNSS data 168 received by individual IOT devices 102 may be cross-checked with positioning data from a trusted source. For example, rather than decoding the ephemeris over the air (OTA), the ephemeris may be downloaded directly from a GNSS control center.

[0039] The message 130 may include data such as, for example, an identifier that uniquely identifies the IOT device sending the message 130, the short-term average 124, the long-term average 126, additional data associated with the IOT device sending the message 130, or any combination thereof. The identifier may be a device number, a serial number, a Media Access Control (MAC) address, an Internet Protocol (IP) address, a service tag, or another type of identifier that uniquely identifies the sender, such as the IOT device 102(1).

[0040] The server 104 serves a particular geographical area (e.g., a portion of a city, one or more cities, one or more counties, one or more states, one or more countries, or another geographical definition). The particular geographical area includes IOT devices 102 and user equipment 108. The server 104 may or may not be physically located in the particular geographical area. When the spoofed data 112 is being broadcast, the server 104 may receive messages 130 from each of the multiple IOT devices 102 that are within the reception area (e.g., sub-area 154) of the spoofed data 112. The reception area of ​​the spoofed data 112 is also referred to as a spoofed zone. The number of IOT devices 102 that receive the spoofed data 112 may vary based on the signal strength associated with the broadcast of the spoofed data 112, which of the IOT devices 102 are within the line of sight of the spoofer 110, and other factors related to the broadcast of the spoofed data 112.

[0041] When spoofing does not exist, the server 104 may determine a subset 152 of devices, for example, a subset of IOT devices 102 that are behaving normally (e.g., the difference between the averages 124, 126 is below a first threshold and the HEPE is below a second threshold). In addition, in some cases, the server 104 may select a portion of the IOT devices 102 that are stationary (e.g., fixed) for inclusion in the subset 152 of devices, and exclude the remaining IOT devices 102 that are not stationary (e.g., may be moving). The server 104 may use messages 130 sent by IOT devices in the subset 152 of devices to determine whether spoofing exists, and may ignore messages 130 sent by IOT devices that are not included in the subset 152 of devices for calculations performed to determine whether spoofing occurs.

[0042] The server 104 may receive a plurality of the messages 130 and use the spoofing detector 132 to analyze the data contained in the plurality of messages 130 to determine whether GNSS signal spoofing is occurring, for example, based on the number of messages 130 received in a particular time interval and other factors. The server 104 may perform an analysis using the analysis module 133 (e.g., as described herein) to determine whether a condition 134 is met. For example, the server 104 may determine whether the number of IOT devices 102 in the subset is greater than a first threshold, whether a ratio (or percentage) of IOT devices 102 sending messages 130 to a total number of IOT devices 102 is greater than a second threshold, whether a size of a sub-region 154 in which the subset of IOT devices 102 is located is greater than a size threshold, and whether the subset of IOT devices 102 has been sending messages 130 for at least a particular duration (e.g., a particular time period). If spoofing detector 132 determines that condition 134 is met, then spoofing detector 132 determines that spoofing is occurring. In some cases, spoofing detector 132 may use machine learning 136 to predict whether spoofing is occurring based on data received in multiple ones of messages 130. For example, machine learning 136 may include a classifier, such as a support vector machine, to predict whether the data indicates that spoofing is occurring.

[0043] If the server 104 determines that spoofing is occurring, the server 104 may potentially send instructions to activate additional IOT devices of the IOT devices 102. For example, when there is no spoofing, a majority (e.g., greater than 50%) of the IOT devices 102 may be in a low power mode (e.g., idle, hibernate, etc.). The remaining IOT devices 102 may be in an active mode, e.g., performing calculations to determine whether spoofing is occurring. When the server 104 receives a message 130 from an individual device in the subset of devices 152, the server 104 may send instructions to instruct the additional IOT devices 102 to transition from a low power mode to an active mode. In this manner, the server 104 receives additional data (e.g., short-term average 124, long-term average 126, HEPE 123, and other data) in the message 130 from the additional IOT devices 102. The server 104 may use the additional data to determine a spoofer location 166 of the spoofer 110, as described herein.

[0044] If the spoofing detector 132 determines that spoofing is occurring, the spoofing detector 132 may identify one or more sub-areas 138 that include the spoofer location 166 of the spoofer 110 and the size of each of the sub-areas 138. For example, the server 104 may determine the location 118 of the IOT device 102 sending the message 130 to determine the sub-area 138 that the spoofing affects. The spoofing detector 132 may determine a threat level 140 and a confidence level 141 associated with the spoofing. For example, the spoofing detector 132 may determine that spoofing is occurring in a particular sub-area (e.g., sub-area 154) of the sub-area 138 with a particular confidence percentage (e.g., confidence level 141) based on the number of IOT devices 102 sending the message 130 and based on the ratio of the number of IOT devices 102 sending the message 130 to the subset 152 of devices. The spoofing detector 132 may determine a threat level 140 based on data in the message 130, such as, for example, the difference between the averages 124, 126, the HEPE, and other data. The threat level 140 of the spoofed data 112 may be higher for one or more of the user equipment 108 if the spoofer 110 is closer to one or more of the user equipment 108 and lower if the spoofer 110 is farther away (e.g., greater than a threshold distance) from one or more of the user equipment 108.

[0045] The spoofing detector 132 may determine a spoofer location 166 of the spoofer 110 to allow one or more actions to be taken to address the spoofing. The one or more actions may include alerting authorities that the spoofed data 112 is being broadcast, resulting in positioning errors that may have disastrous consequences, such as, for example, a car accident. In response, the authorities (e.g., police) may take appropriate action to stop the broadcast of the spoofed data 112. The server 104 may determine the spoofer location 166 of the spoofer 110 by "crowdsourcing" using data from the IOT devices 102, as described herein.

[0046] The server 104 may store in the database 142 the data received from the IOT device 102, intermediate results of calculations performed to determine if spoofing is occurring, and other data. In this manner, the server 104 can access historical data to perform various types of analysis, such as to determine, for example, which sub-areas are being targeted for spoofing, which frequencies are being used for spoofing, etc. Additionally, if machine learning is used, it may be periodically retrained after additional data is received.

[0047] After the spoofing detector 132 determines that spoofing is occurring, the server 104 may use the network management 144 to manage the networks 106, IOT devices 102, and UEs 108 in the area. For example, after spoofing is detected, the server 104 may monitor messages 130 being received from individual IOT devices 102 to determine if spoofing is continuing. If the network management 144 determines at any time that spoofing has stopped (e.g., spoofed data 112 is not being received by the IOT devices 102), the server 104 may stop performing the network management 144.

[0048] Based on the determination that spoofing is occurring, the server 104 may send a spoof alert 146 to the IOT device 102, the user equipment 108, or both. Based on the trust level, the server 104 may include details about the spoofed data 112 in the spoof alert 146, such as, for example, the sub-area 154 in which the spoofed data 112 is broadcast, the frequency in which the spoofed data 112 is broadcast, the constellation being spoofed, and other details associated with the spoofed data 112. Based on the spoofing details provided in the spoof alert 146, the IOT device 102 and the user equipment 108 may ignore the spoofed data 112. For example, a vehicle (e.g., one of the user devices 108) traveling from a first sub-region (e.g., where spoofing is not occurring) to a second sub-region (e.g., where spoofing is occurring) may receive the spoofed data 112, determine that the spoofed data 112 is specified in the spoof alert 146, and ignore the spoofed data 112 when determining a position fix. In this manner, the vehicle may avoid having an accident, routing the vehicle's occupants to an incorrect destination, or another undesirable consequence caused by the spoofed data 112.

[0049] In some cases, the server 104 may receive the message 130 from a particular one of the IOT devices 102, such as the IOT device 102(N), rather than from other IOT devices 102 located near (e.g., in the same sub-region as) the IOT device 102(N). In such a case, the server 104 may determine that the IOT device 102(N) has a faulty navigation sensor, is experiencing GNSS reception problems, or both. For example, atmospheric conditions, electromagnetic interference, an object that temporally blocks the line of sight between the source of the GNSS signal and the IOT device 102(N), a malfunctioning navigation (e.g., GNSS) sensor (e.g., one of the sensors 120), another condition, or any combination thereof, may cause the IOT device 102(N) to erroneously determine that spoofing is occurring and send the message 130 to the server 104. In such a case, the server 104 may exclude the IOT device 102(N) from the subset 152 of devices (e.g., thereby not using subsequently sent messages 130 from the IOT device 102(N) to perform analysis using the analysis module 133). In some cases, the server 104 may send instructions 148 to the IOT device 102(N) to reduce the number of messages 130 being sent by the IOT device 102(N). For example, the instructions 148 may instruct the IOT device 102(N) to turn off (e.g., disable) navigation sensors, stop sending messages 130, or take another action. In this way, the server 104 may stop receiving messages 130 from the IOT device 102(N) that it has erroneously determined to be spoofed. In some cases, the server 104 may alert a maintenance technician that the IOT device 102(N) may be defective. A maintenance technician may schedule maintenance to diagnose and address the problem by, for example, replacing navigation sensors, removing debris that is blocking line of sight, etc.

[0050] The IOT device 102 may, in some cases, send the alert 150 directly to one or more of the user equipment 108 located near (e.g., in the same area or sub-area) one or more of the IOT devices 102. The alert 150 may indicate that spoofing may be occurring and may provide details associated with the spoofing, such as the frequency being used for the spoofing, the sub-area (e.g., sub-area 154) in which the spoofing is occurring, etc. For example, if the IOT device 102(1) is unable to communicate with the server 104 (e.g., the message 130 is not deliverable), the IOT device 102(1) may send the alert 150 directly to one or more of the user equipment 108. In this way, if the server 104 is unavailable or communication with the server 104 is unavailable, the user equipment 108 can get the alert 150 indicating the potential spoofing and act on the alert 150 by ignoring the spoofed data 112 when determining a fix. For example, if the user equipment 108(1) receives an alert 150 from at least a threshold number (e.g., M or more, M>1) of IOT devices 102, the user equipment 108(1) may determine that spoofing is occurring and may ignore the spoofed data 112, use a different positioning mechanism, or both. For example, the spoofing alert 146 and alert 150 may include the general location of the spoofer 110 and details about the spoofed data 112, such as the constellation being spoofed, the frequency being used, etc. In response to receiving the spoofing alert 146 or alert 150, the user equipment 108(1) may determine whether it is located within a certain distance from the spoofer's location (e.g., close enough to be able to receive the spoofed data 112).If the user equipment 108(1) is close enough to the spoofer 110 to be able to receive the spoofed data 112, the user equipment 108(1) may ignore the spoofed data 112 and use another positioning technique, such as using other sensors. For example, the user equipment 108(1) may determine a most recently obtained location that is known to be accurate (e.g., a location determined prior to receiving the spoof alert 146 or 150) and use sensor data from other sensors (e.g., an accelerometer, gyroscope, magnetic compass (magnetometer), map data, etc.) to determine a current location.

[0051] The network management 144 of the server 104 may continue to monitor the messages 130 received from the IOT devices 102 until the server 104 determines that spoofing is no longer occurring. For example, the server 104 may perform an analysis (using the analysis module 133) of the messages 130 received from multiple IOT devices 102, and when the results of the analysis module 133 fail to satisfy the condition 134, the server 104 may determine that spoofing is no longer present. In response, in some cases, the server 104 may send a stop spoofing 156 message to the IOT devices 102 and user equipment 108 indicating that spoofing is no longer present. After receiving the stop spoofing 156 message, the IOT devices 102 and user equipment 108 may resume acquiring and using GNSS data 168.

[0052] Thus, for example, an IOT device co-located with a stationary object, such as a traffic light, street light, security camera, etc., may receive a GNSS signal and analyze the received signal to determine whether a spoofed GNSS signal is being broadcast. For example, to determine whether spoofing is present, an individual IOT device may determine the difference between a short-term average of the GNSS fix (e.g., a real-time position fix) and a long-term average of the GNSS fix. If the individual IOT device determines that (1) the difference meets a first threshold, (2) the difference divided by the horizontal estimated position error (HEPE) meets a second threshold, and (3) conditions (1) and (2) are both true for a particular duration (e.g., a third threshold), then the IOT device may determine that the IOT device is receiving spoofed GNSS data. In response, the IOT device may send a message (e.g., an alert message) to a server. The message may include data associated with the spoofing, including a long term average of the GNSS fix, a short term average of the GNSS fix, the difference between the two, and other data related to the GNSS signal received by the IOT device. The server may service a particular region and may receive multiple messages from multiple IOT devices in the particular region (each of the multiple messages being sent by a respective one of the multiple IOT devices).

[0053] The server may analyze the multiple messages to determine whether spoofing is occurring. For example, the server may select a subset of IOT devices that sent alert messages, determine whether the number of IOT devices in the subset sending messages is greater than a first threshold, determine whether a percentage of the IOT devices sending messages to the total number of IOT devices is greater than a second threshold, and determine whether the number of IOT devices in the subset repeatedly send messages for at least a certain duration. If the server determines that the criteria are met, the server may determine that spoofing is occurring. For example, if the server determines that multiple static IOT devices in a sub-area are moving in a similar pattern, the server may determine that spoofed data exists. To illustrate, if the location jumps are similar, for example, due to the IOT devices receiving spoofed ephemeris, the server may conclude that spoofed data exists. As another example, if the locations of multiple IOT devices jump to the same point, for example, due to meaconing, the server may determine that spoofed data exists.

[0054] By using data from multiple IOT devices, the server can reliably determine if spoofing is occurring. Thus, reliability is improved compared to traditional means of determining spoofing, since multiple devices can confirm the spoofing. Additionally, if a particular IOT device is sending messages while other nearby IOT devices are not, the server can determine that the particular IOT device may have a malfunctioning GNSS sensor or something may be interfering with the particular IOT device's ability to receive GNSS signals, causing the IOT device to erroneously determine that GNSS spoofing may be occurring. The server can request that the particular IOT device temporarily disable its GNSS sensor and request that maintenance be performed on the particular IOT device to address the issue. In this manner, untrusted IOT devices may be identified and corrected.

[0055] 2 illustrates an exemplary wireless communication system 200. The wireless communication system 200 (sometimes referred to as a wireless wide area network (WWAN)) may include various base stations 202 and various UEs 204. The base stations 202 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In an aspect, the macrocell base stations may include eNBs and / or ng-eNBs, if the wireless communication system 200 corresponds to an LTE network, or gNBs, if the wireless communication system 200 corresponds to an NR network, or a combination of both, and the small cell base stations may include femtocells, picocells, microcells, etc.

[0056] The base stations 202 collectively form a RAN and may interface with a core network 270 (e.g., Evolved Packet Core (EPC) or 5G Core (5GC)) through backhaul links 222 and through the core network 270 to one or more location servers 272 (which may be part of the core network 270 or may be external to the core network 270). In addition to other functions, the base stations 202 may perform functions related to one or more of forwarding user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, Multimedia Broadcast Multicast Services (MBMS), subscriber and equipment tracing, RAN Information Management (RIM), paging, positioning, and distribution of alert messages. The base stations 202 may communicate with each other directly or indirectly (e.g., through EPC / 5GC) via backhaul links 234, which may be wired or wireless.

[0057] The base stations 202 may wirelessly communicate with the UEs 204. Each of the base stations 202 may provide communication coverage to a respective geographic coverage area 210. In an aspect, one or more cells may be supported by the base stations 202 in each geographic coverage area 210. A "cell" is a logical communication entity used for communication with a base station (e.g., over some frequency resource called a carrier frequency, component carrier, carrier, band, etc.) and may be associated with an identifier (e.g., physical cell identifier (PCI), virtual cell identifier (VCI), cell global identifier (CGI)) to distinguish cells operating over the same or different carrier frequencies. In some cases, different cells may be configured according to different protocol types (e.g., machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB), or others) that may provide access for different types of UEs. Because a cell is supported by a particular base station, the term "cell" may refer to either or both of the logical communication entity and the base station supporting it, depending on the context. In some cases, the term "cell" may refer to the geographic coverage area (e.g., a sector) of a base station so long as the carrier frequency can be detected and used for communication within any portion of the geographic coverage area 210.

[0058] Because of the proximity of the macrocell base stations 202, the geographic coverage areas 210 may overlap partially (e.g., in handover regions), but some of the geographic coverage areas 210 may be substantially overlapped by larger geographic coverage areas 210. For example, a small cell (SC) base station 202' may have a geographic coverage area 210' that substantially overlaps with the geographic coverage area 210 of one or more macrocell base stations 202. A network that includes both small cell base stations and macrocell base stations may be known as a heterogeneous network. A heterogeneous network may also include a Home eNB (HeNB) that may serve a restricted group known as a Closed Subscriber Group (CSG).

[0059] The communication link 220 between the base station 202 and the UE 204 may include uplink (also referred to as reverse link) transmissions from the UE 204 to the base station 202 and / or downlink (also referred to as forward link) transmissions from the base station 202 to the UE 204. The communication link 220 may use MIMO antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 220 may be over one or more carrier frequencies. The allocation of carriers may be asymmetric for the downlink and uplink (e.g., more or fewer carriers may be allocated for the downlink than for the uplink).

[0060] The wireless communication system 200 may further include a wireless local area network (WLAN) access point (AP) 250 in communication with a WLAN station (STA) 252 via a communication link 254 in an unlicensed frequency spectrum (e.g., 5 GHz). When communicating in the unlicensed frequency spectrum, the WLAN STA 252 and / or the WLAN AP 250 may perform a clear channel assessment (CCA) or listen-before-talk (LBT) procedure before communicating to determine if a channel is available.

[0061] The small cell base station 202' may operate in a licensed and / or unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell base station 202' may employ LTE or NR technology and use the same 5 GHz unlicensed frequency spectrum used by the WLAN AP 250. A small cell base station 202' employing LTE / 5G in an unlicensed frequency spectrum may extend coverage to and / or increase capacity of an access network. NR in an unlicensed spectrum may be referred to as NR-U. LTE in an unlicensed spectrum may be referred to as LTE-U, Licensed Assisted Access (LAA), or MulteFire.

[0062] The wireless communication system 200 may further include a mmW base station 280 that may operate at millimeter wave (mmW) and / or sub-mmW frequencies in communication with the UE 282. Extremely High Frequency (EHF) is a portion of RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 2 millimeters and 20 millimeters. Radio waves in this band may be referred to as millimeter waves. Sub-mmW may extend down to a frequency of 3 GHz with a wavelength of 200 millimeters. The Super High Frequency (SHF) band extends between 3 GHz to 30 GHz and is also referred to as centimeter waves. Communications using mmW / sub-mmW radio frequency bands have high path loss and relatively short distances. The mmW base station 280 and the UE 282 may utilize beamforming (transmit and / or receive) over the mmW communication link 284 to compensate for the extremely high path loss and short distances. It will be appreciated that in alternative configurations, one or more base stations 202 may also transmit using mmW or sub-mmW and beamforming. Therefore, it should be appreciated that the above illustrations are merely illustrative and should not be construed as limiting the various aspects disclosed herein.

[0063] Transmit beamforming is a technique for focusing an RF signal in a particular direction. Traditionally, when a network node (e.g., a base station) broadcasts an RF signal, it broadcasts it in all directions (omni-directionally). With transmit beamforming, the network node determines where a given target device (e.g., a UE) is located (relative to the transmitting network node) and launches a stronger downlink RF signal in that particular direction, thereby providing a faster and stronger RF signal (in terms of data rate) to the receiving device. To change the directionality of the RF signal when transmitting, the network node can control the phase and relative amplitude of the RF signal at each of one or more transmitters broadcasting the RF signal. For example, the network node may use an array of antennas (called a "phased array" or "antenna array") that creates beams of RF waves that can be "steered" to point in different directions without actually moving the antennas. In particular, RF currents from the transmitters are fed to the individual antennas in the correct phase relationship, so that the waves from the separate antennas join together to increase radiation in the desired direction while canceling to suppress radiation in undesired directions.

[0064] A transmit beam may be quasi-colocated, meaning that the transmit beam appears to a receiver (e.g., a UE) to have the same parameters, regardless of whether the network node's own transmit antenna is physically colocated or not. In NR, there are four types of quasi-location (QCL) relationships. In particular, a QCL relationship of a given type means that some parameters for a target reference RF signal on a target beam can be derived from information about a source reference RF signal on a source beam. If the source reference RF signal is QCL Type A, the receiver can use the source reference RF signal to estimate the Doppler shift, Doppler spread, average delay, and delay spread of the target reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type B, the receiver can use the source reference RF signal to estimate the Doppler shift and Doppler spread of the target reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type C, the receiver can use the source reference RF signal to estimate the Doppler shift and average delay of the target reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type D, the receiver can use the source reference RF signal to estimate spatial reception parameters of a target reference RF signal transmitted on the same channel.

[0065] In receive beamforming, a receiver uses a receive beam to amplify detected RF signals on a given channel. For example, the receiver can increase the gain setting and / or adjust the phase setting of an array of antennas in a particular direction to amplify (e.g., increase its gain level) RF signals received from that direction. Thus, when a receiver is said to beamform in a certain direction, it means that the beam gain in that direction is high relative to the beam gains along other directions, or that the beam gain in that direction is the highest compared to the beam gains in that direction of all other receive beams available to the receiver. This results in a stronger received signal strength (e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Signal to Interference and Noise Ratio (SINR), etc.) of RF signals received from that direction.

[0066] The receive beams may be spatially related. The spatial relationship means that the parameters of the transmit beam for the second reference signal may be derived from information about the receive beam for the first reference signal. For example, the UE may use a particular receive beam to receive one or more downlink reference signals (e.g., positioning reference signal (PRS), tracking reference signal (TRS), phase tracking reference signal (PTRS), cell-specific reference signal (CRS), channel state information reference signal (CSI-RS), primary synchronization signal (PSS), secondary synchronization signal (SSS), synchronization signal block (SSB), etc.) from a base station. The UE can then form a transmit beam for sending one or more uplink reference signals (e.g., uplink positioning reference signal (UL-PRS), sounding reference signal (SRS), demodulation reference signal (DMRS), PTRS, etc.) to that base station based on the parameters of the receive beam.

[0067] Note that a "downlink" beam can be either a transmit beam or a receive beam, depending on the entity that forms it. For example, if the base station forms a downlink beam to transmit a reference signal to the UE, then the downlink beam is a transmit beam. However, if the UE forms a downlink beam, then it is a receive beam to receive the downlink reference signal. Similarly, an "uplink" beam can be either a transmit beam or a receive beam, depending on the entity that forms it. For example, if the base station forms an uplink beam, then it is an uplink receive beam, and if the UE forms an uplink beam, then it is an uplink transmit beam.

[0068] In 5G, the frequency spectrum in which wireless nodes (e.g., base station 202 / 280, UE 204 / 182) operate is divided into multiple frequency ranges, namely, FR1 (from 450 MHz to 6000 MHz), FR2 (from 24250 MHz to 52600 MHz), FR3 (above 52600 MHz), and FR4 (between FR1 and FR2). In a multi-carrier system such as 5G, one of the carrier frequencies is called the "primary carrier" or "anchor carrier" or "primary serving cell" or "PCell" and the remaining carrier frequencies are called the "secondary carrier" or "secondary serving cell" or "SCell". In carrier aggregation, the anchor carrier is the carrier operating on the primary frequency (e.g., FR1) utilized by the UE 204 / 282 and the cell in which the UE 204 / 282 either performs an initial radio resource control (RRC) connection establishment procedure or initiates an RRC connection re-establishment procedure. The primary carrier carries all common and UE-specific control channels and may be (but is not always) a carrier among licensed frequencies. The secondary carrier is a carrier operating on a second frequency (e.g., FR2) that may be configured once an RRC connection is established between the UE 204 and the anchor carrier and may be used to provide additional radio resources. In some cases, the secondary carrier may be a carrier among unlicensed frequencies. Since both the primary uplink carrier and the primary downlink carrier are typically UE-specific, the secondary carrier may include only the necessary signaling information and signals, e.g., signaling information and signals that are UE-specific may not be present in the secondary carrier. This means that different UEs 204 / 282 in a cell may have different downlink primary carriers. The same applies to the uplink primary carrier. The network may change the primary carrier of any UE 204 / 282 at any time. This is done, for example, to distribute the load on different carriers.Since a "serving cell" (whether a PCell or an SCell) corresponds to the carrier frequency / component carrier with which any base station is communicating, terms such as "cell", "serving cell", "component carrier", and "carrier frequency" may be used interchangeably.

[0069] For example, still referring to FIG. 2, one of the frequencies utilized by the macrocell base station 202 may be an anchor carrier (or “PCell”), and the other frequencies utilized by the macrocell base station 202 and / or the mmW base station 280 may be secondary carriers (“SCells”). Simultaneous transmission and / or reception of multiple carriers allows the UE 204 / 282 to significantly increase its data transmission and / or data reception rates. For example, two aggregated 20 MHz carriers in a multi-carrier system would theoretically provide a two-fold increase in data rate (i.e., 40 MHz) compared to the data rate achieved by a single 20 MHz carrier.

[0070] The wireless communications system 200 may further include a UE 264, which may communicate with the macrocell base station 202 via communications link 220 and / or with the mmW base station 280 via an mmW communications link 284. For example, the macrocell base station 202 may support a PCell and one or more SCells for the UE 264, and the mmW base station 280 may support one or more SCells for the UE 264.

[0071] In the example of FIG. 2, one or more Earth-orbiting Satellite Positioning System (SPS) Space Vehicles (SVs) 212 (e.g., satellites) may be used as independent sources of location information for any of the illustrated UEs (shown in FIG. 2 as a single UE 204 for simplicity). The UEs 204 may include one or more dedicated SPS receivers specifically designed to receive SPS signals 224 to derive geolocation information from the SVs 212. An SPS typically includes a system of transmitters arranged to enable receivers (e.g., UEs 204) to determine their location on or above the Earth based at least in part on signals (e.g., SPS signals 224) received from transmitters (e.g., SVs 212). Such transmitters typically transmit signals marked with a repeating pseudorandom noise (PN) code of a set number of chips. Although typically located on the SVs 212, transmitters may sometimes be located on ground-based control stations, base stations 202, and / or other UEs 204.

[0072] Use of SPS signals 224 may be augmented by various satellite-based augmentation systems (SBAS), which may be associated with or otherwise enabled for use with one or more global navigation satellite systems and / or regional navigation satellite systems. For example, SBAS may include augmentation systems that provide integrity information, differential corrections, and the like, such as Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), Multi-Function Satellite Augmentation System (MSAS), Global Positioning System (GPS) Aided Geo-Augmented Navigation, or GPS and Geo-Augmented Navigation System (GAGAN). Thus, as used herein, SPS may include any combination of one or more global navigation satellite systems and / or regional navigation satellite systems and / or augmentation systems, and SPS signals 224 may include SPS signals, SPS-like signals, and / or other signals associated with such one or more SPS.

[0073] The wireless communication system 200 may further include one or more UEs, such as a UE 290, that indirectly connect to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links (referred to as "sidelinks"). In the example of FIG. 2, the UE 290 has a D2D P2P link 292 (e.g., through which the UE 290 may indirectly obtain cellular connectivity) in which one of the UEs 204 is connected to one of the base stations 202, and a D2D P2P link 294 (through which the UE 290 may indirectly obtain WLAN-based Internet connectivity) in which the WLAN STA 252 is connected to the WLAN AP 250. In one example, the D2D P2P links 292 and 294 may be supported with any well-known D2D RAT, such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), Bluetooth, etc.

[0074] In the flow diagrams of Figures 3, 4, 5, 6, 7, and 8, each block represents one or more operations that may be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, cause the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the blocks are described is not intended to be construed as limiting, and any number of the described operations may be combined in any order and / or in parallel to implement a process. For purposes of explanation, processes 300, 400, 500, 600, 700, and 800 are described with reference to Figures 1 and 2 as described above, although other models, frameworks, systems, and environments may be used to implement these processes.

[0075] FIG. 3 illustrates a process 300 for determining whether to send a warning message according to an embodiment of the present disclosure. For example, the process 300 may be performed by an individual IOT device among the IOT devices 102 of FIG. 1. One type of GNSS, the Global Positioning System (GPS), uses a 10-bit field to encode the week number in each GPS time signal, meaning that a maximum of 1,024 weeks (19.7 years) may be used. The 1,024-week period is called an "epoch." At the end of each 1,024-week epoch, the receiver resets the week number to 0 and begins counting again.

[0076] At 302, the process acquires GNSS data. At 304, the process determines the short-term average 124 of the GNSS fixes of FIG. 1. For example, the process may use the following formula:

number

[0077] At 306, the process determines the long-term average 126 of the GNSS fixes of Figure 1. For example, the process may use the following formula:

number

[0078] At 308, the process determines the difference (e.g., in distance) between the short-term average of GNSS fixes 124 and the long-term average of GNSS fixes 126. The difference Δr(k) for epoch k may be determined by taking the absolute value of the short-term average of GNSS fixes 124 minus the long-term average of GNSS fixes 126, as follows:

number

[0079] After determining (at 304) the short-term average of the GNSS fix, (at 306) the long-term average of the GNSS fix, and (at 308) the difference, the process determines whether certain criteria are met at 310. At 308, the process determines whether (1) Δr (the difference between the long-term average and the short-term average of the GNSS fix) is greater than a first threshold (TH1), and (2) Δr divided by HEPE is greater than a second threshold (TH2), and both (1) and (2) occurred for a duration greater than a third threshold (TH3). For example, the first threshold TH1 may be 200 meters (m), the second threshold TH2 may be 5, the third threshold TH3 may be 20 seconds, and the HEPE may be 50 m or greater.

[0080] If the process determines "yes" at 310 (the criteria are met), the process sends a warning message to the server. For example, in FIG. 1, if the IOT device 102(1) determines that the difference between ST AVG 124 and LT AVG 126 meets criteria 128, the IOT device 102(1) sends message 130 to the server 104. If the process determines "no" at 310 (the criteria are not met), the process proceeds to 302 to acquire additional GNSS data.

[0081] The server 104 receives the spoofer location 166 of the spoofer 110.

number

number

number

number

number

[0082] 4 illustrates a process 400 for selecting a subset of devices to monitor according to an aspect of the disclosure. Process 400 may be performed by server 104 of FIG.

[0083] At 402, the process determines the absence of a spoofed GNSS signal. At 404, the process receives data from a plurality of devices. The data includes the difference between the short-term GNSS fix and the long-term GNSS fix, HEPE, etc. For example, in FIG. 1, the server 104 may receive a message 130 including the difference between the ST AVG 124 and the LT AVG 126, and the HEPE 123.

[0084] At 406, the process determines, for each device of the plurality of devices, (1) whether the difference between the short-term average and the long-term average of the GNSS fix is ​​less than or equal to a difference threshold (TH4), and at 408, (2) whether the HEPE is less than or equal to a HEPE threshold (TH5). If both (1) and (2) are met, then at 410, the device is selected for inclusion in a subset of devices monitored by the server. For example, in FIG. 1, the server 104 determines that there is no spoofed data 112 and requests that the IOT device 102 send data such as the difference between ST AVG 124 and LT AVG 126 and HEPE 123. For each particular IOT device of the IOT devices 102, if the difference is less than or equal to the threshold TH4 and the HEPE is less than or equal to the threshold TH5, the server 104 may include the particular IOT device in the subset of devices 152. The server 104 may use alert messages (eg, message 130) received from a subset of devices 152 when determining whether spoofing is occurring.

[0085] Thus, the server 104 of FIG. 1 may select a subset of devices 152 (also referred to as selected devices) that are deemed “normal” during times when spoofing is not occurring, for example, by selecting a subset of IOT devices 102 whose (1) Δr is less than or equal to a fourth threshold (TH4) and (2) HEPE is less than or equal to a fifth threshold (TH5). The fourth and fifth thresholds may vary based on factors such as the number of IOT devices that the server 104 manages, how much interference the IOT devices experience, and the like. The fourth and fifth thresholds may be set to values ​​that filter out IOT devices that are sending messages 130 based on a relatively small error when spoofing is not occurring (e.g., a relatively small Δr and a relatively small HEPE).

[0086] 5 illustrates a process 500 for determining whether a spoofed signal is being broadcast, according to an embodiment of the present disclosure. The process 500 may be performed by the server 104 of FIG.

[0087] At 502, the process receives an alert message from each of a plurality of devices of the selected devices. Each alert message includes data associated with each device, such as the difference between the short-term average and the long-term average of the GNSS fix, HEPE. For example, in FIG. 1, the server 104 may receive a message 130 from one or more of the IOT devices 102. The message 130 may include data such as the difference between the ST AVG 124 and the LT AVG 126, HEPE 123.

[0088] At 504, the process may determine whether the number of IOT devices sending messages indicating potential spoofing meets a sixth threshold (TH6). At 506, the process may determine whether the number of IOT devices sending messages 130 divided by the number of devices in the subset 152 of devices is greater than a seventh threshold (TH7). In some cases, the number of IOT devices sending messages 130 divided by the subset of IOT devices may be expressed as a percentage. At 508, the process may determine whether the size of the sub-area in which the device is sending messages is greater than an eighth threshold (TH8). At 510, the process may determine whether the IOT device has been sending messages 130 for a ninth threshold amount of time (TH9) or more. At 512, the process determines whether the conditions 504, 506, 508, and 510 are met. If the process determines "yes" at 512 (the condition is met), the process sends a spoof alert message at 514. The process proceeds back to 502 to receive additional messages. If the process determines "no" at 512 (the condition is not met), the process sends a spoof stop message at 516 if a spoof alert message was previously sent. The process proceeds back to 502 to receive additional messages. For example, in FIG. 1, if the server 104 determines that the conditions 504, 506, 508, and 510 are met, the server 104 performs various actions (e.g., as described herein), including sending a spoof alert to the IOT device 102 and the UE 108. The server 104 determines that spoofing is no longer occurring based on the following determinations: Δr for x% of devices (x%>TH7) <TH4

[0089] Thus, after an IOT device in the selected subset of IOT devices begins to send a warning message (e.g., indicating possible spoofing) to the server 104, the server 104 may determine information such as, for example, how many IOT devices in the subset of IOT devices are sending messages, the ratio of IOT devices sending messages to a selected number of IOT devices, the number of IOT devices sending messages located in a particular sub-region of the region (e.g., a neighborhood of a city), and whether an IOT device has been sending messages for more than a threshold amount of time. Based on determining this information, the server may determine whether spoofing is occurring.

[0090] 6 illustrates an example process 600 including sending an alert message to a server according to an embodiment of the present disclosure. The process 600 may be performed by an individual IOT device of the IOT devices 102 of FIG.

[0091] At 602, the process acquires GNSS data. At 604, the process determines a current GNSS fix based on the GNSS data. At 606, the process updates the GNSS fix information (short-term average 124 and long-term average 126) using the current GNSS fix. For example, in FIG. 1, the sensor 120 of the IOT device 102(1) may receive GNSS data 168 (e.g., from a satellite) or spoofed data 112 and use the GNSS data 168 to determine a current fix. The IOT device 102(1) may retrieve fixes 121 including a current fix and a previously determined fix. The IOT device 102(1) may also retrieve the short-term average 124 and long-term average 126. The spoofed data 112 may include a spoofed constellation, a spoofed frequency, or both.

[0092] At 608, the process may determine the difference between the short-term average of the GNSS fix and the long-term average of the GNSS fix and the HEPE. At 610, the process may determine whether one or more criteria are met. If the process determines at 610 that the criteria are not met, the process proceeds to 602 to acquire additional GNSS data 168. For example, in FIG. 1, the IOT device 102(1) uses the fix 121 to determine the short-term average of the GNSS fix 124 and the long-term average of the GNSS fix 126 and to determine the HEPE 123. If the process determines that the criteria 128 (e.g., 310 in FIG. 3) are not met, the process acquires additional GNSS data 168 and determines additional fixes.

[0093] If the process determines at 610 that the criteria are met, the process proceeds to 612. At 612, the process may send a warning message to the server (and possibly to the user equipment device). For example, in FIG. 1, if the process determines that the criteria 128 (e.g., 208, 210, 212 in FIG. 2) are met, the process sends a message 130 to the server 104 to alert the server 104 that spoofing may be occurring. In some cases, the IOT device 102(1) may send an alert 150 to one or more of the user equipment 108. For example, if the IOT device 102(1) cannot communicate with the server 104, the IOT device 102(1) may send an alert 150 to at least the user equipment 108 located in the sub-region 154 in which the IOT device 102 is located.

[0094] At 614, the process may receive a spoofing alert from the server and perform one or more actions. For example, in FIG. 1, the IOT device 102(1) receives a spoofing alert 146 from the server 104. The spoofing alert 146 may provide details about the spoofed data 112, such as, for example, in which sub-area (e.g., sub-area 154) the spoofed data 112 is being broadcast, the frequency at which the spoofed data 112 is being broadcast, and other details about the spoofed data 112. In response, the IOT device 102(1) may perform one or more actions, such as, for example, not including the spoofed data 112 when determining a long-term average. The IOT device 102(1) may continue to monitor the spoofed data 112 to determine when the spoofing ends. For example, the IOT device 102(1) may continue to send messages 130 while the spoofed data 112 is being broadcast. The IOT device 102(1) may stop updating the long-term average so that the long-term average is not affected by the spoofed data 112 and is accurate enough to serve as a reference position.

[0095] At 616, the process may receive instructions from the server and implement the instructions. For example, in FIG. 1, in response to receiving instructions 148 from the server 104, the IOT device 102(1) may not update the long-term average 126 using the current GNSS fix, discard the spoofed data 112 based on the information provided in the spoof alert 146, not generate any additional messages in the messages 130, disable navigation sensors in the sensors 120, power down the IOT device 102(1), perform another action, or any combination thereof.

[0096] Thus, an IOT device (e.g., a stationary IOT device) receives GNSS data and determines a current fix based on the GNSS data. The IOT device uses the current fix and the previously determined fix to determine a difference between a short-term average of the fix and a long-term average of the fix. If the difference is greater than the first threshold and the difference for the HEPE is greater than the second threshold for a period of time (e.g., duration) greater than a third threshold, the IOT device may determine that spoofing is occurring and send a message to the server indicating spoofing. The message to the server may include the fix, the short-term average of the fix, the long-term average of the fix, the difference between the short-term average and the long-term average of the fix, the HEPE, other data, or any combination thereof.

[0097] 7 illustrates an example process 700 that includes performing an analysis to determine whether spoofed GNSS data is being received by a device, according to an aspect of the disclosure. Process 700 may be performed by server 104 of FIG.

[0098] At 702, the process receives warning messages from selected IOT devices. At 704, the process may determine the number of IOT devices sending warning messages. At 706, the process may determine the location (e.g., sub-area) of each IOT device. At 708, the process may determine the length of time each IOT device has been sending warning messages. At 710, the process may determine the movement patterns of each IOT device. At 712, the process may perform an analysis to determine whether the analysis indicates that spoofing is present. If the process determines at 712 that the analysis indicates "no" (no spoofing is present), the process may determine at 714 that the particular IOT device is defective and take one or more actions. The process may proceed back to 702 to receive additional warning messages from the selected IOT device. For example, in FIG. 1, the server 104 selects a subset 152 of devices (from the IOT devices 102) based on one or more criteria (e.g., 302 and 304 in FIG. 3) when spoofing is not present. The server 104 ignores messages 130 received from the IOT devices 102 that are not included in the subset 152 of devices. After the server 104 receives messages 130 from each device in the subset 152 of devices, the server 104 may perform an analysis including determining the number of IOT devices sending alert messages, determining the location of each IOT device sending alert messages, determining the length of time each IOT device has been sending alert messages, and determining the movement patterns of each IOT device. The server 104 may determine whether the result of the analysis meets one or more criteria (e.g., 306, 308, 310, and 312 in FIG. 3). If the server 104 determines that the results of the analysis indicate that not all of the criteria have been met, the server 104 may determine that the particular IOT device of the IOT devices 102 sending the warning message 130 is defective.In response, the server 104 may remove the particular IOT device from the subset of monitored IOT devices and, in some cases, send instructions 148 to the particular IOT device. The instructions 148 may instruct the particular IOT device to disable a potentially malfunctioning sensor (e.g., a navigation sensor), power down the IOT device, stop sending messages 130, or perform another action.

[0099] If the analysis indicates "yes" (spoofing exists), the process may proceed to 716. At 716, the process may determine details about the spoofed GNSS data, such as which frequencies are being used by the spoofer, which constellations are being used by the spoofer, and other information related to the spoofed GNSS data. At 718, the process may determine in which sub-area spoofing is occurring, a threat level associated with the spoofing, a confidence level associated with the determination that spoofing is occurring, the location of the spoofer, and other spoofing-related information. At 720, the process may send a spoofing alert message to the IOT device and the user equipment (UE) device. For example, in FIG. 1, if the server 104 determines that the results of the analysis meet certain criteria (e.g., 306, 308, 310, and 312 in FIG. 3), the server 104 may send a spoofing alert 146 to the IOT device 102 and the user equipment 108. The spoofing alert 146 may provide details about the spoofed data 112 to enable the IOT device 102 and the user equipment 108 to ignore the spoofed data 112. For example, the details may include which frequency is used by the spoofer, or which constellation is used by the spoofer, or other details to enable the IOT device 102 and the user equipment 108 to ignore the spoofed data 112. In this manner, the user equipment 108 avoids the potentially disastrous consequences of using the spoofed data 112 (e.g., incorrect navigation causing an accident, arriving at a wrong destination, etc.). The server 104 may determine in which sub-region the spoofed data 112 is present, a threat level associated with the spoofed data 112, a confidence level associated with the determination that the spoofed data 112 is present, the location of the spoofer 110, and other information associated with the spoofed data 112 and the spoofer 110.

[0100] Thus, when GNSS spoofing is not occurring, the server selects a subset of IOT devices to create a selected subset of IOT devices. When an IOT device sends a warning message to the server indicating possible spoofing, the server analyzes the warning messages sent by the IOT devices in the selected subset and ignores messages sent by IOT devices not included in the selected subset. Based on the warning messages sent by the selected subset of IOT devices, the server performs an analysis to determine information such as, for example, how many IOT devices in the subset of IOT devices are sending warning messages, the ratio of IOT devices sending warning messages to the number of selected IOT devices, the number of IOT devices sending warning messages located in a particular sub-region of the region (e.g., a neighborhood of a city), whether an IOT device has been sending warning messages for more than a threshold amount of time, etc. The server may determine whether spoofing is occurring based on whether this information satisfies a set of spoofing conditions.

[0101] 8 illustrates an example process 800 including receiving a spoofing alert according to an aspect of the disclosure. Process 800 may be performed by an individual one of the user equipment (UE) 108 of FIG.

[0102] At 802, the process may receive a spoofing alert message. At 804, the process may retrieve from the spoofing alert the location (of the spoofer), the frequency (used to transmit the spoofed data), and the constellation associated with the spoofing. At 806, the process may determine whether the UE is close enough to the location of the spoofer to receive the spoofed data. If a determination is made at 806 of "no" (the UE is not close enough to the spoofer to receive the spoofed data), the process returns to 802. For example, in FIG. 1, the user equipment 108(1) may receive a spoofing alert 146 from the server 104 or an alert 150 from one of the IOT devices 102. The user equipment 108(1) may retrieve data associated with the spoofing (e.g., from the alert 146 or the alert 150), such as the location of the spoofer, the frequency (used to transmit the spoofed data), and the constellation associated with the spoofing. If user equipment 108(1) determines that the location of the spoofer 110 is far enough from user equipment 108(1) that the user equipment 108(1) cannot receive the spoofed data 112, then user equipment 108(1) may continue to use the available GNSS data 168.

[0103] If a determination is made at 806 of "yes" (the UE is close enough to the spoofer to receive spoofed data), the process proceeds to 808. At 808, the process ignores at least a portion of the available GNSS data. At 810, the process may use an alternative positioning mechanism. For example, in FIG. 1, if user equipment 108(1) determines that spoofer 110 is close enough that user equipment 108(1) can receive spoofed data 112, user equipment 108(1) may ignore spoofed data 112. User equipment 108(1) may use an alternative mechanism to determine its position / location. For example, user equipment 108(1) may use a position determined prior to receiving alert 146 or alert 150, along with sensor data from other sensors (e.g., gyroscope, accelerometer, magnetic compass, mapping sensors, etc.) to extrapolate a current position based on the previously determined position and sensor data.

[0104] At 812, the process may determine whether a stop spoofing message has been received. If the process determines at 812 that a stop spoofing message has not been received, the process proceeds back to 810. If the process determines at 812 that a stop spoofing message has been received, the process proceeds to 814. At 814, the process resumes using the available GNSS data. For example, in FIG. 1, the user equipment 108(1) may continue to ignore the spoofed data 112 until the server 104 sends a stop spoofing 156 message indicating that the spoofed data 112 is no longer present.

[0105] FIG. 9 illustrates a device 900 for implementing a server 104, an IOT device 102, or a UE 108 according to an aspect of the disclosure. The device 900 may include one or more processors 902 (e.g., CPU, GPU, etc.), memory 904, a communication interface 906, a display device 908, other input / output (I / O) devices 910 (e.g., keyboard, trackball, etc.), and one or more mass storage devices 912 (e.g., disk drive, solid state disk drive, etc.), configured to communicate with each other via one or more system buses 914 or other suitable connections, etc. Although a single system bus 914 is illustrated for ease of understanding, it should be understood that the system bus 914 may include multiple buses, such as a memory device bus, a storage device bus (e.g., Serial ATA (SATA), etc.), a data bus (e.g., Universal Serial Bus (USB), etc.), a video signal bus (e.g., THUNDERBOLT®, DVI, HDMI®, etc.), a power bus, etc.

[0106] The processor 902 is one or more hardware devices that may include a single processing unit or several processing units, all of which may include single or multiple computing units or multiple cores. The processor 902 may include a graphics processing unit (GPU) integrated into the CPU, or the GPU may be a processor device separate from the CPU. The processor 902 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, graphics processing units, state machines, logic circuitry, and / or any device that manipulates signals based on operational instructions. Among other capabilities, the processor 902 may be configured to fetch and execute computer-readable instructions stored in the memory 904, mass storage device 912, or other computer-readable medium.

[0107] The memory 904 and the mass storage device 912 are examples of computer storage media (e.g., memory storage devices) for storing instructions that may be executed by the processor 902 to perform various functions described herein. For example, the memory 904 may include both volatile and non-volatile memory (e.g., RAM, ROM, etc.) devices. Additionally, the mass storage device 912 may include hard disk drives, solid state drives, removable media including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CDs, DVDs), storage arrays, network attached storage, storage area networks, etc. Both the memory 904 and the mass storage device 912 may be collectively referred to herein as memory or computer storage media, and may be any type of non-transitory medium capable of storing computer-readable processor-executable program instructions as computer program code that may be executed by the processor 902 as a particular machine configured to perform the operations and functions described in the implementations herein.

[0108] The device 900 may include one or more communication interfaces 906 for exchanging data. The communication interface 906 can facilitate communication within a wide variety of network and protocol types, including wired networks (e.g., Ethernet, DOCSIS, DSL, fiber, USB, etc.) and wireless networks (e.g., WLAN, GSM, CDMA, 802.11, Bluetooth, wireless USB, ZigBee, cellular, satellite, etc.), the Internet, etc. The communication interface 906 can also provide communication with external storage, such as a storage array, network attached storage, storage area network, cloud storage, etc.

[0109] The display device 908 may be used to display content (e.g., information and images) to a user. The other I / O devices 910 may be devices that receive various inputs from and provide various outputs to a user, and may include a keyboard, a touchpad, a mouse, a printer, audio input / output devices, etc.

[0110] Computer storage media, such as memory 904 and mass storage device 912, may be used to store software and data. For example, computer storage media may be used to store spoof detector 132, analysis module 133, conditions 134, machine learning 136, threat levels 140 (including confidence levels), database 142, network management 144, other applications 916, and other data 918.

[0111] 10A and 10B, several example components (represented by corresponding blocks) are shown that may be incorporated in a UE, a base station (which may correspond to any of the base stations described herein), and a network entity (which may correspond to or embody any of the network functions described herein) to support file transmission operations. It will be appreciated that these components may be implemented in different types of devices in different implementations (e.g., in an ASIC, in a system on a chip (SoC), etc.). The illustrated components may also be incorporated in other devices in a communication system. For example, other devices in the system may include components similar to the described components to provide similar functionality. Also, a given device may include one or more of the components. For example, a device may include multiple transceiver components that enable the device to operate on multiple carriers and / or communicate via different technologies.

[0112] A UE, base station, or network entity may include a wireless wide area network (WWAN) transceiver 1010 and 1050, respectively, configured to communicate via one or more wireless communications networks (not shown), such as an NR network, an LTE network, a GSM network, etc. The WWAN transceivers 1010 and 1050 may be connected to one or more antennas 1016 and 1056, respectively, to communicate with other network nodes, such as other UEs, access points, base stations (e.g., eNBs, gNBs), etc., via at least one designated RAT (e.g., NR, LTE, GSM, etc.) over a wireless communications medium of interest (e.g., some set of time / frequency resources in a particular frequency spectrum). The WWAN transceivers 1010 and 1050 may be variously configured to transmit and encode signals 1018 and 1058 (e.g., messages, instructions, information, etc.), respectively, and conversely, to receive and decode signals 1018 and 1058 (e.g., messages, instructions, information, pilots, etc.), respectively, in accordance with the designated RAT. In particular, the transceivers 1010 and 1050 include one or more transmitters 1014 and 1054, respectively, for transmitting and encoding signals 1018 and 1058, respectively, and include one or more receivers 1012 and 1052, respectively, for receiving and decoding the signals 1018 and 1058, respectively.

[0113] The UE and base station also, at least in some cases, include wireless local area network (WLAN) transceivers 1020 and 1060, respectively. The WLAN transceivers 1020 and 1060 may be connected to one or more antennas 1026 and 1066, respectively, for communicating with other network nodes, such as other UEs, access points, base stations, etc., via at least one designated RAT (e.g., WiFi, LTE-D, Bluetooth, etc.) over a wireless communication medium of interest. The WLAN transceivers 1020 and 1060 may be variously configured to transmit and encode signals 1028 and 1068, respectively (e.g., messages, instructions, information, etc.), and conversely, to receive and decode signals 1028 and 1068, respectively (e.g., messages, instructions, information, pilots, etc.), in accordance with the designated RAT. In particular, the transceivers 1020 and 1060 include one or more transmitters 1024 and 1064, respectively, for transmitting and encoding signals 1028 and 1068, respectively, and include one or more receivers 1022 and 1062, respectively, for receiving and decoding the signals 1028 and 1068, respectively.

[0114] The transceiver circuitry including at least one transmitter and at least one receiver may in some implementations comprise an integrated device (e.g., embodied as transmitter and receiver circuits of a single communications device), in some implementations comprise separate transmitter devices and separate receiver devices, and in other implementations may be embodied in other manners. In one aspect, the transmitter may include or be coupled to multiple antennas, such as an antenna array (e.g., antennas 1016, 1026, 1056, 1066), that enable each device to perform transmit "beamforming" as described herein. Similarly, the receiver may include or be coupled to multiple antennas, such as an antenna array (e.g., antennas 1016, 1026, 1056, 1066), that enable each device to perform receive beamforming as described herein. In one aspect, the transmitters and receivers may share the same multiple antennas (e.g., antennas 1016, 1026, 1056, 1066) such that each device can only receive or transmit at a given time, but not both at the same time. The UE and / or base station wireless communication devices (e.g., one or both of the transceivers 1010 and 1020 and / or 1050 and 1060) may also comprise a network listen module (NLM), etc. for performing various measurements.

[0115] The UE and base station may, at least in some cases, include satellite positioning system (SPS) receivers 1030 and 1070. The SPS receivers 1030 and 1070 may be connected to one or more antennas 1036 and 1076, respectively, for receiving SPS signals 1038 and 1078, respectively, such as Global Positioning System (GPS) signals, Global Navigation Satellite System (GLONASS) signals, Galileo signals, Beidou signals, Navigation Satellite System of India (NAVIC), Quasi-Zenith Satellite System (QZSS), etc. The SPS receivers 1030 and 1070 may comprise any suitable hardware and / or software for receiving and processing the SPS signals 1038 and 1078, respectively. The SPS receivers 1030 and 1070 appropriately request information and actions from other systems and perform the necessary calculations to determine the position of the UE and base station using measurements obtained by any suitable SPS algorithms.

[0116] The base station and the network entities may each include at least one network interface 1080 for communicating with other network entities. For example, the network interface 1080 (e.g., one or more network access ports) may be configured to communicate with one or more network entities via a wire-based or wireless backhaul connection. In some aspects, the network interface 1080 may be implemented as a transceiver configured to support wire-based or wireless signal communication. This communication may involve, for example, sending and receiving messages, parameters, and / or other types of information.

[0117] The UE, base station, and network entities may include other components that may be used in conjunction with operations as disclosed herein. The UE may include processor circuitry implementing a processing system 1052, for example, for providing functionality related to RF sensing and for providing other processing functions. The base station may include a processing system 1084, for example, for providing functionality related to RF sensing and for providing other processing functions as disclosed herein. The network entities may include processing systems, for example, for providing functionality related to Wi-Fi radar or RF sensing as disclosed herein and for providing other processing functions. In an aspect, the processing systems 1052, 1084 may include, for example, one or more general-purpose processors, multi-core processors, ASICs, digital signal processors (DSPs), field programmable gate arrays (FPGAs), or other programmable logic devices or processing circuitry.

[0118] The UE, base station, and network entity may include memory circuitry implementing memory components 1040, 1086 (e.g., each including a memory device) for maintaining information (e.g., information indicative of reserved resources, thresholds, parameters, etc.). In some cases, the UE, base station, and network entity may include radar components 1042, 1088, respectively. The radar components 1042, 1088 may be hardware circuits that are part of or coupled to the processing systems 1052, 1084, respectively, that, when executed, cause the UE, base station, and network entity to perform the functions described herein. In other aspects, the radar components 1042, 1088 may be external to the processing systems 1052, 1084 (e.g., may be part of a modem processing system, may be integrated with another processing system, etc.). Alternatively, the radar components 1042, 1088 may be memory modules stored in memory components 1040, 1086, respectively (as shown in FIGS. 10A, 10B) that, when executed by the processing systems 1052, 1084 (or a modem processing system, another processing system, etc.), cause the UE, base station, and network entities to perform the functions described herein.

[0119] The UE may include one or more sensors 1044 coupled to the processing system 1052 to provide motion and / or orientation information independent of motion data derived from signals received by the WWAN transceiver 1010, the WLAN transceiver 1020, and / or the SPS receiver 1030. By way of example, the sensors 1044 may include an accelerometer (e.g., a microelectromechanical system (MEMS) device), a gyroscope, a geomagnetic sensor (e.g., a compass), an altimeter (e.g., a barometric altimeter), and / or any other type of motion detection sensor. Additionally, the sensors 1044 may include multiple different types of devices and combine their outputs to provide motion information. For example, the sensors 1044 may use a combination of a multi-axis accelerometer and an orientation sensor to provide the ability to calculate a position in a 2D and / or 3D coordinate system.

[0120] Additionally, the UE may include a user interface 1046 for providing instructions (e.g., audio and / or visual instructions) to a user and / or receiving user input (e.g., upon user actuation of a sensing device such as a keypad, touch screen, microphone, etc.) Although not shown, base stations and network entities may also include user interfaces.

[0121] Referring more particularly to the processing system 1084, on the downlink, IP packets from a network entity may be provided to the processing system 1084. The processing system 1084 may implement functionality for an RRC layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, and a Medium Access Control (MAC) layer. The processing system 1084 may provide RRC layer functions associated with broadcasting of system information (e.g., Master Information Block (MIB), System Information Block (SIB)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-RAT mobility, and measurement configuration for UE measurement reporting; PDCP layer functions associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with transfer of upper layer packet data units (PDUs), error correction through automatic repeat request (ARQ), concatenation, segmentation, and reassembly of RLC service data units (SDUs), re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel prioritization.

[0122] The transmitter 1054 and receiver 1052 may implement Layer 1 functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection on the transport channel, forward error correction (FEC) coding / decoding of the transport channel, interleaving, rate matching, mapping onto the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The transmitter 1054 handles mapping to signal constellations based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an orthogonal frequency division multiplexing (OFDM) subcarrier, multiplexed with reference signals (e.g., pilots) in the time and / or frequency domain, and then combined together using an inverse fast Fourier transform (IFFT) to generate a physical channel carrying the time-domain OFDM symbol stream. The OFDM symbol stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimates may be derived from a reference signal and / or channel condition feedback transmitted by the UE. Each spatial stream may then be provided to one or more different antennas 1056. The transmitter 1054 may modulate an RF carrier with each spatial stream for transmission.

[0123] At the UE, the receiver 1012 receives the signal through its respective antenna 1016. The receiver 1012 recovers the information demodulated onto the RF carrier and provides the information to the processing system 1052. The transmitter 1014 and the receiver 1012 implement Layer 1 functions associated with various signal processing functions. The receiver 1012 may perform spatial processing on the information to recover any spatial streams destined for the UE. If multiple spatial streams are destined for the UE, they may be combined by the receiver 1012 into a single OFDM symbol stream. The receiver 1012 then converts the OFDM symbol stream from the time domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and decoded by determining the signal constellation points that were most likely transmitted by the base station. These soft decisions may be based on channel estimates calculated by a channel estimator. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by the base station on the physical channel. The data and control signals are then provided to a processing system 1052 that implements Layer 3 and Layer 2 functions.

[0124] In the uplink, the processing system 1052 performs demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the core network. The processing system 1052 is also responsible for error detection.

[0125] Similar to the functionality described with respect to downlink transmission by the base station, the processing system 1052 provides RRC layer functionality associated with system information (e.g., MIBs, SIBs) acquisition, RRC connection, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with transfer of upper layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via hybrid automatic repeat request (HARQ), priority handling, and logical channel prioritization.

[0126] Channel estimates derived by the channel estimator from a reference signal or feedback transmitted by the base station may be used by the transmitter 1014 to select an appropriate coding and modulation scheme and to facilitate spatial processing. The spatial streams generated by the transmitter 1014 may be provided to different antennas 1016. The transmitter 1014 may modulate an RF carrier with each spatial stream for transmission.

[0127] The uplink transmission is processed at the base station in a manner similar to that described for the receiver function at the UE. The receiver 1052 receives the signal through its respective antenna 1056. The receiver 1052 recovers the information demodulated onto the RF carrier and provides the information to the processing system 1084.

[0128] In the uplink, the processing system 1084 performs demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the UE. The IP packets from the processing system 1084 may be provided to the core network. The processing system 1084 is also responsible for error detection.

[0129] For convenience, the UE, base station, and / or network entities are illustrated in Figures 10A-10B as including various components that may be configured in accordance with various examples described herein, however, it will be appreciated that the illustrated blocks may have different functionality in different designs.

[0130] The various components of the UE, base station, and network entity may communicate with each other via data buses 1054, 1082, respectively. The components of FIG. 10A, 10B may be implemented in various ways. In some implementations, the components of FIG. 10A, 10B may be implemented in one or more circuits, such as, for example, one or more processors and / or one or more ASICs (which may include one or more processors). Here, each circuit may use and / or incorporate at least one memory component for storing information or executable code used by the circuit to provide this functionality. For example, some or all of the functionality represented by blocks 1010-1046 may be implemented by the processor and memory components of the UE (e.g., by execution of appropriate code and / or by appropriate configuration of the processor components). Similarly, some or all of the functionality represented by blocks 1050-1088 may be implemented by the processor and memory components of the base station (e.g., by execution of appropriate code and / or by appropriate configuration of the processor components). For simplicity, various operations, acts, and / or functions are described herein as being performed "by a UE," "by a base station," "by a positioning entity," etc. However, it will be appreciated that such operations, acts, and / or functions may actually be performed by a particular component or combination of components, such as a UE, a base station, a positioning entity, such as processing systems 1052, 1084, transceivers 1010, 1020, 1050, and 1060, memory components 1040, 1086, radar components 1042, 1088, etc.

[0131] It may be noted that although particular frequencies, integrated circuits (ICs), hardware, and other features are described in the embodiments herein, alternative embodiments may vary. That is, alternative embodiments may utilize additional or alternative frequencies (e.g., other than the 60 GHz and / or 28 GHz frequency bands), antenna elements (e.g., having different sizes / shapes of antenna element arrays), scanning periods (including both static and dynamic scanning periods), electronic devices (e.g., WLAN APs, cellular base stations, smart speakers, IOT devices, mobile phones, tablets, personal computers (PCs), etc.), and / or other features. Those skilled in the art will appreciate such variations.

[0132] It should be understood that any reference to an element herein using a designation such as "first," "second," etc., does not generally limit the quantity or order of those elements. Rather, these designations may be used herein as a convenient way of distinguishing between two or more elements or instances of an element. Thus, a reference to a first element and a second element does not imply that only two elements may be used therein, or that the first element must precede the second element in some manner. Also, unless otherwise stated, a set of elements may comprise one or more elements. In addition, as used herein or in the claims, a term of the form "at least one of A, B, or C" or "one or more of A, B, or C" or "at least one of the group consisting of A, B, and C" means "A or B or C or any combination of these elements." For example, the term may include A, or B, or C, or A and B, or A and C, or A and B and C, or 2A, or 2B, or 2C, etc.

[0133] In light of the above description and explanations, those skilled in the art will appreciate that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0134] Thus, for example, it will be appreciated that a device or any component of a device may be configured (or enabled or adapted) to provide functionality as taught herein. This may be accomplished, for example, by manufacturing (e.g., fabricating) the device or component to provide the functionality, by programming the device or component to provide the functionality, or by using some other suitable implementation technique. As one example, an integrated circuit may be fabricated to provide the required functionality. As another example, an integrated circuit may be fabricated to support the required functionality and then configured (e.g., via programming) to provide the required functionality. As yet another example, a processor circuit may execute code to provide the required functionality.

[0135] Furthermore, the methods, sequences, and / or algorithms described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a random access memory (RAM), a flash memory, a read only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral to the processor (e.g., a cache memory).

[0136] In the above detailed description, it is seen that different features are grouped together in the examples. This mode of disclosure should not be understood as an intention that the exemplary clauses have more features than are expressly stated in each clause. Rather, various aspects of the disclosure may include fewer than all features of each individual exemplary clause disclosed. Thus, the following clauses should be considered to be incorporated into the description hereby, and each clause may stand alone as a separate example. Although each dependent clause in a clause may refer to a specific combination with one of the other clauses, the aspects of that dependent clause are not limited to that specific combination. It will be appreciated that other exemplary clauses may also include combinations of aspects of the dependent clause with the subject matter of any other dependent clause or independent clause, or combinations of any features with other dependent clauses and independent clauses. Various aspects disclosed herein expressly include these combinations, unless it is expressly expressed or can be easily inferred that a particular combination is not intended (e.g., contradictory aspects such as defining an element as both an insulator and a conductor). It is further contemplated that aspects of a clause may be included in any other dependent clause, even if the clause is not directly dependent on an independent clause. Example implementations are described in the numbered clauses below.

[0137] Clause 1. A method of operating a server, the method comprising: receiving an alert message from a monitored device in a set of monitored devices, the alert message including Global Navigation Satellite System (GNSS) measurement data; determining whether a spoofed GNSS condition exists based at least in part on analysis of the GNSS measurement data; and sending a spoof alert message to one or more user equipment (UE) based on the determination.

[0138] Clause 2. The method of clause 1, wherein either a spoofed GNSS condition is determined to be absent and the spoof alert message provides an indication that a spoofed GNSS condition does not exist, or a spoofed GNSS condition is determined to be present and the spoof alert message provides an indication that a spoofed GNSS condition exists.

[0139] Clause 3. The method of clause 2, wherein the step of determining that a spoofed GNSS condition exists includes the steps of determining that a number of monitored devices sending warning messages is greater than a number threshold, determining that a percentage of the number of monitored devices sending warning messages to a total number of monitored devices is greater than a percentage threshold, determining that a size of a sub-region from which the monitored devices are sending warning messages is greater than a size threshold, and determining that a length of time over which the monitored devices are sending warning messages is greater than a time threshold.

[0140] Clause 4. The method of clause 3, wherein the spoof alert message includes at least one of a spoofed constellation used by the spoofed GNSS signal and a frequency used by the spoofed GNSS signal.

[0141] Clause 5. The method of any of clauses 2-4, wherein determining that there is no spoofed GNSS condition includes determining that a difference between a short-term average of the GNSS fixes and a long-term average of the GNSS fixes is less than a difference threshold for a number of sets of monitored devices when the percentage of the total number of sets of monitored devices is greater than a percentage threshold.

[0142] Clause 6. The method of any of clauses 1-5, further comprising the steps of determining that there are no spoofed GNSS conditions, determining that for a particular device of the plurality of devices, a difference between a short-term average of a first plurality of global navigation satellite system fixes and a long-term average of a second plurality of global navigation satellite system fixes is less than or equal to a difference threshold and a horizontal estimated position error is less than or equal to an error threshold, and including the particular device in the set of monitored devices.

[0143] Clause 7. The method of any of clauses 1-6, wherein the alert message includes a short-term average of a first plurality of GNSS fixes determined by the monitored device, a long-term average of a second plurality of GNSS fixes determined by the monitored device, a difference between the short-term average and the long-term average, and a horizontal estimated position error determined by the monitored device.

[0144] Clause 8. The method of any of clauses 1-7, further comprising the steps of receiving a second warning message from a second monitored device in the set of monitored devices, the second warning message including second GNSS measurement data; determining that the second monitored device is defective based at least in part on the second GNSS measurement data; and excluding the second monitored device from the set of monitored devices.

[0145] Clause 9. The method of clause 8, further comprising the step of sending instructions to the second monitored device, the instructions including one of a first instruction for disabling a navigation sensor of the second monitored device or a second instruction for transitioning the second monitored device into a low power mode.

[0146] Clause 10. The method of any of clauses 1 to 9, further comprising the steps of: determining a weighted average of long-term averages of GNSS fixes for each monitored device sending the warning message, the weight for each device being based on a difference between a short-term average of GNSS fixes determined by the monitored device sending the warning message and a long-term average of GNSS fixes determined by the monitored device sending the warning message; and determining a rough location of a spoofer transmitting a spoofed GNSS signal based on the weighted average of the long-term averages of GNSS fixes.

[0147] Clause 11. A method of operating a device, comprising: measuring one or more Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data; determining that one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied; and sending a warning message associated with the GNSS measurement data to a server to alert the server of potential GNSS spoofing.

[0148] Clause 12. The method of clause 11, wherein determining that one or more GNSS spoofing criteria associated with the GNSS measurement data are met comprises determining a current GNSS fix based on the one or more GNSS signals; updating the GNSS fix data to include the current GNSS fix; determining a short-term average of the GNSS fix based on the GNSS fix data; determining a long-term average of the GNSS fix based on the GNSS fix data; determining a difference between the short-term average of the GNSS fix and the long-term average of the GNSS fix; determining that the difference meets a first threshold for at least a particular duration; determining a horizontal estimated position error (HEPE) based on the current GNSS fix; and determining that the HEPE meets a second threshold for at least a particular duration.

[0149] Clause 13. A method as claimed in clause 12, in which the short-term average of the GNSS fixes is determined over a time period of from 10 seconds to 60 seconds.

[0150] Clause 14. Any of the methods of clauses 12 to 13, in which the long-term average of GNSS fixes is determined for a time period ranging from 1 to 30 days.

[0151] Clause 15. The method of any of clauses 11 to 14, further comprising the step of receiving a spoof alert message from the server indicating the presence of a spoofed GNSS signal.

[0152] Clause 16. The method of clause 15, wherein the spoofing alert message includes at least one of a frequency associated with the spoofed signal or a constellation associated with the spoofed signal.

[0153] Clause 17. Any of the methods of clauses 15 to 16, further comprising the step of ignoring spoofed GNSS signals.

[0154] Clause 18. The method of any of clauses 15 to 17, further comprising the steps of determining that one or more user equipment (UE) are receiving a spoofed GNSS signal, and sending a spoofing alert message to at least one of the one or more UEs.

[0155] Clause 19. The method of any of clauses 11-18, further comprising receiving instructions from the server to perform at least one of taking a particular sensor associated with the device offline, ceasing to send alert messages to the server, or powering off the device.

[0156] Clause 20. A method of operating a user equipment, comprising: receiving a spoof alert message including an indication that a spoofed Global Navigation Satellite System (GNSS) condition exists, a location of a spoofer broadcasting the spoofed GNSS signal, and an indication of a spoofed zone; determining that the spoof alert message indicates that a spoofed GNSS condition exists; determining a location of the spoofer broadcasting the spoofed GNSS signal based on the spoof alert message; determining that the user equipment is within a reception area of ​​the spoofed GNSS signal based on the location of the spoofer and a current location of the user equipment; and determining a position of the user equipment without using the spoofed GNSS signal.

[0157] Clause 21. The method of clause 20, wherein the spoofing alert message includes one or more constellations associated with the spoofed GNSS signal.

[0158] Clause 22. Any of the methods of clauses 20 to 21, wherein the spoofing alert message includes one or more frequencies associated with the spoofed GNSS signal.

[0159] Clause 23. The method of any of clauses 20-22, wherein determining a position of the user equipment without using the spoofed GNSS signal includes retrieving a previously determined position determined before receiving the spoof alert message; determining sensor data from one or more sensors of the user equipment, the one or more sensors including a magnetometer, a gyroscope, and an accelerometer; and determining a current position of the user equipment based at least in part on the previously determined position and the sensor data.

[0160] Clause 24. The method of any of clauses 20 to 23, further comprising determining a position of the user equipment using the one or more GNSS signals based on a determination that the spoofing alert message indicates an absence of a spoofed GNSS condition.

[0161] Clause 25. An apparatus comprising a memory, at least one transceiver, and at least one processor communicatively coupled to the memory and the at least one transceiver, wherein the memory, the at least one transceiver, and the at least one processor are configured to perform a method according to any of clauses 1 to 24.

[0162] Clause 26. Apparatus comprising means for carrying out the method according to any of clauses 1 to 24.

[0163] Clause 27. A non-transitory computer-readable medium storing computer-executable instructions, the computer-executable instructions including at least one instruction for causing a computer or processor to perform a method according to any of clauses 1 to 24.

[0164] While the above disclosure sets forth various exemplary aspects, it should be noted that various changes and modifications may be made to the illustrated examples without departing from the scope defined by the appended claims. The present disclosure is not limited to only the specifically illustrated examples. For example, unless otherwise stated, the functions, steps, and / or actions of the method claims according to the aspects of the present disclosure described herein need not be performed in any particular order. Furthermore, although some aspects may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. [Explanation of symbols]

[0165] 100 Systems 102, 102(1), 102(N) Internet of Things (IOT) devices, IOT devices 104 Server 106 Network 108, 108(1), 108(M) User Equipment (UE), UE 110 Spoofer 112 Data 114 Navigation Sensor 115 Wireless Transceiver 116 Sensors 118, 118(1), 118(N) Location 120 Sensors 121 Fix 122 Spoof Checker 123 Horizontal estimated position error (HEPE), HEPE 124 Short Term Average, ST AVG, Average, Short Term Average of GNSS Fixes 126 Long Term Average, LT AVG, Average, Long Term Average of GNSS Fixes 128 Standard 130 Messages 132 Spoof Detector 133 Analysis Module 134 Conditions 136 Machine Learning 138 sub-areas Threat Level 140 141 Trust Level 142 Database 144 Network Management 146 Spoofing Alert 148 Command 150 alarm A subset of 152 devices 154 sub-areas 156 Spoofing Stop 166 Spoofer Location 168 GNSS data 170 GNSS signal source 200 Wireless Communication System 202 Base station, macrocell base station 202' Small Cell (SC) Base Station 204UE 210, 210' Geographical Coverage Area 212 Space Vehicle (SV), SV 220 Communication Links 222 Backhaul Link 224 SPS signal 234 Backhaul Link 250 WLAN Access Points (APs), WLAN APs 252 Wireless Local Area Network (WLAN) Station (STA), WLAN STA 254 Communication Links 264 UE 270 Core Network 272 Location Server 280 mmW base station, base station 282 U.S. 284 mmW communication link 290 UE 292 D2D P2P links 294 D2D P2P links 300 processes 400 processes 500 processes 600 processes 700 processes 800 processes 900 devices 902 Processor 904 Memory 906 Communication Interface 908 Display Devices 910 Other input / output (I / O) devices, other I / O devices 912 Mass Storage Devices 914 System Bus 916 Other Applications 918 Other Data 1010 Wireless Wide Area Network (WWAN) Transceiver, WWAN Transceiver, Transceiver 1012 Receiver 1014 Transmitter 1016 Antenna 1018 signal 1020 Wireless Local Area Network (WLAN) Transceiver, WLAN Transceiver, Transceiver 1022 Receiver 1024 Transmitter 1026 Antenna 1028 signal 1030 Satellite Positioning System (SPS) receiver, SPS receiver 1036 Antenna 1038 SPS signal 1040 Memory Components 1042 Radar Components 1044 Sensor 1046 User Interface 1050 Wireless Wide Area Network (WWAN) Transceiver, WWAN Transceiver, Transceiver 1052 Processing system, receiver 1054 Data bus, transmitter 1056 Antenna 1058 signal 1060 Wireless Local Area Network (WLAN) Transceiver, WLAN Transceiver, Transceiver 1062 Receiver 1064 Transmitter 1066 Antenna 1068 signal 1070 Satellite Positioning System (SPS) Receiver, SPS Receiver 1076 Antenna 1078 SPS signal 1080 Network Interface 1082 Data Bus 1084 Processing System 1086 Memory Components 1088 Radar Components

Claims

1. 1. A method of operating a server, comprising: receiving an alert message from a monitored device in a set of monitored devices, the alert message including Global Navigation Satellite System (GNSS) measurement data, the alert message comprising: a short-term average of a first plurality of GNSS fixes determined by the monitored device; a long-term average of a second plurality of GNSS fixes determined by the monitored device; and the difference between the short-term average and the long-term average; a horizontal estimated position error determined by the monitored device; and and determining whether a spoofed GNSS condition exists based at least in part on an analysis of the GNSS measurement data from a plurality of monitored devices in the set of monitored devices; sending a spoofing alert message to one or more user equipment (UE) based on the determination whether a spoofed GNSS condition exists; A method comprising:

2. the spoofed GNSS condition is determined to be absent and the spoof alert message provides an indication that the spoofed GNSS condition does not exist; or determining that the spoofed GNSS condition exists, and the spoof alert message providing an indication that the spoofed GNSS condition exists. The method of claim 1.

3. determining that a spoofed GNSS condition exists, determining that a number of monitored devices sending the alert message is greater than a threshold number; determining that a percentage of the number of monitored devices sending the alert message relative to a total number of monitored devices is greater than a percentage threshold; determining that the size of the sub-region to which the monitored device is sending the alert message is greater than a size threshold; determining that the length of time that the monitored device has been sending the alert message is greater than a time threshold; 3. The method of claim 2, comprising:

4. The spoofing warning message comprises: A spoofed constellation used by a spoofed GNSS signal, and / or The frequency used by the spoofed GNSS signal 4. The method of claim 3, comprising:

5. determining that there is no spoofed GNSS condition, for a number of monitored devices in said set of monitored devices that are a percentage of a total number of monitored devices in said set of monitored devices that is greater than a percentage threshold; Short-term average of GNSS fixes and Long-term average of GNSS fixes and The difference between Less than the difference threshold The step of determining 3. The method of claim 2, comprising:

6. determining that the spoofed GNSS condition is absent; For a specific device among multiple devices, A short-term average of the first multiple global navigation satellite system fixes; A long-term average of multiple GNSS fixes and is less than or equal to a difference threshold, The horizontal estimated position error is less than or equal to the error threshold. and determining including the particular device in the set of monitored devices; The method of claim 1, further comprising:

7. receiving a second alert message from a second monitored device in the set of monitored devices, the second alert message including second GNSS measurement data; determining that the second monitored device is defective based at least in part on the second GNSS measurement data; removing the second monitored device from the set of monitored devices; The method of claim 1, further comprising:

8. sending an instruction to the second monitored device, the instruction comprising: a first instruction to disable a navigation sensor of the second monitored device; or A second instruction for transitioning the second monitored device to a low power mode. Steps that include one of 8. The method of claim 7, further comprising:

9. determining a weighted average of long term averages of GNSS fixes for each monitored device sending the alert message, the weights for each device being: a short-term average of GNSS fixes determined by the monitored device sending the alert message; a long-term average of GNSS fixes determined by the monitored device sending the alert message; and and a step based on the difference between determining a coarse location of a spoofer transmitting the spoofed GNSS signal based on the weighted average of the long-term averages of GNSS fixes; The method of claim 1, further comprising:

10. 1. A method of operating a device, comprising: measuring one or more Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data; determining that one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied; sending a warning message associated with the GNSS measurement data to a server to alert the server of a potential GNSS spoofing, the warning message comprising: a short-term average of a first plurality of GNSS fixes determined by the device; and a long-term average of a second plurality of GNSS fixes determined by the device; and the difference between the short-term average and the long-term average; a horizontal estimated position error determined by the device; and Steps A method comprising:

11. determining that the one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied, determining a current GNSS fix based on the one or more GNSS signals; updating GNSS fix data to include the current GNSS fix; determining the short-term average of a GNSS fix based on the GNSS fix data; determining the long-term average of GNSS fixes based on the GNSS fix data; determining the difference between the short term average of GNSS fixes and the long term average of GNSS fixes; determining that the difference meets a first threshold for at least a particular duration; determining the horizontal estimated position error (HEPE) based on the current GNSS fix; determining that the HEPE meets a second threshold for at least the specified duration; The method of claim 10, comprising:

12. The short-term average of GNSS fixes is determined for a time period of from 10 seconds to 60 seconds; and said long-term average of GNSS fixes being determined for a time period ranging from 1 to 30 days; The method of claim 11.

13. A server, Memory, and one or more processors communicatively coupled to the memory, the one or more processors: receiving an alert message from a monitored device in a set of monitored devices, the alert message including Global Navigation Satellite System (GNSS) measurement data, the alert message comprising: a short-term average of a first plurality of GNSS fixes determined by the monitored device; a long-term average of a second plurality of GNSS fixes determined by the monitored device; and the difference between the short-term average and the long-term average; a horizontal estimated position error determined by the monitored device; and receiving the determining whether a spoofed GNSS condition exists based at least in part on an analysis of the GNSS measurement data from a plurality of monitored devices in the set of monitored devices; sending a spoofing alert message to one or more user equipment (UE) based on the determination whether the spoofed GNSS condition exists; A server configured to:

14. The server of claim 13, further configured to execute a method according to any one of claims 2 to 9.

15. A device, comprising: Memory, and one or more processors communicatively coupled to the memory, the one or more processors: measuring one or more Global Navigation Satellite System (GNSS) signals to obtain GNSS measurement data; determining that one or more GNSS spoofing criteria associated with the GNSS measurement data are satisfied; and sending a warning message associated with the GNSS measurement data to a server to alert the server of a potential GNSS spoofing, the warning message comprising: a short-term average of a first plurality of GNSS fixes determined by the device; and a long-term average of a second plurality of GNSS fixes determined by the device; and the difference between the short-term average and the long-term average; a horizontal estimated position error determined by the device; and Including, transmitting A device configured to:

Images