Systems and methods for avoiding duplicate delivery in a reset mechanism

Abstract

Systems and methods are disclosed herein for avoiding duplicate delivery in a reset mechanism for seamless redundancy in, for example, a time-sensitive networking (TSN) network or a deterministic networking (DetNet) network. In one embodiment, a method performed by a receiving node includes receiving, via a network, packets from a plurality of flows from a transmitting node, each flow being a replication of a particular packet flow and each packet including a sequence indication. The method further includes performing an elimination procedure, wherein performing the elimination procedure includes: when receiving a packet, resetting one or more parameters employed by the elimination procedure in response to the occurrence of an event; and in response thereto, discarding all received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of a defined period.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62 / 989,305, filed Mar. 13, 2020, the disclosure of which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present disclosure relates to redundancy mechanisms in time-sensitive networking (TSN) networks, deterministic networking (DetNet), or similar network technologies, and more particularly to avoiding duplicate delivery caused by associated reset mechanisms. Background Art

[0004] The Institute of Electrical and Electronics Engineers (IEEE) is currently developing time-sensitive networking (TSN) as a new technology that enhances the IEEE 802.1 and IEEE 802.3 Ethernet standards to a new level of determinism. It can be seen as an evolution of Ethernet to ensure low end-to-end latency, low jitter, and low packet loss.

[0005] The TSN Task Group (TG) within the IEEE 802.1 Working Group (WG) studies deterministic services over IEEE 802 networks. The TSN TG specifies the tools of the TSN toolbox and the use of these tools for specific purposes. The TSN TG is chartered to provide deterministic services over IEEE 802 networks:

[0006] · Guaranteed packet transmission,

[0007] · Low packet loss,

[0008] · Bounded low latency, and

[0009] · Low packet delay variation.

[0010] To achieve extremely low packet loss, the TSN TG specifies frame replication and elimination for reliability (FRER) (802.1CB), which is designed to avoid frame loss due to device failures. It is actually a 1+1 (or 1+n) redundancy function per frame. There is no combined fault detection / handoff. FRER sends frames on two (or more) maximally disjoint paths, then combines the streams and deletes the extra frames.

[0011] Note that the same function as the packet replication and elimination function (PREF) is defined for deterministic networking (DetNet) networks to simplify implementation and allow the same concept to be used in layer 2 (TSN) and layer 3 (DetNet) networks. In the description provided herein, the focus is on FRER.

[0012] Note that according to IEEE 802.1CB: “… This standard defines Frame Replication and Elimination for Reliability (FRER), which divides a stream into one or more chained member streams, thus making the original stream a composite stream. It replicates the packets of the stream, splits the replicas into multiple member streams, and then recombines those member streams at one or more other points, eliminates the replicas, and delivers the reconstructed stream from those points.”

[0013] The elimination function evaluates the “sequence_number” subparameter of packets of one or more member streams passed up from a lower layer in order to discard duplicate packets. The “SequenceHistory” variable maintains a history of the “sequence_number” subparameters of the most recently received packets. During duplicate elimination, the “sequence_number” is checked against a history window (“+ / -frerSeqRcvyHistoryLength”). Packets outside the history window are discarded as invalid. Under normal operation, received packets are within the history window, and only replicas are discarded.

[0014] IEEE 802.1CB defines a timeout mechanism for the elimination function in order to cope with some networking scenarios that cause frames to be discarded unnecessarily (e.g., if the elimination function somehow becomes out of sync with its corresponding sequence generation function; if the sequence generation function is reset; etc.). If a timeout occurs, the history is reset, and the next packet is allowed to be accepted via a recovery algorithm regardless of the value of its “sequence_number” subparameter (see “TakeAny” in 7.4.3.2.6 of IEEE 802.1CB).

[0015] Regarding FRER as defined in IEEE 802.1CB, there are currently some challenges. The reset method of the sequence recovery function defined in IEEE 802.1CB-2017 may sometimes result in temporary duplicate delivery. Duplicate delivery (even if temporary) is unacceptable for a TSN network because it breaks one of the basic design rules, i.e., a TSN stream is not allowed to consume more resources than those reserved for it. Consuming more than the specified resources via duplicate delivery may lead to violations of the quality of service (QoS) requirements of some streams, e.g., delay or loss violations. SUMMARY OF THE INVENTION

[0016] Systems and methods are disclosed herein for avoiding duplicate delivery in a reset mechanism for seamless redundancy in, for example, a time-sensitive networking (TSN) network or a deterministic networking (DetNet) network. In one embodiment, a method performed by a receiving node implementing a redundancy mechanism based on sequence numbers or equivalent functionality includes: receiving, via a network from a transmitting node, packets from a plurality of packet flows. Each packet flow of the plurality of packet flows is a copy of a particular packet flow, the plurality of packet flows traverse separate paths from the transmitting node through the network to the receiving node, and each packet of each packet flow of the plurality of packet flows includes a sequence indicator indicating the position of the packet within the particular packet flow. The method further includes: performing an elimination procedure that processes each received packet to determine whether to discard or accept the received packet, wherein performing the elimination procedure includes: when a packet is received, resetting one or more parameters employed by the elimination procedure in response to the occurrence of an event; and in response to resetting the one or more parameters employed by the elimination procedure, discarding all received packets processed by the elimination procedure from the time the elimination procedure is reset until the end of a defined period. In this way, duplicate delivery does not occur due to the reset of the sequence generation function for sequence number-based seamless redundancy.

[0017] In one embodiment, the duration of the defined period is equal to or greater than the maximum path delay difference between any two paths traversed by the plurality of packet flows through the network. In another embodiment, the duration of the defined period is equal to the maximum path delay difference between any two paths traversed by the plurality of packet flows through the network.

[0018] In one embodiment, discarding the received packets processed by the elimination procedure from the time the elimination procedure is reset until the end of the defined period includes: starting a timer that is set to a value equal to or greater than the maximum path delay difference between any two paths traversed by the plurality of packet flows through the network; and discarding the received packets processed by the elimination procedure as long as the timer is running.

[0019] In one embodiment, performing the elimination procedure further includes: accepting the first received packet after the end of the defined period.

[0020] In one embodiment, the network is a TSN network, and the elimination procedure is performed as part of the frame replication and elimination for reliability (FRER) function of the receiving node. In one embodiment, the one or more parameters for reset include a recovery sequence number parameter and a sequence history parameter.

[0021] In one embodiment, the network is a DetNet network, and the elimination procedure is performed as part of the packet replication and elimination function (PREF) function of the receiving node.

[0022] In one embodiment, the sequence indication is a sequence number. In another embodiment, the sequence indication is a timestamp.

[0023] Corresponding embodiments of the receiving node are also disclosed. In one embodiment, a receiving node implementing a redundancy mechanism based on sequence numbers or equivalent functionality is adapted to: receive packets from a plurality of packet flows from a transmitting node via a network. Each packet flow of the plurality of packet flows is a replication of a specific packet flow, the plurality of packet flows traverse separate paths from the transmitting node through the network to the receiving node, and each packet of each packet flow of the plurality of packet flows includes a sequence indication indicating the position of the packet within the specific packet flow. The receiving node is further adapted to: perform an elimination procedure that processes each received packet to determine whether to discard or accept the received packet. To perform the elimination procedure, the receiving node is further adapted to: when receiving a packet, reset one or more parameters used by the elimination procedure in response to the occurrence of an event; and in response to resetting one or more parameters used by the elimination procedure, discard all received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of a defined period.

