Navigation bar
  Print document Start Previous page
 22 of 210 
Next page End  

SAE J2735-Draft-Rev18 [issued: 06-26-07] 
-
22 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
IEEE P1609.4 provides enhancements to the IEEE 802.11 medium access control (MAC) that support
WAVE safety, mobility and private applications in a multi-channel system by specifying mechanisms for
prioritized access, channel routing, channel coordination and data transmission.
The upper layers of the network stack, up to the application layer, are defined in IEEE P1609.3. There are
two pathways through the WAVE upper layers above the LLC layer: the Wave Short Message Protocol
(WSMP) stack and the UDP/IP stack. IEEE 1609.3 describes networking services for applications running
over either of these stacks, as well as describing the operation of the WSMP stack. Transmissions on the
CCH are limited to WAVE Short Messages (WSM). Either WSMP stack or UDP/IP stack may be used for
communications on SCHs. The WSMP stack is generally used for broadcast applications. 
IEEE P1609.2 defines secure message formats, and specifies how these secure messages are processed
within the WAVE system. These security services are designed to protect messages from attacks such as
eavesdropping, spoofing, alteration and replay, while respecting end users’ rights to privacy. The messages
covered in IEEE P1609.2 security procedures include WAVE management messages and application
messages, but do not include vehicle-originating safety messages. Security services for vehicle-originating
safety messages have not yet been specified in any standard, but will be required before vehicle safety
applications can be deployed.
4.3
Philosophy of Message Design
The DSRC message sets which are the subject of this standard are transported over the protocol stack of the
WAVE Short Message (WSM), a finite resource which must be conserved in order to promote the best
operations for all vehicles.  While other protocol stacks also exist over the DSRC media (and are in fact
expected to simultaneously carry a variety of other ITS related information including such things as ATIS
information encoded in XML forms), the WSM is characterized by short length packet message traffic,
often broadcast to other vehicles in an un-acknowledged delivery mode.  Dialogs and transactions do take
place, and such transaction can leave the control channel in order to use a service channel as needed, but
the general design goal is to maximize support for short broadcast style messages.  To that end, a dense
encoding of information is used in defining the message sets of this Standard.   Several of the design
aspects of this encoding are discussed below. 
This dense encoding uses a three-way approach:
1)
The smallest divisions of information content to be standardized are called Data Elements
2)
Data Frames are the next, more complex data structures to be standardized in this dense encoding
3)
The next level of complexity in the data structure standardization is called Messages
First and foremost, data elements and data frames are typically used  in a known order and with a known
element lengths and often appear without any form of element tagging info encoding because the specific
data element in question (and hence its definitions) can be determined by inspection.  This style of
encoding provided a dense set of packed bytes where the decoding of any byte can be determined by the
definitions. This style of encoding is used for many common messages (both complete messages and
messages which begin with known elements).  In these messages, other elements many be appended using
a simple byte-long tag encoding to separate the elements which follow.  The tag bytes relate to specific
elements of known length, and therefore a length value is not needed.  The range of tags in the two-byte
case follows the ITS practices for enumerations wherein the (upper) first 127 values of a byte are used for
national codes (in this case specific data elements and data frames) and the remaining 127 entries can be
used for local codes as needed.  Messages allow appending 2-byte tagged style to provide an open –ended
means to convey elements that were unknown when the standard was adopted and which are defined and
known only between local implementations.  Further, a range of the 2-byte tags can be used to send
variable length data elements (such as a string).  In this usage the 2-byte tag is followed by a single byte
representing the length of the data to follow.  This allows sending octets or strings up to 255 bytes in
length, and it allows receivers that do not comprehend the tag to calculate the word length and skip over it
to the next tag in the sequence.