CN108737003B - Methods, systems, and computer readable media for testing Time Sensitive Network (TSN) elements - Google Patents

Abstract

Methods, systems, and computer readable media for testing Time Sensitive Network (TSN) elements are disclosed. According to one method for testing TSN elements, the method is performed at a test system. The method includes synchronizing a test system clock with a clock at a System Under Test (SUT). The method also includes receiving a sequence of messages, wherein the sequence of messages is generated using a scheduling rule associated with the TSN stream. The method further includes using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

Description

Methods, systems, and computer readable media for testing Time Sensitive Network (TSN) elements

Priority requirement

This application claims the benefit of romania patent application No. a 002462017 filed on 25/4/2017, the disclosure of which is fully incorporated herein by reference.

Technical Field

The subject matter described herein relates to testing network elements. More particularly, the subject matter relates to methods, systems, and computer-readable media for testing Time Sensitive Network (TSN) elements.

Background

A time sensitive network may be generally defined as a network that may communicate at least some time sensitive data. Thus, a time sensitive network must be able to transmit time sensitive data within an acceptable amount of time. While many of today's communication networks follow best-effort approaches (e.g., networks based on various ethernet and Internet Protocols (IP)), best-effort approaches are generally not suitable for time-sensitive applications because even minor delays in the transmission and/or delivery of time-sensitive content (e.g., data between components in a vehicle control network) are not acceptable for such applications.

Various TSN-related technologies and standards have emerged to overcome the shortcomings of communication networks using best effort approaches. For example, the IEEE 802.1 Time-Sensitive Networking Task Group (Time-Sensitive Networking Task Group) is currently specifying a set of protocols for TSNs. These protocols may provide, require, or facilitate actions for limiting and/or controlling communication-related delays in TSNs. Example behaviors of a TSN may include precise synchronization between all TSN elements (e.g., devices), traffic shaping or scheduling of time-sensitive streams, reservation or "admission control" for reserving or pre-allocating bandwidth and frequency for transmission or reception of time-sensitive streams, and/or identification of non-participating (e.g., "non-TSN") elements within the TSN.

Problems arise when attempting to test resources within a TSN. For example, challenges exist in testing whether TSN elements and/or related components are implementing proper functionality and/or are accurately implementing standards and/or protocols. Currently, there is no effective system and/or method available for testing TSN elements.

Disclosure of Invention

Methods, systems, and computer readable media for testing Time Sensitive Network (TSN) elements are disclosed. According to one method for testing TSN elements, the method is performed at a test system. The method includes synchronizing a test system clock with a clock at a System Under Test (SUT). The method also includes receiving a sequence of messages, wherein the sequence of messages is generated using a scheduling rule associated with the TSN stream. The method further includes using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

According to one system for testing TSN elements, the test system includes at least one processor. The test system is configured for: synchronizing a test system clock with a clock at the SUT; receiving a sequence of test messages, wherein the sequence of messages is generated using a scheduling rule associated with the TSN stream; and using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

The subject matter described herein may be implemented in a combination of software and hardware and/or firmware. For example, the subject matter described herein may be implemented in software executed by a processor (e.g., a hardware-based processor). In one example implementation, the subject matter described herein may be implemented using a non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor of a computer, control the computer to perform steps. Example computer readable media suitable for implementing the subject matter described herein include non-transitory devices such as disk memory devices, chip memory devices, programmable logic devices such as field programmable gate arrays, and application specific integrated circuits. Furthermore, a computer-readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

As used herein, the term "node" refers to at least one physical computing platform that includes one or more processors and memory.

As used herein, the term "function" or "module" refers to a combination of software and hardware and/or firmware for implementing the features described herein. In some embodiments, a module may include a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or a processor.

The invention comprises the following steps:

1. a method for testing a Time Sensitive Network (TSN) element, the method comprising:

at the test system:

synchronizing a test system clock with a clock at a System Under Test (SUT);

receiving a sequence of packets, wherein the sequence of packets is generated using a scheduling rule associated with a TSN stream; and

using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

2. The method of item 1, wherein the sequence of messages is sent by the SUT, the test system, or a speaker device separate from the SUT and the test system.

3. The method of item 1, comprising:

before receiving the message sequence:

generating a test message sequence by using the scheduling rule; and

and transmitting the test message sequence to the SUT.

4. The method of item 3, wherein sending the sequence of test messages to the SUT includes sending at least one corrupted test message, wherein the at least one corrupted test message has a different message size than expected, fuzzy data, is sent in a different order than expected, or is sent outside an acceptable time period based on the scheduling rules.

5. The method of item 3, wherein transmitting the sequence of test messages to the SUT comprises:

scheduling the transmission of each message in the test message sequence; or

Scheduling transmission of a first packet in the sequence of test packets and transmitting subsequent test packets using flow delay information and packet rate.

6. The method of item 3, comprising:

at the test system and prior to generating the sequence of test messages:

determining a TSN schedule for a TSN flow associated with testing of the SUT.

7. The method of item 3, comprising:

at the test system:

providing the SUT with scheduling rules associated with the TSN stream.

8. The method of item 1, wherein determining whether the scheduling rule is accurately implemented by the SUT comprises using latency and packet information arrival time measurements based on packet timestamps and scheduling information about TSN streams.

9. The method of clause 1, wherein the test system clock is configured to be used as a master clock or a slave clock for synchronizing the test system clock with a clock at the SUT.

10. The method of item 1, wherein the test system is configured for testing one or more functions run by the SUT (from) or one or more TSN standards or protocols implemented by the SUT.

11. A system for testing Time Sensitive Network (TSN) elements, the test system comprising:

at least one processor;

wherein the test system is configured for:

synchronizing a test system clock with a clock at a System Under Test (SUT);

receiving a sequence of packets, wherein the sequence of packets is generated using a scheduling rule associated with a TSN stream; and

using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

12. The system of item 11, wherein the sequence of messages is sent by the SUT, the test system, or a speaker device separate from the SUT and the test system.

13. The system of item 11, wherein the testing system is configured to:

before receiving the message sequence:

generating a test message sequence by using the scheduling rule; and

and transmitting the test message sequence to the SUT.

14. The system of item 13, wherein the test system is configured to transmit at least one corrupted test message having a different message size than expected, fuzzy data, transmitted in a different order than expected, or transmitted outside of an acceptable time period based on the scheduling rules.

15. The system of item 13, wherein the testing system is configured to:

scheduling the transmission of each message in the test message sequence; or

Scheduling transmission of a first packet in the sequence of test packets and transmitting subsequent test packets using flow delay information and packet rate.

16. The system of item 13, wherein the testing system is configured to:

before generating the test message sequence:

determining a TSN schedule associated with the TSN stream associated with testing of the SUT.

17. The system of item 13, wherein the test system is configured to provide the SUT with scheduling rules associated with the TSN stream.

18. The system of item 11, wherein the test system is configured to determine whether the scheduling rule is accurately implemented by the SUT by using latency and packet information arrival time measurements based on packet timestamps and scheduling information about TSN streams.

19. The system of item 11, wherein the test system clock is configured to function as a master clock or a slave clock for synchronizing the test system clock with a clock at the SUT.

20. The system of item 11, wherein the testing system is configured to test one or more functions run by the SUT or one or more TSN standards or protocols implemented by the SUT.

21. A non-transitory computer-readable medium comprising computer-executable instructions embodied in the non-transitory computer-readable medium, which, when executed by at least one processor of a computer, cause the computer to perform steps comprising:

at the test system:

synchronizing a test system clock with a clock at a System Under Test (SUT);

receiving a sequence of packets, wherein the sequence of packets is generated using a scheduling rule associated with a TSN stream; and

using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

Drawings

The subject matter described herein will now be described with reference to the accompanying drawings, in which:

FIG. 1 is a diagram illustrating an example test environment for testing TSN elements;

FIG. 2 is a diagram illustrating an example test system that uses an internal master clock for time synchronization;

FIG. 3 is a diagram illustrating an example test system that uses an external master clock for time synchronization;

FIG. 4 is a diagram illustrating an example test system that uses a damage module to damage transmitted test messages;

FIG. 5 is a diagram showing an example test system and a separate speaker (talker) device;

FIG. 6 is a diagram illustrating an example test system using a network splitter to run tests;

FIG. 7 is a diagram showing scheduler errors after testing TSN elements;

FIG. 8 is a graph showing a latency histogram reporting the results after testing TSN elements;

FIG. 9 is a message diagram illustrating a messaging strategy for testing TSN elements; and

FIG. 10 is a block diagram illustrating an example process for testing TSN elements.

Detailed Description

The subject matter described herein relates to methods, systems, and computer-readable media for testing Time Sensitive Network (TSN) elements. The TSN may include various TSN nodes or elements (e.g., repeaters and end stations) having clocks with synchronized times. For example, the TSN and/or nodes therein may use various time synchronization mechanisms, such as a time synchronization protocol, e.g., a protocol based on IEEE gPTP or IEEE PTP. The transmitting TSN elements (e.g., repeaters and speakers) may know when they are scheduled for transmission. For example, each transmit TSN element may use a Time Aware Shaper (TAS) and/or one or more TSN schedules (e.g., a gate access list and/or a streaming schedule) for one or more TSN streams. In this example, the gate access list may indicate when a gate or transmission window (e.g., one or more switch ports) is opened or closed for a particular traffic (e.g., one or more flows) to be transmitted, and the streaming schedule may indicate when a particular stream message or packet is to be transmitted or received. During the transmission window of the scheduled packet, other packet queues or flows may be blocked so that the scheduled packet may be transmitted without delay caused by interfering traffic.

Scheduling rules and/or related schedules may be used to minimize latency in the TSN by providing TSN elements (e.g., speakers and/or repeaters) with transmission windows to send and/or receive messages. For example, scheduling rules and/or related scheduling may cause non-scheduled traffic to be blocked, leaving a port or related transmission medium free when scheduled traffic is to be transmitted. It should be appreciated that the scheduling rules and/or TSN scheduling are more efficient when the TSN elements or their associated clocks are synchronized, thereby minimizing the impact of interfering traffic. However, if the scheduling rules are not correctly or uniformly followed between the various TSN elements, problems may arise because interfering traffic may occur.

In accordance with some aspects of the subject matter described herein, techniques, methods, apparatus, systems, and/or mechanisms for testing time synchronization between TSN elements are disclosed. For example, the test system may be configured to test the time synchronization of one or more clocks by measuring a maximum time error. In this example, determining the maximum time error may include comparing the time reported by the system under test to a time known by a reference (e.g., a master clock or a test system clock).

In accordance with some aspects of the subject matter described herein, techniques, methods, apparatus, systems, and/or mechanisms for testing TSN elements are disclosed. For example, the test system may be configured for test scheduling rules or TSN scheduling implemented by TSN elements. In this example, to test the TSN element or aspects thereof, the test system may use a time synchronization protocol or other synchronization mechanism to synchronize the test system clock with the clock at the SUT, receive a sequence of messages, where the sequence of messages is generated using the scheduling rule, and use timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

In accordance with some aspects of the subject matter described herein, techniques, methods, apparatus, systems, and/or mechanisms for testing the consistency and/or interoperability of TSN elements are disclosed. For example, the conformance test may include a process of testing a specific implementation of the TSN standard against a predetermined and standardized test specification, which may attempt to cover as many testable statements as possible in the standard, thereby ensuring better interoperability of the devices under test. In this example, the test system may be configured to test a particular implementation of the TSN standard by sending and/or receiving test messages to and/or from the SUT. Continuing with the example, the testing system may analyze the observed behavior of the SUT and compare it to expected behavior based on standardized test specifications or related data.

Reference will now be made in detail to exemplary embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

FIG. 1 is a diagram illustrating an example test environment 100 for testing TSN elements. Referring to FIG. 1, a test environment 100 may include a test system 102 and one or more devices and/or Systems Under Test (SUTs) 106. The test system 102 may represent any suitable entity or entities (e.g., one or more computing platforms, nodes, or devices) associated with testing the SUT106 (e.g., one or more TSN elements). For example, the test system 102 may generate and send traffic to the SUT106 and/or receive traffic from the SUT106, and may analyze one or more aspects associated with the SUT 106.

In some embodiments, the test system 102 may be a stand-alone start-up tool, test device, or software executing on one or more processors 112. In some embodiments, test system 102 may be a single device or node, or may be distributed among multiple devices or nodes. In some embodiments, the test system 102 may include one or more modules for running various test-related functions. For example, the test system 102 may include a TSN element simulation module for simulating one or more TSN nodes or devices in communication with the SUT 106.

