Patent Description:
Time Sensitive Networking (TSN) is currently being developed at the Institute of Electrical and Electronics Engineers (IEEE) as a new technology that enhances IEEE <NUM> and IEEE <NUM> Ethernet standards to an entirely new level of determinism. TSN 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. The 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) (see IEEE <NUM>. FRER is targeted to avoid frame loss due to equipment failure. FRER is practically a per-frame <NUM>+<NUM> (or <NUM>+n) redundancy function. There is no failure detection or switchover incorporated into FRER. In FRER, a replication point sends frames of a particular stream on two (or more) maximally disjoint paths. An elimination point then combines the resulting replicated streams (sometimes referred to herein as "member streams") received over at least some (but potentially all) of the disjoint paths and deletes an 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. The discussion herein focuses on FRER but is equally applicable to PREF.

IEEE <NUM>. 1CB states that:
[T]his 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.

FRER uses a replication function and an elimination function. The replication function may, for example, be implemented in a first TSN bridge in a communication path through the TSN network from a first TSN endpoint (referred to as a "Talker") to a second TSN endpoint (referred to as a "Listener"). The elimination function may, for example, be implemented in a last TSN bridge in the communication path (i.e., the TSN bridge closest to the second TSN endpoint). The replication function receives a Stream from the first TSN endpoint and replicates the packets in the Stream to provide multiple Member Streams (each being a copy of Stream). The Member Streams are transmitted through the TSN network via disjoint paths. At the elimination function, depending on conditions within the TSN network, one or more of the Member Streams are received (potentially all of the Member Streams are received if none of the paths have failed). The elimination function processes the received packets to discard duplicate packets.

More specifically, for each received packet received for each of the Member Streams, the elimination function evaluates the "sequence_number" sub-parameter of the packet passed up from the lower layers in order to discard duplicated packets. For this purpose, a "SequenceHistory" variable maintains a history of the "sequence_number" sub-parameters of recently received packets. In addition, a history window is defined by a "frerSeqRcvyHistoryLength" parameter. The "sequence_number" of the received packet is first compared to the history window (e.g., a history window where a central point of the history window corresponds to a last received "sequence_number" and a length of the window corresponds to "frerSeqRcvyHistoryLength"). If the "sequence_number" of the received packet is outside of the history window, the packet is discarded. Otherwise, if the "sequence_number" of the packet is within the history window, the elimination function checks to see if the "sequence_number" is already included in the "SequenceHistory". If so, the received packet is determined to be a duplicate packet and is therefore discarded. Otherwise, the received packet is determined to be a new packet. Therefore, the "sequence_number" of the packet is added to the "SequenceHistory", the history window is updated based on the "sequence_number" of the packet, and the packet is passed to the second TSN endpoint. This process continues for each packet received for any of the Member Streams.

IEEE <NUM>. 1CB also 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 the 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 before receiving a packet from any of the Member Streams that has a "sequence_number" that is within the history window, the "SequenceHistory" and the history window are reset, and the elimination function is allowed to accept the next packet received for any of the Member Streams, regardless of the value of its "sequence_number" sub-parameter. Once this next packet is received, its "sequence_number" is added to the "SequenceHistory" and the history window is updated accordingly.

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. For instance, 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). However, large window size values are more tolerant to network failures and errors. It may be a difficult task to find an optimum window size. Similarly, designing a timeout parameter value that is too small may cause frequent and unnecessary reset of the elimination function. On the other hand, a timeout parameter value that is too large slows down recovery after failure scenarios and causes unwanted networking transient. Furthermore, using FRER for bursty (non-Constant Bit Rate (CBR)) streams makes the above design more challenging or even makes it impossible to find a good balance. "<NPL> describes detecting sequence number wraparound events in dual-redundant AFDX networks. <CIT> describes parallel redundancy networks wherein frames carry a RST and sequence number field. The RST indicates a system reset and a wraparound event of the sequence number generation. Redundant frames are discarded when the sequence number is outside the expected window.

As such, there is a need to provide a solution(s) that allow faster recovery in problematic scenarios in order to minimize the number of unnecessarily dropped frames.

