OMA-SUPL包含一套非常复杂的协议，它综合了移动通信领域现有的一些标准和协议（如3GPP相关协议、WAP等），其目的是充分利用移动网络的相关特性以为用户提供更好的位置服务。OMA-SUPL目前最新版本是3.0，表9-7列举了OMA-SUPL各版本的特点。 :-:  关于代理模式和非代理模式的区别，请参考9.2.3节SUPL架构。 表9-7中的缩写词含义如下。 * RRLP（Radio Resource LCS Protocol）是一种协议，LCS是Location Services的缩写。 * RRC（Radio Resource Control）是一种协议。 * LPP（LTE Positioning Protocol）是基于LTE的定位协议。 * LPPe（OMA LPP Extensions）是LPP扩展协议。 * TIA（Telecommunications Industry Association）是美国电信工业协会。 * OTDOA（Observed Time Difference of Arrival）是一种移动定位技术。 >[info] 提示　OMA-SUPL涉及很多来自移动通信领域的概念和词汇。由于篇幅问题，笔者不打算对它们进行深入介绍，感兴趣的读者可自行研究。 **1、SUPL架构** OMA-SUPL是一个比较复杂的系统，图9-26所示为它的架构。 :-:  图9-26　SUPL架构 图9-26中主要包含三个部分。 * 左下方的SET代表AGPS服务的客户端，例如我们的Android智能手机。在规范中，SET全称是SUPL Enabled Terminal（终端）。 * 右下方的SLP①（SUPL Location Platform）包含两个重要组成部分，一个是SLC（SUPL Location Center），其作用是和SET交互，例如处理来自SET的请求；另外一个是SPC（SUPL Positioning Center），其作用是进行定位计算。如果SET直接和SPC交互，则称为非代理工作模式。相反，如果SET借助SLC与SPC交互的话，则称为代理模式[29]。SUPL 3.0版协议只支持代理模式，故SET将只能和SLC交互。 * 右上方的SUPL Agent②，是一个需要获取位置信息的应用程序。SUPL Agent可以运行在SET中（如图中左下方的SET和SUPL Agent），也可以运行在SUPL Network③中，如图中右上方单独绘制的SUPL Agent。不论哪种情况，定位请求只能由SUPL Agent发起。如果SUPL Agent在SET中，这种请求方式叫SET Initiated请求（终端始发定位请求）[29]。如果SUPL Agent位于SUPL Network中，则这种请求方式叫Network Initiated请求（网络始发定位请求）。 除了上述三个部分外，图9-26中的连线用于表示它们之间交互所使用的协议等信息。 对于网络始发定位请求而言，SLP需要通知目标SET参与定位工作（而在终端始发定位请求中，请求的发起者与SET在一个设备上），这个流程也叫SUPL INIT。SUPL INIT支持的协议很多，例如通过SIP、WAP、SMS等，或者直接利用UDP、TCP等。在使用SIP、WAP或SMS等协议时还需要借助移动通信领域中现有的组件（如SMS需要先通过短信息中心SMS Center来处理）， 所以图中也绘制了这些必要的组件以及这些组件和SLP交互的协议，如SMSC、SIP/IP Core、WAP PRG（Wireless Application Protocol Push Proxy Gateway）、PAP（Push Access Protocol）、POTAP（Push Over The Air Protocol）等。SET和SLP交互的流程由ULP（User Location Protocol， 下节将详细介绍它）描述。 在SLP中，SLC和SPC交互的协议叫ILP（Internal Location Protocol）。 OMA-SUPL还为SET、SLC和SPC定义了一组Function来描述它们应该具有的功能，表9-8 列举了这些Function的名称和功能。 :-:  :-:  SUPL的内容非常多，不过和本章后文代码分析相关的内容大多集中在ULP协议即工作流程上。下面来看看ULP。 **2、ULP介绍** ULP主要描述SET和SLP之间该如何交互以完成定位请求。根据上一节对SUPL Agent的介绍，ULP的使用分为两大类④。 * SUPL Agent位于SET中，由于定位请求只能由SUPL Agent发起，所以在ULP中，它被称为SET Initiated定位请求。其典型的使用案例就是在Android手机中打开导航类应用，这将触发手机发起一次定位请求。 * SUPL Agent位于SUPL Network中，这种情况称为Network Initiated定位请求。例如，某些网络服务需要跟踪SET的位置，就会使用这种方式。不过，笔者目前没有找到与之相关的典型使用案例，有知晓的读者不妨与大家分享相关知识。 这两大类ULP应用场景对应的工作流程各不相同，我们先来看最常见的SET Initated请求的工作流程。 **①、SET Initiated ULP工作流程** 图9-27描述了SET Initiated ULP的工作流程。 :-:  图9-27　SET Initiated ULP流程 1. SET首先和SLP建立数据链接。为了保证数据的安全性，这个链接需要基于TLS（Transport Layer Security，传输层安全）。图中的D/H-SLP为Discovered/Home-SLP的缩写，H-SLP即SET所在运营商所建立的SLP，而D-SLP为SET搜索到的SLP。 2. SET发送SUPL START命令给SLP，该命令携带了一些参数，包括locationId（如果使用移动通信网络，则该参数包括基站的Cell Info。如果使用Wi-Fi，则该参数包括AP的信息）、sETCapablilities（SET的能力，如支持的定位数据封装协议、支持的定位方法等，详情可参考表9-7）。 3. SLP回复SUPL RESPONSE命令给SET。RESPONSE命令包含了SLP支持的定位方法（由posMethod表示），以及SLP支持的定位能力（由sLPCapabilities描述）。 4. SET发送SUPL POS INIT命令给SLP，该命令包含了SET的初始位置等信息。 5. 接着，SET和SLP通过一个或多个SUPL POS消息来计算位置。根据AGPS使用的模式（MSB或MSA），位置的计算方法也不尽相同。 6. 当位置计算完毕后，SLP发送SUPL END命令给SET，二者随后断开TLS链接。 >[info] 提示　关于ULP各消息所包含的参数信息，请读者自行阅读参考资料[28]。 **②、Network Initiated ULP工作流程** 图9-28所示为Network Initiated（NI）ULP的工作流程图。 :-:  图9-28　Network Initiated ULP流程 图9-28中，由于SUPL Agent位于SUPL Network，所以它和SLP的交互遵守MLP（Mobile Location Protocol）。SLP收到SUPL Agent的SLIR（Standard Location Immediate Request）请求后，它将发送SUPL INIT命令给SET。此处需强调，如果SET和SLP此时还没有建立数据链接，SUPL INIT将通过OMA Push消息或数据短信等方式发送给SET，SET收到SUPL INIT命令后将和SLP 建立数据链接。 此后，SLP和SET之间的交互与图9-27类似。SLP最终通过SLIA（Standard Location Immediate Answer）将定位信息发送给SUPL Agent。 >[info] 提示　此处不再详述ULP的细节，请读者自行阅读参考资料[28]。 至此，本章所涉及的GPS相关基础知识就全部介绍完毕。相信读者能感觉到这些内容背后的专业知识是多么庞大和复杂。在此，希望立志成为GPS专家的读者继续保持谦虚的态度，认真学习，争取为中国的北斗导航系统添砖加瓦。 >[info] 提示　本节所述内容能覆盖Android GPS相关模块（不含驱动及芯片底层模块）代码中80%左右的背景知识。 ①　OMA-SUPL中有大量的缩写词汇，请读者阅读时务必注意它们的全称。 ②　规范中的定义是"A Software and/or hardware entity accessing the SUPL enabler in order to obtain location information"。 ③　读者可将其理解为一个帮助定位的系统，规范中的定义是"Access network which facilitates the location determination functionality and provides the SUPL bearer"。 ④　此处讨论仅针对OMA SUPL ULP规范中的Immediate Service。