Apparatus for Supporting TSN Operations with Time-Sensitive Network (TSN) Configuration Verification

Abstract

The present invention relates to a device for supporting time-sensitive network (TSN) configuration verification operations. The device determines a TSN control plane model for each of one or more entities in a communication network, and obtains a symbolic language for each of the one or more entities based on the respective TSN control plane models of the one or more entities in the communication network. The device also obtains an integrated symbolic language for 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. In addition, the device obtains a TSN verification model for the communication network based on the integrated symbolic language. The present invention can be applied to cases of centralized, hybrid, and distributed TSN control planes.

Description

Technical Field

[0001] The present invention generally relates to the field of communication networks, and more particularly to time-sensitive networks (TSNs), especially IEEE TSNs. To this end, the present invention provides devices and methods for supporting TSN operations. The devices and methods can perform TSN configuration verification based on a semantic modeling process. For example, the devices and / or methods of the present invention can obtain an integrated symbolic language of a communication network. In addition, the devices and / or methods can obtain a TSN verification model of the communication network based on the integrated symbolic language of the communication network. Background Art

[0002] Generally, some communication networks are based on TSNs. For example, such communication networks can use TSN technologies, such as having one or more requirements for transmitting data.

[0003] For example, conventional devices provide TSN extensions to enhance the forwarding plane of a conventional bridge so as to provide deterministic performance not only in terms of throughput but also in terms of latency and jitter.

[0004] In addition, TSN operations can address transmissions with very low transmission latency and high availability. For example, some TSN-aware systems operate such that each individual queue can have its own scheduling algorithm, while the transmission scheduling algorithm controls the transmission gate in a time-triggered process. In addition, by using an optimal scheduling algorithm to control the transmission gate, frames can be transmitted at precise times, thereby reducing the latency caused by blocking to the nanosecond level and also ensuring low latency variation.

[0005] In addition, some devices and methods can provide TSN control plane functions. Three methods for providing a TSN control plane are discussed below.

[0006] The conventional method is 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).

[0007] The conventional method is based on a configuration using a fully distributed protocol. The development of the fully distributed method is currently in the process of designing a resource allocation protocol (RAP) that utilizes the underlying transmission of the link registration protocol (LRP).

[0008] The conventional method is based on a hybrid mode that uses a CNC to be responsible for the configuration and control of the TSN bridge and uses a user network interface (UNI) to connect endpoints to the access bridge.

[0009] In addition, for the last case of using the hybrid control plane mode, a stream reservation protocol (SRP) enhancement has also been proposed to support TSN functions that can be used, for example, to announce stream attributes. In addition, some TSN configuration files have been specified based on the application domain. For example, such conventional TSN configuration files have been proposed for TSN configuration files for audio or video bridging, for TSN configuration files for industrial automation, for TSN configuration files for automotive in-vehicle Ethernet communication, for TSN configuration files for mobile fronthaul networks, for TSN configuration files for service provider networks, etc.

[0010] However, conventional TSN-based devices and methods are implemented using static and customized configurations and are aligned with the standards only when the management information base (MIB) is exactly the same as that defined in the standards. In addition, there are no standard-related activities regarding TSN configuration verification. For example, for a fully distributed case, there are no activities related to the relevant verification aspects. In addition, in the case of a centralized configuration or a hybrid configuration, the only verification actions performed are based on the relevant YANG models used by management protocols such as Netconf. For example, for a Netconf message reception event, the Netconf message is analyzed in detail and the YANG model is verified to ensure that, for example, the requested operation is supported on the server side and the patterns and data types described in the message comply with the device's YANG model. Summary of the Invention

[0011] In view of the above problems and drawbacks, embodiments of the present invention aim to improve conventional devices and methods for supporting TSN configuration verification operations.

[0012] The objective is to determine (e.g., derive) an abstract model of the TSN control plane and / or the resulting data plane in a simple manner. Specifically, this should be accomplished based on semantic modeling. Another objective is to detect TSN network configuration errors, e.g., by analyzing configuration files and actively discovering errors. Another objective is to prohibit changes that violate policies or may lead to a degradation in the performance of the communication network. Another objective is to check network-wide variables in real time, e.g., using a verification model determined by a device. Another objective is to perform extensive proactive control and verification processes through semantic modeling and logical formula checking to describe the states and relationships between them.

[0013] The above objectives are achieved by embodiments of the present invention described in the appended independent claims. Advantageous implementations of the embodiments of the present invention are further defined in the dependent claims.

[0014] A first aspect of the present invention provides a device for supporting time-sensitive network operations, the device being configured to: determine a TSN control plane model for each of one or more entities in a communication network; obtain a symbolic language for each of the one or more entities based on the respective TSN control plane models of the one or more entities in the communication network; obtain 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 obtain a TSN verification model of the communication network based on the integrated symbolic language.

[0015] The device can be an electronic device or can be incorporated in an electronic device, such as a personal computer, a server computer, a client computer, a notebook computer and a laptop computer, a tablet device, a mobile phone, a smart phone, etc.

[0016] The device is used to determine the TSN control plane of one or more entities of a communication network. The entity can be a physical entity or a virtual entity that supports one or more of the TSN functions in the communication network. Such an entity can be a TSN bridging device, a virtual TSN switch, or a layer 3 router that supports one or more TSN functions. In addition, determining the control plane of each entity can include deriving the abstract control plane of each entity. For example, each entity of the communication network can support one or more functions, such as Frame Preemption, Cut Through, and Frame Replication and Elimination. In addition, the device can determine the control plane based on the YANG model publicly described by the vendor or through its MIB.

[0017] In addition, the device is used to obtain the symbolic language of each control plane in a vendor-independent manner and determine the abstract control plane. The symbolic language of an entity is a language in which each network parameter or operation is represented by a symbol.

[0018] 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. In addition, if Frame Preemption is supported, two additional operations can 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 "preemption_enabled" is introduced to describe the presence or absence of preemption support. As another example, "mac_addr_port_0" can be used to represent the mac address of port 0. In addition, the symbolic language is also used for model dependencies, data plane constraints, and TSN attributes.

