Data Encoding Performance

Measured runtime performances for data encoding (i.e., serialization) for the security envelope of ETSI ITS are given in Figure 4.1. To obtain the given results, the evaluation methodology described in Section 3.4 is used together with implementation of the different data representation schemes as described above. The given averages are calculated from the results of 10.000 test runs.

One can see from the results presented in Figure 4.1 that the binary scheme massively out- performs all other generic data representation schemes. Moreover, ASN.1 encoding outperforms its protobuf and EXI counterparts.

A significant source of influence on runtime performance for encoding the security envelope is the high number of small and deeply nested data fields used for defining the security envelope (see also Table 4.4). The achieved results depicted in Figure 4.1 indicate that binary encoding can handle this kind of structure better than the other encoding schemes. Moreover, ASN.1 and protobuf are almost on par and both clearly outperform the EXI mechanism.

nesting level 1 2 3 4

sec. profile 1 (CAM) w/o cert. 5 16 4 0 sec. profile 1 (CAM) with PSC 5 22 21 11 sec. profile 2 (DENM) 5 22 23 11 sec. profile 3 (Generic) 5 22 22 11

Table 4.4: Nesting of data fields for individual security profiles’ security envelopes. The numbers in Table 4.4 give the amount of data sets (mandatory and optional) found at the different nesting levels. To obtain the figures in Table 4.4, the full data sets were represented in a tree structure. As only mandatory data fields are used in the provided performance study, the elements of sub-trees following an optional element are not counted. Nesting level one means the top level of the data packet, whereas nesting level four relates to the data elements at the most deeply nested position inside the data packet. Such deep nesting is only present within the PSC’s data structure. One can see from Figure 4.1 that for all data representation schemes the data structure with the least complex structure (security profile 1 without included certificate,

0 200 400 600 800 1000 1200

binary ASN.1 protobuf EXI

runtime in microseconds

profile no. 1 w/o PSC profile no. 1 w. PSC profile no. 2 profile no. 3

(a) Encoding runtime performance on AMD Geode processor.

0 50 100 150 200 250 300

binary ASN.1 protobuf EXI

runtime in microseconds

profile no. 1 w/o PSC profile no. 1 w. PSC profile no. 2 profile no. 3

(b) Encoding runtime performance on Intel Atom processor.

0 10 20 30 40 50 60

binary ASN.1 protobuf EXI

runtime in microseconds

profile no. 1 w/o PSC profile no. 1 w. PSC profile no. 2 profile no. 3

(c) Encoding runtime performance on Intel Core I7 processor.

Figure 4.1: Data encoding runtime performances on different processors.

see Table 4.4) requires significantly less computational performance in comparison to all other data structures.

For all results the standard deviation is given in Figure 4.1. In general, values for this statis- tical metric are small in comparison to the given averages. Therefore, the achieved measurement results can be regarded as significant. The differences between the obtained results for different encoding schemes for same encoded data content are much bigger than three times the standard deviation of the corresponding runtimes in almost all cases. Only the quite similar results for ASN.1 and protobuf show a significant overlap of their standard deviation intervals.

Comparing Figures 4.1c, 4.1b, and 4.1a one can see that except of a general increase in runtime (please note the different scaling of the vertical axis of figures), the overall results are the same for all processor technologies. This means the overall outcome of the performance study does not change by switching from a modern high speed processor (like the Core i7) to a quite old and low speed processor, like the AMD Geode. Lower processor speeds (see also Table 3.2) lead to increased runtimes, as can be expected. However, the increase is somewhat bigger than what can be calculated just by comparison of corresponding processor clock speeds. It is reasonable to observe an advantage in the runtime performance of the Core i7, which is due to the improved processor technology such as pre-caching algorithms, as it was introduced to the market significantly later than the used Atom and Geode processors.

lope’s variants. In each cell, the first figure relates to the number of bytes consumed on the heap, while the second one gives the number of bytes used on the stack. Both values give the corresponding peak values during runtime of the measured algorithm. The profile column gives the number of the security profile as defined in [109]. As described before, the two cases of an envelope with and without certificate are to be distinguished for security profile number one (used for CAMs).

profile binary protobuf ASN.1 EXI (optimized)

1 (CAM) w/o cert. 240 / 12168 1784 / 13528 1463 / 19784 61760 / 680 1 (CAM) with PSC 798 / 15800 3819 / 15016 2186 / 20528 63313 / 680 2 (DENM) 798 / 15800 4023 / 15016 2186 / 20528 63553 / 680 3 (generic) 798 / 15800 3865 / 15016 2186 / 20528 63457 / 680 Table 4.5: Encoding performance results for the security envelope. All values are given in bytes.

In regard to the sum of consumed memory (heap plus stack), binary encoding outperforms all other encoding schemes according to the results from Table 4.5. One should note that the high amount of consumed memory for the EXI implementation is due to the fact that the used encoder does not use any kind of a-priori code generation, as it is used for common ASN.1 and protobuf approaches. Instead the exip library [201] generates the encoding tree on-demand in memory, which is a highly flexible approach. However, it is targeted for experiments and not for mass roll out in embedded systems. Hence, practical realizations for VANETs should use another implementation approach with less demanding runtime and memory requirements.