CN110572204B

CN110572204B - 物联网中的a-gnss辅助数据请求方法

Info

Publication number: CN110572204B
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: 2020-06-09
Anticipated expiration: 2039-11-05
Also published as: WO2021088479A1; CN110572204A

Abstract

本发明提供了物联网中的A‑GNSS辅助数据请求方法，包括：在GNSS捕获搜星结束且捕获到足够数量的卫星信号时，请求下载被捕获而且没有有效星历的卫星的GNSS辅助数据。本发明提供的方法能够避免请求不必要的GNSS辅助数据，从而减少网络连接数和数据流量，降低功耗。物联网终端根据捕获搜索到的GNSS卫星来请求GNSS辅助数据，减少从服务器下载的数据大小。本发明还能够调整A‑GNSS辅助数据来适应物联网的网络协议，减少传输交互20%到50%，进而减小终端功耗和流量。此外辅助数据请求消息包的格式定义适用性强，且能够省略掉不必要的数位，而比特级的请求设定有效减小数据量。

Description

物联网中的A-GNSS辅助数据请求方法

技术领域

本发明属于物联网定位技术领域，涉及物联网中的A-GNSS辅助数据请求方法。

背景技术

大量的物联网终端有定位需求，具体应用的场景和终端有资产跟踪、共享单车、电动车、可穿戴设备等等。即将大量商用的mMTC（大规模物联网）包括NB-IoT（窄带物联网）,eMTC（增强型机器类型通信）等低功耗广域网技术。在这些新型网络中的终端如何实现定位功能是这个领域的新课题。

蜂窝物联网（比如NB-IoT）将用有限的网络容量支持海量的终端。由于这些特点，蜂窝物联网需要终端有尽量小的数据流量。另外，由于物联网（比如NB-IoT）终端多数使用小容量的电池，终端也需要尽量减少数据流量以达到省电的目的。

和以前的终端（例如智能手机）相比，mMTC（例如NB-IoT）的终端具有以下特点：

1.终端的软硬件简单，存储容量小，成本低。

2.终端要求很低功耗。

3.终端的流量和连接次数非常有限。

4.一个特定终端只支持非常有限的应用程序和功能。

很多物联网终端会有定位的需求。精度要求在200米以内的应用需要用GNSS信号定位。GNSS定位要求：（1）捕获足够的GNSS信号（至少4个），然后产生伪距等观测量；（2）星历数据，用来计算卫星的位置和时钟偏差。这两个要求必须要同时满足才能定位成功，缺一不可。

星历数据可以从GNSS信号中解调出来，或者以GNSS辅助数据（主要是实时星历和时钟数据）的形式从网络下载下来，后者又可称为A-GNSS辅助数据。如图1所示。辅助GNSS，或者A-GNSS（Assisted GNSS）已经大量应用在手机定位领域，能够大幅提高性能，减小功耗。对于带GNSS定位功能的物联网终端，A-GNSS辅助数据会显著提高GNSS性能以及降低GNSS的功耗。对于物联网终端，A-GNSS辅助数据通过物联网（例如NB-IoT）下载。每个星座的实时星历数据大概需要1kB到3kB，但这些数据的有效期只有2到4小时。所以一个定位频繁的终端需要每天至少下载6次实时星历。这些流量和连接次数对于手机来说可以忽略，但对于物联网终端是很大的。绝大部分物联网终端对连接次数、功耗和流量都有极其严格的要求。如果一天下载12kB数据，一年的数据量就是4.4MB。一个例子：T-mobile要求NB-IoT终端每年的流量限制在9MB。4.4MB的A-GNSS辅助数据已经占了一半。又例如，中国电信对NB-IoT终端每年的总连接次数也有比较严格的限制。很显然，物联网终端中并不适用采用智能手机中对星历的下载方式。

