An Error Protection Protocol for the Multicast Transmission of Data Samples in V2X Applications

Dedicated Short Range Communication (DSRC) technologies are IEEE 802.11p-based wireless communication systems for vehicular environments [47]. Implementations can be found in ITS-G5 [23] and in WAVE [32] offering ad hoc communication. Several use cases utilizing DSRC for the exchange of small status information have already been tested, including automated valet parking [35, 44], truck platooning [21, 30] and hazard warning systems [17, 22]. In WAVE, also larger data objects can be transmitted via UDP/IP. At its base DSRC uses the physical and data link layer of IEEE 802.11p. The standard handles channel arbitration by a decentralized Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) mechanism. Multicast communication is possible, however, error protection in 802.11 is only specified for unicast transmissions [29].

An alternative to IEEE 802.11-based DSRC technologies that appeared more recently are cellular-based technologies for V2X environments (C-V2X). They offer a sidelink mode, which enables ad hoc communication without the need for base stations [2, 4], such as required in out of coverage situations or for low latency communication. There are LTE-based (4G - Long-Term Evolution) [2] and 5G-based technologies [4]. Those standards try to improve upon 802.11p-based DSRC w.r.t. data rates and reliability. Instead of handling the channel arbitration via CSMA/CA, a Semi-Persistent Scheduling (SPS) approach is used [4]. W.r.t. error protection, a distinction must be made between LTE- and 5G-based technologies. The only means of error protection in LTE-based C-V2X broadcast is sending a packet twice (blind retransmission) [13], which is no sufficient protection for multi-packet samples at higher error rates. In contrast, 5G-based C-V2X provides an acknowledgement-based hybrid automatic repeat request (HARQ) mechanism with up to 32 retransmissions for multicast that can be used for retransmissions [4, 13, 24].

Moreover, while the C-V2X standard claims to be able to translate application-level requirements to network requirements, those network-level requirements are only applied on a packet level [4], rather than on the sample-level, missing out on the potential exploitation of an application’s sample structure and timing requirements. As a result, sample unaware protection leads to a non-controllable number of frame retransmissions that degrades the efficiency of the sample transmissions as well as interferes with sample transmissions on other links, as shown by Reference [41].

In summary, neither 802.11p nor the recent C-V2X based-systems offer appropriate error protection mechanisms for multicast on application sample level. Both require an application-level complement that can properly exploit sample-level timing for which the multicast protocol presented in this article would be a promising candidate. To provide maximum efficiency in such a middleware protocol, MAC layer retransmissions may be disabled, which is permitted by the standards.

Even though data rate improvements for C-V2X exist, it remains unlikely that those suffice for sensor data transfer in sidelink mode. For 802.11p (27Mbit/s) and its successor 802.11bd (54Mbit/s) the transmission of raw sensor data, e.g., a LIDAR stream (35Mbit/s) [1], are impractical, especially due to the nature of a shared wireless channel. Similarly, the performance of C-V2X in sidelink mode does not significantly exceed that of 802.11p/bd [11] in a way that would allow for efficient and reliable sensor data transfer. Data rates in the hundreds of Mbit/s, such as achievable using commodity standards like 802.11ax, are needed.

There are efforts to extend both cellular and 802.11-based technologies to address stringent reliability constraints for communication in safety-critical applications in automotive, industrial and robotic environments. We focus on two noteworthy extensions.

First, 5G-based C-V2X technologies have introduced a standard extension for Ultra-Reliable and Low Latency Communications (URLLC). A guaranteed reliability of 99.999 % is achieved by means of using redundant signal paths and HARQ mechanisms [3]. However, the guaranteed maximum latency is 1ms for 32 B packets and 10ms for packet sizes of 300 B only [5]. This profile results in extremely short latencies at low data rates, which demonstrates that URLLC has never been intended for the exchange of large samples but rather for the reliable exchange of small control information. This, and the fact that URLLC does not offer multicast extensions, makes it inapplicable for cooperative perception applications as considered in this work.

Not limited to cellular technologies are efforts to introduce Time-Sensitive Networking (TSN) mechanisms for wireless communication [8, 18]. Originally designed for wired Ethernet communication [28], TSN offers means of reliable and real-time communication. However, the efforts to bring TSN into the wireless domain right now focus on time synchronization and reliability of small data object communication [36, 45]. The intended use cases are similar to those addressed by URLLC, namely, real-time and safety-critical control and automation applications with short latency requirements.

Consequently, while URLLC and wireless TSN offer advancements towards real-time applications in wireless communication, they are not suitable for real-time communication of large data samples, as, e.g., needed for cooperative perception applications in our use case.

