CN115699696A - Support device for Time Sensitive Network (TSN) operation using TSN configuration verification - Google Patents

Abstract

The present invention relates to an apparatus for supporting Time Sensitive Network (TSN) configuration verification operations. 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 based on the respective TSN control plane model of the one or more entities of the communication network. The device also obtains an integrated symbolic language of the communication network based on the symbolic languages of the one or more entities, wherein the integrated symbolic language indicates one or more relationships between the one or more entities in the communication network. Further, the device obtains a TSN verification model for the communication network based on the integrated symbolic language. The invention can be applied to the case of centralized, hybrid and distributed TSN control planes.

Description

Support device for Time Sensitive Network (TSN) operation using TSN configuration verification

Technical Field

The present invention relates generally to the field of communication networks, and in particular to time-sensitive networks (TSNs), in particular IEEE TSNs. To this end, the present invention provides an apparatus and method for supporting TSN operation. The apparatus and method may perform TSN configuration verification based on a semantic modeling process. For example, the apparatus and/or methods of the present invention may obtain an integrated symbol language for a communication network. Further, the apparatus and/or method may obtain a TSN verification model for a communication network based on an integrated notation language for the communication network.

Background

Typically, some communication networks are based on TSNs, e.g., such communication networks may use TSN technology, e.g., having one or more requirements to transmit data.

For example, conventional devices provide TSN extensions to enhance the forwarding plane of conventional bridges to provide deterministic performance through not only throughput, but also delay and jitter.

Furthermore, TSN operation may address transmissions with 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, with the transmission scheduling algorithm controlling the transmission gates in a time-triggered process. Furthermore, using an optimal scheduling algorithm to control the transmission gates, frames can be transmitted at precise times, reducing latency due to blocking to the nanosecond level, and also ensuring low delay variation.

Further, some devices and methods may provide TSN control plane functionality. Three methods of providing the TSN control plane are discussed below.

Conventional approaches are based on a fully centralized approach, where the TSN bridge is controlled by a Centralized Network Control (CNC) entity and the endpoints are controlled by a Centralized User Controller (CUC).

Conventional approaches are based on configurations using fully distributed protocols. Development of a fully distributed method is currently in progress to design a Resource Allocation Protocol (RAP) using Link Registration Protocol (LRP) underlying transport.

The conventional method is based on: CNC is used to take care of the configuration and control of the TSN bridge and hybrid mode using a User Network Interface (UNI) to connect endpoints to the access bridge.

Furthermore, for the last case of using the hybrid control plane mode, stream Reservation Protocol (SRP) enhancements are also proposed to support TSN functionality that can be used for advertising stream properties, for example. Furthermore, some TSN profiles have been specified based on the application domain, for example, to illustrate which standards, protocols, features, and options should be applied for a given use case. Such conventional TSN profiles are proposed, for example, for TSN profiles for audio or video bridging, for industrial automation, for automotive on-board ethernet communications, for mobile fronthaul networks, for service provider networks, and the like.

However, conventional TSN-based devices and methods are implemented using static and customized configurations and are only aligned with a standard when the Management Information Base (MIB) is identical to that defined in the standard. Furthermore, there is no standard related activity with respect to TSN configuration verification. For example, for the fully distributed case, there is no activity related to the relevant verification aspects. Further, in the case of a centralized configuration or a hybrid configuration, the unique validation action performed is based on the relevant YANG model used by management protocols such as Netsconf. For example, for Netconf message reception events, the Netconf messages are analyzed in detail and a YANG model validation is performed to ensure that, for example, the requested operation is supported on the server side and that the patterns and data types described in the messages comply with the YANG model of the device.

Disclosure of Invention

In view of the foregoing problems and disadvantages, embodiments of the present invention are directed to improvements in conventional apparatus and methods for supporting TSN configuration verification operations.

The aim is to determine (e.g. derive) in a simple manner an abstract model of the TSN control plane (control plane) and/or the derived data plane (data plane). In particular, this should be done based on semantic modeling. Another object is to detect TSN network configuration errors, for example by analyzing configuration files and proactively discovering errors. Another object is to inhibit changes that violate policies or may cause degradation in the performance of the communication network. Another object is to check the network-wide variable in real time, for example using a verification model determined by the device. Another objective is to perform a broad range of active control and verification processes through semantic modeling and logical formula checking to describe the states and relationships between them.

The above objects are achieved by embodiments of the invention described in the attached independent claims. Advantageous realizations of embodiments of the invention are further defined in the dependent claims.

A first aspect of the invention provides an apparatus for supporting time-sensitive network operations, the apparatus being configured to: determining a TSN control plane model for each of one or more entities of a communication network; obtaining a symbolic language for each of one or more entities of a communication network based on their respective TSN control plane models; obtaining an integrated symbolic language of the communication network based on the symbolic languages of the one or more entities, wherein the integrated symbolic language indicates one or more relationships 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.

The device may be or may be incorporated in an electronic device such as a personal computer, server computer, client computer, notebook and laptop computers, tablet devices, mobile phones, smart phones, and the like.

The apparatus is configured to determine a TSN control plane for one or more entities of a communication network. The entities may be physical or virtual entities in the communication network that support one or more of the TSN functions. Such entities may be TSN bridging devices, virtual TSN switches, or layer 3 routers supporting one or more TSN functions. Further, determining the control plane for each entity may include deriving an abstract control plane for each entity. For example, each entity of the communication network may support one or more functions, such as Frame Preemption (Frame Preemption), cut Through forwarding (Cut Through), frame Replication and elimination (Frame Replication and elimination). In addition, the device may determine the control plane based on a YANG model that is published by the vendor or through a description of its MIB.

Further, the apparatus is configured to obtain a symbolic language for each control plane and determine an abstract control plane in a vendor-independent manner. The symbolic language of an entity is the language in which each network parameter or operation is represented by a symbol.

