Zigbee下行协议.docVIP

下行协议及设备协议 1.概述 术语定义： 中控下行协议： Server的业务程序发往适配器的协议称为中控下行协议。 设备下行协议： 适配器通过RS232/USB至各网关的协议称为设备下行协议。 设备协议： 网关至各节点的协议称为设备协议。例如CAN协议，zigbee协议等。 不管是何种网关，Server与其通信的下行协议均使用相同的格式；根据传输介质的不同，设备协议则随之不同。通常一个节点控制多路硬件（比如8路红外发射或双路开关），每路硬件在该节点中均存在一个唯一的通道号；同时每路硬件也提供一个或多个功能供用户操作（比如LED调光硬件提供开、关、调光三个功能），每个功能在该节点中存在一个唯一的操作功能号。对于某些操作功能，还需要一些额外的参数（比如调光操作功能，还需要最大亮度的相对值）。 图1：术语定义 功能界定：适配器与节点完成发送、接收的分片、重组，网关只实现简单的透传，后续如有必要，再实现分片、重组。超时则同时在适配器、网关中完成，其中适配器的超时时间比网关略长（原因为拓朴类似于分布式架构，存在一致性问题）。适配器对于不同的网关的发送、接收超时时间可不相同。 发送时，Server根据中控下行协议将报文发送至适配器，适配器如有必要则先分片，将报文通过RS232/USB发送至网关，网关将报文发送至节点后，需要回应适配器发送成功/失败。当一定时间内网关无法将报文发送至目的节点，需要取消报文的发送，并应答适配器发送超时。考虑到在此过程中，网关有可能出现故障，因此适配器也必须启动定时器，以判断报文是否发送超时。当适配器收到网关的ACK报文后，继续发送下一个报文。当适配器收到网关的NAK或超时后，取消后续分片报文的发送，启动下一个完整报文的发送。 Server发送报文时，由于其承载内容为应用层报文，必然保序到达目的节点。由于节点的处理能力及设备协议栈原因，Server往同一个目的节点发送报文时，采用“发送、等待”的模式，Server必须收到网关的应答报文或者自身发送超时后，才允许下一个报文的发送。对于不同的目的节点，目前可同时发送。后续如碰以TCP等保序的协议栈，再增加同时发送至相同目的节点的功能。 Server发往适配器的中控下行协议格式参见下图：SOF用于同步并表明新的一帧；MAC指目的节点地址，对于不同的网关其使用的长度并不相同（比如CAN最多只需29bit，ZigBee为8字节，IP报文为4字节，以太网为6字节，为方便起见，统一为8字节，每种协议使用哪个bit及其字节序由协议自行定义即可），Control Field为控制域，表明上层对网关发送该报文的控制信息（比如单播、组播、广播、透传等等），Length字段包含了后续DATA及CRC16的长度总和（每种协议可自定义其一帧的最大Length值）： 图2：中控下行协议报文格式 Control Field域的格式参见下图,，链路层和应用层确认标志ACK，ACK=0000b网关肯定回答中控机，其它为网关的链路层否定回答，ACK=1000b节点的应用层肯定回答，其它为节点应用层否定回答；报文方向DIR，DIR=0，报文发起方，DIR=1，报文响应方。SOF、MF，用于指示设备节点的重组信息；SOF、MF的组合如下：SOF=1表示新的一帧，MF=1表示后续有分片帧，有效组合如下：10：新的一帧无分片；11新的一帧后续有分片；00：当前帧后续无分片；01：当前帧后续有分片；packet type表明该报文的发送方式（单播、广播或组播，目前一般为单播或广播）；transparent indicator表示该报文的接收者是接收处理或是透传(CAN/ZigBee互换)；目前该bit必然是接收处理，后续需要网关转换传输介质时，才引入透传功能，其它位预留： 图3：Control Field域格式 中控下行协议DATA域的格式参见下图，通道号、操作功能码中实际使用的bit由各设备协议自行制订，可各不相同： 图4：中控下行协议DATA域格式 适配器往Server发送报文的格式同图2 适配器往Server发送报文的DATA域格式同图4 适配器从Server收到报文后，如Length小于等于设备链路的MTU，则直接将报文透传至网关，如Length大于MTU，则须将报文进行分片，分片的区域包含：Length、DATA、CRC16，每个分片报文的格式遵守如下设备下行协议的格式： 图5：中控下行协议分片包格式 目前节点往网关发送报文时，严禁分片！由于节点只会从网关中收到报文，其重组比较简单，而适配器理论上会从各节点收到分片包，重组工作就比较复杂，因此一期工作适配器不支持重组。 2．帧格式定义 大于一个字节的定义都使用大端，高字节在低地址，以下描述中统一为Byte0为低字节，Byte X 为高字节。 2.1