CN110572204A

CN110572204A - A-GNSS auxiliary data request method in Internet of things

Info

Publication number: CN110572204A
Application number: CN201911068322.9A
Authority: CN
Inventors: 鲁郁
Original assignee: Nuo Ling Technology (ltd) Co Ltd
Current assignee: Nuo Ling Technology (ltd) Co Ltd
Priority date: 2019-11-05
Filing date: 2019-11-05
Publication date: 2019-12-13
Anticipated expiration: 2039-11-05
Also published as: CN110572204B; WO2021088479A1

Abstract

the invention provides an A-GNSS auxiliary data request method in the Internet of things, which comprises the following steps: at the end of a GNSS acquisition search and when a sufficient number of satellite signals are acquired, a request is made to download GNSS assistance data for the satellites that are acquired and that do not have valid ephemeris. The method provided by the invention can avoid the request of unnecessary GNSS auxiliary data, thereby reducing the network connection number and data flow and reducing the power consumption. The terminal of the Internet of things requests the GNSS auxiliary data according to the GNSS satellite acquired and searched, and the size of data downloaded from the server is reduced. The invention can also adjust A-GNSS auxiliary data to adapt to the network protocol of the Internet of things, and reduce transmission interaction by 20 to 50 percent, thereby reducing the power consumption and the flow of the terminal. In addition, the format definition of the auxiliary data request message packet has strong applicability, unnecessary digits can be omitted, and the bit-level request setting effectively reduces the data volume.

Description

A-GNSS auxiliary data request method in Internet of things

Technical Field

The invention belongs to the technical field of positioning of the Internet of things, and relates to an A-GNSS auxiliary data request method in the Internet of things.

Background

a large number of terminals of the internet of things have positioning requirements, and the specific application scenes and the terminals comprise asset tracking, shared bicycles, electric vehicles, wearable equipment and the like. That is, a large number of commercially available mtc (large-scale internet of things) includes low-power wide area network technologies such as NB-IoT (narrowband internet of things), eMTC (enhanced machine type communication), and the like. How terminals in these new networks implement positioning functions is a new topic in this field.

Cellular internet of things (such as NB-IoT) will support massive amounts of terminals with limited network capacity. Due to these characteristics, the cellular internet of things requires the terminal to have the smallest data traffic. In addition, since most terminals of the internet of things (e.g., NB-IoT) use small-capacity batteries, the terminals also need to reduce data traffic as much as possible to achieve the purpose of saving power.

Compared with the previous terminal (such as a smart phone), the mtc (such as NB-IoT) terminal has the following characteristics:

1. the terminal has simple software and hardware, small storage capacity and low cost.

2. the terminal requires very low power consumption.

3. The traffic and the number of connections of the terminal are very limited.

4. A particular terminal supports only a very limited number of applications and functions.

Many internet of things terminals have the requirement of positioning. Applications requiring accuracy within 200 meters require positioning with GNSS signals. GNSS positioning requirements: (1) acquiring enough GNSS signals (at least 4), and then generating pseudo-range observations; (2) ephemeris data, which is used to calculate the position of the satellites and the clock bias. These two requirements must be satisfied simultaneously to achieve successful positioning, and the two requirements are not satisfied.

The ephemeris data may be demodulated from the GNSS signals or downloaded from the network in the form of GNSS assistance data (mainly real-time ephemeris and clock data), which may also be referred to as a-GNSS assistance data. As shown in fig. 1. Assisted GNSS or a-GNSS (Assisted GNSS) has been widely applied in the field of mobile phone positioning, which can greatly improve performance and reduce power consumption. For the terminal of the internet of things with the GNSS positioning function, the A-GNSS auxiliary data can obviously improve the GNSS performance and reduce the GNSS power consumption. For an internet of things terminal, a-GNSS assistance data is downloaded over the internet of things (e.g., NB-IoT). The real-time ephemeris data for each constellation may require approximately 1kB to 3kB, but the validity period of these data is only 2 to 4 hours. A terminal with frequent position fixes needs to download real-time ephemeris at least 6 times a day. These flows and connection times are negligible for the handset, but are significant for the internet of things terminal. Most internet of things terminals have extremely strict requirements on connection times, power consumption and flow. If 12kB of data is downloaded a day, the data size for a year is 4.4 MB. An example is as follows: t-mobile requires NB-IoT terminals to be traffic limited to 9MB per year. 4.4MB of A-GNSS assistance data is already in half. For another example, china telecom also has a relatively strict limit on the total number of connections per year of NB-IoT terminals. Obviously, the terminal of the internet of things is not suitable for downloading ephemeris in the smart phone.

