WO2023151779A1

WO2023151779A1 - On-demand tsn re-configuration through precomputation and optional fsms

Info

Publication number: WO2023151779A1
Application number: PCT/EP2022/053058
Authority: WO
Inventors: Konstantinos ALEXANDRIS; Frank Matthias KOVATSCH; Nicola Sambo; Silvia FICHERA
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-02-09
Filing date: 2022-02-09
Publication date: 2023-08-17

Abstract

The disclosure proposes a first entity for a network node of a TSN comprising a group of network nodes. The first entity is configured to: obtain one or more FSMs and a current state of the one or more FSMs, wherein the one or more FSMs include information related to a set of re-configuration decisions, wherein each re-configuration decision defines a reconfiguration of one or more network nodes of the group of network nodes upon an event; determine a re-configuration of the network node in response to a certain event, based on the one or more FSMs and the current state of the one or more FSMs; and execute the determined re-configuration of the network node. Further, the disclosure proposes a second entity being configured to compute the set of re-configuration decisions and encode the set of re-configuration decisions in one or more FSMs.

Description

ON-DEMAND TSN RE-CONFIGURATION THROUGH PRECOMPUTATION AND OPTIONAL FSMs

TECHNICAL FIELD

The present disclosure relates to communication networks, and particularly to Time Sensitive Networking (TSN). In order to improve the overall system (real-time) response, and to remove dependencies on a centralized controller, the disclosure proposes a distributed approach for enabling local TSN re-configuration decisions and immediate reactions. To this end, the disclosure presents a first entity, a second entity, and corresponding methods for the TSN re-configuration.

BACKGROUND

TSN strives to achieve stringent requirements on reliability, delay, and jitter to enable a converged network for “Industry 4.0” applications. The requirements are met through a number of different mechanisms that all require a significant amount of network configuration. With the requirements of high reliability and hard real-time communication, re-configuration of the network at runtime poses a technical problem, as ideally applications are not interrupted even when network conditions change and re -configuration must be applied.

A conventional methodology to handle network configuration, e.g., in the presence of network failure or other real-time event reaction, is fully centralized and cannot concern scalability and fast network recovery. However, following the Software Defined Networking (SDN) paradigm, fast service restoration, and holistic network overview is difficult to achieve in real-time systems. Thus, there is plenty of room for optimization regarding scalability and feedback control. Especially, for large-scale topologies when a failure arises, the re-configuration of the network at its initial state is impractical to be applied. Thus, the recovery time is impacted, since the SDN controller has a large number of requests to process. Therefore, the main challenge is to improve the overall system (realtime) response by limiting centralized (e.g., SDN) control process that is expensive in time and system complexity. SUMMARY

In view of the above, this disclosure has the objective to introduce a distributed approach for implementing a TSN re-configuration. Another objective is to make the TSN reconfiguration decisions locally, and thus to enable immediate reactions upon a network condition change. Another objective is to improve the reaction time for the TSN network re-configuration. A further objective is to remove a dependency on a centralized controller.

These and other objectives are achieved by the solution of the present disclosure as provided in the enclosed independent claims. Advantageous implementations are further defined in the dependent claims.

A first aspect of the disclosure provides a first entity for a network node of a Time Sensitive Network comprising a group of network nodes, the first network entity being configured to: obtain one or more finite state machines (FSMs), and a current state of the one or more FSMs, wherein the one or more FSMs include information related to a set of reconfiguration decisions, wherein each re-configuration decision defines a re-configuration of one or more network nodes of the group of network nodes upon an event; determine a re-configuration of the network node in response to a certain event, based on the one or more FSMs and the current state of the one or more FSMs; and execute the determined reconfiguration of the network node.

Accordingly, this disclosure proposes a solution for distributing re-configuration decisions in the form of FSMs to enable local decisions and immediate reactions. In this way, upon an event, e.g., a network condition change such as a link failure, congestion, etc., interaction with a centralized entity can be omitted and re-configuration can be applied directly on the same device or through pre-computed peer-to-peer communication, which is already taking the occurred network condition into account.

This disclosure proposes a method based on FSMs, which may store information related to events, network states, operations and network reconfigurations. In an implementation form of the first aspect, the one or more FSMs comprise at least a first state, a second state, and a third state, wherein the first entity is configured to: for the first state, instruct the network node to keep a current configuration; for the second state, instruct the network node to implement a re-configuration; and for the third state, send a state transition request to a particular network node to trigger a state transition.

