杭州市居所出入(智能门禁)服务管理平台接入规范v05.docx

杭州市居所出入（智能门禁）服务管理平台接入规范

（V 1.0.5）

2015年10月

目录
1 背景目标 3
1.1 项目背景 3
1.2 项目目标 3
1.3 适用范围 3
2 规范性引用文件和术语定义 4
2.1 规范性引用文件 4
2.2 术语定义 5
3 第三方接入规范 6
3.1 接入原则 6
3.2 接入流程 6
3.2.1 接入流程图 6
3.2.2 设备接入流程 7
3.2.3 平台接入流程 11
4 第三方接入接口协议 14
4.1 设备接入接口协议 14
4.1.1 设备接入要求 14
4.1.2 设备管理机制 15
4.1.3 设备通信机制 19
4.1.4 通信协议 24
4.1.5 协议字段定义 68
4.2 平台接入接口协议 83
4.2.1 协议概述 83
4.2.2 通讯方式 85
4.2.3 接口协议 85
4.2.4 数据安全 85
4.2.5 报文总体格式 85
4.2.6 业务接口 89

1 背景目标
1.1 项目背景
我市流动人口的涌入，不仅为杭州城市建设、经济发展提供了充足的人力资源，做出积极的贡献，但与此同时，流动人口的大量聚集以及流动性和不确定性，给城市带来了社会治安、文化教育、计划生育等一系列管理难题。依据《涉密略》（浙委办〔2014〕5号）、《涉密略》（杭委办〔2014〕75号）、《杭州市流动人口服务管理条例》、《杭州市人民政府办公厅关于组织申报杭州市2014年政府系统政府投资信息化建设项目的通知》、《关于印发“智慧杭州”建设总体规划(2012-2015)的通知》等条例和文件要求，提出流动人口动态信息（居所出入智能门禁）管控平台建设需求。

1.2 项目目标
以动态信息中的“住”信息采集为目标，采用物联网技术，通过居所智能门禁前端对流动人口相关信息的实时和动态采集，建立流动人口“住”信息数据库，通过对本项目平台的建设及应用，提高流动人口居所的安全性，规范流动人口信息采集的流程，促进流动人口居住信息登记质量，提升政府相关部门服务管理水平。

1.3 适用范围
本《规范》是杭州市居所出入（智能门禁）服务管理平台（以下简称“市平台”）的接入规范指导，是杭州市范围内各类智能门禁系统的数据、设备接入市平台基本依据。
本《规范》适用于杭州市范围内所有已建智能门禁项目改造和新建智能门禁项目。
本《规范》适用于杭州市范围内具有智能门禁管理要求的住宅小区、出租屋、企业以及其他形式的社区和场所，包含老旧居所改造、新建居所等场景。

2 规范性引用文件和术语定义
2.1 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。本规范引用的文件均不注日期，其最新版本适用于本标准。
DB3301/T0007 流动人口信息 居所出入服务管理系统建设规范
GB/T 2260 中华人民共和国行政区划代码
GB/T 2261.1 人的性别代码
GB/T 3304 中国各民族名称的罗马字母拼写法和代码
GB/T 4766 婚姻状况代码
GB/T 10114 县级以下行政区划代码编制规则
GB/T 14916 识别卡 物理特性
GB/T 16260 软件工程 产品质量
GB/T 22239 信息安全技术 信息系统安全等级保护基本要求
GB/T 23705 数字城市地址信息公共平台地名/地址编码规则
GB/Z 28828 信息安全技术 公共及商用服务信息系统个人信息保护指南
GB 50348 安全防范工程技术规范
GB 50396 出入口控制系统工程设计规范
GA 56.2 暂住人口基本信息管理标准
GA 374 电子防盗锁国家标准