it should be noted that the GNSS assistance data download requests (including those used in the first and second methods mentioned in lines 51-63 of the specification) existing in the industry are independent of the acquisition of the satellite search results. The auxiliary data download occurs prior to or concurrent with the acquisition of the star search, as shown in fig. 3. The existing methods have the advantages that the GNSS auxiliary data are downloaded before the satellite acquisition and search are finished, so that the GNSS receiver can perform positioning calculation by using the auxiliary data (satellite ephemeris data) and the satellite search result as soon as the satellite acquisition and search is finished, the time for first positioning can be reduced (1 second to several seconds), and better user experience is provided. The method is very reasonable on terminals such as mobile phones and the like, because GNSS auxiliary data is only about 2kB, and the time for first positioning is an important performance index for mobile phone users. But this method is not suitable for many applications of internet of things positioning. For example, if the terminal of the internet of things is indoors when receiving the positioning request, the result of the satellite acquisition is likely to be that enough satellite signals are not acquired, and in this case, even if the terminal has the assistance data, there is no way to position. The existing methods of assisting the data download request in this case would pay for unnecessary connections and data traffic.

when the terminal is outdoors, if the open area is not blocked, taking the GPS system as an example, the terminal of the Internet of things can predict that about 12 GPS satellites can be seen. For another example, for an internet of things terminal supporting both GPS and beidou, a maximum of about 25 satellite signals can be seen. Therefore, in the conventional method, as shown in fig. 2, before capturing and searching satellites, the terminal of the internet of things requires auxiliary data of all 12 GPS satellites (for a terminal only supporting GPS) or about 25 GPS and beidou satellites (for a terminal simultaneously supporting GPS and beidou). When the terminal of the internet of things is indoors, the positioning failure can be caused because enough satellites cannot be acquired, but a large amount of flow is wasted for downloading satellite data.

in addition, the existing A-GNSS auxiliary data transmission protocol is not suitable for the application of the Internet of things. The existing A-GNSS assistance data transmission protocol generally has two types of methods:

A first method. The support for a-GNSS in the existing 3GPP standard protocol (e.g. LPP protocol) is mainly for smartphone applications, and needs to support multiple positioning technologies (GNSS, LTE OTDOA, WIFI, etc.), and there are multiple types of data (e.g. dedicated messages inquiring about positioning modes supported by the terminal, and various data or information about GNSS L2 and L5 signals, which are not suitable for low-cost terminals of internet of things), and different assistance data requests use different data packets and formats. The protocol is complex, has more redundancy, can increase the connection times, flow and power consumption, and is not suitable for most of the applications of the Internet of things. In addition, such data protocols are generally defined for Control planes, and if used in User planes, another protocol, such as SUPL, is required. Most applications of the internet of things are in user plane, so the protocols are not suitable for the applications of the internet of things.

A second method. The GNSS chip manufacturer may provide assistance data download using custom data protocols, such as parameter definitions of requested data in the disclosure of a GNSS manufacturer as shown in FIG. 2. However, these protocols are also for mobile phones and are not specifically designed for the internet of things, such as the use of HTTP (or HTTPs) over TCP. If the terminal of the internet of things needs to support the LPP/SUPL or HTTP over TCP/IP, the software complexity, storage and power consumption of the terminal can be greatly increased. In addition, the message packet of the request of the protocols is large, the protocols have no flexibility, and the protocols are not suitable for the terminal of the internet of things with extremely high requirements on the simplicity, the flow, the power consumption and the connection number of software.

disclosure of Invention

In order to solve the problems, the invention discloses an A-GNSS auxiliary data request method in the Internet of things, and the method is used for reducing the power consumption of the terminal of the Internet of things on the basis of realizing the positioning function by considering that a power amplifier is needed when the terminal sends data, and the power consumption when the terminal sends data is more than several times (for example, 10 times) of the power consumption when the terminal receives the data.

In order to achieve the purpose, the invention provides the following technical scheme:

An A-GNSS auxiliary data request method in the Internet of things comprises the following steps:

At the end of a GNSS acquisition search and when a sufficient number of satellite signals are acquired, a request is made to download GNSS assistance data for the satellites that are acquired and that do not have valid ephemeris.

Further, the method specifically comprises the following steps:

Step 1, a terminal receives a positioning request and opens a GNSS receiver;

