Method implemented in a packet-switched network for scheduling the transmission of Ethernet frames - Patents.com

Abstract

The present invention relates to a method implemented in a packet-switched network for scheduling the transmission of Ethernet frames, which determines, among several time-critical traffic frames to be transmitted, the time of the next transmission of future time-critical traffic frames (express frames) based on their respective priority levels. This determination of the next transmission time allows a fair timing of the transmission of such time-critical traffic frames, which may belong to different streams. It also allows the transmission of preemptible frames of non-time-critical traffic before said next transmission time.

Description

[Technical Field]

[0001] The present invention relates to the management of communication of Ethernet frames. [Background technology]

[0002] Packet-switched networks are increasingly being used for industrial control applications due to the introduction of Layer 2 features that allow for the transfer of control data that may not be subject to latency and transmission delay variations.

[0003] For example, low latency sampling data, (closed loop) control and image streaming (e.g., process control) have very stringent latency requirements. Image streaming as part of a control loop and associated processing has greater requirements than best effort transport can provide in a converged network.

[0004] At the same time, the best effort stream is not time critical, but rather provides a constant source of interference to the time critical stream.

[0005] Solutions are being progressively developed, especially for the adaptation of switched Ethernet to the requirements of industrial fieldbuses (eg EtherCAT, Ethernet Powerlink, TCnet, PROFINET, etc.).

[0006] All these solutions rely on adding specific proprietary developments to the standard Ethernet protocol that provide support for time-critical streams whose transmission requires controlled scheduling.

[0007] A common scheme used by these adaptations is based on organizing the transmit multiplex in time windows, with each window reserved for a particular stream type, the number of time windows and the repetition frequency being determined according to the requirements of the application.

[0008] Given the periodic activity of (industrial control) applications that generate scheduled streams, the transmit multiplex is ultimately organized into periodic cycles, each cycle containing a set of time windows reserved for scheduled (low latency) streams, with the remainder of the transmit opportunities devoted to unscheduled streams. This communication scheme is shown in Figure 1, which illustrates the periodic organization of the transmit multiplex.

[0009] However, in some environments, latency or jitter requirements are less stringent than in other control applications. Embedded automotive control networks are one such application. In these environments, the extra network engineering required by calculating schedules and synchronizing traffic sources with the network can be avoided if the selected traffic management method guarantees bounded jitter, bounded latency, and zero packet loss for critical control streams.

[0010] Traffic shaping according to predetermined data rates reserved across the network and negotiated with the network by the sources is a well-suited approach to achieving these performance goals, providing a means to guarantee transmission delay bounds and fairness between scheduled streams.

[0011] To further reduce potential sources of latency due to interference between scheduled and non-scheduled streams, a preemption mechanism is introduced. As shown in Figure 2, preemption occurs during the transition between a non-scheduled stream transmission opportunity and a scheduled stream transmission opportunity. Figure 2 illustrates a scheduled frame transmission that is ensured by fragmentation of a non-scheduled frame. Specifically, during such a transition, the start of a scheduled stream transmission opportunity may overlap with the end of a non-scheduled stream transmission opportunity. In such a case, the scheduled stream frame cannot be transmitted until the current transmission of the non-scheduled stream frame has finished.

[0012] By preempting the transmission opportunity for the remaining portion of the non-scheduled frame, it is possible to avoid incurring further delays for the scheduled stream. To facilitate the preemption operation, the frame for the non-scheduled stream can be fragmented and the transmission of the remaining fragment(s) can be delayed until the transmission opportunity for the scheduled stream is completed.

[0013] In an attempt to obtain efficient interworking between scheduled and unscheduled streams, two standards have been developed. 802.1Qbv: Defines a scheduling scheme that relies on the reservation of time windows for different traffic classes. 802.3br (for the MAC part) and 802.1Qbu (for the bridge management part): define a preemption scheme specifying the fragmentation mechanism to be applied to so-called "preemptable" frames, usually during the simultaneous transmission of so-called "express" frames belonging to a scheduled stream.

[0014] 802.1Qbv is based on a periodic calendar table, whose entries specify the opening and closing times of time windows reserved for the transmission of streams of various traffic classes. Scheduled and non-scheduled streams belong to these traffic classes. Due to the periodic nature of the calendar table used by 802.1Qbv, these standards provide an adapted framework for the transmission of periodic scheduled streams with minimal latency, a service similar to that provided by the industry standards cited above.