2.2 术语定义
下列术语和定义适用于本规范。
1、 流动人口
指在本市区居住的非本市区户籍的人员，以及其他县（市）居住的非本县（市）户籍的人员，不包括境外人员。
2、 流动人口居所出入信息
主要包括流动人口姓名、性别、民族、出生日期、公民身份号码、户籍地址、现居住地址、历史居住记录、实时开门记录等信息。
3、 流动人口综合信息平台
在专网或VPN上运行，汇集、整合城乡建设、公安、民政、人力社保、教育、计生等部门采集的流动人口信息，并实现共享的信息系统。
4、 流动人口居所出入服务管理系统
流动人口居所出入服务管理系统由居所出入平台、传输网络、前端设备、出入卡、密钥管理系统等部分组成，以下简称“居所出入系统”。
5、 居所出入平台
在专网或VPN上运行的信息系统，具有流动人口居所出入信息采集、管理、应用和居所出入卡管理、用户权限分类设定和管理、报警管理等功能。
6、 前端设备
指特定用于流动人口居所出入信息采集，由识读设备、管理控制设备、执行设备和传输设备等组成的安装在门端的设备集合。
7、 居所出入卡
指应用于居所出入系统，具有个人信息存储、门禁认证及附加应用功能的非接触集成电路卡，以下简称“出入卡”（包含集成居所出入功能的“市民卡”等）。

3 第三方接入规范
3.1 接入原则
1、 已建设项目
杭州市范围内需要接入市平台的所有已建设完成的智能门禁项目，使用现有平台接入市平台，依据规范上传数据至市平台。
2、 建设中项目
杭州市范围内需要接入市平台的所有建设中的智能门禁项目，根据项目建设情况，酌情选择使用平台接入或者设备直接接入市平台，依据规范上传数据至市平台。
3、 待建设项目
杭州市范围内需要接入市平台的所有待建设的智能门禁项目，使用门禁设备或平台直接接入市平台，依据规范上传数据至市平台，同时使用市平台实现逐级管理相关门禁设备。

3.2 接入流程
3.2.1 接入流程图

3.2.2 设备接入流程
3.2.2.1 接入申请提交、审核

1、 申请资料提交
杭州市范围内需要使用门禁设备直接接入市平台的智能门禁项目，项目业主或者承建单位需要书面提交接入申请和相关资料，资料包括但不限于：接入申请书、项目概况、项目周期、承建单位概况、接入技术实现方案、接入规模、联系人、联系方式等。
2、 市平台承建单位验证测试
市平台承建单位根据接入申请资料中技术方案对接入方案进行验证测试，出具验证测试报告提供市流口办参考。
3、 市流口办审核
市流口办依据相关规范流程、接入申请资料和验证测试报告对接入方进行审核。
4、 发布审核结论
市流口办对接入方审核完成后，通过规定的途径发布审核结论，对于审核通过的接入方，分配接入所需的市平台账号密码、厂商代码等资料，对于审核未通过的接入方，反馈相关问题给接入方，督促尽快完善相关资料。

3.2.2.2 接入调试、评估

1、 接入方产品开发
接入方依据市平台接入规范相关要求开发待接入市平台的产品。
2、 技术联调
接入方产品开发完成后，依据市平台接入规范相关要求与市平台承建单位进行技术联调，确认产品各项参数是否符合要求，是否能够正常的接入市平台。
3、 接入产品完善
若接入方产品经过联调，发现相关问题影响产品接入市平台，需对产品进行完善。
4、 接入试运行
接入方认为产品完全满足市平台接入规范相关要求，同时确认产品可正常稳定的接入市平台后，接入方选取一定数量的产品接入至市平台试运行一段时间（具体试运行数量和时间由市流口办确定）。
5、 市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对接入方进行验证测试，并出具验证测试报告供市流口办参考。
6、 市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对接入方进行评估，并通过规定的途径发布评估结果，对于评估通过的接入方，流口办书面下发准入证明，准予正式接入市平台，对于评估未通过的接入方，反馈相关问题给接入方，督促尽快完成技术整改。

3.2.2.3 正式接入、定期评估

1、 正式接入
接入方依据市平台接入规范相关要求，提供接入产品的详细信息，包括但不限于：出品商、生产日期、产品序列号、产品MAC地址等，接入方接入相关产品时，市流口办或者市平台承建单位依据相关信息，验证每一个接入市平台产品的合法性。
2、 流口办定期发起评估要求
在市平台正常运行期间，流口办可定期发起接入产品评估要求，抽查若干产品进行评估，确保所有接入产品符合市平台接入规范。
3、 市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对抽查产品进行验证测试，并出具验证测试报告供市流口办参考。
4、 市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对抽查产品进行评估，并通过规定的途径发布评估结果，对于通过评估的产品接入方，流口办书面下发验收通过报告，对于未通过评估的产品接入方，暂停其接入资格，反馈相关问题给接入方，督促尽快完成技术整改。

