定位方法、系统、终端与定位服务器

摘要

本公开涉及一种定位方法、系统、终端与定位服务器。该方法包括接收终端内定位应用发起的定位请求；检测终端周围的AP信号；判断定位应用是否属于连续定位应用；如果属于，则判断缓存内是否存在所检测到的AP的定位数据以及定位数据是否过期；如果存在并且未过期，则根据缓存内的AP的定位数据计算定位结果；如果不属于连续定位、缓存内不存在所检测到的AP的定位数据或者定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；将定位结果返回给定位应用。本公开降低了连续定位的时延和定位服务器的定位压力。

权利要求

1.一种定位方法，其特征在于，包括：

接收终端内定位应用发起的定位请求，所述定位请求中携带定位应用的标识；

响应于定位请求，检测终端周围的AP信号；

根据所述定位应用的标识判断定位应用是否属于连续定位应用；

如果属于连续定位应用，则判断终端本地缓存内是否存在所检测到的AP的定位数据以及这些AP的定位数据是否过期；

如果存在并且未过期，则根据终端本地缓存内的AP的定位数据计算定位结果；

如果不属于连续定位应用、终端本地缓存内不存在所检测到的AP的定位数据或者这些AP的定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；

响应于连续定位应用发起的定位请求，接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；

将定位结果返回给定位应用。

2.根据权利要求1所述的定位方法，其特征在于，AP的定位数据包括AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

3.根据权利要求1所述的定位方法，其特征在于，在缓存AP的定位数据时为该次缓存打上时间戳。

4.根据权利要求1所述的定位方法，其特征在于，如果终端缓存内的AP的定位数据已过期，则删除缓存内的AP的定位数据。

5.一种终端，其特征在于，包括：

请求接收单元，用于接收终端内定位应用发起的定位请求，所述定位请求中携带定位应用的标识；

AP检测单元，用于响应于定位请求，检测终端周围的AP信号；

第一判断单元，用于根据所述定位应用的标识判断定位应用是否属于连续定位应用；

第二判断单元，用于如果属于连续定位应用，则判断终端本地缓存内是否存在所检测到的AP的定位数据以及这些AP的定位数据是否过期；

定位计算单元，用于如果存在并且未过期，则根据终端本地缓存内的AP的定位数据计算定位结果；

请求转发单元，用于如果不属于连续定位应用、终端本地缓存内不存在所检测到的AP的定位数据或者这些AP的定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；

数据接收单元，用于响应于连续定位应用发起的定位请求，接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；

结果返回单元，用于将定位结果返回给定位应用。

6.根据权利要求5所述的终端，其特征在于，AP的定位数据包括AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

7.根据权利要求5所述的终端，其特征在于，所述数据接收单元在缓存AP的定位数据时为该次缓存打上时间戳。

8.根据权利要求5所述的终端，其特征在于，所述终端还包括：删除单元，用于如果终端缓存内的AP的定位数据已过期，则删除缓存内的AP的定位数据。

9.一种定位服务器，其特征在于，包括：

接收单元，用于接收终端内定位应用发起的定位请求和终端检测到的AP信号，所述定位请求中携带定位应用的标识；

定位单元，用于根据接收到AP信号确定终端的位置；

应用类型判断单元，用于根据所述定位应用的标识判断定位应用是否属于连续定位应用；

数据查询单元，用于如果定位应用属于连续定位应用，则根据确定的终端的位置自定位数据库中查询终端附近的AP的定位数据；

数据发送单元，用于将确定的终端的位置和查询到的终端附近的AP的定位数据发送至终端，以便终端在本地根据AP的定位数据对连续定位应用发起的定位请求进行处理。

10.根据权利要求9所述的定位服务器，其特征在于，所述定位服务器还包括：加密单元，用于对查询到的终端附近的AP的定位数据进行加密。

11.根据权利要求9所述的定位服务器，其特征在于，AP的定位数据包括AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

12.一种定位系统，其特征在于，包括权利要求5-8中任一项所述的终端和权利要求9-

11中任一项所述的定位服务器。

说明书

定位方法、系统、终端与定位服务器

技术领域

[0001] 本公开涉及定位领域，特别地，涉及一种定位方法、系统、终端与定位服务器。

背景技术

[0002] 目前全球正在掀起移动互联网的建设热潮。美国、日本等国纷纷投入巨资打造无线城市，移动互联网建设正在进入一个大时代。

