Individual Submission G. Karagiannis
Internet-Draft University of Twente
Intended status: Informational R. Wakikawa
Expires: January 7, 2010 J. Kenney
Toyota ITC
July 6, 2009
Traffic safety applications requirements
draft-karagiannis-traffic-safety-requirements-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Karagiannis, et al. Expires January 7, 2010 [Page 1]
Internet-Draft Traffic safety applications requirements July 2009
Abstract
This document describes a number of communication performance
requirements that are imposed by traffic safety applications on a
network layer. These traffic safety applications and requirements
have been derived during the VSC (Vehicular Safety Communications)
and VSC-A (VSC-Applications) projects. The goal of this document is
to stimulate the discussion on judging whether these performance
requirements could or could not be supported (currently and in the
future) by IP based network solutions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of VSC and VSC-A traffic safety applications . . . . 6
4. Overview of traffic safety communication performance
requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Discussion and conclusions . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 17
A.1. Normative References . . . . . . . . . . . . . . . . . . . 17
A.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Karagiannis, et al. Expires January 7, 2010 [Page 2]
Internet-Draft Traffic safety applications requirements July 2009
1. Introduction
Vehicular networking can be considered as one of the most important
enabling technologies needed to support various types of traffic
applications, such as infotainment type of applications, traffic
efficiency & management and traffic safety applications.
Traffic safety applications are those that are primarily applied to
decrease the probability of traffic accidents and the loss of life of
the occupants of vehicles. Note that VSC and VSC-A projects focus on
vehicle-to-vehicle safety. Another project called CICAS-V
(Cooperative Intersection Collision Avoidance Systems - Violation)
discuss the traffic safety application over vehicle-to-infrastracture
communication.
Traffic efficiency & management applications are focusing on
improving the vehicle traffic flow, traffic coordination and traffic
assistance. Moreover, traffic efficiency & management applications
are focusing on providing updated local information, maps and in
general messages of relevance limited in space and/or time.
Infotainment types of applications are the applications that are
neither traffic safety applications nor traffic efficiency &
management applications. Such applications are supported by e.g.,
media downloading use cases. This document describes a number of
communication performance requirements that are imposed by traffic
safety applications on a network layer. These traffic safety
applications and requirements have been derived during the VSC
(Vehicular Safety Communications) and VSC-A (VSC-Applications)
projects. The Vehicle Safety Communications (VSC) consortium, see
[VSC], is supported among others by CAMP (Crash Avoidance Metrics
Partnership). CAMP is a partnership that has been formed in 1995 by
Ford Motor Company and General Motors Corporation. The objective of
CAMP is to accelerate the implementation of crash avoidance
countermeasures to improve traffic safety by investigating and
developing new technologies. VSC has been realized in two phases.
The first phase, denoted as VSC started in 2002 and ended in 2004.
The second phase started in 2006 and ends in 2009. VSC focused and
is focusing on traffic safety related applications. In 2006, The VSC
2 consortium in cooperation with USDOT initiated a three-year
collaborative effort in the area of wireless-based safety
applications under the Vehicle Safety Communications - Applications
(VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the
following members; Mercedes-Benz, Ford, General Motors, Honda &
Toyota. The main goal of this project is to develop and test
communications-based vehicle safety systems to determine whether
vehicle positioning in combination with the DSRC at 5.9 GHz can
improve the autonomous vehicle-based safety systems and/or enable new
Karagiannis, et al. Expires January 7, 2010 [Page 3]
Internet-Draft Traffic safety applications requirements July 2009
communication-based safety applications.
The WAVE Short Message Protocol [IEEE 1609.3] was designed
specifically to offer a more efficient (smaller size) alternative to
TCP or UDP over IP, for 1-hop messages that require no routing. The
goal of this document is to stimulate the discussion on judging
whether these communication performance requirements could or could
not be (currently and in the future) supported by IP based network
solutions.
Karagiannis, et al. Expires January 7, 2010 [Page 4]
Internet-Draft Traffic safety applications requirements July 2009
2. Terminology
The following terms are used in this document :
On Board Unit (OBU)
a processing and communication feature that is located in a
vehicle, which provides an application runtime environment,
positioning, security and communications functions and interfaces
to other vehicles including human machine interfaces. OBU is also
known as OBE (On-Board Equipment).
Road Side Unit (RSU)
equipment located along highways, at traffic intersections and
other type of locations where timely communications with vehicles
are needed. Each RSE includes DSRC radio, a positioning system
and a router to route packets back through the infrastructure
network. RSU is also know as RSE (Road Side Equipment)
vehicle-to-vehicle (v2v)
(same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic
communication mode in which data packets are exchanged between two
vehicles, either directly or traversing multiple vehicles, without
involving any node in the infrastructure.
vehicle-to-infrastructure
generic communication mode in which data packets sent by a vehicle
traverse a network infrastructure.
infrastructure-to-vehicle
generic communication mode in which data packets received by a
vehicle traverse a network infrastructure.
Host vehicle
a vehicle that at a certain moment in time uses the traffic safety
application.
Traffic safety application
application that is primarily applied to decrease the probability
of traffic accidents and the loss of life of the occupants of
vehicles.
Karagiannis, et al. Expires January 7, 2010 [Page 5]
Internet-Draft Traffic safety applications requirements July 2009
3. Overview of VSC and VSC-A traffic safety applications
In VSC, see [VSC] 34 vehicle application scenarios have been
identified, evaluated and ranked. From this evaluation, a subset of
eight significant near- and mid-term traffic safety applications have
been selected: (1) cooperative forward collision warning, (2) curve
speed warning, (3) pre-crash sensing, (4) traffic signal violation
warning, (5) lane-change warning, (6) emergency electronic brake
light, (7) left turn assistant, (8) stop sign movement assistant. A
brief description of these applications is given below (for more
details, see [VSC]):
o Traffic signal violation warning: it informs and warns the driver
to stop at a legally prescribed location in the situation that the
traffic signal indicates a stop and it is estimated that the
driver will be in violation.
o Curve speed warning - Rollover Warning: aids the driver in
negotiating speeds at appropriate speeds.
o Emergency Electronic Brake Lights: it is used to inform vehicles
that a vehicle brakes hard. In particular in this situation a
warning message is sent to the vehicles moving behind the vehicle
that brakes hard.
o Pre-crash sensing: it prepares the driver for an unavoidable and
imminent collision.
o Cooperative Forward Collision Warning: aids the driver in
mitigating or avoiding collisions with the rear-end vehicles in
the forward path of travel through driver notification or warnings
of an unavoidable collision. This application does not attempt to
control the vehicle to avoid an unavoidable collision.
o Left Turn Assistant: it informs the driver about oncoming traffic
in order to assist him in making a left turn at a signalized
intersection without a phasing left turn arrow.
o Lane Change Warning: it warns the driver if an intended lane
change may cause a crash with a nearby moving vehicle.
o Stop Sign Movement Assistance: it warns the driver that the
vehicle is nearby an intersection, which will be passed after
having stopped at a stop sign.
In the VSC-A project an additional investigation has been performed,
on traffic safety applications that can be used in crash immitment
scenarios, see [VSC-A]. The following 7 traffic safety applications
Karagiannis, et al. Expires January 7, 2010 [Page 6]
Internet-Draft Traffic safety applications requirements July 2009
have been selected for implementation in the VSC-A test bed.
o Emergency Electornic Brake Light: is a traffic safety application
that is the same as the Emergency Electornic Brake Light
application defined in the VSC project, see above.
o Forward Collision warning: is a traffic safety application that is
the same as the Cooperative Forward Collision Warning application
defined in the VSC project, see above.
o Intersection Movement Assist: is a traffic is intended to warn the
driver of a vehicle when it is not safe to enter an intersection
due to high collision probability with other vehicles. It is
similar to the Stop Sign Movement Assistance application defined
in the VSC project, see above.
o Blind Spot Warning & Lane Change Warning: it is similar to the
Lane Change Warning application defined in the VSC project, see
above. In the Blind Spot Warning application the driver of a host
vehicle is informed that another vehicle is moving in an adjacent
lane and that this vehicle is positioned in a blind spot zone of
the host vehicle.
o Do Not Pass Warning: this is an application that was not
investigated in the VSC project. It is intended to warn the
driver of a host vehicle during a passing maneuver attempt when a
slower vehicle, ahead and in the same lane, cannot be safely
passed using a passing zone which is occupied by vehicles with the
opposite direction of travel. In addition, the application
provides advisory information that is intended to inform the
driver of the host vehicle that the passing zone is occupied when
a passing maneuver is not being attempted.
o Control Loss Warning: this is an application that was not
investigated in the VSC project. It is intended to enable the
driver of a host vehicle to generate and broadcast a control- loss
event to surrounding vehicles. Upon receiveing this information
the surrounding vehicle determines the relevance of the event and
provides a warning to the driver, if appropriate.
Karagiannis, et al. Expires January 7, 2010 [Page 7]
Internet-Draft Traffic safety applications requirements July 2009
4. Overview of traffic safety communication performance requirements
The VSC consortium specified several performance communication
requirements derived from the traffic safety applications, see
Figure 1 and Figure 2 and [VSC]. The communication parameters used
in Figure 1 and Figure 2 where specified in [VSC]. These are:
o Type of Communication: considers, the (1) source-destination of
the transmission (infrastructure-to-vehicle, vehicle-to-
infrastructure, vehicle-to-vehicle), (2) direction of the
transmission (one-way, two-way), and DSRC (IEEE 802.11p), see
[DSRC], [IEEE 802.11p], communication, (3) source-reception of
communication (point-to-point, point-to-multipooint). Note that
the protocol suite that is used in the VSC and VSC-A projects is
the WAVE protocol suite, which is composed by the combination of
IEEE 1609 protocol suite, see [IEEE 1609.1], [IEEE 1609.2], [IEEE
1609.3], [IEEE 1609.4] and the IEEE 802.11p.
o Transmission Mode: Describes whether the transmission is triggered
by an event (event-driven) or sent automatically at regular
intervals (periodic)
o Minimum Frequency: defines the minimum rate at which a
transmission should be repeated (e.g., 1 Hz).
o Allowable latency: defines the maximum duration of time allowable
between when information is available for transmission (by the
sender) and when it is received by the receiver (e.g., 100 msec).
o Data to be transmitted and/or received: describes the contents of
the communication (e.g., vehicle location, speed and heading).
Design considerations include whether or not vehicles make
periodic broadcasts to identify their position on the roadway and
how privacy is best maintained.
o Maximum required range of communications: defines the
communication distance between two units (e.g., two vehicles) that
is required to effectively support an application.
+---------------- +----------------+----------------------+--- ---+
| | Commun. |.Trans. | Min. |
| | Type | Mode | Freq. |
| | | | (Hz) |
+-----------------+----------------+----------------------+-------+
| Traffic Signal |* infrastructure| Periodic | ~10 |
| violation | -to-vehicle | | |
Karagiannis, et al. Expires January 7, 2010 [Page 8]
Internet-Draft Traffic safety applications requirements July 2009
| warning |* one-way | | |
| |* point-to- | | |
| | -multipoint | | |
| | | | |
| Curve |* infrastructure| Periodic | ~1 |
| Speed warning | -to-vehicle | | |
| |* one-way | | |
| |* point-to- | | |
| | -multipoint | | |
| | | | |
| | | | |
| Emergency |* vehicle-to- | Event driven | ~10 |
| Electronic | -vehicle | | |
| Brake lights |* one-way | | |
| |* point-to- | | |
| | -multipoint | | |
| | | | |
| Pre-Crash |* vehicle-to- | Event driven | ~50 |
| Sensing | -vehicle | | |
| |* Two-way | | |
| |* Point-to-point| | |
| | | | |
| Cooperative |* vehicle-to- | Periodic | ~10 |
| Forward | -vehicle | | |
| Collision |* One-way | | |
| warning |* point-to- | | |
| | -multipoint | | |
| | | | |
| Left Turn |* vehicle-to- | Periodic | ~10 |
| Assistant | -infrastructure| | |
| | and | | |
| | infrastructure| | |
| | -to-vehicle | | |
| |* One-way | | |
| |* point-to- | | |
| | -multipoint | | |
| | | | |
| Lane change |* vehicle-to- | Periodic | ~10 |
| warning | -vehicle | | |
| |* One-way | | |
| |* point-to- | | |
| | -multipoint | | |
| | | | |
| Stop Sign |* vehicle-to- | Periodic | ~10 |
| Movement | -infrastructure| | |
| Assistance | and | | |
| | infrastructure| | |
| | -to-vehicle | | |
Karagiannis, et al. Expires January 7, 2010 [Page 9]
Internet-Draft Traffic safety applications requirements July 2009
| |* One-way | | |
| |* point-to- | | |
| | -multipoint | | |
| | | | |
+-----------------+----------------+----------------------+-------+
Figure 1: Preliminary application scenario communication requirements
(part A), from [VSC]
+---------------- +----------------+----------------------+--- ---+
| | Latency |Data to be transmitted|Max. |
| | (msec) |and/or received |Req'd |
| | | |comm.. |
| | | |range |
| | | |(m) |
+-----------------+----------------+----------------------+-------+
| Traffic Signal | ~100 |* traffic signal | ~250 |
| violation | | status | |
| warning | |* Timing | |
| | |* Directionality | |
| | |* position of the | |
| | | traffic signal | |
| | | stopping location | |
| | |* Whether condition | |
| | | (if available) | |
| | |* Road surface type | |
| | | | |
| Curve | ~1000 |* Curve location | ~200 |
| Speed warning | |* Curve speed limits | |
| | |* Curvature | |
| | |* Bank | |
| | |* Road surface type | |
| | | | |
| Emergency | ~100 |* Position | ~300 |
| Electronic | |* Heading | |
| Brake lights | |* Velocity | |
| | |* Decelaration | |
| | | | |
| Pre-Crash | ~20 |* Vehicle type | ~50 |
| Sensing | |* Position | |
| | |* Velocity | |
| | |* Acceleration | |
| | |* Heading | |
| | |* Yaw rate | |
| | | | |
Karagiannis, et al. Expires January 7, 2010 [Page 10]
Internet-Draft Traffic safety applications requirements July 2009
| Cooperative | ~100 |* Position | ~150 |
| Forward | |* Velocity | |
| Collision | |* Acceleration | |
| warning | |* Heading | |
| | |* Yaw rate | |
| | | | |
| Left Turn | ~100 |* Traffic signal | ~300 |
| Assistant | | status | |
| | |* Timing | |
| | |* Directionality | |
| | |* Road shape and | |
| | | intersection | |
| | | information | |
| | |* Vehicle position | |
| | |* Velocity | |
| | |* Heading | |
| | | | |
| Lane change | ~100 |* Position | ~150 |
| warning | |* Heading | |
| | |* Velocity | |
| | |* Acceleration | |
| | |* Turn Signal status | |
| | | | |
| Stop Sign | ~100 |* Vehicle position | ~300 |
| Movement | |* Velocity | |
| Assistance | |* Heading | |
| | |* Warning | |
| | | | |
+---------------- +----------------+----------------------+--- ---+
Figure 2: Preliminary application scenario communication requirements
(part B), from [VSC]
From these requirements, the most significant ones are:
o Message packet size: for all 8 scenarios, a message size of 200 to
500 bytes is needed.
o Maximum required range of communication: for all 8 scenarios, a
maximum required range of communication of 50 to 300 meters is
needed.
o During the 7 of the 8 scenarios, one-way, point to multipoint
broadcast messages were used.
o During the 1 of the 8 scenarios, Two-way, point to point messages
Karagiannis, et al. Expires January 7, 2010 [Page 11]
Internet-Draft Traffic safety applications requirements July 2009
o During the 6 or 7 of the 8 scenarios, the periodic transmission
mode is used.
o During the 1 or 2 scenarios, Event-driven transmission mode is
used.
o During 6 of the 8 scenarios an allowable latency of 100
miliseconds is needed.
o During 1 of the 8 scenarios an allowable latency of 20 miliseconds
is needed.
o During 1 of the 8 scenarios an allowable latency of 1 second is
needed.
In addition to these communication performance requiremenst the VSC
project derived the network constraints, depicted in Figure 3, see
Appendix H of [VSC].
+----------------------------------+----------------------+
| Constraint type |.Constraint value. |
+----------------------------------+----------------------+
| Aggregate bandwidth | 6 Mb/s |
| | |
| Maximum received packets/sec | 4000 |
| | |
| Maximum allowable latency | 100 ms |
| | |
| Maximum network latency | 10 ms |
| | |
| Maximum packet size | 200 bytes |
+----------------------------------+----------------------+
Figure 3: Network constraints, from appendix H of [VSC]
The VSC-A project, relaxed some of these network constraints. In
particular, the security related network constraints were derived,
see Figure 4 and [VSC-A_1609.2]. In addition to these network
security constraints, the VSC-A uses for the traffic safety
application Do Not Pass Warning, a Maximum required range of
communication, of 700 meters as a target.
Karagiannis, et al. Expires January 7, 2010 [Page 12]
Internet-Draft Traffic safety applications requirements July 2009
+----------------------------------+----------------------+
| Constraint type |.Constraint value. |
+----------------------------------+----------------------+
| Certificate size | < 300bytes |
| | |
| Authentication generations | 10 |
| per second | |
| | |
| Authentication verifications | 1000 |
| per second | |
| | |
| Time delay (authentication + | < 20ms |
| + verification) | |
| | |
| Over-air-bandwidth overhead | 1,810 bytes/s |
| introduced by security | |
| mechanisms (including | |
| certificates); certificates | |
| with each message | |
+----------------------------------+----------------------+
Figure 4: Network security constraints, from [VSC-A_1609.2]
Karagiannis, et al. Expires January 7, 2010 [Page 13]
Internet-Draft Traffic safety applications requirements July 2009
5. Discussion and conclusions
This document described a number of communication performance
requirements that are imposed by traffic safety applications on a
network layer. These traffic safety applications and requirements
have been derived during the VSC (Vehicular Safety Communications)
and VSC-A (VSC-Applications) projects. The goal of this document is
to stimulate the discussion on judging whether these performance
requirements could or could not be supported (currently and in the
future) by IP based network solutions.
It is however important to note that according to the VSC-A project
the following points are important to be mentioned:
1. A general point is that the requirements of the target
applications are intended to be somewhat representative of the
expected requirements discussed in the VSC and VSC-A projects,
but over time it is expected that new application ideas to come
forward and the communication requirements may broaden as a
result. For example, most applications today are designed to
treat safety messages as self-contained such that the decision to
warn a driver can be made purely based on the contents of the
most recent message. In the future, we may see applications that
require correlation of data over multiple messages from a given
sender, or between multiple senders.
2. We now expect typical safety messages to be on the order of 300
to 400 bytes (including all layers of overhead), rather than the
200 bytes given as the upper limit cited in Appendix H of
[VSC].It is expected that the security overhead will be between
about 200 bytes and about 90 bytes, depending on whether a full
certificate or a hashed certificate digest is included (the full
certificate will be included at some reduced rate, probably 1 Hz
to 3 Hz). There is also some additional, sub-rate safety
information to communicate the sending vehicle's path history,
its predicted path, and some of its raw GPS data. The latter is
for purposes of computing precise relative positioning.
Furthermore, it is expected that in some congested-channel
scenarios we might expect to see more than 10 msec of network
latency. This is exacerbated under the current multi-channel
operation standard (IEEE 1609.4) [IEEE 1609.4], which calls for
time to be divided into 50 msec intervals, with switching between
a "control channel interval" and a "service channel interval",
and then back again. Safety messages are only sent during the
control channel interval. It is possible for a given message
that is enqueued in one control channel interval to have to wait
for the next one if it is still in backoff when the first
interval ends, thus incurring at least 50 more msec of latency.
Karagiannis, et al. Expires January 7, 2010 [Page 14]
Internet-Draft Traffic safety applications requirements July 2009
That is highly undesirable however, and in any case we're hoping
to change the standards to avoid this channel-switching paradigm
for safety messages.
3. Furthermore, the requirement on "maximum allowable latency" is
difficult to be interpreted when the communication takes place
over an inherently unreliable medium. The fact is that the
applications built on DSRC (Dedicated Short Range Communications)
will have to be somewhat robust to lost broadcast messages. We
often talk about the delay between successfully delivered
messages, and it is expected that safety applications can
generally tolerate at least 300 msec of such delay (i.e. two
successive lost packets).
Karagiannis, et al. Expires January 7, 2010 [Page 15]
Internet-Draft Traffic safety applications requirements July 2009
6. Security Considerations
No security considerations apply to this document.
Karagiannis, et al. Expires January 7, 2010 [Page 16]
Internet-Draft Traffic safety applications requirements July 2009
7. IANA considerations
No IANA considerations apply to this document.
Appendix A. References
A.1. Normative References
A.2. Informative References
[draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T,
Festag, A., Lenardi, M., "Automotive industry requirements for NEMO
Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02,
(Work in progress), 2009.
[IEEE 802.11p] IEEE P802.11p/D3.0, "Draft Amendment to Standard for
Information Technology-Telecommunications and Information Exchange
Between Systems-Local and Metropolitan Area Networks- Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications- Amendment 7: Wireless Access in
Vehicular Environment", 2007.
[IEEE 1609.1] IEEE P1609.1, "Trial-Use Standard for Wireless Access
in Vehicular Environments (WAVE) - Resource Manager", 2006.
[IEEE 1609.2] IEEE P1609.2, "Trial-Use Standard for Wireless Access
in Vehicular Environments (WAVE) ― Security Services for
Applications and Management Messages", 2006.
[IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless
Access in Vehicular Environments (WAVE)-Networking Services", 2007.
[IEEE 1609.4] IEEE P1609.4, "Trial-Use Standard for Wireless Access
in Vehicular Environments (WAVE) ― Multi-Channel Operation",
2006
[DSRC] Dedicated Short Range Communications (DSRC), USA ITS Standards
advisory, http://www.standards.its.dot.gov/Documents/advisories/
dsrc_advisory.htm
[VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810
591, April 2006.
[VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project,
Final Annual Report, DOT HS 811 073, January 2009.
Karagiannis, et al. Expires January 7, 2010 [Page 17]
Internet-Draft Traffic safety applications requirements July 2009
[VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides
presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found
via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/
VSCA-1609_080827.pdf
Authors' Addresses
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
Email: g.karagiannis@ewi.utwente.nl
Ryuji Wakikawa
TOYOTA InfoTechnology Center, U.S.A., Inc.
465 Bernardo Avenue
Mountain View, CA 94043
USA
Email: ryuji@jp.toyota-itc.com
John Kenney
TOYOTA InfoTechnology Center, U.S.A., Inc.
465 Bernardo Avenue
Mountain View, CA 94043
USA
Email: johnkenney@alumni.nd.edu
Karagiannis, et al. Expires January 7, 2010 [Page 18]