For example, according to 802.1Qcw, the basic operation for Scheduled Traffic is SetGateStates and its associated parameters are grouped in sgs-parameters containers. Furthermore, if frame preemption is supported, two additional operations may be performed, namely 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 "preempt _ enabled" is introduced to describe the presence or absence of preemption support. As another example, "mac _ addr _ port _0" may be used to represent the mac address of port 0. Additionally, symbolic languages are also used for model dependencies, data plane constraints, and TSN properties.

The symbolic model is designed for each device. After all symbolic models are derived for each device, in a subsequent step, an integrated verification symbolic language is built which can also capture the dependencies between the device and the model in order to perform end-to-end verification testing.

For example, the device of the first aspect may obtain a TSN control plane model, which may be used for network verification. The device may have a verification module that may determine a verification model. Network authentication may identify problems proactively and before they are applied. Furthermore, in order to have an integrated function TSN system, the automatic network verification may consider not only the network model for the abstract control plane but also the resulting data plane due to configuration in order to perform end-to-end multi-vendor verification.

The device may obtain (e.g., determine) a TSN verification model for the communication network. For example, in some embodiments, the forwarding plane of a TSN-based network of a communication network may be complex. Furthermore, based on the configuration files used in the communication network, the different control plane aspects may cooperate harmoniously in order to have an integrated functional system. Furthermore, network validation as an end-to-end configuration may be applied to the TSN bridge, given, for example, that the same features and interfaces are available, allowing for operation in a multi-vendor environment. Furthermore, the device of the first aspect is capable of determining a TSN verification model of such a communication network.

The apparatus 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 can find errors before they occur and generate the wrong data plane.

Devices can avoid negatively impacting the orchestrated end-to-end TSN control plane.

Device avoidance verifies for bad (bad) configurations that may impact overall TSN network performance.

Devices may implement a TSN network with end-to-end functionality. For example, such an end-to-end TSN network may consider TSN flow (flow), pure Layer 2 (Layer 2) aspects such AS VLAN configuration, timing information according to 802.1AS requirements, to operate in a coordinated manner or to be configured or verified.

The TSN verification model can be used to actively check TSN configuration validity.

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

The device may obtain (e.g., derive) a model of the unknown control surface.

The device can obtain a new symbolic language for TSN verification.

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

The device is able to dynamically select a verification module plug-in according to the configuration protocol used.

For example, in a multi-vendor TSN environment, a verification process may be defined and may also be implemented for a standardized configuration verification method that is independent of vendor implementation. Furthermore, verification mechanisms may be used to avoid violations of TSN constraints and policies. The TSN verification mechanism may be independent of the TSN configuration file and may be applied to any use case, such as industrial automation or automotive.

The apparatus may include a circuit. The circuitry may include hardware and software. The hardware may include analog circuitry or digital circuitry, or both analog and digital circuitry. In some embodiments, a circuit includes one or more processors and non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code that, when executed by 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 the validity of the TSN configuration and/or the change of the TSN configuration based on a 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 semantic modeling. Further, a verification process may be defined for configuration verification. The verification process and/or the configuration verification protocol or method may be implemented independent of the vendor. Furthermore, it is possible to avoid distributing and implementing misconfigurations that may lead to instability of the entire network, not just for the connected nodes. Furthermore, violations of TSN constraints or policies, etc. may be avoided. Furthermore, the TSN verification mechanism may be independent of the TSN configuration file and may be applied to any use case, such as industrial automation or automotive, etc.

In another implementation of the first aspect, the integrated symbolic language includes information relating to one or more relationships between one or more entities and/or one or more other relationships between TSN control plane models obtained for one or more entities.

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

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

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

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

In another implementation form of the first aspect, the apparatus is further configured to: receiving a verification model of a layer 2 or layer 3 or 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 of the communication network based on the updated integrated symbolic language.

In particular, the device can incorporate layer 2, layer 3 or layer 4 external tools or libraries through symbol mapping in the TSN verification model. For example, during the authentication process, the TSN authentication model of the device may consider not only TSN aspects, network aspects, but also VLAN and Precision Time Protocol (PTP) status. For example, if the talker or listener are not synchronized or they cannot communicate with each other, the devices may not update the TSN configuration of the time aware shaper.

In another implementation manner of the first aspect, the apparatus is further configured to: analyzing the obtained TSN data surface model; the TSN verification model of the communication network is further updated based on the results of the analysis.

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

In another implementation of the first aspect, the characteristic of the communication network includes a Virtual Local Area Network (VLAN) status of the communication network during the authentication procedure, or a Precision Time Protocol (PTP) status of the communication network during the authentication procedure.

In another implementation form of the first aspect, the device includes a network configuration protocol (NETCONF) interface configured to perform TSN authentication model-related communication between the device and at least one entity of a communication network.

In another implementation form of the first aspect, the apparatus is further configured to: before obtaining a TSN verification model of a communication network, a control plane model of an entity is obtained under the condition that the TSN control plane model of the entity is unknown.

In another implementation form of the first aspect, the apparatus is further configured to: receiving a request to change a given TSN configuration; determining a configuration error and a configuration quality for a given TSN configuration based on an integration notation language; and providing a verification result, in particular whether the change to a given TSN configuration should be allowed.

In another implementation form of the first aspect, the apparatus is further configured to: in the event that a change to a given TSN configuration is determined to be not tolerated, processing a reject error; and negotiating the denial error by providing a set of recommendations to a calling function of the TSN configuration verification module.

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

In another implementation form of the first aspect, the apparatus is further configured to verify a verification parameter based on a TSN verification model of the communication network, the verification parameter being, for example:

joint investigation of TSN configuration and layer 2 or layer 3 aspects of the communication network;

reachability of a speaker to a listener in a communication network;

steady state presence of candidate schedulers in case of time-aware shaping, or validation of asynchronous time shaping operations, or loop queuing and forwarding;

bounded path length;

bounded latency;

preemption capability.

