GNSS互联网数据传输协议标准综述
2015-07-07周玉霞康登榜黄小红
周玉霞,周 明,康登榜,黄小红
(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,序列
图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