In literature, there have been several proposals on how to achieve reliable multicast communication in wireless channels. Realizing multicast via multiple unicast connections on the MAC layer cannot solve the limited data rate problem [19, 29]. Approaches adapting the Request-to-Send/Clear-to-Send (RTS/CTS) mechanism used in 802.11 unicast to multicast can only reduce collision errors and do not reduce bit error based frame losses [27, 33]. In this context, complementing or replacing existing bit-level FEC with packet-level FEC protocols to reduce the need for retransmissions has also been addressed [37, 43]. However, protecting large samples using erasure codes under potentially high error rates requires large amounts of redundancy information to achieve reasonable levels of reliability, making such protocols less efficient.

All approaches are agnostic to the application’s timing constraints that are relevant for the presented V2X use case. Moreover, the main focus is on reliability considerations without taking real-time requirements into account.

In contrast, and most relevant to our work, application-level middleware, such as DDS, is organized around the exchange of large data samples. The DDS specification defines a publish-subscribe-mechanism for multicast that includes error protection mechanisms for samples. In detail, the concrete data exchange protocol is implemented in DDS’s Real-Time Publish-Subscribe (RTPS) protocol, which supports communication via User Datagram Protocol (UDP) uni- and multicast [39]. As RTPS originally targeted wired (Ethernet) networks, where frame losses are rare, there are no protocol mechanisms supporting compliance to real-time requirements for lossy wireless channels. DDS implementations specifically designed for wireless networks can be found in wireless sensor networks (WSNs), e.g., References [9, 14]. However, their requirements rather focus on resource-constraint environments rather than on latency bounds as in our automotive use case. A proposal to use DDS in V2X applications can be found in Reference [42]. However, this work only considers the exchange of small objects via unicast and does not consider implications of the lossy wireless channel on error protection. Nevertheless, DDS features bitmap-based acknowledgments as well as the general notion of samples that are of interest for this article. For unicast communication, the Wireless Reliable Real-Time Protocol (W2RP) extends DDS in the context of a lossy wireless real-time setup [41]. It proposes shaping and timeout mechanisms, which are able to translate the application deadline requirements to the scheduling of frame (re)transmissions, and to prevent unbounded interference between different senders. However, W2RP only supports unicast. To address multicast with its complex feedback patterns, we need extended error protection protocols.

Overall, the majority of research in the field of reliable real-time wireless communication has focused on the exchange of small messages. This focus matches the need of many applications in areas ranging from WSNs to industrial automation to current versions of cooperative driving automation, as defined in SAE J3216 [31]. With small messages, focusing transmission timing and error control on individual packets is well justified. The relevance changes where large application data objects are involved requiring many packet transmissions for a single data object. The packets of such objects form coherent records that must jointly match reliability and deadline constraints. It is not clear that the protocols developed for individual packet guarantees are also appropriate for such compound data structures. On the contrary, the discussion above has already shown that the majority of available reliable and real-time protocols for small packets will not be efficient. As we will see in the sequel, the established frame-based approaches lead to inefficient solutions when compared to our novel, application-aware protocol.

On the lower stack levels, frame arbitration has to be managed to minimize collisions. This applies to cellular as well as to 802.11-based technologies.

To access the channel, IEEE 802.11 standards use a CSMA/CA approach. Before sending a frame, the protocol waits for a certain time in which the channel is idle. Each of such waiting times is generated with uniform random distribution within the so-called Contention Window (CW). This procedure reduces the chance for collisions. While SPS in C-V2X works differently from CSMA/CA, there is also randomness involved to reduce the probability of collision. Before transmitting data, channel sensing is used to determine free Resource Blocks (RBs) that could be used for transmission. The actual resource block used for transmission is then selected randomly from the set of free resource blocks within a selection window of a configurable but static size [4].

In the system model, we abstract from the specifics of the MAC layer protocol and focus on access time distribution. First, we assume the load on the channel to be constant at least up to the sample deadline \(D_S\) , i.e., we have an average channel idle time. Next, when drawing uniformly random values from the CW (802.11) or using channel sensing to select the next free resource blocks (C-V2X) within the selection window it will lead to an approximately uniformly random distributed waiting time w.r.t. the idle channel state. As an approximation, we have an average arbitration time ( \(\overline{t}_a\) ), which we define as the uniformly random distribution:Figure 2 depicts our arbitration model. Each transmission is delayed by an arbitration time \(t_a\) (Equation (1)), that on average has the duration of \(\overline{t}_a\) . Once the arbitration process succeeded, the transmission blocks the channel for \(t_{tx,data}\) , with \(t_{tx,data}\) depending on the frame size and the data rate.