3.2.3 平台接入流程
3.2.3.1 接入申请提交、审核

1、 申请资料提交
杭州市范围内需要使用现有平台接入市平台的智能门禁项目，项目业主或者承建单位需要书面提交接入申请和相关资料，资料包括但不限于：接入申请书、项目概况、项目周期、承建单位概况、接入技术实现方案、接入规模、联系人、联系方式等。
2、 市平台承建单位验证测试
市平台承建单位根据接入申请资料中技术方案对接入方案进行验证测试，出具验证测试报告提供市流口办参考。
3、 市流口办审核
市流口办依据相关规范流程、接入申请资料和验证测试报告对接入方进行审核。
4、 发布审核结论
市流口办对接入方审核完成后，通过规定的途径发布审核结论，对于审核通过的接入方，分配接入所需的接口地址、接口账号密码、厂商代码等资料，对于审核未通过的接入方，反馈相关问题给接入方，督促尽快完善相关资料。

3.2.3.2 接入调试、评估

1、 接入方平台改造
接入方依据市平台接入规范相关要求对待接入市平台的平台进行改造，新增市平台接入相关功能。
2、 技术联调
接入方平台改造完成后，依据市平台接入规范相关要求与市平台承建单位进行技术联调，确认平台各项功能是否符合要求，是否能够正常的接入市平台。
3、 接入产品完善
若接入方平台经过联调，发现相关问题影响平台接入市平台，需对平台进行完善。
4、 接入试运行
接入方认为平台完全满足市平台接入规范相关要求，同时确认平台可正常稳定的接入市平台后，接入方将平台接入至市平台试运行一段时间（具体试运行时间由市流口办确定）。
5、 市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对接入方进行验证测试，并出具验证测试报告供市流口办参考。
6、 市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对接入方进行评估，并通过规定的途径发布评估结果，对于评估通过的接入方，流口办书面下发准入证明，准予正式接入市平台，对于评估未通过的接入方，反馈相关问题给接入方，督促尽快完成技术整改。

3.2.3.3 正式接入、定期评估

1、 正式接入
接入方依据市平台接入规范相关要求，提供接入平台的详细信息，包括但不限于：出品商、公网IP、服务器网络MAC地址等，接入方接入相关平台时，市流口办或者市平台承建单位依据相关信息，验证每一个接入市平台的平台合法性。
2、 流口办定期发起评估要求
在市平台正常运行期间，流口办可定期发起接入平台评估要求，抽查若干平台进行评估，确保所有接入平台符合市平台接入规范。
3、 市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对抽查平台进行验证测试，并出具验证测试报告供市流口办参考。
4、 市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对抽查平台进行评估，并通过规定的途径发布评估结果，对于通过评估的平台接入方，流口办书面下发验收通过报告，对于未通过评估的平台接入方，暂停其接入资格，反馈相关问题给接入方，督促尽快完成技术整改。