[0015] For preemption operation, two MAC service interfaces, a preemptable MAC (pMAC) service interface and an express MAC (eMAC) service interface, are designated to implement one level of frame preemption at the transmit port of a bridge or the transmit port of an end station, as illustrated in Figure 3, which shows the preemption protocol stack. The distribution of express traffic with preemptable traffic is achieved by a MAC merge sublayer that links the express media access control (eMAC) and preemptable MAC (pMAC) to a common coordination sublayer (RS) service.

[0016] For traffic classes identified as preemptable, frames selected for transmission are transmitted using the pMAC service instance, and for traffic classes identified as express, frames selected for transmission are transmitted using the eMAC service instance.

[0017] Preemption can only occur between express and preemptable frames, using express frames that have a higher priority than preemptable frames. When preemption occurs, transmission of the preempted frame resumes only when the express frame has been completely transmitted. A preemptable frame can be preempted multiple times. An express frame cannot be preempted by any other frame, but a preemptable frame can be preempted by any express frame.

[0018] The MAC merge lower layer provides one command, the MM_CTL.request primitive, to force the preemption process when there are no express frame transmissions. This specifies a request from the MAC client to the MAC merge lower layer to hold or release the transmission of preemptable traffic. Setting the "hold" command causes preemption to occur when conditions allow it, and prevents the start of pMAC frame transmission until the command is set to "release." In the latter case, if there are no packets to send in the eMAC, the MAC merge lower layer will transmit packets from the pMAC.

[0019] When preempted, frames are split into fragments, reformatted by the MAC merge sublayer, and sent to the Ethernet physical layer as complete frames. These complete frames carry separate payloads and have different formats to identify the first, middle, and last fragments of the preempted frame. Ports that support frame preemption transmit frames with a Start Frame Delimiter (SFD) byte replaced by one of the following: SMD-E for Express Frame, SMD-Sx for the opening fragment of a preemptible frame, or SMD-Cx for continuation fragments of preemptable frames.

[0020] FIG. 4 illustrates the corresponding frame and fragment formats.

[0021] Continuation fragments have a one-byte shorter preamble, providing space for a fragment counter, FCnt bytes. The middle and last fragments are terminated with a partial 4-byte CRC checksum (mCRC). The last fragment is terminated by the FCS of the whole frame, just as in express frames.

[0022] The size of the minimum non-last fragment (excluding FCS) can be fixed by configuration, maintaining compatibility with the Ethernet minimum frame size requirement of 64 bytes. It can take the value 64 × (1 + n) - 4, where 0 ≤ n ≤ 3. If fragmentation would produce fragments smaller than the minimum non-last fragment size, then fragmentation cannot occur. As a result, frames shorter than 64 × 2 × (1 + n) - 4 bytes cannot be fragmented.

[0023] On a switch that does not support preemption, a high-priority frame can be delayed by up to 123.36 μs on a 100 Mbps port, i.e., the duration of a maximum-sized frame at 100 Mbps. With frame preemption in place, the maximum express frame latency due to preemptable frame interference is reduced to 10.16 μs.

[0024] This residual delay can potentially have a negative impact on performance depending on the express stream timing requirements.

[0025] In order to mitigate the effect of transmission interference on higher priority frames by lower priority frames, a so-called guard band can be provided before the transmission of higher priority frames begins.

[0026] When preemption is implemented, the duration of such guard bands can be reduced to a minimum value corresponding to the maximum size of a non-fragmentable frame or fragment, e.g., 123 bytes, when the smallest non-last fragment size is 60 bytes. In this case, the preemption control command must be set to "hold" the time corresponding to that guard band before an express frame transmission is scheduled.

[0027] Fig. 5 illustrates the provision of such a guard band by preemption control using the HOLD command: the preemptable frame is split into two fragments, while the transmission of the express frame is scheduled on time.

[0028] Within the framework of the IEEE TSN standard, this combination of preemption and provision of guard bands is only used if express traffic transmissions are handled according to the 802.1Qbv standard, which explicitly defines the time windows reserved for the transmission of such traffic. Guard bands cannot be inserted before the transmission of individual frames.

[0029] The only IEEE TSN standard that allows for the implementation of guard bands to ensure on-time transmission of high-priority frames is 802.1Qbv, because the time window on which its transmission selection mechanism is based is defined according to a time reference that allows for the in-time insertion of guard bands. In such a configuration, guard bands can only be provided to protect periodic traffic that is synchronized to a common clock and whose cycles are multiples of a common base cycle.

