Patent Description:
Time-Sensitive Networking (TSN) is currently being developed at the Institute for Electronics and Electrical Engineering (IEEE) as a new technology that enhances IEEE <NUM> and IEEE <NUM> Ethernet standards to an entirely new level of determinism. It can be seen as an evolution of Ethernet to guarantee low end-to-end latency, low jitter, and low packet loss.

The TSN Task Group (TG) within the IEEE <NUM> Working Group (WG) deals with deterministic services through IEEE <NUM> networks. The TSN TG specifies the tools of the TSN toolbox, as well as the use of the tools for a particular purpose. TSN TG is chartered to provide deterministic services through IEEE <NUM> networks with:.

In order to achieve extremely low packet loss, the TSN TG specified Frame Replication and Elimination for Reliability (FRER) (<NUM>. 1CB), which is targeted to avoid frame loss due to equipment failure. It is practically a per-frame <NUM>+<NUM> (or <NUM>+n) redundancy function. There is no failure detection / switchover incorporated. FRER sends frames on two (or more) maximally disjoint network paths, then combines the streams and deletes extra frames.

Note that the same functions are defined for Deterministic Networking (DetNet) networks as Packet Replication and Elimination Functions (PREFs) in order to simplify implementation and allow use of the same concept in both Layer2 (TSN) and Layer3 (DetNet) networks, such as described in <NPL>). In the description provided herein, the focus is on FRER although the embodiments can be applied to PREF.

Some aspects of the present disclosure are based on IEEE <NUM>. 1CB, so various terminology and variable names described in IEEE <NUM>. 1CB are used here where appropriate, denoted as "VariableName". In contrast, new variables, functions, and parameters follow IEEE <NUM>. 1CB naming convention and are denoted as "NewEntityName". Note as per IEEE <NUM>. this standard defines Frame Replication and Elimination for Reliability (FRER), which divides a Stream into one or more linked Member Streams, thus making the original Stream a Compound Stream. It replicates the packets of the Stream, splitting the copies into the multiple Member Streams, and then rejoins those Member Streams at one or more other points, eliminates the replicates, and delivers the reconstituted Stream from those points.

An Elimination function evaluates the "sequence_number" sub-parameter of a packet of one or more Member Streams passed up from the lower layers, in order to discard duplicated packets. The "SequenceHistory" variable maintains a history of the "sequence_number" sub-parameters of recently received packets. During duplicate elimination, "sequence_number" is checked against a history window (defined by "frerSeqRcvyHistoryLength"). Packets being outside the history window are discarded as invalid. Under normal operation, received packets are within the history window and only duplicates are dropped.

