MQTTSensor-Network协议规范_支持mqtt协议的消息中间件资源-CSDN文库

4星 · 超过85%的资源需积分: 15 175 浏览量 2017-06-26 10:09:30 上传评论 2 收藏 419KB PDF 举报

资源推荐

资源详情

资源评论

MQTT For Sensor Networks (MQTT-SN)

Protocol Speciﬁcation

Version 1.2

Andy Stanford-Clark and Hong Linh Truong

(andysc@uk.ibm.com, hlt@zurich.ibm.com)

November 14, 2013

Permission to copy and display the MQTT For Sensor Networks (MQTT-SN) Protocol Speciﬁcation (the

”Speciﬁcation”), in any medium without fee or royalty is hereby granted by International Business Machines

Corporation (IBM) (the ”Author”), provided that you include the following on ALL copies of the Speciﬁcation,

or portions thereof, that you make:

1. A link or URL to the Speciﬁcation at one of the Author’s websites

2. The copyright notice as shown in the Speciﬁcation

The Author agrees to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions

to their respective patents that they deem necessary to implement the Speciﬁcation.

THE SPECIFICATION IS PROVIDED ”AS IS,” AND THE AUTHOR MAKES NO REPRESENTATIONS OR

WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE;

THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT

THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS,

COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE AUTHOR WILL NOT BE LIABLE FOR ANY

DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR

RELATING TO ANY USE OR DISTRIBUTION OF THE SPECIFICATION.

The name and trademarks of the Author may NOT be used in any manner, including advertising or publicity

pertaining to the Speciﬁcation or its contents without speciﬁc, written prior permission. Title to copyright in the

Speciﬁcation will at all times remain with the Author.

No other rights are granted by implication, estoppel or otherwise.

Contents

1 Change and Revision History 3

1.1 Version 1.0, November 29, 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Version 1.1, June 5, 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Version 1.2, May 20, 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Introduction 3

3 MQTT-SN vs MQTT 4

4 MQTT-SN Architecture 5

4.1 Transparent Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.2 Aggregating Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 Message Formats 6

5.1 General Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.2.1 Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.2.2 MsgType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.3 Message Variable Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.3.1 ClientId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.3 Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.5 GwAdd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.6 GwId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.7 MsgId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.8 ProtocolId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.9 Radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.10 ReturnCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.11 TopicId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.12 TopicName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.13 WillMsg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3.14 WillTopic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.4 Format of Individual Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.4.1 ADVERTISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.4.2 SEARCHGW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.4.3 GWINFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.4.4 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.4.5 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.4.6 WILLTOPICREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.4.7 WILLTOPIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.4.8 WILLMSGREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.4.9 WILLMSG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.4.10 REGISTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.4.11 REGACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.4.12 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.4.13 PUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.4.14 PUBREC, PUBREL, and PUBCOMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.4.15 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4.16 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4.17 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.4.18 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.4.19 PINGREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.4.20 PINGRESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.4.21 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.4.22 WILLTOPICUPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.4.23 WILLMSGUPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4.24 WILLTOPICRESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4.25 WILLMSGRESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.5 Forwarder Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Functional Description 19

6.1 Gateway Advertisement and Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2 Client’s Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.3 Clean session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.4 Procedure for updating the Will data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.5 Topic Name Registration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.6 Client’s Publish Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.7 Pre-deﬁned topic ids and short topic names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.8 PUBLISH with QoS Level -1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.9 Client’s Topic Subscribe/Un-subscribe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.10 Gateway’s Publish Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.11 Keep Alive and PING Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.12 Client’s Disconnect Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.13 Client’s Retransmission Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.14 Support of sleeping clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Implementation Notes 27

7.1 Support of QoS Level -1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.2 “Best practice” values for timers and counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.3 Mapping of Topic Ids to Topic Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.4 ZigBee related issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1 Change and Revision History

1.1 Version 1.0, November 29, 2007

• Initial version

1.2 Version 1.1, June 5, 2008

• New feature: support of sleeping devices

1.3 Version 1.2, May 20, 2011

• New feature: support of message lengths greater than 255 bytes

• Format for the forwarder encapsulation changed to the format proposed by Nicholas O’Leary (nick oleary@uk.ibm.com)

