Examples of simple DSRC messages encoded with and without ...



PRELIMINARY

Examples of simple DSRC message encoded with and without tagging

davidkelley@

This paper presents a few simple DSRC messages with the literal encoding style defined in the current standard and also with the BER style of encoding being considered for use in the POC work and as a possible preferred encoding for future editions of the standard.

Prerequisites

In order to create these messages one will need two prerequisite items, first a set of common data values encoded into their hex representation forms and second a tool to encode the messages into the BER formats.

The first of these is provided by a simple utility tool I created over the weekend and available download at

The second is a low cost (~200) commercial tool called “ASN1VE ASN.1 viewer/editor” and available at There are other such tools, but I am been suggesting people use this one as a starting point.

I strongly urge anyone interested in creating these messages to obtain these two tools.

If you only want to read this document and understand the problem, you will not need them.

In order the make the data example more recognizable, I have re-used the same data values in multiple instances of the messages. A list of these values is given here in both the base ten and the hex values. These values will become patterns seen in the messages that appear subsequently.

The data itself

The data used in the message examples was encoded with the tool mentioned above.

The values chosen were as follows:

DSRCmsgID varies with each message type, basic safety is 0x02

Seconds at 0.010 sec becomes a value of 0x00-0A

(in seconds x 100, this is milliseconds precision for the current minute)

The tempID is chosen to be 0x1111-1111-11 (poss error here, should be 6)

(this may be the macID at times)

Longitude at -123.1234567 degrees is a value of 0xF8-A9-48-FF

in units of micro degrees

Longitude at -123.1234567 degrees is a value of 0xC5-4A-47-FA

in units of 1/8th micro degrees

Latitude at 30.0 degrees is a value of 0x01-C9-C3-80

in units of micro degrees

Latitude at 30.0 degrees is a value of 0x0E-4E-1C-00

in units of 1/8th micro degrees

Elevation at 300 meters is a value of 0x00-32-C8

Speed at 100 m/sec becomes a value of 0x27-10

Heading at 10 deg becomes a value of 0x07-1C

AccelerationSet4Way is made up of 0x00-00-00-00-00-00-0

Representing Accel in all three axis (lat, long and vert) set to zero and yaw rate also set to zero

Brakes is made up all brakes on (B1111) and ABS and traction set off, so of 0xF5

Steering is 30.01 degrees of angle, so of 0x05-DD

Throttle is 30 percent, so of 0x3C

Light Sets is made all lights off, so of 0x00

Vehicle size is made up of width 213 cm so 0x00-D5 and length of 640 cm

so 0x02-80 resulting in a 3-byte value of 0x0D-52-80

The valueCnts for item types one and two will be set to zero (no items) in our first example, so both are 0x00

The above values will be used in the message that follow. It is important for this study to use values where the full length of the data range is used. Some of the encoding rules found for ASN (such as BER) can take advantage of “shorter” data instances, encoding only a byte rather then more bytes at times. While this is laudable, we do not want it to have a hidden effect on the comparisons of the data we are sending as we examine encoding rules and message lengths.

A First Message, the basic safety message

The messages have been consistently laid out in an 8-byte across pattern. If you use the BER tool mentioned above you can see a layout similar to this and when you pause your mouse key over the data field a nice little pop-up will tell you what part of the message that is. This can be incredibly helpful when decoding raw bytes. Here is a template for the BasicSafetyMessage (see the on-line documentation pages 20-23) with implicit encoding following this format and using the data values just presented. Note that this message is 41 bytes in length with this content.

Bytes Values Meaning

01 02-00 0A-11 1111 1111 -- msgID, currSec, tempID

09 11-C5 4A45 FA-0E 4E1C -- tempID, Lat, Long.

17 00-00 32C8- 2710- 071C- -- Long, Elevation, Speed, Heading

25 0000 0000 0000 00-F5 -- AccelSet (7 bytes total), Brakes

33 05DD- 3C-00- 0D52 80-00 -- Steering, Throttle, LightSet, VehSize, cnt1

41 00 -- cnt2

The dashes in the above (“-“) show where data elements separate and are presented to help the reader the first time through all this.

If there was some content carried in the “item1” or “item2” part of the message, it might look like the above for the beginning of the message but the latter words would contain this additional data. We examine two examples of this next.

Example with type One Content

Presume we wish to send the airbag count. The airbag count itself (lets use a value of four airbags, so 0x04) is preceded by the airbag count tag item, which is defined as the value five (0x05) There is one set of data, so the cnt1 becomes a value of 0x01. These items are inserted before the final cnt2 item (which remains zero because no items of that type are sent). The resulting message is two bytes longer and is shown below. Note that this message is 43 bytes in length with this content.

Bytes Values Meaning

01 0200 0A11 1111 1111 -- msgID, currSec, tempID

09 11C5 4A45 FA0E 4E1C -- tempID, Lat, Long.

17 0000 32C8 2710 071C -- Long, Elevation, Speed, Heading

25 0000 0000 0000 00F5 -- AccelSet (7 bytes total), Brakes

33 05DD 3C00 0D52 8001 -- Steering, Throttle, LightSet, VehSize, cnt1

41 0504 00 -- airbagTag, airbagValue, cnt2

Example with type Two Content