[0019] A symbolic model is designed for each device. After all the symbolic models are derived for each device, in a subsequent step, an integrated verification symbolic language is constructed, which can also capture the dependencies between the devices and the models in order to perform end-to-end verification tests.

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

[0021] The device may obtain (e.g., determine) a TSN verification model of a communication network. For example, in some embodiments, the forwarding plane of a TSN-based network of a communication network may be complex. In addition, different control plane aspects can cooperate harmoniously based on the configuration file used in the communication network, in order to have an integrated functional system. Further, considering operation in a multi-vendor environment, network verification as an end-to-end configuration can be applied to a TSN bridge assuming, for example, the same features and interfaces are available. Moreover, the device of the first aspect is capable of determining a TSN verification model of such a communication network.

[0022] The device of the first aspect may solve one or more of the following problems:

[0023] · The device may provide a robust and efficient TSN verification mechanism.

[0024] · The TSN verification mechanism can find errors before they occur and result in an erroneous data plane.

[0025] · The device may avoid negatively affecting the orchestrated end-to-end TSN control plane.

[0026] · The device avoids verifying bad configurations that may affect the overall TSN network performance.

[0027] · The device may implement a TSN network with end-to-end functionality. For example, such an end-to-end TSN network may consider TSN flows, pure Layer 2 aspects such as VLAN configuration, and timing information according to 802.1AS requirements, so as to work, be configured, or be verified in a coordinated manner.

[0028] · The TSN verification model can be used to proactively check the validity of TSN configurations.

[0029] · Symbolic abstraction of the resulting data plane and / or control plane.

[0030] · The device may obtain (e.g., derive) a model of an unknown control plane.

[0031] · The device may obtain a new symbolic language for TSN verification.

[0032] · The device can obtain a TSN symbol language interpreter in the control plane.

[0033] · The device is capable of dynamically selecting a verification module plug-in according to the configuration protocol used.

[0034] For example, in a multi-vendor TSN environment, a verification process can be defined, and the verification process can also be implemented for a standardized configuration verification method independent of vendor implementation. In addition, the verification mechanism can be used to avoid violating TSN constraints and policies. The TSN verification mechanism can be independent of the TSN configuration file and can be applied to any use case, such as industrial automation or automotive.

[0035] The device may include circuitry. The circuitry may include hardware and software. The hardware may include analog circuitry or digital circuitry, or both analog circuitry and digital circuitry. In some embodiments, the circuitry includes 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 that, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

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

[0037] In particular, the device can derive one or more abstract models for both the control plane and the resulting TSN data plane based on semantic modeling. In addition, a verification process can be defined for configuration verification. The verification process and / or the configuration verification protocol or method can be implemented independent of the vendor. In addition, the distribution and implementation of the following incorrect configurations can be avoided, which may cause the entire network to be unstable, rather than just for the connected nodes. In addition, violations of TSN constraints or policies can be avoided. In addition, the TSN verification mechanism can be independent of the TSN configuration file and can be applied to any use case, such as industrial automation or automotive, etc.

[0038] In another implementation of the first aspect, the integrated symbol language includes information related to one or more relationships between one or more entities and / or one or more other relationships between the obtained TSN control plane models of the one or more entities.

[0039] In another implementation of the first aspect, the TSN control plane model of each entity is obtained based on the function provided by the entity.

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

[0041] In another implementation of the first aspect, the TSN verification model of the communication network is also obtained based on at least one TSN data plane model in the TSN data plane models.

[0042] In another implementation of the first aspect, the TSN verification model of the communication network is also obtained based on the overall TSN data plane model covering the entire network.

[0043] In another implementation of the first aspect, the device is further configured to: receive a verification model for layer 2 or layer 3 or TSN operations from an external library or an external tool; update the integrated symbol language based on the received verification model; and update the TSN verification model of the communication network based on the updated integrated symbol language.

[0044] 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 verification process, the TSN verification model of the device can consider not only TSN aspects and network aspects, but also VLAN and Precision Time Protocol (PTP) status. For example, if the speaker or listener is not synchronized or they cannot communicate with each other, the device may not update the TSN configuration of the time-aware shaper.

[0045] In another implementation of the first aspect, the device is further configured to: analyze the obtained TSN data plane model; and further update the TSN verification model of the communication network based on the result of the analysis.

[0046] In another implementation of the first aspect, the device is further configured to obtain the TSN verification model of the communication network based on the characteristics of the communication network.

[0047] In another implementation of the first aspect, the characteristics of the communication network include the virtual local area network (VLAN) status of the communication network during the verification process, or the Precision Time Protocol (PTP) status of the communication network during the verification process.

[0048] In another implementation of the first aspect, the device includes a Network Configuration Protocol (NETCONF) interface, which is used to perform communication related to the TSN verification model between the device and at least one entity of the communication network.

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

[0050] In another implementation of the first aspect, the device is further configured to: receive a request to change a given TSN configuration; determine configuration errors and configuration quality of the given TSN configuration based on an integrated symbolic language; and provide a verification result, in particular whether the change to the given TSN configuration should be allowed.

[0051] In another implementation of the first aspect, the device is further configured to: handle a rejection error when a change to a given TSN configuration is determined to be not allowed; and negotiate the rejection error by providing a set of recommendations to a calling function of the TSN configuration verification module.

[0052] In particular, the set of recommendations is based on a specific part of the configuration change request that causes the rejection.

[0053] In another implementation of the first aspect, the device is further configured to verify verification parameters based on the TSN verification model of the communication network, where the verification parameters are, for example:

[0054] · A joint investigation of the TSN configuration and aspects of layer 2 or layer 3 of the communication network;

[0055] · Reachability of a speaker to a listener in the communication network;

[0056] · Steady-state existence of a candidate scheduler in the case of time-aware shaping, or verification of asynchronous time shaping operations, or cyclic queuing and forwarding;

[0057] · Bounded path length;

[0058] · Bounded delay;

[0059] · Preemption capability.

[0060] For example, in addition to pure TSN features such as scheduling services, preemption, path replication, elimination, etc., the device may also consider network configuration mechanisms, operations and states of pure layer 2 aspects as well as layer 3 aspects, and configuration states, such as speaker / listener reachability, VLAN configuration and state, buffer size and runtime backlog, IP addressing in a multi-domain setting such as the 802.1AS state regarding time synchronization, etc.

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

