LOCALIZED REMOTE GNSS POSITIONING

Abstract

Methods and apparatus are disclosed for gathering raw Global Navigation Satellite Systems (GNSS) phase measurements at a GNSS receiver and making them available to a remote device for processing to calculate a position fix for the GNSS receiver. The measurements are arranged in a first subset and a second subset. First bits of the first subset and second bits of the second subset are embedded in one or more data messages for transmission to the remote device. The first bits include a coarse part and a fine part of the respective phase measurement. In contrast, the second bits describe at least a portion of the fine part, but none of the coarse part, of the respective phase measurement.

Claims

1. A Global Navigation Satellite Systems (GNSS) receiver comprising: a signal processing unit, configured to make a plurality of phase measurements at a first epoch, each phase measurement being made from a respective different GNSS signal; and at least one processor, configured to: select a first subset of the phase measurements; select a second subset of the phase measurements; for each phase measurement of the first subset, write first bits of the phase measurement to at least one data message for transmission to a remote device for processing; for each phase measurement of the second subset, write second bits of the phase measurement to the at least one data message; and output the at least one data message containing at least the first and the second bits, wherein the first bits include a coarse part and a fine part of the respective phase measurement, and wherein the second bits describe at least a portion of the fine part of and none of the coarse part of the respective phase measurement.

2. The GNSS receiver of claim 1, wherein the first subset comprises at least four phase measurements.

3. The GNSS receiver of claim 1, wherein the first bits describe an integer number of chips and a fractional chip of a spreading code of the respective GNSS signal; and/or wherein the second bits comprise the least significant bits describing the lowest part of the fractional chip of the spreading code of the respective GNSS signal.

4. The GNSS receiver of claim 1, wherein the at least one processor is configured to: obtain at least one quality indicator associated with each phase measurement; and select, as the first subset, the phase measurements having the highest quality, according to the at least one quality indicator.

5. The GNSS receiver of claim 4, wherein the at least one processor is configured to select the second subset from among the phase measurements remaining after the first subset has been selected, wherein the at least one processor is configured to select, as the second subset, the phase measurements having the next highest quality, according to the at least one quality indicator.

6. The GNSS receiver of claim 1, wherein the at least one processor is configured to: obtain at least one quality indicator associated with each phase measurement; assess a first quality criterion for some or all of the phase measurements, wherein the quality criterion is based at least in part on the quality indicators; and responsive to the first quality criterion being satisfied, proceed to output the at least one data message.

7. The GNSS receiver of claim 1, wherein: the signal processing unit is configured to make a plurality of second phase measurements at a second epoch, each second phase measurement being made from a respective different GNSS signal, and the at least one processor is configured to: obtain at least one second quality indicator associated with each second phase measurement; assess a second quality criterion for some or all of the second phase measurements, wherein the second quality criterion is based at least in part on the second quality indicators; and responsive to the second quality criterion not being satisfied, suppress the output of a data message for the second epoch.

8. The GNSS receiver of claim 1, wherein the at least one processor is configured to apply a cryptographic signature to the first bits and second bits, and to write the cryptographic signature to the at least one data message for transmission to a remote device for processing.

9. The GNSS receiver of claim 1, wherein the at least one processor is configured to write to the at least one data message, with the first bits and the second bits, at least one of: a value of a monotonic counter maintained by the at least one processor; and a timestamp according to a local clock of the GNSS receiver.

10. A method of processing a plurality of phase measurements made at a Global Navigation Satellite Systems (GNSS) receiver, to calculate a position fix, the method comprising: obtaining a coarse position estimate for the GNSS receiver; receiving at least one data message comprising at least, for each phase measurement in a first subset of the plurality of phase measurements, first bits of the phase measurement, and for each phase measurement in a second subset of the plurality of phase measurements, second bits of the phase measurement; obtaining GNSS assistance data; and processing the coarse position estimate, the first bits, the second bits and the GNSS assistance data, wherein each phase measurement of the plurality of phase measurements was made by the GNSS receiver from a respective different GNSS signal, wherein the first bits include a coarse part and a fine part of the respective phase measurement, and wherein the second bits describe at least a portion of the fine part of and none of the coarse part of the respective phase measurement.

11. The method of claim 10, wherein the coarse position estimate is based on at least one of: a previous position estimate calculated for the GNSS receiver; or a known geographical area of operation of the GNSS receiver.

12. The method of claim 10, further comprising: receiving the at least one data message comprising a cryptographic signature associated with the plurality of phase measurements; and verifying the authenticity of the cryptographic signature.

13. The method of claim 10, further comprising: receiving the at least one data message comprising a temporal sequence marker comprising at least one of: a monotonic counter value produced by the GNSS receiver, associated with the epoch at which the plurality of phase measurements have been made; or a timestamp produced by the GNSS receiver, associated with the epoch at which the plurality of phase measurements have been made, comparing the temporal sequence marker with a previous temporal sequence marker associated with a previous data message obtained from the GNSS receiver, to determine whether the temporal sequence marker is valid or invalid, and responsive to determining that the temporal sequence marker is invalid, detecting a replay attack.

14. The method of claim 10, wherein obtaining the coarse position estimate comprises receiving user input of the coarse position estimate.

15. (canceled)

16. An apparatus comprising one or more tangible, non-transitory, computer-readable media storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising: obtaining a coarse position estimate for a Global Navigation Satellite Systems (GNSS) receiver; receiving at least one data message comprising at least, for each phase measurement in a first subset of the plurality of phase measurements, first bits of the phase measurement, and for each phase measurement in a second subset of the plurality of phase measurements, second bits of the phase measurement; obtaining GNSS assistance data; and processing the coarse position estimate, the first bits, the second bits and the GNSS assistance data, wherein each phase measurement of the plurality of phase measurements was made by the GNSS receiver from a respective different GNSS signal, wherein the first bits include a coarse part and a fine part of the respective phase measurement, and wherein the second bits describe at least a portion of the fine part of and none of the coarse part of the respective phase measurement.

