周玉霞,周 明,康登榜,黃小紅

(1.中國航天標(biāo)準(zhǔn)化研究所,北京 100071;2.清華大學(xué)網(wǎng)絡(luò)科學(xué)與網(wǎng)絡(luò)空間研究院,北京 100086; 3.北京郵電大學(xué)網(wǎng)絡(luò)技術(shù)研究院,北京 100876)

GNSS互聯(lián)網(wǎng)數(shù)據(jù)傳輸協(xié)議標(biāo)準(zhǔn)綜述

周玉霞1,周 明2,康登榜1,黃小紅3

(1.中國航天標(biāo)準(zhǔn)化研究所,北京 100071;2.清華大學(xué)網(wǎng)絡(luò)科學(xué)與網(wǎng)絡(luò)空間研究院,北京 100086; 3.北京郵電大學(xué)網(wǎng)絡(luò)技術(shù)研究院,北京 100876)

隨著衛(wèi)星導(dǎo)航增強(qiáng)技術(shù)的不斷發(fā)展和廣泛應(yīng)用,如何利用成熟的互聯(lián)網(wǎng)技術(shù)傳輸和播發(fā)衛(wèi)星導(dǎo)航增強(qiáng)信息成為了新的熱門領(lǐng)域,而對相關(guān)協(xié)議標(biāo)準(zhǔn)的研究分析也成為人們關(guān)注的重點。本文通過分析當(dāng)前互聯(lián)網(wǎng)傳輸衛(wèi)星導(dǎo)航增強(qiáng)信息的通信協(xié)議現(xiàn)狀,選擇以廣泛應(yīng)用的Ntrip協(xié)議作為重點研究對象,描述了衛(wèi)星導(dǎo)航增強(qiáng)信息數(shù)據(jù)互聯(lián)網(wǎng)播發(fā)的網(wǎng)絡(luò)架構(gòu),提出了GNSS互聯(lián)網(wǎng)播發(fā)的4個網(wǎng)絡(luò)實體,并詳細(xì)論述了網(wǎng)絡(luò)實體之間采用的超文本傳輸通訊協(xié)議HTTP、實時流傳輸協(xié)議RTSP、簡單實時傳輸協(xié)議RTP的三種通用接口協(xié)議。

RTK;GNSS;Ntrip;衛(wèi)星導(dǎo)航增強(qiáng)信息;傳輸協(xié)議

0 概述

隨著北斗衛(wèi)星導(dǎo)航系統(tǒng)(BeiDou navigation satellite system,BDS)信號覆蓋亞太地區(qū),我國民用導(dǎo)航應(yīng)用發(fā)展迅速,越來越多的行業(yè)和領(lǐng)域需要高精度位置服務(wù)。利用多個基站的網(wǎng)絡(luò)實時動態(tài)測量(real time kinematic,RTK)技術(shù)建立的連續(xù)運(yùn)行參考站系統(tǒng)(continuous operational reference system,CORS)已成為衛(wèi)星導(dǎo)航定位增強(qiáng)系統(tǒng)的主要方案之一。

網(wǎng)絡(luò)RTK技術(shù)在區(qū)域內(nèi)布設(shè)多個永久性連續(xù)運(yùn)行參考站,根據(jù)各參考站的精確坐標(biāo)信息,實時生成電離層、對流層、軌道等誤差的導(dǎo)航修正數(shù)據(jù),通過互聯(lián)網(wǎng)方式發(fā)送到主控中心,由主控中心通過互聯(lián)網(wǎng)或者衛(wèi)星通信向用戶實時連續(xù)播發(fā),用戶端可獲得高精度實時導(dǎo)航數(shù)據(jù)信息。本文主要研究網(wǎng)絡(luò)RTK基于互聯(lián)網(wǎng)方式傳播衛(wèi)星導(dǎo)航數(shù)據(jù)所使用的傳輸協(xié)議標(biāo)準(zhǔn)。

1 國內(nèi)外發(fā)展

