Internet DRAFT - draft-haerri-manet-position-signaling
draft-haerri-manet-position-signaling
Mobile Ad hoc Networking (MANET) J. Haerri
Internet-Draft Karlsruhe Institute of Technology
Intended status: Experimental (KIT), Germany
Expires: January 15, 2009 C. Bonnet
F. Filali
Institut Eurecom, France
July 14, 2008
MANET Position and Mobility Signaling Format
draft-haerri-manet-position-signaling-01
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Haerri, et al. Expires January 15, 2009 [Page 1]
Internet-Draft MANET Position Signaling July 2008
Abstract
This document describes an extension to the node metric TLV defined
in the MetricTLV document to specify a configurable structure to
exchange position and mobility information for MANET protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Representing Position . . . . . . . . . . . . . . . . . . . . 7
6. Representing Time . . . . . . . . . . . . . . . . . . . . . . 8
7. Metric TLV containing Position Information . . . . . . . . . . 9
7.1. Message TLV . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Address Block TLV . . . . . . . . . . . . . . . . . . . . 9
7.3. Position Information Semantic . . . . . . . . . . . . . . 10
7.3.1. Constraints . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Message Layout . . . . . . . . . . . . . . . . . . . 16
A.1. Mobility TLVs . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Haerri, et al. Expires January 15, 2009 [Page 2]
Internet-Draft MANET Position Signaling July 2008
1. Introduction
The generalized packet/message format [PacketBB] specifies a
signaling format which MANET routing protocols can employ for
exchanging protocol information. This format presents the ability to
express and associate attributes to packets, messages or addresses,
by way of a general TLV (type-length-value) mechanism.
The MANET MetricTLV document [MetricTLV] specifies a general metric
TLV structure compatible with the generalized packet/message format
and which can be used by MANET protocols that need to use and
exchange metrics associated with a link or a node.
Position information is a particular metric that is associated with a
node and that may be beneficial for MANET protocols as described in
[GeoProblemStatement]. Position information is usually not a unique
metric but is associated with other metrics such as speed, azimuth or
sampling time. Although the MANET Metric document [MetricTLV] is
able to specify the individual structure of each of them, due to
their correlations and the possible different transmission formats
that are still under discussion, we propose to describe a common
structure for the exchange of position and mobility information in a
separate document.
This document specifies a Mobility structure, which MAY be used by
any MANET routing protocol that needs to exchange geolocalization
information using the MANET Metric format and the generalized MANET
packet/message format. If it is used as a message TLV, it allows a
receiving node to obtain the position, the azimuth or the velocity of
a sending node in a configurable way. If it is used as an address
block TLV, it allows a receiving node to obtain the position, the
azimuth or the velocity of nodes different from the sending node.
Haerri, et al. Expires January 15, 2009 [Page 3]
Internet-Draft MANET Position Signaling July 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119].
Additionally, this document uses the terminology from [PacketBB]
and [MetricTLV], and introduces the following terminology
GPS - Global Positioning System. A geolocalization system
developped and operated by the US Department of Defense that is
able to provide accurate worldwide coordinates of devices equiped
with GPS receivers. A similar European system is currently under
developpement under the name of Galileo. The GPS system does not
work without a clear access to at least 3 satellites, thus is
inoperable for indoor positioning.
GPS-free Positioning - A set of techniques that has been developped
in order to provide a mean of localization in situation when a
clear access to satellites is not possible. Most of the methods
uses multilateration techniques and requires either a formal
training, or an anchor node that knows its accurate position.
Time - The universal GPS time expressed in seconds.
Longitude - The longitude describes the location of a place on Earth
east or west of a north-south line called the Prime Meridian
located in Greenwich, UK. Longitude is given as an angular
measurement ranging from 0 degree at the Prime Meridian to +180
degree eastward and -180 degree westward.
Latitude - The latitude gives the location of a place on Earth north
or south of the equator. Latitude is an angular measurement
ranging from 0 degree at the Equator to 90 degree at the poles.
Elevation - The elevation is the altitude of an object from a known
level or datum. Common datums are mean sea level and the surface
of the WGS-84 geoid used by GPS.
Azimuth - Azimuth is the horizontal component of a direction,
measured around the horizon, from the north toward the east in the
northern hemisphere, and from the south toward the west in the
southern hemisphere.
Mobility - mobility information related to a specific address, which
MAY consist of a longitude, latitude or elevation, a velocity, an
azimuth, and the time this mobility information has been sampled.
Haerri, et al. Expires January 15, 2009 [Page 4]
Internet-Draft MANET Position Signaling July 2008
3. Applicability Statement
The mobility structure described in this document is applicable in
conjuction with [MetricTLV] whenever the transmission of the
position, the velocity or the azimuth of a node or of a set of nodes
is required by a MANET protocol using the generalized MANET packet/
message format [PacketBB].
Haerri, et al. Expires January 15, 2009 [Page 5]
Internet-Draft MANET Position Signaling July 2008
4. Protocol Overview and Functioning
This specification does not describe a protocol, nor does it mandate
specific node or protocol behavior. Rather, it describes mechanisms
for encoding position information using an extension to the TLV
mechanism of [MetricTLV] and [PacketBB].
Protocols using the structure specified in this documents MUST
transmit position information of the local node using a message TLV,
while general position information of other nodes MUST be encoded
using an address TLV block.
Haerri, et al. Expires January 15, 2009 [Page 6]
Internet-Draft MANET Position Signaling July 2008
5. Representing Position
This document specifies an extension to the metric TLV structure to
transmit position information consisting of the 3-tuple longitude,
latitue and elevation, optionally added with the speed and azimuth of
a mobile node.
This document assumes the availability of a GPS (Global Positioning
System) for the sampling of these informations, but is not limited to
it as long as any other system is able to provide a similar position
information format.
This document proposes to transmit mobility information according to
the following two structure formats:
o A standard format able to support the data format provided by GPS
devices.
o A reduced format that encodes the minimum required mobility data
in multiples of a byte in order to limit the size of a TLV
containing mobility information and thus reducing the transmission
overhead.
Due to the specificity of position information, all possible values
MUST be representable. An exponential representation is therefore
not possible. Accordingly, the exprep field specified in [MetricTLV]
MUST be cleared.
Haerri, et al. Expires January 15, 2009 [Page 7]
Internet-Draft MANET Position Signaling July 2008
6. Representing Time
In order to reconstruct the current position or have an estimation of
the freshness of the position information, this document also
specifies the transmission of the position sampling time. As no
synchronization is assumed in this document, the time shared by all
nodes using this document MUST be the GPS time.
GPS (Global Positioning System) time is the atomic time scale
implemented by the atomic clocks in the GPS ground control stations
and the GPS satellites themselves. GPS time is expressed as a number
of seconds since the beginning of the GPS epoch on Sunday January 6th
1980 at 0:00 UTC.
Due to the specificity of the sampling time of position information,
all possible values MUST be representable. A time representation
similar to [TimeTLV] is therefore not possible, and neither is any
exponential representation. Accordingly, the exprep field specified
in [MetricTLV] MUST be cleared.
The GPS time is usually represented by an 64 bit field. In order to
reduce the size of this field, a new reference point common to any
node in the network may be used instead of the GPS epoch. Yet, the
specification of methods to reduce the size of the GPS sampling time
it is out of scope of this document. However, this document
specifies an optional reduced size field of 16 bits for the
transmission of such reduced information.
Haerri, et al. Expires January 15, 2009 [Page 8]
Internet-Draft MANET Position Signaling July 2008
7. Metric TLV containing Position Information
This specification defines an extended structure for one message
block TLV structure or one address block TLV structure for the
inclusion of position information. When using the structure
described in this document, both TLV structures MUST have the
thastypeext bit set to 1 in the tlv-semantics field as defined in
[PacketBB].
7.1. Message TLV
A position metric message TLV SHOULD be used for signaling position
information associated with the local node. If a metric message TLV
is to be included in a message, the originator-address MUST be
included in the msg-header-info as defined in [PacketBB].
The <tlv-type-ext> of the metric message TLV is further defined in
this document :
The 'exprep' bit of the <m-metric-semantic> as defined in
[MetricTLV] MUST be cleared, as an exponential representation MUST
NOT be used for Mobility information.
The <value-type> field as specified in [MetricTLV] contains a 7
bit field containing the value type of the metric being coveyed.
This document proposes the following layout to specify the
presence of position information:
+--------------+------------------------+
| M-value | Value Representation |
+--------------+------------------------+
| TBD | Mobility Metric |
+--------------+------------------------+
Figure 1
7.2. Address Block TLV
A position metric address block TLV SHOULD be used for signaling a
node metric associated with any other node than the local node.
The <tlv-type-ext> of the metric address block TLV is further defined
in this document:
Haerri, et al. Expires January 15, 2009 [Page 9]
Internet-Draft MANET Position Signaling July 2008
The 'exprep' bit of the <m-metric-semantic> as defined in
[MetricTLV] MUST be cleared, as an exponential representation MUST
NOT be used for Mobility information.
The 'outbound' and 'inbound' bits of the <m-metric-semantic> as
defined in [MetricTLV] MUST be cleared according to the following
layout:
+----------+----------+----------------------+
| Inbound | Outbound | Value Representation |
+----------+------+--------------------------+
| 0 | 0 | Node Metric |
+----------+----------+----------------------+
Figure 2
The <value-type> field as specified in [MetricTLV] contains a 5
bit field containing the value type of the metric being coveyed.
This document proposes the following layout to specify the
presence of position information:
+--------------+------------------------+
| M-value | Value Representation |
+----+----+----+----+----+----+----+----+
| TBD | Mobility Metric |
+--------------+------------------------+
Figure 3
7.3. Position Information Semantic
The <value> field of a Metric TLV when the <m-value-type> specifies a
Mobility metric is encoded according to the following layout
<value> = {<value-semantic><mobility>}*
where:
<value-semantic> is an 8 bit field which describes the stucture of
the <mobility> tag.
Haerri, et al. Expires January 15, 2009 [Page 10]
Internet-Draft MANET Position Signaling July 2008
bit 0 (position bit): TLV with this bit cleared ('0') does not
contain the position of the local node or of the address in the
respective address block. TLVs with this bit set ('1')
contains position information.
bit 1 (velocity bit): TLV with this bit cleared ('0') does not
contain the velocity of the local node or of the address in the
respective address block. TLVs with this bit set ('1')
contains the velocity.
bit 2 (azimuth bit): TLV with this bit cleared ('0') does not
contain the azimuth of the local node or of the address in the
respective address block. TLVs with this bit set ('1')
contains the azimuth.
bit 3 (reduced format bit): TLV with this bit cleared ('0') does
not contain position information of the address in the
respective address block or of the local node using the reduced
format. TLVs with this bit set ('1') contains position
information encoded using a reduced format.
bits 4-7 are RESERVED They MUST be cleared ('0')to be in
conformance with this version of the specification.
<mobility> is a field containing the mobility parameters. The
length of this field may be obtained from the <value-semantic>
field. The <mobility> field is specified by:
<mobility> = {<pos><azi>?<velo>?<time>}
where, when the 'reduced format' bit is set:
<pos> is a 48 bit field containing the coordinates of a node
following the general layout:
<pos> = <Longitude><Latitude><Elevation>
<velo> is an 8 bit field containing the node's velocity in m/s.
<azi> is an 8 bit field containing the node's azimuth in
degree.
<time> is an 16 bit field containing the GPS time in seconds
when these mobility parameters have been sampled.
Haerri, et al. Expires January 15, 2009 [Page 11]
Internet-Draft MANET Position Signaling July 2008
or when the 'reduced format' bit is cleared:
<pos> is a 96 bit field containing the coordinates of a node
following the general layout
<pos> = <Longitude><Latitude><Elevation>
<velo> is an 16 bit field containing the node's velocity in
m/s.
<azi> is an 16 bit field containing the node's azimuth in
degree.
<time> is an 64 bit field containing the GPS time in seconds
when these mobility parameters have been sampled.
7.3.1. Constraints
o If the bit <azi> is set ('1'), the bit <velo> MUST also be set
('1').
o The position extension only applies either to message TLVs or to
address block TLVs consisting of a single and unique address.
Haerri, et al. Expires January 15, 2009 [Page 12]
Internet-Draft MANET Position Signaling July 2008
8. IANA Considerations
This document does not specify any message TLV type.
Haerri, et al. Expires January 15, 2009 [Page 13]
Internet-Draft MANET Position Signaling July 2008
9. Security Considerations
This document is subject to similar security issues as [PacketBB].
Accordingly, similar security considerations may be undertaken.
Haerri, et al. Expires January 15, 2009 [Page 14]
Internet-Draft MANET Position Signaling July 2008
10. Normative References
[GeoProblemStatement]
Haerri, J., Bonnet, C., and F. Filali, "MANET Position and
Mobility Signaling: Problem Statement", <tools.ietf.org/
html/draft-haerri-manet-position-problem-statement-01>.
[MetricTLV]
Dean, J., "Representing metric values in MANETs",
<tools.ietf.org/id/draft-dean-manet-metriclv-01.txt>.
[PacketBB]
Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format",
<tools.ietf.org/id/draft-ietf-manet-packetbb-13.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TimeTLV] Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs",
<tools.ietf.org/html/draft-ietf-manet-timetlv-04.txt>.
Haerri, et al. Expires January 15, 2009 [Page 15]
Internet-Draft MANET Position Signaling July 2008
Appendix A. Message Layout
This section specifies the translation from the abstract descriptions
of the Mobility TLVs in this document, and the bit-layout Mobility
TLVs actually exchanged between nodes.
A.1. Mobility TLVs
The basic layout of the <value-semantic> field in the <value> field
of a TLV is as follows:
+----+----+----+----+----+----+----+----+-----------------------+
| Semantic | Value |
+----+----+----+----+----+----+----+----+ |
| 7 6 5 4 3 2 1 0 | |
|Resv|Resv|Resv|Resv|Red |Azim|Velo|Pos | |
+----+----+----+----+----+----+----+----+-----------------------+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | Mobility TLV with |
| | position only |
+----+----+----+----+----+----+----+----+-----------------------+
| 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | Mobility TLV with all|
| | mobility information |
+----+----+----+----+----+----+----+----+-----------------------+
| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | Mobility TLV with |
| | velocity and position |
| | with reduced format |
+----+----+----+----+----+----+----+----+-----------------------+
| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | Mobility TLV with all |
| | mobility information |
| | with reduced format |
+----+----+----+----+----+----+----+----+-----------------------+
Figure 4
where, according to the bits cleared or set in the <value-semantic>
field and the related constraints, other combinations are possible.
Haerri, et al. Expires January 15, 2009 [Page 16]
Internet-Draft MANET Position Signaling July 2008
The basic layout of a Mobility TVL with the 'reduced format' bit
cleared is as follows:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Res|0|0|1|0|0|1| Type-Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |0|1|1|1| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude | Elevation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elevation | Velocity | Azimuth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Azimuth | Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+
Figure 5
where all mobility parameters have been displayed. According to the
bits cleared or set in the <value-semantic> field and the related
constraints, other combinations are possible.
Haerri, et al. Expires January 15, 2009 [Page 17]
Internet-Draft MANET Position Signaling July 2008
Authors' Addresses
Jerome Haerri
Karlsruhe Institute of Technology (KIT), Germany
Phone: +49 721 608-6407
Email: jerome.haerri@kit.edu
Christian Bonnet
Institut Eurecom, France
Phone: +33 4 93 00 8108
Email: bonnet@eurecom.fr
Fethi Filali
Institut Eurecom, France
Phone: +33 4 93 00 8134
Email: filali@eurecom.fr
Haerri, et al. Expires January 15, 2009 [Page 18]
Internet-Draft MANET Position Signaling July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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
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.
Haerri, et al. Expires January 15, 2009 [Page 19]