[0024] In one embodiment, a receiving node implementing a redundancy mechanism based on sequence numbers or equivalent functionality includes: a network interface; and processing circuitry associated with the network interface. The processing circuitry is configured to cause the receiving node to receive packets from a plurality of packet flows from a transmitting node via the network. Each packet flow of the plurality of packet flows is a replication of a specific packet flow, the plurality of packet flows traverse separate paths from the transmitting node through the network to the receiving node, and each packet of each packet flow of the plurality of packet flows includes a sequence indication indicating the position of the packet within the specific packet flow. The processing circuitry is further configured to cause the receiving node to perform an elimination procedure that processes each received packet to determine whether to discard or accept the received packet. To perform the elimination procedure, the processing circuitry is further configured to cause the receiving node to: when receiving a packet, reset one or more parameters used by the elimination procedure in response to the occurrence of an event; and in response to resetting one or more parameters used by the elimination procedure, discard all received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of a defined period.

[0025] In one embodiment, a method performed by a receiving node that implements a redundancy mechanism based on sequence numbers or equivalent functionality includes: receiving, via a network from a transmitting node, packets from a plurality of packet flows. Each packet flow among the plurality of packet flows is a copy of a specific packet flow, the plurality of packet flows traverse separate paths from the transmitting node through the network to the receiving node, and each packet in each packet flow among the plurality of packet flows includes a sequence indicator that indicates the position of the packet within the specific packet flow. The method further includes: performing an elimination procedure that processes each received packet to determine whether to discard or accept the received packet, wherein performing the elimination procedure includes: when a packet is received, detecting the occurrence of a reset event; and in response to detecting the reset event, performing one or more actions to discard or accept the received packet(s), wherein the one or more actions depend on the root cause of the reset.

[0026] In one embodiment, performing the one or more actions includes: determining the root cause of the reset event; determining whether the root cause of the reset event is a start event or an initialization event; and in response to determining that the root cause of the reset event is a start event or an initialization event, collecting and storing the first "n" received packets since the reset event, selecting, from among the first "n" received packets, the packet with the most recent sequence indicator, and accepting the selected packet and discarding the remaining packets among the first "n" received packets.

[0027] In one embodiment, performing the one or more actions includes: determining whether the root cause of the reset event is an administrative event; and in response to determining that the root cause of the reset event is an administrative event, determining whether the first received packet since the reset event can be accepted; and in response to determining that the first received packet since the reset event can be accepted, accepting the first received packet. In one embodiment, determining whether the first received packet since the reset event can be accepted includes: retaining a plurality of sequence recovery-related variables as they were before the reset event, wherein the plurality of sequence recovery-related variables includes a history window and one or more parameters indicating whether a packet with a specific sequence indicator has been received; determining whether the sequence indicator of the first received packet is outside a predefined history window; if the first received packet is outside the history window, determining that the first received packet can be accepted. Determining whether the first received packet since the reset event can be accepted further includes: if the first received packet is within the history window, determining, based on one or more parameters indicating whether a packet with a specific sequence indicator has been received, whether the first received packet has been received; and if the first received packet has been received, determining to discard the first received packet, otherwise, determining to accept the first received packet.

[0028] In one embodiment, performing one or more actions includes: determining whether a root cause of a reset event is a recovery timeout event; and in response to determining that the root cause of the reset event is a recovery timeout event, accepting the first received packet since the reset event.

[0029] In one embodiment, the network is a TSN network, and the elimination procedure is performed as part of the FRER function of the receiving node. In one embodiment, one or more parameters associated with the elimination procedure include a recovery sequence number parameter and a sequence history parameter.

[0030] In one embodiment, the network is a DetNet network, and the elimination procedure is performed as part of the PREF function of the receiving node.

[0031] In one embodiment, the sequence indication is a sequence number. In another embodiment, the sequence indication is a timestamp.

[0032] Corresponding embodiments of the receiving node are also disclosed. In one embodiment, a receiving node implementing a redundancy mechanism based on sequence number or equivalent functionality is adapted to: receive packets from multiple packet flows from a transmitting node via a network. Each packet flow among the multiple packet flows is a copy of a specific packet flow, the multiple packet flows pass from the transmitting node through the network to the receiving node via separate paths, and each packet of each packet flow among the multiple packet flows includes a sequence indication specifying the position of the packet within the specific packet flow. The receiving node is further adapted to: perform an elimination procedure that processes each received packet to determine whether to discard or accept the received packet. To perform the elimination procedure, the receiving node is further adapted to: when receiving a packet, detect the occurrence of a reset event; and in response to detecting the reset event, perform one or more actions to discard or accept the received packet, where the one or more actions depend on the root cause of the reset.

[0033] In one embodiment, a receiving node that implements a redundancy mechanism based on sequence numbers or equivalent functionality includes: a network interface; and processing circuitry associated with the network interface. The processing circuitry is configured to cause the receiving node to receive packets from a plurality of packet flows via the network from a transmitting node. Each packet flow of the plurality of packet flows is a copy of a particular packet flow, the plurality of packet flows traverse separate paths from the transmitting node through the network to the receiving node, and each packet of each packet flow of the plurality of packet flows includes a sequence indicator that indicates the position of the packet within the particular packet flow. The processing circuitry is further configured to cause the receiving node to perform an elimination procedure that processes each received packet to determine whether to discard or accept the received packet. To perform the elimination procedure, the processing circuitry is further configured to cause the receiving node to: when a packet is received, detect the occurrence of a reset event; and in response to detecting the reset event, perform one or more actions to discard or accept the received packet, where the one or more actions depend on the root cause of the reset. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0035] Figure 1 Illustrates such duplicate delivery after sequence recovery functionality at a reset receiving node in a time-sensitive networking (TSN) network;

[0036] Figure 2 Illustrates a system including a transmitting (TX) node and a receiving (RX) node in which embodiments of the disclosure may be implemented;

[0037] Figure 3 is shown in accordance with an embodiment of the first solution described herein Figure 2 a state diagram of the operation of the elimination function at the RX node;

[0038] Figure 4 is a flowchart showing the operation of the RX node in accordance with at least some aspects of the first solution described herein;

[0039] Figure 5 is shown in accordance with an embodiment of the second solution described herein Figure 2 a state diagram of the operation of the elimination function at the RX node;

[0040] Figure 6 is a flowchart showing the operation of the RX node in accordance with at least some aspects of the second solution described herein;

[0041] Figure 7A is shown in more detail in accordance with an embodiment of the present disclosure Figure 6Flowchart of step 602B;

[0042] Figure 7B is a more detailed illustration according to an embodiment of the present disclosure Figure 7A Flowchart of step 714; and

[0043] Figure 8 、 Figure 9 and Figure 10 are schematic block diagrams of RX nodes according to some embodiments of the present disclosure. Detailed Description

[0044] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0045] The embodiments set forth below represent information enabling those skilled in the art to practice these embodiments and illustrate the best mode of practicing these embodiments. Once the following description is read in light of the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure and will recognize applications of these concepts not particularly recited herein. It should be understood that these concepts and applications fall within the scope of the present disclosure.