Systems and methods for packet or frame replication and elimination in a Time Sensitive Networking (TSN) network or Deterministic Networking (DetNet) network are disclosed. There is provided a method according to claim <NUM> which discloses a method of operation of a node in a TSN network or DetNet comprises determining whether to reset a sequence recovery function used for frame or packet elimination for a particular stream of packets based on either or both of an explicit indication or an implicit indication. The method further comprises resetting the sequence recovery function used for frame or packet elimination for the particular stream of packets upon determining to reset the sequence recovery function used for frame or packet elimination for the particular stream of packets. In this manner, packet or frame elimination is improved by avoiding scenarios that result in discarding valid packets or frames due to an out of sync condition between the sequence generation function at the replicator and the sequence recovery function at the eliminator due to resetting of the sequence generation function or network failures.

In some embodiments, resetting the sequence recovery function comprises resetting a sequence number history, a history window, or both the sequence number history and the history window.

Determining whether to reset the sequence recovery function comprises determining whether to reset the sequence recovery function based on the explicit indication. The method further comprises receiving a packet of the particular stream of packets, wherein the packet comprises the explicit indication. The explicit indication is an explicit indication to reset the sequence recovery function, and determining whether to reset the sequence recovery function comprises determining to reset the sequence recovery function based on the explicit indication. The packet comprises an Ethernet frame, and the explicit indication is comprised in a header of the Ethernet frame. Further, the explicit indication is comprised in a Redundancy Tag (R-TAG) comprised in the header of the Ethernet frame. The explicit indication is encoded in one or more bits in a reserved field of the R-TAG. In some embodiments, the explicit indication is encoded in one or more bits in a sequence number field comprised in the R-TAG, and a plurality of remaining bits in the sequence number field indicate a sequence number of the packet in the particular stream of packets. In some embodiments, the explicit indication is one of a set of possible sequence number values for a sequence number field comprised in the R-TAG, the one of the set of possible sequence number values being a combined indication of: (a) the explicit indication and (b) a sequence number of the packet in the particular stream of packets.

In some embodiments, the method further comprises obtaining a sequence number from the packet. Further, determining whether to reset the sequence recovery function based on the explicit indication comprises determining that the sequence number is outside of a history window for the particular stream of packets and determining that the explicit indication to reset the sequence recovery function is present in the packet. A determination is made to reset the sequence recovery function upon determining that the sequence number is outside of the history window for the particular stream of packets and determining that the explicit indication to reset the sequence recovery function is present in the packet. In some embodiments, the method further comprises, after resetting the sequence recovery function, updating the sequence number history and the history window based on the sequence number obtained from the packet and passing the packet to a next node in a respective path of the TSN or DetNet network domain.

In some embodiments, the method further comprises obtaining a sequence number from the packet. Further, the explicit indication to reset the sequence recovery function is present in the packet, and determining whether to reset the sequence recovery function based on the explicit indication comprises determining that the sequence number is within a history window for the particular stream of packets. A determination is made to not reset the sequence recovery function upon determining that the sequence number is within the history window for the particular stream of packets even though the explicit indication to reset the sequence recovery function is present in the packet.

In some embodiments, the method further comprises obtaining a sequence number from the packet. Further, determining whether to reset the sequence recovery function based on the explicit indication comprises determining that the explicit indication to reset the sequence recovery function is not present in the packet. A determination is made to not reset the sequence recovery function upon determining that the sequence number is outside of the history window for the particular stream of packets and determining that the explicit indication to reset the sequence recovery function is not present in the packet.

The method also comprises determining whether to reset the sequence recovery function comprises determining whether to reset the sequence recovery function based on the implicit indication. The implicit indication comprises one or more notifications of one or more remote events. The one or more remote events comprise a path failure detected via Operations and Management (OAM) Continuity Check (CC). In some embodiments, the implicit indication comprises one or more notifications of one or more local events at the node (e.g., interface up or down events).