由于互聯(lián)網(wǎng)傳輸所具有的優(yōu)越性和潛在的巨大商機(jī),歐美已在此領(lǐng)域進(jìn)行了大量的研究、開發(fā)和應(yīng)用示范。歐洲空間局(European Space Agency,ESA)研究通過互聯(lián)網(wǎng)傳輸衛(wèi)星導(dǎo)航增強(qiáng)信息的SISNe T(signal in space through internet)項目[1],能夠為歐洲用戶提供輔助測距、全球定位系統(tǒng)(global positioning system,GPS)和格洛納斯衛(wèi)星導(dǎo)航系統(tǒng)(global navigation satellite system, GLONASS)廣域差分信息以及完好性信息服務(wù)。美國海事無線電技術(shù)委員會(Radio Technical Committee for Maritime Services,RTCM)研究制定了互聯(lián)網(wǎng)進(jìn)行RTCM網(wǎng)絡(luò)傳輸協(xié)議(networked transportof rtcm via internet protocol,Ntrip)[2]。此外,日本多功能衛(wèi)星增強(qiáng)系統(tǒng)(multi-functional satellite augmentation system,MSAS)衛(wèi)星導(dǎo)航定位增強(qiáng)系統(tǒng)已經(jīng)建成并廣泛使用,印度的靜地軌道增強(qiáng)導(dǎo)航系統(tǒng)(GPS aided GEO augmented navigation,GAGAN)的衛(wèi)星導(dǎo)航定位增強(qiáng)系統(tǒng)正在建設(shè)中[4],我國目前衛(wèi)星導(dǎo)航廣域增強(qiáng)系統(tǒng)的建設(shè)工作已經(jīng)啟動并取得重大進(jìn)展。

基于CORS站的衛(wèi)星導(dǎo)航定位增強(qiáng)系統(tǒng)廣泛應(yīng)用于各行各業(yè),用戶數(shù)量不斷增加,需要從參考定位站的網(wǎng)絡(luò)控制中心發(fā)送大量數(shù)據(jù)至廣大的用戶,因此需要在互聯(lián)網(wǎng)的基礎(chǔ)上建立覆蓋網(wǎng)絡(luò)來傳輸這些數(shù)據(jù)。目前支持通過網(wǎng)絡(luò)播發(fā)導(dǎo)航增強(qiáng)信息的傳輸協(xié)議主要有:

(1)SISNe T是歐洲地球同步衛(wèi)星導(dǎo)航覆蓋服務(wù)系統(tǒng)(European geostationary navigation overlay service,EGNOS)于2006年制定的基于互聯(lián)網(wǎng)的衛(wèi)星導(dǎo)航增強(qiáng)系統(tǒng)。它采用傳輸控制協(xié)議(transfer control protocol,TCP),定義了3類傳輸數(shù)據(jù),分別為用戶端到數(shù)據(jù)服務(wù)器的請求消息、數(shù)據(jù)服務(wù)器到用戶端的應(yīng)答消息、數(shù)據(jù)服務(wù)器到用戶端的事件觸發(fā)消息。SISNe T可選擇使用壓縮算法來提高通信速度,降低數(shù)據(jù)延遲時間。但是SISNet系統(tǒng)采用了客戶機(jī)/服務(wù)器(client/server,C/S)架構(gòu)的私有協(xié)議來定義衛(wèi)星導(dǎo)航增強(qiáng)信息數(shù)據(jù)的播發(fā)機(jī)制,這種設(shè)計增加了客戶端的開發(fā)工作量,不利于在移動終端的普及工作。

(2)Ntrip協(xié)議是國際海事無線電技術(shù)委員會制定的衛(wèi)星增強(qiáng)信息的應(yīng)用層通信協(xié)議,是虛擬參考站(virtual reference stations,VRS)進(jìn)行數(shù)據(jù)傳輸所采用的標(biāo)準(zhǔn)協(xié)議,它是一個開放的,非私有的協(xié)議,適合于通過互聯(lián)網(wǎng)傳輸全球衛(wèi)星導(dǎo)航系統(tǒng)(global navigation satellite system,GNSS)數(shù)據(jù)流及差分?jǐn)?shù)據(jù)信息,允許電腦、掌上電腦(personal digital assistant,PDA)和接收機(jī)連接到數(shù)據(jù)處理中心;支持通過移動通信進(jìn)行互聯(lián)網(wǎng)訪問。Ntrip協(xié)議基于文本傳輸通訊協(xié)議(hypertext transfer protocol,HTTP)及TCP協(xié)議,目前在歐洲、亞洲和美國的CORS站上已經(jīng)得到廣泛的應(yīng)用,最新版本為2011年發(fā)布的2.0版本(RTCM 10410.1)[2]。Ntrip2.0修改了1.0版本存在的與HTTP協(xié)議不兼容的部分,加入了塊傳輸編碼,支持HTTP[4]、實時流傳輸協(xié)議(real time streaming protocol,RTSP)[5]、簡單實時傳輸協(xié)議(real time transport protocol,RTP)[6]三種通信協(xié)議。