[0062] In another implementation of the first aspect, the device is incorporated into:

[0063] · a centralized network controller (CNC), or

[0064] · a software defined networking (SDN) controller, or

[0065] · a TSN-aware device, or

[0066] · a TSN bridge.

[0067] For example, the device can obtain a TSN verification model for cases of fully centralized control planes and hybrid control planes as described in 802.1Qcc. In the case of a fully distributed TSN control plane as described in 802.1Qdd, the device can apply the same principle.

[0068] In some embodiments, the device can be incorporated into the CNC. Additionally, according to 802.1Qcc, a set of TSN features can be configured through the CNC, such as credit-based shaper algorithms, frame preemption, scheduling traffic, per-flow filtering and policing, cyclic queuing and forwarding, etc. These features can be considered by the device, for example, by the device's verification model, or used to determine the effectiveness of the TSN configuration.

[0069] In some embodiments, the device can determine the effectiveness of the TSN configuration. For example, the device can determine a "bad" TSN configuration as invalid. As an example, a bad configuration may affect the 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 there may also be cases where a "bad" configuration is translated as correct, accepted, and applied through static configuration analysis if the "bad" configuration respects, for example, the device's YANG model. However, this may lead to instability. For example, in a large-diameter network, if preemption is introduced at each step, the packet arrivals are out of sync, statistical multiplexing cannot be controlled, and the performance guarantee with respect to latency or jitter cannot be controlled. As another example of the time synchronization required for 802.1Qbv functionality in 802.1AS operation, if the SynAnnounceInterval values are different on the two endpoints of a connection, a configuration tool that only checks semantics according to YANG will not be able to perform this check.

[0070] A second aspect of the present invention provides a device for supporting TSN, the device being configured to: determine a TSN control plane model for each of one or more TSN bridges in a communication network; obtain a symbolic language for each of the one or more TSN bridges based on the respective TSN control plane models of the one or more TSN bridges in the communication network; and obtain a distributed TSN verification model for the communication network distributed across the two or more TSN bridges based on the respective symbolic languages of the two or more TSN bridges.

[0071] The device may be an electronic device or may be incorporated into an electronic device, such as a personal computer, a server computer, a client computer, a notebook computer and a laptop computer, a tablet device, a mobile phone, a smart phone, etc.

[0072] In the case of a distributed TSN control plane, the verification device may enable a global perspective. Additionally, in a fully distributed scenario, in-band verification in a specified TSN device (such as a bridge or a switch) may be applied.

[0073] Furthermore, in some embodiments, a new process for verification with a TSN-specified switch may be provided for the device of the first aspect or the device of the second aspect. For example, TSN verification may be performed based on a feedback loop. For example, the feedback loop may be such that 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 a new event to update, correct, or improve the configuration through the feedback loop using the TSN control plane.

[0074] The device of the second aspect may be similar to or the same as 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.

[0075] In an implementation of the second aspect, in a fully distributed TSN control plane, the device is further configured to: when selected as a specified verification TSN bridge with a logical global perspective, perform a verification process based on the distributed TSN verification model.

[0076] A third aspect of the present 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 in a communication network; obtaining a symbolic language for each of the one or more entities based on the respective TSN control plane models of the one or more entities in the communication network; obtaining an integrated symbolic language for 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 one or more entities in the communication network; and obtaining a TSN verification model for the communication network based on the integrated symbolic language.

[0077] In an implementation of the third aspect, the method further includes: determining the validity of the TSN configuration and / or the change of the TSN configuration based on the TSN verification model of the communication network.

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

[0079] In another implementation of the third aspect, the TSN control plane model of each entity is obtained based on the functions provided by the entity.

[0080] In another implementation of the third aspect, the method further includes obtaining the TSN data plane model of each entity in one or more entities of the communication network.

[0081] In another implementation of the third aspect, the TSN verification model of the communication network is also obtained based on at least one TSN data plane model in the TSN data plane models.

[0082] In another implementation of the third aspect, the method further includes: receiving a verification model of layer 2 or layer 3 or TSN operations from an external library or 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.

[0083] In another implementation of the third aspect, the method further includes: analyzing the obtained TSN data plane model; and further updating the TSN verification model of the communication network based on the analysis result.

[0084] In another implementation of the third aspect, the method further includes obtaining the TSN verification model of the communication network additionally based on the characteristics of the communication network.

[0085] In another implementation of the third aspect, the characteristics of the communication network include (for example, not only in terms of TSN, but also) the VLAN state of the communication network during the verification process, or the PTP state of the communication network during the verification process.

[0086] In another implementation of the third aspect, the method further includes: for the cases of fully centralized control plane and hybrid control plane, performing communication related to the TSN verification model between the device and at least one entity of the communication network through the NETCONF interface.

[0087] In another implementation of the third aspect, the method further includes: deriving the control plane model of the entity in the case where the TSN control plane model of the entity is unknown before obtaining the TSN verification model of the communication network.

[0088] In another implementation of the third aspect, the method further includes: receiving a request to change a given TSN configuration; determining configuration errors and configuration quality of the given TSN configuration based on an integrated symbolic language; and providing a verification result, particularly whether the change to the given TSN configuration should be allowed.

[0089] In another implementation of the third aspect, the method further includes: in the case where the change to the given TSN configuration is determined not to be allowed, handling a rejection error; and negotiating the rejection error by providing a set of recommendations to a calling function of a TSN configuration verification module.

[0090] In another implementation of the third aspect, the method further includes: verifying verification parameters based on a TSN verification model of a communication network, the verification parameters such as:

[0091] · A joint investigation of the TSN configuration with aspects of layer 2 or layer 3 of the communication network;

[0092] · The reachability of a speaker to a listener in the communication network;

[0093] · In the case of time-aware shaping, or verification of asynchronous time shaping operations, or cyclic queuing and forwarding, the steady-state existence of a candidate scheduler;

[0094] · Bounded path length;

[0095] · Bounded delay;

[0096] · Preemption ability.

[0097] In another implementation of the third aspect, the method is used for:

[0098] · CNC, or

[0099] · SDN controller, or

[0100] · TSN-aware device, or

[0101] · TSN bridge.

[0102] The method of the third aspect realizes the advantages and effects described for the device of the first aspect.

[0103] A fourth aspect of the present invention provides a method for a time-sensitive network, the method including: determining a TSN control plane model of each of one or more TSN bridges in a communication network; obtaining a symbolic language of each of the one or more TSN bridges based on the respective TSN control plane models of the one or more TSN bridges in the communication network; and obtaining a decentralized TSN verification model of the communication network distributed across two or more TSN bridges based on the respective symbolic languages of the two or more TSN bridges.

[0104] In an implementation of the fourth aspect, in a fully distributed TSN control plane, the method further includes: when being selected as a designated verification TSN bridge having a logical global perspective, performing a verification process based on the distributed TSN verification model.

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

[0106] A fifth aspect of the present invention provides a computer program, the computer program including program code for performing the method according to the third aspect or the fourth aspect or any implementation thereof.

[0107] A sixth aspect of the present invention provides a non-transitory storage medium storing executable program code, the executable program code causing the method according to the third aspect or the fourth aspect or any implementation thereof to be executed when being executed by a processor.

[0108] It should be noted that all devices, elements, units, and apparatuses described in the present application may be implemented by software or hardware elements or any combination thereof. All steps performed by various entities described in the present application and the functions to be performed by various entities described are intended to mean that the corresponding entities are adapted to or are used to perform the corresponding steps and functions. In the following description of specific embodiments, although the specific functions or steps to be performed by external entities are not reflected in the description of the specific detailed elements of the entities performing the specific steps or functions, those skilled in the art should clearly understand that these methods and functions may be implemented by corresponding hardware or software elements or any combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0109] In the following description of specific embodiments, the above aspects and implementations will be elaborated in conjunction with the accompanying drawings, in which:

[0110] Figure 1 Devices for supporting TSN operations according to embodiments of the present invention are shown;

[0111] Figure 2 Another device for supporting a distributed TSN control plane according to embodiments of the present invention is shown;

[0112] Figure 3 is a schematic diagram showing an illustration of a TSN verification module based on software components inside a CNC;

[0113] Figure 4 is a schematic diagram showing an illustration of multi-vendor control plane integration;

[0114] Figure 5 is a schematic diagram showing a flowchart of a process for creating an abstract control plane model for an entity;

[0115] Figure 6 is a schematic diagram showing an illustration of model construction;

[0116] Figure 7 is a schematic diagram showing an illustration of a multi-layer verification process;

[0117] Figure 8 is a schematic diagram showing an illustration of verification module deployment for a fully distributed TSN control plane;

[0118] Figure 9 is a schematic diagram showing an illustration of the addition of a verification model implemented as an extension on 802.1dj;

[0119] Figure 10 shows a method for supporting TSN operations according to an embodiment of the present invention; and

[0120] Figure 11 shows another method for supporting distributed TSN operations according to an embodiment of the present invention. Detailed Description

[0121] Figure 1 shows a device 100 for supporting TSN configuration verification operations according to an embodiment of the present invention.

[0122] The device 100 is configured to determine the TSN control plane models 101, 102, 103 of each of one or more entities 11, 12, 13 in the communication network 1. For example, the communication network 1 may include one or more entities 11, 12, and 13.

[0123] The device 100 is further configured to obtain the symbolic languages 111, 112, 113 of each of one or more entities 11, 12, 13 based on the respective TSN control plane models 101, 102, 103 of the one or more entities 11, 12, 13 in the communication network 1.

[0124] Device 100 is also used to obtain an integrated symbol language 120 of communication network 1 based on the symbol languages 111, 112, 113 of one or more entities 11, 12, 13, wherein the integrated symbol language 120 indicates one or more relationships between one or more entities 11, 12, 13 in communication network 1.

[0125] Device 100 is also used to obtain a TSN verification model 130 of communication network 1 based on the integrated symbol language 120.

[0126] The TSN verification model 130 of device 100 can be obtained independently of the distributed protocol used, or even in the case of implementing a centralized scenario. In addition, the verification model of the device can be easily integrated into the existing configuration mechanisms defined in, for example, 802.1Qcc and / or 802.1Qdd. The device can not only verify TSN attributes, but also verify all components that need to be in the correct state in order to have an end-to-end functional TSN network.

[0127] In addition, the integrated symbol language 120 and / or verification model 130 of device 100 can enable the verification of large instances of combined search problems for hardware and software verification, for example, using semantic modeling based on SAT and satisfiability modulo theory (SMT).

[0128] In addition, device 100 can avoid distributing incorrect configurations that may cause instability in the overall network.

[0129] The integrated symbol language 120 and / or verification model 130 of device 100 can also be extended to cover multi-domain verification processes.

