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 particularly 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. Satellite navigation systems with worldwide coverage are called Global Navigation Satellite Systems (GNSS).

[0003] Reliable navigation is important to public safety. GNSS signals used for navigation can be spoofed, causing navigation problems and potentially disastrous consequences for users. Spoofing refers to broadcasting a false (“spoofed”) GNSS signal with the intention that a 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 dive, 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 poor (e.g., noisy) environment. Summary of the Invention [Means for solving the problem]

[0004] The following presents 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 delineate 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 for 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 equipments (UEs).

[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 met, and sending a warning message associated with the GNSS measurement data to a server to alert the server of the 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, based on the spoof alert message, the location of the spoofer broadcasting the spoofed GNSS signal. 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 met, 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 spoof 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 spoof alert message indicates that a spoofed GNSS condition exists. The one or more processors are configured to determine, based on the spoof alert message, a location of the spoofer broadcasting the spoofed GNSS signal. The one or more processors are configured to determine, based on the location of the spoofer and the current location of the user equipment, that the user equipment is within a reception area of ​​the spoofed GNSS signal. 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 met, 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, based on the spoof alert message, a location of the spoofer broadcasting the spoofed GNSS signal. 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 skilled 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 solely for purposes of illustration of the aspects, not limitation thereof. 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(s) 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 explanation 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. [Figure 2] FIG. 1 illustrates an exemplary wireless communication system in accordance with various aspects of the present disclosure. [Figure 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 aspects of the present disclosure. [Figure 5] FIG. 1 illustrates an example process for determining whether a spoofed signal is being broadcast, according to an aspect of the disclosure. [Figure 6] FIG. 10 illustrates an example process including sending a warning message to a server, according to an aspect of the present 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 present disclosure. [Figure 9] FIG. 1 illustrates a communication system according to one 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 communication 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 communication as described herein; DETAILED DESCRIPTION OF THE INVENTION

[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, and security cameras 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 with a short-term average of GNSS fixes. The short-term average of GNSS fixes is an average of the number of fixes determined over a relatively short time period, such as 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 over a relatively long time period, such as between one 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 long-term average 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 or determining a statistical center, 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 that includes the short-term average of the GNSS fix, the long-term average of the GNSS fix, the difference between the long-term and short-term averages 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 demarcation). The server collects data from multiple IoT devices located in the particular geographic region ("region") to determine if the GNSS data is spoofed. The server may perform analysis of alert messages received from multiple IoT devices, such as 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 if position jumps are similar (e.g., due to spoofed ephemeris) or if 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 signals are rebroadcast on the receiving frequencies, typically at a higher power level than the original signals. The server may, in some cases, 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 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 can be used using point positioning (SPP) without using precision improvements used to increase the accuracy of GNSS-derived positioning, such as 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 related 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" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the present disclosure" does not require that all aspects of the present 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, 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 by, for example, elements of a computing device. It will be recognized that the various actions described herein may be performed by particular 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, the sequences of actions described herein may be considered to be embodied entirely in any form of non-transitory computer-readable storage medium having stored therein a corresponding set of computer instructions that, when executed, cause or instruct associated processors of a device to perform the functions described herein. Accordingly, various aspects of the present disclosure may be embodied in several different forms, all of which are contemplated to be within the scope of the claimed subject matter. Additionally, for each aspect 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 to or otherwise limited to any particular radio access technology (RAT) unless otherwise specified. 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 an “access terminal” or “AT,” a “client device,” a “wireless device,” a “subscriber device,” a “subscriber terminal,” a “subscriber station,” a “user terminal” or “UT,” a “mobile device,” a “mobile terminal,” a “mobile station,” or variations thereof. In general, a UE can communicate with a core network via a RAN, through which the UE can 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 Institute of Electrical and Electronics Engineers (IEEE) 802.11, etc.), etc.

[0026] A base station may operate according to one of several RATs with which it communicates with UEs depending on the network in which it 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. Base stations may be used primarily to support wireless access by UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, base stations may provide purely edge node signaling functionality, while in other systems, base stations may provide additional control and / or network management functions. A communication link through which a UE can send RF signals to a base station is called an uplink (UL) channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). A communication link through which a base station can send RF signals to a UE is called a downlink (DL) or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a 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 receiving point (TRP) or multiple physical TRPs, which 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 the base station's cell (or several cell sectors). 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 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 reference RF signals (or simply "reference signals") the UE is measuring. 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, since a TRP is a point from which a base station transmits and receives wireless signals.