step 2, starting to capture star searching;

Step 3, capturing and searching stars is finished;

Step 4, when judging that enough satellite signals are captured, the terminal requests a network to download GNSS auxiliary data of the captured satellites without valid ephemeris, calculates the position and carries out positioning; when the terminal judges that a sufficient number of satellite signals are not acquired, the terminal does not request the network to download the GNSS auxiliary data, and the positioning fails.

Further, after the GNSS finishes capturing and satellite searching, the downloaded GNSS auxiliary data is judged to be auxiliary data related to the satellite; when there is assistance data that is not related to the satellite, that can help in the star search and is not currently in the terminal, the terminal makes a request download to the server before the star search proceeds.

furthermore, the downloaded GNSS assistance data is adjusted at the server side, reducing the data volume.

Further, the adjustment is performed by: data for several satellites is removed.

Further, data of a plurality of satellites is removed through the following logic:

if the number of the searched satellite signals is larger than or equal to a threshold value, one or more satellites which have the smallest contribution to the positioning accuracy are removed, and the number of the satellites which must be reserved is larger than or equal to the threshold value.

Further, the one or more satellites with the smallest contribution to the positioning accuracy satisfy any one of the following conditions:

(i) the elevation angle is lowest;

(ii) Weakest signal or lowest signal-to-noise ratio

Further, in the step 3, if the number of the searched satellite signals is less than the threshold value, any searched satellite is not removed.

Further, the server queries the number of bytes transmitted by the network protocol each time, and adjusts the network protocol only when the server determines that the conditions are met, where the conditions include at least one of the following conditions:

(i) The last data packet is less than a certain number of bytes;

(ii) the last packet is less than a certain percentage of the full-length packet.

Further, in step 4, when the terminal sends the request message, the requested auxiliary information indicates that the auxiliary information is encoded by bits.

Compared with the prior art, the invention has the following advantages and beneficial effects:

1. The method provided by the invention can avoid the request of unnecessary GNSS auxiliary data, thereby reducing the network connection number and data flow and reducing the power consumption.

2. The terminal of the Internet of things requests the GNSS auxiliary data according to the GNSS satellite acquired and searched, and the size of data downloaded from the server is reduced.

3. The invention can adjust A-GNSS auxiliary data to adapt to the network protocol of the Internet of things, and reduce transmission interaction by 20 to 50 percent, thereby reducing the power consumption and flow of the terminal.

4. The format definition of the auxiliary data request message packet enables various auxiliary data requests to be supported by one format, the applicability is strong, only information bits needing to be obtained can be sent, unnecessary bits are omitted, the size of the request message packet is greatly reduced through bit-level request setting, the data volume is effectively reduced, the satellite number is assigned, and the size of A-GNSS auxiliary data is reduced.

Drawings

fig. 1 is an architecture diagram of a terminal of the internet of things for searching satellite signals and downloading GNSS assistance data.

FIG. 2 is an example of a prior GNSS assistance data request parameter definition.

FIG. 3 is a timing diagram illustrating GNSS assistance data downloading and satellite searching in the prior art. Wherein (a) is a schematic diagram under the condition that sufficient satellite positioning is successfully acquired, and (b) is a schematic diagram under the condition that sufficient satellite positioning is not acquired. This figure exemplifies a terminal supporting only GPS. For the terminals supporting the GPS and the beidou, the total number of visible satellites in the legend becomes 25, that is, ephemeris of 25 GNSS satellites needs to be downloaded.

Fig. 4 is a GNSS assistance data download and satellite search timing chart in the method for requesting a-GNSS assistance data in the internet of things according to the present invention, wherein (a) is a schematic diagram showing a case where sufficient satellite positioning is successfully acquired, and (b) is a schematic diagram showing a case where sufficient satellite positioning is not successfully acquired. This figure exemplifies a terminal supporting only GPS. For terminals supporting GPS and beidou, the number of satellites captured in the legend becomes 10, i.e., 10 satellites from 25 GNSS satellites in view.

Fig. 5 is a flowchart illustrating steps of a method for requesting assistance data of an a-GNSS in the internet of things according to the present invention.

fig. 6 is a diagram illustrating the a-GNSS server reducing the amount of data and the number of exchanges by removing satellite data.

fig. 7 is a flowchart illustrating the adjustment of the size of the auxiliary data to match the network protocol transmission according to the second embodiment.

Fig. 8 is a format example of a terminal request message packet in the third embodiment.