[0003] 定位能力是指通过无线终端和无线网络的配合确定移动用户的实际位置信息，例如，经纬度坐标数据，可以包括三维数据。通过SMS(Short Message System，短消息系统)、MMS(Multimedia Messaging Service，多媒体消息业务)、语音发给用户或以此为基础提供某种增值服务的能力。由于目前技术的限制，GPS主要覆盖区域为室外空旷区域，Cell\Wi-Fi主要覆盖室内等GPS无信号的定位区域。

[0004] 无线局域网又称WLAN(Wireless Lan)，是指通过移动终端和移动网络的配合确定移动用户的实际地理位置，从而提供用户所需要的与位置相关的服务信息的一种移动通信与导航融合的服务形式。基于位置的服务可以被应用于不同的领域，例如，健康、工作、个人生活等。此服务可以用来辨认一个人或物所在的位置，例如，发现最近的提款机或朋友、同事等的当前位置，也能通过客户目前所在的位置提供直接的手机广告，并包括按照位置的天气消息发布，甚至提供本地化的游戏。由于本身不具有目的性和黏性，LBS(Location-Based Services，位置业务)一般都只作为一种工具出现在某种产品中。通过LBS，用户不需要搜索和查找就可以在地图上快速定位自己的位置，在这个位置上寻找自己感兴趣的内容。LBS被认为是移动领域的杀手级业务，普遍被行业看好，也有众多公司试水这一领域。

[0005] WiFi定位弥补了现有主流GPS定位无法实现精准室内定位和基站定位平台无法实现精准定位的缺陷，WiFi定位的主要定位流程是用户上报终端采集得到的AP信号，并上报到服务器平台，平台根据用户上报的定位数据，计算用户的可能位置，下发到终端，提供给用户侧的各种位置服务应用。

[0006] 具体地，WiFi-RSS(Receiving Signal Strength，接收信号强度)定位是利用无线局域网中无线电波的强弱情况作为判断设备位置的标准，通过测量设备接收到多个AP设备的信号强度，对比发出信号的设备的原始发射信号强度，根据信号的衰减情况计算需定位设备的设备位置的一种定位技术。其定位方式如图1所示。

[0007] 系统通过比较信号强度，采用损耗模型来计算信号传播的距离，并根据距离结果计算设备的可能位置。比较常用的损耗模型有Rappaort模型：

[0008] Pr＝Pt-PL(d)＝Pt-PL(d0)-10nlog(d/d0)-FAF    (1)

[0009] 上式中，Pr为接收的信号强度，Pt为AP的发送功率，PL(d)为路径衰减，PL(d0)为距离AP d0处的路径衰减，n为路径损耗系数，FAF为遮蔽因子。

[0010] 在利用WiFi进行定位时，用户上报定位终端接收到的附近的WiFi热点信号标识及信号强度。平台接收到用户上报的信号后，查找上报AP的位置，并根据以上损耗模型，计算终端和各个AP的距离，并最终计算终端的位置。

[0011] 在连续定位的条件下，需要终端连续的向平台发起接收到的定位信号的强度信息。尽管平台计算终端位置的时间消耗较短，一般为200ms左右，但是由于网络时延，用户每次定位的时间消耗大约在2s～5s之间，可见这种定位方式时延较大，减低了用户的定位体验。如果用户侧网络不稳定还很有可能出现无法定位的问题。

发明内容

[0012] 本公开鉴于以上问题中的至少一个提出了新的技术方案。

[0013] 本公开在其一个方面提供了一种定位方法，其降低了连续定位的时延和定位服务器的定位压力。

[0014] 本公开在其另一方面提供了一种终端，其降低了连续定位的时延和定位服务器的定位压力。

[0015] 本公开在其又一方面提供了一种定位服务器，其降低了连续定位的时延和定位服务器的定位压力。

[0016] 本公开在其再一方面提供了一种定位系统，其降低了连续定位的时延和定位服务器的定位压力。

[0017] 根据本公开，提供一种定位方法，包括：

[0018] 接收终端内定位应用发起的定位请求；

[0019] 响应于定位请求，检测终端周围的AP信号；

[0020] 根据定位请求判断定位应用是否属于连续定位应用；

[0021] 如果属于连续定位应用，则判断终端本地缓存内是否存在所检测到的AP的定位数据以及这些AP的定位数据是否过期；

[0022] 如果存在并且未过期，则根据终端本地缓存内的AP的定位数据计算定位结果；

[0023] 如果不属于连续定位应用、终端本地缓存内不存在所检测到的AP的定位数据或者这些AP的定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；

[0024] 响应于连续定位应用发起的定位请求，接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；

