M2MXML: An Open Standard for Machine-To-Machine Communications

White Paper

Byron K. Appelt SensorLogic, Inc.

Introduction
The field of machine-to-machine (M2M) communications is rapidly expanding, however, it adoption cannot yet be termed widespread. One of the reasons behind this is the difficulty in building end-to-end solutions. In most cases, every component, from the device and embedded code, to the back-end application and web interface is a custom effort. This has begun to change. Radio manufacturers and third party integrators have started offering complete telemetry modules inclusive of the radio, power supply, I/O, and even the enclosure and connectors. The availability of this sort of hardware, in many cases reduces the device side hardware design to the selection of an off the shelf component. The advent of the Telemetry Service Provider (TSP) which, for a monthly fee, provides all of the interfaces to carriers, data storage, web interfaces, and other back-end functions, now allows the server side of an M2M application to be purchased as a service rather than architected at great expense and effort. Even though both the hardware and the back-end are available as off the shelf products, the device manufacturers have difficulty selling their products because there is still a significant integration effort in writing embedded code to talk to a back-end service. Similarly, back-end providers are expending resources writing embedded applications because they cant sell their service without devices that can talk to it. The missing piece of the pervasive off-the-shelf telemetry application is a widely adopted protocol allowing embedded code to be written for the commercially available hardware to talk to the server-side application available for hire at the TSP. If this protocol existed, especially as an open standard, device manufacturers as well as third parties could write the embedded applications to interface to any TSP that implemented the protocol. Complete M2M applications could then be constructed from three potentially off the shelf components: back-end services, device hardware, and embedded code. The end users would be able to choose to buy the entire application as a package, implement one or more of the components themselves, or acquire them from different sources. They would all be able to interface because they relied on a standard protocol. M2MXML is being developed as an open standard to be this protocol. The standard, along with supporting code libraries is being developed in the open-source community and is hosted at http://www.m2mxml.org.

Limitations of existing protocols

There are a number of protocols that have been used in M2M and related fields, such as industrial automation. However, they all are a poor fit for one or more reasons.

Designed for a connection oriented environment

Many protocols that have been deployed in M2M were borrowed from industrial automation and were originally designed for use on multi-drop serial networks such as RS485. Therefore a low latency high availability was assumed in their design.

 Designed for a Master-Slave deployment

MODBUS is also an example of a protocol designed to be used in a master-slave configuration. This is sometimes appropriate for M2M, but frequently is not. The ability to have devices report on a schedule or report by exception is crucial to efficient use of wireless bandwidth.

Bandwidth Intensive
Many protocols that were not designed for M2M applications are incredibly bloated when viewed in the context of wireless networks.

Complex
The fact that an M2M protocol needs to be implemented, in some cases, by devices that have very limited computational resources, means that a protocol needs to be simple. This need is further exacerbated by the fact that many of the individuals who would implement the embedded code are principally hardware designers and not software engineers and frequently work individually or in very small teams.

Over Engineered
Many protocol standards are over-designed, with XML protocols being some of the worst. They are written in an attempt to satisfy all members of a committee and often the result is a protocol may satisfy everyone, but is useable by no one.

M2MXML Design Goals

Terse but not too terse
M2MXML needs to be tight enough for reasonable use over wireless networks. However, the cost of bandwidth is decreasing and this should not be ignored. There is a tradeoff between terseness and the effort required for implementation and debug. In the design of M2MXML the goal was to be fairly terse, but maintain a level of human readability so that the protocols use can be quickly understood from examples and be readily debugged especially considering the limited toolsets that are often available to the device developer. It is also assumed that once an application is mature, a compression layer could be implemented on top of M2MXML to reduce the operations cost, if necessary.

XML Based
As its name implies, M2MXML is implemented using the eXtensible Markup Language. This choice was made to leverage an existing and well known grammar, and to allow the use of widely available third party APIs for handling XML. XML in

the embedded world has often been criticized as too bloated, but intelligent use allows the previously mentioned balance of terseness to be reached

Self-Contained messages
In order to facilitate its use on high latency and low availability networks, as well as to decrease the complexity of transactions, M2MXML is essentially composed of self-contained messages. Generally transactions are a single fire and forget message, or a request message followed by a response message.

Transport Agnostic
M2MXML does not specify anything about what transport protocols are used. Any protocol for delivering XML can be used to deliver M2XML.

Extensibility
M2MXML is meant to be the framework for communications in a wide range of M2M applications. Therefore, its design is not meant to include all of the possible commands and configuration parameters, etc. that a complex application would need to define. Parts of the protocol are meant to be defined in an application specific manner. However, the protocol is meant to complete enough that the vast majority of simple applications can use it out of the box.

Examples
A quick way to provide a general feel for M2MXML is to show a few examples. This is not meant to be a tutorial or any sort of reference documentation. These examples are just meant to demonstrate the simplicity and intuitiveness of the protocol.

Example 1: A reporting a data point

The first example is simply a device reporting a single data point on a schedule. In M2MXML data point messages are called percepts, which is a term borrowed from robotics. The following message reports a reading of 42 for an analog port with address A1. Additional attributes can be specified to indicate other data types, a timestamp that is not current, etc. <M2MXML ver=1.0> <Percept address=A1 value=42/> </M2MXML>

Example 2: A command to turn on an output

This example is a command sent to a device to energize a relay. The port connected to the relay has an address of relay1 which is an arbitrary designation unique within the device. A sequence number is used to match the response to the request. The name attribute of the Command element is an example of an area where the protocol is meant to

be customized. The turnOn command is part of the base specification, but additional commands specific to an application can be added. Request: <M2MXML ver=1.0> <Command address=relay1 name=turnOn seq=2876/> </M2MXML> Response: <M2MXML ver=1.0> <Response address=relay1 resultCode=0 seq=2876/> </M2MXML>