17. The apparatus of claim 16, wherein the coarse position estimate is based on at least one of: a previous position estimate calculated for the GNSS receiver; or a known geographical area of operation of the GNSS receiver.

18. The apparatus of claim 16, wherein the operations further comprise: responsive to receiving the at least one data message comprising a cryptographic signature associated with the plurality of phase measurements, verifying the authenticity of the cryptographic signature.

19. The apparatus of claim 16, wherein the operations further comprise: responsive to receiving the at least one data message comprising a temporal sequence marker comprising at least one of (i) a monotonic counter value produced by the GNSS receiver, associated with the epoch at which the plurality of phase measurements have been made (ii) or a timestamp produced by the GNSS receiver, associated with the epoch at which the plurality of phase measurements have been made, comparing the temporal sequence marker with a previous temporal sequence marker associated with a previous data message obtained from the GNSS receiver, to determine whether the temporal sequence marker is valid or invalid, and responsive to determining that the temporal sequence marker is invalid, detecting a replay attack.

20. The apparatus of claim 16, wherein obtaining the coarse position estimate comprises receiving user input of the coarse position estimate.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0109] The invention will now be described by way of example with reference to the accompanying drawings, in which:

[0110] FIG. 1 is a schematic block diagram of a GNSS receiver according to an example;

[0111] FIG. 2 is a block diagram showing the GNSS receiver of FIG. 1 in operation in a system according to an example;

[0112] FIG. 3 is a flowchart illustrating a method performed by the GNSS receiver of FIG. 1 according to a first example;

[0113] FIG. 4 is a flowchart illustrating a method performed by the GNSS receiver according to a second example; and

[0114] FIG. 5 is a flowchart illustrating a method performed by a remote server according to an example.

[0115] It should be noted that these figures are diagrammatic and not drawn to scale.

DETAILED DESCRIPTION

[0116] Reference will now be made in detail to examples according to the present disclosure, which are illustrated in the accompanying drawings. The described examples should not be construed as being limited to the descriptions given in this section. Other examples may have different forms.

[0117] FIG. 1 is a schematic block diagram of a device according to an example. The device comprises a GNSS antenna 101 and a GNSS receiver 100. The GNSS antenna 101 is configured to receive GNSS signals. It may be configured to receive GNSS signals from a single GNSS constellation (for example, GPS), or it may be configured to receive GNSS signals from multiple constellations (for example, GPS, Galileo, GLONASS, and/or BeiDou). Furthermore, it may be configured to receive GNSS signals in a single band (for example L1 for GPS), or it may be configured to receive GNSS signals in multiple bands (for example L1 and L5 for GPS).

[0118] The GNSS receiver 100 comprises an RF front-end 105, a signal processing unit 110, a processor 120, a memory 130, a transmitter 140, and a battery 150. The RF front-end 105 is configured to receive GNSS signals via the GNSS antenna 101, and to output them to the signal processing unit 110. The RF front-end 105 is configured to down-convert and digitise the satellite signals received via the antenna 101. The RF front-end essentially conditions the signals for subsequent signal processing. Other typical tasks performed by the front-end include filtering and amplification. The satellite signals received at the RF front-end 105 via the antenna 101 include at least one ranging signal, such as a GPS L1 C/A signal, for each of a plurality of satellites.

[0119] The signal processing unit 110 is configured to track the received GNSS signalsin particular, in frequency, delay (code-phase) and carrier phaseand to produce GNSS measurements from the received GNSS signals. It is further configured to generate at least one quality indicator for each GNSS measurement.

[0120] The processor 120 is configured to process the GNSS measurements obtained from the signal processing unit 110. While it should be understood that more than one processor may be present within the GNSS receiver 100 for implementing methods according to the present disclosure, for the purposes of the present description it is assumed that there is only one processor 120, as depicted in FIG. 1.

[0121] The memory 130 is in communication with the processor 120. The memory 130 is configured to store software/firmware to be executed by the processor 120. The software/firmware is configured to control the processor 120 to carry out a method according to an example. The memory may also be configured to store data that is used as input to the processor 120 and/or to store data that is output by the processor 120.

[0122] The transmitter is configured to transmit data messages from the GNSS receiver to a remote server 200 (see FIG. 2). The data messages contain raw GNSS measurements, which are passed from the GNSS receiver to the remote server 200, to enable the remote server 200 to calculate the position of the GNSS receiver. In the present example, the transmitter 140 is a cellular modem for a 5G cellular communications network.

[0123] The battery 150 provides power for operating each of the other components of the GNSS receiver 100. Examples according to the present disclosure seek to conserve battery power. This helps to minimise the size, weight, and cost of the battery for a given set of user requirements. Conversely, it can help to increase the operating lifetime (or operating time between recharges), for a given battery capacity.

[0124] FIG. 2 shows the device of FIG. 1 in use in a system according to an example. The GNSS receiver 100 is shown in communication with a remote server 200, via a network (or networks) 250. The one or more networks 250 may include a cellular data communications network (in the present example, a 5G cellular communications network) and the Internet. The server comprises at least one processor 220 and a memory 230, storing computer program code that runs on the processor.

[0125] The server 200 receives the raw GNSS measurements from the GNSS receiver 100, via the one or more networks 250, and calculates (using the processor 220) a position fix for the GNSS receiver based on the measurements. To support this calculation, the server 200 may obtain GNSS assistance data. The GNSS assistance data may include (but is not limited to) any suitable type of assistance data that is known in the art. In the present example, the GNSS assistance data includes satellite ephemeris data (nominal satellite information); and corrections for satellite clock, orbits and biases and ionospheric and tropospheric error. GNSS assistance data can be provided by a third-party data service such as is known in the art. The server 200 may obtain it via the Internet from such a data service (not illustrated in FIG. 2).

