技术领域

本发明涉及移动通信技术领域， 尤其涉及一种用户面定位方法、 系统、 终端及定位服务器。

背景技术

作为移动通信系统的特色业务之一， 定位服务一直被认为是未来移动增 值业务的一个亮点。 目前， 北美、 欧洲和亚太和日韩等国家和地区的主要移 动通信运营商都已开通了移动定位业务。 定位业务是移动增值业务中最具吸 引力的业务， 同时也是产业链各个环节最为复杂的业务之一 。

LOC是开放移动联盟（ Open Mobile Architecture, 简称为 OMA )于 2002 年将 LIF ( Location Inter-operability Forum )论坛的工作， 以及 WAP论坛中的 定位业务， 以及 3GPP R6 LCS stage3相关工作并入而成立的， 其目的是实现 制定互联互通的定位业务标准， 制定移动位置业务的规范， 确保端到端的互 操作； 在漫游、 Le接口等研究领域逐步取代 3GPP和 3GPP2, 成为 Location 业务标准的主要国际规范制订者。 OMA LOC的主要工作就是制定移动通信 网络中基于用户面的定位技术， 将过去移动通信网络中的控制面定位技术中 相关定位参数在 IP通道中传输， 进而实现定位， 同时也减少了对核心网的依 赖， 减少了耦合， 增加了灵活性。