4 第三方接入接口协议
41 设备接入接口协议
4.1.1 设备接入要求
4.1.1.1 设计原则与目标
简化通信协议形式（减少冗余）
节约GPRS流量
数据安全
可扩展性
兼容Internet/GPRS方案
4.1.1.2 物理连接
GPRS/3G网接入
宽带接入
4.1.1.3 通信方式
TCP短连接，承载业务命令
UDP长连接，实现唤醒通知机制（可选）
SMS短信通道，实现唤醒通知机制（可选）
UDP高速数据通道
4.1.2 设备管理机制
4.1.2.1 设备状态管理
4.1.2.1.1 主控器状态
主控器的工作状态可以从uploadStatus或者queryStatus等指令中获得，工作状态是一个字节，0代表主控器正常工作，其他数字代表异常状态码
主控器的联机状态，主要由唤醒通道的可用性和TCP安全信道的可用性两者组成。假设用1个字节来表达联机状态。
Bit0-bit3：
低半字节代表主控器唤醒通道（UDP/短信）的可用性
0000 代表不可用
0001 代表短信通道可用
0010 代表UDP通道可用
Bit4：
是否建立了TCP安全信道连接
0代表NOT CONNECTED
1代表CONNECTED
如果主控器异常无法连接中心服务器（比如主控器断电、无法上网等），服务器是没有办法主动得知这种状态的。所以只能设定主控器定期上传一个“活跃”事件，当服务器超出一定时间后没有获得“活跃”事件，就可以标记这一主控器处于异常状态，以便发出告警，让管理人员人工干预（比如现场检查）。
4.1.2.1.2 门锁状态
门锁的状态，包括门锁的联机状态（是否与主控器正常的建立了连接），门锁自身的工作状态、门锁电池电量、温度等参数组成。
门锁没有TCP连接状态，但是和主控器一样，也要根据最后一次状态更新的时间戳，如果长时间没有更新状态，则可以判定门锁异常。
4.1.2.2 设备密钥管理
4.1.2.2.1 主控器密钥
在主控器上保存了多组密钥，每组密钥做不同的用途。
密钥编号
算法类型
长度
密钥用途
使用频率
（无）
DES/3DES
16
临时会话密钥，在建立TCP安全信道的时候协商产生，不允许通过SetupKey指令修改
频繁
0x01
DES/3DES
16
认证密钥，在建立安全通道的时候使用，用于客户端和服务端相互认证身份。允许通过SetupKey指令修改。
中
0x02
DES/3DES
16
DEK密钥，加密敏感数据，在SetupKey指令中，用于加密新密钥。允许通过SetupKey指令修改。
低
0x03
DES/3DES
16
短信通知密钥，只能用于加密唤醒通知短信
中