Optionally, the FSMs may be described using the YANG model. For example, the YANG tree may present a list of states, where each <state> is associated with an identifier (<id>) and to a string of description (<description>). Notably, the FSMs may include a number of attributes. For instance, an attribute < current- state > defines the current state of the FSM. In addition, a list of actions may also be described. For example, each <action> may be defined by an identifier (<id>) and a type (<type>).

In an implementation form of the first aspect, when the current state of the one or more FSMs is the first state or the second state, a next state of the one or more FSMs is the third state when a network condition change occurs; when the current state of the one or more FSMs is the first state or the third state, a next state of the one or more FSMs is the second state when a state transition request from another first entity of on another network node of the group of network nodes is received; when the current state of the one or more FSMs is the second state or the third state, a next state of the one or more FSMs is the first state when a network condition change is restored.

Optionally, each state may present a list of transitions to other states, where each <transition> is associated with a name, a type (taken from a pool of possible transition types predefined inside the YANG model), a string of description, and other attributes.

In an implementation form of the first aspect, the one or more FSMs comprise a plurality of attributes including one or more of the following:

- an identifier or an address of a particular network node of the group of network nodes for which a state transition is needed,

- a next state of the particular network node.

Possibly, an action can be a conditional action. That is, the action is executed depending on the check of specific conditions, which may be described through the attributes. Possibly, an action can also be directly executed. An action can be taken locally or toward a remote node, i.e., a particular network node. In the second case, the identifier or the address of the particular network node may be needed as an attribute to specify which node has to be involved.

In an implementation form of the first aspect, wherein for the third state, the sending a state transition request to a particular network node to trigger a state transition comprises: determining the particular network node based on the plurality of attributes, and sending the state transition request to a particular first entity of that particular network node.

In an implementation form of the first aspect, the first state is a “Stable” state, the second state is a “Function” state, and the third state is an “Alert” state, wherein for the “Function” state, instructing the network node to implement a re-configuration comprises instructing the network node to perform one or more operations on an incoming stream.

In an implementation form of the first aspect, the one or more operations comprise generating a replication of the incoming stream, and/or relocating the incoming stream.

In a particular implementation, the FSM-based TSN re-configuration mechanism can be introduced to guarantee resilience against sequential failures while limiting/minimizing frame replicas in conjunction with Frame Replication and Elimination for Reliability (FRER). The FSM is distributed to each network node and acts locally to affect the network node behavior in FRER. In this case, the “Function” state of the FSM may also be referred to as “FRER” state.

In another implementation, the FSM-based TSN re-configuration mechanism can be introduced for path re-allocation in case of performance degradation, e.g., a stream cannot meet delay requirements. For instance, the “Function” state of the FSM as discussed in the previous embodiment may be named as “Reroute” state.

In an implementation form of the first aspect, the one or more FSMs further comprise one or more of the following attributes:

- an identifier of an incoming stream on which the one or more operations are to be performed, - one or more parameters for implementing frame replication and elimination.

In an implementation form of the first aspect, the first entity is further configured to: receive a state transition request from another first entity of another network node of the group of network nodes; determine the incoming stream based on the plurality of attributes; and instruct the network node to perform the one or more operations for the determined incoming stream.

Possibly, in the case that another network node or the local agent of the other network node detects a network condition change and identifies that a state transition on the first entity is needed, a state transition request may be sent to the first entity.

In an implementation form of the first aspect, the network condition change includes one or more of the following: a link failure, a device failure, a network congestion, and a performance degradation.

In an implementation form of the first aspect, the first entity is further configured to obtain the one or more FSMs and the current state of the one or more FSMs from a second entity.

Notably, the second entity may be an entity with a global view, such as an SDN controller, which with the knowledge of precomputed re-configuration decisions.

A second aspect of the disclosure provides a second entity configured to compute a set of re-configuration decisions based on network information of a TSN comprising a group of network nodes, wherein each re-configuration decision defines a re-configuration of one or more network nodes of the group of network nodes upon an event; and encode the set of re-configuration decisions in one or more FSMs.

