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]