The test system 102 may include a processor 112, memory 114, and a SUT Test Module (STM) 104. Processor 112 may represent or include a physical processor, a general purpose microprocessor, a single core processor, a multi-core processor, a Field Programmable Gate Array (FPGA), and/or an Application Specific Integrated Circuit (ASIC) for executing software and/or logic stored in memory 114. Memory 114 may represent one or more computer-readable media for storing data, logic, or other information.

The STM 104 may be any suitable entity or entities (e.g., software executing on a processor, an ASIC, an FPGA, or a combination of software, ASIC, or FPGA) for running one or more aspects associated with testing the SUT106 and/or various aspects thereof. In some embodiments, the STM 104 may be implemented using a processor 112 and/or memory 114. For example, the STM 104 may generate test messages for multiple message flows (e.g., flows or sessions) using the processor 112 (e.g., using software stored in the memory 114). In this example, the STM 104 may also utilize the processor 112 to run various tests and/or analyses involving test messages and/or associated responses from the SUT 106.

In some embodiments, the STM 104 may include one or more communication interfaces, such as one or more Network Interface Cards (NICs), for interacting with users, modules, and/or nodes. For example, the STM 104 may use one or more communication interfaces for receiving various messages and one or more communication interfaces for sending various messages. Example messages include IP messages, ethernet frames, ethernet messages, PDUs, datagrams, UDP messages, TCP messages, IP version 4 (v4) messages, IP version 6 (v6) messages, Stream Control Transmission Protocol (SCTP) messages, real-time transport protocol (RTP) messages or Reliable Data Protocol (RDP) messages, messages using tunneling protocol, and/or other TSN related messages.

In some embodiments, the STM 104 may include or provide a communication interface for communicating with STM users 110. The STM user 110 may be any entity (e.g., an automated system or a device or system controlled or controllable by a human user) for selecting and/or configuring various aspects associated with testing and/or generating test-related metric values. For example, various user interfaces (e.g., application user interfaces (APIs) and Graphical User Interfaces (GUIs)) may be provided to provide configuration information such as tests to be run, problems to be analyzed, damage to be generated, types of metrics or statistics to be generated, number of test messages per port or flow to be generated, and/or other settings.

In some embodiments, the STM 104 may include one or more communication interfaces for interacting with the SUT 106. For example, the STM 104 or another entity may be configured to send test messages to or receive test messages from one or more ports (e.g., ports 1, 2, and/or 3) associated with the SUT 106. The SUT106 may be any suitable entity or entities (e.g., device, system, or platform) for communicating with the test system 102 and/or receiving, processing, forwarding, and/or sending one or more messages. For example, the SUT106 may include at least a TSN element capable of communicating time-sensitive data or related messages. In another example, the SUT106 may include one or more systems and/or computing platforms, such as a set of servers and/or routers. In yet another example, the SUT106 may include one or more network or related components, such as a TSN or a portion thereof.

In some embodiments, the TSN elements that may be tested by the test system 102 or the STM 104 may include network repeaters, time synchronization protocol repeaters, network routers, network switches, network devices, servers, or network controllers.

In some embodiments, one or more user interfaces for testing the SUT106 and/or for providing configuration information may support automation, for example, through one or more programming languages (e.g., python, PHP, etc.), representational state transfer (REST) APIs, command lines, and/or Web-based GUIs. For example, the STM user 110 may interact with a Web-based GUI using a Web browser to program or configure one or more aspects for testing the SUT 106.

In some embodiments, the STM 104 may include functionality for accessing STM memory 108 or memory 114. STM memory 108 may be any suitable entity or entities (e.g., storage devices, memory 114, non-transitory computer-readable media, or storage systems) for holding or storing information relating to a test. For example, the STM memory 108 may store information related to message capture, such as time increment information, timestamp related data, and/or other information. In this example, information related to message capture may be used to determine, derive, or calculate statistics related to one or more tests.

In some embodiments, the STM memory 108 may also contain information that may be used to generate statistics and/or metric values associated with one or more aspects of the SUT 106. For example, during one or more test scenarios, the STM memory 108 may contain metric values associated with one or more performance aspects of the SUT 106. In this example, the STM memory 108 may retain a particular set of calculated metric values for a first test or message stream, and may retain another set of calculated metric values for a second test or different message stream. In some embodiments, the STM memory 108 and/or the memory 114 may be located at the test system 102, at another node, or distributed across multiple platforms or devices.

In some embodiments, the test system 102, the STM 104, or another module may be configured to test various aspects associated with the TSN standard set forth by the IEEE 802.1 time-sensitive networking task group. For example, the test system 102, the STM 104, or another module may be configured to test whether the SUT106 meets or properly implements various aspects of the following criteria: IEEE Standard 802.1Qav-2009, IEEE Standard 802.1Qbv-2015, IEEE Standard 802.1AS-Rev, IEEE Standard 802.1Qbu-2016, IEEE Standard 802.1CB, IEEE Standard 802.1Qcc, IEEE Standard 802.1Qca-2015, IEEE Standard 802.1Qch, IEEE Standard 802.1Qci-2017, IEEE Standard 802.1Qcj, IEEE Standard 802.1Qcp, IEEE Standard 802.1Qcr, and/or IEEE Standard 802.1 CM. The above-mentioned publicly available standards or sub-standards (e.g., IEEE Standard 802.1Qav-2009, IEEE Standard 802.1Qbv-2015, IEEE Standard 802.1Qbu-2015, IEEE Standard 802.1Qca-2015, and IEEE Standard 802.1Qci-2017) are incorporated by reference herein in their entirety.

Some example tests that may be run by the test system 102, the STM 104, or another module may include: testing redundancy in a time synchronization protocol (e.g., PTP) configuration gateway; testing timing in a time synchronization protocol configuration gateway; test reservation protocol (e.g., multi-stream reservation protocol (MSRP) or Stream Reservation Protocol (SRP)) flow (flow); testing the expandability of a reservation protocol of a control layer; testing the speaker; analyzing the bandwidth guarantee; analyzing latency (e.g., using normal minimum, maximum, and/or mean latency measurements or histograms); analyzing a scheduler associated with the test speaker; testing the repeater; analyzing a scheduler associated with testing the repeater; testing the hot standby optimal master clock or master clock; testing non-TSN elements to the TSN gateway; test frame replication and elimination; testing seamless redundancy of switches and endpoints; testing the door accuracy; testing TSN scheduling fidelity; testing admission control of the TSN element; testing a discarding strategy of messages with improper sizes; testing interactions with credit-based shapers or other shapers (e.g., non-TAS shapers); testing for real-time configuration changes in the TAS; and/or test configuration updates.