目前， OMA LOC组已经完成了 SUPL1.0(安全用户面定位)标准的制定工 作， 在市场上已经得到了广泛的部署和应用， 目前 OMA LOC 组正在进行 SUPL2.0的工作， 现已经接近尾声。 在 SUPL2.0里， 实现了对 SUPL1.0定位 功能的增强， 比如增加了触发类型的定位， 支持在不同接入网络里实现定位 的功能等， 而且也能支持不同的 GNSS ( Global Navigation Satellite Systems, 全球卫星导航系统） ， 同时， 在 SUPL2.0中目前也定义了紧急定位方案， 并 增加了相应的定位实体， 即 E-SLP ( Emergency-SUPL Location Platform, 紧急 SUPL定位平台） 。 在 SUPL 2.0功能中还实现了终端发起的针对其它终端的 定位功能。 首先， SET1建立和其归属的 SLP (即 H-SLP1 )之间的安全数据连接， 之后 向其归属的 SUPL定位服务器发送 SUPL SET INIT消息

根据收到的定位请求， H-SLP1需要首先判断被定位终端是否归属本定位 服务器，并在判断不归属本定位服务器时，通 过 Lr参考点发起漫游定位请求， 要求其它的定位平台帮助获得被定位终端的位 置。 假如被定位终端是归属本 定位服务器， H-SLP1将需要判断被定位终端的隐私策略是否允 许其被发起请 求的用户所定位， 以及该用户终端是否能够支持 SUPL方式的定位。 当判断 被定位终端不是归属本定位服务器， 而是归属 H-SLP2时， H-SLP1将需要通 过 Lr参考点向其发送漫游定位请求消息，要求其� ��助获取被定位终端的位置。

H-SLP1在获取定位结果前， 无论成功与否或处理时间长短， 发起定位请 求的 SET都需要盲目的等待， 导致用户业务体验不佳。 发明内容

本发明要解决的技术问题是提供一种用户面定 位方法、 系统、 终端及定 位服务器， 以改善用户的业务体验。

为解决以上技术问题， 本发明提供了一种用户面定位方法， 该方法包括： 终端与其归属的定位服务器建立数据连接后， 向所述定位服务器发送针 对第三方的定位请求；

所述定位服务器接收并处理定位请求， 在获取定位结果前向所述终端发 送响应消息， 其中携带定位请求处理信息；

所述终端接收所述响应消息。

优选的， 所述定位服务器向所述终端发送的响应消息中 还携带会话标识 信息； 所述终端接收所述响应消息后， 所述方法还包括：

若所述数据连接中途断开， 所述终端与所述定位服务器重新建立数据连 接， 并向所述定位服务器发送定位请求， 其中携带所述会话标识信息；

所述定位服务器根据接收的定位请求中的会话 标识信息将緩存的第三方 的定位结果发送给所述终端。 优选的， 所述终端接收所述响应消息后与所述定位服务 器重新建立数据 连接前， 所述方法还包括：

所述定位服务器获取定位结果，并判断与所述 终端的数据连接是否断开 , 如断开则緩存所述定位结果， 并向所述终端发送触发消息以触发所述终端重 建连接， 所述触发消息中携带所述会话标识信息。

优选的， 所述定位请求处理信息包括表明处理进程、 处理方式或预计完 成时间的信息。

优选的， 所述终端接收所述响应消息后， 所述方法还包括： 所述终端根 据所述定位请求处理信息选择断开或保持所述 数据连接。

为解决以上技术问题， 本发明还提供了一种用户面定位系统， 该系统包 括终端及定位服务器， 其中：

所述终端包括相连接的第一连接建立模块及定 位代理模块， 所述第一连 接建立模块设置为： 与其归属的定位服务器建立连接； 所述定位代理模块设 置为： 向所述定位服务器发送针对第三方的定位请求 ， 以及接收所述定位服 务器发送的响应消息， 其中携带定位请求处理信息；

所述定位服务器包括相连接的第二连接建立模 块和定位请求处理模块， 所述第二连接建立模块设置为： 与所述终端建立连接， 所述定位请求处理模 块设置为： 接收并处理定位请求， 以及在获取定位结果前向所述终端发送响 应消息。 优选的， 所述定位服务器向所述终端发送的响应消息中 还携带会话标识 信息；

所述终端的第一连接建立模块还设置为： 在所述数据连接中途断开时， 与所述定位服务器重新建立数据连接； 所述定位代理模块还设置为： 与所述 定位服务器重建数据连接后， 向所述定位服务器发送定位请求， 其中携带所 述会话标识信息；

所述定位服务器的定位请求处理模块还设置为 ： 在获取定位结果后緩存 所述定位结果， 接收所述终端发送的携带所述会话标识信息的 定位请求， 以 及根据接收的定位请求中的会话标识信息将緩 存的所述定位结果发送给所述 终端。 优选的， 所述定位服务器还包括与定位请求处理模块连 接的连接触发模 块， 所述连接触发模块设置为： 在获取定位结果后， 判断与所述终端的数据 连接是否断开， 在判断连接断开时向所述终端发送触发消息以 触发所述终端 重建连接， 所述触发消息中携带所述会话标识信息。 优选的， 所述定位请求处理信息包括表明处理进程、 处理方式或预计完 成时间的信息。

优选的， 所述终端还包括与所述连接建立模块和定位代 理模块连接的连 接维护模块， 连接维护模块设置为： 根据所述定位请求处理信息选择断开或 保持连接。

为解决以上技术问题， 本发明还提供了一种终端， 所述终端包括相连接 的连接建立模块及定位代理模块， 其中：

所述连接建立模块设置为： 与其归属的定位服务器建立连接， 以及在所 述数据连接中途断开时， 与所述定位服务器重新建立数据连接；

所述定位代理模块设置为： 向所述定位服务器发送针对第三方的定位请 求， 接收所述定位服务器发送的响应消息， 其中携带定位请求处理信息以及 会话标识信息； 以及与所述定位服务器重建数据连接后， 向所述定位服务器 发送定位请求， 其中携带所述会话标识信息。

优选的， 所述终端还包括与所述连接建立模块和定位代 理模块连接的连 接维护模块， 所述连接维护模块设置为： 根据所述定位请求处理信息选择断 开或保持连接。

为解决以上技术问题， 本发明还提供了另一种用户面定位方法， 该方法 包括：

定位服务器接收并处理终端发送的针对第三方 的定位请求；

在获取定位结果前， 所述定位服务器向所述终端发送响应消息， 其中携 带定位请求处理信息。 优选的， 所述定位服务器向所述终端发送的响应消息中 还携带会话标识 信息； 所述定位服务器向所述终端发送响应消息后， 该方法还包括： 所述定位服务器获取定位结果并緩存所述定位 结果；

所述定位服务器接收所述终端发送的携带所述 会话标识信息的定位请 求； 以及

所述定位服务器根据所述会话标识信息将緩存 的所述定位结果发送给所 述终端。 优选的， 所述定位服务器获取定位结果后， 接收携带所述会话标识信息 的定位请求前， 该方法还包括：

所述定位服务器判断与所述终端的数据连接是 否断开， 如断开则向所述 终端发送触发消息以触发所述终端重建连接， 所述触发消息中携带所述会话 标识信息。

优选的， 其中， 所述定位请求处理信息包括表明处理进程、 处理方式或 预计完成时间的信息。

为解决以上技术问题， 本发明还提供了一种定位服务器， 该定位服务器 包括相连接的连接建立模块和定位请求处理模 块，所述连接建立模块设置为： 与终端建立连接， 所述定位请求处理模块设置为： 接收并处理所述终端发送 的针对第三方的定位请求，以及在获取定位结 果前向所述终端发送响应消息。

优选的， 所述定位请求处理模块向所述终端发送的响应 消息中还携带会 话标识信息；

所述定位请求处理模块还设置为：在获取定位 结果后緩存所述定位结果， 接收所述终端发送的携带所述会话标识信息的 定位请求， 以及根据接收的定 位请求中的会话标识信息将緩存的所述定位结 果发送给所述终端。 优选的， 所述定位服务器还包括与定位请求处理模块连 接的连接触发模 块， 所述连接触发模块设置为： 在获取定位结果后， 判断与所述终端的数据 连接是否断开， 以及在判断连接断开时向所述终端发送触发消 息以触发所述 终端重建连接， 所述触发消息中携带所述会话标识信息。

优选的， 所述定位请求处理信息包括表明处理进程、 处理方式或预计完 成时间的信息。

本发明在终端发起对第三方的定位后， 定位服务器在尚未获取定位结果 (定位成功或定位失败）前， 向发起定位请求的终端发送定位处理信息， 可 使得该终端及时了解当前定位请求的相关处理 信息， 改善用户的业务体验。 附图概述

图 1是现有规范中终端定位第三方流程图；

图 2是本发明提供的 SUPL体系结构示意图；

图 3是本发明用户面定位方法的示意图；

图 4是本发明实施例一的流程示意图， SET1在定位过程中始终保持连接； 图 5是本发明实施例二的流程示意图， 定位过程中连接断开时终端主动 重建连接；

图 6是本发明实施例三的流程示意图， 定位过程中连接断开时 H-SLP1 触发终端重建连接；

图 7 是本发明实施例四的流程示意图， 定位过程中连接断开时 H-SLP1 触发终端重建连接；

图 8是本发明用户面定位系统的一实施例的示意� �；

图 9是本发明用户面定位系统的又一实施例的示� �图。 本发明的较佳实施方式

根据图 1所示的定位流程， 假如用户的隐私设置表明其需要被通知并给 出确认后才能允许定位， 或者是 H-SLP1 判断出需要通过漫游接口来获取被 定位终端的位置信息时， 或者是 H-SLP1选择了釆用发送 SUPL INIT消息来 触发被定位终端完成定位交互时，接下来的定 位处理过程， 将是耗时较长的。 而根据当前的业务流程描述， H-SLP1 必须在整个定位过程结束后， 才通过 SUPL END消息将位置结果反馈给发起请求的终端。 因此， 在此过程中， 发 起请求的终端将只能处于盲目的等待状态， 并不清楚定位服务器是否已经开 始处理此次请求， 以及何时可能获得位置结果， 一直保持和 SUPL定位服务 器之间的数据连接， 直到 SUPL定位服务器定位成功或者返回该用户失败� � 知， 因此， 带来了用户体验不佳的问题， 尤其是当发起定位的用户要求了较 高精度的位置结果， 并且定位过程釆用了耗时较长的定位方法， 或者是被定 位终端需要明确给出确认才能够允许被定位的 时候。 发起定位的用户往往需 要处于盲目的等待状态， 而不知道这种等待是由于定位请求没有被服务 器所 接收， 还是由于定位过程本身的原因所造成的。

从以上分析可以看出， 用户业务体验不佳主要原因在于用户被无奈地 置 于盲目等待的状态， 而不能在得到成功和失败的定位结果之前， 获取任何反 馈信息。

本发明用户面定位方法、 系统、 终端及定位服务器的主要思想是， 在终 端发起对第三方的定位后， 定位服务器在尚未获取定位结果（定位成功或 定 位失败）前， 向发起定位请求的终端发送定位处理信息， 以便该终端及时了 解当前定位请求的相关处理信息， 进而有选择地保持或中断连接。

以下就本发明所基于的实现 SUPL用户面定位的系统结构进行说明。 如 图 2所示，在这个体系结构中， LCS Client是作为网络侧发起业务流程的请求 者， 因此， 在本技术方案的讨论中， 不会涉及， 因此不予赘述。

SLP ( SUPL Location Platform, SUPL定位平台）是一个核心的部分， 是 实现业务流程控制的 SUPL定位服务器。 在用户面定位方案中， SLP和被定 位终端之间有着归属绑定关系。 SLP—般可以通过用户终端号码来判断该用 户是否归属于本 SLP。 当多个 SLP之间是有业务互通关系时， 这些 SLP之间 通过 Lr参考点相连。 通常情况下， 对应于这个 Lr参考点的规范协议是 OMA LOC定义的 RLP ( Roaming Location Protocol, 漫游定位协议）协议。 某一个 SLP使用这个 RLP协议，请求其它 SLP获取被定位终端的位置信息的前提是， 发起请求的 SLP根据用户的号码信息， 判断出用户归属的 SLP , 以及对应的 访问地址、 端口或者是 URL等信息。

终端也是整个用户面定位系统结构中的一部分 ， 并且终端必须支持和 SUPL定位服务器之间的 OMA LOC定义的 ULP( UserPlane Location Protocol, 用户面定位协议）协议。 在此系统结构中， 每一个终端都有其归属的 SLP, 本发明中用 H-SLP ( Home SLP )或者 HSLP来表示。 在具体定位过程中， 终 端使用建立数据连接过程中的信息对服务器进 行认证， 保证该服务器确实是 其归属的、 可信的 SUPL定位服务器。 终端和 SUPL定位服务器通过该数据 连接传递的消息包含除了 SUPL INIT消息之外的全部 ULP规范中定义的消 息。

在 SUPL定位体系结构中， 终端和 SUPL定位服务器之间的数据连接一 般由终端主动建立的。 当终端和 SUPL定位服务器之间还没有完成连接之前， SUPL定位服务器需要通知终端完成这个工作。� �个功能是通过体系结构中的 触发消息通道实现的。 需要说明的是， 这里描述的触发消息通道是对具体触 发消息发送方式的抽象， 比如在 SUPL 2.0规范中， 定义了 5种具体的触发消 息发送方式， 分别是 MT ( Mobile Terminated ) 的短消息， WAP Push消息， UDP方式的 Push消息，通过紧急方式的 IMS核心网以及通常业务方式的 IMS 核心网发送的 SIP Push消息。 通过这些具体的方式， SUPL定位服务器可以 在收到 LCS Client, 或者说外部定位应用请求的情况下， 以及在其认为需要 的时候， 向终端发送 SUPL INIT消息， 触发终端主动建立和服务器之间的数 据连接， 并完成后续的用户面消息交互和定位计算功能 。

SUPL定位架构主要是为高精度 AGPS ( Assisted GPS )等技术服务的， 图中只是针对 AGPS定位方法所需要的 GPS参考网给出了示意。 当然， 针对 更多的现有的和未来的定位方法， 在该体系结构中还可对接其它的参考数据 源， 甚至是对接控制面的系统中的网元， 比如在 LTE控制面定位规范中描述 的和 eNB和 MME之间的协议接口。 可理解地， 具体的数据来源并非本发明 重点关注的。

本发明的重点在于： SUPL定位服务器接收终端的定位请求后，在获� �定 位成功或定位失败的定位结果前， 向发起定位请求的终端发送定位请求处理 信息， 如图 3所示， 该方法包括：

步骤 301 : 终端与其归属的定位服务器建立数据连接后， 向所述定位服 务器发送针对第三方的定位请求；

步骤 302: 所述定位服务器接收并处理所述定位请求， 在获取定位结果 前向所述终端发送响应消息， 其中携带定位请求处理信息； 步骤 303: 所述终端接收所述响应消息。

以下结合附图对本发明的具体实施方式进行 说明

实施例一

如图 4所示，在该实施例一中，终端 SET1向其归属的 SUPL定位服务器

H-SLP1发起定位第三方 SET2的定位流程包括以下步骤：

步骤 401 : SET1与 H-SLP1建立数据连接；

当用户启动终端上的定位应用， 并且要求对另一个用户进行定位时， 终 端上的 SUPL代理功能将启动， 开始建立和其归属的 SLP之间的安全数据连 接；

步骤 402: SET1向 H-SLP1发送定位请求（ SUPL SET INIT ) 消息； 在 SUPL SET INIT消息中包含被定位终端的号码标识以及发� �该请求的 应用期望的位置结果精度和完成时间等参数。

在 SUPL SET INIT消息中， 还包含 SET1为此次会话分配的终端的会话 标识部分， 尚未包含服务器端为此分配的会话标识部分， 因此从会话标识的 角度看， 还是不完整的。

步骤 403 ： H-SLP1 对收到的定位请求进行处理， 并发送响应 （SUPL RESPONSE ) 消息；

根据收到的定位请求， H-SLP1为该会话分配服务器端的会话标识部分， 与 SET1分配的会话标识部分组成完整的会话标识� �息。

H-SLP1还需要判断被定位终端 SET2是否归属本定位服务器， 并在判断 不归属本定位服务器时， 通过 Lr参考点， 发起漫游定位请求， 要求其它的定 位平台帮助获得被定位终端的位置。 假如被定位终端是归属本定位服务器， H-SLP1将需要判断被定位终端 SET2的隐私策略是否允许其被发起请求的用 户所定位， 以及该用户终端是否能够支持 SUPL方式的定位。

当 SET2支持 SUPL时， H-SLP1通过向其发送 SUPL INIT消息， 其中包 含可能的隐私通知和确认元素， 触发 SET2对本次请求进行确认， 并完成获 取其位置的交互过程。

当 SET2不能支持 SUPL定位时， H-SLP1通过其它的途径， 比如短信方 式， 来辅助获取被定位终端对本次请求的确认， 或通过控制面方式的定位， 来获取其位置。

当判断 SET2不是归属本定位服务器， 而是归属 H-SLP2时， H-SLP1将 需要通过 Lr参考点向 H-SLP2发送漫游定位请求消息， 要求 H-SLP2帮助获 取 SET2的位置。

在获取定位结果之前， H-SLP1向发起请求的 SET1回复响应消息， 其中 携带表明处理进程、 处理方式或预期处理时间等定位请求处理信息 。

表明处理进程的信息包括但不限于以下几种： 此次定位请求已经被接收 并处理的信息、 被定位终端是否已经接收定位请求的信息、 是否已经向被定 位终端发出隐私确认的信息。

表明处理方式的信息包括但不限于： 通过 SUPL方式进行处理。

优选地， H-SLP1预设对应于不同处理情景的预期处理时间 ，再根据 SET2 定位数据来源以及 SET2 的隐私设置等相关信息进行选择确定。 ， 据此， 发 起请求的 SET1 可以了解到接下来可能的处理进程和预期时间 ， 并保持和 H-SLP1之间的连接。

步骤 404: 在向发起请求的 SET1反馈响应消息后， H-SLP1继续完成定 位过程；

步骤 405:获取定位结果后， H-SLP1向 SET1发送定位结束（ SUPL END ) 消息， 其中携带定位成功的被定位终端 SET2的位置信息或定位失败的信息。

实施例二

如图 5所示，在该实施例二中，终端 SET1向其归属的 SUPL定位服务器 H-SLP1发起定位第三方 SET2的定位流程包括以下步骤： 步骤 501 : SET1与 H-SLP1建立数据连接；

当用户启动终端上的定位应用， 并且要求对另一个用户进行定位时， 终 端上的 SUPL代理功能将启动， 开始建立和其归属的 SLP之间的安全数据连 接；

步骤 502: SET1向 H-SLP1发送定位请求（ SUPL SET INIT ) 消息； 在 SUPL SET INIT消息中包含被定位终端的号码标识以及发� �该请求的 应用期望的位置结果精度和完成时间等参数。

在 SUPL SET INIT消息中， 还包含 SET1为此次会话分配的终端的会话 标识部分， 尚未包含服务器端为此分配的会话标识部分， 因此从会话标识的 角度看， 还是不完整的。

步骤 503 ： H-SLP1 对收到的定位请求进行处理， 并发送响应 （SUPL RESPONSE ) 消息；

根据收到的定位请求， H-SLP1为该会话分配服务器端的会话标识部分， 与 SET1分配的会话标识部分组成完整的会话标识� �息。

H-SLP1还需要首先判断被定位终端 SET2是否归属本定位服务器， 并在 判断不归属本定位服务器时， 通过 Lr参考点发起漫游定位请求， 要求其它的 定位平台帮助获得被定位终端的位置。假如被 定位终端是归属本定位服务器， H-SLP1将需要判断被定位终端 SET2的隐私策略是否允许其被发起请求的用 户所定位， 以及该用户终端是否能够支持 SUPL方式的定位。

当 SET2支持 SUPL时， H-SLP1通过向其发送 SUPL INIT消息， 其中包 含可能的隐私通知和确认元素， 触发 SET2对本次请求进行确认， 并完成获 取其位置的交互过程。

当 SET2不能支持 SUPL定位时， H-SLP1通过其它的途径， 比如短信方 式， 来辅助获取被定位终端对本次请求的确认， 或通过控制面方式的定位， 来获取其位置。

当判断 SET2不是归属本定位服务器， 而是归属 H-SLP2时， H-SLP1将 需要通过 Lr参考点向 H-SLP2发送漫游定位请求消息， 要求 H-SLP2帮助获 取 SET2的位置。 在获取定位结果之前， H-SLP1向发起请求的 SET1回复响应消息， 其中 携带会话标识信息， 以及表明处理进程、 处理方式或预期处理时间等定位请 求处理信息。

表明处理进程的信息包括但不限于以下几种： 此次定位请求已经被接收 并处理的信息、 被定位终端是否已经接收定位请求的信息、 是否已经向被定 位终端发出隐私确认的信息。

表明处理方式的信息包括但不限于： 通过 SUPL方式进行处理。

优选地， H-SLP1预设对应于不同处理情景的预期处理时间 ，再根据 SET2 定位数据来源以及 SET2 的隐私设置等相关信息进行选择确定。 ， 据此， 发 起请求的 SET1 可以了解到接下来可能的处理进程和预期时间 ， 并选择保持 或者断开和 H-SLP1之间的连接。

步骤 504: 在向发起请求的 SET1反馈响应消息后， H-SLP1继续完成定 位过程， 获取定位结果， 并判断和发起请求的 SET1 之间的连接是否还处于 保持状态， 如处于保持状态， 则 H-SLP1执行步骤 506, 否则 H-SLP1緩存定 位结果， 执行步骤 505;

步骤 505: SET1与 H-SLP1重新建立连接， 并重新发送针对第三方用户 的定位请求（ SUPL SET INIT ) 消息；