需要指出的是，行业里现有的GNSS辅助数据下载请求（包括在说明书51-63行提及的第一种和第二种方法里使用的）都是独立于捕获搜星结果的。辅助数据下载是在捕获搜星之前发生，或者和捕获搜星同时发生，如图3所示。现有这些方法的优势是GNSS辅助数据在捕获搜星结束前就已经下载完成，这样捕获搜星一完成，GNSS接收机就可以用辅助数据（卫星星历数据）和搜星结果进行定位计算，这样可以减少首次定位的时间（1秒到数秒），提供更好的用户体验。这种方法在手机等终端上是非常合理的，因为GNSS辅助数据只有2kB左右，而首次定位的时间对手机用户是重要性能指标。但这种方法不适合很多物联网定位的应用。例如，如果物联网终端在收到定位请求的时候在室内，捕获搜星的结果很可能是没有捕获到足够多的卫星信号，在这种情况下，即使终端有辅助数据，也没有办法定位。所以现有的辅助数据下载请求的方法在这种情况下会付出了不需要的连接和数据流量。

当在室外时，如果是开阔地带没有遮挡，以GPS系统为例，物联网终端可以预测能看到大约12颗GPS卫星。又例如，对于同时支持GPS和北斗的物联网终端，最多能看到大约25颗卫星信号。所以以往的方法如图2所示，物联网终端在捕获搜星之前要求所有这12颗GPS卫星（对只支持GPS的终端）或者大约25颗GPS和北斗卫星（对同时支持GPS和北斗的终端）的辅助数据。而当物联网终端在室内时，由于不能捕获到足够的卫星，会导致定位失败，但却浪费了大量流量下载卫星数据。

此外，现有的A-GNSS辅助数据传输协议并不适用于物联网应用。现有的A-GNSS辅助数据传输协议一般有两类方法：

第一种方法。现有的3GPP标准协议里关于A-GNSS的支持（例如LPP协议）主要针对智能手机应用，需要支持多种定位技术（GNSS，LTE OTDOA，WIFI，等），而且数据种类多（例如有询问终端支持的定位模式的专用消息，还有各种关于GNSS L2和L5信号以及的数据或者信息，这些都不适用于低成本的物联网终端），不同的辅助数据请求使用不同的数据包和格式。这种协议复杂，冗余多，会增加连接次数，流量和功耗，不适于大多数物联网应用。另外，这类数据协议一般是给Control plane定义的，如果要用在User plane，还需要另一个协议，例如SUPL。物联网绝大多数应用是在user plane，所以这些协议不适合物联网的应用。

第二种方法。GNSS芯片厂商提供的辅助数据下载一般采用自定义的数据协议，例如，图2所示的一家GNSS厂商的公开资料中的请求数据的参数定义。但这些协议也是针对手机，没有针对物联网做出了专门设计，例如需要使用HTTP (或者HTTPS) over TCP。如果物联网终端需要支持上述的LPP/SUPL或者HTTP over TCP/IP，会大幅增加终端的软件复杂度，存储和功耗。另外，这些协议的请求的消息包较大，而且它不具备一些灵活性，这些协议都不适合对软件的简易、流量、功耗和连接数有极高要求的物联网终端。

发明内容

为解决上述问题，本发明公开了物联网中的A-GNSS辅助数据请求方法，考虑到终端发送数据时需要功率放大器，终端发送时的功耗是其接收时的功耗的数倍（例如10倍）以上，所以本发明从减小终端发送的次数和数据量（例如减少NB-IoT终端请求A-GNSS的次数和请求的数据量）两方面出发，以在实现定位功能的基础上降低物联网终端的功耗。

为了达到上述目的，本发明提供如下技术方案：

物联网中的A-GNSS辅助数据请求方法，包括如下步骤：

在GNSS捕获搜星结束且捕获到足够数量的卫星信号时，请求下载被捕获而且没有有效星历的卫星的GNSS辅助数据。

进一步的，具体包括如下步骤：

步骤1，终端收到定位请求，打开GNSS接收机；

步骤2，开始捕获搜星；

步骤3，捕获搜星结束；