There is provided an apparatus according to claim <NUM> which discloses a node for a TSN network or DetNet network for frame or packet replication/elimination for reliability are also disclosed. The node is adapted to determine whether to reset a sequence recovery function used for frame or packet elimination for a particular stream of packets based on either or both of an explicit indication or an implicit indication. The node is further adapted to reset the sequence recovery function used for frame or packet elimination for the particular stream of packets upon determining to reset the sequence recovery function used for frame or packet elimination for the particular stream of packets according to the method of claim <NUM>.

In some embodiments, the node comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the node to determine whether to reset the sequence recovery function used for frame or packet elimination for the particular stream of packets based on either or both of an explicit indication or an implicit indication and reset the sequence recovery function used for frame or packet elimination for the particular stream of packets upon determining to reset the sequence recovery function used for frame or packet replication for the particular stream of packets.

There is provided a method according to claim <NUM> which discloses a method of operation of a node in a TSN network or DetNet network for frame or packet replication for reliability are also disclosed. The method comprises transmitting a packet of a particular stream of packets via a first network path, and transmitting the packet of the particular stream of packets via a second network path. The packet comprises an explicit indication that a sequence recovery function used for frame or packet elimination for the particular stream of packets is to be reset.

The packet comprises an Ethernet frame, and the explicit indication is comprised in a header of the Ethernet frame. The explicit indication is comprised in a R-TAG comprised in the header of the Ethernet frame. The explicit indication is encoded in one or more bits in a reserved field of the R-TAG. In some other embodiments, the explicit indication is encoded in one or more bits in a sequence number field comprised in the R-TAG, and a plurality of remaining bits in the sequence number field indicate a sequence number of the packet in the particular stream of packets. In some other embodiments, the explicit indication is one of a set of possible sequence number values for a sequence number field comprised in the R-TAG, the one of the set of possible sequence number values being a combined indication of: (a) the explicit indication and (b) a sequence number of the packet in the particular stream of packets.

There is provided an apparatus according to claim <NUM> which discloses a node for a TSN network or DetNet network for frame or packet replication for reliability are also disclosed. The node is adapted to transmit a packet of a particular stream of packets via a first network path, and transmit the packet of the particular stream of packets via a second network path. The packet comprises an explicit indication that a sequence recovery function used for frame or packet elimination for the particular stream of packets is to be reset.

In some embodiments, the node comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the node to transmit the packet of a particular stream of packets via the first network path and transmit the packet of the particular stream of packets via the second network path. The packet comprises the explicit indication that the sequence recovery function used for frame or packet elimination for the particular stream of packets is to be reset.

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.