After its successful arbitration at the MAC layer, a frame is transmitted over the wireless channel. In a wireless setup there are two sources of data loss. First, different frame transmissions can collide, whereas the chance for such a collision increases with the number of simultaneously accessing senders. Scenarios in which collisions dominate as reason for transmission errors represent an overload situation, in which the transmission of large data samples under real-time constraints is not possible anyway, as queuing effects delay fragment transmission and thereby would lead to service decommissioning (cf. above). As our work only addresses feasible setups, we do not consider this error class. Low or moderate amounts of errors due to occasional collisions, however, still allow for communication in the affected channel. Under such circumstances in a non-overloaded setup, the second source of data loss—bit-error related fading effects—dominate. Root-cause for fading effects are reflections, Doppler-Shift, shadowing, and so on, that influence the signal to noise ratio of the transmitted signal at the receiver.

We model those errors using a bit error rate, as it is common practice in the evaluation of wireless protocols [20]. Correlations between bit errors resulting in burst errors are not considered here specifically. Burst errors affecting multiple consecutive packets correspond to situations with excessive transient error rates, for which we cannot give guarantees with the work presented here. The resulting Bit Error Rate (BER), as adopted from Reference [41], describes the loss probability for each individual frame (Frame Error Rate (FER)), depending on the frame size ( \(S_\text{fr}\) ) in Byte. Different FEC mechanisms can reduce the BER, however, we refer to the residual BER, as it is the effective rate seen at the MAC layer.

In contrast to unicast, a multicast frame is simultaneously transmitted to multiple receivers. As the receivers can differ in their location, error rates can differ as well. We consider two scenarios: First, to cover the generality of the protocol, we use completely independent signal paths. Alternatively, there can be dependent signal paths. These allow to more accurately model use cases such as platooning meaning, where, e.g., due to line topology, a frame lost at the second truck will be lost by all other trailing trucks, too.

Together, the arbitration and loss models are sufficiently detailed to provide a proper basis for evaluation and comparison of different protocols.

RTPS supports UDP multicast and allows serving fragments to all readers in a multicast group simultaneously. As a result, a fragment transmitted by the writer ① can be received by all readers ②. Standard DDS, however, does not specify how to handle feedback from multiple readers in a multicast scenario, making it unsuitable here. When traversing from unicast (W2RP) to multicast, WiMEP can leverage the slack to address the issue of complex error scenarios.

In complex multicast scenarios, where the missing fragments and error rates at each reader can vary, a per-reader acknowledgment tracking is indispensable. Only by doing so, complex error scenarios can be addressed by the protocol. For this purpose, we track the reception progress of each reader at the writer. Each readers’ NackFrags are tracked in a separate vector at the writer ③. A fragment can either be “unsent” □, “sent” , or “acknowledged” . The reader ID transmitted as part of every NackFrag is used for differentiation here. With each NackFrag the writer’s tracking vectors are updated, keeping detailed up-to-date information on each reader. Fragments that are reported as missing by readers within NackFrags are reset to state “unsent” □ (e.g., ④).

In general, a sample transmission is split into two phases. In the transmission phase, all fragments are transmitted once in an ascending manner, starting with the smallest fragment number. NackFrag information are gathered but no retransmissions are performed. As WiMEP adopts the periodic shaping of W2RP, the fragments are transmitted with a fixed distance (shaping time \(t_f^{sh}\) ). During the retransmission phase, which is following the transmission phase and also adheres to the periodic shaping, the gathered information is used to select readers and fragments for retransmission. Arbitrary selection policies could be used to select the next fragment. As multicast is used for the retransmission as well, the retransmitted fragment can be used by each reader that is missing the fragment, reducing the number of retransmission overall. While it might seem excessive to send NackFrags following each received fragment if the information is only used at the end of the transmission phase, not doing so would have severe reliability implications. In case either the last fragment or the NackFrags following that fragment would get lost, the writer would have no indication which fragments need to be retransmitted. As a result, we require regular NackFrag responses during the transmission phase to ensure as much up-to-date information on the readers is available at the writer at the beginning of the retransmission phase. We acknowledge that moderately reducing the NackFrag rate could reduce overhead without severely reducing reliability, but the resulting benefit is small and will shrink with future higher data rates.

The per-reader tracking is also essential for efficient timeouts in multicast scenarios. Timeouts are indispensable in WiMEP to achieve reasonable levels of error protection in cases where no other fragments need to be transmitted and the NackFrags get lost. Without timeouts, this would result in the transmission progress being halted, as the writer does not receive any NackFrags acknowledging or signaling the failure of the last transmission. To avoid such scenarios, we define a configurable timeout of duration \(t_{TO}\) (cf. Figure 4). A timeout is activated if there are no unsent fragments remaining (all fragments are either in state sent or acknowledged ⑤). If no response to the heartbeat part of this message is received prior to the end of the timeout ⑥, then every fragment currently in state will be reset to □, allowing for further retransmissions of affected fragments ⑦.