Another aspect of this disclosure proposes a second entity with a global view, e.g., an SDN controller or a temporarily elected entity through a consensus algorithm, for precomputing re-configuration decisions and encoding them in one or multiple FSMs to apply decisions immediately when an event occurs. In an implementation form of the second aspect, computing the set of re-configuration decisions is further based on a pre-considered network condition change including one or more of the following: a link failure, a device failure, a network congestion, and a performance degradation.

Notably, for calculating the re-configuration decisions that the local network node can apply upon a network condition change, the second entity should take the occurred network condition into account.

In an implementation form of the second aspect, the second entity is further configured to distribute the one or more FSMs to one or more first entities, wherein each first entity is run locally on a network node of the group of network nodes.

In an implementation form of the second aspect, the one or more FSMs comprise at least a first state, a second state, and a third state, wherein the first entity is configured to: for the first state, a network node executing the one or more FSMs is instructed keep a current configuration; for the second state, a network node executing the one or more FSMs is instructed to implement a re-configuration; and for the third state, a network node executing the one or more FSMs is instructed to send a state transition request to a particular network node to trigger a state transition.

In an implementation form of the second aspect, when the current state of the one or more FSMs is the first state or the second state, a next state of the one or more FSMs is the third state when a network condition change occurs; when the current state of the one or more FSMs is the first state or the third state, a next state of the one or more FSMs is the second state when a state transition request from another first entity of on another network node of the group of network nodes is received; when the current state of the one or more FSMs is the second state or the third state, a next state of the one or more FSMs is the first state when a network condition change is restored.

In an implementation form of the second aspect, the one or more FSMs comprise a plurality of attributes including one or more of the following:

- an identifier or an address of a particular network node of the group of network nodes for which a state transition is needed, - a next state of the particular network node.

In an implementation form of the second aspect, the first state is a “Stable” state, the second state is a “Function” state, and the third state is an “Alert” state, wherein for the “Function” state, the network node executing the one or more FSMs is instructed to perform one or more operations on an incoming stream.

In an implementation form of the second aspect, the one or more operations comprise generating a replication of the incoming stream, and/or relocating the incoming stream.

In an implementation form of the second aspect, the one or more FSMs further comprise one or more of the following attributes:

- an identifier of an incoming stream on which the one or more operations are to be performed,

- one or more parameters for implementing frame replication and elimination.

A third aspect of the disclosure provides a first entity for a network node of a TSN comprising a group of network nodes, wherein the method comprises: obtaining one or more FSMs and a current state of the one or more FSMs, wherein the one or more FSMs include information related to a set of re-configuration decisions, wherein each reconfiguration decision defines a re-configuration of one or more network nodes of the group of network nodes upon an event; determining a re-configuration of the network node in response to a certain event, based on the one or more FSMs and the current state of the one or more FSMs; and executing the determined re-configuration of the network node.

Implementation forms of the method of the third aspect may correspond to the implementation forms of the first entity of the first aspect described above. The method of the third aspect and its implementation forms achieve the same advantages and effects as described above for the first entity of the first aspect and its implementation forms.

A fourth aspect of the disclosure provides a method for the second entity, wherein the method comprises: computing a set of re-configuration decisions based on network information of a TSN comprising a group of network nodes, wherein each re-configuration decision defines a re-configuration of one or more network nodes of the group of network nodes upon an event; and encoding the set of re-configuration decisions in one or more FSMs.

Implementation forms of the method of the fourth aspect may correspond to the implementation forms of the second entity of the second aspect described above. The method of the fourth aspect and its implementation forms achieve the same advantages and effects as described above for the second entity of the second aspect and its implementation forms.

A fifth aspect of the disclosure provides a computer program product comprising a program code for carrying out, when implemented on a processor, the method according to the third aspect and any implementation forms of the third aspect, or the fourth aspect and any implementation forms of the fourth aspect.

A sixth aspect of the disclosure provides a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out, the method according to the third aspect and any implementation forms of the third aspect, or the fourth aspect and any implementation forms of the fourth aspect.

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

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

FIG. 1 shows a first entity according to an embodiment of this disclosure;

FIG. 2 shows a second entity according to an embodiment of this disclosure;

FIG. 3 shows FSMs according to this disclosure;

FIG. 4 shows a network topology according to an embodiment of this disclosure;

FIG. 5 shows a network topology according to an embodiment of this disclosure;