[0130] Device 100 may include a processing circuit ( Figure 1(not shown in the figure), the processing circuit is used to execute, perform, or initiate various operations of the device 100 described herein. The processing circuit may include hardware and software. The hardware may include analog circuits or digital circuits, or both analog and digital circuits. 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 general-purpose processor. In one embodiment, the processing circuit includes 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, and when the executable program code is executed by the one or more processors, it causes the device 100 to execute, perform, or initiate the operations or methods described herein.

[0131] Figure 2 Another device 200 for supporting distributed TSN control plane operations according to an embodiment of the present invention is shown.

[0132] The device 200 is used to determine the TSN control plane models 201, 202, 203 of each of the one or more TSN bridges 21, 22, 23 in the communication network 1. For example, the communication network 1 may include the device 200 and one or more TSN bridges 21, 22, 23. In addition, the device 200 may have a global perspective, and the one or more TSN bridges 21, 22, 23 may have a local perspective.

[0133] The device 200 is further used to: obtain the symbolic languages 211, 212, 213 of each of the one or more TSN bridges 21, 22, 23 based on the respective TSN control plane models 201, 202, 203 of the one or more TSN bridges 21, 22, 23 in the communication network 1.

[0134] The device 200 is further used to: obtain the distributed TSN verification model 230 of the communication network 1 distributed on two or more TSN bridges 21, 22, 23 based on the respective symbolic languages 201, 202, 203 of two or more TSN bridges 21, 22, 23.

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

[0136] The device 200 may include a processing circuit ( Figure 2(not shown in the figure), the processing circuit is used to execute, perform, or initiate various operations of the device 200 described herein. The processing circuit may include hardware and software. The hardware may include analog circuits or digital circuits, or both analog and digital circuits. 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 general-purpose processor. In one embodiment, the processing circuit includes 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, and when the executable program code is executed by the one or more processors, it causes the device 200 to execute, perform, or initiate the operations or methods described herein.

[0137] Now refer to Figure 3 , Figure 3 FIG. is a schematic diagram of the device 100 obtaining the TSN verification model 130 based on software elements inside the CNC.

[0138] Figure 3 FIG. shows the architecture of the device 100 for obtaining the TSN verification model 130. For example, for both the hybrid and fully centralized cases, the verification model 130 can be obtained through a verification module incorporated as a software element in the CNC.

[0139] The verification module of the device 100 communicates periodically or event-based with the local verification module proxy 311 of the local agent 311 in each TSN-enabled 802.1 bridge 310 through the management interface 304 (such as Netconf) to retrieve operation status information about information such as port status, link status, PTP status, VLAN information, queuing dynamics, etc.

[0140] The local agent 311 can operate inside the IEEE TSN bridge 310. The local agent 311 can run at each bridge used to offload the CNC. The local agent 311 can be used to minimize the communication overhead between the CNC and the TSN bridge for all required operations and configuration data. In addition, local processing can be performed where applicable.

[0141] The device 100 (e.g., the verification module of the device 100) may have the following functions.

[0142] Device 100 may obtain (e.g., derive) an abstract model of the control plane for each TSN device in communication network 1. In a multi-vendor environment, this functionality may vary. Additionally, device 100 may determine symbolic languages 111, 112, 113 based on control plane models 101, 102, 103 for each TSN device in the network.

[0143] Device 100 may also obtain (e.g., determine) an integrated symbolic language 120 to answer end-to-end queries and also capture interdependencies.

[0144] Device 100 may also derive an interface to a third-party tool that can perform layer 2 / layer 3 verification such as Minesweeper, Batfish, SymNet, or Veriflow. Additionally, 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.

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

[0146] Additionally, upon request for a configuration update, depending on the result of the verification process, a set of return codes may be provided that can describe the following different scenarios:

[0147] a) No obvious errors or poor performance - the configuration can be accepted and applied.

[0148] b) An error is found - the configuration must be rejected.

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

[0150] Additionally, in the case where a configuration update is rejected, a set of suggestions for the call function of the configuration verification module may be provided.

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

[0152] For the centralized configuration model, there are the following two sub-cases:

[0153] Scenario 1: Fully centralized: In this case, the speaker and the listener communicate with the CUC entity to describe the service requirements. In this case, protocols such as PTCC or Restconf or Netconf can be used together with 802.1Qdj to transfer information to the CNC entity.

[0154] Scenario 2: User to network interface (UNI) (enhanced SRP) can be used to transfer service requirements and related speaker / listener information to the CNC via an edge bridge.

[0155] After the service requirements are specified and collected, the service requirements are further transferred to the CNC. In the CNC and other control processes or information (e.g., topology information), the TSN scheduling decision is made by, for example, a TSN scheduling software entity. However, instead of the self-organizing deployment scheduling decision, the verification module can determine whether the configuration request should be permitted.

[0156] In particular, device 100 can consider the process of performing the verification process. In other words, the process of transferring relevant information to the control entity or making the scheduling decision can be disregarded.

[0157] Now refer to Figure 4 , Figure 4 which is a schematic diagram showing a diagram of multi-vendor control plane integration.

[0158] Multi-vendor control plane integration can be performed by device 100 and / or device 200. Hereinafter, the multi-vendor control plane integration is discussed as a process performed by device 100.

[0159] For example, device 100 can obtain a control plane model during the verification module initialization process.

[0160] As a first step during the initialization phase, an abstract model of the TSN control planes 101, 102, 103 for each of the devices 11, 12, 13 is obtained based on the TSN features or the functions it supports. An example of such a process is discussed with respect to Figure 5 .

[0161] In addition, although the TSN working group of IEEE802.1 has clearly specified the TSN management objects and the management information base (MIB), however, each vendor can have its own model and can also use its own semantics and implementation methods, which may not be fully aligned with the standard definitions.

[0162] In addition, to perform end-to-end configuration verification, when operating on a multi-vendor TSN network, device 100 can initially obtain (e.g., generate) models of the control planes 101, 102, 103 for each TSN bridge device 11, 12, 13.

[0163] Next, a symbolic modeling step can be performed, and then an integration step can be performed. Device 100 obtains the symbolic languages 111, 112, 113 of these entities based on the respective TSN control plane models 101, 102, 103 of the entities ( Figure 4 devices 11, 12, and 13 in). In addition, device 100 can finally derive an integrated end-to-end control plane model 401 and a corresponding integrated symbolic language 120.

[0164] Now referring to Figure 5 , Figure 5 is a schematic diagram of a flowchart of a process 500 for creating a control plane model for an entity.

[0165] Process 500 can be executed by device 100 and / or device 200. Hereinafter, process 500 is exemplarily discussed as being executed by device 100.

[0166] At step 501, device 100 or device 200 initiates a verification initialization phase for each entity. For example, these entities can be TSN bridges.

[0167] At step 502, device 100 or device 200 can determine whether the control plane of the entity is known. In addition, when the determination is "no", device 100 or device 200 performs step 503. In addition, when the determination is "yes", device 100 or device 200 performs step 504.

[0168] At step 503, device 100 or device 200 applies model learning techniques to derive a control plane model of the entity.

[0169] For example, when the control plane of the entity is unknown, such as when no YANG model can be used to model the operation of the TSN device, device 100 or device 200 can treat the entity as a black box. Then, model learning techniques can be applied to derive a control plane model. For example, device 100 or device 200 can apply a learning algorithm such as Lstar to create an unknown state diagram by sending input queries to the entity and analyzing the output. In addition, according to the learning process, three cases also describe the relationship with the TSN standard, including the relationship with the TSN standard when the implementation methods are completely aligned, not aligned, or partially aligned.