For example, in addition to pure TSN features such AS scheduling traffic, preemption, path replication, elimination, etc., the device may also consider (allow for) network configuration mechanisms, pure layer 2 aspects AS well AS layer 3 aspects of operation and status and configuration status, such AS talker/listener reachability, VLAN configuration and status, buffer size and runtime backlog, IP addressing in a multi-domain setting such AS 802.1AS status with respect to time synchronization, etc.

For example, in some embodiments, if an endpoint is not connected, it may not be necessary to apply a (e.g., extremely complex) configuration update, or if an access list (ACL) blocks traffic flow, it may not be necessary to apply new time-aware forwarding rules, etc.

In another implementation of the first aspect, the apparatus is incorporated in:

a Centralized Network Controller (CNC), or

A Software Defined Network (SDN) controller, or

TSN sensing devices, or

TSN bridge.

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

In some embodiments, the device may be incorporated into a CNC. Further, according to 802.1Qcc, a set of TSN features, such as credit-value based shaper algorithms, frame preemption, scheduling traffic, stream-wise filtering and policing, round robin queuing and forwarding, etc., may be configured by the CNC, which features may be considered by the device, e.g., by a verification model of the device, or used to determine the validity of the TSN configuration.

In some embodiments, the device may determine the validity of the TSN configuration. For example, the device may determine a "bad" TSN configuration as invalid. As an example, poor configuration may impact overall TSN network performance because the interdependencies are extremely complex and it is not easy to investigate the interdependencies without an automatic verification mechanism. It should be noted that if the "bad" configuration complies (respect) with, for example, the YANG model of the device, there may also be situations where the "bad" configuration is interpreted as correct, accepted and applied by static configuration analysis. However, this may lead to instability. For example, for large diameter networks, if preemption is introduced at each step, packet arrivals are not synchronized, statistical multiplexing cannot be controlled, and performance guarantees by means of delay or jitter cannot be controlled. AS another example of the time synchronization required in 802.1AS operations with respect to 802.1Qbv functionality, if the synannounciceninterval values on the two endpoints of the connection are different, a configuration tool that checks semantics only according to YANG will not be able to perform this check.

A second aspect of the present invention provides a device for supporting a TSN, the device being configured to: 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 one or more TSN bridges of a communication network based on a TSN control plane model for the TSN bridge; and obtaining a distributed TSN verification model of the communication network distributed over the two or more TSN bridges based on respective symbolic languages of the two or more TSN bridges.

The device may be or may be incorporated into an electronic device such as a personal computer, server computer, client computer, notebook and laptop computers, tablet devices, mobile phones, smart phones, and the like.

In the case of a distributed TSN control plane, the authentication device may enable a global view. Furthermore, in the fully distributed case, in-band authentication in a designated TSN device (such as a bridge or switch) may be applied.

Further, in some embodiments, a new process of validating with a TSN-designated switch may be provided for the device of the first aspect or the device of the second aspect, e.g., TSN validation may be performed based on a feedback loop. For example, the feedback loop may be such that: if the result of the verification is negative, the device of the first aspect or the device of the second aspect may specify a new interface to trigger a new event to update, correct or improve the configuration through a feedback loop using the TSN control plane.

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

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

A third aspect of the invention provides a method for a time sensitive network, 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 one or more entities of a communication network based on their respective TSN control plane models; obtaining an integrated symbolic language of the communication network based on the symbolic languages of the one or more entities, wherein the integrated symbolic language indicates one or more relationships between the one or more entities in the communication network; and obtaining a TSN verification model for the communication network based on the integrated notation language.

In an implementation manner of the third aspect, the method further includes: the validity of the TSN configuration and/or the change in the TSN configuration is determined based on a TSN verification model of the communication network.

In another implementation of the third aspect, the integrated symbolic language includes information relating to one or more relationships between one or more entities and/or one or more other relationships between TSN control plane models obtained for one or more entities.

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

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

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

In another implementation form of the third aspect, the method further comprises: receiving a verification model of a layer 2 or layer 3 or 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 another implementation form of the third aspect, the method further comprises: analyzing the obtained TSN data surface model; and further updating the TSN verification model of the communication network based on the results of the analysis.

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

In another implementation of the third aspect, the characteristics of the communication network include (e.g., not only the TSN aspect, but also) a VLAN status of the communication network during an authentication procedure, or a PTP status of the communication network during an authentication procedure.

In another implementation form of the third aspect, the method further comprises: for the case of the fully centralized control plane and the hybrid control plane, the communication related to the TSN authentication model is performed between the device and at least one entity of the communication network through a NETCONF interface.

In another implementation form of the third aspect, the method further comprises: before obtaining a TSN verification model of a communication network, a control plane model of an entity is derived without knowledge of the TSN control plane model of the entity.

In another implementation form of the third aspect, the method further comprises: receiving a request to change a given TSN configuration; determining a configuration error and a configuration quality for a given TSN configuration based on an integration notation language; and providing a verification result, in particular whether the change to the given TSN configuration should be allowed.

In another implementation form of the third aspect, the method further comprises: in the event that the change to a given TSN configuration is determined to not be permitted, processing a rejection error; and negotiating the denial error by providing a set of recommendations to a calling function of the TSN configuration verification module.

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

joint investigation of TSN configuration and layer 2 or layer 3 aspects of the communication network;

reachability of a speaker to a listener in a communication network;

steady state presence of candidate schedulers in case of time-aware shaping, or validation of asynchronous time shaping operations, or loop queuing and forwarding;

bounded path length;

bounded latency;

preemption capability.

In another implementation form of the third aspect, the method is configured to:

CNC, or

SDN controller, or

TSN aware devices, or

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 invention provides a method for a time sensitive network, 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 based on a TSN control plane model for each of the one or more TSN bridges of the communication network; and obtaining a decentralized TSN verification model of the communication network distributed over the two or more TSN bridges based on respective symbolic languages of the two or more TSN bridges.

In an implementation manner of the fourth aspect, in the fully distributed TSN control plane, the method further includes: when selected as a designated verification TSN bridge with a logical global view, a verification process is performed based on the distributed TSN verification model.

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