FIG. 6 shows a network topology according to an embodiment of this disclosure;

FIG. 7 shows a network topology according to an embodiment of this disclosure;

FIG. 8 shows a method according to an embodiment of this disclosure; and

FIG. 9 shows a method according to an embodiment of this disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of a first entity, a second entity, and corresponding methods for managing network configuration through distributed FSMs are described in the following with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment or example may refer to other embodiments or examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment or example is applicative to the other embodiments or examples.

FIG. 1 shows a first entity 100 for a network node 110 of a TSN comprising a group of network nodes. The first entity 100 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the first entity 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The first entity 100 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the first entity 100 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the first entity 100 to perform, conduct or initiate the operations or methods described herein.

The first entity 100 is configured to obtain one or more FSMs 101, and a current state of the one or more FSMs 101. In particular, the one or more FSMs 101 include information related to a set of re-configuration decisions 1011. Notably, each re-configuration decision 1011 defines a re-configuration of one or more network nodes of the group of network nodes upon an event. The first entity 100 is further configured to determine a reconfiguration 102 of the network node 110 in response to a certain event, based on the one or more FSMs 101 and the current state of the one or more FSMs. Further, the first entity 100 is configured to execute the determined re-configuration 102 of the network node 110.

The present disclosure introduces an on-demand TSN re-configuration through distributed FSMs to each network device, e.g., using a network configuration protocol such as NETCONF. This disclosure allows to improve reaction times for the TSN network reconfiguration and remove dependencies on a centralized controller. Notably, the centralized controller typically would follow a two-step approach (notify controller, then distribute re-configuration) and may even not be reachable due to lost connectivity or overload. This leverages the benefits of a distributed approach where TSN can be managed through FSMs covering generic network changes while decisions are made locally and network configuration depends on the live network state.

Furthermore, this approach enables prompt re-configuration in the fully distributed configuration model of TSN, where no centralized controller is used.

According to an embodiment of this disclosure, the first entity 100 may be configured to obtain the one or more FSMs 101 and the current state of the one or more FSMs 101 from a second entity 200.

FIG. 2 shows a second entity 200 according to an embodiment of this disclosure. In particular, the second entity 200 is configured to compute a set of re-configuration decisions 1011 based on network information of a TSN comprising a group of network nodes. In particular, each re-configuration decision 1011 defines a re-configuration of one or more network nodes of the group of network nodes upon an event. The second entity 200 is further configured to encode the set of re-configuration decisions 1011 in one or more FSMs 101.

The second entity 200 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the second entity 200 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application- specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors. The second entity 200 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the second entity 200 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the second entity 200 to perform, conduct or initiate the operations or methods described herein.

This disclosure further proposes a solution for precomputation of the responses to changing network conditions and their encoding in the form of FSMs.

Optionally, the second entity 200 may compute the set of re-configuration decisions 1011 further based on a pre-considered network condition change including one or more of the following: a link failure, a device failure, a network congestion, and a performance degradation.

According to an embodiment of this disclosure, the second entity 200 may be further configured to distribute the one or more FSMs 101 to one or more first entities 100. Each first entity 100 is run locally on a network node 110 of the group of network nodes. The first entity 100 shown in FIG. 2 may be the first entity 100 shown of FIG. 1. Optionally, this disclosure also proposes a solution for distributing the FSMs to local agents or devices to enable local decisions and immediate reactions.

This solution thus reduces network downtime during re-configuration. The proposed approach may be based on an SDN controller implementation that precomputes reconfiguration decisions for a given set of possible conditions that may arise. This disclosure also proposes to proactively install distributed FSM functionality at each TSN device that can be promptly executed by a local agent when a network event occurs.

FIG. 3 shows FSMs according to an embodiment of the disclosure. Optionally, the one or more FSMs 101 comprise at least a first state, a second state, and a third state, as shown in FIG. 3.

According to an embodiment of the disclosure, the first entity 100 may be configured to, for the first state, instruct the network node 110 to keep a current configuration. Possibly, when the current FSM state is the first state, it implies that there is no need to re-configure the network node 110. Optionally, the first entity 100 may be configured to, for the second state, instruct the network node 110 to implement a re-configuration 102. Accordingly, when the current FSM state is the second state, it implies that a network condition has changed, and thus the network node 110 should be re-configured.