16字节的密钥，在DES运算中，只取用前8字节。
4.1.2.2.2 PSAM卡密钥
PSAM卡上保存了SM1加解密用的SM1密钥，具体细节参考PSAM卡规范。
4.1.2.2.3 临时会话密钥
临时会话密钥在TCP安全信道建立的时候协商而来，只有在session生命周期内有效。
4.1.2.3 时间同步机制
主控器与门锁等设备有时需要相对精确的时间，为了获得标准时间，本协议提供两种时间同步机制。
1、 通过在主控器上配置公共NTP/SNTP服务器地址，从INTERNET上获得标准时间。
2、 提供一种简单的内部校时机制，从协议服务器上获得时间。
如果允许的话，建议使用公共NTP/SNTP服务器做时间同步。第二种内部较时方案只是作为备选。
内部较时的原理如下：
服务器提供一条获取时间的指令。假设客户端，在本地时间a这个时间点上，发出读时间指令，在本地时间点b获得了指令放回，返回值是服务器时间值x；假设客户端与标准时间（即服务器时间）相差Δt（即标准时间=客户端时间+Δt）。那么：
指令上行延迟Δup = x - (a+Δt)
指令下行延迟Δdown = (b+Δt) - x
指令总共消耗的时间是Δtotal =Δup +Δdown = b - a
上下行延迟主要决定于网络延迟，上下行延迟的比例主要决定于网络延迟网络上下行速率比例，这一参数和具体的网络状况有关，比如GPRS一般下行速率比上行速率大。
假设比例参数 k =Δdown/Δtotal，在同一时段、同一网络环境下是一个相对稳定的数字。
k =Δdown/Δtotal = ((b+Δt) - x) / (b - a)
Δt = x - b + k * (b - a)
k的取值范围在(0, 1)区间内，考虑极限值：
k = 0的情况下：Δt_min = x - b
k = 1的情况下：Δt_max = x - b + (b-a) = x - a
在延迟很小的情况下（例如b-a <= 2秒），如果时钟精度允许，可以取常量 k = 0.5，则：
Δt ≈ x - (b + a) / 2
上下误差不超过 (b - a) / 2。
如果延迟大，时钟精度要求更高，还可以连续多次采样，根据短时间内比例参数相对稳定的原理设计算法，使得Δt的误差更小，具体流程算法不在本协议约束范围之内。
为了减少误差，读时间指令的请求和回复，应该以明文方式传输，不加密，协议服务器在这条指令的处理上应该提高处理优先级。
4.1.2.4 拍照器管理机制
拍照器根据来源于门锁（门锁联动）、红外感应、或者用户手动拍照命令等事件，触发一次连续的拍照动作，产生一组照片文件的过程，称为一次拍照事件。照片文件存储在拍照器的存储空间（如SD卡）内，照片文件的文件名遵从以下规则：
文件名：T-yyyyMMdd-hhmmss-NN.jpg
T为拍照事件类型（1个字符），目前的定义
A 正常场景拍照（比如刷卡开门）
U 用户（从管理平台发起）手动拍照
W 强行闯入拍照
yyyyMMdd-hhmmss是拍照事件发起的时间戳，单位精度到秒。
NN为照片序号（十进制数字），同一组照片中的第一张照片序号为01，第二张序号为02，以此类推。特殊序号00代表这组照片的缩略图。
当存储空间内剩余空间不足时，优先自动删除7天以前最老的正常场景照片，如果还不足，再删除7天以前最老的手动拍照照片，如果空间还是不足，分两种状况：第一种，如果即将拍摄的强行闯入类的照片，则可以删除最老的强行闯入照片，以重用存储空间；如果不是强行闯入类的照片，则提示拍照失败（通过返回告警等方式，如果是用户平台手动拍照，可以返回错误码）。
每张照片上都应该有时间戳水印（实际拍照时间，而不是策略发生时间），如果可以的话，最好还要打上地址水印，如“XXX小区5单元楼道”，此地址信息通过SetupParameter配置到终端上。
4.1.3 设备通信机制
4.1.3.1 短链接链路超时与持续机制
TCP安全信道上，如果在N分钟内没有数据，则认为链路超时，服务器或者客户端应该自动断开此连接。一般约定超时时间N = 3分钟，但是不做强制要求。
为了延长链路持续时间（比如某条指令请求需要花费比较长的时间去执行），客户端可以发送特殊报文0x0002，以避免超时，服务端收到这个特殊报文后，除了标记时间戳，延长等待时间外，不做任何回复。
4.1.3.2 数据报文中转机制
如果超过2方的节点之间需要进行中转