[0025] 将定位结果返回给定位应用。

[0026] 在本公开的一些实施例中，定位请求中携带定位应用的标识，根据定位应用的标识判断定位应用是否属于连续定位应用。

[0027] 在本公开的一些实施例中，AP的定位数据包括AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

[0028] 在本公开的一些实施例中，在缓存AP的定位数据时为该次缓存打上时间戳。

[0029] 在本公开的一些实施例中，如果终端缓存内的AP的定位数据已过期，则删除缓存内的AP的定位数据。

[0030] 根据本公开，还提供了一种终端，包括：

[0031] 请求接收单元，用于接收终端内定位应用发起的定位请求；

[0032] AP检测单元，用于响应于定位请求，检测终端周围的AP信号；

[0033] 第一判断单元，用于根据定位请求判断定位应用是否属于连续定位应用；

[0034] 第二判断单元，用于如果属于连续定位应用，则判断终端本地缓存内是否存在所检测到的AP的定位数据以及这些AP的定位数据是否过期；

[0035] 定位计算单元，用于如果存在并且未过期，则根据终端本地缓存内的AP的定位数据计算定位结果；

[0036] 请求转发单元，用于如果不属于连续定位应用、终端本地缓存内不存在所检测到的AP的定位数据或者这些AP的定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；

[0037] 数据接收单元，用于响应于连续定位应用发起的定位请求，接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；

[0038] 结果返回单元，用于将定位结果返回给定位应用。

[0039] 在本公开的一些实施例中，定位请求中携带定位应用的标识，第一判断单元根据定位应用的标识判断定位应用是否属于连续定位应用。

[0040] 在本公开的一些实施例中，AP的定位数据包括AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

[0041] 在本公开的一些实施例中，数据接收单元在缓存AP的定位数据时为该次缓存打上时间戳。

[0042] 在本公开的一些实施例中，终端还包括：

[0043] 删除单元，用于如果终端缓存内的AP的定位数据已过期，则删除缓存内的AP的定位数据。

[0044] 根据本公开，还提供了一种定位服务器，包括：

[0045] 接收单元，用于接收终端内定位应用发起的定位请求和终端检测到的AP信号；

[0046] 定位单元，用于根据接收到AP信号确定终端的位置；

[0047] 应用类型判断单元，用于根据定位请求判断定位应用是否属于连续定位应用；

[0048] 数据查询单元，用于如果定位应用属于连续定位应用，则根据确定的终端的位置自定位数据库中查询终端附近的AP的定位数据；

[0049] 数据发送单元，用于将确定的终端的位置和查询到的终端附近的AP的定位数据发送至终端，以便终端在本地根据AP的定位数据对连续定位应用发起的定位请求进行处理。

[0050] 在本公开的一些实施例中，定位服务器还包括：

[0051] 加密单元，用于对查询到的终端附近的AP的定位数据进行加密。

[0052] 在本公开的一些实施例中，定位请求中携带定位应用的标识，应用类型判断单元根据定位应用的标识判断定位应用是否属于连续定位应用。

[0053] 在本公开的一些实施例中，AP的定位数据包括AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

[0054] 根据本公开，还提供了一种定位系统，包括终端和定位服务器。

[0055] 在本公开的技术方案中，针对连续定位应用发出的定位请求，判断终端本地是否缓存了有效的AP的定位数据，如果有，则在终端本地进行定位计算，这样可以显著减小定位时与定位服务器交互所产生的定位时延。同时，由于这种连续定位在终端本地进行，因此也降低了定位服务器的处理负荷。

附图说明

[0056] 此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分。在附图中：

[0057] 图1是三角定位算法示意图。

[0058] 图2是本公开一个实施例的定位方法的流程示意图。

[0059] 图3是本公开一个实施例的终端的结构示意图。

[0060] 图4是本公开一个实施例的定位服务器的结构示意图。

[0061] 图5是本公开一个实施例的定位系统的结构示意图。

[0062] 图6是本公开另一实施例的定位系统的结构示意图。

[0063] 图7是本公开定位SDK的一个实例的结构示意图。

[0064] 图8是本公开定位引擎的一个实例的结构示意图。

[0065] 图9是本公开终端与定位引擎交互格式示意图。

[0066] 图10是本公开定位流程的一个实例的示意图。

具体实施方式