[0126] By obtaining the assistance data and processing the GNSS measurements at the remote server 200, the power consumption of the GNSS receiver can be reduced, compared with a GNSS receiver that calculates its position itself (optionally obtaining assistance information in order to do so). This model works well for energy constrained Internet of things (IoT) applications, where it is not the IoT device itself that needs to know its position, but rather some remote device or service. An exemplary application is asset-tracking where the position of an IoT device needs to be established a few times a day, and the device operates on a tight power budget, such that it is desirable to minimise the power consumption associated with the positioning function as far as possible.

[0127] In some (but not all) examples, the processing power and therefore complexity of the GNSS receiver can be reduced, by calculating positions exclusively in the cloud (that is, exclusively at the remote server 200).

[0128] The saving in power consumption obtained by processing the GNSS measurements remotely comes at the cost of that power that is consumed by the transmitter 140 in order to transmit the measurements to the remote server 200. The RF front-end 105 and signal processing unit 110 also need to consume power in order to make the GNSS measurements. It is desirable to minimise the overall power consumed by the GNSS receiver 100, across all of these functions. The power consumed by the RF front-end 105 and signal processing unit 110 can be reduced by shortening the time taken to make the measurements. The power consumed by the transmitter 140 can be reduced by reducing the amount of data to be transmitted. However, it could be expected that reducing the amount of data transmitted would reduce the accuracy of the eventual position fix. For example, it might be expected that reducing the number of GNSS measurements transmitted to the remote server 200 for a single position calculation may reduce the accuracy of the result of that calculation.

[0129] It is known to use range rate measurementsfor example, Doppler measurementsto calculate a coarse position fix (with the benefit of GNSS assistance data). This coarse position fix (which can be calculated at the remote server 200) can localise the position of the GNSS receiver to within a few kilometres. Provided that the error is no more than 150 km, code phase measurements can then be used to calculate a final position fix based on this coarse position, with greater accuracy. However, this requires both the Doppler measurements and the code phase measurements to be transmitted to the remote server.

[0130] The present inventors have recognised that, in many asset-tracking applications, the coarse position of a GNSS receiver does not change by more than 150 km from one position fix to the next. This assumption holds true, for example, when tracking animals on a farm, tracking machinery on a construction site, or tracking a courier van around a city. Indeed, in each of these cases, the position of the GNSS receiver typically does not change by more than 150 km over its whole operational lifetime. In such cases, the coarse position can be defined in advancefor example, by manual user input specifying a street address or even just a geographical region. In other examples, the coarse position could be established by the GNSS receivers through conventional GNSS positioning, in a commissioning phase of an asset tracking system. Devices could localise their positions once, in a configuration mode; thereafter, the coarse position would not change. The coarse position can be reconfirmed each time the remote server calculates a new position fixsetting the coarse position for the next position fix based on the result of the previous position fix.

[0131] By taking advantage of knowledge of the coarse position in this way, GNSS receivers 100 according to examples of the present disclosure can avoid the need to transmit range-rate measurements to the remote server 200. Correspondingly, the remote server 200 does not receive range-rate measurements from the GNSS receivers 100 and does not calculate the coarse position based on these measurements. Instead, the remote server 200 obtains the coarse position by other means (for example, as suggested above). Omitting the range-rate measurements from the one or more data messages sent from the GNSS receiver 100 to the server 200 helps to reduce the amount of data that needs to be transmitted. Alternatively, the amount of data transmitted can remain the same, but the content of the data messages can be adapted to increase the accuracy of the resulting position fix.

[0132] FIG. 3 is a flowchart illustrating a method performed by the GNSS receiver 100 of FIG. 1, according to an example. The inventors have recognised that more efficient use can be made of the data payload of the data messages if different measurements are treated differently. In particular, they have recognised that it may be inefficient for all the measurements to be encoded in the same way, with the same precision, in the data messages. According to the present example, the measurements are code phase measurements. However, similar principles can also be applied to other phase measurements useful in obtaining a GNSS position fix, such as carrier phase measurements.

[0133] In step 310, the processor 120 obtains a set of code phase measurements for the current epoch, from the signal processing unit 110. Each code phase measurement relates to a particular signal of a particular satellite in a particular GNSS constellation. Some satellites in some constellations may transmit multiple signals capable of supporting code phase measurements (for example GPS L1 and L5); therefore, not all the code phase measurements necessarily relate to different satellites. GNSS constellations are designed such that multiple satellites from the same constellation are in view at the same time, in clear-sky conditions. However, the actual number of signals from which code phase measurements can be made will vary depending on the signal-reception conditions prevailing at the time.

[0134] In step 320, the processor obtains at least one quality indicator associated with each code phase measurement. The quality indicators provide a measure of confidence in the code phase measurements. Weak or noisy signals are of lower quality and thus lower confidence. Strongly received and low-noise signals are of higher quality and accordingly higher confidence.

[0135] A wide variety of quality indicators can provide useful information about the level of confidence in the code phase measurements. Some quality indicators may be produced by the RF front-end 105 and/or signal processing unit 110 in the course of receiving the satellite signals and making the code phase measurements. One example of such a quality indicator is carrier-to-noise power ratio, which is used as the quality indicator in the present example. Other examples of such quality indicators include (but are not limited to): carrier-to-noise time variance, carrier-to-noise density, carrier-to-noise density variability, carrier phase variance, code-phase deviation, frequency deviation, a measure of multipath, loss-of-lock detection, code lock time and phase lock time. It should be apparent that some of these indicators are directly correlated with quality while others are inversely correlated with quality. For example, high deviation or variance would be indicative of low quality; however, a long lock time would be indicative of high quality.