4.1.3.3 避免GPRS拥堵机制
在繁忙时段，主控器可以通过hash分时机制，减少GPRS拥堵的几率。繁忙时段的判定有两种，一种是通过SetupParameter，在主控器上设定已知的繁忙时段，另一种是主控器尝试建立GPRS（TCP/UDP）连接超过2次出错，则自动当作繁忙时段。
类似于“强行闯入告警”之类优先级比较高的控制命令，不强制要求按照分时算法的限制。
Hash分时机制，是对主控器地址计算hash值，以此为依据，设计分时算法。
TODO：分时原理
4.1.3.4 通用命令应答机制
一般的业务指令都是由请求/回复构成。请求和回复通过4字节的指令流水号配对。请求发起方生成新的指令流水号。响应方使用这个流水号产生回复报文。
回复报文中的指令码为原请求报文指令码的最高bit置1，如请求指令0x01的回复报文中指令码为0x81。
回复报文中除了流水号外，还有错误状态编码。在本规范中，除了状态码0代表成功外，其他数值都是错误编码。
4.1.3.5 TCP安全通信机制
通信节点之间，通过TCP安全信道，来保证报文传输的安全性。
一次安全信道的会话（session），有以下几个属性：
1、 会话ID（sessionId）由服务器生成的8个字节的数组，用来唯一标识某个安全信道会话。此数据属于公开数据，允许在网络上以明文方式传输。
2、 会话数据加密算法时所使用的对称算法类型，如DES/3DES等，由通信双方约定。
3、 会话密钥（sessionKey）。由通信双方在初始化（建立安全信道）的流程中协商得到。这个数据是属于隐私数据，由通信双方各自保存，不会在网络上以明文的方式传递。会话密钥的长度是16个字节，如果加密算法是DES，则实际使用中，只采用前8字节。
4、 对于短连接，会话持续及超时时间，一个安全信道会话建立后，空闲等待30分钟后超时失效。
4.1.3.6 建立安全信道会话
Step 1. 建立TCP连接后，服务器告知客户端，自己支持的最高协议版本号，并生成通信随机数
(S-->C) WELCOME:
version 服务器支持的最高协议版本号
random1 服务端随机数 8 bytes
Step 2. 客户端选定协议版本号，生成随机数，发送INIT命令给服务器
(C-->S) INIT_REQ:
DUID, 客户端设备唯一识别码
random2, 客户端生成的随机数 8 bytes
version 协议版本号
authenticateData 客户端认证数据（根据random1计算）
(S-->C) INIT_RESP:
status 错误码（0代表成功）
authenticateData 服务端认证数据（根据random2计算）
sessionId 会话Id，8字节
* 约定临时会话密钥sessionKey的生成算法：使用认证密钥（主控器上存储的密钥编号为0x01）对明文数据 ((random1 xor random2) + (byte)0x12 + (byte)0x28+ 6个(byte)0x00) 进行3DES_CBC加密，生成16字节结果，作为临时会话密钥。
* 客户端认证数据的生成算法：
第一步，使用会话密钥对明文数据 (random1 + (byte)0x13 +(byte)0x29 + 6个(byte)0x00 +8字节的设备唯一识别码) 进行进行3DES_CBC加密（如果输入数据长度不足8个字节的整数倍，则填充0x00）
第二步，将第一步的输出结果，做MD5哈希计算，输出的16个字节作为客户端认证数据数据。
* 服务端认证数据的生成算法：
第一步，使用会话密钥对明文数据 (random2 + (byte)0x14 +(byte)0x30 + 6个(byte)0x00 +8字节的设备唯一识别码) 进行进行3DES_CBC加密（如果输入数据长度不足8个字节的整数倍，则填充0x00）
第二步，将第一步的输出结果，做MD5哈希计算，输出的16个字节作为客户端认证数据数据。
客户端和服务器端双方相互认证合法性后，session正式建立。
4.1.3.7 重用安全信道会话
在会话有效期内，会话可以重用。
Step 1. 建立TCP连接后，服务器告知客户端，自己支持的最高协议版本号，并生成通信随机数
(S-->C) WELCOME:
protocolVersion 服务器支持的最高协议版本号
random1 服务端随机数 8 bytes
Step 2. 客户端跳过INIT命令，直接发送控制命令，同时携带session验证数据。
(C-->S) COMMAND WITH SESSION_DATA ：
sessionId 会话Id，8字节
authenticateData 客户端认证数据（对random1进行加密，以供服务器验证合法性）
(S-->C) COMMAND RESPONSE:
status 错误码（0代表成功）
如果sessionId过期或者非法，status提示ERROR_INVALID_SESSION。客户端应该重新走INIT流程，建立安全通道后，重发这个控制命令。
4.1.3.8 SM1-LV分组机制
假设分组长度为N，加密过程是：首先把原始数据切分成长度为(N-1)的一个个分组，在每组数据前面加上本组长度字节L，分别进行SM1_ECB运算，如果长度不足，填充80 00 00 ...；再把各组加密结果拼接在一起就组成了加密输出。
解密过程则相反：首先把密文数据切分成长度为N的一个个分组，分别进行SM1_ECB解密，去除头一个字节L后，去除填充字节，把有效数据拼接组成原始明文。
一般分组长度N=192 (0xC0)。
4.1.3.9 CRC算法
协议中使用到了CRC16/CRC32算法。
CRC16使用多项式：
1 + x^2 + x^15 + x^16
CRC32使用多项式：
1 + x + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 + x^12 + x^16 + x^22 + x^23 + x^26
样例：
CRC16("123456789"): bb3d
CRC32("123456789"): cbf43926

