AGPS服務器子系統的設計與實現＊

俞杭華，張 皓

（1.上海衛星工程研究所，上海200240；2.上海市東凌公司，上海200082）

0 引 言

網絡輔助全球定位系統（AGPS）輔助定位信息主要包括衛星的偽距信息和多普勒頻偏等，利用這些信息可以大大縮短GPS終端的首次定位時間、提高靈敏度，解決目前GPS定位存在的室內定位困難和首次定位時間過長問題。

目前，國內移動通信市場日益發展，特別是隨著3G技術的商用，中國移動和中國聯通制訂和推出了各自的AGPS方案[1]。設計實現了一個有基本功能的AGPS服務器子系統，用于AGPS終端的開發研制。

1 AGPS服務器的需求分析

1.1 功能概述

網絡輔助全球定位系統（AGPS）概念是在1981年被提出來的，AGPS服務器子系統通過參考接收機實時獲取GPS衛星信息，處理并生成輔助定位信息，通過無線通信網絡或互聯網，將輔助定位信息發送給GPS用戶終端。AGPS定位過程如圖1所示[2－4]。

圖1 AGPS工作原理

AGPS服務器是系統實現輔助信息處理的平臺，根據AGPS定位原理，服務器子系統需要實現三大功能：衛星信息實時獲取；信息存儲、管理；輔助數據有線及無線傳輸。

設計的服務器子系統通過參考接收機實時獲取衛星信息，借助GSM／GPRS等無線網絡，采用無線通信的方式將有用數據發送到移動終端，從而輔助終端實現室內定位或快速定位。

1.2 外部接口

AGPS服務器與終端芯片之間的組網方式有三種：1）服務器與終端芯片通過RS232直連，如圖2（a）所示；2）服務器與終端通過以太網互聯，如圖2（b）所示；3）服務器連接至以太網，終端通過通信模塊連接至GSM／GPRS無線網絡，如圖2（c）所示[5－6]。對服務器的軟件實現而言，在組網方式2、3下實現無線通信的方法是相同的。

圖2 組網方式

根據上述組網方式，輔助定位服務器子系統提供三類接口：與參考接收機通信的串行接口；與終端通信的串行接口（內部調試階段）；鏈入通信網絡并與GPRS模塊進行無線通信的RJ45接口。如圖3所示。表1示出了三類接口的基本信息。

圖3 AGPS服務器接口

表1 AGPS服務器接口信息

1.3 數據格式

1.3.1 與參考接收機通信的數據格式

參考接收機采用THALES公司的DG16，參考其datasheet，從中挑選出所需的數據幀，分別為XYZ、SNV、PBN、MCM。通過串行端口向其發送相關命令，參考接收機會通過串口返回相應信息，具體的命令格式和返回主要信息如表2所示[7]。

表2 與參考接收機通信數據

1.3.2 與接收機終端芯片間通信的數據格式

接收機終端采用ARM9芯片。參考3GPP及OMA制定的相關協議[8]，采取面向連接的socket通訊方式用于服務器子系統與終端間的通信。接收機終端與中心系統的通信協議是不定長格式，所有的信息都采用十六進制數表示，編碼采用二進制編碼方式。

服務器子系統與終端芯片間的通信信號包括通訊幀、授時幀和輔助信息幀等。以服務器子系統向終端發送的輔助信息幀為例給出數據格式的設計，如表3所示。

表3 輔助信息幀格式

表4 輔助信息數據幀信息內容

1.4 服務器模塊

根據服務器的功能需求，將服務器分為三個模塊開展設計，分別是衛星信息實時獲取模塊，信息存儲與管理模塊和輔助信息線傳輸模塊。

衛星信息實時獲取模塊以某固定時間間隔（10 min）從DG16獲取星歷數據，并通過提高參考接收機數據更新速率（10Hz）和串行通信波特率（115 200b／s）等參數，縮短獲取星歷信息的時間至最短（約1.3s）。與此同時，以更短時間間隔（1s）循環獲取除星歷以外的其它衛星信息。

信息存儲與管理模塊通過建立小型數據庫保存約半個小時左右的星歷數據以及其它衛星信息數據。確保每次有終端請求時均有較及時信息。系統記錄每一次服務器與客戶端通信的時間、傳輸的數據內容，并以文件形式將這些信息保存在本地磁盤。