Systems and methods are disclosed herein for improving the elimination function in a TSN network using Frame Replication and Elimination for Reliability (FRER) in accordance with Institute of Electrical and Electronics Engineers (IEEE) <NUM>. 1CB (or likewise in a Deterministic Networking (DetNet) network using Packet Replication and Elimination Functions (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".

More specifically, embodiments are disclosed herein that provide a solution(s) to the following problem scenarios, where frames are dropped unnecessarily:.

In problem scenario (i), when the replication function resets and the sequence number is reset to zero, packets thereafter received by the elimination function will have sequence numbers that are likely to be outside of the history window. As a result, these packets will be dropped even though they are valid. In problem scenario (ii), if the network failures persist long enough, the history window maintained at the elimination function will become out of sync with the sequence numbers of valid packets being transmitted by the replication function. As a result, when the network failures end, the packets received at the elimination function will have sequence numbers that are outside of the history window and will therefore be dropped. Embodiments of the present disclosure address these two problem scenarios.

As described herein, the elimination function uses one or more new triggers for resetting a sequence recovery function (i.e., resetting the history window and/or the sequence number history at the elimination function). As described below, the one or more new triggers include:.

According to the invention, the explicit indication is included in the packet received by the elimination function. More specifically, the packet includes an Ethernet frame, and the explicit indication is included in a header of the Ethernet frame. The explicit indication is included in a Redundancy Tag (R-TAG) included in the header of the Ethernet frame. In this regard, the explicit indication is sometimes referred to herein as a "SeqResetFlag" that is included in the R-TAG of the header of the Ethernet frame. The explicit indication (e.g., the "SetResetFlag") is set by the replication function when the replication function was reset. In this manner, the reset of the replication function can easily be recognized by the elimination function. This solves problem scenario (i).

The implicit indication is an indication or notification of a remote event(s) (e.g., path failure detected via Operations and Management (OAM) Continuity Check (CC) messages) or node-local event(s) (e.g., interface up/down) that are interpreted by the elimination function as a trigger to reset the sequence recovery function. This solves problem scenario (ii).

The embodiments described herein can ensure much faster adaptation to network failure scenarios and protect against unnecessary packet drops when using FRER (or in a TSN network (or likewise when using PREF in a DetNet network).

<FIG> illustrates one example of a TSN network <NUM> in which embodiments of the present disclosure may be implemented. Note that while the TSN network <NUM> is shown as an example, a similar architecture applies for a DetNet network. As illustrated, the TSN network <NUM> includes a first TSN endpoint <NUM>, which is also referred to as the "Talker", that transmits a packet stream (i.e., Stream) to a second TSN endpoint <NUM>, which is also referred to as the "Listener", via the TSN network <NUM>. The TSN endpoints <NUM> and <NUM> may be any suitable type of devices. For example, the first TSN endpoint <NUM> may be a controller, and the second TSN endpoint <NUM> may be an industrial robotics device.

The TSN network <NUM> also includes a first TSN bridge <NUM>, which is also referred to as the "Replicator". Note that while the first TSN endpoint <NUM> and the first TSN bridge <NUM> are illustrated as separate TSN nodes in this example, the first TSN endpoint <NUM> and the first TSN bridge <NUM> may alternatively be implemented as a single TSN node. The first TSN bridge <NUM> receives the packet stream from the first TSN endpoint <NUM> and replicates the packet stream to provide a number (M) of packet streams (referred to as COPY <NUM>,. , COPY M or likewise Member Stream <NUM>,. , Member Stream M). More specifically, the first TSN bridge <NUM> includes a replication function <NUM> that receives the packet stream from the first TSN endpoint <NUM>. A sequence generation function <NUM> operates to generate sequence numbers for the packets in the packet stream. For each packet in the packet stream, the replication function <NUM> inserts a respective sequence number (generated by the sequence generation function <NUM>) into the packet, replicates the resulting packet to provide M copies of the packet, and transmits the M copies of the packet to the second TSN endpoint <NUM> over disjoint paths through the TSN network <NUM>. The sequence generation function <NUM> operates on packets passed down the protocol stack towards the physical layer and generates a value for the sequence number sub-parameter. This process is repeated for each received packet, resulting in the M copies of the packet stream that are transmitted via disjoint paths.

Each m-th copy of the packet stream (where m={<NUM>,. , M}) optionally traverses one or more intermediate TSN bridges <NUM>-m before arriving at a second TSN bridge <NUM>, which operates as an elimination point (or "Eliminator") for the packet stream transmitted from the first TSN endpoint <NUM> to the second TSN endpoint <NUM>. In this example, the second TSN bridge <NUM> is either connected directly to the second TSN endpoint <NUM> or connected to the second TSN endpoint <NUM> via one or more additional TSN nodes <NUM> (e.g., one or more additional TSN bridges). Also, note that while the second TSN endpoint <NUM> and the second TSN bridge <NUM> are illustrated as separate TSN nodes in this example, the second TSN endpoint <NUM> and the second TSN bridge <NUM> may alternatively be implemented as a single TSN node. As illustrated, the second TSN bridge <NUM> includes an elimination function <NUM>. The elimination function <NUM> receives the M copies of the packet stream (assuming that none of the disjoint paths have failed) and operates to discard duplicate or invalid packets before sending a resulting packet stream to the second TSN endpoint <NUM>. More specifically, a sequence recovery function <NUM> of the elimination 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.

As described below in detail, in some embodiments, when the replication function <NUM> is reset (and more specifically when the sequence generation function <NUM> is reset), the replication function <NUM> includes an explicit indictor (e.g., the "SeqResetFlag") in the M copies of a respective packet that indicates to the elimination function <NUM> that a sequence recovery function <NUM> of the elimination function <NUM> is to be reset (i.e., the sequence history maintained for the packet stream and/or the history window maintained for the packet stream is/are to be reset). Upon receiving this explicit indicator, the sequence recovery function <NUM> is reset, thereby preventing valid packets from being discarded due to the reset of the sequence generation function <NUM>.

As also described below in detail, in some embodiments, the elimination function <NUM> obtains an implication indication to reset the sequence recovery function <NUM> (e.g., upon network failure(s)). Upon obtaining the implication indication, the sequence recovery function <NUM> is reset such that valid packets are not discarded due to an out of sync condition between the history window maintained by the elimination function <NUM> for the packet stream and the sequence numbers of receive packets.

<FIG> illustrates the operation of the first TSN bridge <NUM> and the second TSN bridge <NUM> in accordance with some embodiments of the present disclosure. Note that optional steps are represented with dashed lines. As illustrated, the first TSN bridge <NUM> receives a packet of a particular packet stream (e.g., from the first TSN endpoint <NUM>) (step <NUM>). At the first TSN bridge <NUM>, the sequence generation function <NUM> gets, or generates, a sequence number for the packet (step <NUM>) and the replication function <NUM> generates the M copies of the packet, each including the sequence number of the packet (step <NUM>). In some embodiments, if the replication function <NUM>, or more specifically the sequence generation function <NUM>, has been reset, an explicit indicator of this reset is also included in each of the M copies of the packet. The first TSN bridge <NUM> transmits the M copies of the packet via disjoint paths through the TSN network <NUM> (steps <NUM>-<NUM> through <NUM>-M).

At the second TSN bridge <NUM>, the elimination function <NUM> determines whether to reset the sequence recovery function <NUM> based on an explicit indication included in the packet that indicates whether the sequence generation function <NUM> has been reset, an implicit indication, or both (step <NUM>). If the determination is made to reset the sequence recovery function <NUM>, the sequence recovery function <NUM> is reset (step <NUM>). The elimination function <NUM> then performs the elimination process for the packet (step <NUM>).

An explicit indication to reset the sequence recovery function <NUM> is included in the packet received by the elimination function <NUM>. More specifically, the packet includes an Ethernet frame, and the explicit indication is included in a header of the Ethernet frame. The explicit indication is included in the R-TAG included in the header of the Ethernet frame. In this regard, the explicit indication is sometimes referred to herein as a "SeqResetFlag" that is included in the R-TAG of the header of the Ethernet frame. The explicit indication (e.g., the "SetResetFlag") is set by the replication function <NUM> when the replication function <NUM> was reset. In this manner, the reset of the replication function <NUM> can easily be recognized by the elimination function <NUM>. This solves problem scenario (i).

Using the "SeqResetFlag" that is included in the R-TAG of the header of the Ethernet frame as an example, upon receiving a packet for a particular packet stream, the replication function <NUM> operates as follows:.

Upon receiving a packet for one of the copies of the particular packet stream, the elimination function <NUM> operates as follows:.

As discussed above, in some embodiments, the explicit indication is the "SeqResetFlag" where the "SeqResetFlag" is included in the R-TAG of the header of the Ethernet frame included in the packet. <FIG> illustrates an example of the header of an Ethernet frame that includes the R-TAG, and <FIG> illustrates the R-TAG format. While the "SeqResetFlag" may be included in the R-TAG in any desired manner, some examples are as follows. As a first example, the "SeqResetFlag" is included in (e.g., encoded in) the reserved field of the R-TAG (second and/or third bytes of the R-TAG). As per the current IEEE <NUM>. 1CB standard: "This field shall be transmitted with all zeros and shall be ignored on receipt.

As a second example, the "SeqResetFlag" is encoded in the R-TAG using one bit of the Sequence Number field of the R-TAG. For instance, "GenSeqSpace" and "RecovSeqSpace" variables may be used to limit the range of values used in the "Sequence Number" field. Setting their values to <NUM> (or lower) means that only <NUM> bits of the "Sequence Number" field are needed to encode the "sequence_number" sub-parameter. The remaining <NUM> bit can be used as a "SeqResetFlag".

As a third example, the "SeqResetFlag" is encoded in the R-TAG using special value(s) of the Sequence Number field in the R-TAG. For instance, "GenSeqSpace" and "RecovSeqSpace" variables may be used to limit the range of valid "sequence_number" values. "Sequence Number" field values out of the range can be used as special meaning values, like indicating a set "SeqResetFlag". This solution requires modification of the sequence generation and sequence recovery function. For example, setting "GenSeqSpace" and "RecovSeqSpace" to <NUM> means that <NUM> values of the "Sequence Number" field can be used as special values (range: <NUM>-<NUM>). As an example, a "Sequence Number" value of <NUM> can mean for the sequence recovery function that "SeqResetFlag" is set and the "sequence_number" sub-parameter of the packet is <NUM>.

<FIG> is a flow chart that illustrates the operation of the first TSN bridge <NUM> including the replication function <NUM> in accordance with some embodiments of the present disclosure. Note that this flow chart is only an example. Variations will be apparent to those of skill in the art. Further, while steps are illustrated as being performed in a particular order, the steps may be performed in a different order unless otherwise stated or required.

As illustrated, the first TSN bridge <NUM> receives a packet for a particular packet stream (step <NUM>). At the first TSN bridge <NUM>, the replication function <NUM> determines whether the packet is to be replicated (e.g., determines whether the packet already includes an R-TAG) (step <NUM>). If the packet does need to be replicated (e.g., if the packet does not already include an R-TAG), the replication function <NUM>, and more specifically the sequence generation function <NUM>, gets (e.g., generates) a sequence number for the packet (step <NUM>).

The replication function <NUM> also determines whether the sequence generation function <NUM> has been reset (step <NUM>). If so, the replication function <NUM> generates M copies of the packet, each including the sequence number obtained for the packet and an explicit indicator (e.g., the "SeqResetFlag" set) that the sequence generation function <NUM> has been reset (which is also an explicit indicator that the sequence recovery function is to be reset) (step <NUM>). The first TSN bridge <NUM> then transmits the M copies of the packet (step <NUM>). Otherwise, if the sequence generation function <NUM> has not been reset (step <NUM>, NO), the replication function <NUM> generates M copies of the packet, each including the sequence number obtained for the packet and, optionally, the explicator indicator (e.g., the "SeqResetFlag" unset) that the sequence generation function <NUM> has not been reset (step <NUM>). The first TSN bridge <NUM> then transmits the M copies of the packet (step <NUM>).

<FIG> is a flow chart that illustrates the operation of the second TSN bridge <NUM> including the elimination function <NUM> in accordance with some embodiments of the present disclosure. Note that this flow chart is only an example. Variations will be apparent to those of skill in the art. Further, while steps are illustrated as being performed in a particular order, the steps may be performed in a different order unless otherwise stated or required.

As illustrated, the second TSN bridge <NUM> receives a packet for a particular copy of particular packet stream (step <NUM>) and obtains the sequence number of the packet (step <NUM>). The elimination function <NUM> determines whether the sequence number of the packet is within the history window maintained by the sequence recovery function <NUM> for the particular stream (step <NUM>). If not, the elimination function <NUM> determines whether the packet includes an explicit indication that indicates that the sequence generation function <NUM> has been reset (which can be interpreted as an explicit indication to reset the sequence recovery function <NUM>) (step <NUM>). If so, the elimination function <NUM> resets the sequence recovery function <NUM> (e.g., resets the sequence number history and the history window) (step <NUM>) and updates the sequence number history and the history window based on the sequence number of the packet (step <NUM>). More specifically, the sequence number history, after reset, is updated to include the sequence number of the packet. Similarly, the history window is updated such that it includes the sequence number of the packet (e.g., a center point of the history window is updated to be the sequence number of the packet). The elimination function <NUM> also passes the packet to the next hop in the TSN network <NUM> toward the second TSN endpoint <NUM> (step <NUM>).

Returning to step <NUM>, if the packet does not include an explicit indication to reset the sequence recovery function <NUM> (e.g., the "SeqResetFlag" is unset), the packet is discarded (step <NUM>).

Returning to step <NUM>, if the sequence number of the packet is within the history window, the elimination function <NUM> determines whether the sequence number of the packet is included in the sequence number history (i.e., whether it has already been received) (step <NUM>). If so, the packet is discarded (step <NUM>). Otherwise, the packet is passed to the second TSN endpoint <NUM> (step <NUM>). Note that, if the sequence number of the packet is within the history window, the sequence recovery function <NUM> is not reset even if the packet includes the explicit indication of the reset of the sequence generation function <NUM>.

<FIG> is a packet sequence diagram for an example scenario. In this example, after reset of the sequence generation function <NUM>, the replication node (i.e., the first TSN bridge <NUM> in the example of <FIG>) sends two packets with "SeqResetFlag" set. The first packet (packet-<NUM>) resets the sequence recovery function <NUM> at the elimination node (e.g., the second TSN bridge <NUM> in the example of <FIG>), and the first packet (packet-<NUM>) is accepted at the elimination node despite being out of the history window. The second packet (packet-<NUM>) is within the new history window and is therefore accepted.

An implicit indication triggers reset of the sequence recovery function <NUM>. The implicit indication is an indication or notification of a remote event(s) (e.g., path failure detected via OAM CC messages) or node-local event(s) (e.g., interface up/down) that are interpreted by the elimination function <NUM> as a trigger to reset the sequence recovery function <NUM>. This solves problem scenario (ii).

The specific event (or combination of events) that are interpreted as the implicit indication depend on the specific network scenario. For example, if all Member Streams are affected by a temporary network failure, then due to the loss of packets, the received packets after the failure may contain "sequence_number" values that are out of the history window. Therefore, such packets are unnecessarily dropped. Network events like CC failures can provide a hint for such scenarios and the elimination node may decide to trigger the "SequenceRecoveryReset" function. Examples of relevant temporary network failure scenarios are link failures, link flapping, convergence, etc..

<FIG> is a flow chart that illustrates the operation of the second TSN bridge <NUM> in accordance with some embodiments of the present disclosure. Note that this flow chart is only an example. Variations will be apparent to those of skill in the art. Further, while steps are illustrated as being performed in a particular order, the steps may be performed in a different order unless otherwise stated or required.

As illustrated, the second TSN bridge <NUM> receives a packet for a particular copy of particular packet stream (step <NUM>) and obtains the sequence number of the packet (step <NUM>). The elimination function <NUM> determines whether the sequence number of the packet is within the history window maintained by the sequence recovery function <NUM> for the particular stream (step <NUM>). If not, the elimination function <NUM> determines whether there is an implicit indication to reset the sequence recovery function <NUM> (step <NUM>). If so, the elimination function <NUM> resets the sequence recovery function <NUM> (e.g., resets the sequence number history and the history window) (step <NUM>) and updates the sequence number history and the history window based on the sequence number of the packet (step <NUM>). More specifically, the sequence number history, after reset, is updated to include the sequence number of the packet. Similarly, the history window is updated such that it includes the sequence number of the packet (e.g., a center point of the history window is updated to be the sequence number of the packet). The elimination function <NUM> also passes the packet to the next hop in the TSN network <NUM> toward the second TSN endpoint <NUM> (step <NUM>).

Returning to step <NUM>, if there is no implicit indication to reset the sequence recovery function <NUM>, the packet is discarded (step <NUM>).

Returning to step <NUM>, if the sequence number of the packet is within the history window, the elimination function <NUM> determines whether the sequence number of the packet is included in the sequence number history (i.e., whether it has already been received) (step <NUM>). If so, the packet is discarded (step <NUM>). Otherwise, the packet is passed to the second TSN endpoint <NUM> (step <NUM>). Note that, if the sequence number of the packet is within the history window, the sequence recovery function <NUM> is not reset even if there is an implicit indication to reset the sequence recovery function <NUM>.

<FIG> is packet sequence diagram for an example scenario. In this example, after sending packet-<NUM>, there is a network failure for both paths. Some remote event(s) or local event(s) related to the network failures of the paths are interpreted by the elimination node (e.g., the second TSN bridge <NUM> in the example of <FIG>) as an implicit indication to reset the sequence recovery function <NUM>. As such, the sequence number history and the history window are reset. Due to the network failures, packet-<NUM> and packet-<NUM> are dropped. The path (link-<NUM>) for the Member Stream is restored such that packet-<NUM> is received by the elimination node. Since the sequence recovery function <NUM> has been reset, packet-<NUM> is not discarded by the elimination function <NUM>, and the sequence number of packet-<NUM> is added to the sequence number history and used to update the history window. Thereafter, link-<NUM> is restored, and the process continues as described above.

<FIG> is a schematic block diagram of a TSN node <NUM> according to some embodiments of the present disclosure. The TSN node <NUM> may be, for example, a TSN endpoint (e.g., TSN endpoint <NUM> or <NUM>), a TSN bridge (e.g., TSN bridge <NUM> or <NUM>), or a combined TSN endpoint and TSN bridge. As illustrated, the TSN 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 one or more network interfaces <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. The one or more processors <NUM> operate to control the TSN node <NUM> to provide one or more functions of a TSN endpoint (e.g., TSN endpoint <NUM> or <NUM>), a TSN bridge (e.g., TSN bridge <NUM> or <NUM>), or a combined TSN endpoint and TSN bridge, 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 TSN node <NUM> according to some embodiments of the present disclosure. As used herein, a "virtualized" TSN node is an implementation of the TSN node <NUM> in which at least a portion of the functionality of the TSN node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s)) executing on a physical processing node(s) <NUM> in a network(s) <NUM>. As illustrated, in this example, each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and one or more network interfaces <NUM>.

In this example, functions <NUM> of the TSN node <NUM> described herein (e.g., one or more functions of a TSN endpoint (e.g., TSN endpoint <NUM> or <NUM>), a TSN bridge (e.g., TSN bridge <NUM> or <NUM>), or a combined TSN endpoint and TSN bridge) 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 TSN node <NUM> described herein (e.g., one or more functions of a TSN endpoint (e.g., TSN endpoint <NUM> or <NUM>), a TSN bridge (e.g., TSN bridge <NUM> or <NUM>), or a combined TSN endpoint and TSN bridge) 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>.

Also provided is 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 TSN node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the TSN node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the TSN node <NUM> according to some other embodiments of the present disclosure. The TSN node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the TSN node <NUM> described herein (e.g., one or more functions of a TSN endpoint (e.g., TSN endpoint <NUM> or <NUM>), a TSN bridge (e.g., TSN bridge <NUM> or <NUM>), or a combined TSN endpoint and TSN bridge, 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>.

These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like.

Claim 1:
A method of operation of a node in a Time Sensitive Networking, TSN, network or a Deterministic Networking, DetNet, network for frame or packet replication/elimination for reliability, comprising:
determining (<NUM>; <NUM>-<NUM>; <NUM>-<NUM>) whether to reset a sequence recovery function (<NUM>) used for frame or packet elimination for a particular stream of packets based on at least an explicit indication to reset the sequence recovery function and optionally an implicit indication to reset the sequence recovery function; and resetting (<NUM>; <NUM>; <NUM>) the sequence recovery function (<NUM>) used for frame or packet elimination for the particular stream of packets upon determining to reset the sequence recovery function (<NUM>) used for frame or packet elimination for the particular stream of packets;
wherein, when said determining (<NUM>; <NUM>-<NUM>; <NUM>-<NUM>) whether to reset the sequence recovery function (<NUM>) comprises determining (<NUM>; <NUM>-<NUM>) whether to reset the sequence recovery function (<NUM>) based on the explicit indication, the explicit indication is received comprised in a packet of the particular stream of packets, wherein the packet comprises an Ethernet frame with the explicit indication comprised in a Redundancy Tag, R-TAG, comprised in a header of the Ethernet frame and wherein the explicit indication is encoded in one or more bits in a reserved field of the R-TAG; and
wherein, when said determining (<NUM>; <NUM>-<NUM>; <NUM>-<NUM>) whether to reset the sequence recovery function (<NUM>) comprises determining (<NUM>; <NUM>-<NUM>) whether to reset the sequence recovery function (<NUM>) based on the implicit indication, the implicit indication comprises one or more notifications of one or more remote events that comprise a path failure detected via Operations and Management, OAM, Continuity Check, CC.