[0046] In general, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or implied in the context in which the terms are used. All references to an / the element, device, component, part, step, etc. are to be interpreted openly as referring to at least one instance of the element, device, component, part, step, etc., unless otherwise explicitly stated. The steps of any method disclosed herein are not necessarily to be performed in the exact order disclosed, unless a step is explicitly described as being after or before another step and / or in a case where it is implied that a step must be after or before another step. In any appropriate case, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment herein may be applicable to any other embodiment, and vice versa. Other objectives, features, and advantages of the appended embodiments will be apparent from the following description.

[0047] There are certain challenges currently present with respect to Frame Replication and Elimination for Reliability (FRER) as defined in, for example, Institute of Electrical and Electronics Engineers (IEEE) 802.1CB. The reset method of the sequence recovery function defined in IEEE 802.1CB - 2017 may sometimes result in a temporary duplicate delivery. Duplicate delivery (even if temporary) is unacceptable for a Time - Sensitive Networking (TSN) network because it breaks one of the fundamental design rules, namely, that a TSN flow is not allowed to consume more resources than are reserved for it. Consuming more than the specified resources via duplicate delivery may result in violation of the Quality of Service (QoS) requirements of some flows, e.g., latency or loss violations.

[0048] IEEE 802.1CB - 2017 defines three reasons for resetting the sequence recovery function:

[0049] 1. BEGIN event (initialization / reset),

[0050] 2. Management event (also referred to as MNGMT event in this document) (frerSeqRcvyReset = true), and

[0051] 3. RECOVERY_TIMEOUT event (timeout mechanism expiration).

[0052] Resetting the sequence recovery function (see Section 7.4.3.3 SequenceRecoveryReset of 802.1CB - 2017) sets "RecovSeqNum" to "RecovSeqSpace - 1", clears the "SequenceHistory" array, and sets "TakeAny" to true.

[0053] Among the paths for seamless redundancy, the end - to - end delay of some paths is greater than that of other paths. The path with a smaller end - to - end delay is called the fast path, while the path with a larger end - to - end delay is called the slow path. Thus, for different copies / replicas of packets transmitted through different paths, the end - to - end delay is different. This phenomenon of seamless redundancy has an impact on its operation.

[0054] In Scenario - 1 (BEGIN) and Scenario - 2 (Management), the slow path may be transmitting a packet whose corresponding replica has been received and processed (forwarded) by the node's elimination function before the reset is generated. Such scenarios result in duplicate delivery. Figure 1Such repeated delivery is shown after the reset sequence recovery function. After the reset, the packet with sequence_number = 4 arrives via the fast path. It is accepted by the elimination function due to the true value of "TakeAny". Packets received via the slow path after the reset (i.e., Packet - 1, Packet - 2, and Packet - 3) are also accepted because they are within the history window and the reset has cleared the "SequenceHistory". However, these packets have already been delivered before the reset, so repeated delivery occurs.

[0055] Certain aspects and embodiments of the present disclosure may provide solutions to the above or other challenges. Systems and methods for avoiding repeated delivery in the reset mechanism of seamless redundancy in TSN or Deterministic Networking (DetNet) are disclosed herein. In particular, in some embodiments, these systems and methods ensure that the reset function does not cause repeated delivery. In one embodiment, a reset - protection period (also referred to herein as a protection timer) is added after the reset, during which received packets are discarded. In another embodiment, the reset procedure is modified to be root - cause related.

[0056] The embodiments disclosed herein provide improvements to the elimination function of IEEE 802.1CB to enable seamless reset of the sequence recovery function. In one embodiment, a reset method based on a protection timer is provided. In another embodiment, a reset method that takes into account the root cause of the reset is provided.

[0057] Embodiments of the solutions described herein may be applicable to the FRER of TSN, the Packet Replication and Elimination Function (PREF) of DetNet, or other seamless redundancy mechanisms based on sequence numbers or equivalent functionality (such as provided by timestamps). Generally, systems and methods for avoiding duplicate packets in the event of a reset of the sequencing function of a redundancy mechanism (such as the FRER of TSN or the PREF of DetNet) are described herein.

[0058] Certain embodiments may provide one or more of the following technical advantages. The embodiments described herein can ensure that no repeated delivery occurs due to the reset of the sequence generation function of sequence - number - based seamless redundancy.

[0059] The following description focuses on embodiments of a solution for improving the reset of the sequence recovery function in IEEE 802.1CB as described herein. Accordingly, IEEE 802.1CB terminology and variable names are used herein, denoted as "VariableName" where appropriate. New variables, functions, and parameters follow the IEEE 802.1CB naming convention and are denoted as "NewEntityName". Although the following description uses the terminology, definitions, and functions specified by IEEE 802.1CB, the solution described herein is applicable to the FRER of TSN, the PREF of DetNet, or other seamless redundancy mechanisms based on sequence numbers or equivalent functionality (e.g., provided by timestamps).

[0060] Figure 2 System 200 is shown, which includes a transmitting (TX) node 202 and a receiving (RX) node 204. The TX node 202 transmits a replicated packet stream to the RX node 204 via a TSN network 206. As discussed above, the transmission of the replicated packet stream involves copying the packet stream into multiple member streams to provide a composite stream. The member streams are then transmitted to the RX node 204 via the TSN network 206 via a maximum disjoint path that includes one or more fast paths and one or more slow paths. Note that although the nodes 202 and 204 are denoted as "TX node" and "RX node" herein, it should be understood that these nodes can transmit and receive streams via the TSN network 206.

[0061] As shown, the TX node 202 includes a FRER function 208 that operates to provide a FRER in this example according to IEEE 802.1CB. The FRER 208 includes a replication function 210 and an elimination function 212 (shown as optional in the sense that it is not used to transmit the stream to the RX node 204). In a similar manner, the RX node 204 includes a FRER function 214 that operates to provide a FRER in this example according to IEEE 802.1CB. The FRER 214 includes a replication function 216 (shown as optional in the sense that it is not used to receive the stream from the TX node 202) and an elimination function 222.

[0062] When receiving a member stream of the composite stream transmitted by TX node 202, the elimination function 218 at RX node 204 evaluates the "sequence_number" sub-parameter of each packet of each received member stream in order to discard duplicate packets. The "SequenceHistory" variable maintained by the FRER 214 at RX node 204 maintains a history of the "sequence_number" sub-parameters of the most recently received packets. During duplicate elimination, the "sequence_number" of the received packet is checked against the history window ("+ / -frerSeqRcvyHistoryLength"). If the packet is outside the history window, the packet is discarded as invalid. Under normal operation, the received packet is within the history window, and only duplicates are discarded. As described above, in some cases, the sequence recovery function (a part of the elimination function 218) at RX node 204 can be reset. Resetting the sequence recovery function sets "RecovSeqNum" to "RecovSeqSpace-1", clears the "SequenceHistory" array, and sets "TakeAny" to true. If a conventional reset mechanism is used, this may cause duplicate packets to be received (i.e., not discarded by the elimination function 218), as discussed above. Thus, systems and methods related to a new reset mechanism are described herein.

[0063] The root cause of duplicate delivery is that slow-path packets are within the history window by design. It is required for the proper operation of the elimination function 218 at RX node 204. Thus, the purpose of the history is to avoid duplicates. However, if the reset clears the history, the duplicate elimination capability provided by the history will be lost.

[0064] Two solutions are proposed herein, and each solution is described in detail below.

[0065] The first solution is to extend an added reset protection period for the reset mechanism, during which received packets are discarded. The duration of the reset protection period depends on the delay difference of the different paths used by the member streams. For example, the maximum path delay difference between any pair of member streams can be calculated as follows:

[0066] MaxPathDelayDiff = maximum value 对于所有"i”和"j” (PathDelay i - PathDelay j )

[0067] Wherein, "n" represents the number of member streams, and i, j = {1...n}. In one embodiment, the reset protection period is set to MaxPathDelayDiff. However, in an alternative embodiment, the reset protection period is set to a value greater than or equal to MaxPathDelayDiff.

[0068] In one embodiment, the elimination function 218 of the FRER 214 at the RX node 204 uses the reset protection period timer ("ResetGuardTimer") as follows:

[0069] · When the reset sequence recovery function is restored, the elimination function 218 sets "TakeAny" to true, sets "ResetGuardTimer" to the "MaxPathDelayDiff" of the stream, and clears the sequence number history ("SequenceHistory"). In IEEE802.1CB, "TakeAny" is a boolean value that indicates whether the elimination function 218 should accept the next packet regardless of the value of its sequence_number sub-parameter. "SequenceHistory" is the history of the packet sequence numbers that have been received for the stream.

[0070] · The elimination function 218 discards all received packets of the member stream until the "ResetGuardTimer" expires.

[0071] · Once the "ResetGuardTimer" has expired, the elimination function 218 accepts the first packet received from any of the member streams and updates "RecovSeqNum" and "SequenceHistory" accordingly. In IEEE 802.1CB, "RecovSeqNum" retains the highest sequence number value received (modulo(RecovSeqSpace)), or retains the value (RecovSeqSpace - 1) if no packets have been received since the reset sequence recovery function. The "RecovSeqNum" variable is an unsigned integer in the range from 0 to (RecovSeqSpace - 1). RecovSeqSpace is defined in Section 7.4.3.2.1 of IEEE 802.1CB. Whenever the function is reset, RecovSeqNum is initialized to (RecovSeqSpace - 1). When the increment exceeds its maximum value, the new value is 0.

[0072] · Return to normal elimination operation.

[0073] Figure 3It is a state diagram showing the operation of the cancellation function 218 at the RX node 204 according to the first solution. As shown, starting from the normal cancellation mode, packets are received and the normal cancellation procedure is executed. Once reset, the cancellation function 218 transitions to a state where the cancellation function 218 waits until the ResetGuardTimer expires. Before this timer expires, the cancellation function 218 discards all received packets. Once the ResetGuardTimer expires, the cancellation function 218 transitions to a state where the cancellation function 218 accepts or takes in any received packets. Once a packet is received, the cancellation function 218 returns to the state where the cancellation function 218 executes the normal cancellation mode.

[0074] Figure 4 It is a flowchart showing the operation of the RX node 204 according to at least some aspects of the first solution described above. Here, the operation of the RX node 204 is not limited to the FRER for TSN. Instead, Figure 4 the process is generally applicable to the FRER for TSN, the PREF for DetNet, or other seamless redundancy mechanisms based on sequence numbers or equivalent functionality (such as provided by timestamps). Note that the optional steps are indicated by dashed lines / dashed boxes.

[0075] As Figure 4 shown, the RX node 204 receives packets from multiple packet flows from the TX node 202 via a network (e.g., an Ethernet network using the TSN network (referred to herein as the TSN network) or a DetNet network (which can use any L2 networking technology, including but not limited to Ethernet)) (step 400). Each packet flow is a copy of a specific packet flow (e.g., in IEEE802.1CB terminology, each packet flow is a member flow). The packet flows pass through separate paths (e.g., maximally disjoint paths) from the TX node 202 through the network to the RX node 204. In addition, each packet in each of the multiple packet flows includes a sequence indicator indicating the position of the packet within the specific packet flow. For example, the sequence indicator can be a sequence number (e.g., as in IEEE802.1CB), a timestamp, or some equivalent mechanism for defining the position of the packet within the specific replicated packet flow.

[0076] The RX node 204 executes an elimination procedure that processes each received packet to determine whether to discard or accept the received packet (step 402). Executing the elimination procedure includes resetting one or more parameters used by the elimination procedure in response to the occurrence of an event when a packet is received (step 402A). For example, for FRER for TSN, the event can be a BEGIN event, a MNGMT event, or a RECOVERY_TIMEOUT event. In response to resetting the elimination procedure, the RX node 204 discards all received packets processed by the elimination procedure from the time the elimination procedure is reset until the end of the defined period (step 402B). In other words, the RX node 204 discards all received packets received and processed by the elimination procedure during the reset protection period. As discussed above, in some embodiments, the duration of the defined period is equal to or greater than the maximum path delay difference between any two paths through which multiple packets flow through the network. In some other embodiments, the duration of the defined period is equal to the maximum path delay difference between any two paths through which multiple packets flow through the network.

[0077] In some embodiments, discarding the received packets processed by the elimination procedure from the time the elimination procedure is reset until the end of the defined period includes: starting a timer that is set to a value equal to or greater than the maximum path delay difference between any two paths through which multiple packets flow through the network (step 402B1); and discarding the received packets processed by the elimination procedure as long as the timer is running (step 402B2). One embodiment of this timer is the reset protection period timer discussed above.

[0078] In one embodiment, executing the elimination procedure further includes: accepting the first received packet after the end of the defined period (step 402C); and updating one or more parameters used by the elimination procedure accordingly (step 402D), as described above.

[0079] In one embodiment, the network is a TSN network, and the elimination procedure is executed as part of the FRER function of the RX node 204. Additionally, in one embodiment, the one or more parameters reset in step 402A include a recovery sequence number parameter and a sequence history parameter, as described above. In another embodiment, the network is a DetNet network, and the elimination procedure is executed as part of the PREF function of the RX node 204.

[0080] In the second solution disclosed herein, the reset procedure is modified according to the root cause of the reset. In the following description, "n" represents the number of member streams. The root cause of the reset can be a BEGIN event, a MNGMT event (a reset initiated by the management of the sequence recovery function), or a RECOVERY_TIMEOUT event. The operation of the elimination function 218 at the RX node 204 according to the second solution is described below for each of these root causes of the reset. However, note that it is not required that the elimination function 218 implement the second solution for all of these root causes of the reset. Instead, the elimination function 218 can implement the second solution for any one or more of these root causes of the reset.

[0081] In the case where the root cause of the reset is a BEGIN event, there is a node initialization or reset. All variables are set to their default values, and their values before the reset event are forgotten. When the BEGIN event causes a reset, the elimination function 218 of the RX node 204 operates as follows:

[0082] · When the sequence recovery function of the elimination function 218 is reset due to a BEGIN event, the elimination function 218 collects and stores the first "n" received packets from any one of the member streams.

[0083] · The elimination function 218 selects the packet with the largest "sequence_number" from among the collected and stored packets. If there are multiple packets with the largest "sequence_number", the elimination function 218 picks one of them (e.g., any one of them). Note that the largest "sequence_number" is selected by taking into account the cyclic nature of the sequence number space. Also note that in a properly designed system, the difference in the sequence_numbers of these "n" packets is within the history window.

[0084] · The elimination function 218 only forwards the selected packet (e.g., forwards it to one or more higher layers in the protocol stack of the RX node 204), and discards all other stored packets.

