The "Open Device Monitoring and Tracking Protocol",
otherwise known as OpenDMTP™, is a protocol and framework that allows
bi-directional data communications between
servers and devices (clients) over the Internet and similar networks.
OpenDMTP is particularly geared towards Location-based information
(LBS) such as GPS, as well as temperature and other data collected in
remote-monitoring devices. OpenDMTP is small, and is
especially suited for micro-devices such as PDA's, mobile phones, and
custom OEM devices.
(For the server-side GPS tracking web interface see the
Open GPS Tracking System Project
[OpenGTS™], which includes support for the OpenDMTP server.)
History and Purpose:
We saw a need for a communications protocol that allowed high-latency, low-bandwidth (HL/LB) devices
to transmit location data to monitoring-systems. Because these devices often have limited network
connectivity, the protocol needed to be small and efficient. Example devices include mobile phones,
PDA's, OEM micro-devices (alarm systems, temperature monitors, etc.), and more.
There are many mobile GPS tracking devices on the market today with their own closed proprietary
protocols. Searching the web for open protocols revealed only a few available for transferring data
(including GPS information) between devices. However these solutions are generally designed for
non-mobile applications and/or lack some of the low-bandwidth, configurable, and extensible features
that mobile applications require.
Having an open protocol designed specifically for mobile devices has many advantages:
Targeted Event Generation: Many devices on the market are designed simply to
transmit copious amount of GPS data to a back-end server hoping that the server can make
sense of the data that it is receiving. The problem with this approch is that it tends to
result in higher data transmission costs for information which will never be used. A protocol
used for mobile applications need to be able to provide the flexibility to generate only the
events that are pertinent to the specific application.
Network Efficient: Mobile devices typically have limited network connectivity,
and in some cases data communication can be quite expensive (e.g. satellite).
Because of this the protocol needs to be efficient in it's dialog between the client and
server. The communication needs to be optimized such that the necessary information
can be conveyed with a minimum number of bytes in the least amount of time.
Transport Media: Differrent mobile applications will have their own unique way
of communicating data back to the server. Some may use GPRS, or socket based communication, others
may use satellite communication, while still others may use other forms of wireless communication,
such as BlueTooth. The design of the protocol should be able to encompass all such transport
media types, regardless of the type of transport in use.
Bi-directional: Some devices can support two-way communication (ie.
GPRS, or other socket based connections), while others may only support one-way communication (ie.
some satellite communication systems). With this in mind, a protocol should be designed to support
both duplex (two-way) and simplex (one-way) communication.
Flexible Data Encoding: Most types of transport media allow for the transmission of
binary encoded data. However, there may be some forms of media for which an ASCII encoded data
packet is much better suited. A protocol designed with this in mind should be able to support both
types of data encoding.
Configurable Messages: Due to the broad range of data types used in mobile
applications, the protocol should be flexible enough to define standard messages, yet still allow
custom messages within the framework.
Extensible: Not every mobile application is the same. Some require special
handling and may have various types of inputs and outputs. A protocol designed for mobile
applications should insure that the framework can be easily extended to incapsulate the
specific needs of the device.
Small Footprint: Mobile devices typically have limited resources on which to run
client code (ie. memory, processor speed). An open protocol designed with
this in mind should be optimized to allow efficient implementation and should easily support
devices such as PDA's, mobile phones, GPS monitoring devices, and other OEM micro-devices.
Industry Compatibility: Having an open protocol insures better compatibility
between different client devices and service providers.
Reference Implementation: Having a reference implementation that showcases the
major features of the protocol provides an easy starting point on which developers can
add their own features and platform specific implementation without having to worry about
how data gets from the client to the server. The supported reference implementation platforms
include Embedded Linux, Windows CE/Mobile, and Java.
OpenDMTP was specifically designed to suit all these needs, especially
"Targeted Event Generation" and "Network Efficiency". The typical 'data plan' for GPRS communication,
for instance, is usually 1Mb to 2Mb per month. OpenDMTP was designed to optimize packet encoding
to allow the collection of GPS information packets once every 3 minutes, 24 hours a day, 30 days a month,
and still stay under a 1Mb data plan limit.
While XML is very extensible, it fails the "Small Footprint" and "Network Efficiency"
requirements. Thus, it was discounted as a viable protocol solution. Many mobile devices do not have
the resources necessary to be able to provide full XML parsing functionality. And
an XML packet may need to be several hundred bytes in length just to send a few bytes of
actual data. This alone would make the solution cost prohibitive for high-cost
transport media such as satellite.
OpenDMTP also includes a full-featured commercial quality reference implementation
to jump-start development.
For a full-featured GPS tracking web interface see the
Open GPS Tracking System Project
[OpenGTS™], which includes support for the OpenDMTP server.
OpenDMTP is an Open Source protocol and client framework. It is
licensed under the Apache
Software License, version 2. According to the terms of this license, anyone may freely download
and distribute the tools and information released here.
Contact us regarding availability of the following additional features:
J1708/J1587 Data Monitoring: Including the vehicle odometer which satisfies
the requirements for automated hour of service documentation.
Temperature Monitoring: Up to 4 temperature probes can be monitored for refrigerated
trailers, or other applications.
Dual Bluetooth and GPRS Transport: For in-cab hours of service or navigation
Trailer Drop/Hook Detection: Ability to identify and generate
events based on which trailers are currently attached to a tractor.
Additional Supported Client Hardware: Support for a growing list of other commercially
available client hardware.
GeoCorridor Protection for Secure Loads: Ability to securely monitor high-value
load transport from one location to another.
Main project development site