4.1.4 通信协议
4.1.4.1 通信协议格式定义
4.1.4.1.1 数据类型
Integer
指定长度的无符号字节数，采用网络字节序（Big Endian）编码
String
由可读字符组成的字符串
Bytes
固定长度的字节数组
TLV
简单TLV数据对象
Bits
比特位。bit0代表最低位，bit1...bit7依次，Bit8是第二字节的最低位，以此类推。
TLV格式采用“简单TLV数据对象”的约定：
—— 标记字段T由1个字节或2个字节组成，一个字节的Tag取值范围0x01-0xEF，两个字节Tag，前一个字节取值范围0xF0-0xFE，后一个字节的取值范围是0x00-0xFF。首字节0xFF保留做扩展用途
—— 长度字段由1个字节或3个连续字节组成。如果长度字段的首字节处于从‘OO’至‘FE’的范围内，则长度字段由单个字节组成，该字节编码从0至254中的一个整数L。如果首字节等于‘FF’，则长度字段后续2个字节使用从0至65535中的值编码了一个整数L。
——如果L不为空，则值字段V由L个连续字节组成。如果L为空，则数据对象为空:不存在有效字段。
4.1.4.1.2 安全报文格式
通用安全报文格式
字段名
长度
描述
必选/可选
Packet Length
2
报文总长度（包括自身）
M

报文头
Head Length
1
头长度（包括自身，从Head Length到Head Extension的长度）
M
SPI
1
SPI
M
PADDING
1
加密填充字节数，如果有加密，则存在此字段
O
CRC
2
CRC16校验值
O
Head Extension
X
多个TLV构成的报文头扩展数据（明文）
O

User Data
X
多个TLV构成的用户数据（或其密文）
M

4.1.4.1.3 SPI字段编码
b7
b6
b5
b4
b3
b2
b1
b0
RFU
是否存在CRC16字段
0：不存在
1：存在

密钥选择
00：默认密钥
01：指定密钥1
10：指定密钥2
11：其他密钥（保留用作扩展用途，比如可以在头扩展里面指定密钥）

用户数据的加密方法
000：不加密
001：用DES-CBC加密
010：用3DES-CBC加密
011：用SM1-CBC加密
100：用SM1-LV分组加密，分组长度为192字节（ECB）
其它数值保留

默认密钥在TCP安全会话中，指的是临时会话密钥。指定密钥由通信双方约定，比如对于主控器而言，密钥1代表了主控器上存储的通信密钥，其他值暂时不用。
在支持SM1加密的门锁上（由PSAM卡提供SM1算法API），默认密钥代表PSAM卡内存储的加密密钥。
在短信通道上，默认密钥代表短信通知密钥（密钥类型03）

4.1.4.1.4 CRC校验
采用CRC32或者CRC16算法，对原始用户数据UserData（不包括填充字节）明文进行校验。除非对字节数极端敏感（比如门锁和主控器之间，需要控制通信的包长度和数量，以节约电池电量），否则建议用CRC32。
4.1.4.1.5 报文头扩展
报文头扩展数据必然是明文的，不参与加密。只有一些特殊参数才需要放在报文头扩展里面，比如在重用安全会话时声明sessionId等。本文中需要放在报文头扩展中的特殊参数，会专门指出，没有做专门声明的可选或者必选参数，都是作为用户数据存在的。

4.1.4.1.6 填充与校验
安全报文的组包过程，先计算明文的CRC，再填充字节0，再加密。
4.1.4.1.7 welcome报文格式
Welcome报文是服务器发给每一个刚刚建立TCP连接的客户端的，不需要回复，不包含敏感数据，所以建议SPI = 0，不需要CRC校验，也不需要加密。
报文参数（放在用户数据）：
Tag
Length
描述
必选/可选
M_request
1
commandID = WELCOME，无流水号
M
M_version
1

服务器支持的最高协议版本号，版本号的高半字节代表主版本号，低半字节代表次版本号（下同）
M
M_random
8
服务器生成的随机数
M