輔助信息無限傳輸模塊以“請求—應答”方式無線傳輸輔助信息至終端，遵循TCP／IP協議?？赡M演示廣播方式的點到多點通信，即：服務器每秒向已建立連接的多個終端發送輔助信息。輔助信息長度169＊N＋38Byte（N為衛星數），數據傳輸速率約21.4Kb／s，網絡時延小于3s.

2 輔助定位服務器方案設計

服務器初始方案采用收到輔助請求→獲取輔助數據→數據重組→發送輔助信息的思路，就是收到終端請求之后向參考接收機發命令拿數據，再將經過重組后的數據發送給請求的終端。具體實現流程如圖4所示。

試驗驗證發現：初始方案中對衛星信息的采集過程有著嚴重缺陷，當連續收到輔助請求時，會產生因采集混亂而導致的嚴重死機現象，并且致使不能連接多個客戶端。

圖4 初始方案工作流程

針對初始方案中出現的問題，發現需要改變取數據的流程才能解決，因此，重新設計了整體流程。輔助定位服務器啟動以后，與參考接收機DG16通過串口建立連接，向參考接收機循環發送SNV，XYZ，PBN，MCM請求，從而獲得最新的輔助數據。服務器接收到數據之后不斷進行輔助數據的提取并組合成最新的輔助信息，以備接收機請求。當收到某客戶端接收機請求之后，服務器提取最新的輔助信息發送給客戶端接收機。如果有多個客戶端接入并請求，服務器則順序依次處理收到的請求。詳細工作流程如圖5所示。

圖5 改進方案工作流程

試驗證明改進方案是可行的，并且完全解決了死機現象和不能連接多個客戶端的問題。

3 改進方案的軟件實現

3.1 軟件功能結構

輔助定位服務器軟件的功能結構如圖6所示，分為輔助數據獲取，輔助信息組成，輔助請求響應三個子模塊。

圖6 AGPS服務器軟件的功能結構

3.2 socket套接字

本軟件系統實現IP通信的關鍵是建立Socket，為保證輔助信息可靠傳輸，在“請求／應答”方式下采用基于TCP協議的流式套接字技術進行通信。圖7和圖8分別示出了流式Socket工作流程及建立步驟。

3.3 服務器子模塊的設計與實現

圖9示出了服務器子模塊的的詳細劃分。

3.3.1 輔助數據獲取模塊

本模塊功能為向參考接收機發送命令，從而獲取參考接收機的各個輔助數據幀。設計過程中，針對主要的五個重點分別采用了以下方法

1）針對串口通訊，采用了一個串口控件（控件名：serialPort1）實現。

2）針對命令的定時順序循環發送，采用了兩個定時器控件（控件名：timer1，timer2）實現，其中timer1間隔為60s，觸發發送SNV命令的方法；timer2間隔為1s，按順序觸發發送XYZ，PBN，MCM命令的方法。

3）針對數據的接收，采用了建立線程的方法（線程名：threadReceive），在開串口之后立即啟動該線程，實現數據收發。

4）針對數據截取，用了兩次判斷。第一次判斷讀入數據尾是否為“＼r＼n”（對 SNV，XYZ，PBN），或是否其首字符為“M”且長度符合MACM數據幀定義中的長度（對MCM）。當初次判斷通過時進行第二次判斷。第二次判斷讀入數據的頭，是＄PASHQ，SNV；＄PASHQ，XYZ；＄PASHQ，PBN時則其本次讀入的數據分別為SNV，XYZ，PBN，為MACM時，則本次讀入的數據為 MCM.再進行數據長度的判斷從而截取有用數據，截取成功后分別放入相應的4個列表：listXYZ，listSNV，listPBN，listMCM。

5）針對線程的沖突，由于線程的沖突會造成數據錯誤，因此一定要對線程進行處理，此處采用的方法是使用互斥體Mutex類。在讀取數據之后，數據處理之前，先判斷是否有已被創建的Mutex，如果沒有，則進行數據處理，否則等待該Mutex被釋放。具體的實現流程如圖10所示。

圖10 輔助數據獲取模塊詳細流程圖

3.3.2 輔助信息組成模塊

本部分實現發送數據幀的整合。數據經輔助數據獲取模塊處理之后形成了4個列表，本模塊的任務就是將4個列表中有用的數據重新組合成一個可以發送給終端進行定位的數據幀。表5示出了數據重組的方式。

表5 數據重組信息列表

本部分的實現是逐一將數據放入數組的過程，采用新建一個類來實現。流程如圖11所示。

圖11 輔助數據組成模塊詳細流程圖