步骤4，当判断捕获到足够数量的卫星信号时，终端向网络请求下载被捕获而且没有有效星历的卫星的GNSS辅助数据，计算位置，进行定位；当判断未捕获到足够数量的卫星信号时，终端不对网络请求下载GNSS辅助数据，定位失败。

进一步的，在GNSS捕获搜星结束后判断下载的GNSS辅助数据为和卫星相关的辅助数据；当存在和卫星无关的能够帮助搜星且当前不在终端中的辅助数据时，终端在搜星进行之前向服务器进行请求下载。

进一步的，被下载的GNSS辅助数据在服务器端进行调整，减少数据量。

进一步的，所述调整通过如下方式进行：去掉若干卫星的数据。

进一步的，通过如下逻辑去掉若干卫星的数据：

如果搜到的卫星信号个数大于或者等于一个阈值时，去掉对定位精度贡献最小的一颗或者多颗卫星，必须保留的卫星数量大于或等于阈值。

进一步的，所述定位精度贡献最小的一颗或者多颗卫星满足以下条件中的任意一种：

（i）仰角最低；

（ii）信号最弱或信噪比最低

进一步的，所述步骤3中如果搜到的卫星信号个数少于阈值时不去掉任何搜到的卫星。

进一步的，服务器查询网络协议每次传输的字节数，判断符合条件时才进行调整，所述条件包括以下条件中的至少一种：

（i）最后一个数据包少于一定的字节数；

（ii）最后一个数据包少于全长数据包的一定比例。

进一步的，所述步骤4中，终端发送请求消息时，请求的辅助信息指示通过比特编码。

与现有技术相比，本发明具有如下优点和有益效果：

1.本发明提供的方法能够避免请求不必要的GNSS辅助数据，从而减少网络连接数和数据流量，降低功耗。

2.物联网终端根据捕获搜索到的GNSS卫星来请求GNSS辅助数据，减少从服务器下载的数据大小。

3. 本发明能够调整A-GNSS辅助数据来适应物联网的网络协议，减少传输交互20%到50%，进而减小终端功耗和流量。

4. 辅助数据请求消息包的格式定义使得能用一种格式支持各种辅助数据请求，适用性强，且能够只发送需要获取的信息比特位，省略掉不必要的数位，比特级的请求设定大大减小了请求消息包的大小，有效减小数据量指定卫星编号减少了A-GNSS辅助数据的大小。

附图说明

图1为物联网终端搜索卫星信号和下载GNSS辅助数据架构图。

图2为现有的GNSS辅助数据请求参数定义示例。

图3为现有技术中GNSS辅助数据下载和搜星时序图。其中（a）为捕获到足够卫星定位成功状况下示意图，（b）为未捕获到足够卫星定位失败状况下示意图。本图以只支持GPS的终端为例。对于支持GPS和北斗的终端，图例中总的可见卫星数变为25颗，即需下载２５颗GNSS卫星的星历。

图4为本发明提供的物联网中的A-GNSS辅助数据请求方法中GNSS辅助数据下载和搜星时序图，其中（a）为捕获到足够卫星定位成功状况下示意图，（b）为未捕获到足够卫星定位失败状况下示意图。本图以只支持GPS的终端为例。对于支持GPS和北斗的终端，图例中捕获的卫星数目变为10颗，即从25颗GNSS可见星中捕获到10颗。

图5为本发明提供的物联网中的A-GNSS辅助数据请求方法步骤流程图。

图6为A-GNSS服务器通过去除卫星数据减小数据量和交换次数示意图。

图7为实施例二中调整辅助数据大小以匹配网络协议传输的流程图。

图8为实施例三中终端请求消息包的格式示例。

具体实施方式

以下将结合具体实施例对本发明提供的技术方案进行详细说明，应理解下述具体实施方式仅用于说明本发明而不用于限制本发明的范围。另外，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一：

