Time-Sensitive Network (TSN) Experiment in Sensor-Based Integrated Environment for Autonomous Driving

Recently, large amounts of data traffic from various sensors and image and navigation systems within vehicles are generated for autonomous driving. Broadband communication networks within vehicles have become necessary. New autonomous Ethernet networks are being considered as alternatives. The Ethernet-based in-vehicle network has been standardized in the IEEE 802.1 time-sensitive network (TSN) group since 2006. The Ethernet TSN will be revised and integrated into a subsequent version of IEEE 802.1Q-2018 published in 2018 when various new TSN-related standards are being newly revised and published. A TSN integrated environment simulator is developed in this paper to implement the main functions of the TSN standards that are being developed. This effort would minimize the performance gaps that can occur when the functions of these standards operate in an integrated environment. As part of this purpose, we analyzed the simulator to verify that the traffic for autonomous driving satisfies the TSN transmission requirements in the in-vehicle network (IVN) and the preemption (which is one of the main TSN functions) and reduces the overall End-to-End delay. An optimal guard band size for the preemption was also found for autonomous vehicles in our work. Finally, an IVN model for autonomous vehicles was designed and the performance test was conducted by configuring the traffic to be used for various sensors and electronic control units (ECUs).

There are two representative standards that redefine the queuing process for time-sensitive traffic transmission. The first is IEEE 802.1Qbv-2015. The IEEE 802.1Qbv standard has extended the time-based scheduler for time-sensitive traffic transmission and its queuing procedure over AVB traffic transmission structure [7]. The transmission method of existing AVB streams was an event trigger. However, in a TSN, a time-aware scheduler is applied in addition to the existing method to transmit scheduled traffic (ST) by a time-trigger transmission method. ST is transmitted at regular intervals in the vehicle as important data related to vehicle control and safety. If the transmission requirement of the existing AVB stream is to deliver within the maximum 2 ms time delay when passing seven hops, the transmission requirement of the ST is to deliver within 100 µs time when passing five hops. A hop represents a switch. All nodes (switches, gateways, sensors, or ECUs) must be synchronized to the same clock with almost no error in order to transmit the ST properly based on the transmission time. Therefore, a time-aware scheduler should be applied with the time synchronization function of the IEEE 802.1AS-rev standard [13]. In this paper, we refer to this standard and implement these functions in the simulator. The second standard is IEEE 802.1Qbu-2016 [7]. IEEE 802.1Qbu is the standard that defines the preemption mechanism. In the existing transmission policy, if there is a frame being transmitted, the frame is designed to wait until the ongoing transmission is finished, even if there is a frame that needs to be transmitted urgently. However, with the preemption technique, high-priority frames can be preferentially processed. The preemption may interrupt the transmission of a low-priority frame (AVB) during transmission to preferentially process a time-sensitive frame (ST). After processing the high-priority frame, it resumes transmission of the low-priority frame and receives it in the full frame. When switching gates for transmission between ST and AVB, a "guard band" is set for a certain time window to prevent frame collision (see Figure 1). Low-priority frames can be divided into two or more frames as needed. There are two representative standards that redefine the queuing process for time-sensitive traffic transmission. The first is IEEE 802.1Qbv-2015. The IEEE 802.1Qbv standard has extended the time-based scheduler for time-sensitive traffic transmission and its queuing procedure over AVB traffic transmission structure [7]. The transmission method of existing AVB streams was an event trigger. However, in a TSN, a time-aware scheduler is applied in addition to the existing method to transmit scheduled traffic (ST) by a time-trigger transmission method. ST is transmitted at regular intervals in the vehicle as important data related to vehicle control and safety. If the transmission requirement of the existing AVB stream is to deliver within the maximum 2 ms time delay when passing seven hops, the transmission requirement of the ST is to deliver within 100 μs time when passing five hops. A hop represents a switch. All nodes (switches, gateways, sensors, or ECUs) must be synchronized to the same clock with almost no error in order to transmit the ST properly based on the transmission time. Therefore, a time-aware scheduler should be applied with the time synchronization function of the IEEE 802.1AS-rev standard [13]. In this paper, we refer to this standard and implement these functions in the simulator.
The second standard is IEEE 802.1Qbu-2016 [7]. IEEE 802.1Qbu is the standard that defines the preemption mechanism. In the existing transmission policy, if there is a frame being transmitted, the frame is designed to wait until the ongoing transmission is finished, even if there is a frame that needs to be transmitted urgently. However, with the preemption technique, high-priority frames can be preferentially processed. The preemption may interrupt the transmission of a low-priority frame (AVB) during transmission to preferentially process a time-sensitive frame (ST). After processing the high-priority frame, it resumes transmission of the low-priority frame and receives it in the full frame. When switching gates for transmission between ST and AVB, a "guard band" is set for a certain time window to prevent frame collision (see Figure 1). Low-priority frames can be divided into two or more frames as needed.  In order to transmit the ST at the reserved time, there is another method of blocking the frame (1500 bytes of maximum frame size) from entering before the transmission cycle of the ST. However, it is inefficient in utilizing network resources and also increases the delay time of non-ST frames. Therefore, the preemption is required to increase network efficiency and reduce overall delay time. The standard technologies mentioned above have been consistently conducted with the standardization work. In general, theoretical analysis of the time-aware scheduler of a TSN and experiments measuring IVN performance through simulation are the main subjects. Recently, there have been studies analyzing the performance of the preemption [14][15][16][17][18]. In order to transmit the ST at the reserved time, there is another method of blocking the frame (1500 bytes of maximum frame size) from entering before the transmission cycle of the ST. However, it is inefficient in utilizing network resources and also increases the delay time of non-ST frames. Therefore, the preemption is required to increase network efficiency and reduce overall delay time. The standard technologies mentioned above have been consistently conducted with the standardization work. In general, theoretical analysis of the time-aware scheduler of a TSN and experiments measuring IVN performance through simulation are the main subjects. Recently, there have been studies analyzing the performance of the preemption [14][15][16][17][18].