[0028] In some implementations that support UE positioning, 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 transmitting signals to the UE) and / or a location measurement unit (e.g., when receiving and measuring 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 over 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," "radio 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, and determining that the difference meets a first threshold for at least a specific 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 1 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) is 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 taking certain sensors associated with the device offline, stopping sending warning messages to the server, or putting 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 equipments (UEs). If the server determines that a spoofed GNSS condition does not exist, the spoof alert message provides an indication that a spoofed GNSS condition does not exist. If the server determines that a spoofed GNSS condition does exist, the spoof alert message provides an indication that a spoofed GNSS condition exists. Determining that a spoofed GNSS condition exists includes determining that the number of monitored devices sending alert messages is greater than a number threshold, determining that a percentage of the number of monitored devices sending alert messages to the total number of monitored devices is greater than a percentage threshold, determining that a size of a sub-region over which the monitored devices are sending alert messages is greater than a size threshold, and determining that a length of time over which the monitored devices are sending alert messages is greater than a time threshold. The spoof 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 specific device among the multiple 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 the horizontal estimated position error is less than or equal to an error threshold, the server includes the specific 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 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 coarse 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 the location of the 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 the current location of the user equipment, and determines the 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 before 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] 1 illustrates an example of a system 100 for detecting spoofed GNSS data in accordance with various aspects of the present disclosure. The system 100 may include multiple Internet of Things (IoT) devices 102(1)-102(N) (N>0) connected to one or more servers 104 via one or more networks 106. Multiple user equipments (UEs) 108(1)-108(M) (M>0) may be connected to the network 106 and may include user devices such as smartphones, smartwatches, 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 multiple 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 multiple 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 , IOT device 102(1) has an associated location 118(1), and 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 streetlights, traffic lights, security cameras, or another type of stationary object. User equipment 108 may include user devices such as, for example, smartphones, smartwatches, 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 multiple sensors 120, including navigation sensors for receiving GNSS data 168 and determining current fixes. In some cases, the multiple sensors 120 may include an inertial measurement unit (IMU) and a camera to enable each IOT device 102 and the server 104 to determine that the individual IOT device is stationary. Each of the IOT devices 102 may store fixes 121, including current fixes 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 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 GNSS fixes may be determined over a time period of about 20 seconds. The long-term average 126 of GNSS fixes is the 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 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 are 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 criteria 128 are 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 (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) the IOT device 102(1) determines that conditions (1) and (2) are both 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 geographic 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 geographic definition). The particular geographic area includes IOT devices 102 and user equipment 108. The server 104 may or may not be physically located in the particular geographic area. When the spoofed data 112 is being broadcast, the server 104 may receive messages 130 from each of multiple IOT devices 102 that are within a 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 line-of-sight of the spoofer 110, and other factors related to the broadcast of the spoofed data 112.

[0041] When spoofing is not present, 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). Additionally, 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 is present, and may ignore messages 130 sent by IOT devices not included in the subset 152 of devices for calculations performed to determine whether spoofing is occurring.

[0042] The server 104 may receive multiple ones of the messages 130 and use a spoofing detector 132 to analyze the data contained in the multiple 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 an 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 the total number of IOT devices 102 is greater than a second threshold, whether a size of a subregion 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, 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 optionally send instructions to activate additional ones 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 messages 130 from individual devices in the subset 152 of devices, the server 104 may send instructions instructing 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 messages 130 from the additional IOT devices 102. The server 104 may use the additional data to determine the 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-regions 138 that include the spoofer location 166 of the spoofer 110 and the size of each of the sub-regions 138. For example, the server 104 may determine the location 118 of the IoT device 102 sending the message 130 to determine the sub-region 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-region (e.g., sub-region 154) of the sub-region 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 devices 108 if the spoofer 110 is closer to one or more of the user devices 108 and lower if the spoofer 110 is farther away (e.g., greater than a threshold distance) from one or more of the user devices 108.