(3)RT-IGS[7]是由國際GNSS服務(wù)(international GNSS service,IGS)實時工作組開發(fā)制定的一種新的數(shù)據(jù)傳輸協(xié)議,它規(guī)定了4種傳輸數(shù)據(jù),并對四種數(shù)據(jù)傳輸頻率進(jìn)行約定。它與Ntrip協(xié)議不同,其為考慮通過網(wǎng)絡(luò)傳輸更好的實時性能,采用的是用戶數(shù)據(jù)報協(xié)議(user datagram protocol, UDP)。2008年IGS加入RTCM-SC104,采用RTCM-3.0作為GPS和GLONASS觀測消息標(biāo)準(zhǔn),采用RTCM狀態(tài)空間表達(dá)式(state space representation,RTCM-SSR)作為軌道和時鐘的修正消息的標(biāo)準(zhǔn)。

從歷史和現(xiàn)狀來看,SISNet采用C/S架構(gòu)的私有協(xié)議方式很難成為通用的標(biāo)準(zhǔn),RT-IGS已經(jīng)向Ntrip方式逐漸融合,因此Ntrip協(xié)議已經(jīng)成為廣泛采用的網(wǎng)絡(luò)RTK傳輸協(xié)議標(biāo)準(zhǔn)。本文研究的衛(wèi)星導(dǎo)航增強(qiáng)信息互聯(lián)網(wǎng)數(shù)據(jù)傳輸協(xié)議,在兼容Ntrip2.0協(xié)議(RTCM 10410.1)的基礎(chǔ)上,考慮我國衛(wèi)星導(dǎo)航技術(shù)發(fā)展和實際應(yīng)用情況,做出了部分修改。

2 系統(tǒng)結(jié)構(gòu)

衛(wèi)星導(dǎo)航增強(qiáng)信息數(shù)據(jù)互聯(lián)網(wǎng)播發(fā)的網(wǎng)絡(luò)架構(gòu)如圖1所示,包括數(shù)據(jù)源、數(shù)據(jù)服務(wù)器、播發(fā)服務(wù)器、用戶節(jié)點四部分網(wǎng)絡(luò)實體。數(shù)據(jù)源與數(shù)據(jù)服務(wù)器連接,為其提供增強(qiáng)信息原始數(shù)據(jù)流信息。數(shù)據(jù)服務(wù)器獲取原始數(shù)據(jù)并進(jìn)行計算處理,對播發(fā)服務(wù)器發(fā)送處理后的數(shù)據(jù)。播發(fā)服務(wù)器接收數(shù)據(jù)服務(wù)器發(fā)送的衛(wèi)星導(dǎo)航增強(qiáng)信息數(shù)據(jù),同時接受用戶請求,將數(shù)據(jù)源信息表及增強(qiáng)信息數(shù)據(jù)發(fā)送給用戶節(jié)點。用戶節(jié)點向播發(fā)服務(wù)器請求獲取數(shù)據(jù)源信息表以及衛(wèi)星導(dǎo)航增強(qiáng)信息數(shù)據(jù)。

圖1 網(wǎng)絡(luò)實體拓?fù)浣Y(jié)構(gòu)

2.1 數(shù)據(jù)源

數(shù)據(jù)源對應(yīng)Ntrip協(xié)議的NtripSource為系統(tǒng)中的數(shù)據(jù)來源部分,提供類似流媒體數(shù)據(jù)的連續(xù)GNSS數(shù)據(jù)(例如RTCM-104定義的修正值)。為區(qū)分?jǐn)?shù)據(jù)的來源,數(shù)據(jù)源具有唯一的標(biāo)識(identification,ID),對應(yīng)播發(fā)服務(wù)器中定義的掛載點。

2.2 數(shù)據(jù)服務(wù)器

數(shù)據(jù)服務(wù)器對應(yīng)Ntrip協(xié)議的NtripServer,用于將數(shù)據(jù)源的GNSS數(shù)據(jù)傳送到播發(fā)服務(wù)器。