In one-to-many communications, participants can be treated with different priority. The priorities can be either used for prioritizing of already stable links by reducing the negative impact of more erroneous links or to encode the importance and criticality of specific nodes based on the application’s context. In applications such as truck platooning both aspects often overlap. Data provided by the first truck is most important at trucks closest to it. Having intermediate trucks that do not receive the sample data disrupts platooning for all other trailing trucks as well, therefore, the closer to the leading truck, the higher the priority of a reader is. These priorities would correspond with the increasing likelihood of packet loss for trucks further behind the leading truck due to decreasing signal strength.

We propose a writer-centric prioritization mechanism that can leverage applications’ context information to improve retransmission performance. Writer-centric refers to the writer being designated for assigning priorities to the readers based on some configuration (function, algorithm, or table) as part of the information exchange happening between the writer and the readers during the discovery process (cf. Section 5.3). While the assignment of priorities in the truck platooning use case illustrates the advantages achievable with such a mechanism, the priority selection in other use cases might not be as straightforward. In infrastructure-supported use cases such as camera-equipped valet parking or intersection scenarios use cases there is no guarantee for line-of-sight connections. Therefore, the readers deemed most critical (e.g., closest to the area covered by the camera) must not be the readers with the lowest error rates, as shadowing due to walls or buildings within the signal path can decrease signal quality and thereby increase error rates. Consequently, it might be the case that samples can be delivered to less readers completely in time, however, safety is improved significantly. Safety is just one possible prioritization objective. Reader prioritization has many potential objectives, such as mission-criticality, cost, energy consumption or system performance, with applications in rescue operations, traffic, factory automation and robotics or smart buildings and infrastructure, to name just a few examples. The examples show that prioritization is application-context-dependent, which we consider out of the scope of this work. Instead, we focused on implementing a simplistic prioritization mechanism in WiMEP that prioritizes easy and wide usability and works with any priority selection.

If no fixed priorities from the application’s context shall be used, then WiMEP also allows for adaptive prioritization mechanisms using the gathered reader information, e.g., to use the packet delivery rate (PDR) as a priority, however, the system performance would be subject to similar tradeoffs as described above. The PDR is defined as the ratio between fragments acknowledged by a reader and the total number of fragments already sent by a writer:

If all readers are treated equally, then retransmissions to low-priority readers waste resources that could have been used for retransmission addressing higher-priority readers. In the worst case, this can lead to all readers missing their deadlines. For this purpose, we adjust the fragment selection mechanism in the Retransmission Phase (cf. Figure 4).

The retransmission phase is structured as follows: First, at each periodic transmission opportunity, the protocol uses its priority-based reader selector to determine the reader with the highest priority. Once a reader has been selected, its first previously negatively acknowledged fragment is selected and retransmitted via multicast. Hence, all readers missing that particular fragment can benefit from the retransmission. This procedure is repeated until no reader with missing fragments remains or the sample deadline has elapsed. Meanwhile, the timeout mechanism ensures transmission progress does not stall due to dropped fragments at the end of the retransmission phase.

The communication is set up with protocol parameters (fragment size \(S_f\) and period \(t_f^{sh}\) ), which are exchanged during the discovery process. During the discovery process of DDS/RTPS, entities (writers and readers) broadcast available services based on so-called topics. If a subscriber recognizes a publisher matching its topic, then it registers at the publisher and data exchange is initiated. As part of the broadcast of service information as well as during registration Quality of Service (QoS) parameters are exchanged between the entities, which was extended for the distribution of WiMEP parameters and priorities here. So far, we assume static parameter assignments for a platoon in operation. Dynamic parameter optimization might improve performance but increases risk of failure, because any transient transmission disruption due to dynamic reconfiguration states a safety violation. Hence, specific protocols will be needed to address parameter adaption and reconfiguration under consideration of stringent safety and timing constraints. This, however, is out of the scope of this work. Still, it is reasonable to define boundary conditions for the communication system. If the bounds are exceeded, then service can be discontinued or the mode of operation changes. This assumption seems acceptable in the platoon example, because there is a fallback truck behavior, as described in the beginning. Then, we can safely focus on the communication behavior within the bounds. The bounds presented in the following are the basis for the evaluation:

