Internet DRAFT - draft-bergek-mipp
draft-bergek-mipp
Internet Draft M. Bergek
<draft-bergek-mipp-00.txt> Icomera
Category: Informational July 31st, 2007
Expires February 2008
Mobile Infrastructure Positioning Protocol (MIPP) version 1
<draft-bergek-mipp-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document will expire on February 1st, 2008.
Abstract
This memorandum describes the Mobile Infrastructure Positioning
Protocol, which specifies a protocol for distributing positioning
information from network elements which are in motion. The recipients
of positioning information as described herein are assumed to be
other nodes on the same vehicle and/or external recipients. The
emphasis is on an efficient and reliable way to provide a position
reference.
Bergek Expires February 2008 [Page 1]
Internet Draft MIPP (draft) July 31, 2007
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Operating modes .................................................3
4. Packet format ...................................................4
5. Packet oriented operation .......................................9
6. Session oriented operation .....................................10
7. Security Considerations ........................................11
8. IANA Considerations ............................................11
9. References .....................................................11
1. Introduction
Networks have traditionally been static when it comes to geographical
position. Consequently there has not been any need for real-time
distribution of the geographical position of network nodes. With
modern wireless networks it has become increasingly valuable to
connect various forms of moving vehicles to the Internet. With the
advent of passenger Internet services on high-speed trains and
airplanes, the trend is on providing communication services for a
whole vehicle network and in conjunction with this it is usually
highly valuable to know the whereabouts of the vehicle, both for
clients on the vehicle as well as for Internet based servers.
[RFC2712] specifies a way to piggy-back positioning data on DNS
responses but it implies that the network nodes are stationary during
the DNS records' time to live (TTL) period which makes it useless for
vehicles in motion.
Vehicle applications are typically categorised by unstable network
conditions with high latencies and significant packet losses - even
when travelling through populated areas. To date, applications on
vehicles, especially buses, have been designed to be stand-alone and
as a consequence it is not unusual to find multiple components as
well as antennas serving the same purpose (i.e. separate
communication modems and GPS receivers). This not only complicates
installation but also negatively affects the radio performance. This
specification intends to fill a hole when it comes to providing a set
of accepted standards that can be used to simplify the development of
onboard applications. Just as an onboard computer could leverage NTP
or SNTP to get an accurate time, they can use this protocol to get a
position reference.
Today, many applications use the NMEA 183 protocol of GPS equipment,
dating back to maritime equipment. However, the protocol is not
openly documented. Further it is not limited to positioning
information and may not necessarily be used for future positioning
systems.
Bergek Expires February 2008 [Page 2]
Internet Draft MIPP (draft) July 31, 2007
This memorandum is based on extensive real-life experience of vehicle
positioning within the train industry, both on-vehicle and off-
vehicle. The following requirements have been taken into account:
o Bandwidth management. Position updates are potentially sent
every second and vehicles may have limited and/or costly
communication resources. For off-vehicle updates it is thus
beneficial to limit the data volume transmitted.
o Update reliability. Some position updates must be delivered
while others may safely be dropped without any major impact to
the application. This requirement is primarily intended to
increase the reliability when sending updates to external
recipients since the onboard network can be assumed to be
relatively stable in comparison.
o Optional support for non-floating point arithmetics. Some
positioning receivers do not include support for floating point
arithmetics. This is particularly true for Java-based
platforms.
2. Terminology
A number of different network nodes are involved. Some nodes will
provide positioning data for others while some will collect
positioning data from a potential large number of nodes. Others still
will just act as clients. The following terms are used throughout
this document.
o Agent. This is a node with positioning hardware support and can
thus provide positioning information for other nodes in the
network. This node may or may not include an Ethernet interface
and it is therefore wrong to assume that it is able to
distribute the positioning information on a local network (i.e.
to clients).
o Server. This is a node that collects and aggregates the
information sent from one or many agents. The collected
information may be used locally and/or transmitted to
downstream servers.
o Client. These contain no position hardware support by
themselves but can query or receive positioning data from
Agents. Clients are typically located on the vehicle network.
o Receiver. Common generic name for both clients and servers
which receive positioning data from agents.
3. Operating modes
MIPP version 1 can operate in unicast (point to point) or multicast
(point to multipoint) modes. A unicast agent sends periodic
Bergek Expires February 2008 [Page 3]
Internet Draft MIPP (draft) July 31, 2007
positioning data to designated clients and/or servers based on pre-
configured parameters or configuration commands received and accepted
by the agent. A multicast agent sends unsolicited positioning data to
a designated IPv4 or IPv6 local broadcast address or multicast group
address. Multicast clients and/or servers listen on the same address.
In addition to a packet oriented protocol which is the preferred
method of communicating position data, this specification also
defines a session-oriented protocol, the purpose of which is to
provide means for reliable positioning information as well as an
extensible protocol for nodes to exchange information amongst
themselves.
4. Packet format
When used in packet mode, MIPP version 1 is a client of the UDP
protocol which in turn is a client of the IP protocol. Network byte
order is used throughout.
Floating numbers are encoded using a 32 bit floating numbers
according to IEEE 754. Agents which are unable to report their
positions using floating point numbers (e.g. J2ME based devices) may
use the stream and text based protocol described in another chapter.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN | R | L |I|D| Source | Reason | References |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Age (16) | Reserved (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Speed (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Course (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Digest (32) |
Bergek Expires February 2008 [Page 4]
Internet Draft MIPP (draft) July 31, 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional parameters (>=8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Number (VN): This is a four bit value indicating the MIPP
version. For version 1 of this specification, this value will be one.
Reserved / R: Reserved bits not used in this version of the protocol
and should be filled with zeros.
Lock (L): This is a two bit value indicating whether the positioning
receiver currently has acquired a lock on the positioning references
(i.e. for GPS it indicates whether the GPS receiver has lock on
sufficiently many satellites). The value should be interpreted as:
Value Lock type
------------------------------------------------------------------
0 The system has no knowledge on the position, not even a
previous value. This would be the case after coming out
of a cold-reset. The positioning data in the packet
should be zeroed out.
1 The system has previous knowledge on the location but the
reported position is stale. It is up to the receiver to
judge whether the position should be trusted. All
required fields of the packet will contain data. The
timestamp data shall contain the time when the position
was last acquired (where Lock was equal to three).
2 The system has lost contact with its primary positioning
references. A position fix is still provided but may be
inaccurate. The receiver should check bit six and seven
of the Source field to detect the presence of inertial
sensors and dead reckoning which would indicate that the
position may still be valid.
3 The system is operating under normal conditions and has
sufficient information to provide an accurate fix.
For all lock types except the first one (i.e. equal to zero), the
agent may specify the approximate error in position using the
designated additional parameters.
I: A boolean value that indicates the presence of inertial sensors
(i.e. combination of gyro and accelerometer or the simple one-
dimensional gyro with wheel rotation detection).
D: A boolean value that indicates the availability of dead reckoning
support. This would enable the agent to fill out short signal
Bergek Expires February 2008 [Page 5]
Internet Draft MIPP (draft) July 31, 2007
interruptions. The agent may provide information on the precision in
the value based on the time since last fix, combined with the speed
and course profile of the vehicle.
Source: This is an six bit value indicating the source of positioning
information. The value should be interpreted as:
Value Source type
------------------------------------------------------------------
0 Unknown
1 GPS
2 Galileo
3 GPS & Galileo
4 GLONASS
5 Beidou
Reason: The reason why this position update is sent. The agents may
be configured or the receivers may register to receive updates based
on a number of events. The reason is indicated by a one byte bit-
field where the different bits correspond to the following reasons:
Bit # Reason
------------------------------------------------------------------
0 Movement. The vehicle has moved a certain distance. The
distance can be configured in the server. A receiver may
also be able to request updates when the vehicle has
moved a certain distance.
1 Time. A sufficient passage of time has elapsed since the
last update. The time can be configured in the server. A
receiver may also be able to request updates when a
certain time has elapsed.
2 Stop. The vehicle has come to a stop.
3 Start. The vehicle has begun moving.
4 Signal acquired. The agent has acquired contact with its
primary positioning reference.
5 Signal lost. The agent has lost its primary positioning
reference.
6 Significant speed or course change. This allows precise
off-vehicle dead reckoning while sending very modest
amounts of data. The amount of change before an update
with this reason is sent should be configurable since it
is dependent upon the type of vehicle.
It is assumed that different applications of this protocol will
require different levels and hysteris settings for the above speed
and signal events. Thus, the levels are not specified here but
should be set for the individual application. As an example, the
signal could be said to have been acquired when the agent is
Bergek Expires February 2008 [Page 6]
Internet Draft MIPP (draft) July 31, 2007
tracking four simultaneous satellites or the the vehicle could be
said to have stopped after two seconds with a speed of less than 1
m/s.
References: The number of external references used to provide this
fix encoded as a one byte integer value. Depending on the type of
positioning system used, this value should be interpreted
differently. For satellites positioning systems such as GPS and
GALILEO, it indicates the number of satellites used for the fix.
Age: A two byte integer value that indicates the number of seconds
since the system last acquired a good fix (i.e. Lock equal to three).
Used by receivers to judge the validity of a position fix when the
system is out of coverage. The value is not signed and must not wrap
around (i.e. after 65535 seconds it will remain on that value until a
new fix is acquired).
ID: This is a system-wide unique identifier for the agent. Agents
should set this to their designated identifier which must be unique
within the system (i.e. within the same set of positioning nodes).
Timestamp: This is a 64-bit value of UTC time, coded in a UNIX long
time structure.
In the absence of a generally acceptable time format which does
not exhibit the shortcomings of time_t and other current
solutions, this protocol dictates the use of a long time_t
structure as suggested for ISO certification [DRT]. This is the
same as the time_t value but shifted 29 positions to the left. The
three additional most significant bits are used to increase the
range of time_t well beyond the 2038 wrap around date for UNIX
time_t timestamp while at the same time enable precise timing down
to nanoseconds. The agents are free to use the lower 29 bits of
the 64 bit value to encode the decimal part of the timestamp or
pad it with zero bits.
Latitude: This is the latitude of the position in radians, coded as a
32-bit IEEE 754 floating point number with a value of -PI/2 to +PI/2
where positive numbers indicate the Northern hemisphere.
Longitude: This is the longitude of the position in radians, coded as
a 32-bit IEEE 754 floating point number with a value of -PI to +PI
where positive numbers indicate the Eastern hemisphere.
Altitude: This is the height in metres above the used geoid, coded as
a 32-bit IEEE 754 floating point number.
Speed: This is the currently estimated speed in metres per second,
Bergek Expires February 2008 [Page 7]
Internet Draft MIPP (draft) July 31, 2007
coded as a 32-bit IEEE 754 floating point number.
Course: This is the currently estimated course made good (i.e. course
relative to the geoid), coded as a 32-bit IEEE 754 floating point
number.
Message Digest: This field is for authentication purposes. Agents
construct an MD5 hash as defined in [RFC1321] based on the the bits
provided by the ID, Timestamp, Latitude, Longitude, Altitude, Speed,
Course fields and finally a shared secret designated for the two
peers. That is, MessageDigest = MD5(ID + Timestamp + Latitude +
Longitude + Altitude + Speed + Course + Secret) where + denotes
concatenation. The receiver, knowing the secret, should do the same
computation and compare the resulting hash values. If the hash values
do not match, the receiver should silently drop the packet.
N.B. A standard MD5 hash is 128 bits long. For this protocol only the
lowest 32 bits are used (i.e. the last four bytes of the 16 byte
array which is the output of the MD5 generator).
The purpose of the message digest is to detect rogue agents
sending bogus data. The agent may not have a corresponding shared
secret for communication with the receiver in which case the agent
should clear the message digest. In that case it is up to the
receiver to decide whether the information contained in the packet
is to be trusted or not.
Additional parameters: This is a list of parameters that can include
a number of defined parameters as well as custom parameters. The
format of these are given below. An arbitrary number of extra
parameters may be included, provided that the size of the combined
packet, including headers, does not exceed the maximum transfer unit
(MTU) of the network. The size limitation applies to the UDP mode and
does not apply when the agent transmits updates using TCP. The
parameter list is ended by a zero byte where otherwise a new
parameter would start. The field must at least include a zero
(indicating a packet without any additional parameters).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size | Type | Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Size: The number of bytes used for this parameter, including the
Size, Type fields and the contained data. A zero (i.e. Size equals
zero) indicate the end of the parameter list. Receivers may safely
skip unknown parameters.
Bergek Expires February 2008 [Page 8]
Internet Draft MIPP (draft) July 31, 2007
Type: The type of data for this parameter. Values 0-127 are reserved
for future use while values 128-255 are vendor and application
specific and may be used freely.
Data: Any binary data. The receiver should use the type value to
learn how to decode this data.
Predefined types
The following parameter types are defined. Other types may be added
by later revisions of this specification. Vendor types may always be
used but must have a type value greater than or equal to 128.
Value Type description
------------------------------------------------------------------
1 Vehicle name. A human readable name of the system. The
string shall be coded as a UTF-8 string without any
termination character.
2 Odometer. A four byte integer value containing the
odometer (i.e. total distance travelled) in metres.
3 Country. The ISO-3166 country code of the country where
the current fix is located. Coded as a two byte integer
value.
4 Horizontal dilution of precision. This value can be used
to estimate the error of the position in the horizontal
plane. Encoded as a two byte integer value. This value
corresponds to the GPS NMEA data HDOP.
5 Vertical dilution of precision. This value can be used to
estimate the error of the position in the vertical plane.
Encoded as a two byte integer value. This value
corresponds to the GPS NMEA data VDOP.
6 Next update. The estimated maximum time in seconds when
the receiver can expect the next update from the agent.
5. Packet oriented operation
Receivers may operate without ever sending any data by listening to
messages sent to a unicast or broadcast address or the multicast
group address. This implies the existence of at least one agent that
sends unsolicited position updates.
5.1 Position update
An agent may from time to time send a position update to all
configured and registered receivers. In so doing, the agent will set
all fields in the packet and send the data to all configured and
registered receivers.
Bergek Expires February 2008 [Page 9]
Internet Draft MIPP (draft) July 31, 2007
6. Session oriented operation
The datagram based method described in the previous section is the
recommended method for onboard positioning information. As an
alternative to UDP, a stream based TCP method is described that can
be used to ensure message delivery.
MIPP commands, with the exception of the binary update verb described
below, are transmitted as textual lines. Lines consist of zero or
more data characters terminated by the sequence ASCII character "CR"
(hex value 0x0D) followed immediately by ASCII character "LF" (hex
value 0x0A). This sequence is henceforth denoted as <CRLF>.
MIPP commands and replies have a rigid syntax that closely resembles
the SMTP protocol. All commands begin with a command verb. The
general form of a reply is a numeric three digit completion code
(indicating failure or success) usually followed by a text string.
The codes are for use by programs and the text is usually intended
for human users.
In some commands and replies, arguments must follow the verb or reply
code. Some commands do not accept arguments (after the verb), and
some reply codes are followed, sometimes optionally, by free form
text. In both cases, where text appears, it is separated from the
verb or reply code by a space character.
6.1 Session initiation
A MIPP session is initiated when a client/agent opens a connection to
an agent/server and the agent/server responds with an opening
message.
MIPP agent or server implementations may include identification of
their software and version information in the connection greeting
reply after the 220 code. Implementations may make provision for
MIPP servers to disable the software and version announcement due to
security concerns.
6.2 MIPP commands
6.2.1 PUT
The receiver normally sends a 354 response to the PUTB command and
then changes mode to binary input. The sender shall then send
positioning updates in the same format as described for the datagram
method described earlier. The only difference is that each such
positioning update package shall start with two bytes indicating the
length of the data, including the two byte size indicator.
Bergek Expires February 2008 [Page 10]
Internet Draft MIPP (draft) July 31, 2007
The sender can exit the binary mode by sending two zero byte where
the server would expect the start of a new binary positioning update
package. When the receiver exits the binary mode it sends a 250 OK
reply.
6.2.2 QUIT
This command specifies that the receiver must send an OK reply, and
then close the transmission channel.
7. Security considerations
Positioning data are potentially valuable information. To protect the
integrity of the data, participating nodes should use the message
digest function described herein to detect if the data is changed in
transit or if bogus data is sent by a rogue agent. Further, it is
advised that servers employ white-listing based on peer addresses.
This specification does not include support for data confidentiality.
If the positioning data will travel on untrusted networks, it is
assumed that measures are taken to protect the data. This implies the
use of standard VPN technologies and is outside the scope of this
document.
Lastly, it must be remembered that while precise positioning data of
public vehicles will have many benign uses, it could also potentially
be of interest for terrorists and other malicious activities.
8. IANA considerations
This draft implies an assigned port to be used for this protocol. It
further implies that a multicast address is assigned.
9. References
[DRT] Tribble, David R., "ISO C 200X Proposal: Long Time Type",
March 2006, http://david.tribble.com/text/c0xlongtime.html
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1712] C. Farrell et al. "DNS Encoding of Geographical Location."
RFC 1712, November 1994.
Acknowledgements
Bergek Expires February 2008 [Page 11]
Internet Draft MIPP (draft) July 31, 2007
Thanks to, in no special order, Johan Berts, Mats Hojlund, Johannes
Kristinsson and Mikael Strid.
Authors' Addresses
Martin Bergek
Icomera AB
Vikingsgatan 3
SE-41104 Gothenburg
Sweden
Comments are solicited and should be addressed to
contact_ietf@icomera.com.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
Bergek Expires February 2008 [Page 12]
Internet Draft MIPP (draft) July 31, 2007
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Bergek Expires February 2008 [Page 13]