Optionally, the first entity 100 may be configured to, for the third state, send a state transition request to a particular network node to trigger a state transition. Notably, when the current FSM state is the third state, it implies that the first entity 100 has detected a trigger event, and decides a specific device based on the one or more FSMs 101, for which a state transition is needed.

Optionally, when the current state of the one or more FSMs 101 is the first state or the second state, a next state of the one or more FSMs 101 is the third state when a network condition change occurs.

Optionally, when the current state of the one or more FSMs 101 is the first state or the third state, a next state of the one or more FSMs is the second state when a state transition request from another first entity of on another network node of the group of network nodes is received.

Notably, when entering a new FSM state, a number of actions can be triggered to re-configure the network node, which may include the notification to other network nodes.

Optionally, when the current state of the one or more FSMs 101 is the second state or the third state, a next state of the one or more FSMs 101 is the first state when a network condition change is restored.

According to an embodiment of the disclosure, the one or more FSMs 101 may comprise a plurality of attributes including one or more of the following:

- a next state of the particular network node. Optionally, for the third state, sending a state transition request to a particular network node to trigger a state transition comprises determining the particular network node based on the plurality of attributes, and sending the state transition request to a particular first entity of that particular network node.

According to an embodiment, the first state is a “Stable” state, the second state is a “Function” state, and the third state is an “Alert” state, wherein for the “Function” state, instructing the network node 110 to implement a re-configuration 102 comprises instructing the network node 110 to perform one or more operations on an incoming stream.

In particular, the one or more operations may comprise generating a replication of the incoming stream, and/or relocating the incoming stream.

According to an embodiment of the disclosure, the one or more FSMs 101 further comprise one or more of the following attributes:

- one or more parameters for implementing frame replication and elimination.

Optionally, the first entity 100 may be configured to receive a state transition request from another first entity of another network node of the group of network nodes; determine the incoming stream based on the plurality of attributes; and instruct the network node 110 to perform the one or more operations for the determined incoming stream.

According to an embodiment of the disclosure, the FSM-based TSN re-configuration mechanism can be introduced to guarantee resilience against sequential failures while limiting/minimizing frame replicas in conjunction with FRER. FRER is based on redundant transmissions along alternative routes of each flow, as specified in the IEEE 802.1CB.

In this case, the first state may be a “Stable” state, the second state may be a “Function” state (may also be referred to as “FRER” in this application), and the third state is an “Alert” state. Optionally, the first entity is configured to, for the “Function” state, instruct the network node 110 to perform one or more operations on an incoming stream.

For example, the second entity 200 (e.g., an SDN controller) may upload the following FSM to the first entity 100 (e.g., a local agent) of each network node, and indicate the current state of operation, e.g., “Stable” or “FRER”, as <current-state> in the YANG FSM model. Notably, YANG is a data modeling language used to model configuration, state data, and administrative actions manipulated by the NETCONF protocol.

The FSM is distributed to each device and acts locally to affect the network device behavior in FRER. Possibly, only a subset of devices, i.e., network nodes of the TSN, generates replicas depending on the FSM state, thereby minimizing network load from stream replication. If the network conditions change, e.g., link failure on a specific port, a state transition in the FSM may be triggered locally without external interaction, e.g., interactions with the SDN controller. It should be noted that network topologies discussed in this application are the network topologies allowing for redundant paths.

According to this embodiment, the concrete FSM states are explained here: a) at “Stable” state: the network node does not generate replicas, b) at “Function” or “FRER” state: the network node generates replicas, c) at “Alert” state: the agent sends a <rpc> to a specific device, i.e., another network node, to trigger its state transition to the “FRER” state.

A thorough explanation of the transitions between the states is declared here. The transition from “Stable” to “Alert” may be triggered by a failure, e.g., link failure or device failure, at this device. Alternatively, the transition from “Stable” to “Alert” may also be triggered based on a monitored performance parameter, e.g., when the performance parameter such as the experienced delay exceeds a given threshold.