WiMEP is only usable in scenarios where no persistent overload situations occur over the course of a sample transmission. Those occur if the shaping time (here, \(t_f^{sh}\) ) is shorter than the sum of the average arbitration time \(\overline{t}_a\) and transmission times of data fragments \(t_{tx,data}\) and acknowledgments \(t_{tx,ack}\) . Note that for multicast data exchange between a writer and n readers, the acknowledgments of all n readers have to be considered. Persistent overload situations can lead to recurring blocking effects and delays due to queuing on the MAC layer that increase arbitration time even further, making timely sample transmission in those scenarios impractical. To avoid such effects, as in Reference [41], a lower bound for \(t_f^{sh}\) can be defined.

W.r.t. the maximum throughput, a protocol foremost is limited by the underlying technology. For periodic multicast protocols like WiMEP, though, the protocol’s maximum throughput is also bounded from above by other factors. Prior to a deadline \(D_S\) elapsing, based on the shaping time \(t_f^{sh}\) a maximum number of (fragment) transmissions \(N_{tx}^{max}\) are possible:

In error-free scenarios, this results in n times better throughput for multicast over one-to-many communication via multiple unicast streams, as all n readers can be served simultaneously compared to using multiple unicast streams. In non-error-free scenarios, it would be interesting to know to what (frame) error rate WiMEP is at best capable of maintaining error-free sample transmissions. Once again, the periodic nature of the protocol can be used to determine bounds for those error rates. We approximate the number of retransmissions ( \(N_{retr,i}^{needed}\) ). The number of missing fragments per reader is approximated using \(N_f * FER_i\) , where \(N_f\) is the number of individual fragments per sample calculated according to Equation (7) from the given sample size \(S_S\) and configured fragment size \(S_f\) . The number of retransmissions needed at a given FER can be described using the limiting sum of the geometric series in Equation (8). Each x represents a further retransmission step: \(x = 0\) gives the retransmissions needed after the transmission phase. \(x = 1\) then corresponds to the retransmission still needed due to errors occurring during retransmission for \(x = 0\) , Increasing x further continues this series. With this equation representing a geometric series and as \(FER^j \lt 0,\) the presented limiting function converges to the final form of Equation (8). The ceiling function is then used to account for the fact that fragments cannot be missing partly and are always retransmitted completely if dropped in a previous (re)transmission attempt.

Unless environmental conditions ensure dependent errors, independent errors and signal paths must be assumed as the worst case. Thus, for high but still manageable error rates, retransmissions will in most cases not reach all relevant readers. Using a conservative worst-case assumption, we assume that each reader requires \(N_{retr,i}^{needed}\) retransmission. Combining the fragment transmissions from the first phase of WiMEP and the retransmissions needed for each reader, the total number of transmissions needed to transmit a sample to n readers at a given error rate can be calculated by adding the sum of retransmissions needed for each reader. However, for dependent signal paths and errors this equation would vastly overestimate the packet losses and, consequently, the number of retransmission needed to transmit a sample successfully to all readers. To account for dependencies, we introduce the factor \(r_{d}\) that describes the ratio of common errors across different readers, either due to signal paths dependencies, common interference, or just coincidence. For \(r_{d} = 1\) (upper bound) Equation (9) corresponds to the worst-case scenario described above. However, for completely dependent errors, the lower bound of \(r_{d}\) ( \(\frac{1}{n}\) ) becomes relevant, highlighting the significant reduction in the number of needed retransmissions. Again, n here corresponds to the number of readers. Finally, all mixed scenarios with some dependent and some independent paths and errors lie between those bounds.

If \(N_{tx}^{needed}\) exceeds the maximum number of transmissions \(N_{tx}^{max}\) , a reliable sample transmission and thereby deadline violation rates of 0% are not feasible at a given error rate. Consequently, if the number of frame errors exceeds the maximum tolerable FER specified by \(FER_{max}\) in Equation (10) for a given shaping time, then augmented services utilizing the sample data will be discontinued and systems will fall back to a safe state. Only for smaller FERs, reliable sample exchange is possible.

We briefly investigate these reliability bounds in the following evaluation. Thereby, we focus on reliable sample transmission as in the protocol’s capability to transmit the sample completely to all readers within the sample deadline \(D_S\) and not reliability as a statistical parameter.

Reference [41] already demonstrated issues of frame-based retransmissions scheme using MAC-layer retransmissions as used in 802.11 unicast communication. The results showed that 802.11’s ARQ mechanism is unable to deliver the performance needed for real-time sample exchange in challenging channel conditions, resulting in frequent deadline violations.

We evaluated the effectiveness of state of technology retransmission mechanisms for multicast available in C-V2X, namely, blind and HARQ retransmissions, by integrating those into the 802.11 MAC layer. Figure 5 shows the deadline violation rates achieved when transmitting a 450 kB sample either of the frame-based retransmission exceeding 0% for anything exceeding low error rates. In contrast, the sample-based retransmission in WiMEP manages to not violate a single sample deadline. As a result, in the following, we focus only on sample-based retransmission protocols.