對應(yīng)數(shù)據(jù)源標(biāo)識的數(shù)據(jù)服務(wù)器掛載點由播發(fā)服務(wù)器定義并交付給數(shù)據(jù)服務(wù)器配置。數(shù)據(jù)服務(wù)器上運(yùn)行的服務(wù)程序其功能是將處理后的數(shù)據(jù)源增強(qiáng)信息發(fā)送到播發(fā)服務(wù)器,具體數(shù)據(jù)源增強(qiáng)信息數(shù)據(jù)可以是RTCM等協(xié)議數(shù)據(jù)。數(shù)據(jù)服務(wù)器要求可支持虛擬參考站,對產(chǎn)生的增強(qiáng)信息的虛擬參考站可表示為單個數(shù)據(jù)源。

2.3 播發(fā)服務(wù)器

播發(fā)服務(wù)器對應(yīng)Ntrip協(xié)議的NtripCaster。播發(fā)服務(wù)器是系統(tǒng)的核心服務(wù)器,它通過一個監(jiān)聽端口接收數(shù)據(jù)服務(wù)器或用戶節(jié)點發(fā)來的請求消息。根據(jù)收到的這些消息,播發(fā)服務(wù)器判斷是否需要接收數(shù)據(jù)服務(wù)器的增強(qiáng)信息或向用戶節(jié)點發(fā)送增強(qiáng)信息。

2.4 用戶節(jié)點

用戶節(jié)點對應(yīng)Ntrip協(xié)議的NtripClient。用戶節(jié)點向播發(fā)服務(wù)器發(fā)送正確的請求后,可接收播發(fā)服務(wù)器發(fā)送的信息。用戶節(jié)點通過訪問播發(fā)服務(wù)器獲得源信息表,源信息表中的數(shù)據(jù)源描述參數(shù)定義了使用的數(shù)據(jù)格式、掛載點、位置坐標(biāo)和其它信息。用戶節(jié)點選擇源信息表中的數(shù)據(jù)源掛載點,可收到GNSS數(shù)據(jù)。用戶節(jié)點到播發(fā)服務(wù)器的消息格式和狀態(tài)代碼兼容HTTP1.1,可采用基于HTTP、RTSP、簡單RTP的三種通用協(xié)議。

3 系統(tǒng)接口要求

數(shù)據(jù)源、數(shù)據(jù)服務(wù)器、播發(fā)服務(wù)器、用戶節(jié)點之間的接口可根據(jù)實際需要采用基于HTTP、RTSP、簡單RTP的三種通用協(xié)議。由于當(dāng)前大部分終端都已經(jīng)支持HTTP協(xié)議,因此可以顯著地簡化終端的開發(fā)周期。基于HTTP協(xié)議適合用戶節(jié)點單次請求GNSS數(shù)據(jù),基于RTSP協(xié)議適用于用戶節(jié)點連續(xù)請求數(shù)據(jù)的場景。為有效降低消息傳輸?shù)臅r延,針對實時性要求較高的用戶提供服務(wù),Ntrip2.0版本提出基于UDP協(xié)議的簡單RTP應(yīng)用層協(xié)議。RTP協(xié)議在互聯(lián)網(wǎng)上提供端到端的實時信息傳輸,但并不保證服務(wù)質(zhì)量。下面簡單介紹HTTP、RTSP、簡單RTP三種接口協(xié)議的格式、意義和特點。

3.1 基于HTTP的接口

Ntrip基于HTTP1.1協(xié)議實現(xiàn)了一種通用的、無狀態(tài)的信息傳輸方式,所有的數(shù)據(jù)傳輸都是使用TCP連接,并默認(rèn)使用數(shù)據(jù)壓縮格式RTCM3.x協(xié)議進(jìn)行增強(qiáng)信息數(shù)據(jù)傳輸。用戶可以通過各種終端,例如筆記本電腦、手機(jī)或特定的接收機(jī)等方式接入到網(wǎng)絡(luò)中,從而獲得導(dǎo)航增強(qiáng)信息。

接口采用基于HTTP/TCP的通信方式,由用戶節(jié)點或數(shù)據(jù)服務(wù)器發(fā)起請求,由播發(fā)服務(wù)器應(yīng)答。請求響應(yīng)通信的基本結(jié)構(gòu)分別如圖2、圖3所示。每個請求由一個或多個headerline,序列 是字符為0x D和是0x A的序列,并且是HTTP通信標(biāo)準(zhǔn)的行終止符。REQUESTCOMMAND為請求命令的關(guān)鍵字見表1,CODE為響應(yīng)消息的代碼見表2。

