WO2022006760A1

WO2022006760A1 - Supporting means of time-sensitive network (tsn) operations using tsn configuration verification

Info

Publication number: WO2022006760A1
Application number: PCT/CN2020/100741
Authority: WO
Inventors: Kostas KATSALIS; Yumeng Yang; Siyu Tang; Ming Li; Charles SHERIDAN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-07-08
Filing date: 2020-07-08
Publication date: 2022-01-13
Also published as: CN115699696A

Abstract

The present disclosure relates a device for supporting a time-sensitive network (TSN) configuration verification operation. The device determines a TSN control plane model for each of one or more entities of a communication network, and obtains a symbolic language for each of the one or more entities of the communication network, based on their respective TSN control plane models. The device further obtains an integrated symbolic language for the communication network, based on the symbolic language of the one or more entities, wherein the integrated symbolic language is indicative of one or more relations between the one or more entities in the communication network. Moreover, the device obtains a TSN verification model for the communication network, based on the integrated symbolic language. The present disclosure may be applied in the centralized, in the hybrid, and also in the distributed TSN control plane cases.

Description

SUPPORTING MEANS OF TIME-SENSITIVE NETWORK (TSN) OPERATIONS USING TSN CONFIGURATION VERIFICATION

TECHNICAL FIELD

The present disclosure relates generally to the field of communication networks, and particularly, to Time-Sensitive Networks (TSNs) , specifically IEEE TSN. To this end, the disclosure provides a device and a method for supporting a TSN operation. The device and the method may perform a TSN configuration verification based on a semantic modeling procedure. For example, the device and/or the method of the present disclosure may obtain an integrated symbolic language for a communication network. Moreover, the device and/or the method may obtain a TSN verification model for the communication network based on its integrated symbolic language.

BACKGROUND

Generally, some communication networks are based on TSN, for example, such communication networks may use a TSN technique, e.g., with one or more requirements to communicate data.

For instance, a conventional device provides TSN extensions for enhancing the forwarding plane of conventional bridges, in order to be able to provide deterministic performance not only by means of throughput but also by means of delay and jitter.

Moreover, a TSN operation may address transmission of very low transmission latency and high availability. For example, some TSN-aware systems operate such that each individual queue may have its own scheduling algorithm, while a transmission scheduling algorithm controls the transmission gates in a time-triggered process. Further, using an optimal scheduling algorithm to control the transmission gates, a frame may be transmitted at a precise time, reducing latency due to congestion to the nanosecond level but also ensuring low delay variation.

Furthermore, some devices and methods may provide the TSN control plane functionality. In the following, three methods of providing the TSN control plane are discussed.

A conventional method is based on a fully centralized method where TSN bridges are controlled by a Centralized Network Control (CNC) entity and the endpoints by a centralized user Controller (CUC) .

A conventional method is based on a configuration using a fully distributed protocol. The development of the fully distributed method is currently ongoing work for designing the Resource Allocation Protocol (RAP) that is exploiting a Link Registration Protocol (LRP) underlay transport.

A conventional method is based on using a hybrid mode with a CNC responsible for the configuration and control of TSN bridges, and using a User Network Interface (UNI) to connect the endpoints to access bridges.

Moreover, for the last case when using the hybrid control plane mode, Stream Reservation Protocol (SRP) Enhancements are also proposed to support TSN functionality that may be used, for example, for the announcement of stream properties. Furthermore, some TSN profiles have been specified based on the area of application, for example, to explain which standards, protocols, features and options should be applied for a given use-case. Such conventional TSN profiles are proposed for, e.g., TSN profile for audio or video bridging, TSN profile for industrial automation, TSN profile for automotive in-vehicle Ethernet communications, TSN profile for mobile fronthaul networks, TSN profile for service provider networks, etc.

However, conventional TSN based devices and methods exploit static and customized configuration implementations and are aligned with the standard only when the Management Information Base (MIB) are exactly the same as defined in the standard. Furthermore regarding TSN configuration verification there is no standard related activity. For instance, for the fully distributed case, there is no activity on the relevant verification aspects. Moreover, in the case of centralized configuration or hybrid, the only verification action made is based on the relevant YANG models used by a management protocol like Netconf. For example, on a Netconf message receive event, the Netconf message is dissected and YANG model verification is made to guarantee that, e.g., the operations requested are supported on the server side, and the schema and the data types described in the message are respecting the YANG model of the device.

SUMMARY

In view of the above-mentioned problems and disadvantages, embodiments of the present disclosure aim to improve conventional devices and methods for supporting a TSN configuration verification operation.

An objective is to determine (e.g., derive) in a simple manner an abstract model for the TSN control plane and/or the resulting data plane. In particular, this should be done based on semantic modeling. Another objective is to detect a TSN network configuration error, for example, by analyzing configuration files and finding errors proactively. Another objective is to prohibit changes that violate policies or may cause performance degradation in the communication network. Another objective is to check network-wide variables in real-time, for example, using the verification model determined by the device. Another objective is to perform extensive proactive control and verification procedures by semantic modeling and logical formulas checking for describing states and relationships between them.

The above mentioned objectives are achieved by the embodiments of the disclosure as described in the enclosed independent claims. Advantageous implementations of the embodiments of the disclosure are further defined in the dependent claims.

A first aspect of the present disclosure provides a device for supporting a time-sensitive network operation, the device being configured to determine a TSN control plane model for each of one or more entities of a communication network, obtain a symbolic language for each of the one or more entities of the communication network, based on their respective TSN control plane models, obtain an integrated symbolic language for the communication network, based on the symbolic language of the one or more entities, wherein the integrated symbolic language is indicative of one or more relations between the one or more entities in the communication network, and obtain a TSN verification model for the communication network, based on the integrated symbolic language.

The device may be, or may be incorporated in, an electronic device such as a personal computer, a server computer, a client computer, a laptop and a notebook computer, a tablet device, a mobile phone, a smartphone, etc.

The device is configured to determine the TSN control plane for the one or more entities of the communication network. The entities may be a physical entity or a virtual entity in the communication network supporting one or more of TSN functionalities. Such an entity may be a TSN bridge device, a virtual TSN switch, or Layer 3 router supporting one or more TSN functionalities. Furthermore, determining the control plane for each entity may comprise deriving an abstract control plane for each entity. For example, each entity of the communication network may support one or more functionalities such as Frame Preemption, Cut Through, Frame Replication and elimination. Further, the device may determine the control plane based on based on the YANG model exposed by a vendor or by the description of his MIBs.

Moreover, the device is configured to obtain the symbolic language for each control plane in a vendor independent way and determine an abstract control plane. The symbolic language of an entity is a language where each network parameter or operation is represented by symbols.

