*This new scheme bids fair to become a protocol for the Internet of Things, but you may note that it's not, in fact, an "Internet Protocol." Instead, it's a new protocol specifically designed for on again, off again, low powered sensors, actuators and mobile gizmos.
*However, I somehow doubt that the technically correct term "Message Queuing Telemeter of Things" is ever gonna catch on. And you never know about a protocol, either. Even open-sourcing the water doesn't always make the horses drink.
— CALL FOR PARTICIPATION
The charter for this TC is as follows.
(1)(a) Name of Technical Committee:
OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee
(1)(b) Statement of purpose.
The purpose of the Message Queuing Telemetry Transport (MQTT) Technical Committee is to define an open publish/subscribe protocol for telemetry messaging designed to be open, simple, lightweight, and suited for use in constrained networks and multi-platform environments. The TC will accomplish this purpose through the refinement of an input specification.
> Background and Opportunity:
Many industries are seeing rapid demand for products and solutions which map physical world events into digital events for enterprise and Web applications, bringing an inherent need to integrate sensors, actuators and other types of devices with a wide range of application middleware and Web programming models. These applications need to connect and communicate with devices ranging from simple sensors, actuators and complex embedded edge-of-network controllers, to mobile devices, often over wireless networks.
> Needs and Requirements
A simple, predictable, and easy to implement message protocol is needed for connecting embedded and mobile devices such as, physical sensors, controllers, and smart phones with servers used in Web, enterprise, and other applications where a lightweight messaging protocol is desired. The protocol must be able to cope with runtime platform constraints, network constraints and various combinations of both. It must support implementations that run on embedded devices with limited power, processor or memory resources, connecting to a range of web services and enterprise middleware in constrained environments where networks may have any combination of low bandwidth, intermittent connectivity, unpredictable reliability, or high data cost.
Experience with physical world messages and events across many industry domains, has identified key requirements for such a message protocol:
- Bi-directional messaging to uniformly handle both signals and commands.
- Determinable delivery of messages to and from sensors and actuators, and other resource constrained devices connected over intermittent, limited bandwidth networks. Basic Quality of Service (QoS) levels are needed to reflect tradeoffs between bandwidth, availability, and delivery guarantees. Always-connected and sometimes-connected models both need to be supported. A message subscriber must be able to set up a quality of service needed that reflects the constraints and characteristics of message source’s network connection.
- Connectivity Awareness. To support intermittently-connected networks and devices, the publish-subscribe infrastructure needs to provide message subscribers, if necessary, a means to determine the likely connected, disconnected or error state of the end devices in the network.
- Loose coupling to support dynamic system environments where high volumes of physical world messages and events need to be made available to enterprise servers and other consumers in ways that may not have been originally anticipated. Time, space and synchronization decoupling are needed.
- Constrained operations: Instrumentation of the physical world must be supported in a proliferation of platforms, technologies and networks that are driven by very diverse equations of cost, technology and physical constraints.
- Scalability suitable to supporting environments where large numbers of devices need to be connected to a server infrastructure.
> Value of Standardization:
Although connectivity solutions currently exist to integrate these types of systems, the lack of a standardized messaging protocol designed explicitly to address the needs and requirements listed above has become an inhibitor in growing markets. Standardization of an open protocol that addresses the technical and market requirements can overcome these inhibitors through:
- Choices. With a standard protocol, initial choices in devices, networks and suppliers will not limit choices and adaptability in the future. A standard protocol that supports current and future device payload formats will support deployment, connectivity, and reconfiguration over a wide range of network and server characteristics.
- Flexible Integration. Even if highly effective, decoupling techniques between internal device infrastructure and external systems will not see widespread adoption without standardization. With devices and device controllers utilizing a standardized message protocol, a basic publish-subscribe model can support integration with a wide range of established messaging and event processing systems, allowing subscribers to effectively decouple from device and network APIs.
- Time to Market. Porting and supporting multiple protocols on multiple platforms tends to inhibit adoption in control and instrumentation systems, which are built using many variations of hardware and software platforms, device types, and networks. Providing an open protocol that scales well from critical embedded systems up to high volume enterprise transaction processing, and one that is data, platform and language independent, will shorten time to market and support new levels of integration.
- Skills. A standard based on protocol and programming models familiar to both embedded and IT programming communities will accelerate markets by building on skilled resources that already understand these types of solutions.
(1)(c) Scope of Work of the TC:
The TC will accept, as its input document, Version 3.1 of the MQTT specification as published by Eurotech and IBM, and publically available under royalty free terms at http://mqtt.org/documentation....