3.3.3 輔助請求響應模塊

本部分實現對終端發送的輔助請求的響應。之前的兩個模塊完成了數據的獲得和組合，但作為輔助定位服務器，最關鍵的任務是將輔助信息順利轉交給需要輔助的終端。

本部分實現主要包含以下幾個環節

1）使用TcpListener類完成對客戶端的偵聽，并采用創建偵聽線程threadListen使能夠完成持續偵聽。

2）使用Socket類來創建與客戶端的連接，從而可以不必區分有線連接或無線連接。

3）使用了互斥體Mutex來防止與接收線程threadReceive的沖突。

4）利用創建的方法log＿Write進行收發時間和數據的文件存檔，并以時間和IP地址及端口號作為文件名。

5）由于多個客戶端存在的可能性以及單個客戶端持續請求輔助的可能性，采用了發送線程threadSend，從而保證了發送的不間斷。

圖12示出了該模塊的詳細流程。

圖12 輔助請求響應模塊詳細流程圖

4 測試方案及結果

服務器軟件設計完成之后，進行了初步調試，穩定性測試及可靠性測試。測試主要工具是自主編寫的測試程序test1.exe.測試連接圖如圖13所示。

圖13 服務器測試連接示意圖

4.1 初步調試

初步調試主要解決初始方案中的兩個問題：1）長時間工作測試的死機現象；2）不能實現多個客戶端數據的共同收發。

針對死機現象主要采取連接單個客戶端，進行長時間工作，測試是否有死機現象出現。使用測試程序test1.exe進行測試，發送輔助數據間隔設置為6s，測試200次，沒有死機現象出現。

針對連接多個客戶端問題采用連接兩個客戶端，測試是否可以實現兩個客戶端數據的共同收發，測試數據是否正確。在兩臺機器上安裝test1.exe測試軟件，同時連接服務器并以6s的時間間隔發送輔助請求。結果表明服務器可以正常接收輔助請求，并可以按照次序進行輔助信息的發送。

4.2 穩定性測試

作為一個提供數據的中心，輔助定位服務器的穩定性相當重要，因此，設計編寫了一個穩定性測試軟件，從而可以在完善該軟件的同時進行服務器的穩定性測試。主要測試項目有：

1）多個客戶端：在多個客戶端安裝穩定性測試軟件，進行長時間測試，驗證服務器是否可以正常工作，是否可以完整發送數據。

2）多種發送間隔：測試軟件的默認值為6s，可以設置多種發送間隔，進行長時間測試，驗證服務器是否可以正常工作，是否可以完整發送數據。

測試結果表明：分別給服務器連接3個、4個至7個客戶端，服務器可以長時間正常工作；分別采用4s～10s的多個發送間隔，每種時間間隔測試500次左右，未出現異常。

4.3 可靠性測試

由于精確定位的需要，服務器需提供精確的定位輔助信息，才能保證終端的正確定位。因此服務器的可靠性十分重要的。使用接收機進行測試，通過比對定位結果進行可靠性測試。測試結果表明服務器發送的輔助數據完整且數據正確。

5 結 論

從AGPS的定位原理和相關協議出發，結合課題實際，設計實現了一個用于AGPS終端開發的輔助定位服務器，同時還設計了測試軟件對服務器的功能、穩定性和可靠性進行了測試驗證，表明了該輔助定位服務器系統工作穩定、可靠，數據格式的確定以及軟件方案的實現可以順利響應終端接收機的定位輔助請求。完成一個可以真正投入商業應用的AGPS服務器還需要更進一步研究。

[1]中國移動通信集團公司研究院.AGPS終端測試規范[R].2006.

[2]張守信.GPS技術與應用[M].北京：國防工業出版社，2004.

[3]劉基余.GPS衛星導航定位原理與方法[M].北京：科學出版社，2006.

[4]張 昊，廖建新，張彥翔，等.安全用戶平面AGPS移動定位平臺的設計與實現[M].北京：現代電信科技，2006.

[5]中國移動通信有限公司.高精度位置業務（AGPS）試點方案[R].2006.

[6]張 昊.移動定位平臺和位置管理關鍵技術研究[D].北京：北京郵電大學，2006.

[7]John，周 靖.Visual C＃2005從入門到精通[M].北京：清華大學出版社，2006.

[8]MICKEY W.Visual C＃ NET技術內幕[M].冉小旻，羅 鄧，郭 炎，譯.修訂版.北京：清華大學出版社，2007.