[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Draft                                            Hong-Yon Lach
draft-lach-nemo-experiments-overdrive-01.txt       Christophe Janneteau
Expires: April 2003                                    Alexis Olivereau
                                                     Alexandru Petrescu
                                                               Motorola
                                                        Tim Leinmueller
                                                        Michael M. Wolf
                                                        DaimlerChrysler
                                                            Markus Pilz
                                                     University of Bonn

                                                          October  2003


     Laboratory and "Field" Experiments with IPv6 Mobile Networks
                      in Vehicular Environments
            <draft-lach-nemo-experiments-overdrive-01.txt>


Status of this Nemo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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.

Abstract

   This document gives a short high-level overview of experiments
   performed with IPv6 mobile networks using Mobile IPv6-based NEMO
   extensions in the context of the IST OverDRiVE project.  Laboratory
   experiments include simple and nested mobile networks in a pure
   IPv6 environment while "field" experiments demonstrated continuous
   IPv6 vehicular connectivity over two publicly deployed IPv4
   networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and
   inside a metropolitan area.  Lessons learned included the necessity
   for Route Optimization protocols for mobile networks, NAT traversal
   and IPv4-to-IPv6 transition protocols in public access wireless
   networks.






Lach, et al.             Expires April 2003                    [Page 1]


Internet Draft           OverDRiVE Experiments             23 June 2003

Table of Contents

   Status of this Nemo................................................1
   Abstract...........................................................1
   Conventions Used in this Document..................................2
   1. IST OverDRiVE Project...........................................2
   2. Laboratory Experiments..........................................3
   3. "Field" Experiments.............................................6
   4. Conclusions and Future Work....................................10
   Acknowledgements..................................................10
   References........................................................11
   Authors' Addresses................................................12
   Changes...........................................................12
   Copyright Notice..................................................13

Conventions used in this document

   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 RFC-2119 [1].

1. IST OverDRiVE Project

  Work Package 3 of the European research project OverDRiVE [3] aims
  at developing IPv6 protocol mechanisms to support mobility of hosts,
  as well as of networks, that are deployed in vehicular
  environments. The scenarios envision that future vehicular
  environments in trains, ships or vehicles provide on-line
  information to the driver and passengers; provide even access to the
  vehicular communication components from the outside world
  (e.g. allow for software downloads be pushed to car computers). All
  electronic devices deployed in a vehicle (PCs, head screens, engine
  computers and sensors) are connected together with IPv6 protocols,
  and to the IPv6 Internet; the connection is realized either directly
  or through other IPv4 tunneling and gatewaying means.

  The project has defined a set of scenarios which should be supported
  by a mobility (and security) solution [8]. The following two major
  characteristics are valid for all scenarios:

    - Session continuity while changing the point of attachment to the
      Internet.

    - Reachability of the mobile nodes regardless of the current point
      of attachment.

  Thus, several functional scenarios become relevant:

    - Moving of an Intra-Vehicular Area Network (IVAN): the IVAN moves
      homogeneously (network entities stay together) using a mobile
      router to provide the Internet connectivity for nodes within the
      IVAN.

    - Moving into an IVAN with a mobile device. The mobile host moves
      into an IVAN and changes its WMAN connection to a WLAN
      connection, or its UMTS connection to a Bluetooth connection.

    - Moving within an IVAN: in a larger IVAN (e.g. in a train)
      topological hierarchies might be used, involving more than one
      fixed (with respect to IVAN) or mobile router. Mobile nodes can
      move around inside the IVAN connecting to the appropriate access
      router inside the IVAN.




Lach, et al.             Expires April 2003                    [Page 2]


Internet Draft           OverDRiVE Experiments             23 June 2003

2. Laboratory Experiments

  Several laboratory experiments in a pure IPv6 network were performed
  with mobile hosts and mobile networks.  In some scenarios, more than
  one Local Fixed Node and one Correspondent Node were used; for
  example, in some scenarios there is an additional Mobile Host, or
  there are two mobile networks each hosting a Local Fixed Node.
  During all experiments, the mobility management messaging (between
  MR and HA, or between MH and HA) was not interrupting the end-to-end
  communication between these entities, even if several changes in
  Care-of Address were occuring.  The end-to-end communications were
  happening between the LFN and the CN, or between two LFN's, or
  between one MH and one LFN, or between one MH and one CN.  The CN's
  used were local video streaming servers and other servers connected
  on other parts of the worldwide IPv6 Internet.

  A simple mobile network is composed of one Mobile Router and one
  Local Fixed Node, see Figure 1.  The mobile network is initially
  attached at home and moves subsequently to Access Router AR1 and
  AR2.

                                                ----  CN link
                                             --| BR1|------
     ----                                   /   ----     |
    | HA |                                 /           ----
     ----                       ----------/           | CN |
       |            -------    |          |            ----
   ----------------| BR    |---| Network  |--------------
       | home link  -------    |          |              |
     ----    -----              ----------\              |
    | MR |  | LFN |                        \             |
     ----    -----                          \            |
       |       |                         ------        ------
       ---------                        | AR1  |      | AR2  |
     mobile net link                     ------        ------
                                            |             |

                   Figure 1: Simple Mobile Network

  Figure 2 depicts another setting with one Mobile Router, one Mobile
  Host, same Home Agent.  In a first scenario, the mobile network
  starts at home and then moves under AR1 and AR2.  The Mobile Host
  stays at home.



Lach, et al.             Expires April 2003                    [Page 3]


Internet Draft           OverDRiVE Experiments             23 June 2003

  Related to the same figure, another scenario is that the mobile
  network and the mobile hosts are first placed at home and then the
  mobile host moves under the mobile network.  Subsequently the mobile
  network moves together with the mobile host under AR1 and AR2.

  And still with the same figure, yet another scenario; every entity
  is at home, then MH moves under AR1, then the mobile network moves
  too under AR1; then MH moves towards the mobile network and,
  finally, the mobile network moves to AR2.


                                                ----  CN link
                                             --| BR1|------
     ----   ----                            /   ----     |
    | HA | | MH |                          /           ----
     ----   ----                ----------/           | CN |
       |      |     -------    |          |            ----
   ----------------| BR    |---| Network  |--------------
       | home link  -------    |          |              |
     ----    -----              ----------\              |
    | MR |  | LFN |                        \             |
     ----    -----                          \            |
       |       |                         ------        ------
       ---------                        | AR1  |      | AR2  |
     mobile net link                     ------        ------
                                            |             |

           Figure 2: Mobile Router and Mobile Host at Home

  Figure 3 shows a setting where the mobile router and the mobile host
  have different Home Agents.  Various movements were performed.
                                              ----
                                           --| CN |
   ----                                   /   ----        ----   ----
  | HA1|                                 /               | HA2| | MH |
   ----                       ----------/                 ----   ----
     |            -------    |          |      -------      |      |
 ----------------| BR    |---| Network  |-----| BR    |--------------
     | home link  -------    |          |      -------
   ----    -----              ----------\
  | MR |  | LFN |                        \
   ----    -----                          \
     |       |                         ------
     ---------                        | AR1  |
   mobile net link                     ------
                                            |

    Figure 3: Mobile Network and Mobile Host with Different Homes


  In figure 4, the Mobile Host and the Mobile Router have two
  different Home Agents, both situated on the same home link.  Various
  movements were performed.



Lach, et al.             Expires April 2003                    [Page 4]


Internet Draft           OverDRiVE Experiments             23 June 2003

                                                  ----  CN link
                                               --| BR1|------
   ----   ----   ----                         /   ----     |
  | HA1| | HA2| | MH |                       /           ----
   ----   ----   ----             ----------/           | CN |
    |      |      |   -------    |          |            ----
  -------------------| BR    |---| Network  |--------------
         | home link  -------    |          |              |
       ----    -----              ----------\              |
      | MR |  | LFN |                        \             |
       ----    -----                          \            |
         |       |                         ------        ------
         ---------                        | AR1  |      | AR2  |
       mobile net link                     ------        ------
                                              |             |
             Figure 4: Home Agents on the Same Home Link

  In figure 5, one Home Agent is placed in the mobile network.
  Various movements were performed.

                                                ----  CN link
                                             --| BR1|------
     ----                                   /   ----     |
    | HA1|                                 /           ----
     ----                       ----------/           | CN |
       |            -------    |          |            ----
   ----------------| BR    |---| Network  |--------------
       | home link  -------    |          |              |
     ----    -----              ----------\              |
    | MR |  | LFN |                        \             |
     ----    -----                          \            |
       |       |                         ------        ------
       ---------                        | AR1  |      | AR2  |
       |       |                         ------        ------
      ----   ----                           |             |
     | HA2| | MH |
      ----   ----

              Figure 5: Home Agent in the Mobile Network

  An additional range of laboratory experiments were performed and
  reported in section 2.4 of [8].  Examples include:

    -a single Home Agent and two similar mobile networks, each
     composed of one Mobile Router and one Local Fixed Node.

    -two Home Agents and two Mobile Routers (one Home Agent for one
     mobile network), but still one home link.

    -two Home Agents and two Mobile Routers (one Home Agent for one
     mobile network), but on different home links.

    -a Home Agent placed inside a mobile network serving another
     mobile network attached to the first.


Lach, et al.             Expires April 2003                    [Page 5]


Internet Draft           OverDRiVE Experiments             23 June 2003

   The descriptions in section 2.4 of [8] include details of tunnel
   setup procedures and illustrations of MN-HA encapsulations, as well
   as packet paths between various entities.  The laboratory
   experiments helped highlighting several areas for protocol
   improvement of the basic support of network mobility:

     -Excessive tunnelling ("thick" tunnels): when MH attaches to the
      mobile network there are two MRHA encapsulating tunnels involved
      in the CN-MH path. Several levels of mobile networks induce
      excessive tunnelling that can lead to serious packet loss and
      worsen stack behaviour due to excessive
      fragmentation/reassembly. This is especially true in wireless
      environments.

     -Crossover tunnels happen when the path between one tunnel's
      endpoints includes only one of the other tunnel's endpoints . A
      situation leading to crossover tunnels is depicted in Figure 16
      of [8], where a HA is deployed inside a mobile network. The
      initial configuration is in diagram a and diagrams b, c and d
      represent snapshots of the movement scenario.  The MR2HA2 tunnel
      setup procedure corresponding for the diagram d is practically
      impossible to perform.

     -Externally influenced intra-aggregation communication (or
      disconnected operation problem): in the MH and MR with same HA
      case, depicted in diagram c of Figure 12 of [8], the LFN-MH
      communication (intra-aggregation) is influenced by the
      communication between MR and AR1 (external).  If MR looses
      connection to AR1, then LFN looses connection to MH, a fact
      that, as paradoxical as it may seem, is a veritable side effect
      of tunnelling itself.

     -Under-optimal paths: when comparing the length of the CN-MH
      communication path depicted in top-left diagram of Figure 13 of
      [8] to the CN-MH communication in Figure 15 of [8], it is clear
      that the path taken by packets is much longer than the
      optimal. The first diagram can be considered as an ideal to be
      attained, and the only optimal path that can be achieved is
      CN-AR-MR-MH (eliminating the BR-HA-BR additional segment). This
      is not the ideal path (since MH is not physically home) but
      represents an achievable goal, if employing Route Optimization
      techniques.

     -Asymmetric communication paths: outgoing communication paths
      have different lengths than incoming communication paths,
      between the same two entities. See example in Figure 14 of [8].

3. "Field" Experiments

  "Field" experiments were performed in a typical deployment of
  wireless networks.  An overall picture of the experiments is
  described in Figure xx.  Three wireless access networks are
  depicted: the home network (hosting the Home Agent), the Orange
  network (an European Telecom operator for mobile phones) and the
  Wixos network (a WiFi HotSpot network deployed in a large city).

Lach, et al.             Expires April 2003                    [Page 6]


Internet Draft           OverDRiVE Experiments             23 June 2003

  The three networks are inter-connected at Internet level.  The
  Mobile Network, pictured at the bottom, was obtaining Internet
  access via one of the three Wireless Access Networks.

                       ------------             -----------
                      |  Internet  |-----------| Web Server|
                      /------------\            -----------
                     /       |      \
                    /        |       \
                   /         |        \
             --------     --------   -------
            |Home Net|   | Orange | | Wixos |
             --------     --------   -------
                |            |           |
                     Wireless Access


            WLAN    GPRS
              |      |
             ----------
            |Mobile Net|  ---------->
             ----------

           Figure xx: Overall Picture of Field Experiments

3.2 Mobile Network

  The mobile network used in the field experiments is a very simple
  wireless segment (802.11b in ad-hoc mode) linking together an IPv6
  Mobile Router and a Local Fixed Node running user applications
  (notably an http client).  In addition, the mobile network contained
  two boxes helping interconnect the MR to the wireless access
  networks (FrontBoxes).  Inside the mobile network, IPv6 protocols
  are used exclusively; the Mobile Router runs an implementation of
  Mobile IPv6 Mobile Router in implicit mode [2].  However, both Orange
  and Wixos offer IPv4 access exclusively.  FrontBoxes help solve this
  problem.

  Front boxes are entities connected to the Mobile Router that help
  differentiate between mobility management tasks and particular link
  layer/tunnelling functionalities. The GPRS Front Box establishes a
  GPRS connection (i.e. establishes a PPPv4 connection, through a PDP
  Context to the GPRS SGSN), configures an IPv4 interface and
  establishes a UDP tunnel through a NAT box to the home IPv6 network,
  all over its egress interface.  The ingress interface of the
  FrontBox is assigned an IPv6 address and prefix (deduced from the
  IPv6 prefixes of the home network); the FrontBox sends IPv6 Router
  Advertisements over its ingress interface towards the Mobile Router.
  Tunnelling IPv4 packets into UDP IPv4 streams in order to traverse
  NAT is proposed in [12].  In these experiments, IPv6 packets were
  tunneled instead.

  Similarly, the Wireless LAN Front Box offers native IPv6
  connectivity towards the Mobile Router, when the mobile network
  attaches to the Wixos WiFi HotSpot network.

Lach, et al.             Expires April 2003                    [Page 7]


Internet Draft           OverDRiVE Experiments             23 June 2003

3.3 Home Network

  The home network is connected to both IPv4 and IPv6 Internets.  It
  hosts an IPv6 Home Agent, a 6to4 Gateway and a Udptun Gateway.  The
  Home Agent runs Mobile IPv6 with NEMO implicit mode [2].  The Udptun
  Gateway constitutes the UDPv4 tunnel endpoint for both the GPRS and
  WLAN FrontBoxes.

  In addition, the home network offers two WLAN access points towards
  the mobile network.  One of the AP's is connected to the home link
  (where HA resides); the other AP is attached to another link of the
  home network.  Both AP's offer native IPv6 connectivity towards the
  Mobile Router; when the MR connects to the home network AP's, it
  does by bypassing the FrontBoxes.

3.4 Orange Wireless Access (GPRS)

  The GPRS access system offer IPv4 access with a private addressing
  scheme.  It distributes private non-routable addresses (10.x.y.z)
  over a PPP connection, addresses being assigned by DHCP servers.
  This network is connected to the Internet with NAT boxes.

3.5 Wixos Wireless Access (WLAN)

  Wixos is an 802.11b Metropolitan Area Network.  During June 2003,
  the Wixos network was available for public experimentation.  For
  more information about the Wixos network see [6].  Disclaimer: none
  of the participants in the IST OverDRiVE project are affiliated, or
  represent, in any legal or other way the Wixos Network.  The Wixos
  network was used as a public access network.

  The network offers IPv4 access in several "hotspot" areas.  Most of
  the hotspots are not overlapping (in terms of wireless coverage).
  The IPv4 network offers private non-routable IPv4 addresses.  The
  network was not using, at the time of testing, any form of Mobile
  IPv4; an address acquired in one WiFi hotspot is not valid under
  another WiFi hotspot of the same Wixos network.

3.6 Scenarios and Results

  In one scenario, the mobile network was first connected to the home
  network outside the metropolitan area, then moved onto the highway,
  then entered a metropolitan area hotspot, then went out of the
  hotspot and entered again another hotspot.  During all this
  trajectory, a continuous IPv6 connection was maintained between the
  Local Fixed Node and a Correspondent Node (web server kame.net,
  placed in Japan) connected on the IPv6 Internet.

  In another scenario, the Local Fixed Node running exclusively IPv6
  protocols, browsed an IPv4 web server.  This could be accomplished
  by configuring a "proxy" server on the LFN client.  The proxy server
  is connected to both the IPv6 and IPv4 Internets; it is physically
  placed at University of Bonn.  The proxy server converts http IPv6
  requests into IPv4 requests, forwards the request to the IPv4
  Internet, and forwards the received IPv4 reply back to the IPv6
  client of the LFN.
Lach, et al.             Expires April 2003                    [Page 8]


Internet Draft           OverDRiVE Experiments             23 June 2003

  The first mobility scenario (mentioned above) involved a dynamic
  change of IP addresses (both v4 and v6) to the Mobile Router.
  However, the IPv6 address of the LFN was not changing and, as such,
  the applications running on the LFN were not interrupted.  Hiding
  the change of IP address was performed at two levels of different
  granularity.  The dynamics of address assignment to the Mobile
  Router and FrontBoxes is depicted in figure xx.


  AP1     AP2     BS1     BS2    shadow    BS3     AP3     BS4     AP4

   \______/        \_______|_______/        |       |       |       |
    No ad                 ad1              ad2     ad3     ad4     ad5

   |       |       \_______|_______________/        |       |       |
  AD1     AD2                    AD3               AD4     AD3     AD4

       Figure xx: Dynamics of IPv4 and IPv6 Address Assignment

  The first line in figure xx depicts the sequence of WLAN Access
  Points and GPRS Base Stations to which the Mobile Router and
  FrontBoxes attach.  AP1 and AP2 are both in the home network (AP1
  connects HA).  BS1 and BS2 are deployed along the highway segment,
  and the "shadow" area depicts an uncovered segment along the highway
  (a tunnel).  BS3 is deployed at junction zone between highway and
  city.  AP3 and AP4 are the hotspot areas, separated by BS4.

  Dynamics of IPv4 address change show a high level of granularity
  (fine-grained).  The IPv4 addresses distributed either by GPRS or by
  WLAN are pictured on the second line, lower case.  When the mobile
  network connects to the home network, no IPv4 address is assigned.
  Under BS1 and BS2, the mobile network is assigned IPv4 address ad1.
  Switching between these two BS's does not incur a change in the IPv4
  address, ad1 is kept.  Due to the presence of the shadow area (the
  uncovered tunnel), the mobile network will be assigned a new IPv4
  address (ad2) under BS3.  Even though GPRS ensures the same IPv4
  address assigned to a mobile, there exists no mechanism to assign
  the same IPv4 address to the same mobile following a short
  disconnection.

  Dynamics of IPv6 address change show a lower level of granularity
  (coarse-grained).  Assignment of IPv6 addresses to the Mobile Router
  (the Care-of Addresses) is pictured on the bottom line.  At home,
  IPv6 addresses AD1 and and AD2 are assigned to the Mobile Router,
  AD1 being the Home Address.  Whenever the GPRS FrontBox is conneted
  to a BS, AD3 is assigned to the Mobile Router (BS1-4).  Whenever the
  WLAN FrontBox is connected to an AP (AP3-4), AD4 is assigned to MR.

  Less change in the IPv6 address of the MR reduces the number of
  binding information exchanges with the Home Agent.  For example,
  when there is a change ad1-ad2, the corresponding address AD3
  Care-of Address is stable, no need to inform the Home Agent.

  During the experimentation, the dynamics of encapsulation (v6-in-v6
  and v6-in-v4) was also observed.  For further information and
  lessons learned, see [10].
Lach, et al.             Expires April 2003                    [Page 9]


Internet Draft           OverDRiVE Experiments             23 June 2003

4. Conclusions and Future Work

  This report described laboratory and field experiments with an IPv6
  mobile network.  A wide range of laboratory experiments showed the
  viability of NEMO-based network mobility protocols to support
  scenarios with simple mobile networks, nested mobile networks, and
  mobile HA's.  At the same time, the experiments helped proving the
  analytical expectations (such as excessive encapsulations) and also
  raised new problems (such as crossover tunneling).  Solving these
  problems involves developping new protocols for Route Optimization
  for mobile networks.

  Field experiments involved accessing two publicly-deployed wireless
  access systems (GPRS and WLAN) and showed the need for NAT traversal
  and IPv6 transition mechanisms.  These mechanisms were separated
  from Mobile IPv6 mobility management by means of FrontBoxes.

  Delivering multicast traffic to hosts inside the mobile network is
  an important work item identified within the project.  Several
  schemes are currently being considered (home and remote
  subscriptions).

  A DVB-T FrontBox would allow the Mobile Router to receive high-speed
  (broadband) Internet flows (larger bandwidths than with GPRS or
  WLAN).  Developing a DVB-T FrontBox is one of the potential future
  work items.

Acknowledgements

  This work has been performed in the framework of the IST project
  IST-2001-35125 OverDRiVE (Spectrum Efficient Uni- and Multicast Over
  Dynamic Radio Networks in Vehicular Environments), which is partly
  funded by the European Union. The OverDRiVE consortium consists of
  Motorola, DaimlerChrysler, France Telecom, Ericsson and
  Radiotelevisione Italiana as well as Rheinisch-Westfälische
  Technische Hochschule RWTH Aachen, Universität Bonn and the
  University of Surrey. The authors acknowledge the contributions of
  their colleagues in the OverDRiVE consortium.
















o

Lach, et al.             Expires April 2003                   [Page 10]


Internet Draft           OverDRiVE Experiments             23 June 2003

References

  [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
      Levels. RFC 2119, BCP 0014, IETF.  March 1997.

  [2] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert. Nemo
      Basic Support Protocol (work in progress). Internet Draft,
      IETF. draft-ietf-nemo-basic-support-00.txt.  June 2003.

  [3] IST OverDRiVE project on the World Wide Web:
      http://www.ist-overdrive.org, accessed June 23rd 2003.

  [4] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology
      (work in progress). Internet Draft, IETF.
      draft-ietf-nemo-terminology-00.txt. May 2003.

  [5] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6
      (work in progress). Internet Draft, IETF.
      draft-ietf-mobileip-ipv6-22.txt. May 2003.

  [6] Wixos Wireless LAN Network on the World Wide Web:
      http://www.wixos.net, Accessed June 22nd 2003.

  [7] C. Janneteau, ed., "Scenarios, Services and Requirements",
      OverDRiVE Deliverable D03, September 2002.

  [8] M. Ronai, ed., "Concept of Mobile Router and Dynamic IVAN
      Management", OverDRiVE Deliverable D07, March 2003.

  [9] A. Petrescu, ed., "Issues in Designing Mobile IPv6 Network
      Mobility with the MR-HA Bi-directional Tunnel (MRHA),
      draft-petrescu-nemo-mrha-03.txt, (Work in Progress), October
      2003.

  [10] A. Petrescu and H.-Y. Lach, "MR-HA Bidirectional Tunnelling for
       Network Mobility", Motorola Labs internal tech report, October
       2003.

  [11] H.-Y. Lach, C. Janneteau and A. Petrescu, "Network Mobility in
       Beyond-3G Systems", IEEE Communications Magazine, July 2003.

  [12] H. Levkowetz, S. Vaarala, "Mobile IP Traversal of Network Address
       Translation (NAT) Devices", RFC 3519, Proposed Standard,
       IETF.  May 2003.












Lach, et al.             Expires April 2003                   [Page 11]


Internet Draft           OverDRiVE Experiments             23 June 2003

Authors' Addresses

  Hong-Yon Lach                      Christophe Janneteau
  Motorola Labs                      Motorola Labs
  Parc les Algorithmes St Aubin      Parc les Algorithmes St Aubin
  Gif-sur-Yvette 91193               Gif-sur-Yvette 91193
  France                             France
  Phone:  +33 1 69352536             Phone:  +33 1 69352548
  Hong-Yon.Lach@motorola.com         Christophe.Janneteau@motorola.com

  Alexis Olivereau                   Alexandru Petrescu
  Motorola Labs                      Motorola Labs
  Parc les Algorithmes St Aubin      Parc les Algorithmes St Aubin
  Gif-sur-Yvette 91193               Gif-sur-Yvette 91193
  France                             France
  Phone:  +33 1 69352516             Phone:  +33 1 69354827
  Alexis@motorola.com                Alexandru.Petrescu@motorola.com

  Tim Leinmueller                    Michael M. Wolf
  DaimlerChrysler AG                 DaimlerChrysler AG
  Research Telematics and E-Business Research Telematics and E-Business
  Communication Systems (RIC/TC)     Communication Systems (RIC/TC)
  HPC: U800                          HPC: U800
  P.O. Box 2360                      P.O. Box 2360
  89013 Ulm / Germany                89013 Ulm / Germany
  Phone: +49 731 505 2379            Phone: +49 731 505 2379
  Tim.Leinmueller@daimlerchrysler.comMichael.M.Wolf@daimlerchrysler.com

  Markus Pilz
  University of Bonn
  pilz@cs.uni-bonn.de

Changes

  From version 00 to 01:
  -improved presentation.
  -added conclusive remarks of laboratory experiments.
  -enhanced the section of field experiments.
  -improved the conclusions section.
  -changed addresses and affiliations of some authors.
















Lach, et al.             Expires April 2003                   [Page 12]


Internet Draft           OverDRiVE Experiments             23 June 2003

Copyright (C) The Internet Society (2003).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Funding for the RFC editor function is currently provided by the
Internet Society.






























Lach, et al.             Expires April 2003                   [Page 13]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/