A fifth aspect of the invention provides a computer program comprising program code for performing a method according to the third or fourth aspect or any implementation thereof.

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

It should be noted that all devices, elements, units and means described in the present application may be implemented by software or hardware elements or any type of combination thereof. All steps performed by the various entities described in the present application, as well as the functions described to be performed by the various entities, are intended to mean that the respective entities are adapted or used to perform the respective steps and functions. In the following description of specific embodiments, although a specific function or step to be performed by an external entity is not reflected in the description of a specific detailed element of the entity performing the specific step or function, it should be clear to a skilled person that these methods and functions may be implemented by corresponding hardware or software elements or any combination thereof.

Drawings

The foregoing aspects and implementations are explained in the following description of specific embodiments, taken in connection with the accompanying drawings, wherein:

FIG. 1 illustrates an apparatus for supporting TSN operation according to an embodiment of the present invention;

FIG. 2 illustrates another apparatus for supporting a distributed TSN control plane according to an embodiment of the present invention;

FIG. 3 is a schematic diagram showing a diagram of a TSN validation module based on a CNC internal software component;

FIG. 4 is a schematic diagram showing a diagrammatic view of multi-vendor control plane integration;

FIG. 5 is a schematic illustration of a flow chart of a process for creating an abstract control plane model for an entity;

FIG. 6 is a schematic diagram showing a diagram of model construction;

FIG. 7 is a schematic diagram showing a diagram of a multi-layer authentication process;

FIG. 8 is a schematic diagram showing a diagram of a validation module deployment for the fully distributed TSN control plane;

FIG. 9 is a diagram showing the addition of a verification model implemented as an extension over 802.1 dj;

FIG. 10 illustrates a method for supporting TSN operation according to an embodiment of the present invention; and

fig. 11 illustrates another method for supporting distributed TSN operations according to an embodiment of the present invention.

Detailed Description

Fig. 1 shows a device 100 for supporting TSN configuration verification operations according to an embodiment of the invention.

The device 100 is arranged to determine a TSN control plane model 101, 102, 103 for each of one or more entities 11, 12, 13 of the communication network 1. For example, the communication network 1 may comprise one or more entities 11, 12 and 13.

The device 100 is further arranged 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 the respective TSN control plane model 101, 102, 103 of the one or more entities 11, 12, 13.

The apparatus 100 is further configured to obtain an integrated symbolic language 120 of the communication network 1 based on the symbolic languages 111, 112, 113 of the one or more entities 11, 12, 13, wherein the integrated symbolic language 130 indicates one or more relationships between the one or more entities 11, 12, 13 in the communication network 1.

The device 100 is further arranged for obtaining a TSN verification model 130 of the communication network 1 based on the integrated symbolic language 120.

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

Furthermore, the integrated symbolic language 120 and/or verification model 130 of the device 100 may enable verification of large instances of combined search problems for hardware and software verification, for example, using semantic modeling based on SAT and Satisfiability Modeling Theory (SMT).

Furthermore, the device 100 may avoid misconfigurations where the distribution may lead to overall network instability.

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

The device 100 may include processing circuitry (not shown in fig. 1) for performing, carrying out, or initiating the various operations of the device 100 described herein. The processing circuitry may include hardware and software. The hardware may include analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable array (FPGA), a Digital Signal Processor (DSP), or a multi-purpose processor. In one embodiment, the processing circuitry includes one or more processors and non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code that, when executed by one or more processors, causes the device 100 to perform, carry out, or initiate the operations or methods described herein.

Fig. 2 illustrates another apparatus 200 for supporting distributed TSN control plane operations, according to an embodiment of the present invention.

The apparatus 200 is arranged to determine a TSN control plane model 201, 202, 203 for each of one or more TSN bridges 21, 22, 23 of the communication network 1. For example, the communication network 1 may include a device 200 and one or more TSN bridges 21, 22, 23. Further, the device 200 may have a global view and one or more TSN bridges 21, 22, 23 may have a local view.

The device 200 is also configured to: the symbolic language 211, 212, 213 of each of the one or more TSN bridges 21, 22, 23 is obtained based on a TSN control plane model 201, 202, 203 of the respective one or more TSN bridges 21, 22, 23 of the communication network 1.

The device 200 is also configured to: a distributed TSN verification model 230 of the communication network 1 distributed over two or more TSN bridges 21, 22, 23 is obtained based on the respective symbolic languages 201, 202, 203 of the two or more TSN bridges 21, 22, 23.

Device 200 may be similar or identical to device 100 and may have similar or identical functionality.

Device 200 may include processing circuitry (not shown in fig. 2) for performing, carrying out, or initiating the various operations of device 200 described herein. The processing circuitry may include hardware and software. The hardware may include analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable array (FPGA), a Digital Signal Processor (DSP), or a multi-purpose processor. In one embodiment, the processing circuitry includes one or more processors and non-transitory memory connected with the one or more processors. The non-transitory memory may carry executable program code that, when executed by one or more processors, causes the device 200 to perform, carry out, or initiate the operations or methods described herein.

Referring now to fig. 3, fig. 3 is a schematic diagram of the device 100 obtaining a TSN verification model 130 based on software elements internal to the CNC.

Fig. 3 shows the architecture of the device 100 for obtaining the TSN verification model 130, e.g. the verification model 130 may be obtained by a verification module incorporated as a software element in the CNC, for both the hybrid and the fully centralized cases.

The authentication module of device 100 communicates periodically or event-based through management interface 304 (e.g., netconf) with the local authentication module agent 311 of the local agent 311 in each TSN-enabled 802.1 bridge 310 to retrieve operational state information regarding information such as port state, link state, ptp state, vlan information, queuing dynamics, etc.

Home agent 311 may operate within IEEE TSN bridge 310. The local proxy 311 may run at each bridge for unloading CNC. The home agent 311 may be used to minimize the communication overhead between the CNC and the TSN bridge for all operational and configuration data required. Further, local processing may be performed where applicable.

The device 100 (e.g., the authentication module of the device 100) may have the following functions.