[0085] · The elimination function 218 sets "RecovSeqNum" to the sequence_number of the selected packet, and sets the history to all "1"s ("SequenceHistory" = [1,...,1]) (i.e., sets the history to indicate that all packets within the history window have been received). Packets with sequence numbers lower than RecovSeqNum are not accepted.

[0086] · Then, the elimination function 218 can return to normal operation.

[0087] In the case where the root cause of the reset is an MNGMT event, the management system has requested a reset of the sequence recovery function via the "frerSeqRcvyReset" variable. In this case, the values of the sequence recovery-related variables are retained as they were before the reset, and these values are used during the evaluation of received packets. When an MNGMT event causes a reset, the elimination function 218 of the RX node 204 operates as follows:

[0088] · When the sequence recovery function of the elimination function 218 is reset due to an MNGMT event, the elimination function 218 checks whether it can accept the first received packet from any of the member streams after the reset as follows:

[0089] ο If the sequence_number of the received packet is outside the history window (HSW: history window {RecovSeqNum + d;...; RecovSeqNum - d + 1}, where d = "frerSeqRcvyHistoryLength"), then the packet is accepted. Set "RecovSeqNum" to the sequence_number of the received packet, and update the history to indicate acceptance ("SequenceHistory" = [1, 0,..., 0]).

[0090] ο If the sequence_number of the received packet is within the history window (HSW: history window {RecovSeqNum + d;...; RecovSeqNum - d + 1}, where d = "frerSeqRcvyHistoryLength"), then it is evaluated against the retained values of "RecovSeqNum" and "SequenceHistory" to determine whether the packet has been received. If the packet has been received, then it is discarded. If the packet has not been received, then it is forwarded, and "RecovSeqNum" and "SequenceHistory" are updated accordingly.

[0091] · Return to the normal operation of the elimination function 218.

[0092] In the case where the root cause of the reset is a RECOVERY_TIMEOUT event, the timeout mechanism triggers the reset. If the timeout mechanism is properly designed, the timeout lasts longer than the delay difference of the different paths of the member streams; thus, the history can be cleared, and the first packet can be accepted without any risk of duplicate delivery. When a RECOVERY_TIMEOUT event causes a reset, the elimination function 218 of the RX node 204 operates as follows:

[0093] · When the sequence recovery function of the elimination function 218 is reset due to the RECOVERY_TIMEOUT event, the elimination function 218 accepts the first received packet, forwards the packet (e.g., forwards it to one or more higher layers in the protocol stack of the RX node 204), sets "RecovSeqNum" to the sequence_number of the received packet, and updates the history accordingly (e.g., updates the history to "SequenceHistory" = [1,0,...,0]).

[0094] · Return to the normal operation of the elimination function.

[0095] Figure 5 It is a state diagram when the root cause of the reset is considered in the reset procedure according to the second solution described above.

[0096] Figure 6 The operation of the RX node 204 is shown according to at least some aspects of the second solution described above. Here, the operation of the receiving node 204 is not limited to the FRER for TSN. Instead, Figure 6 The process is generally applicable to the FRER for TSN, the PREF for DetNet, or other seamless redundancy mechanisms based on sequence numbers or equivalent functionality (e.g., provided by timestamps). Note that the optional steps are indicated by dashed / dotted boxes.

[0097] As Figure 6 shown, the receiving node 204 receives packets from multiple packet flows from the TX node 202 via a network (e.g., a TSN network or a DetNet network) (step 600). Each packet flow is a copy of a specific packet flow (e.g., in IEEE802.1CB terminology, each packet flow is a member flow). The packet flows traverse separate paths (e.g., maximally disjoint paths) from the TX node 202 through the network to the RX node 204. In addition, each packet in each of the multiple packet flows includes a sequence indication that specifies the position of the packet within the specific packet flow. For example, the sequence indication can be a sequence number (e.g., as in IEEE802.1CB), a timestamp, or some equivalent mechanism for defining the position of the packet within the specific replicated packet flow.

[0098] The RX node 204 performs an elimination procedure that processes each received packet to determine whether to discard or accept the received packet (step 602). Performing the elimination procedure includes: when receiving a packet, detecting the occurrence of a reset event (step 602A). For example, for the FRER for TSN, the reset event can be a BEGIN event, a MNGMT event, or a RECOVERY_TIMEOUT event. In response to detecting the reset event, the RX node 204 performs one or more actions to discard or accept the received packet(s), where the one or more actions depend on the root cause of the reset event (step 602B). Then, the RX node 204 can resume normal operation with respect to the elimination procedure (step 602C).

[0099] Figure 7A is a flowchart that more specifically illustrates step 602B according to at least some aspects of the second solution. Similarly, the operation of the receiving node 204 is not limited to the FRER for TSN. Instead, Figure 7A the process is generally applicable to the FRER for TSN, the PREF for DetNet, or other seamless redundancy mechanisms based on sequence numbers or equivalent functionality (such as provided by a timestamp). Note that optional steps are represented by dashed / dotted boxes.

[0100] As Figure 7A shown, to perform one or more actions to discard or accept the received packet(s) since the reset based on the root cause of the reset, the RX node 204 determines the root cause of the reset (step 700). Similarly, using the FRER as an example, the root cause can be a BEGIN event, a MNGMT event, or a RECOVERY_TIMEOUT event. Although Figure 7A these terms are used herein, they are to be understood in this context as generally covering the corresponding events in the PREF.

[0101] The RX node 204 determines whether the root cause of the reset is a BEGIN event or an initialization event (step 700). If the root cause is a BEGIN event or an initialization event (step 702, yes), the variables are set to their default values and their values before the reset event are forgotten, as described above. In addition, the RX node 204 collects and stores the first "n" received packets since the reset (step 704), selects the packet with the latest sequence indication (e.g., the largest sequence number) (step 706), accepts the selected packet, and discards the remaining packets among the first "n" received packets (step 708). The RX node 204 updates the parameter(s) of the elimination procedure accordingly, as described above (step 710).

[0102] If the root cause is an MNGMT event (step 702, no; and step 712, yes), then the RX node 204 determines whether it can accept the first received packet since the reset (step 714). If so, the RX node 204 accepts the first received packet and updates the parameter(s) of the elimination procedure accordingly, as described above (step 716). Regarding step 714, in one embodiment as shown in Figure 7B the RX node 204 determines whether it can accept the first received packet by retaining a plurality of sequence recovery related variables as they were before the reset, where the plurality of sequence recovery related variables includes a history window and one or more parameters indicating whether a packet with a specific sequence indication has been received (e.g., "RecovSeqNum" and "SequenceHistory"); and determining whether the sequence indication of the first received packet is outside a predefined history window (steps 714-1 and 714-2). If the first received packet is outside the history window (step 714-2, yes), then the RX node 204 determines that it can accept the first received packet (714-3). If the first received packet is within the history window (step 714-2, no), then the RX node 204 determines whether it has received the first received packet based on one or more parameters indicating whether a packet with a specific sequence indication has been received (step 714-3). If it has received the first received packet (step 714-3, yes), then the RX node 204 determines that it can discard the first received packet (step 714-5); otherwise, the RX node 204 determines that it can accept the first received packet (step 714-6).

[0103] Returning to Figure 7A , if the root cause of the reset is a recovery timeout event (step 702, no; and step 712, no), then the RX node 204 accepts the first received packet since the reset (step 718) and updates the parameter(s) of the elimination procedure accordingly, as described above (step 720).