[0136] Other quality indicators may be derived or calculated by the processor 120. These include (but are not limited to): satellite elevation and satellite azimuth. Note that at least GNSS almanac (if not ephemeris) is required, in order to determine the elevation and azimuth of a satellite. Therefore, such quality indicators can only be used if the GNSS receiver has already obtained this datafor example, by decoding a sufficiently long portion of a navigation message from one or more satellites, or through access to GNSS assistance data.

[0137] Quality indicators can be used individually or can be combined into an aggregated quality indicator to obtain a ranking algorithm for the code phase measurements. In an alternative example, the selected quality indicator or the aggregated quality indicator can be combined with predefined preferences or rules to obtain the ranking algorithm. This can be done in any suitable way, as desired. The ranking algorithm should ensure that the resulting order of code phase measurements is (directly or inversely) correlated with signal distortion.

[0138] In step 330, the processor 120 selects a first subset of the code phase measurements, ranked based on their associated quality indicators. The code phase measurements are ordered from highest to lowest according to their quality indicators (e.g., carrier-to-noise power ratios), and the code phase measurements from the signals with the five highest carrier-to-noise power ratios are selected for inclusion in the first subset. However, according to the present example, signals from the same GNSS constellation are preferred. Therefore, the processor 120 evaluates each GNSS constellation (and GNSS band) separately, to identify the five highest quality signals for each band in each constellation. It then selects, for the first subset, the five signals (in the same band) from the GNSS constellation that achieves the highest average carrier-to-noise power ratio, over the respective five strongest signals of that constellation. If no set of five code phase measurements from the same constellation is found, then the processor, in some implementations, may choose the best available set of four, three, or two code phase measurements from the same constellation. It then populates the remainder of the first subset with the best signals from the next best constellation, and so forth, until five code phase measurements have been selected. In each case (provided at least five code phase measurements were available), the resulting first subset consists of the five code phase measurements that are in some sense the best available.

[0139] In some examples, the selection process may include some predefined preferences or rules that are not necessarily related to the quality of the measurementssuch as generally preferring a specific GNSS constellation over another. However, beyond these predefined preferences or rules the selection includes some attempt to characterise and select those code phase measurements that are expected to be the most accurate and reliable.

[0140] In step 335, the processor 120 extracts first bits from each code phase measurement in the first subset and writes these first bits to a data message that is intended for transmission to the remote server 200. The first bits represent a coarse part and a fine part of the respective code phase measurement. The coarse part describes the integer number of chips (from the start of the current iteration of the spreading code) and the fine part represents the fractional chip (that is, the fraction of a chip within the current chip). Note that there is no need to write Doppler information in the data message. There is also no need to collect the integer number of spreading-code iterations. This is because the coarse position is already assumed to be known to within ?150 km (corresponding to around ?0.5 ms of timing-uncertainty, at the speed of light). The Doppler information and integer number of codes would not add any more accuracy to the positioning solution than this. It will be recalled that, for commercial L1 signals on the GPS, Galileo, GLONASS, and BeiDou constellations, the shortest spreading code duration is 1 mswhich corresponds to a positioning/ranging uncertainty of around 300 km (that is, ?150 km). For GPS L1 C/A the code duration is 1 ms. The number of chips in 1 ms is 1023; so, a chip represents 293 m. For GLONASS the code duration is 1 ms. The number of chips in 1 ms is 511; so, a chip represents 586 m. For Beidou B1I the code duration is 1 ms. The number of chips in 1 ms is 2046; so, a chip represents 146.5 m. For Galileo E1 the code duration is 4 ms. The number of chips in 1 ms is 1023 (while the number of chips in a code is 4092); so, a chip represents 293 m.

[0141] The number of bits that should be included in the first bits depends on the desired accuracy of the eventual position fix. The table below gives examples of possible configurations of first bits for various desired resolutions and GNSS constellations.

TABLE-US-00001 TABLE 1 Selecting the number of first bits Number of bits to represent . . . GPS GLONASS Galileo BeiDou Whole number of chips in 1 ms 10 9 10 11 Fractional chip for a resolution 6 7 6 5 of 5 m Fractional chip for a resolution 7 8 7 6 of 2.5 m Fractional chip for a resolution 9 10 9 8 of 1 m

[0142] In general, the number of bits required for a desired resolution, X, depends on the distance associated with the duration of one chip of the spreading code. For GPS L1 C/A, for instance, one chip corresponds to a distance of 293 m. Consequently, the number of bits, Y, required to represent the fractional chip for a resolution of X m is given by:

[00001]$Y=.Math.{\log }_2\frac{293}{X}.Math.$

Here, the brackets denote the ceiling function, which rounds up to the nearest integer.

[0143] For example, to achieve a resolution of 5 m using the GPS constellation, where the code duration is 1 ms and the code comprises 1023 chips (and so each chip is equivalent to 293 m), the first bits should include 16 bits. This is made up of 10 bits for the number of chips as CEIL(log.sub.2(1023))=10 and 6 bits for the fractional chip as CEIL(log.sub.2(293/5))=6.

[0144] In step 340, the processor 120 selects a second subset of the code phase measurements. Again, they are ranked based on the one or more quality indicators associated with each code phase measurement and, in some implementations, in conjunction with predefined preferences or rules. In other words, the second subset is populated with the highest quality code phase measurements that remain after the first subset has been selected, subject to any predefined preferences or rules, where implemented. The same quality indicator (carrier-to-noise power ratio) is used for the selection of the first and second subsets. However, this is not essentialthe first subset could be selected using one quality indicator and the second subset could be selected using a different quality indicator. In any event, the second subset would still be chosen from among the code phase measurements that were not selected for inclusion in the first subset. Note that, in some implementations, there may be no preference for signals and satellites in the same constellations, in respect of the second subsetany signal from any constellation is considered for inclusion, regardless of whether there are any other signals in that band and/or from that constellation. This approach may be taken, in particular, when the assistance information available to the remote device includes timing offsets between the GNSS constellations.