The device 100 may obtain (e.g., derive) an abstract model of the control plane for each TSN device in the communication network 1. In a multi-vendor environment, this functionality may be different. Further, the device 100 may determine the symbolic language 111, 112, 113 based on the control plane model 101, 102, 103 for each TSN device in the network.

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

The device 100 may also derive an interface to a third party tool that is capable of performing layer 2/layer 3 authentication, such as Minesweeper, batfish, symNet, or Veriflow. Furthermore, the TSN verification module of device 100 may focus on TSN aspects in real time, but may combine this information to infer a final verification result.

The apparatus 100 may also obtain (e.g., create) an abstract model of the resulting data plane 301, 302, 303 responsible for the actual forwarding based on the control plane models 101, 102, 103 and the requested configuration.

Furthermore, when a configuration update is requested, depending on the result of the verification process, a set of return codes may be provided, which may describe different scenarios as follows:

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

b) Error is found-the configuration must be rejected.

c) No errors are found but the resulting data plane performance will be poor.

Further, in the event that a configuration update is rejected, a set of suggestions for the calling function of the configuration verification module may be provided.

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

For the centralized configuration model, there are two subcases:

case 1: completely centralizing: in this case, the talker and listener communicate with the CUC entity to describe the service requirements. In this case, a protocol such as PTCC or Restconf or Netconf may be used with 802.1Qdj to pass information to the CNC entity.

Case 2: a user to network interface (UNI) (enhanced SRP) may be used to pass service requirements and related speaker/listener information to the CNC through an edge bridge (edge bridge).

After the business requirements are specified and collected, the business requirements are further passed to the CNC. In CNC and other control processes or information (e.g., topology information), TSN scheduling decisions are made by, for example, TSN scheduling software entities. However, instead of an ad hoc deployment scheduling decision, the verification module may determine whether the configuration request should be allowed.

In particular, the device 100 may consider a procedure of performing the authentication process. In other words, the process of communicating relevant information to the control entity or deciding on scheduling decisions may not be considered.

Referring now to FIG. 4, FIG. 4 is a schematic diagram illustrating a diagram of multi-vendor control plane integration.

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

For example, the device 100 may derive the control plane model during a verification module initialization process.

As a first step during the initialization phase, an abstract model of the TSN control plane 101, 102, 103 for each device 11, 12, 13 is derived based on the TSN characteristics or the functions supported by them. An example of such a process is discussed with respect to fig. 5.

Furthermore, although the TSN working group of IEEE802.1 explicitly specifies TSN management objects and Management Information Bases (MIBs), each vendor may have its own model and may also use its own semantics and implementations that may not be fully aligned with the standard definition.

Further, to perform end-to-end configuration verification, the device 100 may initially obtain (e.g., generate) a model of the control plane 101, 102, 103 for each TSN bridge device 11, 12, 13 when operating on a multi-vendor TSN network.

Next, a symbolic modeling step may be performed, and then an integration step may be performed. The device 100 obtains the symbolic languages 111, 112, 113 of the entities of the communication network 1 (device 11, device 12 and device 13 in fig. 4) based on their respective TSN control plane models 101, 102, 103. Further, the device 100 may ultimately arrive at an integrated end-to-end control plane model 401 and a corresponding integrated symbolic language 120.

Referring now to FIG. 5, FIG. 5 is a schematic illustration of a flow chart of a process 500 for creating a control plane model for an entity.

Process 500 may be performed by device 100 and/or device 200. In the following, process 500 is illustratively discussed as being performed by device 100.

At step 501, the device 100 or device 200 initiates an authentication initialization phase for each entity. For example, these entities may be TSN bridges.

At step 502, the appliance 100 or 200 may determine whether a control plane of an entity is known. Further, when the determination is "no", the apparatus 100 or 200 executes step 503. Further, when the determination is "yes", the apparatus 100 or 200 performs step 504.

At step 503, the appliance 100 or 200 applies model learning techniques to derive a control surface model of the entity.

For example, device 100 or device 200 may treat an entity as a black box when the control plane of the entity is unknown, such as when no YANG model can be used to model the operation of a TSN device. Model learning techniques may then be applied to derive the control surface model. For example, the device 100 or 200 may apply a learning algorithm such as Lstar to create an unknown state diagram by sending an input query to an entity and analyzing the output. In addition, three cases describe relationships to the TSN standard, including relationships to the TSN standard when the implementation is fully aligned, implementation misaligned, or implementation partially aligned, according to a learning process.

At step 504, for example, where the control plane model is known or where the device 100 or 200 (e.g., in step 503) derives a control plane.

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

For example, after deriving the model in step 504, for each TSN entity in the communication network, the device 100 or device 200 may build a symbolic language model, which may be defined as a set of attributes, rules, constraints, and the like.

In general, symbolic language modeling may include a set of symbols (variables) that may represent a data type, attribute, or action. Furthermore, regardless of the management protocol used (e.g., netconf, restconf, SNMP), to retrieve control plane information, the device 100 or device 200 may define a mechanism to convert configuration parameters and attributes into variables based on symbolic modeling.

Further, the appliance 100 or 200 may perform an integration process to integrate the symbolic language into the end-to-end symbolic model of the control plane and, if further used by the configuration verification module, may process these rules related to the configuration reception event. For example, a symbolic language may be used to execute queries and become part of the validation FSM execution process.

Further, there may be three cases:

when the control plane model of the entity is consistent with the actual implementation of a subset (or full set) of the TSN standard or revision, the device 100 performs step 506 and marks the abstract model of the control plane as fully aligned.

The control plane model of the entity is partially aligned with the TSN standard-revision set. For example, perhaps supporting 802.1CB, but following a custom preemption procedure or a custom queuing structure, the device 100 performs step 507 and marks the abstract model of the control plane as partially aligned.

The control plane model of the entity is misaligned with the TSN standard-revision set, and the device 100 performs step 508 and marks the abstract model of the control plane as misaligned.

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