For example, according to 802.1Qcw the basic operation for Scheduled Traffic is SetGateStates and its associated parameters are grouped in the sgs-parameters container. Additionally, if Frame Preemption is supported two additional operations can be performed Set-And-Hold-MAC and Set-And-Release-MAC. Their associated parameters are shm-parameters and srm-parameters, respectively. For example, in the symbolic language a boolean variable “preemption_enabled” is introduced to describe an existence or a lack of a preemption support. As another example “mac_addr_port_0” can be used to represent the mac address of port 0. Furthermore, the symbolic language is also used to model dependencies, data plane constraints, and TSN properties.

A symbolic model is devised for every device. After all the symbolic models have been derived for every device, in the following step, an integrated verification symbolic language is constructed that may also capture the dependencies between devices and models in order to perform an end-to-end verification testing.

For example, the device of the first aspect may obtain the TSN control plane model, which may be used for network verification. The device may have a verification module that may determine the verification model. The network verification may identify issues proactively, and before they are applied. Furthermore, in order to have an integrated functional TSN system, automated network verification may consider network models, not only for the abstracted control plane, but also for the resulting data plane because of configuration, in order to perform an end-to-end multivendor verification.

The device may obtain (e.g., determine) the TSN verification model for the communication network. For instance, in some embodiments, the forwarding plane of a TSN-based network of a communication network may be complex. Moreover, based on the profile used in the communication network, different control plane aspects may harmonically co-operate in order to have an integrated functional system. Furthermore, considering operations in a multivendor environment, network verification as an end-end configuration may be applicable in TSN bridges, assuming e.g. that the same features and interfaces are available. Moreover, the device of the first aspect may be able to determine the TSN verification model for such a communication network.

The device of the first aspect may address one or more of the following issues:

● The device may provide a robust and efficient TSN verification mechanism.

● The TSN verification mechanism may find errors before they occur and produce an erroneous data plane.

● The device may avoid negatively affecting an orchestrated end-to-end TSN control plane.

● The device avoid verifying a bad configuration that may affect the overall TSN network performance.

● The device may enable having an end-to-end functional TSN network. For example, such an end-to-end TSN network may consider the TSN flows, pure Layer 2 aspects like VLAN configuration, timing information according to 802.1AS needs, to work or to be configured or to be verified in a harmonized way.

● The TSN verification model may be used to proactively check TSN configuration validity.

● Symbolic abstraction of the resulting data plane and/or the control plane.

● The device may obtain (e.g., derive) a model for unknown control planes.

● The device may obtain a new symbolic language for TSN verification.

● The device may obtain a TSN symbolic language interpreter in the control plane.

● The device may enable to dynamically select the verification module plugin depending on the configuration protocol used.

For example, in a multivendor TSN environment, the validation procedure may be defined, and may further be implemented for a standardized configuration verification method that is vendor-implementation independent. Moreover, the verification mechanism may be used to avoid violating TSN constraints and policies. The TSN verification mechanism may be TSN profile independent, and may be applied in any use case like Industrial Automation or Automotive.

The device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

In an implementation form of the first aspect, the device is further configured to determine a validity of a TSN configuration and/or a change of a TSN configuration based on the TSN verification model of the communication network.

In particular, the device may derive one or more abstract models for both the control plane and the resulting TSN data plane based on a semantic modeling. Further, a validation procedure may be defined for configuration verification. The validation procedure and/or the configuration verification protocol or method may be independent of the vendor-implementation. Further, it may be possible to avoid distributing and enforcing a wrong configuration that may lead the overall network into an instability not only for the node attached. Further, it may be possible to avoid violating TSN constraints or policing, etc. Additionally, the TSN verification mechanism may be independent from the TSN profile and may be applied in any use case such as industrial automation or automotive, etc.

In a further implementation form of the first aspect, the integrated symbolic language comprises information related to the one or more relations between the one or more entities, and/or one or more further relations between the obtained TSN control plane models of the one or more entities.

In a further implementation form of the first aspect, the TSN control plane model of each entity is obtained based on a functionality provided by the entity.

In a further implementation form of the first aspect, the device is further configured to obtain a TSN data plane model for each of the one or more entities of the communication network.

In a further implementation form of the first aspect, the TSN verification model for the communication network is further obtained based on at least one of the TSN data plane models.

In a further implementation form of the first aspect, the TSN verification model for the communication network is further obtained based on the overall TSN data plane model covering the entire network.

In a further implementation form of the first aspect, the device is further configured to receive a verification model of a Layer 2 or a Layer 3 or the TSN operation, from an external library, or from an external tool, update the integrated symbolic language, based on the received verification model, and update the TSN verification model for the communication network, based on the updated integrated symbolic language.

In particular, the device may enable incorporating Layer2, Layer3, or Layer 4 external tools or libraries through symbolic mapping in the TSN verification model. For example, the TSN verification model of the device may consider not only the TSN aspects, network aspect, but also VLAN and Precision Time Protocol (PTP) state, during the verification procedure. For example, the device might not update TSN configuration for a Time Aware Shaper, if the talkers or listeners are not synchronized, or if they cannot communicate together, etc.

In a further implementation form of the first aspect, the device is further configured to analyze the obtained TSN data plane model, update further the TSN verification model for the communication network, based on a result of the analysis.

In a further implementation form of the first aspect, the device is further configured to obtain the TSN verification model for the communication network further based on characteristics of the communication network.

In a further implementation form of the first aspect, the characteristics of the communication network comprise a Virtual Local Area Network (VLAN) state of the communication network during a verification procedure, or a Precision Time Protocol, (PTP) state of the communication network during a verification procedure.

In a further implementation form of the first aspect, the device comprising a Network Configuration Protocol (NETCONF) interface, configured to perform a communication related to the TSN verification model, between the device and at least one entity of the communication network.

In a further implementation form of the first aspect, the device is further configured to derive, when the TSN control plane model of an entity is unknown, a control plane model for the entity, before obtaining the TSN verification model for the communication network.

In a further implementation form of the first aspect, the device is further configured to receive a request for a change of a given TSN configuration, determine a configuration error and configuration quality of the given TSN configuration, based on the integrated symbolic language, and provide a verification result, in particular, whether the change of the given TSN configuration should be admissible or not.

In a further implementation form of the first aspect, the device is further configured to process a rejection error, when the change of the given TSN configuration is determined as inadmissible, and negotiate the rejection error by providing a set of recommendations to a calling function of a TSN configuration verification module.

In particular, the set of recommendations are based on the specific part of the configuration change request that caused the rejection.

In a further implementation form of the first aspect, the device is further configured to verify, based on the TSN verification model of the communication network, verification parameters such as:

● a joint investigation of a TSN configuration with a layer 2 or layer 3 aspect of the communication network,

● a talkers to listeners reachability in the communication network,

● a steady state existence for candidate schedulers under Time-Aware-Shaping or a verification of an asynchronous time shaping operation, or cycling queuing and forwarding,

● a Bounded path length,

● a Bounded delay,

● a preemption capability.

For example, besides the pure TSN features such as scheduled traffic, preemption, path replication, elimination etc., the device may also consider (take into account) for the network configuration mechanism, both the operational and status and the configuration status of pure Layer 2 and also Layer 3 aspects, such as the Talkers/Listeners reachability, VLAN configuration and status, buffer size and runtime backlog, IP addressing in multi-domain setups like also 802.1AS status regarding the time synchronization, etc.

For example, in some embodiments, there may be no need to apply an (e.g., extremely complex) configuration update, if the endpoints are not connected, or there may be no need to apply a new time-aware forwarding rule, if an Access List (ACL) is blocking the traffic flow, etc.

In a further implementation form of the first aspect, the device is incorporated in:

● a centralized network controller (CNC) , or

● a software defined networking (SDN) controller, or

● a TSN aware device, or

● a TSN bridge.

For example, the device may obtain the TSN verification model for a fully centralized and the hybrid control plane case as described in 802.1Qcc. The device may apply the same principles in the case of a fully distributed TSN control plane as described in 802.1Qdd.

In some embodiments, the device may be incorporated in a CNC. Furthermore, according to 802.1Qcc, a set of TSN features may be configured by the CNC such as credit-based shaper algorithm, frame preemption, scheduled traffic, per-stream filtering and policing, cyclic queuing and forwarding, etc., which may be considered by the device, for example, by the verification model of the device or for determining a validation of a TSN configuration.

In some embodiments, the device may determine the validity of a TSN configuration. For example, the device may determine a “bad” TSN configuration as invalid. As an example, a bad configuration may affect the overall TSN network performance, since the interdependencies are extremely complex and not trivial to be investigated without an automated verification mechanism. Note that the case also exists for a “bad” configuration to be interpreted as correct, be accepted and applied with static configuration analysis, if it respects, for example, the YANG model of a device. However, it could lead to instability. For example, if for large diameter networks preemption is introduced at every step, then packets are arriving out of sync, statistical multiplexing cannot be controlled and performance guarantees by means of delay or jitter cannot be controlled. As another example in 802.1AS operation regarding time synchronization that is necessary for 802.1Qbv functionality, if the SynAnnounceInterval value is different on two endpoints of a connection, the configuration tool that only checks the semantics according to the YANG will fail to perform this check.

A second aspect of the disclosure provides a device for supporting a TSN, the device being configured to determine a TSN control plane model for each of one or more TSN bridges of a communication network, obtain a symbolic language for each of the one or more TSN bridges of the communication network, based on their respective TSN control plane models, and obtain a distributed TSN verification model for the communication network distributed on two or more TSN bridges, based on the respective symbolic languages of the two or more TSN bridges.

In the case of a distributed TSN control plane the verification device may enable a global view. Further, in-Band verification in a designated TSN device like a bridge or a switch may be applied in the fully distributed case.

Furthermore, in some embodiments, a new process with a TSN designated switch for verification may be provided for the device of the first aspect or the device of the second aspect, for example, the TSN verification may be based on a feedback loop. For instance, the feedback loop may be, if the verification result is negative, the device of the first aspect or the device of the second aspect may specify a new interface to trigger new events to update, correct, or improve the configuration through a feedback loop with the TSN control plane.

The device of the second aspect may be similar or identical to the device of the first aspect. The device of the second aspect achieves the advantages and effects described for the device of the first aspect.

In an implementation form of the second aspect, in a fully distributed TSN control plane, the device is further configured to perform a verification procedure based on the distributed TSN verification model, when being selected as a designated verification TSN bridge with logical global view.

A third aspect of the disclosure provides a method for time-sensitive networking, the method comprising determining a TSN control plane model for each of one or more entities of a communication network, obtaining a symbolic language for each of the one or more entities of the communication network, based on their respective TSN control plane models, obtaining an integrated symbolic language for the communication network, based on the symbolic language of the one or more entities, wherein the integrated symbolic language is indicative of one or more relations between the one or more entities in the communication network, and obtaining a TSN verification model for the communication network, based on the integrated symbolic language.

In an implementation form of the third aspect, the method further comprises determining a validity of a TSN configuration and/or a change of a TSN configuration based on the TSN verification model of the communication network.

In a further implementation form of the third aspect, the integrated symbolic language comprises information related to the one or more relations between the one or more entities, and/or one or more further relations between the obtained TSN control plane models of the one or more entities.

In a further implementation form of the third aspect, the TSN control plane model of each entity is obtained based on a functionality provided by the entity.

In a further implementation form of the third aspect, the method further comprises obtaining a TSN data plane model for each of the one or more entities of the communication network.

In a further implementation form of the third aspect, the TSN verification model for the communication network is further obtained based on at least one of the TSN data plane models.

In a further implementation form of the third aspect, the method further comprises receiving a verification model of a Layer 2 or a Layer 3 or the TSN operation, from an external library, or from an external tool, updating the integrated symbolic language, based on the received verification model, and updating the TSN verification model for the communication network, based on the updated integrated symbolic language.

In a further implementation form of the third aspect, the method further comprises analyzing the obtained TSN data plane model, and updating further the TSN verification model for the communication network, based on a result of the analysis.

In a further implementation form of the third aspect, the method further comprises obtaining the TSN verification model for the communication network further based on characteristics of the communication network.

In a further implementation form of the third aspect, the characteristics of the communication network comprise (e.g., not only TSN aspects but also) VLAN state of the communication network during a verification procedure, or a PTP state of the communication network during a verification procedure.

In a further implementation form of the third aspect, the method further comprises performing, by an NETCONF interface, a communication related to the TSN verification model, between the device and at least one entity of the communication network, for the case of fully centralized and hybrid control plane.

In a further implementation form of the third aspect, the method further comprises deriving, when the TSN control plane model of an entity is unknown, a control plane model for the entity, before obtaining the TSN verification model for the communication network.

In a further implementation form of the third aspect, the method further comprises receiving a request for a change of a given TSN configuration, determining a configuration error and configuration quality of the given TSN configuration, based on the integrated symbolic language, and providing a verification result, in particular, whether the change of the given TSN configuration should be admissible or not.

In a further implementation form of the third aspect, the method further comprises processing a rejection error, when the change of the given TSN configuration is determined as inadmissible, and negotiating the rejection error by providing a set of recommendations to a calling function of a TSN configuration verification module.

