The network is very dynamic (e.g.., devices may fail, wireless links are more likely to fail). Some protocols (e.g., ZigBee) change the device address from time to time. Consequently, it is not practical to use network addresses for SA devices and applications to communicate. It is not uncommon for an application to not know the address or identity of the devices that deliver the information it requires. The application is only interested in the data content.
It is possible for multiple applications to be interested in the same sensor data, but for different purposes, meaning that the SA devices have to manage and maintain communications with multiple applications in parallel. This might exceed the limited capabilities of the simple and low-cost SA devices.
This problem can be overcome by using a data-centric communication approach, where information is delivered to consumers as a function of their content and interest. The publish/subscribe (pub/sub) messaging systems is one such approach. It is preferred because it is scalable and support a dynamic application topology.
Publish/Subscribe System
Components that are interested in consuming certain information register their interest. This registration process is called a subscription. The interested party is called a subscriber.
Components that produce certain information do so by publishing their information. They are called the publishers.
The entity that ensures the data gets from the publishers to the subscriber is called a broker. It coordinates subscriptions; subscribers contact the broker in order to subscribe.
There are 3 types of pub/sub system:
- Topic-based systems: Topics are known in advance. Subscriptions and publications are made on a specified set of topics.
- Type-based systems: A subscriber state the type of data it is interested in (e.g., temperature). This type is not very common.
- Content-based systems: The most versatile. The subscriber describes the content it wants to receive (e.g., any messages containing both temperature and light readings, where the temperature is below a certain threshold and the light is on).
Topic-based systems are most suitable for WSNs. A subscriber sends a sub(topic) message to inform the broker of its interest. A publisher sends a pub(topic, data) message that contains the data to be published together with the related topic. If there is a match between the publisher’s and the subscriber’s topics, the broker transfers the pub(topic, data) message to the subscriber. One pub message may be distributed to multiple subscribers if it matches the subscribers' topic of interest.
The following figure shows the placement of the broker in an integrated WSN network.
An application or a SA device can be both subscriber and publisher. Subscribers and publishers are decoupled from each other by the broker, even if they reside on the same device. For example, a temperature sensor may need to be monitored by multiple applications for different reasons. When data is available, the sensor simply creates a pub(topic, data) message and sends it to the broker, which then distributes it to the subscribers.
The set of publishers and subscribers that are coupled by matching topics can dynamically change over time without the subscribers or publishers being aware of it. This is important because in a WSN, nodes might fail and new ones are added to replace failed nodes, or to extend the network at anytime. Applications do not need to be aware of these changes and simply receive data when the new devices begin to operate. Likewise for the SA publisher nodes — they need not know which applications are interested in their data. They simply send their data to the broker, which handles the data distribution.
The pub/sub model simplifies matters for application developers because it hides the complexity of the underlying network and lets them focus on the design of the application itself. To receive data from a SA device, the only thing that an application needs to know is the topic the SA device uses when it publishes its data. Similarly, if it wants to send control information to a SA device, it only has to know the topics the SA device subscribes to, not its actual network address. If a device is removed, no changes are required to the applications and gateways as as long as the SA still uses the same topics for its publications and subscriptions. The topics are defined by the application developers, and not by the network or by the broker.
MQTT
MQTT is an open pub/sub protocol first developed in 1999, which does not consider SA devices. MQTT-S is an extension for sensor networks that has been adapted to better function on devices where low power usage is a primary concern. The protocol has also been adapted for communication over low bandwidth links that are capable of only short messages and where network interruptions are common.
MQTT is designed so that its implementation on the client’s side is very simple. Any system complexities are on the broker’s side. MQTT does not specify the routing or networking techniques. It assumes that the underlying network provides a point-to-point, session-oriented, auto-segmenting data transport service with in-order delivery (such as TCP/IP) and employs this service for to exchange messages.
Because MQTT is connection-oriented, a client has to set up a connection with the broker before exchanging pub/sub messages. The CONNECT message contains a Client ID that that is used by the broker to identify the client.
MQTT supports basic end-to-end QoS. There are three QoS levels:
- Level 0: Best-effort delivery service, where messages are delivered either once or not at all. There is no acknowledgement and no retransmission.
- Level 1: A message is retransmitted until an acknowledgement is received. Messages are guaranteed to arrive, but may be duplicated because of retransmissions.
- Level 2: Guarantees that a message is not only received, but that it is delivered only once to the receiver.
It is up to the application to select the appropriate QoS level for its publications and subscriptions. The broker uses the Client ID to make sure that QoS level 1 and 2 publications are delivered correctly when the client reconnects after a network failure.
The broker monitors the connection using a keep-alive timer that defines the maximum time interval that may elapse between two messages received from that client. If within this time interval the client has no messages to transmit, it sends a PING message to the broker, which the broker acknowledges. The broker uses the keep-alive message to detect client failure or network link failure.
When a connection is established, a client may ask the broker to store a Will message and a Will topic. The broker sends the Will publication to subscribers only when it detects an abnormal loss of connection with the client. Applications can use this feature to detect device and link failures.
MQTT-S
MQTT-S is especially designed for WSNs, taking into consideration the following factors:
- As close as possible to MQTT to allow a seamless connection of the SA devices to an MQTT broker. This enables a smooth integration of the WSN with the existing communication infrastructure. It also enables a very simple and lossless implementation of the gateways. MQTT-S supports all MQTT features and almost all message flows and contents defined by MQTT.
- Optimized for tiny SA devices. It is designed so that it can be implemented for low-cost, battery-operated devices with limited processing and storage. Whenever complexities are required, they reside on the gateway/broker. The client running on the SA devices is kept as simple as possible.
- Consideration of wireless network constraints, such as high link failure rates, low bandwidth, short message payload and lower transmission capacity. For example, the IEEE 802.15.4 standard provides a maximum aggregate (shared) bandwidth of 250 kbit/s in the 2.4 GHz band. Procedures should be defined to reduce the risk of SAs being disconnected from the infrastructure due to link failures or network congestion.
- Network independent. MQTT-S is designed to run on any network that provides the following services:
- Point-to-point data transfer service (unicast service). A datagram service that allows the transport of messages between any two points based on their network address. The two points may be multiple hops away from each other.
- One-hop broadcast data transfer service. This is supported by all wireless networks. Messages sent by a node can be received by all nodes within the transmission range.
- 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.
- 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 allows 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.
- Pre-defined Topic IDs and short Topic Names are introduced, for which no registration is required. Predefined Topic IDs are also a two-byte long replacement of the Topic Name — their mapping to the topic names is known in advance by both the client’s application and the gateway/server. Therefore, both sides can start using pre-defined Topic IDs — there is no need for a registration as in the case of normal Topic IDs mentioned above. Short Topic Names are topic names that have a fixed length of two octets. They are short enough to be carried together with the data within PUBLISH messages. As for pre-defined Topic IDs, there is also no need for a registration for short topic names.
- A discovery procedure helps clients without a pre-configured server/gateway’s address to discover the actual network address of an operating server/gateway. Multiple gateways may be present at the same time within a single wireless network and can co-operate in a load-sharing or stand-by mode.
- The semantic of a “clean session” is extended to the Will feature, i.e., Will topic and Will message, like client's subscriptions, are persistent. A client can also modify its Will topic and Will message during a session.
- A new offline keep-alive procedure is defined to support sleeping clients. With this procedure, battery-operated devices can go into a sleep state during which all messages destined to them are buffered at the server/gateway and delivered later when they wake up.
MQTT-S Architecture
There are two components:
- MQTT-S clients reside on the WSN network and allows the SA devices to access the pub/sub services of a MQTT broker located on the traditional network. They connect to the gateway using the MQTT-S protocol, and the gateway connects to the broker.
- MQTT-S gateway's main function is to translate between the MQTT and MQTT-S protocols. A MQTT-S gateway may or may not be integrated with the broker. It is not integrated with the broker for stand-alone operations. The gateway uses the MQTT protocol to communicate with the broker.
There are two types of gateway, classified according to how it performs the protocol translation between MQTT and MQTT-S:
- Transparent Gateway: For each connected MQTT-S client, a transparent gateway sets up and maintains a MQTT connection to the MQTT broker. The number of connections between the gateway and the broker depends on the number of MTTQ-S clients connected to the gateway. All MQTT-S messages can be mapped to MQTT messages and vice versa.
- Aggregating Gateway: Instead of one MQTT connection for each connected client, this gateway has only one MQTT connection to the broker. All message exchanges between a MQTT-S client and an aggregating gateway end at the gateway. The gateway then decides which information to transport to the broker.
A transparent gateway is simpler to implement, but scalability might become a problem in a network with a very large number of SA devices. An aggregating gateway is more scalable because it significantly reduces the number of concurrent MQTT connections that the broker has to support.
Because wireless networks are more prone to errors and failures, failure of a link between a SA device and a gateway will cause them to be disconnected. In order to increase reliability, a SA device should have access to at least two gateways, so that if its connection to one gateway fails, it can re-connect via the other.
Another reason for providing access to two gateways is to reduce congestion. Links near a gateway could become congested if a large number of SAs send their messages via that gateway. Having more than one gateway helps to reduce congestion because traffic toward the broker can be spread evenly between the gateways.
MQTT-S supports multiple gateways using a gateway discovery procedure. To find a gateway, a client broadcasts a SEARCHGW message. A gateway replies using the GWINFO message. A client may also reply with a GWINFO message if it has the address of a gateway. To give priority to the gateways and to reduce the number of messages, clients delay their transmissions for a random time. If during this delay they hear a GWINFO message sent by another node (gateway or client), they do not send their reply. The SEARCHGW and GWINFO messages are not forwarded by the receiving nodes (local broadcast).
The procedure is bandwidth-efficient because one SEARCHGW and GWINFO message exchange could provide the required information to multiple clients that are concurrently searching for a gateway. If there is no response, the SEARCHGW message is retransmitted. The interval between retransmissions is increased exponentially.
Source
- MQTT.org
- MQTT For Sensor Networks (MQTT-SN)Protocol Specification
- U. Hunkeler, H.L.Truong, A. Stanford-Clark (2008). MQTT-S — A publish/subscribe protocol for Wireless Sensor Networks, Proc. of the 2008 3rd International Conference on Communication Systems Software and Middleware and Workshops (COMSWARE '08), 6-10 Jan. 2008, Bangalore, India
No comments:
Post a Comment