It should be understood that fig. 1 is for illustrative purposes and that various nodes and/or modules, locations, and/or functions described above with respect to fig. 1 may be changed, altered, added, or removed.

FIG. 2 is a diagram illustrating an example test system 102 that uses an internal master clock for time synchronization. In some embodiments, test system 102 and/or functionality therein may be distributed among one or more modules, devices, or computing platforms.

Referring to FIG. 2, the depicted test environment 200 may include the test system 102, the SUT106, and the TSN schedule 210 implemented thereon. As depicted, the test system 102 may include a synchronization module 202, a TSN scheduler module 204, a TSN schedule 206, a speaker 208, a listener 212, and a TSN schedule fidelity module 214. The synchronization module 202 may represent any suitable entity (e.g., software executing on at least one processor) for running various aspects associated with clock synchronization. For example, the synchronization module 202 may implement and use a time synchronization protocol (e.g., gPTP or some other PTP protocol standard) to manage clock synchronization of the test system 102.

In some embodiments, the synchronization module 202 may include, utilize, or access a test system clock. The test system clock may be any suitable entity (e.g., a hardware-based clock or a software-based clock) for generating the time indication and/or for maintaining the time.

In some embodiments, the synchronization module 202 or a related module in the test system 102 may serve as a master clock for time synchronization purposes (e.g., a gPTP or PTP optimal master clock), and the SUT106 may receive time synchronization data from the test system 102, e.g., for synchronizing its own clock with the test system clock.

The TSN scheduler module 204 may represent any suitable entity (e.g., software executing on at least one processor) for running aspects associated with TAS and/or message scheduling. For example, the TSN scheduler module 204 may determine the TSN schedule (e.g., a messaging schedule and/or a gate access list) through one or more test iterations. In some embodiments, the TSN scheduler module 204 may determine a TSN schedule 206 for one or more packet queues or flows. For example, each message queue or flow may be associated with a transmission gate that is open or closed. In this example, the transmission of a message (e.g., a frame or packet) from the message queue can only occur if the door is open and the full message can be transmitted before the door is closed. Continuing with the example, the TSN schedule 206 generated by the TSN scheduler module 204 may include a start time (e.g., an operation reference time) and a repeat time (e.g., an operation cycle time).

In some embodiments, the TSN schedule 206 may include or refer to a gate access list that includes an ordered list of gate operations. For example, the gate access list may include a plurality of entries, where each entry may include a transmission gate setting (e.g., a gate state value) and a latency (e.g., a time interval value) for each packet queue before executing the next list entry.

In some embodiments, the TSN schedule 206 may conform to or be based on IEEE Standard 802.1 Qbv-2015. For example, the TSN schedule 206 may include TAS-related information such as a gate access list and/or other information to indicate when a gate or transmission is open or closed.

In some embodiments (e.g., when implementing the TSN schedule 206 or the associated gate access list), at the beginning of each cycle, the first entry on the list may be executed, and then after a specified latency, the next entry may be executed. In some embodiments, entries may be executed in this manner until the last entry is executed. Once the final entry is executed, no gate changes can be run until the next cycle begins. An exemplary gate access list for two queues (e.g., gates 1 and 2) is described in table 1.

TABLE 1

Door state value	Value of time interval
		{1, open } {2, close }	10,000ns
{1, closed } {2, open }	15,000ns
		{1, open } {2, close }	5,000ns

Speaker 208 may represent any suitable entity (e.g., one or more Network Interface Cards (NICs) or communication modules) for transmitting messages (e.g., frames or message sequences) to SUT106 or other entities. In some embodiments, the speaker 208 may include or represent one or more ports for sending traffic to the SUT106 and/or other entities. For example, the speaker 208 may transmit test messages from one or more associated message queues via one or more ports. In this example, the transmitted test message may be sent to one or more specific ports at the SUT 106.

In some implementations, the speaker 208 or another module may send or share the TSN schedule 206 with the SUT 106. For example, after determining the TSN schedule 206 but before testing the SUT106, the TSN scheduler module 204 may trigger the speaker 208 to send the TSN schedule 206 or TSN schedule 210 to the SUT106 via one or more speaker-related ports. In another example, TSN schedule 206 or TSN schedule 210 may be sent to SUT106 using various mechanisms, such as via different ports (e.g., TSN port or non-TSN port), protocols (e.g., IP, HTTP, TCP, or UDP), and/or entities. In some embodiments, after receiving TSN schedule 206 or TSN schedule 210, SUT106 may store TSN schedule 206 or TSN schedule 210 and use it (e.g., during testing) to schedule and/or run messaging.

Listener 212 may represent any suitable entity (e.g., one or more NICs or communication modules) for receiving messages (e.g., frames or messages) from SUT106 or other entities. In some embodiments, the listener 212 may include or represent one or more ports for receiving traffic from the SUT106 and/or other entities. For example, listener 212 may receive a test message from SUT 106. In some embodiments, listener 212 may include functionality for identifying relevant test messages. For example, the listener 212 may analyze message parameters, such as a source Media Access Control (MAC) address and a destination MAC address, to determine a flow identifier associated with a received message. In this example, the flow identifier may be used to identify a particular message flow and may be used to differentiate the traffic analyzed by each flow.

TSN schedule fidelity module 214 may represent any suitable entity (e.g., software executing on at least one processor) for determining how faithful or accurate the SUT106 implements TSN schedule 210 or related scheduling rules. For example, TSN scheduling fidelity module 214 may analyze the captured traffic and determine how accurately the SUT106 has implemented the TSN schedule 210 based on the TSN schedule 206 and/or using timing information of the received packets. In this example, TSN scheduling fidelity module 214 may be capable of running an analysis for each message stream and/or each test iteration.

In some embodiments, TSN scheduling fidelity module 214 or another module may test gate accuracy. For example, the SUT106 may be configured with a scheduling rule that requires that messages begin to be transmitted after the transmission gate is opened, but that no portion of the message be transmitted after the gate is closed. In this example, to test the implementation of gate accuracy, SUT106 may be configured with TSN schedule 210, speaker 208 may transmit traffic for different queues from different ports, and listener 212 and/or another module may verify that the scheduling rules for TSN schedule 210 in terms of gate accuracy have been met (e.g., transmit overrun statistics remain zero during the test iteration).