TSN Simulator Development
In order to develop the integrated IEEE 802.1Q standard simulation, we implemented the main TSN functions in the published standards such as IEEE 802.1AS, Qbv, Qcc, Qca, Qbu, and 802.3br. Section 3 introduces the time-aware scheduler functions of IEEE 802.1Qbv-2015 (which are the main TSN functions of a TSN) and the implementation issues of the frame preemption of IEEE 802.1Qbu-2016 and 802.3br and describes the configuration of each variable operation parameter related to it. The simulator has been developed based on OMNET ++ version 5.0 and inet-3.3.0, and some related studies that have been conducted can be found in References [10,11,14,19].

Time-Aware Scheduler
The time-aware scheduler acts as a timetable for transmitting data at fixed intervals without being influenced by the transmission of AVB or BE (best effort) traffic. To achieve this, it is important to set a cycle for each stream and appropriately place the ST within the cycle. For this purpose, a parameter for specifying a period for each stream and a parameter for allocating a transmission start time of each ST within the period were separately configured. Since this series of operations was based on the assumption that all nodes in the vehicle are synchronized, a periodic synchronization was performed by designating a specific node as a master, which follows the IEEE 802.1AS-rev operation. Each node was designed to have eight queues-five for ST, two for AVB (Class A, B) traffic, and one for BE traffic (see Figure 2).

TSN Simulator Development
In order to develop the integrated IEEE 802.1Q standard simulation, we implemented the main TSN functions in the published standards such as IEEE 802.1AS, Qbv, Qcc, Qca, Qbu, and 802.3br. Section 3 introduces the time-aware scheduler functions of IEEE 802.1Qbv-2015 (which are the main TSN functions of a TSN) and the implementation issues of the frame preemption of IEEE 802.1Qbu-2016 and 802.3br and describes the configuration of each variable operation parameter related to it. The simulator has been developed based on OMNET ++ version 5.0 and inet-3.3.0, and some related studies that have been conducted can be found in References [10,11,14,19].

Time-Aware Scheduler
The time-aware scheduler acts as a timetable for transmitting data at fixed intervals without being influenced by the transmission of AVB or BE (best effort) traffic. To achieve this, it is important to set a cycle for each stream and appropriately place the ST within the cycle. For this purpose, a parameter for specifying a period for each stream and a parameter for allocating a transmission start time of each ST within the period were separately configured. Since this series of operations was based on the assumption that all nodes in the vehicle are synchronized, a periodic synchronization was performed by designating a specific node as a master, which follows the IEEE 802.1AS-rev operation. Each node was designed to have eight queues-five for ST, two for AVB (Class A, B) traffic, and one for BE traffic (see Figure 2).