In a further implementation form of the third aspect, the method further comprises verifying, based on the TSN verification model of the communication network, verification parameters such as:

● a talkers to listeners reachability in the communication network,

● a Bounded path length,

● a Bounded delay,

● a preemption capability.

In a further implementation form of the third aspect, the method is for

● a CNC, or

● a SDN controller, or

● a TSN aware device, or

● a TSN bridge.

The method of the third aspect achieves the advantages and effects described for the device of the first aspect.

A fourth aspect of the disclosure provides a method for time-sensitive networking, the method comprising determining a TSN control plane model for each of one or more TSN bridges of a communication network, obtaining a symbolic language for each of the one or more TSN bridges of the communication network, based on their respective TSN control plane models, and obtaining a decentralized TSN verification model for the communication network distributed on two or more TSN bridges, based on the respective symbolic languages of the two or more TSN bridges.

In an implementation form of the fourth aspect, in a fully distributed TSN control plane, the method further comprises performing a verification procedure based on the distributed TSN verification model, when being selected as a designated verification TSN bridge with logical global view.

The method of the fourth aspect achieves the advantages and effects described for the device of the second aspect.

A fifth aspect of the present disclosure provides a computer program comprising a program code for performing the method according to the third aspect or fourth aspect or any of their implementation forms.

A sixth aspect of the present disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the third aspect or fourth aspect or any of their implementation forms to be performed.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a device for supporting a TSN operation, according to an embodiment of the disclosure;

FIG. 2 shows another device for supporting a distributed TSN control plane, according to an embodiment of the disclosure;

FIG. 3 a schematic view of a diagram illustrating the TSN verification module based on a software element that is inside a CNC;

FIG. 4 a schematic view of a diagram illustrating multi-vendor control plane integration;

FIG. 5 a schematic view of a flowchart of a procedure for creating an abstract control plane model for an entity;

FIG. 6 is a schematic view of a diagram illustrating a model construction;

FIG. 7 a schematic view of a diagram illustrating a multilayer verification procedure;

FIG. 8 a schematic view of a diagram illustrating verification module deployment for fully distributed TSN control plane;

FIG. 9 a schematic view of a diagram illustrating addition of the verification model implemented as an extension over the 802.1dj;

FIG. 10 shows a method for supporting a TSN operation, according to an embodiment of the disclosure; and

FIG. 11 shows another method for supporting a distributed TSN operation, according to an embodiment of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a device 100 for supporting a TSN configuration verification operation, according to an embodiment of the disclosure.

The device 100 is configured to determine a TSN

control plane model

101, 102, 103 for each of one or

more entities

11, 12, 13 of a communication network 1. For example, the communication network 1 may comprise the one or

more entities

11, 12, and 13.

The device 100 is further configured to obtain a

symbolic language

111, 112, 113 for each of the one or

more entities

11, 12, 13 of the communication network 1, based on their respective TSN

control plane models

101, 102, and 103.

The device 100 is further configured to obtain an integrated symbolic language 120 for the communication network 1, based on the

symbolic language

111, 112, 113 of the one or

more entities

11, 12, 13, wherein the integrated symbolic language 130 is indicative of one or more relations between the one or

more entities

11, 12, 13 in the communication network 1.

The device 100 is further configured to obtain a TSN verification model 130 for the communication network 1, based on the integrated symbolic language 120.

The TSN verification model 130 of the device 100 may be obtained irrelevant of the distributed protocol used, or even if the centralized case is implemented. Further, the verification model of the device may easily be integrated into the existing configuration mechanisms proposed like defined in 802.1Qcc or/and 802.1Qdd. The device may verify not only TSN attributes, but all the components that need to be in the correct state, in order to have an end-to-end functional TSN network.

Further, the integrated symbolic language 120 and/or the verification model 130 of the device 100 may enable a verification of large instances of combinational search problems for hardware and software verification, for example, with semantic modeling based on the SAT and Satisfiability Modulo Theories (SMT) .

Moreover, the device 100 may avoid distributing a wrong configuration that may lead to the overall network instability.

The integrated symbolic language 120 and/or the verification model 130 of the device 100 may also be extended to cover multi-domain verification procedures.

The device 100 may comprise a processing circuitry (not shown in FIG. 1) configured to perform, conduct or initiate the various operations of the device 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device 100 to perform, conduct or initiate the operations or methods described herein.

FIG. 2 shows another device 200 for supporting a distributed TSN control plane operation, according to an embodiment of the disclosure.

The device 200 is configured to determine a TSN

control plane model

201, 202, 203 for each of one or more TSN bridges 21, 22, and 23 of a communication network 1. For example, the communication network 1 may comprise the device 200 and the one or more TSN bridges 21, 22, 23. Further, the device 200 may have a global view and the one or more TSN bridges 21, 22, 23 may have a local view.

The device 200 is further configured to obtain a

symbolic language

211, 212, 213 for each of the one or more TSN bridges 21, 22, 23 of the communication network 1, based on their respective TSN

control plane models

201, 202, 203.

The device 200 is further configured to obtain a distributed TSN verification model 230 for the communication network 1 distributed on two or more TSN bridges 21, 22, 23, based on the respective

symbolic languages

201, 202, 203 of the two or more TSN bridges 21, 22, 23.

The device 200 may be similar or identical to the device 100 and may have similar or identical functions.

The device 200 may comprise a processing circuitry (not shown in FIG. 2) configured to perform, conduct or initiate the various operations of the device 200 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device 200 to perform, conduct or initiate the operations or methods described herein.

Reference is now made to FIG. 3 which is a schematic view of the device 100 obtaining the TSN verification model 130 based on a software element that is inside a CNC.

FIG. 3 illustrates an architecture of the device 100 obtaining the TSN verification model 130, for example, for both the hybrid and fully centralized case, the verification model 130 may be obtained by a verification module that is incorporated as a software element inside the CNC.

The verification module of the device 100 is communicating through a management interface 304 (e.g., Netconf) with a local verification module agent 311 of a local agent 311 in every TSN-enabled 802.1 bridge 310, either periodically or on an event basis, in order to retrieve operational state information regarding information such as port status, link status, ptp status, vlan information, queuing dynamics, etc.

The local agent 311 may operate inside the IEEE TSN Bridge 310. The local agent 311 may run at each bridge used to offload the CNC. The local agent 311 may be used to minimize communication overhead, between the CNC and the TSN bridges for all the operational and configuration data that is required. Further, local processing may be performed when applicable.

The device 100 (e.g., the verification module of the device 100) may have the following functionalities.