It should be appreciated that fig. 2 is for purposes of illustration, and that various nodes and/or modules, locations, and/or functions described above with respect to fig. 2 may be changed, altered, added, or removed. It should be understood that the speaker 208 may also receive at least some traffic and the listener 212 may send at least some traffic, and this nomenclature is for convenience and is not intended to indicate a limitation on either the speaker 208 or the listener 212.

FIG. 3 is a diagram illustrating an example test system 102 that uses an external master clock 302 for time synchronization. Unless otherwise noted, the test system 102 and related modules or entities described in fig. 3 may include similar functionality as described with respect to fig. 2.

Referring to fig. 3, the depicted test environment 300 may involve testing the SUT106 using an external master clock 302. Master clock 302 may represent any suitable entity (e.g., software, hardware, and/or firmware) for generating a time indication and/or for maintaining a time. The master clock 302 may be independent of and/or separate from the test system 102 and may be configured to provide time synchronization messages to various entities (e.g., slave clocks) for time synchronization purposes. In some embodiments, master clock 302 may be a gPTP or PTP optimal master clock, or include similar functionality.

In some embodiments, the synchronization module 202 or another module in the test system 102 may be used as a slave clock (e.g., a gPTP slave clock) for time synchronization purposes. In such embodiments, the test system 102 and the SUT106 may receive time synchronization data from the external master clock 302.

It should be appreciated that fig. 3 is for illustrative purposes and that various nodes and/or modules, locations, and/or functions described above with respect to fig. 3 may be changed, altered, added, or removed.

FIG. 4 is a diagram illustrating an example test system 102 that uses a damage module (IM)402 to damage transmitted test messages. Unless otherwise noted, the test system 102 and related modules or entities described in fig. 4 may include similar functionality as described with respect to fig. 2.

Referring to FIG. 4, the depicted test environment 400 may involve testing the SUT106 using IM 402. IM402 may represent any suitable entity (e.g., software executing on at least one processor) for adjusting transmission scheduling parameters and/or modifying messages or message content during a test iteration or portion thereof. For example, IM402 may be capable of changing the message size of a test message, adding fuzzy data to a test message, modifying data in a test message, or changing when or how a test message is transmitted (e.g., triggering a test message to be transmitted before or after a certain time according to TSN schedule 206). In another example, the IM402 may discard messages or may reorder test messages sent to the SUT 106.

In some embodiments, the synchronization module 202 or a related module in the test system 102 may serve as a master clock for time synchronization purposes (e.g., a gPTP or PTP optimal master clock), and the SUT106 may receive time synchronization data from the test system 102 to synchronize its own clock with the test system clock.

In some embodiments, the synchronization module 202 or another module in the test system 102 may serve as a slave clock (e.g., a gPTP or PTP slave clock) for time synchronization purposes. In such embodiments, the test system 102 and the SUT106 may receive time synchronization data from an external master clock (e.g., a gPTP or PTP optimal master clock).

In some embodiments, the IM402 may include functionality for changing transmission scheduling parameters to determine the highest rate possible and/or the smallest time shaping window possible that the SUT106 and/or its TAS may handle correctly, e.g., without having to exceed an expected receive latency window or frame loss threshold window. For example, the test system 102 and/or one or more associated modules may configure a test using a binary search for varying transmission scheduling parameters in order to determine an appropriate test output limit threshold or window. In this example, the STM user 110 may be able to configure or control all aspects of the TSN scheduler profile. In some embodiments, preset control of various parameters of the TSN scheduler profile may be used in one or more test iterations to determine or derive TAS accuracy convergence criteria.

In some embodiments, the IM402 may include functionality for modifying the message size of test packets used to test admission control and/or other functions of the SUT 106. For example, the test system 102 and/or one or more associated modules may configure tests to transmit test messages of various sizes (e.g., packets of an expected size and packets exceeding an expected or allowed size) from various message queues or ports to the SUT 106. In this example, the SUT106 may be configured with a policy that discards "oversized" packets (e.g., any packets larger than a predetermined maximum packet size value) while forwarding or relaying all other packets to the listener 212. Continuing with the example, to determine whether the policy is accurately implemented at the SUT106, the listener 212 and/or another module (e.g., STM 104) may verify whether an oversized frame was correctly dropped in each queue.

It should be appreciated that fig. 4 is for illustrative purposes and that various nodes and/or modules, locations, and/or functions described above with respect to fig. 4 may be changed, altered, added, or removed. Further, while IM402 is described as being separate from speaker 208, it should be understood that IM402 and/or related functionality may incorporate and/or utilize speaker 208 or another module in testing system 102 when running the various compromising functions described herein.

FIG. 5 is a diagram illustrating an example test system 102 and an individual instructor 502. Unless otherwise noted, the test system 102 and related modules or entities described in fig. 5 may include similar functionality as described with respect to fig. 2.

Referring to FIG. 5, the depicted test environment 500 may involve testing the SUT106 using a separate (e.g., independent of the test system) speaker 502. The speaker 502 may represent any suitable entity (e.g., a TSN device) for transmitting messages (e.g., frames or messages) to the SUT106 or other entities, and may operate independently of the test system 102. For example, the speaker 502 may be the SUT106 or another entity, such as an actual TSN element in an enabled (non-testing) TSN. In this example, test system 102 may include listener 212, but may forego sending test messages from a speaker (e.g., speaker 208) internal to or associated with the test system.

In some embodiments, the SUT106 may incorporate or include the speaker 502 or related functionality. For example, the SUT106, such as in the case of using the speaker 502 or related functionality, may use the TSN schedule 210 to generate the streamed traffic. In this example, the traffic may be sent to one or more ports associated with the listener 212.

In some embodiments, for example, where the speaker 502 is separate from both the test system 102 and the SUT106, the speaker 502 may generate the streamed traffic using the TSN schedule 504. In this example, traffic may be sent to one or more ports associated with the SUT 106. Continuing with the example, the SUT106 may process traffic from the speaker 502 and send at least some of the traffic to the test system 102 using the TSN schedule 210. In some embodiments, the synchronization module 202 or a related module in the test system 102 may serve as a master clock for time synchronization purposes (e.g., a gPTP optimal master clock), and the SUT106 may receive time synchronization data from the test system 102 to synchronize its own clock with the test system clock.

In some embodiments, the synchronization module 202 or another module in the test system 102 may be used as a slave clock (e.g., a gPTP slave clock) for time synchronization purposes. In such embodiments, the test system 102 and the SUT106 may receive time synchronization data from an external master clock (e.g., a gPTP optimal master clock).

