Decentralized Dynamic Scheduling of TCPS Flows and a Simulator for Time-sensitive Networking

We use Python and Simpy [32] to create PYTSN, a discrete event network simulator for TSN. PYTSN supports simulation models for the most-common TSN network components such as (i) TSN switch with support for TAS and eDDSCH-TSN, (ii) ST and BE terminals, and (iii) network link. The simulation models expose several configure options for users to modify and simulate different network scenarios. In this section, we describe the high-level architecture of PYTSN’s switch component. For the architecture and the Simpy design of all other supported components in PYTSN, refer to Reference [21] and PYTSN’s source code in Section 6.

Figure 22 shows the architecture of the TSN switch that supports eDDSCH-TSN. The design supports four ports: Port-A (P\(_A\)), Port-B (P\(_B\)), Port-C (P\(_C\)), and Port-D (P\(_D\)). Ports are built for general purpose usage and can be configured to support ST traffic. Only ports configured to support ST traffic can directly connect to an ST-Terminal and send data and beacons of eDDSCH-TSN. Each port consists of a packet receiving block (Rx) and a packet transmitting block (Tx).

If Rx receives a data packet, then it is sent to the Switch Fabric (SF). SF routes these packets from one port to another. To decide which port to route the packet, SF looks up the switch forwarding table using the incoming packet’s destination-ID. In the current version of the TSN switch, the forwarding table entries are preset during component initialization. If Rx receives a control packet, i.e., registration request and response of eDDSCH-TSN, then it forwards the packet to the Port Control Logic (PCL) for further action.

Figure 23 shows the architecture of Tx. SF uses it to transmit data packets and PCL uses it to transmit control packets. Tx consists of a packet demultiplexer (dmux), six gated TAS queues, and a priority transmitter. The current version of Tx has four queues (\(q_1\) to \(q_4\)) to support ST flows, one queue (\(q_{be}\)) to support BE flows, and one network management queue (\(q_{nm}\)), to support registration request/response packets and beacon packets. The block dmux uses the flow-id and the port through which it has received an incoming packet to route it to the associated queue. Every ST terminal embeds a unique flow-id (\(\gt \!0\)) in the packets it sends. All BE terminals embed a flow-id of \(-1\) in their packets. Control packets such as the registration, deregistration, and beacons use a flow-id of 0. If the received packets’ flow-id is \(-1\), then dmux routes the packets to \(q_{be}\). If it is 0, then the packets are routed to \(q_{nm}\). The block dmux uses the metadata field, prt-rcv, in the packets for routing ST packets having flow-id \(\gt \!0\) to queues. When Rx receives a packet, it creates a metadata field, prt-rcv, to identify the receiving port. The block dmux routes an ST packet it receives to \(q_1\), \(q_2\), \(q_3\), or \(q_4\), if prt-rcv of the packet corresponds to P\(_A\), P\(_B\), P\(_C\), or P\(_D\), respectively. Packets in the queue are transmitted when the gate of that queue is opened. Tx receives these gate control events from PCL through \(in\_gc\). The priority transmitter reads packets from the open queues and prioritizes their transmission using the packet’s priority field if more than one queue is open at the same time.

Although Tx in Figure 23 appears to have a simple architecture, building its discrete event simulation model is non-trivial. First, we need to ensure that data is transferred from queues to the Simpy store resources (\(i_i\): \(i_{nm}\), \(i_{be}\), \(i_1,\ldots i_4\)) at the priority transmitter.s input when there is no pending data waiting for transmission. In our work, we use an interrupt mechanism; each time after transmitting data, the priority transmitter will generate an event noted by the Simpy process (transfer-process) that transfers data from the queue to the priority transmitter’s input-side store resources. A similar problem exists when the priority transmitter tries to read data from its input-side Simpy store resources, but no packets are available. Here, too, we implement an interrupt mechanism. Whenever packets are transferred to the Simpy store resources (\(i_i\): \(i_{nm}\), \(i_{be}\), \(i_1,\ldots i_4\)) or when there is a change in the gate control, an event is generated, which the packet transmitter waits to read packets.

The PCL’s residing in the switch ports (see Figure 22) generates gate control events to open and close gates of queues in Tx. For generating these gate control events, it uses the GCL it receives from the Switch Control Logic (SCL) at the start of every CT. Further, PCL is responsible for (i) transferring registration requests/responses received by Rx to SCL, (ii) transmitting the registration messages received from SCL to other switches in the network via Tx, and (iii) generating and transmitting both configuration and data beacon to the connected ST terminal. PCL infers the timings to generate and send the beacons from the GCL it receives from SCL.

SCL (see Figure 22) controls and coordinates the functioning of eDDSCH-TSN. It continuously updates GCL of the ports from the registration response messages it receives. It sends these updated GCL to the switch ports’ PCL blocks at the start of every CT. During the registration phase of TCPS terminals, SCL is also responsible for forwarding the registration requests and responses it receives to other connected switches in the network.