[0030] However, when there is a need to combine communications with strict delay constraints but with individual independent cycles, or more generally with different traffic shapes that are not synchronized with a common cycle, the IEEE suite of standards does not provide any solution.

[0031] Thus, in the context of scheduling the transmission of Ethernet frames in a packet-switched network, it is desired to determine, as a general problem to be solved, a fair next transmission time for a time-critical traffic frame, taking into account, inter alia, the priority levels of various time-critical traffic streams, and optionally, in embodiments where a possible non-time-critical traffic frame is to be transmitted, to determine whether such transmission of the non-time-critical traffic frame (or at least a frame fragment) is possible, taking into account the next transmission time of the time-critical traffic frame. Summary of the Invention

[0032] The present invention aims to improve the above situation. a) identifying time-critical traffic frames among the Ethernet frames to be transmitted and a priority level for each of the time-critical traffic frames; b) obtaining data on the transmission time of each time-critical traffic frame (denoted as TCiNextTx in the accompanying drawings) and the transmission duration of each time-critical traffic frame (denoted as FrameDur(i)); c) comparing the transmission times of each time-critical traffic frame to determine a list of said transmission times in ascending order; d) for a first frame having a first transmission time at the top of the list, determining the sum of the first transmission time and the transmission duration of the first frame; e) determining whether at least one second transmission time in the list is less than the sum; If not, determining the next transmission time of the time-critical traffic frame as the first transmission time; If so, determining whether a second frame in the list having the second transmission time has a higher priority than the first frame; If not, determining the next transmission time of the time-critical traffic frame as the first transmission time; if so, removing the first transmission time from the list and repeating steps d) and e) using a new transmission time following the first transmission time in the list, said new transmission time becoming the first transmission time for performing the repetition of steps d) and e); f) scheduling the next transmission time of the time-critical traffic frame whose transmission time remains the first transmission time in the list; A method is proposed which includes:

[0033] In one embodiment, the transmission duration data for each time-critical traffic frame is obtained from a frame descriptor field provided within a data structure for the time-critical traffic frame.

[0034] In practice, the length of the frame is known from that field, and therefore its transmission duration can be determined based on its length and the link speed (which is usually known at any egress port of the transmitter device).

[0035] In one embodiment, the priority level of each time-critical traffic frame is defined according to the traffic class ("TCi" in TCiNextTx) to which the time-critical traffic frame belongs.

[0036] For example, the stream context defining a class TCi can usually be obtained from the priority codepoint in the VLAN tag of an Ethernet frame. This traffic class parameter TCi defines the "contractual" time at which frames related to that class parameter TCi should be transmitted. The next transmission time of such a frame of that traffic class TCi will be denoted hereafter and in the accompanying drawings as TCiNextTx.

[0037] For example, in some embodiments, consecutive time-critical traffic frames should be transmitted at their consecutive transmission times separated by the same time slot (as discussed above in connection with the 802.1Qbv standard, which is based on a periodic calendar table), but other time-critical traffic frames (e.g., some signaling frames) may relate to streams that are not periodically scheduled and therefore must be transmitted at specific times that are not necessarily related to the cycle.

[0038] Therefore, it is important to determine the respective priority levels of frames based on the traffic classes TCi, TCj, etc. to which they belong, and also to determine the fairest next transmission time for transmitting time-critical traffic frames, in the manner described above.

[0039] In one embodiment, time-critical traffic frames may be stacked in FIFO queues before their transmission, each queue corresponding to a traffic class to which the time-critical traffic frames belong.

[0040] As shown in FIG. 6, further described below, several FIFO queues can be assigned to one and the same traffic class.

[0041] In one embodiment, the transmission time of a time-critical traffic frame (TCiNextTx) may be defined relative to the current time given by a common clock of the packet-switched network.

[0042] In practice, since the traffic class duration is known and the common network time is known, the transmission time of each of the time-critical traffic frames can be finally determined.

[0043] In one embodiment that distinguishes time-critical traffic frames from non-time-critical traffic frames identified as preemptable traffic frames that are transmitted whenever there are no time-critical traffic frames to transmit, the next transmission time of the time-critical traffic frame determined in f) defines whether at least one minimum-sized fragment of the non-time-critical traffic frame can be transmitted relative to the current time.