In some embodiments, after deriving and analyzing a control plane model for each device, device 100 or device 200 may design a TSN symbolic language from the model. Symbolic modeling may also be used to model dependencies, data plane constraints, and TSN properties. For example, symbolic modeling may be used to parse received TSN configuration instructions into arguments of a logical formula. For example: IPs × ports × IPd × portd × schedule _ entry _ payload → { true, false }.

Referring now to FIG. 6, FIG. 6 is a schematic diagram of a diagram 600 illustrating model building. The model building may be performed by the apparatus 100 or the apparatus 200.

In block 601 of the diagram 600, the YANG section describes the GCL information in terms of the 802.1Qcw required for 802.1 Qbv. As can be seen from block 601, the YANG section specifies: sgs information is required, the relevant gate operation is described by "gate-status-value" and the gate period is described by "time-interval-value".

In block 602 of the illustration 600, a vendor-specific model is provided that indicates 802.1Qbv support, where for GCL, the entry gate is an operation described by the field "gate" and the corresponding period is described by the field "time".

The verification module of device 100 or device 200 may compare the two files obtained based on TSN standard model 603 and TSN vendor model 604 and may also make inferential decisions to identify which portions of the device model follow the standard description. In this case, SRS is supported and may be part of the device model (although vendor specific implementations use different nomenclature), but not shm and srm. Furthermore, all results of all comparisons, along with additional methods to capture dependencies and constraints, are part of TSN symbolic model 605, where symbolic variables are designed based on standard descriptions and comparison results. For example, a boolean variable x1 may be introduced to describe whether preemption support is present.

In a previous step, a symbolic model is derived for each entity 11, 12, 13. Furthermore, after the symbolic models are derived for all entities, in a next step, an integrated verification symbolic language may be built that may also capture dependencies between devices or models in order to perform end-to-end verification testing.

To perform the verification test, device 100 or device 200 may consider one or more of the following inputs:

an integrated control plane symbol model.

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

Configuration to apply (configuration data, such as scheduler decisions to apply, speaker requirements, etc.).

Operational data (statistics, other layer 2/layer 3 information such as VLAN status or PTP information on time synchronization).

Further, device 100 or device 200 may also consider operational data input (e.g., ports synchronized, VLANs set, listener reachable, etc.). Furthermore, as part of the integrated symbol model, device 100 or device 200 may capture dependency issues, e.g., if a time-aware shaper is used, the interface may have an active PTP instance. As another example, if an ACL is applied in a switch, traffic will be blocked. Furthermore, it makes no sense to update many hops of a switch that does not know this.

In addition, device 100 or device 200 may also use data plane constraints and TSN attributes as part of an integrated symbology model.

Referring now to FIG. 7, FIG. 7 is a schematic diagram of a diagram 700 illustrating a multi-layer authentication process. The multi-layer authentication may be performed by the device 100 or the device 200. In the following, the multi-layer authentication process is exemplarily discussed as a process performed by the device 100, without limiting the present invention.

For example, device 100 may include a TSN configuration module, an integrated symbol language 120, and a TSN verification model 130.

In addition, the device 100 may use configuration and operational data (such as reachability information, path existence, and node state, which are not part of the TSN standard set but are required for smooth operation) required for the integrated TSN symbolic model.

The device 100 may connect the TSN authentication module to other authentication mechanisms already available to perform pure layer 2, layer 3 and higher layer authentication operations, such as Minesweeper, batfish, symNet, veriflow, etc. In addition, there may be a layer 2 network authentication toolkit 701, a layer 3 network authentication toolkit 702, and a layer 4 network authentication toolkit 703.

In addition, the device 100 may use the respective mappers 711, 712, 713 to map each of the layer 2 network authentication toolkit 701, the layer 3 network authentication toolkit 702, and the layer 4 network authentication toolkit 703 to its TSN configuration authentication module. For each tool used, the mapping function is responsible for augmenting the integrated end-to-end symbolic model with information provided by external validation tools or external libraries. Further, through this process, device 100 may use a single API to query queries across multiple layers of a protocol stack. The device 100 may also consider disclosing a verification module interface that may allow queries from an external management or control entity to the verification module to be performed for all or part of the integrated symbolic model.

Further, the decision-making process also takes into account higher-level states when the device 100 determines verification, such as when a verification decision is to be made.

It should be noted that, through the mapping function between the TSN module and the external library, the device can quickly verify whether the network satisfies a wide range of expected attributes, such as reachability or isolation between nodes, waypoint (waypoint), black hole, bounded path length, load balancing, functional equivalence of two forwarding devices, and the like. These attributes may be used to quickly verify aspects of the interaction between the TSN and higher layers.

In some embodiments, device 100 or device 200 may perform a validation operation or a symbol check.

For example, a configuration change or update request (via a protocol such as PTCC, by enhanced SRP in the case of hybrid or CUC in the case of fully distributed) may trigger the necessary validation module operations, e.g., communication, to retrieve operational state, symbolic modeling query execution and reasoning, and actions such as discarding, applying, or optimizing the requested configuration update.

For example, device 100 or device 200 may proactively analyze the resulting data surface that may reflect the combined impact of all configuration aspects. In particular, the appliance 100 or 200 may build a set of TSN data plane models based on the control plane model and the actual configuration to be applied. Thereafter, device 100 or device 200 may perform and evaluate checks to determine whether the configuration can be tolerated based on a set of queries. For example, semantic modeling may be used to verify configuration errors, bad configurations, policy violations, and potential security threads. Device 100 or device 200 may also discover errors before the TSN network generates and distributes the error data plane.

Further, device 100 or device 200 may convert the received configuration into a set of semantic logical formulas. For example, as a result of interactions between TSN-enabled devices, such as switches, gateways, and endpoints, device 100 or device 200 may capture a steady state (in the presence of convergence) to which the TSN data plane may converge. In addition, the device 100 or the device 200 may convert the TSN message passing received about the configuration instruction into the following logical formula:

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