[0145] The upper limit on the number of code phase measurements included in the second subset may depend on the size of the payload available in the data message to be transmitted and it may be fixed. It may also depend on the desired resolution of the position fix (to be calculated subsequently by the remote server 200). In general, there may be a trade-off between the size of the payload and the positioning accuracy that is possible. For example, according to one implementation, if there are 5 measurements in the first subset, with a resolution of 2.5 m, and if the data message size is 50 bytes, the second subset may contain up to 15 measurements. According to another implementation, if there are 7 measurements in the first subset, with the same resolution and data message size, the second subset may contain up to 12 measurements.

[0146] In step 345, the processor 120 extracts second bits from each code phase measurement in the second subset and writes these second bits to the data message. Unlike the first bits (which were used to encode the code phase measurements of the first subset), the second bits do not describe the coarse part of the respective code phase measurement. In the present example, this means that the second bits do not describe the integer number of chips of the spreading code. The inventors have discovered that transmitting the integer number of chips for additional code phase measurements (that is, in addition to those of the first subset) does not significantly improve the positioning accuracy. It is believed that this is because the integer number of chips is effectively redundant information, for these additional code phase measurements. Instead, inventors have found that it is more effective to use the bits of the data message to carry a fine part of the code phase measurements in the second subset. Indeed, according to the present example, the processor does not even write the full fractional chip into the data message. The inventors have found that it is sufficient, and indeed more effective, to include only the lowest portion of the fractional partthat is, the least significant bits of the fractional part. In particular, referring again to the GPS example mentioned above, and considering that with the first subset of code phase measurements the position could be fixed with an error below 150 m, the second bits include only the last 5 bits of the fractional chip as CEIL(log.sub.2(150/5))=5. These 5 bits are sufficient to get from the 150 m resolution to the desired 5 m resolution. For a resolution of 2.5 m, 6 second bits are required per code phase measurement in the second subset; for a resolution of 1 m, 8 second bits are required.

[0147] By omitting the integer number of chips when encoding the code phase measurements of the second subset into the data message, a saving per code phase measurement of between around nine and eleven bits can be achieved for a target resolution between 5 m and 1 m. As indicated by the table above, this is a significant saving in data payload. Omitting part of the fractional chip from the second bits typically results in a smaller saving in data payload. The reduction (compared with encoding the fractional chip in full) may be 0, 1, or 2 bits per code phase measurement in the second subset. Nevertheless, this apparently small saving can accumulate to a more significant saving over many code phase measurements.

[0148] In step 350, the processor writes a timestamp to the data message. This can be useful in at least two ways at the remote server 200. Firstly, the server 200 can use the timestamp to obtain (or retrieve) the correct GNSS assistance data for the epoch involved. Secondly, the server can use the timestamp to detect a replay attack, in which a malicious actor tries to spoof the position of the GNSS receiver by eavesdropping on data messages sent by the GNSS receiver to the server, at a first time, and (re-)sending those data messages to the server 200 at a second, later time. If successful, such an attack would give the appearance that the GNSS receiver was still at the determined position (or had returned to that position). However, when the timestamp is included in the data message, the remote server 200 can see that the code phase measurements are related to a time that is not valid, for instance older than the last code phase measurements processed for the same GNSS receiverin other words, it can see that it is calculating a historical position of the GNSS receiver rather than a live position.

[0149] Although not shown explicitly in the flowchart, additional metadata is typically also included in the data message. For example, the data message may include the identity of the GNSS receiver and the information identifying the constellation, satellite, and band to which each code phase measurement pertains.

[0150] In step 360, the processor 120 applies a cryptographic signature to the data message and writes the cryptographic signature to the data message. The signature is applied to the first bits, the second bits and the timestamp. This can enable the remote server 200 to later detect any attempt by a malicious actor to modify any of these elements in order to create a fake/spoofed data message. Many suitable methods for cryptographically signing data are known in the art. Consequently, this step need not be described in further detail here.

[0151] In step 370, the processor 120 outputs the data message to the transmitter 140. In step 380, the processor 120 controls the transmitter 140 to transmit the data message to the remote server 200 via the one or more networks 250. It should be understood that the method of FIG. 3 relates to a single position fix, in this example. The method may be repeated periodically, each time the GNSS receiver is scheduled to update the remote server with fresh positioning data.

[0152] Although the description of the example above has referred to just one data message, it should be understood that the data may be written to any number of data messages. The size of each data message may be selected according to the characteristics of the one or more networks 250 over which the data is to be transmitted. For example, the data may be divided into multiple data messages such that the size of each message matches a packet size used in the one or more networks 250.

[0153] FIG. 4 illustrates a method that can be performed by the GNSS receiver 100 according to another example. Steps 310, 320, 330, 335, 340, 345, 370 and 380 are identical to the same steps described above with reference to FIG. 3. For brevity, the description of the individual steps will not be repeated. However, it will be noted that some of the steps are performed in an order that differs from that of FIG. 3.

[0154] As in FIG. 3, the method begins with step 310, in which the processor obtains a plurality of code phase measurements from the signal processing unit 110, and step 320, in which the processor obtains one or more quality indicators associated with each code phase measurement. Next, in step 330, the processor selects the first subset of the code phase measurements. However, in this version of the method, the processor does not yet write the first bits to the data message. Instead, the processor proceeds directly to step 340, in which it selects the second subset of the code phase measurements.

[0155] At this point, having identified the first and second subsets of the code phase measurements, the processor 120 assesses a quality criterion at least for the first subset of the code phase measurements, in step 410. The purpose of this step is to predict whether at least the selected first subset of the code phase measurements will be adequate to enable the remote server 200 to calculate a position fix. There is always a risk that a position fix cannot be calculated from the measurements transmitted to the serverfor example, because of errors in the measurements. The present example seeks to reduce this risk, by attempting to assess in advance whether the measurements to be transmitted are sufficient to support a successful position calculation. In the present example, this is done based on the one or more quality indicators associated with each measurement. If the aggregate quality of the signal/measurementsas judged by the quality indicatorsis sufficiently high, then there is a reasonably high likelihood that it will be possible to calculate the position fix. Nevertheless, it is desirable that the assessment of the quality criterion in step 410 does not significantly add to the cost in terms of power consumption, since this could reduce the overall benefit of the method to some extent.