[0104] Similarly, in one embodiment, the network is a TSN network and the elimination procedure is performed as part of the FRER function of the RX node 204. In one embodiment, one or more parameters of the reset include a recovery sequence number parameter and a sequence history parameter. In another embodiment, the network is a DetNet network and the elimination procedure is performed as part of the PREF function of the RX node 204.

[0105] As discussed above, in one embodiment, the sequence indication is a sequence number. In another embodiment, the sequence indication is a timestamp.

[0106] Figure 8 It is a schematic block diagram of the RX node 204 according to some embodiments of the present disclosure. As shown, the RX node 204 includes one or more processors 804 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or similar devices), a memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. The one or more processors 804 operate to provide one or more functions of the RX node 204 as described herein. In some embodiments, the (one or more) functions are implemented by software, for example, stored in the memory 806 and executed by the one or more processors 804.

[0107] Figure 9 It is a schematic block diagram showing a virtualized embodiment of the RX node 204 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. In addition, other types of network nodes may have a similar virtualized architecture. Similarly, optional features are represented by dashed boxes.

[0108] As used herein, a "virtualized" RX node is an implementation of the RX node 204 in which at least a portion of the functionality of the RX node 204 is implemented as (one or more) virtual components (e.g., via (one or more) virtual machines executed on (one or more) physical processing nodes in (one or more) networks). As shown, in this example, the RX node 204 includes one or more processing nodes 900 coupled to (one or more) networks 902 or included as part of the network 902. Each processing node 900 includes one or more processors 904 (e.g., a CPU, an ASIC, an FPGA, and / or similar devices), a memory 906, and a network interface 908. In this example, the function 910 of the RX node 204 described herein is implemented at one of the processing nodes 900 or distributed in any desired manner among two or more of the processing nodes 900. In some particular embodiments, some or all of the function 910 of the RX node 204 described herein is implemented as virtual components executed by (one or more) virtual machines, and the (one or more) virtual machines are implemented in the (one or more) virtual environments taken over by the (one or more) processing nodes 900.

[0109] In some embodiments, a computer program comprising instructions is provided, which when executed by at least one processor, cause the at least one processor to perform the functionality of RX node 204 or a certain node (e.g., processing node 900), and the node implements one or more of the functions 910 of RX node 204 in a virtual environment according to any of the embodiments described herein. In some embodiments, a carrier comprising the above computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0110] Figure 10 is a schematic block diagram of RX node 204 according to some other embodiments of the present disclosure. RX node 204 includes one or more modules 1000, each of which is implemented in software. The (one or more) modules 1000 provide the functionality of RX node 204 described herein. This discussion is equally applicable to Figure 9 processing node 900, where the module 1000 can be implemented at one of the processing nodes 900 or distributed among multiple processing nodes 900.

[0111] Any suitable steps, methods, features, functions, or benefits disclosed herein can be performed by one or more functional units or modules of one or more virtual devices. Each virtual device can include a plurality of these functional units. These functional units can be implemented via a processing circuit (which can include one or more microprocessors or microcontrollers) and other digital hardware (which can include a digital signal processor (DSP), dedicated digital logic, etc.). The processing circuit can be configured to execute program code stored in a memory, and the memory can include one or several types of memories, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more telecommunication and / or data communication protocols and instructions for implementing one or more of the technologies described herein. In some implementations, the processing circuit can be used to cause the corresponding functional unit to perform the corresponding function according to one or more embodiments of the present disclosure.

[0112] Although the processes in the figures may show a specific order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.).

[0113] Some example embodiments of the present disclosure are as follows.

[0114] Example 1: A method performed by a receiving node (204), the receiving node implementing a redundancy mechanism based on a sequence number or equivalent functionality, the method comprising:

[0115] · Receiving (400) packets from a plurality of packet flows via a network from a transmitting node (202), wherein:

[0116] ο Each packet flow among the plurality of packet flows is a replication of a specific packet flow;

[0117] ο The plurality of packet flows pass from the transmitting node (202) through the network to the receiving node (204) via separate paths; and

[0118] ο Each packet of each packet flow among the plurality of packet flows includes a sequence indication indicating the position of the packet within the specific packet flow;

[0119] · Performing (402) an elimination procedure, the elimination procedure processing each received packet to determine whether to discard or accept the received packet, wherein performing (402) the elimination procedure includes:

[0120] ο When receiving (400) a packet, resetting (402A) one or more parameters used by the elimination procedure in response to the occurrence of an event; and

[0121] ο In response to resetting (402A) one or more parameters used by the elimination procedure, discarding (402B) all received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of a defined period.

[0122] Example 2: The method of Example 1, wherein the duration of the defined period is equal to or greater than the maximum path delay difference between any two paths through which the plurality of packet flows pass through the network.

[0123] Example 3: The method of Example 1, wherein the duration of the defined period is equal to the maximum path delay difference between any two paths through which the plurality of packet flows pass through the network.

[0124] Example 4: The method of Example 1, wherein discarding (402B) the received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of the defined period includes: starting (402B1) a timer, the timer being set to a value equal to or greater than the maximum path delay difference between any two paths through which the plurality of packet flows pass through the network; and discarding (402B2) the received packets processed by the elimination procedure as long as the timer is running.

[0125] Example 5: The method of any one of Examples 1 to 4, wherein performing (402) the elimination procedure further includes: accepting (402C) the first received packet after the end of the defined period.

[0126] Example 6: The method of any one of Examples 1 to 5, wherein the network is a time-sensitive networking TSN network, and the elimination procedure is performed as part of the frame replication and elimination FRER function for reliability at the receiving node (204).

[0127] Example 7: The method of Example 6, wherein the one or more reset parameters include a recovery sequence number parameter and a sequence history parameter.

[0128] Example 8: The method of any one of Examples 1 to 5, wherein the network is a deterministic networking DetNet network, and the elimination procedure is performed as part of the packet replication and elimination function PREF function at the receiving node (204).

[0129] Example 9: The method of any one of Examples 1 to 8, wherein the sequence indication is a sequence number.

[0130] Example 10: The method of any one of Examples 1 to 8, wherein the sequence indication is a timestamp.

[0131] Example 11: A method performed by a receiving node (204), the receiving node implementing a redundancy mechanism based on a sequence number or equivalent functionality, the method comprising:

[0132] · Receiving (600) packets from a plurality of packet flows via a network from a transmitting node (202), wherein:

[0133] ο Each packet flow in the plurality of packet flows is a replication of a specific packet flow;

[0134] ο The plurality of packet flows pass from the transmitting node (202) through the network to the receiving node (204) through separate paths; and

[0135] ο Each packet in each packet flow in the plurality of packet flows includes a sequence indication indicating the position of the packet within the specific packet flow;

[0136] · Performing (602) an elimination procedure, the elimination procedure processing each received packet to determine whether to discard or accept the received packet, wherein performing (602) the elimination procedure includes:

[0137] ο When receiving (600) a packet, detecting (602A) the occurrence of a reset event; and

[0138] ο In response to detecting (602A) the reset event, performing (602B) one or more actions to discard or accept the received packet(s), wherein the one or more actions depend on the root cause of the reset.

[0139] Example 12: The method of Example 11, wherein performing (602B) one or more actions includes:

[0140] · Determining (700) the root cause of the reset event;

[0141] · Determining (702) whether the root cause of the reset event is a start event or an initialization event;