本发明通过GNSS捕获搜星的结果来决定GNSS辅助数据的下载，以在实际应用中大量减少GNSS辅助数据下载连接请求和下载的数据量。本发明提供了物联网中的A-GNSS辅助数据请求方法，只有在GNSS捕获搜星结束且捕获到足够数量的卫星信号时只请求下载被捕获而且没有有效星历的卫星的辅助数据。具体的说，包括如下几个条件：

1.在GNSS捕获搜星开始及过程中，即使现有的GNSS星历已经失效或者不存在，终端不对网络请求下载GNSS辅助数据。

2.在GNSS捕获搜星结束后（一般会搜星的过程需要数百毫秒到数秒），如果没有捕获到足够数量的卫星信号（数量可根据需要设定，例如，少于四个卫星信号），此次定位尝试已经确认失败，终端不对网络请求下载GNSS辅助数据，如图4（b）所示，这样节省了不必要的网络连接和流量。由于某些物联网终端部分甚至全部时间是在室内，当定位请求发生时，捕获不了足够的GNSS信号。本发明申请的方法可以在这种情况下避免请求不必要的GNSS辅助数据，从而达到减少网络连接数和流量的目的。

3.如果捕获到足够数量的卫星信号（例如，至少四个卫星信号），终端向网络请求下载GNSS辅助数据，而且只请求下载被捕获而且没有有效星历的卫星的辅助数据。

由于各种原因（例如，建筑物或者人体等的遮挡，或者终端的接收机损失，或者终端的灵敏度限制，或者射频干扰），物联网终端不一定能捕获所有的可见卫星信号（对只支持GPS的终端，大约12颗GPS卫星；对同时支持GPS和北斗的终端, 大约２５颗GPS和北斗卫星），在很多时候，捕获的卫星数远远少于所有的可见卫星数量。因此，本发明申请提出物联网终端只需要请求已经捕获的卫星的辅助数据，这会大幅减少数据流量。

例如，，对于一个只支持GPS的终端，GNSS捕获搜星结束后，捕获了GPS卫星3，6，17，22，25，30。如果终端没有这6颗卫星的有效星历，终端会向网络请求下载这6颗卫星的辅助数据，如图4所示。在以往的辅助数据下载方法下，在这个例子中，终端在捕获搜星开始时请求辅助数据，会请求（或者A-GNSS服务器决定）在终端大概位置上预测能看到的12颗卫星（3，6，17，22，25，30，15，27，1，8， 19，31）的辅助数据，甚至A-GNSS服务器会发送所有32颗卫星的星历，显然具有更大的数据量，需要消耗更多的能量。本发明申请的方法只需要请求6颗卫星的辅助数据。在这个范例中，本发明申请的方法所需要的流量至少是现有方法流量的1/2。类似的例子也可以在同时支持GPS和北斗的终端上出现。

终端不用下载存在有效星历的卫星的辅助数据，例如在某些情况下（例如一小时前请求过一些卫星的辅助数据），有些卫星的辅助数据在终端里还没有失效，也不需要请求它们。例如，GNSS捕获搜星结束后，捕获了GPS卫星3，6，17，22，25，30。例如终端现存有卫星3和17的有效星历，这样终端仅需要向网络请求下载卫星6，22，25，30的辅助数据。这就进一步减少了物联网终端下载的数据量。

基于上述说明，本发明提供的物联网中的A-GNSS辅助数据请求方法，如图5所示，包括如下步骤：

步骤1，终端收到定位请求，打开GNSS接收机；

步骤2，开始捕获搜星；

步骤,3，捕获搜星结束；

A-GNSS的辅助数据主要包含以下几种：（1）当前的GPS时间或者UTC时间；（2）终端的粗略位置；（3）GNSS卫星星历中的时钟参数；（4）GNSS卫星星历中的卫星轨道参数；（5）GNSS卫星的长时历书。作为进一步的改进，和卫星相关的辅助数据（包括星历中的轨道参数和时钟参数）的请求根据终端的搜星结果来决定，放在搜星完成后。而和卫星无关的辅助数据（包括GPS或UTC时间，终端的粗略位置），如果能够辅助搜星（包括减少搜星时间）而终端当前没有这些信息，终端需要在搜星进行之前向服务器进行请求。