Frame Preemption
The principles of the frame preemption and development issues in implementation are as follows. In order to start the transmission through the time-aware scheduler, the ST stops transmission of the frame that was being transmitted and splits the frame up at the transmission stop point to transmit the ST first. When the transmission of the ST is completed, the frame preemption functions to transmit the frame that the ongoing transmission interrupted. When the transmission of the ST is completed, the frame preemption successively transmits the interrupted frame and restores the original frame. The key point of the frame preemption is to stop the non-ST frame in transit and to combine the whole of the divided frame. The guard band is the interval between the non-ST frame to be interrupted and the ST frame to be transmitted (see Figure 1). The guard band is processed in units of data size.
In order to apply the frame preemption, frame division and merging processes should be implemented by referring to IEEE 802.3br standards [20]. The preemption process of dividing and merging the frames is performed in Layer 2 because the PHY (Physical) layer cannot recognize the operation of the preemption. Therefore, logical layer processing is required in the MAC (Media Access Control) merge sublayer when going up to Layer 2 (see Figure 3). In Layer 2, MAC is divided into eMAC (expressMAC) and pMAC (preemptableMAC) logically. The eMAC processes the ST frame at high speed, and the pMAC stores the divided frames in the buffer, merges them into a complete frame, and sends it up to the upper layer. The buffer is located in the receiving MAC merge sublayer, and

Frame Preemption
The principles of the frame preemption and development issues in implementation are as follows. In order to start the transmission through the time-aware scheduler, the ST stops transmission of the frame that was being transmitted and splits the frame up at the transmission stop point to transmit the ST first. When the transmission of the ST is completed, the frame preemption functions to transmit the frame that the ongoing transmission interrupted. When the transmission of the ST is completed, the frame preemption successively transmits the interrupted frame and restores the original frame.
The key point of the frame preemption is to stop the non-ST frame in transit and to combine the whole of the divided frame. The guard band is the interval between the non-ST frame to be interrupted and the ST frame to be transmitted (see Figure 1). The guard band is processed in units of data size.
In order to apply the frame preemption, frame division and merging processes should be implemented by referring to IEEE 802.3br standards [20]. The preemption process of dividing and merging the frames is performed in Layer 2 because the PHY (Physical) layer cannot recognize the operation of the preemption. Therefore, logical layer processing is required in the MAC (Media Access Control) merge sublayer when going up to Layer 2 (see Figure 3). In Layer 2, MAC is divided into eMAC (expressMAC) and pMAC (preemptableMAC) logically. The eMAC processes the ST frame at high speed, and the pMAC stores the divided frames in the buffer, merges them into a complete frame, and sends it up to the upper layer. The buffer is located in the receiving MAC merge sublayer, and the fragmented frames are merged in the buffer and sent to the pMAC. If it is not a fragmented frame, it is sent directly to the pMAC without buffer storage.  When transmitting a frame to the pMAC, it is necessary to know whether the frame is a fragmented frame, and how many frames are fragmented. This information, together with the frame preemption, consists of additional formats provided by IEEE 802.1Qbu and IEEE802.1br (see Figure 4). The format includes the beginning, end, and the sequence information identifier of the fragmented frame (see Table 2). The frame is split according to this format, and the fragmented frame is restored to the original frame at the receiving node with reference to the identifier (see Figure 3). As the development progresses, the frame may be divided more than necessary. In order to control this problem, another parameter is configured to limit the maximum number of times that one frame can be divided.

IVN Model Design
An IVN model was designed based on the traffic required for autonomous driving vehicles (see Figure 5). The basic IVN structure and traffic information were provided by a major motor company in Korea, and we redesigned the IVN of each domain based on the traffic information. To illustrate the overall IVN structure, we configured a vehicle to four domains (Infotainment, Body, PT/Chassis, ADAS). When transmitting a frame to the pMAC, it is necessary to know whether the frame is a fragmented frame, and how many frames are fragmented. This information, together with the frame preemption, consists of additional formats provided by IEEE 802.1Qbu and IEEE802.1br (see Figure 4). The format includes the beginning, end, and the sequence information identifier of the fragmented frame (see Table 2). The frame is split according to this format, and the fragmented frame is restored to the original frame at the receiving node with reference to the identifier (see Figure 3). As the development progresses, the frame may be divided more than necessary. In order to control this problem, another parameter is configured to limit the maximum number of times that one frame can be divided. the fragmented frames are merged in the buffer and sent to the pMAC. If it is not a fragmented frame, it is sent directly to the pMAC without buffer storage.  When transmitting a frame to the pMAC, it is necessary to know whether the frame is a fragmented frame, and how many frames are fragmented. This information, together with the frame preemption, consists of additional formats provided by IEEE 802.1Qbu and IEEE802.1br (see Figure 4). The format includes the beginning, end, and the sequence information identifier of the fragmented frame (see Table 2). The frame is split according to this format, and the fragmented frame is restored to the original frame at the receiving node with reference to the identifier (see Figure 3). As the development progresses, the frame may be divided more than necessary. In order to control this problem, another parameter is configured to limit the maximum number of times that one frame can be divided.

