GB/T34966.2-2017
卫星导航增强信息互联网传输第2部分：接口要求
Internet-basedtransmissionofGNSSaugmentationinformation—Part2:Interfacerequirements
- 中国标准分类号（CCS）U65
- 国际标准分类号（ICS）47.020.70
- 实施日期2018-07-01
- 文件格式PDF
- 文本页数28页
- 文件大小1.92M
以图片形式预览卫星导航增强信息互联网传输第2部分：接口要求
卫星导航增强信息互联网传输第2部分：接口要求
国家标准 GB/34966.2一2017 卫星导航增强信息互联网传输 第2部分接口要求 itransmtsionfNssaugmentatoninfrmation- Internet-based Part2:Interfacereguirements 2017-12-29发布 2018-07-01实施 国家质量监督检验检疫总局 发布 国家标准化管理委员会国家标准
GB;/T34966.2一2017 目 次 前言 引言 范围 规范性引用文件 术语、定义和缩略语 3.1术语和定义 3.2缩略语 网络结构 4.l概述 4,2网络实体 基于HT'TP的接口要求 5,1概述 5.2用户节点与播发服务器之间的通信 5.3数据服务器与播发服务器之间的通信 5.4身份认证 5.5传输编码 5.6差错处理 5.7Headerline列表 基于RTSP的接口要求 12 6.I概述 13 6.2用户节点与播发服务器之间的通信 6.3数据服务器与播发服务器之间的通信 6.4KeepAive处理 15 ****** 6.5差错处理 l6 6.6Headerline列表 l6 6. RTP数据流 6.8用于防火墙处理的初始RTP包 基于RTP的接口要求 7.1概述 18 7.2建立连接 18 7.3开始传输 18 7.4结束传输 18 源信息表
GB/T34966.2一2017 18 8.1概述 19 8.2播发服务器记录(CAS) 19 8.3网络记录(NET) 20 8.4数据源记录(STR 23 参考文献
GB;/T34966.2一2017 前 言 GB/T34966《卫星导航增强信息互联网传输》分为三个部分 第1部分:播发体制; 第2部分:接口要求; 第3部分:数据传输格式
本部分为GB/T34966的第2部分
本部分按照GB/T1.1一2009给出的规则起草 本部分由航天科技集团公司提出
本部分由全国宇航技术及其应用标准化技术委员会(SAC/TC425、全国北斗卫星导航标准化技 术委员会(sAC/Tc544)归口
本部分起草单位;航天标准化研究所、清华大学,北京邮电大学、北京航空航天大学、四维 测绘技术有限公司
本部分主要起草人周玉霞、周明、康登榜,谢坤,金天,目大鹏,安常青
GB/T34966.2一2017 引 言 随着卫星导航技术的快速发展和广泛应用,人们对卫星导航服务性能的需求和要求愈来愈高,推动 着卫星导航增强技术逐步深人各个应用领域,由此带来对卫星导航增强技术相关标准规范的需求日趋 旺盛和迫切
本部分重点关注的是卫星导航增强信息传输的接口要求,在编制过程中充分考虑我国卫 星导航技术发展和实际应用情况,并参考了RTCM10410.1《基于互联网的RTCM数据网络传输(Nt- ip). 本部分与Ntrip2.0之间的变化与区别主要在于 名称为“卫星导航增强信息互联网传输第2部分:接口要求”; a b 范围按我国标准化要求编写; 增加了第2章“规范性引用文件”,引用标准中用到的国内及国际标准; c 增加了第3章术语相定义.缩略语",对挂载点hcdler.hdtthime等术潺进行定义,补充了缩 d 略语 将Ntrip2.0中的1.3“系统概念”1.4“系统要素”合并成本部分的第4章“系统结构",将系统 的组成部分定义为网络实体,给出了新型的网络实体拓扑结构,并将网络实体分为数据源,数 据服务器、播发服务器,用户节点 f 明确了本部分的具体数据源增强信息数据传输格式见GB/T34966.3 在第5章“基于HTTP的接口要求”中,以表格的形式增加了对header及headerline的分类 g 介绍 h)增加新的小节,对HTTP身份认证的作用和方式进行阐述 针对RTP通信,改为建立连接、开始传输和结束传输三个阶段 j数据源只支持GNsS校正量 增加了资料性附录,分别给出用户节点与播发服务器之间、数据服务器与播发服务器之间进行 k HTTP通信的实现示例
IN
GB;/T34966.2一2017 卫星导航增强信息互联网传输 第2部分接口要求 范围 GB/T34966的本部分规定了基于网络的卫星导航增强信息数据传输的接口要求,包括网络结构、 基于HTTP的接口要求,基于RTSP的接口要求,基于RTP的接口要求、,源信息表等方面内容
本部分适用于在互联网络环境下卫星导航增强信息传输的接口设计与实现
规范性引用文件 下列文件对于本文件的应用是必不可少的
凡是注日期的引用文件,仅注日期的版本适用于本文 件
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件
GB/T2659世界各国和地区名称代码 GB/T9390导航术语 GB/T17424差分全球导航卫星系统(DGNSS)技术要求 GB/T19391全球定位系统(G;Ps)术语及定义 GB/T34966.1卫星导航增强信息互联网传输第1部分:播发体制 GB/T34966.3卫星导航增强信息互联网传输第3部分;数据传输格式 术语、定义和缩略语 3.1术语和定义 GB/T9390,GB/T17424,GB/T19391,GB/T34966.1和GB/T34966.3界定的以及下列术语和 定义适用于本文件
3.1.1 头部header 网络报文中用于表示网络实体之间的基本信息的部分
3.1.2 头行headerline 头部中以(CR>(LF)结束的每一行
注:CR》LF)是字符为0xD和0xA的序列
3.2缩略语 下列缩略语适用于本文件
GNSS 全球导航卫星系统(GlobalNavigationSatellitesSystem HTML -超文本链接标示语言(HypertextMarkupL.anguage) HTTP 超文本传输协议(HypertextTransfterProtocoD) IETF 互联网工程任务组(IntermeEngineeringTaskForce' NMEA 美国国家海祥电子协会(NationalMarineEleetronicsAssociation
GB/T34966.2一2017 RFC 请求评议(一系列以编号为排定的文件>(RequestForcommenut) RTCM -海事无线电技术委员会(RadioTechniealCommissionforMaritimeserviees) imeTr Protocol RTP 实时传送协议(Real-tinm ransport Protocol RTSP -实时流传输协议(RealTimeStreaming rCP 传输控制协议(TransferControlProtocol UDE Protocol -用户数据报协议(UserDatagram URt -统一资源标识符(UniformResourceldentifier UR 统一资源定位符(UniformResourceL.ocator) 网络结构 4.1概述 卫星导航增强信息互联网播发的网络结构见图1,它包括数据源、数据服务器、播发服务器、用户节 点四级结构,其接口要求是基于HHTTP,RTSP,简单RTP的通用协议,为固定或移动的用户提供卫星 导航增强信息数据,具体内容见GB/T34966.1
本接口要求是由终端用户的应用程序和服务器设备的 应用程序实现
数据源1 数据源2 数据源3 数据源 数据服务器1 数据服务器2 数据服务器N 播发服务器1 播发服务器/1 系统管理员 播发服务器2 HTTP/Telnet 用户节点 --- 用户节点 用户节点 用户节点 用户节点 用户节点 图1网络拓扑结构示意图 4.2网络实体 4.2.1数据源 数据源为系统中的数据来源部分,提供像流媒体数据一样的连续的GNSS数据
数据源对应数据 服务器中的挂载点,每个数据源具有唯一的标识符
单一数据源通常使用GNSS数据描述一个特定区域
源信息表中的数据源描述参数规定了使用 的数据格式、位置坐标和其他信息 4.2.2数据服务器 数据服务器用于将数据源的GNSS数据传送到播发服务器
挂载点由播发服务器定义并交付给 数据服务器配置
数据服务器向播发服务器发送增强信息,增强信息传输格式见GB/T34966.3
GB;/T34966.2一2017 数据服务器可支持虚拟参考站,对产生的增强信息的虚拟参考站也可等效为单一数据源
4.2.3播发服务器 播发服务器使用一个监听端口接收从数据服务器或用户节点发出的请求消息
根据收到的消息 播发服务器判断是否需要接收数据服务器的增强信息或向用户节点发送增强信息
4.2.4用户节点 用户节点向播发服务器发送请求后,可接收播发服务器发送的增强信息
用户节点到播发服务器 的消息格式和状态代码兼容HTTP1.1,采用的是HTTP的短连接方式
基于HITP的接口要求 5.1概述 本接口要求采用基于HTTP/TCP的通信方式,由用户节点或数据服务器发起请求,由播发服务器 应答
请求响应通信的基本结构分别如图2和图3所示
REQUEsTcoMMAN DvalueHTTP/I.1(CR>(LF Headerlinel:values(CR>IF》 Headerline2values(CR>(LFy CR>(LF 图2用户节点或数据服务器请求 HTTP/1.1CODEResponse(CR>(LF Headerlinel;values(CR>(LFy Headerline2:values(CR>IF》 CR)LFy 图3播发服务器响应 序列(CR>《LF)是字符为0xD和0xA的序列,并且是HrTP通信标准的行终止符
每个请求由 一个或多个headerline,加一个空行(表示header结束)组成
根据实际需要,可在header之后跟随数 据,具体内容和格式在GB/T34966.3中定义 请求信息和响应消息的起始行格式参见IETFRFC2616,请求格式见5.2,响应状态码定义参见 5.6.请求信息的header可以包括但不限于表1中所列的headerline;响应消息的header可以包括但不 限于表2中所列的headerline 表1请求信息的headerline Headerline 分类 取值或参考标准 版本 NtripVersion Ntrip/2.0 主机地址 Host IETFRFC26161999中14.23 客户端名称 UserAgent IETFRFC26161999中14.43 连接状态 Conneetion IETFRFC2616一1999中14.10
GB/T34966.2一2017 表1续 分类 Headerline 取值或参考标准 Transfer-Encoding 编码 5.6 Authorizationm 认证 5.7 www-Authorization Ntrip特性 NtripFlags 5.8 表2响应消息的headerline 分类 Headerline 取值或参考标准 版本 Ntrip-Version Ntrip/2.0 时间 Date 1ETFRFC2616一1999中14.18 服务器地址 Server IETFRFC2616一1999中14.38 连接状态 Connection IETFRFC2616一1999中14.10 数据长度 Content-length IETFRFC2616一1999中14.13 编码 TransferEneoding 5,6 Authorization 认证 5.7 www-Authorizationm Ntrip特性 NtripFlags 5.8 5.2用户节点与播发服务器之间的通信 5.2.1基本通信过程 用户节点与播发服务器之间的通信主要包括 用户节点向播发服务器请求源信息表或包含过滤条件的源信息表 a b 播发服务器向用户节点发送源信息表; 用户节点向播发服务器请求增强信息数据,请求信息包含指定的挂载点用户名、密码等， c d 播发服务器向用户节点发送增强信息 播发服务器处理错误状态、错误请求等,见5.6
5.2.2源信息表的请求与响应 用户节点通过发送源信息表(见8.4)请求,可获取数据源的基本信息,请求消息与响应消息示例分 别见图4、图5
GETHTTP CRLF 1.1《 Host:ntrip.example.com(CR>(LF》 /2.0(CR>(LFy Nip Version:Ntrip/ User-Agent:NTRIPExampleClient/2.0(CR>(LF Connection:close(CR>LF CR(LF 图 请求源信息表
GB;/T34966.2一2017 HTTP/1.1200OK(CR>(LF Ntrip-VersionNtrip/2.0(CR)LFy NtripFlags:st_filter,st_auth,st_match,st_striet,rtsp(CR>LF Server;NTRIPE le(Caster/2.0(CR>(LF》 xamp Date:Tue，01Jan200814:08;:15GMT(CR>(LF Conneetion:close
GB/T34966.2一2017 进行修改,即用户优先选择在header里传送NMEA位置
具体的headerline见图8. Ntrip-GGA:$GPGGA.040941.005034.91174，477,M.,*51CRL 图8虚拟参考站数据请求附加的headerline 注发送包含经度和纬度信息的NMEA字符串使得播发服务器可以跟踪用户节点的位置
播发服务器的操作者 需要考虑通知客户这个潜在的隐私问题
5.2.5过滤源信息表的请求消息 过滤源信息表的请求消息是通过请求部分源信息表来减少传输到用户节点的信息量
本部分为可 选功能
播发服务器应支持过滤源信息表功能,可以传送比过滤字符串所要求更多的信息以免遗漏可 用的源信息表
源信息表请求在URL中编码,在请求字符串之后添加“/?”和请求字符串(requeststring),具体见 图9
GET7?requeststringHTTP1.1CRLF 图9过滤源信息表的请求消息 “requeststring"包含一个或多个变量和变量值
其格式为variablel=value&.variable2 =value8
variable3=value
变量具体包括: auth;“auth=1”将限制用户访问源信息表的所有元素,同时要求源信息表的请求需要正确的 a 授权 triet“striet=1”强制播发服务器对非法请求返回一个错误消息
缺省情况下,为保证容错 b 性,对错误的源列表请求将返回一个包括所请求信息的源信息表; match:基于比较的简单过滤方法; d ffilter:基于运算的复杂过滤方法
“match”和“filter” "这两种方达基于相同的果构
谋信息表中每行的字段是一个字符串或着一个整 数
请求字符串中由分号隔开的元素,表示源信息表本行的一列
最后的空字段可以省略
举例如表 3所示
表3“match”和“filter”的源信息表 源信息表行 意义 请求所有在的无NMEA特性的播发服务 y GET match=CAS;;;;;0;CHNHTTP/1.1(CR)(LF 器记录 GET =cAsHTTP/1.1(CR)(LF 请求所有播发服务器记录 match GET tmateh=STR; ;CNREFHTTP/1.1CR>(LF 请求所有CNREF流 R;;;;;;; GET filter=STR;;;;;;;CNREF;;)=39十(=4l;》=1l6+《=请求所有北纬39"至41"和东经1l6°至117"的 7;;;;;NHTTP/1.1
GB;/T34966.2一2017 -非(NOT)运算符用于相反的请求:!; -与(AND)运算符用于选择多个请求:十; -或(OR)运算符用于可替换的选择:l
b 用于数字的运算符: n表示小于 >n表示大于 =n表示小于等于; =n表示大于等于; =n表示等于 =n表示不等于 -n表示约等于(最接近的值)
用于字符串的运算符: 标识任何字符申(例如 “关REF”选择EUREF和GREF,“RTCM关”选择任何RTCM 关 类型); )用于字符串分组.(EUIG)REFIIGs表示选择EUREF,GREF或者IGs. 除非要求使用“flter”的增强功能,用户都应使用“matceh”的方法
如上所述,可以在一个请求中使 用多个过滤器,得到的结果是所有过滤器逻辑“与”的结果
在GET行输人的字符串应符合URL编码规定,参见IETFRFc23961998中2.4
如图10所示 的请求编码后变成图11所示
GETre=STR NCR EURE=O=8E8.6面 R;l 图10过滤源信息表的请求消息 GET /？filter= ;EUREF;;%3E%3D50%2B%3C%3D51;%3E%3D8.1%2B%3c%3D8.6; =sTR" 6N 图11过滤源信息表的请求消息 播发服务器支持源信息表过滤的功能为可选项
如果未能实现过滤功能该请求应视为一个正常 的源信息表请求进行处理
用户节点可以通过分析NuipFugE有 检测到播发服务器是否支持过滤功能
5.3数据服务器与播发服务器之间的通信 数据服务器只有上传数据到播发服务器的功能,每个连接都是由数据服务器发出请求,播发服务器 作出响应
请求和响应完成之后,数据服务器将数据传输到播发服务器,具体示例见图12,图13
CRLF POST/ExampleMountpointHTTP/1.1《 Host:ntrip.example.com(CR)>(IF》 p/20cR>LP) NtripVersion:Ntrip Authoization:BasicbnRyaXA6e2VjcmVo(CR>LF User-Agent:NTRIPExatmpleServer/2.0(CR>(LF)y Conmmeetion close(CR)IF CR>(LF 图12数据服务器发送请求
GB/T34966.2一2017 HTTP/1.1200O)K(CR>(LF NiripVersion，Nupw2.oCR>L Server:NTRIPExampleCaster/2.0(CR)(IF》 Date;Tue，01Jan200814;,08;l5GMT
GB;/T34966.2一2017 Transfer-Encoding:chunked(CR>(LF 图16传输编码headerline 所有实体应能处理收到的传输编码
块传输编码用于传送从播发服务器到用户节点和数据服务器 以及数据服务器到播发服务器的数据流,其格式为先发送十六进制的数据块长度,然后再发送数据块数 据,具体内容参见IETFRFC26161999中3.6. 图17为块传输编码长度为14(十六进制的E)和长度为19十六进制13)字节流的示例
E(CR>LF TESTTESTTEST(CR>(LF 13;extension(CR>(LFy TESTTEsTTEsTTEsT(CR>(LFy 图17块传输编码示例 在传输编码的header中增加extension用于扩展,具体表示见图17第三行,在本接口要求的软件 实体可忽略extension
从播发服务器发送数据的示例如图18所示
HTTP/1.1200oK(CR)LF) NtripVersion:Ntrip/2.0(CR(IF NTRIPExampleCaster/2.0(CR>(IF》 15GMT(CR>(LF Date:Tue，01Jan200814;08;l Cache-Control:nostore，no-cache，max-age=0CR>(LF》 norcache(CR)LFy I2l2IlIa Conneetion:close(CR>LF》 -Encoding:ehunkedCR)(LF Oe Type:gnss/data(CR(IF 《IF fAFC~cMx|@pT\PrgRi@IVjmMC@RAKFeTl)_Tdoxgju(CR)(LF 1E(CR>(LFy x|K\rlAHhUPxCQAjoY\EDnppUj(CR>LF 1E(CR>(I.Fy AGcteir一gwjoEYQAjolczQ4pp~UoCR>(LF 图18从播发服务器发送数据的示例 5.6差错处理 当数据服务器或用户节点发出一个错误的请求时,播发服务器响应一个错误代码,如图19所示
GB/T34966.2一2017 HTTP/1.1codetext(CR)(LF》 Ntrip-Version;Ntrip/2.0(CR>(LF) Server:NTRIPExampleCaster/2.0(CR>(LF) DateTe，01 m28140s.1GMTrcR)LF Content-Type;text/htmlCR>LF Connection:close(CR>LF (CR>(LF longtext 图19播发服务器响应的错误代码 其中代码(eode),文本(tex)和长文本(longtext,可选)三个字段会根据错误条件而发生变化. 表4列出了一组客户端收到的错误代码及其意义
状态代码的详细描述参见IETFRrC2616一1999 中6.1.l和第10章
表4错误代码及其意义 序号 类型 代码字段 文本字段 意义 正常 200 OK 正常状态,无差错 未授权 401 Unauthorized 没有或是错误的授权 未发现 404 NotFound 未找到请求的挂载点 冲突 409 Confliet 挂载点已被其他服务器使用 内部服务器错误 500 lnternalServerError -些内部错误 无法实现 如为请求的是播发服务器无法实现的功能 501 NotlImplemented 如为播发服务器过载或带宽受限 ServiceUnavailable 服务不可用 503 5.7 Headerline列表 5.7.1概述 headeline用于在请求或响应中传输附加信息
主要包括必选、可选、推荐不可用四种类别 播发服务器、数据服务器和用户节点可使用的headerline类型是不相同的,其中，一些headerline 仅用于某一种系统实体,而另一些可用于多个系统实体
对于每一个系统实体需要注意可以使用的 headerline的类别
另外接收端也需要确定处理这些headerline的方式,例如,传输编码是由播发服务 器和数据服务器发送,而用户节点和播发服务器都需要能够处理接收到的传输编码headerline 5.7.2标准HTTP 系统实体之间通信使用的标准HTTP的headerline格式,见表5
10
GB;/T34966.2一2017 表5标准HP的hederline格式 捕发服务器数据服务器用户节点 headerline 描述 用于客户端传送授权信息到播发服务 AuthorizationBasic 不可用 必选 必选 bnRyaXA6e2VjemVo(CR>(LF 器
另见5.4 nostore norcache， 代理服务器禁用缓存
另见Pragma CacheControl: 推荐 可选 不可用 nmaxage=0(CR)(LF 头
此header用于通知接收方 接收实体不能使用持久连接
此header Connection:close(CR>LFy 推荐 推荐 推荐 用于通知接收端软件 此header指定header域结束后的数据 字节数
因为其字节数是未知的它不 Content-lLength:1234(CR>(LF 可选 不可用 不可用 能用于流数据
传送源信息表和错误 代码可以使用此header
此header用 于通知接收方 此header用于通知传送数据的数据类 型
播发服务器使用的类型;错误讯息 使用“text/html”,文本例如源信息表 推荐 Content-Type:gnss/data(CR>(LF 不可用 不可用 使用 ,另外两种类型为 “text/plain”， “gnss/sourcetable”和“gnss/data" 通 知接收方 Date;Tue，01Jan2008 日期的格式参见IETFRFC2616-199g 推荐 可选 可选 14:08;15GMT(CR>(LF 中3.3
此header用于通知接收方 此header包含了请求的主机名
虚拟 主机(例如播发服务器软件在一台服务 Host;ntrip.example.com(CR>(LF 可选 推荐 推荐 器的同一端口的多个不同的实例)需要 使用此headerline,通知接收方,虚播发 服务器需要使用 由播发服务器发送服务器标识字符串 Server:NTRIP 它包括以下序列:“NTRIP”空格软 不可用 推荐 不可用 ExampleCaster/2.0(CR>(ILF 件名称十“/”十版本十空格十附加文 本)
它是信息的接收方 代理服务器禁用缓存
另请参阅 Pragma:norcache(CR)(LF 推荐 可选 不可用 Cache-Control头
此header用于通知 接收方 此header指定所使用的传输编码
见 推荐 Tansfer-Eneding:chunked(CR>(LF 推荐 不可用 连接的接收端应能够正确处理 5.5 编码 由用户节点或数据服务器发送的客户 NTRIP UserAgent 端标识字符串
它包括以下序列,“NT 不可用 推荐 推荐 ExampleServer/2.0(CR(IF》 RIP”十空格十软件名称+“/”十版本 十空格十附加文本) 类型401错误响应需要此 WWW-AuthenticateBasie headerline 必选 不可用 不可用 ream="/ExampleMountpoint"CR(LF 见5.4 1
GB/T34966.2一2017 5.7.3Ntrip特性 系统实体之间通信使用的Ntrip特性的headerline格式,如表6所示
表6Ntrip特性的headerline格式 播发 数据 用户节点 描述 headerline 服务器 服务器 Ntrip-GGA: 此header用于向播发服务器发送初始 $GPGGA,040941.00,5034.911 用户位置,据此信息可以计算出虚拟参 不可用 不可用 推荐 74，47.7,.M.*5I(CR>(LF 考站 Ntrip-Version:Ntrip/2.0CR》 通知接收端使用的Ntrip版本 推荐 推荐 推荐 此header用于传送一个源信息表的记 录和需要上载的数据
其中的字符串 Ntrip-STR:;ExamplePlace; 不可用 推荐 不可用 为源信息表类型为sTR的记录从 none;N;N;400;none(CR)>(LF 第3行开始的数据忽略行标识符和挂 载点) 用来指定实现本接口要求的程序的能 NtripFlags:《flagl》,《lag2> 推荐 不可用 不可用 CR>lF 力集 Ntrip-Flags中用lag标识表示其可选或扩展特性
播发服务器应该至少在每个源信息表请求的 时候传输本headerline
目前定义的lag标识包括 a _auth;支持源信息表的过滤元素“auth” st b ;支持源信息表的过滤元素" st_match: “match”; c “filter” Lfler支持辉信息表的过滤元素" sL=striet.支持源信息表的过滤元素“strie" d rtsp:支持RTSP/RTP协议; e f plain_rtp:支持仅RTP的协议
6 基于RISP的接口要求 6.1概述 RTSP协议采用TCP和UDP协议传输数据
为解决RTSP中UDP存在的问题,采用TCP控制 连接和使用UDP传输数据的混合方式,具体参见RTSP(IETFRFC2326)和RTP(IETFRFC3550)， 其协议功能如下 a RTSP控制连接,用于计费和检测传输结束; b RTSP协议与基于TCP连接的HTTP协议兼容; c RTP可以检测和纠正乱序的数据包 d RTP可以检测丢失的数据; 请求源信息表使用普通的HTTP请求; e f 播发服务器只支持持久的RTSP连接
当“Ntrip-Flag”"头中包含“RTSP"方法时,播发服务器应支持基于RTSP的通信接口要求
请求消息和响应消息的起始行格式参见ETFRFC2616,请求格式见5.2,响应状态码定义见5.6
12
GB;/T34966.2一2017 请求消息的header可以包括但不限于表1中所则的headerline;响应消息的header可以包括但不限于 表2中所列的headerline: RTSP连接控制包括建立连接、开始传输和技术传输三个阶段
RTSP使用SETUP消息启动 RTSP连接,服务器为流分配资源;随后PLAY消息,启动数据流传输;使用TEARDOwN消息释放数 据流资源,结束RTSP连接
6.2用户节点与播发服务器之间的通信 6.2.1建立连接 通信开始使用RTSP协议建立一个连接,用户节点的请求消息见图20
SETUPrtsp://ntrip.example.com/ExMountpointRTSP/1.0(CR>(LF CSeg:1CR)>(1Fy NtripVersion:Ntrip/2.0(CR(LF Ntrip-Component:Ntripclient(CR>(IFy nvo(cR)(LF AuthorizationBasicbnRaXA6c u2vTm User-Agent:NTRIPExampleServer/2.0(CR>LF》 =4588(CR>LF TransportRTP/GNss;umieastclient-port- CR)IF 图20RISP建立连接时用户节点请求消息 NtripComponent用于描述软件实体信息,Transport用于描述协议类型和端口号,其UDP端口可 以随机选取,用户节点使用此端口接收UDP数据
播发服务器响应消息见图21
RTSP/1.0200(OKCR>(LF csq;1cR:(LP) Session:47112344(CR)(LF Transport，RTP/GNsSiuiceastielient-port=45881serveE-port=6256 (CR(LF Ntrip-Version:Ntrip/2.0(CR)(LF》 NTRIPExamplCaster/2.0(CR>(LF Server Date;Tue，01Jan200814;08:l5(GMT(CR)>(IF cR
GB/T34966.2一2017 RTSP/1.0200OKCR)(ILFy cs叫.2cR:LF Session:47112344(CR)(LF CR)(LF 图23播发服务器响应消息 通信完成后,播发服务器开始从服务器端口向用户节点的客户端端口发送数据,其格式采用RTP 协议,见6.7
有关防火墙的处理见6.8.
6.2.3结束传输 用户节点停止数据传输的请求消息以及播发服务器响应消息分别见图24图25
播发服务器收到 该消息或关闭控制连接之后,都会停止传输数据
TEARDOWNrtsp://ntrip.example.com/ExMountpointRTSP/1.0(CR>LF cSeg:3(CR)(LFy Session:47112344(CR>(LF CR)(LF》 图24用户节点停止数据传输的请求消息 RTSP/1.,0200OK(CR>(IF) CSeq:3(CR>(LFy Session:47112344(CR>(LF (CR>(LF 图25播发服务器停止数据传输的响应消息 6.3数据服务器与播发服务器之间的通信 数据服务器与播发服务器之间建立连接和结束传输同6.2.1,6,2.3,其中“NtripComponent”应设置 为“Ntripserver” 数据服务器启动数据传输到播发服务器的请求消息以及播发服务器的响应消息分别见图2和 图27
RECORDr" 7ip.cample.com/EaMoupoRTsPI.0CRLF CSeq:2(CR>(LFy Session:47112344(CR>LF》 (CR>LF 图26数据服务器启动数据传输到播发服务器的请求消息 RTSP1.0200OKCR>L CSeq:2(CR>(LF》 Session:47112344(CR>(LF》 CR)(LFy 图27启动数据传输时播发服务器的响应消息 通信完成后,数据服务器开始从服务器端口向播发服务器的端口发送数据,其格式采用RTP协议 14
GB;/T34966.2一2017 见6.7
数据服务器通信不需要用于防火墙处理的特殊初始数据包
6.4KeepAlive处理 RTP数据传输启动后,由于RTsP协议本身很长一段时间不传输数据,需要一个请求来告诉通讯 双方连接还处于keep-Alive状态,该请求始终由数据服务器或用户节点发出,定期发送到播发服务器
数据服务器或用户节点发出的请求消息见图28,播发服务器的应答消息见图29.
ENRAMETERp7pummEMRTSPIRL丽 CSeq:42(CR>LF Session:47112344(CR>(LFy CR)IF 图28数据服务器或用户节点发出的KkeepAIiv请求消息 RTSP1.0200OKCRLF CSeq:42(CR>(IF Session:47112344CR>(LF CR)IF 图29播发服务器的Keep-Alive响应消息 该请求建议每隔30s发送一次
如果播发服务器超过1nmin没有收到该请求就会关闭连接
数 据服务器或用户发送请求失败时也会关闭连接
Keep-Aive数据包可以用来传送更新的headerline到播发服务器
6.5差错处理 当数据服务器或用户节点发出一个错误请求时,播发服务器响应一个错误响应消息如图30所示
RTSP/1.0codetext(CR(LF Cseq:2(CR>(LF Session:99999(CR>(LF NtripVersion:Ntrip/2.0(CR>(LF》 srer，NTRPExample 72.0(CR>(LF) leCaster/ Date:Tue，01Jan200814:08:l5GMT(CR>(LF CR)(LF 图30播发服务器响应一个错误响应消息 其中代码(code),文本(text),序列号和会话号四个字段会根据错误条件而发生变化
序列号和会 话号与客户端请求消息中的值相同
初始请求应包括这些headerlin ine
表7列出了一组客户端收到的 错误代码及其意义
状态代码的详细描述见IETFRFC2616一1999中6.1.1和第10章
表7错误代码及其意义 序号 类型 代码字段 文本字段 意义 正常 200 OK 正常状态,无差错 未授权 401 Unauthorized 没有或是错误的授权 未发现 404 NotFound 未找到请求的挂载点 15
GB/T34966.2一2017 表7(续 序号 类型 代码字段 文本字段 意义 冲突 409 Confliet 挂载点已被其他服务器使用 内部服务器错误 500 nternalServerError -些内部错误 例如,请求的是播发服务器无法实现的功能 501 无法实现 Notlmplemented 503 无可用服务 例如,播发服务器过载或带宽受限 ServiceUnavailable 6.6Headerline列表 6.6.1概述 只介绍RTSP传输所需的特殊header
有关其他header的详细信息,参见5.7
6.6.2标准RISP 在RTsP中使用而在HTTP通信中不使用的附加headerline如表8所示
Headerlhne中的“Au thorization”,“Date”,“Server”和“User-Agent”也在RTSP中使用
更多信息参见5.7.2
表8Ntrip特性的headerline格式 播发 数据 headerine 用户节点 描述 服务器服务器 请求序列号
每次发送到播发服务器的请求序列号 1
GB;/T34966.2一2017 2 2 w 序列号 PT 时间款 同步源SSRC标识 提供源(CSRC)标识 图32RTP数据块头部 每个字段的值如表9所示
目前使用的字段为载荷类型(PT)和SSRC,其他字段的定义参见 IETFRFC3550
表9RT头部格式及其意义 序号 值 类型 意义 版本号( 表示RTP版本 V 填充位(P) 本接口要求不使用,也许将来使用 扩展位(X 本接口要求不使用,也许将来使用 CSRC计数(CC) 本接口要求不使用,也许将来使用 标签(M 本接口要求不使用,也许将来使用 96 载荷类型(PT) 本接口要求的媒体类型是96 序列号(Ssequeneenumber 每个数据包值加1,开始于一个随机数 定时器的时钟速率为8kHa(分辨率1254s),初始值随机 时间戳(Timestamp SSRc 流标识符流(RTsP的会话号 RTP包头的前六个字段保留,用于将来的扩展功能
随后的三个字段,序列号在发送第一个分组 时初始化为随机选择的值,对于后续发送的每个包其序列号要加1
时间戳随时间的增加而增加 sSRC保持不变
这些值可用于数据流的完整性测试.并对收到的数据包排序
包括RTP头部的整个RTP数据包长度的最大字节数为1526
一般选择最大长度数据包可以减 少包头开销
但构建大长度的数据包会产生较大数据延迟而影响实时性
因此,应根据这两个需求综 合选择大小合适的数据包长度
.8用于防火墙处理的初始RI包 RTP数据连接是由服务器发起,可能会被防火墙阻塞
为避免阻塞,需要从本地网络的RTP客户 端使用其UDP端口发送一个初始的UDP包
此数据包是没有附加的数据的正常RTP数据包,相当 于RTP协议的“KeepAive"数据包
数据包包括12个字节(以十进制数)的报文“12896nnttt ttssss”,其中,“n”是随机选择的序 列号,“t"为时间戳,“s”为会话号
用户节点需要先发送此数据包,再发送RTSP的“PLAY”请求
为兼容所有网络系统建议发送,在 未受防火墙保护的网络系统中可不发送此数据包
基于RIP的接口要求 7.1概述 简单RTP协议使用一种不同的UDP通信方法,它是基于HTTP协议和RTSP/RTP通信的组合
17
GB/T34966.2一2017 在“NtripFlags”中包含对“plain_rtp”的支持
协议支持的负载类型见表10.
表10RTP负载类型及其意义 序号 负载类型 数据部分 描述 96 keepalive包 数据流 普通数据传输 96 97 HTTP HTTP请求/应答 98 结束连接 UDP协议没有连接控制,因此在通信中丢失的数据包应有相应的处理
7.2建立连接 为建立数据服务器或用户节点到播发服务器的连接客户端发送一个RIP包到播发服务器的 UDP端口,播发服务器监听该端口
该包的ssRc可以自由选择,“payoadtype”是97,包的数据部分 的HTTP请求见5,2,5.3
播发服务器使用载荷类型为97的应答请求,其ssRc与请求RTP包相同
从播发服务器发送的 数据部分包含一个标准的HTTP响应,附加的headerline“Session”应包括在响应中,见6.6.2,如果这 个header值与使用的sSRC不同,后续通信的sSRC必应用新的会话号
由于RTP包的大小限制,需 要限制使用header的数量
7.3开始传输 从数据服务器到播发服务器或从播发服务器到用户节点发送数据包的传输见6.7
如果30s没 有发送数据包,建议发送一个Keep-Aive包,其格式与6.8中的数据包一致
7.4结束传输 如果关闭连接,系统实体应发送负载类型为98的无附加数据的RTP数据包
如果系统实体收到 该数据包或1min没有收到该数据包,连接正常关闭
源信息表 8.1概述 播发服务器维护一个包含可用的数据源、数据源网络及播发服务器信息的源信息表,用于收到请求 时发送至用户节点
源信息表记录的类型包括 播发服务器:CAS记录类型; a b) 数据流传输的网络:NET记录类型; 数据流STR记录类型
c 源信息表可在必要时通过引人新的记录类型来扩展
所有用户应解码STR记录类型,CAS和 NET类型的解码是可选的
在源信息表记录中所有的数据字段使用“;”作为字段分隔符;若“;”字符成为一个数据字段的内容 的一部分,则应使用引号““;””
在源信息表中数据字段的数目是不固定的,允许引人附加的数据字 段，最后一个数据字段为“Miscellaneous" 源信息表的结束字符串是:ENDsOURCETABLE
18
GB;/T34966.2一2017 所有行(包括最后一行)均以(CR>(LF)结束
8.2播发服务器记录(CAs 源信息表中的CAS记录用来描述播发服务器信息,最少应包括当前使用的播发服务器
见表11
表11源信息表记录中描述播发服务器的格式及内容 序号 记录参数 意义 格式 长度 示例 CAS 本记录的下列参数用于描述播发服务器 字符 CAS(强制性 type 141.74.243.ll1 字符 host 播发服务器的主机域名或P地址 128 euref-ip.ifag.de 80 满口号 整数 port 2101缺省 NTRIPCaster/0.5.3 播发服务器标识符,例如供应商名字 字符 未定 《identifier BKG 运营播发服务器的单位/机构/公司名称 字符 未定 operator》 ISAP(OS 播发服务器接收来自客户端的大致位置的 NMEA信息的能力 -“播发服务器”表示无法处理收到的来自客 整数 nmea 内端的大致位置的NMEA信息; -“播发服务器”表示能够处理收到的来自客 户端的大致位置的NMEAGGA信息 CHIN (GB/T2659定义的3字节国家代码 字符 DEU德国 country ESP西班牙 十进制 40.12 位置,纬度(北纬为十,南纬为一) 浮点数 小数点 《latitude 12.14 后两位 十进制 0.12 位置，经度(东经为十,西经为 (longitude 浮点数 小数点 357.85 后两位 213.20.169.236 备用播发服务器的IP地址 l0fallback_host) 字符 <128 caster.fgi.i 无备用;0.0.0.0 o.0.0.0 80 备用播发服务器的端口号 《falback_port) 整数 201 无备用:0 (misc 其他信息,记录的最后一个数据字段 字符 未定 none 8.3网络记录(NEr) 源信息表中的NET记录用来描述网络信息,用于根据类型、数据供应商或其他方式对数据源进行 19
GB/T34966.2一2017 分组,如表12所示
表12源信息表记录中描述数据流网络的格式和内容 序号 记录参数 意义 格式 长度 示例 NE 本记录的下列参数用于描述数据流 NET 字符 type 网络 强制性 lEPNIGL(Os、 网络标识符,例如全球导航卫星系统的 identifier 字符 未定 永久性参考站的网络名称 GREF,SAPOS 运营网络的单位/机构/公司名称 字符 未定EUREF,.IGs,sAPOs operator 网络数据流访问保护: None 字符 authentication =Basie基本认证 摘要认证 N,B D= Dee 是否收费 fee N=不计费 字符 Y=计费 webnet) 网络信息的Web地址 字符 未定http://igs.ifag.de lhttp://www.epncb.oma.be 未定 流信息的web地址 字符 《web-str none leuref-ip@ifag,de 未定 注册用的web地址或邮箱地址 字符 《web-reg lhttp://igs.ifag.de ** 其他信息,记录的最后一个数据字段 字节 misc none 未定 8.4数据源记录(STR) 8.4.1STR记录 源信息表中的STR记录描述数据源信息,如表13所示
每个挂载点都需要一个STR类型的 记录
表13源信息表记录中描述数据流的格式和内容 示例 序号 记录参数 意义 格式 长度 sTR 本记录的下列参数用于描述一 STR 字符 《type 数据流 强制性 字符,仅限 “A”“Z” lEU0 播发服务器挂载点 <100 IEU1 mmountpoint “0” IWTZJ0 和 20
GB;/T34966.2一2017 表13(续 序号 记录参数 意义 格式 长度 示例 数据源标识符,例如数据源所在地 《identifier 字符 未定 IBeijing |附件的城市名称 lGB/T34966.3 数据源的数据格式,如 《format》 字符 未定 GB/T34966.3、NEMA0183等 NEMA0183 GB/T34966. 消息类型,括号内 1001(1，10021 《format-details》 字符 未定 是更新周期,单位为秒(s 1003(30 数据流中包括载波相位信息 No(用于DGPs) 整型 carrier Yes，L1用于RTK Yes，L1&.1.2(用于RTK) GPS 导航系统 字符 未定 IBDS naV-System lBDs十GPs lEUREF IGS IIGL0S network I网络 字符 未定 IsAP(Os IGREF IMise GB/T2659定义的3字符国家 lCHN 字符 country lDEU 代码 十进制小数40.12 1C
卫星导航增强信息互联网传输第2部分：接口要求GB/T34966.2-2017
随着人们对信息的需求越来越大，信息传输的速度和精确度也变得越来越关键。卫星导航增强信息互联网传输技术应运而生，解决了传统通信网络无法覆盖的地区和传输过程中遇到的困难。但是，为了实现卫星导航增强信息互联网传输，需要有一套统一的接口标准来保证各个设备之间的兼容性。 GB/T34966.2-2017就是这样一套标准，它规定了卫星导航增强信息互联网传输所需的接口要求。这些接口要求包括数据传输接口、控制接口、电源接口等等。其中最重要的是数据传输接口，因为它关乎到信息传输的速度和精确度。 在GB/T34966.2-2017中，数据传输接口主要分为三个部分：物理层、数据链路层和网络层。物理层主要负责传输物理信号，如电压、电流、频率等。数据链路层则负责将物理信号转化成数据包，并通过数据帧进行传输。网络层则负责控制数据的传输路径和路由选择。 除了数据传输接口之外，GB/T34966.2-2017还规定了其他接口的要求。例如，控制接口需要支持设备状态的查询和设置、电源接口需要满足特定的电压和电流要求等等。这些要求都是为了确保卫星导航增强信息互联网传输技术能够稳定运行。 总之，GB/T34966.2-2017是卫星导航增强信息互联网传输所必需的一套接口标准，它对于保证各个设备之间的兼容性和信息传输的速度和精确度具有至关重要的作用。
卫星导航增强信息互联网传输第2部分：接口要求的相关资料
- 卫星导航船舶监管信息系统第3部分：船载终端技术要求GB/T26782.3-2011
- 卫星导航船舶监管信息系统第1部分：系统组成与功能定义GB/T26782.1-2011解析
- 卫星导航船舶监管信息系统第2部分：系统信息交换协议GB/T26782.2-2011
- 卫星导航动态交通信息交换格式GB/T27605-2011
- 卫星导航定位系统的时间系统GB/T29842-2013
- 卫星导航增强信息互联网传输第3部分：数据传输格式GB/T34966.3-2017
- 卫星导航增强信息互联网传输第2部分：接口要求GB/T34966.2-2017
- 卫星导航增强信息互联网传输第1部分：播发体制GB/T34966.1-2017解析
- 关于信息技术手持设备游戏软件接口要求GB/T32418-2015的探讨
- 水表输入输出协议及电子接口要求GB/T36243-2018
- GB/T38320-2019要求下的智能家用电子系统终端设备与统一接入服务平台接口
- 航天器对发射服务接口要求文件GB/T40544-2021解读
- 成人特里马滑雪靴特里马滑雪板固定器接口要求和试验方法GB/T40922-2021
- 卫星导航增强信息互联网传输第2部分：接口要求GB/T34966.2-2017
