GB/T 34966.2-2017 卫星导航增强信息互联网传输 第2部分：接口要求

ICS47.020.70

U65

国

=11:.

中华人民和国国家标准

GB/T34966.2-2017

卫星导航增强信息互联网传输

第2部分：接口要求

Internet-basedtransmissionofGNSSaugmentationinformation一

Part2:Interfacerequirements

2017-12-29发布2018-07-01实施

中华人民共和国国家质量监督检验检疫总局

发布

中国国家标准化管理委员会

GB/T34966.2-2017

目次

山

引言…………………....I~「

1范围··

2规范性引用文件……………·

3术语、定义和缩｜咯语…………··

3.1术用和定义

3.2缩略语………………1

4网络结构…………………2

4.1概述…………………2

4.2网络实体……………2

5基于HTTP的接口要求…

5.1概述

5.2用户节点与播发服务器之闯的通信………………4

5.3数据服务器与播发服务器之间的通信

5.4身份认证………………8

5.5传输编码……………8

5.6差错处理

5.7Hcadcrline列表……………………10

6基于RTSP的接口要求………………u

6.1概述…………………12

6.2用户节点与播发服务器之间的通信………………13

6.3数据服务器与播发服务器之间的通信……………u

6.4Keep-Alive处理……………………15

6.5差错处理…………........…………·15

6.6Headerline列表……………………16

6.7RTP数据流………………………16

6.8用于防火墙处理的初始RTP包…………………17

7基于RTP的接口要求…………………17

7.1概述…………………17

7.2建立连接………….………….………·18

7.3开始传输…………...…………·四

7.4结束传输…………........…………·18

8源信息表…………………18

GB/T34966.2-2017

进行修改，即用户优先选择在header里传送NMEA位置。具体的headerline见图8。

LNt即GG/\:$GPGG八，040941.00,503川1174,...47.7,M，，头5l(CR><LF>

图8虚拟参考站数据请求附加的headerline

注：发送包fr,经度和纬度信息的NMEA字符串使得播发服务甘苦可以跟踪用户节点的位置。播发服务裸的操作者

可要考虑通知客户这个潜在的隐私问题。

5.2.5过滤源信息表的请求消息

过滤源信息表的请求消息是通过请求部分源信息表来减少传输到用户节点的信息量。本部分为可

选功能。播发服务器应支持过滤源信息表功能，可以传送比过洁、字符串所要求更多的信息以免遗漏可

用的源信息表。

源信息表请求在URL中编码，在请求字符串之后添加“／？”和请求字符串（requeststring），具体见

罔90

lGET/?

图9过7膏、源信息表的请求消息

“requeststring”包含一个或多个变量和变量值。其格式为variablel二valu巳＆variableZ

=value&variable3=value。变量具体包括：

a)auth:“auth=1”将限制用户前问源信息表的所有元素，同时要求源信息表的请求需要正确的

授权；

b)strict:“strict=1”强制播发服务器对非法请求返回一个错误消息。缺省情况下，为保证容错

性，对错误的源列表请求将返回一个包括所请求信息的源信息表；

c)match：基于比较的简单过滤方法；

d)filter：基于运算的复杂过滤方法。

“match”和“filter”这两种方法基于相同的架构。源信息表中每行的字段是一个字符串或者一个整

数。请求字符串中由分号隔开的元素，表示源信息表本行的一列。最后的空字段可以省略。举例如表

3所示。

表3“match”和“filter”的源信息表

源信息表行意义

请求所有在巾罔的无NMEA特性的播发服务