[0045] The spoofing detector 132 may determine a spoofer location 166 of the spoofer 110 to enable one or more actions to be taken to address the spoofing. The one or more actions may include alerting authorities that spoofed data 112 is being broadcast, resulting in positioning errors that could have disastrous consequences, such as a car accident. In response, 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 data received from the IOT device 102, intermediate results of calculations performed to determine whether 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 which sub-areas are being targeted for spoofing, which frequencies are being used for spoofing, etc. Additionally, if machine learning is used, the machine learning 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 the spoofing continues. If the network management 144 at any point determines that the spoofing has stopped (e.g., the 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 a 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-region 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 no spoofing is occurring) to a second sub-region (e.g., where spoofing is occurring) may receive spoofed data 112, determine that the spoofed data 112 is specified in a spoof alert 146, and ignore the spoofed data 112 when determining a position fix. In this way, the vehicle can 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 cases, 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 temporarily 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 erroneously determines is spoofing. 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 the line of sight, etc.

[0050] The IOT device 102 may, in some cases, send an alert 150 directly to one or more of the user equipment 108 located near (e.g., in the same region or sub-region) 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-region (e.g., sub-region 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 alerts 150 from at least a threshold number (e.g., M or more, where 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 spoof alerts 146 and 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 spoof 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 before 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 its current location.

[0051] The network management 144 of the server 104 may continue to monitor 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 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 no longer exists. In response, in some cases, the server 104 may send a stop spoofing 156 message to the IOT devices 102 and the user equipment 108 indicating that spoofing no longer exists. After receiving the stop spoofing 156 message, the IOT devices 102 and the 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, or security camera, may receive GNSS signals and analyze the received signals to determine whether spoofed GNSS signals are being broadcast. For example, to determine whether spoofing is present, an individual IOT device may determine the difference between a short-term average of GNSS fixes (e.g., a real-time position fix) and a long-term average of GNSS fixes. 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), 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 signals received by the IOT device. The server may service a particular region and may receive multiple messages from multiple IOT devices within the particular region (each message of the multiple messages is sent by a respective IOT device of the multiple IOT devices).

[0053] The server may analyze 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 relative 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 specific 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-region are moving in a similar pattern, the server may determine that spoofed data exists. For example, if the location jumps are similar, e.g., because the IoT devices are 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, e.g., because of meaconing, the server may determine that spoofed data exists.

[0054] By using data from multiple IOT devices, the server can reliably determine whether spoofing is occurring. Therefore, since multiple devices can confirm the spoofing, reliability is improved compared to traditional means of determining 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 that something is 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, untrustworthy IOT devices can 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 one 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 UEs 204. Each of the base stations 202 may provide communication coverage for a respective geographic coverage area 210. In one aspect, one or more cells may be supported by the base station 202 in each geographic coverage area 210. A “cell” is a logical communication entity used for communication with a base station (e.g., via some frequency resource referred to as a carrier frequency, component carrier, carrier, band, etc.) and may be associated with an identifier (e.g., a physical cell identifier (PCI), a virtual cell identifier (VCI), a 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” can refer to either or both the logical communication entity and the base station that supports it, depending on the context. In some cases, the term "cell" may refer to the geographic coverage area (e.g., 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 their proximity to macrocell base stations 202, their geographic coverage areas 210 may overlap partially (e.g., within handover regions), but some of their 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 including both small cell and macrocell base stations may be known as a heterogeneous network. A heterogeneous network may also include Home eNBs (HeNBs) that may serve restricted groups known as Closed Subscriber Groups (CSGs).

[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 communicating 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 whether 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 the 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 MultiFire.

[0062] The wireless communication system 200 may further include a millimeter-wave (mmW) base station 280, which may operate at millimeter-wave (mmW) and / or sub-mmW frequencies, communicating 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 and 20 millimeters. Radio waves in this band are sometimes referred to as millimeter waves. Sub-mmW may extend down to frequencies of 3 GHz with wavelengths of 200 millimeters. The very high frequency (SHF) band extends between 3 GHz and 30 GHz and is also referred to as centimeter waves. Communications using the mmW / sub-mmW radio frequency band 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 will be appreciated that the above illustrations are merely exemplary 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 that signal in all directions (omnidirectionally). 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 emits 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. Specifically, RF current from the transmitters is fed to individual antennas in the correct phase relationship, so that the radio waves from the separate antennas combine together to increase radiation in the desired direction while canceling out to suppress radiation in undesired directions.

[0064] A transmit beam may be quasi-colocated, which means 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. In NR, there are four types of pseudo-location (QCL) relationships. In particular, a given type of QCL relationship 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, mean delay, and delay spread of a 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 a 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 mean delay of a 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 the target reference RF signal transmitted on the same channel.

[0065] In receive beamforming, a receiver uses a receive beam to amplify RF signals detected 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) the RF signal 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 higher 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 the RF signal received from that direction.

[0066] The receive beams may be spatially related. The spatial relationship means that parameters of a transmit beam for a second reference signal can be derived from information about the receive beam for the first reference signal. For example, a UE may use a particular receive beam to receive one or more downlink reference signals (e.g., a positioning reference signal (PRS), a tracking reference signal (TRS), a phase tracking reference signal (PTRS), a cell-specific reference signal (CRS), a channel state information reference signal (CSI-RS), a primary synchronization signal (PSS), a secondary synchronization signal (SSS), a 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., an uplink positioning reference signal (UL-PRS), a sounding reference signal (SRS), a demodulation reference signal (DMRS), a 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, the downlink beam is a transmit beam. However, if the UE forms a downlink beam, 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, it is an uplink receive beam, and if the UE forms an uplink beam, 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: FR1 (450 MHz to 6000 MHz), FR2 (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 “secondary carriers” or “secondary serving cells” or “SCells.” 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 on 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 control channels and UE-specific control channels and may (but is not always) be 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 contain only necessary signaling information and signals; for example, 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 can change the primary carrier of any UE 204 / 282 at any time. This is done, for example, to balance the load on different carriers.Since a "serving cell" (whether a PCell or SCell) corresponds to the carrier frequency / component carrier on 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 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] Wireless communications system 200 may further include a UE 264, which may communicate with macrocell base station 202 via communications link 220 and / or with mmW base station 280 via mmW communications link 284. For example, macrocell base station 202 may support a PCell and one or more SCells for UE 264, and mmW base station 280 may support one or more SCells for 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 UE 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 positioned 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. While typically located in the SVs 212, transmitters may sometimes be located on ground-based control stations, base stations 202, and / or other UEs 204.

[0072] The 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 the Wide Area Augmentation System (WAAS), the European Geostationary Navigation Overlay Service (EGNOS), the Multifunction Satellite Augmentation System (MSAS), the Global Positioning System (GPS)-Aided Geo-Augmented Navigation, or the 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 SPSs.

[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 through which one of the UEs 204 is connected to one of the base stations 202 (e.g., through which the UE 290 may indirectly obtain cellular connectivity) and a D2D P2P link 294 through which the WLAN STA 252 is connected to a WLAN AP 250 (through which the UE 290 may indirectly obtain WLAN-based Internet connectivity). In one example, the D2D P2P links 292 and 294 may be supported using any well-known D2D RAT, such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), Bluetooth, etc.

[0074] In the flowcharts 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 software context, 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 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] 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. The Global Positioning System (GPS), one type of GNSS, 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) can be used. A 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 Figure 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), (2) whether Δr divided by HEPE is greater than a second threshold (TH2), and whether 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 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 Figure 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 present 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 multiple 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 message 130 including the difference between ST AVG 124 and LT AVG 126, and HEPE 123.

[0084] At 406, for each device among the plurality of devices, the process determines (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, determines (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 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 among the IOT devices 102, if the difference is less than or equal to threshold TH4 and HEPE is less than or equal to threshold TH5, then the server 104 may include the particular IOT device in the subset of devices 152. The server 104 may use the alert messages (eg, message 130) received from the subset of devices 152 when determining whether spoofing is occurring.

[0085] 1 may select a subset of devices 152 (also referred to as selected devices) that are considered “normal” during times when spoofing is not occurring, for example, by selecting a subset of IOT devices 102 that (1) have a Δr less than or equal to a fourth threshold (TH4) and (2) have a HEPE 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 managed by the server 104, how much interference the IOT devices experience, etc. The fourth and fifth thresholds may be set to values ​​that filter out IOT devices sending messages 130 based on relatively small errors when spoofing is not occurring (e.g., relatively small Δr and relatively small HEPE).

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

[0087] At 502, the process receives an alert message from each of a plurality of devices among 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 message 130 from one or more of the IOT devices 102. Message 130 may include data such as the difference between ST AVG 124 and 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 subregion 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 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 stop spoofing 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 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 IOT devices in the selected subset of IOT devices begin sending warning messages (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 the IOT devices have 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 that includes sending an alert message to a server according to an aspect of the present disclosure. The process 600 may be performed by an individual one 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 GNSS fix information (short-term average 124 and long-term average 126) using the current GNSS fix. For example, in FIG. 1, sensor 120 of 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. IOT device 102(1) may retrieve fix 121, which includes a current fix and a previously determined fix. IOT device 102(1) may also retrieve short-term average 124 and long-term average 126. 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 fix 121 to determine short-term average of the GNSS fix 124 and long-term average of the GNSS fix 126 and determine HEPE 123. If the process determines that criteria 128 (e.g., 310 in FIG. 3) are not met, the process acquires additional GNSS data 168 and determines an additional fix.

[0093] If the process determines at 610 that the criteria are met, the process proceeds to 612. At 612, the process may send an alert 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) is unable to communicate with the server 104, the IOT device 102(1) may send the 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 the spoofing alert 146 from the server 104. The spoofing alert 146 may provide details about the spoofed data 112, such as, for example, which sub-area (e.g., sub-area 154) the spoofed data 112 is being broadcast in, the frequency on 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, IOT device 102(1) may continue to send message 130 while spoofed data 112 is being broadcast. IOT device 102(1) may stop updating its 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 server 104, IOT device 102(1) may not update long-term average 126 using the current GNSS fix, discard spoofed data 112 based on information provided in spoof alert 146, not generate any additional messages in message 130, disable navigation sensors in sensors 120, power down 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 a first threshold and the difference for HEPE is greater than a 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 and long-term averages of the fix, 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 embodiment of the present 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-region) 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 of FIG. 3 ) when spoofing is not present. The server 104 ignores messages 130 received from IOT devices 102 that are not included in the subset 152 of devices. After the server 104 receives messages 130 from individual devices 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 locations of the individual IOT devices sending alert messages, determining the length of time the individual IOT devices have been sending alert messages, and determining the movement patterns of the individual IOT devices. The server 104 may determine whether the results of the analysis satisfy one or more criteria (e.g., 306, 308, 310, and 312 of 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 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-regions 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 spoof 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 of FIG. 3), the server 104 may send a spoof 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 way, the user equipment 108 avoids potentially disastrous consequences of using the spoofed data 112 (e.g., incorrect navigation causing an accident, arriving at an incorrect 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 subregion of the region (e.g., a neighborhood of a city), whether the 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 meets a set of spoofing conditions.

[0101] 8 illustrates an example process 800 including receiving a spoofing alert according to an aspect of the present disclosure. Process 800 may be performed by an individual one of the user equipments (UEs) 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 spoofer's location 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 user equipment 108(1) cannot receive the spoofed data 112, user equipment 108(1) may continue to use available GNSS data 168.

[0103] If a determination is made at 806 as "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 before receiving alert 146 or alert 150, along with sensor data from other sensors (e.g., gyroscope, accelerometer, magnetic compass, mapping sensor, 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 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] 9 illustrates a device 900 for implementing a server 104, an IOT device 102, or a UE 108 according to one aspect of the present disclosure. The device 900 may include one or more processors 902 (e.g., a CPU, a GPU, etc.), memory 904, a communication interface 906, a display device 908, other input / output (I / O) devices 910 (e.g., a keyboard, a trackball, etc.), and one or more mass storage devices 912 (e.g., a disk drive, a solid-state disk drive, etc.), configured to communicate with each other, such as via one or more system buses 914 or other suitable connections. While a single system bus 914 is shown 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., a Serial ATA (SATA)), a data bus (e.g., a Universal Serial Bus (USB)), a video signal bus (e.g., a 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 memory 904, mass storage device 912, or other computer-readable medium.

[0107] Memory 904 and mass storage device 912 are examples of computer storage media (e.g., memory storage devices) for storing instructions that may be executed by processor 902 to perform various functions described herein. For example, memory 904 may include both volatile and non-volatile memory (e.g., RAM, ROM, etc.) devices. Additionally, 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 memory 904 and 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 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 a user and provide various outputs to a user, and may include a keyboard, touchpad, mouse, 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) that may be incorporated into 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 are shown. 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-chip (SoC), etc.). The illustrated components may also be incorporated into other devices in a communication system. For example, other devices in the system may include components similar to the illustrated 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] The UE, base station, or network entity may each include a wireless wide area network (WWAN) transceiver 1010 and 1050 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, for communicating 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 targeted wireless communications medium (e.g., some set of time / frequency resources within a particular frequency spectrum). The WWAN transceivers 1010 and 1050 may be variously configured to transmit and encode signals 1018 and 1058, respectively (e.g., messages, instructions, information, etc.), and conversely, to receive and decode signals 1018 and 1058, respectively (e.g., messages, instructions, information, pilots, etc.), 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, and include one or more receivers 1012 and 1052, respectively, for receiving and decoding 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 target wireless communications medium. 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, and include one or more receivers 1022 and 1062, respectively, for receiving and decoding signals 1028 and 1068, respectively.

