This content is not included in your SAE MOBILUS subscription, or you are not logged in.

Performance Analysis of Existing 1609.2 Encodings v ASN.1

Journal Article
ISSN: 1946-4614, e-ISSN: 1946-4622
Published April 14, 2015 by SAE International in United States
Performance Analysis of Existing 1609.2 Encodings v ASN.1
Citation: Kumar, V. and Whyte, W., "Performance Analysis of Existing 1609.2 Encodings v ASN.1," SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 8(2):356-363, 2015,
Language: English


IEEE Standard 1609.2-2013, Security Services for Applications and Management Messages for Wireless Access in Vehicular Environments (WAVE), specifies its data structures and encoding using a proprietary language based on that used in the Internet Engineering Task Force (IETF)'s Transport Layer Security (TLS) specification. This approach is believed to allow fast encoding and decoding, but is non-standard, is not proved to be complete, lacks automatic tools for generation of codecs, and is difficult to extend. For these reasons, the 1609 Working Group approved the use of Abstract Syntax Notation 1 (ASN.1) for future versions of 1609.2, so long as ASN.1 did not significantly degrade performance.
This paper is the first publication of the results of a performance analysis carried out to determine whether ASN.1-based encoding was in fact acceptable. We consider the issues in designing a security protocol, such as supporting one-pass processing, as well as issues that affect processing time and memory requirements, such as byte-alignment. We show that a design that is optimized for encode/decode time is not necessarily optimized for other metrics, such as ability to support one-pass processing or size of encoded messages. We present results on encoding size and encode/decode time for four alternatives: (a) ASN.1 with Packed Encoding Rules (PER) Unaligned, with a schema optimized for processing time; (b, c) ASN, with a schema, optimized for the requirements of a security protocol, using PER Unaligned and the recently-published Octet Encoding Rules (OER), respectively; and (d) the current 1609.2 protocol.
Our results show that ASN.1 can be used without a significant performance hit, and in fact that the OER may allow faster operations than current 1609.2 implementations. These results in this paper were a significant contributing factor to the 1609 Working Group's October 2014 decision to adopt ASN.1 with OER going forward.