实施例二：

在实施例一的基础上，本例进一步对需要下载的GNSS辅助数据进行调整，以进一步减小功耗和流量。

本例主要通过去掉卫星数据这种方式来减小需要传输的数据量，从而达到降低功耗的目的。这两种方式可根据需要择一或共同使用。以下针对这两种方式一一说明。

例如，如图6所示，A-GNSS原始辅助数据有3200字节，而所用的某种网络协议每次传输的最大数据量是1024字节，这样需要4次传输（4次终端和A-GNSS服务器的交互，终端的功率放大器需要打开4次），图6左侧需request（4）再发送78个字节。本发明提出A-GNSS服务器可以对原始辅助数据进行处理，例如去掉一颗卫星的数据（传输15颗卫星的数据，而不是16颗），这就可以在基本不影响性能的情况下把数据量减小到3050字节，从而只需要3次传输（如图6右侧所示）。由此，可以把终端功耗降低约25%，显著降低了交换次数和功耗。

去掉一颗或者多颗卫星以减少数据量的方法可以在物联网终端或者A-GNSS服务器上实现，逻辑如下：

（1）如果搜到的卫星信号个数少于一个阈值（例如少于8颗卫星，根据需要设定），不去掉任何搜到的卫星；

（2）如果搜到的卫星信号个数大于或者等于一个阈值（例如大于8颗卫星），去掉对定位精度贡献最小的一颗或者多颗卫星（但必须保留的卫星数目至少是阈值），例如可采用下面两个判定标准中的任意一个或者二者的结合来决定去掉哪些卫星：（i）去掉仰角最低的一颗或者多颗卫星，（ii）去掉信号最弱（信噪比最低）的一颗或者多颗卫星。

这个过程是发生在搜星结果产生之后，这样能够避免盲目的减少有用的卫星。

本例还提供了减少需要传输的数据量的另一种方式：卫星的个数不变（在本实施例中是16），但是减少每颗卫星的传输数据。例如，由于卫星时钟的一阶漂移率和二阶漂移率一般很小（二阶漂移率基本为0），它们占用的3个字节（每颗卫星）可以压缩成1个字节（每颗卫星）。又例如，可以不传输GPS卫星周数、卫星健康状况、用户测量精度指示的信息。

又例如，可以降低一些轨道参数的精度（例如轨道长半轴的平方根，平均角速度校正值）。通过这些方法来适当减少传输的数据量，从而减少和服务器交换的数据包的个数。

终端和A-GNSS服务器通信使用适用于物联网的网络协议，例如CoAP (over UDP)。本例对A-GNSS的原始辅助数据进行处理来匹配物联网的网络协议（例如CoAP），充分利用每次的数据传输，以大幅减小终端功耗和流量。作为改进，本发明在减少数据量时还需引入前提条件，以切实取得减少数据包的效果。即根据网络协议每次传输的字节数来匹配网络协议每次传输的字节数。如图7所示，具体步骤如下：

（1）A-GNSS服务器产生辅助数据；

（2）A-GNSS服务器查询网络协议每次传输的字节数；

（3）判断当最后一个数据包少于一定的字节数，或者少于全长数据包的一定比例的时候（例如全长数据包是1000字节，最后一个数据包< 1000 * 30% （=300）的时候），才调整辅助数据来匹配网络协议每次传输的字节数，减少数据量从而最终达到减少数据包的效果；

（4）A-GNSS服务器通过网络协议传输辅助数据给终端。

本例中其余技术特征与实施例一相同。

实施例三：

在实施例一或实施例二的基础上，本发明还可以对辅助信息进行简化压缩的方式减小辅助数据量：

终端发送请求消息时，把请求的辅助信息指示进行简化和压缩。在搜星结束后请求卫星信息时进行该步操作。

对每个辅助信息一般用一个比特（bit）来表示，“0”表示不需要服务器发送这个信息，“1”表示需要服务器发送这个信息。如图8所示，其中列出了用比特表达的信息位。

