Development of an Ethernet-Based Heuristic Time-Sensitive Networking Scheduling Algorithm for Real-Time In-Vehicle Data Transmission

Round 1

Reviewer 1 Report

In the network depicted in figure 1, all of the RC and BE queues are opened at once.  The article doesn’t explain sufficiently how traffic contention is handled between these queues.  Is contention handled with collision detection and a standard Ethernet back off scheme or is some other algorithm used?

The paragraph on lines 143-158 mentions the 15000 guard band for scheduled traffic and the bandwidth reduction due to this guard band twice.  This seems repetitive and perhaps this paragraph should be revised so that these facts are only mentioned once.

On line 206 and 207, dealy should be delay.

The text from line 193-216 discusses the content of figure 3, including variables.  The variables in the diagram use subscripts, but the text does not.  The typesetting needs to be fixed to make this consistent.  This inconsistent typesetting continues in the rest of the paper.

I think there should be some additional discussion of the conditions that lead to a violation of your scheduleability assumption.  If those conditions dominate real world situations, then the applications of your scheduling algorithm are very small, but there is no discussion of the conditions for the reader to determine if the algorithm presented is useful for any given application.

Author Response

Point 1: In the network depicted in figure 1, all of the RC and BE queues are opened at once.  The article doesn’t explain sufficiently how traffic contention is handled between these queues. 

 Response 1: This explanation was intentionally omitted because our focus was on ST. In the TSN network, RC uses the credit-based shaper (CBS) algorithm while BE traffic uses the strict priority algorithm to avoid collisions. CBS determines the transmission of traffic based on the credit value of the RC class. If the credit value is positive, transmission can begin and continue to finish the last bit. This credit value is changing continuously, i.e., it increases while any message is waiting in the queue and decreases while a message is being transmitted. BE traffic is allowed only when no other class is being transmitted. These algorithms are handled by several shapers in Figure 2 within a node.

Point 2: Is contention handled with collision detection and a standard Ethernet back off scheme or is some other algorithm used?

Response 2: If messages from multiple nodes are competing for transmission chance, there might be collisions that can be handled by conventional Ethernet protocol. However, chance of collision is almost negligible due to the use of Ethernet switches.

Point 3: The paragraph on lines 143-158 mentions the 15000 guard band for scheduled traffic and the bandwidth reduction due to this guard band twice.  This seems repetitive and perhaps this paragraph should be revised so that these facts are only mentioned once.

Response 3: To reflect your comments on the point 2, I have corrected the 1st paragraph of the 2.3 section.

Point 4: On line 206 and 207, dealy should be delay.

Response 4: This part has been modified in the paper.

Point 5: The text from line 193-216 discusses the content of figure 3, including variables.  The variables in the diagram use subscripts, but the text does not.  The typesetting needs to be fixed to make this consistent.  This inconsistent typesetting continues in the rest of the paper.

Response 5: To reflect your comments on the point 4, I have corrected the 2nd paragraph of the 3.1section.

Point 6: I think there should be some additional discussion of the conditions that lead to a violation of your scheduleability assumption.  If those conditions dominate real world situations, then the applications of your scheduling algorithm are very small, but there is no discussion of the conditions for the reader to determine if the algorithm presented is useful for any given application.

Response 6: I think that there may be cases for which the proposed algorithm cannot come up with a schedule. The motivation of this research is to provide automotive electronics engineers with a straightforward procedure to obtain an acceptable schedule for in-vehicle network that handles light-medium traffic as most vehicle networks are designed. I think the proposed algorithm can be applicable for most cases that automotive engineers are asked to tackle. I have added a sentence to describe the motivation of this research in the paragraph second to the last in Section 1.

Thank you very much for your valuable comments.

Author Response File: Author Response.pdf

Reviewer 2 Report

The paper proposes a time-sensitive network scheduling algorithm for TSN-scheduled traffic. The method couples STs to routing links. It is claimed that the method reduces the end-to-end delay of the whole system.

The paper does not compare with state-of-the-art methods that fit the same category, such as [1]. This reviewer is having a hard time quantifying the goodness of the heuristic. Also, why couldn't we cast the problem involving gate control list for data transmission as an MIP ?

Concerning your simulations, you plot bar diagrams comparing "strict-only" with your method. Is there any other way of expressing this ? 

The paper contains spelling/grammatical mistakes, such as:
- Title of Section 2.1 contains a spelling mistake (Traffic instead of Traffinc) 
- "For each STi, how many times STi should be transmitted during the entire cycle Tall, which is denoted by N_STi" Are you asking a question ? Or are you making a statement ? 
- "dealy" should be "delay" in p.5 line 206.