圖2 用戶節(jié)點或數(shù)據(jù)服務(wù)器請求

圖3 播發(fā)服務(wù)器響應(yīng)

表1 請求格式及意義

表2 代碼及其意義

3.1.1 用戶節(jié)點與播發(fā)服務(wù)器之間的通信

用戶節(jié)點與播發(fā)服務(wù)器之間的通信主要包括:

(1)用戶節(jié)點向播發(fā)服務(wù)器請求源信息表或包含過濾條件的源信息表;

(2)播發(fā)服務(wù)器向用戶節(jié)點發(fā)送源信息表;

(3)用戶節(jié)點向播發(fā)服務(wù)器請求增強(qiáng)信息數(shù)據(jù),請求信息包含指定的掛載點、用戶名、密碼等;

(4)播發(fā)服務(wù)器向用戶節(jié)點發(fā)送增強(qiáng)信息;

(5)播發(fā)服務(wù)器處理錯誤狀態(tài)、錯誤請求等。

3.1.2 數(shù)據(jù)服務(wù)器與播發(fā)服務(wù)器之間的通信

數(shù)據(jù)服務(wù)器只有上傳GNSS數(shù)據(jù)到播發(fā)服務(wù)器的功能,所有連接都是由數(shù)據(jù)服務(wù)器發(fā)出請求,由播發(fā)服務(wù)器做出響應(yīng)。請求和響應(yīng)完成之后,數(shù)據(jù)服務(wù)器將GNSS數(shù)據(jù)傳輸?shù)讲グl(fā)服務(wù)器。

3.2 基于RTSP的接口

RTSP協(xié)議采用TCP控制連接和使用UDP傳輸數(shù)據(jù)的混合通信方式。具體要求參見RTSP (RFC2326)和RTP(RFC3550),其協(xié)議功能如下:

(1)RTSP控制連接,用于計費(fèi)和檢測傳輸結(jié)束;

(2)RTSP協(xié)議與基于TCP連接的HTTP協(xié)議兼容;

(3)RTP可以檢測和糾正亂序的數(shù)據(jù)包;

(4)RTP可以檢測丟失的數(shù)據(jù);

(5)請求源信息表使用普通的HTTP請求;

(6)播發(fā)服務(wù)器只支持持久的RTSP連接。

用戶節(jié)點與播發(fā)服務(wù)器之間通信的RTSP連接控制包括建立連接、開始傳輸和結(jié)束傳輸三個階段如表3所示。RTSP使用SETUP消息啟動RTSP連接,讓服務(wù)器給流分配資源;隨后的PLAY消息,啟動數(shù)據(jù)流傳輸;使用TEARDOWN消息釋放數(shù)據(jù)流資源,結(jié)束RTSP連接。

表3 請求格式及意義

數(shù)據(jù)服務(wù)器與播發(fā)服務(wù)器之間建立連接和結(jié)束傳輸與用戶節(jié)點與播發(fā)服務(wù)器之間的通信方式相同,區(qū)別為其中的“Ntrip-Component”必須設(shè)置為“Ntripserver”。

RTP數(shù)據(jù)傳輸啟動后,由于RTSP協(xié)議本身很長一段時間不傳輸數(shù)據(jù),需要使用GET_PARAMETER請求來告訴通訊雙方連接還處于Keep-Alive狀態(tài),該請求始終由數(shù)據(jù)服務(wù)器或用戶節(jié)點發(fā)出,定期發(fā)送到播發(fā)服務(wù)器。

基于RTP接口要求的RTP數(shù)據(jù)流,每個數(shù)據(jù)塊的頭部由12個字節(jié)組成,其格式如圖4所示。

圖4 RTP數(shù)據(jù)塊頭部

每個字段的值如表4所示。目前使用的字段為載荷類型(payload type,PT)和同步源標(biāo)識(synchronisation source identifier,SSRC),其它字段的定義參見RFC3550。

表4 RTP頭部格式及其意義

