 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev18 [issued: 06-26-07]
-
180 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
same local area (in particular during heavy traffic conditions) is likely to create potentially excessive
channel loading. For this reason, it has been the focus of the technical committee to use a concise selection
of required information to include in these common messages and to provide effective coding to minimize
the size of the message payload for these repetitive messages. The common message set that was developed
by the committee to meet the requirements of the initial vehicle safety application scenarios was therefore
split into three parts:
MSG_BasicSafetyMessageFrame, Part I, which contains a fixed data structure comprising the information
that must be updated most frequently or which must be known to determine the meaning of the frequently-
changing data. Part I is broadcast most frequently, providing an update rate that is consistent with the scan
rates for on-board vehicle safety system sensors.
MSG_BasicSafetyMessageFrame, Part II, which is added to Part I on a less-frequent basis in order to
complement abbreviated fields in Part I, such as time and position, in order to communicate the complete
time or position. As well, additional data that is important to vehicle safety applications, but is required
less-frequently, is included in Part II.
MSG_BasicSafetyMessageFrame, Part III, which contains additional data frames or data elements with
open-ended tags. Part III is added on an ‘as required’ basis to allow the communication of data that is not
included in Part I or Part II.
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 increase the range 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 (WSMP)
stack in a periodic broadcast mode on the Control Channel (CCH) to other devices (typically other mobile
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