Automatic Gate Schedule Configuration in TSN

[Jiacheng188]

Hello,
I was watching the showcase Automatic Gate Schedule Configuration at showcases/tsn/gatescheduling/sat/omnetpp.ini .
But when I set all kinds of traffic to one single priority so that they should be transmitted in the same queue and controlled by the same gate,I find that the automatic gate scheduler set all other gates close all the time except for the gate transmitting the traffic mentioned above. But if I want to send some best effort traffic in other queues when the gate transmitting the time-sensitive traffic is closing, what can I do? Futher more, is there an opportunity to combine time-aware shaping and credit-based shaping?
Here is my omnetpp.ini file:

[General]
network = inet.networks.tsn.TsnDumbbellNetwork
description = "Z3 SAT based gate scheduling"
record-eventlog = true

*.switch1.typename = "TsnSwitch1"
*.switch2.typename = "TsnSwitch2"

# client applications
*.client*.numApps = 2
*.client*.app[*].typename = "UdpSourceApp"
*.client*.app[0].display-name = "best effort"
*.client*.app[1].display-name = "video"
*.client*.app[0].io.destAddress = "server1"
*.client*.app[1].io.destAddress = "server2"
*.client*.app[0].io.destPort = 1000
*.client*.app[1].io.destPort = 1001
*.client*.app[*].source.packetNameFormat = "%M-%m-%c"
*.client*.app[0].source.packetLength = 1000B
*.client*.app[1].source.packetLength = 500B
*.client*.app[0].source.productionInterval = 500us # ~16Mbps
*.client*.app[1].source.productionInterval = 250us # ~16Mbps

# server applications
*.server*.numApps = 2
*.server*.app[*].typename = "UdpSinkApp"
*.server*.app[0].display-name = "best effort"
*.server*.app[1].display-name = "video"
*.server*.app[0].io.localPort = 1000
*.server*.app[1].io.localPort = 1001

# enable outgoing streams
*.client*.hasOutgoingStreams = true

# client stream identification
*.client*.bridging.streamIdentifier.identifier.mapping = [{stream: "best effort", packetFilter: expr(udp.destPort == 1000)},
                                                          {stream: "video", packetFilter: expr(udp.destPort == 1001)}]

# client stream encoding
*.client*.bridging.streamCoder.encoder.mapping = [{stream: "best effort", pcp: 0},
                                                  {stream: "video", pcp: 0}]

# enable streams
*.switch*.hasIncomingStreams = true
*.switch*.hasOutgoingStreams = true

*.switch*.bridging.streamCoder.decoder.mapping = [{pcp: 0, stream: "best effort"},
                                                  {pcp: 0, stream: "video"}]

*.switch*.bridging.streamCoder.encoder.mapping = [{stream: "best effort", pcp: 0},
                                                  {stream: "video", pcp: 0}]

# enable incoming streams
*.server*.hasIncomingStreams = true

# enable egress traffic shaping
*.switch*.hasEgressTrafficShaping = true

# time-aware traffic shaping with 2 queues
*.switch*.eth[*].macLayer.queue.numTrafficClasses = 2
*.switch*.eth[*].macLayer.queue.queue[0].display-name = "best effort"
*.switch*.eth[*].macLayer.queue.queue[1].display-name = "video"

# automatic gate scheduling
*.gateScheduleConfigurator.typename = "Z3GateScheduleConfigurator"
*.gateScheduleConfigurator.gateCycleDuration = 1ms
# 58B = 8B (UDP) + 20B (IP) + 4B (802.1 Q-TAG) + 14B (ETH MAC) + 4B (ETH FCS) + 8B (ETH PHY)
*.gateScheduleConfigurator.configuration =
   [{pcp: 0, gateIndex: 0, application: "app[0]", source: "client1", destination: "server1", packetLength: 1000B + 58B, packetInterval: 500us, maxLatency: 500us},
    {pcp: 0, gateIndex: 0, application: "app[1]", source: "client1", destination: "server2", packetLength: 500B + 58B, packetInterval: 250us, maxLatency: 500us},
    {pcp: 0, gateIndex: 0, application: "app[0]", source: "client2", destination: "server1", packetLength: 1000B + 58B, packetInterval: 500us, maxLatency: 500us},
    {pcp: 0, gateIndex: 0, application: "app[1]", source: "client2", destination: "server2", packetLength: 500B + 58B, packetInterval: 250us, maxLatency: 500us}]


# gate scheduling visualization
*.visualizer.gateScheduleVisualizer.displayGateSchedules = true
*.visualizer.gateScheduleVisualizer.displayDuration = 100us
*.visualizer.gateScheduleVisualizer.gateFilter = "*.switch1.eth[2].** or *.switch2.eth[0].**.transmissionGate[0] or *.switch2.eth[1].**.transmissionGate[1]"
*.visualizer.gateScheduleVisualizer.height = 16

The scheduled information is shown here:

Gate[1] doesn't give opportunity to other traffic to go through.

[adamgeorge309]

To answer one of your questions about combining credit-based and time-aware shaping, this might be useful:

https://inet.omnetpp.org/docs/showcases/tsn/trafficshaping/mixingshapers/doc/index.html

The showcase is work-in-progress, but the configuration is complete.

[Jiacheng188]

To answer one of your questions about combining credit-based and time-aware shaping, this might be useful:

https://inet.omnetpp.org/docs/showcases/tsn/trafficshaping/mixingshapers/doc/index.html

The showcase is work-in-progress, but the configuration is complete.