the logical formula may also take into account dependencies and constraints and may further incorporate policies. For example, if the combination formula can be satisfied, there is a steady state of the network. Otherwise, there is no steady state and the configuration should be rejected (or updated).

Further, device 100 or device 200 may generate a request to perform a symbol check on the configuration change or update. For example, rather than investigating all possible states, the device 100 or 200 may only traverse the states and portions of the network that are affected by the change based on the verification model. For example, if there is a plan to update 802.1Qbv operations, 802.1Qbu may not be affected, whereas if there is a plan to update 802.1Qci, 802.1Qbu may be affected because the flow may be completely blocked.

For the inspection phase, the apparatus 100 or 200 may consider relevant parts of the verification model, which may be described as a deterministic metric machine (deterministic metric machine). A miller machine is a finite state machine whose output values are determined by its current state and current inputs.

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

accept (mandatory): the configuration is accepted as such and can be applied to the running configuration.

Rejection (mandatory): configuration is rejected by reports on errors or discovered potential performance degradation factors and verification results.

Negotiation (optional): in this case, a particular problem portion of the configuration is identified for a particular entity.

These results may be passed back to the resident calling function, e.g., the CUC.

The negotiation module is discussed next. In addition to "accept" and "reject", device 100 or device 200 may also consider more than one function for triggering negotiation of parameter values to avoid performance degradation. In this case, inside the verification module, tools such as SMT/SAT are considered to call the negotiation function to investigate potential variants in order to optimally adjust the parameters of the data plane that will cause performance degradation or will cause errors. In this case, the TSN validation module mechanism creates a feedback loop. If the verification result is negative, the inventive device provides a new interface to trigger a new event from the verification module to update/correct/improve the configuration through a feedback loop using the TSN control plane. Since the verification process is extremely complex, the negotiation module relies on the discovery of the main verification activity in order to fine-tune the parameterization step by step, instead of starting the verification process again from the beginning.

Referring now to FIG. 8, FIG. 8 is a schematic diagram showing a diagram of a verification module deployment for a fully distributed configuration.

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

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

In fig. 8, the device 200 is based on a TSN bridge with a global view. Furthermore, the entities 21, 22, 23 are based on TSN bridges with local view.

For example, the device 200 may use a designated spanning tree selected according to a Spanning Tree Protocol (STP) operation switch as the designated verification bridge.

In the case where STP is enabled and responsible for forwarding graph establishment, bridge id priority may be used to select the root bridge. In addition, only the validation module may be installed and may also run on the selected STP root bridge. Similar processing may be performed for variants of STP, such as MSTP and RSTP. For example, the root bridge may control the spanning tree topology and may be a hub that connects other switches by establishing logical adjacencies with all switching entities on the network to provide global perspective information. The relevant information passed between the root authentication module (e.g., appliance 200 with the global view) and the different local authentication agents deployed at each bridge is done at the LRP/RAP or LRP which is the preferred additional application.

Next, examples of abstract model constructions that may be performed by device 100 or device 200 are discussed.

For example, the appliance 200 may specify an abstract control plane model for each TSN bridge based on the data type and method implemented. In particular, the device 200 may use a step-by-step process after answering a query as follows:

first, the device 200 determines whether the implementation supports which managed object definitions and encodings in accordance with the TSN standard, such as frame preemption in accordance with 802.1Qbu, scheduled traffic in accordance with 802.1Qbv, frame duplication and elimination in accordance with 802.1CB, and so forth.

To this end, the device 200 performs an exhaustive recursive investigation to analyze the TSN control surface. In addition, the appliance 200 may also construct an abstract symbolic model based on YANG definitions (e.g., IEEE802.1 Qcp YANG model for bridging, IEEE802.1qcw YANG model for Qbv, qbu, and Qci) and by converting attributes to symbolic variables.

For example, the device 200 may obtain samples of frame-prediction-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 the notation bridge _ id _ prediction _ active, and the integrated symbolic language may specify method F (bridge 1_ prediction _ active, bridge2_ prediction _ active, etc.) to verify whether end-to-end preemption is enabled.

Referring now to FIG. 9, FIG. 9 is a schematic diagram showing a diagram of the addition of a verification model implemented as an extension over 802.1 dj.

The verification model may be implemented by the device 100 and/or the device 200. For example, in the case of 802.1Qcc, the authentication module of the apparatus 100 or the authentication module of the apparatus 200 is, as a newly added feature, a + -x authentication configuration (+ -x Verify configuration) as indicated by reference numeral 902. The verification process may be invoked by the CUC by adding verification capabilities to the CNC and publishing them through 802.1 Qdj.

Fig. 10 shows a method 1000 for a time sensitive network according to an embodiment of the invention. The method 1000 may be performed by the apparatus 100 as described above.

The method 1000 includes the steps 1001: a TSN control plane model 101, 102, 103 for each of one or more entities 11, 12, 13 of the communication network 1 is determined.

The method 1000 further comprises step 1002: the symbolic language 111, 112, 113 of each of the one or more entities 11, 12, 13 is obtained based on the respective TSN control plane model 101, 102, 103 of the one or more entities 11, 12, 13 of the communication network 1.

The method 1000 further comprises step 1003: an integrated symbolic language 120 of the communication network 1 is obtained based on the symbolic languages 111, 112, 113 of the one or more entities 11, 12, wherein the integrated symbolic language 130 indicates one or more relationships between the one or more entities 11, 12, 13 in the communication network 1.

The method 1000 further includes step 1004: a TSN verification model 130 of the communication network 1 is obtained based on the integrated symbolic language 120.

Fig. 11 illustrates a method 1100 for a time sensitive network according to an embodiment of the invention. Method 1100 may be performed by device 200 as described above.

The method 1100 includes the steps 1101: a TSN control plane model 201, 202, 203 for each of the one or more TSN bridges 21, 22, 23 of the communication network 1 is determined.

The method 1100 further comprises a step 1102: the symbolic language 211, 212, 213 of each of the one or more TSN bridges 21, 22, 23 is obtained based on a TSN control plane model 201, 202, 203, respectively, of the one or more TSN bridges 21, 22, 23 of the communication network 1.