[0044] In this embodiment, the implementation of the method up to f) is initiated each time a time-critical traffic frame is transmitted to define the next transmission time of a new time-critical traffic frame.

[0045] This embodiment makes it possible to determine early enough whether at least a fragment of a non-time-critical traffic frame can be transmitted depending on the time remaining until the next transmission time of the time-critical traffic frame.

[0046] wherein said one minimum size fragment of a non-time-critical traffic frame corresponds to the duration of a guard band interval (described above with reference to FIG. 5); if the next transmission time is determined in f) to occur after the start of the guard band interval, postponing any transmission of non-time-critical traffic; Otherwise, transmit at least one fragment of the non-time-critical traffic frame.

[0047] In this embodiment, for example, an offset due to command latency can be added to the duration of transmission of one minimum-sized fragment of a non-time-critical traffic frame to determine the appropriate duration of the guard band interval.

[0048] In such an embodiment, a transmission command may be defined that is set to a "hold" state before the start of the guard band interval (shown in FIG. 5) to prevent any transmission of a non-time-critical traffic frame when the next transmission time of a time-critical traffic frame occurs.

[0049] Here, the expression "before the start of the guard band interval" means "just before" the start of the guard band interval or at the start of the guard band interval.

[0050] The transmission command may also be set to the "release" state (shortly after) (or at) the start of transmission of the time-critical traffic frame.

[0051] The present invention is also directed to a computer program comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform the above-described method. The present invention is also directed to a computer-readable storage medium comprising instructions that, when executed by the processing circuit, cause the processing circuit to perform the above-described method.

[0052] The present invention also provides an apparatus, comprising: a processing circuit configured to perform the method; and a communications interface coupled to a packet-switched network and configured to be steered by the processing circuitry to transmit Ethernet frames when transmission of said Ethernet frames is scheduled by the processing circuitry; The present invention relates to an apparatus comprising:

[0053] Further details and advantages of the invention will become apparent from the detailed possible and optional embodiments and from the accompanying drawings. [Brief explanation of the drawings]

[0054] [Figure 1] FIG. 1 illustrates a cyclical organization of a transmission multiplex. [Figure 2] FIG. 1 illustrates a scheduled frame transmission guaranteed by fragmentation of a non-scheduled frame. [Figure 3] FIG. 1 illustrates an example of a preemption protocol stack. [Figure 4] FIG. 1 illustrates the format of a frame and a fragment. [Figure 5] FIG. 10 is a diagram illustrating a guard band provided by preemption control using a HOLD command. [Figure 6] FIG. 1 illustrates a situation for determining the next time-critical transmission time, and in particular example inputs for that purpose. [Figure 7] 4 is a flowchart illustrating some of the steps of the method described above that allows for determining the next transmission time of a time-critical traffic frame. [Figure 8] FIG. 1 shows an example of a device for carrying out the method. DETAILED DESCRIPTION OF THE INVENTION

[0055] In the embodiments presented hereinafter, it is proposed to integrate the management of MAC merge lower layer preemption control commands, which are originally performed for the transmission selection of individual frames or bursts of frames, into a general scheduling scheme.

[0056] The proposed mechanism is based on a priority level for each traffic and synchronization to a common time reference for the frame / burst scheduling scheme.

[0057] Hereinafter, "time-critical traffic" refers to traffic with strict transmission delay and jitter constraints. The transmission times of their frames are referenced to a common time reference shared among all nodes (end stations and bridges) of the network to ensure tight synchronization among all participants in the application. In order to enforce the delay and jitter requirements of time-critical traffic, transmission interference with non-time-critical traffic must be avoided.

[0058] Therefore, time-critical traffic belongs to a traffic class that is considered express traffic due to its priority level.

[0059] If there are several traffic classes associated with time-critical traffic, the transmission of frames of a traffic class at one priority level cannot interfere with the transmission of any frames of a traffic class at a higher priority level.

[0060] Therefore, time-critical traffic frames are treated as express frames.

[0061] Each frame of time-critical traffic is associated with a transmission time expressed in the same time base as network time, and a frame of time-critical traffic is considered to be transmitted when its transmission time expires.