[0067] 下面将参照附图描述本公开。要注意的是，以下的描述在本质上仅是解释性和示例性的，决不作为对本公开及其应用或使用的任何限制。除非另外特别说明，否则，在实施例中阐述的部件和步骤的相对布置以及数字表达式和数值并不限制本公开的范围。另外，本领域技术人员已知的技术、方法和装置可能不被详细讨论，但在适当的情况下意在成为说明书的一部分。

[0068] 本公开下述实施例在现有条件下通过终端判断需要连续定位的应用，定位服务器根据应用特点主动下发定位所需数据，终端接收数据后，可在本地进行定位计算的分布式定位。本公开对于具有连续定位需求的应用，降低了小范围区域中终端和定位服务器交互的次数和网络造成的定位延迟，一方面降低了由于网络时间带来的定位时延较长的问题，减少了网络带来的定位失败影响，另一方面在用户量较大的情况下，减少了SDK(Software Development Kit Windows，软件开发工具包)和定位服务器的多次交互，降低了定位服务器接收到定位请求的压力，降低了定位服务器可能的定位压力，优化了用户体验。

[0069] 本公开下述实施例通过终端判断定位请求来源，确定终端需要进行连续定位服务，然后，定位服务器主动向终端下发一部分定位所需的AP数据库，定位SDK接收到定位数据后，可在本地进行计算，提高定位速度，优化用户的定位体验。本公开可以应用于用户具有连续性定位需求的应用场景。

[0070] 图2是本公开一个实施例的定位方法的流程示意图。

[0071] 如图2所示，该实施例可以包括以下步骤：

[0072] S202，接收终端内定位应用发起的定位请求，其中，终端内的定位应用可以包括单次定位应用和连续的多次定位应用。

[0073] S204，响应于定位请求，检测终端周围的AP(Access Point，接入点)信号；

[0074] 具体地，在接收到定位请求后，终端开始检测其周围的AP信号，例如，可以计算出所接收到的各AP的信号强度。由于各AP都会对外广播其MAC地址，因此终端也可以获得各AP的MAC地址信息。

[0075] S206，根据定位请求判断定位应用是否属于连续定位应用；

[0076] 具体地，由于定位请求中可以携带定位应用的标识，因此，可以根据定位应用的标识判断定位应用是否属于连续定位应用。

[0077] 其中，终端可以与定位服务器约定或协商好分配给连续定位应用的标识的特点，例如，连续定位应用的标识的末位为1，基于此特点，终端与定位服务器都可以判断出该定位应用是否为连续定位应用。

[0078] S208，如果属于连续定位应用，则判断终端本地缓存内是否存在所检测到的AP的定位数据以及这些AP的定位数据是否过期；

[0079] 具体地，如果是连续定位应用，则终端根据步骤S204可以检测出某些AP的信号和MAC地址。根据获取的MAC地址查询终端本地缓存内是否存在这些所检测到AP的定位数据，如果存在，则再判断这些AP的定位数据是否过期。需要指出的是，也可以先判断缓存内的AP的定位数据是否过期，如过期，则无需再判断缓存内是否存在这些所检测到AP的定位数据，否则再判断缓存内是否存在这些所检测到AP的定位数据。

[0080] S210，如果存在并且未过期，则根据终端本地缓存内的AP的定位数据计算定位结果；

[0081] 具体地，可以利用多种方式确定终端的位置，例如，指纹定位或三角定位。当采用三角定位时，可以利用终端检测到的三个信号最强的AP的定位数据计算终端的位置。需要指出的是，如果终端检测到多个AP信号，但是，并非所有AP信号都在终端本地有缓存，此时，只要有三个AP的定位数据就可以利用三角定位法定位出终端的位置。

[0082] S212，如果不属于连续定位应用、终端本地缓存内不存在所检测到的AP的定位数据或者这些AP的定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；

[0083] 具体地，如果不属于连续定位应用，则按照现有技术由定位服务器实现对终端的定位。如果属于连续定位应用，但是，终端本地不存在所检测到的AP的定位数据，因此无法在终端本地完成定位功能，仍需在定位服务器上完成对终端的定位。如果缓存内与终端位置相关的AP的定位数据已过期，也需要由定位服务器来实现对终端的定位，因为，在现实生活中存在AP搬家现象，如果不对AP的定位数据进行定期更新，则可能导致计算出的终端的位置不准确。

[0084] S214，响应于连续定位应用发起的定位请求，接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；

[0085] 具体地，定位服务器接收到定位请求后，根据终端检测到的AP信号计算终端的位置，再到数据库中查询终端周围，例如，设定距离内的AP的定位数据。

[0086] S216，将定位结果返回给定位应用。

