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

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

(1.中國航天標準化研究所,北京 100071;2.清華大學網(wǎng)絡科學與網(wǎng)絡空間研究院,北京 100086; 3.北京郵電大學網(wǎng)絡技術研究院,北京 100876)

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

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

(1.中國航天標準化研究所,北京 100071;2.清華大學網(wǎng)絡科學與網(wǎng)絡空間研究院,北京 100086; 3.北京郵電大學網(wǎng)絡技術研究院,北京 100876)

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

RTK;GNSS;Ntrip;衛(wèi)星導航增強信息;傳輸協(xié)議

0 概述

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

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

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

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

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

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

(2)Ntrip協(xié)議是國際海事無線電技術委員會制定的衛(wèi)星增強信息的應用層通信協(xié)議,是虛擬參考站(virtual reference stations,VRS)進行數(shù)據(jù)傳輸所采用的標準協(xié)議,它是一個開放的,非私有的協(xié)議,適合于通過互聯(lián)網(wǎng)傳輸全球衛(wèi)星導航系統(tǒng)(global navigation satellite system,GNSS)數(shù)據(jù)流及差分數(shù)據(jù)信息,允許電腦、掌上電腦(personal digital assistant,PDA)和接收機連接到數(shù)據(jù)處理中心;支持通過移動通信進行互聯(lián)網(wǎng)訪問。Ntrip協(xié)議基于文本傳輸通訊協(xié)議(hypertext transfer protocol,HTTP)及TCP協(xié)議,目前在歐洲、亞洲和美國的CORS站上已經(jī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服務(international GNSS service,IGS)實時工作組開發(fā)制定的一種新的數(shù)據(jù)傳輸協(xié)議,它規(guī)定了4種傳輸數(shù)據(jù),并對四種數(shù)據(jù)傳輸頻率進行約定。它與Ntrip協(xié)議不同,其為考慮通過網(wǎng)絡傳輸更好的實時性能,采用的是用戶數(shù)據(jù)報協(xié)議(user datagram protocol, UDP)。2008年IGS加入RTCM-SC104,采用RTCM-3.0作為GPS和GLONASS觀測消息標準,采用RTCM狀態(tài)空間表達式(state space representation,RTCM-SSR)作為軌道和時鐘的修正消息的標準。

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

2 系統(tǒng)結構

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

圖1 網(wǎng)絡實體拓撲結構

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

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

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

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

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

2.3 播發(fā)服務器

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

2.4 用戶節(jié)點

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

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

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

3.1 基于HTTP的接口

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

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

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

圖3 播發(fā)服務器響應

表1 請求格式及意義

表2 代碼及其意義

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

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

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

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

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

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

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

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

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

3.2 基于RTSP的接口

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

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

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

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

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

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

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

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

表3 請求格式及意義

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

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

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

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

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

表4 RTP頭部格式及其意義

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

3.3 基于RTP的接口

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

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

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

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

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

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

3.4 源信息表

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

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

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

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

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

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

4 結束語

本文系統(tǒng)分析了國內(nèi)外互聯(lián)網(wǎng)傳輸衛(wèi)星導航增強信息的發(fā)展現(xiàn)狀,通過分析SISNe T、Ntrip、 RT-IGS這三種主要的網(wǎng)絡播發(fā)導航增強信息的傳輸協(xié)議,論述了選擇以廣泛采用的Ntrip協(xié)議作為基礎制定標準的過程。本文描述了衛(wèi)星導航增強信息數(shù)據(jù)互聯(lián)網(wǎng)播發(fā)的網(wǎng)絡架構,提出GNSS互聯(lián)網(wǎng)播發(fā)的四個網(wǎng)絡實體為數(shù)據(jù)源、數(shù)據(jù)服務器、播發(fā)服務器、用戶節(jié)點,并論述了網(wǎng)絡實體之間采用的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)的導航定位增強信息大規(guī)模實時播發(fā)研究[J].宇航學報,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)星導航標準化技術研究。

周玉霞,周明,康登榜,等.GNSS互聯(lián)網(wǎng)數(shù)據(jù)傳輸協(xié)議標準綜述[J].導航定位學報,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