[0062] Hereinafter, "non-time-critical traffic" refers, on the contrary, to traffic classes that are considered preemptible traffic due to their priority level, and the transmission times of their frames are not necessarily related to the common network time: they are transmitted whenever there is no transmission of time-critical traffic, according to a transmission selection mechanism that does not need to be detailed here.

[0063] It also performs hold command scheduling, the goal of which is to set the MAC merge control (MM_CTL.request primitive) command to state HOLD at a time that ensures that sufficient transmission guard band is provided before the transmission of time-critical frames.

[0064] The set time of this so-called "hold command" is fixed based on the network time and on the transmission time of the next time-critical frame.

[0065] The determination of the transmission time of this next time-critical frame is as follows:

[0066] The first scheduling step determines the transmission time of the next time-critical frame for each traffic class: TCiNextTx, where i is the traffic class identifier. In this parameterization TCiNextTx, the index i also determines the priority level p(i) of the traffic class.

[0067] The transmission duration of each frame is available in a data structure (frame descriptor) associated with the frame. The frame duration of a frame of traffic class TCi candidate for transmission (i.e., with transmission time TCiNextTx) is denoted FrameDur(i).

[0068] Frames are stored in queues before their transmission, and the way in which these queues are organized does not need to be detailed here.

[0069] TCiNextTx, Each time a frame of TCi is transmitted (i.e., passed to the MAC Service Layer), or Every time a TCi frame is received from the upper layer, evaluate.

[0070] The evaluation of TCiNextTx itself does not need to be detailed here.

[0071] If there are no frames of traffic class i available for transmission, ie, all queues storing frames of traffic class i are empty, then TCiNextTx is assigned a "null" value.

[0072] As shown in Figure 6, the TCiNextTx of all time-critical TCs of any priority level with a non-'null' value are compared with each other and put into an ordered list by the ascending order of their values, i.e., each element in this list is indexed by an index o such that TciNextTx[o] ≤ TcjNextTx[o+1].

[0073] To each element in this list is associated the transmission duration of a frame candidate for transmission for the traffic class, i.e. FrameDur(i) is associated with TCiNextTx.

[0074] The determination of the transmission time of the next time-critical frame is then obtained by performing the following algorithm, also illustrated in FIG.

[0075] That is, starting with the first (i.e., smallest) TCxNextTx in the ordered list, calculate the end of the transmission time (i.e., the sum of TCxNextTx and FrameDur(x)) of a frame candidate for a transmission of traffic class x: TcxNextTxEnd. If TCxNextTx is less than or equal to TCxNextTxEnd and its priority level p(y) is a traffic class higher than p(x), then the transmission of the frame candidate for a transmission of traffic class TCx will interfere with the transmission of a frame belonging to a traffic class with a higher priority level.

[0076] If so, repeat the transmission time of the next time-critical frame with the next element in the ordered list. Otherwise, select TCxNextTx as the transmission time of the next time-critical frame. This selection process is repeated until the last element in the ordered list is reached.

[0077] Here, for MAC merge lower layer control operations, the parameter HOLDTime is a date that, when it expires (ie, when the current time is greater than or equal to HOLDTime), causes the MM_CTL.request primitive to be set to HOLD.

[0078] HOLDTime is calculated as the result of subtracting TCxNextTx-HOLDOffset, where: TCxNextTx is the transmission time of the frame selected as the next time-critical frame to be transmitted, determined as described above. The HOLDOffset is a duration selected such that the MM_CTL.request primitive is preset to a long enough HOLD to allow the transmission of a non-fragmentable preemptable frame, or at least the last non-fragmentable fragment, to complete.

[0079] By doing so, a reserved transmission guard band is enforced before the transmission of an express frame. The HOLDOffset is calculated from the configurable length of the non-fragmentable frame or the last fragment and the bit rate of the transmission link.

[0080] Also, at the start of transmitting an express frame, the MM_CTL.request primitive is set to RELEASE.

[0081] As shown in Fig. 8, a device DEV, such as an end station, may include a processing circuit CIR for carrying out the above-described method, including a processor PROC and a memory MEM for storing at least instruction data of a computer program according to the present invention. The memory MEM may further include a memory unit arranged as a FIFO queue for temporarily storing incoming frames. The processor PROC can access the memory MEM to read and execute the instructions stored therein. The end station DEV also includes at least a communications interface COM having an egress port EGP and a clock CLK for enabling the processor PROC to operate in synchronization with the clock of the network NTW to which the interface COM is connected. The clock CLK typically ensures the use of the time synchronization protocol described above.