The device 100 may obtain (e.g., derive) an abstract model of the control plane for every TSN device in the communication network 1. This function may be different in a multi-vendor environment. Moreover, the device 100 may determine a

symbolic language

111, 112, 113 based on the

control plane model

101, 102, 103 for every TSN device in the network.

The device 100 may further obtain (e.g., determine) an integrated symbolic language 120 to answer end-to-end queries and also capture interdependencies.

The device 100 may further derive an interface to third party tool that may be able to perform Layer2/Layer3 verification such as Minesweeper, Batfish, SymNet or Veriflow. Moreover, the TSN verification module of the device 100 may focus, in real-time, on the TSN aspects, but may incorporate this information to conclude the final verification result.

The device 100 may further obtain (e.g., create) abstract model of the resulting data plane 301, 302, 303 responsible for the actual forwarding, based on the

control plane model

101, 102, 103, and the requested configuration.

Furthermore, upon a request for configuration update, depending on the result of the verification process, a set of return codes may be provided that may describe different scenarios as follows:

a) no error or poor performance is evident-the configuration can be accepted and applied.

b) an error is found -the configuration must be is rejected.

c) no error is found, but the resulting data plane will have poor performance.

Moreover, in the case of configuration update rejection, a set of suggestions to the calling function of the configuration verification module may be provided.

Next, the device 100 is exemplarily discussed based on the 802.1Qcc amendment (generally known) and its three configuration options that have been described for the TSN networks including the 802.1Qcc for the centralized model, and the 802.1Qdd for the fully distributed case.

For the centralized configuration model there are two subcases as follows:

Case 1: fully centralized: in this case the Talkers and Listeners are communicating with CUC entity to describe traffic requirements. In this case, a protocol like PTCC or Restconf or Netconf etc., may be used together with the 802.1Qdj to pass the information to the CNC entity.

Case 2: A User to Network Interface (UNI) (enhanced SRP) may be used to pass the traffic requirements and the relevant Talkers/Listeners information though the edge bridge to the CNC.

After the traffic requirements are specified and collected, they are further passed to the CNC. In the CNC together with other control procedures or information (for example, topology information) , the TSN scheduling decisions are made, for example, by a TSN Scheduling software entity. However, instead of ad-hoc deploying the scheduling decision, the verification module may determine, if the configuration request should be admitted or not.

In particular, the device 100 may take into account the procedures that the verification process is carried out. In other words, the procedure that the relevant information is passed to the control entity, or the scheduling decision is decided, might not be considered.

Reference is now made to FIG. 4, which is a schematic view of a diagram illustrating multi-vendor control plane integration.

The multi-vendor control plane integration may be performed by the device 100 and/or the device 200. In the following, the multi-vendor control plane integration is discussed as a process that is performed by the device 100.

For example, the device 100 may derive the control plane models, upon the verification module initialization process.

As a first step during the initialization phase, an abstract model for the

TSN control plane

101, 102, 103 of every

device

11, 12, 13 is derived, based on the TSN features or the capabilities that support. An example of such a procedure is discussed with respect to FIG. 5.

Furthermore, although TSN working group of the IEEE802.1 specifies explicitly the TSN managed objects and Management Information Base (MIBs) , however, every vendor may have its own model, may further use its own semantics and implementation that might not completely be aligned with the standards definition.

Moreover, in order to perform an end-to-end configuration verification, when operating over a multi-vendor TSN network, the device 100 may initially obtain (e.g., generate) an model for the

control plane

101, 102, 103 for each

TSN bridge device

11, 12, and 13.

Next, a symbolic modeling step may be performed that may be followed by an integration step. The device 100 obtains the

symbolic language

111, 112, 113 for the entities (device 11, device 12, and device 13 in FIG. 4) of the communication network 1, based on their respective TSN

control plane models

101, 102, and 103. Furthermore, the device 100 may eventually derive an integrated end-to-end control plane model 401 and a corresponding integrated symbolic language 120.

Reference is now made to FIG. 5, which is a schematic view of a flowchart of a procedure 500 for creating a control plane model for an entity.

The procedure 500 may be performed by the device 100 and/or the device 200. In the following, the procedure 500 is exemplary discussed being performed by device 100.

At step 501, the device 100 or the device 200 starts the verification initialization phase for each entity. The entities may be, for example, TSN bridges.

At step 502, the device 100 or the device 200 may determine, whether a control plane of an entity is known or not. Further, when it is determined “No” , the device 100 or the device 200 goes to step 503. Moreover, when it is determined “Yes” , the device 100 or the device 200 goes to step 504.

At step 503, the device 100 or the device 200 applies a model learning technique for deriving the control plane model of an entity.

For instance, when the control plane of an entity is unknown, for example, when no YANG models can be used to model the operation of the TSN device. The device 100 or the device 200 may consider the entity as a black box. Then, it may apply a model learning technique for deriving the control plane model. For example, the device 100 or the device 200 may apply a learning algorithms like Lstar to create the unknown state diagrams, by sending input queries to the entity and analyzing the output. Furthermore, from the learning procedure, three cases also describe the relationship with the TSN standards including when the implementation is fully aligned, or when the implementation not aligned, or the implementation is partially aligned.

At step 504, for example, when the control plane model is known or when the device 100 or the device 200 derived the control plane (e.g., at step 503) .

At step 505, the device 100 or the device 200 obtains (e.g., design) a symbolic language based on the control plane model.

For example, after the model is derived at step 504, for every TSN entity in the communication network, the device 100 or the device 200 may construct a symbolic language model which may be defined as a set of attributes, rules, constraints, etc.

Generally, the symbolic language modeling may comprise a set of symbols (variables) that may represent data types, attributes, or actions. Moreover, irrelevant of the used management protocol (e.g., Netconf, Restconf, SNMP) , to retrieve control plane information, the device 100 or the device 200 may define the mechanism to translate configuration parameters and attributes to variables based on symbolic modeling.

Furthermore, the device 100 or the device 200 may perform an integration process to integrate the symbolic languages to an end-to-end symbolic model of the control plane, and by further use if by the configuration verification module that may process these rules on configuration-received events. For example, the symbolic language may be used to perform queries and be part of a verification FSM execution process.

Further, there may be three cases as follows:

● When a control plane model of an entity is consistent with the actual implementation of a subset (or a full set) of TSN standards or amendments, the device 100 goes to step 506 and marks the abstract model of the control plane as fully aligned.

● A control plane model of an entity is partially aligned with the set of TSN standards-amendments. For example, maybe 802.1CB is supported, but a custom preemption procedure or a customized queueing structure is followed, the device 100 goes to step 507 and marks the abstract model of the control plane as partially aligned.