The method 1100 further comprises the step 1103 of: a distributed TSN verification model 230 of the communication network 1 distributed over two or more TSN bridges 21, 22, 23 is obtained based on the respective symbolic languages 201, 202, 203 of the two or more TSN bridges 21, 22, 23.

The invention has been described in connection with various embodiments and implementations as examples. However, other variations to practice the claimed invention can be understood and effected by those skilled in the art from a study of the drawings, the disclosure, and the independent claims. In the claims as well as in the specification, 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 mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims (21)

1. A device (100) for supporting time sensitive network, TSN, operation, characterized in that the device (100) is configured to:

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

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 a respective TSN control plane model (101, 102, 103) of the one or more entities (11, 12, 13);

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

-obtaining a TSN verification model (130) of the communication network (1) based on the integrated symbolic language (120).

2. The apparatus (100) of claim 1, further configured to:

determining validity of a TSN configuration and/or a change of a TSN configuration based on a TSN verification model (130) of the communication network (1).

3. The apparatus (100) of claim 1 or 2, wherein:

the integrated symbolic language (120) comprises information related to one or more relationships between the one or more entities (11, 12, 13) and/or one or more other relationships between the obtained TSN control surface models (101, 102, 103) of the one or more entities (11, 12, 13).

4. The apparatus (100) according to any one of claims 1 to 3, wherein:

the TSN control plane model (101, 102, 103) for each entity (11, 12, 13) is obtained based on the functionality provided by that entity (11, 12, 13).

5. The apparatus (100) of any of claims 1 to 4, further configured to:

obtaining a TSN data plane model (301, 302, 303) for each of the one or more entities (11, 12, 13) of the communication network (1).

6. The apparatus (100) of claim 5, wherein:

the TSN verification model (130) of the communication network (1) is obtained further based on at least one of the TSN data plane models (301, 302, 303).

7. The apparatus (100) of any of claims 1 to 6, further configured to:

receiving a verification model of layer 2 or layer 3 or the TSN operation from an external library or from an external tool;

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

updating a TSN verification model (130) of the communication network (1) based on the updated integrated symbolic language.

8. The apparatus (100) of any of claims 5 to 7, further configured to:

analyzing the obtained TSN data surface model; and

further updating a TSN verification model (130) of the communication network (1) based on the result of the analysis.

9. The apparatus (100) of any of claims 1 to 8, further configured to:

a TSN verification model (130) of the communication network (1) is additionally obtained based on characteristics of the communication network (1).

10. The apparatus (100) of claim 9,

the features of the communication network (1) include:

virtual local area network, VLAN, status of the communication network (1) during an authentication procedure, or

Precise time protocol, PTP, status of the communication network (1) during an authentication procedure.

11. The apparatus (100) according to any one of claims 1 to 10, comprising:

a network configuration protocol, NETCONF, interface (304) for:

-performing a communication related to the TSN verification model (130) between the device (100) and at least one entity of the communication network (1).

12. The apparatus (100) of any of claims 1 to 11, further configured to:

before obtaining a TSN verification model (130) of the communication network (1), a control plane model of an entity (11, 12, 13) is derived without knowledge of the TSN control plane model (101, 102, 103) of the entity (11, 12, 13).

13. The apparatus (100) of any of claims 1 to 12, further configured to:

receiving a request to change a given TSN configuration;

determining a configuration error and a configuration quality for the given TSN configuration based on the integrated symbol language (120); and

providing a verification result, in particular whether the change to the given TSN configuration should be allowed.

14. The apparatus (100) of claim 13, further configured to:

in the event that the change to the given TSN configuration is determined to not be permitted, processing a rejection error; and

the rejection error is negotiated by providing a set of recommendations to a calling function of the TSN configuration verification module.

15. The apparatus (100) of any of claims 1 to 14, further configured to:

verifying verification parameters, such as:

a joint investigation of TSN configuration and layer 2 or layer 3 aspects of the communication network;

reachability of a speaker to a listener in the communication network;

steady state presence of candidate schedulers in case of time-aware shaping, or validation of asynchronous time shaping operations, or round robin queuing and forwarding;

a bounded path length;

a bounded delay;

preemption capability.

16. The apparatus (100) according to any one of claims 1 to 15, wherein:

the device (100) is incorporated into:

centralized network controller CNC, or

Software defined network SDN controller, or

TSN sensing devices, or

A TSN bridge.

17. An apparatus (200) for supporting time sensitive network, TSN, operations, the apparatus (200) being configured to:

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);

obtaining 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 a respective TSN control plane model (201, 202, 203) of the one or more TSN bridges (21, 22, 23); and

obtaining a distributed TSN verification model (230) of the communication network (1) distributed over two or more TSN bridges (21, 22, 23) based on respective symbolic languages (201, 202, 203) of the two or more TSN bridges (21, 22, 23).

18. The apparatus (200) of claim 17, wherein:

in a fully distributed TSN control plane, the apparatus (200) is further configured to: when selected as a designated verification TSN bridge with a logical global view, a verification process is performed based on the distributed TSN verification model (230).

19. A method (1000) for a time sensitive network, 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 a respective TSN control plane model (101, 102, 103) of the one or more entities (11, 12, 13);

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

obtaining (1004) a TSN verification model (130) of the communication network (1) based on the integrated symbolic language (120).

20. A method (1100) for a time sensitive network, 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 symbol language (211, 212, 213) for each of the one or more TSN bridges (21, 22, 23) based on a respective TSN control plane model (201, 202, 203) of the one or more TSN bridges (21, 22, 23) of the communication network (1); and

obtaining (1103) a distributed TSN verification model (230) of the communication network (1) distributed over two or more TSN bridges (21, 22, 23) based on respective symbolic languages (201, 202, 203) of the two or more TSN bridges (21, 22, 23).

21. A computer program, characterized in that, when executed by a computer, causes the method (1000) according to claim 19 or the method (1100) according to claim 20 to be performed.

Images