[0087] 在该实施例中，针对连续定位应用发出的定位请求，判断终端本地是否缓存了有效的AP的定位数据，如果有，则在终端本地进行定位计算，这样可以显著减小定位时与定位服务器交互所产生的定位时延。同时，由于这种连续定位在终端本地进行，因此也降低了定位服务器的处理负荷。

[0088] 其中，AP的定位数据可以包括但不限于AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

[0089] AP的MAC地址用于标识AP，终端检测到的AP信号的强度、AP的发射功率以及AP的衰减因子用于对终端进行定位，得出终端距离某个AP的距离。再根据各AP的位置以及终端距各AP的距离计算出终端的具体位置。

[0090] 为了确定定位数据是否过期，终端在缓存AP的定位数据时为该次缓存打上时间戳。

[0091] 利用当前时间与时间戳进行比较判断AP的定位数据是否过期，如果终端缓存内的AP的定位数据已过期，则删除缓存内的AP的定位数据。

[0092] 本公开上述实施例无需改变目前智能终端，可以分布式计算定位结果，减少网络消耗时间并提高用户定位体验。在移动互联网体系的基础上，通过终端检测定位应用的特征，判断需要进行连续定位的应用，定位服务器主动向SDK推送定位将会使用的AP数据，SDK收到定位数据后，在本地计算定位结果，减少定位消耗时间，提高用户体验。

[0093] 本领域普通技术人员可以理解，实现上述方法实施例的全部和部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算设备可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤，而前述的存储介质可以包括ROM、RAM、磁碟和光盘等各种可以存储程序代码的介质。

[0094] 图3是本公开一个实施例的终端的结构示意图。

[0095] 如图3所示，该实施例中的终端30可以包括请求接收单元302、AP检测单元304、第一判断单元306、第二判断单元308、定位计算单元310、请求转发单元312、数据接收单元314和结果返回单元316。其中，

[0096] 请求接收单元302，用于接收终端内定位应用发起的定位请求；

[0097] AP检测单元304，用于响应于定位请求，检测终端周围的AP信号；

[0098] 第一判断单元306，用于根据定位请求判断定位应用是否属于连续定位应用；

[0099] 第二判断单元308，用于如果属于连续定位应用，则判断终端本地缓存内是否存在所检测到的AP的定位数据以及这些AP的定位数据是否过期；

[0100] 定位计算单元310，用于如果存在并且未过期，则根据终端本地缓存内的AP的定位数据计算定位结果；

[0101] 请求转发单元312，用于如果不属于连续定位应用、终端本地缓存内不存在所检测到的AP的定位数据或者这些AP的定位数据已过期，则将定位请求和所检测到的AP信号转发给定位服务器；

[0102] 数据接收单元314，用于响应于连续定位应用发起的定位请求，接收定位服务器计算出的定位结果，缓存定位服务器查询到的终端所在位置附近的AP的定位数据；

[0103] 结果返回单元316，用于将定位结果返回给定位应用。

[0104] 在该实施例中，针对连续定位应用发出的定位请求，判断终端本地是否缓存了有效的AP的定位数据，如果有，则在终端本地进行定位计算，这样可以显著减小定位时与定位服务器交互所产生的定位时延。同时，由于这种连续定位在终端本地进行，因此也降低了定位服务器的处理负荷。

[0105] 其中，定位请求中携带定位应用的标识，第一判断单元根据定位应用的标识判断定位应用是否属于连续定位应用。

[0106] 此外，AP的定位数据可以包括但不限于AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

[0107] 数据接收单元在缓存AP的定位数据时为该次缓存打上时间戳。

[0108] 进一步地，终端还可以包括删除单元，用于如果终端缓存内的AP的定位数据已过期，则删除缓存内的AP的定位数据。

[0109] 图4是本公开一个实施例的定位服务器的结构示意图。

[0110] 如图4所示，该实施例中的定位服务器40可以包括接收单元402、定位单元404、应用类型判断单元406、数据查询单元408和数据发送单元410。其中，

[0111] 接收单元402，用于接收终端内定位应用发起的定位请求和终端检测到的AP信号；

[0112] 定位单元404，用于根据接收到AP信号确定终端的位置；

[0113] 应用类型判断单元406，用于根据定位请求判断定位应用是否属于连续定位应用；

[0114] 数据查询单元408，用于如果定位应用属于连续定位应用，则根据确定的终端的位置自定位数据库中查询终端附近的AP的定位数据；

