Internet Draft M. Bergek Icomera Category: Informational July 31st, 2007 Expires February 2008 Mobile Infrastructure Positioning Protocol (MIPP) version 1 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 . 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]