[0114] 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 circuitry in a single communications device), in some implementations comprise separate transmitter and 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), enabling 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), enabling 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 simultaneously. 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) or the like 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 operations from other systems and perform the calculations necessary to determine the positions of the UE and base station using measurements obtained by any suitable SPS algorithms.

[0116] The base station and the network entity 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 can be used in conjunction with operations as disclosed herein. The UE may include processor circuitry implementing a processing system 1052, for example, to provide functionality related to RF sensing and to provide other processing functions. The base station may include a processing system 1084, for example, to provide functionality related to RF sensing and to provide other processing functions. The network entities may include processing systems, for example, to provide functionality related to Wi-Fi radar or RF sensing as disclosed herein and to provide other processing functions. In one 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 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 the memory components 1040, 1086, respectively (as shown in FIGS. 10A, 10B) that, when executed by the processing systems 1052, 1084 (or modem processing systems, 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 systems (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. Furthermore, 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 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 the 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 transport channels, forward error correction (FEC) coding / decoding of transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, 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 orthogonal frequency division multiplexing (OFDM) subcarriers, multiplexed with reference signals (e.g., pilots) in the time and / or frequency domains, 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 and 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 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 intended for the UE. If multiple spatial streams are intended for the UE, they may be combined into a single OFDM symbol stream by the receiver 1012. 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 point that was 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 transmissions by the base station, the processing system 1052 provides RRC layer functionality associated with system information (e.g., MIB, SIB) 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 forwarding upper layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing MAC SDUs onto transport blocks (TBs), demultiplexing 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] Uplink transmissions are processed at the base station in a manner similar to that described for the receiver function at the UE. Receiver 1052 receives signals through its respective antenna 1056. Receiver 1052 recovers the information demodulated onto the RF carrier and provides the information to 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 entity are illustrated in Figures 10A-10B as including various components that may be configured in accordance with various examples described herein, although it will be appreciated that the illustrated blocks may have different functions in different designs.

[0130] The various components of the UE, base station, and network entity may communicate with each other via data buses 1054 and 1082, respectively. The components of FIGS. 10A and 10B may be implemented in various ways. In some implementations, the components of FIGS. 10A and 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 its 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 the UE," "by the base station," "by the positioning entity," etc. However, it will be appreciated that such operations, acts, and / or functions may actually be performed by particular components or combinations of components, such as the UE, the base station, the positioning entity, etc., such as the processing systems 1052, 1084, the transceivers 1010, 1020, 1050, and 1060, the memory components 1040, 1086, the radar components 1042, 1088, etc.

[0131] It may be noted that while particular frequencies, integrated circuits (ICs), hardware, and other features are described in 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., generally does not limit the quantity or order of those elements. Rather, these designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, 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 in some way precede the second element. Also, unless otherwise stated, a set of elements may comprise one or more elements. Additionally, as used in this specification or claims, terms 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" mean "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 illustrative logical 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 illustrative 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 varying 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 random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, removable disk, 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., cache memory).

