 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev28 [issued: 11-10-08]
-
257 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
changing data. Part I is broadcast most frequently, potentially providing a proper update rate that is
consistent with the scan rates for on-board vehicle safety system sensors.
MSG_BasicSafetyMessage Frame, Part II, which is added to Part I on a less-frequent basis in order to
provide additional data that is important to the vehicle safety applications, but is required less-frequently.
Part II can be transmitted periodically or based on event or request triggering. Locally defined content can
be sent to Part II as well, although this requires additional definition in the ASN and XML used.
2.
Applicable documents
A detailed description of the identification and selection of the high-priority vehicle safety applications, as
well as the background descriptions of the application scenarios, are included in the “Vehicle Safety
Communications Project Task 3 Final Report: Identify Intelligent Vehicle Safety Applications Enabled by
DSRC”, published by the National Highway Traffic Safety Administration in March 2005 and publicly
available from National Technical Information Service, Springfield, Virginia 22161 (or online at
3.
Application message sequences
The repetitive broadcast of vehicle safety messages is expected to to increase the range [RS6]of vehicle
environmental awareness beyond the range of any on-board sensors. Each vehicle will broadcast its
relevant information frequently via the MSG_BasicSafetyMessageFrame, Part I and
MSG_BasicSafetyMessageFrame, Part II messages and receive the equivalent messages from all DSRC-
equipped vehicles in the immediate vicinity. Messages from other vehicles can then be analyzed by on-
board processors to identify impending situations that would warrant warning the driver or initiating other
actions, for example, pre-tensioning of seat belts.
4.
Application use with DSRC
The messages in the vehicle safety application area denoted by ACID 20 [the “vehicle-safety” service as
defined by IEEE 1609.4 or its successors] are transmitted using the Wave Short Message Protocol (WSM)
stack in a periodic broadcast mode on a pre-agreed channel to other devices (typically other mobile on-
board units (OBUs)) which have determined to receive this type of message (based on ACID value and
running a suitable application). Therefore, this is a provider application that does not employ a Wave Basic
Service Set (WBSS) as per IEEE 1609.4 Clause 5.3, and there is no confirm and join operation. It is
recommended for channel bandwidth preservation, that these common messages are sent with {ACM=0} as
to permit any vehicle safety or public safety application to determine its relevance, and avoid rebroadcast of
the same information under multiple ACMs within a ACID.
Receivers of these messages are expected to process all such messages. Upon reception of such messages,
they are examined for message content and relevance at the application layer of the protocol stack. Based
on the data exchanged in this application area, devices may determine the need to initiate other services or
applications using other ACID values.
The expected repetition rate for the MSG_BasicSafetyMessageFrame, Part I messages broadcast in this
application is expected to be able to provide similar level of data quality including data freshness, to on-
board sensors used for vehicle safety systems. However, to help prevent the possibility of vehicle
broadcast messages overloading the control channel bandwidth, the frequency of transmissions may need to
be adjusted in dense traffic environments and may be adjusted based on speed, number of vehicles in close
proximity or other parameters in dense traffic environments where many vehicles are stopped or close to
being stopped (e.g., a toll plaza).