Presume we wish to again extend this using a couple of the type2 items. These items are declared to be defined OUTSIDE the standard, and it is presumed that the sending and receiving party know the length of the data and the semantic meaning.[1] The length is vitally important in order to detect the end of each item and the beginning of the next item. Note this is true even when what is sent is a data element defined from the standard.

Consider a user defined 2-btye tag of 0xAAAA and one of 0xBBBB. Consider the payload data to be 4 bytes in length and consisting of the values 0xCCCC-CCCC and 0xDDDD-DDDD. The cnt2 value would be 0x02 representing that two items of some length (known by the tag the follows) are to be found. The message is shown below. Note that this message is 55 bytes in length with this content.

Bytes Values Meaning

01 0200 0A11 1111 1111 -- msgID, currSec, tempID

09 11C5 4A45 FA0E 4E1C -- tempID, Lat, Long.

17 0000 32C8 2710 071C -- Long, Elevation, Speed, Heading

25 0000 0000 0000 00F5 -- AccelSet (7 bytes total), Brakes

33 05DD 3C00 0D52 8001 -- Steering, Throttle, LightSet, VehSize, cnt1

41 0504 02AA AACC CCCC -- airbagTag, airbagValue, cnt2, 1st Item

49 CCBB BBDD DDDD DD -- 1st Item, 2nd item

Laziness and lack of time prevent me from adding more messages right here, forgive me. [Besides most of this work is really guide effort stuff]

Let consider these implicitly encoded test cases and their lengths, partial data is present in the table below.

Message Type Implicit Encoding BER Encoding

Basic Msg 1 41 Bytes ?? Bytes

Basic Msg with Type1 43 Bytes ?? Bytes

Basic Msg with Type2 55 Bytes ?? Bytes

Next step is to load this into the BER viewer tool and re-do the data their way.

Encoding the Same Message in BER form

First, it should be pointed out that an “empty” message of this type is 77 byes long when loaded with nothing but “zero data values” and the required tagging. You can see this with the ASN1VE tool when you first open an empty message. The message is longer (from 41 to 77 bytes) because of the presence of the tagging, but the actual data values are shorter (each is only one byte in length) because BER has the property to save extra bytes of length when it is not actually used by the data to be transmitted. This will become very important when we deal with the map fragment messages.[2]

Looking at this another way, we have ~20 elements in this message. Considering that each tag-value requires two bytes to encode in the BER style, we would expect to see about 40 bytes in pure tagging information added to our message. We have 41 bytes of pure information, this suggests that we should get a message of ~80 bytes when useful data is sent.

The below screen shot shows the ASN1VE tool with this message loaded. The panel on the left is showing the instance names from the ASN (in other words ‘secMark” is an instance of our DSRC defined type “Dsecond”). The gray highlighting of this element is reflected in the highlighting shown in the panel at the upper right, where the actual bytes over the wire for the value secMark is also highlighted. The panel below is the value of this data item (set to 10, as in 10 milliseconds, or 0x0A in Hex) as well as some of the actual tagging information for the element. The tabbed display allow seeing this same information in an XML and a textual format as well. Off to the right side (not shown for size reasons) is an ASCII-text decode of the message content as well.

Observe that the element ‘secMark” is sent in three bytes with the values 0x81-01-0A which reflect the BER style of encoding into a sequence of tag-length-value. Here you can see the encoding values clearly, In general the first two bytes are the tag and length value, followed by one or more bytes to send the data. Play with the tool if you want to see more, it is much more instructive when interactive.

[pic]

The Basic Safety Message (empty) displayed in raw bytes

Hand loading the rest of the data value from the prior example into the tool produced the image shown next. This file has been saved as msg1.dat and is a binary file.[3]

Observe that while the time value was “shortened” a byte by the BER process, the other values were chosen to be full length and representative to prevent any such shortening from occurring when we compared the data. Notice also that structures like the acceleration set, which was crafted to fit into a 7-byte length, is now larger (14 bytes) because the BER encoding has placed tags around each inner element. In the brakes structure, a similar thing has occurred. With some judicious re-coding of the ASN this can be overcome, but it is typical of the BER process.[4] You pay for extra tagging in greater transmitted word count (about two bytes per element), you get extra flexibility in the message design and handling and less custom coding effort.

Notes in developing the next example: The lat and long are reversed in the above example, but this does not change the byte counts. It just shows how what a pain it is to get these things right by hand. The elevation in the BER example was shorted by the BER rules by one byte. Note that there are short (2-byte) entries for “items1” and “items2” in the display, even though in this example there are no such items. Because we hand encoding the DSRC message we have a “count” value that appears in the message to allow the receiving side to decode what follows. With BER this is more or less handled automatically so 6 of these bytes would not be needed here. Overall the BER message below is perhaps 12 bytes longer then it would need to be if we were to re-code the ASN intending to use BER from the onset.

The resulting message is 96 bytes in length. A bit longer than the estimate of 81 bytes, but this is due to the inner tagging that BER has placed on some of our structures. I feel a value of 84 bytes is perhaps more representative.

[pic]

Basic Safety Message encoded with BER format, 96 bytes in length

For completeness, I also provide this same message rendered into the XML format called “XER” that this tool supports. The primary difference between this and the ITS style formats is that the enumerated values are not showed as quite the same style of textual strings and some values display in hex rather then base ten.

-

  basicSafetyMessage

  10

  1111111111 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download