We compare the maximum error-free throughput achievable using WiMEP, Standard DDS with UDP multicast, and a modified W2RP protocol that supports serving multiple readers via multiple unicast streams (unicast one-to-many), in a simulated platoon comprising four trucks. WiMEP is configured with a period \(t_f^{sh} = {700}\,\mu {\mathrm{s}}\) , a timeout duration \(t_{to} = 2 * t_f^{sh}\) and a fixed fragment size of 11,306 B, to utilize the maximum MPDU-size of 802.11ax (11,454 B) when combining the payload (sample fragment) with the 148 B for all protocol headers needed here. The same configuration is also applied to the unicast-based protocol. Standard DDS uses the reliability QoS policy with the heartbeat period being set to \(3,\!500\, \mu\) s. We use this heartbeat period as a compromise between very short and longer periods that both result in extreme outliers, whereas the chosen heartbeat period enables reasonable communication in more conditions.

Figure 6 illustrates the results by visualizing the maximum sample size that the protocols were able to transmit without any deadline violations. It is apparent that WiMEP outperforms the other two protocols in all tested scenarios. While for 0% FER Standard DDS offers reasonable improvements over the unicast-based approach, performance degrades rapidly when increasing error rates. As a result, WiMEP offers double the throughput for FERs in range of 10% to 50%. Assume a constant LIDAR data stream of 35Mbit/s [1] that comprises 10 samples per second, each roughly \({450}\,{\text{kB}}\) in size. WiMEP is the only protocol allowing for a stable transmission of such data in a loaded wireless channel under all tested error rates.

A second important aspect of a wireless multicast protocol is the scaling performance w.r.t. the number of readers as platoons, and other use cases may comprise more than 3 readers. For that purpose, we tested the throughput of the three protocols at a FER of 20%. Results can be found in Figure 7. Increasing the number of readers, WiMEP is scaling the best and offers the highest violation-free throughput in all tested setups. For up to 6 readers standard DDS is outperformed or roughly matched by the unicast-based approach. This highlights that multicast without proper handling of lossy communication in shared wireless channels is not an option. Taking the LIDAR data example from Reference [1], only WiMEP is capable of transmitting the sample to up to 14 readers, with the first issue transmitting that data only observed for 15 readers. Meanwhile, both the unicast one-to-many and the standard DDS approaches did not manage to transmit the LIDAR sample to more than 3 readers without deadline violations.

WiMEP and DDS offered significant advantages over a unicast approach in Section 6.2 for 0% FER. However, for increasing FERs, DDS performance degraded rapidly, while WiMEP scaled better. To investigate the reasons, we compared WiMEP and standard DDS in varying channel conditions. The setup is the same platoon comprising four trucks as in Section 6.2, here transmitting a \({450}\,{\text{kB}}\) LIDAR sample with WiMEP using \(t_f^{sh} \in \lbrace {700}\,\mu {\mathrm{s}}, {1000}\,\mu {\mathrm{s}}\rbrace\) . We tested with increasing frame error rates and interference, with the latter being modeled using the average arbitration time. Note that, following the BER model w.r.t. Equation (2), the FER of smaller NackFrag messages is much lower than the one of the larger fragment messages, to which the FER refers in the following:

Figure 8(a) illustrates, that standard DDS works best only at low levels of interference. For comparison, both tested WiMEP configurations (Figures 8(b), 8(c)) offer more consistent behavior with reliable and violation-free sample transmission at substantial error rates feasible even at higher levels of interference. For both configurations the results are roughly in line with the technical limitations from Section 5.3 though are slightly lower due to statistical modeling effects affecting the violating rate at the fringes of the area of operation. The results also highlight the configurability of our protocol: Using the configurable shaping time parameter \(t_f^{sh}\) , which is only bound from above by Equation (4), it is possible to either adapt the protocol to support higher error rates at lower levels of interference or higher levels of interference at lower error rates.

So far, we have considered errors caused by fading effects while neglecting collision-related errors. Instead, the interference was abstracted and included in the average arbitration time \(t_a\) . To shed some light on behavior under collisions as well, we simulated multiple multicast applications, each comprising four trucks, that attempt to transmit the LIDAR sample ( \({450}\,{\text{kB}}\) ). Figure 9 shows the average arbitration time, the collision rate (FER), and the observed deadline violation rate for increasing number of (identical) applications utilizing the same channel. As already shown in Figure 8, longer shaping times \(t_f^{sh}\) allow for more resilience to interference—and thereby also for more applications using the same channel concurrently without deadline violations.