In some embodiments, TSN schedule fidelity module 214 may analyze received traffic using TSN schedule 206. In some embodiments, expected message flow data and associated expected receipt scheduling data may be input and stored for each message flow. For example, the TSN schedule 206 may include expected packet flow data and associated expected reception schedule data (e.g., reception latency variation information for each TSN flow). In this example, the TSN schedule 206 and/or related information may be provided or determined prior to testing.

In some embodiments, for example, where the message stream is generated by a speaker 502 (or other TSN element) that is not directly associated with the test system 102, the STM user 110 or other user may manually provide the TSN schedule 206 and/or TSN schedule fidelity module 214 with the expected data. For example, the STM user 110 (e.g., a network operator and/or a tester) may exert control over the speaker 502 and/or may know information about the TSN schedule used by the speaker 502. In this example, the STM user 110 may provide the test system 102 and/or modules therein with the expected data.

In some embodiments, a system, device, or module (e.g., a TSN scheduler module) may automatically provide expected data to TSN schedule 206 and/or TSN schedule fidelity module 214. For example, the system may determine, derive, or identify a TSN schedule based on observations, querying nodes or databases (e.g., via an API), test specifications, or other techniques. In some embodiments, the listener 212 may be configured to identify flows of messages received from one or more ports, to identify received messages on a per flow basis and/or to associate received messages with expected message data. For example, the listener 212 may identify or obtain information regarding one or more message parameters (e.g., a source Media Access Control (MAC) address and a destination MAC address) to use as a flow identifier, which may be used to uniquely identify a particular message flow. In this example, the listener 212 may use the flow identifier to associate data of the received message with expected message flow data and associated expected receipt scheduling data on a per message flow basis, including, for example, expected receipt scheduling variation/window information.

In some embodiments, TSN schedule fidelity module 214 may determine how faithfully or accurate the SUT106 achieves the TSN schedule 210. For example, the TSN scheduling fidelity module 214 may analyze each packet stream using timing information of received packets and expected timing information to determine various statistics related to the performance of the SUT 106.

In some embodiments, statistics and/or other test-related data may be presented to STM users 110. For example, the listener 212 or a port therein may be configured to operate in an egress tracking only (egress tracking only) mode. In this example, in an egress-only trace mode, the listener 212 or a port therein may be able to identify relevant packets by reading a particular packet field (e.g., parameter value) and/or a particular offset in the packet to count the packets received per flow. Continuing with the example, in exit-only trace mode, the listener 212 or a port therein may or may not use or read the test system based signature in the received message.

In some embodiments, TSN scheduling fidelity related statistics may be calculated and/or presented. For example, test system 102 or TSN scheduling fidelity module 214 may utilize expected test message data and actual timestamps of the messages to identify time increments of the test messages (e.g., the difference between the expected arrival time of the message and the actual arrival time of the message) in one or more message streams. In this example, the time increment may be shown or depicted as a line or histogram, for example, where the x-axis indicates the number of messages and the y-axis indicates the amount of time (e.g., nanoseconds).

In some embodiments, packet capture and related derived information may be used to determine TSN scheduling fidelity related statistics. For example, STM user 110 may manually check the time of receipt of the message. In another example, STM user 110 may select a message statistics view, where the message statistics view may display various message statistics using data obtained via packet capture analysis in a real-time or offline capture mode.

It should be appreciated that fig. 5 is for illustrative purposes and that various nodes and/or modules, locations, and/or functions described above with respect to fig. 5 may be changed, altered, added, or removed.

FIG. 6 is a diagram illustrating an example test system 102 that performs tests using a network splitter 602-606. Unless otherwise specified, the test system 102, the STM 104, and the SUT106 depicted in FIG. 6 may include similar functionality as described with respect to FIG. 1, the synchronization module 202 and the IM402 depicted in FIG. 6 may include similar functionality as described with respect to FIG. 4, and the instructor 502 depicted in FIG. 6 may include similar functionality as described with respect to FIG. 5.

Referring to FIG. 6, a testing environment 600 is depicted that may involve testing the SUT106 by utilizing a network splitter 602-606 to obtain and analyze traffic between an individual or independent speaker 502 and an individual or independent listener 608. The network splitter 602 and 606 may represent any suitable entity for replicating a packet or related data across one or more links and for transmitting the packet or related data to one or more destinations (e.g., the STM 104).

The speaker 502 may represent any suitable entity (e.g., a TSN device) for transmitting messages (e.g., frames or packets) to the SUT106 or other entities and may operate independently of the test system 102. For example, the speaker 502 may be an actual TSN element in an enabled (non-test) TSN. Listener 608 may represent any suitable entity (e.g., a TSN device) for receiving messages (e.g., frames or messages) from SUT106 or other entities, and may operate independently of test system 102. For example, listener 608 may be an actual TSN element in an enabled (non-test) TSN.

In some embodiments, the synchronization module 202 or a related module in the test system 102 may serve as a master clock for time synchronization purposes (e.g., a gPTP optimal master clock), and the SUT106 may receive time synchronization data from the test system 102 to synchronize its own clock with the test system clock.

In some embodiments, the synchronization module 202 or another module in the test system 102 may be used as a slave clock (e.g., a gPTP slave clock) for time synchronization purposes. In such embodiments, the test system 102 and the SUT106 may receive time synchronization data from an external master clock (e.g., a gPTP optimal master clock).

In some embodiments, test environment 600 may be used for TSN deployment testing, such as debugging a TSN scheduler or other node or problem in an enabled (non-test) environment. For example, using the arrangement shown in FIG. 6, the test system 102 and/or the STM 104 may analyze and/or identify various issues by observing traffic (including injected and/or compromised traffic from the IM402 or other entity). In this example, the test system 102 and/or the STM 104 may use timing information (e.g., timestamps) from the observed traffic and other information (e.g., expected receipt times based on the known TSN schedule 206) to determine scheduling errors or other issues.

Some example test goals for test environment 600 may include: analyze whether the SUT106 (e.g., a message repeater) correctly forwards the TSN packet based on the configured network schedule; analyzing the robustness of TSN prioritization by generating interference or additional traffic (e.g., using IM 402) between speaker 502 and listener 608; analyzing the robustness of TSN prioritization by generating interfering traffic through SUT106 or various repeaters; analyze how or if impairments (e.g., delays, bursts, reordering, drops, corruption) of TSN packets affect SUT 106; and analyze how or if impairments (e.g., delays, bursts, reordering, drops, corruption) of the TSN packet affect the listener 608.