[0156] Continuing from the example described above, the quality criterion could be assessed, in step 410, by comparing the minimum carrier-to-noise power ratio, over the ranked code phase measurements, to a threshold. If at least one of the code phase measurements in the first subset is below the threshold, this may indicate that the ranked code phase measurements include potentially unreliable measurements. In a similar manner to the step 320 of obtaining the quality indicators, the quality criterion may be assessed 410 based on the quality indicators in a variety of ways. In principle, any quality criterion that correlates with success or failure of the positioning calculation could be used.

[0157] According to the present example, the quality criterion is assessed 410 based on the code phase measurements in the first subset alone. This approach is adopted because the first subset is ultimately responsible for providing the minimum information necessary to support a successful position fix. If the data in the first subset is unreliable, then it is doubtful that a successful position fix will be possible (irrespective of the quality of the code phase measurements in the second subset, for which only the second bits are transmitted). In the present example, the processor 120 examines the carrier-to-noise power ratio for all the measurements in the first subset that are related to at least four signals in the same band from four different satellites in any one GNSS constellation.

[0158] In step 412, the processor 120 determines whether the quality criterion assessed in step 410 is satisfied or not. If the quality criterion is satisfied, then the method can proceed with the remaining steps from the method of FIG. 3. In particular, the processor writes the first and second bits to the data message, in steps 335 and 345, respectively. It outputs the data message to the transmitter 140 in step 370; and the transmitter 140 transmits the data message to the remote server 200, in step 380. (The method can also include steps 350 and 360 at this point, but these are omitted from FIG. 4 for simplicity.)

[0159] On the other hand, if the processor determines, in step 412, that the quality criterion is not satisfied, it proceeds instead to step 420. (Note that, in some other implementations, the processor may simply do nothing, depending on the GNSS receiver configuration.) In the present example, in the step 420, the processor 120 itself attempts to calculate the position fix using also additional measurements and/or assistance data. Note that this may involve keeping the RF front-end 105 and signal processing unit 120 in a powered-on state for longer, until sufficient information is available calculate the position fix. This information may include additional measurements, including Doppler measurements. It may also include ephemerides, decoded from a sufficiently long segment of the navigation message for each satellite concerned. Alternatively, in some other examples, the GNSS receiver may be able to access GNSS assistance data, which can avoid the need to decode the navigation messages, and may provide the processor with correction data that is not available merely by decoding the navigation messages. The GNSS receiver can obtain the assistance information from a suitable supporting service (in the same manner as the server 200 in the embodiment of FIG. 2). In particular, if the GNSS receiver includesor is part of, or is incorporated in a module witha cellular modem, then the GNSS receiver may be able to request and obtain the assistance information via the cellular modem over the Internet.

[0160] Assuming the processor 120 successfully calculates a position fix in step 420, it outputs the calculated position in step 425, and controls transmitter 140 to transmit it to the remote server 200, in step 430. In other words, instead of transmitting the data message containing the raw GNSS measurements to server 200 (see step 380), the transmitter 140 transmits the calculated position fix. This helps ensure that the remote server 200 obtains the position of the GNSS receiver (by one means or another) in as many instances as possible. If the attempt to calculate a position fix failed, in step 420, then step 430 is skipped. The transmitter could either transmit a message to notify the server of the failure or could simply transmit nothing at all.

[0161] As indicated in the flowchart of FIG. 4, after the transmission of the data message (in step 380) or else, if the GNSS receiver is configured for that and where possible, the transmission of the position fix (in step 430), the method proceeds to step 440, at which the processor waits until the next scheduled time for determining the position of the GNSS receiver. The processor 120 may control the RF front-end 105, the signal processing unit 110, and the transmitter 140 to switch to a powered-off or power-saving or standby state during the waiting period, in order to conserve power in the battery 150. When the scheduled time comes, the processor 120 activates the RF front-end, signal processing unit 110, and transmitter 140 once more, and the method proceeds to step 310 again. In this way, different outcomes may arise in different iterations of the method (and correspondingly at different epochs). At some epochs, the signals may be of high quality and the quality criterion may be satisfied, resulting in the first and second bits being written to the data message and the data message being transmitted to the remote server. At other epochs, the signals may be of low quality and the quality criterion might not be satisfied, resulting. if the GNSS receiver is configured for that, in an attempt to calculate the position fix at the GNSS receiver itself.

[0162] FIG. 5 illustrates a method performed by the processor 220 of the remote server 200 according to an example. In step 510, the processor 220 obtains the coarse position of the GNSS receiver. This is done using one of the methods described previously abovefor example, the coarse position may be obtained from the user/customer at the time of commissioning of an asset tracking system of which the GNSS receiver 100 forms a part. Note that, unlike many conventional systems, the coarse position estimate is not derived from range-rate measurements (for example, Doppler measurements). The coarse position estimate may be defined in conventional geographic coordinatesfor example, by a latitude and a longitude. Alternatively, in some examples, it may be defined using a grid system. The grid may divide the respective area of operation (potentially the whole world) into overlapping area units each having a radius (or comparable dimension) of 150 km. For example, the grid may contain hexagons, having an apothem equal to 150 km, with an overlap of at least 100 km in each direction. This ensures that several hexagons are always available for a given latitude and longitude.