[0115] 数据发送单元410，用于将确定的终端的位置和查询到的终端附近的AP的定位数据发送至终端，以便终端在本地根据AP的定位数据对连续定位应用发起的定位请求进行处理。

[0116] 在一个实例中，定位服务器还可以包括加密单元，用于对查询到的终端附近的AP的定位数据进行加密。

[0117] 在另一实例中，定位请求中携带定位应用的标识，应用类型判断单元根据定位应用的标识判断定位应用是否属于连续定位应用。

[0118] AP的定位数据可以包括但不限于AP的MAC地址、AP的位置、AP的发射功率以及AP的衰减因子。

[0119] 图5是本公开一个实施例的定位系统的结构示意图。

[0120] 如图5所示，该实施例中的定位系统50可以包括终端502和定位服务器504。其中，终端502和定位服务器504既可以通过前述实施例实现也可以通过下述实施例实现。

[0121] 图6是本公开另一实施例的定位系统的结构示意图。

[0122] 如图6所示，该实施例中的定位系统主要包括终端和定位服务器。

[0123] 终端：指具有定位需求的所有设备，该设备可以是用户的智能手机。该设备可以通过固定、WiFi、移动网络等方式接入互联网。终端对外接口包括听筒接口、定位引擎接口、WiFi设备接口、定位接口、推送信息接口。其中，WiFi设备接口主要负责监听周围的WiFi信号。定位接口主要负责网络接入和发出以及接收对应的定位请求信息和定位结果。推送信息接口主要负责接收该位置附近的定位数据信息。

[0124] 定位服务器：计算定位结果及对请求进行处理。对外接口包括单次定位查询接口和批量定位输出接口。其中，单次定位查询接口根据定位请求输出定位请求中相关的AP的各项信息。批量定位输出接口根据位置信息批量输出所需位置所对应的附近X公里内的所有AP信息。

[0125] 其中，终端包括LBS应用(LBS-APP)和定位SDK，定位服务器包括PE(Position Engine，定位引擎)和PDB(Position Database，定位数据库)，现分别介绍如下：

[0126] LBS应用(LBS-APP)：即用户智能终端上安装的具有定位需求的应用，根据定位应用的特点，可以将应用分为具有连续定位需求的应用，如导航等，和一次定位应用，如周边信息查询等。

[0127] 定位SDK：即用户智能终端上安装的提供位置服务的定位包程序。LBS-APP向定位SDK请求定位时，定位SDK判断LBS-APP是否属于连续定位请求的应用，如发现该应用属于连续定位应用并且终端本地没有可用的定位数据，则向定位服务器说明需要连续定位，请求下发定位数据。在接收到定位服务器下发的定位数据后，定位SDK可利用定位数据库自行计算定位结果。其中，具体的定位方式很多，例如，指纹定位、三角定位等，其中，指纹定位是比对终端收到的信号和数据库的信号，如果信号非常接近，即认为两个点在同一个位置，三角定位是通过已知的AP位置，信号强度的衰减，计算手机到AP的距离，通过三圆定位得出终端的具体位置。

[0128] 图7是本公开定位SDK的一个实例的结构示意图。

[0129] 如图7所示，定位SDK主要包括WiFi探测模块、定位计算模块、定位调度模块、定位网络模块和数据缓存模块。其中，数据缓存模块主要保存定位服务器下发的AP位置及对应的AP定位数据。WiFi探测模块主要监听周围的WiFi信息，该模块监听周围的地磁信息并对该信息进行解析，将信息发送给定位调度模块。定位调度模块判断定位请求是否还在上次定位缓存的有效期内，如还在有效期内，则将定位请求转发给定位计算模块，如不在上次缓存有效期内或者本地无法计算定位结果，则将信息转发至定位网络模块并清除本地缓存数据。定位计算模块在接收到定位请求后，向数据缓存模块请求本次定位相关的AP信息，并根据该AP信息进行计算。定位网络模块主要管理数据对网络的接入，打包定位请求信息并上传，同时接收定位信息及推送的定位缓存信息。

[0130] 定位引擎：是定位服务器中WiFi定位的核心设备，该设备可通过分析终端上传的AP信号，根据该AP信号向AP数据库请求匹配，确定用户所处区域。其中，信号匹配主要指指纹定位，终端上传的信息包括AP的MAC地址和AP的信号强度，而数据库中也有每个位置AP的MAC地址和AP的信号强度，通过比对相似度，确定和现在手机收到的信号最为相似的数据库中的点的位置，然后近似的认为终端即在数据库点对应的位置。当接收到连续定位请求时，根据用户所处区域，主动向用户的定位SDK推送该区域附近的定位数据库。