优选地， SET1在 HLP-S反馈的预期处理时间之后， 重新建立和 HLP1之 间的数据连接。 连接建立后， 发起定位请求的 SET1重新发起针对 SET2的定 位请求， 不过， 在此消息中， 会话标识部分是前述响应消息中的完整的会话 标识信息， 以便 H-SLP1 根据此会话标识信息判断出该请求是针对尚未 完成 的定位会话的。

步骤 506: H-SLP1向 SET1发送定位结束（ SUPL END )消息， 其中携带 定位成功的被定位终端 SET2的位置信息或定位失败的信息。

对于未断开连接的情形， H-SLP1获取定位结果后直接发送携带定位结果 的定位结束消息。

对于中途断开 （包括 SET1 选择断开或连接意外中断） 又重新连接的情 形， H-SLPl收到定位请求后， 根据会话标识信息判断对应的会话定位过程是 否已经完成， 如果尚未完成， 则重复步骤 503 , 向 SET1反馈响应消息， 并表 明目前已经处理的内容和预期的完成时间； 4叚如对应的会话定位过程已经结 束， H-SLP1已经获取并緩存了定位结果，则通过 SUPL END消息将定位结果 带给请求的终端用户， 结束本次 SUPL定位会话。

实施例三

如图 6所示，在该实施例三中，终端 SET1向其归属的 SUPL定位服务器 H-SLP1发起定位第三方 SET2的定位流程包括以下步骤：