● A control plane model of an entity is not aligned with the set of TSN standards-amendments, the device 100 goes to step 508 and marks the abstract model of the control plane as not aligned.

Next, an analysis of the control plane model and the symbolic language model for each entity is discussed.

In some embodiments, after the control plane model is derived and analyzed for each device, the device 100 or the device 200 may devise a TSN symbolic language according to that model. The symbolic modeling may also be used to model dependencies, data plane constraints, and TSN properties. For example, symbolic modeling can be used to parse received TSN configuration instructions as arguments to logical formulas. E.g.: IPs × ports× IPd × portd× schedule_entry_feasible → {true, false} .

Reference is now made to FIG. 6, which is a schematic view of the diagram 600 illustrating a model construction. The model construction may be performed by the device 100 or the device 200.

In block 601 of the diagram 600, the YANG part describes the GCL information, according to 802.1Qcw needed by 802.1Qbv. As can be taken from the block 601, the YANG part specifies that the sgs information is required, the relevant gate operation is described by “gate-status-value” , and the gate period is described by the “time-interval-value” .

In block 602 of the diagram 600, a vendor-specific model is provided indicating that the 802.1Qbv is supported, where for the GCL, entry gate is an operation that is described by field “gate” , and the respective period by field “time” .

The verification module of the device 100 or the device 200 may compare the two files obtained based on the TSN standard models 603 and the TSN vendor models 604, and may further make reasoning decisions, in order to identify which parts of the device model are following the standard description. In this case, the SRS is supported and can be part of the device model (although different naming is used by the vendor-specific implementation) , however, the shm and the srm are not supported. Furthermore, all the results of all comparison, together with additional methods that capture dependencies and constraints, are part of a TSN symbolic model 605 where symbolic variables are designed based on the standard description and the results of the comparison. For example, a Boolean variable x1 can be introduced to describe whether a preemption support exists or not.

In the previous step, a symbolic model is derived for each

entity

11, 12, and 13. Furthermore, after the symbolic models have been derived for all entities, in the following step, an integrated verification symbolic language may be constructed that may capture also the dependencies between devices or the models, in order to perform end-to-end verification testing.

In order to perform the verification testing, the device 100 or the device 200 may consider one or more of the following inputs:

● Integrated control plane symbolic model.

● Configuration data (TSN and other information related for example to ACLs) .

● Configuration to be applied (configuration data like the Scheduler decision to be applied, Talker requirements, etc. )

● Operational data (statistics, other Layer2/Layer3 information like VLAN status or PTP information about time synchronization) .

Moreover, the device 100 or the device 200 may also consider operational data input (e.g., port is synchronized, VLAN is set, listener is reachable, etc. ) . Furthermore, as a part of the integrated symbolic model, the device 100 or the device 200 may capture dependency issues, for example, an interface may have an active PTP instance, if Time Aware Shaper is used. As another example, if an ACL is applied in one switch, then the traffic will be blocked. Further, it doesn’ t make sense to update a switch’s many hops away that is unaware of this.

Moreover, the device 100 or the device 200 may also use the data plane constraint and TSN properties as a part of the integrated symbolic model.

Reference is now made to FIG. 7, which is a schematic view of the diagram 700 illustrating a multilayer verification procedure. The multilayer verification may be performed by the device 100 or the device 200. In the following, the multilayer verification procedure is exemplary discussed as a procedure that is performed by the device 100, without limiting the present disclosure.

For instance, the device 100 may comprise the TSN configuration module, the integrated symbolic language 120 and the TSN verification model 130.

Furthermore, the device 100 may use the configuration and operational data that are needed by the integrated TSN symbolic model (like reachability information, path existence, and node status which are not part of the TSN standard set, but are required for smooth operation) .

The device 100 may wire the TSN verification module to other verification mechanisms that are already available, to perform pure Layer 2, Layer 3, and higher layer verification operations such as Minesweeper, Batfish, SymNet, Veriflow, etc. Moreover, there may be a layer 2 network verification toolbox 701, a layer 3 network verification toolbox 702, and a layer 4 network verification toolbox 703.

Moreover, the device 100 may use a

respective mapper

711, 712, 713 to map each of the layer 2 network verification toolbox 701, the layer 3 network verification toolbox 702, and the layer 4 network verification toolbox 703, to its TSN configuration verification module. For each tool used, a mapping function is responsible to augment the integrated end-to-end symbolic model with the information provided by external verification tools or libraries. Furthermore, with this procedure, the device 100 may ask queries that span many layers of the protocol stack using a single API. The device 100 may also consider exposing a verification module interface that may allow performing queries from external management or control entities to the verification module on full or partial parts of the integrated symbolic model.

Moreover, when the device 100 determines a verification, for example, when a verification decision is to be taken, the decision-making process takes also into account higher layers status.

Note that through the mapping function between the TSN module and the external libraries the device may quickly verify that a network satisfies a wide range of intended properties such as reachability or isolation among nodes, waypoints, black holes, bounded path length, load-balancing, the functional equivalence of two forwarding devices, etc. These properties may be used to quickly verify interacting aspects between TSN and higher layers.

In some embodiments, the device 100 or the device 200 may perform a verification operation or a symbolic checking.

For example, a configuration change or an update request (either through enhanced SRP in the case of hybrid or through CUC in the case of fully distributed through protocols like PTCC) may trigger the necessary verification module operations like communication in order to retrieve operational state, symbolic modeling queries execution and reasoning and actions like drop, apply or optimize the configuration update requested.

For instance, the device 100 or the device 200 may proactively analyze the resulting data plane which may reflect the combined impact of all configuration aspects. In particular, the device 100 or the device 200 may construct a set of TSN data plane models, based on the control plane models and the actual configuration to be applied. Afterwards, the device 100 or the device 200 may determine, based on a set of queries execution and assessment checking, if a configuration is admissible or not. For example, semantic modelling may be used to verify configuration errors, bad configuration, policy violations, but also potential security threads. The device 100 or the device 200 may further find errors before the TSN network produces and distributes erroneous data planes.

Moreover, the device 100 or the device 200 may translate the received configuration into a set of semantic logical formulas. For instance, the device 100 or the device 200 may captures the stable states to which the TSN data plane may converge (if convergence exists) as a result of interactions between TSN enabled devices like switches, gateways and endpoints. Moreover, the device 100 or the device 200 may further translate the TSN messaging received regarding configuration instructions into a logical formula such as:

IPs × ports× IPd × portd× schedule_entry_feasible → {true, false} .

The logical formula may also consider dependencies and constraints, and may further incorporate policies. For example, if the combined formula can be satisfied, there exists a stable state of the network. Otherwise, no stable state exists and the configuration should be rejected (or updated) .