[0170] At step 504, for example, in the case where the control plane model is known or the control plane is obtained in device 100 or device 200 (e.g., in step 503).

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

[0172] For example, after obtaining the model in step 504, for each TSN entity in the communication network, device 100 or device 200 can construct a symbolic language model, which can be defined as a set of attributes, rules, constraints, etc.

[0173] Generally, symbolic language modeling can include a set of symbols (variables), which can represent data types, attributes, or actions. In addition, regardless of the management protocol used (e.g., Netconf, Restconf, SNMP), in order to retrieve control plane information, device 100 or device 200 can define a mechanism to convert configuration parameters and attributes into variables based on symbolic modeling.

[0174] In addition, device 100 or device 200 can perform integration processing to integrate the symbolic language into the end-to-end symbolic model of the control plane, and if further used through the configuration verification module, these rules related to the configuration reception event can be processed. For example, the symbolic language can be used to execute queries and become part of the verification FSM execution process.

[0175] In addition, there may be the following three cases:

[0176] · When the control plane model of the entity is consistent with the actual implementation of the TSN standard or a subset (or the whole set) of the revision, device 100 executes step 506 and marks the abstract model of the control plane as fully aligned.

[0177] · The control plane model of the entity is partially aligned with the TSN standard - revision set. For example, perhaps 802.1CB is supported, but a customized preemption process or a customized queuing structure is followed. Device 100 executes step 507 and marks the abstract model of the control plane as partially aligned.

[0178] · The control plane model of the entity is not aligned with the TSN standard - revision set. Device 100 executes step 508 and marks the abstract model of the control plane as not aligned.

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

[0180] In some embodiments, after obtaining the control plane model for each device and analyzing the control plane model, device 100 or device 200 may design the TSN symbolic language based on the model. Symbolic modeling can also be used to model dependencies, data plane constraints, and TSN attributes. For example, symbolic modeling can be used to parse the received TSN configuration instructions into the arguments of logical formulas. For example: IPs×ports×IPd×portd×schedule_entry_feasible→{true,false}.

[0181] Now refer to Figure 6 , Figure 6 which is a schematic diagram of an illustration 600 showing model construction. The model construction can be performed by device 100 or device 200.

[0182] In block 601 of illustration 600, the YANG part describes the GCL information according to the 802.1Qcw required by 802.1Qbv. As can be seen from block 601, the YANG part specifies that sgs information is required, the related gate operation is described by "gate-status-value", and the gate period is described by "time-interval-value".

[0183] In block 602 of illustration 600, a vendor-specific model is provided, which indicates support for 802.1Qbv. Among them, for the GCL, the ingress gate is an operation described by the field "gate", and the corresponding period is described by the field "time".

[0184] The verification module of device 100 or device 200 can compare the two files obtained based on the TSN standard model 603 and the TSN vendor model 604, and can also make inference decisions to identify which parts of the device model follow the standard description. In this case, SRS is supported and SRS can be part of the device model (although the vendor-specific implementation uses different names), but shm and srm are not supported. In addition, all the results of all comparisons together with additional methods for capturing dependencies and constraints are part of the TSN symbolic model 605, where the symbolic variables are designed based on the standard description and the comparison results. For example, a Boolean variable x1 can be introduced to describe whether preemption support exists.

[0185] In the previous step, symbolic models are obtained for each entity 11, 12, 13. In addition, after obtaining the symbolic models for all entities, in the next step, an integrated verification symbolic language that can also capture the dependencies between devices or models can be constructed to perform end-to-end verification tests.

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

[0187] · Integrated control plane symbol model.

[0188] · Configuration data (TSN and other information related to, for example, ACL).

[0189] · Configuration to be applied (configuration data such as scheduler decisions to be applied, speaker requirements, etc.).

[0190] · Operational data (statistics, other layer 2 / layer 3 information such as VLAN status or PTP information regarding time synchronization).

[0191] In addition, device 100 or device 200 may also consider operational data inputs (e.g., ports are synchronized, VLANs are set, listeners are reachable, etc.). In addition, as part of the integrated symbol model, device 100 or device 200 may capture dependency issues. For example, 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. In addition, it is meaningless to update many hops of switches that are not aware of this.

[0192] In addition, device 100 or device 200 may also use data plane constraints and TSN attributes as part of the integrated symbol model.

[0193] Now referring to Figure 7 , Figure 7 is a schematic diagram of an illustration 700 showing a multi-layer verification process. The multi-layer verification can be performed by device 100 or device 200. Hereinafter, the multi-layer verification process is exemplarily discussed as a process performed by device 100 without limiting the present invention.

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

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

[0196] Device 100 may connect the TSN verification module to other available verification mechanisms to perform pure layer 2, layer 3, and higher layer verification operations, such as Minesweeper, Batfish, SymNet, Veriflow, etc. In addition, 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.

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

[0198] In addition, when the device 100 determines verification, for example, when a verification decision is to be made, the decision-making process also takes into account the higher-layer state.

[0199] 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 meets a wide range of expected properties, such as reachability or isolation between nodes, waypoints, black holes, bounded path lengths, load balancing, functional equivalence of two forwarding devices, etc. These properties can be used to quickly verify aspects of the interaction between TSN and higher layers.

[0200] In some embodiments, the device 100 or the device 200 may perform verification operations or symbolic checks.

[0201] For example, a configuration change or update request (via a protocol such as PTCC, through enhanced SRP in a hybrid case or through CUC in a fully distributed case) may trigger necessary verification module operations such as communication in order to retrieve the operation state, execute and reason about symbolic modeling queries, and actions such as discarding, applying, or optimizing the requested configuration update.

[0202] For example, the device 100 or the device 200 may actively analyze the resulting data plane that may reflect the combined impact of all configuration aspects. In particular, the device 100 or the device 200 may build a set of TSN data plane models based on the control plane model and the actual configuration to be applied. Thereafter, the device 100 or the device 200 may determine whether the configuration can be tolerated based on a set of query execution and evaluation checks. For example, semantic modeling may be used to verify configuration errors, misconfigurations, policy violations, and potential security threads. The device 100 or the device 200 may also discover errors before the TSN network generates and distributes an erroneous data plane.