Detailed Description

The technical solutions provided by the present invention will be described in detail below with reference to specific examples, and it should be understood that the following specific embodiments are only illustrative of the present invention and are not intended to limit the scope of the present invention. Additionally, the steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions and, although a logical order is illustrated in the flow charts, in some cases, the steps illustrated or described may be performed in an order different than here.

The first embodiment is as follows:

the invention determines the downloading of the GNSS auxiliary data by the result of the GNSS capturing satellite searching, so as to greatly reduce the downloading connection request and the downloading data quantity of the GNSS auxiliary data in practical application. The invention provides an A-GNSS auxiliary data request method in the Internet of things, which only requests to download auxiliary data of a satellite which is captured and has no valid ephemeris when GNSS capturing satellite searching is finished and a sufficient number of satellite signals are captured. Specifically, the method comprises the following conditions:

1. At the start and during the GNSS acquisition satellite search, the terminal does not request the network to download GNSS assistance data even if the existing GNSS ephemeris has failed or does not exist.

2. After the GNSS acquisition and satellite search is finished (generally, the satellite search process takes several hundred milliseconds to several seconds), if a sufficient number of satellite signals are not acquired (the number can be set as required, for example, less than four satellite signals), the positioning attempt has failed to be confirmed, and the terminal does not request the network to download GNSS assistance data, as shown in fig. 4 (b), so that unnecessary network connection and traffic are saved. Since some internet of things terminal parts are even indoors at all times, not enough GNSS signals are captured when a positioning request occurs. The method of the invention can avoid the unnecessary GNSS auxiliary data request under the condition, thereby achieving the purpose of reducing the network connection number and the flow.

3. If a sufficient number of satellite signals (e.g., at least four satellite signals) are acquired, the terminal requests the network to download GNSS assistance data, and only requests to download assistance data for satellites that are acquired and have no valid ephemeris.

For various reasons (for example, shielding of buildings or human bodies, or loss of receivers of terminals, or sensitivity limitation of terminals, or radio frequency interference), the terminals of the internet of things cannot necessarily capture all visible satellite signals (about 12 GPS satellites for terminals only supporting GPS; about 25 GPS and beidou satellites for terminals supporting both GPS and beidou), and in many cases, the number of captured satellites is far less than that of all visible satellites. Therefore, the terminal of the internet of things only needs to request the auxiliary data of the acquired satellite, so that the data flow can be greatly reduced.

For example, for a terminal that only supports GPS, after the GNSS acquisition search ends, GPS satellites 3, 6, 17, 22, 25, 30 are acquired. If the terminal does not have valid ephemeris for these 6 satellites, the terminal requests the network to download assistance data for these 6 satellites, as shown in fig. 4. Under the conventional assistance data downloading method, in this example, the terminal requests assistance data at the beginning of the acquisition of a satellite, requests (or the a-GNSS server determines) assistance data for 12 satellites (3, 6, 17, 22, 25, 30, 15, 27, 1, 8, 19, 31) predicted to be visible at the approximate location of the terminal, and even the a-GNSS server transmits ephemeris for all 32 satellites, which obviously has a larger data size and consumes more energy. The method of the present invention requires only the assistance data of 6 satellites. In this example, the method of the present application requires at least 1/2 of the flow of the existing method. Similar examples may also occur on terminals that support both GPS and beidou.

The terminal does not have to download assistance data for satellites for which there is valid ephemeris, e.g. in some cases (e.g. assistance data for some satellites was requested an hour ago), assistance data for some satellites has not been invalidated in the terminal, nor do they need to be requested. For example, after the GNSS satellite acquisition search is finished, GPS satellites 3, 6, 17, 22, 25, 30 are acquired. For example, the terminal now has valid ephemeris for satellites 3 and 17, so that the terminal only needs to request the network for downloading assistance data for satellites 6, 22, 25, 30. This further reduces the amount of data downloaded by the terminal of the internet of things.

based on the above description, the method for requesting a-GNSS assistance data in the internet of things according to the present invention, as shown in fig. 5, includes the following steps:

Step 1, a terminal receives a positioning request and opens a GNSS receiver;

Step 2, starting to capture star searching;

Step 3, capturing and searching stars are finished;