• Return code value “0x03 Rejected, not supported” added

• Field “ReturnCode” added to the messages WILLTOPICRESP and WILLMSGRESP

2 Introduction

There is a recent increase of interest in Wireless Sensor Networks (WSNs), both from commercial and technical

point of view, due to their simplicity, low cost and easy deployment. Those networks can serve different purposes,

from measurement and detection, to automation and process control. A typical WSN consists of a large number

of battery-operated sensors and actuators (SAs), which are usually equipped with a limited amount of storage and

processing capabilities. It is important that those devices communicate wirelessly, since the number of SA-nodes

is typically very large, and the cost of deployment of a wired infrastructure is prohibitively expensive. Such a

network is by nature very dynamic: the wireless links may temporarily break at any time, and nodes may fail

and be replaced very often. In such situations the conventional approach of using addresses for communicating

with the individual nodes may become a nightmare. Applications residing on the ﬁxed network and requiring

interactions with the wireless SA devices would need to manage and maintain means to communicate with a large

number of nodes. In most cases they do not need to know the address or identity of the devices which deliver the

information, but are more interested in the content of the data. For example, an asset tracking application is more

interested in the current location of a certain asset than in the network address of the GPS receivers that deliver that

information. In addition, several applications may have interest in the same sensor data but for different purposes.

In this case the SA nodes would need to manage and maintain communication means with multiple applications

in parallel. This might exceed the limited capabilities of the simple and low-cost SA devices.

Another problem is the difference in the addressing schemes between the networks involved. For example,

how does an application residing on a TCP/IP-based network address a SA device running on a ZigBee

1

-based

wireless network?

The problem described above may be overcome by using a data-centric communication approach, in which

information is delivered to the receivers not based on their network addresses but rather as a function of their con-

tents and interests. One well-known example of data-centric communication is the “Publish/Subscribe” (pub/sub)

messaging system which is already being widely used in enterprise networks, mainly due to their scalability and

support of dynamic network topology. Extending the enterprise pub/sub system into the WSNs also enables a

seamless integration of the WSNs into the enterprise network, thus making the ﬁeld data collected by the SAs

available to all applications as any other enterprise information and enabling the control of the SAs from any

ZigBee is a trademark of ZigBee Alliance in the US, other countries or both. Other company, product or service names may be trademarks

or service marks of others.

enterprise application. This can be for example achieved by using the MQTT protocol, which is an open and

lightweight publish/subscribe protocol designed speciﬁcally for machine-to-machine and mobile applications. It

is optimized for communications over networks where bandwidth is at a premium or where the network con-

nection could be intermittent. However MQTT requires an underlying network, such as TCP/IP, that provides

an ordered lossless connection capability and this is too complex for very simple, small footprint, and low-cost

devices such as wireless SAs.

The purpose of this document is to specify MQTT-SN, a pub/sub protocol for wireless sensor networks.

MQTT-SN can be considered as a version of MQTT which is adapted to the peculiarities of a wireless commu-

nication environment. Wireless radio links have in general a higher failure rates than wired ones due to their

susceptibility to fading and interference disturbances. They have also a lower transmission rate. For example,

WSNs based on the IEEE 802.15.4 standard provide a maximum bandwidth of 250 kbit/s in the 2.4 GHz band.

Moreover, to be resistant against transmission errors, their packets have a very short length. In the case of IEEE

802.15.4, the packet length at the physical layer is limited to 128 bytes. Half of these 128 bytes could be taken

away by the overhead information required by supporting functions such as MAC layer, networking, security, etc.

MQTT-SN is also optimized for implementation on low-cost, battery-operated devices with limited processing

and storage resources.

MQTT-SN was originally developed for running on top of the ZigBee

1

APS layer. ZigBee

1

is an open

industrial consortium with the aim of deﬁning an open and global communication standard for WSNs. To be

global ZigBee

1

has selected the IEEE standard 802.15.4 as the protocol for the PHY and MAC layers, and

adds on top on this standard the required network, security and application layers, thus providing interoperability

between products of different vendors.

MQTT-SN is designed in such a way that it is agnostic of the underlying networking services. Any network

which provides a bi-directional data transfer service between any node and a particular one (a gateway) should

be able to support MQTT-SN. For example a simple datagram service which allows a source endpoint to send