Moreover, the device 100 or the device 200 may generate a request to perform symbolic checking for a configuration change or an update. For example, the device 100 or the device 200 may traverses, based on the verification model, only the states and the part of the network that are affected by the change, rather than investigating all the possible states. For example, if there is a plan to update 802.1Qbv operations, 802.1Qbu might not be affected, however, if there is a plan to update 802.1Qci, it can be affected, since a stream may be completely blocked.

For the checking phase, the device 100 or the device 200 may consider the relevant parts of the verification model which may be described as deterministic Mealy machines. A Mealy machine is a finite-state machine whose output values are determined both by its current state and the current inputs.

The device 100 or the device 200 may identify a number of potential verification results as follows:

● Accept (mandatory) : the configuration is accepted as is and it can be applied to the running configuration.

● Reject (mandatory) : the configuration is rejected with the report on errors, or potential performance degradation factors found and verification findings.

● Negotiate (optional) : in this case, specific problematic parts of the configuration are identified for specific entities.

● These results may be communicated back to the calling function residing, for example, CUC.

Next the negotiation module is discussed. In addition to “accept” and “reject” device 100 or the device 200 may consider one more function to trigger negotiation of parameters values to avoid performance degradation. In this case inside the verification module, a negotiation function is called considering tools like SMT/SAT to investigate for potential workarounds in order to optimally tune parameters that will lead to performance degradation or will cause erroneous data plane. In this case, the TSN Verification Module mechanism creates a feedback loop. If the verification result is negative, the invention devices a new interface to trigger new events form the verification module to update/correct/improve configuration through a feedback loop with the TSN control plane. Since the verification process is extremely complex the negotiation module relies on the findings of the main verification activity, in order to gradually fine-tune parametrization rather than starting again a verification process from scratch.

Reference is now made to FIG. 8, which is a schematic view of a diagram illustrating verification module deployment for fully distributed configuration.

For example, the device 200 may perform the TSN verification for a fully distributed TSN control plane.

The verification module may need having a global view of the TSN network. In the case of centralized and hybrid mode, for example, the device 100 may use out-of-Band verification in the external CNC (controller) entity. In the fully distributed case, such as the 802.1Qdd RAP/LRP protocol, the device 200 may use in-Band verification. For example, the device 200 may assign a designated TSN verification switch. Further, the device 200 may specify a new protocol to elect the TSN designated switch used for verification.

In FIG. 8, the device 200 is based on a TSN bridge with a global view. Further, the

entities

21, 22, and 23 are based on TSN bridges with a local view.

For instance, the device 200 may use a designated spanning-tree elected according to Spanning Tree Protocol (STP) operations switch as a designated verification bridge.

In the case that the STP is enabled and is responsible for the forwarding graph establishment, a bridge id priority may be used to elect the root bridge. Furthermore, the verification module may just be installed and may further run on the elected STP root bridge. A similar process may be performed for variations of the STP such as the MSTP, and the RSTP. For example, the root bridge may control the spanning-tree topology and may be the hub for connecting the other switches by establishing logical adjacencies with all switching entities on the network to provide global view information. The relevant information passing between the root verification module (e.g., the device 200 with the global view) with different local verification agents deployed at each bridge is done over LRP/RAP as an additional application on top or LRP.

At next, an example of abstract model construction is discussed which may be performed by the device 100 or the device 200.

For example, the device 200 may specify an abstract control plane model for every TSN bridge based on the data types and the implemented methods. In particular, the device 200 may use a step by step process following answering queries as follows:

At first, the device 200 determines whether which managed object definitions and encodings according to TSN standards the implementation supports like frame preemption according to 802.1Qbu, scheduled traffic according to 802.1Qbv, Frame Replication and Elimination according 802.1CB etc.

To this end, the device 200 performs an exhaustive recursive investigation for analyzing the TSN control plane. Moreover, the device 200 may further construct the abstract symbolic model based on the YANG definitions (like IEEE 802.1Qcp YANG Model for Bridging, IEEE 802.1Qcw YANG Model for Qbv, Qbu, Qci) and by transforming attributes to symbolic variables.

For example, the device 200 may obtain a sample of frame-preemption-parameters, from 802.1Qcw, as follows:

● uint32 hold-advance //r

● uint32 release-advance //r

● boolean preemption-active //r

● enum hold-request //r

The obtained abstract model may have a symbol bridg_id_preemption_active, while the integrated symbolic language may specify a method F (bridge1_preemption_active, bridge2_preemption_active, etc) to verify whether the preemption is enabled end-to-end? .

Reference is now made to FIG. 9 which is a schematic view of a diagram illustrating addition of the verification model implemented as an extension over the 802.1dj.

The verification model may be implemented by the device 100 and/or the device 200. For example, in the case of the 802.1Qcc, the verification module of the device 100 or the verification module of the device 200 as a newly added feature as +---x verification configuration indicated with the reference 902. By adding verification capability to CNC and exposing through 802.1Qdj, the verification process can be called by CUC.

FIG. 10 shows a method 1000 according to an embodiment of the disclosure for time-sensitive networking. The method 1000 may be carried out by the device 100, as it is described above.

The method 1000 comprises a step 1001 of determining a TSN

control plane model

101, 102, 103 for each of one or

more entities

11, 12, 13 of a communication network 1.

The method 1000 further comprises a step 1002 of obtaining a

symbolic language

111, 112, 113 for each of the one or

more entities

11, 12, 13 of the communication network 1, based on their respective TSN

control plane models

101, 102, 103.

The method 1000 further comprises a step 1003 of obtaining an integrated symbolic language 120 for the communication network 1, based on the

symbolic language

111, 112, 113 of the one or

more entities

11, 12, wherein the integrated symbolic language 130 is indicative of one or more relations between the one or

more entities

11, 12, 13 in the communication network 1.

The method 1000 further comprises a step 1004 of obtaining a TSN verification model 130 for the communication network 1, based on the integrated symbolic language 120.

FIG. 11 shows a method 1100 according to an embodiment of the disclosure for time-sensitive networking. The method 1100 may be carried out by the device 200, as it is described above.

The method 1100 comprises a step 1101 of determining a TSN

control plane model

201, 202, 203 for each of one or more TSN bridges 21, 22, 23 of a communication network 1.

The method 1100 further comprises a step 1102 of obtaining a

symbolic language

control plane models

201, 202, 203.

The method 1100 further comprises a step 1103 of obtaining a distributed TSN verification model 230 for the communication network 1 distributed on two or more TSN bridges 21, 22, 23, based on the respective

symbolic languages

201, 202, 203 of the two or more TSN bridges 21, 22, 23.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

A device (100) for supporting a time-sensitive network, TSN, operation; the device (100) being configured to:

determine a TSN control plane model (101, 102, 103) for each of one or more entities (11, 12, 13) of a communication network (1) ;

obtain a symbolic language (111, 112, 113) for each of the one or more entities (11, 12, 13) of the communication network (1) , based on their respective TSN control plane models (101, 102, 103) ;

obtain an integrated symbolic language (120) for the communication network (1) , based on the symbolic language (111, 112, 113) of the one or more entities (11, 12, 13) , wherein the integrated symbolic language (130) is indicative of one or more relations between the one or more entities (11, 12, 13) in the communication network (1) ; and

obtain a TSN verification model (130) for the communication network (1) , based on the integrated symbolic language (120) .
The device (100) according to claim 1, further configured to:

determine a validity of a TSN configuration and/or a change of a TSN configuration based on the TSN verification model (130) of the communication network (1) .
The device (100) according to claim 1 or 2, wherein:

the integrated symbolic language (120) comprises information related to the one or more relations between the one or more entities (11, 12, 13) , and/or one or more further relations between the obtained TSN control plane models (101, 102, 103) of the one or more entities (11, 12, 13) .
The device (100) according to one of the claims 1 to 3, wherein:

the TSN control plane model (101, 102, 103) of each entity (11, 12, 13) is obtained based on a functionality provided by the entity (11, 12, 13) .
The device (100) according to one of the claims 1 to 4, further configured to:

obtain a TSN data plane model (301, 302, 303) for each of the one or more entities (11, 12, 13) of the communication network (1) .
The device (100) according claim 5, wherein:

the TSN verification model (130) for the communication network (1) is further obtained based on at least one of the TSN data plane models (301, 302, 303) .
The device (100) according to one of the claims 1 to 6, further configured to:

receive a verification model of a Layer 2 or a Layer 3 or the TSN operation, from an external library, or from an external tool;

update the integrated symbolic language (120) , based on the received verification model; and

update the TSN verification model (130) for the communication network (1) , based on the updated integrated symbolic language.
The device (100) according to one of the claims 5 to 7, further configured to:

analyze the obtained TSN data plane model, and

update further the TSN verification model (130) for the communication network (1) , based on a result of the analysis.
The device (100) according to one of the claims 1 to 8, further configured to:

obtain the TSN verification model (130) for the communication network (1) further based on characteristics of the communication network (1) .
The device (100) according to claim 9, wherein:

the characteristics of the communication network (1) comprises:

a Virtual Local Area Network, VLAN, state of the communication network (1) during a verification procedure, or

a Precision Time Protocol, PTP, state of the communication network (1) during a verification procedure.
The device (100) according to one of the claims 1 to10, comprising:

a Network Configuration Protocol, NETCONF, interface (304) , configured to:

perform a communication related to the TSN verification model (130) , between the device (100) and at least one entity of the communication network (1) .
The device (100) according to one of the claims 1 to 11, further configured to:

derive, when the TSN control plane model (101, 102, 103) of an entity (11, 12, 13) is unknown, a control plane model for the entity (11, 12, 13) , before obtaining the TSN verification model (130) for the communication network (1) .
The device (100) according to one of the claims 1 to 12, further configured to:

receive a request for a change of a given TSN configuration,

determine a configuration error and configuration quality of the given TSN configuration, based on the integrated symbolic language (120) , and

provide a verification result, in particular, whether the change of the given TSN configuration should be admissible or not.
The device (100) according to claim 13, further configured to:

process a rejection error, when the change of the given TSN configuration is determined as inadmissible; and

negotiate the rejection error by providing a set of recommendations to a calling function of a TSN configuration verification module.
The device (100) according to one of the claims 1 to 14, further configured to:

verify, based on the TSN verification model (130) of the communication network (1) , verification parameters such as:

a joint investigation of a TSN configuration with a layer 2 or layer 3 aspect of the communication network,

a talkers to listeners reachability in the communication network,

a steady state existence for candidate schedulers under Time-Aware-Shaping or a verification of an asynchronous time shaping operation, or cycling queuing and forwarding,

a Bounded path length,

a Bounded delay,

a preemption capability.
The device (100) according to one of the claims 1 to 15, wherein:

the device (100) is incorporated in:

a centralized network controller, CNC, or

a software defined networking, SDN, controller, or

a TSN aware device, or

a TSN bridge.
A device (200) for supporting a time-sensitive network, TSN, operation, the device (200) being configured to:

determine a TSN control plane model (201, 202, 203) for each of one or more TSN bridges (21, 22, 23) of a communication network (1) ;

obtain a symbolic language (211, 212, 213) for each of the one or more TSN bridges (21, 22, 23) of the communication network (1) , based on their respective TSN control plane models (201, 202, 203) ; and

obtain a distributed TSN verification model (230) for the communication network (1) distributed on two or more TSN bridges (21, 22, 23) , based on the respective symbolic languages (201, 202, 203) of the two or more TSN bridges (21, 22, 23) .
The device (200) according to claim 17, wherein:

in a fully distributed TSN control plane, the device (200) is further configured to perform a verification procedure based on the distributed TSN verification model (230) , when being selected as a designated verification TSN bridge with logical global view.
A method (1000) for time-sensitive networking, the method (1000) comprising:

determining (1001) a TSN control plane model (101, 102, 103) for each of one or more entities (11, 12, 13) of a communication network (1) ;

obtaining (1002) a symbolic language (111, 112, 113) for each of the one or more entities (11, 12, 13) of the communication network (1) , based on their respective TSN control plane models (101, 102, 103) ;

obtaining (1003) an integrated symbolic language (120) for the communication network (1) , based on the symbolic language (111, 112, 113) of the one or more entities (11, 12), wherein the integrated symbolic language (130) is indicative of one or more relations between the one or more entities (11, 12, 13) in the communication network (1) ; and

obtaining (1004) a TSN verification model (130) for the communication network (1) , based on the integrated symbolic language (120) .
A method (1100) for time-sensitive networking, the method (1100) comprising:

determining (1101) a TSN control plane model (201, 202, 203) for each of one or more TSN bridges (21, 22, 23) of a communication network (1) ;

obtaining (1102) a symbolic language (211, 212, 213) for each of the one or more TSN bridges (21, 22, 23) of the communication network (1) , based on their respective TSN control plane models (201, 202, 203) ; and

obtaining (1103) a distributed TSN verification model (230) for the communication network (1) distributed on two or more TSN bridges (21, 22, 23) , based on the respective symbolic languages (201, 202, 203) of the two or more TSN bridges (21, 22, 23) .
A computer program which, when executed by a computer, causes the method (1000) of claim 19 or the method (1100) of claim 20 to be performed.