PRELIMINARY Examples of simple DSRC message encoded with and without tagging
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 be0x1111-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.
BytesValuesMeaning
0102-000A-1111111111-- msgID, currSec, tempID
0911-C54A45FA-0E4E1C-- tempID, Lat, Long.
1700-0032C8-2710-071C--- Long, Elevation, Speed, Heading
2500000000000000-F5-- AccelSet (7 bytes total), Brakes
3305DD-3C-00-0D5280-00-- Steering, Throttle, LightSet, VehSize, cnt1
4100-- 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.
BytesValuesMeaning
0102000A1111111111-- msgID, currSec, tempID
0911C54A45FA0E4E1C-- tempID, Lat, Long.
17000032C82710071C-- Long, Elevation, Speed, Heading
2500000000000000F5-- AccelSet (7 bytes total), Brakes
3305DD3C000D528001-- Steering, Throttle, LightSet, VehSize, cnt1
41050400-- 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.
BytesValuesMeaning
0102000A1111111111-- msgID, currSec, tempID
0911C54A45FA0E4E1C-- tempID, Lat, Long.
17000032C82710071C-- Long, Elevation, Speed, Heading
2500000000000000F5-- AccelSet (7 bytes total), Brakes
3305DD3C000D528001-- Steering, Throttle, LightSet, VehSize, cnt1
41050402AAAACCCCCC-- airbagTag, airbagValue, cnt2, 1st Item
49CCBBBBDDDDDDDD-- 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 TypeImplicit Encoding BER Encoding
Basic Msg 141 Bytes?? Bytes
Basic Msg with Type143 Bytes?? Bytes
Basic Msg with Type255 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.
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.
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
msgIDbasicSafetyMessage</msgID
secMark10</secMark
id1111111111</id <-- hex value
lat60369542144</lat
long_-984987654</long_
elev13000</elev
speed10000</speed
heading1820</heading
-accelSet
long_0</long_
lat0</lat
vert0</vert
yaw0</yaw
</accelSet
-brakes
wheelBrakes11110000</wheelBrakes <-- Note extra bits
tractionoff</traction <-- note enumerated strings
absoff</abs
</brakes
steering1501</steering
throttle60</throttle
lightSet/>
-size
width213</width
length640</length
</size
valueCnt10</valueCnt1
items1/> <-- note null value
valueCnt20</valueCnt2
items2/>
</BasicSafetyMessage
The Basic message rendered into XML format by the same tool
Example with type One Content, in BER
Repeating the prior message, but encoded in BER we have the following message. It has now grown from 96 to 106 bytes (ten bytes). The data values used were the same as the implicit encoding case. You can see the airbag tag value highlighted in the below.
Message with type One content, 106 bytes
Example with type Two Content, in BER
Repeating the prior message, but encoded in BER we have the following message. It has now grown from 106 to 135 bytes (29 bytes). The data values used were the same as the implicit encoding case. You can see the user defined tag value 0xBBBB highlighted in the below.
Message with type Two content, 135 bytes
So what have we learned?
Our message has more or less doubled in size. Reviewing this in a table we see:
Message TypeImplicit Encode BER Encode BER Est
Basic Msg 141 Bytes96 Bytes84 Bytes
Basic Msg with Type143 Bytes106 Bytes94 Bytes
Basic Msg with Type255 Bytes135 Bytes123 Bytes
The value for the BER Est column represents what I believe would be achieved if we were to re-code the message to remove the extra content we added for our own tagging systems and allow BER to operate as intended. In gross terms, we are still looking at a doubling of the transmitted message size.
Summary thoughts and recommendations
The above is intended to show BER in the most unfavorable light, because it is adding the extra tagging bytes to the implicit data required for its tagging systems to the message. This is a very unfair comparison because it fails to expose the great benefits to builders in having these tags. Further, we have some extra tagging present in the DSRC work due to our own decision to use implicit encoding that would be removable (about 12 bytes in this instance). In a nutshell, the builder can use standardized libraries rather then construct these hand encoded messages with custom code and the message set itself can become much more diverse and varied with almost no additional effort to the developer who comes to depend on the tools he has purchased and BER to decode the actual bit stream for him.
Speaking from my own perspective and biases, the above report data certainly would not convince me to use BER. The effort required to build a custom DSRC message parser to deal with implicit encoding seemed to be enough for the POC team to want to use BER, and I feel that is the right choice. But in considering the long term solution the SAE committee should weight this carefully. The contrasting argument is that the cryptographic layer wastes message bytes all over the place, so why go to such effort to conserve here.
The example used here is not very nested, and does not show the value of the tagging in handling more complicated messages. I would ask the reader to consider what the implicit parser problem will look like for the map fragments and perhaps hold off judgment on BERs merits until more of that work is developed. Then, I remains rather confident that despite the increase in message size it brings, people will want to use BER as the preferred approach.
Prepared for the DSRC committee
Feb 22nd 2007
DC Kelley
Further background:
Here is an interesting and simple backgrounder on BER encoding, I do not agree with it all, but it gives a good overview. The document also lists several places for free or low cost ASN tools and viewers that may be of interest, especially to those that hate Microsoft based tools. Be aware that the XER spoken of here is NOT THE SAME as the XML rendering founding ITS and using a conversion standard published by the SAE. Although they are very similar and one can convert between them with modest effort.
1
[1]A fine point to this is that both parties need to know what the tags and length mean, but they do not need to encode it into proper ASN. I suppose this could be argued as an advantage for this approach over BER encoding where you must define all the possible items you might chose to send in the ASN which both parties use to create the decoding logic.
[2]Because the maps are mostly short “extension” values from a known reference point and even if we allow for “long” values in the extensions, the BER encoding would only use the least number of bytes needed to reflect the actual data being sent and most intersection geometry will consist of short (rather then long) extensions. Hence, combined with the ease of nesting data concepts, we can start to see the benefits of BER over hand encoding in such a case.
[3]You can read this file with ANY valid BER reader tool, it does not need to have the ASN of the DSRC message set. However, with the source ASN.1 file information the defined types can be displayed from this primitive forms (integers etc) in the names we have called them in our message set. This is somewhat, but not quite, the same as using the XSD schema files we produce for XML instances.
[4]If we re-code the ASN with BER in mind these would take ~8 bytes and 3 bytes respectively, in other words, if we decide to go with BER much of this type of annoyance can be fixed. The lightSet value happens to show this style because it fits nicely in to a single byte.