[0142] · In response to determining (702, yes) that the root cause of the reset event is a start event or an initialization event:

[0143] ο Collecting and storing (704) the first "n" received packets since the reset event;

[0144] ο Selecting (706) from among the first "n" received packets the packet having the latest sequence indication (e.g., the largest sequence number); and

[0145] ο Accepting (708) the selected packet and discarding the remaining packets among the first "n" received packets.

[0146] Example 13: The method of Example 11 or 12, wherein performing (602B) one or more actions includes:

[0147] · Determining (712) whether the root cause of the reset event is an administrative event;

[0148] · In response to determining (712, yes) that the root cause of the reset event is an administrative event:

[0149] ο Determining (714) whether the first received packet since the reset event can be accepted; and

[0150] ο In response to determining (714, yes) that the first received packet since the reset event can be accepted, accepting (716) the first received packet.

[0151] Example 14: The method of Example 13, wherein determining (714) whether the first received packet since the reset event can be accepted includes:

[0152] · Retaining a plurality of sequence recovery related variables as they were before the reset event, the plurality of sequence recovery related variables including a history window and one or more parameters (e.g., "RecovSeqNum" and "SequenceHistory") indicating whether a packet with a specific sequence indication has been received;

[0153] · Determining whether the sequence indication of the first received packet is outside a predefined history window;

[0154] · If the first received packet is outside the history window, determine that the first received packet can be accepted; and

[0155] · If the first received packet is within the history window, then:

[0156] ο Determine whether the first received packet has been received based on one or more parameters indicating whether a packet with a specific sequence indication has been received;

[0157] ο If the first received packet has been received, discard the first received packet;

[0158] ο Otherwise, accept the first received packet.

[0159] Example 15: The method of any one of Examples 11 to 14, wherein performing (602B) one or more actions includes: determining (702, no; and 712, no) whether the root cause of the reset event is a recovery timeout event; and in response to determining (702, no; and 712, no) that the root cause of the reset event is a recovery timeout event, accepting (718) the first received packet since the reset event.

[0160] Example 16: The method of any one of Examples 11 to 15, wherein the network is a Time-Sensitive Networking (TSN) network, and the elimination procedure is performed as part of the Frame Replication and Elimination for Reliability (FRER) function of the receiving node (204).

[0161] Example 17: The method of Example 16, wherein one or more parameters associated with the elimination procedure include a recovery sequence number parameter and a sequence history parameter.

[0162] Example 18: The method of any one of Examples 11 to 15, wherein the network is a Deterministic Networking (DetNet) network, and the elimination procedure is performed as part of the Packet Replication and Elimination Function (PREF) of the receiving node (204).

[0163] Example 19: The method of any one of Examples 11 to 18, wherein the sequence indication is a sequence number.

[0164] Example 20: The method of any one of Examples 11 to 18, wherein the sequence indication is a timestamp.

[0165] Example 21: A receiving node (204) implementing a redundancy mechanism based on sequence number or equivalent functionality, the receiving node (204) being adapted to perform the method of any one of Examples 1 to 20.

[0166] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

Claims

1. A method performed by a receiving node (204), the receiving node implementing a redundancy mechanism based on a sequence number or its equivalent functionality, the method comprising: ● Receive (400) packets from multiple packet flows via a network from a transmitting node (202), where the network is one of a Time-Sensitive Networking (TSN) network and a Deterministic Networking (DetNet) network, and where: ○ Each packet flow among the multiple packet flows is a copy of a specific packet flow; ○ The multiple packet flows traverse separate paths from the transmitting node (202) through the network to the receiving node (204); and ○ Each packet of each packet flow among the multiple packet flows includes a sequence indicator indicating the position of the packet within the specific packet flow; ● Perform (402) an elimination procedure that processes each received packet to determine whether to discard or accept the received packet, where performing (402) the elimination procedure includes: ○ When receiving (400) the packet, reset (402A) one or more parameters used by the elimination procedure in response to the occurrence of an event; and ○ In response to resetting (402A) the one or more parameters used by the elimination procedure, discard (402B) all the received packets processed by the elimination procedure from the time the elimination procedure is reset until the end of a defined period.

2. The method according to claim 1, wherein, The duration of the defined period is equal to or greater than the maximum path delay difference between any two paths traversed by the multiple packet flows through the network.

3. The method according to claim 1, wherein, The duration of the defined period is equal to the maximum path delay difference between any two paths traversed by the multiple packet flows through the network.

4. The method according to claim 1, wherein, Discarding (402B) the received packets processed by the elimination procedure from the time the elimination procedure is reset until the end of the defined period includes: Start (402B1) a timer that is set to a value equal to or greater than the maximum path delay difference between any two paths traversed by the multiple packet flows through the network; and As long as the timer is running, discard (402B2) the received packets processed by the elimination procedure.

5. The method according to any one of claims 1 to 4, wherein, Performing (402) the elimination procedure further includes: accepting (402C) the first received packet after the end of the defined period.

6. The method according to any one of claims 1 to 4, wherein, The network is a Time-Sensitive Networking (TSN) network, and the elimination procedure is performed as part of the Frame Replication and Elimination for Reliability (FRER) function of the receiving node (204).

7. The method according to claim 6, wherein, The reset one or more parameters include a recovery sequence number parameter and a sequence history parameter.

8. The method according to any one of claims 1 to 4, wherein, The network is a Deterministic Networking (DetNet) network, and the elimination procedure is performed as part of the Packet Replication and Elimination Function (PREF) of the receiving node (204).

9. The method according to any one of claims 1 to 4, wherein, The sequence indicator is a sequence number.

10. The method according to any one of claims 1 to 4, wherein, The sequence indicator is a timestamp.

11. A receiving node (204), the receiving node implementing a redundancy mechanism based on a sequence number or its equivalent functionality, the receiving node (204) being adapted to: ● Receive (400) packets from a plurality of packet flows from a transmitting node (202) via a network, wherein the network is one of a time-sensitive networking TSN network and a deterministic networking DetNet network, and wherein: ○ Each packet flow among the multiple packet flows is a copy of a specific packet flow; ○ The multiple packet flows traverse separate paths from the transmitting node (202) through the network to the receiving node (204); And ○ Each packet of each packet flow among the multiple packet flows includes a sequence indicator indicating the position of the packet within the specific packet flow; and ● Execute an elimination procedure (402) that processes each received packet to determine whether to discard or accept the received packet; ● wherein, to execute the elimination procedure (402), the receiving node (204) is further adapted to: ○ When receiving the packet (400), reset (402A) one or more parameters used by the elimination procedure in response to the occurrence of an event; and ○ In response to resetting (402A) the one or more parameters used by the elimination procedure, discard (402B) all received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of a defined period.

12. The receiving node (204) according to claim 11, wherein, The receiving node (204) is further adapted to execute the method according to any one of claims 2 to 10.