It should be appreciated that fig. 6 is for illustrative purposes and that various nodes and/or modules, locations, and/or functions described above with respect to fig. 6 may be changed, altered, added, or removed.

Fig. 7 is a diagram illustrating scheduler errors after testing TSN elements. In some embodiments, the test system 102, the STM 104, or another module (TSN scheduler fidelity module 214) may include functionality for generating and displaying TSN scheduler-related errors using a histogram 700 or other graphical data representation. For example, as shown in fig. 7, histogram 700 may indicate a significant glitch in TSN scheduler related errors for every 100 transmitted packets.

In some embodiments, the test system 102, the STM 104, or another module (TSN schedule fidelity module 214) may include functionality for displaying or presenting various statistics, preferences, and/or display settings to the STM user 110. For example, the test system 102 or the STM 104 may allow the STM user 110 to configure or change properties related to the histogram 700, including x and y coordinates and related scaling.

It should be understood that fig. 7 is for illustrative purposes and that different and/or additional data and/or display techniques may be used to display the histogram 700 or the data therein.

FIG. 8 is a diagram showing a latency bin reporting results 800 after testing a TSN element. In some embodiments, the test system 102, the STM 104, or another module (e.g., the TSN schedule fidelity module 214) may include functionality for classifying test traffic into latency receivers. Each latency receiver may represent a length of time (e.g., microseconds) associated with a corresponding measured or derived TSN scheduler related error. For example, as shown in fig. 8, the result 800 may indicate a significant amount of error incurred between a latency of 480 and 500 microseconds.

In some embodiments, the test system 102, the STM 104, or another module (TSN schedule fidelity module 214) may include functionality for displaying or presenting various statistics, preferences, and/or display settings to the STM user 110. For example, the test system 102 or the STM 104 may allow the STM user 110 to configure or change the classification algorithm when selecting a latency receiver that may be used to describe the results 800.

It is to be appreciated that fig. 8 is for illustrative purposes and that different and/or additional data and/or display techniques may be used to display the results 800.

Fig. 9 is a message diagram illustrating a messaging strategy for testing TSN elements. Referring to FIG. 9, the test environment 900 may include a speaker 208 for sending or transmitting test messages to the SUT106 and a listener 212 for receiving test messages from the SUT 106. The testing environment 900 may be used to test messaging policies (e.g., Qci policy making) associated with the SUT106, where the SUT106 may include a gPTP relay function. For example, the test environment 900 may be used to test whether messaging policies are implemented correctly (e.g., run as expected) at the SUT 106. In this example, the tested messaging strategy may involve discarding ptp messages received outside the allowed receive window and forwarding or relaying the ptp messages received within the allowed receive window to the listener 212.

In some embodiments, the speaker 208 or an associated module in the test system 102 may serve as a master clock for time synchronization purposes (e.g., a gPTP optimal master clock), and the SUT106 may receive time synchronization data from the speaker 208 to synchronize the SUT's own clock.

Referring to fig. 9, in step 901, a first ptp message may be sent from the speaker 208 to the SUT106 and may be received outside of the allowed ptp receive window.

In step 902, the first ptp message may be sent from SUT106 to listener 212. Because the first ptp message is sent to SUT106 even though it is received outside of the allowed ptp receive window, test system 102 or a related module may determine that the measured message transmission policy at SUT106 was not implemented or configured properly.

In block 903, a second ptp message may be sent from the speaker 208 to the SUT106 and may be received within the allowed ptp receive window.

In step 904, a second ptp message may be sent from SUT106 to listener 212 according to the messaging strategy under test.

In block 905, a third ptp message may be sent from the speaker 208 to the SUT106 and may be received outside of the allowed ptp receive window. The third ptp message may be discarded according to the message sending policy under test.

In block 906, a fourth ptp message may be sent from the speaker 208 to the SUT106 and may be received within the allowed ptp receive window.

In step 907, a fourth ptp message may be sent from SUT106 to listener 212 according to the messaging strategy under test.

In some embodiments, the test system 102, the STM 104, or another module may analyze, derive, and/or determine performance information regarding the SUT106 and/or its functionality. For example, test system 102 may determine, for example, using the results depicted in FIG. 9: when receiving the gPTP message for more than 5 seconds outside the allowed receiving window, the implementation of the sending strategy of the detected message fails; but when receiving a gpptp message within an allowed receive window or within 5 seconds or less outside the allowed receive window, the implementation of the measured message transmission strategy operates as expected.

It should be appreciated that fig. 9 is for illustrative purposes, and that different and/or additional messages and/or actions may be used to test the SUT106 and/or related actions. It should also be appreciated that the various messages and/or actions described herein with respect to fig. 9 may occur in a different order or sequence. Further, it should be understood that various other aspects of the SUT functionality and/or configuration may be tested using the testing system 102 and/or functionality described herein.

Fig. 10 is a block diagram illustrating an example process 1000 for testing TSN elements. In some embodiments, the process 1000, or portions thereof, may be executed by the test system 102, the STM 104, the SUT106, and/or another node or module. In some embodiments, example process 1000 may include blocks 1002, 1004, and/or 1006.

Referring to the example process 1000, in block 1002, the test system clock may be synchronized with the clock at the SUT 106. For example, the STM 104 or the synchronization module 202 may include, utilize, or communicate with a test system clock. In this example, the test system clock and the clock at the SUT106 may be synchronized using gPTP or another time synchronization protocol. In another example, the SUT106 and the test system 102 may use external time input from a GPS-based time source.

In some embodiments, the test system clock may be configured to serve as a master clock or a slave clock for synchronizing the test system clock with the clock at the SUT 106. For example, the test system clock may serve as a PTP optimal master clock, and may provide time synchronization data to the SUT 106. In another example, the test system clock may be used as a slave clock and the time synchronization data may be received from the PTP best Master clock.

In block 1004, a sequence of messages may be received. The sequence of packets may be generated using a scheduling rule associated with the TSN stream. For example, the scheduling rules at the SUT106 (e.g., TSN schedule 210) may be similar or identical to the scheduling rules at the test system 102 (e.g., TSN schedule 206) or other related entities. In this example, the scheduling rules may be provided to the SUT106 by the testing system 102, the STM 104, or a correlation module prior to testing the SUT 106.

