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。