RTP數(shù)據(jù)連接是由服務(wù)器發(fā)起,可能會被防火墻阻塞。為避免阻塞,需要從本地網(wǎng)絡(luò)的RTP客戶端使用其UDP端口發(fā)送一個初始的UDP包。此數(shù)據(jù)包是沒有附加的數(shù)據(jù)的正常RTP數(shù)據(jù)包,相當(dāng)于RTP協(xié)議的“keep alive”數(shù)據(jù)包。

3.3 基于RTP的接口

Ntrip2.0版本支持基于UDP協(xié)議的簡單RTP應(yīng)用層協(xié)議。RTP協(xié)議主要用于為IP網(wǎng)上的語音、圖像、傳真等多種需要實時傳輸?shù)亩嗝襟w數(shù)據(jù)提供端到端的實時傳輸服務(wù)。RTP實現(xiàn)了互聯(lián)網(wǎng)上端到端的實時傳輸并提供時間信息和流同步,但它不能保證服務(wù)質(zhì)量。Ntrip定義的簡單RTP協(xié)議可以有效降低消息傳輸?shù)臅r延,為實時性要求較高的用戶提供了一種服務(wù)選擇。

簡單RTP協(xié)議使用一種不同的UDP通信方法,它是基于HTTP協(xié)議和RTP通信的組合。在“Ntrip-Flags”中包含對“plain_rtp”的支持。協(xié)議支持的負(fù)載類型見表5:

UDP協(xié)議沒有連接控制,因此在通信中丟失的數(shù)據(jù)包、亂序數(shù)據(jù)包和冗余數(shù)據(jù)包必須由應(yīng)用程序做相應(yīng)的處理?；诤唵蜶TP的連接控制包括建立連接、開始傳輸和結(jié)束傳輸三個階段。

為了建立數(shù)據(jù)服務(wù)器或用戶節(jié)點到播發(fā)服務(wù)器的連接,客戶端發(fā)送一個RTP包到播發(fā)服務(wù)器的UDP端口。播發(fā)服務(wù)器在該端口監(jiān)聽數(shù)據(jù)包。該包的SSRC可以自由選擇,而“payload type”需要設(shè)置為97而不是96,包的數(shù)據(jù)部分的HTTP請求與4.1節(jié)定義相同。

播發(fā)服務(wù)器使用載荷類型為97的應(yīng)答請求, 其SSRC與請求RTP包相同。從播發(fā)服務(wù)器發(fā)送的數(shù)據(jù)部分包含一個標(biāo)準(zhǔn)的HTTP響應(yīng),如果這個header值與使用的SSRC不同,那么任何后續(xù)的通信的SSRC必須使用新的會話號。由于RTP包的大小限制,需要限制使用header的數(shù)量以防止超長。如果30秒沒有發(fā)送數(shù)據(jù)包,建議發(fā)送一個Keep-Alive包。

如果關(guān)閉連接,系統(tǒng)實體應(yīng)發(fā)送載荷類型為98的沒有附加數(shù)據(jù)的RTP數(shù)據(jù)包。如果系統(tǒng)實體收到這樣的數(shù)據(jù)包或1分鐘沒有收到數(shù)據(jù)包,該連接正常關(guān)閉。

3.4 源信息表

播發(fā)服務(wù)器維護(hù)一個包含可用的數(shù)據(jù)源、數(shù)據(jù)源網(wǎng)絡(luò)及播發(fā)服務(wù)器信息的源信息表,用于收到用戶請求時發(fā)送至用戶節(jié)點。用戶節(jié)點可根據(jù)收到的源信息表選擇合適的記錄發(fā)起請求。

源信息表記錄的類型包括:

(1)播發(fā)服務(wù)器:CAS記錄類型;

(2)數(shù)據(jù)流傳輸?shù)木W(wǎng)絡(luò):NET記錄類型;

(3)數(shù)據(jù)流:STR記錄類型。

源信息表的結(jié)構(gòu)是可擴(kuò)展的,可在必要時引入新的記錄類型。所有用戶節(jié)點必須能夠解碼STR記錄類型,而解碼CAS和NET類型是可選的。

4 結(jié)束語

