 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev29 [issued: 12-11-08]
-
235 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
Table 2 - Message Priorities
(above table will need to be in B/W to keep SAE pubs happy)
Common Message Header
All messages defined by this standard use elements from a common message header to some degree. In
some messages these elements are defined as optional and may not be present. However, if the defined
data element is sent in the message it SHALL appear in the order and with the structure defined for it in the
common message header for that message. These elements appear in-line and without any form of
encoding structure (such as a sequence) in order to conserve payload bytes. The specific form of each
message is defined by the preceding sections. Unless the term OPTIONAL appears in the ASN definition
for a given data element, that data element is required to be present.
For a generic message, the common message header elements are defined as shown below.
-- Generic Message Structure
AnExampleMessage ::= SEQUENCE {
-- Header items
msgID DSRCmsgID,
msgCnt MsgCount,
id TemporaryID,
-- Message Content itself is defined here
-- Message Content itself is defined here
-- Message Content itself is defined here
... -- # LOCAL_CONTENT
-- Final header item
crc MsgCRC OPTIONAL
}
Of the above four elements, only the msgID element (of type DSRCmsgID) SHALL be mandatory at all
times. This element is used to detect and determine what the content of the rest of the message is (as
defined by the ASN and XML this standard). See the entry in the preceding section for its definition and
usage notes.
The MsgCount element MAY optionally be present in those message definitions that require it. See the
entry in the preceding section for its definition and usage notes.
The TemporaryID element MAY optionally be present in those message definitions that require it. See
the entry in the preceding section for its definition and usage notes.
The crc element (of type CRCvalue) MAY optionally be present in those message definitions that require
it and the value SHALL always occupy the last two bytes of the message payload.
4
This element is
transmitted when the underlying protocols will not expressly provide a suitable CRC value for each
recovered (received) message. The purpose of this data element is not to ensure message reception
correctness (which the lower layers are presumed to handle) but rather as a message level hash value of the
preceding payload content.
When handing a message payload off to the lower layers (or when recovering one) there is additional data
also exchanged with that layer. This information (generically called common management information) is
specified elsewhere in this annex when it is defined by the standard.
4
In fact the T-L-V of this data element occupies the last 4 bytes of the message payload, but only
the last two bytes contain the actual crc value itself.