步骤 601 : SET1与 H-SLP1建立数据连接；

当用户启动终端上的定位应用， 并且要求对另一个用户进行定位时， 终 端上的 SUPL代理功能将启动， 开始建立和其归属的 SLP之间的安全数据连 接；

步骤 602: SET1向 H-SLP1发送定位请求（ SUPL SET INIT ) 消息； 在 SUPL SET INIT消息中包含被定位终端的号码标识以及发� �该请求的 应用期望的位置结果精度和完成时间等参数。

在 SUPL SET INIT消息中， 还包含 SET1为此次会话分配的终端的会话 标识部分， 尚未包含服务器端为此分配的会话标识部分， 因此从会话标识的 角度看， 还是不完整的。

步骤 603 ： H-SLP1 对收到的定位请求进行处理， 并发送响应 （SUPL

RESPONSE ) 消息；

根据收到的定位请求， H-SLP1为该会话分配服务器端的会话标识部分， 与 SET1分配的会话标识部分组成完整的会话标识� �息。

H-SLP1还需要首先判断被定位终端 SET2是否归属本定位服务器， 并在 判断不归属本定位服务器时， 通过 Lr参考点发起漫游定位请求， 要求其它的 定位平台帮助获得被定位终端的位置。假如被 定位终端是归属本定位服务器， H-SLP1将需要判断被定位终端 SET2的隐私策略是否允许其被发起请求的用 户所定位， 以及该用户终端是否能够支持 SUPL方式的定位。 当 SET2支持 SUPL时， H-SLP1通过向其发送 SUPL INIT消息， 其中包 含可能的隐私通知和确认元素， 触发 SET2对本次请求进行确认， 并完成获 取其位置的交互过程。