The transition from “Stable” to “FRER” may be triggered by (NETCONF) <rpc>. The transition from “FRER” to “Stable” may be triggered by a link repair, e.g., by the SDN controller. The transition from “FRER” to “Alert” is triggered by a failure at this device or by a monitored performance parameter. The transition from “Alert” to “Stable” is triggered by a link repair, e.g. by the SDN controller. The transition from “Alert” to “FRER” is triggered by <rpc>. Optionally, the whole information is encoded based on the YANG FSM model. In more detail, upon a failure detection performed by the network devices, the following attributes are included: a) ID/address of the device to transition to “FRER”, b) New state ID (i.e., “FRER”) for that device. While for the devices transitioning to “FRER” the following attributes may be introduced: a) IDs of the streams to be replicated, b) FRER parameters as described in the IEEE P802.1CBcv/db specification.

FIG. 4 to FIG. 6 show an example of the application projected to FRER considering sequential failures. A TSN network topology according to an embodiment of this disclosure is shown in these figures. According to this network topology, the TSN comprises two endpoints, i.e, a talker and a listener, and several network nodes (e.g., switches) located between the two endpoints. Typically, the talker generates a replicated stream and a listener receives the replicated stream and eliminates replicas. The network nodes that are in state “Stable” do not generate replicas.

As shown in FIG. 4, a primary path may be the path along with nodes A^B^C^F^G^H, and a backup path or a redundant path may be the path along with nodes A— >E— >D— >L— 4— >H.

In case of A^B link failure as shown in FIG. 5, the listener receives only one copy of the stream, i.e., the lower stream as shown in FIG. 4, from the backup path. To introduce redundancy upon this event occurs, A^B link failure triggers a transition to “Alert” state at network node B. In this example, network node B may be the network node 110 as shown in FIG. 1, and the local agent (not shown in the figure) of network node B may be the first entity 100 as shown in FIG. 1.

Then, network node B signals network node D to transition to “FRER” state using NETCONF <rpc> one-step communication process instead of two-step as in conventional solutions. It is noted that network node B knows to inform network node D of this failure from the information encoded in the FSM. Network node D receiving the signaling message changes its current state to “FRER”. In “FRER” state, network node D generates a replica of the lower stream via network node C, and thus sequential failures can be mitigated. Further, as a possible sequential failure, I— H link failure occurs as shown in FIG. 6. In case of such an event, a transition to “Alert” state at network node I will be triggered. In this example, network node I may be the network node 110 as shown in FIG. 1, and the local agent (not shown in the figure) of network node I may be the first entity 100 as shown in FIG. 1.

Then, network node I signals network node L to transition to “FRER” state using NETCONF <rpc>. Subsequently, in “FRER” state, network node L generates a replica of the lower stream to network node F, i.e., sequential failure at link D— >C and/or link C^F can be mitigated. Thus, network node F eliminates replicas as concluded in the presented use-case.

This disclosure further proposes another application of the FSM-based TSN reconfiguration mechanism, which comes with path re-allocation in case of performance degradation, e.g., a stream cannot meet delay requirements. For instance, the “Function” state of the FSM as discussed in the previous embodiment may be named as “Reroute” state in this embodiment.

As depicted in FIG. 7, the lower stream (non-FRER) towards L— 1— H path suffers from performance degradation, i.e., delay requirements cannot be fulfilled. Possibly, such performance degradation may trigger a transition to “Reroute” state at network node L. In this example, network node L may be the network node 110 as shown in FIG. 1, and the local agent (not shown in the figure) of network node L may be the first entity 100 as shown in FIG. 1. Network node L signals network nodes F and G to add a new entry to Forwarding Database (FDB) (e.g., using NETCONF <rpc>). This is a one-step communication process instead of a two-step which is used conventionally. Finally, network node L changes its own FDB entry and forwards the stream to network node F instead of network node I.

To summarize, this disclosure aims to improve reaction times for TSN network reconfiguration, and remove dependency on the centralized controller (no single point of failure; enable fully distributed model). Based on the above-discussed embodiments, this disclosure proposes a distributed approach using a one-step communication procedure instead of a two-step communication procedure with a central controller. In this way, the transmission delay is reduced, and also the risk of downtime can be reduced. This disclosure avoids the potential risk that may costed by a single point of failure (SDN controller / Crosswork Network Controller (CNC)). The recovery can take place even if an SDN controller / CNC cannot be reached (e.g., due to failure along the route). In addition, this disclosure can work with distributed TSN configuration model (cf. 802. IQdd), and no centralized controller is required. Further, FSMs proposed in this disclosure that react to network state changes can be generic, thus the proposed approach may cover several existing and future use cases.