[0131] 图8是本公开定位引擎的一个实例的结构示意图。

[0132] 如图8所示，定位引擎主要包括定位网络模块、定位调度模块、定位计算模块和数据查询模块。其中，定位网络模块主要负责管理和终端的沟通功能，并将终端发出的定位请求包并转发给定位调度模块。定位调度模块判断该请求属于连续定位请求，转发请求给定位计算模块，并根据计算结果向数据查询模块查询数据。数据查询模块主要负责从数据库中查询对应的AP的位置信息及对应位置的AP信息。对外接口包括对定位数据库的查询接口和对终端的接口，对定位数据库的查询接口主要负责查询对应AP定位位置信息和该位置的AP信息。对终端的接口主要负责接收定位请求并向终端发出定位结果信息以及向终端推送该位置附近的AP信息。

[0133] 其中，终端与定位引擎的交互格式如图9所示。

[0134] 如图9所示，鉴于移动互联网的链接情况和需求，主要采用UDP(User Datagram Protocol，用户数据报文协议)方式发送。其中，

[0135] PD address/port为发送信息的设备的源地址/源端口。

[0136] PE(Position Engine，定位引擎)address/port为该位置服务引擎对应的目的适配网关地址/目的端口。

[0137] PD port为1字节长度，是该信息来自的终端设备对应的实际物理端口信息。

[0138] Length为2字节长度，包括了IP包和UDP包全部内容的长度。

[0139] PE收到该请求包后先验证包长度是否符合其列出的长度，如果不等则丢弃。

[0140] UDP Length为2字节长度，包括了UDP包和data全部内容的长度。PE收到该请求包后先验证包长度是否符合其列出的长度，如果不等则丢弃。

[0141] USD(User Data，用户数据)内容为该终端上传的监听到的该区域的WiFi信息。

[0142] 定位数据库：主要包括AP的MAC地址、AP的位置、AP的发射功率与AP的损耗系数，用来计算定位结果。定位数据库的对外接口包括单次定位信息查询接口和批量数据输出接口。

[0143] 上述模块之间紧密配合，实现对连续定位应用的快速定位能力。

[0144] 发起定位时，LBS应用向定位SDK发起位置请求，定位SDK根据应用的ID判断其是否属于连续定位应用。如果应用具有连续定位的需求，则定位SDK将连续定位请求传递给定位服务器；定位服务器收到该请求后，向定位信息数据库查询匹配的数据和对应的位置信息，并将与该信息关联的附近的定位元数据推送到定位SDK。下次定位时，SDK先判断该定位请求是否可以在本地进行定位，快速计算定位结果，并将定位结果返回给需定位的LBS应用。

[0145] 首先，定位SDK接收到连续定位的请求后，按照一般定位的方式，查询周围的AP信号，并将信号打包上传至定位引擎，在定位请求中，表示该次定位发起自连续定位应用。

[0146] 定位服务器接收到定位SDK转发的请求后，按照一般定位流程计算用户的位置信息，并回复给定位SDK。同时，由于该定位来自于具有连续定位的应用，定位服务器查询数据库中处于该位置信息附近X公里内的AP相关定位数据，并将该数据经过加密后推送给定位SDK。

[0147] 定位SDK接收到定位结果后，首先将定位结果转发给定位应用。同时，本地解密定位服务器推送的定位数据，将其放置在缓存中，并为其打上时间戳。

[0148] 当设定的T分钟内(其中，T可预先设置)，用户具有第二次定位需求时，终端先查询该定位相关的AP是否存在于缓存中，由于每个AP都会对外广播其MAC地址，MAC地址全球唯一，因此终端通过此MAC地址在数据库中寻找，如果找到相同的MAC地址则将其确定为相关AP。如果该数据在本地可查询到，则定位SDK在本地按照定位模型公式(1)计算和该AP的距离，并最终计算定位结果。

[0149] 如果定位周期过长或定位应用被关闭后再次重新开启等导致超过设定的T分钟，或在终端本地无法查询到相关AP的定位数据，则SDK再次向定位服务器发起定位请求。

[0150] 由上可知，基于分布式终端的定位系统是由定位SDK、定位引擎及后端定位数据库之间的互动来实现的。设备部署简单，无需增大SDK的大小，无需改变用户终端及网络设备，实现了用户各种定位精度的灵活得可扩展性和上层接口标准的简单化，其基本流程如图10所示。