the assistance data of the A-GNSS mainly comprises the following data: (1) current GPS time or UTC time; (2) a coarse location of the terminal; (3) clock parameters in the GNSS satellite ephemeris; (4) satellite orbit parameters in a GNSS satellite ephemeris; (5) long time almanac of GNSS satellites. As a further improvement, the request for assistance data (including orbit parameters and clock parameters in ephemeris) associated with the satellite is determined based on the satellite search results of the terminal, after the satellite search is completed. Assistance data not related to satellites (including GPS or UTC time, rough location of the terminal), if it is possible to assist the star search (including reducing the star search time) without the terminal currently having such information, the terminal needs to request from the server before the star search can take place.

Example two:

Based on the first embodiment, the present example further adjusts the GNSS assistance data to be downloaded, so as to further reduce power consumption and traffic.

The embodiment mainly reduces the data volume needing to be transmitted by removing satellite data, thereby achieving the purpose of reducing power consumption. These two ways may be used alternatively or together as desired. These two modes are explained below.

For example, as shown in fig. 6, the a-GNSS raw assistance data has 3200 bytes, and the maximum data amount per transmission of a certain network protocol used is 1024 bytes, so that 4 transmissions are required (4 interactions between the terminal and the a-GNSS server, 4 times for turning on the power amplifier of the terminal), and 78 bytes are required for the request (4) on the left side of fig. 6. The present invention proposes that the a-GNSS server can process the raw assistance data, for example, by removing one satellite of data (transmitting 15 satellites of data instead of 16), which can reduce the amount of data to 3050 bytes without substantially affecting performance, thus requiring only 3 transmissions (as shown on the right side of fig. 6). Therefore, the power consumption of the terminal can be reduced by about 25%, and the exchange times and the power consumption are obviously reduced.

The method for reducing the data volume by removing one or more satellites can be implemented on an internet of things terminal or an A-GNSS server, and the logic is as follows:

(1) if the number of the searched satellite signals is less than a threshold value (for example, less than 8 satellites, set according to requirements), not removing any searched satellite;

(2) If the number of satellite signals found is greater than or equal to a threshold (e.g., greater than 8 satellites), one or more satellites that contribute least to the positioning accuracy are removed (but the number of satellites that must be retained is at least the threshold), and for example, either or a combination of the following two decision criteria may be used to determine which satellites to remove: (i) the satellite or satellites with the lowest elevation angle are removed, (ii) the satellite or satellites with the weakest signal (lowest signal-to-noise ratio) are removed.

this process occurs after the star search results are generated, thus avoiding the blind reduction of useful satellites.

This example also provides another way to reduce the amount of data that needs to be transmitted: the number of satellites is unchanged (16 in this embodiment) but the transmission data per satellite is reduced. For example, since the first and second order drift rates of satellite clocks are typically small (the second order drift rate is substantially 0), the 3 bytes (per satellite) they occupy can be compressed to 1 byte (per satellite). For another example, information indicating the number of GPS satellite weeks, the health of the satellite, and the measurement accuracy of the user may not be transmitted.

as another example, the accuracy of some track parameters (e.g., the square root of the long half-axis of the track, the average angular velocity correction value) may be reduced. By these methods, the amount of data to be transferred is reduced appropriately, thereby reducing the number of data packets exchanged with the server.

The terminal and the A-GNSS server communicate by using a network protocol suitable for the Internet of things, such as CoAP (over UDP). In the embodiment, the raw assistance data of the A-GNSS is processed to match with a network protocol (such as CoAP) of the Internet of things, and each data transmission is fully utilized, so that the power consumption and the flow of the terminal are greatly reduced. As an improvement, the invention needs to introduce precondition when reducing data volume, so as to actually obtain the effect of reducing data packets. I.e., matching the number of bytes per transmission of the network protocol based on the number of bytes per transmission of the network protocol. As shown in fig. 7, the specific steps are as follows:

(1) The A-GNSS server generates assistance data;

(2) the A-GNSS server inquires the byte number of each transmission of the network protocol;

(3) Judging that when the last data packet is less than a certain number of bytes or less than a certain proportion of the full-length data packet (for example, the full-length data packet is 1000 bytes, and the last data packet is < 1000 x 30% (= 300)), adjusting the auxiliary data to match the number of bytes transmitted by the network protocol each time, and reducing the data amount so as to finally achieve the effect of reducing the data packet;

(4) the A-GNSS server transmits the assistance data to the terminal through a network protocol.

The other technical features in this example are the same as those in the first embodiment.

Example three:

On the basis of the first embodiment or the second embodiment, the invention can also reduce the auxiliary data volume by simplifying and compressing the auxiliary information:

When the terminal sends the request message, the requested auxiliary information indication is simplified and compressed. This step is performed when satellite information is requested after the star search is completed.

For each side information, a bit is typically used to indicate that "0" indicates that the server is not required to send the information, and "1" indicates that the server is required to send the information. As shown in fig. 8, information bits expressed in bits are listed.

For the clock parameters in ephemeris, GPS, Beidou (Beidou), Galileo and Glonass use two bits each, for 8 bits in total. "00" indicates that the clock parameters in any satellite ephemeris in the constellation are not needed, "10" indicates that the clock parameters in all satellite ephemeris in the constellation are needed, "01" indicates that the clock parameters in satellite ephemeris in the constellation that the server considers the terminal to be able to see, "11" indicates that the clock parameters in satellite ephemeris specified by the terminal in the constellation are needed, in which case the request information needs to include a bit vector for the constellation, e.g., the GPS needs one 32 bits, i.e., four bytes, each bit indicates whether the corresponding GPS satellite needs, "0" indicates that the ephemeris clock parameters for the GPS satellite are not needed, "1" indicates that the ephemeris clock parameters for the satellite are needed.

for example, a terminal only supports the GPS and Beidou (Beidou) systems, and searches for a satellite to find GPS satellites 1, 3, 5, 7, 9, 11 and Beidou satellites 3, 6, 9, 12, 15, 18. When satellite assistance information is requested, the 8 bits for the constellation are set to 11110000 (the first 11 indicates that the terminal specifies the clock parameters for a GPS satellite, the second 11 indicates that the terminal specifies the clock parameters for a Beidou satellite, then 00 indicates that no Galileo satellites are needed, and finally 00 indicates that no Glonass satellites are needed. then the next 32 bits indicate which GPS satellites 'clock parameters 1010101010100000 … 00, and the next 32 bits indicate which Beidou satellites' clock parameters 001001001001001001000 … 00.

for the satellite orbit parameter request in ephemeris, the same method as the clock parameter request described above is used. Which satellite orbit parameters of which satellites are required are also indicated by means of 8 bits + a number of 32 bits.

The invention can simplify any one of the clock parameter and the satellite orbit parameter by using the bit, can effectively compress data and reduce the data volume, and can also simplify the clock parameter and the satellite orbit parameter at the same time to obtain smaller data volume.

The other technical characteristics in the embodiment are the same as those in the first or second embodiment.

The technical means disclosed in the invention scheme are not limited to the technical means disclosed in the above embodiments, but also include the technical scheme formed by any combination of the above technical features. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and such improvements and modifications are also considered to be within the scope of the present invention.

Claims

1. The method for requesting the A-GNSS auxiliary data in the Internet of things is characterized by comprising the following steps:

2. The method for requesting a-GNSS assistance data in the internet of things according to claim 1, comprising the steps of:

step 1, a terminal receives a positioning request and opens a GNSS receiver;

step 2, starting to capture star searching;

Step 3, capturing and searching stars is finished;

3. the method for requesting a-GNSS assistance data in the internet of things according to claim 1 or 2, wherein the downloaded GNSS assistance data is determined to be assistance data related to satellites after GNSS satellite acquisition and search are completed; when there is assistance data that is not related to the satellite, that can help in the star search and is not currently in the terminal, the terminal makes a request download to the server before the star search proceeds.

4. the method for requesting a-GNSS assistance data in the internet of things according to claim 1, wherein: the downloaded GNSS assistance data is adjusted at the server side, so that the data volume is reduced.

5. The method of claim 4, wherein the adjusting is performed by: data for several satellites is removed.

6. the method of claim 5, wherein the data of the satellites is removed by the following logic:

7. The method for requesting a-GNSS assistance data in the internet of things according to claim 6, wherein the one or more satellites with the smallest contribution to positioning accuracy satisfy any one of the following conditions:

(i) The elevation angle is lowest;

(ii) the weakest signal or lowest signal-to-noise ratio.

8. the method of claim 5, wherein if the number of the searched satellite signals is less than a threshold, no satellite is removed.

9. the method for requesting a-GNSS assistance data in the internet of things according to any one of claims 4 to 8, wherein: the server firstly inquires the byte number transmitted by the network protocol each time, and the adjustment is carried out when the judgment meets the conditions, wherein the conditions comprise at least one of the following conditions:

(i) the last data packet is less than a certain number of bytes;

10. The method as claimed in claim 2, wherein in step 4, when the terminal sends the request message, the requested assistance information is indicated by bit coding.