[1] Joung, J. (2019). Regulating scheduler (RSC): a novel solution for IEEE 802.1 time sensitive network (TSN). Electronics, 8(2), 189.

Author Response

Point 1: The paper does not compare with state-of-the-art methods that fit the same category, such as [1]. This reviewer is having a hard time quantifying the goodness of the heuristic. Also, why couldn't we cast the problem involving gate control list for data transmission as an MIP ?


[1] Joung, J. (2019). Regulating scheduler (RSC): a novel solution for IEEE 802.1 time sensitive network (TSN). Electronics, 8(2), 189.

Response 1: I totally agree with the reviewer in the sense that the proposed algorithm is not at all state-of-the-art. The motivation of this research is to provide automotive electronics engineers with a straightforward procedure to obtain an acceptable schedule for an in-vehicle network. To introduce state-of-the-art research to readers, [1] is included in the references. In addition, I have added a sentence to describe the motivation of this research in the paragraph second to the last in Section 1.

Point 2: Concerning your simulations, you plot bar diagrams comparing "strict-only" with your method. Is there any other way of expressing this?

Response 2: To reflect your comments on the point 2, I have corrected “strict only” to “priority only” in the plot bar diagrams (figure 8). The “priority only” is a transmission method considering priority without schedule.

Point 3: The paper contains spelling/grammatical mistakes, such as:

- Title of Section 2.1 contains a spelling mistake (Traffic instead of Traffinc)

- "For each STi, how many times STi should be transmitted during the entire cycle Tall, which is denoted by N_STi" Are you asking a question ? Or are you making a statement ?

- "dealy" should be "delay" in p.5 line 206.

Response 3: This part has been modified in the paper.

Thank you very much for your valuable comments.

Author Response File: Author Response.pdf

Reviewer 3 Report

A TSN scheduling algorithm is proposed and demonstrated in several examples. The article is easy to follow. Specific comments:

-The proposed scheduling algorithm seems to be pretty straightforward. What is the main advantage compared to other algorithms in literature?

-In the examples, the data sizes of different STs are always multiple to each other, so as the required transmit time. What if they are not?

-In the proposed solution of end-to-end delays, such as in Figure 5, for ST6, if the message is already generated by ES3 at t0, then the change from Figure 5a) to Figure 5b) will not really change the actual delay, since ES6 will always get the message at t0+60us. Unless ES3 now generate a message at t0+10us, but then message from different end systems are generated asynchronously, then it seems to be a different problem than what the algorithm in Figure 3.

-Some typos: 1) page 5 line 195, the authors said that "ST’s index i is given such that i-th ST has higher or equal priority than (i+1)st ST", this does not appear to be the case in the following examples. 2) Table 2, "CCASE 3" => "CASE 3". 3) page 5 line 206, "reduce end-to-end dealy" => "reduce end-to-end delay"

Author Response

Point 1: 
 The proposed scheduling algorithm seems to be pretty straightforward. What is the main advantage compared to other algorithms in literature?

Response 1: I agree that the algorithm is straightforward. In fact, the motivation of this research is to provide automotive electronics engineers with a straightforward procedure to obtain an acceptable schedule for in-vehicle network without too much complexity. I have added a sentence to describe the motivation of this research in the paragraph second to the last in Section 1.

Point 2: In the examples, the data sizes of different STs are always multiple to each other, so as the required transmit time. What if they are not?

Response 2: There will be no difference in applying the algorithm. The reason for using multiple to each other is just to simplify the diagrams for easier understanding.

Point 3: In the proposed solution of end-to-end delays, such as in Figure 5, for ST6, if the message is already generated by ES3 at t0, then the change from Figure 5a) to Figure 5b) will not really change the actual delay, since ES6 will always get the message at t0+60us. Unless ES3 now generate a message at t0+10us, but then message from different end systems are generated asynchronously, then it seems to be a different problem than what the algorithm in Figure 3.

Response 3: This is actually changing the time of message generation at ES3 by 10us. We start with the assumption that all the messages can be generated at t0. But, a message can be generated later than t0 if it is not needed or scheduled to be transmitted at t0. In Figure 5, ST2 can be generated at t0+10us because its transmission is scheduled at that time. By shifting ST5 on [ES3, SW2] and [SW2, SW1], we can generate ST5 at t0+30 and reduce E2E delay.

Point 4: Some typos: 1) page 5 line 195, the authors said that "ST’s index i is given such that i-th ST has higher or equal priority than (i+1)st ST", this does not appear to be the case in the following examples. 2) Table 2, "CCASE 3" => "CASE 3". 3) page 5 line 206, "reduce end-to-end dealy" => "reduce end-to-end delay"

Response 4: This part has been modified in the paper.

Thank you very much for your valuable comments.

Author Response File: Author Response.pdf