本文系統(tǒng)分析了國內(nèi)外互聯(lián)網(wǎng)傳輸衛(wèi)星導(dǎo)航增強(qiáng)信息的發(fā)展現(xiàn)狀,通過分析SISNe T、Ntrip、 RT-IGS這三種主要的網(wǎng)絡(luò)播發(fā)導(dǎo)航增強(qiáng)信息的傳輸協(xié)議,論述了選擇以廣泛采用的Ntrip協(xié)議作為基礎(chǔ)制定標(biāo)準(zhǔn)的過程。本文描述了衛(wèi)星導(dǎo)航增強(qiáng)信息數(shù)據(jù)互聯(lián)網(wǎng)播發(fā)的網(wǎng)絡(luò)架構(gòu),提出GNSS互聯(lián)網(wǎng)播發(fā)的四個網(wǎng)絡(luò)實體為數(shù)據(jù)源、數(shù)據(jù)服務(wù)器、播發(fā)服務(wù)器、用戶節(jié)點,并論述了網(wǎng)絡(luò)實體之間采用的HTTP、RTSP、簡單RTP的三種通信接口協(xié)議要求。

[1] MATHUR A R,TORáN F,VENTURA-TRAVESET J.SISNeT user interface document V3.1[EB/OL].(2006-05-15) [2015-02-15].http://www.egnos-pro.esa.int/Publications/SISNET/SISNET_UID_3_1.pdf.

[2] The Radio Technical Commission for Maritime Services.Networked transport of RTCM via internet protocol(Ntrip)-version 2.0[EB/OL].(2011-06-28)[2015-02-15].https://ssl29.pair.com/dmarkle/puborder.php?show=3.

[3] 趙軍,王繼龍,吳建平.基于互聯(lián)網(wǎng)的導(dǎo)航定位增強(qiáng)信息大規(guī)模實時播發(fā)研究[J].宇航學(xué)報,2006,27(4):819-823.

[4] FIELDING R,IRVINE U C,GETTYS J,et al.Hypertext transfer protocol-HTTP/1.1[EB/OL].(1999-06-11)[2015-02-15].http://www.ietf.org/rfc/rfc2616.txt.

[5] SCHULZRINNE H,COLUMBIA U,RAO A,et al.Real time streaming protocol(RTSP)[EB/OL].[2015-02-15].http://tools.ietf.org/html/rfc2326.

[6] SCHULZRINNE H,CASNER S,FREDERICK R,et al.RTP:A transport protocol for real-time applications[EB/OL]. [2015-02-15].http://tools.ietf.org/html/rfc3550.

[7] The IGS Real-time Pilot Project Committee.International GNSS Service real-time pilotroject[EB/OL].(2007-06-26) [2015-02-15].http://www.rtigs.net/docs/IGS-RT-Pilot-Project-Call-For-Participation.p df.

A Survey on Internet-based Data Transport Protocol for GNSS

ZHOU Yuxia1,ZHOU Ming2,KANG Dengbang1,HUANG Xiaohong3
(1.China Astronautics Standards Institute,Beijing 100071,China; 2.Institute for Network Sciences and Cyberspace,Tsinghua University,Beijing 100086,China; 3.Network Technology Research Institute,Beijing University of Posts and Telecommunications,Beijing 100876,China)

As the continuously developing and extensive application of GNSSaugmentation technology,it becomes a significant research topic to transport and broadcast GNSS augmentation information efficiently.And then,the researchers pay a lot of attention to the analysis of related standards.This paper focuses on the widely used Networked Transport of RTCM via Internet Protocol(Ntrip)based on the analysis of current communication protocols of internet-based data Transport for Global Navigation Satellite System(GNSS)augmentation information.The paper also describes the network structure that broadcasts GNSS augmentation information via internet,proposes four network entities,and discusses three kinds of general interface protocol based on HTTP,RTSP and simple RTP used between the network entities.

RTK;GNSS;Ntrip;GNSS Augmentation Information;Transport Protocol

P228

A

2095-4999(2015)-04-0032-06

2014-10-16

周玉霞(1972—),女,湖北潛江市人,室主任,高級工程師,從事衛(wèi)星導(dǎo)航標(biāo)準(zhǔn)化技術(shù)研究。

周玉霞,周明,康登榜,等.GNSS互聯(lián)網(wǎng)數(shù)據(jù)傳輸協(xié)議標(biāo)準(zhǔn)綜述[J].導(dǎo)航定位學(xué)報,2015,3(4):32-37.ZHOU Yuxia,ZHOU Ming, KANG Dengbang,et al.A Summary on Internet-based Data Transport Protocol for GNSS[J].Journal of Navigation and Positioning,2015,3(4): 32-37.

10.16547/j.cnki.10-1096.20150407