[0082] Thus, the present invention can be used in packet-switched networks that support a combination of time-critical and non-time-critical traffic, as may occur in industrial automation networks.

[0083] The present invention optimizes the design of Ethernet TSN network interfaces in industrial automation end stations (devices) and the use of network transmission resources.

[0084] In general, the present invention can be applied in embedded control networks, such as industrial, automotive, and aerospace networks, where a combination of time-critical and non-time-critical traffic is supported.

Claims

1. 1. A method implemented in a packet-switched network for scheduling transmission of Ethernet frames, comprising: a) identifying time-critical traffic frames among the Ethernet frames to be transmitted and a priority level for each of the time-critical traffic frames; b) obtaining data of a transmission time of each time-critical traffic frame and data of a transmission duration of each time-critical traffic frame; c) comparing the transmission times of each time-critical traffic frame to determine a list of the transmission times in ascending order; d) for a first frame having a first transmission time at the top of the list, determining the sum of the first transmission time and the transmission duration of the first frame; e) determining whether at least one second transmission time in the list is less than the sum; If not, determining the next transmission time of the time-critical traffic frame as the first transmission time; If so, determining whether a second frame in the list having the second transmission time has a higher priority than the first frame; If not, determining the next transmission time of the time-critical traffic frame as the first transmission time; if so, removing the first transmission time from the list and repeating steps d) and e) using a new transmission time following the first transmission time in the list, the new transmission time becoming the first transmission time for performing the repetition of steps d) and e); f) scheduling the next transmission time of the time-critical traffic frame whose transmission time remains the first transmission time of the list; A method comprising:

2. 2. The method of claim 1, wherein the transmission duration data for each time-critical traffic frame is obtained from a frame descriptor field provided in a data structure for the time-critical traffic frame.

3. 3. The method of claim 1, wherein the priority level of each time-critical traffic frame is defined according to the traffic class to which the time-critical traffic frame belongs.

4. 4. The method of claim 3, wherein the time-critical traffic frames are stacked in FIFO queues before their transmission, each queue corresponding to one traffic class, according to the traffic class to which the time-critical traffic frames belong.

5. A method according to any one of claims 1 to 4, wherein the transmission times of the time-critical traffic frames are defined relative to a current time given by a common clock of the packet-switched network.

6. 6. The method of claim 1, further comprising distinguishing the time-critical traffic frames from non-time-critical traffic frames, identifying the non-time-critical traffic frames as preemptable traffic frames that are transmitted whenever there are no time-critical traffic frames to transmit, and wherein the next transmission time of the time-critical traffic frame determined in step f) defines whether at least one minimum-sized fragment of the non-time-critical traffic frame can be transmitted relative to a current time.

7. 7. The method of claim 6, wherein performing the method up to step f) is initiated at least each time a time-critical traffic frame is transmitted to define the next transmission time of a new time-critical traffic frame.

8. the one minimum size fragment of a non-time-critical traffic frame corresponds to the duration of a guard band interval; if the next transmission time is determined in f) to occur after the start of the guard band interval, postponing transmission of any non-time-critical traffic; 8. The method according to claim 6 or 7, further comprising transmitting at least one fragment of the non-time-critical traffic frame otherwise.

9. 9. The method of claim 8, further comprising adding an offset due to command latency to the duration of transmission of one minimum-sized fragment of a non-time-critical traffic frame to determine the duration of the guard band interval.

10. 10. The method of claim 8 or 9, further comprising setting a transmission command to a "hold" state before the start of the guard band interval to prevent any transmission of a non-time-critical traffic frame when the next transmission time of a time-critical traffic frame occurs.

11. The method of claim 10 , further comprising setting the transmission command to a “released” state after initiation of transmission of the time-critical traffic frame.

12. A computer program comprising instructions which, when executed by a processing circuit, cause the processing circuit to perform the method of any one of claims 1 to 11.

13. A computer readable storage medium containing instructions which, when executed by a processing circuit, cause the processing circuit to perform the method of any one of claims 1 to 11.

14. 1. An apparatus comprising: a processing circuit configured to perform the method of any one of claims 1 to 11; a communications interface coupled to the packet-switched network and configured to be steered by the processing circuitry to transmit Ethernet frames when transmission of the Ethernet frames is scheduled by the processing circuitry; An apparatus comprising:

Images