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

Versions: 00 01 02

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) &#8213; 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) &#8213; 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]


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