【YD通讯标准】 基于公用通信网的物联网应用 电动自行车定位服务 第1部分:应用平台技术要求

ICS33.040.99
中华人民共和国通信行业标准
YD/T3011.1-2016
基于公用通信网的物联网应用
电动自行车定位服务
第1部分：应用平台技术要求
IOTapplicationbasedonpubliccommunicationnetworkPubliclocationserviceforelectricbicyclePart 1: Technical requirements for application platform2016-01-15发布
2016-04-01实施
中华人民共和国工业和信息化部发布前
范围·
规范性引用文件
术语和定义·
缩略语
5电动自行车定位服务总体网络架构6功能要求·
业务要求
接口、协议和数据交互流程…·8
性能要求
安全要求
YD/T3011.1-2016
YD/T3011.1-2016
YD/T3011-2016“基于公用通信网的物联网应用电动自行车定位服务分为以下4个部分：—第1部分：应用平台技术要求：第2部分：应用平台测试方法：www.bzxz.net
—第3部分：终端技术要求：
一第4部分：终端测试方法。
本部分为YD/T3011-2016的第1部分。本部分按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由中国通信标准化协会提出并归口。本部分起草单位：中国信息通信研究院、公安部第三研究所、中国移动通信集团公司、中国电信集团公司、中国联合网络通信集团有限公司。本部分主要起草人：李成、唐前进、刘越、宛海涛、戴欣、刘臻炜、马书慧。HiiKAoNiKAca
1范围
基于公用通信网的物联网应用
电动自行车定位服务
第1部分：应用平台技术要求
YD/T3011.1-2016
本部分规定了基于公用通信网的电动自行车定位服务应用平台的功能、业务、接口和协议、数据交互流程、性能以及安全等方面的技术要求。本部分适用于基于公用通信网的电动自行车定位服务应用平台。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。YD/T2399-2012M2M应用通信协议技术要求3术语和定义
下列术语和定义适用于本文件。3.1
电动自行车定位服务应用平台PublicLocationServiceApplicationPlatformforElectricBicycle实现电动自行车定位服务中的用户管理、数据管理等，并提供定位、远程控制、信息查询及报警等业务的平台，本部分中简称为应用平台。3.2
业务支撑系统BusinessSupportingSystem网络中用于签约、计费和结算的系统。3.3
第三方应用系统ThirdPartyApplicationSystem由电动自行车定位服务应用平台运营方以外的组织机构建设和维护的，与应用平台进行信息交互的应用系统。
业务网关ServiceGateway
电动自行车定位服务终端接入应用平台前，实现接入认证、协议转换和路由寻址的功能实体。3.5
短信网关ShortMessageGateway
部署在电信运营商网络中实现用户手机与应用平台之间短信收发的应用平台。3.6
电动自行车定位服务终端PublicLocationServiceTerminalforElectricBicycle安装在电动自行车上为其提供公共定位服务的设备。3.7
HiiKAoNiKAca
YD/T3011.1-2016
设置警戒SetGuard
电动自行车定位服务终端设置为对振动监测和越界监测给出报警信息的状态。3.8
解除警戒UnsetGuard
电动自行车定位服务终端设置为不对振动监测和越界监测给出报警信息的状态。4缩略语
下列缩略语适用于本文件。
Cyclic Redundancy Check
File Transfer Protocol
Geographic Information SystemGlobal Positioning System
HypertextTransferProtocol
Intermational Mobile Equipment IdentityInternational MobileSubscriberIdentification NumberMachine to Machine
Protocol Data Unit
Quality of Service
Subscriber Identification ModuleSimpleObjectAccessProtocol
User IdentificationModule
5电动自行车定位服务总体网络架构循环元余校验码
文件传输协议
地理信息系统
全球定位系统
超文本传输协议
国际移动设备身份码
国际移动用户识别码
机器到机器
协议数据单元
服务质量
用户标识模块
简单对象访问协议
用户标识模块
电动自行车定位服务是基于公用通信网的物联网应用，提供电动自行车定位、信息查询、远程控制以及报警等功能。图1所示为电动自行车定位服务总体网络架构，第三方应用系统
短信网关
应用平台
业务网关
移动通信网
（用于与终增通信）
移动通信网
用于与用户手机通值电动自行车防盗蜂
用户手机
互联网
应用程库客户端
图1电动自行车定位服务总体网络架构电动自行车定位服务包含以下功能实体：2
业务支撑系线
TiiKAoNiKAca
YD/T3011.1-2016
一应用平台：实现电动自行车定位服务中的用户管理、数据管理等，并提供定位、远程控制、信息查询及报警等业务的平台。根据部署情况，可单独设置业务支撑系统统一完成各类应用平台的公共用户管理和数据管理功能，在这种配置下应用平台主要提供业务功能。一业务支撑系统：网络中用于签约、计费和结算的系统。一第三方应用系统：由电动自行车定位服务应用平台运营方以外的组织机构建设和维护的，与应用平台进行信息交互的应用系统。业务网关：终端接入应用平台前，实现接入认证、协议转换和路由寻址的功能实体。一一短信网关：部署在运营商网络中实现用户手机与应用平台之间短信收发的应用平台。一电动自行车定位服务终端：安装在电动自行车上为其提供公共定位服务的设备。内置用户识别模块的终端，通过与电动自行车应用平台通信，协同实现电动自行车的定位、远程控制、信息查询和数据管理等功能。本标准中如无特别说明，终端均指电动自行车定位服务终端。用户手机：电动自行车用户与应用平台之间进行信息交互的移动通信设备。一应用程序客户端：安装在用户智能终端中用手与应用平台进行业务消息或管理消息交互的功能实体。
一移动通信网：应用平台与用户手机实现短信互通的网络以及应用平台与电动自行车终端进行数据通信的网络。这两种网络可以由同一运营商提供，也可由不同运营商提供。应用平台与电动自行车定位服务终端之间的业务流程：终端通过移动通信网络向应用平台发起连接请求，可通过业务网关与应用平台实现双向数据通信，也可直接与应用平台进行通信。应用平台与用户手机之间的业务流程：应用平台接收到终端的异常报警信息时，通过短信网关将该信息发送给用户手机：当用户需要对终端进行远程控制操作时，指令通过短信网关到达应用平台，由应用平台转发给相应的终端执行操作。6功能要求
6.1用户界面
应用平台应提供基于浏览器或应用程序客户端的用户界面。业务用户和管理用户应能使用浏览器或应用程序客户端接入系统6.2用户管理
应用平台应提供用户管理功能，包括对管理员用户和对业务用户的管理。6.3数据管理
应用平台应能够对用户信息数据及用户业务数据进行存储、查询和更新以及统计：若运营企业使用业务支撑平台对用户数据进行管理，则在应用平台中不作用户数据管理要求。应用平台应能对用户信息数据进行管理。用户信息数据包括：用户终端中SIM/UIM卡号码、用户终端内SIM/UIM卡对应的IMSI号码、终端提供商、终端序列号、与终端绑定的车主手机号码、车辆信息（如车牌号，车辆类型等），用户登录应用平台的账号等信息。应用平台应能对用户业务数据进行管理。用户业务数据包括：终端报警信息、终端当前位置信息和历史位置信息（定位时间、定位方式、车速）、终端设置警戒/解除警戒状态、应用软件版本号、备用电池电压、越界判断范围、定位追踪开启关闭状态、报警功能开启关闭状态等。业务平台对用户业务数据的保存期限应不少于3个月。
HiiKAoNiKAca
YD/T3011.1-2016
应用平台应能根据指定的条件对用户历史里程、报警信息进行查询和统计。6.4通信能力
6.4.1通信协议要求
应用平台应支持短消息以及YD/T2399-2012所规定的通信协议。6.4.2应用平台与终端之间的通信监控终端上报数据的接收：应用平台应能接收终端上报的业务数据，包括各种报警信息，位置信息、远程控制以及参数配置的操作结果信息：监控终端控制指令的下发：应用平台应能向终端下发远程控制指令，包括参数查询与配置、远程控制指令（如定位、重启等）：
应用平台应与终端之间建立心跳连接，监视终端的活动状态。6.4.3应用平台与用户手机之间的通信应用平台应能接收用户手机上报的短信，包括手机对终端的远程控制、参数配置及远程信息查询指令，用户的远程控制指令应通过应用平台接收后由平台发送相应的指令给终端，不能由用户手机直接将指令发给终端。
6.4.4应用平台与第三方应用系统之间的通信应用平台与第三方应用系统之间的通信包括：a）应用平台根据第三方应用系统的查询指令返回指定的用户数据。b）应用平台根据预先配置的策略周期性地向第三方应用系统上报数据。6.5管理要求
6.5.1管理员分级
应用平台的管理员应根据角色的不同分为超级管理员和普通管理员。超级管理员除具备业务管理功能外，还应具备对其他管理员账户进行创建、删除、权限分配的功能；普通管理员仅具备业务管理功能。6.5.2配置管理
应用平台应具备本地或远程配置功能，能够对应用平台的系统参数进行配置。6.5.3告警管理
应用平台应具备告警功能，能够对应用级以及系统级的异常事件进行告警。6.5.4系统日志
应用平台应能够保存系统关键事件日志，如管理员操作、用户数据处理等。7业务要求
7.1定位业务
用户应能通过手机或其他终端查询电动自行车当前的位置，应能通过应用程序客户端或短信的方式获取信息。
应用平台应能根据定位精度要求和卫星信号覆盖情况调用终端相应的定位功能：如果只要求进行卫星定位，则调用卫星定位功能；如果只要求进行Cell-ID（小区识别码）定位，则调用Cell-ID定位功能：如无特别要求，缺省优先调用卫星定位功能，在无法进行卫星定位时调用Cell-ID定位功能。应用平台可采用其他定位技术作为补充的定位手段，如WiFi定位、室内基站定位等。7.2信息查询
HiiKAoNiKAca
YD/T3011.1-2016
应用平台应支持信息查询功能，通过调用“定位能力”和“GIS信息能力”实现对一定时间段内轨迹的查询功能。信息查询功能应能对以下参数进行配置：一终端轨迹上报频率；
一采用的定位方式：
一轨迹的存储期限。
用户应能通过手机或其他终端查询电动自行车历史一段时间内的运动轨迹。信息查询功能应返回实时位置，如果当前位置不可知，则返回最近一次有效定位操作的位置值，并告知用户该有效定位的时间。
7.3远程控制
应用平台应支持远程控制功能，远程控制包括如下控制指令：一用户远程设置警戒、解除警戒：用户远程开启/关闭异常振动监测报警信息上报到应用平台：应用平台开启/关闭异常振动监测报警信息下发到用户手机：一用户远程开启/关闭断电报警信息上报到应用平台：一应用平台开启/关闭断电报警信息下发到用户手机：用户远程开启/关闭越界监测报警信息上报到应用平台：一应用平台开启/关闭越界监测报警信息下发到用户手机：用户远程开启/关闭定位信息上报到应用平台。7.4事件告警
用户应能通过手机接收应用平台转发的电动自行车异常事件，包括：监控器备用电池低电压：
异常振动：
一主电源断开：
一越界。
应用平台应能判断终端是否定时上报心跳，如发生心跳丢失的情况，则主动向用户手机发送终端异常事件告警，包括：
一正常工作状态下心跳丢失：
一休眠状态下心跳丢失。
8接口、协议和数据交互流程
8.1应用平台与电动自行车定位服务终端之间的接口8.1.1协议总体架构
应用平台与电动自行车定位服务终端之间的通信经过业务网关转发。业务网关为终端、应用平台提供多种通信方式的统一通信接入及鉴权，支持智能路由、能力开放、QoS管理、通信代理、话单生成等功能，是终端和应用平台之间的桥梁。业务网关的功能可使用单独网元实现，也可在应用平台侧实现。应用平台、业务网关及终端之间的通信协议栈结构如图2所示。5
HiiKAoNiKAca
YD/T3011.1-2016
业务网关与终端
之间的通信协议
TCP或UDP
底层网络承载较
业务网关
业务网美与终验
之阅的造们协议
业务网关与应用平
之同的通信协议
TCP或UDP
底层网络承载
图2应用通信协议栈结构
应用平台
业务网关与应用平台
之间的通信协议
TCP或UDP
底层网络承载
应用平台与终端之间的应用通信协议采用基于M2M应用通信协议的数据透传方式，其中终端与业务网关之间采用“业务网关与终端之间的数据透传协议”，应用平台与业务网关之间采用“业务网关与应用平台之间的数据透传协议”：对于业务网关在应用平台侧实现的方案，可考虑只采用“业务网关与终端之间的数据透传协议”进行数据透传。所需透传的数据采用“终端与应用之间的交互数据格式”进行封装。本标准只规定规定数据透传的实现方式，关于终端或应用平台的注册登录、连接检测等操作，见YD/T2399-2012。
8.1.2业务网关与终端之间的数据透传协议8.1.2.1协议概述
业务网关与终端之间的数据透传协议采用TCP/IP或UDP/IP协议承载，可采用短连接方式，也可采用长连接方式，采用长连接时，终端需定期向业务网关发送连接检测消息。8.1.2.2消息格式
业务网关与终端之间的数据透传协议消息由消息头和消息体构成，其结构如图3所示。起始
总长度命令代码
消息头(定长：28字节)(必选）
瀛水号
协议版本标识保留字终端序列号报文序号 重发改数
固定参数部分
消息体(变长：0-65507字节)
内客体(不定长）(可选）
可变TLV/TLV组部分
【部分TLV加密（可选）
全部内容体加密(可选)
摘要体（TLV(SMS除外）
摘要算法（计算内容）
报文头内容体 TimestampKey1 Key2Key3图3业务网关与终端之间的数据透传协议消息格式8.1.2.3消息流程
终端与业务网关之间的数据传输采用TRANSPARENTDATA及TRANSPARENTDATAACK消息进行数据透传。图4、图5所示给出了终端与应用平台之间的数据透传的流程。6
HiiKAoNiKAca
8.1.2.4消息定义
正常连接状态
业务网关
正常连接状态
发送数据给终端
平台接收应答
平台将数据组包发送至终端
数据包1(TRANSPARENTDATA）
数据包1响应（TRANSPARENTDATAACK)#源务
数据包n(TRANSPARENTDATA)
数据包响应（TRANSPARENTDATAACK）终端完成接收
终端完成接收
应用平台
YD/T3011.1-2016
有数据需要
发送至终端
应用平台确认应答
图4应用平台向终端数据透传
正常连接状态
终端向应用平台发送数据
业务网关
数据包I(TRANSPARENTDATA）
数据包1响应（TRANSPARENT_DATA_ACK）数据包n(TRANSPARENTDATA)
数据包n响应(TRANSPARENTDATAACK)正常连接状态
平台将数据组包
应用平台
发送终端上行的数据
应用平台接收应答
图5终端向应用平台数据透传
8.1.2.4.1TRANSPARENTDATA消息定义“TRANSPARENTDATA”双向上下行请求消息，用于实现端到端的应用数据连接，即终端或应用平台经由业务网关向对方发送应用数据请求。业务网关如果从终端收到该消息，则根据目的应用的业务代码来获取目的信息，把用户数据转发给相应目的应用：如果从应用收到该消息，则根据目的终端的序列号来分发信息到相应的终端。TRANSPARENTDATA消息格式定义见表1。表1TRANSPARENT_DATA消息格式定义字段名
必选TLV
字节数
本子包用户数据USERDATA部分的CRC16校验YD/T3011.1-2016
字段名
必选TLV
Destination
Address(EC
/TerminalID)
可选TLV
SUBBLOCK
USERDATA
安全TLV部分
0xE021
字节数
不定长
不定长
不定长
表1（续）
来源或目的地址(EC业务代码或终端序列号)：目的应用的业务码（TLV0x4014)目的终端的序列号（TLV0x4012）可选TLV，分包相关参数。
终端与应用之间的交互数据(TAG0x4007)注：当采用分包的时候，该字段将包含在SUBBLOCK(TLV0x4008)中接入验证摘要值：
摘要算法（消息+Timestamp+IMEI+IMSI+上下行接入密码）8.1.2.4.2TRANSPARENTDATAACK消息定义“TRANSPARENTDATAACK”双向上下行应答命令字，用于终端或业务网关向对方发送应用数据请求的应答。TRANSPARENTDATAACK消息格式定义见表2。表2TRANSPARENTDATAACK消息格式定义字段名
RESULT
安全认
证部分
安全TLV部分
0xE021
字节数
应答结果标识
0x00标识业务网关接收成功，CRC16校验成功，并转发Ox01，收业务网关接收成功，CRC16校验成功，但应用平台离线，转发失败Ox02台离业务网关接收成功，CRC16校验成功，但目的地址错误或非法，转发失败
0x03址错业务网关接收成功，CRC16校验成功，但请求方无权限，转发失败0x04无权业务网关接收失败，CRC16校验失败，数据无效Ox05——终端接收成功，CRC16校验成功0x066功终端接收失败，CRC16校验失败，数据无效接入验证摘要值：
摘要算法（消息+Timestamp+IMEI+IMSI+上/下行接入密码）8.1.3业务网关与应用平台之间的数据透传协议8.1.3.1协议概述
业务网关与应用平台之间的数据透传协议可采用短连接方式，也可采用长连接方式。对于短连接方式，应用平台通过登录与业务网关协商会话密钥，在应用平台退出登录之前，双方不必通过心跳维持连接。请求方通过HTTPREQUEST承载请求消息，应答方通过HTTPRESPONSE承载应答消息，随后即可断开连接，结束一次请求处理会话。在短连接方式下，双方的消息交互采用SOAP接口。SOAP是一个可运行在任何传输协议上的轻量级协议，但本协议要求将SOAP消息承载在HTTP上。本协议所定义消息承载在SOAP消息的soap:Body部分中。8
YD/T3011.1-2016
承载本协议的HTTP也可采用长连接方式，应用平台通过登录业务网关建立Socket连接（应用平台登陆业务网关需要协商会话密钥，流程见YD/T2399-2012），此后由业务网关向应用平台周期发送链路检测消息，应用平台返回应答，从而维持Socket长连接：如果连续N个链路检测消息无响应，可认为与业务网关的连接已经断开，发现端释放Socket链路，等待应用平台重新发起登录。在该长连接上的交互消息格式与短连接相同，此时协议消息直接承载在HTTPREQUEST与HTTPRESPONSE上，即协议消息作为XML格式内容，承载在HTTP报文的Content部分中。8.1.3.2消息格式
所有的协议数据单元PDU由如下的消息头和消息体组成：PDU组成
Message Header
MessageBODY
Message HASH
消息头、消息体和消息摘要在xml文件中的格式形式如下：

消息头属性一消息头属性二消息头属性三/Head>
加密后的消息体
消息摘要

未加密的消息体也是一个完整的xml文件，格式如下：消息体属性一消息体属性二消息体属性三描述
消息头
消息体
消息摘要
本标准中消息为文本格式，对于二进制内容，应进行BASE64编码。加密后的消息体通过BASE64编码放入BODY标签。8.1.3.3消息流程
业务数据透传分为应用平台发起的下行业务数据，以及终端发起的上行业务数据。下行消息流程如图6所示。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。