Thank you for your reply. I have seen the showcase which combined the credit-based and asynchronous shaping.
I think I'm able to combine cbs and tas now. But In my simulation, I don't want the best effort traffic to be length-fixed or interval-fixed so I won't provide the information of the best effort traffic to the configurator (as it's required to provide the packetLength and packetInterval parameters).
Now the configurator closes all other gates which makes me confused. : (

[levy]

I think we could add a gate filter parameter to all gate schedule configurators to limit the scope of the auto-configuration. This wouldn't be difficult to do and I think it would solve your problem. Do you agree?

[Jiacheng188]

@levy
Thank you for your reply.
Do you mean that some of the gates can be configured automatically leaving other gates open all the time?
I think the solution should be like this:
Except for guard bands where all the gates are closed,
when the gate for TT is open, all other gates should be closed.When the gate for TT is closed, the all other gates should be open.
But if we go further, the problem is how we integrate CBS and TAS which TSN standard doesn't declare.
For example, assuming we have only one gate for Time-Triggered traffic(TT), and two for Audio-Video Bridge(one for AVB_H, one for AVB_L, and the former has higher priority than the latter)，and the others for Best-effort Traffic(BE) .When the gate for TT is closed, all other gates can be open or we can open the gate for AVB_H for a few time and open the gate for AVB_L for fewer time while remaining time is reserved for BE.
All the papers i have read so far assume the case that when the gate for TT is closed, all other gates should be open.
So this solution will be useful for academic research and for my simulation.
While the way to combine TAS and CBS can be really different, providing the most common configuration is enough.But if user want to test different methods, they can create new configurators or they are able to simulate different methods by providing their own GCLS just as #771 .

[levy]

I suggested something fairly simple: some gates are automatically configured and some gates are manually configured. So you could leave the best effort traffic gates open all the time, assuming that they cannot prevent any other time sensitive traffic to go through within the specified limits. Unfortunately this may not be a good solution because you need guard intervals before time sensitive traffic?

Currently the gate schedule configurators barely know anything about specific traffic categories. All they know is that there is an order of traffic categories and that the specified traffic should go through from source to destination within the specified limits. They assume all gates are closed by default, unless a gate needs to be open in order to achieve the desired result.

Another approach would be that they assume that all gates are open by default, unless a gate that is open by default would prevent another traffic category to go through within the specified limits, including guard intervals to prevent delaying higher priority traffic. Is this what you are suggesting? It's certainly doable but it doesn't seem trivial to me.

[Jiacheng188]

@levy
Hum...
Maybe my suggesting is that:
I can provide some time sensitive traffic information for the configurators :packetLength ,packetInterval, maxLatency,gateIndex,etc.
Then the configurators configure the gates(the gates provided in the gateIndex parameter) the traffic passing through. Then the configurators configure the reamining gates such that when there is no TT trafic trassmitting other gates can be open.
So the transmitting time for remaining gates is the complementary set of the time when the TT traffic is transmitting.
If I can set guard interval length, such as 50us , just add the time in front of each time window transmitting the TT trafic. Then do the same thing as mentioned above to configure remaining gates.
In short, instead of assuming all gates are closed by default or assuming all gates are open by default, the configurators assume that when there is no TT traffic need to be transmitted in some gates other gates of low priority should have a chance to be transmitted.
It seems that my suggesting is quite different from the real implementation and the implementation doesn't consider guard intervals.

[levy]

IIRC the current implementation doesn't consider guard intervals because it assumes a number of things about the whole network and the traffic to greatly simplify the gate scheduling problem:

• all traffic is known by the configurator (it's not the case in your simulation)
• all clocks are either perfectly synchronized, or the time difference is negligible and it is already included in the packet length parameters (this isn't well understood)
• all traffic arrive in time (with negligible differences if time synchronization is used) as calculated by the configurator
• traffic passes through a gate only if the gate is open for the whole duration of the packet transmission according to the schedule

Ok, here's how I understand your suggestion now: So, all gates can be configured to be open in a second pass after the current automatic configuration, unless there's a higher priority gate open within guard interval in the gate schedule. Opening a lower priority gate at the wrong time could effectively prevent the original automatic configuration to work as intended. Do I understand it right?

I think there is a problem though: there cannot be known (by the configurator) TT traffic and unknown non-TT traffic in the same traffic category at the same gate/queue/network interface, because then any schedule the configurator comes up with can be broken by the unknown non-TT traffic.

So, it's more like the configurator needs to know more than it currently does. It cannot simply assume that there's non-TT traffic in all categories because then calculating a schedule is impossible. So for example, you could say that the best effort traffic category only contains non-TT traffic in the whole network, in which case your logic above applies to the gates of that traffic category.

What do you think?

[Jiacheng188]

@levy
Yes, You have understood my meaning.
In most of the research papers i have read, the switch of TSN looks like this:

There are 8(default) queues and 8 gates(controlled by TAS). The queue Q7 of the highest priority is prepared for TT traffic(though we could assign more than more one, let's assume there is only one here), so all other gates or queues are prepared for non-TT traffic(though their priority can be different).
TAS or GCLs control the gates. When there is no TT traffic is transmitting or about to transmitting(guard intervals), other gates can be open.

[levy]

Ok, I see. So here is how this could be implemented.

The automatic gate schedule configurators should be extended with a second stage. The second stage should configure all non-TT gates (which don't have any TT traffic assigned to them). These non-TT gates can be open when the higher priority TT gates are closed, also taking into consideration the guard intervals.

Unfortunately, I don't know when we will have time to make this happen.

[Jiacheng188]

@levy
Thank you for taking it into consideration.And I'm looking forward to that day because it will make the configuration more easier for TSN simulation.
Maybe I can refer to the PR #776 to to read my own GCLs generated offline or just modify the source code to make this happen for me as a band-aid solution (though i'm a newbie in OMNET++ and INET currently).
It's a nice experience to communicate with you and I have understood how the configurators behave.
: )