当 SET2不能支持 SUPL定位时， H-SLP1通过其它的途径， 比如短信方 式， 来辅助获取被定位终端对本次请求的确认， 或通过控制面方式的定位， 来获取其位置。

当判断 SET2不是归属本定位服务器， 而是归属 H-SLP2时， H-SLP1将 需要通过 Lr参考点向 H-SLP2发送漫游定位请求消息， 要求 H-SLP2帮助获 取 SET2的位置。

在获取定位结果之前， H-SLP1向发起请求的 SET1回复响应消息， 其中 携带完整的会话标识信息， 以及表明处理进程、 处理方式或预期处理时间等 定位请求处理信息。

表明处理进程的信息包括但不限于以下几种： 此次定位请求已经被接收 并处理的信息、 被定位终端是否已经接收定位请求的信息、 是否已经向被定 位终端发出隐私确认的信息。

表明处理方式的信息包括但不限于： 通过 SUPL方式进行处理。

优选地， H-SLP1预设对应于不同处理情景的预期处理时间 ，再根据 SET2 定位数据来源以及 SET2 的隐私设置等相关信息进行选择确定。 ， 据此， 发 起请求的 SET1 可以了解到接下来可能的处理进程和预期时间 ， 并选择保持 或者断开和 H-SLP1之间的连接。