[0203] In addition, device 100 or device 200 may convert the received configuration into a set of semantic logic formulas. For example, as a result of the interaction between TSN-enabled devices such as switches, gateways, and endpoints, device 100 or device 200 may capture the stable state to which the TSN data plane can converge (in the case where convergence exists). In addition, device 100 or device 200 may also convert the received TSN message passing regarding configuration instructions into the following logical formula:

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

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

[0206] In addition, device 100 or device 200 may generate a request to perform a symbolic check on a configuration change or update. For example, device 100 or device 200 may, based on a verification model, traverse only the states and parts of the network affected by the change, rather than investigating all possible states. For example, if there is a plan to update the 802.1Qbv operation, 802.1Qbu may not be affected. However, if there is a plan to update 802.1Qci, 802.1Qbu may be affected because the flow may be completely blocked.

[0207] For the checking phase, device 100 or device 200 may consider the relevant part of the verification model that can be described as a deterministic Mealy machine. A Mealy machine is a finite state machine whose output values are determined by its current state and current input.

[0208] Device 100 or device 200 may identify the following multiple potential verification results:

[0209] · Accept (mandatory): The configuration is accepted as is and can be applied to the running configuration.

[0210] · Reject (mandatory): The configuration is rejected by a report on an error or a discovered potential performance degradation factor and verification result.

[0211] · Negotiate (optional): In this case, specific problem parts of the configuration are identified for a specific entity.

[0212] · These results can be transmitted back to the resident calling function, such as CUC.

[0213] Next, the negotiation module is discussed. In addition to "accept" and "reject", the device 100 or the device 200 can 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 workarounds 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 verification module mechanism creates a feedback loop. If the verification result is negative, the device of the present invention provides a new interface to trigger a new event from the verification module to update / correct / improve the configuration through the feedback loop using the TSN control plane. Since the verification process is extremely complex, the negotiation module relies on the findings of the main verification activities to gradually fine-tune the parameterization instead of restarting the verification process from scratch.

[0214] Now refer to Figure 8 , Figure 8 which is a schematic diagram showing the deployment of the verification module for a fully distributed configuration.

[0215] For example, the device 200 can perform TSN verification for a fully distributed TSN control plane.

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

[0217] In Figure 8 , the device 200 is based on a TSN bridge with a global perspective. In addition, the entities 21, 22, 23 are based on TSN bridges with a local perspective.

[0218] For example, the device 200 can use the designated spanning tree selected by operating the switch according to the spanning tree protocol (STP) as the designated verification bridge.

[0219] When STP is enabled and responsible for forwarding graph establishment, the bridge ID priority can be used to select the root bridge. In addition, only the verification module can be installed, and the verification module can also run on the selected STP root bridge. For variants of STP such as MSTP and RSTP, similar processing can be performed. For example, the root bridge can control the spanning tree topology and can be a hub that connects other switches by establishing logical adjacency relationships with all switching entities on the network to provide global perspective information. The relevant information passed between the root verification module (for example, device 200 with a global perspective) and different local verification agents deployed at each bridge is completed on the LRP / RAP or LRP as the preferred additional application.

[0220] Next, an example of abstract model construction that can be performed by device 100 or device 200 is discussed.

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

[0222] First, device 200 determines whether the implementation supports the definition and encoding of which managed objects according to the TSN standard, such as frame preemption according to 802.1Qbu, scheduled traffic according to 802.1Qbv, frame replication and elimination according to 802.1CB, etc.

[0223] For this purpose, device 200 performs an exhaustive recursive investigation to analyze the TSN control plane. In addition, device 200 can also build an abstract symbolic model based on YANG definitions (such as the IEEE 802.1Qcp YANG model for bridging, the IEEE802.1Qcw YANG model for Qbv, Qbu, Qci) and by transforming attributes into symbolic variables.

[0224] For example, device 200 can obtain a sample of frame-preemption-parameters according to 802.1Qcw as follows:

[0225] ·uint32 hold-advance / / r

[0226] ·uint32 release-advance / / r

[0227] ·boolean preemption-active / / r

[0228] ·enum hold-request / / r

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

[0230] Now refer to Figure 9 , Figure 9 which is a schematic diagram showing the addition of a verification model implemented as an extension on 802.1dj.

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

[0232] Figure 10 A method 1000 for a time-sensitive network according to an embodiment of the present invention is shown. Method 1000 may be executed by device 100 as described above.

[0233] Method 1000 includes step 1001: determining the TSN control plane models 101, 102, 103 of each of one or more entities 11, 12, 13 in the communication network 1.

[0234] Method 1000 further includes step 1002: obtaining the symbol languages 111, 112, 113 of each of one or more entities 11, 12, 13 based on the respective TSN control plane models 101, 102, 103 of one or more entities 11, 12, 13 in the communication network 1.

[0235] Method 1000 further includes step 1003: obtaining an integrated symbol language 120 of the communication network 1 based on the symbol languages 111, 112, 113 of one or more entities 11, 12, 13, where the integrated symbol language 120 indicates one or more relationships between one or more entities 11, 12, 13 in the communication network 1.

[0236] Method 1000 further includes step 1004: obtaining a TSN verification model 130 of the communication network 1 based on the integrated symbol language 120.

[0237] Figure 11Method 1100 for a time-sensitive network according to an embodiment of the present invention is shown. Method 1100 may be executed by device 200 as described above.

[0238] Method 1100 includes step 1101: determining a TSN control plane model 201, 202, 203 for each of one or more TSN bridges 21, 22, 23 in communication network 1.

[0239] Method 1100 further includes step 1102: obtaining a symbolic language 211, 212, 213 for each of one or more TSN bridges 21, 22, 23 based on the respective TSN control plane models 201, 202, 203 of the one or more TSN bridges 21, 22, 23 in communication network 1.

[0240] Method 1100 further includes step 1103: obtaining a distributed TSN verification model 230 of communication network 1 distributed over 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.