[0163] In step 520, the processor 220 receives the data message (or data messages) transmitted by the GNSS receiver 100 to the remote server 200 via the one or more networks 250. In step 530, the processor 220 extracts the cryptographic signature that was applied and written to the data message by the GNSS receiver 100 in step 360. Next, in step 540, the processor verifies the authenticity of the cryptographic signature. Many suitable cryptographic algorithms for verifying the authenticity of signed messages are known in the art. Consequently, this step need not be described in any further detail. If the authenticity of the signature cannot be verified successfully, the processor 220 may determine that possible attempted spoofing attack has been identified.

[0164] Provided the authenticity is verified successfully in step 540, the method proceeds to step 550, in which the processor 220 extracts the code phase measurements from the data message. This includes the measurements of the first subset and the second subsetthat is, it includes the first bits and the second bits. In step 560, the processor 220 extracts the timestamp from the data message. It may use this in the subsequent step, step 570, of obtaining GNSS assistance data with which to process the code phase measurements. This is useful, in particular, in usage scenarios in which the raw measurements are not transmitted to the server 200 as soon as they are made, but rather are transmitted with an intentional delay, which may be of the order of seconds, minutes, hours, days, or weeks. In this case, the processor 220 can use the timestamp to look up historical GNSS assistance data that was contemporaneous with the timestamp. That is, the processor may access a database of historical GNSS assistance data, which includes multiple instances of assistance data indexed by respective timestamps. The processor selects the assistance data in the database that has the timestamp that corresponds most closely to the timestamp of the data message. It should be understood that, if the measurements are transmitted to the server 200 immediately when they are made, there may be no need for the timestamp and no need for the database of historical GNSS assistance data. This is because the measurements will always correspond to the most up to date version of the assistance data.

[0165] Optionally, in step 562, the processor 220 may validate the timestamp extracted in step 560. In one example, this involves comparing the timestamp against a previously received timestamp. Successive timestamps should always progress forward in time. That is, a timestamp that is received at the server 200 earlier should relate to an earlier time at the GNSS receiver 100, and a timestamp that is received later at the server 200 should relate to a later time at the GNSS receiver 100. In step 564, the processor 220 examines the result of the comparison in step 562. If the timestamp is not validated successfullythat is, if the timestamp relates to a time that is not later than the previously received timestampthen the method proceeds to step 566, in which the processor 220 declares detection of a replay attack, for instance in the form of an alert. In a replay attack, a malicious actor intercepts a data message and presents it to the server at a later time, in an attempt to trick the server into believing that the GNSS receiver is at a spurious (old) position.

[0166] On the other hand, if the timestamp is validated successfully, the method continues to step 570. In step 570, the processor 220 obtains the GNSS assistance data, in the manner discussed already above.

[0167] Finally, in step 580, the processor 220 calculates the position of the GNSS receiver at the time the measurements were made. It does this using the coarse position estimate obtained in step 510, the code phase measurements extracted from the data message in step 550, and the assistance data obtained in step 570. The dashed arrows indicate the flow of information (that is, the coarse position and code phases, respectively) from steps 510 and 550 to step 580.

[0168] It should be understood that the scope of the present disclosure is not limited to the examples described above. Many variations will be apparent to those skilled in the art, based on the foregoing description.

[0169] For instance, as mentioned previously, the GNSS measurements may be encoded in one data message (as in the examples above), or in multiple data messages.

[0170] Additionally, although in the examples above the GNSS receiver embedded a timestamp in the data message, in other examples there may be other ways to detect replay attacks. Instead of a timestamp, the GNSS receiver may maintain a monotonic counter (which continually increment or decrement its value). The processor of the GNSS receiver may embed the current value of the monotonic counter in the data message(s). At the remote server, the received counter value can be validated in essentially the same way as the timestamp in the example above. The processor of the remote server compares the currently received value of the counter with the immediately previously received value. If the currently received value is not subsequent to the previously received value (bearing in mind the directionincreasing or decreasingof the monotonic counter), then the processor of the remote server detects a replay attack.

[0171] In the example of FIG. 4 above, if the quality criterion is not satisfied in step 412, the method proceeds to step 420, in which the processor of the GNSS receiver attempts to calculate a position fix itself. However, this is optional, not essential. In some other examples, the processor might not be capable of calculating (not configured to calculate) a position fix itself. In a simplified example, in response to a failure to satisfy the quality criterion, the processor may do nothingfor example, it may wait for the next scheduled time at which it is supposed to report GNSS measurements to the remote server.

[0172] Moreover, even when the GNSS receiver is configured to attempt to calculate a position fix itself, it may test one or more additional criteria (in addition to the test of step 412) before doing so. For example, as mentioned above, the processor may check the availability of ephemeris data. In some circumstances, the processor might only attempt to calculate the position fix if valid ephemerides happen to be available already at the GNSS receiverfor example, from a previously decoded navigation data message. In other circumstances, the processor may attempt to resolve a lack of valid ephemerides by decoding the navigation data message. This may require keeping the GNSS receiver in a powered-on state for longer. The processor may also check the number of measurements in the second subset. If there are no such measurements or the number of them is below a threshold, for example, the processor may decide not to attempt a position fix (on the basis that the resulting position fix would be unlikely to be accurate enough in any event).

[0173] In the example described above with reference to FIG. 4, the quality criterion assessed in step 410 was based on carrier-to-noise power ratio. Of course, other quality criteria (or combinations of quality criteria) could be used. By way of example, the carrier-to-noise power ratio associated with each signal could be combined with a respective multipath indicator, to capture complementary information about the quality of the signals. Suitable multipath indicators include, but are not limited to, the variance of the carrier-to-noise power ratio over time. The different quality indicators may be combined in a variety of ways, so as to produce a single defined ranking of the measurements. For example, a weighted linear combination of the indicators could be used. Alternatively, a weighted combination of the squared values of the indicators could be used.

