Information on transport protocol support

A transport protocol is typically used for transporting payloads (data bytes) exceeding the capacity of a single bus frame. If a payload cannot fit into a single frame, it is segmented into parts and transmitted using multiple frames. The receiving device is responsible for reassembling these segments back into the original payload. Upon successful reassembly, the receiver presents the full payload to the upper layer (as if the payload had been transported by a single frame).

Many different proprietary and open transport protocol specifications exist.

Generally, segmented transport of payloads can either be broadcast (1 to n) or one-to-one (1 to 1). One-to-one communication optionally allows for the use of flow-control. Below figure illustrates a (generalized and simplified) transport of segments as broadcast (without flow-control) and as one-to-one (with flow-control).

sequenceDiagram participant a as Node A participant b as All a->>b: Segment 1 a->>b: ... a->>b: Segment n

Broadcast (without flow-control)
sequenceDiagram participant a as Node A participant b as Node B a->>b: Segment 1 b->>a: Flow control 1 a->b: ... a->>b: Segment n b->>a: Flow control n

One-to-one (with flow-control)

Supported transport protocols

The decoders use the input DBC file(s) for configuration of transport protocols. See the DBC section for information on how to configure transport protocols.

Note

Decoding rules (defined by the DBC file(s)) are applied to fully reassembled payloads (with transport protocol specific headers etc. removed).

The following transport protocols are supported:

Timestamping

The reassembled messages are timestamped using the timestamp of the final segment.

Flow-control

Some transport protocols support flow-control. The reassembly generally ignores flow-control messages.

Concurrent / interleaved sessions

Multiple concurrent / interleaved transport protocol sessions are supported.

File crossing

Transport protocol reassembly is continued when crossing consecutive input log files. A transition between two non-consecutive log files aborts all active transport protocol sessions.