GET/?match=CAS;;;;;O;CHNHTTP/1.l(CR><LF>

器记录

GET/?match=C八SHTTP/l.l(CR><LF>请求所有播发服务器记录

GET/?match=STR;;;;;;;CNREFHTTP/1.l(CR><LF>请求所有CNREF流

GET/?filter=STR;;;;;;;CNREF;;>=39十（＝41;>=116+(=请求所有北纬39。至41。和东经Il6°至117。的

117;;;;;NHTTP/1.l(CR><LF>参考站的数据i说

授权用户请求所有的数据流（简要额外传输投

GET/?auth=l&.match=STRHTTP/l.l(CR>(LF>

权fff息）

“match”和“filter”这两种方法的复杂程度不同。“match”只进行简单字符串比较，它仅测试记录

与给定元素是否相等；“filter”方法则添加l了逻辑运算符（多个操作符左到布赋值）。具体情况如下：

a)用于字符串和数字的逻辑运算符：

6

GB/T34966.2-2017

一一非（NOT）运算符用于相反的请求：！；

一一与（AND）运算符用于选择多个请求：十；

或（OR）运~：符用于司替换的选择：｜。

b)用于数字的运算符：

一一＜n表示小于；

一一＞n表示大于；

一一＜＝n表示小于等于；

一一＞＝n表示大于等于；

=n表示等于；

!=n表示不等于；

一一～n表示约等于（最接近的值）。

c)用于字符串的运算符：

一一样标识任何字符串（例如：“养REF”选择EUREF和GREF，“RTCM铃”选择任何RTCM

类型）；

。用于字符串分组：（EUIG)REFIIGS表示选择EUREF,GREF或者IGS。

除非要求使用“filter”的增强功能，用户都应使用“match”的方法。如上所述，可以在一个请求中使

用多个过滤器，得到的结果是所有过滤器逻辑“与”的结果。

在GET行输入的字符串应符合URL编码规定，参见IETFRFC2396-1998中2.4。如罔10所示

的请求编码后变成罔11所示。

GET/?filter=STR;;;;;;;EUREF川）＝50十（＝51;)=8.l十（＝8.6;;;;;NHTTP/1.l(CR><LF>

图10过滤i胃、信息表的请求消息

GET

/?filter=STR;;;;;;;EUREF;;%3E%3D50%2B%3C%3D5l;%3E%3D8.l%2B%3C%3D8.6;;;;;N

」

图11过滤源信息表的请求消息

播发服务苦苦支持源信息表过滤的功能为可选项。如果未能实现过滤功能，该请求应视为一个正常

的源信息表请求进行处理。用户节点可以通过分析Ntrip-Flags检测到播发服务器是否支持过滤功能。

5.3数据服务器与播发服务器之间的通信

数据服务器只有上传数据到播发服务器的功能，每个连接都是由数据服务器发向请求，播发服务器

作州响应。请求和响应完成之后，数据服务器将数据传输到播发服务器，具体示例见罔12、罔130

POST/ExampleMountpointHTTPIl.l<CR><LF>

Host:ntrip.(CR)(LF>

NtripVersion:Ntrip/2.0(CR>(LF>

八utborization:BasicbnRyaXA6c2VjcmVO(CR>(LF>

User-Agent,NTRIPExampleServer/2.0(CR><LF>

Connection:close(CR>(LF>

」J_CR)(LF)

图12数据服务器发送请求

7

GB/T34966.2-2017

HTTP/l.l200OI<(CR><LF>

Ntrip-Version,Ntrip/2.0(CR>(LF>

Server:NTRIPExampleCaster/2.0(CR>(LF>

Date,Tue,01Jan200814,08,lSGMT(CR><LF>

Connectio口：close(CR>(LF>

(CR>(LF>

图13播发服务器晌应请求

5.4身份认证

5.4.1概述

HTTP的身份认证用于用户节点到播发服务辑的通信以及数据服务器到播发服务器的通信，其功

能参见IETFRFC2617。身份认证方式包括基本认证方式和摘要认证方式。

5.4.2基本认证

用户节点或者数据服务器将用户名和密码作为请求的headerline发送到播发服务器。具体示例如

罔14所示。

L八uthorizat肌BasicbnRyaXA6c2VjcmVO(CR>(LF>

图14基本认证的请求headerline示例

本例中，所传输的字符串格式是“ntrip:secret”，使用Base64编码，其中“ntrip”表示用户名，

“secret”表示密码。

若访问的挂载点是受保护的，请求中没有“Authorization”或者数据错误，播发服务器应答401的错

误代码，并在响应中包括以下headerline。具体如罔15所示。

[WWWAuthenticate,Basicrealm＝”／Ex叫

图15基本认证的晌应headerline

基本认证方式是一种不安全的授权的问方法，它假设客户端和服务器之间的连接是可信赖的载体，

在开放网络上应谨慎使用。

5.4.3摘要认证

播发服务器｜垛支持基本认证外，还可以选择支持摘要认证，用于为应用程序提供更安全的用户身份

认证。源信息表记录中包含一个标志，用于标识使用的认证方式，其中，BCBasic）表示基本认证，D(Di­

gest）表示摘要认证，>I(None）表示不进行认证。除非基于安全考虑禁止使用基本认证外，为了保证兼

容性，播发服务器在支持摘要认证时也应支持基本认证。摘要认证与基本认证都是通过通信双方共享

密钥（密码）的方式验证认证信息，其中，基本认证采用明文发送密码，而摘要认证采用密文发送密码。

认证方式使用的WWW-Authenticate和Authorization的headerlin巴格式参见IETFRFC2617。

5.5传输编码

块传输编码用于传输一组数据块。每个块都包含长度信息，数据流与长度信息一起传输，以验证传

输的完整性。具体如罔16所示。

8

GB/T34966.2-2017

Transfer-Encoding:chunked(CR>(LF>

图16传输编码headerline

所有实体应能处理收到的传输编码。块传输编码用于传送从播发服务器到用户节点和数据服务器

以及数据服务器到播发服务器的数据流，其格式为先发送卡六进制的数据块长度，然后再发送数据块数

据，具体内容参见IETFRFC26161999中3.60

罔17为块传输编码长度为14（十六进制的E）和长度为19（十六进制13）字节流的示例。

E<CR><LF>

TESTTESTTEST(CR><LF>

13;extension(CR)(LF>

TESTTESTTESTTEST(CR><LF>

图17块传输编码示例

在传输编码的header中增加lextension用于扩展，具体表示见罔17第三行，在本接口要求的软件

实体可忽略extension。

从播发服务器发送数据的示例如罔18所示。

HTTP/1.l200OK(CR><LF>

NtripVersion:Ntrip/2.0(CR)(LF>

Server:NTRIPExampleCaster/2.0(CR)(LF>

Date:Tue,01Jan200814,08,15G扣fT(CR><LF>

CacbeControl:nostore,nocache,maxage=0(CR>(LF>

Pragma:no-cache(CR)(LF)

Connection:close(CR><LF>

Transfer-Encoding:chunked(CR>(LF>

Content-Type:gnss/data(CR>(LF>

(CR)<LF)

ZD(CR><LF>

f八FC～cM{xl}@pT\PrgRi@I‘VjmMC@RAKFeTl}_Tdoxgju(CR)(LF)

lE(CR)(LF)

Y~xiK\rLAHhUPzCQ八joY\EDn、pp～Uj(CR)<LF)

lE(CR)(LF)

fi\GCtcir~gWjoEYQJ\joIcz{Qzpp~UO(CR)(LF)

图18从播发服务器发送数据的示例

5.6差错处理

当数据服务器或用户节点发州一个错误的请求时，播发服务器响应一个错误代码，如罔19所示。

9

GB/T34966.2-2017

HTTP/l.lcodetext(CR><LF>

NtripVersion,Ntrip/2.0(CR><LF>

Server,NTRIPExampleCaster/2.0(CR>(LF>

Date,Tue,01Jan200814,08,lSGMT(CR><LF>

ContentType,text/html(CR>(LF>

Connectio口：close(CR><LF>

(CR><LF>

longtext

图19播发服务器晌应的错误代码

其中代码（code）、文本（text）和长文本（longtext，可选）三个字段会根据错误条件而发生变化。

表4列出了一组客户端收到的错误代码及其意义。状态代码的详细拙述参见IETFRFC2616-1999

中6.1.1和第10章。

表4错误代码及其意义

类型

序号代码字段文本字段意义

l正常200OK正常状态，无差错

2401Unauthorized

未授权没有或是错误的投权

3未发现404NotFound未找到请求的挂载点

4409Conflict

冲突挂载点已被其他服务苦苦使用

5内部服务器错误500InternalServerError

一些内部错误

6无法实现501NotImplemented如为请求的是播发服务器无法实现的功能

7服务不可用503ServiceUnavailable如为播发服务掠过载或带宽受限

5.7Headerline列表

5.7.1概述

headeline用于在请求或响应中传输附加信息。主要包括必选、可选、推荐、不可用四种类别。

播发服务器、数据服务器和用户节点可使用的headerline类型是不相同的，其中，一些hcadcrlme

仅用于某一种系统实体，而另一些可用于多个系统实体。对于每一个系统实体需要注意可以使用的

headcrline的类别。另外接收端也需要确定处理这些headerline的方式，例如，传输编码是由播发服务

器和数据服务器发送，而用户节点和播发服务器都需要能够处理接收到的传输编码hcadcrline。

5.7.2标准HTTP

系统实体之间通｛言使用的标准HTTP的headcrlinc格式，见表5。

10

GB/T34966.2-2017

表5标准HTTP的headerline格式

headerline

播发服务器数据服务甘苦用户节点描述

Authorization:Basic用于客户端传送授权信息到播发服务

不可用

必选必选

bnRyaXA6c2VjcmVO(CR><LF>熬。另见5.4

Cache-Control:no-store,no-cache,代理服务器禁用缓存。另见Pragma

推荐可选不可用

maxage=O(CR><LF>头。此header用于通知接收方

接收实体不能使用持久连接。比header

Connection:close(CR>(LF>推荐推荐推荐

用于通知接收端软件

此header指定header域结束后的数据

字节数。因为其字节数是未知的，它不

Co口tentLength,1234(CR><LF>可这不可用不可用能用于流数据。传送源、信息表和错误

代码可以使用此header。比header用

于通知接收方

此header用于通知传送数据的数据类

型。播发服务器使用的类型错误讯息

使用“text/html”，文本（例如源信息表〉

Content-Type,gnss/data(CR>(LF>推荐不可用不可用

使用“text/plain”，另外两利t类型为

“gnss/sourcetable”和“gnss/data”。通

知按收方

Date,Tue,01Jan2008日期的格式参见IETFRFC2616-1999

推荐可选可选

14,08:15GMT(CR>(LF>巾3.3。此header用于通知接收方

此header包含了请求的主机名。F草拟

主机（例如播发服务然软件在一台服务

Host:n(CR>(LF>可选推荐推荐郡的同一端口的多个不同的实例〉需要

使用此headerIi肘，通知接收方，~播发

服务苦苦百要使用

FR播发服务器发送服务器标识字符串。

Server:NTRIP它包括以下序列：“NTRIP”＋空中各＋软

不可用

推荐不可用

ExampleCaster/2.0(CR>(LF>件名称十“／”十版本（十空格十附加｜文

本）。它是信息的按收方

代理服务榕禁用缓存。另请参阅

Pragma：口ocache(CR>(LF>推荐可选不可用Cache-Control头。比header用于通知

接收方

此header指定所使用的传输编码。见

TransferEncoding,chunl,ed(CR>(LF>推荐推荐不可用5.5。连接的接收端应能够正确处现

编码

内用户节点或数据服务榕发送的客户

UserAgent:NTRIP端标识字符串。它包括以下序列·“NT-

不可用推荐推荐

ExampleServer/2.0(CR>(LF>RIP”＋空中得十软件名称＋“／”＋版本

（＋空中各十附加i文本）

WWWAuthenticate:Basic类型401错误响应需要此headerline,

不可用

必选不可用

realm＝”／ExampleM:mnt阴int”（CR><LF>见5.4

11

GB/T34966.2-2017

5.7.3Ntrip特性

系统实体之间通信使用的Ntrip特性的headerlin巴格式，如表6所示。

表6Ntrip特性的headerline格式

播发数据

headerline用户节点描述

服务然服务榕

NtripGGJ\,此header用于laJ搭发服务都发送初始

$GPGG/\,040941.00,5034.911不可用不可用推荐用户位置，据此信息可以计算Iii虑拟参

74,...47.7,M，，苦5l(CR><LF>考站

Ntrip-Version:Ntrip/2.0(CR>

通知按1t立端使用的Ntrip版本

(LF>推荐推荐推荐

此header用于传送一个源信息表的记

录和需要上载的数据。其巾的字符串

NtripSTR,;ExamplePlace;...;

不可用不可用为源信息表类型为STR的记录从

推荐

none;N;N;400;none(CR>(LF>

第3行开始的数据（忽略行标识符和挂

载点）

Ntrip--Flags,(flagl),(flag2),...用来指定实现本按口要求的程序的能

推荐不可用不可用

(CR><LF>力集

Ntrip-Flags中用flag标识表示其可选或扩展特性。播发服务器应该至少在每个源信息表请求的

时候传输本headerline。目前定义的flag标识包括：

a)st_auth：支持源信息表的过滤元素“auth”；

b)st_match：支持源信息表的过洁、元素“match”；

c)st_filter：支持源信息表的过滤元素“filter";

d)st_strict：支持源信息表的过滤元素“strict”；

c)rtsp：支持RTSP/RTP协议；

f)plainrtp：支持仅RTP的协议。

6基于RTSP的接口要求

6.1概述

RTSP协议采用TCP和UDP协议传输数据。为解决RTSP中UDP存在的问题，采用TCP控制

连接和使用UDP传输数据的混合方式，具体参见RTSP(IETFRFC2326）和lRTP(IETFRFC3550),

其协议功能如下：

a)RTSP控制连接，用于计费和检测传输结束；

b)RTSP协议与基于TCP连接的HTTP协议兼容；

c)RTP可以检测和纠正乱序的数据包；

cl)RTP可以检测丢失的数据；

e)请求源信息表使用普通的HTTP请求；

£)播发服务器只支持持久的RTSP连接。

当“Ntrip-Flags”头中包含“RTSP”方法时，播发服务器应支持基于RTSP的通信接I]要求。

请求消息和响应消息的起始行格式参见IETFRFC2616，请求格式见5.2，响应状态码定义见5.6。

12