FIG. 8 shows a method 800 according to an embodiment of the disclosure, particularly for a first entity 100 for a network node 110 of a TSN comprising a group of network nodes. In a particular embodiment, the method 800 is performed by the first entity 100 shown in FIG. 1. The method 800 comprises a step 801 of obtaining one or more finite state machines, FSMs 101, and a current state of the one or more FSMs 101. The one or more FSMs 101 include information related to a set of re-configuration decisions 1011. Each reconfiguration decision 1011 defines a re-configuration of one or more network nodes of the group of network nodes upon an event. The method 800 further comprises a step 802 of determining a re-configuration 102 of the network node 110 in response to a certain event, based on the one or more FSMs 101 and the current state of the one or more FSMs 101. The method 800 further comprises a step 803 of executing the determined reconfiguration 102 of the network node 110. Optionally, the one or more FSMs 101 and the current state of the one or more FSMs 101 are obtained from a second entity 200. Possibly, the second entity 200 is the second entity shown in FIG. 2.

FIG. 9 shows a method 900 according to an embodiment of the disclosure. In a particular embodiment, the method 900 is performed by a second entity 200 shown in FIG. 2. The method 900 comprises a step 901 of computing a set of re-configuration decisions 1011 based on network information of a TSN comprising a group of network nodes. Each reconfiguration decision 1011 defines a re-configuration of one or more network nodes of the group of network nodes upon an event. The method 900 comprises a step 902 of encoding the set of re-configuration decisions 1011 in one or more FSMs 101. Optionally, the one or more FSMs 101 are distributed to one or more first entities 100 by the second entity 200. Possibly, each of the first entities 100 may be the first entity shown in FIG. 1 or FIG. 2.

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

Furthermore, any method according to embodiments of the disclosure may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer-readable medium of a computer program product. The computer-readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive.

Moreover, it is realized by the skilled person that embodiments of the first entity 100, or the second entity 200, comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution. Especially, the processor(s) of the first entity 100, or the second entity 200 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims

1. A first entity (100) for a network node (110) of a Time Sensitive Network comprising a group of network nodes, the first network entity being configured to: obtain one or more finite state machines, FSMs (101), and a current state of the one or more FSMs (101), wherein the one or more FSMs (101) include information related to a set of re-configuration decisions (1011), wherein each re-configuration decision (1011) defines a re-configuration of one or more network nodes of the group of network nodes upon an event; determine a re-configuration (102) of the network node (110) in response to a certain event, based on the one or more FSMs (101) and the current state of the one or more FSMs (101); and execute the determined re-configuration (102) of the network node (110).

2. The first entity (100) according to claim 1, wherein the one or more FSMs (101) comprise at least a first state, a second state, and a third state, wherein the first entity (100) is configured to: for the first state, instruct the network node (110) to keep a current configuration; for the second state, instruct the network node (110) to implement a reconfiguration (102); and for the third state, send a state transition request to a particular network node to trigger a state transition.

3. The first entity (100) according to claim 2, wherein

- when the current state of the one or more FSMs (101) is the first state or the second state, a next state of the one or more FSMs (101) is the third state when a network condition change occurs;

- when the current state of the one or more FSMs (101) is the first state or the third state, a next state of the one or more FMSs is the second state when a state transition request from another first entity of on another network node of the group of network nodes is received,

- when the current state of the one or more FSMs (101) is the second state or the third state, a next state of the one or more FSMs (101) is the first state when a network condition change is restored.

4. The first entity (100) according to claim 2 or 3, wherein the one or more FSMs (101) comprise a plurality of attributes including one or more of the following:

- a next state of the particular network node.

5. The first entity (100) according to claim 4, wherein for the third state, the sending a state transition request to a particular network node to trigger a state transition comprises: determining the particular network node based on the plurality of attributes, and sending the state transition request to a particular first entity of that particular network node.

6. The first entity (100) according to one of the claims 2 to 5, wherein the first state is a “Stable” state, the second state is a “Function” state, and the third state is an “Alert” state, wherein for the “Function” state, instructing the network node (110) to implement a reconfiguration (102) comprises instructing the network node (110) to perform one or more operations on an incoming stream.