IVN Model Design
An IVN model was designed based on the traffic required for autonomous driving vehicles (see Figure 5). The basic IVN structure and traffic information were provided by a major motor company in Korea, and we redesigned the IVN of each domain based on the traffic information. To illustrate the overall IVN structure, we configured a vehicle to four domains (Infotainment, Body, PT/Chassis, ADAS).

IVN Model Design
An IVN model was designed based on the traffic required for autonomous driving vehicles (see Figure 5). The basic IVN structure and traffic information were provided by a major motor To illustrate the overall IVN structure, we configured a vehicle to four domains (Infotainment, Body, PT/Chassis, ADAS). Each domain had ECUs and sensors, and a gateway (GW) for each part of the vehicle. GWs are used to interconnect other domains as necessary. In addition, the ADAS sensor fusion was designed as an ECU for autonomous driving. The ADAS sensor fusion ECU collects the information from the sensors, analyzes the information from adjacent vehicles and the road environment, and extracts information necessary for driving. This information leads to control commands necessary for autonomous driving. The IVN model was configured so that the sensors required for autonomous driving were continuously generating data (see Table 3). The sensors included radio detection and ranging (RADARs) and light detection and ranging (LIDARs). The RADAR was used to determine the distance, direction, and altitude of nearby vehicles and the LIDAR was used to identify the surrounding routes and road conditions. The AVM (around view monitoring) is a vehicle camera information system that can see 360 degrees outside the vehicle in the driver's seat. The DSM (driver status monitoring) is also a camera information system which was mounted inside the vehicle to recognize the pupil and prevent drowsy driving. In addition, ECUs for infotainment of vehicles and ECUs for stream information coming from outside the vehicle for control, safety, etc., were arranged. Each domain had ECUs and sensors, and a gateway (GW) for each part of the vehicle. GWs are used to interconnect other domains as necessary. In addition, the ADAS sensor fusion was designed as an ECU for autonomous driving. The ADAS sensor fusion ECU collects the information from the sensors, analyzes the information from adjacent vehicles and the road environment, and extracts information necessary for driving. This information leads to control commands necessary for autonomous driving. The IVN model was configured so that the sensors required for autonomous driving were continuously generating data (see Table 3). The sensors included radio detection and ranging (RADARs) and light detection and ranging (LIDARs). The RADAR was used to determine the distance, direction, and altitude of nearby vehicles and the LIDAR was used to identify the surrounding routes and road conditions. The AVM (around view monitoring) is a vehicle camera information system that can see 360 degrees outside the vehicle in the driver's seat. The DSM (driver status monitoring) is also a camera information system which was mounted inside the vehicle to recognize the pupil and prevent drowsy driving. In addition, ECUs for infotainment of vehicles and ECUs for stream information coming from outside the vehicle for control, safety, etc., were arranged.

Configuring Parameter Value
Prior to the overall simulation test, it was necessary to measure the change in end-to-end delay according to the preemption guard band size, one of the variable parameters. As described above,