步骤 604: 在向发起请求的 SET1反馈响应消息后， H-SLP1继续完成定 位过程， 获取定位结果， 并判断和发起请求的 SET1 之间的连接是否还处于 保持状态， 如处于保持状态， 则执行步骤 607; 如已断开连接， 则 H-SLP1緩 存定位结果， 执行步骤 605;

步骤 605: H-SLP1向 SET1发送触发（ SUPL INIT ) 消息；

当 H-SLP1判断与发起请求的 SET1之间的连接断开后，可选择地向请求 终端发起 SUPL INIT触发消息， 在此消息中， 包含和前述响应消息中相同的 完整的会话标识信息， 用以向终端表明， 本次请求是针对一个尚未完全结束 的定位会话。 同时， 可选地， 在此消息中， 携带明确的服务类型标识， 用以 表明此消息用于触发请求终端到服务器获取已 经获得的定位结果。 同时， 可 选地， 在此消息中， 携带明确的定位类型标识， 用以表明此消息并非用于触 发一次终端和定位服务器之间的用于获取自身 位置的交互过程。

步骤 606: SET1与 H-SLP1重新建立连接， 并发送定位请求（ SUPL POS INIT ) 消息；

SET1在收到触发消息后， 重新建立和 HLP1之间的数据连接。 优选地， 该终端从收到的触发消息中获知， 此消息是针对一个尚未完全结束的会话以 及该会话的完整的会话标识信息。 对应可选地， 该终端从收到的触发消息中 获知， 此消息用于触发其到服务器获取一个已经完成 的定位过程的结果， 和 / 或该消息并不用于触发其和服务器之间的用于 获取自身位置的交互过程。

