GNSS互聯網數據傳輸協議標準綜述

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

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

GNSS互聯網數據傳輸協議標準綜述

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

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

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

RTK;GNSS;Ntrip;衛星導航增強信息;傳輸協議

0 概述

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

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

1 國內外發展

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

基于CORS站的衛星導航定位增強系統廣泛應用于各行各業,用戶數量不斷增加,需要從參考定位站的網絡控制中心發送大量數據至廣大的用戶,因此需要在互聯網的基礎上建立覆蓋網絡來傳輸這些數據。目前支持通過網絡播發導航增強信息的傳輸協議主要有:

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

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

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

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

2 系統結構

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

圖1 網絡實體拓撲結構

2.1 數據源

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

2.2 數據服務器

數據服務器對應Ntrip協議的NtripServer,用于將數據源的GNSS數據傳送到播發服務器。

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

2.3 播發服務器

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

2.4 用戶節點

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

3 系統接口要求

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

3.1 基于HTTP的接口

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

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

圖2 用戶節點或數據服務器請求

圖3 播發服務器響應

表1 請求格式及意義

表2 代碼及其意義

3.1.1 用戶節點與播發服務器之間的通信

用戶節點與播發服務器之間的通信主要包括:

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

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

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

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

(5)播發服務器處理錯誤狀態、錯誤請求等。

3.1.2 數據服務器與播發服務器之間的通信

數據服務器只有上傳GNSS數據到播發服務器的功能,所有連接都是由數據服務器發出請求,由播發服務器做出響應。請求和響應完成之后,數據服務器將GNSS數據傳輸到播發服務器。

3.2 基于RTSP的接口

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

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

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

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

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

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

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

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

表3 請求格式及意義

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

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

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

圖4 RTP數據塊頭部

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

表4 RTP頭部格式及其意義

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

3.3 基于RTP的接口

Ntrip2.0版本支持基于UDP協議的簡單RTP應用層協議。RTP協議主要用于為IP網上的語音、圖像、傳真等多種需要實時傳輸的多媒體數據提供端到端的實時傳輸服務。RTP實現了互聯網上端到端的實時傳輸并提供時間信息和流同步,但它不能保證服務質量。Ntrip定義的簡單RTP協議可以有效降低消息傳輸的時延,為實時性要求較高的用戶提供了一種服務選擇。

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

UDP協議沒有連接控制,因此在通信中丟失的數據包、亂序數據包和冗余數據包必須由應用程序做相應的處理。基于簡單RTP的連接控制包括建立連接、開始傳輸和結束傳輸三個階段。

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

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

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

3.4 源信息表

播發服務器維護一個包含可用的數據源、數據源網絡及播發服務器信息的源信息表,用于收到用戶請求時發送至用戶節點。用戶節點可根據收到的源信息表選擇合適的記錄發起請求。

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

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

(2)數據流傳輸的網絡:NET記錄類型;

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

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

4 結束語

本文系統分析了國內外互聯網傳輸衛星導航增強信息的發展現狀,通過分析SISNe T、Ntrip、 RT-IGS這三種主要的網絡播發導航增強信息的傳輸協議,論述了選擇以廣泛采用的Ntrip協議作為基礎制定標準的過程。本文描述了衛星導航增強信息數據互聯網播發的網絡架構,提出GNSS互聯網播發的四個網絡實體為數據源、數據服務器、播發服務器、用戶節點,并論述了網絡實體之間采用的HTTP、RTSP、簡單RTP的三種通信接口協議要求。

[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] 趙軍,王繼龍,吳建平.基于互聯網的導航定位增強信息大規模實時播發研究[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—),女,湖北潛江市人,室主任,高級工程師,從事衛星導航標準化技術研究。

周玉霞,周明,康登榜,等.GNSS互聯網數據傳輸協議標準綜述[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