SAE J2735 DSRC Message List

A complete list of all adopted SAE DSRC J2735 Messages with brief commentary.

The official release of the standard at this time is called:
SAE J2735 Dedicated Short Range Communications (DSRC) Message Set Dictionary™ (Revised: 2016-03-30)

Buy a complete copy, including the ASN.1 source specification  here.

Comments

The DSRC message set is used in Intelligence Transportation Systems (or ITS, as in ITSware.net) as the primary means by which vehicles communicate with each other (vehicle-to-vehicle, or V2V) and the with the roadway infrastructure (vehicle-to-infrastructure, or V2I or V2x).  Conceptually all DSRC equipped vehicles in the US and much of the rest of the world will be sending their position, velocity and acceleration data to nearby vehicles at a 10Hz rate.  In order to do this with more accuracy, differential corrections are of great value, although they are not required to be present all of the time.  The DSRC message set reuses stock RTCM messages wrapped in an outer ASN message which is defined in the SAE standard J2735.  SNIP provides these messages (using the DSRC Plug-In) and that is why this list appears on a web site which is otherwise devoted the NTRIP Caster issues.

Your rover (or OBU, or vehicle reference receiver) can obtain these messages from the SNIP Caster by way of any TCP/IP connection (typically a cell phone in the test vehicle) or by way of the the Roadside Unit (RSU).  The precise details will vary depending on needs.

If you are interested in the RTCM type messages you are likely to encounter in the real world, here is an article with our popular RTCM 3 cheat sheet summary.

The SNIP Caster (when using the DSRC Plug-In) has several unique abilities with regards to DSRC.  The key item of interest to most readers is that a SNIP Caster is unique in its ability to create properly formatted DSRC message from RTCM corrections streams.  This ability is required in order to send RTCM content over the DSRC message set and the DSRC Wave Short Message (WSM) channel defined by IEEE 1609.   The local SNIP Caster provides well formed messages to a local DOT operation center which in turn distributes them to the roadside units (DSRC transmitters) located along the roadside.  In this configuration, the rover device is typically a passing automobile which recovers the DSRC messages, decodes the ASN and strips out the RTCM connections, and feeds that to the GNSS device in the vehicle to be used in the normal way.

The text below summarizes the tool tips that SNIP will display when decoding various J2735 messages from an NTRIP stream.  Unlike other NTRIP Casters, SNIP has the ability to decode and process both the DSRC and the RTCM messages to provide additional functionality.

The Message List

Current Messages

All must be encoded in ASN.1 UPER format (unaligned packed encoding rules).   Like RTCM messages, the SAE DSRC messages have a unique assigned number and a formal name.   The formal name (e.g. “mapData”) comes from an ASN type definition value but each message is more often referred to by a short acronym  (e.g. “MAP”).

Msg# Message Name & Usage Commentary
#18 mapData
The MAP message is used to provide intersection and roadway lane geometry data for one or more locations (e.g. intersections and fragments of maps).  Almost all roadway geometry information as well as roadway attributes (such as where a do not block region exists, or what maneuvers are legally allowed at a given point) is contained in the “generic lane” details of this message.  MAP messages are used in intersections to number and describe lane level details of each lane, while the SPAT message provides the current state of each signal head controlling the ability to stop/pass a given lane.
#19 signalPhaseAndTimingMessage
The SPAT message is used to provide the current signal / phase timing data (times at which signals will change) for one or more signalized intersections, as well as other time of day status details.   All SPAT messages link to MAP messages to convey the roadway details and to link the signal controller phases to the correct set of lanes.
#20 basicSafetyMessage
The all-purpose BSM message used by both light duty vehicles and other types with various Part II content present depending on the applications being supported.  See the different J2945/x documents for further details.  In simple terms, all equipped vehicles broadcast a stream of BSM messages at a 10Hz rate. Nearly all application exchanges (V2V, V2I, V2X) make use of the presence of BSMs as a prerequisite for operation.
#21 commonSafetyRequest
The CSR message is not deployed in any known use at this time.  Its original design intent was to allow a per vehicle request for supporting data elements in V2V safety exchanges. It has not been developed further since the 2009 edition of the standard.
#22 emergencyVehicleAlert
The EVA message is not deployed in any known use at this time.  Its original design intent (to announce the presence of emergency vehicles in the area).  It has largely been replaced with the additional content now sent in the Part II section of the BSM message (See J2945/2 for further details). It is not recommended for use in new development.
#23 intersectionCollision
The ICA message (intersection collision announcement in this context) and is intended to  inform other nearby users that a dangerous condition exists, or is likely to exist, in the immediate future (e.g., it can be used to detect a red light / stop line violation and inform others).  It can be sourced by both vehicles and by the infrastructure.  The ICA message wraps a BSM message (real or virtual) with additional details to reflect the estimated path of the offending vehicle.
#24 nmeaCorrections
The NMEA message is not deployed in any known use at this time.  Its original design intent was to provide a way to “wrap” NMEA-183 formatted messages for sending over the DSRC channel used in early testing.  As these message lack the level of accuracy expected for DSRC in the BSM message (as well as other key data), there is little practical use for this message at this point.  It is not recommended for use in new development. As with all “wrapped” messages, the internal content of the message is defined by another SDO (in this case NMEA, not to be confused with NEMA).
#25 probeDataManagement
The PDM message is used to control the details of the probe data that the vehicle will collect and then report back to RSU devices using the PVD message. In the DSRC environment vehicles can act as anonymous probes to collect traffic flow data, local weather data, and other conditions.
#26 probeVehicleData
The PVD message is used to report details of collected probe data (meeting the data needs established by other PDM messages) to Road Side Units (RSU) devices in V2I exchanges.
#27 roadSideAlert
The RSA message is a more primitive version of the TIM message. Its original design intent was to support the creation of simple, quick, ad hoc messages for ATIS-like informational use from public safety vehicles by a responder in the field (such as a DOT vehicle which has parked to remove a roadway obstruction) without the need for coordination with others.  By contrast, the TIM message was intended to support more complex pre-planned incident and work zone uses.  This distinction has blurred in more recent times, but the simplicity of deploying the RSA message is still considered of value.
#28 rtcmCorrections
The RTCM messages are used to “wrap” RTCM corrections messages for sending over the DSRC channel. Corrections data allows the GNSS of each DSRC device to maintain lane level accuracy under various conditions.  The type/content of these messages varies with the precise kind of corrections data needed by local deployments.  As with all “wrapped” messages, the internal content of the message is defined by another SDO (in this case RTCM).
#29 signalRequestMessage
The SRM messages are used by authorized parties to request services from an intersection signal controller.  Vehicles approaching an intersection use this message to affect the signal operation.  This is how traditional preemption and priority requests are handled for intersection safety in DSRC.
#30 signalStatusMessage
The SSM messages, which are sent by the local DSRC / Signal Controller, are used to reflect the current operational state of the intersection signal control.  Any prior request services (SRM messages) and their outcomes are reflected here as well.  This message therefore serves as a means to acknowledge signal requests.
#31 travelerInformation
The TIM message is used to contain a variety of traffic condition and “advanced traveler” messages.  It provides the means to inform the public about both incidents (traffic accidents) and pre-planned roadwork events. The TIM message can be used to alert the public to severe weather conditions and other local or regional emergencies.   It can also be used for a variety of speed warnings, traffic signage, road conditions and other general information.  The ITIS codes (J2540) are prominently used in this message.
#32 personalSafetyMessage
The PSM message is used to convey similar BSM-like information for at-risk pedestrian users (rather than being vehicle mounted). The PSM message is described in further detail in the J2945/9 standard.
#33 Not Assigned at this time
The next message developed would be assigned this value as per normal SAE DSRC practices.
#240~#255 testMessage00 ~ testMessage15
These sixteen messages are be used by regional deployments in any way they see fit (the definition and use of the associated message us up to the deployment).