[0136] In the above detailed description, it can be 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 present disclosure may include fewer than all features of each disclosed exemplary clause. Accordingly, the following clauses should be considered hereby incorporated into the description, and each clause may stand alone as a separate example. Although each dependent clause within 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. The various aspects disclosed herein expressly include combinations of specific combinations unless the fact that a particular combination is not intended (e.g., conflicting aspects, such as defining an element as both an insulator and a conductor) is explicitly expressed or can be readily inferred. Furthermore, it is 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, based at least in part on analysis of the GNSS measurement data, whether a spoofed GNSS condition exists; and, based on the determination, sending a spoof alert message to one or more user equipments (UEs).

[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 in which the monitored devices are sending warning messages is greater than a size threshold, and determining that a length of time in which the monitored devices are sending warning messages is greater than a time threshold.

[0140] Clause 4. The method of clause 3, wherein the spoofing 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 the difference between the short-term average of the GNSS fixes and the 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, and determining, for a particular device of the plurality of devices, that 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 that the 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 warning 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 to disable a navigation sensor of the second monitored device or a second instruction to transition the second monitored device to 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 the difference between the short-term averages of GNSS fixes determined by the monitored device sending the warning message and the long-term averages 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, the method 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 met; 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; and 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. The method of clause 12, wherein the short-term average of the GNSS fixes is determined over a time period of 10 to 60 seconds.

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

[0151] Clause 15. The method of any of clauses 11 to 14, further comprising 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. The method of any of clauses 15-16, further comprising the step of ignoring spoofed GNSS signals.

[0154] Clause 18. The method of any of clauses 15 to 17, further comprising determining that one or more user equipments (UEs) are receiving spoofed GNSS signals, and sending a spoof alert message to at least one UE 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 down the device.

[0156] Clause 20. A method of operating a user equipment, the method 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, based on the spoof alert message, the location of the spoofer broadcasting the spoofed GNSS signal; determining, based on the location of the spoofer and a current location of the user equipment, that the user equipment is within a reception area of ​​the spoofed GNSS signal; 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. The method of any 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 to 22, wherein determining the 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 one or more GNSS signals based on a determination that the spoof 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 in accordance with aspects of the present disclosure described herein need not be performed in any particular order. Furthermore, while 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 140 Threat Level 141 Trust Level 142 databases 144 Network Management 146 Spoofing Alert 148 Command 150 alarm A subset of 152 devices 154 sub-areas 156 Spoofing Stop 166 Spoofer Locations 168 GNSS data 170 GNSS signal sources 200 Wireless Communication Systems 202 Base station, macrocell base station 202' Small Cell (SC) Base Station 204 UE 210, 210' Geographic Coverage Area 212 Space Vehicle (SV), SV 220 Communication Links 222 backhaul link 224 SPS signal 234 backhaul links 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 UE 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 transmitters 1026 Antenna 1028 signal 1030 Satellite Positioning System (SPS) receiver, SPS receiver 1036 Antenna 1038 SPS signal 1040 Memory Components 1042 Radar Components 1044 Sensors 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 the set of monitored devices, the alert message including Global Navigation Satellite System (GNSS) measurement data, the alert message including: 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; based on the determination whether a spoofed GNSS condition exists, sending a spoof alert message to one or more user equipments (UEs); 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 wherein the spoof alert message provides an indication that the spoofed GNSS condition exists. The method of claim 1.

3. determining that a spoofed GNSS condition exists comprises: determining that the 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 from 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: the spoofed constellations used by the spoofed GNSS signals, 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 represent a percentage of the 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, First, a short-term average of multiple global navigation satellite system fixes; Second, a long-term average of multiple GNSS fixes and the difference between 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, based at least in part on the second GNSS measurement data, that the second monitored device is defective; excluding 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, wherein the weight for each device is: 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 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 steps and 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 GNSS fixes 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; 11. The method of claim 10, comprising:

12. the short-term average of GNSS fixes is determined for a time period of 10 seconds to 60 seconds; and the long-term average of GNSS fixes is determined for a time period of 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, 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 equipments (UEs) based on the determination whether the spoofed GNSS condition exists; and A server configured to:

14. The server of claim 13, further configured to perform the method of any one of claims 2 to 9.

15. A device, 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 met; and sending a warning message associated with the GNSS measurement data to a server to alert the server of 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