[0151] (1)LBS应用发起定位请求

[0152] 前面提到，定位SDK需要判断定位应用是否属于具有连续定位需求的定位应用。在LBS应用使用定位服务器提供服务时，需要先向定位服务器进行注册。注册时，需要该应用向定位服务器说明，该应用是否为具有连续定位请求的定位应用。

[0153] 具体地，如某连续定位应用A，在其向定位服务器注册后，定位服务器向该应用发布注册号XXXXX1，最后一位1代表该LBS应用具有连续定位属性。

[0154] LBS应用调用定位SDK时，向定位SDK请求定位，并告知定位SDK自己的注册号XXXXX1。

[0155] 定位SDK接收到LBS应用的ID后，判断该应用具有连续定位属性。

[0156] (2)定位发起流程

[0157] 定位SDK接收到LBS应用的定位请求后，向定位终端请求WiFi信息。将获取的WiFi信息打包发送给定位服务器，如该定位应用为连续定位，则同时在请求中表明该定位请求号码XXXXX1。

[0158] 如果该位置上接收到的AP共有5个，信号强度分别为-X1，-X2，-X3，-X4，-X5，则定位SDK向定位服务器上传的定位请求为：

[0159]

[0160]

[0161] (3)定位服务器的定位流程

[0162] 定位服务器接收到定位请求后，首先向定位数据库请求AP1，AP2，AP3，AP4，AP5的位置信息。

[0163] 定位数据库返回给定位引擎AP1、AP2、AP3、AP4、AP5的相关定位信息，包括AP的MAC地址、AP的位置、AP的发射功率和AP的损耗系数。

[0164] 定位引擎接收到数据库的返回信息和上报请求信息后，根据公式(1)计算信号相对发射功率的衰减，从而得到终端相对于AP原位置的距离。

[0165] 根据多个AP的距离计算出该终端的可能位置，并将该终端的可能位置发送给定位SDK。

[0166] (4)查找该位置附近数据

[0167] 由于该应用为连续定位应用，定位服务器获得终端的可能位置后，再次向定位数据库请求定位相关数据。

[0168] 定位数据库接收到查询要求后，查询该位置附近X公里范围内的AP数据信息，包括AP的MAC地址，AP的位置，AP的发射功率，AP的损耗系数。

[0169] 数据库将所有位置相关信息发给定位服务器。

[0170] 定位服务器对该信息进行加密，将加密后的定位信息推送给定位SDK。

[0171] (5)定位SDK解密信息

[0172] 定位SDK接收到定位信息后，对信息进行解密，并缓存在本地，标明该次缓存的具体时间。

[0173] (6)下次定位操作

[0174] 当定位SDK再次接收到定位请求时，首先仍然是向终端请求接收到AP信号。然后，判断该定位请求的时间是否在过期时间之前。如上次缓存的信息还未过期，则定位SDK在本地查询接收到的AP是否存在。

[0175] 如AP在本地可查询，则定位SDK按照公式(1)在本地进行定位计算，并将计算结果返回给定位APP。

[0176] (7)重新向定位服务器发起请求

[0177] 如果检查到上次请求获得的时间已经过期，则定位SDK删除本地缓存得到的信息。

[0178] 如果定位SDK在本地无法查询到定位的AP，则将定位请求上报至定位服务器，定位服务器计算定位结果，并根据定位请求选择再次下发定位数据库。若定位SDK接收到新的定位数据库后，替换原有数据库的内容。

[0179] 该实施例采用分发技术，使用LBS应用，定位SDK，PE和PDB的配合，将需要定位区域周围的定位信息主动推送到用户端，无需更改用户终端设备和网络设备，具有很好的灵活性和可拓展性。

[0180] 通过将定位算法预置到智能手机SDK中，减小了连续定位时对定位服务器产生的负担和压力。

[0181] 定位服务器根据应用特点判断应用为连续定位需求的应用后，主动向终端推送定位数据库，减小了下次定位的网络时间消耗，同时避免了用户可能因为网络造成的无法定位或定位缓慢的问题，进而提高用户的定位体验提高了用户的定位体验。

[0182] 本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同和相似的部分可以相互参见。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处可以参见方法实施例部分的说明。

[0183] 虽然已参照示例性实施例描述了本公开，但应理解，本公开不限于上述的示例性实施例。对于本领域技术人员显然的是，可以在不背离本公开的范围和精神的条件下修改上述的示例性实施例。所附的权利要求的范围应被赋予最宽的解释，以包含所有这样的修改以及等同的结构和功能。