连接建立后， 发起定位请求的 SET1 重新发起针对 SET2 的定位请求 ( SUPL POS INIT ) , 在此消息中， 包括前述响应消息中的完整的会话标识 信息， 以便 H-SLP1 根据此会话标识信息判断出该请求是针对尚未 完成的定 位会话的。 在该消息中， 还优选地， 包括明确服务标识信息， 用以表明本次 请求希望获取已经緩存在定位服务器上的定位 结果。

步骤 607： H-SLP1向 SET1发送定位结束（ SUPL END )消息， 其中携带 定位成功的被定位终端 SET2的位置信息或定位失败的信息。

对于未断开连接的情形， H-SLP1获取定位结果后直接发送携带定位结果 的定位结束消息。

对于中途断开又重新连接的情形， H-SLP1收到定位请求后， 根据会话标 识信息判断对应的会话定位过程是否已经完成 ， 如果尚未完成， 则重复步骤 603 ,向 SET1反馈响应消息，并表明目前已经处理的内� �和预期的完成时间； 假如对应的会话定位过程已经结束， H-SLP1已经获取并緩存了定位结果， 则 通过 SUPL END消息将定位结果带给请求的终端用户， 结束本次 SUPL定位 会话。

实施例四

实施例四中， 终端 SET1向其归属的 SUPL定位服务器 H-SLP1发起定位 第三方 SET2的定位流程如图 7所示， 与实施例三相比， 图 7中实施例四的 步骤 701-705、 707与实施例的步骤 601-605、 607分别对应相同， 不同之处在 于： 步骤 706中， SET1重新发送针对第三方的定位请求（ SUPL SET INIT ) 消息；在此消息中的会话标识部分是前述响应 消息中的完整的会话标识信息 , 以便 H-SLP1根据此会话标识信息判断出该请求是针对 尚未完成的定位会话。

为了实现以上方法， 本发明还提供了一种用户面定位系统， 如图 8所示， 该系统包括终端及定位服务器， 其中：

所述终端包括相连接的连接建立模块及定位代 理模块， 所述连接建立模 块用于与其归属的定位服务器建立连接； 所述定位代理模块， 用于向所述定 位服务器发送针对第三方的定位请求， 以及接收所述定位服务器发送的响应 消息， 其中携带定位请求处理信息；

所述定位服务器包括相连接的连接建立模块和 定位请求处理模块， 所述 连接建立模块用于与所述终端建立连接， 所述定位请求处理模块用于接收并 处理定位请求， 以及在获取定位结果前向所述终端发送响应消 息。

优选地， 所述定位服务器向所述终端发送的响应消息中 还携带完整的会 话标识信息；

所述终端的连接建立模块， 还用于在所述数据连接中途断开时， 主动或 被动与所述定位服务器重新建立数据连接； 所述定位代理模块， 还用于与所 述定位服务器重建数据连接后， 向所述定位服务器发送定位请求， 其中携带 所述完整的会话标识信息；

所述定位服务器的定位请求处理模块， 还用于在获取定位结果后緩存所 述定位结果， 以及接收所述终端发送的携带所述完整的会话 标识信息的定位 请求， 还用于根据接收的定位请求中的完整的会话标 识信息将緩存的所述定 位结果发送给所述终端。

图 9为又一实施例， 与图 8不同的是， 如所述定位服务器还包括与定位 请求处理模块连接的连接触发模块， 用于在获取定位结果后， 判断与所述终 端的数据连接是否断开， 还用于在判断连接断开时向所述终端发送触发 消息 以触发所述终端重建连接， 所述触发消息中携带所述完整的会话标识信息 。

所述定位请求处理信息包括表明处理进程、 处理方式或预计完成时间的 信息。

优选的， 如图 8和图 9所示， 所述终端还包括与所述连接建立模块和定 位代理模块连接的连接维护模块， 用于根据所述定位请求处理信息选择断开 或保持连接。

另外， 本发明还提供了一种终端， 其特征在于， 所述终端包括相连接的 连接建立模块及定位代理模块， 其中：

所述连接建立模块用于与其归属的定位服务器 建立连接， 还用于在所述 数据连接中途断开时， 与所述定位服务器重新建立数据连接；

所述定位代理模块，用于向所述定位服务器发 送针对第三方的定位请求， 以及接收所述定位服务器发送的响应消息， 其中携带定位请求处理信息以及 完整的会话标识信息； 还用于与所述定位服务器重建数据连接后， 向所述定 位服务器发送定位请求， 其中携带所述完整的会话标识信息。