In some embodiments, the sequence of messages received at test system 102 may be sent by SUT106, test system 102, or a speaker device (e.g., speaker 502) separate from SUT106 and test system 102.

In some embodiments, a sequence of test messages may be generated and transmitted to the SUT106 using the TSN schedule 206, for example, at the test system 102 and prior to receiving the sequence of messages from the SUT 106.

In some embodiments, generating the test messages may include embedding a high precision timestamp and/or expected received packet latency in each test message (e.g., packet). For example, by embedding such information, the test system 102 may be able to quickly generate various statistical data and/or other timing-related measurements.

In some embodiments, the TSN schedule for the message streams associated with the testing of the SUT may be determined, selected, or implemented, for example, at the test system 102 and prior to receiving the message sequence from the SUT 106.

In some embodiments, the test system 102 may be configured to provide the scheduling rules to the SUT106, where the scheduling rules may be associated with TSN scheduling.

In some embodiments, transmitting the test packets to the SUT106 may include scheduling the transmission of each test packet, or scheduling the transmission of a first test packet and transmitting subsequent test packets using the flow delay information and packet rate. For example, the STM 104 or TSN scheduler module 204 may generate a transmit packet schedule that contains a list of packets to transmit and a time to transmit each packet. In this example, the transmit message schedule may be used to transmit each message at a scheduled time. In another example, the STM 104 or TSN scheduler module 204 may generate a transmit packet schedule that includes a list of packets to transmit and a time to transmit the first packet. In this example, the transmit packet schedule may be used with the flow delay information, the cycle time parameter information, and/or the expected packet rate to transmit the first packet and subsequent packets.

In some embodiments, transmitting the sequence of test messages to the SUT106 may include transmitting at least one corrupted test message, where the at least one corrupted test message has a different message size than expected, fuzzy data, is transmitted in a different order than expected, or may be transmitted outside of an acceptable time period based on one or more scheduling rules. For example, when sending test packets to the SUT106, the IM402 may adjust test packet attributes and/or transmission-related parameters associated with the TSN schedule 206.

In block 1006, timing information associated with the test system clock may be used to determine whether the scheduling rule is accurately implemented by the SUT 106. In some embodiments, determining whether the scheduling rule is accurately implemented by the SUT106 may include using latency and packet information time of arrival measurements based on the packet data (e.g., high precision timestamps embedded in the test messages and/or expected received packet latencies) and scheduling information about the relevant packet flow.

In some embodiments, the test system 102 may be configured to test one or more functions run by the SUT106 or one or more TSN standards or protocols implemented by the SUT 106. For example, the test system 102 may be configured to: testing redundancy in a time synchronization protocol configuration gateway; testing timing in a time synchronization protocol configuration gateway; testing a reserved protocol flow; testing the expandability of a reservation protocol of a control layer; testing the speaker; analyzing the bandwidth guarantee; analyzing the latent period; analyzing a scheduler associated with the test speaker; testing the repeater; analyzing a scheduler associated with testing the repeater; testing the hot standby optimal master clock or master clock; testing non-TSN elements to the TSN gateway; test frame replication and elimination; testing seamless redundancy of switches and endpoints; testing the door accuracy; testing TSN scheduling fidelity; testing admission control of the TSN element; testing a discarding strategy of messages with improper sizes; testing interactions with credit-based shapers or other shapers (e.g., non-TAS); testing for real-time configuration changes in the TAS; and/or test configuration updates.

It is to be appreciated that process 1000 is for illustrative purposes and that different and/or additional acts can be utilized. It should also be appreciated that various actions described herein may occur in a different order or sequence.

It should be noted that the test system 102, the STM 104, and/or the various modules or functions described herein may constitute a special purpose computing platform, device, or system. For example, test system 102 may be an IxNetwork manufactured by Ixia^TMA test device and configured to operate the various aspects described herein. Further, the test system 102, the STM 104, and/or the various modules or functions described herein may improve the technical field of network testing by providing a viable solution for testing TSN elements.

It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.

Claims (9)

1. A method for testing a Time Sensitive Network (TSN) element, the method comprising:

at the test system:

synchronizing a test system clock with a clock at a System Under Test (SUT);

generating a test message sequence by using a scheduling rule related to the TSN flow;

transmitting the test message sequence to the SUT;

receiving a message sequence from the SUT; and

using timing information associated with the test system clock to determine whether the scheduling rule is accurately implemented by the SUT.

2. The method of claim 1, wherein sending the sequence of test messages to the SUT comprises sending at least one corrupted test message, wherein the at least one corrupted test message has a different message size than expected, fuzzy data, is sent in a different order than expected, or is sent outside an acceptable time period based on the scheduling rules.

3. The method of claim 1, wherein transmitting the sequence of test messages to the SUT comprises:

scheduling the transmission of each message in the test message sequence; or

Scheduling transmission of a first packet in the sequence of test packets and transmitting subsequent test packets using flow delay information and packet rate.

4. The method of claim 2, comprising:

at the test system and prior to generating the sequence of test messages:

determining a TSN schedule for a TSN flow associated with testing of the SUT.

5. The method of claim 2, comprising:

at the test system:

providing the SUT with scheduling rules associated with the TSN stream.

6. The method of claim 1, wherein determining whether the scheduling rule is accurately implemented by the SUT comprises using latency and packet information arrival time measurements based on packet timestamps and scheduling information about TSN streams.

7. The method of claim 1, wherein the test system clock is configured to be used as a master clock or a slave clock for synchronizing the test system clock with a clock at the SUT.

8. A system for testing TSN elements using the method of any of claims 1-7, comprising:

means for synchronizing a test system clock with a clock at a System Under Test (SUT);

means for generating a sequence of test messages using a scheduling rule associated with the TSN stream;

means for transmitting the sequence of test messages to the SUT;

means for receiving a sequence of messages from the SUT; and

means for determining whether the scheduling rule is accurately implemented by the SUT using timing information associated with the test system clock.

9. An apparatus for testing Time Sensitive Network (TSN) elements, the apparatus comprising:

a test system, comprising:

means for synchronizing a test system clock with a clock at a System Under Test (SUT);

means for generating a sequence of test messages using a scheduling rule associated with the TSN stream;

means for transmitting the sequence of test messages to the SUT;

means for receiving a sequence of messages from the SUT; and

means for determining whether the scheduling rule is accurately implemented by the SUT using timing information associated with the test system clock.

Images