While the collision rate is not negligible, it is apparent that the main culprit for deadline violations is a significant increase in average arbitration time once Equation (5) is violated. In those instances where deadline violations occur for the first time for a given \(t_f^{sh}\) , the sum of a frame’s average arbitration time and the actual transmission time exceeds 1500 \(\mu {\mathrm{s}}\) , reaching even double-digit milliseconds, making a timely sample transmission infeasible. This can be explained by the overload situation resulting in queuing effects on the MAC layer, thereby significantly delaying fragment transmissions and eventually leading to deadline violations. Even more problematic, the queuing effects on the MAC layer caused by the overload situation prevail after a sample deadline is passed, delaying the fragments of a subsequent sample even more. In general, however, unless Equation (5) is violated, WiMEP is capable of coping with the errors caused by collisions.

Finally, our simulation results show that WiMEP is capable of addressing both error classes concurrently. We repeat the previous experiment, but this time also simulate errors caused by fading effects. These errors alone account for a FER of 10%. Figure 10 visualizes the results. It is apparent that less applications can utilize the channel simultaneously as, due to the additional channel load caused by the need for more retransmissions, the average arbitration time increased earlier compared to Figure 9, thereby also violating Equation (5) earlier. In spite of this, as long as Equation (5) applies, WiMEP can still sustain reliable and violation-free sample transmission in channels that suffer from collisions and fading-related errors simultaneously.

An essential mechanism introduced as part of WiMEP is the explicit prioritization of readers. The primary focus lies on preventing negative impact from a single reader with high FER. For experiments, we simulated a platoon comprising six trucks, with the readers experiencing different FERs. Sample and fragment sizes are set to 450 kB and 11,306 B, respectively, to accommodate LIDAR samples. A shaping period \(t_f^{sh}\) of 1,000 µ s is used. We simulated 4 FER combinations, with the FER of reader 4 being increased from 50 % to 80 %. WiMEP with prioritization was compared to a modified WiMEP implementation without the prioritization mechanism.

The results are presented in Figure 11. Without prioritization, the average individual deadline violation rates of all readers exceeded 0% in all tested scenarios (Figure 11(a)). In contrast, the WiMEP implementation applying the prioritization mechanism manages to achieve violation rates of 0% for readers 0–3 regardless of the FER experienced by reader 4 (Figure 11(b)). The results apply to scenarios with dependent and independent signal paths alike: Figure 12 visualizes the latencies of a setup configured with 600 kB samples and modified error rates. The latencies of readers 0–3 remain unchanged in case prioritization is used (Figure 12(b)), whereas not using prioritization leads to increased sample latencies and eventual deadline violations across all readers (Figure 12(a)). The “missing” boxplots for reader 4 are a result of the violation rate of reader 4 being 100%, hence there is no latency information available.

When comparing the results with the protocol bounds plotted in Figure 13, the importance of prioritization for predictability becomes apparent. In scenarios with independent signal paths and without utilizing a prioritization mechanism (cf. Figure 11(a)), due to the single high FER reader interfering with retransmissions to other reader, the bounds presented in Figure 13(a) cannot be met. In comparison, with prioritization WiMEP manages to exceed the bounds for independent path ( \(r_d = 1\) ), as the first four readers are subject to bounds for n (number of readers) = 4, as interference from any lower priority reader is prevented. Hence, readers with up to 30% FER do not experience any deadline violations. Similarly, for dependent signal paths (cf. Figure 12 and Figure 13(b)), it is apparent that not using prioritization results in not adhering to the bounds specified in Equation (10). This is contrasted by the results with prioritization that show all readers with FERs lower than the threshold defined by the curve for dependent signal paths ( \(r_d = \frac{1}{n}\) ) not violating any deadlines, as expected.

In mixed FER scenarios as assumed here, the prioritization mechanism is essential for the continuation of the augmented service for the majority of the platoon. It becomes apparent that the prioritization mechanism avoids more important readers (closer to the leading truck) being affected by a single low priority (PDR) reader, whereas not using prioritization leads to increased latencies for all readers and eventually to deadline violations. Using prioritization, only the truck at the end of the platoon would have to leave the platoon. Without prioritization, occasional sample deadline violations will occur at each reader, hence stable platooning is not feasible, as the augmented mode cannot be maintained. The advantages of the prioritization mechanisms do not only apply to platooning applications, but to any use case with similar cyber-physical context and prioritization criteria. To conclude, considering safety-critical applications, the protocol without prioritization does not suffice for systems with hard real-time requirements, whereas when using prioritization, such requirements can be met.

