This note describes the Axeda Wireless Protocol (henceforth "AWP"), its goals and general features. A more detailed description of the protocol can be found in the AWP Protocol Specification.
We also provide a reference implementation of AWP, including a tutorial describing how to build it under .NET and Linux.
The goals of AWP
The goal of AWP is to provide a protocol specifically optimized for wireless, with the functions necessary for M2M applications.
Efficiency is a prime concern. AWP is a binary protocol, so the number of bytes needed is minimized, but it also includes features to minimize the amount of data transmitted, including:
- providing downloadable rules, called Threshold Rules, which allow you to specify the conditions which will cause messages to be sent, and when a transmission is not necessary
- eliminating ack messages where they are not necessary for the application
In addition, the protocol is designed to be implemented by a wide variety of tracking devices. The protocol does not require a particular runtime environment, and is simple enough to be implemented without excessive processing or memory overhead by assets with a small hardware footprint.
The protocol supports a full range of security features, addressing authentication, message integrity, non-repudiation and the prevention of replay attacks. These features are optional, in order to accommodate applications where they are not necessary or devices which will not support them. For more details of the security architecture, see the protocol reference.
Some design features of AWP
AWP is a binary protocol defined in ASN.1. ASN.1 is widely used, for example in the telecommunications industry, and tools are available to generate code in a wide variety of languages, including C, Java, Python and the .NET languages. The combination of a binary protocol with a machine-interpretable specification minimizes the number of bytes transmitted over the wire without burdening the device programmer with the encoding details. On the other hand, the protocol is simple enough to allow hand-coding for those low-end devices that require it.
Minimizing bytes transmitted is just one way that AWP addresses efficiency.
AWP is designed to run over different transmission media, in either connection-oriented (TCP) or connectionless (UDP, SMS) modes. To optimize connectionless communications, a flag in each message tells the receiver whether to ack a message, allowing the sender to indicate whether message loss can be tolerated. The reference implementation includes a retry count so the application knows how many attempts were made to send a message.
Eliminating unnecessary ack messages is another way that AWP address efficiency.
The protocol identifies the protocol version which the tracking device implements, and the Axeda Platform will support devices using any version of AWP.
Alternative protocols
While AWP is designed to be implemented by small footprint tracking devices, not all tracking devices may be capable of implementing the complete protocol. At the encoding level, the platform supports custom codecs which provide native support for devices with proprietary protocols. At the functional level, each model of device has a profile which describes which AWP functions the device supports.
But any protocol will implement some subset of the semantics which follow.
The AWP Payload
The purpose of the AWP is to carry information from the tracking device to the Axeda Platform, and from the platform to the device. This information is carried in time-stamped messages.
A message from the tracking device to the platform may include:
- a location report, typically from a GPS device, in the form of lat/long coordinates
- one or more data items, which may be boolean, integer or string
- one or more alarms, which include the alarm name and a numeric severity, and an optional data item name and value
- one or more files in a compressed archive (e.g., log files)
A message from the platform to the tracking device may include:
- one or more data items
- one or more files in a compressed archive (e.g., a firmware or configuration file update)
- one or more Threshold Rules
String data items can be up to 4K bytes in size, and may use whatever encoding is convenient for the device, including binary or XML.
You can read more about how information is structured on devices and on the platform in the article on the Axeda Data Model.
AWP from the device side
AWP naturally looks somewhat different from the device than it does from the platform. In this section, we will discuss how the protocol works from the point of view of the tracking device. In the next section, we will look at how the protocol looks from the point of view of the platform.
It worth pointing out that a tracking device may provide many functions within the asset, but that here we are only concerned with the way the tracking device exchanges information with the Axeda Platform.
The tracking device has two main goals:
- reacting to events within the asset
- receiving and processing messages from the platform
Events within the asset
A tracking device is attached to an asset, and receives various kinds of information from sensors within the asset. Any information the tracking device receives from the asset might potentially be important, but perhaps not important enough to send a message to the platform. The process of deciding when to send a message to the platform is mediated by what we call Threshold Rules.
So an event within the asset may or may not result in a message being transmitted to the platform:
Event in the asset ---> Threshold Rule(s) run in device ---> Possible message transmitted
Messages from the platform to the asset
What the tracking device and the asset does with data items sent to it is entirely up to the functioning of the device and asset. For example, different data items may be configuration parameters or simply displayed to the user. Neither the platform nor the protocol limit the semantics of data items sent from the platform to the asset.
The same of true of files downloaded to the asset. A file might be a firmware update, a configuration file, or a new book being downloaded to an ebook reader.
On the other hand, the meaning of a Theshold Rule is completely specified. Each model of device has a profile which specifies the types of rules which it supports, and therefore limits the rules which can be downloaded, but if a device supports a given type of Threshold Rule, it must do it in the standard way. For example, if a device includes a data item 'temp', the Threshold Rule:
if temp > 100 then sendDataItem("temp")
must be executed by the device just the way it looks.
Because Threshold Rules are downloaded from the platform, they provide a convenient way to alter the behavior of the tracking device without the need to update its firmware.
AWP from the platform side
As we explained above, the tracking device can send any of the following to the Axeda Platform:
- a location report
- one or more data items
- one or more alarms
- one or more files in a compressed archive (e.g., log files)
When a message arrives at the platform, one or more of the following will happen:
- a Data Item, Alarm or Location will be updated
- one or more Expression Rules will be triggered
- a Data Item, Alarm or Location update will cause the new data to be published to ESS subscriber
You can read more about ESS (Event Subscription Service) in the article on Message Broker Services.
Assets and tracking devices
An important feature of the Axeda Platform is that it supports tracking devices that are separate from the assets they are attached to. The tracking device is the device that actually communicates with the platform on behalf of the asset it is attached to, or associated with. This allows, for example, a tracking device to be replaced when its battery dies without losing track of the asset.
This is explained in much more detail in the article on Model and Asset Associations.