13. A receiving node (204), the receiving node implementing a redundancy mechanism based on a sequence number or its equivalent functionality, the receiving node (204) comprising: ● A network interface (808; 908); and ● Processing circuitry (804; 904) associated with the network interface (808; 908), the processing circuitry (804; 904) configured to cause the receiving node (204) to: ○ Receive (400) packets from multiple packet streams from a transmitting node (202) via a network, where the network is one of a Time-Sensitive Networking (TSN) network and a Deterministic Networking (DetNet) network, and wherein: ■ Each packet stream in the multiple packet streams is a copy of a specific packet stream; ■ The multiple packet streams pass through separate paths from the transmitting node (202) through the network to the receiving node (204); and ■ Each packet in each packet stream of the multiple packet streams includes a sequence indicator indicating the position of the packet within the specific packet stream; and ○ Execute an elimination procedure (402) that processes each received packet to determine whether to discard or accept the received packet; ○ wherein, to cause the receiving node (204) to execute the elimination procedure (402), the processing circuitry (804; 904) is further configured to cause the receiving node (204) to: ■ When receiving the packet (400), reset (402A) one or more parameters used by the elimination procedure in response to the occurrence of an event; and ■ In response to resetting (402A) the one or more parameters used by the elimination procedure, discard (402B) all received packets processed by the elimination procedure from the time of resetting the elimination procedure until the end of a defined period.

14. The receiving node (204) according to claim 13, wherein, The processing circuitry (804; 904) is further configured to cause the receiving node (204) to execute the method according to any one of claims 2 to 10.

15. A method performed by a receiving node (204), the receiving node implementing a redundancy mechanism based on a sequence number or its equivalent functionality, the method comprising: ● Receive (600) packets from multiple packet streams from a transmitting node (202) via a network, where the network is one of a Time-Sensitive Networking (TSN) network and a Deterministic Networking (DetNet) network, and wherein: ○ Each packet stream in the multiple packet streams is a copy of a specific packet stream; ○ The multiple packet streams pass through separate paths from the transmitting node (202) through the network to the receiving node (204); and ○ Each packet of each packet flow among the multiple packet flows includes a sequence indicator indicating the position of the packet within the specific packet flow; ● Execute (602) an elimination procedure that processes each received packet to determine whether to discard or accept the received packet, where executing (602) the elimination procedure includes: ○ When receiving (600) the packet, detect (602A) the occurrence of a reset event; and ○ In response to detecting (602A) the reset event, execute (602B) one or more actions to discard or accept one or more received packets, where the one or more actions depend on the root cause of the reset.

16. The method according to claim 15, wherein, Executing (602B) the one or more actions includes: Determine (700) the root cause of the reset event; Determine (702) whether the root cause of the reset event is a start event or an initialization event; In response to determining (702) that the root cause of the reset event is a start event or an initialization event: Collect and store (704) the first "n" received packets since the reset event; Select (706) the packet with the latest sequence indicator from among the first "n" received packets; and Accept (708) the selected packet and discard the remaining packets among the first "n" received packets.

17. The method according to claim 15, wherein, Executing (602B) the one or more actions includes: Determine (712) whether the root cause of the reset event is an administrative event; In response to determining (712) that the root cause of the reset event is an administrative event: Determine (714) whether the first received packet since the reset event can be accepted; and In response to determining (714) that the first received packet since the reset event can be accepted, accept (716) the first received packet.

18. The method according to claim 17, wherein, Determining (714) whether the first received packet since the reset event can be accepted includes: Retain (714-1) multiple sequence recovery-related variables as they were before the reset event, the multiple sequence recovery-related variables including a history window and one or more parameters indicating whether a packet with a specific sequence indicator has been received; determine (714-2) whether the sequence indicator of the first received packet is outside a predefined history window; If the first received packet is outside the history window (714-2), then determine (714-3) that the first received packet can be accepted; and If the first received packet is within the history window (714-2), then: Based on the one or more parameters indicating whether a packet with a specific sequence indicator has been received, determine (714-4) whether the first received packet has been received; If the first received packet has been received (714-4), then determine (714-5) to discard the first received packet; Otherwise, determine (714-6) to accept the first received packet.

19. The method according to any one of claims 15 to 18, wherein, Performing (602B) the one or more actions includes: Determining (702; 712) whether the root cause of the reset event is a recovery timeout event; In response to determining (702; 712) that the root cause of the reset event is a recovery timeout event, accepting (718) the first received packet since the reset event.

20. The method according to any one of claims 15 to 18, wherein, The network is a Time-Sensitive Networking (TSN) network, and the elimination procedure is performed as part of the Frame Replication and Elimination for Reliability (FRER) function of the receiving node (204).

21. The method according to claim 20, wherein, One or more parameters associated with the elimination procedure include a recovery sequence number parameter and a sequence history parameter.

22. The method according to any one of claims 15 to 18, wherein, The network is a Deterministic Networking (DetNet) network, and the elimination procedure is performed as part of the Packet Replication and Elimination Function (PREF) of the receiving node (204).

23. The method according to any one of claims 15 to 18, wherein, The sequence indication is a sequence number.

24. The method according to any one of claims 15 to 18, wherein, The sequence indication is a timestamp.

25. A receiving node (204) implementing a redundancy mechanism based on a sequence number or its equivalent functionality, the receiving node (204) being adapted to: ● Receive (600) packets from a plurality of packet flows from a transmitting node (202) via a network, wherein the network is one of a time-sensitive networking TSN network and a deterministic networking DetNet network, and wherein: ○ Each packet flow in the plurality of packet flows is a replication of a specific packet flow; ○ The plurality of packet flows traverse separate paths from the transmitting node (202) through the network to the receiving node (204); And ○ Each packet in each packet flow of the plurality of packet flows includes a sequence indication that indicates the position of the packet within the specific packet flow; And ● Performing (602) an elimination procedure that processes each received packet to determine whether to discard or accept the received packet; ● Wherein, to perform (602) the elimination procedure, the receiving node (204) is further adapted to: u When receiving (600) the packet, detecting (602A) the occurrence of a reset event; and u In response to detecting (602A) the reset event, performing (602B) one or more actions to discard or accept one or more received packets, wherein the one or more actions depend on the root cause of the reset.

26. The receiving node (204) as claimed in claim 25, wherein, The receiving node (204) is further adapted to perform the method according to any one of claims 16 to 24.

27. A receiving node (204) implementing a redundancy mechanism based on a sequence number or its equivalent functionality, the receiving node (204) comprising: ● A network interface (808; 908); And ● A processing circuit (804; 904) associated with the network interface (808; 908), the processing circuit (804; 904) configured to cause the receiving node (204) to: u Receive (600) packets from a plurality of packet flows via the network from a transmitting node (202), wherein the network is one of a Time-Sensitive Networking (TSN) network and a Deterministic Networking (DetNet) network, and wherein: ■ Each packet flow in the plurality of packet flows is a replication of a specific packet flow; ■ The plurality of packet flows traverse separate paths from the transmitting node (202) through the network to the receiving node (204); and ■ Each packet in each packet flow of the plurality of packet flows includes a sequence indication that indicates the position of the packet within the specific packet flow; and ○ Performing (602) an elimination procedure that processes each received packet to determine whether to discard or accept the received packet; ○ Wherein, in order to cause the receiving node (204) to perform (602) the cancellation procedure, the processing circuit (804; 904) is further configured to cause the receiving node (204) to: ■ When receiving (600) the packet, detect (602A) the occurrence of a reset event; and ■ In response to detecting (602A) the reset event, perform (602B) one or more actions to discard or accept one or more received packets, wherein the one or more actions depend on the root cause of the reset.

28. The receiving node (204) as claimed in claim 27, wherein, The processing circuit (804; 904) is further configured to cause the receiving node (204) to perform the method according to any one of claims 16 to 24.

29. A computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1-10 and 15-24.

30. A computer program product storing instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1-10 and 15-24.

Images