优选地， 所述终端还包括与所述连接建立模块和定位代 理模块连接的连 接维护模块， 用于根据所述定位请求处理信息选择断开或保 持连接。

另外， 本发明还提供了一种定位服务器， 该定位服务器包括相连接的连 接建立模块和定位请求处理模块， 所述连接建立模块用于与终端建立连接， 所述定位请求处理模块用于接收并处理所述终 端发送的针对第三方的定位请 求， 以及在获取定位结果前向所述终端发送响应消 息。

优选的， 所述定位服务器向所述终端发送的响应消息中 还携带完整的会 话标识信息；

所述定位服务器的定位请求处理模块， 还用于在获取定位结果后緩存所 述定位结果， 以及接收所述终端发送的携带所述完整的会话 标识信息的定位 请求， 还用于根据接收的定位请求中的完整的会话标 识信息将緩存的所述定 位结果发送给所述终端。 优选地， 所述定位服务器还包括与定位请求处理模块连 接的连接触发模 块， 用于在获取定位结果后， 判断与所述终端的数据连接是否断开， 还用于 在判断连接断开时向所述终端发送触发消息以 触发所述终端重建连接， 所述 触发消息中携带所述完整的会话标识信息。

所述定位请求处理信息包括表明处理进程、 处理方式或预计完成时间的 信息。

对应于以上定位服务器， 本发明还提供了一种用户面定位方法， 该方法 包括：

定位服务器接收并处理终端发送的针对第三方 的定位请求；

在获取定位结果前， 所述定位服务器向所述终端发送响应消息， 其中携 带定位请求处理信息。

优选的， 所述定位服务器向所述终端发送的响应消息中 还携带完整的会 话标识信息； 所述定位服务器向所述终端发送响应消息后， 该方法还包括： 所述定位服务器获取定位结果并緩存所述定位 结果；

所述定位服务器接收所述终端发送的携带所述 完整的会话标识信息的定 位请求；

所述定位服务器根据所述完整的会话标识信息 将緩存的所述定位结果发 送给所述终端。

优选的， 所述定位服务器获取定位结果后， 接收携带所述完整的会话标 识信息的定位请求前， 该方法还包括：

所述定位服务器判断与所述终端的数据连接是 否断开， 如断开则向所述 终端发送触发消息以触发所述终端重建连接， 所述触发消息中携带所述完整 的会话标识信息。

所述定位请求处理信息包括表明处理进程、 处理方式或预计完成时间的 信息。

相比于现有技术， 本发明在终端发起对第三方的定位后， 定位服务器在 尚未获取定位结果（定位成功或定位失败）前 ， 先向发起定位请求的终端发 送定位处理信息， 如处理进程、 处理方式及预期处理时间等处理信息， 以便 该终端及时了解当前定位请求的相关处理信息 ， 进而有选择地保持或中断连 接。 另外， 定位服务器在获得定位结果前， 将该定位会话完整的会话标识信 息发送给终端， 当因定位会话建立的数据连接意外或选择中断 时， 终端在定 位请求中将完整的会话标识信息发送给定位服 务器， 可以使得终端快速得到 定位服务器緩存但尚未发送给该终端的定位结 果， 进而提高定位效率， 并进 一步改善用户的业务体验。

可理解地， 但就为了实现用户在定位连接中断后尽快得到 第三方定位结 果这一目的而言， 定位服务器只需要将完整的会话标识信息单独 发送给发起 定位的终端， 与是否发送定位处理信息、 是否同时发送定位处理信息无关。 具体来说， 定位服务器在收到终端针对第三方的定位请求 并获得该定位会话 的完整会话标识信息后， 将该完整的会话标识信息发送给该终端备用， 连接 中断后， 终端主动或在定位服务器触发下重建与定位服 务器的连接， 并向定 位服务器发送携带该完整会话标识的定位请求 ， 即可使得定位服务器在已获 得对应定位结果的前期下， 尽快将定位结果发送给该终端。

除初次建立连接的情形下， 定位服务器反馈定位请求处理信息外， 可扩 展地， 在连接重新建立或连接恢复时， 定位服务器也可针对定位请求反馈相 应的定位请求处理信息， 使发起定位的终端及时了解当前定位请求的相 关处 理信息。

如连接中断， 则需要重建连接， 若连接处于保持或挂起状态则需要恢复 连接。 可理解地， 连接中途断开指在尚未获得定位结果时， 定位会话对应的 连接中断的情形。

在恢复连接时， 终端也可以通过发送会话标识信息， 从而获得会话标识 信息对应会话的定位结果。

本领域普通技术人员可以理解上述方法中的 全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现。 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明不限制于任 何特定形式的硬件和软件的结合。

以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

工业实用性

本发明在终端发起对第三方的定位后， 定位服务器在尚未获取定位结果 (定位成功或定位失败）前， 向发起定位请求的终端发送定位处理信息， 可 使得该终端及时了解当前定位请求的相关处理 信息， 改善用户的业务体验。