[0174] Different quality indicators or combinations of quality indicators may be chosen in different application scenarios, and/or the weighting applied to each quality indicator in a combination of quality indicators may be adjusted according to the application scenario. By way of example, a multipath indicator may be relatively more important in an urban applicationfor example, tracking a fleet of e-scooters in a city. Accordingly, the multipath indicator may be weighted to give it greater influence than a quality indicator based on the carrier-to-noise power ratio. Meanwhile, in a rural application scenariofor example, tracking of livestockthe multipath indicator may be relatively less important (because multipath is not such a significant confounding factor in the open countryside). Accordingly, in such an application, the multipath indicator may be weighted to give it relatively less influence than the carrier-to-noise power ratio.

[0175] The quality indicators discussed abovenamely, the multipath indicator and carrier-to-noise power ratioare quality indicators that can be determined at the GNSS receiver directly from the raw received GNSS signals. In particular, they are derivable from characteristics that are measurable by the signal processing unit 110. In some other examples, certain quality indicators may be calculated by the processor 120. The processor 120 may require assistance information in order to complete the calculations. For instance, satellite elevation may offer a useful quality indicator. All else being equal, signals from satellites at higher elevations tend to produce measurements of a higher quality than signals from satellites at low elevations. However, in order to determine satellite elevation, the processor 120 of the GNSS receiver must have at least almanac information available (to know the approximate positions of the satellites). Additionally, some information about the approximate position of the GNSS receiver must be available to the processor, in order to calculate the elevations of the satellites given their approximate positions. This could be based on a previously calculated position. If ephemerides are available, they may be used to calculate the positions of the satellite more accurately. However, typically, almanac data is more likely to be available, because it is transmitted by each satellite in the constellation and has a validity period of weeksmuch longer than ephemeris data.

[0176] Another potentially useful quality indicator that can be calculated based on almanac or ephemeris data is a measure of dilution of precision (DoP) for the set of satellites whose signals have been measured. Calculation of DoP requires both satellite positions and receiver position to be known, however an indicative measure of DoP may be calculated without reference to the position of the GNSS receiver.

[0177] Both individual quality indicators and combinations of quality indicators can also be combined with customer/developer preferencesfor example, to pre-select or prefer specific GNSS constellations.

[0178] In the examples described above, the processor 120 of the GNSS receiver adopted an approach of: first, ranking the measurements based on the one or more quality indicators; second, populating the first and second subsets based on the ranking; and third, defining a threshold in the one or more quality indicators (in particular, for the first subset) in order to decide whether the overall quality of the set of measurements was sufficient to justify transmitting the set to the remote device. It should be understood that these three steps are not necessarily applied in this order. For instance, in another example, the processor might first apply a threshold (based on the one or more quality indicators) to prune the list of measurements, before then ranking them and selecting the first and second subsets.

[0179] In general, the remote server of the examples above may be replaced with another remote devicethe processing need not be carried out at a server computer. For example, a user device such as a smart phone or tablet computer could be used in place of the remote server to calculate the position fix.

[0180] In the examples above, it was suggested that all of the measurements (in particular, code phase measurements) needed for a given position fix can be measured at the same epoch. This may be advantageous, since it can minimise the length of time that the GNSS receiver needs to be active to support each position fix. When all of the measurements come from a single epoch (or snapshot), it may be desirable (or necessary) to include at least five measurements in the first subset. The fifth measurement can then be used at the remote server to disambiguate which code is seen in the snapshot. However, this is not an absolute requirement. In other examples according to the present disclosure, the GNSS receiver may detect data bit boundaries and signal their timing to the remote device. The data bit boundaries can usually be identified at the receiver by tracking the respective GNSS signal for a sufficiently long duration. For GPS L1, for instance, given about 6 s of signal tracking, the receiver can identify the data bit boundaries and decode the time-of-week (ToW). In this case, a fifth GNSS measurement might not be necessary to disambiguate the code. Instead, the code can be disambiguated based on the knowledge of the frame and data boundaries in the longer duration of captured signal.

[0181] In general, in the flowcharts of FIGS. 3-5, the arrows between the steps do not necessarily imply a causal relationship between those steps. They merely indicate one exemplary order in which the steps may be performed. Method steps may be carried out in a different order from the exemplary order shown in the drawings.

[0182] It should be understood that various components illustrated in FIGS. 1-2 may be implemented in hardware, or software, or a mixture of both. Furthermore, some components may be grouped together in a given implementation or may be implemented separately. In the present implementation, block 105 is implemented entirely in hardware, block 110 is implemented partially in hardware, and the remaining components (downstream in the signal processing chain) are implemented in software. Other implementations are possible, which divide and distribute the various functions differently between hardware and software, or between different hardware components, software modules and/or processors running the software.

[0183] In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word comprising does not exclude the presence of elements or steps other than those listed in a claim. However, where the word comprising is used, this also discloses as a special case the possibility that the elements or steps listed are exhaustivethat is, the apparatus or method may consist solely of those elements or steps. The word a or an preceding an element does not exclude the presence of a plurality of such elements. The embodiments may be implemented by means of hardware comprising several distinct elements. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Furthermore, in the appended claims lists comprising at least one of: A; B; and C should be interpreted as (A and/or B) and/or C.

[0184] In flowcharts, summaries, claims, and descriptions relating to methods, the sequence in which steps are listed is not, in general, intended to be limiting on the order in which they are carried out. The steps may be performed in a different order to that indicated (except where specifically indicated, or where a subsequent step relies on the product of a preceding step). Nevertheless, the order in which the steps are described may in some cases reflect a preferred sequence of operations.

[0185] Furthermore, in general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device, although these are not limiting examples. While various aspects described herein may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0186] The embodiments described herein may be implemented by computer software executable by a data processor of the apparatus, such as in the processor entity, or by hardware, or by a combination of software and hardware. Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, or CD.

[0187] The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), gate level circuits and processors based on multi-core processor architecture, as non-limiting examples.

[0188] Embodiments as discussed herein may be practiced in various components such as integrated circuit modules. The design of integrated circuits is generally a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.