[0241] The present invention has been described in connection with various embodiments and implementations by way of example. However, upon study of the drawings, the present invention, and the independent claims, those skilled in the art will be able to understand and implement other variations for practicing the claimed invention. 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 mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A device (100) for supporting Time-Sensitive Networking (TSN) operations, characterized in that, The device (100) is used for: determining the TSN control plane models (101, 102, 103) of each of one or more entities (11, 12, 13) in a communication network (1); obtaining the symbolic languages (111, 112, 113) of each of the one or more entities (11, 12, 13) based on the respective TSN control plane models (101, 102, 103) of the one or more entities (11, 12, 13) in the communication network (1); 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 (120) 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 device (100) according to claim 1, characterized in that, It is also used for: determining the effectiveness of a TSN configuration and / or a change in the TSN configuration based on the TSN verification model (130) of the communication network (1).

3. The device (100) according to claim 1, wherein: the integrated symbolic language (120) includes 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 plane models (101, 102, 103) of the one or more entities (11, 12, 13).

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

5. The device (100) according to any one of claims 1 to 3, characterized in that, It is also used for: obtaining the TSN data plane models (301, 302, 303) of each of the one or more entities (11, 12, 13) in the communication network (1).

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

7. The device (100) according to any one of claims 1 to 3, characterized in that, It is also used for: receiving a layer 2 or layer 3 or a verification model of 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 the TSN verification model (130) of the communication network (1) based on the updated integrated symbolic language.

8. The device (100) according to claim 5, characterized in that, It is also used for: analyzing the obtained TSN data plane models; and further updating the TSN verification model (130) of the communication network (1) based on the results of the analysis.

9. The device (100) according to any one of claims 1 to 3, characterized in that, It is also used for: In addition, a TSN verification model (130) of the communication network (1) is obtained based on the characteristics of the communication network (1).

10. The apparatus (100) according to claim 9, wherein, the characteristics of the communication network (1) include: the virtual local area network VLAN state of the communication network (1) during the verification process, or the precise time protocol PTP state of the communication network (1) during the verification process.

11. The device (100) according to any one of claims 1 to 3, characterized in that, comprising: a network configuration protocol NETCONF interface (304) for: performing communication related to the TSN verification model (130) between the apparatus (100) and at least one entity of the communication network (1).

12. The device (100) according to any one of claims 1 to 3, characterized in that, also for: before obtaining the TSN verification model (130) of the communication network (1), deriving the control plane models of the entities (11, 12, 13) when the TSN control plane models (101, 102, 103) of the entities (11, 12, 13) are unknown.

13. The device (100) according to any one of claims 1 to 3, characterized in that, also for: receiving a request to change a given TSN configuration; determining the configuration error and configuration quality of 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 device (100) according to claim 13, characterized in that, also for: processing a rejection error in the case where the change to the given TSN configuration is determined not to be allowed; and negotiating the rejection error by providing a set of recommendations to the call function of the TSN configuration verification module.

15. The device (100) according to any one of claims 1 to 3, characterized in that, also for: verifying verification parameters based on the TSN verification model (130) of the communication network (1), the verification parameters including: a joint investigation of the TSN configuration with the layer 2 or layer 3 aspects of the communication network; the reachability of speakers to listeners in the communication network; the steady-state existence of candidate schedulers in the case of time-aware shaping, or verification of asynchronous time shaping operations, or cyclic queuing and forwarding; bounded path length; bounded delay; preemption ability.

16. The apparatus (100) according to any one of claims 1 to 3, wherein: the apparatus (100) is incorporated into: a centralized network controller CNC, or a software-defined network SDN controller, or a TSN-aware device, or a TSN bridge.

17. A device (200) for supporting Time-Sensitive Networking (TSN) operations, characterized in that, The apparatus (200) is for: determining the TSN control plane models (201, 202, 203) of each of one or more TSN bridges (21, 22, 23) in the communication network (1); obtaining the symbol languages (211, 212, 213) of each of the one or more TSN bridges (21, 22, 23) based on the respective TSN control plane models (201, 202, 203) of the one or more TSN bridges (21, 22, 23) in the communication network (1); and Obtain a distributed TSN verification model (230) of the communication network (1) distributed over the two or more TSN bridges (21, 22, 23) based on the respective symbol languages (201, 202, 203) of the two or more TSN bridges (21, 22, 23).

18. The device (200) according to claim 17, characterized in that: In a fully distributed TSN control plane, the device (200) is further configured to: when selected as a specified verification TSN bridge with a logical global perspective, perform a verification process based on the distributed TSN verification model (230).

19. A method (1000) for a time-sensitive network, characterized in that, The method (1000) includes: Determine (1001) the TSN control plane models (101, 102, 103) of each of one or more entities (11, 12, 13) in the communication network (1); Obtain (1002) the symbol language (111, 112, 113) of each of the one or more entities (11, 12, 13) based on the respective TSN control plane models (101, 102, 103) of the one or more entities (11, 12, 13) in the communication network (1); Obtain (1003) an integrated symbol language (120) of the communication network (1) based on the symbol languages (111, 112, 113) of the one or more entities (11, 12, 13), where the integrated symbol language (120) indicates one or more relationships between the one or more entities (11, 12, 13) in the communication network (1); and Obtain (1004) a TSN verification model (130) of the communication network (1) based on the integrated symbol language (120).

20. A method (1100) for a time-sensitive network, characterized in that, The method (1100) includes: Determine (1101) the TSN control plane models (201, 202, 203) of each of one or more TSN bridges (21, 22, 23) in the communication network (1); Obtain (1102) the symbol language (211, 212, 213) of each of the one or more TSN bridges (21, 22, 23) based on the respective TSN control plane models (201, 202, 203) of the one or more TSN bridges (21, 22, 23) in the communication network (1); and Obtain (1103) a distributed TSN verification model (230) of the communication network (1) distributed over the two or more TSN bridges (21, 22, 23) based on the respective symbol languages (201, 202, 203) of the two or more TSN bridges (21, 22, 23).

21. A non-transitory storage medium storing executable program code, characterized in that, When the executable program code is executed by a processor, cause the method (1000) according to claim 19 or the method (1100) according to claim 20 to be executed.

Images