7. The first entity (100) according to claim 6, wherein the one or more operations comprise: generating a replication of the incoming stream, and/or relocating the incoming stream.

8. The first entity (100) according to claim 6 or 7, wherein the one or more FSMs (101) further comprise one or more of the following attributes:

- one or more parameters for implementing frame replication and elimination.

9. The first entity (100) according to claim 8, further configured to: receive a state transition request from another first entity of another network node of the group of network nodes; determine the incoming stream based on the plurality of attributes; and instruct the network node (110) to perform the one or more operations for the determined incoming stream.

10. The first entity (100) according to one of the claims 2 to 9, wherein the network condition change includes one or more of the following: a link failure, a device failure, a network congestion, and a performance degradation.

11. The first entity (100) according to one of the claims 1 to 10, further configured to: obtain the one or more FSMs (101) and the current state of the one or more FSMs

(101) from a second entity (200).

12. A second entity (200), being configured to: compute a set of re-configuration decisions (1011) based on network information of a Time Sensitive Network comprising a group of network nodes, wherein each reconfiguration decision (1011) defines a re-configuration of one or more network nodes of the group of network nodes upon an event; and encode the set of re-configuration decisions (1011) in one or more finite state machines, FSMs (101).

13. The second entity (200) according to claim 11, wherein computing the set of reconfiguration decisions (1011) is further based on a pre-considered network condition change including one or more of the following: a link failure, a device failure, a network congestion, and a performance degradation.

14. The second entity (200) according to claim 12 or 13, further configured to: distribute the one or more FSMs (101) to one or more first entities (100), wherein each first entity (100) is run locally on a network node (110) of the group of network nodes.

15. The second entity (200) according to one of the claims 12 to 14, wherein the one or more FSMs (101) comprise at least a first state, a second state, and a third state, wherein the first entity (100) is configured to: for the first state, a network node (110) executing the one or more FSMs (101) is instructed keep a current configuration; for the second state, a network node (110) executing the one or more FSMs (101) is instructed to implement a re-configuration; and for the third state, a network node (110) executing the one or more FSMs (101) is instructed to send a state transition request to a particular network node to trigger a state transition.

16. The second entity (200) according to claim 15, wherein

- when the current state of the one or more FSMs (101) is the first state or the third state, a next state of the one or more FMSs is the second state when a state transition request from another first entity of on another network node of the group of network nodes is received;

17. The second entity (200) according to one of the claims 12 to 16, wherein the one or more FSMs (101) comprise a plurality of attributes including one or more of the following:

- a next state of the particular network node.

18. The second entity (200) according to one of the claims 10 to 12, wherein the first state is a “Stable” state, the second state is a “Function” state, and the third state is an “Alert” state, wherein: for the “Function” state, the network node (110) executing the one or more FSMs (101) is instructed to perform one or more operations on an incoming stream.

19. The second entity (200) according to claim 18, wherein the one or more operations comprise: generating a replication of the incoming stream, and/or relocating the incoming stream.

20. The second entity (200) according to claim 18 or 19, wherein the one or more FSMs (101) further comprise one or more of the following attributes:

- one or more parameters for implementing frame replication and elimination.

21. Method (800) for a first entity (100) for a network node (110) of a Time Sensitive Network comprising a group of network nodes, the method comprising: obtaining (801) one or more finite state machines, FSMs (101), and a current state of the one or more FSMs (101), wherein the one or more FSMs (101) include information related to a set of re-configuration decisions (1011), wherein each re-configuration decision (1011) defines a re-configuration of one or more network nodes of the group of network nodes upon an event; determining (802) a re-configuration (102) of the network node (110) in response to a certain event, based on the one or more FSMs (101) and the current state of the one or more FSMs (101); and executing (803) the determined re-configuration (102) of the network node (110).

22. Method (900) for a second entity (200), the method comprising: computing (901) a set of re-configuration decisions (1011) based on network information of a Time Sensitive Network comprising a group of network nodes, wherein each re-configuration decision (1011) defines a re-configuration of one or more network nodes of the group of network nodes upon an event; and encoding (902) the set of re-configuration decisions (1011) in one or more finite state machines, FSMs (101).

23. A computer program product comprising a program code for carrying out, when implemented on a processor, the method (800, 900) according to claim 21 or 22.

24. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method (800, 900) of claim 21 or 22.