对于星历中的时钟参数，GPS, 北斗（Beidou）, Galileo和Glonass各用两个比特，共8个比特。“00”表示不需要该星座中任何卫星星历中的时钟参数， ”10“表示需要该星座中所有卫星星历中的时钟参数，”01“表示需要该星座中服务器认为此终端能够看到的卫星星历中的时钟参数，”11“表示需要该星座中由终端指定的卫星星历中的时钟参数，在这种情况下，请求信息需要包括一个对应该星座的比特矢量，例如GPS需要一个32位即四个字节，每个比特表示对应的GPS卫星是否需要，”0“表示不需要这颗GPS卫星的星历时钟参数，”1“表示需要这颗卫星的星历时钟参数。

例如，一个终端只支持GPS和北斗（Beidou）系统，搜星后找到GPS卫星1，3，5，7，9，11和北斗卫星3，6，9，12，15，18。在请求卫星辅助信息时，关于星座的8个比特设置成11110000 （第一个11表示终端指定GPS卫星的时钟参数，第二个11表示终端指定Beidou卫星的时钟参数，然后00表示不需要Galileo任何卫星的时钟参数，最后00表示不需要Glonass任何卫星的时钟参数。然后接下来的32个比特表示哪些GPS卫星的时钟参数：1010101010100000…00，接下来的32个比特表示哪些Beidou卫星的时钟参数：001001001001001001000…00。

对于星历中的卫星轨道参数请求，和上述的时钟参数请求方法一样。也通过8个比特+若干32比特的方式来表示需要哪些卫星的哪些卫星轨道参数。

本发明可以用比特位来简化时钟参数和卫星轨道参数中的任意一种，能够有效压缩数据，减少数据量，也可以同时简化时钟参数和卫星轨道参数，以获得更小的数据量。

本例中其余技术特征与实施例一或二相同。

本发明方案所公开的技术手段不仅限于上述实施方式所公开的技术手段，还包括由以上技术特征任意组合所组成的技术方案。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。

Claims

1.物联网中的A-GNSS辅助数据请求方法，其特征在于，包括如下步骤：

在GNSS捕获搜星结束且捕获到足够数量的卫星信号时，请求下载被捕获而且没有有效星历的卫星的GNSS辅助数据；

被下载的GNSS辅助数据在服务器端进行调整，减少数据量；服务器先查询网络协议每次传输的字节数，判断符合条件时才进行调整，所述条件包括以下条件中的至少一种：

(i)最后一个数据包少于一定的字节数；

(ii)最后一个数据包少于全长数据包的一定比例。

2.根据权利要求1所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，具体包括如下步骤：

步骤1，终端收到定位请求，打开GNSS接收机；

步骤2，开始捕获搜星；

步骤3，捕获搜星结束；

3.根据权利要求1或2所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，在GNSS捕获搜星结束后判断下载的GNSS辅助数据是否为和卫星相关的辅助数据；当存在和卫星无关的能够帮助搜星且当前不在终端中的辅助数据时，终端在搜星进行之前向服务器进行请求下载。

4.根据权利要求1所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，所述调整通过如下方式进行：去掉若干卫星的数据。

5.根据权利要求4所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，通过如下逻辑去掉若干卫星的数据：

如果搜到的卫星信号个数大于一个阈值时，去掉对定位精度贡献最小的一颗或者多颗卫星，必须保留的卫星数量大于或等于阈值。

6.根据权利要求5所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，所述定位精度贡献最小的一颗或者多颗卫星满足以下条件中的任意一种：

(i)仰角最低；

(ii)信号最弱或信噪比最低。

7.根据权利要求4所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，如果搜到的卫星信号个数少于阈值时不去掉任何搜到的卫星。

8.根据权利要求2所述的物联网中的A-GNSS辅助数据请求方法，其特征在于，所述步骤4中，终端发送请求消息时，请求的辅助信息指示通过比特编码。