Considering the limited maximum throughput, full-resolution vehicular camera data (1,920*1,280 pixels and 24-bit color) such as provided by the Audi Autonomous Driving Dataset (A2D2)⁴ [26] cannot be transmitted using the presented setup. For a first test, we scaled down the resolution of frames to 257*171 pixels and used 8-bit color (grayscale) instead (cf. Figure 16). The resulting samples are 44000 kB in size. While not containing all information, basic information such as road boundaries, vehicles, and other potential obstacles are still recognizable, and we end up with samples that can be exchanged using the demonstrator setup. While we acknowledge that advanced future applications would rather use higher-resolution images, the effectiveness of error protection mechanisms for fragmented samples is valid even for lower data rates. Same as with the simulation, sample period \(P_S\) and deadline \(D_S\) are set to 100 ms.

The fragment size \(S_f\) for all following experiments has been set to 1500 B. Given that fragment size, in an initial test of WiMEP, we measured average FERs of 7% and 16% for r0 and r1 in the described setup, respectively. However, it is important to note that there are occasional samples with lower as well as higher FERs. Equation (4) under the assumption of an idle channel for \(t_{f,min}^{sh}\) and Equation (9) for \(t_{f,max}^{sh}\) can be used to estimate feasible parameter configurations for WiMEP. For the latter, a FER of 20% has been used as a point of reference. This results in the shaping time to be selected from \(\left[{0.6}{~ms},{2.6}{~ms}\right]\) . Using WiMEP with \(t_{f}^{sh}\) = 2,000 ms and standard DDS with a heartbeat period of 5 ms, both protocols were able to transmit the sample in a timely manner as long as there had been no interference.

For the direct comparison of standard DDS and the WiMEP implementation, we stressed the channel with additional load and measured the deadline violation rate at each reader. Load has been generated using iperf with the target load gradually increasing from 0Mbit/s to 20Mbit/s. At the upper end, this resulted in 74% of additional channel load. Using iperf’s pacing-timer parameter, the load has been configured to be constant and evenly distributed, transmitting 1500 B packets periodically, as can be seen from the visualized packet trace for 15Mbit/s load in Figure 17. The average periods of the iperf packets for the all four configurations are also plotted in Figure 17. According to Section 5.3, the chosen shaping time ( \(t_{f}^{sh}\) = 2 ms) should allow for deadline violation free sample transmissions in the given environment. Standard DDS retained the heartbeat period of 5 ms from the initial parametrization.

The results visualized in Figure 18 are based on 100 s traces resulting in the evaluation of 1,000 samples in total per data point. The trends in Figure 18 are in line with the simulation results from Section 6.3: Standard DDS only managed to transmit all 1,000 samples if there was no additional channel load. In all other tested scenarios, violation rates exceeded 0%, making standard DDS unusable for wireless multicast communication in use cases like truck platooning where any violation states a safety violation. Contrary to standard DDS, WiMEP only experienced deadline violations at target loads of 20Mbit/s that represent an overload situation with effectively 100% channel load. For all other experiment runs, no violations could be observed, making WiMEP an effective solution that is suitable for the timely exchange of large (fragmented) samples in safety-critical multicast scenarios.

To validate the effectiveness of the prioritization mechanism, we used a fixed channel load of 10Mbit/s. At that load and a shaping time of 2 ms, no deadline violations occur (cf. Figure 18). To investigate priority effects, \(t_{f}^{sh}\) was increased to 2.5 ms, thereby reducing slack for retransmissions and making the sample transmission more vulnerable to deadline violations. We compared WiMEP with and without reader prioritization. Again, results in Figure 19 and Figure 20 are based on a 100 s trace. Average measured FERs experienced by the readers remain unchanged at about 7% and 16% for readers r0 and r1, respectively. However, as the FER of some samples at r1 reaches 27%, we observe deadline violations at r1.

If no prioritization mechanism is used, then it is apparent that not only r1 but both readers experience deadline violations (Figure 19). Deadline violations at r0 correlate with late or incomplete samples at r1, as can been seen when looking at the excerpt of the trace of deadline violations at each reader in Figure 20. Even though r0 does not experience an exceptionally high frame error rate, the retransmissions to r1 affect r0: Fragments being retransmitted that are only missing at r1 prevent transmission progress at r0. Moreover, considering that r1 has a higher probability of not receiving a retransmitted fragment, the probability of required retransmissions is higher for r1, potentially blocking progress at r0 even more. Eventually, this is leading to incomplete or late samples at both readers. As a result, the operation of any envisioned platooning application without a prioritization mechanism is not possible under realistic load and FER conditions. In contrast, default WiMEP with the dedicated prioritization mechanism enables reader r0 (highest priority) to be unaffected by reader r1 (lower priority). This would enable safe platooning between the first two trucks. The increase in r1’s violation rate in comparison is irrelevant in this case, as any deadline violation rate exceeding 0% states a safety violation that would lead to service decommissioning.