IEEE <NUM>. 1CB defines a timeout mechanism for the Elimination function in order to cope with some networking scenarios that results in unnecessarily dropped frames (e.g., if Elimination function somehow gets out of step with its corresponding Sequence generation function; if a Sequence generation function is reset; etc.). If a timeout occurs, the history is reset, and it is allowed to accept the next packet by the recovery algorithm, no matter what the value of its "sequence_number" sub-parameter (see "<NPL>, illustrates the FRER in the <NUM>. 1CB context.

Some embodiments of the present invention are directed to a method for packet or frame replication and elimination in a Time Sensitive Networking, TSN, or Deterministic Networking, DetNet, network according to claim <NUM>. The method includes obtaining by a gate controller downstream information indicating which application instance in an application cluster is downstream active needing to send a stream of packets or frames in a downstream direction through the network. The method further includes, based on the downstream information, controlling by the gate controller a gate within a gate cluster that is associated with the downstream active application instance to be open state which operates to forward the stream of packets or frames in the downstream direction from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoint paths through the network. The method further includes triggering by the gate controller the packet or frame replication entity to reset a sequence number generation function based on the downstream information.

Some other embodiments of the present invention are directed to a Time Sensitive Networking, TSN, or Deterministic Networking, DetNet, network for packet or frame replication and elimination according to claim <NUM>. The network includes a gate controller adapted to obtain downstream information indicating which application instance in an application cluster is downstream active needing to send a stream of packets or frames in a downstream direction through the network. The gate controller is further adapted to, based on the downstream information, control a gate within a gate cluster that is associated with the downstream active application instance to be open state which operates to forward the stream of packets or frames in the downstream direction from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoint paths through the network. The gate controller is further adapted to trigger the packet or frame replication entity to reset a sequence number generation function based on the downstream information.

Potential advantages that may be provided by one or more of these embodiments and further embodiments disclosed herein can include any one or more of the following:.

Dependent claims describe preferred embodiments of the invention. Other networks and methods according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such networks and methods be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims. Moreover, it is intended that all embodiments disclosed herein can be implemented separately or combined in any way and/or combination.

TSN Node: As used herein, a Time Sensitive Networking (TSN) node is any network node in a TSN network. Examples of a TSN node include a TSN endpoint and a TSN bridge.

There currently exist certain challenge(s) with respect to TSN and Deterministic Networking (DetNet). The mechanisms available for reset of seamless redundancy functions include too many unnecessary packet drops and are not cloud ready. As the ultimate goal of seamless redundancy is to avoid packet loss as much as possible. The unnecessary packet drops due to the operations of a seamless redundancy mechanism should be minimized. Furthermore, moving seamless redundancy (e.g., Institute for Electronics and Electrical Engineering (IEEE)<NUM>. 1CB) components to a cloud environment creates challenges regarding availability, so seamless redundancy functions are reset much more frequently than in current industrial hardware environments. Therefore, seamless detection and adaptation to scenarios caused by reset of seamless redundancy (e.g., IEEE <NUM>. 1CB) functions are essential.

In addition, the above-described history window and timeout mechanism require good design of related parameters. However, these are not trivial tasks as contradicting requirements must be fulfilled. During the history window design, one may intend to select a small window size, for example, in order to protect the Elimination node resources or to protect against bogus packets (security). In contrast, large window size values are more tolerant to network failures and errors. It may be a hard task to find an optimum window size. Similarly, designing a too low timeout parameter value may cause frequent (and unnecessary) reset of the Elimination function. On the other hand, a too large timeout parameter value slows down the recovery after failure scenarios and causes unwanted networking transient. Furthermore, using Frame Replication and Elimination for Reliability (FRER) for bursty (non-Constant Bit Rate (CBR)) streams makes the above design more challenging or even impossible to find a right balance.

In <CIT> (hereinafter referred to as "the '<NUM> Application"), an explicit notification solution is described that is based on a new flag included in the R-TAG, namely the "SeqResetFlag". This flag is set by the Replication function when the sequence generation function was reset, so such events can be recognized easily by the Elimination functions. With this solution, the focus is on the scenario where frames might be dropped unnecessarily (with a high probability) when the sequence generation function was reset. This solution provides a much better solution than IEEE <NUM>. 1CB-<NUM> when the sequence generation function was reset, but it cannot provide fully lossless recovery in all cases. It may result in some dropped packets after the reset event.

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Systems and methods are described herein that provide seamless recovery for sequence number based seamless redundancy mechanisms after a sequence number generation reset event.

Embodiments of the solution proposed herein target solving the scenario where frames are dropped unnecessarily by IEEE <NUM>. 1CB-<NUM> functions due to the reset of the sequence generation function.

Aspects of the proposed solution include:.

Note that the existing cyclic sequence number space of IEEE <NUM>. 1CB-<NUM> is referred to in this document as the "original sequence number space".

Explicit notification of the reset event is based on a flag included in the R-TAG, which is referred to herein as the "SeqResetFlag". The usage of the new linear initial sequence number space (which is referred to herein as "InitSeqNumSpace") is noted via a new flag included in the R-TAG, which is referred to herein as the "InitSeqFlag". Sequence values of the new number space ("InitSegNumSpace") are also included in the R-TAG.

While the embodiments described herein focus on FRER of TSN, the solutions proposed herein are also applicable to PREF of DetNet or other seamless redundancy mechanisms based on sequence numbering or equivalent functionality (e.g., provided by timestamps).

Embodiments of the solution described herein enable cloudification of seamless redundancy by providing seamless reset for sequence number generation (Sequence generating function) via improvements of, e.g., the Replication and Elimination function of IEEE <NUM>. In some embodiments, the following aspects are introduced (<NUM>) a new flag for explicit indication of the Sequence generating function reset and (<NUM>) the use of a new linear initial sequence number space to the existing cyclic sequence number space of, e.g., IEEE <NUM>. Again, while the description provided herein focuses on FRER as defined in IEEE <NUM>. 1CB, the solution described herein is applicable to FRER of TSN, PREF of DetNet, or other seamless redundancy mechanisms based on sequence numbering or equivalent functionality (e.g., provided by timestamps).

There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. Certain embodiments may provide one or more of the following technical advantage(s). Embodiments of the proposed solution described herein enable cloudification of seamless redundancy by providing seamless reset for sequence number generation (Sequence generating function) via improvements of the Replication and Elimination function of IEEE <NUM>. These improvements ensure much faster and seamless adaptation to network failure scenarios and protect again unnecessary packet drops when sequence generation is reset.

The main motivation for these improvements is to allow cloudification, i.e., "cloud native" implementation of FRER/ Packet Replication and Elimination Function (PREF) functions. Today's trend is to move applications towards virtualized environments. This trend has reached applications used in industrial environments as well, see, e.g., edge computing, fog computing. Using FRER/PREF in a cloud-based scenario, where Talkers/Listeners (Sources/Destinations) are moved to the Cloud, creates many additional challenges for the FRER/PREF functions. FRERs/PREFs are TSN/DetNet functions that belong to the endpoints, so FRER/PREF must work inside the Cloud. For example, a FRER/PREF is usually an instance in a controller-cluster (ctrl-cluster) serving an industrial application in a cloud, as illustrated in <FIG>. In this regard, <FIG> illustrates a Cloud based scenario requiring improvement of FRER functions.

Typical Cloud actions like running multiple Virtual Machines (VMs)/containers/instances, creating a VM/container/instance, moving a VM/container/instance, resetting a function, removing a VM/container/instance, etc. require FRER functions to adapt to the changing environment seamlessly. Changes in this environment are much more frequent than in current industrial network scenarios or network deployments without cloud.

High availability systems require the elimination of any single point of failure. Therefore, FRER/PREF functions (i.e., Sequence generation) must be improved to be able to support various Cloud specific redundancy solutions.

Using FRER of IEEE <NUM>. 1CB as an example, the impact of the reset of the sequence number generation function depends on the actual value of the sequence_number used for the last packet sent before the reset (noted here as SNL) and the value of the sequence_number used for the first packet sent after the reset (noted here as SNR). According to IEEE <NUM>. 1CB-<NUM>, SNR is always <NUM> and SNL is a value in the range of {<NUM>;. ; GenSeqSpace - <NUM>}.

The following ranges can be defined to analyze the impact of the reset for (<NUM>) the solution described in IEEE <NUM>. 1CB-<NUM>, (<NUM>) the solution described in the '<NUM> Application, and (<NUM>) the solution described herein.

where d = "frerSeqRcvyHistoryLength" defined in IEEE <NUM>. Note that due to the cyclic characteristic of the original sequence number space, "A" and "E" are adjacent ranges, where the border between them is be defined here for the analysis as moduloGenSeqSpace(SNL + GenSeqSpace/<NUM>). <FIG> illustrates the ranges of the cyclic sequence number space.

The assumption for the analysis is that (i) there are no other events in the network, only the sequence generation function is reset and (ii) the "frerSeqRcvyHistoryLength" (d) takes value of <NUM> for the probability calculations.

For the evaluation of the solution described in IEEE <NUM>. 1CB-<NUM>, the following range is important:.

Note that HSW is practically the merger of range "B" and range "C" used for the evaluation.

As per IEEE <NUM>. 1CB-<NUM>, packets with a sequence_number out of the history window (HSW) are dropped and packets within the history window are evaluated against the "SequenceHistory" to decide whether or not they are duplicates. Therefore, IEEE <NUM>. 1CB-<NUM> operates as follows for each of the ranges A-E:.

That is, there is high probability of packet drop (<NUM>%) in most cases until timeout triggers the accept of the next packet. Note that packet drop means packet loss for the application whose operation may be damaged by the lost packets.

For the evaluation of the solution described in the '<NUM> Application, the following additional range is important:.

Note that RIR is practically the merger of range "B", range "C", and range "D" used for the evaluation.

RIR is the range where the Eliminator function ignores the received "SeqResetFlag" and checks the received packet against the HSW. Note that range "D" is also part of RIR, as duplicates over the slower redundancy paths may have a sequence_number below SNL and can be as low as SNL - d. Therefore, the solution described in the '<NUM> Application behaves as follows for each of the ranges:.

There is a low probability of packet drop (<NUM>%) in most cases. When packet drop does happen, it is limited to a maximum of "2d" number of packets after the reset. Some TSN applications may tolerate this when reset occurs, some may not.

The solution described in various disclosed embodiments has the following characteristics for each of the ranges:.

There is no packet drop. Packets sent after the reset are immediately considered valid. TSN applications are not impacted at all, and the implementation impact on FRER nodes is moderate.

Systems and methods are disclosed herein for improving the elimination function in a TSN network using FRER in accordance with IEEE <NUM>. 1CB (or likewise in a DetNet network using PREFs. Note that the discussion herein uses IEEE <NUM>. 1CB terminology and variable names where appropriate, denoted as "VariableName". New variables, functions, and parameters follow IEEE <NUM>. 1CB naming conventions and are denoted as "NewEntityName".

From now on, the description focuses on embodiments of the proposed solution for IEEE <NUM> FRER and as such uses terms and notations as described in <NUM>. 1CB-<NUM> FRER. However, the solution proposed herein is equally applicable to other seamless redundancy mechanisms (e.g., PREF for DetNet) based on sequence numbering or equivalent functionality (e.g., provides by timestamps).

<FIG> illustrates a system <NUM> that includes a transmitting (TX) node <NUM> and a receiving (RX) node <NUM> where the TX node <NUM> transmits a replicated stream of packets to the RX node <NUM> via a TSN network <NUM>. Note that the TX node <NUM> and RX node <NUM> may be, for example, TSN endpoints, TSN bridges, or any other type of TSN node, in this example. Transmission of the replicated stream of packets involves replicating a Stream of packets into multiple Member Streams to thereby provide a Compound Stream. The Member Streams are then transmitted to the RX node <NUM> via the TSN network <NUM> via maximally disjoint paths. Note that while the nodes <NUM> and <NUM> are denoted herein as "TX node" and "RX node", respectively, it should be understood that these nodes may both transmit and receive streams via the TSN network <NUM>.

As illustrated, the TX node <NUM> includes a FRER function <NUM> that operates to provide FRER in accordance with, in this example, IEEE <NUM>. The FRER <NUM> includes a Replication function <NUM> and an Elimination function <NUM> (illustrated as optional in the sense that it is not used for transmission of the Stream to the RX node <NUM>). In a similar manner, the RX node <NUM> includes a FRER function <NUM> that operates to provide FRER in accordance with, in this example, IEEE <NUM>. The FRER <NUM> includes a Replication function <NUM> (illustrated as optional in the sense that it is not used for reception of the Stream from the TX node <NUM>) and an Elimination function <NUM>.

As illustrated, the Replication function <NUM> includes a Sequence Generation function <NUM>. The Sequence Generation function <NUM> operates to generate sequence numbers for the packets in the packet Stream. The Elimination function <NUM> includes a Sequence Recovery function <NUM>. The Sequence Recovery function <NUM> operates on packets passed up the protocol stack towards the higher layer functions and uses the sequence number sub-parameter to decide which packets to pass and which to discard.

In some embodiments, the TX node <NUM> is part of a Cloud implementation (e.g., part of a Ctrl-cluster as described above with respect to <FIG>).

A Sequencing function of the FRERs <NUM> and <NUM> provides the "sequence_number" sub-parameter for FRER functions. In particular, the Sequencing function has two kinds of component functions: (<NUM>) a Sequence Generation function (e.g., the Sequence Generation function <NUM>) that operate on packets passed down the protocol stack towards the physical layer and generates a value for the sequence_number sub-parameter and (<NUM>) a Sequence Recovery function (e.g., the Sequence Recovery function <NUM>) that operates on packets passed up the protocol stack towards the higher layer functions and uses the sequence_number sub-parameter of the received packets to decide which packets to pass and which to discard.

Embodiments of the solution described herein use the flag introduced by the '<NUM> Application to the R-TAG, namely the "SeqResetFlag". This flag is used as follows:.

Embodiments of the solution described herein introduce a new additional sequence number space, which is referred to herein as "InitSeqNumSpace", which is used after initialization or reset of the Sequence Generation function <NUM>. The newly introduced InitSeqNumSpace is illustrated by the bolded linear sequence number space in <FIG>. The sequence_number of the next packet is stored in a new variable, namely the "InitGenSeqNum". When this new number space is exhausted, the Sequence Generation function <NUM> starts to use the original sequence number space, which is illustrated by the non-bolded sequence number space in <FIG>. In other words, <FIG> illustrates an example of the relation of the new (linear) sequence number space and the original (cyclic) sequence number space.

Embodiments of the solution described herein introduce a new flag in the R-TAG, which is referred to as the "InitSeqFlag". This flag is used by the Replication function <NUM> at the TX node <NUM> as follows:.

The "InitSeqNumSpace" is used as follows:.

Embodiments of the solution herein define a new procedure for the Elimination function <NUM> at the RX node <NUM> as well. It uses the new set of variables to handle packets containing sequence_number from the above described "InitSeqNumSpace". The size of the history window is same for both sequence number spaces. The Elimination function <NUM> operates as follows upon receiving a packet from one of the Member Streams of the Stream transmitted by TX node <NUM>:.

Note that the timeout mechanism for the sequence recovery - to accept the next packet, no matter what the value of its sequence_number subparameter (see "TakeAny" variable in <NUM>. 1CB-<NUM> for the original sequence number space) - is not changed and applied for both sequence number spaces.

An implementation may use two variables to enable/disable the use of the reset flag ( "UsingResetFlag" = <NUM>/<NUM> (enable/disable) ) and the new initial sequence number space ( "UsingInitSpace" = <NUM>/<NUM> (enable/disable) ).

<FIG> illustrates a state diagram for the Replication function <NUM> at the TX node <NUM> in accordance with one embodiment of the present disclosure. As illustrated, when in a first state in which the Replication function <NUM> uses the original sequence number space and UsingInitSpace=False, the Replication function <NUM> uses the original sequence number space. Upon reset with the initial sequence number space disabled, the Replication function <NUM> sets SeqGenNum=<NUM> and UseInitSeqNum=False and remains in the first state. However, upon reset with the initial sequence number space enabled, the Replication function <NUM> sets InitSeqGenNum = InitSeqStart and UseInitSeqNum = True and transitions to a second state in which the Replication function <NUM> uses the initial sequence number space. While in the second state, upon reset with the initial sequence number space enabled, the Replication function <NUM> sets InitSeqGenNum = InitSeqStart and UseInitSeq/Num = True and remains in the second state in which the Replication function <NUM> uses the initial sequence number space. While in the second state, upon exhausting the initial sequence number space, the Replication function sets SeqGenNum = <NUM> and UseInitSeq/Num = False and transitions to the first state in which the Replication function uses the original sequence number space. While in the second state, upon the initial sequence number space being disabled, the Replication function sets SeqGenNum = <NUM> and UseInitSeqNum = False and transitions to the first state in which the Replication function uses the original sequence number space.

<FIG> is a flow chart that illustrates the operation of the Replication function <NUM> at the TX node <NUM> in accordance with one embodiment of the present disclosure. Optional steps are represented with dashed lines. As illustrated, the Replication function <NUM> receives a packet (e.g., from a higher layer(s) in the protocol stack) to be sent (step <NUM>). The Replication function <NUM> determines whether the R-Tag is present or set in the packet (step <NUM>). If so (<NUM>, YES), the packet with the R-Tag set is ready to be sent, and as such provided to a lower layer in the protocol stack for transmission (step <NUM>). For instance, multiple copies of the packet may then be generated and sent via different (e.g., disjoint) paths through the TSN network <NUM>. If the R-Tag is not present or set in the packet (step <NUM>, NO), the Replication function <NUM> determines whether the "UsingResetFlag" is enabled (step <NUM>). If so, the Replication function <NUM> determines whether the Sequence Generation function <NUM> has recently been reset (step <NUM>). This is true if a reset has occurred within a predefined or preconfigured amount of time prior to receiving the packet (i.e., the current time) or within a predefined or preconfigured number of packets prior to the receiving the packet. If the Sequence Generation function <NUM> has recently been reset (step <NUM>, YES), the Replication function <NUM> enables the "SeqResetFlag" (e.g., set it to a value of "<NUM>") (step <NUM>). Otherwise, the Replication function <NUM> disables the "SeqResetFlag" (e.g., sets it to a value of "<NUM>") (step <NUM>).

Whether proceeding from step <NUM> or step <NUM>, the Replication function <NUM> determines whether use of "InitSeqNumSpace" is enabled (step <NUM>). If not (<NUM>, NO), the process proceeds to step <NUM>, which is described below. Otherwise (step <NUM>, YES), the Replication function <NUM> determines whether "UseInitSeqNum" is enabled (e.g., set to "True") (step <NUM>). If so (step <NUM>, YES), the Replication function <NUM> enables "InitSeqFlag" (e.g., sets it to "<NUM>") (step <NUM>), adds a sequence number (seq_num) equal to "InitGenSeqNum" to the packet (step <NUM>), increments "InitGenSeqNum" (step <NUM>), and determines whether the "InitSeqNumSpace" is exhausted (step <NUM>). If not (step <NUM>, NO), the process proceeds to step <NUM>, which is described below. Otherwise (step <NUM>, YES), the Replication function <NUM> sets "GenSeqNum" equal to "<NUM>" and sets "UseInitSeqNum" to False (step <NUM>). Then, whether proceeding from the "NO" branch of step <NUM> or step <NUM>, the Replication function <NUM> adds an R-Tag to the packet (step <NUM>) and the procedure proceeds to step <NUM> where the packet is ready to send.

Returning to step <NUM>, if "UseInitSeqNum" is not set to "TRUE", the Replication function <NUM> disables the "initSeqFlag" (e.g., sets it to "<NUM>") (step <NUM>), adds a sequence number (seq_num) equal to "GenSeqNum" to the packet (step <NUM>), and increments "GenSeqSum" (step <NUM>). The procedure then proceeds to step <NUM> where an R-Tag is added to the packet and then the packet is ready to be sent.

<FIG> is a flow chart that illustrates the operation of the Replication function <NUM> at the TX node <NUM> in accordance with another embodiment of the present disclosure. This embodiment is similar to that of <FIG>. As illustrated, the Replication function <NUM> determines that the sequence generation function <NUM> at the TX node <NUM> has been reset (step <NUM>). Responsive to determining that the sequence generation function <NUM> at the TX node <NUM> has been reset, the Replication function <NUM> transmits a first plurality of packets in a Stream of packets, wherein: (a) each of the first plurality of packets comprises a respective sequence number from a linear sequence number space and (b) at least a first packet from among the first plurality of packets that was sent after the rest further comprises an explicit indicator of the reset (step <NUM>). The Replication function <NUM> determines that an end of the linear sequence number space has been reached or that use of the linear sequence number space has been otherwise disabled (step <NUM>). Responsive to determining that the end of the linear sequence number space has been reached or that use of the linear sequence number space has been otherwise disabled, the Replication function <NUM> transmits a second plurality of packet in the Stream of packets, wherein (a) each of the second plurality of packets comprises a respective sequence number of a cyclic sequence number space (step <NUM>).

In one embodiment, each of the first plurality of packets further comprises an explicit indication that the linear sequence number space is being used.

In one embodiment, the network is a TSN network. Further, in one embodiment, the method further comprises resetting the sequence generation function <NUM>, wherein resetting the sequence generation function <NUM> comprises resetting a sequence number history, a history window (e.g., resetting "RecovSeqNum", which is the midpoint of the history window), or both the sequence number history and the history window. In one embodiment, the steps of determining (<NUM>) that the sequence generation function <NUM> at the TX node <NUM> has been reset, transmitting (<NUM>) the first plurality of packets in the Stream of packets, determining (<NUM>) that the end of the linear sequence number space has been reached or that use of the linear sequence number space has been otherwise disabled, and transmitting (<NUM>) the second plurality of packet in the Stream of packets are performed by the FRER function <NUM> of the TX node <NUM> and, more specifically, by the Replication function <NUM> of the TX node <NUM>.

In another embodiment, the network is a DetNet network. Further, in one embodiment, the steps of determining (<NUM>) that the sequence generation function <NUM> at the TX node <NUM> has been reset, transmitting (<NUM>) the first plurality of packets in the Stream of packets, determining (<NUM>) that the end of the linear sequence number space has been reached or that use of the linear sequence number space has been otherwise disabled, and transmitting (<NUM>) the second plurality of packet in the Stream of packets are performed by a PRER of the TX node <NUM>.

<FIG> illustrates a state diagram for an example embodiment of the Elimination function <NUM> at the RX node <NUM>. As illustrated, when in a first state, the Elimination function <NUM> uses the original sequence number space. When in the first packet state and a packet is received with InitSeqNumFlag =<NUM> or a packet is received and the initial sequence number space is disabled, the Elimination function <NUM> remains in the first state. However, when in the first state and a packet is received with InitSeqNumFlag = <NUM> and the initial sequence number space enabled, the Elimination function <NUM> transitions to a second state in which the Elimination function <NUM> uses the initial sequence number space. When in the second state and a packet is received with InitSeqNumFlag =<NUM> and the initial number sequence is enabled, the Elimination function <NUM> remains in the second state. When in the second state and a packet is received with InitSeqNumFlag = <NUM> or a packet is received and initial sequence number space is disabled, the Elimination function <NUM> transitions to the first state.

<FIG> and <FIG> provide a flow chart that illustrates the operation of the Elimination function <NUM> at the RX node <NUM> according to one embodiment of the present disclosure. Optional steps are represented with dashed lines. As illustrated, the Elimination function <NUM> receives a packet (e.g., from a lower layer(s) in the protocol stack) to be processed (step <NUM>). The packet has a "seq_num" value. The Elimination function <NUM> determines whether the "UsingResetFlag" is enabled (step <NUM>). If not (step <NUM>, NO), the Elimination function <NUM> determines whether the sequence number of the packet is in the history window (HSW) (step <NUM>). If not (step <NUM>, NO), the Elimination function <NUM> determines whether "TakeAny" is enabled (step <NUM>). If not (step <NUM>, NO), the Elimination function <NUM> drops the packet (step <NUM>). Otherwise, if "TakeAny" is enabled (step <NUM>, YES), the procedure proceeds to step <NUM>, which is described below. Returning to step <NUM>, if the sequence number of the packet is in the HSW (step <NUM>, YES), the Elimination function <NUM> determines whether the sequence number of the packet is already in the history (step <NUM>). If so (step <NUM>, YES), the Elimination function <NUM> drops the packet (step <NUM>). Otherwise, if the sequence number of the packet not already in the history (step <NUM>, NO), the procedure proceeds to step <NUM>, which is described below.

Returning to step <NUM>, if "UsingResetFlag" is enabled (step <NUM>, YES), the Elimination function <NUM> determines whether use of "InitSeqNumSpace" is enabled (step <NUM>). If not (step <NUM>, NO), the Elimination function <NUM> determines whether "SeqResetFlag" is enabled and the sequence number of the received packet is out of the RIR (step <NUM>). If not (step <NUM>, NO), the procedure proceeds to step <NUM>. Otherwise (step <NUM>, YES), the procedure proceeds to step <NUM>.

Whether proceeding from the YES branch of step <NUM>, the NO branch of step <NUM>, or the YES branch of step <NUM>, the Elimination function <NUM> then updates the "RecovSeqNum" (step <NUM>), updates the "SequenceHistory" (step <NUM>), clears "TakeAny" (step <NUM>), and accepts the packet (step <NUM>).

Returning to step <NUM>, if use of "InitSeqNumSpace" is enabled (step <NUM>, YES), the Elimination function <NUM> determines whether "InitSeqFlag" is enabled (step <NUM>). If not (step <NUM>, NO), the process proceeds to step <NUM>. Otherwise (step <NUM>, YES), the Elimination function <NUM> determines whether "SeqResetFlag" is enabled and the sequence number of the received packet is out of iRIR (step <NUM>). If so (step <NUM>, YES), the procedure proceeds to step <NUM>, which is described below. Otherwise (step <NUM>, NO), the Elimination function <NUM> determines whether the sequence number of the packet is in iHSW (step <NUM>). If so (step <NUM>, YES), the Elimination function <NUM> determines whether the packet is already in history (step <NUM>). If no (step <NUM>), the procedure proceeds to step <NUM>. Otherwise (step <NUM>, NO), the Elimination function <NUM> drops the packet (step <NUM>). Returning to step <NUM>, if the sequence number of the packet is not in iHSW (step <NUM>, NO), the Elimination function <NUM> determines whether "InitTakeAny" is enabled (step <NUM>). If not (step <NUM>, NO), the Elimination function <NUM> discards the packet (step <NUM>). Otherwise (step <NUM>, YES), the process proceeds to step <NUM>.

Whether proceeding from the YES branch of step <NUM>, the NO branch of step <NUM>, or the YES branch of step <NUM>, the Elimination function <NUM> updates the "InitRecovSeqNum" (step <NUM>), updates "InitSequenceHistory" (step <NUM>), and clears "InitTakeAny" (step <NUM>). The Elimination function <NUM> determines whether the sequence number is in STAR (i.e., the range {"GenSeqSpace" - d;. ; "GenSeqSpace" - <NUM> x d}) (step <NUM>). If so (step <NUM>, YES), the Elimination function <NUM> sets "TakeAny" to TRUE (step <NUM>) and the packet is accepted (step <NUM>). Otherwise (step <NUM>, NO), the Elimination function <NUM> accepts the packet (step <NUM>).

One possible option to encode the "SeqResetFlag", the "InitSeqFlag", and the "new sequence number belonging to the linear sequence number space" in the R-TAG are described in the following:.

In <FIG>, which illustrates the R-TAG format (Figure <NUM>-<NUM> in IEEE <NUM>.

Other encoding methods can be constructed as well. For example, "SeqResetFlag" can be encoded in the R-TAG using the reserved fields using <NUM> bit, and the "new sequence number belonging to the linear sequence number space" can be encoded in the remaining <NUM> bits of the reserved fields. Such an encoding includes the information of the sequence number space as well, so no need to explicitly encode the "InitSeqFlag".

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. The network node <NUM> may be the TX node <NUM> or the RX node <NUM> described above. As illustrated, the network node <NUM> includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. The one or more processors <NUM> operate to provide one or more functions of the network node <NUM> as described herein (e.g., one or more functions of the TX node <NUM> or one or more functions of the RX node <NUM>, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure.

As used herein, a "virtualized" network node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node <NUM> includes one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>. In this example, functions <NUM> of the network node <NUM> described herein (e.g., one or more functions of the TX node <NUM> or one or more functions of the RX node <NUM>, as described herein) are implemented at one of the processing nodes <NUM> or distributed across two or more of the processing nodes <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network node <NUM> described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the network node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the network node <NUM> according to some other embodiments of the present disclosure. The network node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network node <NUM><NUM> described herein (e.g., one or more functions of the TX node <NUM> or one or more functions of the RX node <NUM>, as described herein). This discussion is equally applicable to the processing node <NUM> of <FIG> where the modules <NUM> may be implemented at one of the processing nodes <NUM> or distributed across multiple processing nodes <NUM>.

Other embodiments of the present disclosure are directed to providing gate controlled FRER and/or PRER for implementation in a cloud environment. These embodiments are now described below.

Moving industrial applications to a cloud environment is a challenging task. Redundancy solutions developed for cloud environment mainly focus on broadband services and need to be adapted for industrial scenarios having much stronger requirements. In the transport network between the cloud and the industrial endpoint, special functions (FRER) were developed by IEEE <NUM> to meet the reliability requirements of the industrial applications. Cloud specific reliability solutions must be compatible with the FRER-domain. Some embodiments of the present disclosure are directed to a system and operations for enabling adaptation of cloud reliability and FRER functions of the transport domain.

In the cloud environment it is quite usual that single point of failure is avoided by implementing multiple instances of an application. When combined with a transport domain using FRER, the FRER domain is used also within the Cloud environment, such as shown in <FIG>. These application instances can be served by multiple FRER entities in a Cloud environment (Ctrl-cluster). If an application instance fails the Controller-cluster can e.g., activate another application instance. However, such a change of the actual active application instance should be seamless in the FRER domain. The outside world intends to "see" the whole cloud implementation as a single Talker (Ctrl) with a single FRER entity and multiple connections to the TSN network, which may be achieved with prior known approaches.

The mechanisms available for reset of redundancy functions include too many unnecessary packet drops and are not cloud ready. As the ultimate goal of seamless redundancy is to avoid packet loss as much as possible, the unnecessary packet drops due to the operations of a redundancy mechanism should be minimized. Furthermore, moving seamless redundancy (e.g., IEEE <NUM>. 1CB) components to a cloud environment creates challenges regarding availability, as the reset of functions is much more frequent than in current industrial hardware environments. Therefore, seamless detection and adaptation to scenarios caused by reset of redundancy (e.g., IEEE <NUM>. 1CB) functions are essential.

Some embodiments of the present disclosure are directed to utilizing additional functions to enable effective FRER functionalities in a cloud environment and allow the combination/integration of FRER functionalities with cloud specific redundancy functions.

In some embodiments, gate functionality is provided between the application instances and the FRER entites, and which forwards/blocks packets towards or from FRER entities based on gate control information (open or close). Timeout functionality in FRER entities is provided to reset the Sequence generation function, when no packets were received for a given time period. It is noted that reset of Sequence generation function can be achieved by other operations as well. These new functions allow seamless interaction between cloud specific redundancy solutions and the connected packet network using FRER.

<FIG> illustrates a system that includes a plurality of gates (i.e., Gate-<NUM> to Gate-M) within a Gate cluster <NUM> ("Gate-cluster") that provide selective connections between a plurality of application instances (i.e., Ctrl-<NUM> to Ctrl-N) executing in an Application cluster <NUM> ("App-cluster") and a plurality of FRER entities (i.e., FRER-<NUM> to FRER-M) in an FRER entity domain <NUM> in accordance with some embodiments of the present disclosure. The Gate cluster <NUM> is connected between the Application cluster <NUM> and the FRER entity domain <NUM>. Frame forwarding (or packet forwarding) is either allowed or blocked between the Application cluster <NUM> and a given (e.g., selected) FRER entity (i.e., one of FRER-<NUM> to FRER-M) in the domain <NUM> according to the open or close state of the corresponding Gate (e.g., one of Gate-<NUM>. Gate-M) in the Gate cluster <NUM>. The Gate states are controlled (driven) by a Gate controller <NUM> ("Gate ctrl. The Gate controller <NUM> responds to various defined types of information by opening or closing selected ones of the Gates, e.g., such as responsive to Application-cluster state(s). In some embodiments, the information indicates states of the application instances as being one of: downstream active needing to send a stream of packets or frames in a downstream direction through the network; downstream inactive not needing to send a stream of packets or frames in a downstream direction through the network; upstream active needing to receive a stream of packets or frames in an upstream direction from the network; and upstream inactive no needing to receive a stream of packets or frames in an upstream direction from the network.

A Cloud Management ("Cloud Mngmnt") (orchestrator) <NUM> controls the operation and maintenance of application instances in the Application cluster <NUM>. An application instance may not be aware of other application instances.

An Application Cluster Controller (ACC) <NUM> (also "App cls-ctrl. ") selects the downstream active application, that provides the application's output packet flow, i.e., the input for the FRER entity <NUM>. The ACC <NUM> informs about its selection (provides notification of the selection) to the Gate controller <NUM> (e.g., indicating which application instance is downstream active at a given time or during a time-period).

The Gate controller <NUM> sets the gate open or close states according to the received information from the ACC <NUM>. In some or all embodiments, there is only a single gate operated in open state for forwarding packets or frames in a stream from a downstream active application instance, as a given TSN Stream, towards the FRER domain <NUM> at any given time, therefore, only one FRER entity receives packets or frames from the application cluster <NUM>. The Gate controller <NUM> may trigger the open FRER in the FRER domain <NUM> operating in the downstream direction to reset its sequence number generation function, which can also be called "sequence generation function", (e.g., via the frerSeqRcvyReset managed object (<NUM> CB-<NUM>, Section <NUM>.

GATE-x, which can be any of the illustrated Gate-<NUM> through Gate-M, forwards or blocks packet or frame forwarding depending upon the open or closed state, respectively. GATE-x can be implemented as a standalone function (not integrated with FRER) or integrated in FRER Sequencing function (<NUM>. 1CB-<NUM>, Section <NUM>).

FRER entities (i.e., FRER-<NUM> to FRER-M) in the FRER domain <NUM> provide the replication and/or elimination function to create and/or merge the TSN member Streams. The FRER entities <NUM> can be implemented according to one or more of the embodiments described above. As will be described in further detail below, a FRER entity may support a new TimeOutBasedSequenceGenerationReset function. The FRER entity resets its Sequence generation function if no input frames were received for a given (threshold) time interval by the FRER entity for a given TSN Stream. Using TimeOutBasedSequenceGenerationReset function is optional and depends on the system design.

Potential advantages that may be provided by one or more of the embodiments disclosed herein can include any one or more of the following:.

The term "downstream" direction refers to forwarding a TSN Stream from the application instance (the "downstream active application instance") towards the actor(s). The term "upstream" direction refers to forwarding a TSN Stream forwarded from the actor towards the application instance(s) (the "upstream active application instance(s)".

Forwarding of TSN streams in the downstream direction from a downstream active application instance towards one or more actors is now described in the context of <FIG> illustrates the system of <FIG> which is adapted for forwarding TSN streams in the downstream direction in accordance with some embodiments of the present disclosure.

Referring to <FIG>, the Cloud Management <NUM> creates the necessary or desired application instances in the Application-cluster <NUM>. Each application instance can operate as a Talker that generates a downstream TSN Stream. Each application instance can create packets which control one or more actors. Redundancy of application instances is controlled by the Application-Cluster Controller (ACC) <NUM>. For example, the ACC <NUM> may create a plurality of redundant application instances that are concurrently executing in the application cluster <NUM>. The ACC <NUM> selects which application instance output should be forwarded towards the Frame Replication for Reliability (FRER) entity 1420a, which may correspond to a packet or frame replication pathway through the FRER entity domain <NUM> of <FIG>. The application instance that is selected for outputting is referred to as a downstream active application instance. In accordance with some embodiments, the ACC <NUM> selects only a single downstream active application instance (e.g., Ctrl-<NUM>) that will be allowed to stream packets or frames to an associated one of the Gates (e.g., Gate-<NUM>) that is controlled to be open state which operates to forward packets or frames flowing in the downstream direction from the downstream active application instance to an associated packet or frame replication entity (e.g., FRER-<NUM>) entity 1420a for communication through the network.

Corresponding operations by the gate controller <NUM> are now described in the context of the flowchart of <FIG>, in accordance with some embodiments. Referring to <FIG>, the gate controller <NUM> obtains <NUM> downstream information indicating which application instance in the application cluster <NUM> is downstream active needing to send a stream of packets or frames in a downstream direction through the network. Based on the downstream information, the gate controller <NUM> control <NUM> a gate within the gate cluster <NUM> that is associated with the downstream active application instance to be open state which operates to forward the stream of packets or frames in the downstream direction from the downstream active application instance to an associated packet or frame replication entity 1420a for replication and transmission via at least two disjoint paths through the network.

The packet or frame replication entity 1420a replicates the packets or frames in the stream received from the gate associated with the downstream active application instance to create Time-Sensitive Networking (TSN) streams for transmission via the at least two disjoint paths through the network.

In a further embodiment, the control operation <NUM> to change any of the gates between different ones of the open and closed states based on the downstream information is performed in a time synchronized manner, i.e., so that the gates which are controlled to switch states concurrently perform the state switching.

In some embodiments, the control operation <NUM> to control the gate within the gate cluster <NUM> that is associated with the downstream active application instance to be open state, operates to allow only a single one of the gates in the gate cluster <NUM> to be in the open state at a time which operates to forward the stream of packets or frames in the downstream direction to the associated packet or frame replication entity 1420a for replication and transmission via the at least two disjoint paths through the network.

Output packets of the downstream active application instance (e.g., Ctrl-<NUM>) are forwarded by the associated one of the Gates (e.g., Gate-<NUM>) to the associated packet or frame replication entity (e.g., FRER-<NUM>) entity 1420a, which provides a defined level of packet or frame replication for communication through the network in the downstream direction. There is a Gate-x positioned before each FRER entity. In at least some embodiments, each Gate is associated with only a single FRER entity in a one-to-one association. A single Gate-x may be fed packets from multiple application instances executing in the application cluster <NUM>. The ACC <NUM> informs the Gate controller <NUM> about its decision regarding which application instance output should be forwarded towards the FRER entity 1420a. The Gate-controller <NUM> drives the Gates responsive to the received information. In some or all embodiments, in the downstream direction there is only a single one of the Gates that is open (allowing packets to flow through to an associated (connected) one of the FRER entities) for a given TSN Stream at any given time, all the other Gates are closed. It is implementation dependent how to achieve that a change between the open and the closed Gate states happens at the same time for all affected Gates. In one embodiment, the Gates are controlled in a time synchronized manner, e.g., based on a common synchronization clock.

The FRER entity 1420a operates as the entry point to the FRER domain <NUM>. The FRER entity 1420a adds the sequence number information to the packet(s) received from the corresponding open Gate. For example, FRER-<NUM> adds sequence number information to packet(s) received from open state Gate-<NUM>. When there is a change regarding which Gate is open, e.g., Gate-<NUM> is closed and Gate-M is opened, the Sequence generation function of the FRER entity 1420a that serves the newly opened Gate (e.g., FRER-M serving Gate-M) must be reset. This reset can be triggered by the Gate controller <NUM> (e.g., via the frerSeqRcvyReset managed object (<NUM> CB-<NUM>, Section <NUM>. Alternatively, reset can be done in the FRER entity 1420a (e.g., FRER-M) by supporting a new functionality (TimeOutBasedSequenceGenerationReset). The FRER entity 1420a (e.g., FRER-M) resets the Sequence generation function if no input frames were received for a given time by the FRER entity 1420a (e.g., FRER-M) for a given TSN Stream. Reset of Sequence generation function should or must happen before changing the corresponding gate state from closed to open (e.g., the Sequence generation function is reset before Gate-M is changed from closed to open state).

Accordingly, with the reference to the embodiments of <FIG> and <FIG>, the gate controller <NUM> can operate to trigger the packet or frame replication entity 1420a to reset a sequence number generation function <NUM> based on the downstream information. In a further embodiment, the gate controller <NUM> and/or another node (e.g., the application cluster controller <NUM>) can operate to identify which one of the gates within the gate cluster <NUM> is associated with the downstream active application instance and needs to be controlled <NUM> by the gate controller <NUM> to be open state, and can trigger the packet or frame replication entity 1420a, which is associated with the identified gate, to reset the sequence number generation function <NUM>. In a further embodiment, the operation to trigger the packet or frame replication entity 1420a, which is associated with the identified gate, to reset the sequence number generation function <NUM> is performed before the identified gate is controlled to change from a closed state to the open state. In another embodiment, the gate controller <NUM> can operate to trigger the packet or frame replication entity 1420a to reset the sequence number generation function <NUM> using a frerSeqRcvyReset managed object. In another embodiment, the gate controller <NUM> can operate to trigger the packet or frame replication entity 1420a to reset the sequence number generation function <NUM> responsive to no packets or frames being received by the packet or frame replication entity 1420a in a threshold time interval.

The gate controller <NUM> and the gate cluster <NUM> may be part of the FRER domain <NUM>.

Forwarding of a TSN stream in an upstream direction from actors towards application instances is now described in the context of <FIG> illustrates the system of <FIG> which is adapted for forwarding TSN streams in the upstream direction in accordance with some embodiments of the present disclosure.

Referring to <FIG>, for the upstream traffic the Gate cluster <NUM> operation depends on the characteristics of the application instances. There are two possibilities:.

The first case where all Gates are always open, can be implemented by the Gate controller <NUM> responsive to when the information from the ACC <NUM> indicates that the packet or frame sent by the actor must reach all the application instances, i.e., where all application instances are upstream active needing to receive the packet or frame in the upstream direction from the actor via the network. For example, when sensor data is a needed input for each of the application instances of the application cluster <NUM> in order to calculate the control for the actor(s), i.e., all of the application instances are "upstream active", the gate-controller <NUM> controls all the Gates (e.g., Gate-<NUM> to Gate-M) to be open and forward the TSN Stream to each of the application instances (e.g., Ctrl-<NUM> to Ctrl-N) associated with the Gates.

The second case where only some of the Gates are open, can be implemented by the Gate controller <NUM> when the information from the ACC <NUM> indicates that some of the application instances are "upstream inactive" (also referred to as "standby") during which those application instances do not require input. In this scenario the architecture works as described below.

The Cloud Management <NUM> creates the necessary (desired) application instances. Each application instance may operate as a listener for the upstream TSN Stream, i.e., to receive packets of the upstream TSN Stream. Redundancy of application instances is controlled by the ACC <NUM>. The ACC <NUM> selects which of the application instances are upstream active and should receive packets from the packet or frame elimination entities 1420b (e.g., selected ones of the FRER-<NUM> through FRER-M) of the FRER domain <NUM> (<FIG>). Input packets for the application instances are received via the Gate cluster <NUM> from the packet or frame elimination entities 1420b. There is a Gate-x after each packet or frame elimination entity. For example, Gate-<NUM> selectively forwards (when in "open state") or blocks (when in "closed state") packets from FRER-<NUM> to one or more associated application instances, Gate-<NUM> selectively forwards (when in "open state") or blocks (when in "closed state") packets from FRER-<NUM> to one or more associated upstream active application instances, and so-on with Gate-M selectively forwarding (when in "open state") or blocking (when in "closed state") packets from FRER-M to one or more associated upstream active application instances, etc. A Gate-x may feed multiple application instances, e.g., feeding one or more application instances that have been programmatically defined to be associated with Gate-x. The ACC <NUM> informs the Gate controller <NUM> about a decision provided by ACC <NUM> regarding which application instance(s) is(are) upstream active and need input from the FRER entities 1420b of the FRER domain <NUM> (<FIG>). The Gate controller <NUM> selectively drives individual ones of the Gates according to the received information, e.g., opening all Gates or opening a selected one or more of the Gates while maintaining as closed or closing the non-selected one or more of the Gates. All the Gates serving upstream active application instances are controlled by the Gate controller <NUM> to be in the open state for a given TSN Stream so that the upstream active application instances can receive packets of the TSN Stream. In contrast, the Gates corresponding to upstream inactive application instances are controlled by the Gate-controller <NUM> to be in the closed state so that the upstream inactive application instances do not receive packets of the TSN Stream.

Corresponding operations by the gate controller <NUM> are now described in the context of the flowchart of <FIG>, in accordance with some embodiments. Referring to <FIG>, the gate controller <NUM> obtains <NUM> upstream information (e.g., from the ACC <NUM>) indicating which one or more application instances in the application cluster <NUM> are upstream active needing to receive a stream of packets or frames in an upstream direction from the network. Based on the upstream information, the gate controller <NUM> controls <NUM> one or more gates within the gate cluster <NUM> that are associated with the upstream active one or more application instances to be open state which operates to forward the stream of packets or frames from one or more packet or frame elimination entities 1420b, which are associated with the one or more gates and eliminate replicated packets or frames in the stream, in the upstream direction to the upstream active one or more application instances.

The packet or frame elimination (FRER) entities 1420b act as the exit point of the FRER domain <NUM> (<FIG>). A packet or frame elimination (FRER) entity 1420b removes the sequence number information from the packet and sends it to the related one of the Gates. For example, FRER-<NUM> removes the sequence number information from a packet and sends it to the related Gate-<NUM> which, when in the open state, forwards the packet to an associated one or more upstream active application instances. Similarly, FRER-<NUM> removes the sequence number information from a packet and sends it to the related Gate-<NUM> which, when in the open state, forwards the packet to an associated one or more active application instances. In contrast, FRER-M removes the sequence number information from a packet and sends it to the related Gate-M which, when in the closed state, blocks (prevents) forwarding of the packet to an associated one or more inactive application instances.

With further reference to <FIG> and <FIG>, in some embodiments the gate controller <NUM> operates to receive <NUM> from the ACC <NUM> that controls redundancy of the application instances that are concurrently executing, upstream information indicating which one or more application instances in the application cluster <NUM> are upstream active needing to receive a stream of packets or frames in an upstream direction from the network. Based on the upstream information, the gate controller <NUM> further operates to control <NUM> one or more gates within the gate cluster <NUM> that are associated with the upstream active one or more application instances to be open state which operates to forward the stream of packets or frames from one or more packet or frame elimination entities 1420b, which are associated with the one or more gates and eliminate replicated packets or frames in the stream, in the upstream direction to the upstream active one or more application instances.

Claim 1:
A method for packet or frame replication and elimination in a Time Sensitive Networking, TSN, or Deterministic Networking, DetNet, network, the method comprising:
obtaining (<NUM>) by a gate controller (<NUM>) downstream information indicating which application instance in an application cluster (<NUM>) is downstream active needing to send a stream of packets or frames in a downstream direction through the network;
the method being characterized by :
based on the downstream information, controlling (<NUM>) by the gate controller (<NUM>) a gate within a gate cluster (<NUM>) that is associated with the downstream active application instance to be open state which operates to forward the stream of packets or frames in the downstream direction from the downstream active application instance to an associated packet or frame replication entity (1420a) for replication and transmission via at least two disjoint paths through the network; and
triggering by the gate controller (<NUM>) the packet or frame replication entity (1420a) to reset a sequence number generation function (<NUM>) based on the downstream information.