Outdated Messages

All these message must be encoded in ASN.1 BER-DER format (distinguished encoding rules).  The format of these messages reflects an earlier standard and style of encoding (published in 2009).  These message are no longer recommended for new work.

Msg# Message Name & Usage Commentary
#0 Reserved by SAE DSRC TC for use
A placeholder message value in the outdated DER encoding.
#1 alaCarteMessage-D (retired)
A retired message value in the outdated DER encoding.
#2 basicSafetyMessage-D
The older BSM msg, in the outdated DER encoding, not recommended for new use.
#3 basicSafetyMessageVerbose-D
The older BSM msg in its verbose format (allowing optional content), in the outdated DER encoding.
#4 commonSafetyRequest-D
A rarely used msg in the outdated DER encoding, not recommended for new use.
#5 emergencyVehicleAlert-D
A rarely used msg in the outdated DER encoding, not recommended for new use.
#6 intersectionCollision-D
A rarely used msg in the outdated DER encoding, not recommended for use.
#7 mapData-D
The MSP msg in the outdated DER encoding, not recommended for new use.
#8 nmeaCorrections-D
A rarely used msg in the outdated DER encoding, not recommended for new use.
#9 probeDataManagement-D
A rarely used msg in the outdated DER encoding, not recommended for new use.
#10 probeVehicleData-D
A rarely used msg in the outdated DER encoding, not recommended for new use.
#11 roadSideAlert-D
A simple form of the TIM msg,  in the outdated DER encoding, not recommended for new use.
#12 rtcmCorrections-D
The msg used to send RTCM data, in the outdated DER encoding, not recommended for new use.
#13 signalPhaseAndTimingMessage-D
The SPAT, a signal safety msg in the outdated DER encoding, not recommended for new use.
#14 signalRequestMessage-D
A signal safety msg in the outdated DER encoding, not recommended for new use.
#15 signalStatusMessage-D
A signal safety msg in the outdated DER encoding, not recommended for new use.
#16 travelerInformation-D
The TIM msg in the outdated DER encoding, not recommended for new use.
#17 uperFrame-D
A frame msg in the outdated DER encoding to hold other content, not recommended for new use.

See Also

These related message sets may also be of interest to you.

A cheat sheet of the most popular RTCM 3 Messages.

A complete list of all adopted RTCM 3 Messages with commentary.

A complete list of all adopted RTCM 2 Messages with commentary.

Common NMEA-183 messages of interest to GNSS NTRIP users  Site-1  and Site-2.

The only way to truly understand the details of the SAE DSRC message set is to purchase a copy for yourself from SAE, please do so if you have interest.  Here is the web page with some of the SAE standards you would need to do DSRC development work.


SNIP is a robust NTRIP Caster, but it also has built in utilities useful for message decoding

Need to see the internal contents of these messages?  Use SNIP‘s RTCM3 Decoder feature.

Need to use these messages in a navigation solution?  Use SNIP‘s Graphical Display feature

Need to quickly plot the ECEF location of a base station?  Use SNIP‘s Mapping feature.

Download your own copy of SNIP today

Was this article helpful?

Related Articles