a data message to a speciﬁc destination endpoint should be sufﬁcient. A broadcast data transfer service is only

required if the gateway discovery procedure is employed. To reduce the broadcast trafﬁc created by the discovery

procedure, it is desirable that MQTT-SN could indicate the required broadcast radius to the underlying layer.

3 MQTT-SN vs MQTT

MQTT-SN is designed to be as close as possible to MQTT, but is adapted to the peculiarities of a wireless com-

munication environment such as low bandwidth, high link failures, short message length, etc. It is also optimized

for the implementation on low-cost, battery-operated devices with limited processing and storage resources.

Compared to MQTT, MQTT-SN is characterized by the following differences:

1. The CONNECT message is split into three messages. The two additional ones are optional and used to

transfer the Will topic and the Will message to the server.

2. To cope with the short message length and the limited transmission bandwidth in wireless networks, the

topic name in the PUBLISH messages is replaced by a short, two-byte long “topic id”. A registration

procedure is deﬁned to allow clients to register their topic names with the server/gateway and obtain the

corresponding topic ids. It is also used in the opposite direction to inform the client about the topic name

and the corresponding topic id that will be included in a following PUBLISH message.

3. “Pre-deﬁned” topic ids and “short” topic names are introduced, for which no registration is required. Pre-

deﬁned topic ids are also a two-byte long replacement of the topic name, their mapping to the topic names

is however known in advance by both the client’s application and the gateway/server. Therefore both sides

can start using pre-deﬁned topic ids; there is no need for a registration as in the case of “normal” topic ids

mentioned above.

剩余27页未读，继续阅读

评论收藏

内容反馈

pinocchio1975

2017-06-26

很不错的资料，不过是e文的。

ydogg

粉丝: 129
资源: 10

MQTT Sensor-Network 协议规范

最新资源

MQTT Sensor-Network 协议规范

mqtt-virtual-sensor:这是一个简化的 Mqtt 虚拟传感器

feather-mqtt-temp-sensor:使用mqtt发布其读数的温度传感器

iot测试软件

zigbee2mqtt-networkmap:家庭助理自定义卡显示 Zigbee2mqtt 网络地图

wolfMQTT：wolfMQTT是一种小型，快速，可移植的MQTT客户端实现，包括对TLS 1.3的支持

kotori:基于InfluxDB，Grafana，MQTT等的灵活数据历史学家。 免费，开放，简单

Mobile and Web Messaging

luftdatenpumpe:处理来自luftdaten.info，IRCELINE和OpenAQ的实时和历史数据。 按站点ID，传感器ID和传感器类型过滤，应用反向地理编码，存储到时间序列和RDBMS数据库中，发布到MQTT，以JSON输出或在Grafana中可视化

ninESP:ninHOME 节点 - Web 可配置模块化 ESP8266 固件

home2l:The Home2Ls - 私人住宅的智能工具

esp8266-framework:esp8266框架堆栈，可轻松配置应用程序

terkin-datalogger:用于MicroPython和CPython的Terkin数据记录器

串口助手工具合集.zip

史上最全的张飞实战电子学习资料.zip

OLED显示温度和时间-STM32F103C8T6（完整程序工程+原理图+相关资料）.zip

pn532模拟资料包.zip

Vivado license 永久

STM32全系列 Keil MDK pack包（当前最新离线包）

AD Type C 封装库 6Pin 24Pin分享（带3D视图）

STM32HAL库+RS485+串口+定时器+Modbus协议（主机+从机测试）

I2C主机及从机Verilog代码实现.zip

计算机组成与设计硬件软件接口risc-v中文.pdf

Multisim14.0.7z

TDMS转EXCEL官方插件

QFN封装_大全（8、12、16、20、24、28、32、36、40、44、48、52、56、60、64、68、72、80脚）.PcbLib

最新资源

kotori:基于InfluxDB，Grafana，MQTT等的灵活数据历史学家。免费，开放，简单

luftdatenpumpe:处理来自luftdaten.info，IRCELINE和OpenAQ的实时和历史数据。按站点ID，传感器ID和传感器类型过滤，应用反向地理编码，存储到时间序列和RDBMS数据库中，发布到MQTT，以JSON输出或在Grafana中可视化