4.1.4.1.8 重用信道报文格式
主控器建立TCP连接以后，第一个上行控制命令中，在头扩展里面，携带以下信息，可以实现重用安全信道会话。
头扩展参数：
Tag
Length
描述
必选/可选
M_sessionId
8
要重用的会话ID，服务器可以用这个会话ID，获得对应的设备地址。
M
M_authData
16
客户端认证数据 *
M
4.1.4.2 上行控制命令
主控器发给服务器的控制命令称为上行命令。
4.1.4.2.1 会话初始化
初始化命令用于主控器建立安全通道会话。这条指令的请求报文是明文数据（不加密）。如果认证通过，则回复报文用协商出来的会话密钥加密（客户端以此验证服务器端的合法性）；如果认证失败，则回复报文已明文数据返回。
命令名称：Initialize Session
请求参数：
Tag
Length
描述
必选/可选
M_request
5
指令+流水号
commandID = INITIALIZE
M
M_version
1
协议版本号
M
M_random
8
客户端生成的随机数
M
D_DUID
8
设备唯一识别码
M
M_authData
16
客户端认证数据 *
M
回复参数：
Tag
Length
描述
必选/可选
M_response
6
指令+流水号+错误码
M
M_sessionId
8
会话ID，如果不成功，此字段不存在
O

注1：临时会话密钥sessionKey的生成算法
注2：客户端认证数据算法
注3：M_features客户端支持的特性
主控器是否支持DES/3DES加密
主控器是否支持SM1加密
是否支持UDP唤醒通道
是否支持短信唤醒
门锁是否支持SM1加密

4.1.4.2.2 时间同步
时间同步命令提供了一种精度到秒的简单时间同步机制，将中心服务器作为主控器时间同步的源。具体的原理和算法，参考“时间同步机制”这一章节的描述。这条指令的请求和回复报文都是明文（不加密）。
命令名称：Time Synchronize
请求参数：
Tag
Length
描述
必选/可选
M_request
5
指令+流水号
commandID = TIME_SYNC
M
回复参数：
Tag
Length
描述
必选/可选
M_response
6
指令+流水号+错误码
M
M_time
4
时间，与UTC时间1970年时间差，以秒为单位
M

4.1.4.2.3 上线通知
控制器发给服务器的设备上线通知。设备上线，或者重启时，需要发送此通知命令。
在没有UDP长连接通道的情况下，主控器定期更新服务器上的设备工作状态，也可以用这条命令。
服务器通过短信或者UDP通道唤醒主控器，主控器如果要重用安全信道会话，并且没有其他的控制命令要上传的话，也可以用这条命令做为建立TCP连接后的第一条控制命令。（携带sessionId及认证数据）
命令名称：Online Notify
请求参数：
Tag
Length
描述
必选/可选
M_request
5
指令+流水号
commandID = ONLINE_NOTIFY
M
[D_deviceInfo]*
x * n
设备描述信息
M
回复参数：
Tag
Length
描述
必选/可选
M_response
6
指令+流水号+错误码
M

D_deviceInfo详细数据（子TAG）：
Tag
Length
描述
必选/可选
D_code
2
设备编码
M
D_workStatus
1
设备工作状态
0：正常工作
1：脱机
2-0xff：其他异常状态码
O

4.1.4.2.4 状态上传
控制器主动上发设备（包括主控器自身及门锁、传感器等子设备）状态信息的命令。
门锁、传感器等子设备状态由控制器采集并保存，关键状态变更通过Upload Status命令主动上传。设备的各个状态字段作为可选项目，可以只上传数值变更的字段。
命令名称：Upload Status
请求参数：
Tag
Length
描述
必选/可选
M_request
5
指令+流水号
commandID = UPLOAD_STATUS
M
[D_statusInfo]*
x * n
设备状态信息
M
回复参数：
Tag
Length
描述
必选/可选
M_response
6
指令+流水号+错误码
M

请求报文中D_statusInfo的详细数据和设备类型有关系。
主控器的设备状态
Tag
Length
描述
必选/可选
D_code
2
设备编码，0代表主控器自身
M
M_time
4
状态采集时间
M
D_workStatus
1
设备工作状态
0：正常工作
1-255：其他异常状态码
O
D_version
2
主控器程序版本号，高字节代表主版本号，低字节代表次版本号，下同。
O
D_hardware
2
主控器硬件版本号，高字节代表主版本号，低字节代表次版本号，下同。
O
L_battery
1
主控器备用电池电量
O
L_gsmSignal
1
GSM信号(1-99)
O
L_networkMode
1
网