Configuring Parameter Value
Prior to the overall simulation test, it was necessary to measure the change in end-to-end delay according to the preemption guard band size, one of the variable parameters. As described above, using preemption reduces E2E delay and increases network efficiency. The most significant factor in preemption is the size of the guard band that forms the time window between the ST and the non-ST. Depending on the size of the guard band, more non-STs may be sent, so that the segmented traffic is fully integrated and can reach the destination quickly. Therefore, we conducted experiments to see how the delay changed according to the setting of the guard band size when transmitting ST and AVB streams for a simulation time of 5 s. We specified two streams (Stream 1, 2 in Table 5) and measured the preemption occurrence frequency and delay variation at the point where they intersected (see Table 4). The transmission period of the ST stream was set to 10 ms, and the transmission period of the AVB stream was set to 125 µs, which conforms to the transmission requirements of the SR Class A. The minimum guard band size was set to 80 bytes (minimum 64 bytes of frame processing plus additional header information), and the maximum guard band size was set to 512 bytes. Experimental results show that if the guard band becomes too large or small, the frequency of preemption decreases or increases, resulting in poor data transmission efficiency. Taken together, it can be concluded that the optimal guard band size is 128 bytes (see Figure 6). Based on these experimental results, the overall TSN performance test was conducted with the guard band size of 128 bytes.
Sensors 2019, 19, x FOR PEER REVIEW 7 of 11 using preemption reduces E2E delay and increases network efficiency. The most significant factor in preemption is the size of the guard band that forms the time window between the ST and the non-ST. Depending on the size of the guard band, more non-STs may be sent, so that the segmented traffic is fully integrated and can reach the destination quickly. Therefore, we conducted experiments to see how the delay changed according to the setting of the guard band size when transmitting ST and AVB streams for a simulation time of 5 s. We specified two streams (Stream 1, 2 in Table 4) and measured the preemption occurrence frequency and delay variation at the point where they intersected (see Table  5). The transmission period of the ST stream was set to 10 ms, and the transmission period of the AVB stream was set to 125 μs, which conforms to the transmission requirements of the SR Class A. The minimum guard band size was set to 80 bytes (minimum 64 bytes of frame processing plus additional header information), and the maximum guard band size was set to 512 bytes.
Experimental results show that if the guard band becomes too large or small, the frequency of preemption decreases or increases, resulting in poor data transmission efficiency. Taken together, it can be concluded that the optimal guard band size is 128 bytes (see Figure 6). Based on these experimental results, the overall TSN performance test was conducted with the guard band size of 128 bytes.

Performance Test on TSN Integrated Environment
For the TSN performance experiment, the stream of each ECU and sensor was allocated after the design of the IVN model. It was divided into a total of 16 streams, and periodic data transmission was performed by specifying the source to the destination according to the ST and AVB transmission formats defined in the TSN standard (see Table 3). Depending on the IVN domain, links exceeding 100 Mbps were replaced by 1 Gbps links. This is because relatively large video and voice data are mixed in the domain of ADAS and Infotainment. The size of the guard band was set to 128 bytes, which was derived as the optimal value.

Performance Test on TSN Integrated Environment
For the TSN performance experiment, the stream of each ECU and sensor was allocated after the design of the IVN model. It was divided into a total of 16 streams, and periodic data transmission was performed by specifying the source to the destination according to the ST and AVB transmission formats defined in the TSN standard (see Table 3). Depending on the IVN domain, links exceeding 100 Mbps were replaced by 1 Gbps links. This is because relatively large video and voice data are mixed in the domain of ADAS and Infotainment. The size of the guard band was set to 128 bytes, which was derived as the optimal value.
Experimental results show that applying the TSN preemption in combination with ST transmission was more efficient in terms of the E2E delay than using AVB only. It was shown that the delay was reduced in most cases except for streams 5 and 12. Concerning the difference of E2E delay in Table 5, the delay was not reduced due to the fact that the preemption occurred more frequently than necessary under too much traffic by chance. Based on this result, it can be inferred that the proper spacing of the ST, placement of the IVN link, and setting of the guard band size in the preemption are important for IVN design for autonomous driving. As a result of comparing the E2E delays between an AVB and TSNs through experiment, it was confirmed that TSNs satisfy the ST transmission requirements and the frame preemption required to compensate for the delay time caused by AVB stream transmission interruptions (see Table 5).
Through this experiment, it was found that the results can vary greatly depending on how the traffic is arranged and the parameter values are configured in the environment where the functions of TSN standards are integrated. In the future, it may be necessary to modify some of the requirements or recommended parameters of existing standards. This is because the performance of TSNs may not be as desirable when various standards, such as the queuing policies and the link speed configurations of IEEE 802.3 with speeds of 10, 100 Mbps, or greater than 1 Gbps, are integrated into newly revised 802.1Q. We will proceed with further implementation and experimentation to address these issues.

Conclusions
In this paper, a simulator was developed by integrating the main TSN functions under development. Based on the ST for streaming and control data from various sensors provided by a major motor company in Korea, we constructed a TSN in a vehicle for autonomous driving. When testing various standard functions in the integrated environment, it was found that the TSN time-division transmission method was required to satisfy the requirements and that the preemption was required to compensate for the AVB delay. Also, the optimal size of the guard band was found to be 128 bytes for autonomous vehicles through analysis. We anticipate that various future standards for TSNs will be published and that when these standards are applied to an integrated environment, the requirements presented in the existing standards will need to be reconsidered.
In the future, we plan to integrate key features of the upcoming standards such as IEEE 802.1Qci, 802.1Qch, 802.3cg, 802.3ch, and so forth into the simulator developed. This next research topic would include additional performance tests by collecting vehicle traffic data from vehicle original equipment manufacturers (OEMs).